AW: Naming convention for Rust target platforms

[Jan.Sommer]

Hm. Somehow Outlook botched the inline quotes of the html mail.
Does it work now?

Von: Joel Sherrill 
Gesendet: Mittwoch, 31. Januar 2024 16:57
An: Karel Gardas 
Cc: Frank Kühndel ; Sommer, Jan 
; devel@rtems.org
Betreff: Re: Naming convention for Rust target platforms

On Wed, Jan 31, 2024 at 12:31 AM Karel Gardas 
mailto:karel@functional.vision>> wrote:
On 1/30/24 18:13, Frank Kühndel wrote:
> Which name Rust accepts instead of "armv7a-rtems6-eabihf" depends on the
> naming convention of the Rust community:
>  https://docs.rust-embedded.org/embedonomicon/custom-target.html
> According to this file, the part `eabi` is for bare metal. Would this be
> correct when it is based on RTEMS? For example, a Linux target would be
> "x86_64-unknown-linux-gnu" where `gnu` means started by 'glibc'.

This is not completely fair to Jan as the x86_64 example is quite the
exception instead of a common norm in rust platforms names. But you
started with Linux so let's continue with Linux -- see the listing below.

Also IMHO this convention is not about rust per se, but IMHO about LLVM
way of doing things. GCC does that differently. So no C vs Rust, but GCC
vs. LLVM. Once Rust in GCC happen it'll be done in GCC more RTEMS used
way probably...

So for Rust/LLVM I think Jan's proposal is about right except that I
would strip '6' from rtems6. Neither OS (Linux, FreeBSD, NetBSD,
Windows, OpenBSD, VxWorks, etc) uses any version notion in the OS name
anyway... And also would strip 'a' from arm7a. We do not need to mention
'a' here explicitly since for 'm' we do have whole family of 'thumb*'
platform names... E.g. VxWorks in this particular case (ARMv7-A) uses:
armv7-wrs-vxworks-eabihf

WRS took the vendor part of the triple and I would not judge correctness
on what they did.

I have reached out to a contact at a company that has a long history of
supporting the GNU tools and has added Rust to their services in the past
few years. I would like to hear their opinion.

Thanks a lot, so far I just used the armv7a-none-eabihf as a baseline and added
“rtems” to it as I was more focused on the actual porting. Now, for going 
official
I have to fix the annoying little details. My hope is that if we get a good
solution here once and accepted by the Rust community that this paves
the way for other ports.

If I understand your comments regarding binutils correctly then maybe
Something like armv7-rtems-gnueabi(hf) would be more appropriate?

Cheers,
Jan




Cheers,
Karel

On these, they actually do distinguish the OS. I see Linux, Android, and Open
Harmony.

There is also a distinction in the target name for C library used. I see glibc,
musl, and ulibc.

The rest of the target names are multilib variants and appear to reflect a lack
of support for or use of multilibs.

IMO this naming seems to reflect a Linux focus and a lack of understanding
of the processor variations seen in the embedded world.

If this is the final pattern, it may work for RTEMS because people build their
own tools and tend to use 1-2 BSPs. But it will be painful for developers 
testing
multiple BSPs, etc. My cron sweeper builds almost 20 tool chains now. With this,
we would be between 100 and 200 I expect. Some of the BSPs will have a similar
enough processor to share a tool chain but a lot won't.

I am glad you are working through this and this issue isn't a blocker for 
ironing
out a long list of other potential issues.

--joel


$ rustc --print target-list|grep linux
aarch64-linux-android
aarch64-unknown-linux-gnu
aarch64-unknown-linux-gnu_ilp32
aarch64-unknown-linux-musl
aarch64-unknown-linux-ohos
aarch64_be-unknown-linux-gnu
aarch64_be-unknown-linux-gnu_ilp32
arm-linux-androideabi
arm-unknown-linux-gnueabi
arm-unknown-linux-gnueabihf
arm-unknown-linux-musleabi
arm-unknown-linux-musleabihf
armeb-unknown-linux-gnueabi
armv4t-unknown-linux-gnueabi
armv5te-unknown-linux-gnueabi
armv5te-unknown-linux-musleabi
armv5te-unknown-linux-uclibceabi
armv7-linux-androideabi
armv7-unknown-linux-gnueabi
armv7-unknown-linux-gnueabihf
armv7-unknown-linux-musleabi
armv7-unknown-linux-musleabihf
armv7-unknown-linux-ohos
armv7-unknown-linux-uclibceabi
armv7-unknown-linux-uclibceabihf
csky-unknown-linux-gnuabiv2
hexagon-unknown-linux-musl
i586-unknown-linux-gnu
i586-unknown-linux-musl
i686-linux-android
i686-unknown-linux-gnu
i686-unknown-linux-musl
loongarch64-unknown-linux-gnu
m68k-unknown-linux-gnu
mips-unknown-linux-gnu
mips-unknown-linux-musl
mips-unknown-linux-uclibc
mips64-openwrt-linux-musl
mips64-unknown-linux-gnuabi64
mips64-unknown-linux-muslabi64
mips64el-unknown-linux-gnuabi64
mips64el-unknown-linux-muslabi64
mipsel-unknown-linux-gnu
mipsel-unknown-linux-musl
mipsel-unknown-linux-uclibc
mipsisa32r6-unknown-linux-gnu
mipsisa32r6el-unknown-linux-gnu
mipsisa64r6-unknown-linux-gnuabi64
mipsisa64r6el-unknown-linux-gnuabi64
powerpc-unknown-linux-gnu
powerpc-unknown-linux-gnuspe
powerpc-unknown-linux-musl
powerpc64-unknown-linux-gnu
powerpc64-unknown-linux-musl

AW: Naming convention for Rust target platforms

[Jan.Sommer]

Von: Joel Sherrill 
Gesendet: Mittwoch, 31. Januar 2024 16:57
An: Karel Gardas 
Cc: Frank Kühndel ; Sommer, Jan 
; devel@rtems.org
Betreff: Re: Naming convention for Rust target platforms



On Wed, Jan 31, 2024 at 12:31 AM Karel Gardas 
mailto:karel@functional.vision>> wrote:
On 1/30/24 18:13, Frank Kühndel wrote:
> Which name Rust accepts instead of "armv7a-rtems6-eabihf" depends on the
> naming convention of the Rust community:
>  https://docs.rust-embedded.org/embedonomicon/custom-target.html
> According to this file, the part `eabi` is for bare metal. Would this be
> correct when it is based on RTEMS? For example, a Linux target would be
> "x86_64-unknown-linux-gnu" where `gnu` means started by 'glibc'.

This is not completely fair to Jan as the x86_64 example is quite the
exception instead of a common norm in rust platforms names. But you
started with Linux so let's continue with Linux -- see the listing below.

Also IMHO this convention is not about rust per se, but IMHO about LLVM
way of doing things. GCC does that differently. So no C vs Rust, but GCC
vs. LLVM. Once Rust in GCC happen it'll be done in GCC more RTEMS used
way probably...

So for Rust/LLVM I think Jan's proposal is about right except that I
would strip '6' from rtems6. Neither OS (Linux, FreeBSD, NetBSD,
Windows, OpenBSD, VxWorks, etc) uses any version notion in the OS name
anyway... And also would strip 'a' from arm7a. We do not need to mention
'a' here explicitly since for 'm' we do have whole family of 'thumb*'
platform names... E.g. VxWorks in this particular case (ARMv7-A) uses:
armv7-wrs-vxworks-eabihf

WRS took the vendor part of the triple and I would not judge correctness
on what they did.

I have reached out to a contact at a company that has a long history of
supporting the GNU tools and has added Rust to their services in the past
few years. I would like to hear their opinion.

Thanks a lot, so far I just used the armv7a-none-eabihf as a baseline and added
“rtems” to it as I was more focused on the actual porting. Now, for going 
official
I have to fix the annoying little details. My hope is that if we get a good
solution here once and accepted by the Rust community that this paves
the way for other ports.

If I understand your comments regarding binutils correctly then maybe
Something like armv7-rtems-gnueabi(hf) would be more appropriate?

Cheers,
Jan



Cheers,
Karel

On these, they actually do distinguish the OS. I see Linux, Android, and Open
Harmony.

There is also a distinction in the target name for C library used. I see glibc,
musl, and ulibc.

The rest of the target names are multilib variants and appear to reflect a lack
of support for or use of multilibs.

IMO this naming seems to reflect a Linux focus and a lack of understanding
of the processor variations seen in the embedded world.

If this is the final pattern, it may work for RTEMS because people build their
own tools and tend to use 1-2 BSPs. But it will be painful for developers 
testing
multiple BSPs, etc. My cron sweeper builds almost 20 tool chains now. With this,
we would be between 100 and 200 I expect. Some of the BSPs will have a similar
enough processor to share a tool chain but a lot won't.

I am glad you are working through this and this issue isn't a blocker for 
ironing
out a long list of other potential issues.

--joel


$ rustc --print target-list|grep linux
aarch64-linux-android
aarch64-unknown-linux-gnu
aarch64-unknown-linux-gnu_ilp32
aarch64-unknown-linux-musl
aarch64-unknown-linux-ohos
aarch64_be-unknown-linux-gnu
aarch64_be-unknown-linux-gnu_ilp32
arm-linux-androideabi
arm-unknown-linux-gnueabi
arm-unknown-linux-gnueabihf
arm-unknown-linux-musleabi
arm-unknown-linux-musleabihf
armeb-unknown-linux-gnueabi
armv4t-unknown-linux-gnueabi
armv5te-unknown-linux-gnueabi
armv5te-unknown-linux-musleabi
armv5te-unknown-linux-uclibceabi
armv7-linux-androideabi
armv7-unknown-linux-gnueabi
armv7-unknown-linux-gnueabihf
armv7-unknown-linux-musleabi
armv7-unknown-linux-musleabihf
armv7-unknown-linux-ohos
armv7-unknown-linux-uclibceabi
armv7-unknown-linux-uclibceabihf
csky-unknown-linux-gnuabiv2
hexagon-unknown-linux-musl
i586-unknown-linux-gnu
i586-unknown-linux-musl
i686-linux-android
i686-unknown-linux-gnu
i686-unknown-linux-musl
loongarch64-unknown-linux-gnu
m68k-unknown-linux-gnu
mips-unknown-linux-gnu
mips-unknown-linux-musl
mips-unknown-linux-uclibc
mips64-openwrt-linux-musl
mips64-unknown-linux-gnuabi64
mips64-unknown-linux-muslabi64
mips64el-unknown-linux-gnuabi64
mips64el-unknown-linux-muslabi64
mipsel-unknown-linux-gnu
mipsel-unknown-linux-musl
mipsel-unknown-linux-uclibc
mipsisa32r6-unknown-linux-gnu
mipsisa32r6el-unknown-linux-gnu
mipsisa64r6-unknown-linux-gnuabi64
mipsisa64r6el-unknown-linux-gnuabi64
powerpc-unknown-linux-gnu
powerpc-unknown-linux-gnuspe
powerpc-unknown-linux-musl
powerpc64-unknown-linux-gnu
powerpc64-unknown-linux-musl
powerpc64le-unknown-linux-gnu
powerpc64le-unknown-linux-musl
riscv32gc-unknown-linux-gnu

AW: Naming convention for Rust target platforms

[Jan.Sommer]

> -Ursprüngliche Nachricht-
> Von: Frank Kühndel 
> Gesendet: Dienstag, 30. Januar 2024 18:14
> An: Sommer, Jan ; devel@rtems.org
> Betreff: Re: Naming convention for Rust target platforms
> 
> Hello Jan,
> 
> On 1/29/24 19:41, jan.som...@dlr.de wrote:
> > Hi everyone,
> >
> > As mentioned in the other Rust thread, I am working on an initial Rust port
> for RTEMS.
> > The target platform for testing is the ARM Xilinx Zynq-7000 based BSPs.
> > Where I am not completely sure, is how to name the new target for Rust
> (see here the current list:https://doc.rust-lang.org/nightly/rustc/platform-
> support.html#tier-3).
> > The Rust ARM targets usually have the instruction set version and ABI as
> part of the name, e.g. armv7a-none-eabihf.
> > In RTEMS the arm-rtems6-gcc covers all supported ARM versions and
> different ABIs (i.e. hard-float or soft-float) collectively.
> >
> > So, for the Zynq and similar BSPs this would yield for the Rust target
> something like: armv7a-rtems6-eabihf (and possibly armv7a-rtems6-eabi).
> > Similarly, for other ARM BSPs additional Rust targets would need to be
> added. Which might add up to quite a  number of Rust targets over time.
> > Is this fine or do you see another solution?
> Just to make sure I understand your question correct:
> You want to push the RTEMS support you have developed (changes to Rust
> libraries, test framework, ability to have a main() in the Rust code for RTEMS
> etc.) to the official Rust repository - so that it is available to everyone 
> through
> the Rust nightly builds?
> 
> If this is so, then your question would be primarily a question to the Rust
> folks because it is their repository which would possibly receive many
> different entries for (similar?) RTEMS BSPs?
> 
> As far as I understand this, the steps for an RTEMS developer would be:
> 
> 1) Build the right RTEMS tools with the Source Builder. Here: ARM tools.
> 2) Build RTEMS (kernel) for the right (RTEMS) BSP
> 3) Install the Rust compiler and its tools
> 4) Create a Rust project
> 5) Fine tune some Rust configuration files in that project.
> Here the "armv7a-rtems6-eabihf" or something fitting the BSP would
> be used in a config file. The point is, it must be for the processor
> and BSP which matches the RTEMS tools and BSP selected in steps 1)
> and 2)
> 6) Make changes to the sample Rust code generated in the project
> or write the Rust code desired.
> 7) Load the nightly build of the Rust compiler.
> (The nightly is only needed as long as your code has not entered the
> stable build).
> 8) Compile the Rust program code with the Rust nightly compiler.
> 9) Link the Rust binary with the RTEMS libraries into a single
> executable (using a linker build by the RTEMS tools).

Yes, that is my current process.
There might be some possibility to simplify step 5 that you use the
Information of the pkgconfig to figure most things out. 
Then you only need to set which BSP you want to build for
and have the pkgconfig paths set correctly.
It's still WIP for me right now.

> Which name Rust accepts instead of "armv7a-rtems6-eabihf" depends on
> the naming convention of the Rust community:
>  https://docs.rust-embedded.org/embedonomicon/custom-target.html
> According to this file, the part `eabi` is for bare metal. Would this be 
> correct
> when it is based on RTEMS? For example, a Linux target would be "x86_64-
> unknown-linux-gnu" where `gnu` means started by 'glibc'.
> 
> By the way, section "Adding a new target" of
> https://doc.rust-lang.org/nightly/rustc/target-tier-policy.html
> points to an example:
> https://github.com/rust-lang/rust/pull/94872
> and that person discussed that triple name here:
> 
> https://rust-lang.zulipchat.com/#narrow/stream/131828-t-
> compiler/topic/LLVM.2Bmingw-w64.20Windows.20targets
> 
> Greetings,
> Frank
> >
> > Cheers,
> >
> >
> >  Jan
> >
> > Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR) German Aerospace
> > Center Institute for Software Technology | Software for Space Systems
> > and Interactive Visualization | Lilienthalplatz 7 | 38108 Braunschweig
> > | Germany
> >
> > Jan Sommer
> > Telephone +49 531 295-2494 | Telefax 0531 295-2767 |jan.som...@dlr.de
> > DLR.de/SC
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> >
> 
> --
> 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/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

AW: AW: Naming convention for Rust target platforms

[Jan.Sommer]

> -Ursprüngliche Nachricht-
> Von: Sebastian Huber 
> Gesendet: Mittwoch, 31. Januar 2024 08:08
> An: Sommer, Jan ; devel@rtems.org
> Betreff: Re: AW: Naming convention for Rust target platforms
> 
> On 30.01.24 13:45, jan.som...@dlr.de wrote:
> >> -Ursprüngliche Nachricht-
> >> Von: Sebastian Huber
> >> Gesendet: Dienstag, 30. Januar 2024 11:08
> >> An: devel
> >> Cc: Sommer, Jan
> >> Betreff: Re: Naming convention for Rust target platforms
> >>
> >> Hello Jan,
> >>
> >> On 29.01.24 19:41,jan.som...@dlr.de  wrote:
> >>> So, for the Zynq and similar BSPs this would yield for the Rust
> >>> target something like: armv7a-rtems6-eabihf (and possibly armv7a-
> rtems6-eabi).
> >>> Similarly, for other ARM BSPs additional Rust targets would need to
> >>> be added. Which might add up to quite a  number of Rust targets over
> time.
> >>> Is this fine or do you see another solution?
> >> how are the GCC machine flags determined (for linking)? Are they
> >> derived from the target name?
> >>
> > In my current setup I read the information from the pkgconfig files of the
> BSP.
> > I remember that at some point the pkgconfig was marked as
> > experimental. > Is that still the case or is it now an official part
> > of the RTEMS6
> release?
> 
> When RTEMS 6.1 is released, the pkg-config support should be way to get
> the BSP settings. It would be good to get a bit of user feedback how it is 
> used
> right now.

Great to hear.

> If you use the BSP provided flags, then what is the purpose of the Rust target
> name? For example, what happens if I just use "foobar"?
> 

The target triplet string is used in a couple of places of the build system and 
checked.
For example if "rtems" is in the OS part of the string, the build system checks 
if the OS is known.
In its simples form for example here: 
https://github.com/rust-lang/rust/blob/master/library/std/build.rs#L6

Also to clarify: I can use the BSP provided flags for compiling the user 
application.
For integrating a target into the compiler itself one needs to add a spec file 
there.
The stdlibs are compiled with this configuration (e.g. the one for 
armv7a-none-eabihf here: 
https://github.com/rust-lang/rust/blob/master/compiler/rustc_target/src/spec/targets/armv7a_none_eabihf.rs).
I use the BSP flags for passing the CPU and the linker commands.


> --
> embedded brains GmbH & Co. KG
> 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/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

AW: Naming convention for Rust target platforms

[Jan.Sommer]

> -Ursprüngliche Nachricht-
> Von: Sebastian Huber 
> Gesendet: Dienstag, 30. Januar 2024 11:08
> An: devel 
> Cc: Sommer, Jan 
> Betreff: Re: Naming convention for Rust target platforms
> 
> Hello Jan,
> 
> On 29.01.24 19:41, jan.som...@dlr.de wrote:
> > So, for the Zynq and similar BSPs this would yield for the Rust target
> > something like: armv7a-rtems6-eabihf (and possibly armv7a-rtems6-eabi).
> > Similarly, for other ARM BSPs additional Rust targets would need to be
> > added. Which might add up to quite a  number of Rust targets over time.
> > Is this fine or do you see another solution?
> 
> how are the GCC machine flags determined (for linking)? Are they derived
> from the target name?
> 

In my current setup I read the information from the pkgconfig files of the BSP.
I remember that at some point the pkgconfig was marked as experimental.
Is that still the case or is it now an official part of the RTEMS6 release?


> --
> embedded brains GmbH & Co. KG
> 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/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Naming convention for Rust target platforms

[Jan.Sommer]

Hi everyone,

As mentioned in the other Rust thread, I am working on an initial Rust port for 
RTEMS.
The target platform for testing is the ARM Xilinx Zynq-7000 based BSPs.
Where I am not completely sure, is how to name the new target for Rust (see 
here the current list: 
https://doc.rust-lang.org/nightly/rustc/platform-support.html#tier-3).
The Rust ARM targets usually have the instruction set version and ABI as part 
of the name, e.g. armv7a-none-eabihf.
In RTEMS the arm-rtems6-gcc covers all supported ARM versions and different 
ABIs (i.e. hard-float or soft-float) collectively.

So, for the Zynq and similar BSPs this would yield for the Rust target 
something like: armv7a-rtems6-eabihf (and possibly armv7a-rtems6-eabi).
Similarly, for other ARM BSPs additional Rust targets would need to be added. 
Which might add up to quite a  number of Rust targets over time.
Is this fine or do you see another solution?

Cheers, 


Jan

Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR)
German Aerospace Center
Institute for Software Technology | Software for Space Systems and Interactive 
Visualization | Lilienthalplatz 7 | 38108 Braunschweig | Germany

Jan Sommer
Telephone +49 531 295-2494 | Telefax 0531 295-2767 | jan.som...@dlr.de
DLR.de/SC

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

RE: New GPIO-API merged?

[Jan.Sommer]

We now found this general GPIO API here: 
https://github.com/RTEMS/rtems/blob/master/bsps/include/bsp/gpio.h
Is this the current one to use when implementing a new GPIO driver?


> -Original Message-
> From: devel  On Behalf Of jan.som...@dlr.de
> Sent: Mittwoch, 15. Februar 2023 08:40
> To: devel@rtems.org
> Subject: New GPIO-API merged?
> 
> Hello everyone,
> 
> Alex' patch reminded me that there was work done related a new general
> GPIO-API.
> Has that been finished? I tried to find the corresponding header files, but
> couldn't.
> So, I was wondering what the current status is.
> 
> Best regards,
> 
> Jan
> 
> 
> Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR) German Aerospace
> Center Institute for Software Technology | Software for Space Systems and
> Interactive Visualization | Lilienthalplatz 7 | 38108 Braunschweig | Germany
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: Interested for GSoC 2023

[Jan.Sommer]

> -Original Message-
> From: devel  On Behalf Of Karel Gardas
> Sent: Montag, 27. Februar 2023 09:16
> To: j...@rtems.org; Vihas Makwana 
> Cc: rtems-de...@rtems.org 
> Subject: Re: Interested for GSoC 2023
> 
> On 2/27/23 02:16, Joel Sherrill wrote:
> > Another GCC related project could be Rust RTEMS Support but I don't
> > know what that entails beyond turning it on and seeing what goes
> > wrong. I tried to build it last year and got far enough to decide to
> > wait before trying again.
> 
> Not sure how far you went. The process is generally:
> 
> (1) tune Rust compiler to cross-compile correctly for specific hardware/os
> platform. So basically you get no_std capable compiler
> 
> (2) review, patch and by using (1) cross-compile libc
> 
> (3) using sources from (1) and (2) build full stage (std enabled) rustc.
> 
> (4) tweak and tune tools (rustup/cargo etc.) whenever required to smooth
> sharp edges for RTEMS.
> 
> Here, I'm nearly finished with (1) for arm-rtems (e.g. cortex-aX not cortex-
> mX).
> 

Hi Karel,

Very interesting work. I am currently trying to reach the same goal.
The steps I came up with are a bit different:
A.) Build working llvm toolchain for RTEMS (figure out all flags etc., maybe 
building RTEMS with llvm as a bonus)
B.) Build rustc with the "RTEMS-llvm" as backend
C.) Start with no_std and then inch forward to building the stdlib

I work currently on step A (see my llvm experiments in the other thread) and 
started to look at the build stages for rustc.
If you have any tips for the configuration from your step (1), it would be 
greatly appreciated.
My hope is that with the results of step A I can reuse the libc from the 
standard rtems-gcc build environment as this is provided conveniently via rsb.
I am really looking forward to seeing rust supported on RTEMS.

Best regards,

Jan

PS: Maybe it is worth starting a new thread for exchanging ideas? I don't mean 
to hijack Vihas thread.

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

RE: [PATCH v1 0/1] Update rtems-llvm to version 11.1.0

[Jan.Sommer]

> -Original Message-
> From: Hesham Almatary 
> Sent: Mittwoch, 22. Februar 2023 14:34
> To: Sommer, Jan 
> Cc: j...@rtems.org; devel@rtems.org
> Subject: Re: [PATCH v1 0/1] Update rtems-llvm to version 11.1.0
> 
> On Tue, 21 Feb 2023 at 14:30,  wrote:
> >
> > Hello everyone,
> >
> > I tried to build a riscv BSP with the information from Hesham. Thanks again.
> > It now compiles the files, but produces a lot of warnings and fails to link 
> > in
> the end.
> >
> > The warnings are of this type
> > ../../../cpukit/score/cpu/riscv/riscv-exception-handler.S:48:10: warning:
> unknown option, expected 'push', 'pop', 'rvc', 'norvc', 'relax' or 'norelax'
> >.option arch, +zicsr
> >^
> Does this happen if you use the latest LLVM?
> 

The latest I tried so far was llvm14 and there it happened. Do you know if this 
might be solved in more recent versions?
llvm14 was the latest I could build with the shipped compilers of my 
workstation.

> > And in the end the linker cannot find the " _RISCV_Exception_handler", so
> I guess the warning prevents those symbols from being built. My best guess
> is that it is related to this llvm issue: https://reviews.llvm.org/D141666 
> which
> is actively worked on as of this month and we probably have to wait for this
> to become part of llvm.
> >
> Are you sure the right linker is used (lld?) I remember I had to add a custom
> patch for RTEMS to be able to use the right linker and options.
> https://github.com/CTSRD-
> CHERI/clang/blob/master/lib/Driver/ToolChains/RTEMS.cpp
> 

So far I used the linker of the rtems6-gcc toolchain.

> > Out of curiosity, I tried the same with the Zedboard BSP. There, linking
> passed and I got to this point for base_sp.exe:
> > *** BEGIN OF TEST OH ***
> > *** TEST VERSION: 6.0.0.c0fad60c59bf14b9d1a4eb3d76f872e2cf43e7b8
> > *** TEST STATE: (null)
> > *** TEST BUILD:
> > *** TEST TOOLS: Clang 11.1.0
> > (https://git.rtems.org/rtems-source-builder
> > 64df106288cf6c4289a9c78850a82bfb2b41caa2)
> > Creating and starting an application task
> >
> > *** FATAL ***
> > fatal source: 0 (INTERNAL_ERROR_CORE)
> > fatal code: 31
> (INTERNAL_ERROR_BAD_THREAD_DISPATCH_ENVIRONMENT)
> > RTEMS version: 6.0.0.c0fad60c59bf14b9d1a4eb3d76f872e2cf43e7b8
> > RTEMS tools: Clang 11.1.0 (https://git.rtems.org/rtems-source-builder
> > 64df106288cf6c4289a9c78850a82bfb2b41caa2)
> > executing thread is NULL
> >
> > So, let's say it's something. Now at least I have a system to debug. I will 
> > also
> have a look how to make the process more accessible. At the moment things
> are just crowbarred into the build system to make it work.
> >
> > Coming back to the patch: If there are no objections I would like to push
> the commit for llvm11.
> > Chances are that further updates are to come as I progress.
> >
> > Best regards,
> >
> > Jan
> >
> > > -Original Message-
> > > From: Hesham Almatary 
> > > Sent: Mittwoch, 15. Februar 2023 11:17
> > > To: Sommer, Jan 
> > > Cc: j...@rtems.org; devel@rtems.org
> > > Subject: Re: [PATCH v1 0/1] Update rtems-llvm to version 11.1.0
> > >
> > > On Wed, 15 Feb 2023 at 09:22,  wrote:
> > > >
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Hesham Almatary 
> > > > > Sent: Montag, 13. Februar 2023 16:19
> > > > > To: Sommer, Jan 
> > > > > Cc: j...@rtems.org; devel@rtems.org
> > > > > Subject: Re: [PATCH v1 0/1] Update rtems-llvm to version 11.1.0
> > > > >
> > > > > On Mon, 13 Feb 2023 at 12:12,  wrote:
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: Joel Sherrill 
> > > > > > > Sent: Freitag, 10. Februar 2023 15:21
> > > > > > > To: Sommer, Jan 
> > > > > > > Cc: devel@rtems.org
> > > > > > > Subject: Re: [PATCH v1 0/1] Update rtems-llvm to version
> > > > > > > 11.1.0
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Feb 10, 2023 at 3:16 AM Jan Sommer
> > > > > > > mailto:jan.som...@dlr.de> > wrote:
> > > > > > >
> > > > > > >
> > > > > > >   Hello,
> > > > > > >
> > > > > > >   I couldn't get the rtems-llvm buildset to work.
> > > > > > >   As it was building llvm8 which is not that modern, I
> > > > > > > just tried to
> > > build
> > > > > > >   a more recent version with the scripts.
> > > > > > >   It works with llvm11. Are there any objections to updating?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Nope. Please feel free to add this.
> > > > > > >
> > > > > > >
> > > > > > >   And should we keep the rtems-llvm-8.cfg or should I
> > > > > > > remove this with
> > > > > > >   this patch?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >  My main concern is if the architectures that built with
> > > > > > > llvm 8 still build with llvm 11. I think that's only SPARC and 
> > > > > > > RISC-V.
> > > > > > > Are there
> > > > > others?
> > > > > > >
> > > > > Why not the latest LLVM (especially to pick up the latest RISC-V
> > > > > fixes/support). I am not sure how mature the RISC-V support is
> > > 

RE: [PATCH v1 0/1] Update rtems-llvm to version 11.1.0

[Jan.Sommer]

Hello everyone,

I tried to build a riscv BSP with the information from Hesham. Thanks again.
It now compiles the files, but produces a lot of warnings and fails to link in 
the end.

The warnings are of this type
../../../cpukit/score/cpu/riscv/riscv-exception-handler.S:48:10: warning: 
unknown option, expected 'push', 'pop', 'rvc', 'norvc', 'relax' or 'norelax'
   .option arch, +zicsr
   ^
And in the end the linker cannot find the " _RISCV_Exception_handler", so I 
guess the warning prevents those symbols from being built. My best guess is 
that it is related to this llvm issue: https://reviews.llvm.org/D141666 which 
is actively worked on as of this month and we probably have to wait for this to 
become part of llvm.

Out of curiosity, I tried the same with the Zedboard BSP. There, linking passed 
and I got to this point for base_sp.exe:
*** BEGIN OF TEST OH ***
*** TEST VERSION: 6.0.0.c0fad60c59bf14b9d1a4eb3d76f872e2cf43e7b8
*** TEST STATE: (null)
*** TEST BUILD:
*** TEST TOOLS: Clang 11.1.0 (https://git.rtems.org/rtems-source-builder 
64df106288cf6c4289a9c78850a82bfb2b41caa2)
Creating and starting an application task

*** FATAL ***
fatal source: 0 (INTERNAL_ERROR_CORE)
fatal code: 31 (INTERNAL_ERROR_BAD_THREAD_DISPATCH_ENVIRONMENT)
RTEMS version: 6.0.0.c0fad60c59bf14b9d1a4eb3d76f872e2cf43e7b8
RTEMS tools: Clang 11.1.0 (https://git.rtems.org/rtems-source-builder 
64df106288cf6c4289a9c78850a82bfb2b41caa2)
executing thread is NULL

So, let's say it's something. Now at least I have a system to debug. I will 
also have a look how to make the process more accessible. At the moment things 
are just crowbarred into the build system to make it work.

Coming back to the patch: If there are no objections I would like to push the 
commit for llvm11.
Chances are that further updates are to come as I progress.

Best regards,

Jan

> -Original Message-
> From: Hesham Almatary 
> Sent: Mittwoch, 15. Februar 2023 11:17
> To: Sommer, Jan 
> Cc: j...@rtems.org; devel@rtems.org
> Subject: Re: [PATCH v1 0/1] Update rtems-llvm to version 11.1.0
> 
> On Wed, 15 Feb 2023 at 09:22,  wrote:
> >
> >
> >
> > > -Original Message-
> > > From: Hesham Almatary 
> > > Sent: Montag, 13. Februar 2023 16:19
> > > To: Sommer, Jan 
> > > Cc: j...@rtems.org; devel@rtems.org
> > > Subject: Re: [PATCH v1 0/1] Update rtems-llvm to version 11.1.0
> > >
> > > On Mon, 13 Feb 2023 at 12:12,  wrote:
> > > >
> > > > > -Original Message-
> > > > > From: Joel Sherrill 
> > > > > Sent: Freitag, 10. Februar 2023 15:21
> > > > > To: Sommer, Jan 
> > > > > Cc: devel@rtems.org
> > > > > Subject: Re: [PATCH v1 0/1] Update rtems-llvm to version 11.1.0
> > > > >
> > > > >
> > > > >
> > > > > On Fri, Feb 10, 2023 at 3:16 AM Jan Sommer  > > > >  > wrote:
> > > > >
> > > > >
> > > > >   Hello,
> > > > >
> > > > >   I couldn't get the rtems-llvm buildset to work.
> > > > >   As it was building llvm8 which is not that modern, I just tried 
> > > > > to
> build
> > > > >   a more recent version with the scripts.
> > > > >   It works with llvm11. Are there any objections to updating?
> > > > >
> > > > >
> > > > >
> > > > > Nope. Please feel free to add this.
> > > > >
> > > > >
> > > > >   And should we keep the rtems-llvm-8.cfg or should I remove
> > > > > this with
> > > > >   this patch?
> > > > >
> > > > >
> > > > >
> > > > >  My main concern is if the architectures that built with llvm 8
> > > > > still build with llvm 11. I think that's only SPARC and RISC-V.
> > > > > Are there
> > > others?
> > > > >
> > > Why not the latest LLVM (especially to pick up the latest RISC-V
> > > fixes/support). I am not sure how mature the RISC-V support is in
> > > LLVM 8, if it was supported at all.
> > >
> >
> > Yes, that is also my goal. I got llvm11 building with only small changes to 
> > the
> buildset and wanted to go from there.
> > In the meantime I also managed to build llvm up to 14 locally. Once I have
> all the bits and pieces working to some degree I will probably consolidate to 
> a
> more recent version.
> >
> Seems like a good plan.
> 
> > > > > I guess that points to me not knowing the list of architectures
> > > > > that are expected to work. I wonder where we would keep this
> information.
> > > > > Any thoughts?
> > > > >
> > > >
> > > > Thanks for the information.
> > > > I tried to build those to check if they still work and failed, but
> > > > given that the
> > > information I could find is sparse I could very well be the problem.
> > > > What I did is:
> > > > - Build the gcc toolchains for sparc and riscv (as far as I
> > > > understand we need the binutils and libc from that)
> > > I haven't tried doing that for RISC-V. I used to build newlib
> > > manually, and not rely on GCC/binutils.
> > >
> >
> > Ah, I see. Just for clarification you also cross-built newlib with clang?
> >
> Yes, besides compiler-rt (LLVM's version of libgcc). But you don't need to go
> 

RE: [PATCH v1 0/1] Update rtems-llvm to version 11.1.0

[Jan.Sommer]

> -Original Message-
> From: Hesham Almatary 
> Sent: Montag, 13. Februar 2023 16:19
> To: Sommer, Jan 
> Cc: j...@rtems.org; devel@rtems.org
> Subject: Re: [PATCH v1 0/1] Update rtems-llvm to version 11.1.0
> 
> On Mon, 13 Feb 2023 at 12:12,  wrote:
> >
> > > -Original Message-
> > > From: Joel Sherrill 
> > > Sent: Freitag, 10. Februar 2023 15:21
> > > To: Sommer, Jan 
> > > Cc: devel@rtems.org
> > > Subject: Re: [PATCH v1 0/1] Update rtems-llvm to version 11.1.0
> > >
> > >
> > >
> > > On Fri, Feb 10, 2023 at 3:16 AM Jan Sommer  > >  > wrote:
> > >
> > >
> > >   Hello,
> > >
> > >   I couldn't get the rtems-llvm buildset to work.
> > >   As it was building llvm8 which is not that modern, I just tried to 
> > > build
> > >   a more recent version with the scripts.
> > >   It works with llvm11. Are there any objections to updating?
> > >
> > >
> > >
> > > Nope. Please feel free to add this.
> > >
> > >
> > >   And should we keep the rtems-llvm-8.cfg or should I remove
> > > this with
> > >   this patch?
> > >
> > >
> > >
> > >  My main concern is if the architectures that built with llvm 8
> > > still build with llvm 11. I think that's only SPARC and RISC-V. Are there
> others?
> > >
> Why not the latest LLVM (especially to pick up the latest RISC-V
> fixes/support). I am not sure how mature the RISC-V support is in LLVM 8, if
> it was supported at all.
> 

Yes, that is also my goal. I got llvm11 building with only small changes to the 
buildset and wanted to go from there.
In the meantime I also managed to build llvm up to 14 locally. Once I have all 
the bits and pieces working to some degree I will probably consolidate to a 
more recent version.

> > > I guess that points to me not knowing the list of architectures that
> > > are expected to work. I wonder where we would keep this information.
> > > Any thoughts?
> > >
> >
> > Thanks for the information.
> > I tried to build those to check if they still work and failed, but given 
> > that the
> information I could find is sparse I could very well be the problem.
> > What I did is:
> > - Build the gcc toolchains for sparc and riscv (as far as I understand
> > we need the binutils and libc from that)
> I haven't tried doing that for RISC-V. I used to build newlib manually, and 
> not
> rely on GCC/binutils.
> 

Ah, I see. Just for clarification you also cross-built newlib with clang?

> > - Build the rtems-llvm build set
> > - Generate a config for waf using: ./waf bspdefaults
> > --rtems-bsps='sparc/gr712rc' --rtems-compiler=clang > sparc.cfg
> > - Configure the build with the config: ./waf configure
> > --rtems-config=sparc.cfg -$INSTALL_DIR
> > - Run ./waf
> > - I also tried with some riscv BSPs with the same results.
> >
> > The build fails with missing std headers (stddef.h).
> > Looking at the generated config file there are only small differences to the
> one for gcc (essentially the compiler name changed to clang).
> > And the verbose output confirms that the gcc toolchain is not part of the
> include paths.
> > I didn't find an obvious option in "waf configure" to add this.
> I added [1] an option for "sysroot" in the old build system so that Clang 
> could
> find the C library. I don't think that was integrated in waf. However, I was 
> also
> using CHERI-based LLVM with a modified Driver so that it automatically
> fetches the C library (after it gets manually built and installed under a
> convenient LLVM) related to the LLVM install path.
> 
> [1]
> https://github.com/RTEMS/rtems/commit/94481cedc4165f6a49ef528709825
> 1740922fee1
> 

Ah, thanks for this. I think this is a good starting point to experiment with.

Best regards,

Jan

> > If you say that building worked only for few BSPs. Do you remember which
> ones and if there was some magic to do first?
> > Then I could try to reproduce this with the llvm11 compiler.
> I don't think they'll build as is without a few modifications to the build
> system. Simplest thing to do is to use GCC's libgcc and newlib and add a
> "sysroot" or "-L -I" options to the current build system for them.
> 
> >
> > Best regards,
> >
> > Jan
> >
> > > --joel
> > >
> > >
> > >   Have a nice weekend,
> > >
> > >   Jan
> > >
> > >   Jan Sommer (1):
> > > rtems-tools: Update rtems-llvm to version 11.1.0
> > >
> > >rtems/config/6/rtems-llvm.bset   |  2 +-
> > >rtems/config/tools/rtems-llvm-11.1.0.cfg | 21
> > > +
> > >source-builder/config/llvm-common-1.cfg  |  6 +++---
> > >3 files changed, 25 insertions(+), 4 deletions(-)
> > >create mode 100644 rtems/config/tools/rtems-llvm-11.1.0.cfg
> > >
> > >   --
> > >   2.25.1
> > >
> > >   ___
> > >   devel mailing list
> > >   devel@rtems.org 
> > >   http://lists.rtems.org/mailman/listinfo/devel
> > >
> >
> > 

New GPIO-API merged?

[Jan.Sommer]

Hello everyone,

Alex' patch reminded me that there was work done related a new general GPIO-API.
Has that been finished? I tried to find the corresponding header files, but 
couldn't.
So, I was wondering what the current status is.

Best regards,

Jan


Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR)
German Aerospace Center
Institute for Software Technology | Software for Space Systems and Interactive 
Visualization | Lilienthalplatz 7 | 38108 Braunschweig | Germany

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

RE: [PATCH v1 0/1] Update rtems-llvm to version 11.1.0

[Jan.Sommer]

> -Original Message-
> From: Joel Sherrill 
> Sent: Freitag, 10. Februar 2023 15:21
> To: Sommer, Jan 
> Cc: devel@rtems.org
> Subject: Re: [PATCH v1 0/1] Update rtems-llvm to version 11.1.0
> 
> 
> 
> On Fri, Feb 10, 2023 at 3:16 AM Jan Sommer   > wrote:
> 
> 
>   Hello,
> 
>   I couldn't get the rtems-llvm buildset to work.
>   As it was building llvm8 which is not that modern, I just tried to build
>   a more recent version with the scripts.
>   It works with llvm11. Are there any objections to updating?
> 
> 
> 
> Nope. Please feel free to add this.
> 
> 
>   And should we keep the rtems-llvm-8.cfg or should I remove this
> with
>   this patch?
> 
> 
> 
>  My main concern is if the architectures that built with llvm 8 still build 
> with
> llvm 11. I think that's only SPARC and RISC-V. Are there others?
> 
> I guess that points to me not knowing the list of architectures that are
> expected to work. I wonder where we would keep this information. Any
> thoughts?
> 

Thanks for the information.
I tried to build those to check if they still work and failed, but given that 
the information I could find is sparse I could very well be the problem.
What I did is:
- Build the gcc toolchains for sparc and riscv (as far as I understand we need 
the binutils and libc from that)
- Build the rtems-llvm build set
- Generate a config for waf using: ./waf bspdefaults 
--rtems-bsps='sparc/gr712rc' --rtems-compiler=clang > sparc.cfg
- Configure the build with the config: ./waf configure --rtems-config=sparc.cfg 
-$INSTALL_DIR 
- Run ./waf
- I also tried with some riscv BSPs with the same results.

The build fails with missing std headers (stddef.h).
Looking at the generated config file there are only small differences to the 
one for gcc (essentially the compiler name changed to clang).
And the verbose output confirms that the gcc toolchain is not part of the 
include paths.
I didn't find an obvious option in "waf configure" to add this.
If you say that building worked only for few BSPs. Do you remember which ones 
and if there was some magic to do first?
Then I could try to reproduce this with the llvm11 compiler.

Best regards,

Jan

> --joel
> 
> 
>   Have a nice weekend,
> 
>   Jan
> 
>   Jan Sommer (1):
> rtems-tools: Update rtems-llvm to version 11.1.0
> 
>rtems/config/6/rtems-llvm.bset   |  2 +-
>rtems/config/tools/rtems-llvm-11.1.0.cfg | 21
> +
>source-builder/config/llvm-common-1.cfg  |  6 +++---
>3 files changed, 25 insertions(+), 4 deletions(-)
>create mode 100644 rtems/config/tools/rtems-llvm-11.1.0.cfg
> 
>   --
>   2.25.1
> 
>   ___
>   devel mailing list
>   devel@rtems.org 
>   http://lists.rtems.org/mailman/listinfo/devel
> 

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

RE: GitLab and BuildBot

[Jan.Sommer]

> -Original Message-
> From: devel  On Behalf Of Chris Johns
> Sent: Donnerstag, 9. Februar 2023 23:26
> To: Christian MAUDERER ;
> RTEMS Devel 
> Subject: Re: GitLab and BuildBot
> 
> 
> Thanks and it is great to get the feedback. We normally only ever hear from
> people when it does not work :)
> 

Hi Chris,

I wasn't aware of this as I am not so much involved with the trac.
What I got from this thread is that there is currently work on the way to move 
the git repositories and development process to a (self-hosted) Gitlab.
That would be amazing. We use Gitlab internally as well and are quite happy 
with it.

So, looking forward to the new Gitlab.

Best regards, 

Jan

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

RE: docs not building to PDF

[Jan.Sommer]

There is also Kroki: https://kroki.io/
It does the rendering of multiple text based diagram languages, including 
PlantUML, Mermaid, Ditaa and a bunch of others.
Then you only need one tool for it.

Best regards,

Jan

> -Original Message-
> From: devel  On Behalf Of Chris Johns
> Sent: Thursday, October 13, 2022 6:22 AM
> To: Sam Price 
> Cc: Development 
> Subject: Re: docs not building to PDF
>
> On 13/10/2022 3:15 pm, Sam Price wrote:
> > Yes
> > https://github.com/mermaid-js/mermaid-cli
> > 
> >
> > There are command line tools so it can be integrated into pipelines.
> >
> >
> >   Convert Mermaid mmd Diagram File To SVG
> >
> > mmdc -i input.mmd -o output.svg
> >
> >
> >
> >  th
> > eme-and-transparent-background>Create A PNG With A Dark Theme And
> > Transparent Background
> >
> > mmdc -i input.mmd -o output.png -t dark -b transparent
> >
> > You dont get much control though over how it places boxes. But it does
> > sequence diagrams.
> > Im using it for gantt charts.
> >
> > Its one of the mainstream alternatives to plantuml
> >
>
> This tool looks really good and it fits the pattern of tools we can use.
>
> Thanks for this.
> Chris
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel


smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: libbsd fails to link on i386

[Jan.Sommer]

Hi Joel,



Sorry for the long delay.

I tried to reproduce the error locally. For me building rtems and rtems-libbsd 
master for pc386 and pc686 works.

I get some undefined references for the 6-freebsd-12 branch though.

Which branch of rtems-libbsd did you use?



Best regards,



Jan





From: devel  On Behalf Of jan.som...@dlr.de
Sent: Thursday, August 18, 2022 8:09 PM
To: j...@rtems.org; devel@rtems.org
Subject: RE: libbsd fails to link on i386



Hi Joel,



I remember I spent some time fiddling with the bus.h include order.

I can try to have a look at it some time next week.



Best regards,



Jan



From: devel <  devel-boun...@rtems.org> On 
Behalf Of Joel Sherrill
Sent: Wednesday, August 17, 2022 11:24 PM
To:   rtems-de...@rtems.org < 
 devel@rtems.org>
Subject: libbsd fails to link on i386



Hi



I think the wrong bus.h must be being included somewhere. These are static 
inline methods on the i386. Hopefully a simple patch for someone who knows 
what to do:



[1992/2039] Linking build/i386-rtems6-pc386-default/ftpd01.exe
/home/joel/rtems-work/tools/6/lib/gcc/i386-rtems6/12.1.1/../../../../i386-rtems6/bin/ld:
 
./libbsd.a(rtems-kernel-bus-dma.c.20.o): in function `_bsd_bus_dmamem_alloc':
/home/joel/rtems-work/rtems-libbsd/build/i386-rtems6-pc386-default/../../rtemsbsd/rtems/rtems-kernel-bus-dma.c:264:
 
undefined reference to `bsp_bus_space_write_1'
collect2: error: ld returned 1 exit status

/home/joel/rtems-work/tools/6/lib/gcc/i386-rtems6/12.1.1/../../../../i386-rtems6/bin/ld:
 
./libbsd.a(rtems-kernel-bus-dma.c.20.o): in function `_bsd_bus_dmamem_alloc':
/home/joel/rtems-work/rtems-libbsd/build/i386-rtems6-pc386-default/../../rtemsbsd/rtems/rtems-kernel-bus-dma.c:264:
 
undefined reference to `bsp_bus_space_write_1'
collect2: error: ld returned 1 exit status

/home/joel/rtems-work/tools/6/lib/gcc/i386-rtems6/12.1.1/../../../../i386-rtems6/bin/ld:
 
./libbsd.a(rtems-kernel-bus-dma.c.20.o): in function `_bsd_bus_dmamem_alloc':
/home/joel/rtems-work/rtems-libbsd/build/i386-rtems6-pc386-default/../../rtemsbsd/rtems/rtems-kernel-bus-dma.c:264:
 
undefined reference to `bsp_bus_space_write_1'
collect2: error: ld returned 1 exit status

/home/joel/rtems-work/tools/6/lib/gcc/i386-rtems6/12.1.1/../../../../i386-rtems6/bin/ld:
 
./libbsd.a(rtems-kernel-bus-dma.c.20.o): in function `_bsd_bus_dmamem_alloc':
/home/joel/rtems-work/rtems-libbsd/build/i386-rtems6-pc386-default/../../rtemsbsd/rtems/rtems-kernel-bus-dma.c:264:
 
undefined reference to `bsp_bus_space_write_1'
collect2: error: ld returned 1 exit status

/home/joel/rtems-work/tools/6/lib/gcc/i386-rtems6/12.1.1/../../../../i386-rtems6/bin/ld:
 
./libbsd.a(rtems-kernel-bus-dma.c.20.o): in function `_bsd_bus_dmamem_alloc':
/home/joel/rtems-work/rtems-libbsd/build/i386-rtems6-pc386-default/../../rtemsbsd/rtems/rtems-kernel-bus-dma.c:264:
 
undefined reference to `bsp_bus_space_write_1'
collect2: error: ld returned 1 exit status

/home/joel/rtems-work/tools/6/lib/gcc/i386-rtems6/12.1.1/../../../../i386-rtems6/bin/ld:
 
./libbsd.a(rtems-kernel-bus-dma.c.20.o): in function `_bsd_bus_dmamem_alloc':
/home/joel/rtems-work/rtems-libbsd/build/i386-rtems6-pc386-default/../../rtemsbsd/rtems/rtems-kernel-bus-dma.c:264:
 
undefined reference to `bsp_bus_space_write_1'
collect2: error: ld returned 1 exit status

/home/joel/rtems-work/tools/6/lib/gcc/i386-rtems6/12.1.1/../../../../i386-rtems6/bin/ld:
 
./libbsd.a(rtems-kernel-bus-dma.c.20.o): in function `_bsd_bus_dmamem_alloc':
/home/joel/rtems-work/rtems-libbsd/build/i386-rtems6-pc386-default/../../rtemsbsd/rtems/rtems-kernel-bus-dma.c:264:
 
undefined reference to `bsp_bus_space_write_1'
collect2: error: ld returned 1 exit status

/home/joel/rtems-work/tools/6/lib/gcc/i386-rtems6/12.1.1/../../../../i386-rtems6/bin/ld:
 
./libbsd.a(rtems-kernel-bus-dma.c.20.o): in function `_bsd_bus_dmamem_alloc':
/home/joel/rtems-work/rtems-libbsd/build/i386-rtems6-pc386-default/../../rtemsbsd/rtems/rtems-kernel-bus-dma.c:264:
 
undefined reference to `bsp_bus_space_write_1'
collect2: error: ld returned 1 exit status



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: libbsd fails to link on i386

[Jan.Sommer]

Hi Joel,



I remember I spent some time fiddling with the bus.h include order.

I can try to have a look at it some time next week.



Best regards,



Jan



From: devel  On Behalf Of Joel Sherrill
Sent: Wednesday, August 17, 2022 11:24 PM
To: rtems-de...@rtems.org 
Subject: libbsd fails to link on i386



Hi



I think the wrong bus.h must be being included somewhere. These are static 
inline methods on the i386. Hopefully a simple patch for someone who knows 
what to do:



[1992/2039] Linking build/i386-rtems6-pc386-default/ftpd01.exe
/home/joel/rtems-work/tools/6/lib/gcc/i386-rtems6/12.1.1/../../../../i386-rtems6/bin/ld:
 
./libbsd.a(rtems-kernel-bus-dma.c.20.o): in function `_bsd_bus_dmamem_alloc':
/home/joel/rtems-work/rtems-libbsd/build/i386-rtems6-pc386-default/../../rtemsbsd/rtems/rtems-kernel-bus-dma.c:264:
 
undefined reference to `bsp_bus_space_write_1'
collect2: error: ld returned 1 exit status

/home/joel/rtems-work/tools/6/lib/gcc/i386-rtems6/12.1.1/../../../../i386-rtems6/bin/ld:
 
./libbsd.a(rtems-kernel-bus-dma.c.20.o): in function `_bsd_bus_dmamem_alloc':
/home/joel/rtems-work/rtems-libbsd/build/i386-rtems6-pc386-default/../../rtemsbsd/rtems/rtems-kernel-bus-dma.c:264:
 
undefined reference to `bsp_bus_space_write_1'
collect2: error: ld returned 1 exit status

/home/joel/rtems-work/tools/6/lib/gcc/i386-rtems6/12.1.1/../../../../i386-rtems6/bin/ld:
 
./libbsd.a(rtems-kernel-bus-dma.c.20.o): in function `_bsd_bus_dmamem_alloc':
/home/joel/rtems-work/rtems-libbsd/build/i386-rtems6-pc386-default/../../rtemsbsd/rtems/rtems-kernel-bus-dma.c:264:
 
undefined reference to `bsp_bus_space_write_1'
collect2: error: ld returned 1 exit status

/home/joel/rtems-work/tools/6/lib/gcc/i386-rtems6/12.1.1/../../../../i386-rtems6/bin/ld:
 
./libbsd.a(rtems-kernel-bus-dma.c.20.o): in function `_bsd_bus_dmamem_alloc':
/home/joel/rtems-work/rtems-libbsd/build/i386-rtems6-pc386-default/../../rtemsbsd/rtems/rtems-kernel-bus-dma.c:264:
 
undefined reference to `bsp_bus_space_write_1'
collect2: error: ld returned 1 exit status

/home/joel/rtems-work/tools/6/lib/gcc/i386-rtems6/12.1.1/../../../../i386-rtems6/bin/ld:
 
./libbsd.a(rtems-kernel-bus-dma.c.20.o): in function `_bsd_bus_dmamem_alloc':
/home/joel/rtems-work/rtems-libbsd/build/i386-rtems6-pc386-default/../../rtemsbsd/rtems/rtems-kernel-bus-dma.c:264:
 
undefined reference to `bsp_bus_space_write_1'
collect2: error: ld returned 1 exit status

/home/joel/rtems-work/tools/6/lib/gcc/i386-rtems6/12.1.1/../../../../i386-rtems6/bin/ld:
 
./libbsd.a(rtems-kernel-bus-dma.c.20.o): in function `_bsd_bus_dmamem_alloc':
/home/joel/rtems-work/rtems-libbsd/build/i386-rtems6-pc386-default/../../rtemsbsd/rtems/rtems-kernel-bus-dma.c:264:
 
undefined reference to `bsp_bus_space_write_1'
collect2: error: ld returned 1 exit status

/home/joel/rtems-work/tools/6/lib/gcc/i386-rtems6/12.1.1/../../../../i386-rtems6/bin/ld:
 
./libbsd.a(rtems-kernel-bus-dma.c.20.o): in function `_bsd_bus_dmamem_alloc':
/home/joel/rtems-work/rtems-libbsd/build/i386-rtems6-pc386-default/../../rtemsbsd/rtems/rtems-kernel-bus-dma.c:264:
 
undefined reference to `bsp_bus_space_write_1'
collect2: error: ld returned 1 exit status

/home/joel/rtems-work/tools/6/lib/gcc/i386-rtems6/12.1.1/../../../../i386-rtems6/bin/ld:
 
./libbsd.a(rtems-kernel-bus-dma.c.20.o): in function `_bsd_bus_dmamem_alloc':
/home/joel/rtems-work/rtems-libbsd/build/i386-rtems6-pc386-default/../../rtemsbsd/rtems/rtems-kernel-bus-dma.c:264:
 
undefined reference to `bsp_bus_space_write_1'
collect2: error: ld returned 1 exit status



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: V2 : Zynq/ZynqMP UART driver

[Jan.Sommer]

> -Original Message-
> From: devel  On Behalf Of chr...@rtems.org
> Sent: Thursday, September 9, 2021 10:25 AM
> To: devel@rtems.org
> Subject: V2 : Zynq/ZynqMP UART driver
> 
> Hi,
> 
> I have tested this version on zynq and zynqmp hardware and I am not seeing
> any issues.
> 
> I was seeing lost data with the serial port connected to FreeBSD 13 running
> ser2net.
> After careful review iof the driver I ended up spinning up a RPi3 with Ubunutu
> and ser2net it working as expected and there is no lost data. I have raised a
> FreeBSD bug on the package.
> 
> I am not seeing any junk data at boot and no lost data. I have the testsuite
> running now and it should post to build when done. Over 100 tests have run
> without any errors. Note, rtems-test is using my recent patches.
> 

Great. In RTEMS5 while reading the first user input we have a junk character.
Would this be solved with this patch as well?

Best regards,

Jan

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

RE: [PATCH v1] bsps/riscv: Give enough time for clock driver initialization

[Jan.Sommer]

Sorry, for digging out this old patch.

> On Mon, Jun 7, 2021 at 1:57 PM  wrote:
> 
> 
> > -Original Message-
> > From: Gedare Bloom 
> > Sent: Monday, June 7, 2021 7:00 PM
> > To: Sommer, Jan 
> > Cc: devel@rtems.org
> > Subject: Re: [PATCH v1] bsps/riscv: Give enough time for clock driver
> > initialization
> > 
> > On Mon, Jun 7, 2021 at 9:47 AM Jan Sommer  wrote:
> > >
> > > - Clock driver initialization for secondary cores had to take less
> > > than one tick
> > > - If tick time is small (i.e. <= 1ms) setting up all cores could take
> > > too long and a fatal error is thrown.
> > > - Give at least 10 ms time for clock initialization to avoid this
> > > error
> > 
> > Is there a reason to pick 10?
> >
> 
> In qemu I (coarsely) measured 1.5ms for 8 cores.
> So I thought this should add enough buffer to prevent a fatal error.
> I probably could also reduce it to 5 ms.
> 
> > I assume this blocks/idles the system until the interval elapses, so it 
> > would be
> > good to minimize waste (subject to Joel's noted rant about premature
> > optimization).
> >
> 
> No. I'm more worried about boot time. :)
>  

Would a few milliseconds be acceptable?

> 
> 
> If you take a look at the clock initialization of the secondary cores 
> (https://git.rtems.org/rtems/tree/bsps/riscv/riscv/clock/clockdrv.c#n178):
> 
> _SMP_Othercast_action(riscv_clock_secondary_action, );
> 
>   if (cmpval - riscv_clock_read_mtime(>mtime) >= interval) {
> bsp_fatal(RISCV_FATAL_CLOCK_SMP_INIT);
>   }
> 
> It will put the first clock tick 10ms into the future (instead of just one 
> tick), but it won't block the system initialization.
> It only prevents entering the if condition by having a large enough value for 
> interval, but the runtime of the clock initialization is the same.
> 
> How does this impact the timeline for boot to first application thread?
> 
> Is there a period where the system is up but only one core?
> 
> Any other oddities I might be missing?
>  

The main effect this has is that the interrupt of the first tick is delayed by 
a few milliseconds, so that there is enough time for the timers of all cores to 
initialize, even for configurations with short tick intervals.
This should have a similar behavior as if the tick time itself would be long 
(i.e. multiple milliseconds).

Maybe, an alternative solution would be to do this in the 
"riscv_clock_secondary_initialization". 
If the condition there (see below) fails, try again with a longer time interval 
for the clock initialization and only fail if that didn't help either.
Then, it would not affect the situation where everything works fine right now 
and just add a small penalty to the setups where it currently fails.
Would this be acceptable?

  178 static void riscv_clock_secondary_initialization(
  179   volatile RISCV_CLINT_regs *clint,
  180   uint64_t cmpval,
  181   uint32_t interval
  182 )
  183 {
  184 #if defined(RTEMS_SMP) && !defined(CLOCK_DRIVER_USE_ONLY_BOOT_PROCESSOR)
  185   _SMP_Othercast_action(riscv_clock_secondary_action, );
  186
  187   if (cmpval - riscv_clock_read_mtime(>mtime) >= interval) {
  188 bsp_fatal(RISCV_FATAL_CLOCK_SMP_INIT);
  189   }
  190 #endif
  191 }

Best regards,

Jan

> > > ---
> > >  bsps/riscv/riscv/clock/clockdrv.c | 8 +++-
> > >  1 file changed, 7 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/bsps/riscv/riscv/clock/clockdrv.c
> > > b/bsps/riscv/riscv/clock/clockdrv.c
> > > index 3afe86576f..102137aeab 100644
> > > --- a/bsps/riscv/riscv/clock/clockdrv.c
> > > +++ b/bsps/riscv/riscv/clock/clockdrv.c
> > > @@ -211,7 +211,13 @@ static void riscv_clock_initialize(void)
> > >tc->interval = interval;
> > >
> > >cmpval = riscv_clock_read_mtime(>mtime);
> > > -  cmpval += interval;
> > > +  /*
> > > +   * For very short intervals the time of 1 tick is not enough to
> > > +   * set up the timer on all cores in SMP systems.
> > > +   * Give the CPU at least 10 ms.
> > > +   */
> > > +  interval = (1 / us_per_tick) * interval;  cmpval += interval;
> > >
> > >riscv_clock_clint_init(clint, cmpval, 0);
> > >riscv_clock_secondary_initialization(clint, cmpval, interval);
> > > --
> > > 2.17.1
> > >
> > > ___
> > > devel mailing list
> > > devel@rtems.org
> > > http://lists.rtems.org/mailman/listinfo/devel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH v1 1/1] gpiolib/grgpio: Add support for newer grgpio features

[Jan.Sommer]

Hi Daniel,

Did you by any chance found the time to have another look at it or test it on 
the GR712RC?

Best regards,

 Jan

From: devel  On Behalf Of jan.som...@dlr.de
Sent: Friday, August 27, 2021 2:36 PM
To: dan...@gaisler.com; devel@rtems.org
Cc: softw...@gaisler.com
Subject: RE: [PATCH v1 1/1] gpiolib/grgpio: Add support for newer grgpio 
features

Hi Daniel,

As far as I understand the code the bus sets the “info.irq” to the pirq value 
from the PnP information of the devices.

Then the “drvmgr_interrupt_register(priv->dev, irq, "grgpio", isr, arg) )“ will 
register the isr with “irq” as an offset of pirq.

So, for devices with GENIRQ == 0, this should yield the behavior you describe 
with one irq per GPIO line (with pirq as the first interrupt line).

For devices with GENIRQ == 1 a shared ISR for pirq is registered.



In our test setup (with grpio with GENIRQ == 1) the grgpio devices with 
interrupts have info.irq set to pirq (e.g. 0x15 in our setup) and for the 
grgpio without interrupt support it is set to 0.

I don’t have a GR712RC for testing, so I don’t know if it behaves differently.



Best regards,



Jan

From: Daniel Hellstrom mailto:dan...@gaisler.com>>
Sent: Thursday, August 26, 2021 3:11 PM
To: Sommer, Jan mailto:jan.som...@dlr.de>>; 
devel@rtems.org
Cc: softw...@gaisler.com
Subject: Re: [PATCH v1 1/1] gpiolib/grgpio: Add support for newer grgpio 
features


Hi Jan,

I haven't tested the code, but it seems to be that the ordinary case when 
GPIO[N] is connected to Interrupt[N] will not work? The fixup makes GPIO[N] pin 
be associated with interrupt[0] (which is not available) and  GPIO[1] with 
Interrupt[1] and so one which is the case with U699/UT700/GR712RC. I believe it 
is the bus-driver's role to initialize the device structure to indicate the 
device's all interrupts (the first interrupt in the ambapp_bus case), and the 
driver's role to select which interrupt of the available. I'm worrying that 
leaving "info.irq = -1" will disable all interrupts from that GPIO core?

Kind Regards,
Daniel




On 2021-08-25 10:13, jan.som...@dlr.de wrote:

Does anyone have any objections to this?



See also https://lists.rtems.org/pipermail/devel/2021-July/068086.html for the 
cover letter.



Best regards,



Jan



-Original Message-

From: Sommer, Jan

Sent: Thursday, July 1, 2021 5:44 PM

To: devel@rtems.org

Cc: softw...@gaisler.com; Sommer, Jan 


Subject: [PATCH v1 1/1] gpiolib/grgpio: Add support for newer grgpio

features



- Use proper typedef for isr (avoid warning in user application)

- Use set input enable register together with pin direction

- Support irqgen == 1 mode if present in capabilities register

---

 bsps/include/grlib/gpiolib.h  |  7 +--

 bsps/include/grlib/grlib.h|  4 +++-

 bsps/shared/grlib/drvmgr/ambapp_bus.c |  5 +

 bsps/shared/grlib/gpio/gpiolib.c  |  2 +-

 bsps/shared/grlib/gpio/grgpio.c   | 22 --

 5 files changed, 26 insertions(+), 14 deletions(-)



diff --git a/bsps/include/grlib/gpiolib.h b/bsps/include/grlib/gpiolib.h index

f82d4fa2c2..37ac140862 100644

--- a/bsps/include/grlib/gpiolib.h

+++ b/bsps/include/grlib/gpiolib.h

