Re: [PATCH rtems-tools] tiers: Add AArch64 to tier 1
On 20/1/22 9:04 am, Joel Sherrill wrote: > On Wed, Jan 19, 2022 at 2:56 PM Chris Johns wrote: >> >> On 20/1/22 5:08 am, Joel Sherrill wrote: >>> Are the Tier 1 architectures/BSPs documented anywhere besides an INI file? >> >> I do not think they are. > > Me either. I vaguely recall we have had this conversation before. > > Where should they be? Sebastian says we have 5 now. I am not sure. The user manual or a wiki page with a link in the user manual? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-libbsd 1/2] microblaze: Add AXI Ethernet support
On 20/1/22 2:54 pm, Alex White wrote:
> From: Jennifer Averett
> rtemsbsd/rtems/rtems-kernel-vmem.c| 17 +
> diff --git a/rtemsbsd/rtems/rtems-kernel-vmem.c
> b/rtemsbsd/rtems/rtems-kernel-vmem.c
> index f64fbd17..70708902 100644
> --- a/rtemsbsd/rtems/rtems-kernel-vmem.c
> +++ b/rtemsbsd/rtems/rtems-kernel-vmem.c
> @@ -41,6 +41,11 @@
>
> static MALLOC_DEFINE(M_VMEM, "vmem", "VMEM buffers");
>
> +int vmem_add(vmem_t *vm, vmem_addr_t addr, vmem_size_t size, int flags)
> +{
> + return 0;
> +}
> +
> int
> vmem_alloc(vmem_t *vm, vmem_size_t size, int flags, vmem_addr_t *addrp)
> {
> @@ -48,6 +53,18 @@ vmem_alloc(vmem_t *vm, vmem_size_t size, int flags,
> vmem_addr_t *addrp)
> return 0;
> }
>
> +static int dummy_vmem;
> +
> +vmem_t *vmem_create(const char *name, vmem_addr_t base,
> +vmem_size_t size, vmem_size_t quantum, vmem_size_t qcache_max, int flags)
> +{
> + return _vmem;
> +}
> +
> +void vmem_destroy(vmem_t *vm)
> +{
> +}
> +
> void
> vmem_free(vmem_t *vm, vmem_addr_t addr, vmem_size_t size)
> {
What is pulling this interface in?
Why have they been stubbed out?
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-libbsd 2/2] microblaze: Finish AXI Ethernet support
On 20/01/2022 04:54, Alex White wrote: diff --git a/freebsd/sys/netinet/tcp_input.c b/freebsd/sys/netinet/tcp_input.c index fc111d9c..60f9123a 100644 --- a/freebsd/sys/netinet/tcp_input.c +++ b/freebsd/sys/netinet/tcp_input.c @@ -721,6 +721,15 @@ tcp_input(struct mbuf **mp, int *offp, int proto) } #endif /* INET */ +#ifdef __rtems__ +#ifdef __MICROBLAZE__ + /* Ensure that the TCP header is properly aligned in memory. */ + struct tcphdr aligned_hdr; + memcpy(_hdr, th, sizeof(struct tcphdr)); + th = _hdr; +#endif +#endif + /* * Check that TCP offset makes sense, * pull out TCP options and adjust length. XXX Changes like this should not be hidden in a driver-specific patch. The alignment changes are hacks. Why don't you fix the Ethernet frame alignment in the network interface driver? -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-libbsd 0/2] MicroBlaze AXI Ethernet Support
On 20/01/2022 04:54, Alex White wrote: This patch set adds support for Xilinx's AXI Ethernet IP core. It has been tested both in QEMU and on the KCU105 board using the default FPGA implementation from the Xilinx's KCU105 PetaLinux BSP. Alex White (1): microblaze: Finish AXI Ethernet support Jennifer Averett (1): microblaze: Add AXI Ethernet support Please rework this patch set so that it follows the contributing guide: https://github.com/RTEMS/rtems-libbsd/blob/master/CONTRIBUTING.md#how-to-import-code-from-freebsd -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-libbsd 1/2] microblaze: Add AXI Ethernet support
From: Jennifer Averett
---
buildset/default.ini |1 +
freebsd/sys/dev/mii/tiphy.h | 57 +
freebsd/sys/dev/xdma/xdma.c | 501
freebsd/sys/dev/xdma/xdma.h | 285 +
freebsd/sys/dev/xdma/xdma_bank.c | 100 ++
freebsd/sys/dev/xdma/xdma_mbuf.c | 151 +++
freebsd/sys/dev/xdma/xdma_queue.c | 126 ++
freebsd/sys/dev/xdma/xdma_sg.c| 660 ++
freebsd/sys/dev/xdma/xdma_sglist.c| 103 ++
freebsd/sys/dev/xilinx/axidma.c | 666 ++
freebsd/sys/dev/xilinx/axidma.h | 96 ++
freebsd/sys/dev/xilinx/if_xae.c | +
freebsd/sys/dev/xilinx/if_xaereg.h| 122 ++
freebsd/sys/dev/xilinx/if_xaevar.h| 80 ++
.../sys/microblaze/include/machine/in_cksum.h | 82 ++
freebsd/sys/microblaze/microblaze/in_cksum.c | 255
libbsd.py | 43 +
rtemsbsd/include/bsp/nexus-devices.h | 10 +-
rtemsbsd/include/rtems/bsd/local/xdma_if.h| 144 +++
rtemsbsd/local/xdma_if.c | 57 +
rtemsbsd/rtems/rtems-kernel-vmem.c| 17 +
21 files changed, 4666 insertions(+), 1 deletion(-)
create mode 100644 freebsd/sys/dev/mii/tiphy.h
create mode 100644 freebsd/sys/dev/xdma/xdma.c
create mode 100644 freebsd/sys/dev/xdma/xdma.h
create mode 100644 freebsd/sys/dev/xdma/xdma_bank.c
create mode 100644 freebsd/sys/dev/xdma/xdma_mbuf.c
create mode 100644 freebsd/sys/dev/xdma/xdma_queue.c
create mode 100644 freebsd/sys/dev/xdma/xdma_sg.c
create mode 100644 freebsd/sys/dev/xdma/xdma_sglist.c
create mode 100644 freebsd/sys/dev/xilinx/axidma.c
create mode 100644 freebsd/sys/dev/xilinx/axidma.h
create mode 100644 freebsd/sys/dev/xilinx/if_xae.c
create mode 100644 freebsd/sys/dev/xilinx/if_xaereg.h
create mode 100644 freebsd/sys/dev/xilinx/if_xaevar.h
create mode 100644 freebsd/sys/microblaze/include/machine/in_cksum.h
create mode 100644 freebsd/sys/microblaze/microblaze/in_cksum.c
create mode 100644 rtemsbsd/include/rtems/bsd/local/xdma_if.h
create mode 100644 rtemsbsd/local/xdma_if.c
diff --git a/buildset/default.ini b/buildset/default.ini
index 454cc74e..1113c26f 100644
--- a/buildset/default.ini
+++ b/buildset/default.ini
@@ -23,6 +23,7 @@ dev_nic = on
dev_nic_broadcomm = on
dev_nic_dc = on
dev_nic_e1000 = on
+dev_nic_xilinx = on
dev_nic_fxp = on
dev_nic_re = on
dev_nic_smc = on
diff --git a/freebsd/sys/dev/mii/tiphy.h b/freebsd/sys/dev/mii/tiphy.h
new file mode 100644
index ..d3c35575
--- /dev/null
+++ b/freebsd/sys/dev/mii/tiphy.h
@@ -0,0 +1,57 @@
+/*-
+ * SPDX-License-Identifier: BSD-2-Clause
+ *
+ * Copyright (c) 2019 Ruslan Bukin
+ *
+ * This software was developed by SRI International and the University of
+ * Cambridge Computer Laboratory (Department of Computer Science and
+ * Technology) under DARPA contract HR0011-18-C-0016 ("ECATS"), as part of the
+ * DARPA SSITH research programme.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ *
+ * $FreeBSD$
+ */
+
+/*
+ * Texas Instruments DP83867IR/CR Robust, High Immunity
+ * 10/100/1000 Ethernet Physical Layer Transceiver.
+ */
+
+#ifndef _DEV_MII_TIPHY_H_
+#define _DEV_MII_TIPHY_H_
+
+#defineDP83867_PHYCR 0x10/* PHY Control Register
*/
+#define PHYCR_SGMII_EN (1 << 11)
+#defineDP83867_CFG20x14/* Configuration
Register 2 */
+#define CFG2_SPEED_OPT_10M_EN (1 << 6) /* Speed Optimization
*/
+#define CFG2_SPEED_OPT_ENHANCED_EN (1 << 8)
+#define
[PATCH rtems-libbsd 2/2] microblaze: Finish AXI Ethernet support
---
freebsd/sys/dev/xdma/xdma_sg.c | 3 ++-
freebsd/sys/dev/xilinx/axidma.c| 14 --
freebsd/sys/dev/xilinx/if_xae.c| 4 ++--
freebsd/sys/netinet/tcp_input.c| 9 +
freebsd/sys/netinet/tcp_subr.c | 10 ++
freebsd/sys/netinet6/ip6_input.c | 10 ++
.../include/rtems/bsd/test/network-config.h.in | 2 ++
7 files changed, 47 insertions(+), 5 deletions(-)
diff --git a/freebsd/sys/dev/xdma/xdma_sg.c b/freebsd/sys/dev/xdma/xdma_sg.c
index fa69a297..74fad421 100644
--- a/freebsd/sys/dev/xdma/xdma_sg.c
+++ b/freebsd/sys/dev/xdma/xdma_sg.c
@@ -107,6 +107,7 @@ xchan_bufs_alloc_reserved(xdma_channel_t *xchan)
for (i = 0; i < xchan->xr_num; i++) {
xr = >xr_mem[i];
size = round_page(xchan->maxsegsize);
+#ifndef __rtems__
if (vmem_alloc(xchan->vmem, size,
M_BESTFIT | M_NOWAIT, )) {
device_printf(xdma->dev,
@@ -117,10 +118,10 @@ xchan_bufs_alloc_reserved(xdma_channel_t *xchan)
xr->buf.size = size;
xr->buf.paddr = addr;
-#ifndef __rtems__
xr->buf.vaddr = kva_alloc(size);
#else
xr->buf.vaddr = calloc(1,size);
+ xr->buf.paddr = xr->buf.vaddr;
#endif
if (xr->buf.vaddr == 0) {
device_printf(xdma->dev,
diff --git a/freebsd/sys/dev/xilinx/axidma.c b/freebsd/sys/dev/xilinx/axidma.c
index 00ae2f1d..4fbb3104 100644
--- a/freebsd/sys/dev/xilinx/axidma.c
+++ b/freebsd/sys/dev/xilinx/axidma.c
@@ -68,6 +68,8 @@ __FBSDID("$FreeBSD$");
#ifdef __rtems__
#include
+
+#define AXIDMA_DESCRIPTOR_ALIGNMENT 64
#endif
#ifdef AXIDMA_DEBUG
@@ -182,6 +184,10 @@ axidma_intr(struct axidma_softc *sc,
st.error = errors;
st.transferred = desc->status & BD_CONTROL_LEN_M;
+ /* Handle Control / Status Streams. */
+ if (!st.transferred) {
+ st.transferred = desc->app4 & 0xFF;
+ }
tot_copied += st.transferred;
xchan_seg_done(xchan, );
@@ -362,16 +368,20 @@ axidma_desc_alloc(struct axidma_softc *sc, struct
xdma_channel *xchan,
chan->descs_phys = malloc(nsegments * sizeof(bus_dma_segment_t),
M_DEVBUF, M_NOWAIT | M_ZERO);
chan->mem_size = desc_size * nsegments;
+#ifndef __rtems__
if (vmem_alloc(xchan->vmem, chan->mem_size, M_FIRSTFIT | M_NOWAIT,
>mem_paddr)) {
device_printf(sc->dev, "Failed to allocate memory.\n");
return (-1);
}
-#ifndef __rtems__
chan->mem_vaddr = kva_alloc(chan->mem_size);
pmap_kenter_device(chan->mem_vaddr, chan->mem_size, chan->mem_paddr);
#else
- chan->mem_vaddr = calloc(1, chan->mem_size);
+ /* Align DMA descriptors */
+ chan->mem_vaddr = calloc(1, chan->mem_size +
AXIDMA_DESCRIPTOR_ALIGNMENT - 1);
+ chan->mem_vaddr = ((uintptr_t)chan->mem_vaddr +
+ AXIDMA_DESCRIPTOR_ALIGNMENT - 1) & ~0x3F;
+ chan->mem_paddr = chan->mem_vaddr;
#endif
device_printf(sc->dev, "Allocated chunk %lx %d\n",
diff --git a/freebsd/sys/dev/xilinx/if_xae.c b/freebsd/sys/dev/xilinx/if_xae.c
index 0582a588..3b23c5d4 100644
--- a/freebsd/sys/dev/xilinx/if_xae.c
+++ b/freebsd/sys/dev/xilinx/if_xae.c
@@ -729,7 +729,7 @@ xae_miibus_read_reg(device_t dev, int phy, int reg)
#if defined(__rtems__) && defined(DEBUG_MII)
dprintf("%s: reg: %d phy %d val 0x%x\n", __func__, reg, phy, rv);
#endif
- return (rv);
+ return (rv & 0x);
}
static int
@@ -980,7 +980,7 @@ xae_attach(device_t dev)
sc->mii_softc = device_get_softc(sc->miibus);
/* Apply vcu118 workaround. */
- // if (OF_getproplen(node, "xlnx,vcu118") >= 0)
+ if (OF_getproplen(node, "xlnx,vcu118") >= 0)
xae_phy_fixup(sc);
/* All ready to run, attach the ethernet interface. */
diff --git a/freebsd/sys/netinet/tcp_input.c b/freebsd/sys/netinet/tcp_input.c
index fc111d9c..60f9123a 100644
--- a/freebsd/sys/netinet/tcp_input.c
+++ b/freebsd/sys/netinet/tcp_input.c
@@ -721,6 +721,15 @@ tcp_input(struct mbuf **mp, int *offp, int proto)
}
#endif /* INET */
+#ifdef __rtems__
+#ifdef __MICROBLAZE__
+ /* Ensure that the TCP header is properly aligned in memory. */
+ struct tcphdr aligned_hdr;
+ memcpy(_hdr, th, sizeof(struct tcphdr));
+ th = _hdr;
+#endif
+#endif
+
/*
* Check that TCP offset makes sense,
* pull out TCP options and adjust length. XXX
diff --git a/freebsd/sys/netinet/tcp_subr.c b/freebsd/sys/netinet/tcp_subr.c
index eae696c1..d0025c01 100644
--- a/freebsd/sys/netinet/tcp_subr.c
+++ b/freebsd/sys/netinet/tcp_subr.c
@@ -1520,6 +1520,16 @@ tcp_respond(struct tcpcb *tp, void
[PATCH rtems-libbsd 0/2] MicroBlaze AXI Ethernet Support
This patch set adds support for Xilinx's AXI Ethernet IP core. It has been tested both in QEMU and on the KCU105 board using the default FPGA implementation from the Xilinx's KCU105 PetaLinux BSP. Alex White (1): microblaze: Finish AXI Ethernet support Jennifer Averett (1): microblaze: Add AXI Ethernet support buildset/default.ini |1 + freebsd/sys/dev/mii/tiphy.h | 57 + freebsd/sys/dev/xdma/xdma.c | 501 freebsd/sys/dev/xdma/xdma.h | 285 + freebsd/sys/dev/xdma/xdma_bank.c | 100 ++ freebsd/sys/dev/xdma/xdma_mbuf.c | 151 +++ freebsd/sys/dev/xdma/xdma_queue.c | 126 ++ freebsd/sys/dev/xdma/xdma_sg.c| 661 ++ freebsd/sys/dev/xdma/xdma_sglist.c| 103 ++ freebsd/sys/dev/xilinx/axidma.c | 676 ++ freebsd/sys/dev/xilinx/axidma.h | 96 ++ freebsd/sys/dev/xilinx/if_xae.c | + freebsd/sys/dev/xilinx/if_xaereg.h| 122 ++ freebsd/sys/dev/xilinx/if_xaevar.h| 80 ++ .../sys/microblaze/include/machine/in_cksum.h | 82 ++ freebsd/sys/microblaze/microblaze/in_cksum.c | 255 freebsd/sys/netinet/tcp_input.c |9 + freebsd/sys/netinet/tcp_subr.c| 10 + freebsd/sys/netinet6/ip6_input.c | 10 + libbsd.py | 43 + rtemsbsd/include/bsp/nexus-devices.h | 10 +- rtemsbsd/include/rtems/bsd/local/xdma_if.h| 144 +++ rtemsbsd/local/xdma_if.c | 57 + rtemsbsd/rtems/rtems-kernel-vmem.c| 17 + .../rtems/bsd/test/network-config.h.in|2 + 25 files changed, 4708 insertions(+), 1 deletion(-) create mode 100644 freebsd/sys/dev/mii/tiphy.h create mode 100644 freebsd/sys/dev/xdma/xdma.c create mode 100644 freebsd/sys/dev/xdma/xdma.h create mode 100644 freebsd/sys/dev/xdma/xdma_bank.c create mode 100644 freebsd/sys/dev/xdma/xdma_mbuf.c create mode 100644 freebsd/sys/dev/xdma/xdma_queue.c create mode 100644 freebsd/sys/dev/xdma/xdma_sg.c create mode 100644 freebsd/sys/dev/xdma/xdma_sglist.c create mode 100644 freebsd/sys/dev/xilinx/axidma.c create mode 100644 freebsd/sys/dev/xilinx/axidma.h create mode 100644 freebsd/sys/dev/xilinx/if_xae.c create mode 100644 freebsd/sys/dev/xilinx/if_xaereg.h create mode 100644 freebsd/sys/dev/xilinx/if_xaevar.h create mode 100644 freebsd/sys/microblaze/include/machine/in_cksum.h create mode 100644 freebsd/sys/microblaze/microblaze/in_cksum.c create mode 100644 rtemsbsd/include/rtems/bsd/local/xdma_if.h create mode 100644 rtemsbsd/local/xdma_if.c -- 2.30.2 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-tools] tiers: Add AArch64 to tier 1
On Wed, Jan 19, 2022 at 2:56 PM Chris Johns wrote: > > On 20/1/22 5:08 am, Joel Sherrill wrote: > > Are the Tier 1 architectures/BSPs documented anywhere besides an INI file? > > I do not think they are. Me either. I vaguely recall we have had this conversation before. Where should they be? Sebastian says we have 5 now. --joel > > Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Older gcc for MacOS
On Wed, Jan 19, 2022 at 3:00 PM Chris Johns wrote:
>
> On 8/1/22 9:34 am, Joel Sherrill wrote:
> > On Fri, Jan 7, 2022 at 4:17 PM Chris Johns wrote:
> >>
> >> On 8/1/22 8:28 am, Ryan Long wrote:
> >>> Hi,
> >>>
> >>> Our MacOS VM is failing to build several of the tools on the RTEMS 5
> >>> branch. We
> >>> think that using an older version of gcc should get all of the tools to
> >>> build. I
> >>> tried build gcc-4.8 with the RSB, but I get the following error.
> >>>
> >>>
> >>> tester@VM-MacOS bare % ../source-builder/sb-set-builder
> >>> --prefix=${HOME}/rtems-cron-5/tools/gcc-48 gnu-tools-4.8.2
> >>> RTEMS Source Builder - Set Builder, 5 (6225eadda1de modified)
> >>> Build Set: gnu-tools-4.8.2
> >>> error: gnu-tools-4.8.2:24: cannot find file: devel/gcc-4.8.2-newlib-cvs-1
> >>> Build Set: Time 0:00:00.000607
> >>> Build FAILED
> >>>
> >>>
> >>> Does anyone know how to get these tools to build?
> >>>
> >>
> >> It looks like the recipe has rotted.
> >
> > Was there a native gcc recipe? The name includes newlib which would
> > imply it is intended for use with RTEMS.
>
> The `bare/config` tree had recipes to build bare metal tool chains.
>
> > Also clearly old with cvs in the name.
> >
> > Having the ability to build an older gcc would ease the burden of
> > using 5 on newer FreeBSD, Linux, etc with stricter compilers. As
> > with everything, doing it with the RSB gives us control.
>
> Yes but do we want to head down that path?
What's the alternative? Updating the tools on older branches?
The host environments and the released RTEMS versionN build requirements
are two different sets which should overlap nicely at a point at time but
as OSes update and the RTEMS build requirements stay fixed, things go
downhill.
--joel
> Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Older gcc for MacOS
On 8/1/22 9:34 am, Joel Sherrill wrote:
> On Fri, Jan 7, 2022 at 4:17 PM Chris Johns wrote:
>>
>> On 8/1/22 8:28 am, Ryan Long wrote:
>>> Hi,
>>>
>>> Our MacOS VM is failing to build several of the tools on the RTEMS 5
>>> branch. We
>>> think that using an older version of gcc should get all of the tools to
>>> build. I
>>> tried build gcc-4.8 with the RSB, but I get the following error.
>>>
>>>
>>> tester@VM-MacOS bare % ../source-builder/sb-set-builder
>>> --prefix=${HOME}/rtems-cron-5/tools/gcc-48 gnu-tools-4.8.2
>>> RTEMS Source Builder - Set Builder, 5 (6225eadda1de modified)
>>> Build Set: gnu-tools-4.8.2
>>> error: gnu-tools-4.8.2:24: cannot find file: devel/gcc-4.8.2-newlib-cvs-1
>>> Build Set: Time 0:00:00.000607
>>> Build FAILED
>>>
>>>
>>> Does anyone know how to get these tools to build?
>>>
>>
>> It looks like the recipe has rotted.
>
> Was there a native gcc recipe? The name includes newlib which would
> imply it is intended for use with RTEMS.
The `bare/config` tree had recipes to build bare metal tool chains.
> Also clearly old with cvs in the name.
>
> Having the ability to build an older gcc would ease the burden of
> using 5 on newer FreeBSD, Linux, etc with stricter compilers. As
> with everything, doing it with the RSB gives us control.
Yes but do we want to head down that path?
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 0/5] Update rtems-bsp-builder to match RTEMS master
Looks great and thank you for taking care of this. Chris On 20/1/22 5:04 am, Joel Sherrill wrote: > The set of ini files for rtems-bsp-builder was out of sync > with the set of architectures and BSPs currently in RTEMS. > This patch set adds three architectures and a handful of BSPs. > > Build results with these patches are at: > > https://lists.rtems.org/pipermail/build/2022-January/031032.html > > --joel > > Joel Sherrill (5): > rtems-bsps-arm.ini: Add missing BSPs > rtems-bsps-riscv.ini: Add missing BSPs > rtems-bsps-aarch64.ini: New file > rtems-bsps-microblaze.ini: New file > rtems-bsps-x86_64.ini: New file > > config/rtems-bsps-aarch64.ini| 31 +++ > config/rtems-bsps-arm.ini| 16 +--- > config/rtems-bsps-microblaze.ini | 25 + > config/rtems-bsps-riscv.ini | 4 +++- > config/rtems-bsps-x86_64.ini | 25 + > 5 files changed, 97 insertions(+), 4 deletions(-) > create mode 100644 config/rtems-bsps-aarch64.ini > create mode 100644 config/rtems-bsps-microblaze.ini > create mode 100644 config/rtems-bsps-x86_64.ini > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-tools] tiers: Add AArch64 to tier 1
On 20/1/22 5:08 am, Joel Sherrill wrote: > Are the Tier 1 architectures/BSPs documented anywhere besides an INI file? I do not think they are. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-tools] tiers: Add AArch64 to tier 1
Are the Tier 1 architectures/BSPs documented anywhere besides an INI file? --joel On Wed, Jan 19, 2022 at 11:49 AM Kinsey Moore wrote: > > > On 1/19/2022 09:41, Kinsey Moore wrote: > > > > On 1/19/2022 09:13, Sebastian Huber wrote: > >> On 19/01/2022 15:42, Kinsey Moore wrote: > >>> On 1/18/2022 10:23, Sebastian Huber wrote: > On 18/01/2022 17:19, Kinsey Moore wrote: > > Hardware test results have recently been posted for AArch64. > > > > Closes #4581 > > It would be nice if you could run also the new validation tests on > this branch: > > https://git.rtems.org/sebh/rtems.git/log/?h=validation > > >>> It looks like when running with that branch, tar02 and psxftw01 are > >>> consistently failing with a PC in the stack since sometime after > >>> 68b0db358c81a7f770a44ceb819197bdc320bc99 which is what the other > >>> test run used. I'll have to track that down. > >> > >> Thanks for testing. It would be good to do a git bisect to figure out > >> the problem. > > I'm currently doing that now and should have it narrowed down soon. > > > It looks like this was actually just a bad partial build and a full > rebuild resolved the two failures. > > > Kinsey > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 5/5] rtems-bsps-x86_64.ini: New file
--- config/rtems-bsps-x86_64.ini | 25 + 1 file changed, 25 insertions(+) create mode 100644 config/rtems-bsps-x86_64.ini diff --git a/config/rtems-bsps-x86_64.ini b/config/rtems-bsps-x86_64.ini new file mode 100644 index 000..eeccfea --- /dev/null +++ b/config/rtems-bsps-x86_64.ini @@ -0,0 +1,25 @@ +# +# RTEMS Tools Project (http://www.rtems.org/) +# Copyright 2022 Joel Sherrill (j...@rtems.org) +# All rights reserved. +# +# This file is part of the RTEMS Tools package in 'rtems-bsp-builder'. +# +# Permission to use, copy, modify, and/or distribute this software for any +# purpose with or without fee is hereby granted, provided that the above +# copyright notice and this permission notice appear in all copies. +# +# THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES +# WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF +# MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR +# ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES +# WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN +# ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF +# OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + +# +# x86_64 Architecture +# +[x86_64] +bsps = amd64 +exclude = smp -- 2.24.4 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 4/5] rtems-bsps-microblaze.ini: New file
--- config/rtems-bsps-microblaze.ini | 25 + 1 file changed, 25 insertions(+) create mode 100644 config/rtems-bsps-microblaze.ini diff --git a/config/rtems-bsps-microblaze.ini b/config/rtems-bsps-microblaze.ini new file mode 100644 index 000..b886dbd --- /dev/null +++ b/config/rtems-bsps-microblaze.ini @@ -0,0 +1,25 @@ +# +# RTEMS Tools Project (http://www.rtems.org/) +# Copyright 2022 Joel Sherrill (j...@rtems.org) +# All rights reserved. +# +# This file is part of the RTEMS Tools package in 'rtems-bsp-builder'. +# +# Permission to use, copy, modify, and/or distribute this software for any +# purpose with or without fee is hereby granted, provided that the above +# copyright notice and this permission notice appear in all copies. +# +# THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES +# WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF +# MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR +# ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES +# WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN +# ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF +# OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + +# +# Microblaze Architecture +# +[microblaze] +bsps = kcu105, kcu105_qemu +exclude = smp -- 2.24.4 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 2/5] rtems-bsps-riscv.ini: Add missing BSPs
frdme310arty, griscv, grv32i, grv32im, grv32imac, grv32imafdc, rv32iac, rv32i, rv32imac, rv32imafc, rv32imafdc, rv32imafd, rv32im --- config/rtems-bsps-riscv.ini | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/config/rtems-bsps-riscv.ini b/config/rtems-bsps-riscv.ini index da3a5a4..804245e 100644 --- a/config/rtems-bsps-riscv.ini +++ b/config/rtems-bsps-riscv.ini @@ -21,7 +21,9 @@ # RISC-V Architecture # [riscv] -bsps = rv32iac, rv32i, rv32imac, rv32imafc, rv32imafdc, rv32imafd, rv32im, +bsps = frdme310arty, + griscv, grv32i, grv32im, grv32imac, grv32imafdc, + rv32iac, rv32i, rv32imac, rv32imafc, rv32imafdc, rv32imafd, rv32im, rv64imac, rv64imac_medany, rv64imafdc, rv64imafd, rv64imafdc_medany, rv64imafd_medany exclude-smp = rv32i, rv32im -- 2.24.4 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 3/5] rtems-bsps-aarch64.ini: New file
--- config/rtems-bsps-aarch64.ini | 31 +++ 1 file changed, 31 insertions(+) create mode 100644 config/rtems-bsps-aarch64.ini diff --git a/config/rtems-bsps-aarch64.ini b/config/rtems-bsps-aarch64.ini new file mode 100644 index 000..110ab17 --- /dev/null +++ b/config/rtems-bsps-aarch64.ini @@ -0,0 +1,31 @@ +# +# RTEMS Tools Project (http://www.rtems.org/) +# Copyright 2021 Joel Sherrill (j...@rtems.org) +# All rights reserved. +# +# This file is part of the RTEMS Tools package in 'rtems-bsp-builder'. +# +# Permission to use, copy, modify, and/or distribute this software for any +# purpose with or without fee is hereby granted, provided that the above +# copyright notice and this permission notice appear in all copies. +# +# THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES +# WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF +# MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR +# ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES +# WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN +# ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF +# OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + +# +# AArch64 Architecture +# +[aarch64] +bsps = a53_ilp32_qemu, a53_lp64_qemu, + a72_ilp32_qemu, a72_lp64_qemu, + xilinx_versal_ilp32_qemu, xilinx_versal_ilp32_vck190, + xilinx_versal_lp64_qemu, xilinx_versal_lp64_vck190, + xilinx_zynqmp_ilp32_qemu, xilinx_zynqmp_ilp32_zu3eg, + xilinx_zynqmp_lp64_qemu, xilinx_zynqmp_lp64_zu3eg +exclude-smp = a53_ilp32_qemu, a53_lp64_qemu, + a72_ilp32_qemu, a72_lp64_qemu, -- 2.24.4 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 0/5] Update rtems-bsp-builder to match RTEMS master
The set of ini files for rtems-bsp-builder was out of sync with the set of architectures and BSPs currently in RTEMS. This patch set adds three architectures and a handful of BSPs. Build results with these patches are at: https://lists.rtems.org/pipermail/build/2022-January/031032.html --joel Joel Sherrill (5): rtems-bsps-arm.ini: Add missing BSPs rtems-bsps-riscv.ini: Add missing BSPs rtems-bsps-aarch64.ini: New file rtems-bsps-microblaze.ini: New file rtems-bsps-x86_64.ini: New file config/rtems-bsps-aarch64.ini| 31 +++ config/rtems-bsps-arm.ini| 16 +--- config/rtems-bsps-microblaze.ini | 25 + config/rtems-bsps-riscv.ini | 4 +++- config/rtems-bsps-x86_64.ini | 25 + 5 files changed, 97 insertions(+), 4 deletions(-) create mode 100644 config/rtems-bsps-aarch64.ini create mode 100644 config/rtems-bsps-microblaze.ini create mode 100644 config/rtems-bsps-x86_64.ini -- 2.24.4 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 1/5] rtems-bsps-arm.ini: Add missing BSPs
fvp_cortex_r52, imxrt1052, nucleo-h743zi, stm32h7, xen_virtual, xilinx_zynqmp_ultra96 --- config/rtems-bsps-arm.ini | 16 +--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/config/rtems-bsps-arm.ini b/config/rtems-bsps-arm.ini index 02b54e7..b9a940d 100644 --- a/config/rtems-bsps-arm.ini +++ b/config/rtems-bsps-arm.ini @@ -26,9 +26,11 @@ bsps = altcycv_devkit, beagleboardorig, beagleboardxm, beagleboneblack, beaglebonewhite, csb336, csb337, csb637, edb7312, + fvp_cortex_r52, kit637_v6, gumstix, imx7, + imxrt1052, lm3s3749, lm3s6965, lm3s6965_qemu, lm4f120, lpc1768_mbed, lpc1768_mbed_ahb_ram, lpc1768_mbed_ahb_ram_eth, lpc17xx_ea_ram, lpc17xx_ea_rom_int, lpc17xx_plx800_ram, @@ -37,22 +39,27 @@ bsps = altcycv_devkit, lpc24xx_plx800_ram, lpc24xx_plx800_rom_int, lpc40xx_ea_ram, lpc40xx_ea_rom_int, lpc32xx_mzx, lpc32xx_mzx_stage_1, lpc32xx_mzx_stage_2, lpc32xx_phycore, + nucleo-h743zi, raspberrypi, raspberrypi2, realview_pbx_a9_qemu, rtl22xx, rtl22xx_t, smdk2410, - stm32f105rc, stm32f4, + stm32f105rc, stm32f4, stm32h7, tms570ls3137_hdk, tms570ls3137_hdk_intram, tms570ls3137_hdk_sdram, tms570ls3137_hdk_with_loader, + xen_virtual, xilinx_zynq_zc702, xilinx_zynq_zc706, xilinx_zynq_zedboard, - xilinx_zynq_a9_qemu + xilinx_zynq_a9_qemu, + xilinx_zynqmp_ultra96 exclude-smp = atsamv, beagleboardorig, beagleboardxm, beagleboneblack, beaglebonewhite, csb336, csb337, csb637, edb7312, + fvp_cortex_r52, kit637_v6, gumstix, + imxrt1052, lm3s3749, lm3s6965, lm3s6965_qemu, lm4f120, lpc1768_mbed, lpc1768_mbed_ahb_ram, lpc1768_mbed_ahb_ram_eth, lpc17xx_ea_ram, lpc17xx_ea_rom_int, lpc17xx_plx800_ram, @@ -61,11 +68,14 @@ exclude-smp = atsamv, lpc24xx_plx800_ram, lpc24xx_plx800_rom_int, lpc40xx_ea_ram, lpc40xx_ea_rom_int, lpc32xx_mzx, lpc32xx_mzx_stage_1, lpc32xx_mzx_stage_2, lpc32xx_phycore, + nucleo-h743zi, raspberrypi, raspberrypi2, rtl22xx, rtl22xx_t, smdk2410, - stm32f105rc, stm32f4, + stm32f105rc, stm32f4, stm32h7, tms570ls3137_hdk, tms570ls3137_hdk_intram, tms570ls3137_hdk_sdram, tms570ls3137_hdk_with_loader + xen_virtual, + xilinx_zynqmp_ultra96 exclude-network = altcycv_devkit, realview_pbx_a9_qemu -- 2.24.4 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-tools] tiers: Add AArch64 to tier 1
On 1/19/2022 09:41, Kinsey Moore wrote: On 1/19/2022 09:13, Sebastian Huber wrote: On 19/01/2022 15:42, Kinsey Moore wrote: On 1/18/2022 10:23, Sebastian Huber wrote: On 18/01/2022 17:19, Kinsey Moore wrote: Hardware test results have recently been posted for AArch64. Closes #4581 It would be nice if you could run also the new validation tests on this branch: https://git.rtems.org/sebh/rtems.git/log/?h=validation It looks like when running with that branch, tar02 and psxftw01 are consistently failing with a PC in the stack since sometime after 68b0db358c81a7f770a44ceb819197bdc320bc99 which is what the other test run used. I'll have to track that down. Thanks for testing. It would be good to do a git bisect to figure out the problem. I'm currently doing that now and should have it narrowed down soon. It looks like this was actually just a bad partial build and a full rebuild resolved the two failures. Kinsey ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Malloc tests
On Fri, Jan 7, 2022 at 8:25 PM zack leung wrote:
>
> I think that the malloc tests is calculated differently than alloc_size+
> allocsize mod it looks like this
> *alloc_size = (uintptr_t) next_block + HEAP_ALLOC_BONUS - alloc_begin;
> when i run the comparison i get 8 (with heap alignment) and the function
> gives me 12.
> is the heap alloc bonus part of the current block?
The allocation extra is intended to ensure the block is in even
"pages". The size
of a page is specified when the heap instance is created but it is
CPU_HEAP_ALIGMENT for this specific heap.
If CPU_HEAP_ALIGMENT is 16 and you malloc(13), then the block
returned to you is really 16 bytes in size and you should only expect 13 to
be there.
The "bonus" will be between 0 and CPU_HEAP_ALIGNMENT - 1.
But the allocated size adjusted up to the next even multiple of
CPU_HEAP_ALIGNMENT should be the usable size.
--joel
>
> On Thu, 6 Jan 2022 at 21:28, Joel Sherrill wrote:
>>
>> On Thu, Jan 6, 2022 at 2:55 PM Gedare Bloom wrote:
>> >
>> > On Tue, Jan 4, 2022 at 6:10 PM zack leung wrote:
>> > >
>> > > Helllo ,
>> > > I'm working on a patch for malloc_get_usable size right now so far i have
>> > > this test case for malloc, I just make sure that the value is null and i
>> > > just malloc an int and then i make a call to the function malloc_usable
>> > > size and then i compare it like this.
>> > >
>> > > static void test_malloc_usablesize( void ){
>> > >int * a = malloc(sizeof(int));
>> > >rtems_test_assert((int) malloc_usable_size(a) == 12);
>> > >free (a);
>> > >
>> > >int * b = NULL;
>> > >rtems_test_assert( 0 == malloc_usable_size(b));
>> > >free(b);
>> > >
>> > >
>> > > }
>> > > Is there a good amount of storage to allocate? Also I heard someone made
>> > > a
>> >
>> > I think that this test case is quite brittle. The "usable size" will
>> > depend on the implementation details of malloc, and the conditions of
>> > the heap when the allocation request gets made. I don't have better
>> > ideas however for how to test the correctness of the usable_size
>> > function. Maybe there are certain sequences of malloc/free calls that
>> > can be relied upon to give you deterministic sizes of allocations?
>>
>> My suggestion in private chat was that you can depend on the
>> malloc heap being initialized with CPU_HEAP_ALIGNMENT. That's
>> what that macro is specifically for. It is used in
>> include/rtems/score/wkspaceinit*.h
>> and has been since the dawn of time.
>>
>> Then the size for a valid pointer from malloc() should be between
>> the allocated size and the next number on a CPU_HEAP_ALIGNMENT
>> boundary. I think the exact number is actually something like this:
>>
>> expected = alloc_size;
>> mod = alloc_size % CPU_HEAP_ALIGMENT;
>> expected += mod;
>>
>> Adding a helper function in the test to compute the expected
>> size allocated and validate the return may be wise if multiple
>> size allocations are going to be tested.
>>
>>
>> > > formatter for rtems source files. Can someone tell me how to use it and
>> > > if
>> > > it is on the main branch?
>> >
>> > This was part of a gsoc project last year. We haven't quite made the
>> > switch over to it and the associated coding style I think, but you can
>> > find the code via
>> > https://devel.rtems.org/wiki/GSoC/2021#StudentsSummerofCodeTrackingTable
>> > the student was Meh Mbeh Ida Delphine
>> >
>> >
>> > > ___
>> > > devel mailing list
>> > > devel@rtems.org
>> > > http://lists.rtems.org/mailman/listinfo/devel
>> > ___
>> > devel mailing list
>> > devel@rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-tools] tiers: Add AArch64 to tier 1
On 19/01/2022 16:41, Kinsey Moore wrote: ts-performance-no-clock-0 gets test-too-long, but passes with modified tester timeouts and all the other validation tests pass just fine. Great, did the ts-validation-intr test run also? It fails on my Qemu simulator. Yes, that test was included in the validation tests and passed. This is nice, the new validation tests run now successfully on at least one hardware target of the arm, aarch64, powerpc, and sparc architectures. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-tools] tiers: Add AArch64 to tier 1
On 1/19/2022 09:13, Sebastian Huber wrote: On 19/01/2022 15:42, Kinsey Moore wrote: On 1/18/2022 10:23, Sebastian Huber wrote: On 18/01/2022 17:19, Kinsey Moore wrote: Hardware test results have recently been posted for AArch64. Closes #4581 It would be nice if you could run also the new validation tests on this branch: https://git.rtems.org/sebh/rtems.git/log/?h=validation It looks like when running with that branch, tar02 and psxftw01 are consistently failing with a PC in the stack since sometime after 68b0db358c81a7f770a44ceb819197bdc320bc99 which is what the other test run used. I'll have to track that down. Thanks for testing. It would be good to do a git bisect to figure out the problem. I'm currently doing that now and should have it narrowed down soon. ts-performance-no-clock-0 gets test-too-long, but passes with modified tester timeouts and all the other validation tests pass just fine. Great, did the ts-validation-intr test run also? It fails on my Qemu simulator. Yes, that test was included in the validation tests and passed. I think the issue with ts-performance-no-clock-0 is the size of the data cache. However, the data cache is an important factor for the performance data, so there is no way around this. Good to know. We may want to bump up the default test-too-long limit if this is going to be the case. Kinsey ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-tools] tiers: Add AArch64 to tier 1
On 19/01/2022 15:42, Kinsey Moore wrote: On 1/18/2022 10:23, Sebastian Huber wrote: On 18/01/2022 17:19, Kinsey Moore wrote: Hardware test results have recently been posted for AArch64. Closes #4581 It would be nice if you could run also the new validation tests on this branch: https://git.rtems.org/sebh/rtems.git/log/?h=validation It looks like when running with that branch, tar02 and psxftw01 are consistently failing with a PC in the stack since sometime after 68b0db358c81a7f770a44ceb819197bdc320bc99 which is what the other test run used. I'll have to track that down. Thanks for testing. It would be good to do a git bisect to figure out the problem. ts-performance-no-clock-0 gets test-too-long, but passes with modified tester timeouts and all the other validation tests pass just fine. Great, did the ts-validation-intr test run also? It fails on my Qemu simulator. I think the issue with ts-performance-no-clock-0 is the size of the data cache. However, the data cache is an important factor for the performance data, so there is no way around this. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-tools] tiers: Add AArch64 to tier 1
On 1/18/2022 10:23, Sebastian Huber wrote: On 18/01/2022 17:19, Kinsey Moore wrote: Hardware test results have recently been posted for AArch64. Closes #4581 It would be nice if you could run also the new validation tests on this branch: https://git.rtems.org/sebh/rtems.git/log/?h=validation It looks like when running with that branch, tar02 and psxftw01 are consistently failing with a PC in the stack since sometime after 68b0db358c81a7f770a44ceb819197bdc320bc99 which is what the other test run used. I'll have to track that down. ts-performance-no-clock-0 gets test-too-long, but passes with modified tester timeouts and all the other validation tests pass just fine. Kinsey ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
