[yocto] Toolchain with debug support

2015-10-12 Thread atulkumar singh 
Hi All,

Can anyone please tell me how to build a meta toolchain with debug support
by setting CFLAGS to "-g -O0".

I tried adding this into gcc recipe but that didn't worked out for me as
another option I even tried adding CFLAGS_gcc = "-g -O0".
But no success, actually I wish to debug inside a function.

Thanks and regards,
Atul
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Toolchain with debug support (atulkumar singh)

2015-10-12 Thread Taek Hyun Shin 
Hi,

Try the following:

TARGET_CFLAGS_append = " -g -O0"

TARGET_CXXFLAGS_append = " -g -O0"

 

 

Thanks,

 

Best Regards, Wily Taekhyun Shin

 

=
Wily Taekhyun Shin

Research Engineer
R Center
Telechips Inc.
Tel : + 82-2-3443-6792(Ext.390)

Fax : + 82-2-6424-7793 

Mobile : + 82-10-4376-5530

E-mail : ths...@telechips.com 

 
=
본 메일과 첨부 문서는 ㈜텔레칩스의 고유 권한인 비밀 정보를 포함하고 있습니다.
㈜텔레칩스의 사전 서면 승인 없이 어떠한 형태나 방법으로도 본 비밀정보를 제3자에게
누설하거나, 전달하거나, 사용할 수 없습니다. 만일 귀하가 메일의 올바른 수신인이 아닐 경우,
본 메일을 반송하고 삭제하여 주시기 바랍니다. 
=

This mail and attachments contain confidential information of Telechips Inc. 
which has its own authority.
It is not allowed to disclose,transmit or use this confidential information to 
the third parties without the 
prior written consent of Telechips Inc. by any form or means. 
If you are not the intended recipient, please notify the sender immediately and 
do not disclose the 
contents and destroy all copies of the original message.
=

 

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Why RDEPENDS wont install packages in rootfs (Vivek Per)

2015-10-12 Thread Taek Hyun Shin 
Hi,

Results of the image class is different from the result of the package 
class(rpm, deb, ipk)

RDEPENDS is used by the package class

For example, in the case of using the rpm

Add the contents of the RDEPENDS to Requires items in the spec file 

This information applies when you create the rpm by using a spec file.

 

When you create a rootfs to install the contents of IMAGE_INSTALL in the image 
class

also to install using rpm, using --requires option to install an additional 
package to find those that have dependencies.

 

IMAGE_INSTALL an item to install the rootfs, RDEPENDS is the option to use when 
specifying a package with a dependency

 

 

Thanks,

Best Regards, Wily Taekhyun Shin

 

=
Wily Taekhyun Shin

Research Engineer
R Center
Telechips Inc.
Tel : + 82-2-3443-6792(Ext.390)

Fax : + 82-2-6424-7793 

Mobile : + 82-10-4376-5530

E-mail : ths...@telechips.com 

 
=
본 메일과 첨부 문서는 ㈜텔레칩스의 고유 권한인 비밀 정보를 포함하고 있습니다.
㈜텔레칩스의 사전 서면 승인 없이 어떠한 형태나 방법으로도 본 비밀정보를 제3자에게
누설하거나, 전달하거나, 사용할 수 없습니다. 만일 귀하가 메일의 올바른 수신인이 아닐 경우,
본 메일을 반송하고 삭제하여 주시기 바랍니다. 
=

This mail and attachments contain confidential information of Telechips Inc. 
which has its own authority.
It is not allowed to disclose,transmit or use this confidential information to 
the third parties without the 
prior written consent of Telechips Inc. by any form or means. 
If you are not the intended recipient, please notify the sender immediately and 
do not disclose the 
contents and destroy all copies of the original message.
=

 

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Webkit2gtk opengl issue

