On Fri, Apr 11, 2014 at 5:55 PM, Peter Maydell <peter.mayd...@linaro.org> 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.
>
And sys-busses should be referencable and instantiable objects in
their own right. Can we create a sysbus with:
-device sysbus,name=blah
This should all work somehow with Edgars recent per-master-address
series. Masters then also need to specify their attachments in a data
driven way.
-device arm-cpu,master-bus=blah
>> 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).
>
This is probably blocked by consolidation of GPIOs and IRQs.
Unforuntately, Sysbus keeps it's own data structure and APIs for IRQs
quite separate from TYPE_DEVICEs GPIO API. I also think purely
numbered and unnamed GPIOs need to be phased-out as its a blocker on
quite a few features.
So anyways heres my proposal around IRQs/GPIOs. I have a series on
list that adds the capability to name GPIOs. We can use it to
consolidate sysbus::IRQ and device::GPIO by naming all sysbus IRQ
lists (lets just call them "irqs") and moving them into the regular
device->gpio structure. Existing sysbus_foo_irq APIs just back onto
this change so there is no tree-wide change needed. Then instead of
command line IRQ support we add command line GPIO support and the one
soln. just works for all forms of wires.
> 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.
I feel its something of the opposite here. The ultimate goal of an
entire machine on the command line brings to light all these issues
around generalization that are ultimately applicable to machine
extension. Whether not you actually use -M none { -device } is beside
the point. If you assume you have nothing, and aim to be able to do
anything you have less worries about future incapability.
But the real comprehensibility
> problem is from trying to do it with a single line of text
> with highly constrained syntax conventions.
>
And this email thread has quite nicely listed out those constraints. I
think we should get rid of them and continue evolving this idea until
it works.
Regards,
Peter
> thanks
> -- PMM
>
