<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 25, 2019 at 9:18 AM Thomas Doerfler <<a href="mailto:thomas.doerfler@embedded-brains.de">thomas.doerfler@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
<br>
Am 25.10.19 um 16:08 schrieb Joel Sherrill:<br>
> <br>
> One question we need to discuss is what about BSPs which can run on<br>
> multiple simulators and possibly real hardware. For example, the sparc<br>
> BSPs can run on real hardware, sis, qemu, and tsim. How do we<br>
> distinguish the same BSP's expected results on > 1 platform?<br>
<br>
if I remember correctly, those BSPs targetting for multiple<br>
boards/simulators only have a limited number of target boards.<br></blockquote><div><br></div><div>The set is larger than you might think. :) From the top of my head:</div><div><br></div><div>+ RISC-V has a lot of BSPs and can run on multiple simulators (sis, spike, qemu)<br></div><div>   and maybe some on real HW</div><div>+ all SPARC BSPs (sis, some on qemu, tsim) and real hardware<br></div><div>+ PC variants<br></div><div>+ BeagleBone - one variant has qemu and HW<br></div><div>+ Zynq at least has a dedicated BSP variant for qemu so OK<br></div><div>+ Realview has qemu and real HW<br></div><div>+ some STM has a qemu support<br></div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Could we consider each (reference) target board and/or simulator instead<br>
of a BSP? The tiering may then be for a board instead of a BSP. And the<br>
BSP tier is best tier of the target boards?<br></blockquote><div><br></div><div>The tester makes a distinction (e.g. leon3-sis vs leon3-tsim or leon3-qemu) but they</div><div>all test the same binaries with different results. The set of expected failures on each</div><div>of those could be different. </div><div><br></div><div>I don't have a good answer. We currently think of three levels:</div><div><br></div><div>+ architecture<br></div><div>+ BSP Family<br></div><div>+ BSP Variant<br></div><div><br></div><div>and now we are adding the "what did we run that test on" variant for record keeping purposes</div><div><br></div><div>AFAIK The current .tcfg files control only the set of tests that would be considered permanent</div><div>failures across all "runner" variants.</div><div><br></div><div>This is just hard. :(</div><div><br></div><div>--joel</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Kind regards,<br>
<br>
Thomas.<br>
<br>
> <br>
> _______________________________________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
> <br>
<br>
-- <br>
--------------------------------------------<br>
embedded brains GmbH<br>
Thomas Doerfler<br>
Dornierstr. 4<br>
D-82178 Puchheim<br>
Germany<br>
email: <a href="mailto:Thomas.Doerfler@embedded-brains.de" target="_blank">Thomas.Doerfler@embedded-brains.de</a><br>
Phone: +49-89-18 94 741-12<br>
Fax:   +49-89-18 94 741-09<br>
PGP: Public key available on request.<br>
For our privacy statement, see<br>
<a href="https://embedded-brains.de/en/data-privacy-statement/" rel="noreferrer" target="_blank">https://embedded-brains.de/en/data-privacy-statement/</a><br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
</blockquote></div></div>