2015-10-12 Thread Mark O'Donovan 
On Mon, Sep 28, 2015 at 11:51 AM, Mark O'Donovan  wrote:
> On Fri, Sep 25, 2015 at 10:01 PM, Trevor Woerner  wrote:
>> On 09/23/15 07:53, Mark O'Donovan wrote:
>>> I am working on an am335x based project, with a webkitgtk
>>> program on the screen, displaying a simple webpage.
>>>
>>> I want to use a standard yocto kernel, which I believe
>>> means I must do without the SGX hardware acceleration
>>> until an open-source driver is available.
>>
>> You need to use whatever kernel the accelerated drivers were written
>> against. Sometimes that can be fairly recent, other times: not so much.
>>
>>> Thus in fido I had added opengl to DISTRO_FEATURES_remove
>>> This worked with webkitgtk 1.x
>>>
>>> The webkitgtk 2.x recipe  also specifies opengl as optional.
>>> However it depends on gtk+3 which depends on libepoxy
>>> which requires virtual/egl.
>>
>> For ARM SoCs/boards that have mali (which isn't your case, but is mine),
>> the user-space binary-only mali drivers PROVIDE egl, so it is possible
>> for me to build libepoxy with DISTRO_FEATURES_remove = "opengl" and the
>> mali test app and x11 server both build and run correctly.
>>
>>> Is this an oversight??
>>>
>>> Is it possible to build webkit 2.x without opengl??
>>
>> I don't know. But in the mali case it is possible to have mali provide
>> egl/gles1/gles2 and have mesa-gl provide an opengl-only solution as a
>> fall-back for any non-egl/gles1/2 apps (or at least theoretically it is).
>>
>> Hope this helps.
>
>
>
> Thanks Ross, Trevor,
>
> With webkitgtk 1.8 I was having issues with opengl present.
> It seems not to be the case here.
> My screen is completely blank.
> I have discovered that the page fails to render due to
> javascript.
> Disabling JIT solves this issue.
> The example below fails to render if JIT is enabled.
> It will however render if I uncomment the 'alert' statement.
>
> 
> 
> 
> Test
> 
> 
> Page Rendered
> 
>   //alert("JavaScript works")
> 
> 
> 
>
> Is there anything you would like me to test??

So has anyone else come across this??
If not then I will file a bug for JIT in webkitgtk on arm7.

Mark
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] packagegroup not appearing in HOB

2015-10-12 Thread Barros Pena, Belen 


On 07/10/2015 18:36, "yocto-boun...@yoctoproject.org on behalf of Allen
Curtis"  wrote:

>Hello,
>
>I created a packagegroup file as per the instructions called
>packagegroup-foo.bb
>
>Within that file I define 2 package groups as such.
>
>PACKAGES = "\
> packagegroup-foo-apps \
> packagegroup-foo-tools \
>"
>
>RDEPENDS_packagegroup-foo-apps = "Š"
>
>RDEPENDS_packagegroup-foo-tools = "Š"
>
>However, when I run HOB and inspect the list of packages it shows
>packagegroup-foo but it does not list packagegroup-foo-apps or
>packagegroup-foo-tools.
>
>Is this correct?
>
>How do I verify the groups are created correctly so I can complete
>implementation using the new group definitions?

Hi Allen,

Hob development has been on hold for quite a while, so I am not sure how
reliable the list of packages currently is.

If you would like to know if your package group is set up correctly, and
you want to do it with a graphical tool, you can use Toaster, which is the
replacement for Hob. There is a manual here

www.yoctoproject.org/docs/1.8/toaster-manual/toaster-manual.html

And a quick video tutorial here

https://www.youtube.com/watch?v=f3gDg75FwFo

Assuming you are building with 1.8 fido, you can set up Toaster
dependencies as explained here

http://www.yoctoproject.org/docs/1.8/toaster-manual/toaster-manual.html#toa
ster-manual-start

And then run Toaster locally as explained here

http://www.yoctoproject.org/docs/1.8/toaster-manual/toaster-manual.html#set
ting-up-locally-and-running-in-build-mode

You would then need to import your custom layer (the one providing your
package group) and build packagegroup-foo

Once the build finishes, you can select it, view the list of packages
built, search for packagegroup-foo, and look at its dependencies. If the
package group is working as intended, the dependencies should list
packagegroup-foo-apps and packagegroup-foo-tools, and in turn the
dependencies for each of those should list the RDEPENDS you specified.

I know this all sounds quite convoluted, but it's actually not too bad :)
This is how the RDEPENDS for a package group look like in Toaster

http://imgur.com/E7OCp08


If you have any questions, let me know.

Cheers

Belén


>
>TIA
>
>-- 
>___
>yocto mailing list
>yocto@yoctoproject.org
>https://lists.yoctoproject.org/listinfo/yocto

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] FW: packages are compiled but not included in the final image

2015-10-12 Thread Thanassis Silis 


From: djnass...@hotmail.com
To: yocto-boun...@yoctoproject.org
Subject: [yocto] packages are compiled but not included in the final image
Date: Mon, 12 Oct 2015 16:53:51 +







