Re: [yocto] [meta-raspberrypi][PATCH 5/5] rpi-default-providers: Switch providers according to used gfx stack

[Javier Martinez Canillas]

Hello Khem,

On 08/06/2015 04:54 AM, Khem Raj wrote:
> On Tue, Aug 4, 2015 at 11:34 PM, Javier Martinez Canillas
>  wrote:
>>> who defines the distro feature ?
>>>
>>>
>>
>> Distro features AFAICT are user defined options, you can for example have
>> the following in your conf/local.conf:
>>
>> DISTRO_FEATURES_append = " vc4-gfx"
> 
> I wasnt trying to learn about what DISTRO_FEATURES are, I was trying
> to draw attention to the fact that meta-rpi being a BSP layer

Ok, sorry. But I believe it's more productive to just do suggestions
instead of asking rhetorical questions that can be misunderstood :-)

> was trying to define a lot more than a BSP layer is supposed to do. So
> if its a distro feature, I would like it to work as expected on other
> machines besides raspberrypi. If thats not applicable then we should
> rethink if it could be folded into MACHINE_FEATURES if it needs to be

Yes, I in fact was not sure if it should be a distro or machine feature
and then decided on the former because there is more than the kernel to
make it work like changing mesa configure options. But as mentioned to
Andrea Müller, probably we should ship a mesa .bbappend for this in the
BSP so I agree that a MACHINE_FEATURE will make more sense.

> a distro feature then propose it to OE-Core, at the very least
> document them in README of this layer. Or separate it out into a
> common layer which rpi BSPs will depend on.
> but think beyond single machine when deciding on adding distro
> features, there are distros based on OE which support multiple
> machines
> 

Yes, I know that there are distros than support more tha one machine but
I thought it was OK to have machine specific DISTRO_FEATURES but seems I
was wrong.

Another option is to add a different machine (i.e: raspberrypi2-vc4.conf)
so instead of changing the default provider based on a feature, it can
be set based on the machine. Petter Mabäcker asked to have a different BB
recipe for the vc4 kernel so the conditional include of the vc4 patches
will not be needed on the kernel recipe either.

What do you think of this option?

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH 0/5] Add support for 4.1 kernel with vc4 DRM/KMS driver

[Javier Martinez Canillas]

Hello Petter,

On 08/05/2015 10:48 PM, Petter Mabäcker wrote:
>  
> 
> 2015-08-04 18:07 skrev Javier Martinez Canillas: 
> 
>> Hello Petter,
>>
> 
>> Thanks a lot for your feedback.
>>
>> On 08/04/2015 11:16 AM, Petter
> Mabäcker wrote:
>>
>>> On 07/30/2015 10:34 AM, Javier Martinez Canillas
> wrote: 
>>>
 Hello Andrei, This series adds support for Eric Anholt's
> v4.1 kernel, that has support for the vc4 DRM/KMS driver. Which is the
> new open source graphics driver stack for the Raspberry Pi to be used
> instead of the userland driver. We are using it in the Tizen port to
> RPI2 [0] and are trying to push all the patches back to the tizen-distro
> and meta-raspberrypi OE layers so I'm posting these patches to get your
> feedback. The v4.1 kernel is under heavy development so is a
> work-in-progress and should not be used in production. That's why a
> default preference of -1 is set and the kernel only is enabled if the
> "vc4-gfx" feature is added to the DISTRO_FEATURES variable. But even
> when it's still a development kernel, having the recipe in the
> meta-raspberrypi will allow people to test it. The patches are for:
> Patch 1/5 makes optional to add the kgdboc kernel command line parameter
> Patch 2/5 allows to set the mask_gpu_interrupt0 option in config.txt
> Patch 3/5 changes the partition layout to add more space for boot files
> Patch 4/5 adds a recipe for the 4.1 and some patches to make it stable
> Patch 5/5 switchs the default providers according to the gfx stack used
> One problem I found is that the latest RPI kernels changed the path for
> the DT overlays after commit 739c586c8757 ("BCM270X_DT: Move the
> overlays into a subdirectory, adding the README") [1] so the kernel
> fails to build with the default KERNEL_DEVICETREE. I tried to change
> get_dts() function logic to take this into account but found that it
> would had been a more intrusive change and KERNEL_DEVICETREE will have
> to be changed anyways once the recipes for the other kernels are updated
> to the latest HEAD so for now I just define the following on local.conf
> to make it build:
>>> As long as we bump SRCREV for 3.18 kernel as well,
> I see no problem. Since then the KERNEL_DEVICETREE default value can
> look the same in all situations (both 3.18 and 4.x can handle the new
> structure and we get no compatibility issues) and for older kernels
> (3.12 and 3.14) it doesn't matter since they don't have native device
> tree support and will turn device tree support off by default.
>>
>> Yes,
> that's what I meant when I said that the problem will be solved once
>>
> all the recipes for DT enabled kernels are updated to the latest
> branch
>> HEAD. But I didn't want to do that in this series since I
> wanted the
>> changes to be as less intrusive as possible.
> 
> Ok, sounds
> reasonable. Alex found some problems when bumping 3.18 to latest but
> when that is solved he can push the 3.18 bumping and prepare the
> KERNEL_DEVICETREE variable with the new subdir for overlays. 
>

Awesome.
 
>>>
> KERNEL_DEVICETREE = " bcm2708-rpi-b.dtb bcm2708-rpi-b-plus.dtb
> bcm2709-rpi-2-b.dtb overlays/hifiberry-amp-overlay.dtb
> overlays/hifiberry-dac-overlay.dtb
> overlays/hifiberry-dacplus-overlay.dtb
> overlays/hifiberry-digi-overlay.dtb overlays/iqaudio-dac-overlay.dtb
> overlays/iqaudio-dacplus-overlay.dtb overlays/lirc-rpi-overlay.dtb
> overlays/pps-gpio-overlay.dtb overlays/w1-gpio-overlay.dtb
> overlays/w1-gpio-pullup-overlay.dtb " [0]:
> http://blogs.s-osg.org/tizen-rpi2-now-supporting-3d-acceleration/ [1]
> [1]: https://github.com/raspberrypi/linux/commit/739c586c8757 [2] Best
> regards, --- Javier Martinez Canillas Open Source Group Samsung Research
> America Derek Foreman (4): rpi-config: Allow to mask GPU irqs
> sdcard_image-rpi.bbclass: Allocate more space for boot partition
> linux-raspberrypi: Add a 4.1 linux kernel with vc4 support
> rpi-default-providers: Switch providers according to used gfx stack
> Mauro Carvalho Chehab (1): linux-raspberrypi.inc: Make kgdboc kernel
> param optional README | 38 +-- classes/sdcard_image-rpi.bbclass | 6
> +- conf/machine/include/rpi-default-providers.inc | 8 +-
> conf/machine/include/rpi-default-versions.inc | 2 +-
> recipes-bsp/bootfiles/rpi-config_git.bb | 6 ++
> recipes-kernel/linux/linux-raspberrypi.inc | 5 +-
> ..._defconfig-Enable-config-options-for-vc4-.patch | 48 +
> ...-ARM-dts-Fix-i2c-for-bcm2709-RPI2-B-board.patch | 85 +++
> .../0003-drm-vc4-Use-the-fbdev_cma-helpers.patch | 115
> + .../0004-drm-vc4-Allow-vblank-to-be-disabled.patch
> | 26 + .../0005-drm-vc4-Disable-KMS-operations.patch | 95
> + recipes-kernel/linux/linux-raspberrypi_4.1.bb | 16 +++
> 12 files changed, 433 insertions(+), 17 deletions(-) create mode 100644
> recipes-kernel/linux/linux-raspberrypi/0001-ARM-bcm2709_defconfig-Enable-config-options-for-vc4-.patch
> create mode 100644
> recipes-kernel/linux/linux-raspberrypi/0002-ARM-dts-Fix-i2c-for-b

Re: [yocto] [meta-raspberrypi][PATCH 5/5] rpi-default-providers: Switch providers according to used gfx stack

[Andreas Müller]

On Thu, Aug 6, 2015 at 8:59 AM, Javier Martinez Canillas
 wrote:
> Yes, I in fact was not sure if it should be a distro or machine feature
> and then decided on the former because there is more than the kernel to
> make it work like changing mesa configure options. But as mentioned to
> Andrea Müller, probably we should ship a mesa .bbappend for this in the
> BSP so I agree that a MACHINE_FEATURE will make more sense.
Suggestions:

* Mesa: A simple append with

PACKAGECONFIG_append_rpi += " gallium"
GALLIUMDRIVERS_rpi = "vc4"

would do. If you check mesa.inc in oe-core others (intel) do similar
(we might have to wait for a more recent mesa expected in September).

* kernel: have different name e.g linux-raspberrypi-vc4

The selection is done in this layer by changing default providers. In
a first step this could be done manually - aided by a helpful comment.

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

Re: [yocto] qemux86 and generic86

[Bruce Ashfield]

On Wed, Aug 5, 2015 at 1:44 AM, Amit Kumar
 wrote:
> Hi,
>
>
>
> I have a basic doubts on qemux86 build application image is not working on
> generic86 target.
>
> Suppose I have a application which I would like to test on target board, but
> the target board is not yet ready. If I will want to test that application I
> will use the qemu  to test.
>
> But if I build the application for qemu, it does not work for actual target
> board.
>
> Could you please let me know the details reason. If I want to do like that
> what I should have to do.
>

Are you concerned about the kernel, or userspace ? You say 'application', but
I wanted to be sure.

Assuming that your application is generic, and isn't using any machine specific
ops, then it will work fine on qemu and on a h/w target.

That being said, applications are typically rebuilt o be included in a different
image when switching between qemu and the h/w .. so they'l be rebuild and
relinked anyway.

Bruce

>
>
>
>
> Thanks & Regards
>
> Amit
>
> L&T Technology Services Ltd
>
> www.LntTechservices.com
>
> This Email may contain confidential or privileged information for the
> intended recipient (s). If you are not the intended recipient, please do not
> use or disseminate the information, notify the sender and delete it from
> your system.
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [][meta-selinux] libpam: Upgrade recipe with wildcard.

[Philip Tricca]

This is a duplicate. Please disregard in favor of:
https://lists.yoctoproject.org/pipermail/yocto/2015-July/025833.html

Philip

On 08/02/2015 08:52 AM, fl...@twobit.us wrote:
> From: Philip Tricca 
> 
> The DESTDIR prefix patch is now upstream and no longer necessary.
> 
> Signed-off-by: Philip Tricca 
> ---
>  .../pam/libpam/sepermit-add-DESTDIR-prefix.patch   | 31 
> --
>  recipes-extended/pam/libpam_1.%.bbappend   |  8 ++
>  recipes-extended/pam/libpam_1.1.6.bbappend | 10 ---
>  3 files changed, 8 insertions(+), 41 deletions(-)
>  delete mode 100644 
> recipes-extended/pam/libpam/sepermit-add-DESTDIR-prefix.patch
>  create mode 100644 recipes-extended/pam/libpam_1.%.bbappend
>  delete mode 100644 recipes-extended/pam/libpam_1.1.6.bbappend
> 
> diff --git a/recipes-extended/pam/libpam/sepermit-add-DESTDIR-prefix.patch 
> b/recipes-extended/pam/libpam/sepermit-add-DESTDIR-prefix.patch
> deleted file mode 100644
> index d48d386..000
> --- a/recipes-extended/pam/libpam/sepermit-add-DESTDIR-prefix.patch
> +++ /dev/null
> @@ -1,31 +0,0 @@
> -Subject: [PATCH] libpam: add missing DESTDIR prefix
> -
> -The DESTDIR prefix is missing, this will cause build failures for
> -mkdir /var/run/sepermit on the host.
> -
> -| mkdir -p /var/run/sepermit
> -| mkdir: cannot create directory `/var/run/sepermit': Permission denied
> -
> -Upstream-Status: Pending
> -
> -Signed-off-by: Xin Ouyang 
> 
> - modules/pam_sepermit/Makefile.am |2 +-
> - 1 files changed, 1 insertions(+), 1 deletions(-)
> -
> -diff --git a/modules/pam_sepermit/Makefile.am 
> b/modules/pam_sepermit/Makefile.am
> -index cfc5594..bc82275 100644
>  a/modules/pam_sepermit/Makefile.am
> -+++ b/modules/pam_sepermit/Makefile.am
> -@@ -35,7 +35,7 @@ if HAVE_LIBSELINUX
> -   securelib_LTLIBRARIES = pam_sepermit.la
> - 
> - install-data-local:
> --mkdir -p $(sepermitlockdir)
> -+mkdir -p $(DESTDIR)$(sepermitlockdir)
> - endif
> - if ENABLE_REGENERATE_MAN
> - noinst_DATA = README pam_sepermit.8 sepermit.conf.5
> --- 
> -1.7.5.4
> -
> diff --git a/recipes-extended/pam/libpam_1.%.bbappend 
> b/recipes-extended/pam/libpam_1.%.bbappend
> new file mode 100644
> index 000..100a376
> --- /dev/null
> +++ b/recipes-extended/pam/libpam_1.%.bbappend
> @@ -0,0 +1,8 @@
> +#FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> +FILESPATH_append := ":${@base_set_filespath(['${THISDIR}/${PN}'], d)}"
> +
> +PR .= ".4"
> +
> +inherit enable-selinux
> +
> +RDEPENDS_${PN}-runtime += "${@target_selinux(d, 'pam-plugin-selinux')}"
> diff --git a/recipes-extended/pam/libpam_1.1.6.bbappend 
> b/recipes-extended/pam/libpam_1.1.6.bbappend
> deleted file mode 100644
> index 71acecc..000
> --- a/recipes-extended/pam/libpam_1.1.6.bbappend
> +++ /dev/null
> @@ -1,10 +0,0 @@
> -#FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> -FILESPATH_append := ":${@base_set_filespath(['${THISDIR}/${PN}'], d)}"
> -
> -SRC_URI += "file://sepermit-add-DESTDIR-prefix.patch"
> -
> -PR .= ".4"
> -
> -inherit enable-selinux
> -
> -RDEPENDS_${PN}-runtime += "${@target_selinux(d, 'pam-plugin-selinux')}"
> 

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

Re: [yocto] Qt SDK Static Build

[Smith, Virgil]

> > $ bitbake meta-toolchain-qt5
>
> well SDKIMAGE_FEATURES only work when you generate SDKs using -
> cpopulate_sdk out of real images and not meta-toolchain-* targets which IMO
> should no longer be used.

As a (non-expert/non-maintainer) user, I'm happy to hear it said [by Khem Raj] 
that meta-toolchain-* targets should go away.  They easily lead to having 
multiple (incorrect) sysroot versions that can make (gdb remote)  debugging a 
futile experience.  I assume there are good practices for what should go in an 
image recipe vs. local.conf or especially distro.conf that minimize this (and 
other problems?), but the best practice I know is to promptly delete any 
sysroot copy installed by a meta-toolchain-* produced installer.

If anyone with saavy and bandwidth out there is taking input on which of these 
to attack first, I'll happily throw in a vote for Qt4.



Notice to recipient: This email is meant for only the intended recipient of the 
transmission, and may be a communication privileged by law, subject to export 
control restrictions or that otherwise contains proprietary information. If you 
receive this email by mistake, please notify us immediately by replying to this 
message and then destroy it and do not review, disclose, copy or distribute it. 
Thank you in advance for your cooperation.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-oracle-java] oracle-jse-jre fetch issue

[Maxin B. John]

Hi Daniel,

On Wed, Aug 05, 2015 at 05:20:38PM -0300, Daniel. wrote:
> Downloading JDK/JRE automagically is aways a pain in the a**.
> Everytime that Oracle changes something on its website these scripts
> crash.

I agree with your comments.It is really difficult to find a "standard"
way to download binaries from Oracle website that works everywhere.

That's why we mentioned that limitation in the README file in "Notes" section:

http://git.yoctoproject.org/cgit/cgit.cgi/meta-oracle-java/tree/README
 
> A solution I get to my life is aways downloading JDK/JRE
> manually and puting in right place. As a "friendly but not so much"
> solution I did this in one of my recipes:
> 
> 
> --- recipe file ---
> ...
> DL_FILE = 
> "ejre-7u${PV_UPDATE}-fcs-b${BUILD_NUMBER}-linux-arm-vfp-hflt-client_headful-07_may_2014.tar.gz"
> ...
> do_fetch() {
> if ! test -f "${DL_DIR}/${DL_FILE}"; then
> echo "Please accept the License Agreement, download the
> ${DL_FILE} and put it on ${DL_DIR}"
> echo "The download link can be found at
> http://www.oracle.com/technetwork/java/embedded/embedded-se/downloads/javase-embedded-downloads-2209751.html";
> return 1
> else
> return 0
> fi
> }
> 
> --- end recipe file ---
> 
> If the file is not found the recipes aborts with error and user see
> this mesage with the link to where he should go do donwload file, and
> where to put it. It's not a "state-of-art" but it works and
> prevents-me from working arround Oracle's changes. Gentoo (at least
> when I used it) do just like this to install Oracle's Java.
> 
> Best regards,
> - dhs

Best Regards,
Maxin
 
> 2015-08-05 17:02 GMT-03:00 John Davis :
> > I'm at a different client site now, but tomorrow I will be working on the
> > yocto stuff.  I can send it to your tomorrow.
> >
> > FWIW, each line in that email has a line which was changed preceded by the
> > original line starting with a comment #.
> >
> > Even then, I found you need to manually log in to the oracle website to
> > manually download the jar file and place it in the download folders.
> >
> > So, the result is that the script thinks it has a link for downloading a
> > file, however since the file has been downloaded manually using the web
> > browser it skips the download and simply starts the CRC verification.  Once
> > the script determines that the CRC matches the downloaded file it proceeds
> > to the next steps in the build process.
> >
> > --
> > John F. Davis
> > cell: 919 888 8358
> >
> > On Wed, Aug 5, 2015 at 3:47 PM, Mario Domenech Goulart
> >  wrote:
> >>
> >> Hi John,
> >>
> >> On Fri, 31 Jul 2015 14:34:24 -0400 John Davis
> >>  wrote:
> >>
> >> > fwiw, I am trying to fix it like so:
> >> >
> >> > diff --git
> >> >
> >> > a/recipes-devtools/oracle-java/oracle-jse-ejre-arm-vfp-hflt-client-headless.inc
> >> >
> >> > b/recipes-devtools/oracle-java/oracle-jse-ejre-arm-vfp-hflt-client-headless.inc
> >> > index bfa8011..13918d8 100644
> >> > ---
> >> >
> >> > a/recipes-devtools/oracle-java/oracle-jse-ejre-arm-vfp-hflt-client-headless.inc
> >> > +++
> >> >
> >> > b/recipes-devtools/oracle-java/oracle-jse-ejre-arm-vfp-hflt-client-headless.inc
> >> > @@ -1,9 +1,16 @@
> >> > -PV_UPDATE = "60"
> >> > -BUILD_NUMBER = "19"
> >> > +#PV_UPDATE = "60"
> >> > +#BUILD_NUMBER = "19"
> >> > +PV_UPDATE = "75"
> >> > +BUILD_NUMBER = "13"
> >> > require oracle-jse-ejre.inc
> >> > -SRC_URI = "http://download.oracle.com/otn/java/ejre/7u${PV_UPDATE}-b$
> >> > {BUILD_NUMBER}/ejre-7u${PV_UPDATE}-fcs-b$
> >> > {BUILD_NUMBER}-linux-arm-vfp-hflt-client_headless-07_may_2014.tar.gz"
> >> > +#SRC_URI = "http://download.oracle.com/otn/java/ejre/7u$
> >> > {PV_UPDATE}-b${BUILD_NUMBER}/ejre-7u${PV_UPDATE}-fcs-b$
> >> > {BUILD_NUMBER}-linux-arm-vfp-hflt-client_headless-07_may_2014.tar.gz"
> >> > +SRC_URI = "http://download.oracle.com/otn/java/jdk/7u${PV_UPDATE}-b$
> >> > {BUILD_NUMBER}/jdk-7u${PV_UPDATE}-linux-arm-vfp-hflt.tar.gz"
> >> > +
> >> > +#SRC_URI[md5sum] = "b9b8f598b0a7f49e4d221f16ba25c6c0"
> >> > +#SRC_URI[sha256sum] =
> >> > "ed061060011d88efe5563c2949c00993db85db17ab94f18a78713007a2b90faf"
> >> > +
> >> > +SRC_URI[md5sum] = "6958e36bdcc842121510fecf702dcf47"
> >> > +SRC_URI[sha256sum] =
> >> > "29c53bac198ca3faf5ed370025a2a5564d43e05b92d91b6b5d2a8a503de10c01"
> >> > -SRC_URI[md5sum] = "b9b8f598b0a7f49e4d221f16ba25c6c0"
> >> > davis@yoshi:~/progs/meta-oracle-java/recipes-devtools/oracle-java$ git
> >> > diff
> >> > diff --git
> >> >
> >> > a/recipes-devtools/oracle-java/oracle-jse-ejre-arm-vfp-hflt-client-headless.inc
> >> >
> >> > b/recipes-devtools/oracle-java/oracle-jse-ejre-arm-vfp-hflt-client-headless.inc
> >> > index bfa8011..13918d8 100644
> >> > ---
> >> >
> >> > a/recipes-devtools/oracle-java/oracle-jse-ejre-arm-vfp-hflt-client-headless.inc
> >> > +++
> >> >
> >> > b/recipes-devtools/oracle-java/oracle-jse-ejre-arm-vfp-hflt-client-headless.inc
> >> > @@ -1,9 +1,16 @@
> >> > -PV_UPDATE = "60"
> >> > -BUILD_NUMBER

Re: [yocto] [meta-oracle-java] oracle-jse-jre fetch issue

[Daniel.]

Well so user has enough information to donwload it manualy. Still.. shame
on you Oracle hahaha

Best regards,
- dhs
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to flash core-image-sato to a Nvidia Jetson TK1?

[Dalton Fury]

I see, but why boot from SD card, which is slower when there is eMMC?

Anyways, I flashed it successfully. But now I have no clue as to how to
enable CUDA.

I want to do some image processing with OpenCV/CUDA. What I tried is to
compile opencv with USE_CUDA=ON flage set in cmake. Then I tested to see if
I an use the gpu with opencv. But can't, and get 0 when I
call  gpu::getCudaEnabledDeviceCount(). This clearly indiacates that cuda
is not installed. So how do I install CUDA?

On Thu, Aug 6, 2015 at 9:29 AM, Khem Raj  wrote:

>
> On Aug 3, 2015, at 11:15 AM, Dalton Fury  wrote:
>
> Hi,
>
> I am a hobbyist, and liked yocto very much since I used in on an old
> Pandaboard ES. Now I got my hands on a Nvidia Jetson TK1, and want to get a
> yocto running on it. I intend to use it for heavy image processing and I
> prefer not to do it with the Ubuntu which comes with it loaded with GUI and
> Unity and all. So I build the image, but could not find any information on
> how to flash it to the eMMC on the board.
>
> Nvidia provides scripts for doing this. The process is as follows:
>
> 1) Download the driver package and extract it.
>
> 2) Download the sample rootfs and extract it to `rootfs` folder in where
> the driver package is extracted.
>
> 3) Run the apply_binaries.sh script. Upon inspecting the script, I found
> that it copies NVIDIA user space components, Nvidia firmware files, BSP
> test tools, gst test applications, create a lot of symbolic links within
> the rootfs extracted to the 'rootfs' folder. It also places the firmwares
> and kernel modules, and also copies some configuration files for the boot
> loader(U-Boot).
>
> 4) Run flash.sh.
>
> What I did is to copy the rootfs that was made with yocto, and entirely
> skip Step 3 assuming that all the necessary software is already made with
> yocto as a result of adding the BSP. This attempt of course, failed.
> Thought the kernel booted, it froze halfway. No error message. Just a flack
> screen with a while "_" on the top left corner.
>
> This is the bsp I used: https://github.com/kraj/meta-jetson-tk1
>
> This is the guide I used as reference:
> http://elinux.org/Tegra/Downstream_SW/Gentoo_From_eMMC
>
> If anyone has experience performing this(i bet you do), please help me
> out. Thanks.
>
>
> I have booted Angstrom XFCE-nm-image on it from SD card. Firstly you need
> to flash new kernel and also modify the boot loader arguments so it boots
> from SD card first.
> all instructions to update the boot loader cmdline and kernel are
> documented
>
> see
> https://cyclicredundancy.wordpress.com/2014/05/10/flashing-the-rootfs-on-a-nvidia-jetson-tk1/
>
> you might need
>
> sudo ./flash.sh -S 14580MiB jetson-tk1 mmcblk0p1
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to flash core-image-sato to a Nvidia Jetson TK1?

[Khem Raj]

> On Aug 6, 2015, at 11:13 AM, Dalton Fury  wrote:
> 
> I see, but why boot from SD card, which is slower when there is eMMC?

easy to flash and wanted to keep ubuntu around.

> 
> Anyways, I flashed it successfully. But now I have no clue as to how to 
> enable CUDA.
> 
> I want to do some image processing with OpenCV/CUDA. What I tried is to 
> compile opencv with USE_CUDA=ON flage set in cmake. Then I tested to see if I 
> an use the gpu with opencv. But can't, and get 0 when I call  
> gpu::getCudaEnabledDeviceCount(). This clearly indiacates that cuda is not 
> installed. So how do I install CUDA?

We use precompiled drivers package from nvidia for this.

Do you have /etc/ld.so.conf on target ?
if not create one with following content

/usr/lib/arm-linux-gnueabihf/tegra/

and ensure that libcuda.so is there on target

> 
> On Thu, Aug 6, 2015 at 9:29 AM, Khem Raj  > wrote:
> 
>> On Aug 3, 2015, at 11:15 AM, Dalton Fury > > wrote:
>> 
>> Hi,
>> 
>> I am a hobbyist, and liked yocto very much since I used in on an old 
>> Pandaboard ES. Now I got my hands on a Nvidia Jetson TK1, and want to get a 
>> yocto running on it. I intend to use it for heavy image processing and I 
>> prefer not to do it with the Ubuntu which comes with it loaded with GUI and 
>> Unity and all. So I build the image, but could not find any information on 
>> how to flash it to the eMMC on the board.
>> 
>> Nvidia provides scripts for doing this. The process is as follows:
>> 
>> 1) Download the driver package and extract it.
>> 
>> 2) Download the sample rootfs and extract it to `rootfs` folder in where the 
>> driver package is extracted.
>> 
>> 3) Run the apply_binaries.sh script. Upon inspecting the script, I found 
>> that it copies NVIDIA user space components, Nvidia firmware files, BSP test 
>> tools, gst test applications, create a lot of symbolic links within the 
>> rootfs extracted to the 'rootfs' folder. It also places the firmwares and 
>> kernel modules, and also copies some configuration files for the boot 
>> loader(U-Boot).
>> 
>> 4) Run flash.sh.
>> 
>> What I did is to copy the rootfs that was made with yocto, and entirely skip 
>> Step 3 assuming that all the necessary software is already made with yocto 
>> as a result of adding the BSP. This attempt of course, failed. Thought the 
>> kernel booted, it froze halfway. No error message. Just a flack screen with 
>> a while "_" on the top left corner.
>> 
>> This is the bsp I used: https://github.com/kraj/meta-jetson-tk1 
>> 
>> 
>> This is the guide I used as reference: 
>> http://elinux.org/Tegra/Downstream_SW/Gentoo_From_eMMC 
>> 
>> 
>> If anyone has experience performing this(i bet you do), please help me out. 
>> Thanks.
> 
> I have booted Angstrom XFCE-nm-image on it from SD card. Firstly you need to 
> flash new kernel and also modify the boot loader arguments so it boots from 
> SD card first.
> all instructions to update the boot loader cmdline and kernel are documented
> 
> see 
> https://cyclicredundancy.wordpress.com/2014/05/10/flashing-the-rootfs-on-a-nvidia-jetson-tk1/
>  
> 
> 
> you might need
> 
> sudo ./flash.sh -S 14580MiB jetson-tk1 mmcblk0p1
> 
> 
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org 
>> https://lists.yoctoproject.org/listinfo/yocto 
>> 
> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] do_install_append_class-target(): Files are not being installed on the system

[yocto yocto]

Good day,

I am writing a recipe using "inherit autotools". I am using
"do_install_append_class-target()" to install all files on the system. The
folder

build/tmp/work/core2-32-poky-linux/my-recipe/x.y.z-r0/image

contains all files respectively the desired folder structure. However,
after flashing my image all folders and files are not there. What might be
the problem?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] do_install_append_class-target(): Files are not being installed on the system

[Khem Raj]

On Thu, Aug 6, 2015 at 1:32 PM, yocto yocto  wrote:
> Good day,
>
> I am writing a recipe using "inherit autotools". I am using
> "do_install_append_class-target()" to install all files on the system. The
> folder
>
> build/tmp/work/core2-32-poky-linux/my-recipe/x.y.z-r0/image
>
> contains all files respectively the desired folder structure. However, after
> flashing my image all folders and files are not there. What might be the
> problem?

you are not including it in final image is the problem. In order to
include it into final image
you have to add it to RDEPENDS of a given packagegroup or
IMAGE_INSTALL part of image recipe itself.

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

Re: [yocto] qemux86 and generic86

[Khem Raj]

On Tue, Aug 4, 2015 at 10:44 PM, Amit Kumar
 wrote:
> Hi,
>
>
>
> I have a basic doubts on qemux86 build application image is not working on
> generic86 target.
>
> Suppose I have a application which I would like to test on target board, but
> the target board is not yet ready. If I will want to test that application I
> will use the qemu  to test.

here you say you dont have board.

>
> But if I build the application for qemu, it does not work for actual target
> board.

here you say you have board.

 Anyway provide more information if you need further answers on as to
how it fails paste some logs or strace output etc.
qemux86 builds for i586 and those apps should work fine on newer x86
opposite might have problem.
genericx86 defaults to core2-32 which should be able to execute i586 apps.

>
> Could you please let me know the details reason. If I want to do like that
> what I should have to do.
>
>
>
>
>
> Thanks & Regards
>
> Amit
>
> L&T Technology Services Ltd
>
> www.LntTechservices.com
>
> This Email may contain confidential or privileged information for the
> intended recipient (s). If you are not the intended recipient, please do not
> use or disseminate the information, notify the sender and delete it from
> your system.
>
>
> --
> ___
> 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] [meta-raspberrypi] userland

[Herve Jourdain]

Hi,

 

Currently, userland_git.bb PROVIDES virtual/egl and virtual/libgles2.

But "userland" seems to provide many additional components: mmal, vcos,
openmaxil, vchiq_arm, bcm_host, WFC, OpenVG

 

Wouldn't it make sense to add additional PROVIDES to handle those as well?

 

I'm thinking about openmaxil, for instance.

Right now for instance, I get it by adding a DEPEND userland to a .bbappend,
but I'm considering adding maybe a virtual/openmaxil to userland_git.bb.

 

Does it make sense? Any suggestion about that?

 

Best regards,

 

Herve

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

Re: [yocto] [meta-raspberrypi] userland

[Khem Raj]

On Thu, Aug 6, 2015 at 10:57 PM, Herve Jourdain  wrote:
> Hi,
>
>
>
> Currently, userland_git.bb PROVIDES virtual/egl and virtual/libgles2.
>
> But “userland” seems to provide many additional components: mmal, vcos,
> openmaxil, vchiq_arm, bcm_host, WFC, OpenVG
>
>
>
> Wouldn’t it make sense to add additional PROVIDES to handle those as well?


if they are implementation of generic components then sure. openvg and
openmax might be one of them but if no one
is depending on them why bother ?

>
>
>
> I’m thinking about openmaxil, for instance.
>
> Right now for instance, I get it by adding a DEPEND userland to a .bbappend,
> but I’m considering adding maybe a virtual/openmaxil to userland_git.bb.
>
>
>
> Does it make sense? Any suggestion about that?
>
>
>
> Best regards,
>
>
>
> Herve
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] arm-none-eabi toolchain

[Khem Raj]

On Thu, Jul 30, 2015 at 10:25 PM, Lukas Weiss  wrote:
> Hello,
>
> i need a arm-none-eabi toolchain on my yocto host/build system. Ive tried to
> use the arm-poky-linux-gnueabi, but it does not support the arm version +
> format i need:
>
> arm-poky-linux-gnueabi-ld: unrecognised emulation mode: thumb
> | Supported emulations: armelf_linux_eabi armelfb_linux_eabi
>
> My Linux runs on a ARM9 (armv5e, elf), I need cortex-m3 (armv7m, thumb).
> Where do I get that? I do not find any documentation about additional
> toolchains to generate code like peripheral-firmware in my yocto
> environment.
>
> a) How do I get the toolchain in by yocto host?
> b) How to i tell the bitbake-tool to use that toolchain on a certain receipe
> (PACKAGE_ARCH, TARGET_SYS, ... )?
>
> Do you have any hints?

this is not supported usecase but there was some talk about such a
usecase. you could change ld to support additional emulations
so you can then keep using same toolchain to link it but then the c
runtime etc wont match. So far we dont support non-hosted(bare-metal)
environments
>
> Regards,
> Lukas
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto