Re: Device Tree Blob for Beaglebone Black?

[Christian Mauderer]

On 26/02/2020 22:12, Amar Takhar wrote:
> On 2020-02-26 18:46 +0100, Christian Mauderer wrote:
>> Hello Amar,
>>
>> somehow I missed your response this morning. My filter for the mailing
>> list normally keeps stuff with my name in the inbox but your answer
>> didn't contain it and therefore it was hidden in the mailing list folder.
> 
> No problem! :)
> 
> 
>> Full acknowledge. I'm not a fan of another repository like I already
>> said toward Chris. On the other hand: We already have that problem and
>> have to deal with it sometimes anyway. I added a note in the response
>> toward Chris that we maybe sometimes should think about a master
>> repository with sub-repos to make the version dependencies more clear.
>> In other words: One repository to rule them all ;-)
> 
> We can for sure create a sub repository to handle this.  That can be annoying 
> however if the sub repositories don't update often because git pull can take 
> a 
> while.

It's just another problem that I noted sometimes on the mailing list
with RTEMS and libbsd: Sometimes libbsd doesn't compile with some odd
error messages like unresolved symbols. Most of the time the problem is
that libbsd has been updated by the user but RTEMS hasn't. Having
defined versions in a master repository could help the average user to
see which version should be used together. On the other hand someone
would have to keep it up to date and I'm not sure whether all
maintainers would be happy about another necessary maintainance task.
Therefore it's not yet a well thought through idea.

> 
> The other option here is to just document for the user how to do a 'git 
> submodule add' and do it themselves within the RTEMS tree or a separate 
> repository it would depend on just how much demand there would be for this.  
> It's not a huge deal though to detect if the FDT repository is in-tree 
> otherwise 
> force a --with-fdt-repo.
> 
> 
> 
>>> We don't really have a choice here however I would 
>>> suggest we do a mix of the two.
>>>
>>
>> I'm not sure whether that is a very transparent approach.
> 
> Transparent or complicated?  :)  It will still all be documented and out in 
> the 
> open.
> 

If you are a new user and see "for this BSP use the FDT from X" but you
want to use some other BSP and someone tells you "for that BSP the FDT
isn't in X but at Y" it maybe isn't really that clear. Therefore - if we
introduce some handling - I would be in favor of only one location and
not a mix of two or three. Otherwise the situation is only slightly
better than now.

> 
>>>   1. Any source/permissive files be kept within the RTEMS repository.
>>>   2. Binary blobs get ejected to a separate repository lets say 'rtems-fdt'.
>>>   3. Source files with strict licensing gets the boot, too -- though we can 
>>>  discuss how much we care about this.
>>
>> I think we will get big problems finding "permissive" licenses. Most
>> device trees are Linux based and therefore GPL. Even the ones in FreeBSD.
> 
> Okay well if they're all GPL then instead of permissive just say source-based 
> because that is still far better than binary blobs.  It will still be left up 
> to 
> the user if they want to include it the license won't change whether it's in 
> tree 
> our outside.
> 
>>>
>>> How it would work is simple.  During configure if the required FDT files 
>>> exist 
>>> that's great we look for the two binaries we need and build them all as 
>>> part of 
>>> the normal building process.
>>
>> That would add dtc to our mandatory set of tools for RTEMS. Otherwise
>> nothing against it.
> 
> It would for BSPs that have it and if users want it.  Otherwise if there is 
> no 
> FDT then we wouldn't require those tools.
> 
> 
>> There is even a case 5: We have a FDT (for example for BBB) but the user
>> wants to use an adapted one because he has connected extra peripherals
>> or has a board that is only based on the evaluation board. Our build
>> system should be open enough to handle such a case.
>>
>> The FreeBSD FDT scripts work fine for that. You give them your file and
>> the path to the FreeBSD fdt sources and they do the rest.
> 
> Yes that adds yet another option letting users supply their own files.  I 
> should 
> have added that one thank you.
> 
> 
>> Agreed: Open BSPs are first class citizens.
> 
> Awesome I'm glad we agree on that! :)
> 
> 
> Amar.
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
> 

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
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: [PATCH 0/1] [bsp/pc386] Fix --enable-rtems-debug

[Sebastian Huber]

On 25/02/2020 14:07, Jan Sommer wrote:

Hello,

