[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, 9 months ago by support.

Attachments:

You must be logged in to view attached files.

[support]

Unfortunately, it is hard to suggest anything specific based on the description you provided.
In order for us to provide any help with this, we need to be able to reproduce the problem on our side.
Please provide complete and detailed steps to reproduce the issue as described below:

1. The steps should begin with launching Visual Studio. They should include every step necessary to create the project from scratch and reproduce the issue.
2. Please make sure the steps do not involve any 3rd-party code as we will not be able to review it. If the problem only happens with a specific project, please make sure you can reproduce it on a clean project created from scratch.
3. The steps should include uncropped screenshots of all wizard pages, VisualGDB Project Properties pages and any other GUI involved in reproducing the problem. This is critical for us to be able to reproduce the problem on our side.

You can read more about the best way to report VisualGDB issues in our problem reporting guidelines, If you do not wish to document the repro steps and save the screenshots, please consider recording a screen video instead and sending us a link to it.

Please note that many VisualGDB issues are caused by selecting an incompatible combination of settings at some point. We are generally not able to review specific projects and find the specific settings that were set incorrectly. We recommend checking the projects into source control and keeping a track of all changed settings to avoid breaking the projects.

We would also kindly ask you to renew your support as it has expired a few months ago.

[support]

Hi,

There is no fully automatic way to move a subset of settings between projects, however VisualGDB stores its settings in straight-forward XML files (and ESP-IDF configuration is stored in sdkconfig files), so you could try making a basic automation tool that will move the settings you need between projects.

You can configure VisualGDB to invoke the custom tool as a custom shortcut (i.e. menu entry under the project context menu).

[support]

Hi,

VisualGDB does support grouping of source files by folders and it is enabled by default for many project types.

If it’s not working, please do provide the steps and screenshots we requested. We will not be able to help you unless you do so because we do not know what you are doing and why it is not working.

[support]

If you would like us to investigate the issue further, please provide the requested information. If you do not wish to provide it, we will not be able to allocate any additional resources to investigating this and will have the issue closed until anyone else confirms it and provides the repro steps.

[support]

There are no implicit requirements that would lead to this message. If you would like our help troubleshooting this, please do provide the requested information.

[support]

Unfortunately, it is hard to suggest anything specific based on the description you provided.
In order for us to provide any help with this, we need to be able to reproduce the problem on our side.
Please provide complete and detailed steps to reproduce the issue as described below:

1. The steps should begin with launching Visual Studio. They should include every step necessary to create the project from scratch and reproduce the issue.
2. Please make sure the steps do not involve any 3rd-party code as we will not be able to review it. If the problem only happens with a specific project, please make sure you can reproduce it on a clean project created from scratch.
3. The steps should include uncropped screenshots of all wizard pages, VisualGDB Project Properties pages and any other GUI involved in reproducing the problem. This is critical for us to be able to reproduce the problem on our side.

You can read more about the best way to report VisualGDB issues in our problem reporting guidelines, If you do not wish to document the repro steps and save the screenshots, please consider recording a screen video instead and sending us a link to it.

Please note that many VisualGDB issues are caused by selecting an incompatible combination of settings at some point. We are generally not able to review specific projects and find the specific settings that were set incorrectly. We recommend checking the projects into source control and keeping a track of all changed settings to avoid breaking the projects.

You can also try checking various diagnostic output from various parts of VisualGDB as described on this page. Although we won’t be able to review it for a specific project unless the we can reproduce the problem from scratch, checking it might provide some clues on what is causing the unexpected behavior.

[support]

Hi,

This would be fairly straight forward for the regular CMake projects, since CMake supports multiple applications/libraries in the same project out-of-the-box. However, the use of ESP-IDF makes things more complicated, since it implicitly expects a project to have one primary application referencing multiple components.

We would advise researching how ESP-IDF internally defines the bootloader targets, since the bootloader is essentially a separate mini-application built within the same project. You might be able to reuse some of that logic to build the application for the FACTORY partition. That said, it might require patching ESP-IDF or might rely on some APIs that will be changed in future versions. It is ultimately something to do at your own risk.

[support]

Hi,

Thanks for pointing this out. The Renesas devices are quite different from other device families supported by VisualGDB. They extensively rely on fairly complex code generation logic (that uses JavaScript in some cases). VisualGDB does not include a JavaScript engine and cannot replicate the original logic with 100% accuracy, however it still supports a reasonable subset of it that can still save time, while requiring occasional manual adjustments.

In this case, the incorrect syntax comes from the following line in the BSP.XML file:

<string>#define BSP_CFG_ROM_REG_BPS0 (~($$config.bsp.fsp.BPS.BPS0$$ 0U))</string>

You can work around it by patching the file as follows:

<string>#define BSP_CFG_ROM_REG_BPS0 (~($$config.bsp.fsp.BPS.BPS0$$))</string>

You can then set BPS0 to 0 via the project properties (or just hardcode 0 in the template instead of $$config.bsp.fsp.BPS.BPS0$$).

We have noted this in our roadmap for the Renesas BSP, and will look further into it when releasing the next BSP version.

[support]

Thanks for the detailed video. Indeed, the logic for automatically stripping the SSH port worked for the Linux projects, but not for the embedded projects (building the project locally while debugging it with a remote stub running on a target with a custom SSH port is an extremely rare scenario).

We have fixed it in the following build: VisualGDB-5.6.108.4714.msi

[support]

Thanks, we have reproduced the issue and fixed it in the following build: VisualGDB-5.6.108.4714.msi

[support]

Hi,

Just wanted to let you know that we have just released VisualKernel 4.0 Beta 2.

It includes the fix for the LinuxKernelDebugHelper build issue you mentioned, has numerous stability improvements and fixes the issue with the module list filter.

Regarding the extra component in the module path (C:\Users\<username>\source\repos\vmware-ubuntu-16.04\vmware-ubuntu-16.04\vmware-ubuntu-16.04\drivers\media\usb\dvb-usb), VisualKernel computes them using the following logic:

1. Locates the kernel release under your kernel release directory (configurable via Tools->VisualKernel->Manage Linux Kernel Symbols).
2. Loads the matching IndexedModules/InTreeKernelModule element in KernelRelease.xml and appends the PathRelativetoKernel value to the directory of the KernelRelease.xml file.

If you consistently get invalid paths, could you please recheck what module paths are stored in KernelRelease.xml? If they contain an extra component, please try patching the file manually, or just re-importing the kernel using the kernel symbol manager. This should get the correct paths stored, so VisualKernel will be able to load them automatically.

 

[support]

The original issue has been resolved a long time ago, so this is likely something different.

Generally, STM32CubeMX sometimes misses some sources or headers when generating project templates. Newer versions of STM32CubeMX often fix such issues, but sometimes introduce new cases.

The best idea to troubleshoot it is to specifically look for header files defining the missing symbols, and then trace it down:

1. Is the header file included via #include<>?
2. If yes, but the header file is not found, does the include search path contain the header file’s directory?
3. Are the definitions conditional to a #define that is not defined?

If you can narrow it down to a specific construct in the generated STM32CubeMX file that was not imported correctly, we should be able to fix the importing logic to handle it properly. If not, please consider editing the sources manually to include the necessary parts.

[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]

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.

[Author]

Posts