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.hu...@embedded-brains.de
<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 <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
