Jump to content

Javelin

Members
  • Posts

    4
  • Joined

  • Last visited

  1. 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.
  2. 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;
  3. 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.
  4. 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.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines