Our great sponsors
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
builder-hex0
Builder-Hex0 is a minimal build system which includes a bootloader, kernel, shell, and a hex0 compiler
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
Oh yeah, thanks for the context. Checking my old OS it seems I did do that near jump too. I'd forgotten about that.
It looks like the author of this PDF confused the two jumps.
Looks like Linux nowadays does the far jump immediately after setting cr0, thus doing two in one:
https://github.com/torvalds/linux/blob/master/arch/x86/boot/...
But the near and far jump (if you use both) still have VERY different purposes. And the CPU is not really in 32bit mode until all the segment descriptors have been loaded manually.
Linux didn't used to combine them:
https://elixir.bootlin.com/linux/2.2.26/source/arch/i386/boo...
Here we see the near instruction flushing jump, then a bunch of code (that is still in 16bit mode!), and then the long jump that switches the instruction set to 32bit.
The assembly in that last link explains it well.
https://www.udemy.com/course-dashboard-redirect/?course_id=3.... If someone interesting It's good course for OS kernel development. Using this course, I was able to write a 64-bit kernel with memory management, user space, file system, shell. It only lacks the ata disk driver https://github.com/JustVic/melisa_kernel.
I also found "The little book about OS development" useful.
https://littleosbook.github.io/
"It is true: in our quest to make full use of the CPU, we must abandon all of those helpful routines provided by BIOS. As we will see when we look in more detail at the 32-bit protected mode switch-over, BIOS routines, having been coded to work only in 16-bit real mode, are no longer valid in 32-bit protected mode; indeed, attempting to use them would likely crash the machine.
"So what this means is that a 32-bit operating system must provide its own drivers for all hardware of the machine (e.g. the keybaord, screen, disk drives, mouse, etc). Actually, it is possible for a 32-bit protected mode operating system to switch temporarily back into 16-bit mode whereupon it may utilise BIOS, but this teachnique can be more trouble than it is worth, especially in terms of performance."
--
In the toy 32-bit OS I am currently writing, having easy disk access and text output was more important to me than performance, so I decided to implement this technique to access the disk and screen via the BIOS instead of writing an ATA disk driver.
Although I could not find any minimal yet complete working examples of dropping to 16 bit and later resuming 32 bit mode, I was able to piece it together and write assembly functions called enter_16bit_real and resume_32bit_mode. See https://github.com/ironmeld/builder-hex0/blob/main/builder-h.... Those routines are working well but beware the project is a volatile work in progress and is coded in hex for bootstrapping reasons.
If anyone is interested, I have a couple of implementations of booting under UEFI and getting a bunch of info about the system (don't expect a functioning system, they just boot and dump some info):
Nim: https://github.com/khaledh/axiom
Zig: https://github.com/khaledh/axiom-zig (this one goes into depth in disassembling ACPI DSDT bytecode)
If anyone is interested, I have a couple of implementations of booting under UEFI and getting a bunch of info about the system (don't expect a functioning system, they just boot and dump some info):
Nim: https://github.com/khaledh/axiom
Zig: https://github.com/khaledh/axiom-zig (this one goes into depth in disassembling ACPI DSDT bytecode)
First off I don't recommend implementing the specification from scratch. It is big, and there are implementations already in various languages: for C you can use GNU-UEFI, for example, and for Rust you can use uefi-rs. Zig even has it in its standard library! These take care of the fiddly details of interacting with the UEFI firmware's services.
There's tutorial type articles for these around: for C there's https://wiki.osdev.org/UEFI_App_Bare_Bones, for Rust there's this template https://github.com/rust-osdev/uefi-rs/tree/main/template and the crate's documentation.