Re: [QUERY]: Adding support for a platform

["Lad, Prabhakar" <prabhakar.csengg@gmail.com>]

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@dabbelt.com> wrote:
>
> On Tue, 29 Nov 2022 11:16:29 PST (-0800), binutils@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.

Cheers,
Prabhakar