To support AVR DA/DB/DD/EA/DU part, similar to optiboot_dx

[mcuee]

Stretch goal will be to add the support of AVR DA/DB/DD part, similar to optiboot_dx.

Ref: optiboot_dx is too diffierent to be included in optiboot (optiboot_x is integrated into optiboot).

• https://github.com/Optiboot/optiboot/issues/353#issuecomment-1312347766

[WestfW]

Suggestions: Spec currently says "Implicit communication of further bootloader properties happens through a small table located at the top of flash." That would need to change for the Dx parts, since the bootloader section is in low memory :-( Perhaps "at the top of the bootloader section"

If the EEPROM functions are change to allow either negative offsets or to use data-space addresses instead of EEPROM addresses, the functions can be used to access fuses, userrow, and sigrow info as well as eeprom. (Dx devices always have EEPROM mapped into the RAM address space.) (this is also true on xTiny and mega0 chips.)

[stefanrueger]

Perhaps "at the top of the bootloader section"

Thanks, great point! Would that need to be either at top of the bootloader section or near the bottom of the bootloader section?

If it is a Dx part, then AVRDUDE wouldn't know where the top of the bootloader section is (because urboot bootloaders come in different sizes), but it might know where the bootloader section starts, so could read the first page of the bootloader section to suss out configuration etc.

The idea is that rather than implementing an explicit command to the bl asking for capabilities/bl config etc, AVRDUDE is to use the already existing UR_READ_PAGE _FL (or STK_READ_PAGE) to read a config table in the bootloader. However, AVRDUDE would need to know where in flash to find the table. Currently urprotocol works like this:

• AVRDUDE contacts the bootloader to get in sync
• Bootloader answers with Sync/OK bytes that indicate which part the bootloader sits on
• AVRDUDE knows where FLASHEND is on classic/xmega parts, and reads the last page in flash to access the table

[mcuee]

The idea is that rather than implementing an explicit command to the bl asking for capabilities/bl config etc, AVRDUDE is to use the already existing UR_READ_PAGE _FL (or STK_READ_PAGE) to read a config table in the bootloader.

Is this the reason that avrdude -c urclock will not work with Arduino as ISP whereas both -c arduino and -c stk500v1 work fine?

[WestfW]

[top of the bootloader section]

Well, combined with the EEPROM idea in that note... If it's a Dx part, avrdude could theoretically ready the fuses to figure out how long the bootloader section is...

BTW, it bothers me to have "MCU ID" numbers that a chip can not determine from its own hardware. (Yeah, I realize that this is from the original STK500v1 spec.) It seems like we could use the chip signature bytes 1 and 2 (0 is always 0x1E) for our special SYN and OK characters. SIGNATURE_1 (mentioned in some (historical?) datasheets as indicating memory size) only seems to span the range of 0x90 -0xA8, so there would be room to introduce the capabilities bits in there somehow...

[stefanrueger]

OK, got you. On Dx parts the bootloader would be able to read from a linear address space that folds everything into it: fuses, signatures, calibration bytes, EEPROM, SRAM, flash, ... Implementing one page read and page write call each would be sufficient. And, requiring the BOOTSZ fuse to be set to the bootloader size would give us to bootloader. I'll have to start reading the data sheet carefully.

it bothers me to have "MCU ID" numbers that a chip can not determine from its own hardware

Using the signature for IDing simply doesn't work. 58 signatures in avrdude.conf clash (you need avrdude main-line for the following line):

$ avrdude -p*/d | grep = | cut -f2-3 -d, | sort | uniq -c | awk '$1 > 1' | wc -l
58

Most will be "mild" clashes, eg ATmega329 and ATmega329A. But then there are serious ones: Take for example ATxmega64B3 and ATmega4809; they have the same signature but could hardly be more different: different family, different programming interfaces, different flash size, different flash page size, different EEPROM size and different EEPROM page size:

$ avrdude -p*/d | grep 0x96..0x51
  'ATxmega64B3' =>      [0x1E, 0x96, 0x51, 0x00800000, 0x11000, 0x100, 0x8c0000, 0x0800, 0x020, 0, 0x000, 0x0013, 'PM_SPM | PM_PDI | PM_JTAG'], # /usr/local/etc/avrdude.conf 11828
  'ATmega4809' =>       [0x1E, 0x96, 0x51, 0x00004000, 0x0c000, 0x080, 0x001400, 0x0100, 0x040, 0, 0x000, 0x0013, 'PM_SPM | PM_UPDI'], # /usr/local/etc/avrdude.conf 14408

These clashes are the principal justification for establishing an MCU Id. Plus (as we have15.99 to play with) I figured I could transfer more beyond the MCU Id (5 extra bits).

I realize that this is from the original STK500v1 spec

Atmel's way of assigning unique numbers was a failure even then. The MCU ID's are just a way for the programmer AVRDUDE and the bootloader to agree on which chip they talk about.

SIGNATURE_1 (mentioned in some (historical?) datasheets as indicating memory size)

I tried vvv hard to drum up some sense from the signature bytes... to no avail.

Even if signatures had worked (and Atmel had not messed up signatures so badly in the past), we would have been at the mercy of Microchip not messing up in the future :)

[SpenceKonde]

The second byte of the signature DOES indicate flash size with the low nybble, which is n, where flashsize = 1kb * 2^n. The high nybble is either 9 or A (A on exotic parts generally - likely a flag for some feature or another. Parts where n is not an integer (ie, ATmega480x, half-kb AVR-rc parts), it is rounded up, except in a few extreme oddball cases.

[stefanrueger]

| rounded up

Not good enough: urboot bootloaders provide a small info table with their properties at the end of the bootloader section, so the uploader can read that table (at no extra code cost as reading flash is implemented anyway). For classic parts the uploader needs to know exactly how big the flash is so it can read that table at the end of flash (= end of boot section). Signatures are not sufficient. Urboot exchanges an MCU ID with the uploader during handshake via a side channel that costs zero(!) bytes additional bootloader code to achieve this.

[SpenceKonde]

Ah - yeah I suppose that would be a problem on classic AVRs