The whole xparameters.h file is really annoying. It makes the IPIF code impossible to use on more than one board type without a recompile. That may be OK for U-boot but it is horrible in the Linux kernel.
Unfortunately, we have not yet found a good way to store the hardware information (let's call it CROM) as part of the bitstream in a way that it becomes easily available to the software. The hardware system is very flexible, i.e. the location where such information is stored may be different for various boards (bitstreams).
One solution might be to pass the location of the CROM as part of the boot parameters to the Linux kernel or even go one step further and pass the whole HW configuration as a boot parameter to the Linux kernel. A similar technique might be doable for u-boot.
Another solution might be that we define were CROM is located in the address space. It could be in the DCR address space to not fragment the PLB address space. However, since even the DCR address space can be defined by the user it might be difficult to reserve a location for CROM.
A problem is the association with the processor in a multi-processor system. Let's assume you have a chip with two PPCs on the same PLB and one uses some peripherals were the other uses the other peripherals. xparameters.h resolves the association at compile time whereas CROM would need to contain information about which peripherals are used by which processor.
I'm interested in discussing suggestions on how to solve this problem so that SW application do not need to be recompiled and can gather HW information from CROM (or maybe something else) at run time.
- Peter