@@ -28,6 +28,9 @@ struct gpiolib_config {  #define GPIOLIB_IRQ_POL_LOW

0  #define GPIOLIB_IRQ_POL_HIGH 1



+/* Interrupt Service Routine (ISR) */

+typedef void (*gpiolib_isr)(void *arg);

+

 /* Libarary initialize function must be called befor any other */  extern int

gpiolib_initialize(void);



@@ -54,7 +57,7 @@ extern int gpiolib_irq_disable(void *handle);  extern int

gpiolib_irq_mask(void *handle);  extern int gpiolib_irq_unmask(void

*handle);  extern int gpiolib_irq_force(void *handle); -extern int

gpiolib_irq_register(void *handle, void *func, void *arg);

+extern int gpiolib_irq_register(void *handle, gpiolib_isr func, void

+*arg);



 /*** Driver Interface ***/



@@ -66,7 +69,7 @@ struct gpiolib_drv_ops {

  int(*config)(void *handle, struct gpiolib_config *cfg);

  int(*get)(void *handle, int *val);

  int(*irq_opts)(void *handle, unsigned int options);

- int(*irq_register)(void *handle, void *func, void *arg);

+ int(*irq_register)(void *handle, gpiolib_isr func, void

*arg);

  int(*open)(void *handle);

  int(*set)(void *handle, int dir, int outval);

  int(*show)(void *handle);

diff --git a/bsps/include/grlib/grlib.h b/bsps/include/grlib/grlib.h index

49d807..4aa3e9df4a 100644

--- a/bsps/include/grlib/grlib.h

+++ b/bsps/include/grlib/grlib.h

@@ -17,6 +17,7 @@

 #define __GRLIB_H__



 #include 

+#include 



 #ifdef __cplusplus

 extern "C" {

@@ -125,6 +126,7 @@ struct grgpio_regs {

   volatile unsigned int iedge;   /* 0x14 Interrupt edge register */

   volatile 

RE: [PATCH v1 1/1] gpiolib/grgpio: Add support for newer grgpio features

[Jan.Sommer]

Hi Daniel,

As far as I understand the code the bus sets the “info.irq” to the pirq value 
from the PnP information of the devices.

Then the “drvmgr_interrupt_register(priv->dev, irq, "grgpio", isr, arg) )“ will 
register the isr with “irq” as an offset of pirq.

So, for devices with GENIRQ == 0, this should yield the behavior you describe 
with one irq per GPIO line (with pirq as the first interrupt line).

For devices with GENIRQ == 1 a shared ISR for pirq is registered.



In our test setup (with grpio with GENIRQ == 1) the grgpio devices with 
interrupts have info.irq set to pirq (e.g. 0x15 in our setup) and for the 
grgpio without interrupt support it is set to 0.

I don’t have a GR712RC for testing, so I don’t know if it behaves differently.



Best regards,



Jan

From: Daniel Hellstrom 
Sent: Thursday, August 26, 2021 3:11 PM
To: Sommer, Jan ; devel@rtems.org
Cc: softw...@gaisler.com
Subject: Re: [PATCH v1 1/1] gpiolib/grgpio: Add support for newer grgpio 
features


Hi Jan,

I haven't tested the code, but it seems to be that the ordinary case when 
GPIO[N] is connected to Interrupt[N] will not work? The fixup makes GPIO[N] pin 
be associated with interrupt[0] (which is not available) and  GPIO[1] with 
Interrupt[1] and so one which is the case with U699/UT700/GR712RC. I believe it 
is the bus-driver's role to initialize the device structure to indicate the 
device's all interrupts (the first interrupt in the ambapp_bus case), and the 
driver's role to select which interrupt of the available. I'm worrying that 
leaving "info.irq = -1" will disable all interrupts from that GPIO core?

Kind Regards,
Daniel




On 2021-08-25 10:13, jan.som...@dlr.de wrote:

Does anyone have any objections to this?



See also https://lists.rtems.org/pipermail/devel/2021-July/068086.html for the 
cover letter.



Best regards,



Jan



-Original Message-

From: Sommer, Jan

Sent: Thursday, July 1, 2021 5:44 PM

To: devel@rtems.org

Cc: softw...@gaisler.com; Sommer, Jan 


Subject: [PATCH v1 1/1] gpiolib/grgpio: Add support for newer grgpio

features



- Use proper typedef for isr (avoid warning in user application)

- Use set input enable register together with pin direction

- Support irqgen == 1 mode if present in capabilities register

---

 bsps/include/grlib/gpiolib.h  |  7 +--

 bsps/include/grlib/grlib.h|  4 +++-

 bsps/shared/grlib/drvmgr/ambapp_bus.c |  5 +

 bsps/shared/grlib/gpio/gpiolib.c  |  2 +-

 bsps/shared/grlib/gpio/grgpio.c   | 22 --

 5 files changed, 26 insertions(+), 14 deletions(-)



diff --git a/bsps/include/grlib/gpiolib.h b/bsps/include/grlib/gpiolib.h index

f82d4fa2c2..37ac140862 100644

--- a/bsps/include/grlib/gpiolib.h

+++ b/bsps/include/grlib/gpiolib.h

@@ -28,6 +28,9 @@ struct gpiolib_config {  #define GPIOLIB_IRQ_POL_LOW

0  #define GPIOLIB_IRQ_POL_HIGH 1



+/* Interrupt Service Routine (ISR) */

+typedef void (*gpiolib_isr)(void *arg);

+

 /* Libarary initialize function must be called befor any other */  extern int

gpiolib_initialize(void);



@@ -54,7 +57,7 @@ extern int gpiolib_irq_disable(void *handle);  extern int

gpiolib_irq_mask(void *handle);  extern int gpiolib_irq_unmask(void

*handle);  extern int gpiolib_irq_force(void *handle); -extern int

gpiolib_irq_register(void *handle, void *func, void *arg);

+extern int gpiolib_irq_register(void *handle, gpiolib_isr func, void

+*arg);



 /*** Driver Interface ***/



@@ -66,7 +69,7 @@ struct gpiolib_drv_ops {

  int(*config)(void *handle, struct gpiolib_config *cfg);

  int(*get)(void *handle, int *val);

  int(*irq_opts)(void *handle, unsigned int options);

- int(*irq_register)(void *handle, void *func, void *arg);

+ int(*irq_register)(void *handle, gpiolib_isr func, void

*arg);

  int(*open)(void *handle);

  int(*set)(void *handle, int dir, int outval);

  int(*show)(void *handle);

diff --git a/bsps/include/grlib/grlib.h b/bsps/include/grlib/grlib.h index

49d807..4aa3e9df4a 100644

--- a/bsps/include/grlib/grlib.h

+++ b/bsps/include/grlib/grlib.h

@@ -17,6 +17,7 @@

 #define __GRLIB_H__



 #include 

+#include 



 #ifdef __cplusplus

 extern "C" {

@@ -125,6 +126,7 @@ struct grgpio_regs {

   volatile unsigned int iedge;   /* 0x14 Interrupt edge register */

   volatile unsigned int bypass;  /* 0x18 Bypass register */

   volatile unsigned int cap; /* 0x1C Capability register */

+#define GRGPIO_CAP_IRQGEN(reg) BSP_FLD32GET(reg, 8, 12)

   volatile unsigned int irqmap[4];   /* 0x20 - 0x2C Interrupt map registers */

   volatile unsigned int res_30;  /* 0x30 Reserved */

   volatile unsigned int res_34;  /* 0x34 Reserved */

@@ -132,7 +134,7 @@ struct grgpio_regs {

   volatile unsigned int res_3C;  /* 0x3C 

RE: [PATCH v1 1/1] gpiolib/grgpio: Add support for newer grgpio features

[Jan.Sommer]

Does anyone have any objections to this?

See also https://lists.rtems.org/pipermail/devel/2021-July/068086.html for the 
cover letter.

Best regards,

Jan

> -Original Message-
> From: Sommer, Jan
> Sent: Thursday, July 1, 2021 5:44 PM
> To: devel@rtems.org
> Cc: softw...@gaisler.com; Sommer, Jan 
> Subject: [PATCH v1 1/1] gpiolib/grgpio: Add support for newer grgpio
> features
> 
> - Use proper typedef for isr (avoid warning in user application)
> - Use set input enable register together with pin direction
> - Support irqgen == 1 mode if present in capabilities register
> ---
>  bsps/include/grlib/gpiolib.h  |  7 +--
>  bsps/include/grlib/grlib.h|  4 +++-
>  bsps/shared/grlib/drvmgr/ambapp_bus.c |  5 +
>  bsps/shared/grlib/gpio/gpiolib.c  |  2 +-
>  bsps/shared/grlib/gpio/grgpio.c   | 22 --
>  5 files changed, 26 insertions(+), 14 deletions(-)
> 
> diff --git a/bsps/include/grlib/gpiolib.h b/bsps/include/grlib/gpiolib.h index
> f82d4fa2c2..37ac140862 100644
> --- a/bsps/include/grlib/gpiolib.h
> +++ b/bsps/include/grlib/gpiolib.h
> @@ -28,6 +28,9 @@ struct gpiolib_config {  #define GPIOLIB_IRQ_POL_LOW
> 0  #define GPIOLIB_IRQ_POL_HIGH 1
> 
> +/* Interrupt Service Routine (ISR) */
> +typedef void (*gpiolib_isr)(void *arg);
> +
>  /* Libarary initialize function must be called befor any other */  extern int
> gpiolib_initialize(void);
> 
> @@ -54,7 +57,7 @@ extern int gpiolib_irq_disable(void *handle);  extern int
> gpiolib_irq_mask(void *handle);  extern int gpiolib_irq_unmask(void
> *handle);  extern int gpiolib_irq_force(void *handle); -extern int
> gpiolib_irq_register(void *handle, void *func, void *arg);
> +extern int gpiolib_irq_register(void *handle, gpiolib_isr func, void
> +*arg);
> 
>  /*** Driver Interface ***/
> 
> @@ -66,7 +69,7 @@ struct gpiolib_drv_ops {
>   int (*config)(void *handle, struct gpiolib_config *cfg);
>   int (*get)(void *handle, int *val);
>   int (*irq_opts)(void *handle, unsigned int options);
> - int (*irq_register)(void *handle, void *func, void *arg);
> + int (*irq_register)(void *handle, gpiolib_isr func, void
> *arg);
>   int (*open)(void *handle);
>   int (*set)(void *handle, int dir, int outval);
>   int (*show)(void *handle);
> diff --git a/bsps/include/grlib/grlib.h b/bsps/include/grlib/grlib.h index
> 49d807..4aa3e9df4a 100644
> --- a/bsps/include/grlib/grlib.h
> +++ b/bsps/include/grlib/grlib.h
> @@ -17,6 +17,7 @@
>  #define __GRLIB_H__
> 
>  #include 
> +#include 
> 
>  #ifdef __cplusplus
>  extern "C" {
> @@ -125,6 +126,7 @@ struct grgpio_regs {
>volatile unsigned int iedge;   /* 0x14 Interrupt edge register */
>volatile unsigned int bypass;  /* 0x18 Bypass register */
>volatile unsigned int cap; /* 0x1C Capability register */
> +#define GRGPIO_CAP_IRQGEN(reg) BSP_FLD32GET(reg, 8, 12)
>volatile unsigned int irqmap[4];   /* 0x20 - 0x2C Interrupt map registers 
> */
>volatile unsigned int res_30;  /* 0x30 Reserved */
>volatile unsigned int res_34;  /* 0x34 Reserved */
> @@ -132,7 +134,7 @@ struct grgpio_regs {
>volatile unsigned int res_3C;  /* 0x3C Reserved */
>volatile unsigned int iavail;  /* 0x40 Interrupt available register */
>volatile unsigned int iflag;   /* 0x44 Interrupt flag register */
> -  volatile unsigned int res_48;  /* 0x48 Reserved */
> +  volatile unsigned int input_en;/* 0x48 Input enable (if present) */
>volatile unsigned int pulse;   /* 0x4C Pulse register */
>volatile unsigned int res_50;  /* 0x50 Reserved */
>volatile unsigned int output_or;   /* 0x54 I/O port output register, 
> logical-OR
> */
> diff --git a/bsps/shared/grlib/drvmgr/ambapp_bus.c
> b/bsps/shared/grlib/drvmgr/ambapp_bus.c
> index 3c38fc16e0..0aed29224c 100644
> --- a/bsps/shared/grlib/drvmgr/ambapp_bus.c
> +++ b/bsps/shared/grlib/drvmgr/ambapp_bus.c
> @@ -521,11 +521,8 @@ static int ambapp_dev_fixup(struct drvmgr_dev
> *dev, struct amba_dev_info *pnp)
>   for(core = 0; core < subcores; core++)
>   drvmgr_dev_register(devs_to_register[core]);
>   return 1;
> - } else if ( (pnp->info.device == GAISLER_GPIO) &&
> - (pnp->info.vendor == VENDOR_GAISLER) ) {
> - /* PIO[N] is connected to IRQ[N]. */
> - pnp->info.irq = 0;
>   }
> +
>   return 0;
>  }
> 
> diff --git a/bsps/shared/grlib/gpio/gpiolib.c
> b/bsps/shared/grlib/gpio/gpiolib.c
> index cf0038c5bb..0cb76402cc 100644
> --- a/bsps/shared/grlib/gpio/gpiolib.c
> +++ b/bsps/shared/grlib/gpio/gpiolib.c
> @@ -201,7 +201,7 @@ int gpiolib_get(void *handle, int *inval)  }
> 
>  /*** IRQ Functions ***/
> -int gpiolib_irq_register(void *handle, void *func, void *arg)
> +int gpiolib_irq_register(void *handle, gpiolib_isr func, void *arg)
>  {
>   

RE: [PATCH rtems] arm/xilinx: Fix zynq-uart interrupt receive

[Jan.Sommer]

Is this patch also something to backport to RTEMS5 or is this problem only 
specific to the current version?

Best regards,

Jan

> -Original Message-
> From: devel  On Behalf Of Chris Johns
> Sent: Wednesday, August 18, 2021 1:02 AM
> To: j...@rtems.org
> Cc: rtems-de...@rtems.org 
> Subject: Re: [PATCH rtems] arm/xilinx: Fix zynq-uart interrupt receive
> 
> On 17/8/21 11:21 pm, Joel Sherrill wrote:
> > I'm only asking where and how did this get tested? BSPs? Qemu/HW?
> Input?
> 
> I listed the testing in the covering email ...
> 
> https://lists.rtems.org/pipermail/devel/2021-August/068938.html
> 
> > Long overdue. I just hope it stays fixed.
> 
> I agree.
> 
> Chris
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RISCV-SIS: Different busy cycles per tick for primary and secondary cores

[Jan.Sommer]

Hello,

We noticed a bit strange behavior while doing some measurements with the riscv 
bsps running on SIS.
If we run "T_get_one_clock_tick_busy" to get a base reference for busy cycles, 
the values between cpu0 and other secondary cores differ by a constant value.
For example for a 200us tick time:
cpu0:  4460 cycles per tick
cpu1:  4848 cycles per tick
cpu2:  4848 cycles per tick

Results for multiple calls on the same core only differ in a few ticks.
For a 500us tick time it yields:
cpu0:  11957 cycles per tick
cpu1:  12350 cycles per tick
cpu2:  12348 cycles per tick

So, in both cases there is a constant difference of approx. 390 cyples per tick 
between core0 and all other cores.
We ran the test application with "riscv-rtems6-sis -m 4 bin/test-busy-loop.elf 
-freq 100 -d 25 -r"
Is this something to be expected and what could be the reason for this (e.g. in 
rtems or in the SIS)?

Best regards,

Jan

Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR)
German Aerospace Center
Institute for Software Technology | Software for Space Systems and Interactive 
Visualization | Lilienthalplatz 7 | 38108 Braunschweig | Germany
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH] bsps/cadence-spi: Fix moduleid offset

[Jan.Sommer]

> -Original Message-
> From: Gedare Bloom 
> Sent: Tuesday, June 29, 2021 6:22 PM
> To: Kinsey Moore ; Sommer, Jan
> 
> Cc: devel@rtems.org
> Subject: Re: [PATCH] bsps/cadence-spi: Fix moduleid offset
> 
> Jan, please confirm. Thanks
> 

Looks good to me.

Thanks,

Jan

> On Mon, Jun 28, 2021 at 7:06 AM Kinsey Moore
>  wrote:
> >
> > Move the moduleid register to the correct offset according to Cadence
> > IP documentation.
> > ---
> >  bsps/include/dev/spi/cadence-spi-regs.h | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/bsps/include/dev/spi/cadence-spi-regs.h
> > b/bsps/include/dev/spi/cadence-spi-regs.h
> > index b4b2366b3d..207d056fb1 100644
> > --- a/bsps/include/dev/spi/cadence-spi-regs.h
> > +++ b/bsps/include/dev/spi/cadence-spi-regs.h
> > @@ -78,6 +78,7 @@ typedef struct {
> > uint32_t slave_idle_count;
> > uint32_t txthreshold;
> > uint32_t rxthreshold;
> > +   uint32_t unused[51];
> > uint32_t moduleid;
> >  } cadence_spi;
> >
> > --
> > 2.20.1
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[rtems5] Assertion triggered with --enable-debug

[Jan.Sommer]

As a follow-up from the discussions here: 
https://lists.rtems.org/pipermail/users/2021-June/068454.html
For RTEMS5 I noticed that an assertion fails for the Zedboard BSP if RTEMS is 
compiled with the --enable-debug option.
The assert seems to be triggered during the execution of rtems_bsd_initialize  
in the init task. The backtrace looks like this:

Breakpoint 4, _Terminate (the_source=RTEMS_FATAL_SOURCE_ASSERT, 
the_error=3378872)
at ../../../../../c/src/../../cpukit/score/src/interr.c:36
36_User_extensions_Fatal( the_source, the_error );
(gdb) bt
#0  _Terminate (the_source=RTEMS_FATAL_SOURCE_ASSERT, the_error=3378872)
at ../../../../../c/src/../../cpukit/score/src/interr.c:36
#1  0x0010aa26 in rtems_fatal (fatal_source=RTEMS_FATAL_SOURCE_ASSERT, 
error_code=3378872)
at /workspace/rtems/cpukit/include/rtems/fatal.h:88
#2  0x0010aa98 in __assert_func (
file=0x20d250 "/workspace/rtems/cpukit/include/rtems/score/chainimpl.h", 
line=688,
func=0x20d2a4 <__func__.5956> "_Chain_Append_unprotected",
failedexpr=0x20d228 "_Chain_Is_node_off_chain( the_node )")
at ../../../../../c/src/../../cpukit/libcsupport/src/__assert.c:52
#3  0x0011be6c in _Chain_Append_unprotected (the_chain=0x3126d4 
<_Configuration_Scheduler_priority_dflt+1236>,
the_node=0x310d48 <_RTEMS_tasks_Objects+4160>)
at /workspace/rtems/cpukit/include/rtems/score/chainimpl.h:688
#4  0x0011c1ca in _Scheduler_priority_Ready_queue_enqueue (node=0x310d48 
<_RTEMS_tasks_Objects+4160>,
ready_queue=0x310f28 <_RTEMS_tasks_Objects+4640>, bit_map=0x312200 
<_Configuration_Scheduler_priority_dflt>)
at /workspace/rtems/cpukit/include/rtems/score/schedulerpriorityimpl.h:119
#5  0x0011c276 in _Scheduler_priority_Unblock (scheduler=0x2089f0 
<_Scheduler_Table>,
the_thread=0x310d48 <_RTEMS_tasks_Objects+4160>, node=0x310ef0 
<_RTEMS_tasks_Objects+4584>)
at ../../../../../c/src/../../cpukit/score/src/schedulerpriorityunblock.c:50
#6  0x0011d83a in _Scheduler_Unblock (the_thread=0x310d48 
<_RTEMS_tasks_Objects+4160>)
at /workspace/rtems/cpukit/include/rtems/score/schedulerimpl.h:322
#7  0x0011d8d8 in _Thread_Clear_state_locked (the_thread=0x310d48 
<_RTEMS_tasks_Objects+4160>, state=4294967295)
at ../../../../../c/src/../../cpukit/score/src/threadclearstate.c:44
#8  0x00120230 in _Thread_Start (the_thread=0x310d48 
<_RTEMS_tasks_Objects+4160>, entry=0x338fa4,
lock_context=0x338fa0) at 
../../../../../c/src/../../cpukit/score/src/threadstart.c:43
#9  0x001171ac in rtems_task_start (id=167837701, entry_point=0x190f65 
, argument=3282804)
at ../../../../../c/src/../../cpukit/rtems/src/taskstart.c:56
#10 0x001875f4 in rtems_bsd_threads_init_late (arg=) at 
../../rtemsbsd/rtems/rtems-kernel-thread.c:211
#11 0x0018cf58 in _bsd_mi_startup () at ../../freebsd/sys/kern/init_main.c:327
#12 0x001865e0 in rtems_bsd_initialize () at 
../../rtemsbsd/rtems/rtems-kernel-init.c:150
#13 0x001058e2 in register_network_devices (ip=ip@entry=0x31fe24  
"10.42.0.225")
at 
/localdata2/somm_ja/hap/fcc-software/sw/common/rtems/register_ethernet.cpp:130
#14 0x0010534c in task_system_init () at main.cpp:59
#15 0x00120270 in _Thread_Entry_adaptor_numeric (executing=0x30fd08 
<_RTEMS_tasks_Objects>)
at 
../../../../../c/src/../../cpukit/score/src/threadentryadaptornumeric.c:25
#16 0x0011e204 in _Thread_Handler () at 
../../../../../c/src/../../cpukit/score/src/threadhandler.c:139
#17 0x00128e48 in _Thread_Start_multitasking ()
at ../../../../../c/src/../../cpukit/score/src/threadstartmultitasking.c:64

Best regards,

Jan

Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR)
German Aerospace Center
Institute for Software Technology | Software for Space Systems and Interactive 
Visualization | Lilienthalplatz 7 | 38108 Braunschweig | Germany
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH v2 1/1] bsps/i386: Update calibration of TSC to be more accurate

[Jan.Sommer]

Thanks, I prepared tickets for master and 5.
I will make sure that the link in the commit message fits the right ticket of 
the corresponding branch.
My plan is to push that on Monday, when I am back in the office

Best regards,

Jan

From: Joel Sherrill 
Sent: Wednesday, June 16, 2021 8:06 PM
To: Gedare Bloom 
Cc: Sommer, Jan ; devel@rtems.org
Subject: Re: [PATCH v2 1/1] bsps/i386: Update calibration of TSC to be more 
accurate

Me too. Just needs separate tickets for 5 and 6 so the release notes are 
generated correctly.

On Wed, Jun 16, 2021 at 12:51 PM Gedare Bloom 
mailto:ged...@rtems.org>> wrote:
I'm good with it for master and 5.

On Wed, Jun 16, 2021 at 4:18 AM Jan Sommer 
mailto:jan.som...@dlr.de>> wrote:
>
> Closes #4455
> ---
>  bsps/i386/pc386/clock/ckinit.c | 71 ++
>  1 file changed, 38 insertions(+), 33 deletions(-)
>
> diff --git a/bsps/i386/pc386/clock/ckinit.c b/bsps/i386/pc386/clock/ckinit.c
> index 09afe73cde..2df1818dd3 100644
> --- a/bsps/i386/pc386/clock/ckinit.c
> +++ b/bsps/i386/pc386/clock/ckinit.c
> @@ -104,48 +104,60 @@ static uint32_t pc386_get_timecount_i8254(struct 
> timecounter *tc)
>
>  /*
>   * Calibrate CPU cycles per tick. Interrupts should be disabled.
> + * Will also set the PIT, so call this before registering the
> + * periodic timer for rtems tick generation
>   */
>  static void calibrate_tsc(void)
>  {
>uint64_t  begin_time;
> -  uint8_t   then_lsb, then_msb, now_lsb, now_msb;
> -  uint32_t  i;
> -
> -  /*
> -   * We just reset the timer, so we know we're at the beginning of a tick.
> -   */
> -
> -  /*
> -   * Count cycles. Watching the timer introduces a several microsecond
> -   * uncertaintity, so let it cook for a while and divide by the number of
> -   * ticks actually executed.
> -   */
> +  uint8_t   lsb, msb;
> +  uint32_t  max_timer_value;
> +  uint32_t  last_tick, cur_tick;
> +  int32_t   diff, remaining;
> +
> +  /* Set the timer to free running mode */
> +  outport_byte(TIMER_MODE, TIMER_SEL0 | TIMER_16BIT | TIMER_INTTC);
> +  /* Reset the 16 timer reload value, first LSB, then MSB */
> +  outport_byte(TIMER_CNTR0, 0);
> +  outport_byte(TIMER_CNTR0, 0);
> +  /* We use the full 16 bit */
> +  max_timer_value = 0x;
> +  /* Calibrate for 1s, i.e. TIMER_TICK PIT ticks */
> +  remaining = TIMER_TICK;
>
>begin_time = rdtsc();
> -
> -  for (i = rtems_clock_get_ticks_per_second() * pc386_isrs_per_tick;
> -   i != 0; --i ) {
> -/* We know we've just completed a tick when timer goes from low to high 
> */
> -then_lsb = then_msb = 0xff;
> -do {
> -  READ_8254(now_lsb, now_msb);
> -  if ((then_msb < now_msb) ||
> -  ((then_msb == now_msb) && (then_lsb < now_lsb)))
> -break;
> -  then_lsb = now_lsb;
> -  then_msb = now_msb;
> -} while (1);
> +  READ_8254(lsb, msb);
> +  last_tick = (msb << 8) | lsb;
> +  while(remaining > 0) {
> +READ_8254(lsb, msb);
> +cur_tick = (msb << 8) | lsb;
> +/* PIT counts down, so subtract cur from last */
> +diff = last_tick - cur_tick;
> +last_tick = cur_tick;
> +if (diff < 0) {
> +diff += max_timer_value;
> +}
> +remaining -= diff;
>}
>
>pc586_tsc_frequency = rdtsc() - begin_time;
>
>  #if 0
> -  printk( "CPU clock at %u MHz\n", (uint32_t)(pc586_tsc_frequency / 
> 100));
> +  printk( "CPU clock at %u Hz\n", (uint32_t)(pc586_tsc_frequency ));
>  #endif
>  }
>
>  static void clockOn(void)
>  {
> +
> +  /*
> +   * First calibrate the TSC. Do this every time we
> +   * turn the clock on in case the CPU clock speed has changed.
> +   */
> +  if ( x86_has_tsc() ) {
> +calibrate_tsc();
> +  }
> +
>rtems_interrupt_lock_context lock_context;
>pc386_isrs_per_tick= 1;
>pc386_microseconds_per_isr = 
> rtems_configuration_get_microseconds_per_tick();
> @@ -171,13 +183,6 @@ static void clockOn(void)
>rtems_interrupt_lock_release(_i386_i8254_access_lock, _context);
>
>bsp_interrupt_vector_enable( BSP_PERIODIC_TIMER );
> -
> -  /*
> -   * Now calibrate cycles per tick. Do this every time we
> -   * turn the clock on in case the CPU clock speed has changed.
> -   */
> -  if ( x86_has_tsc() )
> -calibrate_tsc();
>  }
>
>  bool Clock_isr_enabled = false;
> --
> 2.17.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH v1] bsps/i386: Update calibration of TSC to be more accurate

[Jan.Sommer]

