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@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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
