<davidlt>
SiFive cooked a new (final?) batch of Unmatched in November IIRC.
<Tenkawa>
I'm looking at other distributors now
<davidlt>
Mouser is the official channel IIRC
<davidlt>
I doubt it's available anywhere else.
<Tenkawa>
I thought about the new Sophon boards but I still am not sure what to think
<davidlt>
Pioneer?
<Tenkawa>
Yeah
<davidlt>
I have one, but I would avoid anything with C910/920
<davidlt>
Especially if SG2380 / MilkV Oasis happens later this year
<Tenkawa>
Yeah I have been reading that as wel
<Tenkawa>
er well
<davidlt>
There is also SG2044 to replace currenct SG2042 with C920V2 also happening this year
<sorear>
is there an official changelog for c920v2?
<davidlt>
In general I have cases were Pioneer spinning all 64-cores is slower compared to Unmatched
<Tenkawa>
I like my Mars CM for a JH7110... is actually the fastest one I have... if only we had the mainline kernel adjustments for it heh
<drmpeg>
Tenkawa: That Mouser link says 27 can ship immediately.
<davidlt>
No, but I had the old datasheet and thus managed to compare them
<davidlt>
Main changes incl. vector V1.0 support, Sv48, cache coherence protocol change, and similar.
<Tenkawa>
oh.. yeah lead time if order is greater than 27
<Tenkawa>
read it wromg
<Tenkawa>
er wrong
<Tenkawa>
I don't like Mouser or Digikey's info page
<aurel32>
davidlt: tried to bisect the issue twice, but ended up with different wrong culprits. The problem is that we are sure of the bad commits, but not sure of the good one (and I tried each of the good ones with 3 different CONFIG_LOCALVERSION)
<davidlt>
I see, it's one of those annoying bugs to hunt
<aurel32>
yeah, just changing CONFIG_LOCALVERSION is enough to change the behaviour
<drmpeg>
Heisenberg.
<aurel32>
davidlt: I guess comparing the datasheets does not tell you the bugs that have been fixed (i.e. FPU one)
<davidlt>
aurel32, ah, yes, but someone reported that it's fixed in C908
<gurki>
aurel32: isnt there some errata?
<davidlt>
I would assume they took time to fix that in C920V2 too
<gurki>
id expect some appendix somewhere
<davidlt>
T-HEAD doesn't publish a doc with errata IIRC
<gurki>
:(
<davidlt>
(I might be wrong)
<davidlt>
there is also a bug that affects atomics
<davidlt>
for build-farm workload SG2380 (16-core SiFive P670) should nuke this from the sky
<davidlt>
not to mention starting price being 120 USD (no idea how they can afford this)
* bjdooks
idly wonders if horsecreek ever got out
<gurki>
i remember someone being quite unhappy about the sg2380 for architectural reasons, but i forgot the deatils
<davidlt>
bjdooks, from SiFive announcement low quantity partners only IIRC
<gurki>
details*
<davidlt>
it's 4 clusters, one is lower clocked
<gurki>
oh dear
<davidlt>
Think P/E cores, Zen4/Zen4C, this is more like AMD, I guess.
MaxGanzII_ has joined #riscv
<davidlt>
One cluster (4 cores) is more energy efficient, but it's the same cores.
<davidlt>
JH8100-series is also 4+1+1 IIRC
<davidlt>
I kinda like these designs, there are even rumors Intel could do 8 + 32 for Arrow Lake
<Tenkawa>
I'll ask the group... is the revision of the HiFive Unmatched going to be a worthwhile board to do development on for a while?
<davidlt>
Tenkawa, no
<Tenkawa>
ok I won't bother
<davidlt>
JH7110 is already faster and way cheaper
<Tenkawa>
I've got a "opportunity" for a purchase next month so I want to make sure I get the right one
<davidlt>
Probably the best next investment is SG2380 / MilkV Oasis.
<Tenkawa>
I have 4 JH7110's already
<Tenkawa>
Best one imo (once kernel/drivers catch up) is the Milk-V Mars CM in my testing
<davidlt>
Also JH8100-series upstreaming is ongoing thus shouldn't be too long before something gets announced.
<Tenkawa>
VF2 is good.. Star64 is ... something
<drmpeg>
Can you have a mainline kernel with VF2?
<davidlt>
Yes
<davidlt>
PCIe didn't land yet, that's annoying part
<drmpeg>
Ok.
<sorear>
the only noteworthy complaint with the sg2380 that I've heard in advance is that we don't know how the x280 / "AI" cores are going to be programmed, and they're not similar enough to the main cores to be used for task scheduling
<sorear>
is there anything other than the PCIe patchset that's not mainline yet and needed for normal headless usage?
<davidlt>
there are other patches IIRC, camera support (?)
<aurel32>
not having the 1.5GHz patch upstreamed is also annoying, although it still works without it, just slower
<davidlt>
aurel32, I kinda expected that to be resolved by now.
<aurel32>
you mean we don't need it anymore?
<davidlt>
Nah, I recall them saying that it will be fixed.
<davidlt>
most likely, I couldn't find anything recent
heat_ has joined #riscv
NicknameJohn has joined #riscv
heat_ is now known as heat
Stat_headcrabed has joined #riscv
erg_ has joined #riscv
crossdev has quit [Read error: Connection reset by peer]
BootLayer has joined #riscv
mlw has quit [Ping timeout: 264 seconds]
mlw has joined #riscv
<NicknameJohn>
Hi. Got a question. So afaik there are only 3 riscv "laptops" models yet and I expected more. What may the main constraints be?
shamoe has joined #riscv
Stat_headcrabed has quit [Quit: Stat_headcrabed]
unnick has quit []
ntwk has quit [Read error: Connection reset by peer]
ezulian has quit [Ping timeout: 255 seconds]
vagrantc has joined #riscv
MaxGanzII_ has joined #riscv
hightower4 has joined #riscv
hightower3 has quit [Ping timeout: 255 seconds]
MaxGanzII_ has quit [Remote host closed the connection]
MaxGanzII_ has joined #riscv
BootLayer has quit [Quit: Leaving]
lagash has quit [Ping timeout: 268 seconds]
zjason` has joined #riscv
zjason has quit [Ping timeout: 264 seconds]
davidlt has quit [Ping timeout: 246 seconds]
GreaseMonkey has quit [Remote host closed the connection]
JanC has quit [Ping timeout: 264 seconds]
hightower3 has joined #riscv
hightower4 has quit [Ping timeout: 268 seconds]
Narrat has joined #riscv
greaser|q has joined #riscv
greaser|q has quit [Remote host closed the connection]
<sorear>
if anyone has a "complete idiot's guide to setting up a clang/lld cross compilation env for linux, ideally with enough libraries to bootstrap clang" lying around you can link to, that would cut a lot of steps off of riscv-non-isa/riscv-elf-psabi-doc#425 being mergeable
<sorear>
NicknameJohn: demand, availability of suitable SoCs
bitoff_ has quit [Remote host closed the connection]
unnick has joined #riscv
<Tenkawa>
NicknameJohn: one major limiter right now to be blunt is GPU quality in the RISC-V area
JanC has joined #riscv
NicknameJohn has quit [Ping timeout: 256 seconds]
<jrtc27>
sorear: if you're willing to do freebsd I can give you a two-liner...
<jrtc27>
otherwise, does extracting the rootfs from a live image for a distro of your choosing not achieve that goal?
<sorear>
hadn't considered using a binary distro as a sysroot, that helps
<sorear>
wouldn't say I'm opposed to freebsd but the only build machine I have handy is nixos and doing anything slightly complicated on it gets painful
ntwk has joined #riscv
<gurki>
sounds like you should put sth different on your build machinr *runs*
<gurki>
machine*
<sorear>
tell me that in 2020 and I'll be eternally grateful.
<sorear>
meowray: JAL_THUNK is a relocation used with the 4-byte jal instruction when you (1) don't care about t1 and t2 before and after the jump (2) have a section boundary within 1 MiB of the pc so that the linker can insert something without breaking up a section. it can be relaxed into cm.j(al)t under the same conditions as a JAL relocation, I don't see how it _replaces_ cm.j(al)t
<jrtc27>
re nixos, yeah our magic build-all-the-things tool doesn't support that as nobody cared enough to figure out all the weirdness that needs handling
<meowray>
ah, ok. i feel unfortunate if linkers need to support so many different jump instructions
<jrtc27>
(we've had a grand total of one person try it and report that it didn't work)
ezulian has quit [Ping timeout: 264 seconds]
NicknameJohn has joined #riscv
mlw has quit [Ping timeout: 256 seconds]
lagash 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.]