Hello all
Am Montag, den 14.08.2017, 17:15 -0400 schrieb Tom Rini:
On Sat, Aug 12, 2017 at 11:03:46AM +0200, Max Krummenacher wrote:
If compiling for thumb the U-Boot 'go' command can not jump to the entry point, as the jump will be done in the assumption that the code jumped to is using the arm instruction set.
So add add a simple forwarder in arm instruction set which then jumps to the 'real' entry.
Signed-off-by: Max Krummenacher max.krummenacher@toradex.com
This looks like a special case of what we're doing in f99993c10882 and dc89c6fb778e and perhaps we need to move that kind of fixup around to somewhere else, as I assume you've found this problem on a custom application? Or are you utilizing hello_world in some test suites? Just curious, thanks!
I guess the difference to f99993c10882 and dc89c6fb778e is that one knows from armv7m that the CPU is thumb only while on an armv7a potentially both arm and thumb mode can be used.
Actually a customer asked how to run hello_world.bin, so I tested with our regular defconfig and the produced hello_world.bin.
I'm having 'CONFIG_SYS_THUMB_BUILD=y' in e.g. configs/colibri_imx6_nospl_defconfig thus all of the U-Boot code including hello_world.c is compiled for thumb.
If I boot that U-Boot, load hello_world.bin into RAM at CONFIG_STANDALONE_LOAD_ADDR and execute 'go CONFIG_STANDALONE_LOAD_ADDR' I get output from the go command and then the CPU resets.
Colibri iMX6 # tftp 0x12000000 hello_world.bin ... Colibri iMX6 # go 0x12000000 ## Starting application at 0x12000000 ...
With the patch I get the expected output.
But actually calling the 'go' command with bit 0 set works. So if the user knows that he is having a thumb binary that would fix the issue as well. With the current implementation the following works:
Colibri iMX6 # go 0x12000001 ## Starting application at 0x12000001 ... Example expects ABI version 9 Actual U-Boot ABI version 9 Hello World argc = 1 argv[0] = "0x12000001" argv[1] = "<NULL>" Hit any key to exit ...
Max