From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:52214) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RvIi8-0001xl-GH for qemu-devel@nongnu.org; Wed, 08 Feb 2012 20:22:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RvIi6-0005Ja-5i for qemu-devel@nongnu.org; Wed, 08 Feb 2012 20:22:08 -0500 Received: from mail-bk0-f45.google.com ([209.85.214.45]:47873) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RvIi5-0005JK-PL for qemu-devel@nongnu.org; Wed, 08 Feb 2012 20:22:06 -0500 Received: by bkue19 with SMTP id e19so979910bku.4 for ; Wed, 08 Feb 2012 17:22:04 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <4F32A442.1090206@codemonkey.ws> References: <1328687721-16030-1-git-send-email-peter.crosthwaite@petalogix.com> <201202081557.48450.paul@codesourcery.com> <201202081615.30937.paul@codesourcery.com> <4F32A442.1090206@codemonkey.ws> Date: Thu, 9 Feb 2012 11:22:04 +1000 Message-ID: From: Peter Crosthwaite Content-Type: multipart/alternative; boundary=0015175cabde036be504b87dd7ec 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: Anthony Liguori Cc: qemu-devel@nongnu.org, peter.maydell@linaro.org, aliguori@us.ibm.com, Paul Brook , Alexander Graf --0015175cabde036be504b87dd7ec Content-Type: text/plain; charset=ISO-8859-1 Alrighty, So it seems like the bootloader as a device idea has some support, just need to work out a few implementaiton details. It seems the consensus is that machine models will instantiate the device. The latest idea is the machine model will pass some of core props to the bootloader while others can come over the command line via a yet to be implemented -property interface. But pretty much any of the alternatives mentioned here start with converting the existing bootloader parameters over to qdev props. So here are the properties of the bootloader (from arm-misc.c): struct arm_boot_info { uint32_t ram_size; char *kernel_filename; char *kernel_cmdline; char *initrd_filename; target_phys_addr_t loader_start; /* multicore boards that use the default secondary core boot functions * need to put the address of the secondary boot code, the boot reg, * and the GIC address in the next 3 values, respectively. boards that * have their own boot functions can use these values as they want. */ target_phys_addr_t smp_loader_start; target_phys_addr_t smp_bootreg_addr; target_phys_addr_t smp_priv_base; int nb_cpus; uint32_t board_id; int (*atag_board)(const struct arm_boot_info *info, void *p); /* multicore boards that use the default secondary core boot functions * can ignore these two function calls. If the default functions won't * work, then write_secondary_boot() should write a suitable blob of * code mimicing the secondary CPU startup process used by the board's * boot loader/boot ROM code, and secondary_cpu_reset_hook() should * perform any necessary CPU reset handling and set the PC for thei * secondary CPUs to point at this boot blob. */ void (*write_secondary_boot)(CPUState *env, const struct arm_boot_info *info); void (*secondary_cpu_reset_hook)(CPUState *env, const struct arm_boot_info *info); }; The addresses, ints and string are easy, but the hard ones are the callbacks. The qdev ptr is a possible implementation but I see a movement away from that. I guess the solution is to provide an abstraction through QOM no? The boards that need to implement their own secondary boot-loop/reset (theres only 1) or atag boot sequence (again only 1) create an object that inherits for the arm boot device and instantiate that? Regards, Peter 2012/2/9 Anthony Liguori > On 02/08/2012 10:15 AM, Paul Brook wrote: > >> 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 >>> >> >> Yes. >> >> There are various implementation/syntax details to resolve, but in >> principle I >> think it should work a lot like that. >> > > There's already a qom-set that takes a path, property, and value. It > works with Visitors. To bridge this to the command line, you would need to > make a Visitor that defined some syntax for mapping strings to types > (pretty trivial really). > > But before we can even think about this, we need to refactor the device > model such that we have a clean separation between initial creation > (including creation of children devices) and initialization that requires > properties to be set (realization). > > I posted a series for the i440fx that started doing this refactoring for > the PC. > > Regards, > > Anthony Liguori > > >> Paul >> >> > --0015175cabde036be504b87dd7ec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Alrighty,

