[U-Boot-Users] [PATCH] for Xilinx's ml300 board

[Peter Ryser <Peter.Ryser@xilinx.com>]

>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