Device tree troubles
Device tree troubles
Posted Jul 26, 2013 13:33 UTC (Fri) by dlang (guest, #313)In reply to: Device tree troubles by etienne
Parent article: Device tree troubles
and this is the root of the misunderstanding.
On ARM devices, the address of the UART is NOT consistent, there are many possible places for it to be, and the same physical pins that are used for one UART may be used for something else instead.
So the kenrel needs to be told what device is hooked up to those pins.
this isn't a matter of it being something that's defined for a particular SoC release, it can depend on how the board that it's plugged into is wired.
And in addition to this, you can have another SoC model that's got most of the same features as the one I talked about above, but which has the different components hooked up on the chip differently, so the functions that share particular pins are going to be different.
The alternative to DT isn't that the kernel will know what's there, or that the kernel can probe and figure out what's there. the alternative is that you will have to have a file included into the kernel build that tells the kernel about the system. At which point that kernel build cannot be used for any other system.
Posted Jul 26, 2013 14:31 UTC (Fri)
by etienne (guest, #25256)
[Link] (4 responses)
I did not express myself precisely. It is constant at run time (C const), and will not change in between power-cycles.
Trying to define pin functions in the pre-boot environment calls for problems, because for instance you still did not define what is the UART pins for the console - and cannot check anything beforehand - (no error log can be printed).
For what I can see, most people attach the DT to the kernel one way or another (i.e. DT not constant for a board), because each new kernel version define more fields of DT or fixes DT bugs (DT would be too complex if it were complete, just define what you use) - and so the DT complexify the system (and slow it down) instead of simplifying it.
Posted Jul 26, 2013 20:16 UTC (Fri)
by dlang (guest, #313)
[Link] (3 responses)
This is wrong, and this point is being made on the kernel list
DT is supposed to describe the hardware period. It's supposed to do so not just for Linux, but for other OSs as well.
If the hardware doesn't change, then the DT should not change. If it does, it should be a bug in the DT being fixed, or it's an API change (which should not be happening)
by the way, where do you expect the data to come from to get linked into your binary?
Posted Jul 29, 2013 10:55 UTC (Mon)
by etienne (guest, #25256)
[Link] (2 responses)
Sorry no more reading LKML, not enough time.
When that is done, I also have to define the hardware PCB with a few thousand lines of DT describing how the system could be used and then define how I use it?
> If the hardware doesn't change, then the DT should not change. If it does, it should be a bug in the DT being fixed
Sorry, firmware in FPGA changed, loaded at run time, the DT description is variable depending on the filesystem content...
> by the way, where do you expect the data to come from to get linked into your binary?
You write it from the same docs that you would write your DT from.
Posted Jul 29, 2013 16:56 UTC (Mon)
by dlang (guest, #313)
[Link] (1 responses)
>You write it from the same docs that you would write your DT from.
I was meaning, where does the system trying to boot find the data to link into your binary. you seem to be saying that the DTis no good because there's no place to store it, so where do you store this other data that needs to be linked?
Posted Jul 29, 2013 19:12 UTC (Mon)
by etienne (guest, #25256)
[Link]
Posted Jul 31, 2013 6:45 UTC (Wed)
by alison (subscriber, #63752)
[Link]
I know, let's call that a "board file"! Oh, wait . . .
Device tree troubles
> and this is the root of the misunderstanding.
That is why it can be defined by the linker.
If you want a common file in between few boards, that common file shall be a partial link, where few symbols are still not defined - the final link specialise that Linux kernel for that system on chip on that board.
At least at link time, errors can be produced if you define the console to an UART which does not have its pin configured for UART but for I/O port.
Ever had a Device Tree: incomplete, wrong version, not at the right place in the FLASH, not present because someone erased that FLASH partition, truncated because the partition/sector_size is too small, corrupted, or the wrong DT file has been copied to FLASH?
How do you recover that board, DHCP/BOOTP (present inside system-on-chip internal ROM) only transfer a single file, the Linux kernel - no DT!
Device tree troubles
Device tree troubles
>
> This is wrong, and this point is being made on the kernel list
So you ask me to write those 10000 or more lines to describe that system on chip, with no real way to test?
Did you see the complexity of those systems on chip lately, they have a defined area of silicon and a package pin count; they fit everything they can find.
They do not even describe completely everything in their voluminous docs, they add reference to sub-parts: lately I wanted to check if there is a DMA in virtual address provided by the ARM subsystem (there are other DMAs in physical addresses in the system) - the only way to know is to ask the processor the content of a register (the docs only say where to read...).
I am already happy when the hardware works the way it is supposed to do, I cannot claim what happens if you would use it another way - and anyway you wouldn't have such a PCB to play with...
Device tree troubles
Device tree troubles
That is, combine the last two files at installation into the sdcard time, when you are running linux, windows or OSx to write that sdcard, when you can display error messages and check stuff.
In the PC world it would be at grub-install-kernel time.
And what I then mean is all this complex DT is just doing what the LD linker do, but a lot more slowly, with a lot more code, and with errors delayed to execution time when it would be better to just use LD.
TL,dr: no DT partition or file, generic kernel is partial link, specialised at installation time.
Device tree troubles
> kernel build that tells the kernel about the system. At which point that
> kernel build cannot be used for any other system.