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 <[email protected]>
wrote:

>
>
> On Sun, Feb 19, 2023 at 5:27 PM Danny Hadley via lists.yoctoproject.org
> <[email protected]> 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 (#15900): 
https://lists.yoctoproject.org/g/meta-ti/message/15900
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]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to