Creating a bug report/issue
I have searched the existing open and closed issues
Required Information
-
DietPi version | cat /boot/dietpi/.version
G_DIETPI_VERSION_CORE=9
G_DIETPI_VERSION_SUB=8
G_DIETPI_VERSION_RC=0
G_GITBRANCH=‘master’
G_GITOWNER=‘MichaIng’
-
Distro version | echo $G_DISTRO_NAME $G_RASPBIAN
bookworm
-
Kernel version | uname --all
Linux DietPi 6.6.54-current-meson64 #1 SMP PREEMPT Fri Oct 4 14:30:05 UTC 2024 aarch64 GNU/Linux
-
Architecture | dpkg --print-architecture
arm64
-
SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3)
Odroid C4/HC4 (aarch64)
-
Power supply used | (EG: 5V 1A RAVpower)
Original Odroid 5V/4A PS
-
SD card used | (EG: SanDisk ultra)
SanDisk Ultra 16GB
Additional Information (if applicable)
- Can this issue be replicated on a fresh installation of DietPi?
It concerns only fresh installs in the early phase.
← If you sent a “dietpi-bugreport”, please paste the ID here →
5b4f7156-c98b-4b7f-8156-a48d2c374a25 | echo $G_HW_UUID
Steps to reproduce
- Odroid HC4 dies during first boot (no attached hardware, no changes in the 9.8 DietPi image)
with
Task dump for CPU 2:
task:swapper/2 state:R running task stack:0 pid:0 ppid:1 flags:0x0000000a
Call trace:
__switch__to+0x0e4/0x15c
0x0
Time out for waiting the udev queue being empty.
-
SPI boot was with Petitboot 20221228, the latest available from Index of /images/petitboot/odroidhc4
-
When restarted with ‘skip SPI’ button pressed, install runs through.
Also, booted via kexec from SPI, there were some delays of the boot process even before
the task dump.
SPI booted failed twice – once with HDDs attached and changed .ini files, once with default
.ini files and without peripherals.
- After boot ran through (pressed bottom button at startup), it stops the setup process at
Stopping networking.service - Raise network interfaces…
Reboot via Petitboot fails. System runs only when restarted without Petitboot (bottom button).
Expected behaviour
- behaviour analog to Odroid N2+ w/DietPi 9.8: System boots with or without Petitboot, boot process and
dmesg log without issues
Actual behaviour
Extra details
- My target is to have a HC4 which runs without being shaky, so I would be happy if I could completely remove Petitboot. I have no need for its functionality.
What I do need, however, is the ability to warm reboot and that the bottom button doesn’t need to be pressed. Since I have the HC4, this was only possible with Petitboot + Stock Ubuntu. I tried Armbian with their brute-force approach to nuke the SPI, but this made the HC4 just hang on a warm reboot.
I would be happy to recompile upstream uboot and flash it to SPI or whatever, as long as I can warm reboot the HC4 without human assistance.
mqybe @MichaIng has an idea
Maybe some other HC4 owner can chime in and confirm or deny the incompatibility as well. If it’s just me on a wild goose chase, it would be different to the HC4 in general being useless with DietPi 9.8.
Also, I want to reiterate that I would be open to ripping out Petitboot and do whatever it takes to get something better into the SPI.
The thread here started in the right direction, but unfortunately, it died down.
I also agree 100% with @MichaIng 's assessment of Petitboot in the quoted tutorial.
Except that I’m very happy that he spent the time to make Petitboot work at least with the N2+. This is what brought me to DietPi. The Armbian guys just nuke Petitboot and essentially say: Deal with the consequences. This is not what I want.
Ideally, I would like to see just uboot running from SPI, as close to upstream as possible. The ability to boot from USB and SSD and to reboot without interference would be enough.
If you need assistance for test runs etc., I can test for you. I have an M1, N2+ and the HC4 for different environments which all include SPI.
I am the one that create one of those threads. And I have the same problems since a few updates ago, no reboot and no boot from usb/ssd, tested a lot of things with @MichaIng but none worked… Petitboot was always the pain in the a**
The solution was doing some steps after flashing dietpi img but as DietPi wants to be user friendly it was decided to leave it like now.
Hopefully we could get some new approach.
I will stay around.
This sounds extremely interesting.
Care to elaborate more on what these steps were?
I take whatever I can, since it’s next to impossible to get some guidelines.
I don’t really care about user friendliness, even if these steps are fiendishly difficult, I won’t have an issue with them.
Maybe something difficult for early adopters could lead to something user-friendly down the line.
It’s a pity that this already exists.
It’s only a:
dd bs=512 seek=1 conv=notrunc,fsync if=odroid-hc4/u-boot-meson.bin of=/dev/${entire-device-to-be-used}
away.
And since U-Boot for Amlogic devices has an HDMI display driver, not even serial console access is necessary.
Only an HDMI display and USB keyboard are sufficient.
I actually read it, tried it and replied to you there via PN.
The link you gave is virus-ridden and doesn’t let me download, instead wants me to give access for a load of suspicious sites and other shenanigans.
What I asked there in the odroid forum was if you could share this again, if possible via a better option like WeTransfer?
Just to be sure:
- You boot from SD card?
- Booting with MASK key hold works?
- So only petitboot is the issue?
Not sure whether there was a recent update to petitboot that broke something. I’ll get to flash the latest version to my Odroid N2+, which should then have the same issue.
I’ll add the option to dietpi-config to flash U-Boot to SPI like available for Odroid N2 and many RK35xx boards already. Just 3 characters of code.
To answer the questions:
- Yes, I boot from SD card.
- Booting with the MASK key works.
- I think petitboot is the issue because it is just too old for modern kernels.
My suspicion is that kexec breaks if the difference between the kernel which executes kexec and the kernel to be booted is too big.
Also, this is not comparable with the N2+. My own N2+ boots with DietPi and Petitboot without any issue, I am quite happy with it. The petitboot on the N2+ is at least one year younger than on the HC4, this can play a role.
The option in the dietpi-config would be great. This should help already. Also maybe include the latest patch from Armbian which lowers the frequency to make the system more stable and avoid Heisenbugs. Thanks!
1 Like
Looks like this file host service has been degraded.
Try here, but it will not last for a long time.
1 Like
Thanks! It’s now downloaded. I post my experience later.
This is just a regular mainline U-Boot build? Because that is present already:
apt install mtd-utils
source /usr/lib/u-boot/platform_install.sh
write_uboot_platform_mtd "$DIR"
It’s a build based on regular mainline sources, but with a build configuration of how a device firmware in my humble opinion should look like. All supported devices use the same look and feel, but take into account the respective device resources. In addition, it is OS agnostic and consists of only a single binary, which can be used for each MASKROM supported boot device. It just has to be copied into the corresponding place. For SPI Flash location, even a U-Boot console command is provided, because this operation is usually not easy to perform with simple on-board OS tools.
But the best thing to do is to just try my build. All that is needed is an otherwise completely erased microSD card, which only contains the firmware binary in place. If everything works to your satisfaction, you can then move the firmware to the desired location. The OS with a suitable bootmeth can be on any other connected storage device.
I’m definitely testing this, but give me a day or two. My HC4 is just doing what it is intended for, serving as a hard drive copy/maintenance station, and the secure erase of two disks is currently in progress. I don’t want to interrupt this, and it runs for quite some time.
One thing I would like to ask: Does your u-boot-meson.bin permit warm reboots?
There is a discussion of a reboot fix on the Armbian forum by changing some bits of the dtb file. Could this be also the issue and the solution here?
Just writing the current Armbian (24.8.1) u-boot to SPI doesn’t fix the warm reboot issue. I tried.
I thought the reboot issue is just due to the fact that petitboot is loaded on reboot? The reboot issues I am aware of on some Odroids were all solved long ago.
Our (Armbian build system) U-Boot is also a single binary (recent mainline U-Boot always is?) and the kernel provides /dev/mtdblock0 for flashing it directly via dd. The script uses flashcp though, but more as an active decision since it validates the flashed image afterwards. Not sure how U-Boot can not be OS agnostic? It always is, just like the kernel is distro agnostic?
Just saying, it sounds nice, but the Armbian-based builds work just fine as far as I know. Hence I want to clarify that no one should be needed to download and flash any other U-Boot than what our images ship with already. Unless facing particular issues, of course. Since we use an Armbian soft fork in the meantime, however we could quickly implement a fix.
Sometimes I have seen the reboot issue on my OPi5 the last weeks
But that is a different SBC hence different issue/bug then. The Odroids all had a shared reboot issue, but that one was solved.
1 Like
For me it works as expected, but YMMV.
No, with petitboot (and a petitboot-compatible ancient stock distribution), it reboots fine.
But when I clear the SPI flash, the OS can’t warm reboot. It just hangs after the screen goes black in the final shutdown phase. No LED activity, either. I need to cold reboot by pulling the plug and putting it back in again, but that’s a huge annoyance since the HC4 is in another room and I do most things via ssh.
Important: This also happens with the latest Armbian 24.8.1 after I wrote their uboot to SPI flash with armbian-config.
What was the solution you had for Odroid reboot issues? I think this issue is still not solved. In this thread are a couple of people with the same issue, starting March 2024, last entry from September 13.
Your u-boot-meson.bin looks good. Very, very good. It’s like what petitboot wishes it were, but never was. This should be the standard. Best approximation of a amd64 UEFI boot I have seen so far.
My feedback:
- The 2 seconds delay are way too short for exploration. Good for later, but not for the first try. My hardware (wireless keyboard and monitor with aggressive power setting defaults) made this impossible, I needed to fetch a new keyboard and --almost-- a new monitor (managed on the fourth or fifth try).
- The instructions on the odroid forum seem a bit outdated. I stopped the autoboot, but after selecting mmc, I had to wait for this to stop and then enter
mmc dev 1. Did I have to exit first? This is a bit counter-intuitive.
- After selecting mmc dev 0 (for SD card), I got the following:
=> mmc dev 0
switch to partitions #0, OK
mmc0 is current device
=> run mmc-fw-to-sf
MMC read: dev # 0, block # 1, count 4095 . . . 4095 blocks read: OK
jedec_spi_nor spi_flash@0: unrecognized JEDEC id bytes: 00, 00, 00
Failed to initialize SPI flash at 0:0 (error 0)
=>
I tried then with
=> mmc dev 1
MMC Device 1 not found
no mmc device at slot 1
=>
as expected, but at least I tried.
So the one thing I want to try (warm reboot) is not possible, since I can’t get the u-boot-meson.bin into the SPI flash.
Any advice?