<davidlt[m]>
If I need a physical machine I just pull a board out of the farm, use a new NVMe.
<rwmjones>
I wonder if those are rogue processes, they don't appear to correspond to any build
<davidlt[m]>
Once I am done, just pop in the old one and let it back into the farm.
<rwmjones>
yup
<davidlt[m]>
Yeah, looking from the time.
<rwmjones>
I really should get the VF2 working, all the hardware is in place
<davidlt[m]>
If you use QEMU, you must use QEMU 8.0.0.
<rwmjones>
I was planning to use their weirdo kernel + Fedora userspace
<davidlt[m]>
Yeah, you can do that. Kernel v6.4 has minimal bits to boot (at 1.0GHz).
<davidlt[m]>
I think Ubuntu has an image for VF2 too now, but aren't widely marketing it (lacks some things).
<davidlt[m]>
I think that's probably 6.2 + whatever was merged in 6.3 and upcoming 6.4.
<davidlt[m]>
That would mean no PCIe, USB, etc.
<davidlt[m]>
I heard (cannot confirm) that upstream stuff already "feels" more stable than vendor kernel.
<thefossguy>
<davidlt[m]> "I think Ubuntu has an image..." <- USB and the 100Mbit PHY doesn't work because it loads the dtb for the newer board variant
<thefossguy>
That's what I have heard though, both of my boards are using the newer v1.3B
<davidlt[m]>
I think this is being discussed on the mailing list.
<davidlt[m]>
1.3B will be default IIRC from further discussions.
<thefossguy>
What I meant to say is this:
<thefossguy>
The DTS support for both hardware revisions is already in Linux. And since uboot (though "universal") is still compiled targeting an individual board, each board will have its own *minimal* DTB hard-wried into uboot. Now, since uboot already knows what board it is running on, it can just pass the DTB name as a parameter to GRUB/Linux and the rest could be handled by GRUB/Linux.
<thefossguy>
No need to actually patch the DTB, neither in the bootloader nor in Linux.
<davidlt[m]>
Patching would be done <1.3B.
<thefossguy>
There are quite a lot of boards with revision 1.2A
<davidlt[m]>
Majority of sales will be 1.3B I assume, thus it's a good choice for default. Patch for 1.2.
<thefossguy>
Agreed with that
<davidlt[m]>
It only works for EXTLINUX what you described.
<davidlt[m]>
But not exactly, because it's a single board and there aren't much to patch.
<davidlt[m]>
Ah, in Linux they actually have two DTS.
<davidlt[m]>
That's fine.
<davidlt[m]>
What they should do is to change fdtfile value based on EEPROM results.
<thefossguy>
Looking at their kickstarter, I see 333 backers for 1.2A (4gb) and 737 backers for 1.2A (8gb). Looking at the official numbers, this is higher in number than 1.3B; Though that's just once source. I assume third party sellers are selling the 1.3B revision.
<davidlt[m]>
Well KS was before the general sale.
<thefossguy>
davidlt[m]: Yup, that's why i said about passing in the DTB name as a parameter and the bootloader/kernel would handle the rest.
<thefossguy>
davidlt[m]: That's how I got it though :D
<davidlt[m]>
Yeah, I just wanted to avoid anything non-general availability.
<davidlt[m]>
I am still running non-production Unmatched :)
<thefossguy>
davidlt[m]: Confirming: Does what I mentioned still apply only to extlinux?
<davidlt[m]>
Yes
<thefossguy>
How has that been?
<davidlt[m]>
A bit painful sometimes, it has one annoying PCB errata.
<thefossguy>
The reset bug?
<davidlt[m]>
and a slightly different PMIC
<davidlt[m]>
If serial console (micro USB) is reconnected the board basically hangs.
<davidlt[m]>
Also doesn't boot if microUSB is not connected.
<thefossguy>
minor but serious since it is a dev board and serial is crutial
<davidlt[m]>
Yeah. If I forget about it while compiling something for hours it makes me a little angry :D
<thefossguy>
XD
zsun has joined #fedora-riscv
zsun has quit [Quit: Leaving.]
zsun has joined #fedora-riscv
esv_ has joined #fedora-riscv
esv has quit [Ping timeout: 240 seconds]
<davidlt[m]>
rwmjones: are you getting Sipeed board?
<rwmjones>
davidlt[m]: errr, not the new one
<rwmjones>
I have one of the ancient ones
<rwmjones>
does it do anything particular different from VF2/etc?
<davidlt[m]>
The new one has the best perf so far.
<davidlt[m]>
It's the 1st board with OoO cores. The benchmarks (from vendor) claims ~2x perf increase version VF2.
<rwmjones>
is it still a big mess of private extensions? I think they completely switched microarch (to andes?)
<davidlt[m]>
Also you get 16GB of RAM (also faster compared to VF2).
<davidlt[m]>
Nah, it's TH1520. That is T-HEAD (Alibaba).
<rwmjones>
I may be only vaguely remembering the details
<rwmjones>
ah ok
<davidlt[m]>
This one has tons of THEAD (vendor) extensions, that are yet to be hooked into glibc (most likely will be0>
<davidlt[m]>
So this one will most likely gonna gain extra performance with time.
<davidlt[m]>
And it costs the same as VF2 IIRC.
<davidlt[m]>
Sadly you don't get PCIe, SD card and maybe eMMC.
<davidlt[m]>
USB + NVMe combo is the best solution here.
<rwmjones>
ugh
<rwmjones>
NVMe is where a good deal of the performance comes from in practice
<davidlt[m]>
No upstream support, but if you need a developer machines, that's best perf and best value option.
<rwmjones>
I mean, as in directly wired to PCIe
<davidlt[m]>
Yeah, IIUC, 64-core C920 (2nd gen OoO?) dev kits might be available for order/pre-order next month.
<rwmjones>
ok, for now I'm going to concentrate on making the VF2 work
<rwmjones>
& fixing dnf5, it's taking ages to build
<davidlt[m]>
Welcome to the party :D
<davidlt[m]>
That's way I work on gazillion of stuff at once.
<davidlt[m]>
"minutes per package" should be a matric..
<davidlt[m]>
*metric
<davidlt[m]>
Jeff approved a patch for GCC to solve sub-word atomic nonsense.
<davidlt[m]>
So that's going to GCC 14, and I wonder if that will land in a special GCC 13 branch for riscv.
<davidlt[m]>
A lot of vendors plan to base whatever they have on GCC 13, thus decision was made to cook a special perf + fixes branch for GCC 13 + riscv64.
<davidlt[m]>
I am thinking of pulling patches from it to our GCC build.
<davidlt[m]>
I didn't check, but from emails I get impression hwprobe syscall landed in 6.4.
<davidlt[m]>
VRULL is suggesting an additional (simpler) interface that depends on isa-string and uses AT_BASE_PLATFORM (aux vector).
<davidlt[m]>
One of the patches is to patch in xthead_ extensions.
<davidlt[m]>
I assume optimized functions will start showing up for THEAD stuff this year too.
<davidlt[m]>
It would be silly not to wire those up at least in glibc.
zsun has quit [Quit: Leaving.]
esv_ is now known as esv
<rwmjones>
davidlt[m]: got a link to that gcc patch or issue?