I need a "clean" build-id and commit-hash for the kernel and the dtb

Autonomous Machines Jetson & Embedded Systems Jetson AGX Xavier
1

Hello,

Here are the steps that I did:

  1. I cloned the D3 Jetson for Xavier v.5.0.0
sudo git clone https://github.com/D3Engineering/d3-jetson-bsp.git
sudo git checkout tags/D3/RELEASE/5.0.0
  1. made changes to the kernel/d3 and hardware/d3 folders
sudo chmod -R 777 *

erase unnecessary files in hardware/d3 and kernel/d3
copy changed files  to /hardware/d3/* and /kernel/d3/*
  1. commited all changes to my local GIT repository:
git add --all
git commit -m "v0.5 kernel+HW"
  1. compiled as follows:
sudo ./bootstrap
sudo ./configure --with-system-type=xavier --with-username=dev --with-dtb='build/deploy/boot/d3-xavier-16x-fpdlink.dtb' --with-l4t='../Linux_for_Tegra/'
sudo make ARCH=arm64 -j16

  1. after compilation:
    [deploy] complete - build ID d8b08853-fa03-4c23-8129-6efd60569871, hash untracked source Wed 21 Jun 2023 15:33:41 IDT)

  2. After copying the newly compiled kernel and dtb to the unit, the dmesg | grep build-id shows:

[    2.186108] build-id: D3 Jetson BSP v5.0.0 build-id:d8b08853-fa03-4c23-8129-6efd60569871 commit-hash:untracked source Wed 21 Jun 2023 15:33:41 IDT
[    2.186114] build-id: failure, kernel does not match device tree: kernel build-id="d8b08853-fa03-4c23-8129-6efd60569871", device-tree build-id="" kernel commit-hash="untracked source Wed 21 Jun 2023 15:33:41 IDT", device-tree commit-hash="dirty source tree me@company.com Sun Apr 30 11:53:52 UTC 2023"

What can I do to receive a build-id for the dtb?
What can I do so that the commit-hash of the kernel and the device-tree will not be reported as “dirty”?

Thanks for any ideas,

Mechi

2

Today I cloned both the D3 and L4T sources - no changes of mine added (except for small bugfix in rtl8812au_xmit.c - otherwise it doesn’t compile.)

I commited the small change:

:~/.../nvidia ((9ee0b61b8...))$ git log
commit 9ee0b61b8d5dcd4db45678e8503375bf6cd25a3a (HEAD)
Author: Mechi <mechi....com>
Date:   Thu Jun 22 13:57:57 2023 +0300

    small bugfix in rtl8812au_xmit.c

commit f0fb057d829177300bf5fca25c6b1d0b2a719622 (tag: D3/RELEASE/5.0.0, origin/d3/5.0.0)
Author: Cody Burrows <cburrows@d3engineering.com>
Date:   Fri Jun 10 15:09:09 2022 -0400

    d3/5.0.0

Still I get:

[deploy] complete - build ID 8c53c0ce-28d8-44a9-9f3b-c1ec2538aef7, hash dirty source tree mechi....com Thu 22 Jun 2023 13:42:16 IDT)

Here’s the history of what I did:

sudo git clone https://github.com/D3Engineering/d3-jetson-bsp.git
cd d3-jetson-bsp
sudo git checkout tags/D3/RELEASE/5.0.0
sudo git submodule update --recursive --init
sudo ./bootstrap
sudo ./configure --with-system-type=xavier --with-username=dev --with-dtb='build/deploy/boot/d3-xavier-16x-fpdlink.dtb' --with-l4t='../Linux_for_Tegra/'
sudo make linux-defconfig
sudo make ARCH=arm64 -j16

< fixed /l4t-submodules/kernel/nvidia/drivers/net/wireless/realtek/rtl8812au/hal/rtl8812a/usb/rtl8812au_xmit.c >
< committed small change in submodules /kernel/nvidia and l4t-submodules and d3-jetson-bsp directory >

sudo make ARCH=arm64 -j16
5

why don’t you fetch the source and compare the git history.
you may refer to developer guide, Working With Sources.

6

The kernel build-id is fine - even though it states “dirty” because I haven’t pushed to the remote repository.

My need is to have a build-id also for the device tree…

I used the following line to see the dtb in a textual file:

dtc -I dtb -O dts d3-xavier-16x-fpdlink.dtb -o show_dtb.txt 2> dtb_err.txt

I compared with a textual dtb compiled a few months ago - each has its own build hash.
How can I read this build hash or have it output in the dmesg?

From this week:

/dts-v1/;

/ {
	compatible = "nvidia,galen\0nvidia,jetson-xavier\0nvidia,p2822-0000+p2888-0001\0nvidia,tegra194";
	model = "Jetson-AGX";
	nvidia,dtsfilename = "arch/arm64/boot/dts/../../../../../../hardware/d3/d3-xavier-16x-fpdlink.dts";
	nvidia,dtbbuildtime = "Jun 22 2023\010:47:56";
	d3,dts-description = "DESC<NVIDIA Jetson AGX Xavier with DesignCore NVIDIA Jetson AGX Xavier FPD-Link III Interface Card>DESC";
	d3,jetson-bsp-version = "5.0.0";
	d3,jetson-bsp-build-id = "38a6b08a-45c3-48f0-828e-692bb61d7ec3";
	d3,jetson-bsp-commit-hash = "dirty source tree  Thu 22 Jun 2023 10:47:54 IDT";

And from a while back:

/dts-v1/;

/ {
	compatible = "nvidia,galen", "nvidia,jetson-xavier", "nvidia,p2822-0000+p2888-0001", "nvidia,tegra194";
	d3,jetson-bsp-commit-hash = "dirty source tree  Thu 16 Feb 2023 13:30:38 IST";
	nvidia,dtbbuildtime = "Feb 16 2023", "13:30:43";
	model = "Jetson-AGX";
	nvidia,dtsfilename = "arch/arm64/boot/dts/../../../../../../hardware/d3/d3-xavier-16x-fpdlink.dts";
	d3,dts-description = "DESC<NVIDIA Jetson AGX Xavier with DesignCore NVIDIA Jetson AGX Xavier FPD-Link III Interface Card>DESC";
	d3,jetson-bsp-build-id = "be4e5468-b10f-4ea1-bdfe-6e93c2e7243c";

I didn’t find any information in the link you sent.
Thanks,
Mechi

7

Sorry for the late response, have you managed to get issue resolved or still need the support? Thanks

8

No.

Since i want to introduce a version control into our system, it’s important that each build be identified by date and hash id.

9

This is not what you want, but as a temporary workaround, consider that the downloaded content could be added to your own repository. The hash ID, in theory, would be the same. This would allow any of:

  • Using that hash ID to search to see if the NVIDIA repository has that ID.
  • Using your own local repository. This can be good because if the ID becomes available via another git server, then you can more easily transfer to that server using the same hash ID.
10

In the documentation I found the following:

Check match between kernel and dtb:

The kernel build ID

cat /sys/module/build_id/parameters/build_id
e2080b9d-68d4-4d37-a906-02cc1491bd39

The device tree build ID

cat /proc/device-tree/d3,jetson-bsp-build-id
e2080b9d-68d4-4d37-a906-02cc1491bd39

This would seem to imply that the kernel and the dtb have the same build-id.
Is this so?

11

I don’t know for certain, but it probably does mean that. To say why, I have to explain some details about the device tree.

You can think of the device tree as a way of passing arguments to kernel drivers related to devices which are not “plug-n-play”. Those devices have no means of broadcasting what they are, or where they are (they use a physical address on some bus or on the memory controller). Being that they are arguments passed to kernel code, they are not actually part of the kernel source itself. However, certain device tree fragments always apply to a given driver, and before building a kernel, one will configure all of the features and drivers. This means that although the device tree is not part of the kernel, that because there is a direct correspondence between device tree and the features enabled in the kernel configuration, that the device tree code for a given feature is enabled and available within the kernel at any time when a feature is enabled.

It is a convenience, and the kernel has the device tree compiler source within the kernel source, and it just happens to be the easiest way to build the tree: Simply build it based on the kernel config, and the kernel source is where one finds the kernel config.

If the ID is the same, it means the ID of the kernel source tree as a whole; the device tree content is in that same source tree. It doesn’t have to be there, but it is, so you should be able to get a correct device tree by building from the configured kernel source.

Some people do modify device trees though. Maybe you have a custom carrier board, and a device is at a different address. The logic of the tree in the kernel represents the default values, and you might still need to edit something like enable or disable, or physical address, prior to building (which would actually modify the ID).

12

Thanks!
So then this can be helpful

14

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.