As Eric Weddington wrote: > Hmm. Can you explain your reasoning a bit more? I'm at a loss in > understanding why we cannot reserve certain section names in the ELF > file.
. Be consistent. The existing scheme (use the well-established offsets) works fine, and there's no need to invent a parallel scheme. The offsets are/have been in use by the entire toolchain. . It cannot be made the universal decision base anyway. See the AVR Studio failure for the .bootload section for an example. Colin mentioned more examples: people might want to have more than one EEPROM section (e.g. to impose a certain externally-synchronized structure to their EEPROM data), so you could not rely on .eeprom being the only EEPROM section. But now, if you cannot rely on some names, where are you drawing the line? The chose of lfuse etc. is rather arbitrary, as obvious as it might be in the first place. Again, it doesn't solve anything that could not likewise be solved by applying the already established offset 0x820000. . The offset hack can even be transported across non-section structured file format (like Intel hex), something that has been requestd as a feature here. As Colin O'Flynn wrote: > For hfuse/lfuse/efuse/fuse section it seems unlikely you would > invent your own section name though. As well if someone accidently > put something in the fuse address space, you could get garbage > programmed in. They would need to modify their linker scripts for that to happen. But then, they are responsible theirselves. My idea about the fuse space is to still use section names on the linker input, but then convert that into section name + offset at linker output, just as it happens for .eeprom. > However - if you'd rather see addresses used for the fuses, what > should the layout be for fuse/lfuse/efuse/hfuse? I'd vote again for a combined fuse address space. IMHO it's been a failure from Atmel to establish different names for the individual fuses, rather than making them an array of fuse cells (which it actually is). The layout is simple: fuse = lfuse, hfuse, efuse. Any additional fuses (of future AVRs) could be added on the fly behind. Basically, that's already the way the JTAG ICE handles the fuses (they do have their own address space there). > > I'm really fine with adding ELF support to avrdude though I'd like > > to see it configure-time optional so people who don't want to > > install the prerequisite libiberty and libbfd could continue as > > they used to. > Sounds good! Again I'm not quite sure how to edit the configure file. You could have a look at the examples that are already there, like libusb detection, and the various AC_ARG_ENABLE statements. > Right now it *only* allows individual updates. So you have to > specify lfuse, efuse, etc. It allows you to do: > -U w:elfuse:main.elf -U w:flash:main.elf > So you have the same file. This way it makes the minimal changes to > the avrdude user interface, it pretty much only adds support for ELF > file programming. OK, I already thought of that, too. > After this is all sorted out and commited, then the magic mode could > be added. Like -U w:*:main.elf :) > There was a lot of discussion on that earlier so I hoped to just add > ELF support without anyone getting mad yet! You don't get me mad ;-), I always intended to write up all this before, but somehow forgot about it. I'm really sorry about that, Colin. Btw., I always thought that adding automatic fuse setting to the compiler, library, and avrdude would be a good thing (and something the PIC people did have years before). I've been discussing that with Brian Dean before, and also on and off in public forums. I'm really thankful that now finally, someone from Atmel (hi Eric :) is pushing that issue. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) _______________________________________________ avrdude-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avrdude-dev
