[Macchiato] DRAM/PCIe remapping

Jeremy Linton jeremy.linton at arm.com
Wed Aug 9 17:07:52 BST 2017


Hi,

On 08/09/2017 10:00 AM, Matt Sealey wrote:
> Hi guys,
> 
> Apologies for not replying to a current thread, I just subscribed..
> 
> Further to the discussion on PCIe graphics cards and DRAM, I've been 
> struggling here to
> get the board to recognize that I was a little cash-happy and got the 
> 16GB package from
> SolidRun. I've spent a couple months being consummately disappointed in 
> only being able
> to reference 4GB from UEFI and Linux.
> 
> Ard's DRAM/PCIe remap patch seems to work relatively well
> ​ but the existing code doesn't
> map enough memory in the MMIO32 space for me; if I have a card that has 
> 2GB on it,

The usual place to map large PCIe BARs is in the 64bit MMIO ranges. Does 
this board not support a 64bit MMIO window?


Which card is that? (curious because I haven't seen a "consumer" GPU 
that supported large BARs. The tesla's/Phi's/etc which do have large 
64bit BARs end up with motherboard compatibility lists because some 
vendors think having a 64-bit MMIO window is "server" feature.)



> I'd
> like to stuff it in the lower 32-bit space. Is it
> really necessary
> to put any DRAM at
> all in the lower 32-bit space apart from the code setting up the
> windowing being in
> that DRAM at the time? Could we dedicate

Removing all RAM from the lower 4G results in machines which aren't 
compatible with PCIe boards that have "bugs" with 64bit addressing. 
Granted a machine with a working SMMU can work around this, but its 
generally a good idea to leave some RAM below 4G.


> the lower ~3GB or so
> to the PCIe space, and
> put a window of up to 16GB DRAM at a high physical
> address
> (what's the
> physical addressing
> limit on mochi?)
> 
> I'm failing to find any reasonable documentation on the io remapping 
> units, and things
> that might be in the way (the ATF diagrams seem to be Just Enough 
> Information (tm) to
> get you into trouble without really explaining why) so my poking
> on this is limited to
> pulling apart patches and trying to figure out the intent..
> 
> The other question is, is the limit of 4GB DRAM solely a device tree 
> issue combined
> with this?
> 
> 	# ARM Pcds
> 	gArmTokenSpaceGuid.PcdSystemMemoryBase|0
> 	gArmTokenSpaceGuid.PcdSystemMemorySize|0x100000000
> 	gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize|36
> 
> 
> 
> Or am I missing something? Is that '36' evidence of an upper limit for 
> windowing
> the DRAM up high? How does UEFI handle a sparse memory map if the 'base' 
> is 0 and
> it has a size, but not a way of breaking this out?
> 
> 
> Ta,
> Matt Sealey <neko at bakuhatsu.net <mailto:neko at bakuhatsu.net>>​
> 
> 
> _______________________________________________
> Macchiato mailing list
> Macchiato at lists.einval.com
> https://lists.einval.com/cgi-bin/mailman/listinfo/macchiato
> 




More information about the Macchiato mailing list