Looking for a page?

 
Important notice - 06 April 2013

All eosgarden activities have been closed forever, in order to focus on new projects.
The content of this website will stay as is, for archive purpose, but won't be updated anymore.
eosgarden software are still available for download, but are no longer maintained. Support is no longer available.
 
 

GitHub

All our OpenSource projects have been migrated to GitHub.
Feel free to fork!
Documentation

Technical details

This section contains some technical details about the XEOS operating systems.
You'll find some usefull informations about the boot process, the XEOS kernel, hardware communication, the available libraries, and the organisation of the XEOS source code.

Table of contents

  1. Boot process
  2. Kernel
  3. Interrupts
  4. Syscalls
  5. Hardware abstraction layer
  6. Memory layout
  7. C Library
  8. XEOS Library
  9. Source code organisation

2. Boot process

The XEOS boot process consist of three main steps:
  1. First-stage bootloader
  2. Second-stage bootloader
  3. Kernel

1 - First-stage bootloader

This is the very first step of the XEOS boot process.
The first-stage bootloader consists of an x86 assembly program, loaded by the BIOS from the first 512 bytes of the XEOS boot floppy.
For technical reasons, related to the BIOS, this software cannot exceed 512 bytes, when loaded into memory.
Even when writing pure assembly, it's hard to setup all the stuff needed by a kernel withing 512 bytes.
So the only task executed by the first-stage bootloader is to find a second-stage bootloader, whose size isn't limited, from the FAT-12 floppy disk, to load it into memory, and to execute it's code.
It uses BIOS interrupts to load the FAT-12 allocation table into memory, and look for a file named 'BOOT2.BIN'.
When it's found the file is loaded into memory, at the 0x50:0 address.
Control is then transfered to the second-stage bootloader.

1.2 - Second-stage bootloader

The second-stage bootloader is responsible to set-up a correct environment for the XEOS kernel, and of course to load and execute it.
Those steps cannot be made by the first-stage bootloader, as it takes more than 512 bytes of code.
The second-stage bootloader is loaded at the 0x50:0 memory address, so it's at the top of the available memory.
Three main tasks are performed here:
  1. Load the XEOS kernel into memory
  2. Switch the CPU to 32bits protected mode
  3. Execute the XEOS kernel

1.2.1 - Kernel load

This first step is exactly the same as what the first-stage bootloader previously did.
It looks for a file named 'KERNEL.ELF' in the XEOS floppy disk, and loads it into memory, at the 0x1000:0 memory address.
Here again, it uses BIOS interrupts.

1.2.2 - 32bits protected mode

For historical reasons, an x86 computer boots in 16bits 'real' mode.
It means the available memory is limited to 1MB, because of a 20bits segmented memory address space.
There's also an unlimited access to all the memory areas, as well as the I/O addresses.
Also, no memory protection, multitasking, or code privilege levels.
It's perfectly possible to create an operating system running in 16bits real mode, but it would lack a lot of features provided by the modern CPUs.
So in order to execute the XEOS kernel, the second-stage bootloader needs to switch the CPU into 32bits protected mode.
This will give access to 4GB of memory, including memory protection and code privilege levels.
Technically, switching to 32bits protected mode means:
  1. Installing a global descriptor table (GDT)
    A GDT tells the x86 CPU about the required memory segmentation.
    It defines at least three memory areas, each one with specific permissions.
    The three memory areas are:
    1. a null descriptor (all zeros)
    2. an executable memory area (to load executable code)
    3. a read/write memoty area (to store data)
    XEOS actually defines two executable memory areas, and two read/write memory area.
    There's one of each for the kernel itself, with all privileges, and one of each for the user-space, with limited privileges.
  2. Enabling the A20 address line
    In real mode, the memory address space is limited to 20bits.
    To access up-to 4GB of memory, the 21st address line (A20), on the CPU's address bus, must be enabled.
    This can be done with a few ways, depending on the architecture:
    • through the system control port
    • through a BIOS interrupt
    • through the keyboard control port
    • through the keyboard out port
XEOS tries by default to enable the A20 line with a BIOS interrupt. If it fails, it will ask the user which way to try.
Once it's done, the CPU is then effectively switched to 32bits protected mode, by using the primary control register (CR0).

1.2.3 - Kernel execution

The XEOS kernel file consists an ELF binary.
The second-stage bootloaders will look for the kernel's starting point, and execute a far jump to tranfer control.
It's important to note that, in 32bits protected mode, BIOS interrupts are no longer available.
Everything has now to be coded from scratch.

3. Kernel

[CONTENT TO COME]

4. Interrupts

[CONTENT TO COME]

5. Syscalls

[CONTENT TO COME]

6. Hardware abstraction layer

[CONTENT TO COME]

7. Memory layout

[CONTENT TO COME]

8. C Library

[CONTENT TO COME]

9. XEOS Library

[CONTENT TO COME]

1. Source code organisation

  • build
    • bin
      • boot
      • core
    • mount
    • obj
      • boot
      • core
        • hal
        • kernel
        • libc
        • xeos
    • release
  • res
  • src
    • boot
      • include
    • core
      • hal
        • cpu
        • gdt
        • idt
        • include
        • io
        • pic
        • pit
        • smbios
      • include
        • hal
        • kernel
        • private
        • xeos
      • kernel
        • include
          • private
        • interrupts
        • syscalls
        • system
        • video
      • libc
      • libxeos
  • sw