[PATCH] ARM: /proc/atags: Export also for DT

Jean-Christophe PLAGNIOL-VILLARD
2015-01-28T06:21:55Z

> On Jan 28, 2015, at 10:07 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
>
> On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:
>
>> On Tue, Jan 27, 2015 at 04:34:47PM -0500, Nicolas Pitre wrote:
>>> On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:
>>>> Or we pass both the ATAGs and wrapped DT to the kernel when both exist,
>>>> and let the kernel deal with it in a much saner environment than the
>>>> restricted decompressor environment.
>>>
>>> ... which would be a step backward in the context of the transition to
>>> DT we accepted. People will have even less of an incentive to fix their
>>> stuff.
>>
>> Where's the people fixing their stuff today?
>
> At least some people in this thread are, otherwise they'd still be away
> hacking on their own.
>
>> I think your position is something of an idealist rather than a
>> realist - the reality is that five years down the line of DT, the
>> platforms which have not converted are now *never* going to convert,
>> irrespective of how much "incentive" we may think we should apply to
>> the situation.
>
> Don't get me wrong. I'm not expecting those platforms to do native DT
> booting ever. However "faking" DT booting with already proven solutions
> that don't bastardize the kernel further should be encouraged.
>
>>> If there is indeed a sizable following for the device then someone
>>> should figure out how to cope with upstream kernels, either through the
>>> installation of some intermediate bootloader that can talk FDT directly,
>>> or via a shim layer. None of that has to be performed by nor linked
>>> with the kernel binary, nor maintained in the kernel tree. And it's not
>>> even that hard to do: we have precedents on other platforms with crappy
>>> bootloaders where this just works.
>>
>> That's a rediculous position if you want something which "just works"
>> on as much hardware as possible, which is, after all, what the single
>> zImage project is all about.
>
> Agreed.
>
>> To be pro single-zImage, and anti popular hardware is quite contradictory.
>
> Indeed. I'm not against popular hardware.
>
>> You only have to look at x86 for this: just because ACPI came along does
>> not mean that the Linux kernel started demanding that ACPI is the only
>> way to describe the world. Linux continues to directly support all the
>> old boot protocols that it did since the days of i386, such as the e820
>> memory interface and doesn't convert these to an ACPI table just because
>> it can.
>
> Booting from a floppy boot sector is no longer supported though.
>
> But that's besides the point. If someone needs a 5-line addition to
> atags_to_fdt.c in order to boot some old stuff then let's just do it and
> move on. I'll happily ACK the patch. The code is there and it is not
> going away soon.
>
> However, if something more involved is needed, is platform specific and
> is likely to require about as many lines in the kernel than it would
> need in some externat shim then the shim solution should be encouraged
> instead. After all that's why LILO, Syslinux and Grub were created on
> X86: to Supplement the crappy PC BIOS boot interface. And if the
> hardware is popular, then finding a motivated hacker to do it shouldn't
> be too hard, right?
>
> In other words, what prevents someone from creating, say, a custom
> minimal Barebox version that sits on top of the existing N900
> bootloader? Wouldn't that provide a much better user experience?

I do agree with Nicolas

If I can get my hand on a phone I?ll put barebox on it

Best Regards,
J.
>
>
> Nicolas
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel