On 21/04/2021 03:56, Joel Sherrill wrote:
For SPARC, all went ok. For arm zynq qemu, I got an object mismatch on
Ada tests.
It is broken on arm for some time. I think it is related to the
"simplified" FPU machine options introduced by Arm some time ago. I had
no time to debug this.
--
Cool, I tried building uboot for the board from this repo:
https://github.com/Xilinx/u-boot-xlnx, and the instructions for zcu106 are
here:
https://github.com/Xilinx/u-boot-xlnx/blob/master/doc/board/xilinx/zynqmp.rst.
But I tried a lot and could not find
Hi
I recently built GCC 11 and GCC 10 with Ada support for SPARC, PowerPC, and
ARM. I did this by hand and not with the RSB.
For SPARC, all went ok. For arm zynq qemu, I got an object mismatch on Ada
tests.
Does this work for anyone?
Thanks.
--joel
On Tue, Apr 20, 2021 at 7:07 PM Chris Johns wrote:
> On 21/4/21 3:37 am, Gedare Bloom wrote:
> > To me, it doesn't make any sense that someone will build and install
> > RTEMS with multiple networking stacks for the same application.
>
> I do this. I have applications in production with the
On 21/4/21 3:37 am, Gedare Bloom wrote:
> To me, it doesn't make any sense that someone will build and install
> RTEMS with multiple networking stacks for the same application.
I do this. I have applications in production with the legacy stack and being
tested and developed against libbsd. This
On 20/4/21 3:46 pm, Sebastian Huber wrote:
> On 20/04/2021 07:30, Chris Johns wrote:
>
>> On 20/4/21 3:28 pm, Sebastian Huber wrote:
>>> This helps if applications are started by a boot loader.
>> How does it help?
> /*
> * Set the Main Stack Pointer (MSP) to the ISR stack area end just
Looks good.
On Tue, Apr 20, 2021, 12:33 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> The multiplication to calculate the length of the memory area to
> allocate may overflow. Return NULL in case of an overflow.
>
> Close #4389.
> ---
> cpukit/libcsupport/src/calloc.c
The multiplication to calculate the length of the memory area to
allocate may overflow. Return NULL in case of an overflow.
Close #4389.
---
cpukit/libcsupport/src/calloc.c | 13 -
cpukit/libcsupport/src/rtemscalloc.c | 9 -
testsuites/libtests/malloctest/init.c | 23
Does this one work? For some reason the full header was not included..
Kind Regards
Robin
On Tue, 20 Apr 2021 at 20:11, Robin Mueller
wrote:
> This commit excludes the PAGESIZE legacy define
> because there is a nameclash with a define of the same name
> coming from the RTEMS header limits.h.
This commit excludes the PAGESIZE legacy define
because there is a nameclash with a define of the same name
coming from the RTEMS header limits.h.
All other changes come from loading the file from a Unix system.
---
.../stm32h7/include/Legacy/stm32_hal_legacy.h | 172 +-
1 file
On 20/04/2021 19:45, Robin Müller wrote:
Hmm, do you have an idea how to fix this cleanly? Was this the reason
the implementation returned 0?
Yes.
This was not an issue with the other implementation:
(rtems_clock_get_ticks_since_boot() * 1000) /
rtems_clock_get_ticks_per_second();
This
Hmm, do you have an idea how to fix this cleanly? Was this the reason the
implementation returned 0?
This was not an issue with the other implementation:
(rtems_clock_get_ticks_since_boot() * 1000) /
rtems_clock_get_ticks_per_second();
Kind Regards
Robin
On Tue, 20 Apr 2021 at 19:31, Robin
Hmm thats odd. File was created on Windows. Now im on Ubuntu, and if i try
to load it it automatically does something with the line endings of the
file taken from upstream/master..
Kind Regards
Robin
On Tue, 20 Apr 2021 at 19:17, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> On
On Tue, Apr 20, 2021 at 11:09 AM Sebastian Huber
wrote:
>
> On 12/04/2021 11:56, Robin.Mueller wrote:
>
> > This adds a configuration option if lwIP is used instead of libbsd.
> > It works by specifying RTEMS_USE_LWIP in the config.ini file.
> The RTEMS_* namespace is reserved for RTEMS API
Yes, I tried to switch oscillator and clock init in the start hook, but
that did not appear to solve the issue.
Kind Regards
Robin
On Tue, 20 Apr 2021 at 19:24, Robin Müller
wrote:
> This is really odd.. THe function is already called in the start up hook
> function init_oscillator() before
On 20/04/2021 19:09, Robin Müller wrote:
Okay, there is some issue with the rtems function to get the uptime
nanoseconds.. The call appears to crash for some reason.
Is this function called before the clock driver is initialized?
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
On 12/04/2021 11:55, Robin.Mueller wrote:
This commit excludes the PAGESIZE legacy define
because there is a nameclash with a define of the same name
coming from the RTEMS header limits.h
I have problems to apply this patch. There seems to be a clash of line
endings.
--
embedded brains GmbH
Okay, there is some issue with the rtems function to get the uptime
nanoseconds.. The call appears to crash for some reason.
Kind Regards
Robin
On Tue, 20 Apr 2021 at 18:31, Robin Mueller
wrote:
> This now uses rtems_clock_get_uptime_nanoseconds
> to calculate the uptime ticks in milliseconds.
On 12/04/2021 11:56, Robin.Mueller wrote:
This adds a configuration option if lwIP is used instead of libbsd.
It works by specifying RTEMS_USE_LWIP in the config.ini file.
The RTEMS_* namespace is reserved for RTEMS API parts. Since this is
BSP-specific, I suggest to rename this option to
This now uses rtems_clock_get_uptime_nanoseconds
to calculate the uptime ticks in milliseconds.
---
bsps/arm/stm32h7/start/bspstart.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/bsps/arm/stm32h7/start/bspstart.c
b/bsps/arm/stm32h7/start/bspstart.c
index
Okay, then I will just implement using rtems_clock_get_uptime_nanoseconds()
, similarly to how it was done in the lwIP sys_now implementation by Pavel.
Kind Regards
Robin
On Mon, 19 Apr 2021 at 19:53, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> On 19/04/2021 18:42, Gedare
The set looks good to me.
On Tue, Apr 20, 2021 at 4:53 AM Sebastian Huber
wrote:
>
> Sebastian Huber (3):
> Remove superfluous includes
> libcsupport: Move rtems_calloc()
> malloc: Hide RTEMS_Malloc_Sbrk_amount
>
> bsps/include/bsp/bootcard.h | 1 -
>
I am currently extending the lwIP port provided by you for the
STM32H743ZI-Nucleo. I am also extending it to be more easily adaptable to
other BSPs and new ports:
https://github.com/rmspacefish/rtems-lwip/tree/78ec73e89644c2ffa3b66c94239e1dc6ccf8a2f8
.
I've managed to receive UDP packets via RAW
Unfortunately, that's not something I've done so I don't have any
particular guidance or instructions for you at this point other than
recommending that you find the generic build instructions for u-boot on
the ZynqMP platform.
Kinsey
On 4/20/2021 07:00, Richi Dubey wrote:
Thanks!
Can you
Thanks!
Can you please tell me more about:
> build a new u-boot that can do what you need and then package it into
> BOOT.bin using bootgen (the code is available on github).
this? How do I build a new uboot that defaults to AArch32 at EL1?
On Mon, Apr 19, 2021 at 6:11 PM Kinsey Moore
wrote:
Move RTEMS_Malloc_Sbrk_amount to the only implementation file which uses
it and make it private to hide implementation-details from an API
header.
---
cpukit/include/rtems/malloc.h | 7 +--
cpukit/libcsupport/src/rtems_heap_extend_via_sbrk.c | 7 ++-
2 files changed,
---
bsps/include/bsp/bootcard.h| 1 -
cpukit/libcsupport/src/newlibc_reent.c | 1 -
cpukit/posix/src/psignal.c | 1 -
cpukit/posix/src/psignalclearsignals.c | 1 -
cpukit/posix/src/psignalsetprocesssignals.c| 1 -
Sebastian Huber (3):
Remove superfluous includes
libcsupport: Move rtems_calloc()
malloc: Hide RTEMS_Malloc_Sbrk_amount
bsps/include/bsp/bootcard.h | 1 -
cpukit/Makefile.am| 1 +
cpukit/include/rtems/malloc.h | 7 +--
Move rtems_calloc() since it only depends on rtems_malloc(). This may
make it easier to customize the heap allocator.
Change licence to BSD-2-Clause according to file history.
Update #3053.
---
cpukit/Makefile.am | 1 +
cpukit/libcsupport/src/malloc_deferred.c | 15
On 20/4/21 4:38 pm, Sebastian Huber wrote:
>
> On 20/04/2021 08:30, Chris Johns wrote:
>> On 20/4/21 3:54 pm, Sebastian Huber wrote:
>>> On 20/04/2021 07:30, Chris Johns wrote:
>>>
We need a way for libdebugger or any other piece of software to capture and
cascade the call. If this can
On 20/04/2021 08:30, Chris Johns wrote:
On 20/4/21 3:54 pm, Sebastian Huber wrote:
On 20/04/2021 07:30, Chris Johns wrote:
We need a way for libdebugger or any other piece of software to capture and
cascade the call. If this can be done on aarch64 then I am happy.
The fatal error extensions
On 20/4/21 3:54 pm, Sebastian Huber wrote:
> On 20/04/2021 07:30, Chris Johns wrote:
>
>> We need a way for libdebugger or any other piece of software to capture and
>> cascade the call. If this can be done on aarch64 then I am happy.
>
> The fatal error extensions execute in a user controllable
32 matches
Mail list logo
