Re: utf32 support

[Frank Kühndel]

Hello John,

On 3/19/24 16:53, John Howard wrote:

P.S.: UTF32 exists for Unicode in 2012 after consolidation from ISO 10646-2012. 
The two standards merged.


Oops. I am apparently outdated ...
Frank

--
embedded brains GmbH & Co. KG
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

Registergericht: Amtsgericht München
Registernummer: HRA 117265
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 v2] user: Add docu for use of Rust with RTEMS

[Frank Kühndel]

Hi Chris,

On 3/19/24 03:24, Chris Johns wrote:

On 16/3/2024 1:14 am, Frank Kühndel wrote:

Ping!

The last discussion of this patch was
https://lists.rtems.org/pipermail/devel/2024-February/077289.html

Does the fact that I recive no further comments to this patch mean it can be
pushed to the RTEMS User Manual as it is?

Sorry Frank, I have been busy with other changes. It is on my list but I have
will need to reread the thread when I have time.


No problem. This can wait.

Greetings,
Frank

--
embedded brains GmbH & Co. KG
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

Registergericht: Amtsgericht München
Registernummer: HRA 117265
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: utf32 support

[Frank Kühndel]

Hello John,

just a side node:

Strictly speaking UTF32 does not exist [1]. The correct name is UCS-4 
(i.e store each character in four bytes). "Current plans are that there 
will never be characters assigned outside the 21-bit code space from 
0x00 to 0x10" [2].


References:

[1] Section "Unicode encodings" in 
https://tldp.org/HOWTO/Unicode-HOWTO-1.html#ss1.2


[2] Section "What are UCS and ISO 10646?" in 
https://www.cl.cam.ac.uk/~mgk25/unicode.html


Greetings,
fk

On 3/18/24 19:02, Gedare Bloom wrote:

I think it would be wchar_t support in newlib.

On Mon, Mar 18, 2024 at 11:56 AM Joel Sherrill  wrote:

What does support for UTF-32 entail? Do you have an idea what software 
functions you are looking for?

I see the International Components for Unicode (ICU) has a converter 
(https://icu.unicode.org/download) which looks it might be part of a solution.

Multibyte character methods defined by POSIX would be in newlib.

I'm not well versed in this area so have questions but I think it basically 
comes down to what software libraries an application needs and porting those to 
RTEMS -- assuming the license is ok.

--joel

On Mon, Mar 18, 2024 at 12:15 PM John Howard  wrote:

I want to add utf32 support.

Where do I start?

— John
___
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

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel



--
embedded brains GmbH & Co. KG
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

Registergericht: Amtsgericht München
Registernummer: HRA 117265
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 v2] user: Add docu for use of Rust with RTEMS

[Frank Kühndel]

Ping!

The last discussion of this patch was
   https://lists.rtems.org/pipermail/devel/2024-February/077289.html

Does the fact that I recive no further comments to this patch mean it 
can be pushed to the RTEMS User Manual as it is?


Greetings
Frank

On 2/23/24 17:29, Frank Kuehndel wrote:

From: Frank Kühndel

---
  user/index.rst   |   3 +-
  user/overview/index.rst  |   2 +
  user/rust/bare-metal.rst | 548 +++
  user/rust/index.rst  |  64 +
  4 files changed, 616 insertions(+), 1 deletion(-)
  create mode 100644 user/rust/bare-metal.rst
  create mode 100644 user/rust/index.rst

diff --git a/user/index.rst b/user/index.rst
index 5b7f3ce..0cc6b2c 100644
--- a/user/index.rst
+++ b/user/index.rst
@@ -18,7 +18,7 @@ RTEMS User Manual (|version|).
  ||copy|  2018 Shashvat Jain
  ||copy|  2018 Vidushi Vashishth
  ||copy|  2017 Tanu Hari Dixit
-||copy|  2016, 2019 embedded brains GmbH & Co. KG
+||copy|  2016, 2024 embedded brains GmbH & Co. KG
  ||copy|  2016, 2019 Sebastian Huber
  ||copy|  2012, 2022 Chris Johns
  ||copy|  2012, 2020 Gedare Bloom
@@ -51,5 +51,6 @@ RTEMS User Manual (|version|).
  
  tools/index

  rsb/index
+rust/index
  
  glossary/index

diff --git a/user/overview/index.rst b/user/overview/index.rst
index 16389d9..cc292e1 100644
--- a/user/overview/index.rst
+++ b/user/overview/index.rst
@@ -66,6 +66,8 @@ RTEMS provides the following basic feature set:
  
  - Python and MicroPython
  
+- :ref:`Rust `

+
  - Parallel languages
  
  - :ref:term:`EMB²`

diff --git a/user/rust/bare-metal.rst b/user/rust/bare-metal.rst
new file mode 100644
index 000..b1c3980
--- /dev/null
+++ b/user/rust/bare-metal.rst
@@ -0,0 +1,548 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 2024 embedded brains GmbH & Co. KG
+
+.. _RustBareMetal:
+
+Bare Metal Rust with RTEMS
+==
+
+To develop with Rust and RTEMS together, you must find a Rust bare metal
+target which matches an RTEMS BSP. The instructions in this section
+are for a SPARC and a Risc-V*hello world*  program. These examples use
+the combinations shown in the table below:
+
+++--++--+
+| RTEMS Architecture | RTEMS BSP| Rust Target| Rust 
CPU |
+++==++==+
+| rtems-sparc| sparc/leon3  | sparc-unknown-none-elf | leon3   
 |
+++--++--+
+| rtems-riscv| riscv/rv64imafdc | riscv64gc-unknown-none-elf | 
generic-rv64 |
+++--++--+
+
+The following sources may be helpful to find a matching BSP and target:
+
+- ``./waf bsplist`` -- executed in an RTEMS git clone
+- ``source-builder/sb-set-builder --list-bsets`` -- executed in an
+  RTEMS source builder git clone
+- `RTEMS Supported 
Architectures<https://devel.rtems.org/wiki/TBR/UserManual/SupportedCPUs>`_
+- `RTEMS Board Support 
Packages<https://devel.rtems.org/wiki/TBR/Website/Board_Support_Packages>`_
+- ``rustc --print target-list``
+- ``rustc --target=riscv64gc-unknown-none-elf --print target-features``
+- ``rustc --target=riscv64gc-unknown-none-elf  --print target-cpus``
+- `Rust Platform 
Support<https://doc.rust-lang.org/nightly/rustc/platform-support.html>`_
+
+The sample instructions which follow build two executables using the
+same source code for the RTEMS configuration ``init.c`` and the Rust
+hello-world application ``lib.rs``. Only the configuration as well as
+the compile and link commands differ for SPARC Leon3 and RISC-V
+64 bit. The Rust application uses ``printk()`` from RTEMS to print
+text to the console.
+
+After building the RTEMS BSP and installing Rust, the basic steps are:
+
+1. Compile the RTEMS configuration in ``init.c`` into an object
+   file using the GNU C compiler from the RTEMS tool chain.
+2. Compile the Rust code containing ``main()`` into a
+   static library using the Rust compiler.
+3. Link the static library with the Rust code,
+   the RTEMS configuration and the RTEMS OS libraries
+   together into one single executable.
+4. Finally run the executable on a simulator.
+
+You can build the examples in a container. This is optional. If you
+prefer to follow these instructions directly on your machine simply
+skip the section*Build a Container*. Just make sure that you machine
+meets all prerequisites to build the RTEMS tools and install the Rust
+tools.
+
+.. _RustBareMetal_Container:
+
+Build a Container
+-
+
+The container must be able to execute the RTEMS source builder and to
+install and run the Rust tools. In an empty directory of your choice
+create the following ``Dockerfile``.
+
+.. code-block:: shell

Re: [PATCH 4/6] build: Add support to make bootloader images

[Frank Kühndel]

 -197,6 +197,15 @@ def make_tar_info_reproducible(info):
  return info
  
  
+def make_image(bld, target):

+if not target.endswith(".norun.exe"):
+if bld.env.BUILD_TOOL_MKIMAGE:
+image = os.path.splitext(target)[0] + bld.env.BOOT_IMAGE_EXTENSION
+bld(rule="${BUILD_TOOL_MKIMAGE} ${SRC} ${TGT}",
+source=target,
+target=image)
+
+
  class Item(object):
  
  def __init__(self, uid, data):

@@ -590,6 +599,30 @@ class ConfigFileItem(Item):
  self.install_target(bld)
  
  
+class MakeImageItem(Item):

+
+def __init__(self, uid, data):
+super(MakeImageItem, self).__init__(uid, data)
+
+def do_configure(self, conf, cic):
+content = self.substitute(conf, self.data["content"])
+f = conf.bldnode.make_node(conf.env.VARIANT + "/bin/mkimage.py")
+f.parent.mkdir()
+f.write(content)
+# 493 == 0755
+f.chmod(493)


In Python2 and Python3: 0o755

Greetings,
fk


+file_path = f.abspath()
+conf.env.BUILD_TOOL_MKIMAGE = file_path
+conf.env.append_value("cfg_files", file_path)
+conf.env.append_value("ENABLE", "HAVE_MKIMAGE")
+
+def do_build(self, bld, bic):
+bld.install_as("${PREFIX}/bin/rtems-mkimage-" + bld.env.ARCH + "-" +
+   bld.env.BSP_NAME + ".py",
+   "bin/mkimage.py",
+   chmod=493)
+
+
  class ConfigHeaderItem(Item):
  
  def __init__(self, uid, data):

@@ -745,6 +778,7 @@ class TestProgramItem(Item):
  )
  
  def do_build(self, bld, bic):

+target = self.get(bld, "target")
  bld(
  cflags=bic.cflags,
  cppflags=bic.cppflags,
@@ -756,9 +790,10 @@ class TestProgramItem(Item):
  source=self.data["source"],
  start_files=True,
  stlib=self.data["stlib"],
-target=self.get(bld, "target"),
+target=target,
  use=bic.objects + bic.use,
  )
+make_image(bld, target)
  
  
  class AdaTestProgramItem(TestProgramItem):

@@ -770,14 +805,16 @@ class AdaTestProgramItem(TestProgramItem):
  objs = []
  for s in self.data["source"]:
  objs.append(self.cc(bld, bic, s))
+target = self.get(bld, "target")
  self.gnatmake(
  bld,
  bic,
  self.data["ada-object-directory"],
  objs,
  self.data["ada-main"],
-self.data["target"],
+target,
  )
+make_image(bld, target)
  
  
  class OptionItem(Item):

@@ -1161,6 +1198,9 @@ class ScriptItem(Item):
  script = self.data["do-build"]
  if script:
  exec(script)
+target = self.data.get("target", None)
+if target is not None:
+make_image(bld, self.substitute(bld, target))
  
  
  class ConfigItemContext(object):

@@ -1284,6 +1324,7 @@ def load_items(ctx, specs):
  "test-program": TestProgramItem,
  "group": GroupItem,
  "library": LibraryItem,
+"mkimage": MakeImageItem,
      "objects": ObjectsItem,
  "option": OptionItem,
  "script": ScriptItem,
-- 2.35.3 ___ devel mailing 
list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel




--
embedded brains GmbH & Co. KG
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

Registergericht: Amtsgericht München
Registernummer: HRA 117265
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 rtems-docs 1/1] user: Add docu for use of Rust with RTEMS

[Frank Kühndel]

Hi Chris,

thanks for reviewing this patch.

On 2/21/24 03:42, Chris Johns wrote:

Hi Frank

Thanks for this, it ia awesome.

On 17/2/2024 7:52 am, Frank Kuehndel wrote:

From: Frank Kühndel

---
  user/index.rst   |   3 +-
  user/overview/index.rst  |   2 +
  user/rust/bare-metal.rst | 549 +++
  user/rust/index.rst  |  64 +

Do you see Rust growing to size it needs a directory?


No. There will hopefully be an additional section on using Rust with 
libstd (in contrast to bare metal). Besides of that, I do not see any 
extension in the "not to far" future.


Just tell me where to put the files. I can also join all text in one 
file if desired.



  4 files changed, 617 insertions(+), 1 deletion(-)
  create mode 100644 user/rust/bare-metal.rst
  create mode 100644 user/rust/index.rst

diff --git a/user/index.rst b/user/index.rst
index 5b7f3ce..0cc6b2c 100644
--- a/user/index.rst
+++ b/user/index.rst
@@ -18,7 +18,7 @@ RTEMS User Manual (|version|).
  ||copy|  2018 Shashvat Jain
  ||copy|  2018 Vidushi Vashishth
  ||copy|  2017 Tanu Hari Dixit
-||copy|  2016, 2019 embedded brains GmbH & Co. KG
+||copy|  2016, 2024 embedded brains GmbH & Co. KG
  ||copy|  2016, 2019 Sebastian Huber
  ||copy|  2012, 2022 Chris Johns
  ||copy|  2012, 2020 Gedare Bloom
@@ -51,5 +51,6 @@ RTEMS User Manual (|version|).
  
  tools/index

  rsb/index
+rust/index
  
  glossary/index

diff --git a/user/overview/index.rst b/user/overview/index.rst
index 16389d9..cc292e1 100644
--- a/user/overview/index.rst
+++ b/user/overview/index.rst
@@ -66,6 +66,8 @@ RTEMS provides the following basic feature set:
  
  - Python and MicroPython
  
+- :ref:`Rust `

+
  - Parallel languages
  
  - :ref:term:`EMB²`

diff --git a/user/rust/bare-metal.rst b/user/rust/bare-metal.rst
new file mode 100644
index 000..b893f57
--- /dev/null
+++ b/user/rust/bare-metal.rst
@@ -0,0 +1,549 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 2024 embedded brains GmbH & Co. KG
+
+.. _RustBareMetal:
+
+Bare Metal Rust with RTEMS
+==
+
+To develop with Rust and RTEMS together, you must find a Rust bare metal
+target which matches an RTEMS BSP.

What does a user look for in a BSP to meet this requirement?


The hardware must match. If you are sitting in front of board X with 
processor Y you must compile RTEMS for that board/processor and you must 
compile the Rust application for that board/processor.


I do not know any algorithm to find matches automatically if that was 
your question. It would be nice to generate a table with all possible 
matching combinations. One would need to read out all RTEMS BSP 
descriptions and all Rust targets and CPU features and say "yes, these 
two are for the same hardware".



The instructions in this section
+are for a SPARC and a Risc-V*hello world*  program. These examples use
+the combinations shown in the table below:
+
+++--++--+
+| RTEMS Architecture | RTEMS BSP| Rust Target| Rust 
CPU |
+++==++==+
+| rtems-sparc| sparc/leon3  | sparc-unknown-none-elf | leon3   
 |
+++--++--+
+| rtems-riscv| riscv/rv64imafdc | riscv64gc-unknown-none-elf | 
generic-rv64 |
+++--++--+
+
+The following sources may be helpful to find a matching BSP and target:
+
+- ``./waf bsplist`` -- executed in an RTEMS git clone
+- ``source-builder/sb-set-builder --list-bsets`` -- executed in an
+  RTEMS source builder git clone
+- `RTEMS Supported 
Architectures<https://devel.rtems.org/wiki/TBR/UserManual/SupportedCPUs>`_
+- `RTEMS Board Support 
Packages<https://devel.rtems.org/wiki/TBR/Website/Board_Support_Packages>`_
+- ``rustc --print target-list``
+- ``rustc --target=riscv64gc-unknown-none-elf --print target-features``
+- ``rustc --target=riscv64gc-unknown-none-elf  --print target-cpus``
+- `Rust Platform 
Support<https://doc.rust-lang.org/nightly/rustc/platform-support.html>`_
+
+The sample instructions which follow build two executables using the
+same source code for the RTEMS configuration ``init.c`` and the Rust
+hello-world application ``lib.rs``. Only the configuration as well as
+the compile and link commands differ for SPARC Leon3 and RISC-V
+64 bit. The Rust application uses ``printk()`` from RTEMS to print
+text to the console.
+
+After building the RTEMS BSP and installing Rust, the basic steps are:
+
+(1) Compile the RTEMS configuration in ``init.c`` into an object
+file using the GNU C compiler from the RTEMS tool chain.
+(2) Compile the Rust code containing ``main()`` into a
+   

Re: Naming convention for Rust target platforms

[Frank Kühndel]

Hello Jan,

On 1/29/24 19:41, jan.som...@dlr.de wrote:

Hi everyone,

As mentioned in the other Rust thread, I am working on an initial Rust port for 
RTEMS.
The target platform for testing is the ARM Xilinx Zynq-7000 based BSPs.
Where I am not completely sure, is how to name the new target for Rust (see 
here the current 
list:https://doc.rust-lang.org/nightly/rustc/platform-support.html#tier-3).
The Rust ARM targets usually have the instruction set version and ABI as part 
of the name, e.g. armv7a-none-eabihf.
In RTEMS the arm-rtems6-gcc covers all supported ARM versions and different 
ABIs (i.e. hard-float or soft-float) collectively.

So, for the Zynq and similar BSPs this would yield for the Rust target 
something like: armv7a-rtems6-eabihf (and possibly armv7a-rtems6-eabi).
Similarly, for other ARM BSPs additional Rust targets would need to be added. 
Which might add up to quite a  number of Rust targets over time.
Is this fine or do you see another solution?

Just to make sure I understand your question correct:
You want to push the RTEMS support you have developed (changes to Rust 
libraries, test framework, ability to have a main() in the Rust code for 
RTEMS etc.) to the official Rust repository - so that it is available to 
everyone through the Rust nightly builds?


If this is so, then your question would be primarily a question to the 
Rust folks because it is their repository which would possibly receive 
many different entries for (similar?) RTEMS BSPs?


As far as I understand this, the steps for an RTEMS developer would be:

1) Build the right RTEMS tools with the Source Builder. Here: ARM tools.
2) Build RTEMS (kernel) for the right (RTEMS) BSP
3) Install the Rust compiler and its tools
4) Create a Rust project
5) Fine tune some Rust configuration files in that project.
   Here the "armv7a-rtems6-eabihf" or something fitting the BSP would
   be used in a config file. The point is, it must be for the processor
   and BSP which matches the RTEMS tools and BSP selected in steps 1)
   and 2)
6) Make changes to the sample Rust code generated in the project
   or write the Rust code desired.
7) Load the nightly build of the Rust compiler.
   (The nightly is only needed as long as your code has not entered the
   stable build).
8) Compile the Rust program code with the Rust nightly compiler.
9) Link the Rust binary with the RTEMS libraries into a single
   executable (using a linker build by the RTEMS tools).

Which name Rust accepts instead of "armv7a-rtems6-eabihf" depends on the 
naming convention of the Rust community:

https://docs.rust-embedded.org/embedonomicon/custom-target.html
According to this file, the part `eabi` is for bare metal. Would this be 
correct when it is based on RTEMS? For example, a Linux target would be 
"x86_64-unknown-linux-gnu" where `gnu` means started by 'glibc'.


By the way, section "Adding a new target" of
   https://doc.rust-lang.org/nightly/rustc/target-tier-policy.html
points to an example:
   https://github.com/rust-lang/rust/pull/94872
and that person discussed that triple name here:

https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/LLVM.2Bmingw-w64.20Windows.20targets

Greetings,
Frank


Cheers,


 Jan

Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR)
German Aerospace Center
Institute for Software Technology | Software for Space Systems and Interactive 
Visualization | Lilienthalplatz 7 | 38108 Braunschweig | Germany

Jan Sommer
Telephone +49 531 295-2494 | Telefax 0531 295-2767 |jan.som...@dlr.de
DLR.de/SC

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel



--
embedded brains GmbH & Co. KG
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

Registergericht: Amtsgericht München
Registernummer: HRA 117265
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: CentOS 8 - no python

[Frank Kühndel]

Hi Joel,

have a great 2024!

On 12/24/23 22:16, Joel Sherrill wrote:
> Hi
>
> Trying to bring up Coverity builds on a Centos 8 machine, I ran into 
this:

>
> + ../source-builder/sb-set-builder --log=l-sparc.txt
> --prefix=/home/joel/rtems-cron-coverity/tools/6 --mail --mail-to=
> bu...@rtems.org  --mail-from=j...@rtems.org 6/rtems-sparc
>
> /usr/bin/env: ‘python’: No such file or directory
>
> There is, in fact, no python executable -- there is python2 and python3.
>
> Suggestions other than adding a symlink?

In RHEL 9.3 there exists the package python-unversioned-command which 
creates a "python" command for "python3". I do not know whether it 
exists in CentOS 8.


Greetings,
Frank

--
embedded brains GmbH & Co. KG
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

Registergericht: Amtsgericht München
Registernummer: HRA 117265
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] Avoid StopIteration exception for non-rtems .pc

[Frank Kühndel]

Hello Martin,

thanks for the fix. Your patch works for me. I tried with

$ ./waf configure --rtems=/opt/rtems/6 
--rtems-bsp=arm/xilinx_zynq_a9_qemu


$ ./waf

$ env QEMU_AUDIO_DRV="none" qemu-system-arm -no-reboot -net none -m 
256M -serial null -serial mon:stdio -nographic -M xilinx-zynq-a9 -kernel 
build/arm-rtems6-xilinx_zynq_a9_qemu/hello.exe


The hello world executable I used runs fine.

Many thanks again,
fk

On 10/5/23 15:40, Martin Erik Werner wrote:

Subject:
[PATCH] Avoid StopIteration exception for non-rtems .pc
From:
Martin Erik Werner 
Date:
10/5/23, 15:40

To:
devel@rtems.org
CC:
chr...@rtems.org, sidd...@bnl.gov, frank.kuehn...@embedded-brains.de


_arch_from_arch_bsp() and _bsp_from_arch_bsp() has overly optimistic
assumptions that the argument must contain a '-'-separated field which
starts with "rtems". These functions are intended to find the target
triplet or the bsp parts of strings like "sparc-gaisler-rtems5-leon3"
and "arm-rtems6-xilinx_zynq_zc702"

But _find_installed_arch_bsps() may call _arch_from_arch_bsp() with the
name (without file extension) of any file which ends with ".pc",
including for example "expat". This triggers a StopIteration exception
when trying to find the next field after the "rtems" field, since no
"rtems" field exists to start with.

Rework these function to remove the preconditions, so that they return
None if no "rtems" field exist or if no field exists before or after the
"rtems" field.

It could be argued. based on their name, that calling these functions
with something that is not a triplet-bsp string is incorrect to start
with, but attempting to address that is not done here.
---

This should fix the issue discovered by David Siddons and Frank Kühndel
described in the "build failed" thread from 2023-07-23 in the
rtems-users mailing list with message-id:
<8e6c2841-ae9e-aacf-de84-e6340d204...@embedded-brains.de>

I have tested this fix when compiling the simple quickstart application
for the sparc-gaisler-rtems5-leon3 and arm-rtems6-xilinx_zynq_zc702
targets, but I have not verified execution of the build results, this is
probably the amount of testing that I will be able to perform at the
moment.

  rtems.py | 14 --
  1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/rtems.py b/rtems.py
index c65a7d2..a29d281 100644
--- a/rtems.py
+++ b/rtems.py
@@ -859,15 +859,17 @@ def _check_arch_bsps(req, config, path, archs, version):
  
  def _arch_from_arch_bsp(arch_bsp):

  fields = arch_bsp.split('-')
-rtems_field_index = next(i for i, field in enumerate(fields) if 
field.startswith('rtems'))
-return '-'.join(fields[:(rtems_field_index + 1)])
-
+for i, field in enumerate(fields):
+if field.startswith('rtems') and fields[:(i + 1)] is not None:
+return '-'.join(fields[:(i + 1)])
+return None
  
  def _bsp_from_arch_bsp(arch_bsp):

  fields = arch_bsp.split('-')
-rtems_field_index = next(i for i, field in enumerate(fields) if 
field.startswith('rtems'))
-return '-'.join(fields[(rtems_field_index + 1):])
-
+for i, field in enumerate(fields):
+if field.startswith('rtems') and fields[(i + 1):] is not None:
+return '-'.join(fields[(i + 1):])
+return None
  
  def _pkgconfig_path(path):

  return os.path.join(path, 'lib', 'pkgconfig')
-- 2.30.2



--
embedded brains GmbH & Co. KG
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

Registergericht: Amtsgericht München
Registernummer: HRA 117265
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: ADA, gnat, rtems 6, ubuntu 22LTS

[Frank Kühndel]

Hello Emanuel,

I cannot say anything about your specific issue. I can just provide this 
information:


Our CI/CD builds rtems-tools with ADA on Ubuntu 22.04 for RSB, Git 
commit 35c73203df1e0bc7f0935cfb37ebc6581d8f1103 for aarch64, arm, bfin, 
i386, m68k, mips, moxie, nios2, or1k, powerpc, riskv, sparc, x86_64. The 
other architectures seem to have problems. Moreover, ADA is only build 
but not tested.


The big issue between building with and without ADA comes down to have 
Ubuntu specially setup for the RTEMS Source Builder to being able to 
build ADA. I need these packages:


bzip2
gcc-12
g++-12
gnat-12

And I need the following links (all g** compiler tools must have the 
same version 12 and all must be available without the "-12" postfix):


ln -s gcc /usr/bin/cc

for exe in /usr/bin/gcc*12 /usr/bin/gcov*12 /usr/bin/g++*12; do
   ln -s $exe ${exe%-12}
done

Greetings
Frank

On 10/4/23 19:02, emanuel stiebler wrote:

Subject:
ADA, gnat, rtems 6, ubuntu 22LTS
From:
emanuel stiebler 
Date:
10/4/23, 19:02

To:
"rtems-de...@rtems.org" 


I just tried to compile the tools for rtems6,
and just with "C", everything(?) works.

Trying to add ADA to the tools, it fails, complaining about gnat not 
being installed.

In the logfile:

hecking for objdir... .libs
configure: WARNING: using in-tree isl, disabling version check
configure: error: GNAT is required to build ada
shell cmd failed: /bin/sh -ex 
/AD1/PUB/RTEMS.work/rsb/rtems/build/aarch64-rtems6-gcc-506cb58-newlib-a021448-x86_64-linux-gnu-1/do-build
error: building 
aarch64-rtems6-gcc-506cb58-newlib-a021448-x86_64-linux-gnu-1emu@W531:/AD1/PUB/RTEMS.work/rsb/rtems$



but "gnat" gives me:

DDD@W531:/AD1/PUB/RTEMS.work/rsb/rtems$ gnat
GNAT 12.3.0
Copyright 1996-2022, Free Software Foundation, Inc.

To list Ada build switches use --help-ada

List of available commands

gnat bind   x86_64-linux-gnu-gnatbind-12
gnat chop   x86_64-linux-gnu-gnatchop-12
gnat clean  x86_64-linux-gnu-gnatclean-12
gnat compile    x86_64-linux-gnu-gnatmake-12 -f -u -c
gnat check  x86_64-linux-gnu-gnatcheck-12
gnat elim   x86_64-linux-gnu-gnatelim-12
gnat find   x86_64-linux-gnu-gnatfind-12
gnat krunch x86_64-linux-gnu-gnatkr-12
gnat link   x86_64-linux-gnu-gnatlink-12
gnat list   x86_64-linux-gnu-gnatls-12
gnat make   x86_64-linux-gnu-gnatmake-12
gnat metric x86_64-linux-gnu-gnatmetric-12
gnat name   x86_64-linux-gnu-gnatname-12
gnat preprocess x86_64-linux-gnu-gnatprep-12
gnat pretty x86_64-linux-gnu-gnatpp-12
gnat stack  x86_64-linux-gnu-gnatstack-12
gnat stub   x86_64-linux-gnu-gnatstub-12
gnat test   x86_64-linux-gnu-gnattest-12
gnat xref   x86_64-linux-gnu-gnatxref-12


Report bugs to rep...@adacore.com

What am I missing?
(GIT version of yesterday ...)

Cheers & Thanks
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


--
embedded brains GmbH & Co. KG
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

Registergericht: Amtsgericht München
Registernummer: HRA 117265
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: [rtems-tools] Fix shlex.join on python 3.8 and earlier

[Frank Kühndel]

Hello Chris,

if I did not make any mistake, this patch works fine on OpenSUSE 15.5.

I had some headaches because the source-builder tries to download the 
rtems-tools as tar.bz2 and the version with the patch is not yet on that 
server. I fumbled your patch into the cached tar.bz2. That seemed to 
work in the end.


Greetings
Frank

On 8/30/23 01:54, chr...@rtems.org wrote:

Hi Frabnk and Joel,

Can you please test this patch and let me know if the issue has been
fixed?

Thanks
Chris


--
embedded brains GmbH & Co. KG
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

Registergericht: Amtsgericht München
Registernummer: HRA 117265
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: [rtems-tools PATCH] rtemstoolkit: Fix shell execution

[Frank Kühndel]

Hello Chris,

On 8/29/23 12:45, Chris Johns wrote:

On 29 Aug 2023, at 6:24 pm, Frank Kühndel  
wrote:

Hello Chris,

our continuous integration server found an issues with this patch
("module 'shlex' has no attribute 'join'"):

Frank, thanks for the post and the insight. I saw the build break in Joel’s 
build but I could not see the reason. This will help.

I will look into this tomorrow. Sorry for the breakage.


No problem at all. I am happy I could help.

Have a good night
Frank

--
embedded brains GmbH & Co. KG
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

Registergericht: Amtsgericht München
Registernummer: HRA 117265
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: [rtems-tools PATCH] rtemstoolkit: Fix shell execution

[Frank Kühndel]

 pipe_commands.append(current_command)
+if shell:
+pipe_commands.append(command)
+else:
+# See if there is a pipe operator in the command. If present
+# split the commands by the pipe and run them with the pipe.
+# if no pipe it is the normal stdin and stdout
+current_command = []
+for cmd in command:
+if cmd == '|':
+pipe_commands.append(current_command)
+current_command = []
+else:
+current_command.append(cmd)
+pipe_commands.append(current_command)
  proc = None
  if len(pipe_commands) == 1:
  cmd = pipe_commands[0]
@@ -600,16 +604,28 @@ class capture_execution(execute):
  if __name__ == "__main__":
  def run_tests(e, commands, use_shell):
  for c in commands['shell']:
-e.shell(c)
+ec, out = e.shell(c)
+if ec != 0:
+  raise RuntimeError('ec = {}'.format(ec))
+for c in commands['error']:
+ec, out = e.shell(c)
+if ec == 0:
+  raise RuntimeError('ec = {}'.format(ec))
  for c in commands['spawn']:
-e.spawn(c)
+ec, out = e.spawn(c)
+if ec != 0:
+  raise RuntimeError('ec = {}'.format(ec))
  for c in commands['cmd']:
  if type(c) is str:
-e.command(c, shell = use_shell)
+ec, out = e.command(c, shell = use_shell)
  else:
-e.command(c[0], c[1], shell = use_shell)
+ec, out = e.command(c[0], c[1], shell = use_shell)
+if ec != 0:
+  raise RuntimeError('ec = {}'.format(ec))
  for c in commands['csubsts']:
-e.command_subst(c[0], c[1], shell = use_shell)
+ec, out = e.command_subst(c[0], c[1], shell = use_shell)
+if ec != 0:
+  raise RuntimeError('ec = {}'.format(ec))
  ec, proc = e.command(commands['pipe'][0], commands['pipe'][1],
   capture = False, stdin = subprocess.PIPE)
  if ec == 0:
@@ -623,11 +639,15 @@ if __name__ == "__main__":
  proc.stdin.close()
  e.capture(proc)
  del proc
+else:
+raise RuntimeError('ec = {}'.format(ec))
  for c in commands['open']:
  ec, proc = e.open(c)
  if ec == 0:
  e.capture(proc)
  del proc
+else:
+raise RuntimeError('ec = {}'.format(ec))
  
  def capture_output(text):

  print(text, end = '')
@@ -640,7 +660,8 @@ if __name__ == "__main__":
  commands = {}
  commands['windows'] = {}
  commands['unix'] = {}
-commands['windows']['shell'] = ['cd', 'dir /w', '.\\xyz', cmd_shell_test]
+commands['windows']['shell'] = ['cd', 'dir /w', cmd_shell_test]
+commands['windows']['error'] = ['.\\xyz']
  commands['windows']['spawn'] = ['hostname', 'hostnameZZ', ['netstat', 
'/e']]
  commands['windows']['cmd'] = [('ipconfig'), ('nslookup', 
'www.python.org')]
  commands['windows']['csubsts'] = [('netstat %0', ['-a']),
@@ -650,8 +671,9 @@ if __name__ == "__main__":
  ["echo",  "hello rtems", "|", "findstr", "rtems"],
  " ".join(["echo",  "hello rtems", "|", "findstr", "rtems"])
  ]
