Re: Subject: [PATCH] improve the format error reporting on i386

2021-09-09 Thread Gedare Bloom
Hi Zack, It looks like something got a little messed up with your commit message. Please see if you can fix it to remove the duplication(s). On Thu, Sep 9, 2021 at 6:00 PM zack leung wrote: > > score/i386: improve the format of exception reporting > > Updates #4203."Updates #4203." > --- > cpuki

Re: [PATCH rtems-tools v1 02/10] covoar.cc: Convert to C++

2021-09-09 Thread Chris Johns
On 10/9/21 12:17 am, Ryan Long wrote: > ExecutableInfo takes a const char* const parameter and initializes a string. > I tried to take off the c_str(), but it wouldn't build then. Is it alright > for that to temporarily stay there until I make a sweep through > ExecutableInfo.cc? Or do you want

Subject: [PATCH] improve the format error reporting on i386

2021-09-09 Thread zack leung
score/i386: improve the format of exception reporting Updates #4203."Updates #4203." --- cpukit/score/cpu/i386/cpu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cpukit/score/cpu/i386/cpu.c b/cpukit/score/cpu/i386/cpu.c index 77b7a7161c..06af57418d 100644 --- a/cpukit/score/c

Re: [PATCH v2] STM32 lwIP addition and CMake support

2021-09-09 Thread Mr. Andrei Chichak
Does it matter that there is a new stable release coming from the LwIP people very soon now? As a target user of the system, I can live with pulling STM’s HAL out of the RTEMS tree completely and adding it back in myself. The HAL calls in RTEMS are no different than the fight that just happened

Re: [PATCH v2] STM32 lwIP addition and CMake support

2021-09-09 Thread Shiro
Hi, Robin, There are a number of ways to manage this, but the first thought that comes to my mind is: * Priority #1: protect the license-integrity of the RTEMS src tree. That means any “license contamination” must be quarantined. I like the way NetBSD (BSD) handles source covered by some forei

Re: [PATCH] rtems: Generate

2021-09-09 Thread Gedare Bloom
This looks ok, but I am reminded that maybe the API for cache coherent allocations is not well-defined in case the BSP doesn't support coherent allocation. That's a separate, but related concern. On Wed, Sep 8, 2021 at 11:58 AM Sebastian Huber wrote: > > Change license to BSD-2-Clause according t

Re: [PATCH] improve the format of error reporting on i386

2021-09-09 Thread Gedare Bloom
On Wed, Sep 8, 2021 at 6:02 PM zack leung wrote: > > Thread ID is now a hex value part of ticket #4203 > Please add Updates #4203. To your commit message, on it's own line separated from the rest of the commit message by a blank line. The first part of your commit message should indicate the c

RE: [PATCH rtems-tools v1 02/10] covoar.cc: Convert to C++

2021-09-09 Thread Ryan Long
ExecutableInfo takes a const char* const parameter and initializes a string. I tried to take off the c_str(), but it wouldn't build then. Is it alright for that to temporarily stay there until I make a sweep through ExecutableInfo.cc? Or do you want me to go ahead and do that, and add it to this

RE: [PATCH rtems-tools v1 01/10] CoverageWriter: Convert to C++

2021-09-09 Thread Ryan Long
Got this fixed when I tested on MacOS. I'll change that "\n" to std::endl. -Original Message- From: devel On Behalf Of Chris Johns Sent: Wednesday, September 8, 2021 5:44 PM To: devel@rtems.org Subject: Re: [PATCH rtems-tools v1 01/10] CoverageWriter: Convert to C++ On 9/9/21 2:44 am,

Re: [PATCH v2] STM32 lwIP addition and CMake support

2021-09-09 Thread Robin Mueller
Hi Shiro, So you mean, retain the STM32 file unchanged in the source tree and then applying the patch? Or copy it from somewhere and then apply the patch? I thought of that option as well. The only issue I see here is that I merged the (example) files provided by STM32 so that one file can be

RE: V2 : Zynq/ZynqMP UART driver

2021-09-09 Thread 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 s

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

2021-09-09 Thread 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

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

2021-09-09 Thread chrisj
From: Chris Johns - Trigger on a single character entering the RX FIFO - Disable the RX timeout - Send up to a FIFO full of data --- bsps/include/dev/serial/zynq-uart.h | 1 + bsps/shared/dev/serial/zynq-uart-polled.c | 21 ++-- bsps/shared/dev/serial/zynq-uart.c| 66 +++

V2 : Zynq/ZynqMP UART driver

2021-09-09 Thread chrisj
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

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

2021-09-09 Thread 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