Hi all,
I am attempting to add a few executables that are not there by default in a 
"core-image-base" image.

so my conf/local.conf looks like

MACHINE ??= 'imx6qsabrelite'
#after version 1.5, use
#MACHINE ??= 'nitrogen6x'

DISTRO ?= 'poky'
PACKAGE_CLASSES ?= "package_rpm package_ipk package_deb"

#dev see http://www.yoctoproject.org/docs/1.8/mega-manual/mega-manual.html
EXTRA_IMAGE_FEATURES = " debug-tweaks "
EXTRA_IMAGE_FEATURES += " package-management  "
EXTRA_IMAGE_FEATURES += " ssh-server-openssh lmsensors "

USER_CLASSES ?= "buildstats image-mklibs image-prelink"
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 = '2'
PARALLEL_MAKE = '-j 2'
ACCEPT_FSL_EULA = ""


#webserver
CORE_IMAGE_EXTRA_INSTALL += " apache2 php "

CORE_IMAGE_EXTRA_INSTALL += " rrdtool bc screen ntp minicom  "

The image has been created but I have the following problems.

while ntpd has been installed on the image and works fine, the executable 
ntpdate is NOT there.
bash is also missing from core-image-base . is that to be expected? Should I 
add it as a CORE_IMAGE_EXTRA_INSTALL or as an EXTRA_IMAGE_FEATURE ?



  -- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] FW: packages are compiled but not included in the final image

2015-10-12 Thread Christopher Larson 
On Mon, Oct 12, 2015 at 10:08 AM, Thanassis Silis 
wrote:

> From: djnass...@hotmail.com
> To: yocto-boun...@yoctoproject.org
> Subject: [yocto] packages are compiled but not included in the final image
> Date: Mon, 12 Oct 2015 16:53:51 +
>
> Hi all,
> I am attempting to add a few executables that are not there by default in
> a "core-image-base" image.
>
> so my conf/local.conf looks like
>
> MACHINE ??= 'imx6qsabrelite'
> #after version 1.5, use
> #MACHINE ??= 'nitrogen6x'
>
> DISTRO ?= 'poky'
> PACKAGE_CLASSES ?= "package_rpm package_ipk package_deb"
>
> #dev see http://www.yoctoproject.org/docs/1.8/mega-manual/mega-manual.html
> EXTRA_IMAGE_FEATURES = " debug-tweaks "
> EXTRA_IMAGE_FEATURES += " package-management  "
> EXTRA_IMAGE_FEATURES += " ssh-server-openssh lmsensors "
>
> USER_CLASSES ?= "buildstats image-mklibs image-prelink"
> 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 = '2'
> PARALLEL_MAKE = '-j 2'
> ACCEPT_FSL_EULA = ""
>
>
> #webserver
> CORE_IMAGE_EXTRA_INSTALL += " apache2 php "
>
> CORE_IMAGE_EXTRA_INSTALL += " rrdtool bc screen ntp minicom  "
>
> The image has been created but I have the following problems.
>
> while ntpd has been installed on the image and works fine, the executable
> ntpdate is NOT there.
> bash is also missing from core-image-base . is that to be expected? Should
> I add it as a CORE_IMAGE_EXTRA_INSTALL or as an EXTRA_IMAGE_FEATURE ?
>

Yes, that's expected, busybox is used by default. Add bash yourself if you
want it, or use a different image.

For ntpdate, it's split out into its own package, so add 'ntpdate' to
CORE_IMAGE_EXTRA_INSTALL as well if you want that.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] FW: packages are compiled but not included in the final image

2015-10-12 Thread Christopher Larson 
On Mon, Oct 12, 2015 at 12:02 PM, Thanassis Silis 
wrote:

> Hi Christopher,
> thank you for the quick response. may I ask the following as well:
>
> i am attempting to include "lmsensors"  as well as a
> CORE_IMAGE_EXTRA_INSTALL.
> I get errors while do_rootfs() runs
>
> Error: lmsensors not found in the base feeds (imx6qsabrelite
> armv7a-vfp-neon armv7a-vfp armv7a armv6-vfp armv6 armv5e-vfp armv5e
> armv5-vfp armv5 armv4 arm noarch any all).
> | ERROR: Function failed: do_rootfs (see
> /mnt/hd/nassdata/yocto/fsl-community-bsp/build/tmp/work/imx6qsabrelite-poky-linux-gnueabi/fsl-image-test/1.0-r0/temp/log.do_rootfs.16989
> for further information)
> ERROR: Task 7
> (/mnt/hd/nassdata/yocto/fsl-community-bsp/sources/meta-fsl-demos/recipes-fsl/images/
> fsl-image-test.bb, do_rootfs) failed with exit code '1'
> NOTE: Tasks Summary: Attempted 5692 tasks of which 5690 didn't need to be
> rerun and 1 failed.
> No currently running tasks (5691 of 5693)
>
> it doesn't seem to be accepted but the log is not particularly
> informative.
> In other cases that i googled it seemed that setting
>
> ALLOW_EMPTY_${PN}-dbg = "1"
> ALLOW_EMPTY_${PN}-dev = "1"
>
> in sources/poky/meta/conf/bitbake.conf solved their issues. But these are
> already set in my case.
>

