Am I building it correctly for my 9xr-pro?
Opened this issue · 10 comments
I've been struggling quite a bit to get the firmware to build for my 9XR-PRO.
I checked out the ersky9xr_r220 tag so I was working with a release that is known to work.
The most difficulty was in finding out how to invoke make.
Eventually the following did the trick (I think), but I don't know if this is correct:
$ make REVB=1 REVX=1
This does produce a rom.bin file and I've been brave enough to install it on my radio and it actually seems to work.
As compiler I've been using arm-none-eabi-gcc version 6.3.1 20170215 [ARM/embedded-6-branch revision 245512] that I installed on macOS via
brew cask install gcc-arm-embedded
The code has some case mismatches in filenames when #including files. So building on a case sensitive file systems like e.g. Ubuntu running in Windows Subsystem for Linux was problematic and needed fixes, but I eventually also got it building there.
Anyway, can you confirm that this is the correct way to build the firmware for my 9xr-pro?
make REVB=1 REVX=1
is the correct command line for the 9XR-PRO.
I'm still using a compiler around 4.7.2 on windows, since I haven't found a pre-built later version.
If you can detail specific #include statements with the wrong case, I'll get them corrected in the source code.
Thanks for the info Mike!
W.r.t. to case mismatch between #include and real file names, I found these:
menus.cpp:#include "S6Rimg.lbm"
Where the file itself is called s6rimg.lbm
mavlink/Mavlink.cpp:#include "Mavlink.h"
This aliases to mavlink.h in the parent folder, but I think the whole #include should be commented out.
Hi,
I am also finding problems with compiling the master branch under Linux for 9XR-Pro
..................................................................................................................
In file included from mavlink.cpp:21:0:
mavlink/Mavlink.cpp:25:21: fatal error: Mavlink.h: No such file or directory
#include "Mavlink.h"
^
compilation terminated.
..................................................................................................................
Commenting the whole #include line does not solve the problem.
Is there a missing file on the mavlink/ directory?
Thanks in advance for your help
Miguel
This Mavlink.cpp should be including "mavlink.h" from the "src" directory, although the #include in the .cpp file may have an uppercase 'M' that is causing you a problem on Linux.
My source code now has:
#include "mavlink.h"
in it, but the file is not committed to Github so that may be the change you need. I'm using windows so I think the incorrect case character doesn't cause a problem for me.
With this change I find a different beast:
/usr/lib/gcc/arm-none-eabi/4.8/../../../arm-none-eabi/bin/ld: section .eh_frame loaded at [0000000000442340,0000000000442377] overlaps section .data loaded at [0000000000442340,0000000000442527]
Puzzling, I was compiling without a problem last time I tried, maybe a month ago, same machine, same compiler.
Miguel
I can compile the branch "next" after adding the file s6rimg.lbm (from the master branch) and changing Mavlink to mavlink in the code and also the file name from mavlink/Mavlink.cpp to mavlink/mavlink.cpp.
I also get several compiler warnings in relation with strict aliasing.
Still no luck with the master branch.
Miguel
EDITED to add: I see only now that you are making new commits on the master branch. I thought without any base that this one was stable and the new commits where going to the next branch. Should have checked first, my fault.
Does the latest commit from the master branch now compile OK then?
No, current version of master does not compile under Linux with this rather standard toolchain:
mentero@momo ~/Desktop/mbtx-er9X/mbtx-master/radio/ersky9x/src $ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.2 (Debian 4.9.2-10)
But my previously downloaded version on April 25 does compile with no issues.
I don't get a section.eh_frame when I compile. It seems to be something to do with exception handling, which is not used.
As a suggestion, try modifying "sam3s8c_flash.ld", and add the eh_frame line to the DISCARD statement:
/DISCARD/ :
{
/* libc.a ( * ) /
libm.a ( * )
/ libgcc.a ( * ) */
*(.eh_frame)
}
I'm using compiler version 4.7.2. I did just try 4.8.3, and then downloaded the latest (6.something) and tried that. None of them produced an eh_frame. All under windows, and I only use this compiler for compiling for the ARM processor.
Yes, that did the trick!.
arm-none-eabi-objcopy -O ihex ersky9xr_rom.elf ersky9xr_rom.hex
arm-none-eabi-objcopy -O binary ersky9xr_rom.elf ersky9xr_rom.bin
arm-none-eabi-objdump -h -S ersky9xr_rom.elf > ersky9xr_rom.lss
text data bss dec hex filename
271180 492 43472 315144 4cf08 ersky9xr_rom.elf
Thank you.
Miguel