Re: System hang when using SetMemoryAttributes

[Michael Zimmermann <sigmaepsilon92@gmail.com>]

Ard,

I have to mark the framebuffer as uncached, because if writes to it are
cached, they don't instantly reach the underlying hardware. I'd have to
manually flush the cache for that region every time otherwise.

Isn't that the normal way? I don't think that any device would work with a
write-cache framebuffer - I actually copied the code from the ArmVirt LCD
drivers which do the same.

Thanks
Michael

On Mon, Sep 26, 2016 at 8:35 AM, Ard Biesheuvel <ard.biesheuvel@linaro.org>
wrote:

> On 25 September 2016 at 20:01, Michael Zimmermann
> <sigmaepsilon92@gmail.com> wrote:
> > Hi,
> >
> > which side effects can SetMemoryAttributes have?
> > I have a device where setting the framebuffer(which is part of DRAM) to
> > EFI_MEMORY_UC makes UEFI hang later on(when already outside the lcd
> driver).
> >
> > If I do the same on a memory range allocated with AllocateAnyPages
> instead
> > of AllocateAddress UEFI boots just fine(but ofc, the screen doesn't
> work).
> >
> > Unfortunately I don't have UART on that device but I'm sure there's no
> > assert because I configured DebugLib to reboot the device in that case -
> > which never happens, it's just stuck when the console drivers(TerminalDxe
> > etc) initialize later on.
> >
>
> Hello Michael,
>
> EFI_MEMORY_WC is more suitable for a framebuffer than EFI_MEMORY_UC,
> since the latter does not allow unaligned accesses, so any unaligned
> store will crash the system.
>
> Since the framebuffer is in DRAM, I assume the reason for setting the
> memory attributes is that the device is not DMA coherent? Could you
> perhaps describe the hardware in more detail?
>
> --
> Ard.
>