On Sun, Jul 06, 2008 at 08:44:52PM +0200, Wolfgang Denk wrote:
the attached patch, where the cpu/arm920t/start.S #includes a cpu/arm920t/s3c24x0/start.S file.
It's not really nice, but otherwise I assure you anyone touching the arm920t start.S file again will find itself in #ifdef/endif hell, once all my s3c24xx related patches would be merged...
I really dislike the code duplication.
I am sympathetic to the cause. For reference, I'm attaching the s3c24xx specific start.S file of my internal tree _before_ s3c24a0, s3c2460, s3c2412 and s3c2443 suppor is merged. So this is for three CPU's, not yet for seven. And it has already way too many ifdefs for my taste. Also, the number of lines of code that I duplicated is probably something like 25-40 assembly instructions. We're not talking about massive amounts here.
I think the problem is a quite generic one. The same one exists for other ARM-core based SoCs, since multiple vendors use the same core, and every vendor (samsung, ti, ...) may have an entire product line each with their specific low-level initialization bits.
I'm having the same problem looking at the arm1136 based s3c6400 code... It is quite different but still somehow related to the cpu/arm1136/start.S code.
The only alternative to either having #ifdef hell or code duplication is the extensive use of macros. Either have one common start.S and put macro placeholders throughout the code, have the actual bits implemented per-cpu. Or have one start.S for each cpu and macros for the shared generic stuff.
Oh, and did I mention that samsung also shares code between s3c24xx and s3c64xx? This means that e.g. the boot-from-nand part of the s3c2443 and the s3c6400 might be identical, so we'd end up having code in cpu/arm920t/s3c24xx/ including/linking to code in cpu/arm1136/s3c64xx...
I'll probably end up with something like cpu/arm920t/s3c24xx 2400, 2410, 2412, 24a0, 2460, 2440, 2442, 2443 cpu/s3c/ generic stuff that is shared cpu/arm1136/s3c64xx 6400, later 6410