warp7: include: configs: Differentiate bootscript address from loadaddr
Reusing the loadaddr to load the boot script breaks some of the logic we
want to have around the bootscript/FIT load addresses. Making a dedicated
bootscript address allows us to differentiate the bootscript load address
from the Linux Kernel or OPTEE load address, thus ensuring that no matter
what the load sequence the bootscript and Kernel/OPTEE binary load
addresses do not conflict.
Matti Vaittinen [Tue, 7 May 2019 07:45:55 +0000 (10:45 +0300)]
regulator: bd718x7: support ROHM BD71837 and BD71847 PMICs
BD71837 and BD71847 is PMIC intended for powering single-core,
dual-core, and quad-core SoC’s such as NXP-i.MX 8M. BD71847
is used for example on NXP imx8mm EVK.
Add regulator driver for ROHM BD71837 and BD71847 PMICs. BD71837 contains 8 bucks and 7 LDOS. BD71847 is reduced
version containing 6 bucks and 6 LDOs. Voltages for DVS
bucks (1-4 on BD71837, 1 and 2 on BD71847) can be adjusted
when regulators are enabled. For other bucks and LDOs we may
have over- or undershooting if voltage is adjusted when
regulator is enabled. Thus this is prevented by default.
BD718x7 has a quirk which may leave power output disabled
after reset if enable/disable state was controlled by SW.
Thus the SW control is only allowed for BD71837 bucks
3 and 4 by default. The impact of this limitation must be
evaluated board-by board and restrictions may need to be
modified. (Linux driver get's these limitations from DT and we
may want to implement same on u-Boot driver).
Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Commit 32ce6179fb99 ("optee: Add lib entries for sharing OPTEE code across
ports") adds code into lib/optee but neglects to update MAINTAINERS to make
me buggable for questions and maintenance.
optee: Make TZDRAM config options contingent on CONFIG_OPTEE
Commit c7b3a7ee5351 ("optee: adjust dependencies and default values for
dram") makes the TZDRAM defines for OPTEE show up for all configs as a
side-effect. While not harmful its not what we really want.
This patch makes the following defines contingent on CONFIG_OPTEE=y
CONFIG_OPTEE_TZDRAM_BASE
CONFIG_OPTEE_TZDRAM_SIZE
Rightly, if you don't have CONFIG_OPTEE=y you don't care about the above
two defines.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Cc: Rui Miguel Silva <rui.silva@linaro.org> Acked-by: Rui Miguel Silva <rui.silva@linaro.org>
Lukasz Majewski [Wed, 19 Jun 2019 15:31:06 +0000 (17:31 +0200)]
pinctrl: mxs: Add support for i.MX2[38] mxs pinctrl driver
The code responsible for setting proper values in the MUX registers
(in the mxs_pinctrl_set_state()) has been ported from Linux kernel
- SHA1: 17bb763e7eaf tag v5.1.11 from linux-stable.
As the pinctrl node in the imx28.dtsi file has gpio pins nodes as subnodes,
it was necessary to use 'dm_scan_fdt_dev()' (as a .bind method) to also
make them 'visible' by the DM's "gpio_mxs" driver.
Signed-off-by: Lukasz Majewski <lukma@denx.de> Reviewed-by: Marek Vasut <marex@denx.de>
Adam Ford [Thu, 23 May 2019 19:11:32 +0000 (14:11 -0500)]
ARM: imx6q_logic: With SPL_OF_CONTROL enabled, remove MMC init
Since the board uses SPL_OF_CONTROL now, we don't need to
explicitly initialize the MMC driver, but we still need to
pinmux the corresponding pins. This patch removes the
initialization code and leave just the muxing behind.
Adam Ford [Thu, 23 May 2019 19:11:31 +0000 (14:11 -0500)]
ARM: imx6q_logic: Enable SPL_DM with SPL_OF_CONTROL
With the spl code correctly returning either MMC1 or MMC2,
this board can not boot either from internal eMMC (MMC1) or
the uSD card on the baseboard (MMC2) using the device tree.
Adam Ford [Thu, 23 May 2019 19:11:30 +0000 (14:11 -0500)]
spl: imx6: Let spl_boot_device return USDHC1 or USDHC2
Currently, when the spl_boot_device checks the boot device, it
will only return MMC1 when it's either sd or eMMC regardless
of whether or not it's MMC1 or MMC2. This is a problem when
booting from MMC2 if MMC isn't being manually configured like in
the DM_SPL case with SPL_OF_CONTROL.
This patch will check the register and return either MMC1 or MMC2.
Shyam Saini [Fri, 14 Jun 2019 07:35:33 +0000 (13:05 +0530)]
i.MX6: nand: add nandbcb command for imx
Writing/updating boot image in nand device is not
straight forward in i.MX6 platform and it requires
boot control block(BCB) to be configured.
It becomes difficult to use uboot 'nand' command to
write BCB since it requires platform specific attributes
need to be taken care of.
It is even difficult to use existing msx-nand.c driver by
incorporating BCB attributes like mxs_dma_desc does
because it requires change in mtd and nand command.
So, cmd_nandbcb implemented in arch/arm/mach-imx
BCB contains two data structures, Firmware Configuration Block(FCB)
and Discovered Bad Block Table(DBBT). FCB has nand timings,
DBBT search area, page address of firmware.
On summary, nandbcb update will
- erase the entire partition
- create BCB by creating 2 FCB/DBBT block followed by
1 FW block based on partition size and erasesize.
- fill FCB/DBBT structures
- write FW/SPL on FW1
- write FCB/DBBT in first 2 blocks
for nand boot, up on reset bootrom look for FCB structure in
first block's if FCB found the nand timings are loaded for
further reads. once FCB read done, DTTB will load and finally
firmware will be loaded which is boot image.
Refer section "NAND Boot" from doc/imx/common/imx6.txt for more usage
information.
Lukasz Majewski [Mon, 24 Jun 2019 13:50:50 +0000 (15:50 +0200)]
clk: sandbox: Add sandbox test code for Common Clock Framework [CCF]
This patch provides code to implement the CCF clock tree in sandbox. It
uses all the introduced primitives; some generic ones are reused, some
sandbox specific were developed.
In that way (after introducing the real CCF tree in sandbox) the recently
added to clk-uclass.c: clk_get_by_id() and clk_get_parent_rate() are tested
in their natural work environment.
Lukasz Majewski [Mon, 24 Jun 2019 13:50:49 +0000 (15:50 +0200)]
clk: sandbox: Adjust clk-mux.c to emulate reading divider value from HW
The generic mux clock code for CCF requires reading the clock multiplexer
value from HW registers. As sandbox by design has readl() as no-op it was
necessary to provide this value in the other way.
The new field in the mux structure (accessible only when sandbox is run)
has been introduced for this purpose.
Lukasz Majewski [Mon, 24 Jun 2019 13:50:48 +0000 (15:50 +0200)]
clk: sandbox: Adjust clk-divider to emulate reading its value from HW
The generic divider clock code for CCF requires reading the divider value
from HW registers. As sandbox by design has readl() as no-op it was
necessary to provide this value in the other way.
The new field in the divider structure (accessible only when sandbox is
run) has been introduced for this purpose.
Lukasz Majewski [Mon, 24 Jun 2019 13:50:47 +0000 (15:50 +0200)]
dts: sandbox: Add 'osc' clock for Common Clock Framework [CCF] testing
This patch adds the 'osc' fixed clock to facilitate the CCF testing in
the sandbox U-Boot. It is a starting point for building CCF hierarchy of
clocks.
Lukasz Majewski [Mon, 24 Jun 2019 13:50:45 +0000 (15:50 +0200)]
clk: Port Linux common clock framework [CCF] for imx6q to U-boot (tag: v5.1.12)
This patch brings the files from Linux kernel (linux-stable/linux-5.1.y
SHA1: 5752b50477da)to provide clocks support as it is used on the Linux
kernel with Common Clock Framework [CCF] setup.
The directory structure has been preserved. The ported code only supports
reading information from PLL, MUX, Divider, etc and enabling/disabling
the clocks USDHCx/ECSPIx depending on used bus. Moreover, it is agnostic
to the alias numbering as the information about the clock is read from the
device tree.
One needs to pay attention to the comments indicating necessary for U-Boot's
driver model changes.
If needed, the code can be extended to support the "set" part of the clock
management.
Lukasz Majewski [Mon, 24 Jun 2019 13:50:44 +0000 (15:50 +0200)]
dm: clk: Define clk_get_by_id() for clk operations
This commit adds the clk_get_by_id() function, which is responsible
for getting the udevice with matching clk->id. Such approach allows
re-usage of inherit DM list relationship for the same class (UCLASS_CLK).
As a result - we don't need any other external list - it is just enough
to look for UCLASS_CLK related udevices.
Signed-off-by: Lukasz Majewski <lukma@denx.de> Reviewed-by: Peng Fan <peng.fan@nxp.com>
Lukasz Majewski [Mon, 24 Jun 2019 13:50:43 +0000 (15:50 +0200)]
dm: clk: Define clk_get_parent_rate() for clk operations
This commit adds the clk_get_parent_rate() function, which is responsible
for getting the rate of parent clock.
Unfortunately, u-boot's DM support for getting parent is different
(the parent relationship is in udevice) than the one in Common Clock
Framework [CCF] in Linux.
To alleviate this problem - the clk_get_parent_rate() function has been
introduced to clk-uclass.c.
Signed-off-by: Lukasz Majewski <lukma@denx.de> Reviewed-by: Peng Fan <peng.fan@nxp.com>
Lukasz Majewski [Mon, 24 Jun 2019 13:50:42 +0000 (15:50 +0200)]
dm: clk: Define clk_get_parent() for clk operations
This commit adds the clk_get_parent() function, which is responsible
for getting the parent's struct clock pointer.
U-Boot's DM support for getting parent is different (the parent
relationship is in udevice) than the one in Common Clock Framework [CCF]
in Linux. To obtain the pointer to struct clk of parent the
pdev->uclass_priv field is read via dev_get_clk_ptr() wrapper.
Signed-off-by: Lukasz Majewski <lukma@denx.de> Reviewed-by: Peng Fan <peng.fan@nxp.com>
Lukasz Majewski [Mon, 24 Jun 2019 13:50:40 +0000 (15:50 +0200)]
clk: Provide struct clk for fixed rate clock (clk_fixed_rate.c)
Up till now the fixed rate clock ('osc') has been added to UCLASS_CLK
without declaring struct clk. As a result it was only accessible by
iterating the udevice's uclass list.
This is a problem for clock code, which operates on pointers to struct
clk (like clk_get_rate()), not udevices.
After this change struct clk is accessible from udevice and udevice from
struct clk.
Signed-off-by: Lukasz Majewski <lukma@denx.de> Reviewed-by: Peng Fan <peng.fan@nxp.com>
Lukasz Majewski [Mon, 24 Jun 2019 13:50:38 +0000 (15:50 +0200)]
clk: Extend struct clk to provide information regarding clock rate
This commit extends the struct clk to provide information regarding the
clock rate.
As a result the clock tree traversal is performed at most once, and further
reads are using the cached value.
Tom Rini [Thu, 18 Jul 2019 15:31:37 +0000 (11:31 -0400)]
Merge branch '2019-07-17-master-imports'
- Various FS/disk related fixes with security implications.
- Proper fix for the pci_ep test.
- Assorted bugfixes
- Some MediaTek updates.
- 'env erase' support.
Removed one of the defconfig(obsoleted) file
and unused CONFIG_MMC_SPI definition to avoid confusion
about if this board using non-DM stuff or not.
uCP1020 is completely DM free board, tested and runs well.
Signed-off-by: Oleksandr Zhadan <oleks@arcturusnetworks.com> Signed-off-by: Michael Durrant <mdurrant@arcturusnetworks.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Some storage devices have multiple hw partitions and both address from
zero, for example eMMC.
However currently block cache invalidation only applies to block
write/erase.
This can cause a problem that data of current hw partition is cached
before switching to another hw partition. And the following read
operation of the latter hw partition will get wrong data when reading
from the addresses that have been cached previously.
To solve this problem, invalidate block cache after a successful
select_hwpart operation.
arm: dts: MediaTek: fix clock order for timer0 node of mt7629.dtsi
The timer0 node has its two clocks written in reversed order. The timer0
is used as the tick timer which causes a problem that the time a delay
function used is 4 times longer.
This patch reverses these two clocks to solve this issue.
Simon Glass [Wed, 10 Jul 2019 17:04:13 +0000 (11:04 -0600)]
chromium: Update docs to clone vboot_reference directly
We don't need a full checkout of Chrome OS to build U-Boot with
Chromium OS verified boot. Update the instructions accordingly and fix a
typo which joins the output directory and defconfig.
Paul Emge [Mon, 8 Jul 2019 23:37:05 +0000 (16:37 -0700)]
CVE-2019-13104: ext4: check for underflow in ext4fs_read_file
in ext4fs_read_file, it is possible for a broken/malicious file
system to cause a memcpy of a negative number of bytes, which
overflows all memory. This patch fixes the issue by checking for
a negative length.
Signed-off-by: Paul Emge <paulemge@forallsecure.com>
Paul Emge [Mon, 8 Jul 2019 23:37:04 +0000 (16:37 -0700)]
CVE-2019-13105: ext4: fix double-free in ext4_cache_read
ext_cache_read doesn't null cache->buf, after freeing, which results
in a later function double-freeing it. This patch fixes
ext_cache_read to call ext_cache_fini instead of free.
Signed-off-by: Paul Emge <paulemge@forallsecure.com>
Paul Emge [Mon, 8 Jul 2019 23:37:03 +0000 (16:37 -0700)]
CVE-2019-13103: disk: stop infinite recursion in DOS Partitions
part_get_info_extended and print_partition_extended can recurse infinitely
while parsing a self-referential filesystem or one with a silly number of
extended partitions. This patch adds a limit to the number of recursive
partitions.
Signed-off-by: Paul Emge <paulemge@forallsecure.com>
arm: qemu: fix failure in flash initialization if booting from TF-A
If U-Boot is loaded and started from TF-A (you need to change
SYS_TEXT_BASE to 0x60000000), it will hang up at flash initialization.
If secure mode is off (default, or -machine virt,secure=off) at qemu,
it will provide dtb with two flash memory banks:
flash@0 {
bank-width = <0x4>;
reg = <0x0 0x0 0x0 0x4000000 0x0 0x4000000 0x0 0x4000000>;
compatible = "cfi-flash";
};
If secure mode is on, on the other hand, qemu provides dtb with 1 bank:
flash@0 {
bank-width = <0x4>;
reg = <0x0 0x4000000 0x0 0x4000000>;
compatible = "cfi-flash";
};
As a result, flash_init()/flash_get_size() will eventually fail.
With this patch applied, relevant CONFIG values are modified.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Currently, CONFIG_TFABOOT is located in armv8/fsl-layerscape Kconfig,
but it will be also useful for other targets if some additional
configuration are necessary.
So move it to arch/arm/Kconfig.
Please note that CONFIG_TFABOOT still depends on
CONFIG_ARCH_SUPPORT_TFABOOT and so the menu won't come up
if any target doesn't need its own customization for TF-A boot.
This will maintain the compatibility.
At the moment mkenvimage has two separate read paths: One to read from
a potential pipe, while dynamically increasing the buffer size, and a
second one using mmap(2), using the input file's size. This is
problematic for two reasons:
- The "pipe" path will be chosen if the input filename is missing or
"-". Any named, but non-regular file will use the other path, which
typically will cause mmap() to fail:
$ mkenvimage -s 256 -o out <(echo "foo=bar")
- There is no reason to have *two* ways of reading a file, since the
"pipe way" will always work, even for regular files.
Fix this (and simplify the code on the way) by always using the method
of dynamically resizing the buffer. The existing distinction between
the two cases will merely be used to use the open() syscall or not.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Andre Przywara [Sun, 30 Jun 2019 01:45:00 +0000 (02:45 +0100)]
tools: mkenvimage: Fix reading from slow pipe
It is perfectly fine for the read(2) syscall to return with less than
the requested number of bytes read (short read, see the "RETURN VALUE"
section of the man page). This typically happens with slow input
(keyboard, network) or with complex pipes.
So far mkenvimage expects the exact number of requested bytes to be
read, assuming an end-of-file condition otherwise. This wrong behaviour
can be easily shown with:
$ (echo "foo=bar"; sleep 1; echo "bar=baz") | mkenvimage -s 256 -o out -
The second line will be missing from the output.
Correct this by checking for any positive, non-zero return value.
This fixes a problem with a complex pipe in one of my scripts, where
the environment consist of two parts.
Signed-off-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Alexander Dahl <ada@thorsis.com>
Frank Wunderlich [Sat, 29 Jun 2019 09:36:20 +0000 (11:36 +0200)]
env: mmc: add erase-function
this adds erase environment for mmc storage
squashed fixes:
- add CONFIG_CMD_ERASEENV
- env: erase redundant offset if defined
- changes mentioned by Simon
- fix whitespaces around errmsg
Suggested-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com> Signed-off-by: Frank Wunderlich <frank-w@public-files.de> Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Frank Wunderlich [Sat, 29 Jun 2019 09:36:19 +0000 (11:36 +0200)]
env: register erase command
this patch adds basic changes for adding a erase-subcommand to env
with this command the environment stored on non-volatile storage written
by saveenv can be cleared.
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
squashed fixes
- start message with "Erasing"
- mark erase-function as optional
- env: separate eraseenv from saveenv
Suggested-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com> Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Marek Vasut [Wed, 26 Jun 2019 22:17:27 +0000 (00:17 +0200)]
common: Fix autocompletion with CONFIG_CMDLINE_PS_SUPPORT
The autocompletion did not work if CONFIG_CMDLINE_PS_SUPPORT was enabled
because U-Boot was comparing the prompt string with CONFIG_SYS_PROMPT .
While this works if CONFIG_CMDLINE_PS_SUPPORT is disabled, this no longer
works if it's enabled because user can override the PS1 . Fix this by
checking prompt string against the current PS1 value.
Signed-off-by: Marek Vasut <marex@denx.de> Cc: Tom Rini <trini@konsulko.com>
Sven Schwermer [Mon, 24 Jun 2019 11:03:34 +0000 (13:03 +0200)]
regulator: Allow enabling GPIO regulator
Drivers need to be able to enable regulators that may be implemented as
GPIO regulators. Example: fsl_esdhc enables the vqmmc supply which is
commonly implemented as a GPIO regulator in order to switch between I/O
voltage levels.
Signed-off-by: Sven Schwermer <sven@svenschwermer.de> Reviewed-by: Lukasz Majewski <lukma@denx.de>
Sven Schwermer [Mon, 24 Jun 2019 11:03:33 +0000 (13:03 +0200)]
regulator: Factor out common enable code
In preparation of being able to enable/disable GPIO regulators, the
code that will be shared among the two kinds to regulators is factored
out into its own source files.
Signed-off-by: Sven Schwermer <sven@svenschwermer.de> Reviewed-by: Lukasz Majewski <lukma@denx.de>
When a crash occurs in thumb mode the crash dump is incorrect. This is due
to the usage of a non-existing configuration variable CONFIG_ARM_THUMB in
the definition of macro thumb_mode(regs).
Use CONFIG_IS_ENABLED(SYS_THUMB_BUILD) to detect that the code has been
compiled for thumb mode. Remove ARM_THUMB from config_whitelist.txt.
With the patch crash dumps indicate thumb mode correctly.
Marek Szyprowski [Fri, 21 Jun 2019 13:35:35 +0000 (15:35 +0200)]
ext4: add support for filesystems without JOURNAL
JOURNAL is optional for EXT4 (and EXT3) filesystems, so add support for
skipping it. This fixes corrupting EXT4 volumes without JOURNAL after
using uboot's 'ext4write' command.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Lukasz Majewski <lukma@denx.de>
Marek Szyprowski [Fri, 21 Jun 2019 13:32:51 +0000 (15:32 +0200)]
ext4: fix calculating inode blkcount for non-512 blocksize filesystems
The block count entry in the EXT4 filesystem disk structures uses
standard 512-bytes units for most of the typical files. The only
exception are HUGE files, which use the filesystem block size, but those
are not supported by uboot's EXT4 implementation anyway. This patch fixes
the EXT4 code to use proper unit count for inode block count. This fixes
errors reported by fsck.ext4 on disks with non-standard (i.e. 4KiB, in
case of new flash drives) PHYSICAL block size after using 'ext4write'
uboot's command.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Lukasz Majewski <lukma@denx.de>
Tom Rini [Thu, 18 Jul 2019 15:30:12 +0000 (11:30 -0400)]
Merge branch '2019-07-17-ci-imports'
This brings in a small update to our Travis-CI config file and
introduces a GitLab CI file. Currently they have the same functionality
and the plan currently is to migrate away from Travis-CI.
Tom Rini [Wed, 17 Jul 2019 21:51:28 +0000 (17:51 -0400)]
gitlab-ci: Split the world build into 4 jobs
To better allow for parallelization of the world build job split things
into 32bit ARM (687 boards), 64bit ARM (215), PowerPC (311 boards) and
everything else (167 boards).
While the 32bit ARM job is heavier than I would like, there is not a
natural split that would reduce it in half or so without requiring the
sort of hard to maintain splits we have to do in Travis CI.
Tom Rini [Wed, 19 Jun 2019 13:25:17 +0000 (09:25 -0400)]
gitlab-ci: Initial conversion of Travis CI build to GitLab CI
Migrate all of the logic in our current .travis.yml file to a GitLab CI
config file. Notable changes are that this will run the jobs on runners
with the "all" tag. The timeout for a job needs to be configured higher
than normal as we no longer split building the world up into a large
number of small jobs but instead perform one big build job. We make use
of stages so that we build and run all of the QEMU + test.py tests first
in order to increase the chance that any problems will be found before
starting the final big build.
Joel Stanley [Thu, 4 Jul 2019 01:35:14 +0000 (11:05 +0930)]
configs: aspeed: Unset CONFIG_MMC
The aspeed board does not have an upstream MMC driver.
As CONFIG_MMC defaults on, the board would fail to build due to the
CONFIG_DM_MMC migration:
===================== WARNING ======================
This board does not use CONFIG_DM_MMC. Please update
the board to use CONFIG_DM_MMC before the v2019.04 release.
Failure to update by the deadline may result in board removal.
See doc/driver-model/MIGRATION.txt for more info.
====================================================
Change the defconfig to disable MMC until a driver is submitted.
configs: am65x_hs_evm: Add support for applying overlays
This will allow for downloading and applying overlays from an MMC/SD
boot media based on the overlay_files ENV variable containing a list
of overlay files.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
configs: am65x_evm: Add support for applying overlays
This will allow for downloading and applying overlays from an MMC/SD
boot media based on the overlay_files ENV variable containing a list
of overlay files.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
board: ti: am654: Use EEPROM-based board detection
The TI AM654x EVM base board and the associated daughtercards have on-
board I2C-based EEPROMs containing board configuration data. Use the
board detection infrastructure introduced earlier to do the following:
1) Parse the AM654x EVM base board EEPROM and populate items like board
name and MAC addresses into the TI common EEPROM data structure
residing in SRAM scratch space
2) Check for presence of daughter card(s) by probing the associated
presence signals via an I2C-based GPIO expander. Then, if such a
card is found, parse the data such as additional Ethernet MAC
addresses from its on-board EEPROM and populate into U-Boot
accordingly
3) Dynamically create an U-Boot ENV variable called overlay_files
containing a list of daugherboard-specific DTB overlays based on
daughercards found.
This patch adds support for the AM654x base board ("AM6-COMPROCEVM")
as well as for the IDK ("AM6-IDKAPPEVM"), OLDI LCD ("OLDI-LCD1EVM")
PCIe/USB3.0 ("SER-PCIEUSBEVM"), 2 Lane PCIe/USB2.0 ("SER-PCIE2LEVM"),
and general purpuse ("AM6-GPAPPEVM") daughtercards.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
ti: common: am6: Add support for setting MAC addresses
The AM654x EVM based on the TI K3 family of SoCs has an updated board
detection EEPROM structure that contains a TLV record of dedicated MAC
addresses rather than a range of MAC addresses as it was used on earlier
platforms such as DRA7. Add a basic function that allows us setting up
Ethernet MAC addresses into the U-Boot environment based on the MAC
address record contained in the common TI EEPROM structure.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
ti: common: am6: Add support for board description EEPROM
The AM654x EVM based on the TI K3 family of SoCs have an updated board
detection EEPROM structure, now comprising variable-sized TLV-type
records, containing a superset of what is already being provided on
earlier platforms such as DRA7. Add basic support for parsing the new
data structures contained on the base board into the common TI EEPROM
structure while also providing infrastructure that can be used later on
to parse data from additional EEPROMs such as the ones that are used on
daughtercards for this platform.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
arm: K3: am654: Map common EEPROM data into SRAM scratch space
The board detection scheme employed on various TI EVMs makes use of
SRAM scratch space to share data read from an on-board EEPROM between
the different bootloading stages. Map the associated definition that's
used to locate this data into the SRAM scratch space we use on AM654x.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
configs: am65x_hs_evm_a53: Increase malloc pool before relocation
The malloc pool used before relocation is getting tight leading to
out of memory errors doing certain DM-related calls. Since we are
running the A53 SPL out of DDR let's just go ahead and bump its size
as used in U-Boot proper as well as SPL (via Kconfig default value)
from 8KB to 32KB.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Acked-by: Andrew F. Davis <afd@ti.com>
configs: am65x_evm_a53: Increase malloc pool before relocation
The malloc pool used before relocation is getting tight leading to
out of memory errors doing certain DM-related calls. Since we are
running the A53 SPL out of DDR let's just go ahead and bump its size
as used in U-Boot proper as well as SPL (via Kconfig default value)
from 8KB to 32KB.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Enable GPIO driver for PCA953X-compatible I2C-based I/O expander
which includes support for the TCA9554/PCA9554-type expander found
on the AM654 EVM base board.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Acked-by: Andrew F. Davis <afd@ti.com>
Enable GPIO driver for PCA953X-compatible I2C-based I/O expander
which includes support for the TCA9554/PCA9554-type expander found
on the AM654 EVM base board.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
The AM654 base board has a TCA9554/PCA9554-type GPIO expander on the
wkup_i2c0 bus at address 0x38 that is used to detect the presence of
daughter cards. Add a respective DTS description of this expander
to enable its use.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
arm: dts: k3-am654-base-board: Enable wkup_i2c0 across all boot stages
To enable the use of an EEPROM-based board detection scheme we need to
be able to access the I2C bus associated with the EEPROMs across all
3 stages of U-Boot: R5 SPL, A53 SPL, and A53 U-Boot (proper). So go
ahead and add/update the wkup_i2c0 peripheral module DTS definitions
and its associated pinmux node accordingly.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
projects / u-boot.git / log