[PATCH 01/34] validation: Test sparc/leon3 BSP family

[Sebastian Huber]

On 02.06.23 02:57, Chris Johns wrote:
> [ resending ... ]
> 
> On 1/6/2023 3:28 am, Sebastian Huber wrote:
>> On 31.05.23 19:25, Joel Sherrill wrote:
>>> On Wed, May 31, 2023 at 12:18 PM Sebastian Huber
>>> <sebastian.huber at embedded-brains.de
>>> <mailto:sebastian.huber at embedded-brains.de>> wrote:
>>>
>>>      On 31.05.23 19:14, Joel Sherrill wrote:
>>>       > This patch has a couple of issues.
>>>       >
>>>       > (1) It includes modifications to arm files which doesn't seem
>>>      consistent.
>>>
>>>      Sorry, these are
>>>
>>>      -- Copyright (C) 2020-2023 embedded brains GmbH
>>>      (http://www.embedded-brains.de <http://www.embedded-brains.de>)
>>>      +- Copyright (C) 2020-2023 embedded brains GmbH & Co. KG
>>>
>>>      changes added by accident. I will fix this separately.
>>>
>>>       >
>>>       > (2) It adds BSP specific tests. There has been on discussion of
>>>      how BSP
>>>       > specific
>>>       > tests should be included in the tree. We have some in this
>>>      category and
>>>       > I am pretty
>>>       > sure Chris has some as well. We need to have a consistent
>>>      approach to
>>>       > where they
>>>       > go.
>>>
>>>      Yes, this is why I mentioned this in the cover letter.
>>>
>>>      The new build system can handle BSP-specific tests quite easily.
>>>
>>>
>>> I didn't argue that. Do we have a discussed and agreed upon location and
>>> organization for these tests?
>>
>> No, this is why I mentioned this in the cover letter.
>>
> 
> There is currently 295 files in testsuites/validation without these new ones. Is
> there an limit on the number of files we put here? Are all the files generated?

All files are generated, except the ones matching tx-*.

> 
> I think adding hardware tests to testsuites/validation is starting to pull the
> validation string a bit far. I suggest somewhere else specific to bsps, a bsp
> family or arch. The level could reflect how the drivers and tests may be shared.
> I guess grlib will end up in leon and riscv flavours.

I like Gedares suggestion.

> 
> There appears to be a naming convention in use in the validation directory but I
> could not see if this is explained?

I will add something to

https://docs.rtems.org/branches/master/eng/req/howto.html

> 
> A leon of any type is a tier 2 device and with no published hardware test
> results I have no idea about any of this code and we have no means to show
> otherwise. 

Test results are available in the QDPs:

https://rtems-qual.io.esa.int/

> I have no specific objection to the changes and I think the change to
> use store and load functions is a good move but the use of a struct member to
> generate the address makes the change seem half done. Is there a validation test
> with the register offsets as constants that checks the register offsets in the
> reg structs are valid?

There are no validation tests for this. They could be generated, 
however, I see no need for this. The structure layout is clearly defined 
by the ABI.

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber at embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/