[U-Boot-Users] u-boot hanging

[U-Boot-Users] u-boot hanging

[Ram]

Hi,
 I had posted a query regarding hanging of u-boot when a return is made from
a standalone application.

 Does this have anything to do with the size of the standalone application?.
Should i specify that somewhere?.

 Is there a maximum size of an App.


 hello_world example works fine for me. However when i do the return from my
custom standalone application, u-boot hangs.

 This behaviour happens 7 out of 10 times. (Sometimes, it works well, most
times it doesnt).

 Do we need to do something "Special" before returning back?.

 Please do advice.

 All im doing is

  while (!tstc())
                ;
  ch = getc ( );
  printf ("Returning\n") ;

  return (0) ;



Regards,
 sriram
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20061117/1bbf1aeb/attachment.htm 

[U-Boot-Users] 16BIT SPANSION Flash writing problem with CFI Driver

[Sam Song]

Hi all,

I have a customized 8548 board which has a SPASION 
S29GL064M11TFIR2, 8Mbyte, in 16-bit mode. When I 
use CFI driver, Flash is detected well and erase
operation is OK but programming failed as follows.

MPC8548E_Rev1.1=> save
Saving Environment to Flash...
Un-Protected 1 sectors
Erasing Flash...
. done
Erased 1 sectors
Writing to Flash...

After a reset, I could get:

U-Boot 1.1.4 (Nov 17 2006 - 19:36:55), Build:
mini-1.1.2

CPU:   8548_E, Version: 1.1, (0x80390011)
Core:  e500v2, Version: 1.0, (0x80210010)
Clock Configuration:
       CPU: 999 MHz, CCB: 399 MHz,
       DDR: 199 MHz, LBC:  24 MHz
L1:    D-cache 32 kB enabled
       I-cache 32 kB enabled
[...]
DDR:   512 MB
SDRAM test phase 1:
SDRAM test phase 2:
SDRAM test passed.
Now running in RAM - U-Boot at: 1ffe0000
FLASH:  8 MB
L2 cache 512KB: enabled
In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0
MPC8548E_Rev1.1=> fli

Bank # 1: CFI conformant FLASH (16 x 16)  Size: 8 MB
in 128 Sectors
 Erase timeout 16384 ms, write timeout 0 ms, buffer
write timeout 4096 ms, buffer size 32
  Sector Start Addresses:
 FF800000      FF810000      FF820000      FF830000   
  
 [snip]
 FFFD0000  RO  FFFE0000  RO  FFFF0000  RO
MPC8548E_Rev1.1=>

It seems that ENV saving operation is OK but not
work for a big file like 600K programming. It 
just hanged there forever.

What could be the problem be? I use the CFI driver
from GIT repository on Nov. 2.

Thanks in advance,

Sam


		
___________________________________________________________ 
??????-3.5G???20M?? 
http://cn.mail.yahoo.com/

[U-Boot-Users] 16BIT SPANSION Flash writing problem with CFI Driver

[Tolunay Orkun]

Sam,

There is not enough information from your email. Still, I have a few
comments.

Sam Song wrote:

> MPC8548E_Rev1.1=> save
> Saving Environment to Flash...
> Un-Protected 1 sectors
> Erasing Flash...
> . done
> Erased 1 sectors
> Writing to Flash...

Did you verify that you have correct data in environment after save? Try
changing something in environment (or add a dummy environment variable)
and save and check.

> Bank # 1: CFI conformant FLASH (16 x 16)  Size: 8 MB
> in 128 Sectors
>  Erase timeout 16384 ms, write timeout 0 ms, buffer
> write timeout 4096 ms, buffer size 32

Looks like your flash part does not support single word writes via
conventional interface (write timeout is 0). It must use buffered
writes. Did you enable buffer writes? You probably did but just double
checking...

> It seems that ENV saving operation is OK but not
> work for a big file like 600K programming. It 
> just hanged there forever.

Did you enable debug? What was the exact command you used to copy data
to flash. Did you use cp.b or just cp? If you used cp did you use the
length in bytes or words (note that cp is equivalent to cp.l)

> What could be the problem be? I use the CFI driver
> from GIT repository on Nov. 2.

I recently submitted a patch for AMD style flashes but it addresses top
boot flash geometry reversal. Your flash is uniform sectored. So, it is
not necessary.

Best regards,
Tolunay

[U-Boot-Users] 16BIT SPANSION Flash writing problem with CFI Driver

[Sam Song]

Tolunay Orkun <listmember@orkun.us> wrote:
> Sam,
> 
> There is not enough information from your email.

Tolunay, thanks. I added some info below.
......
> 
> Did you verify that you have correct data in
> environment after save? Try

I checked that and saw 'test=1' in new env parameters
after reset. 

> > Bank # 1: CFI conformant FLASH (16 x 16)  Size: 8
> > MB in 128 Sectors Erase timeout 16384 ms, write 
> > timeout 0 ms, buffer write timeout 4096 ms, 
> > buffer size 32
> 
> Looks like your flash part does not support single
> word writes via conventional interface 
> (write timeout is 0). It must use buffered
> writes. Did you enable buffer writes? You probably
> did but just double checking...

I didn't enable buffer writes. Once I defined
CFG_FLASH_USE_BUFFER_WRITE, all save operations
would encounter an error. Actually, I noticed
it was unaccptable to enable buffer write for
AMD flash.

MPC8548E_Rev1.1=> save
Saving Environment to Flash...
Un-Protected 1 sectors
Erasing Flash...
. done
Erased 1 sectors
Writing to Flash... Outside available Flash
Protected 1 sectors
MPC8548E_Rev1.1=>

> Did you enable debug? What was the exact command you
> used to copy data to flash. Did you use cp.b or just


After enable debug in CFI, extra message obtained.

U-Boot 1.1.4 (Nov 19 2006 - 15:55:24), Build:
[......]
Now running in RAM - U-Boot at: 0ffe0000
FLASH: flash detect cfi
fwc addr ff800000 cmd 0 0 8bit x 8 bit
fwc addr ff800055 cmd 98 98 8bit x 8 bit
is= cmd 51(Q) addr ff800010 is= 0 51
fwc addr ff800000 cmd 0 0000 16bit x 8 bit
fwc addr ff8000aa cmd 98 9898 16bit x 8 bit
is= cmd 51(Q) addr ff800020 is= 0051 5151
fwc addr ff800000 cmd 0 0000 16bit x 16 bit
fwc addr ff8000aa cmd 98 0098 16bit x 16 bit
is= cmd 51(Q) addr ff800020 is= 0051 0051
is= cmd 52(R) addr ff800022 is= 0052 0052
is= cmd 59(Y) addr ff800024 is= 0059 0059
ushort addr is at ff800050 info->portwidth = 2
addr[0] = 0x0
addr[1] = 0x2
addr[2] = 0x0
addr[3] = 0x0
retval = 0x2
device interface is 2
found port 2 chip 2 port 16 bits chip 16 bits
ushort addr is at ff800026 info->portwidth = 2
addr[0] = 0x0
addr[1] = 0x2
addr[2] = 0x0
addr[3] = 0x0
retval = 0x2
ff800020 : 00 51 00 52 00 59 00 02 00 00 00 40 00 00
00 00  .Q.R.Y..... at ....
ff800030 : 00 00 00 00 00 00 00 27 00 36 00 00 00 00
00 07  .......'.6......
ff800040 : 00 07 00 0a 00 00 00 01 00 05 00 04 00 00
00 17  ................
ff800050 : 00 02 00 00 00 05 00 00 00 01 00 7f 00 00
00 00  ................
ff800060 : 00 01 00 00 00 00 00 00 00 00 00 00 00 00
00 00  ................
ff800070 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00  ................
ff800080 : 00 50 00 52 00 49 00 31 00 33 00 08 00 02
00 01  .P.R.I.1.3......
ff800090 : 00 01 00 04 00 00 00 00 00 01 00 b5 00 c5
00 04  ................
manufacturer is 2
size_ratio 1 port 16 bits chip 16 bits
found 1 erase regions
long addr is at ff80005a info->portwidth = 2
addr[0] = 0x0
addr[1] = 0x7f
addr[2] = 0x0
addr[3] = 0x0
addr[4] = 0x0
addr[5] = 0x0
addr[6] = 0x0
addr[7] = 0x1
erase_region_count = 128 erase_region_size = 65536
ushort addr is at ff800054 info->portwidth = 2
addr[0] = 0x0
addr[1] = 0x5
addr[2] = 0x0
addr[3] = 0x0
retval = 0x5
fwc addr ff800000 cmd f0 00f0 16bit x 16 bit
 8 MB
L2 cache 512KB: enabled
......
MPC8548E_Rev1.1=> erase ffa00000 ffafffff
......
flash_is_busy: 0
.fwc addr ffaf0aaa cmd aa 00aa 16bit x 16 bit
fwc addr ffaf0554 cmd 55 0055 16bit x 16 bit
fwc addr ffaf0aaa cmd 80 0080 16bit x 16 bit
fwc addr ffaf0aaa cmd aa 00aa 16bit x 16 bit
fwc addr ffaf0554 cmd 55 0055 16bit x 16 bit
fwc addr ffaf0000 cmd 30 0030 16bit x 16 bit
flash_is_busy: 1
flash_is_busy: 1
......
flash_is_busy: 1
flash_is_busy: 1
flash_is_busy: 1
flash_is_busy: 0
. done
Erased 16 sectors
MPC8548E_Rev1.1=> cp.b 1000000 ffa00000 40000
......
flash_is_busy: 1
flash_is_busy: 0
fwc addr ff800aaa cmd aa 00aa 16bit x 16 bit
fwc addr ff800554 cmd 55 0055 16bit x 16 bit
fwc addr ff800aaa cmd a0 00a0 16bit x 16 bit
flash_is_busy: 1
flash_is_busy: 0
fwc addr ff800aaa cmd aa 00aa 16bit x 16 bit
fwc addr ff800554 cmd 55 0055 16bit x 16 bit
fwc addr ff800aaa cmd a0 00a0 16bit x 16 bit
......

After 20 minutes or so, have to reset it to 
stop the debug loop...

MPC8548E_Rev1.1=> cmp 1000000 ffa00000 40000
word at 0x01023b3c (0x40a2ff74) != word at 0xffa23b3c
(0x40a2ffff)
Total of 36559 words were the same
MPC8548E_Rev1.1=>

I once programmed a 128KB file sucessfully but never
for 256KB or above.

> > What could be the problem be? I use the CFI driver
> > from GIT repository on Nov. 2.
> 
> I recently submitted a patch for AMD style flashes
> but it addresses top boot flash geometry reversal. 
> Your flash is uniform sectored. So, it is not
> necessary.

That's really a nice work. Some more boards flash
driver in U-Boot tree can be switched to CFI Driver
like RPXlite's, I think.

Thanks again,

Sam


		
___________________________________________________________ 
????????-3.5G???20M??? 
http://cn.mail.yahoo.com

[U-Boot-Users] 16BIT SPANSION Flash writing problem with CFI Driver

[Tolunay Orkun]

Sam Song wrote:
>>> Bank # 1: CFI conformant FLASH (16 x 16)  Size: 8
>>> MB in 128 Sectors Erase timeout 16384 ms, write 
>>> timeout 0 ms, buffer write timeout 4096 ms, 
>>> buffer size 32
>>>       
>> Looks like your flash part does not support single
>> word writes via conventional interface 
>> (write timeout is 0). It must use buffered
>> writes. Did you enable buffer writes? You probably
>> did but just double checking...
>>     
>
> I didn't enable buffer writes. Once I defined
> CFG_FLASH_USE_BUFFER_WRITE, all save operations
> would encounter an error. Actually, I noticed
> it was unaccptable to enable buffer write for
> AMD flash.
>   

I guess you can implement CFG_FLASH_USE_BUFFER_WRITE for AMD style
flash. The details is in the datasheet. It should speed up the
programming anyway.

