I think that at the beginning you should make an ssh port (which I wrote earlier), a terminal and a bash port under riscv. I don’t know if it was the hpk version or as a recipe in Haiku Ports. I mayby pass new test of other haiku software.
I see VisionFive-2 is on sale at AmeriDroid for 15% off! No coupon code needed according to the email! Was the GPU the holdup for it or were there other holdups?
Edit
Never mind. It was an email-only sale.
What about using a Logitech USB mouse/keyboard combo dongle? Only one USB port needs to be used to control both items.
I got built-in Ethernet working. For now it may be slow because interrupts are not implemented yet and pooling with snooze() is used.
36 Likes
This is good news, thanks for the great work you are doing
2 Likes
Network speed is significantly improved after implementing interrupts instead of pooling. Now CPU usage in kernel receive thread is quire high, I suppose overhead of memcpy become significant and it would be nice to implement zero-copy packet handling.
31 Likes
It is frantic !.. better news than a new Risc-V board HW post here ;-))
2 Likes
Why is networking so different in riscv? can’t we just reuse what we already have on x86?
Its a totally different platform - think about that what written earlier about HW devices. The PCI in itself not so major role in device detection.
Also although many operating system services in theory can be resolved - as this processor were designed today … they could select a different HW/SW method what existed for x86(_64) architecture.
They could built totally different design.
Seems it is well documented, as X512 and kallisti5 and some other developers could develop Haiku to once have more stable and complete Haiku as supported platforms and also the programs as well.
Think about future … when a buildmaster service would exist for Risc-V version of Haiku as well … then native and ported apps can be installed once they modified / compiled / fixed for Risc-V as well.
The reliable network connection is a stable base to use a network service or reach remote server connection.
Some of the high CPU usage may be due to checksum validation. We could probably improve here by switching to checksum offloading… a lot of the BSD drivers support this, but we don’t use it there either. (If we don’t have a ticket about this, we should.)
2 Likes
Is there any API in Haiku network stack for checksum offloading? If so, I can try to use it in my dwmac driver.
1 Like
Not yet. I added a ticket for it: #18744 (Network packet checksum offloading) – Haiku
I have a few ideas about how we’d do it, though.
4 Likes
How about mentioning these ideas on the ticket?
1 Like
Thanks a ton for the build instructions! I went through a whole adventure this weekend trying to build the latest code so I could try Haiku on my VF2, and things have changed a bit. I’m gonna share what worked for me here:
git clone https://review.haiku-os.org/buildtools
git clone https://review.haiku-os.org/haiku
cd haiku
git remote add X547 https://github.com/X547/haiku.git
git fetch X547
git checkout device_manager2
git checkout origin/master -- build/jam/repositories/HaikuPorts/riscv64
mkdir generated.riscv64; cd generated.riscv64
../configure --use-gcc-pipe -j8 --cross-tools-source ../../buildtools --build-cross-tools riscv64
jam -j8 -q @minimum-mmc
Haven’t had a chance to try booting the image on my VF2 yet, but it generated a 348MB haiku-mmc.image file as output, so hopefully maybe it kinda worked?
Totally booted up properly once I updated the VF2 firmware and reset the bootloader env.
14 Likes
What, exactly, did you need to do, in what order, to do this?
I was told on IRC to avoid VF2 firmware releases newer than v3.1.5, so I went to the v3.1.5 release page and downloaded the sdcard.img (which I wrote to a microSD card with balena etcher) as well as the u-boot-spl.bin.normal.out and visionfive2_fw_payload.img files.
Next, I booted the VF2 with the newly-written microSD card inserted and logged in over SSH as root. I think the password was starfive? Once logged in, I ran cat /proc/mtd to make sure that I saw this output:
dev: size erasesize name
mtd0: 00040000 00001000 "spl"
mtd1: 00300000 00001000 "uboot"
mtd2: 00100000 00001000 "data"
Once I confirmed that, I copied the u-boot-spl.bin.normal.out and visionfive2_fw_payload.img files to the VF2 by using wget (because scp didn’t work for some reason). And I flashed them to the VF2 using the flashcp command and saw the following output:
# flashcp -v u-boot-spl.bin.normal.out /dev/mtd0
Erasing blocks: 33/33 (100%)
Writing data: 129k/129k (100%)
Verifying data: 129k/129k (100%)
# flashcp -v visionfive2_fw_payload.img /dev/mtd1
Erasing blocks: 722/722 (100%)
Writing data: 2887k/2887k (100%)
Verifying data: 2887k/2887k (100%)
Following this, I shut down the system with shutdown -h now and removed the USB-C power plug. That’s the firmware updated.
Then, to reset the bootloader environment: I connected a USB-serial from a USB port on my Mac to pins 6,8,10 on the VF2 40-pin GPIO, as outlined in the VF2 docs, and used screen on my Mac to connect to the USB serial with screen /dev/cu.usbserial-6124101 115200 (your USB serial device path will probably be different), and plugged the USB-C power back into the VF2.
I saw a message saying to press a key to interrupt the bootloader, so I did that, and then I typed in the commands from @danboid’s other comment:
env default -a -f
setenv boot_targets "mmc0 nvme0 dhcp"
setenv bootcmd_nvme0 "devnum=0; run nvme_boot"
saveenv
This results in a VF2 that can boot Linux successfully from the SD card or Haiku successfully from NVME, if you use Etcher to write the Haiku image to an NVME drive via USB adapter or something. Unfortunately, I haven’t been able to get Haiku to boot from SD card yet; it panics during boot, something about “unable to find boot filesystem” or similar. I haven’t tried digging into that yet since NVME booting is working for me. Although I’m very much looking forward to having multiple USB devices work at the same time so that I can try actually using the system instead of just booting it.
12 Likes
I managed to get keyboard and mouse to work at the same time by rewriting XHCI ring buffer management logic so it now use the same memory for ring buffer itself and transfer descriptor TRBs in it. I am not sure why it fixed the problem, but now it working.
Note that code is not yet fully adapted to new ring buffer management, so expect strange things happening on unplug etc…
14 Likes
Very exciting news! I’m pulling and rebuilding now.
EDIT: I built the latest @nightly-mmc from the device_manager2 branch and then flashed the haiku-mmc.image to an NVME disk with Etcher, waited until the system booted, plugged in my USB keyboard and mouse, and I can confirm they both worked at the same time. Hooray! And the USB keyboard doesn’t drop any keys when running on the real hardware, unlike RVVM (which seems to drop like half my keyboard input for some reason).
6 Likes
I don’t know why it would be different either, but after some inspection of the code, I made a guess as to what might be going wrong and did a refactor that might affect things (without actually rewriting all the management logic, so things should still mostly work as expected elsewhere): https://review.haiku-os.org/c/haiku/+/7343
8 Likes
This is a fix the x86 haiku has needed for a long time.
1 Like