RE: [cip-dev] ldconfig segfault on RZ/Five was Re: Preparing isar-cip-core for RZ/Five

[Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@bp.renesas.com>]

[-- Attachment #1: Type: text/plain, Size: 4032 bytes --]

Hi All,

> -----Original Message-----
> From: Pavel Machek <pavel@denx.de>
> Sent: 13 October 2022 22:48
> To: Ulrich Hecht <uli@fpond.eu>
> Cc: cip-dev@lists.cip-project.org; Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@bp.renesas.com>;
> Jan Kiszka <jan.kiszka@siemens.com>; Florian Bezdeka <florian.bezdeka@siemens.com>; Chris Paterson
> <Chris.Paterson2@renesas.com>; Hung Tran <hung.tran.jy@renesas.com>; Pavel Machek <pavel@denx.de>
> Subject: Re: [cip-dev] ldconfig segfault on RZ/Five was Re: Preparing isar-cip-core for RZ/Five
> 
> Hi!
> 
> > > On 10/12/2022 11:50 AM CEST Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> > > I did a quick test with the patches pointed by Florian but unfortunately ldconfig still fails.
> >
> > I did some experiments on RZ/Five with this issue, and I'm almost positive that there is something
> wrong (or doesn't work as documented) with the icache handling on this SoC.
> >
> > 1. The issue only affects non-PIE executables (there are very few of those, basically just ldconfig,
> gcc, cpp and gcov* on the Debian system), and it occurs very early during the execution of the
> program. According to the datasheet, the cache on the ax45mp-1c core is virtually indexed, so it is
> unlikely that a PIE executable will ever hit anything in the cache when newly loaded, but it is much
> more likely with non-PIE executables.
> >
> 
> This is very good observation. Thanks!
> 
> And indeed it looks like _any_ non-PIE executable fails. See:
> 

Just a brief about the issue and solution:

TEXT_START_ADDR is the start of 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 cores have local memories 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 doesnt trigger a page fault and assume 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 virtual address of any statically compiled application doesnt 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 application 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.

I have attached a patch for binutils to the email. We plan to upstream this patch to binutils soon. 

Cheers,
Prabhakar

[-- Attachment #2: 0001-ld-emulparams-elf32lriscv-defs.sh-Adjust-TEXT_START_.patch --]
[-- Type: application/octet-stream, Size: 1307 bytes --]

From 91b9d727d696701bc0fa09a66a91fbfe3a639e55 Mon Sep 17 00:00:00 2001
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Date: Tue, 29 Nov 2022 11:14:08 +0000
Subject: [PATCH] ld: emulparams: elf32lriscv-defs.sh: Adjust TEXT_START_ADDR
 for RZ/Five
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

With applications compiled with a static flag the virtual address for the
applications may fall within H’0_0003_0000 - H’0_0004_FFFF where the ILM
and DLM blocks of the AX45MP exist.

The MMU won't trigger page faults when the virtual address falls in the
range of AX45MP local memory. So to make sure statically compiled
applications run successfully, adjust the TEXT_START_ADDR to 0x50000.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
 ld/emulparams/elf32lriscv-defs.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ld/emulparams/elf32lriscv-defs.sh b/ld/emulparams/elf32lriscv-defs.sh
index 91015d44..bba34c17 100644
--- a/ld/emulparams/elf32lriscv-defs.sh
+++ b/ld/emulparams/elf32lriscv-defs.sh
@@ -26,7 +26,7 @@ case "$target" in
     ;;
 esac
 
-TEXT_START_ADDR=0x10000
+TEXT_START_ADDR=0x50000
 MAXPAGESIZE="CONSTANT (MAXPAGESIZE)"
 COMMONPAGESIZE="CONSTANT (COMMONPAGESIZE)"
 
-- 
2.25.1