It would be great to have a “reporting software tool” to submit correct/detailed hardware configurations tested…
(I do also believe that firmwares - mobo, gpu, etc - versions are relevant for compatibility)
Here are some - maybe inspiring - hardware reporting tools:
I totally agree that something like this is definitely needed in the next release! Maybe even a link in the About box to a hardware page? I’d even be willing to manage any hardware submissions like I’m doing with the haiku-computer-list project. But in any case, I do think Haiku needs a unified hardware effort so that people can easily find their hardware of choice.
The sad part is that I would like to see Haiku on the RPi, but I don’t have any low-level coding skills (at present, pretty much everything I can do is applications or UX/UI level stuff and scripting).
For now, my thought is to have an image/distro of BSD or Gnu/Linux boot into a Haiku VM directly (kind of like a way to use them like a rocket booster) and run Haiku on the Raspberry Pi that way until the port is solid enough to have a working desktop.
I didn’t have much skills when I started contributing to Haiku as a 1st year computer science student, either. I would say with enough time and dedication, and the help from other Haiku contributors, everything is possible.
The current issues with the ARM port aren’t even related to low level hardware hacking: it’s a problem in the linker or linker scripts. It sure would take some time reading about position-independant code, linker relocations, etc. “Low-level” is not black magic. You can jump straight into it if you have the motivation, or just enter a rabbit hole when trying to write an app and get deeper… and deeper… You’ll probably get there eventually
Likewise, my current work on the SPARC port is mostly copypasting files from upstream glibc and trying to get them to compile. Nothing hard about that, it’s just long and boring.
This one reason I’m getting into AVR programming. Hardware level programming sounds daunting, but it just requires a different way of looking at things. MCU programming seems to be a relatively simple way of getting into the hardware coding mindset.
Even running native on the Pi would already be quite slow (even if it’s Haiku).
If you want a lightweight OS for the Pi, I’d say RiscOS is a more reasonable and already available choice.
I can definitely second this suggestion to use RISC OS. Especially now that the open side of it is now free (Apache licensed). I do run RISC OS Pi on one RPi I have, and admire it’s lightweight-ness and speed. But… it does have limits; afaik, there’s no Bluetooth or Wifi support for it, and the best browser on it (again, afaik) seems to be NetSurf. I would like to really get more into ROOL and really learn about it, but imho, it would appear a Gnu/Linux or a BSD would be the temporary way to go (at least for the idea I have) until the ARM port of Haiku totally works.
Thank you kindly for the encouragement. I really can’t promise anything, but I might at least take a look at the code to see what I can learn (or maybe do). The best thing about computers is that one is never done learning with them, and I know I have much more to learn, much I don’t know, and that if I did know more, I could be of some use.
For now, I at least hope my hardware list effort is helping somewhat. And I still do think about putting my ideas I’d proposed for Beta 1 out there into a concept image or distro one of these days for the community to look it over and provide tips on it, but haven’t gotten around to actually getting that done yet…
I’d often thought the same thing to myself – but as we type, a port of Windows is now on the Pi, for crying out loud! If devout Windowers are so motivated to “plant their flag” on there, I’d like to try to get some yellow tabbed influence in myself.
And as for the question, the RPi will let me run a virtual machine in it, but the problem is acceleration. In other words, it would boot directly up to qemu with Haiku in it, but without something like VT-x or AMD-V, yes, Haiku would definitely be painfully slow. I did read on Medium where a guy did manage to add acceleration support to the RPi 2, so that may help.
But to me, even if it did start as a proof-of-concept with no acceleration, or if a kvm hack was needed, I think it’d be worth a go to try.
Version: Haiku nightly build (hrev52989); 64bit
Rating: good
Startup media: usb and then installed on HD
Started with: Legacy and EFI.
Boot options: disable acpi
CPU: Intel Core m5-6Y57
USB: working (tested mouse and flash drives)
Memory: 8GB
No SD card reader
Wireless: Intel 8260 (Haiku detects as idualwifi7260) mostly stable (randomly get reprompted for wifi password on bootup)
HD: Samsung SSD
Graphics: Intel HD Graphics 515 (working in VESA mode only )
Powerstatus won’t run (in window or in deskbar) so i have no idea how much battery i have left (that may be a problem lol)
Webcam not detected
touch screen not working (is this even supported?)
hmm well this touch screen doesn’t respond to my finger at all.
it won’t launch. When i click PowerStatus the dialog box asks if I want to run in a window or install in deskbar. It doesn’t matter which one I click… that dialog box disappears and nothing else happens. it doesn’t go into the deskbar and it doesn’t open in a window.
And to submit new entries , here’s a link to the add hardware form (or you can add in details manually per the template in the top post).
Also, my apologies for interrupting the discussion @waddlesplash and @kasmith. I just wanted to copy the latest h/w updates to the thread for anyone following it on the forum…
LOL, I see now that you disabled ACPI in the bootloader. Well, no wonder PowerStatus exits immediately; ACPI is how it gets information about attached batteries!
Why do you have ACPI disabled? Does it cause problems on your hardware?
well that makes sense. I wasn’t thinking about the relationship, but it’s quite obvious.
When I do not disable this I can’t boot. I get a kernel debug after the 3rd icon lights up.
I really can’t promise anything, but I might at least take a look at the code to see what I can learn (or maybe do). The best thing about computers is that one is never done learning with them, and I know I have much more to learn, much I don’t know, and that if I did know more, I could be of some use.
)