[PATCH v7] Update test smpstrongapa01
Update smpstrongapa01 to account for task shifting.
---
testsuites/smptests/smpstrongapa01/init.c | 66 ---
1 file changed, 47 insertions(+), 19 deletions(-)
diff --git a/testsuites/smptests/smpstrongapa01/init.c
b/testsuites/smptests/smpstrongapa01/init.c
index bf8bc05231..8a02265615 100644
--- a/testsuites/smptests/smpstrongapa01/init.c
+++ b/testsuites/smptests/smpstrongapa01/init.c
@@ -1,4 +1,5 @@
/*
+ * Copyright (c) 2020 Richi Dubey ( richidu...@gmail.com )
* Copyright (c) 2016, 2017 embedded brains GmbH. All rights reserved.
*
* embedded brains GmbH
@@ -16,7 +17,7 @@
#include "config.h"
#endif
-#include "tmacros.h"
+#include
#include
@@ -24,15 +25,22 @@ const char rtems_test_name[] = "SMPSTRONGAPA 1";
#define CPU_COUNT 4
-#define TASK_COUNT (3 * CPU_COUNT)
+#define TASK_COUNT 5
#define P(i) (UINT32_C(2) + i)
#define ALL ((UINT32_C(1) << CPU_COUNT) - 1)
-#define IDLE UINT8_C(255)
+#define A(cpu0, cpu1, cpu2, cpu3) ( (cpu3 << 3) | (cpu2 << 2) | (cpu1 << 1)|
cpu0 )
-#define NAME rtems_build_name('S', 'A', 'P', 'A')
+typedef enum {
+ T0,
+ T1,
+ T2,
+ T3,
+ T4,
+ IDLE
+} task_index;
typedef struct {
enum {
@@ -43,7 +51,7 @@ typedef struct {
KIND_UNBLOCK
} kind;
- size_t index;
+ task_index index;
struct {
rtems_task_priority priority;
@@ -102,17 +110,34 @@ typedef struct {
static const test_action test_actions[] = {
RESET,
- UNBLOCK( 0, 0, IDLE, IDLE, IDLE),
- UNBLOCK( 1, 0,1, IDLE, IDLE),
- UNBLOCK( 2, 0,1,2, IDLE),
- UNBLOCK( 3, 0,1,2,3),
- UNBLOCK( 5, 0,1,2,3),
- SET_PRIORITY( 3, P(4),0,1,2,3),
- SET_PRIORITY( 5, P(3),0,1,2,5),
- BLOCK(5, 0,1,2,3),
- SET_AFFINITY( 5, ALL,0,1,2,3),
- RESET,
- UNBLOCK( 0, 0, IDLE, IDLE, IDLE),
+ UNBLOCK( T0,T0, IDLE, IDLE, IDLE),
+ UNBLOCK( T1,T0,T1, IDLE, IDLE),
+ UNBLOCK( T2,T0,T1, T2, IDLE),
+ UNBLOCK( T3,T0,T1, T2, T3),
+ UNBLOCK( T4,T0,T1, T2, T3),
+ SET_PRIORITY( T0, P(0), T0,T1, T2, T3),
+ SET_PRIORITY( T1, P(1), T0,T1, T2, T3),
+ SET_PRIORITY( T2, P(2), T0,T1, T2, T3),
+ SET_PRIORITY( T4, P(4), T0,T1, T2, T3),
+ /*
+ * Introduce Task 3 intially with lowest priority to imitate late arrival
+ */
+ SET_PRIORITY( T3, P(8), T0,T1, T2, T4),
+ SET_AFFINITY( T0, ALL, T0,T1, T2, T4),
+ SET_AFFINITY( T1, A(0, 1, 0, 0), T0,T1, T2, T4),
+ SET_AFFINITY( T2, A(0, 0, 1, 0), T0,T1, T2, T4),
+ SET_AFFINITY( T4, A(0, 0, 0, 1), T0,T1, T2, T4),
+ /*
+ *Set affinity of Task 4 only to CPU1, so that we can check shifting
+ */
+ SET_AFFINITY( T3, A(1, 0, 0, 0), T0,T1, T2, T4),
+ /*
+ * Show that higher priority task gets dislodged from its processor
+ * by a lower priority task !
+ * and goes to the cpu that is executing the task with lowest priority
+ * (among all cpus).
+ */
+ SET_PRIORITY( T3, P(3),T3,T1, T2, T0),
RESET
};
@@ -182,7 +207,7 @@ static void check_cpu_allocations(test_context *ctx, const
test_action *action)
size_t i;
for (i = 0; i < CPU_COUNT; ++i) {
-size_t e;
+task_index e;
const Per_CPU_Control *c;
const Thread_Control *h;
@@ -279,7 +304,7 @@ static void test(void)
for (i = 0; i < TASK_COUNT; ++i) {
sc = rtems_task_create(
- NAME,
+ rtems_build_name(' ', ' ', 'T', '0' + i),
P(i),
RTEMS_MINIMUM_STACK_SIZE,
RTEMS_DEFAULT_MODES,
@@ -292,7 +317,10 @@ static void test(void)
rtems_test_assert(sc == RTEMS_SUCCESSFUL);
}
- sc = rtems_timer_create(NAME, &ctx->timer_id);
+ sc = rtems_timer_create(
+rtems_build_name('A', 'C', 'T', 'N'),
+&ctx->timer_id
+ );
rtems_test_assert(sc == RTEMS_SUCCESSFUL);
sc = rtems_timer_fire_after(ctx->timer_id, 1, timer, ctx);
--
2.17.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v6 2/2] Update smpstrongapa01; Add smpstrongapa02,smpstrongapa03
I have sent a new patch, hopefully, it captures the important things we need to check for Strong APA working properly. (Task shifting during task arrival/departure). On Fri, Jun 25, 2021 at 6:44 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 25/06/2021 14:19, Richi Dubey wrote: > > Why can't the test cases of the additional two test programs be > merged > > into the existing test program smpstrongapa01? > > > > Good point. I am looking into this right now. The original idea behind > > having multiple test programs was to have more testing - and be more > > confident that the task-shifting works. I will see if the tests can be > > merged safely. > > I don't want to reduce the number of test cases. I just wonder why we > need three copy and paste variants of the same generic test program > which executes table based test cases. > > -- > 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
source builder fails on master
Hi,
I ran the following commands
mkdir -p $HOME/quick-start/LatestMaster/src
cd $HOME/quick-start/LatestMaster/src
git clone https://github.com/RTEMS/rtems-source-builder.git rsb
git clone https://github.com/RTEMS/rtems.git
cd $HOME/quick-start/LatestMaster/src/rsb/rtems
../source-builder/sb-set-builder
--prefix=$HOME/quick-start/LatestMaster/rtems/6 6/rtems-arm
but it fails.:
.
.
.
package: expat-2.1.0-x86_64-linux-gnu-1
building: expat-2.1.0-x86_64-linux-gnu-1
error: building expat-2.1.0-x86_64-linux-gnu-1
Build FAILED
See error report: rsb-report-expat-2.1.0-x86_64-linux-gnu-1.txt
error: building expat-2.1.0-x86_64-linux-gnu-1
Build Set: Time 0:00:15.413288
Build FAILED
I have attached the report. I think it has something to do with my GCC? I
update it to 11 as well, but I still get the error.
Gcc details:
--
sudo update-alternatives --config gcc
There are 5 choices for the alternative gcc (providing /usr/bin/gcc).
SelectionPath Priority Status
* 0/usr/bin/gcc-11 110 auto mode
1/usr/bin/gcc-10 100 manual mode
2/usr/bin/gcc-11 110 manual mode
3/usr/bin/gcc-770manual mode
4/usr/bin/gcc-880manual mode
5/usr/bin/gcc-970manual mode
Press to keep the current choice[*], or type selection number:
richi@YouAreAmazing:~$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
11.1.0-1ubuntu1~18.04.1'
--with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2
--prefix=/usr --with-gcc-major-version-only --program-suffix=-11
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie
--with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --disable-cet --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-11-YRKbe7/gcc-11-11.1.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-YRKbe7/gcc-11-11.1.0/debian/tmp-gcn/usr
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.1.0 (Ubuntu 11.1.0-1ubuntu1~18.04.1)
--
Can someone please help me out with this?
Thanks.
RTEMS Tools Project - Source Builder Error Report
Build: error: building expat-2.1.0-x86_64-linux-gnu-1
Command Line: ../source-builder/sb-set-builder
--prefix=/home/richi/quick-start/LatestMaster/rtems/6 6/rtems-arm
Python: 3.6.9 (default, Jan 26 2021, 15:33:00) [GCC 8.4.0]
https://github.com/RTEMS/rtems-source-builder.git/origin/4e6dc6431435821a534da6307e72ecbd7e42b82a
Linux YouAreAmazing 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC
2020 x86_64
Tail of the build log:
script:114: CFLAGS_FOR_HOST="${SB_HOST_CFLAGS}"
script:115: CXXFLAGS_FOR_HOST="${SB_HOST_CXXFLAGS}"
script:116: LDFLAGS_FOR_HOST="${SB_HOST_LDFLAGS}"
script:117: LDLIBS_FOR_HOST="${SB_HOST_LIBS}"
script:118: LIBS_FOR_HOST="${SB_HOST_LIBS}"
script:119: CXXFLAGS_FOR_HOST="${SB_HOST_CFLAGS}"
script:120: CC_FOR_HOST=$(echo "gcc ${SB_HOST_CFLAGS}" | sed -e 's,-std=gnu99
,,')
script:121: CXX_FOR_HOST=$(echo "g++ ${SB_HOST_CXXFLAGS}" | sed -e
's,-std=gnu99 ,,')
script:122: # Build
script:123: CFLAGS_FOR_BUILD="${SB_BUILD_CFLAGS}"
script:124: CXXFLAGS_FOR_BUILD="${SB_BUILD_CXXFLAGS}"
script:125: LDFLAGS_FOR_BUILD="${SB_BUILD_LDFLAGS}"
script:126: LDLIBS_FOR_BUILD="${SB_BUILD_LIBS}"
script:127: LIBS_FOR_BUILD="${SB_BUILD_LIBS}"
script:128: CXXFLAGS_FOR_BUILD="${SB_BUILD_CFLAGS}"
script:129: CC_FOR_BUILD=$(echo "gcc ${SB_BUILD_CFLAGS}" | sed -e
's,-std=gnu99 ,,')
script:130: CXX_FOR_BUILD=$(echo "g++ ${SB_BUILD_CXXFLAGS}" | sed -e
's,-std=gnu99 ,,')
script:131: else
script:132: LDFLAGS="${SB_BUILD_LDFLAGS}"
script:133: LDLIBS="${SB_BUILD_LIBS}"
script:134: LIBS="${SB_BUILD_LIBS}"
script:135: CC=$(echo "gcc ${SB_BUILD_CFLAGS}" | sed -e 's,-std=gnu99 ,,')
script:136: CXX=$(echo "g++ ${SB_BUILD_CXXFLAGS}" | sed -e 's,-std=gnu99 ,,')
script:137: CC_FOR_BUILD=${CC}
script:138: CXX_FOR_BUILD=${CXX}
sc
Re: source builder fails on master
These are the last few lines of the report: bindir=/home/richi/quick-start/LatestMaster/rtems/6/bin --exec-prefix=/home/richi/quick-start/LatestMaster/rtems/6 --includedir=/home/richi/quick-start/LatestMaster/rtems/6/include --libdir=/home/richi/quick-start/LatestMaster/rtems/6/lib --mandir=/home/richi/quick-start/LatestMaster/rtems/6/share/man --infodir=/home/richi/quick-start/LatestMaster/rtems/6/share/info --disable-shared checking build system type... x86_64-pc-linux-gnu checking host system type... x86_64-pc-linux-gnu checking how to print strings... printf checking for x86_64-linux-gnu-gcc... gcc -O2 -g -pipe -I/home/richi/quick-start/LatestMaster/src/rsb/rtems/build/tmp/sb-1000/6/rtems-arm/home/richi/quick-start/LatestMaster/rtems/6/include checking whether the C compiler works... no configure: error: in `/home/richi/quick-start/LatestMaster/src/rsb/rtems/build/expat-2.1.0-x86_64-linux-gnu-1/expat-2.1.0': configure: error: C compiler cannot create executables See `config.log' for more details shell cmd failed: /bin/sh -ex /home/richi/quick-start/LatestMaster/src/rsb/rtems/build/expat-2.1.0-x86_64-linux-gnu-1/do-build error: building expat-2.1.0-x86_64-linux-gnu-1 On Tue, Jun 29, 2021 at 1:11 PM Richi Dubey wrote: > Hi, > > I ran the following commands > > mkdir -p $HOME/quick-start/LatestMaster/src > cd $HOME/quick-start/LatestMaster/src > git clone https://github.com/RTEMS/rtems-source-builder.git rsb > git clone https://github.com/RTEMS/rtems.git > cd $HOME/quick-start/LatestMaster/src/rsb/rtems > ../source-builder/sb-set-builder > --prefix=$HOME/quick-start/LatestMaster/rtems/6 6/rtems-arm > > but it fails.: > . > . > . > package: expat-2.1.0-x86_64-linux-gnu-1 > building: expat-2.1.0-x86_64-linux-gnu-1 > error: building expat-2.1.0-x86_64-linux-gnu-1 > Build FAILED > See error report: rsb-report-expat-2.1.0-x86_64-linux-gnu-1.txt > error: building expat-2.1.0-x86_64-linux-gnu-1 > Build Set: Time 0:00:15.413288 > Build FAILED > > I have attached the report. I think it has something to do with my GCC? I > update it to 11 as well, but I still get the error. > > Gcc details: > -- > sudo update-alternatives --config gcc > There are 5 choices for the alternative gcc (providing /usr/bin/gcc). > > SelectionPath Priority Status > > * 0/usr/bin/gcc-11 110 auto mode > 1/usr/bin/gcc-10 100 manual mode > 2/usr/bin/gcc-11 110 manual mode > 3/usr/bin/gcc-770manual mode > 4/usr/bin/gcc-880manual mode > 5/usr/bin/gcc-970manual mode > > Press to keep the current choice[*], or type selection number: > richi@YouAreAmazing:~$ gcc -v > Using built-in specs. > COLLECT_GCC=gcc > COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper > OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa > OFFLOAD_TARGET_DEFAULT=1 > Target: x86_64-linux-gnu > Configured with: ../src/configure -v --with-pkgversion='Ubuntu > 11.1.0-1ubuntu1~18.04.1' > --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs > --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 > --prefix=/usr --with-gcc-major-version-only --program-suffix=-11 > --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id > --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix > --libdir=/usr/lib --enable-nls --enable-clocale=gnu > --enable-libstdcxx-debug --enable-libstdcxx-time=yes > --with-default-libstdcxx-abi=new --enable-gnu-unique-object > --disable-vtable-verify --enable-plugin --enable-default-pie > --with-system-zlib --enable-libphobos-checking=release > --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch > --disable-werror --disable-cet --with-arch-32=i686 --with-abi=m64 > --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic > --enable-offload-targets=nvptx-none=/build/gcc-11-YRKbe7/gcc-11-11.1.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-YRKbe7/gcc-11-11.1.0/debian/tmp-gcn/usr > --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu > --host=x86_64-linux-gnu --target=x86_64-linux-gnu > Thread model: posix > Supported LTO compression algorithms: zlib zstd > gcc version 11.1.0 (Ubuntu 11.1.0-1ubuntu1~18.04.1) > > -- > > > Can someone please help me out with this? > > Thanks. > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] bsps/zynqmp: Allow any or all CGEMs to be enabled
I suppose this could have been configured in libbsd (possibly config.inc) instead if that's what you're getting at. The overall goal is to be able to run the tests that use the network on any one of the board variants that this BSP supports. My takeaway from the earlier conversation on the list is that this was the preferred method of switching the ethernet interface for those tests. Kinsey On 6/28/2021 20:49, Chris Johns wrote: Hi, I am just catching up and missed this one until I saw the patch was pushed. I am sorry but I am confused by this patch. Could someone please explain this reason for this addition to the BSP and approach being taken? Is there something in the BSP that requires this information be provided here? Chris On 9/6/21 6:18 am, Kinsey Moore wrote: Provide the options necessary to enable any combination of CGEM ethernet interfaces in LibBSD. The default is still CGEM3, so this should continue to operate as expected on typical Zynq Ultrascale+ MPSoC development hardware. --- spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml| 8 .../bsps/aarch64/xilinx-zynqmp/optcgem0.yml | 16 .../bsps/aarch64/xilinx-zynqmp/optcgem1.yml | 16 .../bsps/aarch64/xilinx-zynqmp/optcgem2.yml | 16 .../bsps/aarch64/xilinx-zynqmp/optcgem3.yml | 16 5 files changed, 72 insertions(+) create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/optcgem0.yml create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/optcgem1.yml create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/optcgem2.yml create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/optcgem3.yml diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml b/spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml index 16e2b8a7e9..1b6b756912 100644 --- a/spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml +++ b/spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml @@ -27,6 +27,14 @@ links: uid: optramori - role: build-dependency uid: optclkuart +- role: build-dependency + uid: optcgem0 +- role: build-dependency + uid: optcgem1 +- role: build-dependency + uid: optcgem2 +- role: build-dependency + uid: optcgem3 - role: build-dependency uid: ../../optconminor - role: build-dependency diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/optcgem0.yml b/spec/build/bsps/aarch64/xilinx-zynqmp/optcgem0.yml new file mode 100644 index 00..fc878fda60 --- /dev/null +++ b/spec/build/bsps/aarch64/xilinx-zynqmp/optcgem0.yml @@ -0,0 +1,16 @@ +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause +actions: +- get-boolean: null +- env-enable: null +- define-condition: null +build-type: option +copyrights: +- Copyright (C) 2021 On-Line Applications Research +default: false +default-by-variant: [] +description: | + Enable support for CGEM0 +enabled-by: true +links: [] +name: BSP_XILINX_ZYNQMP_USE_CGEM0 +type: build diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/optcgem1.yml b/spec/build/bsps/aarch64/xilinx-zynqmp/optcgem1.yml new file mode 100644 index 00..6d5096bbde --- /dev/null +++ b/spec/build/bsps/aarch64/xilinx-zynqmp/optcgem1.yml @@ -0,0 +1,16 @@ +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause +actions: +- get-boolean: null +- env-enable: null +- define-condition: null +build-type: option +copyrights: +- Copyright (C) 2021 On-Line Applications Research +default: false +default-by-variant: [] +description: | + Enable support for CGEM1 +enabled-by: true +links: [] +name: BSP_XILINX_ZYNQMP_USE_CGEM1 +type: build diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/optcgem2.yml b/spec/build/bsps/aarch64/xilinx-zynqmp/optcgem2.yml new file mode 100644 index 00..a8aca3ebbd --- /dev/null +++ b/spec/build/bsps/aarch64/xilinx-zynqmp/optcgem2.yml @@ -0,0 +1,16 @@ +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause +actions: +- get-boolean: null +- env-enable: null +- define-condition: null +build-type: option +copyrights: +- Copyright (C) 2021 On-Line Applications Research +default: false +default-by-variant: [] +description: | + Enable support for CGEM2 +enabled-by: true +links: [] +name: BSP_XILINX_ZYNQMP_USE_CGEM2 +type: build diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/optcgem3.yml b/spec/build/bsps/aarch64/xilinx-zynqmp/optcgem3.yml new file mode 100644 index 00..8275ad3440 --- /dev/null +++ b/spec/build/bsps/aarch64/xilinx-zynqmp/optcgem3.yml @@ -0,0 +1,16 @@ +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause +actions: +- get-boolean: null +- env-enable: null +- define-condition: null +build-type: option +copyrights: +- Copyright (C) 2021 On-Line Applications Research +default: true +default-by-variant: [] +description: | + Enable support for CGEM3 +enabled-by: true +links: [] +name: BSP_XILINX_ZYNQMP_USE_CGEM3 +type: build ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
GSOC: Adding all generated changes in patch to RSB?
Dear Mentors, I've implemented my new functions locally in Newlib, created basic tests in RTEMS, now I want to add the patches to the RSB to test them. I think I understand that once I submit these patches to newlib, they should only include the added lines of source code...not any changes generated through the build process. However, when I make a patch to add to RSB and test, I need to include everything, right? There are probably about 100 modified files from the reconf / build. Should I: 1) "git add --all" to add the whole load of new files and changes 2) make the commit 3) git format patch Just want to make sure I'm understanding this point... Thank you! Sincerely, Matt ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSOC: Adding all generated changes in patch to RSB?
On Tue, Jun 29, 2021 at 8:07 AM Matthew Joyce wrote: > > Dear Mentors, > > I've implemented my new functions locally in Newlib, created basic > tests in RTEMS, now I want to add the patches to the RSB to test them. > > I think I understand that once I submit these patches to newlib, they > should only include the added lines of source code...not any changes > generated through the build process. +1 > However, when I make a patch to add to RSB and test, I need to include > everything, right? There are probably about 100 modified files from > the reconf / build. Should I: > 1) "git add --all" to add the whole load of new files and changes > 2) make the commit > 3) git format patch Yes -- the RSB patch must include the generated files. But this patch set and RSB modifications are only for your use. Before RTEMS.org RSB is updated, the patch must be in the upstream newlib and we will just bump the newlib hash. That's why I suggested just building newlib (j-newlib, make, make install, etc) locally without the RSB and testing that way. With that said, there are a couple of things to do here: + Do NOT put generated files in your main patch. Make them a separate patch in the set so they are easy to ignore. + Reverse the generated changes to anything that shouldn't change based on what you touched. These are just due to autoconf version difference. In your case, I think this means you only need signal/Makefile.in. The rest are unneeded. + Only submit the patches with manual changes for review. Submit to devel@ and when it passes review, it goes to newlib. When the work is merged into newlib, you can update the RSB newlib hash and submit your tests to RTEMS. You will have to track the status of outstanding work and continue on to the next thing while the review process moves along. FWIW Eshan ended up tracking patches for a few months after last year's GSoC ended before we cleared his queue up. --joel > > Just want to make sure I'm understanding this point... > > Thank you! > > Sincerely, > > Matt ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] bsps/zynqmp: Allow any or all CGEMs to be enabled
On 6/9/2021 00:27, Sebastian Huber wrote: On 08/06/2021 22:18, Kinsey Moore wrote: Provide the options necessary to enable any combination of CGEM ethernet interfaces in LibBSD. The default is still CGEM3, so this should continue to operate as expected on typical Zynq Ultrascale+ MPSoC development hardware. An alternative to this configuration approach would be to enable the device tree support for this BSP. Sorry, I missed this earlier due to travel. Device tree support in libbsd for if_cgem.c is currently #ifdef'd out and has been since it was introduced. I had assumed that was the case for other FDT support as well based on the comments in that initial commit. Kinsey ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] bsps/zynqmp: Allow any or all CGEMs to be enabled
On 29/06/2021 15:48, Kinsey Moore wrote: On 6/9/2021 00:27, Sebastian Huber wrote: On 08/06/2021 22:18, Kinsey Moore wrote: Provide the options necessary to enable any combination of CGEM ethernet interfaces in LibBSD. The default is still CGEM3, so this should continue to operate as expected on typical Zynq Ultrascale+ MPSoC development hardware. An alternative to this configuration approach would be to enable the device tree support for this BSP. Sorry, I missed this earlier due to travel. Device tree support in libbsd for if_cgem.c is currently #ifdef'd out and has been since it was introduced. I had assumed that was the case for other FDT support as well based on the comments in that initial commit. The device tree support is disabled since the original Zynq BSP was added before RTEMS had support for device trees in general. Nobody had the time/budget/need to change the BSP to support device trees so far. -- 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 0/6] Add aarch64/xilinx-versal
I'll look at this, I didn't spend much time on the ilp32 or the vck190 targets. There's probably something that isn't supported in ilp32 mode in the boot code. On Mon, Jun 28, 2021 at 2:53 AM Sebastian Huber wrote: > > Hello Gedare, > > I get linker errors with this BSP: > > Waf: Entering directory `/tmp/sh/b-rtems/aarch64/xilinx_versal_ilp32_vck190' > 10:51:14 runner 'git rev-parse HEAD' > [1334/4030] Compiling bsps/aarch64/shared/start/start.S > 10:51:16 runner ['/opt/rtems/6/bin/aarch64-rtems6-gcc', '-MMD', > '-mcpu=cortex-a72', '-DASM', '-g', '-Icpukit/include', > '-I/home/EB/sebastian_h/src/rtems/cpukit/include', > '-Icpukit/score/cpu/aarch64/include', > '-I/home/EB/sebastian_h/src/rtems/cpukit/score/cpu/aarch64/include', > '-Ibsps/include', '-I/home/EB/sebastian_h/src/rtems/bsps/include', > '-Ibsps/aarch64/include', > '-I/home/EB/sebastian_h/src/rtems/bsps/aarch64/include', > '-Ibsps/aarch64/xilinx-versal/include', > '-I/home/EB/sebastian_h/src/rtems/bsps/aarch64/xilinx-versal/include', > '/home/EB/sebastian_h/src/rtems/bsps/aarch64/shared/start/start.S', > '-c', '-ostart.o'] > [1438/4030] Linking > /tmp/sh/b-rtems/aarch64/xilinx_versal_ilp32_vck190/testsuites/benchmarks/dhrystone.exe > 10:51:16 runner ['/opt/rtems/6/bin/aarch64-rtems6-gcc', > 'testsuites/benchmarks/dhrystone/dhry_1.c.85.o', > 'testsuites/benchmarks/dhrystone/dhry_2.c.85.o', > 'testsuites/benchmarks/dhrystone/init.c.85.o', > '-o/tmp/sh/b-rtems/aarch64/xilinx_versal_ilp32_vck190/testsuites/benchmarks/dhrystone.exe', > '-Wl,-Bstatic', '-L.', '-lrtemscpu', '-lrtemsbsp', '-lrtemstest', > '-Wl,-Bdynamic', '-qrtems', '-mcpu=cortex-a72', '-Wl,--gc-sections', > '-L/home/EB/sebastian_h/src/rtems/bsps/aarch64/shared/start', > '-L/home/EB/sebastian_h/src/rtems/bsps/aarch64/xilinx-versal/start', > '-Wl,--wrap=printf', '-Wl,--wrap=puts'] > /opt/rtems/6/lib/gcc/aarch64-rtems6/10.3.1/../../../../aarch64-rtems6/bin/ld: > skipping incompatible start.o when searching for start.o > /opt/rtems/6/lib/gcc/aarch64-rtems6/10.3.1/../../../../aarch64-rtems6/bin/ld: > skipping incompatible ./start.o when searching for start.o > /opt/rtems/6/lib/gcc/aarch64-rtems6/10.3.1/../../../../aarch64-rtems6/bin/ld: > cannot find start.o > /opt/rtems/6/lib/gcc/aarch64-rtems6/10.3.1/../../../../aarch64-rtems6/bin/ld: > skipping incompatible start.o when searching for start.o > /opt/rtems/6/lib/gcc/aarch64-rtems6/10.3.1/../../../../aarch64-rtems6/bin/ld: > skipping incompatible ./start.o when searching for start.o > collect2: error: ld returned 1 exit status > > > -- > 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] Addded test for timer_create with clock_monotonic
---
cpukit/include/rtems/posix/timer.h| 1 +
cpukit/posix/src/psxtimercreate.c | 5 +-
cpukit/posix/src/timergettime.c | 79 ---
testsuites/psxtests/psxtimer02/psxtimer.c | 38 ++-
4 files changed, 98 insertions(+), 25 deletions(-)
diff --git a/cpukit/include/rtems/posix/timer.h
b/cpukit/include/rtems/posix/timer.h
index bcbf07a65a..839fe3293c 100644
--- a/cpukit/include/rtems/posix/timer.h
+++ b/cpukit/include/rtems/posix/timer.h
@@ -48,6 +48,7 @@ typedef struct {
uint32_t ticks; /* Number of ticks of the initialization */
uint32_t overrun;/* Number of expirations of the timer*/
struct timespec time; /* Time at which the timer was started */
+clockid_t clock_type;
} POSIX_Timer_Control;
/**
diff --git a/cpukit/posix/src/psxtimercreate.c
b/cpukit/posix/src/psxtimercreate.c
index a63cf1d100..b60be3f229 100644
--- a/cpukit/posix/src/psxtimercreate.c
+++ b/cpukit/posix/src/psxtimercreate.c
@@ -40,7 +40,7 @@ int timer_create(
{
POSIX_Timer_Control *ptimer;
- if ( clock_id != CLOCK_REALTIME )
+ if ( clock_id != CLOCK_REALTIME && clock_id != CLOCK_MONOTONIC )
rtems_set_errno_and_return_minus_one( EINVAL );
if ( !timerid )
@@ -91,7 +91,8 @@ int timer_create(
ptimer->timer_data.it_value.tv_nsec= 0;
ptimer->timer_data.it_interval.tv_sec = 0;
ptimer->timer_data.it_interval.tv_nsec = 0;
-
+ ptimer->clock_type=clock_id;
+
_Watchdog_Preinitialize( &ptimer->Timer, _Per_CPU_Get_snapshot() );
_Watchdog_Initialize( &ptimer->Timer, _POSIX_Timer_TSR );
_Objects_Open_u32(&_POSIX_Timer_Information, &ptimer->Object, 0);
diff --git a/cpukit/posix/src/timergettime.c b/cpukit/posix/src/timergettime.c
index ee2a566f0e..57b0ab4918 100644
--- a/cpukit/posix/src/timergettime.c
+++ b/cpukit/posix/src/timergettime.c
@@ -6,6 +6,14 @@
* @brief Function Fetches State of POSIX Per-Process Timers
*/
+/**
+ * @file
+ *
+ * @ingroup POSIXAPI
+ *
+ * @brief Function Fetches State of POSIX Per-Process Timers
+ */
+
/*
* 14.2.4 Per-Process Timers, P1003.1b-1993, p. 267
*
@@ -21,13 +29,13 @@
#include "config.h"
#endif
-#include
#include
-
#include
#include
#include
#include
+#include
+#include
/*
* - When a timer is initialized, the value of the time in
@@ -36,38 +44,65 @@
*between the current time and the initialization time.
*/
-int timer_gettime(
- timer_ttimerid,
- struct itimerspec *value
-)
-{
+int timer_gettime(timer_t timerid, struct itimerspec *value) {
POSIX_Timer_Control *ptimer;
- ISR_lock_Context lock_context;
- uint64_t now;
- uint32_t remaining;
+ ISR_lock_Context lock_context;
+ uint32_t remaining;
+ Per_CPU_Control *cpu;
+ struct timespec *now;// get time now either with
+ struct timespec *expire; // expire
+
+ struct timespec *result;
+
+ if (!value)
+rtems_set_errno_and_return_minus_one(EINVAL);
- if ( !value )
-rtems_set_errno_and_return_minus_one( EINVAL );
+ ptimer = _POSIX_Timer_Get(timerid, &lock_context);
+ if (ptimer == NULL) {
+rtems_set_errno_and_return_minus_one(EINVAL);
+ }
+
+ if (ptimer->clock_type == CLOCK_REALTIME) {
- ptimer = _POSIX_Timer_Get( timerid, &lock_context );
- if ( ptimer != NULL ) {
-Per_CPU_Control *cpu;
+cpu = _POSIX_Timer_Acquire_critical(ptimer, &lock_context);
-cpu = _POSIX_Timer_Acquire_critical( ptimer, &lock_context );
-now = cpu->Watchdog.ticks;
+_TOD_Get(now); // get current time
+rtems_timespec_from_ticks(ptimer->Timer.expire,
+ expire);
-if ( now < ptimer->Timer.expire ) {
- remaining = (uint32_t) ( ptimer->Timer.expire - now );
+if (now->tv_nsec + now->tv_sec >
+expire->tv_nsec + expire->tv_sec) {
+ rtems_timespec_subtract(now, expire, result);
+
+ remaining = (uint32_t)result->tv_nsec + result->tv_sec;
} else {
remaining = 0;
}
-_Timespec_From_ticks( remaining, &value->it_value );
+_Timespec_From_ticks(remaining, &value->it_value);
value->it_interval = ptimer->timer_data.it_interval;
+ _POSIX_Timer_Release(cpu, &lock_context);
+return 0;
+ }
+
+ if (ptimer->clock_type == CLOCK_MONOTONIC) {
+
+cpu = _POSIX_Timer_Acquire_critical(ptimer, &lock_context);
+rtems_timespec_from_ticks(ptimer->Timer.expire, expire);
-_POSIX_Timer_Release( cpu, &lock_context );
+if (now->tv_nsec + now->tv_sec > expire->tv_nsec + expire->tv_sec) {
+
+ rtems_timespec_subtract(now, expire, result);
+ remaining = (uint32_t)result->tv_nsec + result->tv_sec;
+} else {
+ remaining = 0;
+}
+
+_Timespec_From_ticks(remaining, &value->it_value);
+value->it_interval = ptimer->timer_data.it_interval;
+_POSIX_Timer_Release(cpu, &lock_context);
return 0;
}
- rtems_set_errno_and_return_minus_one( EINVAL );
Re: [PATCH] bsps/zynqmp: Allow any or all CGEMs to be enabled
On Tue, Jun 29, 2021 at 7:50 AM Sebastian Huber wrote: > > On 29/06/2021 15:48, Kinsey Moore wrote: > > On 6/9/2021 00:27, Sebastian Huber wrote: > >> On 08/06/2021 22:18, Kinsey Moore wrote: > >>> Provide the options necessary to enable any combination of CGEM ethernet > >>> interfaces in LibBSD. The default is still CGEM3, so this should > >>> continue to operate as expected on typical Zynq Ultrascale+ MPSoC > >>> development hardware. > >> > >> An alternative to this configuration approach would be to enable the > >> device tree support for this BSP. > >> > > Sorry, I missed this earlier due to travel. Device tree support in > > libbsd for if_cgem.c is currently #ifdef'd out and has been since it was > > introduced. I had assumed that was the case for other FDT support as > > well based on the comments in that initial commit. > > The device tree support is disabled since the original Zynq BSP was > added before RTEMS had support for device trees in general. Nobody had > the time/budget/need to change the BSP to support device trees so far. > I'm not sure anyone has the time/budget yet either. FDT support is challenging for RTEMS because it requires a closer interaction between a bootloader and RTEMS, which raises legal/license compliance concerns. Although I agree that FDT is a great solution, I'm not certain about the scope (or creep) it implies in terms of the relationship between RTEMS and Bootloaders/firmware, or whether we need to produce our own "mini bootloader" that deals with FDT support early in the RTEMS startup sequence. Right now, the design eludes me, but I'm certain that requiring users to U-Boot for FDT support is not the best solution for RTEMS. > -- > 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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] spec/aarch64: fix abi flags for xilinx_versal_ilp32_vck190
--- spec/build/bsps/aarch64/xilinx-versal/abi.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/spec/build/bsps/aarch64/xilinx-versal/abi.yml b/spec/build/bsps/aarch64/xilinx-versal/abi.yml index 67340ffa08..90bfca9f76 100644 --- a/spec/build/bsps/aarch64/xilinx-versal/abi.yml +++ b/spec/build/bsps/aarch64/xilinx-versal/abi.yml @@ -14,6 +14,7 @@ default-by-variant: - -mabi=ilp32 variants: - aarch64/xilinx_versal_ilp32_qemu + - aarch64/xilinx_versal_ilp32_vck190 description: | ABI flags enabled-by: true -- 2.25.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Testing SDIO drivers for ZynqMP in RTEMS-libbsd
Hi, I'm working on updating the ZynqMP board's nexus devices so that it will load SDHCI device drivers, but I'm not sure what the best way to test the drivers is. I don't see an existing test for SDIO functionality in the libbsd test suites. Also, does anyone have any advice for running RTEMS in QEMU with SD cards? Thanks, Stephen Clark ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] bsps/zynqmp: Allow any or all CGEMs to be enabled
On Tue, Jun 29, 2021 at 6:34 AM Kinsey Moore wrote: > > I suppose this could have been configured in libbsd (possibly > config.inc) instead if that's what you're getting at. The overall goal > is to be able to run the tests that use the network on any one of the > board variants that this BSP supports. My takeaway from the earlier > conversation on the list is that this was the preferred method of > switching the ethernet interface for those tests. > I acked this patch, and then I also dug into the cgem code. It seems we should leave the decision of which GEM to use to the application. This patch and way of doing that accomplishes the configuration by the application as a BSP option. However, there's no code in the BSP that actually gets controlled by the option. So, I think we should probably find a better way to allow the application to select which GEM it uses, and to provide the glue in the BSP to allow all the possible GEMs to be available. > Kinsey > > On 6/28/2021 20:49, Chris Johns wrote: > > Hi, > > > > I am just catching up and missed this one until I saw the patch was pushed. > > I am > > sorry but I am confused by this patch. > > > > Could someone please explain this reason for this addition to the BSP and > > approach being taken? Is there something in the BSP that requires this > > information be provided here? > > > > Chris > > > > On 9/6/21 6:18 am, Kinsey Moore wrote: > >> Provide the options necessary to enable any combination of CGEM ethernet > >> interfaces in LibBSD. The default is still CGEM3, so this should > >> continue to operate as expected on typical Zynq Ultrascale+ MPSoC > >> development hardware. > >> --- > >> spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml| 8 > >> .../bsps/aarch64/xilinx-zynqmp/optcgem0.yml | 16 > >> .../bsps/aarch64/xilinx-zynqmp/optcgem1.yml | 16 > >> .../bsps/aarch64/xilinx-zynqmp/optcgem2.yml | 16 > >> .../bsps/aarch64/xilinx-zynqmp/optcgem3.yml | 16 > >> 5 files changed, 72 insertions(+) > >> create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/optcgem0.yml > >> create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/optcgem1.yml > >> create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/optcgem2.yml > >> create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/optcgem3.yml > >> > >> diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml > >> b/spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml > >> index 16e2b8a7e9..1b6b756912 100644 > >> --- a/spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml > >> +++ b/spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml > >> @@ -27,6 +27,14 @@ links: > >> uid: optramori > >> - role: build-dependency > >> uid: optclkuart > >> +- role: build-dependency > >> + uid: optcgem0 > >> +- role: build-dependency > >> + uid: optcgem1 > >> +- role: build-dependency > >> + uid: optcgem2 > >> +- role: build-dependency > >> + uid: optcgem3 > >> - role: build-dependency > >> uid: ../../optconminor > >> - role: build-dependency > >> diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/optcgem0.yml > >> b/spec/build/bsps/aarch64/xilinx-zynqmp/optcgem0.yml > >> new file mode 100644 > >> index 00..fc878fda60 > >> --- /dev/null > >> +++ b/spec/build/bsps/aarch64/xilinx-zynqmp/optcgem0.yml > >> @@ -0,0 +1,16 @@ > >> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause > >> +actions: > >> +- get-boolean: null > >> +- env-enable: null > >> +- define-condition: null > >> +build-type: option > >> +copyrights: > >> +- Copyright (C) 2021 On-Line Applications Research > >> +default: false > >> +default-by-variant: [] > >> +description: | > >> + Enable support for CGEM0 > >> +enabled-by: true > >> +links: [] > >> +name: BSP_XILINX_ZYNQMP_USE_CGEM0 > >> +type: build > >> diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/optcgem1.yml > >> b/spec/build/bsps/aarch64/xilinx-zynqmp/optcgem1.yml > >> new file mode 100644 > >> index 00..6d5096bbde > >> --- /dev/null > >> +++ b/spec/build/bsps/aarch64/xilinx-zynqmp/optcgem1.yml > >> @@ -0,0 +1,16 @@ > >> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause > >> +actions: > >> +- get-boolean: null > >> +- env-enable: null > >> +- define-condition: null > >> +build-type: option > >> +copyrights: > >> +- Copyright (C) 2021 On-Line Applications Research > >> +default: false > >> +default-by-variant: [] > >> +description: | > >> + Enable support for CGEM1 > >> +enabled-by: true > >> +links: [] > >> +name: BSP_XILINX_ZYNQMP_USE_CGEM1 > >> +type: build > >> diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/optcgem2.yml > >> b/spec/build/bsps/aarch64/xilinx-zynqmp/optcgem2.yml > >> new file mode 100644 > >> index 00..a8aca3ebbd > >> --- /dev/null > >> +++ b/spec/build/bsps/aarch64/xilinx-zynqmp/optcgem2.yml > >> @@ -0,0 +1,16 @@ > >> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause > >> +actions: > >> +- get-boolean: null > >> +- env-en
Re: source builder fails on master
Run with --no-clean option and see if you can find the config.log for the expat package. Otherwise, you might try to build that expat package by hand to see what is failing. On Tue, Jun 29, 2021 at 1:43 AM Richi Dubey wrote: > > These are the last few lines of the report: > > bindir=/home/richi/quick-start/LatestMaster/rtems/6/bin > --exec-prefix=/home/richi/quick-start/LatestMaster/rtems/6 > --includedir=/home/richi/quick-start/LatestMaster/rtems/6/include > --libdir=/home/richi/quick-start/LatestMaster/rtems/6/lib > --mandir=/home/richi/quick-start/LatestMaster/rtems/6/share/man > --infodir=/home/richi/quick-start/LatestMaster/rtems/6/share/info > --disable-shared > checking build system type... x86_64-pc-linux-gnu > checking host system type... x86_64-pc-linux-gnu > checking how to print strings... printf > checking for x86_64-linux-gnu-gcc... gcc -O2 -g -pipe > -I/home/richi/quick-start/LatestMaster/src/rsb/rtems/build/tmp/sb-1000/6/rtems-arm/home/richi/quick-start/LatestMaster/rtems/6/include > checking whether the C compiler works... no > configure: error: in > `/home/richi/quick-start/LatestMaster/src/rsb/rtems/build/expat-2.1.0-x86_64-linux-gnu-1/expat-2.1.0': > configure: error: C compiler cannot create executables > See `config.log' for more details > shell cmd failed: /bin/sh -ex > /home/richi/quick-start/LatestMaster/src/rsb/rtems/build/expat-2.1.0-x86_64-linux-gnu-1/do-build > error: building expat-2.1.0-x86_64-linux-gnu-1 > > On Tue, Jun 29, 2021 at 1:11 PM Richi Dubey wrote: >> >> Hi, >> >> I ran the following commands >> >> mkdir -p $HOME/quick-start/LatestMaster/src >> cd $HOME/quick-start/LatestMaster/src >> git clone https://github.com/RTEMS/rtems-source-builder.git rsb >> git clone https://github.com/RTEMS/rtems.git >> cd $HOME/quick-start/LatestMaster/src/rsb/rtems >> ../source-builder/sb-set-builder >> --prefix=$HOME/quick-start/LatestMaster/rtems/6 6/rtems-arm >> >> but it fails.: >> . >> . >> . >> package: expat-2.1.0-x86_64-linux-gnu-1 >> building: expat-2.1.0-x86_64-linux-gnu-1 >> error: building expat-2.1.0-x86_64-linux-gnu-1 >> Build FAILED >> See error report: rsb-report-expat-2.1.0-x86_64-linux-gnu-1.txt >> error: building expat-2.1.0-x86_64-linux-gnu-1 >> Build Set: Time 0:00:15.413288 >> Build FAILED >> >> I have attached the report. I think it has something to do with my GCC? I >> update it to 11 as well, but I still get the error. >> >> Gcc details: >> -- >> sudo update-alternatives --config gcc >> There are 5 choices for the alternative gcc (providing /usr/bin/gcc). >> >> SelectionPath Priority Status >> >> * 0/usr/bin/gcc-11 110 auto mode >> 1/usr/bin/gcc-10 100 manual mode >> 2/usr/bin/gcc-11 110 manual mode >> 3/usr/bin/gcc-770manual mode >> 4/usr/bin/gcc-880manual mode >> 5/usr/bin/gcc-970manual mode >> >> Press to keep the current choice[*], or type selection number: >> richi@YouAreAmazing:~$ gcc -v >> Using built-in specs. >> COLLECT_GCC=gcc >> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper >> OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa >> OFFLOAD_TARGET_DEFAULT=1 >> Target: x86_64-linux-gnu >> Configured with: ../src/configure -v --with-pkgversion='Ubuntu >> 11.1.0-1ubuntu1~18.04.1' >> --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs >> --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr >> --with-gcc-major-version-only --program-suffix=-11 >> --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id >> --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix >> --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug >> --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new >> --enable-gnu-unique-object --disable-vtable-verify --enable-plugin >> --enable-default-pie --with-system-zlib --enable-libphobos-checking=release >> --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch >> --disable-werror --disable-cet --with-arch-32=i686 --with-abi=m64 >> --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic >> --enable-offload-targets=nvptx-none=/build/gcc-11-YRKbe7/gcc-11-11.1.0/debian/tmp-nvp tx/usr,amdgcn-amdhsa=/build/gcc-11-YRKbe7/gcc-11-11.1.0/debian/tmp-gcn/usr --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu >> Thread model: posix >> Supported LTO compression algorithms: zlib zstd >> gcc version 11.1.0 (Ubuntu 11.1.0-1ubuntu1~18.04.1) >> >> -- >> >> >> Can someone please help me out with this? >> >> Thanks. > > ___ > devel mailing list > devel@rtems.
Re: [PATCH] bsps/zynq-uart: Make post baud change kick global
ok
On Mon, Jun 28, 2021 at 7:04 AM Kinsey Moore wrote:
>
> The existing fix for the ZynqMP UART hardware bug only caught the vast
> majority of instances where it could occur. To fully fix the data
> corruption, this fix must be applied after every baud rate change. This
> makes the logic reset and kick apply in any locations where the baud
> rate could be changed.
> ---
> bsps/aarch64/xilinx-zynqmp/console/console.c | 5 -
> bsps/shared/dev/serial/zynq-uart-polled.c| 6 ++
> bsps/shared/dev/serial/zynq-uart.c | 8
> 3 files changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/bsps/aarch64/xilinx-zynqmp/console/console.c
> b/bsps/aarch64/xilinx-zynqmp/console/console.c
> index 9886a117dc..d1948f1a0c 100644
> --- a/bsps/aarch64/xilinx-zynqmp/console/console.c
> +++ b/bsps/aarch64/xilinx-zynqmp/console/console.c
> @@ -113,11 +113,6 @@ static void zynqmp_debug_console_early_init(char c)
>
>zynq_uart_initialize(base);
>BSP_output_char = zynqmp_debug_console_out;
> - /*
> - * Some ZynqMP UARTs have a hardware bug that causes TX/RX logic restarts
> to
> - * require a kick after baud rate registers are initialized.
> - */
> - zynqmp_debug_console_out(0);
>zynqmp_debug_console_out(c);
> }
>
> diff --git a/bsps/shared/dev/serial/zynq-uart-polled.c
> b/bsps/shared/dev/serial/zynq-uart-polled.c
> index 74e7255ec2..95c51dea11 100644
> --- a/bsps/shared/dev/serial/zynq-uart-polled.c
> +++ b/bsps/shared/dev/serial/zynq-uart-polled.c
> @@ -144,6 +144,12 @@ void zynq_uart_initialize(rtems_termios_device_context
> *base)
>regs->control = ZYNQ_UART_CONTROL_RXEN
> | ZYNQ_UART_CONTROL_TXEN
> | ZYNQ_UART_CONTROL_RSTTO;
> +
> + /*
> + * Some ZynqMP UARTs have a hardware bug that causes TX/RX logic restarts
> to
> + * require a kick after baud rate registers are initialized.
> + */
> + zynq_uart_write_polled(base, 0);
> }
>
> int zynq_uart_read_polled(rtems_termios_device_context *base)
> diff --git a/bsps/shared/dev/serial/zynq-uart.c
> b/bsps/shared/dev/serial/zynq-uart.c
> index cd0d0e7584..8503e31d49 100644
> --- a/bsps/shared/dev/serial/zynq-uart.c
> +++ b/bsps/shared/dev/serial/zynq-uart.c
> @@ -214,9 +214,17 @@ static bool zynq_uart_set_attributes(
>if (baud > 0) {
> regs->baud_rate_gen = ZYNQ_UART_BAUD_RATE_GEN_CD(brgr);
> regs->baud_rate_div = ZYNQ_UART_BAUD_RATE_DIV_BDIV(bauddiv);
> +regs->control |= ZYNQ_UART_CONTROL_RXRES
> + | ZYNQ_UART_CONTROL_TXRES;
>}
>regs->control |= ZYNQ_UART_CONTROL_RXEN | ZYNQ_UART_CONTROL_TXEN;
>
> + /*
> + * Some ZynqMP UARTs have a hardware bug that causes TX/RX logic restarts
> to
> + * require a kick after baud rate registers are initialized.
> + */
> + zynq_uart_write_polled(context, 0);
> +
>return true;
> }
>
> --
> 2.20.1
>
> ___
> 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] bsps/zynqmp: Allow any or all CGEMs to be enabled
On 6/29/2021 11:10, Gedare Bloom wrote: On Tue, Jun 29, 2021 at 6:34 AM Kinsey Moore wrote: I suppose this could have been configured in libbsd (possibly config.inc) instead if that's what you're getting at. The overall goal is to be able to run the tests that use the network on any one of the board variants that this BSP supports. My takeaway from the earlier conversation on the list is that this was the preferred method of switching the ethernet interface for those tests. I acked this patch, and then I also dug into the cgem code. It seems we should leave the decision of which GEM to use to the application. This patch and way of doing that accomplishes the configuration by the application as a BSP option. However, there's no code in the BSP that actually gets controlled by the option. So, I think we should probably find a better way to allow the application to select which GEM it uses, and to provide the glue in the BSP to allow all the possible GEMs to be available. This patch was primarily targeted at the tests themselves. The application can always provide its own nexus definitions instead of using the ones baked into libbsd for testing (this was brought up in the initial thread where I asked about how this was typically done). Unfortunately, this is hard to do with the tests because the tests are the application and can't be changed for those overrides/alternatives. Kinsey ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] bsps/cadence-spi: Fix moduleid offset
Jan, please confirm. Thanks
On Mon, Jun 28, 2021 at 7:06 AM Kinsey Moore wrote:
>
> Move the moduleid register to the correct offset according to Cadence IP
> documentation.
> ---
> bsps/include/dev/spi/cadence-spi-regs.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/bsps/include/dev/spi/cadence-spi-regs.h
> b/bsps/include/dev/spi/cadence-spi-regs.h
> index b4b2366b3d..207d056fb1 100644
> --- a/bsps/include/dev/spi/cadence-spi-regs.h
> +++ b/bsps/include/dev/spi/cadence-spi-regs.h
> @@ -78,6 +78,7 @@ typedef struct {
> uint32_t slave_idle_count;
> uint32_t txthreshold;
> uint32_t rxthreshold;
> + uint32_t unused[51];
> uint32_t moduleid;
> } cadence_spi;
>
> --
> 2.20.1
>
> ___
> 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] spec/aarch64: fix abi flags for xilinx_versal_ilp32_vck190
Looks good. On 6/29/2021 11:04, Gedare Bloom wrote: --- spec/build/bsps/aarch64/xilinx-versal/abi.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/spec/build/bsps/aarch64/xilinx-versal/abi.yml b/spec/build/bsps/aarch64/xilinx-versal/abi.yml index 67340ffa08..90bfca9f76 100644 --- a/spec/build/bsps/aarch64/xilinx-versal/abi.yml +++ b/spec/build/bsps/aarch64/xilinx-versal/abi.yml @@ -14,6 +14,7 @@ default-by-variant: - -mabi=ilp32 variants: - aarch64/xilinx_versal_ilp32_qemu + - aarch64/xilinx_versal_ilp32_vck190 description: | ABI flags enabled-by: true ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 0/6] Add aarch64/xilinx-versal
This should be fixed now. On Tue, Jun 29, 2021 at 9:10 AM Gedare Bloom wrote: > > I'll look at this, I didn't spend much time on the ilp32 or the vck190 > targets. There's probably something that isn't supported in ilp32 mode > in the boot code. > > On Mon, Jun 28, 2021 at 2:53 AM Sebastian Huber > wrote: > > > > Hello Gedare, > > > > I get linker errors with this BSP: > > > > Waf: Entering directory `/tmp/sh/b-rtems/aarch64/xilinx_versal_ilp32_vck190' > > 10:51:14 runner 'git rev-parse HEAD' > > [1334/4030] Compiling bsps/aarch64/shared/start/start.S > > 10:51:16 runner ['/opt/rtems/6/bin/aarch64-rtems6-gcc', '-MMD', > > '-mcpu=cortex-a72', '-DASM', '-g', '-Icpukit/include', > > '-I/home/EB/sebastian_h/src/rtems/cpukit/include', > > '-Icpukit/score/cpu/aarch64/include', > > '-I/home/EB/sebastian_h/src/rtems/cpukit/score/cpu/aarch64/include', > > '-Ibsps/include', '-I/home/EB/sebastian_h/src/rtems/bsps/include', > > '-Ibsps/aarch64/include', > > '-I/home/EB/sebastian_h/src/rtems/bsps/aarch64/include', > > '-Ibsps/aarch64/xilinx-versal/include', > > '-I/home/EB/sebastian_h/src/rtems/bsps/aarch64/xilinx-versal/include', > > '/home/EB/sebastian_h/src/rtems/bsps/aarch64/shared/start/start.S', > > '-c', '-ostart.o'] > > [1438/4030] Linking > > /tmp/sh/b-rtems/aarch64/xilinx_versal_ilp32_vck190/testsuites/benchmarks/dhrystone.exe > > 10:51:16 runner ['/opt/rtems/6/bin/aarch64-rtems6-gcc', > > 'testsuites/benchmarks/dhrystone/dhry_1.c.85.o', > > 'testsuites/benchmarks/dhrystone/dhry_2.c.85.o', > > 'testsuites/benchmarks/dhrystone/init.c.85.o', > > '-o/tmp/sh/b-rtems/aarch64/xilinx_versal_ilp32_vck190/testsuites/benchmarks/dhrystone.exe', > > '-Wl,-Bstatic', '-L.', '-lrtemscpu', '-lrtemsbsp', '-lrtemstest', > > '-Wl,-Bdynamic', '-qrtems', '-mcpu=cortex-a72', '-Wl,--gc-sections', > > '-L/home/EB/sebastian_h/src/rtems/bsps/aarch64/shared/start', > > '-L/home/EB/sebastian_h/src/rtems/bsps/aarch64/xilinx-versal/start', > > '-Wl,--wrap=printf', '-Wl,--wrap=puts'] > > /opt/rtems/6/lib/gcc/aarch64-rtems6/10.3.1/../../../../aarch64-rtems6/bin/ld: > > skipping incompatible start.o when searching for start.o > > /opt/rtems/6/lib/gcc/aarch64-rtems6/10.3.1/../../../../aarch64-rtems6/bin/ld: > > skipping incompatible ./start.o when searching for start.o > > /opt/rtems/6/lib/gcc/aarch64-rtems6/10.3.1/../../../../aarch64-rtems6/bin/ld: > > cannot find start.o > > /opt/rtems/6/lib/gcc/aarch64-rtems6/10.3.1/../../../../aarch64-rtems6/bin/ld: > > skipping incompatible start.o when searching for start.o > > /opt/rtems/6/lib/gcc/aarch64-rtems6/10.3.1/../../../../aarch64-rtems6/bin/ld: > > skipping incompatible ./start.o when searching for start.o > > collect2: error: ld returned 1 exit status > > > > > > -- > > 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] Addded test for timer_create with clock_monotonic
Hi Zack,
Please provide a full name in your git-commit author metadata (git-config.user)
Please use a short tag at the start of your commit to identify the
scope, in this case, it will be "posix/timer"
Check typo "addded" in your commit message. I think this commit is
related to a ticket? if it finishes it, please use
Closes #.
where is the ticket number, or
Updates #.
If the patch does not close the ticket out.
On Tue, Jun 29, 2021 at 9:19 AM Zack wrote:
>
> ---
> cpukit/include/rtems/posix/timer.h| 1 +
> cpukit/posix/src/psxtimercreate.c | 5 +-
> cpukit/posix/src/timergettime.c | 79 ---
> testsuites/psxtests/psxtimer02/psxtimer.c | 38 ++-
> 4 files changed, 98 insertions(+), 25 deletions(-)
>
> diff --git a/cpukit/include/rtems/posix/timer.h
> b/cpukit/include/rtems/posix/timer.h
> index bcbf07a65a..839fe3293c 100644
> --- a/cpukit/include/rtems/posix/timer.h
> +++ b/cpukit/include/rtems/posix/timer.h
> @@ -48,6 +48,7 @@ typedef struct {
>uint32_t ticks; /* Number of ticks of the initialization */
>uint32_t overrun;/* Number of expirations of the timer*/
>struct timespec time; /* Time at which the timer was started */
> +clockid_t clock_type;
To be consistent, add a comment like the lines above.
> } POSIX_Timer_Control;
>
> /**
> diff --git a/cpukit/posix/src/psxtimercreate.c
> b/cpukit/posix/src/psxtimercreate.c
> index a63cf1d100..b60be3f229 100644
> --- a/cpukit/posix/src/psxtimercreate.c
> +++ b/cpukit/posix/src/psxtimercreate.c
> @@ -40,7 +40,7 @@ int timer_create(
> {
>POSIX_Timer_Control *ptimer;
>
> - if ( clock_id != CLOCK_REALTIME )
> + if ( clock_id != CLOCK_REALTIME && clock_id != CLOCK_MONOTONIC )
> rtems_set_errno_and_return_minus_one( EINVAL );
>
>if ( !timerid )
> @@ -91,7 +91,8 @@ int timer_create(
>ptimer->timer_data.it_value.tv_nsec= 0;
>ptimer->timer_data.it_interval.tv_sec = 0;
>ptimer->timer_data.it_interval.tv_nsec = 0;
> -
> + ptimer->clock_type=clock_id;
add spaces around =. Here, the lines above are aligned on the =, so
you should also align. Write code that uses a consistent style as
surrounding code / as the RTEMS Style.
> +
This blank line adds a lot of whitespace characters (spaces). Blank
lines should be empty.
>_Watchdog_Preinitialize( &ptimer->Timer, _Per_CPU_Get_snapshot() );
>_Watchdog_Initialize( &ptimer->Timer, _POSIX_Timer_TSR );
>_Objects_Open_u32(&_POSIX_Timer_Information, &ptimer->Object, 0);
> diff --git a/cpukit/posix/src/timergettime.c b/cpukit/posix/src/timergettime.c
> index ee2a566f0e..57b0ab4918 100644
> --- a/cpukit/posix/src/timergettime.c
> +++ b/cpukit/posix/src/timergettime.c
> @@ -6,6 +6,14 @@
> * @brief Function Fetches State of POSIX Per-Process Timers
> */
>
> +/**
> + * @file
> + *
> + * @ingroup POSIXAPI
> + *
> + * @brief Function Fetches State of POSIX Per-Process Timers
A file isn't a function
> + */
> +
> /*
> * 14.2.4 Per-Process Timers, P1003.1b-1993, p. 267
> *
> @@ -21,13 +29,13 @@
> #include "config.h"
> #endif
>
> -#include
> #include
> -
Why delete the space separating the two groups of includes, system
includes and rtems includes?
> #include
> #include
> #include
> #include
> +#include
> +#include
Why do you reorder the includes?
>
> /*
> * - When a timer is initialized, the value of the time in
> @@ -36,38 +44,65 @@
> *between the current time and the initialization time.
> */
>
> -int timer_gettime(
> - timer_ttimerid,
> - struct itimerspec *value
> -)
> -{
> +int timer_gettime(timer_t timerid, struct itimerspec *value) {
Why do you reformat the style of the function declaration? I shouldn't
need to spend time reviewing your style changes, focus instead on
writing code in the proper style and avoid making random style changes
that are not related to the new functionality you're introducing.
>POSIX_Timer_Control *ptimer;
> - ISR_lock_Context lock_context;
> - uint64_t now;
> - uint32_t remaining;
> + ISR_lock_Context lock_context;
> + uint32_t remaining;
> + Per_CPU_Control *cpu;
> + struct timespec *now;// get time now either with
we don't use // comments, and I don't know that you need this comment anyway.
> + struct timespec *expire; // expire
ditto
> +
any good reason for a blank line here?
> + struct timespec *result;
> +
> + if (!value)
> +rtems_set_errno_and_return_minus_one(EINVAL);
>
> - if ( !value )
> -rtems_set_errno_and_return_minus_one( EINVAL );
Changing the style and not in the right way. Please read and follow
the RTEMS Coding Conventions:
https://docs.rtems.org/branches/master/eng/coding.html
> + ptimer = _POSIX_Timer_Get(timerid, &lock_context);
> + if (ptimer == NULL) {
> +rtems_set_errno_and_return_minus_one(EINVAL);
> + }
> +
> + if (ptimer->clock_type == CLOCK_REALTIME) {
>
> - ptimer
Re: GSOC: Adding all generated changes in patch to RSB?
Dr. Joel, Thanks! This made me re-read your discord workflow advice from last week, and it brings me to another question...You wrote: "You don't have to rebuild the entire toolsuite at this point. Just add a functional test for sig2str.c to the testsuite (e.g. psxsigNN or similar based on existing names). You have your implementation in your local newlib patches." I did add the test, but I don't quite understand "you have your implementation in your local newlib patches." Do you mean the sig2str.c patch plus generated files? Where exactly is it supposed to be? Am I following the instructions Vaibhav lays out minus the toolset rebuilding? (patch in rtems/rsb/patches, calculate sha512, edit .cfg used by .bset file?) 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? Thank you again for your help! Sincerely, Matt On Tue, Jun 29, 2021 at 3:45 PM Joel Sherrill wrote: > > On Tue, Jun 29, 2021 at 8:07 AM Matthew Joyce wrote: > > > > Dear Mentors, > > > > I've implemented my new functions locally in Newlib, created basic > > tests in RTEMS, now I want to add the patches to the RSB to test them. > > > > I think I understand that once I submit these patches to newlib, they > > should only include the added lines of source code...not any changes > > generated through the build process. > > +1 > > > However, when I make a patch to add to RSB and test, I need to include > > everything, right? There are probably about 100 modified files from > > the reconf / build. Should I: > > 1) "git add --all" to add the whole load of new files and changes > > 2) make the commit > > 3) git format patch > > Yes -- the RSB patch must include the generated files. But this patch set > and RSB modifications are only for your use. Before RTEMS.org RSB is > updated, the patch must be in the upstream newlib and we will just bump > the newlib hash. That's why I suggested just building newlib (j-newlib, make, > make install, etc) locally without the RSB and testing that way. > > With that said, there are a couple of things to do here: > > + Do NOT put generated files in your main patch. Make them a separate > patch in the set so they are easy to ignore. > > + Reverse the generated changes to anything that shouldn't change based > on what you touched. These are just due to autoconf version difference. In > your > case, I think this means you only need signal/Makefile.in. The rest are > unneeded. > > + Only submit the patches with manual changes for review. Submit to devel@ > and when it passes review, it goes to newlib. > > When the work is merged into newlib, you can update the RSB newlib hash > and submit your tests to RTEMS. You will have to track the status of > outstanding work and continue on to the next thing while the review process > moves along. > > FWIW Eshan ended up tracking patches for a few months after last year's > GSoC ended before we cleared his queue up. > > --joel > > > > > Just want to make sure I'm understanding this point... > > > > Thank you! > > > > Sincerely, > > > > Matt ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2] bsps/arm: Move optfdt* files to shared parent directory
I don't have an arm toolchain, if someone can pick this up and test
compile the affected BSPs, it looks ok to me.
On Sun, Jun 27, 2021 at 2:46 PM pranav wrote:
>
> ---
> .../arm/altera-cyclone-v/bspalteracyclonev.yml | 8
> spec/build/bsps/arm/beagle/grp.yml | 8
> spec/build/bsps/arm/beagle/optfdtcpyro.yml | 15 ---
> spec/build/bsps/arm/beagle/optfdtmxsz.yml| 16
> spec/build/bsps/arm/beagle/optfdtro.yml | 15 ---
> spec/build/bsps/arm/beagle/optfdtuboot.yml | 15 ---
> spec/build/bsps/arm/imx/bspimx.yml | 8
> spec/build/bsps/arm/imx/optfdtcpyro.yml | 15 ---
> spec/build/bsps/arm/imx/optfdtmxsz.yml | 16
> spec/build/bsps/arm/imx/optfdtro.yml | 15 ---
> spec/build/bsps/arm/imx/optfdtuboot.yml | 15 ---
> .../arm/{altera-cyclone-v => }/optfdtcpyro.yml | 0
> .../arm/{altera-cyclone-v => }/optfdtmxsz.yml| 0
> .../bsps/arm/{altera-cyclone-v => }/optfdtro.yml | 0
> .../arm/{altera-cyclone-v => }/optfdtuboot.yml | 0
> spec/build/bsps/arm/raspberrypi/grp.yml | 8
> 16 files changed, 20 insertions(+), 134 deletions(-)
> delete mode 100644 spec/build/bsps/arm/beagle/optfdtcpyro.yml
> delete mode 100644 spec/build/bsps/arm/beagle/optfdtmxsz.yml
> delete mode 100644 spec/build/bsps/arm/beagle/optfdtro.yml
> delete mode 100644 spec/build/bsps/arm/beagle/optfdtuboot.yml
> delete mode 100644 spec/build/bsps/arm/imx/optfdtcpyro.yml
> delete mode 100644 spec/build/bsps/arm/imx/optfdtmxsz.yml
> delete mode 100644 spec/build/bsps/arm/imx/optfdtro.yml
> delete mode 100644 spec/build/bsps/arm/imx/optfdtuboot.yml
> rename spec/build/bsps/arm/{altera-cyclone-v => }/optfdtcpyro.yml (100%)
> rename spec/build/bsps/arm/{altera-cyclone-v => }/optfdtmxsz.yml (100%)
> rename spec/build/bsps/arm/{altera-cyclone-v => }/optfdtro.yml (100%)
> rename spec/build/bsps/arm/{altera-cyclone-v => }/optfdtuboot.yml (100%)
>
> diff --git a/spec/build/bsps/arm/altera-cyclone-v/bspalteracyclonev.yml
> b/spec/build/bsps/arm/altera-cyclone-v/bspalteracyclonev.yml
> index da567ddd79..faf7203cd4 100644
> --- a/spec/build/bsps/arm/altera-cyclone-v/bspalteracyclonev.yml
> +++ b/spec/build/bsps/arm/altera-cyclone-v/bspalteracyclonev.yml
> @@ -73,15 +73,15 @@ links:
> - role: build-dependency
>uid: optconuart1
> - role: build-dependency
> - uid: optfdtcpyro
> + uid: ../optfdtcpyro
> - role: build-dependency
>uid: optfdten
> - role: build-dependency
> - uid: optfdtmxsz
> + uid: ../optfdtmxsz
> - role: build-dependency
> - uid: optfdtro
> + uid: ../optfdtro
> - role: build-dependency
> - uid: optfdtuboot
> + uid: ../optfdtuboot
> - role: build-dependency
>uid: opti2cspeed
> - role: build-dependency
> diff --git a/spec/build/bsps/arm/beagle/grp.yml
> b/spec/build/bsps/arm/beagle/grp.yml
> index 1375913fd0..20fafa79a0 100644
> --- a/spec/build/bsps/arm/beagle/grp.yml
> +++ b/spec/build/bsps/arm/beagle/grp.yml
> @@ -22,13 +22,13 @@ links:
> - role: build-dependency
>uid: optdm3730
> - role: build-dependency
> - uid: optfdtcpyro
> + uid: ../optfdtcpyro
> - role: build-dependency
> - uid: optfdtmxsz
> + uid: ../optfdtmxsz
> - role: build-dependency
> - uid: optfdtro
> + uid: ../optfdtro
> - role: build-dependency
> - uid: optfdtuboot
> + uid: ../optfdtuboot
> - role: build-dependency
>uid: ../grp
> - role: build-dependency
> diff --git a/spec/build/bsps/arm/beagle/optfdtcpyro.yml
> b/spec/build/bsps/arm/beagle/optfdtcpyro.yml
> deleted file mode 100644
> index c26b1ae051..00
> --- a/spec/build/bsps/arm/beagle/optfdtcpyro.yml
> +++ /dev/null
> @@ -1,15 +0,0 @@
> -SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> -actions:
> -- get-boolean: null
> -- define-condition: null
> -build-type: option
> -copyrights:
> -- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
> -default: true
> -default-by-variant: []
> -description: |
> - copy the FDT blob into the read-only load area via bsp_fdt_copy()
> -enabled-by: true
> -links: []
> -name: BSP_FDT_BLOB_COPY_TO_READ_ONLY_LOAD_AREA
> -type: build
> diff --git a/spec/build/bsps/arm/beagle/optfdtmxsz.yml
> b/spec/build/bsps/arm/beagle/optfdtmxsz.yml
> deleted file mode 100644
> index 14af766230..00
> --- a/spec/build/bsps/arm/beagle/optfdtmxsz.yml
> +++ /dev/null
> @@ -1,16 +0,0 @@
> -SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> -actions:
> -- get-integer: null
> -- define: null
> -build-type: option
> -copyrights:
> -- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
> -default: 262144
> -default-by-variant: []
> -description: |
> - maximum size of the FDT blob in bytes
> -enabled-by: true
> -format: '{}'
> -links: []
> -name: BSP_FDT_BLOB_SIZE_MAX
> -type: build
> diff --git a/spec/build/bsps/arm/beagle/opt
[PATCH v1 1/2] ReportsBase.cc: Remove possible division by zero
CID 1503709: Division or modulo by float zero
Closes #4415
---
tester/covoar/ReportsBase.cc | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/tester/covoar/ReportsBase.cc b/tester/covoar/ReportsBase.cc
index b4a755c..31dc429 100644
--- a/tester/covoar/ReportsBase.cc
+++ b/tester/covoar/ReportsBase.cc
@@ -482,9 +482,13 @@ void ReportsBase::WriteSummaryReport(
}
}
- percentage = (double) notExecuted;
- percentage /= (double) totalBytes;
- percentage *= 100.0;
+ if (totalBytes == 0) {
+percentage = 0;
+ } else {
+percentage = (double) notExecuted;
+percentage /= (double) totalBytes;
+percentage *= 100.0;
+ }
percentageBranches = (double) (
SymbolsToAnalyze->getNumberBranchesAlwaysTaken(symbolSetName) +
--
1.8.3.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH v1 2/2] rtems-exeinfo.cpp: Fix division by zero errors
CID 1503008: Division or modulo by zero
CID 1503015: Division or modulo by zero
Closes #4416
---
linkers/rtems-exeinfo.cpp| 20
tester/covoar/ReportsBase.cc | 2 +-
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/linkers/rtems-exeinfo.cpp b/linkers/rtems-exeinfo.cpp
index 1e6d4b4..ec51597 100644
--- a/linkers/rtems-exeinfo.cpp
+++ b/linkers/rtems-exeinfo.cpp
@@ -755,6 +755,8 @@ namespace rld
size_t total = 0;
size_t total_size = 0;
size_t inlined_size = 0;
+ double percentage;
+ double percentage_size;
dwarf::functions funcs_inlined;
dwarf::functions funcs_not_inlined;
func_counts counts;
@@ -798,14 +800,24 @@ namespace rld
}
}
+ if ( total == 0 ) {
+percentage = 0;
+ } else {
+percentage = ( funcs_inlined.size() * 100 ) / total;
+ }
+
+ if ( total_size == 0 ) {
+percentage_size = 0;
+ } else {
+percentage_size = ( inlined_size * 100 ) / total_size;
+ }
+
std::cout << "inlined funcs : " << funcs_inlined.size () << std::endl
<< "total funcs : " << total << std::endl
-<< " % inline funcs : " << (funcs_inlined.size () * 100) /
total << '%'
-<< std::endl
+<< " % inline funcs : " << percentage << '%' << std::endl
<< " total size : " << total_size << std::endl
<< "inline size : " << inlined_size << std::endl
-<< " % inline size : " << (inlined_size * 100) / total_size
<< '%'
-<< std::endl;
+<< " % inline size : " << percentage_size << '%' << std::endl;
auto count_compare = [](func_count const & a, func_count const & b) {
return a.size != b.size? a.size < b.size : a.count > b.count;
diff --git a/tester/covoar/ReportsBase.cc b/tester/covoar/ReportsBase.cc
index 31dc429..b54f550 100644
--- a/tester/covoar/ReportsBase.cc
+++ b/tester/covoar/ReportsBase.cc
@@ -482,7 +482,7 @@ void ReportsBase::WriteSummaryReport(
}
}
- if (totalBytes == 0) {
+ if ( totalBytes == 0 ) {
percentage = 0;
} else {
percentage = (double) notExecuted;
--
1.8.3.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v1 1/2] ReportsBase.cc: Remove possible division by zero
On Tue, Jun 29, 2021 at 11:06 AM Ryan Long wrote:
>
> CID 1503709: Division or modulo by float zero
>
> Closes #4415
> ---
> tester/covoar/ReportsBase.cc | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/tester/covoar/ReportsBase.cc b/tester/covoar/ReportsBase.cc
> index b4a755c..31dc429 100644
> --- a/tester/covoar/ReportsBase.cc
> +++ b/tester/covoar/ReportsBase.cc
> @@ -482,9 +482,13 @@ void ReportsBase::WriteSummaryReport(
> }
>}
>
> - percentage = (double) notExecuted;
> - percentage /= (double) totalBytes;
> - percentage *= 100.0;
> + if (totalBytes == 0) {
> +percentage = 0;
> + } else {
> +percentage = (double) notExecuted;
> +percentage /= (double) totalBytes;
> +percentage *= 100.0;
ok, any good reason not to use one line? Just curious.
percentage = 100.0 * (double) notExecuted / totalBytes;
> + }
>
>percentageBranches = (double) (
> SymbolsToAnalyze->getNumberBranchesAlwaysTaken(symbolSetName) +
> --
> 1.8.3.1
>
> ___
> 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 v1 2/2] rtems-exeinfo.cpp: Fix division by zero errors
On Tue, Jun 29, 2021 at 11:06 AM Ryan Long wrote:
>
> CID 1503008: Division or modulo by zero
> CID 1503015: Division or modulo by zero
>
> Closes #4416
> ---
> linkers/rtems-exeinfo.cpp| 20
> tester/covoar/ReportsBase.cc | 2 +-
> 2 files changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/linkers/rtems-exeinfo.cpp b/linkers/rtems-exeinfo.cpp
> index 1e6d4b4..ec51597 100644
> --- a/linkers/rtems-exeinfo.cpp
> +++ b/linkers/rtems-exeinfo.cpp
> @@ -755,6 +755,8 @@ namespace rld
>size_t total = 0;
>size_t total_size = 0;
>size_t inlined_size = 0;
> + double percentage;
> + double percentage_size;
>dwarf::functions funcs_inlined;
>dwarf::functions funcs_not_inlined;
>func_counts counts;
> @@ -798,14 +800,24 @@ namespace rld
> }
>}
>
> + if ( total == 0 ) {
> +percentage = 0;
> + } else {
> +percentage = ( funcs_inlined.size() * 100 ) / total;
that's an integer result, if you're ok with it.
> + }
> +
> + if ( total_size == 0 ) {
> +percentage_size = 0;
> + } else {
> +percentage_size = ( inlined_size * 100 ) / total_size;
ditto
> + }
> +
>std::cout << "inlined funcs : " << funcs_inlined.size () << std::endl
> << "total funcs : " << total << std::endl
> -<< " % inline funcs : " << (funcs_inlined.size () * 100) /
> total << '%'
> -<< std::endl
> +<< " % inline funcs : " << percentage << '%' << std::endl
> << " total size : " << total_size << std::endl
> << "inline size : " << inlined_size << std::endl
> -<< " % inline size : " << (inlined_size * 100) / total_size
> << '%'
> -<< std::endl;
> +<< " % inline size : " << percentage_size << '%' <<
> std::endl;
>
>auto count_compare = [](func_count const & a, func_count const & b) {
> return a.size != b.size? a.size < b.size : a.count > b.count;
> diff --git a/tester/covoar/ReportsBase.cc b/tester/covoar/ReportsBase.cc
> index 31dc429..b54f550 100644
> --- a/tester/covoar/ReportsBase.cc
> +++ b/tester/covoar/ReportsBase.cc
> @@ -482,7 +482,7 @@ void ReportsBase::WriteSummaryReport(
> }
>}
>
> - if (totalBytes == 0) {
> + if ( totalBytes == 0 ) {
> percentage = 0;
>} else {
> percentage = (double) notExecuted;
> --
> 1.8.3.1
>
> ___
> 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 v1 1/2] ReportsBase.cc: Remove possible division by zero
On Tue, Jun 29, 2021 at 11:12 AM Gedare Bloom wrote:
>
> On Tue, Jun 29, 2021 at 11:06 AM Ryan Long wrote:
> >
> > CID 1503709: Division or modulo by float zero
> >
> > Closes #4415
> > ---
> > tester/covoar/ReportsBase.cc | 10 +++---
> > 1 file changed, 7 insertions(+), 3 deletions(-)
> >
> > diff --git a/tester/covoar/ReportsBase.cc b/tester/covoar/ReportsBase.cc
> > index b4a755c..31dc429 100644
> > --- a/tester/covoar/ReportsBase.cc
> > +++ b/tester/covoar/ReportsBase.cc
> > @@ -482,9 +482,13 @@ void ReportsBase::WriteSummaryReport(
> > }
> >}
> >
> > - percentage = (double) notExecuted;
> > - percentage /= (double) totalBytes;
> > - percentage *= 100.0;
> > + if (totalBytes == 0) {
squash your whitespace change from patch 2/2 into this commit.
> > +percentage = 0;
> > + } else {
> > +percentage = (double) notExecuted;
> > +percentage /= (double) totalBytes;
> > +percentage *= 100.0;
> ok, any good reason not to use one line? Just curious.
> percentage = 100.0 * (double) notExecuted / totalBytes;
>
> > + }
> >
> >percentageBranches = (double) (
> > SymbolsToAnalyze->getNumberBranchesAlwaysTaken(symbolSetName) +
> > --
> > 1.8.3.1
> >
> > ___
> > 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: GSOC: Adding all generated changes in patch to RSB?
On Tue, Jun 29, 2021 at 11:55 AM Matthew Joyce wrote: > > Dr. Joel, > > Thanks! This made me re-read your discord workflow advice from last > week, and it brings me to another question...You wrote: > > "You don't have to rebuild the entire toolsuite at this point. Just > add a functional test for sig2str.c to the testsuite (e.g. psxsigNN or > similar based on existing names). You have your implementation in your > local newlib patches." > > I did add the test, but I don't quite understand "you have your > implementation in your local newlib patches." Do you mean the > sig2str.c patch plus generated files? Where exactly is it supposed to > be? Yes. Your changes to newlib are captured in 1+ changes to hand-written source files and 1 patch to hold the generated files that really needed to change. > Am I following the instructions Vaibhav lays out minus the toolset > rebuilding? (patch in rtems/rsb/patches, calculate sha512, edit .cfg > used by .bset file?) > Yes. You only modified newlib and that's all that needs rebuilding until the RSB hashes change. You do not need to build binutils, gcc, gdb, and the other libraries every time. Plus using the RSB method, you are rebuilding newlib from scratch every time. Sometimes you will need to do a clean build but for the most part while editing a file in newlib that has been added to the Makefile.am, stuff regenerated, and a clean first "j-newlib" build with that, you can just do make/make install. > 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 don't know his step numbers but probably. The key is to be aware of when you need to build newlib from scratch and when you need to address the RSB. --joel > Thank you again for your help! > > Sincerely, > > Matt > > On Tue, Jun 29, 2021 at 3:45 PM Joel Sherrill wrote: > > > > On Tue, Jun 29, 2021 at 8:07 AM Matthew Joyce wrote: > > > > > > Dear Mentors, > > > > > > I've implemented my new functions locally in Newlib, created basic > > > tests in RTEMS, now I want to add the patches to the RSB to test them. > > > > > > I think I understand that once I submit these patches to newlib, they > > > should only include the added lines of source code...not any changes > > > generated through the build process. > > > > +1 > > > > > However, when I make a patch to add to RSB and test, I need to include > > > everything, right? There are probably about 100 modified files from > > > the reconf / build. Should I: > > > 1) "git add --all" to add the whole load of new files and changes > > > 2) make the commit > > > 3) git format patch > > > > Yes -- the RSB patch must include the generated files. But this patch set > > and RSB modifications are only for your use. Before RTEMS.org RSB is > > updated, the patch must be in the upstream newlib and we will just bump > > the newlib hash. That's why I suggested just building newlib (j-newlib, > > make, > > make install, etc) locally without the RSB and testing that way. > > > > With that said, there are a couple of things to do here: > > > > + Do NOT put generated files in your main patch. Make them a separate > > patch in the set so they are easy to ignore. > > > > + Reverse the generated changes to anything that shouldn't change based > > on what you touched. These are just due to autoconf version difference. In > > your > > case, I think this means you only need signal/Makefile.in. The rest are > > unneeded. > > > > + Only submit the patches with manual changes for review. Submit to devel@ > > and when it passes review, it goes to newlib. > > > > When the work is merged into newlib, you can update the RSB newlib hash > > and submit your tests to RTEMS. You will have to track the status of > > outstanding work and continue on to the next thing while the review process > > moves along. > > > > FWIW Eshan ended up tracking patches for a few months after last year's > > GSoC ended before we cleared his queue up. > > > > --joel > > > > > > > > Just want to make sure I'm understanding this point... > > > > > > Thank you! > > > > > > Sincerely, > > > > > > Matt ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RE: [PATCH v1 1/2] ReportsBase.cc: Remove possible division by zero
No good reason. I'll make those changes and send V2.
-Original Message-
From: Gedare Bloom
Sent: Tuesday, June 29, 2021 12:13 PM
To: Ryan Long
Cc: devel@rtems.org
Subject: Re: [PATCH v1 1/2] ReportsBase.cc: Remove possible division by zero
On Tue, Jun 29, 2021 at 11:06 AM Ryan Long wrote:
>
> CID 1503709: Division or modulo by float zero
>
> Closes #4415
> ---
> tester/covoar/ReportsBase.cc | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/tester/covoar/ReportsBase.cc
> b/tester/covoar/ReportsBase.cc index b4a755c..31dc429 100644
> --- a/tester/covoar/ReportsBase.cc
> +++ b/tester/covoar/ReportsBase.cc
> @@ -482,9 +482,13 @@ void ReportsBase::WriteSummaryReport(
> }
>}
>
> - percentage = (double) notExecuted;
> - percentage /= (double) totalBytes;
> - percentage *= 100.0;
> + if (totalBytes == 0) {
> +percentage = 0;
> + } else {
> +percentage = (double) notExecuted;
> +percentage /= (double) totalBytes;
> +percentage *= 100.0;
ok, any good reason not to use one line? Just curious.
percentage = 100.0 * (double) notExecuted / totalBytes;
> + }
>
>percentageBranches = (double) (
> SymbolsToAnalyze->getNumberBranchesAlwaysTaken(symbolSetName) +
> --
> 1.8.3.1
>
> ___
> 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
stm32h7 on libbsd?
I see STM32H7 was added to the nexus last year in March. Was libbsd/networking tested on any hardware devices? Thanks, Gedare ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH v2 2/2] rtems-exeinfo.cpp: Fix division by zero errors
CID 1503008: Division or modulo by zero
CID 1503015: Division or modulo by zero
Closes #4416
---
linkers/rtems-exeinfo.cpp | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/linkers/rtems-exeinfo.cpp b/linkers/rtems-exeinfo.cpp
index 1e6d4b4..ec51597 100644
--- a/linkers/rtems-exeinfo.cpp
+++ b/linkers/rtems-exeinfo.cpp
@@ -755,6 +755,8 @@ namespace rld
size_t total = 0;
size_t total_size = 0;
size_t inlined_size = 0;
+ double percentage;
+ double percentage_size;
dwarf::functions funcs_inlined;
dwarf::functions funcs_not_inlined;
func_counts counts;
@@ -798,14 +800,24 @@ namespace rld
}
}
+ if ( total == 0 ) {
+percentage = 0;
+ } else {
+percentage = ( funcs_inlined.size() * 100 ) / total;
+ }
+
+ if ( total_size == 0 ) {
+percentage_size = 0;
+ } else {
+percentage_size = ( inlined_size * 100 ) / total_size;
+ }
+
std::cout << "inlined funcs : " << funcs_inlined.size () << std::endl
<< "total funcs : " << total << std::endl
-<< " % inline funcs : " << (funcs_inlined.size () * 100) /
total << '%'
-<< std::endl
+<< " % inline funcs : " << percentage << '%' << std::endl
<< " total size : " << total_size << std::endl
<< "inline size : " << inlined_size << std::endl
-<< " % inline size : " << (inlined_size * 100) / total_size
<< '%'
-<< std::endl;
+<< " % inline size : " << percentage_size << '%' << std::endl;
auto count_compare = [](func_count const & a, func_count const & b) {
return a.size != b.size? a.size < b.size : a.count > b.count;
--
1.8.3.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH v2 1/2] ReportsBase.cc: Remove possible division by zero
CID 1503709: Division or modulo by float zero
Closes #4415
---
tester/covoar/ReportsBase.cc | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/tester/covoar/ReportsBase.cc b/tester/covoar/ReportsBase.cc
index b4a755c..328980d 100644
--- a/tester/covoar/ReportsBase.cc
+++ b/tester/covoar/ReportsBase.cc
@@ -482,9 +482,11 @@ void ReportsBase::WriteSummaryReport(
}
}
- percentage = (double) notExecuted;
- percentage /= (double) totalBytes;
- percentage *= 100.0;
+ if ( totalBytes == 0 ) {
+percentage = 0;
+ } else {
+percentage = 100.0 * (double) notExecuted / totalBytes;
+ }
percentageBranches = (double) (
SymbolsToAnalyze->getNumberBranchesAlwaysTaken(symbolSetName) +
--
1.8.3.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Testing SDIO drivers for ZynqMP in RTEMS-libbsd
Hello Stephen, testing SD drivers is a bit tricky. You can use the media01 and a SD card. As soon as the driver works, media01 will mount the SD card and you can write to it. I wrote a SD driver just recently. What was really useful for me was a logic analyzer that can be handled by sigrok (in my case it was a Saleae Logic). Sigrok can decode the SD commands and with that I was able to compare what the stack thought that it would send and what reached the hardware. For the analysis I reduced the Speed as far as possible for a SD card. Best regards Christian On 29/06/2021 18:07, Stephen Clark wrote: Hi, I’m working on updating the ZynqMP board’s nexus devices so that it will load SDHCI device drivers, but I’m not sure what the best way to test the drivers is. I don’t see an existing test for SDIO functionality in the libbsd test suites. Also, does anyone have any advice for running RTEMS in QEMU with SD cards? Thanks, Stephen Clark ___ 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: stm32h7 on libbsd?
Hello Gedare, 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. Best regards Christian On 29/06/2021 19:48, Gedare Bloom wrote: I see STM32H7 was added to the nexus last year in March. Was libbsd/networking tested on any hardware devices? Thanks, Gedare ___ 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 v2] bsps/arm: Move optfdt* files to shared parent directory
arm/imx7, arm/altcycv_devkit, arm/raspberrypi and arm/beagleboneblack
compile with the patch. I tried libbsd media01 on beagleboneblack and it
works.
Best regards
Christian
On 29/06/2021 18:56, Gedare Bloom wrote:
I don't have an arm toolchain, if someone can pick this up and test
compile the affected BSPs, it looks ok to me.
On Sun, Jun 27, 2021 at 2:46 PM pranav wrote:
---
.../arm/altera-cyclone-v/bspalteracyclonev.yml | 8
spec/build/bsps/arm/beagle/grp.yml | 8
spec/build/bsps/arm/beagle/optfdtcpyro.yml | 15 ---
spec/build/bsps/arm/beagle/optfdtmxsz.yml| 16
spec/build/bsps/arm/beagle/optfdtro.yml | 15 ---
spec/build/bsps/arm/beagle/optfdtuboot.yml | 15 ---
spec/build/bsps/arm/imx/bspimx.yml | 8
spec/build/bsps/arm/imx/optfdtcpyro.yml | 15 ---
spec/build/bsps/arm/imx/optfdtmxsz.yml | 16
spec/build/bsps/arm/imx/optfdtro.yml | 15 ---
spec/build/bsps/arm/imx/optfdtuboot.yml | 15 ---
.../arm/{altera-cyclone-v => }/optfdtcpyro.yml | 0
.../arm/{altera-cyclone-v => }/optfdtmxsz.yml| 0
.../bsps/arm/{altera-cyclone-v => }/optfdtro.yml | 0
.../arm/{altera-cyclone-v => }/optfdtuboot.yml | 0
spec/build/bsps/arm/raspberrypi/grp.yml | 8
16 files changed, 20 insertions(+), 134 deletions(-)
delete mode 100644 spec/build/bsps/arm/beagle/optfdtcpyro.yml
delete mode 100644 spec/build/bsps/arm/beagle/optfdtmxsz.yml
delete mode 100644 spec/build/bsps/arm/beagle/optfdtro.yml
delete mode 100644 spec/build/bsps/arm/beagle/optfdtuboot.yml
delete mode 100644 spec/build/bsps/arm/imx/optfdtcpyro.yml
delete mode 100644 spec/build/bsps/arm/imx/optfdtmxsz.yml
delete mode 100644 spec/build/bsps/arm/imx/optfdtro.yml
delete mode 100644 spec/build/bsps/arm/imx/optfdtuboot.yml
rename spec/build/bsps/arm/{altera-cyclone-v => }/optfdtcpyro.yml (100%)
rename spec/build/bsps/arm/{altera-cyclone-v => }/optfdtmxsz.yml (100%)
rename spec/build/bsps/arm/{altera-cyclone-v => }/optfdtro.yml (100%)
rename spec/build/bsps/arm/{altera-cyclone-v => }/optfdtuboot.yml (100%)
diff --git a/spec/build/bsps/arm/altera-cyclone-v/bspalteracyclonev.yml
b/spec/build/bsps/arm/altera-cyclone-v/bspalteracyclonev.yml
index da567ddd79..faf7203cd4 100644
--- a/spec/build/bsps/arm/altera-cyclone-v/bspalteracyclonev.yml
+++ b/spec/build/bsps/arm/altera-cyclone-v/bspalteracyclonev.yml
@@ -73,15 +73,15 @@ links:
- role: build-dependency
uid: optconuart1
- role: build-dependency
- uid: optfdtcpyro
+ uid: ../optfdtcpyro
- role: build-dependency
uid: optfdten
- role: build-dependency
- uid: optfdtmxsz
+ uid: ../optfdtmxsz
- role: build-dependency
- uid: optfdtro
+ uid: ../optfdtro
- role: build-dependency
- uid: optfdtuboot
+ uid: ../optfdtuboot
- role: build-dependency
uid: opti2cspeed
- role: build-dependency
diff --git a/spec/build/bsps/arm/beagle/grp.yml
b/spec/build/bsps/arm/beagle/grp.yml
index 1375913fd0..20fafa79a0 100644
--- a/spec/build/bsps/arm/beagle/grp.yml
+++ b/spec/build/bsps/arm/beagle/grp.yml
@@ -22,13 +22,13 @@ links:
- role: build-dependency
uid: optdm3730
- role: build-dependency
- uid: optfdtcpyro
+ uid: ../optfdtcpyro
- role: build-dependency
- uid: optfdtmxsz
+ uid: ../optfdtmxsz
- role: build-dependency
- uid: optfdtro
+ uid: ../optfdtro
- role: build-dependency
- uid: optfdtuboot
+ uid: ../optfdtuboot
- role: build-dependency
uid: ../grp
- role: build-dependency
diff --git a/spec/build/bsps/arm/beagle/optfdtcpyro.yml
b/spec/build/bsps/arm/beagle/optfdtcpyro.yml
deleted file mode 100644
index c26b1ae051..00
--- a/spec/build/bsps/arm/beagle/optfdtcpyro.yml
+++ /dev/null
@@ -1,15 +0,0 @@
-SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
-actions:
-- get-boolean: null
-- define-condition: null
-build-type: option
-copyrights:
-- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
-default: true
-default-by-variant: []
-description: |
- copy the FDT blob into the read-only load area via bsp_fdt_copy()
-enabled-by: true
-links: []
-name: BSP_FDT_BLOB_COPY_TO_READ_ONLY_LOAD_AREA
-type: build
diff --git a/spec/build/bsps/arm/beagle/optfdtmxsz.yml
b/spec/build/bsps/arm/beagle/optfdtmxsz.yml
deleted file mode 100644
index 14af766230..00
--- a/spec/build/bsps/arm/beagle/optfdtmxsz.yml
+++ /dev/null
@@ -1,16 +0,0 @@
-SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
-actions:
-- get-integer: null
-- define: null
-build-type: option
-copyrights:
-- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
-default: 262144
-default-by-variant: []
-description: |
- maximum size of the FDT blob in bytes
-enabled-by: true
-format: '{}'
-links: []
-name: BSP_FDT_BLOB_SIZE_MAX
-type: build
diff --git a/spec/buil
Re: [PATCH v2] bsps/arm: Move optfdt* files to shared parent directory
PS: Wouldn't it make sense to move these even further up? There is for
example ./spec/build/bsps/riscv/riscv/optfdtcpyro.yml too. A short md5
shows that it's the same file again.
Best regards
Christian
On 29/06/2021 20:23, Christian Mauderer wrote:
arm/imx7, arm/altcycv_devkit, arm/raspberrypi and arm/beagleboneblack
compile with the patch. I tried libbsd media01 on beagleboneblack and it
works.
Best regards
Christian
On 29/06/2021 18:56, Gedare Bloom wrote:
I don't have an arm toolchain, if someone can pick this up and test
compile the affected BSPs, it looks ok to me.
On Sun, Jun 27, 2021 at 2:46 PM pranav wrote:
---
.../arm/altera-cyclone-v/bspalteracyclonev.yml | 8
spec/build/bsps/arm/beagle/grp.yml | 8
spec/build/bsps/arm/beagle/optfdtcpyro.yml | 15 ---
spec/build/bsps/arm/beagle/optfdtmxsz.yml | 16
spec/build/bsps/arm/beagle/optfdtro.yml | 15 ---
spec/build/bsps/arm/beagle/optfdtuboot.yml | 15 ---
spec/build/bsps/arm/imx/bspimx.yml | 8
spec/build/bsps/arm/imx/optfdtcpyro.yml | 15 ---
spec/build/bsps/arm/imx/optfdtmxsz.yml | 16
spec/build/bsps/arm/imx/optfdtro.yml | 15 ---
spec/build/bsps/arm/imx/optfdtuboot.yml | 15 ---
.../arm/{altera-cyclone-v => }/optfdtcpyro.yml | 0
.../arm/{altera-cyclone-v => }/optfdtmxsz.yml | 0
.../bsps/arm/{altera-cyclone-v => }/optfdtro.yml | 0
.../arm/{altera-cyclone-v => }/optfdtuboot.yml | 0
spec/build/bsps/arm/raspberrypi/grp.yml | 8
16 files changed, 20 insertions(+), 134 deletions(-)
delete mode 100644 spec/build/bsps/arm/beagle/optfdtcpyro.yml
delete mode 100644 spec/build/bsps/arm/beagle/optfdtmxsz.yml
delete mode 100644 spec/build/bsps/arm/beagle/optfdtro.yml
delete mode 100644 spec/build/bsps/arm/beagle/optfdtuboot.yml
delete mode 100644 spec/build/bsps/arm/imx/optfdtcpyro.yml
delete mode 100644 spec/build/bsps/arm/imx/optfdtmxsz.yml
delete mode 100644 spec/build/bsps/arm/imx/optfdtro.yml
delete mode 100644 spec/build/bsps/arm/imx/optfdtuboot.yml
rename spec/build/bsps/arm/{altera-cyclone-v => }/optfdtcpyro.yml
(100%)
rename spec/build/bsps/arm/{altera-cyclone-v => }/optfdtmxsz.yml
(100%)
rename spec/build/bsps/arm/{altera-cyclone-v => }/optfdtro.yml (100%)
rename spec/build/bsps/arm/{altera-cyclone-v => }/optfdtuboot.yml
(100%)
diff --git
a/spec/build/bsps/arm/altera-cyclone-v/bspalteracyclonev.yml
b/spec/build/bsps/arm/altera-cyclone-v/bspalteracyclonev.yml
index da567ddd79..faf7203cd4 100644
--- a/spec/build/bsps/arm/altera-cyclone-v/bspalteracyclonev.yml
+++ b/spec/build/bsps/arm/altera-cyclone-v/bspalteracyclonev.yml
@@ -73,15 +73,15 @@ links:
- role: build-dependency
uid: optconuart1
- role: build-dependency
- uid: optfdtcpyro
+ uid: ../optfdtcpyro
- role: build-dependency
uid: optfdten
- role: build-dependency
- uid: optfdtmxsz
+ uid: ../optfdtmxsz
- role: build-dependency
- uid: optfdtro
+ uid: ../optfdtro
- role: build-dependency
- uid: optfdtuboot
+ uid: ../optfdtuboot
- role: build-dependency
uid: opti2cspeed
- role: build-dependency
diff --git a/spec/build/bsps/arm/beagle/grp.yml
b/spec/build/bsps/arm/beagle/grp.yml
index 1375913fd0..20fafa79a0 100644
--- a/spec/build/bsps/arm/beagle/grp.yml
+++ b/spec/build/bsps/arm/beagle/grp.yml
@@ -22,13 +22,13 @@ links:
- role: build-dependency
uid: optdm3730
- role: build-dependency
- uid: optfdtcpyro
+ uid: ../optfdtcpyro
- role: build-dependency
- uid: optfdtmxsz
+ uid: ../optfdtmxsz
- role: build-dependency
- uid: optfdtro
+ uid: ../optfdtro
- role: build-dependency
- uid: optfdtuboot
+ uid: ../optfdtuboot
- role: build-dependency
uid: ../grp
- role: build-dependency
diff --git a/spec/build/bsps/arm/beagle/optfdtcpyro.yml
b/spec/build/bsps/arm/beagle/optfdtcpyro.yml
deleted file mode 100644
index c26b1ae051..00
--- a/spec/build/bsps/arm/beagle/optfdtcpyro.yml
+++ /dev/null
@@ -1,15 +0,0 @@
-SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
-actions:
-- get-boolean: null
-- define-condition: null
-build-type: option
-copyrights:
-- Copyright (C) 2020 embedded brains GmbH
(http://www.embedded-brains.de)
-default: true
-default-by-variant: []
-description: |
- copy the FDT blob into the read-only load area via bsp_fdt_copy()
-enabled-by: true
-links: []
-name: BSP_FDT_BLOB_COPY_TO_READ_ONLY_LOAD_AREA
-type: build
diff --git a/spec/build/bsps/arm/beagle/optfdtmxsz.yml
b/spec/build/bsps/arm/beagle/optfdtmxsz.yml
deleted file mode 100644
index 14af766230..00
--- a/spec/build/bsps/arm/beagle/optfdtmxsz.yml
+++ /dev/null
@@ -1,16 +0,0 @@
-SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
-actions:
-- get-integer: null
-- define: null
-build-type: option
-copyrights:
-- Copyright
Re: Question about Raspberry Pi bspstarthooks.c - potential patch
Hi Sebastian, I understand the move in that commit now. Maybe it's not working on the single core models because the code is conditional for ARMV7 + A or ARMV8? https://git.rtems.org/rtems/tree/bsps/arm/shared/start/start.S#n485 I think the single core RPIs are ARM1176JZF-S (ARMv6Z). Do the conditional defines come from the compiler? Thanks, Alan On Tue, Jun 29, 2021 at 1:42 AM Sebastian Huber wrote: > > Hello Alan, > > On 29/06/2021 03:13, Alan Cudmore wrote: > > The current RTEMS 6/master branch does not seem to work on the > > Raspberry Pi single core models, while the 5 branch does. > > > > I was able to track it down to a commit where it stopped working: > > 272534eb725f2486b7a32b39d998202a101bd36e > > > > In that commit, the call: > > /* Clear Secure or Non-secure Vector Base Address Register */ > >arm_cp15_set_vector_base_address(bsp_vector_table_begin); > > > > Was moved from bsp_start_hook_0 to rpi_start_rtems_on_secondary_processor. > > > > If I add it back to bsp_start_hook_0, the single core models work again. > > I moved the VBAR setting to start.S. Maybe the problem is that TTBCR is > no longer set to zero before the VBAR is set. The Raspberry Pi BSP is > the only BSP which did 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: Question about Raspberry Pi bspstarthooks.c - potential patch
On 29/06/2021 20:56, Alan Cudmore wrote: I understand the move in that commit now. Maybe it's not working on the single core models because the code is conditional for ARMV7 + A or ARMV8? https://git.rtems.org/rtems/tree/bsps/arm/shared/start/start.S#n485 I think the single core RPIs are ARM1176JZF-S (ARMv6Z). Oh, yes, this is probably the problem. I wasn't aware that we have a BSP which uses Armv6. I will try to figure out the right options. Do the conditional defines come from the compiler? Yes, these are compiler built-in defines. -- 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 v2 2/2] rtems-exeinfo.cpp: Fix division by zero errors
On Tue, Jun 29, 2021 at 11:50 AM Ryan Long wrote:
>
> CID 1503008: Division or modulo by zero
> CID 1503015: Division or modulo by zero
>
> Closes #4416
> ---
> linkers/rtems-exeinfo.cpp | 20
> 1 file changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/linkers/rtems-exeinfo.cpp b/linkers/rtems-exeinfo.cpp
> index 1e6d4b4..ec51597 100644
> --- a/linkers/rtems-exeinfo.cpp
> +++ b/linkers/rtems-exeinfo.cpp
> @@ -755,6 +755,8 @@ namespace rld
>size_t total = 0;
>size_t total_size = 0;
>size_t inlined_size = 0;
> + double percentage;
> + double percentage_size;
>dwarf::functions funcs_inlined;
>dwarf::functions funcs_not_inlined;
>func_counts counts;
> @@ -798,14 +800,24 @@ namespace rld
> }
>}
>
> + if ( total == 0 ) {
> +percentage = 0;
> + } else {
> +percentage = ( funcs_inlined.size() * 100 ) / total;
> + }
> +
> + if ( total_size == 0 ) {
> +percentage_size = 0;
> + } else {
> +percentage_size = ( inlined_size * 100 ) / total_size;
These are still integer results. If you want double, you should cast,
if you want integer, you should use int type for the percentage and
percentage_size variables.
> + }
> +
>std::cout << "inlined funcs : " << funcs_inlined.size () << std::endl
> << "total funcs : " << total << std::endl
> -<< " % inline funcs : " << (funcs_inlined.size () * 100) /
> total << '%'
> -<< std::endl
> +<< " % inline funcs : " << percentage << '%' << std::endl
> << " total size : " << total_size << std::endl
> << "inline size : " << inlined_size << std::endl
> -<< " % inline size : " << (inlined_size * 100) / total_size
> << '%'
> -<< std::endl;
> +<< " % inline size : " << percentage_size << '%' <<
> std::endl;
>
>auto count_compare = [](func_count const & a, func_count const & b) {
> return a.size != b.size? a.size < b.size : a.count > b.count;
> --
> 1.8.3.1
>
> ___
> 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: Question about Raspberry Pi bspstarthooks.c - potential patch
On Tue, Jun 29, 2021 at 3:01 PM Sebastian Huber wrote: > > On 29/06/2021 20:56, Alan Cudmore wrote: > > I understand the move in that commit now. > > Maybe it's not working on the single core models because the code is > > conditional for ARMV7 + A or ARMV8? > > https://git.rtems.org/rtems/tree/bsps/arm/shared/start/start.S#n485 > > I think the single core RPIs are ARM1176JZF-S (ARMv6Z). > > Oh, yes, this is probably the problem. I wasn't aware that we have a BSP > which uses Armv6. I will try to figure out the right options. Thanks! As soon as you have something that would work, we can test it. The CPU architecture is old, but it looks like these models will be in production until at least 2026. > > > Do the conditional defines come from the compiler? > > Yes, these are compiler built-in defines. > > -- > 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: GSoC - Code Formatting and Style Checking for RTEMS score
Hello mentors, Here is the code for my pre-commit hook script. How it works is by default, upon commiting it outputs a warning stating the number of style issues in case there are mismatches. The user can trigger the strict mode which gives a more detailed output of the style issues by running adding the mode to the config file ( git config mode "strict") - will document this. https://github.com/Idadelveloper/rtems/blob/master/hooks/pre-commit I had already sent some screenshots here on how the outcome looks like. Will love to improve my code based on your feedback and get more suggestions. On Mon, Jun 21, 2021 at 7:05 PM Gedare Bloom wrote: > > > On Sun, Jun 20, 2021 at 1:13 AM Ida Delphine wrote: > >> Hello everyone, >> I updated the hooks script. About the modes, we have the default, >> "strict" and "nonstrict" (couldn't think of better names). With the default >> mode, it prints a warning specifying the number of style issues if any and >> aborts the commit. With the strict mode, it goes into more detail showing >> both the formatted and unformatted patch, the number of style issues, and >> aborts the commit. In the non-strict mode, it simply displays the warning >> with the style issues and the commit happens. >> >> The default mode basically happens when you run >> >>> git commit -m "Commit message" >>> >> The best method I could find to pass arguments to a script was via >> environment variables. So the nonstrict mode applies when you run >> >>> STYLEMODE=nonstrict git commit -m "Commit message" >>> >> The strict mode applies when you run >> >>> STYLEMODE=strict git commit -m "Commit message" >>> >> >> What are the possible options to pass arguments? (Maybe, a blog post :)) > Reading from a git-config file would be better than environment variables. > > It might be better to share screenshots by a link (e.g., a blog post :)) > to avoid hitting the mailing list attachment limits. > > Gedare > >> ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Question about Raspberry Pi bspstarthooks.c - potential patch
Also, if you do not have time, we could research a solution ( guidance is welcome! ) Alan On Tue, Jun 29, 2021 at 3:09 PM Alan Cudmore wrote: > > On Tue, Jun 29, 2021 at 3:01 PM Sebastian Huber > wrote: > > > > On 29/06/2021 20:56, Alan Cudmore wrote: > > > I understand the move in that commit now. > > > Maybe it's not working on the single core models because the code is > > > conditional for ARMV7 + A or ARMV8? > > > https://git.rtems.org/rtems/tree/bsps/arm/shared/start/start.S#n485 > > > I think the single core RPIs are ARM1176JZF-S (ARMv6Z). > > > > Oh, yes, this is probably the problem. I wasn't aware that we have a BSP > > which uses Armv6. I will try to figure out the right options. > > Thanks! As soon as you have something that would work, we can test it. > The CPU architecture is old, but it looks like these models will be in > production until at least 2026. > > > > > > Do the conditional defines come from the compiler? > > > > Yes, these are compiler built-in defines. > > > > -- > > 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 v2 2/2] rtems-exeinfo.cpp: Fix division by zero errors
I'll cast those. Sorry I missed that.
-Original Message-
From: Gedare Bloom
Sent: Tuesday, June 29, 2021 2:03 PM
To: Ryan Long
Cc: devel@rtems.org
Subject: Re: [PATCH v2 2/2] rtems-exeinfo.cpp: Fix division by zero errors
On Tue, Jun 29, 2021 at 11:50 AM Ryan Long wrote:
>
> CID 1503008: Division or modulo by zero CID 1503015: Division or
> modulo by zero
>
> Closes #4416
> ---
> linkers/rtems-exeinfo.cpp | 20
> 1 file changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/linkers/rtems-exeinfo.cpp b/linkers/rtems-exeinfo.cpp
> index 1e6d4b4..ec51597 100644
> --- a/linkers/rtems-exeinfo.cpp
> +++ b/linkers/rtems-exeinfo.cpp
> @@ -755,6 +755,8 @@ namespace rld
>size_t total = 0;
>size_t total_size = 0;
>size_t inlined_size = 0;
> + double percentage;
> + double percentage_size;
>dwarf::functions funcs_inlined;
>dwarf::functions funcs_not_inlined;
>func_counts counts;
> @@ -798,14 +800,24 @@ namespace rld
> }
>}
>
> + if ( total == 0 ) {
> +percentage = 0;
> + } else {
> +percentage = ( funcs_inlined.size() * 100 ) / total;
> + }
> +
> + if ( total_size == 0 ) {
> +percentage_size = 0;
> + } else {
> +percentage_size = ( inlined_size * 100 ) / total_size;
These are still integer results. If you want double, you should cast, if you
want integer, you should use int type for the percentage and percentage_size
variables.
> + }
> +
>std::cout << "inlined funcs : " << funcs_inlined.size () << std::endl
> << "total funcs : " << total << std::endl
> -<< " % inline funcs : " << (funcs_inlined.size () * 100) /
> total << '%'
> -<< std::endl
> +<< " % inline funcs : " << percentage << '%' <<
> + std::endl
> << " total size : " << total_size << std::endl
> << "inline size : " << inlined_size << std::endl
> -<< " % inline size : " << (inlined_size * 100) / total_size
> << '%'
> -<< std::endl;
> +<< " % inline size : " << percentage_size << '%' <<
> + std::endl;
>
>auto count_compare = [](func_count const & a, func_count const & b) {
> return a.size != b.size? a.size < b.size : a.count >
> b.count;
> --
> 1.8.3.1
>
> ___
> 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 v3 2/2] rtems-exeinfo.cpp: Fix division by zero errors
CID 1503008: Division or modulo by zero
CID 1503015: Division or modulo by zero
Closes #4416
---
linkers/rtems-exeinfo.cpp | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/linkers/rtems-exeinfo.cpp b/linkers/rtems-exeinfo.cpp
index 1e6d4b4..6e92206 100644
--- a/linkers/rtems-exeinfo.cpp
+++ b/linkers/rtems-exeinfo.cpp
@@ -755,6 +755,8 @@ namespace rld
size_t total = 0;
size_t total_size = 0;
size_t inlined_size = 0;
+ double percentage;
+ double percentage_size;
dwarf::functions funcs_inlined;
dwarf::functions funcs_not_inlined;
func_counts counts;
@@ -798,14 +800,24 @@ namespace rld
}
}
+ if ( total == 0 ) {
+percentage = 0;
+ } else {
+percentage = (double) ( funcs_inlined.size() * 100 ) / total;
+ }
+
+ if ( total_size == 0 ) {
+percentage_size = 0;
+ } else {
+percentage_size = (double) ( inlined_size * 100 ) / total_size;
+ }
+
std::cout << "inlined funcs : " << funcs_inlined.size () << std::endl
<< "total funcs : " << total << std::endl
-<< " % inline funcs : " << (funcs_inlined.size () * 100) /
total << '%'
-<< std::endl
+<< " % inline funcs : " << percentage << '%' << std::endl
<< " total size : " << total_size << std::endl
<< "inline size : " << inlined_size << std::endl
-<< " % inline size : " << (inlined_size * 100) / total_size
<< '%'
-<< std::endl;
+<< " % inline size : " << percentage_size << '%' << std::endl;
auto count_compare = [](func_count const & a, func_count const & b) {
return a.size != b.size? a.size < b.size : a.count > b.count;
--
1.8.3.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH v3 1/2] ReportsBase.cc: Remove possible division by zero
CID 1503709: Division or modulo by float zero
Closes #4415
---
tester/covoar/ReportsBase.cc | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/tester/covoar/ReportsBase.cc b/tester/covoar/ReportsBase.cc
index b4a755c..328980d 100644
--- a/tester/covoar/ReportsBase.cc
+++ b/tester/covoar/ReportsBase.cc
@@ -482,9 +482,11 @@ void ReportsBase::WriteSummaryReport(
}
}
- percentage = (double) notExecuted;
- percentage /= (double) totalBytes;
- percentage *= 100.0;
+ if ( totalBytes == 0 ) {
+percentage = 0;
+ } else {
+percentage = 100.0 * (double) notExecuted / totalBytes;
+ }
percentageBranches = (double) (
SymbolsToAnalyze->getNumberBranchesAlwaysTaken(symbolSetName) +
--
1.8.3.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
RE: [PATCH] bsps/cadence-spi: Fix moduleid offset
> -Original Message-
> From: Gedare Bloom
> Sent: Tuesday, June 29, 2021 6:22 PM
> To: Kinsey Moore ; Sommer, Jan
>
> Cc: devel@rtems.org
> Subject: Re: [PATCH] bsps/cadence-spi: Fix moduleid offset
>
> Jan, please confirm. Thanks
>
Looks good to me.
Thanks,
Jan
> On Mon, Jun 28, 2021 at 7:06 AM Kinsey Moore
> wrote:
> >
> > Move the moduleid register to the correct offset according to Cadence
> > IP documentation.
> > ---
> > bsps/include/dev/spi/cadence-spi-regs.h | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/bsps/include/dev/spi/cadence-spi-regs.h
> > b/bsps/include/dev/spi/cadence-spi-regs.h
> > index b4b2366b3d..207d056fb1 100644
> > --- a/bsps/include/dev/spi/cadence-spi-regs.h
> > +++ b/bsps/include/dev/spi/cadence-spi-regs.h
> > @@ -78,6 +78,7 @@ typedef struct {
> > uint32_t slave_idle_count;
> > uint32_t txthreshold;
> > uint32_t rxthreshold;
> > + uint32_t unused[51];
> > uint32_t moduleid;
> > } cadence_spi;
> >
> > --
> > 2.20.1
> >
> > ___
> > 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 1/3] cpukit/libmisc/rtems-ftd: Fixed error of null pointer dereference in rtems-fdt.c
See Also CID 1437647 Closes #4460 --- cpukit/libmisc/rtems-fdt/rtems-fdt.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/cpukit/libmisc/rtems-fdt/rtems-fdt.c b/cpukit/libmisc/rtems-fdt/rtems-fdt.c index 7747ba9bf8..bfbc6102a2 100644 --- a/cpukit/libmisc/rtems-fdt/rtems-fdt.c +++ b/cpukit/libmisc/rtems-fdt/rtems-fdt.c @@ -678,14 +678,14 @@ rtems_fdt_unload (rtems_fdt_handle* handle) rtems_chain_extract_unprotected (&handle->blob->node); + rtems_fdt_release_index(&handle->blob->index); + free (handle->blob); handle->blob = NULL; rtems_fdt_unlock (fdt); - rtems_fdt_release_index(&handle->blob->index); - return 0; } -- 2.25.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 2/3] cpukit/libmisc/rtems-fdt: Fixes leaked variable 'bf' in rtems-fdt.c
See Also CID 1437645 Closes #4297 --- cpukit/libmisc/rtems-fdt/rtems-fdt.c | 1 + 1 file changed, 1 insertion(+) diff --git a/cpukit/libmisc/rtems-fdt/rtems-fdt.c b/cpukit/libmisc/rtems-fdt/rtems-fdt.c index bfbc6102a2..5580d415e2 100644 --- a/cpukit/libmisc/rtems-fdt/rtems-fdt.c +++ b/cpukit/libmisc/rtems-fdt/rtems-fdt.c @@ -611,6 +611,7 @@ rtems_fdt_load (const char* filename, rtems_fdt_handle* handle) return fe; } + close (bf); return 0; } -- 2.25.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 3/3] cpukit/libmisc/rtems-fdt: Fix of unreachable statement in rtems-fdt.c
See Also CID 1437638
Closes #4462
---
cpukit/libmisc/rtems-fdt/rtems-fdt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cpukit/libmisc/rtems-fdt/rtems-fdt.c
b/cpukit/libmisc/rtems-fdt/rtems-fdt.c
index 5580d415e2..b1bb26572d 100644
--- a/cpukit/libmisc/rtems-fdt/rtems-fdt.c
+++ b/cpukit/libmisc/rtems-fdt/rtems-fdt.c
@@ -163,7 +163,7 @@ rtems_fdt_init_index (rtems_fdt_handle* fdt,
rtems_fdt_blob* blob)
}
names = calloc(1, total_name_memory);
- if (!entries)
+ if (!names)
{
free(entries);
return -RTEMS_FDT_ERR_NO_MEMORY;
--
2.25.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 1/3] cpukit/libmisc/rtems-ftd: Fixed error of null pointer dereference in rtems-fdt.c
This definitely moves the dereference before the free() so appears to be OK. If Gedare approves, he can merge it. --joel On Tue, Jun 29, 2021 at 2:54 PM Harrison Edward Gerber wrote: > > See Also CID 1437647 > > Closes #4460 > --- > cpukit/libmisc/rtems-fdt/rtems-fdt.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/cpukit/libmisc/rtems-fdt/rtems-fdt.c > b/cpukit/libmisc/rtems-fdt/rtems-fdt.c > index 7747ba9bf8..bfbc6102a2 100644 > --- a/cpukit/libmisc/rtems-fdt/rtems-fdt.c > +++ b/cpukit/libmisc/rtems-fdt/rtems-fdt.c > @@ -678,14 +678,14 @@ rtems_fdt_unload (rtems_fdt_handle* handle) > >rtems_chain_extract_unprotected (&handle->blob->node); > > + rtems_fdt_release_index(&handle->blob->index); > + >free (handle->blob); > >handle->blob = NULL; > >rtems_fdt_unlock (fdt); > > - rtems_fdt_release_index(&handle->blob->index); > - >return 0; > } > > -- > 2.25.1 > > ___ > 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 2/3] cpukit/libmisc/rtems-fdt: Fixes leaked variable 'bf' in rtems-fdt.c
I'm ok with the fix but the commit message could be improved. Something like this would be better. cpukit/libmisc/rtems-fdt.c : close() file to avoid leaking descriptor You almost duplicated the base file name and it isn't leaking the variable, it is leaking the file descriptor referenced by bf. --joel On Tue, Jun 29, 2021 at 2:54 PM Harrison Edward Gerber wrote: > > See Also CID 1437645 > > Closes #4297 > --- > cpukit/libmisc/rtems-fdt/rtems-fdt.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/cpukit/libmisc/rtems-fdt/rtems-fdt.c > b/cpukit/libmisc/rtems-fdt/rtems-fdt.c > index bfbc6102a2..5580d415e2 100644 > --- a/cpukit/libmisc/rtems-fdt/rtems-fdt.c > +++ b/cpukit/libmisc/rtems-fdt/rtems-fdt.c > @@ -611,6 +611,7 @@ rtems_fdt_load (const char* filename, rtems_fdt_handle* > handle) > return fe; >} > > + close (bf); >return 0; > } > > -- > 2.25.1 > > ___ > 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 1/3] cpukit/libmisc/rtems-ftd: Fixed error of null pointer dereference in rtems-fdt.c
Same issue to improve the commit message as I just emailed. Something like this would be better: cpukit/libmisc/rtems-ftd.c: Fixed error of null pointer dereference On Tue, Jun 29, 2021 at 3:07 PM Joel Sherrill wrote: > > This definitely moves the dereference before the free() so appears to be OK. > > If Gedare approves, he can merge it. > > --joel > > On Tue, Jun 29, 2021 at 2:54 PM Harrison Edward Gerber > wrote: > > > > See Also CID 1437647 > > > > Closes #4460 > > --- > > cpukit/libmisc/rtems-fdt/rtems-fdt.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/cpukit/libmisc/rtems-fdt/rtems-fdt.c > > b/cpukit/libmisc/rtems-fdt/rtems-fdt.c > > index 7747ba9bf8..bfbc6102a2 100644 > > --- a/cpukit/libmisc/rtems-fdt/rtems-fdt.c > > +++ b/cpukit/libmisc/rtems-fdt/rtems-fdt.c > > @@ -678,14 +678,14 @@ rtems_fdt_unload (rtems_fdt_handle* handle) > > > >rtems_chain_extract_unprotected (&handle->blob->node); > > > > + rtems_fdt_release_index(&handle->blob->index); > > + > >free (handle->blob); > > > >handle->blob = NULL; > > > >rtems_fdt_unlock (fdt); > > > > - rtems_fdt_release_index(&handle->blob->index); > > - > >return 0; > > } > > > > -- > > 2.25.1 > > > > ___ > > 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 3/3] cpukit/libmisc/rtems-fdt: Fix of unreachable statement in rtems-fdt.c
OK with code. Commit message needs correction per suggestions in other
patches in this series.
--joel
On Tue, Jun 29, 2021 at 2:54 PM Harrison Edward Gerber
wrote:
>
> See Also CID 1437638
>
> Closes #4462
> ---
> cpukit/libmisc/rtems-fdt/rtems-fdt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/cpukit/libmisc/rtems-fdt/rtems-fdt.c
> b/cpukit/libmisc/rtems-fdt/rtems-fdt.c
> index 5580d415e2..b1bb26572d 100644
> --- a/cpukit/libmisc/rtems-fdt/rtems-fdt.c
> +++ b/cpukit/libmisc/rtems-fdt/rtems-fdt.c
> @@ -163,7 +163,7 @@ rtems_fdt_init_index (rtems_fdt_handle* fdt,
> rtems_fdt_blob* blob)
>}
>
>names = calloc(1, total_name_memory);
> - if (!entries)
> + if (!names)
>{
> free(entries);
> return -RTEMS_FDT_ERR_NO_MEMORY;
> --
> 2.25.1
>
> ___
> 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 2/3] cpukit/libmisc/rtems-fdt: Fixes leaked variable 'bf' in rtems-fdt.c
On Tue, Jun 29, 2021 at 3:15 PM Harrison Gerber wrote: > > Joel, > > I'm not too sure what is meant by almost duplicating the base file name. The > file referenced is 'rtems-fdt.c', which is found in a file called 'rtems-fdt' > inside libmisc, so I thought it was best to have the entire directory path at > the front and the name of the file being altered in the description. Let me > know if this is not correct; I'm not totally sure what is meant here, but the > rest I understand! This also is important to your response to the third patch > in this series. > basename is a POSIX command/term for part of the path. dirname is the directory portion. /home/joel/source.c dirname portion -> /home/joel basename portion -> source.c cpukit/libmisc/rtems-fdt: Fixes leaked variable 'bf' in rtems-fdt.c I see now that the directory rtems-fdt is similar to the source file so it wasn't quite as redundant as I thought. How about this? cpukit/libmisc/rtems-fdt/rtems-fdt.c: close() file to avoid leaking descriptor That makes the filename clear and doesn't waste characters with "in " Personally, if the comment needed to longer, I would be ok ditching the cpukit/ part but you don't need to do that for space. > Thanks for the quick response! > No problem. It takes a village to review patches. :) --joel > Harrison Gerber > hger...@uccs.edu > 720-288-7308 > > -Original Message- > From: Joel Sherrill > Sent: Tuesday, June 29, 2021 2:09 PM > To: Harrison Edward Gerber > Cc: rtems-de...@rtems.org ; Harrison Gerber > > Subject: Re: [PATCH 2/3] cpukit/libmisc/rtems-fdt: Fixes leaked variable 'bf' > in rtems-fdt.c > > I'm ok with the fix but the commit message could be improved. > Something like this would be better. > > cpukit/libmisc/rtems-fdt.c : close() file to avoid leaking descriptor > > You almost duplicated the base file name and it isn't leaking the variable, > it is leaking the file descriptor referenced by bf. > > --joel > > On Tue, Jun 29, 2021 at 2:54 PM Harrison Edward Gerber > wrote: > > > > See Also CID 1437645 > > > > Closes #4297 > > --- > > cpukit/libmisc/rtems-fdt/rtems-fdt.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/cpukit/libmisc/rtems-fdt/rtems-fdt.c > > b/cpukit/libmisc/rtems-fdt/rtems-fdt.c > > index bfbc6102a2..5580d415e2 100644 > > --- a/cpukit/libmisc/rtems-fdt/rtems-fdt.c > > +++ b/cpukit/libmisc/rtems-fdt/rtems-fdt.c > > @@ -611,6 +611,7 @@ rtems_fdt_load (const char* filename, rtems_fdt_handle* > > handle) > > return fe; > >} > > > > + close (bf); > >return 0; > > } > > > > -- > > 2.25.1 > > > > ___ > > 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 v2] bsps/arm: Move optfdt* files to shared parent directory
On Tue, Jun 29, 2021 at 12:27 PM Christian Mauderer wrote:
>
> PS: Wouldn't it make sense to move these even further up? There is for
> example ./spec/build/bsps/riscv/riscv/optfdtcpyro.yml too. A short md5
> shows that it's the same file again.
>
Yes. Pranav, can you prepare a patch to move these into spec/build/bsps?
I see
cd spec/build/bsps
grep -r FDT_BLOB
powerpc/qoriq
pops up too.
> Best regards
>
> Christian
>
> On 29/06/2021 20:23, Christian Mauderer wrote:
> > arm/imx7, arm/altcycv_devkit, arm/raspberrypi and arm/beagleboneblack
> > compile with the patch. I tried libbsd media01 on beagleboneblack and it
> > works.
> >
> > Best regards
> >
> > Christian
> >
> > On 29/06/2021 18:56, Gedare Bloom wrote:
> >> I don't have an arm toolchain, if someone can pick this up and test
> >> compile the affected BSPs, it looks ok to me.
> >>
> >> On Sun, Jun 27, 2021 at 2:46 PM pranav wrote:
> >>>
> >>> ---
> >>> .../arm/altera-cyclone-v/bspalteracyclonev.yml | 8
> >>> spec/build/bsps/arm/beagle/grp.yml | 8
> >>> spec/build/bsps/arm/beagle/optfdtcpyro.yml | 15 ---
> >>> spec/build/bsps/arm/beagle/optfdtmxsz.yml| 16
> >>> spec/build/bsps/arm/beagle/optfdtro.yml | 15 ---
> >>> spec/build/bsps/arm/beagle/optfdtuboot.yml | 15 ---
> >>> spec/build/bsps/arm/imx/bspimx.yml | 8
> >>> spec/build/bsps/arm/imx/optfdtcpyro.yml | 15 ---
> >>> spec/build/bsps/arm/imx/optfdtmxsz.yml | 16
> >>> spec/build/bsps/arm/imx/optfdtro.yml | 15 ---
> >>> spec/build/bsps/arm/imx/optfdtuboot.yml | 15 ---
> >>> .../arm/{altera-cyclone-v => }/optfdtcpyro.yml | 0
> >>> .../arm/{altera-cyclone-v => }/optfdtmxsz.yml| 0
> >>> .../bsps/arm/{altera-cyclone-v => }/optfdtro.yml | 0
> >>> .../arm/{altera-cyclone-v => }/optfdtuboot.yml | 0
> >>> spec/build/bsps/arm/raspberrypi/grp.yml | 8
> >>> 16 files changed, 20 insertions(+), 134 deletions(-)
> >>> delete mode 100644 spec/build/bsps/arm/beagle/optfdtcpyro.yml
> >>> delete mode 100644 spec/build/bsps/arm/beagle/optfdtmxsz.yml
> >>> delete mode 100644 spec/build/bsps/arm/beagle/optfdtro.yml
> >>> delete mode 100644 spec/build/bsps/arm/beagle/optfdtuboot.yml
> >>> delete mode 100644 spec/build/bsps/arm/imx/optfdtcpyro.yml
> >>> delete mode 100644 spec/build/bsps/arm/imx/optfdtmxsz.yml
> >>> delete mode 100644 spec/build/bsps/arm/imx/optfdtro.yml
> >>> delete mode 100644 spec/build/bsps/arm/imx/optfdtuboot.yml
> >>> rename spec/build/bsps/arm/{altera-cyclone-v => }/optfdtcpyro.yml
> >>> (100%)
> >>> rename spec/build/bsps/arm/{altera-cyclone-v => }/optfdtmxsz.yml
> >>> (100%)
> >>> rename spec/build/bsps/arm/{altera-cyclone-v => }/optfdtro.yml (100%)
> >>> rename spec/build/bsps/arm/{altera-cyclone-v => }/optfdtuboot.yml
> >>> (100%)
> >>>
> >>> diff --git
> >>> a/spec/build/bsps/arm/altera-cyclone-v/bspalteracyclonev.yml
> >>> b/spec/build/bsps/arm/altera-cyclone-v/bspalteracyclonev.yml
> >>> index da567ddd79..faf7203cd4 100644
> >>> --- a/spec/build/bsps/arm/altera-cyclone-v/bspalteracyclonev.yml
> >>> +++ b/spec/build/bsps/arm/altera-cyclone-v/bspalteracyclonev.yml
> >>> @@ -73,15 +73,15 @@ links:
> >>> - role: build-dependency
> >>> uid: optconuart1
> >>> - role: build-dependency
> >>> - uid: optfdtcpyro
> >>> + uid: ../optfdtcpyro
> >>> - role: build-dependency
> >>> uid: optfdten
> >>> - role: build-dependency
> >>> - uid: optfdtmxsz
> >>> + uid: ../optfdtmxsz
> >>> - role: build-dependency
> >>> - uid: optfdtro
> >>> + uid: ../optfdtro
> >>> - role: build-dependency
> >>> - uid: optfdtuboot
> >>> + uid: ../optfdtuboot
> >>> - role: build-dependency
> >>> uid: opti2cspeed
> >>> - role: build-dependency
> >>> diff --git a/spec/build/bsps/arm/beagle/grp.yml
> >>> b/spec/build/bsps/arm/beagle/grp.yml
> >>> index 1375913fd0..20fafa79a0 100644
> >>> --- a/spec/build/bsps/arm/beagle/grp.yml
> >>> +++ b/spec/build/bsps/arm/beagle/grp.yml
> >>> @@ -22,13 +22,13 @@ links:
> >>> - role: build-dependency
> >>> uid: optdm3730
> >>> - role: build-dependency
> >>> - uid: optfdtcpyro
> >>> + uid: ../optfdtcpyro
> >>> - role: build-dependency
> >>> - uid: optfdtmxsz
> >>> + uid: ../optfdtmxsz
> >>> - role: build-dependency
> >>> - uid: optfdtro
> >>> + uid: ../optfdtro
> >>> - role: build-dependency
> >>> - uid: optfdtuboot
> >>> + uid: ../optfdtuboot
> >>> - role: build-dependency
> >>> uid: ../grp
> >>> - role: build-dependency
> >>> diff --git a/spec/build/bsps/arm/beagle/optfdtcpyro.yml
> >>> b/spec/build/bsps/arm/beagle/optfdtcpyro.yml
> >>> deleted file mode 100644
> >>> index c26b1ae051..00
> >>> --- a/spec/build/bsps/arm/beagle/optfdtcpyro.yml
> >>> +++ /dev/null
> >>> @@ -1,15 +0,0 @@
> >>> -SPDX-Li
Re: [PATCH v2] bsps/arm: Move optfdt* files to shared parent directory
PS: loosely related, there is
arm/altera-cyclone-v/optfdten.yml:name: BSP_FDT_IS_SUPPORTED
It looks like other BSPs are deriving this check by conditioning it on
BSP_START_COPY_FDT_FROM_U_BOOT
This could probably be made consistent across these FDT-supporting BSPs.
Gedare
On Tue, Jun 29, 2021 at 2:37 PM Gedare Bloom wrote:
>
> On Tue, Jun 29, 2021 at 12:27 PM Christian Mauderer
> wrote:
> >
> > PS: Wouldn't it make sense to move these even further up? There is for
> > example ./spec/build/bsps/riscv/riscv/optfdtcpyro.yml too. A short md5
> > shows that it's the same file again.
> >
>
> Yes. Pranav, can you prepare a patch to move these into spec/build/bsps?
>
> I see
> cd spec/build/bsps
> grep -r FDT_BLOB
>
> powerpc/qoriq
> pops up too.
>
>
> > Best regards
> >
> > Christian
> >
> > On 29/06/2021 20:23, Christian Mauderer wrote:
> > > arm/imx7, arm/altcycv_devkit, arm/raspberrypi and arm/beagleboneblack
> > > compile with the patch. I tried libbsd media01 on beagleboneblack and it
> > > works.
> > >
> > > Best regards
> > >
> > > Christian
> > >
> > > On 29/06/2021 18:56, Gedare Bloom wrote:
> > >> I don't have an arm toolchain, if someone can pick this up and test
> > >> compile the affected BSPs, it looks ok to me.
> > >>
> > >> On Sun, Jun 27, 2021 at 2:46 PM pranav wrote:
> > >>>
> > >>> ---
> > >>> .../arm/altera-cyclone-v/bspalteracyclonev.yml | 8
> > >>> spec/build/bsps/arm/beagle/grp.yml | 8
> > >>> spec/build/bsps/arm/beagle/optfdtcpyro.yml | 15 ---
> > >>> spec/build/bsps/arm/beagle/optfdtmxsz.yml| 16
> > >>> spec/build/bsps/arm/beagle/optfdtro.yml | 15 ---
> > >>> spec/build/bsps/arm/beagle/optfdtuboot.yml | 15 ---
> > >>> spec/build/bsps/arm/imx/bspimx.yml | 8
> > >>> spec/build/bsps/arm/imx/optfdtcpyro.yml | 15 ---
> > >>> spec/build/bsps/arm/imx/optfdtmxsz.yml | 16
> > >>> spec/build/bsps/arm/imx/optfdtro.yml | 15 ---
> > >>> spec/build/bsps/arm/imx/optfdtuboot.yml | 15 ---
> > >>> .../arm/{altera-cyclone-v => }/optfdtcpyro.yml | 0
> > >>> .../arm/{altera-cyclone-v => }/optfdtmxsz.yml| 0
> > >>> .../bsps/arm/{altera-cyclone-v => }/optfdtro.yml | 0
> > >>> .../arm/{altera-cyclone-v => }/optfdtuboot.yml | 0
> > >>> spec/build/bsps/arm/raspberrypi/grp.yml | 8
> > >>> 16 files changed, 20 insertions(+), 134 deletions(-)
> > >>> delete mode 100644 spec/build/bsps/arm/beagle/optfdtcpyro.yml
> > >>> delete mode 100644 spec/build/bsps/arm/beagle/optfdtmxsz.yml
> > >>> delete mode 100644 spec/build/bsps/arm/beagle/optfdtro.yml
> > >>> delete mode 100644 spec/build/bsps/arm/beagle/optfdtuboot.yml
> > >>> delete mode 100644 spec/build/bsps/arm/imx/optfdtcpyro.yml
> > >>> delete mode 100644 spec/build/bsps/arm/imx/optfdtmxsz.yml
> > >>> delete mode 100644 spec/build/bsps/arm/imx/optfdtro.yml
> > >>> delete mode 100644 spec/build/bsps/arm/imx/optfdtuboot.yml
> > >>> rename spec/build/bsps/arm/{altera-cyclone-v => }/optfdtcpyro.yml
> > >>> (100%)
> > >>> rename spec/build/bsps/arm/{altera-cyclone-v => }/optfdtmxsz.yml
> > >>> (100%)
> > >>> rename spec/build/bsps/arm/{altera-cyclone-v => }/optfdtro.yml (100%)
> > >>> rename spec/build/bsps/arm/{altera-cyclone-v => }/optfdtuboot.yml
> > >>> (100%)
> > >>>
> > >>> diff --git
> > >>> a/spec/build/bsps/arm/altera-cyclone-v/bspalteracyclonev.yml
> > >>> b/spec/build/bsps/arm/altera-cyclone-v/bspalteracyclonev.yml
> > >>> index da567ddd79..faf7203cd4 100644
> > >>> --- a/spec/build/bsps/arm/altera-cyclone-v/bspalteracyclonev.yml
> > >>> +++ b/spec/build/bsps/arm/altera-cyclone-v/bspalteracyclonev.yml
> > >>> @@ -73,15 +73,15 @@ links:
> > >>> - role: build-dependency
> > >>> uid: optconuart1
> > >>> - role: build-dependency
> > >>> - uid: optfdtcpyro
> > >>> + uid: ../optfdtcpyro
> > >>> - role: build-dependency
> > >>> uid: optfdten
> > >>> - role: build-dependency
> > >>> - uid: optfdtmxsz
> > >>> + uid: ../optfdtmxsz
> > >>> - role: build-dependency
> > >>> - uid: optfdtro
> > >>> + uid: ../optfdtro
> > >>> - role: build-dependency
> > >>> - uid: optfdtuboot
> > >>> + uid: ../optfdtuboot
> > >>> - role: build-dependency
> > >>> uid: opti2cspeed
> > >>> - role: build-dependency
> > >>> diff --git a/spec/build/bsps/arm/beagle/grp.yml
> > >>> b/spec/build/bsps/arm/beagle/grp.yml
> > >>> index 1375913fd0..20fafa79a0 100644
> > >>> --- a/spec/build/bsps/arm/beagle/grp.yml
> > >>> +++ b/spec/build/bsps/arm/beagle/grp.yml
> > >>> @@ -22,13 +22,13 @@ links:
> > >>> - role: build-dependency
> > >>> uid: optdm3730
> > >>> - role: build-dependency
> > >>> - uid: optfdtcpyro
> > >>> + uid: ../optfdtcpyro
> > >>> - role: build-dependency
> > >>> - uid: optfdtmxsz
> > >>> + uid: ../optfdtmxsz
Re: [PATCH v3 2/2] rtems-exeinfo.cpp: Fix division by zero errors
these two look good now, thanks
On Tue, Jun 29, 2021 at 1:37 PM Ryan Long wrote:
>
> CID 1503008: Division or modulo by zero
> CID 1503015: Division or modulo by zero
>
> Closes #4416
> ---
> linkers/rtems-exeinfo.cpp | 20
> 1 file changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/linkers/rtems-exeinfo.cpp b/linkers/rtems-exeinfo.cpp
> index 1e6d4b4..6e92206 100644
> --- a/linkers/rtems-exeinfo.cpp
> +++ b/linkers/rtems-exeinfo.cpp
> @@ -755,6 +755,8 @@ namespace rld
>size_t total = 0;
>size_t total_size = 0;
>size_t inlined_size = 0;
> + double percentage;
> + double percentage_size;
>dwarf::functions funcs_inlined;
>dwarf::functions funcs_not_inlined;
>func_counts counts;
> @@ -798,14 +800,24 @@ namespace rld
> }
>}
>
> + if ( total == 0 ) {
> +percentage = 0;
> + } else {
> +percentage = (double) ( funcs_inlined.size() * 100 ) / total;
> + }
> +
> + if ( total_size == 0 ) {
> +percentage_size = 0;
> + } else {
> +percentage_size = (double) ( inlined_size * 100 ) / total_size;
> + }
> +
>std::cout << "inlined funcs : " << funcs_inlined.size () << std::endl
> << "total funcs : " << total << std::endl
> -<< " % inline funcs : " << (funcs_inlined.size () * 100) /
> total << '%'
> -<< std::endl
> +<< " % inline funcs : " << percentage << '%' << std::endl
> << " total size : " << total_size << std::endl
> << "inline size : " << inlined_size << std::endl
> -<< " % inline size : " << (inlined_size * 100) / total_size
> << '%'
> -<< std::endl;
> +<< " % inline size : " << percentage_size << '%' <<
> std::endl;
>
>auto count_compare = [](func_count const & a, func_count const & b) {
> return a.size != b.size? a.size < b.size : a.count > b.count;
> --
> 1.8.3.1
>
> ___
> 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 2/3] cpukit/libmisc/rtems-fdt: Fixes leaked variable 'bf' in rtems-fdt.c
On Tue, Jun 29, 2021 at 2:26 PM Joel Sherrill wrote: > > On Tue, Jun 29, 2021 at 3:15 PM Harrison Gerber wrote: > > > > Joel, > > > > I'm not too sure what is meant by almost duplicating the base file name. > > The file referenced is 'rtems-fdt.c', which is found in a file called > > 'rtems-fdt' inside libmisc, so I thought it was best to have the entire > > directory path at the front and the name of the file being altered in the > > description. Let me know if this is not correct; I'm not totally sure what > > is meant here, but the rest I understand! This also is important to your > > response to the third patch in this series. > > > > basename is a POSIX command/term for part of the path. dirname is the > directory portion. > > /home/joel/source.c > > dirname portion -> /home/joel > basename portion -> source.c > > cpukit/libmisc/rtems-fdt: Fixes leaked variable 'bf' in rtems-fdt.c > > I see now that the directory rtems-fdt is similar to the source file > so it wasn't quite as redundant as I thought. > > How about this? > > cpukit/libmisc/rtems-fdt/rtems-fdt.c: close() file to avoid leaking descriptor > We usually just use two hops, e.g., cpukit/libmisc: close() file to avoid leaking descriptor whether or not to specify this is in rtems-fdt is a different choice. We don't have a standard way yet of making these "tags" for commits to orient the review/maintainer responsibility. however, we also will not say cpukit for example for something in score, we just say score. Here, I'd be happy with "libmisc/rtems-fdt: close() file to avoid leaking descriptor" > That makes the filename clear and doesn't waste characters with "in " > > Personally, if the comment needed to longer, I would be ok ditching > the cpukit/ part but you don't need to do that for space. +1 ditch it anyway, conciseness in the short-log is a good thing > > > Thanks for the quick response! > > > > No problem. It takes a village to review patches. :) > > --joel > > > Harrison Gerber > > hger...@uccs.edu > > 720-288-7308 > > > > -Original Message- > > From: Joel Sherrill > > Sent: Tuesday, June 29, 2021 2:09 PM > > To: Harrison Edward Gerber > > Cc: rtems-de...@rtems.org ; Harrison Gerber > > > > Subject: Re: [PATCH 2/3] cpukit/libmisc/rtems-fdt: Fixes leaked variable > > 'bf' in rtems-fdt.c > > > > I'm ok with the fix but the commit message could be improved. > > Something like this would be better. > > > > cpukit/libmisc/rtems-fdt.c : close() file to avoid leaking descriptor > > > > You almost duplicated the base file name and it isn't leaking the variable, > > it is leaking the file descriptor referenced by bf. > > > > --joel > > > > On Tue, Jun 29, 2021 at 2:54 PM Harrison Edward Gerber > > wrote: > > > > > > See Also CID 1437645 > > > > > > Closes #4297 > > > --- > > > cpukit/libmisc/rtems-fdt/rtems-fdt.c | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/cpukit/libmisc/rtems-fdt/rtems-fdt.c > > > b/cpukit/libmisc/rtems-fdt/rtems-fdt.c > > > index bfbc6102a2..5580d415e2 100644 > > > --- a/cpukit/libmisc/rtems-fdt/rtems-fdt.c > > > +++ b/cpukit/libmisc/rtems-fdt/rtems-fdt.c > > > @@ -611,6 +611,7 @@ rtems_fdt_load (const char* filename, > > > rtems_fdt_handle* handle) > > > return fe; > > >} > > > > > > + close (bf); > > >return 0; > > > } > > > > > > -- > > > 2.25.1 > > > > > > ___ > > > 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 1/3] cpukit/libmisc/rtems-ftd: Fixed error of null pointer dereference in rtems-fdt.c
On Tue, Jun 29, 2021 at 2:11 PM Joel Sherrill wrote: > > Same issue to improve the commit message as I just emailed. Something > like this would be better: > > cpukit/libmisc/rtems-ftd.c: Fixed error of null pointer dereference > check typo on fdt, and see my note, use 'libmisc/rtems-fdt' would be my preference. > > On Tue, Jun 29, 2021 at 3:07 PM Joel Sherrill wrote: > > > > This definitely moves the dereference before the free() so appears to be OK. > > > > If Gedare approves, he can merge it. > > > > --joel > > > > On Tue, Jun 29, 2021 at 2:54 PM Harrison Edward Gerber > > wrote: > > > > > > See Also CID 1437647 > > > > > > Closes #4460 > > > --- > > > cpukit/libmisc/rtems-fdt/rtems-fdt.c | 4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > diff --git a/cpukit/libmisc/rtems-fdt/rtems-fdt.c > > > b/cpukit/libmisc/rtems-fdt/rtems-fdt.c > > > index 7747ba9bf8..bfbc6102a2 100644 > > > --- a/cpukit/libmisc/rtems-fdt/rtems-fdt.c > > > +++ b/cpukit/libmisc/rtems-fdt/rtems-fdt.c > > > @@ -678,14 +678,14 @@ rtems_fdt_unload (rtems_fdt_handle* handle) > > > > > >rtems_chain_extract_unprotected (&handle->blob->node); > > > > > > + rtems_fdt_release_index(&handle->blob->index); > > > + > > >free (handle->blob); > > > > > >handle->blob = NULL; > > > > > >rtems_fdt_unlock (fdt); > > > > > > - rtems_fdt_release_index(&handle->blob->index); > > > - > > >return 0; > > > } > > > > > > -- > > > 2.25.1 > > > > > > ___ > > > 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
[PATCH v2 1/3] libmisc/rtems-ftd: Fixed error of null pointer dereference
See Also CID 1437647 Closes #4460 --- cpukit/libmisc/rtems-fdt/rtems-fdt.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/cpukit/libmisc/rtems-fdt/rtems-fdt.c b/cpukit/libmisc/rtems-fdt/rtems-fdt.c index 7747ba9bf8..bfbc6102a2 100644 --- a/cpukit/libmisc/rtems-fdt/rtems-fdt.c +++ b/cpukit/libmisc/rtems-fdt/rtems-fdt.c @@ -678,14 +678,14 @@ rtems_fdt_unload (rtems_fdt_handle* handle) rtems_chain_extract_unprotected (&handle->blob->node); + rtems_fdt_release_index(&handle->blob->index); + free (handle->blob); handle->blob = NULL; rtems_fdt_unlock (fdt); - rtems_fdt_release_index(&handle->blob->index); - return 0; } -- 2.25.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH v2 2/3] libmisc/rtems-fdt: close() file 'bf' to avoid leaking descriptor
See Also CID 1437645 Closes #4297 --- cpukit/libmisc/rtems-fdt/rtems-fdt.c | 1 + 1 file changed, 1 insertion(+) diff --git a/cpukit/libmisc/rtems-fdt/rtems-fdt.c b/cpukit/libmisc/rtems-fdt/rtems-fdt.c index bfbc6102a2..5580d415e2 100644 --- a/cpukit/libmisc/rtems-fdt/rtems-fdt.c +++ b/cpukit/libmisc/rtems-fdt/rtems-fdt.c @@ -611,6 +611,7 @@ rtems_fdt_load (const char* filename, rtems_fdt_handle* handle) return fe; } + close (bf); return 0; } -- 2.25.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH v2 3/3] libmisc/rtems-fdt: Fix of unreachable statement from incorrect variable check
See Also CID 1437638
Closes #4462
---
cpukit/libmisc/rtems-fdt/rtems-fdt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cpukit/libmisc/rtems-fdt/rtems-fdt.c
b/cpukit/libmisc/rtems-fdt/rtems-fdt.c
index 5580d415e2..b1bb26572d 100644
--- a/cpukit/libmisc/rtems-fdt/rtems-fdt.c
+++ b/cpukit/libmisc/rtems-fdt/rtems-fdt.c
@@ -163,7 +163,7 @@ rtems_fdt_init_index (rtems_fdt_handle* fdt,
rtems_fdt_blob* blob)
}
names = calloc(1, total_name_memory);
- if (!entries)
+ if (!names)
{
free(entries);
return -RTEMS_FDT_ERR_NO_MEMORY;
--
2.25.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-tools] tester: Add zu3eg test configs
Add tester configurations for ILP32 and LP64 on hardware.
---
.../bsps/xilinx_zynqmp_ilp32_zu3eg.ini| 41 +++
.../testing/bsps/xilinx_zynqmp_lp64_zu3eg.ini | 41 +++
2 files changed, 82 insertions(+)
create mode 100644 tester/rtems/testing/bsps/xilinx_zynqmp_ilp32_zu3eg.ini
create mode 100644 tester/rtems/testing/bsps/xilinx_zynqmp_lp64_zu3eg.ini
diff --git a/tester/rtems/testing/bsps/xilinx_zynqmp_ilp32_zu3eg.ini
b/tester/rtems/testing/bsps/xilinx_zynqmp_ilp32_zu3eg.ini
new file mode 100644
index 000..5fd2039
--- /dev/null
+++ b/tester/rtems/testing/bsps/xilinx_zynqmp_ilp32_zu3eg.ini
@@ -0,0 +1,41 @@
+#
+# RTEMS Tools Project (http://www.rtems.org/)
+# Copyright 2021 Kinsey Moore(kinsey.mo...@oarcorp.com)
+# All rights reserved.
+#
+# This file is part of the RTEMS Tools package in 'rtems-tools'.
+#
+# 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 HOLDER 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.
+#
+
+#
+# The AArch64 Xilinx ZynqMP (Ultrascale+ MPSOC) ILP32 ZU3EG BSP.
+#
+[xilinx_zynqmp_ilp32_zu3eg]
+bsp= xilinx_zynqmp_ilp32_zu3eg
+arch = aarch64
+tester = %{_rtscripts}/tftp.cfg
+jobs = 1
+target_reset_regex = ^No ethernet found.*|^BOOTP broadcast 6.*|^.+complete\.+
TIMEOUT.*|^.*Retry count exceeded.*|^.*: No link\..*|^.*TFTP server died;
starting again.*
+target_start_regex = ^.*Xilinx Zynq MP First Stage Boot Loader.*
+requires = target_on_command, target_off_command,
target_reset_command, bsp_tty_dev
diff --git a/tester/rtems/testing/bsps/xilinx_zynqmp_lp64_zu3eg.ini
b/tester/rtems/testing/bsps/xilinx_zynqmp_lp64_zu3eg.ini
new file mode 100644
index 000..c4d091f
--- /dev/null
+++ b/tester/rtems/testing/bsps/xilinx_zynqmp_lp64_zu3eg.ini
@@ -0,0 +1,41 @@
+#
+# RTEMS Tools Project (http://www.rtems.org/)
+# Copyright 2021 Kinsey Moore(kinsey.mo...@oarcorp.com)
+# All rights reserved.
+#
+# This file is part of the RTEMS Tools package in 'rtems-tools'.
+#
+# 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 HOLDER 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.
+#
+
+#
+# The AArch64 Xilinx ZynqMP (Ultrascale+ MPSOC) LP64 ZU3EG BSP.
+#
+[xilinx_zynqmp_lp64_zu3eg]
+bsp= xilinx_zynqmp_lp64_zu3eg
+arch = aarch64
+tester = %{_rtscripts}/tftp.cfg
+jobs = 1
+target_reset_regex = ^No ethernet found.*|^BOOTP broadcast 6.*|^.+complete\.+
TIMEOUT.*|^.*Retry count exceeded.*|^.*: No link\..*|^.*TFTP server died;
starting again.*
+target_start_regex = ^.*Xilinx Zynq MP First Stage Boot Loader.*
+requi
Re: [PATCH rtems-tools] tester: Add zu3eg test configs
looks good
On Tue, Jun 29, 2021 at 3:36 PM Kinsey Moore wrote:
>
> Add tester configurations for ILP32 and LP64 on hardware.
> ---
> .../bsps/xilinx_zynqmp_ilp32_zu3eg.ini| 41 +++
> .../testing/bsps/xilinx_zynqmp_lp64_zu3eg.ini | 41 +++
> 2 files changed, 82 insertions(+)
> create mode 100644 tester/rtems/testing/bsps/xilinx_zynqmp_ilp32_zu3eg.ini
> create mode 100644 tester/rtems/testing/bsps/xilinx_zynqmp_lp64_zu3eg.ini
>
> diff --git a/tester/rtems/testing/bsps/xilinx_zynqmp_ilp32_zu3eg.ini
> b/tester/rtems/testing/bsps/xilinx_zynqmp_ilp32_zu3eg.ini
> new file mode 100644
> index 000..5fd2039
> --- /dev/null
> +++ b/tester/rtems/testing/bsps/xilinx_zynqmp_ilp32_zu3eg.ini
> @@ -0,0 +1,41 @@
> +#
> +# RTEMS Tools Project (http://www.rtems.org/)
> +# Copyright 2021 Kinsey Moore(kinsey.mo...@oarcorp.com)
> +# All rights reserved.
> +#
> +# This file is part of the RTEMS Tools package in 'rtems-tools'.
> +#
> +# 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 HOLDER 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.
> +#
> +
> +#
> +# The AArch64 Xilinx ZynqMP (Ultrascale+ MPSOC) ILP32 ZU3EG BSP.
> +#
> +[xilinx_zynqmp_ilp32_zu3eg]
> +bsp= xilinx_zynqmp_ilp32_zu3eg
> +arch = aarch64
> +tester = %{_rtscripts}/tftp.cfg
> +jobs = 1
> +target_reset_regex = ^No ethernet found.*|^BOOTP broadcast
> 6.*|^.+complete\.+ TIMEOUT.*|^.*Retry count exceeded.*|^.*: No
> link\..*|^.*TFTP server died; starting again.*
> +target_start_regex = ^.*Xilinx Zynq MP First Stage Boot Loader.*
> +requires = target_on_command, target_off_command,
> target_reset_command, bsp_tty_dev
> diff --git a/tester/rtems/testing/bsps/xilinx_zynqmp_lp64_zu3eg.ini
> b/tester/rtems/testing/bsps/xilinx_zynqmp_lp64_zu3eg.ini
> new file mode 100644
> index 000..c4d091f
> --- /dev/null
> +++ b/tester/rtems/testing/bsps/xilinx_zynqmp_lp64_zu3eg.ini
> @@ -0,0 +1,41 @@
> +#
> +# RTEMS Tools Project (http://www.rtems.org/)
> +# Copyright 2021 Kinsey Moore(kinsey.mo...@oarcorp.com)
> +# All rights reserved.
> +#
> +# This file is part of the RTEMS Tools package in 'rtems-tools'.
> +#
> +# 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 HOLDER 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.
> +#
> +
> +#
> +# The AArch64 Xilinx ZynqMP (Ultrascale+ MPSOC) LP64 ZU3EG BSP.
> +#
> +[xilinx_zynqmp_lp64_zu3eg]
> +bsp= xilinx_zynqmp_lp64_zu3eg
> +arch = aarch64
> +tester = %{_rtscripts}
Re: [PATCH] bsps/zynqmp: Allow any or all CGEMs to be enabled
On 30/6/21 1:21 am, Gedare Bloom wrote: > On Tue, Jun 29, 2021 at 7:50 AM Sebastian Huber > wrote: >> >> On 29/06/2021 15:48, Kinsey Moore wrote: >>> On 6/9/2021 00:27, Sebastian Huber wrote: On 08/06/2021 22:18, Kinsey Moore wrote: > Provide the options necessary to enable any combination of CGEM ethernet > interfaces in LibBSD. The default is still CGEM3, so this should > continue to operate as expected on typical Zynq Ultrascale+ MPSoC > development hardware. An alternative to this configuration approach would be to enable the device tree support for this BSP. >>> Sorry, I missed this earlier due to travel. Device tree support in >>> libbsd for if_cgem.c is currently #ifdef'd out and has been since it was >>> introduced. I had assumed that was the case for other FDT support as >>> well based on the comments in that initial commit. >> >> The device tree support is disabled since the original Zynq BSP was >> added before RTEMS had support for device trees in general. Nobody had >> the time/budget/need to change the BSP to support device trees so far. >> > I'm not sure anyone has the time/budget yet either. FDT support is > challenging for RTEMS because it requires a closer interaction between > a bootloader and RTEMS, which raises legal/license compliance > concerns. Or RTEMS itself if linked into a single executable. > Although I agree that FDT is a great solution, I'm not > certain about the scope (or creep) it implies in terms of the > relationship between RTEMS and Bootloaders/firmware, or whether we > need to produce our own "mini bootloader" that deals with FDT support > early in the RTEMS startup sequence. I agree. RTEMS use to be a single binary image that contained everything and as a configuration controlled item it was simple to manage. FDT and then boot loaders that support FDT brings into RTEMS a range of new issues. Some users completely ban GPL and uboot is GPL and then some FDT is licensed GPL. Licenses aside users need to manage and configuration control 3 separate pieces. These pieces all need to line up and that presents challengers to our project. > Right now, the design eludes me, but I'm certain that requiring users > to U-Boot for FDT support is not the best solution for RTEMS. Yeap, it should be "a" solution and users should be to select what they want. And finally from a developer point of view I understand uboot and FDT is an easy and attractive solution but we as developers do not have to live with the flow on issues these additions crate. As an open source project we need to consider both positions. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] bsps/zynqmp: Allow any or all CGEMs to be enabled
On 30/6/21 2:19 am, Kinsey Moore wrote: > On 6/29/2021 11:10, Gedare Bloom wrote: >> On Tue, Jun 29, 2021 at 6:34 AM Kinsey Moore >> wrote: >>> I suppose this could have been configured in libbsd (possibly >>> config.inc) instead if that's what you're getting at. The overall goal >>> is to be able to run the tests that use the network on any one of the >>> board variants that this BSP supports. My takeaway from the earlier >>> conversation on the list is that this was the preferred method of >>> switching the ethernet interface for those tests. >>> >> I acked this patch, and then I also dug into the cgem code. It seems >> we should leave the decision of which GEM to use to the application. >> This patch and way of doing that accomplishes the configuration by the >> application as a BSP option. However, there's no code in the BSP that >> actually gets controlled by the option. So, I think we should probably >> find a better way to allow the application to select which GEM it >> uses, and to provide the glue in the BSP to allow all the possible >> GEMs to be available. > > This patch was primarily targeted at the tests themselves. The application can > always provide its own nexus definitions instead of using the ones baked into > libbsd for testing (this was brought up in the initial thread where I asked > about how this was typically done). Unfortunately, this is hard to do with the > tests because the tests are the application and can't be changed for those > overrides/alternatives. The tests should be handled by config.inc as you said. If that support is not good enough then we should address that. The issue adding this type of support in BSPs is a possible dependence and that means we can never change it. If we add things for down stream packages be it libbsd or anything else we can never change it because we have to assume there will always be a version of something somewhere that depends on it, eg bisect. I suggest this be removed. I know there are other BSP that have similar defines and we should address as time permits. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
