<courmisch>
did T-Head just change name to Open Chip Community? I'm confused with all those names
junaid_ has joined #riscv
heat has joined #riscv
valdemaras has joined #riscv
<Finde>
seems like they've been using the name for a while if you google for it
sakman has quit [Quit: Leaving]
valdemaras has quit [Quit: valdemaras]
Tenkawa has joined #riscv
sakman has joined #riscv
ntwk has joined #riscv
danilogondolfo has quit [Remote host closed the connection]
Armand has joined #riscv
<muurkha>
best to just stick to calling them Brother Pingtou
ldevulder_ has joined #riscv
hightower3 has quit [Remote host closed the connection]
hightower3 has joined #riscv
ldevulder has quit [Ping timeout: 240 seconds]
Andre_Z has joined #riscv
junaid_ has quit [Remote host closed the connection]
<mps>
Tenkawa: I found why mainline u-boot can't boot VF2. Well it can but when nvme module is not on board
<Tenkawa>
sounds like someone needs to work on that heheh
<Tenkawa>
I like my nvme booting
<mps>
yes, but I don't have much free time and I don't know 'disk' drivers much
<Tenkawa>
I wish I knew u-boot more
<mps>
I think u-boot doesn't properly initialize nvme subsystem or maybe just my nvme model
<Tenkawa>
it could be the latter... its "very" picky about nvme's
<mps>
don't have starting commit to try bisecting
<muurkha>
ugh
elastic_dog has quit [Ping timeout: 256 seconds]
elastic_dog has joined #riscv
wingsorc has joined #riscv
junaid_ has joined #riscv
unnick has quit []
unnick has joined #riscv
<geist>
indeed. i have had fairly bad luck with nvme being stable on my vf2. at best i had it running for an hour before it starts getting a lot of PCIe links and then falls over until you restart
<geist>
(in linux, 5.15 kernel, etc)
<mps>
for me it works but only if I boot it using starfive/debian u-boot
<mps>
and with kernel 6.4 and/or 6.5-rc
* geist
nods
<geist>
i assume it's some combination of firmware/kernel version/nvme brand/etc that needs to line p
<mps>
I guess so
<mps>
(why vendors call u-boot+opensbi firmware) I guess marketing
davidlt has joined #riscv
BootLayer has quit [Quit: Leaving]
<jrtc27>
because that's what it is?
<jrtc27>
it occupies the same space as the EDK2-based firmware on an x86 PC
Leopold_ has joined #riscv
Leopold has quit [Ping timeout: 246 seconds]
<mps>
for long time I'm using u-boot and didn't noticed on their IRC or mailing list that someone call it firmware, but could be that I missed this
<muurkha>
it depends on the context
<muurkha>
I mean you can load u-boot from a disk or something
<muurkha>
then it probably isn't firmware
<muurkha>
but if it's burned into your reset ROM it is
<mps>
muurkha: yes. And I have 'meaning' that firmware is something in chip
<Tenkawa>
Mine is working great with vendor u-boot, aurel32's 6.4 git tree (+ updates from mainline to keep it up to date with patching) and a Samsung SSD 970 EVO Plus 250GB
junaid_ has quit [Ping timeout: 246 seconds]
<mps>
Tenkawa: I'm using same model with same kernel
<Tenkawa>
mps: could be your power, your board, many factors.. I have a highly modified rootfs too
<Tenkawa>
Are you running regular Debian also?
<mps>
Tenkawa: no, it works fine with starfive 'firmware'
<Tenkawa>
Yes.. that's my point
<Tenkawa>
theres too many variables
<mps>
it only can't boot with mainline u-boot+opensbi
<Tenkawa>
Don't use mainline u-boot
<jrtc27>
it's still firmware if you load it from an SD card
<mps>
Tenkawa: why not?
<muurkha>
it's kind of in a fuzzy area
<jrtc27>
I mean, it provides EFI, and F is for Firmware
<Tenkawa>
you can use everything besides mainline u-boot/opensbi and it will work fine
<muurkha>
if I add support to Linux for running EFI binaries as a new personality, does that make Linux firmware?
<mps>
Tenkawa: yes, I know but I want to get mainline things to work
<muurkha>
the whole reason for the term "firmware" was that the hardware/software dichotomy was a bit fuzzy
<muurkha>
and now it's more so
<Tenkawa>
muurkha: yeah its really become a bonded thing now hasn't it?
<Tenkawa>
with a very touchy cohesion keeping the layers together some days
<jrtc27>
Linux can be firmware
<jrtc27>
see LinuxBoot
<mps>
fuzzy field, I agree.
<jrtc27>
but if you're running it in a context where it's meant to be standalone, then no, it's not firmware, it's just also providing a firmware interface
<jrtc27>
U-Boot isn't standalone, it expects an OS to be on top of it
<mps>
long ago I created forth interpreter which was put in e/prom but didn't called it firmware
<jrtc27>
at the end of the day, firmware is "the stuff that's resident before my OS", to a first approximation
<Tenkawa>
jrtc27: fairly accurate term.
<Tenkawa>
, firmware is a specific class of computer software that provides the low-level control for a device's specific hardware.
<mps>
so device drivers are also firmware
<muurkha>
so if I boot Linux with kexec() then Linux is my firmware?
stolen has quit [Quit: Connection closed for inactivity]
<muurkha>
it's a useful vague term but it doesn't name a sharply ontollogically distinct category
<muurkha>
*l
<Tenkawa>
mps: not completely: Device drivers are simply software programs that facilitate the interactions between a computer hardware component and the operating system, whereas firmware consists of low-level software that facilitates basic tasks with a given hardware component.
<jrtc27>
muurkha: depends if the sole purpose of the first Linux is to kexec or not
<mps>
Tenkawa: yes, I know this but still think this is 'vague' field
<muurkha>
maybe a better definition is that firmware is software that looks like hardware
<jrtc27>
in LinuxBoot scenarios, it initialises things, gives you a boot menu, etc, then kexec's, and that's it, so it's firmware
<jrtc27>
in a developer quickly booting into a new kernel scenario, you're using the first Linux as an actual OS
<jrtc27>
LinuxBoot kinda sucks because its interface is kexec, and so you can't boot anything other than Linux
<jrtc27>
or things that pretend to be Linux
<muurkha>
I see, interesting
<jrtc27>
so it's quite the opposite of a standard
<jrtc27>
but for constrained use cases it's an interesting option
<jrtc27>
just please for the love of god do not use it as your vendor-provided firmware or I will swear at you for not following OS-agnostic standards
<muurkha>
haha
davidlt has quit [Ping timeout: 244 seconds]
<muurkha>
could be worse, could be UEFI
<jrtc27>
UEFI is what I want, because like it or not that is *the* standard
<muurkha>
which is OS-agnostic in the same way nondenominational Christian churches are nondenominational
<jrtc27>
so until someone comes up with an actual standard that's better than it, that's what we get
<muurkha>
all that's needed is for Linux and FreeBSD developers to sit down and hash something out
<muurkha>
awaiting buyin from Microsoft, ARM, Apple, and Google would be a mistake
jobol has quit [Quit: Leaving]
<jrtc27>
most Linux devs have no interest in talking to FreeBSD devs
<jrtc27>
many regard us as a stupid niche that nobody really cares about
<jrtc27>
given their market share in the non-home-PC space
<jrtc27>
s/home/home\/workstation/
<muurkha>
that's how most people regard Linux too, maybe a holdover from the pre-Android days
<la_mettrie>
maybe those people don't know much about how internet works
<muurkha>
most don't
<muurkha>
freebsd is also pretty important to how the internet works tho
Andre_Z has quit [Quit: Leaving.]
wingsorc__ has joined #riscv
wingsorc has quit [Ping timeout: 258 seconds]
crabbedhaloablut has quit []
<ardb>
muurkha: nobody likes UEFI, but that is not really the point
<ardb>
whatever Linux and FreeBSD devs 'hash out' together will just be yet another way of doing the same thing
<ardb>
linuxboot is especially terrible because a) it relies on kexec and b) it falls back to an older boot method that predates UEFI
<ardb>
such a fallback only exists for x86 and it is a pile of hacks (ACPI and SMBIOS table discovery, for instance)
<somlo>
having contributed a few (very small) patches to edk2 many years ago, I can say, from a subjective standpoint, that the coding stile is *aggressively* *ugly* :D Yeah, it's "standard", and probably working with it is the mature/sane thing to do, but I subjectively *hate* the damn thing and wish it didn't exist...
<ardb>
edk2 != uefi
<ardb>
granted, it is the reference implementation but other ones exist
<somlo>
hopefully at least one that doesn't cause one's eyes to burn when looking at it :D
<ardb>
and yes, it makes your eyes bleed
<ardb>
if only it were the worst thing about edk2
<somlo>
maybe I'm naive, but more legible code would make for a lower barrier to entry for fixing those other things you dislike about it :)
<somlo>
unless it's deliberate enshittification by whomever controls the spec, in which case, shrug...
heat_ has joined #riscv
heat has quit [Ping timeout: 256 seconds]
<jrtc27>
U-Boot is a perfectly fine minimal UEFI implementation
<jrtc27>
it's like a sloppier Linux kernel
<jrtc27>
I may not like the coding style, and the GPL nature of it is problematic for taking over some segments of the firmware market
<jrtc27>
but the point is to demonstrate implementation != spec
wingsorc__ has quit [Read error: Connection reset by peer]
wingsorc__ has joined #riscv
Armand has quit [Quit: Leaving]
<sorear>
like most words, "firmware" has multiple senses which are related in an intuitive but inexact fashion
<sorear>
is EBBR relevant here?
heat_ has quit [Remote host closed the connection]
ntwk has quit [Ping timeout: 248 seconds]
<muurkha>
I like the description "it's like a sloppier Linux kernel"
<muurkha>
ardb: a kernel image standard for kexec() that allows Linux and FreeBSD to kexec() each other wouldn't need to be even 1% as complex and bug-prone as UEFI
<muurkha>
I don't think UEFI's (and EDK2's) low quality is intentional. it's just that writing terrible software is easier than writing good software, and the process that spawned them didn't have the feedback loops necessary to make good software likely