Message-ID: <alpine.LFD.2.11.1501271309450.1322@knanqh.ubzr>
Date:	Tue, 27 Jan 2015 13:50:22 -0500 (EST)
From:	Nicolas Pitre <nicolas.pitre@...aro.org>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
cc:	Pavel Machek <pavel@....cz>, Tony Lindgren <tony@...mide.com>,
	Pali Rohár <pali.rohar@...il.com>,
	linux-omap <linux-omap@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Aaro Koskinen <aaro.koskinen@....fi>,
	Sebastian Reichel <sre@...nel.org>,
	Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com>,
	linux-arm-kernel@...ts.infradead.org,
	Laura Abbott <lauraa@...eaurora.org>
Subject: Re: N900 v3.19-rc5 arm atags_to_fdt.c is broken

On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:

> On Tue, Jan 27, 2015 at 10:16:24AM -0500, Nicolas Pitre wrote:
> > On Tue, 27 Jan 2015, Pavel Machek wrote:
> > > (Note, that in 3.19 dts for n900 got too big, so we are actually
> > > triggering old bugs. That means that this is a regression fix, and
> > > should go in ASAP).
> > 
> > It is queued here:
> > http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8294/1
> 
> Irrespective of that patch, I commented on another thread (about adding
> the serial number to DT):
> 
> | How about something a little more radical.
> | 
> | Rather than trying to squeeze various ATAGs into DT, why don't we add a
> | standard ATAG to contain the DT and pass that through into the kernel.
> | This is IMHO how we _should_ have done the ATAG compatibility from the
> | start.
> | 
> | That means we could get rid of most of the libfdt in the decompressor,
> | and instead resolve the differences in the kernel.
> 
> That would allow us to get rid of all the FDT compatibility code in the
> decompressor, and when we encounter these special ATAGs, we can deal with
> them in the kernel instead of having to mess around with the DT.  I'd
> also assume (although I haven't checked) that it would be much easier to
> add additional DT properties in the kernel environment, rather than in
> the rather restrictive decompressor environment.

Well...

I was initially against any ATAG-to-DT compatibility at all.  IMHO the 
"right" solution is to update the bootloader.

However people complained that updating the bootloader wasn't possible. 
I therefore suggested they go with a shim layer I termed the "impedance 
matcher" acting like an intermediate boot stage converting their (often 
unofficial and out-of-tree) ATAGs into proper DT nodes.  Some people did 
exactly that and it works wonderfully for them. It also works 
wonderfully for kernel maintenance as the platform specific tweaks are 
kept out of the kernel tree.

Still, that wasn't good enough for some cases as the move to DT 
regressed some platforms that just used to work before.  Concatenating a 
DTB to zImage was tolerable but installing an additional shim layer was 
too much.  Hence the ATAG-to-DT compat code in the decompressor.  This 
was meant to smooth things around the transition to DT, etc.  After all, 
those devices with non-replaceable bootloaders where shim layers are not 
possible should get out of commission eventually?

> We'd need to be careful about how we deal with the atags vs DT.  I'd
> suggest (as above) that we have a tag which points at the DT in
> physical memory, and its size, and pre-scan the atag list for that.
> When we find it, we kick off the DT based stuff as we would normally
> do, and follow it with a parse of the atags.  This would cause the
> atags to override whatever is in the DT, which afaics is the behaviour
> that we actually want.

Maybe.  However that would be yet another scheme for supporting legacy 
platforms with locked bootloaders.  I really think we have enough of 
them already and I'd much prefer if we started _removing_ them not 
creating additional ones.  The ATAG-to-DT code in the bootloader is 
still rather small and it works quite well, and it allows for 
configuring out ATAG support out of the kernel entirely.  It should be 
sufficient for all the official (e.g. upstream) ATAGs already.  If 
that's not good enough then people should consider the impedance matcher 
approach.

> We could augment that with code to update DT too so that we can export
> just the DT based information to kexec'd kernels.

That should already be the case, no?


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