SK, EVM U-boot memory fill (mw.b) command strange behaviour. Please advice.

sviss

Hello forum,

The Sitara am335x supports up to 1GiB of DDR SDRAM (0x4000_0000 bytes). The SK has 256MiB DDR on-board (0x1000_0000 bytes).

Therefore issuing the following commands at u-boot prompt:

1) U-Boot# mw.b 80000000 ff 50000000

2) U-Boot# mw.b 82000000 ff E000001

3) U-Boot# mw.b 82000000 ff E000000

one might expect:

1) (error) out of memory address range

2) (warning) memory fill beyond the available ext. RAM

3) should work normal.

However, U-boot just hangs, and this is the main issue I want to address/understand.

More to that,

A) SK: if I specify some odd memory fill size, the mw.b command always works OK, and if 1 byte more than that - always hangs.

B) EVM: if I specify (another) odd memory fill size, the command always works OK, if 1 byte more - always crashes rebooting the board, and if I specify even bigger size to fill - hangs.

I experimented with 2 SK boards, and 1 EVM.

So, could please somebody try reproduce my "discovery", or if possible suggest a reason for that, or a workaround.

The case is that with my own board I seem to have troubles, with the roots around a DDR writing. Hope, working aroung U-boot (same behavior there) will help to better understand the case.

Attached is a picture illustration.

Thanks!

over 12 years ago

0 Miroslav Kiradzhiyski XID over 12 years ago

TI__Mastermind 25235 points

Hi sviss,

I put some prints in the do_mem_mw() function, located in <u_boot_folder>/common/cmd_mem.c file.

U-Boot doesn't hang - it just enters a while(count--) loop, where the "count" value is the size of the memory area, which you have passed via the command line. If the size is as big as 50000000(hex) the time to make all the iterations in the while loop will be quite long.

Here is the output after running the first command you ran:

U-Boot# mw.b 80000000 ff 50000000
********** count = 1342177279
********** count = 1342177278
********** count = 1342177277
********** count = 1342177276
********** count = 1342177275
********** count = 1342177274
********** count = 1342177273
********** count = 1342177272
********** count = 1342177271
********** count = 1342177270
.......... and so on ...........

There isn't any "valid memory area" error check in this function. I assume it's up to the user to be careful.

Regarding the second part of your post: I'm not able to reproduce the issue. I ran the exact same commands on an EVM board, but everything worked. No crashes, no hanging.

Perhaps you can put some prints in the do_mem_mw() function and see what exactly is happening.

Best regards,
Miroslav

0 sviss over 12 years ago in reply to Miroslav Kiradzhiyski XID

Expert 1530 points

Hi Miroslav,

Thank you for the reply.

I am very pleased to have a message from you because your comprehensive NAND flashing procedure description helped me to avoid many troubles I had with it.

I know, U-boot checks nothing. More to that: my board is already working normal and I can go forward with the development.

I mean that the issue with U-boot RAM fill is still there and I am not sure that I will have time to study it in-depth right now.

There is no issue about a "5000000000". On my picture you can easily see that few bytes is enough to try fill, and have the u-boot hang.

The board there was the TMDSSK3358 (SK short name)

I wouldn't post here if it was just *my* board. But because this was with SK two boards (as well as with my board), I started the topic.

Thank you for your time. Maybe in near future I'll return to the study and will add few prints there as you suggested.

I must apologize that I currently cannot mark the question "answered". It is answered but the problem is still somewhere there.

Thanks again,

0 sviss over 12 years ago in reply to sviss

Expert 1530 points

I added a printout to the do_mem_mw ( ), as follows:

while (count-- > 0) {

    printf("Writing %02X to %04X (size=%d, count: %d) ... ", /* <----- added printout */

 (unsigned int)writeval, (unsigned int)addr, (unsigned int)size, (unsigned int)count );
 if (size == 4)
 *((ulong *)addr) = (ulong )writeval;
 else if (size == 2)
 *((ushort *)addr) = (ushort)writeval;
 else
 *((u_char *)addr) = (u_char)writeval;
 addr += size;
 printf(" OK.\n"); /* <----- added printout */ 
 }

The resulting screenshot of hyperterminal, after Xmodem loading of u-boot-spl.bit and Ymodem loading of u-boot.img containing the code above is as follows :

(the crash happens every time for the same 0x8FF59FC RAM address, I can repeat it infinite times)

Currently I conclude that I am a lone lucky here with this happening.

0 sviss over 12 years ago in reply to sviss

Expert 1530 points

Seems the answer is on my screenshot:

the u-boot is running out of RAM @8ff59f78, and wipes itself.

It is strange that u-boot is not within 80000000..82000000 area.

It is strange that u-boot use of DRAM is not clearly documented, and SK code does not do any checks.

All this was very confusing (for me).

Thanks, Miroslav. You inspired me on finding u-boot problems myself.

Processors

Processors forum

SK, EVM U-boot memory fill (mw.b) command strange behaviour. Please advice.