Otherwise non-ChromeOS samsung devices, like the odroid boards, are
stuck in a bootloop if CONFIG_CROS_EC is not enabled:
<...>
MMC: SAMSUNG SDHCI: 2, EXYNOS DWMMC: 0
Loading Environment from MMC... *** Warning - bad CRC, using default environment
cros-ec communications failure -96
Please reset with Power+Refresh
Cannot init cros-ec device
resetting ...
Issue started after commit e44d7e73fe ("dm: core: Switch
uclass_*_device_err to use uclass_*_device_check").
Signed-off-by: Henrik Grimler <henrik@grimler.se>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Minkyu Kang <mk7.kang@samsung.com>
This reverts commit a034ec06ff.
Commit 4a3ea75de4 ("Revert "mmc: sdhci: set to INT_DATA_END when
there are data"") reverted the alternative fix that was added for
Exynos 4 devices, causing an error when trying to boot from an sdcard:
<...>
Loading Environment from MMC... sdhci_send_command: Timeout for status update!
mmc fail to send stop cmd
<...>
Re-add the quirk to allow booting from sdcards again.
Signed-off-by: Henrik Grimler <henrik@grimler.se>
Make it clear that this is the SPL option to avoid potential confusion
when the description for CONFIG_SPL_VIDEO is the same as that for
CONFIG_VIDEO.
Signed-off-by: John Keeping <john@metanate.com>
flash_get_size() will get the flash size from the device itself and go
through all erase regions to read protection status. However, the device
mappable region (eg: devicetree reg property) might be lower than the
device full size which means that the above cycle will result in a data
bus exception. This change fixes it by reading the 'addr_size' during
probe() and also use that as one possible upper limit.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
- Assorted bootstd fixes and cleanups. This should fix problems with
Debian, and make script-based distributions work when BOOTMETH_DISTRO
is enabled now (as BOOTMETH_DISTRO was renamed and then reintroduced).
We cannot be sure what bootmeth a distro will need to use. Add a new
BOOTMETH_DISTRO option which collects these together. Select this from
BOOTSTD_DEFAULTS so that it is clear what is needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
[trini: Make BOOTMETH_EFILOADER depend on EFI_LOADER, select if EFI_LOADER]
Signed-off-by: Tom Rini <trini@konsulko.com>
We use the terms 'distro' to mean extlinux but they are not really the
same. 'Distro' could refer to any method of booting a distribution,
whereas extlinux is a particular method.
Also we sometimes use syslinux, but it is better to use the same term in
all cases.
Rename distro to syslinux and also update bootstd uses of syslinux to use
extlinux instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
In a few cases the error handling is not quite right. Make sure we
return the actual error in distro_efi_read_bootflow_file() rather than
-EINVAL. Return -IO when a file cannot be read. Also show the error name
if available.
This does not change operation, but does make it easier to diagnose
problems.
Signed-off-by: Simon Glass <sjg@chromium.org>
The patch to relax flag requirements was not accepted[1], so we still have
to have separate bootcommands depending on CMD_BOOTFLOW_FULL.
The previous attempt at this did not work, since it used the wrong name
for the options.
Fix this and change the message to mention BOOTSTD_FULL since this affects
not just the flags, but all functionality, so is more likely what the user
wants.
Drop the useless condition on CMD_BOOTFLOW_FULL while we are here.
[1] https://patchwork.ozlabs.org/project/uboot/patch/20230329071655.1959513-2-sjg@chromium.org/
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: a91492b6e9 ("bootstd: Provide a default command")
Armbian uses a script which needs the HUSH parser. It is likely that
other distros will do the same. Enable it by default, just in case.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Jonas Karlman <jonas@kwiboo.se>
This causes crashes on some boards, e.g. rockpro64. In any case, we
should not do it.
Check the usb_started flag to avoid this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Jonas Karlman <jonas@kwiboo.se>
Tested-by: Tom Rini <trini@konsulko.com>
This should be declared in a header file so that type-checking works
correctly.
Add a single declaration to usb.h and remove the others.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Vasut <marex@denx.de>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
If there is no partition numbered 1, we decide that there are no
partitions at all. That may not be correct, since at least one Debian
installed has just a single partition numbered 2.
Continue searching up to partition 3, just in case.
Signed-off-by: Simon Glass <sjg@chromium.org>
As a starting point, list all currently supported Renesas boards.
For the RZ/N1 board, add details about booting and flashing.
Signed-off-by: Ralph Siemsen <ralph.siemsen@linaro.org>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Renesas RZ/N1 devices contain BootROM code that loads a custom SPKG
image from QSPI, NAND or USB DFU. Support this format in mkimage tool.
SPKGs can optionally be signed, however creation of signed SPKG is not
currently supported.
Example of how to use it:
tools/mkimage -n board/schneider/rzn1-snarc/spkgimage.cfg \
-T spkgimage -a 0x20040000 -e 0x20040000 \
-d u-boot.bin u-boot.bin.spkg
The config file (spkgimage.cfg in this example) contains additional
parameters such as NAND ECC settings.
Signed-off-by: Ralph Siemsen <ralph.siemsen@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add support for Schneider Electric RZ/N1D and RZ/N1S boards, which
are based on the Reneasas RZ/N1 SoC devices.
The intention is to support both boards using a single defconfig, and to
handle the differences at runtime.
Signed-off-by: Ralph Siemsen <ralph.siemsen@linaro.org>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The RZ/N1 is a family of SoC devices from Renesas, featuring:
* ARM Cortex-A7 CPU (single/dual core) and/or Cortex-M3
* Integrated SRAM up to 6MB
* Integrated gigabit ethernet switch
* Optional DDR2/3 controller
* I2C, SPI, UART, NAND, QSPI, SDIO, USB, CAN, RTC, LCD
Add basic support for this family, modeled on the existing RZA1.
Signed-off-by: Ralph Siemsen <ralph.siemsen@linaro.org>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
This is taken directly from Linux kernel 6.3
(commit 457391b0380335d5e9a5babdec90ac53928b23b4)
Signed-off-by: Ralph Siemsen <ralph.siemsen@linaro.org>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Driver for Cadence EDAC DDR controller, as found in the Renesas RZ/N1.
Signed-off-by: Ralph Siemsen <ralph.siemsen@linaro.org>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Pinctrl/pinconf driver for Renesas RZ/N1 (R906G032) SoC.
This is quite rudimentary right now, and only supports applying a
default pin configuration as specified by the device tree.
Signed-off-by: Ralph Siemsen <ralph.siemsen@linaro.org>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Clock driver for the Renesas RZ/N1 SoC family. This is based on
Linux kernel 6.2.y drivers/clk/renesas/r9a06g032-clocks.c as found in
commit 02693e11611e ("clk: renesas: r9a06g032: Repair grave increment error"),
with the following additional patch series applied:
https://lore.kernel.org/linux-renesas-soc/20230301215520.828455-1-ralph.siemsen@linaro.org/
Notable difference: this version avoids allocating a 'struct clk'
for each clock source, as this is problematic before relocation.
Instead, it uses the same approach as existing Renesas R-Car Gen2/3
clock drivers, using a temporary structure filled on-the-fly.
Signed-off-by: Ralph Siemsen <ralph.siemsen@linaro.org>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add new CONFIG_CLK_RCAR to control compilation of shared code for R-Car
clock drivers (renesas-cpg-mssr.c). Enable this for R-Car Gen2 and 3.
This is necessary so that CONFIG_CLK_RENESAS can be enabled, allowing
recursion into the drivers/clk/reneasas directory, without bringing in
the R-Car support code. The support code contains platform specific
access (TMU_BASE) which is not needed on other Renesas devices such as
RZ/N1.
Signed-off-by: Ralph Siemsen <ralph.siemsen@linaro.org>
Reviewed-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Commit 2564fce7ee ("sunxi: move Cortex SMPEN setting into start.S")
added SPL_ARMV7_SET_CORTEX_SMPEN to enable setting SMP bit. For
platforms not using SPL boot, add the corresponding non-SPL config,
so that CONFIG_IS_ENABLED(ARMV7_SET_CORTEX_SMPEN) works as expected.
Signed-off-by: Ralph Siemsen <ralph.siemsen@linaro.org>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Move the TPL up a little to make room for the refcode binary blob. Also
increase the pre-relocation memory to make space for recent additions.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
These are not used in TPL so disable the drivers to save space.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This copies the cpu_call64() function to memory address and then jumps to
it. This seems to work correctly even when called from SPL, which is
running from SPI flash.
Drop the copy as it is not needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
We don't need to commit the SPI-flash MTRR change immediately, since it is
now done in the board_init_f_r(). Also this causes chromebook_link64 to
hang, presumably since we are still running from CAR (Cache-as-RAM) in
SPL. Coral handles this OK, perhaps since it is running from a different
memory area, but it has no effect on Coral anyway.
Drop the extra mtrr_commit() in the SPL implementation.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This function is used by U-Boot proper. It does not set up MTRRs when SPL
is enabled, but we do want this done when it is called from SPL. In fact
it is confusing to use the same function from SPL, since there are quite
a few conditions there.
All init_cache_f_r() really does is commit the MTRRs and set up the cache.
Do this in the SPL's version of this function instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Use the binman symbols for this, to avoid hard-coding the value. We could
use CONFIG_X86_OFFSET_U_BOOT for the address, but it seems better to
obtain the offset and size through the same mechanism.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Probing LPC can cause PCI enumeration to take place, which significantly
increases pre-relocation memory usage. Also, LPC is somtimes enabled
directly by SPL.
Adjust the logic to probe the LPC only after relocation. This allows
chromebook_link64 to start up without a much larger
CONFIG_SYS_MALLOC_F_LEN value.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Show the area of memory cleared for BSS, when debugging is enabled.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
SPL printf() does not normally support %#x so just use %x instead. Hex is
expected in U-Boot anyway.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
For now, just enable the fast-but-large string functions in 32-boot
U-Boot proper only. Avoid using them in SPL. We cannot use then in 64-bit
builds since we only have 32-bit assembly.
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
The debug UART is already set up in SPL, so there is no need to do
anything here. We must provide the (empty) function though.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This adds a lot of code so that it cannot be built with the binary
blobs. It is not used on this board. Drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The bd82x6x_get_gpio_base() does not work if the LPC is not set up.
Probe it early to avoid this problem.
In chromebook_link64 this problem shows up as an inability to read
the GPIO straps for the memory type.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The 'tiny' SPI nor functions have the same name as their big brothers,
which can be confusing. Use different names so it is clear which
version is in the image.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
With tiny SPI flash the erasesize is 0 which can cause a divide-by-zero
error. Check for this and return a proper error instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Allow symbol writing in these cases so that U-Boot can find the position
and size of U-Boot at runtime.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The original function was only called once, before relocation. The new
one is called again after relocation. This was not the intent of the
original call. Fix this by renaming and updating the calling logic.
With this, chromebook_link64 makes it through SPL.
Fixes: 7fe32b3442 ("event: Convert arch_cpu_init_dm() to use events")
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This is useful when looking for tables in memory. Enable it for coreboot.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Enable support for NVMe storage devices. Update the driver to enable the
bus master bit, since coreboot does not do that automatically.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
U-Boot sets up devices ready for use, but coreboot does not. Enable this
so that NVMe works OK from coreboot.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Sometimes coreboot adds new tags that U-Boot does not know about. These
are silently ignored, but it is useful to at least know what we are
missing.
Add a way to collect this information. For Brya it shows:
Unimpl. 38 41 37 34 42 40
These are:
LB_TAG_PLATFORM_BLOB_VERSION
LB_TAG_ACPI_CNVS
LB_TAG_FMAP
LB_TAG_VBOOT_WORKBUF
LB_TAG_TYPE_C_INFO
LB_TAG_BOARD_CONFIG
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Turn these options on to make it easier to debug things.
Also enable dhrystone so we can get some measure of performance.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Enable this so that PCI devices can be used correctly without needing
to do a manual scan.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
