[U-Boot] [PATCH 1/2] LPC2468 support
remco.poelstra at duran-audio.com
Wed Mar 25 11:06:26 CET 2009
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)
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.
More information about the U-Boot