17 Replies Latest reply on Feb 12, 2015 5:11 AM by shigorin

    Bay Trail platform support/woes on Linux

    Green Belt


      I'm interested in finding the place where people who work on linux for baytrail based hardware are communicating, ideally with developers (which means that a mailing list is actually preferred).

      The woes as they are for me with v3.17-rc7 are:

      • CONFIG_PINCTRL_BAYTRAIL=y breaks touchscreen (#68291, #74241)
      • battery information unavailable (#69011)
      • screen backlight brightness not adjustable
      • powering down the screen results in weird "milk" flooding it
      • no suspend available, only "freeze" and "disk" modes

      There are smaller problems like this eMMC/RPMB one, and it looks like anyone working on baytrail uses 32-bit kernels while we're more interested in 64-bit environment, at least if it's not insurmountable (it does boot for me upon flashing 64-bit firmware).  "Anyone" as in people who took part in discussing the above referenced bugs, I'd specifically note Adam Williams of Red Hat with his fedlet project and Rolf Eike Beer of emlix.

      There are vendor-specific nuances like firmware/nvram for brcmfmac (my understanding based on yocto commits is that there's some work on "native" wifi within sugarbay scope) -- those are to be discussed with particular vendors of course.

      So, where's that communication channel, or how do we set up one?

        • Re: Bay Trail platform support/woes on Linux
          LynnZ Brown Belt

          Hello!  Welcome to the Embedded Community! I did some checking for you and here is a reply from someone on our software team: With regards to kernel specific issues … As noted by you, all kernel issues will need to  be reported to kernel.org.  You point out 3 kernel related issues that are in kernel.org.  Look in there for comments that are directly from Intel employees who are responding / review / and patching the kernel.  Addresses that have @linux.intel.com are Intel employees. With graphics .. that is a different issue.  Our graphics driver comes from 01.org.  More specifically it comes from here … https://01.org/linuxgraphics/downloads This is the open source graphics driver. Please note that we are currently only have graphics drivers for 3.16.2  and typically have drivers for released kernels.  We typically do not release drivers for release candidates (rc).   With regards to pure embedded …. We are supporting 3.8 kernel on the Timesys version of Fedora 18 and with Yocto we are supporting kernel 3.8 and LTSI-3.10 kernel from the Linux foundation.  The LTSI kernel is a snapshot of kernel.org that the Linux foundation is supporting for long life, 2-3 years. http://www.linuxfoundation.org/collaborate/workgroups/consumer-electronics/ltsi-overview So, Shigoran, how did my software contact do for you?  :-)  Hope that you're having a great day and this response is just one of the small things that makes it so!



          Hi, I had to edit the italicized sentence above - it originally posted as "We typically to" instead of "We typically do not". 

            • Re: Bay Trail platform support/woes on Linux
              Green Belt

              Thank you for the reply (I've read it back then but was waiting for hardware vendor's reply either); I know how to spot Intel employees in kernel bugzilla but it's harder to find those responsible for a particular subsystem, just bothering anyone is a bad thing IMO :-)


              Regarding kernels: I know of Yocto project; the current issue at hand is that kernel patches provided by ODM within its Android pack (3.10.20-based) don't apply to both android-3.10 and linux-yocto-3.10 as arch/x86/platform/intel-mid/ is simply missing there just as in vanilla 3.10.x (it was merged into mainline by 3.13).  The BSP kernel lacks git data unfortunately, it's just a checkout.  The patches add/change board specific identifiers for ACPI/I2C hooked devices so look like important to me by now.


              The current kernel question is thus "where do I pull kernel git corresponding to Intel_Android_BSP.zip's android-kk/linux/kernel/" (which still leaves the headache of having to figure out and port the bits from android to mainline one).


              The communication question is also still open: where do people trying to get Linux (not Android but good ol' GNU/Linux) onto Intel MID platforms flock with Intel's kernel and graphics developers to at least have some common code ground instead of having to wade through kernel trees floating around?  I can email people directly but that's highly suboptimal as their answers (if any) wouldn't be archived publicly for others to find and use.


              TIA, and don't waste flashy cheers on those Russians -- we value raw matter as usual :-)  Have a great day indeed!

                • Re: Bay Trail platform support/woes on Linux
                  AdolfoS Brown Belt

                  Hello shigorin


                  Sorry for the long delay.

                  Could you please give us more detail about your platform.

                  Is it Bay Trail or Bay Trail CR?

                  Is the design based on BYT-CR MRD program?




                    • Re: Bay Trail platform support/woes on Linux
                      Green Belt

                      No problem, wish there were email notifications [that reached my inbox] though ;-)


                      The SoC is Intel(R) Atom(TM) CPU  Z3745  @ 1.33GHz -- how do I differ the platforms you mentioned?  Regarding MRD program, I could probably ask the ODM but it'd be quicker if it could be told given the hardware running under Linux.


                      BTW the battery status is now available under Linux 3.18-rc4 with this patch applied, one problem less.

                        • Re: Bay Trail platform support/woes on Linux
                          AdolfoS Brown Belt

                          Hello shigorin, this is not directly related to this issue but I think you might want to know that you can enable an option to receive email notifications of replies of threads that you are interested in.


                          You simply enter in the thread, if you look in the right side you should see a "Following in" option if you click on that option and mark the "Email Watches" option you will receive notifications in your inbox anytime there is activity in the thread.

                          1 of 1 people found this helpful
                  • Re: Bay Trail platform support/woes on Linux
                    AdolfoS Brown Belt

                    Hello Shigorin


                    This is the forum for the Intel Opensource Driver Community: Forums | Linux Graphics

                    And in this link you can find contacts and mailing list, and IRC chat rooms for the different Open Source Graphic Drivers used by Intel: Community | Linux Graphics


                    Also you can check the Intel EMGD Driver, although is not completely Open Source, it is designed to give better performance for embedded platforms based on Atom Intel® EMGD for Intel® Atom™ Processor-Based Systems


                    Hope this is useful to you 




                    • Re: Bay Trail platform support/woes on Linux
                      Green Belt

                      Current updates:

                      • screen backlight bug is: fdo#85977 (unresolved so far);
                      • the accelerometer works with 3.18-rcX too, iio-sensor-proxy translates it into [GNOME] desktop rotation.
                      • Re: Bay Trail platform support/woes on Linux
                        Green Belt

                        Updates as of Linux 3.19 (including rc4--rc7):

                        • backlight hack broke as there's ongoing work on backlight support;
                        • SDIO/GPIO related stability seems to have improved considerably, a device can sit for about a week just fine instead of locking up overnight almost each time;
                        • ACPI S0ix is being worked upon within intel-gfx@ mailing list, those interested might find "Display Sequences for Package C8" in this document somewhat informative (not clear what should/must/can be done within distro's userspace excluding xorg driver itself though).