Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

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.

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

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

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

-Mike

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

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.

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.

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

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.

1. Starting application at 0xC2087B2C ...
2. Application terminated, rc = 0xFFF00C12

So tell me how to fix this if you can?