Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing a BIOS bootloader for 64-bit mode from scratch

thasso.xyz

Post reply on HN
Print view View original

71–80 of 82 posts

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

#71

Post by EvanAnderson »

p_l wrote: post #65
EvanAnderson wrote: post #24

Earlier quoted context omitted.

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)

Thanks for that. That sent me down an enjoyable rabbit hole. I got started with PCs back in the 80s and became fairly familiar with how boot worked back then. UEFI happened while I was paying attention to other things and I've never become as familiar with it as I should be. This was a good excuse to do some reading.

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

#72

Post by deaddodo »

p_l wrote: post #65
EvanAnderson wrote: post #24

Earlier quoted context omitted.

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)

Just for clarification's sake, the proper terminology is "UEFI class" not "type".

Otherwise, this is accurate.

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

#73

Post by nineteen999 »

jasaldivara wrote: post #21
livrem wrote: post #10

Earlier quoted context omitted.

This killed FreeDOS (and presumably all the other *DOS as well) on modern hardware unfortunately. It was fun as long as it lasted. I do not know what the next-best single-user, single-process, non-bloated OS would be to run on modern hardware that still has some reasonably modern software and can be used for distraction-free (hobby) development the way FreeDOS could.

> I do not know what the next-best single-user, single-process, non-bloated OS would be to run on modern hardware that still has some reasonably modern software and can be used for distraction-free (hobby) development the way FreeDOS could. Not sure why would you want a single-process OS on modern hardware, but there are some alternatives that run much less things on the background than regular Linux: Haiku, FreeBSD,…

Or, you know, just booting the Linux kernel with init=/bin/sh with /bin/sh being a statically linked binary. You're overthinking things.

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

#74

Post by p_l »

blueflow wrote: post #67
Joker_vD wrote: post #57

Earlier quoted context omitted.

> 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 "leg…

Meanwhile ext family, even in ext4, requires that you handle optimizations decisions made for Fujitsu Eagle and its contemporaries.

I could easily read NTFS with hexeditor, calculator and pen&paper. Trivial even (most annoying part was the run length packing in 4-bit nibbles).

I gave up trying to read ext's cylinder-oriented mappings.

And FWIW, everyone has a read/write driver for FAT with LFN (and UEFI generally avoids names outside 8.3 just in case), using a different filesystem would lead to issues with OS support.

PE itself isn't really that much of legacy cruft, especially as far as it is used in UEFI (sure, you have the "program not for MS-DOS header", but that's useful for the rare case someone tries to open it under FreeDOS).

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

#75

Post by p_l »

rep_lodsb wrote: post #36
immibis wrote: post #32

Earlier quoted context omitted.

What's wrong with depending on the Windows PE format, FAT filesystem and UEFI? You're always going to have some dependencies. FAT32 is better than having the first sector load some magic reserved sectors. Windows PE is better than a fixed memory address.

It's adding pointless complexity, and baking assumptions about how an OS should work into the firmware. Loading a sector at a fixed memory address and jumping to it (with some function provided so that your code can go on to load other sectors) is both easier to understand, and doesn't require you to use some multi-megabyte toolchain.

Unless you need to load anything else other than what's in that sector, because you can't fit enough I/O drivers into one sector to load the rest of the OS.

Unless you're targeting S/360, but even there XA and newer made it a bit more complex.

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

#76

Post by cl91 »

livrem wrote: post #10
deaddodo wrote: post #3

Earlier quoted context omitted.

BIOS is deprecated. All of its functionality on new motherboards is basically emulated via the UEFI; and it's certainly not being extended upon. Deprecated doesn't mean deleted, it just means "no longer updated/developed with a goal towards removal".

This killed FreeDOS (and presumably all the other *DOS as well) on modern hardware unfortunately. It was fun as long as it lasted. I do not know what the next-best single-user, single-process, non-bloated OS would be to run on modern hardware that still has some reasonably modern software and can be used for distraction-free (hobby) development the way FreeDOS could.

> the next-best single-user, single-process, non-bloated OS

is UEFI.

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

#77

Post by sim7c00 »

pitust2 wrote: post #70
sim7c00 wrote: post #55

Earlier quoted context omitted.

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…

If you chose AHCI on QEMU it will require a partition table to be present on the disk, so it recognizes it as a bootable disk. in addition to the magic value. If you do not add the partition table.

Thanks for this comment. It makes me realize this is likely not an AHCI thing ,but how the seaBIOS(? qemu's flavor?) handles enumerating disks via AHCI rather than IDE.

If it uses the IDE controller then it will recognize the boot disk. If i pick AHCI, i need to add the partition table.

UEFI reliability is sketch, but really BIOS is incredibly crap, so much more than UEFI.

Windows DOES use EFI/UEFI, how else will it boot on a system that has EFI/UEFI firmware inside of it? It can let you do secureboot, edit efi variables... - where do you get this classic logic from? (maybe i am totally misisng something, but they interface with it, and should thus use the spec? even tho they might not use gnuefi or EDK2 ofc :P (edk2 is still likley...))

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

#78

Post by ForOldHack »

This seems both cool, and a good exercise, but is it useful? Does it have a UX like a fisher/price toy that you can verify/change your settings on the fly?

Booting is the process of going from mini-me mode/single user/recovery mode to flying.

I have been running Unix along side a Microsoft product since Xenix/dos. ( Looks like 40 years...) How much have we advanced?

I also have been using Linux since the swedish version came out ( first release ) and GNU 0.1.

My apologies about calling Xenix, Unix, It is a has-been wanna-be me-too square-excrament from shortly after release until it's languishing demise.

Microsoft does not release products, they empty their cat boxes onto customers. ( The most recent example is both co-pilot And 22H2. )

If you look at how F1 cars have evolved, and pencils as well as pocket calculators - how close are we to the usable ideal?

Why isn't the bootloader a static kernel mode? It used to be. Someone recently suggested it should be, and I agreed.

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

#79

Post by ForOldHack »

immibis wrote: post #40
rep_lodsb wrote: post #36

Earlier quoted context omitted.

It's adding pointless complexity, and baking assumptions about how an OS should work into the firmware. Loading a sector at a fixed memory address and jumping to it (with some function provided so that your code can go on to load other sectors) is both easier to understand, and doesn't require you to use some multi-megabyte toolchain.

Wouldn't it be better to use a header to specify to load multiple sectors at multiple memory addresses?

Yes, and considering that your boot sector is actually a boot cluster... You need not use compression. You could even steal the entire first cylinder. (Now that is old school)...

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

#80

Post by ForOldHack »

p_l wrote: post #66
ryandrake wrote: post #20

Earlier quoted context omitted.

/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.

You were not there. Multitasking? Xenix. Multitasking DOS? DOS Merge. Pre-emptive multitasking? AmigaOS. DOS 4.0M was task switching. OS/2 2.0? I'm being extremely facetious.

Give me a date, and I will tell you what existed.

Nothing mainstream existed until windows 3.1. at least on x86/32

There also was OLEC on windows 2, that did run in real mode, but the only thing that took advantage of it was the demos, and samples: no commercial product used it.

Post reply on HN