Hi Chris,

after getting qemu-riscv64 ready (patches will come tomorrow), I also
had a quick look at the RZ/Five eval board you shared with us. But that
raised a couple of questions, maybe you can help:

- Why is the default U-Boot hard-wired to a very special boot mode? I'm
missing standard distro boot - which would include UEFI as well.

- Where is the U-Boot tree (upstream support is apparently missing)?
I'm still trying to understand the instructions how to replace it in
QSPI, but first I need a fixable source tree.

- Where is the kernel tree (also no upstream support yet)?

- Can I reconfigure the carrier board to automatically power-on after a
power cycle? Without that, it would be impossible to add the board to
a remote lab.

Thanks,
Jan

--
Siemens AG, Technology
Competence Center Embedded Linux

Hello Jan,

From: Jan Kiszka <jan.kiszka@...>
Sent: 03 October 2022 19:36

Hi Chris,

after getting qemu-riscv64 ready (patches will come tomorrow), I also

Huzzah

had a quick look at the RZ/Five eval board you shared with us. But that
raised a couple of questions, maybe you can help:

I can try :)

- Why is the default U-Boot hard-wired to a very special boot mode? I'm
missing standard distro boot - which would include UEFI as well.

Good question.
@Prabhakar Mahadev Lad or @Hung Tran, could you help answer this?

- Where is the U-Boot tree (upstream support is apparently missing)?
I'm still trying to understand the instructions how to replace it in
QSPI, but first I need a fixable source tree.

The Yocto BSP is here: https://github.com/renesas-rz/meta-rzg2/tree/dunfell/rzfive
The U-Boot recipe points to https://github.com/renesas-rz/renesas-u-boot-cip/tree/v2021.12/rzf-smarc

You're obviously welcome to fork/fixup as you like.

- Where is the kernel tree (also no upstream support yet)?

Kernel tree used by the current BSP is here: https://github.com/renesas-rz/rz_linux-cip/tree/rzfive-5.10-cip1

Upstreaming is still in progress.
We're having some fun sharing things between arm64 and riscv, but we're getting there.
I'm hoping we'll have something bootable in v6.2.

- Can I reconfigure the carrier board to automatically power-on after a
power cycle? Without that, it would be impossible to add the board to
a remote lab.

Yea it's a bit of a pain.
Two changes are actually needed to get these smarc platforms into a remote lab.
1) Change the power wiring so that everything powers on as soon as the AC connector is powered
2) Power the USB serial connection from the USB so it's always on

Let me know if you want the instructions for making these mods to the board.
Note that we'll provide pre-modified boards for the CIP labs when the time comes.

Kind regards, Chris

Thanks,
Jan

--
Siemens AG, Technology
Competence Center Embedded Linux

On 03.10.22 22:12, Chris Paterson wrote:

Hello Jan,

From: Jan Kiszka <jan.kiszka@...>
Sent: 03 October 2022 19:36

Hi Chris,

after getting qemu-riscv64 ready (patches will come tomorrow), I also

Huzzah

had a quick look at the RZ/Five eval board you shared with us. But that
raised a couple of questions, maybe you can help:

I can try :)

- Why is the default U-Boot hard-wired to a very special boot mode? I'm
missing standard distro boot - which would include UEFI as well.

Good question.
@Prabhakar Mahadev Lad or @Hung Tran, could you help answer this?

- Where is the U-Boot tree (upstream support is apparently missing)?
I'm still trying to understand the instructions how to replace it in
QSPI, but first I need a fixable source tree.

The Yocto BSP is here: https://github.com/renesas-rz/meta-rzg2/tree/dunfell/rzfive
The U-Boot recipe points to https://github.com/renesas-rz/renesas-u-boot-cip/tree/v2021.12/rzf-smarc

You're obviously welcome to fork/fixup as you like.

How is the upstreaming status here? For UEFI, a U-Boot from this year is
needed.

- Where is the kernel tree (also no upstream support yet)?

Kernel tree used by the current BSP is here: https://github.com/renesas-rz/rz_linux-cip/tree/rzfive-5.10-cip1

Upstreaming is still in progress.
We're having some fun sharing things between arm64 and riscv, but we're getting there.
I'm hoping we'll have something bootable in v6.2.

I see - over 700 patches for 5.10-cip...

