djwillis/meta-raspberrypi

meta-raspberrypi is an OpenEmbedded BSP layer for the Raspberry Pi boards from http://www.raspberrypi.org/.

meta-raspberrypi's Issues

how to include piTFT display driver for raspberrypi ?

Sir
I need to include piTFT display driver to rpi-hwup-image? how to do it? please specify steps to do it....
please help

bcm2835-bootfiles missing in case of zImage

it's a bit wierd but in case of KERNEL_IMAGETYPE set to zImage the bcm2835-bootfiles are missing in the sdcard image !

Add recipe for RPi.GPIO

Will be trivial, but worth having I think:

http://pypi.python.org/pypi/RPi.GPIO

Error while cloning raspberrypi/linux.git

git clone --bare --mirror git://github.com/raspberrypi/linux.git /downloads/git2/github.com.raspberrypi.linux.git failed with exit code 128, output:
STDOUT: Cloning into bare repository '/../downloads/git2/github.com.raspberrypi.linux.git'...

STDERR: fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

ERROR: Function failed: Fetcher failure for URL: 'git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-patches'. Unable to fetch URL from any source.

SD image creation problem

It seems that the ext3 image hasn't been created before the sd card image builds. If I hexdump the ext3 image and the offset in the sd card image, they're not the same. If I try to use this generated image, the raspberry pi won't boot. If I do the steps manually after the ext3 image has been generated, the image boots (and the hexdumps match).

I tried to find a way to fix it, but I'm a bit too much of a yocto noob to figure out how to add the dependency on the ext3 rootfs file generation.

Here's the hexdump:

seth@ctech ~/ct_yocto/ct_rpi/build $ !785
hexdump -n 3000 -s 20m tmp/deploy/images/rpi-hwup-image-raspberrypi.rpi-sdimg
1400000 0000 0000 0000 0000 0000 0000 0000 0000
*
1400bb0
seth@ctech ~/ct_yocto/ct_rpi/build $ !784
hexdump -n 3000 tmp/deploy/images/rpi-hwup-image-raspberrypi.ext3
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
0000400 1220 0000 9057 0000 0737 0000 161b 0000
0000410 0d4c 0000 0001 0000 0000 0000 0000 0000
0000420 1ce0 0000 1ce0 0000 03a0 0000 0000 0000
0000430 4e6f 4ff8 0000 0014 ef53 0001 0000 0000
0000440 4e6f 4ff8 0000 0000 0000 0000 0000 0000
0000450 0000 0000 0000 0000 0000 0000 0004 0000
0000460 0000 0000 0000 0000 0000 0000 0000 0000
*
00004e0 0008 0000 0000 0000 0000 0000 0000 0000
00004f0 0000 0000 0000 0000 0000 0000 0100 0000
0000500 0000 0000 0000 0000 0000 0000 4f47 0000
0000510 4f48 0000 4f49 0000 4f4a 0000 4f4b 0000
0000520 4f4c 0000 4f4d 0000 4f4e 0000 4f4f 0000
0000530 4f50 0000 4f51 0000 4f52 0000 4f53 0000
0000540 5054 0000 0000 0000 0000 0000 0000 0040
0000550 0000 0000 0000 0000 0000 0000 0000 0000
*
0000800 0003 0000 0004 0000 0005 0000 0b63 02ac
0000810 002d 0000 0000 0000 0000 0000 0000 0000
0000820 1ce3 0000 1ce4 0000 1ce5 0000 048b 02a8
0000830 002b 0000 0000 0000 0000 0000 0000 0000
0000840 39c3 0000 39c4 0000 39c5 0000 0000 02a8
0000850 0027 0000 0000 0000 0000 0000 0000 0000
0000860 56a3 0000 56a4 0000 56a5 0000 0000 02a8
0000870 0021 0000 0000 0000 0000 0000 0000 0000
0000880 7383 0000 7384 0000 7385 0000 062d 02a8
0000890 002f 0000 0000 0000 0000 0000 0000 0000
00008a0 0000 0000 0000 0000 0000 0000 0000 0000
*
0000bb0

Seth

bootlogd init script depends on devppts

https://bugzilla.yoctoproject.org/show_bug.cgi?id=2493

Hidden dependency on oe-core (bleeding edge gstreamer-plugins-bad)

Hi:

Two things in building master:

1. Rpi layer won't build without oe-core now (lately called openembedded-core on github) due to the rpi bbappend on gstreamer-plugins-bad (so the readme needs to clearly state this).

2. The above bbappend needs updating to 1.4.0.

Everything previously built fine against just poky (without oe-core at all).

Thanks...

/dev/ptmx created too late for bootlogd

Somehow /dev/ptmx is not created at start-up. Is created by a devpts script and before that bootlogd needs it and it fails with:
cannot allocate pseudo tty: No such file or directory

I suspect this is an udev problem on RPI.

@g

Kernel build fails with "Inconsistent kallsyms data"

It goes on to say:

"This is a bug - please report about it
Try make KALLSYMS_EXTRA_PASS=1 as a workaround"

adding:
EXTRA_OEMAKE = "KALLSYMS_EXTRA_PASS=1"
to linux-raspberrypi_3.1.9.bb does the job.

This doesn't affect all SRCREVs, but "fc48dbcb3a1eb6a80ddf132b6ca65d408c268c84" (the latest at the moment) does fail without the above.

vc-graphics PROVIDES and RPROVIDES

In master, PROVIDES includes 'virtual/libgl' which it should not; we only have libgles2.

Also, it would be useful to add RPROVIDES= "libgles2" (the gl libs are often dlopened rather than linked against, so it is necessary to add libgles2 to RDEPENDS for packages that are expecting to dlopen it, e.g., cogl).

Compile kernel fails

Hi,

i'm trying to compile everything under linux (which i know is not supported). Appart from compiling the kernel there is no problem. The kernel always gives me:

NOTE: Executing RunQueue Tasks
ERROR: Function failed: do_configure (log file is located at /home/jens/raspberrypi/yocto/poky/raspberrypi/tmp/work/raspberrypi-poky-linux-gnueabi/linux-raspberrypi/3.12.26+gitf03cd5e1012d3fe8314a944879308cf0f3d9e29b-r0/temp/log.do_configure.18715)
ERROR: Logfile of failure stored in: /home/jens/raspberrypi/yocto/poky/raspberrypi/tmp/work/raspberrypi-poky-linux-gnueabi/linux-raspberrypi/3.12.26+gitf03cd5e1012d3fe8314a944879308cf0f3d9e29b-r0/temp/log.do_configure.18715
Log data follows:
| DEBUG: Executing python function sysroot_cleansstate
| DEBUG: Python function sysroot_cleansstate finished
| DEBUG: Executing shell function do_configure
| NOTE: make oldconfig
| make: *** No rule to make target 'oldconfig'. Stop.
| ERROR: oe_runmake failed
| WARNING: /home/jens/raspberrypi/yocto/poky/raspberrypi/tmp/work/raspberrypi-poky-linux-gnueabi/linux-raspberrypi/3.12.26+gitf03cd5e1012d3fe8314a944879308cf0f3d9e29b-r0/temp/run.do_configure.18715:1 exit 1 from
| oe_runmake oldconfig
| ERROR: Function failed: do_configure (log file is located at /home/jens/raspberrypi/yocto/poky/raspberrypi/tmp/work/raspberrypi-poky-linux-gnueabi/linux-raspberrypi/3.12.26+gitf03cd5e1012d3fe8314a944879308cf0f3d9e29b-r0/temp/log.do_configure.18715)
ERROR: Task 5 (/home/jens/raspberrypi/yocto/poky/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_3.12.26.bb, do_configure) failed with exit code '1'

any ideas on that? Or am i running into a problem cause i'm ignoring:

WARNING: Host distribution "Gentoo" has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution.?

Cheers
Jens

sd-image generation from .xz rootfs possibly broken

I have been looking over the changes to the sd image class and noticed that the dd parameters for the rootfs write are different for the .xz rootfs then the default (e.g. ext3):

if [[ "$SDIMG_ROOTFS_TYPE" == *.xz ]]
then
        xzcat ${SDIMG_ROOTFS} | dd of=${SDIMG} conv=notrunc seek=1 bs=$(expr 1024 \* ${BOOT_SPACE_ALIGNED}) && sync && sync
else
        dd if=${SDIMG_ROOTFS} of=${SDIMG} conv=notrunc seek=1 bs=$(expr 1024 \* ${BOOT_SPACE_ALIGNED} + ${IMAGE_ROOTFS_ALIGNMENT} \* 1024) && sync && sync
