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:
There are smaller problems like http://permalink.gmane.org/gmane.linux.kernel.mmc/28281 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?
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 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 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".
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 https://android.googlesource.com/kernel/common/+/android-3.10http:// android-3.10 and http://git.yoctoproject.org/cgit.cgi/linux-yocto-3.10http:// linux-yocto-3.10 as arch/x86/platform/intel-mid/ is simply missing there just as in https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/?id=refs/tags/v3.10.58http... 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 https://git.kernel.org/cgit/linux/kernel/git/dacohen/intel-mid.git/log/http:// 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!
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?
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 https://bugzilla.kernel.org/show_bug.cgi?id=69011# c61 this patch applied, one problem less.
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.
This is the forum for the Intel Opensource Driver Community: https://01.org/linuxgraphics/forum 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: https://01.org/linuxgraphics/community 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 https://www-ssl.intel.com/content/www/us/en/embedded/software/emgd/embedded-media-and-graphics-drive... Intel® EMGD for Intel® Atom™ Processor-Based Systems
Hope this is useful to you
Hello, Shigorin! BSP's fall under the category of Intel Confidential and therefore a CNDA (Corp. Non-Disclosure Agreement) would need to be in place between your company and Intel.
If you are interested in getting that process started please request to have your EDC Basic account upgraded to Privileged. To do this go to http://www.intel.com/content/www/us/en/intelligent-systems/embedded-design-center-contact-us.html Intel® Embedded Design Center Contact and Support and click on the 'Manage my Intel Profile" link that is found in the "Manage Your Intel EDC Account" section of the page. You should then be able to click on "Upgrade to Privileged", complete the form and submit. Once you have completed that step, please let me know so that we can help move the process along for you. In the meantime, would it be okay with you if I had an Intel representative contact you to discuss your project and start the CNDA process if you are interested? LynnZ
Hey LynnZ, what exactly should BSP provide, the known good driver code?
I'm probably interested (ALT Linux has signed NDA with Intel some 12 years ago or so, guess that's expired quite thoroughly by now) but trying to follow your instructions or https://www-ssl.intel.com/content/www/us/en/secure/profile/profile.html this link currently redirects me to https://www-ssl.intel.com/content/www/us/en/secure/profile/profile.message.error.html a page titled "Manage Your Intel Profile" and reading:Service Unavailable
The account profile service is currently unavailable. Please try again later.
Guess I'll try again latersTM, IIRC I've seen that "upgrade" link in the profile before.
Anything legitimate that would help getting ALT working properly on Baytrail is fine with me :-)
Seems to have been fixed, the profile is displayed now with "Pending Privileged" being the status for
Intel® Embedded Design Center program membership; thank you.
Looks like this process has timed out while trying to find out if the previously signed NDA is active/related (the current understanding is "no/no"). Might be worth restarting, not sure.
Hi, Mike. You'll need to work directly with the Intel representative who contacted you for access. Access to Intel Confidential content has not been granted so he likely needs to know more about your project.
Updates as of Linux 3.19 (including rc4--rc7):