Targeting a new embedded Linux board?

[DonMilne]

Hi, I’ve actually made pretty good progress on my own, but I’d appreciate some guidance here.

I’ve been asked to do development for an embedded Linux device based on the NXP i.MX8M Plus. The actual dev board is made by a company called Variscite and is called the DART-MX8M-PLUS.

The board insists on running an embedded Linux. I’ve managed to create an sdcard image inside a Debian VM using Yocto and its Poky template Linux (I tried using WSL2 but couldn’t make it work). Note that it’s an ARM64 based Linux, and it boots just fine in the board.

I have working SSH and Samba.

I struggled for a while to configure a toolchain in VisualGDB, but I just tried using the Raspberry 64bit toolchain, and surprisingly it worked: my “Hello, World!” app runs just fine, and I can even run it inside the debugger (apparantly I somehow managed to include the GDB server in my Yocto script!).

Is there any guidance on how I can adapt this working setup to use the libs and header files from the Poky template? I reckon it can’t be far off, but I assume that I currently have a generic Linux and won’t have access to GPIOs, cameras, USB and other peripheral devices.

Please be warned that I know very little about Linux. Don’t assume that anything is obvious. Do I just copy /usr and /lib folders from the Poky image into the equivalent locations in the x\raspberry64 toolchain folders? Can you confirm the folders I should replace?

My preference would be to have local copies of libraries, i.e. not rely on a network connection for compilation.

I’m running VisualGDB 5.6R8 (Build 4702) in Visual Studio 2015.

[support]

Hi,

The embedded toolchains usually need to be individually built for each specific target. The exact steps vary from distribution to distribution, and often involve troubleshooting some unexpected weird issues, so there is no common guidance here. E.g. we recently updated our STM32MP1 toolchain and had to resolve compatibility issues between the yocto-specific gdb patches and the MinGW toolchain, and also encountered a bug that ware interfering with multi-threaded builds.

You can indeed try using a similar toolchain (e.g. Raspberry Pi), but it may trigger further weird issues when you try to use it for complex projects. It really depends on the differences between the platforms and there’s no fully automatic solution here.

We do offer a toolchain building service for custom targets, so if you start running into strange problems that take too much time to solve, feel free to contact our sales for a quote.

[DonMilne]

Hi, thanks for the reply.  I saw that you offered the toolchain building service, but ISTM that Variscite should be the ones paying for that service, it strikes me as inefficient for each small developer to duplicate that effort.  But perhaps you could tell me if that service is expensive?  I.e. is it pitched at small companies or at megacorps!

[support]

We do provide toolchains for the most common targets (Raspberry Pi, STM32MP1) free of charge.

If you believe that Variscite should be sponsoring a toolchain for their target, feel free to contact them and convince them to do so. We are fine either way, as long as someone agrees to cover the research, porting and testing costs.

[support]

Thank you for ordering the custom toolchain build from us. You can download the pre-built installer here. As discussed per email, we are publishing the steps we took to build the toolchain:

1. Go to the existing Yocto environment (configured by var-setup-release.sh) and run the following command: bitbake build-sysroots. It will copy all the files that need to be present in the target’s file system to var-fsl-yocto/build_xwayland/tmp/sysroots/imx8mp-var-dart.
2. Copy the sysroot built in the previous step to <sysgcc>\variscite\cortexa53-crypto-fslc-linux\sysroot.
3. Locate libc.so inside the sysroot directory. It will contain a linker script fragment referencing a library. Update that paths there to use the sysroot-relative form:

   GROUP ( =/lib/libc.so.6 /usr/lib/libc_nonshared.a  AS_NEEDED ( =/lib/ld-linux-aarch64.so.1 ) )

4. Checkout git://git.yoctoproject.org/meta-mingw into var-fsl-yocto/sources/meta-openembedded/meta-mingw and register it in var-fsl-yocto/sources/base/conf/bblayers.conf. Make sure you are using the correct branch. Also create the var-fsl-yocto/sources/poky/meta/conf/machine-sdk/i686-mingw32.conf file with the following contents:

   require conf/machine-sdk/include/mingw32-common.inc

5. Create a separate Yocto environment and run the following commands there (the double assignment SDKMACHINE is required to work around a bug in the scripts):

   SDKMACHINE=i686-mingw32 MACHINE=imx8mp-var-dart DISTRO=fslc-xwayland . var-setup-release.sh build_xwayland
   export SDKMACHINE=i686-mingw32
   bitbake binutils-cross-canadian-aarch64 gcc-cross-canadian-aarch64 binutils-cross-canadian-aarch64 gdb-cross-canadian-aarch64

   Note that unlike STM32MP1, this won’t produce usable MinGW binaries, but it will be a good starting point.

6. Locate the binutils configuration log (build_xwayland/tmp/work/i686-nativesdk-mingw32-w64-mingw32/binutils-cross-canadian-aarch64/2.36.1-r0/git/build.i686-w64-mingw32.aarch64-fslc-linux/config.log) and create another build directory on the same level.
7. Patch the configuration command line so that the sysroot is located in <prefix>/cortexa53-crypto-fslc-linux/sysroot, e.g.:

   --prefix=/usr/local/oe-sdk-hardcoded-buildpath/sysroots/i686-w64-mingw32/usr \
   --with-sysroot=/usr/local/oe-sdk-hardcoded-buildpath/sysroots/i686-w64-mingw32/usr/cortexa53-crypto-fslc-linux/sysroot \

   Then configure/build/install binutils (they will get installed to /usr/local/oe-sdk-hardcoded-buildpath)

8. Locate the config.log for gcc (e.g. build_xwayland/tmp/work/i686-nativesdk-mingw32-w64-mingw32/gcc-cross-canadian-aarch64/10.3.0-r0/gcc-10.3.0/build.i686-w64-mingw32.aarch64-fslc-linux/config.log). Patch the config command line as shown below:
   1. replace /not/exist with /usr/local/oe-sdk-hardcoded-buildpath/sysroots/i686-w64-mingw32/usr/cortexa53-crypto-fslc-linux/sysroot
   2. Remove –with-system-zlib
9. Manually copy gmp/mpfr/mpc into the gcc source directory. Try configuring/building gcc.
10. When the build fails, apply the attached patch to the generated Makefile. Build it again. After it fails to run the cross-gcc, try installing it (“sudo make install”).
11. When it fails with a missing lto-dump.exe, built it manually (cd gcc && make lto-dump.exe). Re-run the install command.
12. Locate the gdb config log (e.g. build_xwayland/tmp/work/i686-nativesdk-mingw32-w64-mingw32/gdb-cross-canadian-aarch64/10.1-r0/build-aarch64-fslc-linux/config.log).
13. Patch the command line as shown below:

    --build=x86_64-linux \
    --host=i686-w64-mingw32 \
    --target=aarch64-fslc-linux \
    --prefix=/usr/local/oe-sdk-hardcoded-buildpath/sysroots/i686-w64-mingw32/usr \
    --with-sysroot=/usr/local/oe-sdk-hardcoded-buildpath/sysroots/i686-w64-mingw32/usr/cortexa53-crypto-fslc-linux/sysroot

14. Configure/build/install gdb.
15. Copy the files to the toolchain directory (see our pre-built toolchain for a sample structure). Double-check that all tools can locate sysroot:

    aarch64-fslc-linux-g++.exe --print-sysroot
    aarch64-fslc-linux-ld.exe --print-sysroot
    aarch64-fslc-linux-gdb.exe
    show sysroot

16. Copy var-fsl-yocto/build_xwayland/tmp/work/cortexa53-crypto-fslc-linux/libgcc-initial/10.3.0-r0/recipe-sysroot-native/usr/lib/aarch64-fslc-linux/gcc/aarch64-fslc-linux/10.3.0 to <sysgcc>\variscite\lib\aarch64-fslc-linux\gcc\aarch64-fslc-linux\10.3.0.

Note that these steps work for the hardknott branch and will likely not work for others (e.g. the Makefile patch works around a bug that is not present in the previous GCC version).

• This reply was modified 2 years, 1 month ago by support.

Attachments:

You must be logged in to view attached files.

[DonMilne]

Hi, thanks for providing the customized toolchain, which I have confirmed works – at least to the extent of building an running a “Hello, World!” app from Visual Studio. I will be experimenting more over the coming days.

To clarify for future readers, you follow the Variscite instructions to create a Yocto build environment inside a Linux VM (they recommend Ubuntu, I used Debian because I prefer it, and it worked fine). You can then follow the instructions of Sysprogs “support” member above to create the toolchain.

[DonMilne]

And I can now confirm that the toolchain works for blinking an LED too, my usual next step after “Hello, World!”.  FYI: note that the dev board mentioned above doesn’t seem to have a user programmable LED so I had to add one to a pin on connector J14. The Yocto build will determine which GPIOs are available at user level.

[support]

Thanks for confirming this and good to know it works. BTW, if you change your build environment in a minor way (e.g. add new libraries to the setup), you don’t need to rebuild the entire toolchain, as long as the gcc version and ABI (e.g. floating point mode) stays the same. Running a “bitbake build-sysroots” and replacing the sysroot directory in the current toolchain should do the trick.

[Author]

Posts