Live data from Hacker News

Writing a BIOS bootloader for 64-bit mode from scratch

thasso.xyz

61–70 of 82 posts

Re: Writing a BIOS bootloader for 64-bit mode from scratch

#61

The most unnecessarily complicated thing in this article to me is the Makefile and linker script. NASM supports generating flat binary output, but apparently using it would be too "hacky"?

you are totally right.

Later on, make files and linker scripts are an important headache. but when generating flat binary, just generate flat binary! No need to bloat it.

My OS used to have a file called make.sh to tease at this :D Now i am using a 'fileformat' and other fancy things and alas -fbin and --oformat=binary are but fleeting memories. I tried a long time to write separate data c files and code c files, dump it out to binary, and then building some monstrosity from there but it gets really difficult to link&load etc. xD --- better to just use the ELFs or PEs! I suppose that is litteraly what they do for u ;P

Re: Writing a BIOS bootloader for 64-bit mode from scratch

#62

The most unnecessarily complicated thing in this article to me is the Makefile and linker script. NASM supports generating flat binary output, but apparently using it would be too "hacky"?

I find linker scripts much easier to read and reason about than flat nasm but that's just me. Especially with multiple source files.

From how I view linker scripts:

U can use a linker script to create file layout. If you want a flat binary file... u dont want a file layout. So linkerscript is really useless for a flat binary blob. Even if you make it with multiple files. It'd be just the same as saying: cat blob1 blob2 blob2 > finalyblob.

If you'd say have multiple blobs, and use linker directives to align them, the position dependent code within the assembled files will be wrong, unless you specifically define that using for example ORG directive in NASM. If you use the ORG directive in NASM, u will need to keep that synchronized with the linker script in order for all the labels etc. to keep the right offsets calculated.

So essentially.. this linker script might even add complexity and issues when working with multiple binary blobs. u can't align them or use nice linker features....

If you use more structured files, which allow for example for relocation... then ur already using ELF or PE and can simple produce those files. They can be more masterfuly linked with nice features, and linker scripts are then essential.

You can add your binary blob in the right location in the output file of a linking run, using a linker script. This is useful to add data into your files but for an MBR it's not particularly useful. People do it, but it adds no benefit over just sticking it on the front if your disk using 'dd' for example. ------

That being my views, I am wondering what you see the benefit here? Are there some linker features i am unaware of that are particularly useful here? (I really know only alignment stuff in there... and include blobs or put stuff into /discard/ and some basic define sections/segments etc.). I am not familiar with perhaps more advanced linking features.

Re: Writing a BIOS bootloader for 64-bit mode from scratch

#63
post #58

Earlier quoted context omitted.

Not sure, I wouldn't count on it. Currently deep in RISC-V and it seems there's hope.

I don't see how riscv can be anything but worse than Arm in this regard. With Arm at least Arm Holdings has some nominal power to steer towards sanity (devicetrees, systemready etc), with riscv it's again full freedom for vendors to make their own bespoke crap.

Unfortunately this is true in general, but for servers there is some hope: https://github.com/riscv-non-isa/riscv-server-platform

Re: Writing a BIOS bootloader for 64-bit mode from scratch

#64

Earlier quoted context omitted.

And then you're free from dealing with the somewhat convoluted processor init stuff, but instead depend on the Windows PE format, FAT filesystem, and an overcomplicated API. Seems like a bad tradeoff, and part of a slippery slope towards a completely locked down system, where writing your own code and getting it to run on the 'bare metal' is flat out impossible.

