Re: “AW:” ?

[Joel Sherrill]

On Wed, Jan 31, 2024 at 11:20 AM John Howard  wrote:

> Lost in translation.
>
> Anybody here know what “AW:” in the Subject means?
>

Should be German version of "RE: "

>
> At first, I took it to mean a comical expression of sarcasm because of an
> accident.
>
> Ironically, that’s not it.
>
> -- John
> ___
> 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: riscv target spec for newlib and rtems

[Joel Sherrill]

On Sat, Dec 30, 2023, 9:45 AM Matt Wette  wrote:

> The build from git master worked (but first try I ran out of disk space:
> needs > 10 G for the build.
>

That's good news that it built.

We need to check the Users Guide to see if it has disk space
recommendations. Did you see any?

Personally, I always try to leave at least 20GB free in my working VMs. I
think my current Rocky 9 VM started with 120GB for the OS, etc.

--joel



> Matt
>
> On 12/27/23 4:06 PM, Joel Sherrill wrote:
>
> Sounds like you are trying to do this by hand. The RTEMS Source Builder
> (RSB) is the recommended way to build tools. See
> https://docs.rtems.org/branches/master/user/index.html for detailed
> instructions on the required packages on your host and how to use the RSB.
>
> The RSB fetches, patches, and builds the recommended tool versions.
>
> Not that you need it with the RSB building everything for you but the
> target should be riscv-rtems6.
>
> On Wed, Dec 27, 2023, 5:43 PM Matt Wette  wrote:
>
>> Hi All,
>>
>> I'm working on compiling binutils, gcc, newlib and rtems-5.3 for
>> RISC-V.   What is appropriate target-spec?
>> I've searched for specification hints but can't anything. Currently, I'm
>> using riscv-rtems-elf but it seems
>> newlib and rtems want to see a target spec with four fields and rtems is
>> #3 or #4 in the list.
>> Any references for this?
>>
>> for reference, using binutils-2.38, gcc-12.3.0 and newlib-4.3.0.20230120
>> I've gotten binutils, gcc and newlib to build (with patch to deal with
>> above config issue on newlib).
>>
>> Matt
>>
>>
>> ___
>> 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: riscv target spec for newlib and rtems

[Joel Sherrill]

Sounds like you are trying to do this by hand. The RTEMS Source Builder
(RSB) is the recommended way to build tools. See
https://docs.rtems.org/branches/master/user/index.html for detailed
instructions on the required packages on your host and how to use the RSB.

The RSB fetches, patches, and builds the recommended tool versions.

Not that you need it with the RSB building everything for you but the
target should be riscv-rtems6.

On Wed, Dec 27, 2023, 5:43 PM Matt Wette  wrote:

> Hi All,
>
> I'm working on compiling binutils, gcc, newlib and rtems-5.3 for
> RISC-V.   What is appropriate target-spec?
> I've searched for specification hints but can't anything. Currently, I'm
> using riscv-rtems-elf but it seems
> newlib and rtems want to see a target spec with four fields and rtems is
> #3 or #4 in the list.
> Any references for this?
>
> for reference, using binutils-2.38, gcc-12.3.0 and newlib-4.3.0.20230120
> I've gotten binutils, gcc and newlib to build (with patch to deal with
> above config issue on newlib).
>
> Matt
>
>
> ___
> 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: Rust on RTEMS

[Joel Sherrill]

On Fri, Dec 22, 2023 at 7:40 AM Frank Kühndel <
frank.kuehn...@embedded-brains.de> wrote:

> Hello Joel,
>
> On 12/20/23 23:37, Joel Sherrill wrote:
> > Karel Gardas posted in February that he has Rust on RTEMS on an arm.
>
> This is one email from that thread:
> https://lists.rtems.org/pipermail/devel/2023-March/074532.html
> >
> > Frank. Are there instructions on building the tools chain somewhere?
>
> I attach a file with instructions which I just compiled from my notices
> (my Christmas gift to you ;-) ). I have not tested these instructions
> (again) but I hope they will give you a hint how it did it. I attach
> them as file to avoid my mail program inserts line breaks.
>
> In case you or anyone else gives these instructions a try, I will be
> happy for all feedback. The documentation I want to write for the User
> Manual (if no one else does it before me or has a better approach) would
> closely follow the steps in the attached file.
>

Thanks!


> >
> > And is Jan Sommer part of the DLR Rust on RTEMS project?
>
> I met Jan at ESA ADCSS 2023 at Nordwijk. I prefer Jan answers your
> question as I do not want to make anything public without prior
> agreement from DLR.
>

It's not a huge secret. :)

https://activities.esa.int/4000140242 shows an ~EU175 project was awarded
to DLR.   From there, Jan Sommer is the only person at DLR who has mentioned
this.

I understand wanting someone at DLR to make a statement but the activity
is clear.  I assume many of our projects for NASA are just as easily tracked
down if someone knew where to look. Personally, I do not know where to look
for that.

Merry Christmas!

>
> Greetings,
> fk
>
> >
> > --joel
> >
> > On Wed, Dec 20, 2023, 3:59 PM Frank Kühndel <
> > frank.kuehn...@embedded-brains.de> wrote:
> >
> >> Hello Dwaine,
> >>
> >> On 12/20/23 20:41, Molock, Dwaine S. (GSFC-5820) wrote:
> >>   > Hello,
> >>   >
> >>   > Has anyone been able to execute Rust on RTEMS?
> >>
> >> Yes – to use RTEMS from within a Rust application, with
> >>
> >> #![no_std]
> >> #![no_main]
> >>
> >>   >
> >>   > If so, is there a how to guide and what architecture and development
> >> hardware was used?
> >>
> >> I have not yet found time to write a documentation despite I want to do
> >> so. Sorry for this. Ferrous Systems first extended Rust to run on
> >> Gaisler SPARC bare metal and then they figured it works with RTEMS 5
> >> from Gaisler, too. Their documentation is here:
> >> https://github.com/ferrous-systems/sparc-experiments/
> >>
> >> I did run my examples only on simulators. I tried two architectures with
> >> RTEMS 6: Leon3 and RISC-V.
> >>
> >> Greetings,
> >> Frank
> >>
> >> --
> >> embedded brains GmbH & Co. KG
> >> Herr Frank KÜHNDEL
> >> Dornierstr. 4
> >> 82178 Puchheim
> >> Germany
> >> email:frank.kuehn...@embedded-brains.de
> >> phone:  +49-89-18 94 741 - 23
> >> mobile: +49-176-15 22 06 - 11
> >>
> >> Registergericht: Amtsgericht München
> >> Registernummer: HRA 117265
> >> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> >> Unsere Datenschutzerklärung finden Sie hier:
> >> https://embedded-brains.de/datenschutzerklaerung/
> >> ___
> >> users mailing list
> >> users@rtems.org
> >> http://lists.rtems.org/mailman/listinfo/users
> >
>
> --
> embedded brains GmbH & Co. KG
> Herr Frank KÜHNDEL
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: frank.kuehn...@embedded-brains.de
> phone:  +49-89-18 94 741 - 23
> mobile: +49-176-15 22 06 - 11
>
> Registergericht: Amtsgericht München
> Registernummer: HRA 117265
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Rust on RTEMS

[Joel Sherrill]

Karel Gardas posted in February that he has Rust on RTEMS on an arm.

Frank. Are there instructions on building the tools chain somewhere?

And is Jan Sommer part of the DLR Rust on RTEMS project?

--joel

On Wed, Dec 20, 2023, 3:59 PM Frank Kühndel <
frank.kuehn...@embedded-brains.de> wrote:

> Hello Dwaine,
>
> On 12/20/23 20:41, Molock, Dwaine S. (GSFC-5820) wrote:
>  > Hello,
>  >
>  > Has anyone been able to execute Rust on RTEMS?
>
> Yes – to use RTEMS from within a Rust application, with
>
> #![no_std]
> #![no_main]
>
>  >
>  > If so, is there a how to guide and what architecture and development
> hardware was used?
>
> I have not yet found time to write a documentation despite I want to do
> so. Sorry for this. Ferrous Systems first extended Rust to run on
> Gaisler SPARC bare metal and then they figured it works with RTEMS 5
> from Gaisler, too. Their documentation is here:
> https://github.com/ferrous-systems/sparc-experiments/
>
> I did run my examples only on simulators. I tried two architectures with
> RTEMS 6: Leon3 and RISC-V.
>
> Greetings,
> Frank
>
> --
> embedded brains GmbH & Co. KG
> Herr Frank KÜHNDEL
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: frank.kuehn...@embedded-brains.de
> phone:  +49-89-18 94 741 - 23
> mobile: +49-176-15 22 06 - 11
>
> Registergericht: Amtsgericht München
> Registernummer: HRA 117265
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> ___
> 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: Has RTEMS ever had a CVE?

[Joel Sherrill]

On Wed, Sep 13, 2023 at 3:30 AM Schweikhardt, Jens (TSPCE6-TL5) <
jens.schweikha...@tesat.de> wrote:

> Hello,
>
>
>
> I wonder if RTEMS ever had a vulnerability for which a CVE was created
>
> (only the RTEMS OS proper, not libbsd or newlib or other components).
>
> Search engine results don’t turn up much, if anything, so I’m inclined to
> think the answer is “no”.
>
> I found Gedare’s PDF about security hardening for EPICS/RTEMS talking a
> bit about
>
> vulnerabilities, but that does not mention any true CVEs against RTEMS.
>
> Can anyone say with certainty there are no CVEs against RTEMS?
>

There was one reported for the GoAhead webserver which we used to bundle
with RTEMS.
But that CVE was filed against that package years after we removed it.
Gedare Bloom posted
information about it in October 2021.

https://lists.rtems.org/pipermail/users/2021-October/068533.html

There has never (fingers crossed) been one reported against RTEMS. I would
expect there
have been CVEs against packages used with RTEMS which we get from third
parties. But
I don't know about any of those.

I'm not conceited enough to think it could never happen. It just hasn't.

--joel



>
> Jens
>
>
>
>
>
> --
>
> Tesat-Spacecom GmbH & Co. KG
> Sitz: Backnang; Registergericht: Amtsgericht Stuttgart HRA 270977
> Persoenlich haftender Gesellschafter: Tesat-Spacecom Geschaeftsfuehrungs
> GmbH;
> Sitz: Backnang; Registergericht: Amtsgericht Stuttgart HRB 271658;
> Geschaeftsfuehrung: Thomas Reinartz, Kerstin Basche, Ralph Schmid
>
> [image: banner]
> ___
> 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: "signal()" in RTEMS unresolved

[Joel Sherrill]

On Tue, Aug 22, 2023 at 5:17 PM Brett Sterling 
wrote:

> Thanks for the fast response.
>
> I'm pretty sure that if POSIX is an *optional* item, I did *not* build
> with it (I'm *very* new to RTEMS, so I've been using what I was given
> with the "Hello World" Quick Start build).
>
> I'm glad to give that a try if you point me to some sort of documentation
> to learn how to enable POSIX.
>

I actually had to look for this myself. :)

https://docs.rtems.org/branches/master/user/bld/index.html#  describes the
build configuration.  Each BSP has a set of defaults you can print out
using waf bspdefaults

./waf bspdefaults --rtems-bsp=sparc/leon3

That prints all of the options available and their default value. Looking
through that, I see:

# Enable support for POSIX signals
RTEMS_POSIX_API = False

You create an ini file with just what you care about overriding. Something
like:

[sparc/leon3]
RTEMS_POSIX_API = True

Use this option to "waf configure" to select your INI file
"--rtems-config=CONFIG.INI". The idea is that you can configure RTEMS how
you want and keep that INI file under your project's configuration control.

On many of the BSPs for SoCs, you can change RAM/Flash size, clock speed,
and a surprising number of very hardware specific values which tweak the
base SoC board to match a custom board based on that SoC. The goal is to
give people the knobs and switches needed to avoid hacking on a BSP.

If something in the manual needs tweaking, just point it out.

--joel


> That being said, I just want to be clear - we're looking for the
> 'signal()' function rather than the POSIX 'sigaction()' function.
>
> Thanks!
> Brett
> --
> *From:* Joel Sherrill 
> *Sent:* Tuesday, August 22, 2023 4:14 PM
> *To:* Brett Sterling 
> *Cc:* users@rtems.org 
> *Subject:* Re: "signal()" in RTEMS unresolved
>
> 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.
>
>
>
> On Tue, Aug 22, 2023 at 4:46 PM Brett Sterling <
> brett.sterl...@odysseysr.com> wrote:
>
> Hello all,
>
> My code calls the 'signal()' function.  There are no errors during
> compile, but when it goes to the link stage, it gets an error:
>
> : in function `Encore::Framework::Component::Component(unsigned int,
> double)':
> Component.cpp:(.text+0x1338): undefined reference to `signal'
>
>
> Did you build with POSIX enabled? POSIX signals are part of the small
> amount of POSIX functionality that is covered by that switch.
>
>
> I've seen the documentation that indicates the Posix method is to use
> 'sigaction()', but we're looking to use the standard C/C++ library
> functionality.  Based on the error, I'm guessing that either
>
>1. I'm not linking with the correct libraries OR
>2. I need to specify some sort of switch when building the RTEMS tools
>(in order to include the 'signal()' function in the libraries).
>
> I've searched 'the web' but haven't come up with anything that indicates
> where I'm going wrong.
>
> Any pointers here would be appreciated :-)
>
> Thanks!
> Brett
> ___
> users mailing list
> users@rtems.org
> http://lists.rtems.org/mailman/listinfo/users
> <https://usg02.safelinks.protection.office365.us/?url=http%3A%2F%2Flists.rtems.org%2Fmailman%2Flistinfo%2Fusers=05%7C01%7C%7C32fd9200243347529c7408dba35d2acb%7Cd761ffacf6be45b88f6f288a59577095%7C0%7C0%7C638283392785714573%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=y8FFLSdf%2Fu6CUWEAYlmU48stE%2BeK8qJA0lHvAFKStNM%3D=0>
>
>
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: "signal()" in RTEMS unresolved

[Joel Sherrill]

On Tue, Aug 22, 2023 at 4:46 PM Brett Sterling 
wrote:

> Hello all,
>
> My code calls the 'signal()' function.  There are no errors during
> compile, but when it goes to the link stage, it gets an error:
>
> : in function `Encore::Framework::Component::Component(unsigned int,
> double)':
> Component.cpp:(.text+0x1338): undefined reference to `signal'
>

Did you build with POSIX enabled? POSIX signals are part of the small
amount of POSIX functionality that is covered by that switch.

>
> I've seen the documentation that indicates the Posix method is to use
> 'sigaction()', but we're looking to use the standard C/C++ library
> functionality.  Based on the error, I'm guessing that either
>
>1. I'm not linking with the correct libraries OR
>2. I need to specify some sort of switch when building the RTEMS tools
>(in order to include the 'signal()' function in the libraries).
>
> I've searched 'the web' but haven't come up with anything that indicates
> where I'm going wrong.
>
> Any pointers here would be appreciated :-)
>
> Thanks!
> Brett
> ___
> 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: Networking examples

[Joel Sherrill]

On Tue, Aug 15, 2023 at 11:57 AM Brett Sterling <
brett.sterl...@odysseysr.com> wrote:

> Hello all!
>
> To get this out of the way prior to all of the requested debugging
> information - I don't need the legacy stack, any networking stack will do.
> I started with legacy because that was what was shown on the RTEMS
> documentation pages.  We're trying to integrate RTEMS into our system and I
> considered adding the networking stack that had some documentation a big
> enough effort without perhaps trying to integrate another network stack.
> But I'm absolutely glad to go with any suggestion.
>
>
> Now, onto the requested build failure information.
>
> Following
> https://docs.rtems.org/branches/master/legacy-networking/quick_start.html
>
> ../source-builder/sb-set-builder --prefix=$HOME/src/rtems-net-build
> 6/rtems-net-legacy --host=sparc-rtems6 --with-rtems-bsp=sparc
> RTEMS Source Builder - Set Builder, 6 (8e568b2ca348 modified)
> warning: exe: absolute exe found in path: (__cmake) /usr/bin/cmake
> Build Set: 6/rtems-net-legacy
> config: tools/rtems-net-legacy-6.cfg
> error: config error: rtems-bsp.cfg:104: RTEMS tools not found
> (sparc-rtems6-gcc) found; Please check the --with-tools option or --prefix.
> Build FAILED
> Build Set: Time 0:00:00.012407
> Build FAILED
>
> The error information implies that '--prefix' should specify where the
> 'sparc-rtems6-gcc' should be located, so I tried something different
> (specifying where the build tools are located).
>

The prefix is where it will be installed. Normally${prefix}/bin/ will
contain your cross tools.

--rtems-tools path : Path to an install RTEMS tool set

And your --with-rtems-bsp is just the architecture. It would need to be
something like sparc/leon3.

Have you built the tools? Is sparc-rtems6-gcc in your $PATH? Can you run
hello world?

And --host normally denotes the host os where you are building. You usually
want --target.

@Vijay should be able to confirm that for sure. I don't think I have built
the legacy stack this way recently.



> prefix=$HOME/src/Toolchains/osr_rtems_6_sparc 6/rtems-net-legacy
> --host=sparc-rtems6 --with-rtems-bsp=sparc
> RTEMS Source Builder - Set Builder, 6 (8e568b2ca348 modified)
> warning: exe: absolute exe found in path: (__cmake) /usr/bin/cmake
> Build Set: 6/rtems-net-legacy
> config: tools/rtems-net-legacy-6.cfg
> error: config error: rtems-bsp.cfg:131: RTEMS BSP not found
> (sparc-rtems6-sparc.pc); Please check the --with-rtems option or --prefix.
>
>
You have to build RTEMS and install it.  The dot pc file has a pattern like
this for the powerpc/psim BSP I had installed

/home/joel/rtems-work/tools/6/bsp-install/lib/pkgconfig/powerpc-rtems6-psim.pc

prefix to RTEMS
configure/install: /home/joel/rtems-work/tools/6/bsp-install/

Note that yours would be something like sparc-rtems6-leon3.pc.


> Build FAILED
> Build Set: Time 0:00:00.014283
> Build FAILED
>
> What I'm guessing is that the networking build still relies on everything
> being in the correct location, but the documentation doesn't indicate where
> the networking repository should be put and how the networking build fits
> in with the tools build and the application builds.  This is probably the
> information I'm currently lacking.  Then again, I may be missing something
> in the documentation that I erroneously overlooked.  If so, just let me
> know.
>
> The "Hello World" failure is documented in this ticket:
> https://devel.rtems.org/ticket/4927
>

OK. I dhave added Chris who I think wrote that section.

Can you build the rtems-examples from that repository?

--joel


>
> Thanks again in advance!
> Brett
>
>
>
> --
> *From:* Joel Sherrill 
> *Sent:* Tuesday, August 15, 2023 9:57 AM
> *To:* Brett Sterling 
> *Cc:* users@rtems.org ; Vijay Kumar Banerjee <
> vi...@rtems.org>
> *Subject:* Re: Networking examples
>
> 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.
>
> I add Vijay since he has been working with this.
>
> On Tue, Aug 15, 2023 at 9:27 AM Brett Sterling <
> brett.sterl...@odysseysr.com> wrote:
>
> Hello all,
>
> My goal is to integrate networking into our RTEMS solution, so I started
> here: https://docs.rtems.org/branches/master/legacy-networking/index.html
> <https://usg02.safelinks.protection.office365.us/?url=https%3A%2F%2Fdocs.rtems.org%2Fbranches%2Fmaster%2Flegacy-networking%2Findex.html=05%7C01%7C%7Ca986447e0b18401e8d8108db9da85b8c%7Cd761ffacf6be45b88f6f288a59577095%7C0%7C0%7C638277118637201789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C

Re: Networking examples

[Joel Sherrill]

I add Vijay since he has been working with this.

On Tue, Aug 15, 2023 at 9:27 AM Brett Sterling 
wrote:

> Hello all,
>
> My goal is to integrate networking into our RTEMS solution, so I started
> here: https://docs.rtems.org/branches/master/legacy-networking/index.html.
>
> But, as soon as I had started, I hit a failure.  I tried the 'quick start'
> (https://docs.rtems.org/branches/master/legacy-networking/quick_start.html),
> but regardless of which way I tried to build, the build failed.
>

Please post about that. This shouldn't happen.

And Vijay has recent experience testing the legacy stack.


> Based on the failure of the 'quick-start' for the RTEMS "Hello World"
> example coupled with this failure, I'm starting to consider moving back to
> an older RTEMS version (I've seen networking information for both RTEMS 4 &
> 5), but first wanted to reach out to the user community to get input.
>

Let's see how this failed.

>
> Optimally, I would like to find an RTEMS example (any version) *WITH
> NETWORKING* that runs on either an RTEMS simulator, or on a commercially
> available development board so that I can see networking working and then
> evolve it into my system.
>

Do you really want the legacy stack or just a network stack?


>
> Less optimally, I would like to find an RTEMS example (any version) *WITH
> NETWORKING* that at least completely builds.
>
> If no one has examples of these, I would be glad to try different things
> to get the networking stuff building.  Especially if someone else can show
> that they can build with networking.
>
> Thanks in advance!
> Brett
>
> ___
> 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

waf breakage was Re: Hello world fails

[Joel Sherrill]

Chris... added you so you can see what's going on.

Brett was kind enough to file this ticket for you. :)

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

--joel


On Thu, Jul 13, 2023 at 8:29 AM Ben Leone  wrote:

> I ran into this issue as well with the hello world and building other
> applications using waf when starting a new project. It looks like the cause
> of the issue was changes made to rtems_waf in this commit here:
> https://git.rtems.org/rtems_waf/commit/?id=c721249146a510a6746b37e7d731cb1467f91f48
>
> For a quick fix, I just reverted the changes back to what they were before
> and the hello world and building applications seemed to work again. Still
> new to RTEMS myself but for long term, this probably isn't the correct
> solution so if someone has a detailed way to use the bsp_configure function
> in the wscript to avoid causing the arch_bsp iteration issue, that would be
> helpful!
>
> *Ben*
> ------
> *From:* users  on behalf of Joel Sherrill <
> j...@rtems.org>
> *Sent:* Wednesday, July 12, 2023 6:14 PM
> *To:* Brett Sterling 
> *Cc:* users@rtems.org 
> *Subject:* Re: Hello world fails
>
> You don't often get email from j...@rtems.org. Learn why this is important
> <https://aka.ms/LearnAboutSenderIdentification>
>
>
> On Wed, Jul 12, 2023 at 9:10 AM Brett Sterling <
> brett.sterl...@odysseysr.com> wrote:
>
> Thank you for pointing out my error.  My apologies - as I said, this is my
> first time working with RTEMS so I'm sorry I mis-stated.
>
> In the example, the "RTEMS tools suite prefix" is
> '$HOME/quick-start/rtems/6'.
>
> When I was running through the example, my "RTEMS tools suite prefix" is
> '$HOME/src/rtems/quick-start/rtems/6' (as shown in what I typed :-) ).
>
> The reason I started this thread is because I'm not the only one having
> problems with https://docs.rtems.org/branches/master/user/start/app.html -
> a co-worker was also unable to follow these instructions (because it
> appears that the 'waf' execution is looking for the wrong directory).
>
>
> If the directories in the instructions are inconsistent, please file a
> ticket. Have another new experience. :)
>
> When I teach the Open Class, I use this structure:
>
> HOME
>rtems-class
>   tools
> 6
>   rtems, rtems-source-builder, rtems-libbsd, rtems-examples and other
> source repositories at the same level
>
> prefix building RTEMS tools and RTEMS itself is ${HOME}/rtems-class/tools/6
>
> You usually end up adding ${HOME}/rtems-class/tools/6/bin to your PATH.
>
> There is no required naming/paths but you do need to be consistent. There
> is a place for source and a PREFIX for installing.
>
> Confusing things more the BSP and RTEMS Tools do NOT have to use the same
> PREFIX. :)
>
>
>
> I'm open to suggestions of things to try, but in order to clear up any
> confusion, I'm going to redo the "Quick Start" following it verbatim so
> that there is less confusion as to what problem I'm having 
>
>
> If verbatim from that doesn't work, then we need to figure out what's
> wrong in the instructions. Hopefully my alternative version above is
> correct and gives you another view of the paths/prefixes.
>
>
> Thanks to everyone for the help, and my apologies for the 'noob' errors.
>
> Brett
>
>
> --
> *From:* Gedare Bloom 
> *Sent:* Tuesday, July 11, 2023 12:29 PM
> *To:* Brett Sterling 
> *Cc:* j...@rtems.org ; users@rtems.org 
> *Subject:* Re: Hello world fails
>
>
> On Tue, Jul 11, 2023 at 9:54 AM Brett Sterling
>  wrote:
> >
> > Thanks for the response.  However, I think I need a little clarification.
> >
> > In
> https://usg02.safelinks.protection.office365.us/?url=https%3A%2F%2Fdocs.rtems.org%2Fbranches%2Fmaster%2Fuser%2Fstart%2Fapp.html=05%7C01%7C%7C925117adb0434c535d4108db823cc082%7Cd761ffacf6be45b88f6f288a59577095%7C0%7C0%7C638246969685266444%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=rmj7IwfhREwodmwv8WSXXcFUa3KCvXgTW5GBKZ%2Fh2ic%3D=0
> <https://docs.rtems.org/branches/master/user/start/app.html>, it says:
> >
> > ./waf configure --rtems=$HOME/quick-start/rtems/6 --rtems-bsp=sparc/erc32
> >
> > My prefix is: '$HOME/src/rtems', so I used ' ./waf configure
> --rtems=$HOME/src/rtems/quick-start/rtems/6 --rtems-bsp=sparc/erc32'.
> >
> If your prefix is '${HOME}/src/rtems' then your rtems should be
> '${HOME}/src/rtems'
>
> There is no extra magic that appends "quick-start/rtems/6" to your
> prefix during the installation. Since you chose $HOME/src/rtems as
> your prefix, then ever

Re: Hello world fails

[Joel Sherrill]

On Wed, Jul 12, 2023 at 9:10 AM Brett Sterling 
wrote:

> Thank you for pointing out my error.  My apologies - as I said, this is my
> first time working with RTEMS so I'm sorry I mis-stated.
>
> In the example, the "RTEMS tools suite prefix" is
> '$HOME/quick-start/rtems/6'.
>
> When I was running through the example, my "RTEMS tools suite prefix" is
> '$HOME/src/rtems/quick-start/rtems/6' (as shown in what I typed :-) ).
>
> The reason I started this thread is because I'm not the only one having
> problems with https://docs.rtems.org/branches/master/user/start/app.html -
> a co-worker was also unable to follow these instructions (because it
> appears that the 'waf' execution is looking for the wrong directory).
>

If the directories in the instructions are inconsistent, please file a
ticket. Have another new experience. :)

When I teach the Open Class, I use this structure:

HOME
   rtems-class
  tools
6
  rtems, rtems-source-builder, rtems-libbsd, rtems-examples and other
