Re: Tiering, Expected Failures, and BSPs which Run on Multiple Sims/HW
On Fri, Oct 25, 2019 at 9:18 AM Thomas Doerfler < thomas.doerf...@embedded-brains.de> wrote: > Hi, > > > Am 25.10.19 um 16:08 schrieb Joel Sherrill: > > > > One question we need to discuss is what about BSPs which can run on > > multiple simulators and possibly real hardware. For example, the sparc > > BSPs can run on real hardware, sis, qemu, and tsim. How do we > > distinguish the same BSP's expected results on > 1 platform? > > if I remember correctly, those BSPs targetting for multiple > boards/simulators only have a limited number of target boards. > The set is larger than you might think. :) From the top of my head: + RISC-V has a lot of BSPs and can run on multiple simulators (sis, spike, qemu) and maybe some on real HW + all SPARC BSPs (sis, some on qemu, tsim) and real hardware + PC variants + BeagleBone - one variant has qemu and HW + Zynq at least has a dedicated BSP variant for qemu so OK + Realview has qemu and real HW + some STM has a qemu support > > Could we consider each (reference) target board and/or simulator instead > of a BSP? The tiering may then be for a board instead of a BSP. And the > BSP tier is best tier of the target boards? > The tester makes a distinction (e.g. leon3-sis vs leon3-tsim or leon3-qemu) but they all test the same binaries with different results. The set of expected failures on each of those could be different. I don't have a good answer. We currently think of three levels: + architecture + BSP Family + BSP Variant and now we are adding the "what did we run that test on" variant for record keeping purposes AFAIK The current .tcfg files control only the set of tests that would be considered permanent failures across all "runner" variants. This is just hard. :( --joel > > Kind regards, > > Thomas. > > > > > ___ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel > > > > -- > > embedded brains GmbH > Thomas Doerfler > Dornierstr. 4 > D-82178 Puchheim > Germany > email: thomas.doerf...@embedded-brains.de > Phone: +49-89-18 94 741-12 > Fax: +49-89-18 94 741-09 > PGP: Public key available on request. > For our privacy statement, see > https://embedded-brains.de/en/data-privacy-statement/ > ___ > 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: Attributes in build specification items
On Fri, Oct 25, 2019 at 2:35 AM Sebastian Huber
wrote:
>
> Hello,
>
> for the new build system the specification what to build is contained in
> so called build specification items. The items are files in YAML format
> and are maintained by Doorstop and a text editor. For example a build
> specification item for an integer configuration option could look like:
>
> active: true
> build-type: integer-option
> default: 1
> default-by-variant:
> - value: 3
>variant: xilinx_zynq_zc702
> - value: 7
>variant: xilinx_zynq_zedboard
> derived: false
> header: ''
> level: 1.5
> links: []
> name: BSP_ARM_A9MPCORE_PERIPHCLK
> normative: true
> ref: ''
> reviewed: cKwFFKjf_aPPFZe7fKyxBqYcAqdvU2A0yQaBdhbONQ8=
> text: |
>ARM Cortex-A9 MPCore PERIPHCLK clock frequency in Hz
> type: build
>
> How do we want to handle optional attributes (e.g. min)? Should we
> mandate that they are always present in the item file, e.g.
>
> min: null
>
> or should it be able to omit them and use default values in the wscript,
> e.g.
>
> min = self.data.get("min", None)
> if min not None:
> if value < min:
> error()
>
> ?
>
I would lean toward mandating that attributes used to configure should
be present in the item file. This way, the item file is archival with
respect to the build, and one doesn't need to know/read the wscript to
understand what was the configuration default value.
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> ___
> 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: Tiering, Expected Failures, and BSPs which Run on Multiple Sims/HW
Hi, Am 25.10.19 um 16:08 schrieb Joel Sherrill: > > One question we need to discuss is what about BSPs which can run on > multiple simulators and possibly real hardware. For example, the sparc > BSPs can run on real hardware, sis, qemu, and tsim. How do we > distinguish the same BSP's expected results on > 1 platform? if I remember correctly, those BSPs targetting for multiple boards/simulators only have a limited number of target boards. Could we consider each (reference) target board and/or simulator instead of a BSP? The tiering may then be for a board instead of a BSP. And the BSP tier is best tier of the target boards? Kind regards, Thomas. > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > -- embedded brains GmbH Thomas Doerfler Dornierstr. 4 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18 94 741-12 Fax: +49-89-18 94 741-09 PGP: Public key available on request. For our privacy statement, see https://embedded-brains.de/en/data-privacy-statement/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Tiering, Expected Failures, and BSPs which Run on Multiple Sims/HW
Hi Last week, there was a rare meeting of a handful of core developers. One issue was implementing the tiers of BSPs we have discussed for a couple of years now. There is general agreement on the basics of the tiering. Tier 1 has test results on hardware. Tier 2 on simulator only. Tier 3 is known to build. Tier 4 doesn't build and if that isn't fixed is a path to removal. A couple of the challenges are getting test results for lots of BSPs and digesting that into a scoreboard (potential GSoC project?). We would like BSPs to have passes and expected failures.This requires work to identify which failures are expected on a particular BSP. Again this requires help to work through the results. You can look at the build@ mailing list archive to see how many simulators I have been reporting results on. One question we need to discuss is what about BSPs which can run on multiple simulators and possibly real hardware. For example, the sparc BSPs can run on real hardware, sis, qemu, and tsim. How do we distinguish the same BSP's expected results on > 1 platform? Achieving the details of the tiering and having test results is important to the project and community. It will take community help to get results and keep BSPs at Tier 1. Please pipeup on some of the questions and see what it takes to get your favorite BSP to tier 1. Thanks. --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RSB Qemu Leon3 patches error
Hi I am not sure what's up with the Leon patches but I am getting a checksum error and wanted to see if Jiri or someone else knowledgeable could investigate and fix. warning: checksum error: 0001-LEON3-Add-emulation-of-AMBA-plug-play.patch warning: removing: 0001-LEON3-Add-emulation-of-AMBA-plug-play.patch making dir: /home/joel/rtems-cron-5/rtems-source-builder/bare/patches download: (full) https://gaisler.org/qemu/0001-LEON3-Add-emulation-of-AMBA-plug-play.patch -> patches/0001-LEON3-Add-emulation-of-AMBA-plug-play.patch download: https://gaisler.org/qemu/0001-LEON3-Add-emulation-of-AMBA-plug-play.patch -> patches/0001-LEON3-Add-emulation-of-AMBA-plug-play.patch checksums: 0001-LEON3-Add-emulation-of-AMBA-plug-play.patch: 1162bfb7b5839237803356e5fb6efaafdec5b9d2df9d23de42c86d48c5e35327 => 5f2ca77e727dc3b4f9d78ff8c62d610b1bc2afd3345106401cf26e99452db067 warning: checksum error: 0001-LEON3-Add-emulation-of-AMBA-plug-play.patch error: checksum failure file: patches/0001-LEON3-Add-emulation-of-AMBA-plug-play.patch Thanks. --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2] [rsb] Update Spike build
Thanks for updating this. When building on a very clean machine, dtc needs to be referenced and in the PATH. hecking for dtc... no configure: error: device-tree-compiler not found Is this working for you when dtc is not installed before building spike? On Thu, Oct 24, 2019 at 4:39 PM Chris Johns wrote: > On 24/10/19 7:57 pm, Hesham Almatary wrote: > > Latest Spike integrated fesvr in its source directory, so there > > is no separate fesvr anymore. > > Nice. Building and installing fesvr was a little unusual. > > 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
Re: RTEMS Google Code-In 2019
It's not that we don't like GCI or would like to mentor. Everyone who has been an org admin has conflicts with most of the schedule this year. That's also the backbone of our mentor set. We have historically alternated years. --joel On Fri, Oct 25, 2019 at 2:02 AM Ravindra Kumar Meena wrote: > Hello Himanshu, > > I am interested in mentoring for Google Code-in 2019. Looking forward to > be a part of it. > > Thanks > > On Fri, 25 Oct, 2019, 1:32 am Vaibhav Gupta, > wrote: > >> Hello everyone! >> >> I am interested in mentoring for Google Code-In 2019. >> >> -- Vaibhav Gupta >> >> On Fri, Oct 25, 2019, 1:28 AM Vijay Kumar Banerjee < >> vijaykumar9...@gmail.com> wrote: >> >>> >>> >>> >>> On Fri, Oct 25, 2019 at 12:58 AM Himanshu Sekhar Nayak < >>> himanshuwindows...@gmail.com> wrote: >>> Hi guys, So the Org. application submission is still going on and the last date is 28th Oct. As far as I know, we have collected 3 mentors and we gonna need more for mentoring students. Also mentoring and organizing the tasks for young generations is amazing and it will benefit the Org. too. So if anyone interested then let we know us so that we can participate in this competition. Hi Himanshu, >>> >>> It's really nice that you're so enthusiastic about GCI. This year, not >>> many people >>> showed interest in mentoring for GCI and the deadline to collect them is >>> very close. >>> We have only two days. >>> >>> Himanshu contacted me privately and I can try to devote some time to GCI >>> even if >>> I will be having exams at that time. But only a few of us can't handle >>> all the >>> students. We need more mentors! >>> >>> If anyone is interested in mentoring High School students during GCI, >>> please >>> let us know here. The deadline is 28th Oct. >>> >>> Best regards, >>> Vijay >>> Thanks Himanshu >>> ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Detect change in configuration file and re-configure in waf?
Hello,
the new build system uses a set of *.ini files to configure the build.
They are stored in the build lock file:
build/.lock-waf_linux2_build:options = {..., 'rtems_options':
'bsps.ini', ...}
I would like to issue a re-configuration if one of the *.ini files
changes. It would be nice if someone knows a best-practise recipe for
waf to do this.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Attributes in build specification items
Hello,
for the new build system the specification what to build is contained in
so called build specification items. The items are files in YAML format
and are maintained by Doorstop and a text editor. For example a build
specification item for an integer configuration option could look like:
active: true
build-type: integer-option
default: 1
default-by-variant:
- value: 3
variant: xilinx_zynq_zc702
- value: 7
variant: xilinx_zynq_zedboard
derived: false
header: ''
level: 1.5
links: []
name: BSP_ARM_A9MPCORE_PERIPHCLK
normative: true
ref: ''
reviewed: cKwFFKjf_aPPFZe7fKyxBqYcAqdvU2A0yQaBdhbONQ8=
text: |
ARM Cortex-A9 MPCore PERIPHCLK clock frequency in Hz
type: build
How do we want to handle optional attributes (e.g. min)? Should we
mandate that they are always present in the item file, e.g.
min: null
or should it be able to omit them and use default values in the wscript,
e.g.
min = self.data.get("min", None)
if min not None:
if value < min:
error()
?
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2 1/5] riscv: Generate linkcmds.base from the shared linkcmds.base.in
The patch set is fine to commit. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS Google Code-In 2019
Hello Himanshu, I am interested in mentoring for Google Code-in 2019. Looking forward to be a part of it. Thanks On Fri, 25 Oct, 2019, 1:32 am Vaibhav Gupta, wrote: > Hello everyone! > > I am interested in mentoring for Google Code-In 2019. > > -- Vaibhav Gupta > > On Fri, Oct 25, 2019, 1:28 AM Vijay Kumar Banerjee < > vijaykumar9...@gmail.com> wrote: > >> >> >> >> On Fri, Oct 25, 2019 at 12:58 AM Himanshu Sekhar Nayak < >> himanshuwindows...@gmail.com> wrote: >> >>> Hi guys, >>> >>> So the Org. application submission is still going on and the last date >>> is 28th Oct. As far as I know, we have collected 3 mentors and we gonna >>> need more for mentoring students. Also mentoring and organizing the tasks >>> for young generations is amazing and it will benefit the Org. too. So if >>> anyone interested then let we know us so that we can participate in this >>> competition. >>> >>> Hi Himanshu, >> >> It's really nice that you're so enthusiastic about GCI. This year, not >> many people >> showed interest in mentoring for GCI and the deadline to collect them is >> very close. >> We have only two days. >> >> Himanshu contacted me privately and I can try to devote some time to GCI >> even if >> I will be having exams at that time. But only a few of us can't handle >> all the >> students. We need more mentors! >> >> If anyone is interested in mentoring High School students during GCI, >> please >> let us know here. The deadline is 28th Oct. >> >> Best regards, >> Vijay >> >>> Thanks >>> Himanshu >>> >> ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
