Re: [PATCH rtems v1 2/2] bsps/zynqmp: Added I2C support for ZynqMP
On 25/8/21 12:05 am, Stephen Clark wrote: > This approach was also used in bsps/arm/xilinx-zynq/include/bsp/i2c.h. I kept > it specifically for consistency; I assumed it was the standard approach, but > your response makes me think it's not. I am also not sure and why I asked :) > Is there a case to be made for breaking the register functions in both i2c.h > files out into their own c files? I do not know. There can be a tendency to place things into line functions that do not need to be. It saves work by not need to touch the build system. If the code is being moved should it be moved to a C file? This is the reason I raised this. I am happy to follow what ever Joel thinks. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] tester: Add MicroBlaze KCU105 QEMU BSP
On 25/8/21 7:46 am, Alex White wrote:
> On Mon, Aug 23, 2021 at 9:29 PM Chris Johns wrote:
>>
>> Hi,
>>
>> Could you please explain this file?
>>
>> Where is the source?
>>
>> Why would we allow a binay blob into the tester like this?
>
> Hi Chris,
>
> Running MicroBlaze tests on QEMU requires an appropriate DTB file to pass to
> QEMU via the "-hw-dtb" flag. There does not appear to be a way to pass the
> device tree source to QEMU.
>
> This particular DTB comes from Xilinx as part of their KCU105 BSP.
The file you posted has no attribution and that means we cannot accept it. There
is also no source and so the binary blob is not acceptable. Anyway there are
better solutions to solve this.
> It seems most
> sensible to store it next to the tester configuration similar to the other
> device tree files in that directory (psim-device-tree, etc.).
In my view the device tree files are not the same.
> I realize that this is a binary file and the other device tree files in
> tester/rtems/testing/bsps are not, but it seems that this needs to live
> alongside the BSP configuration so that it can be referenced by
> kcu105_qemu.ini.
I do not agree.
>> This seems specific to a set up or a BSP and not the tester. I am not
>> comfortable with this approach. Have alternative approaches have you
>> considered?
>
> I am not aware of another way that would ensure consistency with the tester
> configuration.
The tester is designed to handle this. The user focused INI files:
https://docs.rtems.org/branches/master/user/testing/configuration.html#bsp-and-user-configuration
You provide for your site are imported here:
https://git.rtems.org/rtems-tools/tree/tester/rt/config.py#n468
The key/value pairs are entered into the macro defaults. This means you can add
`%{bsp_qemu_extra_opts}` to the execute command in `qemu.ini` and then you can
create a suitable site specific INI file to match your BSP.
Where you then hold the DTB and the DTS becomes a separate and wider discussion.
> We could require that a user obtain the DTB from elsewhere and
> copy it to the correct directory, but that seems a lot more involved than just
> including the needed file and would be more difficult to keep consistent with
> any future changes that might be needed.
Yes it is more involved but how would the user of the BSP you are doing the work
for handle that same situation for their custom BSP? They cannot post a closed
DTB for their project to this list in the hope we commit it and I would not
suggest to them they create a branch in their repo to hold it. We have 2 roles,
one maintaining RTEMS and BSPs and another developing a suitable eco-system our
users can extend without touching the built tools we provide.
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] tester: Add MicroBlaze KCU105 QEMU BSP
On Mon, Aug 23, 2021 at 9:29 PM Chris Johns wrote: > > Hi, > > Could you please explain this file? > > Where is the source? > > Why would we allow a binay blob into the tester like this? Hi Chris, Running MicroBlaze tests on QEMU requires an appropriate DTB file to pass to QEMU via the "-hw-dtb" flag. There does not appear to be a way to pass the device tree source to QEMU. This particular DTB comes from Xilinx as part of their KCU105 BSP. It seems most sensible to store it next to the tester configuration similar to the other device tree files in that directory (psim-device-tree, etc.). I realize that this is a binary file and the other device tree files in tester/rtems/testing/bsps are not, but it seems that this needs to live alongside the BSP configuration so that it can be referenced by kcu105_qemu.ini. > > This seems specific to a set up or a BSP and not the tester. I am not > comfortable with this approach. Have alternative approaches have you > considered? I am not aware of another way that would ensure consistency with the tester configuration. We could require that a user obtain the DTB from elsewhere and copy it to the correct directory, but that seems a lot more involved than just including the needed file and would be more difficult to keep consistent with any future changes that might be needed. Thanks, Alex > > Chris > > On 24/8/21 4:46 am, Alex White wrote: > > --- > > tester/rtems/testing/bsps/kcu105.dtb | Bin 0 -> 15256 bytes > > tester/rtems/testing/bsps/kcu105_qemu.ini | 38 ++ > > 2 files changed, 38 insertions(+) > > create mode 100644 tester/rtems/testing/bsps/kcu105.dtb > > create mode 100644 tester/rtems/testing/bsps/kcu105_qemu.ini > > > > diff --git a/tester/rtems/testing/bsps/kcu105.dtb > > b/tester/rtems/testing/bsps/kcu105.dtb > > new file mode 100644 > > index > > ..998e8c03b74d8d9ddc82b5f6fa53242415abbd84 > > GIT binary patch > > literal 15256 > > > > Chris > ___ > 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] tester: Limit simultaneous QEMU jobs to 1
There is an emulation problem between RTEMS and QEMU that causes several
sets of tests to fail in circumstances where there is high load on the
host machine. Running multiple instances of QEMU simultaneously
exacerbates this problem which includes all of the spintrcritical tests,
psx12, and some of the other sp* tests. Limiting QEMU to one job at a
time increases test duration, but minimizes the number of tests that
fail this way. This affects at least ARM and AArch64 emulation so those
testing environments have been targeted here.
---
tester/rtems/testing/bsps/a53_ilp32_qemu.ini | 1 +
tester/rtems/testing/bsps/a53_lp64_qemu-cov.ini | 1 +
tester/rtems/testing/bsps/a53_lp64_qemu.ini | 1 +
tester/rtems/testing/bsps/a72_lp64_qemu.ini | 1 +
tester/rtems/testing/bsps/realview_pbx_a9_qemu.ini| 1 +
tester/rtems/testing/bsps/xilinx_versal_lp64_qemu.ini | 1 +
tester/rtems/testing/bsps/xilinx_zynq_a9_qemu-cov.ini | 1 +
tester/rtems/testing/bsps/xilinx_zynq_a9_qemu.ini | 1 +
tester/rtems/testing/bsps/xilinx_zynq_a9_qemu_smp.ini | 2 +-
tester/rtems/testing/bsps/xilinx_zynq_zc706_qemu.ini | 1 +
tester/rtems/testing/bsps/xilinx_zynqmp_ilp32_qemu.ini| 1 +
tester/rtems/testing/bsps/xilinx_zynqmp_lp64_qemu-cov.ini | 1 +
tester/rtems/testing/bsps/xilinx_zynqmp_lp64_qemu.ini | 1 +
13 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/tester/rtems/testing/bsps/a53_ilp32_qemu.ini
b/tester/rtems/testing/bsps/a53_ilp32_qemu.ini
index 3beba06..581c59c 100644
--- a/tester/rtems/testing/bsps/a53_ilp32_qemu.ini
+++ b/tester/rtems/testing/bsps/a53_ilp32_qemu.ini
@@ -36,3 +36,4 @@ bsp = a53_ilp32_qemu
arch = aarch64
tester= %{_rtscripts}/qemu.cfg
bsp_qemu_opts = %{qemu_opts_base} -serial mon:stdio -machine
virt,gic-version=3 -cpu cortex-a53 -m 4096
+jobs = 1
diff --git a/tester/rtems/testing/bsps/a53_lp64_qemu-cov.ini
b/tester/rtems/testing/bsps/a53_lp64_qemu-cov.ini
index 231bd7a..1acf61e 100644
--- a/tester/rtems/testing/bsps/a53_lp64_qemu-cov.ini
+++ b/tester/rtems/testing/bsps/a53_lp64_qemu-cov.ini
@@ -38,3 +38,4 @@ tester= %{_rtscripts}/qemu.cfg
bsp_qemu_opts = %{qemu_opts_base} -serial mon:stdio -machine
virt,gic-version=3 -cpu cortex-a53 -m 4096
bsp_qemu_cov_opts = -exec-trace %{test_executable}.cov
bsp_covoar_cmd= -S %{bsp_symbol_path} -E %{cov_explanations}
+jobs = 1
diff --git a/tester/rtems/testing/bsps/a53_lp64_qemu.ini
b/tester/rtems/testing/bsps/a53_lp64_qemu.ini
index 1b89284..ee6cd81 100644
--- a/tester/rtems/testing/bsps/a53_lp64_qemu.ini
+++ b/tester/rtems/testing/bsps/a53_lp64_qemu.ini
@@ -36,3 +36,4 @@ bsp = a53_lp64_qemu
arch = aarch64
tester= %{_rtscripts}/qemu.cfg
bsp_qemu_opts = %{qemu_opts_base} -serial mon:stdio -machine
virt,gic-version=3 -cpu cortex-a53 -m 4096
+jobs = 1
diff --git a/tester/rtems/testing/bsps/a72_lp64_qemu.ini
b/tester/rtems/testing/bsps/a72_lp64_qemu.ini
index 9b1eb8e..0a24429 100644
--- a/tester/rtems/testing/bsps/a72_lp64_qemu.ini
+++ b/tester/rtems/testing/bsps/a72_lp64_qemu.ini
@@ -36,3 +36,4 @@ bsp = a72_lp64_qemu
arch = aarch64
tester= %{_rtscripts}/qemu.cfg
bsp_qemu_opts = %{qemu_opts_base} -serial mon:stdio -machine
virt,gic-version=3 -cpu cortex-a72 -m 4096
+jobs = 1
diff --git a/tester/rtems/testing/bsps/realview_pbx_a9_qemu.ini
b/tester/rtems/testing/bsps/realview_pbx_a9_qemu.ini
index 68e7f31..5d0ae8d 100644
--- a/tester/rtems/testing/bsps/realview_pbx_a9_qemu.ini
+++ b/tester/rtems/testing/bsps/realview_pbx_a9_qemu.ini
@@ -36,3 +36,4 @@ bsp = realview_pbx_a9_qemu
arch = arm
tester= %{_rtscripts}/qemu.cfg
bsp_qemu_opts = %{qemu_opts_base} %{qemu_opts_no_net} -M realview-pbx-a9 -m
256M
+jobs = 1
diff --git a/tester/rtems/testing/bsps/xilinx_versal_lp64_qemu.ini
b/tester/rtems/testing/bsps/xilinx_versal_lp64_qemu.ini
index d440265..023f9d3 100644
--- a/tester/rtems/testing/bsps/xilinx_versal_lp64_qemu.ini
+++ b/tester/rtems/testing/bsps/xilinx_versal_lp64_qemu.ini
@@ -36,3 +36,4 @@ bsp = xilinx_versal_lp64_qemu
arch = aarch64
tester= %{_rtscripts}/qemu.cfg
bsp_qemu_opts = %{qemu_opts_base} -serial mon:stdio -machine xlnx-versal-virt
-m 4096
+jobs = 1
diff --git a/tester/rtems/testing/bsps/xilinx_zynq_a9_qemu-cov.ini
b/tester/rtems/testing/bsps/xilinx_zynq_a9_qemu-cov.ini
index b09cf0c..3dedf50 100644
--- a/tester/rtems/testing/bsps/xilinx_zynq_a9_qemu-cov.ini
+++ b/tester/rtems/testing/bsps/xilinx_zynq_a9_qemu-cov.ini
@@ -38,3 +38,4 @@ tester= %{_rtscripts}/qemu.cfg
bsp_qemu_opts = %{qemu_opts_base} %{qemu_opts_no_net} %{qemu_opts_serial} -M
xilinx-zynq-a9 -m 256M
bsp_qemu_cov_opts = -exec-trace %{test_executable}.cov
bsp_covoar_cmd= -S %{bsp_symbol_path} -E %{cov_explanations}
+jobs = 1
diff --git
[PATCH v1 0/3] Uninitialized scalar field Coverity issues
Hi, To fix these issues I just needed to add the missing member variables from the initialization lists. Thanks, Ryan Ryan Long (3): rtems-exeinfo.cpp: Initialize byteorder GcovData.cc: Initialize gcnoPreamble rld-dwarf.cpp: Initialize member variables linkers/rtems-exeinfo.cpp | 3 ++- rtemstoolkit/rld-dwarf.cpp | 12 tester/covoar/GcovData.cc | 1 + 3 files changed, 15 insertions(+), 1 deletion(-) -- 1.8.3.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH v1 3/3] rld-dwarf.cpp: Initialize member variables
Initialize member variables not listed.
CID 1503019: Uninitialized scalar field.
Closes #4500
---
rtemstoolkit/rld-dwarf.cpp | 12
1 file changed, 12 insertions(+)
diff --git a/rtemstoolkit/rld-dwarf.cpp b/rtemstoolkit/rld-dwarf.cpp
index 1eae50c..2d6f306 100644
--- a/rtemstoolkit/rld-dwarf.cpp
+++ b/rtemstoolkit/rld-dwarf.cpp
@@ -679,12 +679,18 @@ namespace rld
machine_code_ (false),
external_ (false),
declaration_ (false),
+prototyped_ (false),
inline_ (DW_INL_not_inlined),
entry_pc_ (0),
has_entry_pc_ (false),
pc_low_ (0),
pc_high_ (0),
ranges_ (debug),
+name_ (),
+linkage_name_ (),
+decl_file_ (),
+decl_line_ (0),
+call_file_ (),
call_line_ (0)
{
dwarf_bool db;
@@ -819,6 +825,7 @@ namespace rld
machine_code_ (orig.machine_code_),
external_ (orig.external_),
declaration_ (orig.declaration_),
+prototyped_ (orig.prototyped_),
inline_ (orig.inline_),
entry_pc_ (orig.entry_pc_),
has_entry_pc_ (orig.has_entry_pc_),
@@ -827,6 +834,8 @@ namespace rld
ranges_ (orig.ranges_),
name_ (orig.name_),
linkage_name_ (orig.linkage_name_),
+decl_file_ (orig.decl_file_),
+decl_line_ (orig.decl_line_),
call_file_ (orig.call_file_),
call_line_ (orig.call_line_)
{
@@ -986,7 +995,10 @@ namespace rld
ranges_ = rhs.ranges_;
name_ = rhs.name_;
linkage_name_ = rhs.linkage_name_;
+decl_file_ = rhs.decl_file_;
+decl_line_ = rhs.decl_line_;
call_file_ = rhs.call_file_;
+call_line_ = rhs.call_line_;
}
return *this;
}
--
1.8.3.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH v1 1/3] rtems-exeinfo.cpp: Initialize byteorder
CID 1471637: Uninitialized scalar field
Closes #4499
---
linkers/rtems-exeinfo.cpp | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/linkers/rtems-exeinfo.cpp b/linkers/rtems-exeinfo.cpp
index caae168..e54f9b2 100644
--- a/linkers/rtems-exeinfo.cpp
+++ b/linkers/rtems-exeinfo.cpp
@@ -210,7 +210,8 @@ namespace rld
section::section (const section& orig)
: sec (orig.sec),
-data (orig.data)
+data (orig.data),
+byteorder (orig.byteorder)
{
}
--
1.8.3.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH v1 2/3] GcovData.cc: Initialize gcnoPreamble
CID 1506206: Uninitialized scalar field
Closes #4487
---
tester/covoar/GcovData.cc | 1 +
1 file changed, 1 insertion(+)
diff --git a/tester/covoar/GcovData.cc b/tester/covoar/GcovData.cc
index 02e7489..723e9af 100644
--- a/tester/covoar/GcovData.cc
+++ b/tester/covoar/GcovData.cc
@@ -21,6 +21,7 @@ namespace Gcov {
GcovData::GcovData( Coverage::DesiredSymbols& symbolsToAnalyze ):
numberOfFunctions( 0 ),
+gcnoPreamble(),
symbolsToAnalyze_m( symbolsToAnalyze )
{
}
--
1.8.3.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
RE: [PATCH rtems v1 2/2] bsps/zynqmp: Added I2C support for ZynqMP
Chris,
This approach was also used in bsps/arm/xilinx-zynq/include/bsp/i2c.h. I kept
it specifically for consistency; I assumed it was the standard approach, but
your response makes me think it's not.
Is there a case to be made for breaking the register functions in both i2c.h
files out into their own c files?
Thanks,
Stephen
> -Original Message-
> From: Chris Johns
> Sent: Monday, August 23, 2021 9:38 PM
> To: Stephen Clark ; devel@rtems.org
> Subject: Re: [PATCH rtems v1 2/2] bsps/zynqmp: Added I2C support for ZynqMP
>
> On 24/8/21 8:24 am, Stephen Clark wrote:
> > Added I2C drivers for ZynqMP and updated build system accordingly.
> > ---
> > bsps/aarch64/xilinx-zynqmp/include/bsp.h | 4 ++
> > bsps/aarch64/xilinx-zynqmp/include/bsp/i2c.h | 63
> > +++ bsps/aarch64/xilinx-zynqmp/include/bsp/irq.h | 2 +
> > bsps/aarch64/xilinx-zynqmp/start/bspstart.c | 10 +++
> > spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml | 4 ++
> > .../bsps/aarch64/xilinx-zynqmp/grp_zu3eg.yml | 2 +
> > .../aarch64/xilinx-zynqmp/objcadencei2c.yml | 19 ++
> > .../bsps/aarch64/xilinx-zynqmp/optclki2c0.yml | 19 ++
> > .../bsps/aarch64/xilinx-zynqmp/optclki2c1.yml | 19 ++
> > 9 files changed, 142 insertions(+)
> > create mode 100644 bsps/aarch64/xilinx-zynqmp/include/bsp/i2c.h
> > create mode 100644
> > spec/build/bsps/aarch64/xilinx-zynqmp/objcadencei2c.yml
> > create mode 100644
> > spec/build/bsps/aarch64/xilinx-zynqmp/optclki2c0.yml
> > create mode 100644
> > spec/build/bsps/aarch64/xilinx-zynqmp/optclki2c1.yml
> >
> > diff --git a/bsps/aarch64/xilinx-zynqmp/include/bsp.h
> > b/bsps/aarch64/xilinx-zynqmp/include/bsp.h
> > index 83f2e2f4e4..6d49b9ad2a 100644
> > --- a/bsps/aarch64/xilinx-zynqmp/include/bsp.h
> > +++ b/bsps/aarch64/xilinx-zynqmp/include/bsp.h
> > @@ -70,6 +70,10 @@ BSP_START_TEXT_SECTION void
> > zynqmp_setup_mmu_and_cache(void);
> >
> > void zynqmp_debug_console_flush(void);
> >
> > +uint32_t zynqmp_clock_i2c0(void);
> > +
> > +uint32_t zynqmp_clock_i2c1(void);
> > +
> > #ifdef __cplusplus
> > }
> > #endif /* __cplusplus */
> > diff --git a/bsps/aarch64/xilinx-zynqmp/include/bsp/i2c.h
> > b/bsps/aarch64/xilinx-zynqmp/include/bsp/i2c.h
> > new file mode 100644
> > index 00..e09747d414
> > --- /dev/null
> > +++ b/bsps/aarch64/xilinx-zynqmp/include/bsp/i2c.h
> > @@ -0,0 +1,63 @@
> > +/*
> > + * SPDX-License-Identifier: BSD-2-Clause
> > + *
> > + * Copyright (C) 2021 On-Line Applications Research (OAR)
> > + *
> > + * Redistribution and use in source and binary forms, with or without
> > + * modification, are permitted provided that the following conditions
> > + * are met:
> > + * 1. Redistributions of source code must retain the above copyright
> > + *notice, this list of conditions and the following disclaimer.
> > + * 2. Redistributions in binary form must reproduce the above copyright
> > + *notice, this list of conditions and the following disclaimer in the
> > + *documentation and/or other materials provided with the distribution.
> > + *
> > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> CONTRIBUTORS "AS IS"
> > + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> LIMITED
> > +TO, THE
> > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
> PARTICULAR
> > +PURPOSE
> > + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
> > +CONTRIBUTORS BE
> > + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,
> > +OR
> > + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
> PROCUREMENT
> > +OF
> > + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
> > +BUSINESS
> > + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
> > +WHETHER IN
> > + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
> > +OTHERWISE)
> > + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
> > +ADVISED OF THE
> > + * POSSIBILITY OF SUCH DAMAGE.
> > + */
> > +
> > +#ifndef LIBBSP_ARM_XILINX_ZYNQ_I2C_H
> > +#define LIBBSP_ARM_XILINX_ZYNQ_I2C_H
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +#ifdef __cplusplus
> > +extern "C" {
> > +#endif /* __cplusplus */
> > +
> > +static inline int zynqmp_register_i2c_0(void) {
> > + return i2c_bus_register_cadence(
> > +"/dev/i2c-0",
> > +0x00FF02,
> > +zynqmp_clock_i2c0(),
> > +ZYNQMP_IRQ_I2C_0
> > + );
> > +}
> > +
> > +static inline int zynqmp_register_i2c_1(void) {
> > + return i2c_bus_register_cadence(
> > +"/dev/i2c-1",
> > +0x00FF03,
> > +zynqmp_clock_i2c1(),
> > +ZYNQMP_IRQ_I2C_1
> > + );
>
> I know these are currently inlined but I do not know why they are. It is the
> only
> BSP that does this. Should they be moved to a .c file seem they are being
> touched?
>
> Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 0/5] Preliminary Exception Manager Work
On 8/23/2021 21:41, Chris Johns wrote: On 24/8/21 9:50 am, Kinsey Moore wrote: This patch set contains the result of the Exception Manager work I proposed a while back to manage handling of machine exceptions along with a general feature for mapping exceptions to POSIX signals without delving into the CPU Port-specific details. This is a pretty basic initial implementation, but it can easily be expanded with mutators for the CPU_Exception_frame for additional capabilities. Also included is a test that demonstrates usage of the Exception Manager and exception to signal mapping functionality. Could you please provide a link to the previous discussion? Most of the discussion occurred here: https://lists.rtems.org/pipermail/devel/2021-April/066597.html I sent out my consolidated thoughts here: https://lists.rtems.org/pipermail/devel/2021-April/066902.html I have some concerns on how this interface and libdebugger are to work? Theoretically, libdebugger should be able to be implemented on top of this with some additional CPU_Exception_frame and machine state manipulators. I think I captured a reasonable set of generic exceptions for this purpose. Kinsey ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
