Scott, question for you below... On 2/25/14, 21:56, "Zanussi, Tom" <[email protected]> wrote:
>On Tue, 2014-02-25 at 07:48 -0600, Hart, Darren wrote: >> On 2/25/14, 21:44, "Zanussi, Tom" <[email protected]> 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 _______________________________________________ meta-intel mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-intel
