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 _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
