[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151130153933.GD29576@pali>
Date: Mon, 30 Nov 2015 16:39:33 +0100
From: Pali Rohár <pali.rohar@...il.com>
To: Tony Lindgren <tony@...mide.com>
Cc: Nicolas Pitre <nicolas.pitre@...aro.org>,
Russell King - ARM Linux <linux@....linux.org.uk>,
Arnd Bergmann <arnd@...db.de>,
linux-arm-kernel@...ts.infradead.org,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com>,
Laura Abbott <lauraa@...eaurora.org>,
Sebastian Reichel <sre@...ian.org>,
Will Deacon <will.deacon@....com>,
linux-kernel@...r.kernel.org, Rob Herring <robherring2@...il.com>,
Pavel Machek <pavel@....cz>,
Grant Likely <grant.likely@...aro.org>,
linux-omap@...r.kernel.org, Frank Rowand <frowand.list@...il.com>,
Andreas Färber <afaerber@...e.de>
Subject: Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT
"/chosen/linux,atags" entry
On Monday 30 November 2015 07:23:53 Tony Lindgren wrote:
> * Pali Rohár <pali.rohar@...il.com> [151129 16:16]:
> > On Monday 30 November 2015 01:09:17 Nicolas Pitre wrote:
> > > On Sun, 29 Nov 2015, Russell King - ARM Linux wrote:
> > > > On Sat, Nov 28, 2015 at 12:34:23PM -0500, Nicolas Pitre wrote:
> > > > > Good. And Arnd likes the idea too. So we might be converging at
> > > > > last which is a good thing.
> > > >
> > > > I disagree with the idea that there is convergence. There might be
> > > > convergence towards an idea, but... Here's a mail extract, from
> > > > July 7th, from earlier in this very thread:
> > > >
> > > > Pali:
> > > > > Me:
> > > > > > Are the ATAGs at a fixed address on the N900?
> > > > >
> > > > > Yes, in board-rx51.c is:
> > > > >
> > > > > .atag_offset = 0x100
> > > > >
> > > > > and Nokia Bootloader (proprietary) store them to that address.
> > > > >
> > > > > > Can that be handled in
> > > > > > some kind of legacy file for the N900 which calls save_atags()
> > > > > > on it, so we don't end up introducing yet more stuff that we
> > > > > > have to maintain into the distant future? If not, what about
> > > > > > copying a known working atag structure into a legacy file for
> > > > > > the N900?
> > > > >
> > > > > I already asked question if it is possible to read ATAGs from DT
> > > > > booted kernel. And somebody (do not remember who) wrote to ML,
> > > > > that it is not possible and it can be done in that uncompress
> > > > > code.
> > >
> > > Who is that somebody? If ever it happened to be me then objection is
> > > withdrawn. Otherwise that somebody should come forth and speak up
> > > again.
> > >
> >
> > ... do not remember ... this discussion were in more email threads and
> > takes more then one year... sorry but my memory is not excellent
>
> Yes this certainly seems like the best solution. I think we got into
> the atags-to-dt track as some of the atags are already being translated.
>
> In this case there's no need to translate them AFAIK. You can just
> parse them and have them available for the user space. So as long as
> nothing trashes the atags at the atag_offset, you should be able to
> call a function to parse them in the n900 specific init_machine.
>
> Regards,
>
> Tony
In arch/arm/kernel/setup.c is function setup_arch() and it calls:
mdesc = setup_machine_fdt(__atags_pointer);
if (!mdesc)
mdesc = setup_machine_tags(__atags_pointer, __machine_arch_type);
So it looks like that on atags address is stored either atags structure
or DT structure... so it is truth kernel uncompress code put DT blob to
same offset where is expected atags structure? If yes, then this is
probably reason why atags cannot be read from booted DT kernel. Can
somebody with deep knowledge of DT/atags and uncompress code verify this?
--
Pali Rohár
pali.rohar@...il.com
--
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