So it seems like the bootloader as a device id= ea has some support, just need to work out a few implementaiton details. It= seems the consensus is that machine models will instantiate the device. Th= e latest idea is the machine model will pass some of core props to the boot= loader while others can come over the command line via a yet to be=A0implem= ented=A0-property interface.=A0

But pretty=A0much=A0any of the alternatives mentioned h= ere start with converting the existing bootloader parameters over to qdev p= rops. So here are the properties of the bootloader (from arm-misc.c):

struct arm_boot_info {
=A0=A0 =A0uint32_= t ram_size;
=A0=A0 =A0char *kernel_filename;
=A0=A0 =A0= char *kernel_cmdline;
=A0=A0 =A0char *initrd_filename;
= =A0=A0 =A0target_phys_addr_t loader_start;
=A0=A0 =A0/* multicore boards that use the default secondary core boot= functions
=A0=A0 =A0 * need to put the address of the secondary = boot code, the boot reg,
=A0=A0 =A0 * and the GIC address in the = next 3 values, respectively. boards that
=A0=A0 =A0 * have their own boot functions can use these values as the= y want.
=A0=A0 =A0 */
=A0=A0 =A0target_phys_addr_t smp_= loader_start;
=A0=A0 =A0target_phys_addr_t smp_bootreg_addr;
=A0=A0 =A0target_phys_addr_t smp_priv_base;
=A0=A0 =A0int nb_cpus;
=A0=A0 =A0uint32_t board_id;
=A0=A0 =A0int (*atag_board)(const struct arm_boot_info *info, void *p);
=A0=A0 =A0/* multicore boards that use the default secondary core = boot functions
=A0=A0 =A0 * can ignore these two function calls. If the default funct= ions won't
=A0=A0 =A0 * work, then write_secondary_boot() sho= uld write a suitable blob of
=A0=A0 =A0 * code mimicing the secon= dary CPU startup process used by the board's
=A0=A0 =A0 * boot loader/boot ROM code, and secondary_cpu_reset_hook()= should
=A0=A0 =A0 * perform any necessary CPU reset handling and= set the PC for thei
=A0=A0 =A0 * secondary CPUs to point at this= boot blob.
=A0=A0 =A0 */
=A0=A0 =A0void (*write_secondary_boot)(CPUStat= e *env,
=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 const struct arm_boot_info *info);
=A0=A0 =A0void (*s= econdary_cpu_reset_hook)(CPUState *env,
=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = const struct arm_boot_info *info);
};

<= div>The addresses, ints and string are easy, but the hard ones are the call= backs. The qdev ptr is a possible implementation but I see a movement away = from that. I guess the solution is to provide an abstraction through QOM no= ? The boards that need to implement their own secondary boot-loop/reset (th= eres only 1) or atag boot sequence (again only 1) create an object that inh= erits for the arm boot device and instantiate that?

Regards,
Peter

2012/2/9 Anthony Liguori <anthony@codemonkey.ws>
On 02/08/2012 10:15 AM, Paul Brook = wrote:
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=3D0x10000000

Yes.

There are various implementation/syntax details to resolve, but in principl= e I
think it should work a lot like that.

There's already a qom-set that takes a path, property, and value. =A0It= works with Visitors. =A0To bridge this to the command line, you would need= to make a Visitor that defined some syntax for mapping strings to types (p= retty trivial really).

But before we can even think about this, we need to refactor the device mod= el such that we have a clean separation between initial creation (including= creation of children devices) and initialization that requires properties = to be set (realization).

I posted a series for the i440fx that started doing this refactoring for th= e PC.

Regards,

Anthony Liguori


Paul



--0015175cabde036be504b87dd7ec--