> Once it's set, If I'm not rebuilding the toolset, I'd guess I go
> straight to steps 2.5, 2.6 in the quick-start guide?
I'm sorry, I should have been more specific...I meant 2.5 (Build a
BSP) and 2.6 (Test a BSP) from the RTEMS quick-start?
Thanks again!
On Tue, Jun 29, 2021 at 7:21 PM Joel Sh
From: Chris Johns
- FreeBSD is removing any dependence on binutils and release 13
has remove objdump. This is fine as we build our own version.
---
source-builder/defaults.mc | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/source-builder/defaults.mc b/source-builder/de
Thank you! I checked the config.log after using the --no-clean option and
realized that my GCC wasn't working. Seems like there were some issues with
linking: using binutils vs gold. Following this answer helped:
https://stackoverflow.com/a/53969757 resolve that issue.
On Tue, Jun 29, 2021 at 9:46
> On Jun 23, 2021, at 01:17 , Sebastian Huber
> wrote:
>
>
> On 21/06/2021 15:31, dufa...@hda.com wrote:
>>> On Jun 21, 2021, at 08:52 , Sebastian
>>> Huber wrote:
>>>
>>> What happens when you reduce the memory space for the mbufs to 4MiB? What
>>> is the "RTEMS work space"?
>> By "RTEMS
Hello Gedare,
On 29/06/2021 20:04, Christian Mauderer wrote:
I _think_ Sebastian tested it on the same evaluation board that I used
for writing the SD driver: STM32H743I-EVAL2. I'm not entirely sure
whether the "2" is really relevant or whether that's part of an order
number at a distributor.
The GICv3 support is shared between AArch32 and AArch64. For AArch32,
the new AARCH64_IS_NONSECURE is never defined. Use ARM_MULTILIB_ARCH_V4
instead.
This issue was introduced by 76c6caad52244ab9a14151620a80ff0f71035b6c.
There is still a change in bsp_interrupt_vector_enable() for AArch32
comp
Thanks, that makes sense.
On Wed, Jun 30, 2021 at 7:38 AM Sebastian Huber
wrote:
>
> The GICv3 support is shared between AArch32 and AArch64. For AArch32,
> the new AARCH64_IS_NONSECURE is never defined. Use ARM_MULTILIB_ARCH_V4
> instead.
>
> This issue was introduced by 76c6caad52244ab9a14151
On Wed, Jun 30, 2021 at 3:28 AM wrote:
>
> From: Chris Johns
>
> - FreeBSD is removing any dependence on binutils and release 13
> has remove objdump. This is fine as we build our own version.
removed. :)
> ---
> source-builder/defaults.mc | 5 ++---
> 1 file changed, 2 insertions(+), 3 dele
This patch introduced new warnings:
../../../cpukit/score/src/schedulerstrongapa.c: In function
'_Scheduler_strong_APA_Get_highest_ready':
../../../cpukit/score/src/schedulerstrongapa.c:394:10: warning:
'highest_ready' may be used uninitialized in this function
[-Wmaybe-uninitialized]
394 |
This patch replaces the previous patch that pulled ethernet
configuration from the BSP with configuration via config.inc. Commit of
this patch will be accompanied by reversion of RTEMS commit
10041a4cfc00d5f6876d3d6cfc30c23347b4cf42
___
devel mailing lis
This alters the selection of the 4 Cadence GEM interfaces on the Zynq
Ultrascale+ MPSoC BSP to be provided by config.inc instead of being
provided by options in the RTEMS BSP itself since those options appear
to be dead code when not used in conjunction with LibBSD.
---
rtemsbsd/include/bsp/nexus-
Hello,
I am working on re-implementing support for the uC5282 board in Qemu for use
with RTEMS. I think I am getting close, but am running into some debugging
issues in regards to context switching. I am using the RTEMS 'hello'
application for uC5282 to work on and debug my modifications. Curre
On 1/7/21 12:31 am, Joel Sherrill wrote:
> On Wed, Jun 30, 2021 at 3:28 AM wrote:
>>
>> From: Chris Johns
>>
>> - FreeBSD is removing any dependence on binutils and release 13
>> has remove objdump. This is fine as we build our own version.
>
> removed. :)
Thanks.
>
>> ---
>> source-builde
Looks good and thanks.
Chris
On 1/7/21 6:11 am, Kinsey Moore wrote:
> This alters the selection of the 4 Cadence GEM interfaces on the Zynq
> Ultrascale+ MPSoC BSP to be provided by config.inc instead of being
> provided by options in the RTEMS BSP itself since those options appear
> to be dead c
> + remaining = (uint32_t)result->tv_nsec + result->tv_sec;
What does "remaining" mean here? What do you get if you add a
(truncated) nanoseconds value to a seconds value? (Hint: the units
aren't the same, so the arithmetic is meaningless.)
I thought I could convert it back into the uint32_t
From: Chris Johns
- The member variable `path_` cannot be a reference and initialised to
a const char* type input. To do so would require there is a temporary with
an unspecified life time.
---
tester/covoar/AddressToLineMapper.h | 2 +-
tester/covoar/Target_aarch64.h | 2 +-
2 files ch
From: Chris Johns
---
.../testing/bsps/xilinx_versal_vck190.ini | 43 +++
1 file changed, 43 insertions(+)
create mode 100644 tester/rtems/testing/bsps/xilinx_versal_vck190.ini
diff --git a/tester/rtems/testing/bsps/xilinx_versal_vck190.ini
b/tester/rtems/testing/bsps/xili
17 matches
Mail list logo