Progress on running Haiku on VisionFive 2

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

Do you experience similar problems (not working USB keyboard/mouse) for x86?

iirc, the ring bus was a large portion of the problem with getting DVC webcam working on x86 sometime ago.

1 Like

Syobon Action game (something like Super Mario Bros., but with a lot of traps).

18 Likes

The game runns on a VisionFive?

I posted it in VisionFive 2 thread, so yes.

8 Likes

Build: HAIKU_REVISION=“hrev57525” jam -j8 -q @nightly-mmc
Firmware: VisionFive2 Software v3.1.5
Audio - :checkered_flag: driver port needed.
Ethernet - :white_check_mark:
USB - :white_check_mark: PC-compatible keyboard / mouse working through USB hub.
Video - :white_check_mark: Framebuffer driver used.
Wireless - :white_check_mark:
BT - :checkered_flag: driver port needed.

X512 - :fire: Hot stuff!

9 Likes

Is the framebuffer too slow for the video? Is a “better” (img_gpu) driver coming?

Continuing the discussion from Progress on running Haiku on VisionFive 2:

Original goal stated was: “boot into Haiku desktop without writing dedicated video drivers.”…

As for the IMG BXE-4-32 MC1 GPU driver, not yet. There is a new graphics stack in development so await any further news from @X512.

1 Like

So, I ordered a Milk-V Mars Compute Module a few weeks ago, which takes the same JH7110 SoC from the VisionFive2 and drops it on a Raspberry Pi CM4-compatible PCB. After it arrived today, I installed it into a Waveshare CM4 carrier board, and I was able to get X512’s device_manager2 branch of Haiku to boot… kinda. Unfortunately, the revision of u-boot that comes with the Mars CM is newer than VF2’s v3.1.5, and u-boot shuts off the framebuffer once we exit the bootloader. But based on output from the serial console, it looks like the kernel boots successfully and nothing is panicking or crashing, so that’s pretty cool.

I tried downgrading the u-boot and SPL to the files from VF2’s v3.1.5, but that was a big mistake. v3.1.5 doesn’t seem to know how to find the SD card or the NVME disk on the Mars CM, so I don’t recommend trying to downgrade, as restoring back to a u-boot with working SD and NVME might be a challenge. (I had to resort to TFTP to restore mine.)

10 Likes

It should be possible to patch u-boot and make our own custom build to remove this de-initialization? Do they provide the sources for it somewhere?

1 Like

@X512 says in this GitHub issue that the bootloader-exiting-closes-framebuffer problem was caused by this specific commit to starfive’s u-boot repo.

But the u-boot that’s being used on the Mars CM specifically is from GitHub - milkv-mars/mars-buildroot-sdk: Milk-V Mars Official buildroot SDK (from the dev-mars-cm-sdcard branch for the variant of the Mars CM I have). So I guess I’ll have to revert the upstream u-boot commit in this mars-buildroot-sdk repo and try rebuilding and see how that goes.

Looks like it kinda works! The USB1 USB2 ports on the CM4 carrier board aren’t working, though. With that commit reverted in u-boot, I can actually boot all the way to the desktop, although without USB ports I can’t really do anything there at the moment. Still, pretty cool! I can try to upload the u-boot-spl.bin.normal.out and visionfive2_fw_payload.img files somewhere if anybody else wants to try booting Haiku with this setup.

8 Likes

Sounds like that patch didn’t intentionally disable the frame buffer though but was an attempt to make it work? wierd.

I’ll note that I found a user with an initialization boot up to desktop issue using the newer firmware in which the devs mentioned a fix is in place.

  • VF2 firmware 5.10.3+

Could see if this resolves the newer firmware issues with Haiku…

2 Likes