[U-Boot] [PATCH 1/3] at91rm9200ek: convert to at91

["Andreas Bießmann" <andreas.devel@googlemail.com>]

Dear Reinhard Meyer,

Am 18.10.2010 10:40, schrieb Reinhard Meyer:
> Dear Andreas Bie?mann,

>>>> @@ -113,10 +112,6 @@
>>>> #define CONFIG_DBGU
>>>> #undef CONFIG_USART0
>>>> #undef CONFIG_USART1
>>> Don't #undef what has never been defined.
>>
>> You know this is historic. This are the three possible interfaces for USART on this board. At least at91rm9200 known about DBGU ;) This will be addressed when merging at91rm9200/at91 and maybe avr32 usart implementation.
> 
> I know, its like that in almost all Atmel based boards. Even worse is the AT91 method,
> since some AT91 can have 6 UARTs. However unlikely that they are going to be used as console,
> this is awfully bad = <at91sam9260_ek.h>:
> 
> #define CONFIG_ATMEL_USART	1
> #undef CONFIG_USART0
> #undef CONFIG_USART1
> #undef CONFIG_USART2
> #define CONFIG_USART3		1	/* USART 3 is DBGU */
> Notice the last define !!!

I know that ...

> I once tried to cleanup that a bit, but it really would affect files all across AT91.

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.
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.

I do all of this in spare time at home therefore I go only little steps
... But currently are all arm boards broken (relocation), therefore is
now the time to introduce new interfaces. Do you think the same way?

regards

Andreas Bie?mann