date:20220818

Re: [PATCH v2 1/1] bsp/riscv: Work area size based on /memory node in fdt

2022-08-18 Thread Hesham Almatary

All good, I'd just replace the "end == 0" with "end == NULL" as per my
comment above. Also please test on other RISC-V QEMU platforms to make
sure nothing got broken.

On Wed, 17 Aug 2022 at 14:10, Joel Sherrill  wrote:
>
> I'm ok with this if Hesham acks as well.
>
> --joel
>
> On Wed, Aug 17, 2022 at 6:35 AM Daniel Cederman  wrote:
>>
>> Uses the first entry in the /memory node to determine the end of the
>> work area. Falls back on linker symbol if unable to parse the node.
>> ---
>>  bsps/riscv/shared/start/bspgetworkarea.c | 144 +++
>>  spec/build/bsps/riscv/riscv/obj.yml  |   1 +
>>  2 files changed, 145 insertions(+)
>>  create mode 100644 bsps/riscv/shared/start/bspgetworkarea.c
>>
>> diff --git a/bsps/riscv/shared/start/bspgetworkarea.c 
>> b/bsps/riscv/shared/start/bspgetworkarea.c
>> new file mode 100644
>> index 00..1fa051d25e
>> --- /dev/null
>> +++ b/bsps/riscv/shared/start/bspgetworkarea.c
>> @@ -0,0 +1,144 @@
>> +/* SPDX-License-Identifier: BSD-2-Clause */
>> +
>> +/**
>> + * @file
>> + *
>> + * @brief BSP specific initialization support routines
>> + *
>> + */
>> +
>> +/*
>> + * COPYRIGHT (c) 1989-2020.
>> + * On-Line Applications Research Corporation (OAR).
>> + * Cobham Gaisler AB.
>> + *
>> + * 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.
>> + */
>> +
>> +#include 
>> +#include 
>> +
>> +#include 
>> +
>> +#include 
>> +
>> +/*
>> + *  These are provided by the linkcmds for ALL of the BSPs which use this 
>> file.
>> + */
>> +extern char WorkAreaBase[];
>> +extern char RamEnd[];
>> +
>> +static Memory_Area _Memory_Areas[ 1 ];
>> +
>> +static const char memory_path[] = "/memory";
>> +
>> +static void* get_end_of_memory_from_fdt(void)
>> +{
>> +  const void *fdt;
>> +  const void *val;
>> +  int node;
>> +  int parent;
>> +  int ac;
>> +  int sc;
>> +  int len;
>> +  uintptr_t start;
>> +  uintptr_t size;
>> +
>> +  fdt = bsp_fdt_get();
>> +
>> +  node = fdt_path_offset_namelen(
>> +fdt,
>> +memory_path,
>> +(int) sizeof(memory_path) - 1
>> +  );
>> +
>> +  if (node < 0) {
>> +return NULL;
>> +  }
>> +
>> +  parent = fdt_parent_offset(fdt, node);
>> +  if (parent < 0) {
>> +return NULL;
>> +  }
>> +
>> +  ac = fdt_address_cells(fdt, parent);
>> +  if (ac != 1 && ac != 2) {
>> +return NULL;
>> +  }
>> +
>> +  sc = fdt_size_cells(fdt, parent);
>> +  if (sc != 1 && sc != 2) {
>> +return NULL;
>> +  }
>> +
>> +  if (sc > ac) {
>> +return NULL;
>> +  }
>> +
>> +  val = fdt_getprop(fdt, node, "reg", &len);
>> +  if (len < sc + ac) {
>> +return NULL;
>> +  }
>> +
>> +  if (ac == 1) {
>> +start = fdt32_to_cpu(((fdt32_t *)val)[0]);
>> +size = fdt32_to_cpu(((fdt32_t *)val)[1]);
>> +  }
>> +
>> +  if (ac == 2) {
>> +start = fdt64_to_cpu(((fdt64_t *)val)[0]);
>> +
>> +if (sc == 1)
>> +  size = fdt32_to_cpu(((fdt32_t *)(val+8))[0]);
>> +else
>> +  size = fdt64_to_cpu(((fdt64_t *)val)[1]);
>> +  }
>> +
>> +  return (void*) (start + size);
>> +}
>> +
>> +static void bsp_memory_initialize( void )
>> +{
>> +  void *end;
>> +
>> +  /* get end of memory from the "/memory" node in the fdt */
>> +  end = get_end_of_memory_from_fdt();
>> +  if (end == 0) {
>> +/* fall back to linker symbol if "/memory" node not found or invalid */
>> +end = RamEnd;
>> +  }
>> +  _Memory_Initialize( &_Memory_Areas[ 0 ], WorkAreaBase, end );
>> +}
>> +
>> +RTEMS_SYSINIT_ITEM(
>> +  bsp_memory_initialize,
>> +  RTEMS_SYSINIT_MEMORY,
>> +  RTEMS_SYSINIT_ORDER_MIDDLE
>> +);
>> +
>> +static const Memory_Information _Memory_Information =
>> +  MEMORY_INFORMATION_INITIALIZER( _Memory_Areas );
>> +
>> +const Memory_Inf

Re: [PATCH v2 1/1] bsp/riscv: Work area size based on /memory node in fdt

2022-08-18 Thread Daniel Cederman

I missed your comment, but have made the change now. Are there any 
instructions on how to run the RISCV BSP tests on QEMU or Spike? I could 
not get it to work. Do I need a special version of QEMU or Spike?


On 2022-08-18 10:24, Hesham Almatary wrote:

All good, I'd just replace the "end == 0" with "end == NULL" as per my
comment above. Also please test on other RISC-V QEMU platforms to make
sure nothing got broken.

On Wed, 17 Aug 2022 at 14:10, Joel Sherrill  wrote:

I'm ok with this if Hesham acks as well.

--joel

On Wed, Aug 17, 2022 at 6:35 AM Daniel Cederman  wrote:

Uses the first entry in the /memory node to determine the end of the
work area. Falls back on linker symbol if unable to parse the node.
---
  bsps/riscv/shared/start/bspgetworkarea.c | 144 +++
  spec/build/bsps/riscv/riscv/obj.yml  |   1 +
  2 files changed, 145 insertions(+)
  create mode 100644 bsps/riscv/shared/start/bspgetworkarea.c

diff --git a/bsps/riscv/shared/start/bspgetworkarea.c 
b/bsps/riscv/shared/start/bspgetworkarea.c
new file mode 100644
index 00..1fa051d25e
--- /dev/null
+++ b/bsps/riscv/shared/start/bspgetworkarea.c
@@ -0,0 +1,144 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @brief BSP specific initialization support routines
+ *
+ */
+
+/*
+ * COPYRIGHT (c) 1989-2020.
+ * On-Line Applications Research Corporation (OAR).
+ * Cobham Gaisler AB.
+ *
+ * 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.
+ */
+
+#include 
+#include 
+
+#include 
+
+#include 
+
+/*
+ *  These are provided by the linkcmds for ALL of the BSPs which use this file.
+ */
+extern char WorkAreaBase[];
+extern char RamEnd[];
+
+static Memory_Area _Memory_Areas[ 1 ];
+
+static const char memory_path[] = "/memory";
+
+static void* get_end_of_memory_from_fdt(void)
+{
+  const void *fdt;
+  const void *val;
+  int node;
+  int parent;
+  int ac;
+  int sc;
+  int len;
+  uintptr_t start;
+  uintptr_t size;
+
+  fdt = bsp_fdt_get();
+
+  node = fdt_path_offset_namelen(
+fdt,
+memory_path,
+(int) sizeof(memory_path) - 1
+  );
+
+  if (node < 0) {
+return NULL;
+  }
+
+  parent = fdt_parent_offset(fdt, node);
+  if (parent < 0) {
+return NULL;
+  }
+
+  ac = fdt_address_cells(fdt, parent);
+  if (ac != 1 && ac != 2) {
+return NULL;
+  }
+
+  sc = fdt_size_cells(fdt, parent);
+  if (sc != 1 && sc != 2) {
+return NULL;
+  }
+
+  if (sc > ac) {
+return NULL;
+  }
+
+  val = fdt_getprop(fdt, node, "reg", &len);
+  if (len < sc + ac) {
+return NULL;
+  }
+
+  if (ac == 1) {
+start = fdt32_to_cpu(((fdt32_t *)val)[0]);
+size = fdt32_to_cpu(((fdt32_t *)val)[1]);
+  }
+
+  if (ac == 2) {
+start = fdt64_to_cpu(((fdt64_t *)val)[0]);
+
+if (sc == 1)
+  size = fdt32_to_cpu(((fdt32_t *)(val+8))[0]);
+else
+  size = fdt64_to_cpu(((fdt64_t *)val)[1]);
+  }
+
+  return (void*) (start + size);
+}
+
+static void bsp_memory_initialize( void )
+{
+  void *end;
+
+  /* get end of memory from the "/memory" node in the fdt */
+  end = get_end_of_memory_from_fdt();
+  if (end == 0) {
+/* fall back to linker symbol if "/memory" node not found or invalid */
+end = RamEnd;
+  }
+  _Memory_Initialize( &_Memory_Areas[ 0 ], WorkAreaBase, end );
+}
+
+RTEMS_SYSINIT_ITEM(
+  bsp_memory_initialize,
+  RTEMS_SYSINIT_MEMORY,
+  RTEMS_SYSINIT_ORDER_MIDDLE
+);
+
+static const Memory_Information _Memory_Information =
+  MEMORY_INFORMATION_INITIALIZER( _Memory_Areas );
+
+const Memory_Information *_Memory_Get( void )
+{
+  return &_Memory_Information;
+}
diff --git a/spec/build/bsps/riscv/riscv/obj.yml 
b/spec/build/bsps/riscv/riscv/obj.yml
index 5e767be1bb..b2eb467824 100644
--- a/spec/build/bsps/riscv/riscv/obj.yml
+

Re: libbsd fails to link on i386

2022-08-18 Thread Joel Sherrill

On Wed, Aug 17, 2022 at 6:47 PM Chris Johns  wrote:

> On 18/8/2022 7:23 am, Joel Sherrill wrote:
> > I think the wrong bus.h must be being included somewhere. These are
> static
> > inline methods on the i386. Hopefully a simple patch for someone who
> knows what
> > to do:
>
> Could it be installed with the BSP? Does it happen with a clean prefix?
>

Possible but no cookie for you today. It was a clean install and there is
no bus.h
in the install location.

In fact, there is no file named bus.h in the rtems/ source tree.

Kinsey suggested this was all a subtle matter of the order of include
directories when building but not knowing the right answer didn't let us
pursue that idea. The i386 seems to have a unique bus.h

I was remembering you battled this not so long ago and was
sincerely hoping you would spot what was wrong.

--joel

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

rtems-libbsd on x86_64

2022-08-18 Thread Joel Sherrill

Hi

I took a shot at compiling libbsd for x86_64. First issue is that freebsd
calls this amd64 so the reebsd/sys/@ARCH@/include is looking for the wrong
architecture name. Somehow the waf needs to map x86_64 to amd64.

I manually copied in_cksum.h into place and that left it failing to compile
with this:

[ 257/2034] Compiling freebsd/crypto/openssl/crypto/aes/aes_core.c
../../freebsd/sbin/sysctl/sysctl.c:67:10: fatal error: sys/efi.h: No such
file or directory
   67 | #include 
  |  ^~~
compilation terminated.

Which points to this code:

#ifdef __amd64__
#include 
#include 
#endif

There are other __amd64__ ifdefs in this file. Should I just disable these
with ifdef rtems? Or should we pull the thread? I'm prone to try to disable
the offending code fragments.

Comments and suggestions?

Thanks.

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

RE: libbsd fails to link on i386

2022-08-18 Thread Jan.Sommer

Hi Joel,



I remember I spent some time fiddling with the bus.h include order.

I can try to have a look at it some time next week.



Best regards,



Jan



From: devel  On Behalf Of Joel Sherrill
Sent: Wednesday, August 17, 2022 11:24 PM
To: rtems-de...@rtems.org 
Subject: libbsd fails to link on i386



Hi



I think the wrong bus.h must be being included somewhere. These are static 
inline methods on the i386. Hopefully a simple patch for someone who knows 
what to do:



[1992/2039] Linking build/i386-rtems6-pc386-default/ftpd01.exe
/home/joel/rtems-work/tools/6/lib/gcc/i386-rtems6/12.1.1/../../../../i386-rtems6/bin/ld:
 
./libbsd.a(rtems-kernel-bus-dma.c.20.o): in function `_bsd_bus_dmamem_alloc':
/home/joel/rtems-work/rtems-libbsd/build/i386-rtems6-pc386-default/../../rtemsbsd/rtems/rtems-kernel-bus-dma.c:264:
 
undefined reference to `bsp_bus_space_write_1'
collect2: error: ld returned 1 exit status

/home/joel/rtems-work/tools/6/lib/gcc/i386-rtems6/12.1.1/../../../../i386-rtems6/bin/ld:
 
./libbsd.a(rtems-kernel-bus-dma.c.20.o): in function `_bsd_bus_dmamem_alloc':
/home/joel/rtems-work/rtems-libbsd/build/i386-rtems6-pc386-default/../../rtemsbsd/rtems/rtems-kernel-bus-dma.c:264:
 
undefined reference to `bsp_bus_space_write_1'
collect2: error: ld returned 1 exit status

/home/joel/rtems-work/tools/6/lib/gcc/i386-rtems6/12.1.1/../../../../i386-rtems6/bin/ld:
 
./libbsd.a(rtems-kernel-bus-dma.c.20.o): in function `_bsd_bus_dmamem_alloc':
/home/joel/rtems-work/rtems-libbsd/build/i386-rtems6-pc386-default/../../rtemsbsd/rtems/rtems-kernel-bus-dma.c:264:
 
undefined reference to `bsp_bus_space_write_1'
collect2: error: ld returned 1 exit status

/home/joel/rtems-work/tools/6/lib/gcc/i386-rtems6/12.1.1/../../../../i386-rtems6/bin/ld:
 
./libbsd.a(rtems-kernel-bus-dma.c.20.o): in function `_bsd_bus_dmamem_alloc':
/home/joel/rtems-work/rtems-libbsd/build/i386-rtems6-pc386-default/../../rtemsbsd/rtems/rtems-kernel-bus-dma.c:264:
 
undefined reference to `bsp_bus_space_write_1'
collect2: error: ld returned 1 exit status

/home/joel/rtems-work/tools/6/lib/gcc/i386-rtems6/12.1.1/../../../../i386-rtems6/bin/ld:
 
./libbsd.a(rtems-kernel-bus-dma.c.20.o): in function `_bsd_bus_dmamem_alloc':
/home/joel/rtems-work/rtems-libbsd/build/i386-rtems6-pc386-default/../../rtemsbsd/rtems/rtems-kernel-bus-dma.c:264:
 
undefined reference to `bsp_bus_space_write_1'
collect2: error: ld returned 1 exit status

/home/joel/rtems-work/tools/6/lib/gcc/i386-rtems6/12.1.1/../../../../i386-rtems6/bin/ld:
 
./libbsd.a(rtems-kernel-bus-dma.c.20.o): in function `_bsd_bus_dmamem_alloc':
/home/joel/rtems-work/rtems-libbsd/build/i386-rtems6-pc386-default/../../rtemsbsd/rtems/rtems-kernel-bus-dma.c:264:
 
undefined reference to `bsp_bus_space_write_1'
collect2: error: ld returned 1 exit status

/home/joel/rtems-work/tools/6/lib/gcc/i386-rtems6/12.1.1/../../../../i386-rtems6/bin/ld:
 
./libbsd.a(rtems-kernel-bus-dma.c.20.o): in function `_bsd_bus_dmamem_alloc':
/home/joel/rtems-work/rtems-libbsd/build/i386-rtems6-pc386-default/../../rtemsbsd/rtems/rtems-kernel-bus-dma.c:264:
 
undefined reference to `bsp_bus_space_write_1'
collect2: error: ld returned 1 exit status

/home/joel/rtems-work/tools/6/lib/gcc/i386-rtems6/12.1.1/../../../../i386-rtems6/bin/ld:
 
./libbsd.a(rtems-kernel-bus-dma.c.20.o): in function `_bsd_bus_dmamem_alloc':
/home/joel/rtems-work/rtems-libbsd/build/i386-rtems6-pc386-default/../../rtemsbsd/rtems/rtems-kernel-bus-dma.c:264:
 
undefined reference to `bsp_bus_space_write_1'
collect2: error: ld returned 1 exit status



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: libbsd fails to link on i386

2022-08-18 Thread Joel Sherrill

On Thu, Aug 18, 2022, 1:09 PM  wrote:

> Hi Joel,
>
>
>
> I remember I spent some time fiddling with the bus.h include order.
>
> I can try to have a look at it some time next week.
>

Thanks.



>
> Best regards,
>
>
>
> Jan
>
>
>
> *From:* devel  *On Behalf Of *Joel Sherrill
> *Sent:* Wednesday, August 17, 2022 11:24 PM
> *To:* rtems-de...@rtems.org 
> *Subject:* libbsd fails to link on i386
>
>
>
> Hi
>
>
>
> I think the wrong bus.h must be being included somewhere. These are static
> inline methods on the i386. Hopefully a simple patch for someone who knows
> what to do:
>
>
>
> [1992/2039] Linking build/i386-rtems6-pc386-default/ftpd01.exe
> /home/joel/rtems-work/tools/6/lib/gcc/i386-rtems6/12.1.1/../../../../i386-rtems6/bin/ld:
> ./libbsd.a(rtems-kernel-bus-dma.c.20.o): in function
> `_bsd_bus_dmamem_alloc':
> /home/joel/rtems-work/rtems-libbsd/build/i386-rtems6-pc386-default/../../rtemsbsd/rtems/rtems-kernel-bus-dma.c:264:
> undefined reference to `bsp_bus_space_write_1'
> collect2: error: ld returned 1 exit status
>
> /home/joel/rtems-work/tools/6/lib/gcc/i386-rtems6/12.1.1/../../../../i386-rtems6/bin/ld:
> ./libbsd.a(rtems-kernel-bus-dma.c.20.o): in function
> `_bsd_bus_dmamem_alloc':
> /home/joel/rtems-work/rtems-libbsd/build/i386-rtems6-pc386-default/../../rtemsbsd/rtems/rtems-kernel-bus-dma.c:264:
> undefined reference to `bsp_bus_space_write_1'
> collect2: error: ld returned 1 exit status
>
> /home/joel/rtems-work/tools/6/lib/gcc/i386-rtems6/12.1.1/../../../../i386-rtems6/bin/ld:
> ./libbsd.a(rtems-kernel-bus-dma.c.20.o): in function
> `_bsd_bus_dmamem_alloc':
> /home/joel/rtems-work/rtems-libbsd/build/i386-rtems6-pc386-default/../../rtemsbsd/rtems/rtems-kernel-bus-dma.c:264:
> undefined reference to `bsp_bus_space_write_1'
> collect2: error: ld returned 1 exit status
>
> /home/joel/rtems-work/tools/6/lib/gcc/i386-rtems6/12.1.1/../../../../i386-rtems6/bin/ld:
> ./libbsd.a(rtems-kernel-bus-dma.c.20.o): in function
> `_bsd_bus_dmamem_alloc':
> /home/joel/rtems-work/rtems-libbsd/build/i386-rtems6-pc386-default/../../rtemsbsd/rtems/rtems-kernel-bus-dma.c:264:
> undefined reference to `bsp_bus_space_write_1'
> collect2: error: ld returned 1 exit status
>
> /home/joel/rtems-work/tools/6/lib/gcc/i386-rtems6/12.1.1/../../../../i386-rtems6/bin/ld:
> ./libbsd.a(rtems-kernel-bus-dma.c.20.o): in function
> `_bsd_bus_dmamem_alloc':
> /home/joel/rtems-work/rtems-libbsd/build/i386-rtems6-pc386-default/../../rtemsbsd/rtems/rtems-kernel-bus-dma.c:264:
> undefined reference to `bsp_bus_space_write_1'
> collect2: error: ld returned 1 exit status
>
> /home/joel/rtems-work/tools/6/lib/gcc/i386-rtems6/12.1.1/../../../../i386-rtems6/bin/ld:
> ./libbsd.a(rtems-kernel-bus-dma.c.20.o): in function
> `_bsd_bus_dmamem_alloc':
> /home/joel/rtems-work/rtems-libbsd/build/i386-rtems6-pc386-default/../../rtemsbsd/rtems/rtems-kernel-bus-dma.c:264:
> undefined reference to `bsp_bus_space_write_1'
> collect2: error: ld returned 1 exit status
>
> /home/joel/rtems-work/tools/6/lib/gcc/i386-rtems6/12.1.1/../../../../i386-rtems6/bin/ld:
> ./libbsd.a(rtems-kernel-bus-dma.c.20.o): in function
> `_bsd_bus_dmamem_alloc':
> /home/joel/rtems-work/rtems-libbsd/build/i386-rtems6-pc386-default/../../rtemsbsd/rtems/rtems-kernel-bus-dma.c:264:
> undefined reference to `bsp_bus_space_write_1'
> collect2: error: ld returned 1 exit status
>
> /home/joel/rtems-work/tools/6/lib/gcc/i386-rtems6/12.1.1/../../../../i386-rtems6/bin/ld:
> ./libbsd.a(rtems-kernel-bus-dma.c.20.o): in function
> `_bsd_bus_dmamem_alloc':
> /home/joel/rtems-work/rtems-libbsd/build/i386-rtems6-pc386-default/../../rtemsbsd/rtems/rtems-kernel-bus-dma.c:264:
> undefined reference to `bsp_bus_space_write_1'
> collect2: error: ld returned 1 exit status
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: rtems-libbsd on x86_64

2022-08-18 Thread Joel Sherrill

On Thu, Aug 18, 2022 at 12:09 PM Joel Sherrill  wrote:

> Hi
>
> I took a shot at compiling libbsd for x86_64. First issue is that freebsd
> calls this amd64 so the reebsd/sys/@ARCH@/include is looking for the
> wrong architecture name. Somehow the waf needs to map x86_64 to amd64.
>
> I manually copied in_cksum.h into place and that left it failing to
> compile with this:
>
> [ 257/2034] Compiling freebsd/crypto/openssl/crypto/aes/aes_core.c
> ../../freebsd/sbin/sysctl/sysctl.c:67:10: fatal error: sys/efi.h: No such
> file or directory
>67 | #include 
>   |  ^~~
> compilation terminated.
>
> Which points to this code:
>
> #ifdef __amd64__
> #include 
> #include 
> #endif
>
> There are other __amd64__ ifdefs in this file. Should I just disable these
> with ifdef rtems? Or should we pull the thread? I'm prone to try to disable
> the offending code fragments.
>

I did this to proceed and the changes were relatively minor.

Another challenge is that some x86_64 machine header files include
 to share something with x86. Looks like a place where the
include path  logic somewhere in the waf needs adjusting. No idea
where.

Assuming the include path for x86_64/amd64 is fixed and my sysctl.h patch
is applied, that only leaves three compile errors which appear to be
from the use of x86_64 and x86 machine directories.  For now, I hand
copied these files into place:

reebsd/sys/x86_64/include/machine/in_cksum.h
freebsd/sys/x86_64/include/machine/md_var.h
freebsd/sys/x86_64/include/machine/intr_machdep.h
freebsd/sys/x86_64/include/machine/specialreg.h

Pretty close with some help. Please. :)

Thanks.

>
> Comments and suggestions?
>
> Thanks.
>
> --joel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v1 09/12] malloctest/init.c: Added pragmas to address gcc 12 warnings

2022-08-18 Thread Ryan Long

On 8/16/2022 10:55 PM, Chris Johns wrote:

On 17/8/2022 12:16 pm, Joel Sherrill wrote:

On Tue, Aug 16, 2022, 6:07 PM Chris Johns mailto:chr...@rtems.org>> wrote:
 On 17/8/2022 6:11 am, Ryan Long wrote:
 > Fixed four warnings disabled were for "-Wuse-after-free" and one for a
 > "-Wfree-nonheap-object."

 Is this a gcc warning bug? If p1 was used to access the memory the warning 
is
 right but we are only referencing the address and not the data. It is no
 different to:

   void* p = 0x1;
   printf("P is %p\n", p);

 This is fine and has to be or we could never access any hardware.

That example is different I think. Semantically after a call to free, the
address is no longer valid for any use.

Ah yes sorry, I was looking at the wrong spot in the code. It is down at line 
1531.

Ensuring you don't call another member
of the malloc family is a legitimate way to avoid double frees.

Yes using the pointer is invalid.

If we have an issue with a specific use case pattern that GCC is tripping, then
we discuss it with them. I'm sure all of these were well thought out.

Besides this code is pushing deliberate error conditions so we should not be
surprised that the compiler is detecting issues with the code.

I am not sure the test is correct and should be there. Passing in and then
testing the same value is returned assumes undefined behaviour:

  If ptr does not match a pointer returned earlier by calloc(), malloc(),
  or realloc() or if the space has previously been deallocated by a call
  to free() or realloc(), the behavior is undefined.

https://pubs.opengroup.org/onlinepubs/9699919799/functions/realloc.html

For some of the tests we would just need to set p1 to NULL before the 
check then right?

Do the rest of the patches in this set look good?

Chris

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

Re: [PATCH v1 09/12] malloctest/init.c: Added pragmas to address gcc 12 warnings

2022-08-18 Thread Chris Johns

On 19/8/2022 9:02 am, Ryan Long wrote:
> On 8/16/2022 10:55 PM, Chris Johns wrote:
>> On 17/8/2022 12:16 pm, Joel Sherrill wrote:
>>> On Tue, Aug 16, 2022, 6:07 PM Chris Johns >> > wrote:
>>>  On 17/8/2022 6:11 am, Ryan Long wrote:
>>>  > Fixed four warnings disabled were for "-Wuse-after-free" and one for 
>>> a
>>>  > "-Wfree-nonheap-object."
>>>
>>>  Is this a gcc warning bug? If p1 was used to access the memory the
>>> warning is
>>>  right but we are only referencing the address and not the data. It is 
>>> no
>>>  different to:
>>>
>>>    void* p = 0x1;
>>>    printf("P is %p\n", p);
>>>
>>>  This is fine and has to be or we could never access any hardware.
>>>
>>>
>>> That example is different I think. Semantically after a call to free, the
>>> address is no longer valid for any use.
>> Ah yes sorry, I was looking at the wrong spot in the code. It is down at line
>> 1531.
>>
>>> Ensuring you don't call another member
>>> of the malloc family is a legitimate way to avoid double frees.
>> Yes using the pointer is invalid.
>>
>>> If we have an issue with a specific use case pattern that GCC is tripping, 
>>> then
>>> we discuss it with them. I'm sure all of these were well thought out.
>>>
>>> Besides this code is pushing deliberate error conditions so we should not be
>>> surprised that the compiler is detecting issues with the code.
>> I am not sure the test is correct and should be there. Passing in and then
>> testing the same value is returned assumes undefined behaviour:
>>
>>   If ptr does not match a pointer returned earlier by calloc(), malloc(),
>>   or realloc() or if the space has previously been deallocated by a call
>>   to free() or realloc(), the behavior is undefined.
>>
>> https://pubs.opengroup.org/onlinepubs/9699919799/functions/realloc.html
> 
> For some of the tests we would just need to set p1 to NULL before the check 
> then
> right?

I think so but Joel is the person to comment on the tests and standards.

> Do the rest of the patches in this set look good?

I think so. Some are hard to sort out. I have had a look and then left them. I
suppose this is why most are resorting to pragmas to handle.

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

Re: [PATCH v2 1/1] bsp/riscv: Work area size based on /memory node in fdt

Re: [PATCH v2 1/1] bsp/riscv: Work area size based on /memory node in fdt

Re: libbsd fails to link on i386

rtems-libbsd on x86_64

RE: libbsd fails to link on i386

Re: libbsd fails to link on i386

Re: rtems-libbsd on x86_64

Re: [PATCH v1 09/12] malloctest/init.c: Added pragmas to address gcc 12 warnings

Re: [PATCH v1 09/12] malloctest/init.c: Added pragmas to address gcc 12 warnings

9 matches

Site Navigation

Mail list logo

Footer information