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
Re: devel.rtems.org unavailabe?
I pinged Amar. I recall that he periodically has to restart the webserver. On Fri, Jun 29, 2018, 7:24 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > The > > https://git.rtems.org/ > > still works. > > On 29/06/18 13:21, Amaan Cheval wrote: > > Hi! > > > > Here's what I see when visiting https://devel.rtems.org/: > > > > Service Unavailable > > > > The server is temporarily unable to service your request due to > > maintenance downtime or capacity problems. Please try again later. > > > > Regards, > > Amaan > > -- > 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
Re: devel.rtems.org unavailabe?
The https://git.rtems.org/ still works. On 29/06/18 13:21, Amaan Cheval wrote: Hi! Here's what I see when visiting https://devel.rtems.org/: Service Unavailable The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later. Regards, Amaan -- 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
devel.rtems.org unavailabe?
Hi! Here's what I see when visiting https://devel.rtems.org/: Service Unavailable The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later. Regards, Amaan ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [GSoC - x86_64] Console / serial communication
On 29/06/18 11:04, Amaan Cheval wrote: I'll bench this for now since I don't think it'll be a problem - I believe our tests can ignore extra output outside of the actual test region, yes? Yes, the boot loaders on other platforms are also quite verbose, e.g. U-Boot. -- 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
Re: [GSOC - Tracing] Status Update
> > >Could you please create a self-contained repository which contains >> >> >* a README >> >> >* a simple RTEMS application which runs on a simulator BSP >> >> >* the stuff that makes it possible to view the trace output (it is not a >> problem if it doesn't work, but all pieces should be included) >> >> >The repository should not be a clone of some larger project. It may >> contain external references as submodules. >> >> Okay. Got it. I will update you when its done. >> > > Ok, do you have a time estimate for this? Which parts are missing? Viewing the trace output is buggy right now. I will have to combine the rest. I will push the required things in the repository by end of today and notify you. > Is visualization with Trace Compass a goal of this project? >> >> No it isn't. Trace generation in CTF is a goal. >> > > What are the consumers of this CTF? Why do we need it? What is the benefit > for the RTEMS users? CTF allows traces to be natively generated by any C/C++ application or system, as well as by bare-metal (hardware) components. CTF is a flexible tracing format with a range of configurable datatypes. This allows CTF to describe any binary structure. Also since CTF is a binary trace format it is faster to write. The post processing (eg Trace Compass) and real time monitoring tools available with it are valuable. On Fri, Jun 29, 2018 at 10:35 AM, Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 28/06/18 19:41, Vidushi Vashishth wrote: > >> >Could you please create a self-contained repository which contains >> >> >* a README >> >> >* a simple RTEMS application which runs on a simulator BSP >> >> >* the stuff that makes it possible to view the trace output (it is not a >> problem if it doesn't work, but all pieces should be included) >> >> >The repository should not be a clone of some larger project. It may >> contain external references as submodules. >> >> Okay. Got it. I will update you when its done. >> > > Ok, do you have a time estimate for this? Which parts are missing? > > >> >Did you modify babeltrace? >> >> No I did not. >> > > Ok, this is good. > > >> >Why do you need a very recent babeltrace for your work? >> >> I haven't tested the code with other versions of babeltrace. I cant say >> why it does not work with others. I ll try to test the code with other >> versions and identify what's wrong. >> > > If it doesn't work with the babeltrace shipped with standard > distributions, then this a slight burden to get started for users. It is > not a high priority issue at the moment. > > >> > Is visualization with Trace Compass a goal of this project? >> >> No it isn't. Trace generation in CTF is a goal. >> > > What are the consumers of this CTF? Why do we need it? What is the benefit > for the RTEMS users? > > > -- > 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
