Re: [avrdude-dev] [task #5093] Add support for reading ELF files.

[Joerg Wunsch]

As Eric Weddington wrote:

> Or to extend it further:

> FUSES(OSC_INT_RC | SUT_14CK_65MS | CKDIV8,  SPIEN | JTAGEN | BOOTSZ_4096);

Yes, that's the basic idea.  I don't know whether individual macros
for each fuse or one for all of them would make it simpler for the
user.  Probably individual macros as Colin suggests the user might
want to update just one of them.

Alas, each AVR might have a different default fuse, so we cannot
simply use 0xff as the default value.

> > > The "universal hex file" is the resulting ELF file from the
> > > toolchain.

> > I've heard voices here that not everybody would be happy about this.

> I don't think it's so much fat and bloated as it's a binary format

Still, it carries a lot of baggage along with it:

% ls -l foo.elf *hex
-rwxr-xr-x  1 j  staff  5115 May  8 21:49 foo.elf*
-rw-r--r--  1 j  staff  4297 May  8 21:48 largedemo.hex
-rw-r--r--  1 j  staff    30 May  8 21:48 largedemo_eeprom.hex

The .elf file on top has *only* the `alloc' sections in it.

Sure, it's not *that* fat.  But users have their habits, and often
have been using load files like intel hex for years.

> > > If we're moving towards using the ELF file for everything, then
> > > it doesn't make sense to add the flat hex file capability to the
> > > tools.

> > For avrdude, both would actually be identical as libbfd can handle
> > both input formats transparently.

> Agreed that it would be straight-forward work. IMO, it would just be
> unnecssary work.

The cool thing with libbfd is that it actually *isn't* more work at
all.  It's all there already.


As Colin O'Flynn wrote:

> For the namespace vs. offset:

> Are you allowed to use both? aka can I pull the "magic offset" from
> some known non-changing section?

It doesn't make much sense.

> The code would then do this:

> --Look for section .eeprom
> --Get address of .eeprom starting

But what if the user moved the start address?

The existing offsets have been there for several years now, and are a
fairly stable constant these days.

> Which could make just one ".fuse" memory section that contains the
> three bytes. Or it could possible be renamed something more general
> purpose, such as ".hardware" or whatnot. Then we could fit the
> processor type, signature bytes, etc all in there.

Well, these are not writable.  But the lock bits come to mind.  Alas,
at least in the JTAG ICE, they got their own memory space.

> You absolutely *must* be able to program a single fuse byte IMO.

OK.

> That way you just change what you need...

You still have to specify all bits for a byte though.

> I also plan on the "magic" mode of avrdude having it see if the
> fuses need to be changed, and only changing them if they differ. So
> if the user can say they don't care about a certain fuse that's even
> easier.

OK, fine.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)