[U-Boot-Users] cache and buffer problems

[U-Boot-Users] cache and buffer problems

[chark_uboot at 126.com]

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

[Monstr at seznam.cz]

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

[Wolfgang Denk]

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

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

[Monstr at seznam.cz]

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

[U-Boot-Users] New commands

[Leonid]

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.

[U-Boot-Users] New commands

[Jerry Van Baren]

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

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

[Leonid]

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.

[U-Boot-Users] New commands

[Wolfgang Denk]

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

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

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

> 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

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