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