Re: [yocto] New RC for 1.6.
Hi Beth, There are some artifacts missing for beaglebone, the .dtb files. rc3 had them... This is only a problem for minimal images, all the others don't need the dtb files, but they should be there nevertheless (between rc3 and rc4 kernel image type changed from zImage to uImage fwiw, so the dtb file changed name too, as in uImage-am335x-boneblack.dtb) Cheers, Stefan On Thu, 2014-04-10 at 22:15 -0700, Flanagan, Elizabeth wrote: > All, > > A few much needed bug fixes came in to fix some of the issues we saw > with rc3. We decided that we should just roll and rc4. Please begin > testing this as soon as possible. > > We're seeing one issue on the world build: > > http://autobuilder.yoctoproject.org/main/builders/nightly-world/builds/42/steps/BuildImages/logs/stdio > > but as this produces no published artifacts, I think we're ok with at > least the release artifacts. > > http://autobuilder.yoctoproject.org/pub/releases/yocto-1.6_M5.rc4 > > bitbake bb4980c63db386ce7d30d9a6b86e9f3861b3bc3a > eclipse-poky-juno 26bfc407781aa185f244a47ba63120343cee4a37 > eclipse-poky-kepler 1dfe1d2f1322b5fda8e1a7637c447b0e060efb3e > meta-fsl-arm d4316faef78ceb01ff023579e15110939ec69408 > meta-fsl-ppc c4fa1b431f4efc4982a168119db95236cfa8cad3 > meta-intel db84acfc8d9ed8dccd4a79de39fee337bc729662 > meta-minnow 7bdcd1140b729598bae6246a4bbc21c3950aadd8 > meta-qt3 3016129d90b7ac8517a5227d819f10ad417b5b45 > oecore dca1b4f073fff740364f066f6a68bb3c8697b7a6 > poky a0958261265049904fd78a2ba0198d46e5e65ea9 > > > -- > Elizabeth Flanagan > Yocto Project > Build and Release -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] BBB doesn't boot
On 2014-04-13 20:33, Denys Dmytriyenko wrote: > On Sun, Apr 13, 2014 at 03:12:16AM -0600, Gary Thomas wrote: >> I just tried building (core-image-sato) for my BeagleBoneBlack >> using the latest Poky/Yocto master: >> >> Build Configuration: >> BB_VERSION= "1.23.0" >> BUILD_SYS = "i686-linux" >> NATIVELSBSTRING = "Fedora-13" >> TARGET_SYS= "arm-poky-linux-gnueabi" >> MACHINE = "beaglebone" >> DISTRO= "poky" >> DISTRO_VERSION= "1.6+snapshot-20140411" >> TUNE_FEATURES = "armv7a vfp neon callconvention-hard cortexa8" >> TARGET_FPU= "vfp-neon" >> meta >> meta-yocto >> meta-yocto-bsp= "master:863cc7483f5ee43189537940de8ee5c0964d24cc" >> >> This built the kernel using SRCREV 928d7b2dda >> >> I followed the bring-up instructions from README.hadware and the >> boot failed to even start the kernel. Here's what I see: >> >> === boot log >> = >> U-Boot 2013.07 (Apr 11 2014 - 15:03:04) >> >> I2C: ready >> DRAM: 512 MiB >> WARNING: Caches not enabled >> NAND: 0 MiB >> MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 >> *** Warning - readenv() failed, using default environment >> >> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, >> SoftConn) >> musb-hdrc: MHDRC RTL version 2.0 >> musb-hdrc: setup fifo_mode 4 >> musb-hdrc: 28/31 max ep, 16384/16384 memory >> USB Peripheral mode controller at 47401000 using PIO, IRQ 0 >> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, >> SoftConn) >> musb-hdrc: MHDRC RTL version 2.0 >> musb-hdrc: setup fifo_mode 4 >> musb-hdrc: 28/31 max ep, 16384/16384 memory >> USB Host mode controller at 47401800 using PIO, IRQ 0 >> Net:not set. Validating first E-fuse MAC >> Phy not found >> PHY reset timed out >> cpsw, usb_ether >> Hit any key to stop autoboot: 0 >> mmc0 is current device >> SD/MMC found on device 0 >> reading uEnv.txt >> ** Unable to read file uEnv.txt ** >> 4981688 bytes read in 613 ms (7.7 MiB/s) >> 29192 bytes read in 46 ms (619.1 KiB/s) >> Booting from mmc ... >> ## Booting kernel from Legacy Image at 8020 ... >>Image Name: Linux-3.14.0-yocto-standard >>Image Type: ARM Linux Kernel Image (uncompressed) >>Data Size:4981624 Bytes = 4.8 MiB >>Load Address: 80008000 >>Entry Point: 80008000 >>Verifying Checksum ... OK >> ## Flattened Device Tree blob at 80f8 >>Booting using the fdt blob at 0x80f8 >>Loading Kernel Image ... OK >>Using Device Tree in place at 80f8, end 80f8a207 >> >> Starting kernel ... >> == >> >> Any ideas what I've done wrong? > > Hmm, everything looks sane. What revision is your BBB? And did you press > USER/BOOT button or erased eMMC partition per instructions? > Revision A5A, with an LCD cape Yes, I erased the eMMC before trying this. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] BBB doesn't boot
Hi Gary,
On Sun, 2014-04-13 at 03:12 -0600, Gary Thomas wrote:
> I just tried building (core-image-sato) for my BeagleBoneBlack
> using the latest Poky/Yocto master:
>
> Build Configuration:
> BB_VERSION= "1.23.0"
> BUILD_SYS = "i686-linux"
> NATIVELSBSTRING = "Fedora-13"
> TARGET_SYS= "arm-poky-linux-gnueabi"
> MACHINE = "beaglebone"
> DISTRO= "poky"
> DISTRO_VERSION= "1.6+snapshot-20140411"
> TUNE_FEATURES = "armv7a vfp neon callconvention-hard cortexa8"
> TARGET_FPU= "vfp-neon"
> meta
> meta-yocto
> meta-yocto-bsp= "master:863cc7483f5ee43189537940de8ee5c0964d24cc"
>
> This built the kernel using SRCREV 928d7b2dda
>
> I followed the bring-up instructions from README.hadware and the
> boot failed to even start the kernel. Here's what I see:
>
> === boot log
> =
> U-Boot 2013.07 (Apr 11 2014 - 15:03:04)
>
> I2C: ready
> DRAM: 512 MiB
> WARNING: Caches not enabled
> NAND: 0 MiB
> MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
> *** Warning - readenv() failed, using default environment
>
> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
> musb-hdrc: MHDRC RTL version 2.0
> musb-hdrc: setup fifo_mode 4
> musb-hdrc: 28/31 max ep, 16384/16384 memory
> USB Peripheral mode controller at 47401000 using PIO, IRQ 0
> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
> musb-hdrc: MHDRC RTL version 2.0
> musb-hdrc: setup fifo_mode 4
> musb-hdrc: 28/31 max ep, 16384/16384 memory
> USB Host mode controller at 47401800 using PIO, IRQ 0
> Net:not set. Validating first E-fuse MAC
> Phy not found
> PHY reset timed out
> cpsw, usb_ether
> Hit any key to stop autoboot: 0
> mmc0 is current device
> SD/MMC found on device 0
> reading uEnv.txt
> ** Unable to read file uEnv.txt **
> 4981688 bytes read in 613 ms (7.7 MiB/s)
> 29192 bytes read in 46 ms (619.1 KiB/s)
> Booting from mmc ...
> ## Booting kernel from Legacy Image at 8020 ...
>Image Name: Linux-3.14.0-yocto-standard
>Image Type: ARM Linux Kernel Image (uncompressed)
>Data Size:4981624 Bytes = 4.8 MiB
>Load Address: 80008000
>Entry Point: 80008000
>Verifying Checksum ... OK
> ## Flattened Device Tree blob at 80f8
>Booting using the fdt blob at 0x80f8
>Loading Kernel Image ... OK
>Using Device Tree in place at 80f8, end 80f8a207
>
> Starting kernel ...
> ==
>
> Any ideas what I've done wrong?
>
This is strange because last week I booted myself a BBB.
This actually looks like the serial doesn't output, perhaps the kernel
does boot. I wonder if console is right for the kernel cmdline.
On Friday I built and booted from
master:db80f796e78746014a0f9497638e5c6fd2953ef0 which is a bit earlier
that what you have but basically the same thing (updates for kernel
which should fix things, I've tested with SRCREV_meta_pn-linux-yocto =
"${AUTOREV}" those before they entered in master because I didn't had
HDMI output on my master commit).
I'm gonna rebuild from daisy tip and see what happens.
Cheers,
Stefan
> Thanks
>
> --
>
> Gary Thomas | Consulting for the
> MLB Associates |Embedded world
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] BBB doesn't boot
On Mon, 2014-04-14 at 10:35 +, Stanacar, StefanX wrote:
> Hi Gary,
>
> On Sun, 2014-04-13 at 03:12 -0600, Gary Thomas wrote:
> > I just tried building (core-image-sato) for my BeagleBoneBlack
> > using the latest Poky/Yocto master:
> >
> > Build Configuration:
> > BB_VERSION= "1.23.0"
> > BUILD_SYS = "i686-linux"
> > NATIVELSBSTRING = "Fedora-13"
> > TARGET_SYS= "arm-poky-linux-gnueabi"
> > MACHINE = "beaglebone"
> > DISTRO= "poky"
> > DISTRO_VERSION= "1.6+snapshot-20140411"
> > TUNE_FEATURES = "armv7a vfp neon callconvention-hard cortexa8"
> > TARGET_FPU= "vfp-neon"
> > meta
> > meta-yocto
> > meta-yocto-bsp= "master:863cc7483f5ee43189537940de8ee5c0964d24cc"
> >
> > This built the kernel using SRCREV 928d7b2dda
> >
> > I followed the bring-up instructions from README.hadware and the
> > boot failed to even start the kernel. Here's what I see:
> >
> > === boot log
> > =
> > U-Boot 2013.07 (Apr 11 2014 - 15:03:04)
> >
> > I2C: ready
> > DRAM: 512 MiB
> > WARNING: Caches not enabled
> > NAND: 0 MiB
> > MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
> > *** Warning - readenv() failed, using default environment
> >
> > musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx,
> > SoftConn)
> > musb-hdrc: MHDRC RTL version 2.0
> > musb-hdrc: setup fifo_mode 4
> > musb-hdrc: 28/31 max ep, 16384/16384 memory
> > USB Peripheral mode controller at 47401000 using PIO, IRQ 0
> > musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx,
> > SoftConn)
> > musb-hdrc: MHDRC RTL version 2.0
> > musb-hdrc: setup fifo_mode 4
> > musb-hdrc: 28/31 max ep, 16384/16384 memory
> > USB Host mode controller at 47401800 using PIO, IRQ 0
> > Net:not set. Validating first E-fuse MAC
> > Phy not found
> > PHY reset timed out
> > cpsw, usb_ether
> > Hit any key to stop autoboot: 0
> > mmc0 is current device
> > SD/MMC found on device 0
> > reading uEnv.txt
> > ** Unable to read file uEnv.txt **
> > 4981688 bytes read in 613 ms (7.7 MiB/s)
> > 29192 bytes read in 46 ms (619.1 KiB/s)
> > Booting from mmc ...
> > ## Booting kernel from Legacy Image at 8020 ...
> >Image Name: Linux-3.14.0-yocto-standard
> >Image Type: ARM Linux Kernel Image (uncompressed)
> >Data Size:4981624 Bytes = 4.8 MiB
> >Load Address: 80008000
> >Entry Point: 80008000
> >Verifying Checksum ... OK
> > ## Flattened Device Tree blob at 80f8
> >Booting using the fdt blob at 0x80f8
> >Loading Kernel Image ... OK
> >Using Device Tree in place at 80f8, end 80f8a207
> >
> > Starting kernel ...
> > ==
> >
> > Any ideas what I've done wrong?
> >
>
> This is strange because last week I booted myself a BBB.
> This actually looks like the serial doesn't output, perhaps the kernel
> does boot. I wonder if console is right for the kernel cmdline.
> On Friday I built and booted from
> master:db80f796e78746014a0f9497638e5c6fd2953ef0 which is a bit earlier
> that what you have but basically the same thing (updates for kernel
> which should fix things, I've tested with SRCREV_meta_pn-linux-yocto =
> "${AUTOREV}" those before they entered in master because I didn't had
> HDMI output on my master commit).
>
> I'm gonna rebuild from daisy tip and see what happens.
>
I just did a clean build from daisy and it worked fine...
Could you try again? And perhaps -ccleansstate for linux-yocto? I'm
thinking that somehow it didn't picked up the new console= that changed
in the machine definition.
Cheers,
Stefan
> Cheers,
> Stefan
>
>
>
>
>
>
> > Thanks
> >
> > --
> >
> > Gary Thomas | Consulting for the
> > MLB Associates |Embedded world
> >
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] BBB doesn't boot
On 2014-04-14 05:38, Stanacar, StefanX wrote:
>
>
>
> On Mon, 2014-04-14 at 10:35 +, Stanacar, StefanX wrote:
>> Hi Gary,
>>
>> On Sun, 2014-04-13 at 03:12 -0600, Gary Thomas wrote:
>>> I just tried building (core-image-sato) for my BeagleBoneBlack
>>> using the latest Poky/Yocto master:
>>>
>>> Build Configuration:
>>> BB_VERSION= "1.23.0"
>>> BUILD_SYS = "i686-linux"
>>> NATIVELSBSTRING = "Fedora-13"
>>> TARGET_SYS= "arm-poky-linux-gnueabi"
>>> MACHINE = "beaglebone"
>>> DISTRO= "poky"
>>> DISTRO_VERSION= "1.6+snapshot-20140411"
>>> TUNE_FEATURES = "armv7a vfp neon callconvention-hard cortexa8"
>>> TARGET_FPU= "vfp-neon"
>>> meta
>>> meta-yocto
>>> meta-yocto-bsp= "master:863cc7483f5ee43189537940de8ee5c0964d24cc"
>>>
>>> This built the kernel using SRCREV 928d7b2dda
>>>
>>> I followed the bring-up instructions from README.hadware and the
>>> boot failed to even start the kernel. Here's what I see:
>>>
>>> === boot log
>>> =
>>> U-Boot 2013.07 (Apr 11 2014 - 15:03:04)
>>>
>>> I2C: ready
>>> DRAM: 512 MiB
>>> WARNING: Caches not enabled
>>> NAND: 0 MiB
>>> MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
>>> *** Warning - readenv() failed, using default environment
>>>
>>> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx,
>>> SoftConn)
>>> musb-hdrc: MHDRC RTL version 2.0
>>> musb-hdrc: setup fifo_mode 4
>>> musb-hdrc: 28/31 max ep, 16384/16384 memory
>>> USB Peripheral mode controller at 47401000 using PIO, IRQ 0
>>> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx,
>>> SoftConn)
>>> musb-hdrc: MHDRC RTL version 2.0
>>> musb-hdrc: setup fifo_mode 4
>>> musb-hdrc: 28/31 max ep, 16384/16384 memory
>>> USB Host mode controller at 47401800 using PIO, IRQ 0
>>> Net:not set. Validating first E-fuse MAC
>>> Phy not found
>>> PHY reset timed out
>>> cpsw, usb_ether
>>> Hit any key to stop autoboot: 0
>>> mmc0 is current device
>>> SD/MMC found on device 0
>>> reading uEnv.txt
>>> ** Unable to read file uEnv.txt **
>>> 4981688 bytes read in 613 ms (7.7 MiB/s)
>>> 29192 bytes read in 46 ms (619.1 KiB/s)
>>> Booting from mmc ...
>>> ## Booting kernel from Legacy Image at 8020 ...
>>>Image Name: Linux-3.14.0-yocto-standard
>>>Image Type: ARM Linux Kernel Image (uncompressed)
>>>Data Size:4981624 Bytes = 4.8 MiB
>>>Load Address: 80008000
>>>Entry Point: 80008000
>>>Verifying Checksum ... OK
>>> ## Flattened Device Tree blob at 80f8
>>>Booting using the fdt blob at 0x80f8
>>>Loading Kernel Image ... OK
>>>Using Device Tree in place at 80f8, end 80f8a207
>>>
>>> Starting kernel ...
>>> ==
>>>
>>> Any ideas what I've done wrong?
>>>
>>
>> This is strange because last week I booted myself a BBB.
>> This actually looks like the serial doesn't output, perhaps the kernel
>> does boot. I wonder if console is right for the kernel cmdline.
>> On Friday I built and booted from
>> master:db80f796e78746014a0f9497638e5c6fd2953ef0 which is a bit earlier
>> that what you have but basically the same thing (updates for kernel
>> which should fix things, I've tested with SRCREV_meta_pn-linux-yocto =
>> "${AUTOREV}" those before they entered in master because I didn't had
>> HDMI output on my master commit).
>>
>> I'm gonna rebuild from daisy tip and see what happens.
>>
>
> I just did a clean build from daisy and it worked fine...
> Could you try again? And perhaps -ccleansstate for linux-yocto? I'm
> thinking that somehow it didn't picked up the new console= that changed
> in the machine definition.
I'll try daisy, but my build/test was clean from the mentioned master rev.
I checked the console setup in U-Boot:
console=ttyO0,115200n8
which I think is correct.
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] BBB doesn't boot
On 2014-04-14 05:44, Gary Thomas wrote:
> On 2014-04-14 05:38, Stanacar, StefanX wrote:
>>
>>
>>
>> On Mon, 2014-04-14 at 10:35 +, Stanacar, StefanX wrote:
>>> Hi Gary,
>>>
>>> On Sun, 2014-04-13 at 03:12 -0600, Gary Thomas wrote:
I just tried building (core-image-sato) for my BeagleBoneBlack
using the latest Poky/Yocto master:
Build Configuration:
BB_VERSION= "1.23.0"
BUILD_SYS = "i686-linux"
NATIVELSBSTRING = "Fedora-13"
TARGET_SYS= "arm-poky-linux-gnueabi"
MACHINE = "beaglebone"
DISTRO= "poky"
DISTRO_VERSION= "1.6+snapshot-20140411"
TUNE_FEATURES = "armv7a vfp neon callconvention-hard cortexa8"
TARGET_FPU= "vfp-neon"
meta
meta-yocto
meta-yocto-bsp= "master:863cc7483f5ee43189537940de8ee5c0964d24cc"
This built the kernel using SRCREV 928d7b2dda
I followed the bring-up instructions from README.hadware and the
boot failed to even start the kernel. Here's what I see:
=== boot log
=
U-Boot 2013.07 (Apr 11 2014 - 15:03:04)
I2C: ready
DRAM: 512 MiB
WARNING: Caches not enabled
NAND: 0 MiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
*** Warning - readenv() failed, using default environment
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx,
SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Peripheral mode controller at 47401000 using PIO, IRQ 0
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx,
SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Host mode controller at 47401800 using PIO, IRQ 0
Net:not set. Validating first E-fuse MAC
Phy not found
PHY reset timed out
cpsw, usb_ether
Hit any key to stop autoboot: 0
mmc0 is current device
SD/MMC found on device 0
reading uEnv.txt
** Unable to read file uEnv.txt **
4981688 bytes read in 613 ms (7.7 MiB/s)
29192 bytes read in 46 ms (619.1 KiB/s)
Booting from mmc ...
## Booting kernel from Legacy Image at 8020 ...
Image Name: Linux-3.14.0-yocto-standard
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size:4981624 Bytes = 4.8 MiB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
## Flattened Device Tree blob at 80f8
Booting using the fdt blob at 0x80f8
Loading Kernel Image ... OK
Using Device Tree in place at 80f8, end 80f8a207
Starting kernel ...
==
Any ideas what I've done wrong?
>>>
>>> This is strange because last week I booted myself a BBB.
>>> This actually looks like the serial doesn't output, perhaps the kernel
>>> does boot. I wonder if console is right for the kernel cmdline.
>>> On Friday I built and booted from
>>> master:db80f796e78746014a0f9497638e5c6fd2953ef0 which is a bit earlier
>>> that what you have but basically the same thing (updates for kernel
>>> which should fix things, I've tested with SRCREV_meta_pn-linux-yocto =
>>> "${AUTOREV}" those before they entered in master because I didn't had
>>> HDMI output on my master commit).
>>>
>>> I'm gonna rebuild from daisy tip and see what happens.
>>>
>>
>> I just did a clean build from daisy and it worked fine...
>> Could you try again? And perhaps -ccleansstate for linux-yocto? I'm
>> thinking that somehow it didn't picked up the new console= that changed
>> in the machine definition.
>
> I'll try daisy, but my build/test was clean from the mentioned master rev.
>
> I checked the console setup in U-Boot:
> console=ttyO0,115200n8
> which I think is correct.
>
Actually, I just compared my master tree with the daisy branch and
they are the same, save for the release strings, so there's no need
to rebuild.
Still at a loss though.
StefanX, perhaps you could let me try your exact image on my board?
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] openssl and heartbleed
Does the Yocto project plan to have some response to the heartbleed exploit in openssl in the near term? Has this already been addressed? Thanks, Rich -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] openssl and heartbleed
On Mon, Apr 14, 2014 at 02:37:52PM +, Richard Schmitt wrote: > Does the Yocto project plan to have some response to the heartbleed exploit > in openssl in the near term? Has this already been addressed? It was already addressed for master, daisy, dora and dylan. -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] BBB doesn't boot
On Mon, Apr 14, 2014 at 04:25:55AM -0600, Gary Thomas wrote: > On 2014-04-13 20:33, Denys Dmytriyenko wrote: > > On Sun, Apr 13, 2014 at 03:12:16AM -0600, Gary Thomas wrote: > >> I just tried building (core-image-sato) for my BeagleBoneBlack > >> using the latest Poky/Yocto master: > >> > >> Build Configuration: > >> BB_VERSION= "1.23.0" > >> BUILD_SYS = "i686-linux" > >> NATIVELSBSTRING = "Fedora-13" > >> TARGET_SYS= "arm-poky-linux-gnueabi" > >> MACHINE = "beaglebone" > >> DISTRO= "poky" > >> DISTRO_VERSION= "1.6+snapshot-20140411" > >> TUNE_FEATURES = "armv7a vfp neon callconvention-hard cortexa8" > >> TARGET_FPU= "vfp-neon" > >> meta > >> meta-yocto > >> meta-yocto-bsp= "master:863cc7483f5ee43189537940de8ee5c0964d24cc" > >> > >> This built the kernel using SRCREV 928d7b2dda > >> > >> I followed the bring-up instructions from README.hadware and the > >> boot failed to even start the kernel. Here's what I see: > >> > >> === boot log > >> = > >> U-Boot 2013.07 (Apr 11 2014 - 15:03:04) > >> > >> I2C: ready > >> DRAM: 512 MiB > >> WARNING: Caches not enabled > >> NAND: 0 MiB > >> MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 > >> *** Warning - readenv() failed, using default environment > >> > >> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, > >> SoftConn) > >> musb-hdrc: MHDRC RTL version 2.0 > >> musb-hdrc: setup fifo_mode 4 > >> musb-hdrc: 28/31 max ep, 16384/16384 memory > >> USB Peripheral mode controller at 47401000 using PIO, IRQ 0 > >> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, > >> SoftConn) > >> musb-hdrc: MHDRC RTL version 2.0 > >> musb-hdrc: setup fifo_mode 4 > >> musb-hdrc: 28/31 max ep, 16384/16384 memory > >> USB Host mode controller at 47401800 using PIO, IRQ 0 > >> Net:not set. Validating first E-fuse MAC > >> Phy not found > >> PHY reset timed out > >> cpsw, usb_ether > >> Hit any key to stop autoboot: 0 > >> mmc0 is current device > >> SD/MMC found on device 0 > >> reading uEnv.txt > >> ** Unable to read file uEnv.txt ** > >> 4981688 bytes read in 613 ms (7.7 MiB/s) > >> 29192 bytes read in 46 ms (619.1 KiB/s) > >> Booting from mmc ... > >> ## Booting kernel from Legacy Image at 8020 ... > >>Image Name: Linux-3.14.0-yocto-standard > >>Image Type: ARM Linux Kernel Image (uncompressed) > >>Data Size:4981624 Bytes = 4.8 MiB > >>Load Address: 80008000 > >>Entry Point: 80008000 > >>Verifying Checksum ... OK > >> ## Flattened Device Tree blob at 80f8 > >>Booting using the fdt blob at 0x80f8 > >>Loading Kernel Image ... OK > >>Using Device Tree in place at 80f8, end 80f8a207 > >> > >> Starting kernel ... > >> == > >> > >> Any ideas what I've done wrong? > > > > Hmm, everything looks sane. What revision is your BBB? And did you press > > USER/BOOT button or erased eMMC partition per instructions? > > > > Revision A5A, with an LCD cape Hmm, I'm wondering if LCD cape conflicts here - there's no cape support in this BSP. Can you try w/o it? As of the board revision - I was testing on different ones from A1 to A6 and didn't see any major issue... -- Denys -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] PR server doesn't always work?
I'm using a local PR server and for the most part, it works great!
No more messing about with PR and PRINC and ...
However, I have a situation where it doesn't do what I expect.
Here's my scenario:
* Build some package X
* Rebuild package database (bitbake package-index)
* Update package database on target
* Install package X on target
* Update the RRECOMMENDS_${PN} in the recipe and rebuild.
I can see that the package is updated - everything from
do_package onwards is updated.
* Rebuild package database (bitbake package-index)
* Update package database on target
* Try to install/update package X. I'm told that it is up
to date.
I can see that the package _was_ updated on the build host even
if the PR value was not changed because if I remove package X
and reinstall it, the new RRECOMMENDS_${PN} packages are also
being installed.
Am I missing something? Shouldn't this work and the PR value
be bumped by the PR server, even if all that happened was the
list of recommendations was changed?
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] New RC for 1.6.
On Thu, Apr 10, 2014 at 10:15:49PM -0700, Flanagan, Elizabeth wrote: > All, > > A few much needed bug fixes came in to fix some of the issues we saw > with rc3. We decided that we should just roll and rc4. Please begin > testing this as soon as possible. > > We're seeing one issue on the world build: > > http://autobuilder.yoctoproject.org/main/builders/nightly-world/builds/42/steps/BuildImages/logs/stdio > > but as this produces no published artifacts, I think we're ok with at > least the release artifacts. > > http://autobuilder.yoctoproject.org/pub/releases/yocto-1.6_M5.rc4 > > bitbake bb4980c63db386ce7d30d9a6b86e9f3861b3bc3a > eclipse-poky-juno 26bfc407781aa185f244a47ba63120343cee4a37 > eclipse-poky-kepler 1dfe1d2f1322b5fda8e1a7637c447b0e060efb3e > meta-fsl-arm d4316faef78ceb01ff023579e15110939ec69408 > meta-fsl-ppc c4fa1b431f4efc4982a168119db95236cfa8cad3 > meta-intel db84acfc8d9ed8dccd4a79de39fee337bc729662 > meta-minnow 7bdcd1140b729598bae6246a4bbc21c3950aadd8 > meta-qt3 3016129d90b7ac8517a5227d819f10ad417b5b45 > oecore dca1b4f073fff740364f066f6a68bb3c8697b7a6 > poky a0958261265049904fd78a2ba0198d46e5e65ea9 And the question I have is how one gets his own layers into Yocto autobuilder? -- Denys -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] BBB doesn't boot
On 2014-04-14 09:46, Denys Dmytriyenko wrote: > On Mon, Apr 14, 2014 at 04:25:55AM -0600, Gary Thomas wrote: >> On 2014-04-13 20:33, Denys Dmytriyenko wrote: >>> On Sun, Apr 13, 2014 at 03:12:16AM -0600, Gary Thomas wrote: I just tried building (core-image-sato) for my BeagleBoneBlack using the latest Poky/Yocto master: Build Configuration: BB_VERSION= "1.23.0" BUILD_SYS = "i686-linux" NATIVELSBSTRING = "Fedora-13" TARGET_SYS= "arm-poky-linux-gnueabi" MACHINE = "beaglebone" DISTRO= "poky" DISTRO_VERSION= "1.6+snapshot-20140411" TUNE_FEATURES = "armv7a vfp neon callconvention-hard cortexa8" TARGET_FPU= "vfp-neon" meta meta-yocto meta-yocto-bsp= "master:863cc7483f5ee43189537940de8ee5c0964d24cc" This built the kernel using SRCREV 928d7b2dda I followed the bring-up instructions from README.hadware and the boot failed to even start the kernel. Here's what I see: === boot log = U-Boot 2013.07 (Apr 11 2014 - 15:03:04) I2C: ready DRAM: 512 MiB WARNING: Caches not enabled NAND: 0 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 *** Warning - readenv() failed, using default environment musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Peripheral mode controller at 47401000 using PIO, IRQ 0 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Host mode controller at 47401800 using PIO, IRQ 0 Net:not set. Validating first E-fuse MAC Phy not found PHY reset timed out cpsw, usb_ether Hit any key to stop autoboot: 0 mmc0 is current device SD/MMC found on device 0 reading uEnv.txt ** Unable to read file uEnv.txt ** 4981688 bytes read in 613 ms (7.7 MiB/s) 29192 bytes read in 46 ms (619.1 KiB/s) Booting from mmc ... ## Booting kernel from Legacy Image at 8020 ... Image Name: Linux-3.14.0-yocto-standard Image Type: ARM Linux Kernel Image (uncompressed) Data Size:4981624 Bytes = 4.8 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK ## Flattened Device Tree blob at 80f8 Booting using the fdt blob at 0x80f8 Loading Kernel Image ... OK Using Device Tree in place at 80f8, end 80f8a207 Starting kernel ... == Any ideas what I've done wrong? >>> >>> Hmm, everything looks sane. What revision is your BBB? And did you press >>> USER/BOOT button or erased eMMC partition per instructions? >>> >> >> Revision A5A, with an LCD cape > > Hmm, I'm wondering if LCD cape conflicts here - there's no cape support in > this BSP. Can you try w/o it? Sure I can try it but I don't think that's it. I got the kernel that StefanX built and booted and tried it on my board and it came up. No clue why the kernels are different - ostensibly we both built the same image from the same meta data, but they are slightly different (only in size - I compared the System.map files from both builds and they contain exactly the same bits, just a few changes in memory layout which I can't explain). I'm trying another build from scratch using a different build host to see if that makes a difference. > As of the board revision - I was testing on different ones from A1 to A6 and > didn't see any major issue... > -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] BBB doesn't boot
On Mon, Apr 14, 2014 at 09:51:49AM -0600, Gary Thomas wrote: > On 2014-04-14 09:46, Denys Dmytriyenko wrote: > > On Mon, Apr 14, 2014 at 04:25:55AM -0600, Gary Thomas wrote: > >> On 2014-04-13 20:33, Denys Dmytriyenko wrote: > >>> On Sun, Apr 13, 2014 at 03:12:16AM -0600, Gary Thomas wrote: > I just tried building (core-image-sato) for my BeagleBoneBlack > using the latest Poky/Yocto master: > > Build Configuration: > BB_VERSION= "1.23.0" > BUILD_SYS = "i686-linux" > NATIVELSBSTRING = "Fedora-13" > TARGET_SYS= "arm-poky-linux-gnueabi" > MACHINE = "beaglebone" > DISTRO= "poky" > DISTRO_VERSION= "1.6+snapshot-20140411" > TUNE_FEATURES = "armv7a vfp neon callconvention-hard cortexa8" > TARGET_FPU= "vfp-neon" > meta > meta-yocto > meta-yocto-bsp= "master:863cc7483f5ee43189537940de8ee5c0964d24cc" > > This built the kernel using SRCREV 928d7b2dda > > I followed the bring-up instructions from README.hadware and the > boot failed to even start the kernel. Here's what I see: > > === boot log > = > U-Boot 2013.07 (Apr 11 2014 - 15:03:04) > > I2C: ready > DRAM: 512 MiB > WARNING: Caches not enabled > NAND: 0 MiB > MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 > *** Warning - readenv() failed, using default environment > > musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, > SoftConn) > musb-hdrc: MHDRC RTL version 2.0 > musb-hdrc: setup fifo_mode 4 > musb-hdrc: 28/31 max ep, 16384/16384 memory > USB Peripheral mode controller at 47401000 using PIO, IRQ 0 > musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, > SoftConn) > musb-hdrc: MHDRC RTL version 2.0 > musb-hdrc: setup fifo_mode 4 > musb-hdrc: 28/31 max ep, 16384/16384 memory > USB Host mode controller at 47401800 using PIO, IRQ 0 > Net:not set. Validating first E-fuse MAC > Phy not found > PHY reset timed out > cpsw, usb_ether > Hit any key to stop autoboot: 0 > mmc0 is current device > SD/MMC found on device 0 > reading uEnv.txt > ** Unable to read file uEnv.txt ** > 4981688 bytes read in 613 ms (7.7 MiB/s) > 29192 bytes read in 46 ms (619.1 KiB/s) > Booting from mmc ... > ## Booting kernel from Legacy Image at 8020 ... > Image Name: Linux-3.14.0-yocto-standard > Image Type: ARM Linux Kernel Image (uncompressed) > Data Size:4981624 Bytes = 4.8 MiB > Load Address: 80008000 > Entry Point: 80008000 > Verifying Checksum ... OK > ## Flattened Device Tree blob at 80f8 > Booting using the fdt blob at 0x80f8 > Loading Kernel Image ... OK > Using Device Tree in place at 80f8, end 80f8a207 > > Starting kernel ... > == > > Any ideas what I've done wrong? > >>> > >>> Hmm, everything looks sane. What revision is your BBB? And did you press > >>> USER/BOOT button or erased eMMC partition per instructions? > >>> > >> > >> Revision A5A, with an LCD cape > > > > Hmm, I'm wondering if LCD cape conflicts here - there's no cape support in > > this BSP. Can you try w/o it? > > Sure I can try it but I don't think that's it. I got the kernel that StefanX > built and booted and tried it on my board and it came up. No clue why the > kernels are different - ostensibly we both built the same image from the same > meta data, but they are slightly different (only in size - I compared the > System.map files from both builds and they contain exactly the same bits, > just a few changes in memory layout which I can't explain). Yeah, good point. Doesn't look like your cape causes the issue... The only other difference is in the host. Do you have access to another Linux box you can try? FWIW, I'm using 64-bit Gentoo with gcc-4.7.3. Yours is 32-bit Fedora 13, right? > I'm trying another build from scratch using a different build host to see > if that makes a difference. Do you have any other layers or customizations on top? (the metadata above suggests you build just pure Poky though) -- Denys -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] BBB doesn't boot
On 2014-04-14 10:00, Denys Dmytriyenko wrote: > On Mon, Apr 14, 2014 at 09:51:49AM -0600, Gary Thomas wrote: >> On 2014-04-14 09:46, Denys Dmytriyenko wrote: >>> On Mon, Apr 14, 2014 at 04:25:55AM -0600, Gary Thomas wrote: On 2014-04-13 20:33, Denys Dmytriyenko wrote: > On Sun, Apr 13, 2014 at 03:12:16AM -0600, Gary Thomas wrote: >> I just tried building (core-image-sato) for my BeagleBoneBlack >> using the latest Poky/Yocto master: >> >> Build Configuration: >> BB_VERSION= "1.23.0" >> BUILD_SYS = "i686-linux" >> NATIVELSBSTRING = "Fedora-13" >> TARGET_SYS= "arm-poky-linux-gnueabi" >> MACHINE = "beaglebone" >> DISTRO= "poky" >> DISTRO_VERSION= "1.6+snapshot-20140411" >> TUNE_FEATURES = "armv7a vfp neon callconvention-hard cortexa8" >> TARGET_FPU= "vfp-neon" >> meta >> meta-yocto >> meta-yocto-bsp= "master:863cc7483f5ee43189537940de8ee5c0964d24cc" >> >> This built the kernel using SRCREV 928d7b2dda >> >> I followed the bring-up instructions from README.hadware and the >> boot failed to even start the kernel. Here's what I see: >> >> === boot log >> = >> U-Boot 2013.07 (Apr 11 2014 - 15:03:04) >> >> I2C: ready >> DRAM: 512 MiB >> WARNING: Caches not enabled >> NAND: 0 MiB >> MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 >> *** Warning - readenv() failed, using default environment >> >> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, >> SoftConn) >> musb-hdrc: MHDRC RTL version 2.0 >> musb-hdrc: setup fifo_mode 4 >> musb-hdrc: 28/31 max ep, 16384/16384 memory >> USB Peripheral mode controller at 47401000 using PIO, IRQ 0 >> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, >> SoftConn) >> musb-hdrc: MHDRC RTL version 2.0 >> musb-hdrc: setup fifo_mode 4 >> musb-hdrc: 28/31 max ep, 16384/16384 memory >> USB Host mode controller at 47401800 using PIO, IRQ 0 >> Net:not set. Validating first E-fuse MAC >> Phy not found >> PHY reset timed out >> cpsw, usb_ether >> Hit any key to stop autoboot: 0 >> mmc0 is current device >> SD/MMC found on device 0 >> reading uEnv.txt >> ** Unable to read file uEnv.txt ** >> 4981688 bytes read in 613 ms (7.7 MiB/s) >> 29192 bytes read in 46 ms (619.1 KiB/s) >> Booting from mmc ... >> ## Booting kernel from Legacy Image at 8020 ... >>Image Name: Linux-3.14.0-yocto-standard >>Image Type: ARM Linux Kernel Image (uncompressed) >>Data Size:4981624 Bytes = 4.8 MiB >>Load Address: 80008000 >>Entry Point: 80008000 >>Verifying Checksum ... OK >> ## Flattened Device Tree blob at 80f8 >>Booting using the fdt blob at 0x80f8 >>Loading Kernel Image ... OK >>Using Device Tree in place at 80f8, end 80f8a207 >> >> Starting kernel ... >> == >> >> Any ideas what I've done wrong? > > Hmm, everything looks sane. What revision is your BBB? And did you press > USER/BOOT button or erased eMMC partition per instructions? > Revision A5A, with an LCD cape >>> >>> Hmm, I'm wondering if LCD cape conflicts here - there's no cape support in >>> this BSP. Can you try w/o it? >> >> Sure I can try it but I don't think that's it. I got the kernel that StefanX >> built and booted and tried it on my board and it came up. No clue why the >> kernels are different - ostensibly we both built the same image from the same >> meta data, but they are slightly different (only in size - I compared the >> System.map files from both builds and they contain exactly the same bits, >> just a few changes in memory layout which I can't explain). > > Yeah, good point. Doesn't look like your cape causes the issue... > The only other difference is in the host. Do you have access to another Linux > box you can try? FWIW, I'm using 64-bit Gentoo with gcc-4.7.3. Yours is > 32-bit > Fedora 13, right? I'll try Fedora 17 and Ubuntu 12.04 (x86_64) and see what happens. Note: I use the Fedora 13 system *all* the time for my other Poky/Yocto builds. > >> I'm trying another build from scratch using a different build host to see >> if that makes a difference. > > Do you have any other layers or customizations on top? (the metadata above > suggests you build just pure Poky though) I was trying this on a pure Poky/Yocto build. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ___
Re: [yocto] BBB doesn't boot
On Mon, Apr 14, 2014 at 10:04:41AM -0600, Gary Thomas wrote: > On 2014-04-14 10:00, Denys Dmytriyenko wrote: > > On Mon, Apr 14, 2014 at 09:51:49AM -0600, Gary Thomas wrote: > >> On 2014-04-14 09:46, Denys Dmytriyenko wrote: > >>> On Mon, Apr 14, 2014 at 04:25:55AM -0600, Gary Thomas wrote: > On 2014-04-13 20:33, Denys Dmytriyenko wrote: > > On Sun, Apr 13, 2014 at 03:12:16AM -0600, Gary Thomas wrote: > >> I just tried building (core-image-sato) for my BeagleBoneBlack > >> using the latest Poky/Yocto master: > >> > >> Build Configuration: > >> BB_VERSION= "1.23.0" > >> BUILD_SYS = "i686-linux" > >> NATIVELSBSTRING = "Fedora-13" > >> TARGET_SYS= "arm-poky-linux-gnueabi" > >> MACHINE = "beaglebone" > >> DISTRO= "poky" > >> DISTRO_VERSION= "1.6+snapshot-20140411" > >> TUNE_FEATURES = "armv7a vfp neon callconvention-hard cortexa8" > >> TARGET_FPU= "vfp-neon" > >> meta > >> meta-yocto > >> meta-yocto-bsp= "master:863cc7483f5ee43189537940de8ee5c0964d24cc" > >> > >> This built the kernel using SRCREV 928d7b2dda > >> > >> I followed the bring-up instructions from README.hadware and the > >> boot failed to even start the kernel. Here's what I see: > >> > >> === boot log > >> = > >> U-Boot 2013.07 (Apr 11 2014 - 15:03:04) > >> > >> I2C: ready > >> DRAM: 512 MiB > >> WARNING: Caches not enabled > >> NAND: 0 MiB > >> MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 > >> *** Warning - readenv() failed, using default environment > >> > >> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, > >> SoftConn) > >> musb-hdrc: MHDRC RTL version 2.0 > >> musb-hdrc: setup fifo_mode 4 > >> musb-hdrc: 28/31 max ep, 16384/16384 memory > >> USB Peripheral mode controller at 47401000 using PIO, IRQ 0 > >> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, > >> SoftConn) > >> musb-hdrc: MHDRC RTL version 2.0 > >> musb-hdrc: setup fifo_mode 4 > >> musb-hdrc: 28/31 max ep, 16384/16384 memory > >> USB Host mode controller at 47401800 using PIO, IRQ 0 > >> Net:not set. Validating first E-fuse MAC > >> Phy not found > >> PHY reset timed out > >> cpsw, usb_ether > >> Hit any key to stop autoboot: 0 > >> mmc0 is current device > >> SD/MMC found on device 0 > >> reading uEnv.txt > >> ** Unable to read file uEnv.txt ** > >> 4981688 bytes read in 613 ms (7.7 MiB/s) > >> 29192 bytes read in 46 ms (619.1 KiB/s) > >> Booting from mmc ... > >> ## Booting kernel from Legacy Image at 8020 ... > >>Image Name: Linux-3.14.0-yocto-standard > >>Image Type: ARM Linux Kernel Image (uncompressed) > >>Data Size:4981624 Bytes = 4.8 MiB > >>Load Address: 80008000 > >>Entry Point: 80008000 > >>Verifying Checksum ... OK > >> ## Flattened Device Tree blob at 80f8 > >>Booting using the fdt blob at 0x80f8 > >>Loading Kernel Image ... OK > >>Using Device Tree in place at 80f8, end 80f8a207 > >> > >> Starting kernel ... > >> == > >> > >> Any ideas what I've done wrong? > > > > Hmm, everything looks sane. What revision is your BBB? And did you > > press > > USER/BOOT button or erased eMMC partition per instructions? > > > > Revision A5A, with an LCD cape > >>> > >>> Hmm, I'm wondering if LCD cape conflicts here - there's no cape support > >>> in > >>> this BSP. Can you try w/o it? > >> > >> Sure I can try it but I don't think that's it. I got the kernel that > >> StefanX > >> built and booted and tried it on my board and it came up. No clue why the > >> kernels are different - ostensibly we both built the same image from the > >> same > >> meta data, but they are slightly different (only in size - I compared the > >> System.map files from both builds and they contain exactly the same bits, > >> just a few changes in memory layout which I can't explain). > > > > Yeah, good point. Doesn't look like your cape causes the issue... > > The only other difference is in the host. Do you have access to another > > Linux > > box you can try? FWIW, I'm using 64-bit Gentoo with gcc-4.7.3. Yours is > > 32-bit > > Fedora 13, right? > > I'll try Fedora 17 and Ubuntu 12.04 (x86_64) and see what happens. > > Note: I use the Fedora 13 system *all* the time for my other Poky/Yocto > builds. Yeah, it usually shouldn't matter, as OE is very good at isolating host differences. But at this point we need to eliminate every variable... > >> I'm trying another build from scratch using a different build host to see > >> if that makes a differen
Re: [yocto] openssl and heartbleed
On Monday 14 April 2014 16:41:21 Martin Jansa wrote: > On Mon, Apr 14, 2014 at 02:37:52PM +, Richard Schmitt wrote: > > Does the Yocto project plan to have some response to the heartbleed > > exploit in openssl in the near term? Has this already been addressed? > > It was already addressed for master, daisy, dora and dylan. Specifically, for master and daisy (what will be the 1.6 release), OpenSSL was upgraded to 1.0.1g which includes the fix. For dora (1.5) and dylan (1.4) branches, the specific fix was backported as a patch on top of 1.0.1e. We haven't yet had a point release of 1.4 or 1.5 that includes the fix. At this point given the nature of our project, I'm not sure if we would rush to do one. It's certainly likely we will have a 1.5 point release in the near future though. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] New RC for 1.6.
On Mon, Apr 14, 2014 at 1:29 AM, Stanacar, StefanX wrote: > Hi Beth, > > There are some artifacts missing for beaglebone, the .dtb files. > rc3 had them... This is only a problem for minimal images, all the > others don't need the dtb files, but they should be there nevertheless > (between rc3 and rc4 kernel image type changed from zImage to uImage > fwiw, so the dtb file changed name too, as in > uImage-am335x-boneblack.dtb) > Ok, pushing a fix to the AB. I'll move these over by hand if the build directory still exists (it should). If not, I'll rebuild. Should be there in a few moments. -b > > Cheers, > Stefan > > On Thu, 2014-04-10 at 22:15 -0700, Flanagan, Elizabeth wrote: >> All, >> >> A few much needed bug fixes came in to fix some of the issues we saw >> with rc3. We decided that we should just roll and rc4. Please begin >> testing this as soon as possible. >> >> We're seeing one issue on the world build: >> >> http://autobuilder.yoctoproject.org/main/builders/nightly-world/builds/42/steps/BuildImages/logs/stdio >> >> but as this produces no published artifacts, I think we're ok with at >> least the release artifacts. >> >> http://autobuilder.yoctoproject.org/pub/releases/yocto-1.6_M5.rc4 >> >> bitbake bb4980c63db386ce7d30d9a6b86e9f3861b3bc3a >> eclipse-poky-juno 26bfc407781aa185f244a47ba63120343cee4a37 >> eclipse-poky-kepler 1dfe1d2f1322b5fda8e1a7637c447b0e060efb3e >> meta-fsl-arm d4316faef78ceb01ff023579e15110939ec69408 >> meta-fsl-ppc c4fa1b431f4efc4982a168119db95236cfa8cad3 >> meta-intel db84acfc8d9ed8dccd4a79de39fee337bc729662 >> meta-minnow 7bdcd1140b729598bae6246a4bbc21c3950aadd8 >> meta-qt3 3016129d90b7ac8517a5227d819f10ad417b5b45 >> oecore dca1b4f073fff740364f066f6a68bb3c8697b7a6 >> poky a0958261265049904fd78a2ba0198d46e5e65ea9 >> >> >> -- >> Elizabeth Flanagan >> Yocto Project >> Build and Release > -- Elizabeth Flanagan Yocto Project Build and Release -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] New RC for 1.6.
Hi Denys > And the question I have is how one gets his own layers into Yocto > autobuilder? This question has both political and technical answers. On the technical side, the layer would at least need to: - have YP Compatible status - provide an owner (human) - provide a QA resource (could be the same human) - help support the costs of QA There may be other requirements, and details on some of these issues are still under discussion. If there is a layer you'd like to discuss, let me know and I'll set up a meeting with the appropriate people. -- Jeff Osier-Mixon @Intel Yocto Project Community Manager http://yoctoproject.org -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] BBB doesn't boot
On 2014-04-14 10:08, Denys Dmytriyenko wrote: > On Mon, Apr 14, 2014 at 10:04:41AM -0600, Gary Thomas wrote: >> On 2014-04-14 10:00, Denys Dmytriyenko wrote: >>> On Mon, Apr 14, 2014 at 09:51:49AM -0600, Gary Thomas wrote: On 2014-04-14 09:46, Denys Dmytriyenko wrote: > On Mon, Apr 14, 2014 at 04:25:55AM -0600, Gary Thomas wrote: >> On 2014-04-13 20:33, Denys Dmytriyenko wrote: >>> On Sun, Apr 13, 2014 at 03:12:16AM -0600, Gary Thomas wrote: I just tried building (core-image-sato) for my BeagleBoneBlack using the latest Poky/Yocto master: Build Configuration: BB_VERSION= "1.23.0" BUILD_SYS = "i686-linux" NATIVELSBSTRING = "Fedora-13" TARGET_SYS= "arm-poky-linux-gnueabi" MACHINE = "beaglebone" DISTRO= "poky" DISTRO_VERSION= "1.6+snapshot-20140411" TUNE_FEATURES = "armv7a vfp neon callconvention-hard cortexa8" TARGET_FPU= "vfp-neon" meta meta-yocto meta-yocto-bsp= "master:863cc7483f5ee43189537940de8ee5c0964d24cc" This built the kernel using SRCREV 928d7b2dda I followed the bring-up instructions from README.hadware and the boot failed to even start the kernel. Here's what I see: === boot log = U-Boot 2013.07 (Apr 11 2014 - 15:03:04) I2C: ready DRAM: 512 MiB WARNING: Caches not enabled NAND: 0 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 *** Warning - readenv() failed, using default environment musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Peripheral mode controller at 47401000 using PIO, IRQ 0 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Host mode controller at 47401800 using PIO, IRQ 0 Net:not set. Validating first E-fuse MAC Phy not found PHY reset timed out cpsw, usb_ether Hit any key to stop autoboot: 0 mmc0 is current device SD/MMC found on device 0 reading uEnv.txt ** Unable to read file uEnv.txt ** 4981688 bytes read in 613 ms (7.7 MiB/s) 29192 bytes read in 46 ms (619.1 KiB/s) Booting from mmc ... ## Booting kernel from Legacy Image at 8020 ... Image Name: Linux-3.14.0-yocto-standard Image Type: ARM Linux Kernel Image (uncompressed) Data Size:4981624 Bytes = 4.8 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK ## Flattened Device Tree blob at 80f8 Booting using the fdt blob at 0x80f8 Loading Kernel Image ... OK Using Device Tree in place at 80f8, end 80f8a207 Starting kernel ... == Any ideas what I've done wrong? >>> >>> Hmm, everything looks sane. What revision is your BBB? And did you >>> press >>> USER/BOOT button or erased eMMC partition per instructions? >>> >> >> Revision A5A, with an LCD cape > > Hmm, I'm wondering if LCD cape conflicts here - there's no cape support > in > this BSP. Can you try w/o it? Sure I can try it but I don't think that's it. I got the kernel that StefanX built and booted and tried it on my board and it came up. No clue why the kernels are different - ostensibly we both built the same image from the same meta data, but they are slightly different (only in size - I compared the System.map files from both builds and they contain exactly the same bits, just a few changes in memory layout which I can't explain). >>> >>> Yeah, good point. Doesn't look like your cape causes the issue... >>> The only other difference is in the host. Do you have access to another >>> Linux >>> box you can try? FWIW, I'm using 64-bit Gentoo with gcc-4.7.3. Yours is >>> 32-bit >>> Fedora 13, right? >> >> I'll try Fedora 17 and Ubuntu 12.04 (x86_64) and see what happens. >> >> Note: I use the Fedora 13 system *all* the time for my other Poky/Yocto >> builds. > > Yeah, it usually shouldn't matter, as OE is very good at isolating host > differences. But at this point we need to eliminate every variable... > > I'm trying another build from scratch usin
Re: [yocto] BBB doesn't boot
On Mon, Apr 14, 2014 at 02:11:05PM -0600, Gary Thomas wrote: > Very interesting results! These are the results from the build hosts I have: > Fedora 13 (i686) - fails > Fedora 17 (i686) - fails > Ubuntu 12.04 (x86_64) - boots Interesting indeed. I have no idea what's so special about Fedora host - this is the first time I hear about issues with it. I may try experimenting with different VMs once I have more time... > Note that I routinely build for other targets (which does imply other, mostly > older, kernels) using all of these machines with no differences based on the > build host. Same here - building for different targets with different kernels from meta-ti and on 32 and 64 bit hosts and never had an issue like that... > I don't know what's unique about an x86_64 host, but it does seem to work. > > I was trying this to see how the stock Yocto support for the BBB competes with > building using meta-beaglebone which I've been using successfully. Based on > these results, I'll be sticking with the meta-beaglebone approach for now > (not just for the booting issue, but support for my LCD cape and other things > that aren't there in the Yocto kernel) This is not a "Yocto" kernel, this is a vanilla mainline 3.14 kernel (as a successor to 3.12 work done in meta-ti). Indeed, cape support is missing, as it is still not merged upstream, going through numerous iterations... The point of meta-beagleboard was to work on cape support and such, with the goal to upstream it, while meta-ti kept on working on SoC and peripheral support. Due to different circumstances, meta-beagleboard still uses 3.8 kernel. Once it is accepted upstream, it will be part of the mainline kernel and one of the later versions of the Yocto Project reference BSP. -- Denys -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] BBB doesn't boot
On Mon, 2014-04-14 at 18:44 -0400, Denys Dmytriyenko wrote: > On Mon, Apr 14, 2014 at 02:11:05PM -0600, Gary Thomas wrote: > > Very interesting results! These are the results from the build hosts I > > have: > > Fedora 13 (i686) - fails > > Fedora 17 (i686) - fails > > Ubuntu 12.04 (x86_64) - boots > > Interesting indeed. I have no idea what's so special about Fedora host - this > is the first time I hear about issues with it. I may try experimenting with > different VMs once I have more time... I've been having a look at this. The biggest differences I can find between working and non working builds is the path length to the build directory for the kernel. This is from comparing vmlinux files from working and non working builds. Works: /home/paul/poky/build/tmp/work/beaglebone-poky-linux-gnueabi Doesn't Work: /media/data1/build1/poky/build/tmp/work/beaglebone-poky-linux-gnueabi I also have been wondering if the version strings may be making a difference. http://dan.rpsys.net/uImage-rp2 is a uImage from a broken build where I truncated the path length to a "working" build path length and patched in the same version strings: const char linux_banner[] = "Linux version 3.14.0-yocto-standard (paul@ubuntu-build01) (gcc version 4.8.2 (GCC) ) #1 PREEMPT Mon Apr 14 16:00:52 BST 2014\n"; const char linux_proc_banner[] = "%s version %s (paul@ubuntu-build01) (gcc version 4.8.2 (GCC) ) %s\n"; to init/version.c. I don't have hardware and would be interested to know if the kernel linked to above works or not. If it doesn't, it rules out these path and string lengths, if it does work, it points to a problem there. Cheers, Richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] OEDAM Food Planning
The Yocto Project is going to provide Lunch (Friday/Saturday) and dinner on Friday. http://www.openembedded.org/wiki/OEDAM Please let Jefro know if you plan to skip a meal so he an plan accordingly. Also, if you are planning to attend and have not listed yourself, please do so, or let Jefro kknow so he has a good headcount. Especially for Friday nights dinner. Thanks, Philip -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] BBB doesn't boot
On Tue, Apr 15, 2014 at 01:20:03AM +0100, Richard Purdie wrote: > On Mon, 2014-04-14 at 18:44 -0400, Denys Dmytriyenko wrote: > > On Mon, Apr 14, 2014 at 02:11:05PM -0600, Gary Thomas wrote: > > > Very interesting results! These are the results from the build hosts I > > > have: > > > Fedora 13 (i686) - fails > > > Fedora 17 (i686) - fails > > > Ubuntu 12.04 (x86_64) - boots > > > > Interesting indeed. I have no idea what's so special about Fedora host - > > this > > is the first time I hear about issues with it. I may try experimenting with > > different VMs once I have more time... > > I've been having a look at this. The biggest differences I can find > between working and non working builds is the path length to the build > directory for the kernel. This is from comparing vmlinux files from > working and non working builds. > > Works: > /home/paul/poky/build/tmp/work/beaglebone-poky-linux-gnueabi > > Doesn't Work: > /media/data1/build1/poky/build/tmp/work/beaglebone-poky-linux-gnueabi > > I also have been wondering if the version strings may be making a > difference. > > http://dan.rpsys.net/uImage-rp2 is a uImage from a broken build where I > truncated the path length to a "working" build path length and patched > in the same version strings: > > const char linux_banner[] = >"Linux version 3.14.0-yocto-standard (paul@ubuntu-build01) (gcc > version 4.8.2 (GCC) ) #1 PREEMPT Mon Apr 14 16:00:52 BST 2014\n"; > > const char linux_proc_banner[] = "%s version %s (paul@ubuntu-build01) > (gcc version 4.8.2 (GCC) ) %s\n"; > > to init/version.c. > > I don't have hardware and would be interested to know if the kernel > linked to above works or not. If it doesn't, it rules out these path and > string lengths, if it does work, it points to a problem there. Richard, Good catch! It boots: U-Boot SPL 2013.07 (Apr 10 2014 - 04:47:32) musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Peripheral mode controller at 47401000 using PIO, IRQ 0 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Host mode controller at 47401800 using PIO, IRQ 0 OMAP SD/MMC: 0 reading args spl: error reading image args, err - -1 reading u-boot.img reading u-boot.img U-Boot 2013.07 (Apr 10 2014 - 04:47:32) I2C: ready DRAM: 512 MiB WARNING: Caches not enabled NAND: 0 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 *** Warning - readenv() failed, using default environment musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Peripheral mode controller at 47401000 using PIO, IRQ 0 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Host mode controller at 47401800 using PIO, IRQ 0 Net:not set. Validating first E-fuse MAC cpsw, usb_ether Hit any key to stop autoboot: 0 mmc0 is current device SD/MMC found on device 0 reading uEnv.txt ** Unable to read file uEnv.txt ** 4985376 bytes read in 853 ms (5.6 MiB/s) 29192 bytes read in 28 ms (1017.6 KiB/s) Booting from mmc ... ## Booting kernel from Legacy Image at 8020 ... Image Name: Linux-3.14.0-yocto-standard Image Type: ARM Linux Kernel Image (uncompressed) Data Size:4985312 Bytes = 4.8 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK ## Flattened Device Tree blob at 80f8 Booting using the fdt blob at 0x80f8 Loading Kernel Image ... OK Using Device Tree in place at 80f8, end 80f8a207 Starting kernel ... Booting Linux on physical CPU 0x0 Initializing cgroup subsys cpuset Initializing cgroup subsys cpu Initializing cgroup subsys cpuacct Linux version 3.14.0-yocto-standard (paul@ubuntu-build01) (gcc version 4.8.2 (GCC) ) #1 PREEMPT Mon Apr 14 16:00:52 BST 2014 CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache Machine model: TI AM335x BeagleBone cma: CMA: reserved 16 MiB at 9e80 Memory policy: Data cache writeback CPU: All CPU(s) started in SVC mode. AM335X ES2.0 (sgx neon ) Built 1 zonelists in Zone order, mobility grouping on. Total pages: 129792 Kernel command line: console=ttyO0,115200n8 root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait PID hash table entries: 2048 (order: 1, 8192 bytes) Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) allocated 1048576 bytes of page_cgroup please try 'cgroup_disable=memory' option if you don't want memory cgroups Memory: 489452K/523264K avail
Re: [yocto] BBB doesn't boot
On Mon, 2014-04-14 at 21:38 -0400, Denys Dmytriyenko wrote: > On Tue, Apr 15, 2014 at 01:20:03AM +0100, Richard Purdie wrote: > > On Mon, 2014-04-14 at 18:44 -0400, Denys Dmytriyenko wrote: > > > On Mon, Apr 14, 2014 at 02:11:05PM -0600, Gary Thomas wrote: > > > > Very interesting results! These are the results from the build hosts I > > > > have: > > > > Fedora 13 (i686) - fails > > > > Fedora 17 (i686) - fails > > > > Ubuntu 12.04 (x86_64) - boots > > > > > > Interesting indeed. I have no idea what's so special about Fedora host - > > > this > > > is the first time I hear about issues with it. I may try experimenting > > > with > > > different VMs once I have more time... > > > > I've been having a look at this. The biggest differences I can find > > between working and non working builds is the path length to the build > > directory for the kernel. This is from comparing vmlinux files from > > working and non working builds. > > > > Works: > > /home/paul/poky/build/tmp/work/beaglebone-poky-linux-gnueabi > > > > Doesn't Work: > > /media/data1/build1/poky/build/tmp/work/beaglebone-poky-linux-gnueabi > > > > I also have been wondering if the version strings may be making a > > difference. > > > > http://dan.rpsys.net/uImage-rp2 is a uImage from a broken build where I > > truncated the path length to a "working" build path length and patched > > in the same version strings: > > > > const char linux_banner[] = > >"Linux version 3.14.0-yocto-standard (paul@ubuntu-build01) (gcc > > version 4.8.2 (GCC) ) #1 PREEMPT Mon Apr 14 16:00:52 BST 2014\n"; > > > > const char linux_proc_banner[] = "%s version %s (paul@ubuntu-build01) > > (gcc version 4.8.2 (GCC) ) %s\n"; > > > > to init/version.c. > > > > I don't have hardware and would be interested to know if the kernel > > linked to above works or not. If it doesn't, it rules out these path and > > string lengths, if it does work, it points to a problem there. > > Richard, > > Good catch! It boots: Thanks Denys, this helps narrow down the issue. I've shared http://dan.rpsys.net/uImage-rp3 which is the same as the last one but with my changes to version.c reverted. The one should tell us if its the paths or the strings. I'm guessing the path problem is more likely but anything is possible. This is starting to look like some kind of compiler or linker issue. If it is that, it would help to have more data points about what works and what doesn't. With that in mind could people who have good or bad builds please share the paths they built the kernels in so we can see if we can spot some kind of pattern. Cheers, Richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Help-Gstreamer Vaapi Plugin Issue in 1080p mp4 playback
Hi. I hope someone can help me with my questions. We have built following Gst packages in Ubuntu 13.04 gstreamer-1.2.3 gst-plugins-base-1.2.3 gst-plugins-good-1.2.3 gst-plugins-bad-1.2.3 gst-plugins-ugly-1.2.3 gst-libav-1.2.3 libva-1.3.0 libva-intel-driver-1.3.0 gstreamer-vaapi-0.5.8 Our objective is to build gst-1.2.3 with latest vaapi support. On the way we have installed all other dependencies. We have wrote an application(App1) to create a QT video widget and hence have the window id. QWidget window; window.resize(1920, 1080); window.show(); WId xwinid = window.winId(); And another application (app2) to create gst-video pipe (filesrc-> qtdemux-> vaapidecode-> vaapisink) to test video overlay, where we are using following videooverlay api to test the foreign window, gst_video_overlay_set_window_handle(GST_VIDEO_OVERLAY(vaapisink), aWindowId); And App1 is sending wid to App2 through D-Bus. Now Vaapi able to set the foreign window however, there is some troubling behaviors in vaapisink side. a. First gst_video_overlay_set_window_handle to set the foreign window. b. Play the pipe for some time (It works with foreign window) and Stop. c. Second time Play, vaapisink creates its own window. d. Stop the pipe. e. Call gst_video_overlay_set_window_handle to set the foreign window again. f. Start the pipe (It works with foreign window). So instead of rending to the foreign window why vaapisink is creating its own window in all 2nd attempts to play? Some time we are getting the following core dump while setting the windowid Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb7900b40 (LWP 24910)] 0xb6109d8f in glXMakeCurrentReadSGI () from /usr/lib/i386-linux-gnu/mesa/libGL.so.1 (gdb) bt #0 0xb6109d8f in glXMakeCurrentReadSGI () from /usr/lib/i386-linux-gnu/mesa/libGL.so.1 #1 0xb6109f13 in glXMakeCurrent () from /usr/lib/i386-linux-gnu/mesa/libGL.so.1 #2 0xb645c994 in gl_set_current_context (new_cs=0xb78ff64c, old_cs=0x0) at gstvaapiutils_glx.c:450 #3 0xb645e728 in gst_vaapi_window_glx_ensure_context (window=0xb6f14800, foreign_context=) at gstvaapiwindow_glx.c:217 #4 gst_vaapi_window_glx_ensure_context (window=0xb6f14800, foreign_context=) at gstvaapiwindow_glx.c:185 #5 0xb645e986 in gst_vaapi_window_glx_new_with_xid ( display=display@entry=0xb6f0f8e8, xid=xid@entry=62914566) at gstvaapiwindow_glx.c:413 #6 0xb648f72b in gst_vaapisink_ensure_window_xid (window_id=62914566, sink=0xb6319000) at gstvaapisink.c:553 #7 gst_vaapisink_video_overlay_set_window_handle (overlay=0xb6319000, window=62914566) at gstvaapisink.c:179 #8 0xb7cd11a7 in gst_video_overlay_set_window_handle (overlay=0xb6319000, handle=62914566) at videooverlay.c:357 BTW, is there any way to test this scenario (setting the foreign window) with gst- commands only, which will remove our application overhead? Thanks in advance, Meena From: Beauchesne, Gwenole [gwenole.beauche...@intel.com] Sent: Thursday, April 03, 2014 8:22 PM To: Meenakumari Shedole; yocto@yoctoproject.org Cc: Dipesh Karmakar Subject: RE: [yocto] Help-Gstreamer Vaapi Plugin Issue in 1080p mp4 playback Hi, > I have checked vaapisink source, it seems its supporting overlay on foreign X > window. > https://gitorious.org/vaapi/gstreamer- > vaapi/source/643d35e87a67376af9cd89cd868666368b105ac3:gst/vaapisink/gs > tvaapisink.c > static gboolean gst_vaapisink_implements_interface_supported(); > static gboolean gst_vaapisink_ensure_window_xid(); The version you mention looks very old. I have integrated a fix from another user, who has been successfully using gstreamer-vaapi with GStreamer 0.10 in a scenario you describe (vaapisink + foreign window). Please update your gstreamer-vaapi version to at least 0.5.8. Or, the current git master tree. Other branches are not maintained any more. The fix I have in mind was f8666e2. Regards, Gwenole. > -Original Message- > From: Burton, Ross [mailto:ross.bur...@intel.com] > Sent: Friday, March 28, 2014 4:42 PM > To: Meenakumari Shedole > Cc: yocto@yoctoproject.org; Dipesh Karmakar > Subject: Re: [yocto] Help-Gstreamer Vaapi Plugin Issue in 1080p mp4 > playback > > On 28 March 2014 06:05, Meenakumari Shedole > wrote: > > 1. playbin2 + avi/3gp is working properly because of xvimagesink is used > interally. > > 2. playbin2 + mp4 is not taking vaapi sink, we need to manually set video- > sink=vaapisink. > >Also we are getting arbitrary crash while setting the qml video window id > to the vaapi sink. > >So we are not getting any single pipe to play mp4/avi/3gp stuff. > > The important question is what recipe are you using to get the vaapi > elements? > > What happens if you use vaapisink with AVI/3GP? You should still get some > acceleration. > > Note that especially when using vaapi sink you need to wait for the sink to > create the window and then reparent it, you can
Re: [yocto] BBB doesn't boot
On Tue, Apr 15, 2014 at 05:44:04AM +0100, Richard Purdie wrote: > On Mon, 2014-04-14 at 21:38 -0400, Denys Dmytriyenko wrote: > > On Tue, Apr 15, 2014 at 01:20:03AM +0100, Richard Purdie wrote: > > > On Mon, 2014-04-14 at 18:44 -0400, Denys Dmytriyenko wrote: > > > > On Mon, Apr 14, 2014 at 02:11:05PM -0600, Gary Thomas wrote: > > > > > Very interesting results! These are the results from the build hosts > > > > > I have: > > > > > Fedora 13 (i686) - fails > > > > > Fedora 17 (i686) - fails > > > > > Ubuntu 12.04 (x86_64) - boots > > > > > > > > Interesting indeed. I have no idea what's so special about Fedora host > > > > - this > > > > is the first time I hear about issues with it. I may try experimenting > > > > with > > > > different VMs once I have more time... > > > > > > I've been having a look at this. The biggest differences I can find > > > between working and non working builds is the path length to the build > > > directory for the kernel. This is from comparing vmlinux files from > > > working and non working builds. > > > > > > Works: > > > /home/paul/poky/build/tmp/work/beaglebone-poky-linux-gnueabi > > > > > > Doesn't Work: > > > /media/data1/build1/poky/build/tmp/work/beaglebone-poky-linux-gnueabi > > > > > > I also have been wondering if the version strings may be making a > > > difference. > > > > > > http://dan.rpsys.net/uImage-rp2 is a uImage from a broken build where I > > > truncated the path length to a "working" build path length and patched > > > in the same version strings: > > > > > > const char linux_banner[] = > > >"Linux version 3.14.0-yocto-standard (paul@ubuntu-build01) (gcc > > > version 4.8.2 (GCC) ) #1 PREEMPT Mon Apr 14 16:00:52 BST 2014\n"; > > > > > > const char linux_proc_banner[] = "%s version %s (paul@ubuntu-build01) > > > (gcc version 4.8.2 (GCC) ) %s\n"; > > > > > > to init/version.c. > > > > > > I don't have hardware and would be interested to know if the kernel > > > linked to above works or not. If it doesn't, it rules out these path and > > > string lengths, if it does work, it points to a problem there. > > > > Richard, > > > > Good catch! It boots: > > Thanks Denys, this helps narrow down the issue. I've shared > http://dan.rpsys.net/uImage-rp3 which is the same as the last one but > with my changes to version.c reverted. The one should tell us if its the > paths or the strings. This one also boots for me: Linux version 3.14.0-yocto-standard (richard@ted) (gcc version 4.8.2 (GCC) ) #2 PREEMPT Tue Apr 15 05:40:19 IST 2014 > I'm guessing the path problem is more likely but anything is possible. > This is starting to look like some kind of compiler or linker issue. If > it is that, it would help to have more data points about what works and > what doesn't. With that in mind could people who have good or bad builds > please share the paths they built the kernels in so we can see if we can > spot some kind of pattern. > > Cheers, > > Richard > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] BBB doesn't boot
On Tue, Apr 15, 2014 at 01:07:28AM -0400, Denys Dmytriyenko wrote: > On Tue, Apr 15, 2014 at 05:44:04AM +0100, Richard Purdie wrote: > > On Mon, 2014-04-14 at 21:38 -0400, Denys Dmytriyenko wrote: > > > On Tue, Apr 15, 2014 at 01:20:03AM +0100, Richard Purdie wrote: > > > > On Mon, 2014-04-14 at 18:44 -0400, Denys Dmytriyenko wrote: > > > > > On Mon, Apr 14, 2014 at 02:11:05PM -0600, Gary Thomas wrote: > > > > > > Very interesting results! These are the results from the build > > > > > > hosts I have: > > > > > > Fedora 13 (i686) - fails > > > > > > Fedora 17 (i686) - fails > > > > > > Ubuntu 12.04 (x86_64) - boots > > > > > > > > > > Interesting indeed. I have no idea what's so special about Fedora > > > > > host - this > > > > > is the first time I hear about issues with it. I may try > > > > > experimenting with > > > > > different VMs once I have more time... > > > > > > > > I've been having a look at this. The biggest differences I can find > > > > between working and non working builds is the path length to the build > > > > directory for the kernel. This is from comparing vmlinux files from > > > > working and non working builds. > > > > > > > > Works: > > > > /home/paul/poky/build/tmp/work/beaglebone-poky-linux-gnueabi > > > > > > > > Doesn't Work: > > > > /media/data1/build1/poky/build/tmp/work/beaglebone-poky-linux-gnueabi > > > > > > > > I also have been wondering if the version strings may be making a > > > > difference. > > > > > > > > http://dan.rpsys.net/uImage-rp2 is a uImage from a broken build where I > > > > truncated the path length to a "working" build path length and patched > > > > in the same version strings: > > > > > > > > const char linux_banner[] = > > > >"Linux version 3.14.0-yocto-standard (paul@ubuntu-build01) (gcc > > > > version 4.8.2 (GCC) ) #1 PREEMPT Mon Apr 14 16:00:52 BST 2014\n"; > > > > > > > > const char linux_proc_banner[] = "%s version %s (paul@ubuntu-build01) > > > > (gcc version 4.8.2 (GCC) ) %s\n"; > > > > > > > > to init/version.c. > > > > > > > > I don't have hardware and would be interested to know if the kernel > > > > linked to above works or not. If it doesn't, it rules out these path and > > > > string lengths, if it does work, it points to a problem there. > > > > > > Richard, > > > > > > Good catch! It boots: > > > > Thanks Denys, this helps narrow down the issue. I've shared > > http://dan.rpsys.net/uImage-rp3 which is the same as the last one but > > with my changes to version.c reverted. The one should tell us if its the > > paths or the strings. > > This one also boots for me: > > Linux version 3.14.0-yocto-standard (richard@ted) (gcc version 4.8.2 (GCC) ) > #2 PREEMPT Tue Apr 15 05:40:19 IST 2014 > > > > I'm guessing the path problem is more likely but anything is possible. > > This is starting to look like some kind of compiler or linker issue. If > > it is that, it would help to have more data points about what works and > > what doesn't. With that in mind could people who have good or bad builds > > please share the paths they built the kernels in so we can see if we can > > spot some kind of pattern. BTW, my path is /OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi and it works. -- Denys -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
