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

[Chris Johns]

On 14/6/2023 1:02 am, Sebastian Huber wrote:
> 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-*.

OK

>> 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.

Great

>> 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

Thanks

>> 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/

"Access denied"

The GSoC project active this year will scrap the build list emails and in time
generate the tier results so posting something to that list is the best way to
handle this.

>> 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.

You are more trusting the compiler is right than me. I would have thought
showing it is doing the right thing is what validation tests are for?

I should point out adding offsets as values anywhere kind of removes the need
for a struct. :) The function interface you are adding could accept them
directly. Offsets are humanly verifiable and not effected by the compiler.

Chris