summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2023-03-30arm: mvebu: Define all options for AXP BOOT_FROM_* macrosPali Rohár1-0/+4
Definitions are according to the MV78460 Hardware Specifications. Signed-off-by: Pali Rohár <pali@kernel.org> Tested-by: Tony Dinh <mibodhi@gmail.com> Tested-by: Martin Rowe <martin.p.rowe@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
2023-03-30arm: mvebu: Define all BOOTROM_ERR_MODE_* macrosPali Rohár1-0/+7
A385 BootROM fills into bits [31:28] of register 0x182d0 tracing value, which represents in which state BootROM currently is. BootROM fills one of the possible values: 0x2 (CPU initialization), 0x3 (UART detection), 0x6 (UART booting), 0x8 (PCI Express booting), 0x9 (parallel or SPI NOR booting), 0xA (parallel or SPI NAND booting), 0xB (SATA booting) and 0xE (SD / eMMC booting). Meaning of these values matches TRACE_* macros from Marvell soc_spec.h file: https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/blob/u-boot-2013.01-armada-18.06/tools/marvell/doimage_mv/soc_spec.h Signed-off-by: Pali Rohár <pali@kernel.org> Tested-by: Tony Dinh <mibodhi@gmail.com> Tested-by: Martin Rowe <martin.p.rowe@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
2023-03-30arm: mvebu: Define all options for A38x BOOT_FROM_* macrosPali Rohár1-4/+7
Disassembling A385 BootROM binary reveal how BootROM interprets strapping pins for Boot Device Mode. All possible options are: 0x00..0x07 -> Parallel NOR 0x08..0x15 -> Parallel NAND 0x16..0x17 -> Parallel NOR 0x18..0x25 -> Parallel NAND 0x26..0x27 -> SPI NAND 0x28..0x29 -> UART xmodem 0x2a..0x2b -> SATA 0x2c..0x2d -> PCI Express 0x2e..0x2f -> Parallel NOR 0x30..0x31 -> SD / eMMC 0x32..0x39 -> SPI NOR 0x3a..0x3c -> Parallel NOR 0x3d..0x3e -> UART debug console 0x3f -> Invalid Note that Boot Device Mode Options in A38x Hardware Specifications is incomplete. Signed-off-by: Pali Rohár <pali@kernel.org> Tested-by: Tony Dinh <mibodhi@gmail.com> Tested-by: Martin Rowe <martin.p.rowe@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
2023-03-30arm: mvebu: Convert BOOT_FROM_* constants to function macrosPali Rohár2-23/+22
This allows to merge BOOT_FROM_MMC and BOOT_FROM_MMC_ALT constants to one macro. And also allows to extend other BOOT_FROM_* macros for other variants. Signed-off-by: Pali Rohár <pali@kernel.org> Tested-by: Tony Dinh <mibodhi@gmail.com> Tested-by: Martin Rowe <martin.p.rowe@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
2023-03-30arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constantPali Rohár2-3/+1
A385 BootROM treats strapping configuration 0x22 as SPI-NAND. So remove incorrect definition 0x22 as SATA. SATA on A385 has configuration 0x2A. Signed-off-by: Pali Rohár <pali@kernel.org> Tested-by: Tony Dinh <mibodhi@gmail.com> Tested-by: Martin Rowe <martin.p.rowe@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
2023-03-30arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f constantPali Rohár2-4/+0
A385 BootROM treats strapping configuration 0x3f as invalid. When booting fails (e.g. because of invalid configuration) then BootROM fallbacks to UART booting. Detecting BootROM fallback to UART booting is implemented in U-Boot since commit 2fd4284051e3 ("ARM: mach-mvebu: handle fall-back to UART boot"). So there is no need to define BOOT_FROM_UART_ALT constant and special handling for it anymore, remove it. This change effectively revers commit f3a88e2ca17a ("arm: mvebu: fix boot from UART on ClearFog Base"). Signed-off-by: Pali Rohár <pali@kernel.org> Tested-by: Tony Dinh <mibodhi@gmail.com> Tested-by: Martin Rowe <martin.p.rowe@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
2023-03-30arm: mvebu: Cleanup get_boot_device() codePali Rohár1-5/+10
Show correct information in debug() output and use correct names for variables. No functional change. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de>
2023-03-30arm: mvebu: clearfog: Detect MMC vs SDHC and fixup fdtMartin Rowe1-0/+1
[upstream of vendor commit 19a96f7c40a8fc1d0a6546ac2418d966e5840a99] The Clearfog devices have only one SDHC device. This is either eMMC if it is populated on the SOM or SDHC if not. The Linux device tree assumes the SDHC case. Detect if the device is an eMMC and fixup the device-tree so it will be detected by Linux. Ported from vendor repo at https://github.com/SolidRun/u-boot Signed-off-by: Martin Rowe <martin.p.rowe@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
2023-03-30arm: mvebu: clearfog: Fix MMC detectionMartin Rowe1-0/+1
A388 Clearfog MMC is either SD Card or eMMC with different behaviour for both. Setting the device to non-removable in the u-boot.dtsi allows both to correctly detect the device. Signed-off-by: Martin Rowe <martin.p.rowe@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
2023-03-29mpc83xx: Remove CONFIG_SYS_GPIO{1/2}_PRELIM and relatedChristophe Leroy1-8/+0
Last use of CONFIG_SYS_GPIO1_PRELIM was removed by commit fae2ea5951 ("ppc: Remove MPC8349EMDS board and ARCH_MPC8349 support"). Last use of CONFIG_SYS_GPIO2_PRELIM was removed even before by commit 6843862342 ("ppc: Remove caddy2 / vme8349 boards") Those two items were removed from whitelist by commit 8cca60a2cb ("Kconfig: Remove some symbols from the whitelist") Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Fixes: fae2ea5951 ("ppc: Remove MPC8349EMDS board and ARCH_MPC8349 support")
2023-03-29mpc83xx: Remove stale CONFIG_SYS_LBLAWBAR{4/5/6/7}_PRELIMChristophe Leroy1-16/+0
Last (incorrect) use of those CONFIG items was removed by commit 9fd9abedcc ("TQM834x: remove defines causing gcc4.4 warnings") Those items are invalid and should have been removed at the same time because lblaw[] has only 4 elements. And they were removed from the whitelist by commit 9c5df7a2a9 ("mpc83xx: Migrate LBLAW_* to Kconfig") Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Fixes: 9fd9abedcc ("TQM834x: remove defines causing gcc4.4 warnings")
2023-03-29arm: mach-k3: introduce generic board detction kconfig optionChristian Gmeiner4-6/+9
For non TI boards it is not possible to enable the do_board_detect() call as TI_I2C_BOARD_DETECT is defined in board/ti/common/Kconfig. I want to use do_board_detect() to dectect boards and properties based on some SPI communication with a FPGA. Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2023-03-29iot2050: Add support for configuring M.2 connectorJan Kiszka4-2/+114
The M.2 slots of the related IOT2050 variant need to be configured according to the plugged cards. This tries to detect the card using the M.2 configuration pins of the B-key slot. If that fails, a U-Boot environment variable can be set to configure manually. This variable is write-permitted also in secure boot mode as it is not able to undermine the integrity of the booted system. The configuration is then applied to mux the serdes and to fix up the device tree passed to or loaded by the bootloader. The fix-ups are coming from device tree overlays that are embedded into the firmware image and there also integrity protected. The OS remains free to load a device tree to which they do not apply: U-Boot will not fail to boot in that case. Based on original patch by Chao Zeng. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
2023-03-29arm: dts: iot2050: Add support for M.2 variantchao zeng2-1/+123
Add support for the M.2 board based on the iot2050 advanced board. The board has two m.2 connectors, one is B-keyed, the other E-keyed. The B-key slot can connect 5G/SSD devices, and E-key can be used for WIFI/BT devices. This variant is covered by PG2 firmware image. Signed-off-by: chao zeng <chao.zeng@siemens.com> [Jan: align DT to kernel, polish wording] Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
2023-03-29arm: dts: iot2050: Optionally embed OTP programming data into imageJan Kiszka1-0/+9
Use external blob otpcmd.bin to replace the 0xff filled OTP programming command block to create a firmware image that provisions the OTP on first boot. This otpcmd.bin is generated from the customer keys using steps described in the meta-iot2050 integration layer for the device. Based on original patch by Baocheng Su. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
2023-03-29arm: dts: iot2050: Allow verifying U-Boot proper by SPLJan Kiszka1-0/+16
Add hashes and configuration signature stubs to prepare verified boot of main U-Boot by SPL. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2023-03-29iot2050: Update firmware layoutJan Kiszka1-22/+8
The latest version of the binary-only firmware parts come in a combined form of FSBL and sysfw containers. This implies some layout changes to the generated firmware image but also makes handling of artifacts much simpler (4 files less). The env locations will not change, just the space reserved for U-Boot will shrink from 4 to 3 MB - still plenty of space left in practice. Adjust configuration and documentation accordingly. Along this change, add a new reservation for update commands of the user-controlled OTP part. A specific userspace tool will fill it, and the FSBL will evaluate it during boot. This reservation will use 64K of the former sysfw section. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
2023-03-29arm: dts: iot2050: Use the auto generator nodes for fdtSu Baocheng1-37/+7
Refactor according to the entry `fit: Entry containing a FIT` of document tools/binman/README.entries. As the generator uses the device tree name for the config description, board_fit_config_name_match requires a small adjustment as well. Signed-off-by: Su Baocheng <baocheng.su@siemens.com> [Jan: re-add now required CONFIG_OF_LIST, update config matching] Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2023-03-29board: siemens: iot2050: Split the build for PG1 and PG2Su Baocheng1-55/+25
Due to different signature keys, the PG1 and the PG2 boards can no longer use the same FSBL (tiboot3). This makes it impossible anyway to maintaine a single flash.bin for both variants, so we can also split the build. A new target is added to indicates the build is for PG1 vs. PG2 boards. Hence now the variants have separated defconfig files. The runtime board_is_sr1() check does make no sense anymore, so remove it and replace with build time check. Documentation is updated accordingly. New binary artifacts are already available via meta-iot2050. Signed-off-by: Su Baocheng <baocheng.su@siemens.com> [Jan: refactor config option into targets, tweak some wordings] Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
2023-03-27Revert "rockchip: Fix early use of bootph props"Tom Rini5-11/+11
While this change is correct for v2023.04 it is not correct for next (where this is right now) nor post-v2023.04. This reverts commit 8653e5d3b745925fced5fa6897c92f4a46ec2757. Signed-off-by: Tom Rini <trini@konsulko.com>
2023-03-27Merge branch 'master' into nextTom Rini45-89/+922
2023-03-27rockchip: Use BOOTSTD_DEFAULTS if not DISTRO_DEFAULTSTom Rini1-0/+1
When we do not enable DISTRO_DEFAULTS (generally, to get distro_bootcmd) we instea do want to imply BOOTSTD_DEFAULTS so that when using bootstd the general distro boot functionality will still work. Signed-off-by: Tom Rini <trini@konsulko.com>
2023-03-27rockchip: Disable DISTRO_DEFAULTS for rk3399 boardsSimon Glass1-1/+1
These board have moved to standard boot but the old 'distro_bootcmd' command is still active. Disable DISTRO_DEFAULTS to fix this. Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Vagrant Cascadian <vagrant@debian.org>
2023-03-27x86: som-db5800-som-6867: Fix up adjustment of CONFIG_TEXT_BASESimon Glass1-1/+1
With recent CONFIG_TEXT_BASE changes, there are inconsistencies between several settings. Adjust CONFIG_SYS_MONITOR_LEN to allow more code space. Move the MRC cache out of the way too. Fixes: e23cae30801f ("x86: som-db5800-som-6867: Adjust CONFIG_TEXT_BASE") Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2023-03-27x86: dfi-bt700: Fix up adjustment of CONFIG_TEXT_BASESimon Glass1-1/+1
With recent CONFIG_TEXT_BASE changes, there are inconsistencies between several settings. Adjust CONFIG_SYS_MONITOR_LEN to allow more code space. Move the MRC cache out of the way too. Fixes: 5d1c8342aeaa ("x86: dfi-bt700: Adjust CONFIG_TEXT_BASE") Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2023-03-27x86: conga-qeval20-qa3-e3845: Fix up adjustment of CONFIG_TEXT_BASESimon Glass1-1/+1
With recent CONFIG_TEXT_BASE changes, there are inconsistencies between several settings. Adjust CONFIG_SYS_MONITOR_LEN to allow more code space. Move the MRC cache out of the way too. Fixes: 388f93f96354 ("x86: conga-qeval20-qa3-e3845: Adjust CONFIG_TEXT_BASE") Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
2023-03-27x86: bayleybay: Fix up adjustment of CONFIG_TEXT_BASESimon Glass1-1/+1
With recent CONFIG_TEXT_BASE changes, there are inconsistencies between several settings. Adjust CONFIG_SYS_MONITOR_LEN to allow more code space. Move the MRC cache out of the way too. Fixes: f38be3086837 ("x86: bayleybay: Adjust CONFIG_TEXT_BASE") Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2023-03-27x86: minnowmax: Fix up adjustment of CONFIG_TEXT_BASESimon Glass1-1/+1
With recent CONFIG_TEXT_BASE changes, there are inconsistencies between several settings. Adjust CONFIG_SYS_MONITOR_LEN to allow more code space. Move the MRC cache out of the way too. Add documentation on how to make this change safely. Fixes: 66e2c665f3b6 ("x86: minnowmax: Adjust CONFIG_TEXT_BASE") Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2023-03-25Merge tag 'efi-next-20230325' of ↵Tom Rini6-43/+104
https://source.denx.de/u-boot/custodians/u-boot-efi into next Pull request for efi-next-20230325 Documenation: * add man-page for efi command UEFI: * Let EFI app call ExitBootServices() before legacy booting kernel * Support zboot and bootm in the EFI app * Let efi command show configuration tables * Support booting a 64-bit kernel from 64-bit EFI app * Allocate device-tree copy from high memory * simplify efi_str_to_u16()
2023-03-25x86: Exit EFI boot services before starting kernelSimon Glass1-0/+18
When running the EFI app, we need to exit boot services before jumping to Linux. At some point it may be possible to jump to Linux and pass on the system table, and: * install the device-tree as configuration table * use LoadImage() to load the kernel image (e.g. from memory) * start the image with StartImage() This should allow the Linux efistub to be used. For now, this is not implemented. Signed-off-by: Simon Glass <sjg@chromium.org>
2023-03-25x86: Support booting a 64-bit kernel from 64-bit U-BootSimon Glass3-16/+36
Add the missing code to handle this. For a 64-bit kernel the entry address is 0x200 bytes after the normal entry. Rename the parameter to boot_linux_kernel() accordingly. Update the comments to indicate that these are addresses, not pointers. Signed-off-by: Simon Glass <sjg@chromium.org>
2023-03-25x86: Add return-value comment to cpu_jump_to_64bit()Simon Glass1-0/+1
This does not mention what it returns. Add the missing documentation. Signed-off-by: Simon Glass <sjg@chromium.org>
2023-03-25x86: Adjust bootparam.h to be more like linuxSimon Glass2-25/+47
This likely came from Linux originally, so update it to match v6.2 more. This has no functional change. Signed-off-by: Simon Glass <sjg@chromium.org>
2023-03-25efi: Set RUN_64BIT correctly for the EFI appSimon Glass1-2/+2
The U-Boot EFI app can run as a 64-bit program, so set the Kconfig correctly in that case. Make sure it doesn't build SPL, since there is no need to switch from 32 to 64 bit when running. Signed-off-by: Simon Glass <sjg@chromium.org>
2023-03-24Merge branch 'rpi-2023.04' of ↵Tom Rini3-1/+74
https://source.denx.de/u-boot/custodians/u-boot-raspberrypi - Fixes for booting newer revs of the SoC in the Raspberry Pi 4 - Propagate some firmware DT properties to the loaded DT - Update the Zero2W upstream DT name
2023-03-24mmc: bcm2835-host: let firmware manage the clock divisorVincent Fazio3-0/+54
Newer firmware can manage the SDCDIV clock divisor register, allowing the divisor to scale with the core as necessary. Leverage this ability if the firmware supports it. Adapted from the following raspberrypi Linux kernel commit: bcm2835-sdhost: Firmware manages the clock divisor https://github.com/raspberrypi/linux/commit/08532d242d7702ae0add95096aa49c5e96e066e2 Signed-off-by: Vincent Fazio <vfazio@xes-inc.com> Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
2023-03-24arm: rpi: fallback to max clock rate for MMC clockVincent Fazio2-1/+20
In rpi-firmware 25e2b597ebfb2495eab4816a276758dcc6ea21f1, the GET_CLOCK_RATE mailbox property was changed to return the last value set by SET_CLOCK_RATE. https://github.com/raspberrypi/firmware/issues/1619#issuecomment-917025502 Due to this change in firmware behavior, bcm2835_get_mmc_clock now returns a clock rate of zero since we do not issue SET_CLOCK_RATE. This results in degraded MMC performance. SET_CLOCK_RATE fixes the clock to a specific value and disables scaling so is not an ideal solution. Instead, fallback to GET_MAX_CLOCK_RATE in bcm2835_get_mmc_clock if GET_CLOCK_RATE returns zero. Signed-off-by: Vincent Fazio <vfazio@xes-inc.com> Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
2023-03-24arm: kirkwood: Move internal registers in arch_very_early_init() functionPali Rohár4-3/+15
Same change as was done for mvebu in commit 5bb2c550b11e ("arm: mvebu: Move internal registers in arch_very_early_init() function") but for kirkwood. Signed-off-by: Pali Rohár <pali@kernel.org> Tested-by: Tony Dinh <mibodhi@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
2023-03-24arm: mvebu: Set common SPI flash default speed and modeTony Dinh1-0/+10
CONFIG_SF_DEFAULT_SPEED is used in SPL SPI to configure and probe the flash device during DM SPI uclass probing process, if the spi-max-frequency is not available in the DTB. Currently the max frequency is not available, because of the probing mechanism in SPI uclass has not been fully updated to DM. The CONFIG_SF_DEFAULT_SPEED is set to 1Mhz if a board defconfig does not specify it. This speed is too slow and result in a few seconds delay while the u-boot image is loaded from flash. Based on a survey of the device tree specifications for MVEBU boards, a sane default value should be 10Mhz. The default of 10Mhz enables an almost instantaneously loading of the u-boot image. Note that this patch depends on this patch series (has been merged to u-boot-marvell/next): https://lists.denx.de/pipermail/u-boot/2023-March/511038.html - RESEND: correct spelling of SF_DEFAULT_MODE Signed-off-by: Tony Dinh <mibodhi@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
2023-03-22spl: Add function prototype for spl_mmc_get_uboot_raw_sectorTom Rini1-0/+1
We did not add a prototype for spl_mmc_get_uboot_raw_sector to include/spl.h before, so add and document one now. Correct the incorrect prototype in board/advantech/imx8mp_rsb3720a1/imx8mp_rsb3720a1.c and ensure that we have spl.h where we define a non-weak spl_mmc_get_uboot_raw_sector as well. Signed-off-by: Tom Rini <trini@konsulko.com>
2023-03-22arm: Correct cpu_reset function prototype on some platformsTom Rini3-3/+6
Some platforms were not including <cpu_func.h> which sets the prototype for reset_cpu, and in turn had it set wrong. Correct these cases. Signed-off-by: Tom Rini <trini@konsulko.com>
2023-03-22arm: mach-k3: am62: move scratch board area to HSM RAMKamlesh Gurudasani1-2/+1
On high security devices, ROM enables firewalls to protect the OCSRAM region access during bootup. Only after TIFS has started (and had time to disable the OCSRAM firewall region) will we have write access to the region. So, move scratch board area to HSM RAM. Signed-off-by: Kamlesh Gurudasani <kamlesh@ti.com>
2023-03-22console: Use flush() before panic and resetTony Dinh1-2/+2
To make sure the panic and the reset messages will go out, console flush() should be used. Sleep periods do not work in early u-boot phase when timer driver is not initialized yet. Reference: https://lists.denx.de/pipermail/u-boot/2023-March/512233.html Signed-off-by: Tony Dinh <mibodhi@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Stefan Roese <sr@denx.de>
2023-03-22Merge tag 'u-boot-amlogic-20230322' of ↵Tom Rini1-0/+8
https://source.denx.de/u-boot/custodians/u-boot-amlogic - odroid-go-ultra: setup PMIC regulators at board init
2023-03-19arm: dts: rockchip: rk3188-radxarock-u-boot: remove timer compatible replacementJohan Jonker1-1/+0
The Rockchip timer driver has been renamed after the fall back compatible. There's no need to replace the timer compatible in rk3188-radxarock-u-boot.dtsi anymore, so remove. Signed-off-by: Johan Jonker <jbx6244@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
2023-03-19Revert "arm64: dts: rk356x-u-boot: Drop combphy1 assigned-clocks/rates"Vasily Khoruzhick1-5/+0
This reverts commit 5bec4b0de7851a254fb4447b3599a60f95550141. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
2023-03-19rockchip: rk3588: Add boot device detectionJonas Karlman1-0/+7
Enable SPL on RK3588 to detect which device it was booted from. Fixes use of same-as-spl in u-boot,spl-boot-order prop. Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
2023-03-19rockchip: rk3568-rock-3a: Sync device tree from linuxJonas Karlman2-9/+262
Running U-Boot from eMMC on a ROCK 3 Model A result in the following: U-Boot SPL 2023.04-rc3 (Mar 11 2023 - 17:24:48 +0000) Trying to boot from MMC1 Card did not respond to voltage select! : -110 spl: mmc init failed with error: -95 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ### The sdhci node is missing in board device tree, sync device tree from linux v6.3-rc1 to fix booting from eMMC. Also disable sdmmc2 and uart1 nodes related to using a WiFi and BT module in the M2 slot. Fixes: b44c54f600ab ("arm64: dts: rockchip: rk3568: Add Radxa ROCK 3 Model A board support") Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
2023-03-19rockchip: rk3568: Fix boot device detectionJonas Karlman2-2/+2
The boot source node path for emmc is using the old sdhci name. Replace with correct mmc name and also add same-as-spl to boot order. Fixes: 0d61f8e5f1c0 ("rockchip: rk3568: add boot device detection") Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
2023-03-19rockchip: Fix early use of bootph propsJonas Karlman5-11/+11
Running U-Boot on a ROCK 3 Model A result in the following: No serial driver found resetting ... no sysreset ### ERROR ### Please RESET the board ### Replace bootph- props with u-boot,dm- props to fix this. Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-29 13:19:01 +0000