> instead depend on the Windows PE format, FAT filesystem, and an overcomplicated API. Sometimes I wonder: if UEFI instead used ELF format, ext2 filesystem, and somewhat less complicated API (let's be honest: UEFI API is pretty straightforward if tedious), would people still complain about such dependencies? Or would it be deemed to be "fine" since it's not Microsoft technology even though it still would require one…

Yes, also probably if you used FDT instead of ACPI despite all the problems that are fixed by ACPI but present with FDT, because "ACPI is evil" :V

Re: Writing a BIOS bootloader for 64-bit mode from scratch

#65
post #22

Earlier quoted context omitted.

What's the reason why FreeDOS can't use the CSM (the BIOS compatibility mode of UEFI)?

AFAIK it can. I believe some UEFI implementations don't have CSM.

a Type 3 UEFI implementation has no CSM, Type 2 has CSM available, Type 1 enforces booting into CSM (what many "BIOS"es actually was in later days)

Re: Writing a BIOS bootloader for 64-bit mode from scratch

#66

Earlier quoted context omitted.

None of that exists in single user. When you say init=/bin/foo, then that's it, the only process is /bin/foo.

/bin/foo is the initial process. It can fork and/or exec other processes, right?

As much as DOS allowed multiple processes, even if only one was executed at the time and there was no multitasking outside of ill-fated MS-DOS 4.0 and various Concurrent DOS products.

Re: Writing a BIOS bootloader for 64-bit mode from scratch

#67

Earlier quoted context omitted.

And then you're free from dealing with the somewhat convoluted processor init stuff, but instead depend on the Windows PE format, FAT filesystem, and an overcomplicated API. Seems like a bad tradeoff, and part of a slippery slope towards a completely locked down system, where writing your own code and getting it to run on the 'bare metal' is flat out impossible.

> instead depend on the Windows PE format, FAT filesystem, and an overcomplicated API. Sometimes I wonder: if UEFI instead used ELF format, ext2 filesystem, and somewhat less complicated API (let's be honest: UEFI API is pretty straightforward if tedious), would people still complain about such dependencies? Or would it be deemed to be "fine" since it's not Microsoft technology even though it still would require one…

Its not the fact that its from Microsoft, its the fact that both FAT and PE are full of legacy cruft that is no less painful than going through real mode in the first place.

FAT originally only can do 8.3 filenames, but take a look at this to see what they hacked on top: https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#...

This is all the legacy shit you now have to implement when you want a so-called "legacy-free" boot. Infuriating.

Re: Writing a BIOS bootloader for 64-bit mode from scratch

#68
post #58

Earlier quoted context omitted.

Not sure, I wouldn't count on it. Currently deep in RISC-V and it seems there's hope.

I don't see how riscv can be anything but worse than Arm in this regard. With Arm at least Arm Holdings has some nominal power to steer towards sanity (devicetrees, systemready etc), with riscv it's again full freedom for vendors to make their own bespoke crap.

> With Arm at least Arm Holdings has some nominal power to steer towards sanity

How's that working?

RISC-V at least can have a formal spec that companies can choose to follow. The profile mentioned in another comment is one way. Companies can say they're compliant with this or that profile and software can target it.

Re: Writing a BIOS bootloader for 64-bit mode from scratch

#69
post #46

Earlier quoted context omitted.

Intel did a prototype of a multiprocessor UEFI application that would start up cores and UEFI itself does support synchronization on the assumption that applications/bootloaders will start other cores before calling ExitBootServices. However, there are no protocols as of 2.10 (the current spec[1]) that I can find that would bring up another processor. That said searching it can be a bit arcane. [1] https://uefi.org/s…

It's part of the PI spec rather than the base spec: https://uefi.org/specs/PI/1.8A/V2_DXE_Boot_Services_Protocol...

Interesting, very interesting. Curious that the PI spec doesn't include update dates on the versions. The MP spec was introduced in 1.5 and I have no idea when that was released.

Re: Writing a BIOS bootloader for 64-bit mode from scratch

#70
post #55
post #4

note that you can switch to long mode directly, without going into protected mode first, with way less code: https://wiki.osdev.org/Entering_Long_Mode_Directly i've had a bootloader for a small 64-bit kernel based on this that fit comfortably into the bootsector, including loading the kernel from disk and setting up vesa modes, no stage2 required.

you are right. Though with the partition table in there so u can support a 'modern' AHCI controller and SATA it will shrink your bootloader further and require some optimizations.... - you don't have 510 bytes for the loader in this case but a bunch less. if you want to populate the table with valid entries then it becomes even more tricky (can't use any bytes inside of the table...) If you want to use an actual mode…

ACHI (which is how SATA is exposed) doesn't change any of this. The only thing that is affected is how the loaded OS has to talk to the disk controller. The real thing that loses space is the BPB (a 60 bytes or so, iirc) because some BIOSes are broken and require it and the MBR (but that's only a couple bytes). At least [bootelf] manages to fit in (without a BPB or an MBR) with 128 bytes to spare, enough for a dummy BPB that makes all BIOSes happy.

Additionally, UEFI's reliability is.. sketchy, as far as I know (using the classic logic of "if Windows doesn't use it does it really matter?"). And GNU-EFI suffers from build portability troubles, AFAIK.

[bootelf]: https://github.com/n00byEdge/bootelf

Post reply on HN