On Sun, Jul 06, 2008 at 08:44:52PM +0200, Wolfgang Denk wrote:
In message 20080706164700.GE20299@prithivi.gnumonks.org you wrote:
I meanwhile realized that the entire makefile system doesn't really cope with the fact. So what I'm left with is something along the lines of
Please explain what's the problem...
the problem is tha the main makefile always wants to build cpu/arm920t/start.o, and I don't see an easy way how it could be modified to build cpu/arm920t/s3c24x0/start.o instead. At least until now I don't see an infrastructure for this.
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.
same here. but I'd rather duplicate some 50-100 lines than have 300 lines of completely unreadable #ifdef hell.
- armboot - Startup Code for S3C24xx CPU-cores
You're posting this on the wrong mailing list, then. Did you mean armboot-users@lists.sourceforge.net ? ;-)
please look into your own u-boot source, the entire arm start.S file looks like this, and I just copy+pasted that 'standard'
--- u-boot.orig/include/configs/VCMA9.h +++ u-boot/include/configs/VCMA9.h @@ -35,6 +35,7 @@ */ #define CONFIG_ARM920T 1 /* This is an ARM920T Core */ #define CONFIG_S3C2410 1 /* in a SAMSUNG S3C2410 SoC */ +#define CONFIG_S3C24xx 1 /* in a SAMSUNG S3C24xx family */
Is this really needed? Should not CONFIG_S3C2410 automatically include setting CONFIG_S3C24xx ?
this would have been my preferred choice. But only config.h is included by all the various header files. and config.h itself only includes board/foobar/config.h, i.e. there is no generic header file which gets preprocessed after the board-level config is included and which is still included from config.h. Should I invent one? I'm usually careful with doing things differently than it is already established in the u-boot project. And I've seen PPC examples just doing it like I did it now (defining the family directly in the board-level config). I agree, it's ugly and error prone...