Rebuild of only the *.dtb files with Robert Nelson Kernel

Hi,

I have to disable the LEDs on the AUDIO cape since they do interfere
with the LCD7 cape and the I2C bus.

Since it has to be done before the kernel boots it must
be done in the dtb files under /boot which are read by
Das U-Boot as far as I had understood the whole process.

But everytime I did changes to the regarding sources and
tools/rebuild.sh the kernel, my changes are gone.

How can I trigger only the rebuild the dtb-files with
"something" that only takes stuff under the KERNEL-directory
without copying or resetting anything...?

Thank you very much in advance for any help!

Best regards,
mcc

Hi meino,

I do not remember the exact command line parameters, but you can mostlikely find any old DTC tutorial regarding the bbb, and use the same parameters to compile the applicable DT file for the BBB. The file you’re looking for will be related to am335x-boneblack.dtb ( meaning it will or should be the exact same name but with a different extension - indicating its a device tree source file ). Reading through( and understanding ) the build script should help clear this up.

Also the file does not necessarily need to be in /boot, but uboot does need to know where to find the file. So the file could be in something like /foobar/ so long as uboot ( through uEnv.txt ) knows where the file exists. Take some time to understand uboot, and device tree, you will be glad you did.

Hi William,

Thank you for your help! :slight_smile:

I did some investigations before and the "problem" I see is, that
calling dtc will compile one .dts to a .dtb like gcc will produce a
.o from a .c.
But am335x-boneblack.dtb is more like an "executable" (it is not
executed though): It is linked together from a lot of single .dts
files.

Additionally and preferably I want to do it like or with a target of one
of the makefiles in the Robert Nelson kernel tree to not to get
hickups next time I update or rebuild the whole kernel tree...

Best regards,
mcc

William Hermans <yyrkoon@gmail.com> [13-09-09 03:02]:

Hi William,

Thank you for your help! :slight_smile:

I did some investigations before and the "problem" I see is, that
calling dtc will compile one .dts to a .dtb like gcc will produce a
.o from a .c.
But am335x-boneblack.dtb is more like an "executable" (it is not
executed though): It is linked together from a lot of single .dts
files.

You can easily work around this by turning the "compiled" dtb file into
a flat dts file with dtc, make your changes, then rebuild the dtb file.

The device tree files can be traslated back and forth between the
machine readable and human readable forms by the dtc program.

Additionally and preferably I want to do it like or with a target of one
of the makefiles in the Robert Nelson kernel tree to not to get
hickups next time I update or rebuild the whole kernel tree...

To make it easy to track kernel changes, you should craft a patch with
your desired changes to the device tree and fold them into the patch.sh
script in a forked version of RCN's build scripts. It is then
reasonably straight-forward to merge in changes from upstream while
keeping your local modifications.

For an example, see my fork of RCN's kernel build script that adds
support for the Xenomai real-time patches. I have some extra code in
the git.sh script that pulls the Xenomai code, then I modify the local
kernel image at the end of the patch.sh script:

Once you do this, you can "git fetch" changes from upstream and merge
them with your local changes easily (assuming you code reasonably well,
I suggest keeping your patches in their own procedure to keep the diffs
clean).

Charles Steinkuehler <charles@steinkuehler.net> [13-09-09 04:44]:

> Hi William,
>
> Thank you for your help! :slight_smile:
>
> I did some investigations before and the "problem" I see is, that
> calling dtc will compile one .dts to a .dtb like gcc will produce a
> .o from a .c.
> But am335x-boneblack.dtb is more like an "executable" (it is not
> executed though): It is linked together from a lot of single .dts
> files.

You can easily work around this by turning the "compiled" dtb file into
a flat dts file with dtc, make your changes, then rebuild the dtb file.

The device tree files can be traslated back and forth between the
machine readable and human readable forms by the dtc program.

> Additionally and preferably I want to do it like or with a target of one
> of the makefiles in the Robert Nelson kernel tree to not to get
> hickups next time I update or rebuild the whole kernel tree...

To make it easy to track kernel changes, you should craft a patch with
your desired changes to the device tree and fold them into the patch.sh
script in a forked version of RCN's build scripts. It is then
reasonably straight-forward to merge in changes from upstream while
keeping your local modifications.

For an example, see my fork of RCN's kernel build script that adds
support for the Xenomai real-time patches. I have some extra code in
the git.sh script that pulls the Xenomai code, then I modify the local
kernel image at the end of the patch.sh script:

linux-dev/patch.sh at am33x-v3.8-bone26.1-xenomai · cdsteinkuehler/linux-dev · GitHub

Once you do this, you can "git fetch" changes from upstream and merge
them with your local changes easily (assuming you code reasonably well,
I suggest keeping your patches in their own procedure to keep the diffs
clean).

--
Charles Steinkuehler
charles@steinkuehler.net

Hi Charles,

For the moment I try to figure out, what the makefile target is,
which build the regarding dtb file from the dts files.

Building patches and possibly provide them is a task, which I
will do, if I am sure, its working.

"Then rebuild the dtb file" is exactly which I want to do
with calling one of the dozen targets of the makefiles of
the kernel source.

Best regards,
mcc