[U-Boot] [PATCH v2 01/11] ARM: fix relocation on ARM926EJS

[Tom Rini <trini@ti.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/17/12 10:48, Marek Vasut wrote:
> Dear Tom Rini,
> 
>> On Mon, Sep 17, 2012 at 07:26:06PM +0200, Marek Vasut wrote:
>>> Dear Tom Rini,
>>> 
>>>> On Sun, Sep 16, 2012 at 05:36:47PM +0200, Marek Vasut wrote:
>>>>> Dear Jos? Miguel Gon?alves,
>>>>> 
>>>>>> On 09/16/2012 11:06 AM, Marek Vasut wrote:
>>>>>>> Dear Jos? Miguel Gon?alves,
>>>>>>> 
>>>>>>>> On 09/15/2012 07:03 PM, Marek Vasut wrote:
>>>>>>>>> Dear Jos? Miguel Gon?alves,
>>>>>>>>> 
>>>>>>>>>> Jumping to board_init_r is not performed due to a
>>>>>>>>>> bug on address computation.
>>>>>>>>> 
>>>>>>>>> Is your CONFIG_SYS_TEXT_BASE configured correctly?
>>>>>>>>> I don't detect any misbehavior on my arm926
>>>>>>>>> boards.
>>>>>>>> 
>>>>>>>> Maybe because you are not using it to build an SPL?
>>>>>>> 
>>>>>>> I do ... and I use CONFIG_SPL_TEXT_BASE properly .
>>>>>>> 
>>>>>>>> Please check the same chunk of code in other start.S
>>>>>>>> for arm1176 and armv7. They have the same code that I
>>>>>>>> put for arm926ejs.
>>>>>>> 
>>>>>>> Please wait and please first explain what is the
>>>>>>> issue.
>>>>>> 
>>>>>> The issue is what I've explained in the patch comments.
>>>>> 
>>>>> "Jumping to board_init_r is not performed due to a bug on
>>>>> address computation."
>>>>> 
>>>>> Ok, I don't know how to replicate the bug from this comment
>>>>> or what effects it causes or ... well, anything. So please,
>>>>> try to be more elaborate in your patch description next
>>>>> time. Anyway ..
>>>>> 
>>>>>> Without this change the code never reaches board_init_r
>>>>>> in the SPL and I think I have all the configurations
>>>>>> correctly set.
>>>>> 
>>>>> I wonder why you'd ever want to reach board_init_r in the
>>>>> SPL. SPL is there only to load the real U-Boot from
>>>>> whatever media, so you usually use either NAND SPL
>>>> 
>>>> Here's a good point for me to jump in, I think.  There's two
>>>> things to understand: - In the current in-tree SPL
>>>> implementations the code flow is
>>>> 
>>>> board_init_f calls relocate_code() to clear the BSS _and_ get
>>>> our jump to board_init_r.  It does not actually relocate the
>>>> running U-Boot, just clears the BSS.  board_init_r is what
>>>> calls the things to load and boot the next stage (U-Boot or
>>>> Linux).
>>>> 
>>>> - In my series this has been changed slightly to be
>>>> board_init_f calls
>>>> 
>>>> memset and then board_init_r directly.  So this patch should
>>>> not be needed once rebased on that series.
>>> 
>>> Do we need to do all the relocation in assembler code btw? Can
>>> it not be moved into C code and made generic across all
>>> platforms (module the stack adjustment and a few minor things)
>>> ?
>> 
>> I think people have posted patches for this before and yes, once 
>> CONFIG_NEEDS_MANUAL_RELOC dies it should be all possible to do in
>> C, so long as it doesn't grow in size or doesn't grow in size
>> that would be problematic (remember the 4kb people).
> 
> How does MANUAL_RELOC interfere with that? Eg. on ARM, it can
> already be shifted to C. Then if we made it generic enough, those
> MANUAL_RELOC platforms could simply adopt the C code.

Yes, one of the platforms that already has C code for ELF relocation
(x86, iirc) could be made more generic and I think someone (Graeme?)
already started this a long time ago as part of making a generic set
of functions for board_init_{f,r}.  Just can't make it for all
platforms until everyone has ELF is the point I was poorly making.

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQV2VKAAoJENk4IS6UOR1W3McP/1htBzFzXXPULGOO+1zanoaO
T2tmJZ9f4gHNIY6gnCdU7SlW4mhZPEFlwHD+JwPmIS7ZhGcPxVn9Vgl+r0fpEZHW
VBY1bGeSGmaLhziiT+9MmaUqKUx6IFN5nZX0ypYcHS1ZTo1JztvLSUrSdOnOYHWx
DXXPwNIreUctwIpyjNrhu93e39ep1AYb1ZW+o57Sj4+uGqt8+G9FpEjdxMQrjKqh
r88j7XRgfWNPiqLwuGy+7HHEXnQGDum3Aml/ojO3WSzpZYXZQ4zC4MTND+TwzSi6
h3+nB3OfYktPgFWRDYQt8VyWPl9beVHzhac3o6sF5SiclQyya0liCCNsSbDSKf/G
Zjpjg5cOAmPMMUs1ZXq2Ve5wMxb0alArzxZuMZ/ZA1gRDjazFErvYCUzAQFkDAZz
zB6YMNc1+iCaYyaeNOqvJdMOZXAIoGLx5bbv9dzsnYc45jeU1ScDywcOQC2jTYFf
jnzmqzh/6EJW2gfWW33XdxbHsDOZeEfCzJFmK7/vEbVW0TrkiCMJjHzf/jdguABQ
jhusLwYYJr5yNlwq16RmiPxIaUhBrCFLY5cxLiSTd4v0DdbqyaTC7MEadjKQLpBW
/LA5ImhXr/ORhfNTrVQjDSRhAGdmi2L0GVTurHJ2I6SCIVesu/ioMCGY3sy+aizK
H3jl0yobGtRNFamgK+Ld
=ncZ8
-----END PGP SIGNATURE-----