-commands['unix']['shell'] = ['pwd', 'ls -las', './xyz', sh_shell_test]
-commands['unix']['spawn'] = ['ls', 'execute.pyc', ['ls', '-i']]
+commands['unix']['shell'] = ['pwd', 'ls -las', sh_shell_test, 'ls -las']
+commands['unix']['error'] = ['./xyz']
+commands['unix']['spawn'] = ['ls', ['ls', '-i'], 'ls -l']
  commands['unix']['cmd'] = [('date'), ('date', '-R'), ('date', ['-u', '+%d 
%D']),
 ('date', '-u "+%d %D %S"')]
  commands['unix']['csubsts'] = [('date %0 "+%d %D %S"', ['-u']),
-- 2.37.1 ___ devel mailing 
list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel




--
embedded brains GmbH & Co. KG
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

Registergericht: Amtsgericht München
Registernummer: HRA 117265
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] eng: Add guidelines for validation tests

[Frank Kühndel]

On 6/15/23 09:33, Sebastian Huber wrote:

Subject:
[PATCH] eng: Add guidelines for validation tests
From:
Sebastian Huber 
Date:
6/15/23, 09:33

To:
devel@rtems.org


Update #3717.
---
  eng/req/howto.rst | 59 +++
  1 file changed, 59 insertions(+)

diff --git a/eng/req/howto.rst b/eng/req/howto.rst
index 0de3c01..688f693 100644
--- a/eng/req/howto.rst
+++ b/eng/req/howto.rst
@@ -1127,6 +1127,65 @@ the following post-condition states.
parameter in past calls to ${../if/directive:/name} shall not be
accessed by the ${../if/directive:/name} call.
  
+Validation Test Guidelines

+--
+
+The validation test cases, test runners, and test suites are generated by the
+``./spec2modules.py`` script from specification items.  For the placement and
+naming of the generated sources use the following rules:
+
+* Place architecture-specific validation test sources and programs into the
+  ``testsuites/validation/cpu`` directory.
+
+* Place BSP-specific validation test sources and programs into the
+  ``testsuites/validation/bsps`` directory.
+
+* Place all other validation test sources and programs into the
+  ``testsuites/validation`` directory.
+
+* Place architecture-specific unit test sources and programs into the
+  ``testsuites/unit/cpu`` directory.
+
+* Place BSP-specific unit test sources and programs into the
+  ``testsuites/unit/bsps`` directory.
+
+* Place all other unit test sources and programs into the
+  ``testsuites/unit`` directory.
+
+* Use dashes (``-``) to separate parts of a file name.  Use only dashes, the
+  digits ``0`` to ``9``, and the lower case characters ``a`` to ``z`` for file
+  names.  In particular, do not use underscores (``_``).
+
+* Use the prefix ``tc-`` for test case files.
+
+* Use the prefix ``tr-`` for test runner files.
+
+* Use the prefix ``ts-`` for test suite files.
+
+* Use the prefix ``tx-`` for test extension files (test support code).
+
+* Use hierarchical parts to compose a file name.  The order of the parts from
+  general to specific shall be left to right, for example
+  ``tc-task-construct.c``.


When reading "hierarchical parts" it was not clear to me what they 
meant. Maybe the sentence could be dropped and the next sentence 
rephrased into something like: "The parts separated by dashes shall be 
ordered from most general (left) to more specific (right), for example"



+
+* Tests for fatal errors shall have ``fatal`` as the most general file part,
+  for example ``ts-fatal-too-large-tls-size.c``.
+
+* Validation test suites shall have ``validation`` as the most general file
+  part, for example ``ts-validation-no-clock-0.c``.
+
+* Unit test suites shall have ``unit`` as the most general file part, for
+  example ``ts-unit-no-clock-0.c``.
+
+* Architecture-specific files shall have the architecture name as a file part,
+  for example ``ts-fatal-sparc-leon3-clock-initialization.c``.


I wonder whether ``ts-sparc-leon3-fatal-clock-initialization.c`` would 
be more logical?



+
+* BSP-specific files shall have the BSP family or variant name as a file part,
+  for example ``tc-sparc-gr712rc.c``.
+
+* Architecture-specific or BSP-specific tests shall use the ``enabled-by``
+  attribute of the associated build item to make them conditional.


"for example ``enabled-by: sparc/gr712rc``"?

"specification item" instead of "build item" to be consistent with the 
first sentence below the headline of this new section?


Is an ``enabled-by`` clause also needed for the architecture specific files?


+
  Verify the Specification Items
  --
  
-- 2.35.3 ___ devel mailing 
list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel




--
embedded brains GmbH & Co. KG
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

Registergericht: Amtsgericht München
Registernummer: HRA 117265
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: MIPS build requires native expat lib (Was: [rtems-source-builder PATCH] rtems: Add back gsed that was remove by mistake)

[Frank Kühndel]

Hi Chris,

On 4/21/23 01:48, Chris Johns wrote:

So I believe I am closer to the root of the problem now but I do not know what
needs to be fixed.

All good. I think I have something solid to work on. I just need to find some
time to do this. It is important so it is high on my unfunded list.


If I can be of any help, let me know.
Frank

--
embedded brains GmbH & Co. KG
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

Registergericht: Amtsgericht München
Registernummer: HRA 117265
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: MIPS build requires native expat lib (Was: [rtems-source-builder PATCH] rtems: Add back gsed that was remove by mistake)

[Frank Kühndel]

Hi Chris,

I compared the successful Debian-11 MIPS build with the failing 
AlmaLinux MIPS build.


The Debian 11 container has a native "expat.h" and "libexpat.a" 
installed (and the source-builder uses 
"rtems-source-builder/rtems/build/tmp/sb-1000/tools/rtems-mipstx39-gdb/opt/rtems/6/include/gmp.h"):



  minna@e7a01fbe81fa:~/src$ find /usr -name expat.h
  /usr/include/expat.h
  minna@e7a01fbe81fa:~/src$ find /usr -name libexpat.\*
  /usr/lib/x86_64-linux-gnu/libexpat.so
  /usr/lib/x86_64-linux-gnu/libexpat.a


With other words, the build on Debian is only successful because it uses 
the native "expat" from the OS. On Almalinux it is not installed so it 
fails. (The "expat" on Debian must be pulled in by some dependency from 
other needed packages.)


The "6/rtems-mips.bset" build "gmp" and "gdb" twice but "expat" only 
once. In "tools/rtems-default-tools.bset" "gmp", "expat" and "gdb" are 
build the first time:



%{with_rtems_dtc}
%{with_rtems_expat}
%{with_rtems_gmp}
%{with_rtems_gsed}
%{with_rtems_texinfo}
%{with_rtems_gdb}
%{with_rtems_binutils}
%{with_rtems_gcc}
%{with_rtems_tools}


According to the log, after executing "tools/rtems-tools-6.cfg" there is 
a clean-up and all the above tools are cleaned away, including "gmp", 
"expat" and "gdb", for example "expat":



cleaning: expat-2.4.8-x86_64-linux-gnu-1
[...]
cleanup: 
/home/minna/src/rtems-source-builder/rtems/build/tmp/expat-2.4.8-x86_64-linux-gnu-1-1000
removing: 
/home/minna/src/rtems-source-builder/rtems/build/tmp/expat-2.4.8-x86_64-linux-gnu-1-1000
cleanup: 
/home/minna/src/rtems-source-builder/rtems/build/expat-2.4.8-x86_64-linux-gnu-1
removing: 
/home/minna/src/rtems-source-builder/rtems/build/expat-2.4.8-x86_64-linux-gnu-1
cleanup: 
/home/minna/src/rtems-source-builder/rtems/build/tmp/sb-1000/tools/rtems-default-tools
removing: 
/home/minna/src/rtems-source-builder/rtems/build/tmp/sb-1000/tools/rtems-default-tools



This is why it cannot be found later on and it is not in the remaining 
files. Afterwards "tools/rtems-mipstx39-gdb.bset" build "gmp" and "gdb" 
again but not "expat":



devel/gmp-6.2.1
tools/rtems-gdb-13.1


This is the reason why this second "gdb" build finds "gmp" in 
"rtems-source-builder/rtems/build/tmp/sb-1000/tools/rtems-mipstx39-gdb/opt/rtems/6/include/gmp.h" 
but not "expat.h". Yet, a copy of the whole stuff from the earlier 
"tools/rtems-default-tools.bset" build is still in the 
"rtems-source-builder/rtems/build/tmp/sb-1000-staging" tree. (Yet, it 
looks like that at the end of the "tools/rtems-mipstx39-gdb.bset", the 
files from second "gmp" build would overwrite the ones from first build 
in the "sb-1000-staging" tree.


So I believe I am closer to the root of the problem now but I do not 
know what needs to be fixed.


Greetings,
fk


On 4/20/23 05:23, Chris Johns wrote:

Subject:
Re: [rtems-source-builder PATCH] rtems: Add back gsed that was remove by 
mistake

From:
Chris Johns 
Date:
4/20/23, 05:23

To:
Frank Kühndel , devel@rtems.org


On 19/4/2023 11:26 pm, Frank Kühndel wrote:

Hello Chris,

thanks for the introduction to package build. On AlmaLinux the file
rtems-source-builder/rtems/build/mipstx39-rtems6-gdb-13.1-x86_64-linux-gnu-1/build/gdb/config.log
 (attached) contains this error:


configure:21340: gcc -O2 -g -pipe
-I/home/minna/src/rtems-source-builder/rtems/build/tmp/sb-1000/tools/rtems-mipstx39-gdb/opt/rtems/6/include
 -o conftest -g -O2 
-L/home/minna/src/rtems-source-builder/rtems/build/tmp/sb-1000/tools/rtems-mipstx39-gdb/opt/rtems/6/lib
 conftest.c -lm -ldl  -lexpat >&5
conftest.c:53:10: fatal error: expat.h: No such file or directory
  #include "expat.h"
   ^
compilation terminated.


The include file and the library would be in

rtems-source-builder/rtems/build/tmp/sb-1000-staging/include/expat.h

Is the staging include path in the build flags for GDB?


rtems-source-builder/rtems/build/tmp/sb-1000-staging/lib/libexpat.a
rtems-source-builder/rtems/build/tmp/sb-1000-staging/lib/libexpat.la

The directories mentioned in the gcc-invokation contain only

     84 -rw-r--r--   1  minna    users   84084 Apr 19 13:19
rtems-source-builder/rtems/build/tmp/sb-1000/tools/rtems-mipstx39-gdb/opt/rtems/6/include/gmp.h

and

    6952 -rw-r--r--   1  minna    users 7115648 Apr 19 13:19
rtems-source-builder/rtems/build/tmp/sb-1000/tools/rtems-mipstx39-gdb/opt/rtems/6/lib/libgmp.a
   4 -rwxr-xr-x   1  minna    users 968 Apr 19 13:19
rtems-source-builder/rtems/build/tmp/sb-1000/tools/rtems-mipstx39-gdb/opt/rtems/6/lib/libgmp.la
   4 drwxr-xr-x   2  minna    users    4096 Apr 19 13:19
r

Re: [rtems-source-builder PATCH] rtems: Add back gsed that was remove by mistake

[Frank Kühndel]

Hello Chris,

thanks for the introduction to package build. On AlmaLinux the file 
rtems-source-builder/rtems/build/mipstx39-rtems6-gdb-13.1-x86_64-linux-gnu-1/build/gdb/config.log 
(attached) contains this error:



configure:21340: gcc -O2 -g -pipe 
-I/home/minna/src/rtems-source-builder/rtems/build/tmp/sb-1000/tools/rtems-mipstx39-gdb/opt/rtems/6/include 
-o conftest -g -O2 
-L/home/minna/src/rtems-source-builder/rtems/build/tmp/sb-1000/tools/rtems-mipstx39-gdb/opt/rtems/6/lib 
conftest.c -lm -ldl  -lexpat >&5

conftest.c:53:10: fatal error: expat.h: No such file or directory
 #include "expat.h"
  ^
compilation terminated.


The include file and the library would be in

rtems-source-builder/rtems/build/tmp/sb-1000-staging/include/expat.h
rtems-source-builder/rtems/build/tmp/sb-1000-staging/lib/libexpat.a
rtems-source-builder/rtems/build/tmp/sb-1000-staging/lib/libexpat.la

The directories mentioned in the gcc-invokation contain only

84 -rw-r--r--   1  minnausers   84084 Apr 19 13:19 
rtems-source-builder/rtems/build/tmp/sb-1000/tools/rtems-mipstx39-gdb/opt/rtems/6/include/gmp.h


and

   6952 -rw-r--r--   1  minnausers 7115648 Apr 19 13:19 
rtems-source-builder/rtems/build/tmp/sb-1000/tools/rtems-mipstx39-gdb/opt/rtems/6/lib/libgmp.a
  4 -rwxr-xr-x   1  minnausers 968 Apr 19 13:19 
rtems-source-builder/rtems/build/tmp/sb-1000/tools/rtems-mipstx39-gdb/opt/rtems/6/lib/libgmp.la
  4 drwxr-xr-x   2  minnausers4096 Apr 19 13:19 
rtems-source-builder/rtems/build/tmp/sb-1000/tools/rtems-mipstx39-gdb/opt/rtems/6/lib/pkgconfig
  4 -rw-r--r--   1  minnausers 257 Apr 19 13:19 
rtems-source-builder/rtems/build/tmp/sb-1000/tools/rtems-mipstx39-gdb/opt/rtems/6/lib/pkgconfig/gmp.pc


Just for the records:

PARAM_ARCH="mips"
PARAM_RTEMS_VERSION="6"
PARAM_RSB_GIT_COMMIT="origin/master"
GIT_HEAD="ae00c59541f21d8c459a33774efade80085c9b4a"
CONT_OS_VERSION_ID="8.7"
CONT_OS_ID="almalinux"

Let me know if you need more information. If you have a patch, I will be 
happy to feed our CI with it.


Greetings,
Frank


On 4/19/23 01:48, Chris Johns wrote:

Subject:
Re: [rtems-source-builder PATCH] rtems: Add back gsed that was remove by 
mistake

From:
Chris Johns 
Date:
4/19/23, 01:48

To:
Frank Kühndel , devel@rtems.org


Hi Frank,

Thanks for reporting this and looking into it. MIPS seems to need extra help.

I will try and answer the question you raised earlier about what is happening
with the packages being built. It is a little involved...

Packages we build like gcc and gdb are adding GMP and MPFR into their builds for
reasons internal to their projects. We have handled this with a per package
approach. I added GMP as an internal package (more on this later) a while ago
and gcc symlink'ed in the packages it needed from sources local to that project.
The gcc approach recently broke due to GMP on MacOS aarch64 failing to pass its
self test unless you disabled the assembler support. As a result I moved the
MPFR build out of gcc to an internal package build where we can control what
happens.

Internal packages in the RSB was added when staging was added. Staging is a
function of building vertical stacks of packages. For example GDB sits above
expat and gmp and so those are built and staged before GDB is built. No part of
a build can be installed into the prefix until all the pieces build. If you did
install pieces as the build progressed you would end up with weird and broken
installs under a prefix if the build failed. You also end up with side effects
of anything in the prefix effecting the build. An internal package is staged to
a special path that is not copied to the prefix. An internal package is built,
staged and used but never installed.

I feel over time we will move all symlink'ed packages other than newlib out of
the gcc build tree because we can control the build and they are used in more
than one tool.

Back to this failure. Can you please look in the config.log to see if the reason
for the failure can be seen?

Chris

On 18/4/2023 10:51 pm, Frank Kühndel wrote:

Hello Chris,

I indeed looked into the wrong build. Analyzing the correct results
unfortunately reveals that the issue persists in the current build the way I
described it in my earlier mail. I checked

git head "ae00c59541f21d8c459a33774efade80085c9b4a" and MIPS for

* "openSUSE Leap 15.4" -- failed
* "Fedora Linux 37 (Container Image)" -- failed
* "AlmaLinux 8.7 (Stone Smilodon)" -- failed
* "Debian GNU/Linux 11 (bullseye)" -- OK
* "Ubuntu 22.04.2 LTS" -- OK
* "Ubuntu 20.04.5 LTS" -- OK

This is an excerpt from AlmaLinux build log:

../source-builder/sb-set-builder --rtems-version 6 --prefix /opt/
rtems/6 --with_cxx --with_objc --jobs=12 --trace --log
/home/minna/src/rtems6-devtools-mips-6+git.2312.ae00c59541.x86_6

Re: [rtems-source-builder PATCH] rtems: Add back gsed that was remove by mistake

[Frank Kühndel]

Hello Chris,

I indeed looked into the wrong build. Analyzing the correct results 
unfortunately reveals that the issue persists in the current build the 
way I described it in my earlier mail. I checked


git head "ae00c59541f21d8c459a33774efade80085c9b4a" and MIPS for

* "openSUSE Leap 15.4" -- failed
* "Fedora Linux 37 (Container Image)" -- failed
* "AlmaLinux 8.7 (Stone Smilodon)" -- failed
* "Debian GNU/Linux 11 (bullseye)" -- OK
* "Ubuntu 22.04.2 LTS" -- OK
* "Ubuntu 20.04.5 LTS" -- OK

This is an excerpt from AlmaLinux build log:

../source-builder/sb-set-builder --rtems-version 6 --prefix /opt/
rtems/6 --with_cxx --with_objc --jobs=12 --trace --log 
/home/minna/src/rtems6-devtools-mips-6+git.2312.ae00c59541.x86_64_sb-set-builder.log 
6/rtems-mips
 Python: 3.6.8 (default, Feb 21 2023, 16:34:36) [GCC 8.5.0 20210514 
(Red Hat 8.5.0-16)]


[...]
checking whether to use expat... yes
checking for libexpat... no
configure: error: expat is missing or unusable
make[2]: *** [Makefile:11803: configure-gdb] Error 1
make[2]: Leaving directory 
'/home/minna/src/rtems-source-builder/rtems/build/mipstx39-rtems6-gdb-13.1-x86_64-linux-gnu-1/build'

make[1]: *** [Makefile:1004: all] Error 2
make[1]: Leaving directory 
'/home/minna/src/rtems-source-builder/rtems/build/mipstx39-rtems6-gdb-13.1-x86_64-linux-gnu-1/build'
shell cmd failed: /bin/sh -ex 
/home/minna/src/rtems-source-builder/rtems/build/mipstx39-rtems6-gdb-13.1-x86_64-linux-gnu-1/do-build

error: building mipstx39-rtems6-gdb-13.1-x86_64-linux-gnu-1
  See error report: 
rsb-report-mipstx39-rtems6-gdb-13.1-x86_64-linux-gnu-1.txt

  Note: In some cases the error appears only in
  the complete build log (see --log option)

As I wrote before, this is only to inform you in case your are 
interested. I do not need a fix.


Sorry again for the confusion and greetings,
Frank

On 4/18/23 12:16, Frank Kühndel wrote:

Subject:
Re: [rtems-source-builder PATCH] rtems: Add back gsed that was remove by 
mistake

From:
Frank Kühndel 
Date:
4/18/23, 12:16

To:
chr...@rtems.org, devel@rtems.org


Hello Chris,

I mistakenly looked into to the wrong build. I am currently checking 
this again. This is most likely an error of mine.


Sorry for the confusion
Frank

On 4/18/23 11:54, Frank Kühndel wrote:

Subject:
Re: [rtems-source-builder PATCH] rtems: Add back gsed that was remove 
by mistake

From:
Frank Kühndel 
Date:
4/18/23, 11:54

To:
chr...@rtems.org, devel@rtems.org


Hello Chris,

first of all, I do not use MIPS. So I have no troubles if it builds or 
not. I only want to report an observation from our continuous 
integration (CI) server.


In the past the MIPS builds failed due to the fact that the packages 
(lib)gmp-devel and (lib)expat-devel where not installed in the 
containers. A minor nuisance because all other RTEMS tools do build 
without these. I never understood why in case of MIPS the host must 
provide native packages given the fact that "gmp" and "expat" are 
apparently configured in the MIPS "bset".


You recent patch thankfully improved the situation. Our CI builds MIPS 
on Debian and Ubuntu, now. I do not fully understand why but I believe 
those where the distros where the native gmp-devel packet was needed 
before your patch.


For Alamalinux, Fedora and OpenSUSE the MIPS build still fails 
(apparently for the same reason they failed before your patch):


[...]
checking whether to use expat... yes
checking for libexpat... no
configure: error: expat is missing or unusable
make[2]: *** [Makefile:11803: configure-gdb] Error 1
make[2]: Leaving directory 
'/home/minna/src/rtems-source-builder/rtems/build/mipstx39-rtems6-gdb-13.1-x86_64-linux-gnu-1/build'

make[1]: *** [Makefile:1004: all] Error 2
make[1]: Leaving directory 
'/home/minna/src/rtems-source-builder/rtems/build/mipstx39-rtems6-gdb-13.1-x86_64-linux-gnu-1/build'
shell cmd failed: /bin/sh -ex 
/home/minna/src/rtems-source-builder/rtems/build/mipstx39-rtems6-gdb-13.1-x86_64-linux-gnu-1/do-build

error: building mipstx39-rtems6-gdb-13.1-x86_64-linux-gnu-1
   See error report: 
rsb-report-mipstx39-rtems6-gdb-13.1-x86_64-linux-gnu-1.txt

   Note: In some cases the error appears only in
   the complete build log (see --log option)


This is the end of the build log from Alamlinux 8.7. The error logs 
from the other distributions are identical.


As I indicated before, you do not need to look into this or fix this 
issue for me as I do not use MIPS and I can easily add the required 
(lib)expat-devel packet to those containers. I just write because I 
thought you maybe interested in knowing this detail.


Greetings
Frank


On 4/15/23 00:56, chr...@rtems.org wrote:

From: Chris Johns

- Build GNU sed for hosts that it is not installed on for the MIPS
   tools.
---
  rtems/config/tools/rtems-default-tools.bset | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/rtems/config/tools/rt

Re: [rtems-source-builder PATCH] rtems: Add back gsed that was remove by mistake

[Frank Kühndel]

Hello Chris,

I mistakenly looked into to the wrong build. I am currently checking 
this again. This is most likely an error of mine.


Sorry for the confusion
Frank

On 4/18/23 11:54, Frank Kühndel wrote:

Subject:
Re: [rtems-source-builder PATCH] rtems: Add back gsed that was remove by 
mistake

From:
Frank Kühndel 
Date:
4/18/23, 11:54

To:
chr...@rtems.org, devel@rtems.org


Hello Chris,

first of all, I do not use MIPS. So I have no troubles if it builds or 
not. I only want to report an observation from our continuous 
integration (CI) server.


In the past the MIPS builds failed due to the fact that the packages 
(lib)gmp-devel and (lib)expat-devel where not installed in the 
containers. A minor nuisance because all other RTEMS tools do build 
without these. I never understood why in case of MIPS the host must 
provide native packages given the fact that "gmp" and "expat" are 
apparently configured in the MIPS "bset".


You recent patch thankfully improved the situation. Our CI builds MIPS 
on Debian and Ubuntu, now. I do not fully understand why but I believe 
those where the distros where the native gmp-devel packet was needed 
before your patch.


For Alamalinux, Fedora and OpenSUSE the MIPS build still fails 
(apparently for the same reason they failed before your patch):


[...]
checking whether to use expat... yes
checking for libexpat... no
configure: error: expat is missing or unusable
make[2]: *** [Makefile:11803: configure-gdb] Error 1
make[2]: Leaving directory 
'/home/minna/src/rtems-source-builder/rtems/build/mipstx39-rtems6-gdb-13.1-x86_64-linux-gnu-1/build'

make[1]: *** [Makefile:1004: all] Error 2
make[1]: Leaving directory 
'/home/minna/src/rtems-source-builder/rtems/build/mipstx39-rtems6-gdb-13.1-x86_64-linux-gnu-1/build'
shell cmd failed: /bin/sh -ex 
/home/minna/src/rtems-source-builder/rtems/build/mipstx39-rtems6-gdb-13.1-x86_64-linux-gnu-1/do-build

error: building mipstx39-rtems6-gdb-13.1-x86_64-linux-gnu-1
   See error report: 
rsb-report-mipstx39-rtems6-gdb-13.1-x86_64-linux-gnu-1.txt

   Note: In some cases the error appears only in
   the complete build log (see --log option)


This is the end of the build log from Alamlinux 8.7. The error logs from 
the other distributions are identical.


As I indicated before, you do not need to look into this or fix this 
issue for me as I do not use MIPS and I can easily add the required 
(lib)expat-devel packet to those containers. I just write because I 
thought you maybe interested in knowing this detail.


Greetings
Frank


On 4/15/23 00:56, chr...@rtems.org wrote:

From: Chris Johns

- Build GNU sed for hosts that it is not installed on for the MIPS
   tools.
---
  rtems/config/tools/rtems-default-tools.bset | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/rtems/config/tools/rtems-default-tools.bset 
b/rtems/config/tools/rtems-default-tools.bset

index 0291786..35c9235 100644
--- a/rtems/config/tools/rtems-default-tools.bset
+++ b/rtems/config/tools/rtems-default-tools.bset
@@ -6,7 +6,7 @@
  # available
  #
  %define _internal_gsed_path %{_tmpinternal}
-%defineifnot with_rtems_gmp textproc/gsed-internal
+%defineifnot with_rtems_gsed textproc/gsed-internal
  # GNU tools need texinfo for makeinfo to build documentation
  %define _internal_texinfo_path %{_tmpinternal}
@@ -21,6 +21,7 @@
  %{with_rtems_dtc}
  %{with_rtems_expat}
  %{with_rtems_gmp}
+%{with_rtems_gsed}
  %{with_rtems_texinfo}
  %{with_rtems_gdb}
  %{with_rtems_binutils}
-- 2.37.1


--
embedded brains GmbH & Co. KG
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

Registergericht: Amtsgericht München
Registernummer: HRA 117265
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


--
embedded brains GmbH & Co. KG
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

Registergericht: Amtsgericht München
Registernummer: HRA 117265
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: [rtems-source-builder PATCH] rtems: Add back gsed that was remove by mistake

[Frank Kühndel]

Hello Chris,

first of all, I do not use MIPS. So I have no troubles if it builds or 
not. I only want to report an observation from our continuous 
integration (CI) server.


In the past the MIPS builds failed due to the fact that the packages 
(lib)gmp-devel and (lib)expat-devel where not installed in the 
containers. A minor nuisance because all other RTEMS tools do build 
without these. I never understood why in case of MIPS the host must 
provide native packages given the fact that "gmp" and "expat" are 
apparently configured in the MIPS "bset".


You recent patch thankfully improved the situation. Our CI builds MIPS 
on Debian and Ubuntu, now. I do not fully understand why but I believe 
those where the distros where the native gmp-devel packet was needed 
before your patch.


For Alamalinux, Fedora and OpenSUSE the MIPS build still fails 
(apparently for the same reason they failed before your patch):


[...]
checking whether to use expat... yes
checking for libexpat... no
configure: error: expat is missing or unusable
make[2]: *** [Makefile:11803: configure-gdb] Error 1
make[2]: Leaving directory 
'/home/minna/src/rtems-source-builder/rtems/build/mipstx39-rtems6-gdb-13.1-x86_64-linux-gnu-1/build'

make[1]: *** [Makefile:1004: all] Error 2
make[1]: Leaving directory 
'/home/minna/src/rtems-source-builder/rtems/build/mipstx39-rtems6-gdb-13.1-x86_64-linux-gnu-1/build'
shell cmd failed: /bin/sh -ex 
/home/minna/src/rtems-source-builder/rtems/build/mipstx39-rtems6-gdb-13.1-x86_64-linux-gnu-1/do-build

error: building mipstx39-rtems6-gdb-13.1-x86_64-linux-gnu-1
  See error report: 
rsb-report-mipstx39-rtems6-gdb-13.1-x86_64-linux-gnu-1.txt

  Note: In some cases the error appears only in
  the complete build log (see --log option)


This is the end of the build log from Alamlinux 8.7. The error logs from 
the other distributions are identical.


As I indicated before, you do not need to look into this or fix this 
issue for me as I do not use MIPS and I can easily add the required 
(lib)expat-devel packet to those containers. I just write because I 
thought you maybe interested in knowing this detail.


Greetings
Frank


On 4/15/23 00:56, chr...@rtems.org wrote:

From: Chris Johns

- Build GNU sed for hosts that it is not installed on for the MIPS
   tools.
---
  rtems/config/tools/rtems-default-tools.bset | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/rtems/config/tools/rtems-default-tools.bset 
b/rtems/config/tools/rtems-default-tools.bset
index 0291786..35c9235 100644
--- a/rtems/config/tools/rtems-default-tools.bset
+++ b/rtems/config/tools/rtems-default-tools.bset
@@ -6,7 +6,7 @@
  # available
  #
  %define _internal_gsed_path %{_tmpinternal}
-%defineifnot with_rtems_gmp textproc/gsed-internal
+%defineifnot with_rtems_gsed textproc/gsed-internal
  
  # GNU tools need texinfo for makeinfo to build documentation

  %define _internal_texinfo_path %{_tmpinternal}
@@ -21,6 +21,7 @@
  %{with_rtems_dtc}
  %{with_rtems_expat}
  %{with_rtems_gmp}
+%{with_rtems_gsed}
  %{with_rtems_texinfo}
  %{with_rtems_gdb}
  %{with_rtems_binutils}
-- 2.37.1


--
embedded brains GmbH & Co. KG
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

Registergericht: Amtsgericht München
Registernummer: HRA 117265
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: Help regarding Building x86_64 BSP

[Frank Kühndel]

Hello Karel,

the set of tool builds below was run for RTEMS 6, with RSB
GIT_HEAD 0054104e37aa870aab87294207fc20396312106f. Your comment on me 
using GCC 12 on some OS, which would natively use an older GCC version, 
triggered me to add more OS containers to the build set. This way the 
different GCC variants are better covered in the future.


opensuse-leap 15.4  (gcc 7.5.0, Python 3.6.15)   x86_64 : OK
almalinux 9.1   (gcc 11.3.1, Python 3.9.14)  x86_64 : OK
almalinux 8.7   (gcc 8.5.0, Python 3.6.8)x86_64 : OK
fedora 37   (gcc 12.2.1, Python 3.11.2)  x86_64 : OK
debian 11   (gcc 10.2.1, Python 3.9.2)   x86_64 : OK
opensuse-leap 15.4  (gcc 12.2.1, Python 3.6.15)  x86_64 : OK
ubuntu 22.04(gcc 11.3.0, Python 3.10.6)  x86_64 : OK
ubuntu 20.04(gcc 9.4.0, Python 3.8.10)   x86_64 : OK
ubuntu 22.04(gcc 12.1.0, Python 3.10.6)  x86_64 : OK

Your fix works perfectly. All errors are gone.
Thanks for your time and effort to fix the failing builds.

Greetings
Frank

On 3/19/23 23:18, Karel Gardas wrote:

Subject:
Re: Help regarding Building x86_64 BSP
From:
Karel Gardas 
Date:
3/19/23, 23:18

To:
Frank Kühndel , j...@rtems.org
CC:
"rtems-de...@rtems.org" , skhattar...@gmail.com


On 3/8/23 11:08, Frank Kühndel wrote:
The build failures all happen when `building: 
grub2-2.06-x86_64-linux-gnu-1` which is the last build step. There are 
several similar errors. These are two of them taken from the build log:


cc1: all warnings being treated as errors
util/mkimage.c: In function ‘grub_install_generate_image’:
util/mkimage.c:1386:41: error: dangling pointer to ‘tmp_’ may be used 
[-Werror=d

angling-pointer=]
  1386 | PE_OHDR (o32, o64, header_size) = 
grub_host_to_target32 (header_

size);
util/mkimage.c:857:28: note: ‘tmp_’ declared here
   857 |   __typeof__((o64)->field) tmp_;    \
   |    ^~~~
util/mkimage.c:1386:9: note: in expansion of macro ‘PE_OHDR’
  1386 | PE_OHDR (o32, o64, header_size) = 
grub_host_to_target32 (header_

size);
   | ^~~
util/mkimage.c:1387:40: error: dangling pointer to ‘tmp_’ may be used 
[-Werror=d

angling-pointer=]
  1387 | PE_OHDR (o32, o64, entry_addr) = 
grub_host_to_target32 (layout.s

tart_address);
util/mkimage.c:857:28: note: ‘tmp_’ declared here
   857 |   __typeof__((o64)->field) tmp_;    \
   |    ^~~~
util/mkimage.c:1387:9: note: in expansion of macro ‘PE_OHDR’
  1387 | PE_OHDR (o32, o64, entry_addr) = 
grub_host_to_target32 (layout.s

tart_address);
   | ^~~

Maybe one needs a new version of grub sources for gcc 12?


GRUB 2.06 is the last available release. The release cadence is 2 years 
and next version should be released around this summer. I would not like 
to go to git version in the meantime, but rather stick to released version.


Possible and working (tested on Fedora 37 and Ubuntu 20.04) workaround 
is to use --disable-werror as all the related errors are just warnings.


The patch already sent, testing and reporting from your side would be 
highly appreciated.


Thanks,
Karel


--
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: Help regarding Building x86_64 BSP

[Frank Kühndel]

Hello Karel,

On 3/12/23 13:03, Karel Gardas wrote:

On 3/8/23 11:08, Frank Kühndel wrote:

Hello,

On 3/8/23 01:42, Joel Sherrill wrote:

Subject:
Re: Help regarding Building x86_64 BSP
From:
Joel Sherrill 
Date:
3/8/23, 01:42

To:
Karel Gardas 
CC:
"rtems-de...@rtems.org" 


Did you build the x86_64 tools and qemu using the RTEMS Source Builder?


The only information I can contribute to this discussion are the 
results our Continuous Integration Server currently creates when 
building x86_64 tools with the RTEMS Source Builder:


almalinux 8.7: OK   [gcc (GCC) 8.5.0]
debian 11: OK   [gcc (Debian 10.2.1-6) 10.2.1]
fedora 37: Failure  [gcc (GCC) 12.2.1]
opensuse-leap 15.4: Failure [gcc (SUSE Linux) 12.2.1]
ubuntu 22.04: Failure   [gcc (Ubuntu 12.1.0-2ubuntu1~22.04) 12.1.0]

These builds were for RTEMS 6 and RSB 


Just a remark to table above. Ubuntu 22.04 LTS default GCC is 11.x and 
it's perfectly able to build x86_64 tools (tested by me).


Yes, that is indeed true. Sorry, I forgot to mention I install gcc 12 
where possible. opensuse-leap 15.4 would natively use gcc 7 (and most 
likely compile the tools with it).


For Siddharth Khattar, who started this thread, this would then mean he 
should be able to build the RTEMS tools (using RTEMS Source Builder) on 
ubuntu 22.04 and them with the tools RTEMS as described in the RTEMS 
User manual https://docs.rtems.org/branches/master/user/start/index.html.


Greetings
Frank



On RHEL8, default gcc is 8.5.x and it should be ok.
On RHEL9, default gcc is 11.3.x and it should also be able to build 
tools fine.


The only issue on RHELx is that makeinfo is missing so you either need 
to install from different repo or by hand.


SLES testing in whatever form is out of my reach.

Karel


--
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: [PATCH rtems-source-builder] 6: Update MicroBlaze gdb to 12.1

[Frank Kühndel]

Hello Chris,
Hello Alex,

On 3/8/23 20:51, Chris Johns wrote:

Subject:
Re: [PATCH rtems-source-builder] 6: Update MicroBlaze gdb to 12.1
From:
Chris Johns 
Date:
3/8/23, 20:51

To:
Alex White , devel@rtems.org


What hosts have you tested building this on?

I only ask as gdb-13 is not building on FeeBSD 13.1 for me.


I tried Alex's patch on top of RSB 
bfed51462eafcb6a5102a2d6d80b233f3c6ef635 for RTEMS 6 and microblaze:


almalinux 8.7: OK   [gcc (GCC) 8.5.0]
debian 11: OK   [gcc (Debian 10.2.1-6) 10.2.1]
fedora 37: OK   [gcc (GCC) 12.2.1]
opensuse-leap 15.4: OK  [gcc (SUSE Linux) 12.2.1]
ubuntu 22.04: OK[gcc (Ubuntu 12.1.0-2ubuntu1~22.04) 12.1.0]

With FreeBSD I cannot help, sorry. Also, the above containers use the 
latest OS versions. I did not test older ones. Moreover, Opensuse 15.4 
does not use gcc 12 by default but a much older compiler.


*Without* Alex's patch these builds fail on Ubuntu and Fedora when 
building building microblaze-rtems6-gdb-11.2-x86_64-linux-gnu-1 with the 
following error:


In file included from 
/home/minna/src/rtems-source-builder/rtems/build/microblaz

e-rtems6-gdb-11.2-x86_64-linux-gnu-1/build/sim/../../gdb-11.2/sim/microblaze/mic
roblaze.h:21,
 from 
/home/minna/src/rtems-source-builder/rtems/build/microblaz

e-rtems6-gdb-11.2-x86_64-linux-gnu-1/build/sim/../../gdb-11.2/sim/microblaze/sim
-main.h:21,
 from 
/home/minna/src/rtems-source-builder/rtems/build/microblaz

e-rtems6-gdb-11.2-x86_64-linux-gnu-1/build/sim/../../gdb-11.2/sim/microblaze/../
common/dv-cfi.c:37:
/home/minna/src/rtems-source-builder/rtems/build/microblaze-rtems6-gdb-11.2-x86_
64-linux-gnu-1/build/sim/../../gdb-11.2/sim/microblaze/../../opcodes/microblaze-
opcm.h:45:9: error: ‘fsqrt’ redeclared as different kind of symbol
   45 |   fint, fsqrt,
  | ^
In file included from ../../gnulib/import/math.h:41,
 from 
/home/minna/src/rtems-source-builder/rtems/build/microblaz

e-rtems6-gdb-11.2-x86_64-linux-gnu-1/build/sim/../../gdb-11.2/sim/microblaze/../
common/dv-cfi.c:28:
/usr/include/bits/mathcalls-narrow.h:36:20: note: previous declaration 
of ‘fsqrt

’ with type ‘float(double)’
   36 | __MATHCALL_NARROW (__MATHCALL_NAME (sqrt), 
__MATHCALL_REDIR_NAME2 (sqrt)

, 1);
  |^~~

Greetings,
Frank



Chris

On 9/3/2023 2:14 am, Alex White wrote:

GDB 11.2 fails to compile on Ubuntu 22.04 for MicroBlaze.
---
  rtems/config/6/rtems-microblaze.bset | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rtems/config/6/rtems-microblaze.bset 
b/rtems/config/6/rtems-microblaze.bset
index ea59313..e05fd7b 100644
--- a/rtems/config/6/rtems-microblaze.bset
+++ b/rtems/config/6/rtems-microblaze.bset
@@ -13,7 +13,7 @@
  
  devel/expat-2.4.8-1

  devel/gmp-6.2.1
-tools/rtems-gdb-11.2
+tools/rtems-gdb-12.1
  
  tools/rtems-xilinx-binutils-2.36

  tools/rtems-xilinx-gcc-10-newlib-head

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel



--
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: Help regarding Building x86_64 BSP

[Frank Kühndel]

Hello,

On 3/8/23 01:42, Joel Sherrill wrote:

Subject:
Re: Help regarding Building x86_64 BSP
From:
Joel Sherrill 
Date:
3/8/23, 01:42

To:
Karel Gardas 
CC:
"rtems-de...@rtems.org" 


Did you build the x86_64 tools and qemu using the RTEMS Source Builder?


The only information I can contribute to this discussion are the results 
our Continuous Integration Server currently creates when building x86_64 
tools with the RTEMS Source Builder:


almalinux 8.7: OK   [gcc (GCC) 8.5.0]
debian 11: OK   [gcc (Debian 10.2.1-6) 10.2.1]
fedora 37: Failure  [gcc (GCC) 12.2.1]
opensuse-leap 15.4: Failure [gcc (SUSE Linux) 12.2.1]
ubuntu 22.04: Failure   [gcc (Ubuntu 12.1.0-2ubuntu1~22.04) 12.1.0]

These builds were for RTEMS 6 and RSB 
GIT_HEAD="bfed51462eafcb6a5102a2d6d80b233f3c6ef635".


The build failures all happen when `building: 
grub2-2.06-x86_64-linux-gnu-1` which is the last build step. There are 
several similar errors. These are two of them taken from the build log:


cc1: all warnings being treated as errors
util/mkimage.c: In function ‘grub_install_generate_image’:
util/mkimage.c:1386:41: error: dangling pointer to ‘tmp_’ may be used 
[-Werror=d

angling-pointer=]
 1386 | PE_OHDR (o32, o64, header_size) = grub_host_to_target32 
(header_

size);
util/mkimage.c:857:28: note: ‘tmp_’ declared here
  857 |   __typeof__((o64)->field) tmp_;\
  |^~~~
util/mkimage.c:1386:9: note: in expansion of macro ‘PE_OHDR’
 1386 | PE_OHDR (o32, o64, header_size) = grub_host_to_target32 
(header_

size);
  | ^~~
util/mkimage.c:1387:40: error: dangling pointer to ‘tmp_’ may be used 
[-Werror=d

angling-pointer=]
 1387 | PE_OHDR (o32, o64, entry_addr) = grub_host_to_target32 
(layout.s

tart_address);
util/mkimage.c:857:28: note: ‘tmp_’ declared here
  857 |   __typeof__((o64)->field) tmp_;\
  |^~~~
util/mkimage.c:1387:9: note: in expansion of macro ‘PE_OHDR’
 1387 | PE_OHDR (o32, o64, entry_addr) = grub_host_to_target32 
(layout.s

tart_address);
  | ^~~

Maybe one needs a new version of grub sources for gcc 12?

Greetings
Frank



On Tue, Mar 7, 2023, 11:39 AM Karel Gardas  wrote:


On 3/7/23 19:24, Karel Gardas wrote:

On 3/7/23 15:05, Siddharth Khattar wrote:

Hello all,
So I was aiming to make a project to improve the amd64 BSP for RTEMS
(modify it according to ACPI standards along with other stuff) but
first I would need to build it. Unfortunately there was no way to
build it natively within RTEMS source. So, I needed to install QEMU
and had to build the UEFI firmware,OVMF by Tianocore in order to build
it.

Indeed, they still list Ubutnu 16.04 LTS as a build OS. Hmm, I would go
with VM for this. You need to build it just once...

Investigating more, it looks like qemu build those too, so there is no
need to deal with TianoCore alone anymore. My 7.2.0 install contains:

$ find qemu-7.2.0/share/qemu/ -name 'edk2*'
qemu-7.2.0/share/qemu/edk2-arm-code.fd
qemu-7.2.0/share/qemu/edk2-x86_64-code.fd
qemu-7.2.0/share/qemu/edk2-arm-vars.fd
qemu-7.2.0/share/qemu/edk2-i386-secure-code.fd
qemu-7.2.0/share/qemu/edk2-x86_64-secure-code.fd
qemu-7.2.0/share/qemu/edk2-aarch64-code.fd
qemu-7.2.0/share/qemu/edk2-i386-code.fd
qemu-7.2.0/share/qemu/edk2-i386-vars.fd
qemu-7.2.0/share/qemu/edk2-licenses.txt

Ditto for Qemu build by RSB. Will send you tarball of scripts I'm using
for building and running rtems.exe on those...



Karel
___
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



--
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: RFC #4666 TFTP: Implement block and window size options

[Frank Kühndel]

Hello Joel,

there is nothing which remains to be done. Hence, I closed this ticket. 
Thanks for remaining us and please excuse our sluggish response.


Greetings
Frank

On 2/22/23 21:12, Joel Sherrill wrote:

Hi Sebastian,

This ticket has a number of commits logged against it. What remains or can
it be closed?

https://devel.rtems.org/ticket/4666

If it can't be closed, an update on what needs to be done should be added
and maybe the milestone bumped.

Thanks.

--joel


--
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: [PATCH rtems-source-builder 1/2] Update to gdb 13.1 for rtems 6

[Frank Kühndel]

On 2/22/23 16:26, Joel Sherrill wrote:

Is it ok to push if I fix the comment?


I confess I have not tried your patch. I noted you have commented out 
the gdb-readline8.2.patch. Beside that no surprises and from my side you 
can go ahead.


Greetings
Frank



--joel

On Wed, Feb 22, 2023 at 3:29 AM Frank Kühndel <
frank.kuehn...@embedded-brains.de> wrote:


Hello Joel,

On 2/21/23 16:25, Joel Sherrill wrote:

Subject:
[PATCH rtems-source-builder 1/2] Update to gdb 13.1 for rtems 6
From:
Joel Sherrill
Date:
2/21/23, 16:25

To:
devel@rtems.org


---
   rtems/config/6/rtems-default.bset |  2 +-
   rtems/config/tools/rtems-gdb-13.1.cfg | 16 
   2 files changed, 17 insertions(+), 1 deletion(-)
   create mode 100644 rtems/config/tools/rtems-gdb-13.1.cfg

diff --git a/rtems/config/6/rtems-default.bset

b/rtems/config/6/rtems-default.bset

index a0601aa..a76efe6 100644
--- a/rtems/config/6/rtems-default.bset
+++ b/rtems/config/6/rtems-default.bset
@@ -12,7 +12,7 @@
   %defineifnot with_rtems_dtc  devel/dtc-1.6.1-1
   %defineifnot with_rtems_expatdevel/expat-2.4.8-1
   %defineifnot with_rtems_gmp  devel/gmp-6.2.1
-%defineifnot with_rtems_gdb  tools/rtems-gdb-12.1
+%defineifnot with_rtems_gdb  tools/rtems-gdb-13.1
   %defineifnot with_rtems_binutils tools/rtems-binutils-2.38
   %defineifnot with_rtems_gcc  tools/rtems-gcc-12-newlib-head
   %defineifnot with_rtems_toolstools/rtems-tools-6
diff --git a/rtems/config/tools/rtems-gdb-13.1.cfg

b/rtems/config/tools/rtems-gdb-13.1.cfg

new file mode 100644
index 000..4a6a1c7
--- /dev/null
+++ b/rtems/config/tools/rtems-gdb-13.1.cfg
@@ -0,0 +1,16 @@
+#
+# GDB 12.1

Is 12.1 correct? It looks like a copy-paste error.

Greetings
Frank


+#
+
+%include %{_configdir}/checks.cfg
+%include %{_configdir}/base.cfg
+
+%define gdb_version 13.1
+%define gdb_src_ext xz
+%hash sha512 gdb-%{gdb_version}.tar.xz \
+

  
5lBU/7wDV+7tSxfh7cXvRapzyd3zsSEGUePYWVduJ8HSeyZoAP4mMo7aWIV0VczYYy9AAM/F9j+QhUCWKQGHyg==

+
+#%patch add gdb --rsb-file=gdb-readline8.2.patchhttps://

sourceware.org/git/?p=binutils-gdb.git;a=commitdiff_plain;h=1add37b567a7dee39d99f37b37802034c3fce9c4

+#%hash sha512 gdb-readline8.2.patch

E/nGalfBBfn0rl/pi1SGIuKD11x0qREZBp3ajaFbl/nGMZUIm31M/1z0FsG76K7IjvE5pPsl2JqESt+LBN9lZA==

+
+%include %{_configdir}/gdb-common-1.cfg
-- 2.24.4 ___ devel mailing
listde...@rtems.org  http://lists.rtems.org/mailman/listinfo/devel


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




--
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: [PATCH rtems-source-builder 1/2] Update to gdb 13.1 for rtems 6

[Frank Kühndel]

Hello Joel,

On 2/21/23 16:25, Joel Sherrill wrote:

Subject:
[PATCH rtems-source-builder 1/2] Update to gdb 13.1 for rtems 6
From:
Joel Sherrill 
Date:
2/21/23, 16:25

To:
devel@rtems.org


---
  rtems/config/6/rtems-default.bset |  2 +-
  rtems/config/tools/rtems-gdb-13.1.cfg | 16 
  2 files changed, 17 insertions(+), 1 deletion(-)
  create mode 100644 rtems/config/tools/rtems-gdb-13.1.cfg

diff --git a/rtems/config/6/rtems-default.bset 
b/rtems/config/6/rtems-default.bset
index a0601aa..a76efe6 100644
--- a/rtems/config/6/rtems-default.bset
+++ b/rtems/config/6/rtems-default.bset
@@ -12,7 +12,7 @@
  %defineifnot with_rtems_dtc  devel/dtc-1.6.1-1
  %defineifnot with_rtems_expatdevel/expat-2.4.8-1
  %defineifnot with_rtems_gmp  devel/gmp-6.2.1
-%defineifnot with_rtems_gdb  tools/rtems-gdb-12.1
+%defineifnot with_rtems_gdb  tools/rtems-gdb-13.1
  %defineifnot with_rtems_binutils tools/rtems-binutils-2.38
  %defineifnot with_rtems_gcc  tools/rtems-gcc-12-newlib-head
  %defineifnot with_rtems_toolstools/rtems-tools-6
diff --git a/rtems/config/tools/rtems-gdb-13.1.cfg 
b/rtems/config/tools/rtems-gdb-13.1.cfg
new file mode 100644
index 000..4a6a1c7
--- /dev/null
+++ b/rtems/config/tools/rtems-gdb-13.1.cfg
@@ -0,0 +1,16 @@
+#
+# GDB 12.1


Is 12.1 correct? It looks like a copy-paste error.

Greetings
Frank


+#
+
+%include %{_configdir}/checks.cfg
+%include %{_configdir}/base.cfg
+
+%define gdb_version 13.1
+%define gdb_src_ext xz
+%hash sha512 gdb-%{gdb_version}.tar.xz \
+   
5lBU/7wDV+7tSxfh7cXvRapzyd3zsSEGUePYWVduJ8HSeyZoAP4mMo7aWIV0VczYYy9AAM/F9j+QhUCWKQGHyg==
+
+#%patch add gdb 
--rsb-file=gdb-readline8.2.patchhttps://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff_plain;h=1add37b567a7dee39d99f37b37802034c3fce9c4
+#%hash sha512 gdb-readline8.2.patch 
E/nGalfBBfn0rl/pi1SGIuKD11x0qREZBp3ajaFbl/nGMZUIm31M/1z0FsG76K7IjvE5pPsl2JqESt+LBN9lZA==
+
+%include %{_configdir}/gdb-common-1.cfg
-- 2.24.4 ___ devel mailing 
list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel




--
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: [PATCH 1/1] RSB: Mitigate too short error reports

[Frank Kühndel]

Hi Joel,

On 1/19/23 15:08, Joel Sherrill wrote:

Subject:
Re: [PATCH 1/1] RSB: Mitigate too short error reports
From:
Joel Sherrill 
Date:
1/19/23, 15:08

To:
Frank Kühndel 
CC:
Chris Johns , devel@rtems.org


On Thu, Jan 19, 2023 at 6:47 AM Frank Kühndel <
frank.kuehn...@embedded-brains.de> wrote:


Hello Chris,
Hello Joel,

On 1/16/23 18:27, Joel Sherrill wrote:

Subject:
Re: [PATCH 1/1] RSB: Mitigate too short error reports
From:
Joel Sherrill
Date:
1/16/23, 18:27

To:
Frank Kühndel
CC:
Chris Johns,devel@rtems.org


On Mon, Jan 16, 2023 at 8:46 AM Frank Kühndel <
frank.kuehn...@embedded-brains.de> wrote:


Hi Chris,

On 1/16/23 01:02, Chris Johns wrote:

Subject:
Re: [PATCH 1/1] RSB: Mitigate too short error reports
From:
Chris Johns
Date:
1/16/23, 01:02

To:
Frank Kühndel,devel@rtems.org


On 22/12/2022 9:09 pm, Frank Kühndel wrote:

On 12/21/22 00:06, Chris Johns wrote:

On 21/12/2022 3:44 am, Frank Kuehndel wrote:

From: Frank Kühndel

Close #4642
---
 source-builder/sb/ereport.py | 4 
 1 file changed, 4 insertions(+)

diff --git a/source-builder/sb/ereport.py

b/source-builder/sb/ereport.py

index d8fb5f6..d391917 100755
--- a/source-builder/sb/ereport.py
+++ b/source-builder/sb/ereport.py
@@ -55,6 +55,10 @@ def generate(name, opts, header = None, footer =

None):

 with open(name, 'w') as l:
 l.write(os.linesep.join(r))
 log.notice('  See error report: %s' % (name))
+log.notice('  (Hint: The first error may be in front of

a '

+'line containing\n'
+'  "Error 1" [GNU make] and may be only in the

whole

log '

Is this too specific to GNU make? What ifs a package uses cmake or

something

else?

As the text indicates, this is specific to GNU make. For those using

something

else reading this text will still hint that the first error may not be

in the

end of the report "and may be only in the whole log".

Another weak point in this text is that by far not all errors

originating from

"make". Yet, the true trouble is the original "See error report: %s"

where it

can sometimes happen that the error is not in this "error report" at

all.

I found it difficult to find a wording which is short, clear and

helpful to the

reader and at the same time not confusing. I am not perfectly happy

with the

notice above. I just found it a reasonable compromise.

If you prefer more generic texts - such as the examples below - I will

send a

new patch with the suggested test.

   "Hint: The first error may be far way from the end of the
   report and in cases can only be found in the whole build log."

   "Hint: The error is most likely in the error report otherwise
   see the whole build log [--log option]."

If you find any such change might cause more confusion than it might

be

helpful,

I think it better to close this bug than to try to fix it.


I think all you have written is valid and I have found the wording

difficult.

There will never be a robust error message scanner or a simple full

proof way to

find errors. The parallel builds makes tracking the errors difficult

and

the

point of error and end of the build a long distance apart.

I usually search the logs for "rror:" and that's the first time something
is reported
whether by make or gcc or whatever. It may not be the root cause but it

gets

me to the first report.

Cutting any of these long reports down is always going to be possible to
cut out the real issue. It's ok because it it's more than just an odd

setup

issue on the host, someone will have to build locally to reproduce the
issue.
And then they will get the full output.



As a result I question the value of the report and wonder if it should

be

removed. The report adds overhead to the build as the logging process

needs to

maintain a buffer of lines that is always updating. Your attention and

interest

around this feature highlights how problematic it is so maybe it is

simpler and

better to remove it and we leave users to find the error in the log

file.

I am happy to accept the report has not worked as a feature, remove it

and in

the process we recover some overheads in the logging area of the RSB?


I am not against the error report and I do not say it is a useless
feature. It is just that I found the message '  See error report: %s'
confusing in those cases where the report does not contain the error
at all because it is too short (the error report consists simply of the
last 400 lines of the build log).

To answer your question, I believe there is always a build log - no
matter whether the `--log` option is used or not. In this case, removing
the error report and pointing to the build log in case of error (for
example like '  See build log: %s') would certainly solve all my

concerns.

But on the build@ reports, it is nice to have something. Many t

Re: [PATCH 1/1] RSB: Mitigate too short error reports

[Frank Kühndel]

Hello Chris,
Hello Joel,

On 1/16/23 18:27, Joel Sherrill wrote:

Subject:
Re: [PATCH 1/1] RSB: Mitigate too short error reports
From:
Joel Sherrill 
Date:
1/16/23, 18:27

To:
Frank Kühndel 
CC:
Chris Johns , devel@rtems.org


On Mon, Jan 16, 2023 at 8:46 AM Frank Kühndel <
frank.kuehn...@embedded-brains.de> wrote:


Hi Chris,

On 1/16/23 01:02, Chris Johns wrote:

Subject:
Re: [PATCH 1/1] RSB: Mitigate too short error reports
From:
Chris Johns
Date:
1/16/23, 01:02

To:
Frank Kühndel,devel@rtems.org


On 22/12/2022 9:09 pm, Frank Kühndel wrote:

On 12/21/22 00:06, Chris Johns wrote:

On 21/12/2022 3:44 am, Frank Kuehndel wrote:

From: Frank Kühndel

Close #4642
---
source-builder/sb/ereport.py | 4 
1 file changed, 4 insertions(+)

diff --git a/source-builder/sb/ereport.py

b/source-builder/sb/ereport.py

index d8fb5f6..d391917 100755
--- a/source-builder/sb/ereport.py
+++ b/source-builder/sb/ereport.py
@@ -55,6 +55,10 @@ def generate(name, opts, header = None, footer =

None):

with open(name, 'w') as l:
l.write(os.linesep.join(r))
log.notice('  See error report: %s' % (name))
+log.notice('  (Hint: The first error may be in front of

a '

+'line containing\n'
+'  "Error 1" [GNU make] and may be only in the whole

log '

Is this too specific to GNU make? What ifs a package uses cmake or

something

else?

As the text indicates, this is specific to GNU make. For those using

something

else reading this text will still hint that the first error may not be

in the

end of the report "and may be only in the whole log".

Another weak point in this text is that by far not all errors

originating from

"make". Yet, the true trouble is the original "See error report: %s"

where it

can sometimes happen that the error is not in this "error report" at

all.

I found it difficult to find a wording which is short, clear and

helpful to the

reader and at the same time not confusing. I am not perfectly happy

with the

notice above. I just found it a reasonable compromise.

If you prefer more generic texts - such as the examples below - I will

send a

new patch with the suggested test.

  "Hint: The first error may be far way from the end of the
  report and in cases can only be found in the whole build log."

  "Hint: The error is most likely in the error report otherwise
  see the whole build log [--log option]."

If you find any such change might cause more confusion than it might be

helpful,

I think it better to close this bug than to try to fix it.


I think all you have written is valid and I have found the wording

difficult.

There will never be a robust error message scanner or a simple full

proof way to

find errors. The parallel builds makes tracking the errors difficult and

the

point of error and end of the build a long distance apart.

I usually search the logs for "rror:" and that's the first time something
is reported
whether by make or gcc or whatever. It may not be the root cause but it gets
me to the first report.

Cutting any of these long reports down is always going to be possible to
cut out the real issue. It's ok because it it's more than just an odd setup
issue on the host, someone will have to build locally to reproduce the
issue.
And then they will get the full output.



As a result I question the value of the report and wonder if it should be
removed. The report adds overhead to the build as the logging process

needs to

maintain a buffer of lines that is always updating. Your attention and

interest

around this feature highlights how problematic it is so maybe it is

simpler and

better to remove it and we leave users to find the error in the log file.

I am happy to accept the report has not worked as a feature, remove it

and in

the process we recover some overheads in the logging area of the RSB?


I am not against the error report and I do not say it is a useless
feature. It is just that I found the message '  See error report: %s'
confusing in those cases where the report does not contain the error
at all because it is too short (the error report consists simply of the
last 400 lines of the build log).

To answer your question, I believe there is always a build log - no
matter whether the `--log` option is used or not. In this case, removing
the error report and pointing to the build log in case of error (for
example like '  See build log: %s') would certainly solve all my concerns.


But on the build@ reports, it is nice to have something. Many times it
is possible to diagnose the issue. Just in the past fifteen minutes, there
was one which having the log made it clear that CentOS 7 and other older
distributions need to use a newer GCC. Having the info in the build@
message was more than enough to diagnose that.


On the other hand, implementing the error report too

Re: Typo in rtems-libbsd/rtems_waf/rtems.py?

[Frank Kühndel]

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: [PATCH 1/1] RSB: Mitigate too short error reports

[Frank Kühndel]

Hi Chris,

On 1/16/23 01:02, Chris Johns wrote:

Subject:
Re: [PATCH 1/1] RSB: Mitigate too short error reports
From:
Chris Johns 
Date:
1/16/23, 01:02

To:
Frank Kühndel , devel@rtems.org


On 22/12/2022 9:09 pm, Frank Kühndel wrote:

On 12/21/22 00:06, Chris Johns wrote:

On 21/12/2022 3:44 am, Frank Kuehndel wrote:

From: Frank Kühndel

Close #4642
---
   source-builder/sb/ereport.py | 4 
   1 file changed, 4 insertions(+)

diff --git a/source-builder/sb/ereport.py b/source-builder/sb/ereport.py
index d8fb5f6..d391917 100755
--- a/source-builder/sb/ereport.py
+++ b/source-builder/sb/ereport.py
@@ -55,6 +55,10 @@ def generate(name, opts, header = None, footer = None):
   with open(name, 'w') as l:
   l.write(os.linesep.join(r))
   log.notice('  See error report: %s' % (name))
+    log.notice('  (Hint: The first error may be in front of a '
+    'line containing\n'
+    '  "Error 1" [GNU make] and may be only in the whole log '

Is this too specific to GNU make? What ifs a package uses cmake or something
else?

As the text indicates, this is specific to GNU make. For those using something
else reading this text will still hint that the first error may not be in the
end of the report "and may be only in the whole log".

Another weak point in this text is that by far not all errors originating from
"make". Yet, the true trouble is the original "See error report: %s" where it
can sometimes happen that the error is not in this "error report" at all.

I found it difficult to find a wording which is short, clear and helpful to the
reader and at the same time not confusing. I am not perfectly happy with the
notice above. I just found it a reasonable compromise.

If you prefer more generic texts - such as the examples below - I will send a
new patch with the suggested test.

     "Hint: The first error may be far way from the end of the
     report and in cases can only be found in the whole build log."

     "Hint: The error is most likely in the error report otherwise
     see the whole build log [--log option]."

If you find any such change might cause more confusion than it might be helpful,
I think it better to close this bug than to try to fix it.


I think all you have written is valid and I have found the wording difficult.
There will never be a robust error message scanner or a simple full proof way to
find errors. The parallel builds makes tracking the errors difficult and the
point of error and end of the build a long distance apart.

As a result I question the value of the report and wonder if it should be
removed. The report adds overhead to the build as the logging process needs to
maintain a buffer of lines that is always updating. Your attention and interest
around this feature highlights how problematic it is so maybe it is simpler and
better to remove it and we leave users to find the error in the log file.

I am happy to accept the report has not worked as a feature, remove it and in
the process we recover some overheads in the logging area of the RSB?



I am not against the error report and I do not say it is a useless 
feature. It is just that I found the message '  See error report: %s' 
confusing in those cases where the report does not contain the error
at all because it is too short (the error report consists simply of the 
last 400 lines of the build log).


To answer your question, I believe there is always a build log - no 
matter whether the `--log` option is used or not. In this case, removing 
the error report and pointing to the build log in case of error (for 
example like '  See build log: %s') would certainly solve all my concerns.


On the other hand, implementing the error report took time and was 
certainly done with good reason. I do not feel like I should be the one 
deciding to remove it. Changing the message or simply closing 
https://devel.rtems.org/ticket/4642 would also be perfectly valid for me.


Greetings ... and a happy new year to you
Frank

--
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: [PATCH 1/1] RSB: Mitigate too short error reports

[Frank Kühndel]

On 12/21/22 00:06, Chris Johns wrote:

On 21/12/2022 3:44 am, Frank Kuehndel wrote:

From: Frank Kühndel

Close #4642
---
  source-builder/sb/ereport.py | 4 
  1 file changed, 4 insertions(+)

diff --git a/source-builder/sb/ereport.py b/source-builder/sb/ereport.py
index d8fb5f6..d391917 100755
--- a/source-builder/sb/ereport.py
+++ b/source-builder/sb/ereport.py
@@ -55,6 +55,10 @@ def generate(name, opts, header = None, footer = None):
  with open(name, 'w') as l:
  l.write(os.linesep.join(r))
  log.notice('  See error report: %s' % (name))
+log.notice('  (Hint: The first error may be in front of a '
+'line containing\n'
+'  "Error 1" [GNU make] and may be only in the whole log '

Is this too specific to GNU make? What ifs a package uses cmake or something 
else?


As the text indicates, this is specific to GNU make. For those using 
something else reading this text will still hint that the first error 
may not be in the end of the report "and may be only in the whole log".


Another weak point in this text is that by far not all errors 
originating from "make". Yet, the true trouble is the original "See 
error report: %s" where it can sometimes happen that the error is not in 
this "error report" at all.


I found it difficult to find a wording which is short, clear and helpful 
to the reader and at the same time not confusing. I am not perfectly 
happy with the notice above. I just found it a reasonable compromise.


If you prefer more generic texts - such as the examples below - I will 
send a new patch with the suggested test.


"Hint: The first error may be far way from the end of the
report and in cases can only be found in the whole build log."

"Hint: The error is most likely in the error report otherwise
see the whole build log [--log option]."

If you find any such change might cause more confusion than it might be 
helpful, I think it better to close this bug than to try to fix it.


Greetings,
Frank

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

Is it possible to use cFS without a file system?

[Frank Kühndel]

Hello,

the core Flight System (cFS) is a software platform created by NASA 
(https://cfs.gsfc.nasa.gov/). It provides essential onboard services for 
space missions.


I would like to use cFS on top of an RTEMS qualified for space by ESA 
(https://rtems-qual.io.esa.int/). Yet, this qualified RTEMS has no file 
system. cFS can be configured to be used without IP-networking and with 
static loader only but I have not found any configuration to disable the 
file system.


Does anyone know whether it is possible to use cFS without a file system 
or can give advice on using cFS without file system?


Of course without file system all applications accessing files will not 
work. Yet, would at least the core services (such as Executive Service 
(ES), Software Bus Service (SB), Event Service (EVS), Table Service 
(TBL), and Time Service (TIME)) be functioning?


Greetings and Thanks
Frank

--
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: docs not building to PDF

[Frank Kühndel]

Hello Sam,
Hello Chris,

Sam, your mermaid diagram misses only yet another loop. Beside of that 
it looks really good and impressing. I like it very much. Many thanks 
for your efforts and help.


Unfortunately, I made (yet another) mistake and did not recognize that 
you already reproduced my diagram before I went through all the efforts 
to produce an own new graphic and put it into a patch. I apologize that 
I do not use your image. I simply have the patch ready now and do not 
want to start over again.


Chris, I created a ditaa diagram as you suggested but in the end I 
figured that it misinterprets the "=", "|" and "*" characters in the 
text. I do not know how that can be prevented. I tried to replace them 
by similar looking Unicode. That worked fine on OpenSUSE but failed (as 
I presumed) on FreeBSD.


My current solution is an activity diagram in plantuml. Hopefully this 
solution is acceptable. I will send the patch to the mailing list next.


Greetings
Frank

On 10/13/22 07:19, Sam Price wrote:

Subject:
Re: docs not building to PDF
From:
Sam Price 
Date:
10/13/22, 07:19

To:
Chris Johns 
CC:
Frank Kühndel , Thomas Doerfler 
, Development 



I forgot the loop backs. from close back to open.

On Thu, Oct 13, 2022 at 1:12 AM Chris Johns  wrote:


On 13/10/2022 4:06 pm, Sam Price wrote:

example



https://mermaid.live/edit#pako:eNqFVG1vmzAQ_iuWP6UVaZM0DQGlkSYlnSJ1bUUyddmYkAlmYQEbGVP6sv732cdrtSrj0z0v9p19h1_xjgcU2ziTRNJFRH4JkvQfRy5zWcQi6WeBjVYqiEgcvVAUR76iSu2WyoKLwzu94lyWHBaRsNGOs0yi3Z4IdJrwnEkv5RGT6Aq5-FyGMnXxzBfnc0GzPNZ0cggi0UMdr4HW3sp5-PYV_amiz010dwKrdbWwAnK2e2mqh8CC9OdiFxsN7OZoSGez_LL2rlc3y_V2rWJvs71fepvrzf36iMlZflp4D85qs2xNLvZjvjtk6lquhoPR2CgiFvAC8Nh4pMLnGXVxWd6JPgJPKRPcRmGgitegh1Ii9wa685zF3e3NFimboES1xH-WNFMujXpqgYECIonn52FIhaHT6zw87HV5dFJvsItV7s5NAdb7aIPOXHxYxYNTV1GISNK2DIBtHQZkb3xHs-XQho6as6pv3XnRdSfBu-4C_sflMji8nmYUqkn0ynA202A-L2WEfpz-RP3-HFUzXtMVbKRmnFu5osACQ16LAEq6GsVGqTCIbVG1fIyBJeVc1GKJQNCtrGkdHyfh2rsKECCXTTiSvuhmL4CG1tY0gP_S7ypomQ9KKLOXnGreb9XetnkVDefSQ4ANnFCRkChQD9mrdrlY7mmi_i5bhQENiRoZ9fOzN2UlueTrZ7bDthQ5NXCeBu3Th-2QxJliU8K-c57UJgWx_YqfsD0cDs6soXk5mlyMR2PTmkwN_Kzo0dn4cmxZg4FlTqeTifVm4BfYQNkvLNMyzUvLvJhMp6b59hcqM78E
<
https://mermaid.live/edit#pako:eNqFVG1vmzAQ_iuWP6UVaZM0DQGlkSYlnSJ1bUUyddmYkAlmYQEbGVP6sv732cdrtSrj0z0v9p19h1_xjgcU2ziTRNJFRH4JkvQfRy5zWcQi6WeBjVYqiEgcvVAUR76iSu2WyoKLwzu94lyWHBaRsNGOs0yi3Z4IdJrwnEkv5RGT6Aq5-FyGMnXxzBfnc0GzPNZ0cggi0UMdr4HW3sp5-PYV_amiz010dwKrdbWwAnK2e2mqh8CC9OdiFxsN7OZoSGez_LL2rlc3y_V2rWJvs71fepvrzf36iMlZflp4D85qs2xNLvZjvjtk6lquhoPR2CgiFvAC8Nh4pMLnGXVxWd6JPgJPKRPcRmGgitegh1Ii9wa685zF3e3NFimboES1xH-WNFMujXpqgYECIonn52FIhaHT6zw87HV5dFJvsItV7s5NAdb7aIPOXHxYxYNTV1GISNK2DIBtHQZkb3xHs-XQho6as6pv3XnRdSfBu-4C_sflMji8nmYUqkn0ynA202A-L2WEfpz-RP3-HFUzXtMVbKRmnFu5osACQ16LAEq6GsVGqTCIbVG1fIyBJeVc1GKJQNCtrGkdHyfh2rsKECCXTTiSvuhmL4CG1tY0gP_S7ypomQ9KKLOXnGreb9XetnkVDefSQ4ANnFCRkChQD9mrdrlY7mmi_i5bhQENiRoZ9fOzN2UlueTrZ7bDthQ5NXCeBu3Th-2QxJliU8K-c57UJgWx_YqfsD0cDs6soXk5mlyMR2PTmkwN_Kzo0dn4cmxZg4FlTqeTifVm4BfYQNkvLNMyzUvLvJhMp6b59hcqM78E


SVG link


https://mermaid.ink/svg/pako:eNqFVG1v2jAQ_iuWP0GVtrxDIoo0CTohdaUCJsaWKXKIMzKIjRynKWX899mXV7SK5dM9L_adfRef8IZ7FFs4kkTScUB-CRLevrZsZrOABdKNPAtNVRCQffBO0T5wFZVqz1QmXOwu9IyzWbgbB8JCG84iiTZbItBNyGMmnQMPmEQPyMb30pcHGw9dcT8SNIr3mg53XiBqqOI10MKZzlffvqI_WfS5iGZ1WK2rhRWQs9xLUzUEFqQ_G9vYKGA1R0HOl5MvC-dx-jRZrBcqdpbrl4mzfFy-LK6Y5pNPY2c1ny4npcnG7p5vdpG6lodmo9UxkoB5PAHcMV6pcHlEbZyWV9dH4AfKBLeQ76niNaihA5FbA82c-Xj2_LRGyiYoUS1xj5JGyqVRTS0wkEckcdzY96kwdHqdh_u1Ko_q-QabvcpduSnAeh9t0JmTD6tYzfMqEhFIWpYBsKzDgOyF72q2GNpQUWOW9a06L7ru0LvoLuB_XDaDw-tpRr6aRCcNh0MNRqNURujHzU90eztC2YzndAYLqRjnUs4osMCQ5yKAlM5GsVAyDGJZVC5fY2BJOhe5mCIQdCtzWsfXSbj2qgIEyGkTrqRPqtkToKG1OQ3gv_RFBSXzQQlp9pRTzfut2ls2L6PhXHoIsIFDKkISeOohO2mXjeWWhurvslToUZ-okVE_PzsrK4klXxzZBltSxNTA8cErn76cPBD2nfMqxNYJv2Gr2Wzcmc1-t9Vrd1qdvtkbGPio6NZdp9sxzUbD7A8GvZ55NvA7bKDsbbNv9vtds9HtNcxm-_wXZ4G-ow
<
https://mermaid.ink/svg/pako:eNqFVG1v2jAQ_iuWP0GVtrxDIoo0CTohdaUCJsaWKXKIMzKIjRynKWX899mXV7SK5dM9L_adfRef8IZ7FFs4kkTScUB-CRLevrZsZrOABdKNPAtNVRCQffBO0T5wFZVqz1QmXOwu9IyzWbgbB8JCG84iiTZbItBNyGMmnQMPmEQPyMb30pcHGw9dcT8SNIr3mg53XiBqqOI10MKZzlffvqI_WfS5iGZ1WK2rhRWQs9xLUzUEFqQ_G9vYKGA1R0HOl5MvC-dx-jRZrBcqdpbrl4mzfFy-LK6Y5pNPY2c1ny4npcnG7p5vdpG6lodmo9UxkoB5PAHcMV6pcHlEbZyWV9dH4AfKBLeQ76niNaihA5FbA82c-Xj2_LRGyiYoUS1xj5JGyqVRTS0wkEckcdzY96kwdHqdh_u1Ko_q-QabvcpduSnAeh9t0JmTD6tYzfMqEhFIWpYBsKzDgOyF72q2GNpQUWOW9a06L7ru0LvoLuB_XDaDw-tpRr6aRCcNh0MNRqNURujHzU90eztC2YzndAYLqRjnUs4osMCQ5yKAlM5GsVAyDGJZVC5fY2BJOhe5mCIQdCtzWsfXSbj2qgIEyGkTrqRPqtkToKG1OQ3gv_RFBSXzQQlp9pRTzfut2ls2L6PhXHoIsIFDKkISeOohO2mXjeWWhurvslToUZ-okVE_PzsrK4klXxzZBltSxNTA8cErn76cPBD2nfMqxNYJv2Gr2Wzcmc1-t9Vrd1qdvtkbGPio6NZdp9sxzUbD7A8GvZ55NvA7bKDsbbNv9vtds9HtNcxm-_wXZ4G-ow



I couldn't figure out how to get semi colons to work
new lines are kind  of a pain also.

You are a legend (pun intended) :D

It is looking goo but Frank has the final say.

Chris


stateDiagram-v2

initbsd:Initialize libbsd
initNetwork

Re: docs not building to PDF

[Frank Kühndel]

Hello Chris,

On 10/11/22 23:47, Chris Johns wrote:

On 11/10/2022 7:12 pm, Frank Kühndel wrote:

Hello Chris,

On 10/11/22 03:09, Chris Johns wrote:

On 10/10/2022 9:22 pm, Frank Kühndel wrote:

images/filesystem/tftpfs_usage.png:
https://share.embedded-brains.de/index.php/s/fQ4WrLrqmBjcbwC

I have a greyed out image I cannot clearly see?

The image has a transparent background. Some image viewers put a gray pattern in
the background in those case. The PDF has naturally a white background on top of
which the image is displayed.


images/filesystem/ftpfs_usage.svg:
https://share.embedded-brains.de/index.php/s/xk7kArkm6mbjcn2

The SVG file is the source for the PNG. Both files must be placed in the
images/filesystem folder.

How is the SVG file created and how can it be edited?

I used Inkscape. It should be possible to edit it with (almost) any tool that
supports SVG.

I tried withhttps://pixelied.com/features/svg-editor  and it was a mess.


Yes. I tried another Web-based tool and it was the same mess. Yet, all 
converter handle this correctly. For example:


$ firefox file:///home/frank/tftpfs_usage.svg
$ convert -geometry 1422x1574 tftpfs_usage.svg tftpfs_usage.png
$ display tftpfs_usage.svg
$ libreoffice tftpfs_usage.svg
$ rsvg-convert --width 1422 --height 1574 -o tftpfs_usage_Z.png 
tftpfs_usage.svg


So, I guess it is a bug in the web-based tools.



My concern is the widgets (or whatever they are called) a tool has may not be
available in another.


Inkscape is open source and available freely on (almost?) all operating 
system. It is *the* standard open source tool for producing high-quality 
vector graphics today.





Your Web-Browser should be able to display SVG directly when you
point it to the file like for example:file:///home//tftpfs_usage.svg

You can recreate the PNG with Inkscape on the command line with:

$ inkscape --export-dpi=300 --export-filename=tftpfs_usage.png tftpfs_usage.svg

We have a number of images in the doco created using PlantUML. Did you consider
using that tool? It has the advantage the images can be regenerated from the
source as part of the build if PlantUML and Ditaa are installed and we get a
consistent looking set of images.


I took a look into PlantUML:

* My image is not an UML diagram (or similar to another diagram input 
format it supports)
* It may be realized as an Activity Diagram, yet. But it will not look 
very similar to the current image.
* Most of all, I will need to spend significant time to learn PlantUML 
and to get the result in shape I will certainly need to do some trying 
and fumbling around.


Openly, my company will never pay me for converting the image to 
PlantUML. Sorry about this.


Do you see any solution to this problem?

Greetings
Frank

--
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: docs not building to PDF

[Frank Kühndel]

Hello,

I am very sorry for having caused this trouble.

In my first email in June I wrote that there is an image which I did not 
send as part of the patch (who is reviewing some 160KiB binary PNG data 
and will the mailing list server accept that?). Yet, I forgot to mention 
these files in my last Email. I uploaded the two missing files to:


images/filesystem/tftpfs_usage.png:
https://share.embedded-brains.de/index.php/s/fQ4WrLrqmBjcbwC

images/filesystem/ftpfs_usage.svg:
https://share.embedded-brains.de/index.php/s/xk7kArkm6mbjcn2

The SVG file is the source for the PNG. Both files must be placed in the 
images/filesystem folder.


Again sorry for the trouble
Frank


On 10/8/22 22:17, Noor Aman wrote:

After further digging I found that this image 'tftpfs_usage.png' is
actually missing from the /images/filesystem directory. So just to confirm
this, I used a dummy 'tftpfs_usage.png', put that in the same directory and
everything built fine. So nothing needs to be removed. All we need is the
actual 'tftpfs_usage.png' image in the directory.

On Sat, 8 Oct 2022 at 20:00, Joel Sherrill  wrote:



On Sat, Oct 8, 2022 at 7:24 AM Noor Aman  wrote:


Hey Frank,

I was able to find the issue which was causing the pdf to be not built
properly.
==
diff --git a/filesystem/trivial_ftp.rst b/filesystem/trivial_ftp.rst
index 3ef8bba..eccd035 100644
--- a/filesystem/trivial_ftp.rst
+++ b/filesystem/trivial_ftp.rst
@@ -280,10 +280,7 @@ application.  The mount point can be any directory.
The name ``/tftp``
  used in the figure serves only as an example.  The final unmounting and
  remove directory steps are optional.

-.. figure:: ../images/filesystem/tftpfs_usage.png
-  :width: 90%
-  :align: center
-  :alt: TFTP Usage Diagram
+
===
This png is causing issues. Removing these lines removed the error and
the pdf was generated successfully. I hope this is helpful.


Thanks. I saw this email right as I was setting up to do a git bisect with
my
morning tea.

Two issues with this figure situation.

(1) We probably should not have png/jpg files without the corresponding
source.

(2) I have no idea how to fix this other than to remove the figure. It
looks like Frank's
text is referencing the figure so simply removing it isn't the best answer.

--joel


Thanks,
Noor

On Sat, 8 Oct 2022 at 05:35, Chris Johns  wrote:


On 8/10/2022 9:47 am, Chris Johns wrote:

On 8/10/2022 10:12 am, Noor Aman wrote:

I can confirm that the same is happening on my PC too.

Could you please bisect the repo to find the patch that broke things?

A simpler way to find the commit is to see the last build on
docs.rtems.org
which is 6.278550b and the next commit after 278550b is:

commit 23fc93bf648507ac417237c20069c4ab7c793251
Author: Frank Kühndel
Date:   Thu Jun 9 15:21:05 2022 +0200

 TFTPFS: New documentation

Frank ?


--
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: [PATCH rtems-docs v2] TFTPFS: New documentation

[Frank Kühndel]

ping!

Since this patch was sent in June to the list I will shortly recap the 
context:


* I extended the TFTP file system by block and window size options. 
These patches are already part of RTEMS.


* The patch below is the documentation for it. Version 1 of this patch 
has already been reviewed by Chris, Joel and Sebastian (many thanks 
again) and I fixed all raised issues (see 
https://lists.rtems.org/pipermail/devel/2022-June/071822.html).


* What is missing is an OK for this patch.

For your convenience, I put v2 of the generated filesystem.pdf for 
download at the link shown below. I hope the PDF is more convenient to 
read than the patch itself. Please, remind that only chapter "Trivial 
FTP Client Filesystem" is affected by this patch.


https://share.embedded-brains.de/index.php/s/Qg6aoX7kByxfQLZ

My question is: Do you have more critic or are you OK with v2 of this patch?

Thanks in advance
Frank

On 6/9/22 15:21, Frank Kuehndel wrote:

Subject:
[PATCH rtems-docs v2] TFTPFS: New documentation
From:
Frank Kuehndel 
Date:
6/9/22, 15:21

To:
devel@rtems.org


From: Frank Kühndel

---
  filesystem/index.rst   |   1 +
  filesystem/trivial_ftp.rst | 564 -
  2 files changed, 562 insertions(+), 3 deletions(-)

diff --git a/filesystem/index.rst b/filesystem/index.rst
index f4e2ed6..64a2f1d 100644
--- a/filesystem/index.rst
+++ b/filesystem/index.rst
@@ -9,6 +9,7 @@ RTEMS Filesystem Design Guide (|version|).
  .. topic:: Copyrights and License
  
  ||copy|  1988, 2015 On-Line Applications Research Corporation (OAR)

+||copy|  2022 embedded brains GmbH (http://www.embedded-brains.de)
  
  .. include:: ../common/license.rst
  
diff --git a/filesystem/trivial_ftp.rst b/filesystem/trivial_ftp.rst

index e43c036..3ef8bba 100644
--- a/filesystem/trivial_ftp.rst
+++ b/filesystem/trivial_ftp.rst
@@ -3,7 +3,565 @@
  Trivial FTP Client Filesystem
  *
  
-This chapter describes the Trivial FTP (TFTP) Client Filesystem.

+This chapter describes the Trivial File Transfer Protocol (TFTP) Client
+Filesystem.  TFTP is designed to be an especially simple protocol which
+uses the User Datagram Protocol (UDP) for data transfer over the Internet.
+Its purpose is to send a single file between to network nodes (client and
+server).  A file can be sent in both directions, i.e. a client can either
+read a file from a server or write a file to the server.
  
-This chapter should be written after the IMFS chapter is completed and describe

-the implementation of the TFTP.
+Besides reading or writing a file no other operations are supported.  That
+is, one cannot seek the file, not append to the end of a file, not open
+the file for reading and writing at the same time, not list directories,
+not move files and so on.
+
+TFTP is inherent insecure as it does not provide any means for
+authentication or encryption.  Therefore, it is highly recommended not
+to employ it on public networks.  Nevertheless, it is still widely used
+to load software and configuration data during early boot stages over
+a Local Area Network (LAN).
+
+RTEMS TFTP Filesystem Implementation
+
+
+The RTEMS TFTP filesystem implements a TFTP client which can be used
+through the file system.  With other words, one needs to mount the
+TFTP filesystem and can afterwards open a file for reading or writing
+below that mount point.  The content of that file is then effectively
+read from or written to the remote server.  The RTEMS implementation
+implements the following features:
+
+* `RFC 1350<https://www.rfc-editor.org/rfc/rfc1350.html>`_
+  *The TFTP Protocol (Revision 2)*
+* `RFC 2347<https://www.rfc-editor.org/rfc/rfc2347.html>`_
+*TFTP Option Extension*
+* `RFC 2348<https://www.rfc-editor.org/rfc/rfc2348.html>`_
+*TFTP Blocksize Option*
+* `RFC 7440<https://www.rfc-editor.org/rfc/rfc7440.html>`_
+*TFTP Windowsize Option*
+
+Many simple TFTP server do not support options (RFC 2347). Therefore, in
+case the server rejects the first request with options, the RTEMS client
+makes automatically a second attempt using only the "classical" RFC 1350.
+
+The implementation has the following shortcomings:
+
+* IPv6 is not supported (yet).
+
+* No congestion control is implemented.
+
+  (Congestion is simply expressed a network traffic jam which involves
+  package loss.)  This implementation would worsen a congestion situation
+  and squeeze out TCP connections.  If that is a concern in your setup,
+  it can be prevented by using value `1` as `windowsize` when mounting
+  the TFTP file system.
+
+* One must call ``open()``, ``read()``, ``write()`` and ``close()``
+  at a good pace.
+
+  TFTP is designed to read or write a whole already existing file in
+  one sweep.  It uses timeouts (of unspecified length) and it does not
+  know keep-alive messages.  If the client does not respond to the
+  server in due

Re: [PATCH] sb/execute: Use a decoder that maintains state aross blocks

[Frank Kühndel]

Hello Chris,

I reviewed this patch and I also tested it in the environment which made 
problems earlier. The UnicodeDecodeError disappeared. This patch is fine 
for me.


Many tanks for fix this issue.
Frank

On 9/29/22 12:59, chr...@rtems.org wrote:

From: Chris Johns

Update #4726
---
  source-builder/sb/execute.py | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/source-builder/sb/execute.py b/source-builder/sb/execute.py
index 3db9abc..bdab373 100755
--- a/source-builder/sb/execute.py
+++ b/source-builder/sb/execute.py
@@ -27,6 +27,7 @@
  from __future__ import print_function
  
  import functools

+import codecs
  import io
  import os
  import re
@@ -181,6 +182,7 @@ class execute(object):
  
  if trace_threads:

  print('execute:_readthread: start')
+decoder = codecs.getincrementaldecoder(sys.stdout.encoding)()
  count = 0
  line = ''
  try:
@@ -201,7 +203,7 @@ class execute(object):
  break
  # str and bytes are the same type in Python2
  if type(data) is not str and type(data) is bytes:
-data = data.decode(sys.stdout.encoding)
+data = decoder.decode(data)
  last_ch = data[-1]
  sd = (line + data).split('\n')
  if last_ch != '\n':


--
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: [PATCH 1/2] sb/setbuilder: Install the build when stagging or configured to install

[Frank Kühndel]

Hi Chris,

I checked your two patches in an opensuse leap 15.4 container building 
the tools (rtems-source-builder git) for RTEMS 6 and ARM BSP. The build 
was OK; the dependencies on "expat-devel" and "gmp-devel" are gone.


Thanks and have a nice weekend
Frank


On 9/16/22 08:59, chr...@rtems.org wrote:

Subject:
[PATCH 1/2] sb/setbuilder: Install the build when stagging or configured 
to install

From:
chr...@rtems.org
Date:
9/16/22, 08:59

To:
devel@rtems.org


From: Chris Johns

---
  source-builder/sb/setbuilder.py | 9 ++---
  1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/source-builder/sb/setbuilder.py b/source-builder/sb/setbuilder.py
index f24ac87..3e16111 100644
--- a/source-builder/sb/setbuilder.py
+++ b/source-builder/sb/setbuilder.py
@@ -226,6 +226,9 @@ class buildset:
  def installing(self):
  return self.install_mode() == 'installing'
  
+def installable(self):

+return not self.opts.no_install() or self.staging()
+
  def staging(self):
  return not self.installing()
  
@@ -553,14 +556,14 @@ class buildset:

 ', '.join([b.name() for b in builds])))
  if deps is None and not have_errors:
  for b in builds:
-log.trace('_bset:   : %s: %r' % (self.install_mode(),
- b.installable()))
+log.trace('_bset:   : %s: installable=%r 
build-installable=%r' % \
+  (self.install_mode(), self.installable(), 
b.installable()))
  if b.installable():
  prefix = b.config.expand('%{_prefix}')
  buildroot = 
path.join(b.config.expand('%{buildroot}'), prefix)
  if self.staging():
  prefix = b.config.expand('%{stagingroot}')
-if not self.opts.no_install():
+if self.installable():
  self.install(self.install_mode(), b.name(), 
buildroot, prefix)
  #
  # Sizes ...
-- 2.37.1 ___ devel mailing 
list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel




--
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: [PATCH 3/3] devel/gcc: Check and build GNU sed if not available on build host

[Frank Kühndel]

Hello Chris,

our CI build the tools (rtems-source-builder git) for revision

c0edd80bcd27b3dad7ee7acf5ea129e81e6a6f64 "rtems/jpeg: Update the checksum"

OK and failed for revision

468fc79e8c7c8076e8b65be82ba2009e41dd6c8e "devel/gcc: Check and build GNU 
sed if not available on build host"


with missing dependencies for expat-devel (and as followup gmp-devel). 
Excerpt from the source-builder log:


checking size of unsigned __int128... 16
checking for library containing dlopen... none required
checking whether to use expat... yes
checking for libexpat... no
configure: error: expat is missing or unusable
make[2]: *** [Makefile:10085: configure-gdb] Error 1
make[2]: *** Waiting for unfinished jobs

This happens in an opensuse leap 15.4 container within a build for RTEMS 
6 and ARM BSP. I tested on an almalinux container too and got the same 
error.


"expat" and "gmp" are usually build by the source-builder itself. Hence, 
I wonder whether these new additional dependencies on "expat-devel" and 
"gmp-devel" packages are added by intention or whether this may be a 
unwanted side effect of the patches?


Greetings
Frank

--
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: rtems-central: Error trying to add FACE POSIX Timer Behavior

[Frank Kühndel]

Hi Joel,

as far as I can remember, the error handling of `spec2modules.py` was
never excellent. Adding `notes: null` to
`spec/acfg/if/posix-timer-face-behavior.yml` fixes your problem:


SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
appl-config-option-type: feature-enable
copyrights:
- Copyright (C) 2022 On-Line Applications Research Corporation (OAR)
description: |
  If this configuration option is defined, then POSIX timers may
  not be created to use the CLOCK_REALTIME. Per POSIX, this is allowed
  behavior but per the FACE Technical Standard, using POSIX timers based
  on CLOCK_REALTIME (e.g., time of day) is unsafe for real-time safety
  systems as setting CLOCK_REALTIME will perturb any active timers.

  If this option is not defined, POSIX timers may be created to use the
  CLOCK_REALTIME in compliance with the POSIX specification.
enabled-by: true
index-entries: []
interface-type: appl-config-option
links:
- role: appl-config-group-member
  uid: group-face
name: CONFIGURE_POSIX_TIMERS_FACE_BEHAVIOR
notes: null
type: interface
}}}

Missing non-optional keys, misspelled keys, or keys placed in the wrong
level lead to exceptions in `spec2modules.py` as well as missing values,
or values of wrong type.

In this particular case, I found the problem by comparing
`spec/acfg/if/posix-timer-face-behavior.yml` to files using
`group-filesystem` (e.g. `spec/acfg/if/filesystem-all.yml`).

There is a documentation on specification items:
https://docs.rtems.org/branches/master/eng/req/items.html

The format for your file `spec/acfg/if/posix-timer-face-behavior.yml` is
described in

* section "5.2.2.18. Interface Item Type"
* sub-section "5.2.2.20. Application Configuration Option Item Type"

It states the missing key "notes".

I hope I could help.

Greetings
Frank



On 8/12/22 23:28, Joel Sherrill wrote:
> Hi
> 
> I've just attached the patch as a work in progress since spec2modules.py is
> unhappy with what I've done so far. I'd appreciate some guidance. I checked
> that spec2modules.py ran OK before my changes. I added a group-face and
> hope I did that much right. But something is wrong. Help appreciated.
> 
> $ ./spec2modules.py
> Traceback (most recent call last):
>   File "./spec2modules.py", line 85, in 
> main()
>   File "./spec2modules.py", line 76, in main
> rtemsspec.applconfig.generate(config["appl-config"], item_cache)
>   File "/home/joel/rtems-work/rtems/rtems-central/rtemsspec/applconfig.py",
> line 336, in generate
> _generate(group, options, enabled, sphinx_content)
>   File "/home/joel/rtems-work/rtems/rtems-central/rtemsspec/applconfig.py",
> line 264, in _generate
> content.add_option_notes(content.substitute(item["notes"]))
>   File "/home/joel/rtems-work/rtems/rtems-central/rtemsspec/items.py", line
> 210, in __getitem__
> return self._data[key]
> KeyError: 'notes'
> 
> Thanks.
> 
> --joel

-- 
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: How to automate finding comments in copyright/license block

[Frank Kühndel]

Hi Joel,

it of course depends what exactly you are looking for, what you expect
as output and what patterns to match. May be this is an idea but it
still contains a few false positives in its output:

$ cd rtems
$ fgrep -rn -C 3 'COPYRIGHT' cpukit/ | fgrep -C 3 'P1003'

Relicensing is a formidable and tremendous task. I have a lot of respect
for you and all others working on it.

Greetings
fk


On 8/10/22 15:38, Joel Sherrill wrote:
> I've spotted a few cases like this over the past couple of weeks and wonder
> how we can automate finding them:
> 
> /*
>  *  6.7.7 Wait for Asynchronous I/O Request, P1003.1b-1993, p. 164
>  *
>  *  COPYRIGHT (c) 1989-2007.
>  *  On-Line Applications Research Corporation (OAR).
>  *
> 
> The reference to a page in the very old POSIX standard shouldn't be in this
> block.
> 
> This is ignoring that we probably need to figure out what to do with
> references to the paper copy of the 1993 POSIX standard. That's another
> task.
> 
> And ignoring that there are still many files to relicense.
> 
> --joel

-- 
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: [PATCH rtems-docs 1/1] TFTPFS: New documentation

[Frank Kühndel]

Hello Chris,
Hello Joel,
Hello Sebastian,

many thanks for your reviews and comments. I will send an updated v2 of
this patch. It will take your comments in account.

On 6/7/22 18:56, Joel Sherrill wrote:
> 
> On Sun, Jun 5, 2022 at 8:56 PM Chris Johns  wrote:
> 
>> Hi Frank,
>>
>> Thanks for the documentation and the TFTP file system update.
>>
>> On 4/6/2022 1:22 am, Frank Kuehndel wrote:
>>> From: Frank Kühndel 
>>>
>>> ---
>>>  filesystem/index.rst   |   1 +
>>>  filesystem/trivial_ftp.rst | 638 -
>>>  2 files changed, 636 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/filesystem/index.rst b/filesystem/index.rst
>>> index f4e2ed6..64a2f1d 100644
>>> --- a/filesystem/index.rst
>>> +++ b/filesystem/index.rst
>>> @@ -9,6 +9,7 @@ RTEMS Filesystem Design Guide (|version|).
>>>  .. topic:: Copyrights and License
>>>
>>>  | |copy| 1988, 2015 On-Line Applications Research Corporation (OAR)
>>> +| |copy| 2022 embedded brains GmbH (http://www.embedded-brains.de)
>>>
>>>  .. include:: ../common/license.rst
>>>
>>> diff --git a/filesystem/trivial_ftp.rst b/filesystem/trivial_ftp.rst
>>> index e43c036..f5940c6 100644
>>> --- a/filesystem/trivial_ftp.rst
>>> +++ b/filesystem/trivial_ftp.rst
>>> @@ -3,7 +3,639 @@
>>>  Trivial FTP Client Filesystem
>>>  *
>>>
>>> -This chapter describes the Trivial FTP (TFTP) Client Filesystem.
>>> +This chapter describes the Trivial File Transfer Protocol (TFTP) Client
>>> +Filesystem.  TFTP is designed to be an especially simple protocol which
>>> +uses the User Datagram Protocol (UDP) for data transfer over the
>> Internet.
>>> +Its purpose is to send a single file between to network nodes (client
>> and
>>> +server).  A file can be sent in both directions, i.e. a client can
>> either
>>> +read a file from a server or write a file to the server.
>>>
>>> -This chapter should be written after the IMFS chapter is completed and
>> describe
>>> -the implementation of the TFTP.
>>> +Besides reading or writing a file no other operations are supported.
>> That
>>> +is, one cannot seek the file, not append to the end of a file, not open
>>> +the file for reading and writing at the same time, not list directories,
>>> +not move files and so on.
>>> +
>>> +TFTP is inherent insecure as it does not provide any means for
>>> +authentication or encryption.  Therefore, it cannot be used over the
>> public
>>> +Internet.
>> Recommended or highly recommended to not be used on public networks?

Ok. I change it to "highly recommended".

>>
>>> Nevertheless, it is still widely used to load software and
>>> +configuration data during early boot stages over a Local Area Network
>>> +(LAN).
>> With regard to security the TFTP port is secure and so the server runs as
>> root.
>> In rtems-tools there is a TFTP proxy to provide a central instance that can
>> proxy sessions out to other machines on a network at any port, ie ones
>> that a
>> user can connect with. This works with the rtems-tftp-server also included
>> in
>> rtems-tools. The rtems-tftp-server (and proxy) and in Python so should be
>> portable.

I did not try this server. It seems not to support the windowsize option
anyway.

>>
>>> +
>>> +RTEMS TFTP Filesystem Implementation
>>> +
>>> +
>>> +The RTEMS TFTP filesystem implements a TFTP client which can be used
>>> +through the file system.  With other words, one needs to mount the
>>> +TFTP filesystem and can afterwards open a file for reading or writing
>>> +below that mount point.  The content of that file is then effectively
>>> +read from or written to the remote server.  The RTEMS implementation
>>> +implements the following features:
>>> +
>>> +* RFC 1350 *The TFTP Protocol (Revision 2)*
>>> +* RFC 2347 *TFTP Option Extension*
>>> +* RFC 2348 *TFTP Blocksize Option*
>>> +* RFC 7440 *TFTP Windowsize Option*
>>
> Would you kindly put the URLs for these in?

OK. I add the URLs as links.
> 
> 
>>> +Many simple TFTP server do not support options (RFC 2347). Therefore, in
>>> +case the server rejects the first request with options, the RTEMS client
>>> +makes automatically a second attempt using only the "clas

Re: [PATCH 3/7] TFTPFS: Restore tftpDriver.c

[Frank Kühndel]

Hello Joel, 




From: "Joel Sherrill"  
To: "Frank Kühndel"  
Cc: "rtems-de...@rtems.org"  
Sent: Saturday, June 4, 2022 1:05:25 AM 
Subject: Re: [PATCH 3/7] TFTPFS: Restore tftpDriver.c 

> Is this really just a move/rename? Does it preserve the git blame info? 

This (PATCH 3/7) is really a file "copy/recreate" (git blame info will *NOT* be 
preserved). The move/rename is (at the very beginning of) PATCH 2/7. My 
understanding is, that the git blame info will be "moved" by PATCH 2/7 from 
original file tftpDriver.c to the "copied/moved" tftpfs.c file provided the 
person commiting the patches does not apply the trick described in the link I 
send in the cover letter of this patch set. If that trick is applied both files 
tftpDriver.c and tftpfs.c will have an intact git blame info - at least as long 
as nothing "surprising" like a git rebase happens. 

My feeling is that more original code survived in tftpfs.c than in 
tftpDriver.c. Therefore, in case the trick is not applied (i.e. only one file 
ends up with an intact git blame info) it is preferable that this be tftpfs.c. 

Greetings 
fk 


> --joel 

On Fri, Jun 3, 2022, 10:22 AM Frank Kuehndel < [ 
mailto:frank.kuehn...@embedded-brains.de | frank.kuehn...@embedded-brains.de ] 
> wrote: 


From: Frank Kühndel < [ mailto:frank.kuehn...@embedded-brains.de | 
frank.kuehn...@embedded-brains.de ] > 

--- 
cpukit/libfs/src/ftpfs/tftpDriver.c | 1088 +++ 
1 file changed, 1088 insertions(+) 
create mode 100644 cpukit/libfs/src/ftpfs/tftpDriver.c 

diff --git a/cpukit/libfs/src/ftpfs/tftpDriver.c 
b/cpukit/libfs/src/ftpfs/tftpDriver.c 
new file mode 100644 
index 00..d0eadcf99a 
--- /dev/null 
+++ b/cpukit/libfs/src/ftpfs/tftpDriver.c 
@@ -0,0 +1,1088 @@ 
+/* SPDX-License-Identifier: BSD-2-Clause */ 
+ 
+/** 
+ * @file 
+ * 
+ * Trivial File Transfer Protocol file system (TFTP client) for RFC 1350. 
+ * 
+ * Transfer file to/from remote host 
+ */ 
+ 
+/* 
+ * Copyright (c) 1998 Eric Norum < [ mailto:e...@norum.ca | e...@norum.ca ] > 
+ * 
+ * Modifications to support reference counting in the file system are 
+ * Copyright (c) 2012 embedded brains GmbH. 
+ * 
+ * Redistribution and use in source and binary forms, with or without 
+ * modification, are permitted provided that the following conditions 
+ * are met: 
+ * 1. Redistributions of source code must retain the above copyright 
+ * notice, this list of conditions and the following disclaimer. 
+ * 2. Redistributions in binary form must reproduce the above copyright 
+ * notice, this list of conditions and the following disclaimer in the 
+ * documentation and/or other materials provided with the distribution. 
+ * 
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" 
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE 
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR 
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF 
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS 
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN 
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) 
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE 
+ * POSSIBILITY OF SUCH DAMAGE. 
+ */ 
+ 
+#ifdef HAVE_CONFIG_H 
+#include "config.h" 
+#endif 
+ 
+#include  
+#include  
+#include  
+#include  
+#include  
+#include  
+#include  
+#include  
+#include  
+#include  
+#include  
+#include  
+#include  
+#include  
+#include  
+#include  
+#include  
+ 
+#ifdef RTEMS_NETWORKING 
+#include  
+#endif 
+ 
+#ifdef RTEMS_TFTP_DRIVER_DEBUG 
+int rtems_tftp_driver_debug = 1; 
+#endif 
+ 
+/* 
+ * Range of UDP ports to try 
+ */ 
+#define UDP_PORT_BASE 3180 
+ 
+/* 
+ * Default limits 
+ */ 
+#define PACKET_FIRST_TIMEOUT_MILLISECONDS 400L 
+#define PACKET_TIMEOUT_MILLISECONDS 6000L 
+#define OPEN_RETRY_LIMIT 10 
+#define IO_RETRY_LIMIT 10 
+ 
+/* 
+ * TFTP opcodes 
+ */ 
+#define TFTP_OPCODE_RRQ 1 
+#define TFTP_OPCODE_WRQ 2 
+#define TFTP_OPCODE_DATA 3 
+#define TFTP_OPCODE_ACK 4 
+#define TFTP_OPCODE_ERROR 5 
+ 
+/* 
+ * Largest data transfer 
+ */ 
+#define TFTP_BUFSIZE 512 
+ 
+/* 
+ * Packets transferred between machines 
+ */ 
+union tftpPacket { 
+ /* 
+ * RRQ/WRQ packet 
+ */ 
+ struct tftpRWRQ { 
+ uint16_t opcode; 
+ char filename_mode[TFTP_BUFSIZE]; 
+ } tftpRWRQ; 
+ 
+ /* 
+ * DATA packet 
+ */ 
+ struct tftpDATA { 
+ uint16_t opcode; 
+ uint16_t blocknum; 
+ uint8_t data[TFTP_BUFSIZE]; 
+ } tftpDATA; 
+ 
+ /* 
+ * ACK packet 
+ */ 
+ struct tftpACK { 
+ uint16_t opcode; 
+ uint16_t blocknum; 
+ } tftpACK; 
+ 
+ /* 
+ * ERR

Re: [PATCH] sb/setbuilder: Control buildsets using the --with-* command line option

[Frank Kühndel]

Hello Chris,

On 5/6/22 00:35, Chris Johns wrote:
> On 5/5/2022 10:48 pm, Frank Kühndel wrote:
>> Hi Chris,
>>
>> On 5/5/22 04:52, chr...@rtems.org wrote:
>>> From: Chris Johns 
>>>
>>> - Expand macros in buildset file names
>>>
>>> - Add support to buildsets for `%defineifnot`
>>>
>>> - Update 6 and 7 to support command line build overrides
>>>
>>> Closes #4646
>> Useful feature. Just two comments:
>>
>> 1) There exist other packages. Have these been forgotten or are they
>> irrelevant for this purpose?
>>
>> mips: mipstx39-rtems6-gdb-11.2-x86_64-linux-gnu-1
>> riscv: sis-2.29-x86_64-linux-gnu-1
>> sparc: sis-2.29-x86_64-linux-gnu-1
>> x86_64: grub2-2.06-x86_64-linux-gnu-1
> Not irrelevant, may be forgotten but I would settle on limited time to check 
> all
> possible places, make the changes and test. The pattern to manage this is now
> set so please feel free to post patches with further changes.

I have the same time limits for such task. I just wanted to ensure these
are not accidentally forgotten.

> 
>> 2) Are these new options worth documenting?
> A great question and yes I would love to see this happen.
> 
>> Currently:
>>
>> source-builder/sb-set-builder --help
>> [...]
>> --with- : Add the --with- to the build
>> --without-  : Add the --without- to the build
>> [...]
> The `--with-*` and `--without-*` is modelled after the configure option. There
> is no means to know in the config scripts where and how they are used so there
> is no simple way to produce relevant help messages. Updating the python based 
> on
> script does not seem wise to me.
> 
>> There at least exist the following (from source-builder/config/checks.cfg):
> Yeah and this is what makes it difficult to link back to the python `--help`.
> The parser is too slow to scan all the sources to build a list when --help is 
> used.
> 
> A file in the `source-builder` directory called `help.ini` (or whatever) could
> hold a list that is checked when a with or without macro is referenced in a
> config file might work. If there is no help present a warning is printed. The
> problem is updating the file when an option is removed from the config 
> scripts?
> 
> Another possible solution is to add something like:
> 
>  %help with-rtems-gcc Set the path to a BSET build configuration for GCC
> 
> And a tool could be written to parse the configs and update the file?

I was thinking of the much simpler solution of just adding a fixed text
either to the output of the --help option or into the RTEMS User Manual
and live with some options not being documented. On the other side, you
have a point in generating the list automatically as there seem to exist
quite a number of such --with-/--without- options.

> 
>> #
>> # Process the command line --with-/--without- options.
>> #
>> %{?with_cxx:%define enable_cxx 1}
>> %{?without_cxx:%define enable_cxx 0}
>> %{?with_ada:%define enable_ada 1}
>> %{?without_ada:%define enable_ada 0}
>> %{?with_fortran:%define enable_fortran 1}
>> %{?without_fortran:%define enable_fortran 0}
>> %{?with_java:%define enable_java 1}
>> %{?without_java:%define enable_java 0}
>> %{?with_objc:%define enable_objc 1}
>> %{?without_objc:%define enable_objc 0}
>>
>> (Note: --with-java does not work. GCC configure does not known language
>> "java". See https://gcc.gnu.org/install/configure.html option
>> --enable-languages)
> Please raise a ticket ... a patch would also be welcome? :)

I created https://devel.rtems.org/ticket/4647

> 
> Chris

-- 
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
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] sb/setbuilder: Control buildsets using the --with-* command line option

[Frank Kühndel]

Hi Chris,

On 5/5/22 04:52, chr...@rtems.org wrote:
> From: Chris Johns 
> 
> - Expand macros in buildset file names
> 
> - Add support to buildsets for `%defineifnot`
> 
> - Update 6 and 7 to support command line build overrides
> 
> Closes #4646

Useful feature. Just two comments:

1) There exist other packages. Have these been forgotten or are they
irrelevant for this purpose?

mips: mipstx39-rtems6-gdb-11.2-x86_64-linux-gnu-1
riscv: sis-2.29-x86_64-linux-gnu-1
sparc: sis-2.29-x86_64-linux-gnu-1
x86_64: grub2-2.06-x86_64-linux-gnu-1

2) Are these new options worth documenting? Currently:

source-builder/sb-set-builder --help
[...]
--with- : Add the --with- to the build
--without-  : Add the --without- to the build
[...]

There at least exist the following (from source-builder/config/checks.cfg):

#
# Process the command line --with-/--without- options.
#
%{?with_cxx:%define enable_cxx 1}
%{?without_cxx:%define enable_cxx 0}
%{?with_ada:%define enable_ada 1}
%{?without_ada:%define enable_ada 0}
%{?with_fortran:%define enable_fortran 1}
%{?without_fortran:%define enable_fortran 0}
%{?with_java:%define enable_java 1}
%{?without_java:%define enable_java 0}
%{?with_objc:%define enable_objc 1}
%{?without_objc:%define enable_objc 0}

(Note: --with-java does not work. GCC configure does not known language
"java". See https://gcc.gnu.org/install/configure.html option
--enable-languages)

Greetings
fk

-- 
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
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: Feature list only in user guide

[Frank Kühndel]

Hi Joel,

On 4/28/22 18:15, Joel Sherrill wrote:
> On Thu, Apr 28, 2022 at 8:53 AM Frank Kühndel <
> frank.kuehn...@embedded-brains.de> wrote:
> 
>> Hello,
>>
>> I was looking for a list of RTEMS Features (e.g. supported language,
>> drives, BSPs, etc.) I expected it on www.rtems.org and did not find
>> anything till a college of mine pointed me to the excellent list in the
>> RTEMS User Manual:
>>
>> https://docs.rtems.org/branches/master/user/overview/index.html#features
>>
>> I would expect that a potential interested new RTEMS user would search
>> such a list on the project home-page or maybe in the wiki. From a
>> marketing point of view, would it not make sense to place this list or a
>> link to it prominently on the home page?
>>
> It should be checked to be sure it is up to date and definitely covered
> somewhere prominent.  It looks like the page we long time folks likely
> think is very prominent and accessible isn't anymore. Before Trac, the
> top entry page of the Wiki was this type of overview with features. I
> think I found the page here in the TBR section of the Wiki.
> 
> https://devel.rtems.org/wiki/TBR/Website/What_is_RTEMS
> 
> This page (and maybe some others) likely need a refresh/rework
> and linked from the top of devel.rtems.org. If you just want info and
> are not trying to file a bug, that entry page is just not helping.

... and from www.rtems.org?

A simple link to a feature list would be good and an easy start.
Consolidating and updating the feature list(s) would - of course - be
great but such activities often have low priorities and a
not-so-up-to-date list now is better than a perfect-up-to-date list in
months (or even years?).

By the way, in the older "What_is_RTEMS" list the network stack is more
prominently placed and notes network service like DHCP, FTPD, TFTP,
SNMP. I could imagine this is something a potential new RTEMS user may
also be looking for.

> 
> I'm also curious how you think it compares to the list of things used in
> the first RTEMS manuals (early 90s). This is the proceedings with the first
> published paper on RTEMS (Aug 1990) and a lot of what is in the manuals
> as background first appeared in this paper. I expect you will recognize
> early versions of figures and love the font. It looks old. See page 247 in
> the PDF.
> 
> https://web.archive.org/web/20170218223058/http://www.dtic.mil/dtic/tr/fulltext/u2/a247043.pdf
> 
> I need to trim it and upload it to rtems.org.

So, that is the history! Very nice indeed. Well worth to keep it on the
home page.

It reads like an introduction to computer science. What is
embedded-computing? How does a Scheduler work? How to use semaphores for
mutual exclusion? How to layout memory for tasks, stacks, global
variables and the heap? ...

Interestingly, its set of managers was almost complete 32 years ago. It
only missed five managers:

* Rate-Monotonic-Manager,
* Barrier-Manager,
* User-Extension-Manager,
* Cache-Manager and
* Multi-Processing-Manager

Greetings
fk

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

Feature list only in user guide

[Frank Kühndel]

Hello,

I was looking for a list of RTEMS Features (e.g. supported language,
drives, BSPs, etc.) I expected it on www.rtems.org and did not find
anything till a college of mine pointed me to the excellent list in the
RTEMS User Manual:

https://docs.rtems.org/branches/master/user/overview/index.html#features

I would expect that a potential interested new RTEMS user would search
such a list on the project home-page or maybe in the wiki. From a
marketing point of view, would it not make sense to place this list or a
link to it prominently on the home page?

Just a thought
fk

-- 
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
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: GCC version for RTEMS 6? (Can Ada be used?)

[Frank Kühndel]

Hello,

On 4/27/22 20:22, Joel Sherrill wrote:
> On Wed, Apr 27, 2022 at 1:12 PM Frank Kühndel <
> frank.kuehn...@embedded-brains.de> wrote:
> 
>> Hi Karel,
>>
>> On 4/27/22 19:46, Karel Gardas wrote:
>>> On 4/27/22 19:25, Frank Kühndel wrote:
>>>> I do not need ADA but ADA may be worth considering. With GCC 10 one
>>>> needed to have a GNAT 10 compiler installed to build the tools incl.
>>>> --with_ada. I presume, one would need a GNAT 12 to build ADA with the
>>>> GCC 12 sources? The current Fedora 35 has GNAT 11. All other distros I
>>>> know of have GNAT 10 at best (I have not checked on tumbleweed yet).
>>>> OpenSUSE may get ADA 12 from an unusual repro???
>>> On https://gcc.gnu.org/install/prerequisites.html there is a text:
>>>
>>> "
>>> GNAT
>>>
>>> In order to build GNAT, the Ada compiler, you need a working GNAT
>>> compiler (GCC version 5.1 or later).
>>>
>>> ...
>>> "
>>>
>>> is it outdated? If so, this would require some bugreport to gcc team?
>> The text says too: "Other native compiler versions may work but this is
>> not guaranteed and will typically fail with hard to understand
>> compilation errors during the build."
>>
>> I tried last year to build the tools "--with_ada" on Ubuntu, OpenSUSE,
>> Fedora, AlmaLinux and Debian. Moreover, I tried all versions of GNAT
>> each of the OS offered "normal" users to install. Only GNAT 10 worked
>> for me. Nothing else.
>>
>> The text in the chapter your cited can be understood this way: Compiling
>> ADA with a native compiler of the same version will work. If the native
>> compiler has a higher version it, is rather unlikely to work. If the
>> native compiler has a lower version, it may work or not. So, I do not
>> think you can file a bug with GCC.
>>
> When I more regularly built Ada, I always used the native Ada compiler
> to build the same version of GCC I was going to use with RTEMS natively
> with  Ada enabled. I didn't care what version of GCC/Ada was from the OS.
> 
> + OS GCC/Ada ->
> +  native using RTEMS GCC version
> + cross compiler for RTEMS with Ada

With "native using RTEMS GCC version" you mean you downloaded the
official GCC tar-ball and build an Ada compiler following the
README/Install instructions?

I was always thinking that building an Ada non-cross compiler would run
into the same errors as building an Ada cross compiler. Interesting. I
have no time to test it right now but I will write it on my list and
give it a try.

In case that will work, Karel would be right. The RSB should at least
check the GNAT Version and issue a warning or error instead of letting
users marvel around why the Ada cross compiler failed to build with a
bizarre error.

> 
> At least now you don't have to build RTEMS to have some headers and
> libraries before you build Ada. Long ago, you had to build a cross C/C++
> compiler first to build RTEMS, then use the RTEMS libraries as part of
> building the toolchain with Ada.
> 
> Also as I mentioned to Sebastian privately, Ada is likely to build for
> all targets except those where float and double are the same size. I
> only remember sh as having a multilib like this but I feel like there
> is another case.

I tried on all targets and Ada does not build on sh and lm32 (tested on
Ubuntu, Debian, OpenSUSE with RTEMS 6 and GNAT 10).

Greetings
fk

 Ada on Sh failure (Debian 11) 

../gcc-interface/Makefile:299: update target 's-soflin.o' due to:
s-soflin.adb
/home/minna/src/rtems-source-builder/rtems/build/sh-rtems6-gcc-0f001dd-newlib-64
b2081-x86_64-linux-gnu-1/build/./gcc/xgcc
-B/home/minna/src/rtems-source-builder
/rtems/build/sh-rtems6-gcc-0f001dd-newlib-64b2081-x86_64-linux-gnu-1/build/./gcc
/ -nostdinc
-B/home/minna/src/rtems-source-builder/rtems/build/sh-rtems6-gcc-0f0
01dd-newlib-64b2081-x86_64-linux-gnu-1/build/sh-rtems6/newlib/ -isystem
/home/mi
nna/src/rtems-source-builder/rtems/build/sh-rtems6-gcc-0f001dd-newlib-64b2081-x8
6_64-linux-gnu-1/build/sh-rtems6/newlib/targ-include -isystem
/home/minna/src/rt
ems-source-builder/rtems/build/sh-rtems6-gcc-0f001dd-newlib-64b2081-x86_64-linux
-gnu-1/gnu-mirror-gcc-0f001dd/newlib/libc/include
-B/opt/rtems/6/sh-rtems6/bin/
-B/opt/rtems/6/sh-rtems6/lib/ -isystem /opt/rtems/6/sh-rtems6/include
-isystem /
opt/rtems/6/sh-rtems6/sys-include-c -g -O2 -m4-single-only  -W -Wall
-gnatpg
 -nostdinc -m4-single-only  s-soflin.adb -o s-soflin.o
s-scaval.adb:103:07: warning: "IV_Ilf" overlays smaller object
s-scaval.adb:103:07: warning: program execution may be erroneous
s-scaval.adb:103:07: warning: size of "IV_Ilf" is 64
s-

Re: GCC version for RTEMS 6? (Can Ada be used?)

[Frank Kühndel]

Hi Karel,

On 4/27/22 19:46, Karel Gardas wrote:
> On 4/27/22 19:25, Frank Kühndel wrote:
>> I do not need ADA but ADA may be worth considering. With GCC 10 one
>> needed to have a GNAT 10 compiler installed to build the tools incl.
>> --with_ada. I presume, one would need a GNAT 12 to build ADA with the
>> GCC 12 sources? The current Fedora 35 has GNAT 11. All other distros I
>> know of have GNAT 10 at best (I have not checked on tumbleweed yet).
>> OpenSUSE may get ADA 12 from an unusual repro???
> 
> On https://gcc.gnu.org/install/prerequisites.html there is a text:
> 
> "
> GNAT
> 
>     In order to build GNAT, the Ada compiler, you need a working GNAT
> compiler (GCC version 5.1 or later).
> 
> ...
> "
> 
> is it outdated? If so, this would require some bugreport to gcc team?

The text says too: "Other native compiler versions may work but this is
not guaranteed and will typically fail with hard to understand
compilation errors during the build."

I tried last year to build the tools "--with_ada" on Ubuntu, OpenSUSE,
Fedora, AlmaLinux and Debian. Moreover, I tried all versions of GNAT
each of the OS offered "normal" users to install. Only GNAT 10 worked
for me. Nothing else.

The text in the chapter your cited can be understood this way: Compiling
ADA with a native compiler of the same version will work. If the native
compiler has a higher version it, is rather unlikely to work. If the
native compiler has a lower version, it may work or not. So, I do not
think you can file a bug with GCC.

Greetings
fk
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GCC version for RTEMS 6? (Can Ada be used?)

[Frank Kühndel]

Hello Sebastian,

On 4/27/22 11:54, Sebastian Huber wrote:
>> we have to select a GCC version for the RTEMS 6 release. Currently,
>> GCC 10 is used, however, with the release of GCC 10.4 this year it
>> will reach its end of life. Other options are GCC 11 and 12. GCC 12
>> will be released in the next weeks. It has some nice features:
>>
>> * Initialization of stack variables:
>>
>> https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-ftrivial-auto-var-init
>>
>>
>> * Improved static analysis with -fanalyzer
>>
>> * Improved gcov support, with the ability to back port changes from
>> GCC 13:
>>
>> https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593536.html
>>
>> * Upstream maintenance for the next three years
>>
>> The draw back is that it is brand new.
> 
> The Ada support is broken in GCC 12 for most targets:

I do not need ADA but ADA may be worth considering. With GCC 10 one
needed to have a GNAT 10 compiler installed to build the tools incl.
--with_ada. I presume, one would need a GNAT 12 to build ADA with the
GCC 12 sources? The current Fedora 35 has GNAT 11. All other distros I
know of have GNAT 10 at best (I have not checked on tumbleweed yet).
OpenSUSE may get ADA 12 from an unusual repro???

So, if I am not mistaken, switching to GCC 12 will have the effect that
the "normal" RTEMS ADA user will for quite a while not be able to build
ADA. I am not sure how important that would be.

Greetings
fk
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2 2/2] gdb: Split python's version into major/minor and check for embed option

[Frank Kühndel]

9:  _ifs[2]: %endif:
dir=None %endif False []
config: source-builder/config/gdb-common-1.cfg: 119:  _if[1]: []
config: source-builder/config/gdb-common-1.cfg: 120:>%define
gdb-python-config-libs %(%{gdb-python-config}
%{gdb-python-config-lib-check-flags} | %{gdb-python-lib-filter}) [True]
exe: shell: /usr/bin/python3-config --ldflags | awk 'BEGIN{FS="
"}/python/{for(i=1;i%if
%{gdb-python-ver-major}
 < 3 ||  %{gdb-python-ver-major} == 3 && %{gdb-python-ver-minor} < 8 [True]
config: source-builder/config/gdb-common-1.cfg: 115:  _if[1]: ['2', '<',
'3', '|
|', '2', '==', '3', '&&', '7', '<', '8']
config: source-builder/config/gdb-common-1.cfg: 115:  _if[2}: OR found at 3
config: source-builder/config/gdb-common-1.cfg: 115:  _if[2]: AND found at 7
config: source-builder/config/gdb-common-1.cfg: 115:  _if[2]: next OP
found at 3
config: source-builder/config/gdb-common-1.cfg: 115:  _if: numeric value
check
config: source-builder/config/gdb-common-1.cfg: 115:  _if[2]:  ('2',
'<', '3') True none True
config: source-builder/config/gdb-common-1.cfg: 115:  _if[2]: joining: or
config: source-builder/config/gdb-common-1.cfg: 115:  _if[2]: OR true,
short circuit eval
config: source-builder/config/gdb-common-1.cfg: 115:  _ifs[2]: dir=None
3 ['2', '<', '3']
config: source-builder/config/gdb-common-1.cfg: 116:>%define
gdb-python-config-lib-check-flags --ldflags [True]
config: source-builder/config/gdb-common-1.cfg: 117:>%else [True]
config: source-builder/config/gdb-common-1.cfg: 118: %define
gdb-python-config-lib-check-flags --ldflags --embed [False]
config: source-builder/config/gdb-common-1.cfg: 119: %endif [False]
config: source-builder/config/gdb-common-1.cfg: 119:  _ifs[2]: %endif:
dir=None %endif False []
config: source-builder/config/gdb-common-1.cfg: 119:  _if[1]: []
config: source-builder/config/gdb-common-1.cfg: 120:>%define
gdb-python-config-libs %(%{gdb-python-config}
%{gdb-python-config-lib-check-flags} | %{gdb-python-lib-filter}) [True]
exe: shell: /usr/bin/python2-config --ldflags | awk 'BEGIN{FS="
"}/python/{for(i=1;i%define
gdb-python-lib-check %(%{_sbdir}/sb/rtems-build-dep -c %{__cc}
%{gdb-host-libs} -l %{gdb-python-config-libs}) [True]
exe: shell:
/home/minna/src/rtems-source-builder/source-builder/sb/rtems-build-dep
-c gcc  -l libpython2.7*
exe:
/home/minna/src/rtems-source-builder/source-builder/sb/rtems-build-dep
-c gcc  -l libpython2.7*
shell-output: 0 found


-- 
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
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/2] gdb: Split python's version into major/minor and check for embed option

[Frank Kühndel]

Hi Chris,

I tested your two patches for ARM on top of
990e3f05e62cf48117f6de8346e9ea8a8d9b1ba3 (Git master
rtems-source-builder, RTEMS 6) on the following OS:

* openSUSE Leap 15.3 Python 2.7.18
* openSUSE Leap 15.3 Python 3.6.15
* Ubuntu 22.04 LTS Python 3.10.4
* AlmaLinux 8.5 (Arctic Sphynx) Python 3.6.8
* Debian GNU/Linux 11 (bullseye) Python 3.9.2
* Fedora Linux 35 (Container Image) Python 3.10.4

Everything worked fine. But inspecting the code, I wonder about this line:

%if %{gdb-python-ver-major} <= 3 && %{gdb-python-ver-minor} < 8

What if the Python version would be 2.9? (No, I do not I believe that I
will ever see Python 2.8 or 2.9.)

Many thanks for your efforts
fk



This is the output from the RSB log on Fedora:

config: source-builder/config/gdb-common-1.cfg: 114:>%if
%{gdb-python-ver-major}
 <= 3 && %{gdb-python-ver-minor} < 8 [True]
config: source-builder/config/gdb-common-1.cfg: 114:  _if[1]: ['3',
'<=', '3', '
&&', '10', '<', '8']
config: source-builder/config/gdb-common-1.cfg: 114:  _if[2]: AND found at 3
config: source-builder/config/gdb-common-1.cfg: 114:  _if[2]: next OP
found at 3
config: source-builder/config/gdb-common-1.cfg: 114:  _if: numeric value
check
config: source-builder/config/gdb-common-1.cfg: 114:  _if[2]:  ('3',
'<=', '3') True none True
config: source-builder/config/gdb-common-1.cfg: 114:  _if[2]: joining: and
config: source-builder/config/gdb-common-1.cfg: 114:  _if: numeric value
check
config: source-builder/config/gdb-common-1.cfg: 114:  _if[2]:  ('10',
'<', '8') False and False
config: source-builder/config/gdb-common-1.cfg: 114:  _ifs[2]: dir=None
3 ['10', '<', '8']
config: source-builder/config/gdb-common-1.cfg: 115: %define
gdb-python-config-lib-check-flags --ldflags [False]
config: source-builder/config/gdb-common-1.cfg: 116: %else [False]
config: source-builder/config/gdb-common-1.cfg: 117:>%define
gdb-python-config-lib-check-flags --ldflags --embed [True]
config: source-builder/config/gdb-common-1.cfg: 118:>%endif [True]
config: source-builder/config/gdb-common-1.cfg: 118:  _ifs[2]: %endif:
dir=None %endif True []
config: source-builder/config/gdb-common-1.cfg: 118:  _if[1]: []
config: source-builder/config/gdb-common-1.cfg: 119:>%define
gdb-python-config-libs %(%{gdb-python-config}
%{gdb-python-config-lib-check-flags} | %{gdb-python-lib-filter}) [True]
exe: shell: /usr/bin/python3-config --ldflags --embed | awk 'BEGIN{FS="
"}/python/{for(i=1;i%if
%{gdb-python-ver-major} <= 3 && %{gdb-python-ver-minor} < 8 [True]
config: source-builder/config/gdb-common-1.cfg: 114:  _if[1]: ['3',
'<=', '3', '&&', '6', '<', '8']
config: source-builder/config/gdb-common-1.cfg: 114:  _if[2]: AND found at 3
config: source-builder/config/gdb-common-1.cfg: 114:  _if[2]: next OP
found at 3
config: source-builder/config/gdb-common-1.cfg: 114:  _if: numeric value
check
config: source-builder/config/gdb-common-1.cfg: 114:  _if[2]:  ('3',
'<=', '3') True none True
config: source-builder/config/gdb-common-1.cfg: 114:  _if[2]: joining: and
config: source-builder/config/gdb-common-1.cfg: 114:  _if: numeric value
check
config: source-builder/config/gdb-common-1.cfg: 114:  _if[2]:  ('6',
'<', '8') True and True
config: source-builder/config/gdb-common-1.cfg: 114:  _ifs[2]: dir=None
3 ['6', '<', '8']
config: source-builder/config/gdb-common-1.cfg: 115:>%define
gdb-python-config-lib-check-flags --ldflags [True]
config: source-builder/config/gdb-common-1.cfg: 116:>%else [True]
config: source-builder/config/gdb-common-1.cfg: 117: %define
gdb-python-config-lib-check-flags --ldflags --embed [False]
config: source-builder/config/gdb-common-1.cfg: 118: %endif [False]
config: source-builder/config/gdb-common-1.cfg: 118:  _ifs[2]: %endif:
dir=None %endif False []
config: source-builder/config/gdb-common-1.cfg: 118:  _if[1]: []
config: source-builder/config/gdb-common-1.cfg: 119:>%define
gdb-python-config-libs %(%{gdb-python-config}
%{gdb-python-config-lib-check-flags} | %{gdb-python-lib-filter}) [True]
exe: shell: /usr/bin/python3-config --ldflags | awk 'BEGIN{FS="
"}/python/{for(i=1;i%if
%{gdb-python-ver-major} <= 3 && %{gdb-python-ver-minor} < 8 [True]
config: source-builder/config/gdb-common-1.cfg: 114:  _if[1]: ['2',
'<=', '3', '&&', '7', '<', '8']
config: source-builder/config/gdb-common-1.cfg: 114:  _if[2]: AND found at 3
config: source-builder/config/gdb-common-1.cfg: 114:  _if[2]: next OP
found at 3
config: source-builder/config/gdb-common-1.cfg: 114:  _if: numeric value
check
config: source-builder/config/gdb-common-1.cfg: 114:  _if[2]:  ('2',
'<=', '3') True none True
config: source-builder/config/gdb-common-1.cfg: 114:  _if[2]: joining: and
config: source-builder/config/gdb-common-1.cfg: 114:  _if: numeric value
check
config: source-builder/config/gdb-common-1.cfg: 114:  _if[2]:  ('7',
'<', '8') True and True
config: source-builder/config/gdb-common-1.cfg: 114:  _ifs[2]: dir=None
3 ['7', '<', '8']
config: source-builder/config/gdb-common-1.cfg: 115:>%define

Re: [PATCH] GDB: fix python config command line arguments based on python version

[Frank Kühndel]

Hi Chris,

On 4/22/22 03:19, Chris Johns wrote:
> On 21/4/2022 5:45 pm, Karel Gardas wrote:
>> On 4/21/22 02:12, Chris Johns wrote:
>>> On 21/4/2022 4:38 am, Karel Gardas wrote:
>>>> Chris, Frank,
>>>>
>>>> I don't feel particularly comfortable with this patch. It works here on 
>>>> Ubuntu
>>>> 20.04 with python 3.3 and Ubuntu 22.04 with Python 3.10, but I have to 
>>>> admit
>>>> semantics of this cfg language is beyond my liking and a lot is in complete
>>>> darkness here. E.g. how &&, < operator are working here. Delete both int
>>>> conversions and it'll not work at all. Keep one and it'll work well.
>>>> The problem is probably lack of time to go thorough all the docs on
>>>> docs.rtems.org to find relevant bits while working on the patch.
>>>>
>>>> Anyway, if you have time, please review and test on your platforms.
>>> I think you are right to be concerned. I cannot find in the parser any 
>>> support
>>> for `int()` which makes me wonder if `int(3)` is being compared but I am not
>>> sure.
>> Hmm. And I've thought cfg format is just DSL interpreted in python hence
>> translated internally to python hence my int() usage.
>>
>>> Leave this with me and I will take a closer look.
>> Absolutely!
>>
>>> I think we will need to add a
>>> numerical compare. Hmmm.
>> Another solution may be to enhance version string to print every number with 
>> two
>> digits and with leading zero if needed and concatenate string together. This 
>> may
>> probably work too even with lexi comparison.
>> E.g.
>>
>> 2.7.1  -> "020701"
>> 2.7.17 -> "020717"
>> 3.9.2  -> "030902"
>> 3.10.3 -> "031003"
>>
>> Hard to judge which approach is cleanest one.
> This breaks when we exceed 99 etc. Maybe that will happen, maybe it will not.

> I wonder if hacking the parser to handle this provides a more long term 
> solution
> beyond this use case.
> 
> The problem becomes adding support to the language. I wonder if checking if 
> both
> the left and right hand sides in a compare are numeric, ie 3 or 3.0, and if 
> they
> are make the comparison numeric? To force a lexicographical comparison simply
> have `%if x%{yyy} < 3.8`?

Do not exists simpler solutions than changing the language?

For example, calling `/usr/bin/python3-config --help` first. If the
result string contains `--embed` use it, else don't.

For example on OpenSUSE (Python 3.6.15):

$  /usr/bin/python3-config --help
Usage: /usr/bin/python3-config
--prefix|--exec-prefix|--includes|--libs|--cflags|--ldflags|--extension-suffix|--help|--abiflags|--configdir

On Fedora 35 (Python 3.10.4):

$ /usr/bin/python3-config --help
Usage: /usr/bin/python3.10-x86_64-config
--prefix|--exec-prefix|--includes|--libs|--cflags|--ldflags|--extension-suffix|--help|--abiflags|--configdir|--embed

Again OpenSUSE but Python 2.7.18:

$ /usr/bin/python2-config --help
Usage: /usr/bin/python2-config
[--prefix|--exec-prefix|--includes|--libs|--cflags|--ldflags|--help]

For example, the following command will either return "--embed" or empty
(the redirection of strerr is important for Python 2):

$ /usr/bin/python3-config --help 2>1 | grep --fixed-strings
--only-matching -e --embed

Greetings,
fk

-- 
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
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] GDB: fix python config command line arguments based on python version

[Frank Kühndel]

Hi Karel,

On 4/20/22 20:38, Karel Gardas wrote:
> Chris, Frank,
> 
> I don't feel particularly comfortable with this patch. It works here on
> Ubuntu 20.04 with python 3.3 and Ubuntu 22.04 with Python 3.10, but I
> have to admit semantics of this cfg language is beyond my liking and a
> lot is in complete darkness here. E.g. how &&, < operator are working
> here. Delete both int conversions and it'll not work at all. Keep one
> and it'll work well.
> The problem is probably lack of time to go thorough all the docs on
> docs.rtems.org to find relevant bits while working on the patch.
> 
> Anyway, if you have time, please review and test on your platforms.

I am rather sorry to write this but your patch does not work for me. The
before failing build on "Fedora Linux 35 (Container Image)" with Python
3.10.4 works fine with your patch. Yet, the "openSUSE Leap 15.3"
container with Python 3.6.15 (which was building OK without this patch)
fails now:

11:32:00  config: tools/rtems-gdb-11.2.cfg
11:32:00  error: shell macro failed:
/home/minna/src/rtems-source-builder/source-builder/sb/rtems-build-dep
-c gcc  -l : 2: error: no library (-l) provided
11:32:00  Build FAILED
11:32:00  Build Set: Time 0:00:37.716473

Some notes: The "RTEMS User Manual" Section "14.5.8.21. %if"

  https://docs.rtems.org/branches/master/user/rsb/configuration.html#if

states:

  "< The left hand side is numerically less than the
 right hand side."

  "<= The left hand side is numerically less than or
  equal to the right hand side."

According to this, it is never a lexicographical comparison. 3.10 is 3.1
as floating number and thus 3.1 < 3.8 holds true. What I do not know is
whether the tool uses integers or real numbers nor whether the
documentation is up to date. The `&&` and the `int()` are _not_
documented there. The `&&` is actually used in .cfg-files but
surprisingly seldom. Moreover, this command may help debugging:

   `%{echo message}`  Print the following string as a message.

Greetings,
fk

-- 
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
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: RSB Issue with lexicographic comparison of python versions (shown on Ubuntu 22.04 LTS/python 3.10 platform).

[Frank Kühndel]

Hello,

just as note, I have already opened a ticked for this issue:

   https://devel.rtems.org/ticket/4631

Greetings
fk

On 4/19/22 12:06, Karel Gardas wrote:
> testing RSB on soon to be release Ubuntu 22.04 LTS. This distro provides
> python 3.10 and interestingly gdb compilation fails badly on it with:
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Awk error when building tools on Mingw64

[Frank Kühndel]

Hello Ryan,

I believe I have a different error than yours on a "Fedora Linux 35
Container" but my error is exactly at the same place as yours.

But to your problem:

It looks like the `$i` has been replaced nothing by substitution.
Compare the output:

At the top: `[...]match($i,\".*lpython.*\")[...]`
In the error message below: `[...]match(,".*lpython.*")[...]`

It looks like `awk` gets the command line without `$i`.

The problem is likely in file source-builder/config/gdb-common-1.cfg
line 111 and line 117. May I suggest to try to comment out line 117 and
118 with an `#` (or replace them somehow). Then the gdb should build.

The question is why the `$i` disappears? I have seen such things in
Makefiles. There, you would need to write `$$i` to prevent substitution.
Does "Mingw64" use an unusual `sh`? Maybe replacing all `sh` with a link
to `bash` solves this?

Greetings,
fk


On 3/17/22 15:55, Ryan Long wrote:
> Subject:
> Awk error when building tools on Mingw64
> From:
> Ryan Long 
> Date:
> 3/17/22, 15:55
> 
> To:
> devel@rtems.org
> 
> 
> Hello,
> 
> I'm trying to build the Aarch64 tools on Mingw64. When building gdb, I
> am getting the following error.
> 
> config: tools/rtems-gdb-10.cfg
> error: shell macro failed: sh -c "/mingw64/bin/python2-config --ldflags
> | awk 'BEGIN{FS=\"
> \"}/python/{for(i=1;i \"lib\"substr($i,3)\"*\";}'": 1: awk: cmd. line:1: BEGIN{FS="
> "}/python/{for(i=1;i "lib"substr(,3)"*";}
> awk: cmd. line:1: ^ syntax error
> awk: cmd. line:1: BEGIN{FS="
> "}/python/{for(i=1;i "lib"substr(,3)"*";}
> awk: cmd. line:1: ^ 1 is invalid as number of arguments for match
> 
> I made a file to store this command like so
> 
>   BEGIN {FS=" "}
> 
>   /python/ {
> for(i=1;i if(match($i,".*lpython.*"))
>     print "lib"substr($i,3)"*"
>   }
> 
> and ran it with the command "python2-config --ldflags | awk -f
> test.awk". It produces "libpython2.7*" as the output. The only
> difference between the two is I took out the "\"s since it's not being
> run on the command line.
> 
> Does anyone have any ideas what might be going on? And how do we go
> about fixing this when the solution is found?
> 
> Thanks,
> 
> Ryan
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

-- 
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
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 1/1] libtftpfs: Change to BSD-2-Clause license

[Frank Kühndel]

Hi Sebastian,

On 3/15/22 17:46, Sebastian Huber wrote:
> On 15/03/2022 17:27, Frank Kuehndel wrote:
>> + * Copyright (C) W. Eric Norum
> 
> Copyright statements should have a year. You can use the Git history to
> get it.

Yes, I know. But I can only trace the history back to

commit 39e6e65a2c5a3312f365d59f23c469641e049c82
Author: Joel Sherrill 
Date:   Wed Aug 19 21:32:28 1998 +

This commit is apparently not the one for the author. I can only guess:
These files where imported from FreeBSD??? - and most likely from
another RCS??? They originally contain the famous CVS and SVN tag $Id$
(without date unfortunately).

Hence, I concluded the simplest solution is not to provide the year.

Greetings,
fk

-- 
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
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] c-user: Fix message manager documentation

[Frank Kühndel]

On 9/14/21 5:52 PM, Sebastian Huber wrote:
> Remove bogus return status from rtems_message_queue_receive().  Clarify
> rtems_message_queue_flush().
> 
> Close #4508.
> ---
>  c-user/message/directives.rst | 19 ++-
>  1 file changed, 10 insertions(+), 9 deletions(-)
> 
> diff --git a/c-user/message/directives.rst b/c-user/message/directives.rst
> index f320350..7317eb4 100644
> --- a/c-user/message/directives.rst
> +++ b/c-user/message/directives.rst
> @@ -891,10 +891,6 @@ queue.
>  :c:macro:`RTEMS_UNSATISFIED`
>  The queue was empty.
>  
> -:c:macro:`RTEMS_UNSATISFIED`
> -The queue was flushed while the calling task was waiting to receive a
> -message.
> -
>  :c:macro:`RTEMS_TIMEOUT`
>  The timeout happened while the calling task was waiting to receive a
>  message
> @@ -1039,17 +1035,22 @@ present on the queue, count is set to zero.
>  The ``count`` parameter was `NULL
>  `_.
>  
> +.. rubric:: NOTES:
> +
> +The directive does not flush tasks waiting to receive a message from the
> +:term:`wait queue` of the message queue.
> +
>  .. rubric:: CONSTRAINTS:
>  
>  The following constraints apply to this directive:
>  
> -* The directive may be called from within task context.
> -
>  * The directive may be called from within interrupt context.
>  
> -* When the directive operates on a remote object, the directive sends a 
> message
> -  to the remote node and waits for a reply.  This will preempt the calling
> -  task.
> +* The directive may be called from within device driver initialization 
> context.
> +
> +* The directive may be called from within task context.
> +
> +* The directive will not cause the calling task to be preempted.
>  
>  .. Generated from spec:/rtems/message/if/buffer

Hi Sebastian,

the text for the `count` parameter needs to be changed too. Currently it
says:

| count
|
| This parameter is the pointer to an uint32_t object. When the
| directive call is successful, the number of unblocked tasks will be
| stored in this object.

It should instead read:

| count
|
| This parameter is the pointer to an uint32_t object. When the
| directive call is successful, the number of messages removed will be
| stored in this object.

Greetings
fk




___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2 12/12] c-user: Generate clock manager documentation

[Frank Kühndel]

river is a driver which provides the :term:`clock tick` 
> and a
> +time counter.  The time counter is used to drive the 
> :term:`CLOCK_REALTIME`
> +and :term:`CLOCK_MONOTONIC`.  The Clock Driver can be initialized by 
> the
> +application with the :ref:`CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER` 
> and
> +:ref:`CONFIGURE_MICROSECONDS_PER_TICK` application configuration 
> options.
> +
> +clock tick
> +The clock tick is a coarse time measure provided by RTEMS.  The
> +:term:`Clock Driver` emits clock ticks at rate specified by the
> +:ref:`CONFIGURE_MICROSECONDS_PER_TICK` application configuration 
> option.  In
> +contrast to :term:`CLOCK_REALTIME` and :term:`CLOCK_MONOTONIC`, the 
> clock
> +tick rate is not affected by incremental adjustments.
> +
> +CLOCK_MONOTONIC
> +The CLOCK_MONOTONIC is a clock provided by RTEMS which measures the 
> time
> +since an unspecified starting point.  In contrast to 
> :term:`CLOCK_REALTIME`,
> +this clock cannot be set.  It may be affected by incremental 
> adjustments for
> +example carried out by the :term:`NTP` or the use of a :term:`PPS` 
> signal.
> +See also :term:`CLOCK_REALTIME`, :term:`clock tick`, and
> +:term:`Clock Driver`.
> +
> +CLOCK_REALTIME
> +The CLOCK_REALTIME is a clock provided by RTEMS which measures the 
> real time
> +(also known as wall-clock time).  It is defined by :term:`POSIX`.  In
> +particular, every day is treated as if it contains exactly 86400 
> seconds and
> +leap seconds are ignored.  This clock can be set by the application 
> which may
> +result in time jumps.  It may be affected by incremental adjustments 
> for
> +example carried out by the :term:`NTP` or the use of a :term:`PPS` 
> signal.
> +RTEMS can represent time points of this clock in nanoseconds ranging 
> from
> +1988-01-01T00:00:00.0Z to 2514-05-31T01:53:03.9Z.  
> See also
> +:term:`CLOCK_MONOTONIC`, :term:`clock tick`, and :term:`Clock 
> Driver`.
> +
>  cluster
>  We have clustered scheduling in case the set of processors of a 
> system is
>  partitioned into non-empty pairwise disjoint subsets.  These subsets 
> are
> @@ -458,6 +491,10 @@ Glossary
>  non-existent
>  The state occupied by an uncreated or deleted task.
>  
> +NTP
> +This term is an acronym for
> +`Network Time Protocol 
> <https://en.wikipedia.org/wiki/Network_Time_Protocol>`_.
> +
>  NUMA
>  This term is an acronym for Non-Uniform Memory Access.
>  
> @@ -527,9 +564,17 @@ Glossary
>  A term used to describe the ease with which software can be rehosted 
> on
>  another computer.
>  
> +POSIX
> +This term is an acronym for
> +`Portable Operating System Interface 
> <https://en.wikipedia.org/wiki/POSIX>`_.
> +
>  posting
>  The act of sending an event, message, semaphore, or signal to a task.
>  
> +PPS
> +This term is an acronym for
> +`Pulse-Per-Second 
> <https://en.wikipedia.org/wiki/Pulse-per-second_signal>`_.
> +
>  preempt
>  The act of forcing a task to relinquish the processor and 
> dispatching to
>  another task.
> @@ -650,6 +695,10 @@ Glossary
>  RTEMS
>  This term is an acronym for Real-Time Executive for Multiprocessor 
> Systems.
>  
> +RTEMS epoch
> +The RTEMS epoch is a point in time.  It is 1988-01-01T00:00:00Z in
> +`ISO 8601 <https://en.wikipedia.org/wiki/ISO_8601>`_ time format.
> +
>  running
>  The state of a rate monotonic timer while it is being used to 
> delineate a
>  period.  The timer exits this state by either expiring or being 
> canceled.
> @@ -910,6 +959,10 @@ Glossary
>  TTAS
>  This term is an acronym for Test and Test-And-Set.
>  
> +Unix epoch
> +The Unix epoch is a point in time.  It is 1970-01-01T00:00:00Z in
> +`ISO 8601 <https://en.wikipedia.org/wiki/ISO_8601>`_ time format.
> +
>  User Extension Table
>  A table which contains the entry points for each user extensions.
>  
> -- 2.26.2 ___ devel mailing
> list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
> 
-- 
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
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 0/8] Generate documentation for managers

[Frank Kühndel]

Hello Sebastian,

this actually really improves the documentation. The new constraints
sections makes it clearer when a function can be used. Moreover, there
are new descriptions of all parameters. I guess you must have looked in
the source code, to figure out the correct set of errors each directive
may return. I also did see that there are new code examples. Like it!

I only fond these minor issues:

1) In section "SEMAPHORE_CREATE - Create a semaphore" it looks like the
following passage for the original text has not found its way into the
new description:

-It is not allowed to create an initially locked MrsP semaphore and the
-``RTEMS_INVALID_NUMBER`` status code will be returned in SMP
configurations
-in this case.  This prevents lock order reversal problems with the
-allocator mutex.


2) In section "rtems_extension_create()": The parameter
"extension_table" is not described in the parameter list. It also does
not get clear to me from the description what is the use of the whole
thing/what happens here with the "extension_table". The original text
had at least this sentence: "The extension set specified by
:c:data:`table` is copied to the ESCB." -- what ever that means.

Greetings
fk

-- 
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
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] basedefs: Add stringification of argument lists

[Frank Kühndel]

Hello Sebastian,

On 2/9/21 3:14 PM, Sebastian Huber wrote:
> On 09/02/2021 15:10, Gedare Bloom wrote:
> 
>> On Tue, Feb 9, 2021 at 7:07 AM Sebastian Huber
>>   wrote:
>>> On 09/02/2021 15:04, Gedare Bloom wrote:
>>>
> We are responsible to monitor the RTEMS development during the
> pre-qualification activity and adjust the specification, etc. I would
> have sent you an e-mail that a specification update is necessary. The
> basedefs is an area with a higher probability of changes.
>
 Is there a sustainable plan for beyond the project lifetime (maybe,
 something we need to discuss separately)? Is there a plan/way to
 automate consistency checking or to clue a developer that there is a
 possible related spec file to consider updating?

>>> I think this is something for the how-to section:
>>>
>>> https://docs.rtems.org/branches/master/eng/req/howto.html
>>>
>>> For example, I added/changed an interface specification item, what
>>> should I do next?
>>>
>> Yes, I was just wondering if we can automate/script any checks to help
>> us think less.
> The goal is to get some script support in the future, however, the
> specification is still not complete enough to get useful results at the
> moment. The script could give you for example an indication which other
> items are affected if some item is changed.

I would already be happy if, for example, for the whole of the basedefs
(i.e. for all interfaces and requirements) I would have a place to store
the git-hash of the version I last updated the basedefs as well as the
list of most important files. Then I could later do the following to
figure out if there were any relevant changes which I need to take care of:

$ cd rtems
$ git pull
$ git diff  HEAD 

where for the basedefs for example:

HASH-OF-LAST-UPDATE = 766009b4f19ecdb7f193c683ca60d6d8570f15c5

LIST-OF-RELEVANT-FILES = cpukit/include/rtems/score/basedefs.h \
testsuites/sptests/spmisc01/init.c

Greetings
fk

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] basedefs: Add stringification of argument lists

[Frank Kühndel]

Hello Sebastian,

On 2/8/21 7:54 AM, Sebastian Huber wrote:
> On 14/12/2020 09:44, Sebastian Huber wrote:
> 
>> Change RTEMS_STRING() and RTEMS_XSTRING() to accept a variable number of
>> arguments which is stringified.  This can be used for example to create
>> register lists for inline assembler statements.
>> ---
>>   cpukit/include/rtems/score/basedefs.h | 16 
>>   1 file changed, 8 insertions(+), 8 deletions(-)
>>
>> diff --git a/cpukit/include/rtems/score/basedefs.h
>> b/cpukit/include/rtems/score/basedefs.h
>> index 0081dbfbe4..87a693e180 100644
>> --- a/cpukit/include/rtems/score/basedefs.h
>> +++ b/cpukit/include/rtems/score/basedefs.h
>> @@ -335,13 +335,13 @@ extern "C" {
>>   /**
>>    * @ingroup RTEMSAPIBaseDefs
>>    *
>> - * @brief Stringifies _x without expanding.
>> + * @brief Stringifies the arguments without expanding them.
>>    *
>> - * @param _x is the token to stringify.
>> + * @param ... are the arguments to stringify.
>>    *
>> - * @return Returns the stringification of the token _x.
>> + * @return Returns the stringification of the arguments.
>>    */
>> -#define RTEMS_STRING( _x ) #_x
>> +#define RTEMS_STRING( ... ) #__VA_ARGS__
>>     /* Generated from spec:/rtems/basedefs/if/typeof-refx */
>>   @@ -898,13 +898,13 @@ extern "C" {
>>   /**
>>    * @ingroup RTEMSAPIBaseDefs
>>    *
>> - * @brief Stringifies the expansion of _x.
>> + * @brief Stringifies the expansion of the arguments.
>>    *
>> - * @param _x is the token expand and stringify.
>> + * @param ... are the arguments to expand and stringify.
>>    *
>> - * @return Returns the stringification of the expansion of token _x.
>> + * @return Returns the stringification of the expansion of the
>> arguments.
>>    */
>> -#define RTEMS_XSTRING( _x ) RTEMS_STRING( _x )
>> +#define RTEMS_XSTRING( ... ) RTEMS_STRING( __VA_ARGS__ )
>>     /* Generated from spec:/rtems/basedefs/if/define-global-symbol */
> Any objections to push this? It makes the macro a bit more flexible.
> Linux uses the same approach.
No objections but I am missing something. We do not used a certain
frozen RTEMS version for the pre-qualification, do we?

This brings about the problem that very change in RTEMS which is part of
the pre-qualified source code must trigger the needed changes in the
pre-qualification data set - here in the specification items:

  spec/rtems/basedefs/req/string-0.yml
  spec/rtems/basedefs/req/xstring-0.yml

I know, everyone wants to program and push his/her code into RTEMS as
fast as possible without dealing with documentation, specification items
or other depending stuff. ... and I am among the first doing so ...
Yet, if the pre-qualification data set is not continuously kept up to
date, the whole documentation is outdated even before the
pre-qualification project ends. Is this topic somehow addressed? ... and
who is responsible to adapt the above two files?

Greetings
fk
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] eng: Requirements counting shall start at zero

[Frank Kühndel]

Hello Gedare,

On 12/11/20 4:41 PM, Gedare Bloom wrote:
> 
> 
> On Fri, Dec 11, 2020 at 8:16 AM Frank Kühndel
>  <mailto:frank.kuehn...@embedded-brains.de>> wrote:
> 
> Hello Joel,
> 
> On 12/11/20 3:49 PM, Joel Sherrill wrote:
> >
> >
> > On Fri, Dec 11, 2020, 8:41 AM Frank Kuehndel
> >  <mailto:frank.kuehn...@embedded-brains.de>
> > <mailto:frank.kuehn...@embedded-brains.de
> <mailto:frank.kuehn...@embedded-brains.de>>> wrote:
> >
> >     From: Frank Kühndel  <mailto:frank.kuehn...@embedded-brains.de>
> >     <mailto:frank.kuehn...@embedded-brains.de
> <mailto:frank.kuehn...@embedded-brains.de>>>
> >
> >     ---
> >      eng/req/req-for-req.rst | 21 +
> >      1 file changed, 21 insertions(+)
> >
> >     diff --git a/eng/req/req-for-req.rst b/eng/req/req-for-req.rst
> >     index 9225e95..dcc4c11 100644
> >     --- a/eng/req/req-for-req.rst
> >     +++ b/eng/req/req-for-req.rst
> >     @@ -308,6 +308,27 @@ spec:/classic/task/create-err-invname
> >
> >          ...
> >
> >     +If requirements or the YAML files which contain them are to be
> >     numbered,
> >     +the numbering shall start with 0. For example:
> >
> >     +
> >     +.. code-block:: none
> >     +
> >     +    weak-alias-0.yml
> >     +    weak-alias-1.yml
> >     +
> >     +Smaller numbers shall be prefixed with 0 to the same count of
> digits
> >     +as the largest number. For example:
> >
> >
> > When one goes from 99 to 100 requirements and didn't anticipate having
> > that many, does this mean all the files will have to be renamed?
> 
> I can change the text to what Gedare Bloom suggested: "If we know the
> max count (N) ahead of time, ..."
> 
> Just from my experience with the requirements for the basedefs, when I
> create the requirements for an operation, I know the number I end up
> with before checking them in. The issue we discuss would only cause
> trouble if later more requirements for the same operation must be added.
> This is not totally unlikely but it means that one actually has 9 and
> then need a 10th one.
> 
> >
> > Should we start with a minimum of three or four digits? What would
> drive
> > the number of requirements in a set? How large of a functional
> area will
> > a single numbered set contain?
> >
> > I'm just wondering if it is simpler to just have 001 as a minimum.
> 
> I think that 99 requirements for a single operation are really out of
> scope. That will hopefully never ever happen. Even 9 is already a lot.
> Also it is rather advisable to adapt the names of the requirements to
> indicate the purpose. The numbering is more for the case that there are
> two or more requirements on the same topic (like on handling the same
> bad input argument).
> 
>   my-function-0
>   my-function-1
>   my-function-global-side-effect
>   my-function-bad-argument-x-error-handling
>   my-function-bad-argument-y-error-handling
>   my-function-called-in-wrong-state
> 
> 
> This actually means there is a requirement for unnumbered names as well.
> 
> Would it be better to explicitly define all requirements numbered and
> use -0, in case they should be extended later, or perhaps to start
> numbering without a number as 0 "implied" and numbers begin with 1?
> 

If there is a -1 then I personally prefer that there should be a -0. For
the basedefs, I ended all requirements with -0 even if there was no -1.
Yet, whether this is the most wisest thing to do, I cannot say. I would
leave it to the author.

These numbers are mainly for requirements which need to be split:

  my-function.yml
"The function shall return 7 and set global variable X to 5".

If later someone needs to split this, would renaming it be so much trouble?

  my-function-0.yml
"The function shall return 7".

  my-function-1.yml
"The function shall set global variable X to 5".

Could be as well:

  my-function-result.yml
"The function shall return 7".

  my-function-side-effect.yml
"The function shall set global variable X to 5".

Greetings
Frank

> 
> My opinion is that defining whether we start counting with 0 or with 1
> makes sense. Everything else seems to me a bit like solving theoretical
> problems.
> 
&

Re: [PATCH v2] eng: Requirements counting shall start at zero

[Frank Kühndel]

Hello Andrew,

I did not intent to become the authority in numbering files. :-)

Maybe Sebastian has some advice as he knows your application better than
I do. I personally would be pragmatic and do what seems to be an easy to
realize as well as a good solution.

Greetings
Frank



On 12/11/20 4:30 PM, Andrew Butterfield wrote:
> Hello Frank,
> 
>  I have a use case where the numbers will exceed 10 .
> 
> It's not for numbered requirements but numbered test-files.
> These result from different scenarios generated by our SPIN models, as
> part of the qualification activity.
> 
> The files are generated (and numbered) automatically, so the constraints
> are somewhat different.
> 
> For the Events Manager, for example,  I'd expect the final number of
> generated test source files to exceed 10.
> It is unlikely that we would reach 100, though.
> 
> Regards, Andrew
> 
>> On 11 Dec 2020, at 15:16, Frank Kühndel
>> > <mailto:frank.kuehn...@embedded-brains.de>> wrote:
>>
>> Hello Joel,
>>
>> On 12/11/20 3:49 PM, Joel Sherrill wrote:
>>>
>>>
>>> On Fri, Dec 11, 2020, 8:41 AM Frank Kuehndel
>>> >> <mailto:frank.kuehn...@embedded-brains.de>
>>> <mailto:frank.kuehn...@embedded-brains.de
>>> <mailto:frank.kuehn...@embedded-brains.de>>> wrote:
>>>
>>>    From: Frank Kühndel >> <mailto:frank.kuehn...@embedded-brains.de>
>>>    <mailto:frank.kuehn...@embedded-brains.de
>>> <mailto:frank.kuehn...@embedded-brains.de>>>
>>>
>>>    ---
>>> eng/req/req-for-req.rst | 21 +
>>> 1 file changed, 21 insertions(+)
>>>
>>>    diff --git a/eng/req/req-for-req.rst b/eng/req/req-for-req.rst
>>>    index 9225e95..dcc4c11 100644
>>>    --- a/eng/req/req-for-req.rst
>>>    +++ b/eng/req/req-for-req.rst
>>>    @@ -308,6 +308,27 @@ spec:/classic/task/create-err-invname
>>>
>>>     ...
>>>
>>>    +If requirements or the YAML files which contain them are to be
>>>    numbered,
>>>    +the numbering shall start with 0. For example:
>>>
>>>    +
>>>    +.. code-block:: none
>>>    +
>>>    +    weak-alias-0.yml
>>>    +    weak-alias-1.yml
>>>    +
>>>    +Smaller numbers shall be prefixed with 0 to the same count of digits
>>>    +as the largest number. For example:
>>>
>>>
>>> When one goes from 99 to 100 requirements and didn't anticipate having
>>> that many, does this mean all the files will have to be renamed?
>>
>> I can change the text to what Gedare Bloom suggested: "If we know the
>> max count (N) ahead of time, ..."
>>
>> Just from my experience with the requirements for the basedefs, when I
>> create the requirements for an operation, I know the number I end up
>> with before checking them in. The issue we discuss would only cause
>> trouble if later more requirements for the same operation must be added.
>> This is not totally unlikely but it means that one actually has 9 and
>> then need a 10th one.
>>
>>>
>>> Should we start with a minimum of three or four digits? What would drive
>>> the number of requirements in a set? How large of a functional area will
>>> a single numbered set contain?
>>>
>>> I'm just wondering if it is simpler to just have 001 as a minimum.
>>
>> I think that 99 requirements for a single operation are really out of
>> scope. That will hopefully never ever happen. Even 9 is already a lot.
>> Also it is rather advisable to adapt the names of the requirements to
>> indicate the purpose. The numbering is more for the case that there are
>> two or more requirements on the same topic (like on handling the same
>> bad input argument).
>>
>>  my-function-0
>>  my-function-1
>>  my-function-global-side-effect
>>  my-function-bad-argument-x-error-handling
>>  my-function-bad-argument-y-error-handling
>>  my-function-called-in-wrong-state
>>
>> My opinion is that defining whether we start counting with 0 or with 1
>> makes sense. Everything else seems to me a bit like solving theoretical
>> problems.
>>
>>>
>>>    +
>>>    +.. code-block:: none
>>>    +
>>>    +    alias-00.yml
>>>    +    alias-01.yml
>>>    +    alias-02.yml
>>>    +    ...
>>>    +    alias-09.yml
>>>    +    alias-10.yml
>>>    +    alias-11.yml
>>>    +
>>> Conf

Re: [PATCH v2] eng: Requirements counting shall start at zero

[Frank Kühndel]

Hello Joel,

On 12/11/20 3:49 PM, Joel Sherrill wrote:
> 
> 
> On Fri, Dec 11, 2020, 8:41 AM Frank Kuehndel
>  <mailto:frank.kuehn...@embedded-brains.de>> wrote:
> 
> From: Frank Kühndel  <mailto:frank.kuehn...@embedded-brains.de>>
> 
> ---
>  eng/req/req-for-req.rst | 21 +
>  1 file changed, 21 insertions(+)
> 
> diff --git a/eng/req/req-for-req.rst b/eng/req/req-for-req.rst
> index 9225e95..dcc4c11 100644
> --- a/eng/req/req-for-req.rst
> +++ b/eng/req/req-for-req.rst
> @@ -308,6 +308,27 @@ spec:/classic/task/create-err-invname
> 
>      ...
> 
> +If requirements or the YAML files which contain them are to be
> numbered,
> +the numbering shall start with 0. For example:
> 
> +
> +.. code-block:: none
> +
> +    weak-alias-0.yml
> +    weak-alias-1.yml
> +
> +Smaller numbers shall be prefixed with 0 to the same count of digits
> +as the largest number. For example:
> 
> 
> When one goes from 99 to 100 requirements and didn't anticipate having
> that many, does this mean all the files will have to be renamed?

I can change the text to what Gedare Bloom suggested: "If we know the
max count (N) ahead of time, ..."

Just from my experience with the requirements for the basedefs, when I
create the requirements for an operation, I know the number I end up
with before checking them in. The issue we discuss would only cause
trouble if later more requirements for the same operation must be added.
This is not totally unlikely but it means that one actually has 9 and
then need a 10th one.

> 
> Should we start with a minimum of three or four digits? What would drive
> the number of requirements in a set? How large of a functional area will
> a single numbered set contain?
> 
> I'm just wondering if it is simpler to just have 001 as a minimum.

I think that 99 requirements for a single operation are really out of
scope. That will hopefully never ever happen. Even 9 is already a lot.
Also it is rather advisable to adapt the names of the requirements to
indicate the purpose. The numbering is more for the case that there are
two or more requirements on the same topic (like on handling the same
bad input argument).

  my-function-0
  my-function-1
  my-function-global-side-effect
  my-function-bad-argument-x-error-handling
  my-function-bad-argument-y-error-handling
  my-function-called-in-wrong-state

My opinion is that defining whether we start counting with 0 or with 1
makes sense. Everything else seems to me a bit like solving theoretical
problems.

> 
> +
> +.. code-block:: none
> +
> +    alias-00.yml
> +    alias-01.yml
> +    alias-02.yml
> +    ...
> +    alias-09.yml
> +    alias-10.yml
> +    alias-11.yml
> +
>  Conflict Free Requirements
>  --
> 
> -- 
> 2.26.2
> 
> ___
> devel mailing list
> devel@rtems.org <mailto:devel@rtems.org>
> http://lists.rtems.org/mailman/listinfo/devel
> <http://lists.rtems.org/mailman/listinfo/devel>
> 

Greetings
Frank
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] rtems-fdt / shell - Fix string truncation warning

[Frank Kühndel]

Hello Chris,

On 10/15/20 10:29 PM, Chris Johns wrote:
> On 16/10/20 7:24 am, Joel Sherrill wrote:
>> On Thu, Oct 15, 2020 at 2:13 PM Chris Johns > <mailto:chr...@rtems.org>> wrote:
>> On 15/10/20 10:27 pm, Frank Kuehndel wrote:
>> > From: Frank Kühndel > <mailto:frank.kuehn...@embedded-brains.de>>
>> >
>> > The compiler warning was:
>> >
>> > ../../../cpukit/libmisc/rtems-fdt/rtems-fdt.c:267:5: warning:
>> > 'strncpy' specified bound depends on the length of the source argument
>> >   267 |     strncpy(path, name, namelen);
>> >       |     ^~~~
>> >
>> > It turns out that the `strncpy()` nor the buffer `path` is needed when
>> > one uses `strncmp()` instead of `strcmp()`. This needs some change to
>> > the algorithm but has the advantage that `name` is never truncated
>> > to the size of the buffer `path`.
>> >
>> > Note:
>> >
>> > rtems-fdt.c, rtems-fdt-shell.c and cpukit/include/rtems/rtems-fdt.h
>> > seem to be dead code.
>>
>> We cannot tell this is as a user may depend on it. With this command I 
>> know
>> users on Zynq platforms that use FDT to map PL logic to drivers. The 
>> command is
>> very much in use and is used as a PS to PL testing method.

This statement was not meant as an offense. I spent a lot of time trying
to figure out where and how this code was used - without result. With
this statement, I hoped to trigger a reaction by someone indicating that
he/she knows the code can be removed or that he/she knows the code is in
use. I am sorry that my text was not appropriate.

I will send a patch v2 without this text on Monday.

Frank

>>
>> > They implement a shell command `fdt` but that
>> > command is not part of the shell nor of any macro in
>> > cpukit/include/rtems/shellconfig.h.
>>
>> It have been missed and needs be added. Adding something in 
>> shellconfig.h would
>> be a help.
>>
>> Does that mean it also is not in the Shell manual?
>>
> Yes it seems so:
> 
> (sphinx38) ruru rtems-docs.git $ grep -r fdt shell
> (sphinx38) ruru rtems-docs.git $
> 
> Chris
> 

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] rtems-fdt / shell - Fix string truncation warning

[Frank Kühndel]

On 10/15/20 2:09 PM, Sebastian Huber wrote:
> 
>> From: Frank Kühndel
>>
>> The compiler warning was:
>>
>> ../../../cpukit/libmisc/rtems-fdt/rtems-fdt.c:267:5: warning:
>> 'strncpy' specified bound depends on the length of the source argument
>>    267 | strncpy(path, name, namelen);
>>    | ^~~~
>>
>> It turns out that the `strncpy()` nor the buffer `path` is needed when
>> one uses `strncmp()` instead of `strcmp()`. This needs some change to
>> the algorithm but has the advantage that `name` is never truncated
>> to the size of the buffer `path`.
> Does it help to use bsearch() to simplify this code further?

Nice! I did not even know (or remember about) bsearch().

No, it wont help. bsearch() works on "similar" objects (e.g. two
strings). The function I modified searches a string in an array of
'rtems_fdt_index_entry' objects. To make that work, one must create a
dummy 'rtems_fdt_index_entry' containing that string.

Moreover, there remains the problem that the 'name' string has an
artificially restricted length which must be convoyed to the 'compar()'
function used by 'bseach()'.

Finally, rtems-fdt.c is - most likely - dead code. So, I would end up
spending my time on brushing up dead code.

Greetings
fk
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] testsuites/samples/fileio - Increase of stack size

[Frank Kühndel]

I also created a ticket for RTEMS version 5 as requested by Joel and
Chris. It is #4144.

Yet, note that I have not tested whether the problem appears there, too.
The efforts to install and compile 5.1 just for this simple test are
prohibitive. Sorry for this. Maybe someone else who is working with 5.1
can check it.

Moreover, I cannot contribute to the discussion -Og versus -O0.

Greetings
Frank

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] testsuites/samples/fileio - Increase of stack size

[Frank Kühndel]

Hi Joel,

Sebastian is the opinion its a "GCC 10 issue".

On 10/9/20 3:32 PM, Joel Sherrill wrote:
> This is interesting. When I teach RTEMS classes, I always run this
> application and the last time, this BSP was the one used. It was a rare
> case of all Zynq users with no LEON users. :)
> 
> What version of RTEMS and how did you configure it? 

Version is the newest, I think 6:

remote.origin.url=git://git.rtems.org/rtems.git

The branch bases on origin/master.
The preceding commit was:
commit 558a19d3adff6a3ecf678f94408b48beccbbc9fb (origin/master,
origin/HEAD, master)

The config.ini is

[arm/realview_pbx_a9_qemu]
RTEMS_DEBUG = True
RTEMS_NETWORKING = True
RTEMS_POSIX_API = True
RTEMS_SMP = True
BUILD_TESTS = True

> 
> This sounds like it may need a ticket since it likely needs to be
> included on the 5 branch.pa 

I can open a ticket for 5 and 6 if you like.

Greetings
Frank

> 
> I don't doubt it crashed. Just want details so we can apply the patch
> properly. 
> 
> --joel
> 
> On Fri, Oct 9, 2020 at 8:07 AM Frank Kuehndel
>  > wrote:
> 
> When I use the 'shell' from the fileio sample with the command below:
> 
>    env QEMU_AUDIO_DRV="none" \
>    qemu-system-arm -no-reboot -net none -nographic -M
> realview-pbx-a9 -m 256M \
>    -kernel build/arm/realview_pbx_a9_qemu/testsuites/samples/fileio.exe
> 
> The executable crashes with an "BLOWN STACK!!!" as soon as I try to
> login
> as 'root' with password. (The logins without password work fine.)
> Increasing
> the stack size of the affected thread a bit solves the issue. Hence,
> I suggest this patch.
> ---
>  testsuites/samples/fileio/init.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/testsuites/samples/fileio/init.c
> b/testsuites/samples/fileio/init.c
> index 86b34b99dd..c552d33613 100644
> --- a/testsuites/samples/fileio/init.c
> +++ b/testsuites/samples/fileio/init.c
> @@ -630,7 +630,7 @@ static void fileio_start_shell(void)
>    printf(" =\n");
>    rtems_shell_init(
>      "SHLL",                          /* task_name */
> -    RTEMS_MINIMUM_STACK_SIZE * 4,    /* task_stacksize */
> +    RTEMS_MINIMUM_STACK_SIZE * 5,    /* task_stacksize */
>      100,                             /* task_priority */
>      "/dev/foobar",                   /* devname */
>      /* device is currently ignored by the shell if it is not a pty */
> -- 
> 2.26.2
> 
> ___
> 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] shell: Fixing bug in line editing of the shell with CTRL-U.

