[U-Boot-Users] dynamic setting of CONFIG_SYS_CLK_FREQ

[U-Boot-Users] dynamic setting of CONFIG_SYS_CLK_FREQ

[Kumar Gala]

I was wondering if there where an examples in the current u-boot source 
tree in which CONFIG_SYS_CLK_FREQ was determined dynamically.  I have a 
system in which I can read a config register on the board to let me 
know if the CONFIG_SYS_CLK_FREQ is 66Mhz or 33Mhz.  I was hoping to 
have the 16550 uart (and anything else) that needed CONFIG_SYS_CLK_FREQ 
grab it from a variable instead.

This is on an MPC85xx platform system.

thanks

- Kumar

[U-Boot-Users] dynamic setting of CONFIG_SYS_CLK_FREQ

[Wolfgang Denk]

In message <66FC73FC-9476-11D8-A48D-000393DBC2E8@motorola.com> you wrote:
> I was wondering if there where an examples in the current u-boot source 
> tree in which CONFIG_SYS_CLK_FREQ was determined dynamically.  I have a 

Not exactly for CONFIG_SYS_CLK_FREQ - but the TQM8xxL boards  contain
code to measure the input clock against the (known) 32kHz clock.

> system in which I can read a config register on the board to let me 
> know if the CONFIG_SYS_CLK_FREQ is 66Mhz or 33Mhz.  I was hoping to 
> have the 16550 uart (and anything else) that needed CONFIG_SYS_CLK_FREQ 
> grab it from a variable instead.

If you provide a suitable init fuction which sets the  value  in  the
global  data  section eraly enough, you can probably shortcut the use
of CONFIG_SYS_CLK_FREQ.

> This is on an MPC85xx platform system.

...or any other.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
"There are three principal ways to lose money: wine, women, and engi-
neers. While the first two are more pleasant, the third is by far the
more certain."                           - Baron Rothschild, ca. 1800

[U-Boot-Users] dynamic setting of CONFIG_SYS_CLK_FREQ

[Kumar Gala]

How bad would it be to do something like:

#define CONFIG_SYS_CLK_FREQ	(gd->sys_clk)

or is this what you meant by 'provide a suitable init fuction'

- kumar

On Apr 22, 2004, at 12:14 PM, Wolfgang Denk wrote:

> In message <66FC73FC-9476-11D8-A48D-000393DBC2E8@motorola.com> you 
> wrote:
>> I was wondering if there where an examples in the current u-boot 
>> source
>> tree in which CONFIG_SYS_CLK_FREQ was determined dynamically.  I have 
>> a
>
> Not exactly for CONFIG_SYS_CLK_FREQ - but the TQM8xxL boards  contain
> code to measure the input clock against the (known) 32kHz clock.
>
>> system in which I can read a config register on the board to let me
>> know if the CONFIG_SYS_CLK_FREQ is 66Mhz or 33Mhz.  I was hoping to
>> have the 16550 uart (and anything else) that needed 
>> CONFIG_SYS_CLK_FREQ
>> grab it from a variable instead.
>
> If you provide a suitable init fuction which sets the  value  in  the
> global  data  section eraly enough, you can probably shortcut the use
> of CONFIG_SYS_CLK_FREQ.
>
>> This is on an MPC85xx platform system.
>
> ...or any other.
>
>
> Best regards,
>
> Wolfgang Denk
>
> -- 
> Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
> Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
> "There are three principal ways to lose money: wine, women, and engi-
> neers. While the first two are more pleasant, the third is by far the
> more certain."                           - Baron Rothschild, ca. 1800

[U-Boot-Users] dynamic setting of CONFIG_SYS_CLK_FREQ

[VanBaren, Gerald]

The simplest way for shortcutting...

#define CONFIG_SYS_CLK_FREQ   get_clock_freq()

(writing of an acceptable get_clock_freq()is left as an exercize for the reader)

gvb


