[U-Boot-Users] idea: fdt_checkboard

[U-Boot-Users] idea: fdt_checkboard

[Timur Tabi]

Jerry,

What do you think about implementing a board-specific function called "fdt_checkboard()"? 
  On platforms that have this function, it would be called by fdt_open_into(). 
fdt_checkboard() would scan the device tree and make sure that it's the right tree for 
this board (e.g. by checking the 'model' or 'compatible' fields), and return an error if 
it's not.

This would be helpful in eliminating the possibility of accidentally using the wrong 
device tree.  It could happen, for instance, if there are multiple device trees for a 
given board.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] idea: fdt_checkboard

[Jerry Van Baren]

Timur Tabi wrote:
> Jerry,
> 
> What do you think about implementing a board-specific function called 
> "fdt_checkboard()"?  On platforms that have this function, it would be 
> called by fdt_open_into(). fdt_checkboard() would scan the device tree 
> and make sure that it's the right tree for this board (e.g. by checking 
> the 'model' or 'compatible' fields), and return an error if it's not.
> 
> This would be helpful in eliminating the possibility of accidentally 
> using the wrong device tree.  It could happen, for instance, if there 
> are multiple device trees for a given board.

Hi Timur,

I would rather give hush the ability to read fdt properties so that the 
logic could be scripted rather than being "hardcoded" in a C function. 
This would give some interesting capabilities, like selecting the proper 
fdt out of several in memory.

Unfortunately I'm spouting off out of ignorance, I don't know at this 
point how much effort it would take to give hush the ability to test fdt 
properties.

Best regards,
gvb

[U-Boot-Users] idea: fdt_checkboard

[Wolfgang Grandegger]

Jerry Van Baren wrote:
> Timur Tabi wrote:
>> Jerry,
>>
>> What do you think about implementing a board-specific function called 
>> "fdt_checkboard()"?  On platforms that have this function, it would be 
>> called by fdt_open_into(). fdt_checkboard() would scan the device tree 
>> and make sure that it's the right tree for this board (e.g. by checking 
>> the 'model' or 'compatible' fields), and return an error if it's not.
>>
>> This would be helpful in eliminating the possibility of accidentally 
>> using the wrong device tree.  It could happen, for instance, if there 
>> are multiple device trees for a given board.
> 
> Hi Timur,
> 
> I would rather give hush the ability to read fdt properties so that the 
> logic could be scripted rather than being "hardcoded" in a C function. 
> This would give some interesting capabilities, like selecting the proper 
> fdt out of several in memory.
> 
> Unfortunately I'm spouting off out of ignorance, I don't know at this 
> point how much effort it would take to give hush the ability to test fdt 
> properties.

Such scripting capabilities might be nice to have but first we need 
something more basic. We should also keep in mind that the FDT will be 
used to configure U-Boot from the early beginning. In this context a 
board specific "fdt_checkboard" function would make sense, but I prefer 
that it's already called when an address is assigned to the blob.

Wolfgang.

[U-Boot-Users] idea: fdt_checkboard

[Timur Tabi]

Jerry Van Baren wrote:

> I would rather give hush the ability to read fdt properties so that the 
> logic could be scripted rather than being "hardcoded" in a C function. 
> This would give some interesting capabilities, like selecting the proper 
> fdt out of several in memory.

The two really aren't mutually exclusive.  Besides, fdt_checkboard() would not work in a 
hush script.  The C function would scan the device tree *and* read data from the hardware 
and compare the two.  For instance, if it says that there's a PCI device at address X, it 
should check if CFG_PCI1_MEM_PHYS is set to the same value.  These are the kinds of things 
that can only be done in C code.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale