[PATCH 4/5] [ARM] Auto calculate ZRELADDR and provide option for exceptions

[Eric Miao]

2010/6/10 Uwe Kleine-König <u.kleine-koenig at pengutronix.de>:
> On Thu, Jun 10, 2010 at 05:38:27PM +0800, Eric Miao wrote:
>> 2010/6/10 Russell King - ARM Linux <linux at arm.linux.org.uk>:
>> > On Thu, Jun 10, 2010 at 11:00:15AM +0200, Uwe Kleine-König wrote:
>> >> What do you think about requiring r4 to be set to physoffset as I did in
>> >> my series?  This way zImage would already know PHYSOFFSET and so didn't
>> >> need to guess ZRELADDR.  OK, until most bootloaders are fixed we need
>> >> to guess, too.  But at least this would provide a way to stop guessing
>> >> wrong for the affected platforms.
>> >
>> > That means it won't get implemented.  Look at the facts.  It's taken
>> > _years_ (5+ years) for boot loaders to start passing a value in r1.
>> > We then switched to the ATAG stuff, and it's again taking years for
>> > boot loaders to start passing right ATAG stuff - and most of them don't
>> > get it right.  Eg, lots of uboot are happy to print out the memory
>> > information on the terminal as they start up, but don't pass memory
>> > information to the kernel.
>> >
>> > So if we want phys offset in r4, we better realise that it'll take
>> > something like five years of nagging to get it in place, and even then
>> > people will continue to use boot loaders which don't have support.
>> > And if it's only necessary for a handful of platforms, I doubt anyone's
>> > really going to bother - or even validate that r4 is correct.
>> >
>> > You have a whole set of other problems - how do you cope with existing
>> > boot loaders which happen to call the kernel with a value in r4 which
>> > _could_ potentially be valid, but should not be used?  At the moment,
>> > r4 could contain _any_ value what so ever.
>> >
>> > Let's face it - advertising that "the kernel will eventually start using
>> > r4" doesn't solve the problem either - we did that with the ATAG list
>> > and we know the results from that.
>> >
>> > Maybe the right experiment to try this time - if we want r4 to contain
>> > a value - is to say that kernel 2.6.37 will require a value in r4, and
>> > won't boot without it, and will therefore be incompatible with old
>> > boot loaders.
>> >
>>
>> It might be difficult to guess if it's a correct value in r4 and we might
>> not need it. We know which boards can be compiled together and
>> the phys_offset can be guessed and we make a single kernel for them,
>> otherwise we end up building a specific kernel. Although my observation
>> is that most platforms can guess phys_offset automatically, but due to
>> the fact there are so many ARM variants out there, and each is doing
>> things differently, what we can do now is to provide both choices.
>>
>> And you reminded me that it might be better if we can make RUNTIME_PHYS_OFFSET
>> depends on the architecture this is test-proofed, so when the day that
>>
>> RUNTIME_PHYS_OFFSET
>>         depends on {ALL_ARCH}
> I would prefer
>
>        config HAVE_RUNTIME_PHYS_OFFSET
>                bool
>
>        config RUNTIME_PHYS_OFFSET
>                depens on HAVE_RUNTIME_PHYS_OFFSET
>
>        config ARCH_FOO
>                select HAVE_RUNTIME_PHYS_OFFSET
>
> for the usual reasons.
>

That's a good way to go.