hangs in uboot boot prompt if dtbs dir is missing

Bug #1458866 reported by Michael Vogt on 2015-05-26
This bug affects 2 people
Affects Status Importance Assigned to Milestone

Bug Description

This is a bit of a low priority bug. For some reason my /boot/uboot/a/ directory lost the dtbs/ subdir. The boot mode is snappy_ab=a and snappy_mode=regular. On a reboot the system now hangs in uboot:
reading uEnv.txt
237 bytes read in 5 ms (45.9 KiB/s)
Loaded environment from uEnv.txt
Importing environment from mmc ...
Running uenvcmd ...
reading snappy-system.txt
1585 bytes read in 8 ms (193.4 KiB/s)
reading a/vmlinuz
6508992 bytes read in 382 ms (16.2 MiB/s)
reading a/initrd.img
5111808 bytes read in 298 ms (16.4 MiB/s)
reading a/dtbs/am335x-boneblack.dtb
** Unable to read file a/dtbs/am335x-boneblack.dtb **
Kernel image @ 0x82000000 [ 0x000000 - 0x6351c0 ]
ERROR: Did not find a cmdline Flattened Device Tree
Could not find a valid device tree

Would be nice if in general on failures like this the bootloader would just try the other partition.

Fwiw, the initrd was also corrupted and it did not fallback cleanly from that too.

Michael Vogt (mvo) on 2015-05-26
description: updated
Michael Vogt (mvo) wrote :

Subscribing Paolo to get the input of a expert :)

Setting to critical for now as the goal is to never run into a situation where the device can not boot, however if this is too rare/difficult feel free to set to "high" instead.

Changed in snappy:
status: New → Triaged
importance: Undecided → Critical
Paolo Pisati (p-pisati) wrote :

Watchdog handling in uboot is really fragile and I had to hack the uboot src code to get this, but here it is:

as soon as you are back to the command prompt, uboot keeps calling watchdog_reset() in the polling loop to read a character from the serial line, making the watchdog useless - if we want to fix this scenario we need to hack the source code and make WATCHDOG_RESET() a NULL function, this way we create a sort of 'one way' mode - once you start uboot, either you get to the point of loading the kernel or the board reset itself - bear in mind that in this case, as soon as you get back to the serial prompt you have 60secs before the board reboot itself, so forget any manual work with this bootloader.

I'm engaging upstream to see if we can get this logic to work in a clean way.

On the other hand i hit another critical scenario when the boot prompts says "must RESET the board to recover", well, in this case the board was trying to boot the new kernel and failed, but the hardware was modified in way that the watchdog is ineffective and the board will never reboot (and the plug needs to be physically pulled).

Paolo Pisati (p-pisati) wrote :

ok, never mind - i was able to create an uboot that forcefully reboots the board, no matter what happens, it's REALLY hackish and you can find both MLO and uboot.img attached to this post to try out

Zygmunt Krynicki (zyga) wrote :

I'm marking this bug as won't fix as it was reported in snapd 15.04 era. Please re-open with updated information if the original issue is still a problem for you.

Changed in snappy:
status: Triaged → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers