Odroid HC4 cannot install or boot DietPi 9.8 with Petitboot active

Troubleshooting
21

Not just UEFI boot but also: extlinux (extlinux.conf), legacy script (boot.src), PXE and DHCP

To explore, blindly press and hold a key from the beginning. This will drop you off at the U-Boot console from the start. From there, the boot menu can be started with e.g. “=> menu 120”, which then gives you two minutes to press any key to cancel the countdown. Then you have all the time in the world to choose the desired entry.

This is the selection of UEFI bootmeth for the mmc device and should not be selected if you want to run console commands :wink:
Either the entry “U-Boot console” or the ESC key should have been chosen.

Looks like the SFC can’t identify your SPI for some reason. But let’s put this issue on hold for now. There are other methods to transfer the firmware to the SPI. For example, you can use the same method you use with the Armbian firmware to transfer the binary to offset 0 at the SPI.

To test this, it is not necessary to transfer the firmware to the SPI. Running the firmware from microSD is sufficient. To do this, either the SPI must be erased or the device is forced to boot from microSD like a cold start.

22

At least with this wireless keyboard, there is no key to press at start since the wireless connection also initializes. There is no working keyboard until then! But getting a different keyboard was an easy task, so no issues here.

True, but there’s no way to know this when you see the menu and nothing else. Without some README or explanation, it’s blind guesswork. Also, there was no entry 'U-Boot console" for me. I would have chosen it since it’s self-explanatory. The only thing besides the specific boot options was ‘Exit’.

Which method? Could you just give a one-liner with the command?

I already spent close to an hour digging around in the Armbian scripts, trying to find a way before I read your post. I was hoping to find such a command there. No luck.

Hardkernel wants to write a full image to the SD card for SPI flash. I looked there as well, but there’s just no way to make sense of their spiboot.img within the spiupdate-xxxxxxxx image and if that can be substituted by your custom uboot or if this needs more support around it.

It’s not that easy if you don’t know how!

I tested it this way, because I couldn’t write it to the SPI (see above). But this doesn’t help me with the warm reboot issue. With an empty SPI, it doesn’t run. It stops before anything is loaded. The only way is really to skip SPI with the MASK button, but then any uboot boots.

23

If peripherals aren’t fast enough, the firmware can’t do anything useful about it, because waiting for the slowest ones at the expense of faster is not an optimal option.

Now that you say it, I dimly remember a discussion regarding this one-day. But since this is native mainline U-Boot functionality, I pay little attention to it. “U-boot console” is just one possible state that can be reached here, and they thought (Menu) “Exit” would be more appropriate. But as you can see, not necessarily the better choice :wink:

I don’t know exactly how the SPI is exposed in your distribution, but with MichaIng’s information from his post above, it’s simply:

dd bs=512 conv=notrunc,fsync if=odroid-hc4/u-boot-meson.bin of=/dev/mtdblock0

This is just the reason why I prefer a self-contained solution.

24

Now that’s dead simple. <forehead slap> I thought there is some special wizardry involved when writing to the flash instead of the SD card.

BUT: I don’t have a /dev/mtdblock0. ls /dev/mtd* turns up empty. Neither with or without MASK button pressed. Do I need to expose the flash somehow to the system or do I need to start from scratch with Hardkernel’s petitboot?

25

Sure, the kernel used must have built the appropriate drivers and the flash must be wired correctly in the DTB.
Maybe everything is available, and the flash cannot be initiated by the kernel, just like in the firmware transfer attempt.
What I also find strange is the fact that with empty SPI flash it does not automatically fall back to microSD boot.
How do you proceed to get the SPI flash empty?

26

To make sure that everything works, I rewrite petitboot with the stock spibootupdate-xxxxxxxx (insert SD card with this on it) and then empty the flash from there with

# flash_eraseall /dev/mtd0
# flash_eraseall /dev/mtd1
# flash_eraseall /dev/mtd2
# flash_eraseall /dev/mtd3
27

Do you have some flashcp command there, to copy the u-boot-meson.bin to /dev/mtd0 there?

28

Doubtful. There’s pb-update, but this specifically updates petitboot over the internet. It contains an ancient uboot, so I could try with uboot commands, but I don’t know if this would work. And there’s still the issue with the three 00 bytes which are not recognized by uboot’s write command.

29

Does pb-update happen to be a shell script so we can see what’s executed?

Can you post the output of lsmod from that system?

30

First attempt:

I have no idea. I need to mount one of Hardkernel’s images to find out. And their images just contain ODROIDBIOS.BIN, petitboot.cfg and spiboot.img. The latter has no discernible format with fdisk -lu spiboot.img and is most likely a direct copy of the SPI flash.

I have no knowledge about this format and cannot proceed further.

Next try:

This spiupdate-xxxxxxxx image, written to SD card, updates the SPI flash on the HC4 upon powerup with this card.

Message is ‘spiboot.img is found, SPI flash memory will be updated!!’

Then, when I execute pb-update the SPI flash gets updated from tobetter’s webserver with a later spiboot.img. This happens in three steps:

  • updating U-boot
  • updating Boot logo
  • updating Firmware

followed by a reboot.

pb-update is just a shim which contains the URL from where to fetch the latest spiboot.img and then starts the real logic with the updater in /etc/spiupdate. I have attached both files.
pb-update.txt (1006 Bytes)
spiupdate.txt (2,8 KB)

Petitboot is a very small linux distribution based on the first stock vendor kernel 4.9. So not everything in there might be applicable.

Regarding the Armbian image which I wanted to use to erase the SPI flash:

I have attached the lsmod output as a text file: modules_20241028.txt (3,2 KB)

This image is at Armbian 24.8.4 after some updates. For whatever reason, sudo armbian-config → ‘Toggle hardware configuration’ has no entry anymore for the HC4. I am sure that just a few days ago before the update, there was an entry and I could enable SPI access there.

Maybe that’s the reason why the /dev/mtb* is not populated?

I’ll try again with the Armbian image 24.8.1 from their website. But now, I do have petitboot again – also with pb-update, I got an update to 20220317, which is older than what they have on the website. But this is temporary anyway until I can boot DietPi.

Update:

With Armbian 24.8.1, I do have the /dev/mtd0, /dev/mtd0ro and /dev/mtdblock0 files. If the flashing doesn’t work from this image, I would think maybe I should use petitboot for this.

The easiest would probably be to have your u-boot-meson.bin together with whatever the flash needs to contain in an image and update from petitboot by renaming this image to spiboot.img.

What do you think?

31

Look what spiflash_update() is doing:

So, running these commands manually and replacing u-boot.bin with u-boot-meson.bin should be what you’re looking for in this environment.

I don’t see any SPI related modules in your provided lsmod log which are loaded.
In the mainline DTS, SPI flash support is wired out-of-the-box.
So, if the driver isn’t compiled as a build-in, at least spi-meson-spifc should be loaded automatically.
With “modprobe spi-nor” /dev/mtd* should then become available and “modprobe mtdblock” should give /dev/mtdblock*.
In the first step, it is therefore important to make sure that the spi-meson-spifc driver is operational.

32

Yes, this was helpful. I used this from Armbian 24.8.1 and I could also erase the SPI flash from there with your quoted commands and successfully write your u-boot to SPI flash.

I have confirmed several times that with your u-boot config, a reboot works with Armbian (and should work with DietPi)!

@MichaIng: This u-boot config really well thought-out and should be standard u-boot in DietPi and elsewhere. Only thing missing would be an update option from within, but that’s easy with the write to SPI configuration.

@usual-user: You should put this in some public repo, together with a bit of documention. This is much too good and deserves wider recognition.

Thanks a lot for your help!

33

Can you please run

=> sf probe

in the U-Boot console of the firmware running now from SPI flash to see if the SPI flash still can’t be identified?

Since all of it are native mainline U-Boot functionalities, and the code originates in the mainline U-Boot git repository, there isn’t much that would be available in an additional repository.
If you want documentation, you should use the available U-Boot documentation.
It’s best to start here, because that’s the main feature goal of my build.
My contribution is just how I configure the build and apply in-flight patches as early bird access to future features. I willingly share the resulting binaries with anyone interested.

34 
=> sf probe
SF: Detected xt25f128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB

It seems to be detected. Not too sure about the 16 MiB since Hardkernel claims it has only 8 MiB.

You are too modest here. You put all this together in seamless way with sensible options, feedback to the screen of the running options etc.

The setup alone is worth a writeup. The generic stuff in the documentation helps no one who wants to have a good experience. It’s like comparing Linux from Scratch with DietPi.

Yours is the only bootloader so far which can solve the warm reboot issue and work with recent kernels. That’s a huge plus.

I have loaned out my N2+ and have to get it back first, but I am going to put this on the N2+ and the M1 as well and see if it works there with all functionality, including reboots.

Next step is running this u-boot on the HC4 with DietPi and a Hardkernel Ubuntu to see if all are compatible.

EDIT: The new Hardkernel Ubuntu 24.04 is not compatible ootb. u-boot can’t find the system. It has the two partitions with boot and system. Any idea how to fix this?

If you want feedback on how it works, let me know. But it would be best not to clutter this thread with it.

35

OK, so running mmc-fw-to-sf should also be functional and able to copy over whatever code resides in the firmware area of the selected source storage.

The information represents the JEDEC ID read from the flash. Either it is a fake chip that presents a fake ID, or there is a corresponding chip installed.
A visual inspection of the chip markings can bring clarity if necessary.

Everyone has a different opinion about what a good experience is. This is also the reason why there are all the configuration options, so that everyone can assemble it according to their style. The default configurations in U-Boot for different devices reflect this. The look and feel is different for each device, although it is built from the same sources and can have the same generic features.
I’m just trying, taking into account the given device resources, to uniformize this according to my ideas.
If you want to get an impression of it, you can just use my build and use it as a inspiration if a modified build is desired.

No, it’s more like comparing what options they use in .config to build their kernels. And you will hardly find a detailed description there of which option was used and why and how to use the resulting feature.

I didn’t do anything special in this regard, I just used current mainline sources to build the firmware. Everyone should be able to do the same, as all the necessary ingredients are publicly available.

For the M1 you should note that the functionality can only be used via the serial console, as no HDMI driver is available for rk35xx SoCs in mainline U-Boot so far.

Images with mainline-compliant bootflows only require the native image on a storage device connected to the device on any interface (USB, eMMC, microSD, SATA, …).
If multiple OS images are attached concurrently, only “=> bootstd scan -l” should be necessary to find the bootmeth and select the bootflow to boot.

If I’m not mistaken, Hardkernel images can only booted via Petitboot out-of-the-box.
For images with proprietary bootflows, such as Hardkernel images that depend on petitboot properties, you have to replace the bootflow.
I would compose an extlinux.conf and drop it in. The most complex thing about it is the extraction of the kernel command line from the proprietary bootflow. But if you have access to a running system, a “cat /proc/cmdline” is sufficient

If you’re interested in a 24.10 release build, let me know and I upload it for you.
I recently created it in preparation for my planned 25.01 preview build. It is basically a consolidation in which all preview patches that landed have been obsolated.

36

I assume that this firmware area would be the root of the partition, so I could use this command just by putting a new u-boot-meson.bin there from the OS, restart to u-boot, select the device and then use mmc-fw-to-sf?

There are experiences where a majority of users agree upon that they are pleasant. Think Apple. This is one example. What you put together is one step above the rest.

This uniformization is what is badly needed in the ARM arena.

Yes, I will use your build, don’t know about building my own, though. There’s only 24 hours in the day, and so many things to do…

Yours works, the others don’t work as well. Putting together something is more than the sum of its parts.

Good reminder, thanks. I do have a UART adapter for the M1, but this is significantly more effort. This is the one good aspect of petitboot.

Good point, I’ll do just that. This should be enough guidance, I guess.

Yes, please! I would be interested. Where is the place where you usually post these things? Here on DietPi, at the Odroid forum, or elsewhere?

37

Nope, MASKROM does not support partition layouts, it addresses raw devices with absolute addresses.
Hence

dd bs=512 seek=1 conv=notrunc,fsync if=u-boot-meson.bin of=/dev/${entire-device-to-be-used}

for amlogic SoCs and

dd bs=512 seek=64 conv=notrunc,fsync if=u-boot-rockchip.bin of=/dev/${entire-device-to-be-used}

for rockchip SoCs.

Correct.

But it’s just common UNIX system administrator work.

That doesn’t exist in the x86 architecture world either, or do you know two motherboard manufacturers whose BIOS look and feel is identical.

The reason why I share my build on request for those interested.

But what does it help if it can’t boot my OS of choice.

If there are any questions, I can try to help. Maybe this thread offers some insights.
But it was a losing battle, you can’t teach old dogs new tricks.

Most times on request. With all the different devices, it is difficult to find a central location.
I was asked to do so in the Odroid forum, but it doesn’t scale there for just two devices (N2+ and M1).
The plan was to deliver updates regularly, but with the little interest and only insignificant changes in relation to Odroid devices, I have refrained from doing so so far.

Since my previous long-term file hoster has obviously become unusable, I have attached this 24.10 release build in this post.
odroid-firmware-24.10.tgz.txt (3.2 MB)

38

The 24.10 doesn’t work for me. Won’t find the SD card and insists to PXE boot.

39

I’d like to see the entire serial console log of the boot attempt, can you please provide it?

If no valid bootmeth can be found, this is to be expected. Finally, you will be dropped off at the U-Boot console to perform further actions.

40

This unit doesn’t have a serial console; I need to find a way.

Response will be delayed since I need to use the device for my hard drive erasure and testing, which blocks it for a long time (hours up to a day or more).