[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151215122038.GI30871@n2100.arm.linux.org.uk>
Date: Tue, 15 Dec 2015 12:20:38 +0000
From: Russell King - ARM Linux <linux@....linux.org.uk>
To: Pali Rohár <pali.rohar@...il.com>
Cc: Nicolas Pitre <nicolas.pitre@...aro.org>,
Tony Lindgren <tony@...mide.com>,
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 Tue, Dec 15, 2015 at 10:33:25AM +0100, Pali Rohár wrote:
> So am I understand correctly that solution would be to hack
> arch/arm/mm/mmu.c to not overwrite page at PHYS_OFFSET?
That's completely unnecessary: there are enough platform hooks to cope
with whatever the platform requires.
If you want to reserve the memory, then you have the ->reserve callback,
where you can call:
memblock_reserve(PHYS_OFFSET, PAGE_SIZE);
if you wish to prevent the first page being overwritten. You're then
responsible for freeing this page later in the boot sequence, or you
could just keep it around and refer to the atags in that page directly.
You could also just save_atags() in there, with a comment saying that
this is a work-around for N900 which needs the ATAGs saved, and this
is allowed in ->reserve as a special exception.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps 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