source repositories at the same level

prefix building RTEMS tools and RTEMS itself is ${HOME}/rtems-class/tools/6

You usually end up adding ${HOME}/rtems-class/tools/6/bin to your PATH.

There is no required naming/paths but you do need to be consistent. There
is a place for source and a PREFIX for installing.

Confusing things more the BSP and RTEMS Tools do NOT have to use the same
PREFIX. :)



> I'm open to suggestions of things to try, but in order to clear up any
> confusion, I'm going to redo the "Quick Start" following it verbatim so
> that there is less confusion as to what problem I'm having 
>

If verbatim from that doesn't work, then we need to figure out what's wrong
in the instructions. Hopefully my alternative version above is correct and
gives you another view of the paths/prefixes.

>
> Thanks to everyone for the help, and my apologies for the 'noob' errors.
>
> Brett
>
>
> --
> *From:* Gedare Bloom 
> *Sent:* Tuesday, July 11, 2023 12:29 PM
> *To:* Brett Sterling 
> *Cc:* j...@rtems.org ; users@rtems.org 
> *Subject:* Re: Hello world fails
>
>
> On Tue, Jul 11, 2023 at 9:54 AM Brett Sterling
>  wrote:
> >
> > Thanks for the response.  However, I think I need a little clarification.
> >
> > In
> https://usg02.safelinks.protection.office365.us/?url=https%3A%2F%2Fdocs.rtems.org%2Fbranches%2Fmaster%2Fuser%2Fstart%2Fapp.html=05%7C01%7C%7C925117adb0434c535d4108db823cc082%7Cd761ffacf6be45b88f6f288a59577095%7C0%7C0%7C638246969685266444%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=rmj7IwfhREwodmwv8WSXXcFUa3KCvXgTW5GBKZ%2Fh2ic%3D=0,
> it says:
> >
> > ./waf configure --rtems=$HOME/quick-start/rtems/6 --rtems-bsp=sparc/erc32
> >
> > My prefix is: '$HOME/src/rtems', so I used ' ./waf configure
> --rtems=$HOME/src/rtems/quick-start/rtems/6 --rtems-bsp=sparc/erc32'.
> >
> If your prefix is '${HOME}/src/rtems' then your rtems should be
> '${HOME}/src/rtems'
>
> There is no extra magic that appends "quick-start/rtems/6" to your
> prefix during the installation. Since you chose $HOME/src/rtems as
> your prefix, then everywhere that the original prefix of
> $HOME/quick-start/rtems/6 gets used you should replace with
> $HOME/src/rtems.
>
> > I believe this is equivalent to what you suggested, except that you have
> '--rtems-bsps' instead of '--rtems-bsp' (I think mine is the correct
> syntax).
> >
> > As for "pointing to the share directory', I didn't do that - that was
> the error message printed when I tried to configure.
> >
> > I'm not sure what you mean by pointing to the wrong directories - I
> followed the web page directions specifically.  However, I also admit I may
> have done something incorrectly, so if you could point to the thing I
> should change, I'm glad to do so :-)
> >
> > Thanks again,
> > Brett
> >
> > 
> > From: Joel Sherrill 
> > Sent: Tuesday, July 11, 2023 9:24 AM
> > To: Brett Sterling 
> > Cc: users@rtems.org 
> > Subject: Re: Hello world fails
> >
> > 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.
> >
> >
> >
> > On Tue, Jul 11, 2023 at 8:35 AM Brett Sterling <
> brett.sterl...@odysseysr.com> wrote:
> >
> > I've been working my way through the 'Quick Start' and everything was
> going pretty well until
> https://usg02.safelinks.protection.office365.us/?url=https%3A%2F%2Fdocs.rtems.org%2Fbranches%2Fmaster%2Fuser%2Fstart%2Fapp.html=05%7C

Re: Hello world fails

[Joel Sherrill]

On Tue, Jul 11, 2023 at 8:35 AM Brett Sterling 
wrote:

> I've been working my way through the 'Quick Start' and everything was
> going pretty well until
> https://docs.rtems.org/branches/master/user/start/app.html.
>
> I get to the point where I'm supposed to 'configure', and I get the
> following:
>
> ~/src/rtems/quick-start/app/hello$ ./waf configure
> --rtems=$HOME/src/rtems/quick-start/rtems/6 --rtems-bsp=sparc/erc32
> Setting top to   :
> /home/bsterling/src/rtems/quick-start/app/hello
> Setting out to   :
> /home/bsterling/src/rtems/quick-start/app/hello/build
> RTEMS path is not valid,
> "/home/bsterling/src/rtems/quick-start/rtems/6/share/rtems6" not found.
> (complete log in
> /home/bsterling/src/rtems/quick-start/app/hello/build/config.log)
>
>
 I have this in my handy scripts for building rtems-examples:

CPU=powerpc
BSP=psim
./waf configure --rtems=${HOME}/rtems-work/tools/6/bsp-install \
--rtems-tools=${HOME}/rtems-work/tools/6 \
--rtems-bsps=${CPU}/${BSP}

That --rtems points to the --prefix directory you used when you built and
installed RTEMS.
This is from my install:

$ pwd
/home/joel/rtems-work/tools/6/bsp-install/sparc-rtems6/leon3
$ ls
lib  make  Makefile.inc

--rtems-tools directory should have a bin/TARGET-gcc under it.

--rtems-bsps looks OK

I think you have just pointed to the wrong directories. It should be
similar to
how I build rtems-examples.

--joel



>
> I have verified that all of the source files contain only what is
> described on that page.
>
> When I look in the rtems/6/share directory, I have the following:
>
> ~/src/rtems/quick-start/rtems/6/share$ ls -l
> total 32
> drwxr-xr-x 3 bsterling osr 4096 Jul 10 14:39 doc
> drwxr-xr-x 3 bsterling osr 4096 Jul 10 15:00 gcc-12.3.1
> drwxr-xr-x 5 bsterling osr 4096 Jul 10 15:02 gdb
> drwxr-xr-x 2 bsterling osr 4096 Jul 10 15:01 iconv_data
> drwxr-xr-x 2 bsterling osr 4096 Jul 10 15:02 info
> drwxr-xr-x 2 bsterling osr 4096 Jul 10 14:43 locale
> drwxr-xr-x 5 bsterling osr 4096 Jul 10 15:00 man
> drwxr-xr-x 9 bsterling osr 4096 Jul 10 15:02 rtems
>
>
Normally you don't point all the way down to share directory

>
> I tried renaming 'rtems' to 'rtems6', but that resulted in the following
> errors:
>
> ~/src/rtems/quick-start/app/hello$ ./waf configure
> --rtems=$HOME/src/rtems/quick-start/rtems/6 --rtems-bsp=sparc/erc32
> Setting top to   :
> /home/bsterling/src/rtems/quick-start/app/hello
> Setting out to   :
> /home/bsterling/src/rtems/quick-start/app/hello/build
> Traceback (most recent call last):
>   File
> "/home/bsterling/src/rtems/quick-start/app/hello/.waf3-2.0.19-1f3c580272b15a03d2566843c5fe872a/waflib/Scripting.py",
> line 119, in waf_entry_point
> run_commands()
>   File
> "/home/bsterling/src/rtems/quick-start/app/hello/.waf3-2.0.19-1f3c580272b15a03d2566843c5fe872a/waflib/Scripting.py",
> line 182, in run_commands
> ctx=run_command(cmd_name)
>   File
> "/home/bsterling/src/rtems/quick-start/app/hello/.waf3-2.0.19-1f3c580272b15a03d2566843c5fe872a/waflib/Scripting.py",
> line 173, in run_command
> ctx.execute()
>   File
> "/home/bsterling/src/rtems/quick-start/app/hello/.waf3-2.0.19-1f3c580272b15a03d2566843c5fe872a/waflib/Configure.py",
> line 85, in execute
> super(ConfigurationContext,self).execute()
>   File
> "/home/bsterling/src/rtems/quick-start/app/hello/.waf3-2.0.19-1f3c580272b15a03d2566843c5fe872a/waflib/Context.py",
> line 92, in execute
> self.recurse([os.path.dirname(g_module.root_path)])
>   File
> "/home/bsterling/src/rtems/quick-start/app/hello/.waf3-2.0.19-1f3c580272b15a03d2566843c5fe872a/waflib/Context.py",
> line 133, in recurse
> user_function(self)
>   File "/home/bsterling/src/rtems/quick-start/app/hello/wscript", line 26,
> in configure
> rtems.configure(conf, bsp_configure = bsp_configure)
>   File
> "/home/bsterling/src/rtems/quick-start/app/hello/rtems_waf/rtems.py", line
> 190, in configure
> check_options(conf,
>   File
> "/home/bsterling/src/rtems/quick-start/app/hello/rtems_waf/rtems.py", line
> 496, in check_options
> arch_bsps = _check_arch_bsps(rtems_bsps, rtems_config, rtems_path,
>   File
> "/home/bsterling/src/rtems/quick-start/app/hello/rtems_waf/rtems.py", line
> 851, in _check_arch_bsps
> installed = _find_installed_arch_bsps(config, path, archs, version)
>   File
> "/home/bsterling/src/rtems/quick-start/app/hello/rtems_waf/rtems.py", line
> 823, in _find_installed_arch_bsps
> if _arch_from_arch_bsp(f[:-3]) in archs:
>   File
> "/home/bsterling/src/rtems/quick-start/app/hello/rtems_waf/rtems.py", line
> 862, in _arch_from_arch_bsp
> rtems_field_index = next(i for i, field in enumerate(fields) if
> field.startswith('rtems'))
> StopIteration
>
>
> Please note that I started with rtems 6 because when I tried to use the
> released rtems 5 'Getting Started', I couldn't get past the first few
> steps.  

Re: Error using rtems network legacy on MVME3100

[Joel Sherrill]

Hi


The message "sec1: (tsec ethernet) Your application has not enough mbuf
clusters configured for this driver." would normally indicate that you
don't have enough mbuf memory configured. See

https://git.rtems.org/network-demos/tree/networkconfig-mpc8313erdb.h

around line 88 for the parameters you likely need to increase.

If there is a minimum, it is in the network driver itself somewhere. Should
be under ./bsps/powerpc/mvme3100/

If this is a GigE interface, it is sometimes surprising how much buffering
you need.

--joel

On Thu, Jun 22, 2023 at 4:21 PM Zainab Olalekan  wrote:

> Hi everyone,
>
> I am having issues running rtems network legacy on the MVME3100 board. The
> configuration setup and output are below.  Could you advise on how to
> resolve this problem? Thank you.
>
>
> NET_CFG_IFACE =tse1
> NET_CFG_BOOT_PROT = dhcp
> NET_CFG_SELF_IP = xx.xx.xx.xx
> NET_CFG_NETMASK = 255.xx.xx.xx
> NET_CFG_MAC_ADDR = xx:xx:xx:xx:xx:xx
> NET_CFG_GATEWAY_IP = 0.0.0.0
> NET_CFG_DOMAINNAME = localnet
>
>
> Welcome to rtems-6.0.0 (PowerPC/Generic (no FPU)/mvme3100)
> BSP: mvme3100, CVS Release ($Name$)
> CPU 0x8020 - rev 0x20
> Additionnal boot options are H
> Initial system stack at 117070
> Going to start PCI buses scanning and initialization
> Board Type: MVME3100-1152 (S/N E1726C0)
> External (=PCI Bus) Clock Freq   :    Hz
> Core Complex Bus (CCB) Clock Freq:  0 Hz
> CPU Clock Freq: 13332 Hz
> Ethernet 0  EC:9E:CD:19:B3:53
> Ethernet 1  EC:9E:CD:19:B3:54
> Ethernet 2  EC:9E:CD:19:B3:55
> Number of PCI buses found is : 2
> BUS:SLOT:FUN  VENDOR-DEV_ID: COMMAND STATUS BASE_ADDR0 BASE_ADDR1 IRQ_PIN
> -> IRQ_LINE
>   0:0x00:00x1057-0x0008:  0x0006 0x20b0 0x8000 0x   0
> ->   0 (=0x00)
>   0:0x11:00x10e3-0x0148:  0x0146 0x02b0 0x8014 0x   1
> ->   0 (=0x00)
>   0:0x12:00x10b5-0x6520:  0x0147 0x02b0 0x 0x   0
> ->   0 (=0x00)
>   0:0x14:00x1095-0x3124:  0x01c7 0x02b0 0x8034 0x   1
> ->   2 (=0x02)
> Memory: 268435456 bytes
> Cleared PCI errors: pci_stat was 0x20b0
> OpenPIC Version 1.2 (1 CPUs and 56 IRQ sources) at 0x3775135744
> OpenPIC Vendor 0 (Unknown), Device 0 (Unknown), Stepping 0
> OpenPIC timer frequency is 4166 Hz
> MSR is 0x1000, TCR 0x0400
> -
> Exit from bspstart
> Tundra Tsi148 PCI-VME bridge detected at 0x8010, IRQ 0
> Tsi148 Outbound Ports:
> Port  VME-Addr   Size   PCI-Adrs   Mode:
> 0:0x2000 0x0e00 0xc000 A32, SUP, D32, SCT
> 1:0x 0x00ff 0xcf00 A24, SUP, D32, SCT
> 2:0x 0x0001 0xcfff A16, SUP, D32, SCT
> 7:0x 0x0100 0xce00 CSR, SUP, D32, SCT
> Tsi148 Inbound Ports:
> Port  VME-Addr   Size   PCI-Adrs   Mode:
> 0:0xc000 0x1000 0x A32, PGM, DAT, SUP, USR, MBLT, BLT
> vmeTsi148 IRQ manager: looking for registers on VME...
> Trying to find CSR on VME...
> vmeTsi148 - IRQ manager using VME CSR to flush FIFO
> libi2c: Claiming driver slot failed (rtems status code 5)
> Initializing I2C library failed
> Registering /dev/console as minor 0 (==/dev/ttyS0)
>
>
> *** BEGIN OF TEST TELNETD 2 ***
> *** TEST VERSION: 6.0.0.b2967081e5daa673141d714a2e53280898dce566
> *** TEST STATE: EXPECTED_PASS
> *** TEST BUILD: RTEMS_POSIX_API
> *** TEST TOOLS: 12.2.1 20230425 (RTEMS 6, RSB
> 3c8c2ce38a8fe0a622f88fb3422d1f8fa609609b, Newlib 9ae9eef)
> tsec1: (tsec ethernet) Your application has not enough mbuf clusters
>   configured for this driver.
> Can't bring tse1 up: No such device or address
>  an't set default route: Network is
>  unr[e aRchTaEblMe
> c./.S. /stehsutsuittdeso/wtelnent d02]/init.
>  : 6R3T rv E=M= 0S
>  version: 6.0.0.b2967081e5daa673141d714a2e53280898dce566
> RTEMS tools: 12.2.1 20230425 (RTEMS 6, RSB
> 3c8c2ce38a8fe0a622f88fb3422d1f8fa609609b, Newlib 9ae9eef)
> executing thread ID: 0x0a010001
> executing thread name: UI1
>
>
>
>
> Best Regards,
> Zainab Olalekan
> ___
> 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: Problem using sphinx to build documentation

[Joel Sherrill]

On Tue, Jun 6, 2023 at 4:11 AM andrew.butterfi...@scss.tcd.ie <
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
>

Which sphinx version got installed?

>
> 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/ <
> http://www.scss.tcd.ie/Andrew.Butterfield/>
> 
>
>
>
>
>
> ___
> 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

ESA Mission Juice Launch

[Joel Sherrill]

 Hi

The JUICE mission was scheduled to launch today but unfortunately, there
was a delay on the launch of the ESA Juice mission this morning due to
lightning. But on a positive note, it means that we all didn't miss it. :)
It is scheduled for Friday at 8:14 a.m. ET.

"After JUICE arrives at Jupiter in July 2031, the spacecraft will spend
about three and a half years orbiting the gas giant and conducting flybys
of three of its moons: Ganymede, Callisto and Europa. Toward the end of the
mission, Juice will focus solely on orbiting Ganymede, making it the first
spacecraft to ever orbit a moon in the outer solar system."

AFAIK this mission includes at least RTEMS based instruments and Data
Processing Unit (DPU). If anyone has more details on the use of RTEMS on
this mission, please share.

https://flightsoftware.jhuapl.edu/files/2016/Day-3/Day-3-13-Hellstrom.pdf

More general info on the mission

https://www.bbc.com/news/science-environment-65254502

--joel
Sans Serif
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Error in building rtems 5.3 tools via mingw

[Joel Sherrill]

On Fri, Mar 17, 2023 at 10:22 AM Giovanni Righi  wrote:

> Good afternoon,
> I'm trying to build the rtems 5.3 tools in windows using mingw, but I'm
> getting an error during the gdb build.
> I'm attaching the logs so you can see what's going on.
>

The error looks like this gdb is using a feature which is considered
deprecated by the late model gcc in your mingw.

=
In file included from ../../gdb-9.1/gdb/corelow.c:25:

../../gdb-9.1/gdb/inferior.h: In member function 'void
infcall_suspend_state_deleter::operator()(infcall_suspend_state*) const':

../../gdb-9.1/gdb/inferior.h:80:38: warning: 'bool
std::uncaught_exception()' is deprecated: use 'std::uncaught_exceptions()'
instead [-Wdeprecated-declarations]

   80 | if (!std::uncaught_exception ())
==

I see two options since I don't think using an older compiler version is
likely possible.

(1) Change the RSB file which has the gdb configure command to ensure it
disables werror.

(2) Update the version of gdb in the RSB. You can probably just copy the
gdb-12 cfg file from the master and bump to that.

Both require a minor level of digging into rtems-source-builder/rtems/config

--joel


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

RTEMS Open Class (virtual) April 24-28, 2023

[Joel Sherrill]

Hi

There will be an RTEMS Open Class held virtually the week of April 24-28
Times each day will be based on the US Central time zone (Chicago).
Adjustments
may be considered to accommodate the participants.

April 24  - Kick Start and Getting Started
April 25-28 - Open Class

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

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

Thanks.

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

Re: Problems with docs on docs.rtems.org

[Joel Sherrill]

I can confirm that. Do you mind filing a ticket?

I suspect this is just a matter of the script generating the online docs is
missing the --single-html option.

But the person responsible for that production will need a ticket to
remember since they are about to go on holiday.

Thanks.

--joel

On Fri, Feb 17, 2023 at 2:38 AM Schweikhardt, Jens (TSPCE6-TL5) <
jens.schweikha...@tesat.de> wrote:

> Hello *,
>
>
>
> It seems there is a problem with the docs on docs.rtems.org.
>
> All the orange icon “HTML” links in the “Single HTML” column lead to an
> empty page.
>
> Can anyone confirm this?
>
>
>
> The pdf links look ok.
>
>
>
> Jens
>
>
>
> --
>
> Tesat-Spacecom GmbH & Co. KG
> Sitz: Backnang; Registergericht: Amtsgericht Stuttgart HRA 270977
> Persoenlich haftender Gesellschafter: Tesat-Spacecom Geschaeftsfuehrungs
> GmbH;
> Sitz: Backnang; Registergericht: Amtsgericht Stuttgart HRB 271658;
> Geschaeftsfuehrung: Thomas Reinartz, Kerstin Basche, Ralph Schmid
>
> [image: banner]
> ___
> 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: CPU Usage

[Joel Sherrill]

On Fri, Jan 13, 2023, 8:17 PM  wrote:

> I basically just copied and renamed the existing function that prints to
> the console, but changed it to return a struct.  I couldn’t personally give
> it back.  I thought my customer at the time would roll it back in.  Looks
> like that never happened.  Sorry.
>

That's more or less what I've had in mind. Asking for the info for a single
thread is easy from an API view but asking for all threads is more
complicated since the user has to pass an array of structures to receive
the information and it might not be long enough.

--joel

>
>
> On Jan 13, 2023, at 17:05, Joel Sherrill  wrote:
>
> 
> That's the right answer Karel.
>
> I will add that we have been open to the addition of an API to obtain this
> information if someone could propose one. 
>
> This is an area where not knowing what users would like to have has been a
> hurdle.
>
> On Fri, Jan 13, 2023 at 3:42 PM Karel Gardas 
> wrote:
>
>>
>> I would guess it is, but judge yourself by going to the RTEMS source
>> code[*] and grepping for "rtems_cpu_usage".
>>
>> Cheers,
>> Karel
>>
>> [*] used few months old trunk here.
>>
>> On 1/13/23 21:48, Molock, Dwaine S. (GSFC-5820) wrote:
>> > Hello,
>> >
>> > Is there a RTEMS API available to obtain the current CPU usage or
>> > anything similar to the “/proc/stat” file in Linux that can be read to
>> > obtain this information?
>> >
>> > Thanks,
>> >
>> > Dwaine
>> >
>> >
>> > ___
>> > 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
>
>
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: CPU Usage

[Joel Sherrill]

That's the right answer Karel.

I will add that we have been open to the addition of an API to obtain this
information if someone could propose one. 

This is an area where not knowing what users would like to have has been a
hurdle.

On Fri, Jan 13, 2023 at 3:42 PM Karel Gardas 
wrote:

>
> I would guess it is, but judge yourself by going to the RTEMS source
> code[*] and grepping for "rtems_cpu_usage".
>
> Cheers,
> Karel
>
> [*] used few months old trunk here.
>
> On 1/13/23 21:48, Molock, Dwaine S. (GSFC-5820) wrote:
> > Hello,
> >
> > Is there a RTEMS API available to obtain the current CPU usage or
> > anything similar to the “/proc/stat” file in Linux that can be read to
> > obtain this information?
> >
> > Thanks,
> >
> > Dwaine
> >
> >
> > ___
> > 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: C++ math functions not available in namespace std

[Joel Sherrill]

On Wed, Jan 11, 2023 at 8:46 AM  wrote:

> Ah, thanks for the clarification.
>

FWIW in case someone looks at this, I think this impacts aarch64, x86,
powerpc, and maybe one other architecture. I just don't remember for sure.


> If I can be of any help with the porting, let me know.
>

Thanks. Maybe some testing.

--joel

>
>
>
>
> *From:* Joel Sherrill 
> *Sent:* Mittwoch, 11. Januar 2023 14:08
> *To:* Sommer, Jan 
> *Cc:* rtems-us...@rtems.org 
> *Subject:* Re: C++ math functions not available in namespace std
>
>
>
> This happens on the architectures where size of long double is not the
> same as double. The header file disables everything if any math method is
> missing.
>
>
>
> I have it on my list to address. I was porting the long double methods
> from FreeBSD before anyone ran into this but haven't finished
>
>
>
> On Wed, Jan 11, 2023, 3:43 AM  wrote:
>
> Hello and happy New Year,
>
> I stumbled upon a slightly weird problem with the current cross-compilers.
> According to https://en.cppreference.com/w/cpp/numeric/math/fmax
> std::fmax should be part of  for >= C++11.
> However, if I try to use it, I sometimes get  "error: 'fmax' is not a
> member of 'std'; did you mean 'max'?"
>
> I do get the error when compiling the test file (see below) with
> i386-rtems6-g++ and riscv-rtems6-g++, but for example not for
> arm-rtems6-g++.
> If I use "fmax" instead of "std::fmax" the file compiles for all 3
> architectures.
> However, I have a library which uses the math functions with the namespace
> qualifier, which I cannot change that easily.
>
> Does someone know, what is the reason for that behavior (I guess it's
> related to newlib?) and what a solution could look like?
>
> Best regards,
>
> Jan
>
>
> PS: My test file looks like this:
>
> #include 
>
> double test(double a, double b)
> {
> return std::fmax(a, b);
> }
>
>
> ___
> 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: C++ math functions not available in namespace std

[Joel Sherrill]

This happens on the architectures where size of long double is not the same
as double. The header file disables everything if any math method is
missing.

I have it on my list to address. I was porting the long double methods from
FreeBSD before anyone ran into this but haven't finished

On Wed, Jan 11, 2023, 3:43 AM  wrote:

> Hello and happy New Year,
>
> I stumbled upon a slightly weird problem with the current cross-compilers.
> According to https://en.cppreference.com/w/cpp/numeric/math/fmax
> std::fmax should be part of  for >= C++11.
> However, if I try to use it, I sometimes get  "error: 'fmax' is not a
> member of 'std'; did you mean 'max'?"
>
> I do get the error when compiling the test file (see below) with
> i386-rtems6-g++ and riscv-rtems6-g++, but for example not for
> arm-rtems6-g++.
> If I use "fmax" instead of "std::fmax" the file compiles for all 3
> architectures.
> However, I have a library which uses the math functions with the namespace
> qualifier, which I cannot change that easily.
>
> Does someone know, what is the reason for that behavior (I guess it's
> related to newlib?) and what a solution could look like?
>
> Best regards,
>
> Jan
>
>
> PS: My test file looks like this:
>
> #include 
>
> double test(double a, double b)
> {
> return std::fmax(a, b);
> }
>
>
> ___
> 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

RTEMS Open Class (virtual) January 23-27, 2023

[Joel Sherrill]

Hi

There will be an RTEMS Open Class held virtually the week of January 23-27.
Times each day will be based on the US Central time zone (Chicago).
Adjustments
may be considered to accommodate the participants.

January 23  - Kick Start and Getting Started
January 24-27 - Open Class

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

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

Thanks.

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

Re: Running two RTEMS instances on two RISC-V harts

[Joel Sherrill]

The leon3 BSP also supported something similar at one point.

If the two applications do not need to communicate, then it should
not be an issue. If the do need to communicate, then this might be
a case where the original distributed multiprocessing in RTEMS makes
sense. It isn't used much but is still there. Or you could just reserve some
RAM for a shared communications area and manage it yourself.

The key is going to be keeping the two really separate and making
sure you can load two images.

--joel

On Mon, Oct 24, 2022 at 8:03 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Jens,
>
> in general, such a setups works. We used it some time ago on the NXP
> P1020 before the SMP support was available. You just have to provide two
> MEMORY definitions for the linker. You also have to make sure that you
> don't accidentally share hardware modules between the two RTEMS
> instances without synchronization.
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> ___
> 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 and file descriptors

[Joel Sherrill]

On Mon, Oct 17, 2022, 12:23 PM Miroslaw Dach 
wrote:

> Hello,
>
> I have followed the instruction to change  the limit of File Descriptors
> higher than 64:
>
> https://docs.rtems.org/branches/master/user/migration/v4_11-to-v5.html
> chapter 13.1.3. File Descriptors
>
> Is it required to rebuild the RTEMS5 kernel with the
> macro FD_SETSIZE set to the higher value then 64 or is it enough to
> set it  along with CONFIGURE_MAXIMUM_FILE_DESCRIPTORS when the application
> is built?
>

If you go above 64 for configured file descriptors, FD_SETSIZE used by
select() does not automatically change. That is set in the C Library
headers which are considered constant when RTEMS is built.

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.

How many descriptors do you need? And will you be using select()?

--joel



> Best Regards
> Mirek
> ___
> 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: xilinx_zynqmp_ilp32_zu3eg namespace issue (cmath round not in std)

[Joel Sherrill]

On Wed, Oct 5, 2022 at 1:20 PM Trip Richert 
wrote:

> I'm having an issue compiling using with the ilp32 compiler.  Some free
> functions, which should be in the std namespace, aren't namespaced.
>
> Here's an example.
>
> #include 
> double round_wrapper(double val)
> {
>return std::round(val);
> }
>
> I get an error message that the round function isn't in the std
> namespace.  Calling return round(val); without the std namespace compiles
> successfully.
>
> This is the command I used to compile
>
> /opt/rtems/6/aarch64/bin/aarch64-rtems6-g++ -std=gnu++11 -D_GNU_SOURCE
> -D__RTEMS_MAJOR__=6 -D__rtems__ -fno-strict-aliasing -mcpu=cortex-a53
> -mabi=ilp32
> -isystem
> /opt/rtems/6/aarch64/bsps/aarch64-rtems6/xilinx_zynqmp_ilp32_zu3eg/lib/include
> -qrtems -ffunction-sections
> -fdata-sections -fPIC -o test.obj -c example.cpp
>
> I tried a couple of revisions of rtems, the latest was  aarch64-rtems6-g++
> (GCC) 12.2.1 20220924 (RTEMS 6, RSB
> cfed1659a297cb0f95a03e053345962097aa02bf, Newlib 01f6251c0)
>
> if I try to compile the exact same code with similar arguments for arm
> zedboard, it compiles successfully.  So, something is different about the
> ilp32 compiler
>
> /opt/rtems/6/arm/bin/arm-rtems6-g++  -std=gnu++11 -D__RTEMS_MAJOR__=6
> -D__rtems__ -fno-strict-aliasing -mthumb -mfpu=neon -mfloat-abi=hard
> -march=armv7-a -mtune=cortex-a9 -isystem
> /opt/rtems/6/arm/bsps/arm-rtems6/xilinx_zynq_zedboard/lib/include -qrtems
> -ffunction-sections -fdata-sections -fPIC  -o test.obj -c example.cpp
>

What gcc version is this?  is provided by gcc.


>
> I wasn't sure whether to send this to the bug email list, or to check here
> first to see if someone noticed something I was messing up first.
>

This is a good enough place to start the discussion.

--joel

>
>
> Thanks,
> Trip Richert
>
>
> --
>
> CONFIDENTIALITY NOTICE:
>
> *The contents of this e-mail message may be privileged, confidential,
> proprietary, Controlled Unclassified Information (CUI) or otherwise
> protected against disclosure or dissemination. This e-mail message and any
> files transmitted with it are intended solely for the use of the
> individual/individuals or entity/entities to whom they are addressed. If
> you are not the intended recipient of this message, any dissemination,
> distribution, printing or copying is strictly prohibited. If you have
> received this message in error, please e-mail or call the sender
> (trip.rich...@nta-inc.net , 2563361406) and
> destroy all copies. *
> ___
> 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

DART Impact Live Stream

[Joel Sherrill]

Hi

Tomorrow is the day DART slams into the asteroid. Be sure to catch the NASA
live feed. This is an RTEMS mission of great importance. It could be the
beginning of a planetary defense system.

Tune in for our live broadcast coverage of DART’s impact with Dimorphos
starting Monday, Sept. 26 at 6 p.m. EDT on NASA TV, the agency’s website,
and on Facebook, Twitter, or YouTube. You can also watch a live feed from
DART's camera instrument, DRACO, in the moments leading up to impact.

NASA link: https://www.nasa.gov/nasalive

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

Re: RSB build fails on M1 Macbook Pro

[Joel Sherrill]

On Tue, Sep 20, 2022 at 8:17 AM 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.
>

That's usually a misleading message. You have Python but not the
associated python-devel or whatever it is called in that environment.

It can't find the Python.h file I think is what it will be if you look in
the
right config.log.

--joel


>
> 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" , "
> users@rtems.org" 
> > Subject: Re: RSB build fails on M1 Macbook Pro
> >
> >
> >  JFYI: 2 months ago I pushed patches in order to make M1 working at
> least
> >  for arm target. As devil is in the detail you will also need to
> provide
> >  rsb-report-sparc-rtems6-gdb-11.2-x86_64-apple-darwin21.6.0-1.txt for
> >  investigation.
> >
> >  Karel
> >
> >  On 9/20/22 14:55, andrew.butterfi...@scss.tcd.ie wrote:
> >  > Dear all,
> >  > I tried to follow the Quickstart on my new M1 Macbook Pro (Apple
> Silicon),
> >  > which one of my students is also trying to do.
> >  >
> >  > It fails with the following error
> >  >
> >  > ...
> >  > downloading: sources/gdb-11.2.tar.xz - 21.0MB of 21.0MB (100%)
> >  > building: sparc-rtems6-gdb-11.2-x86_64-apple-darwin21.6.0-1
> >  > error: building sparc-rtems6-gdb-11.2-x86_64-apple-darwin21.6.0-1
> >  > Build FAILED
> >  >See error report:
> rsb-report-sparc-rtems6-gdb-11.2-x86_64-apple-darwin21.6.0-1.txt
> >  > error: building sparc-rtems6-gdb-11.2-x86_64-apple-darwin21.6.0-1
> >  > Build Set: Time 0:06:26.055237
> >  > error: building sparc-rtems6-gdb-11.2-x86_64-apple-darwin21.6.0-1
> >  > Build Set: Time 0:06:26.058387
> >  > Build FAILED
> >  >
> >  > python maps to /usr/local/bin/python - it's a Mach-O 64-bit
> executable x86_64
> >  >
> >  > python --version is 3.6.8
> >  >
> >  > There is a  homebrew python3 but it's an arm64 executable, so
> seems not to be implicated.
> >  >
> >  > The full terminal transcript is attached
> >  >
> >  > 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/
> >  >
> 
> >  >
> >  >
> >  >
> >  > ___
> >  > 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: RSB build fails on M1 Macbook Pro

[Joel Sherrill]

FWIW OAR very recently got an M1 Mac to do automated build sweeps on.  It
has not been brought online yet but it's in the queue.

You can see what else is being built regularly by looking at the build
mailing list results. Help is needed for odd host and target issues but at
least the intent is to build 5, 6, and 7 at least once a week on a variety
of hosts if there are changes.

On Tue, Sep 20, 2022, 8:01 AM Karel Gardas  wrote:

>
> JFYI: 2 months ago I pushed patches in order to make M1 working at least
> for arm target. As devil is in the detail you will also need to provide
> rsb-report-sparc-rtems6-gdb-11.2-x86_64-apple-darwin21.6.0-1.txt for
> investigation.
>
> Karel
>
> On 9/20/22 14:55, andrew.butterfi...@scss.tcd.ie wrote:
> > Dear all,
> > I tried to follow the Quickstart on my new M1 Macbook Pro (Apple
> Silicon),
> > which one of my students is also trying to do.
> >
> > It fails with the following error
> >
> > ...
> > downloading: sources/gdb-11.2.tar.xz - 21.0MB of 21.0MB (100%)
> > building: sparc-rtems6-gdb-11.2-x86_64-apple-darwin21.6.0-1
> > error: building sparc-rtems6-gdb-11.2-x86_64-apple-darwin21.6.0-1
> > Build FAILED
> >See error report:
> rsb-report-sparc-rtems6-gdb-11.2-x86_64-apple-darwin21.6.0-1.txt
> > error: building sparc-rtems6-gdb-11.2-x86_64-apple-darwin21.6.0-1
> > Build Set: Time 0:06:26.055237
> > error: building sparc-rtems6-gdb-11.2-x86_64-apple-darwin21.6.0-1
> > Build Set: Time 0:06:26.058387
> > Build FAILED
> >
> > python maps to /usr/local/bin/python - it's a Mach-O 64-bit executable
> x86_64
> >
> > python --version is 3.6.8
> >
> > There is a  homebrew python3 but it's an arm64 executable, so seems not
> to be implicated.
> >
> > The full terminal transcript is attached
> >
> > 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/
> > 
> >
> >
> >
> > ___
> > 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

Fwd: FSW-2023 Registration is now open! Secure your ticket

[Joel Sherrill]

Hi

This is the first in-person FSW since before COVID. This is a workshop
focused on space going applications. The presentations tend to be very
interesting and top notch. Plus the opportunity to speak with others in the
field is really incredible.

OAR is planning to be there including myself and a few others. Gaisler
usually is represented as well. Hopefully others will be able to attend as
well.

--joel



 Forwarded Message 
Subject:FSW-2023 Registration is now open! Secure your ticket
Date:   Fri, 16 Sep 2022 18:00:18 -0400 (EDT)
From:   Flight Software Workshop 
Reply-To:   i...@flightsoftware.org
To: joel.sherr...@oarcorp.com



Flight software workshop: March 20 to 23, 2023 at Caltech/JPL
Dear Joel,

Registration is open for 2023 Flight Software Workshop, which will be in
person at Caltech in Pasadena, CA on March 20, 2023 to March 23, 2023.
  We hope you will join us for a week of flight software discussion and
knowledge-sharing.

Register for FSW-2023 here!
<
https://r20.rs6.net/tn.jsp?f=001F4LSfUx-u8pMPB_uq4Kb7F1RFzB29_X2YN2xRJ8EkG_QvTOowjCo2Y5o6-0297qZi7_e62PU0flSackTTxx5M5LmS7IBU0XZ_If75HdFHNRmRqpl2I5PHW8beRhQvAQiw-iwrRrr6G21snEcnqqwpyAZcxLdLwEWJIYdGc2Gi-W3JffDA2piuttuszN2Ldr8IGtOqccd3ygMXHzV2UHyZNlz-GtgOmvL=vpTyfEz6YELgKOJNCWjyCj022AxYPw-idGcVy6HxH4IRtDoLgeG7fg===Mi3ZzLFyaismnwMWolLZUSl8J6cBnok1rcYjls8ODvl_3hnoeeYMew==>



Sign up for our mailing list
<
https://r20.rs6.net/tn.jsp?f=001F4LSfUx-u8pMPB_uq4Kb7F1RFzB29_X2YN2xRJ8EkG_QvTOowjCo2Y5o6-0297qZtYIJcq6enlPpg3TZ9KNRzOE77ZKdINNFjUgfrkErFcF-8ONefy83s51_u0clCDtxzKdrphq9_ItuRuX9-N4xKygsJg6Fkg133TPe1CrGpfqN4oxw5AvXObtLsPUPrZdvwl0CgY3OxBpgwfkeVsaitDh4dto5JsvYmZ2LDOfZfNamHWFoonJOw_SfIiocMjYUz0Z4Bjz4II-y9Dlb7keMpYnvceeFmE5PZOSkJcWhmMyrDwScAgRXe5cQ1p4gBW_-C-TMRzyOKVeqV5IFnVUhNw===vpTyfEz6YELgKOJNCWjyCj022AxYPw-idGcVy6HxH4IRtDoLgeG7fg===Mi3ZzLFyaismnwMWolLZUSl8J6cBnok1rcYjls8ODvl_3hnoeeYMew==>
to

keep up to date on FSW-2023.

FSW-2023 Workshop Cycle



Registration Opens: September 16, 2022-- TODAY!

First Call for Abstracts: October 1, 2022

Abstract Submission Deadline: December 12, 2022

Abstract Acceptance Notification: January 15, 2023

Presentation Submission Deadline: February 20, 2023

Workshop: March 20-23, 2023

The Flight Software Workshop is continuing its 16-year tradition of
emphasizing the latest technical content in an informal setting. The
workshop provides an opportunity to present current flight software
architectures, novel approaches to mission solutions, and techniques for
flight software development, integration, test, and verification.

FSW-2023 Topics

General themes for Flight Software Workshop:

   * Artificial intelligence, machine learning, and onboard data processing
   * Space networking
   * Onboard data storage and representation
   * Flight software architectures, frameworks, and software buses
   * Software enabled mission concepts
   * Digital twin, config management, and software enabled emulation
   * DevOps, continuous integration, and automated testing
   * FSW, embedded processor, and FPGA interactions
   * Flight Operating Systems
   * New languages (bring your non-C work)
   * Your hot FSW topic we haven't listed!

Please note: Themes are suggested topics, meant to guide and inspire
Workshop participants. Other flight software subjects are welcome for
consideration!



Demos and Workshop Sessions

We would like to encourage the community to get hands-onat FSW Workshop
2023! While we will continue our presentation tracks, we recommend
considering submitting your hardware and software demonstration, as well
as your workshop ideas.


Check your inbox on October 1(FSW-2023 Call for Abstracts) for
instructions on how to submit your abstract for a presentation, demo, or
workshop this year!





The Aerospace Corporation, NASA Jet Propulsion Laboratory, Southwest
Research Institute, and The Johns Hopkins University Applied Physics
Laboratory are the Founding Sponsors of the Flight Software Workshop.
Additional sponsorship opportunities exist for the 2023 Workshop. Please
email inquiries to Violet Torossian (Sponsor Relations) at
spon...@flightsoftware.org .

More information about this year's Workshop can be found at the 2023
Workshop Home Page
<
https://r20.rs6.net/tn.jsp?f=001F4LSfUx-u8pMPB_uq4Kb7F1RFzB29_X2YN2xRJ8EkG_QvTOowjCo2Q81GblSU-4ACmU_PwP-JpXrT6JZoNa6dVwA9YbqcSd0RHnJLELIBtsjHWiY8bH0sJnjTia4Gdpwc6RFIp1UUlWDrx3EGf8Tzg===vpTyfEz6YELgKOJNCWjyCj022AxYPw-idGcVy6HxH4IRtDoLgeG7fg===Mi3ZzLFyaismnwMWolLZUSl8J6cBnok1rcYjls8ODvl_3hnoeeYMew==>.

All prior years' recorded and pre-recorded presentations can be found on
our FSW Workshop YouTube playlist page
<

Re: Want to add RISC-V-based PolarFire SoC support to RTEMS

[Joel Sherrill]

On Fri, Aug 26, 2022 at 6:37 AM  wrote:

> Hi Hesham,
>
> The boot HARTID configurable is Ok but I am thinking about SMP.
>
> The PolarFire SoC has 4 U54's with hartid 1,2,3,4 but the SMP
> starts with cpu number '0' to MAX cpu number then the PolarFire
> SoC U54's hartid number should become 0,1,2,3 to run the SMP.
>

Yeah. I think the BSP is going to be responsible for mapping things
so RTEMS can ask for 0..n-1 but the BSP interacts with 1..n. If that
can be done via changing the base number to 0 without messing
anything up, that would be the simplest I think.

--joel


> Regards
> Padmarao
>
> On Thu, 2022-08-25 at 10:05 +0100, Hesham Almatary wrote:
> >
> > Hello Padmarao,
> >
> > I wonder if we can make the boot HARTID configuragle in RTEMS for
> > RISC-V. Something like introducing a new option (e.g.,
> > optboothartid.yml) in the generic RISC-V BSP.
> >
> > On Thu, 25 Aug 2022 at 06:08,  wrote:
> > > Hi Hesham,
> > >
> > > The generic RISC-V BSP is working on the PolarFire SoC without SMP
> > > but
> > > doesn't work with SMP because it expects first HARTID  should be
> > > '0', t
> > > he PolarFire SoC SMP starts with HARTID '1'(U54) because the HARTID
> > > '0'(E51) reserved for first state booatloader. When the RTEMS is
> > > executing on the PolarFire SoC it reads hartid number with "HARTID-
> > > 1" so that the SMP can start from hartid '0'.
> > >
> > > i.e reason I have added seperate BSP for the PolarFire SoC.
> > >
> > > Yes, there is a lot of code duplication and will try to re-use the
> > > existing code for the PolarFire SoC with modification.
> > >
> > > Will remove platform-dependent #ifdefs in startup code, is it Ok to
> > > add CPU dependent #ifdefs?
> > >
> > > Regards
> > > Padmarao
> > >
> > > On Wed, 2022-08-24 at 11:00 +0100, Hesham Almatary wrote:
> > > > Hello Padmarao,
> > > >
> > > > It would be great to have support for running RTEMS on PolarFire.
> > > >
> > > > I had a quick look at the code. There is a lot of code
> > > > duplications
> > > > already. The generic RISC-V BSP already has SMP, CLINT, PLIC, and
> > > > 16550 support. Why can't this code be shared (i.e., if you use
> > > > the
> > > > riscv/riscv BSP and just provide your FDT)?
> > > >
> > > > I'd also try to avoid introducing platform-dependent #ifdefs in
> > > > shared
> > > > code (e.g., start.S).
> > > >
> > > > Cheers,
> > > > Hesham
> > > >
> > > > On Wed, 24 Aug 2022 at 08:14, 
> > > > wrote:
> > > > > Hi,
> > > > >
> > > > > I want to add a new BSP for RISC-V-based Microchip PolarFire
> > > > > SoC(MPFS)
> > > > > to RTEMS.
> > > > >
> > > > > The PolarFire SoC is the 4x 64-bit RISC-V U54 cores and a 64-
> > > > > bit
> > > > > RISC-
> > > > > V
> > > > > E51 monitor core SoC from Microchip.
> > > > >
> > > > > The new BSP is added for the U54 cores not for E51 because the
> > > > > E51
> > > > > moniter core is resreved for first stage bootloader (Hart
> > > > > Software
> > > > > Services).
> > > > >
> > > > > This BSP supports below components:
> > > > >
> > > > > 4 CPU Cores (U54)
> > > > > Interrupt controller (PLIC)
> > > > > Timer (CLINT)
> > > > > UART (mmuart, 16550-compatible)
> > > > >
> > > > > We have already done some work on this and tested but not with
> > > > > latest
> > > > > RTEMS source(8th March, 2022 commit) and want to send patches
> > > > > with
> > > > > latest source.
> > > > >
> > > > > https://github.com/polarfire-soc/rtems/tree/mpfs-rtems
> > > > >
> > > > > Regards
> > > > > Padmarao
> > > > > ___
> > > > > 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
>
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Want to add RISC-V-based PolarFire SoC support to RTEMS

[Joel Sherrill]

On Thu, Aug 25, 2022, 12:08 AM  wrote:

> Hi Hesham,
>
> The generic RISC-V BSP is working on the PolarFire SoC without SMP but
> doesn't work with SMP because it expects first HARTID  should be '0', t
> he PolarFire SoC SMP starts with HARTID '1'(U54) because the HARTID
> '0'(E51) reserved for first state booatloader. When the RTEMS is executing
> on the PolarFire SoC it reads hartid number with "HARTID-1" so that the SMP
> can start from hartid '0'.
>
> i.e reason I have added seperate BSP for the PolarFire SoC.
>
> Yes, there is a lot of code duplication and will try to re-use the
> existing code for the PolarFire SoC with modification.
>

You are on a path to create a BSP variant. Share entire files via build
system. Set conditional variables for small things. For larger things just
pick different files.


> Will remove platform-dependent #ifdefs in startup code, is it Ok to
> add CPU dependent #ifdefs?


Where? Usually if they are small sections of code, it's ok in a BSP

Just balance amount shared versus just swapping the file, refactoring a
helper method which can be swapped at the file level, etc

>
>
> Regards
> Padmarao
>
> On Wed, 2022-08-24 at 11:00 +0100, Hesham Almatary wrote:
> > Hello Padmarao,
> >
> > It would be great to have support for running RTEMS on PolarFire.
> >
> > I had a quick look at the code. There is a lot of code duplications
> > already. The generic RISC-V BSP already has SMP, CLINT, PLIC, and
> > 16550 support. Why can't this code be shared (i.e., if you use the
> > riscv/riscv BSP and just provide your FDT)?
> >
> > I'd also try to avoid introducing platform-dependent #ifdefs in
> > shared
> > code (e.g., start.S).
> >
> > Cheers,
> > Hesham
> >
> > On Wed, 24 Aug 2022 at 08:14,  wrote:
> > > Hi,
> > >
> > > I want to add a new BSP for RISC-V-based Microchip PolarFire
> > > SoC(MPFS)
> > > to RTEMS.
> > >
> > > The PolarFire SoC is the 4x 64-bit RISC-V U54 cores and a 64-bit
> > > RISC-
> > > V
> > > E51 monitor core SoC from Microchip.
> > >
> > > The new BSP is added for the U54 cores not for E51 because the E51
> > > moniter core is resreved for first stage bootloader (Hart Software
> > > Services).
> > >
> > > This BSP supports below components:
> > >
> > > 4 CPU Cores (U54)
> > > Interrupt controller (PLIC)
> > > Timer (CLINT)
> > > UART (mmuart, 16550-compatible)
> > >
> > > We have already done some work on this and tested but not with
> > > latest
> > > RTEMS source(8th March, 2022 commit) and want to send patches with
> > > latest source.
> > >
> > > https://github.com/polarfire-soc/rtems/tree/mpfs-rtems
> > >
> > > Regards
> > > Padmarao
> > > ___
> > > 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: How can I add LDFLAGS for bsp build?

[Joel Sherrill]

On Fri, Jul 22, 2022 at 11:40 AM DAVE ERICKSON  wrote:

> Hi Joel;
>
>
>> BTW  RTEMS uses GNU autotools differently in that it configures in one
>> folder/directory and the builds targets into another folder is a very rare
>> way of using autotools. I know this because I have downloaded and reviewed
>> over 5000 open source projects for my new book.
>>
>
> Funny because the core GNU tools like gcc, binutils, gdb plus newlib all
> allow out of tree builds.
>
> It may be rare to use it this way but it works and leaves your source
> directory with no build artifacts.
>
> It also allows having multiple builds from the same source tree
> simultaneously.
>
> *It's not an indictment of the RTEMS use of GNU Autotools that you build
> out of the configured folder.  I am not sure why stating a truth may be
> offensive?*
>

I'm not trying to be offensive.  Sorry if it came across that way.

FWIW RTEMS after the 5 branch does not use autotools anyway.

>
>
> *It was never a touchy point I was making, it was that for the purposes of
> debugging you can't use the online advice that people suggest to fix RTEMS
> configuration problems because the "build setup"*
>
> *(configuring in one folder, bulding targets in another) is not the
> TYPICAL way OTHERS use the GNU Autotools. So file finding in PATH searching
> works with different options.*
>
>
>>
>> Most GNU autotools projects configure IN THE FOLDER that they want to
>> compile and archive source code.  That's one reason why the problems of
>> diagnosing RTEMS build configurations are harder.
>>
>
> This is not required for autotools. It is just the default instructions.
>
> * When I read this I first thought I was talking to Richard Stallman.
> (LOL)*
>
>>
>> Setting explicit file locations with absolute directories is a way to
>> workaround the problems.
>>
>>
>> Cheers!
>>
>> Daemondave on github
>>
>> Check out my new book  Untrapped Value on LeanPub:
>> https://leanpub.com/untrappedvalue
>>
>
>
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: How can I add LDFLAGS for bsp build?

[Joel Sherrill]

On Fri, Jul 22, 2022 at 10:12 AM DAVE ERICKSON  wrote:

>  Thanks for stepping on my point, Joel.  :)
>

Sorry if I said something that contradicted you.

>
> ( I attended the RTEMS Open course instructed by Joel many years ago...  )
>

Thanks. :)


>
> Joel's comments on
>
> CFLAGS += -Og -g -Wall
> CXXFLAGS +=  -Og -g -Wall
>
> will NOT solve your gcc "can't find library problem" since these are
> tangential to your problem and are compiler flags. Compiler flags don't
> affect linking which is the stage where gcc/ar/ld programs create the code
> archive.
>
> If you want to express exactly which library to use then specify in the
> LDFLAGS environment variable  in the folder where gcc is configured to
> "build from" in   bsps/arm/tms570/config/xxx.cfg
>
> LDFLAGS += ~/ ...rest of explicit path... /arm-rtems5/lib/libm.a
>
> (NOTICE NO FLAG PREFIX ON EXPLICIT PATH)
>

libm.a should be implicitly along the search path. If it isn't, then
something isn't right with the tool chain.

Test case based on /tmp/t.c with the sparvc/leon3 bsp on the master:


int main(void)
{
  return 0;
}
===

===
BSPDIR=/home/joel/rtems-work/tools/6/bsp-install/sparc-rtems6/leon3/
ABI_FLAGS=-mcpu=leon3
CFLAGS="-Og -g -Wall"

sparc-rtems6-gcc ${ABI_FLAGS} ${CFLAGS} \
  -B ${BSPDIR}/lib/ -qrtems t.c -o t \
  -lrtemsdefaultconfig -lm
===

Since t.c is a stub main(), there is no RTEMS configuration and you need
the  -lrtemsdefaultconfig.

-lm is in the same directory as libc.a and implicitly part of the library
search path. Every library provided by gcc, newlib, or RTEMS will be on the
search path.

If you follow the normal instructions for libbsd or lwip, they will be laid
into the BSP install directory and also available.


>
> Will instruct gcc/ar/ld to do exactly what you want, which is include
> EXACTLY that library at EXACTLY that location.
>

If you do it manually, you have to be careful to pick the right multilib
variant.

>
> The explicit library path can be used to check and see if it's a location
> problem before a library internals problem.
>
> nm -D   or nm to find the missing symbol inside a library.
>
>
> BTW  RTEMS uses GNU autotools differently in that it configures in one
> folder/directory and the builds targets into another folder is a very rare
> way of using autotools. I know this because I have downloaded and reviewed
> over 5000 open source projects for my new book.
>

Funny because the core GNU tools like gcc, binutils, gdb plus newlib all
allow out of tree builds.

It may be rare to use it this way but it works and leaves your source
directory with no build artifacts.

It also allows having multiple builds from the same source tree
simultaneously.


>
> Most GNU autotools projects configure IN THE FOLDER that they want to
> compile and archive source code.  That's one reason why the problems of
> diagnosing RTEMS build configurations are harder.
>

This is not required for autotools. It is just the default instructions.

>
> Setting explicit file locations with absolute directories is a way to
> workaround the problems.
>
>
> Cheers!
>
> Daemondave on github
>
> Check out my new book  Untrapped Value on LeanPub:
> https://leanpub.com/untrappedvalue
>
>
>
>
> --
> *From: *"Joel Sherrill" 
> *To: *"DAVE ERICKSON" 
> *Cc: *"Y. HB" , "rtems-us...@rtems.org" <
> users@rtems.org>
> *Sent: *Friday, July 22, 2022 8:42:49 AM
> *Subject: *Re: How can I add LDFLAGS for bsp build?
>
> This is an application matter and it all depends on what build system you
> are using.
> If your build system is make, then something like this will probably work.
>
> LDFLAGS += -lm
>
> You may also want to ensure that the CFLAGS has the desired optimization,
> debug, and warning levels selected:
>
> CFLAGS += -Og -g -Wall
> CXXFLAGS +=  -Og -g -Wall
>
> If using waf, cmake, etc, etc, you ultimately want to produce the same
> invocations of gcc but the mechanics are different.
>
> --joel
>
> On Fri, Jul 22, 2022 at 9:09 AM DAVE ERICKSON 
> wrote:
>
>> Hi Y.HB
>>
>> LDFLAGS sets both the library kind to include in the archive build but it
>> also uses the -L flags to know where to look for it. The -lm can mean the
>> libm.a. libm.so libm.la so it searches the LD_LIBRARY_PATH environment
>> variable to find one that fits. If you want expressly to include the libm.a
>> you should specify it instead of -lm. The first thing I recommend is find
>> the symbols inside the Makefile configured for the .  Look for the LDFLAGS
>> and then your LD_LIBRA

Re: How can I add LDFLAGS for bsp build?

[Joel Sherrill]

This is an application matter and it all depends on what build system you
are using.

If your build system is make, then something like this will probably work.

LDFLAGS += -lm

You may also want to ensure that the CFLAGS has the desired optimization,
debug, and warning levels selected:

CFLAGS += -Og -g -Wall
CXXFLAGS +=  -Og -g -Wall

If using waf, cmake, etc, etc, you ultimately want to produce the same
invocations of gcc but the mechanics are different.

--joel

On Fri, Jul 22, 2022 at 9:09 AM DAVE ERICKSON  wrote:

> Hi Y.HB
>
> LDFLAGS sets both the library kind to include in the archive build but it
> also uses the -L flags to know where to look for it. The -lm can mean the
> libm.a. libm.so libm.la so it searches the LD_LIBRARY_PATH environment
> variable to find one that fits. If you want expressly to include the libm.a
> you should specify it instead of -lm. The first thing I recommend is find
> the symbols inside the Makefile configured for the .  Look for the LDFLAGS
> and then your LD_LIBRARY_PATH to see if it matches where that
> arm-rtems5/lib/libm.a is.
>
> You can even use the flag argument:  arm-rtems5/lib/libm.a or
> ./arm-rtems5/lib/libm.a to express the precise library and location to use.
>
> This is one important distinction that many people confuse about how
> automake and autoconf work: There is no "internal logic" in the autotools
> way of creating recipes for Makefiles. m4 is used for pattern processing.
> You must express what you want it to make, it won't go looking anywhere
> else than what is specified.
>
> It's not cmake, scons, or raw make. GNU Autotools creates recipe files,
> like config.status, that just hold environmental variables.
>
> DaemonDave on github.
>
> --
> *From: *"Y. HB" 
> *To: *"rtems-us...@rtems.org" 
> *Sent: *Friday, July 22, 2022 12:11:38 AM
> *Subject: *Re: How can I add LDFLAGS for bsp build?
>
> I added -lm in LDFLAGS in my custom bsps/arm/tms570/config/xxx.cfg
>
> the flag is added to compiling arguments, but it still reported undefined
> reference to 'floor', but I see there is floor symbols in the
> arm-rtems5/lib/libm.a
>
> Why is it?
>
> Thanks
>
> On Fri, Jul 22, 2022 at 1:43 PM Y. HB  wrote:
>
>> Hello
>>
>> I'm working on a custom tms570 bsp upon RTEMS 5.1, but it depends on math
>> lib (-lm), how can I add this flag to the bsp build?
>>
>> Shall I add LDFLAGS="-lm" during configure or shall I change some
>> variables in c/src/lib/libbsp/arm//Makefile.am?
>>
>> Thanks
>>
>
> ___
> 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: [Introduction] [GSoC Participant]

[Joel Sherrill]

I was cleaning out tabs since I had too many open and came across
this link which might have low level code that is useful:

https://github.com/isometimes/rpi4-osdev/

It is under Creative Commons CC0 license which should make it perfectly
acceptable to leverage code from this in the BSP.

After making sure your board runs Linux and works OK, it might be
a good idea to try to run at least through their bare metal hello world
exercise. From that hello world, you should be in good shape to get
an RTEMS hello world working.

I didn't go through all the code but at least that gives you a working
example that boots and prints to the uart and frame buffer. I have
what, if anything else, would be useful from there.

--joel

On Wed, May 25, 2022 at 10:30 PM Noor Aman  wrote:

> Hello Everyone, I'm Mohd Noor Aman from Delhi, India, an active GSoC
> participant 2022.
> My project is : Port AArch64 RTEMS for Raspberry pi 4b.
> My mentors are: Kinsey Moore, Alan Cudmore and Hesham Almatary.
>
> My discord handle is : katana-flinger#0608
> my github handle : 0xNoor
>
> I'm hoping to get along with this community and do well with the project.
> regards,
> Mohd Noor Aman
> ___
> 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: Building newly for 6/rtems-arm blows on compiling iOS_failure.cc

[Joel Sherrill]

On Wed, May 25, 2022, 3:30 PM Mr. Andrei Chichak  wrote:

> Yes, I noticed it was not clang but gcc that was complaining about
> --->  <—— that long after I hit send. I was hoping for your forgiveness.
>
> I went into /Users/andreichichak/quick-start/src/rsb and did a find .
> -name ctype_inline.h
> I love being able to cut/paste between computers.
>

Hmm.. we've seen cases where l building libbsd after an install of libbsd
can sometimes fail because the installed headers are not the right ones for
the cloned source. I wonder if building gcc and libraries can do the same
thing.

--joel

>
> Giving:
>
>
> ./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/gnu-mirror-gcc-197b7ac/libstdc++-v3/config/os/bionic/ctype_inline.h
>
> ./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/gnu-mirror-gcc-197b7ac/libstdc++-v3/config/os/qnx/qnx6.1/ctype_inline.h
>
> ./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/gnu-mirror-gcc-197b7ac/libstdc++-v3/config/os/vxworks/ctype_inline.h
>
> ./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/gnu-mirror-gcc-197b7ac/libstdc++-v3/config/os/uclibc/ctype_inline.h
>
> ./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/gnu-mirror-gcc-197b7ac/libstdc++-v3/config/os/djgpp/ctype_inline.h
>
> ./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/gnu-mirror-gcc-197b7ac/libstdc++-v3/config/os/hpux/ctype_inline.h
>
> ./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/gnu-mirror-gcc-197b7ac/libstdc++-v3/config/os/newlib/ctype_inline.h
>
> ./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/gnu-mirror-gcc-197b7ac/libstdc++-v3/config/os/bsd/dragonfly/ctype_inline.h
>
> ./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/gnu-mirror-gcc-197b7ac/libstdc++-v3/config/os/bsd/netbsd/ctype_inline.h
>
> ./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/gnu-mirror-gcc-197b7ac/libstdc++-v3/config/os/bsd/freebsd/ctype_inline.h
>
> ./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/gnu-mirror-gcc-197b7ac/libstdc++-v3/config/os/bsd/openbsd/ctype_inline.h
>
> ./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/gnu-mirror-gcc-197b7ac/libstdc++-v3/config/os/bsd/darwin/ctype_inline.h
>
> ./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/gnu-mirror-gcc-197b7ac/libstdc++-v3/config/os/mingw32/ctype_inline.h
>
> ./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/gnu-mirror-gcc-197b7ac/libstdc++-v3/config/os/gnu-linux/ctype_inline.h
>
> ./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/gnu-mirror-gcc-197b7ac/libstdc++-v3/config/os/generic/ctype_inline.h
>
> ./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/gnu-mirror-gcc-197b7ac/libstdc++-v3/config/os/solaris/ctype_inline.h
>
> ./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/gnu-mirror-gcc-197b7ac/libstdc++-v3/config/os/tpf/ctype_inline.h
>
> ./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/gnu-mirror-gcc-197b7ac/libstdc++-v3/config/os/mingw32-w64/ctype_inline.h
>
> ./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/gnu-mirror-gcc-197b7ac/libstdc++-v3/config/os/aix/ctype_inline.h
> ./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/build/arm-rtems6/armv5te+fp/hard/libstdc++-v3/include/arm-rtems6/bits/ctype_inline.h
> <—— this one
>
> ./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/build/arm-rtems6/thumb/armv7-r+fp/hard/libstdc++-v3/include/arm-rtems6/bits/ctype_inline.h
>
> ./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/build/arm-rtems6/thumb/cortex-m7/hard/libstdc++-v3/include/arm-rtems6/bits/ctype_inline.h
>
> ./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/build/arm-rtems6/thumb/libstdc++-v3/include/arm-rtems6/bits/ctype_inline.h
>
> ./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/build/arm-rtems6/thumb/armv7-r/libstdc++-v3/include/arm-rtems6/bits/ctype_inline.h
>
> ./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/build/arm-rtems6/thumb/cortex-r52/hard/libstdc++-v3/include/arm-rtems6/bits/ctype_inline.h
>
> ./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/build/arm-rtems6/thumb/armv7-a/libstdc++-v3/include/arm-rtems6/bits/ctype_inline.h
>
> ./rtems/build/arm-rtems6-gcc-197b7ac-newlib-64b2081-x86_64-apple-darwin18.7.0-1/build/arm-rtems6/thumb/armv6-m/libstdc++-v3/include/arm-rtems6/bits/ctype_inline.h
>
> 

Re: RTEMS 5 on mcp750 fails

[Joel Sherrill]

On Sat, May 21, 2022, 11:02 AM Miroslaw Dach 
wrote:

> Hi Hainz,
>
> Thanks for the indication. I have exactly found this setting and am going
> to reduce
> CONFIGURE_EXTRA_TASK_STACKS which is currently setup by default in EPICS
> to 32MB.
> The mcp750 has just 32MB so it is no wonder that it does not work.
>

If it is configured for unified workspace, you wouldn't specify extra
stacks and this wouldn't have been tripped.

Unified and unlimited can avoid some issues.

--joel

>
> I will test the new configuration next week.
> Have a nice weekend
> Best Regards
> Mirek
>
>
> sob., 21 maj 2022 o 05:39 Heinz Junkes 
> napisał(a):
>
>> Hi Mirek,
>> You can find the configuration of the RTEMS at EPICS here:
>>
>> epics-base/modules/libcom/RTEMS/posix/rtems_config.c
>>
>> There for example
>> ...
>> #define CONFIGURE_EXTRA_TASK_STACKS (4000 *
>> RTEMS_MINIMUM_STACK_SIZE)
>>
>> #define CONFIGURE_UNLIMITED_ALLOCATION_SIZE 32
>> #define CONFIGURE_UNLIMITED_OBJECTS
>> #define CONFIGURE_UNIFIED_WORK_AREAS
>> …
>>
>> best regards,
>> Heinz
>>
>> > On 21. May 2022, at 00:21, Joel Sherrill  wrote:
>> >
>> > On Fri, May 20, 2022 at 3:55 PM Miroslaw Dach 
>> > wrote:
>> >
>> >> Hi Chris,
>> >>
>> >> Thank you very much for your expertise and attached links which are
>> very
>> >> helpful.
>> >> As regards the INTERNAL_ERROR_TOO_LITTLE_WORKSPACE error message:
>> >> Is it possible to determine with some debug information what is the
>> >> foreseen by RTEMS WORKSPACE size?
>> >>
>> >
>> > This CONFIGURE_MEMORY_OVERHEAD is there as a mechanism to toss
>> > extra memory at the workspace in case confdefs.h makes a mistake. I
>> think
>> > this
>> > is more likely to be something else like a misconfigured system. But
>> adding
>> > this
>> > to your RTEMS configuration with some chunk of memory like 128K might
>> > allow this to proceed. But if it is a memory allocation error in the BSP
>> > like
>> > not assigning memory right to RTEMS, this won't fix it. See:
>> >
>> >
>> https://docs.rtems.org/branches/master/c-user/config/general.html#configure-memory-overhead
>> >
>> > Chris has touched one of the boards in the motorola_powerpc family
>> > more recently than I have. I would think this would work unless
>> something
>> > is off in the EPICS configuration of RTEMS. There was a discussion of
>> the
>> > EPICS RTEMS configuration with Till recently on tech-talk and I thought
>> > it looked ok.
>> >
>> > --joel
>> >
>> >>
>> >> Best Regards
>> >> Mirek
>> >>
>> >> śr., 18 maj 2022 o 00:53 Chris Johns  napisał(a):
>> >>
>> >>> 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 hard

Re: Fwd: RTEMS 5 on mcp750 fails

[Joel Sherrill]

On Fri, May 20, 2022 at 3:55 PM Miroslaw Dach 
wrote:

> Hi Chris,
>
> Thank you very much for your expertise and attached links which are very
> helpful.
> As regards the INTERNAL_ERROR_TOO_LITTLE_WORKSPACE error message:
> Is it  possible to determine with some debug information what is the
> foreseen by RTEMS WORKSPACE size?
>

 This CONFIGURE_MEMORY_OVERHEAD is there as a mechanism to toss
extra memory at the workspace in case confdefs.h makes a mistake. I think
this
is more likely to be something else like a misconfigured system. But adding
this
to your RTEMS configuration with some chunk of memory like 128K might
allow this to proceed. But if it is a memory allocation error in the BSP
like
not assigning memory right to RTEMS, this won't fix it. See:

https://docs.rtems.org/branches/master/c-user/config/general.html#configure-memory-overhead

Chris has touched one of the boards in the motorola_powerpc family
more recently than I have. I would think this would work unless something
is off in the EPICS configuration of RTEMS. There was a discussion of the
EPICS RTEMS configuration with Till recently on tech-talk and I thought
it looked ok.

--joel

>
> Best Regards
> Mirek
>
> śr., 18 maj 2022 o 00:53 Chris Johns  napisał(a):
>
> > 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
___
users mailing list
users@rtems.org

Re: Windows as a RTEMS dev environment

[Joel Sherrill]

On Fri, Apr 15, 2022 at 1:21 PM zhengxiaojun  wrote:

> Hi,
>
> ok, https://devel.rtems.org/ticket/4547
> 
>
> Mingw64 has a pre-compiled dtc package, you can bypass the compilation.
>

That's good to know. That means we have two possible solutions:

(1) Disable dtc in RSB for mingw64. Possible downside on version
incompatibility

(2) Figure out what they did to build it and mirror that patch into the RSB
recipe.
https://packages.msys2.org/package/dtc?repo=msys=x86_64 appears to
be
the package so perhaps the answer is in there.

An easy workaround is to comment out dtc in rtems-default.bset and load the
mingw package.

Thanks for the info.

--joel


> Bit of a mess. Lets try again with Ubuntu, after that AIX !
> 
> On Fri, 15 Apr 2022 at 13:14, Matthew J Fletcher 
> wrote:
> 
>  As an update with Mingw64 i had to manually create
> x86_64-w64-mingw32-g++
>  and x86_64-w64-mingw32-gcc (just copy  paste of g++ and
> gcc), now it can
>  find all the tools, no idea how the tools RSB is looking for
> would be
>  created.
> 
>  Oddly even with Mingw64 the "convert-dtsv0-lexer.l:27:10: fatal
> error:
>  fnmatch.h: No such file or directory" issue is still there, and
> its not
>  actually present,.. will probably just end up install all of Mingw
> 
>  Looking at the RSB logs, it looks like the include paths
> generated are
>  pretty messed up "
> 
> -I/c/Users/MatthewFletcher/play/src/rsb/rtems/build/tmp/sb-197609/6s/c/Users/MatthewFletcher/play/rtems/6/include
>  ' "
> 
> 
>  On Fri, 15 Apr 2022 at 12:29, Matthew J Fletcher <
> ami...@gmail.com> wrote:
> 
>  Hi,
> 
>  To make Joel happy with a patch i've been trying to setup a
> Windows VM as
>  a build environment, the process seems to have a few issues.
> 
>  1) If your username/profile has a space in it the scripts
> dont all
>  encapsulate with quotes so break in various ways. Ok, so,
> created a new
>  user to get around that.
> 
>  2) Getting a native build environment msys2, mingw64, etc
> setup seems
>  pretty random. Tried mingw64 first but makeinfo and some
> other tools not
>  available, ok, so moved to msys2. Dependency checks now pass
> but rsb
>  builder fails on first package DTC.
> 
>  convert-dtsv0-lexer.l:27:10: fatal error: fnmatch.h: No such
> file or
>  directory
>  Its clearly present at C:\msys64\usr\include\fnmatch.h
> 
>  RSB looks to have issues, not surprising given the million
> possible
>  windows setups.
> 
>  Does anyone have a known working setup on Windows ?
> 
> 
>  regards
>  ---
>  Matthew J Fletcher
> 
> 
> 
>  --
> 
>  regards
>  ---
>  Matthew J Fletcher
> 
> 
> 
> --
> 
> regards
> ---
> Matthew J Fletcher
> ___
> users mailing list
> users@rtems.org
> http://lists.rtems.org/mailman/listinfo/users ami...@gmail.com>
> ___
> 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: Windows as a RTEMS dev environment

[Joel Sherrill]

On Fri, Apr 15, 2022 at 7:38 AM Matthew J Fletcher  wrote:

> ok, https://devel.rtems.org/ticket/4547


dtc on windows is clearly not cared about by the Linux focused people who
developed and maintain it. For RTEMS, the best solution might be to disable
building it on msys/mingw. I think I had Ryan comment it out by hand the
last time he did a test build on msys/mingw. If you google this, you will
see
others not using RTEMS with similar issues.

Spaces in users names. I'll add that to the spaces in paths on the warnings
slide for the RTEMS Class. There are lots of things which can bite you which
are obvious in hindsight.

One of the most insidious is having a variable like LIB which is used in
build environments be set for MSVC. That will break a build pretty
weirdly also.

>
>
> Bit of a mess. Lets try again with Ubuntu, after that AIX !
>

Ubuntu will likely just be getting the required host packages installed.

AIX would be interesting. It still boils down to getting the required host
packages but there might be a wrinkle on that host. :)

--joel

>
> On Fri, 15 Apr 2022 at 13:14, Matthew J Fletcher  wrote:
>
> > As an update with Mingw64 i had to manually create x86_64-w64-mingw32-g++
> > and x86_64-w64-mingw32-gcc (just copy & paste of g++ and gcc), now it can
> > find all the tools, no idea how the tools RSB is looking for would be
> > created.
> >
> > Oddly even with Mingw64 the "convert-dtsv0-lexer.l:27:10: fatal error:
> > fnmatch.h: No such file or directory" issue is still there, and its not
> > actually present,.. will probably just end up install all of Mingw
> >
> > Looking at the RSB logs, it looks like the include paths generated are
> > pretty messed up "
> >
> -I/c/Users/MatthewFletcher/play/src/rsb/rtems/build/tmp/sb-197609/6s/c/Users/MatthewFletcher/play/rtems/6/include
> > ' "
> >
> >
> > On Fri, 15 Apr 2022 at 12:29, Matthew J Fletcher 
> wrote:
> >
> >> Hi,
> >>
> >> To make Joel happy with a patch i've been trying to setup a Windows VM
> as
> >> a build environment, the process seems to have a few issues.
> >>
> >> 1) If your username/profile has a space in it the scripts dont all
> >> encapsulate with quotes so break in various ways. Ok, so, created a new
> >> user to get around that.
> >>
> >> 2) Getting a native build environment msys2, mingw64, etc setup seems
> >> pretty random. Tried mingw64 first but makeinfo and some other tools not
> >> available, ok, so moved to msys2. Dependency checks now pass but rsb
> >> builder fails on first package DTC.
> >>
> >> convert-dtsv0-lexer.l:27:10: fatal error: fnmatch.h: No such file or
> >> directory
> >> Its clearly present at C:\msys64\usr\include\fnmatch.h
> >>
> >> RSB looks to have issues, not surprising given the million possible
> >> windows setups.
> >>
> >> Does anyone have a known working setup on Windows ?
> >>
> >>
> >> regards
> >> ---
> >> Matthew J Fletcher
> >>
> >>
> >
> > --
> >
> > regards
> > ---
> > Matthew J Fletcher
> >
> >
>
> --
>
> regards
> ---
> Matthew J Fletcher
> ___
> 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: wkspace failed allocations with heap protection enabled

[Joel Sherrill]

On Wed, Apr 13, 2022 at 10:51 AM Matthew J Fletcher 
wrote:

> Hi Joel,
>
> Works fine without debug, its the deferred free doing _Heap_Allocate with
> the negative size thats causing it.
>

Glad that workaround gets you by it. Please do file a ticket though. :)

--joel

>
>
> On Wed, 13 Apr 2022 at 16:09, Joel Sherrill  wrote:
>
>> This appears to be a bad side-effect of the way the deferred free is
>> implemented
>> when the memory protection/fence is enabled. This is turned on by
>> enabling
>> rtems debug.
>>
>> I'd recommend filing a ticket and assigning it to Sebastian for a real
>> fix.
>>
>> In the meantime, see if building RTEMS without debug enabled helps.
>>
>> --joel
>>
>> On Wed, Apr 13, 2022 at 4:30 AM Matthew J Fletcher 
>> wrote:
>>
>>> Hi,
>>>
>>> Investigating the "Total number of failed allocations:" from the
>>> wkspace cmd i see that;
>>>
>>> /* Statistics */
>>> ++stats->failed_allocs;
>>>
>>> Are incremented when _Heap_Allocate_aligned_with_boundary fails, however
>>> it
>>> seems this will routinely fail due to;
>>>
>>> _Heap_Protection_free_all_delayed_blocks seemingly on purpose creating an
>>> impossibly large allocation.
>>>
>>> uintptr_t large = 0
>>>   - (uintptr_t) HEAP_BLOCK_HEADER_SIZE
>>>   - (uintptr_t) HEAP_ALLOC_BONUS
>>>   - (uintptr_t) 1;
>>>
>>> void *p = _Heap_Allocate( heap, large );
>>>
>>> This makes it difficult to place a breakpoint on failed_allocs to
>>> investigate true low memory situations with heap protection enabled.
>>>
>>>
>>> regards
>>> ---
>>> Matthew J Fletcher
>>> ___
>>> users mailing list
>>> users@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/users
>>>
>>
>
> --
>
> regards
> ---
> Matthew J Fletcher
>
>
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: wkspace failed allocations with heap protection enabled

[Joel Sherrill]

This appears to be a bad side-effect of the way the deferred free is
implemented
when the memory protection/fence is enabled. This is turned on by enabling
rtems debug.

I'd recommend filing a ticket and assigning it to Sebastian for a real fix.

In the meantime, see if building RTEMS without debug enabled helps.

--joel

On Wed, Apr 13, 2022 at 4:30 AM Matthew J Fletcher  wrote:

> Hi,
>
> Investigating the "Total number of failed allocations:" from the
> wkspace cmd i see that;
>
> /* Statistics */
> ++stats->failed_allocs;
>
> Are incremented when _Heap_Allocate_aligned_with_boundary fails, however it
> seems this will routinely fail due to;
>
> _Heap_Protection_free_all_delayed_blocks seemingly on purpose creating an
> impossibly large allocation.
>
> uintptr_t large = 0
>   - (uintptr_t) HEAP_BLOCK_HEADER_SIZE
>   - (uintptr_t) HEAP_ALLOC_BONUS
>   - (uintptr_t) 1;
>
> void *p = _Heap_Allocate( heap, large );
>
> This makes it difficult to place a breakpoint on failed_allocs to
> investigate true low memory situations with heap protection enabled.
>
>
> regards
> ---
> Matthew J Fletcher
> ___
> 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: get_heap_info memsets stats element

[Joel Sherrill]

On Wed, Apr 13, 2022 at 8:32 AM Matthew J Fletcher  wrote:

> Hi,
>
> _Heap_Get_information provides the information but its then memset after
> retrieval, is this a bug or design ?
>
>   _Heap_Get_information(heap, info);
>   memset(>Stats, 0, sizeof(info->Stats));
>

In this case, this call is in support of resource snapshot. This is used in
tests
to ensure the number of objects/allocations is the same before and after a
test case is executed. It verifies no leaks.

The stats section has the number of calls, maximum memory allocated, etc.
and
would legitimately change. By zero'ing it out, it makes it possible to
compare
the before and after versions.

Would be good to have a comment here explaining that. Patch welcome. :_

--joel

>
> --
>
> regards
> ---
> Matthew J Fletcher
> ___
> 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: RTEMS support

[Joel Sherrill]

On Tue, Mar 29, 2022, 8:28 PM Steven White  wrote:

> Is there a support group that answers questions about the installation and
> usage of RTEMS?
>

There's here and the Discord chat.

--joel

Thanks,Steve
> ___
> 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: Split BSP in RTEMS 4.11 - autotools newbie question

[Joel Sherrill]

On Mon, Mar 14, 2022 at 7:37 AM Dariusz.sabala  wrote:

> Hello
>
> I am developing SAMRH71 BSP in RTEMS 4.11, I started editing atsam BSP and
> accomplished some success, but the decision was made to support both BSP
> (atsam and samrh71) in separate folders. I reverted my changes, copied and
> renamed atsam folder to samrh71 and tried to build this renamed BSP, but
> unfortunately nothing is being built - make just enters the folder and
> leaves it with no artifact build
>
> make[1]: Entering directory
> '/home/dsa/projects/p1/repo/rtems/samrh71/arm-rtems4.11/c'
> Making all in .
> make[2]: Entering directory
> '/home/dsa/projects/p1/repo/rtems/samrh71/arm-rtems4.11/c'
> make[2]: Nothing to be done for 'all-am'.
>
> Can you give me advice on what and where to change in the buildsystem to
> make it build? Honestly I am cmake kid :) and knowing that autotools is no
> longer supported in the newest RTEMS does not encourage learning this
> powerful but complex tool.
>

Assuming there aren't any mistakes lurking. :)

>From the top directory:

bootstrap -c
bootstrap -p
bootstrap

When you add, move, and delete directories, it is possible that the
generated fragments which include lists of BSPs could get out of sync.

Overall, I'd recommend you move to 6.

--joel


>
> Best regards
> dsa
> ___
> 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

RTEMS Accepted in Google Summer of Code 2022

[Joel Sherrill]

Hi

