This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: framebuffer corruption due to overlapping stp instructions on arm64
- From: Mikulas Patocka <mpatocka at redhat dot com>
- To: Andrew Pinski <pinskia at gmail dot com>
- Cc: Catalin Marinas <catalin dot marinas at arm dot com>, Will Deacon <will dot deacon at arm dot com>, linux at armlinux dot org dot uk, thomas dot petazzoni at free-electrons dot com, linux-arm-kernel at lists dot infradead dot org, LKML <linux-kernel at vger dot kernel dot org>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 3 Aug 2018 09:31:16 -0400 (EDT)
- Subject: Re: framebuffer corruption due to overlapping stp instructions on arm64
- References: <alpine.LRH.2.02.1808021242320.31834@file01.intranet.prod.int.rdu2.redhat.com> <CA+=Sn1mWkjuwVnjw6OWWUM=UcP76bdFa680FebCseewHfx3NpA@mail.gmail.com>
On Fri, 3 Aug 2018, Andrew Pinski wrote:
> On Thu, Aug 2, 2018 at 12:31 PM Mikulas Patocka <mpatocka@redhat.com> wrote:
> >
> > Hi
> >
> > I tried to use a PCIe graphics card on the MacchiatoBIN board and I hit a
> > strange problem.
> >
> > When I use the links browser in graphics mode on the framebuffer, I get
> > occasional pixel corruption. Links does memcpy, memset and 4-byte writes
> > on the framebuffer - nothing else.
> >
> > I found out that the pixel corruption is caused by overlapping unaligned
> > stp instructions inside memcpy. In order to avoid branching, the arm64
> > memcpy implementation may write the same destination twice with different
> > alignment. If I put "dmb sy" between the overlapping stp instructions, the
> > pixel corruption goes away.
> >
> > This seems like a hardware bug. Is it a known errata? Do you have any
> > workarounds for it?
>
> Yes fix Links not to use memcpy on the framebuffer.
> It is undefined behavior to use device memory with memcpy.
>
> Thanks,
> Andrew Pinski
Links can be fixed easily - but there is exterme amount of code that
accesses videoram via C pointers in the Xserver and in the GPU drivers.
How do you intend to fix that?
What should we use instead of direct access or memcpy? Libc doesn't
provide any macros or functions for framebuffer access. Using hardcoded
assembler doesn't make the the programs portable.
Mikulas