[U-Boot-Users] New port Siemens SMN42 board

[Gary Jennejohn]

"Peter Pearse" writes:
> 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
> constraints, 
> IMHO more thought should be given to code intended to be merged into the
> main tree. 
> Anywhere that I find myself duplicating code unchanged, I try to stop and
> ask myself 
> how the code structure should be changed to prevent this. Otherwise the
> maintenance 
> effort can expand exponentially....
> 

Too true.

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

As the driver currently stands this isn't really feasible beacuse it uses
macros and routines which are specific to the LPC2292. It might be possible
to make a cpu/lpc2292 and put things like eth.c, spi.c, iap_entry.S and
mmc.c into it. I personally have no problem doing that, if you consider
it to be a good approach. In fact it would probably be better to have a
cpu/arm720t/lpc2292 a la cpu/920t with its multitude of sub-directories.
This would address points (a), (b), (c) and (e).

> 	b) Yet another spi.c - there was discussion about this
> 
>       e.g http://blog.gmane.org/gmane.comp.boot-loaders.u-boot
> 	Subject AT91 NAND om AT91SAM9260EK
> 	Subject Atmel DataFlash hooks.
> 
> 	Perhaps you could check what the conclusion was (or RFC your own
> ideas)
> 	and apply it to your patch, for others to follow.
> 

This is a very long thread and difficult to follow because the site does
not present the entire thread in an easy to follow manner. This means
searching the site for the subject and then trying to thread it onesself.

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

Unfortunately not. SMN42.h uses macros from the header file included as a
result of the ifdef. Without these macros soft_i2c.c does not work.

> 	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 was sort of unsure about this myself. I asked Wolfgang Denk whether I
shouldn't also use CONFIG_LPC2292 here, but he never responded to my
question. I'm not certain whether this will adversely impact other boards.
I'm willing to change the patch so that it reads (CONFIG_MMC && \
CONFIG_LPC2292), which would minimize its scope.

On a (ARM) related note - our customer reports that he cannot compile u-boot
because his tool-chain dumps its cookies on this union in include/ \
asm-arm/processor.h:

union debug_insn {
	u32	arm;
	u16	thumb;
};

His gcc defines arm as 1 which leads to big problems. He's unwilling to
move to a different tool-chain (what can one do?).

AFAICT the union is not used anywhere in the C-sources, either directly or
indirectly. In fact most of this header file seems to be excess baggage
taken directly from the linux-tree. Any problem with renaming the arm entry
to e.g. _arm?

---
Gary Jennejohn / garyjATjennejohnDOTorg gjATfreebsdDOTorg garyjATdenxDOTde
=====================================================================
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
=====================================================================