From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?B?QW5kcmVhcyBCaWXDn21hbm4=?= Date: Mon, 18 Oct 2010 11:27:53 +0200 Subject: [U-Boot] [PATCH 1/3] at91rm9200ek: convert to at91 In-Reply-To: <4CBC07E8.7020901@emk-elektronik.de> References: <1287189674-95445-1-git-send-email-andreas.devel@googlemail.com> <1287189674-95445-2-git-send-email-andreas.devel@googlemail.com> <4CBB3B3B.8040408@emk-elektronik.de> <5704DFFE-9C3D-4648-A739-BBBFCE2685A3@googlemail.com> <4CBC07E8.7020901@emk-elektronik.de> Message-ID: <4CBC1319.4030604@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 = : > > #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