Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition

[Peter Crosthwaite]

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 <address@hidden>

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