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

[Eric Weddington]

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> rg] On Behalf Of Joerg Wunsch
> Sent: Tuesday, May 08, 2007 10:00 AM
> To: address@hidden
> Subject: Re: [avrdude-dev] [task #5093] Add support for 
> reading ELF files.
> 
> Yes, some kind of avr-libc API.  My (rough) ideas are something like
> 
> LFUSE(OSC_INT_RC | SUT_14CK_65MS | CKDIV8);
> HFUSE(SPIEN | JTAGEN | BOOTSZ_4096);
> 
> or maybe (for those who already know what they want)
> 
> LFUSE(0xe2);
> HFUSE(0x91);
> 
> but then, why not simply
> 
> FUSES(0xe2, 0x91);
> 
> ?

Or to extend it further:

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


> (Only the LPM fuse reading breaks that by using the
> index order lfuse, lock, efuse, hfuse.  Ick.)
> 
> The application can read them, but not really in an indexed way, OK.

Ah, my bad. I wasn't aware that the app could read them.

> Anyway, all the other tools treat the fuses and lock bits as a kind of
> memory space, including the Atmel stuff (JTAG ICE, STK500 protocol),
> and so does avrdude (and avarice) internally.  It juest doesn't make
> any sense to me to try pretending they were anything else than a
> memory space which would justify treating them differently than other
> memory spaces.
> 
> > The application can address flash, sram, and eeprom. It cannot
> > address the fuses.
> 
> That doesn't matter here as the user simply doesn't care at all about
> whether we use section names, memory offsets, a pile of postcards or
> whatever as long as it works.  It doesn't matter whether these memory
> ranges are user addressable but whether the tools treat them rather
> uniformly -- and they do.  (Btw., reading lock and fuse bits in the
> AVR much more resembles reading ROM than accessing the EEPROM does.
> The former uses LPM, the latter goes through a peripheral device.)

(Sort of. Yes, it uses LPM but only after you load Z with the address, set 2
bits in a register, hop on one leg, bow to the east,... Oh, sorry. I got
carried away. Somewhat similar to EEPROM accesses. ;-)

> 
> > 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 guess this has several reasons, the ELF file looks rather opaque to
> the user (``I don't know what I'm really giving away when I send that
> file to my customer.''), while one can ``look inside'' the hex file
> easily.  The ELF file probably has a reputation of being fat and
> bloated.

I don't think it's so much fat and bloated as it's a binary format and one
cannot throw it an editor to see what it contains. But that's why we have
these conversion utils.
 

> > Even if we don't necessarily have the tools go off of fixed section
> > names, is there some other way, in the ELF file, to tag one or more
> > sections, as belonging to "fuses" without it having to have some
> > magical address offset that is bogus to begin with?
> 
> No, ELF doesn't know about multiple memory spaces.

Bah! Just like GCC...
 
> > the fuse bytes into individual sections (1 byte per 
> section) and have the
> > tools then work with these fixed section names, because 
> they can't be
> > combined with any other section, ...
> 
> You are repeating this over and over again, but I still don't see what
> you think here.  I don't see what having three different sections
> (name space bloat) of one byte each would buy us, compared to one
> section of variable (currently max 3) length.  *Who* do you think
> would ever manually mess with the combined fuse space, and then, if he
> did, why do you think that person wouldn't be able to do the very same
> with the three single sections?

I just want to make sure that there is not a way for the user to
accidentally get them in the wrong order via the tools. If the avr-libc API
is such that all 3 would have to be defined at once and it perserves the
order for the user, then that's ok.
 
> A mere mortal simply won't notice any of these anyway, they do appear
> in the linkerscript (but they have to appear there anyway in order to
> be dragged into the output ELF file).  Btw., I think if you don't go
> for the offset option, you'll end up in complaints about overlapping
> sections from the linker (as your new fuse sections all start at
> offset 0, and thus would appear to collide with the interrupt vector
> table).
> 
> I guess before discussing that further, there should really be a
> prototype implementation of the entire toolchain: libc macros
> (simplified API draft), linker script modifications, test run.

Ok, agreed.
 
> > 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.

Eric