[meta-intel] Kernel bug 109051
I’m using the meta-intel “valley-island” BSP under “krogoth” and think I may have run into https://bugzilla.kernel.org/show_bug.cgi?id=109051. I’m using a J1900 (listed as affected) and the system locks up totally (running a graphics-based application) after an indeterminate period. Using the scripts referenced on the related bug page for comment 437 (https://bugzilla.kernel.org/show_bug.cgi?id=109051#c437) appears to resolve the issue. Is anyone aware of this and/or know if it will be fixed within the Yocto kernel tree? -- Chris Tapp opensou...@keylevel.com www.keylevel.com -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] meta-valleyisland BSP layer retirement communication
Hi Ng, > On 19 Jul 2016, at 03:36, Ng, Mei Yeen <mei.yeen...@intel.com> wrote: > > Dear mailing-list, > > We are planning to retire meta-valleyisland BSP layer from meta-intel master > branch and this change is targeted for the upcoming Yocto Project 2.2. > > This layer is retired in future YP releases because there are no immediate > requirements for support in newer LTSI kernel. Could you please explain what that means / why that is the case? There are boards requiring this BSP that will be in production until after 2020 (we use one) and it would be a pity not to be able to benefit from the improvements that will be made in future versions of Yocto. > The meta-valleyisland BSP layer will continue to be maintained in Yocto > Project for: > Yocto Project v2.0 (Jethro) > https://www.yoctoproject.org/downloads/bsps/jethro20/valley-island > <https://www.yoctoproject.org/downloads/bsps/jethro20/valley-island> Does that mean that there is no official support for ‘krogoth’, even though meta-intel has meta-valleyisland in the ‘krogoth’ branch? I’m currently updating our code to use this... > If you have a concern on this proposal, please let us know. > If we do not hear any response from mailing-list, we will remove > meta-valleyisland BSP from meta-intel master branch start from 3rd August > 2016. > > Thank you. > Ng Mei Yeen > Intel Corporation > > > > > > -- > ___ > meta-intel mailing list > meta-intel@yoctoproject.org <mailto:meta-intel@yoctoproject.org> > https://lists.yoctoproject.org/listinfo/meta-intel > <https://lists.yoctoproject.org/listinfo/meta-intel> -- Chris Tapp opensou...@keylevel.com www.keylevel.com -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] RFC to migrate meta-intel/meta-isg -> meta-intel-isg
> On 10 Mar 2016, at 17:48, Saul Wold <s...@linux.intel.com> wrote: > > > Folks, > > Currently the meta-intel repo contains a sub-layer called meta-isg > which holds a small number of older BSP and a set of Intel specific > software. > > The BSPs, haswell, valleyisland, crystalforest and mohonpeak, are all > using the intel-core* BSPs as appropriate with kernel versions varying > from 3.14 -> 4.1. Any new BSPs should continue to use intel-core* BSPs > with the slight chance that additional kernel cmdline options might be > required. > > The additional Intel specific software is DPDK, QAT, Zlib-QAT and > OpenSSL-QAT, these are specific to certain Intel hardware and not > general. > > The ISG (IoTG) team maintaining the meta-isg layer would like to add > more current graphics than allowed by the Yocto Project's stable rules, > which states no updates in stable, unless needed for urgent CVE issues. > > I would like to hear from the various users of meta-intel and meta- > intel/meta-isg about moving meta-isg into it's own repo that would be > named meta-intel-isg and meta-intel-isg-bsp to distinguish between the > sofware and the BSPs. The hope is that most of the BSP configuration > will come from the meta-intel BSPs to reduce fragmentation. Only > special cases will land in the isg-bsp layer. Most changes should come > in via linux-yocto kernel repo and via intel-core* BSPS. > > Thoughts? This sounds sensible. What are the implications to users? For example, I currently build for a valleyisland platform - will I need to do anything moving forward other that switch to a new layer (ignoring the normal consequential changes due to kernel updates, etc.)? -- Chris Tapp opensou...@keylevel.com www.keylevel.com You can tell you're getting older when your car insurance gets real cheap! -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [yocto] "Crazy" Xorg memory usage after upgrading from Daisy to Fido
Hi Vincent, I may have made some progress. The undesirable memory usage within Xorg isn’t there if I create an xorg.conf file containing: Section “Device” Identifier “Intel Video” Driver “intel” Option “TearFree” “true" EndSection So it looks as if I need to enable “TearFree”. I didn’t need to add this for the 2.99.910 version of xf86-video-intel included with ‘daisy’. Chris > On 23 Nov 2015, at 23:48, Chris Tapp <opensou...@keylevel.com> wrote: > > Hi Vincent, > > I’ve finally got back to being able to investigate this further. > > I’ve now moved on to “jethro” and I’m seeing exactly the same behaviour. I’ve > tried with kernel versions 3.14.39, 3.19.5 and 4.1.8. > >> On 10 Jun 2015, at 03:50, Cheah, Vincent Beng Keat >> <vincent.beng.keat.ch...@intel.com> wrote: >> >> Hi Chris, >> >> I don’t have any idea with regard to the issue that you are getting below. >> All the work that we are doing here so far is on CHV (yocto-kernel-3.19.5 >> standard/base branch). >> >> From your statement below, it looks to me that you are upgrading meta-intel >> from Daisy to Fido branch which are using yocto-kernel-3.14 >> (meta-intel/isg/valleyisland BSP). I'm not sure if you are able to reproduce >> this with yocto-kernel-3.19.5 (standard/base branch) from the meta-intel >> common directory. Also, comparing Daisy branch against Fido, it seems like >> there are lot of changes in the user-space stacks, which I'm not sure could >> cause the issue below. >> >> >> Daisy 1.6.2 >> Kernel 3.4, 3.10, 3.14 (Supportable common base) >> Xorg-server 1.15 >> Wayland/Weston 1.4.0 >> Xf86-video-intel 2.99.910 >> Libdrm 2.4.52 >> MESA 9.2.5 >> Cairo 1.12.16 >> libVA 1.3.1 (from meta-intel) >> Intel-VA-driver 1.3.2 (from meta-intel) >> GStreamer 1.2.3 >> GStreamer-VAAPI 0.5.8 (from meta-intel) >> >> >> Dizzy 1.7.1 >> Kernel 3.10, 3.14, 3.17 (Supportable common base) >> Xorg-server 1.15.1 >> Wayland/Weston 1.5.0 >> Xf86-video-intel 2.99.912 >> Libdrm 2.4.54 >> MESA 10.1.3 >> Cairo 1.12.16 >> libVA 1.3.1 (from meta-intel) >> Intel-VA-driver 1.3.2 (from meta-intel) >> GStreamer 1.4.1 >> GStreamer-VAAPI 0.5.8 (from meta-intel) >> >> >> Fido 1.8 >> Kernel 3.14, 3.19 (supportable comon base) >> Xorg-server 1.16.3 >> Wayland/weston 1.6.0 >> Xf86-video-intel 2.99.917 >> Libdrm 2.4.59 >> Mesa 10.4.4 >> Cairo 1.12.18 >> LibVA 1.5.0 (from meta-intel) >> Intel-VA-driver 1.5.0 (from meta-intel) >> Gstreamer 1.4.5 >> Gstreamer-vaapi 0.5.10 (from meta-intel) >> >> >> ... Vincent >> >> -Original Message- >> From: Chang, Rebecca Swee Fun >> Sent: Wednesday, June 10, 2015 9:08 AM >> To: Cheah, Vincent Beng Keat >> Cc: meta-intel@yoctoproject.org; Chris Tapp; Yocto Project; Wold, Saul; >> 'Paul Eggleton' >> Subject: RE: [meta-intel] "Crazy" Xorg memory usage after upgrading from >> Daisy to Fido >> >> Hi Vincent, >> >> Can you help to comment on this issue mentioned by Chris? >> Thanks. >> >> Regards, >> Rebecca >> >>> -Original Message- >>> From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com] >>> Sent: 09 June, 2015 12:15 AM >>> To: Chang, Rebecca Swee Fun >>> Cc: meta-intel@yoctoproject.org; Chris Tapp; Yocto Project; Wold, Saul >>> Subject: Re: [meta-intel] "Crazy" Xorg memory usage after upgrading >>> from Daisy to Fido >>> >>> Rebecca, is this something you or one of your colleagues would be able >>> to help with? >>> >>> Thanks, >>> Paul >>> >>> On Friday 05 June 2015 08:29:00 Chris Tapp wrote: >>>> I’ve got an application that I’ve had running nicely under Daisy for >>>> some time. As Daisy is now a bit old, I decided to move the >>>> application to >>> Fido. >>>> I’m using the meta-intel/isg/valleyisland BSP and also switched to >>>> using its Fido branch. >>>> >>>> The move only required a few minor changes and allowed me to drop a >>>> Daisy “updates” layer that I had been using for things like gstreamer-1.0. >>>> >>>> However, there is one behaviour which is killing me - I keep getting >>>> oom-killer events!
[meta-intel] Crazy Xorg memory usage after upgrading from Daisy to Fido
I’ve got an application that I’ve had running nicely under Daisy for some time. As Daisy is now a bit old, I decided to move the application to Fido. I’m using the meta-intel/isg/valleyisland BSP and also switched to using its Fido branch. The move only required a few minor changes and allowed me to drop a Daisy “updates” layer that I had been using for things like gstreamer-1.0. However, there is one behaviour which is killing me - I keep getting oom-killer events! The application is basically an OpenGL-ES 2.0 application that renders various bits of text, images and streams captured from a gstreamer pipeline at 60 Hz to a 1080 screen. Under Daisy this generally took just under 50% CPU and used a modest percentage of the 4 GB system memory - i.e. no where near running out and usage was just about static. Under Fido the CPU usage is about the same and the memory used by the application itself looks reasonable when compared to Daisy (and usage is static). However, the memory used by XOrg is far from constant or stable - it basically has a VSZ value cycling from about 630m to 2989m with the cycle period being in the order of 5 to 10 seconds. Peaks in XOrg memory usage coincide with stutters in video playback within my app (audio is unaffected). Monitoring /proc/meminfo when this is going on shows that “Shmem” usage is following the same pattern as the memory used by XOrg (i.e. Shmem usage is high at the same time). If the values are plotted on a graph they appear to show that Shmem usage grows linearly and then falls rapidly when nearly all the free memory has been exhausted, perhaps in response to a delayed garbage collection run. Does anyone have any ideas as to what I should be looking at to work out what’s going on? Are there any significant changes between XOrg under Daisy and Fido that could be causing this? Could this be related to the meta-intel video drivers? Any feedback / comments would be really appreciated. Thanks :-) -- Chris Tapp opensou...@keylevel.com www.keylevel.com You can tell you're getting older when your car insurance gets real cheap! signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] GStreamer 1.0 and VAAPI
Hi Ross, On 7 Jan 2015, at 12:02, Burton, Ross ross.bur...@intel.com wrote: On 2 January 2015 at 22:35, Chris Tapp opensou...@keylevel.com wrote: As I'm using GStreamer 1.0, I'm pulling gstreamer-vaapi-1.0 in to my image. How does gst-va-intel relate to this? I've tried adding this to my image as well, but that results in GStreamer 0.10 being pulled in, resulting in installation conflicts with the 1.0 libraries. Ignore gst-va-intel, all you need is gstreamer-vaapi-1.0 to get GStreamer 1.0 to do VAAPI. Thanks. What about va-intel and libva-intel-driver - looks like I need these? That said 1.0 and 0.10 shouldn't be conflicting, what were the errors? I don't have the exact message to hand at the moment, but it was something to do with 0.10 shared libs being installed with the same name as the corresponding 1.0 libs. The 0.10 then took precedence as they were installed later. 0.10 was pulled in due to some RDEPENDS in gst-va-intel (e.g. for gst-plugins-good-isomp4, which is 0.10 specific). -- Chris Tapp opensou...@keylevel.com www.keylevel.com You can tell you're getting older when your car insurance gets real cheap! -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [yocto] Sound over HDMI for ASrock IMB-151 (valleyisland)
I think I've worked this one out. It looks as if the kernel patch at http://mailman.alsa-project.org/pipermail/alsa-devel/2013-October/067530.html needs to be included so that the ValleyView HDMI codec is detected. Adding it manually before compiling the kernel gives me audio over HDMI. Chris On 14 Dec 2014, at 13:04, Chris Tapp opensou...@keylevel.com wrote: I'm having trouble getting audio out of the HDMI connector on an ASrock IMB-151 board. aplay -l reports: List of PLAYBACK Hardware Devices card 0: PCH [HDA Intel PCH], device 0: ALC662 rev1 Analog [ALC662 rev1 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 1: ALC662 rev1 Digital [ALC662 rev1 Digital] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 3: ID 2882 Digital [ID 2882 Digital] Subdevices: 1/1 Subdevice #0: subdevice #0 and aplay -L gives: null Discard all samples (playback) or generate zero samples (capture) sysdefault:CARD=PCH HDA Intel PCH, ALC662 rev1 Analog Default Audio Device front:CARD=PCH,DEV=0 HDA Intel PCH, ALC662 rev1 Analog Front speakers surround40:CARD=PCH,DEV=0 HDA Intel PCH, ALC662 rev1 Analog 4.0 Surround output to Front and Rear speakers surround41:CARD=PCH,DEV=0 HDA Intel PCH, ALC662 rev1 Analog 4.1 Surround output to Front, Rear and Subwoofer speakers surround50:CARD=PCH,DEV=0 HDA Intel PCH, ALC662 rev1 Analog 5.0 Surround output to Front, Center and Rear speakers surround51:CARD=PCH,DEV=0 HDA Intel PCH, ALC662 rev1 Analog 5.1 Surround output to Front, Center, Rear and Subwoofer speakers surround71:CARD=PCH,DEV=0 HDA Intel PCH, ALC662 rev1 Analog 7.1 Surround output to Front, Center, Side, Rear and Woofer speakers iec958:CARD=PCH,DEV=0 HDA Intel PCH, ALC662 rev1 Digital IEC958 (S/PDIF) Digital Audio Output hdmi:CARD=PCH,DEV=0 HDA Intel PCH, ID 2882 Digital HDMI Audio Output Running aplay -D plug:hdmi /usr/share/sounds/alsa/Front_Center.wav gives nothing out of the hdmi. And speaker-test -D hdmi gives: speaker-test 1.0.27.2 Playback device is hdmi Stream parameters are 48000Hz, S16_LE, 1 channels Using 16 octaves of pink noise Channels count (1) not available for playbacks: Invalid argument Setting of hwparams failed: Invalid argument I've not been able to find anything on the internet that gives me a clue to what's wrong, and alsa is not an area I'm familiar with! Anyone got an idea where I need to look? -- Chris Tapp opensou...@keylevel.com www.keylevel.com You can tell you're getting older when your car insurance gets real cheap! -- ___ yocto mailing list yo...@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- Chris Tapp opensou...@keylevel.com www.keylevel.com You can tell you're getting older when your car insurance gets real cheap! -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] Sound over HDMI for ASrock IMB-151 (valleyisland)
I'm having trouble getting audio out of the HDMI connector on an ASrock IMB-151 board. aplay -l reports: List of PLAYBACK Hardware Devices card 0: PCH [HDA Intel PCH], device 0: ALC662 rev1 Analog [ALC662 rev1 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 1: ALC662 rev1 Digital [ALC662 rev1 Digital] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 3: ID 2882 Digital [ID 2882 Digital] Subdevices: 1/1 Subdevice #0: subdevice #0 and aplay -L gives: null Discard all samples (playback) or generate zero samples (capture) sysdefault:CARD=PCH HDA Intel PCH, ALC662 rev1 Analog Default Audio Device front:CARD=PCH,DEV=0 HDA Intel PCH, ALC662 rev1 Analog Front speakers surround40:CARD=PCH,DEV=0 HDA Intel PCH, ALC662 rev1 Analog 4.0 Surround output to Front and Rear speakers surround41:CARD=PCH,DEV=0 HDA Intel PCH, ALC662 rev1 Analog 4.1 Surround output to Front, Rear and Subwoofer speakers surround50:CARD=PCH,DEV=0 HDA Intel PCH, ALC662 rev1 Analog 5.0 Surround output to Front, Center and Rear speakers surround51:CARD=PCH,DEV=0 HDA Intel PCH, ALC662 rev1 Analog 5.1 Surround output to Front, Center, Rear and Subwoofer speakers surround71:CARD=PCH,DEV=0 HDA Intel PCH, ALC662 rev1 Analog 7.1 Surround output to Front, Center, Side, Rear and Woofer speakers iec958:CARD=PCH,DEV=0 HDA Intel PCH, ALC662 rev1 Digital IEC958 (S/PDIF) Digital Audio Output hdmi:CARD=PCH,DEV=0 HDA Intel PCH, ID 2882 Digital HDMI Audio Output Running aplay -D plug:hdmi /usr/share/sounds/alsa/Front_Center.wav gives nothing out of the hdmi. And speaker-test -D hdmi gives: speaker-test 1.0.27.2 Playback device is hdmi Stream parameters are 48000Hz, S16_LE, 1 channels Using 16 octaves of pink noise Channels count (1) not available for playbacks: Invalid argument Setting of hwparams failed: Invalid argument I've not been able to find anything on the internet that gives me a clue to what's wrong, and alsa is not an area I'm familiar with! Anyone got an idea where I need to look? -- Chris Tapp opensou...@keylevel.com www.keylevel.com You can tell you're getting older when your car insurance gets real cheap! -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] Valleyisland boot gets stuck
Hi Rebecca, On 1 Dec 2014, at 02:37, Chang, Rebecca Swee Fun rebecca.swee.fun.ch...@intel.com wrote: Thanks for your email. We have tested on the supported platforms that we declared in our BSP download page and there is no such issue seen on our side. You can also choose to log a bugzilla ticket if you think you need this issue to be fix. However, since the board you used is not in our supported platform list, we will evaluate first and try our best to help you. I may have found out how to get round this, but I'm not sure I understand why my change works! I started off using the kernel command line given in the default image built by the BSP, which includes: acpi_enforce_resources=lax video=efifb:off vga=0x318 Dropping these seems to have solved the problem. I've not had a chance yet to see if adding them in one at a time makes the problem come back. -Original Message- From: meta-intel-boun...@yoctoproject.org [mailto:meta-intel- boun...@yoctoproject.org] On Behalf Of Chris Tapp Sent: 28 November, 2014 4:58 PM To: meta-intel@yoctoproject.org Subject: [meta-intel] Valleyisland boot gets stuck I'm using the valleyisland BSP to create an image for an ASRock IBI-151 board and this is basically working, but there is an issue when it boots - the boot stalls when the Yocto psplash gets progress bar gets to about 66%. The console doesn't appear to have any messages that give a clue to what's going on. I can get the boot to continue by inserting or removing a USB device (including inserting a 'random' USB security device). Once booted the system runs normally. Any ideas what's going on here? -- Chris Tapp opensou...@keylevel.com www.keylevel.com You can tell you're getting older when your car insurance gets real cheap! -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel -- Chris Tapp opensou...@keylevel.com www.keylevel.com You can tell you're getting older when your car insurance gets real cheap! -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] Valleyisland boot gets stuck
I'm using the valleyisland BSP to create an image for an ASRock IBI-151 board and this is basically working, but there is an issue when it boots - the boot stalls when the Yocto psplash gets progress bar gets to about 66%. The console doesn't appear to have any messages that give a clue to what's going on. I can get the boot to continue by inserting or removing a USB device (including inserting a 'random' USB security device). Once booted the system runs normally. Any ideas what's going on here? -- Chris Tapp opensou...@keylevel.com www.keylevel.com You can tell you're getting older when your car insurance gets real cheap! -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] Why won't my app use multiple threads under 'valleyisland'?
On 29 Jul 2014, at 16:41, Darren Hart dvh...@linux.intel.com wrote:
On Thu, Jul 24, 2014 at 09:45:41PM +0100, Chris Tapp wrote:
I've got a recipe for an application. This has:
1) A main thread;
2) An OpenGL ('X' / EGL) graphics rendering thread created using posix
threads;
3) As many threads as required from the graphics thread for GStreamer to
service various pipelines.
On a Cedartrail platform this happily uses multiple cores.
Major difference here is graphics chip, cedartrail uses EMGD binary drivers,
baytrail (valleyisland) uses the open source Intel i965 drivers.
I recently (yesterday) updated meta-intel master and daisy to properly support
video acceleration in gstreamer 1.0 - I don't know if this impacts you or not.
Thanks for the pointer. I'll give it a try and see if it makes a difference.
However, if I use the same recipe under a 64-bit valleyisland build (daisy) it
only ever uses a single core (and virtually grinds to a halt).
'top' shows CPU usage for the application never goes above 25% (J1900, so
four
cores available). Running four instances of 'yes' gets the total CPU usage to
100%, so all the cores are available.
Does /proc/cpu list four cores?
It does.
I've also found that running the GStreamer pipeline outside of (and at the same
time as) my application works as expected - i.e. more CPU resources are used
and the application runs at the target loop time, so the system can definitely
do what I want...
'taskset' shows that the affinity mask for the application is not restricting
the set of available cores.
Umm... Any ideas what's going on here?
It looks as if GStreamer and OpenGL are fighting for access to something, but
the pipelines only render to 'fakesink' and 'appsink'.
I don't have any GL/GST development experience, so this is likely best taken
to
those respective lists.
Thanks, I've already tried that and not got anything back ;-)
--
Darren
Chris Tapp
opensou...@keylevel.com
www.keylevel.com
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] Why won't my app use multiple threads under 'valleyisland'?
I've got a recipe for an application. This has:
1) A main thread;
2) An OpenGL ('X' / EGL) graphics rendering thread created using posix threads;
3) As many threads as required from the graphics thread for GStreamer to
service various pipelines.
On a Cedartrail platform this happily uses multiple cores.
However, if I use the same recipe under a 64-bit valleyisland build (daisy) it
only ever uses a single core (and virtually grinds to a halt).
'top' shows CPU usage for the application never goes above 25% (J1900, so four
cores available). Running four instances of 'yes' gets the total CPU usage to
100%, so all the cores are available.
'taskset' shows that the affinity mask for the application is not restricting
the set of available cores.
Umm... Any ideas what's going on here?
It looks as if GStreamer and OpenGL are fighting for access to something, but
the pipelines only render to 'fakesink' and 'appsink'.
Chris Tapp
opensou...@keylevel.com
www.keylevel.com
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] J1900 (Bay trail) BSP
Hi Rebecca, On 21 Apr 2014, at 03:08, Chang, Rebecca Swee Fun rebecca.swee.fun.ch...@intel.com wrote: Hi, Bay Trail BSP is now named, meta-valleyisland. It is in meta-intel/meta-isg. Please do checkout Dora branch as it is not available in master branch. I should have asked the other day if there are plans for meta-valleyisland to be added to Daisy and future versions? I hope so, as the embedded board I'm looking to use is due to be launched about now and will be available until 2020 ;-) Thank you. Rebecca -Original Message- From: meta-intel-boun...@yoctoproject.org [mailto:meta-intel- boun...@yoctoproject.org] On Behalf Of Chris Tapp Sent: 18 April, 2014 12:40 AM To: Yocto Project; meta-intel@yoctoproject.org Subject: [meta-intel] J1900 (Bay trail) BSP Is there a BSP for the J1900 anywhere? I thought I had seen some patches go through for Bay Trail, but I've not found anything obvious in meta-intel. I want to get accelerated GLES under X if that helps. Chris Tapp opensou...@keylevel.com www.keylevel.com -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel Chris Tapp opensou...@keylevel.com www.keylevel.com -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] J1900 (Bay trail) BSP
On 28 Apr 2014, at 21:46, Ong, Boon Leong boon.leong@intel.com wrote: Bay Trail BSP is now named, meta-valleyisland. It is in meta-intel/meta-isg. Please do checkout Dora branch as it is not available in master branch. I should have asked the other day if there are plans for meta-valleyisland to be added to Daisy and future versions? We plan to support BYT for daisy on Linux v3.10 LTSI/LTS. We are currently up-streaming BYT related kernel drivers (with PCI enumeration support). So, it is anticipated that the next LTS/LTSI to be announced by Aug/Sept time-frame should carry with it all the kernel drivers for BYT. Knowing that future YP releases will always have a version of Linux LTS/LTSI, so from our perspective, the kernel drivers should just work onwards. Thanks, that's good news :-) I'll kick things off using Dora and plan to move to Daisy later on. Please DO anticipate that in future, we are likely to drop validating BYT platform after some version of Linux LTSI and switch focus on next platform. So, if you need to ensure your product that to continue to work on future releases of Linux, you can either maintain it yourself or engage OSVs such as Wind River which has extended support. I'm hoping that we won't need any updates once we've got the initial version running, especially as we don't have the budget to engage OSVs. We only run with hardware that's part of the platform, so kernel updates aren't likely to be needed. It's sometimes nice to be able to use later versions of other packages (e.g. GStreamer), but those are generally simple enough to pull in if needed. I hope so, as the embedded board I'm looking to use is due to be launched about now and will be available until 2020 ;-) Thank you. Rebecca Chris Tapp opensou...@keylevel.com www.keylevel.com -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] J1900 (Bay trail) BSP
Is there a BSP for the J1900 anywhere? I thought I had seen some patches go through for Bay Trail, but I've not found anything obvious in meta-intel. I want to get accelerated GLES under X if that helps. Chris Tapp opensou...@keylevel.com www.keylevel.com -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] BSP retirements from meta-intel layer
On 18 Mar 2014, at 01:50, Ong, Boon Leong boon.leong@intel.com wrote: -Original Message- From: Darren Hart [mailto:dvh...@linux.intel.com] Sent: Tuesday, March 18, 2014 6:54 AM To: Keskinarkaus, Teemu; Chris Tapp; Kamble, Nitin A Cc: meta-intel@yoctoproject.org; Chang, Rebecca Swee Fun; Ong, Boon Leong Subject: Re: [meta-intel] BSP retirements from meta-intel layer On 3/13/14, 21:21, Keskinarkaus, Teemu teemu.keskinark...@maximatecc.com wrote: From: meta-intel-boun...@yoctoproject.org [mailto:meta-intel- boun...@yoctoproject.org] On Behalf Of Chris Tapp Following on from the chiefriver BSP retirement thread, what is the general policy for BSP life-cycles within meta-intel? For example, we committed to using the Cedartrail BSP a couple of years back as if offered support for what was then a new platform with a reasonable forward buy-time. However, support for that has been dropped even though boards are still available using the chipset (e.g. ASRock DN2800MT) and these are going to be available for a few years yet. From our point of view it is a pity not to be able to make use of the improvements and enhancements that have gone into later Yocto versions, especially as we're continually updating our software. This interests me as well since we have been planning on using Yocto on our HW for a long time. We also noticed the drop of Cedartrail BSP and we ended up on porting it to newer Yocto ourselves which of course wasn't what we were hoping to get when switching to Yocto. As for chief river, sys940x, and n450 (which I haven't yet posted the retirement notification for), these systems are simply being supported by the intel-common BSPs (intel-core2-32 and intel-corei7-64). So support is not being dropped, it is being streamlined. The hardware is still supported. While we would like to support every platform continually, we (I speak of the core yocto team here, not as an Intel BSP maintainer) sometimes must decide between adding a new platform or continuing to support an older platform. I expect this to become less of an issues as the platforms become more open over time (as we are seeing with the graphics on the Baytrail SoCs for example). As for more specific platforms such as cedar trail as mentioned here, that must be addressed the BSP maintainers. If folks are doing the forward ports themselves, that is something the maintainers need to be aware of and take into consideration with their support plans. Please discuss this with them (Rebecca and Boon Leong added to Cc) - off list would be best as this becomes an individual support issue between the customer and the Board/BSP vendor (Intel ISG in this case). In the case of Cedartrail, the last YP BSP is support is version 1.3 (danny). There is no plan for upgrade to newer YP version. If you have specific need, please contact your Intel sales rep/account and they should be able to bring your case for internal whether an upgrade plan is approved. Thanks and sorry for inconvenience caused. Thanks for the suggestion, but I don't have an Intel sales rep/account as we are only a small player when it comes to hardware. We typically make 100 to 200 units a year, and, because this is low volume, we use COTS hardware like the DN2800MT (formally Intel, now ASRock). I will get in touch with the UK sales office and see what they suggest. In general I can't imagine anyone expecting support for old hardware to continue, but support was dropped with Dylan back in April 2013 even though the silicon is still in production. This is really why I was hoping an official position on support could be given, as small players (of which there are many in the embedded sector) don't have the contacts with the silicon vendors which means it can take a long, long time for important information to make it through. Though there is a bit of a heads-up as I've just seen that EOL was announced back in November 2013 for the non-embedded version of the N2800 - just sent a request to our board supplier to check which one they use... Chris Tapp opensou...@keylevel.com www.keylevel.com -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] BSP retirements from meta-intel layer
Following on from the chiefriver BSP retirement thread, what is the general policy for BSP life-cycles within meta-intel? For example, we committed to using the Cedartrail BSP a couple of years back as if offered support for what was then a new platform with a reasonable forward buy-time. However, support for that has been dropped even though boards are still available using the chipset (e.g. ASRock DN2800MT) and these are going to be available for a few years yet. From our point of view it is a pity not to be able to make use of the improvements and enhancements that have gone into later Yocto versions, especially as we're continually updating our software. Chris Tapp opensou...@keylevel.com www.keylevel.com -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] Cedartrail zero-copy texture updates
I'm trying to get zero-copy GLES textures working using Danny / Cedartrail (PVR) so I can stream video frames into a GLES application. Googling hasn't really helped that much with how to do this, but I think I need to use eglCreateImageKHR and a client-side buffer so that glEGLImageTargetTexture2DOES() can be used to bind the texture to an image in memory. eglCreatePixmapSurfaceHI() looks like it allows client memory to be used as a colour-buffer which can be passed to eglCreateImageKHR, but I can't seem to be able to create a context which supports pixmaps. Are there any examples out there to show how to put all of this together? Chris Tapp opensou...@keylevel.com www.keylevel.com ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [yocto] Cedartrail zero-copy texture updates
Hi Marc, On 24 Feb 2014, at 19:21, Marc Ferland ferla...@sonatest.com wrote: On Mon, Feb 24, 2014 at 03:46:07PM +, Chris Tapp wrote: I'm trying to get zero-copy GLES textures working using Danny / Cedartrail (PVR) so I can stream video frames into a GLES application. Googling hasn't really helped that much with how to do this, but I think I need to use eglCreateImageKHR and a client-side buffer so that glEGLImageTargetTexture2DOES() can be used to bind the texture to an image in memory. eglCreatePixmapSurfaceHI() looks like it allows client memory to be used as a colour-buffer which can be passed to eglCreateImageKHR, but I can't seem to be able to create a context which supports pixmaps. Are there any examples out there to show how to put all of this together? Documentation about this stuff is indeed sparse and hard to find! I once tried (and failed!) to do something similar on crownbay but the texture data was mapped to a polygon mesh (no video acceleration stuff). The documentation that I came across mentionned using the GL_TEXTURE_STREAM_IMG extension to implement the zero-copy texture transfers. Maybe the same extension is available on cedartrail. I don't think is it. I tried to find this before and could only find GL_IMG_texture_stream2 listed in the GL extensions (for which I can find no documentation!). The pdf used to be hosted on intel (emgd section) web site, but it looks like it was taken down. I can check if I still have it somewhere if you're interested. Yes please :-) Chris Tapp opensou...@keylevel.com www.keylevel.com ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] Fwd: [yocto] Where's my 'thermal_zone'?
I'm trying to find the cpu temperatures on a system running a cedartrail image built under Danny. /sys/thermal has thermal_cooling entries (four of which are CPU related), but not the thermal_zone entries I need to read the CPU temperatures. What do I need to do / add to get these in? Chris Tapp opensou...@keylevel.com www.keylevel.com ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
