On 15.04.14 04:21, Peter Crosthwaite wrote:
Add a sysbus device consisting of a single ram. This allows for instantiation of RAM just like any other device. There are a number of good reasons to want to do this this:1: Consistency. RAM is not that special where board level files should have to instantiate it with a completely different API. This reduces complexity of board level development by hiding the memory API completely and handling everything via the sysbus API. 2: Device tree completeness. Ram Now shows up in info-qtree and friends. E.g. Info qtree gives meaningful information under the root system bus: dev: sysbus-memory, id "zynq.ocm_ram" size = 262144 (0x40000) read-only = false irq 0 mmio 00000000fffc0000/0000000000040000 dev: sysbus-memory, id "zynq.ext_ram" size = 134217728 (0x8000000) read-only = false irq 0 mmio 0000000000000000/0000000008000000 3: Remove dependence of global state. Board files don't have to explicity request the global singleton (and much unloved) address_space_memory() and go hacking on it. address_space_memory() is still ultimately used, but the ugliness is hidden in one place - the sysbus core (we can fix that another day). 4: Data driven machine creation. There is list discussion on being able to create or append-to sysbus machines in a data-driven way (whether thats from command-line, monitor or scripts or whatever). This patch removes the memory special case from that problem and allows RAM instantiation to come via whatever solutions we come up with sysbus device instantiation. Signed-off-by: Peter Crosthwaite <[email protected]>
Could you please show that this approach works for more complicated machines, like x86's pc machine and its PCI holes?
Alex