- Can I reconfigure the carrier board to automatically power-on after a
power cycle? Without that, it would be impossible to add the board to
a remote lab.

Yea it's a bit of a pain.
Two changes are actually needed to get these smarc platforms into a remote lab.
1) Change the power wiring so that everything powers on as soon as the AC connector is powered
2) Power the USB serial connection from the USB so it's always on

Let me know if you want the instructions for making these mods to the board.
Note that we'll provide pre-modified boards for the CIP labs when the time comes.

Ah, ok. Thanks!

Jan

--
Siemens AG, Technology
Competence Center Embedded Linux

On 04.10.22 09:15, Jan Kiszka wrote:

On 03.10.22 22:12, Chris Paterson wrote:

Hello Jan,

From: Jan Kiszka <jan.kiszka@...>
Sent: 03 October 2022 19:36

Hi Chris,

after getting qemu-riscv64 ready (patches will come tomorrow), I also

Huzzah

had a quick look at the RZ/Five eval board you shared with us. But that
raised a couple of questions, maybe you can help:

I can try :)

- Why is the default U-Boot hard-wired to a very special boot mode? I'm
missing standard distro boot - which would include UEFI as well.

Good question.
@Prabhakar Mahadev Lad or @Hung Tran, could you help answer this?

- Where is the U-Boot tree (upstream support is apparently missing)?
I'm still trying to understand the instructions how to replace it in
QSPI, but first I need a fixable source tree.

The Yocto BSP is here: https://github.com/renesas-rz/meta-rzg2/tree/dunfell/rzfive
The U-Boot recipe points to https://github.com/renesas-rz/renesas-u-boot-cip/tree/v2021.12/rzf-smarc

You're obviously welcome to fork/fixup as you like.

How is the upstreaming status here? For UEFI, a U-Boot from this year is
needed.

- Where is the kernel tree (also no upstream support yet)?

Kernel tree used by the current BSP is here: https://github.com/renesas-rz/rz_linux-cip/tree/rzfive-5.10-cip1

Upstreaming is still in progress.
We're having some fun sharing things between arm64 and riscv, but we're getting there.
I'm hoping we'll have something bootable in v6.2.

I see - over 700 patches for 5.10-cip...

...and it's based on an outdated CIP baseline. We are specifically
missing "riscv: fix build with binutils 2.38", compared to latest CIP
kernels. Those happily build with the Debian toolchain.

Fixing up locally for now.

Jan

--
Siemens AG, Technology
Competence Center Embedded Linux

On 04.10.22 20:28, Jan Kiszka wrote:

On 04.10.22 09:15, Jan Kiszka wrote:

On 03.10.22 22:12, Chris Paterson wrote:

Hello Jan,

From: Jan Kiszka <jan.kiszka@...>
Sent: 03 October 2022 19:36

Hi Chris,

after getting qemu-riscv64 ready (patches will come tomorrow), I also

Huzzah

had a quick look at the RZ/Five eval board you shared with us. But that
raised a couple of questions, maybe you can help:

I can try :)

- Why is the default U-Boot hard-wired to a very special boot mode? I'm
missing standard distro boot - which would include UEFI as well.

Good question.
@Prabhakar Mahadev Lad or @Hung Tran, could you help answer this?

- Where is the U-Boot tree (upstream support is apparently missing)?
I'm still trying to understand the instructions how to replace it in
QSPI, but first I need a fixable source tree.

The Yocto BSP is here: https://github.com/renesas-rz/meta-rzg2/tree/dunfell/rzfive
The U-Boot recipe points to https://github.com/renesas-rz/renesas-u-boot-cip/tree/v2021.12/rzf-smarc

You're obviously welcome to fork/fixup as you like.

How is the upstreaming status here? For UEFI, a U-Boot from this year is
needed.

- Where is the kernel tree (also no upstream support yet)?

Kernel tree used by the current BSP is here: https://github.com/renesas-rz/rz_linux-cip/tree/rzfive-5.10-cip1

Upstreaming is still in progress.
We're having some fun sharing things between arm64 and riscv, but we're getting there.
I'm hoping we'll have something bootable in v6.2.

I see - over 700 patches for 5.10-cip...

