Re: [PATCH v3 2/2] update README with instructions for stm32 patch
Hi Robin, Looks like this patch answers one of my questions in the other patch. This looks good and can be merged after the first patch. Thanks! On Sun, Oct 24, 2021 at 4:59 AM Robin Müller wrote: > > Hi, > > This patch now contains all files which have the problematic license so the > RTMES LwIP code stays free of them. > Actually, it probably would be a better idea if the patch is applied as > part of the build process.. Does anyone have experience how to do this with > waf? > > Kind Regards > Robin Müller > > On Sun, 24 Oct 2021 at 12:54, Robin Mueller > wrote: > > > --- > > README.md | 10 ++ > > 1 file changed, 10 insertions(+) > > > > diff --git a/README.md b/README.md > > index ebbef12..3653b67 100644 > > --- a/README.md > > +++ b/README.md > > @@ -17,6 +17,16 @@ It is recommended that the user supplies the > > `lwipopts.h` configuration file. Th > > contain template option files to get started. The user can copy and > > rename this files into the > > application and then pass the include path to the build system using the > > `--lwip-opts` option. > > > > +# Applying the STM32 patch file > > + > > +Some STM32 files are problematic due to the used license. Therefore, they > > are applied in form of > > +a patch. You need to perform the following steps in order to use the > > STM32H7 BSP: > > + > > +```sh > > +wget -O stm32.patch > > https://raw.githubusercontent.com/robamu-org/rtems-stm32-lwip-port-patch/main/stm32-bsp-eth-dhcp-files.patch > > +git am stm32.patch > > +``` > > + > > # Building with waf > > > > It is assumed that the path(s) containing the `lwipopts.h` file was > > stored in the environmental > > -- > > 2.32.0 > > > > > ___ > 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: i386 and epiphany on FreeBSD 13 for rtems 5
On 12/22/21 3:51 PM, Joel Sherrill wrote: > Hi > > Both i386 and epiphany rtems 5 GCC fail to build on FreeBSD 13. It > appears that the newer compiler on FreeBSD 13 does not like some code > from the older GCC. > > Logs linked here: > > epiphany - https://lists.rtems.org/pipermail/build/2021-December/030627.html > > i386 - https://lists.rtems.org/pipermail/build/2021-December/030628.html > > I only see two fixes. (1) Add --disable-werror to these targets on > rtems5 or (2) update the gcc on rtems5. We always are resistant to (2) > so I guess that leaves us with option (1). > > Thoughts, comments, jokes, concurrence? joke? Here is one: what about to bootstrap native gcc 7.5.0 with --disable-werror and then use that to compile i386 cross-compiler? Remark: looks like you will not be able to keep tools from past working on modern systems indefinitely which means you can also declare rtems5 tools support for FreeBSD 12.x max. Or, what about to require installed gcc able to bootstrap cross-compiler without issues? My pretty current FreeBSD 14 provides following gccs: $ pkg search gcc|grep "GNU Compiler Collection"|grep -v "Cross" aarch64-none-elf-gcc-8.4.0_3 GNU Compiler Collection for bare metal aarch64 cross-development arm-none-eabi-gcc-8.4.0_3 GNU Compiler Collection for bare metal arm cross-development arm-none-eabi-gcc492-4.9.2_5 GNU Compiler Collection for bare metal arm cross-development gcc-10_4 Meta-port for the default version of the GNU Compiler Collection gcc10-10.3.0 GNU Compiler Collection 10 gcc10-devel-10.3.1.s20211008 GNU Compiler Collection 10 gcc11-11.2.0 GNU Compiler Collection 11 gcc11-devel-11.2.1.s20211009 GNU Compiler Collection 11 gcc12-devel-12.0.0.s20211128 GNU Compiler Collection 12 gcc48-4.8.5_14 GNU Compiler Collection 4.8 gcc8-8.5.0_1 GNU Compiler Collection 8 gcc9-9.4.0 GNU Compiler Collection 9 gcc9-devel-9.4.1.s20211007 GNU Compiler Collection 9 riscv32-unknown-elf-gcc-8.4.0_3 GNU Compiler Collection for bare metal riscv32 cross-development riscv64-none-elf-gcc-8.4.0_3 GNU Compiler Collection for bare metal riscv64 cross-development I guess this is more than enough to throw away system wide clang and use one of those? Karel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: New validation test suites
On 17/12/2021 04:34, Chris Johns wrote:
On 16/12/21 6:36 pm, Sebastian Huber wrote:
On 16/12/2021 04:51, Chris Johns wrote:
On 16/12/21 3:27 am, Sebastian Huber wrote:
On 15/12/2021 06:46, Chris Johns wrote:
On 14/12/21 6:24 pm, Sebastian Huber wrote:
Hello Chris,
On 13/12/2021 22:01, Chris Johns wrote:
On 14/12/21 1:53 am, Sebastian Huber wrote:
[...]
We finished the specification of the pre-qualified RTEMS feature set. The
specification is available in an RTEMS Project repository:
https://git.rtems.org/rtems-central/tree/spec
I had a quick look. Is there a more user friendly view of this data?
I think the term "specification" is a little bit misleading because the data
files are not easily read by a person. I understand this is the specification
data set however it is not what I am traditionally use to seeing.
You can use the "./specview.py" script to get views of the specification. For
example, this command displays the transition map for the rtems_signal_send()
directive:
Is specview.py part of rtems.git?
No, this script is in rtems-central. This is also the location of the
specification items.
I am not sure linking a script from that repo like this is helpful.
If not part of rtems.git how much data is there for all the output? That is it
is generated and held in the repo with the tests?
In rtems.git, there are only the generated sources.
[...]
There should be no reach back to the upstream specs, scripts etc and for good
reasons. The information you posted is nice and useful and I do not wish to
release manage rtems-central to accommodate these tests in a release.
Would capturing that information with the tests be something worth doing?
I don't think it would be useful. If you want to modify the tests you should
work with the specification items and the corresponding scripts.
This is not about modifying the tests. As I previously stated the tests provide
little detail on the verification matrix being solved.
In relation to where is best to make changes, rtems-central may be the best
place however we will accept patches to the tests as they are in rtems.git. How
that is pushed back to rtems-central is not a focus here.
In theory, you can change the tests by hand, however, this is very
difficult. I had to compact the preconditions to postconditions table to
reduce the data size of the tests. It looks now like this:
static const ScoreSchedReqYield_Entry
ScoreSchedReqYield_Entries[] = {
#if !defined(RTEMS_SMP)
{ 1, 0, 0, 0, 0, 0, ScoreSchedReqYield_Post_HomeSchedulerState_NA,
ScoreSchedReqYield_Post_AskForHelp_NA },
#else
{ 1, 0, 0, 0, 0, 0, ScoreSchedReqYield_Post_HomeSchedulerState_NA,
ScoreSchedReqYield_Post_AskForHelp_NA },
#endif
{ 1, 0, 0, 0, 0, 0, ScoreSchedReqYield_Post_HomeSchedulerState_NA,
ScoreSchedReqYield_Post_AskForHelp_NA },
[...]
#if !defined(RTEMS_SMP)
{ 1, 0, 0, 0, 0, 0, ScoreSchedReqYield_Post_HomeSchedulerState_NA,
ScoreSchedReqYield_Post_AskForHelp_NA }
#else
{ 0, 0, 0, 0, 0, 0, ScoreSchedReqYield_Post_HomeSchedulerState_Idle,
ScoreSchedReqYield_Post_AskForHelp_No }
#endif
};
static const uint8_t
ScoreSchedReqYield_Map[] = {
0, 0, 2, 2, 3, 8, 10, 11, 0, 0, 2, 2, 4, 4, 1, 1, 5, 5, 1, 1, 5, 5,
1, 1, 0,
0, 6, 6, 12, 8, 13, 14, 0, 0, 6, 6, 4, 4, 9, 9, 3, 15, 7, 7, 3, 3, 7, 7
};
If you want to work with these tests, then you definitely should do this
via rtems-central.
Adding the
tables as comments would blow up the sources considerably. Some tests have about
5 table entries and the table entries depend on C preprocessor defines.
Ah yes I agree and what I was wanting to understand.
I think we need to understand what a release will contain because the specs used
are not captured with a release. I appreciate the efforts to make this available
as a workflow for development and for the pre-qual process but I am now
critically examining what this means for a release. For example lets say years
after a release someone questions a test, they will only have the test source
code in the release package and I think this is a short coming. Adding the
rtems-central repo as a package to the releases source may be a solution however
this creates further issues. How do I know the master of the rtems-central and
the committed sources match when creating the release as separate pieces of
rtems.git may have been updated at different commit points in rtems-central?
I suggest we get together when we can. Contact me off-line and lets see if we
can arrange a time :)
We can add a release branch to rtems-central. The RTEMS sources are
included as a Git submodule.
[...]
In an earlier version of the header, we had a link which you didn't like:
If I need to look at the formatting rules the heading "Software Development
Management" is easy to see and then a click on "Coding Standards" gives me what
I am looking for.
To generate these headers I click on "Software Requirements Engineering" and
then do I just
i386 and epiphany on FreeBSD 13 for rtems 5
Hi Both i386 and epiphany rtems 5 GCC fail to build on FreeBSD 13. It appears that the newer compiler on FreeBSD 13 does not like some code from the older GCC. Logs linked here: epiphany - https://lists.rtems.org/pipermail/build/2021-December/030627.html i386 - https://lists.rtems.org/pipermail/build/2021-December/030628.html I only see two fixes. (1) Add --disable-werror to these targets on rtems5 or (2) update the gcc on rtems5. We always are resistant to (2) so I guess that leaves us with option (1). Thoughts, comments, jokes, concurrence? --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RE: [rtems-tools] tester: Update jobs configuration
ping
-Original Message-
From: Ryan Long
Sent: Wednesday, December 8, 2021 9:29 AM
To: devel@rtems.org
Subject: Re: [rtems-tools] tester: Update jobs configuration
ping
On 11/1/2021 5:31 PM, Ryan Long wrote:
> ping
>
> -Original Message-
> From: Ryan Long
> Sent: Wednesday, October 20, 2021 3:06 PM
> To: devel@rtems.org
> Cc: Ryan Long
> Subject: [rtems-tools] tester: Update jobs configuration
>
> Allow for default_jobs and max_jobs to be specified in the BSP's
> configuration file.
> ---
> rtemstoolkit/options.py| 45
> +-
> tester/rtems/testing/bsps/beagleboardxm.ini| 2 +-
> tester/rtems/testing/bsps/beagleboneblack.ini | 2 +-
> tester/rtems/testing/bsps/imx7.ini | 2 +-
> tester/rtems/testing/bsps/mcf5235.ini | 2 +-
> tester/rtems/testing/bsps/mvme2307.ini | 2 +-
> tester/rtems/testing/bsps/pc.ini | 2 +-
> tester/rtems/testing/bsps/qoriq_e500.ini | 2 +-
> tester/rtems/testing/bsps/qoriq_e6500_32.ini | 2 +-
> tester/rtems/testing/bsps/qoriq_e6500_64.ini | 2 +-
> tester/rtems/testing/bsps/raspberrypi2.ini | 2 +-
> tester/rtems/testing/bsps/xilinx_versal_vck190.ini | 2 +-
> .../rtems/testing/bsps/xilinx_zynq_a9_qemu_smp.ini | 2 +-
> tester/rtems/testing/bsps/xilinx_zynq_zc706.ini| 2 +-
> tester/rtems/testing/bsps/xilinx_zynq_zedboard.ini | 2 +-
> .../testing/bsps/xilinx_zynqmp_ilp32_zu3eg.ini | 2 +-
> .../testing/bsps/xilinx_zynqmp_lp64_zu3eg.ini | 2 +-
> tester/rtems/testing/defaults.mc | 2 +
> 18 files changed, 45 insertions(+), 34 deletions(-)
>
> diff --git a/rtemstoolkit/options.py b/rtemstoolkit/options.py index
> 5ebe3bc..4b7a93a 100644
> --- a/rtemstoolkit/options.py
> +++ b/rtemstoolkit/options.py
> @@ -102,7 +102,7 @@ class command_line(object):
> '--no-clean': 'Do not clean up the build
> tree',
> '--always-clean': 'Always clean the build tree,
> even with an error',
> '--keep-going': 'Do not stop on an error.',
> -'--jobs=[0..n,none,half,full]': 'Run with specified number of
> jobs, default: num CPUs.',
> +'--jobs=[0..n,none,half,full]': 'Run with specified
> + number of jobs (default: defined in configuration file)',
> '--macros file[,file]': 'Macro format files to load
> after the defaults',
> '--log file': 'Log file where all build
> output is written to',
> }
> @@ -327,6 +327,11 @@ class command_line(object):
> # Handle the jobs for make
> if '_ncpus' not in self.defaults:
> raise error.general('host number of CPUs not set')
> +if self.defaults['default_jobs'] != '0':
> +print(
> +'default_jobs is %d and the default is %d' %
> +(self.defaults['default_jobs'], 0)
> +)
> ncpus = self.jobs(self.defaults['_ncpus'])
> if ncpus > 1:
> self.defaults['_smp_mflags'] = '-j %d' % (ncpus) @@ -427,28
> +432,25 @@ class command_line(object):
> um += [m]
> return um if len(um) else None
>
> -def jobs(self, cpus):
> +def jobs(self, num_cpus):
> try:
> -cpus = int(cpus)
> +cpus = int(num_cpus)
> except:
> raise error.general('invalid host cpu value')
> opt_jobs = self.opts['jobs']
> if opt_jobs == 'default':
> -_jobs = self.defaults.get_value('jobs')
> -if _jobs is not None:
> -if _jobs == 'none':
> -cpus = 0
> -elif _jobs == 'max':
> -pass
> -elif _jobs == 'half':
> -cpus = cpus / 2
> -else:
> -try:
> -cpus = int(_jobs)
> -except:
> -raise error.general('invalid %%{jobs} value: %s' %
> (_jobs))
> +_jobs = self.defaults.get_value('default_jobs')
> +if _jobs == 'none':
> +cpus = 0
> +elif _jobs == 'max':
> +pass
> +elif _jobs == 'half':
> +cpus = cpus / 2
> else:
> -opt_jobs = 'max'
> +try:
> +cpus = int(_jobs)
> +except:
> +raise error.general('invalid %%{jobs} value: %s'
> + %
> + (_jobs))
> if opt_jobs != 'default':
> if opt_jobs == 'none':
> cpus = 0
> @@ -474,7 +476,14 @@ class command_line(object):
> if not ok:
> raise error.internal('bad jobs option: %s' %
> (opt_jobs))
> if cpus <= 0:
> -
Re: [PATCH rtems-docs v2] Update package list for Ubuntu
Hi, > On 20 Dec 2021, at 17:22, Ryan Long wrote: > > Updated the latest version referenced of Ubuntu to 21.04, updated > package list, and identified what packages need to still be installed > afterwards to pass sb-check. This should be 20.04, to match the patch > -The latest version is Ubuntu 18.04.1 LTS 64-bit. This section also includes > +The latest version is Ubuntu 20.04.3 LTS 64-bit. This section also includes Regards, Anders Montonen ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
