Problem of migrating from kernel overlays to uboot overlay #212
Comments
No, that statement is incorrect.. U-Boot just "reports" it is disabled and recommends for you to enable it.. In your /boot/uEnv.txt just make sure you have these set.. and it'll boot the same way as before u-boot overlays... Yeah, your going to have to post the problem overlay, i can't help you with just that information.. Regards, |
Is it possible to put multiple customized customize there? I have six DT. Thanks! |
|
@BrentCC no... that's not how it works. For u-boot overlays we start with a base ".dtb" this usually comes from the kernel tree. For the beaglebone black this would be: Then for u-boot overlays you list the "overlays" you'd like to apply on top of those.. Which would be found under /lib/firmware/ and set via: Pre u-boot overlays, you'd just boot: Then in your case, you'd load these via 'slots'.. /lib/firmware/am335x-bonegreen-overlay-ni2c2.dtbo With u-boot overlays, the "load by slot" is done by u-boot instead of by the kernel.. Regards, |
|
Here's another example to explain it: (with just 2 of your random overlays..) U-Boot overlay's: U-Boot Load: am335x-boneblack.dtb Linux Overlay: U-Boot Load: am335x-boneblack.dtb See, we just "moved" where the device overlay load happens.. and best of all, since we do it u-boot, you don't have a random kernel "runtime" issues.. Regards, |
|
Hi Robert Thanks for the reply! It looks clearer to me.
Where can I find the path of this file? so I can modify it. I have a another question about correctly using bb.org-overlays to make the dtbo file. Thanks again! |
|
@BrentCC the repo with the 4.19.94-ti device tree's can be found here: https://github.com/beagleboard/BeagleBoard-DeviceTrees just use the Makefile to build and install your *.dtb Regards, |
|
@RobertCNelson However, I couldn't boot up afterwards. The boot up log is attached below. |
I have no idea what that would do.. you already have "uname_r=4.19.94-ti-r59" defined, so it'll auto pre-pend the path: "/boot/dtbs/4.19.94-ti-r59/"... So just use: Second: Disables all uboot_overlays_addr*= So if you want to use: uboot_overlays_addr*= Edit (looked at log) Yeap, it "gave" up finding your "am335x-bonegreen-overlay-ni2c2.dtb"... Hence the double "/boot/boot".. Just use: Regards, |
|
Hi @RobertCNelson But I run into another error that stops me from booting. Next step, I will try And add uboot_overlay_addrX |
|
@BrentCC do you have both microSD/eMMC defined in your custom am335x-bonegreen-overlay-ni2c2.dtb ? Waiting for /dev/mmcblk1p1 usually means it's waiting for eMMC. Since i don't have access to your your am335x-bonegreen-overlay-ni2c2.dtb, you'll need to look at it to see if you have the eMMC enabled... Regards, |
|
Hi, @RobertCNelson
No, I only have eMMC to boot up. I flashed the image into eMMC through SDcard. I followed the guide here. BBG works perfectly before I used the custom kernel. I upload am335x-bonegreen-overlay-ni2c2.dts here. In addition, I also tried to enable uboot overlays as below. However, maybe there is a conflict in i/o definition.... |
If we look at that file: Only microSD is enabled, thus your eMMC is disabled.. you need to pass What was your old kernel?
You need to disable pin's your overlay uses.. That's this section: Regards, |
|
PS, this is a bug: I'll work on that it, it should not have swapped over... |
|
Hi @RobertCNelson
Yes, you are right! Originally, the system was running on SD card. After too many read/write, I found out that some I/O on SD card were dead. I wasn't sure if those dead I/O caused the problem I had, so I decided to move the system to eMMC.
I didn't record the exact version, but I know it's an old one from 2017.
Yesterday, I contacted the original developer. He said the sniffer cape needs nearly every possible pin on the beaglebone to be configured as a GPIO to function properly, and more pins are available for this when booting off of the SD card. (eMMC mode reserves some pins for itself). Thanks! |
|
This time I tried to boot up the system from SD card and it seemed working fine. But I found out that service cannot be initialized since |
|
Kernel overlays don't exist post 4.14.x (slots file), so in 4.19.x you need to run u-boot overlays.. If you want kernel overlays just run: Kernel overlays are un-supported so good luck! Regards, |
|
Hi Robert Thanks! |
|
TI moved to 4.19.x after 4.14.108: if you aren't relying on the TI PRU patch-set, then use the bone channel.. Which will pull in 4.14.215-bone44.. Why 215 vs 222 -> https://mirrors.edge.kernel.org/pub/linux/kernel/projects/rt/4.14/ So when the RT patch get's bumped i'll rebuild the old 4.14.x branch.. Regards, |
Hi,
I have packet sniffing device that consists of BBG and a cape(sniffer)
The device was running with an old image from 2017, and I updated it to the latest image.
However after the update, I couldn't initialize BBG any more. After some debugging, the issue is related to the overlays.
The device was configured with kernel overlays with bone cape manager and slots, but these are removed from the latest kernel.
I tried several methods to re-configure it.
i) Disable the uboot overlay and stick to the old solution.
As instructed in here, I put #enable_uboot_overlays=1 in the boot up file. However, it is automatically written into the file when BBG boots up
ii) Override U-Boot external capes
As instructed here, I put overrode the uboot overlay with my customized ones.(using dtc to compile dts into dtbo)
Afterwards, I couldn't boot up BBG because, I have this error:
I googled this error, and I found someone had encountered similar issue as well.
I tried to follow the suggestion to make my dtbo file, but nothing need to be done. Do you know why it's not working in my case?
Therefore, the issue still remains. Could you give me some hints about migrating from kernel overlays to uboot overlays?
(By the way, the old DT files also contain slots)
Image: bone-eMMC-flasher-debian-10.3-iot-armhf-2020-04-06-4gb.img
Hardware: SeeedStudio BeagleBone Green
Capes: Customized cape(packet sniffer)
Thank you so much in advance!
The text was updated successfully, but these errors were encountered: