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

Bruce,

Elf support was added on the following commit.
http://support.criticallink.com/gitweb/?p=u-boot-mitydspl138.git;a=commit;h=664282611755f43d396887e3ba2c8f06e275ea86

The latest MDK should have this change and includes the latest compiled uboot image in the /images folder
http://support.criticallink.com/redmine/attachments/download/3047/release_2013-05-15.run

Jonathan,
Thanks for pointing me in the right direction. I have downloaded the latest MDK and installed u-boot. The bootelf command was there but appeared to not work. It attempted to jump to address 0x00000000 which was never going to work!

To explain what we have: Our application is built with TI's Code Composer and runs standalone of any O/S (it contains its own schedular). The output from Code Composer is set to ELF format. What I tried was to load the ELF image into RAM at 0xc0700000 and simply did a 'bootelf 0xc0700000'. It then appeared to try and start from address 0x00000000 and halted.

We have run this as a binary on the board by converting the ELF build file to a flat model binary using TI's tools (which are no longer supported). Then, using u-boot, we load the binary into RAM at the correct location and jump to the start address. This works fine which proves that our image is OK, but we thought it would be better to use the ELF tool in u-boot.

Would you say that what we are trying is valid?

Thanks,
Bruce

You may need to provide an "entry point" argument to the linker to point to the location in memory that the code should jump to. Have you dumped out your elf headers? I think by default the entry point is 0 for linux apps as it will get relocated anyway and dropped into user mapped space. The u-boot elf loader is not that smart (it doesn't relocate, etc.).

You can try iminfo in uboot to get the ELF header information.

-Mike

Mike, thanks for your reply.

I tried lminfo and it doesn't recognise the image. I attach a log of the u-boot commands used and a small dump of the file. Also a log from a PC application (readelf) which seems to decipher the header OK.

We do have a start location specified in the image (0xc0000000).

Your comment that bootelf doesn't relocate makes me think that I am expecting something that isn't implemented. What I expected was that bootelf would scan through an ELF image and copy the various sections to the correct locations in RAM (i.e. code, data, constants, ect.) and jump to the entry point. Is this not the case?

Kind regards,
Bruce

The above thread has gone a little cold, does anyone know if uboot ELF loader should work with TI Code Composer generated images?

Thanks,
Bruce

Hi Bruce,

Looking at your elf information, it looks like you are loading the ELF image to 0xc0700000, which is right in the middle of your text areas (the seem to span from 0xC0000000 through 0xC0CBFFFF or thereabouts).

Am I reading that right? So as bootelf starts running it's going to unpack the ELF sections right over the top of the ELF file, including the headers, before it jumps to the entry point, which likely just got stomped by the loading process.

Try loading to 0xC2000000 or 0xC5000000 so that your ELF image is away from u-Boot as well as the "unpacked" sections when the ELF loader runs.

Does that help?

-Mike

Oops, my silly. That now works, it takes the TI CCS image and moves sections to the correct address and runs

Thanks again for your help.
Bruce