linux-kernel - Re: [PATCH 5/5] arm: dts: Convert mvebu device tree files to 64 bits

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]

Date:	Thu, 21 Mar 2013 21:22:36 +0100
From:	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>
To:	Andrew Lunn <andrew@...n.ch>
Cc:	Gregory CLEMENT <gregory.clement@...e-electrons.com>,
	Jason Cooper <jason@...edaemon.net>,
	Grant Likely <grant.likely@...retlab.ca>,
	Rob Herring <rob.herring@...xeda.com>,
	Ezequiel Garcia <ezequiel.garcia@...e-electrons.com>,
	linux-arm-kernel@...ts.infradead.org,
	devicetree-discuss@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
	Arnd Bergmann <arnd@...db.de>, Olof Johansson <olof@...om.net>,
	Nicolas Pitre <nico@...xnic.net>,
	Lior Amsalem <alior@...vell.com>,
	Maen Suleiman <maen@...vell.com>,
	Tawfik Bayouk <tawfik@...vell.com>,
	Shadi Ammouri <shadi@...vell.com>,
	Eran Ben-Avi <benavi@...vell.com>,
	Yehuda Yitschak <yehuday@...vell.com>,
	Nadav Haklai <nadavh@...vell.com>,
	Ike Pan <ike.pan@...onical.com>,
	Chris Van Hoof <vanhoof@...onical.com>,
	Dan Frazier <dann.frazier@...onical.com>,
	Leif Lindholm <leif.lindholm@....com>,
	Jon Masters <jcm@...hat.com>,
	David Marlin <dmarlin@...hat.com>,
	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>
Subject: Re: [PATCH 5/5] arm: dts: Convert mvebu device tree files to 64
 bits

Dear Andrew Lunn,

On Thu, 21 Mar 2013 21:15:33 +0100, Andrew Lunn wrote:

> Could you recommend a document which introduces LPAE.
> 
> Only being able to address 7GB seems a bit odd to me. I kind of
> expected you set up the translation tables to map a page in the 32 bit
> address range to any arbitrary page in the 40 bit address range. So
> leaving 0xC0000000 to 0xffffffff in the 32bit address range clear is
> easy. But why do you loose space in the 40bit address range?

translation tables convert virtual addresses to physical addresses.
Here, we are only talking about physical addresses. There is an overlap
between the physical addresses used by the RAM, and the physical
addresses at which I/O devices are visible.

And I'm not sure the SDRAM address decoding windows allows to split the
first 4 GB of RAM into two areas, one that would be mapped starting at
physical address 0x0, and another area that would be mapped at a
different address (above 4 GB).

However, I'm unsure why 0xC0000000 was chosen. Why not 0xD0000000,
where the internal registers currently start?

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.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/