Stuck on Starting Kernel on a modified BeagleBone Black

General Discussion
1

Hello everyone, thanks for the time you are according me, its a bit making me crazy im on this problem since 2 weeks

According to me everything seems okay, but it doesnt seems to display anything, it just do an infinite loop right here without displaying any error message, my beagle is normally using debian 8.6 image and kernel 4.4 i tried to update it to 6.6.32-ti-arm32-r6 by using the same config file or the default config omap2, it works on a basic beagle using default config but not on this beaglebone which is a bit modified regarding dtb file and uboot. I tried generate a new uboot but i cant make it work, doing a proper make am335x_evm_defconfig, what can solve my problem and can you detect any problem in my uboot logs ?

I have 2 uEnv.txt since the original beagle image is a 8.6 iot, one in /boot/uEnv.txt that says :
uname_r=6.6.32
cmdline = coherent_pool=1M splash video=HDMI-A-1:1024x600MR@60e fbcon=rotate:3 usbcore.authorized_default=0 fsck.mode=auto fsck.repair=yes ima_audit=1 ima_tcb

And the other one is /uEnv.txt at the root of the filesystem that is pretty much the original file from the beagle 8.6 image, i can paste it if you ask me

Here is what a Serial Port connected to my beagle returns me :

U-Boot 2015.10-dirty (Mar 05 2021 - 11:45:45 +0100)

       Watchdog enabled
I2C:   i2c set bus num init all
i2c set bus num 2
i2c_set_bus_num
ready
DRAM:  512 MiB
Reset Source: Global external warm reset has occurred.
Reset Source: Global warm SW reset has occurred.
Reset Source: Power-on reset has occurred.
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment

 mac: 34fc6f 02690
<ethaddr> not set. Validating first E-fuse MAC
<ethaddr> mac to set is valid
debug ti cpsw
cpsw
Hit any key to stop autoboot:  0
gpio: pin 53 (gpio 53) value is 1
select fdt core_tpm2_sa3.dtb
switch to partitions #0, OK
mmc0 is current device
gpio: pin 54 (gpio 54) value is 1
Checking for: /uEnv.txt ...
1154 bytes read in 9 ms (125 KiB/s)
gpio: pin 55 (gpio 55) value is 1
Loaded environment from uEnv.txt
Importing environment from mmc ...
Checking if uenvcmd is set ...
gpio: pin 56 (gpio 56) value is 1
Running uenvcmd ...
535 bytes read in 63 ms (7.8 KiB/s)
debug1: [/boot/vmlinuz-6.6.32] ...
7547208 bytes read in 486 ms (14.8 MiB/s)
debug3: [/boot/initrd.img-6.6.32] ...
3700064 bytes read in 278 ms (12.7 MiB/s)
debug2: [/boot/dtbs/6.6.32/core_tpm2_sa3.dtb] ...
58677 bytes read in 371 ms (154.3 KiB/s)
debug: [console=ttyO2,115200n8 root=/dev/mmcblk0p1 rootfstype=ext4 rootwait coherent_pool=1M splash video=HDMI-A-1:1024x600MR@60e fbcon=rotate:3 usbcore.authorized_default=0 fsck.mode=auto fsck.repair=yes ima_audit=1 ima_tcb] ...
debug: [bootz 0x82000000 0x88080000:387560 0x88000000] ...
Kernel image @ 0x82000000 [ 0x000000 - 0x732948 ]
## Flattened Device Tree blob at 88000000
   Booting using the fdt blob at 0x88000000
   Using Device Tree in place at 88000000, end 88011534

Starting kernel ...
1 Like
2

Hello…as you may well know! I am sort of an okay person to discuss Linux, u-boot, and the kernels at hand.

Other people will tell you hands down that others are more adequate in this build…

Now, from what I remember…

  1. Kernel 4.4.x and Debian 8 is a long time ago in electrical engineering chat from what I can tell.
  2. Things have happened, kernels have changed (for the better and for the worse), and u-boot has changed.
  3. Have you researched line for line what it is exactly you are looking to attain from your boot log?

Also, I remember, not that this entails what you are going through right now, that in that era of Linux is when eMMC and the micro SD Card were not too friendly with one another.

All fun aside here, I had to erase everything from the eMMC or the first so many bytes to boot into the micro SD Card (I think).

That is my two cents for now. I have not gone over your boot log and I will most likely not go over the boot log.

With the two /boot/uEnv.txt files, I am not sure that is possible because they would seemingly overwrite each other on different boots.

So, one day while booting, you would get kernel 4.4.x while other days booting, you might get kernel 6.6.x.

Anyway, with such an older kernel, I would not know where to start.

Do you need the 4.4.x kernel with Debian 8? If so, keep it. If not, sudo blkdiscard /dev/YOUR_PARTITION and be done with it.

I know it is hard to get over. I am still trying but things change and how they change quickly is difficult.

I know! I pop in a BBB to program something and I realize change is not always so bad off in my eyes. The newer boards are booting faster than ever, there is still development around them, and people seem to like them (me included).

Anyway, enough fuss.

It gets complicated and quickly. The command blkdiscard can do things that are not wanted. You will lose access to any partition that you command (I think) with blkdiscard and not have access to unless you do wonders with fstrim…

https://manpages.debian.org/testing/util-linux/blkdiscard.8.en.html

and…

https://man7.org/linux/man-pages/man8/fstrim.8.html

Anyway…I hope you are doing well and can understand that maybe some people have really moved on from Debian 8, kernel 4.4.x and older images. LTS stopped for it.

https://wiki.debian.org/LTS

Even Buster is old news and just lost LTS status.

Seth

P.S. I can try to help but I am not sure exactly what is needed to support non LTS devices. So, can you update/upgrade via apt or apt-get or are you solely trying to make builds for the BBB with kernels, u-boot, and fs’s like Debian (rootfs)?

Dang it, I tried before with this task. I did not do so well. If you decide to listen to me, I may steer you in an opposing direction!

3

Also @anon88318452 ,

I think I can help you build something. Will it work? No clue.

I can do it though. What is your end result? Just a kernel, BBB, and u-boot?

Seth

P.S. I mean…back when I was building like a hooligan on Pepsi Colas, I noticed some changes taking place.

make menuconfig # does not work but does if you replace that command

with...

make ARCH=arm CROSS_COMPILE=/usr/bin/YOUR_TOOLCHAIN

and/or...

make ARCH=arm CROSS_COMPILE=~/YOUR_TOOLCHAIN

and then...like you typed out:

make ARCH=arm CROSS_COMPILE=~/YOUR_TOOLCHAIN distclean
make ARCH=arm CROSS_COMPILE=~/YOUR_TOOLCHAIN am335x_evm_defconfig
make ARCH=arm CROSS_COMPILE=~/YOUR_TOOLCHAIN

But, it is not always so easy because of the changes that have taken place.

Does everyone know exactly what took place and when? Not me! I try to keep up. One man here!

Seth

P.S. Then, u-boot is another idea. Buildroot? Have you tried with Buildroot yet? Yes…okay. It may be easier to listen to Bootlin on Buildroot these days to get a start.

Test and repeat, take notes, and see what works versus what does not, then plunge into working order.

That took me some time. Years. It is not as easy as just commanding the machine at times. Are you using openbeagle.org and/or their kernel? If so, yay! If not, things can get iffy. I will wait for feedback!

I hope the best for you and your endeavors. Hopefully, through yelling and bantering, we can conclude. I will (may) help. It really depends if you keep coming back to chat.

4

ttyS2…

1 Like
5

Thanks for all the answers,

here is what uEnv.txt at the root of the file system look like :

These are needed to be compliant with Angstrom’s 2013.06.20 u-boot.

loadaddr=0x82000000
fdtaddr=0x88000000
rdaddr=0x88080000

initrd_high=0xffffffff
fdt_high=0xffffffff

##These are needed to be compliant with Debian 2014-05-14 u-boot.

loadximage=echo debug1: [/boot/vmlinuz-${uname_r}] … ; load mmc 0:1 ${loadaddr} /boot/vmlinuz-${uname_r}
loadxfdt=echo debug2: [/boot/dtbs/${uname_r}/${board_fdt}.dtb] … ;load mmc 0:1 ${fdtaddr} /boot/dtbs/${uname_r}/${board_fdt}.dtb
loadxrd=echo debug3: [/boot/initrd.img-${uname_r}] … ; load mmc 0:1 ${rdaddr} /boot/initrd.img-${uname_r}; setenv rdsize ${filesize}
loaduEnvtxt=load mmc 0:1 ${loadaddr} /boot/uEnv.txt ; env import -t ${loadaddr} ${filesize};
check_dtb=if test -n ${dtb}; then setenv fdtfile ${dtb};fi;
loadall=run loaduEnvtxt; run check_dtb; run loadximage; run loadxrd; run loadxfdt;

