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
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
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
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
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(+)
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 |
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);
| ^
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
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
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/../../../../
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
_
11 matches
Mail list logo