Re: libbsd fails to link on i386

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? Chris _

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

Re: qoriq build of rtems-libbsd

And the same error happens on qm8xx_stk8xx. On Wed, Aug 17, 2022 at 4:01 PM Joel Sherrill wrote: > Sorry. Forgot to update my libbsd tree and got the wrong error. It is this: > > /home/joel/rtems-work/tools/6/lib/gcc/powerpc-rtems6/12.1.1/../../../../powerpc-rtems6/bin/ld: > ./libbsd.a(nfs_clbio

Re: qoriq build of rtems-libbsd

Sorry. Forgot to update my libbsd tree and got the wrong error. It is this: /home/joel/rtems-work/tools/6/lib/gcc/powerpc-rtems6/12.1.1/../../../../powerpc-rtems6/bin/ld: ./libbsd.a(nfs_clbio.c.10.o): the target (_bsd_unmapped_buf) of a R_PPC_SDAREL16 relocation is in the wrong output section (.da

qoriq build of rtems-libbsd

Hi Not sure what's going on but 6-freebsd-12 does not build for qoriq_e6500_32 In file included from parse.y:88: ../../freebsd/sbin/pfctl/pfctl_parser.h:181:27: error: expected ')' before numeric constant 181 | BITSET_DEFINE(qpri_bitset, QPRI_BITSET_SIZE); | ^

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

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 |

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

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(+)

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

Sure, I can move it to the shared directory (riscv/shared/start). On 2022-08-17 11:16, Hesham Almatary wrote: Thanks for the patch. LGTM. I wonder if we can also reuse that for the generic shared RISC-V BSP (e.g., bsps/riscv/riscv) instead of just NOEL? On Wed, 17 Aug 2022 at 09:58, Daniel Ced

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

Thanks for the patch. LGTM. I wonder if we can also reuse that for the generic shared RISC-V BSP (e.g., bsps/riscv/riscv) instead of just NOEL? On Wed, 17 Aug 2022 at 09:58, Daniel Cederman wrote: > Uses the first entry in the /memory node to determine the end of the > work area. Falls back on l

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

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/noel/start/bspgetworkarea.c | 144 + spec/build/bsps/riscv/noel/obj.yml | 1 + 2 files changed, 145 insertions(+) c

Re: [PATCH v4 1/2] bsp/riscv: Work area size based on stack pointer

On 2022-08-15 17:19, Hesham Almatary wrote: On Mon, 15 Aug 2022 at 15:35, Daniel Cederman wrote: On 2022-08-15 15:43, Hesham Almatary wrote: On Mon, 15 Aug 2022 at 08:16, Daniel Cederman wrote: From: Martin Aberg Remember the initial stack pointer in start.S. It can later be used to determ