mmcargs=setenv bootargs console=tty1,115200n8 ${optargs} root=/dev/mmcblk0p1 rootfstype=${mmcrootfstype} ${cmdline}

uenvcmd=run loadall; run mmcargs; echo debug: [${bootargs}] … ; echo debug: [bootz ${loadaddr} ${rdaddr}:${rdsize} ${fdtaddr}] … ; bootz ${loadaddr} ${rdaddr}:${rdsize} ${fdtaddr};

6

I replaced ttyO2 with ttyS2 but nothing more came out of the beagle, I would really like your help i’m a bit stuck, thank you for the time you are according me

7

There was a point where the serial devices were labelled ttyOx. It depends on the kernel version you are booting, so worth checking both.

Also as this is a modified board and you have modified the devicetree, without knowing the specifics not that easy to say why your board isn’t working.

Are you enabling more or fewer UARTS ? This might affect the dev numbering of the port.
Is it just the serial console not working ?
Does your board have ethernet ? If so can you ping it ?
Does it have the user leds ? do they flash ?

In other words is the only problem the lack of a serial console.

8

thanks for the answer !

Are you enabling more or fewer UARTS ? This might affect the dev numbering of the port.

i connected a cape to the BBB, i took the config file of the old kernel, and used the same one without modification to generate the new kernel on 6.6.32-ti-arm32-r6 on robert nelson source, also i took the same .dtb file on my old kernel, would it work if i juste keep the same one for my new kernel ?

Is it just the serial console not working ?

the serial console is working on ttyS2 since the serial output is located here on the modified BB on an extended cape, it just lock on starting kernel and reboot every 1 minute showing the same uboot log

Does your board have ethernet ? If so can you ping it ?

My board has ethernet but i cant ping it anymore, no response

Does it have the user leds ? do they flash ?

yes it does have it , they turn on and they just stay static and then all shut down

i saw that beagle bone image in debian 12 started using a directory containing overlays whereas in the debian 8 image it wasnt described the same way no ? i’m not an expert of the BB at all
i really appreciate the time you are according me, ty

9

OK to clarify

You are using a standard BBB with a custom cape ?

You have moved the console UART2 to the cape, rather than the default UART0.

Have you wired up the UART correctly ? Tried swapping RX and TX pins ?

Does the board boot without the cape connected ?

10

You are using a standard BBB with a custom cape ?

it is not a standard BBB it is a modified BBB with a custom cape made by TI, i know its hard to help someone with a customised hardware but i have nowhere to find solution.

Have you wired up the UART correctly ? Tried swapping RX and TX pins ?

Texas instrument did it, the kernel boot on 4.4 but not when i dpkg -i the .deb file that i generated for the new kernel using the old config file, just to be sure can i use again my .dtb file i had on 4.4 or can it cause the problem ?

Does the board boot without the cape connected ?

It also doesnt boot, but with the kernel 4.4 it does

11

Here is more log with printf at the end of bootm.c :

debug2: [/boot/dtbs/6.6.32/core_tpm2_sa3.dtb] …
58677 bytes read in 235 ms (243.2 KiB/s)
debug: [console=ttyO2,115200n8 root=/dev/mmcblk0p1 rootfstype=ext4 rootwait coherent_pool=1M splash video=HDMI-A-1:1024x600MR@60e fbcon=rotate:3 usbcore.authorized_default=0 fsck.mode=auto fsck.repair=yes] …
debug: [bootz 0x82000000 0x88080000:53e66e 0x88000000] …
boot_fn …Kernel image @ 0x82000000 [ 0x000000 - 0xa859b0 ]

Flattened Device Tree blob at 88000000

Booting using the fdt blob at 0x88000000
boot_fn …EDK - boot_fn BOOTM_STATE_OS_PREP Using Device Tree in place at 88000000, end 88011534
BOOTM_STATE_OS_GO boot_selected_os …
Starting kernel …

12

