On Mon, Apr 14, 2014 at 10:57 AM, Alistair Francis
<alistair.fran...@xilinx.com> wrote:
> On Fri, Apr 11, 2014 at 7:13 PM, Peter Crosthwaite
> <peter.crosthwa...@xilinx.com> wrote:
>> 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?
>>>
> At the moment it doesn't allow generic timer outputs or any complex
> connections
> like that, that might be possible to implement (see below). Sorry, I
> should have specified that
> the a9mpcore_priv needs to be added by a separate -device argument
>
>>>> 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.
>>>
> See below
>>
>> 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).
>>>
> See below
>>
>> 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.
>>
> I think this is a good idea.
>
>>> 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.
What about extending QMP to allow users to add sysbus devices via scripting?
Using a similar approach to this patch except:
- Removing the CPU and memory components (at least for now)
- Removing some of the assumptions that are being made due to the
simplicity of command line arguments
QMP already allows objects to be added, I don't think it would be too
difficult to extend this
to add devices as well.
>
> Overall I agree this implementation makes a lot of assumptions to simplify
> the complexity of machine model generation. I still think it should be
> possible
> for a user to at least add sysbus devices to QEMU via the command line. The
> CPU, memory and interrupt controller could be a bit much and too complex to
> attach via command line, but users should be able to attach most other
> QOM devices.
>
> Even just allowing relatively simple devices to be added via the
> command line will eventually
> make it easier to implement a scripting language to generate entire machines.
>
> The command line arguments could be extended to allow 'masters', or
> something similar
> which specify what to connect to. For example device's X interrupt
> lines or different address
> spaces.
>
>>
>> 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.
>>>
> One last point, although it is highly constrained, it still allows
> complete generation
> of relatively simple machines. Something which I think will benefit
> end users, and if they
> want to do anything more complex they can write C code (or a scripting
> language)
> and implement it that way.
>
> Thanks,
> Alistair
>>
>> 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
>>>
>>
