[P1013] Boot a Codewarrior Bareboard ELF file from RAM

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

[P1013] Boot a Codewarrior Bareboard ELF file from RAM

1,669 Views
jasonfohr
Contributor I

I have u-boot running on a custom P1013 board. I also have a bareboard CodeWarrior project that I have created using the template. It should print "Welcome to codewarrior" and then loop forever. I am able to tftp the ELF image into RAM and boot into the image, but I'm not getting any text. I have updated the serial project to point to the u-boot registers, but I still see nothing. The code successfully runs so it is not crashing,  but something must be configured configured wrong.

I would prefer to have the ELF image reload all of the settings and not rely on U-boot for pre-initalization, but it seems like the default build configurations don't support that. I either build the RAM image, which is relying on the POD to run the target init script. Or, I build the ROM image, which is assuming the image is booting from ROM.

What is the best way to handle this issue?

Tags (1)
0 Kudos
15 Replies

1,297 Views
addiyi
NXP Employee
NXP Employee

Please take a look on Debugging ARMv7 Applications running in an Environment initialized by U-Boot / ROM target debug. It is not for power architectures, but the steps are similar.

Adrian

0 Kudos

1,297 Views
jasonfohr
Contributor I

I am past the stage where I can use bootelf to boot the application and I can also debug the application. Currently the UART is not functioning correctly, I see no text being printed to the console. But when I download the code normally using the POD, triggering the P1013CC_init_core.tcl script, everything works. I'm wondering if there is a way I can incorporate the init script into the RAM build directly. Therefore, it will function more like Linux, where it re-initializes everything and then I don't have to sit and make sure my u-boot environment and the CodeWarrior environment play nice with each other. Are there any examples for modifying the loader scripts and initialization files in order to achieve this?

0 Kudos

1,297 Views
addiyi
NXP Employee
NXP Employee

The tcl script are use for target initialization, In your case the target initialization is done by uboot. If you want to run your app from uboot, you have to build your app for RAM  and use the bootelf command to load it. For debugging you can set a breakpoint to application entry point and start app using bootelf. The steps are describes in document above (ignore the fact that is used for ARM).

Adrian

0 Kudos

1,297 Views
jasonfohr
Contributor I

I did this but I cannot get the printf functions to actually produce output. The code runs fine, but produces no output. This makes me think your Serial UART libraries are dependent on initializations, which are done differently in the .tcl script versus what u-boot does. Therefore, I would rather have the Codewarrior application re-initialize everything so I don't have to worry about making u-boot and the Codewarrior files compatible.

0 Kudos

1,297 Views
addiyi
NXP Employee
NXP Employee

Does your application produce output when you start it using CW? The serial UART library is not depending on initialization file.

Adrian

0 Kudos

1,297 Views
jasonfohr
Contributor I

Only when I load it using the Codewarrior POD, using download session and the P1013DS_init_core.tcl initialization script. When I load it from u-boot I see nothing.

0 Kudos

1,297 Views
addiyi
NXP Employee
NXP Employee

I think you have to rebuild the uart library, since the default one used in CW will use the CCSRBAR set by initialization file (0xE0000000 in CW versus 0xff700000 in Uboot). Import P1012_serial project (it is available in \PA\PA_Support\Serial\) into CW and change the base addresses in duart_config.h. 

Adrian

0 Kudos

1,297 Views
jasonfohr
Contributor I

I did that, but still did not see any output.

0 Kudos

1,297 Views
addiyi
NXP Employee
NXP Employee

Changing the CCRBAR is the only thing initialization file is doing additional to uboot. So, using correct settings in Serial project (correct registers addresses, reading from fpga) should solve your problem.

Adrian

0 Kudos

1,297 Views
jasonfohr
Contributor I

And if I didn't want to deal with figuring out the differences between my u-boot project and the Codewarrior settings, is there a way I can insert the initialization code from the script somewhere such that it will re-initialize the environment separate from u-boot? Like add some function call in __ppc_eabi_init.c iniside the __init_hardware() function call? I would rather not have to make sure the Codewarrior projects align nicely with u-boot. It makes more sense to me to have the Codewarrior applications re-initialize the environment similar to how Linux does it. This way they can be treated separately. The person developing the Codewarrior application has to know nothing about what u-boot is doing other than the address where it can safely run code from without overriding u-boot.

0 Kudos

1,297 Views
addiyi
NXP Employee
NXP Employee

You can try that, but make sure all the initialization are done before calling the uart functions.

Adrian

0 Kudos

1,297 Views
Pavel
NXP Employee
NXP Employee

CodeWarrior uses .tcl script for the P1013 configuring. This script is used for clock configuring, memory configuring and MMU configuring and so on.

Your software can change configuration after loading.

If your software is used under u-boot, u-boot provides configuration of the P1013 clock, memory and MMU.

If your software is standalone, a debug TAP (CodeWarrior TAP or USB TAP) is needed for configuring of the P1013 clock, memory and MMU and code loading.

 

Do you use your software as standalone software?


Have a great day,
Pavel Chubakov

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

0 Kudos

1,297 Views
jasonfohr
Contributor I

We have multiple applications, some of them are used purely for diagnostic purposes. These are built using the codewarrior IDE, including support for the I/O, which links in a Serial UART library. U-boot was programmed as the initial bootloader in order to be able to boot between these various applications. As these applications are compiled with the codewarrior libraries, they are intended to be standalone applications. The only difference is I am loading them from u-boot. I want these applications to be like the Linux kernel. The Linux kernel is a standalone application, and will re-configure the SoC on boot, overwriting whatever u-boot did. I want the Codewarrior applications to do the same.

0 Kudos

1,297 Views
Pavel
NXP Employee
NXP Employee

Look at Readme from u-boot:

http://git.denx.de/?p=u-boot.git;a=blob_plain;f=README;hb=HEAD

Find "Standalone HOWTO" in this file.

 

See also the following page:

http://www.denx.de/wiki/view/DULG/UBootStandalone


Have a great day,
Pavel Chubakov

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

0 Kudos

1,297 Views
jasonfohr
Contributor I

I am correctly booting into the code warrior application from u-boot. I have no problems with u-boot. My issue is with codewarrior IDE and the default project setup. The application code was developed in codewarrior IDE using codewarrior settings. This means the printf function is build using codewarrior libraries. My question was more how to boot a code warrior image from RAM so that it works when being loaded from a bootloader like u-boot.

Those links are more focused on the u-boot environment, which is not where i'm having trouble.

0 Kudos