> -----Original Message-----
> From: u-boot-users-admin at lists.sourceforge.net
> [mailto:u-boot-users-admin at lists.sourceforge.net]On Behalf Of Wolfgang
> Denk
> Sent: Thursday, April 22, 2004 1:15 PM
> To: Kumar Gala
> Cc: U-Boot mailing list
> Subject: Re: [U-Boot-Users] dynamic setting of CONFIG_SYS_CLK_FREQ
>
>
> In message
> <66FC73FC-9476-11D8-A48D-000393DBC2E8@motorola.com> you wrote:
> > I was wondering if there where an examples in the current
> u-boot source
> > tree in which CONFIG_SYS_CLK_FREQ was determined
> dynamically.  I have a
>
> Not exactly for CONFIG_SYS_CLK_FREQ - but the TQM8xxL boards  contain
> code to measure the input clock against the (known) 32kHz clock.
>
> > system in which I can read a config register on the board to let me
> > know if the CONFIG_SYS_CLK_FREQ is 66Mhz or 33Mhz.  I was hoping to
> > have the 16550 uart (and anything else) that needed
> CONFIG_SYS_CLK_FREQ
> > grab it from a variable instead.
>
> If you provide a suitable init fuction which sets the  value  in  the
> global  data  section eraly enough, you can probably shortcut the use
> of CONFIG_SYS_CLK_FREQ.
>
> > This is on an MPC85xx platform system.
>
> ...or any other.
>
>
> Best regards,
>
> Wolfgang Denk
>
> --
> Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
> Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
> "There are three principal ways to lose money: wine, women, and engi-
> neers. While the first two are more pleasant, the third is by far the
> more certain."                           - Baron Rothschild, ca. 1800
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>



******************************************
The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege.  If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager.  Please do not copy it for any purpose, or disclose its contents to any other person.  The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company.  The recipient should check this e-mail and any attachments for the presence of viruses.  The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email.
******************************************

[U-Boot-Users] dynamic setting of CONFIG_SYS_CLK_FREQ

[Dan Malek]

Kumar Gala wrote:
> I was wondering if there where an examples in the current u-boot source 
> tree in which CONFIG_SYS_CLK_FREQ was determined dynamically.

Kinda.  The 8xx, 8260, and 8560 (that I know of), use the 'global_descriptor'
to hold clock information necessary for computing such things.  Their
serial drivers (among others) use the clock values to derive their
divisor clocks.

We should probably use this same model for other boards, and you could
just define CONFIG_SYS_CLK_FREQ to fetch this instead of making it
a fixed number.

Thanks.


	-- Dan

[U-Boot-Users] dynamic setting of CONFIG_SYS_CLK_FREQ

[Wolfgang Denk]

In message <89194C60-9482-11D8-9316-000393DBC2E8@motorola.com> you wrote:
> How bad would it be to do something like:
> 
> #define CONFIG_SYS_CLK_FREQ	(gd->sys_clk)

Thisi s perfectly legal.

> or is this what you meant by 'provide a suitable init fuction'

No. I meant: you can do something like the above, but you  must  make
sure  that  there  is  code  to  initialize gd->sys_clk before anyone
attempts to access it.

And BTW: sys_clk is not a member of the struct "gd".

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
        ... Hiroshima 45 ... Chernobyl 86 ... Windows 95 ...

[U-Boot-Users] dynamic setting of CONFIG_SYS_CLK_FREQ

[Kumar Gala]

thanks,

I realized that sys_clk is not defined, I was going to add it for 85xx 
since none of the other defines in gd currently represent the value. 
The other option would be to have a function return the proper 
frequency (as suggested earlier in the thread). Any suggestions as to 
which option would be preferred?

I'm able to initialize gd->sys_clk (CONFIG_SYS_CLK_FREQ) as the first 
thing done in board_early_init_f.

- kumar

On Apr 22, 2004, at 2:44 PM, Wolfgang Denk wrote:

> In message <89194C60-9482-11D8-9316-000393DBC2E8@motorola.com> you 
> wrote:
>> How bad would it be to do something like:
>>
>> #define CONFIG_SYS_CLK_FREQ	(gd->sys_clk)
>
> Thisi s perfectly legal.
>
>> or is this what you meant by 'provide a suitable init fuction'
>
> No. I meant: you can do something like the above, but you  must  make
> sure  that  there  is  code  to  initialize gd->sys_clk before anyone
> attempts to access it.
>
> And BTW: sys_clk is not a member of the struct "gd".
>
> Best regards,
>
> Wolfgang Denk
>
> -- 
> Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
> Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
>         ... Hiroshima 45 ... Chernobyl 86 ... Windows 95 ...

[U-Boot-Users] dynamic setting of CONFIG_SYS_CLK_FREQ

[Wolfgang Denk]

In message <6A9BF178-9496-11D8-9316-000393DBC2E8@motorola.com> you wrote:
> 
> I realized that sys_clk is not defined, I was going to add it for 85xx 
> since none of the other defines in gd currently represent the value. 

