[GSoC - x86_64] Current state, next steps, and minimal mergable BSP

[Amaan Cheval]

Hi!

There are 3 sections to this email:
- An update on the current state
- What I plan to work on next
- An open question on when we want to merge this upstream

--------------------------------------------------------------------------------

The current state of the BSP (available at
https://github.com/AmaanC/rtems-gsoc18/) is:

- Using FreeBSD's bootloader (loader.efi) to load RTEMS' ELF image
(replacing the existing FreeBSD /boot/kernel/kernel file)

- Likely complete linker script (linkcmds includes TLS sections and
SYSINIT seems to work)

- bspgetworkarea does _NOT_ detect available memory size right now, it
just uses all stub values (I believe FreeBSD's bootloader leaves this
information in a struct somewhere, but I need to look into it more to
know for sure)

- Untidy context-switching (how do we decide which registers should or
shouldn't be saved? For eg. rdi, rsi are part of the calling
convention and are hence clobbered by merely calling
_CPU_Context_switch - should everything but those 2 be excluded?)

- Polled console driver using ns16550-context, console-termios,
console-termios-init (hello.exe works
https://gist.github.com/AmaanC/9d95e50d3ae3dacbe7c91169b7633cfe, the
"Test" on L58 is me adding a printk to confirm printk works too.)
  NOTE: The test never ends by itself - we don't have a shutdown
routine yet, so it just loops idly, forever.

--------------------------------------------------------------------------------

My rough next steps (subject to reshuffling based on your feedback,
and realizing I didn't know all the requirements / possibilities) are:

- Work on ticker.exe passing with the idle-clock task
(clock-simidle.c) if possible
- Clean up the existing code we have and we ought to leave some time
for code reviews
- Document anything that isn't already documented (how to load the
RTEMS ELF into a FreeBSD image, for eg. - it's not friendly to
iterative develoment because you need QEMU to edit the UFS filesystem
if your host is a standard Linux kernel - see[1].)
- Look into ISR code needed
- Move console code to interrupt mode (from current polled mode)
- Look into ACPI (specifically at least be able to shutdown / reset
the system to cleanly exit)
- Misc. subtle issues with specific tests possibly failing
- Bonus items, if there's time

--------------------------------------------------------------------------------

Is there anything from the above list you'd like sooner, as part of
the BSP we merge in the coming week or two? Is the current technical
state sufficient to be merged (after cleanups)?

My understanding is that we don't really have a _hard_ requirement on
what the minimal BSP is that gets merged, but given that we reach the
Init task and printf/console drivers work, do we want to merge ASAP?
Or do we prefer to have ticker.exe passing, a real interrupt based
clock driver, etc. functioning too, if we can (i.e. should I see if I
can rush those)?

Cheers, and sorry about the lengthy email!

[1] https://lists.rtems.org/pipermail/devel/2018-June/022166.html