first you need to write a driver for light pen for pc when for touchpads
I’m more concerned about sound than touchpad. But hopefully sometime I should get everything working. Is the process for the network drivers just rewriting them? Is there a good before/after I can look at for a done driver?
What is a driver for light pen?
No, the network drivers are imported with little to no changes. There is usally a compatibility wrapper file (usually called glue.c) to do the interfacing. You can see for yourself in src/add-ons/kernel/drivers/network and compare with the corresponding FreeBSD drivers.
But this can only work for network drivers I think. Not sure if anyone has tried it with something else.
Oh. Maybe this was answered elsewhere, but how to you view the drivers? Do you have to extract them?
If you mean in source form, the answer is no, you’ll need to clone the haiku source code to view them.
if you only want to view and compare you can go here.
network\drivers\kernel\add-ons\src - haiku - Haiku’s main repository (haiku-os.org)
Then go wlan for wifi and ether for cable connected, under the eatch driver we have dev folder where the freebsd files goes
Here you can see the drivers we have HardwareInfo – Haiku (haiku-os.org), I haven’t updated for a while (last time 2019). If you look at the network drives. say “attansic_l2 (ae)” the (ae) are the FreeBSD name for it. It’s a ethernet driver so will be under our ethernet.
here you have the freebsd drivers
freebsd-src/sys/dev at main · freebsd/freebsd-src (github.com)
and you can find the ae name here
Thanks for those links.
Sadly, unless someone uses my disk imaging mod this is true, but not from a limitation of Mac hardware but of Haiku that I cannot solve until Haiku supports being able to load its own images into memory like Linux has the ability to do; with a Linux-based system it’s possible to bless an ESP and boot from it as a Boot Camp drive. Haiku can’t do that which frustrated me out of working on ‘Haiku on Mac’.
These are pretty common for Mac hardware with Haiku sadly (no AirPort/Wifi or audio). Far as with the display, you might be able to set a safe resolution from Haiku’s boot menu and see if you can get it to use that.
I don’t understand how these two things are related…
You can set up an EFI system partition with our bootx64.efi in it and that should work. I don’t know what “blessing” is, is that a Mac specific thing? And how it is related to “load its own images into memory”? If you have an EFI system partition, all you need is the EFI bootloader to run the EFI executable inside that (in our case, the bootloader) and we can take it from there?
Also, do there exist bugreports about this with some detailed technical explanation? Or are you just being frustrated about it but done nothing to help improve the situation in that regard?
Oh yes, I have tried to mess with syslinux, I’ve tried to create custom images and RAM disks, I have tried to recompile Haiku after modifying the boot loader, but I realize what I’ve messed with so far isn’t enough. tbh I’d have to pour more time into figuring out how to do this because I believe Haiku would need to be modified to support booting from a self-contained image to do what I want it to do — and it does not. You should know this because you develop Haiku.
And I have explained before in a thread years ago why this is useful, Haiku requires a BeFS partition in either legacy or EFI mode to run, which a Mac’s firmware cannot see and cannot boot from. Yes, I can create both a BeFS volume and an ESP, but why do I have to be stuck in the past? It’s far easier to have a volume that is natively supported, and persistent Linux distributions support this. The advantages of this are that the Mac can see the volume in its own Startup Chooser, I can boot different revisions, and upgrades and installs are very easy to do, since I don’t need to partition anything beyond making an ESP and having images on top of it.
bless is a command unique to the Mac as part of OS X - 13, it’s roots go back to the classic Mac OS (where either OpenFirmware or dragging Finder and System onto a vintage system folder would bless a drive and make it a startup disk).
But I’ll add with Apple Silicon being the next generation of Macs, my motivation to get this done has honestly dropped…
Well I just don’t understand how any of this works.
syslinux and RAM disks are not supported in Haiku for this purpose and should not be needed. All you need is to start haiku_loader in a way or another, and haiku_loadeer will take care of everything else.
So, you either start it as an EFI executable (or using the old style MBR booting), or, if you have some other way to start bootloaders, you have to port it to that format in some way. We already have various different ports of the bootloader: for EFI, for MBR, for PXE booting, for OpenFirmware in both PPC and SPARC versions. We used to have a version for baremetal ARM too, but now we use the EFI version there.
So, can you provide info on what kind of format is needed for Mac systems? I assume it is not a standard EFI executable then? What is it? An ELF file, a Mach-O executable?
So, can you provide info on what kind of format is needed for Mac systems?
If I understood correctly, he is reporting the fact that you would have to create two partitions for Haiku to boot using the standard MacOS boot loader. That’s because the boot loader doesn’t understand BeFS, thus it would be unable to see the haiku_loader executable in that partition. So you would have to create a FAT partition for the sole purpose of placing haiku_loader there so that it can be started by the Mac Boot Loader and then start haiku itself from the BeFS partition.
That’s not required by other OS as the mac boot loader is able to find the efi loader in supported partition formats and thus boot the OS. So in practice he would need an EFI System Partition only for Haiku.
Does the Macintosh boot loader manage EXT4 to load Linux directly from there? I find that surprising. Does it also do that for XFS, ReiserFS, and whatever other filesystems you may install Linux on?
He mentioned persistent Linux distributions, so I guess the partition booted by mac would be a FAT partition with inside an image that is then mounted as the Linux root? But at this point I’m just speculating
You also need an ESP if you boot macos. I don’t really see the problem?
And to clarify ESP is just a FAT partition that is marked as a boot partition either by flag (old school intel partition) or by type uuid (GPT-partition).
This has changed a few times in the history of mac, so I’m not aware of how it works on all macs and all versions of OSX, but in the past you didn’t need an EFI partition.
While the ESP was present, the BootROM didn’t care about it, because it would look for a
boot.efi file in the blessed disk itself. At a certain point you could freely delete the ESP and the mac would continue to boot.
But I don’t know if that changed because I stopped using multiboot on mac a long time ago, and also I’m sure that on Apple Silicon that has changed. Nowadays I have a Linux VM always running in Parallels within OSX as my development environment and thus I don’t keep a separate bootable Linux install anymore, thus didn’t have to keep up on how boot workflow has evolved on mac.
What do you mean by a blessed disk? What exactly does the command do?
Nothing is preventing the firmware from skipping rhe esp i suppose (network boot is a good example too)
but as long as the esp is usable when present that seems like a fine way to use haiku.
As for the booting method described above
Loading the entire OS needlessly into ram as a ramdisk as a workaround for some boot issue sounds convoluted (also means the OS cant evict uneeded parts from active memory needlessly, don’t really see what the advantage would be)