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]

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

On Thu, Mar 21, 2013 at 09:22:36PM +0100, Thomas Petazzoni wrote:

> 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).

On prior Marvell chips the SDRAM is mapped on a rank by rank basis, so
each rank can be placed in DRAM properly.
 
> However, I'm unsure why 0xC0000000 was chosen. Why not 0xD0000000,
> where the internal registers currently start?

Probably because the 8GB is composed of 4 2GB ranks and what was done
is to map like this:

  Rank 0 ->           0 ->  0x80000000 (2G)
  Rank 1 -> 0x080000000 -> 0x0C0000000 (2G rank, 1G mapped)
  Rank 2 -> 0x100000000 -> 0x180000000
  Rank 3 -> 0x180000000 -> 0x300000000

The ranks must be power of two sizes, and aligned to their size,
so it isn't possible to get closer to 0xD0000000.

To recover the lost RAM the entire rank would need to be located
above 4G.

Or, better, locate all the internal registers above 8G and use
contiguous DRAM mapping from 0 -> 8GB

Linux is sensitive to the ratio of high/low memory, if that gets too
big it struggles, maximizing low memory is desirable - I assume ARM is
basically the same as x86 in this regard?

> So why not map the whole SDRAM above 4GB physical address?

I think the no-MMU boot mode would break if this was done?

Jason
--
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/