Device Tree Node Worthy?

[BrianBrelsford]

TOPIC:
Device Tree Node Worthy
I have a question on if my task/feature is device tree worthy, or if I am totally off base on its purpose.

HW:
We have a controller with an ARM core that is used on several different HW instantiations.
The FW image for each platform contains a large amount of common code, but each has a unique Kernel Device tree.

TASK:
The task at hand is determining the “reset cause”.
For debug purposes, and during Linux startup some code needs to know why it is booting.
There are actually ~10 different reason that we could have reset, examples are:
AC power up, User initiated, Watch dog timeout, external reset, etc.

HOW TO KNOW:
Some designs we read registers in the processor, and from a 8 bit CPLD bus.
Others we have a FPGA on a 32 bit bus, and some have a GPIO’s that we will need to read for more information.
So the various platforms have different HW/registers to access, which we then piece together to determine why we are here.

WAY #1:
One way is just put the code into a module that runs in early Linux and put the results in a sysfs file
Then at runtime have a switch or if/else that checks which platform we are currently running on, read and interpret the necessary HW/registers.

WAY#2:
Each of our platforms will have their own unique Kernel device tree.
Create a device tree node that has the registers, their bus widths, bit polarity, etc
Then startup code would read the data from this node, process the necessary registers, then determine the cause.
a) Data driven from device tree
b) Common code that processes it

QUESTIONS:
Is WAY#2 a misconception or bastardization of what device tree is for?

Since “reset_casue” is really a homegrown feature, it is not a normal processor initialization for the industry.
Is this type of feature what we want to KEEP OUT of device tree?



I would appreciate any guidance on these type of non-standard HW items.
Depending on the answer I might have more questions.

Thank you for your time
Brian Brelsford

[WarheadsSE]

This seems like like it comes down to your intent on mainlining your product's kernel support.

Assuming that you are intending to eventually mainline this series of products, I suggest going the DT route. This simplifies your code, and allows for that code to be able to handle future models without code updates. This saves time in the end for pin re-routes, etc.