No subject

At the end we should have a clean "atmel_usart" that works for "RM", too.
Maybe we can make it happen that the "init" function gets the address of
the USART to use, similar to other (lan) interfaces, instead of odd defines
and #ifdef cascades that hardcode addresses.

For testing purposes it would be "nice" if u-boot could have several uarts
initialized and a simple "talk" command that patches serial data bidirectionally
from console to any usart available (for example to simply check a connected
GPS receiver or modem for function. "talk usart3 4800n81 0x1a" or alike ;)

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

My board (top9000) is AT91SAM9XE based (thats a flavout of the 9260, notice
that it uses at91sam9260.h in where "*XE*" changes a few defines.

Thats probably the only AT91SAM9 board that works with relocation. The port is in the
"WIP" branch of "u-boot-atmel", if you want to have a look at it. I don't think
the top9000 port is ready for mainline yet (there are still going to be small changes),
but I could provide a patch if Wolfgang agrees to a premature version.

> I do all of this in spare time at home therefore I go only little steps

So do I (not being paid for extra work beyond getting the top9000 working).

> ... But currently are all arm boards broken (relocation), therefore is
> now the time to introduce new interfaces. Do you think the same way?

Of course. Its just alot of work. And we should plan that to avoid double work ;)

regards

Reinhard