Memory Map (General)

From Syslinux Wiki
Jump to: navigation, search

SYSLINUX Memory Management

As SYSLINUX runs directly on the machine, it must implement some of the functions of an operating system. One of these functions is memory management, which is implemented quite simply - as a bootloader, SYSLINUX doesn't need any of the fancy features such as memory paging and virtual memory.

After it is fully loaded (see boot stages for details), SYSLINUX runs in the protected 32-bit mode (even on 64-bit machines), with memory paging disabled. Thus, it is able to directly address up to 4 GB of physical memory, limited to the actual amount of installed RAM.

Physical Memory Organization

The layout of the SYSLINUX image in memory is important in order to better understand the functionality of the software. The image below presents the layout (map) of the physical memory after SYSLINUX image is fully loaded and a COM32 module is executed.

MemoryMapGeneral.png

0 - 640K

The first 640K of memory contain the entire SYSLINUX image (located in the first 64K segment of memory), plus other segments used mainly for buffering. Starting from bottom, the relevant memory portions in this area are:

  • Segment 0 of memory, containing the SYSLINUX image.
  • xfer_buf_seg is a buffer used by the SYSLINUX core to transfer data to high memory (the COM32 module, above 1024KB). This kind of buffer is also called a bounce buffer.
  • cache_seg is a small disk cache used to cache file system metadata (such as inode descriptors). It's worth mentioning that this buffer is used only by disk based derivatives of SYSLINUX; PXELINUX uses pktbuf_seg instead, that holds the current Ethernet packet.
  • real_mode_seg has multiple functions:
    • It holds the real-mode part of the Linux kernel.
    • It is used by the system to pass data to and from the BIOS, when a BIOS call is made on behalf of a COM32 module, because the BIOS functions are unable to address more than 640K of memory. This is also a bounce buffer, analogue with xfer_buf_seg.
    • This segment is also used by the SYSLINUX core getc() function, for reading a character from a file.
    • This segment can hold a COM16 binary.
  • PXE and EBDA are found at the end of this area and are used by other parts of the system. PXE is used for network booting (Preboot eXecution Environment), and EBDA (Extended BIOS Data Area) contain some global variables used by the BIOS. SYSLINUX does not overlap with these areas.

640K - 1024K

The memory area between 640K and 1024K is not used by SYSLINUX, as it can be seen from the diagram. This space is mainly shared between the VGA buffer and BIOS, ISA device memory, and the BIOS runtime.

1024K - End of physical RAM

This portion of memory is also called high memory (not to be confused with the Linux kernel conception of high memory), and it contains the currently loaded SYSLINUX module. At this time SYSLINUX is not able to load more than one module simultaneously, but a better, ELF format based, module system is under development.

The components of a COM32 module are:

  • COM32 interrupt handlers which actually are stub routines that enter the real mode and execute the BIOS interrupts handlers. SYSLINUX does not implement any device driver, and leaves hardware management to be handled by the computer BIOS. COM32 modules run in protected mode, and in this run mode an IDT (Interrupt Descriptor Table) needs to be configured instead of a simple IVT (found at the start of the physical RAM, handled by the BIOS). So SYSLINUX sets up an IDT to point to routines in this segment. These routines record the interrupt number, and call the appropriate BIOS interrupt handler in real mode. This technique is also called thunking.
  • COM32 .data and .text segments, which contain the module code and initialized global data.
  • COM32 .bss segment, which contain the uninitialized data of the module.

The end of the .bss segment marks also the end of module static code and data, and the rest of the RAM is shared between the module stack and the heap. Near the end of the RAM, SYSLINUX also stores its label information, right before system ACPI information.

See also

This page is known to be best accurate as of SYSLINUX version 3.70. Minor modifications may have occurred in subsequent versions, but the general idea presented in this page remains the same.