[PATCH 1/2] spec/aarch64: Ensure that libbsd can build properly

2020-11-16 Thread Kinsey Moore 
These files are required for libbsd to build against the AArch64 A53
BSPs.
---
 spec/build/bsps/aarch64/grp.yml | 4 
 1 file changed, 4 insertions(+)

diff --git a/spec/build/bsps/aarch64/grp.yml b/spec/build/bsps/aarch64/grp.yml
index 4b5f998a12..1b8dc1c629 100644
--- a/spec/build/bsps/aarch64/grp.yml
+++ b/spec/build/bsps/aarch64/grp.yml
@@ -5,6 +5,10 @@ copyrights:
 enabled-by: true
 includes: []
 install:
+- destination: ${BSP_INCLUDEDIR}/bsp
+  source:
+  - bsps/aarch64/include/bsp/linker-symbols.h
+  - bsps/aarch64/include/bsp/start.h
 - destination: ${BSP_INCLUDEDIR}/dev/clock
   source:
   - bsps/include/dev/clock/arm-generic-timer.h
-- 
2.20.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 2/2] spec/aarch64: Only apply SUBALIGN(4) to ILP32

2020-11-16 Thread Kinsey Moore 
The SUBALIGN(4) required on rtemsroset and rtemsrwset for ILP32 builds
was previously present on LP64 builds and causes no issues within RTEMS,
but causes relocation/alignment issues when building libbsd. This
restricts those alignment changes to ILP32 builds.
---
 bsps/aarch64/shared/start/linkcmds.base| 6 --
 spec/build/bsps/aarch64/a53/linkcmds_ilp32.yml | 1 +
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/bsps/aarch64/shared/start/linkcmds.base 
b/bsps/aarch64/shared/start/linkcmds.base
index 450c3ba2a9..4bf5b10746 100644
--- a/bsps/aarch64/shared/start/linkcmds.base
+++ b/bsps/aarch64/shared/start/linkcmds.base
@@ -43,6 +43,8 @@ STARTUP (start.o)
 
 bsp_stack_align = DEFINED (bsp_stack_align) ? bsp_stack_align : 16;
 
+bsp_set_align = DEFINED (bsp_set_align) ? bsp_set_align : 8;
+
 bsp_stack_exception_size = DEFINED (bsp_stack_exception_size) ? 
bsp_stack_exception_size : 0;
 bsp_stack_exception_size = ALIGN (bsp_stack_exception_size, bsp_stack_align);
 
@@ -243,7 +245,7 @@ SECTIONS {
.got : ALIGN_WITH_INPUT {
*(.got.plt) *(.igot.plt) *(.got) *(.igot)
} > REGION_RODATA AT > REGION_RODATA_LOAD
-   .rtemsroset : ALIGN_WITH_INPUT SUBALIGN(4) {
+   .rtemsroset : ALIGN_WITH_INPUT SUBALIGN(bsp_set_align) {
/* Special FreeBSD linker set sections */
__start_set_sysctl_set = .;
*(set_sysctl_*);
@@ -297,7 +299,7 @@ SECTIONS {
.data1 : ALIGN_WITH_INPUT {
*(.data1)
} > REGION_DATA AT > REGION_DATA_LOAD
-   .rtemsrwset : ALIGN_WITH_INPUT SUBALIGN(4) {
+   .rtemsrwset : ALIGN_WITH_INPUT SUBALIGN(bsp_set_align) {
KEEP (*(SORT(.rtemsrwset.*)))
bsp_section_data_end = .;
} > REGION_DATA AT > REGION_DATA_LOAD
diff --git a/spec/build/bsps/aarch64/a53/linkcmds_ilp32.yml 
b/spec/build/bsps/aarch64/a53/linkcmds_ilp32.yml
index ed585f1950..085c9c707c 100644
--- a/spec/build/bsps/aarch64/a53/linkcmds_ilp32.yml
+++ b/spec/build/bsps/aarch64/a53/linkcmds_ilp32.yml
@@ -60,6 +60,7 @@ content: |
 
   OUTPUT_FORMAT ("elf32-littleaarch64")
   OUTPUT_ARCH (aarch64:ilp32)
+  bsp_set_align = 4;
 
   INCLUDE linkcmds.base
 copyrights:
-- 
2.20.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/2] spec/aarch64: Ensure that libbsd can build properly

2020-11-16 Thread Sebastian Huber 

On 16/11/2020 14:15, Kinsey Moore wrote:


These files are required for libbsd to build against the AArch64 A53
BSPs.

Looks good.

--
embedded brains GmbH
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
PGP: Public key available on request.

embedded brains GmbH
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 2/2] spec/aarch64: Only apply SUBALIGN(4) to ILP32

2020-11-16 Thread Sebastian Huber 

On 16/11/2020 14:15, Kinsey Moore wrote:


The SUBALIGN(4) required on rtemsroset and rtemsrwset for ILP32 builds
was previously present on LP64 builds and causes no issues within RTEMS,
but causes relocation/alignment issues when building libbsd. This
restricts those alignment changes to ILP32 builds.


Please check it in if you think it is necessary.

What troubles me a bit is that these SUBALIGN() stuff is present at all.

It also troubles me that the splinkersets01 test case didn't catch this 
problem.


--
embedded brains GmbH
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
PGP: Public key available on request.

embedded brains GmbH
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 2/2] spec/aarch64: Only apply SUBALIGN(4) to ILP32

2020-11-16 Thread Kinsey Moore 
-Original Message-
From: Sebastian Huber  
Sent: Monday, November 16, 2020 07:35
To: Kinsey Moore ; devel@rtems.org
Subject: Re: [PATCH 2/2] spec/aarch64: Only apply SUBALIGN(4) to ILP32

>On 16/11/2020 14:15, Kinsey Moore wrote:
>
>> The SUBALIGN(4) required on rtemsroset and rtemsrwset for ILP32 builds 
>> was previously present on LP64 builds and causes no issues within 
>> RTEMS, but causes relocation/alignment issues when building libbsd. 
>> This restricts those alignment changes to ILP32 builds.
>
> Please check it in if you think it is necessary.
>
> What troubles me a bit is that these SUBALIGN() stuff is present at all.
>
> It also troubles me that the splinkersets01 test case didn't catch this 
> problem.

That test was what originally caught the problem during development of the A53 
BSP. This patch isn't the addition of a fix for the alignment problems, it's an 
adjustment of the original fix to be compatible with libbsd's use of 
rtemsroset/rtemsrwset linker sections.

Kinsey
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/2] spec/aarch64: Only apply SUBALIGN(4) to ILP32

2020-11-16 Thread Sebastian Huber 

On 16/11/2020 14:40, Kinsey Moore wrote:


-Original Message-
From: Sebastian Huber  
Sent: Monday, November 16, 2020 07:35

To: Kinsey Moore;devel@rtems.org
Subject: Re: [PATCH 2/2] spec/aarch64: Only apply SUBALIGN(4) to ILP32


On 16/11/2020 14:15, Kinsey Moore wrote:


The SUBALIGN(4) required on rtemsroset and rtemsrwset for ILP32 builds
was previously present on LP64 builds and causes no issues within
RTEMS, but causes relocation/alignment issues when building libbsd.
This restricts those alignment changes to ILP32 builds.

Please check it in if you think it is necessary.

What troubles me a bit is that these SUBALIGN() stuff is present at all.

It also troubles me that the splinkersets01 test case didn't catch this problem.

That test was what originally caught the problem during development of the A53 
BSP. This patch isn't the addition of a fix for the alignment problems, it's an 
adjustment of the original fix to be compatible with libbsd's use of 
rtemsroset/rtemsrwset linker sections.
So, this SUBALIGN() is just a workaround for some other problem? It 
would be good to document this known issue somewhere, for example a 
ticket. Is this an upstream problem in GCC or the GNU linker?


--
embedded brains GmbH
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
PGP: Public key available on request.

embedded brains GmbH
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 2/2] spec/aarch64: Only apply SUBALIGN(4) to ILP32

2020-11-16 Thread Kinsey Moore 
-Original Message-
From: Sebastian Huber  
Sent: Monday, November 16, 2020 07:44
To: Kinsey Moore ; devel@rtems.org
Subject: Re: [PATCH 2/2] spec/aarch64: Only apply SUBALIGN(4) to ILP32

> On 16/11/2020 14:40, Kinsey Moore wrote:
>
>> -Original Message-
>> From: Sebastian Huber
>> Sent: Monday, November 16, 2020 07:35
>> To: Kinsey Moore;devel@rtems.org
>> Subject: Re: [PATCH 2/2] spec/aarch64: Only apply SUBALIGN(4) to ILP32
>>
>>> On 16/11/2020 14:15, Kinsey Moore wrote:
>>>
 The SUBALIGN(4) required on rtemsroset and rtemsrwset for ILP32 
 builds was previously present on LP64 builds and causes no issues 
 within RTEMS, but causes relocation/alignment issues when building libbsd.
 This restricts those alignment changes to ILP32 builds.
>>> Please check it in if you think it is necessary.
>>>
>>> What troubles me a bit is that these SUBALIGN() stuff is present at all.
>>>
>>> It also troubles me that the splinkersets01 test case didn't catch this 
>>> problem.
>> That test was what originally caught the problem during development of the 
>> A53 BSP. This patch isn't the addition of a fix for the alignment problems, 
>> it's an adjustment of the original fix to be compatible with libbsd's use of 
>> rtemsroset/rtemsrwset linker sections.
> So, this SUBALIGN() is just a workaround for some other problem? It would be 
> good to document this known issue somewhere, for example a ticket. Is this an 
> upstream problem in GCC or the GNU linker?

Yes, SUBALIGN() is the workaround for ILP32 defaulting to 8 byte alignment in 
the rtemsroset and rtemsrwset linker sections because RTEMS expects them to 
default to 4 byte alignment when using 4 byte pointers. I suspect it's an issue 
in the GNU linker, but I haven't had a chance to track down the root cause. 
This patch is necessary because while RTEMS works fine with 4 byte alignment in 
those sections in the context of 8 byte pointers, libbsd puts things other than 
pointers in those sections and requires the alignment of those sections to 
exactly match the pointer size.

I'll open a ticket for documentation purposes.

Kinsey
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Update newlib in RTEMS mirror and bump tools

2020-11-16 Thread Joel Sherrill 
Hi

I pushed a fix which needs to be in the 5 and 6 tools.

https://devel.rtems.org/ticket/4174

Sebastian.. you mentioned having a script to update the tool RSB recipes.
Could you force an update on the github tools mirror and bump the newlib in
all three please?

Thanks.

--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Update newlib in RTEMS mirror and bump tools

2020-11-16 Thread Sebastian Huber 

Hello Joel,

On 16/11/2020 15:21, Joel Sherrill wrote:

Hi

I pushed a fix which needs to be in the 5 and 6 tools.

https://devel.rtems.org/ticket/4174 

Sebastian.. you mentioned having a script to update the tool RSB 
recipes. Could you force an update on the github tools mirror and bump 
the newlib in all three please?


I have a script to update the 6 and 7 build sets. I have a patch for 
Newlib under review (sent to the list today). I will update the Newlib 
version once it is integrated if this is all right for you.


For RTEMS 5, I think we should only back port this particular fix and 
not do an overall Newlib update.


--
embedded brains GmbH
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
PGP: Public key available on request.

embedded brains GmbH
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: Update newlib in RTEMS mirror and bump tools

2020-11-16 Thread Joel Sherrill 
On Mon, Nov 16, 2020, 8:25 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Joel,
>
> On 16/11/2020 15:21, Joel Sherrill wrote:
> > Hi
> >
> > I pushed a fix which needs to be in the 5 and 6 tools.
> >
> > https://devel.rtems.org/ticket/4174  >
> >
> > Sebastian.. you mentioned having a script to update the tool RSB
> > recipes. Could you force an update on the github tools mirror and bump
> > the newlib in all three please?
>
> I have a script to update the 6 and 7 build sets. I have a patch for
> Newlib under review (sent to the list today). I will update the Newlib
> version once it is integrated if this is all right for you
>

No problem.


> For RTEMS 5, I think we should only back port this particular fix and
> not do an overall Newlib update.
>

What changes are.you concerned about taking?

What other patches would we need to backport?

--joel

>
> --
> embedded brains GmbH
> 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
> PGP: Public key available on request.
>
> embedded brains GmbH
> 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: Update newlib in RTEMS mirror and bump tools

2020-11-16 Thread Sebastian Huber 

On 16/11/2020 15:33, Joel Sherrill wrote:


For RTEMS 5, I think we should only back port this particular fix and
not do an overall Newlib update.


What changes are.you concerned about taking?
I recently updated the . I am not sure if you have to 
re-compile everything after the changes. I think we require binary 
compatibility within a release branch?


--
embedded brains GmbH
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
PGP: Public key available on request.

embedded brains GmbH
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 v2 1/2] bsps/shared/ofw: Implement RTEMS OFW interface

2020-11-16 Thread Christian Mauderer 
Hello,

sorry for the long delay. I tested it on xilinx-zynq-a9-qemu (which
doesn't have a FDT) and the test seems to run fine. So I'm OK with the
patches. If no one objects in the next two days, I'll commit them.

Best regards

Christian

On 03/11/2020 19:18, G S Niteesh Babu wrote:
> RTEMS OFW is a FDT only implementation of the OpenFirmWare
> interface. This API is created to be compatible with FreeBSD
> OpenFirmWare interface. The main intention is to make
> porting of FreeBSD drivers to RTEMS easier.
> 
> Most functions implemented have an direct one-one mapping
> with the original OFW API and some extra auxiliary functions
> were implemented to make working with device trees easier in
> RTEMS.
> 
> Update #3784
> ---
>  bsps/include/ofw/ofw.h| 548 +++
>  bsps/include/ofw/ofw_compat.h |  74 
>  bsps/shared/ofw/ofw.c | 682 ++
>  spec/build/bsps/obj.yml   |   5 +
>  4 files changed, 1309 insertions(+)
>  create mode 100644 bsps/include/ofw/ofw.h
>  create mode 100644 bsps/include/ofw/ofw_compat.h
>  create mode 100644 bsps/shared/ofw/ofw.c
> 
> diff --git a/bsps/include/ofw/ofw.h b/bsps/include/ofw/ofw.h
> new file mode 100644
> index 00..4c402671a4
> --- /dev/null
> +++ b/bsps/include/ofw/ofw.h
> @@ -0,0 +1,548 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/**
> + * @file
> + *
> + * @ingroup ofw
> + *
> + * RTEMS FDT implementation of OpenFirmWare Interface.
> + *
> + * RTEMS OFW is a FDT only implementation of the OpenFirmWare interface.
> + * This API is created to be compatible with FreeBSD OpenFirmWare interface.
> + * The main intention is to make porting of FreeBSD drivers to RTEMS easier.
> + */
> +
> +/*
> + * Copyright (C) 2020 Niteesh Babu G S 
> + *
> + * 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 COPYRIGHT HOLDERS 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 COPYRIGHT OWNER 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.
> + */
> +
> +#ifndef _OFW_H
> +#define _OFW_H
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +#include 
> +#include 
> +#include 
> +
> +/**
> + * Represents a node in the device tree. The offset from fdtp to node is used
> + * instead of fdt offset to make sure this is compatible with OF interface in
> + * FreeBSD.
> + */
> +typedef uint32_t  phandle_t;
> +/**
> + * Represents the effective phandle of the node.
> + */
> +typedef uint32_t  ihandle_t;
> +/**
> + * Represents the data type of the buffer.
> + */
> +typedef uint32_t  pcell_t;
> +
> +/**
> + * @struct rtems_ofw_memory_area
> + *
> + * This is used to represent elements(FDT properties) that define
> + * region of memory address.
> + */
> +typedef struct {
> +  /** The start address of the memory region. */
> +  uint32_t start;
> +  /** The size of the memory region. */
> +  uint32_t size;
> +} rtems_ofw_memory_area;
> +
> +/**
> + * @struct rtems_ofw_ranges
> + *
> + * This is used to represent the ranges property in the device tree.
> + */
> +typedef struct {
> +  /** The physical address within the child bus address space */
> +  uint32_t child_bus;
> +  /** The physical address within the parent bus address space */
> +  uint32_t parent_bus;
> +  /** The size of the range in the child’s address space */
> +  uint32_t size;
> +} rtems_ofw_ranges;
> +
> +/**
> + * @brief Gets the node that is next to @a node.
> + *
> + * @param[in] node Node offset
> + *
> + * @retval Peer node offset Successful operation.
> + * @retval 0 No peer node or invalid node handle
> + */
> +phandle_t rtems_ofw_peer(
> +  phandle_t   node
> +);
> +
> +/**
> + * @brief Gets the node that is the child of @a node.
> + *
> + * @param[in] node Node offset
> + *
> + * @retval child node offset Successful operation.
> + * @retval 0 No child node or invalid node handle

Re: Proposal for hardware configuration dependent performance limits

2020-11-16 Thread Chris Johns 


On 16/11/20 5:40 pm, Sebastian Huber wrote:
> On 16/11/2020 00:33, Chris Johns wrote:
> 
> In the proposal, limits are specified like this:
>
>
> limits:
>  sparc/gr712rc:
>    DirtyCache:
>  max-upper-bound: 0.05
>  mean-upper-bound: 0.05
>    FullCache:
>  max-upper-bound: 0.05
>  mean-upper-bound: 0.05
>    HotCache:
>  max-upper-bound: 0.05
>  mean-upper-bound: 0.05
>    Load/1:
>  max-upper-bound: 0.1
>  mean-upper-bound: 0.1
>    Load/2:
>  max-upper-bound: 0.1
>  mean-upper-bound: 0.1
>    Load/3:
>  max-upper-bound: 0.1
>  mean-upper-bound: 0.1
>    Load/4:
>  max-upper-bound: 0.1
>  mean-upper-bound: 0.1
>
> This neglects that the limits are subject to a board configuration. One
> approach to cover this is the addition of a new BSP provided function:
>
> const char *rtems_get_hardware_performance_hash();
>
> The BSP feeds all performance related data into a hash function and
 "data" here means configuration?
>>> Yes, hardware configuration.
>> Why not make these values part of the BSP configuration? The defaults for the
>> BSP can have a set of suitable values. Different boards have different
>> configurations to match and a separate kernel build.
>>
> This doesn't work on BSPs which support configuration via a hardware
> enumeration, boot loader settings, or device trees. Also changes in the BSP
> options have no influence on the BSP name. Not only BSP configuration 
> influence
> performance, the CPU options play a role too, for example RTEMS_SMP. In order 
> to
> compare performance values over time we have to obtain the values under the 
> same
> conditions.

Maybe I am not understanding the context.

A BSP, which ever one, has a set of options that configure it. An example is the
xilinx_zynq_zc702 and the `ZYNQ_RAM_LENGTH = 0x4000`. If I have 2 Zynq
circuits one with 256M and one with 1G I need to build and maintain 2 RTEMS
builds and from a purists point of view I need to maintain 2 builds of the exact
same application.

I asked about the fixed memory and your answer was to use the BSP options, the
size is fixed in the linker command files via the BSP option. That is what I
have done.

I would expect there exists a set of values for the xilinx_zynq_zc702 with no
SMP and with SMP as this BSP supports SMP. Those values would match all the
other settings for the BSP such as ZYNQ_CLOCK_CPU_1X, BSP_ARM_A9MPCORE_PERIPHCLK
etc. If my clock is different (and they are) I would need to supply a suitable
set of performance values if I wanted to pass those tests.

I am not questioning the need for the values or the tests. I am suggesting the
values form part of the BSP settings so a user can adjust them to suite their
specific set up in the same way they adjust other BSP settings. I do not think
we should attempt to hold or manage an endless sets of possible values and I do
not see the need for complex encapsulation methods such as a base64 hashes. The
systems we interact with are too complex and list is endless.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 7/8] validation/ts-performance-0: Add test suite

2020-11-16 Thread Chris Johns 


On 16/11/20 5:48 pm, Sebastian Huber wrote:
> 
> On 16/11/2020 00:53, Chris Johns wrote:
>> On 13/11/20 9:07 pm, Sebastian Huber wrote:
>>> Share a default test suite with ts-validation-0.
>>> ---
>>>   spec/build/testsuites/validation/grp.yml  |   2 +
>>>   .../testsuites/validation/performance-0.yml   |  19 ++
>>>   testsuites/validation/ts-default.h    | 237 ++
>>>   testsuites/validation/ts-performance-0.c  |  74 ++
>>>   testsuites/validation/ts-validation-0.c   | 155 +---
>>>   5 files changed, 333 insertions(+), 154 deletions(-)
>>>   create mode 100644 spec/build/testsuites/validation/performance-0.yml
>>>   create mode 100644 testsuites/validation/ts-default.h
>>>   create mode 100644 testsuites/validation/ts-performance-0.c
>>>
>>> diff --git a/spec/build/testsuites/validation/grp.yml
>>> b/spec/build/testsuites/validation/grp.yml
>>> index 390fb48803..1a903a4198 100644
>>> --- a/spec/build/testsuites/validation/grp.yml
>>> +++ b/spec/build/testsuites/validation/grp.yml
>>> @@ -10,6 +10,8 @@ includes:
>>>   install: []
>>>   ldflags: []
>>>   links:
>>> +- role: build-dependency
>>> +  uid: performance-0
>>>   - role: build-dependency
>>>     uid: validation-0
>>>   type: build
>>> diff --git a/spec/build/testsuites/validation/performance-0.yml
>>> b/spec/build/testsuites/validation/performance-0.yml
>>> new file mode 100644
>>> index 00..ba14066dd3
>>> --- /dev/null
>>> +++ b/spec/build/testsuites/validation/performance-0.yml
>>> @@ -0,0 +1,19 @@
>>> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
>>> +build-type: test-program
>>> +cflags: []
>>> +copyrights:
>>> +- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
>>> +cppflags: []
>>> +cxxflags: []
>>> +enabled-by: true
>>> +features: c cprogram
>>> +includes: []
>>> +ldflags: []
>>> +links: []
>>> +source:
>>> +- testsuites/validation/ts-performance-0.c
>>> +stlib: []
>>> +target: testsuites/validation/ts-performance-0.exe
>>> +type: build
>>> +use-after: []
>>> +use-before: []
>>> diff --git a/testsuites/validation/ts-default.h
>>> b/testsuites/validation/ts-default.h
>> Who's defaults are these?
> This is an implementation of the default validation test suite runner and
> application configuration. The goal is to use it for a wide range of test 
> cases.

OK.

>>> new file mode 100644
>>> index 00..0f7db65a8e
>>> --- /dev/null
>>> +++ b/testsuites/validation/ts-default.h
>>> @@ -0,0 +1,237 @@
>>> +/* SPDX-License-Identifier: BSD-2-Clause */
>>> +
>>> +/**
>>> + * @file
>>> + *
>>> + * @brief This header file provides the default validation test suite 
>>> runner
>>> + *   and application configuration.
>>> + */
>>> [...]
>>> +#define CONFIGURE_SCHEDULER_EDF_SMP
>>> +
>>> +#include 
>>> +
>>> +RTEMS_SCHEDULER_EDF_SMP(a);
>>> +
>>> +RTEMS_SCHEDULER_EDF_SMP(b);
>>> +
>>> +RTEMS_SCHEDULER_EDF_SMP(c);
>>> +
>>> +#define CONFIGURE_SCHEDULER_TABLE_ENTRIES \
>>> +  RTEMS_SCHEDULER_TABLE_EDF_SMP(a, rtems_build_name('A', ' ', ' ', ' ')), \
>>> +  RTEMS_SCHEDULER_TABLE_EDF_SMP(b, rtems_build_name('B', ' ', ' ', ' ')), \
>>> +  RTEMS_SCHEDULER_TABLE_EDF_SMP(c, rtems_build_name('C', ' ', ' ', ' '))
>>> +
>>> +#define CONFIGURE_SCHEDULER_ASSIGNMENTS \
>>> +  RTEMS_SCHEDULER_ASSIGN(0, RTEMS_SCHEDULER_ASSIGN_PROCESSOR_MANDATORY), \
>>> +  RTEMS_SCHEDULER_ASSIGN(1, RTEMS_SCHEDULER_ASSIGN_PROCESSOR_OPTIONAL), \
>>> +  RTEMS_SCHEDULER_ASSIGN(2, RTEMS_SCHEDULER_ASSIGN_PROCESSOR_OPTIONAL), \
>>> +  RTEMS_SCHEDULER_ASSIGN(2, RTEMS_SCHEDULER_ASSIGN_PROCESSOR_OPTIONAL)
>>> +
>> These seems specific but I ma not sure.
> This configuration provides enough resources to run a wide range of test 
> cases.
> For example, the SMP scheduler configuration with three schedulers can be used
> to test most of the SMP support of RTEMS.
>>
>> Do tests depend on this configuration?
> Yes, if the configuration provides the necessary resources, they pass, 
> otherwise
> they fail.

Any particular reason for those schedulers in that order?

>> Does the number of cores available effect this or the dependent tests? I 
>> assume
>> this is included in a number of tests.
> If a test needs three processors and a board has only two, then the test case
> should fail.

Will those BSPs have the failing tests excluded?

I would like to be comfortable the tests and these set ups are not solely
focused on the LEON.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2 1/2] bsps/shared/ofw: Implement RTEMS OFW interface

