Re: [GSoC - x86_64] Current state, next steps, and minimal mergable BSP
Hi! Quick question - when I squash and submit the patches to devel, do 2 commits make sense? 1. Initial BSP that can build completely and get to the user's Init task 2. NS16550 console driver that lets printf/printk work Another question - my code has a bunch of XXX comments in it - are we okay to leave that as-is? Should I be changing some to TODOs, as appropriate (seems like unnecessary effort since the BSP is still in flux a fair bit). I've made a WIP pull-request on Github to make some early feedback easier (patches on the mailing list would likely feel cluttered for this much code, I think). There's a bunch of clean-up left before I'll squash (see the to-do in the PR), but I'd appreciate a skimmed review if possible for anything else I need to do pre-merge: https://github.com/AmaanC/rtems-gsoc18/pull/1 Let me know what you think! On Sun, Jul 1, 2018 at 7:06 AM, Chris Johns wrote: > >> On 29 Jun 2018, at 11:37 pm, Amaan Cheval wrote: >> >> On Fri, Jun 29, 2018 at 6:46 PM, Sebastian Huber >> wrote: >>> >>> 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. >> > > I am happy to see this code merged as soon as possible. > > Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [GSoC - x86_64] Current state, next steps, and minimal mergable BSP
> On 29 Jun 2018, at 11:37 pm, Amaan Cheval wrote: > > On Fri, Jun 29, 2018 at 6:46 PM, Sebastian Huber > wrote: >> >> 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. > I am happy to see this code merged as soon as possible. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [GSoC - x86_64] Current state, next steps, and minimal mergable BSP
On Fri, Jun 29, 2018 at 6:46 PM, Sebastian Huber
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
Re: [GSoC - x86_64] Current state, next steps, and minimal mergable BSP
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
[GSoC - x86_64] Current state, next steps, and minimal mergable BSP
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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