debug: [console=ttyO2,115200n8 root=/dev/mmcblk0p1 rootfstype=ext4 rootwait coherent_pool=1M splash video=HDMI-A-1:1024x600MR@60e fbcon=rotate:3 usbcore.authorized_default=0 fsck.mode=auto fsck.repair=yes] …

For 6.x kernels you need to use ttyS and not ttyO (4.x kernels) as @RobertCNelson said.

I would imagine you can still use the same dtb file. There might be more drivier options in newer kernels that require extra dts file entries. The symlink option is possibly one such example, so there could be others.

If the board is similar enough I would try booting the standard BBB image, with your u-boot which you know works,
As you are getting no kernel output it is hard to say exactly where in the kernel the issue is.

Also don’t know if you have seen it, but there is a problem on the 6.x kernels with some eMMC wearing out and bricking very quickly. https://forum.beagleboard.org/t/possible-emmc-firmware-bug-or-hw-issue-recent-seeed-studio-bbbs-with-6-1-x-kernels/36648?u=benedict.hewson

13

thanks for your answer, yes i changed to ttyS but its still the same problem, board doesnt boot with BBB image sadly and i dont get more logs

also i tried BBB image but the board is somewhat different and doesnt boot with bb image even with adding my uboot to it

we probably dont use anything in the eMMC , everything is in the SD

why dont have any log after the starting kernel, i also tried ttyS2 and nothing came out

14

@RobertCNelson @benedict.hewson Do you have any tips to see more logs in the uboot ? i am a bit stuck

15

try something much newer: Files · v2022.04-bbb.io-am335x-am57xx · BeagleBoard.org / u-boot · GitLab

Regards,

16

the uboot is modified to work with a tpm, and i dont have the knowledge to make these changes again, i already tried to boot from uboot of 2021 but it wont boot since it should detect a tpm before booting do you think the old uboot can stop the kernel from booting ?

here is more log using printf :

debug: [console=ttyS2,115200n8 root=/dev/mmcblk0p1 rootfstype=ext4 rootwait coherent_pool=1M splash video=HDMI-A-1:1024x600MR@60e fbcon=rotate:3 usbcore.authorized_default=0 fsck.mode=auto fsck.repair=yes] …
debug: [bootz 0x82000000 0x88080000:53e66e 0x88000000] …
select boot_fn[0]
boot_fn 00000000 …
Kernel image @ 0x82000000 [ 0x000000 - 0xa859b0 ]

Flattened Device Tree blob at 88000000

Booting using the fdt blob at 0x88000000
select boot_fn[5]
boot_fn 9ff5a225 …
boot_fn BOOTM_STATE_OS_PREP
do_bootm_linux start flag=100 os.type=0
do_bootm_linux BOOTM_STATE_OS_PREP
Using Device Tree in place at 88000000, end 88011534
BOOTM_STATE_OS_GO boot_selected_os …
boot_selected_os call boot_fn=9ff5a225
do_bootm_linux start flag=400 os.type=0
do_bootm_linux BOOTM_STATE_OS_GO | BOOTM_STATE_OS_FAKE_GO
Transferring control to Linux (at address 82000000)…
bootstage_mark start
bootstage_mark stop
announce_and_cleanup start

announce_and_cleanup Starting kernel …

announce_and_cleanup cleanup_before_linux
announce_and_cleanup stop
kernel_entry start r2=88000000

17

okay, time to start a manual bisect… What was the old kernel, and what’s the new?

Regards,

18

the old kernel was 4.4 the new is 6.6.32-ti-arm32-r6, the original image of the bbb was around 8.7 debian iot image i cross compiled it using the same config file, and i have copy past the same dtb file in the new folder, should it work as simply as that ?

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j$(nproc) bindeb-pkg

uboot is loading a tpm and is modified from the original uboot of 2015

19

Yeap, too big of a jump…

If i were in your place, i’d start:

4.4 → 4.19.x ( 4.19.94-ti-r74 · Tags · BeagleBoard.org / Linux · GitLab )

Test and verify for a few weeks, then this upgrade:

4.19.x → 5.10.x: ( 5.10.168-ti-r79 · Tags · BeagleBoard.org / Linux · GitLab )

That’ll get you on the safest most stable kernel…

Regards,

20

thank you i’ll try and i will come back to you