<jrtc27>
if riscv_cbom_block_size were initialised to 0 it would work
<jrtc27>
the default of L1_CACHE_BYTES probably got added later
<conordooley>
Maybe I am just in weekend mode already /shrug
<jrtc27>
alternatively have a local variable in riscv_init_cbom_blocksize that tracks what the maybe-found one is and conditionally update riscv_cbom_block_size to that at the end
<jrtc27>
easier for the compiler to reason about too
<jrtc27>
oh right declared cbom_hartid is inside the loop's scope
<conordooley>
I'm just not sure what the intent for cmbom_hartid is though.
<jrtc27>
that's even worse
<conordooley>
I assume the intent is to say "nah your blocksize doesnt agree with the last hart I checked"?
<jrtc27>
well, first hart that had the property
<jrtc27>
but yeah
<jrtc27>
note this also fails to diagnose when some harts have it and some don't
<jrtc27>
really it should be if (first) set blocksize else check exactly the same
<conordooley>
I gotta cycle home, but unless you feel like putting this in an email I'll do it when I get back
<palmer>
IIUC that code works (asize from the int/long truncation)
<jrtc27>
I don't have the patch in my inbox for some reason
<jrtc27>
nah it's UB
<jrtc27>
in the warning case
<jrtc27>
and the warning case hits whenever the property exists and has a value other than L1_CACHE_BYTES
<jrtc27>
as the code is just a total mess that doesn't do what it thinks it does
<conordooley>
Specifically: arch/riscv/mm/dma-noncoherent.c:107:6: warning: variable 'cbom_hartid' is uninitialized when used here [-Wuninitialized]
<conordooley>
I see you sent a patch palmer, guess you may as well define cbom_hartid while youre at it
<palmer>
ya, sorry, it's early
<palmer>
I'll just fi x it
<Esmil>
MoeIcenowy: there is not really a plan. it's still unclear if it's even wanted upstream
Xav101 has joined #riscv
<palmer>
Esmil: you're talking about the jh7100 support?
<MoeIcenowy>
Esmil: well yes I may want to wait 7110 too
<Esmil>
palmer: yes
<MoeIcenowy>
what I heard is that 7100 is only produced in a low amount
<wmat>
LetoThe2nd: no, that's implementation specific
<palmer>
ya, that'd essentially be my argument: it's just a super buggy chip and they're fixing it, the projects it was going in to kind of died out
<Esmil>
exactly. it's a mpw (multi project wafer)
<Esmil>
..for testing the jh7110
conordooley has quit [Quit: Client closed]
<palmer>
I've seen some posts about boards go but, I'm never clear which chip they have but if these things actually ended up out in the real world then I'd be happy to take code for it
<MoeIcenowy>
Esmil: well the existing number seems to be a bit more than what I recognize as a MPW
<MoeIcenowy>
(I think FU540 is a MPW tapeout too
<Esmil>
palmer: well, the visionfive v1 and starlight boards are in the real world
<palmer>
OK, I wasn't super sure about that -- I have one of the early test runs, but I thought they didn't go much farther than that
<palmer>
but if they actually got to real users and can be made to work (which IIRC was kind of up in the air last time, they were pretty broken) then I wouldn't have any problems taking support for them
<MoeIcenowy>
I have some friend that bought VisionFive v1 in public way
<Esmil>
once the visionfive v1 boards are sold out there won't be any more
<MoeIcenowy>
and the performance is shocking to her (shockingly low)
<Esmil>
MoeIcenowy: well, they're faster than the D1 :P
<MoeIcenowy>
Esmil: well only if the draft-V on D1 is not counted
<Esmil>
MoeIcenowy: that would only be for specific workloads though
<Esmil>
not boot linux, run some python code fx.
<dramforever__>
I don't think there's enough interest in the soon-to-be-obsolete JH7100 to be worth it taking all these efforts to make it run mainline Linux
<dramforever__>
From what I see though, VisionFive V1 is definitely a publicly available board you can buy, but it is pretty broken
<MoeIcenowy>
BTW for D1 mainlining I think a problem on U-Boot is that existing sunxi code is highly coupled with arm architecture
<MoeIcenowy>
I scouted an intern in OSPP to do D1 mainlining
<palmer>
just try to reduce the config and post it
<conchuod>
btw your DKIM is failing palmer
<palmer>
interesting
<conchuod>
I don't recall it failing the last time I b4'ed something of yours
<palmer>
I was sending email from home this morning, so maybe it's broken over there
<palmer>
Google has been telling me they're going to shut off my authentication mechanism for like a year now, so it's also possible something's broken
<conchuod>
dunno, it was the v2 zicbom I just downloaded
<conchuod>
Hmm that's your own email & I think the other was the rivos mail. I'll keep an eye out.
jacklsw has joined #riscv
dramforever__ has joined #riscv
dramforever_ has quit [Ping timeout: 255 seconds]
davidlt has quit [Ping timeout: 244 seconds]
Xav101 has quit [Ping timeout: 252 seconds]
jack_lsw has joined #riscv
aerkiaga has quit [Remote host closed the connection]
jacklsw has quit [Quit: Back to the real world]
<conchuod>
hmm that zicbom patch looks no good to me unfortunately palmer build failure with clang..
jack_lsw has quit [Read error: Connection reset by peer]
<palmer>
OK, I probably just didn't even build it -- I wasn't worried about it for this MW anyway
<conchuod>
(:
<conchuod>
tbf palmer it built with gcc
<conchuod>
But I don't think my gcc supports zicbom
davidlt has joined #riscv
brazuca20 has joined #riscv
brazuca has quit [Ping timeout: 252 seconds]
dramforever_ has joined #riscv
dramforever__ has quit [Ping timeout: 268 seconds]
brazuca20 is now known as brazuca
BootLayer has quit [Quit: Leaving]
ffcc has quit [Remote host closed the connection]
davidlt has quit [Ping timeout: 268 seconds]
cwebber has quit [Ping timeout: 255 seconds]
<DynamiteDan>
greetings. Are there already riscv servers without counting fpga based? Thanks in advance
___nick___ has quit [Ping timeout: 268 seconds]
cwebber has joined #riscv
<conchuod>
What do you mean by "servers"? I'd have thought that running cores implemented in an FPGA would be pretty unsuited to what I'd consider a server
fedorafan has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<drmpeg>
The Rivos folks are working on servers. But they're still in super stealth mode.
<jrtc27>
proper servers will be blocked on AIA, IOMMU, ACPI etc...
<jrtc27>
whole bunch of server-y parts of the architecture and platform ecosystem that just aren't there
dramforever__ has joined #riscv
<conchuod>
jrtc27: soonTM
dramforever_ has quit [Ping timeout: 268 seconds]
<conchuod>
I have a rack beside my desk here, @rivos feel free to send me a server when you have one ;)
dramforever_ has joined #riscv
dramforever__ has quit [Ping timeout: 252 seconds]
<dh`>
depends what you mean by "server"
<dh`>
none of that crap is really necessary as long as you have disks and ram and cpus
<dh`>
I guess some people need those horrible management console things (not happening anytime soon) and others need thermal monitoring, but that seems like all that actually matters
<conchuod>
Depends on if your target market
dramforever_ has quit [Read error: Connection reset by peer]
dramforever__ has joined #riscv
<DynamiteDan>
ah okay
<DynamiteDan>
so we can see riscv as a replacement of mips on expansion cards
wingsorc has quit [Quit: Leaving]
strlst has quit [Quit: Lost terminal]
<muurkha>
LetoThe2nd: not that I've seen. despite the whole RV64IMACFDZicsrZomgwtfbbq thing, AFAIK there isn't even a letter to indicate whether it implements page tables and separate privilege levels or not
<muurkha>
RV32 is usually microcontrollery things and RV64 is usually things that can run Linux or FreeBSD, but that's not necessary
<conchuod>
Zomgwtfbbq
<conchuod>
sounds about right...
<conchuod>
Zihintpause I get
<conchuod>
but Zicbom doesnt exactly convey its meaning in the same way
<muurkha>
heh
<muurkha>
Zicsr is perfectly clear though!
<muurkha>
all of them are dramatic improvements over "i7-3840QM" though
<dh`>
yes and no
<dh`>
intel's stuff is marketing-driven and that causes various problems
<dh`>
but a model number you look up in a table is, realistically, probably a bettter solution than gigantic feature strings
<muurkha>
also "i7" does imply that it has an MMU
<muurkha>
which is close to what LetoThe2nd was asking
<conchuod>
I think I missed Leto;s question, but I don;t think that i5-10400f or R9 3950X is in the same category as the isa string
aerkiaga has joined #riscv
<dh`>
it is not (and also it only works for single-vendor environments) but it's similar
<dh`>
but I suppose for x86 the real thing is what the cpuid instruction spews
<conchuod>
An environment where the vast majority of customers have no idea about what an MMU is
<dh`>
anyway, nobody has ever really solved this problem (robust identification and handling of architecture variants)
<dh`>
nor does anybody really acknowledge that it's a fundamentally different problem at different points in the market
<conchuod>
Processor naming is awful across the board
<muurkha>
conchuod: the question was what, if anything, was the RISC-V equivalent to the Cortex-M vs. Cortex-A (and Cortex-R) distinction
<jrtc27>
it's not a problem in the microcontroller space because your BSP is intimately tied to your hardware
<conchuod>
I hate the AMD naming, R7 5600X and then R5 7YYY.
<conchuod>
And then add Zen <N> to that
<jrtc27>
it's the same as intel, just s/((Ryz|Z)en|R)/i/...
<conchuod>
Spent ages the other day trying to explain all that to my brother.
<conchuod>
intel gets a pass because its been like that for such a long time, but I feel with the ryzen stuff no-one really mentions the R<N> bit
<conchuod>
Not that intels naming is good either, just the AMD one came up the other day for me
<jrtc27>
it's only more confusing than intel because (a) people are less exposed to it (b) we're at generations that collide with the 3/5/7 naming and multiple of them are available at the same time
<jrtc27>
and I guess intel like to use their well/lake-based naming in preference to nth generation
<conchuod>
Intel also skipped some of the problematic ones didn't they
<jrtc27>
ivy bridge was 3rd, broadwell was 5th, kaby lake was 7th
<conchuod>
I forgot kaby lake existed haha
<conchuod>
suppressed memories maybe
<jrtc27>
how many of the lakes between skylake and alder lake does anyone remember...
<jrtc27>
"it's another something lake, thanks intel for my 1% performance increase"
<conchuod>
But ye, I guess youre right about the names rather than zen n
<jrtc27>
intel is also the company that brought you 14nm+++
<conchuod>
Well theyre not the only liars there are they
<jrtc27>
having said that, AMD also screwed up with Zen/Zen+/Zen 2/Zen 3 being 1/2/3/4...
<jrtc27>
and I guess you're right that Zen X not being the same thing as Ryzen X is confusing
<jrtc27>
since those are orthogonal terms
<jrtc27>
so I guess I take it back somewhat
<conchuod>
While we are bagging on AMD, their GPU naming is even worse
<muurkha>
I'm waiting for AMD to name their next line of processors after a different religion
<conchuod>
I have no idea anymore what GPU is what in their range (but I did back in the days of 7950 etc)
<muurkha>
following AMD Zen we could have AMD Wahhabi and AMD Presbyterian
dramforever_ has joined #riscv
<conchuod>
Going for a complete reset like they did is fine I guess, but at least do something completely different, not make a 6800 etc
dramforever__ has quit [Ping timeout: 252 seconds]
<conchuod>
AMD Satanism anyone?
<muurkha>
just don't try to put an AMD Wahhabi in the same system as an AMD Shiite, they will have a conflict
* psydroid
will settle for Tygon Dhyana
<conchuod>
AMD Shiite would have a different meaning here muurkha
<muurkha>
it would?
<conchuod>
Maybe AMD Shiite is what they can call their entry level products
<conchuod>
It's a phonetic spelling of how we'd pronouce shite
<muurkha>
oh, right
<muurkha>
actual Shiites generally say Shia
<psydroid>
AMD Alevite
<psydroid>
AMD Baha'i
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #riscv
bauruine has quit [Remote host closed the connection]
<conchuod>
palmer: I only just noticed you took the gpio binding patch.. Do I remember you saying Rob could then enable dtbs_check for RISC-V in his bot?
<palmer>
I was actually looking for his bot right now
<palmer>
I'm getting a ton of failures locally, but they don't seem to be related
<conchuod>
There should be none now with the minimum supported dt-schema
<conchuod>
(v2022.03)
<conchuod>
There's new ones with v2022.08 that I am currently spinning a v2 for.
<palmer>
OK, I'm way out of date
<palmer>
never mind, I was on the wrong box
<palmer>
$ dt-validate --version
<palmer>
2022.3.2
<conchuod>
There "should" be none now with that.
<palmer>
OK
<palmer>
now that I open the file and look I see no errors, but I thought I looked like 6 minutes ago and had a bunch
<conchuod>
can't help with that! /shrug
<palmer>
I just had an out of tree patch
<palmer>
I think it's OK
<palmer>
the out of tree patch was to fix these tegra210-quad-peripheral-props.yaml failures
aerkiaga has quit [Remote host closed the connection]
<palmer>
I'm getting a bunch of stuff like /scratch/merges/ko-linux-next/linux/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml: 'additionalProperties' is a required property
<conchuod>
I'm not seeing that but my dt-schema is a lot newer. I'll downgrade.
<conchuod>
Yeah, downgraded those show up. A shit load of them actually.