RTOS/RTEMS (rtems.git) history rewrite

[Chris Johns]

Hello,

A merge request was applied that contained a merge commit and a decision was
taken to correct this in the git repo. This means the history has been
rewritten. Please check your forks or clones if you have updated and pulled in
the merge commit.

We are looking into getting GitLab to flag this and block this from happening.

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

GitLab Workflows and Merge Requests

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

Issues in GitLab

[Chris Johns]

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

RTEMS Project Repos in GitLab

[Chris Johns]

 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

[Chris Johns]

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

GitLab Launch

[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

RTEMS Trac Ticket to GitLab import

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

[Chris Johns]

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

Re: MicroZed PHY timeout

[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: riscv target spec for newlib and rtems

[Chris Johns]

On 30/12/2023 1:05 pm, Joel Sherrill wrote:
> Chris... I thought the RSB was ok for Python 3 for RTEMS 5? Is it just on the
> branch? 

Sorry I am not sure what the status is.

> Matt..can you try the tip of the 5 branch? Looking at the log, I see commit
> messages about Python 3.

This is the way to go.

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

Re: rtems6 master on darwin-x86_64 fails building: arm-rtems6-gcc-814ec21-newlib-fbc5496-x86_64-apple-darwin22.6.0-1

[Chris Johns]

On 19/10/2023 6:25 am, Chris Johns wrote:
> On 18/10/2023 8:48 pm, Sebastian Huber wrote:
>> On 18.10.23 12:29, Heinz Junkes wrote:
>>> unfortunately also with the GCC 13.2 configuration still the same error:
>>> nclude -g -O2 -mthumb -O2
>>> -I../../../../gcc-13.2.0/libgcc/../newlib/libc/sys/rtems/include -g -O2
>>> -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings
>>> -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
>>> -isystem ./include -fno-inline -g -DIN_LIBGCC2 -fbuilding-libgcc
>>> -fno-stack-protector -Dinhibit_libc -fno-inline -I. -I. -I../../.././gcc
>>> -I../../../../gcc-13.2.0/libgcc -I../../../../gcc-13.2.0/libgcc/.
>>> -I../../../../gcc-13.2.0/libgcc/../gcc
>>> -I../../../../gcc-13.2.0/libgcc/../include -DHAVE_CC_TLS -o _divtc3.o -MT
>>> _divtc3.o -MD -MP -MF _divtc3.dep -DL_divtc3 -c
>>> ../../../../gcc-13.2.0/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS
>>> ../../../../gcc-13.2.0/libgcc/libgcc2.c: In function '__divdc3':
>>> ../../../../gcc-13.2.0/libgcc/libgcc2.c:2063:7: internal compiler error:
>>> Segmentation fault: 11 2063 | if (FABS (d) >= RBIG) | ^~ Please submit a 
>>> full
>>> bug report, with preprocessed source (by using -freport-bug). See
>>> <https://gcc.gnu.org/bugs/> for instructions. make[4]: *** [_divdc3.o] 
>>> Error 1
>>
>> Ok, great. At least it is consistent. Maybe GCC 10 works.
>>
>> This bug should be reported to the GCC project.
> 
> I have just built the RSB master on a Sonoma (14.0) MacBook M2 Pro 
> 
> (r-py3) chris@weka rtems %  
> /Users/chris/development/rtems/6/bin/arm-rtems6-gcc
> --version
> arm-rtems6-gcc (GCC) 12.3.1 20231012 (RTEMS 6, RSB
> 633023de6517998ee3b84e7ed172b1c5f2bf502b, Newlib fbc5496)
> Copyright (C) 2022 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> I am only using Xocde tools and related command line bits and pieces and a
> python.org installed Python with a virtual env.
> 
> I do not have an Intel Mac with me to test on that. I will when I return home.
> 

Sorry about the delay.

I can build 6/rtems-arm on Sonoma M2 with Xcode 15.0.1 and on Monterey (Intel)
with Xcode 14.2. I see the same error as you on Ventura (Intel) with Xcode 
15.0.1.

I have the file for a bug report but I have not filed it. You can find the file
here:

https://ftp.rtems.org/pub/rtems/people/chrisj/gcc/libgcc2-__divdc3.i

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

Re: rtems6 master on darwin-x86_64 fails building: arm-rtems6-gcc-814ec21-newlib-fbc5496-x86_64-apple-darwin22.6.0-1

[Chris Johns]

On 18/10/2023 8:48 pm, Sebastian Huber wrote:
> On 18.10.23 12:29, Heinz Junkes wrote:
>> unfortunately also with the GCC 13.2 configuration still the same error:
>> nclude -g -O2 -mthumb -O2
>> -I../../../../gcc-13.2.0/libgcc/../newlib/libc/sys/rtems/include -g -O2
>> -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings
>> -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
>> -isystem ./include -fno-inline -g -DIN_LIBGCC2 -fbuilding-libgcc
>> -fno-stack-protector -Dinhibit_libc -fno-inline -I. -I. -I../../.././gcc
>> -I../../../../gcc-13.2.0/libgcc -I../../../../gcc-13.2.0/libgcc/.
>> -I../../../../gcc-13.2.0/libgcc/../gcc
>> -I../../../../gcc-13.2.0/libgcc/../include -DHAVE_CC_TLS -o _divtc3.o -MT
>> _divtc3.o -MD -MP -MF _divtc3.dep -DL_divtc3 -c
>> ../../../../gcc-13.2.0/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS
>> ../../../../gcc-13.2.0/libgcc/libgcc2.c: In function '__divdc3':
>> ../../../../gcc-13.2.0/libgcc/libgcc2.c:2063:7: internal compiler error:
>> Segmentation fault: 11 2063 | if (FABS (d) >= RBIG) | ^~ Please submit a full
>> bug report, with preprocessed source (by using -freport-bug). See
>>  for instructions. make[4]: *** [_divdc3.o] Error 
>> 1
> 
> Ok, great. At least it is consistent. Maybe GCC 10 works.
> 
> This bug should be reported to the GCC project.

I have just built the RSB master on a Sonoma (14.0) MacBook M2 Pro 

(r-py3) chris@weka rtems %  /Users/chris/development/rtems/6/bin/arm-rtems6-gcc
--version
arm-rtems6-gcc (GCC) 12.3.1 20231012 (RTEMS 6, RSB
633023de6517998ee3b84e7ed172b1c5f2bf502b, Newlib fbc5496)
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I am only using Xocde tools and related command line bits and pieces and a
python.org installed Python with a virtual env.

I do not have an Intel Mac with me to test on that. I will when I return home.

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

Re: Windows 11 - Compiling toolchain (5.3 and 6)

[Chris Johns]

On 13/10/2023 1:21 am, Sebastian Huber wrote:
> some of our customers use WSL2 with Ubuntu, they reported no issues with the 
> RSB
> build of RTEMS 6.

I think something in recent Linux versions is causing problems with RTEMS 5.

> If you want to build mingw tools, then I would build them on Linux with a 
> mingw
> cross compiler.

If you do this make sure you collect and handle the DLLs referenced in the
build. Not doing this can leave you with some hidden surprises. The Linux distro
packages and the Windows native DLL may not align.

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

Re: rsb gdb build on aarch64 (OS-X M2)

[Chris Johns]

On 28/9/2023 6:28 am, Heinz Junkes wrote:
> It was a mess with homebrew and python versions on my system.
> Rsb works well ;-)

Thanks for following this up and good to know. Have you managed to use the gdb
executable? A user has reported on discord the ARM gdb crashing however I do not
see that happening with my build.

I build on my M2 using a python.org install, a virtual environment and X code. I
welcome users using homebrew or macports but I cannot directly support the
efforts because of the amount of work to that would be more than I can handle.

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

Re: Networking examples

[Chris Johns]

On 18/8/2023 12:54 am, Gedare Bloom wrote:
> I don't think that "--with-rtems" is a valid command line option to
> use. I guess RSB should be a little more noisy about unknown command
> line options.

The --with-* and --without-* options align to the autoconf type options where
users can override some defaults. The reason the RSB cannot say anything is it
does not know what is needed or used.

The --with-*/--without-* options define a specific type of macro the config
scripts can use to key specific functionality around. The RSB python code which
handles the command line and reports any errors does not know all the config
logic paths in advance so it cannot say if a value is needed or right. This is
also the reason a generic approach is being used rather than being able to
specify specific options for specific purposes.

Resolving the issue might be possible with a lot of work and it would require a
number of changes in a few places based around some form of a config definition
of the with and without options.

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

Re: Path issue Filesystem mounted with NFS(v4?)

[Chris Johns]

On 13/7/2023 10:29 pm, Heinz Junkes wrote:
> I see exact the same behavior as in the ticket 4273.
> Thanks for looking into….

This has been fixed.

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

Re: RTEMS 5.3 libbsd, networking issue for 100mbps link (1Gbps is fine)

[Chris Johns]

On 18/7/2023 8:21 pm, Karol Gliwa wrote:
> Hi Guys,
> 
>  
> 
> I have following problem with networking on Zynq running RTEMS 5.3 + libbsd +
> BSP zynq_zedboard of according version.
> 
> I had to patch the libbsd to support some network PHY for the boards I use.
> 
>  
> 
> Whenever I connect the device to 1Gbit interface, and the link is negotiated 
> to
> 1Gbit everything seems working just fine. I can PING the board and 
> successfully
> connect to TCP/IP socket (custom test echo server basing on the examples int 
> the
> rtems-libbsd repository + sockets).
> 
>  
> 
> When I connect the board to 100Mbit interface (another usb dongle) it seems to
> establish the link fine, but I cannot ping the board nor connect to the 
> socket.
> I replicated this behavior with at least three different 1Gbit interfaces 
> (works
> each time) and two 100Mbit dongles (not working). I confirmed that behavior
> using PYNQ Z1 board and also with our other custom device.
> 
>  
> 
> Additionally, I had an opportunity to test our custom board with another 
> 'hello
> world' echo server that came from my colleges that use Xilin'x Vitis + LwIP
> (bare metal application) and that one has been working in every link speed
> configuration.
> 
>  
> 
> It seems to me that the problem my reside in the RTEMS software part or 
> drivers
> (or my compilation or configuration) and not in the HW since I could confirm
> it's working with LwIP for all configs... Unfortunately, I have little
> experience with networking in general and was not able to solve that issue on 
> my
> own.
> 
>  
> 
> I attach the RTEMS shell output of `ifconfig -a` executed on PYNQ Z1 when
> connected to 1Gbit eth device (PING working):
> 
>  
> 
> '''
> 
> SHLL [/] # ifconfig  cgem0 192.168.10.207 netmask 255.255.255.0
> 
> SHLL [/] # ifconfig -a   
> 
> cgem0: flags=8843 metric 0 mtu 1500
> 
>     options=80008
> 
>     ether 0e:b0:ba:5e:ba:11
> 
>     inet6 fe80::cb0:baff:fe5e:ba11%cgem0 prefixlen 64 scopeid 0x1
> 
>     inet 192.168.10.207 netmask 0xff00 broadcast 192.168.10.255
> 
>     nd6 options=21
> 
>     media: Ethernet autoselect (1000baseT )
> 
>     status: active
> 
> lo0: flags=8049 metric 0 mtu 16384
> 
>     options=680003
> 
>     inet 127.0.0.1 netmask 0xff00
> 
>     inet6 ::1 prefixlen 128
> 
>     inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
> 
>     nd6 options=21
> 
>     groups: lo
> 
> '''
> 
>  
> 
>  
> 
> Then hot switch to 100Mbit usb eth card (PING not working):
> 
> '''
> 
> SHLL [/] # info: cgem0: link state changed to DOWN
> 
> cgem0: cgem_mediachange: could not set ref clk0 to 2500.
> 
> info: cgem0: link state changed to UP
> 
> SHLL [/] # ifconfig  cgem0 172.19.1.207 netmask 255.255.255.0 
> 
> SHLL [/] # ifconfig -a 
> 
> cgem0: flags=8843 metric 0 mtu 1500
> 
>     options=80008
> 
>     ether 0e:b0:ba:5e:ba:11
> 
>     inet6 fe80::cb0:baff:fe5e:ba11%cgem0 prefixlen 64 scopeid 0x1
> 
>     inet 172.19.1.207 netmask 0xff00 broadcast 172.19.1.255
> 
>     nd6 options=21
> 
>     media: Ethernet autoselect (100baseTX )
> 
>     status: active
> 
> lo0: flags=8049 metric 0 mtu 16384
> 
>     options=680003
> 
>     inet 127.0.0.1 netmask 0xff00
> 
>     inet6 ::1 prefixlen 128
> 
>     inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
> 
>     nd6 options=21
> 
>     groups: lo
> 
> '''
> 
>  
> 
>  
> 
>  
> 
> Do You have any idea of what may be causing the issue here? Thanks for all 
> help
> in advance.

Are the clocks to the PHY being correctly set and the driver knows the 
frequency.

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

Re: HEADS UP: git repo WRONG push landed.

[Chris Johns]

Amar as edited the repo. You can read his post here ..

https://lists.rtems.org/pipermail/devel/2023-July/075819.html

Chris

On 19/7/2023 12:13 am, Brett Sterling wrote:
> The easiest way to do this is to revert and push.  'unpushing' is not
> recommended :-)
> 
> Brett
> 
> *From:* users  on behalf of Karel Gardas
> 
> *Sent:* Tuesday, July 18, 2023 7:58 AM
> *To:* users@rtems.org 
> *Subject:* HEADS UP: git repo WRONG push landed.
>  
> [You don't often get email from karel.gar...@centrum.cz. Learn why this is
> important at https://aka.ms/LearnAboutSenderIdentification
>  ]
> 
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you recognize the sender and know the content
> is safe.
> 
> 
>    Dear RTEMS users,
> 
> if you are using RTEMS git repo, please do not pull now. Wrong patches
> landed in the main RTEMS git.rtems.org and they needs to be removed.
> 
> Thanks for your patience!
> Karel
> 
> 
>  Forwarded Message 
> Subject: HEADS UP: git repo WRONG push landed.
> Date: Tue, 18 Jul 2023 15:40:11 +0200
> From: Karel Gardas 
> To: rtems-de...@rtems.org 
> 
> 
>    Folks,
> 
> I've completely screwed up and pushed wrong repository to the git.rtems.org.
> 
> I don't know how that happen as this should land on github.com...
> 
> So please do not commit anything for now, I'll try to lookup help on
> discord.com and see what can be done to unpush...
> 
> Thanks and really sorry for this mess...
> 
> Karel
> ___
> devel mailing list
> de...@rtems.org
> https://usg02.safelinks.protection.office365.us/?url=http%3A%2F%2Flists.rtems.org%2Fmailman%2Flistinfo%2Fdevel=05%7C01%7C%7Cdf082186a2e94e7469a508db87972228%7Cd761ffacf6be45b88f6f288a59577095%7C0%7C0%7C638252855427392820%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=KaysoMVjUZ3z52kLfaNS1xmwbdN5Y3YmOQLPiYCUHlI%3D=0
>  
> 
> ___
> users mailing list
> users@rtems.org
> https://usg02.safelinks.protection.office365.us/?url=http%3A%2F%2Flists.rtems.org%2Fmailman%2Flistinfo%2Fusers=05%7C01%7C%7Cdf082186a2e94e7469a508db87972228%7Cd761ffacf6be45b88f6f288a59577095%7C0%7C0%7C638252855427392820%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=hcdP78m3VZM%2BhIPEluZSxF45bbuMfkuWqBGByQxtMSs%3D=0
>  
> 
> 
> ___
> users mailing list
> users@rtems.org
> http://lists.rtems.org/mailman/listinfo/users
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Path issue Filesystem mounted with NFS(v4?)

[Chris Johns]

On 11/7/2023 7:32 pm, Heinz Junkes wrote:
> Hallo,
> 
> I am observing a strange problem with an NFS(v4) mounted filesystem and path 
> usage.
> 
> I have mounted a filesystem via NFSv4 (/Volumes):
> 
> loc = 0x00820a20
> node_access = 0x007c2378, node_access_2 = 0x, handler = 0x005c3474
> type = nfs, mounted, read-write, target = /Volumes, dev = 141.14.131.192, 
> root loc = 0x00913468
> 
> In the shell I can change there into a directory:
> 
> SHLL [/] # cd /Volumes/Epics/LogDir/Database
> SHLL [/Volumes/Epics/LogDir/Database] # pwd
> /Volumes/Epics/LogDir/Database
> 
> SHLL [/Volumes/Epics/LogDir/Database] # ls -l
> total 20
> -rw-r--r--  1 1001  1001  10694 Mar 23  2021 iocvmeIOC3.dbhcr
> -rw-r--r--  1 1001  1001  0 Mar 23  2021 iocvmeIOC3.dbior
> -rw-r--r--  1 1001  1001   5451 Mar 23  2021 iocvmeIOC3.dbl
> 
> I can now copy a file to here:
> 
> SHLL [/Volumes/Epics/LogDir/Database] # cp /etc/passwd .
> SHLL [/Volumes/Epics/LogDir/Database] # ls -l
> total 24
> -rw-r--r--  1 1001   1001   10694 Mar 23  2021 iocvmeIOC3.dbhcr
> -rw-r--r--  1 1001   1001   0 Mar 23  2021 iocvmeIOC3.dbior
> -rw-r--r--  1 1001   10015451 Mar 23  2021 iocvmeIOC3.dbl
> -rwxrwxrwt  1 65534  65534 14 Jul 11 11:28 passwd
> SHLL [/Volumes/Epics/LogDir/Database] # cat passwd
> root::0:0
> SHLL [/Volumes/Epics/LogDir/Database] # rm passwd
> SHLL [/Volumes/Epics/LogDir/Database] # ls -l
> total 20
> -rw-r--r--  1 1001  1001  10694 Mar 23  2021 iocvmeIOC3.dbhcr
> -rw-r--r--  1 1001  1001  0 Mar 23  2021 iocvmeIOC3.dbior
> -rw-r--r--  1 1001  1001   5451 Mar 23  2021 iocvmeIOC3.dbl
> 
> If I now specify the path instead of “.”, the file appears one dir up 
> 
> SHLL [/Volumes/Epics/LogDir/Database] # cp /etc/passwd 
> /Volumes/Epics/LogDir/Database/passwd
> SHLL [/Volumes/Epics/LogDir/Database] # ls -l
> total 20
> -rw-r--r--  1 1001  1001  10694 Mar 23  2021 iocvmeIOC3.dbhcr
> -rw-r--r--  1 1001  1001  0 Mar 23  2021 iocvmeIOC3.dbior
> -rw-r--r--  1 1001  1001   5451 Mar 23  2021 iocvmeIOC3.dbl
> SHLL [/Volumes/Epics/LogDir/Database] # ls -l ..
> total 40
> drwxrwxrwx  2 65534  65534  4096 Jul 11 11:29 Database
> -rwxrwxrwt  1 65534  65534  9980 Jul 10 11:52 iocvmeIOC1.dbhcr
> -rwsrwsrwt  1 65534  65534 0 Jul 10 11:52 iocvmeIOC1.dbior
> -rwxrwxrwt  1 65534  65534  4713 Jul 10 11:59 iocvmeIOC1.dbl
> drwxrwxrwx  3 65534  65534  4096 Mar 23  2021 log
> -rwxrwxrwt  1 65534  6553414 Jul 11 11:30 passwd
> SHLL [/Volumes/Epics/LogDir/Database] # cat ../passwd
> root::0:0
> 
> 
> Any Idea what might go wrong? Any fix?

