[PATCH] ARM: dts: aspeed: Update reserved memory nodes for zaius and witherspoon

[Patrick Williams]

On Fri, Feb 17, 2017 at 01:48:41PM +1100, Cyril Bur wrote:
> On Thu, 2017-02-16 at 08:05 -0600, Patrick Williams wrote:
> > On Thu, Feb 16, 2017 at 04:49:22PM +1100, Cyril Bur wrote:
> > > -		flash_memory: region at 94000000 {
> > > +		flash_memory: region at 98000000 {
> > >  			no-map;
> > > -			reg = <0x94000000 0x04000000>; /* 64M */
> > > +			reg = <0x98000000 0x04000000>; /* 64M */
> > > +		};
> > > +
> > > +		vga_memory: framebuffer at 9c000000 {
> > > +			no-map;
> > > +			reg = <0x9c000000 0x04000000>; /* 64MB */
> > 
> > Do we really have to allocate 64MB to a VGA framebuffer?  We can store a
> > 4K resolution monitor with 32bit color in 32MB, so why is it required to
> > reserve this much memory?  Between this and the PNOR memory region, now
> > 1/4th of the BMCs memory is reserved.
> 
> The reservation of 64MB is because the hardware is capable of using
> 64MB, therefore the host can use that region of memory. We're playing
> it safe here by ensuring the BMC doesn't use any of it to avoid any
> possibility of the host corrupting BMC memory. This is the most generic
> dts for the platform so we've gone with stability over performance.

Is there anything the BMC can do to restrict how big of a memory map the
host side of the VGA can open up?  If there isn't we're going to have to
allocate this much on all systems because we can't trust the host to
"behave".

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20170220/43d33b1b/attachment.sig>