[QUERY]: Adding support for a platform

[Lad, Prabhakar]

Hi Palmer,

On Tue, Nov 29, 2022 at 7:35 PM Palmer Dabbelt <palmer at dabbelt.com> wrote:
>
> On Tue, 29 Nov 2022 11:28:11 PST (-0800), prabhakar.csengg at gmail.com wrote:
> > Hi Palmer,
> >
> > Oops I should have included linux-riscv to the CC list here (doing it now)
> >
> > On Tue, Nov 29, 2022 at 7:20 PM Palmer Dabbelt <palmer at dabbelt.com> wrote:
> >>
> >> On Tue, 29 Nov 2022 11:16:29 PST (-0800), binutils at sourceware.org wrote:
> >> > Hi All,
> >> >
> >> > If this is not the right place to ask this question please let me know.
> >> >
> >> > So we have a RISCV platform (Renesas RZ/Five) for which we need to
> >> > adjust the TEXT_START_ADDR. So below are my queries:
> >> > * What is the procedure for upstreaming?
> >> > * Are patches accepted for individual platforms (for adjusting TEXT_START_ADDR)?
> >>
> >> Is this still related to that bug with the static binaries you'd
> >> mentioned before?  I think we'd really need to figure out the root cause
> >> before we can make a reasoned decision here, my guess would be that
> >> changing TEXT_START_ADDR just works around the real bug.
> >>
> > Below is the root cause and the solution:
> >
> > TEXT_START_ADDR is the start of the text segment of an application.
> > This is being set to 0x10000 for RISCV platforms.
> >
> > So when an application is compiled with the static flag the load would
> > start from 0x10000 - xyz (depending on size of the application)
> >
> > Entry point 0x101c0
> > There are 5 program headers, starting at offset 64Program Headers:
> >   Type           Offset             VirtAddr           PhysAddr
> >                  FileSiz            MemSiz              Flags  Align
> >   LOAD           0x0000000000000000 0x0000000000010000 0x0000000000010000
> >                  0x0000000000059b48 0x0000000000059b48  R E    0x1000
> >   LOAD           0x0000000000059b60 0x000000000006ab60 0x000000000006ab60
> >                  0x0000000000001f68 0x0000000000003528  RW     0x1000
> >
> > So for the above application which is compiled statically we can see
> > the entry point is 0x101c0 and load 0x0000000000010000.
> >
> > Andes AX45MP cores have local memory ILM and DLM that are mapped in
> > the region H’0_0003_0000 - H’0_0004_FFFF on the RZ/Five SoC. When the
> > virtual address falls in this range the MMU doesn't trigger a page
> > fault and assumes the virtual address as physical address and hence
> > the application fails to run (panics somewhere).
> >
> > So to avoid this issue we set the TEXT_START_ADDR to 0x50000 so that
> > the virtual address of any statically compiled application does not
> > fall in the range of H’0_0003_0000 - H’0_0004_FFFF.
> >
> > Elf file type is EXEC (Executable file)
> > Entry point 0x504e4
> > There are 5 program headers, starting at offset 64
> >
> > Program Headers:
> >   Type           Offset             VirtAddr           PhysAddr
> >                  FileSiz            MemSiz              Flags  Align
> >   LOAD           0x0000000000000000 0x0000000000050000 0x0000000000050000
> >                  0x0000000000057dc8 0x0000000000057dc8  R E    0x1000
> >   LOAD           0x00000000000585b8 0x00000000000a95b8 0x00000000000a95b8
> >                  0x0000000000004ee0 0x00000000000064b0  RW     0x1000
> >   NOTE           0x0000000000000158 0x0000000000050158 0x0000000000050158
> >                  0x0000000000000044 0x0000000000000044  R      0x4
> >
> > So now with the fix for statically compiled applications we can see
> > its offsetted and entry point is 0x504e4 and load is at
> > 0x0000000000050000. So with this we are for sure the MMU will always
> > trigger a page fault.
>
> OK, cool, that explains it.
>
> So I think we need to teach Linux about this platform-specific behavior
> so we can prevent any addresses in the offending VA range from being
> allocated.
Agreed, any pointers on doing this?

> Then it'll be up to userspace to deal with the fallout, if
> that means changing TEXT_START_ADDRESS it seems fine to me.  I'm not
> sure if there's already some sort of autoconf-type thing to change the
> default in binutils, if not then adding one seems like the way to go.
>
TBH I haven't explored the code yet if it was configurable using
autoconf. I'll have to do some digging.

> Then it's up to distros that want to run on the impacted hardware to
> make sure they rebuild all the impacted binaries.  I don't think there's
> any way around that for userspace-visible errata, and it this case the
> check for impacted binaries seems pretty manageable to write down (some
> sort of `find | objdump | grep` thing would probably do it).
>
Agreed.

Cheers,
Prabhakar