Platforms can overwrite the weak definition of spl_mmc_boot_mode() to
determine where to load U-Boot proper from.
For most of them this is a trivial decision based on Kconfig variables,
but it might be desirable the probe the actual device to answer this
question.
Pass the pointer to the mmc struct to that function, so implementations
can make use of that.
Compile-tested for all users changed.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Stefano Babic <sbabic@denx.de>
Reviewed-by: Ley Foon Tan <ley.foon.tan@inte.com> (for SoCFPGA)
Acked-by: Lokesh Vutla <lokeshvutla@ti.com> (for OMAP and K3)
Reviewed-by: Simon Glass <sjg@chromium.org>
Add support for Kevin, an RK3399-based convertible chromebook that is
very similar to Bob. This patch is mostly based on existing support for
Bob, with only minor changes for Kevin-specific things.
Unlike other Gru boards, coreboot sets Kevin's center logic to 925 mV,
so adjust it here in the dts as well. The rk3399-gru-kevin devicetree
has an unknown event code reference which has to be defined, set it
to the Linux counterpart. The new defconfig is copied from Bob with the
diffconfig:
DEFAULT_DEVICE_TREE "rk3399-gru-bob" -> "rk3399-gru-kevin"
DEFAULT_FDT_FILE "rockchip/rk3399-gru-bob.dtb" -> "rockchip/rk3399-gru-kevin.dtb"
VIDEO_ROCKCHIP_MAX_XRES 1280 -> 2400
VIDEO_ROCKCHIP_MAX_YRES 800 -> 1600
+TARGET_CHROMEBOOK_KEVIN y
With this Kevin can boot from SPI flash to a usable U-Boot prompt on the
display with the keyboard working, but cannot boot into Linux for
unknown reasons.
eMMC starts in a working state but fails to re-init, microSD card works
but at a lower-than-expected speed, USB works but causes a hang on
de-init. There are known workarounds to solve eMMC and USB issues.
Cc: Marty E. Plummer <hanetzer@startmail.com>
Cc: Simon Glass <sjg@chromium.org>
[Alper: commit message, resync config with Bob, update MAINTAINERS,
add to Rockchip doc, add Kconfig help message, set regulator]
Co-developed-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Several architectures had a default board_fit_config_name_match already;
this provides a generic weak version. We default to rejecting all configs.
This will use the FIT's default config, instead of the first config. This
may result in boot failures if there are multiple configurations and the
first config is *not* the default.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Parts of later SPL may need RAM information as well, so do full
dram_init() call, which includes the existing dram probing but also
initializes the ram information in gd.
dram_init() from sdram.c does the following steps:
- uclass_get_device(UCLASS_RAM, ...) like the current code
- ret = ram_get_info(dev, &ram);
- gd->ram_size = ram.size;
CONFIG_SPL_RAM already makes sure that sdram.c gets compiled
and thus no other variant of dram_init() can exist.
So it's the same functionality as before and only adds that the
SPL now aquires knowledge about the amount of available ram,
which it didn't know about before.
Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Apparently speedy was forgotten from this list of veyron devices.
Fixes: 49105fb7ed ("rockchip: add common spl board file")
Signed-off-by: Urja Rannikko <urjaman@gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The function's name is misleading as one might think it is used
generally to select the boot-mode when in reality it is only used by the
MMC driver to find out in what way it should try reading U-Boot Proper
from a device (either using a filesystem, a raw sector/partition, or an
eMMC boot partition).
Rename it to spl_mmc_boot_mode() to make it more obvious what this
function is about.
Link: https://lists.denx.de/pipermail/u-boot/2020-April/405979.html
Signed-off-by: Harald Seiler <hws@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
The core Rockchip spl code contains a default board_fit_config_name_match
implementation doing nothing. Individual boards may want to handle this
differently, so add a __weak atribute to make it possible to override
this function in other places.
Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
At present panic() is in the vsprintf.h header file. That does not seem
like an obvious choice for hang(), even though it relates to panic(). So
let's put hang() in its own header.
Signed-off-by: Simon Glass <sjg@chromium.org>
[trini: Migrate a few more files]
Signed-off-by: Tom Rini <trini@konsulko.com>
The common SPL removed SoC-specific code for RK3399's SPL and in the
process caused the previously-unconditional DRAM initialization in
board_init_f() to only happen when compiling a configuration that does not
support TPL, meaning DRAM never gets initialized if TPL is supported but
disabled.
Fix this by omitting the DRAM init in SPL only when we are configured to
also build a TPL. This fixes custom configurations that have disabled
TPL, and it should also unbreak the "ficus-rk3399", "rock960-rk3399",
and "chromebook_bob" defconfigs, although since I don't have any of
those devices I can't confirm they're broken now.
Fixes: b7abef2ecb ("rockchip: rk3399: Migrate to use common spl board file")
Signed-off-by: Thomas Hebb <tommyhebb@gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The common SPL code reordered the DRAM initialization before
rockchip_stimer_init(), which as far as I can tell causes the RK3399 to
lock up completely.
Fix this issue in the common code by putting the DRAM init back after
timer init. I have only tested this on the RK3399, but it wouldn't make
any sense for the timer init to require DRAM be set up on any system.
Fixes: b7abef2ecb ("rockchip: rk3399: Migrate to use common spl board file")
Signed-off-by: Thomas Hebb <tommyhebb@gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The header file sdram.h is used for rk3288 and similar SoCs, rename it
to make it more understandable.
Signed-off-by: YouMin Chen <cym@rock-chips.com>
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Pass spl_image and bootdev to board_return_bootrom.
i.MX8MN needs the args to let ROM to load images
Cc: Simon Glass <sjg@chromium.org>
Cc: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Cc: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The common spl board file handles board_init_f() in SPL,
and with board_early_init_f() and arch_cpu_init() callback,
other operateion after board_init_f() should go to board specific
spl_board_init().
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