...and it's based on an outdated CIP baseline. We are specifically
missing "riscv: fix build with binutils 2.38", compared to latest CIP
kernels. Those happily build with the Debian toolchain.

Fixing up locally for now.

root@demo:~# cat /sys/firmware/devicetree/base/model ; echo
Renesas SMARC EVK based on r9a07g043f01
root@demo:~# cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux bookworm/sid"
NAME="Debian GNU/Linux"
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
BUILD_ID="698957d5-dirty"
VARIANT="CIP Core image"
VARIANT_VERSION="1.0"

But due to the weird U-Boot setup, I had to add some hacks, rather than
a proper boot process.

Jan

--
Siemens AG, Technology
Competence Center Embedded Linux

On 04.10.22 21:36, Jan Kiszka wrote:

On 04.10.22 20:28, Jan Kiszka wrote:

On 04.10.22 09:15, Jan Kiszka wrote:

On 03.10.22 22:12, Chris Paterson wrote:

Hello Jan,

From: Jan Kiszka <jan.kiszka@...>
Sent: 03 October 2022 19:36

Hi Chris,

after getting qemu-riscv64 ready (patches will come tomorrow), I also

Huzzah

had a quick look at the RZ/Five eval board you shared with us. But that
raised a couple of questions, maybe you can help:

I can try :)

- Why is the default U-Boot hard-wired to a very special boot mode? I'm
missing standard distro boot - which would include UEFI as well.

Good question.
@Prabhakar Mahadev Lad or @Hung Tran, could you help answer this?

- Where is the U-Boot tree (upstream support is apparently missing)?
I'm still trying to understand the instructions how to replace it in
QSPI, but first I need a fixable source tree.

The Yocto BSP is here: https://github.com/renesas-rz/meta-rzg2/tree/dunfell/rzfive
The U-Boot recipe points to https://github.com/renesas-rz/renesas-u-boot-cip/tree/v2021.12/rzf-smarc

You're obviously welcome to fork/fixup as you like.

How is the upstreaming status here? For UEFI, a U-Boot from this year is
needed.

- Where is the kernel tree (also no upstream support yet)?

Kernel tree used by the current BSP is here: https://github.com/renesas-rz/rz_linux-cip/tree/rzfive-5.10-cip1

Upstreaming is still in progress.
We're having some fun sharing things between arm64 and riscv, but we're getting there.
I'm hoping we'll have something bootable in v6.2.

I see - over 700 patches for 5.10-cip...

...and it's based on an outdated CIP baseline. We are specifically
missing "riscv: fix build with binutils 2.38", compared to latest CIP
kernels. Those happily build with the Debian toolchain.

Fixing up locally for now.

root@demo:~# cat /sys/firmware/devicetree/base/model ; echo
Renesas SMARC EVK based on r9a07g043f01
root@demo:~# cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux bookworm/sid"
NAME="Debian GNU/Linux"
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
BUILD_ID="698957d5-dirty"
VARIANT="CIP Core image"
VARIANT_VERSION="1.0"

But due to the weird U-Boot setup, I had to add some hacks, rather than
a proper boot process.

https://gitlab.com/cip-project/cip-core/isar-cip-core/-/commits/wip/rzfive

Test by flashing the image to an SD-Card switching to SD booting on the
module.

Maybe we can find a better solution for the boot procedure before moving
forward with this.

Anyway, now we have a real distribution on this board. Pavel, can you
re-check what you observed, if those issues persist with Debian?

Jan

--
Siemens AG, Technology
Competence Center Embedded Linux

Hi Jan,

Subject: Re: [cip-dev] Preparing isar-cip-core for RZ/Five

On 04.10.22 09:15, Jan Kiszka wrote:

On 03.10.22 22:12, Chris Paterson wrote:

Hello Jan,

From: Jan Kiszka <jan.kiszka@...>
Sent: 03 October 2022 19:36

Hi Chris,

after getting qemu-riscv64 ready (patches will come tomorrow), I
also

Huzzah

had a quick look at the RZ/Five eval board you shared with us. But
that raised a couple of questions, maybe you can help:

I can try :)

- Why is the default U-Boot hard-wired to a very special boot

mode? I'm

missing standard distro boot - which would include UEFI as

well.

Good question.
@Prabhakar Mahadev Lad or @Hung Tran, could you help answer this?

