Following up on my previous email - this was definitely a problem with the address I was using to load in the overlay from uboot; my hunch is that I was overwriting the loaded base device tree accidentally (offsetting the location of the overlay by `F000` was probably not enough). Now I am able to successfully execute the `fdt apply` command and it looks like - based on the output from `fdt print` everything is happy.
Now I am running into a problem within the kernel startup itself; with the overlay loaded I am seeing kernel panic messages in my console and the machine fails to boot. I think some relevant bits are: ``` [ 2.514743] tilcdc 4830e000.fb: failed to get functional clock [ 2.520694] ------------[ cut here ]------------ [ 2.525359] WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:4261 tilcdc_fini+0x68/0xbc [ 2.533041] Modules linked in: [ 2.536122] CPU: 0 PID: 1 Comm: swapper Not tainted 5.10.145-g8b51d20b6e #1 [ 2.543151] Hardware name: Generic AM33XX (Flattened Device Tree) [ 2.549321] [<c010d818>] (unwind_backtrace) from [<c0109e50>] (show_stack+0x10/0x14) [ 2.557115] [<c0109e50>] (show_stack) from [<c0add9f8>] (__warn+0xbc/0x118) [ 2.564130] [<c0add9f8>] (__warn) from [<c0addacc>] (warn_slowpath_fmt+0x78/0xac) [ 2.571661] [<c0addacc>] (warn_slowpath_fmt) from [<c0659404>] (tilcdc_fini+0x68/0xbc) [ 2.579630] [<c0659404>] (tilcdc_fini) from [<c06597a4>] (tilcdc_init.constprop.0+0x2ac/0x5bc) [ 2.588293] [<c06597a4>] (tilcdc_init.constprop.0) from [<c0659b04>] (tilcdc_pdev_probe+0x50/0xa8) [ 2.597304] [<c0659b04>] (tilcdc_pdev_probe) from [<c06728b8>] (platform_drv_probe+0x48/0x9c) [ 2.605880] [<c06728b8>] (platform_drv_probe) from [<c06706c4>] (really_probe+0xf0/0x49c) [ 2.614106] [<c06706c4>] (really_probe) from [<c0670dc0>] (driver_probe_device+0x5c/0xb4) [ 2.622332] [<c0670dc0>] (driver_probe_device) from [<c06710b0>] (device_driver_attach+0xa8/0xb0) [ 2.631255] [<c06710b0>] (device_driver_attach) from [<c0671110>] (__driver_attach+0x58/0x104) [ 2.639922] [<c0671110>] (__driver_attach) from [<c066e560>] (bus_for_each_dev+0x74/0xc0) [ 2.648148] [<c066e560>] (bus_for_each_dev) from [<c066fa5c>] (bus_add_driver+0xf8/0x1e8) [ 2.656363] [<c066fa5c>] (bus_add_driver) from [<c0671a40>] (driver_register+0x88/0x118) [ 2.664502] [<c0671a40>] (driver_register) from [<c010174c>] (do_one_initcall+0x54/0x1d0) [ 2.672733] [<c010174c>] (do_one_initcall) from [<c0f011b8>] (kernel_init_freeable+0x1b4/0x218) [ 2.681494] [<c0f011b8>] (kernel_init_freeable) from [<c0aec0b8>] (kernel_init+0x8/0x118) [ 2.689723] [<c0aec0b8>] (kernel_init) from [<c0100148>] (ret_from_fork+0x14/0x2c) [ 2.697323] Exception stack(0xc1861fb0 to 0xc1861ff8) [ 2.702406] 1fa0: 00000000 00000000 00000000 00000000 [ 2.710630] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 2.718890] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 2.725544] ---[ end trace 622da960c249401c ]--- ``` and ``` [ 3.485229] VFS: Cannot open root device "mmcblk1p2" or unknown-block(0,0): error -6 [ 3.493753] Please append a correct "root=" boot option; here are the available partitions: [ 3.502578] 0100 65536 ram0 [ 3.502617] (driver?) [ 3.508938] 0101 65536 ram1 [ 3.508975] (driver?) [ 3.515173] 0102 65536 ram2 [ 3.515178] (driver?) [ 3.521390] 0103 65536 ram3 [ 3.521395] (driver?) [ 3.527618] 0104 65536 ram4 [ 3.527624] (driver?) [ 3.533817] 0105 65536 ram5 [ 3.533823] (driver?) [ 3.540033] 0106 65536 ram6 [ 3.540039] (driver?) [ 3.546226] 0107 65536 ram7 [ 3.546231] (driver?) [ 3.552440] 0108 65536 ram8 [ 3.552446] (driver?) [ 3.558631] 0109 65536 ram9 [ 3.558637] (driver?) [ 3.564831] 010a 65536 ram10 [ 3.564836] (driver?) [ 3.571131] 010b 65536 ram11 [ 3.571137] (driver?) [ 3.577414] 010c 65536 ram12 [ 3.577419] (driver?) [ 3.583712] 010d 65536 ram13 [ 3.583718] (driver?) [ 3.590102] 010e 65536 ram14 [ 3.590106] (driver?) [ 3.596319] 010f 65536 ram15 [ 3.596322] (driver?) [ 3.602579] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) [ 3.610889] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]--- ``` My hope here is that the second error - being "unable to mount root fs" - is being caused by earlier problems (I'm not sure why adding an overlay would result in the kernel being unable to mount `mmcblk1p2`). I am currently trying to see if I can get more debug output from the kernel to help understand what is happening in the first error. I've uploaded a full log of the output here - https://gist.github.com/dadleyy/6512800f7a52a3ef9923557e05954403 -----Original message----- From: Danny Hadley via lists.yoctoproject.org Sent: Sunday, February 19 2023, 6:27 pm To: [email protected] Subject: [meta-ti] [kirkstone] trouble loading device tree overlay (beaglebone black, uboot, linux-ti-staging) Hello - I'd like to start by saying thanks gain to all for the continued work on this project! I'm reaching out again for help on my beaglebone + yocto project. I feel like I am really close to a functional implementation, but I am now stuck on getting my LCD screen to render anything (for reference, I am using one of these - https://4dsystems.com.au/4dcape-43). My hunch is that I need to enable the device tree overlay for the cape. I've spend a few days poking around, and have a recipe in my yocto project that compiles the overlay files from this repo - https://github.com/beagleboard/bb.org-overlays. At this point, I have a bunch of compiled `.dtbo` files both being written to the `DEPLOY_DIR_IMAGE` and the boot partition of my wic file which is exciting (my guess is I am specifically interested in this one - https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-BONE-4D4C-01-00A1.dts). The current hurdle I am facing is that when I attempt to apply the overlay from my u-boot script - running `fdt apply ...` prints the following error to the console: ``` failed on fdt_overlay_apply(): FDT_ERR_BADSTRUCTURE base fdt does did not have a /__symbols__ node make sure you've compiled with -@ ``` That error seems pretty clear but I'm still seeing it after subsequently adding `KERNEL_DTB_OVERLAY_SUPPORT = "1"` to a bbappend file for `linux-ti-staging_%`. I have dumped the contents of my fdt file (am335x-boneblack.dtb) using `fdtdump` and it looks like there is a `__symbols__` entry. This was also the case when manually running `fdt print` from a u-boot prompt and saving the output to a logfile through `screen`. I've uploaded the full device tree output from `fdt print` to this gist: https://gist.github.com/dadleyy/7926873ab60e9c9b5b5b02cb44e1e70b I've also been reading the u-boot docs here - https://u-boot.readthedocs.io/en/latest/usage/fdt_overlays.html and this blog post from 2018 - https://irq5.io/2018/07/24/boot-time-device-tree-overlays-with-u-boot/ My guess is that I am doing something wrong with the length and/or address of the fdt file or the overlay I am trying to use. I would be happy to provide any additional information, and any assistance is really appreciated! Thanks, - Danny
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15883): https://lists.yoctoproject.org/g/meta-ti/message/15883 Mute This Topic: https://lists.yoctoproject.org/mt/97076057/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/meta-ti/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
