[U-Boot] [PATCH 1/2] LPC2468 support

[Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>]

On 11:06 Wed 25 Mar     , Remco Poelstra wrote:
> Wolfgang Denk schreef:
> > Dear Remco Poelstra,
> > 
> >>> Is there no way we can do without such a #ifdef here?
> >> The problem is that start.S needs hardware.h, but the code in immap.h 
> >> should not be included in start.S, so I can not merge hardware.h and immap.h
> > 
> > Why not? I'm not aware of such a restriction?
> 
> I'm not an expert in assembly, but at first I had immap.h included in 
> start.S and it complained about invalid instructions, so if I combine 
> hardware.h and immap.h, then there must be some way of making sure that 
> the assembler ignores the C code in immap.h. Do you know of any such thing?
> 
immap.h?
>   > I would like to avoid the ever growing list of
> > 
> > 	#if defined(this) || defined(that) || defined(...) || ...
> > 
> > Maybe we can have a common #define that covers the common case?
> 
> I could add something like
> #if defined(CONFIG_LPC2922) || defined(CONFIG_LPC2468)
> #define (CONFIG_LPC2000)
> #endif
> 
> in a general place and then use CONFIG_LPC2000 at the common places.
> 
> The problem I then have is: What would be the best place to put such 
> define? Preferably it is automatically included also for the LPC2292 
> code. If that's not possible, it can be defined in the board config, but 
> I think that leads to confusion.
> What's your opinion?
Maybe in include/asm-arm/config.h
> 
> >>> Ummm... What exactly is this file needed for?
> >> I don't need it, but start.S wants to include it. See my comment about 
> >> the #ifdef's. Other architectures left it empty too, so it seemed the 
> >> best option to me.
> > 
> > Hm... that doesn't really make sense to me. Also, the error checking
> > in this file makes little sense to me.
> 
> I can remove the file, but than I need to put an #ifdef construct in 
> start.S to only exclude it in the lpc2468 case. The file is used by the 
> other ARM ports. I can also simply empty it, but in this way it is more 
> similar to the other ports. What would you like?
no please do not I'll prefer to separate arch file

Best Regards;
J.