In message 20030707184116.GA26444@buici.com you wrote:
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.
Like allthe other source files are woking at the moment.
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.
It's not exactly beautiful, but it's simple, and it works.
What I'd like to see is something much more flexible. I'd like to let
You pay a price for such flexibility.
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.
There have been several discussions about things like this, or better config tools, etc.
I need to see a working example before I can comment on such a suggestion.
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
Again, flexibility does not come for free. If you try t make the flash driver compile-time configurable, it may easily end up being unreadable. If you configure at run-time you will pay with memory footprint.
We all know that automatic detection can be implemented, and where to find existing code which could be reused. This is theory. In practice, we're better off by just cloning and adapting an existing, highly specialized driver. YMMV.
Again: I'll be happy to accept a better solution, but it must meet two requirements:
* It shall work on all existing boards. * It shall not have a bigger memory footprint.
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.
No tricks are needed. There are boards with two kinds of flash. This works fine as is.
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
I see, another round of config tool discussion. But this time buttom up :-)
This way, we only compile and link the files necessary for each configuration option. It means that we can eliminate redundant code
...
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
Feel free to submit a tested patch. I need to see working code to have something I can criticize ;-)
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
No, it doesn't work that way. U-Boot is always linked to the pre- relocation address in flash. The post-relocation address is not known at compile time, as it may depend on things like RAM size.
Best regards,
Wolfgang Denk