Project

General

Profile

How to run bin application via u-boot?

Added by Ahmed Shaaban over 10 years ago

Hi everyone,i have MityARM1808F.
I could use "bootelf" command[ex: bootelf 0xc0700000] to run any app.out,but the size of .out format is usually large(in my case is about 5 Mega byte which is too large to be saved on SPI flash with FPGA image) so i converted it to app.bin format but i couldn't find the u-boot command to run it.
So how to run app.bin via u-boot?


Replies (9)

RE: How to run bin application via u-boot? - Added by Alexander Block over 10 years ago

Posting some previous direct followup e-mails from the customer.

I have followed the steps of the Starterware wiki ([[https://support.criticallink.com/redmine/projects/arm9-platforms/wiki/StarterWare]]) and I could run elf (UART_MITY_ARM.out) format successfully.
Now, I need to know if I could convert .out to .bin (which size is smaller than the out (ELF) image) and I need to know how to save it into SPI flash, but i didn't find Uboot cmd to run bin format only elf format (.bin - bootelf).

So, how do I run the bin format for an ARM app?

The reason behind why i want to use .bin instead of .out is as follows:

I'll put the CPU application and FPGA image in SPI NOR Flash and the problem is the .out size is very large (5 Mbyte and may increase as the application is under development) unlike the .bin which size is 400 Kbyte.
So i want to use .bin instead of .out (ELF).

I have tried loadb and go Uboot commands as follows:

Hit any key to stop autoboot: 0
U-Boot > loadb 0xc0700000
## Ready for binary (kermit) download to 0xc0700000 at 115200 bps...
## Total Size = 0x0000b650 = 46672 Bytes
## Start Addr = 0xc0700000
U-Boot > go 0xc0700000
## Starting application at 0xc0700000

But as you see it didn't work.

I have already tried to load .out/.bin in the following addresses :
0xC3000000 and 0xC30078C8 (which is the entry point in the map file ), but nothing works.

So if you got time could you try the following steps on a Mity kit and let me know the result:
1- load "UART_MITY_ARM.out" using either "tftp" or "loadb" U-boot commands.
2- use "go" command.

I really appreciate your guidance.

Note:
I have done the previous steps on Starterware .out example and it didn't work either.

Attached is the zip file containing the sample projects the customer is trying to run. They were built in CCS 5.3 and he is using an XDS 100 v3 emulator.

RE: How to run bin application via u-boot? - Added by Michael Williamson over 10 years ago

I think you need to strip the .out file (make a release version that removes the debugging information).

If I get a second I will try it out.

-Mike

RE: How to run bin application via u-boot? - Added by Ahmed Shaaban over 10 years ago

Hi Mike,
I have tried what you mentioned and it didn't work.
I'll wait your trial.
Thanks in advance.

RE: How to run bin application via u-boot? - Added by Michael Williamson over 10 years ago

Just to confirm, you have the compiler option "--symdebug:none" in your release compile and link options?

-Mike

RE: How to run bin application via u-boot? - Added by Alexander Block over 10 years ago

Ahmed,

I believe Mike was suggesting that you build the application as a "release" version without any debugging and see what the resulting application file size is?

I.E. if it was 5MB in debug maybe it's 2MB in release, thus no need to bother with the binary conversion.

If that is not the case as you saying that when you built your application in a "release" mode it stopped working, again still as the .out (elf) format?

Alex

RE: How to run bin application via u-boot? - Added by Ahmed Shaaban over 10 years ago

Michael Williamson wrote:

Just to confirm, you have the compiler option "--symdebug:none" in your release compile and link options?

-Mike

Thanks Mike.
Unfortunately I didn't check this compiler option and now It's my weekend so I'll check it on Sunday and let you know.
But just for my curious, there is no U-boot command is used to run .bin format is that right?

Alexander Block wrote:

Ahmed,

I believe Mike was suggesting that you build the application as a "release" version without any debugging and see what the resulting application file size is?

I.E. if it was 5MB in debug maybe it's 2MB in release, thus no need to bother with the binary conversion.

If that is not the case as you saying that when you built your application in a "release" mode it stopped working, again still as the .out (elf) format?

Alex

Thanks Alex.
Exactly that what I understood from Mike's post and after i used release option the .out size became 2MB(while .out size in debug was 3MB) without checking the compiler option "--symdebug:none". So i told Mike it didn't work(i mean the idea of reducing the .out size by using release option) because i didn't notice a big difference in the .out size. Sorry for the misunderstanding i made.

RE: How to run bin application via u-boot? - Added by Ahmed Shaaban over 10 years ago

Hi Mike,
I have set the compiler option to "--symdebug:none" and the size of the .out file generated is also 3 MB.
Is there another option to minimize the size of out file? and as i asked you before is there a Uboot command to execute .bin format?
Thanks in advance.

RE: How to run bin application via u-boot? - Added by Michael Williamson over 10 years ago

Hi Ahmed,

If I knew the answer to using a bin file beyond "go", as you asked before, I would have told you before. :^)

So you set the --symdebug:none option and the filesystem grew on your Release build from 2MB to 3MB? That's odd.

The .out file clearly is not getting stripped of debug data if it is still 3MB vs. 400 kB. I really think we should focus on figuring out what is still in that file. The relocation information and section tables of an ELF file should not be consuming 2.5 MB of space and would be worth having so you don't need to store all that magic in your load scripts.

The SPI-NOR is 8 MB in size. 3 MB plus the FPGA code should easily fit in the SPI. You also have a fairly large NAND device available for image storage which is must quicker that the SPI device. Can you use that? Are you trying to get to a shorter boot time?

As I said before, I (or someone else at CL) will need some time to look into loading your .bin file directly. It's non-trivial, and not a use case most of our customers require (those few using Starterware are OK loading the .elf / .out files).

It is mentioned on the wiki that the .bin file generated in the Starterware flow will not work because Starterware jams it's own bootloader with an AIS header that is specific to the Logic PD or TI EVM. It has code to reinitialize DDR and the PLLs, etc., that has already been done by the UBL and UBoot available on the MitySOM modules. To use that flow you would need to remove the UBL and uBoot (replacing it with the binary from Starterware) and make sure that the Starterware settings initialized the DDR and pinmux properly for our SOM. Once you do that, you don't have the flexibility to update your application unless you build it into your application or use a JTAG interface.

I don't know off hand what's inside the bin file (what format is it? AIS? COFF Object? how/where are the interrupt vectors stored? is there a C runtime initialization block to set up the stack pointer? etc.). In theory the bin file could be loaded directly to the proper locations in RAM and you would run "go" from uBoot and you program should work. But it's not clear how to parse the binary file for loading memory.

If I get time, I can investigate, but it may take a while.

-Mike

RE: How to run bin application via u-boot? - Added by Ahmed Shaaban over 10 years ago

If I knew the answer to using a bin file beyond "go", as you asked before, I would have told you before. :^)

I'm Sorry for my insistence.

So you set the --symdebug:none option and the filesystem grew on your Release build from 2MB to 3MB? That's odd.

No, the size didn't change much (debug out size is 3.06 MB and release out size is 2.88 MB).

The .out file clearly is not getting stripped of debug data if it is still 3MB vs. 400 kB. I really think we should focus on figuring out what is still in that file. The relocation information and section tables of an ELF file should not be consuming 2.5 MB of space and would be worth having so you don't need to store all that magic in your load scripts.

I hope you help me to do that.

The SPI-NOR is 8 MB in size. 3 MB plus the FPGA code should easily fit in the SPI. You also have a fairly large NAND device available for image storage which is must quicker that the SPI device. Can you use that? Are you trying to get to a shorter boot time?

Yes, i want to minimize boot time.

As I said before, I (or someone else at CL) will need some time to look into loading your .bin file directly. It's non-trivial, and not a use case most of our customers require (those few using Starterware are OK loading the .elf / .out files).

Take your time, I'll be waiting.

It is mentioned on the wiki that the .bin file generated in the Starterware flow will not work because Starterware jams it's own bootloader with an AIS header that is specific to the Logic PD or TI EVM. It has code to reinitialize DDR and the PLLs, etc., that has already been done by the UBL and UBoot available on the MitySOM modules. To use that flow you would need to remove the UBL and uBoot (replacing it with the binary from Starterware) and make sure that the Starterware settings initialized the DDR and pinmux properly for our SOM. Once you do that, you don't have the flexibility to update your application unless you build it into your application or use a JTAG interface.

You are totally right.

I don't know off hand what's inside the bin file (what format is it? AIS? COFF Object? how/where are the interrupt vectors stored? is there a C runtime initialization block to set up the stack pointer? etc.). In theory the bin file could be loaded directly to the proper locations in RAM and you would run "go" from uBoot and you program should work. But it's not clear how to parse the binary file for loading memory.

If I get time, I can investigate, but it may take a while.

Thanks for your effort.

Note:
I have tried some ideas i want to share with you.
After some digging on the internet i found that [[http://e2e.ti.com/support/embedded/linux/f/354/p/168449/614814.aspx#614814]]:
there is a mistake in the config.mk file of "u-boot-mitydspl138/lib_arm"
line 32=> STANDALONE_LOAD_ADDR = 0xC100000 (there is a zero missing)
i changed that address to 0xC2080000 (entry point of Uart echo example of "CL MitydspL138_Starterware") then i rebuilt the uboot then i converted the .out to .bin.
Using the Uboot "tftp 0xC2080000" command i load the bin file then i used "go 0xC2080000" command and the starterware message appeared on Hyper terminal.
I have done the similar to SYS/BIOS project (UART_MITY_ARM) but nothing works.
I always receive this message :
(Note => I rebuilt uboot with STANDALONE_LOAD_ADDR = 0xC2087B2C )
U-Boot > tftp 0xC2087B2C 192.168.0.1:UART_MITY_ARM.bin
Using device
TFTP from server 192.168.0.1; our IP address is 192.168.0.2
Filename 'UART_MITY_ARM.bin'.
Load address: 0xc2087b2c
Loading: ####
done
Bytes transferred = 47280 (b8b0 hex)
U-Boot > go 0xC2087B2C
  1. Starting application at 0xC2087B2C ...
  2. Application terminated, rc = 0xFFF00C12

So tell me how to fix this if you can?

    (1-9/9)
    Go to top
    Add picture from clipboard (Maximum size: 1 GB)