linux-kernel - RE: [PATCH 4/9] ARM: add CONFIG_PHYS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <HK2PR06MB0561C34E8FE1480224C2C6778AA00@HK2PR06MB0561.apcprd06.prod.outlook.com>
Date:	Fri, 19 Feb 2016 17:18:46 +0000
From:	Chris Brandt <Chris.Brandt@...esas.com>
To:	Russell King - ARM Linux <linux@....linux.org.uk>,
	Arnd Bergmann <arnd@...db.de>
CC:	Nicolas Pitre <nicolas.pitre@...aro.org>,
	Jon Medhurst <tixy@...aro.org>,
	Ard Biesheuvel <ard.biesheuvel@...aro.org>,
	Marc Zyngier <marc.zyngier@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: RE: [PATCH 4/9] ARM: add CONFIG_PHYS_OFFSET default values

On 19 Feb 2016, Russell King wrote:

> Using the DTB location on XIP platforms is a no-goer - the flattened
> DTB information can be fixed, so on an XIP platform it makes sense
> for this to also be in flash, not in RAM (the whole point of XIP is
> to remove constant data from RAM after all, so why would you want to
> copy the FDT to RAM?)

I was under the impression that the DTB had a limited life span, and once booted, it could be clobbered. Hence, RAM would not really be wasted (post boot that is).

For an XIP system (with MMU), if you have your DTB in ROM someplace, you run the risk of getting it cut off after the MMU setup is done because it would fall someplace after the _exiprom marker.


> Passing it in a register to the kernel image is also not possible:
> we've been out of spare registers for some time now for passing
> additional information into the kernel.  It wouldn't be a problem
> had folk not had this "eww, I don't like ATAGs, lets get rid of them
> and use DT instead" attitude: had we kept ATAGs, then we'd have an
> in-memory format to pass this kind of information to the kernel.
> That would solve soo many problems today it's untrue: stuff like
> where a debugging UART is located and the type of it...

Too bad we just couldn't have added an ATAG to point to a DTB. Sigh.


Chris