- Where is the U-Boot tree (upstream support is apparently

missing)?

I'm still trying to understand the instructions how to replace

it in

QSPI, but first I need a fixable source tree.

The Yocto BSP is here:


You're obviously welcome to fork/fixup as you like.

How is the upstreaming status here? For UEFI, a U-Boot from this

year

is needed.

- Where is the kernel tree (also no upstream support yet)?

Kernel tree used by the current BSP is here:

>>

Upstreaming is still in progress.
We're having some fun sharing things between arm64 and riscv, but

we're getting there.

I'm hoping we'll have something bootable in v6.2.

I see - over 700 patches for 5.10-cip...

RZ/Five and RZ/G2UL share same drivers except CPU, IRQ and Cache.

Already RZ/G2UL full support is available in 5.10-cip and we are going to reuse
the SoC and board dtsi from RZ/G2UL for RZ/Five.

So once, if we mainline CPU, IRQ and Cache and backport to 5.10-cip
We will have full support for 5.10-cip.

Cheers,
Biju

On 05.10.22 00:30, Prabhakar Mahadev Lad wrote:

Hi Jan,

-----Original Message-----
From: Chris Paterson <Chris.Paterson2@...>
Sent: 03 October 2022 21:13
To: Jan Kiszka <jan.kiszka@...>; Prabhakar Mahadev Lad
<prabhakar.mahadev-lad.rj@...>; Hung Tran
<hung.tran.jy@...>
Cc: cip-dev <cip-dev@...>
Subject: RE: Preparing isar-cip-core for RZ/Five

Hello Jan,

From: Jan Kiszka <jan.kiszka@...>
Sent: 03 October 2022 19:36

Hi Chris,

after getting qemu-riscv64 ready (patches will come tomorrow), I

also

Huzzah

had a quick look at the RZ/Five eval board you shared with us. But
that raised a couple of questions, maybe you can help:

I can try :)

- Why is the default U-Boot hard-wired to a very special boot mode?

I'm

missing standard distro boot - which would include UEFI as well.

Its just that we used the standard configs which we use for BSP releases. Looking at the u-boot code enabling distro boot should be straight forward as EFI is supported on RISC-V

Exactly - that's why I don't understand that you are not doing it
already. The default setup should be generic, easily extensible. But now
your users need to compile an own firmware and flash it, just to have a
standard boot procedure. And you won't be SystemReady this way as well.

Jan

--
Siemens AG, Technology
Competence Center Embedded Linux

Hi!

But due to the weird U-Boot setup, I had to add some hacks, rather than
a proper boot process.

https://gitlab.com/cip-project/cip-core/isar-cip-core/-/commits/wip/rzfive

Test by flashing the image to an SD-Card switching to SD booting on the
module.

Maybe we can find a better solution for the boot procedure before moving
forward with this.

Anyway, now we have a real distribution on this board. Pavel, can you
re-check what you observed, if those issues persist with Debian?

I believe I was running Debian; two versions and Ubuntu, IIRC :-).

Can you check if ldconfig and gcc work for you? That were the
roadblocks I was hitting. If they do, I'll be interested in details of
your setup.

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

On 05.10.22 20:21, Pavel Machek wrote:

Hi!

But due to the weird U-Boot setup, I had to add some hacks, rather than
a proper boot process.

https://gitlab.com/cip-project/cip-core/isar-cip-core/-/commits/wip/rzfive

Test by flashing the image to an SD-Card switching to SD booting on the
module.

Maybe we can find a better solution for the boot procedure before moving
forward with this.

Anyway, now we have a real distribution on this board. Pavel, can you
re-check what you observed, if those issues persist with Debian?

I believe I was running Debian; two versions and Ubuntu, IIRC :-).

Can you check if ldconfig and gcc work for you? That were the
roadblocks I was hitting. If they do, I'll be interested in details of
your setup.

Hmm, seems the issue persists:

root@demo:~# ldconfig
Illegal instruction

[ 297.146728] ldconfig[497]: unhandled signal 4 code 0x1 at 0x00000000000380c8 in ldconfig[10000+83000]
[ 297.146768] CPU: 0 PID: 497 Comm: ldconfig Not tainted 5.10.83-cip1-riscv-renesas #1
[ 297.146775] epc: 00000000000380c8 ra : 0000000000015382 sp : 0000003fffe01c10
[ 297.146782] gp : 0000000000099da8 tp : 0000003fda772800 t0 : 0000003fda7787c0
[ 297.146788] t1 : 0000003fda8065a8 t2 : 0000002acbbda7a0 s0 : 0000002afa2ec890
[ 297.146794] s1 : 0000000000000001 a0 : 0000003fffe01d18 a1 : 0000000000000001
[ 297.146800] a2 : 0000003fffe01c88 a3 : 0000000000000000 a4 : 0000003fffe01d18
[ 297.146806] a5 : 000000000009736e a6 : 0000003fffe01c80 a7 : 00000000000000dd
[ 297.146812] s2 : 0000003fffe01c88 s3 : 0000000000000000 s4 : 0000000000000000
[ 297.146819] s5 : 00000000000105a4 s6 : 000000000009e670 s7 : 0000002afa2ec850
[ 297.146824] s8 : 0000002afa2ec710 s9 : 0000000000000000 s10: 0000002acbbe39c8
[ 297.146830] s11: 0000002acbbe3938 t3 : 0000002acbaf2610 t4 : 00000000000925a8
[ 297.146835] t5 : 0000000000000004 t6 : 0000000000000000
[ 297.146842] status: 0000000200004020 badaddr: 00000000a01253cf cause: 0000000000000002

(gdb) disassemble $pc,+0x10
Dump of assembler code from 0x380c8 to 0x380d8:
=> 0x00000000000380c8: auipc a2,0x66
0x00000000000380cc: addi a2,a2,2000 # 0x9e898
0x00000000000380d0: sd a0,0(a2)
0x00000000000380d2: mv a5,sp
0x00000000000380d4: addi a4,sp,416
0x00000000000380d6: sd zero,0(a5)
End of assembler dump.

Do we have any instruction set restrictions that prevents the usage of
distros on this CPU? Under QEMU, we come along here as well and execute
this without problems. Some infamous Intel CPU comes to my mind at this
point - hope, history does not repeat here....

Jan

--
Siemens AG, Technology
Competence Center Embedded Linux

On 06.10.22 08:29, Jan Kiszka wrote:

On 05.10.22 20:21, Pavel Machek wrote:

Hi!

But due to the weird U-Boot setup, I had to add some hacks, rather than
a proper boot process.

https://gitlab.com/cip-project/cip-core/isar-cip-core/-/commits/wip/rzfive

Test by flashing the image to an SD-Card switching to SD booting on the
module.

Maybe we can find a better solution for the boot procedure before moving
forward with this.

Anyway, now we have a real distribution on this board. Pavel, can you
re-check what you observed, if those issues persist with Debian?

I believe I was running Debian; two versions and Ubuntu, IIRC :-).

Can you check if ldconfig and gcc work for you? That were the
roadblocks I was hitting. If they do, I'll be interested in details of
your setup.

Hmm, seems the issue persists:

root@demo:~# ldconfig
Illegal instruction

[ 297.146728] ldconfig[497]: unhandled signal 4 code 0x1 at 0x00000000000380c8 in ldconfig[10000+83000]
[ 297.146768] CPU: 0 PID: 497 Comm: ldconfig Not tainted 5.10.83-cip1-riscv-renesas #1
[ 297.146775] epc: 00000000000380c8 ra : 0000000000015382 sp : 0000003fffe01c10
[ 297.146782] gp : 0000000000099da8 tp : 0000003fda772800 t0 : 0000003fda7787c0
[ 297.146788] t1 : 0000003fda8065a8 t2 : 0000002acbbda7a0 s0 : 0000002afa2ec890
[ 297.146794] s1 : 0000000000000001 a0 : 0000003fffe01d18 a1 : 0000000000000001
[ 297.146800] a2 : 0000003fffe01c88 a3 : 0000000000000000 a4 : 0000003fffe01d18
[ 297.146806] a5 : 000000000009736e a6 : 0000003fffe01c80 a7 : 00000000000000dd
[ 297.146812] s2 : 0000003fffe01c88 s3 : 0000000000000000 s4 : 0000000000000000
[ 297.146819] s5 : 00000000000105a4 s6 : 000000000009e670 s7 : 0000002afa2ec850
[ 297.146824] s8 : 0000002afa2ec710 s9 : 0000000000000000 s10: 0000002acbbe39c8
[ 297.146830] s11: 0000002acbbe3938 t3 : 0000002acbaf2610 t4 : 00000000000925a8
[ 297.146835] t5 : 0000000000000004 t6 : 0000000000000000
[ 297.146842] status: 0000000200004020 badaddr: 00000000a01253cf cause: 0000000000000002

(gdb) disassemble $pc,+0x10
Dump of assembler code from 0x380c8 to 0x380d8:
=> 0x00000000000380c8: auipc a2,0x66
0x00000000000380cc: addi a2,a2,2000 # 0x9e898
0x00000000000380d0: sd a0,0(a2)
0x00000000000380d2: mv a5,sp
0x00000000000380d4: addi a4,sp,416
0x00000000000380d6: sd zero,0(a5)
End of assembler dump.

Do we have any instruction set restrictions that prevents the usage of
distros on this CPU? Under QEMU, we come along here as well and execute
this without problems. Some infamous Intel CPU comes to my mind at this
point - hope, history does not repeat here....

auipc was introduced with ISA 2.0, around 2019 - please don't tell me we
are on 1.0 here.

Jan

--
Siemens AG, Technology
Competence Center Embedded Linux

On 06.10.22 08:49, Jan Kiszka wrote:

On 06.10.22 08:29, Jan Kiszka wrote:

On 05.10.22 20:21, Pavel Machek wrote:

Hi!

But due to the weird U-Boot setup, I had to add some hacks, rather than
a proper boot process.

https://gitlab.com/cip-project/cip-core/isar-cip-core/-/commits/wip/rzfive

Test by flashing the image to an SD-Card switching to SD booting on the
module.

Maybe we can find a better solution for the boot procedure before moving
forward with this.

Anyway, now we have a real distribution on this board. Pavel, can you
re-check what you observed, if those issues persist with Debian?

I believe I was running Debian; two versions and Ubuntu, IIRC :-).

Can you check if ldconfig and gcc work for you? That were the
roadblocks I was hitting. If they do, I'll be interested in details of
your setup.

Hmm, seems the issue persists:

root@demo:~# ldconfig
Illegal instruction

[ 297.146728] ldconfig[497]: unhandled signal 4 code 0x1 at 0x00000000000380c8 in ldconfig[10000+83000]
[ 297.146768] CPU: 0 PID: 497 Comm: ldconfig Not tainted 5.10.83-cip1-riscv-renesas #1
[ 297.146775] epc: 00000000000380c8 ra : 0000000000015382 sp : 0000003fffe01c10
[ 297.146782] gp : 0000000000099da8 tp : 0000003fda772800 t0 : 0000003fda7787c0
[ 297.146788] t1 : 0000003fda8065a8 t2 : 0000002acbbda7a0 s0 : 0000002afa2ec890
[ 297.146794] s1 : 0000000000000001 a0 : 0000003fffe01d18 a1 : 0000000000000001
[ 297.146800] a2 : 0000003fffe01c88 a3 : 0000000000000000 a4 : 0000003fffe01d18
[ 297.146806] a5 : 000000000009736e a6 : 0000003fffe01c80 a7 : 00000000000000dd
[ 297.146812] s2 : 0000003fffe01c88 s3 : 0000000000000000 s4 : 0000000000000000
[ 297.146819] s5 : 00000000000105a4 s6 : 000000000009e670 s7 : 0000002afa2ec850
[ 297.146824] s8 : 0000002afa2ec710 s9 : 0000000000000000 s10: 0000002acbbe39c8
[ 297.146830] s11: 0000002acbbe3938 t3 : 0000002acbaf2610 t4 : 00000000000925a8
[ 297.146835] t5 : 0000000000000004 t6 : 0000000000000000
[ 297.146842] status: 0000000200004020 badaddr: 00000000a01253cf cause: 0000000000000002

(gdb) disassemble $pc,+0x10
Dump of assembler code from 0x380c8 to 0x380d8:
=> 0x00000000000380c8: auipc a2,0x66
0x00000000000380cc: addi a2,a2,2000 # 0x9e898
0x00000000000380d0: sd a0,0(a2)
0x00000000000380d2: mv a5,sp
0x00000000000380d4: addi a4,sp,416
0x00000000000380d6: sd zero,0(a5)
End of assembler dump.

