heat has quit [Read error: Connection reset by peer]
heat has joined #riscv
jn has quit [Ping timeout: 240 seconds]
FL4SHK has quit [Ping timeout: 240 seconds]
Andre_Z has joined #riscv
terminalpusher has quit [Remote host closed the connection]
MaxGanzII has quit [Remote host closed the connection]
MaxGanzII has joined #riscv
heat has quit [Remote host closed the connection]
heat has joined #riscv
heat_ has joined #riscv
heat has quit [Read error: Connection reset by peer]
heat_ is now known as heat
Andre_Z has quit [Quit: Leaving.]
jacklsw has joined #riscv
jay321 has joined #riscv
jay321 has quit [Ping timeout: 240 seconds]
jay321 has joined #riscv
jn has joined #riscv
jn has joined #riscv
jn has quit [Changing host]
jn_ has joined #riscv
jn_ has quit [Changing host]
jn_ has joined #riscv
jn has quit [Ping timeout: 265 seconds]
knolle has quit [Ping timeout: 256 seconds]
knolle has joined #riscv
Tenkawa has quit [Quit: Was I really ever here?]
bjoto has quit [Ping timeout: 240 seconds]
bjoto has joined #riscv
JanC has quit [Remote host closed the connection]
JanC has joined #riscv
terminalpusher has joined #riscv
Stat_headcrabed has quit [Quit: Stat_headcrabed]
vagrantc has joined #riscv
jacklsw has quit [Read error: Connection reset by peer]
terminalpusher has quit [Ping timeout: 245 seconds]
elastic_dog has quit [Killed (cadmium.libera.chat (Nickname regained by services))]
elastic_dog has joined #riscv
rurtty has quit [Ping timeout: 256 seconds]
wingsorc__ has joined #riscv
knolle has quit [Ping timeout: 264 seconds]
Stat_headcrabed has joined #riscv
wingsorc has quit [Ping timeout: 240 seconds]
emacs_pprentice_ has joined #riscv
wingsorc__ has quit [Read error: Connection reset by peer]
<sevan>
Anyone done the Ubuntu 22.10 to 23.04 upgrade on the risc-v image via do-release-upgrade yet?
<sevan>
it's amusing to see that lots of updates have been landing for months and being held back for a while, which is why I'm curious if anyone has tried it yet. :)
Stat_headcrabed has quit [Quit: Stat_headcrabed]
FL4SHK has joined #riscv
meta-coder has joined #riscv
midnight has quit [Ping timeout: 264 seconds]
<drewfustini>
smaeul: I thought that OpenSBI did fixup the device tree that Linux gets.
<drewfustini>
the bootcode for the hart running linux puts the dtb address in a1:
<drewfustini>
1: la a1, _start + 256 // DTB is at boot start + 256
<drewfustini>
The opensbi I'm using is master as of:
<drewfustini>
Date: Mon Jan 9 05:20:43 2023 +0000
<drewfustini>
docs: Update domain's region permissions and requirements
<drewfustini>
I'll update it to see if any difference
<jrtc27>
how are you booting, and where does the FDT come from?
<jrtc27>
OpenSBI patches what it passes on, but if you load your own FDT in Linux land (and it doesn't make a call down into firmware to patch it) then you won't see the reserved memory regions, I assume
<jrtc27>
if you're using EFI things should be fine, but if you're not then it probably is all broken
<jrtc27>
U-Boot with booti should also work if U-Boot's loading the FDT for Linux
<jrtc27>
but if you're hopping straight from OpenSBI to Linux with an embedded FDT then I expect that to be a pile of flames now
<jrtc27>
(embedded in Linux, that is)
<drewfustini>
the bootcode on the hart jumps to fw_payload which is opensbi+linux. The only dtb is the one passed to opensbi in register a1
<drewfustini>
I thought that means Linux is getting the fixed up dt from opensbi. I will rebuild with the linux commit prior to the break and check what 'dtc -I fs' shows
<jrtc27>
then yes you should have the fixed up FDT
BootLayer has quit [Quit: Leaving]
<FL4SHK>
so I read that NetBSD has a RISC-V port
<FL4SHK>
on the Wikipedia page for NetBSD
<FL4SHK>
can you run X on that?
Leopold has quit [Ping timeout: 240 seconds]
<jrtc27>
AFAIK the status is "it boots on qemu" for some definition of "boots" and that's about it
<jrtc27>
I know X works on FreeBSD, and it probably works on OpenBSD too?
<FL4SHK>
I see
<FL4SHK>
I heard that Linux porting is proving to be had for RISC-V folks
<jrtc27>
?
Leopold has joined #riscv
<FL4SHK>
hard
<jrtc27>
X works on Linux too
<FL4SHK>
oh
<FL4SHK>
maybe I heard wrong then
<FL4SHK>
I know that X works on Linux
<FL4SHK>
I'm using Linux on an x86-64 machine right now
<FL4SHK>
with an X server...
<jrtc27>
is this in the context of the VisionFive 2 specifically, or RISC-V in general?
<FL4SHK>
RISC-V in general
<jrtc27>
then it definitely works
<FL4SHK>
gotcha
<FL4SHK>
that sounds good
<jrtc27>
SiFive's vendor image shipped with the HiFive Unmatched boots to an XFCE desktop if you have a suitable GPU installed
<FL4SHK>
hm, I don't have any existing hardware, but I do have FPGA dev boards
<jrtc27>
you probably don't want to run X on an FPGA...
<FL4SHK>
why not?
<jrtc27>
because even a text console can be a bit painful
<FL4SHK>
too slow?
<jrtc27>
yes
<FL4SHK>
I see
<jrtc27>
at best it's 1/10th the speed of a real system
<jrtc27>
at worst more like 1/100th+
<FL4SHK>
with what FPGA?
<jrtc27>
something big and expensive like a VCU-118
<FL4SHK>
oh
<FL4SHK>
I mean I bought something big and expensive
<FL4SHK>
I was expecting something like 500 MHz or more
<FL4SHK>
with the FPGA I bought
<jrtc27>
500 MHz for a soft-core sounds very aggressive
<FL4SHK>
...it's Ultrascale+
<jrtc27>
as is the VCU-118
<FL4SHK>
and that's apparently realistic for this dev board
<FL4SHK>
hm
<jrtc27>
simple in-order pipeline designs are around 100-150 MHz
<jrtc27>
out-of-order is capped at more like 50 MHz
<FL4SHK>
that really doesn't sound like what I was told
<FL4SHK>
I've heard of as much as maybe 300 MHz
<FL4SHK>
at least
<jrtc27>
for a very basic processor, maybe
<jrtc27>
but once you make it more complex, give it a good memory subsystem so it's not spending all its time waiting for DRAM, etc, things get a bit slower
<gurki>
the vexriscv guys have a nice table on their github page
<gurki>
(disclaimer: im not involved in that project)
<FL4SHK>
I'm told that for my dev board the range is 100-600 MHz
<FL4SHK>
at least for soft CPUs
<FL4SHK>
depending on features
<FL4SHK>
soft CPUs in general
<gurki>
(mostly. :3)
<jrtc27>
what's the dev board?
<FL4SHK>
Xilinx ZCU104
<gurki>
FL4SHK: softcores vary wildly, dpeending on complexity as jrtc27 mentioned
<FL4SHK>
I see
<FL4SHK>
yeah, that's true
<jrtc27>
so it's about 1/5th the size of the VU9P in the VCU-118
<jrtc27>
in terms of CLB bits at least
<jrtc27>
don't know how the interconnect compares
<FL4SHK>
I have no idea
<FL4SHK>
maybe I wasted my money and am currently wasting my time
<jrtc27>
I mean, you can always just synthesise a core and see what frequency you get...
<gurki>
synthesizing these vexriscv variants from the link i posted should give you a rough idea
<FL4SHK>
sure, I guess I'll try that
<gurki>
i would expect it to do similar-ish to that artix7
<FL4SHK>
to an Artix 7?
<FL4SHK>
isn't that a lot slower?
<jrtc27>
those vexriscv cores are all RV32IMA though, not RV64IMAFDC as the general linux distro baseline
<jrtc27>
which, if you're going to be running X, is surely what you'd want
<jrtc27>
(well, most are even a further subset)
<gurki>
jrtc27: im not saying "use it for the final thing", but these examples can serve as a guideline to get into the differences of softcores :)
<jrtc27>
sure
<gurki>
there is a set of scripts to run linux on a vexriscv via the litex stuff, but ultimately you probably do want a rv64...
meta-coder has quit [Quit: leaving]
<FL4SHK>
I suppose I could just synthesizing one of my existing CPU designs
<gurki>
realistically this is your board and your time so you can do whatever you seem fit ;)
<FL4SHK>
sounds good
sauce has quit []
<muurkha>
courmisch: sweet, thanks!
Leopold has quit [Ping timeout: 240 seconds]
Leopold has joined #riscv
<muurkha>
jrtc27: I'm surprised you'd say "even a text console [on an FPGA] can be a bit painful" as if that was some generalized attribute of FPGAs :]
<muurkha>
certainly I've had very usable X-Windows and especially text consoles on hardware running at more like 25MHz than 500MHz
<FL4SHK>
that is good to hear
<jrtc27>
try running gdb on them
<muurkha>
I don't think F+D make any difference for X. the C extension is surely useful but that's just a marginal gain (or loss) of performance
<jrtc27>
F+D mean you can install distribution packages rather than building everything from source
<muurkha>
yes, true
<muurkha>
in theory you could cross-assemble from binaries to work around the absence of C but I don't know if anybody is doing that
<muurkha>
I did run GDB on a SPARC 5 from time to time
<jrtc27>
you could, but desktop stacks are a lot to cross-compile
<jrtc27>
I mean, it's doable, we've done it
<jrtc27>
but it's not particularly fun
<jrtc27>
unless you want a really barebones one
<muurkha>
it might depend on your compilation setup
<muurkha>
like, if you're running autoconf scripts from upstream, it's going to be a bear
<muurkha>
the text console on the SPARC 5 was pretty unusable but I think that's because it was implemented in interpreted FORTH or something
<muurkha>
lots of slower machines had very responsive text consoles
<muurkha>
the potential advantage of cross-assembling binaries is that in theory you don't have to worry about the build system
<muurkha>
you just take the distribution packages and munge their binaries to not use C instructions or whatever
aredridel has quit [Read error: Connection reset by peer]
<drewfustini>
re: the device tree passed from opensbi, I don't see any entries in reserved-memory so maybe something is going wrong.
<Esmil>
smaeul: I was forward porting some of the extra D1 patches in your code and at some point I had enabled the aldo and hpldo, but not the lradc keyboard driver, which meant the aldo was shut off and this results in USB 1.1 devices not being able to enumerate. I don't see any relation between usb and the aldo in your device trees though, so this maybe something to look into when upstream the ldo support
<Esmil>
*in your tree
MaxGanzII has quit [Ping timeout: 240 seconds]
<smaeul>
Esmil: Interesting. Sounds like some part of the USB PHY is powered from ALDO. Thanks for letting me know!