[U-Boot-Users] dynamic setting of CONFIG_SYS_CLK_FREQ

[Pantelis Antoniou <panto@intracom.gr>]

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