Do we have any instruction set restrictions that prevents the usage of
distros on this CPU? Under QEMU, we come along here as well and execute
this without problems. Some infamous Intel CPU comes to my mind at this
point - hope, history does not repeat here....

auipc was introduced with ISA 2.0, around 2019 - please don't tell me we
are on 1.0 here.

Nope, it must be some other condition: I've found those instructions in
working binaries as well, and I was even able to modify one on-the-fly
to run the very same op-code there, without any trap.

Jan

--
Siemens AG, Technology
Competence Center Embedded Linux

Hi Jan,

On 06.10.22 09:08, Prabhakar Mahadev Lad wrote:

Hi Jan,

-----Original Message-----
From: Jan Kiszka <jan.kiszka@...>
Sent: 06 October 2022 07:50
To: Pavel Machek <pavel@...>; Chris Paterson
<Chris.Paterson2@...>; Prabhakar Mahadev Lad
<prabhakar.mahadev-lad.rj@...>; Hung Tran
<hung.tran.jy@...>
Cc: cip-dev <cip-dev@...>
Subject: Re: Preparing isar-cip-core for RZ/Five

On 06.10.22 08:29, Jan Kiszka wrote:

On 05.10.22 20:21, Pavel Machek wrote:

Hi!

But due to the weird U-Boot setup, I had to add some hacks,

rather

than a proper boot process.

https://gi

tlab.com%2Fcip-project%2Fcip-core%2Fisar-cip-core%2F-

%2Fcommits%2Fwi

p%2Frzfive&amp;data=05%7C01%7Cprabhakar.mahadev-

lad.rj%40bp.renesas.

com%7Cc8b33a1b0332467e04ce08daa7670053%7C53d82571da1947e49cb4625a166

a4a2a%7C0%7C0%7C638006358079991069%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM

C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%

7C%7C&amp;sdata=I2ajBytTSsUvSHp5wmkA1rgVz83rW%2B6aHGby1O2tyog%3D&amp

;reserved=0

Test by flashing the image to an SD-Card switching to SD booting

on

the module.

Maybe we can find a better solution for the boot procedure before
moving forward with this.

Anyway, now we have a real distribution on this board. Pavel, can
you re-check what you observed, if those issues persist with

Debian?

I believe I was running Debian; two versions and Ubuntu, IIRC :-).

Can you check if ldconfig and gcc work for you? That were the
roadblocks I was hitting. If they do, I'll be interested in details
of your setup.

Hmm, seems the issue persists:

root@demo:~# ldconfig
Illegal instruction

[ 297.146728] ldconfig[497]: unhandled signal 4 code 0x1 at
0x00000000000380c8 in ldconfig[10000+83000] [ 297.146768] CPU: 0

PID:

497 Comm: ldconfig Not tainted 5.10.83-cip1-riscv-renesas #1 [
297.146775] epc: 00000000000380c8 ra : 0000000000015382 sp :
0000003fffe01c10 [ 297.146782] gp : 0000000000099da8 tp :
0000003fda772800 t0 : 0000003fda7787c0 [ 297.146788] t1 :
0000003fda8065a8 t2 : 0000002acbbda7a0 s0 : 0000002afa2ec890 [
297.146794] s1 : 0000000000000001 a0 : 0000003fffe01d18 a1 :
0000000000000001 [ 297.146800] a2 : 0000003fffe01c88 a3 :
0000000000000000 a4 : 0000003fffe01d18 [ 297.146806] a5 :
000000000009736e a6 : 0000003fffe01c80 a7 : 00000000000000dd [
297.146812] s2 : 0000003fffe01c88 s3 : 0000000000000000 s4 :
0000000000000000 [ 297.146819] s5 : 00000000000105a4 s6 :
000000000009e670 s7 : 0000002afa2ec850 [ 297.146824] s8 :
0000002afa2ec710 s9 : 0000000000000000 s10: 0000002acbbe39c8 [
297.146830] s11: 0000002acbbe3938 t3 : 0000002acbaf2610 t4 :
00000000000925a8 [ 297.146835] t5 : 0000000000000004 t6 :
0000000000000000 [ 297.146842] status: 0000000200004020 badaddr:
00000000a01253cf cause: 0000000000000002

