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 <address@hidden>