[U-Boot] after relocation, the original text_base memory section can't be used

[U-Boot] after relocation, the original text_base memory section can't be used

[Yuping Luo]

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.

      u-boot  image:

 arm-none-linux-gnueabi-objdump  -h .obj/boot/uboot/u-boot

.obj/boot/uboot/u-boot:     file format elf32-littlearm
Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         000373f4  01500000  01500000  00008000  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .rodata       0000804c  015373f4  015373f4  0003f3f4  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .hash         00000040  0153f440  0153f440  00047440  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .data         00000a74  0153f480  0153f480  00047480  2**3
                  CONTENTS, ALLOC, LOAD, DATA
  4 .got.plt      0000000c  0153fef4  0153fef4  00047ef4  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  5 .u_boot_cmd   000004f8  0153ff00  0153ff00  00047f00  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  6 .dynsym       000000b0  015462a0  0154bb6c  00053b6c  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  7 .rel.dyn      00005ea8  015403f8  015403f8  000483f8  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  8 .bss          000058cc  015403f8  015403f8  0004e2a0  2**3
                  ALLOC
  9 .ARM.attributes 0000002d  00000000  00000000  00053c1c  2**0
                  CONTENTS, READONLY

and the u-boot runtime info

U-Boot 2011.03-dirty-svn4940 (May 26 2011 - 15:08:09) for PRIMA2

U-Boot code: 01500000 -> 015403F8  BSS: -> 01545CC4
CPU:    Prima2
Board:  Prima2 EVB
monitor len: 00045CC4
ramsize: 20000000
TLB table at: 1fff0000
Top of RAM usable for U-Boot at: 1fff0000
Reserving 279k for U-Boot at: 1ffaa000
Reserving 1056k for malloc() at: 1fea2000
Reserving 24 Bytes for Board Info at: 1fea1fe8
Reserving 120 Bytes for Global Data at: 1fea1f70
New Stack Pointer is: 1fea1f68
RAM Configuration:
Bank #0: 00000000 512 MiB
relocation Offset is: 1eaaa000
monitor flash len: 00046350
Now running in RAM - U-Boot at: 1ffaa000
MMC:   to Init SD0...
Prima2 SD/MMC: 0
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial

Hit any key to stop autoboot:  0
Prima2 #

Thanks.
Yuping

[U-Boot] after relocation, the original text_base memory section can't be used

[Albert ARIBAUD]

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] after relocation, the original text_base memory section can't be used

[Yuping Luo]

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.boot@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 at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>