Re: Naming convention for Rust target platforms
On Wed, Jan 31, 2024 at 12:31 AM Karel Gardas 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. > > > 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 > riscv32gc-unknown-linux-musl > riscv64-linux-android > riscv64gc-unknown-linux-gnu > riscv64gc-unknown-linux-musl > s390x-unknown-linux-gnu > s390x-unknown-linux-musl > sparc-unknown-linux-gnu > sparc64-unknown-linux-gnu > thumbv7neon-linux-androideabi > thumbv7neon-unknown-linux-gnueabihf > thumbv7neon-unknown-linux-musleabihf > x86_64-linux-android > x86_64-unikraft-linux-musl > x86_64-unknown-linux-gnu > x86_64-unknown-linux-gnux32 > x86_64-unknown-linux-musl > x86_64-unknown-linux-ohos > > ___
AW: AW: Naming convention for Rust target platforms
> -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
> -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: Naming convention for Rust target platforms
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 ri
AW: Naming convention for Rust target platforms
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 powerpc64le
Re: [Patch] bsp/tms570/sci: fix bug in tms570_sci_read_received_chars()
Hi Sebastian,
(I believe I forgot to include devel@rtems.org in my previous answer, sorry for
the duplicate email)
Sorry for the delayed answer, we were quite busy at work.
You will find attached the Git patch file for the SCI bug. I've taken into
account your suggestions.
While testing the counterpart of my protocol on a Zynq, I found a similar issue
where the UART is assumed to be used for printable text only. The second patch
fixes it.
I've used `git format-patch -2 HEAD` to generate the patch files. If something
is not quite right for you to integrate my changes, let me know.
Best regards,
Adrien Chardon, on behalf of Reflex Aerospace
From: Sebastian Huber
Sent: 25 January 2024 20:29
To: Adrien Chardon ; devel@rtems.org
Subject: Re: [Patch] bsp/tms570/sci: fix bug in tms570_sci_read_received_chars()
[You don't often get email from sebastian.hu...@embedded-brains.de. Learn why
this is important at https://aka.ms/LearnAboutSenderIdentification ]
Hello Adrien,
the change looks good. I would remove the
tms570_sci_read_received_chars() and TMS570_SCI_BUFFER_SIZE:
static void tms570_sci_interrupt_handler(void * arg)
{
rtems_termios_tty *tty = arg;
tms570_sci_context *ctx = rtems_termios_get_device_context(tty);
/*
* Check if we have received something.
*/
if ( (ctx->regs->FLR & TMS570_SCI_FLR_RXRDY ) == TMS570_SCI_FLR_RXRDY ) {
char buf[1];
buf[0] = ctx->regs->RD;
rtems_termios_enqueue_raw_characters(tty, buf, 1);
}
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/
From bcf82a1217d9bdf3ca5aca0beb713fb8abf24ee0 Mon Sep 17 00:00:00 2001
From: Adrien Chardon
Date: Tue, 30 Jan 2024 18:02:04 +0100
Subject: [PATCH 2/2] bsps/shared/zynq-uart-polled: fix bug in
zynq_uart_initialize()
Similar to the recent commit in tms570-sci.c, the assumption that a UART will
only see printable ASCII characters, instead of any value in the range
0x00-0xFF, is wrong.
A non forgiving binary protocol will be thrown off by this driver sending
"\r\r\r\r" when initializing.
If a user wants to flush the interface, they should explicitely use the
dedicated function `tcflush(fd, TCIOFLUSH);`.
---
bsps/shared/dev/serial/zynq-uart-polled.c | 6 --
1 file changed, 6 deletions(-)
diff --git bsps/shared/dev/serial/zynq-uart-polled.c bsps/shared/dev/serial/zynq-uart-polled.c
index 6865fa8d6f..222758c0d8 100644
--- bsps/shared/dev/serial/zynq-uart-polled.c
+++ bsps/shared/dev/serial/zynq-uart-polled.c
@@ -144,12 +144,6 @@ void zynq_uart_initialize(rtems_termios_device_context *base)
| ZYNQ_UART_MODE_PAR(ZYNQ_UART_MODE_PAR_NONE)
| ZYNQ_UART_MODE_CHRL(ZYNQ_UART_MODE_CHRL_8)
| mode_clks;
-
- while (zynq_uart_read_polled(base) >= 0) {
-/* Drop */
- }
-
- zynq_uart_reset_tx_flush(ctx);
}
int zynq_uart_read_polled(rtems_termios_device_context *base)
--
2.34.1
From 6130a1f06150d5194d6af34ff722567cd72f5de6 Mon Sep 17 00:00:00 2001
From: Adrien Chardon
Date: Wed, 24 Jan 2024 18:01:52 +0100
Subject: [PATCH 1/2] bsp/tms570/sci: fix bug in
tms570_sci_read_received_chars()
`tms570_sci_interrupt_handler()` is called when an RX interrupt fires. It checks
in the register `FLR`, the `RXRDY` bit (Receiver ready flag - indicate that the
SCIRD contains new data). If it is set, it calls
`tms570_sci_read_received_chars()`.
`tms570_sci_read_received_chars()` checks the register `RD` against 0. If it is
non zero, it returns 1 to indicate that one byte was read.
In the old behavior, if it is zero, the function returns 0 to indicate that no
data was read.
The new behavior is to not silently drop 0x00 bytes. Ignoring 0x00 bytes is fine
when working with printable text (which, I assume, is how this driver was
tested), but as soon as the UART is used in non canonical (raw) mode, with
potentially 0x00 bytes, these bytes will be silently dropped, causing issues in
the data/protocol layer above.
---
bsps/arm/tms570/console/tms570-sci.c | 45 ++--
1 file changed, 9 insertions(+), 36 deletions(-)
diff --git bsps/arm/tms570/console/tms570-sci.c bsps/arm/tms570/console/tms570-sci.c
index d5668034ef..0d1e10f108 100644
--- bsps/arm/tms570/console/tms570-sci.c
+++ bsps/arm/tms570/console/tms570-sci.c
@@ -33,8 +33,6 @@
#include
#include
-#define TMS570_SCI_BUFFER_SIZE 1
-
// This symbol can overwriten in user space. Not that making it const prevented
// the weak/strong mechanism to work and the linker always preferred this symbol
// over the strong one in user space.
@@ -176,33 +174,6 @@ rtems_device_driver console_initialize(
return RTEMS_SUCCESSFUL;
}
[PATCH rtems-source-builder] bare/config/qemu-5.2.0: Add gdbus-codegen patch
--- bare/config/devel/qemu-5.2.0-1.cfg | 7 +++ 1 file changed, 7 insertions(+) diff --git a/bare/config/devel/qemu-5.2.0-1.cfg b/bare/config/devel/qemu-5.2.0-1.cfg index 3c8186b..ac476ad 100644 --- a/bare/config/devel/qemu-5.2.0-1.cfg +++ b/bare/config/devel/qemu-5.2.0-1.cfg @@ -43,6 +43,13 @@ %hash sha512 cgem_zynqmp_versal.patch \ XIAGD29Qa4uaEKij3TYh1HJUJb7r9ZjZXl19t3Vk+8uleG2O7M1xgqmeA6zoQq+GCrcMRoJxqV4kniRapLgZRQ== +# +# Patch to fix detection of gdbus-codegen from gio-2.0 packageconfig in QEMU configure used by QEMU meson +# +%patch add qemu --rsb-file=gdbus_codegen.patch -p1 https://devel.rtems.org/raw-attachment/ticket/4987/0001-configure-Correctly-handle-gdbus_codegen.patch +%hash sha512 gdbus_codegen.patch \ + 1zQ7kAtB11NwNuFK4pXOpYjk09lrgN8CPpc2qNzm2BzDVfhiTh0JWCKtuMbdgKijKdXDKEe/D42ig/XWlINXLg== + # # The Qemu build instructions. We use 5.x.x Release 1. # -- 2.39.2 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-source-builder] bare/config/qemu-5.2.0: Add gdbus-codegen patch
OK Thanks Chris On 1/2/2024 6:30 am, Kinsey Moore wrote: > --- > bare/config/devel/qemu-5.2.0-1.cfg | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/bare/config/devel/qemu-5.2.0-1.cfg > b/bare/config/devel/qemu-5.2.0-1.cfg > index 3c8186b..ac476ad 100644 > --- a/bare/config/devel/qemu-5.2.0-1.cfg > +++ b/bare/config/devel/qemu-5.2.0-1.cfg > @@ -43,6 +43,13 @@ > %hash sha512 cgem_zynqmp_versal.patch \ > > XIAGD29Qa4uaEKij3TYh1HJUJb7r9ZjZXl19t3Vk+8uleG2O7M1xgqmeA6zoQq+GCrcMRoJxqV4kniRapLgZRQ== > > +# > +# Patch to fix detection of gdbus-codegen from gio-2.0 packageconfig in QEMU > configure used by QEMU meson > +# > +%patch add qemu --rsb-file=gdbus_codegen.patch -p1 > https://devel.rtems.org/raw-attachment/ticket/4987/0001-configure-Correctly-handle-gdbus_codegen.patch > +%hash sha512 gdbus_codegen.patch \ > + > 1zQ7kAtB11NwNuFK4pXOpYjk09lrgN8CPpc2qNzm2BzDVfhiTh0JWCKtuMbdgKijKdXDKEe/D42ig/XWlINXLg== > + > # > # The Qemu build instructions. We use 5.x.x Release 1. > # ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [Patch] bsp/tms570/sci: fix bug in tms570_sci_read_received_chars()
On 31.01.24 18:35, Adrien Chardon wrote: You will find attached the Git patch file for the SCI bug. I've taken into account your suggestions. Thanks, I checked in this patch with some changes since it didn't apply on the master branch. I guess you have some additional local modifications. -- 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
Re: [Patch] bsp/tms570/sci: fix bug in tms570_sci_read_received_chars()
Hello Adrien, On 31.01.24 18:35, Adrien Chardon wrote: While testing the counterpart of my protocol on a Zynq, I found a similar issue where the UART is assumed to be used for printable text only. The second patch fixes it. I am not sure about this patch. It changes the initialization. The code you remove was added by: commit 691d0edd34f25a883c5dd0a56051d087b88e4fa4 Author: Chris Johns Date: Tue Aug 17 17:57:41 2021 +1000 arm/xilinx: Fix zynq-uart interrupt receive - Trigger on a single character entering the RX FIFO - Disable the RX timeout - Send up to a FIFO full of data -- 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
Re: [PATCH v2 0/5] libtest: Add packet processor
Hello, any comments to the second version of this patch set? -- 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
