Re: [Qemu-devel] [PATCH 5/7] hw/arm/boot: Allow easier swapping in of different loader code

[Peter Crosthwaite]

On Tue, Dec 17, 2013 at 9:47 PM, Peter Maydell <address@hidden> wrote:
> On 17 December 2013 11:36, Peter Crosthwaite
> <address@hidden> wrote:
>> On Tue, Dec 17, 2013 at 8:31 PM, Peter Maydell <address@hidden> wrote:
>>> I'm not convinced about this at all -- this would be letting the
>>> "I know about booting Linux" code spread out from boot.c
>>> where it currently is into every device. That sounds like a bad idea. -
>>>
>>
>> So the "I know about boot linux" code already has to span multiple
>> architectures it's already reasonably 'spread out' just looking at the
>> zoo of Linux bootloaders. Its also a contributor to the much disliked
>> inconsistencies in boot flow between archs.
>>
>> If we can outsource arch/board specific bringup to device land it
>> would allow consolidation of all the different Linux bootloaders. Or
>> at least across embedded - E.g. Microblaze, ARM, some of the board
>> level PPC bootloaders O.R. and the newly posted Moxie machine.
>>
>> ARM_CPU / MICROBLAZE_CPU would be responsible for setting dtb reg ptr
>> / kernel args, program entry point.
>> ARM_GIC would set itself up.
>
> ...but how? What the GIC state needs to be depends on the board.
>

In such cases, boards could trivially define a lightweight QOM child class
(of the device in question) that implements the linux_reset() hook their
specific way:

TypeInfo vexpress_gic_info {
    .parent = TYPE_ARM_GIC,
    .interfaces = {
        { TYPE_LINUX_RESET },
        {}
    },
    .class_init = vexpress_gic_class_init,
}

Regards,
Peter

> It's times like this I see the appeal of pushing the whole thing off onto
> a custom "firmware blob" which does the work :-)
>
>> we are not going to solve this today and at the end of the day, the
>> patch does make this much more self documenting and flexible for ARM,
>> so:
>>
>> Reviewed-by: Peter Crosthwaite <address@hidden>
>
> Thanks.
>
> -- PMM
>