(NASM) (80x86) Bootloader NEEDS xor ax, ax

Question

I am learning how to make a bootloader from osdev. I\'m using NASM to assemble my code, and a x86 machine to run my bootloader. This is a little piece of code which prints a

Answer 1

Its 2018 and I have stumbled upon this same problem. Micheal's answers and comments seem to be the best solution yet. We don't live in a perfect world and that's just how it is. This is why I wanted to develop a BIOS when I started OS Dev. I hate to run someone else's code in my computer without examining it. But that's just too hard in case of Firmwares and BIOSes. It might even brick your PC if you mess with the BIOS without knowing what you're doing.

Anyway, I have just added this comment in case someone else stumbles upon this same problem later. I would seriously suggest to examine the source code and/or reverse engineer some already available bootloaders like GRUB, Windows Boot Manager, LILO etc. You can also download live USB linux distros for your PC, install it in a flash drive and look at the boot sector code in a Hex Editor and maybe even disassemble it.

This isn't exactly an answer to the question but its worth a mention. To make this more relevant all I can say is that I have reversed GRUB's code, as installed on Kali Linux USB bootable and it starts with a XOR BP, BP instruction.

Answer 2

In theory you wouldn't need a BPB when writing a MBR and not a VBR¹, and the presence of the xor ax, ax instruction wouldn't influence the booting.
You should include a xor bh, bh however (more on Int 10/AH=0Eh)

---

Sadly this is just theory.

Specially for USB devices a BPB is implicitly assumed by some firmware, including the full FDC descriptor (with a valid OS name).
Many thanks to Michael Petch for stressing this out.

Since the introduction of UEFI implementations, particularly the parts dealing with CSM (Compatibility Support Module), i.e. legacy booting, writing a fully supported MBR has became tricky.

The firmware will sometimes try to automatically detect what boot mode to use and since all UEFI devices are also legacy devices per specification, the firmware must rely on some quirk to tell them apart.

My firmware detect a device as "legacy", even when explicitly told so, only when at least one of these is true:

• There is a bootable, non empty, partition in the MBR partition table.
  The starting/ending address, either in CHS or LBA, are not checked at all.
• The first instruction is a xor ax, ax (in either forms: 33 C0 or 31 C0). This is because the first thing most bootloaders do is to set the segment registers to zero through AX.

There may be other "signatures", like a jump at the first bytes, but I haven't tested them (yet).

If the firmware fails to detect the device as legacy and it is not a UEFI compliant device, it will be skipped.

---

You can use the xor ax, ax (in which case I suggest using of db 33h, 0c0h and a comment for documentation) or by adding a dummy partition entry, as shown below.

BITS 16
ORG 7c00h                       ;Soon or later you'll need this

 xor bh, bh
 mov ah, 0x0E
 mov al, 0x41
 int 0x10

_loop:
 hlt                            ;Be eco-friendly
jmp _loop

 ;Pad to the first PTE (Partition Table Entry), it is at 1beh
 TIMES 01beh-($-$$) db 00h

 dd 80h                         ;Bootable partition at CHS 0:0:0 (Which is illegal but not checked)
 db 01h                         ;Non empty partition (Type 1 is MS-DOS 2.0 FAT)

 ;Pad to the end of the sector minus 2
 TIMES 510-($-$$) db 00h
 dw 0aa55h                      ;Signature

---

¹ According to the parameters of the dd command.