[U-Boot-Users] dynamic setting of CONFIG_SYS_CLK_FREQ

Pantelis Antoniou
2004-04-26T10:18:01Z

Wolfgang Denk wrote:

>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.
>
>
I'm not talking just about Linux. And don't get me started
about the mess which is the current bd_info structure.

>>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.
>
>
We can do the same with environment variables.

Let's partition the variables to two categories.

One will be the normal variables as we have now.
The other we can refer to them as phantom variables;
they are never written to persistant storage but live in
RAM only. The version variable you refer is one of them.

IMHO it's a more consistent interface.

As for the state of Linux, we can try to migrate 2.6 to
this interface.

>Best regards,
>
>Wolfgang Denk
>
>
Regards

Pantelis