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. thanks -- PMM
