On Fri, Jan 29, 2021 at 9:57 AM Robin Müller
wrote:
> The whole code base I'm using might go public soon so I will also send the
> link here
> as soon as it is. I think this might also be useful for people who would
> like to evaluate how to set up Eclipse and the CMake build system for
> their
On 1/29/21 3:10 PM, jan.som...@dlr.de wrote:
From: Joel Sherrill
On Fri, Jan 29, 2021 at 7:20 AM wrote:
Hello
I just tried to debug a riscv test program running in qemu.
However, gdb could not establish a connection to qemu and produced the
following error:
/tmp/rtems/riscv❯
The whole code base I'm using might go public soon so I will also send the
link here
as soon as it is. I think this might also be useful for people who would
like to evaluate how to set up Eclipse and the CMake build system for
their application
Kind Regards
Robin
On Fri, 29 Jan 2021 at 17:47,
Alright, I figured out the issue, that was an application level problem,
the UDP frames are received and sent without issues as far as I can see.
I think I might submit a patch soon with some of initial improvements. But
I will summarize the changes I had to do here for now in case other people
Hi Matthew,
Sounds good. I will try to report if we make any progress on my end. We
intend to apply it to some additional code (EPICS) so that might give some
insights into the process that users might need for their applications.
On Fri, Jan 29, 2021 at 9:11 AM Matthew J Fletcher wrote:
> Hi
Hi Gedare,
I suspect that the Coverty analysis of RTEMS is more mature than the
GCC11 -fanalyzer at this stage, i was actually thinking of the
possibilities that an integrated GCC option adds to RTEMS based, but closed
source applications (such as ours), where other static options
like Coverty
On Fri, Jan 29, 2021 at 6:15 AM Joel Sherrill wrote:
>
>
> On Fri, Jan 29, 2021, 6:49 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> Hello Matthew,
>>
>> On 29/01/2021 10:14, Matthew J Fletcher wrote:
>> > Hi,
>> >
>> > Does RTEMS trunk roughly follow GCC releases ?,.
Unfortunately, may be time to characterize this so we can ask on gdb's list
what to do.
--joel
On Fri, Jan 29, 2021 at 8:38 AM wrote:
>
>
>
>
> *From:* Joel Sherrill
> *Sent:* Friday, January 29, 2021 3:33 PM
> *To:* Sommer, Jan
> *Cc:* Jiri Gaisler ; rtems-us...@rtems.org <
>
I think I might have found one issue. In the HAL_ETH_Init(ETH_HandleTypeDef
*heth) function
The following piece of code was excluded:
#ifndef __rtems__
/* SET DSL to 64 bit */
MODIFY_REG(heth->Instance->DMACCR, ETH_DMACCR_DSL, ETH_DMACCR_DSL_64BIT);
#endif /* __rtems__ */
I reintroduced the
From: Joel Sherrill
Sent: Friday, January 29, 2021 3:33 PM
To: Sommer, Jan
Cc: Jiri Gaisler ; rtems-us...@rtems.org
Subject: Re: riscv: gdb cannot connect to rtems runnin in qemu
On Fri, Jan 29, 2021 at 8:29 AM mailto:jan.som...@dlr.de>>
wrote:
Just tried again with the rv32imac BSP.
With
On Fri, Jan 29, 2021 at 8:29 AM wrote:
> Just tried again with the rv32imac BSP.
> With this gdb works.
>
I was poking at the gdb source and found the code in question in
riscv-tdep.c:
/* In theory a binary compiled for RV32 could run on an RV64 target,
however, this has not been
Just tried again with the rv32imac BSP.
With this gdb works.
Best regards,
Jan
> -Original Message-
> From: users On Behalf Of jan.som...@dlr.de
> Sent: Friday, January 29, 2021 3:10 PM
> To: j...@rtems.org; j...@gaisler.se
> Cc: users@rtems.org
> Subject: RE: riscv: gdb cannot
> From: Joel Sherrill
>
>On Fri, Jan 29, 2021 at 7:20 AM wrote:
>> Hello
>>
>> I just tried to debug a riscv test program running in qemu.
>> However, gdb could not establish a connection to qemu and produced the
>> following error:
>> /tmp/rtems/riscv❯ riscv-rtems6-gdb ticker.exe
>> GNU
On Fri, Jan 29, 2021 at 7:20 AM wrote:
> Hello
>
> I just tried to debug a riscv test program running in qemu.
> However, gdb could not establish a connection to qemu and produced the
> following error:
> /tmp/rtems/riscv❯ riscv-rtems6-gdb ticker.exe
> GNU gdb (GDB) 10.1.90.20210125-git
> [..]
>
Hello
I just tried to debug a riscv test program running in qemu.
However, gdb could not establish a connection to qemu and produced the
following error:
/tmp/rtems/riscv❯ riscv-rtems6-gdb ticker.exe
GNU gdb (GDB) 10.1.90.20210125-git
[..]
For help, type "help".
Type "apropos word" to search
On Fri, Jan 29, 2021, 5:52 AM Robin Müller
wrote:
> Hi,
>
> I am actually configuring the MPU with the following function, which was
> taken over from the STM32 example project:
>
> /*Configure the MPU attributes */
> void MPU_Config(void)
> {
> MPU_Region_InitTypeDef MPU_InitStruct;
>
>
On Fri, Jan 29, 2021, 6:49 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> Hello Matthew,
>
> On 29/01/2021 10:14, Matthew J Fletcher wrote:
> > Hi,
> >
> > Does RTEMS trunk roughly follow GCC releases ?,. i've seen discussion
> > of GCC 11 on the dev mailing list.
> you can
Hello Matthew,
On 29/01/2021 10:14, Matthew J Fletcher wrote:
Hi,
Does RTEMS trunk roughly follow GCC releases ?,. i've seen discussion
of GCC 11 on the dev mailing list.
you can already try out the GCC 11 based tools with the experimental
RTEMS 7 tool chain available in the RSB.
I wonder
Hi,
I am actually configuring the MPU with the following function, which was
taken over from the STM32 example project:
/*Configure the MPU attributes */
void MPU_Config(void)
{
MPU_Region_InitTypeDef MPU_InitStruct;
/* Disable the MPU */
HAL_MPU_Disable();
/* Configure the MPU
On 29/01/2021 12:01, Robin Müller wrote:
The HAL_ETH_Transmit call just times out. If I set the timeout to 20
to HAL_MAX_DELAY, the function will just block indefinitely.
Does anyone have an idea why this might happen?
I would check the memory settings in the MPU for this area. You probably
It probably adds the lwIP sources and builds them.
Right now I am trying to solve an issue with the DMA (hopefully the last
issue), because the following function used by lwIP is not working:
static err_t low_level_output(struct netif *netif, struct pbuf *p)
{
uint32_t i=0, framelen = 0;
Hi,
Does RTEMS trunk roughly follow GCC releases ?,. i've seen discussion of
GCC 11 on the dev mailing list.
I wonder if we (RTEMS users) could take advantage of the new static
analysis options in GCC 11.
https://developers.redhat.com/blog/2021/01/28/static-analysis-updates-in-gcc-11/
22 matches
Mail list logo