fi

Note that in the xz case the block size, and hence the initial seek, does not include the IMAGE_ROOTFS_ALIGNMENT, so I think the image is getting written before the start of the rootfs partition.

(BTW, good job on this, it's great not having large emtpy images about :) )

Kernel config fragment for sound?

The kernel currently has the ALSA driver (and system) as loadable modules.

Would it make sense for the kernel to have a config fragment to make these built-ins if ALSA is configured as a feature?

Remove poky-raspberrypi distro config

This is a horrible way of just adding a BBMASK of the rpi-zram-service recipe - not only does it change DISTRO thus forcing a bunch of packages to rebuild if you've already built them, it also doesn't solve the issue for non-Poky OE-Core only users.

Until systemd is integrated in OE-Core could you not just tell people to add the BBMASK in the README as other layers that need this kind of thing do (e.g. meta-ti)?

Creating yocto image with omxplayer fails

I have an issue when building a yocto/poky image with meta-raspberrypi and meta-oe layers which should include omxplayer.
I added meta-oe to the bblayers.conf, removed libav from BBMASK and added a IMAGE_INSTALL_append = " omxplayer" to my local.conf.
The package build process seems fine, but the do_rootfs step fails. It seems tune2fs does not see any input:

| tune2fs 1.42.1 (17-Feb-2012)
| Creating journal inode: done
| This filesystem will be automatically checked every 20 mounts or
| 0 days, whichever comes first. Use tune2fs -c or -i to override.
| 0+0 records in
| 0+0 records out
| 0 bytes (0 B) copied, 9.905e-06 s, 0.0 kB/s
| Error: The location 100% is outside of the device /home/julian/dev/rpi/yoctoProject/raspberryPiBuild/tmp/deploy/images/rpi-basic-image-raspberrypi-20120914172541.rootfs.rpi-sdimg.
| ERROR: Function failed: do_rootfs (see /home/julian/dev/rpi/yoctoProject/raspberryPiBuild/tmp/work/raspberrypi-poky-linux-gnueabi/rpi-basic-image-1.0-r0/temp/log.do_rootfs.20666 for further information)
ERROR: Task 7 (/home/julian/dev/rpi/yoctoProject/meta-raspberrypi/recipes-core/images/rpi-basic-image.bb, do_rootfs) failed with exit code '1'

The full logfile can be found at http://pastebin.ca/2204282.

I am unsure though if this is related to the meta-oe integration or just related to the rootfs size maybe?

Raspberry b+ no usb and no ethernet

Hi,
I am new in yocto and I tried to build the rpi-basic-image for the B+ model. It seems that I don't have usb and ethernet port running.
Do you know if there are some minnor changes to apply to your meta-raspberry to build an image for the B+ model ?
I would be happy to try it of you can give me some advice ...

Fix zram service loading script for 3.2 kernel

The rpi-load-zram.sh script does not work with the 3.2 kernel due to changes in argument names for the zram module; the script already contains the correct alternative line, but it's commented out.

Building for armhf (RaspberryPI on Debian)

I'm trying to build some OE deb packages using meta-raspberrypi, but my wheezy Raspbian distro is complaining that the OE .deb was built for the "arm" architecture and not for the "armhf" one.

Of course it would work on a non-accel Raspbian, but any improvement counts on a small ARM system

To fix this, I tried to use an "armhf" machine, by changing the machine definition in the following way. However, this didn't fix it, even if bitbake is telling me it's using the hardware accelerated FPU.

diff --git a/conf/machine/include/tune-arm1176jzf-s.inc b/conf/machine/include/tune-arm1176jzf-s.inc
index b52c161..9060f48 100644
--- a/conf/machine/include/tune-arm1176jzf-s.inc
+++ b/conf/machine/include/tune-arm1176jzf-s.inc
@@ -6,5 +6,5 @@ TUNEVALID[arm1176jzfs] = "Enable arm1176jzfs specific processor optimizations"
TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "arm1176jzfs", "-mtune=arm1176jzf-s", "", d)}"

