onversion and steps towards fully data driven machines which
should be the ultimate objective anyway.
As Peter C says elsewhere in this thread, through its link syntax
foo=<&ref> you can describe any sort of topology you like in a device
tree.
Regards,
John
--
John Williams, PhD, B. Eng, B. IT
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663 f: +61-7-30090663
addresses but can be overriden in the same
way:
--kernel zImage@0x2000 --initrd fs.img@0x4000
and so on
The '@' symbol will need to be escaped by it's a pretty natural syntax.
John
--
John Williams, PhD, B. Eng, B. IT
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663 f: +61-7-30090663
On Mon, Jan 30, 2012 at 10:28 AM, John Williams
wrote:
> On Sun, Jan 29, 2012 at 4:51 PM, Peter Crosthwaite
> wrote:
>> Hi All,
>>
>> So on the topic of these command line arguments for initrd, dtb and friends,
>> another related issue we have encountered (and hav
On Mon, Jan 30, 2012 at 12:11 PM, Anthony Liguori wrote:
> On 01/29/2012 06:28 PM, John Williams wrote:
>>
>> On Sun, Jan 29, 2012 at 4:51 PM, Peter Crosthwaite
>> wrote:
>>>
>>> Hi All,
>>>
>>> So on the topic of these command line argum
e machine model? How do we pass arguments to
>> it?
>
>
> You create a device via qdev (now QOM) that takes whatever properties you
> need. You then do:
>
> -device elf-loader,base=0xa0,file=my-elf-binary
>
> No different than adding a network card.
A network card
On Mon, Jan 30, 2012 at 12:48 PM, Anthony Liguori wrote:
>
> On Jan 29, 2012 8:41 PM, "John Williams"
> wrote:
>>
>> >>>> There's an opportunity here - QEMU needs the cmdline ability to load
>> >>>> random
do it using a global, but keep in mind that this will need
>> refactoring.
>
>
> Globals are even worse!
>
> Can't you hear the kernel loader begging to be turned into a device? It's
> pleading with us to stop abusing other parts of QEMU and make it a first
> class citizen of QEMU.
Is there some kind of initialisation phase where such a device can do its thing?
Unless I'm missing something a "loader" device will be racing the rest
of the VM after reset to populate the memory with the desired
contents, no?
John
--
John Williams, PhD, B. Eng, B. IT
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663 f: +61-7-30090663
> -Original Message-
> From: Edgar E. Iglesias [mailto:edgar.igles...@gmail.com]
> Sent: Saturday, 27 October 2012 2:12 PM
> To: Peter Crosthwaite
> Cc: qemu-devel@nongnu.org Developers; Avi Kivity; Peter Maydell; John
> Williams
> Subject: Re: [Qemu-devel] [RFC
canning and parsing the device tree)
If only a HW DTB is provided, then that same DTB is used for the kernel.
There are situations when you might want them to be different.
Rgds,
John
--
John Williams, PhD, B. Eng, B. IT
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663 f: +61-7-30090663
need a
bit of extra logic not present in the current ssi code. You should fix that,
not invent a whole new bus.
==
He's gone and done exactly that, indeed generalised it with the
proposed changes to SSI.
If you don't like how he's done the Stellaris change then feel free to
NACK th
ause its non-trivial.
Ping..
We'd really appreciate some feedback on this to avoid the duplicated
effort we are seeing in other areas such as SPI.
Thanks,
John
--
John Williams, PhD, B. Eng, B. IT
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663 f: +61-7-30090663
On Fri, Mar 30, 2012 at 5:58 PM, Peter A. G. Crosthwaite
wrote:
> These patches add support for the Primcell PL330 DMA controller and add it to
> the Xilinx Zynq machine model. Patch 1 is the device model. Patch 2 is the
> machine model update.
>
> The Device model was originally contributed by
aze CPU
> *
> + * Copyright (c) 2009 Edgar E. Iglesias
> * Copyright (c) 2012 SUSE LINUX Products GmbH
Trivial nitpick - please add
Copyright (c) 2009-2012 PetaLogix Qld Pty Ltd
here as well - we've been driving and funding pretty much all of the
MicroBlaze QEMU development the last 3
ed on its technical merit as it stands
today, and if that is suitable then it be merged, with a commitment from us
that when there is suitable plumbing in place our work will be refactored
around that? Indeed, the process of us doing so will probably provide
useful feedback in the design of these underlying layers.
Thanks in advance for your consideration and cooperation.
Regards,
John
--
John Williams, PhD, B. Eng, B. IT
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663 f: +61-7-30090663
On Fri, Sep 2, 2011 at 12:45 PM, John Williams
wrote:
> On Fri, Aug 26, 2011 at 7:17 AM, Anthony Liguori wrote:
>
>> On 08/25/2011 03:20 PM, Edgar E. Iglesias wrote:
>>
>>> On Thu, Aug 25, 2011 at 02:54:13PM -0500, Anthony Liguori wrote:
>>>
>>>>
in every circumstance.
Again this is contrary to our experience - the predominant reason we
have differing OF trees is because we routinely encounter machine
models that contain devices that QEMU knows nothing about. So, we
invalidate them in the device tree before passing it through to the
guest k
unless those roles start pulling in
competing directions.
Commercially my company is an active user and supporter of MicroBlaze and
PPC440 platforms, while personally the Sinclair Spectrum was my first ever
home computing experience and will always have a special place in my geek
heart. So, I vote
17 matches
Mail list logo
