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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20070516/dd6741af/attachment.htm
[U-Boot-Users] New commands
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
[U-Boot-Users] New commands
Quoted 2 lines · In message <[email protected]> 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.cfile.
Adding new commands is trivial per se.
Quoted 2 lines
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.
Quoted 1 line
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
Signature · 6 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de They're usually so busy thinking about what happens next that the only time they ever find out what is happening now is when they come to look back on it. - Terry Pratchett, _Wyrd Sisters_
[U-Boot-Users] New commands
Quoted 5 lines
Quoted 1 line
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.cfile.Adding new commands is trivial per se.
Yes, I know.
Quoted 10 lines
Quoted 2 lines
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.
Quoted 1 line
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
[U-Boot-Users] New commands
In reply to Wolfgang DenkOn Wednesday, May 16, 2007 5:26 AM Wolfgang Denk:
Quoted 11 lines
Quoted 3 lines
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.
Quoted 1 line
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.
[U-Boot-Users] New commands
Quoted 36 lines · Leonid
On Wednesday, May 16, 2007 5:26 AM Wolfgang Denk:
Quoted 11 lines
Quoted 3 lines
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.
Quoted 1 line
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.
Quoted 3 lines
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
[U-Boot-Users] New commands
Quoted 1 line · Jerry Van Baren
I think you are missing the fundamental part of the problem: u-boot
uses
Quoted 4 lines
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.
Quoted 4 lines
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
Quoted 3 lines
the #defined bit flags.
This has come up a couple of times, but no good solution has shaken
out.
Quoted 2 lines
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.
Quoted 4 lines
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.
Quoted 3 lines
I personally sidestepped the issue by enabling and disabling my new "fdt" command based on whether
CONFIG_OF_LIBFDTwas 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.
[U-Boot-Users] New commands
In reply to LeonidQuoted 5 lines · In message <406A31B117F2734987636D6CCC93EE3C017BA168@ehost011-3.exch011.interme…
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).
Quoted 3 lines
1) 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.
Quoted 1 line
2) 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).
Quoted 4 lines
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
Signature · 4 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Is the glass half empty, half full, or twice as large as it needs to