<ddevault>
familiar to anyone on the hifive unleashed?
jrjsmrtn has quit [Ping timeout: 250 seconds]
X-Scale` has joined #riscv
X-Scale has quit [Ping timeout: 265 seconds]
X-Scale` is now known as X-Scale
<jrtc27>
ddevault: sounds like a device tree / kernel mismatch
<ddevault>
hm, perhaps
<ddevault>
I'm using upstream 5.14.5
<jrtc27>
the original fusdk u-boot and linux used pcieaux as the name
<jrtc27>
when upstreamed it switched to pcie_aux
<jrtc27>
I made freebsd support both (because I hate vendoring device trees) but upstream linux just supports the name for the one it vendors
<ddevault>
hm
X-Scale` has joined #riscv
<ddevault>
and the u-boot which ships on the microSD card hands off its dt to linux? linux doesn't load its own?
<jrtc27>
it always hands off its own
<jrtc27>
but linux being linux is supposed to just ignore that and load its own
<jrtc27>
because somehow it still hasn't figured out how to make stable bindings
X-Scale has quit [Ping timeout: 252 seconds]
X-Scale` is now known as X-Scale
jrjsmrtn has joined #riscv
hendursa1 has quit [Quit: hendursa1]
hendursaga has joined #riscv
<ddevault>
I don't fully understand the system, but if I follow correctly
<ddevault>
the broken system has pcieaux in /proc/device-tree/soc/pcie@e00000000/clock-names
<ddevault>
but pcie_aux is the appropriate upstream name
<ddevault>
my kernel tree has pcie_aux in arch/riscv/boot/dts/sifive/fu740-c000.dtsi
<ddevault>
and I'm not sure where the pcieaux string is coming from
<jrtc27>
u-boot's device tree
<jrtc27>
I assume you're not using upstream u-boot?
<ddevault>
I'm using u-boot from the microSD card that shipped with the box
<ddevault>
upstream u-boot was later on my todo list
<jrtc27>
oh seems upstream u-boot hasn't renamed it yet either
<ddevault>
my booting workflow right now is a UEFI image on a flash drive which u-boot on the microSD card automatically picks up and boots to
<jrtc27>
anyway I think you're supposed to build the device tree and put it on the ESP in a specific place
<ddevault>
I don't want to get into the u-boot bits right now so I suppose the best temporary fix would be to patch linux back to pcieaux?
<jrtc27>
don't ask me how any of that works though...
<jrtc27>
I assume you've enabled CONFIG_SOC_SIFIVE?
<ddevault>
yep
<ddevault>
it does boot and everything but pci seems to be working
jwillikers has quit [Remote host closed the connection]
<jrtc27>
ok so apparently the extlinux config generated by u-boot-update is supposed to include an fdt line that points at your board's dtb file
<ddevault>
oh, for the kernel command line?
<ddevault>
er, no
<ddevault>
I think I will end up patching u-boot
* ddevault
shrugs
frost has quit [Quit: Connection closed]
<ddevault>
woot now it doesn't boot at all
jrjsmrtn has quit [Read error: Connection reset by peer]
jrjsmrtn has joined #riscv
<ddevault>
got it :D
<ddevault>
including the pcie issue
<ddevault>
thanks jrtc27! that was a great help
jwillikers has joined #riscv
freakazoid333 has joined #riscv
freakazoid12345 has quit [Ping timeout: 268 seconds]
mahmutov_ has joined #riscv
haritz has quit [Ping timeout: 240 seconds]
Raito_Bezarius has quit [Ping timeout: 260 seconds]
Narrat has joined #riscv
Raito_Bezarius has joined #riscv
jwillikers has quit [Remote host closed the connection]
cwebber has quit [Ping timeout: 260 seconds]
peeps[zen] has joined #riscv
[itchyjunk] has quit [Read error: Connection reset by peer]
peepsalot has quit [Ping timeout: 265 seconds]
cwebber has joined #riscv
crabbedhaloablut has joined #riscv
cwebber has quit [Ping timeout: 260 seconds]
jwillikers has joined #riscv
<ddevault>
this fan is killing me
jwillikers has quit [Remote host closed the connection]
<AhmedCharles[m]>
Sometimes I tune it out. :)
ats has quit [Ping timeout: 268 seconds]
mahmutov has joined #riscv
mahmutov_ has quit [Ping timeout: 260 seconds]
jacklsw has quit [Quit: Back to the real life]
<ddevault>
I replaced it with the fan from my unleashed and it's slightly better
cwebber has joined #riscv
djdelorie has quit [Quit: Leaving]
BOKALDO has quit [Quit: Leaving]
smartin has quit [Quit: smartin]
arlen has joined #riscv
<geist>
i haven't debugged it much but it seems that the current version of ubuntu riscv has an unaligned fault when it tries to boot on riscv
<geist>
unclear why i see it, since it seems others would too, unless it's actually untested
gioyik has joined #riscv
[itchyjunk] has joined #riscv
vagrantc has joined #riscv
<Esmil>
geist: "current version of ubuntu riscv" is that 21.04 Hirsute? because that works fine on my starlight board
<geist>
21.04 yes, on qemu, virt machine
<geist>
but good to know it works for you
<geist>
i have an older qemu install of 20.10 that i tried to upgrade to 21.04 then it faults. so thinking it was an upgrade problem i then did a fresh install and it faults too
<geist>
obviously a few things changed, but it never gets the kernel started so it was somethign in the uboot or kernel update or both
<geist>
but i haven't tried in a few months so maybe it was fixed in the interim
<geist>
also possible it's becaus ei'm using more or less bleeding edge qemu. perhaps it got more picky about unaligned bits than previous versions
<jrtc27>
there was a bug where ftrace would try and instrument itself and oops early in boot
<geist>
yah i hadnt actually sat down to trace where it was. it was definitely before it outputted anythingm but far enough in that a comprehensive instruction trace in qemu was extremely long
<xentrac>
jrtc27: the RISC-V accelerator thing reminds me of how people use 8051s these days; 8051 machine code is sort of like the scripting language for a bunch of DSPs
<jrtc27>
oh on qemu not hardware
<xentrac>
maybe RISC-V is a better alternative to the 8051
<geist>
there's an embedded project i saw a while back that uses an instance of a little riscv emulator started up in a thread to run some BPF like code
<xentrac>
interesting, I wonder why they chose RISC-V rather than BPF itself
<xentrac>
or, say, Lua
<geist>
i dunno what BPF looks like, but it's pretty network centric isn't it?
<xentrac>
not at all
<geist>
i think the idea is it's easy to write a riscv emulator and can use LLVM to generate filters pretty efficiently
<xentrac>
LLVM has an eBPF backend too
* geist
shrugs
<xentrac>
(but not a Lua one)
<geist>
just callin it as i see it. i dunno what the rationale was
<geist>
but point is riscv is simple enough that that sort of thing isn't insane
<xentrac>
yeah, I'm curious, I wasn't saying you were lying :)
<geist>
nah, i ust dont know what they were thinking, more that it was done
<xentrac>
agreed
<xentrac>
I've been thinking about a bytecode to use as a compact C compilation target
<geist>
that would also be a good use for riscv e as well, halves the size of the emulator state
<xentrac>
occasionally that matters
<jrtc27>
E is also limited to 32-bit so 64-bit arithmetic is slow
<geist>
indeed, though in this case 32bit was totally fine, since it's also running on a 32bit host, etc
<xentrac>
also usually for scripting-like applications your arithmetic is, like, loop counters and array indexing
<xentrac>
maybe some bit field extraction
<geist>
might even leave out the m and a extensions
<geist>
or at least the divide part, which unforunately can't be separated from m
<geist>
IIRC
<geist>
unless that's some feature of the e extension
<xentrac>
it isn't
<xentrac>
in an emulator there's less reason to leave out m than in hardware
<geist>
unless hardware itself doesn't have a divide
<geist>
well the host that is
<geist>
well, actually yeah i guess that'd make sense to leave it in
<geist>
since the host can natively run long division instead of an emulated version of it (and an additional libgcc.a that takes up space in the emulated block)
<xentrac>
even if your host hardware doesn't have a divide, it's likely that a program big enough to start up a riscv emulator in a thread to run some BPF-like code also contains a division subroutine
<xentrac>
if it doesn't otherwise use integer division, that might be a reason to want to leave out divide
<xentrac>
for Veskeno I have a different reason to leave out divide: division is error-prone, and there are several ways to do it that give the same answers for some arguments and different answers for other arguments
<xentrac>
signs, overflows, division by 0
<xentrac>
because the objective for Veskeno is that if your implementation passes the test suite, it should probably be correct
balrog_ is now known as balrog
balrog has quit [Quit: Bye]
devcpu has quit [Quit: leaving]
balrog has joined #riscv
<jrtc27>
geist: Zmmul is being retroactively factored out of M
<geist>
for the reason that folks want to make divisorless embedded hardware, a-la cortex-m0?
<xentrac>
jrtc27: oh, that's good!
devcpu has joined #riscv
<jrtc27>
yeah pretty much
<jrtc27>
gcc supported an -mno-div option in the past to support standards-violating hardware
<jrtc27>
I pushed back against adding similar to clang and in parallel zmmul was created
<xentrac>
even if your hardware isn't embedded per se, it makes a lot of sense to do division in a non-constant-time fashion even if you have a single-cycle or few-cycle multiplier
<xentrac>
not always but often
<xentrac>
and in RISC-land, non-constant-time generally means in a subroutine, even if it's a millicode subroutine
<xentrac>
right?
<xentrac>
(I mean I'm a little out of my depth here, never having built a working CPU myself, so I'm curious to know if my summary above is actually correct)
pecastro has quit [Remote host closed the connection]
pecastro has joined #riscv
arlen_ has joined #riscv
arlen has quit [Ping timeout: 265 seconds]
<sorear>
rocket has a few multicycle units that operate independently of the instruction pipeline
winterflaw has quit [Remote host closed the connection]
winterflaw has joined #riscv
mahmutov has quit [Ping timeout: 252 seconds]
winterflaw has quit [Ping timeout: 276 seconds]
<jimwilson>
some university courses leave out divide because it is too hard for a one semester processor design class, that is why gcc has -mno-div, but zmmul is a better solution and we will switch to that when it gets ratified
<sorear>
interesting, I thought it was pressure from the soft core people
jwillikers has joined #riscv
<jimwilson>
your history goes back farther than mine, but currently, as far as I know, the primary users of -mno-div are university classes
gioyik has quit [Ping timeout: 276 seconds]
Narrat has quit [Quit: They say a little knowledge is a dangerous thing, but it's not one half so bad as a lot of ignorance.]