[U-Boot] [PATCH] arm: Add option to disable code relocation

[Simon Glass]

Hi Graeme,

On Sun, Feb 5, 2012 at 3:37 PM, Graeme Russ <graeme.russ at gmail.com> wrote:
> Hi Simon
>
> On Mon, Feb 6, 2012 at 10:32 AM, Simon Glass <sjg at chromium.org> wrote:
>> Hi Graeme,
>>
>> On Sun, Feb 5, 2012 at 3:23 PM, Graeme Russ <graeme.russ at gmail.com> wrote:
>>> Hi Wolfgang, Simon,
>>>
>>> On Mon, Feb 6, 2012 at 9:44 AM, Wolfgang Denk <wd at denx.de> wrote:
>>>> Dear Simon Glass,
>>>>
>>>> In message <CAPnjgZ2Z0ojdLHz6yd5UuWru7pmJBLeogHzhK7rWGWk46xxqpA at mail.gmail.com> you wrote:
>>>>>
>>>>> This patch shows how to do this sort of thing on ARM. I would like to
>>>>> see this feature in mainline, but it makes more sense to do it
>>>>> properly if/when generic relocation is in. Then it will automatically
>>>>> work for all archs. For now it is a useful patch.
>>>>
>>>> Sorry, as I see it your chances to get this in are epsilon.
>>>
>>> I think the immediate focus should be on centralising the init sequence
>>> processing into /common/init.c and then bringing the new'initcall'
>>> architecture online
>>>
>>> Once these have been done, any board can just specific:
>>>
>>> SKIP_INIT(RELOC)
>>>
>>> And this can be wrapped:
>>>
>>> #ifdef CONFIG_SYS_SKIP_RELOC
>>> SKIP_INIT(RELOC)
>>> #endif
>>>
>>> Done ;)
>>
>> Which reminds me - did you do that pull request for your x86 refactor?
>> If not, what is the plan?
>
> I pushed the changes into the x86 sub-repo but noticed a minor glitch
> which breaks the build. On top of that, I've upgraded my dev machine to
> a 64-bit arch, moved from Ubuntu to Fedora and got a dud motherboard in
> the mix. So my dev machine is only just now back online, but I need to
> sort out the last few 64-bit build issues (which require U-Boot patches)
> and fix up the x86 sub-repo before sending the pull request.
>
> Sorry for the dealy, but hopefully I'll have it all sorted by the end of
> the week

OK thanks for the update. Would be keen to get my generic board stuff
tested on x86 also, but that might be a separate problem. For
initcalls, are you still thinking of looking at that?

Regards,
Simon

>
> Regards,
>
> Graeme