Re: N900 v3.19-rc5 arm atags_to_fdt.c is broken

[Russell King - ARM Linux <linux@arm.linux.org.uk>]

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.

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.

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

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.