[U-Boot-Users] dynamic setting of CONFIG_SYS_CLK_FREQ
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
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
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@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
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
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@denx.de ... Hiroshima 45 ... Chernobyl 86 ... Windows 95 ...
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
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
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
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
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
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
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
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
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
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
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
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
participants (4)
-
Dan Malek -
Kumar Gala -
Pantelis Antoniou -
Wolfgang Denk