Leopold has quit [Remote host closed the connection]
Gravis_ has joined #riscv
Gravis has quit [Ping timeout: 268 seconds]
Leopold has joined #riscv
Stat_headcrabed has joined #riscv
MaxGanzII has joined #riscv
MaxGanzII has quit [Remote host closed the connection]
MaxGanzII has joined #riscv
danilogondolfo has joined #riscv
BootLayer has joined #riscv
bauruine has joined #riscv
ldevulder has joined #riscv
MaxGanzII has quit [Ping timeout: 240 seconds]
MaxGanzII has joined #riscv
heat has joined #riscv
pecastro has joined #riscv
wiagn has joined #riscv
Stat_headcrabed has quit [Ping timeout: 240 seconds]
wiagn is now known as Stat_headcrabed
enoq has joined #riscv
jacklsw has quit [Ping timeout: 240 seconds]
wiagn has joined #riscv
Stat_headcrabed has quit [Ping timeout: 246 seconds]
wiagn is now known as Stat_headcrabed
wingsorc has quit [Ping timeout: 240 seconds]
Stat_headcrabed has quit [Quit: Stat_headcrabed]
Tenkawa has joined #riscv
MaxGanzII_ has joined #riscv
MaxGanzII has quit [Remote host closed the connection]
prabhakarlad has joined #riscv
Tenkawa has quit [Quit: Was I really ever here?]
Noisytoot has quit [Ping timeout: 248 seconds]
Noisytoot has joined #riscv
aredridel has quit [Read error: Connection reset by peer]
aredridel has joined #riscv
aredridel has quit [Read error: Connection reset by peer]
aredridel has joined #riscv
BootLayer has quit [Quit: Leaving]
billchenchina has joined #riscv
somlo has quit [Quit: Leaving]
billchenchina- has joined #riscv
billchenchina has quit [Ping timeout: 246 seconds]
meta-coder has joined #riscv
Leopold has quit [Ping timeout: 268 seconds]
Leopold has joined #riscv
Stat_headcrabed has joined #riscv
BootLayer has joined #riscv
Stat_headcrabed has quit [Quit: Stat_headcrabed]
meta-coder has quit [Ping timeout: 240 seconds]
jay321 has joined #riscv
enoq_ has joined #riscv
enoq has quit [Ping timeout: 264 seconds]
enoq_ is now known as enoq
pedja has joined #riscv
vagrantc has joined #riscv
jacklsw has joined #riscv
somlo has joined #riscv
Leopold has quit [Ping timeout: 265 seconds]
Leopold has joined #riscv
MaxGanzII_ has quit [Ping timeout: 240 seconds]
junaid_ has joined #riscv
MaxGanzII_ has joined #riscv
jacklsw has quit [Read error: Connection reset by peer]
prabhakarlad has quit [Quit: Client closed]
frkazoid333 has quit [Ping timeout: 248 seconds]
somlo has quit [Remote host closed the connection]
JanC has joined #riscv
Stat_headcrabed has joined #riscv
junaid_ has quit [Ping timeout: 240 seconds]
lemoniter has joined #riscv
Gravis_ is now known as Gravis
billchenchina- has quit [Quit: Leaving]
frkazoid333 has joined #riscv
junaid_ has joined #riscv
Tenkawa has joined #riscv
Tenkawa has quit [Client Quit]
sakman has quit [Remote host closed the connection]
___nick___ has joined #riscv
___nick___ has quit [Client Quit]
___nick___ has joined #riscv
BootLayer has quit [Quit: Leaving]
Stat_headcrabed has quit [Quit: Stat_headcrabed]
MaxGanzII_ has quit [Remote host closed the connection]
MaxGanzII_ has joined #riscv
terminalpusher has joined #riscv
elastic_dog has quit [Remote host closed the connection]
elastic_dog has joined #riscv
elastic_dog has quit [Remote host closed the connection]
fuwei has quit [Ping timeout: 264 seconds]
fuwei has joined #riscv
jay321 has quit [Read error: Connection reset by peer]
jay321 has joined #riscv
jay321 has quit [Read error: Connection reset by peer]
jay321 has joined #riscv
ikke has joined #riscv
elastic_dog has joined #riscv
junaid_ has quit [Remote host closed the connection]
elastic_dog has quit [Remote host closed the connection]
<ikke>
I received a starfive 2 board today and trying to boot it, but it is failing for some reason: https://tpaste.us/1X59. uEnv.txt contains https://tpaste.us/Wx0Y where the kernel_comp_* variables are defined. Anyone knows what the issue might be?
elastic_dog has joined #riscv
<ikke>
I tried to set the boot switches to eMMC (high, low), but then it immediately fails Odwmci_s: Response Timeout.
<ikke>
BOOT fail,Error is 0xffffffff
ldevulder has quit [Quit: Leaving]
<jrtc27>
I mean, my suggestion would be to just boot with EFI like a proper computer
<jrtc27>
but for some reason the linux community continues to be allergic to doing that on riscv boards...
<muurkha>
heh
<muurkha>
EFI has the stink of Microsoft on it
<jrtc27>
sounds like your uEnv.txt just isn't being parsed though
___nick___ has quit [Ping timeout: 268 seconds]
<muurkha>
it requires you to package your kernel into a Windows executable
<jrtc27>
PE/COFF isn't Windows
<muurkha>
who else uses it this millennium?
<mps>
oh no, EFI on SBCs
<jrtc27>
well, PE is windows, but COFF was in System V
<jrtc27>
yes, EFI on SBCs
<jrtc27>
be thankful
<jrtc27>
it's a standard, not some cobbled-together piece of crap called booti that does basically nothing useful
<muurkha>
"standard"
<jrtc27>
where booti is just "what does linux want? ok, let's do that"
<muurkha>
heh, well, I guess that might explain why people like it
<muurkha>
if they're Linux people
<mps>
iirc I read that the fedora wants to use u-boot EFI for x86 with bios
<jrtc27>
there were mutterings of that earlier this week, yes
elastic_dog has quit [Ping timeout: 240 seconds]
<jrtc27>
efi-on-bios isn't the stupidest idea, though one does wonder whether those computers should instead be confined to the dustbin of history
<muurkha>
most of our experience with EFI/UEFI compes from motherboards designed for Microsoft Windows which, unsurprisingly, often give us a lot of trouble with not just Linux but also FreeBSD, NetBSD, etc.
<jrtc27>
whether that's u-boot, clover, edk2's old duetpkg, etc providing it
<mps>
I use EFI only there where I don't have choice
<jrtc27>
yes, firmware has bugs
<muurkha>
how much of that trouble is due to EFI's complexity, I can't say
JanC has quit [Read error: Connection reset by peer]
<jrtc27>
that's the fault of the implementations and conformance testing, not the standard
<muurkha>
complex firmware has more bugs
<muurkha>
some of the complexity is the fault of the standard
JanC has joined #riscv
<jrtc27>
a lot of the complexity is on the side
<jrtc27>
the actual bit that OSes use is quite small
<muurkha>
but I don't have a better alternative to offer
<mps>
solve layers problems by addinm more layers
<jrtc27>
it just doesn't really distinguish between OS and driver in the spec
<muurkha>
maybe the part that OSes don't use shouldn't be there
<jrtc27>
except for runtime services
<mps>
s/addinm/adding/
<jrtc27>
well, the point is, a bootloader *can* use those things if it wants to
<jrtc27>
they just don't because it's kinda stupid
<mps>
well, I tried EFI on riscv board and qemu, hassle
elastic_dog has joined #riscv
somlo has joined #riscv
elastic_dog has quit [Remote host closed the connection]
<jrtc27>
works great for me
<jrtc27>
I get a full-fat FreeBSD experience complete with its bootloader
<mps>
lucky you
wingsorc has joined #riscv
elastic_dog has joined #riscv
terminalpusher has quit [Remote host closed the connection]
prabhakarlad has joined #riscv
JanC_ has joined #riscv
JanC is now known as Guest6890
Guest6890 has quit [Killed (calcium.libera.chat (Nickname regained by services))]
JanC_ is now known as JanC
elastic_dog has quit [Read error: Connection reset by peer]
elastic_dog has joined #riscv
Andre_Z has joined #riscv
<pierce>
Oh I missed an EFI convo :(
billchenchina has joined #riscv
<pierce>
Happy to see jrtc27 and I see eye to eye here
Andre_Z has quit [Client Quit]
pedja has quit [Quit: Leaving]
billchenchina- has joined #riscv
billchenchina has quit [Ping timeout: 256 seconds]
Andre_Z has joined #riscv
danilogondolfo has quit [Remote host closed the connection]
wingsorc has quit [Remote host closed the connection]
<dh`>
far too useful
<dh`>
woops
<dh`>
(although I'm sure that qualifies as a valid cynical comment on *something* in the scroll here)
wingsorc has joined #riscv
<muurkha>
heh
jay321 has quit [Read error: Connection reset by peer]
jay321 has joined #riscv
jay321 has quit [Remote host closed the connection]
jay321 has joined #riscv
jay321 has quit [Read error: Connection reset by peer]
<mps>
to explain my stance about EFI, I'm not against it where it works without problems. Actually I use it on some machines and it works fine
jay321 has joined #riscv
jay321 has quit [Read error: Connection reset by peer]
<mps>
and it is quite good it is added to u-boot, imo
<mps>
but remembering openbios (forth) on some old sparc machines is nostalgia
<mps>
when (and if) I've got retirement maybe I would try to write boot loader in forth for some modern boards
<muurkha>
I'm not against EFI at all, I just feel like it's understandable that some people hate it
jay321 has joined #riscv
<muurkha>
they might be wrong to hate it, but if so they're understandably wrong
<heat>
have you seen the complexity of EDK2? it's crazy. although this is kind of conflating EFI and the EFI PI spec (and an implementation, which AFAIK is the only one of the PI spec)
<heat>
you *can* implement EFI in a minimal way (see uboot), but it's usually not what people are hating on
<heat>
like, why does my firmware contain a copy of an out of date openssl? and a written-from-scratch network stack (that's not actively fuzzed nor tested against)?
<muurkha>
yeah, those things are kind of worrying
<muurkha>
also the sheer volume of crap involved in building a minimal EFI-loadable image is overwhelming
<muurkha>
compared to, like, your serial port is at 3fc hex, your load address is 80480000 hex, and you have 256 interrupt vectors are 8 bytes each starting at 0, and interrupts are disabled at powerup
<mps>
heat: I guess it is complicated because all these 'cpu-in-cpu' secrets
<muurkha>
instead you need a FAT filesystem, a PE executable with its farrago of shitty headers, and fifty-seven thousand libraries, to be able to compile a "hello world" image
<muurkha>
it may in fact be the most practical solution to being able to find out what devices there are and how to set them up, given the world we live in
<muurkha>
but it's sure not fucking pleasant
lemoniter has quit [Quit: Leaving]
jay321 has quit [Read error: Connection reset by peer]
<jrtc27>
what do you need fifty-seven thousand libraries for?
<heat>
mps, it's complicated because EFI and tianocore were designed with a spirit of unwavering modularity and encapsulation, plus vendors' silly ideas of what firmware should or shouldn't do
<valerius>
"vendors' silly ideas of what firmware should or shouldn't do" -- I'd say that's 99% of it...
Tenkawa has joined #riscv
ch has quit [Quit: ch]
ch has joined #riscv
feldzeugmeister has joined #riscv
sakman has quit [Quit: Leaving]
billchenchina- has quit [Ping timeout: 256 seconds]
pecastro has quit [Ping timeout: 240 seconds]
<dh`>
firmware _could_ contain all device drivers and just export virtio to the OS
<dh`>
but given the persistent build quality issues that firmware always has, that's not the right answer
<feldzeugmeister>
new to riscv. is there a basic model desktop computer under 500 available that is linux kernel compatible? thanks
<muurkha>
jrtc27: the standard build environment for EFI images
<jrtc27>
nobody uses that
<jrtc27>
in linux land it's gnu-efi
<heat>
everyone working on firmware uses that
<jrtc27>
everywhere else, including linux kernel land, it's do your own thing
<jrtc27>
yes, but this isn't about people working on firmware
<muurkha>
what should I use?
<jrtc27>
this is about people writing hello world
<muurkha>
or kernels
<heat>
then yes, probably gnu-efi. or roll your own problematic EFISTUB
<muurkha>
feldzeugmeister: no, though the VisionFive boards seem to have just reached some customers
<muurkha>
they're not really a basic model desktop computer, but you could plausibly build a basic model desktop computer around one
<muurkha>
VisionFive 2 I think? ikke just got theirs
<feldzeugmeister>
muurkha thanks so much ill look at it
<feldzeugmeister>
what do most people here use then? more expensive models or?
<muurkha>
qemu
<feldzeugmeister>
ah so its not quite consumer grade yet
<muurkha>
right
<muurkha>
or PicoRV32 on an FPGA
<another|>
horse creek might be interesting
<feldzeugmeister>
there sad. I dont like the CPU options on the market
<feldzeugmeister>
thats
<muurkha>
I mean there are supposedly over a billion RISC-V microcontrollers already shipped, presumably most in consumer products, but those can't run Linux
<muurkha>
ikke had some questions about how to get the VisionFive (2?) to boot
<muurkha>
and there's the
aerkiaga has joined #riscv
<muurkha>
SiFive boards
<muurkha>
and I think someone has shipped some T-Head Xuantie Pingtouge hardware, which is also Linux-capable
<muurkha>
but I don't think anyone will sell you an ATX case with a RISC-V board in it running Linux yet?
<feldzeugmeister>
riscv by itself doesn't have the open source firmware guarantee right? its up to the manufacturers. im curious how this will turn out
<feldzeugmeister>
no one can predict the future but wont everyone still build their proprietary crap into it
<gurki>
well you need a ton of proprietary stuff to actually build an asic in 2023, even if you ignore the ip for peripherals and memories
<feldzeugmeister>
the build process doesn't matter to me. as long as the product is free
<feldzeugmeister>
but good point
<gurki>
so riscv doesnt solve a significant fraction of these issues, but its a start.
<muurkha>
solving them? I thought you were in favor of chip designs being proprietary, gurki :)
<muurkha>
right, by virtue of being open, RISC-V International isn't in a position to demand that people implementing RISC-V only run free firmware on it
<gurki>
muurkha: my personal oppinion is that the foss flows and such are too crappy to actually be usable right now
<gurki>
but i certainly wouldnt mind for that to change
<gurki>
its not like i particularly enjoy using these glorious eda tools.
<gurki>
:P
<muurkha>
gurki: oh, you mean the EDA tools? I thought you meant the designs themselves
<feldzeugmeister>
im sure many ppl are hyped because of not understanding those points you two brought up
<feldzeugmeister>
hopefully they arent disappointed
<gurki>
muurkha: i was talking about both
<muurkha>
eh, people get disappointed
<muurkha>
so it goes
<feldzeugmeister>
its a part of life
<gurki>
muurkha: but my oppinion doesnt change. id be a huge fan of none of this being proprietary
<gurki>
and riscv is an important stepstone, so im happy about it :)
<muurkha>
interesting, I had no idea
<muurkha>
that's nice to hear :)
<feldzeugmeister>
even if they made an open CPU,ppl would just shift the proprietary stuff elsewhere, you could put blobs into the battery firmware, etc
aredridel has quit [Read error: Connection reset by peer]
<feldzeugmeister>
maybe its a pointless battle
aredridel has joined #riscv
<muurkha>
feldzeugmeister: it's not pointless because the different forms of proprietary restrictions reinforce one another
<gurki>
feldzeugmeister: you cant get all parts of the puzzle foss at once, youll never actually arrive at an image
<gurki>
one puzzle piece at a time :)
<feldzeugmeister>
of course I was just being cynical
<feldzeugmeister>
just that this stuff happens to slowly. we will be old once this newer stuff matures
enoq has quit [Remote host closed the connection]
<muurkha>
I haven't done it, but as I understand it, it's currently possible to get a pretty respectable PicoRV32 configuration running in a Lattice UP5K or UP8K FPGA without ever touching the poop of proprietary EDA tools
<muurkha>
or proprietary designs
<muurkha>
wait, there isn't a UP8K. what was I thinking of?
<feldzeugmeister>
what would that device be in terms of performance?
<muurkha>
iCE40HX8K is what I was thinking of
<muurkha>
well, it won't run Linux; there isn't room for an MMU
<feldzeugmeister>
one day hopefully
<gurki>
i dont have enough experience with lattice to translate lut/ff counts from xilinx to lattice, but according to what the vexriscv guys state on their github you might get a vexriscv with mmu to fit