In message 408CC565.9040006@intracom.gr you wrote:
I'm talking about how the loaded image/kernel gets access to the information.
At that point the variables are placed in RAM, and can contain every info that is present in the gd structure.
No. The interface to the (Linux) kernel is (at the moment, and for PowerPC) the bd_info structure. Plus the params passed in the registers like address and size of the ramdisk and the command line.
U-boot can continue to use the gd structure, but the application can access all it's configuration from the environment variables.
For example we can fill a environment variable with the system clock value at the later stages of initialization.
I do not like this idea. Think about the consequences. It will grow the environment, and "saveenv" would write all data to persisten storage. There are some boards where environment storage is really tight (like a 512 byte EEPROM). This would cause problems.
Also, it is conecptually not clean. Environment variables are meant as user (or at least manufacturer) configurable data which can be edited and changed. They are NOT intended for other purposes like storing data that is available otherwise. I know that this concept is not kept very strictly - for example, the "version" environment variable is IMHO bogus because the U-Boot version can be displayed with the "version" command - but then there was the (valid) request from users to check the U-Boot version from the running Linux system, so I gave in.
But please let's keep the environment as clean as possible.
What you are trying to do really asks for an implementation of bi_recs; if we had such a list of feature records you could easily do what you want to do. And we could even use this directly to pass all this information to Linux.
Best regards,
Wolfgang Denk