I just noticed that the patch with the suggestions from Joel
(https://lists.rtems.org/pipermail/users/2019-April/033151.html) never made it 
into the repository.

Since I have now git send-email configured, here it is again.


Thanks, I checked it in.

--
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: Build Linux: PASSED 5/rtems-arm on x86_64-linux-gnu

[Sebastian Huber]

On 27/02/2020 07:38, Chris Johns wrote:

On 27/2/20 5:25 pm, Sebastian Huber wrote:

On 26/02/2020 23:15, Chris Johns wrote:

On 27/2/20 12:26 am, Sebastian Huber wrote:

On 26/02/2020 14:21,sebastian.hu...@embedded-brains.de   wrote:

RTEMS Source Builder Repository Status
    Remotes:
  1: origin:ssh://s...@dispatch.rtems.org/data/git/rtems-source-builder.git
  2:
main:g...@main.eb.localhost:eb/101-embedded-brains/oss/rtems-source-builder.git
  3:esa:g...@gitrepos.estec.esa.int:external/rtems-smp-qualification-rsb.git

Why are the remote repositories reported?

It provides the git environment being used. The report needs a repo and I am not
sure you can tell which is the source of branch programmatically.


I think we should remove this private and user-dependent information.

I have a specific repo I use for these types of publicly posted build ...

RTEMS Source Builder Repository Status
   Remotes:
     1: origin: git://git.rtems.org/rtems-source-builder.git
   Status:
    Clean
   Head:
    Commit: 14c5cb77132a3e66afab571afbf67dacad433ec3

The Status and Head are very important information. Which remote repositories
you use should be none of the business of the RTEMS Project. It can leak
business relationships and project names. We should not do this without asking
the user. I suggest to remove this part of the report.

I think the repo used is important information especially if someone is wanting
to replicate post results.


To replicate results all you need is the commit hash and the original 
report must show a clean status. If the commit hash is not included in 
the RTEMS repositories you can ask the reporter.


I think if a user requests to send a report and the status is not clean, 
then the RSB should stop with an error.


--
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: Build Linux: PASSED 5/rtems-arm on x86_64-linux-gnu

[Chris Johns]

On 27/2/20 5:25 pm, Sebastian Huber wrote:
> On 26/02/2020 23:15, Chris Johns wrote:
>> On 27/2/20 12:26 am, Sebastian Huber wrote:
>>> On 26/02/2020 14:21,sebastian.hu...@embedded-brains.de  wrote:
 RTEMS Source Builder Repository Status
    Remotes:
  1: 
 origin:ssh://s...@dispatch.rtems.org/data/git/rtems-source-builder.git
  2:
 main:g...@main.eb.localhost:eb/101-embedded-brains/oss/rtems-source-builder.git
  
 3:esa:g...@gitrepos.estec.esa.int:external/rtems-smp-qualification-rsb.git
>>> Why are the remote repositories reported?
>> It provides the git environment being used. The report needs a repo and I am 
>> not
>> sure you can tell which is the source of branch programmatically.
>>
>>> I think we should remove this private and user-dependent information.
>> I have a specific repo I use for these types of publicly posted build ...
>>
>> RTEMS Source Builder Repository Status
>>   Remotes:
>>     1: origin: git://git.rtems.org/rtems-source-builder.git
>>   Status:
>>    Clean
>>   Head:
>>    Commit: 14c5cb77132a3e66afab571afbf67dacad433ec3
> 
> The Status and Head are very important information. Which remote repositories
> you use should be none of the business of the RTEMS Project. It can leak
> business relationships and project names. We should not do this without asking
> the user. I suggest to remove this part of the report.

I think the repo used is important information especially if someone is wanting
to replicate post results.

Having posted resulted is really great and important so I do not wish to stop
this happening. It is your choice to post the the results from that repo and
posting is not enable by default.

As I said I have a separate machine I run the posted builds from and it is a
read-only copy of the repo. I can update the documentation to highlight this
happens.

You are unhappy and that is fair enough and I am ok with this so I suggest we
wait for others to provide feedback.

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

Re: Build Linux: PASSED 5/rtems-arm on x86_64-linux-gnu

[Sebastian Huber]

On 26/02/2020 23:15, Chris Johns wrote:

On 27/2/20 12:26 am, Sebastian Huber wrote:

On 26/02/2020 14:21,sebastian.hu...@embedded-brains.de  wrote:

RTEMS Source Builder Repository Status
   Remotes:
     1: origin:ssh://s...@dispatch.rtems.org/data/git/rtems-source-builder.git
     2:
main:g...@main.eb.localhost:eb/101-embedded-brains/oss/rtems-source-builder.git
     3:esa:g...@gitrepos.estec.esa.int:external/rtems-smp-qualification-rsb.git

Why are the remote repositories reported?

It provides the git environment being used. The report needs a repo and I am not
sure you can tell which is the source of branch programmatically.


I think we should remove this private and user-dependent information.

I have a specific repo I use for these types of publicly posted build ...

RTEMS Source Builder Repository Status
  Remotes:
1: origin: git://git.rtems.org/rtems-source-builder.git
  Status:
   Clean
  Head:
   Commit: 14c5cb77132a3e66afab571afbf67dacad433ec3


The Status and Head are very important information. Which remote 
repositories you use should be none of the business of the RTEMS 
Project. It can leak business relationships and project names. We should 
not do this without asking the user. I suggest to remove this part of 
the report.


--
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: Build Linux: PASSED 5/rtems-arm on x86_64-linux-gnu

[Chris Johns]

On 27/2/20 12:26 am, Sebastian Huber wrote:
> On 26/02/2020 14:21, sebastian.hu...@embedded-brains.de wrote:
>> RTEMS Source Builder Repository Status
>>   Remotes:
>>     1: origin:ssh://s...@dispatch.rtems.org/data/git/rtems-source-builder.git
>>     2:
>> main:g...@main.eb.localhost:eb/101-embedded-brains/oss/rtems-source-builder.git
>>     3: 
>> esa:g...@gitrepos.estec.esa.int:external/rtems-smp-qualification-rsb.git
> 
> Why are the remote repositories reported?

It provides the git environment being used. The report needs a repo and I am not
sure you can tell which is the source of branch programmatically.

> I think we should remove this private and user-dependent information.

I have a specific repo I use for these types of publicly posted build ...

RTEMS Source Builder Repository Status
 Remotes:
   1: origin: git://git.rtems.org/rtems-source-builder.git
 Status:
  Clean
 Head:
  Commit: 14c5cb77132a3e66afab571afbf67dacad433ec3

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

Re: Bump Newlib?

[Joel Sherrill]

On Wed, Feb 26, 2020 at 8:12 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 26/02/2020 14:53, Joel Sherrill wrote:
> > On Wed, Feb 26, 2020 at 6:10 AM Sebastian Huber
> >  > > wrote:
> >
> > On 25/02/2020 16:53, Joel Sherrill wrote:
> >  > Corinna just pushed my patch to resolve the newlib symlink on
> > MSYS2 issue.
> >  > I think Chris had found a way to work around this in the RSB.
> >  >
> >  > Anyway, there is at least one other patch of interest. Is it time
> to
> >  > bump the
> >  > newlib version?
> >
> > Yes, this would be good after changes like this.
> >
> >
> > Just to make sure only one of us works on this, are you planning to do
> it or
> > should I add it to my queue?
>
> Please add it to your queue.
>

Done. And building now. Hopefully it will complete before the morning.

--joel

>
> --
> 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: Device Tree Blob for Beaglebone Black?

[Amar Takhar]

On 2020-02-26 18:46 +0100, Christian Mauderer wrote:
> Hello Amar,
> 
> somehow I missed your response this morning. My filter for the mailing
> list normally keeps stuff with my name in the inbox but your answer
> didn't contain it and therefore it was hidden in the mailing list folder.

No problem! :)


> Full acknowledge. I'm not a fan of another repository like I already
> said toward Chris. On the other hand: We already have that problem and
> have to deal with it sometimes anyway. I added a note in the response
> toward Chris that we maybe sometimes should think about a master
> repository with sub-repos to make the version dependencies more clear.
> In other words: One repository to rule them all ;-)

We can for sure create a sub repository to handle this.  That can be annoying 
however if the sub repositories don't update often because git pull can take a 
while.

The other option here is to just document for the user how to do a 'git 
submodule add' and do it themselves within the RTEMS tree or a separate 
repository it would depend on just how much demand there would be for this.  
It's not a huge deal though to detect if the FDT repository is in-tree 
otherwise 
force a --with-fdt-repo.



> > We don't really have a choice here however I would 
> > suggest we do a mix of the two.
> > 
> 
> I'm not sure whether that is a very transparent approach.

Transparent or complicated?  :)  It will still all be documented and out in the 
open.


> >   1. Any source/permissive files be kept within the RTEMS repository.
> >   2. Binary blobs get ejected to a separate repository lets say 'rtems-fdt'.
> >   3. Source files with strict licensing gets the boot, too -- though we can 
> >  discuss how much we care about this.
> 
> I think we will get big problems finding "permissive" licenses. Most
> device trees are Linux based and therefore GPL. Even the ones in FreeBSD.

Okay well if they're all GPL then instead of permissive just say source-based 
because that is still far better than binary blobs.  It will still be left up 
to 
the user if they want to include it the license won't change whether it's in 
tree 
our outside.

> > 
> > How it would work is simple.  During configure if the required FDT files 
> > exist 
> > that's great we look for the two binaries we need and build them all as 
> > part of 
> > the normal building process.
> 
> That would add dtc to our mandatory set of tools for RTEMS. Otherwise
> nothing against it.

It would for BSPs that have it and if users want it.  Otherwise if there is no 
FDT then we wouldn't require those tools.


> There is even a case 5: We have a FDT (for example for BBB) but the user
> wants to use an adapted one because he has connected extra peripherals
> or has a board that is only based on the evaluation board. Our build
> system should be open enough to handle such a case.
> 
> The FreeBSD FDT scripts work fine for that. You give them your file and
> the path to the FreeBSD fdt sources and they do the rest.

Yes that adds yet another option letting users supply their own files.  I 
should 
have added that one thank you.


> Agreed: Open BSPs are first class citizens.

Awesome I'm glad we agree on that! :)


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

Re: Device Tree Blob for Beaglebone Black?

[Christian Mauderer]

Hello Amar,

somehow I missed your response this morning. My filter for the mailing
list normally keeps stuff with my name in the inbox but your answer
didn't contain it and therefore it was hidden in the mailing list folder.

On 26/02/2020 06:00, Amar Takhar wrote:
> 
> I've had to deal with this issue quite a lot in the past it can be really 
> annoying having to maintain separate repositories where we have to 'pin' a 
> version to the main repo. 

Full acknowledge. I'm not a fan of another repository like I already
said toward Chris. On the other hand: We already have that problem and
have to deal with it sometimes anyway. I added a note in the response
toward Chris that we maybe sometimes should think about a master
repository with sub-repos to make the version dependencies more clear.
In other words: One repository to rule them all ;-)

> We don't really have a choice here however I would 
> suggest we do a mix of the two.
> 

I'm not sure whether that is a very transparent approach.

> 
>   1. Any source/permissive files be kept within the RTEMS repository.
>   2. Binary blobs get ejected to a separate repository lets say 'rtems-fdt'.
>   3. Source files with strict licensing gets the boot, too -- though we can 
>  discuss how much we care about this.

I think we will get big problems finding "permissive" licenses. Most
device trees are Linux based and therefore GPL. Even the ones in FreeBSD.

> 
> How it would work is simple.  During configure if the required FDT files 
> exist 
> that's great we look for the two binaries we need and build them all as part 
> of 
> the normal building process.

That would add dtc to our mandatory set of tools for RTEMS. Otherwise
nothing against it.

> 
> If they are not found print a notice to the user to get the 'rtems-fdt' 
> repository and point to it with a --rtems-fdt-path=  This is where it gets 
> annoying because there are several steps to get the right file.  Generally we 
> have to:
> 
>   1. Read a file stored within RTEMS that says what version of the FDT 
>  repository to checkout.
>   2. As part of configure this file needs to be loaded and the 'rtems-fdt'
>  repository checked to see if it's at the right revision.
>   3. If it as not at the right revision then the user will have to fix this 
>  manually and re-run configure.
>   4. Some BSPs may not even have the FDT files until you purchase a board.  
> Do 
>  we have any of these cases?  Now we have a situation where we have no 
>  revision *or* files and no way to test this code or ensure it even works.

There is even a case 5: We have a FDT (for example for BBB) but the user
wants to use an adapted one because he has connected extra peripherals
or has a board that is only based on the evaluation board. Our build
system should be open enough to handle such a case.

The FreeBSD FDT scripts work fine for that. You give them your file and
the path to the FreeBSD fdt sources and they do the rest.

> 
> Regardless for case #4 it's going to be a user issue to get the FDT files and 
> our issue to suck these in.
> 
> It makes sense to do it this way for RTEMS as I don't see a reason to 
> "punish" 
> the BSPs where everything is free and open it would be great to have these 
> 'just 
> work' and it is less maintenance for us longterm.

Agreed: Open BSPs are first class citizens.

Best regards

Christian

> 
> 
> Amar.
> ___
> 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

RTEMS Open Class in Huntsville AL US May 11-15

[Joel Sherrill]

Joel Sherrill 
Mon, Jan 14, 2019, 9:30 AM
to rtems-de...@rtems.org
Hi

There will be an RTEMS Open Class in Huntsville Alabama the
week of May 11-15.

May 11 - Getting Started
May 11-15 - Open Class

Details and registration forms at http://rtems.com/trainingschedule.

If you have questions at all about the class, feel free to email me
directly.

Thanks.

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

Re: ticket #2970 Add ftw.h to newlib

[Joel Sherrill]

On Wed, Feb 26, 2020 at 9:06 AM Eshan Dhawan 
wrote:

> so the subtasks would consist of adding missing functions to stat.h ,
> types.h mainly I suppose
>

What do you think is missing in those? My reading of the POSIX standard has
is implying that
 includes  to get st_mode and the stat structure.

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/ftw.h.html

The subtasks I referred to as the same for every time a new C Library or
POSIX method
is added to RTEMS or Newlib:

+ the code itself
+ test code
+ addition to documentation as needed
+ update to compliance tracking spreadsheet (usually I will do this)

>
> - Eshan
>
> On Wed, Feb 26, 2020 at 7:30 PM Joel Sherrill  wrote:
>
>>
>>
>> On Wed, Feb 26, 2020 at 7:03 AM Eshan Dhawan 
>> wrote:
>>
>>> I wanted to know the status of implementation of ftw.h in newlib
>>> and the dependencies it requires?
>>>
>>
>> FIrst hint is that the ticket is still open. :)
>>
>> The next is a way to check if it is part of the installed C Library.
>> Wherever
>> you installed the tools (TOOLS_PREFIX) for CPU-rtems5
>>
>> find TOOLS_PREFIX -name ftw.h
>> CPU-rtems5-nm TOOLS_PREFIX/CPU-rtems5/lib/libc.a | grep ftw
>>
>> In this case, you will see it isn't there.
>>
>>
>>>
>>> As it could be ported from FreeBSD since it lies under favourable
>>> licence
>>>
>>
>> Yep. And this would almost certainly need to be merged into the newlib C
>> library
>> with tests added to RTEMS.
>>
>> Documentation added to the POSIX Users Guide and the tracking spreadsheet
>> updated.
>>
>> Just to list all the subtasks. :)
>>
>> --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: ticket #2970 Add ftw.h to newlib

[Eshan Dhawan]

so the subtasks would consist of adding missing functions to stat.h ,
types.h mainly I suppose

- Eshan

On Wed, Feb 26, 2020 at 7:30 PM Joel Sherrill  wrote:

>
>
> On Wed, Feb 26, 2020 at 7:03 AM Eshan Dhawan 
> wrote:
>
>> I wanted to know the status of implementation of ftw.h in newlib
>> and the dependencies it requires?
>>
>
> FIrst hint is that the ticket is still open. :)
>
> The next is a way to check if it is part of the installed C Library.
> Wherever
> you installed the tools (TOOLS_PREFIX) for CPU-rtems5
>
> find TOOLS_PREFIX -name ftw.h
> CPU-rtems5-nm TOOLS_PREFIX/CPU-rtems5/lib/libc.a | grep ftw
>
> In this case, you will see it isn't there.
>
>
>>
>> As it could be ported from FreeBSD since it lies under favourable licence
>>
>
> Yep. And this would almost certainly need to be merged into the newlib C
> library
> with tests added to RTEMS.
>
> Documentation added to the POSIX Users Guide and the tracking spreadsheet
> updated.
>
> Just to list all the subtasks. :)
>
> --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: Ticket #3515: covoar failure while running for full testsuites

[Joel Sherrill]

HI

I don't have an immediate answer but I have questions.

+ Is wait() in the Symbol Set the coverage analysis is supposed to include?

If so, this error is a side-effect of a normal execution case which
shouldn't
be an error. We are careful that an RTEMS exe only includes the minimum
symbols needed. This means that if a symbol is not needed, the linker leaves
it out. covoar is going to ask for information in the exe for every symbol
of
interest and some/many will not be in a particular exe. It should just
ignore
the "symbol not found in this exe" reported by the symbol lookup.

There is a bit of a degenerate case where the symbol is not in any exe.
This means that covoar has never actually seen an exe with the code in
it and thus cannot include it in the coverage reports. There is a special
report for methods with 0 coverage. They are just listed by name.

+ If wait() is not in the "symbols of interest", then I have no idea why
covoar is looking for it in the exe.

If it's the first case, then I expect integrating the new-ish use of
the ELF/DWARF library rather than executing nm and parsing the
output just missed this and whoever did it thought it was an error.

--joel

--joel

On Wed, Feb 26, 2020 at 1:06 AM Vijay Kumar Banerjee <
vijaykumar9...@gmail.com> wrote:

>
>
> On Wed, Feb 26, 2020 at 12:28 PM Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>>
>>
>> On Fri, Feb 21, 2020 at 1:27 PM Bran S  wrote:
>>
>>> On Wed, 19 Feb 2020 at 22:51, Vijay Kumar Banerjee
>>>  wrote:
>>> >
>>> >
>>> >
>>> > On Mon, Feb 17, 2020 at 12:08 AM Bran S  wrote:
>>> >>
>>> >> Hi Guys,
>>> >>
>>> > Hi Bran!
>>> >>
>>> >> I am trying to understand and solve Ticket #3515.
>>> >> https://devel.rtems.org/ticket/3515
>>> >>
>>> >> $ /home/user45/quick-start/rtems/5/share/rtems/tester/bin/covoar -
>>> >> -S
>>> /home/user45/quick-start/rtems/5/share/rtems/tester/rtems/testing/coverage/leon3-sis-symbols.ini
>>> >> -O leon3-sis-coverage -E
>>> >>
>>> /home/user45/quick-start/rtems/5/share/rtems/tester/rtems/testing/coverage/Explanations.txt
>>> >> -p RTEMS-5
>>> /home/user45/quick-start/build/b-leon3/sparc-rtems5/c/leon3/testsuites/fstests/fsclose01.exe
>>> >>
>>> >> The output of the above command is at:
>>> >> https://gist.github.com/archsbran/7834a931d52311c7b26842c6325d8d9a
>>> >>
>>> >> On the last line it can be seen that absence of `wait` symbol causes
>>> the error.
>>> >>
>>> >> I made some changes in ExecutableInfo.cc to print out the symbols
>>> >> being added into coverageMap.
>>> >> Added symbols can be seen from line 636 to 7236 at the above link.
>>> >> In those lines we can see that `wait` is not added into coverageMap.
>>> >>
>>> > Great work in finding the possible issue.
>>> >>
>>> >> I am new so the only thing I know about covoar is that it does
>>> >> coverage analysis.
>>> >> Any ideas on how to move further into solving this ?
>>> >
>>> > I added Chris in CC, he'll be able to tell us where to look for the
>>> source
>>> > of the error you found.
>>> > In general, you can follow covoar.cc file, which has the main `covoar`
>>> > function in it. That will be a good starting point.
>>> >
>>>
>>>
>>> Yeah, I traversed through the code in covoar.cc
>>>
>>> It goes something like:
>>>
>>> In covoar.cc: covar()
>>> at line 382: objdumpProcessor->load( exe, objdumpFile, err );
>>> Here, `exe` points to the executableinfo object, the one in which the
>>> coverageMap was created via createCoverageMap()
>>>
>>> Now inside objdumpProcessor->load()
>>> at line 301: finalizeSymbol() is called which further calls
>>> findCoverageMap() at line 35. This is the point where error occurs, as
>>> `wait` symbol is not found.
>>>
>>> Hi Bran,
>>
>> Sorry, I couldn't find time to look into the details and I was hoping
>> someone
>> else will join in. You are in the right direction and found the function
>> that is
>> getting the error. Now that you have a function to follow, I will suggest
>> you to
>> run gdb on covoar and follow this function, especially where it's getting
>> the
>> symbols.
>> To run covoar on gdb do the following:
>> $gdb /path/to/covoar
>> (gdb) r - -S
>> /home/lunatic/development/rtems/rtems-tools/tester/rtems/testing/coverage/leon3-qemu-symbols.ini
>>  \
>> -O leon3-qemu-coverage \
>> -E
>> /home/lunatic/development/rtems/rtems-tools/tester/rtems/testing/coverage/Explanations.txt
>> \
>> -p RTEMS-5 /your/exe.exe
>>
>> The above is just an example and you can adapt it according to your exe
> and bsp. Also, since you're using leon3-sis-coverage, please also add the
> option -fTSIM
>
>> set a breakpoint at findCoverageMap() and see what it is doing.
>> Most likely, you'll be able to see where is it getting other symbols
>> from and why is "wait" not there, or if it's there, why is it skipping it.
>>
>> Best regards,
>> Vijay
>>
>>> The objdumpProcessor->load() function searches symbols in
>>> CoverageMap(via finalizeSymbol()) according to the symbols present in
>>> objdump generated at
>>> li

Re: Bump Newlib?

[Sebastian Huber]

On 26/02/2020 14:53, Joel Sherrill wrote:
On Wed, Feb 26, 2020 at 6:10 AM Sebastian Huber 
> wrote:


On 25/02/2020 16:53, Joel Sherrill wrote:
 > Corinna just pushed my patch to resolve the newlib symlink on
MSYS2 issue.
 > I think Chris had found a way to work around this in the RSB.
 >
 > Anyway, there is at least one other patch of interest. Is it time to
 > bump the
 > newlib version?

Yes, this would be good after changes like this.


Just to make sure only one of us works on this, are you planning to do it or
should I add it to my queue?


Please add it to your queue.

--
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: ticket #2970 Add ftw.h to newlib

[Joel Sherrill]

On Wed, Feb 26, 2020 at 7:03 AM Eshan Dhawan 
wrote:

> I wanted to know the status of implementation of ftw.h in newlib
> and the dependencies it requires?
>

FIrst hint is that the ticket is still open. :)

The next is a way to check if it is part of the installed C Library.
Wherever
you installed the tools (TOOLS_PREFIX) for CPU-rtems5

find TOOLS_PREFIX -name ftw.h
CPU-rtems5-nm TOOLS_PREFIX/CPU-rtems5/lib/libc.a | grep ftw

In this case, you will see it isn't there.


>
> As it could be ported from FreeBSD since it lies under favourable licence
>

Yep. And this would almost certainly need to be merged into the newlib C
library
with tests added to RTEMS.

Documentation added to the POSIX Users Guide and the tracking spreadsheet
updated.

Just to list all the subtasks. :)

--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: Bump Newlib?

[Joel Sherrill]

On Wed, Feb 26, 2020 at 6:10 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 25/02/2020 16:53, Joel Sherrill wrote:
> > Corinna just pushed my patch to resolve the newlib symlink on MSYS2
> issue.
> > I think Chris had found a way to work around this in the RSB.
> >
> > Anyway, there is at least one other patch of interest. Is it time to
> > bump the
> > newlib version?
>
> Yes, this would be good after changes like this.
>

Just to make sure only one of us works on this, are you planning to do it or
should I add it to my queue?

--joel


>
> --
> 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: Build Linux: PASSED 5/rtems-arm on x86_64-linux-gnu

[Sebastian Huber]

On 26/02/2020 14:21, sebastian.hu...@embedded-brains.de wrote:

RTEMS Source Builder Repository Status
  Remotes:
1: origin:ssh://s...@dispatch.rtems.org/data/git/rtems-source-builder.git
2: 
main:g...@main.eb.localhost:eb/101-embedded-brains/oss/rtems-source-builder.git
3: esa:g...@gitrepos.estec.esa.int:external/rtems-smp-qualification-rsb.git


Why are the remote repositories reported? I think we should remove this 
private and user-dependent information.


--
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

ticket #2970 Add ftw.h to newlib

[Eshan Dhawan]

I wanted to know the status of implementation of ftw.h in newlib
and the dependencies it requires?

As it could be ported from FreeBSD since it lies under favourable licence
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Bump Newlib?

[Sebastian Huber]

On 25/02/2020 16:53, Joel Sherrill wrote:

Corinna just pushed my patch to resolve the newlib symlink on MSYS2 issue.
I think Chris had found a way to work around this in the RSB.

Anyway, there is at least one other patch of interest. Is it time to 
bump the

newlib version?


Yes, this would be good after changes like this.

--
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: Project query #2920

[Joel Sherrill]

On Wed, Feb 26, 2020, 2:06 AM Anmol Mishra  wrote:

> Hello, My name is Anmol, I am a Google Summer of Code, Student developer
> aspirant for 2020.
> I have completed the Hello-world task.
>
> I am interested in Ticket #2920 i.e "Improve Coverage Analysis Toolset". I
> know that Dr. Joel is the owner and Dr. Gedare has reported it as per the
> information provided on the wiki page. Is there any mentor interested to
> mentor me for this project? I sincerely want to commit myself to this
> project and Is this project under high priority to be considered for GSoC?
>

It would likely be me as mentor. Former students who have worked on
coverage help out also.

I suggest looking at all the coverage tickets filed and back through this
mailing list for help in reproducing the bugs. There are a couple of bugs
and a few desired improvements.

--joel

>
>
> Best Regards
> Anmol
> ___
> 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: Coverity Scan broken?

[Sebastian Huber]

On 25/02/2020 21:51, Gedare Bloom wrote:

It's working for me. I see the results from Joel's recent run. Maybe
try again. The interface has been changed, and I don't see any results
for other projects (RTEMS-Newlib, RTEMS-Tools).


I don't see anything. I tried it with Firefox and Safari. I will try to 
add a new account.


--
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

RTEMS Tester possible issues

[Cláudio Maia]

Hello,

This email describes several possible issues related to RTEMS Tester and its 
documentation.