Do we really need this value? Please keep "gd"  free  from  redundand
values,  i.  e. from data which can be derived/calculated easily from
other variables.

> The other option would be to have a function return the proper 
> frequency (as suggested earlier in the thread). Any suggestions as to 
> which option would be preferred?

The function approach sounds cleaner to me.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
It is more rational to sacrifice one life than six.
	-- Spock, "The Galileo Seven", stardate 2822.3

[U-Boot-Users] dynamic setting of CONFIG_SYS_CLK_FREQ

[Pantelis Antoniou]

Wolfgang Denk wrote:

>In message <6A9BF178-9496-11D8-9316-000393DBC2E8@motorola.com> you wrote:
>
>>I realized that sys_clk is not defined, I was going to add it for 85xx 
>>since none of the other defines in gd currently represent the value. 
>>
>
>Do we really need this value? Please keep "gd"  free  from  redundand
>values,  i.  e. from data which can be derived/calculated easily from
>other variables.
>
>
>>The other option would be to have a function return the proper 
>>frequency (as suggested earlier in the thread). Any suggestions as to 
>>which option would be preferred?
>>
>
>The function approach sounds cleaner to me.
>
>
>Best regards,
>
>Wolfgang Denk
>
>
IMHO the gd data are pretty much useless in a complicated environment.

For example when you have multiple network interfaces you have no
information which network interface was used to obtain the configuration,
which was it's ethernet address etc.

For me the gd is usefull only for the simple case of most boards with
one network interface, fixed clock etc.

For anything more complicated is better to parse the environment variables.

Some information however is only available in the gd, for example the 
clocks.

Why don't we just add the missing information to the environment variables?

Regards

Pantelis

[U-Boot-Users] dynamic setting of CONFIG_SYS_CLK_FREQ

[Wolfgang Denk]

In message <408CAD48.4020004@intracom.gr> you wrote:
> 
> IMHO the gd data are pretty much useless in a complicated environment.

Agreed. But that's not what they were meant for.

The gd data is intended to store the absolute  minimum  of  rwritable
date  which  is  really  unavoidable to be stored in global variables
until the RAM has been initialized and a standard  data  segment  and
stack are available.

> For example when you have multiple network interfaces you have no
> information which network interface was used to obtain the configuration,
> which was it's ethernet address etc.

This is something which can easily be done after relocation  to  RAM,
so there is no need to use gd for this purpose.

> For me the gd is usefull only for the simple case of most boards with
> one network interface, fixed clock etc.

No. This is NOT the intention.

> For anything more complicated is better to parse the environment variables.

In the end we will probably have something like bi_recs ...

> Why don't we just add the missing information to the environment variables?

Because you cannot access envrionment in  very  early  initialization
steps,  or you have to do it in a very slow way (like reading byte by
byte from serial EEPROM), which would horribly slow down boot.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
I have a theory that it's impossible to prove anything, but  I  can't
prove it.

[U-Boot-Users] dynamic setting of CONFIG_SYS_CLK_FREQ

[Pantelis Antoniou]

Wolfgang Denk wrote:

>In message <408CAD48.4020004@intracom.gr> you wrote:
>
>>IMHO the gd data are pretty much useless in a complicated environment.
>>
>
>Agreed. But that's not what they were meant for.
>
>The gd data is intended to store the absolute  minimum  of  rwritable
>date  which  is  really  unavoidable to be stored in global variables
>until the RAM has been initialized and a standard  data  segment  and
>stack are available.
>
>
>>For example when you have multiple network interfaces you have no
>>information which network interface was used to obtain the configuration,
>>which was it's ethernet address etc.
>>
>
>This is something which can easily be done after relocation  to  RAM,
>so there is no need to use gd for this purpose.
>
>
>>For me the gd is usefull only for the simple case of most boards with
>>one network interface, fixed clock etc.
>>
>
>No. This is NOT the intention.
>
>
>>For anything more complicated is better to parse the environment variables.
>>
>
>In the end we will probably have something like bi_recs ...
>
>
>>Why don't we just add the missing information to the environment variables?
>>
>
>Because you cannot access envrionment in  very  early  initialization
>steps,  or you have to do it in a very slow way (like reading byte by
>byte from serial EEPROM), which would horribly slow down boot.
>
>
Correct.

But I'm not talking about the early initialization.

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.

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.

