2

The platform is MIPS, and the kernel is linux 2.6.31.

First, I reserve 8M RAM zone, out of total RAM of 64M, so the kernel only uses 56M RAM zone. Second, I use the ioremap() function to transform the physical address to a virtual address in kernel, then write my data. Like this:

void *virt_addr = (void *)ioremap(0x83800000,0x800000);//0x83800000 is the start physical address of 8M
memset_io(virt_addr,0,0x800000);
memcpy_toio(virt_addr,buf,0x800000);
iounmap(virt_addr);

I then read the data in uboot: Keeping the power, and rebooting the system, I enter uboot. Uboot uses the physical address, so I read the data starting at 0x83800000. Here's the problem: At 0x83800000(0M), one byte of data is wrong, at 0x83c00000(4M), one byte of data is wrong, and at 0x84000000(8M), one byte of data is wrong. But all the rest of the data is right,same as buf!! So strange!! I don't know the reason, who can help me? Thanks...

Peter
  • 14,559
  • 35
  • 55
dovelj
  • 21
  • 1
  • Be concrete, what does it mean "wrong" - give concrete values. These values are always the same? – Alex Hoppus Apr 21 '15 at 17:57
  • Thank you! In uboot, these values are always the same,if I do like this:char temp[1]; memcpy(temp,(void *)0x83800000); printf("%p\n",temp[0]), the printf result is always "0000000e", if printf("%c\n",temp[0]), the result is messy code....It look like the memcpy_toio function not writing data to 0x83800000 and other two address... – dovelj Apr 22 '15 at 01:31
  • Thank you! In uboot, these values are always the same,if I do like this:char temp[1]; memcpy(temp,(void *)0x83800000); printf("%p\n",temp[0]), the printf result is always "0000000e", if printf("%c\n",temp[0]), the result is messy code....It look like the memcpy_toio function not writing data to 0x83800000 and other two address...@Alex Hoppus – dovelj Apr 22 '15 at 01:38
  • First, using "%p" with a single byte is nonsensical; that's only for pointers, and "%c" is only for printable characters. Second, 0x84000000 is beyond the 8M you say you have appropriated so why do you have any expectation as to its value. Third, memcpy has 3 arguments and you've only showed 2. However, if you're correct that 1 byte at each of the locations has in fact been changed, I wonder if there isn't some earlier-executing part of the boot loader that is attempting to discover available RAM regions by poking arbitrary values at 4M intervals and trying to read them back. – Gil Hamilton Apr 22 '15 at 02:08
  • Thanks...I find the reason today. In uboot, the system will check the RAM size: uint8_t *p = (uint8_t *)a0000000, pat = 0x77; int i; *p = pat; for(i = 1; ; i++) { *(p + i *4*1024*1024) = (uint8_t)(i); if (*p != pat) { break; } } – dovelj Apr 23 '15 at 08:27

0 Answers0