On Tue, Dec 17, 2013 at 9:47 PM, Peter Maydell <peter.mayd...@linaro.org> wrote:
> On 17 December 2013 11:36, Peter Crosthwaite
> <peter.crosthwa...@xilinx.com> wrote:
>> On Tue, Dec 17, 2013 at 8:31 PM, Peter Maydell <peter.mayd...@linaro.org>
>> 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 <peter.crosthwa...@xilinx.com>
>
> Thanks.
>
> -- PMM
>
