Forum Replies Created
-
AuthorPosts
-
December 13, 2015 at 23:16 in reply to: Cross-compiling Qt Embedded 5.5 for Raspberry Pi 2 – libicui18n.so.48 not found #7346
support
KeymasterHi,
It looks like you compiled your program against libicu18n version 48 and then updated your Raspberry PI image to libicu18n version 52.
Please delete the cross-compiled Qt, resynchronize the sysroot and build it again so that it is linked against version 52, not version 48.
support
KeymasterHi,
Strange. The boot mode should be “1,7” for the bootloader. Can you put breakpoints on the Sleep() calls after _Port.EscapeFunction() calls in the bootloader test program and check the state of GPIO0, GPIO2, GPIO15 and RESET at each sleep() call? Does it perform a device reset and does it hold the “UART Download Mode” (0/1/0) once reset is released?
support
KeymasterHi,
We don’t support it directly. However you can import a Ninja Build project to VisualGDB by selecting “Import a project built with other tools” in the wizard and specifying the build command line and the path to the built executable. VisualGDB will then invoke the command line you specified to build your project.
support
KeymasterOK, no problem. Let us know if you encounter problems with the arm-eabi toolchain.
support
KeymasterNo problem. Enjoy VisualGDB!
support
KeymasterHi,
The Qt framework has a bad habit of hardcoding various paths in the executables like qmake.exe, hence moving the toolchain to a different location would break everything.
The easiest workaround would be to make a symlink from c:\SysGCC to d:\SysGCC:
mklink /d c:\SysGCC d:\SysGCC
This way your files will be physically located in d:\, but you can still use the c:\SysGCC path to access them.
support
KeymasterHi,
Based on the log you provided it looks like the linker eliminates all code and data from the output image as it assumes it is all unused.
You can resolve this by adding a KEEP statement to the declaration of the interrupt vector table in your linker script. This will mark the vector table as used and will in turn bring in the reset handler, main(), and the functions called by it. You will also need to explicitly specify the entry point in your linker script so that gdb can jump to it automatically after programming your FLASH.
Please refer to our STM32 linker scripts for examples on the KEEP() statement and the entry point definition.
support
KeymasterHi,
Sorry to hear that. Building the kernel can be indeed tricky, but we tried to cover all the complexities in our kernel building tutorial. Did you encounter problems not mentioned there?
support
KeymasterYou should be able to do that, however if the Edison SDK from Intel does not include boost, you will need to cross-compile it.
You can either follow the Boost cross-compilation guide or contact our sales for a quote if you want us to cross-compile it for you.
support
KeymasterHi,
We simply connected Beaglebone to our internal network with a DHCP server via an Ethernet cable. Then we used the stock firmware listed here and were able to create new projects. If this does not work for you, please let us know which problems you are encountering so that we could help you resolve them.
support
KeymasterHi,
We do mention supported kernel versions on the kgdboe page.
We are not planning to support older kernels as their popularity is declining over time as people are switching to newer ones.
COM port-based debugging should work. Let us know if you encounter any problems with it.
December 10, 2015 at 20:39 in reply to: Two Problems: 1) LinuxKernelDebugHelper seg fault AND 2) KGDBoE build fails #7324support
KeymasterHi,
KGDBoE usually does not work on ARM devices because their network drivers do not implement all the necessary interfaces.
If you want to try it nonetheless, you can simply comment out the code calling the cpu_down() function, as it should be irrelevant on a single-core device. Otherwise, we generally advise using JTAG to debug kernel on embedded ARM boards.
It is hard to say what causes the KernelDebugHelper to crash from your log, most likely some kernel modifications break some assumptions. Please try disabling the “build/install a custom kernel module for collecting module information faster” checkbox. This should eliminate the need to build KernelDebugHelper and use an alternative slower mechanism instead.
support
KeymasterIt looks like the configuration file is missing. Normally it should be created when you build the kernel as described in this tutorial. Have you managed to build the kernel successfully?
support
KeymasterHi,
Wow, thanks a lot for trying this out. This is definitely not something we could have figured out without the hardware. We can certainly add an option to configure the delay in the debugging plugin.
Just to double-check: did you manage to get the bootloader test tool to repoer a successful sync? The output you shared still says “timeout reading reply”. Does it get even more reliable if you increase the delay to 100 ms?
support
KeymasterNormally the ‘None’ item type is used to add Makefile and the .mak files to your project. “None” indicates that the file does not participate in the build. If your VS does not recognize it, most likely your installation is corrupt. Please try repairing it via Add/Remove programs.
-
AuthorPosts