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:

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, F

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 mentione

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

AW: Naming convention for Rust target platforms

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

Naming convention for Rust target platforms

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

RE: New GPIO-API merged?

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

RE: Interested for GSoC 2023

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

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

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

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

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 op

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

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

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 Raumfahr

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

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

RE: GitLab and BuildBot

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

RE: docs not building to PDF

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:

RE: libbsd fails to link on i386

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 F

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 On Behalf Of Joel Sherrill Sent: Wednesday, August 17, 2022 11:24 PM To: rtems-de...@rtems.org Subject: libbsd fails to l

RE: V2 : Zynq/ZynqMP UART driver

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

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

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

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

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

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,

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

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;

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

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

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

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 tim

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

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

[rtems5] Assertion triggered with --enable-debug

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_initial

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

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

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

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

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

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

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

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)

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

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 Me

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

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

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

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

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

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 Maude

Improve SMP support for PC BSP

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

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

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

RE: Building llvm toolchain for RTEMS

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

RE: Writing code that takes time to run

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

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, bu

RE: Writing code that takes time to run

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 tim

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

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

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

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

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

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 diffe

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

@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; dev

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

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

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 i

[libbsd] How to install machine header files?

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

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

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

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

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 Q

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

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

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

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

RE: About is_non_preempt_mode_supported

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

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

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 P

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

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

RE: Flashdisk driver based on spidev

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 driv

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

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 +

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

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

Flashdisk driver based on spidev

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

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

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

RE: [PATCH 0/2] Import ehci_pci

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

RE: [PATCH 0/2] Import ehci_pci

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 O

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

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

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

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, 202

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 .

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

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, Februar

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

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

Build failure with current master

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

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

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 supp

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

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

RE: CAN user space API for RTEMS

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.

CAN user space API for RTEMS

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

RE: BSP_CONSOLE_MINOR option for Zynq board with new build system

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:

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

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

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

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

Certificate for docs.rtems.org expired?

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 Raumfa

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

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

RE: BSP_CONSOLE_MINOR option for Zynq board with new build system

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

BSP_CONSOLE_MINOR option for Zynq board with new build system

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 compi

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

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

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

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

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

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 includ

RE: We are loosing patches

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

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

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 arou

RE: Announce: RTEMS 5.1 Release

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

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

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

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

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

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

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:

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

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

  1   2   >