[U-Boot-Users] cache and buffer problems
Hi, I got a problem about cache and write buffer after I download the u-boot.bin to my board (s3c4510),I found that I can't erase the Flash (at49bv1614) any more ,so the u-boot is still running on my board I can't erase it . First I think it is caused by the Flash sector locked , but I check the status by software , it shows that it isn't be locked . So I think about write buffer and cache ,maybe my erase command cannot arrive flash,but in write buffer. from the datasheet ,it seems that s3c4510 can't close the cache while it is working untill system reset and clear the cache enable bit in SYSCFG register . but after reset ,u-boot enable cache again . plz tell me how to erase the flash or disable the cache. thx!
Hi, I wrote some emails with Daniel Hellstrom(sparc custodian) about new command, because he need space for new command around AMBA bus. And we did find problem in include/cmd_confdefs.c file.
Because command identification are 64bit value and U-BOOT has 63 commands now. We need extend unsigned long long value.
What proper solution is?
Best regards Michal Simek
In message 2572.4738-30809-160003137-1179312406@seznam.cz you wrote:
I wrote some emails with Daniel Hellstrom(sparc custodian) about new command, because he need space for new command around AMBA bus. And we did find problem in include/cmd_confdefs.c file.
Adding new commands is trivial per se.
Because command identification are 64bit value and U-BOOT has 63 commands now. We need extend unsigned long long value.
Unfortunately the C standard does not define any longer integer data types that can be used directly in the C preprocessor.
What proper solution is?
Get rid of the existing coee and come up with a completely new implementation. But this is a non-trivial task.
Best regards,
Wolfgang Denk
I wrote some emails with Daniel Hellstrom(sparc custodian) about new command,
because he need space for new command around AMBA bus. And we did find problem in include/cmd_confdefs.c file.
Adding new commands is trivial per se.
Yes, I know.
Because command identification are 64bit value and U-BOOT has 63 commands now. We need extend unsigned long long value.
Unfortunately the C standard does not define any longer integer data types that can be used directly in the C preprocessor.
What proper solution is?
Get rid of the existing coee and come up with a completely new implementation. But this is a non-trivial task.
Yes. I think that is the right time for discuss it and find completely new implementation because you cannot add new commands now.
Best regards, Michal Simek
On Wednesday, May 16, 2007 5:26 AM Wolfgang Denk:
Because command identification are 64bit value and U-BOOT has 63 commands now. We need extend unsigned long long value.
Unfortunately the C standard does not define any longer integer data types that can be used directly in the C preprocessor.
What proper solution is?
Get rid of the existing coee and come up with a completely new implementation. But this is a non-trivial task.
There is actually an approach in place, virtually converting single u-boot command into root of command tree. See for example how "nand" command (or shall I say "nand" tree?) is implemented. Wolfgang, do you approve this way of doing or it had sneaked into u-boot "illegally"?
Of course, this is only half-solution which can provide temporary relief. As a matter of fact, I'm using it myself for my proprietary commands.
In my mind, there are two (not mutually excluding) generic ways to proceed (backward compatibility will be preserved of course meaning old scripts will be still working).
1) Strictly hierarchical "CISCO-like" CLI instead of "flat" u-boot scheme. There are several existing implementations of such CLI which can be used.
2) Further advance of "bash"-like shell (hush is used in u-boot right now). Existing shell lacks many features one is used to see in Linux/Unix shells. It's highly questionable though whether it makes sense to add u-boot specific commands in there, making u-boot shell scripts incompatible with Linux ones.
Best regards,
Leonid.
Leonid wrote:
On Wednesday, May 16, 2007 5:26 AM Wolfgang Denk:
Because command identification are 64bit value and U-BOOT has 63 commands now. We need extend unsigned long long value.
Unfortunately the C standard does not define any longer integer data types that can be used directly in the C preprocessor.
What proper solution is?
Get rid of the existing coee and come up with a completely new implementation. But this is a non-trivial task.
There is actually an approach in place, virtually converting single u-boot command into root of command tree. See for example how "nand" command (or shall I say "nand" tree?) is implemented. Wolfgang, do you approve this way of doing or it had sneaked into u-boot "illegally"?
Of course, this is only half-solution which can provide temporary relief. As a matter of fact, I'm using it myself for my proprietary commands.
In my mind, there are two (not mutually excluding) generic ways to proceed (backward compatibility will be preserved of course meaning old scripts will be still working).
- Strictly hierarchical "CISCO-like" CLI instead of "flat" u-boot
scheme. There are several existing implementations of such CLI which can be used.
- Further advance of "bash"-like shell (hush is used in u-boot right
now). Existing shell lacks many features one is used to see in Linux/Unix shells. It's highly questionable though whether it makes sense to add u-boot specific commands in there, making u-boot shell scripts incompatible with Linux ones.
Best regards,
Leonid.
Hi Leonid,
I think you are missing the fundamental part of the problem: u-boot uses a #defined bitmap to enable and disable commands at compile time. The #defined bitmap can hold, at most, 64 bits and 63 of those bits are used. The fundamental limitation stems from the desire to enable/disable commands at compile time in conjunction with how many bits gcc (actually, the preprocessor) supports for #if conditional compilation. There are also implicit desires to use & and | to combine the #defined bit flags.
This has come up a couple of times, but no good solution has shaken out.
At one time I proposed simply creating a second set of 64 bit command enable/disable #defines, but Wolfgang wasn't too keen on that solution. I really cannot think of any other way to maintain the current method of compile-time selection and add expansion. Discussion thread here: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/24647
I personally sidestepped the issue by enabling and disabling my new "fdt" command based on whether CONFIG_OF_LIBFDT was defined or not, thereby not needing to use the last command control bit in the #define.
gvb
On Wednesday, May 16, 2007 11:42 AM Jerry Van Baren wrote:
I think you are missing the fundamental part of the problem: u-boot
uses
a #defined bitmap to enable and disable commands at compile time. The
#defined bitmap can hold, at most, 64 bits and 63 of those bits are used.
I am fully aware of that.
The fundamental limitation stems from the desire to enable/disable commands at compile time in conjunction with how many bits gcc (actually, the preprocessor) supports for #if conditional compilation. There are also implicit desires to use & and | to
combine
the #defined bit flags.
This has come up a couple of times, but no good solution has shaken
out.
At one time I proposed simply creating a second set of 64 bit command enable/disable #defines, but Wolfgang wasn't too keen on that
solution.
I really cannot think of any other way to maintain the current method
of compile-time selection and add expansion. Discussion thread here: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/24647
I agree.
I personally sidestepped the issue by enabling and disabling my new "fdt" command based on whether CONFIG_OF_LIBFDT was defined or not, thereby not needing to use the last command control bit in the
#define.
That can be another way of doing that.
Leonid.
In message 406A31B117F2734987636D6CCC93EE3C017BA168@ehost011-3.exch011.intermedia.net you wrote:
There is actually an approach in place, virtually converting single u-boot command into root of command tree. See for example how "nand" command (or shall I say "nand" tree?) is implemented. Wolfgang, do you approve this way of doing or it had sneaked into u-boot "illegally"?
It is perfectly OK where logical groups of commands exist where one command makes no sense without the other(s).
- Strictly hierarchical "CISCO-like" CLI instead of "flat" u-boot
scheme. There are several existing implementations of such CLI which can be used.
The CLI is not a problem here. We are talking about how to enable certain features or feature sets, or disable them.
- Further advance of "bash"-like shell (hush is used in u-boot right
Again, this has nothing to do with the current topic (although it is a perfectly legal qustion in itself).
now). Existing shell lacks many features one is used to see in Linux/Unix shells. It's highly questionable though whether it makes sense to add u-boot specific commands in there, making u-boot shell scripts incompatible with Linux ones.
You are off track. Adding commands is trivial. Just do it. The problem is how toadd commands in a way that they are not compiled at all when not explicitely selected in the board configuration.
Best regards,
Wolfgang Denk
participants (5)
-
chark_uboot＠126.com -
Jerry Van Baren -
Leonid -
Monstr＠seznam.cz -
Wolfgang Denk