nanopi-r6s: u-boot: bump to 2025.01 final, with working UMS and SD -> NVMe -> eMMC boot order #7683
Conversation
… NVMe -> eMMC boot order - also LEDs, networking, more supported compression methods... - copypasta reigns supreme. refactor is coming, just not today - also hack the u-boot dtsi for consistent-with-Linux-mainline-DT mmc/sd numbering - this was previously a separate patch in 2024.10
github-actions
bot
added
size/medium
| function pre_config_uboot_target__r6s_patch_uboot_dtsi_for_sd_emmc_order() { | ||
| display_alert "u-boot for ${BOARD}" "u-boot: add to u-boot dtsi for SD=mmc0 and eMMC=mmc1" "info" | ||
| cat <<- EOD >> arch/arm/dts/rk3588s-nanopi-r6s-u-boot.dtsi | ||
| / { aliases { mmc0 = &sdmmc; mmc1 = &sdhci; }; }; |
There was a problem hiding this comment.
Doesn't Nanopi R6S uboot have mmc0 as sdmmc already?
There was a problem hiding this comment.
I think mmc0 should be sdhci on both Linux and Uboot side, but i suppose it is late to say it since the board is already mainlined
There was a problem hiding this comment.
Indeed. The problem here is that u-boot 2025.01 has devicetree-rebasing from some old DT version, which is half-way reorganized. As I intend to (real soon now) refactor all those hooks spread over a dozen boards into a single "mainline rockchip u-boot" extension, I opted to simply force the torvalds-master aliases on both boards...
| # include/configs/rockchip-common.h | ||
| # -#define BOOT_TARGETS "mmc1 mmc0 nvme scsi usb pxe dhcp spi" | ||
| # +#define BOOT_TARGETS "mmc0 nvme mmc1 scsi usb pxe dhcp spi" | ||
| # On R6S, mmc1 is the eMMC, mmc0 is the SD card slot |
There was a problem hiding this comment.
Maybe USB should have higher priority as well
There was a problem hiding this comment.
Yeah, in the past I've been bumping USB higher up the list, as it is convenient for people who are experimenting (eg flash Armbian and mainline uboot to eMMC, then use a Fedora on USB, etc).
But many have complained that usb start (enumerating all buses) is quite slow and delays normal boot by quite a few seconds.
For the specific case of the R6*, those don't have too many USB ports, and I'm switching the USB3 port to UMS/Gadget/OTG mode (for UMS/RockUSB/etc) so bumping USB up the list to allow booting from USB2 is not worth it, I think.
(When I do the refactor I intend to make it easy to change the order, and enable/disable OTG so it's easy to make a fast USB3-bootable bootloader).
There was a problem hiding this comment.
PS. I'm gonna do at least one more rk356x board (odroid-m1) and one rk3399 board (rockpro64) before any refactoring so I can get the full picture of the complexity of making all those things "generic".
nanopi-r6s: u-boot: bump to 2025.01 final, with working UMS and SD -> NVMe -> eMMC boot order