from:"JohnS"

Hi RTEMS Community.

This email explains the Workflows and Merge Requests.

GitLab is will be open and accounts can be created from 12PM EST / 5PM GM.

The workflow is based around issues and merge requests. We use project forks as
the base of our workflow and outside of that there is no workflow we mandate.
What works for one task or work package may not work for another. Complex tasks
may affect a number of our GitLab Projects with issues and merge requests in a
number of projects. You may want to use an Epic to bring work together.

RTEMS will only accept changes via a Merge Request. This allows us to use the
Gitlab review and approval support which provides an easily accessible record of
the issue, code changes, and the reviews.

Workflows

With our GitLab instance, you fork a repo into your personal workspace and use
that to manage your changes. RTEMS will only accept changes via a Merge Request.
This allows us to use the Gitlab review and approval support which provides an
easily accessible record of the issue, code changes, and the reviews.

Issues and Merge Requests

Most merge requests will have a ticket however it is not always required.
Discussions can happen in merge requests and for simple isolated changes this is
fine.

Please do not use merge requests to introduce new code, concepts, styles or to
change existing behaviours such as APIs or internal interfaces. Please create an
issue before you start the work so the community is aware of the changes coming.
The merge requests can then focus on the details of the implementation and
approval does not need to be about approval of change at a functional level.

Merge Requests

1. We will work with forks of a project as we do not allow pushes to project
repos. This means you need to keep your forked project up to date.

https://docs.gitlab.com/ee/user/project/merge_requests/authorization_for_merge_requests.html#forking-workflow

2. If you are part of a team working on a change you can collaborate on merge
requests

https://docs.gitlab.com/ee/user/project/merge_requests/allow_collaboration.html

3. You work on a fork of a project under your namespace, e.g. my user name is
chris and my namespace is https://gitlab.rtems.org/chris.

4. GitLab enforces branch naming rules and provides branch naming patterns to
help

https://docs.gitlab.com/ee/user/project/repository/branches/index.html#prefix-branch-names-with-issue-numbers

5. You can create a merge from your fork:

https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html#when-you-work-in-a-fork

6. We do not normally squash merge requests. A merge request with more than one
commit should be buildable at each commit so a bisect of main does not
break.

If you need help please join the #gitlab-support channel on our Discord server.
You can find our invite link here https://www.rtems.org/discord. We will also
respond to posts on this list when we have the time.

Regards
Chris Johns
RTEMS GitLab Team
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

GitLab Workflows and Merge Requests

Hi RTEMS Community.

This email explains the Workflows and Merge Requests.

GitLab is will be open and accounts can be created from 12PM EST / 5PM GM.

Workflows

Issues and Merge Requests

Most merge requests will have a ticket however it is not always required.
Discussions can happen in merge requests and for simple isolated changes this is
fine.

Merge Requests

1. We will work with forks of a project as we do not allow pushes to project
repos. This means you need to keep your forked project up to date.

https://docs.gitlab.com/ee/user/project/merge_requests/authorization_for_merge_requests.html#forking-workflow

2. If you are part of a team working on a change you can collaborate on merge
requests

https://docs.gitlab.com/ee/user/project/merge_requests/allow_collaboration.html

3. You work on a fork of a project under your namespace, e.g. my user name is
chris and my namespace is https://gitlab.rtems.org/chris.

4. GitLab enforces branch naming rules and provides branch naming patterns to
help

https://docs.gitlab.com/ee/user/project/repository/branches/index.html#prefix-branch-names-with-issue-numbers

5. You can create a merge from your fork:

https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html#when-you-work-in-a-fork

6. We do not normally squash merge requests. A merge request with more than one
commit should be buildable at each commit so a bisect of main does not
break.

Regards
Chris Johns
RTEMS GitLab Team
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Issues in GitLab

Hi RTEMS Community.

This email explains RTEMS Issues in GitLab.

GitLab is will be open and accounts can be created from 12PM EST / 5PM GM.

All valid tickets in Trac have been brought across to GitLab. This is the fourth
move of this database and each move adds a layer of complexity as we align the
fields and data in the issues. We ask you to review issues in GitLab you are
working on or interested in long term and please make any suitable adjustments
if you think they are needed.  If you are curious we have gone from GNATS ->
Bugzilla -> Trac -> GitLab.

Trac Issues Import

Importing the Trac issues into GitLab was a complex time consuming task and
could not be done with GitLab launched and in use. As we could not bring the
Trac names across as the only accounts in GitLab were the RTEMS GitLab team. We
did not want to create user accounts and asking for user accounts to match
existing Trac accounts was difficult and fragile. The most pragmatic solution
was to strip the names we could not match.

Trac had a single issue database for all RTEMS projects and the projects shared
a single issue number. GitLab supports per-project issues with independent issue
numbers. We could not break up the single Trac database into the projects we
have in GitLab. As a result all Trac issues have been imported into the
RTOS/RTEMS project. The issue should have a label that details its origin.
Please do not move tickets from before #5004 from RTOS/RTEMS as it breaks the
history. Anything after RTOS/RTEMS issue #5004 can be moved.

New issues should be made in the related project, for example  make RSB tickets
in Tools/RTEMS Source Builder.

Issue Templates

We have basic issue and merge request templates located at
https://gitlab.rtems.org/rtems/gitlab-config/-/tree/main/.gitlab. The templates
will evolve as we learn to work with GitLab.

Assignee

We have imported all issues with the Assignee of “Trac Migrate”. If you have an
existing ticket in Trac and you would like to own the issue and its history in
GitLab please update the Assignee field. if the issue

Labels

GitLab only has labels so keywords and components have been consolidated as
labels. Please review existing issues in RTOS/RTEMS for examples on what to use.

If you need help please join the #gitlab-support channel on our Discord server.
You can find our invite link here https://www.rtems.org/discord. We will also
respond to posts on this list when we have the time.

Regards
Chris Johns
RTEMS GitLab Team
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Issues in GitLab

Hi RTEMS Community.

This email explains RTEMS Issues in GitLab.

GitLab is will be open and accounts can be created from 12PM EST / 5PM GM.

All valid tickets in Trac have been brought across to GitLab. This is the fourth
move of this database and each move adds a layer of complexity as we align the
fields and data in the issues. We ask you to review issues in GitLab you are
working on or interested in long term and please make any suitable adjustments
if you think they are needed.  If you are curious we have gone from GNATS ->
Bugzilla -> Trac -> GitLab.

Trac Issues Import

Importing the Trac issues into GitLab was a complex time consuming task and
could not be done with GitLab launched and in use. As we could not bring the
Trac names across as the only accounts in GitLab were the RTEMS GitLab team. We
did not want to create user accounts and asking for user accounts to match
existing Trac accounts was difficult and fragile. The most pragmatic solution
was to strip the names we could not match.

Trac had a single issue database for all RTEMS projects and the projects shared
a single issue number. GitLab supports per-project issues with independent issue
numbers. We could not break up the single Trac database into the projects we
have in GitLab. As a result all Trac issues have been imported into the
RTOS/RTEMS project. The issue should have a label that details its origin.
Please do not move tickets from before #5004 from RTOS/RTEMS as it breaks the
history. Anything after RTOS/RTEMS issue #5004 can be moved.

New issues should be made in the related project, for example  make RSB tickets
in Tools/RTEMS Source Builder.

Issue Templates

We have basic issue and merge request templates located at
https://gitlab.rtems.org/rtems/gitlab-config/-/tree/main/.gitlab. The templates
will evolve as we learn to work with GitLab.

Assignee

We have imported all issues with the Assignee of “Trac Migrate”. If you have an
existing ticket in Trac and you would like to own the issue and its history in
GitLab please update the Assignee field. if the issue

Labels

GitLab only has labels so keywords and components have been consolidated as
labels. Please review existing issues in RTOS/RTEMS for examples on what to use.

If you need help please join the #gitlab-support channel on our Discord server.
You can find our invite link here https://www.rtems.org/discord. We will also
respond to posts on this list when we have the time.

Regards
Chris Johns
RTEMS GitLab Team
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RTEMS Project Repos in GitLab

 using Tags. The “RTEMS Issues
in GitLab” email explains RTEMS’s issues in GitLab and how they have been
imported from Trac.

If you need help please join the #gitlab-support channel on our Discord server.
You can find our invite link here https://www.rtems.org/discord. We will also
respond to posts on this list when we have the time.

Regards
Chris Johns
RTEMS GitLab Team
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RTEMS Project Repos in GitLab

 using Tags. The “RTEMS Issues
in GitLab” email explains RTEMS’s issues in GitLab and how they have been
imported from Trac.

If you need help please join the #gitlab-support channel on our Discord server.
You can find our invite link here https://www.rtems.org/discord. We will also
respond to posts on this list when we have the time.

Regards
Chris Johns
RTEMS GitLab Team
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

RTEMS GitLab Sign In

Hi RTEMS Community.

GitLab is will be open and accounts can be created from 12PM EST / 5PM GM.

This email explains getting an account and signing onto GitLab.
We did not bring any of the existing accounts over to GitLab so you can create
and set up a new account that suits you. It also means we only end up with the
accounts for users who want access. Accounts are personal to you, we do not
allow shared accounts.

Creating an Account

To create an account head to our GitLab server at https://gitlab.rtems.org/ and
then click the “Register” link. If you happen to click “Sign In” click the
“Register now” link below the sign on in the “Don't have an account yet?” area.
The GitLab documentation on managing your Profile is
https://docs.gitlab.com/ee/user/profile/. You can use any email address and all
emails we send are personal emails to you.

Term of Service (TOS)

You will need to accept our TOS agreement for your account to be created. The
TOS covers code of conduct, contributed code licence and privacy policy. It also
covers your conduct if you are a code owner and approver.

Setting up 2FA and SSH key

We require you to use 2FA. A number of client apps should work. GitLab’s
documentation on 2FA is
https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html.
To clone a repo to make a merge request you will need to add an SSH key to your
account. The GitLab documentation to do this is
https://docs.gitlab.com/ee/user/ssh.html.

GitLab Roles

We have defined roles for the projects we have, for example GitLab
administrators, code owners, groups and approvers. We need accounts to complete
adding the roles we have in the project. If you have an existing role in the
RTEMS project, for example maintainer of an architecture, please make your
account and then please create an Administration issue detailing the roles you 
have

If you need help please join the #gitlab-support channel on our Discord server.
You can find our invite link here https://www.rtems.org/discord. We will also
respond to posts on this list when we have the time.

Regards
Chris Johns
RTEMS GitLab Team
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

RTEMS GitLab Sign In

Hi RTEMS Community.

GitLab is will be open and accounts can be created from 12PM EST / 5PM GM.

This email explains getting an account and signing onto GitLab.
We did not bring any of the existing accounts over to GitLab so you can create
and set up a new account that suits you. It also means we only end up with the
accounts for users who want access. Accounts are personal to you, we do not
allow shared accounts.

Creating an Account

To create an account head to our GitLab server at https://gitlab.rtems.org/ and
then click the “Register” link. If you happen to click “Sign In” click the
“Register now” link below the sign on in the “Don't have an account yet?” area.
The GitLab documentation on managing your Profile is
https://docs.gitlab.com/ee/user/profile/. You can use any email address and all
emails we send are personal emails to you.

Term of Service (TOS)

You will need to accept our TOS agreement for your account to be created. The
TOS covers code of conduct, contributed code licence and privacy policy. It also
covers your conduct if you are a code owner and approver.

Setting up 2FA and SSH key

We require you to use 2FA. A number of client apps should work. GitLab’s
documentation on 2FA is
https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html.
To clone a repo to make a merge request you will need to add an SSH key to your
account. The GitLab documentation to do this is
https://docs.gitlab.com/ee/user/ssh.html.

GitLab Roles

We have defined roles for the projects we have, for example GitLab
administrators, code owners, groups and approvers. We need accounts to complete
adding the roles we have in the project. If you have an existing role in the
RTEMS project, for example maintainer of an architecture, please make your
account and then please create an Administration issue detailing the roles you 
have

If you need help please join the #gitlab-support channel on our Discord server.
You can find our invite link here https://www.rtems.org/discord. We will also
respond to posts on this list when we have the time.

Regards
Chris Johns
RTEMS GitLab Team
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

GitLab Launch

2024-04-26 Thread Chris Johns

Hi RTEMS Community.

We will be launching GitLab during the 1st May 2024. You can access RTEMS GitLab
(RGL) at:

  https://gitlab.rtems.org/

Account creation will be enabled on the 1st May 2024.

The goal of the move to GitLab is to modernise our workflow reducing the burden
of merging patches into our project and making it easier to send in changes. We
are excited to accept merge requests in GitLab and we hope this brings more
people into the project and it encourages users to submit back to the project.

The move to Gitlab means we need to change our workflow. You will need a GitLab
account with 2FA and if you wish to create merge requests you will need to add
an SSH key. Additionally, some repos have changed names and the URL in any repos
you currently have cloned will need updating. The issues in Trac have been moved
to GitLab and may need review and updating.

The development list (devel*..) will no longer be used for patches. Any patches
are not merged from devel@ will need to be turned into a merge request to be
merged. Discussions about patches can happen in merge requests.

I will be sending the following emails to help explains the steps you need work
through and how things will work:

 1. Signing on to RTEMS GitLab
 2. RTEMS Project Repos in GitLab
 3. RTEMS Issues in GitLab
 4. Workflows and Merge Requests

These emails are an introduction. Our documentation is a work in progress and we
ask you to consider creating merge requests to update it if things are missing
or not clear. We welcome contributions from the community to get this work
completed. What we present at the beginning is a starting point.

With GitLab active we can finish some remaining server upgrade work. We will be
taking service2.rtems.org down to upgrade it. The server currently hosts Trac,
docs, mailman web, cgit and more. We were asked by OSU OSL, who host our
servers, to do this and it has taken us a couple of years to get to a point we
can. I would like to thank Lance at OSU OSL for his patience and understanding.
I personally appreciate this and I am sure the community does as well.

This is not the end of the server work we would like to do however it is the end
of the current funding. If you would like to donate to help support the server
work please reach out to Joel and I. The funding can be handled confidentially
if that is important. We need funding to improve the services we provide so
please consider helping.

Finally I would like to thank Amar for his hard work and diligence in bringing
this all together. I appreciate the hours you have put in. Awesome effort. I
would also like to thank Joel, Gedare and Kinsey for putting in the hours each
week over the past months to help make this happen.

If you need help please join the #gitlab-support channel on our Discord server.
It is open to posts and questions. You can find our invite link here
https://www.rtems.org/discord. We will also respond to posts on this list when
we have the time.

Regards
Chris Johns
RTEMS GitLab Team

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

GitLab Launch

2024-04-26 Thread Chris Johns

Hi RTEMS Community.

We will be launching GitLab during the 1st May 2024. You can access RTEMS GitLab
(RGL) at:

  https://gitlab.rtems.org/

Account creation will be enabled on the 1st May 2024.

The goal of the move to GitLab is to modernise our workflow reducing the burden
of merging patches into our project and making it easier to send in changes. We
are excited to accept merge requests in GitLab and we hope this brings more
people into the project and it encourages users to submit back to the project.

The move to Gitlab means we need to change our workflow. You will need a GitLab
account with 2FA and if you wish to create merge requests you will need to add
an SSH key. Additionally, some repos have changed names and the URL in any repos
you currently have cloned will need updating. The issues in Trac have been moved
to GitLab and may need review and updating.

The development list (devel*..) will no longer be used for patches. Any patches
are not merged from devel@ will need to be turned into a merge request to be
merged. Discussions about patches can happen in merge requests.

I will be sending the following emails to help explains the steps you need work
through and how things will work:

 1. Signing on to RTEMS GitLab
 2. RTEMS Project Repos in GitLab
 3. RTEMS Issues in GitLab
 4. Workflows and Merge Requests

These emails are an introduction. Our documentation is a work in progress and we
ask you to consider creating merge requests to update it if things are missing
or not clear. We welcome contributions from the community to get this work
completed. What we present at the beginning is a starting point.

With GitLab active we can finish some remaining server upgrade work. We will be
taking service2.rtems.org down to upgrade it. The server currently hosts Trac,
docs, mailman web, cgit and more. We were asked by OSU OSL, who host our
servers, to do this and it has taken us a couple of years to get to a point we
can. I would like to thank Lance at OSU OSL for his patience and understanding.
I personally appreciate this and I am sure the community does as well.

This is not the end of the server work we would like to do however it is the end
of the current funding. If you would like to donate to help support the server
work please reach out to Joel and I. The funding can be handled confidentially
if that is important. We need funding to improve the services we provide so
please consider helping.

Finally I would like to thank Amar for his hard work and diligence in bringing
this all together. I appreciate the hours you have put in. Awesome effort. I
would also like to thank Joel, Gedare and Kinsey for putting in the hours each
week over the past months to help make this happen.

If you need help please join the #gitlab-support channel on our Discord server.
It is open to posts and questions. You can find our invite link here
https://www.rtems.org/discord. We will also respond to posts on this list when
we have the time.

Regards
Chris Johns
RTEMS GitLab Team

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

[LincolnTalk] 10 x 10 Pop-up Tent no longer available

2024-04-25 Thread Sharon Johns via Lincoln

The Pop up tent has been taken in exchange for a donation to Dana- Farber 
Cancer Institute.
Thank you very much to the many people that were interested in supporting our 
DFMC fundraising efforts and contacted me about having the tent, but it is no 
longer available. 

Sharon & David Johns. 


Sent from my iPad
-- 
The LincolnTalk mailing list.
To post, send mail to Lincoln@lincolntalk.org.
Browse the archives at https://pairlist9.pair.net/mailman/private/lincoln/.
Change your subscription settings at 
https://pairlist9.pair.net/mailman/listinfo/lincoln.

Repo Transition to GitLab

2024-04-25 Thread Chris Johns

Hi RTEMS Community

The git repos on git.rtems.org are open and accepting patches. The GitLab repos
will move us to main, something we have been waiting to do. Allowing commits
into the repos means they will be brought across and played on top of the new
main branch. We have changes in the repo on GitLab as part of our testing and
new files such as CODEOWNERS.

As a result you will check out main and not rename your master to main.

Regards
Chris
RTEMS GitLab Team
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Cortex-M floating point (Was: RTEMS 6 branching)

2024-04-24 Thread Chris Johns

On 24/4/2024 10:37 pm, Cedric Berger wrote:
> Hello Sebastian,
> 
> On 23.04.2024 19:56, Sebastian Huber wrote:
>>> 1. Are all the things need for the release resolved? Tickets reviewed?
>> It would be nice to have the interrupt get/set priority API in RTEMS 6. The 
>> Cortex-M floating point issue is not yet fixed in the RTEMS master.
> 
> Do you have any feedback on the two patches that I posted on the ticket, which
> seems to fix the issue?

Thanks to everyone for responding. It seems clear the 6 branch will happen once
GitLab is launched. Once we launch the 6 milestone can be used with burndown and
burnup charts
(https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html)
to track the branch point.

I know I am getting ahead of myself but once we have GiLab running and you have
a patch you would like merged please make a merge request. If there is an issue
please make sure it is on the 6.1 milestone or create one and assign it to the
milestone.

In the meantime Amar and I will take a look at the release notes. We think these
can be based on a ChangeLog report created via the GitLab API. The wrinkle here
is the API needs a key and that of course cannot be exposed in commits.

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

Re: Cortex-M floating point (Was: RTEMS 6 branching)

2024-04-24 Thread Chris Johns

On 24/4/2024 10:37 pm, Cedric Berger wrote:
> Hello Sebastian,
> 
> On 23.04.2024 19:56, Sebastian Huber wrote:
>>> 1. Are all the things need for the release resolved? Tickets reviewed?
>> It would be nice to have the interrupt get/set priority API in RTEMS 6. The 
>> Cortex-M floating point issue is not yet fixed in the RTEMS master.
> 
> Do you have any feedback on the two patches that I posted on the ticket, which
> seems to fix the issue?

Thanks to everyone for responding. It seems clear the 6 branch will happen once
GitLab is launched. Once we launch the 6 milestone can be used with burndown and
burnup charts
(https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html)
to track the branch point.

I know I am getting ahead of myself but once we have GiLab running and you have
a patch you would like merged please make a merge request. If there is an issue
please make sure it is on the 6.1 milestone or create one and assign it to the
milestone.

In the meantime Amar and I will take a look at the release notes. We think these
can be based on a ChangeLog report created via the GitLab API. The wrinkle here
is the API needs a key and that of course cannot be exposed in commits.

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

Re: RTEMS 6 branching

2024-04-24 Thread Chris Johns

On 25/4/2024 12:06 am, Peter Dufault wrote:
>> On Apr 24, 2024, at 9:27 AM, Kinsey Moore  wrote:
>>
>> That use case definitely wasn't considered for rtems-lwip and I don't know 
>> that it's ever been discussed. If that were intended, I'd expect a "./waf 
>> uninstall" target to exist that would remove the installed network stack so 
>> that you could install a different one since the different stacks install 
>> vastly different sets of headers. IIRC, Chris advocates for installing the 
>> network libraries into a different location than the installed BSP to allow 
>> you to choose which you want at a later time.
>>
> 
> I've been moving a driver from legacy to bsd so I definitely need to easily 
> switch back and forth for the same BSP for testing.
> 
> I agree with Chris, but it's apparently a desirement, not a requirement, so 
> it shouldn't hold up the branching.

Agreed. It would be nice but is it something user would really want or use? I
get there are use cases like the one you raise but a single installed network
stack in a single install prefix makes it easier to write build system checks to
detect the type of stack. I have applications that can switch between legacy and
libbsd and that is important when migrating stacks and debugging.

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

RTEMS 6 branching

2024-04-20 Thread Chris Johns

Hi,

There has been some discussion about when we will branch and it is timely we
discuss this. This is my input. :)

While I create the releases I am not solely responsible for milestone dates or
thresholds for a release.

Please test the RC snaphots on our ftp server. Saying you have is as important
as reporting issues.

1. Are all the things need for the release resolved? Tickets reviewed?

2. The tickets are now in GitLab and locked down in Trac so how does that work
if we make a release now? I do not think it does.

3. GitLab is going to happen soon so do we take this moment in time and make 6
with GitLab and learn what we need to do easing dot releases that always follow?
If we do not we may end up with 6.1 and then 6.2 that has differences.

4. GitLab breaks the release scripts for the release notes (ChangeLog). Amar and
I have discussed a few options but we are yet to test and settle on anything. As
is the case with these things easy is often is a series of small things that
take time to get right.

5. Have the docs been reviewed for RTEMS 5 vs RTEMS 6 changes? Are they updated
for a separated legacy network stack, net services and waf building?

6. I have a few small patches to push and then an update to the RSB to pick
those changes up before I can create RC4.


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

Re: [PATCH] bsps/powerpc: Introduction of interrupt locks

2024-04-20 Thread Chris Johns

On 19/4/2024 6:12 pm, Christian MAUDERER wrote:
> it is tested on an MVME2500 which uses the powerpc/qoriq_e500 in an SMP
> configuration.

Great and thanks. I should have access next week to MVME2700 hardware and can
test it there. I doubt there will be an issue looking at the change but this
group of BSPs has had issues in the past, eg interrupts on some boards did not
work for over 10 years after a change, ie RTEMS 4.10 until 5.

I am OK to push the change and if I find anything I will raise it.

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

Re: RSB format changes to meet coding standard

2024-04-20 Thread Chris Johns

On 19/4/2024 7:15 pm, andrew.butterfi...@scss.tcd.ie wrote:
> Will you also do this with the formal code in rtems-central/formal ?

Sorry, I do not use it so would prefer not to update it just yet. I think it
best left to the leaders of that repo.

> I do remember using yapf at some point – I have no problem in your doing this 
> here.

Great.

> I expect to be proposing an update to the formal stuff
>  (models,code,documentation) over the Summer period as well.

Great and looking forward to see the results. We will be on GitLab soon and that
will help us all with merge requests as well as coordinating these activities,
for example GitLab has Epics.

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

RSB format changes to meet coding standard

2024-04-18 Thread Chris Johns

Hi,

I would like to run the python code we own through yapf and it's default to
standardise the formatting and to being it inline with the coding standards. It
would be good to do this before we branch for RTEMS 6.

I can crate a patch and post if required but it will be noise and doubt anyone
will review it, I would not. I will run builds etc to make sure the conversion
is clean.

Do I have permission to make the format change as a single commit and push it?

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

Re: [RFC] rtems: Add options to kernel output char handler

2024-04-18 Thread Chris Johns

On 18/4/2024 4:16 pm, Sebastian Huber wrote:
> On 18.04.24 04:02, Chris Johns wrote:
>> On 17/4/2024 11:06 pm, Sebastian Huber wrote:
>>> Make the kernel I/O output character device processing configurable
>>> through an option set parameter.  Add RTEMS_NO_OUTPUT and RTEMS_FLUSH
>>> options.  The goal of this API change is to enable flushing the kernel
>>> output device in the system termination process before a reset is
>>> issued.  A use case for using RTEMS_NO_WAIT is the polled processing of
>>> an input and output stream from and to the I/O device.
>>
>> Thanks for providing this overview.
>>
>> I am still confused about the differences in terms of why you would need the
>> RTEMS_NO_WAIT. Do you have a specific application where this is required? It
>> might help me understand the need for the change? Examples are need to reset 
>> in
>> a specific period, a test mode you are running in a system, etc?
> 
> The RTEMS_NO_WAIT can be used to process an input stream using getchark() and
> then send responses using a non-blocking output char variant. This helps to 
> have
> enough processing time and allows an overlapping send/receive.
> 
>>
>> Is this change for RTEMS 7?
> 
> Yes, this would be good.

Great, I think it is too late for 6.

>> In the context of the change:
>>
>> 1. RTEMS_FLUSH etc are too generic.
> 
> I added them to , so they could be reused in other
> directives. A bit less generic names could be:
> 
> * RTEMS_IO_FLUSH
> 
> * RTEMS_IO_DRAIN
> 
> * RTEMS_IO_NO_OUTPUT
> 

Sure, that is better.

> This would be in the IO namespace similar to RTEMS_EVENT_ANY and 
> RTEMS_EVENT_ALL.

Yeap

>> 2. The language used needs some work, maybe fewer "while"s. For example:
>>
>>   While the #RTEMS_NO_WAIT option is set in the option_set parameter, while
>>   the #RTEMS_NO_OUTPUT option is cleared in the option_set parameter, while
>>   the device can immediately accept a character for output, the character in
>>   out shall be hand over to the device for output.
>>
>> This is difficult to read and when it is probability easier to read the code 
>> it
>> is of questionable value. I appreciate it is not always easy to write but I 
>> feel
>> clarity would be a good to have here.
> 
> This is the documentation of a function pointer type, so there is no direct
> code. With three flags, you have to specify for eight variants what should
> happen. The wording is in EARS. It should be easy to translate this into code
> for a particular device.
> 
> https://docs.rtems.org/branches/master/eng/req/req-for-req.html#syntax

I think EARS is too specialised for RTEMS and here in this small isolated case.
If it was taught in first year undergrad courses and widely adopted it would be
a different. It is not used in RTEMS and starting here and now only makes this
piece of code harder to maintain.

>> Another example:
>>
>>   While no character is available in the device, a polled
>>   character input functions shall return minus one.
>>
>> It could be written as:
>>
>>   A polled character input function shall return a character if the device
>>   has successfully received one else the function returns minus one.
> 
> I would prefer the EARS variant. This function type should define requirements
> for the associated implementations.

I do not agree and until EARS is agreed to at the project level this will not
change.

>> I think receive and transmit is better than for example "be hand over to the
>> device for output", maybe "shall be transmitted by the device".
> 
> The name of this function type is BSP_output_char_function_type and not
> BSP_transmit_char_function_type, so I used "output" here and not "transmit".

The function outputs data, the device transmits. If the requirement is to output
the data it does not cover the transmission and the transmission is the
important part.

> Also, the character may not get immediately transmitted if FIFOs are involved
> (thus the need for the flush). Maybe my understanding of transmitted is wrong,
> but for me transmitting has something to do with signals on a medium.

I have never heard of a device that has data loaded into a FIFO to transmit has
a mode that transmits sooner or faster? I would have assumed outputting the data
to the FIFO would sent it. There is a distinct difference between output and
transmit and I would like to see the transmit aspect be specified and met.

>> 3. Flush needs to be worded in terms of successfully transmitted by the 
>> device
>> to avoid the case of data being written to the device

Re: [PATCH] bsps/powerpc: Introduction of interrupt locks

2024-04-17 Thread Chris Johns

Hi Vincenzo,

Welcome to RTEMS.

What hardware in the shared VME PowerPC family of BSPS has this change been
tested on?

Thanks
Chris

