Hi, Albert
Thanks for your help.
I found the root cause: In our implementation, the RomCode
initialises the mmu with one hardcode page table address (0x014F8000)
to store the 16KB table, however, it's rewritten by the data. we may
refer to the uboot way of using the dynamically generated TLB address
and memory in arch/arm/lib/board.c, it's flexible.
regards,
Yuping
On Thu, May 26, 2011 at 7:10 PM, Albert ARIBAUD
<albert.u.b...@aribaud.net> wrote:
> Hi,
>
> Le 26/05/2011 11:04, Yuping Luo a écrit :
>> Hi,
>>
>> With 2011.03 uboot, I am adding firmware flashing feature to our
>> arm cortex a9 soc platform via usb, in which the data firstly be
>> uploaded to memory wholly (more than 200MB, thanks our 512MB physical
>> memory), then burned.
>> By my understanding, after relocation the successive memory range
>> (0~~ relocaddr) can be (re)used. however, if the original text section
>> (in my case, 0x01500000) is written, the data abort happens when
>> accessing 0x01600000; if the memory section (0x01500000~0x01600000)
>> not written, everything is ok. please correct me if I am wrong.
>
> Well, what is sure is that not all of 1500000-1600000 was used before
> relocation either (it ends around 1546000), so 1600000 was not accessed
> before reloc. How can you be sure the issue happens after reloc? For all
> we know, it could be a bug in the code code that writes 1500000 to
> 1600000 itself.
>
> Amicalement,
> --
> Albert.
> _______________________________________________
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
