[U-Boot-Users] New port Siemens SMN42 board
peter.pearse at arm.com
Wed Mar 21 15:39:43 CET 2007
> -----Original Message-----
> From: u-boot-users-bounces at lists.sourceforge.net
> [mailto:u-boot-users-bounces at lists.sourceforge.net] On Behalf
> Of Gary Jennejohn
> Sent: 19 March 2007 14:35
> To: u-boot-users at lists.sourceforge.net
> Subject: [U-Boot-Users] New port Siemens SMN42 board
> Hello List,
> Wolfgang Denk asked me to send this patch to the list so that
> "the ARM maintainer can take care of it".
> Attached SMN42_diff.gz against u-boot as checked out of git
> this morning.
Thanks for your patch for SMN42.
Each new board added to the U-Boot tree provides a chance to improve the
existing code. Whilst just cutting & pasting the code from an existing board
is sufficient for local use, and may be necessary because of time
IMHO more thought should be given to code intended to be merged into the
Anywhere that I find myself duplicating code unchanged, I try to stop and
how the code structure should be changed to prevent this. Otherwise the
effort can expand exponentially....
In the case of the SMN42 patch:-
a) board/lpc2292sodimm/eth.c has been duplicated
IMHO this code should be submitted as drivers/eth_<hardware id>.c
with its own CONFIG_ for use in include/configs headers
Then I can submit a patch to lpc2292sodimm to use it.
b) Yet another spi.c - there was discussion about this
Subject AT91 NAND om AT91SAM9260EK
Subject Atmel DataFlash hooks.
Perhaps you could check what the conclusion was (or RFC your own
and apply it to your patch, for others to follow.
c) I believe MMC was (or should be) included in the SPI discussion
d) Is it possible to avoid the ifdef in common/soft_i2c.c?
Perhaps this indicates another area that could be redesigned.
e) Ditto the duplicated iap_entry.S
f) fs/fat/fat.c - Will your use of CONFIG_MMC affect other boards
which use it?
I look forward to receiving your next version of the SMN42 patch
More information about the U-Boot