On 12/09/2010 03:50 AM, Christian Glindkamp wrote:
I don't like the idea of having all of the carrier boards in the same
file as the SoM. Carrier boards may be developed by different people and
if there are a large number of them then the board files will start to
get quite big and confusing.
I think we need a standardised architecture for managing SoMs. A simple,
crude way would be to export the init functions from the SoM, i.e:
stam9g20_map_io and stamp9g20_board_init. Have the core SoM
functionality in those functions, for example in board-stamp9g20.c:
void __init stamp9g20_map_io(void)
{
/* Initialize processor: 18.432 MHz crystal */
at91sam9260_initialize(18432000);
/* DGBU on ttyS0. (Rx & Tx only) */
at91_register_uart(0, 0, 0);
/* USART0 on ttyS1. (Rx, Tx, CTS, RTS, DTR, DSR, DCD, RI) */
at91_register_uart(AT91SAM9260_ID_US0, 1, ATMEL_UART_CTS
| ATMEL_UART_RTS | ATMEL_UART_DTR
| ATMEL_UART_DSR | ATMEL_UART_DCD
| ATMEL_UART_RI);
/* set serial console to ttyS0 (ie, DBGU) */
at91_set_serial_console(0);
}
EXPORT_SYMBOL(stamp9g20_map_io);
and then have the carrier specific initialisation in board-portuxg20.c:
static void __init portuxg20_map_io(void)
{
stamp9g20_map_io();
/* USART1 on ttyS2. (Rx, Tx, CTS, RTS) */
at91_register_uart(AT91SAM9260_ID_US1, 2,
ATMEL_UART_CTS | ATMEL_UART_RTS);
/* USART2 on ttyS3. (Rx, Tx, CTS, RTS) */
at91_register_uart(AT91SAM9260_ID_US2, 3,
ATMEL_UART_CTS | ATMEL_UART_RTS);
/* USART4 on ttyS5. (Rx, Tx only) */
at91_register_uart(AT91SAM9260_ID_US4, 5, 0);
/* USART5 on ttyS6. (Rx, Tx only) */
at91_register_uart(AT91SAM9260_ID_US5, 6, 0);
}
This reduces code reuse, and also means that if the carrier board has
some esoteric setup it can do its own initialisation rather than calling
stamp9g20_map_io. The downsides to this approach are the necessity of
having the exported functions and the relationship between the SoM and
the carrier board is not completely clear.
Maybe having additional macros similar to MACHINE_START for SoMs so that
we can have a machine_desc type struct for the SoM and can do things
like som->map_io()?
Agreed.
Okay, I think we are both for the same approach :-).
~Ryan
--
Bluewater Systems Ltd - ARM Technology Solution Centre
Ryan Mallon 5 Amuri Park, 404 Barbadoes St
ryan@bluewatersys.com PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com New Zealand
Phone: +64 3 3779127 Freecall: Australia 1800 148 751
Fax: +64 3 3779135 USA 1800 261 2934
--
