Re: System hang when using SetMemoryAttributes

[Michael Zimmermann <sigmaepsilon92@gmail.com>]

oh and in case it makes a difference: it's a 64bit ARM device running 32bit
code.

On Mon, Sep 26, 2016 at 9:13 AM, Michael Zimmermann <
sigmaepsilon92@gmail.com> wrote:

> 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.
>>
>
>