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

Joel Stanley joel at jms.id.au
Tue Feb 21 15:45:34 AEDT 2017


On Tue, Feb 21, 2017 at 2:46 PM, Patrick Williams <patrick at stwcx.xyz> wrote:
> 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".

Ben and Jeremy have been enhancing the host driver to be smarter. Ben,
what's the state of play?

Cheers,

Joel


More information about the openbmc mailing list