dtb-rebuilder vs. BeagleBoard-DeviceTrees on BeagleBone Black

I’ve playing with device trees on the BeagleBone Black and have come across two repos that appear to do similar things.

and

What’s the difference between the two? I’ve been using the second to experiment with different device trees. Should I be using the rebuilder?

–Mark

Hi Mark,

I'm EOL'ing mine, the beagleboard one should be use for all current
and future dts patches.

Regards,

Hi Robert,

Hi Tarmo,

Thank you. That's good to know.

A kernel upgrade on our devices requires using the dtb-rebuilder to get our modified base DTB-s (am335x-boneblack.dtb). For the 4.19-ti series the most recent supported kernel version in your repo appears to be "4.19.25-ti-r17" from 6 months ago (when looking at commit comments).

The beagleboard repo doesn't list any kernel versions anywhere. When using this repo, how would I recognize which 4.19-ti kernel version I'd be able to apply my modified DTB-s to?

That shouldn't be an issue going forward.. (easy to say as 4.19-ti has
quieted down, so that might backfire with 5.4-ti)

With the old dtb-rebuilder repo, we'd always push a dts patch to the
kernel build script first, tag it and then manually copy it back to
the dtb-rebuilder. So things would get out of sync if i didn't copy
it over..

With the new repo, everything gets pushed to the
BeagleBoard-DeviceTrees repo first, and the files get sync'ed directly
back to the kernel build script afterwards:

https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/ti-linux-4.19.y/patch.sh#L353-L409

It should be less error prone. I hope..

Regards,

Hi Robert,

Thank you. That's good to know.

A kernel upgrade on our devices requires using the dtb-rebuilder to get our modified base DTB-s (am335x-boneblack.dtb). For the 4.19-ti series the most recent supported kernel version in your repo appears to be "4.19.25-ti-r17" from 6 months ago (when looking at commit comments).

The beagleboard repo doesn't list any kernel versions anywhere. When using this repo, how would I recognize which 4.19-ti kernel version I'd be able to apply my modified DTB-s to?

That shouldn't be an issue going forward.. (easy to say as 4.19-ti has
quieted down, so that might backfire with 5.4-ti)

With the old dtb-rebuilder repo, we'd always push a dts patch to the
kernel build script first, tag it and then manually copy it back to
the dtb-rebuilder. So things would get out of sync if i didn't copy
it over..

With the new repo, everything gets pushed to the
BeagleBoard-DeviceTrees repo first, and the files get sync'ed directly
back to the kernel build script afterwards:

https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/ti-linux-4.19.y/patch.sh#L353-L409

It should be less error prone. I hope..

Ok, the patch flow process seems sound.

But I have a rather simpler question. How would I match a specific kernel deb package to a BeagleBoard-DeviceTrees repo commit which went into _this_ package?

I suspect I can't randomly pick a set of DTB files meant for one kernel, modify and then apply those to another kernel.

E.g. I've chosen linux-image-4.19.50-ti-r24 as my kernel (from your apt repo). Now I wish to modify the DTB-s corresponding to _this_ kernel package. Not for 5.x, not for some newer or older release of 4.19-ti. How would I find the DTB-s in this package from the BeagleBoard-DeviceTrees repo?

Off-topic: I'm also assuming that the kernel packages in repos.rcn-ee.com are all tested and good for production use, which may or may not be correct.

Yesterday you have to look at the dates:

https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/ti-linux-4.14.y/patches/soc/ti/beagleboard_dtbs/0001-Add-BeagleBoard.org-DTBS-v4.14.x-ti.patch

******************
Subject: [PATCH] Add BeagleBoard.org DTBS: v4.14.x-ti
  https://github.com/beagleboard/BeagleBoard-DeviceTrees/tree/v4.14.x-ti
+https://github.com/beagleboard/BeagleBoard-DeviceTrees/commit/f15c95bd3d543557fcbbf9e43778c0483391b64e
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
******************

So here's what i came up with, hopefully it's enough, but we could add more:

https://github.com/RobertCNelson/ti-linux-kernel-dev/commit/f9dfbd70c0a4cab2ec81444290ec6fb16d6f645b

kernel v4.14.108 rebase with rt: v4.14.106-rt56 aufs/wireguard/etc
AUFS: sfjro/aufs4-standalone@df5c09a
BBDTBS: beagleboard/BeagleBoard-DeviceTrees@f15c95b
CAN-ISOTP: hartkopp/can-isotp@b31bce9
RT: patch-4.14.106-rt56.patch.xz
TI_AMX3_CM3: http://git.ti.com/gitweb/?p=processor-firmware/ti-amx3-cm3-pm-firmware.git;a=commit;h=6a849767df85ce9399494f53fb5c753665396653
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>

Regards,

Okay this has the best tag, just have to clean it up a little:

https://github.com/beagleboard/linux/releases/tag/4.14.108-ti-xenomai-r120

Regards,

Here's the final version..

https://github.com/beagleboard/linux/releases/tag/4.19.73-ti-r29

What else would be useful? :wink:

Regards,

Here's the final version..

https://github.com/beagleboard/linux/releases/tag/4.19.73-ti-r29

What else would be useful? :wink:

That's beautiful, thank you!

So yeah, i test what i can, can't test everything especially if Ubuntu
or Debian throws in a wrench with a broken gcc version or something
else in their testing repos..

Ok, so you verify that the kernel builds, then package and publish the result and finally run some integration tests using real hardware. Sounds great.

Question: when you run the weekly or daily integration tests on your little farm, how can I consume only the kernel packages that passed?

This file get's updated..

https://github.com/beagleboard/image-builder/blob/master/configs/kernel.data#L7

Now, before we go more into the details, i don't' "guarantee"
anything.. If your worried about something breaking, have a test node
you test with before you push out to many units..

Regards,

Here's the final version..

https://github.com/beagleboard/linux/releases/tag/4.19.73-ti-r29

What else would be useful? :wink:

That's beautiful, thank you!

So yeah, i test what i can, can't test everything especially if Ubuntu
or Debian throws in a wrench with a broken gcc version or something
else in their testing repos..

Ok, so you verify that the kernel builds, then package and publish the
result and finally run some integration tests using real hardware.
Sounds great.

Question: when you run the weekly or daily integration tests on your
little farm, how can I consume only the kernel packages that passed?

This file get's updated..

https://github.com/beagleboard/image-builder/blob/master/configs/kernel.data#L7

Good to know. Thanks.

Now, before we go more into the details, i don't' "guarantee"
anything.. If your worried about something breaking, have a test node
you test with before you push out to many units..

Whaddya mean, test?
https://thedailywtf.com/articles/Flawless-Compilation