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

[Chris Johns]

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?

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.

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

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

Chris