[U-Boot-Users] Manufacturer specific code in a bothersome place
Marc Singer
elf at buici.com
Mon Jul 7 17:29:07 CEST 2003
On Mon, Jul 07, 2003 at 04:20:41PM +0200, Wolfgang Denk wrote:
> In message <20030707002607.GA4106 at 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>
>
> > 2) 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.
>
> > 3) 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.
More information about the U-Boot
mailing list