On 24/10/2019 07:10, Chris Johns wrote:
For newlib, I'm caught up at the moment. Not sure about Sebastian.
I wait since one month for a Newlib patch approval.
Is this important to 5?
Yes, it is quite important if we want to keep the libbsd up to date.
Is it just not review and so would a ping
On 24/10/19 4:03 pm, Sebastian Huber wrote:
> On 24/10/2019 07:00, Chris Johns wrote:
>> On 23/10/19 5:18 pm, Sebastian Huber wrote:
>>> On 22/10/2019 14:45, Joel Sherrill wrote:
I would like to see most targets moved to newer major versions but I think
at
least the PowerPC will wan
On 24/10/2019 07:00, Chris Johns wrote:
On 23/10/19 5:18 pm, Sebastian Huber wrote:
On 22/10/2019 14:45, Joel Sherrill wrote:
I would like to see most targets moved to newer major versions but I think at
least the PowerPC will want to bump for the upcoming gcc 7 release.
Yes. For all targets
On 23/10/19 5:18 pm, Sebastian Huber wrote:
> On 22/10/2019 14:45, Joel Sherrill wrote:
>> I would like to see most targets moved to newer major versions but I think at
>> least the PowerPC will want to bump for the upcoming gcc 7 release.
>
> Yes. For all targets except powerpc I would directly m
On Wed, Oct 23, 2019 at 6:04 AM Thomas Doerfler
wrote:
>
> Hi,
>
> most likely the RAM areas have been mapped to the lowest-possible
> non-NULL address, and they can be mapped to an address boundary matching
> the RAM size. zc702 has a 1MByte ram, mapped to the 1MByte boundary,
> zc706 has a 4MByt
Hi,
I submitted a RFC patch series to be able to build RTEMS/RISC-V with
LLVM/Clang. I'd appreciate your feedback on that.
A sample configure line to build RTEMS with LLVM/Clang is:
../rtems/configure --target=riscv-rtems6
--enable-rtemsbsp=rv64imafdc_clang CC_FOR_TARGET="clang"
CXX_FOR_TARGET=
---
bsps/riscv/shared/start/linkcmds.base.in | 5 +
1 file changed, 5 insertions(+)
diff --git a/bsps/riscv/shared/start/linkcmds.base.in
b/bsps/riscv/shared/start/linkcmds.base.in
index 7d6a23cde0..d921e29fe4 100644
--- a/bsps/riscv/shared/start/linkcmds.base.in
+++ b/bsps/riscv/shared/star
LLVM/LLD does not support STARTUP and ALIGN_WITH_INPUT directives that
GNU LD support. INPUT and ALIGN(8) are supported by LLVM/LLD and can
replace the unsupported STARTUP/ALIGN_WITH_INPUT directives.
The commit conditionally adds the supported directive that linkers
can understand depending on th
ld.lld defaults .work to PROGBITS otherwise
---
bsps/riscv/shared/start/linkcmds.base.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/bsps/riscv/shared/start/linkcmds.base.in
b/bsps/riscv/shared/start/linkcmds.base.in
index 857bf2dabd..7d6a23cde0 100644
--- a/bsps/riscv/sha
This commit moves the existing linkcmds.base to linkcmds.base.in
in order to make it configurable by autotools.
---
bsps/riscv/shared/start/{linkcmds.base => linkcmds.base.in} | 0
c/src/lib/libbsp/riscv/riscv/Makefile.am| 2 +-
c/src/lib/libbsp/riscv/riscv/configure.ac
---
bsps/riscv/riscv/config/rv64imafdc_clang.cfg | 14 ++
1 file changed, 14 insertions(+)
create mode 100644 bsps/riscv/riscv/config/rv64imafdc_clang.cfg
diff --git a/bsps/riscv/riscv/config/rv64imafdc_clang.cfg
b/bsps/riscv/riscv/config/rv64imafdc_clang.cfg
new file mode 100644
in
Hello,
I checked in four patches to simplify the linkcmds generation. I hope
that I didn't break anything with this.
The patches help a bit to get started with the new build system.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 1
Hi,
most likely the RAM areas have been mapped to the lowest-possible
non-NULL address, and they can be mapped to an address boundary matching
the RAM size. zc702 has a 1MByte ram, mapped to the 1MByte boundary,
zc706 has a 4MByte RAM mapped to the 4MByte boundary.
Having an identical starting ad
Hello,
why is the ZYNQ_RAM_ORIGIN different in these two BSP variants?
AS_IF([test "x${RTEMS_BSP}" == xxilinx_zynq_zc702],
[ZYNQ_RAM_ORIGIN="0x0010"
ZYNQ_RAM_MMU="${ZYNQ_RAM_ORIGIN}"
ZYNQ_RAM_MMU_LENGTH="16k"
ZYNQ_RAM_ORIGIN_AVAILABLE="${ZYNQ_RAM_ORIGIN} + 0x40
14 matches
Mail list logo