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. 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.
Therefore, we can't have just CFG_FDT_ADDR. We need CFG_FDT_ADDR_xxxx
My vote is to have xxxx be the type of memory. So if CFG_FDT_ADDR_FLASH is defined to value X, that means that the FDT is stored in flash at address X. If CFG_FDT_ADDR_EEPROM is defined instead, then it means that FDT is located in EEPROM at address X.
This would eliminate the "CFG_FDT_IS_IN_xxx"-type macros, which I think are redundant.
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).
CFG_FDT_ADDR_BY_ENV: If defined, the env variable "fdtaddr" is looked up early in the boot and "fdt" is set accordingly. This allows to hold more than
I would rather that the FDT subsystem *set* the fdtaddr variable, instead of the other way around.
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.
CFG_FDT_ADDR_RAM: If defined, the blob is moved to RAM after relocation for further preparation or for performance reasons. "fdt" is re-set accordingly. The blob is then ready and in place for booting Linux. If CFG_FDT_ADDR_RAM is set to 0, the blob will be copied to a default location, e.g. before the initrd location.
I think we're going to have to always relocate the FDT to RAM. Considering the level of functionality that libfdt provides, and considering how much of that functionality depends on being able to write to the FDT, it makes sense to require it to be in RAM.
Good, and for booting the FDT must be in RAM anyhow.
"checkboard()" is a name that can mean anything. If the function is
The purpose of the function is to provide board-specific code that validates the FDT. The amount of checking performed is at the discretion of the function.
For example, checkboard() *should* compare the values in the board header file with the FDT to verify that the memory mappings map, for instance.
I tend to leave it up to the board specific code where and how to verify the FDT. There are already various entry points like checkboard() or misc_init_r().
Wolfgang.