As Eric Weddington wrote: > > . It cannot be made the universal decision base anyway. See the > > AVR Studio failure for the .bootload section for an example.
> For some reason I'm drawing a blank on this; I can't seem to > remember the issue. Could you refresh my memory? At least in some version, AVR Studio also had implied knowledge about the object file section names, and it only handled .text, .data, and .bss. Perhaps that has been fixed since, it could be it has been in the COFF era. My only point was that implied knowledge about names that can be otherwise freely used by the programmer is evil. > One cannot make comparisons to the EEPROM section here. Why not? Technically, what's the difference between the array of EEPROM cells available through the EE* IO registers, and the array of EEPROM cells available as fuse bits? > With fuse sections, there is only 1 byte per section, > so there is nothing to add. (Or just one fuse sections with up to three bytes by now.) My point is: relying on a section name adds another parameter that has not been used at all in the past, at least not inside the tools (only at the Makefile level). 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. Does that really make sense to you? To me, it doesn't. As ugly as it is, I'd then rather stay with all the various offsets. > > Again, it doesn't solve anything that could not likewise be solved > > by applying the already established offset 0x820000. > True, execept that those offsets are also arbitrary and they also > become "magic numbers" instead of having meaningful names. Yes, they are magic, but they are not user-visible (well, to some degree, they are, but that's most annyoing for SRAM where you cannot avoid it anyway). > > . 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. > Which is bogus. Right now, the tools put the flash data in one hex > file, and the eeprom data in a separate hex file. Which has probably been a failure right from the beginning. This distinction into multiple files has not been necessary at all. > Where should one put the fuse data? In the flash hex file? In the "universal" hex file. Just run avr-objcopy without any -j or --change-section-lma options, and you'll yield exactly that file. It will contain the entire containts of all loaded sections (text, data, eeprom, fuse) flattened to one file, but no meta information (symbol table, debugging information). No three, four, or five hex files needed. Of course, I don't say this should completely obviate the need for also reading ELF files. There's not much point in running the avr-objcopy step into an ihex file at all if we also could get the same information from the ELF file. Btw., that's what AVaRICE used to do for years (except they didn't extend the idea to fuses). > If one puts the fuse data in with the flash hex file, at these large > offsets, then standard tools will not be able to work with these > files. Those tools that cannot handle the flattened hex file have to be fed their individual hex files as they got them by now. They won't be helped with the ELF file approach either though. However, we can teach avrdude to handle the flattened hex file, and we (i.e. you :) could perhaps even teach the Atmel tools to handle it. Right now, the Atmel tools don't have any option to handle fuse file settings as being part of a load file anyway (only specified on the command-line, similar to the "m" option of avrdude), so it would be a worthwhile addition. > If we have a single ELF file, then why can't we just use section > names, and why do we need to have arbitrary offsets? Because we already need offsets for at least two memory spaces anyway (flash ROM and EEPROM where we cannot get rid of it), and I don't see a point in having two different methods for the same purpose (distinction of target memory spaces). -- 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
