Re: [PATCH 2/3] build: Replace variant patterns with a list
On 20.01.23 00:36, Chris Johns wrote: So let me turn this around ... I am do not understand your resistance to there being importable modules of python in rtems.git to read and write these files in rtems.git? These modules are in rtems-central.git (which has rtems.git as a submodule) together with the format specification. How can I use them in rtems.git? -- 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 2/3] build: Replace variant patterns with a list
On 19/1/2023 6:06 pm, Sebastian Huber wrote: > On 19.01.23 01:17, Chris Johns wrote: Why has this been done? >>> The enabled-by expressions used in patch 3 do not support regular >>> expressions. >> I did not pick that up. Why was that regx functionality removed? Is it >> related >> to scripting and rtems-central? > > The enabled-by expressions supported by the wscript don't support regular > expressions: > > https://github.com/RTEMS/rtems/blob/master/wscript#L144 > > The interesting part of the patch set is patch 3: > > Merge the "default" and "default-by-variant" attributes. Use an > "enabled-by" expression to select the default value based on the enabled > set. This makes it possible to select default values depending on other > options. For example you could choose memory settings based on whether > RTEMS_SMP is enabled or disabled. Thanks, this make sense. I had not made the connections. Why the noise in the patch of only lines being moved? Where has this come from? Is there a new requirement spec fields be in some osrt of order? >>> I did the change with a script which sorted the lists. In general, the lists >>> should be sorted. >> This is a good example of problems a lack of scripting support along side the >> build spec files creates. It makes manual changes difficult when rules get >> layered like this plus it means you are the only one who can make generated >> changes without there being a clash of scripting specifics, ie my script vs >> your >> script or something like that. > > I don't understand what is the problem with the sorted lists. If you have a > list > of unordered phrases, it is not unusual to still sort them in lexicographic > order. I welcome sorted entries. Manual edits may or may not be sorted so we end up with a mix and when a "magic" script runs again it generates more of these white space changes. If I can run: ./waf formatspec the "magic" happens it is easy to document and for any user to update these files, run a command and know the results are OK to post. It is no different to the work Gedare is doing to get the code formatting sorted so none us have to audit formatting of the code. So let me turn this around ... I am do not understand your resistance to there being importable modules of python in rtems.git to read and write these files in rtems.git? >> And I have no intention in cloning rtems-central and learning how to use it. >> There was a primary agreement for the separation of all qual work and the >> ability for it to be removed from the project without any side effects. > > You don't have to use the stuff in rtems-central, it could be just more > convenient and efficient. It would be possible to write a Github action which > checks that the build items match the expected format for pull requests. Lets not bring more github stuff into our workflows. There is no agreement that github is what this project wants to use. I am OK with automation if it is something we can manage. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 2/3] build: Replace variant patterns with a list
On 19.01.23 01:17, Chris Johns wrote: Why has this been done? The enabled-by expressions used in patch 3 do not support regular expressions. I did not pick that up. Why was that regx functionality removed? Is it related to scripting and rtems-central? The enabled-by expressions supported by the wscript don't support regular expressions: https://github.com/RTEMS/rtems/blob/master/wscript#L144 The interesting part of the patch set is patch 3: Merge the "default" and "default-by-variant" attributes. Use an "enabled-by" expression to select the default value based on the enabled set. This makes it possible to select default values depending on other options. For example you could choose memory settings based on whether RTEMS_SMP is enabled or disabled. Why the noise in the patch of only lines being moved? Where has this come from? Is there a new requirement spec fields be in some osrt of order? I did the change with a script which sorted the lists. In general, the lists should be sorted. This is a good example of problems a lack of scripting support along side the build spec files creates. It makes manual changes difficult when rules get layered like this plus it means you are the only one who can make generated changes without there being a clash of scripting specifics, ie my script vs your script or something like that. I don't understand what is the problem with the sorted lists. If you have a list of unordered phrases, it is not unusual to still sort them in lexicographic order. And I have no intention in cloning rtems-central and learning how to use it. There was a primary agreement for the separation of all qual work and the ability for it to be removed from the project without any side effects. You don't have to use the stuff in rtems-central, it could be just more convenient and efficient. It would be possible to write a Github action which checks that the build items match the expected format for pull requests. -- 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 2/3] build: Replace variant patterns with a list
On 18/1/2023 6:00 pm, Sebastian Huber wrote: > On 18.01.23 04:59, Chris Johns wrote: >> Hi Sebastian, >> >> I had not got to this part of the patch set because the other was being >> discussed. I thought a patch set was considerd as a whole rather than having >> to >> deal with the extra complexity of possible splits and if they exist? If this >> was >> pull request or merge request in a tool none of this patch set would have >> been >> applied unless split into separate merge reguests. :) > > Sorry, I thought you were already finished with the patch set. Maybe we should > move the patch review to pull requests. I am still buried after being away and no I was not finsihed. I am sorry for the confusion. >> Why has this been done? > > The enabled-by expressions used in patch 3 do not support regular expressions. I did not pick that up. Why was that regx functionality removed? Is it related to scripting and rtems-central? >> Why the noise in the patch of only lines being moved? Where has this come >> from? >> Is there a new requirement spec fields be in some osrt of order? > > I did the change with a script which sorted the lists. In general, the lists > should be sorted. This is a good example of problems a lack of scripting support along side the build spec files creates. It makes manual changes difficult when rules get layered like this plus it means you are the only one who can make generated changes without there being a clash of scripting specifics, ie my script vs your script or something like that. And I have no intention in cloning rtems-central and learning how to use it. There was a primary agreement for the separation of all qual work and the ability for it to be removed from the project without any side effects. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 2/3] build: Replace variant patterns with a list
On 18.01.23 04:59, Chris Johns wrote: Hi Sebastian, I had not got to this part of the patch set because the other was being discussed. I thought a patch set was considerd as a whole rather than having to deal with the extra complexity of possible splits and if they exist? If this was pull request or merge request in a tool none of this patch set would have been applied unless split into separate merge reguests. :) Sorry, I thought you were already finished with the patch set. Maybe we should move the patch review to pull requests. Why has this been done? The enabled-by expressions used in patch 3 do not support regular expressions. Why the noise in the patch of only lines being moved? Where has this come from? Is there a new requirement spec fields be in some osrt of order? I did the change with a script which sorted the lists. In general, the lists should be sorted. Thanks Chris On 12/1/2023 11:03 pm, Sebastian Huber wrote: Replace the variant patterns in the default-by-variant list with an explicit list of matching BSPs. The change was tested by comparing the output of ./waf bspdefaults before and after the change. The change message does not explain the line movements. Chris --- .../bsps/aarch64/xilinx-zynqmp/optclki2c0.yml | 8 +++ .../bsps/aarch64/xilinx-zynqmp/optclki2c1.yml | 8 +++ .../bsps/aarch64/xilinx-zynqmp/optclkuart.yml | 7 +-- .../bsps/aarch64/xilinx-zynqmp/optloadoff.yml | 2 +- .../bsps/aarch64/xilinx-zynqmp/optramori.yml | 2 +- .../arm/altera-cyclone-v/optclkfastidle.yml | 4 +++- spec/build/bsps/arm/beagle/optam335x.yml | 3 ++- spec/build/bsps/arm/beagle/optdebug.yml | 3 ++- spec/build/bsps/arm/beagle/optdm3730.yml | 3 ++- spec/build/bsps/arm/imx/optcachedata.yml | 4 +++- spec/build/bsps/arm/imx/optcacheinst.yml | 4 +++- spec/build/bsps/arm/lm3s69xx/optgpioahb.yml | 4 ++-- spec/build/bsps/arm/lm3s69xx/optgpionum.yml | 7 --- spec/build/bsps/arm/lm3s69xx/optlm3s3749.yml | 2 +- spec/build/bsps/arm/lm3s69xx/optlm3s6965.yml | 3 ++- spec/build/bsps/arm/lm3s69xx/optlm4f120.yml | 2 +- spec/build/bsps/arm/lm3s69xx/optssiblks.yml | 7 --- spec/build/bsps/arm/lm3s69xx/optsysclk.yml| 6 -- spec/build/bsps/arm/lm3s69xx/optudma.yml | 4 ++-- spec/build/bsps/arm/lm3s69xx/optxtalcfg.yml | 7 --- spec/build/bsps/arm/lpc24xx/optcclk.yml | 12 +++ spec/build/bsps/arm/lpc24xx/optdmachn.yml | 11 -- spec/build/bsps/arm/lpc24xx/optemcclkdiv.yml | 6 -- .../bsps/arm/lpc24xx/optemcis42s32800b.yml| 4 ++-- .../bsps/arm/lpc24xx/optemcis42s32800d7.yml | 3 ++- .../build/bsps/arm/lpc24xx/optemcm29w160e.yml | 3 ++- .../bsps/arm/lpc24xx/optemcm29w320e70.yml | 3 ++- .../bsps/arm/lpc24xx/optemcmt48lc4m16a2.yml | 3 ++- spec/build/bsps/arm/lpc24xx/optethrmii.yml| 5 - spec/build/bsps/arm/lpc24xx/optheapext.yml| 3 ++- spec/build/bsps/arm/lpc24xx/optoscmain.yml| 3 ++- spec/build/bsps/arm/lpc24xx/optotgi2c.yml | 6 -- spec/build/bsps/arm/lpc24xx/optpclkdiv.yml| 6 -- spec/build/bsps/arm/lpc24xx/optstopeth.yml| 3 ++- spec/build/bsps/arm/lpc24xx/optstopusb.yml| 3 ++- spec/build/bsps/arm/lpc24xx/optuart1cfg.yml | 5 - spec/build/bsps/arm/lpc24xx/optuart2cfg.yml | 12 --- spec/build/bsps/arm/lpc24xx/optuart3cfg.yml | 7 +-- spec/build/bsps/arm/lpc32xx/optotgi2c.yml | 4 +++- spec/build/bsps/arm/lpc32xx/optotgvbus.yml| 4 +++- spec/build/bsps/arm/lpc32xx/optscratchsz.yml | 4 +++- .../bsps/arm/realview-pbx-a9/optcachedata.yml | 4 +++- .../bsps/arm/realview-pbx-a9/optcacheinst.yml | 4 +++- .../arm/realview-pbx-a9/optclkbootcpu.yml | 4 +++- .../arm/realview-pbx-a9/optclkfastidle.yml| 4 +++- spec/build/bsps/arm/stm32f4/opteni2c1.yml | 2 +- spec/build/bsps/arm/stm32f4/optf10xxx.yml | 2 +- spec/build/bsps/arm/stm32f4/optf4.yml | 2 +- spec/build/bsps/arm/stm32f4/opthclk.yml | 2 +- spec/build/bsps/arm/stm32f4/optpclk1.yml | 2 +- spec/build/bsps/arm/stm32f4/optpclk2.yml | 2 +- spec/build/bsps/arm/stm32f4/optsysclk.yml | 2 +- spec/build/bsps/arm/stm32h7/abi.yml | 2 +- spec/build/bsps/arm/stm32h7/optbootcore.yml | 4 ++-- spec/build/bsps/arm/stm32h7/optenuart4.yml| 4 ++-- spec/build/bsps/arm/stm32h7/optenuart5.yml| 6 +++--- spec/build/bsps/arm/stm32h7/optenuart7.yml| 6 +++--- spec/build/bsps/arm/stm32h7/optenuart8.yml| 2 +- spec/build/bsps/arm/stm32h7/optenuart9.yml| 6 +++--- spec/build/bsps/arm/stm32h7/optenusart10.yml | 6 +++--- spec/build/bsps/arm/stm32h7/optenusart3.yml | 6 +++--- spec/build/bsps/arm/stm32h7/optenusart6.yml | 6 +++--- spec/build/bsps/arm/stm32h7/optlinkcmds.yml | 8 +++ .../bsps/arm/stm32h7/optmemflashorigin.yml| 2 +-
Re: [PATCH 2/3] build: Replace variant patterns with a list
Hi Sebastian, I had not got to this part of the patch set because the other was being discussed. I thought a patch set was considerd as a whole rather than having to deal with the extra complexity of possible splits and if they exist? If this was pull request or merge request in a tool none of this patch set would have been applied unless split into separate merge reguests. :) Why has this been done? Why the noise in the patch of only lines being moved? Where has this come from? Is there a new requirement spec fields be in some osrt of order? Thanks Chris On 12/1/2023 11:03 pm, Sebastian Huber wrote: > Replace the variant patterns in the default-by-variant list with an > explicit list of matching BSPs. > > The change was tested by comparing the output of > > ./waf bspdefaults > > before and after the change. The change message does not explain the line movements. Chris > --- > .../bsps/aarch64/xilinx-zynqmp/optclki2c0.yml | 8 +++ > .../bsps/aarch64/xilinx-zynqmp/optclki2c1.yml | 8 +++ > .../bsps/aarch64/xilinx-zynqmp/optclkuart.yml | 7 +-- > .../bsps/aarch64/xilinx-zynqmp/optloadoff.yml | 2 +- > .../bsps/aarch64/xilinx-zynqmp/optramori.yml | 2 +- > .../arm/altera-cyclone-v/optclkfastidle.yml | 4 +++- > spec/build/bsps/arm/beagle/optam335x.yml | 3 ++- > spec/build/bsps/arm/beagle/optdebug.yml | 3 ++- > spec/build/bsps/arm/beagle/optdm3730.yml | 3 ++- > spec/build/bsps/arm/imx/optcachedata.yml | 4 +++- > spec/build/bsps/arm/imx/optcacheinst.yml | 4 +++- > spec/build/bsps/arm/lm3s69xx/optgpioahb.yml | 4 ++-- > spec/build/bsps/arm/lm3s69xx/optgpionum.yml | 7 --- > spec/build/bsps/arm/lm3s69xx/optlm3s3749.yml | 2 +- > spec/build/bsps/arm/lm3s69xx/optlm3s6965.yml | 3 ++- > spec/build/bsps/arm/lm3s69xx/optlm4f120.yml | 2 +- > spec/build/bsps/arm/lm3s69xx/optssiblks.yml | 7 --- > spec/build/bsps/arm/lm3s69xx/optsysclk.yml| 6 -- > spec/build/bsps/arm/lm3s69xx/optudma.yml | 4 ++-- > spec/build/bsps/arm/lm3s69xx/optxtalcfg.yml | 7 --- > spec/build/bsps/arm/lpc24xx/optcclk.yml | 12 +++ > spec/build/bsps/arm/lpc24xx/optdmachn.yml | 11 -- > spec/build/bsps/arm/lpc24xx/optemcclkdiv.yml | 6 -- > .../bsps/arm/lpc24xx/optemcis42s32800b.yml| 4 ++-- > .../bsps/arm/lpc24xx/optemcis42s32800d7.yml | 3 ++- > .../build/bsps/arm/lpc24xx/optemcm29w160e.yml | 3 ++- > .../bsps/arm/lpc24xx/optemcm29w320e70.yml | 3 ++- > .../bsps/arm/lpc24xx/optemcmt48lc4m16a2.yml | 3 ++- > spec/build/bsps/arm/lpc24xx/optethrmii.yml| 5 - > spec/build/bsps/arm/lpc24xx/optheapext.yml| 3 ++- > spec/build/bsps/arm/lpc24xx/optoscmain.yml| 3 ++- > spec/build/bsps/arm/lpc24xx/optotgi2c.yml | 6 -- > spec/build/bsps/arm/lpc24xx/optpclkdiv.yml| 6 -- > spec/build/bsps/arm/lpc24xx/optstopeth.yml| 3 ++- > spec/build/bsps/arm/lpc24xx/optstopusb.yml| 3 ++- > spec/build/bsps/arm/lpc24xx/optuart1cfg.yml | 5 - > spec/build/bsps/arm/lpc24xx/optuart2cfg.yml | 12 --- > spec/build/bsps/arm/lpc24xx/optuart3cfg.yml | 7 +-- > spec/build/bsps/arm/lpc32xx/optotgi2c.yml | 4 +++- > spec/build/bsps/arm/lpc32xx/optotgvbus.yml| 4 +++- > spec/build/bsps/arm/lpc32xx/optscratchsz.yml | 4 +++- > .../bsps/arm/realview-pbx-a9/optcachedata.yml | 4 +++- > .../bsps/arm/realview-pbx-a9/optcacheinst.yml | 4 +++- > .../arm/realview-pbx-a9/optclkbootcpu.yml | 4 +++- > .../arm/realview-pbx-a9/optclkfastidle.yml| 4 +++- > spec/build/bsps/arm/stm32f4/opteni2c1.yml | 2 +- > spec/build/bsps/arm/stm32f4/optf10xxx.yml | 2 +- > spec/build/bsps/arm/stm32f4/optf4.yml | 2 +- > spec/build/bsps/arm/stm32f4/opthclk.yml | 2 +- > spec/build/bsps/arm/stm32f4/optpclk1.yml | 2 +- > spec/build/bsps/arm/stm32f4/optpclk2.yml | 2 +- > spec/build/bsps/arm/stm32f4/optsysclk.yml | 2 +- > spec/build/bsps/arm/stm32h7/abi.yml | 2 +- > spec/build/bsps/arm/stm32h7/optbootcore.yml | 4 ++-- > spec/build/bsps/arm/stm32h7/optenuart4.yml| 4 ++-- > spec/build/bsps/arm/stm32h7/optenuart5.yml| 6 +++--- > spec/build/bsps/arm/stm32h7/optenuart7.yml| 6 +++--- > spec/build/bsps/arm/stm32h7/optenuart8.yml| 2 +- > spec/build/bsps/arm/stm32h7/optenuart9.yml| 6 +++--- > spec/build/bsps/arm/stm32h7/optenusart10.yml | 6 +++--- > spec/build/bsps/arm/stm32h7/optenusart3.yml | 6 +++--- > spec/build/bsps/arm/stm32h7/optenusart6.yml | 6 +++--- > spec/build/bsps/arm/stm32h7/optlinkcmds.yml | 8 +++ > .../bsps/arm/stm32h7/optmemflashorigin.yml| 2 +- > spec/build/bsps/arm/stm32h7/optmemflashsz.yml | 2 +- > .../build/bsps/arm/stm32h7/optmemsdram1sz.yml | 8 +++ > .../build/bsps/arm/stm32h7/optmemsdram2sz.yml | 4 ++-- > spec/build/bsps/arm/stm32h7/optpwrsupply.yml | 6 +++--- > .../arm/stm32h7/optusart1alternatefunc.yml| 2
[PATCH 2/3] build: Replace variant patterns with a list
Replace the variant patterns in the default-by-variant list with an explicit list of matching BSPs. The change was tested by comparing the output of ./waf bspdefaults before and after the change. --- .../bsps/aarch64/xilinx-zynqmp/optclki2c0.yml | 8 +++ .../bsps/aarch64/xilinx-zynqmp/optclki2c1.yml | 8 +++ .../bsps/aarch64/xilinx-zynqmp/optclkuart.yml | 7 +-- .../bsps/aarch64/xilinx-zynqmp/optloadoff.yml | 2 +- .../bsps/aarch64/xilinx-zynqmp/optramori.yml | 2 +- .../arm/altera-cyclone-v/optclkfastidle.yml | 4 +++- spec/build/bsps/arm/beagle/optam335x.yml | 3 ++- spec/build/bsps/arm/beagle/optdebug.yml | 3 ++- spec/build/bsps/arm/beagle/optdm3730.yml | 3 ++- spec/build/bsps/arm/imx/optcachedata.yml | 4 +++- spec/build/bsps/arm/imx/optcacheinst.yml | 4 +++- spec/build/bsps/arm/lm3s69xx/optgpioahb.yml | 4 ++-- spec/build/bsps/arm/lm3s69xx/optgpionum.yml | 7 --- spec/build/bsps/arm/lm3s69xx/optlm3s3749.yml | 2 +- spec/build/bsps/arm/lm3s69xx/optlm3s6965.yml | 3 ++- spec/build/bsps/arm/lm3s69xx/optlm4f120.yml | 2 +- spec/build/bsps/arm/lm3s69xx/optssiblks.yml | 7 --- spec/build/bsps/arm/lm3s69xx/optsysclk.yml| 6 -- spec/build/bsps/arm/lm3s69xx/optudma.yml | 4 ++-- spec/build/bsps/arm/lm3s69xx/optxtalcfg.yml | 7 --- spec/build/bsps/arm/lpc24xx/optcclk.yml | 12 +++ spec/build/bsps/arm/lpc24xx/optdmachn.yml | 11 -- spec/build/bsps/arm/lpc24xx/optemcclkdiv.yml | 6 -- .../bsps/arm/lpc24xx/optemcis42s32800b.yml| 4 ++-- .../bsps/arm/lpc24xx/optemcis42s32800d7.yml | 3 ++- .../build/bsps/arm/lpc24xx/optemcm29w160e.yml | 3 ++- .../bsps/arm/lpc24xx/optemcm29w320e70.yml | 3 ++- .../bsps/arm/lpc24xx/optemcmt48lc4m16a2.yml | 3 ++- spec/build/bsps/arm/lpc24xx/optethrmii.yml| 5 - spec/build/bsps/arm/lpc24xx/optheapext.yml| 3 ++- spec/build/bsps/arm/lpc24xx/optoscmain.yml| 3 ++- spec/build/bsps/arm/lpc24xx/optotgi2c.yml | 6 -- spec/build/bsps/arm/lpc24xx/optpclkdiv.yml| 6 -- spec/build/bsps/arm/lpc24xx/optstopeth.yml| 3 ++- spec/build/bsps/arm/lpc24xx/optstopusb.yml| 3 ++- spec/build/bsps/arm/lpc24xx/optuart1cfg.yml | 5 - spec/build/bsps/arm/lpc24xx/optuart2cfg.yml | 12 --- spec/build/bsps/arm/lpc24xx/optuart3cfg.yml | 7 +-- spec/build/bsps/arm/lpc32xx/optotgi2c.yml | 4 +++- spec/build/bsps/arm/lpc32xx/optotgvbus.yml| 4 +++- spec/build/bsps/arm/lpc32xx/optscratchsz.yml | 4 +++- .../bsps/arm/realview-pbx-a9/optcachedata.yml | 4 +++- .../bsps/arm/realview-pbx-a9/optcacheinst.yml | 4 +++- .../arm/realview-pbx-a9/optclkbootcpu.yml | 4 +++- .../arm/realview-pbx-a9/optclkfastidle.yml| 4 +++- spec/build/bsps/arm/stm32f4/opteni2c1.yml | 2 +- spec/build/bsps/arm/stm32f4/optf10xxx.yml | 2 +- spec/build/bsps/arm/stm32f4/optf4.yml | 2 +- spec/build/bsps/arm/stm32f4/opthclk.yml | 2 +- spec/build/bsps/arm/stm32f4/optpclk1.yml | 2 +- spec/build/bsps/arm/stm32f4/optpclk2.yml | 2 +- spec/build/bsps/arm/stm32f4/optsysclk.yml | 2 +- spec/build/bsps/arm/stm32h7/abi.yml | 2 +- spec/build/bsps/arm/stm32h7/optbootcore.yml | 4 ++-- spec/build/bsps/arm/stm32h7/optenuart4.yml| 4 ++-- spec/build/bsps/arm/stm32h7/optenuart5.yml| 6 +++--- spec/build/bsps/arm/stm32h7/optenuart7.yml| 6 +++--- spec/build/bsps/arm/stm32h7/optenuart8.yml| 2 +- spec/build/bsps/arm/stm32h7/optenuart9.yml| 6 +++--- spec/build/bsps/arm/stm32h7/optenusart10.yml | 6 +++--- spec/build/bsps/arm/stm32h7/optenusart3.yml | 6 +++--- spec/build/bsps/arm/stm32h7/optenusart6.yml | 6 +++--- spec/build/bsps/arm/stm32h7/optlinkcmds.yml | 8 +++ .../bsps/arm/stm32h7/optmemflashorigin.yml| 2 +- spec/build/bsps/arm/stm32h7/optmemflashsz.yml | 2 +- .../build/bsps/arm/stm32h7/optmemsdram1sz.yml | 8 +++ .../build/bsps/arm/stm32h7/optmemsdram2sz.yml | 4 ++-- spec/build/bsps/arm/stm32h7/optpwrsupply.yml | 6 +++--- .../arm/stm32h7/optusart1alternatefunc.yml| 2 +- .../bsps/arm/stm32h7/optusart1gpiopins.yml| 2 +- .../bsps/arm/stm32h7/optusart1gpioregs.yml| 2 +- .../bsps/arm/xilinx-zynq/opta9periphclk.yml | 4 ++-- .../bsps/arm/xilinx-zynq/optcachedata.yml | 4 +++- .../bsps/arm/xilinx-zynq/optcacheinst.yml | 4 +++- .../bsps/arm/xilinx-zynq/optclkcpu1x.yml | 4 ++-- .../bsps/arm/xilinx-zynq/optclkfastidle.yml | 4 +++- .../build/bsps/arm/xilinx-zynq/optclkuart.yml | 4 ++-- .../bsps/arm/xilinx-zynqmp/optcachedata.yml | 4 +++- .../bsps/arm/xilinx-zynqmp/optcacheinst.yml | 4 +++- .../bsps/arm/xilinx-zynqmp/optclkfastidle.yml | 4 +++- .../bsps/arm/xilinx-zynqmp/optclkuart.yml | 2 +- .../build/bsps/dev/irq/optarmgic-icc-bpr0.yml | 14 - .../bsps/dev/irq/optarmgic-icc-igrpen0.yml| 14 -
