[beagleboard] 4.1 or 4.4 kernel for best stability and feature support on BBB

I recommend you use v4.4.x, as v4.1.x was a big testing platform for
what went into our v4.4.x kernel.

We are still building v4.1.x for users who need it, but a lot of fixes
went into v4.4.x...

For overlays, everything that worked in v4.1.x, works in v4.4.x.

Regards,

Thanks for confirming my suspicion…

To update kernel should I use /opt/scripts/tools/./update_kernel.sh ?

Tried that and it looks it went for the latest 4.6.5

Questions:

  • Can I tell this script to use 4.4.16-bone-rt-r11
  • Is this the best way to update or should I recompile using 4.4.16-bone-rt-r11 and port all my stuff into it?
  • What does the 'is currently unavailable on [rcn-ee.com/repos] means in output below?

Here is the output of the update_kernel.sh

root@arm:/opt/scripts/tools# ./update_kernel.sh
info: checking archive
2016-08-03 17:13:26 URL:https://rcn-ee.com/repos/latest/jessie-armhf/LATEST-bone-rt [92/92] → “LATEST-bone-rt” [1]

Thanks for confirming my suspicion...

To update kernel should I use /opt/scripts/tools/./update_kernel.sh ?

Tried that and it looks it went for the latest 4.6.5

Questions:
- Can I tell this script to use 4.4.16-bone-rt-r11

./update_kernel.sh --lts-4_4

I've updated the script to be more vocal about options:

https://github.com/RobertCNelson/boot-scripts/commit/f79a2f90e3cbffc0c5243e646e728dacf2f51e82

With no cmdline options it defaults to "--stable"...

- Is this the best way to update or should I recompile using
4.4.16-bone-rt-r11 and port all my stuff into it?

- What does the 'is currently unavailable on [rcn-ee.com/repos] means in
output below?

That's just to prevent race conditions, in the past my cable modem
hasn't been the fastest network connection..

It's there now:

http://repos.rcn-ee.net/debian/pool/main/l/linux-upstream/linux-image-4.6.5-bone-rt-r3_1jessie_armhf.deb

Regards,

Thanks Robert.

Was just typing a reply that I found that on on line 200 of the script:

https://github.com/RobertCNelson/boot-scripts/blob/master/tools/update_kernel.sh#L200

Its running now and just completed. reboot shows that it worked. Most appreciated once again!

Why not use apt ? After all APT is the debian way, and we’re using debian . . .

The script uses apt... it just takes work out of selecting which is
the latest of all the kernel branch's..

Regards,

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!

Plug in a serial adapter, then we can see what's happening..

Or just reflash with a newer modern image.

Regards,

U-Boot 2014.10-rc2-00017-ge202aa7-dirty (Aug 25 2016 - 16:36:51)

Watchdog enabled
I2C: ready
DRAM: 512 MiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment

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.

Thanks for your time,
Alex

Alexander,

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.

Thanks,
Alex

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 ).

The USB boot is beside the point. I’m sorry, I didn’t mean to draw any unnecessary attention to it.
I’m just trying to get the kernel to start.