On Fri, Jun 29, 2018 at 6:46 PM, Sebastian Huber <sebastian.hu...@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@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
