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

Andreas Bießmann andreas.devel at googlemail.com
Mon Oct 18 11:27:53 CEST 2010


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


More information about the U-Boot mailing list