x86_64 support?

[Chris Johns]

On 10/02/2017 02:22, Joel Sherrill wrote:
> On Feb 9, 2017 7:29 AM, "Jan Sommer" <soja-lists at aries.uberspace.de
> <mailto:soja-lists at aries.uberspace.de>> wrote:
>
>     Hello,
>
>     As far as I see there is no support for x86_64 yet. I found that
>     there was a GSoC proposal to add BSP for the architecture, but I am
>     not sure if it was accepted.
>
>     Does someone know what is the current status of 64bit support and
>     what would be missing for a working BSP with a PCI and clock driver?
>
>
> There has been interest in a "pure" new port to x86_64 which does not
> have support for legacy PC hardware. It has been mentioned long enough
> that the RSB includes tool chain support.and newlib has been checked to
> see if it has setjmp. The tool chain is as ready as it can be.
>
> There needs to be a new port (e.g. score/cpu) and a new clean new BSP.
> There may be code in the old BSP which can be leveraged but we need to
> be careful to not carry baggage forward.
>
> A couple of things areas not present at all in the i386 support are APIC
> and EFI. These must be in the new x86_64 BSP.
>
> So no actual code in place. We need EFI boot, APIC interrupts, PCI,
> clock, timer and console to have a minimum BSP. That should be enough to
> run libbsd.
>
> A new framebuffer driver is likely a possibility.
>

I recently updated the x86_64 project ticket and I suggest checking it ...

  https://devel.rtems.org/ticket/2898

The project and tasks are listed in the ticket. An important issue is 
support for Intel's ACPICA code. Handling all the tables a modern BIOS 
creates is lots of work without the Intel code. I think FreeBSD's 
version is a good start. The same goes for UEFI run-time support.

We also need to examine the effect the change has on any hyper-visors or 
partitioning wrappers that support RTEMS. I would like to see the 32bit 
i386 BSP removed from the source tree.

Chris