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