Re: [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
 >>> > 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 )
  +- 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [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
mailto:sebastian.hu...@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 )
     +- 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.hu...@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/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [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
>> > > 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 )
>>     +- 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Chris Johns]

[ 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
>> > > 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 )
>>     +- 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Sebastian Huber]

On 31.05.23 19:25, Joel Sherrill wrote:
On Wed, May 31, 2023 at 12:18 PM Sebastian Huber 
> 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 )
+- 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.

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@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/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Joel Sherrill]

On Wed, May 31, 2023 at 12:18 PM Sebastian Huber <
sebastian.hu...@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)
> +- 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?

>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@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/
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Sebastian Huber]

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)

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

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@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/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel