New kernel for Nanopi R5S makes SD-card not bootable - SOLVED

[Cabletwister]

Creating a bug report/issue

• I have searched the existing open and closed issues

Required Information

• DietPi version | 9.7.1 master MichaIng
• Distro version | bullseye
• Kernel version | Linux DietPi 5.10.110 #1 SMP Sat Dec 3 CST 2022 aarch64 GNU/Linux
• SBC model | NanoPi R5S/R5C (aarch64) (mine is an R5S)
• Power supply used | big
• SD card used | Sandisk

Additional Information (if applicable)

• Software title | (EG: Nextcloud)
• Was the software title installed freshly or updated/migrated?
• Can this issue be replicated on a fresh installation of DietPi?
  YES - when pulling the latest bookworm image from https://dietpi.com/downloads/images/DietPi_NanoPiR5S-ARMv8-Bookworm.img.xz and flash it to SD, this SD card will not start.

Steps to reproduce

• Use an existing DietPi installation that is successfully starting from SD Card
• Do the update and switch to the new kernel
• Reboot

Expected behaviour

DietPi with new kernel is starting from SD card

Actual behaviour

SD Card is not discovered as bootable, NanoPi starts from MMC or any other system, cannot use SD

Extra details

I have first experienced this when updating a DietPi installation that was some 3-4 months old. As the youngest working DietPi image I had on my machine was March 2023 I had to use this one. I installed it to several SD cards and did an install & update.
=> Whenever I went for the new R5S kernel, I was unable to start from SD afterwards
=> Whenever I kept the old version (selected "Cancel" when asked to switch to new kernel) it works like a charm, boots from SD
=> Whenever I download the latest image and flash to card, it will not start from SD

[MichaIng]

Can you try to keep pressing the MASK key before powering on, until you see some LEDs blinking? The bootloader changed the boot order, AFAIK, so I guess it just boots the eMMC with priority, at least if it contains an image with the original FriendlyELEC bootloader (which was the case with our older images).

[Cabletwister]

SOLVED
So with the old images, if you want to boot them from SD card, just put in the SD card and power
With this image (the new one), if you want to boot from SD-card, you have to press MASK while powering it and keep MASK pressed until the red LED blinks. This does NOT harm your MMC, so if you start it the next time, it simply boots from MMC.

The bis drawback of this version is: Now it is not possible to reboot into DietPi. So if there is just one second of Power-Loss, it will boot to the MMC.

Anyway, this clarified and solved the issue!

[Cabletwister]

SOLVED the problem by

• flashing the latest image to SD
• enter the SD
• press MASK while powerup until the red LED blinks
• do so again for any reboot

[MichaIng]

So the default boot order is bad. IMO it makes sense to boot from movable boot devices with priority, internal ones with less priority, i.e. from SD card, if it is bootable, from eMMC only if no bootable SD card (or USB drive) is present.

I remember there even was an Armbian patch touching this. Maybe we can either remove, change or add a patch to adjust the boot order.

[MichaIng]

Testing this: MichaIng/build@5b888ee
Build is running: https://github.com/MichaIng/DietPi/actions/runs/11059240281

[MichaIng]

Okay in my case it does actually boot from SD card first, without above patch.

@Cabletwister what image is on your eMMC? Those FriendlyELEC R5/R6 SBCs have this weird behaviour, that their boot order depends on whether an image contains a FriendlyELEC vendor bootloader, or mainline U-Boot. So my guess is that the image on your eMMC is an older one, or an official FriendlyELEC image, and is then booted from eMMC with higher priority, than an SD card image with mainline U-Boot. In this case, there is nothing we can change about this, but you could flash mainline U-Boot to the eMMC or a DietPi image.

[Cabletwister]

Yes, the image on the MMC is a vendor-provided image, to be precise it is an SD-to-MMC-FriendlyWRT image.

Yes, it would be great to either have something like the oldfashioned BIOS boot-priority-setting or something like the GRUB we used in the ancient first years of Linux. Or just the plain "removable drives have priority" if this is possible.

As I am very happy with DietPi and more and more unhappy with FriendlyWRT, I am considering to flash DietPi to the MMC, hopefully this would also solve the issue for my case.

If I can help with any R5S related topic, please drop me a note, I can test whatever should be tested.

[MichaIng]

The problem is we have no real effect on this: the hardware/ROM decides about which boot device to use first. And obviously it decides to use the eMMC in this case, loading the bootloader shipped with the FriendlyELEC image. It would need to pick the SD card before our bootloader even had a chance to do further decisions, show a selection menu or such 🤔.

Other SBCs have a jumper to set the boot priority hardware-wise, but the NanoPi R5/R6 ones have a MASK button only, to disable the eMMC temporarily.

[Cabletwister]

The strange thing for me is: This depends on the image loaded to the SD card:

• When I enter an SD card with an old DietPi image, it starts from SD no problems
• When I enter the very same SD card but with the new image, it it not discovered as bootable, so it starts from MMC unless I mask it through the button.

[MichaIng]

As said, essentially it is prioritising to boot a vendor bootloader, if present on and boot device. There was actually a table somewhere on FriendlyELEC wiki, but I cannot find it anymore. However, should be like this:

eMMC	SD card
vendor	!vendor!
!vendor!	mainline
mainline	!vendor!
mainline	!mainline!

And the 2nd is sadly the default case, with some vendor image pre-installed on eMMC and DietPi now using mainline U-Boot.