In order to boot u-boot in the aspeed machine we need to run at least
qemu 3059c2f5a813 (v4.0.0-1592-g3059c2f5a813), which is not in a
released tag.
This should be changed to v4.1.0 when it is released.
Signed-off-by: Joel Stanley <joel@jms.id.au>
Tests in test/py/tests/test_env.py like this fail without CONFIG_HUSH_PARSER:
=> => printenv test_env_0
## Error: "test_env_0" not defined
=> .=> setenv test_env_0
=> => echo $test_env_0
$test_env_0
=> F
We also want a mac address so the ethernet device works in qemu.
Signed-off-by: Joel Stanley <joel@jms.id.au>
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.
Signed-off-by: Joel Stanley <joel@jms.id.au>
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>
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>
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>
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>
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>
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>
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>
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>
Enable I2C via driver model as well as the associated set of U-Boot
commands to allow us interacting with various I2C slave devices.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Acked-by: Andrew F. Davis <afd@ti.com>
Enable I2C via driver model as well as the associated set of U-Boot
commands to allow us interacting with various I2C slave devices.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
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>
Only U-Boot specifc DT properties or overrides, must be in -u-boot.dtsi.
Pinctrl nodes does not belong here. Now that pinctrl nodes are in kernel
DT, there is no reason to be keep these in -u-boot.dtsi. Move them to
proper places so that it would ease copying DT entries from kernel DT.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
There is no need for to include this header here, so drop it.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
K3 devices have I2C IP that is same as OMAP2+ family. Allow driver to be
compiled for ARCH_K3.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Add instructions for flashing boot images to the eMMC with a
layout of the address where each image needs to be flashed.
Also add instructions to flash filesystem partition in user
partition and boot kernel from the rootfs.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Enable all the relevant configs that enables support for loading
sysfw via MMC.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Use the System Firmware (SYSFW) loader framework to load and start
the SYSFW as part of the AM654 early initialization sequence. While
at it also initialize the WKUP_UART0 pinmux as it is used by SYSFW
to print diagnostic messages.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Switch to using the full malloc scheme in post-relocation SPL to allow
better utilization of available memory for example by allowing memory
to get freed. Initially allocate a 16MB-sized region in DDR starting
at address 0x84000000 for this purpose.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
In order to be able to use more advanced driver functionality which often
relies on having BSS initialized during early boot prior to relocation
several things need to be in place:
1) Memory needs to be available for BSS to use. For this, we locate BSS
at the top of the MCU SRAM area, with the stack starting right below
it,
2) We need to move the initialization of BSS prior to entering
board_init_f(). We will do this with a separate commit by turning on
the respective CONFIG option.
In this commit we also clean up the assignment of the initial SP address
as part of the refactoring, taking into account the pre-decrement post-
increment nature in which the SP is used on ARM.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Introduce a framework that allows loading the System Firmware (SYSFW)
binary as well as the associated configuration data from an image tree
blob named "sysfw.itb" from an FS-based MMC boot media or from an MMC
RAW mode partition or sector.
To simplify the handling of and loading from the different boot media
we tap into the existing U-Boot SPL framework usually used for loading
U-Boot by building on an earlier commit that exposes some of that
functionality.
Note that this initial implementation only supports FS and RAW-based
eMMC/SD card boot.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
The current U-Boot SPL image loader infrastructure is very powerful,
able to initialize and load from a variety of boot media however it
is strongly geared towards loading specific types of images in a very
specific way. To address the need being able to use this infrastructure
to load arbitrary image files go ahead and refactor it as follows:
- Refactor existing spl_mmc_load_image function into superset function,
accepting additional arguments such as filenames and media load offset
(same concept can also be applied toother spl_XXX_load_image functions)
- Extend the loader function to "remember" their peripheral initialization
status so that the init is only done once during the boot process,
- Extend the FIT image loading function to allow skipping the parsing/
processing of the FIT contents (so that this can be done separately
in a more customized fashion)
- Populate the SPL_LOAD_IMAGE_METHOD() list with a trampoline function,
invoking the newly refactored superset functions in a way to maintain
compatibility with the existing behavior
This refactoring initially covers MMC/SD card loading (RAW and FS-based).
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
On some platform we have sufficient memory available early on to allow
setting up and using a basic BSS prior to entering board_init_f(). Doing
so can for example be used to carry state over to board_init_r() without
having to resort to extending U-Boot's global data structure.
To support such scenarios add a Kconfig option called CONFIG_SPL_EARLY_BSS
to allow moving the initialization of BSS prior to entering board_init_f(),
if enabled. Note that using this option usually should go along with using
CONFIG_SPL_SEPARATE_BSS and configuring BSS to be located in memory
actually available prior to board_init_f().
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
We would like to use the driver even without power domains being
specified for cases such as during early boot when the required power
domains have already gotten enabled by the SoC's boot ROM and such
explicit initialization is not needed and possible.
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Add Support for creating a GPT partition for the filesystem in eMMC.
The filesystem is created in the user partition (partition 0).
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Add a platform specific set_control_reg() callback to help switch to
UHS speed modes.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
The HOST_CONTROL2 register is a part of SDHC v3.00 and not just specific
to arasan/zynq controllers. Add the same to sdhci.h.
Also create a common API to set UHS timings in HOST_CONTROL2.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Add support in the driver for handling phy specific registers.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
With changes in the driver requiring phy related properties,
add the same for the SD card node to prevent breaking boot with
the driver update.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
The am654_sdhci driver needs to switch the clock off
before disabling its phy dll and needs to re-enable
the clock before enabling the phy again.
Therefore, make the sdhci_set_clock() function accessible
in the am654_sdhci driver.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Add Support for masking some bits in the capabilities
register of a host controller.
Also remove the redundant readl() into caps1.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
In device nodes with more than one entry in the reg property,
it is sometimes useful to regmap only of the entries. Add an
API regmap_init_mem_index() to facilitate this.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
The host controller works perfectly well without having to add any
quirks. Remove them.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Sync the sdhci0 node from kernel. This changes the compatible that is
required to be there in the driver. Change the same for the SD card node
which is not yet supported in kernel. This also syncs the main_pmx0 node
as a side effect.
Also change the name of the driver to match the compatible in kernel.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
So far USB was not enabled for the Allwinner H6 boards, as the PHY
driver was not ready and the clock gates were missing. Since this is now
fixed, let's add the PHY and the OHCI/EHCI drivers to the build, for
all existing H6 boards.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Corentin Labbe <clabbe.montjoie@gmail.com> # Pine-H64
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
