* 3.10.17-1.0.0_beta meta-fsl-bsp-release layer
@ 2014-01-20 16:08 Alok Kumar
2014-01-20 16:21 ` Eric Nelson
0 siblings, 1 reply; 30+ messages in thread
From: Alok Kumar @ 2014-01-20 16:08 UTC (permalink / raw)
To: meta-freescale
Hi,
I am interested in trying out 3.10.17-1.0.0_beta build, how could I
built it or try out the binaries.
I am looking for chromium browser to try on imx6 nitrogen6x.
Please advise.
--
Regards
Alok Kumar
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 3.10.17-1.0.0_beta meta-fsl-bsp-release layer
2014-01-20 16:08 3.10.17-1.0.0_beta meta-fsl-bsp-release layer Alok Kumar
@ 2014-01-20 16:21 ` Eric Nelson
2014-01-20 16:44 ` Alok Kumar
0 siblings, 1 reply; 30+ messages in thread
From: Eric Nelson @ 2014-01-20 16:21 UTC (permalink / raw)
To: Alok Kumar, meta-freescale
Hi Alok,
These are really two separate questions:
On 01/20/2014 09:08 AM, Alok Kumar wrote:
> Hi,
>
> I am interested in trying out 3.10.17-1.0.0_beta build, how could I
> built it or try out the binaries.
>
Please hold tight for patches to add 3.10.17-1.0.0_beta on
SABRE Lite/Nitrogen6x.
> I am looking for chromium browser to try on imx6 nitrogen6x.
>
You'll want to include the "meta-browser" layer:
https://github.com/OSSystems/meta-browser
And add the chromium recipe in your build.
Regards,
Eric
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 3.10.17-1.0.0_beta meta-fsl-bsp-release layer
2014-01-20 16:21 ` Eric Nelson
@ 2014-01-20 16:44 ` Alok Kumar
2014-01-20 20:58 ` Alok Kumar
2014-01-21 3:14 ` Eric Nelson
0 siblings, 2 replies; 30+ messages in thread
From: Alok Kumar @ 2014-01-20 16:44 UTC (permalink / raw)
To: Eric Nelson; +Cc: meta-freescale
Hi Eric,
I am not sure if I understand it. my apology.
I am following this
http://wiki.wandboard.org/index.php/Getting_started_with_Yocto_on_Wandboard
and took stable dora branch.
Now if I want to try chromium beta,
a) should I got to development branch first and get everything from below.
repo init -u
https://github.com/Freescale/fsl-community-bsp-platform -b master
b) apply chromium recipe on this build and build the image.
c) where should I test this on Sabrelite or nitorgen6x ?
Please advise.
Thanks
Alok
On Mon, Jan 20, 2014 at 11:21 AM, Eric Nelson
<eric.nelson@boundarydevices.com> wrote:
> Hi Alok,
>
> These are really two separate questions:
>
>
> On 01/20/2014 09:08 AM, Alok Kumar wrote:
>>
>> Hi,
>>
>> I am interested in trying out 3.10.17-1.0.0_beta build, how could I
>> built it or try out the binaries.
>>
> Please hold tight for patches to add 3.10.17-1.0.0_beta on
> SABRE Lite/Nitrogen6x.
>
>
>> I am looking for chromium browser to try on imx6 nitrogen6x.
>>
> You'll want to include the "meta-browser" layer:
> https://github.com/OSSystems/meta-browser
>
> And add the chromium recipe in your build.
>
> Regards,
>
>
> Eric
>
--
Regards
Alok Kumar
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: 3.10.17-1.0.0_beta meta-fsl-bsp-release layer
2014-01-20 16:44 ` Alok Kumar
@ 2014-01-20 20:58 ` Alok Kumar
2014-01-21 3:14 ` Eric Nelson
1 sibling, 0 replies; 30+ messages in thread
From: Alok Kumar @ 2014-01-20 20:58 UTC (permalink / raw)
To: Eric Nelson; +Cc: meta-freescale
I am running into error for libgnome-keyring.
NERROR: Nothing RPROVIDES 'libgnome-keyring' (but
/home/user/yocto/sources/poky/meta/recipes-core/images/core-image-base.bb
RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'libgnome-keyring' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['libgnome-keyring']
ERROR: Required build target 'core-image-base' has no buildable providers.
Missing or unbuildable dependency chain was: ['core-image-base',
'libgnome-keyring']
Any advise how to fix this error to build chromium ?
Thanks
Alok
On Mon, Jan 20, 2014 at 11:44 AM, Alok Kumar <alokkat@gmail.com> wrote:
> Hi Eric,
>
> I am not sure if I understand it. my apology.
>
> I am following this
> http://wiki.wandboard.org/index.php/Getting_started_with_Yocto_on_Wandboard
>
> and took stable dora branch.
>
> Now if I want to try chromium beta,
> a) should I got to development branch first and get everything from below.
>
> repo init -u
> https://github.com/Freescale/fsl-community-bsp-platform -b master
>
> b) apply chromium recipe on this build and build the image.
> c) where should I test this on Sabrelite or nitorgen6x ?
>
> Please advise.
>
> Thanks
> Alok
>
> On Mon, Jan 20, 2014 at 11:21 AM, Eric Nelson
> <eric.nelson@boundarydevices.com> wrote:
>> Hi Alok,
>>
>> These are really two separate questions:
>>
>>
>> On 01/20/2014 09:08 AM, Alok Kumar wrote:
>>>
>>> Hi,
>>>
>>> I am interested in trying out 3.10.17-1.0.0_beta build, how could I
>>> built it or try out the binaries.
>>>
>> Please hold tight for patches to add 3.10.17-1.0.0_beta on
>> SABRE Lite/Nitrogen6x.
>>
>>
>>> I am looking for chromium browser to try on imx6 nitrogen6x.
>>>
>> You'll want to include the "meta-browser" layer:
>> https://github.com/OSSystems/meta-browser
>>
>> And add the chromium recipe in your build.
>>
>> Regards,
>>
>>
>> Eric
>>
>
>
>
> --
> Regards
> Alok Kumar
--
Regards
Alok Kumar
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 3.10.17-1.0.0_beta meta-fsl-bsp-release layer
2014-01-20 16:44 ` Alok Kumar
2014-01-20 20:58 ` Alok Kumar
@ 2014-01-21 3:14 ` Eric Nelson
2014-01-21 14:42 ` Diego
2014-01-23 15:08 ` Alok Kumar
1 sibling, 2 replies; 30+ messages in thread
From: Eric Nelson @ 2014-01-21 3:14 UTC (permalink / raw)
To: Alok Kumar; +Cc: meta-freescale
Hi Alok,
On 01/20/2014 09:44 AM, Alok Kumar wrote:
> Hi Eric,
>
> I am not sure if I understand it. my apology.
>
No sweat. Over a year in and I'm still figuring things out...
> I am following this
> http://wiki.wandboard.org/index.php/Getting_started_with_Yocto_on_Wandboard
>
> and took stable dora branch.
>
I'd start with Daiane's docs on i.MX Community:
http://layers.openembedded.org/layerindex/branch/master/layer/meta-gnome/
And O.S.Systems that describes how to specifically build for
Nitrogen6x:
http://www.ossystems.com.br/blog/2013/04/15/yocto-with-boundary-devices-nitrogen6x-5-steps-only.html
Make sure you use the "dora" branch instead of "dylan" though.
> Now if I want to try chromium" beta,
> a) should I got to development branch first and get everything from below.
>
> repo init -u
> https://github.com/Freescale/fsl-community-bsp-platform -b master
>
Again, you should stick with "Dora" unless you need something
specific in "master".
> b) apply chromium recipe on this build and build the image.
After the repo sync, you'll need to pull in the meta-browser
layer:
~/yocto/sources$ git clone git://github.com/OSSystems/meta-browser.git
And you'll need to add meta-browser and meta-gnome to your
conf/bblayers.conf file:
BBLAYERS = " \
...
${BSPDIR}/sources/meta-openembedded/meta-gnome \
${BSPDIR}/sources/meta-browser \
...
"
And finally, you'll need to pull it into your build.
The easy way is to add this to your local.conf file:
IMAGE_INSTALL += " \
chromium \
"
I'm not sure why, but when I went through these steps,
I got complaints about the license for libav and
was prompted to add this to local.conf:
LICENSE_FLAGS_WHITELIST = "commercial"
I think there's something screwy with that, though.
The recipes in poky/meta/recipes-multimedia/libav/
appear to have a combination of GPL and LGPL
licenses.
> c) where should I test this on Sabrelite or nitorgen6x ?
>
We recommend the use of "nitrogen6x" for the MACHINE type.
The resulting image will run on either the SABRE Lite
or Nitrogen6X boards.
Regards,
Eric
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: 3.10.17-1.0.0_beta meta-fsl-bsp-release layer
2014-01-21 3:14 ` Eric Nelson
@ 2014-01-21 14:42 ` Diego
2014-01-21 15:22 ` Booting 3.5.7 kernel on imx6sabresd? randy.krakora
2014-01-21 19:25 ` 3.10.17-1.0.0_beta meta-fsl-bsp-release layer Eric Nelson
2014-01-23 15:08 ` Alok Kumar
1 sibling, 2 replies; 30+ messages in thread
From: Diego @ 2014-01-21 14:42 UTC (permalink / raw)
To: meta-freescale
Eric Nelson wrote:
> I got complaints about the license for libav and
>
> was prompted to add this to local.conf:
> LICENSE_FLAGS_WHITELIST = "commercial"
>
> I think there's something screwy with that, though.
> The recipes in poky/meta/recipes-multimedia/libav/
> appear to have a combination of GPL and LGPL
> licenses.
Eric, I'd bet the:
LICENSE_FLAGS = "commercial"
in the libav recipe is because of the patents that cover several of the
included codecs (gsm, x264, mp3lame, etc).
Bests,
Diego
^ permalink raw reply [flat|nested] 30+ messages in thread
* Booting 3.5.7 kernel on imx6sabresd?
2014-01-21 14:42 ` Diego
@ 2014-01-21 15:22 ` randy.krakora
2014-01-21 15:39 ` Otavio Salvador
2014-01-21 19:25 ` 3.10.17-1.0.0_beta meta-fsl-bsp-release layer Eric Nelson
1 sibling, 1 reply; 30+ messages in thread
From: randy.krakora @ 2014-01-21 15:22 UTC (permalink / raw)
To: 'meta-freescale@yoctoproject.org'
I've been trying to build and boot 3.5.7 kernel on an imx6 sabresd board.
Here's snips to get the code and build it:
manifest.xml:
<project remote="fsl-release" name="meta-fsl-bsp-release"
path="sources/meta-fsl-bsp-release" revision="dylan_3.5.7-1.0.0" >
<copyfile src="imx/tools/fsl-setup-release.sh"
dest="fsl-setup-release.sh"/>
<copyfile dest="imx/README" src="README-3.5.7-1.0.0"/>
</project>
local.conf:
PREFERRED_VERSION_linux-imx_mx6="3.5.7-1.0.0"
gcc:
gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-2ubuntu1)
Here's what I get when I burn the .sdcard file and try to boot:
U-Boot 2013.04-04882-ga5a24c3 (Jan 16 2014 - 09:10:38)
CPU: Freescale i.MX6Q rev1.2 at 792 MHz
CPU: Temperature 29 C, calibration data: 0x56f4af7d
Reset cause: POR
Board: MX6Q/SDL-SabreSD
I2C: ready
DRAM: 1 GiB
MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
In: serial
Out: serial
Err: serial
Found PFUZE100! deviceid=10,revid=11
Net: FEC [PRIME]
Hit any key to stop autoboot: 0
mmc1 is current device
reading boot.scr
** Unable to read file boot.scr **
reading uImage
4667456 bytes read in 214 ms (20.8 MiB/s)
Booting from mmc ...
reading imx6q-sabresd.dtb
46128 bytes read in 19 ms (2.3 MiB/s)
## Booting kernel from Legacy Image at 12000000 ...
Image Name: Linux-3.5.7-1.0.0+3285970
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 4667392 Bytes = 4.5 MiB
Load Address: 10008000
Entry Point: 10008000
Verifying Checksum ... Bad Data CRC
ERROR: can't get kernel image!
Does anyone have any tips on why this is happening? I know I should use 3.10, but I cannot yet, we need 3.5.7 first.
Regards,
Randy Krakora
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: Booting 3.5.7 kernel on imx6sabresd?
2014-01-21 15:22 ` Booting 3.5.7 kernel on imx6sabresd? randy.krakora
@ 2014-01-21 15:39 ` Otavio Salvador
2014-01-21 16:16 ` randy.krakora
0 siblings, 1 reply; 30+ messages in thread
From: Otavio Salvador @ 2014-01-21 15:39 UTC (permalink / raw)
To: randy.krakora@freescale.com; +Cc: meta-freescale@yoctoproject.org
On Tue, Jan 21, 2014 at 1:22 PM, randy.krakora@freescale.com
<randy.krakora@freescale.com> wrote:
> I've been trying to build and boot 3.5.7 kernel on an imx6 sabresd board.
>
...
> ## Booting kernel from Legacy Image at 12000000 ...
> Image Name: Linux-3.5.7-1.0.0+3285970
> Image Type: ARM Linux Kernel Image (uncompressed)
> Data Size: 4667392 Bytes = 4.5 MiB
> Load Address: 10008000
> Entry Point: 10008000
> Verifying Checksum ... Bad Data CRC
> ERROR: can't get kernel image!
>
> Does anyone have any tips on why this is happening? I know I should use 3.10, but I cannot yet, we need 3.5.7 first.
Please try to change fdt_addr to 0x18000000.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Booting 3.5.7 kernel on imx6sabresd?
2014-01-21 15:39 ` Otavio Salvador
@ 2014-01-21 16:16 ` randy.krakora
2014-01-21 16:21 ` Otavio Salvador
0 siblings, 1 reply; 30+ messages in thread
From: randy.krakora @ 2014-01-21 16:16 UTC (permalink / raw)
To: 'Otavio Salvador'; +Cc: 'meta-freescale@yoctoproject.org'
fdt_addr was already 0x18000000.
Is there anything else maybe?
Thanks,
Randy
-----Original Message-----
From: otavio.salvador@gmail.com [mailto:otavio.salvador@gmail.com] On Behalf Of Otavio Salvador
Sent: Tuesday, January 21, 2014 10:39 AM
To: Krakora Randy-B37740
Cc: meta-freescale@yoctoproject.org
Subject: Re: [meta-freescale] Booting 3.5.7 kernel on imx6sabresd?
On Tue, Jan 21, 2014 at 1:22 PM, randy.krakora@freescale.com <randy.krakora@freescale.com> wrote:
> I've been trying to build and boot 3.5.7 kernel on an imx6 sabresd board.
>
...
> ## Booting kernel from Legacy Image at 12000000 ...
> Image Name: Linux-3.5.7-1.0.0+3285970
> Image Type: ARM Linux Kernel Image (uncompressed)
> Data Size: 4667392 Bytes = 4.5 MiB
> Load Address: 10008000
> Entry Point: 10008000
> Verifying Checksum ... Bad Data CRC
> ERROR: can't get kernel image!
>
> Does anyone have any tips on why this is happening? I know I should use 3.10, but I cannot yet, we need 3.5.7 first.
Please try to change fdt_addr to 0x18000000.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Booting 3.5.7 kernel on imx6sabresd?
2014-01-21 16:16 ` randy.krakora
@ 2014-01-21 16:21 ` Otavio Salvador
2014-01-21 20:11 ` Ra37740@freescale.comndy
0 siblings, 1 reply; 30+ messages in thread
From: Otavio Salvador @ 2014-01-21 16:21 UTC (permalink / raw)
To: randy.krakora@freescale.com; +Cc: meta-freescale@yoctoproject.org
On Tue, Jan 21, 2014 at 2:16 PM, randy.krakora@freescale.com
<randy.krakora@freescale.com> wrote:
> fdt_addr was already 0x18000000.
>
> Is there anything else maybe?
You could try to update the U-Boot to what we're using in Dora.
I barely remember of dealing with this but I don't recall what was the fix ...
Sorry,
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Booting 3.5.7 kernel on imx6sabresd?
2014-01-21 16:21 ` Otavio Salvador
@ 2014-01-21 20:11 ` Ra37740@freescale.comndy
2014-01-21 20:23 ` Otavio Salvador
0 siblings, 1 reply; 30+ messages in thread
From: Ra37740@freescale.comndy @ 2014-01-21 20:11 UTC (permalink / raw)
To: Otavio Salvador; +Cc: meta-freescale@yoctoproject.org
On 01/21/2014 11:21 AM, Otavio Salvador wrote:
> On Tue, Jan 21, 2014 at 2:16 PM, randy.krakora@freescale.com
> <randy.krakora@freescale.com> wrote:
>> fdt_addr was already 0x18000000.
>>
>> Is there anything else maybe?
> You could try to update the U-Boot to what we're using in Dora.
>
> I barely remember of dealing with this but I don't recall what was the fix ...
>
> Sorry,
>
Which u-boot does dora update as latest? meta-fsl-arm or
meta-fsl-bsp-release?
-Randy
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Booting 3.5.7 kernel on imx6sabresd?
2014-01-21 20:11 ` Ra37740@freescale.comndy
@ 2014-01-21 20:23 ` Otavio Salvador
2014-01-21 21:03 ` Daiane.Angolini
0 siblings, 1 reply; 30+ messages in thread
From: Otavio Salvador @ 2014-01-21 20:23 UTC (permalink / raw)
To: Ra37740@freescale.comndy; +Cc: meta-freescale@yoctoproject.org
On Tue, Jan 21, 2014 at 6:11 PM, Ra37740@freescale.comndy
<b37740@freescale.com> wrote:
> On 01/21/2014 11:21 AM, Otavio Salvador wrote:
>>
>> On Tue, Jan 21, 2014 at 2:16 PM, randy.krakora@freescale.com
>> <randy.krakora@freescale.com> wrote:
>>>
>>> fdt_addr was already 0x18000000.
>>>
>>> Is there anything else maybe?
>>
>> You could try to update the U-Boot to what we're using in Dora.
>>
>> I barely remember of dealing with this but I don't recall what was the fix
>> ...
>>
>> Sorry,
>>
> Which u-boot does dora update as latest? meta-fsl-arm or
> meta-fsl-bsp-release?
You call; I will always advice you to use the mainline one. Dora uses 2013.10.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Booting 3.5.7 kernel on imx6sabresd?
2014-01-21 20:23 ` Otavio Salvador
@ 2014-01-21 21:03 ` Daiane.Angolini
2014-01-22 15:06 ` randy.krakora
0 siblings, 1 reply; 30+ messages in thread
From: Daiane.Angolini @ 2014-01-21 21:03 UTC (permalink / raw)
To: Otavio Salvador, randy.krakora@freescale.com
Cc: meta-freescale@yoctoproject.org
> -----Original Message-----
> From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-
> bounces@yoctoproject.org] On Behalf Of Otavio Salvador
> Sent: Tuesday, January 21, 2014 6:24 PM
> To: Krakora Randy-B37740
> Cc: meta-freescale@yoctoproject.org
> Subject: Re: [meta-freescale] Booting 3.5.7 kernel on imx6sabresd?
>
> On Tue, Jan 21, 2014 at 6:11 PM, Ra37740@freescale.comndy
> <b37740@freescale.com> wrote:
> > On 01/21/2014 11:21 AM, Otavio Salvador wrote:
> >>
> >> On Tue, Jan 21, 2014 at 2:16 PM, randy.krakora@freescale.com
> >> <randy.krakora@freescale.com> wrote:
> >>>
> >>> fdt_addr was already 0x18000000.
> >>>
> >>> Is there anything else maybe?
> >>
> >> You could try to update the U-Boot to what we're using in Dora.
> >>
> >> I barely remember of dealing with this but I don't recall what was
> >> the fix ...
> >>
> >> Sorry,
> >>
> > Which u-boot does dora update as latest? meta-fsl-arm or
> > meta-fsl-bsp-release?
>
> You call; I will always advice you to use the mainline one. Dora uses
> 2013.10.
Meta-fsl-arm[1] uses, by default, the u-boot from denx, it means, the mainline u-boot (we call it u-boot-fslc)
Meta-fsl-bsp-release [2] uses, by default, the u-boot fork created by Freescale (we can it u-boot-imx)
Latest dora u-boot from meta-fsl-arm is 2013.10
Latest dora u-boot from meta-fsl-bsp-release is 2013.04
Meta-fsl-bsp-release is an additional layer used by Freescale *on top of* meta-fsl-arm in order to add new version
of packages on every new BSP release. It adds, for example, the new kernel version, and some configuration, for example
the configuration that change the default u-boot used by imx6 boards.
Remember that, usually, a Freescale release only support a set of boards (for example imx6), but meta-fsl-arm does support
all boards.
We, as community, prefer to have u-boot mainline because we think it´s the best choice at long term, both for
development and for support. We do value u-boot-imx, and as much as possible, we work to integrate the important
features from u-boot-imx to u-boot-fslc (and, you can imagine, we work on this when we have some time). Today, we believe
u-boot-fslc can handle all the boards, only few exception uses a u-boot fork, but the direction we have is migrating
as much as possible to u-boot mainline.
The kernel can be used as a parallel comparison. Today, we cannot use linux-fslc for most of supported board,
the main reason is GPU support. As GPU has closed source code, the mainline integration is already a dilemma[3]. But, as u-boot,
the general guideline is having as much as possible on mainline, for both easy development and easy support. In long term
is much better to have mainline kernel as default.
I´m being obvious and leaving the main point of this discussion, but I only want to clear this point for people who
don´t think it´s so obvious. If there is someone having a bad time to understand all this layering and don´t want to ask in ML, please,
send me an email and I will do my best to explain what I know (it´s confusing to me as well)
[1] http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/
[2] http://git.freescale.com/git/cgit.cgi/imx/meta-fsl-bsp-release.git/
[3] I´m sure I´m not the person to detail this issue, so I apologize if it´s not a dilemma, in definition.
Daiane
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Booting 3.5.7 kernel on imx6sabresd?
2014-01-21 21:03 ` Daiane.Angolini
@ 2014-01-22 15:06 ` randy.krakora
2014-01-22 15:10 ` Fabio Estevam
0 siblings, 1 reply; 30+ messages in thread
From: randy.krakora @ 2014-01-22 15:06 UTC (permalink / raw)
To: Daiane.Angolini@freescale.com, Otavio Salvador
Cc: meta-freescale@yoctoproject.org
Ok, so I found the prebuilt images for my board here:
http://autobuilder.yoctoproject.org/pub/releases/CURRENT/machines/imx6qsabresd/
I burned a card with one - core-image-minimal-imx6qsabresd.sdcard. It seemed to work to boot the kernel, so I copied my kernel and .dtb file to that card and it booted as shown below.
reading boot.scr
** Unable to read file boot.scr **
reading uImage
4667456 bytes read in 215 ms (20.7 MiB/s)
Booting from mmc ...
reading imx6q-sabresd.dtb
46128 bytes read in 20 ms (2.2 MiB/s)
## Booting kernel from Legacy Image at 12000000 ...
Image Name: Linux-3.5.7-1.0.0+3285970
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 4667392 Bytes = 4.5 MiB
Load Address: 10008000
Entry Point: 10008000
Verifying Checksum ... OK
## Flattened Device Tree blob at 11000000
Booting using the fdt blob at 0x11000000
Loading Kernel Image ... OK
OK
Using Device Tree in place at 11000000, end 1100e42f
Starting kernel ...
<Hung here for many minutes>
So, it appears maybe there is something wrong with my kernel build? Any ideas would be appreciated.
Regards,
Randy Krakora
-----Original Message-----
From: Angolini Daiane-B19406
Sent: Tuesday, January 21, 2014 4:04 PM
To: Otavio Salvador; Krakora Randy-B37740
Cc: meta-freescale@yoctoproject.org
Subject: RE: [meta-freescale] Booting 3.5.7 kernel on imx6sabresd?
> -----Original Message-----
> From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-
> bounces@yoctoproject.org] On Behalf Of Otavio Salvador
> Sent: Tuesday, January 21, 2014 6:24 PM
> To: Krakora Randy-B37740
> Cc: meta-freescale@yoctoproject.org
> Subject: Re: [meta-freescale] Booting 3.5.7 kernel on imx6sabresd?
>
> On Tue, Jan 21, 2014 at 6:11 PM, Ra37740@freescale.comndy
> <b37740@freescale.com> wrote:
> > On 01/21/2014 11:21 AM, Otavio Salvador wrote:
> >>
> >> On Tue, Jan 21, 2014 at 2:16 PM, randy.krakora@freescale.com
> >> <randy.krakora@freescale.com> wrote:
> >>>
> >>> fdt_addr was already 0x18000000.
> >>>
> >>> Is there anything else maybe?
> >>
> >> You could try to update the U-Boot to what we're using in Dora.
> >>
> >> I barely remember of dealing with this but I don't recall what was
> >> the fix ...
> >>
> >> Sorry,
> >>
> > Which u-boot does dora update as latest? meta-fsl-arm or
> > meta-fsl-bsp-release?
>
> You call; I will always advice you to use the mainline one. Dora uses
> 2013.10.
Meta-fsl-arm[1] uses, by default, the u-boot from denx, it means, the mainline u-boot (we call it u-boot-fslc) Meta-fsl-bsp-release [2] uses, by default, the u-boot fork created by Freescale (we can it u-boot-imx)
Latest dora u-boot from meta-fsl-arm is 2013.10 Latest dora u-boot from meta-fsl-bsp-release is 2013.04
Meta-fsl-bsp-release is an additional layer used by Freescale *on top of* meta-fsl-arm in order to add new version of packages on every new BSP release. It adds, for example, the new kernel version, and some configuration, for example the configuration that change the default u-boot used by imx6 boards.
Remember that, usually, a Freescale release only support a set of boards (for example imx6), but meta-fsl-arm does support all boards.
We, as community, prefer to have u-boot mainline because we think it´s the best choice at long term, both for development and for support. We do value u-boot-imx, and as much as possible, we work to integrate the important features from u-boot-imx to u-boot-fslc (and, you can imagine, we work on this when we have some time). Today, we believe u-boot-fslc can handle all the boards, only few exception uses a u-boot fork, but the direction we have is migrating as much as possible to u-boot mainline.
The kernel can be used as a parallel comparison. Today, we cannot use linux-fslc for most of supported board, the main reason is GPU support. As GPU has closed source code, the mainline integration is already a dilemma[3]. But, as u-boot, the general guideline is having as much as possible on mainline, for both easy development and easy support. In long term is much better to have mainline kernel as default.
I´m being obvious and leaving the main point of this discussion, but I only want to clear this point for people who don´t think it´s so obvious. If there is someone having a bad time to understand all this layering and don´t want to ask in ML, please, send me an email and I will do my best to explain what I know (it´s confusing to me as well)
[1] http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/
[2] http://git.freescale.com/git/cgit.cgi/imx/meta-fsl-bsp-release.git/
[3] I´m sure I´m not the person to detail this issue, so I apologize if it´s not a dilemma, in definition.
Daiane
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Booting 3.5.7 kernel on imx6sabresd?
2014-01-22 15:06 ` randy.krakora
@ 2014-01-22 15:10 ` Fabio Estevam
2014-01-22 17:47 ` randy.krakora
0 siblings, 1 reply; 30+ messages in thread
From: Fabio Estevam @ 2014-01-22 15:10 UTC (permalink / raw)
To: randy.krakora@freescale.com
Cc: meta-freescale@yoctoproject.org, Otavio Salvador
On Wed, Jan 22, 2014 at 1:06 PM, randy.krakora@freescale.com
<randy.krakora@freescale.com> wrote:
> Ok, so I found the prebuilt images for my board here:
>
> http://autobuilder.yoctoproject.org/pub/releases/CURRENT/machines/imx6qsabresd/
>
> I burned a card with one - core-image-minimal-imx6qsabresd.sdcard. It seemed to work to boot the kernel, so I copied my kernel and .dtb file to that card and it booted as shown below.
>
> reading boot.scr
> ** Unable to read file boot.scr **
> reading uImage
> 4667456 bytes read in 215 ms (20.7 MiB/s)
> Booting from mmc ...
> reading imx6q-sabresd.dtb
> 46128 bytes read in 20 ms (2.2 MiB/s)
> ## Booting kernel from Legacy Image at 12000000 ...
> Image Name: Linux-3.5.7-1.0.0+3285970
> Image Type: ARM Linux Kernel Image (uncompressed)
> Data Size: 4667392 Bytes = 4.5 MiB
> Load Address: 10008000
> Entry Point: 10008000
> Verifying Checksum ... OK
> ## Flattened Device Tree blob at 11000000
> Booting using the fdt blob at 0x11000000
> Loading Kernel Image ... OK
> OK
> Using Device Tree in place at 11000000, end 1100e42f
>
> Starting kernel ...
>
> <Hung here for many minutes>
Ok, ,at least now you don't get the CRC kernel error.
Try doing this in the U-boot prompt:
=> setenv fdt_addr 0x18000000
=> save
=> reset
Regards,
Fabio Estevam
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Booting 3.5.7 kernel on imx6sabresd?
2014-01-22 15:10 ` Fabio Estevam
@ 2014-01-22 17:47 ` randy.krakora
2014-01-22 17:52 ` Fabio Estevam
0 siblings, 1 reply; 30+ messages in thread
From: randy.krakora @ 2014-01-22 17:47 UTC (permalink / raw)
To: 'Fabio Estevam'; +Cc: meta-freescale@yoctoproject.org, Otavio Salvador
Ahhh, yes, Otavio's suggestion for my original uboot, it works now. And my wife always claims she has to tell me things twice...I guess I should believe her now.
So that worked. Then I went back to my original built image ( uboot, kernel and dtb file ) and burned it again and now it works, not sure why, although maybe I didn't really change fdt_addr before when Otavio mentioned it?
Either way, probably beginner's luck, bad followed by good. Thanks for all your support and patience.
Regards,
Randy Krakora
-----Original Message-----
From: Fabio Estevam [mailto:festevam@gmail.com]
Sent: Wednesday, January 22, 2014 10:10 AM
To: Krakora Randy-B37740
Cc: Angolini Daiane-B19406; Otavio Salvador; meta-freescale@yoctoproject.org
Subject: Re: [meta-freescale] Booting 3.5.7 kernel on imx6sabresd?
On Wed, Jan 22, 2014 at 1:06 PM, randy.krakora@freescale.com <randy.krakora@freescale.com> wrote:
> Ok, so I found the prebuilt images for my board here:
>
> http://autobuilder.yoctoproject.org/pub/releases/CURRENT/machines/imx6
> qsabresd/
>
> I burned a card with one - core-image-minimal-imx6qsabresd.sdcard. It seemed to work to boot the kernel, so I copied my kernel and .dtb file to that card and it booted as shown below.
>
> reading boot.scr
> ** Unable to read file boot.scr **
> reading uImage
> 4667456 bytes read in 215 ms (20.7 MiB/s) Booting from mmc ...
> reading imx6q-sabresd.dtb
> 46128 bytes read in 20 ms (2.2 MiB/s)
> ## Booting kernel from Legacy Image at 12000000 ...
> Image Name: Linux-3.5.7-1.0.0+3285970
> Image Type: ARM Linux Kernel Image (uncompressed)
> Data Size: 4667392 Bytes = 4.5 MiB
> Load Address: 10008000
> Entry Point: 10008000
> Verifying Checksum ... OK
> ## Flattened Device Tree blob at 11000000
> Booting using the fdt blob at 0x11000000
> Loading Kernel Image ... OK
> OK
> Using Device Tree in place at 11000000, end 1100e42f
>
> Starting kernel ...
>
> <Hung here for many minutes>
Ok, ,at least now you don't get the CRC kernel error.
Try doing this in the U-boot prompt:
=> setenv fdt_addr 0x18000000
=> save
=> reset
Regards,
Fabio Estevam
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Booting 3.5.7 kernel on imx6sabresd?
2014-01-22 17:47 ` randy.krakora
@ 2014-01-22 17:52 ` Fabio Estevam
0 siblings, 0 replies; 30+ messages in thread
From: Fabio Estevam @ 2014-01-22 17:52 UTC (permalink / raw)
To: randy.krakora@freescale.com
Cc: meta-freescale@yoctoproject.org, Otavio Salvador
On Wed, Jan 22, 2014 at 3:47 PM, randy.krakora@freescale.com
<randy.krakora@freescale.com> wrote:
> Ahhh, yes, Otavio's suggestion for my original uboot, it works now. And my wife always claims she has to tell me things twice...I guess I should believe her now.
>
> So that worked. Then I went back to my original built image ( uboot, kernel and dtb file ) and burned it again and now it works, not sure why, although maybe I didn't really change fdt_addr before when Otavio mentioned it?
>
> Either way, probably beginner's luck, bad followed by good. Thanks for all your support and patience.
Glad it works, but as said previously in this thread, there is not
much value in using 3.5 kernel, which is obsolete and will have no
more bug fixes, packages upgrades, etc.
Switch to 3.10 and things will be run smoother for you and your customer.
Regards,
Fabio Estevam
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 3.10.17-1.0.0_beta meta-fsl-bsp-release layer
2014-01-21 14:42 ` Diego
2014-01-21 15:22 ` Booting 3.5.7 kernel on imx6sabresd? randy.krakora
@ 2014-01-21 19:25 ` Eric Nelson
2014-01-22 12:41 ` Alok Kumar
1 sibling, 1 reply; 30+ messages in thread
From: Eric Nelson @ 2014-01-21 19:25 UTC (permalink / raw)
To: Diego, meta-freescale
On 01/21/2014 07:42 AM, Diego wrote:
> Eric Nelson wrote:
>> I got complaints about the license for libav and
>>
>> was prompted to add this to local.conf:
>> LICENSE_FLAGS_WHITELIST = "commercial"
>>
>> I think there's something screwy with that, though.
>> The recipes in poky/meta/recipes-multimedia/libav/
>> appear to have a combination of GPL and LGPL
>> licenses.
>
> Eric, I'd bet the:
> LICENSE_FLAGS = "commercial"
> in the libav recipe is because of the patents that cover several of the
> included codecs (gsm, x264, mp3lame, etc).
>
Thanks Diego,
There seem to be lots of disclaimers about this library:
http://libav.org/legal.html
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 3.10.17-1.0.0_beta meta-fsl-bsp-release layer
2014-01-21 19:25 ` 3.10.17-1.0.0_beta meta-fsl-bsp-release layer Eric Nelson
@ 2014-01-22 12:41 ` Alok Kumar
2014-01-23 8:41 ` Diego
0 siblings, 1 reply; 30+ messages in thread
From: Alok Kumar @ 2014-01-22 12:41 UTC (permalink / raw)
To: Eric Nelson; +Cc: meta-freescale, Diego
[-- Attachment #1: Type: text/plain, Size: 5060 bytes --]
I ran into following errors while building chromium for nitrogen6X, could
someone advise if something not compatible in my conf layer (below)
/home/user/yocto/build/tmp/work/cortexa9hf-vfp-neon-mx6-poky-linux-gnueabi/qtbase/5.1.1-r0/qtbase-opensource-src-5.1.1/src/plugins/platforms/xcb/qxcbwindow.cpp:423:51:
warning: narrowing conversion of 'XEMBED_VERSION' from 'unsigned int' to
'long int' inside { } [-Wnarrowing]
long data[] = { XEMBED_VERSION, XEMBED_MAPPED };
^
/home/user/yocto/build/tmp/work/cortexa9hf-vfp-neon-mx6-poky-linux-gnueabi/qtbase/5.1.1-r0/qtbase-opensource-src-5.1.1/src/plugins/platforms/xcb/qxcbconnection.cpp:
In constructor 'QXcbConnection::QXcbConnection(QXcbNativeInterface*, bool,
const char*)':
/home/user/yocto/build/tmp/work/cortexa9hf-vfp-neon-mx6-poky-linux-gnueabi/qtbase/5.1.1-r0/qtbase-opensource-src-5.1.1/src/plugins/platforms/xcb/qxcbconnection.cpp:275:50:
error: cannot convert 'Display* {aka _XDisplay*}' to 'EGLNativeDisplayType
{aka _FBDisplay*}' for argument '1' to 'void*
eglGetDisplay(EGLNativeDisplayType)'
EGLDisplay eglDisplay = eglGetDisplay(dpy);
^
make[5]: *** [.obj/release-shared/qxcbconnection.o] Error 1
make[5]: *** Waiting for unfinished jobs....
make[5]: Leaving directory
`/home/user/yocto/build/tmp/work/cortexa9hf-vfp-neon-mx6-poky-linux-gnueabi/qtbase/5.1.1-r0/build/src/plugins/platforms/xcb'
make[4]: *** [sub-xcb-plugin-pro-make_first-ordered] Error 2
make[4]: Leaving directory
`/home/user/yocto/build/tmp/work/cortexa9hf-vfp-neon-mx6-poky-linux-gnueabi/qtbase/5.1.1-r0/build/src/plugins/platforms/xcb'
make[3]: *** [sub-xcb-make_first] Error 2
make[3]: Leaving directory
`/home/user/yocto/build/tmp/work/cortexa9hf-vfp-neon-mx6-poky-linux-gnueabi/qtbase/5.1.1-r0/build/src/plugins/platforms'
make[2]: *** [sub-platforms-make_first] Error 2
make[2]: Leaving directory
`/home/user/yocto/build/tmp/work/cortexa9hf-vfp-neon-mx6-poky-linux-gnueabi/qtbase/5.1.1-r0/build/src/plugins'
make[1]: *** [sub-plugins-make_first] Error 2
make[1]: Leaving directory
`/home/user/yocto/build/tmp/work/cortexa9hf-vfp-neon-mx6-poky-linux-gnueabi/qtbase/5.1.1-r0/build/src'
make: *** [sub-src-make_first] Error 2
ERROR: oe_runmake failed
WARNING: exit code 1 from a shell command.
*My conf/bblayer.conf is as below:*
LCONF_VERSION = "6"
BBPATH = "${TOPDIR}"
BSPDIR := "${@os.path.abspath(os.path.dirname(d.getVar('FILE', True)) +
'/../..')}"
BBFILES ?= ""
BBLAYERS = " \
${BSPDIR}/sources/poky/meta \
${BSPDIR}/sources/poky/meta-yocto \
\
${BSPDIR}/sources/meta-openembedded/meta-oe \
${BSPDIR}/sources/meta-openembedded/meta-gnome \
${BSPDIR}/sources/meta-openembedded/meta-browser \
\
${BSPDIR}/sources/meta-fsl-arm \
${BSPDIR}/sources/meta-fsl-arm-extra \
${BSPDIR}/sources/meta-fsl-demos \
${BSPDIR}/sources/meta-qt5 \
"
*And conf/local.conf*
MACHINE ??= 'nitrogen6x'
DISTRO ?= 'poky'
PACKAGE_CLASSES ?= "package_rpm"
EXTRA_IMAGE_FEATURES = "debug-tweaks ssh-server-openssh"
IMAGE_INSTALL_append = " eglibc-staticdev strace gcc g++ binutils libgcc
libgcc-dev libstdc++ libstdc++-dev libstdc++-staticdev tslib-conf
tslib-tests tslib-calibrate openssh-sftp-server alsa-lib alsa-tools
alsa-state alsa-utils-alsaconf tslib evtest dbus nano git qtbase gstreamer
cairo pango fontconfig freetype pulseaudio qtbase qtbase-fonts
qtbase-plugins qtbase-examples chromium"
USER_CLASSES ?= "buildstats image-mklibs image-prelink"
LICENSE_FLAGS_WHITELIST = "commercial"
PATCHRESOLVE = "noop"
BB_DISKMON_DIRS = "\
STOPTASKS,${TMPDIR},1G,100K \
STOPTASKS,${DL_DIR},1G,100K \
STOPTASKS,${SSTATE_DIR},1G,100K \
ABORT,${TMPDIR},100M,1K \
ABORT,${DL_DIR},100M,1K \
ABORT,${SSTATE_DIR},100M,1K"
CONF_VERSION = "1"
BB_NUMBER_THREADS = '8'
PARALLEL_MAKE = '-j 8'
DL_DIR ?= "${BSPDIR}/downloads/"
ACCEPT_FSL_EULA = ""
Thanks
Alok
On Tue, Jan 21, 2014 at 2:25 PM, Eric Nelson <
eric.nelson@boundarydevices.com> wrote:
> On 01/21/2014 07:42 AM, Diego wrote:
>
>> Eric Nelson wrote:
>>
>>> I got complaints about the license for libav and
>>>
>>> was prompted to add this to local.conf:
>>> LICENSE_FLAGS_WHITELIST = "commercial"
>>>
>>> I think there's something screwy with that, though.
>>> The recipes in poky/meta/recipes-multimedia/libav/
>>> appear to have a combination of GPL and LGPL
>>> licenses.
>>>
>>
>> Eric, I'd bet the:
>> LICENSE_FLAGS = "commercial"
>> in the libav recipe is because of the patents that cover several of the
>> included codecs (gsm, x264, mp3lame, etc).
>>
>> Thanks Diego,
>
> There seem to be lots of disclaimers about this library:
> http://libav.org/legal.html
>
>
>
>
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale
>
--
Regards
Alok Kumar
[-- Attachment #2: Type: text/html, Size: 7393 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: 3.10.17-1.0.0_beta meta-fsl-bsp-release layer
2014-01-22 12:41 ` Alok Kumar
@ 2014-01-23 8:41 ` Diego
2014-01-23 11:08 ` Alok Kumar
0 siblings, 1 reply; 30+ messages in thread
From: Diego @ 2014-01-23 8:41 UTC (permalink / raw)
To: meta-freescale
In data mercoledì 22 gennaio 2014 07:41:03, Alok Kumar ha scritto:
> I ran into following errors while building chromium for nitrogen6X, could
> someone advise if something not compatible in my conf layer (below)
>
> /home/user/yocto/build/tmp/work/cortexa9hf-vfp-neon-mx6-poky-linux-gnueabi/q
> tbase/5.1.1-r0/qtbase-opensource-src-5.1.1/src/plugins/platforms/xcb/qxcbwin
> dow.cpp:423:51: warning: narrowing conversion of 'XEMBED_VERSION' from
> 'unsigned int' to 'long int' inside { } [-Wnarrowing]
> long data[] = { XEMBED_VERSION, XEMBED_MAPPED };
> ^
> /home/user/yocto/build/tmp/work/cortexa9hf-vfp-neon-mx6-poky-linux-gnueabi/q
> tbase/5.1.1-r0/qtbase-opensource-src-5.1.1/src/plugins/platforms/xcb/qxcbcon
> nection.cpp: In constructor
> 'QXcbConnection::QXcbConnection(QXcbNativeInterface*, bool, const char*)':
> /home/user/yocto/build/tmp/work/cortexa9hf-vfp-neon-mx6-poky-linux-gnueabi/q
> tbase/5.1.1-r0/qtbase-opensource-src-5.1.1/src/plugins/platforms/xcb/qxcbcon
> nection.cpp:275:50: error: cannot convert 'Display* {aka _XDisplay*}' to
> 'EGLNativeDisplayType {aka _FBDisplay*}' for argument '1' to 'void*
> eglGetDisplay(EGLNativeDisplayType)'
> EGLDisplay eglDisplay = eglGetDisplay(dpy);
> ^
Hi Alok,
please take a look closely to the error log, because I think you haven't.
/home/user/yocto/build/tmp/work/cortexa9hf-vfp-neon-mx6-poky-linux-
gnueabi/qtbase/5.1.1-r0/qtbase-opensource-
src-5.1.1/src/plugins/platforms/xcb/qxcbconnection.cpp:275:50:
error: cannot convert 'Display* {aka _XDisplay*}' to 'EGLNativeDisplayType
Can be easily seen is a qtbase 5.1.1 error, not a Chromium error. qtbase is
not required for Chromium.
Please remove qt related things from your IMAGE_INSTALL_append and try again.
Bests,
Diego
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: 3.10.17-1.0.0_beta meta-fsl-bsp-release layer
2014-01-23 8:41 ` Diego
@ 2014-01-23 11:08 ` Alok Kumar
0 siblings, 0 replies; 30+ messages in thread
From: Alok Kumar @ 2014-01-23 11:08 UTC (permalink / raw)
To: Diego; +Cc: meta-freescale@yoctoproject.org
[-- Attachment #1: Type: text/plain, Size: 2731 bytes --]
Hi Diego,
Thanks for reply. Appreciate your feedback. I have a question, I would
like to use Qt WebEngine as mentioned in following blog.
http://blog.qt.digia.com/blog/2013/09/12/introducing-the-qt-webengine/
I thought of having some programming interface with chromium using QT
WebEngine which in introduced in QT 5.2.
Which package of QT in bblayer.conf and local.conf, I should be including
to accomplish this?
Thanks
Alok
On Thu, Jan 23, 2014 at 3:41 AM, Diego <diego.ml@zoho.com> wrote:
> In data mercoledì 22 gennaio 2014 07:41:03, Alok Kumar ha scritto:
> > I ran into following errors while building chromium for nitrogen6X, could
> > someone advise if something not compatible in my conf layer (below)
> >
> >
> /home/user/yocto/build/tmp/work/cortexa9hf-vfp-neon-mx6-poky-linux-gnueabi/q
> >
> tbase/5.1.1-r0/qtbase-opensource-src-5.1.1/src/plugins/platforms/xcb/qxcbwin
> > dow.cpp:423:51: warning: narrowing conversion of 'XEMBED_VERSION' from
> > 'unsigned int' to 'long int' inside { } [-Wnarrowing]
> > long data[] = { XEMBED_VERSION, XEMBED_MAPPED };
> > ^
> >
> /home/user/yocto/build/tmp/work/cortexa9hf-vfp-neon-mx6-poky-linux-gnueabi/q
> >
> tbase/5.1.1-r0/qtbase-opensource-src-5.1.1/src/plugins/platforms/xcb/qxcbcon
> > nection.cpp: In constructor
> > 'QXcbConnection::QXcbConnection(QXcbNativeInterface*, bool, const
> char*)':
> >
> /home/user/yocto/build/tmp/work/cortexa9hf-vfp-neon-mx6-poky-linux-gnueabi/q
> >
> tbase/5.1.1-r0/qtbase-opensource-src-5.1.1/src/plugins/platforms/xcb/qxcbcon
> > nection.cpp:275:50: error: cannot convert 'Display* {aka _XDisplay*}' to
> > 'EGLNativeDisplayType {aka _FBDisplay*}' for argument '1' to 'void*
> > eglGetDisplay(EGLNativeDisplayType)'
> > EGLDisplay eglDisplay = eglGetDisplay(dpy);
> > ^
>
> Hi Alok,
>
> please take a look closely to the error log, because I think you haven't.
> /home/user/yocto/build/tmp/work/cortexa9hf-vfp-neon-mx6-poky-linux-
> gnueabi/qtbase/5.1.1-r0/qtbase-opensource-
> src-5.1.1/src/plugins/platforms/xcb/qxcbconnection.cpp:275:50:
> error: cannot convert 'Display* {aka _XDisplay*}' to 'EGLNativeDisplayType
>
> Can be easily seen is a qtbase 5.1.1 error, not a Chromium error. qtbase is
> not required for Chromium.
>
> Please remove qt related things from your IMAGE_INSTALL_append and try
> again.
>
> Bests,
> Diego
>
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale
>
--
Regards
Alok Kumar
[-- Attachment #2: Type: text/html, Size: 3961 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 3.10.17-1.0.0_beta meta-fsl-bsp-release layer
2014-01-21 3:14 ` Eric Nelson
2014-01-21 14:42 ` Diego
@ 2014-01-23 15:08 ` Alok Kumar
2014-01-23 15:14 ` Gary Thomas
2014-01-23 15:43 ` Eric Nelson
1 sibling, 2 replies; 30+ messages in thread
From: Alok Kumar @ 2014-01-23 15:08 UTC (permalink / raw)
To: Eric Nelson; +Cc: meta-freescale@yoctoproject.org
[-- Attachment #1: Type: text/plain, Size: 2850 bytes --]
Eric,
After building chromium, when I tried to launch it
find / -name "chrome*"
/usr/bin/chrome
/usr/bin/chrome/chrome_100_percent.pak
/usr/bin/chrome/chrome
/usr/bin/chrome/chrome.pak
I get following error.
/usr/bin/chrome/chrome
(chrome:2068): Gtk-WARNING **: cannot open display:
Any thoughts, what I am missing here.
Thanks
Alok
On Mon, Jan 20, 2014 at 10:14 PM, Eric Nelson <
eric.nelson@boundarydevices.com> wrote:
> Hi Alok,
>
>
> On 01/20/2014 09:44 AM, Alok Kumar wrote:
>
>> Hi Eric,
>>
>> I am not sure if I understand it. my apology.
>>
>>
> No sweat. Over a year in and I'm still figuring things out...
>
>
> I am following this
>> http://wiki.wandboard.org/index.php/Getting_started_
>> with_Yocto_on_Wandboard
>>
>> and took stable dora branch.
>>
>>
> I'd start with Daiane's docs on i.MX Community:
> http://layers.openembedded.org/layerindex/branch/master/
> layer/meta-gnome/
>
> And O.S.Systems that describes how to specifically build for
> Nitrogen6x:
> http://www.ossystems.com.br/blog/2013/04/15/yocto-with-
> boundary-devices-nitrogen6x-5-steps-only.html
>
> Make sure you use the "dora" branch instead of "dylan" though.
>
>
> Now if I want to try chromium" beta,
>> a) should I got to development branch first and get everything from below.
>>
>> repo init -u
>> https://github.com/Freescale/fsl-community-bsp-platform -b master
>>
>>
> Again, you should stick with "Dora" unless you need something
> specific in "master".
>
>
> b) apply chromium recipe on this build and build the image.
>>
>
> After the repo sync, you'll need to pull in the meta-browser
> layer:
> ~/yocto/sources$ git clone git://github.com/OSSystems/
> meta-browser.git
>
> And you'll need to add meta-browser and meta-gnome to your
> conf/bblayers.conf file:
>
> BBLAYERS = " \
> ...
> ${BSPDIR}/sources/meta-openembedded/meta-gnome \
> ${BSPDIR}/sources/meta-browser \
> ...
> "
>
> And finally, you'll need to pull it into your build.
> The easy way is to add this to your local.conf file:
>
> IMAGE_INSTALL += " \
> chromium \
> "
>
> I'm not sure why, but when I went through these steps,
> I got complaints about the license for libav and
> was prompted to add this to local.conf:
>
> LICENSE_FLAGS_WHITELIST = "commercial"
>
> I think there's something screwy with that, though.
> The recipes in poky/meta/recipes-multimedia/libav/
> appear to have a combination of GPL and LGPL
> licenses.
>
>
> c) where should I test this on Sabrelite or nitorgen6x ?
>>
>>
> We recommend the use of "nitrogen6x" for the MACHINE type.
> The resulting image will run on either the SABRE Lite
> or Nitrogen6X boards.
>
> Regards,
>
>
> Eric
>
>
--
Regards
Alok Kumar
[-- Attachment #2: Type: text/html, Size: 4940 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: 3.10.17-1.0.0_beta meta-fsl-bsp-release layer
2014-01-23 15:08 ` Alok Kumar
@ 2014-01-23 15:14 ` Gary Thomas
[not found] ` <CACoWYqXYmKAQ3L_9HjLvEEwJNQ56G+9ENcgup7t44D25EpTTcA@mail.gmail.com>
2014-01-23 15:43 ` Eric Nelson
1 sibling, 1 reply; 30+ messages in thread
From: Gary Thomas @ 2014-01-23 15:14 UTC (permalink / raw)
To: meta-freescale
On 2014-01-23 08:08, Alok Kumar wrote:
> Eric,
>
> After building chromium, when I tried to launch it
>
> find / -name "chrome*"
> /usr/bin/chrome
> /usr/bin/chrome/chrome_100_percent.pak
> /usr/bin/chrome/chrome
> /usr/bin/chrome/chrome.pak
>
> I get following error.
> /usr/bin/chrome/chrome
>
> (chrome:2068): Gtk-WARNING **: cannot open display:
>
> Any thoughts, what I am missing here.
Do you have X running?
If you tried to run this from outside the X desktop, you'll need to do something like
DISPLAY=:0.0 /usr/bin/chrome/chrome
> On Mon, Jan 20, 2014 at 10:14 PM, Eric Nelson <eric.nelson@boundarydevices.com <mailto:eric.nelson@boundarydevices.com>> wrote:
>
> Hi Alok,
>
>
> On 01/20/2014 09:44 AM, Alok Kumar wrote:
>
> Hi Eric,
>
> I am not sure if I understand it. my apology.
>
>
> No sweat. Over a year in and I'm still figuring things out...
>
>
> I am following this
> http://wiki.wandboard.org/__index.php/Getting_started___with_Yocto_on_Wandboard <http://wiki.wandboard.org/index.php/Getting_started_with_Yocto_on_Wandboard>
>
> and took stable dora branch.
>
>
> I'd start with Daiane's docs on i.MX Community:
> http://layers.openembedded.__org/layerindex/branch/master/__layer/meta-gnome/ <http://layers.openembedded.org/layerindex/branch/master/layer/meta-gnome/>
>
> And O.S.Systems that describes how to specifically build for
> Nitrogen6x:
> http://www.ossystems.com.br/__blog/2013/04/15/yocto-with-__boundary-devices-nitrogen6x-5-__steps-only.html
> <http://www.ossystems.com.br/blog/2013/04/15/yocto-with-boundary-devices-nitrogen6x-5-steps-only.html>
>
> Make sure you use the "dora" branch instead of "dylan" though.
>
>
> Now if I want to try chromium" beta,
> a) should I got to development branch first and get everything from below.
>
> repo init -u
> https://github.com/Freescale/__fsl-community-bsp-platform <https://github.com/Freescale/fsl-community-bsp-platform> -b master
>
>
> Again, you should stick with "Dora" unless you need something
> specific in "master".
>
>
> b) apply chromium recipe on this build and build the image.
>
>
> After the repo sync, you'll need to pull in the meta-browser
> layer:
> ~/yocto/sources$ git clone git://github.com/OSSystems/__meta-browser.git <http://github.com/OSSystems/meta-browser.git>
>
> And you'll need to add meta-browser and meta-gnome to your
> conf/bblayers.conf file:
>
> BBLAYERS = " \
> ...
> ${BSPDIR}/sources/meta-__openembedded/meta-gnome \
> ${BSPDIR}/sources/meta-browser \
> ...
> "
>
> And finally, you'll need to pull it into your build.
> The easy way is to add this to your local.conf file:
>
> IMAGE_INSTALL += " \
> chromium \
> "
>
> I'm not sure why, but when I went through these steps,
> I got complaints about the license for libav and
> was prompted to add this to local.conf:
>
> LICENSE_FLAGS_WHITELIST = "commercial"
>
> I think there's something screwy with that, though.
> The recipes in poky/meta/recipes-multimedia/__libav/
> appear to have a combination of GPL and LGPL
> licenses.
>
>
> c) where should I test this on Sabrelite or nitorgen6x ?
>
>
> We recommend the use of "nitrogen6x" for the MACHINE type.
> The resulting image will run on either the SABRE Lite
> or Nitrogen6X boards.
>
> Regards,
>
>
> Eric
>
>
>
>
> --
> Regards
> Alok Kumar
>
>
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale
>
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: 3.10.17-1.0.0_beta meta-fsl-bsp-release layer
2014-01-23 15:08 ` Alok Kumar
2014-01-23 15:14 ` Gary Thomas
@ 2014-01-23 15:43 ` Eric Nelson
1 sibling, 0 replies; 30+ messages in thread
From: Eric Nelson @ 2014-01-23 15:43 UTC (permalink / raw)
To: Alok Kumar; +Cc: meta-freescale@yoctoproject.org
Hi Alok,
On 01/23/2014 08:08 AM, Alok Kumar wrote:
> Eric,
>
> After building chromium, when I tried to launch it
>
> find / -name "chrome*"
> /usr/bin/chrome
> /usr/bin/chrome/chrome_100_percent.pak
> /usr/bin/chrome/chrome
> /usr/bin/chrome/chrome.pak
>
> I get following error.
> /usr/bin/chrome/chrome
>
> (chrome:2068): Gtk-WARNING **: cannot open display:
>
It looks like you're running this over the serial console...
Try setting the DISPLAY variable:
~/$ DISPLAY=:0 /usr/bin/chrome/chrome
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 3.10.17-1.0.0_beta meta-fsl-bsp-release layer
@ 2014-01-22 18:40 alokcherryhills
0 siblings, 0 replies; 30+ messages in thread
From: alokcherryhills @ 2014-01-22 18:40 UTC (permalink / raw)
To: Alok Kumar, Eric Nelson; +Cc: meta-freescale@yoctoproject.org, Diego
[-- Attachment #1: Type: text/plain, Size: 5463 bytes --]
Could someone please offer advice on this chrome building issues.
Thanks
Alok
Sent from my Windows Phone
------------------------------
From: Alok Kumar <alokkat@gmail.com>
Sent: 1/22/2014 7:41 AM
To: Eric Nelson <eric.nelson@boundarydevices.com>
Cc: Diego <diego.ml@zoho.com>; meta-freescale@yoctoproject.org
Subject: Re: [meta-freescale] 3.10.17-1.0.0_beta meta-fsl-bsp-release layer
I ran into following errors while building chromium for nitrogen6X, could
someone advise if something not compatible in my conf layer (below)
/home/user/yocto/build/tmp/work/cortexa9hf-vfp-neon-mx6-poky-linux-gnueabi/qtbase/5.1.1-r0/qtbase-opensource-src-5.1.1/src/plugins/platforms/xcb/qxcbwindow.cpp:423:51:
warning: narrowing conversion of 'XEMBED_VERSION' from 'unsigned int' to
'long int' inside { } [-Wnarrowing]
long data[] = { XEMBED_VERSION, XEMBED_MAPPED };
^
/home/user/yocto/build/tmp/work/cortexa9hf-vfp-neon-mx6-poky-linux-gnueabi/qtbase/5.1.1-r0/qtbase-opensource-src-5.1.1/src/plugins/platforms/xcb/qxcbconnection.cpp:
In constructor 'QXcbConnection::QXcbConnection(QXcbNativeInterface*, bool,
const char*)':
/home/user/yocto/build/tmp/work/cortexa9hf-vfp-neon-mx6-poky-linux-gnueabi/qtbase/5.1.1-r0/qtbase-opensource-src-5.1.1/src/plugins/platforms/xcb/qxcbconnection.cpp:275:50:
error: cannot convert 'Display* {aka _XDisplay*}' to 'EGLNativeDisplayType
{aka _FBDisplay*}' for argument '1' to 'void*
eglGetDisplay(EGLNativeDisplayType)'
EGLDisplay eglDisplay = eglGetDisplay(dpy);
^
make[5]: *** [.obj/release-shared/qxcbconnection.o] Error 1
make[5]: *** Waiting for unfinished jobs....
make[5]: Leaving directory
`/home/user/yocto/build/tmp/work/cortexa9hf-vfp-neon-mx6-poky-linux-gnueabi/qtbase/5.1.1-r0/build/src/plugins/platforms/xcb'
make[4]: *** [sub-xcb-plugin-pro-make_first-ordered] Error 2
make[4]: Leaving directory
`/home/user/yocto/build/tmp/work/cortexa9hf-vfp-neon-mx6-poky-linux-gnueabi/qtbase/5.1.1-r0/build/src/plugins/platforms/xcb'
make[3]: *** [sub-xcb-make_first] Error 2
make[3]: Leaving directory
`/home/user/yocto/build/tmp/work/cortexa9hf-vfp-neon-mx6-poky-linux-gnueabi/qtbase/5.1.1-r0/build/src/plugins/platforms'
make[2]: *** [sub-platforms-make_first] Error 2
make[2]: Leaving directory
`/home/user/yocto/build/tmp/work/cortexa9hf-vfp-neon-mx6-poky-linux-gnueabi/qtbase/5.1.1-r0/build/src/plugins'
make[1]: *** [sub-plugins-make_first] Error 2
make[1]: Leaving directory
`/home/user/yocto/build/tmp/work/cortexa9hf-vfp-neon-mx6-poky-linux-gnueabi/qtbase/5.1.1-r0/build/src'
make: *** [sub-src-make_first] Error 2
ERROR: oe_runmake failed
WARNING: exit code 1 from a shell command.
*My conf/bblayer.conf is as below:*
LCONF_VERSION = "6"
BBPATH = "${TOPDIR}"
BSPDIR := "${@os.path.abspath(os.path.dirname(d.getVar('FILE', True)) +
'/../..')}"
BBFILES ?= ""
BBLAYERS = " \
${BSPDIR}/sources/poky/meta \
${BSPDIR}/sources/poky/meta-yocto \
\
${BSPDIR}/sources/meta-openembedded/meta-oe \
${BSPDIR}/sources/meta-openembedded/meta-gnome \
${BSPDIR}/sources/meta-openembedded/meta-browser \
\
${BSPDIR}/sources/meta-fsl-arm \
${BSPDIR}/sources/meta-fsl-arm-extra \
${BSPDIR}/sources/meta-fsl-demos \
${BSPDIR}/sources/meta-qt5 \
"
*And conf/local.conf*
MACHINE ??= 'nitrogen6x'
DISTRO ?= 'poky'
PACKAGE_CLASSES ?= "package_rpm"
EXTRA_IMAGE_FEATURES = "debug-tweaks ssh-server-openssh"
IMAGE_INSTALL_append = " eglibc-staticdev strace gcc g++ binutils libgcc
libgcc-dev libstdc++ libstdc++-dev libstdc++-staticdev tslib-conf
tslib-tests tslib-calibrate openssh-sftp-server alsa-lib alsa-tools
alsa-state alsa-utils-alsaconf tslib evtest dbus nano git qtbase gstreamer
cairo pango fontconfig freetype pulseaudio qtbase qtbase-fonts
qtbase-plugins qtbase-examples chromium"
USER_CLASSES ?= "buildstats image-mklibs image-prelink"
LICENSE_FLAGS_WHITELIST = "commercial"
PATCHRESOLVE = "noop"
BB_DISKMON_DIRS = "\
STOPTASKS,${TMPDIR},1G,100K \
STOPTASKS,${DL_DIR},1G,100K \
STOPTASKS,${SSTATE_DIR},1G,100K \
ABORT,${TMPDIR},100M,1K \
ABORT,${DL_DIR},100M,1K \
ABORT,${SSTATE_DIR},100M,1K"
CONF_VERSION = "1"
BB_NUMBER_THREADS = '8'
PARALLEL_MAKE = '-j 8'
DL_DIR ?= "${BSPDIR}/downloads/"
ACCEPT_FSL_EULA = ""
Thanks
Alok
On Tue, Jan 21, 2014 at 2:25 PM, Eric Nelson <
eric.nelson@boundarydevices.com> wrote:
> On 01/21/2014 07:42 AM, Diego wrote:
>
>> Eric Nelson wrote:
>>
>>> I got complaints about the license for libav and
>>>
>>> was prompted to add this to local.conf:
>>> LICENSE_FLAGS_WHITELIST = "commercial"
>>>
>>> I think there's something screwy with that, though.
>>> The recipes in poky/meta/recipes-multimedia/libav/
>>> appear to have a combination of GPL and LGPL
>>> licenses.
>>>
>>
>> Eric, I'd bet the:
>> LICENSE_FLAGS = "commercial"
>> in the libav recipe is because of the patents that cover several of the
>> included codecs (gsm, x264, mp3lame, etc).
>>
>> Thanks Diego,
>
> There seem to be lots of disclaimers about this library:
> http://libav.org/legal.html
>
>
>
>
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale
>
--
Regards
Alok Kumar
[-- Attachment #2: Type: text/html, Size: 8913 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2014-01-24 21:30 UTC | newest]
Thread overview: 30+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-01-20 16:08 3.10.17-1.0.0_beta meta-fsl-bsp-release layer Alok Kumar
2014-01-20 16:21 ` Eric Nelson
2014-01-20 16:44 ` Alok Kumar
2014-01-20 20:58 ` Alok Kumar
2014-01-21 3:14 ` Eric Nelson
2014-01-21 14:42 ` Diego
2014-01-21 15:22 ` Booting 3.5.7 kernel on imx6sabresd? randy.krakora
2014-01-21 15:39 ` Otavio Salvador
2014-01-21 16:16 ` randy.krakora
2014-01-21 16:21 ` Otavio Salvador
2014-01-21 20:11 ` Ra37740@freescale.comndy
2014-01-21 20:23 ` Otavio Salvador
2014-01-21 21:03 ` Daiane.Angolini
2014-01-22 15:06 ` randy.krakora
2014-01-22 15:10 ` Fabio Estevam
2014-01-22 17:47 ` randy.krakora
2014-01-22 17:52 ` Fabio Estevam
2014-01-21 19:25 ` 3.10.17-1.0.0_beta meta-fsl-bsp-release layer Eric Nelson
2014-01-22 12:41 ` Alok Kumar
2014-01-23 8:41 ` Diego
2014-01-23 11:08 ` Alok Kumar
2014-01-23 15:08 ` Alok Kumar
2014-01-23 15:14 ` Gary Thomas
[not found] ` <CACoWYqXYmKAQ3L_9HjLvEEwJNQ56G+9ENcgup7t44D25EpTTcA@mail.gmail.com>
2014-01-23 16:06 ` Gary Thomas
2014-01-23 16:49 ` Alok Kumar
2014-01-24 16:41 ` Alok Kumar
2014-01-24 16:55 ` Eric Nelson
2014-01-24 21:30 ` Otavio Salvador
2014-01-23 15:43 ` Eric Nelson
-- strict thread matches above, loose matches on Subject: below --
2014-01-22 18:40 alokcherryhills
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.