<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 12, 2023 at 10:58 AM Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</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">On Mon, Jun 12, 2023 at 12:56 AM Sebastian Huber<br>
<<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>> wrote:<br>
><br>
><br>
><br>
> On 01.06.23 22:06, Gedare Bloom wrote:<br>
> > On Thu, Jun 1, 2023 at 2:00 PM Gedare Bloom<<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>>  wrote:<br>
> >> ---------- Forwarded message ---------<br>
> >> From: Sebastian Huber<<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>><br>
> >> Date: Wed, May 31, 2023 at 10:31 AM<br>
> >><br>
> >> The existing tests in the RTEMS test suite are basically BSP<br>
> >> independent. This patch set introduces BSP-specific validation tests.<br>
> >> These tests are disabled for other BSPs through the build system, for<br>
> >> example:<br>
> >><br>
> >> spec/build/testsuites/validation/bsp-sparc-leon3-gr712rc.yml<br>
> >> [...]<br>
> >> cxxflags: []<br>
> >> enabled-by: sparc/gr712rc<br>
> >> features: c cprogram<br>
> >> [...]<br>
> > The use of the enabled-by: field to control the BSP-specific tests<br>
> > looks reasonable. However, we should decide where/how any BSP-specific<br>
> > tests should reside. It looks to me like the current approach is to<br>
> > dump all test files in a single monolithic 'validation' directory, and<br>
> > let the user/script sort it out. This results in a mix of tests<br>
> > intended for all targets, and some for specific targets. This is<br>
> > pretty much non-maintainable from my point-of-view without some<br>
> > additional tool support. Correct me if I'm wrong.<br>
><br>
> Yes, this is the current approach. There is no strict one-to-one<br>
> relationship of test cases and test suites. The file names are somewhat<br>
> descriptive, for example:<br>
><br>
> ls -l *leon3*<br>
> -rw-r--r-- 1 sebastian_h domain users 3739 31. Mai 10:44<br>
> tc-bsp-sparc-leon3-gr712rc.c<br>
> -rw-r--r-- 1 sebastian_h domain users 6138 31. Mai 10:44<br>
> tc-fatal-bsp-sparc-leon3-shutdown.c<br>
> -rw-r--r-- 1 sebastian_h domain users 5135 31. Mai 10:44<br>
> tr-fatal-bsp-sparc-leon3-cache-snooping-disabled-boot.c<br>
> -rw-r--r-- 1 sebastian_h domain users 2723 31. Mai 10:44<br>
> tr-fatal-bsp-sparc-leon3-cache-snooping-disabled-boot.h<br>
> -rw-r--r-- 1 sebastian_h domain users 5406 31. Mai 10:44<br>
> tr-fatal-bsp-sparc-leon3-cache-snooping-disabled-secondary.c<br>
> -rw-r--r-- 1 sebastian_h domain users 2753 31. Mai 10:44<br>
> tr-fatal-bsp-sparc-leon3-cache-snooping-disabled-secondary.h<br>
> -rw-r--r-- 1 sebastian_h domain users 5270 31. Mai 10:44<br>
> tr-fatal-bsp-sparc-leon3-clock-initialization.c<br>
> -rw-r--r-- 1 sebastian_h domain users 2681 31. Mai 10:44<br>
> tr-fatal-bsp-sparc-leon3-clock-initialization.h<br>
> -rw-r--r-- 1 sebastian_h domain users 2488 31. Mai 10:44<br>
> ts-bsp-sparc-leon3-gr712rc.c<br>
> -rw-r--r-- 1 sebastian_h domain users 2845 31. Mai 10:44<br>
> ts-fatal-bsp-sparc-leon3-cache-snooping-disabled-boot.c<br>
> -rw-r--r-- 1 sebastian_h domain users 2919 31. Mai 10:44<br>
> ts-fatal-bsp-sparc-leon3-cache-snooping-disabled-secondary.c<br>
> -rw-r--r-- 1 sebastian_h domain users 2797 31. Mai 10:44<br>
> ts-fatal-bsp-sparc-leon3-clock-initialization.c<br>
> -rw-r--r-- 1 sebastian_h domain users 3148 31. Mai 10:45<br>
> ts-fatal-bsp-sparc-leon3-shutdown-response.c<br>
> -rw-r--r-- 1 sebastian_h domain users 4909 31. Mai 10:44<br>
> ts-fatal-bsp-sparc-leon3-shutdown.c<br>
><br>
> We could also introduce subdirectories to organize things. The test<br>
> framework prints out the file name in messages, so it would be nice if<br>
> they remain unique. With subdirectories this would lead to longer path<br>
> names, for example<br>
><br>
> testsuites/validation/sparc/leon3/tc-bsp-sparc-leon3-gr712rc.c<br>
><br>
I see. Maybe it makes sense to have all BSP-specific tests in a bsps<br>
subdirectory, with the unique names encoded to ensure the arch/bsp<br>
combination appears in the filename, such as:<br>
testsuites/validation/bsps/tc-bsp-sparc-leon3-gr712rc.c<br>
If so, 'bsp-' can probably be omitted from the filename. This way,<br>
architecture-specific testing may also be easily possible, like<br>
tc-sparc-something.c<br></blockquote><div><br></div><div>We also have to account for device driver/class type tests which </div><div>are not BSP specific but only work if a BSP supports a specific feature.</div><div>For example, Alex wrote some GPIO tests for the Microblaze work. Assuming </div><div>these were based on a common GPIO API, they would work on any BSP</div><div>which supported that API. </div><div><br></div><div>Similarly for other optional devices where the drivers are in rtems.git</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>
> ><br>
> > I would like to discuss possible ways to manage the integration of<br>
> > tests that are conditionally-built based on the arch/bsp tuple. We<br>
> > should have clear guidance for others who want to add such tests in<br>
> > the future, or who would modify existing tests.<br>
><br>
> Yes, this makes sense. We could add a new section for BSP-specific tests to:<br>
><br>
> <a href="https://docs.rtems.org/branches/master/eng/req/howto.html" rel="noreferrer" target="_blank">https://docs.rtems.org/branches/master/eng/req/howto.html</a><br>
><br>
> For a pre-qualified BSP you have to specify the fatal errors and write<br>
> validation tests for it. Other BSP-specific specification and validation<br>
> may be necessary for the kernel IO device driver, cache controller<br>
> support, memory management unit initialization, memory protection unit<br>
> initialization, etc.<br>
><br>
Good, that would definitely be important to document.<br>
<br>
I think we should have some of the BSP-specific tests under some other<br>
location in testsuites, while others would be under validation where<br>
they are used for pre-qualification?<br>
<br>
Maybe it is sensible to introduce testsuites/bsps/ also.<br>
<br>
I'm not entirely clear about the difference between 'validation' and<br>
any other kind of tests, such as where specific tests should be<br>
located.<br>
<br>
> Even for normal BSPs, some unit tests would be helpful. For example, I<br>
> had to fix _AArch32_PMSA_Initialize() twice:<br>
><br>
> <a href="https://github.com/RTEMS/rtems/commits/master/cpukit/score/cpu/arm/aarch32-psma-init.c" rel="noreferrer" target="_blank">https://github.com/RTEMS/rtems/commits/master/cpukit/score/cpu/arm/aarch32-psma-init.c</a><br>
><br>
> Unit tests would have probably found the errors before applications hit<br>
> the special cases.<br>
><br>
Something like testsuites/bsps/arm-aarch32-psma-init.c (or whatever<br>
file naming convention we like to decide on. I forget the meaning of<br>
tc/tr/ts/tx but recall they are about specific kinds of testing for<br>
validation.)<br></blockquote><div><br></div><div>I was wondering it we more of less mirrored the bsps/ structure</div><div><br></div><div>shared/</div><div>ARCH/shared</div><div>ARCH/BSP</div><div><br></div><div>We have solved this problem elsewhere. We don't have to encode it in the file names. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Gedare<br>
<br>
> --<br>
> embedded brains GmbH<br>
> Herr Sebastian HUBER<br>
> Dornierstr. 4<br>
> 82178 Puchheim<br>
> Germany<br>
> email: <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
> phone: +49-89-18 94 741 - 16<br>
> fax:   +49-89-18 94 741 - 08<br>
><br>
> Registergericht: Amtsgericht München<br>
> Registernummer: HRB 157899<br>
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler<br>
> Unsere Datenschutzerklärung finden Sie hier:<br>
> <a href="https://embedded-brains.de/datenschutzerklaerung/" rel="noreferrer" target="_blank">https://embedded-brains.de/datenschutzerklaerung/</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></blockquote></div></div>