Thanks. bitbake foo | cat is most likely to be what I was looking for. I found the cooker log shortly after I asked my question. I'll go look through bitbake and see what it would take to create a

Hi, This is Rohit, I am trying to get yocto wokring on a ARM Board (EMB-3500 iMX6). The board doesn't support booting from Memory card. So we use the mfgtools to flash the image to on board Nand. We

On Thu, Jun 12, 2014 at 12:00 PM, Burton, Ross <ross.burton@...> wrote: On 12 June 2014 19:53, Patrick Doyle <wpdster@...> wrote: > As you know, when we bitbake a recipe, we see lots of messages

You want to see the cooker log. If you want to see that as it happens, then for a one-off you can convince bitbake that it's not running on a vt (bitbake foo | cat -). After the event, the cooker

I'm sure I'll get tired of looking at this eventually, and learn to love the normal ncurses style interface of bitbake. But things are still new enough to me that I want to know what's going on. As

are you asking for clarifications after reading this http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#shared-state-cache, or you haven't seen it yet?

I am a newbie to Yocto project... I wanted to know.. what is the role of the "sstate-cache" directory?

As was mentioned in the other replies, you can always have a single bbappend with board specific SRC_URI updates to add the patches you need onto the base board support. It's unfortunate that the

Hello Yocto-Community, It's really easy to add auto completion in the SDK setup scripts with BASH's "read -e -p". I attached a short patch that does this. Makes life very comfortable ;-). I already

Thanks for the pointer :)

We crossed in the air. I just sent something similar, and I was going to go dig into the details .. but you are already there. Let me know if you have further issues, and I can also say that the

Aha, so yes, that is likely the same thing that I was seeing before. If you have no configuration at all, the tools don't have anything to seed into the config_frag.txt file (and in earlier versions

I think I see the problem now. A defconfig must be provided on SRC_URI (or a fragment) or we see the failure. I'll add in a SRC_URI defconfig instead of it reusing the in-tree config. Cheers, Alex

Hi Bruce, Currently I'm using - SRC_URI = "git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.12.y \ file://sl030raspberrypii2ckernel.patch \ file://dummy.cfg \

I have a fix for a similar issue in a patch queue that I'm going to finish work on short (as part of 1.7 development work) .. the error message that is generated in that scenario is certainly not

Hi Holger, I know you've already seen this but just to round this off, the issue is now fixed: https://bugzilla.yoctoproject.org/show_bug.cgi?id=6426 Cheers, Paul -- Paul Eggleton Intel Open

Hi, I was taking a quick look at converting the meta-raspberrypi kernel recipes to be linux-yocto style, to provide config frag support. I'm working with poky master, referencing

<danielhilst@...> wrote: you can do: SRC_URI_append_som1 = " file://som1.patch" assuming som1 is a valid machine name (e.g. you have conf/machines/som1.conf) you can do all builds with 1

Yes I do compile the device drivers as modules, but yet I have to register the *_board_info structs on board-*.c file, here is an example: http://pastebin.com/GMSDQERB Thanks in advance, Cheers!

Can you compile the different device drivers as modules and load them at runtime? Can you compile the different device drivers statically and probe them based on a devicetree