[kriro]

Seems to be for a x86 operating system. I'd have preferred some other architecture because so much of OSdev for x86 that I remember was working around quirks of the architecture (A20 gate etc.). I guess it's a valuable lesson but I'd really enjoy a fork of the book for the hardware you find in a Beagle Bone or Pi3 or something. Maybe this could be crowdfunded if the x86 version is popular?

[tuhdo]

Author here. Yes, it's a x86 operating system. However, rather than getting around A20, it focused on protected mode instead.

The book not only teaches x86, but how to use the official resources from the hardware manufacturer to write the OS. In sum, a reader when reaching part 3 for writing the OS, he will need to use the official document, in this case, the "System Programming Guide" manual from Intel to write C code that complies with the documents. Once he learned how to do so, learning other platforms will be much easier given how complex x86 is.

[wolfgke]

> Author here. Yes, it's a x86 operating system. However, rather than getting around A20, it focused on protected mode instead.

You still have to open the A20 gate in the bootloader if you want to access a memory adress that has bit 20 (counting from 0) be set to 1 (you probably want) - even if you switch to protected mode. The only exception is if you boot from UEFI instead of BIOS - in this case the A20 gate is already set. But the book uses BIOS as far as I see it.

[tuhdo]

In the Volume 3, it is said that:

"In protected mode, the IA-32 architecture provides a normal physical address space of 4 GBytes (2 32 bytes). This is the address space that the processor can address on its address bus. This address space is flat (unsegmented), with addresses ranging continuously from 0 to FFFFFFFFH. This physical address space can be mapped to read- write memory, read-only memory, and memory mapped I/O. The memory mapping facilities described in this chapter can be used to divide this physical memory up into segments and/or pages."

It correlates to my experience of developing in protected mode in QEMU. Once entered protected mode, I can access to any address above 0x10000 without being wrapped around. When I was writing my first kernel (https://github.com/tuhdo/os-study) in real-mode, indeed A20 must be enabled.

[Vendan]

The A20 gate would affect both real and protected mode, so to be truely compliant, you should be opening it even for a protected mode OS. It was originally a purely hardware hack forcing an address line(A20, or the 21st address line) to stay low, thus "wrapping" addresses from 1mb-2mb to 0-1mb, so it would have affected real or protected mode identically. On modern hardware, there is a chance that A20 is (against the accepted spec) default open, or possible not implemented.

[wolfgke]

> On modern hardware, there is a chance that A20 is (against the accepted spec) default open, or possible not implemented.

To nitpick on this a little bit (consider it as a polite supplement):

In Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3 (3A, 3B, 3C & 3D): System Programming Guide

in section

8.7.13.4 External Signal Compatibility

one can read (emphasis by me):

"A20M# pin — On an IA-32 processor, the A20M# pin is typically provided for compatibility with the Intel 286 processor. Asserting this pin causes bit 20 of the physical address to be masked (forced to zero) for all external bus memory accesses. Processors supporting Intel Hyper-Threading Technology provide one A20M# pin, which affects the operation of both logical processors within the physical processor.

The functionality of A20M# is used primarily by older operating systems and not used by modern operating systems. On newer Intel 64 processors, A20M# may be absent.".

TLDR: The accepted spec is that A20M# might not exist.

[Vendan]

fair point, I hadn't bothered to look more, but it's still true that A20(when implemented) gates both real and protected modes, and therefore "ignoring it to focus on protected mode" is invalid