lmsensors emits a ton of binary packages, you'll have to see which ones you
need. Read meta-oe/recipes-support/lm_sensors/lmsensors_3.4.0.bb, the
PACKAGES lines.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[linux-yocto] [PATCH] drm/i915: Fix the VBT child device parsing for BSW

2015-10-12 Thread Tan Jui Nee 
From: Ville Syrjälä 

Recent BSW VBT has a VBT child device size 37 bytes instead of the 33
bytes our code assumes. This means we fail to parse the VBT and thus
fail to detect eDP ports properly and just register them as DP ports
instead.

Fix it up by using the reported child device size from the VBT instead
of assuming it matches out struct defintions.

The latest spec I have shows that the child device size should be 36
bytes for rev >= 195, however on my BSW the size is actually 37 bytes.
And our current struct definition is 33 bytes.

Feels like the entire VBT parses would need to be rewritten to handle
changes in the layout better, but for now I've decided to do just the
bare minimum to get my eDP port back.

Cc: Vijay Purushothaman 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Damien Lespiau 
Signed-off-by: Daniel Vetter 
(cherry picked from commit 90e4f1592bb6e82f6690f0e05a8aadcf04d7bce7)
Signed-off-by: abdul arif abdul muttalib 
Signed-off-by: Tan Jui Nee 
---
 drivers/gpu/drm/i915/intel_bios.c | 26 +-
 drivers/gpu/drm/i915/intel_bios.h |  4 ++--
 2 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index c684085..4cbd325 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -447,6 +447,12 @@ parse_general_definitions(struct drm_i915_private 
*dev_priv,
}
 }
 
+static union child_device_config *
+child_device_ptr(struct bdb_general_definitions *p_defs, int i)
+{
+   return (void *) _defs->devices[i * p_defs->child_dev_size];
+}
+
 static void
 parse_sdvo_device_mapping(struct drm_i915_private *dev_priv,
  struct bdb_header *bdb)
