Cygwin tools failure

2022-10-11 Thread Ryan Long 
Cygwin has been unable to build the tools for awhile. This has been due 
to an array subscript being a char while building DTC. The maintainers 
didn't see an issue with the code itself, so it's going to go on being 
broken for awhile I guess.


Joel recommended commented out the building of DTC through the RSB. 
After doing so, I'm running into the following error. I was building 
AArch64's tools. Disabling DTC and building with my Debian WSL instance 
built it just fine.



[ 48/258] Compiling rtemstoolkit/elftoolchain/libelf/libelf_align.c
../rtemstoolkit/elftoolchain/libelf/elf.c:34:35: error: ‘LIBELF_ARCH’ 
undeclared here (not in a function); did you mean ‘LIBELF_ERROR’?

   34 | .libelf_arch    = LIBELF_ARCH,
  |   ^~~
  |   LIBELF_ERROR
../rtemstoolkit/elftoolchain/libelf/elf.c:35:35: error: 
‘LIBELF_BYTEORDER’ undeclared here (not in a function); did you mean 
‘LIBELF_ERROR’?

   35 | .libelf_byteorder   = LIBELF_BYTEORDER,
  |   ^~~~
  |   LIBELF_ERROR
../rtemstoolkit/elftoolchain/libelf/elf.c:36:35: error: ‘LIBELF_CLASS’ 
undeclared here (not in a function)

   36 | .libelf_class   = LIBELF_CLASS,
  |   ^~~~

Waf: Leaving directory 
`/home/rtems-tester/rtems-cron-6/rtems-source-builder/rtems/build/rtems-tools-d0a65c72d1a170637258eb19f7d3e433be7c3c86-1/rtems-tools-d0a65c72d1a170637258eb19f7d3e433be7c3c86/build'



Does anyone know a fix for this?

Thanks,

Ryan

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

Re: [PATCH] bsps: Improve riscv console FDT parsing

2022-10-11 Thread Alan Cudmore 
Ping for this RISC-V console fix - it builds without error on 310ARTY,
Polarfire, and generic RISCV variants. I tested it on the generic QEMU
riscv platform and Padmarao tested it on the PolarFire.
Thanks,
Alan

On Thu, Sep 29, 2022 at 12:12 PM Alan Cudmore 
wrote:

> This fixes a problem with parsing the FDT compatible property by
> replacing the RISCV_CONSOLE_IS_COMPATIBLE macro with calls to
> the fdt_stringlist_contains function. The macro only works when
> the compatible FDT entry is a single string and not a list of
> strings. The new call will compare each item in the string list.
>
> Close #4728.
> ---
>  bsps/riscv/riscv/console/console-config.c | 14 +-
>  1 file changed, 5 insertions(+), 9 deletions(-)
>
> diff --git a/bsps/riscv/riscv/console/console-config.c
> b/bsps/riscv/riscv/console/console-config.c
> index d962a5a418..7908c2f325 100644
> --- a/bsps/riscv/riscv/console/console-config.c
> +++ b/bsps/riscv/riscv/console/console-config.c
> @@ -139,10 +139,6 @@ static void riscv_console_set_reg_32(uintptr_t addr,
> uint8_t i, uint8_t val)
>  }
>  #endif
>
> -#define RISCV_CONSOLE_IS_COMPATIBLE(actual, actual_len, desired) \
> -  (actual_len == sizeof(desired) \
> - && memcmp(actual, desired, sizeof(desired) - 1) == 0)
> -
>  static void riscv_console_probe(void)
>  {
>const void *fdt;
> @@ -170,7 +166,7 @@ static void riscv_console_probe(void)
>  }
>
>  #if RISCV_ENABLE_HTIF_SUPPORT != 0
> -if (RISCV_CONSOLE_IS_COMPATIBLE(compat, compat_len, "ucb,htif0")) {
> +if (fdt_stringlist_contains(compat, compat_len, "ucb,htif0")) {
>htif_console_context_init(&htif_console_instance.base, node);
>
>riscv_console.context = &htif_console_instance.base;
> @@ -181,8 +177,8 @@ static void riscv_console_probe(void)
>
>  #if RISCV_CONSOLE_MAX_NS16550_DEVICES > 0
>  if (
> -  (RISCV_CONSOLE_IS_COMPATIBLE(compat, compat_len, "ns16550a")
> -  || RISCV_CONSOLE_IS_COMPATIBLE(compat, compat_len, "ns16750"))
> +(fdt_stringlist_contains(compat, compat_len, "ns16550a")
> +|| fdt_stringlist_contains(compat, compat_len, "ns16750"))
>  && ns16550_devices < RISCV_CONSOLE_MAX_NS16550_DEVICES
>  ) {
>ns16550_context *ctx;
> @@ -203,7 +199,7 @@ static void riscv_console_probe(void)
>  ctx->set_reg = riscv_console_set_reg_8;
>}
>
> -  if (RISCV_CONSOLE_IS_COMPATIBLE(compat, compat_len, "ns16750")) {
> +  if (fdt_stringlist_contains(compat, compat_len, "ns16750")) {
>  ctx->has_precision_clock_synthesizer = true;
>}
>
> @@ -243,7 +239,7 @@ static void riscv_console_probe(void)
>  #endif
>
>  #if RISCV_ENABLE_FRDME310ARTY_SUPPORT != 0
> -if (RISCV_CONSOLE_IS_COMPATIBLE(compat, compat_len, "sifive,uart0")) {
> +if (fdt_stringlist_contains(compat, compat_len, "sifive,uart0")) {
>fe310_uart_context *ctx;
>
>ctx = &fe310_uart_instance;
> --
> 2.34.1
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: docs not building to PDF

2022-10-11 Thread Chris Johns 
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 with https://pixelied.com/features/svg-editor and it was a mess.

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

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

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

Re: Cygwin tools failure

2022-10-11 Thread Joel Sherrill 
On Tue, Oct 11, 2022 at 8:36 PM Ryan Long  wrote:

> Cygwin has been unable to build the tools for awhile. This has been due
> to an array subscript being a char while building DTC. The maintainers
> didn't see an issue with the code itself, so it's going to go on being
> broken for awhile I guess.
>
> Joel recommended commented out the building of DTC through the RSB.
> After doing so, I'm running into the following error. I was building
> AArch64's tools. Disabling DTC and building with my Debian WSL instance
> built it just fine.
>
>
> [ 48/258] Compiling rtemstoolkit/elftoolchain/libelf/libelf_align.c
> ../rtemstoolkit/elftoolchain/libelf/elf.c:34:35: error: ‘LIBELF_ARCH’
> undeclared here (not in a function); did you mean ‘LIBELF_ERROR’?
> 34 | .libelf_arch= LIBELF_ARCH,
>|   ^~~
>|   LIBELF_ERROR
> ../rtemstoolkit/elftoolchain/libelf/elf.c:35:35: error:
> ‘LIBELF_BYTEORDER’ undeclared here (not in a function); did you mean
> ‘LIBELF_ERROR’?
> 35 | .libelf_byteorder   = LIBELF_BYTEORDER,
>|   ^~~~
>|   LIBELF_ERROR
> ../rtemstoolkit/elftoolchain/libelf/elf.c:36:35: error: ‘LIBELF_CLASS’
> undeclared here (not in a function)
> 36 | .libelf_class   = LIBELF_CLASS,
>|   ^~~~
>
> Waf: Leaving directory
>
> `/home/rtems-tester/rtems-cron-6/rtems-source-builder/rtems/build/rtems-tools-d0a65c72d1a170637258eb19f7d3e433be7c3c86-1/rtems-tools-d0a65c72d1a170637258eb19f7d3e433be7c3c86/build'
>
>
> Does anyone know a fix for this?
>

rtemstoolkit/elftoolchain/libelf/_libelf_config.h has ifdef's for various
host operating
systems and does not have one for Cygwin or MSYS. But it can't know the
native ELF
details because the native format is not ELF:

$ file /bin/cat.exe
/bin/cat.exe: PE32+ executable (console) x86-64, for MS Windows

I'm not sure what to do about this. My first thought would be to add
Cygwin to the list like FreeBSD and see if that defines what you need.
or find the x86_64 Linux settings and use those for Cygwin to let it
compile.

I'm not sure why we need to know the native ELF details.

--joel


> Thanks,
>
> Ryan
>
> ___
> 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: Cygwin tools failure

2022-10-11 Thread Chris Johns 
On 12/10/2022 2:30 pm, Joel Sherrill wrote:
> 
> 
> On Tue, Oct 11, 2022 at 8:36 PM Ryan Long  > wrote:
> 
> Cygwin has been unable to build the tools for awhile. This has been due
> to an array subscript being a char while building DTC. The maintainers
> didn't see an issue with the code itself, so it's going to go on being
> broken for awhile I guess.
> 
> Joel recommended commented out the building of DTC through the RSB.
> After doing so, I'm running into the following error. I was building
> AArch64's tools. Disabling DTC and building with my Debian WSL instance
> built it just fine.
> 
> 
> [ 48/258] Compiling rtemstoolkit/elftoolchain/libelf/libelf_align.c
> ../rtemstoolkit/elftoolchain/libelf/elf.c:34:35: error: ‘LIBELF_ARCH’
> undeclared here (not in a function); did you mean ‘LIBELF_ERROR’?
>     34 | .libelf_arch    = LIBELF_ARCH,
>    |   ^~~
>    |   LIBELF_ERROR
> ../rtemstoolkit/elftoolchain/libelf/elf.c:35:35: error:
> ‘LIBELF_BYTEORDER’ undeclared here (not in a function); did you mean
> ‘LIBELF_ERROR’?
>     35 | .libelf_byteorder   = LIBELF_BYTEORDER,
>    |   ^~~~
>    |   LIBELF_ERROR
> ../rtemstoolkit/elftoolchain/libelf/elf.c:36:35: error: ‘LIBELF_CLASS’
> undeclared here (not in a function)
>     36 | .libelf_class   = LIBELF_CLASS,
>    |   ^~~~
> 
> Waf: Leaving directory
> 
> `/home/rtems-tester/rtems-cron-6/rtems-source-builder/rtems/build/rtems-tools-d0a65c72d1a170637258eb19f7d3e433be7c3c86-1/rtems-tools-d0a65c72d1a170637258eb19f7d3e433be7c3c86/build'
> 
> 
> Does anyone know a fix for this?
> 
> 
> rtemstoolkit/elftoolchain/libelf/_libelf_config.h has ifdef's for various host
> operating
> systems and does not have one for Cygwin or MSYS. But it can't know the 
> native ELF
> details because the native format is not ELF:
> 
> $ file /bin/cat.exe
> /bin/cat.exe: PE32+ executable (console) x86-64, for MS Windows
> 
> I'm not sure what to do about this. My first thought would be to add 
> Cygwin to the list like FreeBSD and see if that defines what you need.
> or find the x86_64 Linux settings and use those for Cygwin to let it
> compile.
> 
> I'm not sure why we need to know the native ELF details.

The tools use to build on Ming64...

https://git.rtems.org/rtems-tools/tree/rtemstoolkit/elftoolchain/libelf/_libelf_config.h?h=5#n191

This patch broke the support...

https://git.rtems.org/rtems-tools/commit/rtemstoolkit/elftoolchain/libelf/_libelf_config.h?id=ff68bccc25386c84d893187af36e4bac88db4b10

Consider a patch to add the piece removed at the end of this patch as approved.

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