I'm planing to preprare an RPM package of NXT software to have fully reproducible and stable build system.

Basically I've managed to compile the latest stable version from the svn tag lejos_nxj_0.9.1-3[1] (as the official sources doesn't contain eclipse plugin sources) and it works quite well (tools, examples, eclipse plugin). The only remaining issue I have is with the lejos_nxt_rom.bin binary blob. Generally I used the available arm-none-eabi toolchain to compile it, more precisely the following versions:

and the compilation succeded but the output image once flashed doesn't boot. It probably might require some changes as it uses none-eabi instead of the arm-elf ABI comparing to the nxtvm/build_arm_toolchain.sh script. On the other hand I'm using this toolchain without any problems to package the libnxt[2] and it works. Based on that I'm suppose that it could be used to prepare the lejos image as well.

Do you have some ideas what changes might be neccessary in order to compile and use the image using this toolchain?

BTW. I saw that Debian packagers had noticed similar problem (requirement of using non available toolchain) while trying to prepare the lejos[3] package.

The toolchain we use was selected after a lot of time and effort, looking at both code quality and size. Newer versions of the compiler produce larger slower code and also cause issues with some of the optimizations. I have no idea why it does not boot, but note that the flash tools (and some of the assembler routines, and the low level data access code) may make assumptions about the layout of the binary image which may not hold true for your image. I would not recommend using anything other than the toolchain we have selected, even if you manage to get a working image, unless the final image is identical to the standard VM there will be support issues, I doubt if you will get much help with investigating and fixing any problems that are only seen with your build.

What are the reasons for not using the toolchain used to build the release image?

What Andy said ...If you're an expert you may be able to make our firmware sources work with your own toolchain. But for now, use the toolchain built by the shell script that you find in SVN. That our firmware doesn't run with all toolchains might be an issue with our sources, linker script, or whatever. I have never looked into this. Also, you need to make sure that you have an arm-elf (not arm-eabi) toolchain which supports interworking. Again, I did not look into how to make our firmware work with arm-eabi toolchains. But even if it builds and runs, you will run into other issues like performance, firmware size, etc.

Also, I strongly doubt that Debian and Fedora ask package maintainers to compile every firmware BLOB from scratch.

gloomyandy wrote:What are the reasons for not using the toolchain used to build the release image?

I've even tried to use the nxtvm/build_arm_toolchain.sh script to regenerate the toolchain but the compilation failed. Besides I'm not sure that in this form it can be included in the distribution. That is why I'm trying to use the available one.

gloomyandy wrote:What are the reasons for not using the toolchain used to build the release image?

I've even tried to use the nxtvm/build_arm_toolchain.sh script to regenerate the toolchain but the compilation failed. Besides I'm not sure that in this form it can be included in the distribution. That is why I'm trying to use the available one.

Googling for a while pointed me to the lejos-osek[5] which seems to use similar arm-non-eabi toolchain for producing firmware image for NXT brick, there are additional section definition like .ARM.exidx, but I'm not an expert in this area.

I think, I could also try to compare the output from your toolchain with the one included in the Fedora distribution, but as aforementioned I wasn't able to recompile yours. Would it be possible that you can share the link where I can download exactly the same toolchain, in a precompiled form (for linux x86 platform), you're using to release the lejos_nxt_rom.bin file?

gloomyandy wrote:What are the reasons for not using the toolchain used to build the release image?

I've even tried to use the nxtvm/build_arm_toolchain.sh script to regenerate the toolchain but the compilation failed. Besides I'm not sure that in this form it can be included in the distribution. That is why I'm trying to use the available one.

That links says "All program binaries and program libraries ...". I don't think that the firmware BLOB satisfies the definition of program binary and program library. A few sentences down, they state that program binaries and libraries are basically all executable files and all *.a and *.so files. The firmware BLOB is none of the above.

Also please consider, that distributions ship a lot of precompiled firmware BLOBs. Some examples are: CPU microcode, the firmware for your DVB-T stick, the firmware of your Wifi card, etc.

dwrobel wrote:Googling for a while pointed me to the lejos-osek[5] which seems to use similar arm-non-eabi toolchain for producing firmware image for NXT brick, there are additional section definition like .ARM.exidx, but I'm not an expert in this area.

I'm not quite sure what lejos-osek is. I think it's some fork of the leJOS firmware, with the Java part removed. Also consider that the fork happened many years ago.

I have worked with an ARM-eabi toolchain before. I wrote a linker script with a colleague of mine for a C++ project on a recent ARM cortex processor. As far as I recall, the exidx section was only for debugging information and inclusion in the firmware BLOB is not required. Anyhow, to track down all the problems with recent eabi toolchains, you really need to dig into the code. There might be problems with the compiler, the libc version, binutils, and whatnot. I can't tell right now, as I don't have time to dig into these issues and I don't even have a working setup (JTAG debugger and whatnot) right now.

dwrobel wrote:I think, I could also try to compare the output from your toolchain with the one included in the Fedora distribution, but as aforementioned I wasn't able to recompile yours. Would it be possible that you can share the link where I can download exactly the same toolchain, in a precompiled form (for linux x86 platform), you're using to release the lejos_nxt_rom.bin file?

I'm not sure how comparing the code would help. The diff will be rather large. It will still be like searching the needle in the haystack.

gloomyandy wrote:What are the reasons for not using the toolchain used to build the release image?

I've even tried to use the nxtvm/build_arm_toolchain.sh script to regenerate the toolchain but the compilation failed. Besides I'm not sure that in this form it can be included in the distribution. That is why I'm trying to use the available one.

Thanks. In such cases it always helps if you use -j1 instead of -j2 (which I chose to be the default, see MAKEOPTS in the shell script).However, I think the error that makes the build fail is "/home/dw/projects/rpmbuild/BUILD/lejos/nxtvm/src/gcc-4.3.2/gcc/doc/cppopts.texi:757: @itemx must follow @item".That seems related to documentation! Do you have latex installed? Maybe we need to pass a configure options to gcc to disable building the documentation.

Now the pacakge is almost ready. It allows either to reuse the binary NXT firmware blob without recompilation or recompile it using either the arm-elf-gcc or the arm-none-eabi-gcc toolchain with the information that the build compiled with the arm-none-eabi-gcc toolchain is currently not supported.

As of now the package compiles successfully from scratch on Fedora 20 where the ant 1.9.2 and java 1.7.0 is being used, however it fails on Fedora rawhide (the development version) where the ant 1.9.4 and java 1.8.0 is used.

where %{version} = 0.9.1 the %add_maven_depmap is documented here. I just need your opinion about the selected groupId:artifactId. Please fell free to suggest the correct ones according to your preferences.

I am rather puzzled by this effort and why we would think it is a good thing? Do you intend to test all of the components you are building? Do you intend to help users with any problems that may show up when using this build? In effect you are creating a fork of leJOS, why is this a good thing?

gloomyandy wrote:I am rather puzzled by this effort and why we would think it is a good thing? Do you intend to test all of the components you are building?

I'm trying to get lejos-nxj included in the Fedora distribution. To achieve it I just need to recompile from sources all the necessary components, as this is the requirement from the distribution point of view. More information can found here

gloomyandy wrote:In effect you are creating a fork of leJOS, why is this a good thing?

I'm absolutely far from that, It would be really appreciated if I could just download original source tarball, unpack it, type make and got all the binaries recompiled. If you could help me to reach that stage it would be really appreciated. It would also help wider adaptation of lejos amongst different distributions.

gloomyandy wrote:The toolchain we use was selected after a lot of time and effort, looking at both code quality and size. Newer versions of the compiler produce larger slower code and also cause issues with some of the optimizations.

I've compiled some sources using clang-3.5, the generated report could give you some hints about potential places which might not work while the code get optimized. Using newer version of gcc with optimizations turned on could remove entirely the read from the AT91C_PIOA_ISR register in line 118 from generated code, additionally both reads from AT91C_PIOA_ISR and AT91C_PIOA_PDSR can be completely reordered. More information can be found here.

On the other hand I was able to just compile and boot succesfully the embox project on my NXT. This project uses the arm-none-eabi-gcc toolchain which currently seems to be preffered toolchain from distribution's point of view. In other words having possibility to use this toolchain would significantly help maintaining lejos package. Please consider to support it.