2020-11-16 Thread Niteesh G. S. 
Hello Christian,

On Tue, Nov 17, 2020 at 12:10 AM Christian Mauderer 
wrote:

> Hello,
>
> sorry for the long delay. I tested it on xilinx-zynq-a9-qemu (which
> doesn't have a FDT) and the test seems to run fine. So I'm OK with the
> patches. If no one objects in the next two days, I'll commit them.
>

Thanks for testing the patches.

Thanks,
Niteesh.



> Best regards
>
> Christian
>
> On 03/11/2020 19:18, G S Niteesh Babu wrote:
> > RTEMS OFW is a FDT only implementation of the OpenFirmWare
> > interface. This API is created to be compatible with FreeBSD
> > OpenFirmWare interface. The main intention is to make
> > porting of FreeBSD drivers to RTEMS easier.
> >
> > Most functions implemented have an direct one-one mapping
> > with the original OFW API and some extra auxiliary functions
> > were implemented to make working with device trees easier in
> > RTEMS.
> >
> > Update #3784
> > ---
> >  bsps/include/ofw/ofw.h| 548 +++
> >  bsps/include/ofw/ofw_compat.h |  74 
> >  bsps/shared/ofw/ofw.c | 682 ++
> >  spec/build/bsps/obj.yml   |   5 +
> >  4 files changed, 1309 insertions(+)
> >  create mode 100644 bsps/include/ofw/ofw.h
> >  create mode 100644 bsps/include/ofw/ofw_compat.h
> >  create mode 100644 bsps/shared/ofw/ofw.c
> >
> > diff --git a/bsps/include/ofw/ofw.h b/bsps/include/ofw/ofw.h
> > new file mode 100644
> > index 00..4c402671a4
> > --- /dev/null
> > +++ b/bsps/include/ofw/ofw.h
> > @@ -0,0 +1,548 @@
> > +/* SPDX-License-Identifier: BSD-2-Clause */
> > +
> > +/**
> > + * @file
> > + *
> > + * @ingroup ofw
> > + *
> > + * RTEMS FDT implementation of OpenFirmWare Interface.
> > + *
> > + * RTEMS OFW is a FDT only implementation of the OpenFirmWare interface.
> > + * This API is created to be compatible with FreeBSD OpenFirmWare
> interface.
> > + * The main intention is to make porting of FreeBSD drivers to RTEMS
> easier.
> > + */
> > +
> > +/*
> > + * Copyright (C) 2020 Niteesh Babu G S 
> > + *
> > + * 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 COPYRIGHT HOLDERS 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 COPYRIGHT OWNER 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.
> > + */
> > +
> > +#ifndef _OFW_H
> > +#define _OFW_H
> > +
> > +#ifdef __cplusplus
> > +extern "C" {
> > +#endif
> > +
> > +#include 
> > +#include 
> > +#include 
> > +
> > +/**
> > + * Represents a node in the device tree. The offset from fdtp to node
> is used
> > + * instead of fdt offset to make sure this is compatible with OF
> interface in
> > + * FreeBSD.
> > + */
> > +typedef uint32_t  phandle_t;
> > +/**
> > + * Represents the effective phandle of the node.
> > + */
> > +typedef uint32_t  ihandle_t;
> > +/**
> > + * Represents the data type of the buffer.
> > + */
> > +typedef uint32_t  pcell_t;
> > +
> > +/**
> > + * @struct rtems_ofw_memory_area
> > + *
> > + * This is used to represent elements(FDT properties) that define
> > + * region of memory address.
> > + */
> > +typedef struct {
> > +  /** The start address of the memory region. */
> > +  uint32_t start;
> > +  /** The size of the memory region. */
> > +  uint32_t size;
> > +} rtems_ofw_memory_area;
> > +
> > +/**
> > + * @struct rtems_ofw_ranges
> > + *
> > + * This is used to represent the ranges property in the device tree.
> > + */
> > +typedef struct {
> > +  /** The physical address within the child bus address space */
> > +  uint32_t child_bus;
> > +  /** The physical address within the parent bus address space */
> > +  uint32_t parent_bus;
> > +  /** The size of the range in the child’s address space */
> > +  uint32_t size;
> > +} rtems_ofw_ranges;
> > +
> > +/**
> > + * @brief Gets the node that is next to @a node.
> > + *
> > + * @para

Re: [PATCH 7/8] validation/ts-performance-0: Add test suite

2020-11-16 Thread Sebastian Huber 

On 17/11/2020 00:15, Chris Johns wrote:


new file mode 100644
index 00..0f7db65a8e
--- /dev/null
+++ b/testsuites/validation/ts-default.h
@@ -0,0 +1,237 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @brief This header file provides the default validation test suite runner
+ *   and application configuration.
+ */
[...]
+#define CONFIGURE_SCHEDULER_EDF_SMP
+
+#include 
+
+RTEMS_SCHEDULER_EDF_SMP(a);
+
+RTEMS_SCHEDULER_EDF_SMP(b);
+
+RTEMS_SCHEDULER_EDF_SMP(c);
+
+#define CONFIGURE_SCHEDULER_TABLE_ENTRIES \
+  RTEMS_SCHEDULER_TABLE_EDF_SMP(a, rtems_build_name('A', ' ', ' ', ' ')), \
+  RTEMS_SCHEDULER_TABLE_EDF_SMP(b, rtems_build_name('B', ' ', ' ', ' ')), \
+  RTEMS_SCHEDULER_TABLE_EDF_SMP(c, rtems_build_name('C', ' ', ' ', ' '))
+
+#define CONFIGURE_SCHEDULER_ASSIGNMENTS \
+  RTEMS_SCHEDULER_ASSIGN(0, RTEMS_SCHEDULER_ASSIGN_PROCESSOR_MANDATORY), \
+  RTEMS_SCHEDULER_ASSIGN(1, RTEMS_SCHEDULER_ASSIGN_PROCESSOR_OPTIONAL), \
+  RTEMS_SCHEDULER_ASSIGN(2, RTEMS_SCHEDULER_ASSIGN_PROCESSOR_OPTIONAL), \
+  RTEMS_SCHEDULER_ASSIGN(2, RTEMS_SCHEDULER_ASSIGN_PROCESSOR_OPTIONAL)
+

These seems specific but I ma not sure.

This configuration provides enough resources to run a wide range of test cases.
For example, the SMP scheduler configuration with three schedulers can be used
to test most of the SMP support of RTEMS.

Do tests depend on this configuration?

Yes, if the configuration provides the necessary resources, they pass, otherwise
they fail.

Any particular reason for those schedulers in that order?
Most tests use one processor. With just two processors you can probably 
test more than 90% of the RTEMS SMP support. Only some very specific 
corner cases need more than two processors. This is a general purpose 
test suite and the configuration will be adapted if a new test case 
needs something special. If it is too special, then it can be added to a 
dedicated test suite.



Does the number of cores available effect this or the dependent tests? I assume
this is included in a number of tests.

If a test needs three processors and a board has only two, then the test case
should fail.

Will those BSPs have the failing tests excluded?
Currently, there is no support for the new test framework in the RTEMS 
Tester. You can only specify the expected state of a complete test 
suite. I hope to eventually add some support for the new test framework 
so that the expected state of individual test cases can be specified.


I would like to be comfortable the tests and these set ups are not solely
focused on the LEON.
I am not focused on the LEON. Why do you think something is 
LEON-specific in this test suite?


--
embedded brains GmbH
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
PGP: Public key available on request.

embedded brains GmbH
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: Proposal for hardware configuration dependent performance limits

2020-11-16 Thread Sebastian Huber 


On 16/11/2020 23:42, Chris Johns wrote:

On 16/11/20 5:40 pm, Sebastian Huber wrote:

On 16/11/2020 00:33, Chris Johns wrote:


In the proposal, limits are specified like this:


limits:
  sparc/gr712rc:
    DirtyCache:
  max-upper-bound: 0.05
  mean-upper-bound: 0.05
    FullCache:
  max-upper-bound: 0.05
  mean-upper-bound: 0.05
    HotCache:
  max-upper-bound: 0.05
  mean-upper-bound: 0.05
    Load/1:
  max-upper-bound: 0.1
  mean-upper-bound: 0.1
    Load/2:
  max-upper-bound: 0.1
  mean-upper-bound: 0.1
    Load/3:
  max-upper-bound: 0.1
  mean-upper-bound: 0.1
    Load/4:
  max-upper-bound: 0.1
  mean-upper-bound: 0.1

This neglects that the limits are subject to a board configuration. One
approach to cover this is the addition of a new BSP provided function:

const char *rtems_get_hardware_performance_hash();

The BSP feeds all performance related data into a hash function and

"data" here means configuration?

Yes, hardware configuration.

Why not make these values part of the BSP configuration? The defaults for the
BSP can have a set of suitable values. Different boards have different
configurations to match and a separate kernel build.


This doesn't work on BSPs which support configuration via a hardware
enumeration, boot loader settings, or device trees. Also changes in the BSP
options have no influence on the BSP name. Not only BSP configuration influence
performance, the CPU options play a role too, for example RTEMS_SMP. In order to
compare performance values over time we have to obtain the values under the same
conditions.

Maybe I am not understanding the context.

A BSP, which ever one, has a set of options that configure it. An example is the
xilinx_zynq_zc702 and the `ZYNQ_RAM_LENGTH = 0x4000`. If I have 2 Zynq
circuits one with 256M and one with 1G I need to build and maintain 2 RTEMS
builds and from a purists point of view I need to maintain 2 builds of the exact
same application.

I asked about the fixed memory and your answer was to use the BSP options, the
size is fixed in the linker command files via the BSP option. That is what I
have done.

I would expect there exists a set of values for the xilinx_zynq_zc702 with no
SMP and with SMP as this BSP supports SMP. Those values would match all the
other settings for the BSP such as ZYNQ_CLOCK_CPU_1X, BSP_ARM_A9MPCORE_PERIPHCLK
etc. If my clock is different (and they are) I would need to supply a suitable
set of performance values if I wanted to pass those tests.

I am not questioning the need for the values or the tests. I am suggesting the
values form part of the BSP settings so a user can adjust them to suite their
specific set up in the same way they adjust other BSP settings. I do not think
we should attempt to hold or manage an endless sets of possible values and I do
not see the need for complex encapsulation methods such as a base64 hashes. The
systems we interact with are too complex and list is endless.


I think it will be highly BSP-specific what parameters are relevant to 
the performance limits. This is why I suggested to add a function which 
can be implemented by each BSP.


const char *rtems_get_hardware_performance_something();

It should return a string which changes if a performance relevant 
parameter changed. If it is only SMP/no-SMP, ZYNQ_CLOCK_CPU_1X, and 
BSP_ARM_A9MPCORE_PERIPHCLK, then fine, just return "SMP/800MHz/400MHz" 
or whatever.


My point is that we need a key reported by the BSP and then some 
performance limits which can be found by arch/bsp/key to check if there 
are performance regressions.


--
embedded brains GmbH
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
PGP: Public key available on request.

embedded brains GmbH
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

GMP is now a required dependency for building GDB

2020-11-16 Thread Sebastian Huber 

Hello,

I tried to update the RTEMS 6/7 tools yesterday and all builds failed on 
my FreeBSD machine. The reason is this change in GDB:


commit 1b4ac058f7daeb9bac9ab0e63a7e73535208dfef
Author: Joel Brobecker 
Date:   Sun Nov 15 03:08:40 2020 -0500

    gdb: Make GMP a required dependency for building GDB

    This commit modifies gdb's configure script to trigger an error
    if we cannot find a usable libgmp.

    For the record, making this a requirement was discussed in March 2018:
https://sourceware.org/pipermail/gdb-patches/2018-March/147373.html

    gdb/ChangeLog:

    * configure.ac: Generate an error if a usable GMP library
    could not be found.
    * configure: Regenerate.

The GMP library is not available by default on FreeBSD systems. For GCC 
we include a fixed version and build it together with GCC. What should 
be do for GDB?


--
embedded brains GmbH
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
PGP: Public key available on request.

embedded brains GmbH
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