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