crabbedhaloablut has quit [Ping timeout: 250 seconds]
BootLayer has joined #riscv
Noisytoot has quit [Ping timeout: 255 seconds]
<drewfustini>
conchuod: "make ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- DT_CHECKER_FLAGS=-m dt_binding_check -j8" (I only have 8) takes a long time. Do you know if it can just check a subset?
indy_ is now known as indy
vagrantc has quit [Quit: leaving]
<mtinman[m]>
<Tenkawa> "ahh its the spi/u-boot" <- Hey, have you flashed your VF2 to v2.11.5 firmware yet? If you did, how well does it work? Does it boot to NVMe SSD without using SD Card for boot?
<conchuod>
drewfustini: I run it on a thread ripper usually ;)
<conchuod>
If you just want the processed schema then dtbs_check gives it to you
<conchuod>
And that's waaay faster
<drewfustini>
I'm trying to get an example in a new yaml to pass and it seems to go through all the yaml files when I run that make command
<conchuod>
And you can do DT_SCHEMA_FILES=/path/to/new/yaml
<conchuod>
For the binding check
<drewfustini>
ah, thanks
<conchuod>
And that'll only test the one binding
<conchuod>
I think that despite the plural, it doesn't takes multiple
<drewfustini>
thanks, that is SO much better :)
<geertu>
conchuod: drewfustini: It used to work for multiple files (DT_SCHEMA_FILES="file1 file2 file3") too, but that was broken recently
MaxGanzII has joined #riscv
Noisytoot has joined #riscv
ldevulder has joined #riscv
<bjdooks>
grr, my ryzen9 has fallen over again :/
crabbedhaloablut has joined #riscv
Armand has quit [Remote host closed the connection]
Armand has joined #riscv
Stat_headcrabed has joined #riscv
<Stat_headcrabed>
How long it would take to compile linux kernel directly on VF2?
<jrtc27>
so either make your fdt64_t properly aligned to avoid UB or use unaligned_fdt64_t if you can only make it 4 byte aligned
Noisytoot has joined #riscv
Vyquos[m] has joined #riscv
Andre_Z has joined #riscv
heat_ is now known as heat
<heat>
what exception do you get? you're guaranteed to be able to do unaligned accesses in riscv (thru native CPU means or firmware emulation in M mode)
<bjdooks>
thsi is in uboot spl before it loads M
<heat>
ah yes
<jrtc27>
you're not guaranteed to be able to do unaligned accesses in riscv even outside M-mode
<heat>
there you have it then :)
<jrtc27>
that is only true on some platforms
<bjdooks>
in fact it's the opensbi loader that seems to be fucked
<heat>
jrtc27, ah yes they relaxed that recently right?
<jrtc27>
it just so happens that linux/freebsd/etc require such platforms
<jrtc27>
"recently"
<jrtc27>
many years ago
<bjdooks>
but we're trying to understand why and if the correct ix is to just sort uboot out
<jrtc27>
but yes, it used to be that S-mode and above was specified by the ISA as supporting unaligned accesses (up to around 2018/2019?)
<heat>
hey that's totally recent right????
<heat>
(time is weeiiiiird)
Noisytoot has quit [Read error: Connection reset by peer]
<mtinman[m]>
Tenkawa: If I get to it before you do I will post my dmesg, and anything else you might like to peek at, just let me know...
<mtinman[m]>
jrtc27: not sure yet.
<Tenkawa>
jrtc27: this is still vendor
<Tenkawa>
not mainline
<jrtc27>
that's clearly Linux output
<jrtc27>
I don't care what drivers Linux has
<jrtc27>
I mean in U-Boot
<jrtc27>
am I still forced to boot off a crappy SD card?
<mtinman[m]>
I had seen rumors that they fixed that.
wiagn has joined #riscv
<Tenkawa>
I don
<mtinman[m]>
jrtc27: And that was exactly my concern as well
<Tenkawa>
umm...
<Tenkawa>
oh wait yes I do
Stat_headcrabed has quit [Ping timeout: 252 seconds]
wiagn is now known as Stat_headcrabed
<jrtc27>
though as far as I can tell they still haven't fixed the FDT so it doesn't crash any OS that tries to bring up all the harts it claims exist
<conchuod>
They're in the process of upstreaming it to u-boot Jess.
<Tenkawa>
(tower of machines is too tall)
<jrtc27>
nor have they fixed the memory reported
<conchuod>
it being a pci driver
<jrtc27>
ok
<jrtc27>
but their release says they have it
<conchuod>
It probably does
<Tenkawa>
I hope the memory bug is fixed
<conchuod>
I just don't really care for what they're shipping on GtiHub, only what comes on the board and what's upstream..
<mtinman[m]>
conchuod: Amen.
<jrtc27>
I don't really care where it comes from so long as it works
jacklsw has quit [Read error: Connection reset by peer]
<jrtc27>
upstream is a little better than vendor, but I just want a working U-Boot I don't need to compile myself
<jrtc27>
you know, like any other computer
MaxGanzII has quit [Remote host closed the connection]
<conchuod>
If that's what you care about, then you can just update the boot script for the ram and cpu issues, no?
<mtinman[m]>
I dunno, I have had to compile for ARM SBCs as well at times...
<conchuod>
Aye, but that's not good user experience though is it
<jrtc27>
yes and those ARM SBCs are not real computers as a result; real computers ship with firmware you don't have to build yourself
<mtinman[m]>
jrtc27: Agreed.
<mtinman[m]>
Anything with DTBs...
MaxGanzII has joined #riscv
<conchuod>
> If that's what you care about, then you can just update the boot script for the ram and cpu issues, no?
<conchuod>
I'd be more "worried" about your generic bsd image not working when some random person tries to use it, which is only really solveable by what comes on the board by default
<jrtc27>
I have a /boot/lua/loader.lua or whatever it is for FreeBSD to patch up the FDT, but I can't do the same for the memory, and I cannot be bothered to figure out what arcane incantation is needed to make U-Boot run some custom code before bootefi
MaxGanzII has quit [Client Quit]
<jrtc27>
yes, exactly
<jrtc27>
but it's so hopelessly broken that step 0 for this is going to be to update firmware
<jrtc27>
and besides, it won't even recognise a USB stick with the installer on it
<jrtc27>
so in a way problem averted
<conchuod>
I think they have the same PCI IP as we do, give or take. Should probably look at their u-boot driver..
<jrtc27>
the whole thing just pisses me off because it's clearly there has been absolutely no attempt to perform any basic QA on the firmware they shipped and instead just tossed on whatever steaming pile of brokenness they had lying around at the time
<jrtc27>
I get that early firmware has bugs
<jrtc27>
but this goes so far beyond that it's unbelievable
<mtinman[m]>
I have to agree with you there, j.
<conchuod>
I guess their flow never used the u-boot dt beyond u-boot?
<jrtc27>
anyway rant over...
<jrtc27>
well, clearly
<conchuod>
But I don't really get why they bothered turning on the S7 in u-boot in the first place.
<mtinman[m]>
jrtc27: I have had that rant already myself...
<jrtc27>
because linux is set on the mentality that the FDT ships with linux...
<jrtc27>
which is ass-backwards
<jrtc27>
I get *why* that's the case, but how many years has the world had to fix this mess?
<jrtc27>
conchuod: they even go to great lengths to ensure that opensbi initialisation happens on the S7 core, IIRC
<mtinman[m]>
jrtc27: Last time I checked FDTs were dispersed with the device by the vendor.
<jrtc27>
some magic cold-boot-hart FDT property to force it
<jrtc27>
mtinman[m]: that's the theory, but in practice linux just ships its own copy of every FDT you could ever want so that it can change bindings whenever it sees fit
<jrtc27>
they're better about that now but still not perfect
<jrtc27>
they at least acknowledge the existence of other OSes that have to parse these FDTs and change their drivers whenever linux decides to break things
KombuchaKip has quit [Quit: Leaving.]
<jrtc27>
ah no ok they set starfive,boot-hart-id = <1>;
<conchuod>
Is it?
<conchuod>
>because linux is set on the mentality that the FDT ships with linux
<jrtc27>
is there a distro that doesn't do that?
<jrtc27>
everywhere I look, whether it's riscv or arm, that's how things work in linux land
<conchuod>
Well, the distros might do it but I don't get to operate on that basis.
sh1r4s3_ has quit [Ping timeout: 268 seconds]
ldevulder has quit [Quit: Leaving]
<conchuod>
jrtc27: I don't understand the point of that boot hart property
<jrtc27>
nor do I
<jrtc27>
they mumbled something about debuggability
<conchuod>
?
<jrtc27>
got merged to opensbi despite my many objections
<jrtc27>
let me go find the mess of a thread...
<conchuod>
If you really care about "debugability" then don't tell your software that the other CPUs exist?
<jrtc27>
ah right it did in fact get reverted in upstream opensbi
<conchuod>
heh
<conchuod>
If you wanna do development you can achieve the same result in other ways
<conchuod>
Also, and this is probably my lack of opensbi knowledge showing, how come that is in dt? Doesn't opensbi know what platform it is running on & can just do things like this without having to parse for a dt property?
<jrtc27>
but yes, FDT is for hardware, not software policy
Armand has quit [Read error: Connection reset by peer]
<conchuod>
^
<jrtc27>
"what hart does OpenSBI want to boot on" is not hardware
<jrtc27>
and for extra fun the FDT doesn't even live in OpenSBI's repo, it's in U-Boot's...
<jrtc27>
at least it's in /chosen where other abominations exist...
prabhakarlad has quit [Quit: Client closed]
brazuca has quit [Ping timeout: 260 seconds]
<drewfustini>
patches for arch/riscv are supposed to be bases on riscv/linux.git for-next branch, right?
vagrantc has joined #riscv
jellydonut has quit [Quit: jellydonut]
armand_ is now known as Armand
prabhakarlad has joined #riscv
<Stat_headcrabed>
conchuod: how do you test mainline kernel patches on vf2?
<conchuod>
Stat_headcrabed: can you be a little more specific?
<Stat_headcrabed>
well i'm developing pmic driver for this board
<conchuod>
I build a kernel+dtb, tftp them to my board, boot that and then what I do highly depends on what it is for
<conchuod>
drewfustini: ye or riscv/linux.git master
<Stat_headcrabed>
How to generate initramfs?
<Stat_headcrabed>
Or qemu needed?
<conchuod>
I build one with buildroot, but you probably don't need an initramfs. Do you not have an existing userspace that you use with their kernel on an sd card or something?
<Stat_headcrabed>
Initramfs could be different from vmlinuz version?
<Stat_headcrabed>
I thought they should be same
<conchuod>
I boot the same initramfs for everything /shrug
<Stat_headcrabed>
ok, that would be much easier foe me
<Stat_headcrabed>
thanks
<conchuod>
Easiest thing is just to use whatever userspace you already use right now
<Stat_headcrabed>
I would rather use starfive's debian userspace
<Stat_headcrabed>
Currently, regulator framework complains "failed to get the current voltage" to me, still digging code for reason
JanC has quit [Ping timeout: 265 seconds]
jellydonut has joined #riscv
JanC has joined #riscv
jmdaemon has joined #riscv
Stat_headcrabed has quit [Quit: Stat_headcrabed]
rurtty has quit [Quit: Leaving]
Narrat has joined #riscv
brazuca has joined #riscv
Stat_headcrabed has joined #riscv
Stat_headcrabed has quit [Client Quit]
jobol has quit [Quit: Leaving]
grgy has quit [Remote host closed the connection]
grgy has joined #riscv
MaxGanzII has joined #riscv
brazuca has quit [Quit: Client closed]
brazuca has joined #riscv
BootLayer has quit [Quit: Leaving]
<drewfustini>
conchuod: I just read hellwig NAK on " Re: [PATCH v7 1/6] riscv: mm: dma-noncoherent: Switch using function pointers for cache management". It doesn't seem like that is something for him NAK as it is in arch/riscv, right?
<conchuod>
He is the dma maintainer?
<drewfustini>
yeah... for kernel/dma, but I was thinking about if that applies to arch/riscv/include/asm/dma-noncoherent.h
sh1r4s3 has joined #riscv
<jrtc27>
his facts are wrong anyway... Zicbom came after vendor extensions because RVI dragged its heels on the issue
<drewfustini>
yeah
<jrtc27>
(yes, coherent DMA would be nice, but vendors gonna vendor...)
<drewfustini>
that is what I was thinking... nothing that exists right now had any standard options when it was designed
<drewfustini>
the specs just said we expect the system to be coherent... which isn't very practical for these lower end SoCs
<drewfustini>
The bar should be higher for next generation of SoCs (late 2023?, early 2024?) which is reasonable to expect to have Zicbom and Svpbmt in their cores.
<jrtc27>
making DMA coherent isn't hard or expensive
<drewfustini>
ah
<jrtc27>
it's just harder if you want it to perform well
<jrtc27>
the lazy option is to just plumb DMA as another last-level cache client
<drewfustini>
I don't know much about SoC design but I had thought making all the peripheral coherent made the design more complex and/or required more die area.
<jrtc27>
only really for a single core system
aredridel has quit [Read error: Connection reset by peer]
<jrtc27>
if you have more than one you already have the logic in your LLC to do coherency between the cores
<conchuod>
> his facts are wrong anyway... Zicbom came after vendor extensions because RVI dragged its heels on the issue
<conchuod>
Oh yah, I forgot to reply and point that out.
aredridel has joined #riscv
<drewfustini>
I have a somewhat niche non-coherent system I need to get working soon and I was happy at the thought of function pointers instead of ALTERNATIVES(). I still have not fully grok'd those macros.
brazuca has quit [Quit: Client closed]
<drewfustini>
conchuod: does the PolarFire SoC avoids all this because the DMA capable peripherals are on a cache coherent interconnect?
<conchuod>
Welll.....
<conchuod>
We can avoid it, but there are some reasons that we want to do it. Namely working around a PCI controller that's only 32-bit capable and some other fun.
rurtty has joined #riscv
<drewfustini>
Is it that the interconnect (bus?) used has a coherency protocol?
<drewfustini>
I suppose it doesn't really matter but sometimes I wonder how the hardware magically knows to keep dma buffers coherent between the cpus and the dma'ing peripheral controller.
<Tenkawa>
Well.. updated my spi and fw but no luck.. still showing up as 4gb instead of 8gb...
<Tenkawa>
hmm
brazuca has joined #riscv
KombuchaKip has joined #riscv
brazuca has quit [Quit: Client closed]
ntwk has quit [Ping timeout: 255 seconds]
<mtinman[m]>
How about NVMe boot?
<Tenkawa>
I'd need to rebuild my os
<Tenkawa>
I run a XFS root currently
<Tenkawa>
that doesn't boot on "any" u-boot
<mtinman[m]>
Oh, ok, I'll be testing it tonight, and keep you posted...
<mtinman[m]>
Oh, really?
<Tenkawa>
No.. you have to chainload it on all setups
<mtinman[m]>
Well thank you, I didn't know that...
frkazoid333 has quit [Ping timeout: 250 seconds]
<Tenkawa>
I haven't found one yet even on arm that can boot XFS without a helper...
<mtinman[m]>
Tenkawa: I had to build it into the bios on my Dell WS...
<Tenkawa>
I like XFS perf though so I dont mind using a chainload
<mtinman[m]>
Small PITA, but WELL worth it!
<mtinman[m]>
Is XFS a COW fs?
<Tenkawa>
Case preservation Copy-on-write Data deduplication Data scrubbing Execute in place Extent File attribute Extended file attributes File change log Fork Links Hard Symbolic
<Tenkawa>
yeah... lot of features
frkazoid333 has joined #riscv
bauruine has quit [Remote host closed the connection]
Andre_Z has quit [Ping timeout: 268 seconds]
billchenchina has quit [Ping timeout: 250 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.]
troglodito has quit [Ping timeout: 265 seconds]
guerby has quit [Remote host closed the connection]
guerby has joined #riscv
troglodito has joined #riscv
Armand has quit [Remote host closed the connection]
Armand has joined #riscv
JanC_ has joined #riscv
JanC is now known as Guest2516
Guest2516 has quit [Killed (cadmium.libera.chat (Nickname regained by services))]
JanC_ is now known as JanC
MaxGanzII has quit [Ping timeout: 255 seconds]
wingsorc has joined #riscv
KombuchaKip has quit [Quit: Leaving.]
jmdaemon has quit [Ping timeout: 248 seconds]
pedja has quit [Quit: Leaving]
jmdaemon has joined #riscv
sh1r4s3_ has joined #riscv
sh1r4s3 has quit [Read error: Connection reset by peer]