0

I wrote a little bootloader in assembly and it uses BIOS interrupts and it works great on my pc. My question is, is there any possibility to make it work on Mac / Apple systems. I know that Apple doesn't use BIOS in that sense and that they are locking lot of things down. However it is possible to use a live ubuntu stick on mac, so might it be possible to run an assembly program from startup on a mac? If yes, do you know any starting points or references of what has been done before?

Thanks a lot!

Improve this question

2 Answers 2

Reset to default
2

My question is, is there any possibility to make it work on Mac / Apple systems.

There's always a possibility. For example, it's possible that someone might port a system emulator (e.g. Bochs, Qemu) to UEFI (so that it looks like a UEFI application) that's capable of emulating a completely different computer that does have BIOS.

In practice, you'll need to write at a new boot loader for UEFI.

Note that you should also assume that UEFI is the first step in a "legacy baggage removal" scheme (and assume that Intel's "no BIOS after 2020, not even just a compatibility module" statement was made because Intel are planning to rip "legacy baggage" out of chipsets, etc; which would prevent firmware written by other people from continuing to support BIOS). For one simple example (that already exists); Apple machines don't have a PS/2 keyboard controller chip and don't have "legacy PS/2 emulation for USB devices" support, and attempting to access the PS/2 keyboard controller chip can cause the computer to lock up.

Mostly; there are a whole pile of assumptions (e.g. about the memory map, and the existence of things like A20 gate, PIC chips, PIT chip, PS/2 keyboard controller, "BIOS compatible" video card ROM, VGA hardware registers, etc) that are either not true for UEFI or not future-proof for UEFI. For this reason you should also audit the OS that the boot loader boots, to identify and eradicate all of the (potentially false) "legacy assumptions" (otherwise, even if you've got a perfectly good boot loader designed for UEFI, the OS will probably fail soon after boot).

Improve this answer
6
  • Excellent, maybe fewer people will think that 16-bit real mode with legacy PC hardware is "closer to the metal" of their modern desktop, and stop targeting that for their toy OS projects. But most of the worst x86-16 SO questions are from people using emu8086 or DOSBOX for school, though, so probably that won't really cut that down. :/ Anyway, still good to hear that we're not stuck with crap like A20 forever!
    – Peter Cordes
    Commented May 3, 2019 at 5:11
  • @PeterCordes: There's definitely some up-sides. Unfortunately, there's also down-sides (e.g. ACPI, Secure Boot) - we're entering an era where the complexity that an unprepared beginner needs to contend with is enough to prevent most beginners from beginning.
    – Brendan
    Commented May 3, 2019 at 5:21
  • I haven't actually written a UEFI application (or a legacy bootloader, but I know how because people ask about them all the damn time on SO), but presumably osdev documentation will evolve to cover UEFI more? As long as vendors make it possible to disable SecureBoot, we should still be ok, right? I see what you're saying to some degree, but most of the bootloader questions on SO are from people that seem to barely understand asm in the first place. They could learn just as well (or better) developing on a virtual environment with a debugger, like BOCHS. Or non-x86 MARS.
    – Peter Cordes
    Commented May 3, 2019 at 5:29
  • Maybe there are a large amount of people that experiment with a toy OS but never need to ask questions on SO because they can debug their own silly mistakes, but many of them would give up if it were more complicated. I guess the gap/leap between purely making BIOS (or UEFI) calls vs. using in/out or MMIO to talk to "hardware" directly gets a lot bigger with this change, because then probably the only stable interface will be UEFI calls? And even if you do assume an AHCI SATA controller or something, you'd need ACPI to find it? That's a fair point, if it's what you meant.
    – Peter Cordes
    Commented May 3, 2019 at 5:35
  • @PeterCordes: People write boot loaders for BIOS in assembly because most compilers don't support real mode well and the calling conventions for BIOS are almost pleasurable for assembly (and horrible for higher level languages). For UEFI it's opposite - the calling conventions (stack alignment requirements, etc) and position independence (and PE32+ file format) make assembly language "less fun" and higher level languages far more viable.
    – Brendan
    Commented May 3, 2019 at 6:12
0

Mac firmware doesn't provide a legacy BIOS mode, AFAIK.

You'd have to rewrite your code as a 32 or 64-bit UEFI application, using UEFI "system calls" instead of the int 0x10 and so on BIOS calls. You can of course still write it in assembly, and it will still run natively on the CPU.

Assembly doesn't just mean 16-bit real mode with BIOS calls.

The BIOS int-whatever interfaces are already obsolete on PCs, too, but PC firmware usually has a backwards-compat mode you can enable that switches the CPU back into real mode and provides those software interfaces. (The firmware itself probably switched to 32 or 64-bit mode during bootup before loading your 512-byte bootloader from disk.)

That's what happens when you run legacy BIOS code on your PC.

According to https://www.ubuntu.com/download/desktop, the regular x86-64 Ubuntu bootable disk images work on PC and Mac, presumably both using UEFI.

Or maybe not, according to http://www.rodsbooks.com/ubuntu-efi/ booting Ubuntu on a Mac normally goes through the Mac firmare Compatibility Support Module (CSM) which provides BIOS emulation on a Mac. (Apparently also useful for some ways of booting Windows, which is why it exists in the first place.) That page seems out of date, though; Windows normally boots with UEFI on modern PCs, too.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.