Here is the datasheet:
http://www.spansion.com/datasheets/s29gl-m_00_b6_e.pdf

Since you are able to write small amounts of data successfully, it means
that either timeout or status processing is not quite correct. For
non-buffered writes I believe the write timeout of 0 may be the problem.
Typically these values are set to 0 if the feature is not supported but
the datasheet gives program sequence as well. Please override the data
read from CFI regarding write timeout with a non zero value (say 1ms
timeout) and see what happens. Perhaps, they set the timeout to 0
because they want the process to be completely driven by DQ7 bits. When
timeout is 0 we might be bypassing the DQ7 toggle check so verify the
path is working as expected. Finally, they have toggle/operations
defined for other DQ bits in additon to DQ7. It might be necessary to
monitor other bits as well for a successful completion. You might need
to verify that as well.

Test your flash writes with debug turned off. Debugging code interferes
in my Intel flash boards and cp fails.

Good luck,
Tolunay

[U-Boot-Users] 16BIT SPANSION Flash writing problem with CFI Driver

[Sam Song]

Tolunay Orkun <listmember@orkun.us> wrote:

> Here is the datasheet:
>
http://www.spansion.com/datasheets/s29gl-m_00_b6_e.pdf
> 

Got it. I will try it when available.

> non-buffered writes I believe the write timeout of 0
> may be the problem. Typically these values are set
> to 0 if the feature is not supported but
> the datasheet gives program sequence as well. Please
> override the data read from CFI regarding write
> timeout with a non zero value (say 1ms
> timeout) and see what happens. Perhaps, they set the

With this hacking way as suggested, it simply worked
fine! I tried programming a 1.4MB files several times.
No probelm.

--- drivers/cfi_flash.c 17 Nov 2006 09:02:43 -0000    
 1.2
+++ drivers/cfi_flash.c 20 Nov 2006 03:41:43 -0000    
 1.3
@@ -1107,7 +1107,12 @@ ulong flash_get_size (ulong 
+#ifndef CONFIG_S29GL064M
info->write_tout = (tmp * (1 << flash_read_uchar
(info, FLASH_OFFSET_WMAX_TOUT))) / 1000;
+#else
+ info->write_tout = 1;   /* Suggested by Tolunay */
+#endif /* CONFIG_S29GL064M  */
+

> Good luck,

Thanks:-)

Sam


	

	
		
___________________________________________________________ 
Mp3???-???????
http://music.yahoo.com.cn/?source=mail_mailbox_footer

[U-Boot-Users] 16BIT SPANSION Flash writing problem with CFI Driver

[Tolunay Orkun]

Sam Song wrote:
>> non-buffered writes I believe the write timeout of 0
>> may be the problem. Typically these values are set
>> to 0 if the feature is not supported but
>> the datasheet gives program sequence as well. Please
>> override the data read from CFI regarding write
>> timeout with a non zero value (say 1ms
>> timeout) and see what happens. Perhaps, they set the
>>     
>
> With this hacking way as suggested, it simply worked
> fine! I tried programming a 1.4MB files several times.
> No probelm.
>   

