From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47101) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rv9zY-0000iC-5B for qemu-devel@nongnu.org; Wed, 08 Feb 2012 11:03:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rv9zT-0007LI-Fn for qemu-devel@nongnu.org; Wed, 08 Feb 2012 11:03:32 -0500 Received: from mail-bk0-f45.google.com ([209.85.214.45]:48703) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rv9zT-0007L6-Ae for qemu-devel@nongnu.org; Wed, 08 Feb 2012 11:03:27 -0500 Received: by bkue19 with SMTP id e19so560571bku.4 for ; Wed, 08 Feb 2012 08:03:26 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <201202081557.48450.paul@codesourcery.com> References: <1328687721-16030-1-git-send-email-peter.crosthwaite@petalogix.com> <201202081456.08096.paul@codesourcery.com> <201202081557.48450.paul@codesourcery.com> Date: Thu, 9 Feb 2012 02:03:26 +1000 Message-ID: From: Peter Crosthwaite Content-Type: multipart/alternative; boundary=000e0cdfc786273e8f04b876095a Subject: Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: peter.maydell@linaro.org, aliguori@us.ibm.com, Alexander Graf , qemu-devel@nongnu.org --000e0cdfc786273e8f04b876095a Content-Type: text/plain; charset=ISO-8859-1 2012/2/9 Paul Brook > > So here are some of the problems im trying to solve with the bootloader: > > > > Smp bootstrap secondary CPUs while loading an elf (currently elfs will be > > assumed to be not kernels). > > Change the kernel, initrd and dtb load address on the command line. > > Use my own SMP secondary bootloop. > > > > My intention with this patch was to set myself to do boot > parameterizations > > on the command line by just adding them as qdev props to the > > arm_linux_loader and set them using -device instantiation. E.G. -device > > arm_boot_loader,initrd_addr=0x10000000. But if I take the approach you > are > > suggesting, the for this initrd load address option, I would need to add > > myself a command line option, fetch that command line option in every arm > > machine model and then pass it to arm_load_kernel. > > No. You just set/override properties on the device that the machine > created. > I thought we already had this, but it looks like the closest we have is > -global. > > Something like "-property /devicepath/propertyname=value". > This is something we need anyway. Creating new devices with -device is of > very limited value if you can't link existing device properties to that new > device. Remember that in the new world order we don't have magic > bus-device, > everything is done via link properlties. > > Ok, that sounds more workable :). So i would add my initrd_addr property to the bootloader as a qdev prop as I suggested before, then something like: qemu-system-arm -M verstailepb -property /foo/bar/arm_linux_loader.0,initrd_addr=0x10000000 ? Paul > Peter --000e0cdfc786273e8f04b876095a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/2/9 Paul Brook &l= t;paul@codesourcery.com>
> So here are some of the problems im trying to solve = with the bootloader:
>
> Smp bootstrap secondary CPUs while loading an elf (currently elfs will= be
> assumed to be not kernels).
> Change the kernel, initrd and dtb load address on the command line. > Use my own SMP secondary bootloop.
>
> My intention with this patch was to set myself to do boot parameteriza= tions
> on the command line by just adding them as qdev props to the
> arm_linux_loader and set them using -device instantiation. E.G. -devic= e
> arm_boot_loader,initrd_addr=3D0x10000000. But if I take the approach y= ou are
> suggesting, the for this initrd load address option, I would need to a= dd
> myself a command line option, fetch that command line option in every = arm
> machine model and then pass it to arm_load_kernel.

No. =A0You just set/override properties on the device that the machin= e created.
I thought we already had this, but it looks like the closest we have is
-global.

Something like "-property /devicepath/propertyname=3Dvalue".
This is something we need anyway. =A0Creating new devices with -device is o= f
very limited value if you can't link existing device properties to that= new
device. =A0Remember that in the new world order we don't have magic bus= -device,
everything is done via link properlties.


Ok, that sounds more workable :). So i would add my = initrd_addr property to the bootloader as a qdev prop as I suggested before= , then something like:

qemu-system-arm -M verstailepb -property /foo/bar/arm_linux_loader.0,in= itrd_addr=3D0x10000000
=A0
?

Paul

Peter
--000e0cdfc786273e8f04b876095a--