Wolfgang Grandegger wrote:
Timur Tabi wrote:
Wolfgang Grandegger wrote:
Then something similar to the ENV could be chosen:
CFG_FDT_ADDR CFG_FDT_IS_IN_FLASH CFG_FDT_IS_IN_xxx
We need two addresses:
- The address where the FDT is stored when the system is powered up
OK.
- The address in RAM where the FDT should be placed before Linux is
booted.
This should be some kind of default address.
Any default address is most likely board-specific. It would be nice if U-Boot could determine the best address automatically when possible.
Also be aware, that the blob can be within a uImage created with mkimage. Then the load address defined in the uImage should be used.
Yes.
You might be right. The _IS_IN_ is used for the ENV, I have to check what the rational behind it is (if there is one at all).
It's handy if you want to use the same macro to represent different types of addresses. Personally, I don't see much value in that. I would rather that a particular macro be used to represent only one kind of value. When I see CFG_FDT_ADDR_RAM, I know that the value is a virtual address that the CPU can dereference at any time.
I'm not sure if you understand the intended purpose. The address of the _initial_ blob could be stored in the env variable "fdtaddr" to select _one_ blob out of many in the FLASH.
Hmm....
I can see value in that, but then that variable can contain completely different addresses depending on the type of storage, which I don't like. Plus, I would rather that we use macro commands to set the FDT address, rather than an environment variable. This gives us more flexibility.
I tend to leave it up to the board specific code where and how to verify the FDT.
fdt_checkboard() *is* board-specific code.
There are already various entry points like checkboard() or
misc_init_r().
But this functions don't normally know where the FDT is. fdt_checkboard() would be designed specifically to validate an FDT from a board-specific point-of-view. It's good to have that code isolated from other board-specific code.