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

Tom Rini
2012-09-17T18:00:42Z

-----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-----