> -----Original Message----- > From: > [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > rg] On Behalf Of Joerg Wunsch > Sent: Tuesday, May 08, 2007 10:00 AM > To: [email protected] > Subject: Re: [avrdude-dev] [task #5093] Add support for > reading ELF files. > > 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); > > ?
Or to extend it further: FUSES(OSC_INT_RC | SUT_14CK_65MS | CKDIV8, SPIEN | JTAGEN | BOOTSZ_4096); > (Only the LPM fuse reading breaks that by using the > index order lfuse, lock, efuse, hfuse. Ick.) > > The application can read them, but not really in an indexed way, OK. Ah, my bad. I wasn't aware that the app could read them. > 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.) (Sort of. Yes, it uses LPM but only after you load Z with the address, set 2 bits in a register, hop on one leg, bow to the east,... Oh, sorry. I got carried away. Somewhat similar to EEPROM accesses. ;-) > > > 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. I don't think it's so much fat and bloated as it's a binary format and one cannot throw it an editor to see what it contains. But that's why we have these conversion utils. > > 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. Bah! Just like GCC... > > 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? I just want to make sure that there is not a way for the user to accidentally get them in the wrong order via the tools. If the avr-libc API is such that all 3 would have to be defined at once and it perserves the order for the user, then that's ok. > 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. Ok, agreed. > > 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. Eric _______________________________________________ avrdude-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avrdude-dev
