[linux-yocto] [PATCH] meta: add genericx86 BSP

[Bruce Ashfield]

On 13-08-21 01:33 PM, Darren Hart wrote:
> On Wed, 2013-08-21 at 17:57 +0100, Ross Burton wrote:
>> This BSP aims at supporting a broad range of Intel platforms, from Atom up to
>> Xeon.  As such the kernel includes a range of drivers, and the corresponding
>> machine configuration in meta-yocto-bsp includes a range of user-space drivers.
>>
>> Signed-off-by: Ross Burton <ross.burton at intel.com>
>> ---
>>   .../bsp/genericx86/genericx86-standard.scc         |   28 ++++++++++++++++++++
>>   1 file changed, 28 insertions(+)
>>   create mode 100644 meta/cfg/kernel-cache/bsp/genericx86/genericx86-standard.scc
>>
>> diff --git a/meta/cfg/kernel-cache/bsp/genericx86/genericx86-standard.scc b/meta/cfg/kernel-cache/bsp/genericx86/genericx86-standard.scc
>> new file mode 100644
>> index 0000000..94d8ca7
>> --- /dev/null
>> +++ b/meta/cfg/kernel-cache/bsp/genericx86/genericx86-standard.scc
>> @@ -0,0 +1,28 @@
>> +define KMACHINE genericx86
>> +define KTYPE standard
>> +define KARCH i386
>> +
>> +# TODO: long-term move away from common-pc?
>> +include bsp/common-pc/common-pc-standard.scc
>> +branch atom-pc
>> +
>> +include cfg/x86.scc
>> +include cfg/boot-live.scc
>> +
>> +include features/power/intel.scc
>> +
>> +# Ideally all of these below would be modules instead of built-in.
>> +
>> +# common-pc brings in the other USB controllers
>> +include features/usb/xhci-hcd.scc
>
> And should really bring this one in too...

Agreed!

>
>> +
>> +# Intel ethernet, old and new Intel wireless.
>> +include features/rfkill/rfkill.scc
>> +include features/intel-e1xxxx/intel-e1xxxx.scc
>> +include features/iwlwifi/iwlwifi.scc
>> +include features/iwlegacy/iwlegacy.scc
>> +
>> +# Intel Gen and GMA500. common-pc provides Vesa framebuffer.
>> +include features/i915/i915.scc
>> +include features/drm-gma500/drm-gma500.scc
>> +include features/drm-gma500/drm-gma3600.scc
>
> This is really a fairly small change. Any reason this shouldn't just be
> an update to common-pc? Is there a conceptual difference here?

I'd like to see them just merge. They are both targeting a similar set
of commodity hardware platforms. Sure, qemux86 will pick these up as
well, but as qemu gains more functionality we can use more and more of
the options.

Cheers,

Bruce


>