On Mon, Jul 07, 2003 at 04:20:41PM +0200, Wolfgang Denk wrote:
In message 20030707002607.GA4106@buici.com you wrote:
I'm porting u-boot to the Sharp KEV7A400 development board. The CPU has an ARM9 core with some Sharp and some ARM cells. The existing ARM920T cpu code has quite a bit of Samsung specific code in it. So, the question is this: how do we best handle development like this?
If this really becomes a problem I think we might create processor specific sub-directories below the CPU/* directory, i.e. something like
cpu/arm920t/s3c24x0/ cpu/arm920t/other_1/ cpu/arm920t/other_2/ ...
What do you think?
OK. Does this mean that the configuration line in Makefile says:
... arm arm920t/<subcpu> <boardname>
- There are some board-specific driver choices, e.g. serial driver, that sometimes appear in the CPU directory. Perhaps these choices are best made in the board directory instead.
There should be no _board_-specific drivers in CPU directories. We had this discussion before, and all such cases that I'm aware of are really _processor_-specific drivers.
Perhaps I am misspeaking. These serial drivers are chip specific. ARM920T, however, is *not* a chip. The serial driver in the ARM920T directory is specific to the Samsung implementation.
Please name the files if you disagree.
- Drivers, such as serial, could be made to export a function table. This would allow driver selection by choosing which file to compile and link.
Isn't this how it works right now?
The serial driver for the samsung chip exports serial_getc(void) and like routines. It could export more generic routines using a jump table. I think this is the same thing that happened with the x86 port.
Cheers.