dgilmore changed the topic of #fedora-riscv to: Fedora on RISC-V https://fedoraproject.org/wiki/Architectures/RISC-V || Logs: https://libera.irclog.whitequark.org/fedora-riscv || Alt Arch discussions are welcome in #fedora-alt-arches
davidlt has joined #fedora-riscv
<davidlt> conchuod, to make you happy this morning, there is "C920V2".
<davidlt> I have been looking at the old C920 datasheet and C920V2 to compare them.
<davidlt> They are slightly different, but basically tweaked to fix/improve some things.
<davidlt> Esmil, are you around?
<conchuod> I heard it potentially has vector V1?
<davidlt> conchuod, it does.
<davidlt> conchuod, v1.0, sv48 was added, different cache coherent protocol, Priv 1.12, removal of memory attribute extension (the one that used reserved bit IIRC).
<davidlt> conchuod, it seems to be just enough to solve SG2042 problems
<davidlt> It's not very much V2, it's more like a refresh.
<conchuod> I really really hope that it does marchid set.
<davidlt> execution units, pipeline, etc. didn't change.
<conchuod> has*
<davidlt> conchuod, well that is a truly interesting question ;)
<conchuod> They started setting that for their new cores.
<conchuod> And the zero marchid/impid is used to apply the erratum
<davidlt> Yeah, the question is when C920V2 happened, before or after that decision.
<davidlt> I wonder if they fixed other erratas too
<davidlt> atomic stuff
<davidlt> floating point
<conchuod> If they didn't, we will have to account for that in the kernel.
<conchuod> Do you know if there is an SoC it is going to show up in?
<davidlt> conchuod, no, but I bet it's SG2044.
<davidlt> That's updated SG2042. It's to be released in 2024, and it has vector v1.0.
<davidlt> Most likely it's C920 -> C920V2.
<davidlt> From news:
<davidlt> Otherwise, the 64-core Sophgo 2044 is an incremental upgrade — it will support PCIe Gen5, Gigabit Ethernet, and LPDDR5x. It will draw up to 120 watts of power.
<davidlt> and C920V2 really solves the current 64-core problems
<conchuod> the issues with that soc are not the cores though, its the memory bandwidth etc, right?
<conchuod> I have one actually, but I have yet to get around to setting it up somewhere at home. Had it at work for a while.
<davidlt> conchuod, I am getting one (V1.3), I think.
<conchuod> Jisheng I think told them to send me one.
<davidlt> what I don't like is that IP/SoC seem to be rushed to me (again, atomic issues [do you trust it?], floating point issues [glibc tests failing], they way they did marchid, etc.).
<davidlt> I get it, it's growing pains.
<davidlt> But it is an e-waste basically.
<conchuod> Ye, very laissez-faire attitude there.
<conchuod> Although the killer issue for that SoC is the horrible performance
<davidlt> Oh yes, and it's not gonna improve significantly.
<davidlt> I am all for that 16-core P670 board.
<davidlt> It will be way more useful for me. I don't need tons of cores, I need a good ST performance.
<davidlt> It's not like I am running a large SIMD workflow that just processes numbers.
<davidlt> Even that might actually work better on SG2380.
<davidlt> I am all for 64 + 4-8 monster cores, like what Intel does. 8 + 16, and rumors suggest 8 + 32 maybe in the future.
<davidlt> Xoen Phi with 60+ cores + 512-bit vector was kinda cool too .. for number processing, but it took 10 minutes to launch Python IIRC.
zsun has joined #fedora-riscv
<Esmil> conchuod: now i am :)
<Esmil> conchuod: btw. i looked at the th1520 clocks, and then the sg2042 clock patchset. it seems like they use the same PLL ip at least. i'll dig a bit and see if it's also the dividers and muxes
<Esmil> ..so ideally we'd share some of that code
<Esmil> drewfustini: ^
<conchuod> it was davidlt that was looking for you
<conchuod> Do you know what IP it is?
<conchuod> If you could comment on the patchset to that affect it'd be nice.
<Esmil> yes, they say that in the th1420 system user manual. 2sec
davidlt has quit [Ping timeout: 256 seconds]
<Esmil> "Silicon Creations {integer PLL,Sigma-Delta PLL}"
<conchuod> Ye, I am not surprised.
<Esmil> i think the difference is just whether the fractional part does anything
<conchuod> I felt like I recognised some of the terminology in the patches when I looked at them.
<Esmil> conchuod: have you worked with the same ip?
<conchuod> All the PLLs in mpfs are silicon creations IP I think.
<Esmil> oh! ehh
<Esmil> heh
<conchuod> We have quite a lot of PLLs but they're all the same IP. There's like 11 of them + some DLLs too IIRC.
<Esmil> ..and each of them has the same cfg0, cfg1, cfg2 and cfg3 registers, where cfg0 mostly controls the integer parts and cfg1 is mostly flags and the 24bit fractional part?
<conchuod> I don't think that part is the same, but the formulation of the PLL itself seems similar.
<conchuod> Does tge 1520 doc have a register map?
<conchuod> Esmil: Is that for the PLL?
<Esmil> yes, they mixed the pll register with different types of registers for muxes and gates
<Esmil> *pll registers
<conchuod> It's not the same layout, but the same bits are there in other places etc.
<Esmil> ah, so maybe different versions
<conchuod> The ones we have seem more complex.
<Esmil> maybe you got the pro version then ;)
<conchuod> Probably need more of a range of features and frequencies etc since they're used to provide clocks to the fabric.
<conchuod> mpfs-ccc.c is a driver for the one we have (in this case, used for 4 instances with two PLLs each)
<conchuod> PF_SoC_RegMap_V1_4/MPFS/ioscb_pll_mss.htm (if you care to download the register map) has the specifics on registers, but clearly it is not the same.
davidlt has joined #fedora-riscv
<Esmil> thanks. yeah, that's very different
<conchuod> Ye. I wasn't suggesting common driver or anything, was just the terminology all seemed the same.
<Esmil> yes
<davidlt> Esmil, I sent you and Heinrich to help out Mark (elfutils, valgrind, etc.) getting Ubuntu Server on VF2
<Esmil> yes, i saw. Heinrich answered already
<davidlt> Esmil, I forgot to mention that Mark already didn't understood the instructions.
<Esmil> ah, well at least now there is a mail thread, where he can answer what's not clear
<davidlt> Esmil, correct. He basically has no experience with SBCs and these instructions ask for way too many things for unknown reason.
<davidlt> Esmil, one more thing. I forgot to tell him to buy UART USB dongle, which makes life harder.
<davidlt> Esmil, he already added riscv64 build (based on vendor's Debian build) to https://builder.sourceware.org/
<davidlt> But toolchain, etc. is too old for what he wants.
<Esmil> yeah
<davidlt> I suggested to go with Ubuntu for now as you support VF2 already. That should give him something stable to work with.
<davidlt> I also connected him to RVI for future dev board offers, etc.
<Esmil> cool. yeah, we don't anything close to what the vender kernel has working, but at least basic mmc, sdcard, ethernet, usb and pci should be working well enough that the ubuntu installer can boot from the sd-card and guide you through installing on the nvme
<davidlt> Yeah, he definitely wants NVMe.
<Esmil> yes
<davidlt> He has been debugging a failing unit test in elfutils on Fedora/RISCV farm, but hopefully they can their CI stuff working.
<davidlt> Maybe that would help with valgrind support landing :)
<Esmil> that would be cool
<davidlt> Yeah, he said they don't really have access to the hardware to test.
<davidlt> Well, we are still failing developers with easy to use infrastructure.
zsun has quit [Quit: Leaving.]
<conchuod> Who is "mark"?
<davidlt> conchuod, Mark Wielaard
<conchuod> Ah
<conchuod> I was just hoping that youd not say mr cto
<conchuod> cos that'd be bad if it was the case
<davidlt> heh :)
fuwei has quit [Ping timeout: 252 seconds]
fuwei has joined #fedora-riscv
fuwei has quit [Remote host closed the connection]
davidlt has quit [Ping timeout: 260 seconds]