boards: lm3s6965-ek: configuration to test nxflat on QEMU - #3763
Conversation
…nary loader mode on QEMU; Conditionally turn off -mpic-data-is-text-relative flag to access bss via the GOT (https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139630111). This is related to issue apache#3737.
a-lunev
changed the title
| -imxrt1060-evk:libcxxtest | ||
| -launchxl-cc1310:nsh | ||
| -launchxl-tms57004:nsh | ||
| -lm3s6965-ek:qemu-nxflat |
There was a problem hiding this comment.
why remove it from ci?
There was a problem hiding this comment.
why remove it from ci?
Hi @xiaoxiang781216,
Any nxflat configuration requires NXFLAT Toolchain for building. The standard GNU Toolchain will fail. (https://cwiki.apache.org/confluence/display/NUTTX/NxFlat)
I analyzed scripts in nuttx/tools/ci and I did not find NXFLAT Toolchain setup in the scripts.
There was a problem hiding this comment.
But from the comment, the special compiler flags is supported by gcc now?
There was a problem hiding this comment.
It also needs the nxflat tools. I can get the CI side sorted out today if you would like @a-lunev at least for Linux.
There was a problem hiding this comment.
But from the comment, the special compiler flags is supported by gcc now?
This has nothing to do with GCC. These are the NxFLAT tools that are provided in the Bitbucket buildroot tools. These: https://bitbucket.org/nuttx/buildroot/src/master/toolchain/nxflat/
There was a problem hiding this comment.
If that is OK with you I can submit the PR to bring that into the CI pipeline.
Sure. I we can put into a new incubator-nuttx-tools repository if you like. I have the copyright on all of the code and I think all of the nxflat code is BSD. There may be some references to some of the older XFLAT code which I released as GPL, but I wrote those too and also have the copyright. So I think that the licensing in the buildroot/toolchain/nxflat directory is okay.
The vision that I had for the buildroot tools is that that there would be once place that you could just configure and make and get all of the tools that you need. So it also build the nuttx-eabi or nuttx-elf toolchain (which is a good thing), nxflat, and things like genromfs. It is a pretty handy concept and, I think, still worthy of support.
The advantage of the nuttx-elf toolchain is that it does not include any foreign C library header files or logic; it builds against the NuttX C library and eliminates all of those incompatibilities.
There was a problem hiding this comment.
The vision that I had for the buildroot tools is that that there would be once place that you could just configure and make and get all of the tools that you need. So it also build the nuttx-eabi or nuttx-elf toolchain (which is a good thing), nxflat, and things like genromfs. It is a pretty handy concept and, I think, still worthy of support.
I still think we should use githumb.com/nuttx for this purpose. But in order to use that, I think we need to start over. Remove the garbage that has accumulated there and restrict access.
There was a problem hiding this comment.
The vision that I had for the buildroot tools is that that there would be once place that you could just configure and make and get all of the tools that you need. So it also build the nuttx-eabi or nuttx-elf toolchain (which is a good thing), nxflat, and things like genromfs. It is a pretty handy concept and, I think, still worthy of support.
The advantage of the nuttx-elf toolchain is that it does not include any foreign C library header files or logic; it builds against the NuttX C library and eliminates all of those incompatibilities.
I also like the idea to have a dedicated nuttx-elf Toolchain (like for nxflat).
There was a problem hiding this comment.
If that is OK with you I can submit the PR to bring that into the CI pipeline.
Sure. I we can put into a new incubator-nuttx-tools repository if you like. I have the copyright on all of the code and I think all of the nxflat code is BSD. There may be some references to some of the older XFLAT code which I released as GPL, but I wrote those too and also have the copyright. So I think that the licensing in the buildroot/toolchain/nxflat directory is okay.
From the header it says ldnxflat.c was originally from elf2flt.c which is GPL V2+ so I am not sure it could realistically become BSD. This makes it quite to hard to carry in a official capacity, especially with the additional dependency that it is built against binutils. Please do correct me if I am wrong here.
https://github.com/uclinux-dev/elf2flt/blob/main/elf2flt.c
The vision that I had for the buildroot tools is that that there would be once place that you could just configure and make and get all of the tools that you need. So it also build the nuttx-eabi or nuttx-elf toolchain (which is a good thing), nxflat, and things like genromfs. It is a pretty handy concept and, I think, still worthy of support.
The advantage of the nuttx-elf toolchain is that it does not include any foreign C library header files or logic; it builds against the NuttX C library and eliminates all of those incompatibilities.
Here though for nxflat tools itself I don't think we are gaining anything though as it is only using the BFD library, but please correct me if I am wrong. I do understand the benefits of having a NuttX toolchain in general.
As for the github.com/nuttx org I have no interest in it. We will likely have to remove that as part of graduation as it will be representing as the NuttX project without operating inline with the Apache requirements. These things need to be under the Apache project or be a different project. I am offering a home for this tool as I have a personal interest in it and if we do find a better place, happy to see it move there. I tried to be very upfront in README that this is your work.
There was a problem hiding this comment.
From the header it says ldnxflat.c was originally from elf2flt.c which is GPL V2+ so I am not sure it could realistically become BSD. This makes it quite to hard to carry in a official capacity, especially with the additional dependency that it is built against binutils. Please do correct me if I am wrong here.
Yeah.. I forgot about that file.
| -eagle100:thttpd | ||
| -launchxl-cc1310:nsh | ||
| -launchxl-tms57004:nsh | ||
| -lm3s6965-ek:qemu-nxflat |
| ARCHPICFLAGS += -mno-pic-data-is-text-relative | ||
| endif | ||
| endif | ||
|
|
There was a problem hiding this comment.
This needs the nxflat tools defined
diff --git a/boards/arm/tiva/lm3s6965-ek/scripts/Make.defs b/boards/arm/tiva/lm3s6965-ek/scripts/Make.defs
index 0d4d49fa1c..6460e812ff 100644
--- a/boards/arm/tiva/lm3s6965-ek/scripts/Make.defs
+++ b/boards/arm/tiva/lm3s6965-ek/scripts/Make.defs
@@ -60,6 +60,8 @@ CXXPICFLAGS = $(ARCHPICFLAGS) $(CXXFLAGS)
CPPFLAGS := $(ARCHINCLUDES) $(ARCHDEFINES) $(EXTRAFLAGS)
AFLAGS := $(CFLAGS) -D__ASSEMBLY__
+MKNXFLAT = mknxflat
+LDNXFLAT = ldnxflat
NXFLATLDFLAGS1 = -r -d -warn-common
NXFLATLDFLAGS2 = $(NXFLATLDFLAGS1) -T$(TOPDIR)/binfmt/libnxflat/gnu-nxflat-pcrel.ld -no-check-sections
LDNXFLATFLAGS = -e main -s 2048
|
Let's merge this PR first. once the toolchain issue get resolved we can remove lm3s6965-ek:qemu-nxflat from the black list. |
6 participants
boards: lm3s6965-ek: added config to run NuttX with enabled NXFLAT binary loader mode on QEMU;
Conditionally turn off -mpic-data-is-text-relative flag to access bss via the GOT (https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139630111).
This is related to issue #3737.