Glad to hear that the hack has worked.
> --- drivers/cfi_flash.c 17 Nov 2006 09:02:43 -0000    
>  1.2
> +++ drivers/cfi_flash.c 20 Nov 2006 03:41:43 -0000    
>  1.3
> @@ -1107,7 +1107,12 @@ ulong flash_get_size (ulong 
> +#ifndef CONFIG_S29GL064M
> info->write_tout = (tmp * (1 << flash_read_uchar
> (info, FLASH_OFFSET_WMAX_TOUT))) / 1000;
> +#else
> + info->write_tout = 1;   /* Suggested by Tolunay */
> +#endif /* CONFIG_S29GL064M  */
> +
>   
Instead of a chip specific solution we should try to find more
generalized solution. At minimum, we could always use 1 if the value
turns out to be 0 after calculation.

Or maybe we should examine the DQ7 toggle check to see if there is a
race condition. If there is a race condition there we should fix that
problem instead.

Best regards,
Tolunay

[U-Boot-Users] 16BIT SPANSION Flash writing problem with CFI Driver

[Andrew Dyer]

On 11/20/06, Tolunay Orkun <listmember@orkun.us> wrote:
> Sam Song wrote:
> >> non-buffered writes I believe the write timeout of 0
> >> may be the problem. Typically these values are set
> >> to 0 if the feature is not supported but
> >> the datasheet gives program sequence as well. Please
> >> override the data read from CFI regarding write
> >> timeout with a non zero value (say 1ms
> >> timeout) and see what happens. Perhaps, they set the
> >>
> >
> > With this hacking way as suggested, it simply worked
> > fine! I tried programming a 1.4MB files several times.
> > No probelm.
> >
>
> Glad to hear that the hack has worked.
> > --- drivers/cfi_flash.c 17 Nov 2006 09:02:43 -0000
> >  1.2
> > +++ drivers/cfi_flash.c 20 Nov 2006 03:41:43 -0000
> >  1.3
> > @@ -1107,7 +1107,12 @@ ulong flash_get_size (ulong
> > +#ifndef CONFIG_S29GL064M
> > info->write_tout = (tmp * (1 << flash_read_uchar
> > (info, FLASH_OFFSET_WMAX_TOUT))) / 1000;
> > +#else
> > + info->write_tout = 1;   /* Suggested by Tolunay */
> > +#endif /* CONFIG_S29GL064M  */
> > +
> >
> Instead of a chip specific solution we should try to find more
> generalized solution. At minimum, we could always use 1 if the value
> turns out to be 0 after calculation.
>

I think we had a long e-mail exchange about this problem in may of '05
some of which is here:

http://article.gmane.org/gmane.comp.boot-loaders.u-boot/17379

it looks like a fix never got committed (at least as of the last time
I pulled from git which was admittedly a while ago).

-- 
Hardware, n.:
        The parts of a computer system that can be kicked.

[U-Boot-Users] 16BIT SPANSION Flash writing problem with CFI Driver

[Andrew Dyer]

On 11/20/06, Andrew Dyer <amdyer@gmail.com> wrote:
> I think we had a long e-mail exchange about this problem in may of '05
> some of which is here:
>
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/17379
>
> it looks like a fix never got committed (at least as of the last time
> I pulled from git which was admittedly a while ago).

I have to take this one back - a fix for rounding up cfi timeouts went in here:

2662b40cace272da5759040622561d821c878d56

and here:

79b4cda076069d04122f0d863bcb822b5e596c93


-- 
Hardware, n.:
        The parts of a computer system that can be kicked.

[U-Boot-Users] 16BIT SPANSION Flash writing problem with CFI Driver

[Tolunay Orkun]

Andrew Dyer wrote:

>>> --- drivers/cfi_flash.c 17 Nov 2006 09:02:43 -0000
>>>  1.2
>>> +++ drivers/cfi_flash.c 20 Nov 2006 03:41:43 -0000
>>>  1.3
>>> @@ -1107,7 +1107,12 @@ ulong flash_get_size (ulong
>>> +#ifndef CONFIG_S29GL064M
>>> info->write_tout = (tmp * (1 << flash_read_uchar
>>> (info, FLASH_OFFSET_WMAX_TOUT))) / 1000;
>>> +#else
>>> + info->write_tout = 1;   /* Suggested by Tolunay */
>>> +#endif /* CONFIG_S29GL064M  */
>>> +
>>>
>>>       
>> Instead of a chip specific solution we should try to find more
>> generalized solution. At minimum, we could always use 1 if the value
>> turns out to be 0 after calculation.
>>
>>     
>
> I think we had a long e-mail exchange about this problem in may of '05
> some of which is here:
>
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/17379
>
> it looks like a fix never got committed (at least as of the last time
> I pulled from git which was admittedly a while ago).
>
>   
Thanks Andew for jogging my memory. I now remember that discussion and 
actually I did submit a patch which was committed. It is in the git. I 
just checked it. It was committed Feb 28, 2006

http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=commitdiff;h=79b4cda076069d04122f0d863bcb822b5e596c93

Sam you said this in your original mail:
> What could be the problem be? I use the CFI driver
> from GIT repository on Nov. 2.
Sam please do sync up with the git and please make sure you do have 
latest code next time.

Best regards,
Tolunay

[U-Boot-Users] 16BIT SPANSION Flash writing problem with CFI Driver

[Sam Song]

Tolunay Orkun <listmember@orkun.us> wrote:
> Andrew Dyer wrote:
> > I think we had a long e-mail exchange about this
> > problem in may of '05 some of which is here:
>
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/17379
> >
> > it looks like a fix never got committed (at least
> > as of the last time I pulled from git which was 
> > admittedly a while ago).
> >   
> Thanks Andew for jogging my memory. I now remember
> that discussion and actually I did submit a patch
> which was committed. It is in the git. I 
> just checked it. It was committed Feb 28, 2006
> 
>
http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=commitdiff;h=79b4cda076069d04122f0d863bcb822b5e596c93
> 
> Sam you said this in your original mail:
> > What could be the problem be? I use the CFI driver
> > from GIT repository on Nov. 2.
> Sam please do sync up with the git and please make
> sure you do have latest code next time.

My bad! After a quick upgrade to 1.1.6, CFI driver 
worked fine with/without buffer writes! I would not
play it again.

Apologize for the noise...

U-Boot 1.1.6 (Nov 21 2006 - 21:13:51), Build:
mini-1.1.6

CPU:   8548_E, Version: 1.1, (0x80390011)
Core:  E500, Version: 1.0, (0x80210010)
Clock Configuration:
       CPU: 999 MHz, CCB: 399 MHz,
       DDR: 199 MHz, LBC:  24 MHz
L1:    D-cache 32 kB enabled
       I-cache 32 kB enabled

[......]
DDR:   512 MB
SDRAM test phase 1:
SDRAM test phase 2:
SDRAM test passed.
FLASH:  8 MB
L2 cache 512KB: enabled
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0
MPC8548E_Rev1.1=> fli

Bank # 1: CFI conformant FLASH (16 x 16)  Size: 8 MB
in 128 Sectors
 Erase timeout 16384 ms, write timeout 1 ms, buffer
write timeout 5 ms, buffer size 32
  Sector Start Addresses:
 FF800000      FF810000      FF820000      FF830000   
  
 [...]
 FFFD0000 ERO  FFFE0000  RO  FFFF0000  RO
MPC8548E_Rev1.1=>
MPC8548E_Rev1.1=> cp.b ffa00000 ffc00000 180000
Copy to Flash... done
MPC8548E_Rev1.1=> iml
Image at FFA00000:
   Image Name:   Simple Embedded Linux Framework
   Image Type:   PowerPC Linux RAMDisk Image (gzip
compressed)
   Data Size:    1447416 Bytes =  1.4 MB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
Image at FFC00000:
   Image Name:   Simple Embedded Linux Framework
   Image Type:   PowerPC Linux RAMDisk Image (gzip
compressed)
   Data Size:    1447416 Bytes =  1.4 MB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
MPC8548E_Rev1.1=>

Sorry,

Sam


	

	
		
___________________________________________________________ 
Mp3???-???????
http://music.yahoo.com.cn/?source=mail_mailbox_footer

[U-Boot-Users] 16BIT SPANSION Flash writing problem with CFI Driver

[Wolfgang Denk]

In message <c166aa9f0611201620q289593d0n3e106fe0eebcb451@mail.gmail.com> you wrote:
>
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/17379
> 
> it looks like a fix never got committed (at least as of the last time
> I pulled from git which was admittedly a while ago).

According to my notes this should be part of commit
79b4cda076069d04122f0d863bcb822b5e596c93 (sr, 28 Feb 2006).


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I am not now, nor have I ever been, a member of the demigodic party.
                                                   -- Dennis Ritchie

[U-Boot-Users] u-boot hanging

[Wolfgang Denk]

In message <8bf247760611170016n2bc309dbhf0d44e10c03d2e01@mail.gmail.com> you wrote:
>
>  I had posted a query regarding hanging of u-boot when a return is made from
> a standalone application.

Did you really follow the required steps? See the documentation!

>  Do we need to do something "Special" before returning back?.

Yes, you must initialize your app.

>  All im doing is
> 
>   while (!tstc())
>                 ;
>   ch = getc ( );
>   printf ("Returning\n") ;
> 
>   return (0) ;

I don't see any call to app_startup(), nor do I see any checking of
get_version() results...

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A Freudian slip is when you say one thing but mean your mother.

[U-Boot-Users] u-boot hanging

[Ram]

Hi,
   Thanks for your response, im certainly initialising by calling
app_startup ( ) ;

   My Program Looks like:

  int hello_world (int argc, char * argv [ ])
  {
       int ch ;

       app_startup(argv);
       printf ("Example expects ABI version %d\n", XF_VERSION);
       printf ("Actual U-Boot ABI version %d\n", (int)get_version());

       printf ("Do you want to execute all the tests\n") ;
       printf ("Enter Y to yes or any other key to exit:") ;

       while (!tstc())
                 ;
       ch = getc ( );

       if (ch == 'Y' || ch == 'y') {
              printf ("Executing tests\n") ;
              tests ( ) ;
       }

       printf ("Returning back to u-boot\n") ;
       printf ("\n\n") ;

      return (0) ;
 }


 When i return back, I dont get the u-boot prompt.  I need to restart the
board.

  I get the print Returning back to u-boot.


  Am i missing something before return?.



On 11/18/06, Wolfgang Denk <wd@denx.de> wrote:
>
> In message <8bf247760611170016n2bc309dbhf0d44e10c03d2e01@mail.gmail.com>
> you wrote:
> >
> >  I had posted a query regarding hanging of u-boot when a return is made
> from
> > a standalone application.
>
> Did you really follow the required steps? See the documentation!
>
> >  Do we need to do something "Special" before returning back?.
>
> Yes, you must initialize your app.
>
> >  All im doing is
> >
> >   while (!tstc())
> >                 ;
> >   ch = getc ( );
> >   printf ("Returning\n") ;
> >
> >   return (0) ;
>
> I don't see any call to app_startup(), nor do I see any checking of
> get_version() results...
>
> Best regards,
>
> Wolfgang Denk
>
> --
> Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> A Freudian slip is when you say one thing but mean your mother.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20061120/dfb6fbb8/attachment.htm 

[U-Boot-Users] 16BIT SPANSION Flash writing problem with CFI Driver

[Bastos Fernandez Alexandre]

Hi,

>> I didn't enable buffer writes. Once I defined
>> CFG_FLASH_USE_BUFFER_WRITE, all save operations
>> would encounter an error. Actually, I noticed
>> it was unaccptable to enable buffer write for
>> AMD flash.
>>
>
>I guess you can implement CFG_FLASH_USE_BUFFER_WRITE for AMD style
>flash. The details is in the datasheet. It should speed up the
>programming anyway.

I use CFG_FLASH_USE_BUFFER_WRITE in my board
with a Spansion S29GL032 Flash in 8BIT mode,
and til now, it works perfectly.

This mode is the only one allowed in 8BIT mode,
so I guess that it is acceptable for Spansion/AMD
flashes

Best regards,

Alexandre

[U-Boot-Users] 16BIT SPANSION Flash writing problem with CFI Driver

[Sam Song]

Bastos Fernandez Alexandre <alebas@televes.com> wrote:
> I use CFG_FLASH_USE_BUFFER_WRITE in my board
> with a Spansion S29GL032 Flash in 8BIT mode,
> and til now, it works perfectly.
> 
> This mode is the only one allowed in 8BIT mode,
> so I guess that it is acceptable for Spansion/AMD
> flashes

Glad to see your input on this point. My misleading
understanding was from old notes in CHANGELOG. Should 
be updated this time. This way, the implementation
of buffer writes support is an issue of 16-bit
support.

Thanks,

Sam


	

	
		
___________________________________________________________ 
Mp3???-???????
http://music.yahoo.com.cn/?source=mail_mailbox_footer