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

41–50 of 82 posts

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

#41

Post by [deleted] »

rep_lodsb wrote: post #37
dataflow wrote: post #7

Earlier quoted context omitted.

> 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. How in the world do you fit all that in 512 bytes? I'm guessing you don't have a real-world filesystem (that allows the kernel to be anywhere on the disk just as a normal file)? Because just dealing with file fragmentation shoul…

I've been thinking about how to structure a filesystem such that code complexity - in the boot loader and elsewhere - can be minimized. You'd want something similar to NTFS, except that it should be possible to refer to a file (MFT entry) directly by starting sector number. So they would either need to always remain at a fixed position, or have a link pointing back to any reference so it can be updated. Somewhere in…

[deleted]

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

#42

Post by RiverCrochet »

rep_lodsb wrote: post #37
dataflow wrote: post #7

Earlier quoted context omitted.

> 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. How in the world do you fit all that in 512 bytes? I'm guessing you don't have a real-world filesystem (that allows the kernel to be anywhere on the disk just as a normal file)? Because just dealing with file fragmentation shoul…

I've been thinking about how to structure a filesystem such that code complexity - in the boot loader and elsewhere - can be minimized. You'd want something similar to NTFS, except that it should be possible to refer to a file (MFT entry) directly by starting sector number. So they would either need to always remain at a fixed position, or have a link pointing back to any reference so it can be updated. Somewhere in…

> File names would be entirely optional and for human consumption; for direct links within a filesystem, sector numbers would be used, and some kind of unique numeric identifier for anything "higher-level".

Each file has index number ("Inode"?) in the MFT. The first 24 (0-23) are reserved, and 11 of them contain metadata about the volume . https://flatcap.github.io/linux-ntfs/ntfs/files/ - somewhere in the Windows API is something that allows opening a file by "Inode" number. This link and info may be really old so it could be more of the reserved inodes are used now.

So, if 23 isn't being used yet, you could use that to put your 2BL - create a file there and name it $2BL or something. Would be funny to see what future Windows update that does use it does to it, if that ever happens (and of course maybe it is used).

> Maybe there could be a flag that tells the OS that a certain file should never be fragmented?

Haven't looked but I recall from an old book I read that small files are stored right in the MFT and I think existing data + the cluster size is the limit there.

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

#43

Post by gtirloni »

Brian_K_White wrote: post #38
ryandrake wrote: post #20

Earlier quoted context omitted.

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

Sure the facility to fork still exists. So what? Observing that the kernel still provides fork() is like observing that the cpu still provides JMP. It won't fork random processes you don't explicitly tell it to. I thought it was obvious that if you don't want unsolicited processes, then don't specify /bin/init as /bin/foo. The practical example is /bin/sh, but it could be any other executable. Up to you to specify a…

It's obvious but many people here seem to be confusing the Linux kernel with kernel+systemd and complaining Linux has many processes like it's not customizable.

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

#45

Post by LiamPowell »

leeter wrote: post #39
LiamPowell wrote: post #15

Earlier quoted context omitted.

UEFI exists. You just put a Windows-like binary in a folder on a partition and it runs in a hosted environment in 64-bit mode. And of course there's countless bootloaders that can take care of all this for you too.

This is fine if you're only running on a single core, however if you're a multiprocessor OS you still need to deal with legacy when bringing up the other cores. Intel and AMD should consider a mode that disables that and brings up the other cores using a 64bit SIPI. While I applaud Intel on the X86S idea... I think there is room for bits of that without throwing out all the backwards compat. An X86SC which drops real…

I vaguely recall there being some multicore stuff in UEFI, but it's been years since I looked at it.

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

#46

Post by leeter »

LiamPowell wrote: post #45
leeter wrote: post #39

Earlier quoted context omitted.

This is fine if you're only running on a single core, however if you're a multiprocessor OS you still need to deal with legacy when bringing up the other cores. Intel and AMD should consider a mode that disables that and brings up the other cores using a 64bit SIPI. While I applaud Intel on the X86S idea... I think there is room for bits of that without throwing out all the backwards compat. An X86SC which drops real…

I vaguely recall there being some multicore stuff in UEFI, but it's been years since I looked at it.

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/specs/UEFI/2.10/index.html

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

#47

Post by skissane »

dataflow wrote: post #7
5- wrote: 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.

> 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. How in the world do you fit all that in 512 bytes? I'm guessing you don't have a real-world filesystem (that allows the kernel to be anywhere on the disk just as a normal file)? Because just dealing with file fragmentation shoul…

> Because just dealing with file fragmentation should bump you way over 512 bytes I would imagine.

Historically, many filesystems have had a special file type or attribute for contiguous files - a file guaranteed to not be fragmented on disk. Most commonly used for boot loaders, OS kernels, or other essential system files - although historically some people used them for database files for a performance boost (which is likely rather marginal with contemporary systems, but decades ago could be much more significant).

Some systems required certain system files to be contiguous without having any special file metadata to mark them as such - for example, MS-DOS required IO.SYS and MSDOS.SYS to be contiguous on disk, but didn’t have any file attribute to mark them as contiguous. Unlike an operating system with proper support for contiguous files, DOS won’t do anything to stop you fragmenting IO.SYS or MSDOS.SYS, it is just the system will fail to start if you do. (Some might interpret the System attribute as implying Contiguous, but officially speaking it doesn’t.)

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

#48

Post by userbinator »

hyperman1 wrote: post #18

The 80286 has the Machine Status Word (MSW), a 16 bit register. The 80386 expands this to CR0, a 32 bits register. Then 64 bit long mode adds the EFER MSR and expands CR0 to 64 bits. But even today only 11 bits of CR0 are in use and EFER has 8 active bits. I wonder why intel/AMD did not simply use the free bits of the existing register, and made that decision twice? https://wiki.osdev.org/CPU_Registers_x86-64#CR0 .

The one-word answer is probably "bureaucracy". Large groups of people just don't tend to make particularly good decisions overall, and a lot of nonsensical choices arise from that.

Ditto for why CR1 and 5-7 are still "reserved" and CR8 came into existence.

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

#49

Post by userbinator »

ThinkBeat wrote: post #14

All to me entirely unnecessary steps required to get the CPU into the correct mode is astounding. They all seem to be steps needed for backwards compatibility. Could Intel just provide a flag, command, to start in the right mode from the beginning. Or just remove all the backwards compatibility. I think I remember doing some research and ARM64 has some of the same issues. Are there any CPUs that are designed from scr…

Intel tried that with the 80376 and it did not go well: https://en.wikipedia.org/wiki/Intel_80376

Neither did the Itanium (Itanic).

Backwards compatibility is the whole reason for choosing x86 over ARM, MIPS, RISC-V, etc. Sadly it seems some people at Intel and AMD don't realise this.

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

#50

Post by ChickeNES »

5- wrote: 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.

Or just use https://limine-bootloader.org/, which greatly simplifies everything. No messing around in real mode (even when doing SMP), automatically loads your kernel using a higher-half mapping, and also works on aarch64 and riscv64.
Post reply on HN