I’m trying to migrate from the 3.8 kernel to the 3.14 kernel on a board very similar to the Beaglebone Black, but I’m running into some issues with device trees. In 3.8, I used a (slightly modified) LCD4 device tree overlay to get an LCD up and running with my board. As far as I know, device tree overlays are now a thing of the past and this is no longer possible. I don’t intend to ever change device tree configuration while the system is running, so it seemed like the best option would be to make an additional device tree that is loaded with the kernel.
I’ve never worked with device tree files before, so I made a rough attempt at turning the overlay into a fixed device tree file. Here’s a link to the contents of the file. I based the syntax off of some online resources and some existing dts files for pin-muxing and driver config (am335x-boneblack.dts as an example), but when I try to build the dtb file I just get an “Unable to parse input tree” error. It seems like the error always occurs on the first line past the /dts-v1/ line in the dts file (i.e. The error is thrown on the first #include line, but if the #include lines are deleted the error is thrown on the &am335x_pinmux line), and since there is no description or anything I really have no idea where the problems are in my source file.
From the looks of the am335x-boneblack.dts file, it isn’t extremely complicated to add new pin muxing or configuration if the basic device tree configuration is already handled (by the dtsi files) but I haven’t really had any luck. If anyone could take a look at my file and let me know why it’s completely failing I would really appreciate it.
Are you building this in a kernel source directory? Both the *.dtsi
files you are including reference a very large chain of other files that
all need to be present to properly build the device tree. And of course
the am33xx.dtsi and am335x-bone-common.dtsi files both need to be
preset, as well.
Also, if you comment both the include lines, the &am33xx_pinmux has no
reference, so it's an immediate error if you're not compiling an overlay
(where you are allowed to have references to undefined objects that are
expected to resolve later when the overlay loads).
I suggest you either start with a pre-flattened device tree (just
"decompile" the *.dtb file you're booting with using the dtc utility) or
better yet, get a kernel source directory and add your customized device
tree to the build process. Or at the very least copy the required
include files out of the kernel tree so you can easily diff them as
updates are made on the kernel side.
Converting an overlay file into an include file for the device tree is
very straight-forward, I'm not sure you even have to change anything.
Thanks for the quick reply Charles. I had only included the dtsi files “one level up” from my file in the build directory without realizing that they relied on other files as well. That probably explains it. And after thinking about it it seems pretty obvious that the reference won’t work if nothing is being included.
I built the kernel I’m using from source, so it wouldn’t be too challenging to rebuild it with my file included. If the kernel needs to compile dts files during its build, does it need to be told to look for my new file? I haven’t included any board-specific information in the file (aside from the #include) so I’d assume that the kernel can’t figure this out on its own while it’s building. My initial frantic googling hasn’t given me a location of this configuration, so do you (or anyone, really) know where you specify the device tree files to build?
Thanks for the quick reply Charles. I had only included the dtsi files “one level up” from my file in the build directory without realizing that they relied on other files as well. That probably explains it. And after thinking about it it seems pretty obvious that the reference won’t work if nothing is being included.
I built the kernel I’m using from source, so it wouldn’t be too challenging to rebuild it with my file included. If the kernel needs to compile dts files during its build, does it need to be told to look for my new file? I haven’t included any board-specific information in the file (aside from the #include) so I’d assume that the kernel can’t figure this out on its own while it’s building. My initial frantic googling hasn’t given me a location of this configuration, so do you (or anyone, really) know where you specify the device tree files to build?
Note that unless you're trying to build the device tree into the kernel
itself (which isn't done on the BeagleBone), building the dtb files is
pretty much completely separate from building the kernel.
So to experiment, you can just run builds local to the firmware
directory, although I'd recommend getting your dts tweaks committed to a
clone of the kernel source/build-scripts (whichever you're using). That
should make it easier to track progress of all the folks frantically
working on improving ARM device-tree support!
Thanks for the help guys, but I’m still a little confused on how exactly the build script knows which dtb files to generate. I’m using Robert C Nelson’s build scripts and I’ve modified one of them to skip the kernel and just build the dtbs. The firmware/Makefile that my kernel source has doesn’t mention anything about dts or dtb files, so I’m not really sure how I would modify that file in order to build an additional dtb file. The terminal echoes each dtb file it packages, and this list matches the dtb files specified in arch/arm/boot/dts/Makefile so I’m guessing that’s what it’s using to figure out which dtbs to build/package. Would I modify this file? This makefile only specifies dtb files with no information on the corresponding dts files, so I tried adding a line for my dts file in a similar manner (i.e. I added myBlob.dts to arch/arm/boot/dts/ and then added a myBlob.dtb line to the Makefile) but this doesn’t work.
Sorry for needing so much hand-holding through this but I’m really having a tough time wrapping my head around how exactly all this stuff works.
Thanks for the help guys, but I’m still a little confused on how exactly the build script knows which dtb files to generate. I’m using Robert C Nelson’s build scripts and I’ve modified one of them to skip the kernel and just build the dtbs. The firmware/Makefile that my kernel source has doesn’t mention anything about dts or dtb files, so I’m not really sure how I would modify that file in order to build an additional dtb file. The terminal echoes each dtb file it packages, and this list matches the dtb files specified in arch/arm/boot/dts/Makefile so I’m guessing that’s what it’s using to figure out which dtbs to build/package. Would I modify this file? This makefile only specifies dtb files with no information on the corresponding dts files, so I tried adding a line for my dts file in a similar manner (i.e. I added myBlob.dts to arch/arm/boot/dts/ and then added a myBlob.dtb line to the Makefile) but this doesn’t work.
Sorry for needing so much hand-holding through this but I’m really having a tough time wrapping my head around how exactly all this stuff works.
In firmware/Makefile, you will see capes with the dtbo extension. The makefile runs device tree compiler (dtc) with the source of dts and output of dtbo. You just need to add your DTS file name, but use the dtbo extension.
I got the kernel build process to build my dtb file, but n now it looks like the kernel isn’t loading it. I’m not super familiar with how the kernel actually figures out which dtb files to use, so I just threw my dtb in the boot directory in my root file system, but inspection of /proc/device-tre/e makes it pretty clear that it hasn’t loaded.
As an experiment, rather than making my own dtb file, I simply threw my code into the am335x-bone-common.dtsi device tree, built that and replaced the existing one so that it would be loaded automatically. I know this is a petty stupid way to change the device tree, but I thought it would be fine for a quick test. The LCD still isn’t working, but the interesting thing is that the additions (pinmux and ocp config for LCD) to the dtsi file do appear in /proc/device-tree/ and its sub-directories. When I compare /proc/device-tree/ with these modifications on the 3.14 kernel and /proc/device-tree/ with the 3.8 kernel and the corresponding device tree overlay, they look pretty identical. By this I mean that all the directories/files generated by the device tree overlay match up with the configuration of my modified device tree. This makes me think that the device tree has loaded properly, but the LCD driver still doesn’t seem to be configured.
Here’s the contents of the file I modified. I know it’s pretty extensive, but if anyone could help me figure out why this wouldn’t work it would be appreciated. If not, advice on getting the kernel to load my own dtb file would still be great.
The kernel doesn't load your device tree. The kernel just uses the
device tree loaded into memory by the boot loader. If you're using the
recent Debian images, you need to edit the line that looks like this:
The ${fdtfile} is the filename of the device tree u-boot will load and
pass to the kernel. This isn't generally set in the uEnv.txt file,
which means you're using the default value (which is set by some script
stuff that happens behind the scenes in the default uBoot configuration,
not all of which is overridden by the uEnv.txt file).
Anyway, just adjust things so that when the uenvcmd= line is run*, you
have the proper device tree loaded.
[*]
uenvcmd runs loadfiles
loadfiles runs loadfdt
loadfdt loads the device tree file from /dtbs/${fdtfile}
...so the easiest thing to do is probably just change ${fdtfile} to the
name of your device tree.
