When using DHCP, busybox's udhcpc script will write the DNS entries that the server returned into the resolv.conf file. In this case, I think you'll have to "provide" resolv.conf in some other way, th

On 08/07/2014 11:10 AM, Paul Eggleton wrote: ... > * Provide tools to allow modifying software for which a recipe already exists. > If the user has an external source tree we use that, otherwise we ca

I finally got around to trying to use our custom board's BSP with Yocto images. Since the board has a touchscreen (well, actually it has two) I built the core-image-sato. I had to tweak the startup a

On 11/13/2014 02:07 PM, Burton, Ross wrote: Ah, thanks, found it. It's set to run at runlevel 5 and somehow my inittab has "3" as its level. Setting it to 5 displays the desktop. Next challenge is to

On 11/13/2014 02:10 PM, Mike Looijmans wrote: Hmm. That's a big disappointment. I've been using "ts_calibrate" in the past, and that worked just fine on this board. Sato uses an X application for this

On 11/13/2014 02:28 PM, Burton, Ross wrote: Maybe, but it demonstrates that the hardware and drivers are working just fine. Tried, but that did not help, same problem. I have one of those attached to

On 11/13/2014 02:54 PM, Mike Looijmans wrote: That one works, root@topic-miami-florida-med-xc7z015:~# DISPLAY=0:0 xinput_calibrator -v --devic e event1 DEBUG: XInputExtension version is 2.3 DEBUG: Ski

On 11/13/2014 06:58 PM, Michael Gloff wrote: Interesting option, can you elaborate on that (in particular, in combination with Yocto builds)? Met vriendelijke groet / kind regards, Mike Looijmans Syst

For the "download" directory, just set the permissions for the group to allow writing. I've used this with an NFS share that holds all downloads. The machien also runs apache and shares this directory

The one-size-fits-all solution is to use an unionfs, and a writable part in RAM or mounted elsewhere, e.g. in flash (typically a tiny jffs2 partition). It requires quite some scripting to get right, y

On 12/10/2014 08:00 PM, Khem Raj wrote: A more convincing use-case for multi-machine building is the emerging of "hybrids". The little/big architecture that puts different versions of ARM CPUs into a

On 12/10/2014 06:42 AM, Moore, Thomas (FtWorth) wrote: I think that comment is outdated or something that someone wanted to implement some day or so. I've always just named my kernel module recipes "k

On 12/11/2014 08:42 PM, Mark Hatle wrote: The OMAP PRU and DSP each run their own bootloader/kernels (the PRU is just bare metal code), and do not share code with the ARM that runs the rest. From the

Create your own image recipe (hint: "require" another image, or just copy it), that reduces the parse time. Creating the image usually takes less than a minute. You can also just build the new package

On 15-01-15 01:11, J. Tang wrote: If the CPU has actual hard-float support, then enabling it should increase floating point performance by an order of magnitude (e.g. 100x faster or so). If you don't

On 15-01-15 22:51, Glenn Schmottlach wrote: Obvious alternative is to fork the kernel and manage it in your own repo. Using git "rebase" you can keep your changes on top, and git format-patch can gene

On 26-03-15 14:44, Gary Thomas wrote: The hosts need to be similar for the build tools to be recycled. If they have different OS versions, or even different CFLAGS you'll see a rebuild of "native" pac

On 16-04-15 13:00, testlaster wrote: Short answer: Put "inherit module" in your recipe to build the module. Example Makefile: https://github.com/topic-embedded-products/kernel-module-vdmafb/blob/maste

On 22-04-15 19:58, Paul Eggleton wrote: Man, I've been working with OE for years, and this is the first time I ever saw this. You should create a link to this page using ten feet neon tubes. Seriously

Yocto/OE doesn't support multiple "machines" in a single build. You'll have to create a separate yocto build (can use the same environment though) by setting MACHINE to your armv7 firmware system and