Can't build FrSky X9D targets #1818

breadoven · 2022-04-10T10:03:11Z

breadoven
Apr 10, 2022

Trying to build FrSky X9D targets from upstream/main and have the following problems:

Using:

cmake -DPCB=X9E -DDEFAULT_MODE=2 -DGVARS=YES -DPPM_UNIT=PERCENT_PREC1 -DHELI= NO -DCMAKE_BUILD_TYPE=Release ../

The following error occurs (also for X9D and X9D+):

/mnt/f/EdgeTXDev/radio/src/io/frsky_firmware_update.cpp: In member function 'void FrskyDeviceFirmwareUpdate::sendFrame(
':
/mnt/f/EdgeTXDev/radio/src/io/frsky_firmware_update.cpp:254:7: error: 'IntmoduleSerialDriver' was not declared in this scope
  254 |       IntmoduleSerialDriver.sendBuffer(uart_ctx, outputTelemetryBuffer.data,
      |       ^~~~~~~~~~~~~~~~~~~~~
/mnt/f/EdgeTXDev/radio/src/io/frsky_firmware_update.cpp: In member function 'const char* FrskyDeviceFirmwareUpdate::doFlashFirmware(const char*, ProgressHandler)':
/mnt/f/EdgeTXDev/radio/src/io/frsky_firmware_update.cpp:367:30: error: 'serialInitParams' was not declared in this scope; did you mean 'pxx2SerialInitParams'?
  367 |       etx_serial_init params(serialInitParams);
      |                              ^~~~~~~~~~~~~~~~
      |                              pxx2SerialInitParams
/mnt/f/EdgeTXDev/radio/src/io/frsky_firmware_update.cpp:369:18: error: 'IntmoduleSerialDriver' was not declared in this scope
  369 |       uart_ctx = IntmoduleSerialDriver.init(&params);
      |                  ^~~~~~~~~~~~~~~~~~~~~
/mnt/f/EdgeTXDev/radio/src/io/multi_firmware_update.cpp: In member function 'virtual void MultiInternalUpdateDriver::init(bool)':
/mnt/f/EdgeTXDev/radio/src/io/multi_firmware_update.cpp:104:18: error: 'IntmoduleSerialDriver' was not declared in this scope
  104 |       uart_ctx = IntmoduleSerialDriver.init(&params);
      |                  ^~~~~~~~~~~~~~~~~~~~~
make[3]: *** [radio/src/CMakeFiles/firmware.dir/build.make:83: radio/src/CMakeFiles/firmware.dir/io/frsky_firmware_update.cpp.o] Error 1

Also for X9D+ 2019 there is FLASH overflow occurring.

Using:

cmake -DPCB=X9D+ -DPCBREV=2019 -DDEFAULT_MODE=2 -DGVARS=YES -DPPM_UNIT=PERCENT_PREC1 -DHELI=NO -DCMAKE_BUILD_TYPE=Release ../

/opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/bin/ld: ../../firmware.elf section `.text' will not fit in region `FLASH'
/opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/bin/ld: region `FLASH' overflowed by 5100 bytes
collect2: error: ld returned 1 exit status

Building using using Windows WSL Ubuntu 20.04 which works fine for all other targets. Any idea what the problem is here ? Doesn't make much sense given these targets build OK for the Nightly's.

Answered by breadoven

Apr 14, 2022

OK I think I've worked out what's happening here. The CMakeCache.txt file in the Build folder doesn't get reset between radio builds, it keeps the settings of the previous build which may not be correct for the current radio type (expected I guess since it is a cache file). So if you run X9D+ 2019 it sets up PXX2 support by default setting this ON in the cache file. If you then build the X9D radio it adds support for PXX1 but when you run the build it also includes PXX2 from the previous build causing the build to crash because PXX2 isn't compatible with the X9D. The Nightly run script deletes the CMakeCache file between each build avoiding this problem.

I think this needs clarifying in t…

View full answer

pfeerick · 2022-04-12T06:08:51Z

pfeerick
Apr 12, 2022
Maintainer

For the first cmake... you specified -DPCB=X9E instead of -DPCB=X9D ... although that should have built the firmware without error still.

Both cmake lines look ok, and build for me.

I would double check you're on the latest commit of main , as those frsky_firmware_update.cpp errors look reminiscent to errors that were fixed about 10-14 days ago, although they only seemed to effect companion builds... Are you using something like the following to run the actual firmware build?

make -j`nproc` firmware

0 replies

breadoven · 2022-04-12T10:14:04Z

breadoven
Apr 12, 2022
Author

Thanks for the reply. Should have said X9 targets but it makes no difference. The only X9 that builds is the Lite.

Command to build is make -j'nproc' firmware and my local main branch is up to date with the remote main.

However, I've just built the X9 targets in Gitpod and there are no problems doing it that way so it seems this is an issue building locally using WSL. (WSL1 not 2 since 2 is way too slow).

I did notice there are some differences when the build environment is set up so don't know if that's the issue. WSL is adding support for USB Serial, PXX1, MULTI and CRSF which Gitpod doesn't do. Also version numbers of components are different. I tried removing PXX1, MULTI and CRSF and the FLASH overflow reduced but still occurred. The other X9 targets failed with the same error as before.
(Ignore the commit numbers, WSL was building from Main, Gitpod from my dev branch).

LOCAL WSL:
Failed build with FLASH overflow but otherwise no errors.

cmake -DPCB=X9D+ -DPCBREV=2019 -DDEFAULT_MODE=2 -DGVARS=YES -DPPM_UNIT=PERCENT_PREC1 -DHELI=NO -DCMAKE_BUILD_TYPE=Release ../
-- EdgeTX 2.8.0 @ f475a9ce
-- Python found, version: 3.8.10
-- Qt Version: 5.12.8
-- Foxlib found at /usr/lib/x86_64-linux-gnu/libFOX-1.6.so
-- SDL Lib: /usr/lib/x86_64-linux-gnu/libSDL.so;-lpthread; Headers: /usr/include/SDL; Version: 1.2.15
-- Adding support for USB serial
-- Adding support for PXX1 as internal module
-- Adding support for PXX2 as internal module
-- Adding support for MULTI as internal module
-- Adding support for CRSF as internal module
Storage conversion: 219
TARGET simu/libsimulator: cpp compiler /usr/bin/c++ v9
-- Added optional gtests target
TARGET bootloader: cpp compiler arm-none-eabi-g++ v10.2.1
TARGET firmware: cpp compiler arm-none-eabi-g++ v10.2.1
-- Simulators library search path: ../lib/companion28
TARGET companion28: cpp compiler /usr/bin/c++ v9
-- Added optional gtests-companion target
-- install /mnt/f/EdgeTXDev/build to /usr/local/bin
-- linuxdeployqt will be downloaded
-- Configuring done
-- Generating done

GITPOD:
Builds OK.

cmake -DPCB=X9D+ -DPCBREV=2019 -DDEFAULT_MODE=2 -DGVARS=YES -DPPM_UNIT=PERCENT_PREC1 -DHELI=NO -DCMAKE_BUILD_TYPE=Release ../
CMake Warning (dev) at CMakeLists.txt:1 (project):
  Policy CMP0048 is not set: project() command manages VERSION variables.
  Run "cmake --help-policy CMP0048" for policy details.  Use the cmake_policy
  command to set the policy and suppress this warning.

  The following variable(s) would be set to empty:

    CMAKE_PROJECT_VERSION
    CMAKE_PROJECT_VERSION_MAJOR
    CMAKE_PROJECT_VERSION_MINOR
    CMAKE_PROJECT_VERSION_PATCH
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Deprecation Warning at CMakeLists.txt:19 (cmake_policy):
  The OLD behavior for policy CMP0023 will be removed from a future version
  of CMake.

  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW
  behavior and not rely on setting a policy to OLD.


-- EdgeTX 2.8.0 @ db577a93
-- Python found, version: 3.6.9
-- Qt Version: 5.12.9
-- Foxlib found at /usr/lib/x86_64-linux-gnu/libFOX-1.6.so
-- SDL Lib: /usr/lib/x86_64-linux-gnu/libSDL.so;-lpthread; Headers: /usr/include/SDL; Version: 1.2.15
-- Googletest will be downloaded
-- Adding support for PXX2 as internal module
Storage conversion: 219
TARGET simu/libsimulator: cpp compiler /usr/bin/c++ v7
-- Added optional gtests target
TARGET bootloader: cpp compiler arm-none-eabi-g++ v10.2.1
TARGET firmware: cpp compiler arm-none-eabi-g++ v10.2.1
-- Simulators library search path: ../lib/companion28
TARGET companion28: cpp compiler /usr/bin/c++ v7
-- Added optional gtests-companion target
CMake Deprecation Warning at companion/src/CMakeLists.txt:354 (cmake_policy):
  The OLD behavior for policy CMP0026 will be removed from a future version
  of CMake.

  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW
  behavior and not rely on setting a policy to OLD.


-- install /workspace/edgetx/build to /usr/local/bin
-- linuxdeployqt will be downloaded
-- Configuring done

1 reply

pfeerick Apr 12, 2022
Maintainer

I would check the version of cmake being used then, as maybe an older version is being used in your WSL1 environment, resulting in some of the directives are not being followed. As I'm guessing since you're using WSL1 instead of WSL2 this also means you're not using the docker build environment (which is what gitpod is also using)?

It's interesting that WSL2 is slower for you... I found the exact opposite... but you must ensure that the repo checkout / build is being done within the WSL2 filesystem... otherwise it will be slow, as you are not taking advantage of the native filesystem support (NTFS into WSL2 == suck eggs performance).

breadoven · 2022-04-13T09:00:22Z

breadoven
Apr 13, 2022
Author

I got these 9X targets to build in the end but only by switching off a few of what seem to be default settings in the build configuration. These worked:

cmake -DPCB=X9D -DINTERNAL_MODULE_PXX1=ON -DINTERNAL_MODULE_MULTI=OFF -DINTERNAL_MODULE_CRSF=OFF -DINTERNAL_MODULE_PXX2=OFF -DDEFAULT_MODE=2 -DGVARS=YES -DPPM_UNIT=PERCENT_PREC1 -DHELI=NO -DENABLE_SERIAL_PASSTHROUGH=OFF -DCMAKE_BUILD_TYPE=Release ../

cmake -DPCB=X9D+ -DPCBREV=2019 -DINTERNAL_MODULE_PXX1=ON -DINTERNAL_MODULE_PXX2=OFF -DINTERNAL_MODULE_MULTI=OFF -DINTERNAL_MODULE_CRSF=OFF -DDEFAULT_MODE=2 -DGVARS=NO -DPPM_UNIT=PERCENT_PREC1 -DHELI=NO -DENABLE_SERIAL_PASSTHROUGH=OFF -DCMAKE_BUILD_TYPE=Release ../

cmake -DPCB=X9E -DINTERNAL_MODULE_PXX1=OFF -DINTERNAL_MODULE_PXX2=OFF -DINTERNAL_MODULE_MULTI=OFF -DINTERNAL_MODULE_CRSF=OFF -DDEFAULT_MODE=2 -DGVARS=YES -DPPM_UNIT=PERCENT_PREC1 -DHELI=NO -DENABLE_SERIAL_PASSTHROUGH=OFF -DCMAKE_BUILD_TYPE=Release ../

The X9D+ 2019 firmware.bin file based on the above settings is 515KB vs 512KB for the latest Nightly build. No GVARS defined or it overflows FLASH. So there is a size difference but then I don't know what settings the Nightly build is using (PXX1 defined ? uses ~4K). Also, don't know what settings Gitpod is using (couldn't figure out where the cmake_options.txt file is being generated).

And the above were built in WSL1. I did move the repository into the WSL drive/folder and converted to WSL2 and it is indeed a bit faster. However, it caused problems with other windows based programs I use which then suffer the painfully slow file access issues so I gave up with it and went back to WSL1 since it appears it probably wasn't causing the build problems anyway.

So don't know if there's an issue building in WSL or whether the cmake options simply need clarifying in the Wiki because the default cmake setup includes options that don't seem to work for the X9 targets.

1 reply

pfeerick Apr 13, 2022
Maintainer

The 'explicit' options used by the nighties are listed here... https://github.com/EdgeTX/edgetx/blob/main/tools/build-gh.sh ... if you are using the same parameters, and getting completely different file sizes, something is broken in your build environment setup... doubly so if it is adding things like Adding support for PXX1 as internal module which are not done on the gitpod / docker build environments. Are you using the correct version of cmake? We install a newer version from Kitware rather than the stock one in the repos for in ubuntu1804

root@a3b726ba7247:/src/build-TX16S# cmake --version
cmake version 3.22.1

breadoven · 2022-04-13T09:15:58Z

breadoven
Apr 13, 2022
Author

I'll check what the Nightly is using and compare.

Also my cmake version is 3.16.3 so could do with updating.

Thanks.

1 reply

pfeerick Apr 13, 2022
Maintainer

This may help when updating it...
https://github.com/EdgeTX/build-edgetx/blob/099d6d465d1fb60f6db22bd086e3f42ce4622814/dev/Dockerfile#L12-L16

breadoven · 2022-04-13T21:34:52Z

breadoven
Apr 13, 2022
Author

Thanks for the cmake update link.

Regarding the Nightly build options given above. What is EXTRA_OPTIONS ?. Can't find any definition for this which is problematic given it likely includes the options I'm after.

1 reply

pfeerick Apr 13, 2022
Maintainer

Nope, nada... try again :-P EXTRA_OPTIONS is exactly that, provision for extra options to be passed... of which there are none. ;) This is for if you were to run the build-gh.sh manually/locally... and want to pass more options than are used by default. As you can see from the output from a nightly job... there are no parameters given in order the following are the values that were set for SRCDIR, BUILD_TYPE, COMMON_OPTIONS, EXTRA_OPTIONS during the last nightly build for X9D as per the build log.

 : /__w/edgetx/edgetx/./tools/..
+ : Release
+ : -DCMAKE_BUILD_TYPE=Release -DCMAKE_RULE_MESSAGES=OFF -DDISABLE_COMPANION=YES -Wno-dev
+ :

breadoven · 2022-04-14T08:32:13Z

breadoven
Apr 14, 2022
Author

OK I think I've worked out what's happening here. The CMakeCache.txt file in the Build folder doesn't get reset between radio builds, it keeps the settings of the previous build which may not be correct for the current radio type (expected I guess since it is a cache file). So if you run X9D+ 2019 it sets up PXX2 support by default setting this ON in the cache file. If you then build the X9D radio it adds support for PXX1 but when you run the build it also includes PXX2 from the previous build causing the build to crash because PXX2 isn't compatible with the X9D. The Nightly run script deletes the CMakeCache file between each build avoiding this problem.

I think this needs clarifying in the Wiki. All it says there is "To build for other radios, you just need to select another build target by specifying appropriate values for PCB and PCBREV for your radio". Needs to mention deleting the CMakeCache file between different radio builds to avoid unwanted/incompatible options being included ... or some other smarter solution.

The X9D+ 2019 builds at 512K if I delete the CMakeCache file before building, same size as the Nightly build.

1 reply

pfeerick Apr 14, 2022
Maintainer

Derp... yes, that is the case... it just needs clarifying... as this is normal and expected. If you compile for different radios, it is customary to build to separate build folders for each, as if you don't, you don't get any of the benefits of incremental compilation... you would be effectively completely building each time, rather than only compiling any changes.

breadoven · 2022-04-14T09:25:50Z

breadoven
Apr 14, 2022
Author

Ah different build folders per radio ... didn't realise that was possible. That should make different radio builds easier. Probably that's the bit needs adding to the Wiki. Only drawback I guess is each Build folder is almost a GB so not so good if you're tight on disk space.

1 reply

pfeerick Apr 14, 2022
Maintainer

True... but that case... you delete the folder ;)

HThuren · 2022-09-04T12:25:03Z

HThuren
Sep 4, 2022

Maybe add "rm -f CMakeCache.txt arm-none-eabi/CMakeCache.txt" to tools\msys2_fetch_and_build_all_tx16s.sh file, before 1. cmake call, to show the need

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Can't build FrSky X9D targets #1818

{{title}}

Replies: 8 comments 6 replies

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

Select a reply

Can't build FrSky X9D targets #1818

breadoven Apr 10, 2022

Replies: 8 comments · 6 replies

pfeerick Apr 12, 2022 Maintainer

breadoven Apr 12, 2022 Author

pfeerick Apr 12, 2022 Maintainer

breadoven Apr 13, 2022 Author

pfeerick Apr 13, 2022 Maintainer

breadoven Apr 13, 2022 Author

pfeerick Apr 13, 2022 Maintainer

breadoven Apr 13, 2022 Author

pfeerick Apr 13, 2022 Maintainer

breadoven Apr 14, 2022 Author

pfeerick Apr 14, 2022 Maintainer

breadoven Apr 14, 2022 Author

pfeerick Apr 14, 2022 Maintainer

HThuren Sep 4, 2022

breadoven
Apr 10, 2022

Replies: 8 comments 6 replies

pfeerick
Apr 12, 2022
Maintainer

breadoven
Apr 12, 2022
Author

pfeerick Apr 12, 2022
Maintainer

breadoven
Apr 13, 2022
Author

pfeerick Apr 13, 2022
Maintainer

breadoven
Apr 13, 2022
Author

pfeerick Apr 13, 2022
Maintainer

breadoven
Apr 13, 2022
Author

pfeerick Apr 13, 2022
Maintainer

breadoven
Apr 14, 2022
Author

pfeerick Apr 14, 2022
Maintainer

breadoven
Apr 14, 2022
Author

pfeerick Apr 14, 2022
Maintainer

HThuren
Sep 4, 2022