From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marc Singer Date: Mon, 7 Jul 2003 11:41:16 -0700 Subject: [U-Boot-Users] Manufacturer specific code in a bothersome place In-Reply-To: <20030707163337.00E75C6D82@atlas.denx.de> References: <20030707152907.GA2816@buici.com> <20030707163337.00E75C6D82@atlas.denx.de> Message-ID: <20030707184116.GA26444@buici.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Mon, Jul 07, 2003 at 06:33:32PM +0200, Wolfgang Denk wrote: > In message <20030707152907.GA2816@buici.com> you wrote: > > > > > 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/ > > Probably not. Maybe we can solve this by a #define in the board > config file. Now, I'm confused as to how this would work. In the CPU directory, there is a Makefile and several source files. The Makefile staticly builds the sources and links a library. This library includes the primary entry point for u-boot. If we want to have a sub-cpu directory, either we implement something in the Makefile that selects source files or we use a goofy #ifdef over the whole contents of a source file--tough for me not to editorialize. What I'd like to see is something much more flexible. I'd like to let the board directory & Makefile control the whole build. In it, we select the libraries and object file to link in order to get the services we need. This would allow, for example, a serial_lh7a400.c, serial_ns16550.c, and so on to coexist where only one is compiled and linked. In another example, it seems that we don't share as much of the flash code as we could. Since most flash programming is always the same, we could have a driver that is passed descriptive parameters for the flash device and then handles all of the details. And, here is where the jump table comes in: my board has two kinds of flash. With jump tables, I can use both drivers without using function name tricks. > > 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. > > Which advantage do we get from an additional level of indirection > when the functions are known (getc, tstc, putc, puts) anyway? IMHO it > just adds additional complexity (needs manual relocation) and wastes > memory. It seems to me that there is already some of this going on. In drivers/serial.c, there are calls to the NS16650_ routines. Perhaps there's some middle ground that makes sense. Chiefly, I'm interested in making this all simpler. I think that the whole-file #ifdefs are not the best method for selecting code. The Linux kernel configuration stuff works well in selecting object files for linking. obj-$(CONFIG_SERIAL_16550) += serial_16550.o obj-$(CONFIG_SERIAL_LH7A400) += serial_lh7a400.o This way, we only compile and link the files necessary for each configuration option. It means that we can eliminate redundant code (e.g. serial.c as well as serial-ns16550.c) as well as putting more code into central locations. That's for the serial driver. There are other drivers, however, for which we may need more than one. For example, I have two kinds of flash on my board. I'd like to be able to choose from a common set of flash drivers. In this case, jump tables make it possible to link more than one driver of the same type, letting the board specific code handle board-specific setup. BTW, I don't think that jump-table relocation should be a problem as long as the file is linked to the target (post-relocation) load address. Still, I agree that for the serial driver there is no reason for the dynamic dispatch afforded by a jump table. Cheers.