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

[Amaan Cheval]

On Fri, Jun 29, 2018 at 6:46 PM, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
> 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.*))
>   }
>

Thanks for the heads-up - those patches are part of why I haven't
rebased recently :)
I likely will soon.

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

Ooh, brilliant, I'd missed that. I'll send patches there instead of
the wiki after the code is closer to being merged and more stable.

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

Noted. I'll start cleaning right away, then, unless someone disagrees soon.

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