>Best regards,
>
>Wolfgang Denk
>
>
Regards

Pantelis

[U-Boot-Users] dynamic setting of CONFIG_SYS_CLK_FREQ

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
GUIs  are  virtually  useless.  Learn  tools.  They're  configurable,
scriptable, automatable, cron-able, interoperable, etc. We don't need
no brain-dead winslurping monolithic claptrap.
                               -- Tom Christiansen in 371140df at csnews

[U-Boot-Users] dynamic setting of CONFIG_SYS_CLK_FREQ

[Pantelis Antoniou]

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

[U-Boot-Users] dynamic setting of CONFIG_SYS_CLK_FREQ

[Wolfgang Denk]

In message <408CE1D9.1080201@intracom.gr> you wrote:
> 
> We can do the same with environment variables.
> 
> Let's partition the variables to two categories.

I see what you mean. But it might be not as easy.

> 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.

Well, but how do you present it to the user? Will "printenv" show all
variables mixed? So how does the user know which get saved and  which
not?  How  do  you  merge  both  with  the standard CLI and hush in a
consistent way? And allthis without  (significantly)  increasing  the
memory footprint _and_ keeping the code readable?

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

Good idea.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
I paid too much for it, but its worth it.

[U-Boot-Users] dynamic setting of CONFIG_SYS_CLK_FREQ

[Pantelis Antoniou]

Wolfgang Denk wrote:

>In message <408CE1D9.1080201@intracom.gr> you wrote:
>
>>We can do the same with environment variables.
>>
>>Let's partition the variables to two categories.
>>
>
>I see what you mean. But it might be not as easy.
>
>
>>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.
>>
>
>Well, but how do you present it to the user? Will "printenv" show all
>variables mixed? So how does the user know which get saved and  which
>not?  How  do  you  merge  both  with  the standard CLI and hush in a
>consistent way? And allthis without  (significantly)  increasing  the
>memory footprint _and_ keeping the code readable?
>
>
Well, will the user care?

Why should he know that the version or the clock variable is real?
If he tries to change a read only variable it should be denied.
If the variable is writable the action should take place immediately.
If the action should be persistent it should be saved to storage.

Since the variables are present at RAM but not in persistent storage
the size of the environment is the same. As for the code footprint
this is debatable. If someone needs this "feature" he can enable
it explicitly. If not enabled everything should work as it were.


>>As for the state of Linux, we can try to migrate 2.6 to
>>this interface.
>>
>
>Good idea.
>
>Best regards,
>
>Wolfgang Denk
>
>
Regards

Pantelis

[U-Boot-Users] dynamic setting of CONFIG_SYS_CLK_FREQ

[Wolfgang Denk]

In message <408CF369.9050907@intracom.gr> you wrote:
>
> >Well, but how do you present it to the user? Will "printenv" show all
> >variables mixed? So how does the user know which get saved and  which
> >not?  How  do  you  merge  both  with  the standard CLI and hush in a
> >consistent way? And allthis without  (significantly)  increasing  the
> >memory footprint _and_ keeping the code readable?
> >
> >
> Well, will the user care?

I hope you are joking here. Of course he will.

> Why should he know that the version or the clock variable is real?

He  must  know  which  variables  are  available  when  reading   the
environment  under Linux. He must know which variables can be changed
(with the changes showing some effect). Etc. etc.

> If he tries to change a read only variable it should be denied.

Per definitionem there should be no variables in the environment that
cannot be changed. Period.

I know that there is the big exception of "ver" (I had a weak  moment
when  I  alloed  for  that),  and there are the smaller exceptions of
serial# end ethaddr which are settable  only  once  (usually  by  the
vendor), but this is at least configurable.

> Since the variables are present at RAM but not in persistent storage
> the size of the environment is the same. As for the code footprint
> this is debatable. If someone needs this "feature" he can enable
> it explicitly. If not enabled everything should work as it were.

I think the concept of environment variables as we  have  so  far  is
conceptually  pretty  clean.  What you suggest is different, and does
not fit. That does NOT mean that your idea is bad - not at  all.  BUt
such  "automatic"  variables must be kept separated from the environ-
ment. They shall not be  mixed  in  the  display  of  the  "printenv"
command, and not be settable by "setenv".

Please feel free to implement new "printvar" and "setvar" commands as
optional extension, but I really don't see that much benefit. Already
now it is pretty ifficult to find a variable definition  in  a  long,
multi-page "printenv" output.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
You can observe a lot just by watchin'.                  - Yogi Berra

