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

[Joerg Wunsch]

As Eric Weddington wrote:

> I know that you lean towards having a single .fuse space with multiple
> bytes. Can you answer these questions:

> - How would a user specify the fuse information in their application (with a
> proposed avr-libc API that was discussed)?

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);

?

> - How would a user specify each fuse byte individually?

Do they need it?  Don't they simply want to program *all* fuse bytes?

Anyway, see above.

> - How would the user know which byte went to which fuse address location?

Why do they need to know?  As long as the connection between the names
above and the actual fuse is obvious, I don't think anybody cares.

Despite, it's always been obvious to me that the index order is lfuse,
hfuse, efuse.  (Only the LPM fuse reading breaks that by using the
index order lfuse, lock, efuse, hfuse.  Ick.)

Also, see another posting from me: new fuse bytes did appear in the
past over thee lifetime of a product line (the AVR8).  In case the
current fuse space exhausts, and somone things the Xmegaplus needs
another ultrafuse, the single address space for all fuses could simply
be extended, without touching everything again.

> > And unlike the offset hack, that parameter
> > cannot be applied universally, so the old offset hack cannot be
> > replaced by it.  But then, we'll end up in two things for the same
> > purpose: to distinguish different target memory spaces, some of them
> > would be recognized by section name, and some of them would be
> > recognized by their internal offset.

> That is a bogus argument. The fuses don't necessarily have their own
> "target memory spaces" because *they are never seen by the
> application*.

The application can read them, but not really in an indexed way, OK.
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.)

> 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.

> Avrdude needs to have this capability. If they can all program the AVR
> from an ELF file, then there is no need for them to work with multiple hex
> files, or a bastardized hex file.

If you call that hex file `bastardized', why don't you attribute the
ELF file the same? ;-)

> 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.

> 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?

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.

> 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.

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

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