Javelin

Thanks.

There must be some level of confusion because I did submit a fix for the C4/HC4 reboot problems that had been reported for years. I probably should have sent it directly to you.

I've submitted fixes to DietPi for certain boards because it seems once they become unsupported here they no longer receive bug fixes. I know the lead guy (Michealng) has made attempts to share patches. Is there a particular process for submitting patches for Armbian?

Thanks to g4751 for doing the tests for Odroid-HC4. The tests for the Odroid-C2 were performed by myself. Tests were performed on Armbian 24.08 Official releases. Fix is to add a section to the DTB to enable a recently (last year) added kernel driver "meson64-reboot" that is an updated version of the "odroid-reboot" in older kernels. For Odroid-C2: - save your existing DTB - use DTC to convert DTB->DTS - modify the DTS with the code below - use DTC to convert DTS->DTB - reboot (will fail because new DTB not loaded yet) - POR (will now load the new DTB) - log-in - reboot should now work. For Odroid-HC4: - save your existing DTB - use DTC to convert DTB->DTS - modify the DTS with the code below - use DTC to convert DTS->DTB - reboot (will fail because new DTB not loaded yet) - POR (will now load the new DTB) - log-in - reboot should now work. Notes: - As far as I know, only the Odroid -C4 has an Armbian patch to do the above automatically for each release. - For others, updates may overwrite the DTB and you'll need to perform this fix again. In theory, DTB changes are fairly rare.

Check your messages, g4715.

Agree. If we have a solution we'll post a thread.

Could you show the complete DTS for "Armbian_21.02.4_Odroidhc4_buster_current_5.10.27"?

Choosing the XC-I card won't increase the transfer speed on an HC4. Does the soft-reset work with the HC-I cards?

1) It would be good if you could reload an earlier version of Armbian (incorporating the fixes for gpios = <0x44 0x06 0x06> and then with gpios = <0x44 0x06 0x03>) until the soft-reset works. 2) Using a second computer with a terminal program you could capture a text version of the boot log. If you're not comfortable with that then nvm.

I'll have to do a deep dive to see what's going wrong. In the meantime it would be good if you could capture the boot sequence rather than photograph it. Also, where are you getting Armbian 24.8.4? From here: https://www.armbian.com/odroid-hc4/ ?

Try this: gpios = <0x44 0x06 0x03>;

gpios = <0x44 0x06 0x06>; HC4 has a different pin assignment for the TF_IO and a simpler circuit but the control logic is identical. The 0x06 should work fine.

You'd need to use a USB serial (TTL) board and connect the serial console connector on the board, then use Putty as a terminal and capture there. Unfortunately I don't have an eMMC, also this kind of storage boots slightly differently and these low-level changes would probably need to be done differently.

I'll download your OS and give it a try to see if I can reproduce. - this is off an sdcard? - a better log would be great - to be sure, when your board doesn't reboot you would get this continuously? bl31 reb▒GXBB:BL1:08dafd:0a8993;FEAT:EDFC318C;POC:3;RCY:0;EMMC:800;NAND:81;SD:800;USB:8;LOOP:1;EMMC:800;NAND:81;SD:800;USB:8;LOOP:2;EMMC:800;NAND:81;SD:800;USB:8;LOOP:3;EMMC:800;NAND:81;SD:800;USB:8;LOOP:4;EMMC:800;NAND:81;SD:800;USB:8;GXBB:BL1:08dafd:0a8993;FEAT:EDFC318C;POC:3;RCY:0;EMMC:800;NAND:81;SD:0;READ:0;CHK:0;

EDIT: After discussion with a few users, to avoid the issue of having this modification wiped out by a future DTB update and create the unfortunate scenario where the /boot/armbianEnv.txt requests to load a DTB which no longer exists, it's a lot simpler to overwrite the original DTB thus keeping the naming identical. If the DTB gets overwritten by an update then the reboot functionality may just revert to the no-reboot behavior until the fix is re-applied to the newer DTB. The problem lies in the SDCARD signals not being in the right state for a reboot. To solve this we will de-compile the DTB in /boot/dtb/amlogic/meson-gxbb-odroidc2.dtb to create a source version (DTS), modify it, and re-generate the new DTB with the same name. The board will need to be re-started to load-in the new DTB after which the following reboots should be automatic. 1) Back-Up everything - if the DTB is somehow not at the right place or the 1 character editing goings wrong there's probably a way to recover from the u-boot console but I haven't explored that. 2) Go To: /boot/dtb/amlogic ls -al (you will see your meson-gxbb-odroidc2.dtb which is hardcoded in the bootloader as the DTB to load) 3) Convert to a source file by doing: dtc -I dtb -O dts -o meson-gxbb-odroidc2.dts meson-gxbb-odroidc2.dtb (you will now have a new DT Source file meson-gxbb-odroidc2.dts) 4) Edit: vi meson-gxbb-odroidc2.dts find the entry TF_IO look for the line gpios = <0x38 0x03 0x00>; the hex number in red is to be changed from 0x00 to 0x06 (what this does is set the SDCARD in a mode to be ready to boot by allowing the resistor pull-down to enable the VDDIO Regulator to go to 3.3V which is the proper boot voltage) save, exit 5) Return the DTS file to a new DTB file (which is the only format accepted by the bootloader). We will copy the original DTB to another name and overwrite the original: cp meson-gxbb-odroidc2.dtb meson-gxbb-odroidc2-ORIGINAL.dtb dtc -O dtb -o meson-gxbb-odroidc2.dtb meson-gxbb-odroidc2.dts many warnings will be emitted, they can be safely ignored 6) No changes need be performed to /boot/armbianEnv.txt (ie. the 'fdtfile=' directive) as the DTB file with the expected naming will be loaded except now it has the TF_IO mod. 7) Now you will reboot - THIS WILL SHUTDOWN BUT WILL NOT REBOOT AUTOMATICALLY BECAUSE THE NEW DTB IS NOT ACTIVE YET. 8 ) Do a Power Reset to bring-up the board and load the new DTB. 9) Now if you do a reboot you will finally get a proper reboot sequence.

The proposed solution here (https://github.com/armbian/build/pull/4824) basically performs a power-reset of the SDCARD in the final moments in order to prepare for the bootloader's (Uboot) restart. What puzzles me is that the kernel has a Watchdog feature which seems to operating fine as witnessed by the console log "watchdog: watchdog0: watchdog did not stop!" meaning that the watchdog driver has been told to disregard attempts to disable it (which is fine in the context that the watchdog is being used to reset the cpu). The problem is, the watchdog never times-out because, i presume, something is still "kicking the dog" (there seems to be a worker thread tasked for this purpose). As a test I "brutally" caused a watchdog timeout (watchdog_dev.c: watchdog_release()) by: 1) disabling interrupts 2) setting watchdog timeout to 2 secs 3) going into infinite loop The board now reboots fine and reliably but clearly i've skipped the notification handler mechanism that is meant to be used in the "odroid-reboot.c" solution. So I guess my question is, are reboots meant to be an elegant hand-off from kernel to uboot, or is the watchdog supposed to be the means to get all registers/pin to their POR state ready for a cold boot? I'm new here so didn't know where to post, let me know the preferred place or whether it's not appropriate.