[meta-intel] Next Gen Intel BSPs (GMA600 on TunnelCreek)

[Hart, Darren]

Scott, question for you below...

On 2/25/14, 21:56, "Zanussi, Tom" <tom.zanussi at intel.com> wrote:

>On Tue, 2014-02-25 at 07:48 -0600, Hart, Darren wrote:
>> On 2/25/14, 21:44, "Zanussi, Tom" <tom.zanussi at intel.com> wrote:
>> 
>> >On Thu, 2014-02-20 at 20:56 -0600, Tom Zanussi wrote:
>> >> On Tue, 2014-02-11 at 18:18 -0600, Hart, Darren wrote:
>> >> > All,
>> >> > 
>> >> > I have just pushed the next-gen Intel BSP changes following the
>>meta
>> >> > commits to linux-yocto-dev and linux-yocto-3.10.
>> >> > 
>> >> > Changes include:
>> >> > 
>> >> > 1) New common BSPs:
>> >> > intel-core2-32:  Support core2 and old atom (pre-baytrail) CPUs
>> >> > intel-corei7-64: Support Nehalem and Baytrail and newer
>> >>core/xeon/atom CPUs
>> >> > 
>> >> > [ ] Beth: Can you please add these two BSPs to meta-intel-nightly?
>> >> > 
>> >> > 2) New INTEL_COMMON_PACKAGE_ARCH
>> >> > This is set to ${TUNE_PKGARCH}-intel-common and applies to any BSP
>> >> > including intel-common-pkgarch.inc. This demotes the linux-yocto
>>and
>> >> > linux-yocto-dev recipes to a PACKAGE_ARCH less specific than
>> >>MACHINE_ARCH
>> >> > (the default for linux-yocto*). For machines that include the
>> >> > intel-common-pkgarch.inc and delete their linux-yocto*bbappend
>>Files,
>> >>they
>> >> > will reuse the intel-common linux-yocto* package. This is either
>>the
>> >> > intel-core2-32-intel-common or the intel-corei7-64-intel-common
>> >>kernel,
>> >> > the same one used for the two new BSPs.
>> >> > 
>> >> > Using the new intel-common PACKAGE_ARCH is an opt-in mechanism.
>> >>Currently
>> >> > only the two new BSPs are using it, although the linux-yocto
>> >>meta-data is
>> >> > already building in support for all the non-emgd meta-intel BSPs.
>> >> > 
>> >> > Next step is to add the inclusion of the intel-common-pkgarch.inc
>>to
>> >>every
>> >> > BSP and delete the linux-yocto machine-specific bbappend and
>> >> > build/boot/verify each BSP. Such a patch series exists here:
>> >> > 
>> >> > 
>> 
>>>>http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-contrib/log/?h=dvh
>>>>ar
>> >>t/
>> >> > bsp-ng
>> >> > 
>> >> > 
>> >> 
>> >> Just FYI...
>> >> 
>> >> crownbay-noemgd from bsp-ng boots but X doesn't start (last good
>>boot or
>> >> normal non-bsp-ng bSP was 2/12 so it's either this patchset or
>>something
>> >> in master since then, will look into it...):
>> >> 
>> >> using poky/master: bb0c26960d3b05070346cdfdfd05d6fd4ad0a7b1
>> >> 
>> >
>> >So the problem here is some kind of interference with the
>>CONFIG_GMA600,
>> >which is now turned on by default - I'll have to either dig into find
>> >the actual problem or just turn it off for _crownbay-noegd...
>> 
>> Oh... Hrm... We should actually be able to use that driver now on the
>> Tunnel Creek systems as of 3.10-LTSI and 3.13+. Scott Garman tested it
>>on
>> the MinnowBoard, I haven't done so myself unfortunately. Do we specify
>> another driver in the xorg.conf or something that is causing some
>> confusion about which driver to use?
>> 
>
>No, there's no special xorg.conf for crownbay-noemgd...

Scott, did you have to do something special to get the gma600 driver
working on the MinnowBoard? Did it require you to write an xorg.conf?

-- 
Darren Hart
Yocto Project - Linux Kernel
Intel Open Source Technology Center