On 17/4/2024 5:34 pm, Vincenzo Calabretta wrote:
> Interrupt locks are introduced in shared vme device drivers to enable
> compilation in an SMP configuration of the qoriq BSP.
> ---
>  bsps/powerpc/shared/vme/vmeTsi148.c   | 44 ++-
>  bsps/powerpc/shared/vme/vmeUniverse.c | 40 +---
>  2 files changed, 45 insertions(+), 39 deletions(-)
> 
> diff --git a/bsps/powerpc/shared/vme/vmeTsi148.c 
> b/bsps/powerpc/shared/vme/vmeTsi148.c
> index aaabb1b28d..a6f0ac87ab 100644
> --- a/bsps/powerpc/shared/vme/vmeTsi148.c
> +++ b/bsps/powerpc/shared/vme/vmeTsi148.c
> @@ -545,16 +545,17 @@ vmeTsi148Reset(void)
>   vmeTsi148ResetXX(THEBASE);
>  }
>  
> +RTEMS_INTERRUPT_LOCK_DEFINE( static, vmeTsi148_lock, "vmeTsi148_lock" )
>  void
>  vmeTsi148ResetBusXX(BERegister *base)
>  {
> -unsigned long flags;
>  uint32_t  v;
> +rtems_interrupt_lock_context lock_context;
>  
> - rtems_interrupt_disable(flags);
> + rtems_interrupt_lock_acquire( &vmeTsi148_lock, &lock_context );
>   v = TSI_RD(base, TSI_VCTRL_REG);
>   TSI_WR(base, TSI_VCTRL_REG, v | TSI_VCTRL_SRESET);
> - rtems_interrupt_enable(flags);
> + rtems_interrupt_lock_release( &vmeTsi148_lock, &lock_context );
>  }
>  
>  void
> @@ -1410,7 +1411,8 @@ int
>  vmeTsi148IntRoute(unsigned int level, unsigned int pin)
>  {
>  int  i;
> -unsigned longmask, shift, mapreg, flags, wire;
> +unsigned longmask, shift, mapreg, wire;
> +rtems_interrupt_lock_context lock_context;
>  
>   if ( pin >= TSI_NUM_WIRES || ! tsi_wire[pin] || 
> !vmeTsi148IrqMgrInstalled )
>   return -1;
> @@ -1442,8 +1444,7 @@ unsigned long   mask, shift, mapreg, flags, wire;
>   /* wires are offset by 1 so we can initialize the wire table to all 
> zeros */
>   wire = (tsi_wire[pin]-1) << shift;
>  
> -rtems_interrupt_disable(flags);
> -
> + rtems_interrupt_lock_acquire( &vmeTsi148_lock, &lock_context );
>   for ( i = 0; i   wire_mask[i] &= ~mask;
>   }
> @@ -1453,7 +1454,7 @@ rtems_interrupt_disable(flags);
>   mask |= wire;
>   TSI_WR( THEBASE, mapreg, mask );
>  
> -rtems_interrupt_enable(flags);
> + rtems_interrupt_lock_release( &vmeTsi148_lock, &lock_context );
>   return 0;
>  }
>  
> @@ -1461,9 +1462,9 @@ VmeTsi148ISR
>  vmeTsi148ISRGet(unsigned long vector, void **parg)
>  {
>  VmeTsi148ISR   rval = 0;
> -unsigned long  flags;
>  volatile IRQEntry *p;
>  int   v = uni2tsivec(vector);
> +rtems_interrupt_lock_context lock_context;
>  
>  
>   if ( v < 0 )
> @@ -1471,13 +1472,13 @@ int   v = uni2tsivec(vector);
>  
>   p = irqHdlTbl + v;
>  
> - rtems_interrupt_disable(flags);
> + rtems_interrupt_lock_acquire( &vmeTsi148_lock, &lock_context );
>   if ( *p ) {
>   if ( parg )
>   *parg = (*p)->usrData;
>   rval = (*p)->isr;
>   }
> - rtems_interrupt_enable(flags);
> + rtems_interrupt_lock_release( &vmeTsi148_lock, &lock_context );
>  
>   return rval;
>  }
> @@ -1794,8 +1795,8 @@ vmeTsi148InstallISR(unsigned long vector, VmeTsi148ISR 
> hdl, void *arg)
>  {
>  IRQEntry  ip;
>  intv;
> -unsigned long  flags;
>  volatile IRQEntry *p;
> +rtems_interrupt_lock_context lock_context;
>  
>   if ( !vmeTsi148IrqMgrInstalled || (v = uni2tsivec(vector)) < 0 )
>   return -1;
> @@ -1808,14 +1809,14 @@ volatile IRQEntry *p;
>   ip->isr=hdl;
>   ip->usrData=arg;
>  
> - rtems_interrupt_disable(flags);
> + rtems_interrupt_lock_acquire( &vmeTsi148_lock, &lock_context );
>   if (*p) {
> - rtems_interrupt_enable(flags);
> + rtems_interrupt_lock_release( &vmeTsi148_lock, 
> &lock_context );
>   free(ip);
>   return -1;
>   }
>   *p = ip;
> - rtems_interrupt_enable(flags);
> + rtems_interrupt_lock_release( &vmeTsi148_lock, &lock_context );
>   return 0;
>  }
>  
> @@ -1824,22 +1825,22 @@ vmeTsi148RemoveISR(unsigned long vector, VmeTsi148ISR 
> hdl, void *arg)
>  {
>  int   v;
>  IRQEntry  ip;
> -unsigned long flags;
>  volatile IRQEntry *p;
> +rtems_interrupt_lock_context lock_context;
>  
>   if ( !vmeTsi148IrqMgrInstalled || (v = uni2tsivec(vector)) < 0 )
>   return -1;
>  
>   p = irqHdlTbl + v;
>  
> - rtems_interrupt_disable(flags);
> + rtems_interrupt_lock_acquire( &vmeTsi148_lock, &lock_context );
>   ip = *p;
>   if ( !ip || ip->isr!=hdl || ip->usrData!=arg ) {
> -

Re: [RFC] rtems: Add options to kernel output char handler

2024-04-17 Thread Chris Johns

On 17/4/2024 11:06 pm, Sebastian Huber wrote:
> Make the kernel I/O output character device processing configurable
> through an option set parameter.  Add RTEMS_NO_OUTPUT and RTEMS_FLUSH
> options.  The goal of this API change is to enable flushing the kernel
> output device in the system termination process before a reset is
> issued.  A use case for using RTEMS_NO_WAIT is the polled processing of
> an input and output stream from and to the I/O device.

Thanks for providing this overview.

I am still confused about the differences in terms of why you would need the
RTEMS_NO_WAIT. Do you have a specific application where this is required? It
might help me understand the need for the change? Examples are need to reset in
a specific period, a test mode you are running in a system, etc?

Is this change for RTEMS 7?

In the context of the change:

1. RTEMS_FLUSH etc are too generic.

2. The language used needs some work, maybe fewer "while"s. For example:

 While the #RTEMS_NO_WAIT option is set in the option_set parameter, while
 the #RTEMS_NO_OUTPUT option is cleared in the option_set parameter, while
 the device can immediately accept a character for output, the character in
 out shall be hand over to the device for output.

This is difficult to read and when it is probability easier to read the code it
is of questionable value. I appreciate it is not always easy to write but I feel
clarity would be a good to have here.

Another example:

 While no character is available in the device, a polled
 character input functions shall return minus one.

It could be written as:

 A polled character input function shall return a character if the device
 has successfully received one else the function returns minus one.

I think receive and transmit is better than for example "be hand over to the
device for output", maybe "shall be transmitted by the device".

3. Flush needs to be worded in terms of successfully transmitted by the device
to avoid the case of data being written to the device is held in FIFOs awaiting
transmission and reset is asserted. Maybe FLUSH is the wrong term because it is
so overloaded in what it means? An alternative could be
RTEMS_BSP_IO_TRANSMISSION_COMPLETE? And following on you could have
RTEMS_BSP_IO_NO_TRANSMISSION? The key point is "transmission" relates to the
external data pin of the interface.

Chris

> ---
>  cpukit/include/rtems/bspIo.h | 50 ++--
>  cpukit/include/rtems/rtems/options.h | 20 ++-
>  2 files changed, 67 insertions(+), 3 deletions(-)
> 
> diff --git a/cpukit/include/rtems/bspIo.h b/cpukit/include/rtems/bspIo.h
> index 31580cd800..09a3c47243 100644
> --- a/cpukit/include/rtems/bspIo.h
> +++ b/cpukit/include/rtems/bspIo.h
> @@ -10,7 +10,7 @@
>   */
>  
>  /*
> - * Copyright (C) 2020, 2021 embedded brains GmbH & Co. KG
> + * Copyright (C) 2020, 2024 embedded brains GmbH & Co. KG
>   * Copyright (C) 2015 On-Line Applications Research Corporation (OAR)
>   *
>   * Redistribution and use in source and binary forms, with or without
> @@ -58,6 +58,8 @@
>  #define _RTEMS_BSPIO_H
>  
>  #include 
> +#include 
> +#include 
>  #include 
>  
>  #ifdef __cplusplus
> @@ -89,8 +91,42 @@ extern "C" {
>   * @ingroup RTEMSAPIKernelCharIO
>   *
>   * @brief Polled character output functions shall have this type.
> + *
> + * @param out is the character to output.
> + *
> + * @param option_set is the option set.
> + *
> + * While the #RTEMS_NO_WAIT option is set in the option_set parameter, while
> + * the device cannot immediately accept a character for output, the character
> + * in out shall not be hand over to the device for output, optionally the
> + * device output shall be flushed, and ::RTEMS_UNSATISFIED shall be returned.
> + *
> + * While the #RTEMS_NO_OUTPUT option is set in the option_set parameter, the
> + * character in the out parameter shall not be handed over to the device for
> + * output.
> + *
> + * While the #RTEMS_NO_WAIT option is cleared in the option_set parameter,
> + * while the #RTEMS_NO_OUTPUT option is cleared in the option_set parameter,
> + * the character in the out parameter shall be hand over to the device for
> + * output.
> + *
> + * While the #RTEMS_NO_WAIT option is set in the option_set parameter, while
> + * the #RTEMS_NO_OUTPUT option is cleared in the option_set parameter, while
> + * the device can immediately accept a character for output, the character in
> + * out shall be hand over to the device for output.
> + *
> + * While the #RTEMS_FLUSH option is set in the option_set parameter, the 
> device
> + * output shall be flushed before the function returns.
> + *
> + * @retval ::RTEMS_SUCCESSFUL The requested operation was successful.
> + *
> + * @retval ::RTEMS_UNSATISFIED The device is was not ready to output a
> + *   character.
>   */
> -typedef void ( *BSP_output_char_function_type )( char );
> +typedef rtems_status_code ( *BSP_output_char_function_type )(
> +  char out,
> +  rtems_option option_set

Re: 6.1rc3 CentOS 7 Build Sweep Report

2024-04-17 Thread Chris Johns

On 18/4/2024 4:13 am, Joel Sherrill wrote:
> Hi
> 
> 6.1rc3 appears to be in pretty good shape on CentOS 7 (w/GCC 8 and Python 3
> SCL). Results should be on the build@ list. One odd issue appears to be in the
> rtems-tester.
> 
> Testing a riscv-bsp with spike, I get this output. It is repeated with other
> spike/risc-v bsp tests. Any ideas?
> 
> Exception in thread _stdout[spike]:
> Traceback (most recent call last):
>   File "/opt/rh/rh-python36/root/usr/lib64/python3.6/threading.py", line 916, 
> in
> _bootstrap_inner
>     self.run()
>   File "/opt/rh/rh-python36/root/usr/lib64/python3.6/threading.py", line 864, 
> in run
>     self._target(*self._args, **self._kwargs)
>   File "/home/joel/rtems-6.1rc3/tools/6/share/rtems/rtemstoolkit/execute.py",
> line 226, in _readthread
>     data = data.decode(sys.stdout.encoding)
> UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 0: 
> invalid
> start byte

The rtems-tools's execute.py needs to be updated to use an incremental decoder
codec. This also happened in the RSB and was fixed with:

https://git.rtems.org/rtems-source-builder/commit/source-builder/sb/execute.py?id=e04c84191b790b7bddd179bc67337e4205b61f8e

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

Re: Certificate of the documentation page expired yesterday

2024-04-13 Thread Chris Johns

Thanks, it should be fixed.

Chris

On 13/4/2024 12:41 am, Heinz Junkes wrote:
> Common Name (CN)
> docs.rtems.org
> Organisation (O)
> 
> Organisational Unit (OU)
> 
> Issued By
> Common Name (CN)
> R3
> Organisation (O)
> Let's Encrypt
> Organisational Unit (OU)
> 
> Validity Period
> Issued On
> Friday, 12 January 2024 at 20:02:57
> Expires On
> Thursday, 11 April 2024 at 21:02:56
> SHA-256 Fingerprints
> Certificate
> 9f6e41915a88f37a44627f92e459202504780eeab66109bfb4af1aa0f808ccc7
> Public key
> 8f203f1219335bee3b05d2a42e0e670e551cf7f69159463415a099580d8305fb
> 
> Heinz
> 
> 
> ___
> 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 v2 2/3] dev/serial: Add ZYNQ_UART_[01]_BASE_ADDR

2024-04-04 Thread Chris Johns




On 4/4/2024 8:19 pm, Sebastian Huber wrote:
> On 28.03.24 16:48, Kinsey Moore wrote:
>> This patch set looks good to me. I'd suggest a different file for the versal
>> unless there's a good name that can easily cover both.
> 
> The versal BSP doesn't use this driver and seems to have a different hardware
> UART interface. It uses a BSP-specific driver:
> 
> ./bsps/aarch64/xilinx-versal/include/dev/serial/versal-uart-regs.h
> ./bsps/aarch64/xilinx-versal/include/dev/serial/versal-uart.h
> ./bsps/aarch64/xilinx-versal/dev/serial/versal-uart-polled.c
> ./bsps/aarch64/xilinx-versal/dev/serial/versal-uart.c
> 
> I don't think we should mix these two currently independent drivers.
> 

Ah yes and thanks. I think the Versal UART is based on ARM IP that XIlinx has
modified. It is even worse to handle as the TX FIFO trigger does not work as
expected. It needs to have half the TX FIFO loaded before TX interrupts work.

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

Re: [PATCH rtems-source-builder 1/2] glib: Update to 2.56.4

2024-04-03 Thread Chris Johns

Looks good

Chris

On 6/3/2024 9:12 am, Kinsey Moore wrote:
> This updates glib to 2.56.4 for AArch64 build support.
> ---
>  bare/config/devel/glib-2.56.4-1.cfg| 30 ++
>  bare/config/devel/qemu-couverture.bset |  2 +-
>  bare/config/devel/qemu-xilinx.bset |  2 +-
>  bare/config/devel/qemu.bset|  2 +-
>  source-builder/config/glib-2-1.cfg |  1 +
>  5 files changed, 34 insertions(+), 3 deletions(-)
>  create mode 100644 bare/config/devel/glib-2.56.4-1.cfg
> 
> diff --git a/bare/config/devel/glib-2.56.4-1.cfg 
> b/bare/config/devel/glib-2.56.4-1.cfg
> new file mode 100644
> index 000..175b060
> --- /dev/null
> +++ b/bare/config/devel/glib-2.56.4-1.cfg
> @@ -0,0 +1,30 @@
> +#
> +# GLib
> +#
> +
> +%if %{release} == %{nil}
> +%define release 1
> +%endif
> +
> +%include %{_configdir}/base.cfg
> +
> +%define glib_version_major 2.56
> +%define glib_version_minor 4
> +%define glib_version   %{glib_version_major}.%{glib_version_minor}
> +
> +%hash sha256 glib-%{glib_version}.tar.xz 
> J/cD0SXvsH+KdDZmtYDfC0CVxZ/IdQ6IkBMskdQ3UEw=
> +
> +#
> +#Add patches to suppress null argument warning
> +#
> +
> +%patch add glib 
> https://devel.rtems.org/raw-attachment/ticket/4634/566e1d61a500267c7849ad0b2552feec9c9a29a6.patch
> +%hash sha512 566e1d61a500267c7849ad0b2552feec9c9a29a6.patch \
> +   
> ULwUKgmgGLAOlgsr09K2GdYVGm8yzffwWRGRZTi5B8KdMuyAE+Y0eFOAg2L77aVG3o14l6x9qNA1DH8uMYKOcw==
> +
> +#
> +# The GLib build instructions. We use 2.x.x Release 1.
> +#
> +%if !%{pkgconfig check glib-2.0} || %{defined _rsb_getting_source}
> + %include %{_configdir}/glib-2-1.cfg
> +%endif
> diff --git a/bare/config/devel/qemu-couverture.bset 
> b/bare/config/devel/qemu-couverture.bset
> index 60bec8e..69f6dfb 100644
> --- a/bare/config/devel/qemu-couverture.bset
> +++ b/bare/config/devel/qemu-couverture.bset
> @@ -21,6 +21,6 @@ devel/libiconv-1.14-1
>  devel/gettext-0.18.3.1-1
>  devel/libffi-3.0.13-1
>  devel/pixman-0.32.4-1
> -devel/glib-2.48.2-1
> +devel/glib-2.56.4-1
>  devel/dtc-1.6.1-1
>  devel/qemu-couverture-git-1
> diff --git a/bare/config/devel/qemu-xilinx.bset 
> b/bare/config/devel/qemu-xilinx.bset
> index 91b07e8..5bcbe2f 100644
> --- a/bare/config/devel/qemu-xilinx.bset
> +++ b/bare/config/devel/qemu-xilinx.bset
> @@ -20,5 +20,5 @@ devel/libiconv-1.14-1
>  devel/gettext-0.18.3.1-1
>  devel/libffi-3.0.13-1
>  devel/pixman-0.40.0-1
> -devel/glib-2.48.2-1
> +devel/glib-2.56.4-1
>  devel/qemu-xilinx-v2020.2-1
> diff --git a/bare/config/devel/qemu.bset b/bare/config/devel/qemu.bset
> index 3a9b0d5..7de2ca4 100644
> --- a/bare/config/devel/qemu.bset
> +++ b/bare/config/devel/qemu.bset
> @@ -20,5 +20,5 @@ devel/libiconv-1.14-1
>  devel/gettext-0.18.3.1-1
>  devel/libffi-3.0.13-1
>  devel/pixman-0.40.0-1
> -devel/glib-2.48.2-1
> +devel/glib-2.56.4-1
>  devel/qemu-5.2.0-1
> diff --git a/source-builder/config/glib-2-1.cfg 
> b/source-builder/config/glib-2-1.cfg
> index 09b43fa..5f80db0 100644
> --- a/source-builder/config/glib-2-1.cfg
> +++ b/source-builder/config/glib-2-1.cfg
> @@ -60,6 +60,7 @@ URL:   https://developer.gnome.org/glib/
>  --build=%{_build} --host=%{_host} \
>  --with-sysroot=$SYSROOT \
>  --disable-dtrace \
> +--enable-libmount=no \
>  --with-pcre=internal
>  
>%{_ld_library_path}=$SYSROOT/lib \
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [RSB PATCH] sb: Add sb-rtems-pkg to update the RTEMS package hashes and checksums

2024-04-03 Thread Chris Johns

On 4/4/2024 6:54 am, Kinsey Moore wrote:
> On Wed, Apr 3, 2024 at 2:11 PM Chris Johns  <mailto:chr...@rtems.org>> wrote:
> 
>> On 4 Apr 2024, at 3:52 am, Kinsey Moore > <mailto:kinsey.mo...@oarcorp.com>> wrote:
>> Looks fine overall. Minor nits:
>> "host" is set to "freebsd" and is never used.
> 
> The tool uses simhost so it could be any host listed in that module and it
> references that table. Nothing is built but needed to creat a build 
> object.
> Simhost is used to get all sources for all hosts. 
> 
> 
> I'm not referencing simhost. It's literally just an unused variable called
> "host" that gets set and never used.

Hmm Ok and thanks. I will take a closer look. I think it should be used.

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

Re: [RSB PATCH] sb: Add sb-rtems-pkg to update the RTEMS package hashes and checksums

2024-04-03 Thread Chris Johns

> On 4 Apr 2024, at 3:52 am, Kinsey Moore  wrote:
> 
> Looks fine overall. Minor nits:
> "host" is set to "freebsd" and is never used.

The tool uses simhost so it could be any host listed in that module and it 
references that table. Nothing is built but needed to creat a build object. 
Simhost is used to get all sources for all hosts. 

> Numeric indexes for repo config details are nice for brevity, but not for 
> readability.

I will add something. 

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

[RBW] Re: how wide of wheels and tires will a specialized seqoia handle

2024-04-03 Thread JohnS

Hello Bo,

I have an '82 Sequoia that I have RH 700 x 32 Stampede Pass tires mounted 
on Velocity Quill rims. Comfortable amount of clearance without fenders. I 
have not tired them with fenders since this is my naked road bike (no 
fenders nor racks). My Crust LB-canti is my fully dressed bike. I'm very 
happy with my Sequoia, nice neutral handling, smooth ride and descends 
well. FWIW, I've heard people on the 650B list like to convert the Sequoia 
to 650b, so 38 or even a 42 may fit. 

Good luck,
JohnS

On Wednesday, April 3, 2024 at 2:09:27 PM UTC-4 boru...@gmail.com wrote:

> there is a steel sequoia I am looking at remotely.
> the tires on it say 23mm and look narrow as knife blades
> there doesn't seem to be a lot of room beyond that 
> for wider wheels and tires.
>
> I bet there are 20 people on the list with experience 
> with this situation
>
> is the sequoia a good solution for someone hoping for
> 32s or at least 28s?
>
> fenders would be too much to hope for?
>
> thanks for the expertise
>
> Bo 
> Bellingham
>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/ad77850e-219c-462b-9b6d-3a606153b658n%40googlegroups.com.

Re: [Bugfix rtems-lwip 1/4] Fix definition of portTICK_RATE_MS

2024-04-02 Thread Chris Johns

On 1/4/2024 9:49 am, Bernd Moessner wrote:
> The FreeRTOS define portTICK_RATE_MS must represent the time in ms
> between two system ticks.
> ---
>  rtemslwip/xilinx/xlwipopts.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/rtemslwip/xilinx/xlwipopts.h b/rtemslwip/xilinx/xlwipopts.h
> index d915c3c..23b942f 100644
> --- a/rtemslwip/xilinx/xlwipopts.h
> +++ b/rtemslwip/xilinx/xlwipopts.h
> @@ -29,7 +29,7 @@
>  
>  /* These macros allow RTEMS to pretend to be FreeRTOS for Xilinx drivers */
>  #define tskIDLE_PRIORITY RTEMS_MAXIMUM_PRIORITY
> -#define portTICK_RATE_MS (rtems_clock_get_ticks_per_second() * 1000)
> +#define portTICK_RATE_MS (1000 / rtems_clock_get_ticks_per_second())

I do not know lwip but this macro is computing a constant at every location it
is used so I wonder if this could be a global value, eg:

--
extern const size_t rtems_portTICK_RATE_MS;
#define portTICK_RATE_MS rtems_portTICK_RATE_MS
--
const size_t rtems_portTICK_RATE_MS =
   (1000 / rtems_clock_get_ticks_per_second()) + 1;
--

?

Should the value be `+ 1` in case the tick is greater than 1msec?

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

Re: [RBW] Re: Question about rear brake cable housing routing with low friction on a Clem

2024-04-02 Thread JohnS

+1 for Universal Cycles, they are my go to for Jagwire cables, SRAM chains 
and other mundane parts that I use when rebuilding a bike. Also always 
impressed with the creative use of brake cable noodles. As I recall someone 
posted using one at the stem or some such.

JohnS


On Tuesday, April 2, 2024 at 8:35:53 AM UTC-4 Kim H. wrote:

> @Allan -
> I thank-you for sharing with me the details of how your 135 degree brake 
> noodle fits onto your rear brake cable housing. I appreciate it very much. 
> Thank-you for the noodle link, as well. Universal Cycles is relatively 
> close to me out of Oregon.
>
> Kim Hetzel.
>
> On Tuesday, April 2, 2024 at 3:48:57 AM UTC-7 Allan McLane wrote:
>
>> Kim,
>>
>> The photo shows how Riv arranged the cable housing guide braze-on on this 
>> bike, a Rosco Platypus. The entire housing slides through the braze-on and 
>> the end of the housing slips into the entrance of the noodle. It isn’t 
>> really necessary but I also slipped a short length of clear tubing around 
>> the outside of noodle about midway along, just to hold it off the seat tube 
>> paint.
>>
>> Here’s one source for that part:
>> https://www.universalcycles.com/shopping/product_details.php?id=205
>>
>> Allan in SE Vt
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/f2b9fc3c-31e8-4415-aa81-301325f24b4an%40googlegroups.com.

[RBW] Re: WTB 26" Front Wheel with Generator Hub

2024-03-30 Thread JohnS

Thank Ian for the links. I'm pressed by all the lighting options they have! 

JohnS


On Thursday, March 28, 2024 at 11:15:44 AM UTC-4 Ian A wrote:

> John,
>
> Since 2013,  have bought from bike24.de, rose.de and bike-discount.de in 
> Germany. All have been excellent.  My last order was in 2020 from Rose 
> Bike, when I couldn't find what I needed locally. Things have changed over 
> the past 10 years or so. There are quite a number of restrictions by 
> manufacturers as to what can leave the EU (in order to protect local North 
> America vendors, which makes good sense) and things like batteries now fall 
> under restrictions for dangerous cargo. Rose removed the cycle computer 
> from my order because of the single CR2032 battery couldn't be shipped 
> outside of the EU without extensive paperwork!
>
> Naturally, with this being the RBW list, look for local options first. 
> Maybe a list member is holding just what you are looking for. :)
>
> IanA Kitimat BC
> On Thursday, March 28, 2024 at 6:13:46 AM UTC-7 JohnS wrote:
>
>> Thank you Ian, the quality of the hub is something to consider. You 
>> mention ordering from German sites, is there one or two that you can 
>> recommend?
>>
>> JohnS
>>
>>
>> On Wednesday, March 27, 2024 at 5:39:10 PM UTC-4 Ian A wrote:
>>
>>> Just be aware that is a fairly low end dynamo in the Shimano range. 
>>> Slightly heavy and draggy in comparison to the higher end Shimano and SP 
>>> products.
>>>
>>> Some shopping around on the German sites might get you an SP hub or an 
>>> LX/XT hub built into a wheel. Shimano does have a restriction on allowing 
>>> the export of their products from Europe to North America. A complete wheel 
>>> might be excepted from the restriction. 
>>>
>>> I have bought a fair bit of stuff over the years (Tubus racks, B&M 
>>> lights, Brooks Saddles, Ortlieb panniers and handlebar bag, tires, spokes 
>>> and nipples etc) and quite a few of those items are now restricted for 
>>> export. Xxcycle in France doesn't seem to observe those restrictions (yet). 
>>> Maybe they do now,  my last order was while back.
>>>
>>> My main reason for ordering from Germany is because the economy shipping 
>>> option comes through the regular postal system and gets delivered by Canada 
>>> Post on this end. Canadian consumers will have horror stories of shipments 
>>> delivered via UPS and FedEx due to the brokerage fees for customs entry. 
>>> Also, shipping tends to be faster to Canada from Europe than from the USA. 
>>>
>>> IanA Deepest, darkest BC, Canada
>>> On Wednesday, March 27, 2024 at 1:59:09 PM UTC-7 JohnS wrote:
>>>
>>>>
>>>> Even better! And they have a ton of stuff on sale, so I could add 
>>>> socks, gloves or a jersey to the box and won't impact the shipping.
>>>>
>>>> JohnS
>>>>
>>>> On Wednesday, March 27, 2024 at 4:42:39 PM UTC-4 mathiass...@gmail.com 
>>>> wrote:
>>>>
>>>>>  >> so the total price will be between 125 and 130 Euro; a Euro being 
>>>>> $1.08 at the moment. 
>>>>>
>>>>> That's WITH shipping. 
>>>>>
>>>>> >> 124.95 € instead of €165.95
>>>>> >> Price incl. VAT plus €24.55 (for delivery to United States of 
>>>>> America)
>>>>> >> Product code: 234412101"
>>>>>
>>>>> Lighting articles in general are a great deal over there, bc they're a 
>>>>> commodity. Most bikes in Germany are sold with lighting -- it's required 
>>>>> on 
>>>>> bikes used on public roads, with some exemptions for lightweight road 
>>>>> bikes 
>>>>> -- so it's a huge market, and that helps.
>>>>>
>>>>> cheers -m
>>>>>
>>>>>
>>>>> On Wednesday, March 27, 2024 at 4:08:12 PM UTC-4 JohnS wrote:
>>>>>
>>>>>> Thank you Mathias, that looks like a good deal, I'll have to check to 
>>>>>> see what the shipping would be. I may go that route if isn't too 
>>>>>> expensive 
>>>>>> and I don't hear from someone on the list.
>>>>>>
>>>>>> Hello NYCBikeGuy, sorry to give the impression that I know how to 
>>>>>> build wheels, I don't, but I've heard swapping rims isn't too hard, so I 
>>>>&

RTEMS Trac Ticket to GitLab import

2024-03-28 Thread Chris Johns


Hi RTEMS Community

GitLab transition is progressing better than we expected and we are now at a
point where we want to move the tickets in Trac to GitLab. A lot of preparation
has been done in planning the move and an outcome we had not planned is the time
it will take is much more. The original plan was updating the database in Trac
and importing into GitLab however this will not work and we need to break the
tickets up into the various project parts, import and update in GitLab. The time
required to do this is longer than expected.

There are a number of complicating factors migrating the tickets as the separate
projects we will have based on the breakdown of the repos have their own ticket
database. The user accounts we have will not be migrated so you can create your
account when the time comes so when we import the tickets the current owners
will not be available.

We believe it will take around 3 weeks to migrate the data if all goes as
planned. The ticket database will be captured on 29th March 2024 and Trac will
remain open for ticket updating however the changes will not be part of the move
to GitLab. If you update a ticket or push a commit that updates a ticket you
will need to migrate the changes to the GitLab ticket when it is available.
Trac’s Timeline tool can be used to find and review what has changed.

Regards
Chris
RTEMS GitLab Team - Amar, Chris, Gedare, Joel, Kinsey
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

RTEMS Trac Ticket to GitLab import

2024-03-28 Thread Chris Johns

Hi RTEMS Community

GitLab transition is progressing better than we expected and we are now at a
point where we want to move the tickets in Trac to GitLab. A lot of preparation
has been done in planning the move and an outcome we had not planned is the time
it will take is much more. The original plan was updating the database in Trac
and importing into GitLab however this will not work and we need to break the
tickets up into the various project parts, import and update in GitLab. The time
required to do this is longer than expected.

There are a number of complicating factors migrating the tickets as the separate
projects we will have based on the breakdown of the repos have their own ticket
database. The user accounts we have will not be migrated so you can create your
account when the time comes so when we import the tickets the current owners
will not be available.

We believe it will take around 3 weeks to migrate the data if all goes as
planned. The ticket database will be captured on 29th March 2024 and Trac will
remain open for ticket updating however the changes will not be part of the move
to GitLab. If you update a ticket or push a commit that updates a ticket you
will need to migrate the changes to the GitLab ticket when it is available.
Trac’s Timeline tool can be used to find and review what has changed.

Regards
Chris
RTEMS GitLab Team - Amar, Chris, Gedare, Joel, Kinsey
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[RBW] Re: WTB 26" Front Wheel with Generator Hub

2024-03-28 Thread JohnS

Thank you Ian, the quality of the hub is something to consider. You mention 
ordering from German sites, is there one or two that you can recommend?

JohnS


On Wednesday, March 27, 2024 at 5:39:10 PM UTC-4 Ian A wrote:

> Just be aware that is a fairly low end dynamo in the Shimano range. 
> Slightly heavy and draggy in comparison to the higher end Shimano and SP 
> products.
>
> Some shopping around on the German sites might get you an SP hub or an 
> LX/XT hub built into a wheel. Shimano does have a restriction on allowing 
> the export of their products from Europe to North America. A complete wheel 
> might be excepted from the restriction. 
>
> I have bought a fair bit of stuff over the years (Tubus racks, B&M lights, 
> Brooks Saddles, Ortlieb panniers and handlebar bag, tires, spokes and 
> nipples etc) and quite a few of those items are now restricted for export. 
> Xxcycle in France doesn't seem to observe those restrictions (yet). Maybe 
> they do now,  my last order was while back.
>
> My main reason for ordering from Germany is because the economy shipping 
> option comes through the regular postal system and gets delivered by Canada 
> Post on this end. Canadian consumers will have horror stories of shipments 
> delivered via UPS and FedEx due to the brokerage fees for customs entry. 
> Also, shipping tends to be faster to Canada from Europe than from the USA. 
>
> IanA Deepest, darkest BC, Canada
> On Wednesday, March 27, 2024 at 1:59:09 PM UTC-7 JohnS wrote:
>
>>
>> Even better! And they have a ton of stuff on sale, so I could add socks, 
>> gloves or a jersey to the box and won't impact the shipping.
>>
>> JohnS
>>
>> On Wednesday, March 27, 2024 at 4:42:39 PM UTC-4 mathiass...@gmail.com 
>> wrote:
>>
>>>  >> so the total price will be between 125 and 130 Euro; a Euro being 
>>> $1.08 at the moment. 
>>>
>>> That's WITH shipping. 
>>>
>>> >> 124.95 € instead of €165.95
>>> >> Price incl. VAT plus €24.55 (for delivery to United States of America)
>>> >> Product code: 234412101"
>>>
>>> Lighting articles in general are a great deal over there, bc they're a 
>>> commodity. Most bikes in Germany are sold with lighting -- it's required on 
>>> bikes used on public roads, with some exemptions for lightweight road bikes 
>>> -- so it's a huge market, and that helps.
>>>
>>> cheers -m
>>>
>>>
>>> On Wednesday, March 27, 2024 at 4:08:12 PM UTC-4 JohnS wrote:
>>>
>>>> Thank you Mathias, that looks like a good deal, I'll have to check to 
>>>> see what the shipping would be. I may go that route if isn't too expensive 
>>>> and I don't hear from someone on the list.
>>>>
>>>> Hello NYCBikeGuy, sorry to give the impression that I know how to build 
>>>> wheels, I don't, but I've heard swapping rims isn't too hard, so I was 
>>>> going to give it a try if needed.
>>>>
>>>> JohnS
>>>>
>>>> On Wednesday, March 27, 2024 at 1:28:58 PM UTC-4 NYCbikeguy wrote:
>>>>
>>>>> You seem to be savvy in wheel building. I have a disk brake dynamo in 
>>>>> gold currently laced to a 700c rim with machined sidewall for rim brakes 
>>>>> (so versatile!) Let me know if you're interested. I'll send pics.
>>>>>
>>>>> On Wednesday, March 27, 2024 at 1:01:53 PM UTC-4 mathiass...@gmail.com 
>>>>> wrote:
>>>>>
>>>>>> Here's a new option:
>>>>>>
>>>>>>
>>>>>> https://www.rosebikes.com/rose-dt-swiss-535shimano-dh-3d32-qr-26-discnon-disc-mtb-front-wheel-2721231?article_size=6853&product_shape=1
>>>>>>
>>>>>> you get the 19 % VAT deducted when shipping to the U.S. so the total 
>>>>>> price will be between 125 and 130 Euro; a Euro being $1.08 at the 
>>>>>> moment. 
>>>>>> I've had excellent luck with Rose products; they sold 700x35 mm Pasela 
>>>>>> Tourguards last year for $17 a pop -- less than half the price stateside.
>>>>>>
>>>>>> cheers -mathias
>>>>>>
>>>>>> On Wednesday, March 27, 2024 at 10:51:13 AM UTC-4 JohnS wrote:
>>>>>>
>>>>>>> Hello All,
>>>>>>>
>>>>>>> Looking to make my '82 Stumpy a year round errand runner, so dyno 
>>>&g

Re: Xilinx header files installed by BSP

2024-03-27 Thread Chris Johns

On 27/3/2024 7:14 am, Kinsey Moore wrote:
> On Mon, Mar 25, 2024 at 3:34 PM Bernd Moessner  > wrote:
> 
> 
> On 25.03.2024 13:26, Sebastian Huber wrote:
> > Hello,
> >
> > the BSPs for the Xilinx Zynq/ZynqMP/Versal platforms use code from
> > Xilinx. They also install some header files from Xilinx in the
> > top-level include directory of the BSP, for example:
> >
> > sleep.h  xbasic_types.h  xil_assert.h  xil_cache.h xil_exception.h
> > xil_io.h  xil_mem.h  xil_printf.h  xil_smc.h xil_types.h 
> > xparameters.h  xpseudo_asm_gcc.h  xpseudo_asm.h xreg_cortexa53.h 
> > xstatus.h
> >
> > This can lead to conflicts if I would like to build software from
> >
> > https://github.com/Xilinx/embeddedsw 
> 
> >
> > because now some header files are duplicated and available through
> > different include paths. Why do we install these header files? I think
> > they should be only used internally to build the BSP provided drivers.
> > The RTEMS drivers should expose their interfaces not through the
> > Xilinx header files.
> >
> > Any objections to remove the installation of the Xilinx header files?
> >
> Dear Sebastian,
> 
> Zynq 7000 is not using them. Rtems-lwip requires some of the headers. I
> provided a patch which added "objxilinxsupport.yml" to the Zynq 7000
> configurations. After a discussion on Discord my patch was rolled back
> (which I think was a good decision).
> 
> Chris and Kinsey, please correct me if I misunderstood something, but as
> far as I understood it the headers will be removed from the kernel.
> Afaik, there are some drivers for the ZU require them. Thus, it will
> require some time / planning to overwork the drivers and move the
> required headers to rtems-lwip.
> 
> Long story short, Chris and Kinsey should be able to give some more
> detailed information on the strategy and timeline.
> 
> 
> The eventual goal is that the installed Xilinx headers will no longer be
> installed to prevent conflicts as Sebastian suggested. Currently, use of the
> QSPI/NOR and NAND drivers in RTEMS requires access to those headers in the
> installed BSP. Those drivers need to be wrapped to remove dependency on
> installed Xilinx headers. It's on my todo list to wrap these drivers properly.


Reduced exposure and/or removal would benefit us long term. The upstream repo is
a company over wall one and forced pushes and bulk updates happen based on the
internal Xilinx release cycle for their tools.

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

Re: [PATCH v2 2/3] dev/serial: Add ZYNQ_UART_[01]_BASE_ADDR

2024-03-27 Thread Chris Johns

On 28/3/2024 6:43 am, Sebastian Huber wrote:
> This helps to provide a shared implementation of the kernel I/O support.
> ---
>  bsps/aarch64/xilinx-zynqmp/console/console.c  |  4 +-
>  bsps/aarch64/xilinx-zynqmp/include/bsp.h  |  2 +
>  bsps/arm/xilinx-zynq/console/console-config.c |  5 +-
>  bsps/arm/xilinx-zynq/include/bsp.h|  1 +
>  .../console/console-config.c  |  4 +-
>  bsps/arm/xilinx-zynqmp-rpu/include/bsp.h  |  2 +
>  .../xilinx-zynqmp/console/console-config.c|  4 +-
>  bsps/arm/xilinx-zynqmp/include/bsp.h  |  2 +
>  bsps/include/dev/serial/zynq-uart-zynq.h  | 66 +++
>  bsps/include/dev/serial/zynq-uart-zynqmp.h| 66 +++
>  10 files changed, 148 insertions(+), 8 deletions(-)
>  create mode 100644 bsps/include/dev/serial/zynq-uart-zynq.h
>  create mode 100644 bsps/include/dev/serial/zynq-uart-zynqmp.h
> 
> diff --git a/bsps/aarch64/xilinx-zynqmp/console/console.c 
> b/bsps/aarch64/xilinx-zynqmp/console/console.c
> index 1e5df997e8..ce031a914e 100644
> --- a/bsps/aarch64/xilinx-zynqmp/console/console.c
> +++ b/bsps/aarch64/xilinx-zynqmp/console/console.c
> @@ -188,11 +188,11 @@ RTEMS_SYSINIT_ITEM(
>  static zynq_uart_context zynqmp_uart_instances[2] = {
>{
>  .base = RTEMS_TERMIOS_DEVICE_CONTEXT_INITIALIZER( "Zynq UART 0" ),
> -.regs = (volatile struct zynq_uart *) 0xff00,
> +.regs = (volatile zynq_uart *) ZYNQ_UART_0_BASE_ADDR,
>  .irq = ZYNQMP_IRQ_UART_0
>}, {
>  .base = RTEMS_TERMIOS_DEVICE_CONTEXT_INITIALIZER( "Zynq UART 1" ),
> -.regs = (volatile struct zynq_uart *) 0xff01,
> +.regs = (volatile zynq_uart *) ZYNQ_UART_1_BASE_ADDR,
>  .irq = ZYNQMP_IRQ_UART_1
>}
>  };
> diff --git a/bsps/aarch64/xilinx-zynqmp/include/bsp.h 
> b/bsps/aarch64/xilinx-zynqmp/include/bsp.h
> index 0ccca8b196..38a9fad768 100644
> --- a/bsps/aarch64/xilinx-zynqmp/include/bsp.h
> +++ b/bsps/aarch64/xilinx-zynqmp/include/bsp.h
> @@ -55,6 +55,8 @@
>  #include 
>  #include 
>  
> +#include 
> +
>  #ifdef __cplusplus
>  extern "C" {
>  #endif /* __cplusplus */
> diff --git a/bsps/arm/xilinx-zynq/console/console-config.c 
> b/bsps/arm/xilinx-zynq/console/console-config.c
> index d22ceb557d..42e64ee4dd 100644
> --- a/bsps/arm/xilinx-zynq/console/console-config.c
> +++ b/bsps/arm/xilinx-zynq/console/console-config.c
> @@ -35,15 +35,16 @@
>  
>  #include 
>  #include 
> +#include 
>  
>  zynq_uart_context zynq_uart_instances[2] = {
>{
>  .base = RTEMS_TERMIOS_DEVICE_CONTEXT_INITIALIZER( "Zynq UART 0" ),
> -.regs = (volatile struct zynq_uart *) 0xe000,
> +.regs = (volatile zynq_uart *) ZYNQ_UART_0_BASE_ADDR,
>  .irq = ZYNQ_IRQ_UART_0
>}, {
>  .base = RTEMS_TERMIOS_DEVICE_CONTEXT_INITIALIZER( "Zynq UART 1" ),
> -.regs = (volatile struct zynq_uart *) 0xe0001000,
> +.regs = (volatile zynq_uart *) ZYNQ_UART_1_BASE_ADDR,
>  .irq = ZYNQ_IRQ_UART_1
>}
>  };
> diff --git a/bsps/arm/xilinx-zynq/include/bsp.h 
> b/bsps/arm/xilinx-zynq/include/bsp.h
> index 3311a99b50..5ffd5f573a 100644
> --- a/bsps/arm/xilinx-zynq/include/bsp.h
> +++ b/bsps/arm/xilinx-zynq/include/bsp.h
> @@ -55,6 +55,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #ifdef __cplusplus
>  extern "C" {
> diff --git a/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c 
> b/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c
> index eacf6ddcce..13eaa269c5 100644
> --- a/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c
> +++ b/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c
> @@ -44,11 +44,11 @@
>  static zynq_uart_context zynqmp_uart_instances[2] = {
>{
>  .base = RTEMS_TERMIOS_DEVICE_CONTEXT_INITIALIZER( "Zynq UART 0" ),
> -.regs = (volatile struct zynq_uart *) 0xff00,
> +.regs = (volatile zynq_uart *) ZYNQ_UART_0_BASE_ADDR,
>  .irq = ZYNQMP_IRQ_UART_0
>}, {
>  .base = RTEMS_TERMIOS_DEVICE_CONTEXT_INITIALIZER( "Zynq UART 1" ),
> -.regs = (volatile struct zynq_uart *) 0xff01,
> +.regs = (volatile zynq_uart *) ZYNQ_UART_1_BASE_ADDR,
>  .irq = ZYNQMP_IRQ_UART_1
>}
>  };
> diff --git a/bsps/arm/xilinx-zynqmp-rpu/include/bsp.h 
> b/bsps/arm/xilinx-zynqmp-rpu/include/bsp.h
> index e386bd4b26..d80cedbd0d 100644
> --- a/bsps/arm/xilinx-zynqmp-rpu/include/bsp.h
> +++ b/bsps/arm/xilinx-zynqmp-rpu/include/bsp.h
> @@ -61,6 +61,8 @@
>  #include 
>  #include 
>  
> +#include 
> +
>  #ifdef __cplusplus
>  extern "C" {
>  #endif /* __cplusplus */
> diff --git a/bsps/arm/xilinx-zynqmp/console/console-config.c 
> b/bsps/arm/xilinx-zynqmp/console/console-config.c
> index ea148836a5..787ee05dd6 100644
> --- a/bsps/arm/xilinx-zynqmp/console/console-config.c
> +++ b/bsps/arm/xilinx-zynqmp/console/console-config.c
> @@ -44,11 +44,11 @@
>  static zynq_uart_context zynqmp_uart_instances[2] = {
>{
>  .base = RTEMS_TERMIOS_DEVICE_CONTEXT_INITIALIZER( "Zynq UART 0" ),
> -.regs = (volatile struct zynq_uart *) 0xff00,
> +.regs

[RBW] Re: WTB 26" Front Wheel with Generator Hub

2024-03-27 Thread JohnS


Even better! And they have a ton of stuff on sale, so I could add socks, 
gloves or a jersey to the box and won't impact the shipping.

JohnS

On Wednesday, March 27, 2024 at 4:42:39 PM UTC-4 mathiass...@gmail.com 
wrote:

>  >> so the total price will be between 125 and 130 Euro; a Euro being 
> $1.08 at the moment. 
>
> That's WITH shipping. 
>
> >> 124.95 € instead of €165.95
> >> Price incl. VAT plus €24.55 (for delivery to United States of America)
> >> Product code: 234412101"
>
> Lighting articles in general are a great deal over there, bc they're a 
> commodity. Most bikes in Germany are sold with lighting -- it's required on 
> bikes used on public roads, with some exemptions for lightweight road bikes 
> -- so it's a huge market, and that helps.
>
> cheers -m
>
>
> On Wednesday, March 27, 2024 at 4:08:12 PM UTC-4 JohnS wrote:
>
>> Thank you Mathias, that looks like a good deal, I'll have to check to see 
>> what the shipping would be. I may go that route if isn't too expensive and 
>> I don't hear from someone on the list.
>>
>> Hello NYCBikeGuy, sorry to give the impression that I know how to build 
>> wheels, I don't, but I've heard swapping rims isn't too hard, so I was 
>> going to give it a try if needed.
>>
>> JohnS
>>
>> On Wednesday, March 27, 2024 at 1:28:58 PM UTC-4 NYCbikeguy wrote:
>>
>>> You seem to be savvy in wheel building. I have a disk brake dynamo in 
>>> gold currently laced to a 700c rim with machined sidewall for rim brakes 
>>> (so versatile!) Let me know if you're interested. I'll send pics.
>>>
>>> On Wednesday, March 27, 2024 at 1:01:53 PM UTC-4 mathiass...@gmail.com 
>>> wrote:
>>>
>>>> Here's a new option:
>>>>
>>>>
>>>> https://www.rosebikes.com/rose-dt-swiss-535shimano-dh-3d32-qr-26-discnon-disc-mtb-front-wheel-2721231?article_size=6853&product_shape=1
>>>>
>>>> you get the 19 % VAT deducted when shipping to the U.S. so the total 
>>>> price will be between 125 and 130 Euro; a Euro being $1.08 at the moment. 
>>>> I've had excellent luck with Rose products; they sold 700x35 mm Pasela 
>>>> Tourguards last year for $17 a pop -- less than half the price stateside.
>>>>
>>>> cheers -mathias
>>>>
>>>> On Wednesday, March 27, 2024 at 10:51:13 AM UTC-4 JohnS wrote:
>>>>
>>>>> Hello All,
>>>>>
>>>>> Looking to make my '82 Stumpy a year round errand runner, so dyno 
>>>>> lights are the way to go.
>>>>>
>>>>> Requirements:
>>>>> 26" rim brake for a wider tire. I plan to use RH 26" x 2.3" Rat Trap 
>>>>> pass tires.
>>>>> 100 mm spacing.
>>>>> 6V, 3W power output for front and rear LED lights.
>>>>> Good working order and can be serviced (no rusty axle nuts).
>>>>>
>>>>> Nice to have, but not required:
>>>>> Silver color, but black is ok.
>>>>> 32 spoke count (I have an extra rim, so if yours is worn out, I can 
>>>>> switch it).
>>>>> Looking to spend about $100 plus shipping to Allentown PA 18104.
>>>>> Hub brand is not too important to me, the exception would be the Sanyo 
>>>>> hub, I've read that it has noticeable drag.
>>>>>
>>>>> Please reply directly to me if you have one to unload.
>>>>> Thank you,
>>>>> JohnS
>>>>>
>>>>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/e3057555-a067-4ab9-bcc4-f180f6fd136dn%40googlegroups.com.

[RBW] Re: WTB 26" Front Wheel with Generator Hub

2024-03-27 Thread JohnS

Thank you Mathias, that looks like a good deal, I'll have to check to see 
what the shipping would be. I may go that route if isn't too expensive and 
I don't hear from someone on the list.

Hello NYCBikeGuy, sorry to give the impression that I know how to build 
wheels, I don't, but I've heard swapping rims isn't too hard, so I was 
going to give it a try if needed.

JohnS

On Wednesday, March 27, 2024 at 1:28:58 PM UTC-4 NYCbikeguy wrote:

> You seem to be savvy in wheel building. I have a disk brake dynamo in gold 
> currently laced to a 700c rim with machined sidewall for rim brakes (so 
> versatile!) Let me know if you're interested. I'll send pics.
>
> On Wednesday, March 27, 2024 at 1:01:53 PM UTC-4 mathiass...@gmail.com 
> wrote:
>
>> Here's a new option:
>>
>>
>> https://www.rosebikes.com/rose-dt-swiss-535shimano-dh-3d32-qr-26-discnon-disc-mtb-front-wheel-2721231?article_size=6853&product_shape=1
>>
>> you get the 19 % VAT deducted when shipping to the U.S. so the total 
>> price will be between 125 and 130 Euro; a Euro being $1.08 at the moment. 
>> I've had excellent luck with Rose products; they sold 700x35 mm Pasela 
>> Tourguards last year for $17 a pop -- less than half the price stateside.
>>
>> cheers -mathias
>>
>> On Wednesday, March 27, 2024 at 10:51:13 AM UTC-4 JohnS wrote:
>>
>>> Hello All,
>>>
>>> Looking to make my '82 Stumpy a year round errand runner, so dyno lights 
>>> are the way to go.
>>>
>>> Requirements:
>>> 26" rim brake for a wider tire. I plan to use RH 26" x 2.3" Rat Trap 
>>> pass tires.
>>> 100 mm spacing.
>>> 6V, 3W power output for front and rear LED lights.
>>> Good working order and can be serviced (no rusty axle nuts).
>>>
>>> Nice to have, but not required:
>>> Silver color, but black is ok.
>>> 32 spoke count (I have an extra rim, so if yours is worn out, I can 
>>> switch it).
>>> Looking to spend about $100 plus shipping to Allentown PA 18104.
>>> Hub brand is not too important to me, the exception would be the Sanyo 
>>> hub, I've read that it has noticeable drag.
>>>
>>> Please reply directly to me if you have one to unload.
>>> Thank you,
>>> JohnS
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/71ca55fd-a034-44e2-a812-185737418099n%40googlegroups.com.

[RBW] WTB 26" Front Wheel with Generator Hub

2024-03-27 Thread JohnS

Hello All,

Looking to make my '82 Stumpy a year round errand runner, so dyno lights 
are the way to go.

Requirements:
26" rim brake for a wider tire. I plan to use RH 26" x 2.3" Rat Trap pass 
tires.
100 mm spacing.
6V, 3W power output for front and rear LED lights.
Good working order and can be serviced (no rusty axle nuts).

Nice to have, but not required:
Silver color, but black is ok.
32 spoke count (I have an extra rim, so if yours is worn out, I can switch 
it).
Looking to spend about $100 plus shipping to Allentown PA 18104.
Hub brand is not too important to me, the exception would be the Sanyo hub, 
I've read that it has noticeable drag.

Please reply directly to me if you have one to unload.
Thank you,
JohnS

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/016f3047-5ca0-4b3f-91e7-adcf288fcab8n%40googlegroups.com.

Re: [PATCH v2] bsps: Add BSP_FLUSH_KERNEL_CHAR_OUTPUT BSP option

2024-03-21 Thread Chris Johns

On 21/3/2024 5:39 pm, Sebastian Huber wrote:> On 21.03.24 00:28, Chris Johns 
wrote:
>> On 21/3/2024 2:11 am, Sebastian Huber wrote:
>>> On 19.03.24 18:44, Chris Johns wrote:
>>>> On 20/3/2024 2:03 am, Sebastian Huber wrote:
>>>>> On 19.03.24 14:50, Kinsey Moore wrote:
>>>>>> The xilinx-zynqmp-rpu bsp_reset() is modified, but not included in the 
>>>>>> spec
>>>>>> file for the new option. Its family differs from the arm/xilinx-zynqmp 
>>>>>> BSP
>>>>>> family with a -rpu suffix.
>>>>> Yes, but this BSP is quite new. I would prefer to let it not flush 
>>>>> anything by
>>>>> default to carry out a reset.
>>>>>
>>>>>> I'd be fine with this being enabled for the AArch64 BSPs as well, but I
>>>>>> imagine that's better as a separate patch.
>>>>> Why should it be enabled by default? The arm/xilinx-zynq and 
>>>>> arm/xilinx-zynqmp
>>>>> BSPs were the only ones doing an UART flush in the general termination
>>>>> procedure. It probably was done to address a specific use case (maybe test
>>>>> runs).
>>>> Is the issue the flush is before an infinite loop which means the UART FIFO
>>>> should drain?
>>
>> What is the issue you are wanting to solve removing the flush?
> 
> The bsp_reset() function should reset the system and do nothing more. Doing
> additional things like flushing an UART device may not make sense for all
> applications. Some applications may not use the UART device, so it may not be
> initialized and powered off.  Some applications may use it with an
> application-specific protocol which doesn't like the additional four '\r' 
> during
> reset. Doing a UART flush takes some time and some applications may prefer a
> fast reset time. The bsp_reset() is the wrong place to do add specific cleanup
> functions. Applications can customize the termination procedure with their own
> fatal error extension, destructors, and exit handlers.

This makes sense however the console needs this. Removing the code as my reading
of this changes does breaks those systems where the console is in use and relies
on the UART being flushed. A solution that addresses the console side of things
would be more acceptable. You present some valid cases for making a change but a
user should be able to enter reset in a shell and see all output or invoke a
fatal error and expect to see the full error message.

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

Re: [PATCH v2] bsps: Add BSP_FLUSH_KERNEL_CHAR_OUTPUT BSP option

2024-03-20 Thread Chris Johns

On 21/3/2024 2:11 am, Sebastian Huber wrote:
> On 19.03.24 18:44, Chris Johns wrote:
>> On 20/3/2024 2:03 am, Sebastian Huber wrote:
>>> On 19.03.24 14:50, Kinsey Moore wrote:
>>>> The xilinx-zynqmp-rpu bsp_reset() is modified, but not included in the spec
>>>> file for the new option. Its family differs from the arm/xilinx-zynqmp BSP
>>>> family with a -rpu suffix.
>>> Yes, but this BSP is quite new. I would prefer to let it not flush anything 
>>> by
>>> default to carry out a reset.
>>>
>>>> I'd be fine with this being enabled for the AArch64 BSPs as well, but I
>>>> imagine that's better as a separate patch.
>>> Why should it be enabled by default? The arm/xilinx-zynq and 
>>> arm/xilinx-zynqmp
>>> BSPs were the only ones doing an UART flush in the general termination
>>> procedure. It probably was done to address a specific use case (maybe test
>>> runs).
>> Is the issue the flush is before an infinite loop which means the UART FIFO
>> should drain?

What is the issue you are wanting to solve removing the flush?

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

Re: [RBW] I have questions

2024-03-20 Thread JohnS

Will has Mark's alternate safety strap in this email news letter, scroll 
down to "Mark's safety cable". Looks like a good solution since the cable 
housing protects the bike frame from the cable.

https://us7.campaign-archive.com/?u=ad1569fa93a2ab2374ead2fde&id=279bef4181

As far as 650B tires go, I recommend Rene Herse Babyshoe Pass 42mm width 
tire, extra light casing. They are great for mixed surface rides; road and 
hard packed gravel or cinder such as a rail trail. As mentioned already, 
they are not so good in mud where they can get squirmy and can loose 
traction. I have them on my Crust Lightening Bolt canti which is my bike 
for long rides and mixed surfaces. I have Gravel King SK tires on my gravel 
bike. They are a very good tire and I use that bike for more challenging 
gravel rides where the surface can be looser and the trails are more like 
mountain bike single track.

Good luck,
JohnS




On Wednesday, March 20, 2024 at 12:21:08 PM UTC-4 J wrote:

> You don't say which Gravel King model you are using, but I see in your 
> Philly post that you have Ultradynamico Cava tires on your bike. So maybe 
> you run the file tread GK? Anyhow, I rode through 2 sets of 700x42 Gravel 
> King SK on my old Sam Hillbourne before moving up to 700x50 which just 
> barely fit. I thought I'd notice a big difference but it turned out not to 
> be true, as long as I kept the air pressure up. I only have 650b bikes now, 
> and don't ride Gravel King SK after discovering the Rene Herse file tread 
> much smoother and faster "feeling". I've switched back and forth from 42 
> and 48mm RH file treads as well as 42 Gran Bois and have settled on 48mm RH 
> (Switchback Hill) which measures quite a bit over 48mm on my wheels. The 
> 42mm tires gave the perception that I was faster but the strava data did 
> not corroborate, and the 48mm have so much lovely float over gravel 
> compared to anything narrower or with tooth, I figured why bother? YMMV but 
> I think 48s won't be an issue. If my words sway you at all towards RH, just 
> keep in mind that they are not great in wet conditions with steep descents 
> combined with rim brakes. I learned this twice this fall, and kept RH 
> knobbies on until a few days ago. 
>
> mysterious J
>
> On Wednesday, March 20, 2024 at 11:42:19 AM UTC-4 Patrick Moore wrote:
>
>> The 60 mm Schwalbe Big Ones that used to be on my dirt road Matthews were 
>> among the very fastest-rolling tires I've used, including various "racing" 
>> tires and 2 extralight RH models. I'd say that the right 48 mm tire will 
>> roll plenty fast. 
>>
>> I've not used any Gravel Kings.
>>
>> Patrick "it's not my tires that make me slow" Moore
>>
>> On Tue, Mar 19, 2024 at 7:10 PM Bicycle Belle Ding Ding! <
>> jonasa...@gmail.com> wrote:
>>
>>> ... Can 48 mm tires do a 15-17 mph road ride pace? I have 42 on all my 
>>> other bikes. Would 48s be slow? The ride is a 2 day event, 100 miles total. 
>>> I’d like to keep the tires if I could, because they’re new and they are fat 
>>> enough to also double as gravel tires, should I decide to do a gravel ride 
>>> again. But I do more road rides than anything else, and if those 48s will 
>>> cripple me, I’ll go back to 42s. What’s the consensus?
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/518961dc-ee36-4474-89ff-cc46564ff841n%40googlegroups.com.

Re: [PATCH v2] bsps: Add BSP_FLUSH_KERNEL_CHAR_OUTPUT BSP option

On 19/3/2024 7:39 pm, Sebastian Huber wrote:
> Make the kernel I/O output character device flushing configurable.  The
> bsp_reset() function should reset the unit and do nothing else.

This changes existing behaviour. RTEMS is poor at cleanly handling the console
output on reset. Working with the powerpc/mvme2700 and EPICS is hard because the
output is lost on reset and assert and crash output is corrupted.

As an OS I think we should be heading other way and if you want just a reset you
provide it.

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

Re: [PATCH v2] bsps: Add BSP_FLUSH_KERNEL_CHAR_OUTPUT BSP option

On 20/3/2024 2:03 am, Sebastian Huber wrote:
> On 19.03.24 14:50, Kinsey Moore wrote:
>> The xilinx-zynqmp-rpu bsp_reset() is modified, but not included in the spec
>> file for the new option. Its family differs from the arm/xilinx-zynqmp BSP
>> family with a -rpu suffix.
> 
> Yes, but this BSP is quite new. I would prefer to let it not flush anything by
> default to carry out a reset.
> 
>> I'd be fine with this being enabled for the AArch64 BSPs as well, but I
>> imagine that's better as a separate patch.
> 
> Why should it be enabled by default? The arm/xilinx-zynq and arm/xilinx-zynqmp
> BSPs were the only ones doing an UART flush in the general termination
> procedure. It probably was done to address a specific use case (maybe test 
> runs).

Is the issue the flush is before an infinite loop which means the UART FIFO
should drain?

> I don't really like the new bsp_flush_kernel_char_output() function. Another
> approach could be an API change of
> 
> /**
>  * @ingroup RTEMSAPIKernelCharIO
>  *
>  * @brief Polled character output functions shall have this type.
>  */
> typedef void ( *BSP_output_char_function_type )( char );
> 
> to something like this
> 
> typedef int ( *BSP_output_char_function_type )( int action );
> 
> If action in {0, ..., 255}, then print out the character. If 0x100 is set, 
> then
> flush the output device. If 0x200 is set, then do Y... The return value could 
> be
> used to give a status indication.
> 
> This could then be use for example by test runs, to flush the test output 
> after
> the end of the test.

This also requires a code change so is a flush function that bad an option?

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

Re: [PATCH 1/5] bsps: Use bsps/aarch64/xilinx-zynqmp

On 19/3/2024 5:59 pm, Sebastian Huber wrote:
> On 19.03.24 03:21, Chris Johns wrote:
>> Does this patch series build at the per commit level?
> 
> I used
> 
> ./waf bspdefaults > a.txt
> apply patch
> ./waf bspdefaults > b.txt
> diff a.txt b.txt
> 
> to check that the defaults don't change.

Great.

> I will build the BSPs for each commit today.

Thanks. The reason I raised this is GitLab can squash merges to `main` and the
reason is always being able to bisect `main` so it is an issue being considered.
This patch set made me wonder what we do now?

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

Re: [PATCH 3/5] xilinx-zynqmp-rpu: Remove URLs from copyrights

On 19/3/2024 5:52 pm, Sebastian Huber wrote:
> On 19.03.24 03:20, Chris Johns wrote:
>> On 19/3/2024 3:30 am, Sebastian Huber wrote:
>>> ---
>>>   spec/build/bsps/arm/xilinx-zynqmp-rpu/abi.yml    | 2 +-
>>>   spec/build/bsps/arm/xilinx-zynqmp-rpu/bspmercuryxu5.yml  | 2 +-
>>>   spec/build/bsps/arm/xilinx-zynqmp-rpu/linkcmds.yml   | 2 +-
>>>   spec/build/bsps/arm/xilinx-zynqmp-rpu/optprocunitrpu.yml | 2 +-
>>>   4 files changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/spec/build/bsps/arm/xilinx-zynqmp-rpu/abi.yml
>>> b/spec/build/bsps/arm/xilinx-zynqmp-rpu/abi.yml
>>> index ba70c44d7d..06795eb416 100644
>>> --- a/spec/build/bsps/arm/xilinx-zynqmp-rpu/abi.yml
>>> +++ b/spec/build/bsps/arm/xilinx-zynqmp-rpu/abi.yml
>>> @@ -5,7 +5,7 @@ actions:
>>>   - env-append: null
>>>   build-type: option
>>>   copyrights:
>>> -- Copyright (C) 2023 Reflex Aerospace GmbH 
>>> (https://www.reflexaerospace.com/  )
>>> +- Copyright (C) 2023 Reflex Aerospace GmbH
>> Why this change?
> 
> When I updated our company name to embedded brains GmbH & Co. KG, I removed 
> the
> URLs from our copyright statements since we were basically the only ones doing
> this. If you don't have an issue with the URLs, then I will discuss internally
> if we would like to add them again to our copyright statements.

This is fine. I was wondering if there was some technical reason which there is 
not.

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

Re: [PATCH v2] user: Add docu for use of Rust with RTEMS

On 16/3/2024 1:14 am, Frank Kühndel wrote:
> Ping!
> 
> The last discussion of this patch was
>    https://lists.rtems.org/pipermail/devel/2024-February/077289.html
> 
> Does the fact that I recive no further comments to this patch mean it can be
> pushed to the RTEMS User Manual as it is?

Sorry Frank, I have been busy with other changes. It is on my list but I have
will need to reread the thread when I have time.

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

Re: RTEMS 7 GDB Build Failure on FreeBSD 13

On 19/3/2024 1:27 am, Joel Sherrill wrote:
> I am going through the logs on the test sweep VMs to see why some builds are
> failing. This is due to gdb's requirement for GMP and MPFR. What's the
> recommended way to address this? Load native packages?

No, we need to add support to build them. We have to because other hosts like
MacOS do not have a standard package system.

Chris

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

Re: [PATCH 1/5] bsps: Use bsps/aarch64/xilinx-zynqmp

Does this patch series build at the per commit level?

Chris

On 19/3/2024 3:30 am, Sebastian Huber wrote:
> ---
>  spec/build/bsps/dev/irq/optarmgic-icc-bpr0.yml| 6 +-
>  spec/build/bsps/dev/irq/optarmgic-icc-igrpen0.yml | 6 +-
>  spec/build/cpukit/optsmp.yml  | 6 +-
>  3 files changed, 3 insertions(+), 15 deletions(-)
> 
> diff --git a/spec/build/bsps/dev/irq/optarmgic-icc-bpr0.yml 
> b/spec/build/bsps/dev/irq/optarmgic-icc-bpr0.yml
> index 5338538de0..44d2671eb6 100644
> --- a/spec/build/bsps/dev/irq/optarmgic-icc-bpr0.yml
> +++ b/spec/build/bsps/dev/irq/optarmgic-icc-bpr0.yml
> @@ -15,11 +15,7 @@ default:
>- aarch64/xilinx_versal_aiedge
>- aarch64/xilinx_versal_qemu
>- aarch64/xilinx_versal_vck190
> -  - aarch64/xilinx_zynqmp_ilp32_qemu
> -  - aarch64/xilinx_zynqmp_ilp32_zu3eg
> -  - aarch64/xilinx_zynqmp_lp64_cfc400x
> -  - aarch64/xilinx_zynqmp_lp64_qemu
> -  - aarch64/xilinx_zynqmp_lp64_zu3eg
> +  - bsps/aarch64/xilinx-zynqmp
>value: null
>  - enabled-by: true
>value: 0x0002
> diff --git a/spec/build/bsps/dev/irq/optarmgic-icc-igrpen0.yml 
> b/spec/build/bsps/dev/irq/optarmgic-icc-igrpen0.yml
> index fbc2dd9227..9b552c3f96 100644
> --- a/spec/build/bsps/dev/irq/optarmgic-icc-igrpen0.yml
> +++ b/spec/build/bsps/dev/irq/optarmgic-icc-igrpen0.yml
> @@ -15,11 +15,7 @@ default:
>- aarch64/xilinx_versal_aiedge
>- aarch64/xilinx_versal_qemu
>- aarch64/xilinx_versal_vck190
> -  - aarch64/xilinx_zynqmp_ilp32_qemu
> -  - aarch64/xilinx_zynqmp_ilp32_zu3eg
> -  - aarch64/xilinx_zynqmp_lp64_cfc400x
> -  - aarch64/xilinx_zynqmp_lp64_qemu
> -  - aarch64/xilinx_zynqmp_lp64_zu3eg
> +  - bsps/aarch64/xilinx-zynqmp
>value: null
>  - enabled-by: true
>value: 0x0001
> diff --git a/spec/build/cpukit/optsmp.yml b/spec/build/cpukit/optsmp.yml
> index 45d41299da..f78558d6eb 100644
> --- a/spec/build/cpukit/optsmp.yml
> +++ b/spec/build/cpukit/optsmp.yml
> @@ -13,11 +13,6 @@ default:
>  description: |
>Enable the Symmetric Multiprocessing (SMP) support
>  enabled-by:
> -- aarch64/xilinx_zynqmp_ilp32_qemu
> -- aarch64/xilinx_zynqmp_ilp32_zu3eg
> -- aarch64/xilinx_zynqmp_lp64_cfc400x
> -- aarch64/xilinx_zynqmp_lp64_qemu
> -- aarch64/xilinx_zynqmp_lp64_zu3eg
>  - arm/altcycv_devkit
>  - arm/fvp_cortex_r52
>  - arm/imx7
> @@ -33,6 +28,7 @@ enabled-by:
>  - arm/xilinx_zynq_picozed
>  - arm/xilinx_zynq_pynq
>  - arm/xilinx_zynq_microzed
> +- bsps/aarch64/xilinx-zynqmp
>  - i386/pc386
>  - i386/pc486
>  - i386/pc586
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 3/5] xilinx-zynqmp-rpu: Remove URLs from copyrights

On 19/3/2024 3:30 am, Sebastian Huber wrote:
> ---
>  spec/build/bsps/arm/xilinx-zynqmp-rpu/abi.yml| 2 +-
>  spec/build/bsps/arm/xilinx-zynqmp-rpu/bspmercuryxu5.yml  | 2 +-
>  spec/build/bsps/arm/xilinx-zynqmp-rpu/linkcmds.yml   | 2 +-
>  spec/build/bsps/arm/xilinx-zynqmp-rpu/optprocunitrpu.yml | 2 +-
>  4 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/spec/build/bsps/arm/xilinx-zynqmp-rpu/abi.yml 
> b/spec/build/bsps/arm/xilinx-zynqmp-rpu/abi.yml
> index ba70c44d7d..06795eb416 100644
> --- a/spec/build/bsps/arm/xilinx-zynqmp-rpu/abi.yml
> +++ b/spec/build/bsps/arm/xilinx-zynqmp-rpu/abi.yml
> @@ -5,7 +5,7 @@ actions:
>  - env-append: null
>  build-type: option
>  copyrights:
> -- Copyright (C) 2023 Reflex Aerospace GmbH ( 
> https://www.reflexaerospace.com/ )
> +- Copyright (C) 2023 Reflex Aerospace GmbH

Why this change?

Chris

>  default:
>  - enabled-by: true
>value:
> diff --git a/spec/build/bsps/arm/xilinx-zynqmp-rpu/bspmercuryxu5.yml 
> b/spec/build/bsps/arm/xilinx-zynqmp-rpu/bspmercuryxu5.yml
> index d08f048060..3fa210d8e7 100644
> --- a/spec/build/bsps/arm/xilinx-zynqmp-rpu/bspmercuryxu5.yml
> +++ b/spec/build/bsps/arm/xilinx-zynqmp-rpu/bspmercuryxu5.yml
> @@ -4,7 +4,7 @@ bsp: xilinx_zynqmp_mercuryxu5_rpu
>  build-type: bsp
>  cflags: []
>  copyrights:
> -- Copyright (C) 2023 Reflex Aerospace GmbH ( 
> https://www.reflexaerospace.com/ )
> +- Copyright (C) 2023 Reflex Aerospace GmbH
>  cppflags: []
>  enabled-by: true
>  family: xilinx-zynqmp-rpu
> diff --git a/spec/build/bsps/arm/xilinx-zynqmp-rpu/linkcmds.yml 
> b/spec/build/bsps/arm/xilinx-zynqmp-rpu/linkcmds.yml
> index a3654f3f42..9c8a6d1cd6 100644
> --- a/spec/build/bsps/arm/xilinx-zynqmp-rpu/linkcmds.yml
> +++ b/spec/build/bsps/arm/xilinx-zynqmp-rpu/linkcmds.yml
> @@ -38,7 +38,7 @@ content: |
>_stack_end = bsp_section_stack_end;
>__undef_stack = bsp_section_stack_begin;
>  copyrights:
> -- Copyright (C) 2023 Reflex Aerospace GmbH ( 
> https://www.reflexaerospace.com/ )
> +- Copyright (C) 2023 Reflex Aerospace GmbH
>  enabled-by: true
>  install-path: ${BSP_LIBDIR}
>  links: []
> diff --git a/spec/build/bsps/arm/xilinx-zynqmp-rpu/optprocunitrpu.yml 
> b/spec/build/bsps/arm/xilinx-zynqmp-rpu/optprocunitrpu.yml
> index 09a3965906..d684f5a06d 100644
> --- a/spec/build/bsps/arm/xilinx-zynqmp-rpu/optprocunitrpu.yml
> +++ b/spec/build/bsps/arm/xilinx-zynqmp-rpu/optprocunitrpu.yml
> @@ -4,7 +4,7 @@ actions:
>  - define-condition: null
>  build-type: option
>  copyrights:
> -- Copyright (C) 2023 Reflex Aerospace GmbH ( 
> https://www.reflexaerospace.com/ )
> +- Copyright (C) 2023 Reflex Aerospace GmbH
>  default:
>  - enabled-by: true
>value: true
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] bsps: Add BSP_FLUSH_KERNEL_CHAR_OUTPUT option

On 19/3/2024 3:49 am, Sebastian Huber wrote:
> Make the kernel I/O output character device flushing configurable.  The
> bsp_reset() function should reset the unit and do nothing else.
> ---
>  bsps/aarch64/xilinx-zynqmp/console/console.c  |  3 ++-
>  bsps/aarch64/xilinx-zynqmp/include/bsp.h  |  2 --
>  .../console/console-config.c  |  3 ++-
>  bsps/arm/xilinx-zynqmp-rpu/include/bsp.h  |  2 --
>  bsps/arm/xilinx-zynqmp-rpu/start/bspreset.c   |  3 ---
>  .../xilinx-zynqmp/console/console-config.c|  2 +-
>  bsps/arm/xilinx-zynqmp/include/bsp.h  |  2 --
>  bsps/arm/xilinx-zynqmp/start/bspreset.c   |  4 +---
>  bsps/include/bsp/bootcard.h   |  5 +
>  bsps/shared/start/bspfatal-default.c  |  4 
>  spec/build/bsps/bspopts.yml   |  2 ++
>  spec/build/bsps/optflushkerncharout.yml   | 20 +++
>  12 files changed, 37 insertions(+), 15 deletions(-)
>  create mode 100644 spec/build/bsps/optflushkerncharout.yml
> 
> diff --git a/bsps/aarch64/xilinx-zynqmp/console/console.c 
> b/bsps/aarch64/xilinx-zynqmp/console/console.c
> index 9ce0b1da63..d1b2850952 100644
> --- a/bsps/aarch64/xilinx-zynqmp/console/console.c
> +++ b/bsps/aarch64/xilinx-zynqmp/console/console.c
> @@ -41,6 +41,7 @@
>  #include 
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -234,7 +235,7 @@ rtems_status_code console_initialize(
>return RTEMS_SUCCESSFUL;
>  }
>  
> -void zynqmp_debug_console_flush(void)
> +void bsp_flush_kernel_char_output(void)
>  {
>zynq_uart_reset_tx_flush(&zynqmp_uart_instances[BSP_CONSOLE_MINOR]);
>  }
> diff --git a/bsps/aarch64/xilinx-zynqmp/include/bsp.h 
> b/bsps/aarch64/xilinx-zynqmp/include/bsp.h
> index 0ccca8b196..d36abde415 100644
> --- a/bsps/aarch64/xilinx-zynqmp/include/bsp.h
> +++ b/bsps/aarch64/xilinx-zynqmp/include/bsp.h
> @@ -86,8 +86,6 @@ BSP_START_TEXT_SECTION void 
> zynqmp_setup_mmu_and_cache(void);
>   */
>  BSP_START_TEXT_SECTION void zynqmp_setup_secondary_cpu_mmu_and_cache( void );
>  
> -void zynqmp_debug_console_flush(void);
> -
>  uint32_t zynqmp_clock_i2c0(void);
>  
>  uint32_t zynqmp_clock_i2c1(void);
> diff --git a/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c 
> b/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c
> index f52e008f2b..196b2dec58 100644
> --- a/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c
> +++ b/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c
> @@ -35,6 +35,7 @@
>  #include 
>  #include 
>  
> +#include 
>  #include 
>  #include 
>  
> @@ -79,7 +80,7 @@ rtems_status_code console_initialize(
>return RTEMS_SUCCESSFUL;
>  }
>  
> -void zynqmp_debug_console_flush(void)
> +void bsp_flush_kernel_char_output(void)
>  {
>zynq_uart_reset_tx_flush(&zynqmp_uart_instances[BSP_CONSOLE_MINOR]);
>  }
> diff --git a/bsps/arm/xilinx-zynqmp-rpu/include/bsp.h 
> b/bsps/arm/xilinx-zynqmp-rpu/include/bsp.h
> index e386bd4b26..060147967c 100644
> --- a/bsps/arm/xilinx-zynqmp-rpu/include/bsp.h
> +++ b/bsps/arm/xilinx-zynqmp-rpu/include/bsp.h
> @@ -83,8 +83,6 @@ extern "C" {
>   */
>  BSP_START_TEXT_SECTION void zynqmp_setup_mpu_and_cache(void);
>  
> -void zynqmp_debug_console_flush(void);
> -
>  #ifdef __cplusplus
>  }
>  #endif /* __cplusplus */
> diff --git a/bsps/arm/xilinx-zynqmp-rpu/start/bspreset.c 
> b/bsps/arm/xilinx-zynqmp-rpu/start/bspreset.c
> index eecb4da838..a894f55f6e 100644
> --- a/bsps/arm/xilinx-zynqmp-rpu/start/bspreset.c
> +++ b/bsps/arm/xilinx-zynqmp-rpu/start/bspreset.c
> @@ -30,13 +30,10 @@
>   * POSSIBILITY OF SUCH DAMAGE.
>   */
>  
> -#include 
>  #include 
>  
>  void bsp_reset(void)
>  {
> -  zynqmp_debug_console_flush();

Why remove the call here?

> -
>while (true) {
>  /* Wait */
>}
> diff --git a/bsps/arm/xilinx-zynqmp/console/console-config.c 
> b/bsps/arm/xilinx-zynqmp/console/console-config.c
> index eadd7f11a2..360d193ba2 100644
> --- a/bsps/arm/xilinx-zynqmp/console/console-config.c
> +++ b/bsps/arm/xilinx-zynqmp/console/console-config.c
> @@ -81,7 +81,7 @@ rtems_status_code console_initialize(
>return RTEMS_SUCCESSFUL;
>  }
>  
> -void zynqmp_debug_console_flush(void)
> +void bsp_flush_kernel_char_output(void)
>  {
>zynq_uart_reset_tx_flush(&zynqmp_uart_instances[BSP_CONSOLE_MINOR]);
>  }
> diff --git a/bsps/arm/xilinx-zynqmp/include/bsp.h 
> b/bsps/arm/xilinx-zynqmp/include/bsp.h
> index a08a5feee9..2785e4c2e0 100644
> --- a/bsps/arm/xilinx-zynqmp/include/bsp.h
> +++ b/bsps/arm/xilinx-zynqmp/include/bsp.h
> @@ -79,8 +79,6 @@ extern "C" {
>   */
>  BSP_START_TEXT_SECTION void zynqmp_setup_mmu_and_cache(void);
>  
> -void zynqmp_debug_console_flush(void);
> -
>  #ifdef __cplusplus
>  }
>  #endif /* __cplusplus */
> diff --git a/bsps/arm/xilinx-zynqmp/start/bspreset.c 
> b/bsps/arm/xilinx-zynqmp/start/bspreset.c
> index b43b19b05f..ed2f4da83a 100644
> --- a/bsps/arm/xilinx-zynqmp/start/bspreset.c
> +++ b/bsps/arm/xilinx-zynqmp/start/bspreset.c
> @@ -30,12 +30,10 @@
>   * POSSIBILITY OF SUCH DAM

Re: rtems-6.1-rc2 on Mac OSX Sonoma 14.4 (Apple M2) failed -> fixed

On 12/3/2024 8:06 pm, Heinz Junkes wrote:
> Hello Chris,
> 
> thanks for your mail. I have now installed the python as you described.

Great.

> The source-builder process runs quite well. 
> 
> Unfortunately, the gcc-13.2.0-newlib for powerpc cannot be built:

I updated to the latest RSB with the newlib FS_SIZE 256 patch that Joel pushed
today and 6/rtems-powerpc built without error on an M2 MacBook.

I have Sonoma 14.2.1 and the latest Xcode. No brew of MacPorts.

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

RTEMS GitLab

Hi RTEMS Community

I would like to announce that RTEMS will be moving to GitLib in the coming month
or so. We do not have any exact dates yet and we will let you know when we do.
The change is large and complex because we are integrating an active open source
project made up of various pieces into a single platform.

1. A number of services we currently run will be locked to prevent further
modification but will remain available while we move, for example our current
Trac web site.

2. All repo default branches will be moved to `main` as part of the move. You
will need to migrate any repos you have to use `main` and we will provide
instructions when the time comes.

3. Accounts you may have will not be migrated. If you have a Trac account you
will need to create a new account on GitLab. Accounts will be protected by 2FA.

4. The initial roll out is to provide repo access with Merge Requests. Once live
there will be no need to send patches to mailing lists for review and 
integration.

5. We will provide more detail closer to the roll out of the projects in GitLab
and the approval process we will initially adopt. GitLab will be set up with an
initial set of roles and positions assigned to people. This is an initial
starting point and we are open to adding people who can help with the
administrative tasks we have.

6. Moving the tickets from Trac to GitLab is complicated and involved and will
require at least three weeks which means we will need to take Trac off line to
do this. This means automatic updating via git commits will not be migrated and
will require manual updates once GitLab is available. We need the Trac tickets
in GitLab to be able to set up GitLab and migrate them to a suitable workflow.

7. Some mailings for administrative purposes will be removed.

I would like to thank those who have worked over the last 12 months to bring
this effort to life. This includes the people who were approached to sponsor the
work, RTEMS GitLab team and Amar for his efforts making this happen. It is a
complex task to secure the systems we run.

Regards
Chris
RTEMS GitLab Team - Amar, Chris, Gedare, Joel, Kinsey
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

RTEMS GitLab

Hi RTEMS Community

I would like to announce that RTEMS will be moving to GitLib in the coming month
or so. We do not have any exact dates yet and we will let you know when we do.
The change is large and complex because we are integrating an active open source
project made up of various pieces into a single platform.

1. A number of services we currently run will be locked to prevent further
modification but will remain available while we move, for example our current
Trac web site.

2. All repo default branches will be moved to `main` as part of the move. You
will need to migrate any repos you have to use `main` and we will provide
instructions when the time comes.

3. Accounts you may have will not be migrated. If you have a Trac account you
will need to create a new account on GitLab. Accounts will be protected by 2FA.

4. The initial roll out is to provide repo access with Merge Requests. Once live
there will be no need to send patches to mailing lists for review and 
integration.

5. We will provide more detail closer to the roll out of the projects in GitLab
and the approval process we will initially adopt. GitLab will be set up with an
initial set of roles and positions assigned to people. This is an initial
starting point and we are open to adding people who can help with the
administrative tasks we have.

6. Moving the tickets from Trac to GitLab is complicated and involved and will
require at least three weeks which means we will need to take Trac off line to
do this. This means automatic updating via git commits will not be migrated and
will require manual updates once GitLab is available. We need the Trac tickets
in GitLab to be able to set up GitLab and migrate them to a suitable workflow.

7. Some mailings for administrative purposes will be removed.

I would like to thank those who have worked over the last 12 months to bring
this effort to life. This includes the people who were approached to sponsor the
work, RTEMS GitLab team and Amar for his efforts making this happen. It is a
complex task to secure the systems we run.

Regards
Chris
RTEMS GitLab Team - Amar, Chris, Gedare, Joel, Kinsey
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-source-builder 1/2] rtems-tools-6.cfg: Bump hash to account for 5 months of changes

OK

Thanks
Chris

On 14/3/2024 7:00 am, Joel Sherrill wrote:
> In particular, the BSP set definitions for rtems-bsp-builder were
> out of sync with RTEMS and caused unnecessary failures reported to
> the build@ mailing list.
> ---
>  rtems/config/tools/rtems-tools-6.cfg | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/rtems/config/tools/rtems-tools-6.cfg 
> b/rtems/config/tools/rtems-tools-6.cfg
> index 7ef2052..8abfeea 100644
> --- a/rtems/config/tools/rtems-tools-6.cfg
> +++ b/rtems/config/tools/rtems-tools-6.cfg
> @@ -10,14 +10,14 @@
>   %define rtems_tools_source rtems-tools-%{rtems_tools_version}
>   %define rtems_tools_ext xz
>  %else
> - %define rtems_tools_version f408c0f8d935d53c232c67bed39e4018fd8d7a2a
> + %define rtems_tools_version 12971a8
>   %define rtems_tools_ext bz2
>  %endif
>  
>  %define rtems_tools_source rtems-tools-%{rtems_tools_version}
>  %source set rtems-tools 
> https://git.rtems.org/rtems-tools/snapshot/%{rtems_tools_source}.tar.%{rtems_tools_ext}
>  %hash   sha512 rtems-tools-%{rtems_tools_version}.tar.bz2 \
> -   
> xZIWwcW4y9wOsIY+8XWDAxKk51TwKFHeOw39SS6zxrgE0LOFxfpy/SQeidCRvOUieQPbEmZRUdLyFW1UDEHh3w==
> +  
> SrjY0gweRgWHmqBYj0wFnu1LFkaeNeS05SD1dKVzz2kvs3UCZ6AM8DrLbVe0q4H14DZwmrE3mMgbutsVev0Oxg==
>  
>  #
>  # Optionally enable/disable building the RTEMS Tools via the command line.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-tools] rtems-score-thread.ini: Remove _Thread_Close so trace examples link

OK

Thanks
Chris

On 12/3/2024 1:06 am, Joel Sherrill wrote:
> _Thread_Close no longer exists. There are multiple exapmles which
> show tracing in rtems-examples which fail to link due to this.
> ---
>  linkers/rtems-score-thread.ini | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/linkers/rtems-score-thread.ini b/linkers/rtems-score-thread.ini
> index 974bcfd..a759f72 100644
> --- a/linkers/rtems-score-thread.ini
> +++ b/linkers/rtems-score-thread.ini
> @@ -5,7 +5,7 @@
>  trace = _Thread_Handler_initialization, _Thread_Create_idle, 
> _Thread_Start_multitasking
>  trace = _Stack_Allocate, _Stack_Free, _Thread_Start
>  trace = _Thread_Yield, _Thread_Set_life_protection
> -trace = _Thread_Kill_zombies, _Thread_Close
> +trace = _Thread_Kill_zombies
>  trace = _Thread_Clear_state, _Thread_Set_state, _Thread_Load_environment
>  trace = _Thread_Handler
>  trace = _Thread_Get
> @@ -19,7 +19,7 @@ trace = _Stack_Allocate, _Thread_Start
>  trace = _Thread_Restart, _Thread_Handler
>  
>  [rtems-score-thread-destroy]
> -trace = _Thread_Kill_zombies, _Thread_Close
> +trace = _Thread_Kill_zombies
>  
>  [rtems-score-thread-activity]
>  trace = _Thread_Yield, _Thread_Set_life_protection
> @@ -38,7 +38,6 @@ _Thread_Start = Status_Control, Thread_Control*, const 
> Thread_Entry_information*
>  _Thread_Yield = void, Thread_Control*
>  _Thread_Set_life_protection = Thread_Life_state, Thread_Life_state
>  _Thread_Kill_zombies = void, void
> -_Thread_Close = void, Thread_Control*, Thread_Control*, Thread_Close_context*
>  _Thread_Clear_state = States_Control, Thread_Control*, States_Control
>  _Thread_Set_state = States_Control, Thread_Control*, States_Control
>  _Thread_Load_environment = void, Thread_Control*
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: MicroZed PHY timeout

2024-03-13 Thread Chris Johns

On 14/3/2024 2:00 am, Kinsey Moore wrote:
> As far as I know, the Zynq LibBSD CGEM support hasn't changed much beyond the 
> updates to support ZynqMP variants of the peripheral. Are you building LibBSD 
> master or 6-freebsd-12?
> 
> Kinsey
> 
> -Original Message-
> From: users  On Behalf Of Richard VanderWal
> Sent: Tuesday, March 12, 2024 11:34 AM
> To: RTEMS Users 
> Subject: MicroZed PHY timeout
> 
> Good Morning, 
> 
> We are moving our RTEMS 5.1 application on ARM 32 MicroZed hardware (BSP 
> arm/xilinx_zynq_zedboard) to the latest RTEMS master. We have found that the 
> cgem0 interface no longer is initialized and we’re seeing a “phy read 
> timeout: 1” message during boot. This appears to be happening in a call to 
> cgem_miibus_readreg called from cgem_probe. 
> 
> We’re running on actual Avnet MicroZed board not anything custom. 
> 
> Has anyone else encountered this? Any help is appreciated. 
> 

As a starting point and a guess I would check the clock to the PHY. If something
in the path to defining the PHY clock changed it could result in the PHY
appearing to no work. The cgem driver is being used on Zynq, ZynqMP and Versal
boards now and something may have touched the clock set up.

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

Re: rtems-6.1-rc2 on Mac OSX Sonoma 14.4 (Apple M2) failed -> fixed

2024-03-11 Thread Chris Johns

[ Sorry, my email does not show your message ]

Hi Heinz,

I see you are using brew on your M machine which is fine. As an alternative I
have documented using python.org:

 https://docs.rtems.org/branches/master/user/hosts/macos.html#python

and a virtual environment.

Chris

On 12/3/2024 2:09 pm, Heinz Junkes wrote:
> 
> ___
> 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: Multiple PowerPC BSPs Fail to BUIld

2024-03-11 Thread Chris Johns

On 11/3/2024 6:04 pm, Sebastian Huber wrote:
> sorry for breaking the build. I fixed it. The problem is that 
> header file depends on the BSP-provided define BSP_SHARED_HANDLER_SUPPORT. So,
> the include order matters.

Thank you for quickly sorting this out.

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

Re: [PATCH 4/6] build: Add support to make bootloader images

2024-03-10 Thread Chris Johns

On 7/3/2024 5:27 pm, Sebastian Huber wrote:
> On 07.03.24 02:09, Chris Johns wrote:
>> On 6/3/2024 8:33 am, Gedare Bloom wrote:
>>> If script generation needs to be done, it should be implemented in
>>> Python with input from the yml spec item as necessary to fill out a
>>> templated script with variables to customize for the BSP, and with
>>> appropriate injection of comments etc to allow traceability backward
>>> to the original source data and source program that generated the
>>> script.
>> We cannot import the YML data in external code without coping it as it all
>> resides in the wscript file. I would prefer seeing the YML python support 
>> moved
>> into `spec` as modules with unitests that can be imported. This would allow 
>> us
>> to add eco-system tools to support, manage and use the YML data.
> 
> The module to work with specification items is here:
> 
> https://github.com/RTEMS/rtems-central/blob/master/rtemsspec/items.py
> 
> This stuff has tests, code formatting, static analysis, and even a CI script.

This does not help rtens.git ans that is the scope of this patch set.

> Independent of this, working with the build specification items would be the
> wrong approach. You need the input of a configured BSP.

I do not understand what this means. What is the "input of a configured BSP"?

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

Re: Multiple PowerPC BSPs Fail to BUIld

2024-03-10 Thread Chris Johns

On 10/3/2024 8:40 am, Joel Sherrill wrote:
> Hi
> 
> In looking at the build sweep log, I see what looks like motorola_powerpc and
> beatnik all have a common build failure that results in 53 configurations
> failing per
> 
> https://lists.rtems.org/pipermail/build/2024-March/051698.html
> 
> This is one but there are a lot.
> 
> debug powerpc/mvme2307 build:
>       configure: /home/tester/rtems-cron-6/rtems/waf configure\
>       --prefix=/home/tester/rtems-cron-6/tools/6/bsps --top=/home/tester\
>       /rtems-cron-6/rtems --rtems-config=config-powerpc-mvme2307-debug.ini
>      error: home/tester/bsps/powerpc/include/bsp/irq_supp.h:87:65: error:
>             'rtems_irq_connect_data' {aka 'struct
>             __rtems_irq_connect_data__'} has no member named
>             'next_handler'
> 
> Anyone care to fix that?

There has been some PowerPC interrupt changes recently.

I do not have access to a mvme2700 to test these changes and awhen I can is not
known at this point in time. My concern is the interconnected relationship these
BSPs have makes them fragile. The last release that had working interrupts on
the mvme2700 was 4.10 and 5 did not work until I updated the release branch. We
had broken interrupts for years. I would like to avoid this if possible.

Chris

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

[RBW] Re: Video: Repairing Pam Murray's Silver shifters

2024-03-09 Thread JohnS


Thank you Eric for sharing! All good advice. Nothing worse than a small 
part falling on the shop floor and spending untold time groping around 
looking for it.

JohnS

PS - Which bike are you bringing to the Expo?

On Saturday, March 9, 2024 at 11:43:53 AM UTC-5 Pam Bikes wrote:

> I'm beyond amazed how great this group is to come together to fix my 
> broken shifters.  Thank you to Eric for taking them apart and to Mike 
> Godwin for the guts.  I love to repair things and get full utility out of 
> all components.  What a great video.
>
> On Friday, March 8, 2024 at 9:35:26 PM UTC-5 Tony Lockhart wrote:
>
>> Lovely video, Eric. Your shop gives me those Van Neistat vibes. Thanks 
>> for documenting this and sharing your process. 
>>
>>
>>
>> On Wednesday, March 6, 2024 at 4:48:05 AM UTC-8 eric...@gmail.com wrote:
>>
>>> Hi everyone — Last fall Pam Murray sent me some Silver shifter levers 
>>> that were in need of repair. They came off her high-mileage Betty Foy after 
>>> the springs wore out. 
>>>
>>> Thanks to Mike Godwin for sending me a broken pair of the old Suntour 
>>> Sprint levers, they provided the parts I needed to get Pam's shifters back 
>>> up and running. 
>>>
>>> I made a video about the process, it's up here: 
>>> https://youtu.be/0g67pjAPYZk
>>>
>>> I hope this is helpful to anyone looking to get their worn out or broken 
>>> Silver v1 or v2 shifters back into shape.
>>>
>>> Cheers! 
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/e0c5157b-4577-4acd-a64c-9c0845b0c1ebn%40googlegroups.com.

Re: [PATCH 4/6] build: Add support to make bootloader images

2024-03-06 Thread Chris Johns

On 6/3/2024 8:33 am, Gedare Bloom wrote:
> If script generation needs to be done, it should be implemented in
> Python with input from the yml spec item as necessary to fill out a
> templated script with variables to customize for the BSP, and with
> appropriate injection of comments etc to allow traceability backward
> to the original source data and source program that generated the
> script.

We cannot import the YML data in external code without coping it as it all
resides in the wscript file. I would prefer seeing the YML python support moved
into `spec` as modules with unitests that can be imported. This would allow us
to add eco-system tools to support, manage and use the YML data.

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

Re: [PATCH 5/6] build: Add mkimage support for powerpc/qoriq

2024-03-04 Thread Chris Johns

On 4/3/2024 6:35 pm, Sebastian Huber wrote:
> On 04.03.24 08:22, Chris Johns wrote:
>>> diff --git a/spec/build/bsps/powerpc/qoriq/mkimage.yml
>>> b/spec/build/bsps/powerpc/qoriq/mkimage.yml
>>> new file mode 100644
>>> index 00..712fd237b1
>>> --- /dev/null
>>> +++ b/spec/build/bsps/powerpc/qoriq/mkimage.yml
>>> @@ -0,0 +1,39 @@
>>> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
>>> +build-type: mkimage
>>> +content: |
>>> +  #!${PYTHON}
>>> +
>>> +  import gzip
>>> +  import os
>>> +  import shutil
>>> +  import subprocess
>>> +  import sys
>>> +  import tempfile
>>> +
>>> +  with tempfile.TemporaryDirectory() as tmp_dir:
>>> +  bin_path = os.path.join(tmp_dir, "bin")
>>> +  gz_path = os.path.join(tmp_dir, "gz")
>>> +  subprocess.run([
>>> +  "${OBJCOPY}",
>>> +  "-O", "binary", sys.argv[1], bin_path
>>> +  ],
>>> + check=True)
>>> +  with open(bin_path, "rb") as f_bin:
>>> +  with gzip.open(gz_path, "wb") as f_gz:
>>> +  shutil.copyfileobj(f_bin, f_gz)
>>> +  subprocess.run([
>>> +  "${U_BOOT_MKIMAGE}",
>>> +  "-A", "ppc", "-O", "linux", "-T", "kernel", "-a", "0x4000", "-e",
>>> +  "0x4000", "-n", "RTEMS", "-d", gz_path, sys.argv[2]
>>> +  ],
>>> + check=True)
>> Sorry this patch is a no from me and adding python like this with such 
>> limited
>> error checking is something I am not comfortable with.
>>
>> I am OK wih a python module that something robust can import and validate 
>> giving
>> the user consistent and meaningful error messages but as I have just said 
>> whole
>> programs in spec files like this, sorry thet is no from me.
> 
> Python exceptions usually give a lot of context, but sure you always can 
> improve
> things. 

Lets define and implement what we want from the start. I do not think I am
asking for a major piece of work to be written but this task has some ground
work that needs to be established with an architecture that scales. It is an
important feature we need so I am happy to find a suitable initial starting 
point.

> If someone doesn't like the error handling in a mkimage script he can
> improve it through patches.
> 
> The script may have to know details of the BSP configuration, so what would be
> your approach to address this?

As a said a loadable module of code that confirms to an API to export the "BSP
configuration" as an option. That module would be wrapped in a generic command
that validates the module and handles the error checking presenting the user
with errors messages that are not language based or implementation specific.

A key point is defining what is exported.

The command line tool can be in rtems-tools and based on the framework there if
that helps. The imported module could contain variables, a class or a series of
calls. For example:

 m.py

 USES_TEMPFILE = True

Then you can:

 import m
 if hasattr(m, 'USES_TEMPFILE') and m.USES_TEMPFILE:
   # get a temp file
   try:
 m.something()
   finally:
 # clean up temp file

The tool can be focused on your use case with a stable command line interface
yet extendible.

> With the script in the build specification item
> you can simply use the variable substitution. I don't think these scripts will
> be super complex, just a sequence of commands.

May be it is simpler if we just say no host code fragments like this in spec
files? I fine and relieved if that is the case. It would forced formalisation of
the exporting of these parameters, something I think we need long term.

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

Re: [PATCH 5/6] build: Add mkimage support for powerpc/qoriq

2024-03-03 Thread Chris Johns

On 28/2/2024 2:15 am, Sebastian Huber wrote:
> Update #4272.
> ---
>  spec/build/bsps/optpython.yml | 14 
>  spec/build/bsps/optubootmkimage.yml   | 20 
>  spec/build/bsps/powerpc/qoriq/grp.yml |  6 
>  spec/build/bsps/powerpc/qoriq/mkimage.yml | 39 +++
>  4 files changed, 79 insertions(+)
>  create mode 100644 spec/build/bsps/optpython.yml
>  create mode 100644 spec/build/bsps/optubootmkimage.yml
>  create mode 100644 spec/build/bsps/powerpc/qoriq/mkimage.yml
> 
> diff --git a/spec/build/bsps/optpython.yml b/spec/build/bsps/optpython.yml
> new file mode 100644
> index 00..15e0e500e6
> --- /dev/null
> +++ b/spec/build/bsps/optpython.yml
> @@ -0,0 +1,14 @@
> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> +actions:
> +- script: |
> +value = sys.executable
> +- env-assign: PYTHON
> +build-type: option
> +copyrights:
> +- Copyright (C) 2024 embedded brains GmbH & Co. KG
> +default: []
> +description: ''
> +enabled-by: true
> +links: []
> +name: PYTHON
> +type: build
> diff --git a/spec/build/bsps/optubootmkimage.yml 
> b/spec/build/bsps/optubootmkimage.yml
> new file mode 100644
> index 00..65a996be50
> --- /dev/null
> +++ b/spec/build/bsps/optubootmkimage.yml
> @@ -0,0 +1,20 @@
> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> +actions:
> +- get-string: null
> +- substitute: null
> +- find-optional-program: null
> +- env-assign: U_BOOT_MKIMAGE
> +build-type: option
> +copyrights:
> +- Copyright (C) 2024 embedded brains GmbH & Co. KG
> +default:
> +- enabled-by: true
> +  value: mkimage
> +description: |
> +  This build option defines the name of the U-Boot boot loader tool to make 
> an
> +  image.
> +enabled-by: true
> +format: '{}'
> +links: []
> +name: U_BOOT_MKIMAGE
> +type: build
> diff --git a/spec/build/bsps/powerpc/qoriq/grp.yml 
> b/spec/build/bsps/powerpc/qoriq/grp.yml
> index 65e623fdbd..cb96682722 100644
> --- a/spec/build/bsps/powerpc/qoriq/grp.yml
> +++ b/spec/build/bsps/powerpc/qoriq/grp.yml
> @@ -18,6 +18,10 @@ links:
>uid: ../../objirq
>  - role: build-dependency
>uid: ../../optconsolebaud
> +- role: build-dependency
> +  uid: ../../optobjcopy
> +- role: build-dependency
> +  uid: ../../optubootmkimage
>  - role: build-dependency
>uid: ../crti
>  - role: build-dependency
> @@ -114,6 +118,8 @@ links:
>uid: optuartirq
>  - role: build-dependency
>uid: start
> +- role: build-dependency
> +  uid: mkimage
>  - role: build-dependency
>uid: ../../bspopts
>  type: build
> diff --git a/spec/build/bsps/powerpc/qoriq/mkimage.yml 
> b/spec/build/bsps/powerpc/qoriq/mkimage.yml
> new file mode 100644
> index 00..712fd237b1
> --- /dev/null
> +++ b/spec/build/bsps/powerpc/qoriq/mkimage.yml
> @@ -0,0 +1,39 @@
> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> +build-type: mkimage
> +content: |
> +  #!${PYTHON}
> +
> +  import gzip
> +  import os
> +  import shutil
> +  import subprocess
> +  import sys
> +  import tempfile
> +
> +  with tempfile.TemporaryDirectory() as tmp_dir:
> +  bin_path = os.path.join(tmp_dir, "bin")
> +  gz_path = os.path.join(tmp_dir, "gz")
> +  subprocess.run([
> +  "${OBJCOPY}",
> +  "-O", "binary", sys.argv[1], bin_path
> +  ],
> + check=True)
> +  with open(bin_path, "rb") as f_bin:
> +  with gzip.open(gz_path, "wb") as f_gz:
> +  shutil.copyfileobj(f_bin, f_gz)
> +  subprocess.run([
> +  "${U_BOOT_MKIMAGE}",
> +  "-A", "ppc", "-O", "linux", "-T", "kernel", "-a", "0x4000", "-e",
> +  "0x4000", "-n", "RTEMS", "-d", gz_path, sys.argv[2]
> +  ],
> + check=True)

Sorry this patch is a no from me and adding python like this with such limited
error checking is something I am not comfortable with.

I am OK wih a python module that something robust can import and validate giving
the user consistent and meaningful error messages but as I have just said whole
programs in spec files like this, sorry thet is no from me.

Chris

> +copyrights:
> +- Copyright (C) 2024 embedded brains GmbH & Co. KG
> +enabled-by:
> +  and:
> +  - HAVE_OBJCOPY
> +  - HAVE_U_BOOT_MKIMAGE
> +links:
> +- role: build-dependency
> +  uid: ../../optpython
> +type: build
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 4/6] build: Add support to make bootloader images

2024-03-03 Thread Chris Johns

On 1/3/2024 9:57 pm, Sebastian Huber wrote:
> On 29.02.24 00:05, Chris Johns wrote:
>>>> If it is will the details be exported in the pkgconfig file and made 
>>>> available
>>>> for users building applications in a consistent and easy to use way?
>>> Application build systems can query the tool using the RTEMS_MKIMAGE package
>>> configuration varible, for example:
>>>
>>>    pkg-config --variable=RTEMS_MKIMAGE
>>> ${prefix}/lib/pkgconfig/${ARCH}-${BSP_NAME}.pc
>> Nice. This is my preferred way of handling this.
>>
>>> If the BSP does not provide a tool, then the variable RTEMS_MKIMAGE is set 
>>> to
>>> "false".
>> So the process has to be a single command?
> 
> Yes, a single command which is written in Python. For the U-Boot image it
> converts the ELF file to binary, then to a gz file, then to the U-Boot image.

I see it is in a YAML spec file. Sorry that is a no from me. See below.

I have learnt the hard way from the RSB and others we need to be precise with
these interfaces and it is best we consider and review them before we launch 
them.

>>> It could help to export also EXEEXT and BOOT_IMAGE_EXTENSION in the package
>>> configuration file. For RTEMS 6, we should have a look how our package
>>> configuration support can be used to build applications on some commonly 
>>> used
>>> build systems. We are currently not able to produce build images.
>> Yes we should. I also wonder if base addresses and other values that get used
>> should be prov
>>
>>>> Is this output created along side the ELF file?
>>> Yes.
>> +1
>>
>>>> Does this approach handle all BSPs that need this?
>>> The BSP can use Python, so I would say yes.
>> I am sorry I do not follow.
> 
> The script is written in Python, so this should be good enough to generate 
> boot
> images for all kinds of BSPs.

Python is good but I am not convinced we should allow all the code (or any code)
to resides in the spec YML file as you have. For example the code you have
posted for this command uses uboot's mkimage command and I am not comfortable we
make a host OS specific dependency that has no configure check (I can see), ie
does this patch set build on an M class MacOS machine without brew or macports
help. [1]

I cautious of host code being included in spec files. It is too easy to sneak in
code we depend that creates untracked dependencies and then who cleans that up?
Reverting a patch like this because we find one later would be counter
productive to everyone.

I am happy if we add a command to the rtems-tool repo that can find and import a
python module installed by a BSP or resident in the build tree but it needs to
be python end to end and not reliant on a subprocess call unless the subprocess
call uses a tool installed by the RSB. The import interface would need to
specified so it can be supported long term.

And the problem with your code is a lack of error handling. We should avoid
python exceptions for user errors. They should be for program errors.

[1] https://git.rtems.org/rtems-tools/tree/misc/tools/mkimage.py

>>>> Will you be converting all BSPs that need this type of support?
>>> I will add support for the BSPs using U-Boot.
>> Could you please provide the high level view of how this is to be handled? I
>> have not reviewed all the detail in the patches to understand this and even 
>> then
>> I may get things wrong.
> 
> The BSP provides an optional script to convert an ELF file into a boot image. 
> In
> a Makefile it could be used like this:
> 
> EXEEXT = $(shell pkg-config --variable=EXEEXT $(PKG_CONFIG))
> RTEMS_MKIMAGE = $(shell pkg-config --variable=RTEMS_MKIMAGE $(PKG_CONFIG))
> 
> ifeq ($(RTEMS_MKIMAGE), false)
> APP = $(BUILDDIR)/app$(EXEEXT)
> else
> BOOT_IMAGE_EXTENSION = $(shell pkg-config --variable=BOOT_IMAGE_EXTENSION
> $(PKG_CONFIG))
> APP = $(BUILDDIR)/app$(BOOT_IMAGE_EXTENSION)
> 
> %$(BOOT_IMAGE_EXTENSION): %$(EXEEXT)
> $(RTEMS_MKIMAGE) $^ $@
> endif
> 
>> Should we create a GSoC project to review and support the other BSPs?
> 
> I would add the boot image support only if needed. There are probably more
> important things to do.

The idea of the project would be investigating which other BSPs need this. An an
example
https://github.com/epics-base/epics-base/blob/7.0/configure/os/CONFIG.Common.RTEMS-mvme2700.
There are other example we need to clean up.

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

Re: [RFC] libdl: Make Elf_Sym::st_other available

2024-03-03 Thread Chris Johns

On 1/3/2024 6:05 pm, Sebastian Huber wrote:
> On 29.02.24 00:27, Chris Johns wrote:
>> On 27/2/2024 6:46 pm, Sebastian Huber wrote:
>>> The 64-bit PowerPC ELFv2 relocation support needs access to the
>>> Elf_Sym::st_other symbol information.  The machine-specific relocation 
>>> handler
>>> had only access to the Elf_Sym::st_info symbol information.  This change
>>> extends the 8-bit syminfo parameter to 16-bit and uses the additional
>>> 8-bits to provide Elf_Sym::st_other.  Another approach could be to pass
>>> a pointer to an Elf_Sym object instead of symname, syminfo, and
>>> symvalue.
>>
>> I think symname and symvalue have to stay or the code needed to support them
>> moves out to all reloc handlers [1]. I agree there is a limit to the number 
>> args
>> to keep adding. If there is a need for more fields then it may pay to pass in
>> Elf_Sym* or rtems_rtl_obj_sym* which is the symbol table reference?
>>
>> Chris
>>
>> [1] https://git.rtems.org/rtems/tree/cpukit/libdl/rtl-elf.c#n429
> 
> What do you prefer, a new st_other parameter, use Elf_Sym*, or use
> rtems_rtl_obj_sym*?
> 
> The
> 
> /**
>  * An object file symbol.
>  */
> typedef struct rtems_rtl_obj_sym
> {
>   rtems_chain_node node;    /**< The node's link in the chain. */
>   const char*  name;    /**< The symbol's name. */
>   void*    value;   /**< The value of the symbol. */
>   uint32_t data;    /**< Format specific data. */
> } rtems_rtl_obj_sym;
> 
> has no st_info and st_other members. I tend to pass a Elf_Sym* pointer.

Ah thanks. I think Elf_Sym* as changes to sizeof(rtems_rtl_obj_sym) effects the
size of the runtime symbol table. The data you need is only for resolving that
obj's relocs and nothing more if I understand things correctly.

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

Re: [PATCH] build: Use -frandom-seed=0

2024-02-29 Thread Chris Johns

On 29/2/2024 6:36 pm, Sebastian Huber wrote:
> On 29.02.24 00:29, Chris Johns wrote:
>> On 28/2/2024 6:24 pm, Sebastian Huber wrote:
>>> On 28.02.24 06:34, Chris Johns wrote:
>>>> The manual says:
>>>>
>>>>     The string can either be a number (decimal, octal or hex) or
>>>>     an arbitrary string (in which case it’s converted to a number by
>>>>     computing CRC32).
>>>>
>>>>     The string should be different for every file you compile.
>>>>
>>>> I take this to mean the option `-frandom-seed=0` uses `0` as a number
>>>> however it
>>>> is the same for every file and the manual clearly says it must be 
>>>> different?
>>> Using -frandom-seed=0 seems to be quite common on the internet. The random 
>>> seed
>>> is rarely used in GCC. The only use case in RTEMS I found is related to the 
>>> gcov
>>> code coverage instrumentation.
>> There are lots of things that are common on the internet I ignore 😉
>>
>> Is this a bug in the documentation?
> 
> From my point of view this random seed is a gray area in the compiler. The 
> cases
> in which it is used should not matter for the RTEMS build (except for the code
> coverage):
> 
> https://gcc.gnu.org/pipermail/gcc-help/2024-February/143324.html
> 
> I will try to add it only to the coverage flags.

I would prefer knowing which path is right. If the documentation for gcc says
not to do something then I am not sure it is good for us to add it anywhere. For
example it is working now in your testing but a future release of gcc changes
and subtle issues appear our testing does not pick up. If the gcc maintainers
say it is OK then I am fine but they need to update their documentation. I know
nothing about this options so it is difficult for me to say yes to the change
when it is in conflict to the published documentation. Others may have a
different view.

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

Re: 6.1rc2 on Rocky 9

2024-02-29 Thread Chris Johns

On 1/3/2024 2:43 am, Joel Sherrill wrote:
> Hi
> 
> Looks pretty good overall. This appears to be the only issue:
> 
> Testing: riscv rv64imac_spike
> BSP to Build: rv64imac
> 'distclean' finished successfully (0.011s)
> Regenerate build specification cache (needs a couple of seconds)...
> 
> real 0m25.545s
> user 2m30.639s
> sys 0m29.614s
> *** /home/joel/rtems-6.1rc2/rtems
> Exception in thread _stdout[spike]:
> Traceback (most recent call last):
>   File "/opt/rh/rh-python36/root/usr/lib64/python3.6/threading.py", line 916, 
> in
> _bootstrap_inner
>     self.run()
>   File "/opt/rh/rh-python36/root/usr/lib64/python3.6/threading.py", line 864, 
> in run
>     self._target(*self._args, **self._kwargs)
>   File "/home/joel/rtems-6.1rc2/tools/6/share/rtems/rtemstoolkit/execute.py",
> line 226, in _readthread
>     data = data.decode(sys.stdout.encoding)
> UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 0: 
> invalid
> start byte

This looks like rtems-tools needs to be updated to use the same decoder as the 
RSB:

https://git.rtems.org/rtems-source-builder/tree/source-builder/sb/execute.py#n185

Happy to review a patch and your ever improving python skills :)

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

Re: [RTEMS Tools 1/4] linkers: Avoid void pointer arithmetic

OK too all and thanks

Chris

On 26/2/2024 8:41 pm, Sebastian Huber wrote:
> ---
>  linkers/rtems-syms.cpp | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/linkers/rtems-syms.cpp b/linkers/rtems-syms.cpp
> index f0ac2bb..9fe552e 100644
> --- a/linkers/rtems-syms.cpp
> +++ b/linkers/rtems-syms.cpp
> @@ -322,9 +322,9 @@ output_sym::operator ()(const 
> rld::symbols::symtab::value_type& value)
>if (sym.type () == STT_TLS) {
>  c.write_line ("#define RTEMS_TLS_INDEX_" + sym.name () + " " + 
> std::to_string(index));
>  c.write_line ("static size_t rtems_rtl_tls_" + sym.name () + "(void) 
> {");
> -c.write_line ("  extern __thread void* "  + sym.name () +  ";");
> -c.write_line ("  const void* tls_base = rtems_rtl_tls_get_base ();");
> -c.write_line ("  const void* tls_addr = (void*) &"  + sym.name () +  
> ";");
> +c.write_line ("  extern __thread char "  + sym.name () +  "[];");
> +c.write_line ("  size_t tls_base = (size_t) rtems_rtl_tls_get_base 
> ();");
> +c.write_line ("  size_t tls_addr = (size_t) "  + sym.name () +  ";");
>  c.write_line ("  return tls_addr - tls_base;");
>  c.write_line ("}");
>  c.write_line ("");
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] build: Use -frandom-seed=0

On 28/2/2024 6:24 pm, Sebastian Huber wrote:
> On 28.02.24 06:34, Chris Johns wrote:
>> The manual says:
>>
>>    The string can either be a number (decimal, octal or hex) or
>>    an arbitrary string (in which case it’s converted to a number by
>>    computing CRC32).
>>
>>    The string should be different for every file you compile.
>>
>> I take this to mean the option `-frandom-seed=0` uses `0` as a number 
>> however it
>> is the same for every file and the manual clearly says it must be different?
> 
> Using -frandom-seed=0 seems to be quite common on the internet. The random 
> seed
> is rarely used in GCC. The only use case in RTEMS I found is related to the 
> gcov
> code coverage instrumentation.

There are lots of things that are common on the internet I ignore ;)

Is this a bug in the documentation?

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

Re: [RFC] libdl: Make Elf_Sym::st_other available

On 27/2/2024 6:46 pm, Sebastian Huber wrote:
> The 64-bit PowerPC ELFv2 relocation support needs access to the
> Elf_Sym::st_other symbol information.  The machine-specific relocation handler
> had only access to the Elf_Sym::st_info symbol information.  This change
> extends the 8-bit syminfo parameter to 16-bit and uses the additional
> 8-bits to provide Elf_Sym::st_other.  Another approach could be to pass
> a pointer to an Elf_Sym object instead of symname, syminfo, and
> symvalue.

I think symname and symvalue have to stay or the code needed to support them
moves out to all reloc handlers [1]. I agree there is a limit to the number args
to keep adding. If there is a need for more fields then it may pay to pass in
Elf_Sym* or rtems_rtl_obj_sym* which is the symbol table reference?

Chris

[1] https://git.rtems.org/rtems/tree/cpukit/libdl/rtl-elf.c#n429
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [Tools] add libiberty/argv.c for mingw32 build

OK

Thanks
Chris

On 28/2/2024 7:25 pm, Sebastian Huber wrote:
> From: zhengxiaojun 
> 
> Signed-off-by: zhengxiaojun 
> 
> Close #4974.
> ---
>  rtemstoolkit/wscript | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/rtemstoolkit/wscript b/rtemstoolkit/wscript
> index 20b1047..0611e2e 100644
> --- a/rtemstoolkit/wscript
> +++ b/rtemstoolkit/wscript
> @@ -399,9 +399,9 @@ def conf_libiberty(conf):
>  def bld_libiberty(bld, conf):
>  defines = ['HAVE_CONFIG_H=1']
>  if bld.env.DEST_OS == 'win32':
> -pex_host = 'libiberty/pex-win32.c'
> +pex_host = ['libiberty/pex-win32.c','libiberty/argv.c']
>  else:
> -pex_host = 'libiberty/pex-unix.c'
> +pex_host = ['libiberty/pex-unix.c']
>  if bld.env.DEST_OS == 'darwin':
>  defines += ['HAVE_SPAWN_H=1', 'HAVE_POSIX_SPAWN=1', 
> 'HAVE_POSIX_SPAWNP=1']
>  bld.stlib(target = 'iberty',
> @@ -410,8 +410,7 @@ def bld_libiberty(bld, conf):
>includes = ['libiberty'],
>cflags = conf['cflags'],
>defines = defines,
> -  source =['libiberty/argv.c',
> -   'libiberty/concat.c',
> +  source =['libiberty/concat.c',
> 'libiberty/cplus-dem.c',
> 'libiberty/cp-demangle.c',
> 'libiberty/d-demangle.c',
> @@ -426,8 +425,7 @@ def bld_libiberty(bld, conf):
> 'libiberty/xmalloc.c',
> 'libiberty/xmemdup.c',
> 'libiberty/xstrdup.c',
> -   'libiberty/xstrerror.c',
> -   pex_host])
> +   'libiberty/xstrerror.c'] + pex_host)
>  
>  #
>  # The doxy command.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 4/6] build: Add support to make bootloader images

On 28/2/2024 6:44 pm, Sebastian Huber wrote:
> On 28.02.24 06:48, Chris Johns wrote:
>> Hi,
>>
>> Is this to allow BSP ready output to be created from the build system?
> 
> Yes, this is the goal.

Nice and thanks for looking into this.

>> If it is will the details be exported in the pkgconfig file and made 
>> available
>> for users building applications in a consistent and easy to use way?
> 
> Application build systems can query the tool using the RTEMS_MKIMAGE package
> configuration varible, for example:
> 
>   pkg-config --variable=RTEMS_MKIMAGE
> ${prefix}/lib/pkgconfig/${ARCH}-${BSP_NAME}.pc

Nice. This is my preferred way of handling this.

> If the BSP does not provide a tool, then the variable RTEMS_MKIMAGE is set to
> "false".

So the process has to be a single command?

> It could help to export also EXEEXT and BOOT_IMAGE_EXTENSION in the package
> configuration file. For RTEMS 6, we should have a look how our package
> configuration support can be used to build applications on some commonly used
> build systems. We are currently not able to produce build images.

Yes we should. I also wonder if base addresses and other values that get used
should be prov

>> Is this output created along side the ELF file?
> 
> Yes.

+1

>> Does this approach handle all BSPs that need this?
> 
> The BSP can use Python, so I would say yes.

I am sorry I do not follow.

>> Will you be converting all BSPs that need this type of support?
> 
> I will add support for the BSPs using U-Boot.

Could you please provide the high level view of how this is to be handled? I
have not reviewed all the detail in the patches to understand this and even then
I may get things wrong.

Should we create a GSoC project to review and support the other BSPs?

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

Re: [Tools] rtemstoolkit/libierty: Add missing file

OK and thanks

Chris

On 27/2/2024 9:56 pm, Sebastian Huber wrote:
> This fixes the following build error for --host=x86_64-w64-mingw32:
> 
> rtemstoolkit/libiberty.a(pex-win32.c.18.o): in function `win32_spawn':
> rtemstoolkit/libiberty/pex-win32.c:643: undefined reference to `writeargv'
> 
> Update #4969.
> ---
>  rtemstoolkit/libiberty/argv.c | 568 ++
>  rtemstoolkit/wscript  |   3 +-
>  2 files changed, 570 insertions(+), 1 deletion(-)
>  create mode 100644 rtemstoolkit/libiberty/argv.c
> 
> diff --git a/rtemstoolkit/libiberty/argv.c b/rtemstoolkit/libiberty/argv.c
> new file mode 100644
> index 000..a95a10e
> --- /dev/null
> +++ b/rtemstoolkit/libiberty/argv.c
> @@ -0,0 +1,568 @@
> +/* Create and destroy argument vectors (argv's)
> +   Copyright (C) 1992-2023 Free Software Foundation, Inc.
> +   Written by Fred Fish @ Cygnus Support
> +
> +This file is part of the libiberty library.
> +Libiberty is free software; you can redistribute it and/or
> +modify it under the terms of the GNU Library General Public
> +License as published by the Free Software Foundation; either
> +version 2 of the License, or (at your option) any later version.
> +
> +Libiberty is distributed in the hope that it will be useful,
> +but WITHOUT ANY WARRANTY; without even the implied warranty of
> +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> +Library General Public License for more details.
> +
> +You should have received a copy of the GNU Library General Public
> +License along with libiberty; see the file COPYING.LIB.  If
> +not, write to the Free Software Foundation, Inc., 51 Franklin Street - Fifth 
> Floor,
> +Boston, MA 02110-1301, USA.  */
> +
> +
> +/*  Create and destroy argument vectors.  An argument vector is simply an
> +array of string pointers, terminated by a NULL pointer. */
> +
> +#ifdef HAVE_CONFIG_H
> +#include "config.h"
> +#endif
> +#include "ansidecl.h"
> +#include "libiberty.h"
> +#include "safe-ctype.h"
> +
> +/*  Routines imported from standard C runtime libraries. */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#ifdef HAVE_UNISTD_H
> +#include 
> +#endif
> +#if HAVE_SYS_STAT_H
> +#include 
> +#endif
> +
> +#ifndef NULL
> +#define NULL 0
> +#endif
> +
> +#ifndef EOS
> +#define EOS '\0'
> +#endif
> +
> +#define INITIAL_MAXARGC 8/* Number of args + NULL in initial argv */
> +
> +
> +/*
> +
> +@deftypefn Extension char** dupargv (char * const *@var{vector})
> +
> +Duplicate an argument vector.  Simply scans through @var{vector},
> +duplicating each argument until the terminating @code{NULL} is found.
> +Returns a pointer to the argument vector if successful.  Returns
> +@code{NULL} if there is insufficient memory to complete building the
> +argument vector.
> +
> +@end deftypefn
> +
> +*/
> +
> +char **
> +dupargv (char * const *argv)
> +{
> +  int argc;
> +  char **copy;
> +  
> +  if (argv == NULL)
> +return NULL;
> +  
> +  /* the vector */
> +  for (argc = 0; argv[argc] != NULL; argc++);
> +  copy = (char **) xmalloc ((argc + 1) * sizeof (char *));
> +
> +  /* the strings */
> +  for (argc = 0; argv[argc] != NULL; argc++)
> +copy[argc] = xstrdup (argv[argc]);
> +  copy[argc] = NULL;
> +  return copy;
> +}
> +
> +/*
> +
> +@deftypefn Extension void freeargv (char **@var{vector})
> +
> +Free an argument vector that was built using @code{buildargv}.  Simply
> +scans through @var{vector}, freeing the memory for each argument until
> +the terminating @code{NULL} is found, and then frees @var{vector}
> +itself.
> +
> +@end deftypefn
> +
> +*/
> +
> +void freeargv (char **vector)
> +{
> +  register char **scan;
> +
> +  if (vector != NULL)
> +{
> +  for (scan = vector; *scan != NULL; scan++)
> + {
> +   free (*scan);
> + }
> +  free (vector);
> +}
> +}
> +
> +static void
> +consume_whitespace (const char **input)
> +{
> +  while (ISSPACE (**input))
> +{
> +  (*input)++;
> +}
> +}
> +
> +static int
> +only_whitespace (const char* input)
> +{
> +  while (*input != EOS && ISSPACE (*input))
> +input++;
> +
> +  return (*input == EOS);
> +}
> +
> +/*
> +
> +@deftypefn Extension char** buildargv (char *@var{sp})
> +
> +Given a pointer to a string, parse the string extracting fields
> +separated by whitespace and optionally enclosed within either single
> +or double quotes (which are stripped off), and build a vector of
> +pointers to copies of the string for each field.  The input string
> +remains unchanged.  The last element of the vector is followed by a
> +@code{NULL} element.
> +
> +All of the memory for the pointer array and copies of the string
> +is obtained from @code{xmalloc}.  All of the memory can be returned to the
> +system with the single function call @code{freeargv}, which takes the
> +returned result of @code{buildargv}, as it's argument.
> +
> +Returns a pointer to the argument vector if successful.  Returns
> +@code{NULL} if @var{sp} is @code{NUL

Re: [Tools] rtemstoolkit/libierty: Add missing file

OK and thanks

Chris

On 27/2/2024 9:56 pm, Sebastian Huber wrote:
> This fixes the following build error for --host=x86_64-w64-mingw32:
> 
> rtemstoolkit/libiberty.a(pex-win32.c.18.o): in function `win32_spawn':
> rtemstoolkit/libiberty/pex-win32.c:643: undefined reference to `writeargv'
> 
> Update #4969.
> ---
>  rtemstoolkit/libiberty/argv.c | 568 ++
>  rtemstoolkit/wscript  |   3 +-
>  2 files changed, 570 insertions(+), 1 deletion(-)
>  create mode 100644 rtemstoolkit/libiberty/argv.c
> 
> diff --git a/rtemstoolkit/libiberty/argv.c b/rtemstoolkit/libiberty/argv.c
> new file mode 100644
> index 000..a95a10e
> --- /dev/null
> +++ b/rtemstoolkit/libiberty/argv.c
> @@ -0,0 +1,568 @@
> +/* Create and destroy argument vectors (argv's)
> +   Copyright (C) 1992-2023 Free Software Foundation, Inc.
> +   Written by Fred Fish @ Cygnus Support
> +
> +This file is part of the libiberty library.
> +Libiberty is free software; you can redistribute it and/or
> +modify it under the terms of the GNU Library General Public
> +License as published by the Free Software Foundation; either
> +version 2 of the License, or (at your option) any later version.
> +
> +Libiberty is distributed in the hope that it will be useful,
> +but WITHOUT ANY WARRANTY; without even the implied warranty of
> +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> +Library General Public License for more details.
> +
> +You should have received a copy of the GNU Library General Public
> +License along with libiberty; see the file COPYING.LIB.  If
> +not, write to the Free Software Foundation, Inc., 51 Franklin Street - Fifth 
> Floor,
> +Boston, MA 02110-1301, USA.  */
> +
> +
> +/*  Create and destroy argument vectors.  An argument vector is simply an
> +array of string pointers, terminated by a NULL pointer. */
> +
> +#ifdef HAVE_CONFIG_H
> +#include "config.h"
> +#endif
> +#include "ansidecl.h"
> +#include "libiberty.h"
> +#include "safe-ctype.h"
> +
> +/*  Routines imported from standard C runtime libraries. */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#ifdef HAVE_UNISTD_H
> +#include 
> +#endif
> +#if HAVE_SYS_STAT_H
> +#include 
> +#endif
> +
> +#ifndef NULL
> +#define NULL 0
> +#endif
> +
> +#ifndef EOS
> +#define EOS '\0'
> +#endif
> +
> +#define INITIAL_MAXARGC 8/* Number of args + NULL in initial argv */
> +
> +
> +/*
> +
> +@deftypefn Extension char** dupargv (char * const *@var{vector})
> +
> +Duplicate an argument vector.  Simply scans through @var{vector},
> +duplicating each argument until the terminating @code{NULL} is found.
> +Returns a pointer to the argument vector if successful.  Returns
> +@code{NULL} if there is insufficient memory to complete building the
> +argument vector.
> +
> +@end deftypefn
> +
> +*/
> +
> +char **
> +dupargv (char * const *argv)
> +{
> +  int argc;
> +  char **copy;
> +  
> +  if (argv == NULL)
> +return NULL;
> +  
> +  /* the vector */
> +  for (argc = 0; argv[argc] != NULL; argc++);
> +  copy = (char **) xmalloc ((argc + 1) * sizeof (char *));
> +
> +  /* the strings */
> +  for (argc = 0; argv[argc] != NULL; argc++)
> +copy[argc] = xstrdup (argv[argc]);
> +  copy[argc] = NULL;
> +  return copy;
> +}
> +
> +/*
> +
> +@deftypefn Extension void freeargv (char **@var{vector})
> +
> +Free an argument vector that was built using @code{buildargv}.  Simply
> +scans through @var{vector}, freeing the memory for each argument until
> +the terminating @code{NULL} is found, and then frees @var{vector}
> +itself.
> +
> +@end deftypefn
> +
> +*/
> +
> +void freeargv (char **vector)
> +{
> +  register char **scan;
> +
> +  if (vector != NULL)
> +{
> +  for (scan = vector; *scan != NULL; scan++)
> + {
> +   free (*scan);
> + }
> +  free (vector);
> +}
> +}
> +
> +static void
> +consume_whitespace (const char **input)
> +{
> +  while (ISSPACE (**input))
> +{
> +  (*input)++;
> +}
> +}
> +
> +static int
> +only_whitespace (const char* input)
> +{
> +  while (*input != EOS && ISSPACE (*input))
> +input++;
> +
> +  return (*input == EOS);
> +}
> +
> +/*
> +
> +@deftypefn Extension char** buildargv (char *@var{sp})
> +
> +Given a pointer to a string, parse the string extracting fields
> +separated by whitespace and optionally enclosed within either single
> +or double quotes (which are stripped off), and build a vector of
> +pointers to copies of the string for each field.  The input string
> +remains unchanged.  The last element of the vector is followed by a
> +@code{NULL} element.
> +
> +All of the memory for the pointer array and copies of the string
> +is obtained from @code{xmalloc}.  All of the memory can be returned to the
> +system with the single function call @code{freeargv}, which takes the
> +returned result of @code{buildargv}, as it's argument.
> +
> +Returns a pointer to the argument vector if successful.  Returns
> +@code{NULL} if @var{sp} is @code{NUL

Re: [PATCH 4/6] build: Add support to make bootloader images

Hi,

Is this to allow BSP ready output to be created from the build system?

If it is will the details be exported in the pkgconfig file and made available
for users building applications in a consistent and easy to use way?

Is this output created along side the ELF file?

Does this approach handle all BSPs that need this?

Will you be converting all BSPs that need this type of support?

Thanks
Chris

On 28/2/2024 2:15 am, Sebastian Huber wrote:
> Add a new build item type to provide optional BSP-specific tools to make
> bootloader images.  The tools are installed as Python scripts in:
> 
>   ${prefix}/bin/rtems-mkimage-${ARCH}-${BSP_NAME}.py
>
> Application build systems can query the tool using the RTEMS_MKIMAGE package
> configuration varible, for example:
> 
>   pkg-config --variable=RTEMS_MKIMAGE 
> ${prefix}/lib/pkgconfig/${ARCH}-${BSP_NAME}.pc
> 
> If the BSP does not provide a tool, then the variable RTEMS_MKIMAGE is set to
> "false".
> 
> Update #4272.
> ---
>  spec/build/bsps/bspopts.yml  |  2 ++
>  spec/build/bsps/optpkgmkimage.yml| 19 ++
>  spec/build/bsps/pkgconfig.yml|  1 +
>  spec/build/cpukit/cpuopts.yml|  4 +++
>  spec/build/cpukit/optbootimageext.yml| 17 +
>  spec/build/cpukit/optbuildbootimages.yml | 16 +
>  wscript  | 45 ++--
>  7 files changed, 102 insertions(+), 2 deletions(-)
>  create mode 100644 spec/build/bsps/optpkgmkimage.yml
>  create mode 100644 spec/build/cpukit/optbootimageext.yml
>  create mode 100644 spec/build/cpukit/optbuildbootimages.yml
> 
> diff --git a/spec/build/bsps/bspopts.yml b/spec/build/bsps/bspopts.yml
> index 734292f421..74fe6d17f9 100644
> --- a/spec/build/bsps/bspopts.yml
> +++ b/spec/build/bsps/bspopts.yml
> @@ -33,6 +33,8 @@ links:
>uid: optldflagsbsp
>  - role: build-dependency
>uid: optmakelegacy
> +- role: build-dependency
> +  uid: optpkgmkimage
>  - role: build-dependency
>uid: optprintexcpt
>  - role: build-dependency
> diff --git a/spec/build/bsps/optpkgmkimage.yml 
> b/spec/build/bsps/optpkgmkimage.yml
> new file mode 100644
> index 00..00d9a0171f
> --- /dev/null
> +++ b/spec/build/bsps/optpkgmkimage.yml
> @@ -0,0 +1,19 @@
> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> +actions:
> +- get-string: null
> +- substitute: null
> +- env-assign: null
> +build-type: option
> +copyrights:
> +- Copyright (C) 2024 embedded brains GmbH & Co. KG
> +default:
> +- enabled-by: HAVE_MKIMAGE
> +  value: $${prefix}/bin/rtems-mkimage-${ARCH}-${BSP_NAME}.py
> +- enabled-by: true
> +  value: 'false'
> +description: ''
> +enabled-by: true
> +format: '{}'
> +links: []
> +name: PKGCONFIG_MKIMAGE
> +type: build
> diff --git a/spec/build/bsps/pkgconfig.yml b/spec/build/bsps/pkgconfig.yml
> index afaffbbf0f..e1cdc9a70e 100644
> --- a/spec/build/bsps/pkgconfig.yml
> +++ b/spec/build/bsps/pkgconfig.yml
> @@ -20,6 +20,7 @@ content: |
>RTEMS_MAJOR=${__RTEMS_MAJOR__}
>RTEMS_MINOR=${__RTEMS_MINOR__}
>RTEMS_REVISION=${__RTEMS_REVISION__}
> +  RTEMS_MKIMAGE=${PKGCONFIG_MKIMAGE}
>  
>Name: ${ARCH}-rtems${__RTEMS_MAJOR__}-${BSP_NAME}
>Version: ${RTEMS_VERSION}
> diff --git a/spec/build/cpukit/cpuopts.yml b/spec/build/cpukit/cpuopts.yml
> index 1d28ace552..bdf8fc2f66 100644
> --- a/spec/build/cpukit/cpuopts.yml
> +++ b/spec/build/cpukit/cpuopts.yml
> @@ -75,6 +75,10 @@ links:
>uid: optcoverageldflags
>  - role: build-dependency
>uid: optnocoverageldflags
> +- role: build-dependency
> +  uid: optbootimageext
> +- role: build-dependency
> +  uid: optbuildbootimages
>  - role: build-dependency
>uid: optversion
>  target: cpukit/include/rtems/score/cpuopts.h
> diff --git a/spec/build/cpukit/optbootimageext.yml 
> b/spec/build/cpukit/optbootimageext.yml
> new file mode 100644
> index 00..c9347ffba8
> --- /dev/null
> +++ b/spec/build/cpukit/optbootimageext.yml
> @@ -0,0 +1,17 @@
> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> +actions:
> +- get-string: null
> +- env-assign: null
> +build-type: option
> +copyrights:
> +- Copyright (C) 2024 embedded brains GmbH & Co. KG
> +default:
> +- enabled-by: true
> +  value: .img
> +description: |
> +  Defines the file extension of boot images.
> +enabled-by: true
> +format: '{}'
> +links: []
> +name: BOOT_IMAGE_EXTENSION
> +type: build
> diff --git a/spec/build/cpukit/optbuildbootimages.yml 
> b/spec/build/cpukit/optbuildbootimages.yml
> new file mode 100644
> index 00..12328b006d
> --- /dev/null
> +++ b/spec/build/cpukit/optbuildbootimages.yml
> @@ -0,0 +1,16 @@
> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> +actions:
> +- get-boolean: null
> +- env-enable: null
> +build-type: option
> +copyrights:
> +- Copyright (C) 2024 embedded brains GmbH & Co. KG
> +default:
> +- enabled-by: true
> +  value: false
> +description: |
> +  If this option is enabled, then boot images for the test programs are 
> built.
> +enabled-by: true
> +l

Re: [PATCH 1/6] build: Fix script action

On 28/2/2024 2:15 am, Sebastian Huber wrote:
> We have to use a custom dictorary to be able to set the "value" argument

Spelling. :)

Chris

> in the exec() context.
> 
> Update #4272.
> ---
>  wscript | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/wscript b/wscript
> index a71e0d3f10..6c81083b2c 100755
> --- a/wscript
> +++ b/wscript
> @@ -1026,8 +1026,14 @@ class OptionItem(Item):
>  return value
>  
>  def _script(self, conf, cic, value, arg):
> -exec(arg)
> -return value
> +local_variables = {
> +"self": self,
> +"conf": conf,
> +"cic": cic,
> +"value": value
> +}
> +exec(arg, None, local_variables)
> +return local_variables["value"]
>  
>  def _test_state_benchmark(self, conf, name):
>  self._do_append_test_cppflags(conf, name, "-DTEST_STATE_BENCHMARK=1")
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] build: Use -frandom-seed=0

Hi,

The manual says:

  The string can either be a number (decimal, octal or hex) or
  an arbitrary string (in which case it’s converted to a number by
  computing CRC32).

  The string should be different for every file you compile.

I take this to mean the option `-frandom-seed=0` uses `0` as a number however it
is the same for every file and the manual clearly says it must be different?

Chris

On 28/2/2024 12:23 am, Sebastian Huber wrote:
> This makes the build reproducible.
> ---
>  spec/build/bsps/opto0.yml | 1 +
>  spec/build/bsps/opto1.yml | 1 +
>  spec/build/bsps/opto2.yml | 1 +
>  spec/build/bsps/optog.yml | 1 +
>  spec/build/bsps/optos.yml | 1 +
>  5 files changed, 5 insertions(+)
> 
> diff --git a/spec/build/bsps/opto0.yml b/spec/build/bsps/opto0.yml
> index de7ad1515e..bb59ce8cfa 100644
> --- a/spec/build/bsps/opto0.yml
> +++ b/spec/build/bsps/opto0.yml
> @@ -13,6 +13,7 @@ default:
>- -g
>- -fdata-sections
>- -ffunction-sections
> +  - -frandom-seed=0
>  description: |
>Default optimization flags for C and C++ compilers.
>  enabled-by: true
> diff --git a/spec/build/bsps/opto1.yml b/spec/build/bsps/opto1.yml
> index d3e0b6d361..b3bfea2dec 100644
> --- a/spec/build/bsps/opto1.yml
> +++ b/spec/build/bsps/opto1.yml
> @@ -13,6 +13,7 @@ default:
>- -g
>- -fdata-sections
>- -ffunction-sections
> +  - -frandom-seed=0
>  description: |
>Default optimization flags for C and C++ compilers.
>  enabled-by: true
> diff --git a/spec/build/bsps/opto2.yml b/spec/build/bsps/opto2.yml
> index ff4f1d23e0..068f2f075d 100644
> --- a/spec/build/bsps/opto2.yml
> +++ b/spec/build/bsps/opto2.yml
> @@ -13,6 +13,7 @@ default:
>- -g
>- -fdata-sections
>- -ffunction-sections
> +  - -frandom-seed=0
>  description: |
>Default optimization flags for C and C++ compilers.
>  enabled-by: true
> diff --git a/spec/build/bsps/optog.yml b/spec/build/bsps/optog.yml
> index de20502c78..7149d91e3b 100644
> --- a/spec/build/bsps/optog.yml
> +++ b/spec/build/bsps/optog.yml
> @@ -13,6 +13,7 @@ default:
>- -g
>- -fdata-sections
>- -ffunction-sections
> +  - -frandom-seed=0
>  description: |
>Default optimization flags for C and C++ compilers.
>  enabled-by: true
> diff --git a/spec/build/bsps/optos.yml b/spec/build/bsps/optos.yml
> index a39447ef36..12c96621f9 100644
> --- a/spec/build/bsps/optos.yml
> +++ b/spec/build/bsps/optos.yml
> @@ -13,6 +13,7 @@ default:
>- -g
>- -fdata-sections
>- -ffunction-sections
> +  - -frandom-seed=0
>  description: |
>Default optimization flags for C and C++ compilers.
>  enabled-by: true
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] powerpc: Use RTEMS_XCONCAT()

OK

Thanks
Chris

On 28/2/2024 2:20 am, Sebastian Huber wrote:
> Prefer macros with a proper namespace.
> ---
>  cpukit/score/cpu/powerpc/include/rtems/asm.h | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/cpukit/score/cpu/powerpc/include/rtems/asm.h 
> b/cpukit/score/cpu/powerpc/include/rtems/asm.h
> index 27af64e724..94f54245b4 100644
> --- a/cpukit/score/cpu/powerpc/include/rtems/asm.h
> +++ b/cpukit/score/cpu/powerpc/include/rtems/asm.h
> @@ -75,23 +75,21 @@
>  #define __PROC_LABEL_PREFIX__  __USER_LABEL_PREFIX__
>  #endif
>  
> -#include 
> -
>  /* Use the right prefix for global labels.  */
>  
> -#define SYM(x) CONCAT1 (__USER_LABEL_PREFIX__, x)
> +#define SYM(x) RTEMS_XCONCAT (__USER_LABEL_PREFIX__, x)
>  
>  /* Use the right prefix for procedure labels.  */
>  
> -#define PROC(x) CONCAT1 (__PROC_LABEL_PREFIX__, x)
> +#define PROC(x) RTEMS_XCONCAT (__PROC_LABEL_PREFIX__, x)
>  
>  /* Use the right prefix for registers.  */
>  
> -#define REG(x) CONCAT1 (__REGISTER_PREFIX__, x)
> +#define REG(x) RTEMS_XCONCAT (__REGISTER_PREFIX__, x)
>  
>  /* Use the right prefix for floating point registers.  */
>  
> -#define FREG(x) CONCAT1 (__FLOAT_REGISTER_PREFIX__, x)
> +#define FREG(x) RTEMS_XCONCAT (__FLOAT_REGISTER_PREFIX__, x)
>  
>  /*
>   *  define macros for all of the registers on this CPU
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: 6.1rc2 Tool Build Failures