[U-Boot] U-Boot support for board(s) meesc, otc570

[Reinhard Meyer]

Dear Daniel Gorsulowski,
> Hello Reinhard,
>
> Reinhard Meyer wrote:
>> Dear Daniel Gorsulowski,
>>> Today I found out by GPIO debugging, that U-Boot seems to boot but prints
>>> its startup messages to wrong USART with proper baudrate. I'll try to
>>> find out, why there is no output on DBGU.
>>
>> Note that the USART to use is defined differently than before:
>>
>> /* serial console */
>> #define CONFIG_ATMEL_USART
>> #define CONFIG_USART_BASE		ATMEL_BASE_DBGU
>> #define	CONFIG_USART_ID			ATMEL_ID_SYS
>> #define CONFIG_BAUDRATE			115200
>> #define CONFIG_SYS_BAUDRATE_TABLE	{115200 , 19200, 38400, 57600, 9600 }
>
> I did so, see http://lists.denx.de/pipermail/u-boot/2011-January/085863.html
>
> But I'm a little bit confused. In the past, USART_ID was defined by '3',
> if DBGU was used. Now, USART_ID is replaced by CONFIG_USART_ID, which is
> defined by ATMEL_ID_SYS, which is defined by '1'.
> However, this discrepancy does not matter, because CONFIG_USART_ID is
> only used once in drivers/serial/atmel_usart.c, line 57:
> usart_hz = get_usart_clk_rate(USART_ID);
> And get_usart_clk_rate(); ignores its parameter. See
> arch/arm/include/asm/arch-at91/clk.h

That is correct for AT91. However AVR32 has separate clock dividers for each USART.
The atmel_usart driver is the same for both architectures. For that reason the ID
is carried along but nowhere used in AT91 clock code. But who knows, maybe there will be
an AT91 variant in the future with different clocks for each peripheral...

What matters is that the driver uses the value of CONFIG_USART_BASE to access the
registers. This value you have set (correctly) to ATMEL_BASE_DBGU. So by all
reasoning output should not come out any other USART...

> static inline unsigned long get_usart_clk_rate(unsigned int dev_id)
> {
>          return get_mck_clk_rate();
> }
> (all other functions in clk.h act similar. I think, a rework would be
> advisable?)

No, in AVR32 those functions are different for each peripheral.

>
> Back to the problem...
> In my opinion, my USART configuration is correct. I still have no idea,
> why there is no output on DBGU.

I am at a loss there, too.

Which USART is the output coming from instead? Is it really console output
or maybe some other, independent pulses?

Can you verify that the value for ATMEL_BASE_DBGU in at91sam9263.h is correct?

Are you using the actual driver source? It should have lines like
         atmel_usart3_t *usart = (atmel_usart3_t*)CONFIG_USART_BASE;
at the begin of each function.

Best Regards,
Reinhard