[PATCH] ARM: mvebu: fix RAM size for Armada XP board DB-MV784MP-GP

Jason Gunthorpe jgunthorpe at obsidianresearch.com
Wed Mar 13 14:30:54 EDT 2013


On Wed, Mar 13, 2013 at 06:43:24PM +0100, Andrew Lunn wrote:
> On Wed, Mar 13, 2013 at 11:35:59AM -0600, Jason Gunthorpe wrote:
> > On Wed, Mar 13, 2013 at 03:37:00PM +0100, Gregory CLEMENT wrote:
> > 
> > > >> +		 * size of the module actually plugged
> > > >>   		 */
> > > >> -		reg = <0x00000000 0xC0000000>;
> > > >> +		reg = <0x00000000 0xD0000000>;
> > > > 
> > > >     But this is not 4G?
> > > 
> > > You're totally right!
> > > It should be reg = <0x00000000 0xF0000000>;
> > 
> > Isn't it 'right' as it is? The various included DT's put devices at
> > address 0xd0008000 for instance, memory shouldn't overlap that..
> 
> Shouldn't DT describe the hardware? The hardware has 4GB. How much of
> it Linux decides to use so as to avoid overlaps with registers etc, is
> not a hardware issue, but software.

Sure, but which HW? The 'reg' in 'memory' is not describing a DDR
bus. It is describing the DDR address mapping registers in the SOC -
and they are probably set for 0 -> 0xD0000000 by the firmware.

To describe the 4G of DDR you need DT nodes that show:
- The N DDR chip selects going to each DDR rank
- How much memory is in each DDR rank
- How each chip select is currently mapped into CPU address space

This is the minimal amount of information needed for Linux to
reprogram the entire address map, if it so chooses.

To me, the *address map* in the DTB passed from the firwmare should
reflect the state of the machine when the OS is started. That way an
OS without drivers for the address map hardware will function
properly.

Regards,
Jason



More information about the linux-arm-kernel mailing list