<somlo>
anyway, I like the idea of a maintained RV64G[C] design that's written in language that's not, um, "experimental" -- hope they stick around and maintain it in the long run
<sorear>
cva6?
<somlo>
doesn't look like it supports the "fd" part of "g", at least at a cursory glance -- so no Fedora distro capability (opensbi adamantly refuses to emulate f and d in m-mode :)
<somlo>
basically, I want RocketChip but written in Verilog, so it doesn't grind to a halt when all the Chisel-speaking contributors suddeny get fired
<somlo>
*suddenly
jacklsw has joined #riscv
<sorear>
what doesn't support fd?
<sorear>
... dunno why the cva6 README doesn't mention the FPU when the rest of the docs do
Tenkawa has quit [Quit: Was I really ever here?]
<somlo>
huh, maybe I should dedicate some spare cycles to studying cva6, then...
<Esmil>
I tried compiling the lpi4a branch of https://github.com/revyos/thead-u-boot.git with the light_lpi4a_defconfig, but that seems to lock up with the laste message:
<Revy[m]>
thead-kernel is also planned to change it.
<Esmil>
Revy[m]: The u-boot-with-spl-lpi4a.bin in Sipeeds debian image works. It says "U-Boot SPL 2020.01-ga50d8b9d", but the a50d8b9d commit is not in the repo above
<Revy[m]>
Some patches in sipeed are not synchronized to revyos.
<Esmil>
Revy[m]: ah, do you know where I can find their repo?
<Revy[m]>
I don't know. I need to ask sipeed.
prabhakarlad has joined #riscv
<Esmil>
Revy[m]: that would be great. Does the lpi4a branch with the light_lpi4a_defconfig work for you?
<Revy[m]>
If you're flashing a new uboot, you'll need the corresponding kernel. And reset the environment.
<Esmil>
Hmm.. but for me u-boot locks up before i even get a prompt to load a kernel
<Revy[m]>
The uboot and kernel from the T-Head release need to match.
<Revy[m]>
I plan to retest uboot on Monday.
<Esmil>
Revy[m]: ah, cool. it would be great if you could also enable CONFIG_EFI_LOADER=y CONFIG_CMD_EFIDEBUG=y CONFIG_CMD_NVEDIT_EFI=y
davidlt has quit [Read error: Connection reset by peer]
prabhakarlad90 has joined #riscv
prabhakarlad41 has joined #riscv
prabhakar73 has joined #riscv
prabhakarlad41 has quit [Client Quit]
prabhakar73 has quit [Client Quit]
prabhakarlad53 has joined #riscv
prabhakar83 has joined #riscv
prabhakarlad53 has quit [Client Quit]
prabhakar83 has quit [Client Quit]
prabhakar has quit [Ping timeout: 256 seconds]
prabhakarlad has quit [Ping timeout: 250 seconds]
prabhakarlad90 has quit [Ping timeout: 250 seconds]
prabhakarlad has joined #riscv
<Esmil>
Revy[m]: btw. on the Lichee Pi 4A the two ethernet phy's are on the same MDC and MDIO lines. if you want to you gmac0's mdio for phy0 and gmac1's mdio for phy1 you'd need to switch pinmux in-between the two gmac's can both control the same pins. alternatively you can just tell gmac1 use the phy through gmac0's mdio as is done here: