Re: LIST OF IO BENCHMARKS

[Joel Sherrill]

On Sat, May 19, 2018, 5:06 PM Udit agarwal  wrote:

> Hi,
>
> On Fri, May 18, 2018 at 11:19 PM, Gedare Bloom  wrote:
>
>> Udit,
>>
>> Can you please compare pros/cons of FIO, IOZONE, and Bonnie++,
>> probably in a blog post is a good idea.
>>
> Done, here
> 
> is the comparison.
>

That url has a hard-coded IP address in it. GSoC blogs should be hosted
somewhere where they will have a long life with stable URLs.

It looks nice though. :)


>> The GPLv2 is not a problem for test suites / benchmarks. It is only a
>> problem for code that should get merged into the rtems.git.
>>
>> Gedare
>>
>> On Thu, May 17, 2018 at 5:20 AM, Udit agarwal 
>> wrote:
>> > Hi all,
>> > As discussed in yesterday's IRC meeting, here is the list of different
>> IO
>> > benchmarks(which are supported by FreeBSD) in the decreasing order of
>> their
>> > popularity  :
>> >
>> > FIO - License type:  GPLv2 - Widely accepted for storage device
>> benchmarking
>> > IOZONE - License: Customized - Large number of features, Also used for
>> > storage benchmarking
>> > Bonnie++ - GPLv2 - Widely known filesystem benchmark, Not much used for
>> > storage benchmarking.
>> > IOMETER -  GPLv2 - Out of active development.
>> > IORATE - Flexible - Out of active development
>> >
>> > I have performed SDIO-SDHCI performance analysis using IOZONE. Here are
>> the
>> > results. And i have documented the process on my blog.
>> >
>> > Regards,
>> >
>> > Udit Agarwal
>> >
>> >
>> > ___
>> > devel mailing list
>> > devel@rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>>
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Vijay Kumar Banerjee]

On 21 May 2018 at 02:29, Cillian O'Donnell  wrote:

>
>
> On Sun, 20 May 2018, 15:35 Vijay Kumar Banerjee, 
> wrote:
>
>> On 20 May 2018 at 00:53, Vijay Kumar Banerjee 
>> wrote:
>>
>>>
>>>
>>> On Sun, 20 May 2018, 00:45 Cillian O'Donnell, 
>>> wrote:
>>>
 It works.. Sorry I was using the right covoar but the wrong rtems-test.
 Ahh its nice to see the data back in the reports again. Did you manage to
 track down 2 exes with the mismatch in symbol size?

>>> Great! so next is the parsing of the symbol file.
>>> I couldn't manage to track down the mismatch.
>>>
>>> I have pushed these to my master branch.
>>
>> The latest update to cov-tester-support branch (please have a look)
>> parses the symbol-set ini file from the coverage script. The parsing
>> is working but currently it's not generating reports, as covoar
>> needs to be updated .
>>
>
> It's best if covoar reads it's own config file, otherwise it creates a
> dependency on the tester. Scanning over the recent changes to covoar there,
> it looks like it can already handle multiple sets, so the one ini with
> multiple sets in it is the way to go.
>
Okay, Understood.

> Here are the things that I have done and that needs to be
>> done in order to generate reports :
>>
>> I have added a symbol-sets.ini file and parsed it from the coverage
>> script
>> this is how it works :
>>
>>
>>- The ini file can be updated with all the symbols, separated by ' ,
>>' (comma)
>>
>>
> This is the way covoar is actually handling it now. You should test a
> multi set ini and see if that's working.
>
Yeah, I have seen it. will try with multiple sets.

>
>>-
>>- The coverages splits them and makes a list of all the sets
>>-  The respective libraries are parsed from the libraries section.
>>- It returns a dict with all the symbols and thir resp. library
>>addresses.
>>- The library addresses are absolute so it can be run from anywhere
>>top of build tree is not necessary.
>>
>> This was a good idea but it's just that dependency issue we want to stay
> away from. Covoar has something to find the build directory too, it just
> hasn't been connected up yet, so running it from the top of the build
> directory is ok for the moment.
>

yes it can find the build directory. I was giving it a shot to do it from
the script.

If covoar's standalone working is a necessity then it surely needs to be
working
from covoar and shouldn't depend on the script.

>
> Probably the most pressing thing now is investigating those mismatch in
> symbol size.
>

any advice on where/how to look for it ?

> This way we can parse all the symbols from the same ini file.
>>
>> what needs to be done :
>>
>>- I have added #FIXME s in the code , those are the small fixes that
>>would be needed .
>>- The covoar needs to be updated. My proposal is that we can feed the
>>parsed  dict to the covoar instead of feeding the symbol file and
>>letting
>>covoar parse it ( As I mentioned previously).
>>
>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

WiFi status

[Joel Sherrill]

Hi

What's the status of the wifi support?

Sorry for such a general question.

Thanks.

--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Cillian O'Donnell]

On Sun, 20 May 2018, 15:35 Vijay Kumar Banerjee, 
wrote:

> On 20 May 2018 at 00:53, Vijay Kumar Banerjee 
> wrote:
>
>>
>>
>> On Sun, 20 May 2018, 00:45 Cillian O'Donnell, 
>> wrote:
>>
>>> It works.. Sorry I was using the right covoar but the wrong rtems-test.
>>> Ahh its nice to see the data back in the reports again. Did you manage to
>>> track down 2 exes with the mismatch in symbol size?
>>>
>> Great! so next is the parsing of the symbol file.
>> I couldn't manage to track down the mismatch.
>>
>> I have pushed these to my master branch.
>
> The latest update to cov-tester-support branch (please have a look)
> parses the symbol-set ini file from the coverage script. The parsing
> is working but currently it's not generating reports, as covoar
> needs to be updated .
>

It's best if covoar reads it's own config file, otherwise it creates a
dependency on the tester. Scanning over the recent changes to covoar there,
it looks like it can already handle multiple sets, so the one ini with
multiple sets in it is the way to go.

> Here are the things that I have done and that needs to be
> done in order to generate reports :
>
> I have added a symbol-sets.ini file and parsed it from the coverage script
> this is how it works :
>
>
>- The ini file can be updated with all the symbols, separated by ' , '
>(comma)
>
>
This is the way covoar is actually handling it now. You should test a multi
set ini and see if that's working.

>
>-
>- The coverages splits them and makes a list of all the sets
>-  The respective libraries are parsed from the libraries section.
>- It returns a dict with all the symbols and thir resp. library
>addresses.
>- The library addresses are absolute so it can be run from anywhere
>top of build tree is not necessary.
>
> This was a good idea but it's just that dependency issue we want to stay
away from. Covoar has something to find the build directory too, it just
hasn't been connected up yet, so running it from the top of the build
directory is ok for the moment.

Probably the most pressing thing now is investigating those mismatch in
symbol size.

> This way we can parse all the symbols from the same ini file.
>
> what needs to be done :
>
>- I have added #FIXME s in the code , those are the small fixes that
>would be needed .
>- The covoar needs to be updated. My proposal is that we can feed the
>parsed  dict to the covoar instead of feeding the symbol file and
>letting
>covoar parse it ( As I mentioned previously).
>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSoC] Ways to make the x86_64 port work with UEFI

[Joel Sherrill]

On Sun, May 20, 2018, 12:10 PM Amaan Cheval  wrote:

> On Sat, May 19, 2018 at 6:51 PM, Gedare Bloom  wrote:
> > On Fri, May 18, 2018 at 5:53 PM, Joel Sherrill  wrote:
> >>
> >>
> >> On Fri, May 18, 2018 at 3:24 PM, Amaan Cheval 
> >> wrote:
> >>>
> >>> Hi everyone!
> >>>
> >>> I've written a quick blog post summarizing the options I've considered
> >>> to make the x86_64 port work with UEFI firmware - the primary winner
> >>> seems to be in my eyes to use "gnu-efi" and to add support for the
> >>> target "pei-x86-64" (aliased to "efi-app-x86_64") to
> >>> "x86_64-rtems5-objcopy" in binutils. I've submitted a patch for this
> >>> here[1].
> >>
> >>
> >> That patch is quite simple so shouldn't be a problem if this is the
> >> direction
> >> that gets consensus.
> >>>
> >>>
> >>> The blog post is here:
> >>> https://blog.whatthedude.com/post/uefi-app-options/
> >>>
> >>> I'd appreciate all feedback (and please do let me know if I haven't
> >>> provided enough context)!
> >>>
> >>> Specifically, some concerns I'd like to discuss are:
> >>>
> >>> - Does everyone agree with me on choosing gnu-efi + objcopy as our
> >>> method of choice?
> >>
> >>
> >> Does using gnu-efi add code that runs on the target? Can you point
> >> us to the files, if so.
>
> Sure. The files would run on the target, yes. These are the ones
> listed here (as linked to in my blog post, perhaps without sufficient
> emphasis):
> https://wiki.osdev.org/UEFI#Developing_with_GNU-EFI
>
> >>
> >> Can you tell which approach FreeBSD takes?
>
> FreeBSD takes the gnu-efi approach I see as the "winner" here (also a
> link in the post):
>
> https://github.com/freebsd/freebsd/blob/996b0b6d81cf31cd8d58af5d8b45f0b4945d960d/stand/efi/loader/Makefile#L98-L1
> 


This is (no surprise) appropriately licensed and IMO the winning solution.
Knowing it is what FreeBSD does makes it an easy choice.

A comment in the readme mentions there is a i386 version of this code so
that could be used to let pc386 boot from UEFI.


>
> >>
> >>>
> >>> - How do we integrate gnu-efi into our build process? A part of the
> >>> RSB, making sure the path to the libraries are in an exported
> >>> variable? Or perhaps a part of the RTEMS kernel itself if the licenses
> >>> are compatible (I don't see any on the project[2], only copyright
> >>> notices within the source files of the release versions).
> >>
> >>
> >> GNU-efi would be built like qemu or the device tree compiler would
> >> be my guess and x86_64-rtems toolset might add that to the standard
> >> set of tools. License on host tools being GPL isn't an issue.
> >>
> >
> > It appears to be a standard 2-clause BSD released by Intel as
> > specified in the README file of gnu-efi.
> >
> >>
> >>>
> >>> - Regardless of how we manage UEFI, do we require Multiboot support
> >>> too? Multiboot drops us in a 32-bit protected mode environment,
> >>> whereas 64-bit UEFI firmware will boot us into 64-bit long mode - this
> >>> would mean the kernel would need to support separate code-paths for
> >>> the 2 if we want to support both methods.
> >>
> >>
> >> That's a good question. For GSoC, I think UEFI is fine and perhaps a
> ticket
> >> under the general "modern PC support" ticket for multiboot support.
> Unless
> >> that eliminates a LOT of PCs.
> >>
> >> I don't want you to spend all summer getting an image to boot both
> >> ways. Personally, I want you to have a working BSP one way. :)
> > +1
> >
>
> Noted, thanks!
>
> >>>
> >>>
> >>> [1] https://www.sourceware.org/ml/binutils/2018-05/msg00197.html
> >>> [2] https://sourceforge.net/projects/gnu-efi/
> >>
> >>
> >> --joel
> >>
> >> ___
> >> devel mailing list
> >> devel@rtems.org
> >> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSoC] Ways to make the x86_64 port work with UEFI

[Amaan Cheval]

On Sat, May 19, 2018 at 6:51 PM, Gedare Bloom  wrote:
> On Fri, May 18, 2018 at 5:53 PM, Joel Sherrill  wrote:
>>
>>
>> On Fri, May 18, 2018 at 3:24 PM, Amaan Cheval 
>> wrote:
>>>
>>> Hi everyone!
>>>
>>> I've written a quick blog post summarizing the options I've considered
>>> to make the x86_64 port work with UEFI firmware - the primary winner
>>> seems to be in my eyes to use "gnu-efi" and to add support for the
>>> target "pei-x86-64" (aliased to "efi-app-x86_64") to
>>> "x86_64-rtems5-objcopy" in binutils. I've submitted a patch for this
>>> here[1].
>>
>>
>> That patch is quite simple so shouldn't be a problem if this is the
>> direction
>> that gets consensus.
>>>
>>>
>>> The blog post is here:
>>> https://blog.whatthedude.com/post/uefi-app-options/
>>>
>>> I'd appreciate all feedback (and please do let me know if I haven't
>>> provided enough context)!
>>>
>>> Specifically, some concerns I'd like to discuss are:
>>>
>>> - Does everyone agree with me on choosing gnu-efi + objcopy as our
>>> method of choice?
>>
>>
>> Does using gnu-efi add code that runs on the target? Can you point
>> us to the files, if so.

