x86_64 BSP


  1. x86_64 BSP
  2. Introduction
  3. Project
    1. Goal
    2. Prerequisite
    3. Resources
  4. Tasks
    1. Tools
    2. CPU Kit
    3. BSP
      1. Console
      2. Timer
  5. Acknowledgements
  6. Miscellaneous Sections
  7. References

Students: Amaan Cheval

Mentors: Hesham Almatary, Chris Johns, Joel Sherrill


This project involves the creation of an x86_64 BSP for RTEMS to replace the aging i386 PC BSP. The BSP is to boot on current Off The Self (OTS) PC hardware, x86 dev boards and emulators in popular emulation software.

This BSP is to support 64bit only, there is no need to support 32bit.

The i386 BSP contains legacy support and this is becoming harder and harder to maintain and some parts are not supported on newer hardware. There is no need to support any legacy hardware.



To remove the i386 BSP and replace with a fully functional RTEMS with SMP, TLS, dynamic loading, and libbsd support.


  • Knowledge of x86_64 ASM, C Programming language.
  • Knowledge of hardware and low level drivers.
  • Knowledge of low level debugging.
  • Knowledge of x86_64 Intel processors.
  • Knowledge of FreeBSD kernel source would help.
  • Requires x86_64-rtems tool configuration.
  • Requires QEMU,
  • Requires modern PC hardware, e.g. a recent motherboard or a Minnow Max board.


  • Current RTEMS developers.
  • Use existing code instead, e.g. FreeBSD, Intel.


The following are the tasks:


  • Build and verify x86_64 tools.
  • Check suitable floating point multilib variants are being built and are functioning.
  • Confirm newlib support is valid. Check setjmp/longjmp support is functioning.
  • Check Thread Local Storage (TLS) is supported.


Add support for the x86_64 architecture.

It is still no clear if this is a new architecture or something added to the i386 architecture that exists in the cputkit/score/i386. Consider the effect support for any hyper-visors needs may have.

The tools for this architecture are different to the i386-rtems tools so it could be a new architecture. This means the i386 support could be removed including the tools however this may effect any existing hyper-visor or partitioned system support.


Add support for:

  • Add support for UEFI booting. Evaluate using an ASM generated table header or adding a tool to create the PC COFF+ format file. Use the FreeBSD support in the FreeBSD kernel source.
  • Support UEFI and Multiboot formats.
  • Support boot loader command line arguments.
  • Add support for ACPI using Intel's ACPICA. Best to base this on the FreeBSD code in it's kernel source.
  • Add support for APIC.
  • Add support for SMP.
  • Support low level remote debugging.
  • Thread Local Storage (TLS) support.


The i386 PC has legacy console support plus support for newer PCI UARTS. The i386 BSP code can be used as reference however I do not encourage reuse because the code's structure is not of a standard I would accept. Further to this, boot modes such as UEFI have the video hardware in graphics mode or the hardware can be headless and console IO can be redirected by the UEFI bios settings. This means a more flexibly and simplified console structure is required that can support redirection.

The redirection to a boot loader such as UEFI adds another complication. At some point RTEMS needs to take over the hardware and so printk need to be able to take over the related hardware, eg a serial port. This may mean some form of video switching from a graphics mode to text mode. Using a graphics mode with text is fine for testing however in production the slow down is not acceptable.





Miscellaneous Sections

As the project progresses, you will need to add build instructions, etc and this page will evolve from a project description into a HOWTO.


  • TBD
Last modified on 11/08/18 at 21:04:12 Last modified on 11/08/18 21:04:12