[avr-gcc-list] Xmega class confusion?

[Erik Walthinsen]

Once again I have found myself with a toolchain that doesn't support all 
the various Xmega chips I've been using (this one is from Ubuntu 10.04), 
so I'm trying to fix it up.  However, I've found an inconsistency that 
makes me wonder if all of the various chips are misassigned to the 
"avrxmegaX" classes.

First, the classes from the binutils usage, filled out:

avrxmega1 - XMEGA, < 8K FLASH, [<= 64K RAM?]
avrxmega2 - XMEGA, > 8K, <= 64K FLASH, <= 64K RAM
avrxmega3 - XMEGA, > 8K, <= 64K FLASH, > 64K RAM
avrxmega4 - XMEGA, > 64K, <= 128K FLASH, <= 64K RAM
avrxmega5 - XMEGA, > 64K, <= 128K FLASH, > 64K RAM
avrxmega6 - XMEGA, > 128K, <= 256K FLASH, <= 64K RAM
avrxmega7 - XMEGA, > 128K, <= 256K FLASH, > 64K RAM

The salient point here is the difference between > and <=.  If you have 
a 128KB chip, it should fall under either avrxmega4 or 5, since it's 
less than or *equal* to 128K.

Here's a table I've compiled of all the current Xmega-A chips, their 
flash and RAM, along with the class I think they *should* be, and the 
classes that are currently assigned in the codebase I'm working from:

chip    flash   ram     extRAM? class   curclass
16a4    16      2               2
32a4    32      4               2       3
64a4    64      4               2
128a4   128     8               4
64a3    64      4               2       4
128a3   128     8               4       6
192a3   192     16              6
256a3   256     16              6       6
64a1    64      4       x       3       5
128a1   128     8       x       5       7
192a1   192     16      x       7
256a1   256     16      x       7
384a1   384     32      x       9

The 32a4 seems miscategorized entirely as a >64K RAM part, which is 
impossible without an EBI.  All the other chips suffer from "flash 
inflation", putting them in the next category up.

So, first thing to do is determine if the placement of the '=' is 
correct in the class table.  It makes perfect sense for it to be located 
where it is, since the class is used to determine whether ELPM and other 
17+bit address operations are necessary.

If the classes I've listed above are correct, both binutils and gcc need 
to be adjusted (easy), and avr-libc has to be fixed to provide crtx*.o 
files with different names appropriate to the different classes.  It 
might even make sense to just switch them to class names rather than 
choosing a particular chip (e.g. crtx32a4.o).

A further question is what is to be done with the 348a1.  I have no 
specific idea what the tweaks are that makes the higher flash sizes 
viable, so I've no idea if the <=256K really means that, or if the real 
limit for classes 6 and 7 is higher.

I'm going to proceed on my end as if my reading is correct, and try to 
reassign all the chips.  I can post the patch that results, though it's 
going to be derived from the Ubuntu 10.04 "bsdpatches/patch-xmega" so it 
might need integration work.