@@ -476,10 +482,10 @@ parse_sdvo_device_mapping(struct drm_i915_private 
*dev_priv,
block_size = get_blocksize(p_defs);
/* get the number of child device */
child_device_num = (block_size - sizeof(*p_defs)) /
-   sizeof(*p_child);
+   p_defs->child_dev_size;
count = 0;
for (i = 0; i < child_device_num; i++) {
-   p_child = &(p_defs->devices[i]);
+   p_child = child_device_ptr(p_defs, i);
if (!p_child->old.device_type) {
/* skip the device block if device type is invalid */
continue;
@@ -1067,25 +1073,19 @@ parse_device_mapping(struct drm_i915_private *dev_priv,
DRM_DEBUG_KMS("No general definition block is found, no devices 
defined.\n");
return;
}
-   /* judge whether the size of child device meets the requirements.
-* If the child device size obtained from general definition block
-* is different with sizeof(struct child_device_config), skip the
-* parsing of sdvo device info
-*/
-   if (p_defs->child_dev_size != sizeof(*p_child)) {
-   /* different child dev size . Ignore it */
-   DRM_DEBUG_KMS("different child size is found. Invalid.\n");
+   if (p_defs->child_dev_size < sizeof(*p_child)) {
+   DRM_ERROR("General definiton block child device size is too 
small.\n");
return;
}
/* get the block size of general definitions */
block_size = get_blocksize(p_defs);
/* get the number of child device */
child_device_num = (block_size - sizeof(*p_defs)) /
-   sizeof(*p_child);
+   p_defs->child_dev_size;
count = 0;
/* get the number of child device that is present */
for (i = 0; i < child_device_num; i++) {
-   p_child = &(p_defs->devices[i]);
+   p_child = child_device_ptr(p_defs, i);
if (!p_child->common.device_type) {
/* skip the device block if device type is invalid */
continue;
@@ -1105,7 +1105,7 @@ parse_device_mapping(struct drm_i915_private *dev_priv,
dev_priv->vbt.child_dev_num = count;
count = 0;
for (i = 0; i < child_device_num; i++) {
-   p_child = &(p_defs->devices[i]);
+   p_child = child_device_ptr(p_defs, i);
if (!p_child->common.device_type) {
/* skip the device block if device type is invalid */
continue;
diff --git a/drivers/gpu/drm/i915/intel_bios.h 
b/drivers/gpu/drm/i915/intel_bios.h
index 6afd5be..af0b476 100644
--- a/drivers/gpu/drm/i915/intel_bios.h
+++ b/drivers/gpu/drm/i915/intel_bios.h
@@ -277,9 +277,9 @@ struct bdb_general_definitions {
 * And the device num is related with the size of general definition
 * block. It is obtained by using

[linux-yocto] [PATCH] Backport eDP bug fix for Braswell

2015-10-12 Thread Tan Jui Nee 
Hi,

This patch is targeted for Braswell bug fixes on i915 graphics driver.
We encountered issues which eDP unable to initialize due to changes in
BIOS VBT.
The patch was backported from upstream kernel into linux-yocto-4.1.
The functionality and bug fixed by the patch has been built and tested
on the Cherry Hill platform.

This patchset was targeted to merge into linux-yocto-4.1 on standard/base 
branch.

Please review and provide feedback if any.

Thank you.

Best regards,
Jui Nee

Ville Syrjälä (1):
  drm/i915: Fix the VBT child device parsing for BSW

 drivers/gpu/drm/i915/intel_bios.c | 26 +-
 drivers/gpu/drm/i915/intel_bios.h |  4 ++--
 2 files changed, 15 insertions(+), 15 deletions(-)

-- 
1.9.1

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [yocto] [meta-raspberrypi][PATCH V4 1/5] userland: Fix install prefix and generate pkgconfigs

2015-10-12 Thread Joachim Schiele 
On 03.10.2015 23:53, Andrei Gherzan wrote:
> On Sat, Oct 03, 2015 at 02:47:24PM -0700, Khem Raj wrote:
>> On Sat, Oct 3, 2015 at 2:27 PM, Andrei Gherzan  wrote:
>>> On Sat, Oct 03, 2015 at 10:46:07PM +0200, Andrei Gherzan wrote:
 On Sat, Oct 03, 2015 at 10:40:50PM +0200, Andrei Gherzan wrote:
> On Sat, Oct 03, 2015 at 10:33:12PM +0200, Andrei Gherzan wrote:
>> On Sat, Oct 03, 2015 at 01:31:24PM -0700, Khem Raj wrote:
>>> On Sat, Oct 3, 2015 at 1:11 PM, Andrei Gherzan  
>>> wrote:
 On Sat, Oct 03, 2015 at 01:06:55PM -0700, Khem Raj wrote:
> On Sat, Oct 3, 2015 at 12:18 PM, Andrei Gherzan  
> wrote:
>> I tested with and without - same result.
>> DISTRO_FEATURES="alsa argp bluetooth ext2 irda largefile pcmcia 
>> usbgadget
>> usbhost wifi xattr nfs zeroconf pci 3g nfc x11 ipv4 ipv6 
>> libc-backtrace
>> libc-big-macros libc-bsd libc-cxx-tests libc-catgets libc-charsets 
>> libc-crypt
>> libc-crypt-ufc libc-db-aliases libc-envz libc-fcvt libc-fmtmsg 
>> libc-fstab
>> libc-ftraverse  libc-getlogin libc-idn libc-inet-anl 
>> libc-libm
>> libc-locales libc-locale-code   libc-memusage 
>> libc-nis
>> libc-nsswitch libc-rcmd libc-rtld-debug libc-spawn libc-streams 
>> libc-sunrpc
>> libc-utmp libc-utmpx libc-wordexp libc-posix-clang-wchar 
>> libc-posix-regexp
>> libc-posix-regexp-glibc libc-posix-wchar-io 
>> largefile
>> opengl ptest multiarch wayland pulseaudio sysvinit bluez5"
>>
>> No modification to the default poky distro.
>
> hmm I am using angstrom and it works there and for verification I now
> tried with OE-Core ( alone ) it works there too, can you check some
> other parameters that are there in your sandbox ? here is my build
>
>  MACHINE=raspberrypi2 bitbake userland
> Parsing recipes: 100%
> |##|
> ETA:  00:00:00
> Parsing of 918 .bb files complete (0 cached, 918 parsed). 1350
> targets, 59 skipped, 0 masked, 0 errors.
> NOTE: Resolving any missing task queue dependencies
>
> Build Configuration:
> BB_VERSION= "1.28.0"
> BUILD_SYS = "x86_64-linux"
> NATIVELSBSTRING   = "Ubuntu-14.04"
> TARGET_SYS= "arm-oe-linux-gnueabi"
> MACHINE   = "raspberrypi2"
> DISTRO= "nodistro"
> DISTRO_VERSION= "nodistro.0"
> TUNE_FEATURES = "arm armv7a vfp thumb neon callconvention-hard
> vfpv4 cortexa7"
> TARGET_FPU= "vfp-vfpv4-neon"
> meta-raspberrypi  = 
> "kraj/master:a903a9cd18ae556121265da93ed74f857944a0da"
> meta  = 
> "kraj/master:602e512b92bcc78403144fedeb4211bbf56ff1c8"
>
> NOTE: Preparing RunQueue
> NOTE: Executing SetScene Tasks
> NOTE: Executing RunQueue Tasks
> NOTE: Tasks Summary: Attempted 454 tasks of which 315 didn't need to
> be rerun and all succeeded.

 Here is my build configuration.

 Build Configuration:
 BB_VERSION= "1.28.0"
 BUILD_SYS = "x86_64-linux"
 NATIVELSBSTRING   = "Arch-rolling"
 TARGET_SYS= "arm-poky-linux-gnueabi"
 MACHINE   = "raspberrypi2"
 DISTRO= "poky"
 DISTRO_VERSION= "2.0"
 TUNE_FEATURES = "arm armv7a vfp thumb neon callconvention-hard 
 vfpv4
 cortexa7"
 TARGET_FPU= "vfp-vfpv4-neon"
 meta
 meta-yocto
 meta-yocto-bsp= "master:eac61f37e36099f74485dab398b57f3812826d17"
 meta-raspberrypi  = "master:48da0cdc5fb147a20b41a77b2dfeef4efd483b32"
 meta-oe
 meta-multimedia   = "master:f4533380c8a5c1d229f69ee0c2ef9d187ef8"


 But anyway can you please check in your userland install dir for the 
 header I'm
 missing? Or in sysroot.
>>>
>>> its part of userland itself so no other package should be needed and
>>> not required in sysroot
>>>
>>> ./work/raspberrypi2-oe-linux-gnueabi/userland/git-r5/package/usr/src/debug/userland/git-r5/build/interface/vmcs_host/wayland-dispmanx-server-protocol.h
>>> ./work/raspberrypi2-oe-linux-gnueabi/userland/git-r5/packages-split/userland-dbg/usr/src/debug/userland/git-r5/build/interface/vmcs_host/wayland-dispmanx-server-protocol.h
>>>

[yocto] FW: root password in a core-image-base without "debug-tweaks" ?

2015-10-12 Thread Thanassis Silis 


From: djnass...@hotmail.com
To: yocto-boun...@yoctoproject.org
Subject: root password in a core-image-base without "debug-tweaks" ?
Date: Mon, 12 Oct 2015 19:12:55 +




hi all,
I bitbaked a core-image-base without "debug-tweaks" , and now i am greeted on 
ttymxc1 with a login , but it also asks for password.
empty password is not accepted.
/etc/shadow states "root::..." so the root password is supposedly empty. but I 
cannot login.

as for ssh I copied my id_rsa.pub over to /home/root/.ssh/authorized_keys in 
order to ssh to the board.

thank you in advance for your help

  -- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] FW: root password in a core-image-base without "debug-tweaks" ?

2015-10-12 Thread Mike Looijmans 

On 12-10-15 23:39, Thanassis Silis wrote:


I bitbaked a core-image-base without "debug-tweaks" , and now i am greeted on
ttymxc1 with a login , but it also asks for password.
empty password is not accepted.
/etc/shadow states "root::..." so the root password is supposedly empty. but I
cannot login.


Yep, turning it on makes the box too vulnerable and leaving it out makes the 
box inaccessible.


Here's a simple solution to allow you to login but without crippling SSH:

https://github.com/OpenPLi/openpli-oe-core/blob/master-next/meta-openpli/recipes-openpli/images/openpli-image.bb#L45



Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto