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

[Peter Crosthwaite <peter.crosthwaite@petalogix.com>]

[-- Attachment #1: Type: text/plain, Size: 3616 bytes --]

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 <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=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
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 4774 bytes --]