Re: [yocto] [wpe-webkit] Optimising imx6 performance for HTML5 using Cog + WPE WebKit

[Andy Pont]

Carlos wrote...



 We start the browser with the following command line:

 cog --enable-accelerated-2d-canvas=1 appui/index.html



How the performance compares if you disable accelerated-2d-canvas?
It gets worse or its the same?
It is the same. I have been testing with http://fabricjs.com//animation 
and https://themaninblue.com/experiment/AnimationBenchmark/canvas/ and 
in all circumstances I see 10-12fps.



Usually on the web application side there are different things that can
be optimized to make it perform better on WPE.
I think it would be helpful to understand the problem if you can share a
demo of your web app where the performance problem can be easily reproduced.
The web app is responding to data being sent to it over a websocket 
connection from a backend application. I’ll see if we can create 
something that doesn’t rely on the websocket interface that can be run 
in the browser on its own.


-Andy.

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

[yocto] Optimising imx6 performance for HTML5 using Cog + WPE WebKit

[Andy Pont]

Hello,

Broadening this out to the Freescale and Yocto mailing lists to see if 
any one has any answers…


We are using Cog and WPE Webkit on an i.MX6 Solo based board with a user 
interface that is based on HTML5, Javascript and CSS and are having some 
issues with fading and other canvas effects.  The board is running a 
Yocto image with the following in conf/local.conf:


PREFERRED_PROVIDER_virtual/wpebackend = "wpebackend-rdk"
PACKAGECONFIG_pn-wpebackend-rdk = "imx6"

PACKAGECONFIG_append_pn-cairo = " glesv2 egl"
PACKAGECONFIG_append_pn-wpewebkit = " 2dcanvas"

We start the browser with the following command line:

cog --enable-accelerated-2d-canvas=1 appui/index.html

Are there any other settings we should be using either in the Yocto 
build or when launching Cog as we are finding the CPU usage is >90%?


Is there a definitive way to show that all of the necessary drivers are 
loaded and Cog is making use of the GPU?


I have tried this with Cog 0.3.0 built with WPE WebKit 2.24.1 and Cog 
0.4.0 built with WPE WebKit 2.26.1 and both give the same dissappointing 
results, as does running on the iMX6Q-SDP board I also have here.


-Andy.

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

Re: [yocto] Partitioning SD cards

[Andy Pont]

I wrote...

I have created a “wic” directory in my custom layer and copied 
sdimage-bootpart.wks into it as sdimage-project.wks without making any 
changes but “wic list image” throws an error with the new .wks file:


UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb0 in position 
37: invalid start byte

Ignore that, I deleted the directory and tried again and it is OK now!

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

Re: [yocto] Partitioning SD cards

[Andy Pont]

Maciej wrote...

How do I stop the wic generation process including the FAT formatted 
“boot” partition?

This depends on the wic (.wks) file you are using.

I have been using the default one (sdimage-bootpart.wks)?

What is the best strategy for partitioning / formatting / mounting the 
second partition as /home?  Should it be part of the image build 
process or a one-time task run at first boot?

Use --exclude-path and --rootfs-dir flags in the .wks file.
You can look at my example, where I extract one subdir from rootfs 
(/storage in this case) on a separate partition.

https://github.com/3mdeb/meta-rte/blob/master/wic/sunxi-mmc-spl.wks
I have created a “wic” directory in my custom layer and copied 
sdimage-bootpart.wks into it as sdimage-project.wks without making any 
changes but “wic list image” throws an error with the new .wks file:


UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb0 in position 37: 
invalid start byte


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

[yocto] Partitioning SD cards

[Andy Pont]

Hello,

I am working on a custom platform where U-Boot will be programmed into 
an SPI NOR flash device and the ext4 file systems will be in a removable 
microSD card.  The Linux kernel itself will be stored in the /boot 
directory of the root file system.


The customer wants the (16GB) microSD card formatted as 1GB to mount at 
/ and the remaining 15GB mounted as /home.


In the recipe for my image I have defined the following to try to create 
a suitable image for writing to the microSD card:


IMAGE_FSTYPES_append = " wic"
IMAGE_ROOTFS_SIZE = “1048576”

The image file that is being created is bigger than 1GB even though the 
root file system is only a little over 450MB.  Looking at the contents 
of what gets written to the microSD card this looks as though it is, in 
part, because it also includes the ~20MB “boot” partition containing the 
boot files.


A couple of questions…

How do I stop the wic generation process including the FAT formatted 
“boot” partition?


What is the best strategy for partitioning / formatting / mounting the 
second partition as /home?  Should it be part of the image build process 
or a one-time task run at first boot?


-Andy.

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

Re: [yocto] Building SDK for macOS

[Andy Pont]

Ross wrote...


Did a little poking.

The need to build a SDK tarball on an existing macOS could probably be removed 
by using one of the convenient tarballs from 
https://github.com/phracker/MacOSX-SDKs/releases.

The SDK is 32-bit, which is going to be an issue on modern macOS systems.

The layer has several versioned bbappends which need updating to work with 
recent releases.

None of this is insurmountable, meta-darwin has been used for products in the 
past and with a little effort can be made to do so again.
Thanks for the feedback. If time allows I may take a look into some of 
these issues and see if they are resolvable. In the meantime, I think a 
headless Linux VM with SSH and NFS support enabled might be the quicker 
route to follow.


-Andy.



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

[yocto] Building SDK for macOS

[Andy Pont]

This may be a really dumb question but is it possible to generate an SDK 
from a Yocto build that will allow cross compilation of an application 
to be done on a machine running macOS?


-Andy.


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

[yocto] Init stops working on second boot cycle

[Andy Pont]

I’ve got a strange issue and I don’t know whether it is a Yocto related 
issue, a kernel issue or something else completely…


I have an image that is built with thud (2.6.2) using meta-atmel for the 
SAMA5D2-Xplained reference board.  I deploy the resulting .wic file to 
an SD card and boot the reference board and all is OK.  I can log into 
the terminal, upload files, etc. and again all seems to be well.


If I press the reset button on the hardware platform, on the next boot 
cycle it always stops with the following being last messages being 
displayed:


Freeing unused kernel memory: 1024K
Run /sbin/init as init process
INIT: version 2.88 booting

The system hasn’t completely hung as the occasional kernel message 
appears but the user space init process (sysvinit) doesn’t seem to be 
working at all.  If I put the SD card into a Linux desktop machine the 
file system on it is still valid and the changes that I have made are 
still present.


Anyone got any ideas as to what is screwing it up?

-Andy.



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

[yocto] libgroove recipe

[Andy Pont]

Hello,

Does anyone know if there is a recipe for librgoove[1] and supporting 
libraries?  I have searched in the OpenEmbedded Layer Index and more 
widely on the web but can’t see anything but maybe someone knows a dark 
corner it may be hiding in.


-Andy.

1 - https://github.com/andrewrk/libgroove


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

Re: [yocto] Shared area conflict

[Andy Pont]

Khem wrote...


there are two recipes building/installing same files. You have to
avoid conflicts via either removing them from one recipe or not
installing them
I’ve fixed this issue by creating a .bbappend file in my custom 
meta-layer that tells mesa not to install these two packages.


Only one major issue left to resolve which is described in [1] albeit 
that I have gone back to thud but I get the same results as I did with 
warrior. I have borrowed the recipes for v1.14 of the PowerVR drivers 
from [2] and fixed a couple of kernel compile issues for kernel >= 
4.1.15 and will try those once I have the device tree entries for my LCD 
cape incorporated.


-Andy.

1. https://lists.yoctoproject.org/pipermail/yocto/2019-July/046165.html
2. https://git.phytec.de/meta-phytec
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Shared area conflict

[Andy Pont]

Hello,

When I try to bitbake core-image-minimal it is giving up with the 
following error:


ERROR: mesa-gl-2_18.1.9-r0 do_packagedata: The recipe mesa-gl is trying 
to install files into a shared area when those files already exist. 
Those files and their manifest location are:

  /home/me/Yocto/BeagleBoneBlack/tmp/pkgdata/beaglebone/runtime/libgbm
(matched in manifest-beaglebone-libgbm.packagedata)
  
/home/me/Yocto/BeagleBoneBlack/tmp/pkgdata/beaglebone/runtime/libgbm-dev

(matched in manifest-beaglebone-libgbm.packagedata)
Please verify which recipe should provide the above files.

I’ve tried one of the suggestions that it gives in the rather verbose 
message that follows and nuked the “tmp” directory and rebuilt but with 
no further success.  My local.conf contains:


PREFERRED_PROVIDER_libgbm = “libgbm”
PREFERRED_PROVIDER_libgbm-dev = "libgbm-dev”

How do I get it to stop complaining?

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

Re: [yocto] Building for AM335x with meta-ti and meta-qt5

[Andy Pont]

I wrote about trying to compile the SGX kernel modules giving up with 
the following error:



| *** Multiarch build: no
| *** Primary arch:target_armel
| *** Secondary arch:  none
| ../config/core.mk:513: $(KERNELDIR)/vmlinux does not exist. Kbuild 
may fail.
| eurasiacon/build/linux2/toplevel.mk:230: 
eurasiacon/build/linux2/moduledefs/target_armel.mk: No such file or 
directory


This gets pulled from 
https://git.ti.com/graphics/omap5-sgx-ddk-linux/commits/ti-img-sgx/1.17.4948957/k4.19 
and the files in the …/eurasiacon/build/linux2/moduledefs/ directory 
are:


host_i386.mk
target_aarch64.mk
target_i686.mk
target_neutral.mk
host_x86_64.mk
target_armhf.mk
target_mips32r2el.mk
target_x86_64.mk

I’m guessing it is supposed to be using target_armhf.mk but I can’t 
figure out why it is making the incorrect decision and trying to use a 
file that doesn’t exist.


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

[yocto] Building for AM335x with meta-ti and meta-qt5

[Andy Pont]

I am trying to build a Yocto (warrior) image for the AM335x using 
meta-ti and meta-qt5 that will render directly to the GPU.  Initially 
this will be for the Beaglebone Black but then ultimately will be for a 
custom hardware platform.


In broad outline, I think, the software stack needs to look a bit like:

Qt Application
QtBase, QtWebEngine, etc.
Qt-OpenGL
ti-sgx-ddk
AM335x GPU

I have included meta-ti and meta-qt5 into my belayers.conf and added 
ti-sgx-ddk-km, ti-sgx-ddk-um, qtbase and qtwebengine to 
IMAGE_INSTALL_append.  When I try to bitbake core-image-minimal I start 
to get a failure to compile ti-sgx-ddk-km with a number of, what appear 
to be, warnings of the form:


KBUILD_EXTRA_SYMBOLS=
| grep: 
/home/me/Yocto/BeagleBoneBlack/tmp/work-shared/beaglebone/kernel-source/include/linux/amba: 
Is a directory
| grep: 
/home/me/Yocto/BeagleBoneBlack/tmp/work-shared/beaglebone/kernel-source/include/linux/avf: 
Is a directory


It then ultimately appears to give up with:

| *** Multiarch build: no
| *** Primary arch:target_armel
| *** Secondary arch:  none
| ../config/core.mk:513: $(KERNELDIR)/vmlinux does not exist. Kbuild may 
fail.
| eurasiacon/build/linux2/toplevel.mk:230: 
eurasiacon/build/linux2/moduledefs/target_armel.mk: No such file or 
directory


Is there a specific kernel I need to define in local.conf that the GPU 
drivers build against?


Also, is there any specific configuration I need to do in order to get 
Qt to use the SGX OpenGL drivers?


I have had a search on the web but not found anything for recent Yocto 
versions, only very old stuff.


-Andy.

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

Re: [yocto] wpewebkit, cog and libgles2

[Andy Pont]

I wrote...

The conf/distro/poky-atmel.conf file in meta-atmel contains the 
following line:


DISTRO_FEATURES_remove ?= "opengl wayland x11 3g nfc pulseaudio”

Switching back to the regular DISTRO = “poky” seems to have got it 
building again.
Switching back to poky caused a whole host of other issues.  I have 
managed to create a configuration that fully builds cog and wpewebkit 
using poky-atmel with wpebackend-rdk, wayland and core-image-weston.


When I boot the board a desktop appears with an icon that opens a 
Wayland terminal.   I’m trying to find some information on how to 
replace that so that it starts Cog automatically at boot up but not 
finding anything helpful.  I know that Cog itself works as I can start 
it up using the debug terminal.


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

[yocto] Atmel device tree overlays

[Andy Pont]

Hello,

The meta-atmel layer includes a BSP recipe called dt-overlay-at91[1] 
that pulls in a number of .dtso files for various peripheral devices 
that can be connected to their reference boards.


I can’t figure out how to get the overlays into the FIT image that my 
board is booting from.  For the time being, if I have to include all of 
them then so be it but ideally I would like to be able to define which 
get used.


-Andy.

[1] https://layers.openembedded.org/layerindex/recipe/88706/

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

Re: [yocto] wpewebkit, cog and libgles2

[Andy Pont]

Ross wrote...


Search that until you find the DISTRO_FEATURES= and see if it it
contains opengl.  It presumably doesn't, and above the assignment it
will tell you what removed it (or the absence of something adding it).


The conf/distro/poky-atmel.conf file in meta-atmel contains the 
following line:


DISTRO_FEATURES_remove ?= "opengl wayland x11 3g nfc pulseaudio”

Switching back to the regular DISTRO = “poky” seems to have got it 
building again.


Thanks for your help and guidance!

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

Re: [yocto] wpewebkit, cog and libgles2

[Andy Pont]

Joshua wrote...


I’m confused now as there appears to be two active meta layers that support WPE 
WebKit. The one you reference meta-wpe and the one I was originally using 
meta-webkit (https://github.com/Igalia/meta-webkit) as that was the one that 
included Cog. Is one preferred to the other?


AFAIK, meta-webkit is the one you should be using. Its the one currently being 
actively maintained by the WPEWebKit folks.
I have gone back to using that one. I think I am being a bit dim (I 
blame the unusually warm UK weather) but I can’t see what bitbake is 
complaining about. Having added:


IMAGE_INSTALL_append = " nodejs wpewebkit”

bitbake reports:

ERROR: Nothing PROVIDES 'libepoxy' (but 
/home/me/yocto/sources/meta-webkit/recipes-browser/wpewebkit/wpewebkit_2.24.2.bb 
DEPENDS on or otherwise requires it)
libepoxy was skipped: missing required distro feature 'opengl' (not in 
DISTRO_FEATURES)


despite my local.conf containing:

DISTRO_FEATURES_append = " opengl libepoxy”

Can someone put me out of my misery?

-Andy.

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

[yocto] Pre-installing node.js packages

[Andy Pont]

Hello,

Is there a way to add node.js packages into a build?  I’m trying to 
avoid having to include npm and compiler into my target image.


-Andy.

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

Re: [yocto] wpewebkit, cog and libgles2

[Andy Pont]

Ross wrote...


Well the libwpe build script says this:

find_package(EGL REQUIRED)

(https://github.com/WebPlatformForEmbedded/libwpe/blob/master/CMakeLists.txt)


I’m confused now as there appears to be two active meta layers that 
support WPE WebKit. The one you reference meta-wpe and the one I was 
originally using meta-webkit (https://github.com/Igalia/meta-webkit) as 
that was the one that included Cog. Is one preferred to the other?



Which suggests that you can't build it without EGL.  You should
investigate whether EGL is simply an option, or whether it's used as a
fundamental part of the rendering.  If it's optional then the Mesa
recipe can build a software GL implementation, if the latter then
you'll need a new browser as software GL is *terrible*.
I’m not wedded to Cog as a browser. I just need something that can 
support HTML5 and Javascript as it will be running a single page 
application (SPA) served from localhost.


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

[yocto] wpewebkit, cog and libgles2

[Andy Pont]

Hello,

I am trying to add wpewebkit and the cog browser on top of a 
core-image-minimal build using Warrior.  When I try to build bitbake 
gives me the following output:


ERROR: Nothing PROVIDES 'virtual/egl' (but 
/home/me/yocto/sources/meta-webkit/recipes-browser/wpewebkit/wpewebkit_2.24.2.bb, 
/home/me/yocto/sources/meta-webkit/recipes-browser/libwpe/libwpe_1.2.0.bb 
DEPENDS on or otherwise requires it). Close matches:

  virtual/kernel
  virtual/perf
  virtual/mesa

I am building for a Microchip (Atmel) SAMA5D2 using meta-atmel.  We 
don’t need OpenGL or 3D support - hence one of the reasons for picking 
the SAMA5D2 which doesn’t have a hardware GPU.


The options appear to be to either add software OpenGL support to the 
configuration to resolve the dependency or tell wpewebkit not to want 
OpenGL support.


Any advice on the easiest way to resolve this would be much appreciated.

-Andy.


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

Re: [yocto] any rumblings about a newer YP powerpc reference board than mpc8315e-rdb?

[Andy Pont]

Robert wrote...

> > I would look at one of the P10xx series QorIQ boards.  Digi-Key list
> > the P1021RDB-PC-ND and P1024RDB-PA-ND as being active parts which
> > are either single or dual e500 cores.
> 
>   i would start with the machine definition files in the meta-fsl-ppc
> layer:
> 
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-ppc/tree/conf/machine
> 
> and see what looks promising. however, IIRC, one of the properties of
> a YP reference board is that it shouldn't be stupid, crazy expensive,
> no? so anything climbing above $500 (USD) might not be an option.
> people used to spending $60 for a beaglebone black might have a
> seizure to suddenly realize they need $500 for a powerpc reference
> board.

Using Digi-Key UK as my reference, they list the MPC8308-RDB-ND and
MPC8313E-RDBC-ND as being available for less than £250 which makes them sub
$300 which is probably the best price I have seen for Power Architecture
reference boards.

Granted, they are still more expensive than a BBB, RPi or something like
that but cheap compared to >$2,000 reference boards we used to have to buy
in the old days!

-Andy



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

Re: [yocto] any rumblings about a newer YP powerpc reference board than mpc8315e-rdb?

[Andy Pont]

Ross Burton wrote...

>> it seems of limited value for YP to have a powerpc reference board,
>> mpc8315e-rdb, that is essentially impossible to procure. is there any
>> effort being made to look around for a newer powerpc reference board
>> that people could actually buy?
>
>Do you have any suggestions?

If we are being strictly pedantic then is isn't PowerPC (at least in the world 
that is Freescale / NXP / Whoever they are this week).

I would look at one of the P10xx series QorIQ boards.  Digi-Key list the 
P1021RDB-PC-ND and P1024RDB-PA-ND as being active parts which are either single 
or dual e500 cores.

-Andy

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

[yocto] TI DM355

[Andy Pont]

Hello,

I appreciate that the TI DM355 is now a very old device (ARM9 based) but I
was wondering what the best starting point would be as I can't see it in the
meta-ti layer.

Any thoughts?

Andy.

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

Re: [yocto] Setting root password

[Andy Pont]

Hi Daniel,

> I didn't know about this EXTRA_USERS_PARAMS. What I do is adding this 
> function to
> my image. 
> # This function sets the password for root based on ROOT_PASSWD variable
> set_root_password () {
> local p=$(openssl passwd -1 -salt "My salt" "${ROOT_PASSWD}")
>sed -e "s/root:[^:]*:/root:${p}:/" -i ${IMAGE_ROOTFS}/etc/shadow
> }
> And append it to ROOTFS_POSTPROCESS_COMMAND:
> ROOTFS_POSTPROCESS_COMMAND += "set_root_password; "
> I did all this in a class file which I import on all my images, 

As your method works and the EXTRA_USERS_PARAMS appears not to be doing could 
you send me your class file to save me having to reinvent the wheel?

> About your problem, can you get the "usermod" error from log.do_rootfs 

The end of the log.do_roots file just contains the following:

NOTE: Executing set_user_group ...
DEBUG: Executing shell function set_user_group
NOTE: Performing usermod with [-R 
X/build/tmp/work/intel_core2_32-poky-linux/core-image-minimal-initramfs/1.0-r0/rootfs
 -P Hkw6rBJlcfhvM root] and 1 times of retry
Server refused shutdown.  Remaining client fds: 2
Client pids: 3878 16245
Server will shut down after all clients exit.
WARNING: usermod command did not succeed. Retrying...
ERROR: Tried running usermod command 1 times without success, giving up
WARNING: 
X/build/tmp/work/intel_core2_32-poky-linux/core-image-minimal-initramfs/1.0-r0/temp/run.set_user_group.3878:1
 exit 1 from
  exit 1
DEBUG: Python function do_rootfs finished

Thanks,

Andy.

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

[yocto] Setting root password

[Andy Pont]

Hello,

Looking around the web and reading the assorted documents it seems to be
that the defined way to set the root password is to remove "debug-tweaks"
from EXTRA_IMAGE_FEATURES and to add the following lines to local.conf:

require conf/distro/include/security_flags.inc
INHERIT += "extrausers"
EXTRA_USERS_PARAMS = "usermod -P  root;"

When I try to build core-image-minimal then the build fails with the
following:

| DEBUG: Executing shell function set_user_group
| NOTE: Performing usermod with [-R
X/build/tmp/work/intel_core2_32-poky-linux/core-image-minimal-initramfs/
1.0-r0/rootfs -P Hkw6rBJlcfhvM root] and 1 times of retry
| Server refused shutdown.  Remaining client fds: 2
| Client pids: 3878 16245
| Server will shut down after all clients exit.
| WARNING: usermod command did not succeed. Retrying...
| ERROR: Tried running usermod command 1 times without success, giving up
| WARNING:
X/build/tmp/work/intel_core2_32-poky-linux/core-image-minimal-initramfs/
1.0-r0/temp/run.set_user_group.3878:1 exit 1 from
|   exit 1
| DEBUG: Python function do_rootfs finished
| ERROR: Function failed: set_user_group (log file is located at
X/build/tmp/work/intel_core2_32-poky-linux/core-image-minimal-initramfs/
1.0-r0/temp/log.do_rootfs.3878)

Any ideas on how to make this work?

Thanks,

Andy.

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

Re: [yocto] Setting root password

[Andy Pont]

Rudi wrote…

> > Still, I think is a good ideia to understand what is going wrong with
> > EXTRA_USERS_PARAMS, other users may having the same problem.
>
> EXTRA_USERS_PARAMS works for me all the time. The stanza is what I am
using 
> in my image recipes:
> 
> EXTRA_USERS_PARAMS = "\
> groupadd developers; \
> useradd -p `openssl passwd ${DEV_PASSWORD}` developer; \
> useradd -g developers developer; \
> usermod -p `openssl passwd ${ROOT_PASSWORD}` root; \
>"
>
> If this is an accurate copy of what you are using
>
> EXTRA_USERS_PARAMS = "usermod -P  root;"
>
> then the issue probably is the capital -P. It should be lowercase.

Good spot.  I copied and pasted it from an article I found on the web!
Having changed it to lower case it now works as expected!

Thanks,

Andy.

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

[yocto] psplash wierdness

[Andy Pont]

I have spent all morning fine tuning psplash on a PXE booting system using
an NFS mounted root file system (all built with Yocto 1.8 for the
intel-core2-32 machine) and all is exactly as I need.

When I boot the system using an initrd of the same file system the first
output from the init process is:

/etc/init.d/rc: /etc/rcS.d/S00psplash.sh: line 28: can't open '/dev/null'

Line 28 of S00psplash.sh corresponds to the call to /usr/bin/psplash to
display the image to hide the init messages.

Am I being a complete numpty (highly probable) or have I missed something
about using an initrd?

Thanks,

Andy.


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

Re: [yocto] psplash wierdness

[Andy Pont]

Khem wrote...


> Your initrd is missing /dev/null device it seems. You need to create it dring 
> build or 
> some runtime mechanism 

Hmmm, on further inspection it appears that in the /etc/rcS.d run level that 
psplash has been created as S00 while udev which is presumably going to create 
these devices isn't setup to be called until S04!

Bit more thought needed here...

Andy.

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

Re: [yocto] Dumping sysvinit

[Andy Pont]

Hi Mike,

> > Back to plan A then, trying to figure out how to get Busybox init and
> mdev as the defaults in the image.
> 
> Create your own distro, here's an example that uses mdev:
> 
> https://github.com/topic-embedded-products/meta-
> topic/blob/master/conf/distro/tiny.conf

Thanks for pointing me in the direction of this.  I have cloned it and used
it as the basis of my distro, tweaked it a bit and it is starting to behave
how I want.  There are a few anomalies that I haven't managed to figure out
yet...

Despite having VIRTUAL-RUNTIME_initscripts = "" the root file system still
contains /etc/rcX.d directories

On other embedded Linux projects that boot using Busybox init the
/etc/init.d directory contained the individual service start and kill files
e.g. S50-dropbear and K50-dropbear but I can't see how to make Yocto
populate this directory in that form.

Thoughts and guidance from anyone would be much appreciated!

Andy.


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

Re: [yocto] Dumping sysvinit

[Andy Pont]

Hello all,

> > I think if you remove/comment-out the last of those 3 lines or install
> > your host's SDL-devel package you'll solve this issue (?)
> >
> Yes, that's right.  Either disable the graphical qemu support, or install
> the host's sdl-devel package so it can build.

On my CentOS 6.7 host system running the package manager reports that SDL-devel 
is already installed:

# yum install SDL-devel
Package SDL-devel-1.2.14-6.el6.x86_64 already installed and latest version
Nothing to do

This is probably something to do with the fact that in order to get Fido to 
build I have to use the devtoolset-2.1 package to get a recent gcc version and 
it probably isn't aware of the standard SDL-devel libraries.

Commenting out just the last line of the 3 QEMU/SDL related lines throws out a 
couple of errors whereas removing all of them gives me a build.

Now to figure out why the tar.gz file for the root file system has grown from 
just under 3MiB to almost 15MiB!

Thanks for all the help and advice.

Andy.




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

Re: [yocto] Dumping sysvinit

[Andy Pont]

Ross wrote...

> > Now to figure out why the tar.gz file for the root file system has grown 
> > from just under 3MiB to almost 15MiB!
> 
> That would be systemd... it pulls in a lot of libraries that are fairly common
> on complex systems but on a minimal image less so.

Back to plan A then, trying to figure out how to get Busybox init and mdev as 
the defaults in the image.

Thanks for the feedback!

Andy.

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

Re: [yocto] Dumping sysvinit

[Andy Pont]

Mark wrote...

> > Bit of a newbie question (probably) but what is the easiest way to dump
> > sysvinit and use Busybox init in a core-image-minimal image?
> 
> It has been a while since I've done this.  But unless things have changed
> dramatically.  You will need to define your own custom image.

On the basis that sounded like more hard work than I have time for I thought
I would try switching to systemd.  Following the instructions in the dev
manual [1].

If I add the extra variables to build/conf/local.conf then with the machine
type set to genericx86 I get this build error:

ERROR: Function failed: do_configure (log file is located at
X/build/tmp/work/x86_64-linux/qemu-native/2.2.0-r1/temp/log.do_configure
.1926)
ERROR: Logfile of failure stored in:
X/build/tmp/work/x86_64-linux/qemu-native/2.2.0-r1/temp/log.do_configure
.1926
Log data follows:
| DEBUG: Executing python function sysroot_cleansstate
| DEBUG: Python function sysroot_cleansstate finished
| DEBUG: Executing shell function autotools_preconfigure
| DEBUG: Shell function autotools_preconfigure finished
| DEBUG: Executing python function autotools_copy_aclocals
| DEBUG: Python function autotools_copy_aclocals finished
| DEBUG: Executing shell function do_configure
| 
| ERROR: User requested feature sdl
|configure was not able to find it.
|Install SDL devel

I'm guessing that this is me being dim and that build/conf/local.conf isn't
what the documentation refers to as "your distribution configuration file".
Can someone point me in the right direction?

Thanks,

Andy.

[1]
http://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html#selecting-an
-initialization-manager

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

[yocto] Dumping sysvinit

[Andy Pont]

Hello,

Bit of a newbie question (probably) but what is the easiest way to dump
sysvinit and use Busybox init in a core-image-minimal image?

Thanks,

Andy.


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

[yocto] Build failure (Segmentation fault) with Fido on CentOS

[Andy Pont]

Hello,

After several years away from OpenEmbedded and MVL6 I am back trying to work
with Yocto and BitBake!

My build system is a Core-i7 3770 running CentOS 6.7 (x86_64) with all the
latest updates applied.  I have cloned Fido from the git repository and set
the target as "genericx86" and started the build with "bitbake
core-image-minimal".  The build is failing with the following output (some
path names changed to protect the innocent):

g++: Internal error: Segmentation fault (program as)
| Please submit a full bug report.
| See  for instructions.
| Makefile:1059: recipe for target 'tree.o' failed
| make[1]: *** [tree.o] Error 1
| make[1]: *** Waiting for unfinished jobs
| rm gcc.pod
| make[1]: Leaving directory
'X/build/tmp/work/x86_64-poky-linux/gcc-cross-initial-i586/4.9.2-r0/gcc-
4.9.2/build.x86_64-linux.i586-poky-linux/gcc'
| Makefile:3954: recipe for target 'all-gcc' failed
| make: *** [all-gcc] Error 2
| ERROR: oe_runmake failed
| WARNING:
X/build/tmp/work/x86_64-poky-linux/gcc-cross-initial-i586/4.9.2-r0/temp/
run.do_compile.9831:1 exit 1 from
|   exit 1
| ERROR: Function failed: do_compile (log file is located at
X/build/tmp/work/x86_64-poky-linux/gcc-cross-initial-i586/4.9.2-r0/temp/
log.do_compile.9831)

As CentOS runs some very old versions of certain tools I have installed the
native standalone SDK (v1.8) to get a version of Python that works for
BitBake.  Is this down to the fact that the native gcc/g++ version on CentOS
is 4.4.7 and binutils is v2.20.51 or have I missed something in the setup?

Thanks,

Andy.


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