Michael Hennebry <[EMAIL PROTECTED]> wrote: > You can let the tool read or infer the offsets from the elf file. > E.g. any 1 byte section named .hfuse can be infered to carry fuse > data regardless of its offset.
What about things like user-defined EEPROM sections? User-defined ROM sections? Oh, there's already a popular one named .bootload. I'm not too fond about the idea of hardcoding section names. This didn't work too well in the past -- look at all the people who try to debug an application consisting of a .text plus a .bootload section in AVR Studio within a single application. Let's face it, our linker can already only handle a flat (32 or more bits wide) address space anyway. It will take any section starting at address zero as an overlap of another section starting at address zero, and complain about it. The work^H^H^H^Hhackaround has been to introduce offsets which are simply way beyond the address space implemented in any AVR's single memory area. There's a well-established set of offsets already (with AVR-GDB being the one using the most different memory regions right now), and if we have to extend the list of offsets (like for fuse bits), we can always do. The advantage is that the result will not only work on ELF files but also on image files like Intel Hex, provided (obviously) you generate a single hex file combining the contents of *any* loadable section, i.e. you don't have any -j or -R options on the avr-objcopy command-line. The offsets will then simply propagated into the hex file, and all that needs to be done is teaching avrdude about the physical memory regions each offset describes. This could be done in the config file on a per-device base, so suppose Atmel would suddenly start producing a new superior controller, say they call it Xmega :), which considerably extends the flash ROM address space, well, the Xmega family would simply use a different set of offset than the classic AVRs used to use. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) _______________________________________________ AVR-chat mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avr-chat
