As I don’t have a RiscV board of any type, and I’ve seen X512 post images of Haiku booting on TinyEMU/QEMU, I’d like to know the steps required to do likewise. I can do it from within Haiku or Windows, whichever provides the best experience, performance-wise.
5 Likes
I’d love to know that too. Thank you for asking.
I’m hoping someone can tell me what to do, because I have spent HOURS scouring websites and pages, trying to figure stuff out, to little avail.
I’ve tried using QtEMU in Windows and it seems to do nothing. There is NO option for a RiscV CPU/system anywhere. I’ve tried following this page:
To no avail. The best I can get is a black screen window with a “no video driver initialized” message or something in the middle. Well, that makes sense since ati-vga doesn’t exist on most/all RiscV boards.
Can someone just help out and give a step-by-step set of instructions on how to boot a RiscV Haiku .image via QEMU or otherwise, because nothing I’m doing is getting me anywhere.
The fact that real hardware doesn’t have ati-vga does not matter. Qemu allows to create whatever combination of hardware you want, and Haiku include the needed drivers, so that will work.
If nothing happens, it possibly means that the RISC-V port of Haiku is currently broken. I don’t see the point to use it if you’re going to run it in a VM, anyways, that will just result in a slower emulation (the virtual machine can’t use any cpu acceleration) and besides that it will just be the same Haiku you already know, possibly with less software and more bugs.
The webpage also tells you how to switch between the serial port (where you can see the boot log) and the ati-vga display (where you can see the desktop). Maybe you can’t see the bootscreen on RISC-V yet (it depends on the exact version of the bootloader). And there is also a warning that there are bugs and it may take multiple tries to get to the desktop.
Since I have NO clue how to proceed… I’m assuming that no one else is interested in helping me in this “Trivial Pursuit”?
Why do you assume it´s a matter of being interested? I rather suspect it´s because most of us have no clue about running the RiscV version of Haiku (at least I don´t). @X512 , who´s the main (only?) developer of the RiscV port is generally very helpful. People have real lives too, give him a bit of time. Or see if you can catch him on IRC and ask him there.
A few months ago I was able to boot up Haiku on qemu-system-riscv64 but now it seems broken unfortunately. Getting stalled at the jump to kernel:
SATP: 0x80000000000fbe80
Calling ExitBootServices. So long, EFI!
arch_enter_kernel(satp: 0x80000000000fbe80, kernelArgs: 0xff71e8a8, kernelEntry: 0xffffffc0020970d4, sp: 0xffffffc002827000)
I was using a command line similar to this:
qemu-system-riscv64 -kernel u-boot.bin -M virt -m 2048 \
-device virtio-blk-device,drive=x0,bus=virtio-mmio-bus.0 \
-drive file=haiku-mmc.image,if=none,format=raw,id=x0 \
-device usb-ehci,id=ehci -device usb-tablet -device usb-kbd \
-device ramfb -serial stdio
Tried it on Fedora 39 with qemu-8.0.5 and qemu-8.1.1, no success. (As I remember it used to work on the same setup in September. What could have changed? Not so much commits in the bootloader or the kernel since then.)
never mind the difference between ramfb vs ati-vga we didn’t even get to the point when the accelerant would be able to do any mode setting.
3 Likes
I refer to “interest” based on OTHER people (other than X512) who might be able to help break down the steps and help me get it working (figuring I was doing something wrong or interpreted the instruction wrong), who I assume tried it out themselves at some point. But if it’s broken, it’s broken. Just a matter of someone gluing the pieces back together again… whoever that might be.
If you only knew the “why” of my persistence. But, in time, it will be made known (if it can be)… A RISC-V VM environment is not the end-all-be-all, but rather a convenient stepping stone. It’s always a stepping stone, in every case (one develops the OS in a virtual environment until it can run in actual hardware, unless the actual hardware no longer exists or is too hard to come by).
“Don’t go jumping in after alligators” is my new motto. Don’t try to start (or win) an argument that will ultimately fail. I’ve tried in the past and failed every time. Why? Because too many people in positions of power and authority (or greater knowledge) assume a lesser person could not POSSIBLY know what they’re talking about. Ideas too radical. A waste of time. Etc. I’m sure what Jean-Louis-Gassee was working on was laughed at… until they saw what it could actually do. Sometimes it’s simply better to just work on the sidelines… or hope to find like-minded people. Money definitely helps, but money isn’t everything, except to those who make it such. Hint but never tell. That way, if it never comes to pass (or it fails), you’re not derided as a fool for even having tried. And, if it succeeds, you amaze the rest, who will wonder how you were able to pull it off.
Any chance of figuring out what the last working RISC-V Haiku revision/QEMU version was? I wouldn’t have a clue, but someone else might. I’m assuming QEMU is QEMU on any platform, correct? Windows, macOS, Haiku, Linux, etc.
Hmm… interesting. In the RiscV section, Revision 57001 is only 62Mbytes. Yet Revision 57100 is over 300Mbytes. Assuming Rev 57001 is even a complete/working build, a ton of stuff must have been left out. I’m going to try several revisions leading up to September 2023 in hopes one of them works. Worth a shot.
Also, Revision 57197 is the last, before it jumps to Revision 57322. I wonder why such a long pause in Revisions. Did the breakage occur after that jump (update: I’m thinking potentially so, because Rev 57322 was committed in October)? Of course, even so, I have to wonder… why produce non-working revisions, to download? Or, do they work, but only on specific emulated/hardware setups? And, if so, which one(s)? I’m hoping someone has an answer, if that’s the case. 
Update: Ok, I ran Rev 57001 and got a LOT more than before (which was nothing)… whole streams of text on the Windows 11 Powershell Terminal… that I finally realized was OpenSBI and then Haiku’s boot loader! After everything… it ended up telling me it couldn’t initialize the virtual screen configuration. Apparently no file or directory for it?
Oddly enough, I think it saw my Ryzen 7 laptop’s Radeon graphics (something about Radeon HD)… but upon trying to get ATI started, it found no supported devices.
Any idea how close I might be to seeing the desktop?
!!!UPDATE!!! Houston, we have liftoff!!! A Haiku desktop!!! I was simply missing -device ati-vga in the command line!
3 Likes
I’ve now decided to build Haiku RiscV from source…
I’ve downloaded the build tools and the source code… but I want to build a specific revision of Haiku. How do I go about doing that?
Ok, that’s all I need to know, that you have a later, more useful goal in mind 
Have fun in your risc-v hacking journey then!
I just wanted to check that to not let you waste time on running Haiku on RISC-V and finding out that, well, it’s just Haiku.
Yes, there was often breakage and there may be more. It’s still very early days. We had some problems coordonating the updates to various packages as there wasn’t an haikuports builder yet (I think there still isn’t) for RISC-V. So, all packages have to be built manually.
It may be a good idea to:
- include that info in the webpage about risc-v
- report a bug if this version worked in qemu, but newer ones don’t
In your haiku source directory, before you start building anything:
git checkout hrev570001
If it is old enough, you may have to find a version of the buildtools from the same time (going to the buildtools directory and using git checkout btrevxxxxx to get it)
THANK YOU! Been spending hours trying to figure that out and came very close to figuring it was something that simple, but couldn’t find a page that said it THAT simply!
Now, does “btrevxxxxx” stand for “build tools revxxxxx”?
Update: I tried building hrev57197 (which is a usable RISCV Haiku image in QEMU, from the Haiku site), and it failed. Also, I noticed a ton of /x86_64/ directory references during the build . Why? I thought maybe I had an older version of the build tools, so I did a “git checkout btrev57197” and it said there was nothing there. So I tried “git checkout bthrev57197” (thinking maybe the name was wrong) and it said the same thing. So the build tools must be current. But why is it failing to build, if there is a working nightlies copy on the Haiku website? How did THEY make a working copy, but I can’t?
Yes.
The numbering from the buildtools is independant from the numbering for Haiku itself. You can see the numbers at https://cgit.haiku-os.org/haiku/log/ and https://cgit.haiku-os.org/buildtools/log/
Unfortunately there is no direct way to find the matching btrev for a given hrev. So, you have to use these two pages and try to match the dates. This is annoying and stupid, there would be an easy way to fix it (for people who know git: we should have the buildtools as a submodule of the haku git), but when we proposed to set this up, someone said it was a bad idea for some reason, and we still have no solution. Fortunately, the buildtools do not change as often as Haiku, so it should not be too difficult to find the right version.
Can you share the command lines you used? To make sure it is all correct.
Are you building from inside your RISC-V VM or from some other system? In the latter case, what system is it?
My guess (but without any commands or logs, it is just a guess) is that the Haiku build starts by building tools that run on the host (the machine you are compiling on) and then uses these tools to build Haiku for the target (in your case, a RISC-V system). This allows us to use our own tools (things like xres, rc, mimeset, and many others) even when building from Linux or some other non-Haiku system. And, of course, these use the CPU of the host machine, so, if you are building on a PC, they will be built for x86_64.
1 Like
ah yes, hrev57197 should be the last one before the update to gcc-13.1 toolchain
some more testing gives me the following results:
- hrev57197: successful boot to desktop
- hrev57322: rather verbose page table dump, then is stalls when trying to jump to the kernel
- hrev57453: stalls when trying to jump to the kernel
- hrev57453+2: after reverting hrev57299 and hrev57298, successful boot to desktop
This gives us a hint: there might be something wrong with the initial page table setup in the boot loader.
8 Likes
Thanks on spending time on testing.
5 Likes
Ok, I’m assuming, if I don’t do a “git checkout” on the build tools, then the version I’m working with is the latest, correct? And, probably doesn’t work, to build Haiku (RISCV) hrev57197 properly, right? Thus, the version that directly precedes Haiku (RISCV) hrev57197 is btrev43203, which is dated 2023/6/20. And the very next btrev is the day AFTER (2023/8/5) the last successful build of Haiku (RISCV) hrev57197 (2023/8/4), so logically, it was being built with the prior revision of the build tools, because you can’t build older revisions of Haiku with newer tools you haven’t created yet.
That seems right.
David Karoly found a bug and fixed it, the fix was just merged. So you may be able to build and use the latest version now. That will be simpler than building older ones
You can also check the next nightly build and see if that works again.
1 Like
Part of this adventure is the learning process. Doing something you didn’t know how to before. Figuring out how to fix something that was broken before. Learning new things, different things, is what life is all about. This is far from just getting to use Haiku on a different/new platform. Haiku is Haiku on EVERY platform. But, why do we choose one platform over another, to run Haiku? There must be a reason, or else we’re just “spinning teapots”, so to speak.
Update: Ok, now I’m getting mad. I’ve downloaded the buildtools. I checked out the btrev just prior to the day after the last working build of Haiku (RiscV). And now, the tools won’t build! So, how on earth did anyone create the Haiku (RiscV) hrev57197 image?