> -Original Message-
> From: Gedare Bloom 
> Sent: Tuesday, June 15, 2021 5:01 PM
> To: Sommer, Jan 
> Cc: devel@rtems.org
> Subject: Re: [PATCH v1] bsps/i386: Update calibration of TSC to be more
> accurate
> 
> On Fri, Jun 11, 2021 at 1:44 AM Jan Sommer  wrote:
> >
> > Closes #4455
> > ---
> >  bsps/i386/pc386/clock/ckinit.c | 72
> > ++
> >  1 file changed, 39 insertions(+), 33 deletions(-)
> >
> > diff --git a/bsps/i386/pc386/clock/ckinit.c
> > b/bsps/i386/pc386/clock/ckinit.c index 09afe73cde..cbd2360fde 100644
> > --- a/bsps/i386/pc386/clock/ckinit.c
> > +++ b/bsps/i386/pc386/clock/ckinit.c
> > @@ -104,48 +104,61 @@ static uint32_t pc386_get_timecount_i8254(struct
> > timecounter *tc)
> >
> >  /*
> >   * Calibrate CPU cycles per tick. Interrupts should be disabled.
> > + * Will also set the PIT, so call this before registering the
> > + * periodic timer for rtems tick generation
> >   */
> >  static void calibrate_tsc(void)
> >  {
> >uint64_t  begin_time;
> > -  uint8_t   then_lsb, then_msb, now_lsb, now_msb;
> > -  uint32_t  i;
> > -
> > -  /*
> > -   * We just reset the timer, so we know we're at the beginning of a tick.
> > -   */
> > -
> > -  /*
> > -   * Count cycles. Watching the timer introduces a several microsecond
> > -   * uncertaintity, so let it cook for a while and divide by the number of
> > -   * ticks actually executed.
> > -   */
> > +  uint8_t   lsb, msb;
> > +  uint32_t  max_timer_value;
> > +  uint32_t  last_tick, cur_tick;
> > +  int32_t   diff, remaining;
> > +
> > +  /* Set the timer to free running mode */  outport_byte(TIMER_MODE,
> > + TIMER_SEL0|TIMER_16BIT|TIMER_INTTC);
> Please add spaces between the OR'd values |.
> 

Was just moved from the existing code, but you are right that I can fix it, if 
I touch it.
Will send an update with this and your other formatting suggestions.

> > +  outport_byte(TIMER_CNTR0, 0);
> > +  outport_byte(TIMER_CNTR0, 0);
> I suppose it is needed to write two 0's, but it may be worth a comment why.
> 

Yes, you need to first set the lsb and then the msb of the 16bit reload 
register.
I will add a comment.

> > +  /* 16 bit counter */
> > +  max_timer_value = 0x;
> > +  /* Calibrate for 1s */
> > +  remaining = TIMER_TICK;
> >
> >begin_time = rdtsc();
> > -
> > -  for (i = rtems_clock_get_ticks_per_second() * pc386_isrs_per_tick;
> > -   i != 0; --i ) {
> > -/* We know we've just completed a tick when timer goes from low to
> high */
> > -then_lsb = then_msb = 0xff;
> > -do {
> > -  READ_8254(now_lsb, now_msb);
> > -  if ((then_msb < now_msb) ||
> > -  ((then_msb == now_msb) && (then_lsb < now_lsb)))
> > -break;
> > -  then_lsb = now_lsb;
> > -  then_msb = now_msb;
> > -} while (1);
> > +  READ_8254(lsb,msb);
> space after comma
> 
> > +  last_tick = (msb << 8) | lsb;
> > +  while(remaining > 0) {
> > +READ_8254(lsb,msb);
> > +cur_tick = (msb << 8) | lsb;
> > +/* PIT counts down, so subtract cur from last */
> > +diff = last_tick - cur_tick;
> > +last_tick = cur_tick;
> > +if (diff < 0) {
> > +diff += max_timer_value;
> > +}
> > +remaining -= diff;
> >}
> >
> >pc586_tsc_frequency = rdtsc() - begin_time;
> >
> >  #if 0
> > -  printk( "CPU clock at %u MHz\n", (uint32_t)(pc586_tsc_frequency /
> > 100));
> > +  printk( "CPU clock at %u Hz\n", (uint32_t)(pc586_tsc_frequency ));
> >  #endif
> >  }
> >
> >  static void clockOn(void)
> >  {
> > +
> > +  /*
> > +   * First calibrate the TSC. Do this every time we
> > +   * turn the clock on in case the CPU clock speed has changed.
> > +   */
> > +  for (int i = 0; i<5; ++i)
> > +  {
> > +  if ( x86_has_tsc() )
> > +calibrate_tsc();
> 
> What's the reason to do this 5 times? I don't see any averaging, so just the
> last one is being taken as "correct"
> 

Left overs from debugging.
I removed the print, but forgot to remove the loop as well...

Best regards,

Jan

> > +  }
> > +
> >rtems_interrupt_lock_context lock_context;
> >pc386_isrs_per_tick= 1;
> >pc386_microseconds_per_isr =
> > rtems_configuration_get_microseconds_per_tick();
> > @@ -171,13 +184,6 @@ static void clockOn(void)
> >rtems_interrupt_lock_release(_i386_i8254_access_lock,
> > _context);
> >
> >bsp_interrupt_vector_enable( BSP_PERIODIC_TIMER );
> > -
> > -  /*
> > -   * Now calibrate cycles per tick. Do this every time we
> > -   * turn the clock on in case the CPU clock speed has changed.
> > -   */
> > -  if ( x86_has_tsc() )
> > -calibrate_tsc();
> >  }
> >
> >  bool Clock_isr_enabled = false;
> > --
> > 2.17.1
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org

RE: [PATCH v2 2/2] i386: Remove unneeded include header files

[Jan.Sommer]

> -Original Message-
> From: Gedare Bloom 
> Sent: Wednesday, June 9, 2021 8:33 PM
> To: Sommer, Jan 
> Cc: Amar Takhar ; Chris Johns ;
> devel@rtems.org
> Subject: Re: [PATCH v2 2/2] i386: Remove unneeded include header files
> 
> On Wed, Jun 9, 2021 at 12:27 PM Gedare Bloom  wrote:
> >
> > On Wed, Jun 9, 2021 at 12:21 PM Gedare Bloom 
> wrote:
> > >
> > > It is helpful. there should be
> > > remote: 3: update trac
> > >
> > ok, actually what's missing is
> > 0: init
> >
> > I think the hooks need to be updated for rtems-libbsd. without running
> > init, the TMP_REV is not generated, so there's nothing to send to
> > trac.
> >
> > I'm going to update the hooks, and we'll see if it works next time.
> > You'll need to manually close the ticket(s) for 5.
> >
> It seems like tickets were being closed for the 6-freebsd-12 branch, so now
> I'm not actually sure this is the right fix, or why they were working without
> the init step. We may need to do some testing.
> 
I didn't create ticket for the 6-freebsd-12 branch. Should I have?
The output of git push looks quite similar:

$ git push upstream HEAD~:6-freebsd-12
Counting objects: 4, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 627 bytes | 627.00 KiB/s, done.
Total 4 (delta 3), reused 0 (delta 0)
remote: 1: mail v...@rtems.org
remote: 2: update github
remote: 4: IRC
remote: usage:  
remote: 5: Buildbot
To ssh://dispatch.rtems.org/data/git/rtems-libbsd.git
   34862dd273..1ca0dc7309  HEAD~ -> 6-freebsd-12

> > > now we need to find out why. seems the problem really is on git side.
> > >
> > > On Wed, Jun 9, 2021 at 12:03 PM  wrote:
> > > >
> > > > That`s the output I got.
> > > > Not sure if it is helpful:
> > > >
> > > > $ git push upstream HEAD~:5-freebsd-12 Counting objects: 4, done.
> > > > Delta compression using up to 8 threads.
> > > > Compressing objects: 100% (4/4), done.
> > > > Writing objects: 100% (4/4), 658 bytes | 658.00 KiB/s, done.
> > > > Total 4 (delta 3), reused 0 (delta 0)
> > > > remote: 1: mail v...@rtems.org
> > > > remote: 2: update github
> > > > remote: 4: IRC
> > > > remote: usage:  
> > > > remote: 5: Buildbot
> > > > To ssh://dispatch.rtems.org/data/git/rtems-libbsd.git
> > > >a2bc8eba46..9edb1201f6  HEAD~ -> 5-freebsd-12
> > > >
> > > > $ git push upstream HEAD:5-freebsd-12 Counting objects: 7, done.
> > > > Delta compression using up to 8 threads.
> > > > Compressing objects: 100% (6/6), done.
> > > > Writing objects: 100% (7/7), 567 bytes | 567.00 KiB/s, done.
> > > > Total 7 (delta 4), reused 0 (delta 0)
> > > > remote: 1: mail v...@rtems.org
> > > > remote: 2: update github
> > > > remote: 4: IRC
> > > > remote: usage:  
> > > > remote: 5: Buildbot
> > > > To ssh://dispatch.rtems.org/data/git/rtems-libbsd.git
> > > >9edb1201f6..5c1b99e4d2  HEAD -> 5-freebsd-12
> > > >
> > > > > -Original Message-
> > > > > From: Gedare Bloom 
> > > > > Sent: Wednesday, June 9, 2021 7:59 PM
> > > > > To: Sommer, Jan ; Amar Takhar
> > > > > 
> > > > > Cc: Chris Johns ; devel@rtems.org
> > > > > Subject: Re: [PATCH v2 2/2] i386: Remove unneeded include header
> > > > > files
> > > > >
> > > > > On Wed, Jun 9, 2021 at 10:51 AM  wrote:
> > > > > >
> > > > > > Thanks. Pushed to master, 5-freebsd-12 and 6-freebsd-12.
> > > > > > Short question: Does the buildbot recognize the pushes to
> > > > > > rtems-libbsd/5-
> > > > > freebsd-12 and update the ticket?
> > > > > > I added the ticket number to the commit description, but the
> > > > > > ticket has not
> > > > > been updated.
> > > > > >
> > > > > Do you still have the terminal output from running git-push?
> > > > >
> > > > > The git side looks ok, but I can't check the trac end.
> > > > >
> > > > > > Best regards,
> > > > > >
> > > > > > Jan
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: Chris Johns 
> > > > > > > Sent: Wednesday, June 9, 2021 12:13 PM
> > > > > > > To: Sommer, Jan ; ged...@rtems.org
> > > > > > > Cc: devel@rtems.org
> > > > > > > Subject: Re: [PATCH v2 2/2] i386: Remove unneeded include
> > > > > > > header files
> > > > > > >
> > > > > > > On 8/6/21 11:52 pm, jan.som...@dlr.de wrote:
> > > > > > > > I would also like to backport this to 5-freebsd-12 to
> > > > > > > > solve this issue
> > > > > there as
> > > > > > > well.
> > > > > > > > I created a corresponding ticket:
> > > > > > > https://devel.rtems.org/ticket/4452#ticket
> > > > > > >
> > > > > > > OK for 5.
> > > > > > >
> > > > > > > Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH v2 2/2] i386: Remove unneeded include header files

[Jan.Sommer]

That`s the output I got.
Not sure if it is helpful:

$ git push upstream HEAD~:5-freebsd-12  
Counting objects: 4, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 658 bytes | 658.00 KiB/s, done.
Total 4 (delta 3), reused 0 (delta 0)
remote: 1: mail v...@rtems.org
remote: 2: update github
remote: 4: IRC
remote: usage:  
remote: 5: Buildbot
To ssh://dispatch.rtems.org/data/git/rtems-libbsd.git
   a2bc8eba46..9edb1201f6  HEAD~ -> 5-freebsd-12

$ git push upstream HEAD:5-freebsd-12  
Counting objects: 7, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (7/7), 567 bytes | 567.00 KiB/s, done.
Total 7 (delta 4), reused 0 (delta 0)
remote: 1: mail v...@rtems.org
remote: 2: update github
remote: 4: IRC
remote: usage:  
remote: 5: Buildbot
To ssh://dispatch.rtems.org/data/git/rtems-libbsd.git
   9edb1201f6..5c1b99e4d2  HEAD -> 5-freebsd-12

> -Original Message-
> From: Gedare Bloom 
> Sent: Wednesday, June 9, 2021 7:59 PM
> To: Sommer, Jan ; Amar Takhar
> 
> Cc: Chris Johns ; devel@rtems.org
> Subject: Re: [PATCH v2 2/2] i386: Remove unneeded include header files
> 
> On Wed, Jun 9, 2021 at 10:51 AM  wrote:
> >
> > Thanks. Pushed to master, 5-freebsd-12 and 6-freebsd-12.
> > Short question: Does the buildbot recognize the pushes to rtems-libbsd/5-
> freebsd-12 and update the ticket?
> > I added the ticket number to the commit description, but the ticket has not
> been updated.
> >
> Do you still have the terminal output from running git-push?
> 
> The git side looks ok, but I can't check the trac end.
> 
> > Best regards,
> >
> > Jan
> >
> > > -Original Message-
> > > From: Chris Johns 
> > > Sent: Wednesday, June 9, 2021 12:13 PM
> > > To: Sommer, Jan ; ged...@rtems.org
> > > Cc: devel@rtems.org
> > > Subject: Re: [PATCH v2 2/2] i386: Remove unneeded include header files
> > >
> > > On 8/6/21 11:52 pm, jan.som...@dlr.de wrote:
> > > > I would also like to backport this to 5-freebsd-12 to solve this issue
> there as
> > > well.
> > > > I created a corresponding ticket:
> > > https://devel.rtems.org/ticket/4452#ticket
> > >
> > > OK for 5.
> > >
> > > Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH v2 2/2] i386: Remove unneeded include header files

[Jan.Sommer]

Thanks. Pushed to master, 5-freebsd-12 and 6-freebsd-12.
Short question: Does the buildbot recognize the pushes to 
rtems-libbsd/5-freebsd-12 and update the ticket?
I added the ticket number to the commit description, but the ticket has not 
been updated.

Best regards,

Jan

> -Original Message-
> From: Chris Johns 
> Sent: Wednesday, June 9, 2021 12:13 PM
> To: Sommer, Jan ; ged...@rtems.org
> Cc: devel@rtems.org
> Subject: Re: [PATCH v2 2/2] i386: Remove unneeded include header files
> 
> On 8/6/21 11:52 pm, jan.som...@dlr.de wrote:
> > I would also like to backport this to 5-freebsd-12 to solve this issue 
> > there as
> well.
> > I created a corresponding ticket:
> https://devel.rtems.org/ticket/4452#ticket
> 
> OK for 5.
> 
> Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH v2 2/2] i386: Remove unneeded include header files

[Jan.Sommer]

Thanks,

I would also like to backport this to 5-freebsd-12 to solve this issue there as 
well.
I created a corresponding ticket: https://devel.rtems.org/ticket/4452#ticket

Best regards,

Jan

> -Original Message-
> From: Chris Johns 
> Sent: Tuesday, June 8, 2021 4:59 AM
> To: Gedare Bloom ; Sommer, Jan
> 
> Cc: devel@rtems.org
> Subject: Re: [PATCH v2 2/2] i386: Remove unneeded include header files
> 
> I agree this is the way to solve this issue.
> 
> Chris
> 
> On 8/6/21 3:09 am, Gedare Bloom wrote:
> > This looks like a much better solution :) If no one complains by
> > Thursday go ahead and push it.
> >
> > On Mon, Jun 7, 2021 at 2:53 AM Jan Sommer  wrote:
> >>
> >> ---
> >>  .../sys/i386/include/machine/intr_machdep.h   |6 -
> >>  rtemsbsd/include/x86/bus.h| 1109 
> >>  rtemsbsd/include/x86/specialreg.h | 1143 -
> >>  3 files changed, 2258 deletions(-)
> >>  delete mode 100644 freebsd/sys/i386/include/machine/intr_machdep.h
> >>  delete mode 100644 rtemsbsd/include/x86/bus.h
> >>  delete mode 100644 rtemsbsd/include/x86/specialreg.h
> >>
> >> diff --git a/freebsd/sys/i386/include/machine/intr_machdep.h
> b/freebsd/sys/i386/include/machine/intr_machdep.h
> >> deleted file mode 100644
> >> index a0b28387..
> >> --- a/freebsd/sys/i386/include/machine/intr_machdep.h
> >> +++ /dev/null
> >> @@ -1,6 +0,0 @@
> >> -/*-
> >> - * This file is in the public domain.
> >> - */
> >> -/* $FreeBSD$ */
> >> -
> >> -#include 
> >> diff --git a/rtemsbsd/include/x86/bus.h b/rtemsbsd/include/x86/bus.h
> >> deleted file mode 100644
> >> index 2427ae51..
> >> --- a/rtemsbsd/include/x86/bus.h
> >> +++ /dev/null
> >> @@ -1,1109 +0,0 @@
> >> -/*-
> >> - * SPDX-License-Identifier: BSD-3-Clause AND BSD-2-Clause-NetBSDE
> >> - *
> >> - * Copyright (c) KATO Takenori, 1999.
> >> - *
> >> - * All rights reserved.  Unpublished rights reserved under the copyright
> >> - * laws of Japan.
> >> - *
> >> - * Redistribution and use in source and binary forms, with or without
> >> - * modification, are permitted provided that the following conditions
> >> - * are met:
> >> - *
> >> - * 1. Redistributions of source code must retain the above copyright
> >> - *notice, this list of conditions and the following disclaimer as
> >> - *the first lines of this file unmodified.
> >> - * 2. Redistributions in binary form must reproduce the above copyright
> >> - *notice, this list of conditions and the following disclaimer in the
> >> - *documentation and/or other materials provided with the
> distribution.
> >> - * 3. The name of the author may not be used to endorse or promote
> products
> >> - *derived from this software without specific prior written 
> >> permission.
> >> - *
> >> - * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY
> EXPRESS OR
> >> - * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> IMPLIED WARRANTIES
> >> - * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> DISCLAIMED.
> >> - * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT,
> INDIRECT,
> >> - * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
> (INCLUDING, BUT
> >> - * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
> SERVICES; LOSS OF USE,
> >> - * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
> AND ON ANY
> >> - * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
> TORT
> >> - * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
> OF THE USE OF
> >> - * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
> DAMAGE.
> >> - *
> >> - * $FreeBSD$
> >> - */
> >> -
> >> -/* $NetBSD: bus.h,v 1.12 1997/10/01 08:25:15 fvdl Exp $*/
> >> -
> >> -/*-
> >> - * Copyright (c) 1996, 1997 The NetBSD Foundation, Inc.
> >> - * All rights reserved.
> >> - *
> >> - * This code is derived from software contributed to The NetBSD
> Foundation
> >> - * by Jason R. Thorpe of the Numerical Aerospace Simulation Facility,
> >> - * NASA Ames Research Center.
> >> - *
> >> - * Redistribution and use in source and binary forms, with or without
> >> - * modification, are permitted provided that the following conditions
> >> - * are met:
> >> - * 1. Redistributions of source code must retain the above copyright
> >> - *notice, this list of conditions and the following disclaimer.
> >> - * 2. Redistributions in binary form must reproduce the above copyright
> >> - *notice, this list of conditions and the following disclaimer in the
> >> - *documentation and/or other materials provided with the
> distribution.
> >> - *
> >> - * THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND
> CONTRIBUTORS
> >> - * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT
> NOT LIMITED
> >> - * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
> FOR A PARTICULAR
> >> - * PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE FOUNDATION OR
> CONTRIBUTORS
> >> - * BE LIABLE FOR ANY 

RE: [PATCH v1] bsps/riscv: Give enough time for clock driver initialization

[Jan.Sommer]

> -Original Message-
> From: Gedare Bloom 
> Sent: Monday, June 7, 2021 7:00 PM
> To: Sommer, Jan 
> Cc: devel@rtems.org
> Subject: Re: [PATCH v1] bsps/riscv: Give enough time for clock driver
> initialization
> 
> On Mon, Jun 7, 2021 at 9:47 AM Jan Sommer  wrote:
> >
> > - Clock driver initialization for secondary cores had to take less
> > than one tick
> > - If tick time is small (i.e. <= 1ms) setting up all cores could take
> > too long and a fatal error is thrown.
> > - Give at least 10 ms time for clock initialization to avoid this
> > error
> 
> Is there a reason to pick 10?
>

In qemu I (coarsely) measured 1.5ms for 8 cores.
So I thought this should add enough buffer to prevent a fatal error.
I probably could also reduce it to 5 ms.
 
> I assume this blocks/idles the system until the interval elapses, so it would 
> be
> good to minimize waste (subject to Joel's noted rant about premature
> optimization).
> 

If you take a look at the clock initialization of the secondary cores 
(https://git.rtems.org/rtems/tree/bsps/riscv/riscv/clock/clockdrv.c#n178):

_SMP_Othercast_action(riscv_clock_secondary_action, );

  if (cmpval - riscv_clock_read_mtime(>mtime) >= interval) {
bsp_fatal(RISCV_FATAL_CLOCK_SMP_INIT);
  }

It will put the first clock tick 10ms into the future (instead of just one 
tick), but it won't block the system initialization.
It only prevents entering the if condition by having a large enough value for 
interval, but the runtime of the clock initialization is the same.

> > ---
> >  bsps/riscv/riscv/clock/clockdrv.c | 8 +++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/bsps/riscv/riscv/clock/clockdrv.c
> > b/bsps/riscv/riscv/clock/clockdrv.c
> > index 3afe86576f..102137aeab 100644
> > --- a/bsps/riscv/riscv/clock/clockdrv.c
> > +++ b/bsps/riscv/riscv/clock/clockdrv.c
> > @@ -211,7 +211,13 @@ static void riscv_clock_initialize(void)
> >tc->interval = interval;
> >
> >cmpval = riscv_clock_read_mtime(>mtime);
> > -  cmpval += interval;
> > +  /*
> > +   * For very short intervals the time of 1 tick is not enough to
> > +   * set up the timer on all cores in SMP systems.
> > +   * Give the CPU at least 10 ms.
> > +   */
> > +  interval = (1 / us_per_tick) * interval;  cmpval += interval;
> >
> >riscv_clock_clint_init(clint, cmpval, 0);
> >riscv_clock_secondary_initialization(clint, cmpval, interval);
> > --
> > 2.17.1
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH v1 0/2] [libbsd] Install correct machine include headers

[Jan.Sommer]

Thanks, Chris & Christian.
I think I got a better understanding of the issues now and found a simpler 
solution which is less intrusive.
I will post a new patchset.

Best regards,

   Jan

> -Original Message-
> From: Chris Johns 
> Sent: Tuesday, June 1, 2021 11:28 PM
> To: Christian Mauderer ; Gedare Bloom
> ; Sommer, Jan 
> Cc: devel@rtems.org
> Subject: Re: [PATCH v1 0/2] [libbsd] Install correct machine include headers
> 
> On 2/6/21 4:20 am, Christian Mauderer wrote:
> > On 01/06/2021 19:24, Gedare Bloom wrote:
> >> On Mon, May 10, 2021 at 11:26 AM Jan Sommer 
> wrote:
> >>>
> >>> Hello,
> >>>
> >>> This is a follow-up on this discussion regarding the installed
> >>> header files in libbsd:
> >>> https://lists.rtems.org/pipermail/devel/2021-April/066211.html
> >>>
> >>> The current situation is, that for example for all machines the
> >>> bus.h is installed from within the rtemsbsd directory
> >>> (https://git.rtems.org/rtems-
> libbsd/tree/rtemsbsd/include/machine/bus.h).
> >>>
> >>> According to the file docu it originates from the amd64 version of this
> file.
> >>> It also has the following section in it which we ran into when
> >>> compiling Chris' ptpd2 archive:
> >>>
> >>> #ifdef __i386__
> >>>    #error "your include paths are wrong"
> >>> #endif
> >>>
> >>> This patchset does the following:
> >>> - Add the target dependent machine include directory to
> >>> 'header-paths' in libbsd.py
> >>> - Import (mostly) '_bus.h', 'bus.h' and 'cpufunc.h' for the targets
> >>> from freebsd-org
> >>> - Remove those header files from rtemsbsd directory
> >>>
> >>> As a result the matching versions for machine dependent header files
> >>> are now installed for each BSP.
> >>> Would this be an acceptable solution?
> >>>
> >>> So far I compiled some BSPs for i386, arm, aarch64, powerpc, riscv,
> >>> sparc and
> >>> sparc64 to check that they still compile after the changes.
> >>> Are there any other architectures which should be included?
> >
> > I think the best starting point to find out the minimum supported
> > platforms is the nexus-devices.h. At least the officially supported
> > BSPs should have an entry there. That is:
> >
> > #if defined(LIBBSP_ARM_REALVIEW_PBX_A9_BSP_H)
> > #elif defined(LIBBSP_ARM_BEAGLE_BSP_H) #elif
> > defined(LIBBSP_ARM_LPC32XX_BSP_H) #elif
> > defined(LIBBSP_M68K_GENMCF548X_BSP_H)
> > #elif defined(LIBBSP_ARM_XILINX_ZYNQ_BSP_H)
> > #elif defined(LIBBSP_AARCH64_XILINX_ZYNQMP_BSP_H)
> > #elif defined(LIBBSP_ARM_ATSAM_BSP_H)
> > #elif defined(LIBBSP_ARM_ALTERA_CYCLONE_V_BSP_H)
> > #elif defined(LIBBSP_ARM_IMX_BSP_H)
> > #elif defined(LIBBSP_ARM_IMXRT_BSP_H)
> > #elif defined(LIBBSP_ARM_LPC24XX_BSP_H) #elif
> > defined(LIBBSP_ARM_STM32H7_BSP_H) #elif
> > defined(LIBBSP_I386_PC386_BSP_H) #elif
> > defined(LIBBSP_POWERPC_QORIQ_BSP_H)
> > #elif defined(LIBBSP_POWERPC_TQM8XX_BSP_H)
> > #elif defined(LIBBSP_POWERPC_MOTOROLA_POWERPC_BSP_H)
> >
> > So I think you should have a look at m68k too.
> >
> > Did you try to run it on any of the platforms?
> >
> >>>
> >>> I ran into one problem regarding the compilation of
> >>> rtemsbsd/sys/dev/dw_mmc/dw_mmc.c:105
> >>>
>  return (bus_space_read_4(0, sc->bushandle, off));
> >>>
> >>> The first parameter creates an error for riscv (I think because
> >>> dereferencing a NULL pointer).
> >>> Are there any suggestion how to solve it (I am not familiar with the
> >>> bus space and there is a lot of macro magic going on)?
> >>>
> >> It looks like this will be a problem for any architecture. so should
> >> the function that calls bus_space_write_4(0 ...)
> >>   The macro trail goes...
> >>
> >> #define    __bs_rs(sz, t, h, o)
> >> \
> >>     (*(t)->__bs_opname(r,sz))((t)->bs_cookie, h, o)
> >>
> >> #define    bus_space_read_4(t, h, o)   __bs_rs(4,(t),(h),(o))
> >>
> >> so t is dereferenced. It appears to be an error in the API usage by
> >> the dw_mmc.c code to not specify a valid bus space.
> >
> > dw_mmc is only relevant for very few platforms. So in theory it could
> > be limited to these. But most likely that won't really solve the problem.
> >
> > The right answer is that dw_mmc doesn't use the API like intended
> > (like Gedare said). That could be a problem for more drivers that use
> > stuff from bus.h in rtemsbsd. They never had to use that API
> > correctly. Even worse: Some of the __rtems__ hacks in freebsd could have
> that problem too.
> >
> > I think for this patch set we either need to have a thorough look at
> > these locations or run (not only build) it on a number of platforms,
> > especially the ones with special drivers in rtemsbsd or with heavily adapted
> drivers.
> 
> The only arch that supports a tag we current have is the x86 and that is for 
> IO
> vs mem space. I posted some patches earlier this year I need to revisit for
> the powerpc (mvme2700). If possible we prefer no tags and a single flat
> address space that is cache coherent. In the x86 tags cannot be avoided and
> supported drivers handle 

Improve SMP support for PC BSP

[Jan.Sommer]

Hello,

Currently the pc BSP in SMP mode uses a timer interrupt on cpu0 which is then 
distributed to all other cores via an IPI for the scheduler tick.
This means, if cpu0 locally disables its interrupts (e.g. in a driver), all 
schedulers lose their sense of time.
Worst case this could lead to a hanging system, e.g. like in the test 
smpclock01 (https://devel.rtems.org/ticket/4008).
The clockdriver uses the PIT and as far as I understand it, it is only possible 
to create a global timer interrupt with the PIT and not simultaneous interrupts 
for each core (please correct me if I am wrong).

I started reading into possible solutions and as with everything x86-related, 
it is a bit messy.
So my propsed steps forward would be the following:

1. Update the CPU feature recognition:
-

The next steps need to know about the availability of more modern features.
So, I would port the identcpu.c (and possibly the tsc.c) from FreeBSD to RTEMS.
I have done this for testing already and seems to be quite straight forward.

2. For RTEMS_SMP: Implement clockdriver for the Local APIC with TSC_DEADLINE 
mode
-

If the TSC_DEADLINE mode is available (i.e. on newer Intel processors (2013+)) 
this is probably the easiest and most accurate method.
The TSC rate on these processors is invariant and synchronized across all cores 
during reset (unless the BIOS does something stupid after reset).
Creating a clock driver for that using the Local APIC should be fairly straight 
forward.
Maybe the TSC calibration routine could be improved a bit.
We also have corresponding hardware here for testing.
In general I think for SMP we should require invariant TSCs, so that 
rtems_get_uptime and similar methods are in line across cores.

3. For RTEMS_SMP: Implement clockdriver for Local APIC without TSC_DEADLINE mode
-

For older or non-Intel processors the TSC_DEADLINE mode is not available.
As far as I see it, the most reasonable option would be to use the LAPIC timer 
in periodic mode.
To do that, I would first need to calibrate the rate of the Local APIC timer 
with the PIT, similar to the TSC. The rate of the LAPIC is the same across all 
cpu cores, the trouble is then the sychronization of the timer interrupt 
between all LAPICs of all cores.

I found this Master thesis which discusses synchronization via atomic variables 
with formulas derived from PTP:
https://core.ac.uk/download/pdf/302914733.pdf

It looks like this could synchronize the LAPIC timers across the cores 
reasonably well.
At the very least it should be an improvement compared to the distribution 
using the IPIs.
However, this work would not be required by our projects, so I have to see how 
to find some spare time for the implementation.

Anyways, would you see this as a viable solution? Or do you see any pitfalls I 
might have overlooked?

Best regards,

Jan



Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR)
German Aerospace Center
Institute for Software Technology | Software for Space Systems and Interactive 
Visualization | Lilienthalplatz 7 | 38108 Braunschweig | Germany

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

RE: [PATCH v1 0/2] [libbsd] Install correct machine include headers

[Jan.Sommer]

Ping :)

> -Original Message-
> From: Gedare Bloom 
> Sent: Monday, May 10, 2021 10:55 PM
> To: Sommer, Jan 
> Cc: devel@rtems.org
> Subject: Re: [PATCH v1 0/2] [libbsd] Install correct machine include headers
> 
> I can't review these currently, just want to put a note out there.
> Hopefully someone else gets to it. Otherwise ping it in a week or two and I
> might have more time to look myself..
> 
> On Mon, May 10, 2021 at 11:26 AM Jan Sommer 
> wrote:
> >
> > Hello,
> >
> > This is a follow-up on this discussion regarding the installed header
> > files in libbsd:
> > https://lists.rtems.org/pipermail/devel/2021-April/066211.html
> >
> > The current situation is, that for example for all machines the bus.h
> > is installed from within the rtemsbsd directory
> (https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/include/machine/bus.h).
> >
> > According to the file docu it originates from the amd64 version of this 
> > file.
> > It also has the following section in it which we ran into when compiling
> Chris' ptpd2 archive:
> >
> > #ifdef __i386__
> >   #error "your include paths are wrong"
> > #endif
> >
> > This patchset does the following:
> > - Add the target dependent machine include directory to 'header-paths'
> > in libbsd.py
> > - Import (mostly) '_bus.h', 'bus.h' and 'cpufunc.h' for the targets
> > from freebsd-org
> > - Remove those header files from rtemsbsd directory
> >
> > As a result the matching versions for machine dependent header files
> > are now installed for each BSP.
> > Would this be an acceptable solution?
> >
> > So far I compiled some BSPs for i386, arm, aarch64, powerpc, riscv, sparc
> and sparc64 to check that they still compile after the changes.
> > Are there any other architectures which should be included?
> >
> > I ran into one problem regarding the compilation of
> > rtemsbsd/sys/dev/dw_mmc/dw_mmc.c:105
> >
> > > return (bus_space_read_4(0, sc->bushandle, off));
> >
> > The first parameter creates an error for riscv (I think because 
> > dereferencing
> a NULL pointer).
> > Are there any suggestion how to solve it (I am not familiar with the bus
> space and there is a lot of macro magic going on)?
> >
> > Also, I am not sure if I always added the header files in the right
> > module in libbsd.py. Any suggestions where to put them instead would be
> welcome.
> >
> > Best regards,
> >
> > Jan
> >
> > Jan Sommer (2):
> >   rtemsbd: Remove machine dependent files and use the ones from
> freebsd
> >   machine: Add machine dependent header files to libbsd.py
> >
> >  freebsd/sys/arm/include/machine/_bus.h|  47 +
> >  freebsd/sys/arm/include/machine/bus.h | 769 
> >  freebsd/sys/arm64/include/machine/_bus.h  |  46 +
> >  freebsd/sys/arm64/include/machine/bus.h   | 469 ++
> >  freebsd/sys/powerpc/include/machine/_bus.h|  50 +
> >  freebsd/sys/powerpc/include/machine/bus.h | 467 ++
> >  freebsd/sys/riscv/include/machine/_bus.h  |  46 +
> >  freebsd/sys/riscv/include/machine/bus.h   | 469 ++
> >  freebsd/sys/riscv/include/machine/cpufunc.h   | 135 +++
> >  freebsd/sys/riscv/include/machine/riscvreg.h  | 246 +
> >  .../sys/sparc}/include/machine/_bus.h |   0
> >  .../sys/sparc}/include/machine/bus.h  |   0
> >  freebsd/sys/sparc/include/machine/cpufunc.h   |   0
> >  freebsd/sys/sparc64/include/machine/_bus.h|  41 +
> >  freebsd/sys/sparc64/include/machine/bus.h | 852
> ++
> >  libbsd.py |  26 +-
> >  rtemsbsd/include/machine/cpufunc.h|   1 -
> >  waf_libbsd.py |   2 -
> >  18 files changed, 3660 insertions(+), 6 deletions(-)  create mode
> > 100644 freebsd/sys/arm/include/machine/_bus.h
> >  create mode 100644 freebsd/sys/arm/include/machine/bus.h
> >  create mode 100644 freebsd/sys/arm64/include/machine/_bus.h
> >  create mode 100644 freebsd/sys/arm64/include/machine/bus.h
> >  create mode 100644 freebsd/sys/powerpc/include/machine/_bus.h
> >  create mode 100644 freebsd/sys/powerpc/include/machine/bus.h
> >  create mode 100644 freebsd/sys/riscv/include/machine/_bus.h
> >  create mode 100644 freebsd/sys/riscv/include/machine/bus.h
> >  create mode 100644 freebsd/sys/riscv/include/machine/cpufunc.h
> >  create mode 100644 freebsd/sys/riscv/include/machine/riscvreg.h
> >  rename {rtemsbsd => freebsd/sys/sparc}/include/machine/_bus.h (100%)
> > rename {rtemsbsd => freebsd/sys/sparc}/include/machine/bus.h (100%)
> > create mode 100644 freebsd/sys/sparc/include/machine/cpufunc.h
> >  create mode 100644 freebsd/sys/sparc64/include/machine/_bus.h
> >  create mode 100644 freebsd/sys/sparc64/include/machine/bus.h
> >  delete mode 100644 rtemsbsd/include/machine/cpufunc.h
> >
> > --
> > 2.17.1
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel

RE: Building llvm toolchain for RTEMS

[Jan.Sommer]

Ok, I build the llvm buildset with RSB and then tried to set the COMPILER 
option in the ini file for the BSP, but that did not work.
Is it only available for certain BSPs or am I completely of the track?

Best regards,

Jan

> -Original Message-
> From: devel  On Behalf Of jan.som...@dlr.de
> Sent: Friday, May 21, 2021 12:25 PM
> To: devel@rtems.org
> Subject: Building llvm toolchain for RTEMS
> 
> Hello,
> 
> I see some references to llvm toolchains for RTEMS from time to time, but
> haven't really looked into it.
> Is it possible to let RSB build a clang C/C++ compiler and kernel for e.g. the
> Zedboard BSP?
> If yes, how would I build such a toolchain? I see that there is a llvm 
> buildset in
> RSB, but it doesn't seem architecture specific.
> 
> Best regards,
> 
> Jan
> 
> Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR) German Aerospace
> Center Institute for Software Technology | Software for Space Systems and
> Interactive Visualization | Lilienthalplatz 7 | 38108 Braunschweig | Germany
> 
> Jan Sommer
> Telephone +49 531 295-2494 | Telefax 0531 295-2767 | jan.som...@dlr.de
> DLR.de/SC
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: Writing code that takes time to run

[Jan.Sommer]

Yes, exactly.
For example if you want to block for 1s:
uint32_t cycles_per_tick = T_get_one_clock_tick_busy(void);
uint32_t cycles_per_sec = rtems_clock_get_ticks_per_second() * cycles_per_tick;
T_busy(cycles_per_sec);

