[U-Boot] Relocation issue on armv7 targets

From: Aneesh V <aneesh@ti.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] Relocation issue on armv7 targets
Date: Tue, 19 Jun 2012 20:38:27 -0700	[thread overview]
Message-ID: <4FE145B3.6010705@ti.com> (raw)
In-Reply-To: <CALdT2jyX0tz_rs2f1ExT=nE4_W5oSfYegwLU2HSAAaQohYe4xQ@mail.gmail.com>

Hi Jagan,

On 06/19/2012 08:36 AM, jagan wrote:
> Hi Albert,
>
> I have observed an issue regarding u-boot relocation, it's working with
> _TEXT_BASE address but
> for other address in DDR it's not working. Stops at relocation offset.

This is not quite clear to me. What's working and what's not working.
Please note that according to the new relocation scheme, u-boot should
start at CONFIG_SYS_TEXT_BASE. u-boot then relocates itself to the
end of available SDRAM. U-Boot will not work if it starts from any
other location.

Contrast this with the earlier scheme where U-boot could start from a
location other than CONFIG_SYS_TEXT_BASE and then it relocates itself
to CONFIG_SYS_TEXT_BASE

The following thread has some discussion on this topic.
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/95967/

br,
Aneesh

>
> I was trying this on both QEMU as well as real target.
>
> Here are my findings:
> -----------------------------
> VExpress# tftp 0x8000 u-boot.bin
> smc911x: detected LAN9118 controller
> smc911x: phy initialized
> smc911x: MAC 52:54:00:12:34:56
> Using smc911x-0 device
> TFTP from server 192.168.0.3; our IP address is 192.168.0.4
> Filename 'u-boot.bin'.
> Load address: 0x8000
> Loading: ##########################
> done
> Bytes transferred = 128736 (1f6e0 hex)
> VExpress# go 0x8000
> ## Starting application at 0x00008000 ...
>
>
> U-Boot 2012.04.01-00004-gdd16cc2-dirty (Jun 19 2012 - 20:42:05)
>
> U-Boot code: 60800000 ->  6081C200  BSS: ->  60851C88
> monitor len: 00051C88
> ramsize: 08000000
> TLB table at: 67ff0000
> Top of RAM usable for U-Boot at: 67ff0000
> Reserving 327k for U-Boot at: 67f9e000
> Reserving 144k for malloc() at: 67f7a000
> Reserving 44 Bytes for Board Info at: 67f79fd4
> Reserving 120 Bytes for Global Data at: 67f79f5c
> New Stack Pointer is: 67f79f50
> DRAM:  128 MiB
> relocation Offset is: 0779e000
> qemu: fatal: Trying to execute code outside RAM or ROM at 0x077a6a68
>
> R00=67f79f5c R01=67f9e000 R02=00000000 R03=6081f610
> R04=67f9e000 R05=67f79f5c R06=67f9e000 R07=00000002
> R08=60000f80 R09=0779e000 R10=6081f610 R11=67f79ad9
> R12=60000ff8 R13=67f79f50 R14=077a6a68 R15=077a6a68
> PSR=600001d3 -ZC- A svc32
> Aborted
>
>  From the logs, it's unable to get the exact lr value a/f relocation
> happens, due to
> that board_init_r not been called.
>
> Could you please help me, Do I need to change any TEXT_BASE or liker script
> for this.?
>
> I have analyzed and understood the code and seems to be some wired thing on
> start code.
> I found some hack for this, but does it a valid issue or did I make any
> mistake.
>
> Request for your help.
>
> Regards,
> Jagan.
>
>
>
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot