[U-Boot-Users] Start of new ARM920T target

[Marc Singer]

I respect your objections.  This was not intended as a *real* patch.
I wanted you to look at the Makefile portion to see if you approved.

As for Perl, I think I can write the script using sh.  Perl was just
too darn quick and easy.

BTW, the RTC_DEBUG macro isn't mine.  I'll see where it came from.

On Fri, Jul 18, 2003 at 01:34:31AM +0200, Wolfgang Denk wrote:
> Now for the technical discussion: I don't  see  much  advantage  when
> using your mkconfigx script. IMHO it has several problems:
> * It will incorrectly include files  that  have  been  commented  out
>   using C comments, "#if 0" or similar clauses.

That's an interesting objection.

> * It is based on the assumption that only  CONFIG_*  definitions  are
>   relevant; it would be nice if this was the case, but actually there
>   is  at  least  a  couple  of  CFG_*  variables, and some boards use
>   (locally) even completely different names

Though this is true, the point is to enable conditional compilation
and *not* to allow every configuration option to control Makefiles.

> You  modify  include/asm-arm/processor.h   in   an   unexpacted   way
> (inserting "#undef arm"). Please don't add such code to system header
> files.  Ther  eis  obviously  a  problem  somewhere in your toolchain
> and/or on tyour system. Please fix the cause, not the symptoms.

This is to work around a bug.  Someone was #define'ing it and breaking
a struture.  I think that the true culprit is the code that #define's
a symbol that isn't all upper case.

> May I please ask you to clean up the patch as far as the KEV7A400 dev
> board is concerned, and resubmit it. Please omit the mkconfigx  stuff
> (and other "goodies" like .gdbinit).

Of course.  There's lots of work to do before it is useful.

 -*-

Let me elaborate on mkconfigx.

First, I wrote this script to handle the new feature in order to make
it easy to enable or disable it.  It would be very easy to make it
execute only for boards or CPUs that use this configuration feature.
Or, when a particular tool was available.

I look only for CONFIG_ constants on purpose.  We can have a simple
rule: only CONFIG_ constants that define the value '1' will be parsed
by mkconfigx.

I'm not sure I'd want to solve the #if 0 problem.  Yes, someone could
get something that they don't want.  On the other handle, it is
reasonable to change the definition to '0' from '1' when a feature
isn't desired.  

The strength of this kind of configuration comes from the fact that it
allows the Makefiles to be the arbitrator of what code is included and
what is excluded.  I've been using it a lot while tweaking the ARM920
builds to accomodate the architectural differences between the Samsung
parts and the Sharp parts.  There are far too many #ifdefs in the
existing ARM920 code making it difficult to figure out what belongs
where.  This configuration method lets us move the decisions about
what belongs where to the Makefile.

So, instead of putting at the top of a source file:

  #if defined (CPUA) | defined (CPUB) | ...
  /* code */
  #endif

We put in the makefile

  src-$(CONFIG_CPUA)		+=start_type_1.S timer_type1.c ...
  src-$(CONFIG_CPUB)		+=start_type_2.S timer_type1.c ...
  src-$(CONFIG_CPUC)		+=start_type_1.S timer_type2.c ...

and move the code to separate files.  There are many places where code
shares a file for no good reason.  I'm looking to put truly ARM920
code in ARM920 triggered sources, and so on.

Cheers.