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

[Sebastian Huber]

Hello Amaan,

On 29/06/18 14:31, Amaan Cheval wrote:
> 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)

I reworked the initialization and interrupt stack allocation and checked 
in the patch for this today:

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

I will update the documentation next week. You need a new section in the 
linker command file:

   .rtemsstack (NOLOAD) : {
     *(SORT(.rtemsstack.*))
   }

>
> - 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?)

Since the _CPU_Context_switch() is a function call, you only have to 
save/restore the non-volatile (callee-saved) registers and thread-local 
registers.

>
> - 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].)

We have a new place for BSP documentation:

https://docs.rtems.org/branches/master/user/bsps/bsps-x86_64.html

> - Look into ISR code needed

In the ISR code you have to save/restore the volatile (caller-saved) 
registers and thread-local registers.

> - 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)?

 From my point of view we can merge this stuff right now if the license 
and copyright status is clear of all files and it builds all tests.

>
> Cheers, and sorry about the lengthy email!
>
> [1] https://lists.rtems.org/pipermail/devel/2018-June/022166.html
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.