It you take a look at the implementation of T_busy 
(https://git.rtems.org/rtems/tree/cpukit/libtest/t-test-busy.c) it is just a 
loop which wastes count cpu cycles.
So the 1s is the time it blocks while being active on a CPU.

Of course this only holds true if the cpu frequency is constant during 
execution.
In most hardware cases this should be the case for RTEMS. I think by default 
energy saving is not used in BSPs.
I am not sure how qemu will behave. Does someone else have more information on 
this one?

Best regards

Jan

From: Richi Dubey 
Sent: Saturday, May 22, 2021 7:21 AM
To: Joel Sherrill 
Cc: Sommer, Jan ; rtems-de...@rtems.org 
Subject: Re: Writing code that takes time to run

Hi,

About the code:

 T_busy(T_get_one_clock_tick_busy() * SOME_CONSTANT);

does this support context switch? If task A executing on CPU 1 gets preempted 
while executing this (by task B) and then comes back on CPU 1 after some time 
(when task B finishes its execution), would task A finish its execution of this 
function - as nothing happened?

So, if we ask Task A to run T_busy for 5000 ticks, and it gets preempted after 
3000 ticks and maybe moves to another CPU, would it run for the remaining 2000 
ticks on that CPU?

On Fri, May 21, 2021 at 9:50 AM Richi Dubey 
mailto:richidu...@gmail.com>> wrote:
Hi,

Thanks for your quick responses!

The suggestion certainly is helpful, we are going to try it out. I'll post the 
result here.

On Thu, May 20, 2021 at 8:57 PM Joel Sherrill 
mailto:j...@rtems.org>> wrote:


On Thu, May 20, 2021 at 10:05 AM mailto:jan.som...@dlr.de>> 
wrote:
Hi Richi,

You can checkout the T_busy functions here: 
https://git.rtems.org/rtems/tree/cpukit/include/rtems/test.h#n2390
uint_fast32_t T_get_one_clock_tick_busy(void) gives you the busy count for one 
tick.

You can then calculate the number of cycles you need to wait for you desired 
certain time and pass it to: void T_busy(uint_fast32_t)
This should give you comparably accurate results over different platforms.

That's certainly a better method than what I suggested.

--joel

Best regards,

Jan



From: devel mailto:devel-boun...@rtems.org>> On Behalf 
Of Richi Dubey
Sent: Thursday, May 20, 2021 4:53 PM
To: rtems-de...@rtems.org 
mailto:devel@rtems.org>>
Subject: Writing code that takes time to run

Hi,

We are thinking of writing a piece of code that takes some time to run (it 
would be amazing if it takes around 2 secs to run on hardware, but we would be 
happy with something that takes a few milliseconds as well).

We tried writing this:

  for(int i = 0; i<1000; ++i){
  fib2 = fib0 + fib1;
  fib0 = fib1;
  fib1 = fib2;
  }

which takes few milliseconds when tested on qemu, but only takes few 
microseconds on a real board. Do you have any suggestions of what else we can 
do?

We want to write a code that is context switch safe (so, we can't simply check 
the time before a loop, run an infinite loop that keeps checking current time 
and stops after a few seconds - because this logic would fail if there happens 
a context switch inside the loop and the task gets the control back after a few 
seconds). We also don't want to do a wake_after() since we want the task to be 
running on the cpu during the entire time (it is okay if the task gets 
preempted due to a higher priority process), and not voluntarily giving the 
control to some other task.

Any suggestions? The aim is to see the affect of a task getting removed from 
the cpu due to task shifting by the newly arrived task (in strong apa vs non 
task shifting scheduler).

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

Building llvm toolchain for RTEMS

[Jan.Sommer]

Hello,

I see some references to llvm toolchains for RTEMS from time to time, but 
haven't really looked into it.
Is it possible to let RSB build a clang C/C++ compiler and kernel for e.g. the 
Zedboard BSP?
If yes, how would I build such a toolchain? I see that there is a llvm buildset 
in RSB, but it doesn't seem architecture specific.

Best regards,

Jan

Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR)
German Aerospace Center
Institute for Software Technology | Software for Space Systems and Interactive 
Visualization | Lilienthalplatz 7 | 38108 Braunschweig | Germany

Jan Sommer
Telephone +49 531 295-2494 | Telefax 0531 295-2767 | jan.som...@dlr.de
DLR.de/SC

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

RE: Writing code that takes time to run

[Jan.Sommer]

Hi Richi,

You can checkout the T_busy functions here: 
https://git.rtems.org/rtems/tree/cpukit/include/rtems/test.h#n2390
uint_fast32_t T_get_one_clock_tick_busy(void) gives you the busy count for one 
tick.

You can then calculate the number of cycles you need to wait for you desired 
certain time and pass it to: void T_busy(uint_fast32_t)
This should give you comparably accurate results over different platforms.

Best regards,

Jan



From: devel  On Behalf Of Richi Dubey
Sent: Thursday, May 20, 2021 4:53 PM
To: rtems-de...@rtems.org 
Subject: Writing code that takes time to run

Hi,

We are thinking of writing a piece of code that takes some time to run (it 
would be amazing if it takes around 2 secs to run on hardware, but we would be 
happy with something that takes a few milliseconds as well).

We tried writing this:

  for(int i = 0; i<1000; ++i){
  fib2 = fib0 + fib1;
  fib0 = fib1;
  fib1 = fib2;
  }

which takes few milliseconds when tested on qemu, but only takes few 
microseconds on a real board. Do you have any suggestions of what else we can 
do?

We want to write a code that is context switch safe (so, we can't simply check 
the time before a loop, run an infinite loop that keeps checking current time 
and stops after a few seconds - because this logic would fail if there happens 
a context switch inside the loop and the task gets the control back after a few 
seconds). We also don't want to do a wake_after() since we want the task to be 
running on the cpu during the entire time (it is okay if the task gets 
preempted due to a higher priority process), and not voluntarily giving the 
control to some other task.

Any suggestions? The aim is to see the affect of a task getting removed from 
the cpu due to task shifting by the newly arrived task (in strong apa vs non 
task shifting scheduler).

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

RE: [PATCH v2 1/1] grlib/genirq: Taking into account that it could be more than one ISR enabled/disabled

[Jan.Sommer]

Thanks, pushed to master and 5.

From: devel  On Behalf Of Daniel Hellstrom
Sent: Thursday, April 15, 2021 1:03 PM
To: Moyano Heredia, Victor Gabriel ; devel@rtems.org
Subject: Re: [PATCH v2 1/1] grlib/genirq: Taking into account that it could be 
more than one ISR enabled/disabled


Looks good.

Thanks,
Daniel


On 2021-04-15 11:52, Moyano, Gabriel wrote:

---

 bsps/shared/grlib/irq/genirq.c | 4 ++--

 1 file changed, 2 insertions(+), 2 deletions(-)



diff --git a/bsps/shared/grlib/irq/genirq.c b/bsps/shared/grlib/irq/genirq.c

index 285416b0d3..ca80445c70 100644

--- a/bsps/shared/grlib/irq/genirq.c

+++ b/bsps/shared/grlib/irq/genirq.c

@@ -188,8 +188,8 @@ static int genirq_set_active(

   return 1;

}

e = isrentry;

-   } else {

-   enabled += isrentry->enabled;

+   } else if ( isrentry->enabled ) {

+   enabled = 1;

}

isrentry = isrentry->next;

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

RE: [PATCH 0/1] grlib/genirq: Issue when enabling/disabling interrupt

[Jan.Sommer]

Does someone have any objections to this patch?
I would like to push it to master and 5.
Or should we reach out to someone at Gaisler to check if it is ok?

Best regards,

Jan

> -Original Message-
> From: devel  On Behalf Of
> gabriel.moy...@dlr.de
> Sent: Tuesday, April 13, 2021 10:09 AM
> To: Moyano Heredia, Victor Gabriel ;
> ged...@rtems.org
> Cc: devel@rtems.org
> Subject: AW: [PATCH 0/1] grlib/genirq: Issue when enabling/disabling
> interrupt
> 
> >Yes, rtems 5 also has it. I can create a ticket.
> 
> Here is the link to the ticket https://devel.rtems.org/ticket/4385#ticket.
> BTW the proposed solution for the master branch can be also applied to 5 as
> well.
> 
> >Regarding the proposed solution, I wanted to start a thread for discussing it
> (maybe there is better was to do it).
> >
> >
> >>Is this a bug in rtems 5 also?
> >>
> >>If so, does it warrant a back-port fix and a ticket?
> >>
> >>On Mon, Apr 12, 2021 at 3:16 AM Moyano, Gabriel
>  wrote:
> >>>
> >>> Hello everyone,
> >>>
> >>> I've found what can be an issue in the function genirq_set_active():
> under some conditions it can return a value greater than 1.
> >>>
> >>> This function is used by genirq_enable() and genirq_disable() and both
> of them returns the value returned by genirq_set_active(). According to the
> documentation in genirq.h, they should return -1, 0 or 1.
> >>>
> >>> When this issue can happen? If there are 3 entries in the list of IRQ and 
> >>> 2
> of them are already enabled, the variable `enabled` would be 2, because of
> `enabled += isrentry->enabled`.
> >>>
> >>> As a possible solution, the value of `enabled` can changed to 1 if it's
> greater than 1 (see the patch) or maybe improve the search.
> >>>
> >>> Thanks in advance,
> >>>
> >>> Gabriel Moyano
> >>>
> >>>
> >>>
> >>> Moyano, Gabriel (1):
> >>>   grlib/genirq: Taking into account that it could be more than one ISR
> >>> enabled/disabled
> >>>
> >>>  bsps/shared/grlib/irq/genirq.c | 5 +
> >>>  1 file changed, 5 insertions(+)
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: Booting a rtems exe on Zynq UltraScale+ MPSoC ZCU106 board

[Jan.Sommer]

Hi Richi,

In your log it says:

Image Type:   ARM Linux Kernel Image (gzip compressed)

At least for our zedboard devices we use the following main options for mkimage.

mkimage  -A arm -O rtems -T kernel

Which yields  for me:
Image Type:   ARM RTEMS Kernel Image (gzip compressed)

IIRC the difference between -O rtems  and -O linux is subtle, but maybe that 
helps.

Best regards,

Jan


From: devel  On Behalf Of Richi Dubey
Sent: Wednesday, April 14, 2021 3:22 PM
To: Kinsey Moore 
Cc: rtems-de...@rtems.org 
Subject: Re: Booting a rtems exe on Zynq UltraScale+ MPSoC ZCU106 board

Trying to boot directly from the .img  file also fails:

ZynqMP> tftpboot 0x300 rdubey/sp01.img
Using ethernet@ff0e device
TFTP from server 172.19.0.3; our IP address is 172.19.2.40
Filename 'rdubey/sp01.img'.
Load address: 0x300
Loading: 
 6.1 MiB/s
done
Bytes transferred = 50978 (c722 hex)
ZynqMP> bootm  0x300  ; reset
## Booting kernel from Legacy Image at 0300 ...
   Image Name:   RTEMS
   Image Type:   ARM Linux Kernel Image (gzip compressed)
   Data Size:50914 Bytes = 49.7 KiB
   Load Address: 0030
   Entry Point:  0030
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
FDT and ATAGS support not compiled in - hanging
### ERROR ### Please RESET the board ###

What can I do now?

On Wed, Apr 14, 2021 at 6:11 PM Kinsey Moore 
mailto:kinsey.mo...@oarcorp.com>> wrote:
If you’re only running RTEMS, you should be able to drop the FDT commands since 
that what appears to be causing the problem and I don’t think that the 
arm/xilinx_zynqmp BSP uses it at all.

Kinsey

From: Richi Dubey mailto:richidu...@gmail.com>>
Sent: Wednesday, April 14, 2021 01:01
To: Kinsey Moore mailto:kinsey.mo...@oarcorp.com>>; 
rtems-de...@rtems.org 
mailto:devel@rtems.org>>
Subject: Booting a rtems exe on Zynq UltraScale+ MPSoC ZCU106 board

Hi,

I followed the 8.2.23 
docs
 to build rtems for the xilinx_zynqmp_ultra96 bsp since it was the only bsp 
corresponding to xilinx-zynqmp in the rtems-bsp.

Then I followed the boot via Uboot section 8.2.1.1 on 
docs,
 but the uboot on zcu106 does not have a run loadfdt command, and its 
alternative is fdt addr [address]. But something is wrong, I cannot run the 
sp01.img file:

With fdt:
--
ZynqMP> tftpboot 0x300 rdubey/sp01.img
Using ethernet@ff0e device
TFTP from server 172.19.0.3; our IP address is 172.19.2.40
Filename 'rdubey/sp01.img'.
Load address: 0x300
Loading: 
 6.9 MiB/s
done
Bytes transferred = 50978 (c722 hex)
ZynqMP> fdt addr 0x2A0
ZynqMP> bootm  0x300 - 0x2A0 ; reset
## Booting kernel from Legacy Image at 0300 ...
   Image Name:   RTEMS
   Image Type:   ARM Linux Kernel Image (gzip compressed)
   Data Size:50914 Bytes = 49.7 KiB
   Load Address: 0030
   Entry Point:  0030
   Verifying Checksum ... OK
## Flattened Device Tree blob at 02a0
   Booting using the fdt blob at 0x2a0
   Uncompressing Kernel Image ... OK
   Loading Device Tree to 07ff1000, end 07fff257 ... OK
fdt_find_or_add_subnode: chosen: FDT_ERR_BADSTRUCTURE
ERROR: /chosen node create failed
 - must RESET the board to recover.

FDT creation failed! hanging...### ERROR ### Please RESET the board ###
--

With loading the system.dtb that I generally use for loading yocto linux images:


-
ZynqMP> tftpboot 0x2A0 rdubey/system.dtb
Using ethernet@ff0e device
TFTP from server 172.19.0.3; our IP address is 172.19.253.142
Filename 'rdubey/system.dtb'.
Load address: 0x2a0
Loading: ###T #
 8.8 KiB/s
done
Bytes transferred = 45656 (b258 hex)
ZynqMP> tftpboot 0x300 rdubey/sp01.img
Using ethernet@ff0e device
TFTP from server 172.19.0.3; our IP address is 172.19.253.142
Filename 'rdubey/sp01.img'.
Load address: 0x300
Loading: 
 1.7 MiB/s
done
Bytes transferred = 50978 (c722 hex)
ZynqMP> bootm  0x300 - 0x2A0 ; reset
## Booting kernel from Legacy Image at 0300 ...
   Image Name:   RTEMS
   Image Type:   ARM Linux Kernel Image (gzip compressed)
   Data Size:50914 Bytes = 49.7 KiB
   Load Address: 0030
   Entry Point:  0030
   Verifying Checksum ... OK
## Flattened Device Tree blob at 02a0
   Booting using the fdt blob at 0x2a0
   Uncompressing Kernel Image ... OK
   Loading Device Tree to 07ff1000, end 07fff257 ... OK

Starting kernel ...

"Synchronous Abort" handler, esr 0x0200
elr: 90593000 lr : 10081868 (reloc)
elr: 0030 lr : 7fdee868
x0 :  x1 : 
x2 : 07ff1000 x3 : 
x4 : 0030 x5 : 
x6 : 0008 x7 : 
x8 : 

RE: [libbsd] How to install machine header files?

[Jan.Sommer]

@Sebastian: Do you have a suggestion how I could resolve this? I think you have 
the most experience with the libbsd build system.

Best regards,

Jan

> -Original Message-
> From: devel  On Behalf Of jan.som...@dlr.de
> Sent: Thursday, April 1, 2021 11:59 AM
> To: chr...@rtems.org; devel@rtems.org
> Subject: RE: [libbsd] How to install machine header files?
> 
> > -Original Message-
> > From: Chris Johns 
> > Sent: Thursday, April 1, 2021 6:25 AM
> > To: Sommer, Jan ; devel@rtems.org
> > Subject: Re: [libbsd] How to install machine header files?
> >
> > On 1/4/21 6:37 am, jan.som...@dlr.de wrote:
> > > Hello,
> > >
> > > I stumbled upon some include path problems in libbsd while looking
> > > at
> > Chris' ptpd port and I am not sure what is the recommended way to solve
> it.
> > > It starts with "freebsd/sys/sys/bus.h" including "machine/_bus.h".
> > > Currently, this will be the one from within "rtemsbd" which will
> > > redirect to
> > "rtemsbsd/include/machine/bus.h" which is amd64 specific.
> > > For the pc686 BSP this will create a compile error for applications
> > > which
> > include "".
> >
> > OK.
> >
> > > I tried to solve it by removing the "_bus.h" in rtemsbsd and
> > > installing the
> > correct one from "freebsd/sys/i386/include/machine/_bus.h", but I am
> > not sure how to tell waf to install the file.
> > > Is there a way to add a single architecture specific header to the
> > > install
> > headers?
> >
> > Yes 
> >
> > https://git.rtems.org/rtems-libbsd/tree/libbsd.py#n111
> > https://git.rtems.org/rtems-libbsd/tree/libbsd.py#n2903
> >
> > > I could add a corresponding path and wildcard to the "header-paths"
> > > in
> > libbsd.py, but I am not sure if this is the right place.
> >
> > I think the PCI module is the place to handle this. I am sorry but I
> > cannot see the issue clear at the moment and I cannot invest time
> performing a build.
> >
> 
> Thank you for taking a look at it.
> The main problem is, that the header files added there are not copied to the
> prefix with "waf install".
> To me it looks like only the files matched with header-paths
> (https://git.rtems.org/rtems-libbsd/tree/libbsd.py#n123) are installed.
> I checked today with the pc686 and zedboard builds and the header files
> which end up in PREFIX/lib/include/machine are only the ones from within
> the rtemsbsd directory and none from the
> freebsd/sys/$ARCH/include/machine.
> 
> > The addCPUDependentFreeBSDHeaderFiles() on line 2931 of libbsd.py in
> > the PCI module looks a little suspect because there is no list of archs
> provided.
> > Could the issue be as simple as the list of archs is not there and the
> > list is empty?
> >
> 
> It looks like only some of the add* functions take an archs list.
> addCPUDependentFreeBSDHeaderFiles() only takes the header file list.
> I dug around in the waf_libbsd.py, but I couldn't figure out what happens to
> the header files added by this function.
> 
> Best regards,
> 
> Jan
> 
> > Chris
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [rtems5 PATCH 0/5] Backport zynq SPI drivers to rtems5

[Jan.Sommer]

> -Original Message-
> From: Chris Johns 
> Sent: Thursday, April 1, 2021 2:15 AM
> To: Sommer, Jan ; devel@rtems.org
> Subject: Re: [rtems5 PATCH 0/5] Backport zynq SPI drivers to rtems5
> 
> Hi Jan,
> 
> This looks good. Has this been tested on zync hardware? If no then some
> testing is needed and if yes then please push.
> 

Yes, I tested it this morning on a Zynq device and pushed.

Best regards,

Jan

> Thanks
> Chris
> 
> On 31/3/21 8:06 pm, Jan Sommer wrote:
> > This patchset backports:
> > - The cadence SPI driver (see: https://devel.rtems.org/ticket/4369)
> > - The xilinx axi SPI driver (see: https://devel.rtems.org/ticket/4370)
> > - The i2c and spi shell commands (see:
> > https://devel.rtems.org/ticket/4371)
> >
> > For the SPI drivers I didn't change any code (except the include
> > paths) I put them in bsps/arm/shared instead of bsps/shared, since
> > rtems5 has no aarch64 BSPs which could use them.
> >
> > From Christian's commit I only stripped the part for the waf build
> > system. I found the commands quite handy during driver development and
> > testing.
> >
> > Best regards,
> >
> > Jan
> >
> > Christian Mauderer (1):
> >   shell: Add i2c and spi commands
> >
> > Jan Sommer (4):
> >   bsps/xilinx_zynq: Add SPI driver for cadence-spi
> >   bsps/xilinx_zynq: Add cadence SPI driver to build system
> >   bsps/xilinx_zynq: Add SPI driver for xilinx-axi-spi
> >   bsps/xilinx_zynq: Add Xilinx AXI SPI driver to build
> >
> >  bsps/arm/headers.am   |   4 +
> >  bsps/arm/include/bsp/cadence-spi-regs.h   |  84 
> >  bsps/arm/include/bsp/cadence-spi.h|  63 +++
> >  bsps/arm/include/bsp/xilinx-axi-spi-regs.h|  88 
> >  bsps/arm/include/bsp/xilinx-axi-spi.h |  67 +++
> >  bsps/arm/shared/spi/cadence-spi.c | 444 ++
> >  bsps/arm/shared/spi/xilinx-axi-spi.c  | 402 
> >  c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am  |   4 +
> >  .../lib/libbsp/arm/xilinx-zynqmp/Makefile.am  |   4 +
> >  cpukit/Makefile.am|   4 +
> >  cpukit/include/rtems/shellconfig.h|  28 ++
> >  cpukit/libmisc/shell/main_i2cdetect.c | 107 +
> >  cpukit/libmisc/shell/main_i2cget.c| 145 ++
> >  cpukit/libmisc/shell/main_i2cset.c| 124 +
> >  cpukit/libmisc/shell/main_spi.c   | 157 +++
> >  15 files changed, 1725 insertions(+)
> >  create mode 100644 bsps/arm/include/bsp/cadence-spi-regs.h
> >  create mode 100644 bsps/arm/include/bsp/cadence-spi.h
> >  create mode 100644 bsps/arm/include/bsp/xilinx-axi-spi-regs.h
> >  create mode 100644 bsps/arm/include/bsp/xilinx-axi-spi.h
> >  create mode 100644 bsps/arm/shared/spi/cadence-spi.c  create mode
> > 100644 bsps/arm/shared/spi/xilinx-axi-spi.c
> >  create mode 100644 cpukit/libmisc/shell/main_i2cdetect.c
> >  create mode 100644 cpukit/libmisc/shell/main_i2cget.c
> >  create mode 100644 cpukit/libmisc/shell/main_i2cset.c
> >  create mode 100644 cpukit/libmisc/shell/main_spi.c
> >
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [libbsd] How to install machine header files?

[Jan.Sommer]

> -Original Message-
> From: Chris Johns 
> Sent: Thursday, April 1, 2021 6:25 AM
> To: Sommer, Jan ; devel@rtems.org
> Subject: Re: [libbsd] How to install machine header files?
> 
> On 1/4/21 6:37 am, jan.som...@dlr.de wrote:
> > Hello,
> >
> > I stumbled upon some include path problems in libbsd while looking at
> Chris' ptpd port and I am not sure what is the recommended way to solve it.
> > It starts with "freebsd/sys/sys/bus.h" including "machine/_bus.h".
> > Currently, this will be the one from within "rtemsbd" which will redirect to
> "rtemsbsd/include/machine/bus.h" which is amd64 specific.
> > For the pc686 BSP this will create a compile error for applications which
> include "".
> 
> OK.
> 
> > I tried to solve it by removing the "_bus.h" in rtemsbsd and installing the
> correct one from "freebsd/sys/i386/include/machine/_bus.h", but I am not
> sure how to tell waf to install the file.
> > Is there a way to add a single architecture specific header to the install
> headers?
> 
> Yes 
> 
> https://git.rtems.org/rtems-libbsd/tree/libbsd.py#n111
> https://git.rtems.org/rtems-libbsd/tree/libbsd.py#n2903
> 
> > I could add a corresponding path and wildcard to the "header-paths" in
> libbsd.py, but I am not sure if this is the right place.
> 
> I think the PCI module is the place to handle this. I am sorry but I cannot 
> see
> the issue clear at the moment and I cannot invest time performing a build.
> 

Thank you for taking a look at it.
The main problem is, that the header files added there are not copied to the 
prefix with "waf install".
To me it looks like only the files matched with header-paths 
(https://git.rtems.org/rtems-libbsd/tree/libbsd.py#n123) are installed.
I checked today with the pc686 and zedboard builds and the header files which 
end up in PREFIX/lib/include/machine are only the ones from within the rtemsbsd 
directory and none from the freebsd/sys/$ARCH/include/machine.

> The addCPUDependentFreeBSDHeaderFiles() on line 2931 of libbsd.py in the
> PCI module looks a little suspect because there is no list of archs provided.
> Could the issue be as simple as the list of archs is not there and the list is
> empty?
> 

It looks like only some of the add* functions take an archs list.
addCPUDependentFreeBSDHeaderFiles() only takes the header file list.
I dug around in the waf_libbsd.py, but I couldn't figure out what happens to 
the header files added by this function.

Best regards,

Jan

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

[libbsd] How to install machine header files?

[Jan.Sommer]

Hello,

I stumbled upon some include path problems in libbsd while looking at Chris' 
ptpd port and I am not sure what is the recommended way to solve it.
It starts with "freebsd/sys/sys/bus.h" including "machine/_bus.h".
Currently, this will be the one from within "rtemsbd" which will redirect to 
"rtemsbsd/include/machine/bus.h" which is amd64 specific.
For the pc686 BSP this will create a compile error for applications which 
include "".

I tried to solve it by removing the "_bus.h" in rtemsbsd and installing the 
correct one from "freebsd/sys/i386/include/machine/_bus.h", but I am not sure 
how to tell waf to install the file.
Is there a way to add a single architecture specific header to the install 
headers?
I could add a corresponding path and wildcard to the "header-paths" in 
libbsd.py, but I am not sure if this is the right place.

Best regards,

Jan


Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR)
German Aerospace Center
Institute for Software Technology | Software for Space Systems and Interactive 
Visualization | Lilienthalplatz 7 | 38108 Braunschweig | Germany


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

RE: [PATCH 0/3] Add spidev driver for Xilinx AXI Quad SPI device

[Jan.Sommer]

Thanks, pushed to master.
I will prepare the tickets and patches for backporting next.

Best regards,

Jan

> -Original Message-
> From: Gedare Bloom 
> Sent: Tuesday, March 30, 2021 4:12 PM
> To: Sommer, Jan 
> Cc: devel@rtems.org
> Subject: Re: [PATCH 0/3] Add spidev driver for Xilinx AXI Quad SPI device
> 
> This is all xilinx-zynq/zynqmp stuff. It has sat for several weeks now with no
> comment, go ahead and merge it.
> 
> The backport of the driver is probably fine, the shell command will need
> review--they'll both need tickets for backport also.
> 
> Gedare
> 
> On Tue, Mar 30, 2021 at 2:01 AM  wrote:
> >
> > Just a short bump for this patch.
> >
> > > -Original Message-
> > > From: Sommer, Jan
> > > Sent: Wednesday, March 10, 2021 9:15 PM
> > > To: devel@rtems.org
> > > Cc: Sommer, Jan 
> > > Subject: [PATCH 0/3] Add spidev driver for Xilinx AXI Quad SPI
> > > device
> > >
> > > This patchset adds a spidev driver for the Xilinx AXI Quad SPI device.
> > > It currently supports Standard SPI mode.
> > >
> > > Thanks goes to Rick van der Wal for testing the driver with his SPI IMU.
> > >
> > > Jan Sommer (3):
> > >   bsps/xilinx_zynq: Add SPI driver for xilinx-axi-spi
> > >   bsps/shared: Add Xilinx-AXI SPI driver to waf
> > >   bsps/xilinx_zynq: Add Xilinx AXI SPI driver to autotools build
> > >
> > >  bsps/headers.am   |   2 +
> > >  bsps/include/dev/spi/xilinx-axi-spi-regs.h|  88 
> > >  bsps/include/dev/spi/xilinx-axi-spi.h |  67 +++
> > >  bsps/shared/dev/spi/xilinx-axi-spi.c  | 402 ++
> > >  c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am  |   1 +
> > >  .../lib/libbsp/arm/xilinx-zynqmp/Makefile.am  |   1 +
> > >  spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml |   2 +
> > >  spec/build/bsps/arm/xilinx-zynq/grp.yml   |   2 +
> > >  .../arm/xilinx-zynqmp/bspxilinxzynqmp.yml |   2 +
> > >  spec/build/bsps/objdevspixil.yml  |  18 +
> > >  10 files changed, 585 insertions(+)  create mode 100644
> > > bsps/include/dev/spi/xilinx-axi-spi-regs.h
> > >  create mode 100644 bsps/include/dev/spi/xilinx-axi-spi.h
> > >  create mode 100644 bsps/shared/dev/spi/xilinx-axi-spi.c
> > >  create mode 100644 spec/build/bsps/objdevspixil.yml
> > >
> > > --
> > > 2.17.1
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH 0/3] Add spidev driver for Xilinx AXI Quad SPI device

[Jan.Sommer]

Just a short bump for this patch.

> -Original Message-
> From: Sommer, Jan
> Sent: Wednesday, March 10, 2021 9:15 PM
> To: devel@rtems.org
> Cc: Sommer, Jan 
> Subject: [PATCH 0/3] Add spidev driver for Xilinx AXI Quad SPI device
> 
> This patchset adds a spidev driver for the Xilinx AXI Quad SPI device.
> It currently supports Standard SPI mode.
> 
> Thanks goes to Rick van der Wal for testing the driver with his SPI IMU.
> 
> Jan Sommer (3):
>   bsps/xilinx_zynq: Add SPI driver for xilinx-axi-spi
>   bsps/shared: Add Xilinx-AXI SPI driver to waf
>   bsps/xilinx_zynq: Add Xilinx AXI SPI driver to autotools build
> 
>  bsps/headers.am   |   2 +
>  bsps/include/dev/spi/xilinx-axi-spi-regs.h|  88 
>  bsps/include/dev/spi/xilinx-axi-spi.h |  67 +++
>  bsps/shared/dev/spi/xilinx-axi-spi.c  | 402 ++
>  c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am  |   1 +
>  .../lib/libbsp/arm/xilinx-zynqmp/Makefile.am  |   1 +
>  spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml |   2 +
>  spec/build/bsps/arm/xilinx-zynq/grp.yml   |   2 +
>  .../arm/xilinx-zynqmp/bspxilinxzynqmp.yml |   2 +
>  spec/build/bsps/objdevspixil.yml  |  18 +
>  10 files changed, 585 insertions(+)
>  create mode 100644 bsps/include/dev/spi/xilinx-axi-spi-regs.h
>  create mode 100644 bsps/include/dev/spi/xilinx-axi-spi.h
>  create mode 100644 bsps/shared/dev/spi/xilinx-axi-spi.c
>  create mode 100644 spec/build/bsps/objdevspixil.yml
> 
> --
> 2.17.1

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

RE: [PATCH v2 1/1] bsps/riscv: Add per cpu clock interrupt

[Jan.Sommer]

> -Original Message-
> From: Gedare Bloom 
> Sent: Monday, March 22, 2021 5:52 PM
> To: Sebastian Huber 
> Cc: Sommer, Jan ; devel@rtems.org
> Subject: Re: [PATCH v2 1/1] bsps/riscv: Add per cpu clock interrupt
> 
> On Mon, Mar 22, 2021 at 10:28 AM Sebastian Huber
>  wrote:
> >
> >
> > On 22/03/2021 16:56, Jan Sommer wrote:
> > > diff --git a/bsps/riscv/riscv/clock/clockdrv.c
> > > b/bsps/riscv/riscv/clock/clockdrv.c
> > > index d085b6bd95..e8a39c8591 100644
> > > --- a/bsps/riscv/riscv/clock/clockdrv.c
> > > +++ b/bsps/riscv/riscv/clock/clockdrv.c
> > > @@ -41,6 +41,7 @@
> > >   #include 
> > >   #include 
> > >   #include 
> > > +#include 
> > >
> > >   #include 
> > >
> > > @@ -92,13 +93,18 @@ static void riscv_clock_at_tick(riscv_timecounter
> *tc)
> > >   {
> > > volatile RISCV_CLINT_regs *clint;
> > > uint64_t value;
> > > +  uint32_t cpu = 0;
> > > +
> > > +#if defined(RTEMS_SMP)
> > > +  cpu = _CPU_SMP_Get_current_processor(); #endif
> > You can use rtems_scheduler_get_processor() to get rid of this include
> > of an implementation header and the #if.
> >
> 
> Nice catch. Jan, you can push it with the modification to use the API function
> instead. (Note: BSPs are in a gray area, but generally considered as
> "application" layer, so we should prefer they use the APIs, and if they need
> to poke into the internals of RTEMS, we need to consider why and what can
> be done to avoid violation of the
> layer/encapsulation.)
> 

Thanks. Pushed to master with the changes applied.

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

RE: [PATCH v2 1/1] bsps/riscv: Add per cpu clock interrupt

[Jan.Sommer]

> -Original Message-
> From: Sebastian Huber 
> Sent: Monday, March 22, 2021 5:28 PM
> To: Sommer, Jan ; devel@rtems.org
> Subject: Re: [PATCH v2 1/1] bsps/riscv: Add per cpu clock interrupt
> 
> 
> On 22/03/2021 16:56, Jan Sommer wrote:
> > diff --git a/bsps/riscv/riscv/clock/clockdrv.c
> > b/bsps/riscv/riscv/clock/clockdrv.c
> > index d085b6bd95..e8a39c8591 100644
> > --- a/bsps/riscv/riscv/clock/clockdrv.c
> > +++ b/bsps/riscv/riscv/clock/clockdrv.c
> > @@ -41,6 +41,7 @@
> >   #include 
> >   #include 
> >   #include 
> > +#include 
> >
> >   #include 
> >
> > @@ -92,13 +93,18 @@ static void riscv_clock_at_tick(riscv_timecounter
> *tc)
> >   {
> > volatile RISCV_CLINT_regs *clint;
> > uint64_t value;
> > +  uint32_t cpu = 0;
> > +
> > +#if defined(RTEMS_SMP)
> > +  cpu = _CPU_SMP_Get_current_processor(); #endif
> You can use rtems_scheduler_get_processor() to get rid of this include of an
> implementation header and the #if.
> 

Great. I was looking for that, but thought the function should be used by 
higher level applications because of the scheduler in the name.
Should have looked closer to see that it will end up 
_CPU_SMP_Get_current_processor in the end anyways.

Thanks, 

Jan

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

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

RE: About is_non_preempt_mode_supported

[Jan.Sommer]

> -Original Message-
> From: devel  On Behalf Of Gedare Bloom
> Sent: Thursday, March 18, 2021 8:11 PM
> To: Richi Dubey 
> Cc: rtems-de...@rtems.org 
> Subject: Re: About is_non_preempt_mode_supported
> 
> On Thu, Mar 18, 2021 at 11:25 AM Richi Dubey 
> wrote:
> >
> > Thanks for your help! I read the doc.
> >>
> >> This is definitely an area where you have to think a bit at the
> >> conceptual purpose of the API/feature to realize why it can't work or
> >> is unsafe in SMP mode.
> >
> > I understand. The only reason we would want to have a feature like no
> preemption for a thread is to give it the exclusive right to some data for 
> some
> time. Since there are multiple threads running on multiple processors, no
> preemption for one thread does not help us achieve anything. Got it.
> >
> > But, what if we still want such a feature? Why is it impossible to have? I
> don't see any harm in having a processor run a no preempt thread in an SMP
> environment.
> >
> It would not provide anything, and it might encourage a false sense of
> concurrency-safety.
> 

How would I temporarily disable preemption for the current thread on its 
specific core only?
For example, a thread sends several events to a set of other threads and this 
sending should not be interrupted in case the first event wakes up a sleeping 
thread of higher priority on the same CPU.
If there are no other resource dependencies, would a simple 
rtems_interrupt_local_disable be the right thing to do?

Best regards,

Jan

> > Thanks!
> >
> > On Wed, Mar 17, 2021 at 6:14 PM Joel Sherrill  wrote:
> >>
> >>
> >>
> >> On Wed, Mar 17, 2021 at 1:54 AM Richi Dubey 
> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I am debugging tm19 running on Strong APA scheduler. It gives the
> following error:
> >>> rtems_signal_catch FAILED -- expected (RTEMS_SUCCESSFUL) got
> >>> (RTEMS_NOT_IMPLEMENTED)
> >>>
> >>> which is due to line 167. This arises because the variable
> is_non_preempt_mode_supported in _Scheduler_Control of SMP Strong
> APA scheduler is set to false.
> >>>
> >>> On further checking, I can see that almost all the SMP schedulers have
> this variable set as false in cpukit/include/rtems/scheduler.h. Please let me
> know why this is the case. What would I need to do to support non preempt
> tasks in the Strong APA scheduler?
> >>
> >>
> >> No preempt does not make sense in an SMP environment. The idea with
> >> no preempt is that by setting it, the thread runs without another
> >> thread (only
> >> interrupts) preempting it. This works fine on uniprocessor systems
> >> but since there are always multiple threads running in SMP, the
> >> assumption is violated.
> >>
> >> No preempt is an old RTOS feature and sometimes has a name like
> >> scheduler lock. It is just one of the features/APIs not safe for SMP
> >> that we removed or made inoperable in SMP mode. This section in the
> >> manual covers these features:
> >>
> >> https://docs.rtems.org/branches/master/c-
> user/symmetric_multiprocessi
> >> ng_services.html#application-issues
> >>
> >> This is definitely an area where you have to think a bit at the
> >> conceptual purpose of the API/feature to realize why it can't work or
> >> is unsafe in SMP mode.
> >>
> >> --joel
> >>>
> >>> ___
> >>> devel mailing list
> >>> devel@rtems.org
> >>> http://lists.rtems.org/mailman/listinfo/devel
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH 0/3] Add spidev driver for Xilinx AXI Quad SPI device

[Jan.Sommer]

Could someone also please have a look at this patchset.
When this goes through, I would like to backport this, the cadence-spi driver 
and the spi shell command of Christian to rtems5.

Best regards,

Jan

> -Original Message-
> From: Sommer, Jan
> Sent: Wednesday, March 10, 2021 9:15 PM
> To: devel@rtems.org
> Cc: Sommer, Jan 
> Subject: [PATCH 0/3] Add spidev driver for Xilinx AXI Quad SPI device
> 
> This patchset adds a spidev driver for the Xilinx AXI Quad SPI device.
> It currently supports Standard SPI mode.
> 
> Thanks goes to Rick van der Wal for testing the driver with his SPI IMU.
> 
> Jan Sommer (3):
>   bsps/xilinx_zynq: Add SPI driver for xilinx-axi-spi
>   bsps/shared: Add Xilinx-AXI SPI driver to waf
>   bsps/xilinx_zynq: Add Xilinx AXI SPI driver to autotools build
> 
>  bsps/headers.am   |   2 +
>  bsps/include/dev/spi/xilinx-axi-spi-regs.h|  88 
>  bsps/include/dev/spi/xilinx-axi-spi.h |  67 +++
>  bsps/shared/dev/spi/xilinx-axi-spi.c  | 402 ++
>  c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am  |   1 +
>  .../lib/libbsp/arm/xilinx-zynqmp/Makefile.am  |   1 +
>  spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml |   2 +
>  spec/build/bsps/arm/xilinx-zynq/grp.yml   |   2 +
>  .../arm/xilinx-zynqmp/bspxilinxzynqmp.yml |   2 +
>  spec/build/bsps/objdevspixil.yml  |  18 +
>  10 files changed, 585 insertions(+)
>  create mode 100644 bsps/include/dev/spi/xilinx-axi-spi-regs.h
>  create mode 100644 bsps/include/dev/spi/xilinx-axi-spi.h
>  create mode 100644 bsps/shared/dev/spi/xilinx-axi-spi.c
>  create mode 100644 spec/build/bsps/objdevspixil.yml
> 
> --
> 2.17.1

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

RE: [PATCH v2] user/bsps: Mention fixed console baud rate for zynq

[Jan.Sommer]

Thanks. Pushed to master.

> -Original Message-
> From: Gedare Bloom 
> Sent: Monday, March 15, 2021 11:08 PM
> To: Joel Sherrill 
> Cc: Sommer, Jan ; rtems-de...@rtems.org
> 
> Subject: Re: [PATCH v2] user/bsps: Mention fixed console baud rate for zynq
> 
> Yeah go ahead, thanks Jan.
> 
> On Mon, Mar 15, 2021 at 6:58 AM Joel Sherrill  wrote:
> >
> > If this matches the state of the got master, then ok.
> >
> > On Mon, Mar 15, 2021, 7:55 AM  wrote:
> >>
> >> Could someone please have a look at this patch?
> >>
> >> > -Original Message-
> >> > From: Sommer, Jan
> >> > Sent: Friday, March 5, 2021 7:04 PM
> >> > To: devel@rtems.org
> >> > Cc: Sommer, Jan 
> >> > Subject: [PATCH v2] user/bsps: Mention fixed console baud rate for
> >> > zynq
> >> >
> >> > ---
> >> >  user/bsps/arm/xilinx-zynq.rst | 12 
> >> >  1 file changed, 12 insertions(+)
> >> >
> >> > diff --git a/user/bsps/arm/xilinx-zynq.rst
> >> > b/user/bsps/arm/xilinx-zynq.rst index 365c336..29f9cb0 100644
> >> > --- a/user/bsps/arm/xilinx-zynq.rst
> >> > +++ b/user/bsps/arm/xilinx-zynq.rst
> >> > @@ -37,6 +37,18 @@ to return the peripheral clock. Normally this is
> >> > half the CPU  clock. This function is declared ``weak`` so you can
> >> > override the  default behaviour by providing it in your application.
> >> >
> >> > +Console
> >> > +---
> >> > +
> >> > +The console driver for the UARTs will always be initialized to a
> >> > +baud rate of 115200 with 8 bit characters, 1 stop bit and no
> >> > +parity bits during start up.
> >> > +Previous configurations programmed into the hardware by the Xilinx
> >> > +tools or a bootloader will be overwritten.
> >> > +
> >> > +The settings for the console driver can be changed by the user
> >> > +application through the termios API afterwards.
> >> > +
> >> >  Debugging with xilinx_zynq_a9_qemu
> >> >  --
> >> >
> >> > --
> >> > 2.17.1
> >>
> >> ___
> >> devel mailing list
> >> devel@rtems.org
> >> http://lists.rtems.org/mailman/listinfo/devel
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: Flashdisk driver based on spidev

[Jan.Sommer]

Thanks for all the pointers Chris, I will do some more research and see if I 
get a better idea how to go about this.

Best regards,
Jan

> -Original Message-
> From: Chris Johns 
> Sent: Wednesday, March 10, 2021 7:28 PM
> To: Sommer, Jan ; devel@rtems.org
> Subject: Re: Flashdisk driver based on spidev
> 
> On 11/3/21 12:59 am, jan.som...@dlr.de wrote:
> > Hello,
> >
> > We will probably at some point need support for Micron-based NOR-flash
> devices to store data which are connected via SPI.
> > I found the flashdisk API in RTEMS and was wondering if I understand
> everything correctly.
> > My idea would be to have the layers like this:
> > spidev-driver <-- micron-flashdisk-driver <-- (libblock?) <--
> > jffs2-filesystem <-- POSIX file operations
> >
> > Another option would be to have the flashdisk-driver do the SPI
> transaction itself, but I am not sure if there is a lot performance to gain.
> > The bus setup will not change between consecutive read/write accesses to
> the memory (except for CS if multiple flash devices are present).
> > From my work with the spidev drivers, which are currently in review, the
> overhead didn't seem very big to me for these conditions considering that
> writes will always be in the kB range due to the sector size.
> > Using the spidev API would have the benefit that the same flashdisk driver
> can be used with different SPI devices.
> >
> > Are these assumptions reasonable or does someone have further
> suggestions to consider?
> >
> 
> I do not think the JFFS2 will sit on top of libblock. The flashdisk does block
> management and I am not sure you want that with JFFSv2,
> 
> I suggest a CFI based NOR flash chip driver that uses the QSPI driver. Then a
> file to glue it to JFFS2. The flash chip driver needs to provide:
> 
>  - open
>  - read   - hooked to JFFSv2
>  - write  - hooked to JFFSv2
>  - erase  - hooked to JFFSv2
>  - close  - hooked to JFFSv2 destroy
> 
> I would also considering supporting a base and size in the JFFS flash chip 
> glue.
> This lets you leave the bottom part of a boot QSPI flash to support a boot and
> factory image (anti-bricking) set of blocks. I have also used a top block to 
> hold
> factory settings in some Zynq devices.
> 
> Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH v2] user/bsps: Mention fixed console baud rate for zynq

[Jan.Sommer]

Could someone please have a look at this patch?

> -Original Message-
> From: Sommer, Jan
> Sent: Friday, March 5, 2021 7:04 PM
> To: devel@rtems.org
> Cc: Sommer, Jan 
> Subject: [PATCH v2] user/bsps: Mention fixed console baud rate for zynq
> 
> ---
>  user/bsps/arm/xilinx-zynq.rst | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/user/bsps/arm/xilinx-zynq.rst b/user/bsps/arm/xilinx-zynq.rst
> index 365c336..29f9cb0 100644
> --- a/user/bsps/arm/xilinx-zynq.rst
> +++ b/user/bsps/arm/xilinx-zynq.rst
> @@ -37,6 +37,18 @@ to return the peripheral clock. Normally this is half the
> CPU  clock. This function is declared ``weak`` so you can override the  
> default
> behaviour by providing it in your application.
> 
> +Console
> +---
> +
> +The console driver for the UARTs will always be initialized to a baud
> +rate of 115200 with 8 bit characters, 1 stop bit and no parity bits
> +during start up.
> +Previous configurations programmed into the hardware by the Xilinx
> +tools or a bootloader will be overwritten.
> +
> +The settings for the console driver can be changed by the user
> +application through the termios API afterwards.
> +
>  Debugging with xilinx_zynq_a9_qemu
>  --
> 
> --
> 2.17.1

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

RE: [PATCH v5 0/3] Add cadence-SPI driver

[Jan.Sommer]

Thanks. Pushed to master.

> -Original Message-
> From: Chris Johns 
> Sent: Wednesday, March 10, 2021 6:56 PM
> To: Sommer, Jan ; devel@rtems.org
> Subject: Re: [PATCH v5 0/3] Add cadence-SPI driver
> 
> OK to push from me.
> 
> On 9/3/21 10:22 pm, Jan Sommer wrote:
> > v5:
> > - Add some documentation
> > - Thanks for testing by Rick van der Wal
> > - Fix bug in CS logic
> > - Work-around too slow RXNEMPTY flag for some bus frequencies
> > - Created issue in trac: https://devel.rtems.org/ticket/4320
> >
> > v4:
> > - Use copyright information without UTF-8 characters
> >
> > v3:
> > - Fix wrong changes to spec/build/bsps/arm/xilinx-zynq/obj.yml
> >
> > v2:
> > - Moved source file to bsps/shared/dev/spi
> > - Moved include files to bsps/include/dev/spi
> > - Enabled build in aarch64 BSPs
> >
> > v1:
> >
> > This patchset implements a driver for the cadence-spi device of the Xilinx
> Zynq-7000 based SoCs  using the spidev API.
> >
> >
> > Jan Sommer (3):
> >   bsps/xilinx_zynq: Add SPI driver for cadence-spi
> >   bsps/xilinx_zynq: Add SPI driver to waf
> >   bsps/xilinx_zynq: Add SPI driver to autotools build
> >
> >  bsps/headers.am   |   5 +
> >  bsps/include/dev/spi/cadence-spi-regs.h   |  84 
> >  bsps/include/dev/spi/cadence-spi.h|  63 +++
> >  bsps/shared/dev/spi/cadence-spi.c | 444 ++
> >  c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am  |   3 +
> >  .../lib/libbsp/arm/xilinx-zynqmp/Makefile.am  |   3 +
> >  spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml |   2 +
> >  spec/build/bsps/arm/xilinx-zynq/grp.yml   |   2 +
> >  .../arm/xilinx-zynqmp/bspxilinxzynqmp.yml |   2 +
> >  spec/build/bsps/objdevspizynq.yml |  18 +
> >  10 files changed, 626 insertions(+)
> >  create mode 100644 bsps/include/dev/spi/cadence-spi-regs.h
> >  create mode 100644 bsps/include/dev/spi/cadence-spi.h
> >  create mode 100644 bsps/shared/dev/spi/cadence-spi.c  create mode
> > 100644 spec/build/bsps/objdevspizynq.yml
> >
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Flashdisk driver based on spidev

[Jan.Sommer]

Hello,

We will probably at some point need support for Micron-based NOR-flash devices 
to store data which are connected via SPI.
I found the flashdisk API in RTEMS and was wondering if I understand everything 
correctly.
My idea would be to have the layers like this:
spidev-driver <-- micron-flashdisk-driver <-- (libblock?) <-- jffs2-filesystem 
<-- POSIX file operations

Another option would be to have the flashdisk-driver do the SPI transaction 
itself, but I am not sure if there is a lot performance to gain.
The bus setup will not change between consecutive read/write accesses to the 
memory (except for CS if multiple flash devices are present).
>From my work with the spidev drivers, which are currently in review, the 
>overhead didn't seem very big to me for these conditions considering that 
>writes will always be in the kB range due to the sector size.
Using the spidev API would have the benefit that the same flashdisk driver can 
be used with different SPI devices.

Are these assumptions reasonable or does someone have further suggestions to 
consider?

Best regards,

Jan


Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR)
German Aerospace Center
Institute for Software Technology | Software for Space Systems and Interactive 
Visualization | Lilienthalplatz 7 | 38108 Braunschweig | Germany

Jan Sommer

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

RE: [5 PATCH 0/2] Backport fixes to zynq uart to RTEMS5

[Jan.Sommer]

> -Original Message-
> From: Chris Johns 
> Sent: Tuesday, March 9, 2021 3:20 AM
> To: Sommer, Jan ; devel@rtems.org
> Subject: Re: [5 PATCH 0/2] Backport fixes to zynq uart to RTEMS5
> 
> OK for 5.
> 

Thanks. Pushed to 5.

> On 6/3/21 5:58 am, Jan Sommer wrote:
> > This patchset backports the commits of Kinsey Moore and myself, which
> > fix the stdin behavior for the zynq-uart based console driver.
> > I checked the behavior on hardware with the termios.exe application.
> > Before, the scanf and similar functions do not wait for user input and
> > return immediately. With the patches the application behaves as expected.
> >
> > A corresponding ticket can be found here:
> > https://devel.rtems.org/ticket/4236
> >
> > Small side note:
> > I noticed that the ARM BSP docs for RTEMS5 list mostly TODO.
> > Should I create a patchset backporting the BSP documentation or do you
> > want to do that in one go as part of the 5.2 release preparation?
> >
> > Best regards,
> >
> > Jan
> >
> > Jan Sommer (1):
> >   bsps/shared: Allow setting baud rate for zynq uart
> >
> > Kinsey Moore (1):
> >   zynq-uart: Fix set_attributes implementation
> >
> >  bsps/arm/include/bsp/zynq-uart.h  |  7 +++
> >  bsps/arm/shared/serial/zynq-uart-polled.c |  2 +-
> >  bsps/arm/shared/serial/zynq-uart.c| 77 ---
> >  3 files changed, 75 insertions(+), 11 deletions(-)
> >
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH 0/2] Import ehci_pci