AVAILTUNES += "arm1176jzfs"
-TUNE_FEATURES_tune-arm1176jzfs = "${TUNE_FEATURES_tune-armv6} arm1176jzfs"
-PACKAGE_EXTRA_ARCHS_tune-arm1176jzfs = "${PACKAGE_EXTRA_ARCHS_tune-armv6}"
+TUNE_FEATURES_tune-arm1176jzfs = "${TUNE_FEATURES_tune-armv6hf} arm1176jzfs"
+PACKAGE_EXTRA_ARCHS_tune-arm1176jzfs = "${PACKAGE_EXTRA_ARCHS_tune-armv6hf}"

recipie for WiPi support

how would I go about adding support for the Wi-Pi module?

Changes IMAGE_FSTYPES to compressed variants

The images in deploy are eating up space, what do you think of a patch like this:

-IMAGE_FSTYPES += "tar.bz2 ext3 rpi-sdimg"
+IMAGE_FSTYPES += "tar.bz2 ext3.xz rpi-sdimg.xz"

?

Console kernel parameter not respected

Even though the kernel bb recipe sets up the commandline so that the console is on ttyAMA0, it is ends up on tty1, from dmesg, the actual kernel command line looks like this:

Kernel command line: dma.dmachans=0x3c bcm2708_fb.fbwidth=1280 bcm2708_fb.fbheight=1024 bcm2708.boardrev=0x2 bcm2708.serial=0xc80d92c5 smsc95xx.macaddr=B8:27:EB:0D:92:C5 dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait

This is not the command line the recipe defines, and note that the console parameter is there twice. Any idea what is going on here?

kernel.img isn't always created

The build was failing with the following error:

/home/seth/ct_yocto/ct_rpi/build/tmp/deploy/images/bcm2835-bootfiles/kernel.img: No such file or directory

It looked like the BCM recipe to generate the kernel image wasn't running. I made the following change and it build without an error.

seth@ctech-vm ~/ct_yocto/poky/meta-raspberrypi $ git diff conf/machine/raspberrypi.conf
diff --git a/poky/meta-raspberrypi/conf/machine/raspberrypi.conf b/poky/meta-raspberrypi/con
index a64104b..984b21b 100755
--- a/poky/meta-raspberrypi/conf/machine/raspberrypi.conf
+++ b/poky/meta-raspberrypi/conf/machine/raspberrypi.conf
@@ -36,6 +36,8 @@ MACHINE_EXTRA_RRECOMMENDS += "
bcm2835-kernel-image
"

+MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "bcm2835-kernel-image"
+

Seth

raspberrypi.conf should not include anything from distro

As of commit 3c4e203 raspberrypi.conf includes files from conf/distro; this is not right, the machine conf describes the hardware, nothing else (btw, I don't know if being Yocto compliant is of any concern, but having distro stuff in a BSP layer makes it non-compliant).

As for the new includes, I don't think the splitting of the fallback preferred providers and versions into include files serves any useful purpose, it just makes the machine configuration hard to navigate, but at least these should be in conf/machine/include.

PREFERRED_PROVIDER_virtual/kernel

Hi,

I think it should be fine to use '?=' instead of '=' in conf/machine/include/rpi-default-providers.inc in order to allow overriding provider in local.conf (for example). I use it for Xenomai kernel defined in meta-xenomai.

PREFERRED_PROVIDER_virtual/kernel ?= "linux-raspberrypi"

regards

Ensure SD partitions are 4MiB aligned

"Ideally you want to ensure your partitions are 4MiB aligned, which should be aligned to a multiple of the erase block size on most SD cards."

rpi-basic-image

I believe we should supply a slightly more fully featured image to build. Allowing for a bit more connectivity.

name: rpi-basic-image or rpi-hwup-ssh-image

additional features:

IMAGE_INSTALL += "openssh-sftp-server telnetd"

IMAGE_FEATURES += "ssh-server-openssh"

OR

IMAGE_FEATURES += "ssh-server-dropbear"

Also with an sftp server for dropbear (suggestions?)

I don't feel that people should have to do one of the alternatives listed below to just a get connected to the image over a network.

1. editing the meta-raspberry layer directly
2. creating a new layer (as is proper)
3. adding IMAGE_FEATURES = "dropbear" to local.conf (yuck!).

Add recipe for omxplayer

https://github.com/huceke/omxplayer

Add recipe for bcm2835

C Library for I/O:

http://www.open.com.au/mikem/bcm2835/

Machine not available in Poky 1.3 Hob

I was using Poky's Hob GUI tool to build images for my raspberry pi.

I tried it with the latest release of Poky, but the raspberrypi machine is not available.

At first I thought it was odd the meta-yocto-bsp layer was there

layer path priority

meta /home/benjamin/poky/meta 5
meta-yocto /home/benjamin/poky/meta-yocto 5
meta-yocto-bsp /home/benjamin/poky/meta-yocto-bsp 5
meta-raspberrypi /home/benjamin/poky/meta-raspberrypi 6

so I removed it from bblayers.conf

layer path priority

meta /home/benjamin/poky/meta 5
meta-yocto /home/benjamin/poky/meta-yocto 5
meta-raspberrypi /home/benjamin/poky/meta-raspberrypi 6

Unfortunately I'm new so I could use help debugging

Random MAC if there is no cmdline.txt in the boot partition

I discovered a Problem if there is no cmdline.txt in the boot partition. The MAC-Adresse is not set correctly. It seems that the Kernel ignores the parameters set by bootloader. If I Boot with a cmdline.txt I get this result by cat /proc/cmdline

dma.dmachans=0x3c bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708.boardrev=0x2 bcm2708.serial=0x668ba95f smsc95xx.macaddr=B8:27:XX:XX:XX:XX dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait quiet

The param quiet was added for testing ;-) Without that file I get:
dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait debug

See also: #23

vc-graphics* missing COMPATIBLE_MACHINE

When building for e.g. beagleboard:

NOTE: multiple providers are available for virtual/egl (libgles-omap3, vc-graphics-hardfp, vc-graphics)

Doesn't support udev > 164

gstreamer1.0-plugins-bad_1.4.0.bbappend error

Hi,

There is an issue when building core-image-minimal for RPi as gstreamer1.0-plugins-bad_1.4.0.bbappend is version dependent.

ERROR: No recipes available for:
/media/SAMSUNG_EXT4_BIS/Yocto/poky_gistre/meta-raspberrypi/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.4.0.bbappend

I saw a patch here at http://pgtux.wordpress.com/tag/raspberrypi, but not included right now, why ?

thx by advance,

regards

Latest kernel not working?

I've updated the kernel recipe to use SRCREV = "e3a21fc997669aae744537bf69e123f88a5e69e2"

and the bootfiles to use SRCREV = "9308c7ed387e5422883753f7fb71a75506abd1f8"

However, this seems to give a kernel that doesn't boot. The compiled kernel.img is also about half the size of the image from raspberrypi/linux. Using the raspberrypi/linux image with the bootfiles from the above SRCREV works, as does using the "3fc65f9f291fb19cad434968a4a0f66ab749e637" kernel srcrev with the kernel recipe.

The later kernels just get the "four-colours" at boot, so the bootloader is failing to load the image.

Is there anyway to configure the kernel using menuconfig

Hi,

I recently started playing around with Yocto and I'm using my Raspberry Pi Model B board as a reference platform. As I've managed to build to default rpi-basic-image I've started to venture deeper into Yocto and wanted to customize the kernel modules etc. Using vanilla Yocto and their provided kernels you can use "bitbake linux-yocto -c kernel_configme -f" or "bitbake linux-yocto -c menuconfig" to do so. For the raspberry pi images this does not seem to work however. I'm guessing this is because of the "overriden" linux kernel used in the BSP.

Is there any way to run menuconfig to configure the raspberrypi kernel used in the BSP as with the yocto or vanilla kernel?

Issue with libgles1 when building Yocto LSB image

Hi,

I've been working to get the Poky LSB image built up for the RPi but have been having problems with it pulling in mesa-dri and libQT4.

I think the mesa issue is due to a dependency on libgles1 which defaults to the mesa-dri provider.

Looking at recipes-bcm/vc-graphics/vc-graphics.inc I see it advertises it provides:

PROVIDES = "virtual/libgl virtual/libgles2 virtual/egl"

Now looking at the RPi firmware binaries over here

https://github.com/raspberrypi/firmware/tree/master/hardfp/opt/vc/lib

I see there is a libGLESv1_CM.so so I'm thinking maybe we can add libgles1 to vc-graphics.inc

PROVIDES = "virtual/libgl virtual/libgles1 virtual/libgles2 virtual/egl"

Then I can set a preferred provider for libgles1 and the mesa-dri problem goes away (hopefully).

Can anybody advise if this is a sensible solution, or am I on the wrong track about libGLESv1_CM.so

Thanks!

Alex

Generate CMDLINE

CMDLINE ends up " debug ", because it's overwritten in linux.inc. So kernel won't boot without a cmdline.txt. Define a CMDLINE in kernel recipe.

@g

Package zram service both for systemd and sysvinit

I think rpi-zram-service package should be modified along the lines of this bbappend: https://github.com/Guacamayo/meta-guacamayo/blob/master/meta-guacamayo/recipes-support/rpi-zram-service/rpi-zram-service.bbappend. The distro can then choose whether to pull in rpi-zram-service-systemd, or rpi-zram-service-initd.

Since update-rc.d.bbclass is in OE core, I assume inheriting it should not cause any problem but the sysvinit distros would still need to provide systemd.bbclass, but this can be an empty dummy. The alternative is to use a variable in the inherit. I can make patch, but wanted to gauge the thoughts on this first.

udev is version 164 - activate UDEV_GE_141 in rpi kernel

UDEV_GE_141

@g

XBMC Build

I have been attempting to build XBMC for the Raspberry Pi today, I hit the following issue:

http://pastebin.com/xiqdQNWS

Which was a show stopper for me.

However I have posted some patches to meta-oe to fix up the libcec to the latest required version for the new XBMC and RasPi configuration.

I have been trying to build SRCREV xbmc/xbmc@45fe6fc which is the revision that the Raspberry Pi support got pulled in on.

sdimage is ~ 4G size but roofs is only 60mb (11mb free)

denzil branch

Since master has now been updated to be incompatible with denzil, could we have a denzil branch for this layer? Thanks!

There is no RTC on RaspberryPi / Deactivate HWCLOCK from busybox

In this way we will avoid warnings at boot.

@g

Dependency rpi-basic-image, vc-graphics and integration xf86-video-fbturbo

Hi Andrei,
I am creating and building an embedded Linux distribution for the raspberry pi3.
I use the version of Yocto Project 2.2.1 - Morty and the layer meta-raspberrypi.
I am integrating the vc-graphics/vc-graphics-hardfp (meta-raspberrypi recipes) into the image rpi-basic-image.
I am not able to solve the problems of dependencies between the recipe vc-graphics/vc-graphics-hardfp of this recipe rpi-basic-image (see the Error message below):

"1 error: Required build target 'rpi-basic-image' has no buildable providers.Missing or unbuildable dependency chain was: ['rpi-basic-image', 'vc-graphics']"

Could you help me to resolve the vc-graphics/vc-graphics-hardfp dependencies.

See also the copy of the IMAGE_INSTALL_append (Toaster Morty 2.2.1) below:
"apt dpkg dbus sudo tzdata glibc-utils localedef networkmanager pointercal xinit libmatchbox matchbox-terminal matchbox-desktop matchbox-keyboard xkeyboard-config matchbox-session matchbox-wm libx11 consolekit base-passwd liberation-fonts pkgconfig xserver-xorg xf86-input-libinput vc-graphics".

I also need xf86-video-fbturbo in the meta-raspberrypi.

Maybe you could integrate the recipe for the driver xf86-video-fbturbo from https://github.com/ssvb/xf86-video-fbturbo into the meta-raspberrypi?

Because the same driver applies in the Raspbian during the installation stage of the package xserver-xorg-video-fbturbo and I would like the same driver on my embedded Linux distribution. Could you please make the new recipe for raspberry pi3?
See the links below : https://github.com/ssvb/xf86-video-fbturbo, https://github.com/ssvb/xf86-video-fbturbo/wiki/Installation,

https://www.reddit.com/r/raspberry_pi/comments/1ubcwu/fbturbo_accelerated_x_driver_in_raspbian/

I thank you in advance for your reply.

Denis

Enable Hard Float Support ?

Hi guys,
I'd like to know if your layer could support armhf, if it supports it I'd like to know how to enable it, I'm currently generating armel binaries

kernel needs vm.min_free_kbytes of at least 8192

All of the foundation images ship with vm.min_free_kbytes = 8192 - values lower than this are known to cause issues

As I have found no easy way to set the defaults in-kernel, we need to call sysctl on boot. For systemd based images this can simply be done by adding a file to /etc/sysctl.d, but sysv based images use a single /etc/sysctl.conf file, which complicates matters..