I am pleased to be able to announce that the RTEMS Project has been
accepted into the 2022 Edition of the Google Summer of Code (
https://summerofcode.withgoogle.com/).

There are a few changes this year which everyone should be made aware of
that are discussed at
https://opensource.googleblog.com/2021/11/expanding-google-summer-of-code-in-2022.html
:

+ Participants do not have to be students. They only have to be new to open
source.

+ Projects can now be large or small.

+ There is some flexibility in the timeline

We use our ticketing system to track potential projects. There are keywords
like SoC, small, large, kernel, ecosystem, BSPs, etc. These are used to
generate our Open Projects page (
https://devel.rtems.org/wiki/Developer/OpenProjects). If you have a project
idea, feel free to put it in Trac.

Mentors are always needed and appreciated. You don't have to be an RTEMS
expert to be helpful to a student. Often just being a regular RTEMS user
who has already done some work is enough to be able to help someone newer.
Also you may have experience in some domain or with some hardware that does
make you the right person to mentor. Please let myself or Gedare know if
you want to mentor or just have questions.

But, of course, this would not work without students and new contributors.
Please recruit those who might enjoy a GSoC project.

Thanks.

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

RTEMS Open Class (virtual) April 25-29

[Joel Sherrill]

Hi

There will be an RTEMS Open Class held virtually the week of April 25-29.
Times each day will be based on the US Central time zone (Chicago).
Adjustments
may be considered to accommodate the participants.

April 25  - Kick Start and Getting Started
April 26-29 - Open Class

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

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

Thanks.

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

Re: Testing SMP Configuration with rtems-test

[Joel Sherrill]

On Sat, Feb 19, 2022, 7:48 AM Jiri Gaisler  wrote:

> You should add -m 4 to the bsp_run_opts in the leon3-sis-cov.ini file,
> which is in
>
> /opt/rtems/6/share/rtems/tester/rtems/testing/bsps/leon3-sis-cov.ini
>
> (or similar depending on where you installed RBS).
>

Alex.. did you ever work with SMP configurations when you were improving
the coverage reports?

--joel


> Jiri.
>
> On 2022-02-19 09:26, Jerzy J wrote:
> > Hi,
> >
> > I've been trying to get some coverage reports on my tests. I'm using
> RTEMS
> > 6 and gr712rc/leon3 bsps.
> >
> > Normally I run my tests using:
> > `./sparc-rtems6-sis -leon3 -r s -m 4
> >
> $HOME/RTEMS/src/rtems/build/sparc/gr712rc/testsuites/validation/ts-model-barrier-mgr-0.exe`
> > , where I can specify `-m 4`.
> >
> > However when using rtems-test:
> > `./rtems-test --rtems-tools=$HOME/RTEMS/rtems/6 --log=log_leon3_sis
> > --rtems-bsp=leon3-sis-cov --coverage
> >
> ~/RTEMS/src/rtems/build/sparc/gr712rc/testsuites/validation/ts-model-barrier-mgr-0.exe
> > `
> > My tests fail, since as I can see in the log it runs:
> > `=>  exe: /home/yoman/RTEMS/rtems/6/bin/sparc-rtems6-sis -leon3 -nouartrx
> > -r -tlim 200 s -cov
> >
> /home/yoman/RTEMS/src/rtems/build/sparc/gr712rc/testsuites/validation/ts-model-barrier-mgr-0.exe`
> > resulting in only 1 cpu online.
> >
> > Is there a way I can pass `-m 4` into rtems-test or is there some extra
> > configuration step I'm probably not aware of that handles this?
> >
> > My 'config.ini' file:
> > `[sparc/gr712rc]
> > RTEMS_SMP = True
> > BUILD_TESTS = True`
> >
> > Thank you in advance and all the best!
> > Jerzy
> > ___
> > 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

Flight Software Workshop Agenda Posted

[Joel Sherrill]

Hi

The Flight Software Workshop is next week and the agenda has been
posted. This is a virtual event and you should still be able to
register. See https://lnkd.in/eTpFc8RA

Ignoring interesting keynotes and project presentations, there are two
presentations on the ESA pre-qualification effort and RTEMS state of
the world which should be of interest to the community.

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

Re: Barrier Manager cross-node behaviour

[Joel Sherrill]

On Fri, Jan 28, 2022, 7:15 AM Jerzy J  wrote:

> Hi Joel,
>
> Thank you for your help and clarification, this is exactly what i needed!
>
> In terms of submitting this to the community, the situation is exactly as
> mentioned by Andrew.
>

Thanks for the info Andrew. My long term concern with the qualification
work, particularly the process of modifying rtems-central and generating
content for RTEMS.git, needs to be made familiar to the community.

We need to make sure that the software engineering or users guide covers
all of this.  It may even be a good idea to have some video presentations
that are recorded and put on YouTube.

The formal verification material is even harder but basically the same
process. There should be community instructions for taking formal
verification and modifying and or checking it.

In both cases, that doesn't make skills required to actually update it any
easier but the process should be well documented and easily repeatable with
a known set of tools. And those tools should be acquirable reliably.

>
> >If that statement and any others like it were deleted,
> >would this issue go away?
>
> I think if it's consistent and either doesn't mention nodes at all or does
> so on all of the directives it would definitely be more clear!
>

Overnight, I realized that I should probably grep for the word node in the
users guide and ensure it is only used in the right sections. No point in
relying on eithe one of us to read that he entire thing. ;)

>
> >Please point out all the places where the barrier documentation
> >uses language from a distributed multiprocessing and shouldn't.
>
> As far as I'm aware, I've only seen nodes mentioned in Classic API Guide,
> in Barrier Manager Directives section:
> -
> https://docs.rtems.org/branches/master/c-user/barrier/directives.html#rtems-barrier-create
> -
> https://docs.rtems.org/branches/master/c-user/barrier/directives.html#rtems-barrier-ident
> -
> https://docs.rtems.org/branches/master/c-user/barrier/directives.html#rtems-barrier-delete
>

I'll fix at least that.

Thanks

--joel

>
> Hope that helps and all the best,
> Jerzy
>
> pt., 28 sty 2022 o 12:00 andrew.butterfi...@scss.tcd.ie <
> andrew.butterfi...@scss.tcd.ie> napisał(a):
>
>> Hi Joel,
>>   Jerzy is doing a Dissertation on this topic, and we have every plan to
>> feed this back into the community. The is an academic spin-off from the ESA
>> sponsored activity that ran for the last two years or so.
>>
>> I know that the precise way we integrate this stuff back into the
>> community needs to be figured out, and discussion is underway about aspects
>> of this on the devel mailing list.
>>
>> Sebastian and I hope to come to you all with a proposal regarding the
>> Formal Methods part - I'll let him lead that as he has a better feel for
>> what would fit best with community guidelines.
>>
>> 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: users  on behalf of Joel Sherrill <
>> j...@rtems.org>
>> Reply to: "j...@rtems.org" 
>> Date: Thursday 27 January 2022 at 23:39
>> To: Jerzy J 
>> Cc: "rtems-us...@rtems.org" 
>> Subject: Re: Barrier Manager cross-node behaviour
>>
>> On Thu, Jan 27, 2022 at 5:04 PM Jerzy J 
>> wrote:
>> >
>> > Hi,
>> >
>> > I'm using RTEMS 6 and I'm trying to model the Barrier Manager
>> behaviour
>> > using Promela.
>>
>> Cool! Have you modeled anything else? Is this something which could be
>> submitted to the community and used openly?
>>
>> Just thinking anything that grows formal verification for RTEMS
>> hopefully
>> helps if there is the potential for more input. Not that I am likely
>> the one to
>> build the formal model.
>>
>> > However, there's one unclear thing to me which I couldn't find an
>> exact
>> > explanation of in the documentation.
>> >
>> > While the `rtems_barrier_ident` directive can only search on the
>> local
>> > node, if a task already had an id of the barrier f

Re: Barrier Manager cross-node behaviour

[Joel Sherrill]

On Thu, Jan 27, 2022 at 5:04 PM Jerzy J  wrote:
>
> Hi,
>
> I'm using RTEMS 6 and I'm trying to model the Barrier Manager behaviour
> using Promela.

Cool! Have you modeled anything else? Is this something which could be
submitted to the community and used openly?

Just thinking anything that grows formal verification for RTEMS hopefully
helps if there is the potential for more input. Not that I am likely the one to
build the formal model.

> However, there's one unclear thing to me which I couldn't find an exact
> explanation of in the documentation.
>
> While the `rtems_barrier_ident` directive can only search on the local
> node, if a task already had an id of the barrier from a different node,
> would it be able to call the `rtems_barrier_wait` directive on that
> barrier, or would it get INVALID_ID return code?
> In other words, can a task from one node, call directives on a barrier from
> another node if it had an id of the barrier?

The concept of node only applies when RTEMS is built for
distributed multiprocessing. This is completely different from
the SMP support.

For distributed multiprocessing, the system model is multiple
CPUs cards on a shared bus like VMEbus with an area
of shared memory. In a distributed multiprocessing configuration,
each node is a complete RTEMS executable with an assigned
node number in the system.

For SMP, the cores are tightly integrated, share a memory
image, etc. This is considered one "node".

There is no mixing of models.

With the distributed multiprocessing, a subset of Classic API
services allow an object instance to be created with global visibility.
If global, then the ident service can be used to look up the id
for a name. For example, a task can be global. If created on
node 1, a task on node 2 can change its priority.

I doubt you really care about the distributed multiprocessing
configuration but even if you did, barriers are local only and
can't be accessed by other nodes in a distributed
processing configuration.

> I would also assume that behaviour would be consistent for `delete` and
> `release` directives as well? Although it is mentioned in the `delete`
> directive constraints that only local tasks can delete a barrier, in other
> directives it is not listed as a constraint.

That is probably just an artifact of copying the starting point for
the documentation from another API class that did support
being global.

If that statement and any others like it were deleted,
would this issue go away?

Please point out all the places where the barrier documentation
uses language from a distributed multiprocessing and shouldn't.

Thanks.

--joel

> Thanks you in advance and all the best,
> Jerzy
> ___
> 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: RTEMS_FATAL_SOURCE_EXCEPTION during startup

[Joel Sherrill]

On Sat, Jan 1, 2022, 4:02 PM Петр Борисенко  wrote:

> Ok I see.
> The master branch is a bit ahead of my local one.
> And I really don't know what to think about these conflicts:
>

If this is applying a patch for an older version of RTEMS to the master,
the build system has changed

```
> # Conflicts:
> # bsps/arm/stm32f4/headers.am
>

Part of the old build system

>
> # bsps/arm/stm32f4/include/bsp/irq.h
>

Will have to be resolved.

# bsps/arm/stm32f4/start/bsp_specs
>

Gone now.

# c/src/lib/libbsp/arm/stm32f4/Makefile.am
>

Old build system.

> ```
> Has `arm/stm32f4` been eliminated from the main source tree?
>

It is still there. Under bsps/arm.

The changes to those.filea may have to be translated to the current master.

Andrei will be more familiar. I answering from my phone.


> Best regards.
> Peter Borisenko
> Awesome Technologies, Ltd.
> http://awsmtek.com
> hardw...@awsmtek.com
> +79062165482
>
>
> On Sun, Jan 2, 2022 at 12:13 AM  wrote:
>
>> I reported this, Set fixed it, and the report was closed.
>>
>> Either someone said “multilib, multilib, multilib” and it came back,
>> Peter needs to do a pull, or something has reverted.
>>
>> https://devel.rtems.org/ticket/4504
>>
>> A
>>
>> On 2022-January-01, at 13:56, Петр Борисенко  wrote:
>>
>> I didn't print anything explisitly.
>> Here is call stack:
>> ```
>> Thread #1 (Suspended : Signal : SIGINT:Interrupt)
>> output_char() at console-config.c:104 0x8007132
>> rtems_putc() at rtems_putc.c:31 0x800f038
>> _IO_Vprintf() at iovprintf.c:133 0x800b8b4
>> vprintk() at vprintk.c:31 0x8009aa0
>> printk() at printk.c:40 0x800794e
>> bsp_fatal_extension() at bspfatal-default.c:26 0x8006ea2
>> _User_extensions_Iterate() at userextiterate.c:181 0x800e686
>> _User_extensions_Fatal() at userextimpl.h:446 0x800b856
>> _Terminate() at interr.c:38 0x800b856
>> rtems_fatal() at fatal.h:158 0x80103a6
>> _ARM_Exception_default() at arm-exception-default.c:24 0x80103a6
>> () at 0xfff9
>> 0x0
>> ```
>>
>> Best regards.
>> Peter Borisenko
>> Awesome Technologies, Ltd.
>> http://awsmtek.com
>> hardw...@awsmtek.com
>> +79062165482
>>
>>
>> On Sat, Jan 1, 2022 at 7:09 PM Joel Sherrill  wrote:
>>
>>> Assuming it is compiled correctly, printing this early should be via
>>> printk().
>>>
>>> Can you attach gdb and just walk through the BSP initialisation?
>>>
>>> --joel
>>>
>>> On Sat, Jan 1, 2022, 2:08 AM  wrote:
>>>
>>> > (sorry, I accidentally sent this to the dev list instead of users. too
>>> > much cheer)
>>> >
>>> > It’s bombing in printf. It’s so early that the stack hasn’t been set up
>>> > yet, and it’s found an error and it’s trying to poot a message out on
>>> the
>>> > console, which is also not set up yet.
>>> >
>>> > Umm, what could be wrong? Lemme think… (I’ve worked wth this bsp in
>>> > RTEMS4.11, and a version in RTEMS5)
>>> >
>>> > I had problems with that BSP blowing up just like this because
>>> portions of
>>> > it weren’t compiled with the proper instruction set, and when the
>>> startup
>>> > code called memset (I think), it would call memset in newlib/libc that
>>> was
>>> > compiled for the wrong architecture, do the wrong thing, end up in
>>> printf
>>> > and die a horrible death.
>>> >
>>> > Let’s see if I can find the thread on Discord…
>>> >
>>> > around August 19/2021
>>> >
>>> > run:
>>> >
>>> > rtems-exeinfo -O blah.exe
>>> >
>>> > and make sure that all of the functions have the same architecture
>>> > specified. Mine had a mix of -mcpu=cortex-m4 and -mcpu=arm7tdmi which
>>> are
>>> > incompatible.
>>> >
>>> >
>>> >
>>> > Andrei Chichak
>>> > (from The Great White North)
>>> >
>>> >
>>> > > On 2021-December-31, at 18:48, Петр Борисенко 
>>> wrote:
>>> > >
>>> > > Hello and Happy new year!
>>> > > I am getting an error during startup:
>>> > > RTEMS_FATAL_SOURCE_EXCEPTION
>>> > > Catching it in _ARM_Exception_default.
>>> > > The bsp is `arm/stm32f4`.
>>> > > Here is contains of CPU_Exception_frame:
>>> > > register_r0 uint32_t 0x80139bc
>&

Re: RTEMS_FATAL_SOURCE_EXCEPTION during startup

[Joel Sherrill]

Assuming it is compiled correctly, printing this early should be via
printk().

Can you attach gdb and just walk through the BSP initialisation?

--joel

On Sat, Jan 1, 2022, 2:08 AM  wrote:

> (sorry, I accidentally sent this to the dev list instead of users. too
> much cheer)
>
> It’s bombing in printf. It’s so early that the stack hasn’t been set up
> yet, and it’s found an error and it’s trying to poot a message out on the
> console, which is also not set up yet.
>
> Umm, what could be wrong? Lemme think… (I’ve worked wth this bsp in
> RTEMS4.11, and a version in RTEMS5)
>
> I had problems with that BSP blowing up just like this because portions of
> it weren’t compiled with the proper instruction set, and when the startup
> code called memset (I think), it would call memset in newlib/libc that was
> compiled for the wrong architecture, do the wrong thing, end up in printf
> and die a horrible death.
>
> Let’s see if I can find the thread on Discord…
>
> around August 19/2021
>
> run:
>
> rtems-exeinfo -O blah.exe
>
> and make sure that all of the functions have the same architecture
> specified. Mine had a mix of -mcpu=cortex-m4 and -mcpu=arm7tdmi which are
> incompatible.
>
>
>
> Andrei Chichak
> (from The Great White North)
>
>
> > On 2021-December-31, at 18:48, Петр Борисенко  wrote:
> >
> > Hello and Happy new year!
> > I am getting an error during startup:
> > RTEMS_FATAL_SOURCE_EXCEPTION
> > Catching it in _ARM_Exception_default.
> > The bsp is `arm/stm32f4`.
> > Here is contains of CPU_Exception_frame:
> > register_r0 uint32_t 0x80139bc
> > register_r1 uint32_t 0
> > register_r2 uint32_t 0
> > register_r3 uint32_t 76
> > register_r4 uint32_t 0
> > register_r5 uint32_t 0
> > register_r6 uint32_t 0
> > register_r7 uint32_t 0
> > register_r8 uint32_t 0
> > register_r9 uint32_t 0
> > register_r10 uint32_t 0
> > register_r11 uint32_t 0
> > register_r12 uint32_t 0
> > register_sp uint32_t 536909088
> > register_lr void * 0x80001c3 
> > register_pc void * 0x8013f08 <_svfprintf_r+8152>
> > register_xpsr uint32_t 16777216
> > vector uint32_t 3
> > vfp_context const ARM_VFP_context * 0x0
> > reserved_for_stack_alignment uint32_t 3522771716
> > _Port_Minor rtems_device_minor_number * 0x20006988
> > 
> > *_Port_Minor rtems_device_minor_number 1363452156
> >
> > What could it be? Any common reasons? Or what additional info should I
> > provide?
> >
> > Also it would be really appreciated if someone will help me export/build
> > bsp as a debuggable source tree.
> >
> > Best regards.
> > Peter Borisenko
> > Awesome Technologies, Ltd.
> > http://awsmtek.com
> > hardw...@awsmtek.com
> > +79062165482
> > ___
> > users mailing list
> > users@rtems.org
> > http://lists.rtems.org/mailman/listinfo/users
>
> ___
> devel mailing list
> de...@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
> ___
> 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

Ten Years of Git

[Joel Sherrill]

Hi

Had a memory pop up which noted that today is the tenth anniversary of
when we made CVS ready only. That means today there are now 26 years,
7 months, and 4 days of RTEMS history to peruse online.

This is the post and original in the RTEMS Users Facebook group.

https://www.facebook.com/groups/4847496844/permalink/10158477934211845/

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

Flight Software Workshop Call for Abstracts (2 weeks)

[Joel Sherrill]

Hi

I apologize if this is a bit mangled. The mail I received was heavily
HTML and I sanitized it to this. The URL included is the best place to
go for information. :)

This year's Workshop will be held February 7-10, 2022! It's free for
attendees and all-virtual.

Only two weeks away from the abstract submission deadline, November
12, 2021. Over 315 space flight software engineers and students
registered so far! For info submitting and registration, visit

http://flightsoftware.jhuapl.edu/workshop/FSW2022


FSW-22 Cycle Dates
Registration Opens: August 16, 2021 - Registration is open!
First Call for Abstracts: September 1, 2021 - Accepting submissions now!
Abstract Submission Deadline: November 12, 2021
Abstract Acceptance Notification:  December 10, 2022
Presentation Submission Deadline: January 14, 2022
Virtual Workshop: February 7-10, 2022
Questions about the Workshop? Check out the FSW-22 home page or
contact the Workshop Organizing Committee.

If you know a person or group who might be interested in submitting an
abstract, feel free to forward this email!

The FSW-2022 Organizing Committee
Website: http://flightsoftware.org
Twitter: @FSWWorkshop
YouTube: Flight Software Workshop
Support: i...@flightsoftware.org
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Static allocation

[Joel Sherrill]

On Tue, Sep 28, 2021 at 11:21 AM Петр Борисенко  wrote:
>
>  > By wanting static allocation only, you need to use the special task and 
> queue create APIs for that and avoid services which do dynamic allocation
>
> Are we talking about some existing API? Can you provide a link for 
> documentation?

Existing APIs. If you use rtems_task_create() the task stack will be
dynamically allocated. If you use rtems_task_construct(), you provide
the stack space and nothing is dynamically allocated.

https://docs.rtems.org/branches/master/c-user/task/directives.html#rtems-task-construct

Similar API for RTEMS message queue where you provide the pending
message buffers

https://docs.rtems.org/branches/master/c-user/message/directives.html#rtems-message-queue-construct

And you want to configure maximum numbers of each type of object so
they are pre-allocated. When you configure unlimited, there is no hard
limit, nothing is pre-allocated.

Sebastian is there any guidance in the Classic API or Users Guide
about static systems?

>
> On Tue, Sep 28, 2021, 6:33 PM Joel Sherrill  wrote:
>>
>>
>>
>>
>> On Tue, Sep 28, 2021, 10:05 AM Петр Борисенко  wrote:
>>>
>>> Seems pretty obvious, but I mean kernel. When I define a queue or a task, 
>>> will it compile statically or it will get memory from heap during the 
>>> initialization? @Sebastian Huber mentioned that it depends on using of 
>>> UNLIMITED_OBJECTS configuration option. On
>>
>>
>> Unlimited objects is inherently dynamic memory allocation. It assumes that 
>> there are no hard limits on the number of objects created. Historically, all 
>> Classic API and POSIX API structures were allocated from the RTEMS Workspace 
>> and this lets you dynamically extend the number of objects until you run out 
>> of memory.
>>
>> Combine it with unified work area and you can allocate until all memory on 
>> your board is consumed.
>>
>> By wanting static allocation only, you need to use the special task and 
>> queue create APIs for that and avoid services which do dynamic allocation.
>>
>> --joel
>>>
>>>
>>> On Tue, Sep 28, 2021, 5:26 PM Joel Sherrill  wrote:
>>>>
>>>>
>>>>
>>>> On Tue, Sep 28, 2021, 6:43 AM Петр Борисенко  wrote:
>>>>>
>>>>> Hello!
>>>>> Is it possible to compile Rtems statically and disable memory allocation
>>>>> routines and heap?
>>>>
>>>>
>>>> No. You have to restrict your application use of APIs and services to 
>>>> those which do not use dynamic allocation.
>>>>
>>>> --joel
>>>>>
>>>>> ___
>>>>> 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: Static allocation

[Joel Sherrill]

On Tue, Sep 28, 2021, 10:05 AM Петр Борисенко  wrote:

> Seems pretty obvious, but I mean kernel. When I define a queue or a task,
> will it compile statically or it will get memory from heap during the
> initialization? @Sebastian Huber  
> mentioned
> that it depends on using of UNLIMITED_OBJECTS configuration option. On
>

Unlimited objects is inherently dynamic memory allocation. It assumes that
there are no hard limits on the number of objects created. Historically,
all Classic API and POSIX API structures were allocated from the RTEMS
Workspace and this lets you dynamically extend the number of objects until
you run out of memory.

Combine it with unified work area and you can allocate until all memory on
your board is consumed.

By wanting static allocation only, you need to use the special task and
queue create APIs for that and avoid services which do dynamic allocation.

--joel

>
> On Tue, Sep 28, 2021, 5:26 PM Joel Sherrill  wrote:
>
>>
>>
>> On Tue, Sep 28, 2021, 6:43 AM Петр Борисенко  wrote:
>>
>>> Hello!
>>> Is it possible to compile Rtems statically and disable memory allocation
>>> routines and heap?
>>>
>>
>> No. You have to restrict your application use of APIs and services to
>> those which do not use dynamic allocation.
>>
>> --joel
>>
>>> ___
>>> 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: Static allocation

[Joel Sherrill]

On Tue, Sep 28, 2021, 6:43 AM Петр Борисенко  wrote:

> Hello!
> Is it possible to compile Rtems statically and disable memory allocation
> routines and heap?
>

No. You have to restrict your application use of APIs and services to those
which do not use dynamic allocation.

--joel

> ___
> 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: Issue Compiling the Tool Suite on Windows 10

[Joel Sherrill]

On Mon, Sep 27, 2021, 9:32 AM Christian MAUDERER <
christian.maude...@embedded-brains.de> wrote:

> Hello Luke,
>
> compiling the tool suite on Windows is a bit tricky in my experience and
> it needs ages. I just recently wanted to try a patch that would prefer
> python3 and had quite some problems with it:
>
> https://lists.rtems.org/pipermail/devel/2021-August/069006.html
>
>  From what I can say at the moment, I think your best bet is using msys2
> and not cygwin (if you have the choice). You'll need flex additionally
> to the packets given in the manual here:
>
>  https://docs.rtems.org/branches/master/user/hosts/windows.html#msys2
>
> For my patch that didn't work but I think with the current upstream RSB
> it should work.
>

Piling on, gdb 9 (RTEMS 5) will no longer build on Cygwin. Google finds
plenty of discussion on this and other packages.  I've discussed how to
deal with this with Chris. Looks I will be spending a small patch rather
than upgrading that branch to gdb 10.


> Best regards
>
> Christian
>
> Am 23.09.21 um 18:37 schrieb Luke Halberstadt:
> > Dear Sir/Madam,
> >
> > I am working on compiling the RTEMS toolchain on a Windows machine
> following the instructions provided here:
> > https://docs.rtems.org/branches/master/user/hosts/windows.html#cygwin
> >
> > Both Cygwin and MSYS2 are installed along with most of the recommended
> packages, however, I could not find the gcc4* or python packages. Instead,
> I installed similar gcc* and python2 packages.
> >
> > When I compile using the following command,
> > ../source-builder/sb-set-builder --prefix=/cygdrive/c/opt/rtmes/5.1
> 5/rtems-sparc --jobs=none
> >
> > The build makes it up to building gdb and then fails with a python error.
> > building: sparc-rtems5-gdb-9.1-x86_64-pc-cygwin-1
> > error: building sparc-rtems5-gdb-9.1-x86_64-pc-cygwin-1
> >
> > I have attached the rsb-report and log files The key issue seems to be
> in the following lines of the report:
> > 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:8869: configure-gdb] Error 1
> > make[1]: Leaving directory
> '/cygdrive/c/opt/rtems/5.1/rtems/build/sparc-rtems5-gdb-9.1-x86_64-pc-cygwin-1/build'
> > make: *** [Makefile:855: all] Error 2
> > shell cmd failed: sh -ex
> /cygdrive/c/opt/rtems/5.1/rtems/build/sparc-rtems5-gdb-9.1-x86_64-pc-cygwin-1/do-build
> > error: building sparc-rtems5-gdb-9.1-x86_64-pc-cygwin-1
> >
> > By default, Python is installed at /bin, not /usr/bin, so I tried
> copying the python files from /bin to /usr/bin, but that did not resolve
> the issue. I attached a screenshot showing the contents of /usr/bin when
> this failure occurred.
> >
> > Any ideas how to get around this problem so that gcc recognizes the
> python installation? Thank you for your input.
> >
> > Sincerely,
> >
> > Luke Halberstadt
> > Senior Associate Training Engineer
> > Natick, MA USA
> > (508) 647-0196
> > lhalb...@mathworks.com
> >
> >
> > ___
> > users mailing list
> > users@rtems.org
> > http://lists.rtems.org/mailman/listinfo/users
> >
>
> --
> 
> embedded brains GmbH
> Herr Christian MAUDERER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: christian.maude...@embedded-brains.de
> phone: +49-89-18 94 741 - 18
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> ___
> 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: Pleiades Neo and RTEMS?

[Joel Sherrill]

On Sat, Sep 25, 2021 at 12:35 AM Pierre FICHEUX  wrote:
>
> Hi Joel,
>
> I work with Airbus (including Defence and Space) so I can ask them about the 
> OS.

Thanks. At one point, there was a PDF of a presentation with Airbus'
history with RTEMS.
I think it came from a presentation in France and you may have been a
part of that. Do
you happen to have a copy of it? Or a link?

>
> I'm quite sure they use RTEMS.

:)

--joel

