Rolling back to old kernel

I am running the following command (that I usually use to update the kernel) to go back to an earlier version for a test.

./update_kernel.sh --kernel v4.1.2-ti-r3

Is the command I am using but I get errors such as

error: [linux-image-v4.1.2-ti-r3] unavailable

Are these still available to download?

Sorry, 4.1.3-ti-r5 is the oldest still in the repo from 2015-07-22,
there where lots of issues with the first couple rounds..

Have you tried: 4.1.13-ti-r33 ?

What issue are you seeing?

Regards,

Seeing the system hang with a 3Mbps UART on the system that is generating a HUGE amount of overrun errors on the port.

Wanted to see if an older 4.1 kernel behaved differently at all.

Not really sure how to debug this at all, the serial debug console locks up completely and the logs are empty when I power off and back on again. I lose network connectivity with the unit too.

Sounds like:

https://github.com/RobertCNelson/ti-linux-kernel/commit/622efc9bbb23861488f06cfa580b31bcaa27fa0d

So please retest with: 4.1.13-ti-r33 ?

Regards,

Hi Robert,

Sorry I missed that the first time. The system is running 4.1.13-ti-r33 but yes it does sound like that very much so!

I am using the bb.org overlay, would I need to do anything different at all?

Lee

Hi Robert,

Sorry I missed that the first time. The system is running 4.1.13-ti-r33 but
yes it does sound like that very much so!

Humm.. it should be fixed with that then..

I am using the bb.org overlay, would I need to do anything different at all?

Wonder if it's the same issue with spi/overlays.. we can't get
dmaengine to work with spi when used as an overlay (1/2).

Does it help if you update your dtb to have the serial ports defined directly?

1: https://github.com/beagleboard/bb.org-overlays/commit/48d33d4d22f284103db83626b343724cf18c578d
2: https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/ti-linux-4.1.y/patches/beaglebone/dts/0009-spi-omap2-mcspi-ti-pio-mode.patch

Regards,

I can certainly give that a go, I can replicate the problem every few hours.

I am using simply loading the default overlay. https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-UART2-00A0.dts

What changes would I make to this? I am happy being able to compile that back into the initram etc.

Here you go:

https://github.com/RobertCNelson/dtb-rebuilder/commit/c7ef581450aa068b8cd6c428655a797f387562d1

git clone https://github.com/RobertCNelson/dtb-rebuilder/

cd dtb-rebuilder/

git checkout origin/4.1-ti -b tmp

make
sudo make install

/boot/uEnv.txt

dtb=am335x-boneblack-ttyS2.dtb

about dtb-rebuilder:

it's regular synced with the 4.1.x-ti:

https://github.com/RobertCNelson/dtb-rebuilder/commits/4.1-ti

r31-r33 was just aufs/config changes so the dtb's are 100% binary..

Regards,

Thanks Robert, really appreciate that and did’t see dtb-rebuilder before.

I will give that a go. Just applied and rebooting.

Can I remove the loading of the cape BB-UART2 as a result of this and will the port change from ttyO2 to ttyS2?

Also is there a way to verify it’s in PIO mode now as well.

Finally, if I do get the lockup, is there any info I can get you at all!!

Lee

Thanks Robert, really appreciate that and did’t see dtb-rebuilder before.

I will give that a go. Just applied and rebooting.

Can I remove the loading of the cape BB-UART2 as a result of this and will
the port change from ttyO2 to ttyS2?

Yeap, you won't need the cape loading.. Don't worry about the
ttyO2/ttyS2, it'll have the same exact name /dev/ttyX that the overlay
did..

PS, kernel/systemd/udev in wheezy/jessie is setup to do a /dev/ttyS
<-> /dev/ttyO linking...

Also is there a way to verify it’s in PIO mode now as well.

Finally, if I do get the lockup, is there any info I can get you at all!!

If we still get a lockup, we should cc/ping these guys:

https://github.com/RobertCNelson/ti-linux-kernel/commit/622efc9bbb23861488f06cfa580b31bcaa27fa0d

Regards,

Hmm ok, so I removed the

cape_enable=bone_capemgr.enable_partno=BB_UART2

and added

dtb=am335x-boneblack-ttyS2.dtb

from/to uEnv and now I have no ttyO2 there. I have verified that am335x-boneblack-ttyS2.dtb is in /boot/dtbs/4.1.13-ti-r33

Understood on the lockup, hopefully it won’t be needed if this works around it!!!

Ah sorry, I realise what I had done! I was using am335x-boneblack-emmc-overlay.dtb already to disable the HDMI as we need to use those pins.

ttyO2 has appeared now like you say which is great so thank you for that. Still seeing overrun errors but hopefully won’t see the hang now.

Can I verify the port is now in PIO mode at all?