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
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
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
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
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
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
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
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
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,
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
> -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
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
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 +++
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
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
15 matches
Mail list logo