[U-Boot] ## Application terminated, rc = 0x1

[U-Boot] ## Application terminated, rc = 0x1

[ba_f]

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

[U-Boot] ## Application terminated, rc = 0x1

[Nable]

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?

[U-Boot] ## Application terminated, rc = 0x1

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I express preference for a chronological  sequence  of  events  which
precludes a violence.   - Terry Pratchett, _The Dark Side of the Sun_

[U-Boot] ## Application terminated, rc = 0x1

[ba_f]

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...

[U-Boot] ## Application terminated, rc = 0x1

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Mike's Law: For a lumber company employing two men and a cut-off saw,
the marginal product of labor for any number  of  additional  workers
equals  zero  until the acquisition of another cut-off saw. Let's not
even consider a chainsaw.
- Mike Dennison [You could always  schedule the saw, though - ed.]

[U-Boot] "go" does not work for uImage - was: ## Application terminated, rc = 0x1

[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

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Testing can show the presense of bugs, but not their absence.
                                                   -- Edsger Dijkstra

[U-Boot] U-Boot version issue

[ba_f]

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

[U-Boot] U-Boot version issue

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

> ## 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 at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

Regards,
Simon

[U-Boot] U-Boot version issue

[Michal Simek]

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


-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20151009/0785a0aa/attachment.sig>

[U-Boot] U-Boot version issue

[ba_f]

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