Sure. The files would run on the target, yes. These are the ones
listed here (as linked to in my blog post, perhaps without sufficient
emphasis):
https://wiki.osdev.org/UEFI#Developing_with_GNU-EFI

>>
>> Can you tell which approach FreeBSD takes?

FreeBSD takes the gnu-efi approach I see as the "winner" here (also a
link in the post):
https://github.com/freebsd/freebsd/blob/996b0b6d81cf31cd8d58af5d8b45f0b4945d960d/stand/efi/loader/Makefile#L98-L119

>>
>>>
>>> - How do we integrate gnu-efi into our build process? A part of the
>>> RSB, making sure the path to the libraries are in an exported
>>> variable? Or perhaps a part of the RTEMS kernel itself if the licenses
>>> are compatible (I don't see any on the project[2], only copyright
>>> notices within the source files of the release versions).
>>
>>
>> GNU-efi would be built like qemu or the device tree compiler would
>> be my guess and x86_64-rtems toolset might add that to the standard
>> set of tools. License on host tools being GPL isn't an issue.
>>
>
> It appears to be a standard 2-clause BSD released by Intel as
> specified in the README file of gnu-efi.
>
>>
>>>
>>> - Regardless of how we manage UEFI, do we require Multiboot support
>>> too? Multiboot drops us in a 32-bit protected mode environment,
>>> whereas 64-bit UEFI firmware will boot us into 64-bit long mode - this
>>> would mean the kernel would need to support separate code-paths for
>>> the 2 if we want to support both methods.
>>
>>
>> That's a good question. For GSoC, I think UEFI is fine and perhaps a ticket
>> under the general "modern PC support" ticket for multiboot support. Unless
>> that eliminates a LOT of PCs.
>>
>> I don't want you to spend all summer getting an image to boot both
>> ways. Personally, I want you to have a working BSP one way. :)
> +1
>

Noted, thanks!

>>>
>>>
>>> [1] https://www.sourceware.org/ml/binutils/2018-05/msg00197.html
>>> [2] https://sourceforge.net/projects/gnu-efi/
>>
>>
>> --joel
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Vijay Kumar Banerjee]

On 20 May 2018 at 00:53, Vijay Kumar Banerjee 
wrote:

>
>
> On Sun, 20 May 2018, 00:45 Cillian O'Donnell, 
> wrote:
>
>> It works.. Sorry I was using the right covoar but the wrong rtems-test.
>> Ahh its nice to see the data back in the reports again. Did you manage to
>> track down 2 exes with the mismatch in symbol size?
>>
> Great! so next is the parsing of the symbol file.
> I couldn't manage to track down the mismatch.
>
> I have pushed these to my master branch.

The latest update to cov-tester-support branch (please have a look)
parses the symbol-set ini file from the coverage script. The parsing
is working but currently it's not generating reports, as covoar
needs to be updated .
Here are the things that I have done and that needs to be
done in order to generate reports :

I have added a symbol-sets.ini file and parsed it from the coverage script
this is how it works :


   - The ini file can be updated with all the symbols, separated by ' , '
   (comma)
   - The coverages splits them and makes a list of all the sets
   -  The respective libraries are parsed from the libraries section.
   - It returns a dict with all the symbols and thir resp. library
   addresses.
   - The library addresses are absolute so it can be run from anywhere
   top of build tree is not necessary.

This way we can parse all the symbols from the same ini file.

what needs to be done :

   - I have added #FIXME s in the code , those are the small fixes that
   would be needed .
   - The covoar needs to be updated. My proposal is that we can feed the
   parsed  dict to the covoar instead of feeding the symbol file and
   letting
   covoar parse it ( As I mentioned previously).
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel