<conchuod>
mmind00: have you tried using the D1 with a toolchain that does not support Zicbom?
GenTooMan has quit [Ping timeout: 244 seconds]
<mmind00>
conchuod: hmm, in the beginning I had both zicbom + thead cmos as encoded .long instructions - at that point yes ... but am not sure which combinations I tested after moving to zicbom instructions ... did you encounter an issue?
GenTooMan has joined #riscv
<conchuod>
Yeah mmind00 but I am not exactly sure what the cause is yet.
<conchuod>
Rebuilding with a zicbom enabled toolchain atm
<mmind00>
conchuod: hmm, I'd think the kconfig option _should_ catch the non-zicbom toolchain ... when you try to build with the non-zicbom toolchain, it should not present the zicbom kconfig option?
<conchuod>
What is actually meant to happen on a D1 if you don't have zicbom in your toolchain?
<mmind00>
it should work just as well ... i.e. there is the general noncoherent option which gets activated bei either zicbom-extension or the d1-cmo-errata
<mmind00>
and the noncoherent code itself then is a 3-way alternative between a nop, zicbom or d1-cmo patched in depending on what is available
<conchuod>
I am using the plain risc-v defconfig with an initramfs, a 512M hacked in memory node, gcc 11.1
* mmind00
also clearly remembers building kernels with non, zicbom, d1-cmo, zicbom+d1-cmo config variants
<conchuod>
Let me build with clang and see what happens there & then rebuild with GCC again & check what is in my .config.
<conchuod>
I've had an unfun time so far trying this patchset haha
<mmind00>
conchuod: can you check in your .config what CONFIG_RISCV_DMA_NONCOHERENT, CONFIG_CC_HAS_ZICBOM, CONFIG_RISCV_ISA_ZICBOM and CONFIG_ERRATA_THEAD_CMO say
<conchuod>
So: clang-15 build kernel hangs while loading my initramfs. That may be my fault, but the initramfs /did/ work on the d1-wip branch. That .config has all of the above =y
<conchuod>
My GCC 11.1 gives not found for the ZICBOM ones, =y for CONFIG_RISCV_DMA_NONCOHERENT & CONFIG_ERRATA_THEAD_CMO
<mmind00>
I guess that is the non-zicbom one, right? I just moved to a newer binutils version when doing that ... but in any case, that looks like the expected config-variant for that case
<mmind00>
conchuod: moving forward, are you getting a build error or runtime issue?
<conchuod>
runtime, just pasting logs atm.
knolle has quit [Ping timeout: 268 seconds]
<mmind00>
conchuod: and does building the kernel with the same config variant (=zicbom disabled) with the newer toolchain result in the same issue?
<conchuod>
well idk what's happened now - it's not giving me the problems I had a few minutes ago
<mmind00>
and what does " it's not giving me the problems I had a few minutes ago" mean?
<conchuod>
I was getting RCU stalls prior & it was boot-looping. I rebuilt my initramfs too this time, so I guess that there may have been something in that that has problems on a d1
<conchuod>
sorry, I am not a fast typer
<mmind00>
no worries :-)
<mmind00>
conchuod: so when you build with new(-zicbom)-toolchain, it hangs when CONFIG_RISCV_ISA_ZICBOM is disabled and runs when CONFIG_RISCV_ISA_ZICBOM=y ?
<conchuod>
It hangs at debug_vm_pgtable for me with booth the above GCC and CLANG settings for those options.
<conchuod>
There's gotta be something else wrong with my setup..
<conchuod>
mmind00: argh, I figured it out. The hanging was in fact a bad initramfs..
<mmind00>
phew
<conchuod>
Yeah! sorry for the noise haha
<mmind00>
conchuod: definitly no worries ... a false alarm is waaaaay better than finding out if there was a major issue there
<conchuod>
I had not rebuilt my boot.scr so it was automatically loading an old initramfs (:
knolle has joined #riscv
<conchuod>
btw, on a really high level, what difference does having ZICBOM make?
<conchuod>
Is there a massive performance gain?
<mmind00>
beats me ... i.e. right now its all qemu, hardware using that is still somewhere in the pipeline hopefully
<conchuod>
Oh right
<conchuod>
I think I misunderstood what was going on
<mmind00>
the riscv-booth at embedded-world had multiple cpu-core companies present and I did ask all of them about svpbmt and zicbom, but they didn't even seem to know these extensions :-)
<conchuod>
I had it in my head for some reason that a zicbom toolchain was required for full D1 support
<mmind00>
nope, thankfully they're completely separate ... only that zicbom and d1-cmo are frigthingly similar
<conchuod>
idk if you have seen me flailing around with regexes mmind00 for the isa string? I think it is funny that we basically are all good with rv64imafdc in the kernel & have been for quite a while
<mmind00>
conchuod: I remember seeing a lot of patches about the isa string parsing, but have no real memory about details :-)
<conchuod>
I am curious what this supposed chromebook-esque laptop is going to have in it
<mmind00>
there is a chromebook-esque device upcoming?
<conchuod>
The details are better forgotten to be quite honest, unless you want to bleach your eyes.
<mmind00>
they (+vendor-site) sadly don't really talk about the riscv-core in there
<conchuod>
The details of the regex stuff is not important, it's just the fact that we've not really seen anything fancier than rv64imafdc yet kernel wise
<conchuod>
Yup, I think there were some rumours being discussed here maybe a few days ago.
<conchuod>
Not to be harsh, but while a risc-v laptop sounds cool and all - it feels like a very bad use of my money
<mmind00>
haha, probably
<conchuod>
The website was full of crap about web3 which for me is an instant turnoff
<conchuod>
No I do not want a risc-v laptop NFT tyvm!
<mmind00>
:-D
<mmind00>
also, that aged not well, judging by all the nft/crypto/etc news recently
<conchuod>
My cousin works for an NFT trading company, he has done well out of it b/c he was not laid off - but they've let like half their staff go.
<conchuod>
I feel bad b/c the recruiters/HR etc in those sort of companies are not NFT fanboys or whatever, but they're affected.
EchelonX has joined #riscv
EchelonX has quit [Remote host closed the connection]
EchelonX has joined #riscv
<conchuod>
mmind00: does the d1 have l2? I am getting 404s on links in their webpage & google isnt doing me much good either
<conchuod>
It looks like no, but hard to get a clear answer from google.
Andre_H has joined #riscv
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.]
jobol has quit [Quit: Leaving]
<smaeul>
conchuod: D1 does not have any L2 cache
<dh`>
conchuod: people who go work for those companies ought to have done their due diligence on the companies' real prospects
<dh`>
can we expect non-techies to realize that all this nft and blockchain stuff is a scam? probably, the information is readily available to anyone who cares to look
<smaeul>
conchuod: I will reply to your email in a bit, but it's not just the memory node that requires the DTB to come from firmware (although that is the most obvious reason). OpenSBI adds a reserved memory node, and will add CPU idle states in the future. U-Boot sets the Ethernet MAC address.
<smaeul>
platform firmware also decides what resources get reserved for the DSP or for a secure partition
<conchuod>
Ye smaeul take your time :)
<conchuod>
And thanks re the l2
<conchuod>
I have my thoughts on those reasons but we can discuss them on the mail thread
ghee has joined #riscv
<conchuod>
dh`: true, but I would not expect the likes of my mother to really be able to understand. Maybe that is reason why she shouldn't go work there but idk