[kirkstone] trouble loading device tree overlay (beaglebone black, uboot, linux-ti-staging)

[kirkstone] trouble loading device tree overlay (beaglebone black, uboot, linux-ti-staging)

[danny]

[-- Attachment #1: Type: text/plain, Size: 2604 bytes --]

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


[-- Attachment #2: Type: text/html, Size: 5932 bytes --]

Re: [meta-ti] [kirkstone] trouble loading device tree overlay (beaglebone black, uboot, linux-ti-staging)

[Robert Nelson]

[-- Attachment #1: Type: text/plain, Size: 1900 bytes --]

On Sun, Feb 19, 2023 at 5:27 PM Danny Hadley via lists.yoctoproject.org
<danny=sizethreestudios.com@lists.yoctoproject.org> wrote:

> 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)
> <https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-BONE-4D4C-01-00A1.dts).>
> .
>

The separate "bb.org-overlays" should not be used outside of anything newer
than v4.19.x based kernels. While it worked great for many years, just too
many device-tree api changes over the years..

Our 5.10.x-ti branch has direct support for the BB-BONE-4D4C-01-00A1.dts:
https://git.beagleboard.org/beagleboard/linux/-/blob/5.10/arch/arm/boot/dts/overlays/BB-BONE-4D4C-01-00A1.dts
, thus it's already built for this lcd.

The other trick, the Black defaults to built-in hdmi..  Another board has
shipped that's the Black without an HDMI.  "BeagleBone-Green", so in u-boot
force fdtfile=am335x-bonegreen.dtb and apply the BB-BONE-4D4C-01-00A1.dtbo
overlay..

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

[-- Attachment #2: Type: text/html, Size: 3265 bytes --]

Re: [meta-ti] [kirkstone] trouble loading device tree overlay (beaglebone black, uboot, linux-ti-staging)

[Danny]

[-- Attachment #1: Type: text/plain, Size: 5859 bytes --]

Hi Robert - Thank you for the response (and apologies for double emailing)!
I have tried swapping my kernel provider to use the bb.org recipe by
setting:

```
PREFERRED_PROVIDER_virtual/kernel = "linux-bb.org"
```

but after about ~5 attempts I still have not been able to successfully
fetch the repo; I am a bit worried I might be trying to fetch too large of
an amount of data. I believe the relevant logs from my build system are:

```
git -c core.fsyncobjectfiles=0 -c gc.autoDetach=false -c core.pager=cat
clone --bare --mirror https://git.beagleboard.org/beagleboard/linux.git
git.beagleboard.org.beagleboard.linux.git --progress failed with exit code
128, no output
```

yocto aside, trying to clone via

```
git clone https://git.beagleboard.org/beagleboard/linux.git
```

fails (somewhat expectedly, I think) with

```
error: 1610 bytes of body are still expected1.01 GiB | 5.65 MiB/s
fetch-pack: unexpected disconnect while reading sideband packet
fatal: early EOF
fatal: fetch-pack: invalid index-pack output
```

I am able to clone with `--depth 1 --no-checkout`, which I had considered
doing to make a personal mirror on github but I don't think thats the right
direction to go, or if I should be looking into some bitbake configuration
to perform some shallow clone.

Is there a correct way to go about using the `git.beaglebone.org` servers
as the source?

I did notice that you *might* be maintaining a mirror on github.com at
https://github.com/beagleboard/linux - is it safe to assume that will be
kept up to date with the sources at git.beagleboard.org? The commit
referred to by the current kirkstone branch in meta-ti (
https://git.yoctoproject.org/meta-ti/tree/meta-ti-bsp/recipes-kernel/linux/linux-bb.org_git.bb?h=kirkstone)
does not exist (9b11aaf2cdb1861ca74dc69d032a0f94cdd32bd6) in the github
repo, i.e (
https://github.com/beagleboard/linux/commit/9b11aaf2cdb1861ca74dc69d032a0f94cdd32bd6
).

What is interesting is that the parent of 9b11aaf does exist in both -
49ae123d2fee3f4ed30c5359fbb3e398e898f2a9. I tried overriding the `SRC_URI`
of the linux-bb.org_git.bb recipe to be

```
SRC_URI = "git://
github.com/beagleboard/linux.git;protocol=https;branch=${BRANCH}"
SRCREV = "49ae123d2fee3f4ed30c5359fbb3e398e898f2a9"
```

which causes bitbake to fail with

```
Fetcher failure: Unable to find revision
49ae123d2fee3f4ed30c5359fbb3e398e898f2a9 in branch 5.10
```
I had also tried using a `.tar.gz` of the source itself from the download
url provided by gitlab but wasn't sure what needed to change for that to be
accepted as a `SRC_URI` by bitbake.

As a third option I noticed that the overlays themselves seem to be kept up
to date in https://git.beagleboard.org/beagleboard/BeagleBoard-DeviceTrees;
this caught my eye because I was thinking that the existing recipe I set up
to compile and place the overlays in my boot partition from the legacy
https://github.com/beagleboard/bb.org-overlays repo works almost as-is with
a `SRC_UI` pointing to that repo.

The thinking there is that I can still use `linux-ti-staging` and the `
git.ti.com` upstream kernel sources while using the `git.beaglebone.org`
upstream as the source for my device tree overlays. Since the kernel
sources might not include all of the patches from the `git.beaglebone.org`
source, I'm skeptical if this would work, but I'm going to give it a try
now and see what happens.

Thanks again for your help!

On Tue, Feb 21, 2023 at 9:42 AM Robert Nelson <robertcnelson@gmail.com>
wrote:

>
>
> On Sun, Feb 19, 2023 at 5:27 PM Danny Hadley via lists.yoctoproject.org
> <danny=sizethreestudios.com@lists.yoctoproject.org> wrote:
>
>> 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)
>> <https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-BONE-4D4C-01-00A1.dts).>
>> .
>>
>
> The separate "bb.org-overlays" should not be used outside of anything
> newer than v4.19.x based kernels. While it worked great for many years,
> just too many device-tree api changes over the years..
>
> Our 5.10.x-ti branch has direct support for the BB-BONE-4D4C-01-00A1.dts:
> https://git.beagleboard.org/beagleboard/linux/-/blob/5.10/arch/arm/boot/dts/overlays/BB-BONE-4D4C-01-00A1.dts
> , thus it's already built for this lcd.
>
> The other trick, the Black defaults to built-in hdmi..  Another board has
> shipped that's the Black without an HDMI.  "BeagleBone-Green", so in u-boot
> force fdtfile=am335x-bonegreen.dtb and apply the BB-BONE-4D4C-01-00A1.dtbo
> overlay..
>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.com/
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#15894):
> https://lists.yoctoproject.org/g/meta-ti/message/15894
> Mute This Topic: https://lists.yoctoproject.org/mt/97076057/7450809
> Group Owner: meta-ti+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/meta-ti/unsub [
> dadleyy@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

[-- Attachment #2: Type: text/html, Size: 9592 bytes --]

RE: [meta-ti] [kirkstone] trouble loading device tree overlay (beaglebone black, uboot, linux-ti-staging)

[danny]

[-- Attachment #1: Type: text/plain, Size: 7035 bytes --]

Following up on this - I was able to get a mirror set up and have been successfully able to clone from that remote instead of `git.beagleboard.org` which solved my fetching problems. I'm not sure if it was necessary, but there were some hoops I had to jump through to checkout and publish the commit rev `9b11aaf` to the mirror; after cloning, git was complaining it was a bad object so I fetched it explicitly and checked out a branch using it as the rev, e.g (from memory, ymmv):

 
```

git fetch 9b11aaf

git checkout -b 5.10-9b11aaf-explicit 9b11aaf

``` 

 
for posterity's sake, my `linux-bb.org_%.bbappend` looks like:

 
```

DEPENDS += " lzop-native"
BB_FETCH_PREMIRRORONLY = "1"
BRANCH = "5.10-9b11aaf-explicit"
PREMIRRORS:prepend = " \
    git://git.beagleboard.org/.* git://....;protocol=https \
"

```

 
at the end of the day, the LCD cape is now rendering everything I'd expect it to, so I'd consider this a success.

 
Thank you very much.

-----Original message-----
From: Danny Hadley
Sent: Tuesday, February 21 2023, 7:59 pm
To: Robert Nelson
Cc: danny; meta-ti@lists.yoctoproject.org
Subject: Re: [meta-ti] [kirkstone] trouble loading device tree overlay (beaglebone black, uboot, linux-ti-staging)
 Hi Robert - Thank you for the response (and apologies for double emailing)! I have tried swapping my kernel provider to use the bb.org recipe by setting:
 ```
PREFERRED_PROVIDER_virtual/kernel = "linux-bb.org"
```
 but after about ~5 attempts I still have not been able to successfully fetch the repo; I am a bit worried I might be trying to fetch too large of an amount of data. I believe the relevant logs from my build system are:

```
git -c core.fsyncobjectfiles=0 -c gc.autoDetach=false -c core.pager=cat clone --bare --mirror https://git.beagleboard.org/beagleboard/linux.git git.beagleboard.org.beagleboard.linux.git --progress failed with exit code 128, no output
```
 yocto aside, trying to clone via

```
git clone https://git.beagleboard.org/beagleboard/linux.git
```
 fails (somewhat expectedly, I think) with

```
error: 1610 bytes of body are still expected1.01 GiB | 5.65 MiB/s    
fetch-pack: unexpected disconnect while reading sideband packet
fatal: early EOF
fatal: fetch-pack: invalid index-pack output
```
 I am able to clone with `--depth 1 --no-checkout`, which I had considered doing to make a personal mirror on github but I don't think thats the right direction to go, or if I should be looking into some bitbake configuration to perform some shallow clone.
 Is there a correct way to go about using the `git.beaglebone.org` servers as the source?
 I did notice that you might be maintaining a mirror on github.com at https://github.com/beagleboard/linux - is it safe to assume that will be kept up to date with the sources at git.beagleboard.org? The commit referred to by the current kirkstone branch in meta-ti (https://git.yoctoproject.org/meta-ti/tree/meta-ti-bsp/recipes-kernel/linux/linux-bb.org_git.bb?h=kirkstone) does not exist (9b11aaf2cdb1861ca74dc69d032a0f94cdd32bd6) in the github repo, i.e (https://github.com/beagleboard/linux/commit/9b11aaf2cdb1861ca74dc69d032a0f94cdd32bd6).
 What is interesting is that the parent of 9b11aaf does exist in both - 49ae123d2fee3f4ed30c5359fbb3e398e898f2a9. I tried overriding the `SRC_URI` of the linux-bb.org_git.bb recipe to be

```
SRC_URI = "git://github.com/beagleboard/linux.git;protocol=https;branch=${BRANCH}"
SRCREV = "49ae123d2fee3f4ed30c5359fbb3e398e898f2a9"
```
 which causes bitbake to fail with

```
Fetcher failure: Unable to find revision 49ae123d2fee3f4ed30c5359fbb3e398e898f2a9 in branch 5.10
```
I had also tried using a `.tar.gz` of the source itself from the download url provided by gitlab but wasn't sure what needed to change for that to be accepted as a `SRC_URI` by bitbake.
 As a third option I noticed that the overlays themselves seem to be kept up to date in https://git.beagleboard.org/beagleboard/BeagleBoard-DeviceTrees; this caught my eye because I was thinking that the existing recipe I set up to compile and place the overlays in my boot partition from the legacy https://github.com/beagleboard/bb.org-overlays repo works almost as-is with a `SRC_UI` pointing to that repo.
 The thinking there is that I can still use `linux-ti-staging` and the `git.ti.com` upstream kernel sources while using the `git.beaglebone.org` upstream as the source for my device tree overlays. Since the kernel sources might not include all of the patches from the `git.beaglebone.org` source, I'm skeptical if this would work, but I'm going to give it a try now and see what happens.
 Thanks again for your help!
 On Tue, Feb 21, 2023 at 9:42 AM Robert Nelson <robertcnelson@gmail.com> wrote:
  On Sun, Feb 19, 2023 at 5:27 PM Danny Hadley via lists.yoctoproject.org <danny=sizethreestudios.com@lists.yoctoproject.org> wrote:
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 separate "bb.org-overlays" should not be used outside of anything newer than v4.19.x based kernels. While it worked great for many years, just too many device-tree api changes over the years..
 Our 5.10.x-ti branch has direct support for the BB-BONE-4D4C-01-00A1.dts: https://git.beagleboard.org/beagleboard/linux/-/blob/5.10/arch/arm/boot/dts/overlays/BB-BONE-4D4C-01-00A1.dts , thus it's already built for this lcd.
 The other trick, the Black defaults to built-in hdmi..  Another board has shipped that's the Black without an HDMI.  "BeagleBone-Green", so in u-boot force fdtfile=am335x-bonegreen.dtb and apply the BB-BONE-4D4C-01-00A1.dtbo overlay..
 Regards,
 --
Robert Nelson
https://rcn-ee.com/


 
-=-=-=-=-=-=-=-=-=-=-=-

Links: You receive all messages sent to this group.

View/Reply Online (#15900): https://lists.yoctoproject.org/g/meta-ti/message/15900

Mute This Topic: https://lists.yoctoproject.org/mt/97076057/7473053

Group Owner: meta-ti+owner@lists.yoctoproject.org

Unsubscribe: https://lists.yoctoproject.org/g/meta-ti/unsub [danny@sizethreestudios.com]

-=-=-=-=-=-=-=-=-=-=-=-






[-- Attachment #2: Type: text/html, Size: 13857 bytes --]

Re: [meta-ti] [kirkstone] trouble loading device tree overlay (beaglebone black, uboot, linux-ti-staging)

[Robert Nelson]

On Tue, Feb 21, 2023 at 6:59 PM Danny <dadleyy@gmail.com> wrote:
>
> Hi Robert - Thank you for the response (and apologies for double emailing)! I have tried swapping my kernel provider to use the bb.org recipe by setting:
>

No worries, i'm on every list, so it's a matter of just replying to
the one with the most reach!


> ```
> PREFERRED_PROVIDER_virtual/kernel = "linux-bb.org"
> ```
>
> but after about ~5 attempts I still have not been able to successfully fetch the repo; I am a bit worried I might be trying to fetch too large of an amount of data. I believe the relevant logs from my build system are:
>
> ```
> git -c core.fsyncobjectfiles=0 -c gc.autoDetach=false -c core.pager=cat clone --bare --mirror https://git.beagleboard.org/beagleboard/linux.git git.beagleboard.org.beagleboard.linux.git --progress failed with exit code 128, no output
> ```
>
> yocto aside, trying to clone via
>
> ```
> git clone https://git.beagleboard.org/beagleboard/linux.git
> ```
>
> fails (somewhat expectedly, I think) with
>
> ```
> error: 1610 bytes of body are still expected1.01 GiB | 5.65 MiB/s
> fetch-pack: unexpected disconnect while reading sideband packet
> fatal: early EOF
> fatal: fetch-pack: invalid index-pack output
> ```

So I've talked with NM about this too, I'm thinking we should swap the
beagleboard.org's git repo back to github:
https://github.com/Beagleboard/linux  as both repo's are a mirror of
each other...

On the Hosting side, BeagleBoard.org's "GitLab" git server is a single
AWS arm64 host, whereas github is a massive data farm..

Swap: https://git.beagleboard.org/beagleboard/linux.git
For: https://github.com/beagleboard/linux.git

I keep both in sync on every BeagleBoard.org tag..

https://git.ti.com/gitweb?p=arago-project/meta-ti.git;a=commit;h=f843fa1914896358911b52eba7052ba1996a6919

CC'ed Denys and Ryan from ^

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

Re: [meta-ti] [kirkstone] trouble loading device tree overlay (beaglebone black, uboot, linux-ti-staging)

[Robert Nelson]

What is interesting is that the parent of 9b11aaf does exist in both -
49ae123d2fee3f4ed30c5359fbb3e398e898f2a9. I tried overriding the
`SRC_URI` of the linux-bb.org_git.bb recipe to be

```
SRC_URI = "git://github.com/beagleboard/linux.git;protocol=https;branch=${BRANCH}"
SRCREV = "49ae123d2fee3f4ed30c5359fbb3e398e898f2a9"
```

which causes bitbake to fail with

```
Fetcher failure: Unable to find revision
49ae123d2fee3f4ed30c5359fbb3e398e898f2a9 in branch 5.10
```

ah, i see another issue..

49ae123d2fee3f4ed30c5359fbb3e398e898f2a9 -> 5.10.145-ti-r55

How do we fix this in yocto, to grab a specific tag, and not the
branch:  (the Branches get rebased, the tag's stay for-ever)

I've seen another user do it on the forum (Balena maybe..)

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

Re: [meta-ti] [kirkstone] trouble loading device tree overlay (beaglebone black, uboot, linux-ti-staging)

[Robert Nelson]

Thinking this would fix both?

```
SRC_URI = "git://github.com/beagleboard/linux.git;protocol=https;tag=5.10.145-ti-r55"
SRCREV = "49ae123d2fee3f4ed30c5359fbb3e398e898f2a9"
```

Another step could be to move 5.10.145-ti-r55 -> to a variable:

lots of tags to choose from:
https://git.beagleboard.org/beagleboard/linux/-/tags

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

Re: [meta-ti] [kirkstone] trouble loading device tree overlay (beaglebone black, uboot, linux-ti-staging)

[Robert Nelson]

On Thu, Feb 23, 2023 at 1:21 PM Robert Nelson <robertcnelson@gmail.com> wrote:
>
> Thinking this would fix both?
>
> ```
> SRC_URI = "git://github.com/beagleboard/linux.git;protocol=https;tag=5.10.145-ti-r55"
> SRCREV = "49ae123d2fee3f4ed30c5359fbb3e398e898f2a9"
> ```
>
> Another step could be to move 5.10.145-ti-r55 -> to a variable:
>
> lots of tags to choose from:
> https://git.beagleboard.org/beagleboard/linux/-/tags

K3 only arm64 tags can be filtered via:

https://git.beagleboard.org/beagleboard/linux/-/tags?sort=updated_desc&search=ti-arm64

non arm64 are am335x/am57xx

Regards,
-- 
Robert Nelson
https://rcn-ee.com/

Re: [meta-ti] [kirkstone] trouble loading device tree overlay (beaglebone black, uboot, linux-ti-staging)

[Denys Dmytriyenko]

On Thu, Feb 23, 2023 at 01:23:50PM -0600, Robert Nelson wrote:
> On Thu, Feb 23, 2023 at 1:21 PM Robert Nelson <robertcnelson@gmail.com> wrote:
> >
> > Thinking this would fix both?
> >
> > ```
> > SRC_URI = "git://github.com/beagleboard/linux.git;protocol=https;tag=5.10.145-ti-r55"
> > SRCREV = "49ae123d2fee3f4ed30c5359fbb3e398e898f2a9"
> > ```
> >
> > Another step could be to move 5.10.145-ti-r55 -> to a variable:
> >
> > lots of tags to choose from:
> > https://git.beagleboard.org/beagleboard/linux/-/tags
> 
> K3 only arm64 tags can be filtered via:
> 
> https://git.beagleboard.org/beagleboard/linux/-/tags?sort=updated_desc&search=ti-arm64
> 
> non arm64 are am335x/am57xx
> 
> Regards,
> -- 
> Robert Nelson
> https://rcn-ee.com/

Thanks, Robert. I'll take a look and update the recipe.

-- 
Denys

RE: [meta-ti] [kirkstone] trouble loading device tree overlay (beaglebone black, uboot, linux-ti-staging)

[danny]

[-- Attachment #1: Type: text/plain, Size: 8521 bytes --]

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: meta-ti@lists.yoctoproject.org
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 (#15880): https://lists.yoctoproject.org/g/meta-ti/message/15880

Mute This Topic: https://lists.yoctoproject.org/mt/97076057/7473053

Group Owner: meta-ti+owner@lists.yoctoproject.org

Unsubscribe: https://lists.yoctoproject.org/g/meta-ti/unsub [danny@sizethreestudios.com]

-=-=-=-=-=-=-=-=-=-=-=-






[-- Attachment #2: Type: text/html, Size: 15763 bytes --]