[U-Boot-Users] dynamic setting of CONFIG_SYS_CLK_FREQ

[Pantelis Antoniou]

Wolfgang Denk wrote:

>In message <408CF369.9050907@intracom.gr> you wrote:
>
>>>Well, but how do you present it to the user? Will "printenv" show all
>>>variables mixed? So how does the user know which get saved and  which
>>>not?  How  do  you  merge  both  with  the standard CLI and hush in a
>>>consistent way? And allthis without  (significantly)  increasing  the
>>>memory footprint _and_ keeping the code readable?
>>>
>>>
>>>
>>Well, will the user care?
>>
>
>I hope you are joking here. Of course he will.
>
>
We have a different definition of a "user" in mind it seems.
Your users appear to be much more technical inclined than mine...

>>Why should he know that the version or the clock variable is real?
>>
>
>He  must  know  which  variables  are  available  when  reading   the
>environment  under Linux. He must know which variables can be changed
>(with the changes showing some effect). Etc. etc.
>
>
>>If he tries to change a read only variable it should be denied.
>>
>
>Per definitionem there should be no variables in the environment that
>cannot be changed. Period.
>
>I know that there is the big exception of "ver" (I had a weak  moment
>when  I  alloed  for  that),  and there are the smaller exceptions of
>serial# end ethaddr which are settable  only  once  (usually  by  the
>vendor), but this is at least configurable.
>
>
Ideological purity is a worthy endeavor.
The real world has different things in mind.

>>Since the variables are present at RAM but not in persistent storage
>>the size of the environment is the same. As for the code footprint
>>this is debatable. If someone needs this "feature" he can enable
>>it explicitly. If not enabled everything should work as it were.
>>
>
>I think the concept of environment variables as we  have  so  far  is
>conceptually  pretty  clean.  What you suggest is different, and does
>not fit. That does NOT mean that your idea is bad - not at  all.  BUt
>such  "automatic"  variables must be kept separated from the environ-
>ment. They shall not be  mixed  in  the  display  of  the  "printenv"
>command, and not be settable by "setenv".
>
>Please feel free to implement new "printvar" and "setvar" commands as
>optional extension, but I really don't see that much benefit. Already
>now it is pretty ifficult to find a variable definition  in  a  long,
>multi-page "printenv" output.
>
>
>
Hmm, do I see a grep in the future? ;).

>Best regards,
>
>Wolfgang Denk
>
>
Anyway, this discussion is pretty academic at the moment.
We'll cross this bridge when we get there.

Regards

Pantelis

[U-Boot-Users] dynamic setting of CONFIG_SYS_CLK_FREQ

[Wolfgang Denk]

In message <408D0DC6.1050602@intracom.gr> you wrote:
>
> We have a different definition of a "user" in mind it seems.
> Your users appear to be much more technical inclined than mine...

Every user is a user. User includes you and me. Butyes, we train  our
users to really emply the features of U-Boot, and many of them do. In
some  cases  I  was astonished myself to see what can be done by some
tricky environment definitions in combination with other features  in
U-Boot.

> Ideological purity is a worthy endeavor.
> The real world has different things in mind.

Maybe. But there is no reason that some perfectly  valid  real  world
requirements  should  be  implemented in a way that breaks the design
rules. I think this can be done in a clean way, too. And it  is  part
of my role as maintainer to keep an eye on clean design and code.

> >optional extension, but I really don't see that much benefit. Already
> >now it is pretty ifficult to find a variable definition  in  a  long,
> >multi-page "printenv" output.
> >
> >
> Hmm, do I see a grep in the future? ;).

Probably not.

What Detlev Zundel and me have been discussing was the idea to create
logical  groups  of  environment  variables,  like  network   related
(ipaddr,  serverip,  netmask, ethaddr, hostname, ...), boot arguments
stuff, etc. We think that the capabilities of  environment  variables
would  be much easier to understand if variables that belong together
logically are printed together, too. We  put  this  discussion  to  a
(temporary)  rest  when  it became clear that we could not think of a
clever way to implement such groups  without  breaking  compatibility
with the existing storage format of the environment.

> Anyway, this discussion is pretty academic at the moment.

But very useful, I think.

> We'll cross this bridge when we get there.

Agreed.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Of all the things I've lost, I miss my mind the most.