Re: [PATCH v2 1/2] bsps: Import Xilinx support code
On 22.12.22 19:56, Kinsey Moore wrote: +++ b/spec/build/bsps/objxilinxsupport.yml @@ -0,0 +1,45 @@ +SPDX-License-Identifier: CC-BY-SA-5.0 OR BSD-2-Clause +build-type: objects I just noticed that these build items use CC-BY-SA-5.0 and not CC-BY-SA-4.0 like all the other build items. I think this should be consistent. -- 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
[docs 1/3] eng: Add more flags to build group item
--- eng/req/items.rst | 8 1 file changed, 8 insertions(+) diff --git a/eng/req/items.rst b/eng/req/items.rst index e718605..eb7ce38 100644 --- a/eng/req/items.rst +++ b/eng/req/items.rst @@ -2978,6 +2978,8 @@ This type is used by the following types: * :ref:`SpecTypeBuildBSPItemType` +* :ref:`SpecTypeBuildGroupItemType` + * :ref:`SpecTypeBuildLibraryItemType` * :ref:`SpecTypeBuildObjectsItemType` @@ -3004,6 +3006,8 @@ This type is used by the following types: * :ref:`SpecTypeBuildBSPItemType` +* :ref:`SpecTypeBuildGroupItemType` + * :ref:`SpecTypeBuildLibraryItemType` * :ref:`SpecTypeBuildObjectsItemType` @@ -3026,6 +3030,10 @@ context. This type is used by the following types: +* :ref:`SpecTypeBuildAdaTestProgramItemType` + +* :ref:`SpecTypeBuildGroupItemType` + * :ref:`SpecTypeBuildLibraryItemType` * :ref:`SpecTypeBuildObjectsItemType` -- 2.35.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[docs 2/3] eng: Improve build option default values
Merge "default" and "default-by-variant" attributes. Use an enabled-by expression to select the default value. --- eng/req/items.rst | 62 +++ 1 file changed, 25 insertions(+), 37 deletions(-) diff --git a/eng/req/items.rst b/eng/req/items.rst index eb7ce38..c037a93 100644 --- a/eng/req/items.rst +++ b/eng/req/items.rst @@ -714,8 +714,6 @@ option. The following explicit attributes are mandatory: * ``default`` -* ``default-by-variant`` - * ``description`` The explicit attributes for this type are: @@ -729,19 +727,11 @@ actions actions are carried out during the configure command execution. default -The attribute value shall be a :ref:`SpecTypeBuildOptionValue`. It shall be -the default value of the option if no variant-specific default value is -specified. Use ``null`` to specify that no default value exits. The -variant-specific default values may be specified by the -``default-by-variant`` attribute. - -default-by-variant The attribute value shall be a list. Each list element shall be a -:ref:`SpecTypeBuildOptionDefaultByVariant`. The list is checked two times -and processed from top to bottom. Firstly, the base BSP name is used to -match with a variant. Secondly, the BSP family name prefixed by ``bsps/`` -is used to match with a variant. If a matching variant is found, then the -processing stops. +:ref:`SpecTypeBuildOptionDefaultValue`. It shall be the list of default +values of the option. When a default value is needed, the first value on +the list which is enabled according to the enabled set is choosen. If no +value is enabled, then the default value is ``null``. description The attribute value shall be an optional string. It shall be the @@ -766,17 +756,17 @@ Please have a look at the following example: - define: null build-type: option copyrights: -- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de) -default: 115200 -default-by-variant: -- value: 9600 - variants: +- Copyright (C) 2020, 2022 embedded brains GmbH (http://www.embedded-brains.de) +default: +- enabled-by: - bsps/powerpc/motorola_powerpc - m68k/m5484FireEngine - powerpc/hsc_cm01 -- value: 19200 - variants: - - m68k/COBRA5475 + value: 9600 +- enabled-by: m68k/COBRA5475 + value: 19200 +- enabled-by: true + value: 115200 description: | Default baud for console and other serial devices. enabled-by: true @@ -3423,22 +3413,20 @@ This type is used by the following types: * :ref:`SpecTypeBuildOptionAction` -.. _SpecTypeBuildOptionDefaultByVariant: +.. _SpecTypeBuildOptionDefaultValue: -Build Option Default by Variant -^^^ +Build Option Default Value +^^ -This set of attributes specifies build option default values by variant. All -explicit attributes shall be specified. The explicit attributes for this type -are: +This set of attributes specifies a build option default value. All explicit +attributes shall be specified. The explicit attributes for this type are: -value -The attribute value shall be a :ref:`SpecTypeBuildOptionValue`. It value -shall be the default value for the matching variants. +enabled-by +The attribute value shall be an :ref:`SpecTypeEnabledByExpression`. -variants -The attribute value shall be a list of strings. It shall be a list of -Python regular expression matching with the desired variants. +value +The attribute value shall be a :ref:`SpecTypeBuildOptionValue`. Its value +shall be the default value for the associated enabled-by expression. This type is used by the following types: @@ -3495,9 +3483,7 @@ This type is used by the following types: * :ref:`SpecTypeBuildOptionAction` -* :ref:`SpecTypeBuildOptionDefaultByVariant` - -* :ref:`SpecTypeBuildOptionItemType` +* :ref:`SpecTypeBuildOptionDefaultValue` .. _SpecTypeBuildSource: @@ -3681,6 +3667,8 @@ This type is used by the following types: * :ref:`SpecTypeActionRequirementTransition` +* :ref:`SpecTypeBuildOptionDefaultValue` + * :ref:`SpecTypeEnabledByExpression` * :ref:`SpecTypeInterfaceIncludeLinkRole` -- 2.35.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[docs 3/3] eng: Add reason to test program state
--- eng/req/items.rst | 27 +++ 1 file changed, 19 insertions(+), 8 deletions(-) diff --git a/eng/req/items.rst b/eng/req/items.rst index c037a93..95531a8 100644 --- a/eng/req/items.rst +++ b/eng/req/items.rst @@ -3449,14 +3449,25 @@ This type is used by the following types: Build Option Set Test State Action ^^ -This set of attributes specifies test states for a set of test programs. -Generic attributes may be specified. Each generic attribute key shall be a -:ref:`SpecTypeName`. Each generic attribute value shall be a -:ref:`SpecTypeBuildTestState`. The keys shall be test program names. The names -shall correspond to the name of a :ref:`SpecTypeBuildTestProgramItemType` or -:ref:`SpecTypeBuildAdaTestProgramItemType` item. Due to the processing order -of items, there is no way to check if the name specified by the attribute key -is valid. +This set of attributes specifies the test state for a set of test programs with +an optional reason. All explicit attributes shall be specified. The explicit +attributes for this type are: + +reason +The attribute value shall be an optional string. If the value is present, +then it shall be the reason for the test state definition. + +state +The attribute value shall be a :ref:`SpecTypeBuildTestState`. It shall be +the test state for the associated list of tests. + +tests +The attribute value shall be a list of strings. It shall be the list of +test program names associated with the test state. The names shall +correspond to the name of a :ref:`SpecTypeBuildTestProgramItemType` or +:ref:`SpecTypeBuildAdaTestProgramItemType` item. Due to the processing +order of items, there is no way to check if a specified test program name +is valid. This type is used by the following types: -- 2.35.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2 1/2] bsps: Import Xilinx support code
I will update these. Thanks, Kinsey On Tue, Jan 17, 2023 at 2:45 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 22.12.22 19:56, Kinsey Moore wrote: > > +++ b/spec/build/bsps/objxilinxsupport.yml > > @@ -0,0 +1,45 @@ > > +SPDX-License-Identifier: CC-BY-SA-5.0 OR BSD-2-Clause > > +build-type: objects > > I just noticed that these build items use CC-BY-SA-5.0 and not > CC-BY-SA-4.0 like all the other build items. I think this should be > consistent. > > -- > 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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2 1/2] bsps: Import Xilinx support code
On 17.01.23 15:19, Kinsey Moore wrote: I will update these. Or we update the other items. What is the difference between v5.0 and v4.0? Can you update/mix them without issues? If mixed, what is the overall document license? -- 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
[docs] eng: Use a recommendation for requirement texts
Update #3715. --- eng/req/items.rst | 126 +++--- 1 file changed, 63 insertions(+), 63 deletions(-) diff --git a/eng/req/items.rst b/eng/req/items.rst index 95531a8..19e8726 100644 --- a/eng/req/items.rst +++ b/eng/req/items.rst @@ -4597,130 +4597,130 @@ of links. Requirement Text -The value shall be a string. It shall state a requirement or constraint. The -value shall not contain an element of +The value shall be a string. It shall state a requirement or constraint. The +text should not use one of the following words or phrases: -* "``acceptable``", +* acceptable -* "``adequate``", +* adequate -* "``almost always``", +* almost always -* "``and/or``", +* and/or -* "``appropriate``", +* appropriate -* "``approximately``", +* approximately -* "``as far as possible``", +* as far as possible -* "``as much as practicable``", +* as much as practicable -* "``best``", +* best -* "``best possible``", +* best possible -* "``easy``", +* easy -* "``efficient``", +* efficient -* "``e.g.``", +* e.g. -* "``enable``", +* enable -* "``enough``", +* enough -* "``etc.``", +* etc. -* "``few``", +* few -* "``first rate``", +* first rate -* "``flexible``", +* flexible -* "``generally``", +* generally -* "``goal``", +* goal -* "``graceful``", +* graceful -* "``great``", +* great -* "``greatest``", +* greatest -* "``ideally``", +* ideally -* "``i.e.``", +* i.e. -* "``if possible``", +* if possible -* "``in most cases``", +* in most cases -* "``large``", +* large -* "``many``", +* many -* "``maximize``", +* maximize -* "``minimize``", +* minimize -* "``most``", +* most -* "``multiple``", +* multiple -* "``necessary``", +* necessary -* "``numerous``", +* numerous -* "``optimize``", +* optimize -* "``ought to``", +* ought to -* "``probably``", +* probably -* "``quick``", +* quick -* "``rapid``", +* rapid -* "``reasonably``", +* reasonably -* "``relevant``", +* relevant -* "``robust``", +* robust -* "``satisfactory``", +* satisfactory -* "``several``", +* several -* "``shall be included but not limited to``", +* shall be included but not limited to -* "``simple``", +* simple -* "``small``", +* small -* "``some``", +* some -* "``state of the art``", +* state of the art -* "``sufficient``", +* sufficient -* "``suitable``", +* suitable -* "``support``", +* support -* "``systematically``", +* systematically -* "``transparent``", +* transparent -* "``typical``", +* typical -* "``user friendly``", +* user friendly -* "``usually``", +* usually -* "``versatile``", and +* versatile -* "``when necessary``". +* when necessary This type is used by the following types: -- 2.35.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Typo in rtems-libbsd/rtems_waf/rtems.py?
Hi,
It looks like there is a typo in rtems-libbsd/rtems_waf/rtems.py.
rtems_share_rtems_version = os.path.join(rtems_path, 'share', 'rtems' +
rtems_version)
if not os.path.exists(os.path.join(rtems_share_rtems_version)):
ctx.fatal('RTEMS path is not valid, "%s" not found.' %
(rtems_share_rtems_version))
I think that "+ rtems_version" does not belong there?
git clone https://github.com/RTEMS/rtems-libbsd.git
cd rtems-libbsd/
git checkout 6-freebsd-12
git submodule init
git submodule update rtems_waf
./waf configure --prefix=${RTEMS_ROOT} --rtems-bsps=powerpc/beatnik
--buildset=buildset/default.ini
leads to :
# project configured on Tue Jan 17 17:46:09 2023 by
# waf 2.0.19 (abi 20, python 20710f0 on linux2)
# using ./waf configure --prefix=/home/rtems/MVME6100_6_RUN/rtems/6
--rtems-bsps=powerpc/beatnik --buildset=buildset/default.ini
#
Setting top to
/home/rtems/MVME6100_6_INST/rtems-libbsd
Setting out to
/home/rtems/MVME6100_6_INST/rtems-libbsd/build
from /home/rtems/MVME6100_6_INST/rtems-libbsd: RTEMS path is not valid,
"/home/rtems/MVME6100_6_RUN/rtems/6/share/rtems6" not found.
Heinz
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Typo in rtems-libbsd/rtems_waf/rtems.py?
Hello Heinz,
have you installed RTEMS (not only the tools) in `${RTEMS_ROOT}` before
configuring libbsd? If I am not mistaken, installing RTEMS creates the
`share/rtems6` directory.
Greetings
Frank
On 1/17/23 18:11, Heinz Junkes wrote:
Hi,
It looks like there is a typo in rtems-libbsd/rtems_waf/rtems.py.
rtems_share_rtems_version = os.path.join(rtems_path, 'share', 'rtems' +
rtems_version)
if not os.path.exists(os.path.join(rtems_share_rtems_version)):
ctx.fatal('RTEMS path is not valid, "%s" not found.' %
(rtems_share_rtems_version))
I think that "+ rtems_version" does not belong there?
git clonehttps://github.com/RTEMS/rtems-libbsd.git
cd rtems-libbsd/
git checkout 6-freebsd-12
git submodule init
git submodule update rtems_waf
./waf configure --prefix=${RTEMS_ROOT} --rtems-bsps=powerpc/beatnik
--buildset=buildset/default.ini
leads to :
# project configured on Tue Jan 17 17:46:09 2023 by
# waf 2.0.19 (abi 20, python 20710f0 on linux2)
# using ./waf configure --prefix=/home/rtems/MVME6100_6_RUN/rtems/6
--rtems-bsps=powerpc/beatnik --buildset=buildset/default.ini
#
Setting top to
/home/rtems/MVME6100_6_INST/rtems-libbsd
Setting out to
/home/rtems/MVME6100_6_INST/rtems-libbsd/build
from /home/rtems/MVME6100_6_INST/rtems-libbsd: RTEMS path is not valid,
"/home/rtems/MVME6100_6_RUN/rtems/6/share/rtems6" not found.
Heinz
--
embedded brains GmbH
Herr Frank KÜHNDEL
Dornierstr. 4
82178 Puchheim
Germany
email: frank.kuehn...@embedded-brains.de
phone: +49-89-18 94 741 - 23
mobile: +49-176-15 22 06 - 11
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: Typo in rtems-libbsd/rtems_waf/rtems.py?
On 18/1/2023 6:16 am, Frank Kühndel wrote:
> have you installed RTEMS (not only the tools) in `${RTEMS_ROOT}` before
> configuring libbsd? If I am not mistaken, installing RTEMS creates the
> `share/rtems6` directory.
This is correct and it is a simple and fast key to see if a kernel of a specific
version has been installed.
> On 1/17/23 18:11, Heinz Junkes wrote:
>> Hi,
>>
>> It looks like there is a typo in rtems-libbsd/rtems_waf/rtems.py.
>>
>> rtems_share_rtems_version = os.path.join(rtems_path, 'share', 'rtems' +
>> rtems_version)
>> if not os.path.exists(os.path.join(rtems_share_rtems_version)):
>> ctx.fatal('RTEMS path is not valid, "%s" not found.' %
>> (rtems_share_rtems_version))
>>
>> I think that "+ rtems_version" does not belong there?
>>
>> git clonehttps://github.com/RTEMS/rtems-libbsd.git
>> cd rtems-libbsd/
>> git checkout 6-freebsd-12
>> git submodule init
>> git submodule update rtems_waf
>>
>> ./waf configure --prefix=${RTEMS_ROOT} --rtems-bsps=powerpc/beatnik
>> --buildset=buildset/default.ini
As Frank points put the kernel needs to be installed before this command is run.
Chris
>>
>> leads to :
>>
>> # project configured on Tue Jan 17 17:46:09 2023 by
>> # waf 2.0.19 (abi 20, python 20710f0 on linux2)
>> # using ./waf configure --prefix=/home/rtems/MVME6100_6_RUN/rtems/6
>> --rtems-bsps=powerpc/beatnik --buildset=buildset/default.ini
>> #
>>
>> Setting top to
>> /home/rtems/MVME6100_6_INST/rtems-libbsd
>>
>> Setting out to
>> /home/rtems/MVME6100_6_INST/rtems-libbsd/build
>> from /home/rtems/MVME6100_6_INST/rtems-libbsd: RTEMS path is not valid,
>> "/home/rtems/MVME6100_6_RUN/rtems/6/share/rtems6" not found.
>>
>>
>> Heinz
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Typo in rtems-libbsd/rtems_waf/rtems.py?
Sorry, I just saw my install script threw an error:
rtems@rtems-dev:~/MVME6100_6_INST/kernel$ ./waf bsp_defaults
--rtems-bsps=powerpc/beatnik > config.ini
No function 'bsp_defaults' defined in /home/rtems/MVME6100_6_INST/kernel/wscript
Heinz
> On 17. Jan 2023, at 21:08, Chris Johns wrote:
>
> On 18/1/2023 6:16 am, Frank Kühndel wrote:
>> have you installed RTEMS (not only the tools) in `${RTEMS_ROOT}` before
>> configuring libbsd? If I am not mistaken, installing RTEMS creates the
>> `share/rtems6` directory.
>
> This is correct and it is a simple and fast key to see if a kernel of a
> specific
> version has been installed.
>
>> On 1/17/23 18:11, Heinz Junkes wrote:
>>> Hi,
>>>
>>> It looks like there is a typo in rtems-libbsd/rtems_waf/rtems.py.
>>>
>>> rtems_share_rtems_version = os.path.join(rtems_path, 'share', 'rtems' +
>>> rtems_version)
>>> if not os.path.exists(os.path.join(rtems_share_rtems_version)):
>>> ctx.fatal('RTEMS path is not valid, "%s" not found.' %
>>> (rtems_share_rtems_version))
>>>
>>> I think that "+ rtems_version" does not belong there?
>>>
>>> git clonehttps://github.com/RTEMS/rtems-libbsd.git
>>> cd rtems-libbsd/
>>> git checkout 6-freebsd-12
>>> git submodule init
>>> git submodule update rtems_waf
>>>
>>> ./waf configure --prefix=${RTEMS_ROOT} --rtems-bsps=powerpc/beatnik
>>> --buildset=buildset/default.ini
>
> As Frank points put the kernel needs to be installed before this command is
> run.
>
> Chris
>
>>>
>>> leads to :
>>>
>>> # project configured on Tue Jan 17 17:46:09 2023 by
>>> # waf 2.0.19 (abi 20, python 20710f0 on linux2)
>>> # using ./waf configure --prefix=/home/rtems/MVME6100_6_RUN/rtems/6
>>> --rtems-bsps=powerpc/beatnik --buildset=buildset/default.ini
>>> #
>>>
>>> Setting top to
>>> /home/rtems/MVME6100_6_INST/rtems-libbsd
>>>
>>> Setting out to
>>> /home/rtems/MVME6100_6_INST/rtems-libbsd/build
>>> from /home/rtems/MVME6100_6_INST/rtems-libbsd: RTEMS path is not valid,
>>> "/home/rtems/MVME6100_6_RUN/rtems/6/share/rtems6" not found.
>>>
>>>
>>> Heinz
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Typo in rtems-libbsd/rtems_waf/rtems.py?
ok with
./waf bspdefaults --rtems-bsps=powerpc/beatnik … it works
I had ./waf bsp_defaults :-(
rtems@rtems-dev:~/MVME6100_6_RUN/rtems/6/share$ ls -l
total 36
drwxr-xr-x 3 rtems rtems 4096 Jan 17 17:09 doc
drwxr-xr-x 3 rtems rtems 4096 Jan 17 17:42 gcc-12.2.1
drwxr-xr-x 5 rtems rtems 4096 Jan 17 17:44 gdb
drwxr-xr-x 2 rtems rtems 4096 Jan 17 17:44 iconv_data
drwxr-xr-x 2 rtems rtems 4096 Jan 17 17:44 info
drwxr-xr-x 2 rtems rtems 4096 Jan 17 17:13 locale
drwxr-xr-x 5 rtems rtems 4096 Jan 17 17:42 man
drwxr-xr-x 9 rtems rtems 4096 Jan 17 17:44 rtems
drwxr-xr-x 3 rtems rtems 4096 Jan 17 21:15 rtems6
Danke, Heinz
> On 17. Jan 2023, at 21:08, Chris Johns wrote:
>
> On 18/1/2023 6:16 am, Frank Kühndel wrote:
>> have you installed RTEMS (not only the tools) in `${RTEMS_ROOT}` before
>> configuring libbsd? If I am not mistaken, installing RTEMS creates the
>> `share/rtems6` directory.
>
> This is correct and it is a simple and fast key to see if a kernel of a
> specific
> version has been installed.
>
>> On 1/17/23 18:11, Heinz Junkes wrote:
>>> Hi,
>>>
>>> It looks like there is a typo in rtems-libbsd/rtems_waf/rtems.py.
>>>
>>> rtems_share_rtems_version = os.path.join(rtems_path, 'share', 'rtems' +
>>> rtems_version)
>>> if not os.path.exists(os.path.join(rtems_share_rtems_version)):
>>> ctx.fatal('RTEMS path is not valid, "%s" not found.' %
>>> (rtems_share_rtems_version))
>>>
>>> I think that "+ rtems_version" does not belong there?
>>>
>>> git clonehttps://github.com/RTEMS/rtems-libbsd.git
>>> cd rtems-libbsd/
>>> git checkout 6-freebsd-12
>>> git submodule init
>>> git submodule update rtems_waf
>>>
>>> ./waf configure --prefix=${RTEMS_ROOT} --rtems-bsps=powerpc/beatnik
>>> --buildset=buildset/default.ini
>
> As Frank points put the kernel needs to be installed before this command is
> run.
>
> Chris
>
>>>
>>> leads to :
>>>
>>> # project configured on Tue Jan 17 17:46:09 2023 by
>>> # waf 2.0.19 (abi 20, python 20710f0 on linux2)
>>> # using ./waf configure --prefix=/home/rtems/MVME6100_6_RUN/rtems/6
>>> --rtems-bsps=powerpc/beatnik --buildset=buildset/default.ini
>>> #
>>>
>>> Setting top to
>>> /home/rtems/MVME6100_6_INST/rtems-libbsd
>>>
>>> Setting out to
>>> /home/rtems/MVME6100_6_INST/rtems-libbsd/build
>>> from /home/rtems/MVME6100_6_INST/rtems-libbsd: RTEMS path is not valid,
>>> "/home/rtems/MVME6100_6_RUN/rtems/6/share/rtems6" not found.
>>>
>>>
>>> Heinz
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Typo in rtems-libbsd/rtems_waf/rtems.py?
On 18/1/2023 7:17 am, Heinz Junkes wrote: > ok with > ./waf bspdefaults --rtems-bsps=powerpc/beatnik … it works > > I had ./waf bsp_defaults :-( Ah > rtems@rtems-dev:~/MVME6100_6_RUN/rtems/6/share$ ls -l > total 36 > drwxr-xr-x 3 rtems rtems 4096 Jan 17 17:09 doc > drwxr-xr-x 3 rtems rtems 4096 Jan 17 17:42 gcc-12.2.1 > drwxr-xr-x 5 rtems rtems 4096 Jan 17 17:44 gdb > drwxr-xr-x 2 rtems rtems 4096 Jan 17 17:44 iconv_data > drwxr-xr-x 2 rtems rtems 4096 Jan 17 17:44 info > drwxr-xr-x 2 rtems rtems 4096 Jan 17 17:13 locale > drwxr-xr-x 5 rtems rtems 4096 Jan 17 17:42 man > drwxr-xr-x 9 rtems rtems 4096 Jan 17 17:44 rtems > drwxr-xr-x 3 rtems rtems 4096 Jan 17 21:15 rtems6 > Nice and thanks for letting us know. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 1/3] build: Format build items
On 17/1/2023 6:39 pm, Sebastian Huber wrote: > On 17.01.23 03:48, Chris Johns wrote: >> On 16/1/2023 6:56 pm, Sebastian Huber wrote: >>> On 16.01.23 01:35, Chris Johns wrote: On 13/1/2023 1:54 am, Sebastian Huber wrote: > On 12.01.23 15:44, Kinsey Moore wrote: >> The other two patches look fine to me. The use of dump() that results in >> this >> patch does several things: >> * Removal of whitespace >> This is fine for whitespace at the base level of indentation. Whitespace >> within an indented block may be more important for readability. >> >> * Removal of comments >> This is not good as they are exclusively used to annotate manually >> ordered >> blocks of test result expectations >> >> * Rearrangement of items in alphabetical order >> In general, rearrangement of top-level sections is good. For indented >> sections >> specifically in tst*.yml, this is bad for the above reaso > One goal of the new build system was to be able to alter the data through > scripts. This requires that the build items are human and machine > readable and > writable. The Python YAML import/export does not preserve white space and > comments. Can someone edit the file and add a hex number? >>> >>> Yes, you can manually use whatever format is understood by the YAML loader. >>> When >>> you write the file with the YAML dumper, then the standard representation is >>> used. >> >> Are there python modules in rtems.git someone could import that reads and >> writes >> the YAML spec files? If not should we provide a module to do this? It could >> be >> `spec` so a user can use `import spec` after setting the import path. >> >> That is, if external scripts (and I encourage this) all used a common read >> and >> write type functionality the format consistency is relative to specific >> version >> of rtems.git being used. Updates become read then write. > > The Python modules to work with specification items are in rtems-central.git. > This repository contains also a format specification of the build items. And how does that help here with this repo? I suggest you reconsider the accessibility of those modules before pushing scripted generation changes like this into rtems.git. > We > could add an action to a Github work flow to check the build item format for > pull requests and commits. Thanks for including github in this thread. It has now confirmed my position of no github automations in our repos (including rtems-central). >>> I changed the representer to use the format attribute, see v2 of the patch: >>> >>> https://lists.rtems.org/pipermail/devel/2023-January/074094.html >>> >> >> I see and thanks. How many format strings would cover the majority of >> formats we >> have? >> >> I am wondering if `format:` is checked against a standard list and those are >> part of the "writer" support? For example `address`, `address32`, `hex64` >> etc? I >> am concerned about repeated common format strings being placed through all >> the >> spec files. > > The format string is a standard Python format string. This is easy to > implement > and flexible. We could replace this with a fixed set of formats. Maybe if you have scripting support which this repo does not. I think the formats should be controlled however I see the whole discussion and patch as academic until rtems.git has scripting support in python modules. 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
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 +-
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 +- spec/build/bsps/arm/
Re: Typo in rtems-libbsd/rtems_waf/rtems.py?
On 17.01.23 21:13, Heinz Junkes wrote: rtems@rtems-dev:~/MVME6100_6_INST/kernel$ ./waf bsp_defaults --rtems-bsps=powerpc/beatnik > config.ini If you just want to build a BSP with default values, you should simply use: [powerpc/beatnik] -- 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
