On 10/02/2017 02:22, Joel Sherrill wrote:
On Feb 9, 2017 7:29 AM, "Jan Sommer" <soja-li...@aries.uberspace.de
<mailto:soja-li...@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
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Reply via email to