A am currently attempting to load an MQX application using a third-party boot-loader (U-Boot). U-Boot itself has been configured to work with my board (a custom Vybrid vf610-based board), and confirmed to function properly.
The MQX application is loaded into U-Boot using CKermit and the "loadb"-command. Before loading, elf-image is converted into a binary using the fromelf-utility, and then packed using the U-Boot "mkimage"-utility, which has been adapted to support booting for MQX (if interested in how I did this, let me know) using the following command:
$ fromelf --bin --output=mqxapp.bin mqxapp.axf && ${UBOOT_ROOT}/tools/mkimage -A arm -O mqx -T standalone -C none -a 0x80000000 -d mqxapp.bin mqxapp.img
The load addresses has been cross-checked with mapfile.txt and correspond with the indicated entry-point.
The image header of the image is correctly read by U-Boot and the CRC verified:
## Checking Image at 81000000 ...
Legacy image found
Image Name:
Image Type: ARM MQX Standalone Program (uncompressed)
Data Size: 283956 Bytes = 277.3 KiB
Load Address: 80000000
Entry Point: 80000000
Verifying Checksum ... OK
I am currently working on a Linux host-system (Ubuntu 14.04) using "ARM DS-5" and "ULINKpro D" debugger.
The issue I am experiencing is that MQX does not actually load unless a debugging session is running. In order to launch a debugging session when loading from U-Boot, I first load MQX into DDR using CKermit before start the debugger using the "Connect Only"-option in the configuration. I then halt the target and load the elf-file mqxapp.axf. Upon doing this, I get the following message in the Debug-view:
Semihosting server socket created at port 8000
Semihosting enabled automatically due to semihosting symbol detected in image 'mqxapp.axf'
set debug-from main
When I continue execution, I am still in U-Boot and able to load boot the image using the "bootm"-command. U-Boot then behaves as expected and loads MQX. From there MQX runs as expected.
However, when not starting the debugger, MQX does not run, executing flow ends up in one of the fault-traps in U-Boot.
From what I can see, the issue may be related to semihosting. I am using MQX's built-in printf, which seems to using semihosting in some way.
Thus, is there a way of disabling semihosting in MQX? A simple release-build does not seem to work.
已解决! 转到解答。
Thanks to Nicolas I was able to solve the issue. The solution consisted of adding a file "retarget.c" containing the following two functions:
void _sys_exit(int return_code);
void _ttywrch(int ch);
"retarget.c" also contained to followin #pragma:
#pragma import(__use_no_semihosting_swi)
Hey Thomas,
I had an issue with semihosting recently and put in a support ticket with ARM for their DS-5 development suite. They supplied me with this page showing how to disable semi-hosting.
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0475k/chr1358938917495.html.
All the best,
Nick
Thank you Nicholas, this is very helpful.
After some reading, I find that ARM have introduced a concept of "retargeting" some IO-functions (typically STDIO-related).
I have found several resources on how to achieve this on other platforms:
Sticky Bits » Blog Archive » Rehosting ARMCC for the mbed with CMSIS-DAP
http://fossies.org/linux/wolfssl/IDE/MDK-ARM/MDK-ARM/wolfSSL/Retarget.c
http://infocenter.arm.com/help/topic/com.arm.doc.faqs/attached/3844/retarget.c
Is there a way of seamlessly achieving this with MQX on Vybrid?
Cheers.
Thanks to Nicolas I was able to solve the issue. The solution consisted of adding a file "retarget.c" containing the following two functions:
void _sys_exit(int return_code);
void _ttywrch(int ch);
"retarget.c" also contained to followin #pragma:
#pragma import(__use_no_semihosting_swi)