>
> regards
>
> Le lun. 16 août 2021 à 18:13, Joel Sherrill  a écrit :
>>
>> Hi
>>
>> I noticed that another Pleiades Neo satellite was launching later today.
>>
>> https://directory.eoportal.org/web/eoportal/satellite-missions/p/pleiades-neo
>>
>> My quick search didn't find any indication of the software or hardware
>> internals of the satellites. Given the parties involved, I expect there is
>> a reasonable chance RTEMS is hiding in these somewhere.
>>
>> Does anyone have any insight? I'm happy for an offlist answer.
>>
>> Thanks.
>>
>> --joel
>> ___
>> users mailing list
>> users@rtems.org
>> http://lists.rtems.org/mailman/listinfo/users
>
>
>
> --
>
> Pierre FICHEUX -/- CTO Smile ECS, France -\- pierre.fich...@smile.fr
>  http://www.smile.fr
>  https://smile.eu/fr/offres/embarque-iot
> I would love to change the world, but they won't give me the source code
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: "printf()" from ISR worked consistently? Huh?

[Joel Sherrill]

On Wed, Aug 18, 2021 at 3:13 PM Peter Dufault  wrote:
>
> I've been porting some old code to rtems-6 and I had a "logtxt()" function 
> that I'd used for years that was callable from an ISR - it buffered up the 
> info and sent it to a task to log.
>
> I didn't realize that the old library had a fall-back "logtxt()" that used 
> printf() that I'd over-ridden in the applications where I'd been using it.  A 
> lot of things weren't working right yet, but "logtxt()" appeared to be 
> working just fine.  More things started working once I replaced "logtxt()" 
> with a version that used "printk()".
>
> How could printf() from an ISR work at all, let alone seem to work well?  The 
> "logtxt()" was only to the console, maybe that's why.

Just lucky. It somehow didn't use the FPU and managed to enqueue the
characters without conflicting with a task using it or using a mutex
that tripped a fatal error.

Another approach might be to write an sprintk (thought we had it)
calling _IO_Vprintf which is the guts of printk and have it print to a
buffer. Then send the buffer via a message queue to a thread to print
it. More complicated but doesn't force the caller to incur the
overhead of polling the characters out. That polling output overhead
maybe breaking timing and causing you some issues. Does the code work
without the logging?

> Also, is there an equivalent to the VxWorks "in_isr()" for a simple-minded 
> "logtxt()" that switches between printk() and printf()?

The cleverly named rtems_interrupt_is_in_progress() should be the answer.

https://docs.rtems.org/releases/rtems-docs-4.11.0/c-user/interrupt_manager.html#rtems-interrupt-is-in-progress

But the IO may be mixed between printf() and printk().

>
>
> Peter
> -
> Peter Dufault
> HD Associates, Inc.  Software and System Engineering
>
>
>
> ___
> 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: libbsd network on an mvme2500

[Joel Sherrill]

On Tue, Aug 17, 2021, 7:00 PM Chris Johns  wrote:

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

Do you have something like CONFIGURE_UNLIMITED and
CONFIGURE_UNIFIED_WORKSPACE?

With those (spelled correctly) you should be able to create objects until
memory runs out.

Also configuring the minimum thread stack size to give some breathing space
is often handy.

--joel


> 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
>
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Chat

[Joel Sherrill]

On Tue, Aug 10, 2021, 9:58 AM Gedare Bloom  wrote:

>
>
> On Tue, Aug 10, 2021 at 5:34 AM Kuan-Hsun Chen  wrote:
>
>> Hi Benson,
>>
>> Regarding Discord for RTEMS, here you go: https://discord.gg/TKhmGt8p.
>>
>> Best,
>> Kuan-Hsun
>>
>> On Tue, Aug 10, 2021 at 1:21 PM Mathew Benson 
>> wrote:
>>
>>> Is there a Slack or Discord channel to discuss RTEMS?  I don't want to
>>> flood everybody's inbox with emails.
>>>
>>>
> As well, for this kind of development work (porting RTEMS), you can bring
> your discussions and questions over to de...@rtems.org.
>
>
>> I want to port RTEMS to the Xilinx Zynq Ultrascale+ R5.  I've taken the
>>> RTEMS training, but that was a couple years ago.  I think I'll be fine once
>>> I can just get through the build system and can focus on just code, but the
>>> build system seems very foreign to me.  There still seems to be either
>>> fragments of an old build system or just files that don't seem to serve any
>>> purpose.  It would appear that "/spec/build/bsps/arm/xilinx-zynqmp" is
>>> where my build set definition begins, but then what is
>>> "/bsps/arm/xilinx-zynqmp/config" for?
>>>
>>>
> We haven't quite divorced ourselves from the older autotools build system,
> but new BSPs/ports (including the aarch64) are not using the old build
> system at all.
>
> The arm/xilinx-zynqmp is a BSP for only the 32-bit arm support of the Zynq
> Ultrascale+ MPSOC specifically tested/used on the Ultra96. It was
> contributed by Dornerworks. I guess this is a little confusing, because now
> we also have bsps/aarch64/xilinx-zynqmp, which provides the 64-bit support.
> At some point, we should be able to deprecate/drop the arm/xilinx-zynqmp
> with the ability to configure the aarch64/xilinx-zynqmp to only run in
> aarch32 mode.
>

Probably worth starting a thread to ask Kinsey about that. I think the user
was trying something like that at one point.

I also think the BSP dornerworks contributed can run under Xen. So that
would have to be accounted for

But I'd focus in r5 simple bsp as an arm CPU with a simple goal of click
tick and interrupts native but using openamp to talk to a host for as much
as possible. I thought someone had openamp working but I just remember it
has been discussed multiple times.


>
>> Also, everything still seems to be organized by architecture, the board.
>>> How do you want the Zynq Ultrascale organized?  It has multiple
>>> architectures on the same SoC.  Should it be under "arm" or "aarch64"?  Is
>>> it possible to build two kernels in a single step, or should it contain an
>>> entry in "arm" for the R5 and an entry in "aarch64" for the A53?
>>>
>>>
> It will be preferred to work on the aarch64 version for the A53 processor.
> The R5 as a standalone would be a BSP under arm though.
>
>
>> --
>>> *Mathew Benson*
>>> CEO | Chief Engineer
>>> Windhover Labs, LLC
>>> 832-640-4018
>>>
>>>
>>> www.windhoverlabs.com
>>>
>>> ___
>>> users mailing list
>>> users@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/users
>>
>>
>>
>> --
>> Diese Mail wurde mobil geschrieben. Etwaige Rechtschreibfehler sind volle
>> Absicht und als großzügiges Geschenk zu verstehen.
>> ___
>> 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: RTEMS on the Zynq Ultrascale+ R5

[Joel Sherrill]

On Mon, Aug 9, 2021 at 12:53 PM Mathew Benson 
wrote:

> I might take that on.  When I took the RTEMS training a couple years ago,
> the repository was still in the middle of a restructuring and build system
> upgrade so it was a little confusing.  I just looked at it and the new
> documentation and it looks a lot less daunting.
>

That's good feedback.

Hopefully this is mostly a BSP with possibly a few tweaks to the ARM
specific code if the CPU model has differences not yet accounted for.

If used as a side processor only, it might not have many peripheral drivers
which would make things simpler. The timer for the clock and interrupt
controller are quite likely already supported.

One thing that does need to be addressed in the BSP and software stack is
how to communicate with it as a side processor. There are standard open
source packages out there for that and whatever one is used here would need
to be ported.

I'm guessing here but the console may be virtual through that
communications bridge to the main cores.

--joel

>
>
> On Mon, Aug 9, 2021 at 12:35 PM Joel Sherrill  wrote:
>
>> On Mon, Aug 9, 2021 at 11:49 AM Gedare Bloom  wrote:
>> >
>> > Hi Mathew,
>> >
>> > Not that I'm aware of, so probably not. There is ongoing work that is
>> > improving the Zynq Ultrascale+ support, and there is also work ongoing
>> > for the Xilinx Versal, which shares some features including R5F
>> > co-processors. OAR has been pushing on Ultrascale, but I couldn't tell
>> > you what their scope is, and I have been working with Chris Johns on
>> > the Versal but the R5F is not yet in scope for me.
>>
>> Gedare's right. OAR did the aarch64 bit port but we haven't touched the
>> R5 yet. Everytime someone (you?) ask, I always think of the R52 FVP and
>> tms570 BSPs but those aren't what you need.
>>
>> This is certainly something we'd like to see for RTEMS. It just needs a
>> sponsor.   :)
>>
>> --joel
>> >
>> > Gedare
>> >
>> > On Sat, Aug 7, 2021 at 2:22 PM Mathew Benson 
>> wrote:
>> > >
>> > > Has anybody started or completed porting RTEMS to the R5?
>> > >
>> > > Sent from my iPad
>> > > ___
>> > > 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
>>
>
>
> --
> *Mathew Benson*
> CEO | Chief Engineer
> Windhover Labs, LLC
> 832-640-4018
>
>
> www.windhoverlabs.com
>
>
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: RTEMS on the Zynq Ultrascale+ R5

[Joel Sherrill]

On Mon, Aug 9, 2021 at 11:49 AM Gedare Bloom  wrote:
>
> Hi Mathew,
>
> Not that I'm aware of, so probably not. There is ongoing work that is
> improving the Zynq Ultrascale+ support, and there is also work ongoing
> for the Xilinx Versal, which shares some features including R5F
> co-processors. OAR has been pushing on Ultrascale, but I couldn't tell
> you what their scope is, and I have been working with Chris Johns on
> the Versal but the R5F is not yet in scope for me.

Gedare's right. OAR did the aarch64 bit port but we haven't touched the
R5 yet. Everytime someone (you?) ask, I always think of the R52 FVP and
tms570 BSPs but those aren't what you need.

This is certainly something we'd like to see for RTEMS. It just needs a
sponsor.   :)

--joel
>
> Gedare
>
> On Sat, Aug 7, 2021 at 2:22 PM Mathew Benson  
> wrote:
> >
> > Has anybody started or completed porting RTEMS to the R5?
> >
> > Sent from my iPad
> > ___
> > 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: Building a library for use with RTEMS via CMake

[Joel Sherrill]

