Amazing! Less than three hours after I posted you have USB working! Is that USB 2.0 and 3.0?
I presume the visionfive 2 HDMI doesn’t support audio yet does it? I’ve got some dirt cheap USB C headphone adapters (“sounds cards”) I’ll have to see if they work with haiku x86 then maybe I can use it on RV for audio? I presume the onboard audio isn’t supported yet?
It is XHCI (USB 3).
It will probably work in the same way as in x86 (with some glitches).
There are an audio jack on the left side. It is not supported yet by Haiku but seems not complicated to support.
So how is performance on this board? is it worth buying?, great work BTW, the speed at which you make progress is impressive, it makes us happy to see it every time.
X512 may correct me if he knows better but the phoronix benchmarks I saw put it in the same ballpark as a RPi 3 in terms of its CPU. This will partly be because all compilers, libraries and apps are optimised for x86 and/or ARM but not RISCV yet.
EDIT
I’m not sure phoronix have benchmarked the visionfive 2 yet so maybe I was thinking of tests they did on the Unmatched. I don’t think there’s a world of difference between the two tho so my comparison could still be good enough. I’m not expecting it to be as fast as my RPi 4 but I’m encouraged by the fact it has an open source mesa GPU driver in the works.
Optimization to riscv maybe be a 10-15% cpu speed. RPi4 prize is now very unsatisfacted, because ARM on RPi4 is fast. Vision Five have a other issures, like m.2 port or UEFI in Uboot. The Power o RiscV is open architeture and software drivers. Maybe a SWOT analise (+ and -) talk you more.
There might also be a lack of developer interest in an ARM port due to ARM being a closed ISA.
The Core of ARM is under licence and it’s cost (high price), many of developer choose a ARM becase is in new technlogy and monetary gain. Majority of Engeeners don’t like RISCV, open project is excelent to open source, not for monetization. An idea of SBC is not a speed.
Many of years be a intel 8051, now when RPi look a light of sun, the era of old intel pass.
tqh summed up the problem very well. It is not so much lack of interest, but lack of time and ever changing hardware. I have over the years bought several ARM devices, and each of them became obsolete and possibly broken before I could even get started on porting Haiku to it. I still own some of them, and maybe I’ll get back to Haiku hacking on at least one (the other is way too old and it would not make sense anymore to get Haiku running there, and the architecture is very strange, 2 CPU cores of which only one has an MMU…)
There is no problem at all with it being a “closed” ISA (what does that even mean? That issue has been solved since at least the 6502 cloning the ISA of the Motorola 6800 but swapping the CPU pins around so it wouldn’t be fully compatible, or the z80 being a clone of the 8080 but renaming the mnemonics in the assembler so people would notice, but lawyers wouldn’t).
There were problems with each machine using an ARM CPU being essentially a completely different architecture, with a different UART to send debug to, a different way to program the framebuffer, and so on. When we started, even the MMU wasn’t standard and was different between various ARM generations.
Recently this is solved by having UEFI for all machines, meaning we can get at least the bootloader running on any machine without any new code. This benefits both RISC-V and ARM, since they have both standardized on UEFI, and as a result, the ARM port has started to make some progress again.
So, TL;DR: it is not a problem of closed ISA, but of lack of architecture standardization for anything but the CPU itself.
Not visionfive 2 but Haiku generally not supports audio over hdmi.
Well, that all depends on the drivers. On modern x86 PCs with Intel graphics, it is not done yet because it requires collaboration between the graphics driver and the sound driver, both of which are rather complicated things designed by Intel. But on other chipset designs, it may be a lot easier.
This probably would be good to post as an official haiku news post. Do not ask me how though…
Just make a pull request to the website, which is hosted on github at GitHub - haiku/website: The Haiku website. (Pull requests are accepted; please file issues at https://dev.haiku-os.org).. There is a “news” section, but it is rarely used nowadays since all developer blogs also get to the homepage. But it’s available.
@X512 are you planning to merge your current progress with the upstream haiku sources? I’m asking because I’m seriously considering getting one of these VisionFive 2 boards (just after getting my next paycheck! 
) for use with haiku (no dual-boot), so I’d like to give it a try.
Thank you very much,
Luca
Some PCI refactor is needed in upstream Haiku to add VisionFive 2 support (multiple domains, separate MSI interrupt controller per domain, resource allocation).
Current VisionFive 2 support code is published here: Commits · X547/haiku · GitHub.
Thank you very much for your reply. So, at least in theory, if I build the visionfive2 branch from your repo, I should get a bootable haiku, right? Is there any special param that I should pass to the configure script? Can you share the build commands you use to build your images?
I know that I’m asking a bit too much infos, please don’t get offended.
Thanks a lot,
Luca
At this point I like to imagine what will happen next, someone will order TSMC to have a SOC printed at 7 nanometers with 256 cores based on RISC-V and another 256 cores based on this GPU and another 256 Neural cores for AI. All based on these Vision Five 2 milestones. It will be a chiplet SOC with lots of ram attached directly to the SOC and just as much extensible ram. it will be a pretty big SOC,bigger than the AMD EPYC processors actually…
oh well it will also need a lot of Watts at full throttle, but who cares … 
And we will have the most powerful HAIKU of all time, and no one will have anything to say about it…
It could actually happen tomorrow itself.
I would say that the revolution has begun.
What would you actually run on a 256 core CPU? The majority of software out there will only utilize 1 core and some of them will utilize a handful. To make a CPU feel faster, single thread performance is pretty much the only thing that matters.
I’m curious what the glteapot fps is on this board.
Moore’s law was replaced by Amdahl’s law. Theoretically up to 4096 cores.
@ x68k
The answer to your question is the scheduler is that it sort of breaks threads on cores. The question for me is memory allocation, because we still operate on 4-16GB of RAM.
You can build software really fast for one. If you have lots of cores but spread over multiple machines you can use icecc to do distributed builds. I never had any luck with distcc but icecc is easy to set up.