[U-Boot-Users] u-boot hanging
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
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/
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
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.....@.... 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
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
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
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
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).
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
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=79b4cda076...
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
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=79b4cda076...
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
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
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
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@denx.de A Freudian slip is when you say one thing but mean your mother.
participants (5)
-
Andrew Dyer -
Ram -
Sam Song -
Tolunay Orkun -
Wolfgang Denk