[U-Boot] mtest issue

[Alexey Goncharov]

Hello Jerry, Wolfgang and all the u-boot maillist participants!

Sorry for the broken encoding in my previous mail.

>> I have a LPC2468 board and currently play with u-boot. U-boot version
>> is 1.1.6 from Embedded Artists. I've already made u-boot loading and
>
> 1.1.6 is really old.

I'll keep this in mind and will make the update as soon as fix current issue.


>> Pattern 00000000  Writing...  Reading...
>> Mem error @ 0xA075AB74: found A0780000, expected 001D6ADD
>
> What does the value A0780000 mean to your system?  That looks like a magic
> memory address.  Who would store that into memory?  That may be a clue for
> finding the culprit.

Sorry i didn't provide you with the information at all. System has 8
Mbyte SDRAM and adresses from 0xA0780000 (7,5 Mbyte) to 0xA0800000 (8
MByte) are reserved for u-boot image and data. 0xA0780000 - is a
TEXT_BASE (and CFG_MEMTEST_END) in target system. I found following
excerpt from u-boot/cpu/arm720t/start.S:

ldr r0, _TEXT_BASE                /* upper 128 KiB: relocated uboot   */
sub r0, r0, #CFG_MALLOC_LEN               /* malloc area    */
sub r0, r0, #CFG_GBL_DATA_SIZE           /* bdinfo    */
#ifdef CONFIG_USE_IRQ
sub r0, r0, #(CONFIG_STACKSIZE_IRQ+CONFIG_STACKSIZE_FIQ)
#endif
sub sp, r0, #12 /* leave 3 words for abort-stack    */

This means that we have a memory map illustrated below:

1. Stack (grows "back" from higher adresses to lower addresses)
2. 12 bytes for abort-stack
3. FIQ Stack (grows "back" from higher adresses to lower addresses)
4. IRQ stack  (grows "back" from higher adresses to lower addresses)
5. Global data
6. Heap
--TEXT_BASE = 0xA0780000
7. Uboot image

After calculating all the segment's adresses, i figured out that
addresses which give mtest error are from Stack segment (for example,
0xA075AB74). Here we come to the question: how can the memory segment
be checked if it's already occupied as a stack segment? My guess is
the mtest fails because of it "doesn't want" to corrupt the fragile
data in stack.

> If you specify a smaller, known unused, area to the mtest command (help
> mtest), does it work?  Work your way through your "unused" memory map and
> find where it breaks.

I also used the mtest to check memory segments right after "the broken
cell" and would say that everything is fine. It's only a range about
20 bytes and some addresses within this range give a mtest-error.


>> In case with CFG_ALT_MEMTEST defined mtest also fails with error:
>>
>> Testing a0000000 ... a0780000:
>> Iteration:      1
>> FAILURE (read/write) @ 0xa075ab68: expected 0x001d6adb, actual 0xffe29525)
>
> Note that the expected and actual are inverses:
>  ~0x001d6adb == 0xffe29525
> IIRC, the memory test stores the pattern, checks it, stores the ~pattern,
> and then checks that.  This is smelling of a memory timing issue again.

I also used a very simple low-level test, written by co-worker, to
check the SDRAM before u-boot becomes loaded. Here is the source of
it:

 unsigned int testSDRAM_32(void)
 {
   unsigned int i,j;
   for ( i = 0,j=0; i < (1024*1024*8); i+=sizeof(unsigned int),j++)
   {
     *(unsigned int*)((unsigned int)(SDRAM_BASE_ADDR+i)) = (unsigned int)j;
   }
   for ( i = 0,j=0; i < (1024*1024*8); i+=sizeof(unsigned int),j++)
   {
     if (*(unsigned int*)((unsigned int)(SDRAM_BASE_ADDR+i)) !=
(unsigned int)j) return(FALSE);
   }
   return(TRUE);
 }

 {
 static const unsigned char test_mem_BAD[] = "\r\nTest SDRAM Failed!\r\n";
 unsigned char *pMsg;
 unsigned int i;
   if(testSDRAM_32() == TRUE)
   {
     static const unsigned char test_mem_OK[] = "\r\nTest SDRAM OK.\r\n";
     pMsg = (unsigned char *)test_mem_OK - (unsigned char *)TEXT_BASE;
     for(i=0; i<(sizeof(test_mem_OK)-1); i++)
     {
       while((U0LSR & (1<<5)) == 0); /* Wait for empty U0THR */
       U0THR = *pMsg++;
     }
   }
   else
   {
     static const unsigned char test_mem_BAD[] = "\r\nTest SDRAM Failed!\r\n";
     pMsg = (unsigned char *)test_mem_BAD - (unsigned char *)TEXT_BASE;
     for(i=0; i<(sizeof(test_mem_BAD)-1); i++)
     {
       while((U0LSR & (1<<5)) == 0); /* Wait for empty U0THR */
       U0THR = *pMsg++;
     }
   }
 }

And i would say that there are no errors in common, and timing issues
in particular.

So.. let's try to gather all the questions in one list:

1. Can i decrease the CFG_MEMTEST_END to avoid the overlaying of mtest
check-segment and stack (or whatever)? I mean i've already decreased
CFG_MEMTEST_END to 0xa0750000. Mtest passes, but, obviously, addresses
from 0xa0750000 to 0xa0800000 are not being checked. is it ok?
2. Is the memory map i "illustrated" above right?
3. What is abort-stack (12 bytes)? (please, don't laugh)