[U-Boot] ## Application terminated, rc = 0x1
Hello U-Boot Crew,
i want to boot a little kernel on ARM Cortex a9.
But the kernel crushes pretty early with the following u-boot output:
## Starting application at 0x01000000 ... ## Application terminated, rc = 0x1
Since i have no clue where (and how) to start debugging, my first question is:
What may cause "Application terminated, rc = 0x1"?
I don't think it is a regular code exit, like main(){ return 1; }.
There must be any other issue. But how to find out what's wrong?
Please, any advice for debugging, or any hint about what may cause rc=0x1 is welcome.
Thanks
Hi,
i want to boot a little kernel on ARM Cortex a9. But the kernel crushes pretty early with the following u-boot output:
## Starting application at 0x01000000 ... ## Application terminated, rc = 0x1
What board do you use? This address may be used by something different than application code.
Since i have no clue where (and how) to start debugging, my first question is:
What may cause "Application terminated, rc = 0x1"?
This message is located in two places: common/cmd_boot.c -> do_go() common/cmd_elf.c -> do_bootelf()
In both places it prints return value of your application (value of R0 after control is passed back to u-boot). What command do you use to start application? First option (cmd_boot -> do_go -> do_go_exec) may use do_go_exec() implementation from arch/arm/lib/cmd_boot.c that forces Thumb mode and I'm not sure whether it's OK for your application.
There must be any other issue. But how to find out what's wrong?
Please, any advice for debugging, or any hint about what may cause rc=0x1 is welcome.
arm-none-eabi-gdb + OpenOCD + JTAG dongles is a nice setup for debugging. If you have JTAG dongle, you can build U-Boot with debug information, set temporary breakpoint on do_go and do_bootelf functions, let the CPU run till one of these points and then single-step to the entry point of your application and further.
Debugging without JTAG is possible but it's a hard way. As a first attempt you can start with verifying that "int main(){ return 2; }" shows "Application terminated, rc = 0x2" and if it doesn't happen, you should look at the disassembly of your application. Btw, did you try applications from examples?
Dear ba_f,
In message 5c515fb3b2f956768d10d2e2c2e9402e@rbg.informatik.tu-darmstadt.de you wrote:
But the kernel crushes pretty early with the following u-boot output:
## Starting application at 0x01000000 ... ## Application terminated, rc = 0x1
This is NOT a crash. The program terminates normally with a return code of 1.
What may cause "Application terminated, rc = 0x1"?
Something that takes the same effect as "return(1)" from your main() function, resp. an "exit(1)" from other parts of the code.
I don't think it is a regular code exit, like main(){ return 1; }.
But yes, it is. From the line
## Application terminated, rc = 0x1
you can see that the program returned normally to U-Boot, and U-Boot continues running (unless your code destroyed any of the U-Boot execution environment).
Best regards,
Wolfgang Denk
Thank you two, this was the hint i needed.
The Load-Address was wrong.
Anyway, i still don't know how to determine the Load- & Entry-Address, and i would be thankful if you could clear some things up for me.
I always work on ARM Cortex A9 processors. The first time i came in touch with U-Boot i booted a Uimage kernel, and i had to do it the following way: (Please, notice the offset between Load- & Entry-Address)
uboot> fatload mmc 0 0x00ffffc0 bootstrap.uimage uboot> go 0x01000000
But, while both kernels (the Uimage and the current mini kernel) are linked for start address 0x01000000, i cannot use the same load address on the mini-Kernel. Now, i have to load and jump to the same address to make it work. Like this:
uboot> fatload mmc 0 0x01000000 miniKernel.bin uboot> go 0x01000000
Why this? How comes the offset with the Uimage?
Another issue:
I tried to execute the same Uimage on another platform. The platform has the same processor but another U-Boot. On this platform i fail to execute with my common way:
uboot> fatload mmc 0 0x00ffffc0 bootstrap.uimage uboot> go 0x01000000 ## Starting application at 0x01000000 ... undefined instruction pc : [<010000f4>] lr : [<3ff74bc0>]
This looks to me like a wrong Load- or Entry-Address. But again, it is the same Uimage with start address 0x01000000.
What's wrong here? I'm confused...
Dear ba_f,
In message 2e2178cf246f80c4f9098dce357e5528@rbg.informatik.tu-darmstadt.de you wrote:
Anyway, i still don't know how to determine the Load- & Entry-Address, and i would be thankful if you could clear some things up for me.
Did you read the FAQ? See es[ecially [1]
[1] http://www.denx.de/wiki/view/DULG/MyStandaloneProgramDoesNotWork
The first time i came in touch with U-Boot i booted a Uimage kernel, and i had to do it the following way: (Please, notice the offset between Load- & Entry-Address)
uboot> fatload mmc 0 0x00ffffc0 bootstrap.uimage uboot> go 0x01000000
Any uImage should be booted using the "bootm" command, not "go".
But, while both kernels (the Uimage and the current mini kernel) are linked for start address 0x01000000, i cannot use the same load address on the mini-Kernel. Now, i have to load and jump to the same address to make it work. Like this:
uboot> fatload mmc 0 0x01000000 miniKernel.bin uboot> go 0x01000000
Why this? How comes the offset with the Uimage?
The uImage file contains a 64 byte header which is interpreted by commands like "iminfo" or "bootm".
Another issue:
Plese do NOT do that. Do not mix topics in a single posting. Please open a new thread instead.
Best regards,
Wolfgang Denk
Dear ba_f,
In message 2e2178cf246f80c4f9098dce357e5528@rbg.informatik.tu-darmstadt.de you wrote:
Another issue:
So, here we go in a new thread.
I tried to execute the same Uimage on another platform. The platform has the same processor but another U-Boot. On this platform i fail to execute with my common way:
uboot> fatload mmc 0 0x00ffffc0 bootstrap.uimage uboot> go 0x01000000 ## Starting application at 0x01000000 ... undefined instruction pc : [<010000f4>] lr : [<3ff74bc0>]
Your other platform might use a different memory map...
After running the "fatload" as above, type
iminfo ffffc0
and it will show you which load and entry point addresses shuld be used.
Best regards,
Wolfgang Denk
Hello,
i have an issue with different U-Boot versions, and i have no clue what's the problem. Maybe someone's got an idea?
Working on Xilinx' ARM Platform i use U-Boot version u-boot-xlnx-xilinx-v14.6.01, and it's all good with that one and even lower versions. But, using u-boot-xlnx-xilinx-v14.7 or higher results in serious CPU errors:
uboot> fatload mmc 0 0x00ffffc0 bootstrap.uimage reading bootstrap.uimage 6139968 bytes read in 528 ms (11.1 MiB/s) uboot> go 0x01000000 ## Starting application at 0x01000000 ... undefined instruction pc : [<01000004>] lr : [<3ff74bc0>] sp : 3fb51e08 ip : 00002802 fp : 00000000 r10: 3fb572d8 r9 : 00000002 r8 : 3fb51f40 r7 : 3ffaff50 r6 : 01000000 r5 : 3fb572dc r4 : 00000002 r3 : 01000000 r2 : 3fb572dc r1 : 3fb572dc r0 : 00000001 Flags: nZCv IRQs off FIQs off Mode SVC_32 Resetting CPU ...
I checked autoconf.mk of both version, but none uses Thumb mode.
I already posted this in a similar context. In that thread i thought the different platform was the reason for failure. But now i'm convinced it is the U-Boot version making trouble. The platform in the other thread uses a new xilinx U-boot. http://lists.denx.de/pipermail/u-boot/2015-September/228940.html
Now i use the same platform and the same uimage but another U-Boot.
Unfortunately, the DIFF between u-boot-xlnx-xilinx-v14.6 and u-boot-xlnx-xilinx-v14.7 is 60'000 lines...
Thank u & have nice day,
ba_f
+Marcel who is the maintainer
Hi,
On 8 October 2015 at 14:56, ba_f ba_f@rbg.informatik.tu-darmstadt.de wrote:
Hello,
i have an issue with different U-Boot versions, and i have no clue what's the problem. Maybe someone's got an idea?
Working on Xilinx' ARM Platform i use U-Boot version u-boot-xlnx-xilinx-v14.6.01, and it's all good with that one and even lower versions. But, using u-boot-xlnx-xilinx-v14.7 or higher results in serious CPU errors:
uboot> fatload mmc 0 0x00ffffc0 bootstrap.uimage reading bootstrap.uimage 6139968 bytes read in 528 ms (11.1 MiB/s) uboot> go 0x01000000
What is that bootstrap program? Maybe you need to turn off the cache before starting it with the 'dcache off' command?
## Starting application at 0x01000000 ... undefined instruction pc : [<01000004>] lr : [<3ff74bc0>] sp : 3fb51e08 ip : 00002802 fp : 00000000 r10: 3fb572d8 r9 : 00000002 r8 : 3fb51f40 r7 : 3ffaff50 r6 : 01000000 r5 : 3fb572dc r4 : 00000002 r3 : 01000000 r2 : 3fb572dc r1 : 3fb572dc r0 : 00000001 Flags: nZCv IRQs off FIQs off Mode SVC_32 Resetting CPU ...
I checked autoconf.mk of both version, but none uses Thumb mode.
I already posted this in a similar context. In that thread i thought the different platform was the reason for failure. But now i'm convinced it is the U-Boot version making trouble. The platform in the other thread uses a new xilinx U-boot. http://lists.denx.de/pipermail/u-boot/2015-September/228940.html
Now i use the same platform and the same uimage but another U-Boot.
Unfortunately, the DIFF between u-boot-xlnx-xilinx-v14.6 and u-boot-xlnx-xilinx-v14.7 is 60'000 lines...
Why is there a special Xilinx U-Boot? Can this not be removed in favour of upstream?
Thank u & have nice day,
ba_f
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Regards, Simon
Hi,
On 10/09/2015 03:02 PM, Simon Glass wrote:
+Marcel who is the maintainer
Marcel? :-)
Hi,
On 8 October 2015 at 14:56, ba_f ba_f@rbg.informatik.tu-darmstadt.de wrote:
Hello,
i have an issue with different U-Boot versions, and i have no clue what's the problem. Maybe someone's got an idea?
Working on Xilinx' ARM Platform i use U-Boot version u-boot-xlnx-xilinx-v14.6.01, and it's all good with that one and even lower versions. But, using u-boot-xlnx-xilinx-v14.7 or higher results in serious CPU errors:
This issue shouldn't be discussed in this mailing list as Simon pointed out. It is related to Xilinx and pretty ancient version.
uboot> fatload mmc 0 0x00ffffc0 bootstrap.uimage reading bootstrap.uimage 6139968 bytes read in 528 ms (11.1 MiB/s) uboot> go 0x01000000
What is that bootstrap program? Maybe you need to turn off the cache before starting it with the 'dcache off' command?
yes, likely this is a problem. There is one related problem to this which is also in mainline u-boot. When you load stuff from non volatile memories sometimes u-boot does cache flush and sometimes not. I am not sure if all RAW accesses (e.g. MMC, Sata) have cache flush but reading from FS doesn't have it.
I would try what Simon suggested which is disable dcache and also load image via tftp for example.
Thanks, Michal
Am 2015-10-09 15:02, schrieb Simon Glass:
+Marcel who is the maintainer
Hi,
On 8 October 2015 at 14:56, ba_f ba_f@rbg.informatik.tu-darmstadt.de wrote:
Hello,
i have an issue with different U-Boot versions, and i have no clue what's the problem. Maybe someone's got an idea?
Working on Xilinx' ARM Platform i use U-Boot version u-boot-xlnx-xilinx-v14.6.01, and it's all good with that one and even lower versions. But, using u-boot-xlnx-xilinx-v14.7 or higher results in serious CPU errors:
uboot> fatload mmc 0 0x00ffffc0 bootstrap.uimage reading bootstrap.uimage 6139968 bytes read in 528 ms (11.1 MiB/s) uboot> go 0x01000000
What is that bootstrap program? Maybe you need to turn off the cache before starting it with the 'dcache off' command?
Indeed DCache is the problem.
The old u-boot had CONFIG_SYS_DCACHE_OFF=y.
Thanks, ba_f
participants (5)
-
ba_f -
Michal Simek -
Nable -
Simon Glass -
Wolfgang Denk