I have an BeagleBone that is running 3.8.13-bone79.
I update the kernel using ./update-kernel.sh --lts-4_4
The old /etc/kernel/postinst.d/zz-uenv_txt fails to update /boot/uEnv.txt,
so I manually update the file to "uname=4.4.19-bone13"
Then I reboot.
D2 goes on for a few seconds (I guess during the bootloader),
and then D3/D4/D5 come on for a second,
and then all the lights shut off...I'm assuming this is essentially a power down.
No messages or anything on the serial debug port.
Can you offer any advice? I've replicated this a couple times. Have no idea what to do next!
Net: not set. Validating first E-fuse MAC
cpsw, usb_ether
Hit any key to stop autoboot: 0
gpio: pin 53 (gpio 53) value is 1
Booting from usb …
(Re)start USB…
USB0: Port not available.
USB error: all controllers failed lowlevel init
USB is stopped. Please issue ‘usb start’ first.
gpio: pin 56 (gpio 56) value is 0
gpio: pin 55 (gpio 55) value is 0
gpio: pin 54 (gpio 54) value is 0
Card did not respond to voltage select!
Card did not respond to voltage select!
gpio: pin 56 (gpio 56) value is 0
gpio: pin 55 (gpio 55) value is 0
gpio: pin 54 (gpio 54) value is 0
switch to partitions #0, OK
mmc1(part 0) is current device
gpio: pin 54 (gpio 54) value is 1
SD/MMC found on device 1
Checking for: /uEnv.txt …
Checking for: /boot.scr …
Checking for: /boot/boot.scr …
Checking for: /boot/uEnv.txt …
gpio: pin 55 (gpio 55) value is 1
932 bytes read in 14 ms (64.5 KiB/s)
Loaded environment from /boot/uEnv.txt
Checking if uname_r is set in /boot/uEnv.txt…
gpio: pin 56 (gpio 56) value is 1
Running uname_boot …
loading /boot/vmlinuz-4.4.19-bone13 …
7269608 bytes read in 415 ms (16.7 MiB/s)
loading /boot/dtbs/4.4.19-bone13/am335x-boneblack.dtb …
55834 bytes read in 38 ms (1.4 MiB/s)
loading /boot/initrd.img-4.4.19-bone13 …
7498211 bytes read in 432 ms (16.6 MiB/s)
debug: [console=ttyO0 splash plymouth.ignore-serial-consoles fbcon=rotate:2 ${optargs} capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN capemgr.enable_partno=BB-UART4,BB-BONE-LCD4-01.
debug: [bootz 0x82000000 0x88080000:7269e3 0x88000000] …
Kernel image @ 0x82000000 [ 0x000000 - 0x6eece8 ]
Flattened Device Tree blob at 88000000
Booting using the fdt blob at 0x88000000
Loading Ramdisk to 8f8d9000, end 8ffff9e3 … OK
Loading Device Tree to 8f8c8000, end 8f8d8a19 … OK
Starting kernel …
And then it shutsdown.
We are using a custom bootloader that’s pretty old. It was only modified to allow for a boot from USB,
which explains some of the messages at the top.
Maybe some of the kernel options are no longer supported?
I guess I should just try a new image, but I’m just curious if you see anything obvious from these logs.
Are you just loading the rootfs and kernel from USB ? If this is the case you should not need a custom
first or second stage bootloader. Granted I have not done this myself since 3.8.x kernels, but It should just work, Unless uboot has changed in this regard. Don’t see why it should have though.
Nothing is loaded from USB in this particular situation, because nothing is connected to USB. I was just pointing out that there is a custom bootloader that is designed to check for a bootable USB and boot from it if it is there. It looks like newer bootloaders support this, but at the time, it wasn’t supported.
The bootloader in this case seems to perform it’s task correctly, it’s just that the kernel seems unhappy, (4.4.19-bone13). I think my next step is to try getting rid of some of the kernel options, and see if that helps. If that fails, I will try a few other kernel versions. And if that fails, I’ll switch to a new image per Robert’s suggestion.
It looks like newer bootloaders support this, but at the time, it wasn’t supported.
At the time when ? USB boot has been possible since the Beaglebone white. But I digress, it depends on what exactly you mean by “boot”. If you mean loading the kernel and rootfs from USB. Then yes that is possible. If you mean bootloaders from USB too . . . that’s a bit more problematic. But there was a successful GSoC project that did just that( I believe ).