On Mon, Jul 19, 2021 at 8:17 AM  wrote:
>
> Hello,
>
> I have built RTEMS 5 and its tools for the Xilinx Zynq Zedboard and installed 
> the BSP and tools at a certain position on my machine.
> The tools are added to the PATH variable and RTEMS_BSPS is also available in 
> the environment.
>
> Now we need to build a library for the use with RTEMS via CMake.
> For this we wanted to use the toolchain files.
> Does anybody know how to correctly setup such a toolchain file using the 
> RTEMS compiler?
>
> We managed to get a toolchain file working which at least built the library.
> But when we wanted to link to this library during compilation of a RTEMS 
> application we got a bunch of errors due to undefined references to standard 
> library functions.
> Does anybody has a clue where this might origin from?
>
> Building a RTEMS application which does not use the own library works fine.
>
> Our toolchain file looks like this:
>
> # CMake toolchain file for ARM
> # The compiler is based on
> # The RTEMS_BSPS environment variable is expected to be set.
> set(ARCH arm)
> set(CMAKE_SYSTEM_NAME RTEMS5)
>
> set(CMAKE_CXX_FLAGS "" CACHE STRING "ARM RTEMS5 gcc additional compiler 
> flags" FORCE)
>

It sounds like you didn't specify the compiler arguments. You are missing
the arguments which produce code for the Zynq CPU mode. This is
from the zynq qemu configuration

-march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard -mtune=cortex-a9

For rtems5, you also need other arguments like -B DIR -specs bsp_specs -qrtems

For rtems6, it is just -B DIR -qrtems

DIR will point to the installed BSP.

I don't see those in this configuration.

> set(RTEMS_TOOLS_PATH $ENV{RTEMS_BSPS}/../../tools/bin)
>
> set(CMAKE_C_COMPILER ${RTEMS_TOOLS_PATH}/arm-rtems5-gcc CACHE PATH "ARM 
> RTEMS5 gcc" FORCE)
> set(CMAKE_CXX_COMPILER ${RTEMS_TOOLS_PATH}/arm-rtems5-gcc CACHE PATH "ARM 
> RTEMS5 gcc" FORCE)
> set(CMAKE_CXX_COMPILER_AR ${RTEMS_TOOLS_PATH}/arm-rtems5-gcc-ar CACHE PATH 
> "ARM RTEMS5 ar" FORCE)
> set(CMAKE_CXX_COMPILER_RANLIB ${RTEMS_TOOLS_PATH}/arm-rtems5-gcc-ranlib CACHE 
> PATH "ARM RTEMS5 gcc ranlib" FORCE)
> set(CMAKE_RANLIB ${RTEMS_TOOLS_PATH}/arm-rtems5-ranlib CACHE PATH "ARM RTEMS5 
> ranlib" FORCE)
> set(CMAKE_READELF ${RTEMS_TOOLS_PATH}/arm-rtems5-readelf CACHE PATH "ARM 
> RTEMS5 readelf" FORCE)
> set(CMAKE_STRIP ${RTEMS_TOOLS_PATH}/arm-rtems5-strip CACHE PATH "ARM RTEMS5 
> strip" FORCE)
> set(CMAKE_ADDR2LINE ${RTEMS_TOOLS_PATH}/arm-rtems5-addr2line CACHE PATH "ARM 
> RTEMS5 addr2line" FORCE)
> set(CMAKE_LINKER ${RTEMS_TOOLS_PATH}/arm-rtems5-ld CACHE PATH "ARM RTEMS5 ld" 
> FORCE)
> set(CMAKE_NM ${RTEMS_TOOLS_PATH}/arm-rtems5-nm CACHE PATH "ARM RTEMS5 nm" 
> FORCE)
> set(CMAKE_OBJCOPY ${RTEMS_TOOLS_PATH}/arm-rtems5-objcopy CACHE PATH "ARM 
> RTEMS5 objcopy" FORCE)
> set(CMAKE_OBJDUMP ${RTEMS_TOOLS_PATH}/arm-rtems5-objdump CACHE PATH "ARM 
> RTEMS5 objdump" FORCE)
>
> set(CMAKE_TARGET_CONFIG_POSTFIX .rtems5_gcc_arm)
>
> 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

Re: Heap allocation for libbsd overwrites IMFS

[Joel Sherrill]

On Wed, Jun 23, 2021, 4:47 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

>
>
> On 23/06/2021 10:32, jan.som...@dlr.de wrote:
> > One of our applications for the Zedboard fails with fatal error after
> the setup of the network stack in libbsd.
> > So far I traced it down to the point that the memory allocation for
> libbsd overwrites parts of the IMFS of rtems.
> > When opening device files later this will lead to the crash.
> > The backtrace looks like this for the bad allocation looks like this:
> > _Heap_Block_split
>  ../../../../../c/src/../../cpukit/score/src/heap.c:313  0x10dd58
> > _Heap_Block_allocate_from_begin
>  ../../../../../c/src/../../cpukit/score/src/heap.c:378  0x10dfd6
> > _Heap_Block_allocate
> ../../../../../c/src/../../cpukit/score/src/heap.c:465  0x10dfd6
> > _Heap_Allocate_aligned_with_boundary
> ../../../../../c/src/../../cpukit/score/src/heapallocate.c:265  0x10e19c
>
> > rtems_heap_allocate_aligned_with_boundary
>  ../../../../../c/src/../../cpukit/libcsupport/src/malloc_deferred.c:92
> 0x10962e
> > malloc
> ../../../../../c/src/../../cpukit/libcsupport/src/malloc.c:39   0x10950e
>
> > _bsd_malloc   ../../rtemsbsd/rtems/rtems-kernel-malloc.c:80   0x170048
>
> > [more libbsd]
> > ifconfig  ../../freebsd/sbin/ifconfig/ifconfig.c:1024 0x1724fa
> >
>
> You probably have a general memory corruption issue. As a first step I
> would enable RTEMS_DEBUG = True to enable the heap protection. This
> could help to debug the issue.
>
> > With 1 GiB of RAM, available memory shouldn't be a problem.
> > At the moment we have configured the system with
> CONFIGURE_UNLIMITED_OBJECTS and CONFIGURE_UNIFIED_WORK_AREAS.
>
> This is fine.
>
> > Maybe that is not right in this case. Are there any suggestions how to
> better configure the system?
> > I found CONFIGURE_MEMORY_OVERHEAD in the docs, but I am not so sure how
> to use it or if it would help.
>
> No, it would not help.
>

It should only be used when the confdefs calculations appear to have a bug
and under allocate. This was added long ago to provide a quick workaround
for users. Usually an error in confdefs takes a bit to debug

--joel

>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> ___
> 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: Timeslice issues with preemption enabled

[Joel Sherrill]

On Thu, Jun 10, 2021 at 9:58 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 10/06/2021 16:24, Gedare Bloom wrote:
> >>> 5. Can anyone give some suggestions to solve the problem? thanks!
> > Classic and POSIX APIs can be mixed. It is a poorly documented benefit
> > of RTEMS. I think in this case, you should be able to use
> > pthread_setschedparam(...) with passing policy == SCHED_RR to get the
> > behavior you seek. You have to use posix priorities in the sched_param
> > argument. though, or else your thread will have its priority changed.
> > Pass the task_id instead of pthread_t as the first argument, and the
> > rest should work itself out. Do let us know if that works or it
> > doesn't work/you have more questions.
>
> You can use these directives to convert priority values:
>
>
> https://docs.rtems.org/branches/master/c-user/scheduling-concepts/directives.html#rtems-scheduler-map-priority-to-posix
>
> In general, the timeslicing based on clock tick quantum is quite coarse.
> The internal timestamps would allow a much finer grained timeslicing.
> This could be added if someone is interested in a small project.
>

TImeslicing accounting requires something to invoke the update method.
The only "trigger" is the clock tick. Turning the tick quantum down doesn't
add a lot of overhead. One millisecond is certainly not an issue on even
low end hardware. And then have a timeslice of 1 tick.

Also the timeslice value is the same across all threads.

If you are depending on timeslicing in your application to share the CPU
across threads, then you probably should at least consider why they are
using that much uninterrupted CPU time and ensure you have accounted
for that in your design.

--joel


>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> ___
> 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: finstrument-functions issues

[Joel Sherrill]

On Fri, Jun 4, 2021 at 9:16 AM Matthew J Fletcher  wrote:

> Replying to myself.
>
> Seems various interrupt and other rtems routines need to be excluded, with
> "-finstrument-functions-exclude-file-list=/rtems
> -finstrument-functions-exclude-function-list=arm_interrupt_,rtems_"
> stability resumes.
>

Thank you for posting the solution even though you had to find it on your
own.

There is a section in the users guide which discusses this option without
mentioning the exclude option at all. Could you kindly provide a patch to
mention that option and give any advice you have along with your example
above? It would be certainly be appreciated by the next person to follow
this path.

I would bet that not every rtems_ method needs to be excluded but the
rules for what needs to be excluded are unclear to me. I expect it depends
on what the profiling methods actually do.

--joel


>
>
> On Wed, 2 Jun 2021 at 15:34, Matthew J Fletcher  wrote:
>
>> Hi
>>
>> Has anyone tried with -finstrument-functions with the rtems-5 branch a
>> (gcc 7.5.0) ? even with a minimal stub (shown), i get random crashes,
>> normally in the heap allocate/free code paths
>>
>> __attribute__((no_instrument_function)) void __cyg_profile_func_enter
>> (void *this_fn, void *call_site)
>> {
>> }
>> __attribute__((no_instrument_function)) void __cyg_profile_func_exit
>> (void *this_fn, void *call_site)
>> {
>> }
>>
>> Removing  -finstrument-functions from the makefiles removes the crashes.
>>
>>
>> regards
>> ---
>> Matthew J Fletcher
>>
>>
>
> --
>
> regards
> ---
> Matthew J Fletcher
>
> ___
> 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

RFC: Move Away from Freenode

[Joel Sherrill]

Hi

Community input is needed and appreciated!

The #rtems IRC server (freenode.net) has undergone some turmoil and we need
to discuss what to do. This email provides some hopefully unbiased
background on the Freenode situation, the options I identified, and my
personal recommendation.

If you follow the nerdy type of news, you may be aware of some serious
turmoil. I won't even try to rehash all the news but the basic outline is
that the owner of the domain name has pushed some uncool things, forcing
some elected leaders out, most/all the volunteers have left, etc. There is
some concern that any information on freenode will be commercialized. This
isn't much except for registered users who have a nickname and password.
That much should all be covered here with lots of links.

https://www.theregister.com/2021/05/19/freenode_staff_resigns/

This is a starting point to read things from the volunteer viewpoint that
was posted to a GCC mailing list:

https://gist.github.com/joepie91/df80d8d36cd9d1bde46ba018af497409

At this point, open source projects are bailing on Freenode for libera.chat
which was founded and setup by Freenode volunteers. I saw over 400 projects
have moved to the libera.chat. Showing the tone of what's happening at
Freenode, if libera.chat was mentioned in a channel, the admins for that
channel had their permissions removed and new admins were assigned. This
has only increased the rate of the exodus.

https://www.vice.com/en/article/pkbgvg/major-internet-projects-are-leaving-freenode-after-korean-prince-takeover

Our Discord setup seems to be doing well and is more active than I ever saw
on IRC. The question to the community is what should we do? Options are:

(1) Drop Freenode and IRC entirely. Focus on Discord
(2) Drop Freenode. Add libre.chat (or another). Still keep Discord
(3) Drop Freenode. Drop Discord. Focus on IRC on libre.chat (or another).

I'm leaning to (1) but whatever we do, the git commit -> IRC bot is
down/broken and will have to be addressed. If we commit completely to
Discord, we need bot(s) there and git commits need to go to Discord.

Even if we go with (1), it may make sense to claim #rtems on the two IRC
servers that open source projects are moving to. Just in case something
else happens, we will have those channels reserved and some admins lined
up. But we can leave them unused.

If anyone knows or wants to now about Discord bots, I am sure help would be
appreciated.

What does everyone thing should happen?

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

Re: GSoC Introduction

[Joel Sherrill]

On Fri, May 21, 2021 at 7:03 AM Matthew Joyce  wrote:

> Sir,
>
> I think that makes sense. I'll put some time into it and will follow
> up in our first meeting next week.


I sent an email to newlib@ and cc'ed you but you should subscribe.

Corinna said that winsup/cygwin/strsig.cc could be a good starting point
or reference. I tend to think providing the historical BSD interfaces and
the
newer POSIX ones is a good thing.

psignal() and psiginfo() would be good to provide also but the
implementation
there is strictly Cygwin specific in details. It should be possible to add
an
RTEMS implementation to the RTEMS source for these.

The other thing I forgot to mention is that when you add a prototype to
a POSIX header, you need to add a corresponding compile-only test to
testsuites/psxtests/psxhdrs. Lining up all the headers as a starting point
and picking at the methods you mentioned would be a good first step.
Hopefully one set of patches to the headers and you don't touch them
again for the rest of the summer.


> Now I'm about to jump on a
> transatlantic flight with my four-year-old (Please wish me
> luck)...Thank you again and have a great weekend!
>

Hope the four year old does well. That's younger than when we first
did a trip to Europe with our four children. I think the youngest was
about 10 then. I joked that they all had to be self-propelled with their
own carry on gear, no stroller, and no car seats.

--joel

>
> Sincerely,
>
> Matt
>
> On Thu, May 20, 2021 at 10:50 AM Joel Sherrill  wrote:
> >
> >
> >
> > On Thu, May 20, 2021 at 8:21 AM Matthew Joyce 
> wrote:
> >>
> >> Dr. Joel,
> >>
> >> Thanks! I'd definitely like to get one or two easier ones under my
> >> belt first. Based on my initial look for what can be ported, I'd plan
> >> to start with dladdr. Sig2str and str2sig have to be re-implemented,
> >> but I think they should be fairly straightforward. Once I have those
> >> done, I'll start to tackle the others. Does that sound reasonable, or
> >> would you have a different recommendation?
> >
> >
> > That sounds reasonable enough. As a work pattern for adding POSIX
> > APIs, it has worked best to assume you will have patches outstanding
> > for multiple APIs at the same time. While one is being reviewed, you
> > should work on the next.Sometimes the newer ones end up getting
> > wrapped up before the first ones posted.
> >
> > Also all the new APIs require adding prototypes to newlib POSIX
> > headers. This means tool bumps which means it would be a good idea
> > to put together a patch to update the POSIX headers which are in
> > newlib to add the new APIs in a batch. This will mean a single bump
> > of the newlib version in the RSB which has a reasonable chance of working
> > for all the additions.
> >
> > Adding methods as needed to the headers would be a fairly easy
> > step and is a prerequisite for a number of your planned methods.
> >
> >>
> >>
> >> Also, where can I find the master API tracking CSV file?  Thanks again!
> >
> >
> > It is in rtems-docs
> >
> >
> https://git.rtems.org/rtems-docs/tree/posix-compliance/RTEMS-Standards-Compliance.csv
> >
> > I don't recall adding the new methods yet and someone internal
> > spotted a couple of minor mistakes so it looks like I will be updating
> > it soon.
> >>
> >>
> >> Sincerely,
> >>
> >> Matt
> >>
> >> On Wed, May 19, 2021 at 7:11 PM Joel Sherrill  wrote:
> >> >
> >> >
> >> >
> >> > On Wed, May 19, 2021 at 9:09 AM Matthew Joyce 
> wrote:
> >> >>
> >> >> Hello RTEMS Community,
> >> >>
> >> >> My name is Matt Joyce and it is a great honor for me to join you as a
> >> >> 2021 GSoC student developer! I'm a former active-duty US Army
> infantry
> >> >> officer now serving part-time in the reserves. Since 2019 I've been
> >> >> back in school pursuing a BS in Computer Science remotely at Oregon
> >> >> State while based with my family in Berlin, Germany.
> >> >>
> >> >> I see that there is a large group of RTEMS developers/users in
> >> >> Germany, so one day I hope to be able to meet some of you in person,
> >> >> too!
> >> >
> >> >
> >> > Hopefully this will be a fun summer for you.
> >> >>
> >> >>
> >> >> My project focuses on POSIX compliance. I plan to add multiple new
> >> >> methods not currently supported by

Re: GSoC Introduction

[Joel Sherrill]

On Thu, May 20, 2021 at 8:21 AM Matthew Joyce  wrote:

> Dr. Joel,
>
> Thanks! I'd definitely like to get one or two easier ones under my
> belt first. Based on my initial look for what can be ported, I'd plan
> to start with dladdr. Sig2str and str2sig have to be re-implemented,
> but I think they should be fairly straightforward. Once I have those
> done, I'll start to tackle the others. Does that sound reasonable, or
> would you have a different recommendation?
>

That sounds reasonable enough. As a work pattern for adding POSIX
APIs, it has worked best to assume you will have patches outstanding
for multiple APIs at the same time. While one is being reviewed, you
should work on the next.Sometimes the newer ones end up getting
wrapped up before the first ones posted.

Also all the new APIs require adding prototypes to newlib POSIX
headers. This means tool bumps which means it would be a good idea
to put together a patch to update the POSIX headers which are in
newlib to add the new APIs in a batch. This will mean a single bump
of the newlib version in the RSB which has a reasonable chance of working
for all the additions.

Adding methods as needed to the headers would be a fairly easy
step and is a prerequisite for a number of your planned methods.


>
> Also, where can I find the master API tracking CSV file?  Thanks again!
>

It is in rtems-docs

https://git.rtems.org/rtems-docs/tree/posix-compliance/RTEMS-Standards-Compliance.csv

I don't recall adding the new methods yet and someone internal
spotted a couple of minor mistakes so it looks like I will be updating
it soon.

>
> Sincerely,
>
> Matt
>
> On Wed, May 19, 2021 at 7:11 PM Joel Sherrill  wrote:
> >
> >
> >
> > On Wed, May 19, 2021 at 9:09 AM Matthew Joyce 
> wrote:
> >>
> >> Hello RTEMS Community,
> >>
> >> My name is Matt Joyce and it is a great honor for me to join you as a
> >> 2021 GSoC student developer! I'm a former active-duty US Army infantry
> >> officer now serving part-time in the reserves. Since 2019 I've been
> >> back in school pursuing a BS in Computer Science remotely at Oregon
> >> State while based with my family in Berlin, Germany.
> >>
> >> I see that there is a large group of RTEMS developers/users in
> >> Germany, so one day I hope to be able to meet some of you in person,
> >> too!
> >
> >
> > Hopefully this will be a fun summer for you.
> >>
> >>
> >> My project focuses on POSIX compliance. I plan to add multiple new
> >> methods not currently supported by RTEMS with the intent to improve
> >> application portability.
> >> (
> https://summerofcode.withgoogle.com/projects/?sp-search=Matthew%20Joyce#6686502693634048
> )
> >> With your guidance, I am excited to dive in and put what I've been
> >> learning to work and make my first real-world contributions to the
> >> greater good.
> >
> >
> > Any idea which method(s) you want to tackle first?
> >
> > --joel
> >>
> >>
> >> Thank you very much for this opportunity!  I look forward to working
> with you.
> >>
> >> Sincerely,
> >>
> >> Matt
> >> ___
> >> 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: GSoC Introduction

[Joel Sherrill]

On Wed, May 19, 2021 at 9:09 AM Matthew Joyce  wrote:

> Hello RTEMS Community,
>
> My name is Matt Joyce and it is a great honor for me to join you as a
> 2021 GSoC student developer! I'm a former active-duty US Army infantry
> officer now serving part-time in the reserves. Since 2019 I've been
> back in school pursuing a BS in Computer Science remotely at Oregon
> State while based with my family in Berlin, Germany.
>
> I see that there is a large group of RTEMS developers/users in
> Germany, so one day I hope to be able to meet some of you in person,
> too!
>

Hopefully this will be a fun summer for you.

>
> My project focuses on POSIX compliance. I plan to add multiple new
> methods not currently supported by RTEMS with the intent to improve
> application portability.
> (
> https://summerofcode.withgoogle.com/projects/?sp-search=Matthew%20Joyce#6686502693634048
> )
> With your guidance, I am excited to dive in and put what I've been
> learning to work and make my first real-world contributions to the
> greater good.
>

Any idea which method(s) you want to tackle first?

--joel

>
> Thank you very much for this opportunity!  I look forward to working with
> you.
>
> Sincerely,
>
> Matt
> ___
> 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: About runnning RTEMS on qemu

[Joel Sherrill]

On Wed, May 19, 2021 at 3:45 AM Richi Dubey  wrote:

> Hi,
>
> I do not have access to a real board, and I wanted to run a test on
> different architectures (or bsps) over qemu to see if there is anything
> amiss with the test.
>
> So, I ran the SMP test that I developed on realview_pbx_a9_qemu (arm), but
> I want to test on a few more boards/debuggers. Can you please suggest to me
> bsps that you work right out of the box on qemu for a SMP system(without
> needing much configuration):
>
> Have you guys tried one of these recently?
>  a53_lp64_qemuaarch64
>

Eventually but right now aarch64 does not have SMP support.


>  lm3s6965_qemu   arm
>

I don't think this particular ARM variant has SMP support in hardware.


>  xilinx_zynq_a9_qemu   arm
>

This should work.

A sufficiently high pc BSP variant should also work on qemu.


>  qemuprep powerpc
>  qemuprep-altivec powerpc
>  qemuppc  powerpc
>

The real hardware didn't support SMP but worse, these qemu models are
marked for removal and I don't know that I ever knew how to use them. I
vaguely recall having to have a boot ROM image but that memory may
be flawed.

>
> Can I use sparc leon3 and use sis/gdb as well for a SMP test?
>

leon3 should do SMP on sis (but not the one in gdb which is now disabled)
as well as when using qemu.

Jiri's standalone sis is nice for leon and riscv SMP.

--joel


>
> Thanks!
>
>
> ___
> 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: Can printf() be made SMP safe?

[Joel Sherrill]

On Fri, Apr 30, 2021 at 2:07 PM Dave DeGroote 
wrote:

> Hello,
>
> I'm trying to get RTEMS running using SMP on a Leon3/gr712rc (2 cores). I
> have it partially running, but it crashes intermittently on printf's.  Can
> anyone tell me if there's a way to make printf() SMP safe?  printf appears
> to use termios which uses rtems_mutex_init() and
> rtems_binary_semaphore_init() which I don't think are SMP safe (but I'm
> also new to this so I'm not sure).
>

Those are SMP safe. I suspect you are using the Classic API (e.g.
rtems_task_) and by default they do not have floating point enabled. You
probably just need to enable the floating point attribute on the task
create calls (or for the init task).

https://docs.rtems.org/branches/master/c-user/task/directives.html#rtems-task-create

See configuring a system chapter for the init task setting.

If you provide the exception, we would know for sure.

--joel

>
> Thanks!
>
> [image: Astrobotic Logo] *Dave DeGroote*
>
> Flight Software Engineer
>
> *Astrobotic*
>
> 1016 N. Lincoln Avenue  |  Pittsburgh, PA 15233
>
> office: 412.682.3282
>
>
>
>
>
> *Disclaimer*
>
> The information contained in this communication from the sender is
> confidential. It is intended solely for use by the recipient and others
> authorized to receive it. If you are not the recipient, you are hereby
> notified that any disclosure, copying, distribution or taking action in
> relation of the contents of this information is strictly prohibited and may
> be unlawful.
> ___
> 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: RTEMS Discord Server Available

[Joel Sherrill]

I generated a permanent link and made it available via the left hand side
of rtems.org's top page.

I'm still learning Discord.

Thanks.

--joel

On Mon, Apr 26, 2021 at 2:03 AM Pierre FICHEUX 
wrote:

> Thx a lot, it works.
>
> Le lun. 26 avr. 2021 à 08:56, Eshan Dhawan  a
> écrit :
>
>> Hi
>> Maybe this should help
>> Link : https://discord.gg/vgXyBEc8
>>
>> Thanks
>> - Eshan
>>
>> On 26-Apr-2021, at 12:18 PM, Pierre FICHEUX 
>> wrote:
>>
>> 
>> Hi Joel,
>>
>> Looks like the link is outdated, is there a way to join the RTEMS
>> community on Discord?
>>
>> Thx
>>
>>
>> Le mar. 23 mars 2021 à 21:49, Joel Sherrill  a écrit :
>>
>>>   Hi
>>>
>>> RTEMS now has a Discord server (https://discord.gg/6SrpDfBF).
>>>
>>> Feel free to drop by and chat.
>>>
>>> --joel
>>> ___
>>> users mailing list
>>> users@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/users
>>
>>
>>
>> --
>>
>> Pierre FICHEUX -/- CTO Smile ECS, France -\- pierre.fich...@smile.fr
>>  http://www.smile.fr
>>  https://smile.eu/fr/offres/embarque-iot
>> I would love to change the world, but they won't give me the source code
>>
>> ___
>> users mailing list
>> users@rtems.org
>> http://lists.rtems.org/mailman/listinfo/users
>>
>>
>
> --
>
> Pierre FICHEUX -/- CTO Smile ECS, France -\- pierre.fich...@smile.fr
>  http://www.smile.fr
>  https://smile.eu/fr/offres/embarque-iot
> I would love to change the world, but they won't give me the source code
>
>
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Question on rtems epoch time

[Joel Sherrill]

On Sat, Apr 24, 2021, 4:26 AM  wrote:

> Hi:
>
> I have a question is that why rtems's epoch base year is 1988(#define
> TOD_BASE_YEAR 1988)?
> I change TOD_BASE_YEAR to 1970 and TOD_SECONDS_1970_THROUGH_1988 to 0,such
> as:
>
>
> It work well. So I wonder is that a good method?


RTEMS development started in 1988 and it was for the Classic API only.
Using 1988 as the base year gave us a leap year as epoch and dividing by
four worked for a long time to determine leap years.

Over the years, the score has moved to POSIX time and the 1988 restriction
could be enforced not at the score level but at the classic level.

>
>
>
>
> Thanks! ___
> 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: RTEMS on RISC-V

[Joel Sherrill]

On Thu, Apr 22, 2021, 10:54 AM Pierre FICHEUX 
wrote:

> Hi Joel,
>
> Thanks for your answer, so there is currently no RISC-V board supported by
> RTEMS (except HiFive Unleashed ) ?
>

The NOEL-V is the only one I know.

Not sure of the state of things for the Unleashed.

>
> Le jeu. 22 avr. 2021 à 17:43, Joel Sherrill  a écrit :
>
>>
>>
>> On Thu, Apr 22, 2021, 10:17 AM Pierre FICHEUX 
>> wrote:
>>
>>> Hi all,
>>>
>>> I've read several messages about running  RTEMS on HiFive Unleashed
>>> board (with rv64imac/imafdc BSP ?). The board is currently discontinued so
>>> what is the best choice to test RTEMS on RISC-V (except QEMU) ?
>>>
>>
>> I'm going to answer from the perspective of what I'd like to see
>> supported.
>>
>> First Gaisler has the NOEL-V now and should have bit images for it for
>> some popular fpga boards. You'd have to check on the technical details but
>> this should work.
>>
>> There is a new HiFive board called Unmatched which would be nice to
>> support. And there is a RISC-V Beagle now that also looks promising. I have
>> no idea how much either of them would take to support.
>>
>> --joel
>>
>>
>>
>>> Thx by advance
>>>
>>> Regards
>>>
>>> --
>>>
>>> Pierre FICHEUX -/- CTO Smile ECS, France -\- pierre.fich...@smile.fr
>>>  http://www.smile.fr
>>>  https://smile.eu/fr/offres/embarque-iot
>>> I would love to change the world, but they won't give me the source code
>>>
>>> ___
>>> users mailing list
>>> users@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/users
>>
>>
>
> --
>
> Pierre FICHEUX -/- CTO Smile ECS, France -\- pierre.fich...@smile.fr
>  http://www.smile.fr
>  https://smile.eu/fr/offres/embarque-iot
> I would love to change the world, but they won't give me the source code
>
>
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: RTEMS on RISC-V

[Joel Sherrill]

On Thu, Apr 22, 2021, 10:17 AM Pierre FICHEUX 
wrote:

> Hi all,
>
> I've read several messages about running  RTEMS on HiFive Unleashed board
> (with rv64imac/imafdc BSP ?). The board is currently discontinued so what
> is the best choice to test RTEMS on RISC-V (except QEMU) ?
>

I'm going to answer from the perspective of what I'd like to see supported.

First Gaisler has the NOEL-V now and should have bit images for it for some
popular fpga boards. You'd have to check on the technical details but this
should work.

There is a new HiFive board called Unmatched which would be nice to
support. And there is a RISC-V Beagle now that also looks promising. I have
no idea how much either of them would take to support.

--joel



> Thx by advance
>
> Regards
>
> --
>
> Pierre FICHEUX -/- CTO Smile ECS, France -\- pierre.fich...@smile.fr
>  http://www.smile.fr
>  https://smile.eu/fr/offres/embarque-iot
> I would love to change the world, but they won't give me the source code
>
> ___
> 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: SIS in "real time"

[Joel Sherrill]

On Tue, Apr 13, 2021 at 8:02 AM Heinz Junkes 
wrote:

> Unfortunately I still do not understand it. Under Unix it runs perfectly
> and also the
> values are displayed correctly.
>
> In the debugger, the contents of the structure timespec are displayed
> correctly.
>
> Another point that probably makes the program hang:
>
> the function pthread_cond_timedwait(, , ) returns "1"
> and does not wait for the timeout.
> This return value should not exist at all?
>
> Under Unix, as expected, "110" is returned. ETIMOUT.
>

What's your current version of the source?

--joel

>
> Heinz
>
>
> > On 12. Apr 2021, at 20:38, Gedare Bloom  wrote:
> >
> > On Fri, Apr 9, 2021 at 11:45 AM Heinz Junkes 
> wrote:
> >>
> >> Jiri, Joel, thanks for your answers.
> >>
> >> @Joel: I was wondering that rtems-examples in psx_example_3 does not
> wait 3 seconds.
> >>
> >> I made a curious observation:
> >>
> >> in the original code:
> >>
> >>   clock_gettime( CLOCK_REALTIME,  );
> >>   timeout.tv_sec += 3;
> >>   timeout.tv_nsec = 0;
> >>   printf("The task is coming to enter in a timed wait\n");
> >>   pthread_cond_timedwait(, , );
> >>
> >>
> >> I then inserted some printfs and found that the "3" is added to the
> nsec’s.
> >>
> >> Then I added the rtems-timespec-helpers routines, but get the same
> behavior:
> >>
> >>
> >> void * print_hello(void * arg)
> >> {
> >>  struct timespec now, timeout;
> >>  rtems_timespec_set(, 3, 0);
> >>
> >>  printf(": Hello World! task with max priority \n");
> >>  clock_gettime( CLOCK_REALTIME,  );
> >> printf("now tv_sec = %d, tv_nsec = %d\n", now.tv_sec, now.tv_nsec);
> >>  rtems_timespec_add_to(, );
> >> printf("timeout tv_sec = %d, tv_nsec = %d\n", timeout.tv_sec,
> timeout.tv_nsec);
> >
> > Please try with the appropriate type sizes and report back what you find.
> >
> > tv_sec is of type time_t
> > tv_nsec is of type long
> >
> > %d will only take 32b of those values, so you get some kind of garbage
> > (that can depend on endianness)
> >
> >>  printf("The task is coming to enter in a timed wait\n");
> >>  pthread_cond_timedwait(, , );
> >>  printf("The task is coming out from the timed wait \n");
> >>  return NULL;
> >> }
> >>
> >> program output:
> >>
> >>  Enter in the main
> >> Creating first task
> >> : Hello World! task with max priority
> >> now tv_sec = 4766459, tv_nsec = 567993600
> >> timeout tv_sec = 4766459, tv_nsec = 567993603
> >> The task is coming to enter in a timed wait
> >> The task is coming out from the timed wait
> >> First Task created
> >> Creating second task
> >> : Hello World! Task with lowest priority Second task created
> >>  Out of the main
> >>
> >> If I now swap the arguments in the set-function , i.e. instead of
> >> rtems_timespec_set(, 3, 0);
> >>
> >> rtems_timespec_set(, 0, 3);
> >>
> >> it looks as it should
> >>
> >> : Hello World! task with max priority
> >> now tv_sec = 10766729, tv_nsec = 567993600
> >> timeout tv_sec = 10766732, tv_nsec = 567993600
> >> The task is coming to enter in a timed wait
> >> The task is coming out from the timed wait
> >> First Task created
> >> Creating second task
> >> : Hello World! Task with lowest priority Second task created
> >>  Out of the main
> >>
> >> But still no timed wait  recognizable :-(
> >>
> >> Heinz
> >>
> >>
> >>
> >> ___
> >> 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: Can not build rtems-examples for sparc/erc32

[Joel Sherrill]

On Fri, Apr 9, 2021 at 12:27 PM Heinz Junkes 
wrote:

> Danke,
> that worked.
>

On RTEMS? :) I saw it on Linux.


> Heinz
>
> > On 9. Apr 2021, at 14:35, Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
> >
> > On 09/04/2021 09:20, junkes wrote:
> >
> >> can not build examples (https://github.com/RTEMS/rtems-examples.git)
> for sparc/erc32.
> >> Seems to related to missing run time linker lib.
> > I updated the RSB. I hope it is fixed now.
> >
> > --
> > embedded brains GmbH
> > Herr Sebastian HUBER
> > Dornierstr. 4
> > 82178 Puchheim
> > Germany
> > email: sebastian.hu...@embedded-brains.de
> > phone: +49-89-18 94 741 - 16
> > fax:   +49-89-18 94 741 - 08
> >
> > Registergericht: Amtsgericht München
> > Registernummer: HRB 157899
> > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> > Unsere Datenschutzerklärung finden Sie hier:
> > https://embedded-brains.de/datenschutzerklaerung/
> >
>
> ___
> 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: SIS in "real time"

[Joel Sherrill]

Hi

I  made some changes to test3.c so it can be compiled for RTEMS or
any "normal" POSIX host like Linux. I avoided the rtems timespec
addition method.

I think this does what you expect on Linux but didn't try it on RTEMS.

FWIW this is a good minimal example of how a program can support
being built for Linux and RTEMS. For bigger examples, I prefer the RTEMS
configuration and Init thread to be in a separate file. I think the psx
reporting
examples do that.

--joel

On Fri, Apr 9, 2021 at 12:45 PM Heinz Junkes 
wrote:

> Jiri, Joel, thanks for your answers.
>
> @Joel: I was wondering that rtems-examples in psx_example_3 does not wait
> 3 seconds.
>
> I made a curious observation:
>
> in the original code:
>
>clock_gettime( CLOCK_REALTIME,  );
>timeout.tv_sec += 3;
>timeout.tv_nsec = 0;
>printf("The task is coming to enter in a timed wait\n");
>pthread_cond_timedwait(, , );
>
>
> I then inserted some printfs and found that the "3" is added to the nsec’s.
>
> Then I added the rtems-timespec-helpers routines, but get the same
> behavior:
>
>
> void * print_hello(void * arg)
> {
>   struct timespec now, timeout;
>   rtems_timespec_set(, 3, 0);
>
>   printf(": Hello World! task with max priority \n");
>   clock_gettime( CLOCK_REALTIME,  );
> printf("now tv_sec = %d, tv_nsec = %d\n", now.tv_sec, now.tv_nsec);
>   rtems_timespec_add_to(, );
> printf("timeout tv_sec = %d, tv_nsec = %d\n", timeout.tv_sec,
> timeout.tv_nsec);
>   printf("The task is coming to enter in a timed wait\n");
>   pthread_cond_timedwait(, , );
>   printf("The task is coming out from the timed wait \n");
>   return NULL;
> }
>
> program output:
>
>  Enter in the main
> Creating first task
> : Hello World! task with max priority
> now tv_sec = 4766459, tv_nsec = 567993600
> timeout tv_sec = 4766459, tv_nsec = 567993603
> The task is coming to enter in a timed wait
> The task is coming out from the timed wait
> First Task created
> Creating second task
>  : Hello World! Task with lowest priority Second task created
>  Out of the main
>
> If I now swap the arguments in the set-function , i.e. instead of
>  rtems_timespec_set(, 3, 0);
>
>  rtems_timespec_set(, 0, 3);
>
> it looks as it should
>
> : Hello World! task with max priority
> now tv_sec = 10766729, tv_nsec = 567993600
> timeout tv_sec = 10766732, tv_nsec = 567993600
> The task is coming to enter in a timed wait
> The task is coming out from the timed wait
> First Task created
> Creating second task
>  : Hello World! Task with lowest priority Second task created
>  Out of the main
>
> But still no timed wait  recognizable :-(
>
> Heinz
>
>
>
> ___
> users mailing list
> users@rtems.org
> http://lists.rtems.org/mailman/listinfo/users


test3.c
Description: Binary data
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: SIS in "real time"

[Joel Sherrill]

On Fri, Apr 9, 2021 at 7:15 AM Jiri Gaisler  wrote:

>
> On 2021-04-09 13:23, Heinz Junkes wrote:
>
> Can the SIS Simple Instruction Simulator run in "real time"?
> I.e. a sleep of 3 seconds should also last 3 seconds?
> Thanks Heinz
>
> Try starting sis with -rt .
>

I just learned of a new feature. :)

Heinz .. is this to slow down the prompt for interactive tests or something
more interesting?

--joel

> Jiri.
>
>
>
> ___
> users mailing listusers@rtems.orghttp://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: can't find "pthread_barrier_t"

[Joel Sherrill]

On Sat, Mar 27, 2021, 4:39 AM 382535941 <382535...@qq.com> wrote:

> I would like to compile rtems on my C6678 board. I have changed some
> code and when I wanted to compile it, I find it doesn't
> define pthread_barrier_t in \cpukit\include\rtems\posix\pthread.h. Is there
> other place to put it or I should install a pthread library?
>

That is an internal support file for the implementation of pthreads. The
actual header file you want to include was installed with the RTEMS tool
chain.

Did you build an items tool chain and is that what you are using?

--joel

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

RTEMS Discord Server Available

[Joel Sherrill]

  Hi

RTEMS now has a Discord server (https://discord.gg/6SrpDfBF).

Feel free to drop by and chat.

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

Re: rtems-record-lttng: Corrupted timestamps after translating to CTF

[Joel Sherrill]

On Fri, Mar 5, 2021 at 12:00 PM Gedare Bloom  wrote:

> On Fri, Mar 5, 2021 at 10:27 AM Joel Sherrill  wrote:
> >
> >
> >
> > On Fri, Mar 5, 2021 at 10:45 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
> >>
> >> On 05/03/2021 16:11, jan.som...@dlr.de wrote:
> >>
> >> > Some of the resulting CTF events have a very large timestamp. This
> only occurs for events of which are created by CPUs other than CPU0, but
> not all of them.
> >> > I ran rtems-record-lttng in gdb and could track it to
> record-client.c:176 (
> https://git.rtems.org/rtems-tools/tree/trace/record/record-client.c#n176).
> >> > There the (delta * ctx->to_bt_scaler ) causes an overflow and sets
> per_cpu->uptime.bt to a very large negative number which then later
> becomes a very large (positive) timestamp.
> >> >
> >> > I have some trouble figuring out what is going wrong here. The
> timestamps which are read from the rtems record events looks quite
> reasonable to me.
> >> > The to_bt_scaler is quite a large value and I don't fully get what it
> scales. Does someone have some hints?
> >> It could be related to ring buffer overflows. Do you get
> >> RTEMS_RECORD_PER_CPU_OVERFLOW items? There could be also some bugs in
> >> record-client.c. More unit tests for it would be helpful.
> >
> >
> > Asking stupidly, are there tests now? We didn't catch that libtrace was
> missing in the new coverage reports:
> >
> >
> https://ftp.rtems.org/pub/rtems/people/joel/coverage/coverage-2021-02-28/
> >
> > I can add it to the queue that libtrace is added. If more subsystems
> > are missing that we want to track coverage on, please point them out.
> >
>
> In cpukit the following are not covered. I have no strong opinion, but
> unless there is justification NOT to report on it, we should? Several
> of these don't have any tests, so then the question is whether they
> should have tests/examples written that use them.
>
> libdebugger
> libdl
> libdrvmgr
> libfs
> libgnat
> libi2c
> libmisc/capture
> libmisc/fb
> libmisc/monitor
> libmisc/mouse
> libmisc/redirector
> libmisc/rtems-fdt
> libmisc/serdbg
> libmisc/shell
> libmisc/utf8proc
> libmisc/uuid
> libmisc/xz
> libpci
> librtemscxx
> libtest
> libtrace
> mghttpd
> telnetd
> zlib
>
> It may be good just to know that our testsuite covers 0% of some of
> these directories, so that users can know... use at your own peril :o
>

I'm moving this part over to devel@ and a new thread.

--joel

>
> > --joel
> >>
> >>
> >> --
> >> embedded brains GmbH
> >> Herr Sebastian HUBER
> >> Dornierstr. 4
> >> 82178 Puchheim
> >> Germany
> >> email: sebastian.hu...@embedded-brains.de
> >> phone: +49-89-18 94 741 - 16
> >> fax:   +49-89-18 94 741 - 08
> >>
> >> Registergericht: Amtsgericht München
> >> Registernummer: HRB 157899
> >> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> >> Unsere Datenschutzerklärung finden Sie hier:
> >> https://embedded-brains.de/datenschutzerklaerung/
> >>
> >> ___
> >> 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: RTEMS 5 how to run "hello" example

[Joel Sherrill]

On Tue, Mar 16, 2021 at 1:40 PM Olga Syrbachova 
wrote:

> Thank you very much for your reply and for your concern!
>
> Actually I'd like to create my own application and test some mechanisms,
> provided by RTEMS. This is a part of my Bachelor Thesis. I'd like,
> for example, to create two/three tasks and make them communicate with each
> other via queues, schedule them by priority etc. I have some experience
> with FreeRTOS. It is run via Visual Studio, which is quite simple. And now
> with RTEMS I am a bit frustrated and don't know where to start. That's why
> I followed the tutorial on the Website. "Hello World" program worked just
> fine, so I decided to try some more complicated applications before I start
> with my own, that's why I decided to build "ticker" with waf. Unfortunately
> I didn't find any helpful (for me) tutorial on how to create applications
> in RTEMS. I mean I can handle writing the App's code, but I don't get it
> how to compile and run it. So I was just going to do the same as in the
> tutorial, but with my own application. Is it the right way to proceed or is
> there another way ?
>

The tests in RTEMS are just that tests. They depend on things that
shouldn't be installed or used by user applications.

I would recommend cloning rtems-examples and going from one of those. There
is a directory with variations on ticker and I suspect the base one is a
better one to start from.

If you want to write POSIX code, one of the POSIX examples there would
serve you ok

--joel


>
>
> 
>  Virenfrei.
> www.avast.com
> 
> <#m_-8462729502950921950_m_6778778117170402098_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Tue, 16 Mar 2021 at 16:29, Vijay Kumar Banerjee 
> wrote:
>
>> On Tue, Mar 16, 2021 at 4:07 AM Olga Syrbachova 
>> wrote:
>> >
>> > Thank you very much for your reply!
>> >
>> > I've added
>> > includes =
>> '/home/olga/development/rtems/rtems-5/testsuites/support/include/tmacros.h',
>> >
>> It takes the relative address to the directory where the header file
>> is. For example, if you're building from the
>> "/home/olga/development/rtems" directory the includes argument would
>> be:
>>
>> `includes = './rtems-5/testsuites/support/include/'`
>>
>> BTW, your first email at the start of the thread says that you just
>> want to run the samples, the samples get built as a part of the rtems
>> and you'll be able to see the *.exe files in the build directory. Is
>> there any reason that you're trying to build it in a separate
>> directory with waf? Experimenting with the build system is a good
>> reason though, just making sure that we're not pushing you in the
>> wrong direction and your objective is indeed to try waf on your own
>> and not just running RTEMS hello app.
>>
>> Best regards,
>> Vijay
>>
>>
>> > it still says "No such file or directory". I'm pretty sure the path is
>> write, though there is now another path to "tmacros.h" (the first one
>> below), it's a folder named "tmacros.h" and it's empty.
>> > olga@olga-H270M-DS3H:~$ locate tmacros.h
>> >
>> /home/olga/development/app/ticker/build/sparc-rtems5-erc32/$HOME/developement/rtems/rtems-5/testsuites/support/include/tmacros.h
>> >
>> /home/olga/development/rtems/rtems-5/testsuites/support/include/tmacros.h
>> >
>> >
>> > On Mon, 15 Mar 2021 at 21:00, Vijay Kumar Banerjee 
>> wrote:
>> >>
>> >> On Mon, Mar 15, 2021 at 1:53 PM Olga Syrbachova 
>> wrote:
>> >> >
>> >> > Sure! https://github.com/syrba4eva/RTEMS/blob/main/wscript
>> >>
>> >> Thanks. In this line:
>> https://github.com/syrba4eva/RTEMS/blob/main/wscript#L33
>> >> After cflags parameter, add "includes", for example:
>> >>
>> >> bld(features = 'c cprogram',
>> >>   target = 'ticker.exe',
>> >>   cflags = '-g -O2',
>> >>   includes='. .. ./original/path/to/tmacros.h',
>> >>   source = ['init.c', 'tasks.c'])
>> >>
>> >> you don't need to copy tmacros.h or any headers from rtems, just add
>> >> the path to includes.
>> >>
>> >>
>> >> Best regards,
>> >> Vijay
>> >>
>> >> >
>> >> > On Mon, 15 Mar 2021 at 20:36, Vijay Kumar Banerjee 
>> wrote:
>> >> >>
>> >> >> On Mon, Mar 15, 2021 at 1:30 PM Olga Syrbachova <
>> syrba4ev...@gmail.com> wrote:
>> >> >> >
>> >> >> > Thank you very much for your reply!
>> >> >> > Unfortunately I'm still a bit confused and don't quite understand
>> what to do. Where do I need to modify the "include" parameter? In the
>> wscript file from the "hello" example there is no "include" parameter. I
>> also tried to find a tutorial on how to write a wscript, but didn't find
>> any (Could you suggest any please?). So I tried to copy the file
>> "tmacros.h" from testsuites/support/include to app/ticker. Now after
>> running ./waf I get an error, which tells me that "buffer_test_io.h" wasn't
>> found. When I copied it to my app/ticker directory it 

Re: Issues with configuring BSP with waf

[Joel Sherrill]

On Fri, Mar 12, 2021, 10:22 PM Ida Delphine  wrote:

> Thank you, I finally succeeded :)
> And I will love to update the documentation right away so that others
> won't struggle like I did. But I'm not sure how to go about it..
>

The source for the documentation is in the rtems-docs for repo. It is
organised into a directory per manual title. You should be able to quickly
find the text. It is ASCII in Rest format. But the things I think are wrong
will be easy edits. At least I hope.



 Fri, 12 Mar 2021, 11:58 pm Joel Sherrill,  wrote:
>
>>
>>
>> On Thu, Mar 11, 2021 at 11:55 PM Ida Delphine  wrote:
>>
>>> Hello,
>>> Please I need some help. Following the GSoC getting started guide(
>>> https://docs.rtems.org/branches/master/user/start/gsoc.html),everything
>>> went well to the point I had to do an offline download. I used this command
>>> ../source-builder/sb-set-builder --source-only-download 5/rtems-sparc
>>>
>>
>> This command has a subtle mistake. If you are on the master, it should be
>> 6/rtems-sparc.
>>
>> I see 5 a couple of times at that URL. If you understand that when that
>> was written, the
>> git master was "headed to 5" and not that the "5 release branch" is cut,
>> the git master is
>> "headed to 6". That means 5 needs to change to 6 in there.
>>
>> Also any reference to autoconf/automake and configure with --enable type
>> options
>> is out of date.
>>
>> Corrections to documentation are very much appreciated. Please help
>> the next traveler avoid stepping in the same potholes.
>>
>> --joel
>>
>>
>>> Seems like there was a mismatch. I got this error:
>>> b-set-builder --source-only-download 5/rtems-sparc
>>> RTEMS Source Builder - Set Builder, 6 (5e449fb5c2cb)
>>> Build Set: 5/rtems-sparc
>>> error: no build set file found: 5/rtems-sparc.bset
>>> Build Set: Time 0:00:00.000205
>>> Build FAILED
>>> I then replaced 5/rtems in the command with 6/rtems and everything
>>> worked. I was able to install the suite, build the board support package,
>>> and test my BSP though along the way I had to replace "5" with "6" in
>>> certain commands. Everything went well until I wanted to prove I can work
>>> on RTEMS. I followed the instructions to create my hello application and
>>> added the necessary .c files. The problem was when I tried configuring this
>>> application using waf with the command:
>>>
>>> ./waf configure --rtems=$HOME/quick-start/rtems/5 --rtems-bsp=sparc/erc32
>>>
>>> I got this error:
>>> Setting top to   :
>>> /home/idadel/quick-start/app/hello
>>> Setting out to   :
>>> /home/idadel/quick-start/app/hello/build
>>> RTEMS path is not valid, "/home/idadel/quick-start/rtems/5/share/rtems5"
>>> not found.
>>> (complete log in /home/idadel/quick-start/app/hello/build/config.log)
>>> I thought I showld startover but and work with rtems.git/5 instead of
>>> rtems.git/master. Same with rsb. So I got the sources and did a "git
>>> checkout"  from the master to the "5" branch. Everything went well with me
>>> not not having to change any "5" to "6" in some commands. I didn't make it
>>> as far as testing my BSP. I had issues with configuring my BSP with the
>>> command:
>>>
>>> ./waf configure --rtems=$HOME/quick-start/rtems/5 --rtems-bsp=sparc/erc32
>>>
>>> I got this:
>>> bash: ./waf: No such file or directory
>>> I'm confused and don't know what I missed or where I went wrong.
>>>
>>> Ida.
>>>
>>>
>>>
>>>
>>> On Thu, Mar 11, 2021 at 6:03 PM Ida Delphine  wrote:
>>>
>>>> Okay. Thank you :)
>>>>
>>>> On Thu, 11 Mar 2021, 5:57 pm Gedare Bloom,  wrote:
>>>>
>>>>> On Thu, Mar 11, 2021 at 9:48 AM Ida Delphine 
>>>>> wrote:
>>>>> >
>>>>> > Thank you for your response. I am not working on the
>>>>> rtems.git/master branch. I'm not using it because earlier I tried
>>>>> downloading sources with it but I got this error
>>>>> > 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
>>>>> > So I decided to use the other alternative(get the s

Re: Issues with configuring BSP with waf

[Joel Sherrill]

On Thu, Mar 11, 2021 at 11:55 PM Ida Delphine  wrote:

> Hello,
> Please I need some help. Following the GSoC getting started guide(
> https://docs.rtems.org/branches/master/user/start/gsoc.html),everything
> went well to the point I had to do an offline download. I used this command
> ../source-builder/sb-set-builder --source-only-download 5/rtems-sparc
>

This command has a subtle mistake. If you are on the master, it should be
6/rtems-sparc.

I see 5 a couple of times at that URL. If you understand that when that was
written, the
git master was "headed to 5" and not that the "5 release branch" is cut,
the git master is
"headed to 6". That means 5 needs to change to 6 in there.

Also any reference to autoconf/automake and configure with --enable type
options
is out of date.

Corrections to documentation are very much appreciated. Please help
the next traveler avoid stepping in the same potholes.

--joel


> Seems like there was a mismatch. I got this error:
> b-set-builder --source-only-download 5/rtems-sparc
> RTEMS Source Builder - Set Builder, 6 (5e449fb5c2cb)
> Build Set: 5/rtems-sparc
> error: no build set file found: 5/rtems-sparc.bset
> Build Set: Time 0:00:00.000205
> Build FAILED
> I then replaced 5/rtems in the command with 6/rtems and everything worked.
> I was able to install the suite, build the board support package, and test
> my BSP though along the way I had to replace "5" with "6" in certain
> commands. Everything went well until I wanted to prove I can work on RTEMS.
> I followed the instructions to create my hello application and added the
> necessary .c files. The problem was when I tried configuring this
> application using waf with the command:
>
> ./waf configure --rtems=$HOME/quick-start/rtems/5 --rtems-bsp=sparc/erc32
>
> I got this error:
> Setting top to   :
> /home/idadel/quick-start/app/hello
> Setting out to   :
> /home/idadel/quick-start/app/hello/build
> RTEMS path is not valid, "/home/idadel/quick-start/rtems/5/share/rtems5"
> not found.
> (complete log in /home/idadel/quick-start/app/hello/build/config.log)
> I thought I showld startover but and work with rtems.git/5 instead of
> rtems.git/master. Same with rsb. So I got the sources and did a "git
> checkout"  from the master to the "5" branch. Everything went well with me
> not not having to change any "5" to "6" in some commands. I didn't make it
> as far as testing my BSP. I had issues with configuring my BSP with the
> command:
>
> ./waf configure --rtems=$HOME/quick-start/rtems/5 --rtems-bsp=sparc/erc32
>
> I got this:
> bash: ./waf: No such file or directory
> I'm confused and don't know what I missed or where I went wrong.
>
> Ida.
>
>
>
>
> On Thu, Mar 11, 2021 at 6:03 PM Ida Delphine  wrote:
>
>> Okay. Thank you :)
>>
>> On Thu, 11 Mar 2021, 5:57 pm Gedare Bloom,  wrote:
>>
>>> On Thu, Mar 11, 2021 at 9:48 AM Ida Delphine  wrote:
>>> >
>>> > Thank you for your response. I am not working on the rtems.git/master
>>> branch. I'm not using it because earlier I tried downloading sources with
>>> it but I got this error
>>> > 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
>>> > So I decided to use the other alternative(get the sources from
>>> releases)
>>> >
>>> > Since I'm a GSoC applicant should I wait till the issue at the master
>>> branch is resolved?
>>> >
>>> Yes, that issue has been resolved so please try again. Hopefully,
>>> things work a bit better. We try not to break things, but unexpected
>>> problems come up from time to time, especially based on host OS
>>> dependencies.
>>>
>>> > Cheers,
>>> > Ida.
>>> >
>>> > On Thu, Mar 11, 2021 at 4:18 PM Gedare Bloom  wrote:
>>> >>
>>> >> On Thu, Mar 11, 2021 at 7:33 AM Ida Delphine 
>>> wrote:
>>> >> >
>>> >> > Hello everyone,
>>> >> > Was following the quick build documentation and had issues around
>>> where I have to do a manual BSP build.  In the last step of configuring the
>>> BSP, I ran this command:
>>> >> >
>>> >> > ./waf configure --prefix=$HOME/quick-start/rtems/5
>>> >> >
>>> >> Are you working on rtems.git/master branch or /5 branch? Note that you
>>> >> need to be sure to use a consistent compiler toolchain based on the
>>> >> version of RTEMS that you use.
>>> >>
>>> >> In rtems/5 branch we don't have waf support integrated yet. The
>>> >> upgrade to waf is happening currently on the master branch, which will
>>> >> eventually become the RTEMS version 6 release.
>>> >>
>>> >> For GSoC students we expect development to happen on the development
>>> >> head and not a release, so please make sure that you have the
>>> >> toolchain built from rtems-source-builder.git/master and the rtems
>>> >> source tree from rtems.git/master.
>>> >>
>>> >> > It didn't produce the expected output. I instead got:
>>> >> > bash: ./waf: No such file or directory
>>> >> > As a result I downloaded it with the command:
>>> 

Re: Error by building a BSP on Ubuntu 18.04

[Joel Sherrill]

On Thu, Mar 11, 2021 at 2:41 PM Olga Syrbachova 
wrote:

> It is RTEMS 5.1. I've checked the configure step. It seems to be fine. I
> get this:
>
> config.status: creating Makefile
>
> target architecture: sparc.
> available BSPs: erc32.
> 'make all' will build the following BSPs: erc32.
> other BSPs can be built with 'make RTEMS_BSP="bsp1 bsp2 ..."'
>
> config.status: creating Makefile
>
> And I still have the same error running make -j 2.
>

I wonder if you bootstrapped with the RTEMS autoconf/automake or the system
one.

type autoconf

and see which is picked up. Normally the RTEMS tools bin directory goes at
the
head of your PATH.

--joel

>
> On Thu, 11 Mar 2021 at 00:18, Gedare Bloom  wrote:
>
>> Hi Olga,
>>
>> On Wed, Mar 10, 2021 at 1:35 PM Olga Syrbachova 
>> wrote:
>> >
>> > Hi! I'm following this tutorial
>> https://docs.rtems.org/branches/master/user/installation/kernel.html.
>> > After successfully building a tool chain for the SPARC architecture in
>> step 5.1.1. I moved to the step 5.3.1. And then in step 5.3.4. I get an
>> error:
>> >
>> > olga@olga-H270M-DS3H:~/development/rtems/kernel/erc32$ make -j 2
>> > Making all in sparc-rtems5/c
>> > make[1]: Entering directory
>> '/home/olga/development/rtems/kernel/erc32/sparc-rtems5/c'
>> > Making all in .
>> > make[2]: Entering directory
>> '/home/olga/development/rtems/kernel/erc32/sparc-rtems5/c'
>> > make[2]: Nothing to be done for 'all-am'.
>> > make[2]: Leaving directory
>> '/home/olga/development/rtems/kernel/erc32/sparc-rtems5/c'
>> > Making all in erc32
>> > make[2]: Entering directory
>> '/home/olga/development/rtems/kernel/erc32/sparc-rtems5/c/erc32'
>> > make[2]: *** No rule to make target 'all'.  Stop.
>> > make[2]: Leaving directory
>> '/home/olga/development/rtems/kernel/erc32/sparc-rtems5/c/erc32'
>> > Makefile:362: recipe for target 'all-recursive' failed
>> > make[1]: *** [all-recursive] Error 1
>> > make[1]: Leaving directory
>> '/home/olga/development/rtems/kernel/erc32/sparc-rtems5/c'
>> > Makefile:482: recipe for target 'all-recursive' failed
>> > make: *** [all-recursive] Error 1
>> >
>> We would need a bit more. Is this on rtems5? Often, this kind of
>> failure indicates that configure failed, check your configure step.
>>
>> In RTEMS6 we will be getting rid of configure, but for now there is
>> support for both in the RTEMS6 'master' branch.
>>
>> > Did I miss something or am I doing something wrong? Many thanks in
>> advance for your help!
>> > ___
>> > 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: Installing rtems on 32 bit windows host machine

[Joel Sherrill]

On Thu, Mar 11, 2021 at 1:05 PM Alireza Banejad 
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-gccerror: 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
> http://lists.rtems.org/mailman/listinfo/users
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

ftw() Test Additions May Require rtems6 Tool Update

[Joel Sherrill]

  Hi

First, this does NOT impact rtems5.

On February 3, Eshan Dhawan posted additions to the RTEMS test suite for
ftw() and nftw() which he had previously worked to add to newlib. There
have been multiple updates to the rtems6 tool recipes in the RSB since then
so if you may already have ftw() and nftw() in your tools. But if you
attempt to build RTEMS with tests enabled and get an test link failure
because ftw() is undefined, you will need to update your tools.

I posted a few days ago on devel@ and there was no negative feedback. This
is just being courteous and pointing out some may hit a bump as we improve
POSIX Compliance moving forward with RTEMS.

I'd like to thank Eshan and point out that porting these methods was part
of his GSoC 2020 project. It has just taken this long to make this
particular piece of the project acceptable to Newlib, Cygwin, and RTEMS.
The ftw.h in newlib is used by both Cygwin and Newlib.

Thanks.

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

Re: RTEMS DEMO

[Joel Sherrill]

On Wed, Mar 10, 2021 at 5:26 AM Mingyu Li  wrote:

> Dear Eduardo,
>
> You may refer to the https://github.com/RTEMS/rtems/tree/master/testsuites
> ,
> and search for keywords like mutex for some simple demos.
>

There are lots of programs in the test suites but they tend to make
terrible
demos or even examples of how one would do things since many are
contorted to test specific paths and return values.

That said, testsuites/samples has some I like to show people but fileio
is by far the most interesting but it isn't a concurrency demo, it shows
off the shell.

For what I think you are doing, I think
https://git.rtems.org/rtems-examples/
is a better source of examples. There are a variety of programs more geared
to showing off a way of doing something. The hello and ticker variants are
just examples of how the same functional thing can be achieved differently
and have different footprints. led is a collection of ways to setup a 1
second
periodic activity to blink an LED. Some are reasonable, some are strictly
examples and not how to do a periodic activity in a real system. The POSIX
examples are just that -- examples of some POSIX thread services. There
are others in there.

libbsd has netshell which is cool if you are on a BSP with libbsd support
and that's what you want to show.

If you have some similar examples from the net that you want comparables,
point us to them. Good examples are hard to come by.



> Hope this helps. Please let me know if you have any further questions.
>

Examples are hard. Please feel free to give examples from other places
or some specific examples you have in mind.

--joel

>
> Bests,
> Maxul
>
> Eduardo Escalante  于2021年3月10日周三 上午6:35写道：
>
>> Hello, I am a University of Houston Electrical Engineering student. I am
>> in a
>> advanced microprocessor course this semester working on a presentation
>> involving RTEMS. One of my requirements is to demo RTEMS using a
>> microcontroller by using concepts such as semaphores, task, scheduling,
>> and
>> mutexes. Unfortunately, it has been a hassle finding a simple demo
>> showcasing a demo. Is there anyway someone can help me with this?--
>> kind regards,
>>
>> *Eduardo Escalante*
>> *University of Houston- *Computer Engineering student
>> ___
>> 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: Offline download of sources fails

[Joel Sherrill]

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.

--joel

>
> Cheers,
>
> Ida.
>
> ___
> 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: rtems-record-lttng: Corrupted timestamps after translating to CTF

[Joel Sherrill]

On Fri, Mar 5, 2021 at 10:45 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 05/03/2021 16:11, jan.som...@dlr.de wrote:
>
> > Some of the resulting CTF events have a very large timestamp. This only
> occurs for events of which are created by CPUs other than CPU0, but not all
> of them.
> > I ran rtems-record-lttng in gdb and could track it to
> record-client.c:176 (
> https://git.rtems.org/rtems-tools/tree/trace/record/record-client.c#n176).
> > There the (delta * ctx->to_bt_scaler ) causes an overflow and sets
> per_cpu->uptime.bt to a very large negative number which then later
> becomes a very large (positive) timestamp.
> >
> > I have some trouble figuring out what is going wrong here. The
> timestamps which are read from the rtems record events looks quite
> reasonable to me.
> > The to_bt_scaler is quite a large value and I don't fully get what it
> scales. Does someone have some hints?
> It could be related to ring buffer overflows. Do you get
> RTEMS_RECORD_PER_CPU_OVERFLOW items? There could be also some bugs in
> record-client.c. More unit tests for it would be helpful.
>

Asking stupidly, are there tests now? We didn't catch that libtrace was
missing in the new coverage reports:

https://ftp.rtems.org/pub/rtems/people/joel/coverage/coverage-2021-02-28/

I can add it to the queue that libtrace is added. If more subsystems
are missing that we want to track coverage on, please point them out.

--joel

>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
> ___
> 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: Ultra96-V2 Xilinx Zynq Cortex-R5 support

[Joel Sherrill]

I've cc'ed Kinsey Moore and asked him to subscribe to this list so he can
reply.

On Fri, Feb 19, 2021 at 11:46 AM Juan Solano  wrote:

> Hi all,
>
> I was looking for a bsp that supports a Cortex-R5 board and it seems the
> only one available is the Xilinx Zynq bsp, is that correct? It was not
> clear to me if this bsp is working on the Cortex-R5 processors of the board.
>

Kinsey did an R5 for a custom SOC that never saw silicon. He can tell you
what is in RTEMS and give you an idea what needs to be done.

I think as part of the aarch64 port Kinsey has submitted, we looked at this
board and decided not to get it because it didn't have wired Ethernet.
Someone has told me there is an add-on shield to add it, But I don't know
for sure or have a link to that.

Kinsey has been using another Avnet board and a board from Trenz. Both have
wired networking.


> Is the Avnet Ultra96-V2 a good recommendation to experiment with? I am
> currently just learning RTEMS, which makes other boards too expensive for
> my needs.
>

If you are just learning RTEMS, the first step we always recommend is a
simulator since they are free. Qemu has a Zynq simulation which I think all
the core developers use from time to time. Kinsey has spent a lot of time
on Qemu for the aarch64 and there are BSPs in the tree for that. He is
close to another round of submissions which he should talk about.

Simulators are great for getting familiar with things. The same cross
toolchain can be used and it is just a matter of switching BSPs. It works
as long as the simulator has enough IO for your initial steps.



--joel

>
> Rgds,
> Juan.
> ___
> 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: MVME2500 (qoriq_e500) no longer boots with RTEMS6

[Joel Sherrill]

On Fri, Feb 19, 2021 at 3:07 PM Christian Mauderer 
wrote:

> On 19/02/2021 19:52, junkes wrote:
> > On 2021-02-19 18:40, Gedare Bloom wrote:
> >> Advise how you built. We are starting to see some bitrot breakage in
> >> configuration. The cutover to waf will come soon, and I don't expect
> >> rtems6 release to support autoconf build of rtems itself. I suggest
> >> you change over to waf build of rtems kernel if you haven't yet.
> >
> > I use a build system from Christian Maurer:
> > https://gitlab.com/c-mauderer/rtems-simulation-environment
>
> It's not really a build system but only a Makefile that collects the
> commands so that I can run some quick tests. Please also note that this
> is no official repo. So don't be surprised if it changes or breaks.
>

This is exactly why I haven't been prone to share my rtems-cron-helpers
which includes a build_bsp script which makes waf and autoconf look the
same from the command line. It also can run the tester. Saves me a lot of
keyboarding  :)

--joel

>
> >
> > define build_toolchain
> >  rm -rf $(RSB)/rtems/build
> >  cd $(RSB)/rtems && ../source-builder/sb-set-builder \
> >  --prefix=$(PREFIX) \
> >  --log=$(RSB)/b-rsb-toolchain-$(1).log \
> >  $(RTEMS_VERSION)/rtems-$(1)
> >  rm -rf $(RSB)/rtems/build
> >
> > define build_bsp
> >  cd $(SRC_RTEMS) && ./waf clean || true
> >  cd $(SRC_RTEMS) && ./waf bsp_defaults --rtems-bsps=$(1)/$(2) >
> > config.ini
> >  cd $(SRC_RTEMS) && sed -i \
> >  -e "s|RTEMS_POSIX_API = False|RTEMS_POSIX_API = True|" \
> >  -e "s|CLOCK_DRIVER_USE_FAST_IDLE =
> > True|CLOCK_DRIVER_USE_FAST_IDLE = False|" \
> >  -e "s|BUILD_TESTS = False|BUILD_TESTS = True|" \
> >  config.ini
> >  cd $(SRC_RTEMS) && ./waf configure --prefix=$(PREFIX)
> >  cd $(SRC_RTEMS) && ./waf
> >  cd $(SRC_RTEMS) && ./waf install
> > endef
> >
> > define build_libbsd
> >  rm -rf $(SRC_LIBBSD)/build
> >  cd $(SRC_LIBBSD) && ./waf configure \
> >  --prefix=$(PREFIX) \
> >  --rtems-bsps=$(1)/$(2) \
> >  --enable-warnings \
> >  --optimization=2 \
> >  --rtems-version=$(RTEMS_VERSION)
> >  cd $(SRC_LIBBSD) && ./waf
> >  cd $(SRC_LIBBSD) && ./waf install
> > endef
> >
> >
> > I would like to switch to waf. But this is not available for the
> > kernel with RTEMS5 and unfortunately it does not work with RTEMS6.
> > Heinz > ___
> > 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: [EXTERNAL] Re: RTEMS 5.1: cmath compiler errors on m68k/uC5282

[Joel Sherrill]

On Wed, Feb 17, 2021 at 10:34 AM Nkwocha, Noble N. (IVV-1800) <
noble.n.nkwo...@nasa.gov> wrote:

>
> Is the plan proposed here going to preclude "long double" type
> implementations in RTEMS 5.1?
>

On some architectures, the hardware really supports 128-bit floating point.
For those, newlib
currently does not have libm long double methods. There is an RTEMS ticket
to locate and
port them from some BSD.  Only aarch64, i386, riscv, and x86_64 can be
depended on to
have hardware 128-bit float support. On all others (except m68k), long
double is the same
type as double from GCC and newlib has long double libm methods that just
rename the
double one to the long double name..

m68k is a bit odd in that you only have true 128-bit long double support if
the MC68881
FPU support is present which is basically 68020 w/FPU, 68030, 68040, and
68060. The
5282 or other Coldfires do not have hardware 128-bit long double support,
Long double
is the same as double. In this family, it varies by cpu model and when
possible, the static
inline versions from math-68881.h are used.

I **think** this is strictly a matter of a C++ wrapper change. The long
double support
in newlib has been stable for a LONG time.

--joel


>
> What happens to backward-compatibility?
>


>
> Thank you,
> Noble
>
>
>
> -Original Message-
> From: users [mailto:users-boun...@rtems.org] On Behalf Of Michael
> Davidsaver
> Sent: Wednesday, February 17, 2021 11:20 AM
> To: j...@rtems.org
> Cc: rtems-us...@rtems.org 
> Subject: [EXTERNAL] Re: RTEMS 5.1: cmath compiler errors on m68k/uC5282
>
> On 2/17/21 7:34 AM, Joel Sherrill wrote:
> > And indeed adding -std=c++98 seems to be a workaround.
> >
> >
> > EPICS most likely should use a newer C++ standard than that. C++03 is
> > C++98 with corrections. But it does not have long long because C++98
> > definition predated C99 finalization and C99 has long long. GCC
> > accepts long long and ll format specifier on printf() but will
> > complain only if you turn on -pedantic.
> >
> > You probably should be using C++11 or C++14 (bug fixed C++11).
>
> This is the plan.  When I say "workaround" there is an implied "temporary"
> as I expect that the underlying issue is fixable.
>
> The worst cases I can imagine are either patching out various "using
> ::acoshl" lines in the GCC cmath header or injecting some dummy definitions
> into the newlib math.h header like:
>
> > long double acoshl(long double) __attribute__((error("Not
> > implemented")));
> ___
> users mailing list
> users@rtems.org
>
> https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.rtems.org%2Fmailman%2Flistinfo%2Fusersdata=04%7C01%7Cnoble.n.nkwocha%40nasa.gov%7Cce534ba45de646800b5d08d8d35ff04f%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637491756316082153%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=AAyFjKv2KNCaYpCHeMhTQf37eAVcYJIY%2BDrqSoli2JM%3Dreserved=0
>
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users