Linux device trees... - Page 1
Forum section: electronics / projects

author: Boscoe
author_rank: Frequent Contributor
timestamp: August 01, 2019, 03:31:47 pm
content: These things have been a thorn in my side for months now. I'm part time developing a logger based on a processor running Linux. I initially started of with the Octavo Systems offering but it was too high power so I'm planning on moving to the Microchip SOMhttps://www.microchip.com/wwwproducts/en/ATSAMA5D27-SOM1#additional-features.The problem is I find the information from the vendors of these modules are often a bit thin on documentation especially on the Linux side of things. I assume this is because it's not really their problem however it would make the product soooo much more inviting if you made it easier for your customers to actually use it!I have never read a good explanation of the device tree 'language' and reading about them gets very confusing, fast. Explanations are often very vague and only let you know how to compile and load them - useless. I've tried going through the relevant git repo for the device tree overlays for the Microchip SOM but all I could find were very short overlays for the evaluation kit. They did not include the majority of the fundamental peripherals so I have no idea where they are covered.Could someone point me in a good direction on how to learn this stuff? Or give me some pointers on how to go about it?Thanks

author: langwadt
author_rank: Super Contributor
timestamp: August 01, 2019, 04:28:59 pm
content: Quote from: Boscoe on August 01, 2019, 03:31:47 pmhttps://www.kernel.org/doc/Documentation/devicetree/bindings/?

author: thinkfat
author_rank: Unknown
timestamp: August 02, 2019, 04:59:59 pm
content: Looking into the kernel documentation for devicetree bindings is not a bad advice, actually.A Device Tree source compiles to a flat, structured blob, the information therein it effectively free-format. The device tree compiler will put anything into the binary, as long as it can be represented by the syntax.The kernel parses the device tree at startup, extracting necessary information like system memory size and physical address, kernel command line, etc. Device driver framework will search for "compatible" attributes inside tree objects and parse out agreed-upon information like I/O memory and interrupts, while driver init functions parse driver specific attributes.Depending on the generic driver class, certain class attributes will also be extracted from device objects and stored for consumption by the driver, others need to be parsed inside the driver itself - the documentation of the bindings explains those.All in all, it's a bit like the DSDT in the ACPI framework, except you cannot store procedures, just structured objects.

author: AlexFerro
author_rank: Contributor
timestamp: August 03, 2019, 06:29:34 am
content: I felt your pain a while ago, it gets somewhat better eventually, and not because you move to a less stressful career like hostage negotiation.I think a large portion of the problem as you describe it is that you are expected to either be closely working with a vendor representative, or know somebody at your company who already knows this stuff. It's certainly doable on your own (as that's how I learned all of it), but unless you have a resource you can quickly ping, it takes a ton of time.Edit: The one place I have seen concessions made to those who don't fit those characteristics is in in the provision of a fully configured system matching an eval kit or other reference design the you aren't expected to need to adjust. But once you get outside that, it's pretty quickly into the deep end.I no longer know links to most of the resources I used to learn about device trees, but there are some decent talks about devices trees and the promise they hold, and somewhat how they work, out there on the internet. Just remember as you delve into the older talks, that some of the rosy outlooks for how device trees are going to solve all your problems and make breakfast in the morning really didn't pan out that way in the real world. Especially the theoretical one ideal device tree that perfectly describes the hardware can be flashed onto the hardware and never changes, even as kernel versions change or you go between vendor release branches or the mainline kernel tree*. I can't speak to the consistency of the SAM A5 parts and the various kernel trees out there for them, as I have never used them.I usually get device tree information from several sources:Random google searches and forum postsThe bindings documentation mentioned by langwadtOther kernel documentation for the subsystems that's not specifically for device treesThe code for the driver I am trying to use. Look in the foo_probe function and sometimes you can have an easier time of figuring out what an under-documented driver takes for argumentsOther similar looking boards whose device tree source files are easily made public, say as part of the device tree source folder in the kernelFor your specific point about not being able to to find the full device tree files, the device trees usually include** references to other files containing more generic information and description.As some examples let's take two sam a5 boards "supported" by the mainline linux kernel branch, the sama5d4_xplained board from microchip, and what looks to be a 3rd party som (Aries/DENX MA5D4) and the eval kit (Aries/DENX MA5D4EVK). Nothing specific about my choices other than being the first things to catch my eye looking through the listing of device trees.If you look at the MA5D4EVK (https://elixir.bootlin.com/linux/latest/source/arch/arm/boot/dts/at91-sama5d4_ma5d4evk.dts) you will see it's fairly short and filled with references not directly mentioned in the file, but at the top it includes at91-sama5d4_ma5d4.dtsi (https://elixir.bootlin.com/linux/latest/source/arch/arm/boot/dts/at91-sama5d4_ma5d4.dtsi). This chained series of course lets the common features of the MA5D4 som be described in one place, while supposedly features specific to the EVK can be only listed in a file for the EVK. Now you may be saying, I looked at the MA5D4 som files you linked and it's still missing stuff. That's because it includes the sama5d4.dtsi (https://elixir.bootlin.com/linux/latest/source/arch/arm/boot/dts/sama5d4.dtsi), which actually describes the peripheral set available to *all* designs that use the SAMA5D4 chip. If we then go look at the official sama5d4 xplained board (https://elixir.bootlin.com/linux/latest/source/arch/arm/boot/dts/at91-sama5d4_xplained.dts) you can see it includes the same sama5d4.dtsi as the som above uses, since it is based on the same chip. Some chips go even further and have a family common include file that each chip's include file modifies with the unique features.While you may be using a vendor provided kernel release, it is almost certain that they provided most of these files in similar places in their folder structure.You may also be able to find a support forum that you may find people discussing getting a peripheral working that is useful to you. Microchip likely hosts one.Hopefully this helps point you on the right track, and isn't just a repeat of things you already know. I am no expert on this, but I muddle along enough that the people who pay my salary seem to be happy.* Yes technically most of this is usually the vendor's fault, but it's still something to be aware of when you go out looking for help or snippets solving a problem.** Unless its a specific device tree overlay file, which I usually see in the hobby community where the external hardware cannot be fully determined at build time and instead depends on what the user has to connect. They simply have references, and expect the kernel to fill things in at run time.

author: droelf
author_rank: Newbie
timestamp: August 03, 2019, 01:27:21 pm
content: I had always issues with the .dtsi includes, which settings get overwritten in another file etc. What helped me a lot was the reverse compile option of the dtc compiler, you feed it the final (binary) .dtb and it transforms it to dts source:Code:dtc -I dtb -O dts -o devicetree.dts devicetree.dtb

author: legacy
author_rank: Super Contributor
timestamp: August 03, 2019, 01:37:45 pm
content: I have a serioud problem with the LDT about boards like Walnut designed around chip like PowerPC405GP because modern kernels read the PCI information from the LDT but this hasn't been never written in the proper way, so what worked with Linux Kernel 2.6.22 simply does no more work with kernel >= 2.6.28What I mean is: LDT requires a lot of support in the kernel, and if it's not written you have to write it along with the LDT blob.

author: thinkfat
author_rank: Unknown
timestamp: August 03, 2019, 01:52:34 pm
content: Quote from: legacy on August 03, 2019, 01:37:45 pmDevice tree support has come a long way since kernel 2.6. But not much hope for old stuff like ppc400, I guess.Gesendet von meinem Nokia 6.1 mit Tapatalk