Writing Boot Sector Code (2007)(susam.in)
susam.in
Writing Boot Sector Code (2007)
https://susam.in/blog/writing-boot-sector-code/
11 comments
> no one wants to use GNU/AT&T assembler syntax
I am the one who enjoyed using AT&T syntax. It remainded me old-days PDP-11 assembler.
I am the one who enjoyed using AT&T syntax. It remainded me old-days PDP-11 assembler.
This is an obsolete way to do that. In UEFI you don't need to play with assembly, look:
https://www.rodsbooks.com/efi-programming/hello.html
https://www.rodsbooks.com/efi-programming/hello.html
I still don't really understand the necessity of EFI
I agree UEFI is the way to go. Just curious, how do people debug their programs though? Older non-pc systems had really decent debuggers built in.
There are couple ways. You can compile UEFI for QEMU (OVMF package or possibly compile coreboot with Tianocore payload). Another way is just output. UEFI gives you shell, so you can see output and in UEFI it's much easier to deal with this stuff.
If you use coreboot and libpayload it's much easier because it offers you built-in GDB server you can connect to via serial port.
If you use coreboot and libpayload it's much easier because it offers you built-in GDB server you can connect to via serial port.
QEMU and Tianocore works in some cases.
Everyone who has done BIOS work thinks that UEFI is a bloated mess, to put it lightly. UEFI is itself an environment with comparable complexity to an operating system. Linus' posts about it are worth reading:
https://yarchive.net/comp/linux/efi.html
The result should be generation of intermediate files and the final hello.efi program file of about 46KiB on a 64-bit system
That's bigger than the whole MS-DOS 3.2 kernel.
https://yarchive.net/comp/linux/efi.html
The result should be generation of intermediate files and the final hello.efi program file of about 46KiB on a 64-bit system
That's bigger than the whole MS-DOS 3.2 kernel.
Boot sector programming has always seemed like ln of the cooler ways to play with writing lower level code,but am I wrong to assume it won't work on systems with UEFI?
That's correct. UEFI firmware will execute a PE image (the same format that Windows executables use) on a FAT32 file system, and can access UEFI services to execute a kernel.
EDIT: as pointed out by a sibling comment, the UEFI firmware may support a CSM (compatibility support module) that can boot a legacy BIOS loader.
EDIT: as pointed out by a sibling comment, the UEFI firmware may support a CSM (compatibility support module) that can boot a legacy BIOS loader.
It may work with UEFI if it's set to compatibility mode.
That's largely because no one wants to use GNU/AT&T assembler syntax. In the official Intel syntax, the important 4 lines of code would be more like
...and I immediately feel compelled to optimise it to (186+)
Also, especially with newer CPUs and on a laptop, it's a good idea to put a HLT in the infinite loop, like so:
A halt causes the CPU to spend most of the time waiting for an interrupt, instead of spinning in a tight loop and wasting far more power than necessary.