idea: fdt_checkboard
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.
Signature · 2 lines
Timur Tabi Linux Kernel Developer @ Freescale
Quoted 11 lines · 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 byfdt_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
Quoted 15 lines · Jerry Van Baren
Quoted 11 lines · 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 byfdt_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,
Quoted 8 lines
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.
Quoted 4 lines · Jerry Van Baren
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.
Signature · 2 lines
Timur Tabi Linux Kernel Developer @ Freescale