-----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://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi

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

Cheers,
Prabhakar