[RTEMS Project] #2898: x86_64 BSP (was: Create an x86_64 BSP)

[RTEMS trac]

#2898: x86_64 BSP
-------------------------+-------------------------
 Reporter:  tokencolour  |       Owner:
     Type:  project      |      Status:  new
 Priority:  normal       |   Milestone:  Indefinite
Component:  bsps         |     Version:  4.11
 Severity:  normal       |  Resolution:
 Keywords:  SoC          |
-------------------------+-------------------------
Description changed by chrisj:

Old description:

> = Create an x86_64 BSP =
>

> [[TOC(Developer/Projects/Open/x86_64_BSP, depth=2)]]
>

> '''Mentors:''' TBD.
>
> '''Students:''' TBD.
>

> '''Status:'''
>
> Uninitiated.
>
> '''Introduction:'''
>
> This project involves the creation of an x86_64 BSP for RTEMS that would
> allow for installing on an OTS PC, x86 dev boards and emulated in popular
> emulation software.
>
> newlib needs to be evaluated. It may be missing setjmp/longjmp support
> for x86_64.
>
> The existing pc386 BSP is a reference for some things but a goal of this
> effort is that the BSP not have any legacy device support. Using the
> pc386 as a reference, it is missing support for a number of modern things
> including:
>
> * booting from EFI
> * EFI support for devices
> * APIC support (interrupt controller)
> * proper synchronization for SMP during context switch (XXX ticket #)
> * Thread Local Storage (TLS) support
>
> In addition, there has been discussion of the pc386 console device driver
> being updated to a newer infrastructure model and I am not sure if the
> clock driver uses the bintime support.
>
> The pc386 BSP is complex and straddles supporting legacy and modern
> hardware. A new legacy free BSP for i386 as well as a port for x86_64
> with a legacy free BSP are needed. This project is focused on the x86_64.
>
> '''Goal:'''
>
> To have a functioning x86_64 BSP that will boot on OTS hardware and
> emulate fully in any x86 emulator.  Extended goals would include running
> RTEMS as a process in the build platform and peripheral support.
>

> '''Requirements:'''
>
> * Knowledge of x86_64 ASM, C Programming language.
> * Run on non-legacy hardware configurations.
> * Share code as possible with pc386 BSP.
> * Create x86_64 architectural port.
> * Requires x86_64-rtems tool configuration.
>

> '''Resources:'''
>
> * Current RTEMS developers.
> * Do not reinvent the wheel and use existing code instead, e.g. from
> FreeBSD.
>
> '''Acknowledgements'''
>  *  TBD
>
> = 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.
>
> = References =
>  *  TBD
>
> '''Other sections:''' If you have more to say about the project that
> doesn't fit in the proposed sections of this template, feel free to add
> other sections at will.

New description:

 = x86_64 BSP =

 [[PageOutline(1-5, Contents, inline)]]

 == Mentors ==
 Chris Johns

 == Students ==

 TBD.

 == Status ==

 Looking for funding.

 = Introduction =

 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.

 = Project =

 == Goal ==

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

 == Prerequisite ==

 * 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.

 == Resources ==

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

 = Tasks =

 The following are the tasks:

 == Tools ==

 1. Build and verify x86_64 tools.
 1. Check suitable floating point multilib variants are being built and are
 functioning.
 1. Confirm newlib support is valid. Check `setjmp`/`longjmp` support is
 functioning.
 1. Check TSL is supported.

 == CPU Kit ==

 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.

 == BSP ==

 Add support for:

 1. 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.
 1. Support UEFI and Multiboot formats.
 1. Support boot loader command line arguments.
 1. Add support for ACPI using Intel's ACPICA. Best to base this on the
 FreeBSD code in it's kernel source.
 1. Add support for APIC.
 1. Add support for SMP.
 1. Support low level remote debugging.
 1. Thread Local Storage (TLS) support.

 === Console ===

 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.

 === Timer ===

 TDB

 = Acknowledgements =

 None.

 = 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.

 = References =

 * TBD

--

--
Ticket URL: <http://devel.rtems.org/ticket/2898#comment:3>
RTEMS Project <http://www.rtems.org/>
RTEMS Project