ELF "Production File Format" generation

Go To Last Post
21 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi All,

Now that we've got a nice build server happening largely thanks to Bingo's .deb file, we still have one manual process we want to automate: combining two hex files, fuses, user signature row (this is for xmega) and eeprom into a single file.

We currently do the hex file and fuses manually using AVR studio, which gets old very quickly - and it's missing user signature integration.

If I understand the documentation correctly (e.g. https://www.avrfreaks.net/index.p... and http://www.nongnu.org/avr-libc/u...), the ELF files generated as a part of the binutils contains exactly this information - at least for fuse support, not sure.

However, it looks like it's incomplete for my purposes, or (just as likely) I haven't gotten my head around it yet.

What I want to do is generate a "production ELF file format" with:
* Two hex files (bootloader + application images) [edit] srec_cat works nicely to make this into a single image [/edit]
* Fuses
* User signature row, which is where I store the CRC of the applcation.
* (optionally) EEPROM.

I can probably hack something up to do this, but I'm looking to see if the existing tools already do this, and if so, where is the best place for documentation to read up on?

Thanks!
Damien

Last Edited: Wed. Jan 13, 2010 - 01:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well the GCC toolchain already outputs ELF files that AVR Studio can parse to read not only the code image but also the fuse settings. However you hope of combining two program images in one .elf is, I think, going to be close to impossible. Obviously .hex files are easily combined with either Srecord or even a text editor because they are so simple but likelihood of being able to do that in ELF is far more limited.

Given that the bootloader is likely unchanging I think what I'd do is use avr-objcopy to embedded it as a block of "data" in the app .elf at the fixed bootloader address as part of the app building process. This does mean that if it ever changes you will have to then rebuild the app to combine the two.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why not combine the bootloader and the application in the same build? That way the compiler spits out an ELF file that already contains both. I've done this successfully many years ago.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Why not combine the bootloader and the application in the same build?

That's fine as long as the BL doesn't want a vector table, for one just doing simple UART polling it should be fine though.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Well the GCC toolchain already outputs ELF files that AVR Studio can parse to read not only the code image but also the fuse settings. However you hope of combining two program images in one .elf is, I think, going to be close to impossible. Obviously .hex files are easily combined with either Srecord or even a text editor because they are so simple but likelihood of being able to do that in ELF is far more limited.
What happens if one localizes all the symbols in the bootloader before linking them?

Iluvatar is the better part of Valar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Making two (or more) ELF files (or hex files if your linker is build with the BFD library) into one is the job of the linker.

The thing is, the linker is a rather complex thing. You can easily go mad figuring out how to do what you want. gcc knows how to drive the linker, so starting with the compiler to compose your ELF might be a simpler way.

Stealing Proteus doesn't make you an engineer.

Last Edited: Wed. Jan 13, 2010 - 08:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ArnoldB wrote:

The thing is, the linker is a rather complex thing. You can easily go mad figuring out how to do what you want.

That's a great quote! :lol:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Another possibility is a script that takes
two elf files or one tar file as its input.
I'm not sure what programming software can use elf files directly.
The script might need to use objcopy and avrdude.

Iluvatar is the better part of Valar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I'm not sure what programming software can use elf files directly.
Atmel's windows command line tools and AVR Studio if I am not mistaken. Atmel did introduce this under the header "ELF production file format", and I assume this is what the OP is asking about.

Stealing Proteus doesn't make you an engineer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ArnoldB wrote:
Quote:

I'm not sure what programming software can use elf files directly.
Atmel's windows command line tools and AVR Studio if I am not mistaken. Atmel did introduce this under the header "ELF production file format", and I assume this is what the OP is asking about.
In that case,
the OP can use a script that calls a command line tool twice.
That assumes the second call can be told to not erase.

Iluvatar is the better part of Valar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you for the responses and sorry for the delay. I should mention a couple of things to help clear it up.

1) The bootloader is built as a separate project as it uses interrupt vectors and I much prefer for it to have it's own C setup environment. It's a more complex beast than just a simple flash loader.

2) I'm happy to do scripting (or even an entire program) to make this happen - so long as it can run at the end of the ./build.sh script that I have. The concept is that every time a check-in is made to either the bootloader or the application, it gets rebuilt and combined into said ELF file - currently, only the hex files and original uncombined elf files are produced.

One day I want to run automated programming and regression tests at the same time, but we can leave that discussion for another time :)

Hopefully I'll have time to look at it a little more closely this week at it.

-- Damien

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

damien_d wrote:
2) I'm happy to do scripting (or even an entire program) to make this happen - so long as it can run at the end of the ./build.sh script that I have. The concept is that every time a check-in is made to either the bootloader or the application, it gets rebuilt and combined into said ELF file - currently, only the hex files and original uncombined elf files are produced.
Is having precisely one ELF a requirement?
To me, the simplest thing would be two ELFs and a script that used both of them.
Just don't erase before using the second one.
If you have to have just one file, could it be a tar file with two ELFs in it?
The script would untar and proceed as before.

Iluvatar is the better part of Valar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

To me, the simplest thing would be two ELFs and a script that used both of them.

Until the facility to build fuses using GCC was added a year or two back this is the way everyone would have handled this. Many simply use a .bat file on Windows rather than a .sh on Linux in fact that just invokes the Atmel command line tools as many times as necessary to perform all the programming steps.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

To me, the simplest thing would be two ELFs and a script that used both of them.

Until the facility to build fuses using GCC was added a year or two back this is the way everyone would have handled this. Many simply use a .bat file on Windows rather than a .sh on Linux in fact that just invokes the Atmel command line tools as many times as necessary to perform all the programming steps.

Which seems to be a fair conclusion to make. However, the manufacture and chip programming is outsourced, so I'm not sure yet what control we have in that process.

Better talk to the HW guys :)

However, we're yet to sort out the user signature issue, but I'm guessing it will be handled somewhat like the EEPROM. Time to dig!

-- Damien

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

However, the manufacture and chip programming is outsourced, so I'm not sure yet what control we have in that process.

Which is why Atmel make a "command line tools only" download available at www.atmel.no/beta_ware - you just get the production facility to download/install this then send them a .bat file. They just double-click the .bat icon to do the entire programming process.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Since you are already building the boot as a separate project, I would generate the boot image (vectors included) as a binary and include it as a binary object in the app project build. There have been several discussions for directly including binary at a known location in flash.

Even if you have a function table in the boot that is accessed by the app, this will be your easiest solution.

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have this same problem. I want to use a single file for production programming which would include the application, the bootloader, the fuses, and the eeprom.

I can easily create an elf with the app+fuses+eeprom
but then there is no bootloader

I can easily create a merged HEX with the app+BL
but then I have to program the fuses and eep separately.

Is there a tool to create an ELF from the HEX, EEP, and fuses?

I am using AVR Studio 5.1, and a bootloader created with IAR.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cant you just prodice two ELF "as usual" and then, in a second like step driven by own linker script, combine and arrange the ELFs produced in the first step?

ArnoldB wrote:
gcc knows how to drive the linker, ...
The GNU linker is driven and controlled by a linker script, not by compiler witchcraft.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm making a production elf file using the avr studio program device function, by loading the bootloader, uploading the code into the device ( using whatever method required _ - getting it to do any required EEMEM initialisation then .. reading back the code into a hex file, reading back the eemem into a hex file, setting the fuses and lockbits in avr studio settings the setting the target directories in the code and eemem to the ones just saved and then hitting save elf file.
I then program devices using just the elf file and it does everything.
The only thing I'm not sure about is where the 'save elf file' gets it data from because it does seem to access the chip so some of my actions may not be needed. If anyone knows more details how the 'save elf file' feature actualy works I'd be pleased.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

rowifi wrote:
save elf file
Fantastic! It works.
Although saving to elf is only present in AVR Studio 4, I was having a hard time looking for such button in AVR Studio 5.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ganzziani wrote:

Although saving to elf is only present in AVR Studio 4, I was having a hard time looking for such button in AVR Studio 5.

Is it useful in Studio 5?

My version of AVR Studio could program ELF files, but could not Verify. Without Verify if was useless for 'production', and useless using the flaky Dragon programmer, and generally useless...I had to stick with HEX and Fuses.

I haven't looked at Studio 5 yet.