1- On the documentation page of RTEMS Tester 
(https://docs.rtems.org/branches/master/user/tools/tester.html) it is stated 
that one can use "sparc-rtems5-run" to execute/test programs compiled for SPARC 
architectures.
However, this command does not exist in the bin folder of the toolchain, and I 
believe that is not being built when building the toolchain executables (at 
least with the configurations that I am using). 
Is this command not being used any more?


2- Consequently, when executing the Tester with the following options (as 
suggested in Section 11.5.3): 

$ rtems-test --log=log_erc32_run --rtems-bsp=erc32-run --rtems-tools=$RTEMS/5 
./build/sparc-rtems5/c/erc32/testsuites/samples

I get the following error message for each of the tests (example for 
base_sp.exe):

error: run.cfg:70: execute failed: 
/opt/working-dir/rtems/5/bin/sparc-rtems5-run 
./build/sparc-rtems5/c/erc32/testsuites/samples/base_sp.exe: exit-code:2

However, if I modify the bsp from "erc32-run" to "erc32-sis", as follows: 

$ rtems-test  --log=log_erc32_run --rtems-bsp=erc32-sis --rtems-tools=$RTEMS/5 
./build/sparc-rtems5/c/erc32/testsuites/samples

all tests execute with success, as it is using the SIS simulator. 
This is an indicator that "--rtems-bsp=erc32-run" is using "sparc-rtems5-run" 
which is not being built (as explained in 1).


3- Oddly enough, when I execute the RTEMS Tester with "--rtems-bsp=erc32-run" 
as an option and using the "samples" folder as input, the minimum.exe passes 
the test without any error message. 
However, when executing the test alone, as follows:

$ rtems-test --log=log_erc32_run --rtems-bsp=erc32-run --rtems-tools=$RTEMS/5 
./build/sparc-rtems5/c/erc32/testsuites/samples/minimum.exe

the log shows the same error message (as below) but the test is marked as 
passed.

error: run.cfg:70: execute failed: 
/opt/working-dir/rtems/5/bin/sparc-rtems5-run 
./build/sparc-rtems5/c/erc32/testsuites/samples/minimum.exe: exit-code:2


4- The documentation mentions GDB in Section 11.5.3 "Select the erc32 BSP and 
use GDB." but no GDB instance is instantiated by default when running the 
tester and no GDB option appears in the help of "rtems-tester --help" command. 
Am I missing something here?


5- Now concerning ARM architectures, is there any equivalent procedure to 
cross-test executables for ARM architectures, as there is at the moment for 
SPARC (with SIS)? What is the purpose of "arm-rtems5-run"?

Regards,
Cláudio



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

[PATCH] score: Fix context switch extensions (SMP)

[Sebastian Huber]

In uniprocessor and SMP configurations, the context switch extensions
were called during _Thread_Do_dispatch():

void _Thread_Do_dispatch( Per_CPU_Control *cpu_self, ISR_Level level )
{
  Thread_Control *executing;

  executing = cpu_self->executing;

  ...
  do {
Thread_Control *heir;

heir = _Thread_Get_heir_and_make_it_executing( cpu_self );
...
_User_extensions_Thread_switch( executing, heir );
...
_Context_Switch( &executing->Registers, &heir->Registers );
...
  } while ( cpu_self->dispatch_necessary );
  ...
}

In uniprocessor configurations, this is fine and the context switch
extensions are called for all thread switches except the very first
thread switch to the initialization thread.  However, in SMP
configurations, the context switch may be invalidated and updated in the
low-level _Context_Switch() routine.  See:

  
https://docs.rtems.org/branches/master/c-user/symmetric_multiprocessing_services.html#thread-dispatch-details

In case such an update happens, a thread will execute on the processor
which was not seen in the previous call of the context switch
extensions.  This can confuse for example event record consumers which
use events generated by a context switch extension.

Fixing this is not straight forward.  The context switch extensions call
must move after the low-level context switch.  The problem here is that
we may end up in _Thread_Handler().  Adding the context switch
extensions call to _Thread_Handler() covers now also the thread switch
to the initialization thread.  We also have to save the last executing
thread (ancestor) of the processor.  Registers or the stack cannot be
used for this purpose.  We have to add it to the per-processor
information.  Existing extensions may be affected, since now context
switch extensions use the stack of the heir thread.  The stack checker
is affected by this.

Calling the thread switch extensions in the low-level context switch is
difficult since at this point an intermediate stack is used which is
only large enough to enable servicing of interrupts.

Update #3885.
---
 cpukit/include/rtems/score/percpu.h  |  7 +++
 cpukit/include/rtems/score/userextimpl.h |  6 ++
 cpukit/libmisc/stackchk/check.c  | 26 +++---
 cpukit/score/src/threadcreateidle.c  |  3 +++
 cpukit/score/src/threaddispatch.c|  5 +
 cpukit/score/src/threadhandler.c |  4 
 cpukit/score/src/userextaddset.c | 21 +
 testsuites/sptests/spextensions01/init.c |  4 
 8 files changed, 73 insertions(+), 3 deletions(-)

diff --git a/cpukit/include/rtems/score/percpu.h 
b/cpukit/include/rtems/score/percpu.h
index 7c95a9649a..31bc2b0bff 100644
--- a/cpukit/include/rtems/score/percpu.h
+++ b/cpukit/include/rtems/score/percpu.h
@@ -528,6 +528,13 @@ typedef struct Per_CPU_Control {
   struct _Thread_Control *idle_if_online_and_unused;
 } Scheduler;
 
+/**
+ * @brief The ancestor of the executing thread.
+ *
+ * This member is used by _User_extensions_Thread_switch().
+ */
+struct _Thread_Control *ancestor;
+
 /**
  * @brief Begin of the per-CPU data area.
  *
diff --git a/cpukit/include/rtems/score/userextimpl.h 
b/cpukit/include/rtems/score/userextimpl.h
index 8b456c072d..8c969e23c9 100644
--- a/cpukit/include/rtems/score/userextimpl.h
+++ b/cpukit/include/rtems/score/userextimpl.h
@@ -386,7 +386,11 @@ static inline void _User_extensions_Thread_switch(
 _ISR_lock_ISR_disable( &lock_context );
 _Per_CPU_Acquire( cpu_self, &lock_context );
 
+executing = cpu_self->ancestor;
+cpu_self->ancestor = heir;
 node = _Chain_Immutable_first( chain );
+
+if ( executing != heir ) {
 #endif
 
 while ( node != tail ) {
@@ -398,6 +402,8 @@ static inline void _User_extensions_Thread_switch(
 }
 
 #if defined(RTEMS_SMP)
+}
+
 _Per_CPU_Release( cpu_self, &lock_context );
 _ISR_lock_ISR_enable( &lock_context );
 #endif
diff --git a/cpukit/libmisc/stackchk/check.c b/cpukit/libmisc/stackchk/check.c
index eec3a911aa..0c859f6375 100644
--- a/cpukit/libmisc/stackchk/check.c
+++ b/cpukit/libmisc/stackchk/check.c
@@ -295,8 +295,8 @@ static void Stack_check_report_blown_task(
  *  rtems_stack_checker_switch_extension
  */
 void rtems_stack_checker_switch_extension(
-  Thread_Control *running RTEMS_UNUSED,
-  Thread_Control *heir RTEMS_UNUSED
+  Thread_Control *running,
+  Thread_Control *heir
 )
 {
   bool sp_ok;
@@ -306,6 +306,22 @@ void rtems_stack_checker_switch_extension(
   /*
*  Check for an out of bounds stack pointer or an overwrite
*/
+#if defined(RTEMS_SMP)
+  sp_ok = Stack_check_Frame_pointer_in_range( heir );
+
+  if ( !sp_ok ) {
+pattern_ok = Stack_check_Is_sanity_pattern_valid(
+  &heir->Start.Initial_stack
+);
+Stack_check_report_blown_task( heir, pattern_ok );
+  }
+
+  pattern_ok = Stack_check_Is_sanity_pattern_valid( 
&running->Start.Initial_stack );
+
+  if ( !pattern_o

Re: error in libtests dl06

[Sebastian Huber]

Hello,

On 26/02/2020 10:06, Eshan Dhawan wrote:

Hello
I was installing riscv from the latest rtems git
and make install showed error
this error was not before and is probably due to some merged patch


please delete your build tree and try to configure and build it again. 
There may be some issue with the dependency tracking in the build system.


--
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

error in libtests dl06

[Eshan Dhawan]

Hello
I was installing riscv from the latest rtems git
and make install showed error
this error was not before and is probably due to some merged patch

Makefile:8571: recipe for target 'dl06.pre' failed
make[5]: *** [dl06.pre] Error 1
make[5]: Leaving directory
'/home/eshan/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/libtests'
Makefile:663: recipe for target 'libtests' failed
make[4]: *** [libtests] Error 2
make[4]: Leaving directory
'/home/eshan/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites'
Makefile:1222: recipe for target 'testsuites' failed
make[3]: *** [testsuites] Error 2
make[3]: Leaving directory
'/home/eshan/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac'
Makefile:716: recipe for target 'install-recursive' failed
make[2]: *** [install-recursive] Error 1
make[2]: Leaving directory
'/home/eshan/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac'
Makefile:289: recipe for target 'install-recursive' failed
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory
'/home/eshan/development/rtems/kernel/rv32imac/riscv-rtems5/c'
Makefile:410: recipe for target 'install-recursive' failed
make: *** [install-recursive] Error 1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

AW: [PATCH v4 0/3] [rtems-libbsd] Fix compilation for amd64

[Jan.Sommer]

Are there any further comments regarding these patches?
Is the solution with the "path-mappings" acceptable or do you prefer something 
different?

Beste regards,

   Jan

> -Ursprüngliche Nachricht-
> Von: Sommer, Jan
> Gesendet: Dienstag, 18. Februar 2020 11:22
> An: devel@rtems.org
> Cc: Sommer, Jan
> Betreff: [PATCH v4 0/3] [rtems-libbsd] Fix compilation for amd64
> 
> Similar to the previous patchset for i386 this one enables compilation for the
> amd64 BSP with the following limitations:
> - dev_nic_e1000 needs to be off
> - debugger01.exe does not link because the amd64 bsp has no libdebugger
> support
> 
> I tried to use the lessons learned from the last patch set.
> It does not seem to affect arm, sparc and i386 compilation.
> Made a mistake and started to send with v3, so I will increment from
> there to keep consecutive numbers.
> 
> Version 4:
> - Added a path-mapping mechanism to waf_libbsd.py and libbsd.py
> - Removed the "if cpu == " switches from waf_libbsd.py
> 
> Best regards,
> 
> Jan
> 
> Jan Sommer (3):
>   amd64: Add missing files from FreeBSD
>   amd64: Add to build
>   amd64: Port to RTEMS
> 
>  freebsd/sys/amd64/amd64/in_cksum.c|  245 
>  freebsd/sys/amd64/include/machine/_bus.h  |   48 +
>  freebsd/sys/amd64/include/machine/cpufunc.h   | 1053 +
>  freebsd/sys/amd64/include/machine/efi.h   |   78 ++
>  freebsd/sys/amd64/include/machine/in_cksum.h  |   86 ++
>  freebsd/sys/amd64/include/machine/md_var.h|   90 ++
>  .../sys/amd64/include/machine/specialreg.h|6 +
>  freebsd/sys/sys/efi.h |  198 
>  libbsd.py |   25 +
>  rtemsbsd/amd64/include/machine/clock.h|2 +
>  waf_libbsd.py |   13 +-
>  11 files changed, 1842 insertions(+), 2 deletions(-)
>  create mode 100644 freebsd/sys/amd64/amd64/in_cksum.c
>  create mode 100644 freebsd/sys/amd64/include/machine/_bus.h
>  create mode 100644 freebsd/sys/amd64/include/machine/cpufunc.h
>  create mode 100644 freebsd/sys/amd64/include/machine/efi.h
>  create mode 100644 freebsd/sys/amd64/include/machine/in_cksum.h
>  create mode 100644 freebsd/sys/amd64/include/machine/md_var.h
>  create mode 100644 freebsd/sys/amd64/include/machine/specialreg.h
>  create mode 100644 freebsd/sys/sys/efi.h
>  create mode 100644 rtemsbsd/amd64/include/machine/clock.h
> 
> --
> 2.17.1

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

Re: Update to waf 2.0.19?

[Chris Johns]

> On 26 Feb 2020, at 6:05 pm, Sebastian Huber 
>  wrote:
>> On 26/02/2020 03:22, Chris Johns wrote:
>>> On 25/2/20 7:02 pm, Sebastian Huber wrote:
>>> Hello,
>>> 
>>> in order to close this bug:
>>> 
>>> https://devel.rtems.org/ticket/3569
>>> 
>>> I would like to update waf to the latest version 2.0.19 in:
>>> 
>>> rtems-docs
>>> rtems-tools
>>> rtems-libbsd
>>> rtems-examples
>>> 
>> What testing have you done and which hosts?
> 
> I haven't done a lot of testing. I tried to build everything on my Linux 
> machine. I checked also the rtems-tools on mingw64 and FreeBSD. I just hope 
> that the change from 2.0.18 to 2.0.19 fixed only bugs.

Thanks, this looks ok then. I suggest we do this and then see what happens. 
Thomas is responsive and that is a good thing. 

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

Project query #2920

[Anmol Mishra]

Hello, My name is Anmol, I am a Google Summer of Code, Student developer
aspirant for 2020.
I have completed the Hello-world task.

I am interested in Ticket #2920 i.e "Improve Coverage Analysis Toolset". I
know that Dr. Joel is the owner and Dr. Gedare has reported it as per the
information provided on the wiki page. Is there any mentor interested to
mentor me for this project? I sincerely want to commit myself to this
project and Is this project under high priority to be considered for GSoC?


Best Regards
Anmol
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel