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

[Remco Poelstra <remco.poelstra@duran-audio.com>]

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?

  > 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?

>>> 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?

> I'm not an expert for this processor, but I wonder it there might be
> some form of sync instruction (or memory barrier or similar) needed?

No, none at all. There is only a single linear memory region for the 
processor and a write to a location has immediate effect, whether it be 
a register or just RAM.

I suppose leaving parts of the 2468 and 2292 code separated is OK for 
the time being (considering offset lists and data structures), in the 
hope someone will upgrade the 2292 code?

I'm willing to look into the PUT32() vs. writel() problem in about half 
a year or so. That will at least cleanup part of the code.

Kind regards,

Remco Poelstra