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

[Colin O'Flynn]

Hello,

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

Right now I use section names, so that needs to change. But if using the magic 
offsets replace the section names, it would work for almost any format of 
course...

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

If we got the default fuse programmed in the avrdude configuration file, you 
could also add a command that brought the AVR back to "factory" state. Handy 
if you were prototyping with a device than wanted to put it away into a 
drawer, or just pulled a random device out of a drawer... make the fuse bytes 
something sane.

Also handy for new users who screw up the fuses and have to rescue the device. 

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

Hmm... though you bring up a good point, that you need to draw the line 
somewhere. If someone is messing around with their fuse bytes they should be 
able to read the default value and plug that in.

How would you check if a section has data or not based just on the offset? As 
we really want to avoid programming nonsense in when it's not there. 

Could avr-libc be set up to do for example the three fuse bytes, followed by 
the inverse of their bytes... and avrdude checks for that pattern?

> Well, these are not writable. 

I was thinking more of solving the other problems mentioned before, of getting 
the AVR device into the .ELF file so avrdude can get that automagically.

Regards,

 -Colin

On Tuesday 08 May 2007 17:09, Joerg Wunsch wrote:
> 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.