I’d thought about of this possibility when posting the thread (relationship between cape eprom and device tree) that I suspect prompted this RFD. Here are some thoughts I’d had (that were not included in the original thread):
In general, putting info in an eprom is appropriate when the info can be
a) determined at hardware definition (compile) time, and
b) is static in nature.
- Eprom backwards compatibility
The current eprom spec has the bulk of the eprom area (offset 244 for 32543 bytes) marked as “Available”. The comment in the BBB SRM says: “Available space for other non-volatile codes/data to be used as needed by the manufacturer or SW driver. Could also store presets for use by SW.”
If we alter the eprom spec to use part or all of this area for a DT file, we should consider the situation that some or all of this space has already been used by a manufacturer in an existing cape eprom. Any space dedicated to DT usage would become space that is no longer available for other uses to the manufacturer. That could make an existing eprom contents not “forward compatible” with the proposed eprom spec change.
FYI, I’ve run across at least one cape that uses some of this area for it’s own purposes.
This possibility of pre-use also implies at least some signature checking logic for a DT file in the eprom so that there is a high probability that an existing eprom will not be mistaken for one containing a DT file etc.
There are few enough capes today, many of which are manufactured by one entity, that it might be possible to quantify how many capes would be impacted by the proposed change.
This may or may not be a big consideration – I’m not passing judgment - just calling it out as one consideration.
- DT eprom size allocation
How much of the eprom “Available” space would be allocated to DT storage?
The obvious ends of the scale are 0 and “all of it”.
Future expansion proofing makes me want to back off of “all of it” (it’s always good to have some left over space in the eprom so that if nothing else you can indicate “this eprom scheme got obsolete over time go look for the expanded eprom contents”).
Can someone provide some input as to any naturally existing bounds that could be taken advantage of? For example is there a maximum DT file size?
- Duplicate information
Following on from the “size” thoughts takes me back to my original thread’s topic. Ideally I’d prefer not to duplicate the eprom’s pin usage area in a more verbose format (DT source). That just seems wasteful of eprom space.
However, leveraging the existing pin map into a DT file could require a pin table to DT source translator. If we just put a DT source file in the eprom, the “translator/author” is a human. If we want to use the pin map info to create a DT file, we are lead into a software exercise that is probably harder than the storage space gain is worth. I’m uncertain as to how difficult this such a translation might be as I’ve not seen a “DT source language spec” (and thus don’t feel I’m really entitled to an opinion on that).
How hard this could be also depends on the next item –
- Store DT source or compiled DT file?
If one stores a compiled file:
Uses less space (I’m assuming that, I did not check the numbers).
Results in a simple copy from eprom to file system.
Since the cape manager uses compiled overlays, this avoids any need to “compile DT source on the fly” during the boot process. I initially want to shy away from on the fly compiles…. Feel to me like that could generate too much support hassle if the compile fails.
A compiled DT file is not very human friendly. But that may not be an issue as I’ve read that if you swap the input and output files to the DTC, it will “decompile a DTO into source”. I’ve not tried that – can anyone confirm that is working?
-
DT has more than pin info
There was a comment made in my other thread that effectively said that reading the pins from the eprom could be done, but that it was of minor value as the DT files handle more than pin configuration.
-
HDW pin init vs device driver loading
Being new to the DT stuff, I’ll accept 5) at face value. The additional info he mentioned as being handled in the DT file were device drivers.
Are there other things that DT is suppose to do also?
(where can one find a DT compiler input language syntax and semantics specification?)
I admit that I was thinking low level hardware pins in my orig post. I tend to think of device drivers as “the next layer up” and as part of the OS. I want my hardware to come up and be all configured for initial use (I tend to include internal eprom processing in the “hardware layer” viewpoint). A 2nd layer of abstraction is created when the OS device drivers are loaded.
With a DT source specifying both pin conifg and driver loads, it makes me wonder about what types of things need to be considered here?
I assume a DT file in an a eprom could end up referring to a device driver that no longer exists; What happens then?
Would (does?) cape manager just not load the driver or does it throw away the entire DT file as “invalid”?
Perhaps others could offer thought as to what need to be considered here.
Dave
