From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
To: Palmer Dabbelt <palmer@dabbelt.com>
Cc: binutils@sourceware.org, linux-riscv@lists.infradead.org
Subject: Re: [QUERY]: Adding support for a platform
Date: Tue, 29 Nov 2022 21:33:54 +0000 [thread overview]
Message-ID: <CA+V-a8vKStFdBwqjo+n-iVREtd3g1r_HFPABoijhrc9GVw3i6A@mail.gmail.com> (raw)
In-Reply-To: <mhng-17a43ac8-4700-48e4-9660-6f967328e8ab@palmer-ri-x1c9a>
Hi Palmer,
On Tue, Nov 29, 2022 at 7:35 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>
> On Tue, 29 Nov 2022 11:28:11 PST (-0800), prabhakar.csengg@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@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.
>
> 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
next prev parent reply other threads:[~2022-11-29 21:34 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-29 19:16 Lad, Prabhakar
2022-11-29 19:20 ` Palmer Dabbelt
2022-11-29 19:28 ` Lad, Prabhakar
2022-11-29 19:35 ` Palmer Dabbelt
2022-11-29 21:33 ` Lad, Prabhakar [this message]
2022-11-29 20:12 ` Jessica Clarke
2022-11-29 20:21 ` Andrew Waterman
2022-11-29 20:57 ` Palmer Dabbelt
2022-11-29 21:40 ` Lad, Prabhakar
2022-11-29 21:54 ` Palmer Dabbelt
2022-12-12 12:43 ` Lad, Prabhakar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CA+V-a8vKStFdBwqjo+n-iVREtd3g1r_HFPABoijhrc9GVw3i6A@mail.gmail.com \
--to=prabhakar.csengg@gmail.com \
--cc=binutils@sourceware.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).