[Frank Kühndel]

Hello,

we fixed the minor issues in the patch, created two tickets (#4096 for
milestone 5 and #4097 for 6) and Sebastian Huber added the fix to the
git sources.

Many thank to all reviewers for their helpful comments.

Greetings,
Frank

On 9/27/20 9:26 AM, Chris Johns wrote:
> On 26/9/20 2:06 am, Joel Sherrill wrote:
>> On Fri, Sep 25, 2020, 10:06 AM Gedare Bloom > <mailto:ged...@rtems.org>> wrote:
>>
>> On Fri, Sep 25, 2020 at 3:11 AM Frank Kuehndel
>> > <mailto:frank.kuehn...@embedded-brains.de>> wrote:
>> >
>> > This patch fixes a tiny bug in the command line editing of the RTEMS
>> shell. Typing CTRL-U in the shell should remove all characters left of 
>> the
>> cursor. After pressing CTRL-U, the current implementation does wrongly 
>> place
>> the cursor at the end of the line instead at its beginning.
>> >
>> >
>> > To reproduce the bug, start the shell and type 'abc123' (no ):
>> >
>> > > ~/src/rtems $ qemu-system-arm -net none -nographic -M 
>> realview-pbx-a9 -m
>> 256M -kernel build/arm/realview_pbx_a9_qemu/testsuites/libtests/dl10.exe
>> > >
>> > >
>> > > *** BEGIN OF TEST libdl (RTL) 10 ***
>> > > *** TEST VERSION: 6.0.0.d9bdf166644f612dd628fe4951c12c6f8e94ba5f
>> > > *** TEST STATE: USER_INPUT
>> > > *** TEST BUILD: RTEMS_DEBUG RTEMS_NETWORKING RTEMS_POSIX_API 
>> RTEMS_SMP
>> > > *** TEST TOOLS: 10.2.1 20200904 (RTEMS 6, RSB
>> 31f936a7b74d60bda609a9960c6e1a705ba54974, Newlib a0d7982)
>> > > RTL (libdl) commands: dl, rtl
>> > >
>> > >
>> > > RTEMS Shell on /dev/foobar. Use 'help' to list commands.
>> > > SHLL [/] # abc123
>> >
>> > Then move the cursor onto the '1' by hitting three times the 
>> 
>> key. Next type -U:
>> >
>> > > SHLL [/] # 123
>> >
>> > Note that the cursor is at the end of the line (after '3') instead of
>> correctly at the beginning (on the '1'), now.
>> >
>> > Continuing typing 'echo ' incorrectly results in the output:
>> >
>> > > SHLL [/] # 123echo 123
>> >
>> > The patch changes this behavior so that the cursor in the second last 
>> step
>> will be on the '1' and typing 'echo ' will then correctly reflected as:
>> >
>> > > SHLL [/] # echo 123
>> >
>>
>> Please put the above bug details into a ticket
>> https://devel.rtems.org/wiki/NewTicket with a milestone of 6
>>
>>
>> Why wouldn't this also be appropriate for 5?
>>
> It is fine for 5 with a ticket.
> 
>> And can anyone confirm this happens on real hardware? Sometimes control
>> characters act funny on simulators.
> It is broken on hardware so the simulator and hardware match.
> 
> Chris
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
> 

-- 

embedded brains GmbH
Frank Kühndel
Dornierstr. 4
82178 Puchheim
Germany
email: frank.kuehn...@embedded-brains.de
Phone: +49-89-18 94 741 - 23
Fax:   +49-89-18 94 741 - 09
PGP: Public key available on request.
PGP: Fingerprint: EE89 0670 B8BE 551A ED4E  FB85 829C 306F 649C 05B9

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel