Dear Andreas Bießmann,
I plan to merge at91rm9200_usart and at91_usart for 2011.03. It will introduce clear naming scheme in at91 (USRT3 vs DBGU). Also I plan to remove the necessity to hardcode the base addresses in header of at91_usart.c. But to do this we need a clean basis to test the changes.
at91sam9* uses "atmel_usart", not "at91_usart". You should merge the "rm" usart into "atmel_usart" which currently works for AT91SAM9 and AVR32.
From there we got the "hangover" of the UART3 trick.
At the end we should have a clean "atmel_usart" that works for "RM", too. Maybe we can make it happen that the "init" function gets the address of the USART to use, similar to other (lan) interfaces, instead of odd defines and #ifdef cascades that hardcode addresses.
For testing purposes it would be "nice" if u-boot could have several uarts initialized and a simple "talk" command that patches serial data bidirectionally from console to any usart available (for example to simply check a connected GPS receiver or modem for function. "talk usart3 4800n81 0x1a" or alike ;)
Eg. at91rm9200ek and at91sam9260ek (i can get one from time to time) or your at91sam9263 based boards. I also think a lot of avr32 stuff could merge into the same drivers ... will have a look for that in future.
My board (top9000) is AT91SAM9XE based (thats a flavout of the 9260, notice that it uses at91sam9260.h in where "*XE*" changes a few defines.
Thats probably the only AT91SAM9 board that works with relocation. The port is in the "WIP" branch of "u-boot-atmel", if you want to have a look at it. I don't think the top9000 port is ready for mainline yet (there are still going to be small changes), but I could provide a patch if Wolfgang agrees to a premature version.
I do all of this in spare time at home therefore I go only little steps
So do I (not being paid for extra work beyond getting the top9000 working).
... But currently are all arm boards broken (relocation), therefore is now the time to introduce new interfaces. Do you think the same way?
Of course. Its just alot of work. And we should plan that to avoid double work ;)
regards
Reinhard