deelan

Reporting back after way too much time passed. I played around with other distros that used an older version of U-Boot and seemingly did not suffer from the reboot issue, however the reboot issue started coming back sporadically with newer kernels. Having read about pure UHS-I cards causing the issue I decided to buy a new SD card for my Odroid C4 and look at that, the reboot issue disappeared completely even with the 6.0 nightly kernel build. Safe to say I'm moving back to Armbian now having abandoned it previously due to this issue. Old card on the left (Class 10 UHS-I) New card on the right (UHS-I, UHS class 3, A1, V30) Old card does not reboot while new one does.

So after a bit of googling I've came across this: https://lists.denx.de/pipermail/u-boot/2020-December/435196.html Apparently the reboot issue has been documented back in 2020, and there was a simple DTS patch developed and merged into linux. I could confirm that my C4 is running the fixed dts with GPIO_OPEN_DRAIN set on the tflash_vdd regulator. However I obviously still experience the issue. What I want to try is applying some of the changes to the armbian kernel as Hardkernel did in theirs to fix the reboot problem (https://github.com/hardkernel/linux/commit/84628497332a5cd2154c92436ec86fad900fe0af). I don't know what your stance on doing hacky patches like this is, but I still want to try it. Unfortunately I can't build a kernel. It errors out even though I'm building without making any changes at all. I'm building in a VM on latest Ubuntu Hirsute server. I don't see an error, probably because it gets lots in all of the parallel make threads running.

I did that and it shows the same behaviour. There actually is a vital difference in the boot process as I've just noticed. The Odroid HC4 has an internal 16MB flash as seen in the bottom of the block diagram While the C4 lacks that flash and replaces that with the eMMC slot. https://wiki.odroid.com/odroid-hc4/software/boot_sequence shos that the HC4 has Odroid's Petitboot living on the flash. I'm not quite sure why you are only seeing U-Boot logs on your HC4 (does armbian somehow replace petitboot on the spi?) So well, for now I'm not too sure what to make out of all of this, I can certainly try hooking up to serial and see if I can trace any kind of U-boot activity, but I don't understand why the stock image reboots fine all the time but running apt upgrade or switching to nightly (which contains a kernel update) messes things up so much. As your log shows U-boot has successfully started up but it can't start the SD card. This is most likely a problem with the SD card not reacting well to a soft reboot, using wrong voltage levels and this could be fixable with the use of a different SD card or what's also been on my mind. To try and see wether theres any kind of SoC function or MMC kernel function to properly reset the SD-card before rebooting. Another thing to add would be that ArchDroid has rebooted fine for me so it might be worth to consult with their devs about the best way to handle rebooting Amlogic SoCs.

Hi there! I just got my hands on a brand new Odroid C4. I flashed Armbian Bullseye (tried Buster too as Bullseye is marked unstable) onto an SD card. The Issue I'm now facing is, after any sort of kernel update the board will not properly soft reboot anymore. I can restart the freshly installed system (which I generated the ix link with) as many times as I want using /sbin/reboot, but one apt upgrade later the board hangs in limbo when I issue a soft reboot. I can see the system itself shutting down, the blue light stopping to heartbeat, and then nothing happens anymore, until I replug power, then the board boots up fine. I have tried to run nand-sata-install as described on the C4's board page (If you face issues with rebooting run this as root) but it does not help, and I'm not even sure whether it even flashes a new U-Boot at all. Obviously, I have trouble using the board as a server like this, as I'd have to come home and replug it if I ever need to reboot so hopefully this can get fixed Should anyone require further data, I can always provide that.