(gdb) disassemble $pc,+0x10
Dump of assembler code from 0x380c8 to 0x380d8:
=> 0x00000000000380c8: auipc a2,0x66
0x00000000000380cc: addi a2,a2,2000 # 0x9e898
0x00000000000380d0: sd a0,0(a2)
0x00000000000380d2: mv a5,sp
0x00000000000380d4: addi a4,sp,416
0x00000000000380d6: sd zero,0(a5)
End of assembler dump.

Do we have any instruction set restrictions that prevents the usage

of

distros on this CPU? Under QEMU, we come along here as well and
execute this without problems. Some infamous Intel CPU comes to my
mind at this point - hope, history does not repeat here....

auipc was introduced with ISA 2.0, around 2019 - please don't tell me
we are on 1.0 here.

I have seen similar issue with yocto dunfell release, If I go higher up to kirkstone release I see there is patch
add-riscv-support.patch [0] (I haven't tried this release yet though).

[0] https://git.openembedded.org/openembedded-core/tree/meta/recipes-core/glibc/ldconfig-native-2.12.1?h=kirkstone

I doubt that something that fundamental wouldn't be in the Debian
package as well. And it works fine over QEMU.

Jan

--
Siemens AG, Technology
Competence Center Embedded Linux

Hi!

Can you check if ldconfig and gcc work for you? That were the
roadblocks I was hitting. If they do, I'll be interested in details of
your setup.

Hmm, seems the issue persists:

:-(. Do you get gcc faulting, too?

root@demo:~# ldconfig
Illegal instruction

[ 297.146728] ldconfig[497]: unhandled signal 4 code 0x1 at 0x00000000000380c8 in ldconfig[10000+83000]

...

(gdb) disassemble $pc,+0x10
Dump of assembler code from 0x380c8 to 0x380d8:
=> 0x00000000000380c8: auipc a2,0x66
0x00000000000380cc: addi a2,a2,2000 # 0x9e898
0x00000000000380d0: sd a0,0(a2)

auipc is something rather simple. a2 = pc + 0x66 << something. Not
sure how it could fault. Plus we get "illegal instruction", suggesting
it is not some other fault.

Could some kind of self-modifying code be involved? I guess some kind
of debugging/watchpoint is not probable.

Do we have any instruction set restrictions that prevents the usage of
distros on this CPU? Under QEMU, we come along here as well and execute
this without problems. Some infamous Intel CPU comes to my mind at this
point - hope, history does not repeat here....

Which Intel CPU comes to mind? Pentium with its fdiv bug? I'd say
recent ones outdid it :-).

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

On 06.10.22 13:43, Pavel Machek wrote:

Hi!

Can you check if ldconfig and gcc work for you? That were the
roadblocks I was hitting. If they do, I'll be interested in details of
your setup.

Hmm, seems the issue persists:

:-(. Do you get gcc faulting, too?

I tried, but installation fails - illegal instruction.

root@demo:~# ldconfig
Illegal instruction

[ 297.146728] ldconfig[497]: unhandled signal 4 code 0x1 at 0x00000000000380c8 in ldconfig[10000+83000]

...

(gdb) disassemble $pc,+0x10
Dump of assembler code from 0x380c8 to 0x380d8:
=> 0x00000000000380c8: auipc a2,0x66
0x00000000000380cc: addi a2,a2,2000 # 0x9e898
0x00000000000380d0: sd a0,0(a2)

auipc is something rather simple. a2 = pc + 0x66 << something. Not
sure how it could fault. Plus we get "illegal instruction", suggesting
it is not some other fault.

Could some kind of self-modifying code be involved? I guess some kind
of debugging/watchpoint is not probable.

No idea - but why should ldconfig be self-modifying?

Do we have any instruction set restrictions that prevents the usage of
distros on this CPU? Under QEMU, we come along here as well and execute
this without problems. Some infamous Intel CPU comes to my mind at this
point - hope, history does not repeat here....

Which Intel CPU comes to mind? Pentium with its fdiv bug? I'd say
recent ones outdid it :-).

Quark :D
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738575%22

Jan

--
Siemens AG, Technology
Competence Center Embedded Linux