Is it related to https://devel.rtems.org/ticket/4723?

I was planning to look into this in the next couple of weeks.

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

Re: Initializing I2C on the RTEMS6 MVME3100 BSP

[Chris Johns]

On 28/6/2023 6:48 am, Zainab Olalekan wrote:
> I am encountering difficulties with initializing I2C on the RTEMS6 MVME3100 
> BSP,
> required to run EPICS test. I have made adaptations based on Heinz's patch for
> RTEMS5, but I am experiencing an error. Here is the specific error message
> alongside an attached file showing the modifications made.

The trace shows the code is crashing somewhere.

Has Heinz run I2C on the MVME3100?

We now have an #epics channel on our discord server
(https://devel.rtems.org/wiki/Developer/discord) which can be more interactive
depending on timezones.

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

Re: Problem using sphinx to build documentation

[Chris Johns]

On 7/6/2023 10:09 pm, andrew.butterfi...@scss.tcd.ie wrote:
> Done - it's #4915

This is now fixed.

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

Re: Problem using sphinx to build documentation

[Chris Johns]

On 6/6/2023 7:11 pm, andrew.butterfi...@scss.tcd.ie wrote:
> I am trying to install sphinx on an Apple Silicon OSX machine.
> I've already done this successfully on a similar machine.
> 
> This time, after  following steps in   the rtems-docs README.txt,
> I do ./waf , it does some stuff and then:
> 
> [ 7/10] Compiling common/_static/favicon.ico
> [ 8/10] Compiling common/_static/my-styles.css
> [ 9/10] Compiling common/_static/logo.png
> [10/10] Compiling common/_static/style.css
> 
> Theme error:
> An error happened in rendering the page bld/index.
> Reason: UndefinedError("'style' is undefined")
> 
> I have not seen this error before - any thoughts?
> 
> I'm using pip 22.2.1 and Python 3.10.6

Could you please raise a ticket?

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

Re: arm bsps: changing the float-abi to softfp

[Chris Johns]

On 5/4/2023 4:11 am, Sebastian Huber wrote:
> If you really need such a multilib, then you can patch 
> gcc/config/arm/t-rtems. I
> don't know if you can add custom patches to the RTEMS Source Builder.

There is a means if someone wants to update gcc-common-1.cfg to allow user macro
maps.

1. User patch or source macro map

Create a user macro map. Examples can be found here:

https://git.rtems.org/rtems-source-builder/tree/rtems/config/snapshots

2. Update gcc-common-1.cfg to select user macro maps

Update:

 
https://git.rtems.org/rtems-source-builder/tree/source-builder/config/gcc-common-1.cfg

with suitable selects. For example:

https://git.rtems.org/rtems-source-builder/tree/source-builder/config/gcc-4.7-1.cfg

I suggest:

 %select gcc-user
 %select newlib-user
  ...

3. Provide your macros to the set builder command using --macros.

You can also set the environment variable `RSB_MACROS` or create a file called
$HOME/.rsb_macros.

It has been many years since I have used and tested this.

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

Re: OS X Build Problems tag 5.2 ->Invalid configuration `arm64-apple-darwin22.3.0': machine `arm64-apple' not recognized

[Chris Johns]

On 30/3/2023 3:06 am, Heinz Junkes wrote:
> Hi,
> 
> I have, once again, a problem with building RTEMS on OS X.
> 
> It works fine with rtems6/master 
> 
> with clang 10.0.0 , python 3.8.5 on 
> Darwin Judiciary-Pag.fritz.box 22.2.0 Darwin Kernel Version 22.2.0: Fri Nov 
> 11 02:04:44 PST 2022; root:xnu-8792.61.2~4/RELEASE_ARM64_T8103 arm64
> python shows:
> (base) Judiciary-Pag:rtems-libbsd heinz$ python
> Python 3.8.5 (default, Sep  4 2020, 02:22:02)
> [Clang 10.0.0 ] :: Anaconda, Inc. on darwin
> Type "help", "copyright", "credits" or "license" for more information.
 import sysconfig
 sysconfig.get_config_vars()['HOST_GNU_TYPE']
> 'x86_64-apple-darwin13.4.0'

OK

> and clang 14.0.0 with python 3.11.2 on
> mac07:VE_RTEMS_INST hjunkes$ uname -a
> Darwin mac07.pse.bht-berlin.de 22.3.0 Darwin Kernel Version 22.3.0: Mon Jan 
> 30 20:39:35 PST 2023; root:xnu-8792.81.3~2/RELEASE_ARM64_T8103 arm64

My machine shows:

% uname -a
Darwin weka.contemporary.net.au 22.3.0 Darwin Kernel Version 22.3.0: Mon Jan 30
20:39:46 PST 2023; root:xnu-8792.81.3~2/RELEASE_ARM64_T6020 arm64

I have a M2 Pro processor so I wonder if that explains the T6020 vs T8103? The
work I am doing can be tracked here https://devel.rtems.org/ticket/4892

> python shows:
> mac07:VE_RTEMS_INST hjunkes$ python
> Python 3.11.2 (main, Feb 16 2023, 02:55:59) [Clang 14.0.0 
> (clang-1400.0.29.202)] on darwin

Where is this python from?

> Type "help", "copyright", "credits" or "license" for more information.
 import sysconfig
 sysconfig.get_config_vars()['HOST_GNU_TYPE']
> 'aarch64-apple-darwin22.3.0'
> 
> 
> on CLANG 14.0.0 and python 3.11.2
> 
> OK with rtems 6 / master 
> 
>   git clone https://github.com/RTEMS/rtems-source-builder.git rsb
> …
> 
> RTEMS Source Builder - Set Builder, 6 (f0e34eab8bf3 modified)
>  Command Line: ../source-builder/sb-set-builder --jobs=2 
> --prefix=/Users/hjunkes/RTEMS_RASPI_RUN/rtems/6 6/rtems-arm
>  Python: 3.11.2 (main, Feb 16 2023, 02:55:59) [Clang 14.0.0 
> (clang-1400.0.29.202)]
> warning: exe: absolute exe found in path: (__install_info) 
> /usr/bin/install-info
> warning: exe: absolute exe found in path: (__makeinfo) /usr/bin/makeinfo
> Build Set: 6/rtems-arm
> Build Set: tools/rtems-default-tools.bset
> Build Set: textproc/gsed-internal.bset
> config: textproc/gsed.cfg
> package: gsed-4.8-arm64-apple-darwin22.3.0-1
> script:  1: #!/bin/sh
> 
> Failed with rtems 5.2
> 
> git clone https://github.com/RTEMS/rtems-source-builder.git rsb
> cd rsb
> git checkout tags/5.2
> 
> ...
> RTEMS Tools Project - Source Builder Error Report
>  Build: error: building autoconf-2.69-arm64-apple-darwin22.3.0-1
>  Command Line: ../source-builder/sb-set-builder --jobs=2 
> --prefix=/Users/hjunkes/VE_RTEMS_RUN/rtems/5 5/rtems-arm
>  Python: 3.11.2 (main, Feb 16 2023, 02:55:59) [Clang 14.0.0 
> (clang-1400.0.29.202)]
>  
> https://github.com/RTEMS/rtems-source-builder.git/origin/1116c5f85fb5dceca4a57c1b69195b6e9215b084-modified
>  Darwin mac07.pse.bht-berlin.de 22.3.0 Darwin Kernel Version 22.3.0: Mon Jan 
> 30 20:39:35 PST 2023; root:xnu-8792.81.3~2/RELEASE_ARM64_T8103 arm64
> Tail of the build log:
> ...
> + 
> ac_prefix=/Users/hjunkes/VE_RTEMS_INST/rsb/rtems/build/tmp/sb-659039/Users/hjunkes/VE_RTEMS_RUN/rtems/5
> + test arm64-apple-darwin22.3.0 '!=' arm64-apple-darwin22.3.0
> + export CFLAGS CFLAGS_FOR_BUILD CC
> + CFLAGS='-O2 -pipe -fbracket-depth=1024 
> -I/Users/hjunkes/VE_RTEMS_INST/rsb/rtems/build/tmp/sb-659039/5/rtems-autotools-internal/Users/hjunkes/VE_RTEMS_RUN/rtems/5/include
>  '
> + ./configure --build=arm64-apple-darwin22.3.0 
> --host=arm64-apple-darwin22.3.0 --verbose --disable-nls 
> --without-included-gettext 
> --prefix=/Users/hjunkes/VE_RTEMS_INST/rsb/rtems/build/tmp/sb-659039/Users/hjunkes/VE_RTEMS_RUN/rtems/5
> configure: WARNING: unrecognized options: --disable-nls, 
> --without-included-gettext
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for a thread-safe mkdir -p... build-aux/install-sh -c -d
> checking for gawk... no
> checking for mawk... no
> checking for nawk... no
> checking for awk... awk
> checking whether make sets $(MAKE)... yes
> Invalid configuration `arm64-apple-darwin22.3.0': machine `arm64-apple' not 
> recognized

There have been a number of fixes on RTEMS 6 to work the latest aarch64 MacOS
releases from Karel Gardas. Maybe they need to be back ported to 5?

> configure: error: /bin/sh build-aux/config.sub arm64-apple-darwin22.3.0 failed
> checking build system type...
> checking build system type...
> shell cmd failed: /bin/sh -ex  
> /Users/hjunkes/VE_RTEMS_INST/rsb/rtems/build/autoconf-2.69-arm64-apple-darwin22.3.0-1/do-build
> error: building autoconf-2.69-arm64-apple-darwin22.3.0-1
> 
> 
> on CLANG 10.0.0 and python 3.8.5
> 
> Ok with RTEMS 5.2 (and rtems6)

On which MacOS?

Chris

> 
> RTEMS Source Builder - Set Builder, 5 (1116c5f85fb5 modified)
>  Command Line: 

Re: Error in building rtems 5.3 tools via mingw

[Chris Johns]

On 29/3/2023 9:11 pm, Giovanni Righi wrote:
> Ok, also I forgot to say in the previous email that I'm using windows 11. 

Ah thanks. I have access to a Windows 11 machine.

Chris

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

Re: Error in building rtems 5.3 tools via mingw

[Chris Johns]

 File
> "C:/opt/rtems/rtems-source-builder-5.3/rtems/build/rt51/rtems-tools-5.3/waf3-2.0.19-1f3c580272b15a03d2566843c5fe872a/waflib/Task.py",
>  line 180, in process
>     ret=self.run()
>   File "", line 14, in f
>   File
> "C:/opt/rtems/rtems-source-builder-5.3/rtems/build/rt51/rtems-tools-5.3/waf3-2.0.19-1f3c580272b15a03d2566843c5fe872a/waflib/Task.py",
>  line 173, in exec_command
>     return self.generator.bld.exec_command(cmd,**kw)
>   File
> "C:/opt/rtems/rtems-source-builder-5.3/rtems/build/rt51/rtems-tools-5.3/waf3-2.0.19-1f3c580272b15a03d2566843c5fe872a/waflib/Context.py",
>  line 183, in exec_command
>     raise Errors.WafError('Execution failure: %s'%str(e),ex=e)
> waflib.Errors.WafError: Execution failure: [Errno 32] Broken pipe
> 
> shell cmd failed: sh -ex
>  /c/opt/rtems/rtems-source-builder-5.3/rtems/build/rt51/do-build
> error: building rt51
> 
> Il giorno sab 25 mar 2023 alle ore 00:06 Chris Johns  <mailto:chr...@rtems.org>> ha scritto:
> 
> On 23/3/2023 10:48 pm, Giovanni Righi wrote:
> > Ok so I tried what you suggested, I downloaded the rtems-tools-5.3 tar
> form the
> > server and I launched directly the waf script.
> > I got the same error, then I tried again and again I got the same error
> but on a
> > file following the one that caused the first error. So I launched the 
> waf
> again
> > and it managed to compile all the files.
> > After this I did a waf clean and tried again and I got the same results,
> error -
> > error - compilation complete.
> > Note the two errors happened in the same files as the first "run".
> > So now I have the tools compiled but I don't know how to finish the 
> build
> of the
> > toolchain, because if I launch the sb-set-builder again it cleans
> everything and
> > starts again so when it reaches the tools part it crashes again because 
> of the
> > waf error.
> > I hope the explanation is clear and there is a solution for this 
> problem. 
> > I attach a file with parts of the three runs so you can see what's 
> going on.
> 
> Thanks. I wonder if the scripting used to handle the `.m4` files is 
> broken on
> mingw? What happens if you add --jobs=1 to a clean build?
> 
> What version of Windows?
> 
> Chris
> 
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Error in building rtems 5.3 tools via mingw

[Chris Johns]

On 23/3/2023 10:48 pm, Giovanni Righi wrote:
> Ok so I tried what you suggested, I downloaded the rtems-tools-5.3 tar form 
> the
> server and I launched directly the waf script.
> I got the same error, then I tried again and again I got the same error but 
> on a
> file following the one that caused the first error. So I launched the waf 
> again
> and it managed to compile all the files.
> After this I did a waf clean and tried again and I got the same results, 
> error -
> error - compilation complete.
> Note the two errors happened in the same files as the first "run".
> So now I have the tools compiled but I don't know how to finish the build of 
> the
> toolchain, because if I launch the sb-set-builder again it cleans everything 
> and
> starts again so when it reaches the tools part it crashes again because of the
> waf error.
> I hope the explanation is clear and there is a solution for this problem. 
> I attach a file with parts of the three runs so you can see what's going on.

Thanks. I wonder if the scripting used to handle the `.m4` files is broken on
mingw? What happens if you add --jobs=1 to a clean build?

What version of Windows?

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

Re: Error in building rtems 5.3 tools via mingw

[Chris Johns]

On 23/3/2023 1:16 am, Giovanni Righi wrote:
> I opened the ticket as requested.
> Now I'm having another issue, I re-runned the source-builder but now it stop
> with the following error:
> + ./waf
> Waf: Entering directory
> `C:/opt/rtems/rtems-source-builder-5.3/rtems/build/rt51/rtems-tools-5.3/build'
> [  1/258] Compiling rtemstoolkit/elftoolchain/libelf/libelf_convert.m4
> Traceback (most recent call last):
>   File "", line 55, in 
>   File "", line 20, in run
> OSError: [Errno 22] Invalid argument

That looks like waf in rtems-tools had an issue. It may need to be updated.

Are you able to download the rtems-tools tar file from our servers and manually
build that package?

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

Re: Error in building rtems 5.3 tools via mingw

[Chris Johns]

On 22/3/2023 3:19 am, Giovanni Righi wrote:
> Ok I managed to resolve the problem by updating the gdb to gdb-12 as you 
> suggested.
> Just for information if someone will have the same problem, I got the 
> gdb-12.cfg
> from the master and copied it inside the 
> rtems-source-builder/rtems/config/tools
> directory. then I had to modify the rtems-default.bset file
> inside rtems-source-builder/rtems/config/5 by changing the gdb version to 12.1
> otherwise the builder will still use the 9.1 version.
> Thank you once again for your help.

Could you please raise a ticket for this and assign it to me?

The table at the top of this page https://devel.rtems.org/ has a link to help
create a but report for 5.4.

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

Announce: RTEMS 5.3 Release

[Chris Johns]

RTEMS 5.3 Release is available.

 https://ftp.rtems.org/pub/rtems/releases/5/5.3

Please follow the release instructions provided by the link.

We love to hear about your projects and what you use RTEMS on so please let us
know. You can drop by on Discord, post on u...@rtems.org or you can send Joel or
me a private email.

If you find a problem please raise a ticket and select the 5.4 milestone. The
simplest way to create a ticket is to head to the developer Wiki at:

 https://devel.rtems.org/

Then click on the "Next (milestone)" link for the RTEMS 5 Release. You will need
an account.

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

Re: Current python with RTEMS efforts

[Chris Johns]

On 9/2/2023 6:26 am, Scobie, Rory Hewitt wrote:
> 
> I was wondering if anyone knows of active efforts to build python and run it
> under RTEMS?

I do not know of any active efforts.

> Web searches found ESA’s efforts with micropython and some old instructions 
> from
> the python 2.4 / RTEMS 4.6 timeframe, however I didn’t find anything more
> recent.  Are there any current efforts or information about building and 
> running
> python under RTEMS?

I have built and used cpython on RTEMS successfully. It is old and you can find
the efforts archived here:

https://ftp.rtems.org/pub/rtems/archive/current_contrib/python/

I have no idea how much value this is with a current python version. Python
worked really well and the product that used it could read POP and IMAP 
mailboxes.

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

Re: Dynamic loader usage in RTEMS 5.1

[Chris Johns]

On 14/1/2023 7:58 am, John Clemens wrote:
> I'm trying to understand how to build/link code to use the dynamic loader in
> RTEMS v5.1. I'm using
> https://docs.rtems.org/releases/rtems-5.1/user/exe/loader.html as a reference.
> 
> My codebase has a core object and several components that will be loaded at 
> boot
> time.  I do the 2-pass linking step with the embedded global symbol table on 
> my
> core object, and then run rtems-syms to generate "*-sym.o" objects for my
> runtime files (but do -not- send them through a second linking pass).
> 
> Now I have a core object and several "fooX.o" and "fooX-sym.o" files.. what 
> do I
> do from here?  Are the fooX-sym.o files supposed to be linked into the core
> object somehow?
> 
> I'm sure I'm missing an obvious step.  Any pointers?

Have you read the documentation in the User Manual:

https://docs.rtems.org/branches/master/user/exe/loader.html

If you still have some questions, please ask.

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

Announce: RTEMS 5.2 Release

[Chris Johns]

RTEMS 5.2 Release is available.

 https://ftp.rtems.org/pub/rtems/releases/5/5.2

Please follow the release instructions provided by the link.

We love to hear about your projects and what you use RTEMS on so please let us
know. You can drop by on Discord, post on u...@rtems.org or you can send Joel or
me a private email.

If you find a problem please raise a ticket and select the 5.3 milestone. The
simplest way to create a ticket is to head to the developer Wiki at:

 https://devel.rtems.org/

Then click on the "Next (milestone)" link for the RTEMS 5 Release. You will need
an account.

Thanks to everyone who has contributed to the release over the past few years.
This is a community project and without the support of the community we would
not be able to make these quality releases.

Thanks
Chris

ps: Happy birthday Dad!
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Announce: RTEMS 5.2-rc1 Release Candidate

[Chris Johns]

The RTEMS 5.2-rc1 Release Candidate is available. The release can be found at:

 https://ftp.rtems.org/pub/rtems/releases/5/rc/5.2-rc1/

Please follow the release instructions provided by the link. The release notes
can be found here:

 
https://ftp.rtems.org/pub/rtems/releases/5/rc/5.2-rc1/rtems-5.2-rc1-release-notes.html

They detail the change that have been made on the 5 branch.

If you find a problem please raise a ticket and select the 5.2 milestone. The
simplest way to create a ticket is to head to the developer Wiki at:

 https://devel.rtems.org/

Then click on the "Next (milestone)" link for the RTEMS 5 Release. You will need
an account.

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

Re: RTEMS5 and file descriptors

[Chris Johns]

On 20/10/2022 4:03 am, Michael Davidsaver wrote:
> On 10/17/22 22:50, Chris Johns wrote:
>> On 18/10/2022 4:42 pm, Sebastian Huber wrote:
>>> On 18/10/2022 06:15, Chris Johns wrote:
>>>> On 18/10/2022 2:22 pm, Michael Davidsaver wrote:
>>>>> On 10/17/22 16:20, Chris Johns wrote:
>>>>>> 2. Look at kqueue, it is a better interface for this type of blocking
>>>>> Maybe not relevant in Miroslaw's application, but I've found
>>>>> that the RTEMS kqueue implementation doesn't notify when a
>>>>> TCP connection is closed by reset.  I think this is a lack
>>>>> of NOTE_EOF *.
>>>> Thanks. I cannot find a ticket for this? Do you know if one has been 
>>>> created?
> 
> Not by me.  I ran into this incidentally while testing some
> new networking code using libevent, which helped me towards
> finding:
> 
> https://www.mail-archive.com/freebsd-hackers@freebsd.org/msg43808.html
> 
> Which leads with a reasonably clear statement that kqueue
> is/was not 100% functionally equivalent to select()/poll().
> At that point I configured libevent to use poll() and
> continued with my own troubleshooting.  Then unfortunately,
> I forgot about it until I read this thread.
> 
> https://github.com/mdavidsaver/pvxs/blob/6ee82fac6533d6551b18aa489cb263adc1333018/src/evhelper.cpp#L171-L178
> 
> That freebsd thread is 19 years old, and I haven't spent the
> time to investigate what happened since then.
> 
> libevent has:
> 
>> #ifdef NOTE_EOF
>>     /* Make it behave like select() and poll() */
>>     if (filter == EVFILT_READ)
>>     out->fflags = NOTE_EOF;
>> #endif
> https://github.com/libevent/libevent/blob/8f47d8de281b877450474734594fdc0a60ee35d1/kqueue.c#L193-L197
> 
> 
>>> This looks like a general FreeBSD limitation.
> 
> This was my general assessment at the time.
> 
>  
>> Is NOTE_EOF the same as EV_EOF? I noticed EV_EOF in the FreeBSD man page for
>> kqueue.
> 
> I'm no expert on the kqueue mechanism, but I think not.
> 
> https://man.openbsd.org/kqueue.2
> 
> This openbsd manpage mentions both, although 'NOTE_EOF' is
> only mentioned in passing, with no definition given.
> 
> Some searching leads me to think that EV_EOF is a "flag"
> while NOTE_EOF is an "fflag" (filter flag).  I have not
> investigated the precise distinction between the two.

Thanks for the response. It is unusual compatibility between implementations of
kqueue is not a major concern.

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

Re: RTEMS5 and file descriptors

[Chris Johns]

On 18/10/2022 4:42 pm, Sebastian Huber wrote:
> On 18/10/2022 06:15, Chris Johns wrote:
>> On 18/10/2022 2:22 pm, Michael Davidsaver wrote:
>>> On 10/17/22 16:20, Chris Johns wrote:
>>>> 2. Look at kqueue, it is a better interface for this type of blocking
>>> Maybe not relevant in Miroslaw's application, but I've found
>>> that the RTEMS kqueue implementation doesn't notify when a
>>> TCP connection is closed by reset.  I think this is a lack
>>> of NOTE_EOF *.
>> Thanks. I cannot find a ticket for this? Do you know if one has been created?
> 
> This looks like a general FreeBSD limitation.
> 

Is NOTE_EOF the same as EV_EOF? I noticed EV_EOF in the FreeBSD man page for 
kqueue.

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

Re: RTEMS5 and file descriptors

[Chris Johns]

On 18/10/2022 2:22 pm, Michael Davidsaver wrote:
> On 10/17/22 16:20, Chris Johns wrote:
>> 2. Look at kqueue, it is a better interface for this type of blocking
> 
> Maybe not relevant in Miroslaw's application, but I've found
> that the RTEMS kqueue implementation doesn't notify when a
> TCP connection is closed by reset.  I think this is a lack
> of NOTE_EOF *.

Thanks. I cannot find a ticket for this? Do you know if one has been created?

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

Re: RTEMS5 and file descriptors

[Chris Johns]

On 18/10/2022 9:19 am, Miroslaw Dach wrote:
>>AFAIK you'd have to patch the header in the C Library when building the tools
> using the RSB to have a possible clean solution. Editing the installed header
> would be uncool.
> I see , I thought that it is somehow simpler thing.
>>How many descriptors do you need? And will you be using select()?
> I need maximum 128 file descriptors to be used.

The issue is a little more complicated because of the way the fd number are
allocated. RTEMS implements not reusing fd number once free (closed) preferring
to move to an unused fd number until all numbers have been used. The idea is to
try and catch the accidental continued use of an fd after close when an open
follows.

If you allocate 200 descriptors the following select code will work:

/* RTEMS entry point */
void Init(void) {
  /* start networking */
  int fd = socket(...);
  FD_ZERO();
  FD_SET(fd, );
  nfds = sd + 1;
  r = select(nfds, , NULL, NULL, NULL);
  /* blah blah */
}

while this will not:

/* RTEMS entry point */
void Init(void) {
  /* use up all the fd spots select has by default */
  for (i = 0; i < 65; i++) {
fd = open("afile", ...);
close(fd);
  }
  /* start networking */
  fd = socket(...);
  FD_ZERO();
  /* out of range access */
  FD_SET(fd, );
  nfds = sd + 1;
  rv = select(nfds, , NULL, NULL, NULL);
  /* blah blah */
}

If you control the code in quesiton and can make changes the following are some
suggestions:

1. Consider a thread per descriptor. Select is slow

2. Look at kqueue, it is a better interface for this type of blocking

3. Look at the following select work around ..
https://git.rtems.org/rtems/tree/cpukit/mghttpd/mongoose.c#n1522

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

Re: [EX]Re: xilinx_zynqmp_ilp32_zu3eg namespace issue (cmath round not in std)

[Chris Johns]

On 6/10/2022 5:54 am, Trip Richert wrote:
> I've been using primarily :
> 
> aarch64-rtems6-gcc (GCC) 10.3.1 20210409 (RTEMS 6, RSB no-repo, Newlib 
> 0c0f3df)
> aarch64-rtems6-g++ (GCC) 10.3.1 20210409 (RTEMS 6, RSB no-repo, Newlib 
> 0c0f3df)
> 
> but also tested it with 
> 
> aarch64-rtems6-gcc (GCC) 12.2.1 20220924 (RTEMS 6, RSB
> cfed1659a297cb0f95a03e053345962097aa02bf, Newlib 01f6251c0)
> aarch64-rtems6-g++ (GCC) 12.2.1 20220924 (RTEMS 6, RSB
> cfed1659a297cb0f95a03e053345962097aa02bf, Newlib 01f6251c0)
> 

I can confirm the example code in
https://en.cppreference.com/w/cpp/numeric/math/round fails to build with
aarch64-rtems6-gcc and it does builds with arm-rtems6-gcc.

Something is broken. Joel?

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

Re: Student difficulty joining items users list.

[Chris Johns]

On 19/9/2022 9:29 pm, andrew.butterfi...@scss.tcd.ie wrote:
> Hi all,
> 
> A student of mine is trying to subscribe to this mailing list at
> https://lists.rtems.org/mailman/listinfo/users
> 
> 
> He adds in his email address, hits “Subscribe” and gets back a pop-up saying :
> 
> “Forbidden, you don't have permission to access this resource”
> 
> Any ideas what the problem might be?
> 

The web interface is currently disabled but you can subscribe using email.

Send an email to '-j...@rtems.org' where '' is the name and it does
not matter what the subject or body is. So to join the user list send to
'users-j...@rtems.org'.

I know this is old school but I hope it helps.

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

Re: RSB build fails on M1 Macbook Pro

[Chris Johns]

On 21/9/2022 1:35 am, Karel Gardas wrote:
> 
> Well, obviously, I would fix that by installing the library. But anyway, gdb 
> is
> IIRC compiled before GCC which probably also means you will be missing mpfr 
> and
> mpc too -- so best way for you may be following
> https://gcc.gnu.org/install/prerequisites.html
> 
> IIRC libraries are nice enough to provide pkg config scripts, but really just
> IIRC, you need to investigate yourself how to make them "available" for RSB.
> 
> BTW, the required libraries are also mentioned here:
> https://docs.rtems.org/branches/master/user/rsb/why-build-from-source.html

Yeap.

> Cheers,
> Karel
> 
> On 9/20/22 15:56, andrew.butterfi...@scss.tcd.ie wrote:
>>
>>
>> How do I fix this?

Andrew,

I have required for decades the RSB builds tools for MacOS with just Xcode.
Recent updates by Apple to MacOS has effected using the MacOS provided python
with a gdb build in some rather unpleasant ways. I will spare you the detail but
 Xocde is now set up so you cannot link the python runtime. I have not had time
to find a workable solution. I can see 2 possible paths long term ...

1. Disable python in GDB. I do not like this as pretty printers are used with 
C++

2. Detect and use a python.org installed Python

Watching the changes it seems Apple has been removing a bunch of things from the
OS it use to provide. For example Emacs as gone I think that is a good decision
because you can download a better more current version than Apple provided.
Maybe the same is happening with Python given python.org has a current and easy
to install solution.

In the very early days of the RSB when it was called SpecBuilder I stepped into
Homebrew or Macports, not sure which, and got lost deep in the weeds of detail.
I kept having issues with installed libraries when building gcc. I started
becoming more focused on dependent packages and fixes in them than a gcc build
for RTEMS. This was decades ago and I am not sure what the current state of
Homebrew or Macports are. If the RSB can work with them that would be great and
I would happily accept patches but it is not something I will spend time on.

Chris

>>
>>
>> On 20/09/2022, 14:41, "Karel Gardas"  wrote:
>>
>>
>>  You are missing isl library header file:
>>
>>  configure:6284: /usr/bin/cc -O2 -pipe -fbracket-depth=1024
>> 
>> -I/Users/butrfeld/REPOS/RTEMS/src/rsb/rtems/build/tmp/sb-501/tools/rtems-default-tools/Users/butrfeld/RTEMS/rtems/6/include
>>  -o conftest -g -O2
>> 
>> -L/Users/butrfeld/REPOS/RTEMS/src/rsb/rtems/build/tmp/sb-501/tools/rtems-default-tools/Users/butrfeld/RTEMS/rtems/6/lib
>>    -lisl -lmpc -lmpfr -lgmp conftest.c  -lisl -lgmp >&5
>>  conftest.c:10:10: fatal error: 'isl/schedule.h' file not found
>>  #include 
>>    ^~~~
>>  1 error generated.
>>
>>  Karel
>>
>>  On 9/20/22 15:35, andrew.butterfi...@scss.tcd.ie wrote:
>>  >
>>  >
>>  > Hi Karel,
>>  >
>>  > Gdb config.log now attached
>>  >
>>  > Andrew
>>  >
>>  >
>>  > On 20/09/2022, 14:17, "Karel Gardas"  wrote:
>>  >
>>  >
>>  >  Usually just last page is enough. Anyway, your report reports 
>> that
>> the
>>  >  compilation fails on gdb configure with:
>>  >
>>  >  configure: WARNING: MPFR is missing or unusable; some features 
>> may be
>>  >  unavailable.
>>  >  checking whether to use python... /opt/homebrew/bin/python3
>>  >  checking for python... no
>>  >  configure: error: no usable python found at 
>> /opt/homebrew/bin/python3
>>  >  make[1]: *** [configure-gdb] Error 1
>>  >
>>  >  if you look into gdb build directory you will see config.log 
>> there
>> which
>>  >  may tell you more about why your homebrew python3 fails.
>>  >
>>  >  Karel
>>  >
>>  >  On 9/20/22 15:02, Andrew Butterfield wrote:
>>  >  > Hi Karel,
>>  >  > here it is - I didn't want to attach this unless necessary!
>>  >  >
>>  >  > Regards,
>>  >  >    Andrew
>>  >  >
>>  >  >
>>  >  >
>>  >  >
>> 
>>  >  > Andrew Butterfield Tel: +353-1-896-2517 Fax:
>> +353-1-677-2204
>>  >  > Lero@TCD, Head of Software Foundations & Verification Research
>> Group
>>  >  > School of Computer Science and Statistics,
>>  >  > Room G.39, O'Reilly Institute, Trinity College, University of
>> Dublin
>>  >  >  
>> http://www.scss.tcd.ie/Andrew.Butterfield/
>>  >  >
>> 
>>  >  >
>>  >  >
>>  >  > -Original Message-
>>  >  > From: Karel Gardas 
>>  >  > Date: Tuesday 20 September 2022 at 14:00
>>  >  > To: "andrew.butterfi...@scss.tcd.ie"
>> , 

Re: What is meaning / usage of STM32F4_GPIO_CONFIG_TERMINAL

[Chris Johns]

On 9/9/2022 5:48 pm, Y. HB wrote:
> Sorry for the last message, it was sent by accident. I have known that the
> STM32F4_GPIO_CONFIG_TERMINAL is used inside start-config-io.c, and used as a
> termination of set_config_array.

No problem and thanks for letting us know.

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

Re: libgcrypt and rtems?

[Chris Johns]

On 31/8/2022 11:37 am, Scott Zemerick wrote:
> Hello!  I am interested if anyone has utilized libgcrypt
> (https://github.com/gpg/libgcrypt ) with
> rtems?  And as a followup question, if not libgcrypt, what crypto library are
> you using successfully?  We ask because we want to utilize our CryptoLib
> (https://github.com/nasa/CryptoLib/wiki
> ) on rtems.  Thanks!

We have https://git.rtems.org/rtems/tree/cpukit/libcrypt. In libbsd openssl can
be used. I have ported the crypto code from this https://tinyssh.org/.

The GNU library looks to be GPL or LGPL with some 3 clause BSD files and so we
will not include it.

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

Re: Try to load and run RTEMS Image on Cora-z7-10

[Chris Johns]

On 29/5/2022 6:57 am, Heinz Junkes wrote:
> Hi Chris,
> 
> I am trying to understand the problems my student is having with the 
> Cora-z7-10.
> 
> I am trying my hand at a beaglebone black and RTEMS6 (master).
> Unfortunately I have similar problems.
> 
> I built the rtems-examples.
> 
> rtems/6/bin/arm-rtems6-objcopy -R -S --strip-debug -O binary posix_hello.exe 
> posix_hello.bin
> cat posix_hello.bin | gzip -9 >posix_hello.gz
> rtems/6/bin/mkimage.py -A arm -O rtems -T kernel -a 0x8000 -e 0x8000 
> -n "PosixHello" -d posix_hello.gz posix_hello.img
> I then copied this image file to the SD card of the beaglebone black.
> 
> and boot it :
> …
> BeagleBone Black:
> BeagleBone: cape eeprom: i2c_probe: 0x54:
> BeagleBone: cape eeprom: i2c_probe: 0x55:
> BeagleBone: cape eeprom: i2c_probe: 0x56:
> BeagleBone: cape eeprom: i2c_probe: 0x57:
> Net: eth0: MII MODE
> cpsw, usb_ether
> Press SPACE to abort autoboot in 2 seconds
> =>
> => fatload mmc 0 0x8080 posix_hello.img
> 71208 bytes read in 7 ms (9.7 MiB/s)
> => fatload mmc 0 0x8800 am335x-boneblack.dtb
> 33325 bytes read in 3 ms (10.6 MiB/s)
> => bootm 0x8080 - 0x8800
> ## Booting kernel from Legacy Image at 8080 ...
> Image Name: PosixHello
> Created: 2022-05-28 20:26:28 UTC
> Image Type: ARM RTEMS Kernel Image (gzip compressed)
> Data Size: 71144 Bytes = 69.5 KiB
> Load Address: 8000
> Entry Point: 8000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
> ## Transferring control to RTEMS (at address 8000) ...
> 
> RTEMS Beagleboard: am335x-based
> ARM Debug: 0x4b141000
> *** FATAL ***
> fatal source: 1 (INTERNAL_ERROR_RTEMS_API)

The `rtems_fatal_error_occurred()` call is happening.

> fatal code: 22 (0x0016)

This code is the `rtems_status_code` which is `RTEMS_NOT_CONFIGURED`:

https://git.rtems.org/rtems/tree/cpukit/include/rtems/rtems/status.h#n204

I am not sure where this is called from. A grep shows only a few spots.

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

Re: Fwd: RTEMS 5 on mcp750 fails

[Chris Johns]

On 18/5/2022 9:36 am, Miroslaw Dach wrote:
> Dear RTEMS Users and Developers,
> 
> I have built RTEMS 5 with EPICS 7 and tried to boot my application on
> mcp750 cPCI board.
> The first thing that I have encountered is that the boot file is in the elf
> format so I have
> converted it to the binary one.:
> powerpc-rtems5-objcopy -I elf32-powerpc -O binary myApp.boot myApp.boot.bin

We removed the various post-link hooks.

> So far so good
> Next, I booted the system with my app and it fails in the  *bsp_early*
> function in
> bsps/powerpc/motorola_powerpc/start/bspstart.c
> 
> The boot sequence:
> Network Boot File load in progress... To abort hit 
> 
> Bytes Received =&1270208, Bytes Loaded =&1270208
> Bytes/Second   =&635104, Elapsed Time =2 Second(s)
> 
> Residual-Data Located at: $01F88000
> 
> Model: (e2)
> Serial: MOT000
> Processor/Bus frequencies (Hz): 366680480/66671508
> Time Base Divisor: 4000
> Memory Size: 200
> Residual: 1f88000 (length 27148)
> 
> PCI: Probing PCI hardware
> 
> RTEMS 5.0.0/PPC load:
> Uncompressing the kernel...
> done
> Now booting...
> -
> Welcome to rtems-5.0.0 (PowerPC/Generic (classic FPU)/mcp750) on Mesquite
> cPCI (MCP750)
> -
> idreg 0 = 0x1208029271
> OpenPIC found at 0xc100.
> pci : Configuring interrupt routing for 'Mesquite cPCI (MCP750)'
> pci : No bridge from bus 0 towards root found
> pci : No bridge from bus 0 towards root found
> pci : Device 1:0x0b:0 routed to interrupt_line 27
> pci : Device 1:0x0d:0 routed to interrupt_line 25
> Cleared PCI errors: pci_stat was 0x2280
> OpenPIC Version ? (2 CPUs and 16 IRQ sources) at 0x3238002688
> OpenPIC Vendor 0 (Unknown), Device 0 (Unknown), Stepping 2
> OpenPIC timer frequency is 8333848 Hz

This all looks OK.

> 
> *** FATAL ***
> fatal source: 0 (INTERNAL_ERROR_CORE)
> fatal code: 2 (INTERNAL_ERROR_TOO_LITTLE_WORKSPACE)
> RTEMS version: 5.0.0.fc89cc76804499eba3f3bc4097b795a84f07571a-modified
> RTEMS tools: 7.5.0 20191114 (RTEMS 5, RSB 5 (6225eadda1de), Newlib 7947581)
> executing thread is NULL
> 
> My application in the binary format uncompressed with stripped symbols is a
> 2.3M + 501K bootloader so I do not think that it
> is an issue with the WORKSPACE? The mcp750 has 32MB of RAM.
> How to detect what is the real cause of INTERNAL_ERROR_TOO_LITTLE_WORKSPACE
> ?
> Would it be the problem with the linker script ppcboot.lds?

I do not think so. I suggest you check the Classic API Guide here:

https://ftp.rtems.org/pub/rtems/releases/5/5.1/docs/html/c-user/config/intro.html#sizing-the-rtems-workspace

The accounting of memory is better and this means the extra space needed may
need to be adjusted. I am not sure where in EPCIS this is controlled and if it
can be overridden in your local configuration.

RTEMS 5 has a unified workspace and heap. This means the heap and workspace can
use memory until it is all used. The benefit is not need to manage the workspace
size statically:

https://ftp.rtems.org/pub/rtems/releases/5/5.1/docs/html/c-user/config/general.html#configure-unified-work-areas

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

Re: Try to load and run RTEMS Image on Cora-z7-10

[Chris Johns]

On 4/5/2022 3:56 pm, Sebastian Huber wrote:
> On 03/05/2022 16:43, Sarmad Ahmad wrote:
>> I create the image as follows
>>
>> ./mkimage.py -A arm -O linux -T kernel -a 0x1000 -e 0x1000 -n RTEMS 
>> -d
>> hello.exe test5.img
> 
> Maybe there is an issue with the mkimage.py script. I would try to use the
> mkimage tool from U-Boot.

I am using that script all the time with aarch64 and uboot without error. I am
using `-O rtems` and not `-O linux` so I do not know if that makes a difference.

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

Re: RTEMS5 for arm on macOS 12.3. Or how Apple blew up RTEMS.

[Chris Johns]

On 26/3/2022 8:44 am, Mr. Andrei Chichak wrote:
> Good day. It must be Friday afternoon, because my RTEMS5 install has been 
> messed up. Yes, this install worked until now.
> 
> RTEMS5, stm32f4 BSP, macOS
> 
> I recently updated macOS to 12.3 (Monterey) and a “feature" of 12.3 is the 
> removal of python 2.7. This caused arm-rtems5-gdb to fail with:
> 
> dyld[12480]: Library not loaded: 
> /System/Library/Frameworks/Python.framework/Versions/2.7/Python 
>  Referenced from: /Users/andreichichak/RTEMS5/rtems/5/bin/arm-rtems5-gdb
>  Reason: tried: 
> '/System/Library/Frameworks/Python.framework/Versions/2.7/Python' (no such 
> file), '/Library/Frameworks/Python.framework/Versions/2.7/Python' (no such 
> file) 
> Abort trap: 6
> 
> I went back to my install scripts, grabbed the latest RSB blob, then
> 
> ../source-builder/sb-set-builder —prefix=$HOME/RTEMS5/rtems/5 5/rtems-arm
> 
> goes well for a while then fails setting up to build gdb with:
> 
> config: tools/rtems-gdb-9.1-1.cfg
> error: config error: gdb-common-1.cfg:99: "gdb: python: header file not 
> found: python3.8/Python.h, please install”
> 
> I had python 3.9 installed, so I used brew and installed 3.8, uninstalled 
> 3.9, reinstalled 3.8, rebooted, but I get the same rsb failure.
> 
> I’m not sure how python is supposed to be configured. Maybe this is a clue:
> 
> python —version
> -bash: python: command not found
> 
> python3 —version
> Python 3.8.9
> 
> I seem to have a couple of instances of Python.h in an appropriately named 
> directory:
> 
> /usr/local/Cellar/python@3.8/3.8.13/Frameworks/Python.framework/Versions/3.8/include/python3.8/Python.h
> /System/Volumes/Data/usr/local/Cellar/python@3.8/3.8.13/Frameworks/Python.framework/Versions/3.8/include/python3.8/Python.h
> 
> But something doesn’t seem to be pointing at one of those folders so the rsb 
> script can find it.
> 
> Any hints?

I spent a small amount of time looking into the breakage around python on recent
MacOS versions and as you have discovered things have change. I need to look
into getting gdb to find and use the Xcode runtime for python3.

Chris

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

Re: Where can I get the kernel sources?

[Chris Johns]

On 3/2/22 4:02 am, Heinz Junkes wrote:
> I think I slept through the latest development. Sorry about that.

Welcome back.

> Where can I get the rtems sources (c/src)?

This directory has gone. It had only existed on the master branch recently to
hold the autoconf build files and we have now removed all autoconf support from
master. RTEMS 6 is the first release with the new waf build support.

The sources that lived under the `c/src` had been moved over a period of time in
stages. The first major change was moving all the header files to
`cpukit/include` and `bsps/include`, then non-bsp sources were moved to various
places then finally the bsp sources were moved to `bsps`. The autoconf build
files were not mived because we knew they were going to be removed.

The tree under the top level directory `bsps` is kind of the same as the old
path of `c/src/lib/libbsp`. There has been some changes in the bsps but this is
mostly improved reuse of sources across bsps.

Also gone from the tree is `cpukit/libnetworking`. The legacy networking stack
is now in a separate repo ... https://git.rtems.org/rtems-net-legacy/.

I hope this helps

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

Re: libbsd network on an mvme2500

[Chris Johns]

On 18/8/21 5:19 am, Chandler, Brendan wrote:
> I think I found the answer to my own issue.  I needed this configuration 
> option:
> #define CONFIGURE_MAXIMUM_USER_EXTENSIONS   5
> 
> With that, the error "cannot create extension" goes away and I can boot.
> 

Great to see you managed to solve the problem and thank you for letting us know.

Chris

> 
> 
> From: Chandler, Brendan 
> Sent: Tuesday, August 17, 2021 11:09
> To: users@rtems.org
> Subject: libbsd network on an mvme2500
> 
> Hi rtems-users,
> 
> I'm trying to set up a simple RTEMS 5 program to get my mvme2500 board up and 
> running with a static network configuration using libbsd.  I took the hello.c 
> example from the getting started guide, and modified it to use libbsd and 
> configure the network.  My problem is I get a runtime error when loading my 
> binary when I call rtems_bsd_initialize():
> 
> ## Booting kernel from Legacy Image at 1000 ...
>Image Name:   RTEMS
>Created:  2021-08-17  15:32:55 UTC
>Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>Data Size:968695 Bytes = 946 KiB
>Load Address: 4000
>Entry Point:  4000
>Verifying Checksum ... OK
> ## Flattened Device Tree blob at 2000
>Booting using the fdt blob at 0x2000
>Uncompressing Kernel Image ... OK
>Loading Device Tree to 00ff9000, end 00fff04a ... OK
> emerg: rtems_bsd_threads_init_early: cannot create extension
> 
> This seems to be coming from 
> rtems-libbsd/rtemsbsd/rtems/rtems-kernel-thread.c where the call to 
> rtems_extension_create() fails.
> 
> I've posted my code at github here:
> https://github.com/brendanchandler/test-rtems5
> 
> Can anyone help get around this error?  I'm probably missing some 
> configuration or setup, but haven't been able to determine what it is.
> 
> Thanks in advance for any help,
> Brendan
> 
> ___
> users mailing list
> users@rtems.org
> http://lists.rtems.org/mailman/listinfo/users
> 
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Versal VCK190 hardware test results

[Chris Johns]

Hi,

I ran a build of rtems.git master today on a Versal VCK190 eval board. The first
time we have run RTEMS on Versal silicon and an A72. Hello World worked first 
time.

I would like to thank Kinsey for the awesome aarch64 support and Gedare for the
fantastic effort getting the Versal and A72 support integrated.

I do not have a networked power switch connected to the eval board so these
results are really good:

Passed:568
Failed:  3
User Input:  5
Expected Fail:   0
Indeterminate:   0
Benchmark:   3
Timeout: 4
Test too long:   0
Invalid: 0
Wrong Version:   0
Wrong Build: 0
Wrong Tools: 1
--
Total: 584

I will try and get a test run posted to build @ rtems.org.

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

Re: RFC: Move Away from Freenode

[Chris Johns]

On 29/5/21 3:17 am, Johnson, Andrew N. wrote:
> On May 28, 2021, at 1:57 AM, Christian MAUDERER
>  > wrote:
>>
>> I still think it's a bit odd to say "Drop Freenode" because Freenode seems to
>> go into a more commercial direction but at the same time say that the Discord
>> (which seems to be commercial through and through) is a good alternative.
>>
>> In other words: As long as we don't mind using Discord, I would just keep the
>> Freenode IRC just like it is.
> 
> I’m not an IRC (or Discord) user so I won’t be affected whatever you decide, 
> but
> I wouldn’t categorize what has been happening at Freenode as “going in a more
> commercial direction.” The fact that any mention of Libera.chat in a channel 
> now
> seems to result in that organization’s channels being taken over may be more 
> of
> a risk than the RTEMS community would want to take. If Joel were to have even
> raised this question there you might have already lost control of those 
> channels.
> 
> If you want more of the back-story, here’s a free link to Wednesday's LWN
> article at https://lwn.net/SubscriberLink/857140/9dcadcf209612879/
>  which is more up to
> date than The Register story that Joel linked to.

Thanks Andrew. Any dispute like this is messy.

For RTEMS it is the content that is posted that we need to consider. It is
freely given and needs to be freely available to anyone to see at any point in
time. The means to do this can and will change.

Discord is free to use even through it is a commercially based service. If we
cannot easily access to the contents of the chats and archive them we need to
consider its long term viability.

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

Re: Manually building a BSP from branch 5 of git

[Chris Johns]

On 26/5/21 6:10 pm, Johnson, Andrew N. wrote:
> On May 25, 2021, at 8:18 PM, Vijay Kumar Banerjee  > wrote:
>>
>> I found the 5.1 docs version from rtems ftp. This looks like the right one:
>> https://ftp.rtems.org/pub/rtems/releases/5/5.1/docs/html/user/start/bsp-build.html#manual-bsp-build
>> 
> 
> Excellent, thanks – I would have expected that version of the User Manual to 
> be
> linked from the Releases table of https://devel.rtems.org/
>  on the row for branch 5.

Agreed and fixed. Thank you.

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

Re: Manually building a BSP from branch 5 of git

[Chris Johns]

On 26/5/21 1:18 pm, Vijay Kumar Banerjee wrote:
> I found the 5.1 docs version from rtems ftp. This looks like the right one:
> https://ftp.rtems.org/pub/rtems/releases/5/5.1/docs/html/user/start/bsp-build.html#manual-bsp-build

+1

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

Re: rsb (RTEMS source Builder) support for local mirrors ?

[Chris Johns]

On 27/4/21 4:07 am, Michael Davidsaver wrote:
> On 4/26/21 1:21 AM, Goetz Pfeiffer wrote:
>> Hello,
>>
>> I have used rsb to build my local cross compiler toolchain for RTEMS.
>>
>> This is a great tool, but it downloads all sources from some internet 
>> servers. The problem is
>> that servers may be down at the time I need them or that the locations of 
>> some files have changed
>> and rsb doesn't know about this.
>>
>> Would it be possible to change rsb in a way that it has an option to 
>> download all needed files from a
>> local mirror ?
> 
> I've had some success with running the RSB recipes twice.  First with 
> '--source-only-download',
> and then again with '--no-download'.  The second time uses previously 
> downloaded files,
> and can be run on a offline host.

Does the `--url` option work? It should point you to a local server.

A better or more complete way to handle tools is to "deploy" them. Deployed
tools lets you add a version label into the tools that can be seen with the
standard version option the tools come with. There is a real benefit to having a
special label in the version for deployed tool sets especially binary packages.

Unfortunately I have not had the time to document how to do this so here is a
brief untested procedure. It is pretty much what the release procedure does:

1. Clone or download the RSB source.

2. Add or edit a VERSION file in the top level of the RSB source. The 5.1
release tarball of the RSB has a version file.

3. Run the `sb-get-sources` command to fetch all the source and patches.

4. Package the RSB, source and patches.

Notes:

a) The format for the VERSION file is documented here:

https://git.rtems.org/rtems-source-builder/tree/source-builder/sb/version.py#n31

b) The release process creates the VERSION file here:

https://git.rtems.org/rtems-release/tree/rtems-release-rsb-version

c) The get sources command is better than the download options because it
downloads all patches for all archs and all hosts. This is a requirement for
releasing.

d) Released sources contain a released RTEMS kernel and RTEMS Tools and this
requires special management of the checksum the RSB uses when building from a
source package. The hashes for these packages are placed in the VERSION file.
The 5.1 release shows how this is done.

e) A simple and clean way to deploy ...  clone the release scripts and run them
:) Joel has patches for Linux he is yet to post so pester him if you would like
to follow this path. The release scripts handle the release path for downloading
and special release labels. The release procedure is open and available for just
this purpose.

>> In my case I would need this feature not just for version 5 of RTEMS but 
>> also for version
>> 4.9 and 4.10.

RTEMS 4.9, 4.10, and 4.11 would need some work to bring it inline with 5 to
support deployment. That work would need to be funded so if this is something
you need please contact me off list.

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

Re: Installing rtems on 32 bit windows host machine

[Chris Johns]

On 12/3/21 9:47 pm, Alireza Banejad wrote:
> any thoughts?

What are the names of the compilers that have been installed?

Chris

> 
> On Fri, Mar 12, 2021 at 4:00 AM Alireza Banejad  <mailto:alibanejad1...@gmail.com>> wrote:
> 
> thanks again,
> this time I installed Cygwin and run the sb-check and returned that the
> environment is ok, but  when installing rtems with the source builder it
> results in an error, checking out the log file tells me the following:
> checking whether to use python... /usr/bin/python2
> checking for python... no
> configure: error: no usable python found at /usr/bin/python2
> make[1]: *** [Makefile:9705: configure-gdb] Error 1
> make[1]: Leaving directory
> 
> '/cygdrive/c/opt/rtems/rsb/rtems/build/arm-rtems6-gdb-6427605-i686-pc-cygwin-1/build'
> make: *** [Makefile:857: all] Error 2
> shell cmd failed: sh -ex
>  
> /cygdrive/c/opt/rtems/rsb/rtems/build/arm-rtems6-gdb-6427605-i686-pc-cygwin-1/do-build
> error: building arm-rtems6-gdb-6427605-i686-pc-cygwin-1
> i don't know why this happens even though python exists in this path?. I
> also have the python-devel and python3-devel packages installed
> 
> On Fri, Mar 12, 2021 at 2:22 AM Joel Sherrill  <mailto:j...@rtems.org>> wrote:
> 
> Re-adding devel@ to keep things recorded.
> 
> On Thu, Mar 11, 2021 at 1:23 PM Alireza Banejad
> mailto:alibanejad1...@gmail.com>> wrote:
> 
> Hello Joel,
> thank you for responding, 
> so basically I installed the msys2 i686 and downloaded the 
> packages
> and finally downloaded themingw-w64-i686-toolchain, after 
> exporting
> the proper path of the compiler I ran the 
> gcc -dumpmachine command, it returned i686-w64-mingw32 yet the
> sb-check of rsb wants a i686-w32-mingw32-gcc compiler. 
> 
> 
> Chris Johns will hopefully jump in shortly. 
> 
> 
> On Thu, Mar 11, 2021 at 10:42 PM Joel Sherrill  <mailto:j...@rtems.org>> wrote:
> 
> 
> 
> On Thu, Mar 11, 2021 at 1:05 PM Alireza Banejad
> mailto:alibanejad1...@gmail.com>> 
> wrote:
> 
> Hello everyone,
> I was wondering whether I could install RTEMS on a 32-bit
> Windows 7 host machine using either msys2 or Cygwin.
> I already tried installing it on msys2 i686 but when 
> running
> sb-check it returns:
> 
> |error: exe: not found: (__cc) i686-w32-mingw32-gcc error:
> exe: not found: (__cxx) |i686-w32-mingw32-g++
> 
> Environment is not correctly set up.
> 
> It seems there is no such compiler as 
> i686-w32-mingw32-gcc to add in the first place.
> 
> 
> Assuming you have installed the gcc package, what is the
> compiler called? 
> 
> I don't think any of the core developers have seen Windows 7
> especially 32-bit in a while. 
>  
> The file that sets the expectations based on host is
> source-builder/sb/windows.py. It may require some tinkering to
> match a 32-bit environment.
> 
> We'd love to have a patch to that file (don't break 64-bit) 
> and,
> if needed, documentation.
> 
> --joel
> 
> 
> ___
> users mailing list
> users@rtems.org <mailto:users@rtems.org>
> http://lists.rtems.org/mailman/listinfo/users
> <http://lists.rtems.org/mailman/listinfo/users>
> 
> 
> ___
> users mailing list
> users@rtems.org
> http://lists.rtems.org/mailman/listinfo/users
> 
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Offline download of sources fails

[Chris Johns]

On 11/3/21 4:37 pm, Ida Delphine wrote:
> When I run it again with "--trace" I still get the same output. Nothing extra.
> Don't know if I am missing something...

It could by my instructions. I would need to check but I am not able to at the
moment.

If you are using git and are up to date on master or the 5 branch there are some
fixes that have some issues that are being looked into. It looks similar ..

https://devel.rtems.org/ticket/4335

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

Re: Offline download of sources fails

[Chris Johns]

On 11/3/21 4:17 pm, Ida Delphine wrote:
> My development host is Ubuntu 20.04 not Windows. 

Oh I do apologise, for some reason I thought your host was Windows.

> Also I'm a bit confused on how
> to run it with --trace to find the log file. Can you please help me with some
> context? 

Add the option `--trace` and run the command again. There should be a log with a
date/time stamp in the name or you can specify --log= to have a specific log.
The trace will add a lot more output. Once created please search it for the bit
you see as failing and it may highlight what is going wrong. Or upload it
somewhere so I can download it and have a look.

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

Re: Offline download of sources fails

[Chris Johns]

On 11/3/21 3:34 pm, Ida Delphine wrote:
> Hello again,
> 
> So I started over and downloaded all the required packages for my host (Ubuntu
> 20.04) and still have offline download issues...
> Please take a look at the error message:
> 
> RTEMS Source Builder - Set Builder, 6 (fe2d13b6daf3)
> Build Set: 6/rtems-sparc
> Build Set: 6/rtems-autotools.bset
> Build Set: 6/rtems-autotools-internal.bset
> config: tools/rtems-autoconf-2.69-1.cfg
> config: tools/rtems-automake-1.12.6-1.cfg
> Build Sizes: usage: 0.000B total: 19.014KB (sources: 0.000B, patches: 
> 19.014KB,
> installed 0.000B)
> Build Set: Time 0:00:00.933172
> Build Set: 6/rtems-autotools-base.bset
> config: tools/rtems-autoconf-2.69-1.cfg
> config: tools/rtems-automake-1.12.6-1.cfg
> Build Sizes: usage: 0.000B total: 19.014KB (sources: 0.000B, patches: 
> 19.014KB,
> installed 0.000B)
> Build Set: Time 0:00:00.840448
> Build Set: Time 0:00:01.777350
> config: devel/expat-2.1.0-1.cfg
> package: expat-2.1.0-x86_64-linux-gnu-1
> Creating source directory: sources
> download:
> https://github.com/libexpat/libexpat/releases/download/R_2_1_0/expat-2.1.0.tar.gz
>  
> 
> -> sources/expat-2.1.0.tar.gz
>  redirect:
> https://github-releases.githubusercontent.com/80314213/0186bc60-b675-11e7-83c0-13aced4..
> . log>
> downloading: sources/expat-2.1.0.tar.gz - 549.4kB of 549.4kB (100%)
> reporting: devel/expat-2.1.0-1.cfg -> expat-2.1.0-x86_64-linux-gnu-1.txt
> reporting: devel/expat-2.1.0-1.cfg -> expat-2.1.0-x86_64-linux-gnu-1.xml
> config: devel/gmp-6.1.0.cfg
> package: gmp-6.1.0-x86_64-linux-gnu-1
> download: https://gcc.gnu.org/pub/gcc/infrastructure/gmp-6.1.0.tar.bz2
>  ->
> sources/gmp-6.1.0.tar.bz2
> downloading: sources/gmp-6.1.0.tar.bz2 - 2.3MB of 2.3MB (100%)  
> reporting: devel/gmp-6.1.0.cfg -> gmp-6.1.0-x86_64-linux-gnu-1.txt
> reporting: devel/gmp-6.1.0.cfg -> gmp-6.1.0-x86_64-linux-gnu-1.xml
> config: tools/rtems-gdb-10.cfg
> error: shell macro failed:
> /home/idadel/quick-start/src/rsb/source-builder/sb/rtems-build-dep -c gcc  -l 
> :
> 2: error: no library (-l) provided

I think this looks like something with Windows and the shell.

Could you please run with --trace and then search the log file for this the
above line. The shell macro should be present that failed.

> Build FAILED
> Build Set: Time 0:00:12.713688
> Build FAILED
> 
> Also for some reason when I run "sb-check" it tells me "command not found"

This looks like a Windows issue.

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

Re: Offline download of sources fails

[Chris Johns]

On 11/3/21 8:23 am, Michael Davidsaver wrote:
> On 3/10/21 10:55 AM, Chris Johns wrote:
>> ...
>> Also have a look at the command sb-get-sources. It will fetch the source and
>> patches for all hosts and architectures.
> 
> Neat.  I've been wishing for something like this as I'd like to archive full
> source along with toolchain builds.  

The patches and sources directories hold everything.

> Would it handle something like an
> arch/bsp specific patches to rtems-kernel or rtems-libbsd?  (assuming there
> can be such things)

If the RSB is configured to download a patch this tool will download it. The
kernel and libbsd tend to be built based on a commit in their respective repos
the RSB downloads a tarball of the source that is uses.

Note, the RSB supports a released mode that is controlled by the VERSION file in
the root directory of the RSB. This can be used to deploy source locally. The
release scripts ...

https://git.rtems.org/rtems-release/tree/rtems-release-sources

... do this when creating a release.

>> $ ../source-builder/sb-get-sources --tar 5/rtems-powerpc 5/rtems-i386 
>> 5/rtems-arm 5/rtems-kernel 5/rtems-libbsd
>> RTEMS Source Builder - Get Sources, 5 (803d42cda7b3)
>> ...
>> Build Set: 5/rtems-i386 for win32
>> error: 5/rtems-i386:5: %patch duplicate add: 
>> https://devel.rtems.org/raw-attachment/ticket/2830/gcc-7.5.0-i386march-1.diff
>> Build Set: Time 0:00:00.000236
>> Build FAILED
> 
> I guess the recent march patch breaks this somehow?
> 

The patch link looks fine and I can download it with my browser. I wonder if
this is a Windows thing?

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

Re: Offline download of sources fails

[Chris Johns]

On 10/3/21 11:57 pm, Joel Sherrill wrote:
> On Wed, Mar 10, 2021, 6:42 AM Ida Delphine  > wrote:
> 
> Hello,
> On trying to download my sources using this command stated in the 
> documentation:
> 
> ../source-builder/sb-set-builder --source-only-download 5/rtems-sparc
> 
> Unfortunately, I get some errors and the build fails:
> RTEMS Source Builder - Set Builder, 6 (47d540e7f9fe)
> error: exe: not found: (__bison) /usr/bin/bison
> error: exe: not found: (__flex) /usr/bin/flex
> error: host build environment is not set up correctly
> Build FAILED
> 
> Please what's the way out? I've been trying to resolve this for hours.
> 
> You are missing some programs on your development host.
> 
> There is sb-check which will do a more thorough review of what you should have
> installed.
> 
> I do not see your host listed but the Users Manual has a section for most host
> operating systems with detailed instructions for installing the dependencies.
> You need to use their package manager to install at least bison and flex. You
> are likely also missing some development libraries needed.
> 
> Check the users guide.

Also have a look at the command sb-get-sources. It will fetch the source and
patches for all hosts and architectures.

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

Re: Problem by installing RTEMS 5.1 on Windows 10

[Chris Johns]

On 5/3/21 7:36 pm, Olga Syrbachova wrote:
> Thank you very much for your reply. I'm using MSYS2 MinGW 64-bit.
> Actually I also tried to install RTEMS 4.11.0 and 4.11.2 and I didn't succeed.
> After running:
> $ ../source-builder/sb-set-builder --prefix=/opt/rtems/4.11 4.11/rtems-sparc
> --jobs=none
> 
> in ...@LAPTOP-NOT8H6PV MINGW64 /c/opt/rtems/4.11.0/rtems
> 
> I got this error:
> ...
> package: expat-2.1.0-x86_64-w64-mingw32-1
> Build Set: Time 0:04:39.603651
> Traceback (most recent call last):
>   File "../source-builder/sb-set-builder", line 29, in 
>     setbuilder.run()
>   File "../source-builder/sb/setbuilder.py", line 502, in run
>     b.build(deps)
>   File "../source-builder/sb/setbuilder.py", line 354, in build
>     self.build_package(configs[s], b)
>   File "../source-builder/sb/setbuilder.py", line 191, in build_package
>     _build.make()
>   File "../source-builder/sb/build.py", line 471, in make
>     self.builddir()
>   File "../source-builder/sb/build.py", line 340, in builddir
>     self.rmdir(builddir)
>   File "../source-builder/sb/build.py", line 161, in rmdir
>     path.removeall(rmpath)
>   File "../source-builder/sb/path.py", line 150, in removeall
>     os.unlink(file)
> PermissionError: [WinError 5] Zugriff verweigert:
> 'C:\\opt\\rtems\\4.11.0\\rtems\\build\\e2xwm1\\expat-2.1.0\\xmlwf\\xmlwf.exe'

Is that command running? Something has this file locked.

Is Windows running in a VM or on hardware?

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

Re: Problem by installing RTEMS 5.1 on Windows 10

[Chris Johns]

On 5/3/21 7:11 am, Olga Syrbachova wrote:
> Hi! I have a problem installing RTEMS. I follow the tutorial step by step, but
> something goes wrong. I work on Windows 10.
> 
> My steps after creating /c/opt/rtems
> 
> $ wget
> https://ftp.rtems.org/pub/rtems/releases/5/5.1/sources/rtems-source-builder-5.1.tar.xz
> 
> $ tar Jxf rtems-source-builder-5.1.tar.xz
> $ mv rtems-source-builder-5.1 5.1
> ...
> $ source-builder/sb-check
> RTEMS Source Builder - Check, 5.not_released
> Environment is ok
> 
> What does 5.not_released mean?
> 

At a guess there is no VERSION file in the stop of the RSB source package which
would seem strange give this exists in releases. If there is it is a bug in the
RSB on Windows.

> By running 
> $ ../source-builder/sb-set-builder --list-bsets
> I get 
> $ ../source-builder/sb-set-builder --list-bsets
> RTEMS Source Builder - Set Builder, 5.1
> Traceback (most recent call last):
>   File "../source-builder/sb/cmd-set-builder.py", line 26, in 
>     setbuilder.run()
>   File "../source-builder/sb/setbuilder.py", line 722, in run
>     if not list_bset_cfg_files(opts, configs):
>   File "../source-builder/sb/setbuilder.py", line 670, in list_bset_cfg_files
>     print('Examining: %s' % (os.path.relpath(p)))
> LookupError: unknown encoding: cp65001

What shell environment are you using?

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

Re: RTEMS 5 ARM gdb missing python support? Am I building it wrong?

[Chris Johns]

On 5/3/21 6:41 am, Isaac Gutekunst wrote:
> I recompiled the tools the exact same way, and the problem appears to be gone
> away. Sorry for the noise your inboxes!

No problem and thanks for letting us know all is OK.

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

Re: ANN: RTEMS libnetworking relocation

[Chris Johns]

On 4/3/21 9:24 am, Gedare Bloom wrote:
> We have had third-party validation on hardware tests (Thanks to Heinz
> Junkes!) that ironed out a few minor issues. The network stack update
> will be pushed tomorrow. *Fingers crossed* everything just works as
> usual for rtems6 for anyone who isn't using libnetworking.

Congratulations.

Vijay, awesome work, a really great contribution. Thank you.

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

Re: xilinx_zynq_a9_qemu with RTEMS 6 keyboard input is ignored

[Chris Johns]

On 25/2/21 4:35 am, Christian Mauderer wrote:
> On 24/02/2021 06:45, Chris Johns wrote:
>> On 24/2/21 4:21 pm, Gedare Bloom wrote:
>>> On Tue, Feb 23, 2021 at 10:20 PM Gedare Bloom  wrote:
>>>>
>>>> On Tue, Feb 23, 2021 at 3:36 PM Chris Johns  wrote:
>>>>>
>>>>> On 24/2/21 5:53 am, Heinz Junkes wrote:
>>>>>> it works with the Ubuntu package : qemu-system-arm 1:4.2-3ubuntu6.14
>>>>>
>>>>> That is interesting. Which version of qemu does ubuntu provide?
>>>>>
>>>> That's qemu-4.2
>>>
>>> https://launchpad.net/ubuntu/+source/qemu/1:4.2-3ubuntu6.14
>>>
>>> With a couple of patches applied
>>
>> We are now on qemu-5 
>>
>> https://git.rtems.org/rtems-source-builder/tree/bare/config/devel/qemu.bset
>>
>> I moved us to this version to pick up the fixes to the networking support 
>> when
>> debugging on the zynq. There was an invalid assert that stopped qemu with gdb
>> connected and a network interface configured. I work around the problem on 
>> the
>> zynq by using telnet.
>>
>> Chris
> 
> Seems to be a very version specific problem. Everything works fine with a qemu
> from the master branch from a few days back (b826fb8002e624).

This is good to hear. I will see if there is a later release.

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

Re: xilinx_zynq_a9_qemu with RTEMS 6 keyboard input is ignored

[Chris Johns]

On 24/2/21 4:21 pm, Gedare Bloom wrote:
> On Tue, Feb 23, 2021 at 10:20 PM Gedare Bloom  wrote:
>>
>> On Tue, Feb 23, 2021 at 3:36 PM Chris Johns  wrote:
>>>
>>> On 24/2/21 5:53 am, Heinz Junkes wrote:
>>>> it works with the Ubuntu package : qemu-system-arm 1:4.2-3ubuntu6.14
>>>
>>> That is interesting. Which version of qemu does ubuntu provide?
>>>
>> That's qemu-4.2
> 
> https://launchpad.net/ubuntu/+source/qemu/1:4.2-3ubuntu6.14
> 
> With a couple of patches applied

We are now on qemu-5 

https://git.rtems.org/rtems-source-builder/tree/bare/config/devel/qemu.bset

I moved us to this version to pick up the fixes to the networking support when
debugging on the zynq. There was an invalid assert that stopped qemu with gdb
connected and a network interface configured. I work around the problem on the
zynq by using telnet.

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

Re: xilinx_zynq_a9_qemu with RTEMS 6 keyboard input is ignored

[Chris Johns]

On 24/2/21 5:53 am, Heinz Junkes wrote:
> it works with the Ubuntu package : qemu-system-arm 1:4.2-3ubuntu6.14

That is interesting. Which version of qemu does ubuntu provide?

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

Re: MVME2500 (qoriq_e500) no longer boots with RTEMS6

[Chris Johns]

On 20/2/21 6:17 pm, Heinz Junkes wrote:
> I was totally happy with the Makefile provided by Christian.
> It saved me a lot of typing and made it possible for me to play 
> through different variants in a really structured and consistent way 
> without "forgetting something every now and then".
> Such help is very important for people like me who are not 
> permanently in the RTEMS cloud ;-)
> Thanks to all for the useful hints and support.

This is great to hear and as Christian said it his sandbox to aid him.

If you are interested in having this BSP integrated into the eco-system the
approach Andrew Johnson posted for the m68k/uC5282 is worth a look 

https://lists.rtems.org/pipermail/users/2021-February/068148.html

A bset file like that is all we need to add it to the RSB.

Chris

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

Re: xilinx_zynq_a9_qemu with RTEMS 6 keyboard input is ignored

[Chris Johns]

On 20/2/21 7:10 am, junkes wrote:
> running test programs with keyboard input. Is ignored on xilinx_zynq_a9_qemu

This is a known issue with qemu, well the one the RSB is building. It is a pain
but I am not sure what has broken. The zynq code is running on hardware.

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

Re: RTEMS 5.1: cmath compiler errors on m68k/uC5282

[Chris Johns]

On 17/2/21 7:16 am, Johnson, Andrew N. wrote:
> I tried to build the in-progress port of EPICS for the uC5282 BSP last night 
> against a release build of RTEMS-5.1 with tools and BSP built using RSB. It 
> looks like the g++ cmath routines haven't been configured properly for this 
> target. It failed at the first C++ source file includes math.h (other BSPs 
> such as the beatnik and qoriq_e500 get further than this, and only the pc686 
> build completely succeeds right now):
> 
>> /local/anj/RTEMS-5.1/rtems-5.1/bin/m68k-rtems5-g++ 
>> -B/local/anj/RTEMS-5.1/rtems-5.1/m68k-rtems5/uC5282/lib/ -specs bsp_specs 
>> -qrtems -mcpu=5282   -D_GNU_SOURCE -D_DEFAULT_SOURCE
>> -DUNIX  -O2 -g -ffunction-sections -fdata-sections   -Wall   
>> -DMY_DO_BOOTP=NULL-D__LINUX_ERRNO_EXTENSIONS__ -DHAVE_SOCKADDR_SA_LEN=1  
>> -I. -I../O.Common -I. -I../osi/compiler/gcc -I../osi/compiler/default -I. 
>> -I../osi/os/RTEMS-posix -I../osi/os/RTEMS -I../osi/os/posix 
>> -I../osi/os/default -I.. -I../as -I../bucketLib -I../calc -I../cvtFast 
>> -I../cppStd -I../cxxTemplates -I../dbmf -I../ellLib -I../env -I../error 
>> -I../fdmgr -I../flex -I../freeList -I../gpHash -I../iocsh -I../log 
>> -I../macLib -I../misc -I../osi -I../pool -I../ring -I../taskwd -I../timer 
>> -I../yacc -I../yacc -I../yajl -I../../../../include/compiler/gcc 
>> -I../../../../include/os/RTEMS -I../../../../include -c 
>> ../cxxTemplates/resourceLib.cpp
>> In file included from 
>> /local/anj/RTEMS-5.1/rtems-5.1/lib/gcc/m68k-rtems5/7.5.0/include/c++/math.h:36:0,
>>  from ../cxxTemplates/resourceLib.h:38,
>>  from ../cxxTemplates/resourceLib.cpp:15:
>> /local/anj/RTEMS-5.1/rtems-5.1/lib/gcc/m68k-rtems5/7.5.0/include/c++/cmath:1086:11:
>>  error: '::acoshl' has not been declared
>>using ::acoshl;
>>^~
>> /local/anj/RTEMS-5.1/rtems-5.1/lib/gcc/m68k-rtems5/7.5.0/include/c++/cmath:1090:11:
>>  error: '::asinhl' has not been declared
>>using ::asinhl;
>>^~
>> /local/anj/RTEMS-5.1/rtems-5.1/lib/gcc/m68k-rtems5/7.5.0/include/c++/cmath:1094:11:
>>  error: '::atanhl' has not been declared
>>using ::atanhl;
>>^~
>>
>> ... many similar errors snipped ...
>>
>> /local/anj/RTEMS-5.1/rtems-5.1/lib/gcc/m68k-rtems5/7.5.0/include/c++/cmath:1220:11:
>>  error: '::tgammal' has not been declared
>>using ::tgammal;
>>^~~
>> /local/anj/RTEMS-5.1/rtems-5.1/lib/gcc/m68k-rtems5/7.5.0/include/c++/cmath:1224:11:
>>  error: '::truncl' has not been declared
>>using ::truncl;
>>^~
> 
> There could very well have been errors building the BSP on my part as I had 
> to hand-create a uC5282.bset file for RSB to build it:
> 
>> tux% cat config/5/bsps/uC5282.bset 
>> %define mail_single_report 1
>>
>> %define with_rtems_bsp uC5282
>> %define rtems_target   m68k-rtems5
>> %define rtems_host %{rtems_target}
>>
>> 5/rtems-m68k
>> 5/rtems-kernel
>> 5/rtems-libbsd

This file looks fine. I copied this into a file in my 5.1 RSB and built it
without error. The end of the build is:

ruru rtems $ ../source-builder/sb-set-builder
--prefix=/builds/rtems/release/5.1/install --log=uC5282.txt
--with-rtems-tests=yes 5/bsps/uC5282

RTEMS Source Builder - Set Builder, 5.1
Build Set: 5/bsps/uC5282

Build Set: 5/rtems-m68k.bset
 
Installing: 5/bsps/uC5282 -> /builds/rtems/release/5.1/install
clean staging: 5/bsps/uC5282
Staging Size: 2.540GB
Build Set: Time 0:22:20.672548
ruru rtems $ /builds/rtems/release/5.1/install/bin/m68k-rtems5-g++ --version
m68k-rtems5-g++ (GCC) 7.5.0 20191114 (RTEMS 5, RSB 5.1, Newlib 7947581)

> The libbsd line there might be wrong, but I wouldn’t expect that to affect 
> the availability of  functions to the C++ compiler.

The libbsd did not cause an issue for me.

What host are you on?

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

Re: AW: RTEMS mkimage.py for U-Boot scripts

[Chris Johns]

On 12/2/21 2:31 am, andre.nahrw...@dlr.de wrote:
> There has been a small typo in the previous patch.

Thank you for the patch. Could you please send it as a git patch to
de...@rtems.org or attach it to a ticket in Trac?

This may help ...

https://docs.rtems.org/branches/master/eng/vc-users.html?highlight=commit#creating-a-patch

Thanks
Chris

> 
> -Ursprüngliche Nachricht-
> Von: users  Im Auftrag von andre.nahrw...@dlr.de
> Gesendet: Donnerstag, 11. Februar 2021 16:14
> An: users@rtems.org
> Betreff: AW: RTEMS mkimage.py for U-Boot scripts
> 
> Hello,
> 
> after some digging I think I found the problem and at least a workaround.
> 
> As a disclaimer, I do not know if this really counts as a general fix.
> I have not invested enough time to dig through the original mkimage U-Boot 
> source to figure this out.
> But I have attached my workaround patch if anyone might face the same 
> problems.
> 
> The source of the problem are eight bytes between the header and the actual 
> input file which are missing when using mkimage.py.
> Also the input size and input crc are wrong which is a result of the missing 
> bytes.
> 
> These eight bytes always reflect the actual size of the input file (first 
> four bytes) with four bytes zeros following.
> Within the original mkimage tool these eight bytes are considered part of the 
> input file section in the output file.
> Therefore the calculated input size is eight bytes higher and the input crc 
> differs.
> 
> As a workaround the mkimage.py script will add these eight bytes to the 
> output file and the input crc calculation and adjusts the input size.
> This only happens when the type script was selected.
> 
> Best regards
> André
> 
> -Ursprüngliche Nachricht-
> Von: users  Im Auftrag von andre.nahrw...@dlr.de
> Gesendet: Dienstag, 26. Januar 2021 08:09
> An: users@rtems.org
> Betreff: RTEMS mkimage.py for U-Boot scripts
> 
> Hello,
> 
> in our laboratory setup we use different U-Boot scripts to control the boot 
> behavior of our development board (Trenz TE0715 [1] on top of Trenz TE0706 
> [2]).
> 
> These simple scripts need to be converted into a script image using the 
> mkimage command for U-Boot. [3] We use the following command which works fine:
> 
> ./mkimage -A arm -T script -C none -n "fancy name" -d bootscripts/rtems 
> rtems.img
> Image Name:   fancy name
> Created:  Tue Jan 26 06:57:50 2021
> Image Type:   ARM Linux Script (uncompressed)
> Data Size:324 Bytes = 0.32 KiB = 0.00 MiB
> Load Address: 
> Entry Point:  
> Contents:
>Image 0: 316 Bytes = 0.31 KiB = 0.00 MiB
> 
> Because our setup also depends on the rtems-zynq-mkimg command and the rtems 
> environment to be available we wanted to switch to the usage of the 
> mkimage.py command which comes via RTEMS.
> BUT every script image we generate with this tool behaves different than the 
> one we generated with mkimage.
> First of all is the output different, including a different resulting file 
> size and a missing contents section.
> 
> mkimage.py -A arm -T script -C none -n "fancy name" -d bootscripts/rtems 
> rtems.img
> Image Name:fancy name
> Created:   Tue Jan 26 08:00:06 2021
> Image Type:none
> Data Size: 316
> Load Address:  0
> Entry Point:   0
> 
> Adding the OS option with linux or u-boot does seem to change something, but 
> the resulting script image is again not usable.
> 
> I became aware of this because when a script image like this is uploaded to 
> U-Boot and sourced, no error occurs but also nothing else happens.
> Usually it should print some information on what the script is doing and then 
> well do its intended operations like it does when it is converted via the 
> mkimage script.
> 
> Has somebody else had the same issue and maybe even overcome it?
> Or does anybody have a clue where the problem may originate from?
> 
> Thanks in advance for the answer and help.
> 
> [1] 
> https://wiki.trenz-electronic.de/display/PD/TE0715+TRM#TE0715TRM-KeyFeatures
> [2] 
> https://wiki.trenz-electronic.de/display/PD/TE0706+TRM#TE0706TRM-KeyFeatures
> [3] https://www.denx.de/wiki/DULG/UBootScripts 
> 
> Best regards
> Andre Nahrwold
> --
> Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR) German Aerospace Center 
> Institute for Software Technolog | SRV-OSS BS | Lilienthalpl. 7 | 38108 
> Braunschweig | Geb. 112C Raum 001 M.Sc. Andre Nahrwold | Telephone +49 531 
> 295-3834 | andre.nahrw...@dlr.de DLR.de
> 
> ___
> users mailing list
> users@rtems.org
> http://lists.rtems.org/mailman/listinfo/users
> 
> 
> ___
> users mailing list
> users@rtems.org
> http://lists.rtems.org/mailman/listinfo/users
> 
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: RTEMS5 checksum failure file: sources/jpegsrc.v9a

[Chris Johns]

On 2/2/21 4:36 am, Gedare Bloom wrote:
> Indeed. It seems the sha512 has changed. The file doesn't appear to be 
> different
> on the http server. I found a copy
> at https://download.videolan.org/contrib/jpeg/
>  that has a matching sha512sum as
> we expect in the RSB. 

RSB matching version is:

https://ftp.rtems.org/pub/rtems/releases/5/5.1/sources/jpegsrc.v9a.tar.gz

Releases copy in the sources to protect against this. Please consider a ticket
and patch for the RSB for the 5 branch as OK given ...

> I compared those two tar files, and found this:
> 
> --rw-r--r-- 1 gedare gedare   4807 May  2  2010 makejvcx.v10
> --rw-r--r-- 1 gedare gedare   3595 May  2  2010 makecvcx.v10
> --rw-r--r-- 1 gedare gedare   3595 May  2  2010 makedvcx.v10
> --rw-r--r-- 1 gedare gedare   2876 May  2  2010 makervcx.v10
> --rw-r--r-- 1 gedare gedare   3535 May  2  2010 maketvcx.v10
> --rw-r--r-- 1 gedare gedare   2876 May  2  2010 makewvcx.v10
> --rw-r--r-- 1 gedare gedare   2288 May  2  2010 makecfil.v10
> --rw-r--r-- 1 gedare gedare   2288 May  2  2010 makedfil.v10
> --rw-r--r-- 1 gedare gedare   1142 May  2  2010 makerfil.v10
> --rw-r--r-- 1 gedare gedare   2123 May  2  2010 maketfil.v10
> --rw-r--r-- 1 gedare gedare   1142 May  2  2010 makewfil.v10
> --rw-r--r-- 1 gedare gedare   1859 May  1  2010 makeasln.v10
> --rw-r--r-- 1 gedare gedare    679 May  1  2010 makejsln.v10
> --rw-r--r-- 1 gedare gedare   5789 May  1  2010 makejfil.v10
> +-rw-r--r-- 1 gedare gedare   4804 May  2  2010 makejvcx.v10
> +-rw-r--r-- 1 gedare gedare   3592 May  2  2010 makecvcx.v10
> +-rw-r--r-- 1 gedare gedare   3592 May  2  2010 makedvcx.v10
> +-rw-r--r-- 1 gedare gedare   2873 May  2  2010 makervcx.v10
> +-rw-r--r-- 1 gedare gedare   3532 May  2  2010 maketvcx.v10
> +-rw-r--r-- 1 gedare gedare   2873 May  2  2010 makewvcx.v10
> +-rw-r--r-- 1 gedare gedare   2285 May  2  2010 makecfil.v10
> +-rw-r--r-- 1 gedare gedare   2285 May  2  2010 makedfil.v10
> +-rw-r--r-- 1 gedare gedare   1139 May  2  2010 makerfil.v10
> +-rw-r--r-- 1 gedare gedare   2120 May  2  2010 maketfil.v10
> +-rw-r--r-- 1 gedare gedare   1139 May  2  2010 makewfil.v10
> +-rw-r--r-- 1 gedare gedare   1856 May  1  2010 makeasln.v10
> +-rw-r--r-- 1 gedare gedare    676 May  1  2010 makejsln.v10
> +-rw-r--r-- 1 gedare gedare   5786 May  1  2010 makejfil.v10
> 
> It appears that someone has removed some unicode characters or similar ( 
> <8b>¯¨
> ) from the file header line
> +
> of all these .v10 files in the ijg.org  download, without
> somehow modifying the file metadata.

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

Re: Using LwIP on the STM32H7

[Chris Johns]

On 2/2/21 8:32 am, Mr. Andrei Chichak wrote:
> Is there any advantage to using bsd networking over LWiP, or vice versa? 

They are different stacks with different feature sets and different hardware
resource demands. I am not familiar with the features of LwIP so I am not the
best person to compare them.

The BSD stack has most of the features you get with FreeBSD. It has IPv4, IPv6,
IPsec, VLAN, bridging, dhcp, openssl, lots of routing alternatives, packet
filtering and more. It has a range of useful commands including tcpdump.

The BSD based system provides a solid base to solve a range of networking issues
your RTEMS device may encounter at the system level and not at the low level
programming level.

The BSD stack uses a lot more resources to do all this and LwIP may be a prefect
fit. I welcome RTEMS being able to support a range of networking solutions.

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

Re: Using LwIP on the STM32H7

[Chris Johns]

On 29/1/21 12:35 am, Robin Müller wrote:
> Are there any other thinks I need to take into account for making LwIP
> work with RTEMS?

I have not used LwIP but there is an RSB package ...

https://git.rtems.org/rtems-source-builder/tree/rtems/config/net/lwip-1-1.cfg

It has a patch. I have no idea about the state of the patch or what it does.

Any updates to LwIP would be welcomed back into the project.

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

Re: Build failure on windows

[Chris Johns]

On 19/1/21 12:26 pm, jameszxj wrote:
> Hi,
>  I got the error message??MSYS2use python2-config
> 
> 
> config: tools/rtems-gdb-head.cfg
> error: shell macro failed: sh -c "/mingw64/bin/python2-config --ldflags | awk 
> 'BEGIN{FS=\" \"}/python/{for(i=1;i \"lib\"substr($i,3)\"*\";}'": 1: awk: cmd. line:1: BEGIN{FS=" 
> "}/python/{for(i=1;i "lib"substr(,3)"*";}
> awk: cmd. line:1:
>
>  ^ syntax error
> awk: cmd. line:1: BEGIN{FS=" 
> "}/python/{for(i=1;i "lib"substr(,3)"*";}
> awk: cmd. line:1:
>
>
>  ^ 1 is invalid as number of arguments for match
> close failed in file object destructor:

It looks like a quoting issue as `$i` has gone. The addition of the
shell at the start of the command must be the issue.

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

Re: Build failure on windows

[Chris Johns]

On 16/1/21 2:10 am, ND wrote:
> Trying to compile RBS for riscv on windows using MSYS2 fails with following 
> error.
> 
> error: shell macro failed: sh -c "/usr/bin/python3-config --ldflags --embed |
> awk 'BEGIN{FS=\" \"}

What does the command ...

 /usr/bin/python3-config --ldflags --embed

show you in an MSYS2 shell?

> Compiling master branch.
> Any ideas, what might be wrong?

The output of the command may help.

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

Re: libbsd: "swi6: Giant task queue" suspend if removing SD Card

[Chris Johns]

On 8/1/21 1:10 am, Christian Mauderer wrote:
> Hello RUI Zhengxin,
> 
> On 07/01/2021 04:43, RUI Zhengxin wrote:
>> Hi all,
>> We find "swi6: Giant task queue" suspend if removing SD Card.
>> libbsd5.1 is running at beagle bone hardware, the sdhci driver is attached
>> success.
>> *sdhci_ti0:  mem 0x4809c000-0x4809c3ff irq 78,4 on
>> simplebus0*
>> *mmc0:  on sdhci_ti0*
>> The console show the message when removing sd card
>> *emerg: mmcsd_detach: FIXME*
> 
> Like the message suggests: Removing SD cards is currently not implemented. The
> part of the subsystem is just removed and replaced by a BSD_PANIC("FIXME"). 
> It's
> a bit back since I last touched that subsystem but if I remember correctly, it
> would be quite a bit of work to add that support.

I have added VFS support to libbsd but I have not looked at this specific set of
interfaces. I have left them alone for now. Once my changes are merged and
stable it would be interesting to see if the devfs and related pieces can be
reverted back to something closer to the original FreeBSD sources and if it
helps in this case.

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

Re: Advice on JTAG debugging RTEMS for ARM (beaglebone)

[Chris Johns]

On 29/12/20 3:24 pm, James Fitzsimons wrote:
> Hi Chris,
> 
> Thanks very much for your reply and advice.
> 
> On Tue, 29 Dec 2020 at 11:58, Chris Johns  <mailto:chr...@rtems.org>> wrote:
> 
> > I'm using TI Code Composer Studio to load the RTEMS application image 
> via
> XDS100
> > V3.0 debugger. If I reset the program counter and step through the 
> startup
> code
> > I see it error on the bsp_fdt_get() call.
> 
> Is this a crash or is an error reported? We should report an error and not
> crash.
> 
> 
> Neither - the processor continues running, just not executing anything useful.
> 
> > My IDE isn't copying an fdt image to the expected location the way uboot
> would,
> > and so this makes sense. My question is how do other people get around
> this problem?
> >
> > Has anyone else used a similar setup and solved this issue?
> 
> I have not hit this issue but I saw this as a problem with the approach 
> taken of
> loading an FDT via the bootloader. It would have been nice to have a way 
> to
> integrate an FDT into the IMFS (or executable) rather than an external 
> load.
> 
> 
> Agreed - this would make it much easier to debug things. Even just having this
> as an option
> to support debugging would be useful.
>  
> 
> Another approach is to boot using uboot and have it load the FDT and RTEMS
> executable then jump to it. If you can connect via JTAG, reset the 
> processor,
> set a hardware break point on the entry point to RTEMS, and start the 
> processor
> running from reset it should trigger when uboot jumps to RTEMS. The entry 
> point
> is at a fixed address. When the breakpoint is hit delete it and then you 
> can set
> further break points in your application.
> 
> 
> Thanks for this suggestion - I've managed to get this working pretty much as 
> you
> described.
> I build the SD card image and boot from that, then connect via JTAG, reset and
> break on Init().
> It's a pretty clunky process, but at least I have actual on device debugging
> working now instead of
> having to rely on printf debugging.

Excellent and thanks for reporting it back to us. Yes it is clunky however
anything else would need time spent adding IMFS support or directly linked in
support and no one has done that.

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

Re: Advice on JTAG debugging RTEMS for ARM (beaglebone)

[Chris Johns]

On 29/12/20 9:27 am, James Fitzsimons wrote:
> Hi all,
> 
> I am trying to debug an RTEMS application on a TI AM3358 ARM processor
> (Beaglebone Black) and the RTEMS startup code is halting on the bsp_fdt_get 
> call.
> 
> I'm using TI Code Composer Studio to load the RTEMS application image via 
> XDS100
> V3.0 debugger. If I reset the program counter and step through the startup 
> code
> I see it error on the bsp_fdt_get() call.

Is this a crash or is an error reported? We should report an error and not 
crash.

> My IDE isn't copying an fdt image to the expected location the way uboot 
> would,
> and so this makes sense. My question is how do other people get around this 
> problem?
> 
> Has anyone else used a similar setup and solved this issue?

I have not hit this issue but I saw this as a problem with the approach taken of
loading an FDT via the bootloader. It would have been nice to have a way to
integrate an FDT into the IMFS (or executable) rather than an external load.

> Many thanks for any advice you can provide.

The only approaches I can think of are a bit hack'ish but they might work.

Can you set up an environment to load and run uboot from an SD card? Have uboot
load the FDT then stop at it's command line. Once at the command line connect
via JTAG and load the application. I suspect you will need to set the registers
to the same values uboot uses when entering the application. I seem to remember
one of them points to the FDT blob.

Another approach is to boot using uboot and have it load the FDT and RTEMS
executable then jump to it. If you can connect via JTAG, reset the processor,
set a hardware break point on the entry point to RTEMS, and start the processor
running from reset it should trigger when uboot jumps to RTEMS. The entry point
is at a fixed address. When the breakpoint is hit delete it and then you can set
further break points in your application.

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

Re: RTEMS 5.1 JFFS2 Issues

[Chris Johns]

On 8/12/20 7:32 am, richard.glos...@l3harris.com wrote:
> Hi we are using the LEON3.  Had been operating under rcc-1.3-rc7-gcc with
> correct operation of the JFFS2 file system.  Recently attempted upgrade to
> rcc-1.3.0-gcc (RTEMS 5.1 release) and now are getting segmentation fault
> whenever we attempt to access the /mnt/jffs drive in any way.  I have 
> determined
> that the exception is occurring whenever /mnt/jffs2 is accessed.  It occurs 
> down
> in RTEMS mutex code in an inline function contained in threadimpl.h.  It 
> occurs
> in an inline function called _Thread_Wait_claim which in turn calls
> _/Thread/_Wait_release_default_critical which leads to a segmentation fault. 
> This is a definite variation going from rcc-1.3-rc7-gcc to rcc-1.3.0-gcc.
> 
> Has anyone seen this?  Thoughts/ideas on how to troubleshoot?
> 

I run JFFS2 from RTEMS 5.1 on a Zynq and do not see the issues you do.

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

Re: Python problems on OS X

[Chris Johns]

On 18/11/20 7:58 am, Joel Sherrill wrote:
> On Tue, Nov 17, 2020 at 2:01 PM Gedare Bloom  > wrote:
> 
> On Tue, Nov 17, 2020 at 3:19 AM Andrew Butterfield
> mailto:andrew.butterfi...@scss.tcd.ie>> 
> wrote:
> >
> > I keep getting a python error when trying to build the tool suite on
> > OS X. The end of the error log is:
> >
> > ```
> > checking whether to use python...
> /Library/Frameworks/Python.framework/Versions/2.7/bin/python2
> > checking for python... no
> > configure: error: no usable python found at
> /Library/Frameworks/Python.framework/Versions/2.7/bin/python2
> > make[1]: *** [configure-gdb] Error 1
> > make: *** [all] Error 2
> > shell cmd failed: /bin/sh -ex 
> 
> /Users/butrfeld/REPOS/esa-qual/modules/rsb/rtems/build/sparc-rtems6-gdb-0295dde-x86_64-apple-darwin19.6.0-1/do-build
> > error: building sparc-rtems6-gdb-0295dde-x86_64-apple-darwin19.6.0-14
> 
> This is a candidate for the worst error message ever. 

BSOD ?

> It isn't looking for the
> Python interpreter executable, it is looking for Python development libraries 
> and headers.  There is a lot of code above this point but the final 
> check/error 
> is in gdb/configure.ac . If the build tree is still 
> around,
> look at gdb/config.log
> for details on what it really tried.
> 
> On CentOS, the package is named something like python-devel. My recollection
> is that it needs to be Python2 but that may be outdated based on the gdb 
> version.

Correct. Recent gdb versions support python2 and python3 and we look for both.

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

Re: Python problems on OS X

[Chris Johns]

On 17/11/20 9:19 pm, Andrew Butterfield wrote:
> I keep getting a python error when trying to build the tool suite on 
> OS X. The end of the error log is:
> 
> ```
> checking whether to use python... 
> /Library/Frameworks/Python.framework/Versions/2.7/bin/python2

That looks like RSB has provided a suitable path.

> checking for python... no
> configure: error: no usable python found at 
> /Library/Frameworks/Python.framework/Versions/2.7/bin/python2
> make[1]: *** [configure-gdb] Error 1
> make: *** [all] Error 2
> shell cmd failed: /bin/sh -ex  
> /Users/butrfeld/REPOS/esa-qual/modules/rsb/rtems/build/sparc-rtems6-gdb-0295dde-x86_64-apple-darwin19.6.0-1/do-build
> error: building sparc-rtems6-gdb-0295dde-x86_64-apple-darwin19.6.0-1
> 
> ```

What is the gdb configure command line the RSB uses?

> What are the criteria for python to be "useable"?

Does the following help?

https://git.rtems.org/rtems-source-builder/tree/source-builder/config/gdb-common-1.cfg#n7

On MacOS (darwin) I gave up on the library checks and assume if the header is
present the Python install is OK.

After the build fails there should be a config.log file under `build` ...

 find build -name config.log

Does it provide any insight into why the configure failed?

> I have removed all traces of non-native (brew) pythons that I can find.

OK.

> I followed the virtual environment instructions in the rtems-central README.md

I do not use rtems-central or follow it in detail.

> :- which python
> /Library/Frameworks/Python.framework/Versions/2.7/bin/python2
> 
> :- which python3
> /Library/Frameworks/Python.framework/Versions/3.8/bin/python3

That looks fine. Did you install python3?

> My machine is running macOS Catalina 10.15.7

Catalina should be fine. I installed Big Sur yesterday and was going to test it
today. I suspect it will only have python3 support.

Unrelated, does Catalina support APFS?

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

Re: Compilation error in compiling RISC-V bsps

[Chris Johns]

On 13/11/20 5:20 pm, somesh deshmukh wrote:
> Thanks for all the comments/suggestions.

No problem.

> This issue exists with the released version 5.1 however when I tried with the
> master branch source code, I did not faced this issue.

Oh that is interesting and thank you for checking master and reporting back. I
wonder what has changed to fix this  hmm

Could you please try the master version of `rtems-ld` with a 5.1 build of the
BSP with tests?

You should be able to copy the master version to your 5.1 tool set.

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

Re: Compilation error in compiling RISC-V bsps

[Chris Johns]

On 13/11/20 10:55 am, Joel Sherrill wrote:
> On Thu, Nov 12, 2020 at 4:16 PM Chris Johns  <mailto:chr...@rtems.org>> wrote:
> On 13/11/20 3:00 am, Joel Sherrill wrote:
> > The tests that start with dl are dynamic loader tests. They require
> architecture
> > specific support which sometimes breaks. That's why there is a ticket 
> until it
> > gets addressed by someone. Things get fixed as either volunteers step 
> up or
> > someone gets funded to fix them.
> >
> > You should be to do "make -k" to ignore this error and continue or, more
> > cleanly, add a ".tcfg" file to the BSP's config directory to specify 
> that this
> > test should be excluded. 
> bsps/riscv/riscv/config/rv64imafd-testsuite.tcfg
> which
> > should need only one line:
> >
> > expected-fail: dl06
> >
> > There are lots of other .tcfg files to look at for examples.
> 
> The expected fail state is a runtime state so the test still needs to 
> build.
> 
> So temporarily it needs to be exclude?  

I suppose it could if the ticket is updated to reflect the fact the test is
disabled and the exclude is commented with the ticket number?

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

Re: Compilation error in compiling RISC-V bsps

[Chris Johns]

On 13/11/20 3:00 am, Joel Sherrill wrote:
> The tests that start with dl are dynamic loader tests. They require 
> architecture
> specific support which sometimes breaks. That's why there is a ticket until it
> gets addressed by someone. Things get fixed as either volunteers step up or
> someone gets funded to fix them.
> 
> You should be to do "make -k" to ignore this error and continue or, more
> cleanly, add a ".tcfg" file to the BSP's config directory to specify that this
> test should be excluded. bsps/riscv/riscv/config/rv64imafd-testsuite.tcfg 
> which
> should need only one line:
> 
> expected-fail: dl06
> 
> There are lots of other .tcfg files to look at for examples.
> 

The expected fail state is a runtime state so the test still needs to build.

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

Re: RTEMS 5.1 Release LibBSD Networking Issue - FIXED

[Chris Johns]

On 11/11/20 1:37 am, Rick VanderWal wrote:
> Lesson: Don't just randomly select an odd number for the first octet of your 
> MAC
> address for testing.

Setting the group address bit in the OUI will cause you issues. If your OUI is
locally generated for testing I suggest you set the locally administered address
bit in the first octet of the OUI.

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

Re: RTEMS 5.1 Release LibBSD Networking Issue

[Chris Johns]

On 6/11/20 2:19 am, rvanderwal wrote:
> Good Morning,
> 
> I seem to be having an issue with RTEMS 5.1 Release Libbsd networking when I
> include my own 'rtems_bsd_get_mac_address' function as described in
> rtemsbsd/include/rtems/bsd/bsd.h. I'm running on a Xilinx Microzed using
> xilinx_zynq_zedboard BSP and have a minimal RTEMS console application (source
> code included below). The rc.conf file configures the cgem0 interface and 
> starts
> FTP and telnet daemons.
> 
> If I include the 'rtems_bsd_get_mac_address' function, the mac address is set
> but RTEMS doesn't respond to any pings and doesn't allow any connections.
> However, a ping to an external device from RTEMS is successful. I have run
> tcpdump filtering on ICMP messages and RTEMS sees them.
> 
> If I comment out the 'rtems_bsd_get_mac_address' function, it has the default
> mac address and everything works as expected.
> 
> All guidance and help are greatly appreciated.

I have commented in the code fragments below.

> Thanks,
> Rick
> 
> 
> //
> // RTEMS_Main.c
> //
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> #include 
> #include 
> 
> #include 
> 
> void rtems_bsd_get_mac_address(const char* name, int unit, uint8_t 
> mac_addr[6])
> {
>     mac_addr[0] = 0x0f;
>     mac_addr[1] = 0xc0;
>     mac_addr[2] = 0xcb;
>     mac_addr[3] = 0x6f;
>     mac_addr[4] = 0xcb;
>     mac_addr[5] = 0x22;
> }

Interesting, I did not know this existed. I prefer following the same process
FreeBSD provides and uses. See below.

> static void start_console(void)
> {
>     rtems_status_code sc = rtems_shell_init(
>         "SHLL",
>         32 * 1024,
>         1,
>         CONSOLE_DEVICE_NAME,
>         true,
>         true,
>         NULL
>     );
>     assert(sc == RTEMS_SUCCESSFUL);
> }
> 
> static void network_init(void)
> {
>     printf("BSD\n");
>     rtems_status_code sc = rtems_bsd_initialize();
>     assert(sc == RTEMS_SUCCESSFUL);
> 
>     sc = rtems_task_wake_after( 1000 );
>     assert(sc == RTEMS_SUCCESSFUL);
>     
>     printf("Config\n");
>     // configure bsd networking by specifying configuration file, wait 
> forever,
> verbose = true
>     rtems_bsd_run_rc_conf("/media/mmcsd-0-0/rc.conf", 0, true);

I suggest specifying the MAC address for the interface in rc.conf. For a Zync I
have something like:

ifconfig_cgem0="DHCP rxcsum txcsum"
ifconfig_cgem0_alias0="ether 0f:c0:cb:6f:cb:22"

I generate the rc.conf file writing it to /etc/rc.conf. This lets me read a MAC
address from what ever piece of hardware has been placed on the board.

Chris

> }
> 
> void *main_thread(void *arg)
> {
>   printf("Media Server\n");
>   rtems_media_server_initialize(
>         25,
>         32 * 1024,
>         RTEMS_PREEMPT | RTEMS_NO_TIMESLICE | RTEMS_ASR | 
> RTEMS_INTERRUPT_LEVEL(0),
>         RTEMS_NO_FLOATING_POINT | RTEMS_LOCAL );
>     
>   rtems_status_code sc = rtems_task_wake_after( 1000 );
>   assert(sc == RTEMS_SUCCESSFUL);
> 
>   network_init();
>   
>   sc = rtems_task_wake_after( 1000 );
>   assert(sc == RTEMS_SUCCESSFUL);
>   
>   start_console();
> 
>   assert(0);
> }
> 
> /*
>  * Configure LibBSD.
>  */
> #define RTEMS_BSD_CONFIG_NET_PF_UNIX
> #define RTEMS_BSD_CONFIG_NET_IF_BRIDGE
> #define RTEMS_BSD_CONFIG_NET_IF_LAGG
> #define RTEMS_BSD_CONFIG_NET_IF_VLAN
> #define LIBBSP_ARM_XILINX_ZYNQ_BSP_H
> #define RTEMS_BSD_CONFIG_BSP_CONFIG
> #define RTEMS_BSD_CONFIG_SERVICE_TELNETD
> #define RTEMS_BSD_CONFIG_SERVICE_FTPD
> #define RTEMS_BSD_CONFIG_INIT
> 
> #include 
> 
> /*
>  * Configure Shell
>  */
> #define CONFIGURE_SHELL_COMMANDS_INIT
> 
> #include 
> 
> #include 
> 
> #ifdef RTEMS_BSD_MODULE_USER_SPACE_WLANSTATS
>   #define SHELL_WLANSTATS_COMMAND _shell_WLANSTATS_Command,
> #else
>   #define SHELL_WLANSTATS_COMMAND
> #endif
> 
> #ifdef RTEMS_BSD_MODULE_USR_SBIN_WPA_SUPPLICANT
>   #define SHELL_WPA_SUPPLICANT_COMMAND _shell_WPA_SUPPLICANT_Command,
> #else
>   #define SHELL_WPA_SUPPLICANT_COMMAND
> #endif
> 
> #define CONFIGURE_SHELL_USER_COMMANDS \
>   SHELL_WLANSTATS_COMMAND \
>   SHELL_WPA_SUPPLICANT_COMMAND \
>   _interrupt_shell_command, \
>   _shell_ARP_Command, \
>   _shell_HOSTNAME_Command, \
>   _shell_PING_Command, \
>   _shell_ROUTE_Command, \
>   _shell_NETSTAT_Command, \
>   _shell_IFCONFIG_Command, \
>   _shell_TCPDUMP_Command, \
>   _shell_SYSCTL_Command, \
>   _shell_VMSTAT_Command
> 
> #define CONFIGURE_SHELL_COMMANDS_ALL
> 
> #include 
> 
> /*
>  * Configure RTEMS.
>  */
> #define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
> #define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
> 
> #define CONFIGURE_APPLICATION_NEEDS_LIBBLOCK
> 
> #define CONFIGURE_FILESYSTEM_DEVFS
> #define CONFIGURE_FILESYSTEM_DOSFS
> #define CONFIGURE_MAXIMUM_FILE_DESCRIPTORS 32
> 
> #define CONFIGURE_MAXIMUM_USER_EXTENSIONS 1
> 
> #define CONFIGURE_UNLIMITED_ALLOCATION_SIZE 32
> #define CONFIGURE_UNLIMITED_OBJECTS
> #define CONFIGURE_UNIFIED_WORK_AREAS
> 

Re: RTEMS 5.1 documentation in docs.rtems.org

[Chris Johns]

On 29/10/20 12:54 am, Christian Mauderer wrote:
> Hello Jan,
> 
> On 28/10/2020 07:51, jan.som...@dlr.de wrote:
>> Hello,
>>
>> If colleagues have RTEMS related questions, I like to direct them to 
>> docs.rtems.org to read the fine manual.
>> I noticed that in the releases section of the page 5.1 is not yet included.
> 
> You are right that there seem to be some missing links on the "All
> Releases" section and for the 5 branch.

I do apologise, I have not been able to get to this item because it is a thread
that once pulled drags me into a range of things I need to sort out and from
experience I can quickly sink a lot of time into it.

I am concerned adding the 5.1 docs and doxygen as the other releases are
currently being handled will fill the server's disk [1]. To avoid this I have
reworked the way the releases are handled to avoid filling the disk. Filling
this disk effects other critical things we have running such as git.

> To be honest: I have no idea where that would have to fixed.

I login into the service level of the machines behind the jail and then into the
docs.rtems.org jail. The access to the service machine is restricted.

Once into the jail I need to teach apache to follow the mount point to the
TrueNAS or I add HTML redirects as the click links. I am not sure which is the
better approach. Both have benefits and side effects.

I then need to update ..

https://git.rtems.org/chrisj/rtems-admin.git/tree/docs

... to manage the new location.

I then need to consider if the other releases are moved to the TrueNAS as well
and clearing that space on the disk that holds them.

>> Since with the work on RTEMS 6 the active branch documentation is diverging, 
>> could you please also add the 5.1 documentation there?
> 
> If you need something urgently: If you click on the "Latest Release
> Manuals" on the rtems.org start page, you reach the documentation for
> 5.1 that is saved on ftp.rtems.org:
> 
>   https://ftp.rtems.org/pub/rtems/releases/5/5.1/docs/html/

Thank you for providing the link. This is my solution I referred to above. I
have placed the documentation in the FTP release area that maps to the TrueNAS
storage which we have plenty of. There is a link (subtle to find) in the release
HTML page at:

https://ftp.rtems.org/pub/rtems/releases/5/5.1/#rtems-documentation

Another benefit of having the documentation here is a clone of the release tree
provides you with all the parts.

I hope this helps.

Chris

[1] https://devel.rtems.org/ticket/3138
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: rtems-syms for dynamic load

[Chris Johns]

On 22/10/20 11:17 pm, Rotem Dror wrote:
> 
> I'm trying to implement the example found in the user manual of RTEMS (see
> */9.7.3.3. Loadable Symbols/* on:
> https://docs.rtems.org/branches/master/user/exe/loader.html). 
> 
> From this example, it seems that it is necessary to use *_rtems-syms
> _*application. This app is existing on the RCC version. But when I try to run 
> it
> I get an error message: "cannot execute binary file" (on msys2 terminal).

RCC version? Did you build the tools or is this from a supplier?

Chris

> I also tried to execute this app on CMD of windows and got a message that this
> file is not recognized as a command. And when I change the suffix to .exe I 
> got
> an error that this file is 16 bit (??)/

The rtems-tools does build on Windows and the commands should work.

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

Re: Which documentation is relevant for testing?

[Chris Johns]

On 9/9/20 11:40 pm, Frank Kühndel wrote:
> I want to acquaint myself with testing in RTEMS. I found two sources of
> documentation on this topic:
> 
>   * the RTEMS User Manual Chapter "9. Testing"
>     https://docs.rtems.org/branches/master/user/testing/index.html

This is the relevant documentation.

>   * and the file rtems-tools/doc/rtems-tester.txt
>     https://git.rtems.org/rtems-tools/tree/doc/rtems-tester.txt

This can be removed. It existed before we had a user manual.

> Please, could you point out which of these two is authoritative?

The User manual is the one.

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

Re: Is -malign-int a usual m68k/ColdFire option?

[Chris Johns]

On 2/10/20 6:34 pm, Sebastian Huber wrote:
> Hello,
> 
> a test suite failure surfaced that we may have an issue with the alignment of
> basic data structures on ColdFire targets:
> 
> https://devel.rtems.org/ticket/4013
> 
> The chips usually have at least a 32-bit data system bus.

These days this is true however some architectures reach back to a time when a
16 bit bus was considered new. The m68K is one and the widely used 68302, 68320
etc all had 16bit buses for many years.

> I am not sure why
> RTEMS didn't use the -malign-int for the ColdFire targets before. Has anyone
> experience using this option?

The RSB set builder option `--targetcflags flags` was added to the RSB before it
became the RSB to control a tools build for this specific option. Alan asked for
a way to align ints on the MMS (runs a RAD hardened Coldfire) to test the
performance so I added this option. He would need to comment on the effect it 
had.

The RSB can support adding target specific options in a config with:

%define _targetcflags -g _O2 -malign-int
%define _targetcxxflags -g -O2 -malign-int

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

Re: rtems_bsd_initialize() in POSIX_Init and qemu-system-i386

[Chris Johns]

On 2/10/20 6:13 pm, Heinz Junkes wrote:
> Yes, seems to be a problem with the e1000.
> with "model=rtl8139” it works perfectly.

Could you please raise a ticket? It would be interesting to know if this happens
on real hardware.

> qemu-system-i386 -m 64 -no-reboot -serial stdio -display none -net 
> nic,model=rtl8139,macaddr=0e:b0:ba:5e:ba:11 -net user,restrict=yes -append 
> "--video=off --console=/dev/com1" -kernel libComTestHarness 

qemu-system-i386 -m 512M -no-reboot -serial mon:stdio -nographic -net
nic,model=rtl8139 -net vde,id=vde0,sock=/tmp/vde1 -kernel
build/i386-rtems6-pc686-default/dhcpcd01.exe  -append '--console=/dev/com1
--printk=/dev/com1'

Using VDE :)

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

Re: rtems_bsd_initialize() in POSIX_Init and qemu-system-i386

[Chris Johns]

On 2/10/20 2:48 pm, Heinz Junkes wrote:
> init01.exe does not initialize the network interface.

Yes. It splits the problem.

> I see the same delay with dhcpcd01.exe

Are you using the e1000? Try rtl8139.

I do not see these delays on real PC hardware or qemu with rtl8139.

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

Re: rtems_bsd_initialize() in POSIX_Init and qemu-system-i386

[Chris Johns]

On 2/10/20 5:34 am, Heinz Junkes wrote:
> I have finally managed to apply the patch. Unfortunately it didn't lead to a 
> change in the behaviour of qemu. The delay of about 45 seconds is still there.

How are you initialising libbsd?

If you run `init01.exe` from the tests how long does it take?

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

Re: rtems_bsd_initialize() in POSIX_Init and qemu-system-i386

[Chris Johns]

On 29/9/20 5:43 am, junkes wrote:
> I have a problem with rtems_bsd_initialize() in POSIX_Init() and qemu.
> 
> call of
>     sc = rtems_bsd_initialize();
>     assert(sc == RTEMS_SUCCESSFUL);
> always takes about 45 seconds until it is finished.
> 
> The output of
> 
> nexus0: 
> pcib0 pcibus 0 on motherboard
> pci0:  on pcib0
> pci0:  at device 0.0 (no driver attached)
> pci0:  at device 1.0 (no driver attached)
> pci0:  at device 1.1 (no driver attached)
> pci0:  at device 1.3 (no driver attached)
> pci0:  at device 2.0 (no driver attached)
> em0:  port 0xc000-0xc03f mem
> 0xfebc-0xfebd irq 11 at device 3.0 on pci0
> 
> comes very fast, but then the system is "frozen" for about 45 seconds.
> Then this output appears:
> 
> info: em0: Ethernet address: 0e:b0:ba:5e:ba:11
> cpu0 on motherboard

What is the network configuration?

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

Re: RTEMS BSD Version

[Chris Johns]

On 16/9/20 8:53 pm, richard.glos...@l3harris.com wrote:
> Does anyone know how to determine the version/build date of the BSD network
> stack for the version of RTEMS you have installed locally?

I could not find any think that captures this in libbsd.a or in an executable
file. I think it is something that should be added.

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

Re: How to use lvgl on pc386 BSP.

[Chris Johns]

On 9/9/20 3:45 am, jan.som...@dlr.de wrote:
> They got a bit delayed due to the work for the RTEMS5 release and because 
> there were some discussions about branch naming for FreeBSD.

Are the patches OK? Maybe a post to devel to list what is needed and I can take
a look. I have lost track of what is where.

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

Re: rtems-tftp server not working with iPXE.

[Chris Johns]

On 7/9/20 4:06 pm, Karel Gardas wrote:
> On 9/7/20 2:34 AM, Chris Johns wrote:
>> On 7/9/20 8:29 am, Chris Johns wrote:
>>>
>>> Hmm looks like the socket returns a string in Python 2 and bytes in Python 
>>> 3. I
>>> will need to play around to find a suitable solution for this.
>>>
>>
>> Fixed on master. Please test and let me know how you go.
> 
> Thanks, but no go here on Ubuntu 18.04 LTS. Perhaps I don't know usage
> well, but I:
> 
> - dhcp
> - boot tftp:///smp01.exe
> 
> on iPXE hardware side.
> 
> But tftp server throws FileNotFoundError on me as if the file smp01.exe
> was not presented in base. But it's there look:

Try the -F option to force the file. This causes the TFTP server to ignore the
requested file name and to send the file you specify on the command line. The
idea is the DHCP (BOOTP) server does not need to be touched to change the file
you select to load using TFTP. This is how the `rtems-test` command internally
handles downloading the different tests.

But ...

> sudo ~/git/rtems/rtems-tools/tester/rtems-tftp-server -v -b
> ~/sfw/rtems/5.1-smp2-vga80x50-key-to-reset/i386-rtems5/pc686/tests/
> RTEMS Tools - TFTP Server, undefined (b1c6a98da4a2)
>  Command Line:
> /export/home/karel/git/rtems/rtems-tools/tester/rtems-tftp-server -v -b
> /export/home/karel/sfw/rtems/5.1-smp2-vga80x50-key-to-reset/i386-rtems5/pc686/tests/
>  Host: Linux silence 5.4.0-42-generic #46~18.04.1-Ubuntu SMP Fri Jul 10
> 07:21:24 UTC 2020 x86_64
>  Python: 2.7.17 (default, Jul 20 2020, 15:37:01) [GCC 7.5.0]
> ] tftp: server: all:69
> ] tftp: 1: start: 10.0.30.128:2057
> ] tftp: 1: error: : global name
> 'FileNotFoundError' is not defined
> ] tftp: 1: end: 10.0.30.128:2057
> ] tftp: 2: start: 10.0.30.128:2057
> ] tftp: 2: error: : global name
> 'FileNotFoundError' is not defined
> ] tftp: 2: end: 10.0.30.128:2057
> ] tftp: 3: start: 10.0.30.128:2057
> ] tftp: 3: error: : global name
> 'FileNotFoundError' is not defined
> ] tftp: 3: end: 10.0.30.128:2057
> ] tftp: 4: start: 10.0.30.128:2057
> ] tftp: 4: error: : global name
> 'FileNotFoundError' is not defined
> ] tftp: 4: end: 10.0.30.128:2057
> ] tftp: 5: start: 10.0.30.128:2057
> ] tftp: 5: error: : global name
> 'FileNotFoundError' is not defined
> ] tftp: 5: end: 10.0.30.128:2057
> ] tftp: 6: start: 10.0.30.128:2057
> ] tftp: 6: error: : global name
> 'FileNotFoundError' is not defined
> ] tftp: 6: end: 10.0.30.128:2057
> ^Cabort: user terminated
> 
> 
> $ ls -la
> /export/home/karel/sfw/rtems/5.1-smp2-vga80x50-key-to-reset/i386-rtems5/pc686/tests/smp01.exe
> -rwxr-xr-x 1 karel karel 4797752 Sep  7 00:02
> /export/home/karel/sfw/rtems/5.1-smp2-vga80x50-key-to-reset/i386-rtems5/pc686/tests/smp01.exe
> 
> 
> so it looks like there is some issue with file handling on tftp server
> or have I done anything wrong?

... it looks like there is an issue so please run with `--show-backtrace` so I
can see where the "global name" issue is.


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

Re: Using model checking to do test generation for RTEMS

[Chris Johns]

On 4/9/20 7:35 pm, Andrew Butterfield wrote:
> Dear Chris,
> 
>  thanks for your feedback - much appreciated!
> 
> Responses to your queries inline below.
> 
>> On 3 Sep 2020, at 00:38, Chris Johns > <mailto:chr...@rtems.org>> wrote:
>>
>> On 1/9/20 2:30 am, Andrew Butterfield wrote:
>>> Dear all,
>>>
>>> I am involved the in the ESA sponsored project RTEMS-SMP, to add
>>> tools and data for software qualification. Our focus is on the use
>>> of formal techniques to assist in software verification.
>>
>> Excellent :)
>>
>>> We have a developed a prototype for an approach that uses the SPIN
>>> model-checker (spinroot.com <http://spinroot.com>) to produce formal models
>>> of RTEMS API
>>> behaviour, from which API tests can be generated. The formal models
>>> form one way of specifying the desired behaviour for these APIs.
>>
>> Spin looks nice. Its maturity and wide host support looks great.
>>
>>> We have developed a prototype demonstrator of this technique and are
>>> now seeking feedback from the community. It is expected that a
>>> suitably revised and updated version of this would become part of the
>>> proposed RTEMS qualification tool-chain.
>>>
>>> The demonstrator can be found at:
>>>  https://github.com/andrewbutterfield/manual-spin2tests
>>
>> The repo looks great. The approach looks suitable for our project.
>>
>>> Feedback on all aspects of this from a range of different perspectives
>>> would be very welcome.
>>
>> Will the results of your efforts be merged into the rtems-central repo?
> 
> Yes - I believe so.

Great.

>> Is there any relationship between the spec files Sebastian is creating for 
>> the
>> APIs and your work? If not how would they be kept in sync or at a minimum how
>> would we know they do not match?
> 
> The plan is for our work to be fully integrated with what Sebastian is 
> building.
> Our spin2test tool would be part of the qualification tools, and the tests we
> produce
> would be integrated with the handwritten test suites. The test results would
> feed  into
> the tests analysis tools (coverage, etc..) and that analysis would end up as 
> part of
> the qualification datapackage.

Sounds good. I am looking forward to seeing the results.

>> How is the log from the test output used to validate the model?
> 
> The test output shows what the test did, so it can be used by someone familiar
> with the
> requirements to judge if the test expectations of correct behaviour are
> themselves correct.
> So, yes, they can help in that regard.

Just so I understand, if the model and the API do not match the test will report
a failure?

>> I would like to see this work performed on a tier-1 architecture [1]. At this
>> point in time SPARC (and LEON) is not tier-1 because there are no test 
>> results
>> from hardware posted to build @ rtems.org <http://rtems.org>. This leaves the
>> ESA pre-qual project
>> with some choices. You could select a suitable target like a beagleboneblack 
>> and
>> post hardware test results or encourage other members of the pre-qual 
>> project to
>> run the testsuite on a LEON and post the results. We could then move SPARC 
>> and
>> LEON to tier-1, something I personally would love to see.
> 
> In one sense the ESA project has no choice - we have to work with
> leon3/gr712rc/gr740.

That is fine. We understand few people often see the real hardware with flight
software development. We are relaxed on how an architecture can reach tier-1, we
need only one device from a family to run the tests with the results being
published. My desire is to automatically monitor the test results and age out
older results.

> I should point out that a test generated by us has been run (standalone) on
> gr740 hardware at ESTEC.
> Would it help if the results of that was posted? 

The test output needs to be posted using the public rtems-tools.git `rtems-test`
command. For public test results to be meaningful the tools used to generate the
results need to be public.

> My understanding is that as our project rolls out we will be running hardware 
> tests.

This is understandable and what I would expect. The role of tiers in RTEMS is to
bring the results out into the public so all users can view where each
architecture and device family sits. I personally see value for hardware vendors
having devices in tier-1 and I see value for large organisation like ESA
expecting to see their selected hardware in tier-1. You and I will not make this
happen.

> However, the way I built the test executables was using waf configured for the
> above three BSPs, and so it should be possible to do it for another tier-1 
> architecture.

If the tests end up in the testsuite the tests will be required to pass on all
supported architectures. We consider the range of architecture we support a real
feature because the code needs to be clean.

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

Re: rtems-tftp server not working with iPXE.

[Chris Johns]

On 7/9/20 8:29 am, Chris Johns wrote:
> 
> Hmm looks like the socket returns a string in Python 2 and bytes in Python 3. 
> I
> will need to play around to find a suitable solution for this.
> 

Fixed on master. Please test and let me know how you go.

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