Message-ID: <20150127223331.GP26493@n2100.arm.linux.org.uk>
Date:	Tue, 27 Jan 2015 22:33:31 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Nicolas Pitre <nico@...xnic.net>
Cc:	Pali Rohár <pali.rohar@...il.com>,
	Rob Herring <robherring2@...il.com>,
	Pavel Machek <pavel@....cz>, Will Deacon <will.deacon@....com>,
	Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com>,
	Sebastian Reichel <sre@...ian.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Tony Lindgren <tony@...mide.com>
Subject: Re: [PATCH] ARM: /proc/atags: Export also for DT

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

So, at some point we have to start thinking as a realist rather than
an idealist, and realise that there are platforms out there which are
/never/ going to convert.

Most of my platforms here are /never/ going to convert to DT-only
booting quite simply because they don't have anyone working on that
stuff, and no one is willing to put the effort in.

The only platforms which I have which have converted are:
- OMAP SDP4430
- Versatile Express
- SolidRun Hummingboard & Cubox-i

Quite literally everything else is *never* going to support native DT
booting - and I'd go as far as to say that if I ever wanted to put the
effort in, I probably couldn't, because the boot loader sources aren't
available anymore.  (eg, the LDP3430 situation is such a mess that even
if the boot loader source is still available, identifying the correct
board version is near on impossible given the multitude of different
variants of the same product.)

The older Versatile and Integrator platforms, for example, are going
to be booting with the appended DTB for as long as they're around.
Most likely all the PXA platforms too, and, the IOP32x based N2100
boxes (which already need their kernels wrapped because the provided
boot loader has had environment saving disabled.)

As much as you may not like it, ATAGs are here to stay now, at least
on the older platforms, and no amount of "incentives" will change that.

> > However, there's another consideration to be had here before we can say
> > that: how many people out there want to run a mainline (or even an
> > updated kernel derived from mainline) on this device?  If there's a
> > sizable following for the device wanting updated support, then it's
> > something we really need to consider supporting inspite of our
> > disappointment with Nokia inventing these "proprietary" tags.
> 
> 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.

To be pro single-zImage, and anti popular hardware is quite contradictory.

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.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists