On 11.04.14 09:55, Peter Maydell wrote:
On 11 April 2014 07:34, Alistair Francis <alistair.fran...@xilinx.com> wrote:
This patch allows sysbus devices to be attached via
command line arguments.
This can be used to build an entire machine from the command
line or to just add devices that aren't in the machine_init
code.
A peripheral can be added with the following syntax:
-device cadence_uart,addr=0xE0000000,irq=27
A CPU can be added with either of the following:
-device cpu,model=cortex-a9,type=arm-cpu,reset-cbar=0xF8F00000,midr=0x413
FC090
-sysbusdev device=cpu,name=microblaze-cp
I don't see how this can possibly be sufficient information
to wire up the CPU properly. How would you specify
where the generic timer outputs go on an A15?
How are you going to handle the private peripheral
mappings? Is the user supposed to provide another
argument for the a9mpcore_priv device?
RAM or ROM can be attached with this command:
-device memory,name=zynq.ext_ram,addr=0x00000000,size=0x8000000
How would you use this if you needed to manage
multiple separate address spaces? I'm hoping we can
get rid of address_space_memory at some point
in favour of actually properly modelling when different
CPUs or DMA masters have different views of the world,
so I don't want us to tie ourselves into an incorrect
model by command line back-compat problems.
Multiple IRQ lines can be used as well as multiple properties:
-device pl330,addr=0xF8003000,irq=13,irq=14,irq=15,irq=16,irq=17,\
irq=40,irq=41,irq=42,irq=43,num_chnls=8,num_periph_req=4,num_events=16
This doesn't seem to actually specify anywhere how those
IRQ numbers are supposed to be interpreted. You need
to somehow say "connect this IRQ output line up to
device X's GPIO input line Y" (where X will usually but not
necessarily be an interrupt controller).
Again addr= is assuming a single system wide address
space.
I also think that "allow machine specification by the
command line" is a terrible goal -- certainly we should allow
users the flexibility to put machines together from individual
devices, but we should do that with a reasonably usable
configuration or scripting language (and then we can use
that internally for our own board models). If you try to
specify things using command line argument syntax as
your primary approach then the result is going to end
up with hard-coded shortcuts (like the address space and
which-interrupt-controller problems I mention above) that
you've ended up with to try to make the command line
vaguely comprehensible. But the real comprehensibility
problem is from trying to do it with a single line of text
with highly constrained syntax conventions.
I agree. And both things should be orthogonal goals. I think it makes a
lot of sense to work towards converting machine files into say python
scripts.
But even then users will still want to define additional devices using
-device on the command line on top of that base machine file. So we need
a solution to link up devices with "facilities provided by the boad" as
well - to a certain extent.
I'm not sure if it's worth it to worry about the case where a -device
provides interfaces that you would need to hook up to from -device
again. We already have working interfaces for that really.
Alex
