Dear Wolfgang Denk,
Then just write in the comment part of the second patch that the other one has to be applied first...
Thats fine with me.
Anyway, is the method of (for example!)
#define DBU_ADDR 0xsomething (in a SoC header file)
dbu_t *dbu = (dbu_t *)DBU_ADDR; (in a function)
OK?
Yes.
Thats the way I do it currently
Or do we need to further encapsulate that in a function like
No.
I have seen that somewhere in u-boot.
I was even thinking of something like
struct soc { u32 xyz[0x80]; /* XYZ unit */ u32 dbu[0x80]; /* Debug Unit */ u32 rstc[0x80]; /* Reset Controller */ and so on.
This is what PPC used to do; I like that - but ARM people always explained to me that it makes no sense because address space on ARM SoC is only sparely populated.
Even if, that's no reason, on can write "u32 spi0[0x1000]", on AT91 the spacing of peripherals is 0x4000 bytes, in fact it repeats times in its window. The system stuff is like one peripheral with its components spaced by 0x200 bytes (hence the 0x80 above).
I think this looks nice, but as mentioned before - I'm not an ARM expert. They tend to do it differently.
I can be done for AT91, but I'm not Don Quichote ;)
Would the toolchain "gulp" when one defines the whole 4 GB that way?
Best Regards, Reinhard