[U-Boot] Struct SoC access

[Reinhard Meyer <u-boot@emk-elektronik.de>]

Dear Wolfgang Denk,
> I think we have a misunderstaning ehre - I thought the entries like
> "xyz" were indeed "u32" types - buut now I get the impression that
> what you have in mind is that they are actually structs describing
> hardware blocks.

No, thats just spacemakers, otherwise one would have do declare all
structs for all hardware blocks in that file (or include a bunch of files).

> struct immap is what corresponds to your struct soc above.

Yes, with at least all currently used blocks declared as structs,
the currently unused ones made up of the proper amount of u32s
Since different AT91 SoC might have some blocks missing or at other
addresses in another amount etc.,
but with the same layout of each individual block, it would make sense
to keep the block structure definitions in separate files like
at91_dbu.h, at91_rstc.h, etc.
They would have to be included in the corresponding at91sam9260.h,
at91sam9261.h, etc. where the individual soc layouts would be defined.

>> Would the toolchain "gulp" when one defines the whole 4 GB that way?
> 
> Why not?

Since the AT91s have no base address registers at all, the memory layout
is completely fixed. Even chip selects have a fixed address and fixed
size of 256MB each. Therefore it _might_ make sense to completely
define the 4GB in the soc struct.
Then assign struct soc *soc = (struct soc *)0;

Did you read Mike's comment of hardware dependent direct usage of
struct members to access hardware? I thought that was generally
discouraged for several reasons (cache and access sequencing)?

Whats a IOCCC?

Reinhard