[Jan.Sommer]

> -Original Message-
> From: Sebastian Huber 
> Sent: Monday, March 8, 2021 4:42 PM
> To: Sommer, Jan ; Moyano Heredia, Victor Gabriel
> ; devel@rtems.org
> Subject: Re: [PATCH 0/2] Import ehci_pci
> 
> On 08/03/2021 16:38, jan.som...@dlr.de wrote:
> 
> > Could someone please approve this patchset (and ideally the similar ones
> for 6-freebsd-12 and 5-freebsd-12)?
> > They only import the files for the USB flash drive support from FreeBSD
> without any RTEMS related changes.
> The changes are fine.
> 

Thanks, pushed.

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

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

RE: [PATCH 0/2] Import ehci_pci

[Jan.Sommer]

Could someone please approve this patchset (and ideally the similar ones for 
6-freebsd-12 and 5-freebsd-12)?
They only import the files for the USB flash drive support from FreeBSD without 
any RTEMS related changes.

Best regards,

Jan


> -Original Message-
> From: devel  On Behalf Of
> gabriel.moy...@dlr.de
> Sent: Monday, February 22, 2021 12:44 PM
> To: devel@rtems.org
> Subject: AW: [PATCH 0/2] Import ehci_pci
> 
> Sorry, I have forgotten to mention that this patch is for the master
> 
> -Ursprüngliche Nachricht-
> Von: Moyano Heredia, Victor Gabriel
> Gesendet: Montag, 22. Februar 2021 11:53
> An: devel@rtems.org
> Cc: Moyano Heredia, Victor Gabriel 
> Betreff: [PATCH 0/2] Import ehci_pci
> 
> Import ehci_pci from freebsd-org using freebsd-to-rtems.py
> 
> Moyano, Gabriel (2):
>   ehci_pci: Import from freebsd-org
>   ehci_pci: Add to build system
> 
>  freebsd/sys/dev/usb/controller/ehci_pci.c | 593
> ++
>  freebsd/sys/dev/usb/usb_pci.h |  43 ++
>  libbsd.py |   2 +
>  3 files changed, 638 insertions(+)
>  create mode 100644 freebsd/sys/dev/usb/controller/ehci_pci.c
>  create mode 100644 freebsd/sys/dev/usb/usb_pci.h
> 
> --
> 2.17.1
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH v3 1/1] bsps/shared: Allow setting baud rate for zynq uart

[Jan.Sommer]

Thanks. Pushed to master.

> -Original Message-
> From: Gedare Bloom 
> Sent: Friday, March 5, 2021 6:48 PM
> To: Sommer, Jan 
> Cc: devel@rtems.org
> Subject: Re: [PATCH v3 1/1] bsps/shared: Allow setting baud rate for zynq
> uart
> 
> Looks good to me.
> 
> On Fri, Mar 5, 2021 at 10:42 AM Jan Sommer  wrote:
> >
> > ---
> >  bsps/shared/dev/serial/zynq-uart.c | 21 -
> >  1 file changed, 16 insertions(+), 5 deletions(-)
> >
> > diff --git a/bsps/shared/dev/serial/zynq-uart.c
> > b/bsps/shared/dev/serial/zynq-uart.c
> > index 8f17d3ca65..cd0d0e7584 100644
> > --- a/bsps/shared/dev/serial/zynq-uart.c
> > +++ b/bsps/shared/dev/serial/zynq-uart.c
> > @@ -144,14 +144,22 @@ static bool zynq_uart_set_attributes(  {
> >zynq_uart_context *ctx = (zynq_uart_context *) context;
> >volatile zynq_uart *regs = ctx->regs;
> > +  int32_t baud;
> >uint32_t brgr = 0;
> >uint32_t bauddiv = 0;
> >uint32_t mode = 0;
> >int rc;
> >
> > -  rc = zynq_cal_baud_rate(115200, , , regs->mode);
> > -  if (rc != 0)
> > -return rc;
> > +  /*
> > +   * Determine the baud rate
> > +   */
> > +  baud = rtems_termios_baud_to_number(term->c_ospeed);
> > +
> > +  if (baud > 0) {
> > +rc = zynq_cal_baud_rate(baud, , , regs->mode);
> > +if (rc != 0)
> > +  return rc;
> > +  }
> >
> >/*
> > * Configure the mode register
> > @@ -202,8 +210,11 @@ static bool zynq_uart_set_attributes(
> >
> >regs->control &= ~(ZYNQ_UART_CONTROL_RXEN |
> ZYNQ_UART_CONTROL_TXEN);
> >regs->mode = mode;
> > -  regs->baud_rate_gen = ZYNQ_UART_BAUD_RATE_GEN_CD(brgr);
> > -  regs->baud_rate_div = ZYNQ_UART_BAUD_RATE_DIV_BDIV(bauddiv);
> > +  /* Ignore baud rate of B0. There are no modem control lines to
> > + de-assert */  if (baud > 0) {
> > +regs->baud_rate_gen = ZYNQ_UART_BAUD_RATE_GEN_CD(brgr);
> > +regs->baud_rate_div = ZYNQ_UART_BAUD_RATE_DIV_BDIV(bauddiv);
> > +  }
> >regs->control |= ZYNQ_UART_CONTROL_RXEN |
> ZYNQ_UART_CONTROL_TXEN;
> >
> >return true;
> > --
> > 2.17.1
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH v3 0/1] Enable baud rate selection for zynq uart

[Jan.Sommer]

Thanks. To be honest, I wasn’t really sure what to do with B0 since there 
aren’t any modem control lines.
I just grepped for B0 and looked what other BSPs are doing and they do nothing, 
so I copied that to have at least common behavior among RTEMS.

From: Joel Sherrill 
Sent: Friday, March 5, 2021 6:54 PM
To: Sommer, Jan 
Cc: rtems-de...@rtems.org 
Subject: Re: [PATCH v3 0/1] Enable baud rate selection for zynq uart



On Fri, Mar 5, 2021 at 11:42 AM Jan Sommer 
mailto:jan.som...@dlr.de>> wrote:
v3:
- Make sure the baud registers are not modified for baud rate B0

B0 is an odd bird. It indicates hang up. From 
https://pubs.opengroup.org/onlinepubs/9699919799.2008edition/functions/tcsetattr.html:

If the output baud rate stored in the termios structure pointed to by termios_p 
is the zero baud rate, B0, the modem control lines shall no longer be asserted. 
Normally, this shall disconnect the line.

If the input baud rate stored in the termios structure pointed to by termios_p 
is 0, the input baud rate given to the hardware is the same as the output baud 
rate stored in the termios structure.

Since we don't likely have any BSPs which have real modem control
lines on the serial ports, that usually means to ignore it so you don't
end up with a divide by 0 on the baud rate divisor calculations.

I'm not saying anything negative about your patches. Just that B0 is
a weird corner of POSIX and computing history.

v2:
- Use rtems_baud_to_number instead of duplicating baud table

This patch allows to set the baud rate of the zynq-uart using the termios API.
I could change the baud rate successfully on hardware using the termios 
application.

Best regards,

Jan


Jan Sommer (1):
  bsps/shared: Allow setting baud rate for zynq uart

 bsps/shared/dev/serial/zynq-uart.c | 21 -
 1 file changed, 16 insertions(+), 5 deletions(-)

--
2.17.1

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

RE: [PATCH v4 0/3] Add cadence-SPI driver

[Jan.Sommer]

Thanks, I got some test feedback from Rick van der Wal.
I will prepare a new patch set with some modifications.

The zynq-uart issue is currently more pressing for me.

Best regards,

   Jan

> -Original Message-
> From: Gedare Bloom 
> Sent: Friday, March 5, 2021 4:41 PM
> To: Sommer, Jan 
> Cc: devel@rtems.org
> Subject: Re: [PATCH v4 0/3] Add cadence-SPI driver
> 
> Jan, I think this driver is fine to go in if you're happy with it.
> 
> On Fri, Feb 19, 2021 at 6:06 AM Jan Sommer  wrote:
> >
> > v4:
> > - Use copyright information without UTF-8 characters
> >
> > v3:
> > - Fix wrong changes to spec/build/bsps/arm/xilinx-zynq/obj.yml
> >
> > v2:
> > - Moved source file to bsps/shared/dev/spi
> > - Moved include files to bsps/include/dev/spi
> > - Enabled build in aarch64 BSPs
> >
> > v1:
> >
> > This patchset implements a driver for the cadence-spi device of the Xilinx
> Zynq-7000 based SoCs  using the spidev API.
> >
> >
> > Jan Sommer (3):
> >   bsps/xilinx_zynq: Add SPI driver for cadence-spi
> >   bsps/xilinx_zynq: Add SPI driver to waf
> >   bsps/xilinx_zynq: Add SPI driver to autotools build
> >
> >  bsps/headers.am   |   5 +
> >  bsps/include/dev/spi/cadence-spi-regs.h   |  84 
> >  bsps/include/dev/spi/cadence-spi.h|  48 ++
> >  bsps/shared/dev/spi/cadence-spi.c | 437 ++
> >  c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am  |   3 +
> >  .../lib/libbsp/arm/xilinx-zynqmp/Makefile.am  |   3 +
> >  spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml |   2 +
> >  spec/build/bsps/arm/xilinx-zynq/grp.yml   |   2 +
> >  .../arm/xilinx-zynqmp/bspxilinxzynqmp.yml |   2 +
> >  spec/build/bsps/objdevspizynq.yml |  18 +
> >  10 files changed, 604 insertions(+)
> >  create mode 100644 bsps/include/dev/spi/cadence-spi-regs.h
> >  create mode 100644 bsps/include/dev/spi/cadence-spi.h
> >  create mode 100644 bsps/shared/dev/spi/cadence-spi.c  create mode
> > 100644 spec/build/bsps/objdevspizynq.yml
> >
> > --
> > 2.17.1
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH v2 1/1] bsps/shared: Allow setting baud rate for zynq uart

[Jan.Sommer]

> -Original Message-
> From: Gedare Bloom 
> Sent: Friday, March 5, 2021 4:36 PM
> To: Sommer, Jan 
> Cc: devel@rtems.org
> Subject: Re: [PATCH v2 1/1] bsps/shared: Allow setting baud rate for zynq
> uart
> 
> On Mon, Feb 22, 2021 at 9:23 AM Jan Sommer  wrote:
> >
> > ---
> >  bsps/shared/dev/serial/zynq-uart.c | 14 +++---
> >  1 file changed, 11 insertions(+), 3 deletions(-)
> >
> > diff --git a/bsps/shared/dev/serial/zynq-uart.c
> > b/bsps/shared/dev/serial/zynq-uart.c
> > index 8f17d3ca65..dd5a6e1cb8 100644
> > --- a/bsps/shared/dev/serial/zynq-uart.c
> > +++ b/bsps/shared/dev/serial/zynq-uart.c
> > @@ -144,14 +144,22 @@ static bool zynq_uart_set_attributes(  {
> >zynq_uart_context *ctx = (zynq_uart_context *) context;
> >volatile zynq_uart *regs = ctx->regs;
> > +  int32_t baud;
> >uint32_t brgr = 0;
> >uint32_t bauddiv = 0;
> >uint32_t mode = 0;
> >int rc;
> >
> > -  rc = zynq_cal_baud_rate(115200, , , regs->mode);
> > -  if (rc != 0)
> > -return rc;
> > +  /*
> > +   * Determine the baud rate
> > +   */
> > +  baud = rtems_termios_baud_to_number(term->c_ospeed);
> > +
> > +  if (baud > 0) {
> > +rc = zynq_cal_baud_rate(baud, , , regs->mode);
> > +if (rc != 0)
> > +  return rc;
> > +  }
> What happens if baud == 0?
> 

Ah, you are right. My initial goal was to leave it unchanged (because there are 
no modem control lines to deassert), but forgot that the baud rate registers 
are set below with then 0. That is not what it should be.
I will prepare a new patch with a condition.

Thanks.

> >
> >/*
> > * Configure the mode register
> > --
> > 2.17.1
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH v2 1/1] bsps/shared: Allow setting baud rate for zynq uart

[Jan.Sommer]

Could someone please have a look a this patch and approve it?
Should I then still add a new section to the docs regarding the console 
behavior for the zynq?
With this patch applied it would be that the baud rate of the fsbl is 
overwritten by default to 115200, but can be changed using the termios API 
(compared to the currently unchangeable baud rate).
I am not sure if that information is that useful or if people will figure that 
out in 2 min anyways.

Best regards,

Jan

> -Original Message-
> From: Sommer, Jan
> Sent: Monday, February 22, 2021 5:23 PM
> To: devel@rtems.org
> Cc: Sommer, Jan 
> Subject: [PATCH v2 1/1] bsps/shared: Allow setting baud rate for zynq uart
> 
> ---
>  bsps/shared/dev/serial/zynq-uart.c | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/bsps/shared/dev/serial/zynq-uart.c
> b/bsps/shared/dev/serial/zynq-uart.c
> index 8f17d3ca65..dd5a6e1cb8 100644
> --- a/bsps/shared/dev/serial/zynq-uart.c
> +++ b/bsps/shared/dev/serial/zynq-uart.c
> @@ -144,14 +144,22 @@ static bool zynq_uart_set_attributes(  {
>zynq_uart_context *ctx = (zynq_uart_context *) context;
>volatile zynq_uart *regs = ctx->regs;
> +  int32_t baud;
>uint32_t brgr = 0;
>uint32_t bauddiv = 0;
>uint32_t mode = 0;
>int rc;
> 
> -  rc = zynq_cal_baud_rate(115200, , , regs->mode);
> -  if (rc != 0)
> -return rc;
> +  /*
> +   * Determine the baud rate
> +   */
> +  baud = rtems_termios_baud_to_number(term->c_ospeed);
> +
> +  if (baud > 0) {
> +rc = zynq_cal_baud_rate(baud, , , regs->mode);
> +if (rc != 0)
> +  return rc;
> +  }
> 
>/*
> * Configure the mode register
> --
> 2.17.1

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

RE: [PATCH] MAINTAINERS: Add myself to write after approval

[Jan.Sommer]

Thanks. Pushed successfully.

Best regards,

Jan

> -Original Message-
> From: Chris Johns 
> Sent: Thursday, March 4, 2021 8:35 AM
> To: Sommer, Jan ; devel@rtems.org
> Subject: Re: [PATCH] MAINTAINERS: Add myself to write after approval
> 
> Approved.
> 
> Welcome and congratulations on your commit access.
> 
> Chris
> 
> On 4/3/21 6:32 pm, jan.som...@dlr.de wrote:
> > Could someone approve this patch, please?
> >
> > Best regards,
> >
> > Jan
> >
> >> -Original Message-
> >> From: Sommer, Jan
> >> Sent: Thursday, February 25, 2021 2:05 PM
> >> To: devel@rtems.org
> >> Cc: Sommer, Jan 
> >> Subject: [PATCH] MAINTAINERS: Add myself to write after approval
> >>
> >> ---
> >>  MAINTAINERS | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git a/MAINTAINERS b/MAINTAINERS index 29e22357a5..6c9b70bc40
> >> 100644
> >> --- a/MAINTAINERS
> >> +++ b/MAINTAINERS
> >> @@ -53,6 +53,7 @@ Christian Mauderer
> >> christian.maude...@embedded-brains.de
> >>  Hesham Almataryheshamelmat...@gmail.com
> >>  Amaan Cheval   am...@rtems.org
> >>  Vijay Kumar Banerjee   vi...@rtems.org
> >> +Jan Sommer j...@rtems.org
> >>
> >>  Localized Write Permission
> >>  ==
> >> --
> >> 2.17.1
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> >
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH] MAINTAINERS: Add myself to write after approval

[Jan.Sommer]

Could someone approve this patch, please?

Best regards,

Jan

> -Original Message-
> From: Sommer, Jan
> Sent: Thursday, February 25, 2021 2:05 PM
> To: devel@rtems.org
> Cc: Sommer, Jan 
> Subject: [PATCH] MAINTAINERS: Add myself to write after approval
> 
> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 29e22357a5..6c9b70bc40 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -53,6 +53,7 @@ Christian Mauderer
> christian.maude...@embedded-brains.de
>  Hesham Almataryheshamelmat...@gmail.com
>  Amaan Cheval   am...@rtems.org
>  Vijay Kumar Banerjee   vi...@rtems.org
> +Jan Sommer j...@rtems.org
> 
>  Localized Write Permission
>  ==
> --
> 2.17.1

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

RE: [PATCH v1 1/1] bsps/shared: Allow setting baud rate for zynq uart

[Jan.Sommer]

> -Original Message-
> From: Sebastian Huber 
> Sent: Monday, February 22, 2021 4:58 PM
> To: Sommer, Jan ; devel@rtems.org
> Subject: Re: [PATCH v1 1/1] bsps/shared: Allow setting baud rate for zynq
> uart
> 
> 
> On 22/02/2021 16:43, Jan Sommer wrote:
> > +  /*
> > +   * Determine the baud rate
> > +   */
> > +  switch (term->c_ospeed) {
> > +case B0:  baud = 0;  break;
> > +case B50: baud = 50; break
> I am pretty sure we already have a function for this.
> 

Ah, you are right. I looked in other serial drivers and copied the table from 
there, but now found the rtems_termios_baud_to_index function.
I will use this one then.

Thanks.

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

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

RE: [PATCH rtems-docs] user/bsps: Mention fixed console baud rate for zynq

[Jan.Sommer]

> -Original Message-
> From: Chris Johns 
> Sent: Saturday, February 20, 2021 11:57 PM
> To: Gedare Bloom ; Sommer, Jan
> 
> Cc: devel@rtems.org
> Subject: Re: [PATCH rtems-docs] user/bsps: Mention fixed console baud rate
> for zynq
> 
> On 20/2/21 3:59 am, Gedare Bloom wrote:
> > On Fri, Feb 19, 2021 at 1:21 AM Jan Sommer  wrote:
> >>
> >> ---
> >>  user/bsps/arm/xilinx-zynq.rst | 14 ++
> >>  1 file changed, 14 insertions(+)
> >>
> >> diff --git a/user/bsps/arm/xilinx-zynq.rst
> >> b/user/bsps/arm/xilinx-zynq.rst index 365c336..dcc0649 100644
> >> --- a/user/bsps/arm/xilinx-zynq.rst
> >> +++ b/user/bsps/arm/xilinx-zynq.rst
> >> @@ -37,6 +37,20 @@ to return the peripheral clock. Normally this is
> >> half the CPU  clock. This function is declared ``weak`` so you can
> >> override the  default behaviour by providing it in your application.
> >>
> >> +Console
> >> +---
> >> +
> >> +The console driver for the UARTs will always be set to a baud rate
> >> +of 115200 with 8 bit characters, 1 stop bit and no parity bits
> >> +during start up.
> >> +Previous configurations programmed into the hardware by the Xilinx
> >> +tools or a bootloader will be overwritten.
> >> +
> >> +The settings for parity and stop bits can be changes by the user
> >> +application. The baud rate is hard coded to 115200 and can not be
> >> +changed.
> >> +
> >> +
> > Only 1 blank line here please. Chris to approve the content, I think
> > he has the most to say on this topic :)
> 
> It is OK for master because it is what we have. Joel and I have been
> discussing the issue of the hardcoded baudrate and the issues it presents. If
> we decide something needs to change this documentation can change.
> 
> The issue is there are 2 UARTs on the zync and if one is used for the console
> the fixed rate is fine however if one is used for another purpose not being
> able to set the baudrate is a bug in RTEMS.
> 

That actually is a use case for us.
I have taken a closer look at the source and I don't see any reason why the 
baud rate should hard coded.
It looks like it is only missing the switch-case for the termios Baud options.
I will prepare a patch.

Best regards,

Jan

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

RE: [PATCH 1/1] zynq-uart: Fix set_attributes implementation

[Jan.Sommer]

> -Original Message-
> From: Chris Johns 
> Sent: Wednesday, February 10, 2021 12:08 AM
> To: Sommer, Jan ; devel@rtems.org
> Subject: Re: [PATCH 1/1] zynq-uart: Fix set_attributes implementation
> 
> On 9/2/21 11:42 pm, Jan Sommer wrote:
> > From: Kinsey Moore 
> >
> > The zynq-uart set_attributes implementation was configured to always
> > return false which causes spconsole01 to fail. This restores the
> > disabled implementation which sets the baud rate registers
> > appropriately and allows spconsole01 to pass. This also expands the
> > set_attributes functionality to allow setting of the stop bits,
> > character width, and parity.
> 
> Hmmm I missed this change.
> 
> Sebastian changed the Zynq driver to return an error. Returning an error is
> correct because the attributes are not being set however we have a couple
> of design approaches clashing.
> 
> The issue pulls right back to the Xilinx SystemZ design dialogue box. The
> hardware designer has the ability to set the serial port defaults. These
> settings form part of the ps7init data the FSBL paints into the hardware very
> early in the boot process. Also in this data are parallel port pin settings, 
> AXI
> clocks, memory and more so lots of important stuff. The Xilinx bootloader
> and ones I have created (I do not know about uboot) do not touch the UART
> hardware on purpose so the system designer has control. Then in 2017
> Sebastian pushed a change to force the baudrate to a BSP specific default.
> 
> This is normally all OK because all Zynq designs I know of use the default of
> 115200,8,n,1 for the configuration. A problem arises when these defaults are
> varied.
> 
> Maybe something explaining this in the user manual ...
> 
> https://docs.rtems.org/branches/master/user/bsps/bsps-arm.html#xilinx-
> zynq
> 
> so we have provided information on what to change?
> 

Do I understand it correctly, that a patch adding something like the following 
would be sufficient?

Console
---

The console driver for the UARTs of the Zynq SoC will be initialized to a baud 
rate
of 115200 with 8 bit characters, 1 stop bit and no parity bits.
Previous configurations from, e.g., a bootloader will be overwritten.
If a different setting is required, the user application can configure the 
console device
through the standard termios API, e.g. in the init task.

Best regards,

Jan


> The other approach is not to touch the defaults in hardware and allow a get
> attributes to discover them? Does termios drivers have a low level get? I can
> see a set but no get in the zynq uart driver.
> 
> Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH v3 1/3] bsps/xilinx_zynq: Add SPI driver for cadence-spi

[Jan.Sommer]

> -Original Message-
> From: devel  On Behalf Of Chris Johns
> Sent: Tuesday, February 16, 2021 10:53 PM
> To: Gedare Bloom ; Peter Dufault 
> Cc: devel@rtems.org
> Subject: Re: [PATCH v3 1/3] bsps/xilinx_zynq: Add SPI driver for cadence-spi
> 
[...]
> > We haven't really made anything official policy, but I think the rule
> > is to avoid unicode unless there is a good reason for it.
> 
> We do not have a policy and I think we should.
> 
> I looked back and found the only discussion was about the sources for
> documentation:
> 
> https://lists.rtems.org/pipermail/devel/2019-February/052742.html
> 
> After that there is not a lot.
> 
> The doco thread prompted me to check patch 1/3 in this series and saved the
> email. The text in it was a large long box of ascii encoding of some form. I
> applied the patch using git as test and git is fine with this which is neat 
> and
> the unicode characters appeared in the git log as:
> 
> +/*
> + * Copyright (C) 2020 Jan Sommer, Deutsches Zentrum fr Luft-
> +und
> Raumfahrt e. V. (DLR)
> + *
> 
> Less and vi both has similar things ...
> 
>  * Copyright (C) 2020 Jan Sommer, Deutsches Zentrum f\xc3\xbcr Luft- und
> Raumfahrt e. V. (DLR)
> 

That's strange. 
I also do my development in terminal. Less, cat and other CLI tools show the 
characters fine.


> The issue for terminal level work discussed in the doco source is present but
> in terms of formal names I am fine with there being unicode characters. I
> think having a formal name written in its proper form is what we should
> allow. The use of unicode in comments or code is different and here we
> need to accept the low common denominator which looks like me on a text
> terminal.
> 

Sounds reasonable to me.

Best regards,

Jan

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

RE: [PATCH v3 1/3] bsps/xilinx_zynq: Add SPI driver for cadence-spi

[Jan.Sommer]

> -Original Message-
> From: dufa...@hda.com 
> Sent: Tuesday, February 16, 2021 2:05 PM
> To: Sommer, Jan 
> Cc: j...@rtems.org; devel@rtems.org
> Subject: Re: [PATCH v3 1/3] bsps/xilinx_zynq: Add SPI driver for cadence-spi
> 
> You could use "fuer" to replace "für" as was done in the olden days.  Or do
> you need permission for that as well?
> 

The umlaut is part of the official brand.
That can be tricky, depending on the corporate policy.

> I find it odd to avoid Unicode and not allow umlauts in 2021.
> 

Yes. Luckily my parents gave me an ASCII-compatible name.
Saves a lot of trouble  :-)

Best regards,

Jan

> > On Feb 16, 2021, at 05:21 , jan.som...@dlr.de wrote:
> >
> > Ok, I asked if it is ok to use the English name for our organization as 
> > well.
> >
> > The answer might take some time, though.
> >
> >
> >
> > Best regards,
> >
> >
> >
> > Jan
> >
> >
> >
> > From: Joel Sherrill 
> > Sent: Monday, February 15, 2021 9:41 PM
> > To: Peter Dufault 
> > Cc: Sommer, Jan ; rtems-de...@rtems.org
> > 
> > Subject: Re: [PATCH v3 1/3] bsps/xilinx_zynq: Add SPI driver for
> > cadence-spi
> >
> >
> >
> > Christian submitted a series of patches to eliminate unicode. I'd
> > prefer if we avoided it
> >
> >
> >
> > On Mon, Feb 15, 2021, 8:20 AM Peter Dufault  wrote:
> >
> > An international project should allow UTF in source code.  You might need
> to hunt what setting you need (for gnome-terminal "export
> LANG=en_US.UTF-8" works for me in the US).  I'm surprised if anyone is
> working on a system that can't at least display UTF-8.
> >
> > > On Feb 15, 2021, at 03:21 , jan.som...@dlr.de wrote:
> > >
> > > Hi Chris,
> > >
> > >> -Original Message-
> > >> From: Chris Johns 
> > >> Sent: Sunday, February 14, 2021 10:20 PM
> > >> To: Sommer, Jan ; devel@rtems.org
> > >> Subject: Re: [PATCH v3 1/3] bsps/xilinx_zynq: Add SPI driver for
> > >> cadence-spi
> > >>
> > >> Hi Jan,
> > >>
> > >> Thank you for the changes. I have one question inlined below ...
> > >>
> > >> On 14/2/21 10:30 pm, Jan Sommer wrote:
> > >>> ---
> > >>> bsps/include/dev/spi/cadence-spi-regs.h |  84 +
> > >>> bsps/include/dev/spi/cadence-spi.h  |  48 +++
> > >>> bsps/shared/dev/spi/cadence-spi.c   | 437
> > >> 
> > >>> 3 files changed, 569 insertions(+) create mode 100644
> > >>> bsps/include/dev/spi/cadence-spi-regs.h
> > >>> create mode 100644 bsps/include/dev/spi/cadence-spi.h
> > >>> create mode 100644 bsps/shared/dev/spi/cadence-spi.c
> > >>>
> > >>> diff --git a/bsps/include/dev/spi/cadence-spi-regs.h
> > >>> b/bsps/include/dev/spi/cadence-spi-regs.h
> > >>> new file mode 100644
> > >>> index 00..2851c88df1
> > >>> --- /dev/null
> > >>> +++ b/bsps/include/dev/spi/cadence-spi-regs.h
> > >>> @@ -0,0 +1,84 @@
> > >>> +/* SPDX-License-Identifier: BSD-2-Clause */
> > >>> +
> > >>> +/*
> > >>> + * Copyright (C) 2020 Jan Sommer, Deutsches Zentrum für Luft- und
> > >> Raumfahrt e. V.
> > >>
> > >> Is there a unicode character in this line? I cannot see anything in
> > >> our coding standard about unicode characters in source and I am not
> > >> sure what the actual policy is. I seem to remember some have been
> > >> removed in the past. I thought I would ask on the list now before we
> push these changes.
> > >>
> > >
> > > There is an u-Umlaut in it. That is probably it. As it is part of the 
> > > name, it's
> hard to get rid of.
> > > I could probably use the English name (German Aerospace Center) which
> has no special characters.
> > > Would that be preferred?
> > >
> > > Best regards,
> > >
> > >Jan
> > >
> > >> Chris
> > > ___
> > > devel mailing list
> > > devel@rtems.org
> > > http://lists.rtems.org/mailman/listinfo/devel
> >
> > Peter
> > -
> > Peter Dufault
> > HD Associates, Inc.  Software and System Engineering
> >
> > This email is delivered through the public internet using protocols subject
> to interception and tampering.
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> >
> 
> Peter
> -
> Peter Dufault
> HD Associates, Inc.  Software and System Engineering
> 
> This email is delivered through the public internet using protocols subject to
> interception and tampering.

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

RE: [PATCH v3 1/3] bsps/xilinx_zynq: Add SPI driver for cadence-spi

[Jan.Sommer]

Ok, I asked if it is ok to use the English name for our organization as well.
The answer might take some time, though.

Best regards,

Jan

From: Joel Sherrill 
Sent: Monday, February 15, 2021 9:41 PM
To: Peter Dufault 
Cc: Sommer, Jan ; rtems-de...@rtems.org 
Subject: Re: [PATCH v3 1/3] bsps/xilinx_zynq: Add SPI driver for cadence-spi

Christian submitted a series of patches to eliminate unicode. I'd prefer if we 
avoided it

On Mon, Feb 15, 2021, 8:20 AM Peter Dufault 
mailto:dufa...@hda.com>> wrote:
An international project should allow UTF in source code.  You might need to 
hunt what setting you need (for gnome-terminal "export LANG=en_US.UTF-8" works 
for me in the US).  I'm surprised if anyone is working on a system that can't 
at least display UTF-8.

> On Feb 15, 2021, at 03:21 , jan.som...@dlr.de wrote:
>
> Hi Chris,
>
>> -Original Message-
>> From: Chris Johns mailto:chr...@rtems.org>>
>> Sent: Sunday, February 14, 2021 10:20 PM
>> To: Sommer, Jan mailto:jan.som...@dlr.de>>; 
>> devel@rtems.org
>> Subject: Re: [PATCH v3 1/3] bsps/xilinx_zynq: Add SPI driver for cadence-spi
>>
>> Hi Jan,
>>
>> Thank you for the changes. I have one question inlined below ...
>>
>> On 14/2/21 10:30 pm, Jan Sommer wrote:
>>> ---
>>> bsps/include/dev/spi/cadence-spi-regs.h |  84 +
>>> bsps/include/dev/spi/cadence-spi.h  |  48 +++
>>> bsps/shared/dev/spi/cadence-spi.c   | 437
>> 
>>> 3 files changed, 569 insertions(+)
>>> create mode 100644 bsps/include/dev/spi/cadence-spi-regs.h
>>> create mode 100644 bsps/include/dev/spi/cadence-spi.h
>>> create mode 100644 bsps/shared/dev/spi/cadence-spi.c
>>>
>>> diff --git a/bsps/include/dev/spi/cadence-spi-regs.h
>>> b/bsps/include/dev/spi/cadence-spi-regs.h
>>> new file mode 100644
>>> index 00..2851c88df1
>>> --- /dev/null
>>> +++ b/bsps/include/dev/spi/cadence-spi-regs.h
>>> @@ -0,0 +1,84 @@
>>> +/* SPDX-License-Identifier: BSD-2-Clause */
>>> +
>>> +/*
>>> + * Copyright (C) 2020 Jan Sommer, Deutsches Zentrum für Luft- und
>> Raumfahrt e. V.
>>
>> Is there a unicode character in this line? I cannot see anything in our 
>> coding
>> standard about unicode characters in source and I am not sure what the
>> actual policy is. I seem to remember some have been removed in the past. I
>> thought I would ask on the list now before we push these changes.
>>
>
> There is an u-Umlaut in it. That is probably it. As it is part of the name, 
> it's hard to get rid of.
> I could probably use the English name (German Aerospace Center) which has no 
> special characters.
> Would that be preferred?
>
> Best regards,
>
>Jan
>
>> Chris
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

Peter
-
Peter Dufault
HD Associates, Inc.  Software and System Engineering

This email is delivered through the public internet using protocols subject to 
interception and tampering.

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

RE: [PATCH 0/1] misc: tools: fix mkimage.py script type processing

[Jan.Sommer]

> -Original Message-
> From: Chris Johns 
> Sent: Tuesday, February 16, 2021 6:27 AM
> To: Sommer, Jan ; devel@rtems.org
> Subject: Re: [PATCH 0/1] misc: tools: fix mkimage.py script type processing
> 
> On 12/2/21 3:23 am, Jan Sommer wrote:
> > Here is the patch from Andre also in git send-email format.
> 
> Thanks. Pushed.
> 

Thanks.

> > It would be great if we could integrate it in master and the 5 braches.
> 
> I have created a ticket and pushed the change to the 5 branch. It would be a
> help if a ticket and tested 5 patch is also created. :)
> 

Sorry, this patch was a bit spontaneous and I missed that here.

Best regards,

Jan

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

RE: [PATCH v3 1/3] bsps/xilinx_zynq: Add SPI driver for cadence-spi

[Jan.Sommer]

Hi Chris,

> -Original Message-
> From: Chris Johns 
> Sent: Sunday, February 14, 2021 10:20 PM
> To: Sommer, Jan ; devel@rtems.org
> Subject: Re: [PATCH v3 1/3] bsps/xilinx_zynq: Add SPI driver for cadence-spi
> 
> Hi Jan,
> 
> Thank you for the changes. I have one question inlined below ...
> 
> On 14/2/21 10:30 pm, Jan Sommer wrote:
> > ---
> >  bsps/include/dev/spi/cadence-spi-regs.h |  84 +
> >  bsps/include/dev/spi/cadence-spi.h  |  48 +++
> >  bsps/shared/dev/spi/cadence-spi.c   | 437
> 
> >  3 files changed, 569 insertions(+)
> >  create mode 100644 bsps/include/dev/spi/cadence-spi-regs.h
> >  create mode 100644 bsps/include/dev/spi/cadence-spi.h
> >  create mode 100644 bsps/shared/dev/spi/cadence-spi.c
> >
> > diff --git a/bsps/include/dev/spi/cadence-spi-regs.h
> > b/bsps/include/dev/spi/cadence-spi-regs.h
> > new file mode 100644
> > index 00..2851c88df1
> > --- /dev/null
> > +++ b/bsps/include/dev/spi/cadence-spi-regs.h
> > @@ -0,0 +1,84 @@
> > +/* SPDX-License-Identifier: BSD-2-Clause */
> > +
> > +/*
> > + * Copyright (C) 2020 Jan Sommer, Deutsches Zentrum für Luft- und
> Raumfahrt e. V.
> 
> Is there a unicode character in this line? I cannot see anything in our coding
> standard about unicode characters in source and I am not sure what the
> actual policy is. I seem to remember some have been removed in the past. I
> thought I would ask on the list now before we push these changes.
> 

There is an u-Umlaut in it. That is probably it. As it is part of the name, 
it's hard to get rid of.
I could probably use the English name (German Aerospace Center) which has no 
special characters.
Would that be preferred?

Best regards,

Jan

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

RE: [PATCH v2 2/3] bsps/xilinx_zynq: Add SPI driver to waf

[Jan.Sommer]

Yes, my bad.
When changing that compared to version 1 of the patch, I wanted to remove the 
references to cadence-spi, but instead removed the ones to cadence-i2c :-/

I will send in a new patchset.

Best regards,

   Jan

> -Original Message-
> From: Kinsey Moore 
> Sent: Saturday, February 13, 2021 6:16 PM
> To: Sommer, Jan ; devel@rtems.org
> Subject: RE: [PATCH v2 2/3] bsps/xilinx_zynq: Add SPI driver to waf
> 
> The header locations in spec/build/bsps/arm/xilinx-zynq/obj.yml don't look
> correct due to the relocation and should probably be removed entirely since
> they're now broken out into spec/build/bsps/objdevspizynq.yml, instead.
> 
> Kinsey
> 
> -Original Message-
> From: devel  On Behalf Of Jan Sommer
> Sent: Saturday, February 13, 2021 08:19
> To: devel@rtems.org
> Subject: [PATCH v2 2/3] bsps/xilinx_zynq: Add SPI driver to waf
> 
> ---
>  spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml  |  2 ++
>  spec/build/bsps/arm/xilinx-zynq/grp.yml|  2 ++
>  spec/build/bsps/arm/xilinx-zynq/obj.yml|  4 ++--
>  .../bsps/arm/xilinx-zynqmp/bspxilinxzynqmp.yml |  2 ++
>  spec/build/bsps/objdevspizynq.yml  | 18 ++
>  5 files changed, 26 insertions(+), 2 deletions(-)  create mode 100644
> spec/build/bsps/objdevspizynq.yml
> 
> diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml
> b/spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml
> index 552723c61c..c952b4f59e 100644
> --- a/spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml
> +++ b/spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml
> @@ -33,6 +33,8 @@ links:
>uid: ../../objirq
>  - role: build-dependency
>uid: ../../objdevserialzynq
> +- role: build-dependency
> +  uid: ../../objdevspizynq
>  - role: build-dependency
>uid: ../../optcachedata
>  - role: build-dependency
> diff --git a/spec/build/bsps/arm/xilinx-zynq/grp.yml
> b/spec/build/bsps/arm/xilinx-zynq/grp.yml
> index 74adbd7fa7..0bbee1922c 100644
> --- a/spec/build/bsps/arm/xilinx-zynq/grp.yml
> +++ b/spec/build/bsps/arm/xilinx-zynq/grp.yml
> @@ -57,6 +57,8 @@ links:
>uid: ../../objirq
>  - role: build-dependency
>uid: ../../objdevserialzynq
> +- role: build-dependency
> +  uid: ../../objdevspizynq
>  - role: build-dependency
>uid: linkcmds
>  - role: build-dependency
> diff --git a/spec/build/bsps/arm/xilinx-zynq/obj.yml
> b/spec/build/bsps/arm/xilinx-zynq/obj.yml
> index 6602b20a03..8b7e65ed40 100644
> --- a/spec/build/bsps/arm/xilinx-zynq/obj.yml
> +++ b/spec/build/bsps/arm/xilinx-zynq/obj.yml
> @@ -14,9 +14,9 @@ install:
>- bsps/arm/xilinx-zynq/include/tm27.h
>  - destination: ${BSP_INCLUDEDIR}/bsp
>source:
> -  - bsps/arm/xilinx-zynq/include/bsp/cadence-i2c-regs.h
> -  - bsps/arm/xilinx-zynq/include/bsp/cadence-i2c.h
>- bsps/arm/xilinx-zynq/include/bsp/i2c.h
> +  - bsps/arm/xilinx-zynq/include/bsp/cadence-spi.h
> +  - bsps/arm/xilinx-zynq/include/bsp/cadence-spi-regs.h
>- bsps/arm/xilinx-zynq/include/bsp/irq.h
>  links: []
>  source:
> diff --git a/spec/build/bsps/arm/xilinx-zynqmp/bspxilinxzynqmp.yml
> b/spec/build/bsps/arm/xilinx-zynqmp/bspxilinxzynqmp.yml
> index 51d3268e99..d4e8cbc1ce 100644
> --- a/spec/build/bsps/arm/xilinx-zynqmp/bspxilinxzynqmp.yml
> +++ b/spec/build/bsps/arm/xilinx-zynqmp/bspxilinxzynqmp.yml
> @@ -69,6 +69,8 @@ links:
>uid: ../../objirq
>  - role: build-dependency
>uid: ../../objdevserialzynq
> +- role: build-dependency
> +  uid: ../../objdevspizynq
>  - role: build-dependency
>uid: ../../opto2
>  - role: build-dependency
> diff --git a/spec/build/bsps/objdevspizynq.yml
> b/spec/build/bsps/objdevspizynq.yml
> new file mode 100644
> index 00..b778e756e1
> --- /dev/null
> +++ b/spec/build/bsps/objdevspizynq.yml
> @@ -0,0 +1,18 @@
> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> +build-type: objects
> +cflags: []
> +copyrights:
> +- Copyright (C) 2021 German Aerospace Center (DLR)
> +cppflags: []
> +cxxflags: []
> +enabled-by: true
> +includes: []
> +install:
> +- destination: ${BSP_INCLUDEDIR}/dev/spi
> +  source:
> +  - bsps/include/dev/spi/cadence-spi-regs.h
> +  - bsps/include/dev/spi/cadence-spi.h
> +links: []
> +source:
> +- bsps/shared/dev/spi/cadence-spi.c
> +type: build
> --
> 2.17.1
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH v2] bsps/shared: Build fsl-edma only for certain BSP

[Jan.Sommer]

Thank you. The pipeline works again.

Have a nice week-end,

Jan

> -Original Message-
> From: devel  On Behalf Of Christian MAUDERER
> Sent: Friday, January 22, 2021 3:52 PM
> To: Sebastian Huber ; RTEMS
> 
> Subject: Re: [PATCH v2] bsps/shared: Build fsl-edma only for certain BSP
> 
> Am 22.01.21 um 15:48 schrieb Sebastian Huber:
> > On 22/01/2021 15:44, Christian Mauderer wrote:
> >
> >> Move the Freescale EDMA driver to it's own object and build it only
> >> for the BSP that is currently using it.
> > Looks good.
> >
> 
> Thanks. I pushed it.
> 
> --
> 
> 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/
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Build failure with current master

[Jan.Sommer]

Hello,

Our nightly build of the current master of some ARM BSPs failed today (e.g. 
raspberrypi, zedboard).
It seems to be related to commit a434cc80cb00e: bsps/shared: Adapt fsl-edma 
driver for imxrt

The error I get is:
[  60/4060] Compiling bsps/shared/dev/dma/fsl-edma.c
[  62/4060] Compiling bsps/shared/dev/display/disp_hcms29xx.c
../../../bsps/shared/dev/dma/fsl-edma.c:65:35: error: 'EDMA' undeclared here 
(not in a function)
   65 | (volatile struct fsl_edma *) ,
  |   ^~~~
../../../bsps/shared/dev/dma/fsl-edma.c: In function 'fsl_edma_init':
../../../bsps/shared/dev/dma/fsl-edma.c:265:4: error: #error "Unknown chip"
  265 |   #error "Unknown chip"
  |^
../../../bsps/shared/dev/dma/fsl-edma.c: In function 
'fsl_edma_install_obtained_channel':
../../../bsps/shared/dev/dma/fsl-edma.c:362:4: error: #error "Unknown chip"
  362 |   #error "Unknown chip"
  |^
../../../bsps/shared/dev/dma/fsl-edma.c:341:12: warning: unused variable 
'channel_index' [-Wunused-variable]
  341 |   unsigned channel_index = fsl_edma_channel_index_of_tcd(ctx->edma_tcd);
  |^
../../../bsps/shared/dev/dma/fsl-edma.c: In function 'fsl_edma_release_channel':
../../../bsps/shared/dev/dma/fsl-edma.c:422:4: error: #error "Unknown chip"
  422 |   #error "Unknown chip"
  |^
../../../bsps/shared/dev/dma/fsl-edma.c:424:5: warning: passing argument 1 of 
'rtems_interrupt_handler_remove' makes integer from pointer without a cast 
[-Wint-conversion]
  424 | fsl_edma_interrupt_handler,
  | ^~
  | |
  | void (*)(void *)
In file included from ../../../bsps/arm/xilinx-zynq/include/bsp/irq.h:40,
 from ../../../bsps/shared/dev/dma/fsl-edma.c:41:
../../../cpukit/include/rtems/irq-extension.h:159:23: note: expected 
'rtems_vector_number' {aka 'unsigned int'} but argument is of type 'void 
(*)(void *)'
  159 |   rtems_vector_number vector,
  |   ^~
../../../bsps/shared/dev/dma/fsl-edma.c:425:5: warning: passing argument 2 of 
'rtems_interrupt_handler_remove' from incompatible pointer type 
[-Wincompatible-pointer-types]
  425 | ctx
  | ^~~
  | |
  | fsl_edma_channel_context *
In file included from ../../../bsps/arm/xilinx-zynq/include/bsp/irq.h:40,
 from ../../../bsps/shared/dev/dma/fsl-edma.c:41:
../../../cpukit/include/rtems/irq-extension.h:160:27: note: expected 
'rtems_interrupt_handler' {aka 'void (*)(void *)'} but argument is of type 
'fsl_edma_channel_context *'
  160 |   rtems_interrupt_handler handler,
  |   ^~~
../../../bsps/shared/dev/dma/fsl-edma.c:416:8: error: too few arguments to 
function 'rtems_interrupt_handler_remove'
  416 |   sc = rtems_interrupt_handler_remove(
  |^~
In file included from ../../../bsps/arm/xilinx-zynq/include/bsp/irq.h:40,
 from ../../../bsps/shared/dev/dma/fsl-edma.c:41:
../../../cpukit/include/rtems/irq-extension.h:158:19: note: declared here
  158 | rtems_status_code rtems_interrupt_handler_remove(
  |   ^~
../../../bsps/shared/dev/dma/fsl-edma.c:411:12: warning: unused variable 
'channel_index' [-Wunused-variable]
  411 |   unsigned channel_index = fsl_edma_channel_index_of_tcd(ctx->edma_tcd);
  |^
At top level:
../../../bsps/shared/dev/dma/fsl-edma.c:151:13: warning: 
'edma_interrupt_error_handler' defined but not used [-Wunused-function]
  151 | static void edma_interrupt_error_handler(void *arg)
  | ^~~~

We should have the most recent build tools installed.

Best regards,

Jan


Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR)
German Aerospace Center
Institute for Software Technology | Software for Space Systems and Interactive 
Visualization | Lilienthalplatz 7 | 38108 Braunschweig | Germany
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH v2 0/1] xilinx_zynq: Enable support for 4kiB MMU pages

[Jan.Sommer]

Could someone please push these changes?
I think this is the last patchset from me which is open.

Cheers,

Jan

> -Original Message-
> From: Sommer, Jan
> Sent: Friday, November 27, 2020 2:43 PM
> To: devel@rtems.org
> Cc: Sommer, Jan 
> Subject: [PATCH v2 0/1] xilinx_zynq: Enable support for 4kiB MMU pages
> 
> Changes in v2:
> - Disable the option by default for xilinx_zynq (keep enabled for
>   realview)
> - Created corresponding ticket: https://devel.rtems.org/ticket/4192
> 
> 
> Jan Sommer (1):
>   bsp/xilinx_zynq: Enable support for 4kiB MMU pages
> 
>  c/src/lib/libbsp/arm/xilinx-zynq/configure.ac |  4 
>  spec/build/bsps/arm/optmmusmallpages.yml  | 17 +++--
>  spec/build/bsps/arm/xilinx-zynq/grp.yml   |  2 +-
>  3 files changed, 20 insertions(+), 3 deletions(-)
> 
> --
> 2.17.1

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

RE: [PATCH v1 0/1] bsps/arm: Fix MMU small pages support

[Jan.Sommer]

If there are no objections, could someone please push the changes?

Cheers, 

Jan

> -Original Message-
> From: Sommer, Jan
> Sent: Tuesday, November 24, 2020 9:41 AM
> To: devel@rtems.org
> Cc: Sommer, Jan 
> Subject: [PATCH v1 0/1] bsps/arm: Fix MMU small pages support
> 
> Following the discussion on the mailinglist
> (https://lists.rtems.org/pipermail/users/2020-November/067978.html) here
> is a patch which rounds the address range of a section only to next 4kiB
> boundary for the ARM MMU if small pages are enabled.
> 
> This should close the following tickets:
> - https://devel.rtems.org/ticket/4184
> - https://devel.rtems.org/ticket/4185
> 
> Best regards,
> 
>  Jan
> 
> Jan Sommer (1):
>   bsps/arm: Fix MMU small pages support
> 
>  bsps/arm/include/bsp/arm-cp15-start.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --
> 2.17.1

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

RE: CAN user space API for RTEMS

[Jan.Sommer]

Great.
I did some search regarding RTEMS and CAN beforehand, but only found quite old 
discussions.
I blame the naming of the bus for that .
@Pavel Pisa You have lots of experience with different 
CAN setups. In your Email from March you also discussed many different APIs. 
What is you take on can4linux? Would it be useful or is any of the others 
better suited?

Best regards,

Jan

From: Gedare Bloom 
Sent: Wednesday, December 2, 2020 6:00 PM
To: Sommer, Jan ; Pavel Pisa 
Cc: devel@rtems.org
Subject: Re: CAN user space API for RTEMS

Hello Jan,

There are some interested parties in CAN for RTEMS (but mostly of the volunteer 
type). Have a look at Pavel's message from March this year: 
https://lists.rtems.org/pipermail/devel/2020-March/058161.html

Gedare

On Wed, Dec 2, 2020 at 8:41 AM mailto:jan.som...@dlr.de>> 
wrote:
Hello,

We have some upcoming projects which will use RTEMS and will require CAN.
RTEMS doesn't have a CAN user interface and as far as I can see there is also 
no such thing in FreeBSD (please correct me if I'm wrong) which we could take 
in via rtems-libbsd.
Now, our options are to just use keep everything internal and use some custom 
driver (maybe based on some micro controller implementations) or contribute 
some kind of CAN subsystem to RTEMS.
I find the latter option more appealing, but then the question would be if we 
can use an API known from somewhere else like for spi and i2c and there doesn't 
seem to be a lot of choices:
- SocketCan --> seems to be too much work to implement in RTEMS (would probably 
need a socket implementation as well). I found some discussions about an 
implementation for FreeBSD, but it seems to have died.
- Can4Linux: Seems to be still maintained, the header file seems to be licensed 
under 3-Clause BSD. Is uses chardev, so it is probably reasonably easy to 
implement similar to spidev.

Would there be any interest in having a can4linux implementation in RTEMS? Or 
are there other/better available APIs?

Best regards,

Jan

Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR)
German Aerospace Center
Institute for Software Technology | Software for Space Systems and Interactive 
Visualization | Lilienthalplatz 7 | 38108 Braunschweig | Germany

Jan Sommer

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

CAN user space API for RTEMS

[Jan.Sommer]

Hello,

We have some upcoming projects which will use RTEMS and will require CAN.
RTEMS doesn't have a CAN user interface and as far as I can see there is also 
no such thing in FreeBSD (please correct me if I'm wrong) which we could take 
in via rtems-libbsd.
Now, our options are to just use keep everything internal and use some custom 
driver (maybe based on some micro controller implementations) or contribute 
some kind of CAN subsystem to RTEMS.
I find the latter option more appealing, but then the question would be if we 
can use an API known from somewhere else like for spi and i2c and there doesn't 
seem to be a lot of choices:
- SocketCan --> seems to be too much work to implement in RTEMS (would probably 
need a socket implementation as well). I found some discussions about an 
implementation for FreeBSD, but it seems to have died.
- Can4Linux: Seems to be still maintained, the header file seems to be licensed 
under 3-Clause BSD. Is uses chardev, so it is probably reasonably easy to 
implement similar to spidev.

Would there be any interest in having a can4linux implementation in RTEMS? Or 
are there other/better available APIs?

Best regards,

Jan

Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR)
German Aerospace Center
Institute for Software Technology | Software for Space Systems and Interactive 
Visualization | Lilienthalplatz 7 | 38108 Braunschweig | Germany

Jan Sommer

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

RE: BSP_CONSOLE_MINOR option for Zynq board with new build system

[Jan.Sommer]

Hi Sebastian,

I forgot to follow up with this until I ran into the same thing again. 
Your patch works and solves the problem.
Would you be so kind to push it to master?

Best regards,

Jan

> -Original Message-
> From: Sebastian Huber 
> Sent: Friday, September 25, 2020 4:14 PM
> To: Sommer, Jan ; devel@rtems.org
> Subject: Re: BSP_CONSOLE_MINOR option for Zynq board with new build
> system
> 
> Hello Jan,
> 
> On 25/09/2020 15:36, jan.som...@dlr.de wrote:
> > Hello,
> >
> > I am currently making my first steps with the new build system and so far it
> is amazing.
> > Especially, the inheritance option is very handy for maintaining different
> configurations.
> > Therefore, a big thank you to Sebastian and everyone else involved.
> thanks for having a look at it.
> >
> > I ran into a smaller problem when compiling for a zynq-board.
> > I tried to override BSP_CONSOLE_MINOR=0, but it seems that the option is
> interpreted as a Boolean and then the define not set.
> > At least I run into:
> > ../../../bsps/arm/xilinx-zynq/start/bspreset.c: In function 'bsp_reset':
> > ../../../bsps/arm/xilinx-zynq/start/bspreset.c:37:49: error:
> 'BSP_CONSOLE_MINOR' undeclared (first use in this function)
> > 37 |
> zynq_uart_reset_tx_flush(_uart_instances[BSP_CONSOLE_MINOR]);
> 
> Yes, this could be a potential problem in several BSPs. I used a script to
> convert the BSP options, but to detect if it was an integer or boolean type
> was just an heuristic. In order to fix this, you first have to find the build
> specification item of the option:
> 
> spec/build/bsps/arm/xilinx-zynqmp/optconminor.yml:name:
> BSP_CONSOLE_MINOR
> spec/build/bsps/arm/xilinx-zynq/optconminor.yml:name:
> BSP_CONSOLE_MINOR
> 
> So, we have this option duplicated. This is an issue on its own. At some point
> in time we should unify the options across the BSPs.
> 
> Then open the file (spec/build/bsps/arm/xilinx-zynq/optconminor.yml):
> 
> SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> actions:
> - get-boolean: null
> - define-condition: null
> build-type: option
> copyrights:
> - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-
> brains.de)
> default: true
> default-by-variant: []
> description: |
>    minor number of console device
> enabled-by: true
> links: []
> name: BSP_CONSOLE_MINOR
> type: build
> 
> Under actions you see what is done with the value specified by the
> configuration file (or the default value). See also:
> 
> https://docs.rtems.org/branches/master/eng/req/items.html#spectypebuild
> optionaction
> 
> This patch fixes probably the issue:
> 
> diff --git a/spec/build/bsps/arm/xilinx-zynq/optconminor.yml
> b/spec/build/bsps/arm/xilinx-zynq/optconminor.yml
> index 55074c6dac..486eb92d33 100644
> --- a/spec/build/bsps/arm/xilinx-zynq/optconminor.yml
> +++ b/spec/build/bsps/arm/xilinx-zynq/optconminor.yml
> @@ -1,15 +1,16 @@
>   SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
>   actions:
> -- get-boolean: null
> -- define-condition: null
> +- get-integer: null
> +- define: null
>   build-type: option
>   copyrights:
>   - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-
> brains.de)
> -default: true
> +default: 1
>   default-by-variant: []
>   description: |
>     minor number of console device
>   enabled-by: true
> +format: '{}'
>   links: []
>   name: BSP_CONSOLE_MINOR
>   type: build
> 
> The integer options need a "format" attribute.

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

RE: [PATCH v1 0/1] xilinx_zynq: Enable support for 4kiB MMU pages

[Jan.Sommer]

> -Original Message-
> From: Sebastian Huber 
> Sent: Friday, November 27, 2020 9:27 AM
> To: Sommer, Jan ; devel@rtems.org
> Subject: Re: [PATCH v1 0/1] xilinx_zynq: Enable support for 4kiB MMU pages
> 
> On 26/11/2020 17:08, Jan Sommer wrote:
> 
> > This should enable the support for small MMU tables for the
> > xilinx_zynq based BSPs and enable it by default.
> I would not enable it by default, since it makes the TLB cache less efficient
> and you more frequently have to access memory to get the MMU
> descriptors. You only need the 4KiB pages, if you do some extra stuff in your
> application.

Ok, I copied the behavior from the realview BSP. Should I change it to default 
disabled there too?

Cheers,

Jan

> >
> > Would this also be something to backport to RTEMS5?
> > I could prepare a patch where it is not enabled by default, so that
> > there is no difference for users of 5.1.
> This would be fine from my side.
> 
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hub...@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/

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

How to set values depending on BSP options in spec files?

[Jan.Sommer]

Hello,

I tried to get further acquainted with the new build system and how the spec 
files work.
Following a previous discussion 
(https://lists.rtems.org/pipermail/users/2020-November/067971.html) I thought 
adding support for the 4 kB MMU pages to the xilinx_zynq_* BSPs might be a 
small task to check things out.
Unfortunately, I still ran in some problems.
What I essentially have to do is:
1. Add the option ARM_MMU_USE_SMALL_PAGES to the xilinx_zynq BSPs.
2. Update the linker script to reserve enough space for the small table 
descriptors.

1.) was pretty straight forward. I just added the a link to optmmusmallpages to 
the xilinx-zynq/grp.yml of the BSP family.

For 2.) I essentially only have to update the ARM_MMU_TRANSLATION_TABLE_SIZE to 
the right value.
The default value of 16kiB is set in arm/optmmusz.yml. For option 
ARM_MMU_USE_SMALL_PAGES enabled this would need to be 4MiB+16kiB.
How would I achieve to set the MMU table size dependent on the 
ARM_MMU_USE_SMALL_PAGES option?

Would it be somewhere in xilinx-zynq/grp.yml?
Or in the arm/optmmusz.yml somehow with the "default-by-variant" mechanism.
Or would I create an new xilinx-zynq/optmmusz.yml and define it there?
Or something else?

Best regards,

Jan


Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR)
German Aerospace Center
Institute for Software Technology | Software for Space Systems and Interactive 
Visualization | Lilienthalplatz 7 | 38108 Braunschweig | Germany

Jan Sommer

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

Certificate for docs.rtems.org expired?

[Jan.Sommer]

Hello,

The webmaster is probably aware, but just in case:
Firefox and Edge don't let me connect to docs.rtems.org because of an invalid 
certificate.
Probably, the certificate is expired. Connecting to www.rtems.org still works 
fine.

Best regards,

Jan

Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR)
German Aerospace Center
Institute for Software Technology | Software for Space Systems and Interactive 
Visualization | Lilienthalplatz 7 | 38108 Braunschweig | Germany

Jan Sommer
Telephone +49 531 295-2494 | Telefax 0531 295-2767 | jan.som...@dlr.de
DLR.de/SC

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

RE: AW: [PATCH 1/3] Remove duplicate GRETH driver

[Jan.Sommer]

> -Original Message-
> From: devel  On Behalf Of Jiri Gaisler
> Sent: Tuesday, October 27, 2020 3:18 PM
> To: devel@rtems.org
> Subject: Re: AW: [PATCH 1/3] Remove duplicate GRETH driver
> 
> 
> On 10/26/20 8:52 AM, Jiri Gaisler wrote:
> > On 10/26/20 3:37 AM, gabriel.moy...@dlr.de wrote:
> >> Hi Jiri,
> >>
> >> My understanding was that one driver version was meant to be used with
> drvmgr (greth.c) and the other without it (greth2.c). May I ask why do you've
> chosen to remove greth.c and not greth2.c?
> 
> I have fixed-up the greth.c file to avoid inline SPARC assembly code, but the
> file is not used even when RTEMS is compiled with --enable-drvmgr. The
> problem is that both greth2.c and greth.c are compiled, and as they define
> the same symbols, greth2.c is pulled in first by chance. I need to disable the
> building of the network files in bsps/shared/shared-sources.am when --
> enable-drvmgr is defined. Does anyone know how to do this? My skills in m4
> etc. are limited ... :-(
> 

If 99% of the code are the same, would it be an option to have just one driver 
implementation and in the drvmgr just use a wrapper for the driver?

Best regards,

Jan

> 
> >
> > The problem I had was that greth.c contains SPARC assembly code and
> > cannot be built on any other architecture. I will change my patch to
> > disable greth.c on non-SPARC targets or try to replace the asssembly
> > code with macros as in greth2.c. Thanks for the feedback!
> >
> > An other issue is that the two files are 99% identical, but only
> > greth,c seems to be maintained. PHY handling and multi-cast support
> > are areas where the files have diverged. But this is an other discussion ...
> >
> >
> >> Thanks,
> >> Gabriel
> >>
> >> -Ursprüngliche Nachricht-
> >> Von: devel  Im Auftrag von Jiri Gaisler
> >> Gesendet: Sonntag, 25. Oktober 2020 23:26
> >> An: devel@rtems.org
> >> Betreff: [PATCH 1/3] Remove duplicate GRETH driver
> >>
> >>* bsps/shared/net/greth2.c is being used instead
> >> ---
> >>  bsps/shared/grlib-sources.am  |4 -
> >>  bsps/shared/grlib/net/README  |7 -
> >>  bsps/shared/grlib/net/greth.c | 1655 -
> >>  bsps/shared/grlib/net/network_interface_add.c |   62 -
> >>  4 files changed, 1728 deletions(-)
> >>  delete mode 100644 bsps/shared/grlib/net/README  delete mode
> 100644
> >> bsps/shared/grlib/net/greth.c  delete mode 100644
> >> bsps/shared/grlib/net/network_interface_add.c
> >>
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: BSP_CONSOLE_MINOR option for Zynq board with new build system

[Jan.Sommer]

Thanks, I will have a look at it and check if your changes fix the issue.

Have a nice week-end,

   Jan

> -Original Message-
> From: Sebastian Huber 
> Sent: Friday, September 25, 2020 4:14 PM
> To: Sommer, Jan ; devel@rtems.org
> Subject: Re: BSP_CONSOLE_MINOR option for Zynq board with new build
> system
> 
> Hello Jan,
> 
> On 25/09/2020 15:36, jan.som...@dlr.de wrote:
> > Hello,
> >
> > I am currently making my first steps with the new build system and so far it
> is amazing.
> > Especially, the inheritance option is very handy for maintaining different
> configurations.
> > Therefore, a big thank you to Sebastian and everyone else involved.
> thanks for having a look at it.
> >
> > I ran into a smaller problem when compiling for a zynq-board.
> > I tried to override BSP_CONSOLE_MINOR=0, but it seems that the option is
> interpreted as a Boolean and then the define not set.
> > At least I run into:
> > ../../../bsps/arm/xilinx-zynq/start/bspreset.c: In function 'bsp_reset':
> > ../../../bsps/arm/xilinx-zynq/start/bspreset.c:37:49: error:
> 'BSP_CONSOLE_MINOR' undeclared (first use in this function)
> > 37 |
> zynq_uart_reset_tx_flush(_uart_instances[BSP_CONSOLE_MINOR]);
> 
> Yes, this could be a potential problem in several BSPs. I used a script to
> convert the BSP options, but to detect if it was an integer or boolean type
> was just an heuristic. In order to fix this, you first have to find the build
> specification item of the option:
> 
> spec/build/bsps/arm/xilinx-zynqmp/optconminor.yml:name:
> BSP_CONSOLE_MINOR
> spec/build/bsps/arm/xilinx-zynq/optconminor.yml:name:
> BSP_CONSOLE_MINOR
> 
> So, we have this option duplicated. This is an issue on its own. At some point
> in time we should unify the options across the BSPs.
> 
> Then open the file (spec/build/bsps/arm/xilinx-zynq/optconminor.yml):
> 
> SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> actions:
> - get-boolean: null
> - define-condition: null
> build-type: option
> copyrights:
> - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-
> brains.de)
> default: true
> default-by-variant: []
> description: |
>    minor number of console device
> enabled-by: true
> links: []
> name: BSP_CONSOLE_MINOR
> type: build
> 
> Under actions you see what is done with the value specified by the
> configuration file (or the default value). See also:
> 
> https://docs.rtems.org/branches/master/eng/req/items.html#spectypebuil
> doptionaction
> 
> This patch fixes probably the issue:
> 
> diff --git a/spec/build/bsps/arm/xilinx-zynq/optconminor.yml
> b/spec/build/bsps/arm/xilinx-zynq/optconminor.yml
> index 55074c6dac..486eb92d33 100644
> --- a/spec/build/bsps/arm/xilinx-zynq/optconminor.yml
> +++ b/spec/build/bsps/arm/xilinx-zynq/optconminor.yml
> @@ -1,15 +1,16 @@
>   SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
>   actions:
> -- get-boolean: null
> -- define-condition: null
> +- get-integer: null
> +- define: null
>   build-type: option
>   copyrights:
>   - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-
> brains.de)
> -default: true
> +default: 1
>   default-by-variant: []
>   description: |
>     minor number of console device
>   enabled-by: true
> +format: '{}'
>   links: []
>   name: BSP_CONSOLE_MINOR
>   type: build
> 
> The integer options need a "format" attribute.

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

BSP_CONSOLE_MINOR option for Zynq board with new build system

[Jan.Sommer]

Hello,

I am currently making my first steps with the new build system and so far it is 
amazing.
Especially, the inheritance option is very handy for maintaining different 
configurations.
Therefore, a big thank you to Sebastian and everyone else involved. 

I ran into a smaller problem when compiling for a zynq-board.
I tried to override BSP_CONSOLE_MINOR=0, but it seems that the option is 
interpreted as a Boolean and then the define not set.
At least I run into:
../../../bsps/arm/xilinx-zynq/start/bspreset.c: In function 'bsp_reset':
../../../bsps/arm/xilinx-zynq/start/bspreset.c:37:49: error: 
'BSP_CONSOLE_MINOR' undeclared (first use in this function)
   37 |   zynq_uart_reset_tx_flush(_uart_instances[BSP_CONSOLE_MINOR]);

Best regards,

   Jan


Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR)
German Aerospace Center
Institute for Software Technology | Software for Space Systems and Interactive 
Visualization | Lilienthalplatz 7 | 38108 Braunschweig | Germany

Jan Sommer
Telephone +49 531 295-2494 | Telefax 0531 295-2767 | jan.som...@dlr.de
DLR.de/SC

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

RE: [PATCH v1 7/9] bsps/pc386: Separate smp API functions. Makes smpfatal08 link

[Jan.Sommer]

> -Original Message-
> From: Sebastian Huber 
> Sent: Wednesday, September 16, 2020 12:30 PM
> To: Sommer, Jan ; devel@rtems.org
> Subject: Re: [PATCH v1 7/9] bsps/pc386: Separate smp API functions. Makes
> smpfatal08 link
> 
> On 16/09/2020 12:06, jan.som...@dlr.de wrote:
> 
> > Is there an easy way to only send the updated patch to the mailinglist or
> should I send in the full patch set with v2?
> It seems the patch set is already included in the RTEMS master.

Ok, then I will simply send a update.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH v1 7/9] bsps/pc386: Separate smp API functions. Makes smpfatal08 link

[Jan.Sommer]

Hi Sebastian,

Sure.
Is there an easy way to only send the updated patch to the mailinglist or 
should I send in the full patch set with v2?

Cheers,

  Jan

> -Original Message-
> From: Sebastian Huber 
> Sent: Tuesday, September 15, 2020 6:38 AM
> To: Sommer, Jan ; devel@rtems.org
> Subject: Re: [PATCH v1 7/9] bsps/pc386: Separate smp API functions. Makes
> smpfatal08 link
> 
> Hello Jan,
> 
> On 31/05/2020 16:22, Jan Sommer wrote:
> > diff --git a/bsps/i386/pc386/start/bspsmp.c
> > b/bsps/i386/pc386/start/bspsmp.c new file mode 100644 index
> > 00..026f86916f
> > --- /dev/null
> > +++ b/bsps/i386/pc386/start/bspsmp.c
> > @@ -0,0 +1,43 @@
> > +
> > +#include 
> 
> this file has no license and copyright header. Would you mind sending a patch
> which adds one. Ideally based on this template:
> 
> https://docs.rtems.org/branches/master/eng/coding-file-hdr.html#c-c-
> assembler-source-file-template

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

RE: [PATCH v1 2/6] waf: Add path-mappings feature

[Jan.Sommer]

Hi Chris,

> -Original Message-
> From: Chris Johns 
> Sent: Thursday, September 10, 2020 6:44 AM
> To: Sommer, Jan ; devel@rtems.org
> Subject: Re: [PATCH v1 2/6] waf: Add path-mappings feature
> 
> On 15/8/20 5:57 am, Jan Sommer wrote:
> > - path-mappings allow to fix autogenerated include paths for some
> > corner cases of target platforms without the need to change the build
> > system
> > - Currently used for i386 based bsps
> 
> I will need to take in this patch into my development libbsd branchs and
> merge.
> I will try and get this done ASAP.
> 

I am not sure I understand everything completely.
Do you need me to update anything in the patch?

Best regards,

   Jan

> I am refactoring parts of the libbsd builder.py and related files to separate
> the user and kernel space headers. There are conflicts in these files that
> become apparent with some of the FreeBSD source. It looks like I based my
> work on this patch and these changes so I hope it will be easy to sort out. I
> would prefer to bring this into my branch, sort out what is happening and
> push them.
> Sorry this will not happen today but it will get done as it is top of my list.
> 
> Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: We are loosing patches

[Jan.Sommer]

I would like this idea.
We got Gitlab this year and collaboration with it is pretty convenient.
They also seem to hand out free licenses for OSS projects.
I guess installing and maintaining an instance is probably quite some work.

Best regards,

   Jan

> -Original Message-
> From: devel  On Behalf Of Christian Mauderer
> Sent: Wednesday, September 9, 2020 10:24 AM
> To: RTEMS Devel RTEMS 
> Subject: We are loosing patches
> 
> Hello,
> 
> triggered by a comment from Chris here
> 
> https://lists.rtems.org/pipermail/users/2020-September/067873.html
> 
> I started to take a look at patches from non maintainers and write after
> approval maintainers for some months: I think in May and June we lost at
> least one or two of the following ones:
> 
> https://lists.rtems.org/pipermail/devel/2020-May/059751.html
> https://lists.rtems.org/pipermail/devel/2020-May/059771.html
> https://lists.rtems.org/pipermail/devel/2020-May/059772.html
> https://lists.rtems.org/pipermail/devel/2020-May/059773.html
> https://lists.rtems.org/pipermail/devel/2020-June/060125.html
> https://lists.rtems.org/pipermail/devel/2020-June/060231.html
> https://lists.rtems.org/pipermail/devel/2020-June/060235.html
> 
> It's a bit hard to see exactly whether a later version has been added with a
> different subject, merged with another patch or just has been rejected for
> some reason. That's another problem with our current system.
> 
> I think we start to loose valuable contributions due to that. I also found 
> some
> patches where just no one responded because no one noted it and the
> person sending the patch had to ping it some time later. That's not really
> encouraging to continue participating for new contributors.
> 
> I even lost track of some of my own patches in the past and found out about
> a month later that I should have pushed them long ago.
> 
> Maybe it would be a good idea to start at least discussing whether we should
> change something to avoid these problems. I think our current system has
> two main problems:
> 
> 1. All patches go to one single devel mailing list. It's sometimes hard to see
> which patches are for what repository. And small patches tend to just vanish
> between lot of other mails.
> 
> 2. We have a big problem seeing which patch sets are done, which are in the
> middle of a discussion and which are rejected.
> 
> A lot of other projects use software to solve these problems. Linux uses
> "patchwork" for it since a long time (which needs one mailing list per
> project). Most other projects use systems with pull requests like github or a
> self hosted gitlab for that kind of stuff.
> 
> Maybe we should think about following these examples and go one step to
> more modern software development too? What do you think?
> 
> Best regards
> 
> Christian
> --
> 
> embedded brains GmbH
> Herr Christian Mauderer
> Dornierstr. 4
> D-82178 Puchheim
> Germany
> email: christian.maude...@embedded-brains.de
> Phone: +49-89-18 94 741 - 18
> Fax:   +49-89-18 94 741 - 08
> PGP: Public key available on request.
> 
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH v1 0/6] [libbsd] Fix e1000 driver for i386 in master and 5

[Jan.Sommer]

Hi Chris,

> -Original Message-
> From: Chris Johns 
> Sent: Friday, August 14, 2020 11:43 PM
> To: Sommer, Jan ; devel@rtems.org
> Subject: Re: [PATCH v1 0/6] [libbsd] Fix e1000 driver for i386 in master and 5
> 
> On 15/8/20 5:57 am, Jan Sommer wrote:
> > Hello,
> >
> > I finally got around to port the e1000 driver fixes which are already
> > present in the 5-freebsd-12 branch of rtems-libbsd also for the master
> > (and 5) branch.
> 
> Thanks. I will push these soon.
> 

As mentioned over at the users list, could you please push these changes?
They should enable compilation for i386 again and we could establish Ethernet 
connections with Intel network devices.
The patches should apply to libbsd master and 5 branch, as they are both based 
on FreeBSD master.

> I am not sure if the 5 branch in the rtems-libbsd.git repo is right and if it
> should be made from the 5-freebsd-12 branch? I feel it is currently confusing
> but either way it has issues.
> 

Maybe, we can continue to discuss that outside of this patch set? Renaming a 
branch later should be no trouble.
An option could be to rename 5 -> 5-freebsd-master, then the mapping between 
rtems and FreeBSD would always be explicit.

Cheers,

   Jan

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

RE: Announce: RTEMS 5.1 Release

[Jan.Sommer]

> -Original Message-
> From: users [mailto:users-boun...@rtems.org] On Behalf Of Chris Johns
> Sent: Wednesday, August 26, 2020 3:54 AM
> To: Users
> Subject: Announce: RTEMS 5.1 Release
> 
> The RTEMS 5.1 Release is available. The release can be found at:

Great news and thank you very much for your efforts.
I saw that there is no release tag for 5.1 in the repository. Is this 
intentional or could you please add one?

> 
>  https://ftp.rtems.org/pub/rtems/releases/5/5.1
> 
> Please follow the release instructions provided by the link.
> 
> The RTEMS 5 release is a significant milestone for the RTEMS project with
> many
> years of effort from many people as we continue to improve RTEMS's
> features,
> capabilities and performance while maintaining our stability.
> 
> We love to hear about your projects and what you use RTEMS on so please
> let us
> know. You can post on u...@rtems.org or you can send Joel or me a private
> email.
> 
> If you find a problem please raise a ticket and select the 5.2 milestone. The
> simplest way to create a ticket is to head to the developer Wiki at:
> 

Are there guidelines of changes which are allowed for 5.2?
For example, we might need SPI on a Zynq board and could implement a driver 
using the SPI-API.
Would this be acceptable as a patch for 5.2 since it shouldn't break any 
features in the core-API?

Best regards,

   Jan

>  https://devel.rtems.org/
> 
> Then click on the "Next (milestone)" link for the RTEMS 5 Release. You will
> need
> an account.
> 
> Thanks to everyone who has contributed to the release over the past few
> years.
> This is a community project and without the support of the community we
> would
> not be able to make these quality releases.
> 
> Thanks
> Chris
> 
> ps: Happy birthday Dad!

Happy Birthday :)

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

[rtems-libbsd] Question how to treat necessary changes from freebsd master

[Jan.Sommer]

Hello,

I have now a patchset ready which should also properly enable the e1000 driver 
for the master branch of rtems-libbsd.
There is just a small problem:

The commit the current freebsd-org submodule points to has this line in the 
e1000/if_em.c 
(https://github.com/freebsd/freebsd/blob/6b0307a/sys/dev/e1000/if_em.c#L1839)

>   if (adapter->hw.mac.type < em_mac_min)
>   lem_smartspeed(adapter);
>   E1000_WRITE_REG(>hw, E1000_IMS, EM_MSIX_LINK | E1000_IMS_LSC);

This works fine on qemu, but hangs when tested on actual hardware.
With the current master of freebsd this has been changed to:

>   if (hw->mac.type < em_mac_min)
>   lem_smartspeed(adapter);
>   else if (hw->mac.type == e1000_82574 &&
>   adapter->intr_type == IFLIB_INTR_MSIX)
>   E1000_WRITE_REG(>hw, E1000_IMS, EM_MSIX_LINK |
>   E1000_IMS_LSC);

And this also works on the hardware.
So, should I add this change with an ifdef __rtems__ to the patch set which has 
to be resolved during the next bump of freebsd-org?
Or should I leave it out for the moment and it will be added automatically with 
the next bump of the submodule?

Best regards,

Jan


Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR)
German Aerospace Center
Simulation and Software Technology | Software for Space Systems and Interactive 
Visualization | Lilienthalplatz 7 | 38108 Braunschweig | Germany

Jan Sommer
Telephone +49 531 295-2494 | Telefax 0531 295-2767 | jan.som...@dlr.de
DLR.de/SC

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

RE: [PATCH v1 0/1] i386: Fix possible race condition on first context restore

[Jan.Sommer]

> -Original Message-
> From: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de]
> Sent: Wednesday, July 29, 2020 11:42 AM
> To: Sommer, Jan; devel@rtems.org
> Subject: Re: [PATCH v1 0/1] i386: Fix possible race condition on first context
> restore
> 
> On 29/07/2020 11:18, jan.som...@dlr.de wrote:
> 
> > Could someone please check the patch and push it to the 5 and master
> branches?
> > I will be on vacation from tomorrow, so I wanted to give it a pre-vacation
> bump.
> > My response times will be a bit delayed, but I will check emails from time 
> > to
> time.
> I checked in both patches.

Thank you. More relaxed vacation now :)
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH v1 0/1] i386: Fix possible race condition on first context restore

[Jan.Sommer]

Could someone please check the patch and push it to the 5 and master branches?
I will be on vacation from tomorrow, so I wanted to give it a pre-vacation bump.
My response times will be a bit delayed, but I will check emails from time to 
time.

Cheers,

   Jan

> -Original Message-
> From: Sommer, Jan
> Sent: Wednesday, July 22, 2020 2:42 PM
> To: devel@rtems.org
> Cc: Sommer, Jan
> Subject: [PATCH v1 0/1] i386: Fix possible race condition on first context
> restore
> 
> Ran into this problem sometimes when testing examples of rtems-libbsd,
> but it should be general.
> 
> I opened tickets https://devel.rtems.org/ticket/4030 and
> https://devel.rtems.org/ticket/4031 correspondintly.
> 
> Cheers,
> 
>Jan
> 
> Jan Sommer (1):
>   i386: Fix possible race condition on first context restore
> 
>  cpukit/score/cpu/i386/cpu_asm.S | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --
> 2.17.1

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

RE: [PATCH v1 0/1] bsps/pc386: Fix IPI for non-consecutive Apic IDs

[Jan.Sommer]

> -Original Message-
> From: Gedare Bloom [mailto:ged...@rtems.org]
> Sent: Monday, July 20, 2020 10:12 PM
> To: Sommer, Jan
> Cc: devel@rtems.org
> Subject: Re: [PATCH v1 0/1] bsps/pc386: Fix IPI for non-consecutive Apic IDs
> 
> Hi Jan,
> 
> Slightly off-topic, but which Intel Atom board are you using? If you
> can say, and if your board has non-legacy boot, how did you get
> through the boot sequence? 

We use one of these boards from RTD with an E38xx Atom: 
https://www.rtd.com/PC104/CM/CML24BT/CML24BT.htm
I can't check the boot settings from home office, but if I remember correctly 
we use the BIOS for booting (I assume that is the legacy mode?).
I compiled iPXE and boot it from an usb flash drive and then load and run the 
RTEMS applications via tftp.

Maybe using the approach of the x86_64 BSP via the FreeBSD loader could work 
with modern UEFIs?

Cheers,

   Jan



> That has been a trouble for some folks
> before.
> 
> Gedare
> 
> On Fri, Jul 3, 2020 at 6:32 AM Jan Sommer  wrote:
> >
> > Hi,
> >
> > I had some time for more hardware testing of the SMP functionality on a
> > PC.
> > It turns out I missed a few places where the APICID <-> cpuid needed to be
> > translated.
> > This only occurs if the APIC Ids of different cores are not numbered
> > consecutively, which qemu does.
> >
> > With this patch I can now run 52 examples on an Intel Atom with 4 cores.
> > The patch should apply to master and the 5 branch.
> > Did I understand it correctly, that for integrating the patch in the
> > RTEMS5 release, I need to first create a ticketr?
> >
> > Best regards,
> >
> > Jan
> >
> > Jan Sommer (1):
> >   bsps/pc386: Fix IPI for non-consecutive APICIDs
> >
> >  bsps/i386/pc386/start/smp-imps.c | 16 ++--
> >  1 file changed, 10 insertions(+), 6 deletions(-)
> >
> > --
> > 2.17.1
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel