Author Topic: Linux device trees...  (Read 1310 times)

0 Members and 1 Guest are viewing this topic.

Offline BoscoeTopic starter

  • Frequent Contributor
  • **
  • Posts: 285
Linux device trees...
« on: August 01, 2019, 03:31:47 pm »
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 SOM https://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
 

Online langwadt

  • Super Contributor
  • ***
  • Posts: 4857
  • Country: dk
Re: Linux device trees...
« Reply #1 on: August 01, 2019, 04:28:59 pm »
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 SOM https://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


https://www.kernel.org/doc/Documentation/devicetree/bindings/ ?

 

Online thinkfat

  • Supporter
  • ****
  • Posts: 2161
  • Country: de
  • This is just a hobby I spend too much time on.
    • Matthias' Hackerstübchen
Re: Linux device trees...
« Reply #2 on: August 02, 2019, 04:59:59 pm »
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.
Everybody likes gadgets. Until they try to make them.
 

Offline AlexFerro

  • Contributor
  • Posts: 13
  • Country: us
Re: Linux device trees...
« Reply #3 on: August 03, 2019, 06:29:34 am »
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 posts
  • The bindings documentation mentioned by langwadt
  • Other kernel documentation for the subsystems that's not specifically for device trees
  • The 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 arguments
  • Other similar looking boards whose device tree source files are easily made public, say as part of the device tree source folder in the kernel

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

« Last Edit: August 03, 2019, 06:42:50 am by AlexFerro »
Typos and other errors graciously sponsored by my brain and/or the time of day.
 

Offline droelf

  • Newbie
  • Posts: 1
  • Country: ch
Re: Linux device trees...
« Reply #4 on: August 03, 2019, 01:27:21 pm »
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: [Select]
dtc -I dtb -O dts -o devicetree.dts devicetree.dtb
 

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: Linux device trees...
« Reply #5 on: August 03, 2019, 01:37:45 pm »
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.28

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

Online thinkfat

  • Supporter
  • ****
  • Posts: 2161
  • Country: de
  • This is just a hobby I spend too much time on.
    • Matthias' Hackerstübchen
Re: Linux device trees...
« Reply #6 on: August 03, 2019, 01:52:34 pm »
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.28

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

Everybody likes gadgets. Until they try to make them.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf