dtb-rebuilder vs. BeagleBoard-DeviceTrees on BeagleBone Black

yoder · October 8, 2019, 1:28am

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

RobertCNelson · October 8, 2019, 1:43am

Hi Mark,

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

Regards,

Tarmo · October 8, 2019, 10:57am

Hi Robert,

RobertCNelson · October 8, 2019, 2:34pm

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:

github.com

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


      
          		cp -v ../wireless-regdb/regulatory.db.p7s ./firmware/
          		${git_bin} add -f ./firmware/regulatory.*
          		${git_bin} commit -a -m 'Add wireless-regdb regulatory database file' -m "https://git.kernel.org/pub/scm/linux/kernel/git/sforshee/wireless-regdb.git/commit/?id=${wireless_regdb_hash}" -s
          
          		${git_bin} format-patch -1 -o ../patches/wireless_regdb/
          		echo "WIRELESS_REGDB: https://git.kernel.org/pub/scm/linux/kernel/git/sforshee/wireless-regdb.git/commit/?id=${wireless_regdb_hash}" > ../patches/git/WIRELESS_REGDB
          
          		rm -rf ../wireless-regdb/ || true
          
          		${git_bin} reset --hard HEAD^
          
          		start_cleanup
          
          		${git} "${DIR}/patches/wireless_regdb/0001-Add-wireless-regdb-regulatory-database-file.patch"
          
          		wdir="wireless_regdb"
          		number=1
          		cleanup
          	fi

This file has been truncated. show original

It should be less error prone. I hope..

Regards,

Tarmo · October 9, 2019, 8:12am

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:

ti-linux-kernel-dev/patch.sh at ti-linux-4.19.y · RobertCNelson/ti-linux-kernel-dev · GitHub

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.

RobertCNelson · October 9, 2019, 2:36pm

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

RobertCNelson · October 9, 2019, 3:43pm

******************
Subject: [PATCH] Add BeagleBoard.org DTBS: v4.14.x-ti
GitHub - beagleboard/BeagleBoard-DeviceTrees at v4.14.x-ti
+Merge pull request #7 from jadonk/bbai-clock-limit-experiements · beagleboard/BeagleBoard-DeviceTrees@f15c95b · GitHub
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:

github.com/RobertCNelson/ti-linux-kernel-dev

kernel v4.14.108 rebase with rt: v4.14.106-rt56 aufs/wireguard/etc

committed 03:41PM - 09 Oct 19 UTC

RobertCNelson

+11 -11

AUFS: https://github.com/sfjro/aufs4-standalone/commit/df5c09adc49fd0d431c0f18d1…90130675c8bffb9 BBDTBS: https://github.com/beagleboard/BeagleBoard-DeviceTrees/commit/f15c95bd3d543557fcbbf9e43778c0483391b64e CAN-ISOTP: https://github.com/hartkopp/can-isotp/commit/b31bce98d65f894aad6427bcf6f3f7822e261a59 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>

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: Gitweb @ Texas Instruments - Open Source Git Repositories - git.TI.com/gitweb - processor-firmware/ti-amx3-cm3-pm-firmware.git/commit
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>

Regards,

RobertCNelson · October 9, 2019, 4:31pm

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,

RobertCNelson · October 9, 2019, 8:57pm

Here's the final version..

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

What else would be useful?

Regards,

Tarmo · October 10, 2019, 11:17am

Here's the final version..

Release 4.19.73-ti-r29 · beagleboard/linux · GitHub

What else would be useful?

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?

RobertCNelson · October 10, 2019, 2:41pm

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,

Tarmo · October 10, 2019, 4:31pm

Here's the final version..

Release 4.19.73-ti-r29 · beagleboard/linux · GitHub

What else would be useful?

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

image-builder/configs/kernel.data at master · beagleboard/image-builder · GitHub

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?