u-Boot and standalone applications

[ericfornstedt]

Hi,

We are using a P1020RDP-PD board for a development project, and there are some things about u-Boot and standalone  
applications which we don't quite understand.

Together with u-Boot, an example "Hello World"-application is build as a binary. We can put that binary into an  image file with mkimage, download it through ymodem and boot it with bootm. This part works fine.

But, if we try the same with the binary from CodeWarrior Bare-board sample project, there application crashes at the  
printf-statement. That is, if we put the binary into an image and let u-Boot boot it. If we download it with CodeWarrior, and thereby bypass u-Boot, it works fine.

So we have two scenarios:

• Download binary to RAM through CodeWarrior and execute -> Works fine.
• Download same binary (in image file) to RAM through u-Boot and boot with bootm command -> Crash.

We have verified that the binary is put at the same address in both cases and the entry point is also the same.

If the printf-statement is stripped out from the application, so that basically only the while(1) remains, the application "works" and do not crash. It seems the printf-statement included in the binary does not work very well together with u-Boot, which might be by design.

This leads us to two question about this.

1. Can we use u-Boot o boot an application that execute in a "clean" environment, similar to what it executes in when downloaded with CodeWarrior? With no interference of u-Boot, just as a bare-board application.
2. If that is not the way forward, what is required from our application to make it run properly from u-Boot?

Any thoughts or ideas are appreciated!

BR
/ Eric

[brett_p_stahlma]

Eric,

Here's a snippet from a ticket I submitted to NXP a while back, which could be relevant. I wanted to invite you to be an observer on the thread, but networking issues have thus far prevented it...

Thanks,

Brett S.

Hmm... There appears to be an alignment issue: Inspecting the rodata for the string constants in my printf() calls showed that the problem occurred only for a string that was not a multiple of 4 bytes (including the trailing NUL). For example, if printf("foobar\n") worked, then printf("fooba\n") would cause the program to hang.

Using the idea here...

https://gcc.gnu.org/ml/gcc-help/2011-10/msg00068.html

...I created the following macro:

#define ASTR(s) ({ static char foo[] __attribute__((aligned(4))) = s; foo; })

When I wrapped the problematic string literals in ASTR(...), the problem went away.

I suspect that the GNU C library print routines are doing some sort of misaligned accesses when the string constants are not 4 byte aligned. If so, then I'm thinking there's a problem with the way the library is built for the ROM target. This was a really frustrating issue to root cause, and I'm still not sure I've found the optimal solution.

Please advise...

Thanks,

Brett S.

[brettstahlman]

Together with u-Boot, an example "Hello World"-application is build as a binary.

Eric,

How did you build the binary that was fed through mkimage and successfully loaded with bootm? Using one of the project templates in CodeWarrior?

Thanks,

Brett S.

[ericfornstedt]

Hi,

Yes, it was a bareboard example project in CodeWarrior if I remember correct. To make it work togeather with u-boot we had to rebuild the serial library with a CCSRBAR location matching u-boot. Just as Alexander suggested above.

BR

/ Eric

[brett_p_stahlma]

Thanks Eric. I actually ended up basing my app on u-boot's standalone Hello World template and adding commands to the "preboot" environment var to have it loaded automatically on boot.

[ericfornstedt]

Hi,

Thank you both, I think these answers explains why the setup we tried does not work. We will keep this in mind when continuing our project.

BR

/ Eric

[alexander_yakov · Accepted solution]

Our support for u-boot is typically limited to what is provided in our Linux BSP (SDK), and we typically support U-boot questions regarding how to use U-boot to run Linux kernel. We have no experience running custom applications from U-boot.

But, based on my understanding on how U-boot works - I do not think U-boot somehow restricts your custom application from working, I think the application crashes not because of U-boot limitations. Typical reason for application crash is an access to some memory address, not assigned to any memory controller. In this case machine check or checkstop error happens.

In your case you said this happens when you use printf(), I guess this printf accesses some hardware registers to output something to serial port. These hardware registers are relocatable. When you run your code from CodeWarrior, they are located as configured in CodeWarrior target initialization file. When you run the same code from U-boot, these registers may be located at another offset. The suggestion here is to create another CodeWarrior target initialization file, which does exactly the same configuration as U-boot does, and than create a code which will work with this new target configuration file, and than check this new code under U-boot.

Have a great day,
Alexander

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[sinanakman]

Hi Eric

You don't mention the u-boot version you are trying this with but normally

you can not have u-boot to boot another u-boot (in this case a standalone application as

you call it). The reason for this is that u-boot expects an uninitialized system but your

initial u-boot already does the initialization. With loading and running via

JTAG works probably because your JTAG init scrip does not do any of

the initialization and leaves it to the standalone application.

There is a some more explanation on this here :

CanUBootBeConfiguredSuchThatItCanBeStartedInRAM < DULG < DENX 

Some vendors provided a "ram" version of u-boot which strips off the 

initialization part but this isn't really a  recommended way. For ARM architectures

there is also SPL u-boot which separates the images in a similar way but

this doesn't apply to your e500 architecture in question.

Hope this helps. Please let me know if you have any other questions.

I also suggest that you use the latest stock u-boot version so then you can also

seek help in u-boot mailing list.

Regards

Sinan Akman