Selecting a bootable kernel in the U-Boot console via a debugging connection

/en/linux/blog/ debianubootcubieboardkerneluart
29/August/2018
authorRentaro
Rentaro

What did the embedded system look like?

Manual kernel selection
Manual kernel selection 595x715
u-boot-kernel-select.png


There is one small CubieBoard 2 next to the small router.
And there is no physical access to them.
A USB-UART is connected to a router controlled by LEDE, the pins of which are connected to CubieBoard2.
Both the router and CubieBoard2 are accessible via ssh.

It was the presence of UART in the assembly that allowed us to raise the fallen CubieBoard2 remotely.

How did it fail?

One day a regular update of the Debian kernel arrives
linux-image-4.9.0-8-armmp-lpae.
After the update the system stops responding.

How is this usually done?

Everything is simple here, you take out the microsd card, and then there is no need to describe it further.

UART, your time has come!

First, connect to the router via ssh, then connect to USB-UART
screen /dev/ttyUSB0 115200
Here is part of the log from a normal kernel boot.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

...
2 USB Device(s) found
Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
2471 bytes read in 169 ms (13.7 KiB/s)
## Executing script at 43100000
Mainline u-boot / new-style environment detected.
4391424 bytes read in 570 ms (7.3 MiB/s)
26547 bytes read in 347 ms (74.2 KiB/s)
18629865 bytes read in 1423 ms (12.5 MiB/s)
Booting Debian 4.19.0-0.bpo.10-armmp-lpae from mmc 0:1...
## Flattened Device Tree blob at 43000000
   Booting using the fdt blob at 0x43000000
   Loading Ramdisk to 48e3b000, end 49fff4e9 ... OK
   Loading Device Tree to 48e31000, end 48e3a7b2 ... OK

Starting kernel ...

root: recovering journal
root: clean, 102306/610800 files, 873002/2441216 blocks
...

Let’s look at the boot process from /boot/boot.scr, and we find the following:

1
2
3
4
5
6
7
8
9
10
11

for pathprefix in ${image_locations}
do
  if test -e ${device} ${partition} ${pathprefix}vmlinuz-${fk_kvers}
  then
    load ${device} ${partition} ${kernel_addr_r} ${pathprefix}vmlinuz-${fk_kvers} \
    && load ${device} ${partition} ${fdt_addr_r} ${pathprefix}${fdtpath} \
    && load ${device} ${partition} ${ramdisk_addr_r} ${pathprefix}initrd.img-${fk_kvers} \
    && echo "Booting Debian ${fk_kvers} from ${device} ${partition}..." \
    && bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}
  fi
done

and here are the same lines, but with variables:

1
2
3
4
5

load mmc 0:1 0x42000000 /boot/vmlinuz-4.9.0-8-armmp-lpae
load mmc 0:1 0x43000000 /boot/dtb-4.9.0-8-armmp-lpae
load mmc 0:1 0x44300000 /boot/initrd.img-4.9.0-8-armmp-lpae
echo "Booting Debian 4.9.0-8-armmp-lpae from mmc 0:1..."
bootz 0x42000000 0x44300000:${filesize} 0x43000000

If the kernel fails to boot you are left in initrd forever.
Reboot, wait for the line Hit any key to stop autoboot, press any key and remain in the U-Boot console.
Clue: in U-Boot there is a help command.
Enter the commands manually, changing the file names to the previous working kernel:

1
2
3
4
5

load mmc 0:1 0x42000000 /boot/vmlinuz-4.9.0-7-armmp-lpae
load mmc 0:1 0x43000000 /boot/dtb-4.9.0-7-armmp-lpae
load mmc 0:1 0x44300000 /boot/initrd.img-4.9.0-7-armmp-lpae
echo "Booting Debian 4.9.0-7-armmp-lpae from mmc 0:1..."
bootz 0x42000000 0x44300000:${filesize} 0x43000000

Starting kernel ...