Re: [yocto] [meta-raspberrypi] Confusion about U-Boot setup

[Belisko Marek]

Hi,

On Wed, Sep 4, 2019 at 6:56 PM Greg Wilson-Lindberg
 wrote:
>
> > -Original Message-
> > From: Belisko Marek [mailto:marek.beli...@gmail.com]
> > Sent: Wednesday, September 04, 2019 12:26 AM
> > To: Greg Wilson-Lindberg 
> > Cc: Yocto list discussion 
> > Subject: Re: [yocto] [meta-raspberrypi] Confusion about U-Boot setup
> >
> > Hi,
> >
> > On Tue, Sep 3, 2019 at 8:58 PM Greg Wilson-Lindberg 
> > wrote:
> > >
> > > I've configured a sumo build, by way of QT's boot2qt to use u-boot and I 
> > > am
> > seeing a u-boot prompt for keypress to drop out of automatic booting on 
> > startup, but
> > I don't see any configuration scripts for u-boot (uEnv.txt or a script) on 
> > the image or
> > in the build tmp/ dir.
> > >
> > > For the raspberry pi, how is u-boot configured on startup?
> > there is u-boot variable called bootdelay which can be set to e.g. 2 to 
> > wait until
> > autoboot for 2 secs. I think this is the case. Thanks.
>
> There is a variable "BOOT_DELAY", that is used to tell the Raspberry Pi boot 
> loader to delay after setting up the graphics and before loading the kernel. 
> This has nothing to do with u-boot.  There should be some way to change the 
> u-boot delay that waits for user input, among other things, I just haven't 
> been able to find it yet and was wondering if someone could point me to where 
> it can be found.
I think you need to look at u-boot source. Such thing is not available
in yocto IIRC.
>
> BR,
> Greg
>
> > >
> > > Regards,
> > > Greg Wilson-Lindberg
> > >
> > > --
> > > ___
> > > yocto mailing list
> > > yocto@yoctoproject.org
> > > https://lists.yoctoproject.org/listinfo/yocto
> >
> > BR,
> >
> > marek

BR,

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

Re: [yocto] [meta-raspberrypi] Confusion about U-Boot setup

[Belisko Marek]

Hi,

On Tue, Sep 3, 2019 at 8:58 PM Greg Wilson-Lindberg
 wrote:
>
> I've configured a sumo build, by way of QT's boot2qt to use u-boot and I am 
> seeing a u-boot prompt for keypress to drop out of automatic booting on 
> startup, but I don't see any configuration scripts for u-boot (uEnv.txt or a 
> script) on the image or in the build tmp/ dir.
>
> For the raspberry pi, how is u-boot configured on startup?
there is u-boot variable called bootdelay which can be set to e.g. 2
to wait until autoboot for 2 secs. I think this is the case. Thanks.
>
> Regards,
> Greg Wilson-Lindberg
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

BR,

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

Re: [yocto] Fetching Yocto layers

[Belisko Marek]

On Mon, Sep 2, 2019 at 4:50 PM Maciej Pijanowski
 wrote:
>
>
> On 02.09.2019 15:51, Josef Holzmayr wrote:
> > I'd like to throw kas into the discussion too, I've been using it quite
> > successfully.
> >
> > https://github.com/siemens/kas
> +1 for kas. Previously I was using repo, custom scripts and custom
> Docker container for running  the build. kas does all of that
> and makes significantly faster for me to start a new project.
>
> I have described my repo vs kas experience a while ago
> if someone would be interested: https://blog.3mdeb.com/2019/2019-02-07-kas/
Thanks for sharing blog post, really useful. I also discovered kas
tool few months ago and as Maciej said it's really convenient and nice
tool for helping managing
multiple yocto layers. Usually I have multiple targets so using kas
docker I build them by changing only machine and kas take care of
rest. Really recommend it.
> I hope it's fine to link to one's blog post there?
> >
> > Greetz
> >
> > On Mon, Sep 02, 2019 at 03:34:28PM +0200, Alexander Kanavin wrote:
> >> On Mon, 2 Sep 2019 at 15:05, Brian Silverman  wrote:
> >>
> >>> The tags chosen above are based on what we test and ship.  So my issue is
> >>> that someone has to correctly follow the above instructions for different
> >>> versions of multiple layers if they want a reproducible build of a 
> >>> specific
> >>> version of mylayer-image.
> >>>
> >>> Is there a canonical why to encode this information within my layer?
> >>> Obviously I could script the above, store it in my layer, and have the 
> >>> user
> >>> run that script.  But, that seems very unyocto-like.
> >>>
> >> At the moment Yocto project does not have an off-the shelf setup for
> >> multiple layers. You are welcome to provide and maintain one, until then it
> >> is indeed custom scripts, or tools like Google's 'repo', or maybe git
> >> submodules could work.
> >>
> >> Alex
> >> --
> >> ___
> >> yocto mailing list
> >> yocto@yoctoproject.org
> >> https://lists.yoctoproject.org/listinfo/yocto
> >
> --
> Maciej Pijanowski
> Embedded Systems Engineer
> https://3mdeb.com | @3mdeb_com
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

BR,

marek
-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] MySql python support in Yocto.

[Belisko Marek]

Hi Mauro,

On Wed, Aug 28, 2019 at 6:14 AM Mauro Ziliani  wrote:
>
> Hi all.
>
> There is some library for MariaDB/MySql in Python3 in Yocto?
You can check: https://layers.openembedded.org/layerindex/recipe/4825/
>
>
> Best regards.
>
>MZ
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] building SDK artifacts with external toolchain

[Belisko Marek]

Hi,

I have an dilema to solve. I have an SDK from vendor which contains
scripts to build u-boot + kernel + some kind of application and create
initramfs out of that and this can be flashed to NOR device and boot.
But setup and using is really horrible. Idea is to port this process
to yocto and have possibility to be used as yocto SDK for development.
Issue is that u-boot and kernel are obsolete (u-boot 2010 and kernel
3.18) and after few fixed I was able to buld and run u-boto with 7.3
arm ggc but when building kernel I got some issue with asm and I'm
kind of lost ;). So idea was to use toolchain which SDK provide but
it's again 4.9.4 (some linaro clone). Target is to use poky rocko with
this setup. I tried to build minimal image with external toolchain but
got some QA issues like:

gmp-6.1.2-r0 do_package_qa: QA Issue: libgmpxx rdepends on
external-linaro-toolchain-dbg [debug-deps]
 ERROR: gmp-6.1.2-r0 do_package_qa: QA Issue:
/usr/lib/libgmpxx.so.4.5.2 contained in package libgmpxx requires
libstdc++.so.6(CXXABI_1.3), but no providers found in
RDEPENDS_libgmpxx? [file-rdeps]
 ERROR: gmp-6.1.2-r0 do_package_qa: QA Issue:
/usr/lib/libgmpxx.so.4.5.2 contained in package libgmpxx requires
libstdc++.so.6(CXXABI_ARM_1.3.3), but no providers found in
RDEPENDS_libgmpxx? [file-rdeps]
 ERROR: gmp-6.1.2-r0 do_package_qa: QA Issue:
/usr/lib/libgmpxx.so.4.5.2 contained in package libgmpxx requires
libstdc++.so.6(GLIBCXX_3.4), but no providers found in
RDEPENDS_libgmpxx? [file-rdeps]
 ERROR: gmp-6.1.2-r0 do_package_qa: QA Issue:
/usr/lib/libgmpxx.so.4.5.2 contained in package libgmpxx requires
libstdc++.so.6(GLIBCXX_3.4.11), but no providers found in
RDEPENDS_libgmpxx? [file-rdeps]
 ERROR: gmp-6.1.2-r0 do_package_qa: QA Issue:
/usr/lib/libgmpxx.so.4.5.2 contained in package libgmpxx requires
libstdc++.so.6, but no providers found in RDEPENDS_libgmpxx?
[file-rdeps]

I can workaround those but to me it looks like it's somehow not
compatible or so (was using 4.9.4 linaro toolchain). My idea was to
maybe use older poky (when 4.9 toolchain was used) but I'm not sure I
like this approach. Other ideas? Thanks.

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] U-boot enable not working for Raspberry Pi3

[Belisko Marek]

Hi Greg,

On Tue, Aug 6, 2019 at 8:29 PM Greg Wilson-Lindberg
 wrote:
>
> Hi Marek,
>
> Thanks for the suggestion, that seems to be the case. What image are you 
> building so I can try that to see what I get?
Please don't top post ;). I'm building basic image. I worked few
months ago with bootqt and sometimes it was bit tricky ;). Are you
sure you have this variable set in local.conf?
>
> BR,
> Greg
>
> > -Original Message-
> > From: Belisko Marek [mailto:marek.beli...@gmail.com]
> > Sent: Tuesday, August 06, 2019 11:12 AM
> > To: Greg Wilson-Lindberg 
> > Cc: Yocto list discussion 
> > Subject: Re: [yocto] U-boot enable not working for Raspberry Pi3
> >
> > Hi Greg,
> >
> > On Tue, Aug 6, 2019 at 7:12 PM Greg Wilson-Lindberg 
> > wrote:
> > >
> > > I'm working with a Yocto Sumo build provided with Qt's boot2qt system. 
> > > I'm trying
> > to enable using Das U-boot to load Linux as a first step in trying to 
> > enable OSTree
> > updates.
> > >
> > > In the meta-raspberrypi documentation is says to set:
> > >
> > > RPI_USE_U_BOOT = "1"
> > Could be tha tboot2qt somehow drop your config. Please try tin run bitbake 
> > -e
> >  | grep ^RPI_USE_U_BOOT to be sure that variable exists. I
> > used it many times and it works perfectly fine.
> > >
> > > to enable u-boot for the raspberrypi. I have set that variable in the top 
> > > level
> > local.conf file but I don't seem to be getting any changes in the build. 
> > Nothing in the
> > cooker log shows building u-boot, and the start up screen doesn't show any 
> > u-boot
> > messages.
> > >
> > > It appears that I'm missing necessary to turn u-boot on, can anybody shed 
> > > some
> > light on what is going on?
> > >
> > > Regards,
> > >
> > > Greg Wilson-Lindberg
> > > www.sakuraus.com
> > > --
> > > ___
> > > yocto mailing list
> > > yocto@yoctoproject.org
> > > https://lists.yoctoproject.org/listinfo/yocto
> >
> > BR,
> >
> > marek
> >
> > --
> > as simple and primitive as possible
> > -
> > Marek Belisko - OPEN-NANDRA
> > Freelance Developer
> >
> > Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
> > Tel: +421 915 052 184
> > skype: marekwhite
> > twitter: #opennandra
> > web: http://open-nandra.com

BR,

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

Re: [yocto] U-boot enable not working for Raspberry Pi3

[Belisko Marek]

Hi Greg,

On Tue, Aug 6, 2019 at 7:12 PM Greg Wilson-Lindberg
 wrote:
>
> I'm working with a Yocto Sumo build provided with Qt's boot2qt system. I'm 
> trying to enable using Das U-boot to load Linux as a first step in trying to 
> enable OSTree updates.
>
> In the meta-raspberrypi documentation is says to set:
>
> RPI_USE_U_BOOT = "1"
Could be tha tboot2qt somehow drop your config. Please try tin run
bitbake -e  | grep ^RPI_USE_U_BOOT to be sure that
variable exists. I used it many times and it works perfectly fine.
>
> to enable u-boot for the raspberrypi. I have set that variable in the top 
> level local.conf file but I don't seem to be getting any changes in the 
> build. Nothing in the cooker log shows building u-boot, and the start up 
> screen doesn't show any u-boot messages.
>
> It appears that I'm missing necessary to turn u-boot on, can anybody shed 
> some light on what is going on?
>
> Regards,
>
> Greg Wilson-Lindberg
> www.sakuraus.com
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] meta-openstack: bundler fails to build

[Belisko Marek]

Hi,

I'm trying to build bundler ruby tool from meta-openstack (thud
branch) but it fails with following:

ERROR: bundler-1.6.2-r0 do_compile: Function failed: do_compile (log
file is located at
/home/builder/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/bundler/1.6.2-r0/temp/log.do_compile.2232)
ERROR: Logfile of failure stored in:
/home/builder/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/bundler/1.6.2-r0/temp/log.do_compile.2232
Log data follows:
| DEBUG: Executing shell function do_compile
| ERROR:  Loading command: build (LoadError)
| cannot load such file -- zlib
| ERROR:  While executing gem ... (NoMethodError)
| undefined method `invoke_with_build_args' for nil:NilClass
| WARNING: exit code 1 from a shell command.

Any ideas what should be checked (I'm not familiar with ruby at all).
I plan to also bump bundler to 2.0 version so can share then results
and recipe. Thanks.

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] wic: error when using --rootfs-dir=${IMAGE_ROOTFS}/data

[Belisko Marek]

On Tue, Jul 16, 2019 at 8:54 AM Mittal, Anuj  wrote:
>
> On Tue, 2019-07-16 at 08:38 +0200, Belisko Marek wrote:
> > I have wks file with following content:
> >
> > part ubootenv --ondisk=mmcblk --no-table --size 12
> > part /boot --source bootimg-partition --ondisk mmcblk --fstype=vfat
> > --label boot --active --align 1024 --size 16
> > part /root --source rootfs --ondisk mmcblk --fstype=ext4 --label
> > rootA
> > --align 1024 --fixed-size 300 --exclude-path data/
> > part /data --source rootfs --rootfs-dir=${IMAGE_ROOTFS}/data --ondisk
> > "mmcblk" --fstype=ext4 --label data --align 1024 --fixed-size 200
> >
> > Basically I want to create extra data partition with content from
> > rootfs /data directory. When wic image is created I'm getting strange
> > errors like:
> >
> > Couldn't get bitbake variable from
> > /home/marekbelisko/.build/tmp/sysroots/raspberrypi0-
> > wifi/imgdata/${IMAGE_ROOTFS}/data.env.
> >  | File /home/marekbelisko/.build/tmp/sysroots/raspberrypi0-
> > wifi/imgdata/${IMAGE_ROOTFS}/data.env
> > doesn't exist.
>
> If you haven't tried this already, renaming .wks to .wks.in might help.
Thanks that does the trick. But I'm completely confused why? ;) Any
explanation? Thanks.
>
> Thanks,
> Anuj

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] wic: error when using --rootfs-dir=${IMAGE_ROOTFS}/data

[Belisko Marek]

Hi,

I have wks file with following content:

part ubootenv --ondisk=mmcblk --no-table --size 12
part /boot --source bootimg-partition --ondisk mmcblk --fstype=vfat
--label boot --active --align 1024 --size 16
part /root --source rootfs --ondisk mmcblk --fstype=ext4 --label rootA
--align 1024 --fixed-size 300 --exclude-path data/
part /data --source rootfs --rootfs-dir=${IMAGE_ROOTFS}/data --ondisk
"mmcblk" --fstype=ext4 --label data --align 1024 --fixed-size 200

Basically I want to create extra data partition with content from
rootfs /data directory. When wic image is created I'm getting strange
errors like:

Couldn't get bitbake variable from
/home/marekbelisko/.build/tmp/sysroots/raspberrypi0-wifi/imgdata/${IMAGE_ROOTFS}/data.env.
 | File 
/home/marekbelisko/.build/tmp/sysroots/raspberrypi0-wifi/imgdata/${IMAGE_ROOTFS}/data.env
doesn't exist.

I found similar usage (for boot directory in poky):
scripts/lib/wic/canned-wks/efi-bootdisk.wks.in:2:part /boot --source
rootfs --rootfs-dir=${IMAGE_ROOTFS}/boot --fstype=vfat --label boot
--active --align 1024 --use-uuid --overhead-factor 1.0

Am I doing something wrong here or any ideas? Thanks.

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] do_rootfs fails while attempting to install hostapd package

[Belisko Marek]

On Sat, Jun 1, 2019 at 8:26 PM Morné Lamprecht  wrote:
>
> >I would check run.do_rootfs and check it maybe
> >there will be some more info.
>
> I checked it based on your suggestion,
> unfortunately found no relevant info.
>
> >Do you have some custom extension for hostapd?
>
> No, just the standard package.
Which startup system do you use (sysVinit or systemd)?
You can take a look at poky/meta/classed/update-rc.d.bbclass which
checks various parameters and try to debug it (by adding some
printouts).
By my guess is that some misconfiguration between systemd/sysvinit
must cause this issue. Thanks.
>
> - Morné

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] do_rootfs fails while attempting to install hostapd package

[Belisko Marek]

Hi,

On Sat, Jun 1, 2019 at 4:41 PM Morné Lamprecht  wrote:
>
> Hi
>
> I created a new custom distribution and
> everything seems to work fine until the do_rootfs
> task is executed. It fails specifically when
> trying to install the hostapd package, with the
> error below (snippet from log.do_rootfs):
I would check run.do_rootfs and check it maybe there will be some more info.
Do you have some custom extension for hostapd? Thanks.
>
> > Running scriptlet: hostapd-2.6-r0.aarch64
> >
> > usage: update-rc.d [-n] [-f] [-r ]  remove update-rc.d
> > [-n] [-r ] [-s]  defaults [NN | sNN kNN]
> > update-rc.d [-n] [-r ] [-s]  start|stop NN runlvl [runlvl]
> >
> > error: %prein(hostapd-2.6-r0.aarch64) scriptlet failed, exit status 1
>
> > error: hostapd-2.6-r0.aarch64: install failed
>
> The hostapd package itself builds fine, it is
> just the installation to the rootfs that fails.
>
> The hostapd package is specified in
> MACHINE_EXTRA_DEPENDS, if I remove it, then the
> build succeeds without any issues.
>
> If I interpret the error correctly, it is the
> preinstall scriptlet that fails...but I am not
> sure where to start debugging this.
>
> Any suggestions ?
>
> - Morné
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

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

[yocto] npm package issue with do_package split_and_strip_files

[Belisko Marek]

Hi,

I'm adding recipe for nodejs package and all steps works fine just
when packaging is done I get strange error like:
['arm-poky-linux-gnueabi-strip', '--remove-section=.comment',
'--remove-section=.note',
'/home/marek/projects/tst/.build-opi/tmp/work/armv7vet2hf-neon-poky-linux-gnueabi/ifu/4.5.2-r0/sysroot-destdir/usr/lib/node/camera/node_modules/usage/compiled/sunos/ia32/0.10/sysinfo.node']'

Looks like it want strip build executable not for arm arch (I'm
building for arm). In recipe I just fetch sources and include npm
class. Thanks.

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] meta-sunxi maintained?

[Belisko Marek]

Hi Maciej,

On Wed, May 29, 2019 at 1:08 PM Maciej Pijanowski
 wrote:
>
>
> On 29.05.2019 09:39, Belisko Marek wrote:
> > Hi Dimitris,
> >
> > On Wed, May 29, 2019 at 9:03 AM Dimitris Tassopoulos  
> > wrote:
> >> Hi Marek,
> >>
> >> that's correct. I have a branch though which I've started to experiment 
> >> and add support for Mali. I didn't finished because I've tried to do this 
> >> by myself from the scratch and soon I've hit a wall. Nevertheless, I've 
> >> done the same for the rk3399 for nanopi-neo4 and during this process I've 
> >> learned a lot on how to do it with some help from other people from the 
> >> open source scene. The graphics stack was too complicated for me in the 
> >> beginning.
> > You can maybe look to meta-sunxi there is sunxi-mali driver +
> > libraries which will add support for that. When I've set that package
> > to PREFERRED_PROVIDER_virtual/gles2 I get issues with compilation
> > gtk3+ and others. I've spend 2 hours looking and trying yesterday but
> > without any success. Also pls look at this communication:
> > https://github.com/linux-sunxi/meta-sunxi/issues/144 (looks like we
> > can use opensource drivers + libs later). Thanks.
> What are you trying to achieve? Which kernel version are you using?
> Isn't the mali recipe in meta-sunxi quite dated already? Can it work
> with mainline kernel correctly?
>
> I would suggest to try the recent blobs as described in this post:
> https://bootlin.com/blog/mali-opengl-support-on-allwinner-platforms-with-mainline-linux/
>
> As I've written previously, I have been using the Wayland / Qt with
> good performance on H3 using the mainline kernel. Is it something you
> are looking for?
> You can take a look at my dirty branch - maybe this will be any help:
> https://github.com/3mdeb/meta-sunxi/tree/weston-with-kms/recipes-graphics/mali
I've took some patches and now core-image-sato can be build. I have
just one question for mali kernel module. Does it need some dts
changes or it will work out of the box (I didn't see any dts changes
in your branch thus I'm asking).
Thanks.
>
> Unfortunately, I had stopped working on that and presently do not have much
> time to clean up / get back to it. I can provide some support and / or get
> back to it if it seems valuable and there is some interest.
> >> Therefore now that I feel much more confident with it I'm going to re-try 
> >> and finish with my branch. Armbian does have support, so I'll try to stick 
> >> to the Armbian backend for maintenance reasons.
> >>
> >> I hope that this will be rather easy, because the dri driver should 
> >> already be there, so the only thing I believe is needed is the blobs and 
> >> to create symlinks for the various so libs to that blob.
> >>
> >> Anyway, I'll try to do that also. In the meantime I will also wait a bit 
> >> to see if that merge between those two layers is possible and doable, 
> >> which will help to short the time and effort to do that.
> >>
> >> Regards,
> >> Dimitris
> > BR,
> >
> > marek
> >> Belisko Marek  schrieb am Mi., 29. Mai 2019, 
> >> 08:37:
> >>> Hi Dimitris,
> >>>
> >>> On Tue, May 28, 2019 at 1:07 PM Dimitris Tassopoulos  
> >>> wrote:
> >>>> Hi Enrico,
> >>>>
> >>>> I'm totally positive to any possibility for such integration. 
> >>>> Personally, that was the first thing I've tried to do before I start 
> >>>> this layer, but I've failed as it got really complex and the overhead 
> >>>> was too much after some point (at least for me). If you have look it's 
> >>>> actually a mix of meta-sunxi and armbian, but I had to remove or change 
> >>>> many stuff to fit the armbian in the layer.
> >>>>
> >>>> If you have time to have a look to my layer and you think that such kind 
> >>>> of integration is possible and can be done in a more easy way, then from 
> >>>> my side I'm all in.
> >>>> I believe that re-using the armbian patches is easier as it makes 
> >>>> maintenance much easier, there are more supported SBCs and also there is 
> >>>> much more testing involved in armbian and frequent updates fix those 
> >>>> bugs.
> >>> I did check your layer and it seems that you're not using sunxi-mali
> >>> for opengl HW acceleration only mesa so SW rendering? Thanks.
> >>>> Please consider it and I can help as much as I can and my time allows 
>

Re: [yocto] warrior: QA issue when bump kernel to 5.2-rc2

[Belisko Marek]

On Thu, May 30, 2019 at 2:35 PM Bruce Ashfield  wrote:
>
> On Thu, May 30, 2019 at 4:14 AM Belisko Marek  wrote:
> >
> > Hi,
> >
> > I'm trying to add support for latest possible released kernel in
> > meta-sunxi by using poky warrior and hit this QA issue:
> > ERROR: linux-mainline-5.2-rc2-r0 do_package: QA Issue: linux-mainline:
> > Files/directories were installed but not shipped in any package:
> >   /lib/modules/5.2.0-rc2/modules.builtin.modinfo
> > Please set FILES such that these items are packaged. Alternatively if
> > they are unneeded, avoid installing them or delete them within
> > do_install.
> > linux-mainline: 1 installed and not shipped files. [installed-vs-shipped]
> >
> > I can simply drop it but would like to see if anything was updated
> > from actual linux-yocto (which is 5.0.3). Ideas? Thanks.
>
> I have a change to kernel.bbclass that packages that new file, and
> explains where it comes from.
>
> Stay tuned, it'll arrive in about 5 minutes :D
Awesome, thanks!
>
> Bruce
>
> >
> > BR,
> >
> > marek
> >
> > --
> > as simple and primitive as possible
> > -
> > Marek Belisko - OPEN-NANDRA
> > Freelance Developer
> >
> > Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
> > Tel: +421 915 052 184
> > skype: marekwhite
> > twitter: #opennandra
> > web: http://open-nandra.com
> > --
> > ___
> > 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
> - "Use the force Harry" - Gandalf, Star Trek II

BR,

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

[yocto] warrior: QA issue when bump kernel to 5.2-rc2

[Belisko Marek]

Hi,

I'm trying to add support for latest possible released kernel in
meta-sunxi by using poky warrior and hit this QA issue:
ERROR: linux-mainline-5.2-rc2-r0 do_package: QA Issue: linux-mainline:
Files/directories were installed but not shipped in any package:
  /lib/modules/5.2.0-rc2/modules.builtin.modinfo
Please set FILES such that these items are packaged. Alternatively if
they are unneeded, avoid installing them or delete them within
do_install.
linux-mainline: 1 installed and not shipped files. [installed-vs-shipped]

I can simply drop it but would like to see if anything was updated
from actual linux-yocto (which is 5.0.3). Ideas? Thanks.

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] meta-sunxi maintained?

[Belisko Marek]

Hi Maciej,

On Wed, May 29, 2019 at 1:08 PM Maciej Pijanowski
 wrote:
>
>
> On 29.05.2019 09:39, Belisko Marek wrote:
> > Hi Dimitris,
> >
> > On Wed, May 29, 2019 at 9:03 AM Dimitris Tassopoulos  
> > wrote:
> >> Hi Marek,
> >>
> >> that's correct. I have a branch though which I've started to experiment 
> >> and add support for Mali. I didn't finished because I've tried to do this 
> >> by myself from the scratch and soon I've hit a wall. Nevertheless, I've 
> >> done the same for the rk3399 for nanopi-neo4 and during this process I've 
> >> learned a lot on how to do it with some help from other people from the 
> >> open source scene. The graphics stack was too complicated for me in the 
> >> beginning.
> > You can maybe look to meta-sunxi there is sunxi-mali driver +
> > libraries which will add support for that. When I've set that package
> > to PREFERRED_PROVIDER_virtual/gles2 I get issues with compilation
> > gtk3+ and others. I've spend 2 hours looking and trying yesterday but
> > without any success. Also pls look at this communication:
> > https://github.com/linux-sunxi/meta-sunxi/issues/144 (looks like we
> > can use opensource drivers + libs later). Thanks.
> What are you trying to achieve? Which kernel version are you using?
> Isn't the mali recipe in meta-sunxi quite dated already? Can it work
> with mainline kernel correctly?
I'm trying to make meta-sunxi in state where if you pull it and add to
your project it will at least build ;).
I juts jumped in to help a bit so please be patient with me ;).
Current state in meta-sunxi is that sunxi-mali is set as
PREFFERED_PROVIDED for various opengl technologies.
Also I'm not sure if it can wotj but anyway can be compiled (kernel
modules + userspace stuff).
Basically if you currently run on actual master core-image-sato you'll
get those kind of errors. I think there must be some mis-configuration
or so.
>
> I would suggest to try the recent blobs as described in this post:
> https://bootlin.com/blog/mali-opengl-support-on-allwinner-platforms-with-mainline-linux/
Yes this would be other option to use opensource stuff from bootlin or
one from oe (when it will be available)
>
> As I've written previously, I have been using the Wayland / Qt with
> good performance on H3 using the mainline kernel. Is it something you
> are looking for?
> You can take a look at my dirty branch - maybe this will be any help:
> https://github.com/3mdeb/meta-sunxi/tree/weston-with-kms/recipes-graphics/mali
OK thanks I'll try to take a look.
>
> Unfortunately, I had stopped working on that and presently do not have much
> time to clean up / get back to it. I can provide some support and / or get
> back to it if it seems valuable and there is some interest.
+1
> >> Therefore now that I feel much more confident with it I'm going to re-try 
> >> and finish with my branch. Armbian does have support, so I'll try to stick 
> >> to the Armbian backend for maintenance reasons.
> >>
> >> I hope that this will be rather easy, because the dri driver should 
> >> already be there, so the only thing I believe is needed is the blobs and 
> >> to create symlinks for the various so libs to that blob.
> >>
> >> Anyway, I'll try to do that also. In the meantime I will also wait a bit 
> >> to see if that merge between those two layers is possible and doable, 
> >> which will help to short the time and effort to do that.
> >>
> >> Regards,
> >> Dimitris
> > BR,
> >
> > marek
> >> Belisko Marek  schrieb am Mi., 29. Mai 2019, 
> >> 08:37:
> >>> Hi Dimitris,
> >>>
> >>> On Tue, May 28, 2019 at 1:07 PM Dimitris Tassopoulos  
> >>> wrote:
> >>>> Hi Enrico,
> >>>>
> >>>> I'm totally positive to any possibility for such integration. 
> >>>> Personally, that was the first thing I've tried to do before I start 
> >>>> this layer, but I've failed as it got really complex and the overhead 
> >>>> was too much after some point (at least for me). If you have look it's 
> >>>> actually a mix of meta-sunxi and armbian, but I had to remove or change 
> >>>> many stuff to fit the armbian in the layer.
> >>>>
> >>>> If you have time to have a look to my layer and you think that such kind 
> >>>> of integration is possible and can be done in a more easy way, then from 
> >>>> my side I'm all in.
> >>>> I believe that re-using the armbian patches is easier as it makes 
> >>>> maintenance much easi

Re: [yocto] meta-sunxi maintained?

[Belisko Marek]

Hi Dimitris,

On Wed, May 29, 2019 at 10:03 AM Dimitris Tassopoulos  wrote:
>
> Hi Marek,
>
> I see (and now remember) that there is a recipe for libgles for Mali400 and 
> A10/20.
> Are you interested for this architecture or newer (like H2, H3, H5) ?
>
> I can only make a wild guess that maybe because the driver is a bit old, then 
> if you
> try to build new recipes then there might be some issues.
>
> This also is the difference between the layers that I've mentioned before. 
> The meta-sunxi
> is clean and raw layer. Meaning that you get more flexibility to add/remove 
> things and
> also have a more generic layer. On the other hand, the other layer is not 
> really configurable
> and flexible in the same depth but it takes the full armbian distro and wraps 
> it. So, if the
> distro works, then the layer should work only with those components (of 
> course you can
> do modifications). That's the difference in the approach I meant in the 
> previous mail.
>
> I don't have any A10/20 hardware to test, but I could spin a build and look 
> at the errors you get.
> If you send my your local conf file and your environment setup and build 
> command I ca
> trigger a build and see if there's anything I can help with.
Thanks it will be really helpful. Basically I'm doing same as
described here:
https://github.com/linux-sunxi/meta-sunxi/issues/240#issuecomment-496410993
Looking at sunxi-mali more devices should be supported:
COMPATIBLE_MACHINE = "(sun4i|sun5i|sun7i|sun8i)"
>
> Regards,
> Dimitris

BR,

marek
>
> On Wed, May 29, 2019 at 9:39 AM Belisko Marek  wrote:
>>
>> Hi Dimitris,
>>
>> On Wed, May 29, 2019 at 9:03 AM Dimitris Tassopoulos  
>> wrote:
>> >
>> > Hi Marek,
>> >
>> > that's correct. I have a branch though which I've started to experiment 
>> > and add support for Mali. I didn't finished because I've tried to do this 
>> > by myself from the scratch and soon I've hit a wall. Nevertheless, I've 
>> > done the same for the rk3399 for nanopi-neo4 and during this process I've 
>> > learned a lot on how to do it with some help from other people from the 
>> > open source scene. The graphics stack was too complicated for me in the 
>> > beginning.
>> You can maybe look to meta-sunxi there is sunxi-mali driver +
>> libraries which will add support for that. When I've set that package
>> to PREFERRED_PROVIDER_virtual/gles2 I get issues with compilation
>> gtk3+ and others. I've spend 2 hours looking and trying yesterday but
>> without any success. Also pls look at this communication:
>> https://github.com/linux-sunxi/meta-sunxi/issues/144 (looks like we
>> can use opensource drivers + libs later). Thanks.
>> >
>> > Therefore now that I feel much more confident with it I'm going to re-try 
>> > and finish with my branch. Armbian does have support, so I'll try to stick 
>> > to the Armbian backend for maintenance reasons.
>> >
>> > I hope that this will be rather easy, because the dri driver should 
>> > already be there, so the only thing I believe is needed is the blobs and 
>> > to create symlinks for the various so libs to that blob.
>> >
>> > Anyway, I'll try to do that also. In the meantime I will also wait a bit 
>> > to see if that merge between those two layers is possible and doable, 
>> > which will help to short the time and effort to do that.
>> >
>> > Regards,
>> > Dimitris
>>
>> BR,
>>
>> marek
>> >
>> > Belisko Marek  schrieb am Mi., 29. Mai 2019, 
>> > 08:37:
>> >>
>> >> Hi Dimitris,
>> >>
>> >> On Tue, May 28, 2019 at 1:07 PM Dimitris Tassopoulos  
>> >> wrote:
>> >> >
>> >> > Hi Enrico,
>> >> >
>> >> > I'm totally positive to any possibility for such integration. 
>> >> > Personally, that was the first thing I've tried to do before I start 
>> >> > this layer, but I've failed as it got really complex and the overhead 
>> >> > was too much after some point (at least for me). If you have look it's 
>> >> > actually a mix of meta-sunxi and armbian, but I had to remove or change 
>> >> > many stuff to fit the armbian in the layer.
>> >> >
>> >> > If you have time to have a look to my layer and you think that such 
>> >> > kind of integration is possible and can be done in a more easy way, 
>> >> > then from my side I'm all in.
>> >> > I 

Re: [yocto] meta-sunxi maintained?

[Belisko Marek]

Hi Dimitris,

On Wed, May 29, 2019 at 9:03 AM Dimitris Tassopoulos  wrote:
>
> Hi Marek,
>
> that's correct. I have a branch though which I've started to experiment and 
> add support for Mali. I didn't finished because I've tried to do this by 
> myself from the scratch and soon I've hit a wall. Nevertheless, I've done the 
> same for the rk3399 for nanopi-neo4 and during this process I've learned a 
> lot on how to do it with some help from other people from the open source 
> scene. The graphics stack was too complicated for me in the beginning.
You can maybe look to meta-sunxi there is sunxi-mali driver +
libraries which will add support for that. When I've set that package
to PREFERRED_PROVIDER_virtual/gles2 I get issues with compilation
gtk3+ and others. I've spend 2 hours looking and trying yesterday but
without any success. Also pls look at this communication:
https://github.com/linux-sunxi/meta-sunxi/issues/144 (looks like we
can use opensource drivers + libs later). Thanks.
>
> Therefore now that I feel much more confident with it I'm going to re-try and 
> finish with my branch. Armbian does have support, so I'll try to stick to the 
> Armbian backend for maintenance reasons.
>
> I hope that this will be rather easy, because the dri driver should already 
> be there, so the only thing I believe is needed is the blobs and to create 
> symlinks for the various so libs to that blob.
>
> Anyway, I'll try to do that also. In the meantime I will also wait a bit to 
> see if that merge between those two layers is possible and doable, which will 
> help to short the time and effort to do that.
>
> Regards,
> Dimitris

BR,

marek
>
> Belisko Marek  schrieb am Mi., 29. Mai 2019, 08:37:
>>
>> Hi Dimitris,
>>
>> On Tue, May 28, 2019 at 1:07 PM Dimitris Tassopoulos  
>> wrote:
>> >
>> > Hi Enrico,
>> >
>> > I'm totally positive to any possibility for such integration. Personally, 
>> > that was the first thing I've tried to do before I start this layer, but 
>> > I've failed as it got really complex and the overhead was too much after 
>> > some point (at least for me). If you have look it's actually a mix of 
>> > meta-sunxi and armbian, but I had to remove or change many stuff to fit 
>> > the armbian in the layer.
>> >
>> > If you have time to have a look to my layer and you think that such kind 
>> > of integration is possible and can be done in a more easy way, then from 
>> > my side I'm all in.
>> > I believe that re-using the armbian patches is easier as it makes 
>> > maintenance much easier, there are more supported SBCs and also there is 
>> > much more testing involved in armbian and frequent updates fix those bugs.
>> I did check your layer and it seems that you're not using sunxi-mali
>> for opengl HW acceleration only mesa so SW rendering? Thanks.
>> >
>> > Please consider it and I can help as much as I can and my time allows for 
>> > that integration.
>> >
>> > Regards,
>> > Dimitris
>> >
>> >
>> Marek
>> >
>> > On Tue, May 28, 2019 at 12:56 PM Enrico  
>> > wrote:
>> >>
>> >> On Tue, May 28, 2019 at 12:06 PM Dimitris Tassopoulos  
>> >> wrote:
>> >> >
>> >> > >
>> >> > > I was thinking about this also, too. The only reason is that in 
>> >> > > meta-sunxi they do a great job and they keep their layer clean, which 
>> >> > > is great I think. The other layers are just based on the armbian 
>> >> > > distro, which is a lot different, but for me it was much easier to 
>> >> > > integrate their patches, patching scripts and bootloader scripts to a 
>> >> > > Yocto layer. That way the only thing I do is that from time to time I 
>> >> > > just integrate their new patches and that's it. There's no 
>> >> > > development in the layer is just re-use of the armbian work and a 
>> >> > > wrapper around it. Therefore, it's hard, even no doable to put those 
>> >> > > different architectures together. But definitely that decision also 
>> >> > > bothered me a lot before I create the layer and I also don't like 
>> >> > > time to be spend on the same thing from different people. 
>> >> > > Nevertheless, from my point of view I couldn't find a way to put 
>> >> > > those things together. I've tried but I couldn't do it.
>> >> > >
>> >> > > Therefore, it was easier for me to do it the way I'v

Re: [yocto] meta-sunxi maintained?

[Belisko Marek]

Hi Dimitris,

On Tue, May 28, 2019 at 1:07 PM Dimitris Tassopoulos  wrote:
>
> Hi Enrico,
>
> I'm totally positive to any possibility for such integration. Personally, 
> that was the first thing I've tried to do before I start this layer, but I've 
> failed as it got really complex and the overhead was too much after some 
> point (at least for me). If you have look it's actually a mix of meta-sunxi 
> and armbian, but I had to remove or change many stuff to fit the armbian in 
> the layer.
>
> If you have time to have a look to my layer and you think that such kind of 
> integration is possible and can be done in a more easy way, then from my side 
> I'm all in.
> I believe that re-using the armbian patches is easier as it makes maintenance 
> much easier, there are more supported SBCs and also there is much more 
> testing involved in armbian and frequent updates fix those bugs.
I did check your layer and it seems that you're not using sunxi-mali
for opengl HW acceleration only mesa so SW rendering? Thanks.
>
> Please consider it and I can help as much as I can and my time allows for 
> that integration.
>
> Regards,
> Dimitris
>
>
Marek
>
> On Tue, May 28, 2019 at 12:56 PM Enrico  wrote:
>>
>> On Tue, May 28, 2019 at 12:06 PM Dimitris Tassopoulos  
>> wrote:
>> >
>> > >
>> > > I was thinking about this also, too. The only reason is that in 
>> > > meta-sunxi they do a great job and they keep their layer clean, which is 
>> > > great I think. The other layers are just based on the armbian distro, 
>> > > which is a lot different, but for me it was much easier to integrate 
>> > > their patches, patching scripts and bootloader scripts to a Yocto layer. 
>> > > That way the only thing I do is that from time to time I just integrate 
>> > > their new patches and that's it. There's no development in the layer is 
>> > > just re-use of the armbian work and a wrapper around it. Therefore, it's 
>> > > hard, even no doable to put those different architectures together. But 
>> > > definitely that decision also bothered me a lot before I create the 
>> > > layer and I also don't like time to be spend on the same thing from 
>> > > different people. Nevertheless, from my point of view I couldn't find a 
>> > > way to put those things together. I've tried but I couldn't do it.
>> > >
>> > > Therefore, it was easier for me to do it the way I've done it. And after 
>> > > all, although it doesn't seem right, at the same time this is the beauty 
>> > > of the open source. I think the layers are just incompatible in the way 
>> > > that they are do things. Also it's not bad to have alternatives.
>> > >
>> > > Sunxi is a great community and I believe many of the armbian patches are 
>> > > coming from there. Others not. Of course, having them all together would 
>> > > be nice. But I don't think that it's possible because of the different 
>> > > approach.
>>
>> It would be great to integrate all those different layers in
>> meta-sunxi,the main problem is that usually they come with their own
>> bootloader/kernel/etc so you have to *maintain* all these
>> different configurations.
>> Infact in the past i refused to do such things because i didn't have
>> the time to maintain all those different versions, it was just easier
>> to support what was already in mainline uboot/kernel.
>>
>> But of course if someone wants to do it then it's welcome, the worst
>> thing that can happen is that once an arch gets unmaintained it will
>> be removed.
>>
>> One thing that can be done anyway is to have those external layers
>> linked in the readme, so at least people will know they exist.
>>
>> Enrico
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] meta-sunxi maintained?

[Belisko Marek]

Hi Dimitris,

On Tue, May 28, 2019 at 12:06 PM Dimitris Tassopoulos  wrote:
>
> Hi Belisko,
>
> I was thinking about this also, too. The only reason is that in meta-sunxi 
> they do a great job and they keep their layer clean, which is great I think. 
> The other layers are just based on the armbian distro, which is a lot 
> different, but for me it was much easier to integrate their patches, patching 
> scripts and bootloader scripts to a Yocto layer. That way the only thing I do 
> is that from time to time I just integrate their new patches and that's it. 
> There's no development in the layer is just re-use of the armbian work and a 
> wrapper around it. Therefore, it's hard, even no doable to put those 
> different architectures together. But definitely that decision also bothered 
> me a lot before I create the layer and I also don't like time to be spend on 
> the same thing from different people. Nevertheless, from my point of view I 
> couldn't find a way to put those things together. I've tried but I couldn't 
> do it.
>
> Therefore, it was easier for me to do it the way I've done it. And after all, 
> although it doesn't seem right, at the same time this is the beauty of the 
> open source. I think the layers are just incompatible in the way that they 
> are do things. Also it's not bad to have alternatives.
>
> Sunxi is a great community and I believe many of the armbian patches are 
> coming from there. Others not. Of course, having them all together would be 
> nice. But I don't think that it's possible because of the different approach.
>
> I hope this explains your question and even more that explains that was not a 
> decision to divide things or create more hassle for the same chips.
Yes certainly. Thanks for great explanation and sorry if I wrote it in
not polite way I didn't mean to offence ;). Thanks.
>
> Regards,
> Dimitris
>
> Belisko Marek  schrieb am Di., 28. Mai 2019, 11:49:
>>
>> Hi Dimitris,
>>
>> On Tue, May 28, 2019 at 11:01 AM Dimitris Tassopoulos  
>> wrote:
>> >
>> > Hi Belisko,
>> >
>> > you can also have a look in to this layer: 
>> > http://layers.openembedded.org/layerindex/branch/master/layer/meta-allwinner-hx/
>> > It's for allwinner H2,H3 and H5 boards that already have support on 
>> > Armbian.
>> > Pretty much is just a Yocto layer with all the patches and BSP support 
>> > from Armbian.
>> > It supports 4.14 and 4.19 mainline kernels only and also the PREEMPT-RT 
>> > patches.
>> > Warrior support was added recently, too.
>> OK thanks. I think I'll stick with meta-sunxi ;). What about join
>> forces and maintains one layer properly instead having it separated?
>> >
>> > A similar one is also this: 
>> > http://layers.openembedded.org/layerindex/branch/master/layer/meta-nanopi-neo4/
>> >
>> > Dimitris
>> >
>> > On Mon, May 27, 2019 at 7:33 PM Belisko Marek  
>> > wrote:
>> >>
>> >> Hi Enrico,
>> >>
>> >> On Mon, May 27, 2019 at 5:44 PM Enrico  
>> >> wrote:
>> >> >
>> >> > Hi,
>> >> >
>> >> > i try to keep it maintained, but now i just have a lime2 for testing
>> >> > on real hardware, and i don't have the resources to do test builds for
>> >> > all the supported boards.
>> >> > Your help would be welcome, i can't check right now if i have the
>> >> > rights to add you as co-maintainer, anyway i will add you.
>> >> Thanks I have few sunxi based boards so can do tests also on my setup.
>> >> Pls ping me when you will add me. Thanks.
>> >> >
>> >> > Thanks for the help!
>> >> >
>> >> > Enrico
>> >>
>> >> Marek
>> >> >
>> >> > On Mon, May 27, 2019 at 4:50 PM Belisko Marek  
>> >> > wrote:
>> >> > >
>> >> > > Hello,
>> >> > >
>> >> > > I'm just curious if meta-sunxi is still maintained? I was contributed
>> >> > > to layer back while and when look now thud branch is un-compilable
>> >> > > (dri2proto not replaced) and warrior branch not created yet. There is
>> >> > > 14 issues + 6 pending pull requests. Added maintainers also in CC. I
>> >> > > think it would be good to have sunxi properly maintained as boards
>> >> > > with sunxi processors are popular. I can give a hand as co-maintainer
>> >> > > if necessary. Thanks a lot.
>> >> > >
>> >> > > BR,
>> >> > >
>> >> > > marek
>> >> > >
>> >> > > --
>> >> > > as simple and primitive as possible
>> >> > > -
>> >> > > Marek Belisko - OPEN-NANDRA
>> >> > > Freelance Developer
>> >> > >
>> >> > > Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
>> >> > > Tel: +421 915 052 184
>> >> > > skype: marekwhite
>> >> > > twitter: #opennandra
>> >> > > web: http://open-nandra.com
>> >> --
>> >> ___
>> >> yocto mailing list
>> >> yocto@yoctoproject.org
>> >> https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>>
>> marek

BR,

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

Re: [yocto] meta-sunxi maintained?

[Belisko Marek]

Hi Maciej,


On Tue, May 28, 2019 at 11:48 AM Maciej Pijanowski
 wrote:
>
>
> On 27.05.2019 19:32, Belisko Marek wrote:
> > Hi Enrico,
> Hi,
> >
> > On Mon, May 27, 2019 at 5:44 PM Enrico  
> > wrote:
> >> Hi,
> >>
> >> i try to keep it maintained, but now i just have a lime2 for testing
> >> on real hardware, and i don't have the resources to do test builds for
> >> all the supported boards.
> >> Your help would be welcome, i can't check right now if i have the
> >> rights to add you as co-maintainer, anyway i will add you.
> > Thanks I have few sunxi based boards so can do tests also on my setup.
> > Pls ping me when you will add me. Thanks.
> >> Thanks for the help!
> >>
> >> Enrico
> > Marek
> >> On Mon, May 27, 2019 at 4:50 PM Belisko Marek  
> >> wrote:
> >>> Hello,
> >>>
> >>> I'm just curious if meta-sunxi is still maintained? I was contributed
> >>> to layer back while and when look now thud branch is un-compilable
> >>> (dri2proto not replaced) and warrior branch not created yet. There is
> >>> 14 issues + 6 pending pull requests. Added maintainers also in CC. I
> >>> think it would be good to have sunxi properly maintained as boards
> >>> with sunxi processors are popular. I can give a hand as co-maintainer
> >>> if necessary. Thanks a lot.
> I think I have some of the dirty code for integration of the recent Mali
> blobs
> with the mainline kernel as described here:
> https://bootlin.com/blog/more-opengl-binaries-for-the-mali-support-on-allwinner-platforms-with-mainline-linux/
> We were testing Qt + Wayland on mainline Linux IIRC.
> Let me know if you think this could be beneficial to the community.
> We are not actively using at the moment, though. meta-sunxi was not that
> active when we worked on
> that so maybe we were not motivated enough to polish things up and
> submit a PR.
Sure. Pls submit PR. Have you seen recent discussion:
https://github.com/linux-sunxi/meta-sunxi/issues/144#issuecomment-496408159
?
Does your work use the same components or? Thanks.
>
> We use orange-pi-zero as a base for our product we use for on-hardware
> validation:
> https://3mdeb.com/products/open-source-hardware/rte/ so I believe we can
> help
> with maintenance of this platform / SoC (we use meta-sunxi for building
> images for it:
> https://github.com/3mdeb/meta-rte).
> We have quite a number of other Allwinner platforms as well (H3 and A20
> mostly).
That would be cool. I plan to spend some time on co-maintaining
meta-sunxi so I hope feedback and merging will be much smoother ;)
>
> >>>
> >>> BR,
> >>>
> >>> marek
> >>>
> >>> --
> >>> as simple and primitive as possible
> >>> -
> >>> Marek Belisko - OPEN-NANDRA
> >>> Freelance Developer
> >>>
> >>> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
> >>> Tel: +421 915 052 184
> >>> skype: marekwhite
> >>> twitter: #opennandra
> >>> web: http://open-nandra.com
>
> --
> Maciej Pijanowski
> Embedded Systems Engineer
> https://3mdeb.com | @3mdeb_com
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

BR,

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

Re: [yocto] meta-sunxi maintained?

[Belisko Marek]

Hi Dimitris,

On Tue, May 28, 2019 at 11:01 AM Dimitris Tassopoulos  wrote:
>
> Hi Belisko,
>
> you can also have a look in to this layer: 
> http://layers.openembedded.org/layerindex/branch/master/layer/meta-allwinner-hx/
> It's for allwinner H2,H3 and H5 boards that already have support on Armbian.
> Pretty much is just a Yocto layer with all the patches and BSP support from 
> Armbian.
> It supports 4.14 and 4.19 mainline kernels only and also the PREEMPT-RT 
> patches.
> Warrior support was added recently, too.
OK thanks. I think I'll stick with meta-sunxi ;). What about join
forces and maintains one layer properly instead having it separated?
>
> A similar one is also this: 
> http://layers.openembedded.org/layerindex/branch/master/layer/meta-nanopi-neo4/
>
> Dimitris
>
> On Mon, May 27, 2019 at 7:33 PM Belisko Marek  wrote:
>>
>> Hi Enrico,
>>
>> On Mon, May 27, 2019 at 5:44 PM Enrico  wrote:
>> >
>> > Hi,
>> >
>> > i try to keep it maintained, but now i just have a lime2 for testing
>> > on real hardware, and i don't have the resources to do test builds for
>> > all the supported boards.
>> > Your help would be welcome, i can't check right now if i have the
>> > rights to add you as co-maintainer, anyway i will add you.
>> Thanks I have few sunxi based boards so can do tests also on my setup.
>> Pls ping me when you will add me. Thanks.
>> >
>> > Thanks for the help!
>> >
>> > Enrico
>>
>> Marek
>> >
>> > On Mon, May 27, 2019 at 4:50 PM Belisko Marek  
>> > wrote:
>> > >
>> > > Hello,
>> > >
>> > > I'm just curious if meta-sunxi is still maintained? I was contributed
>> > > to layer back while and when look now thud branch is un-compilable
>> > > (dri2proto not replaced) and warrior branch not created yet. There is
>> > > 14 issues + 6 pending pull requests. Added maintainers also in CC. I
>> > > think it would be good to have sunxi properly maintained as boards
>> > > with sunxi processors are popular. I can give a hand as co-maintainer
>> > > if necessary. Thanks a lot.
>> > >
>> > > BR,
>> > >
>> > > marek
>> > >
>> > > --
>> > > as simple and primitive as possible
>> > > -
>> > > Marek Belisko - OPEN-NANDRA
>> > > Freelance Developer
>> > >
>> > > Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
>> > > Tel: +421 915 052 184
>> > > skype: marekwhite
>> > > twitter: #opennandra
>> > > web: http://open-nandra.com
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto



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

[yocto] gstreamer1.0-plugins-base meta-sunxi issue with custom virtual/egl or virtual/libgles2 on thud

[Belisko Marek]

Hi,

I'm trying to compile image using libnice which have dependency on
gstreamer. Everything went fine but I get QA issues for plugins-base
like:

ERROR: gstreamer1.0-plugins-base-1.14.4-r0 do_package_qa: QA Issue:
/usr/lib/libgstgl-1.0.so.0.1404.0 contained in package libgstgl-1.0
requires libGLESv2.so, but no providers found in
RDEPENDS_libgstgl-1.0? [file-rdeps]
ERROR: gstreamer1.0-plugins-base-1.14.4-r0 do_package_qa: QA Issue:
/usr/lib/libgstgl-1.0.so.0.1404.0 contained in package libgstgl-1.0
requires libEGL.so, but no providers found in RDEPENDS_libgstgl-1.0?
[file-rdeps]
ERROR: gstreamer1.0-plugins-base-1.14.4-r0 do_package_qa: QA Issue:
/usr/lib/gstreamer-1.0/libgstopengl.so contained in package
gstreamer1.0-plugins-base-opengl requires libGLESv2.so, but no
providers found in RDEPENDS_gstreamer1.0-plugins-base-opengl?
[file-rdeps]
ERROR: gstreamer1.0-plugins-base-1.14.4-r0 do_package_qa: QA Issue:
/usr/lib/gstreamer-1.0/libgstopengl.so contained in package
gstreamer1.0-plugins-base-opengl requires libEGL.so, but no providers
found in RDEPENDS_gstreamer1.0-plugins-base-opengl? [file-rdeps]
ERROR: gstreamer1.0-plugins-base-1.14.4-r0 do_package_qa: QA run found
fatal errors. Please consider fixing them.
ERROR: gstreamer1.0-plugins-base-1.14.4-r0 do_package_qa: Function
failed: do_package_qa

meta-sunxi is using custom recipe which provide virtual/egl
virtual/libgles2 see:
https://github.com/linux-sunxi/meta-sunxi/blob/master/recipes-graphics/libgles/sunxi-mali_git.bb

also in configuration there is:
PREFERRED_PROVIDER_virtual/mesa ?= "mesa-gl"
PREFERRED_PROVIDER_virtual/libgl ?= "mesa-gl"
PREFERRED_PROVIDER_virtual/libgles1 ?= "sunxi-mali"
PREFERRED_PROVIDER_virtual/libgles2 ?= "sunxi-mali"
PREFERRED_PROVIDER_virtual/egl ?= "sunxi-mali"
XSERVER += "sunxi-mali \
sunxi-mali-dev"
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "\
kernel-module-mali \
kernel-module-mali-drm \
"

which is fine. I was able to workaround this issue by adding bbappend
for plugins base with content:
RDEPENDS_libgstgl-1.0 += "sunxi-mali"
RDEPENDS_${PN}-opengl += "sunxi-mali"

and add RPROVIDES_${PN} = "libGLESv1_CM.so libGLESv2.so libEGL.so" to
sunxi-mali.bb recipe.

Above workaround is not nice because if someone update
PREFERRED_PROVIDER then gstreamer will be broken. Any ideas how to fix
properly this QA issue? Thanks.

BR,

marek


-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] meta-sunxi maintained?

[Belisko Marek]

Hi Enrico,

On Mon, May 27, 2019 at 5:44 PM Enrico  wrote:
>
> Hi,
>
> i try to keep it maintained, but now i just have a lime2 for testing
> on real hardware, and i don't have the resources to do test builds for
> all the supported boards.
> Your help would be welcome, i can't check right now if i have the
> rights to add you as co-maintainer, anyway i will add you.
Thanks I have few sunxi based boards so can do tests also on my setup.
Pls ping me when you will add me. Thanks.
>
> Thanks for the help!
>
> Enrico

Marek
>
> On Mon, May 27, 2019 at 4:50 PM Belisko Marek  wrote:
> >
> > Hello,
> >
> > I'm just curious if meta-sunxi is still maintained? I was contributed
> > to layer back while and when look now thud branch is un-compilable
> > (dri2proto not replaced) and warrior branch not created yet. There is
> > 14 issues + 6 pending pull requests. Added maintainers also in CC. I
> > think it would be good to have sunxi properly maintained as boards
> > with sunxi processors are popular. I can give a hand as co-maintainer
> > if necessary. Thanks a lot.
> >
> > BR,
> >
> > marek
> >
> > --
> > as simple and primitive as possible
> > -
> > Marek Belisko - OPEN-NANDRA
> > Freelance Developer
> >
> > Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
> > Tel: +421 915 052 184
> > skype: marekwhite
> > twitter: #opennandra
> > web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] meta-sunxi maintained?

[Belisko Marek]

Hello,

I'm just curious if meta-sunxi is still maintained? I was contributed
to layer back while and when look now thud branch is un-compilable
(dri2proto not replaced) and warrior branch not created yet. There is
14 issues + 6 pending pull requests. Added maintainers also in CC. I
think it would be good to have sunxi properly maintained as boards
with sunxi processors are popular. I can give a hand as co-maintainer
if necessary. Thanks a lot.

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [Yocto] RPI WiFi not loading module

[Belisko Marek]

Hi,

On Thu, May 23, 2019 at 11:15 AM Jonas Andersson
 wrote:
>
> Hi
>
> I have problem to get my WiFi working on boot on Raspberry Pi 3.
for rpi issues I would suggest to open ticket on meta-raspberrypi
github with stated which yocto branch and other details. Thanks.
>
> The problem is that wlan0 interface not showing up, if I manually run 
> modprobe brcmfmac it works.
>
> To try to "force" the load of brcmfmac i added it to KERNEL_MODULE_AUTOLOAD 
> and that generated an file in /etc/modules-load.d/ -> brcmfmac.conf but it is 
> still not loaded.
>
> I use systemd an to my understanding systemd-modules-load.service is handling 
> module auto load, but that file is missing and I cant see how to include it 
> in my build.
>
> Building thud version and I have added the following to my image recipe:
>
> DISTRO_FEATURES_append = " wifi"
>
> IMAGE_INSTALL_append = " iw wpa-supplicant packagegroup-base 
> module-init-tools"
>
> IMAGE_INSTALL_append = "\
> linux-firmware-rpidistro-bcm43430 \
> linux-firmware-rpidistro-bcm43455 \
> bluez-firmware-rpidistro-bcm43430a1-hcd \
> bluez-firmware-rpidistro-bcm4345c0-hcd \
>  "
> Then i have symlinked wpa-supplicant service to load wpa-supplicant.conf file 
> and that work when I manually loads the module.
>
> Best regards
> Jonas
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

BR,

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

Re: [yocto] setting SRC_URI runtime - possible options

[Belisko Marek]

On Wed, May 22, 2019 at 9:50 AM Paul Barker  wrote:

> On Tue, 21 May 2019, at 11:23, Belisko Marek wrote:
> > On Tue, May 21, 2019 at 12:14 PM Alexander Kanavin
> >  wrote:
> > > You can write a class which sets the template for SRC_URI and then a
> > >  series of recipes that inherit the class, and define the variable that
> > >  would turn the template into the actual URI.
> > OK I think it make sense. So parsing of config file will be done in
> > class and then class will be used in recipes to set correct SRU_URI.
> > Do you have any idea what is wrong with actual code I posted? Why it is
> > doing some strange things? Thanks.
>
> You're setting the SRC_URI value only in the do_fetch task. It's needed in
> at least the do_unpack task as well and possibly other tasks.
>
> You could look at setting this in an anonymous python function instead if
> you really need to parse a config file.
>
Yes I was using anonymous python function before but  then when project was
unpacked the SRCPV + SRCREV was somehow not updated.
I'll try to look more on it and debug. Thanks.

>
> --
> Paul Barker
> Managing Director & Principal Engineer
> Beta Five Ltd
>

BR,

marek
-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] setting SRC_URI runtime - possible options

[Belisko Marek]

On Tue, May 21, 2019 at 12:14 PM Alexander Kanavin 
wrote:

> You can write a class which sets the template for SRC_URI and then a
> series of recipes that inherit the class, and define the variable that
> would turn the template into the actual URI.
>
OK I think it make sense. So parsing of config file will be done in class
and then class will be used in recipes to set correct SRU_URI.
Do you have any idea what is wrong with actual code I posted? Why it is
doing some strange things? Thanks.

>
> Alex
>
> On Tue, 21 May 2019 at 12:10, Belisko Marek 
> wrote:
> >
> > Hi,
> >
> > On Tue, May 21, 2019 at 12:00 PM Alexander Kanavin <
> alex.kana...@gmail.com> wrote:
> >>
> >> If you provide some context for why you want this, we might be able to
> >> suggest a different way.
> >
> > Customer wants to have kind of base-os (build in yocto) and then on top
> of that different flavor python application which should be fetch and added
> during build based on configuration file. This is only need. Thanks.
> >>
> >>
> >> Alex
> >>
> >> On Tue, 21 May 2019 at 08:11, Belisko Marek 
> wrote:
> >> >
> >> > Hi,
> >> >
> >> > I have special need to fetch repo which is defined in config file in
> form (repo and branch):
> >> > g...@testrepo.com/myrepo mysuperbranch
> >> >
> >> > Config file is placed in recipe directory. I've tried to add some
> bits and pieces but it seems it's not doing right. Snippet from recipe:
> >> >
> >> > LICENSE = "CLOSED"
> >> >
> >> > SRCREV = "${AUTOREV}"
> >> > PV = "${SRCPV}"
> >> >
> >> > do_fetch_prepend () {
> >> >
> >> > src_uri = d.getVar('SRC_URI')
> >> >
> >> > p = d.getVar("FILE")
> >> > idx = p.rfind("/")
> >> > p = p[:idx]
> >> > p += "/config.txt"
> >> >
> >> > with open(p) as f:
> >> > read_data = f.readline().strip().split(" ")
> >> > d.setVar('SRC_URI', read_data[0])
> >> > }
> >> >
> >> > SRC_URI = ""
> >> >
> >> > S = "${WORKDIR}/git"
> >> >
> >> > It looks like that repo is fetched but unpack doesn't put git
> directory in $WORKDIR and in build directory I get strange directories like:
> >> >
> >> > !=
> >> > bitbake-cookerdaemon.log
> >> > cache
> >> > conf
> >> > ${@d.getVar('S')
> >> > else
> >> > if
> >> > os.path.join('
> >> > os.path.normpath(d.getVar('S'))
> >> > os.path.normpath(d.getVar('WORKDIR'))
> >> > 'patches')}
> >> > tmp
> >> >
> >> > so there is obviously I'm doing something wrong :). My question is if
> this is the way or should I stick to some variables set in local.conf and
> then use it in recipe? Thanks a lot for any pointers.
> >> >
> >> > BR,
> >> >
> >> > marek
> >> > --
> >> > as simple and primitive as possible
> >> > -
> >> > Marek Belisko - OPEN-NANDRA
> >> > Freelance Developer
> >> >
> >> > Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
> >> > Tel: +421 915 052 184
> >> > skype: marekwhite
> >> > twitter: #opennandra
> >> > web: http://open-nandra.com
> >> > --
> >> > ___
> >> > yocto mailing list
> >> > yocto@yoctoproject.org
> >> > https://lists.yoctoproject.org/listinfo/yocto
> >
> >
> >
> > marek
>


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

Re: [yocto] setting SRC_URI runtime - possible options

[Belisko Marek]

Hi,

On Tue, May 21, 2019 at 12:00 PM Alexander Kanavin 
wrote:

> If you provide some context for why you want this, we might be able to
> suggest a different way.
>
Customer wants to have kind of base-os (build in yocto) and then on top of
that different flavor python application which should be fetch and added
during build based on configuration file. This is only need. Thanks.

>
> Alex
>
> On Tue, 21 May 2019 at 08:11, Belisko Marek 
> wrote:
> >
> > Hi,
> >
> > I have special need to fetch repo which is defined in config file in
> form (repo and branch):
> > g...@testrepo.com/myrepo mysuperbranch
> >
> > Config file is placed in recipe directory. I've tried to add some bits
> and pieces but it seems it's not doing right. Snippet from recipe:
> >
> > LICENSE = "CLOSED"
> >
> > SRCREV = "${AUTOREV}"
> > PV = "${SRCPV}"
> >
> > do_fetch_prepend () {
> >
> > src_uri = d.getVar('SRC_URI')
> >
> > p = d.getVar("FILE")
> > idx = p.rfind("/")
> > p = p[:idx]
> > p += "/config.txt"
> >
> > with open(p) as f:
> > read_data = f.readline().strip().split(" ")
> > d.setVar('SRC_URI', read_data[0])
> > }
> >
> > SRC_URI = ""
> >
> > S = "${WORKDIR}/git"
> >
> > It looks like that repo is fetched but unpack doesn't put git directory
> in $WORKDIR and in build directory I get strange directories like:
> >
> > !=
> > bitbake-cookerdaemon.log
> > cache
> > conf
> > ${@d.getVar('S')
> > else
> > if
> > os.path.join('
> > os.path.normpath(d.getVar('S'))
> > os.path.normpath(d.getVar('WORKDIR'))
> > 'patches')}
> > tmp
> >
> > so there is obviously I'm doing something wrong :). My question is if
> this is the way or should I stick to some variables set in local.conf and
> then use it in recipe? Thanks a lot for any pointers.
> >
> > BR,
> >
> > marek
> > --
> > as simple and primitive as possible
> > -
> > Marek Belisko - OPEN-NANDRA
> > Freelance Developer
> >
> > Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
> > Tel: +421 915 052 184
> > skype: marekwhite
> > twitter: #opennandra
> > web: http://open-nandra.com
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
>


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

[yocto] setting SRC_URI runtime - possible options

[Belisko Marek]

Hi,

I have special need to fetch repo which is defined in config file in form
(repo and branch):
g...@testrepo.com/myrepo mysuperbranch

Config file is placed in recipe directory. I've tried to add some bits and
pieces but it seems it's not doing right. Snippet from recipe:

LICENSE = "CLOSED"

SRCREV = "${AUTOREV}"
PV = "${SRCPV}"

do_fetch_prepend () {

src_uri = d.getVar('SRC_URI')

p = d.getVar("FILE")
idx = p.rfind("/")
p = p[:idx]
p += "/config.txt"

with open(p) as f:
read_data = f.readline().strip().split(" ")
d.setVar('SRC_URI', read_data[0])
}

SRC_URI = ""

S = "${WORKDIR}/git"

It looks like that repo is fetched but unpack doesn't put git directory in
$WORKDIR and in build directory I get strange directories like:

!=
bitbake-cookerdaemon.log
cache
conf
${@d.getVar('S')
else
if
os.path.join('
os.path.normpath(d.getVar('S'))
os.path.normpath(d.getVar('WORKDIR'))
'patches')}
tmp

so there is obviously I'm doing something wrong :). My question is if this
is the way or should I stick to some variables set in local.conf and then
use it in recipe? Thanks a lot for any pointers.

BR,

marek
-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] wic cp doesn't work with ext4 partition

[Belisko Marek]

On Wed, May 15, 2019 at 1:47 PM Belisko Marek 
wrote:

> Hi,
>
> I'm trying to update some artifact after image is build using wic tool.
> I've tried wic rm image.wic:2/boot/uImage and this works fine (verified
> with wic ls). While when I want to copy something to ext4 partition (I've
> tried to copy to vfat boot partition and it works fine) like:
> wic cp uImage_modified image.wic:2/boot and verify with wic ls file is not
> copied. Anything I'm missing here? Thanks.
>
Hmm seems that if I remove file first then it works fine. No idea why it
works with vfat though.

>
> BR,
>
> marek
>
> --
> as simple and primitive as possible
> -
> Marek Belisko - OPEN-NANDRA
> Freelance Developer
>
> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
> Tel: +421 915 052 184
> skype: marekwhite
> twitter: #opennandra
> web: http://open-nandra.com
>

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

[yocto] wic cp doesn't work with ext4 partition

[Belisko Marek]

Hi,

I'm trying to update some artifact after image is build using wic tool.
I've tried wic rm image.wic:2/boot/uImage and this works fine (verified
with wic ls). While when I want to copy something to ext4 partition (I've
tried to copy to vfat boot partition and it works fine) like:
wic cp uImage_modified image.wic:2/boot and verify with wic ls file is not
copied. Anything I'm missing here? Thanks.

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] xloadimage recipe

[Belisko Marek]

Hello,

I was trying to write recipe for xloadimage (yes this SW is from 1993) and
have some "custom" configuration step required. I already put some effort
into that without success. Just curious: does anybody have recipe for that
package to share? Thanks a lot.

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-java] Illegal instruction (core dumped) when compiling jaxp1.3-native-1.4.01-r0

[Belisko Marek]

Hi,

looks like when use this proposal [0] it start working (juts need to update
multiple recipes which calls javac in configure phase with -Xnoinlining).
Compiletime disable inlining doesn't work.

It thee some pending fix for that? When use host gcc 5.5 (from ubuntu
16.04) all works good (while not with gcc 7.3).

[0] - https://sourceforge.net/p/jamvm/mailman/message/25051239/

On Mon, Feb 25, 2019 at 9:53 PM Belisko Marek 
wrote:

> Hi,
>
> I'm using meta-java sumo branch and on ubuntu 18.04 I have this issue
> (building for beaglebone-yocto machine):
> ERROR: jaxp1.3-native-1.4.01-r0 do_compile: Function failed: do_compile
> (log file is located at
> /home/jenkins/my_build/tmp/work/x86_64-linux/jaxp1.3-native/1.4.01-r0/temp/log.do_compile.15390)
> ERROR: Logfile of failure stored in:
> /home/jenkins/my_build/tmp/work/x86_64-linux/jaxp1.3-native/1.4.01-r0/temp/log.do_compile.15390
> Log data follows:
> | DEBUG: Executing shell function do_compile
> | Illegal instruction (core dumped)
> | WARNING: exit code 132 from a shell command.
> | ERROR: Function failed: do_compile (log file is located at
> /home/jenkins/my_build/tmp/work/x86_64-linux/jaxp1.3-native/1.4.01-r0/temp/log.do_compile.15390)
> ERROR: Task
> (virtual:native:/home/jenkins/meta-java/recipes-core/xml-commons/jaxp1.3_1.4.01.bb:do_compile)
> failed with exit code '1'
> ERROR: gnujaf-native-1.1.1-r1 do_compile: Function failed: do_compile (log
> file is located at
> /home/jenkins/my_build/tmp/work/x86_64-linux/gnujaf-native/1.1.1-r1/temp/log.do_compile.15475)
> ERROR: Logfile of failure stored in:
> /home/jenkins/my_build/tmp/work/x86_64-linux/gnujaf-native/1.1.1-r1/temp/log.do_compile.15475
> Log data follows:
> | DEBUG: Executing shell function do_compile
> | Illegal instruction (core dumped)
> | WARNING: exit code 132 from a shell command.
> | ERROR: Function failed: do_compile (log file is located at
> /home/jenkins/my_build/tmp/work/x86_64-linux/gnujaf-native/1.1.1-r1/temp/log.do_compile.15475)
>
> Looks like javac is failing (when run devshell and call java it will print
> help though). I tried same setup on ubuntu 16.04 and here it works
> perfectly fine. Any ides what can cause this - different toolchain or?
> Thanks.
>
> BR,
>
> marek
>
> --
> as simple and primitive as possible
> -
> Marek Belisko - OPEN-NANDRA
> Freelance Developer
>
> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
> Tel: +421 915 052 184
> skype: marekwhite
> twitter: #opennandra
> web: http://open-nandra.com
>

BR,

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

[yocto] [meta-java] Illegal instruction (core dumped) when compiling jaxp1.3-native-1.4.01-r0

[Belisko Marek]

Hi,

I'm using meta-java sumo branch and on ubuntu 18.04 I have this issue
(building for beaglebone-yocto machine):
ERROR: jaxp1.3-native-1.4.01-r0 do_compile: Function failed: do_compile
(log file is located at
/home/jenkins/my_build/tmp/work/x86_64-linux/jaxp1.3-native/1.4.01-r0/temp/log.do_compile.15390)
ERROR: Logfile of failure stored in:
/home/jenkins/my_build/tmp/work/x86_64-linux/jaxp1.3-native/1.4.01-r0/temp/log.do_compile.15390
Log data follows:
| DEBUG: Executing shell function do_compile
| Illegal instruction (core dumped)
| WARNING: exit code 132 from a shell command.
| ERROR: Function failed: do_compile (log file is located at
/home/jenkins/my_build/tmp/work/x86_64-linux/jaxp1.3-native/1.4.01-r0/temp/log.do_compile.15390)
ERROR: Task
(virtual:native:/home/jenkins/meta-java/recipes-core/xml-commons/jaxp1.3_1.4.01.bb:do_compile)
failed with exit code '1'
ERROR: gnujaf-native-1.1.1-r1 do_compile: Function failed: do_compile (log
file is located at
/home/jenkins/my_build/tmp/work/x86_64-linux/gnujaf-native/1.1.1-r1/temp/log.do_compile.15475)
ERROR: Logfile of failure stored in:
/home/jenkins/my_build/tmp/work/x86_64-linux/gnujaf-native/1.1.1-r1/temp/log.do_compile.15475
Log data follows:
| DEBUG: Executing shell function do_compile
| Illegal instruction (core dumped)
| WARNING: exit code 132 from a shell command.
| ERROR: Function failed: do_compile (log file is located at
/home/jenkins/my_build/tmp/work/x86_64-linux/gnujaf-native/1.1.1-r1/temp/log.do_compile.15475)

Looks like javac is failing (when run devshell and call java it will print
help though). I tried same setup on ubuntu 16.04 and here it works
perfectly fine. Any ides what can cause this - different toolchain or?
Thanks.

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] readonly rootfs - storing data in separate partition

[Belisko Marek]

On Mon, Feb 18, 2019 at 6:05 PM Joshua Watt  wrote:

> On Mon, 2019-02-18 at 17:36 +0100, Belisko Marek wrote:
>
> Hi,
>
> I plan to use readonly rootfs option and store some custom data in
> separate partition (like hostname, wpa_supplicant.conf etc). I have wic
> file which create rootfs + then rest is for data storage. I can adjust
> various recipes to symlink to /data partition. My question is if there
> exists some mechanism how to store some pieces in non-rootfs partition? I
> know some projects which put those extra files to deploy dir and then by dd
> create dummy storage nd put files there and finally create partition from
> that. Thanks a log for any pointers.
>
>
> We do this a lot using volatiles files. The best documentation is the core
> volatiles file:
> https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/initscripts/initscripts-1.0/volatiles
>
Can this be used when systemd is init manager? Thanks.

>
>
> BR,
>
> marek
>
> --
>
> Joshua Watt 
>

BR,

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

Re: [yocto] readonly rootfs - storing data in separate partition

[Belisko Marek]

On Mon, Feb 18, 2019 at 5:52 PM Marc Ferland  wrote:

> On Mon, Feb 18, 2019 at 11:37 AM Belisko Marek 
> wrote:
>
>> Hi,
>>
>> I plan to use readonly rootfs option and store some custom data in
>> separate partition (like hostname, wpa_supplicant.conf etc). I have wic
>> file which create rootfs + then rest is for data storage. I can adjust
>> various recipes to symlink to /data partition. My question is if there
>> exists some mechanism how to store some pieces in non-rootfs partition? I
>> know some projects which put those extra files to deploy dir and then by dd
>> create dummy storage nd put files there and finally create partition from
>> that. Thanks a log for any pointers.
>>
>>
>
> You could potentially use overlayfs to have a RO rootfs and a separate RW
> layer in another partition for example. I think linux-yocto also support
> AUFS.
>
This one seems promising:
https://github.com/cmhe/meta-readonly-rootfs-overlay
This is not exactly what I was looking for but I think it can be usable.
Anyone using this? Thanks.

>
> Good luck,
>
> Marc
>

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

[yocto] readonly rootfs - storing data in separate partition

[Belisko Marek]

Hi,

I plan to use readonly rootfs option and store some custom data in separate
partition (like hostname, wpa_supplicant.conf etc). I have wic file which
create rootfs + then rest is for data storage. I can adjust various recipes
to symlink to /data partition. My question is if there exists some
mechanism how to store some pieces in non-rootfs partition? I know some
projects which put those extra files to deploy dir and then by dd create
dummy storage nd put files there and finally create partition from that.
Thanks a log for any pointers.

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi] Rainbow screen with Raspberry Pi 3 A+ but not on B+

[Belisko Marek]

Hi Markus,

On Fri, Feb 1, 2019 at 2:54 PM Markus W  wrote:

> Thanks Marek!
>
> I pretty sure it doesn't boot, but I haven't confirmed it as you suggested
> it.
>
> I have never connected to the uart interface directly on the GPIO or via
> bluetooth. It probably takes me more time to figure it out and to do this
> than trying the thud branch as @agherzan has mentioned here:
> https://github.com/agherzan/meta-raspberrypi/issues/373
>
OK attaching serial port isn't that hard but as you stated, please try thud
branch. You can try https://hub.mender.io/t/raspberry-pi-3-model-b-b/57 to
follow this procedure as this is verified for B/B+ works fine with thud.

>
> I am also using meta-mender, do I need to upgrade all layers to thud than?
>
> Regards,
> Markus
>
> P.S.: pls don't top post ;)

marek

>
> On Fri, 1 Feb 2019 at 13:17, Belisko Marek 
> wrote:
>
>> On Fri, Feb 1, 2019 at 1:11 PM Markus W  wrote:
>>
>>> Hi!
>>>
>>> I have been running a yocto image (sumo) on a raspberry 3 B+ without any
>>> problems, but wanted to test the new raspberry Pi 3 A+ board with it but I
>>> just get the Rainbow screen on boot. I have updated meta-openembedded to
>>> the latest sumo and meta-raspberry was still up to date with the latest
>>> (sumo) and still the same result.
>>>
>>
>>> My question: Has anybody been running sumo on a raspberrypi 3 a+
>>> successfully? I have been googling around for issues but can't find
>>> anything on the new board and yocto. Seems that I am missing something.
>>>
>> Can you connect serial console and add enable_uart=1 to config.txt and
>> verify? This looks like it doesn't boot. You can also ask on [1]
>>
>>>
>>> Regards,
>>> Markus
>>>
>> --
>>>
>>
>> [1] -  https://github.com/agherzan/meta-raspberrypi/issues
>>
>> BR,
>>
>> marek
>>
>>> ___
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>
>>
>> --
>> as simple and primitive as possible
>> -
>> Marek Belisko - OPEN-NANDRA
>> Freelance Developer
>>
>> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
>> Tel: +421 915 052 184
>> skype: marekwhite
>> twitter: #opennandra
>> web: http://open-nandra.com
>>
>

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi] Rainbow screen with Raspberry Pi 3 A+ but not on B+

[Belisko Marek]

On Fri, Feb 1, 2019 at 1:11 PM Markus W  wrote:

> Hi!
>
> I have been running a yocto image (sumo) on a raspberry 3 B+ without any
> problems, but wanted to test the new raspberry Pi 3 A+ board with it but I
> just get the Rainbow screen on boot. I have updated meta-openembedded to
> the latest sumo and meta-raspberry was still up to date with the latest
> (sumo) and still the same result.
>

> My question: Has anybody been running sumo on a raspberrypi 3 a+
> successfully? I have been googling around for issues but can't find
> anything on the new board and yocto. Seems that I am missing something.
>
Can you connect serial console and add enable_uart=1 to config.txt and
verify? This looks like it doesn't boot. You can also ask on [1]

>
> Regards,
> Markus
>
-- 
>

[1] -  https://github.com/agherzan/meta-raspberrypi/issues

BR,

marek

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


-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] adding files to data partition (not rootfs)

[Belisko Marek]

Hello,

I can to the problem that we have 2x rootfs + data partition where
persistent data sholud be stored. We also want to store some configuration
files in persistent data partition. I've created wic file with fixed size
of that partition but I'm not sure how to add files to that partition. Is
there some generic yocto way how to deal with that? Thanks for any pointers.

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Date/Time Update Without NTP

[Belisko Marek]

On Mon, Nov 26, 2018 at 12:57 PM Donal Morrissey
 wrote:
>
> Hi There,
>
> I'm using yocto sumo with systemd, and have an issue where I can't identify 
> which service is grabbing time from the ethernet based network.
>
> If I start the unit without a network connection, the time is reported as 
> EPOC. As soon as I connect the network, the date/time is updated. However, 
> there isn't anything in the logs that I can see which tells details of the 
> service which has updated time. Also, the ntpd binary is not installed.
>
> Is there a time service, other than NTP, which would typically be enabled on 
> Yocto builds?
it should be probably systemd-timesyncd service (check if it's running)
>
> Cheers,
> Donal
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

BR,

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

Re: [yocto] using pip3-native to install python requirements

[Belisko Marek]

On Mon, Nov 12, 2018 at 10:35 AM Outback Dingo  wrote:
>
> On Mon, Nov 12, 2018 at 3:22 PM Belisko Marek  wrote:
> >
> > Hi,
> >
> > I'm having recipe for custom python3 application whcih need to install
> > ~20 python dependencies. I've create requirements.txt and using pip on
> > PC I can install necessary python packages. When try to use
> > pip3-native (as DEPENDS) and call pip3 I get some errors:
> >
> > pkg_resources.VersionConflict: (pip 8.1.1
> > (/usr/lib/python3/dist-packages), Requirement.parse('pip==9.0.1'))
> >
> > I would like to ask it pip3 can be used (didn't find any other
> > occurrence in poky) or should I add python dependencies as RDEPENDS ?
>
> i believe you just need to add inherit setuptools3 to the recipe your
> trying to use pip3 for
Well application doesn't contain setup.py (after inheriting setuptool3 I get:)
recipe-sysroot-native/usr/bin/python3-native/python3: can't open file
'setup.py': [Errno 2] No such file or directory
| ERROR: python3 setup.py build_ext execution failed.

So is the correct way to create setup.py which will internall somehow
add all required external modules to be installed. Thanks.
>
> > Thanks.
> >
> > BR,
> >
> > marek
> >
> >
> > --
> > as simple and primitive as possible
> > -
> > Marek Belisko - OPEN-NANDRA
> > Freelance Developer
> >
> > Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
> > Tel: +421 915 052 184
> > skype: marekwhite
> > twitter: #opennandra
> > web: http://open-nandra.com
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] using pip3-native to install python requirements

[Belisko Marek]

Hi,

I'm having recipe for custom python3 application whcih need to install
~20 python dependencies. I've create requirements.txt and using pip on
PC I can install necessary python packages. When try to use
pip3-native (as DEPENDS) and call pip3 I get some errors:

pkg_resources.VersionConflict: (pip 8.1.1
(/usr/lib/python3/dist-packages), Requirement.parse('pip==9.0.1'))

I would like to ask it pip3 can be used (didn't find any other
occurrence in poky) or should I add python dependencies as RDEPENDS ?
Thanks.

BR,

marek


--
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to compute SRCREV for a github project

[Belisko Marek]

Hi,


On Tue, Nov 6, 2018 at 5:10 PM Laurentiu-Cristian Duca
 wrote:
>
> Dear yocto community,
>
>   A basic question regarding yocto and git.
> How to compute the SRCREV for the linux-raspberrypi_4.14.bb recipe:
> $ cat meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_4.14.bb
> LINUX_VERSION ?= "4.14.68"
> SRCREV = "8c8666ff6c1254d325cfa300d16f9928b3f31fc0"
> SRC_URI = "git://github.com/raspberrypi/linux.git;branch=rpi-4.14.y"
> ...
>
>   If I want to change to LINUX_VERSION 4.14.74 (for example),
> how will I compute or get the SRCREV for this version
SRCREV is git commit id from 4.14.74 (so if you checkout 4.14.74 tag
just run git log -1 and copy git commit ID to SRCREV and it will
work).
> (please note that I am not interested in AUTOREV)?
> The command "git log -50" lists the latest 50 commits
> and a 40-bit signature for each commit, but does not show the kernel version.
>
>   I have searched google but no response found.
>
> Thank you and best regards,
> Laurentiu-Cristian Duca
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] intel-nuc: hddimg EFI_PROVIDER for final install

[Belisko Marek]

Hi,

I'm trying to build hddimg for intel-nuc. Basically default
EFI_PROVIDER is systemd-boot but I want to use grub-efi so I've
updated variable accordingly. I have some changes in grub-efi (more
rootfs partitions + data). When trying to start hddimg it will start
grub with grub.cfg with my changes and not one which should be used
for "live" boot. I don't have an idea hos sysconfig found updated
grub.cfg and not one for live boot. Any ideas or I need to change also
something else? Thanks.

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] master-next : QA issue with glibc locale

[Belisko Marek]

On Mon, Oct 22, 2018 at 11:01 AM Belisko Marek  wrote:
>
> Hi Khem,
> On Mon, Oct 22, 2018 at 12:31 AM Khem Raj  wrote:
> >
> > On Sun, Oct 21, 2018 at 7:42 PM Belisko Marek  
> > wrote:
> > >
> > > Hi Khem,
> > >
> > > On Sun, Oct 21, 2018 at 8:40 PM Khem Raj  wrote:
> > > >
> > > >
> > > >
> > > > On Sun, Oct 21, 2018 at 7:27 PM Belisko Marek  
> > > > wrote:
> > > >>
> > > >> Hi,
> > > >>
> > > >> I had problem with rocko see here [1] but issue is still present in
> > > >> poky master-next also:
> > > >
> > > >
> > > > Is it using stock poky or are there any customizations if yes then 
> > > > please share those too
> > > Nope any customizations just stock poky (master-next
> > > 32bfcbed083622de7462d0c563a7070acd7efe9b)
> >
> > interesting, I dont have is reproducble so cant see much through the
> > issue . but does
> > the workaround suggested in
> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=12265
> > help where you disable cross-localedef
> I tried suggested workaround (wipe all stuff except downloads and
> re-run again) and hit this:
>
> ERROR: core-image-base-1.0-r0 do_rootfs: Unable to install packages.
> Command 
> '/home/marek/projects/yocto/poky/build/tmp/work/beaglebone_yocto-poky-linux-gnueabi/core-image-base/1.0-r0/recipe-sysroot-native/usr/bin/opkg
> --volatile-cache -f
> /home/marek/projects/yocto/poky/build/tmp/work/beaglebone_yocto-poky-linux-gnueabi/core-image-base/1.0-r0/opkg.conf
> -t 
> /home/marek/projects/yocto/poky/build/tmp/work/beaglebone_yocto-poky-linux-gnueabi/core-image-base/1.0-r0/temp/ipktemp/
> -o 
> /home/marek/projects/yocto/poky/build/tmp/work/beaglebone_yocto-poky-linux-gnueabi/core-image-base/1.0-r0/rootfs
>  --force_postinstall --prefer-arch-to-version   install
> locale-base-en-gb locale-base-en-us' returned 255:
> Collected errors:
>  * opkg_prepare_url_for_install: Couldn't find anything to satisfy
> 'locale-base-en-gb'.
>  * rm_r: Failed to open dir
> /home/marek/projects/yocto/poky/build/tmp/work/beaglebone_yocto-poky-linux-gnueabi/core-image-base/1.0-r0/temp/ipktemp//opkg-o8sLzj:
> No such file or directory.
>
> ERROR: core-image-base-1.0-r0 do_rootfs: Function failed: do_rootfs
> ERROR: Logfile of failure stored in:
> /home/marek/projects/yocto/poky/build/tmp/work/beaglebone_yocto-poky-linux-gnueabi/core-image-base/1.0-r0/temp/log.do_rootfs.2729
> ERROR: Task 
> (/home/marek/projects/yocto/poky//meta/recipes-core/images/core-image-base.bb:do_rootfs)
> failed with exit code '1'
>
> I have same with below patch (when workaround QA issue). I have
> meta-java in bblayers and building openjdk-8 (but I don't think this
> could have some influence). Thanks.

Looks like issue is with core-image-base. When build
core-image-minimal issue vanished (with workaround from bugzilla)
> >
> > > >>
> > > >>
> > > >>
> > > >> ERROR: glibc-locale-2.28-r0 do_package: QA Issue: glibc-locale:
> > > >> Files/directories were installed but not shipped in any package:
> > > >>   /usr/share/i18n
> > > >>   /usr/share/i18n/charmaps
> > > >>   /usr/share/i18n/locales
> > > >>   /usr/share/i18n/charmaps/ISO-8859-2.gz
> > > >>   /usr/share/i18n/charmaps/T.61-8BIT.gz
> > > >>   /usr/share/i18n/charmaps/IBM855.gz
> > > >>   /usr/share/i18n/charmaps/IBM1163.gz
> > > >>   /usr/share/i18n/charmaps/IBM1129.gz
> > > >>   /usr/share/i18n/charmaps/SHIFT_JIS.gz
> > > >>   /usr/share/i18n/charmaps/CWI.gz
> > > >>   /usr/share/i18n/charmaps/CP1253.gz
> > > >>   /usr/share/i18n/charmaps/IBM880.gz
> > > >>   /usr/share/i18n/charmaps/T.101-G2.gz
> > > >>   /usr/share/i18n/charmaps/ISO-8859-5.gz
> > > >>   /usr/share/i18n/charmaps/CP1250.gz
> > > >>   /usr/share/i18n/charmaps/INIS-8.gz
> > > >>   /usr/share/i18n/charmaps/SHIFT_JISX0213.gz
> > > >>   /usr/share/i18n/charmaps/IBM297.gz
> > > >>   /usr/share/i18n/charmaps/ISO_10367-BOX.gz
> > > >>   /usr/share/i18n/charmaps/CP1257.gz
> > > >>   /usr/share/i18n/charmaps/JIS_C6220-1969-RO.gz
> > > >>   /usr/share/i18n/charmaps/IBM278.gz
> > > >>   /usr/share/i18n/charmaps/IBM858.gz
> > > >>   /usr/share/i18n/charmaps/KSC5636.gz
> > > >>   /usr/share/i18n/charmaps/IBM285.gz
> > > >>   /usr/share/i18n/c

Re: [yocto] master-next : QA issue with glibc locale

[Belisko Marek]

Hi Khem,
On Mon, Oct 22, 2018 at 12:31 AM Khem Raj  wrote:
>
> On Sun, Oct 21, 2018 at 7:42 PM Belisko Marek  wrote:
> >
> > Hi Khem,
> >
> > On Sun, Oct 21, 2018 at 8:40 PM Khem Raj  wrote:
> > >
> > >
> > >
> > > On Sun, Oct 21, 2018 at 7:27 PM Belisko Marek  
> > > wrote:
> > >>
> > >> Hi,
> > >>
> > >> I had problem with rocko see here [1] but issue is still present in
> > >> poky master-next also:
> > >
> > >
> > > Is it using stock poky or are there any customizations if yes then please 
> > > share those too
> > Nope any customizations just stock poky (master-next
> > 32bfcbed083622de7462d0c563a7070acd7efe9b)
>
> interesting, I dont have is reproducble so cant see much through the
> issue . but does
> the workaround suggested in
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=12265
> help where you disable cross-localedef
I tried suggested workaround (wipe all stuff except downloads and
re-run again) and hit this:

ERROR: core-image-base-1.0-r0 do_rootfs: Unable to install packages.
Command 
'/home/marek/projects/yocto/poky/build/tmp/work/beaglebone_yocto-poky-linux-gnueabi/core-image-base/1.0-r0/recipe-sysroot-native/usr/bin/opkg
--volatile-cache -f
/home/marek/projects/yocto/poky/build/tmp/work/beaglebone_yocto-poky-linux-gnueabi/core-image-base/1.0-r0/opkg.conf
-t 
/home/marek/projects/yocto/poky/build/tmp/work/beaglebone_yocto-poky-linux-gnueabi/core-image-base/1.0-r0/temp/ipktemp/
-o 
/home/marek/projects/yocto/poky/build/tmp/work/beaglebone_yocto-poky-linux-gnueabi/core-image-base/1.0-r0/rootfs
 --force_postinstall --prefer-arch-to-version   install
locale-base-en-gb locale-base-en-us' returned 255:
Collected errors:
 * opkg_prepare_url_for_install: Couldn't find anything to satisfy
'locale-base-en-gb'.
 * rm_r: Failed to open dir
/home/marek/projects/yocto/poky/build/tmp/work/beaglebone_yocto-poky-linux-gnueabi/core-image-base/1.0-r0/temp/ipktemp//opkg-o8sLzj:
No such file or directory.

ERROR: core-image-base-1.0-r0 do_rootfs: Function failed: do_rootfs
ERROR: Logfile of failure stored in:
/home/marek/projects/yocto/poky/build/tmp/work/beaglebone_yocto-poky-linux-gnueabi/core-image-base/1.0-r0/temp/log.do_rootfs.2729
ERROR: Task 
(/home/marek/projects/yocto/poky//meta/recipes-core/images/core-image-base.bb:do_rootfs)
failed with exit code '1'

I have same with below patch (when workaround QA issue). I have
meta-java in bblayers and building openjdk-8 (but I don't think this
could have some influence). Thanks.
>
> > >>
> > >>
> > >>
> > >> ERROR: glibc-locale-2.28-r0 do_package: QA Issue: glibc-locale:
> > >> Files/directories were installed but not shipped in any package:
> > >>   /usr/share/i18n
> > >>   /usr/share/i18n/charmaps
> > >>   /usr/share/i18n/locales
> > >>   /usr/share/i18n/charmaps/ISO-8859-2.gz
> > >>   /usr/share/i18n/charmaps/T.61-8BIT.gz
> > >>   /usr/share/i18n/charmaps/IBM855.gz
> > >>   /usr/share/i18n/charmaps/IBM1163.gz
> > >>   /usr/share/i18n/charmaps/IBM1129.gz
> > >>   /usr/share/i18n/charmaps/SHIFT_JIS.gz
> > >>   /usr/share/i18n/charmaps/CWI.gz
> > >>   /usr/share/i18n/charmaps/CP1253.gz
> > >>   /usr/share/i18n/charmaps/IBM880.gz
> > >>   /usr/share/i18n/charmaps/T.101-G2.gz
> > >>   /usr/share/i18n/charmaps/ISO-8859-5.gz
> > >>   /usr/share/i18n/charmaps/CP1250.gz
> > >>   /usr/share/i18n/charmaps/INIS-8.gz
> > >>   /usr/share/i18n/charmaps/SHIFT_JISX0213.gz
> > >>   /usr/share/i18n/charmaps/IBM297.gz
> > >>   /usr/share/i18n/charmaps/ISO_10367-BOX.gz
> > >>   /usr/share/i18n/charmaps/CP1257.gz
> > >>   /usr/share/i18n/charmaps/JIS_C6220-1969-RO.gz
> > >>   /usr/share/i18n/charmaps/IBM278.gz
> > >>   /usr/share/i18n/charmaps/IBM858.gz
> > >>   /usr/share/i18n/charmaps/KSC5636.gz
> > >>   /usr/share/i18n/charmaps/IBM285.gz
> > >>   /usr/share/i18n/charmaps/INIS.gz
> > >>   /usr/share/i18n/charmaps/EUC-TW.gz
> > >>   /usr/share/i18n/charmaps/IBM274.gz
> > >>   /usr/share/i18n/charmaps/IBM038.gz
> > >>   /usr/share/i18n/charmaps/DS_2089.gz
> > >>   /usr/share/i18n/charmaps/GB2312.gz
> > >>   /usr/share/i18n/charmaps/EBCDIC-UK.gz
> > >>   /usr/share/i18n/charmaps/GOST_19768-74.gz
> > >>   /usr/share/i18n/charmaps/ISO-IR-209.gz
> > >>   /usr/share/i18n/charmaps/BS_4730.gz
> > >>   /usr/share/i18n/charmaps/IT.gz
> > >>   /usr/share/i18n/charmaps/IBM918.gz
> &

Re: [yocto] master-next : QA issue with glibc locale

[Belisko Marek]

Hi Khem,

On Sun, Oct 21, 2018 at 8:40 PM Khem Raj  wrote:
>
>
>
> On Sun, Oct 21, 2018 at 7:27 PM Belisko Marek  wrote:
>>
>> Hi,
>>
>> I had problem with rocko see here [1] but issue is still present in
>> poky master-next also:
>
>
> Is it using stock poky or are there any customizations if yes then please 
> share those too
Nope any customizations just stock poky (master-next
32bfcbed083622de7462d0c563a7070acd7efe9b)
>>
>>
>>
>> ERROR: glibc-locale-2.28-r0 do_package: QA Issue: glibc-locale:
>> Files/directories were installed but not shipped in any package:
>>   /usr/share/i18n
>>   /usr/share/i18n/charmaps
>>   /usr/share/i18n/locales
>>   /usr/share/i18n/charmaps/ISO-8859-2.gz
>>   /usr/share/i18n/charmaps/T.61-8BIT.gz
>>   /usr/share/i18n/charmaps/IBM855.gz
>>   /usr/share/i18n/charmaps/IBM1163.gz
>>   /usr/share/i18n/charmaps/IBM1129.gz
>>   /usr/share/i18n/charmaps/SHIFT_JIS.gz
>>   /usr/share/i18n/charmaps/CWI.gz
>>   /usr/share/i18n/charmaps/CP1253.gz
>>   /usr/share/i18n/charmaps/IBM880.gz
>>   /usr/share/i18n/charmaps/T.101-G2.gz
>>   /usr/share/i18n/charmaps/ISO-8859-5.gz
>>   /usr/share/i18n/charmaps/CP1250.gz
>>   /usr/share/i18n/charmaps/INIS-8.gz
>>   /usr/share/i18n/charmaps/SHIFT_JISX0213.gz
>>   /usr/share/i18n/charmaps/IBM297.gz
>>   /usr/share/i18n/charmaps/ISO_10367-BOX.gz
>>   /usr/share/i18n/charmaps/CP1257.gz
>>   /usr/share/i18n/charmaps/JIS_C6220-1969-RO.gz
>>   /usr/share/i18n/charmaps/IBM278.gz
>>   /usr/share/i18n/charmaps/IBM858.gz
>>   /usr/share/i18n/charmaps/KSC5636.gz
>>   /usr/share/i18n/charmaps/IBM285.gz
>>   /usr/share/i18n/charmaps/INIS.gz
>>   /usr/share/i18n/charmaps/EUC-TW.gz
>>   /usr/share/i18n/charmaps/IBM274.gz
>>   /usr/share/i18n/charmaps/IBM038.gz
>>   /usr/share/i18n/charmaps/DS_2089.gz
>>   /usr/share/i18n/charmaps/GB2312.gz
>>   /usr/share/i18n/charmaps/EBCDIC-UK.gz
>>   /usr/share/i18n/charmaps/GOST_19768-74.gz
>>   /usr/share/i18n/charmaps/ISO-IR-209.gz
>>   /usr/share/i18n/charmaps/BS_4730.gz
>>   /usr/share/i18n/charmaps/IT.gz
>>   /usr/share/i18n/charmaps/IBM918.gz
>>   /usr/share/i18n/charmaps/MAC-CYRILLIC.gz
>>   /usr/share/i18n/charmaps/CP10007.gz
>>   /usr/share/i18n/charmaps/BS_VIEWDATA.gz
>>   /usr/share/i18n/charmaps/ISO_646.IRV.gz
>>   /usr/share/i18n/charmaps/EBCDIC-FI-SE.gz
>>   /usr/share/i18n/charmaps/NF_Z_62-010.gz
>>   /usr/share/i18n/charmaps/KOI8-R.gz
>>   /usr/share/i18n/charmaps/IBM280.gz
>>   /usr/share/i18n/charmaps/IBM857.gz
>>   /usr/share/i18n/charmaps/JIS_C6229-1984-KANA.gz
>>   /usr/share/i18n/charmaps/EUC-JISX0213.gz
>>   /usr/share/i18n/charmaps/ISO-8859-7.gz
>>   /usr/share/i18n/charmaps/CSN_369103.gz
>>   /usr/share/i18n/charmaps/GEORGIAN-ACADEMY.gz
>>   /usr/share/i18n/charmaps/NS_4551-1.gz
>>   /usr/share/i18n/charmaps/IBM1164.gz
>>   /usr/share/i18n/charmaps/WINDOWS-31J.gz
>>   /usr/share/i18n/charmaps/GBK.gz
>>   /usr/share/i18n/charmaps/PT2.gz
>>   /usr/share/i18n/charmaps/NATS-SEFI.gz
>>   /usr/share/i18n/charmaps/TSCII.gz
>>   /usr/share/i18n/charmaps/JIS_C6220-1969-JP.gz
>>   /usr/share/i18n/charmaps/ISO-8859-10.gz
>>   /usr/share/i18n/charmaps/IBM290.gz
>>   /usr/share/i18n/charmaps/EBCDIC-US.gz
>>   /usr/share/i18n/charmaps/ISIRI-3342.gz
>>   /usr/share/i18n/charmaps/JIS_C6229-1984-HAND.gz
>>   /usr/share/i18n/charmaps/MIK.gz
>>   /usr/share/i18n/charmaps/HP-THAI8.gz
>>   /usr/share/i18n/charmaps/TCVN5712-1.gz
>>   /usr/share/i18n/charmaps/DIN_66003.gz
>>   /usr/share/i18n/charmaps/CP774.gz
>>   /usr/share/i18n/charmaps/JOHAB.gz
>>   /usr/share/i18n/charmaps/IBM904.gz
>>   /usr/share/i18n/charmaps/LATIN-GREEK-1.gz
>>   /usr/share/i18n/charmaps/IBM863.gz
>>   /usr/share/i18n/charmaps/HP-ROMAN8.gz
>>   /usr/share/i18n/charmaps/ISO_5428.gz
>>   /usr/share/i18n/charmaps/IEC_P27-1.gz
>>   /usr/share/i18n/charmaps/CP1254.gz
>>   /usr/share/i18n/charmaps/CP1125.gz
>>   /usr/share/i18n/charmaps/KOI-8.gz
>>   /usr/share/i18n/charmaps/JIS_C6229-1984-A.gz
>>   /usr/share/i18n/charmaps/ISO-8859-9.gz
>>   /usr/share/i18n/charmaps/ISO_646.BASIC.gz
>>   /usr/share/i18n/charmaps/IBM860.gz
>>   /usr/share/i18n/charmaps/IBM891.gz
>>   /usr/share/i18n/charmaps/NF_Z_62-010_1973.gz
>>   /usr/share/i18n/charmaps/CP773.gz
>>   /usr/share/i18n/charmaps/NS_4551-2.gz
>>   /usr/share/i18n/charmaps/ISO-8859-13.gz
>>   /usr/share/i18n/charmaps/ANSI_X3.4-1968.gz
>>   /usr/share/i18n/charmaps/EBCDIC-ES-A.gz
>>  

[yocto] master-next : QA issue with glibc locale

[Belisko Marek]

Hi,

I had problem with rocko see here [1] but issue is still present in
poky master-next also:

ERROR: glibc-locale-2.28-r0 do_package: QA Issue: glibc-locale:
Files/directories were installed but not shipped in any package:
  /usr/share/i18n
  /usr/share/i18n/charmaps
  /usr/share/i18n/locales
  /usr/share/i18n/charmaps/ISO-8859-2.gz
  /usr/share/i18n/charmaps/T.61-8BIT.gz
  /usr/share/i18n/charmaps/IBM855.gz
  /usr/share/i18n/charmaps/IBM1163.gz
  /usr/share/i18n/charmaps/IBM1129.gz
  /usr/share/i18n/charmaps/SHIFT_JIS.gz
  /usr/share/i18n/charmaps/CWI.gz
  /usr/share/i18n/charmaps/CP1253.gz
  /usr/share/i18n/charmaps/IBM880.gz
  /usr/share/i18n/charmaps/T.101-G2.gz
  /usr/share/i18n/charmaps/ISO-8859-5.gz
  /usr/share/i18n/charmaps/CP1250.gz
  /usr/share/i18n/charmaps/INIS-8.gz
  /usr/share/i18n/charmaps/SHIFT_JISX0213.gz
  /usr/share/i18n/charmaps/IBM297.gz
  /usr/share/i18n/charmaps/ISO_10367-BOX.gz
  /usr/share/i18n/charmaps/CP1257.gz
  /usr/share/i18n/charmaps/JIS_C6220-1969-RO.gz
  /usr/share/i18n/charmaps/IBM278.gz
  /usr/share/i18n/charmaps/IBM858.gz
  /usr/share/i18n/charmaps/KSC5636.gz
  /usr/share/i18n/charmaps/IBM285.gz
  /usr/share/i18n/charmaps/INIS.gz
  /usr/share/i18n/charmaps/EUC-TW.gz
  /usr/share/i18n/charmaps/IBM274.gz
  /usr/share/i18n/charmaps/IBM038.gz
  /usr/share/i18n/charmaps/DS_2089.gz
  /usr/share/i18n/charmaps/GB2312.gz
  /usr/share/i18n/charmaps/EBCDIC-UK.gz
  /usr/share/i18n/charmaps/GOST_19768-74.gz
  /usr/share/i18n/charmaps/ISO-IR-209.gz
  /usr/share/i18n/charmaps/BS_4730.gz
  /usr/share/i18n/charmaps/IT.gz
  /usr/share/i18n/charmaps/IBM918.gz
  /usr/share/i18n/charmaps/MAC-CYRILLIC.gz
  /usr/share/i18n/charmaps/CP10007.gz
  /usr/share/i18n/charmaps/BS_VIEWDATA.gz
  /usr/share/i18n/charmaps/ISO_646.IRV.gz
  /usr/share/i18n/charmaps/EBCDIC-FI-SE.gz
  /usr/share/i18n/charmaps/NF_Z_62-010.gz
  /usr/share/i18n/charmaps/KOI8-R.gz
  /usr/share/i18n/charmaps/IBM280.gz
  /usr/share/i18n/charmaps/IBM857.gz
  /usr/share/i18n/charmaps/JIS_C6229-1984-KANA.gz
  /usr/share/i18n/charmaps/EUC-JISX0213.gz
  /usr/share/i18n/charmaps/ISO-8859-7.gz
  /usr/share/i18n/charmaps/CSN_369103.gz
  /usr/share/i18n/charmaps/GEORGIAN-ACADEMY.gz
  /usr/share/i18n/charmaps/NS_4551-1.gz
  /usr/share/i18n/charmaps/IBM1164.gz
  /usr/share/i18n/charmaps/WINDOWS-31J.gz
  /usr/share/i18n/charmaps/GBK.gz
  /usr/share/i18n/charmaps/PT2.gz
  /usr/share/i18n/charmaps/NATS-SEFI.gz
  /usr/share/i18n/charmaps/TSCII.gz
  /usr/share/i18n/charmaps/JIS_C6220-1969-JP.gz
  /usr/share/i18n/charmaps/ISO-8859-10.gz
  /usr/share/i18n/charmaps/IBM290.gz
  /usr/share/i18n/charmaps/EBCDIC-US.gz
  /usr/share/i18n/charmaps/ISIRI-3342.gz
  /usr/share/i18n/charmaps/JIS_C6229-1984-HAND.gz
  /usr/share/i18n/charmaps/MIK.gz
  /usr/share/i18n/charmaps/HP-THAI8.gz
  /usr/share/i18n/charmaps/TCVN5712-1.gz
  /usr/share/i18n/charmaps/DIN_66003.gz
  /usr/share/i18n/charmaps/CP774.gz
  /usr/share/i18n/charmaps/JOHAB.gz
  /usr/share/i18n/charmaps/IBM904.gz
  /usr/share/i18n/charmaps/LATIN-GREEK-1.gz
  /usr/share/i18n/charmaps/IBM863.gz
  /usr/share/i18n/charmaps/HP-ROMAN8.gz
  /usr/share/i18n/charmaps/ISO_5428.gz
  /usr/share/i18n/charmaps/IEC_P27-1.gz
  /usr/share/i18n/charmaps/CP1254.gz
  /usr/share/i18n/charmaps/CP1125.gz
  /usr/share/i18n/charmaps/KOI-8.gz
  /usr/share/i18n/charmaps/JIS_C6229-1984-A.gz
  /usr/share/i18n/charmaps/ISO-8859-9.gz
  /usr/share/i18n/charmaps/ISO_646.BASIC.gz
  /usr/share/i18n/charmaps/IBM860.gz
  /usr/share/i18n/charmaps/IBM891.gz
  /usr/share/i18n/charmaps/NF_Z_62-010_1973.gz
  /usr/share/i18n/charmaps/CP773.gz
  /usr/share/i18n/charmaps/NS_4551-2.gz
  /usr/share/i18n/charmaps/ISO-8859-13.gz
  /usr/share/i18n/charmaps/ANSI_X3.4-1968.gz
  /usr/share/i18n/charmaps/EBCDIC-ES-A.gz
  /usr/share/i18n/charmaps/IBM284.gz
  /usr/share/i18n/charmaps/ISO-8859-1.gz
  /usr/share/i18n/charmaps/CP770.gz
  /usr/share/i18n/charmaps/CSA_Z243.4-1985-1.gz
  /usr/share/i18n/charmaps/ANSI_X3.110-1983.gz
  /usr/share/i18n/charmaps/EBCDIC-IS-FRISS.gz
  /usr/share/i18n/charmaps/MAC-IS.gz
  /usr/share/i18n/charmaps/TIS-620.gz
  /usr/share/i18n/charmaps/ISO_6937-2-25.gz
  /usr/share/i18n/charmaps/RK1048.gz
  /usr/share/i18n/charmaps/IBM1133.gz
  /usr/share/i18n/charmaps/GREEK7-OLD.gz
  /usr/share/i18n/charmaps/CP737.gz
  /usr/share/i18n/charmaps/IBM037.gz
  /usr/share/i18n/charmaps/IBM866NAV.gz
  /usr/share/i18n/charmaps/CP1255.gz
  /usr/share/i18n/charmaps/ISO_6937.gz
  /usr/share/i18n/charmaps/IBM256.gz
  /usr/share/i18n/charmaps/CSA_Z243.4-1985-2.gz
  /usr/share/i18n/charmaps/EBCDIC-DK-NO-A.gz
  /usr/share/i18n/charmaps/IBM874.gz
  /usr/share/i18n/charmaps/JUS_I.B1.003-MAC.gz
  /usr/share/i18n/charmaps/ES.gz
  /usr/share/i18n/charmaps/ISO_5427-EXT.gz
  /usr/share/i18n/charmaps/ISO_5427.gz
  /usr/share/i18n/charmaps/KOI8-T.gz
  /usr/share/i18n/charmaps/EBCDIC-PT.gz
  /usr/share/i18n/charmaps/BIG5-HKSCS.gz
  /usr/share/i18n/charmaps/IBM423.gz
  /usr/share/i18n/charmaps/IBM869.gz
  /usr/share/i18n/charmaps/IBM905.gz
  

Re: [yocto] permissions when installing scripts

[Belisko Marek]

Hi Bas,

On Mon, Oct 15, 2018 at 8:45 PM Bas Mevissen  wrote:
>
>
>
> cp -a or --preserve(=) optionally combined with other options
> does the trick. However, using install is the better solution.
But -p will keep current user and not root used when installed in
final rootfs (also QA report warnings about host contamination).
I think I'll stick with install ;). Thanks.
>
>
> -- Bas.
>
> On 2018-10-15 14:35, Burton, Ross wrote:
> > As you've discovered, cp doesn't preserve permissions.  Using install
> > -m755 is the idiom.
> >
> > Ross
> > On Mon, 15 Oct 2018 at 11:12, Belisko Marek 
> > wrote:
> >>
> >> Hi,
> >>
> >> I have package which contains bunch of scripts (with +x flag for
> >> user). When installed in do_install method (simply by copying them to
> >> destination) they loose +x flag. I know copying directly is not best
> >> approach but there exists better way how to keep scripts permissions
> >> like in repo (except calling install -m 755 for all of them)? Thanks.
> >>
> >> BR,
> >>
> >> marek
> >>
> >> --
> >> as simple and primitive as possible
> >> -
> >> Marek Belisko - OPEN-NANDRA
> >> Freelance Developer
> >>
> >> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
> >> Tel: +421 915 052 184
> >> skype: marekwhite
> >> twitter: #opennandra
> >> web: http://open-nandra.com
> >> --
> >> ___
> >> yocto mailing list
> >> yocto@yoctoproject.org
> >> https://lists.yoctoproject.org/listinfo/yocto
>

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] permissions when installing scripts

[Belisko Marek]

Hi,

I have package which contains bunch of scripts (with +x flag for
user). When installed in do_install method (simply by copying them to
destination) they loose +x flag. I know copying directly is not best
approach but there exists better way how to keep scripts permissions
like in repo (except calling install -m 755 for all of them)? Thanks.

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [sumo] systemd install problem when polkit enabled

[Belisko Marek]

Hi,

I'm building core image (with added systemd) for x86 but I hit an
issue when installing systemd
that it fails chown polkitd:root (looks like there was discussion
about this issue here:
https://patchwork.openembedded.org/patch/142904/ but no real
explanation why it sometimes fails). Any ideas what to check? Using
poky sumo. Thanks.

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Display 1920x1080 double LVDS channel problem

[Belisko Marek]

Hello,

On Fri, May 18, 2018 at 11:41 AM Enrico Bonomi 
wrote:

> Hi,

> I'm working with an imx6duallite with Yocto 1.7.3. I want to drive a
1920x1080 display with 2 LVDS channels but i came across a problem.
Pictures are shown correctly on display but they have wrong colors (for
example a blue bar during psplash is shown pink).
This is not yocto specific question. I think you can get more help on
meta-freesc...@yoctoproject.org

> my .dts has the following ldb:

>  {
> ipu_id = <1>;
> disp_id = <0>;
> ext_ref = <1>;
> mode = "sep0";
> sec_ipu_id = <1>;
> sec_disp_id = <1>;
> status = "okay";
> split-mode;

> lvds-channel@0{
> fsl,data-mapping = "spwg";
> fsl,data-width = <24>;
> crtc = "ipu1-di0";
> status = "okay";
> };

> lvds-channel@1{
> fsl,data-mapping = "spwg";
> fsl,data-width = <24>;
> crtc = "ipu1-di0";
> status = "okay";
> };



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

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] wic error during creating sdimg

[Belisko Marek]

Hi,

seems to be caused by empty IMAGE_BOOT_FILES. When added to
machine.conf everything works as expected. Sorry for noise.

On Thu, Jan 11, 2018 at 8:45 PM, Belisko Marek <marek.beli...@gmail.com> wrote:
> Hi,
>
> below error is from wic when creating SD image. I have no clue where
> error can be. I'm portin mender to orangepi and already asked for
> support but seems nobody really understand what is going on. Any help
> appreciated.
>
> error log:
>
> DEBUG: Executing python function set_image_size
> DEBUG: Python function set_image_size finished
> DEBUG: Executing python function extend_recipe_sysroot
> NOTE: Direct dependencies are
> ['virtual:native:/home/marek/projects/orangepi_plus/orange-pi-distro/poky/meta/recipes-devtools/dosfstools/dosfstools_4.1.bb:do_populate_sysroot',
> 'virtual:native:/home/marek/projects/orangepi_plus/orange-pi-distro/poky/meta/recipes-extended/parted/parted_3.2.bb:do_populate_sysroot',
> 'virtual:native:/home/marek/projects/orangepi_plus/orange-pi-distro/poky/meta/recipes-devtools/rsync/rsync_3.1.2.bb:do_populate_sysroot',
> '/home/marek/projects/orangepi_plus/orange-pi-distro/poky/meta/recipes-kernel/kmod/depmodwrapper-cross_1.0.bb:do_populate_sysroot',
> 'virtual:native:/home/marek/projects/orangepi_plus/orange-pi-distro/poky/meta/recipes-devtools/prelink/prelink_git.bb:do_populate_sysroot',
> 'virtual:native:/home/marek/projects/orangepi_plus/orange-pi-distro/poky/meta/recipes-devtools/fdisk/gptfdisk_1.0.3.bb:do_populate_sysroot',
> '/home/marek/projects/orangepi_plus/orange-pi-distro/poky/meta/recipes-devtools/mklibs/mklibs-native_0.1.43.bb:do_populate_sysroot',
> '/home/marek/projects/orangepi_plus/orange-pi-distro/poky/meta/recipes-core/meta/wic-tools.bb:do_populate_sysroot',
> 'virtual:native:/home/marek/projects/orangepi_plus/orange-pi-distro/poky/meta/recipes-devtools/pseudo/pseudo_1.8.2.bb:do_populate_sysroot',
> 'virtual:native:/home/marek/projects/orangepi_plus/orange-pi-distro/poky/meta/recipes-core/update-rc.d/update-rc.d_0.7.bb:do_populate_sysroot',
> '/home/marek/projects/orangepi_plus/orange-pi-distro/poky/meta/recipes-devtools/qemu/qemuwrapper-cross_1.0.bb:do_populate_sysroot',
> 'virtual:native:/home/marek/projects/orangepi_plus/orange-pi-distro/poky/meta/recipes-devtools/mtools/mtools_4.0.18.bb:do_populate_sysroot',
> 'virtual:native:/home/marek/projects/orangepi_plus/orange-pi-distro/poky/meta/recipes-devtools/opkg-utils/opkg-utils_0.3.5.bb:do_populate_sysroot',
> 'virtual:native:/home/marek/projects/orangepi_plus/orange-pi-distro/poky/meta/recipes-devtools/opkg/opkg_0.3.5.bb:do_populate_sysroot',
> 'virtual:native:/home/marek/projects/orangepi_plus/orange-pi-distro/poky/meta/recipes-devtools/makedevs/makedevs_1.0.1.bb:do_populate_sysroot',
> '/home/marek/projects/orangepi_plus/orange-pi-distro/poky/meta/recipes-core/glibc/ldconfig-native_2.12.1.bb:do_populate_sysroot',
> 'virtual:native:/home/marek/projects/orangepi_plus/orange-pi-distro/poky/meta/recipes-extended/pigz/pigz_2.3.4.bb:do_populate_sysroot']
> NOTE: Installed into sysroot: ['dosfstools-native', 'parted-native',
> 'rsync-native', 'gptfdisk-native', 'wic-tools', 'mtools-native',
> 'acl-native']
> NOTE: Skipping as already exists in sysroot: ['depmodwrapper-cross',
> 'prelink-native', 'mklibs-native', 'pseudo-native',
> 'update-rc.d-native', 'qemuwrapper-cross', 'opkg-utils-native',
> 'opkg-native', 'makedevs-native', 'ldconfig-native', 'pigz-native',
> 'gnu-config-native', 'pkgconfig-native', 'quilt-native',
> 'autoconf-native', 'xz-native', 'automake-native', 'libtool-native',
> 'systemd-systemctl-native', 'readline-native', 'util-linux-native',
> 'texinfo-dummy-native', 'gettext-minimal-native', 'ncurses-native',
> 'shadow-native', 'popt-native', 'attr-native', 'nss-native',
> 'elfutils-native', 'binutils-native', 'zlib-native', 'openssl-native',
> 'debianutils-native', 'qemu-native', 'kmod-native',
> 'libarchive-native', 'libsolv-native', 'm4-native', 'lzo-native',
> 'sqlite3-native', 'nspr-native', 'flex-native', 'bison-native',
> 'cryptodev-linux-native', 'makedepend-native', 'pixman-native',
> 'libsdl-native', 'glib-2.0-native', 'alsa-lib-native', 'dtc-native',
> 'gtk-doc-native', 'bzip2-native', 'e2fsprogs-native', 'cmake-native',
> 'expat-native', 'rpm-native', 'util-macros-native', 'xproto-native',
> 'libpng-native', 'libx11-native', 'libxext-native',
> 'libxrandr-native', 'libxrender-native', 'libffi-native',
> 'gettext-native', 'libpcre-native', 'python3-native', 'curl-native',
> 'db-native', 'dbus-native', 'file-native', 'xtrans-native',
> 'inputproto-native', 'xextproto-native', 'kbproto-native',
> 'libxcb-native', 'randrproto-native', 'renderproto-native',
> 'libxdmcp-native', 'xcb-proto-native', 'libpthread-stubs-native',
> 'libxau-native']
> DEBUG: Python function extend_recipe_sysroo

[yocto] wic error during creating sdimg

[Belisko Marek]

Hi,

below error is from wic when creating SD image. I have no clue where
error can be. I'm portin mender to orangepi and already asked for
support but seems nobody really understand what is going on. Any help
appreciated.

error log:

DEBUG: Executing python function set_image_size
DEBUG: Python function set_image_size finished
DEBUG: Executing python function extend_recipe_sysroot
NOTE: Direct dependencies are
['virtual:native:/home/marek/projects/orangepi_plus/orange-pi-distro/poky/meta/recipes-devtools/dosfstools/dosfstools_4.1.bb:do_populate_sysroot',
'virtual:native:/home/marek/projects/orangepi_plus/orange-pi-distro/poky/meta/recipes-extended/parted/parted_3.2.bb:do_populate_sysroot',
'virtual:native:/home/marek/projects/orangepi_plus/orange-pi-distro/poky/meta/recipes-devtools/rsync/rsync_3.1.2.bb:do_populate_sysroot',
'/home/marek/projects/orangepi_plus/orange-pi-distro/poky/meta/recipes-kernel/kmod/depmodwrapper-cross_1.0.bb:do_populate_sysroot',
'virtual:native:/home/marek/projects/orangepi_plus/orange-pi-distro/poky/meta/recipes-devtools/prelink/prelink_git.bb:do_populate_sysroot',
'virtual:native:/home/marek/projects/orangepi_plus/orange-pi-distro/poky/meta/recipes-devtools/fdisk/gptfdisk_1.0.3.bb:do_populate_sysroot',
'/home/marek/projects/orangepi_plus/orange-pi-distro/poky/meta/recipes-devtools/mklibs/mklibs-native_0.1.43.bb:do_populate_sysroot',
'/home/marek/projects/orangepi_plus/orange-pi-distro/poky/meta/recipes-core/meta/wic-tools.bb:do_populate_sysroot',
'virtual:native:/home/marek/projects/orangepi_plus/orange-pi-distro/poky/meta/recipes-devtools/pseudo/pseudo_1.8.2.bb:do_populate_sysroot',
'virtual:native:/home/marek/projects/orangepi_plus/orange-pi-distro/poky/meta/recipes-core/update-rc.d/update-rc.d_0.7.bb:do_populate_sysroot',
'/home/marek/projects/orangepi_plus/orange-pi-distro/poky/meta/recipes-devtools/qemu/qemuwrapper-cross_1.0.bb:do_populate_sysroot',
'virtual:native:/home/marek/projects/orangepi_plus/orange-pi-distro/poky/meta/recipes-devtools/mtools/mtools_4.0.18.bb:do_populate_sysroot',
'virtual:native:/home/marek/projects/orangepi_plus/orange-pi-distro/poky/meta/recipes-devtools/opkg-utils/opkg-utils_0.3.5.bb:do_populate_sysroot',
'virtual:native:/home/marek/projects/orangepi_plus/orange-pi-distro/poky/meta/recipes-devtools/opkg/opkg_0.3.5.bb:do_populate_sysroot',
'virtual:native:/home/marek/projects/orangepi_plus/orange-pi-distro/poky/meta/recipes-devtools/makedevs/makedevs_1.0.1.bb:do_populate_sysroot',
'/home/marek/projects/orangepi_plus/orange-pi-distro/poky/meta/recipes-core/glibc/ldconfig-native_2.12.1.bb:do_populate_sysroot',
'virtual:native:/home/marek/projects/orangepi_plus/orange-pi-distro/poky/meta/recipes-extended/pigz/pigz_2.3.4.bb:do_populate_sysroot']
NOTE: Installed into sysroot: ['dosfstools-native', 'parted-native',
'rsync-native', 'gptfdisk-native', 'wic-tools', 'mtools-native',
'acl-native']
NOTE: Skipping as already exists in sysroot: ['depmodwrapper-cross',
'prelink-native', 'mklibs-native', 'pseudo-native',
'update-rc.d-native', 'qemuwrapper-cross', 'opkg-utils-native',
'opkg-native', 'makedevs-native', 'ldconfig-native', 'pigz-native',
'gnu-config-native', 'pkgconfig-native', 'quilt-native',
'autoconf-native', 'xz-native', 'automake-native', 'libtool-native',
'systemd-systemctl-native', 'readline-native', 'util-linux-native',
'texinfo-dummy-native', 'gettext-minimal-native', 'ncurses-native',
'shadow-native', 'popt-native', 'attr-native', 'nss-native',
'elfutils-native', 'binutils-native', 'zlib-native', 'openssl-native',
'debianutils-native', 'qemu-native', 'kmod-native',
'libarchive-native', 'libsolv-native', 'm4-native', 'lzo-native',
'sqlite3-native', 'nspr-native', 'flex-native', 'bison-native',
'cryptodev-linux-native', 'makedepend-native', 'pixman-native',
'libsdl-native', 'glib-2.0-native', 'alsa-lib-native', 'dtc-native',
'gtk-doc-native', 'bzip2-native', 'e2fsprogs-native', 'cmake-native',
'expat-native', 'rpm-native', 'util-macros-native', 'xproto-native',
'libpng-native', 'libx11-native', 'libxext-native',
'libxrandr-native', 'libxrender-native', 'libffi-native',
'gettext-native', 'libpcre-native', 'python3-native', 'curl-native',
'db-native', 'dbus-native', 'file-native', 'xtrans-native',
'inputproto-native', 'xextproto-native', 'kbproto-native',
'libxcb-native', 'randrproto-native', 'renderproto-native',
'libxdmcp-native', 'xcb-proto-native', 'libpthread-stubs-native',
'libxau-native']
DEBUG: Python function extend_recipe_sysroot finished
DEBUG: Executing shell function do_image_sdimg
+ mkdir -p 
/home/marek/projects/orangepi_plus/orange-pi-distro/build/tmp-glibc/work/orange_pi_pc_plus-oe-linux-gnueabi/opipcplus-minimal/1.0-r0
+ mkdir -p 
/home/marek/projects/orangepi_plus/orange-pi-distro/build/tmp-glibc/work/orange_pi_pc_plus-oe-linux-gnueabi/opipcplus-minimal/1.0-r0/rootfs
+ rm -rf 
/home/marek/projects/orangepi_plus/orange-pi-distro/build/tmp-glibc/work/orange_pi_pc_plus-oe-linux-gnueabi/opipcplus-minimal/1.0-r0/data
+ mkdir -p 

Re: [yocto] Run application at system boot

[Belisko Marek]

Hi,

On Tue, Dec 5, 2017 at 3:21 PM, Laurentiu-Cristian Duca
 wrote:
> Hello yocto community,
>
>   I want to know a few things
> about how to configure yocto such that
> - a simple application (let's say a hello world C program
> from a new recipe) is run at boot time.
depends which init system you're using. By default in yocto there is
sysVInit and basically you need to write simple script which will be
used by sysVInit to start/stop your program
Look here: 
http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-classes-update-rc.d
> - run a kernel module from a simple recipe at boot time
> and automatically build its "/dev/hello" interface file
> (which normally is done by hand using mknod).
Look here: 
http://www.yoctoproject.org/docs/2.4/ref-manual/ref-manual.html#migration-1.7-kernel-module-autoloading
>
>   I appreciate any hint, example or tutorial regarding this questions.
>
> Thank you very much,
> Laurentiu
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] qt4 sdk problem on rocko

[Belisko Marek]

Hi,

I'm porting our layers to latest rocko release. I build SDK to be able
to crosscompile our cmake based application which is using qt4. To
have qt4-tool in sdk I've added:
TOOLCHAIN_HOST_TASK_append = " nativesdk-qt4-tools"

Then in app CMakelists.txt I've use include(FindQt4) but it's barking
with following:
CMake Warning at
/opt/poky/2.4/sysroots/x86_64-pokysdk-linux/usr/share/cmake-3.8/Modules/FindQt4.cmake:618
(message):
  /opt/poky/2.4/sysroots/x86_64-pokysdk-linux/usr/bin/qmake reported
  QT_INSTALL_LIBS as "/opt/poky/2.4/sysroots/x86_64-pokysdk-linux/usr/lib"
  but QtCore could not be found there.  Qt is NOT installed correctly for the
  target build environment.
Call Stack (most recent call first):
  CMakeLists.txt:85 (include)

I did small check and seems that FindQt4 is using some mechanism to
find qmake and then based on qmake --query use variables. Problem is
that qmake -query report this:

/opt/poky/2.4/sysroots/x86_64-pokysdk-linux/usr/bin$ ./qmake -query
QT_INSTALL_PREFIX:/opt/poky/2.4/sysroots/x86_64-pokysdk-linux/usr
QT_INSTALL_DATA:/opt/poky/2.4/sysroots/x86_64-pokysdk-linux/usr
QT_INSTALL_DOCS:/opt/poky/2.4/sysroots/x86_64-pokysdk-linux/usr/doc
QT_INSTALL_HEADERS:/opt/poky/2.4/sysroots/x86_64-pokysdk-linux/usr/include
QT_INSTALL_LIBS:/opt/poky/2.4/sysroots/x86_64-pokysdk-linux/usr/lib
QT_INSTALL_BINS:/opt/poky/2.4/sysroots/x86_64-pokysdk-linux/usr/bin
QT_INSTALL_PLUGINS:/opt/poky/2.4/sysroots/x86_64-pokysdk-linux/usr/plugins
QT_INSTALL_IMPORTS:/opt/poky/2.4/sysroots/x86_64-pokysdk-linux/usr/imports
QT_INSTALL_TRANSLATIONS:/opt/poky/2.4/sysroots/x86_64-pokysdk-linux/usr/translations
QT_INSTALL_CONFIGURATION:/etc/xdg
QT_INSTALL_EXAMPLES:/opt/poky/2.4/sysroots/x86_64-pokysdk-linux/usr/examples
QT_INSTALL_DEMOS:/opt/poky/2.4/sysroots/x86_64-pokysdk-linux/usr/demos
QMAKE_MKSPECS:/opt/poky/2.4/sysroots/x86_64-pokysdk-linux/usr/mkspecs
QMAKE_VERSION:2.01a
QT_VERSION:4.8.7

which is problem because I don't want to link + use included for x86
qt4 but for cross compiled.

Any ideas what to check? Thanks a lot.

BR,

marek


-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] rocko: QA issue with glibc-locale

[Belisko Marek]

Hi Ross,

On Thu, Oct 19, 2017 at 9:42 PM, Belisko Marek <marek.beli...@gmail.com> wrote:
> Hi Ross,
>
> On Thu, Oct 19, 2017 at 9:15 PM, Burton, Ross <ross.bur...@intel.com> wrote:
>> On 19 October 2017 at 12:10, Belisko Marek <marek.beli...@gmail.com> wrote:
>>>
>>> I'm using latest origin/rocko
>>> (65d23bd7986615fdfb0f1717b615534a2a14ab80) with no change to build
>>> beaglebone core-image-minimal. While build I got this QA error:
>>>
>>> ERROR: glibc-locale-2.26-r0 do_package: QA Issue: glibc-locale:
>>> Files/directories were installed but not shipped in any package:
>>>   /usr/share/i18n
>>
>>
>> I've seen this (and some other weird ones) in glibc-locales, and they've
>> always been resolved by just rebuilding the recipe. bitbake glibc-locale
>> -cclean && bitbake glibc-locale might well make it go away.
> OK thanks I'll try and get back with result.
Nope it's not working. Same issue when run above commands. Thanks.
>>
>> Ross
>
> BR,
>
> marek
>
> --
> as simple and primitive as possible
> -
> Marek Belisko - OPEN-NANDRA
> Freelance Developer
>
> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
> Tel: +421 915 052 184
> skype: marekwhite
> twitter: #opennandra
> web: http://open-nandra.com

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] rocko: QA issue with glibc-locale

[Belisko Marek]

Hi Ross,

On Thu, Oct 19, 2017 at 9:15 PM, Burton, Ross <ross.bur...@intel.com> wrote:
> On 19 October 2017 at 12:10, Belisko Marek <marek.beli...@gmail.com> wrote:
>>
>> I'm using latest origin/rocko
>> (65d23bd7986615fdfb0f1717b615534a2a14ab80) with no change to build
>> beaglebone core-image-minimal. While build I got this QA error:
>>
>> ERROR: glibc-locale-2.26-r0 do_package: QA Issue: glibc-locale:
>> Files/directories were installed but not shipped in any package:
>>   /usr/share/i18n
>
>
> I've seen this (and some other weird ones) in glibc-locales, and they've
> always been resolved by just rebuilding the recipe. bitbake glibc-locale
> -cclean && bitbake glibc-locale might well make it go away.
OK thanks I'll try and get back with result.
>
> Ross

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] rocko: QA issue with glibc-locale

[Belisko Marek]

Hi Khem,

On Thu, Oct 19, 2017 at 6:08 PM, Khem Raj <raj.k...@gmail.com> wrote:
> On Thu, Oct 19, 2017 at 4:10 AM, Belisko Marek <marek.beli...@gmail.com> 
> wrote:
>> Hi,
>>
>> I'm using latest origin/rocko
>> (65d23bd7986615fdfb0f1717b615534a2a14ab80) with no change to build
>> beaglebone core-image-minimal. While build I got this QA error:
>>
>
>
> what layers do you use ? and any local changes ?
No local changes. Basically I added to local.conf installation of
bluez5 (as I have in different project issue with bluez5) to verify if
it's working in current rocko branch. So no other changes just bare
poky.
>
>> ERROR: glibc-locale-2.26-r0 do_package: QA Issue: glibc-locale:
>> Files/directories were installed but not shipped in any package:
>>   /usr/share/i18n
>>   /usr/share/i18n/charmaps
>>   /usr/share/i18n/locales
>>   /usr/share/i18n/charmaps/EUC-JISX0213.gz
>>   /usr/share/i18n/charmaps/IBM905.gz
>>   /usr/share/i18n/charmaps/ARMSCII-8.gz
>>   /usr/share/i18n/charmaps/JUS_I.B1.003-SERB.gz
>>   /usr/share/i18n/charmaps/CP1257.gz
>>   /usr/share/i18n/charmaps/EUC-TW.gz
>>   /usr/share/i18n/charmaps/IBM1129.gz
>>   /usr/share/i18n/charmaps/ISO_10646.gz
>>   /usr/share/i18n/charmaps/DS_2089.gz
>>   /usr/share/i18n/charmaps/ISO-8859-1.gz
>>   /usr/share/i18n/charmaps/SHIFT_JISX0213.gz
>>   /usr/share/i18n/charmaps/MACINTOSH.gz
>>   /usr/share/i18n/charmaps/IBM273.gz
>>   /usr/share/i18n/charmaps/ECMA-CYRILLIC.gz
>>   /usr/share/i18n/charmaps/GB_1988-80.gz
>>   /usr/share/i18n/charmaps/IEC_P27-1.gz
>>   /usr/share/i18n/charmaps/PT154.gz
>>   /usr/share/i18n/charmaps/IBM1004.gz
>>   /usr/share/i18n/charmaps/ISO-IR-209.gz
>>   /usr/share/i18n/charmaps/JOHAB.gz
>>   /usr/share/i18n/charmaps/SHIFT_JIS.gz
>>   /usr/share/i18n/charmaps/JIS_X0201.gz
>>   /usr/share/i18n/charmaps/NATS-DANO-ADD.gz
>>   /usr/share/i18n/charmaps/ES2.gz
>>   /usr/share/i18n/charmaps/T.101-G2.gz
>>   /usr/share/i18n/charmaps/IBM424.gz
>>   /usr/share/i18n/charmaps/IBM1164.gz
>>   /usr/share/i18n/charmaps/GEORGIAN-PS.gz
>>   /usr/share/i18n/charmaps/EBCDIC-DK-NO.gz
>>   /usr/share/i18n/charmaps/ISO-8859-7.gz
>>   /usr/share/i18n/charmaps/CP770.gz
>>   /usr/share/i18n/charmaps/BIG5-HKSCS.gz
>>   /usr/share/i18n/charmaps/IBM866.gz
>>   /usr/share/i18n/charmaps/EBCDIC-ES-A.gz
>>   /usr/share/i18n/charmaps/IBM861.gz
>>   /usr/share/i18n/charmaps/EBCDIC-AT-DE-A.gz
>>   /usr/share/i18n/charmaps/WINDOWS-31J.gz
>>   /usr/share/i18n/charmaps/ISO-8859-5.gz
>>   /usr/share/i18n/charmaps/IBM864.gz
>>   /usr/share/i18n/charmaps/EBCDIC-PT.gz
>>   /usr/share/i18n/charmaps/ISO_6937-2-ADD.gz
>>   /usr/share/i18n/charmaps/INIS-CYRILLIC.gz
>>   /usr/share/i18n/charmaps/JIS_C6229-1984-A.gz
>>   /usr/share/i18n/charmaps/IBM038.gz
>>   /usr/share/i18n/charmaps/JIS_C6220-1969-RO.gz
>>   /usr/share/i18n/charmaps/KOI8-R.gz
>>   /usr/share/i18n/charmaps/ISO-8859-11.gz
>>   /usr/share/i18n/charmaps/PT.gz
>>   /usr/share/i18n/charmaps/IBM865.gz
>>   /usr/share/i18n/charmaps/GBK.gz
>>   /usr/share/i18n/charmaps/IBM256.gz
>>   /usr/share/i18n/charmaps/IBM1132.gz
>>   /usr/share/i18n/charmaps/ISO_5427.gz
>>   /usr/share/i18n/charmaps/EBCDIC-CA-FR.gz
>>   /usr/share/i18n/charmaps/IBM290.gz
>>   /usr/share/i18n/charmaps/LATIN-GREEK.gz
>>   /usr/share/i18n/charmaps/IBM1133.gz
>>   /usr/share/i18n/charmaps/ISO_646.BASIC.gz
>>   /usr/share/i18n/charmaps/IBM922.gz
>>   /usr/share/i18n/charmaps/MAC-IS.gz
>>   /usr/share/i18n/charmaps/CP1258.gz
>>   /usr/share/i18n/charmaps/IBM874.gz
>>   /usr/share/i18n/charmaps/IBM856.gz
>>   /usr/share/i18n/charmaps/EBCDIC-ES-S.gz
>>   /usr/share/i18n/charmaps/IBM855.gz
>>   /usr/share/i18n/charmaps/IBM860.gz
>>   /usr/share/i18n/charmaps/IBM1162.gz
>>   /usr/share/i18n/charmaps/IBM275.gz
>>   /usr/share/i18n/charmaps/NC_NC00-10.gz
>>   /usr/share/i18n/charmaps/ISO-8859-9.gz
>>   /usr/share/i18n/charmaps/DIN_66003.gz
>>   /usr/share/i18n/charmaps/TCVN5712-1.gz
>>   /usr/share/i18n/charmaps/ISO-8859-15.gz
>>   /usr/share/i18n/charmaps/CP10007.gz
>>   /usr/share/i18n/charmaps/ISO-IR-197.gz
>>   /usr/share/i18n/charmaps/GB2312.gz
>>   /usr/share/i18n/charmaps/ISO-8859-2.gz
>>   /usr/share/i18n/charmaps/ISO_10367-BOX.gz
>>   /usr/share/i18n/charmaps/IBM037.gz
>>   /usr/share/i18n/charmaps/EBCDIC-AT-DE.gz
>>   /usr/share/i18n/charmaps/MAC-CENTRALEUROPE.gz
>>   /usr/share/i18n/charmaps/CP737.gz
>>   /usr/share/i18n/charmaps/GEORGIAN-ACADEMY.gz
>>   /u

[yocto] rocko: QA issue with glibc-locale

[Belisko Marek]

Hi,

I'm using latest origin/rocko
(65d23bd7986615fdfb0f1717b615534a2a14ab80) with no change to build
beaglebone core-image-minimal. While build I got this QA error:

ERROR: glibc-locale-2.26-r0 do_package: QA Issue: glibc-locale:
Files/directories were installed but not shipped in any package:
  /usr/share/i18n
  /usr/share/i18n/charmaps
  /usr/share/i18n/locales
  /usr/share/i18n/charmaps/EUC-JISX0213.gz
  /usr/share/i18n/charmaps/IBM905.gz
  /usr/share/i18n/charmaps/ARMSCII-8.gz
  /usr/share/i18n/charmaps/JUS_I.B1.003-SERB.gz
  /usr/share/i18n/charmaps/CP1257.gz
  /usr/share/i18n/charmaps/EUC-TW.gz
  /usr/share/i18n/charmaps/IBM1129.gz
  /usr/share/i18n/charmaps/ISO_10646.gz
  /usr/share/i18n/charmaps/DS_2089.gz
  /usr/share/i18n/charmaps/ISO-8859-1.gz
  /usr/share/i18n/charmaps/SHIFT_JISX0213.gz
  /usr/share/i18n/charmaps/MACINTOSH.gz
  /usr/share/i18n/charmaps/IBM273.gz
  /usr/share/i18n/charmaps/ECMA-CYRILLIC.gz
  /usr/share/i18n/charmaps/GB_1988-80.gz
  /usr/share/i18n/charmaps/IEC_P27-1.gz
  /usr/share/i18n/charmaps/PT154.gz
  /usr/share/i18n/charmaps/IBM1004.gz
  /usr/share/i18n/charmaps/ISO-IR-209.gz
  /usr/share/i18n/charmaps/JOHAB.gz
  /usr/share/i18n/charmaps/SHIFT_JIS.gz
  /usr/share/i18n/charmaps/JIS_X0201.gz
  /usr/share/i18n/charmaps/NATS-DANO-ADD.gz
  /usr/share/i18n/charmaps/ES2.gz
  /usr/share/i18n/charmaps/T.101-G2.gz
  /usr/share/i18n/charmaps/IBM424.gz
  /usr/share/i18n/charmaps/IBM1164.gz
  /usr/share/i18n/charmaps/GEORGIAN-PS.gz
  /usr/share/i18n/charmaps/EBCDIC-DK-NO.gz
  /usr/share/i18n/charmaps/ISO-8859-7.gz
  /usr/share/i18n/charmaps/CP770.gz
  /usr/share/i18n/charmaps/BIG5-HKSCS.gz
  /usr/share/i18n/charmaps/IBM866.gz
  /usr/share/i18n/charmaps/EBCDIC-ES-A.gz
  /usr/share/i18n/charmaps/IBM861.gz
  /usr/share/i18n/charmaps/EBCDIC-AT-DE-A.gz
  /usr/share/i18n/charmaps/WINDOWS-31J.gz
  /usr/share/i18n/charmaps/ISO-8859-5.gz
  /usr/share/i18n/charmaps/IBM864.gz
  /usr/share/i18n/charmaps/EBCDIC-PT.gz
  /usr/share/i18n/charmaps/ISO_6937-2-ADD.gz
  /usr/share/i18n/charmaps/INIS-CYRILLIC.gz
  /usr/share/i18n/charmaps/JIS_C6229-1984-A.gz
  /usr/share/i18n/charmaps/IBM038.gz
  /usr/share/i18n/charmaps/JIS_C6220-1969-RO.gz
  /usr/share/i18n/charmaps/KOI8-R.gz
  /usr/share/i18n/charmaps/ISO-8859-11.gz
  /usr/share/i18n/charmaps/PT.gz
  /usr/share/i18n/charmaps/IBM865.gz
  /usr/share/i18n/charmaps/GBK.gz
  /usr/share/i18n/charmaps/IBM256.gz
  /usr/share/i18n/charmaps/IBM1132.gz
  /usr/share/i18n/charmaps/ISO_5427.gz
  /usr/share/i18n/charmaps/EBCDIC-CA-FR.gz
  /usr/share/i18n/charmaps/IBM290.gz
  /usr/share/i18n/charmaps/LATIN-GREEK.gz
  /usr/share/i18n/charmaps/IBM1133.gz
  /usr/share/i18n/charmaps/ISO_646.BASIC.gz
  /usr/share/i18n/charmaps/IBM922.gz
  /usr/share/i18n/charmaps/MAC-IS.gz
  /usr/share/i18n/charmaps/CP1258.gz
  /usr/share/i18n/charmaps/IBM874.gz
  /usr/share/i18n/charmaps/IBM856.gz
  /usr/share/i18n/charmaps/EBCDIC-ES-S.gz
  /usr/share/i18n/charmaps/IBM855.gz
  /usr/share/i18n/charmaps/IBM860.gz
  /usr/share/i18n/charmaps/IBM1162.gz
  /usr/share/i18n/charmaps/IBM275.gz
  /usr/share/i18n/charmaps/NC_NC00-10.gz
  /usr/share/i18n/charmaps/ISO-8859-9.gz
  /usr/share/i18n/charmaps/DIN_66003.gz
  /usr/share/i18n/charmaps/TCVN5712-1.gz
  /usr/share/i18n/charmaps/ISO-8859-15.gz
  /usr/share/i18n/charmaps/CP10007.gz
  /usr/share/i18n/charmaps/ISO-IR-197.gz
  /usr/share/i18n/charmaps/GB2312.gz
  /usr/share/i18n/charmaps/ISO-8859-2.gz
  /usr/share/i18n/charmaps/ISO_10367-BOX.gz
  /usr/share/i18n/charmaps/IBM037.gz
  /usr/share/i18n/charmaps/EBCDIC-AT-DE.gz
  /usr/share/i18n/charmaps/MAC-CENTRALEUROPE.gz
  /usr/share/i18n/charmaps/CP737.gz
  /usr/share/i18n/charmaps/GEORGIAN-ACADEMY.gz
  /usr/share/i18n/charmaps/ISO-8859-9E.gz
  /usr/share/i18n/charmaps/NF_Z_62-010.gz
  /usr/share/i18n/charmaps/CSA_Z243.4-1985-1.gz
  /usr/share/i18n/charmaps/IBM869.gz
  /usr/share/i18n/charmaps/HP-GREEK8.gz
  /usr/share/i18n/charmaps/ANSI_X3.110-1983.gz
  /usr/share/i18n/charmaps/ISO_5428.gz
  /usr/share/i18n/charmaps/GOST_19768-74.gz
  /usr/share/i18n/charmaps/PT2.gz
  /usr/share/i18n/charmaps/MIK.gz
  /usr/share/i18n/charmaps/IBM851.gz
  /usr/share/i18n/charmaps/JIS_C6229-1984-B-ADD.gz
  /usr/share/i18n/charmaps/ISO_6937-2-25.gz
  /usr/share/i18n/charmaps/SEN_850200_C.gz
  /usr/share/i18n/charmaps/MAC-CYRILLIC.gz
  /usr/share/i18n/charmaps/CP1256.gz
  /usr/share/i18n/charmaps/BRF.gz
  /usr/share/i18n/charmaps/GREEK7.gz
  /usr/share/i18n/charmaps/INIS-8.gz
  /usr/share/i18n/charmaps/JIS_C6229-1984-KANA.gz
  /usr/share/i18n/charmaps/EUC-JP.gz
  /usr/share/i18n/charmaps/NS_4551-2.gz
  /usr/share/i18n/charmaps/INVARIANT.gz
  /usr/share/i18n/charmaps/IBM880.gz
  /usr/share/i18n/charmaps/EBCDIC-ES.gz
  /usr/share/i18n/charmaps/IBM277.gz
  /usr/share/i18n/charmaps/BIG5.gz
  /usr/share/i18n/charmaps/IBM297.gz
  /usr/share/i18n/charmaps/IBM866NAV.gz
  /usr/share/i18n/charmaps/IBM903.gz
  /usr/share/i18n/charmaps/KOI-8.gz
  /usr/share/i18n/charmaps/NATS-DANO.gz
  /usr/share/i18n/charmaps/MAC-SAMI.gz
  

[yocto] rocko problem with external cross compilation

[Belisko Marek]

Hi,

we're bumping our layer to latest master (rocko). Previously we use
for development purposes only flow like:
- build image and use sysroot + toolchain for cross compilation (we
use cmake where we setup toolchain file with correct paths and compile
our application)

But when try to use same approach for image build via rocko it always
fail when doing external cross compilation (errors about that cannot
compile simple program -> I checked path for gcc and g++ and they are
correct). Any ideas what to look for appreciated. Thanks a lot.

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Custom FIT image: circular dependencies issue

[Belisko Marek]

Hi Yegor,

On Mon, Aug 7, 2017 at 9:00 AM, Yegor Yefremov
 wrote:
> I've switched to Yocto's master branch from Krogoth and get now
> circular dependencies for my kernel recipe:
>
> ERROR: 502 unbuildable tasks were
> found.#
>
>   | ETA:  0:00:08
> These are usually caused by circular dependencies and any circular
> dependency chains found will be printed below. Increase the debug
> level to see a list of unbuildable tasks.
>
> Identifying dependency loops (this may take a short while)...
>
> ERROR:
> Dependency loop #1 found:
>   Task 
> /home/user/MyProjects/oss/yocto/poky/meta-baltos/recipes-kernel/linux/linux-yocto-custom.bb:do_create_fitimage
> (dependent Tasks ['linux-yocto-custom.bb:do_deploy'])
>   Task 
> /home/user/MyProjects/oss/yocto/poky/meta-baltos/recipes-kernel/linux/linux-yocto-custom.bb:do_packagedata
> (dependent Tasks ['linux-yocto-custom.bb:do_package',
> 'linux-yocto-custom.bb:do_create_fitimage'])
>   Task 
> /home/user/MyProjects/oss/yocto/poky/meta-baltos/recipes-kernel/linux/linux-yocto-custom.bb:do_deploy
> (dependent Tasks ['linux-yocto-custom.bb:do_bundle_initramfs',
> 'depmodwrapper-cross_1.0.bb:do_populate_sysroot',
> 'linux-yocto-custom.bb:do_populate_sysroot',
> 'linux-yocto-custom.bb:do_packagedata'])

This is my just rough explanation why you see this error. As you have
defined task do_create_fitimage before do_packagedata after do_deploy
new circular dependency check added in commit 7821f225 is creating
error showed above. When changing to following everything seems to
works fine:
-addtask create_fitimage before do_packagedata after do_deploy
+
+addtask create_fitimage before do_install after do_compile

As you simply copy its file + create dtb you can create
do_deploy_append method and create those steps there and you don't
need separate task. Hope this helps.
>
>
> ERROR: Command execution failed: 1
>
> My kernel recipe:
>
> inherit kernel
> require recipes-kernel/linux/linux-yocto.inc
>
> python __anonymous () {
> depends = d.getVar("DEPENDS", True)
> depends = "%s u-boot-mkimage-native dtc-native" % depends
> d.setVar("DEPENDS", depends)
> }
>
> do_create_fitimage() {
> cp ${THISDIR}/linux-yocto-custom/kernel-fit.its ${DEPLOY_DIR_IMAGE}
> uboot-mkimage -f ${DEPLOY_DIR_IMAGE}/kernel-fit.its
> ${DEPLOY_DIR_IMAGE}/kernel-fit.itb
> }
>
> addtask create_fitimage before do_packagedata after do_deploy
>
> KBRANCH = "linux-3.18.y"
> KCONFIG_MODE = "--alldefconfig"
>
> SRC_URI = 
> "git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git;protocol=git;bareclone=1;branch=${KBRANCH}"
> SRC_URI += "file://defconfig"
> SRC_URI += "file://baltos.scc \
>"
>
> LINUX_VERSION ?= "3.18"
> LINUX_VERSION_EXTENSION ?= ""
>
> SRCREV="v3.18.32"
>
> PV = "${LINUX_VERSION}+git${SRCPV}"
>
> COMPATIBLE_MACHINE_baltos = "baltos"
>
> Any idea?
>
> Regards,
> Yegor
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Migrating from krogoth to morty (can't boot fitImage)

[Belisko Marek]

Hi Colin,

On Tue, Jul 25, 2017 at 12:21 PM,   wrote:
> I'm trying to migrate my krogoth environment to morty. I have custom recipes
> for u-boot and kernel; the only change necessary to build under morty was to
> patch u-boot for gcc6  - other than that the source versions and configs
> used are the same.
> On krogoth I can boot a fitImage kernel, but not on morty. (uImage works on
> both).
> Looking at the image info on the morty image, it looks like the load/entry
> addresses are completely wrong.
Do you have those variables in your conf: UBOOT_ENTRYPOINT and
UBOOT_LOADADDRESS.
For details please check: meta/classes/kernel-fitimage.bbclass
>
> On krogoth:
> U-Boot > iminfo
>
> ## Checking Image at 1800 ...
>FIT image found
>FIT description: U-Boot fitImage for
> Image 0 (kernel@1)
>  Description:  Linux kernel
>  Type: Kernel Image
>  Compression:  uncompressed
>  Data Start:   0x18e8
>  Data Size:3304552 Bytes = 3.2 MiB
>  Architecture: ARM
>  OS:   Linux
>  Load Address: 0x10008000
>  Entry Point:  0x10008000
>  Hash algo:sha1
>  Hash value:   10a220564569205b11febba4b7e2809395bfee9c
> Image 1 (fdt@1)
>  Description:  Flattened Device Tree blob
>  Type: Flat Device Tree
>  Compression:  uncompressed
>  Data Start:   0x18326e44
>  Data Size:38269 Bytes = 37.4 KiB
>  Architecture: ARM
>  Hash algo:sha1
>  Hash value:   79d5eeb892ef059566c04d98cdc6b30e92a665a2
> Default Configuration: 'conf@1'
> Configuration 0 (conf@1)
>  Description:  Boot Linux kernel with FDT blob
>  Kernel:   kernel@1
>  FDT:  fdt@1
> ## Checking hash(es) for FIT Image at 1800 ...
>Hash(es) for Image 0 (kernel@1): sha1+
>Hash(es) for Image 1 (fdt@1): sha1+
>
> On morty:
> U-Boot > iminfo
>
> ## Checking Image at 1800 ...
>FIT image found
>FIT description: U-Boot fitImage for
> Image 0 (kernel@1)
>  Description:  Linux kernel
>  Type: Kernel Image
>  Compression:  uncompressed
>  Data Start:   0x18e8
>  Data Size:3304016 Bytes = 3.2 MiB
>  Architecture: ARM
>  OS:   Linux
>  Load Address: 0x01314c40   <- doesn't seem like these could be
> correct?
>  Entry Point:  0x01314c40
>  Hash algo:sha1
>  Hash value:   e2de67793e93d854614a42994180b77e053c7302
> Image 1 (fdt@1)
>  Description:  Flattened Device Tree blob
>  Type: Flat Device Tree
>  Compression:  uncompressed
>  Data Start:   0x18326c2c
>  Data Size:38269 Bytes = 37.4 KiB
>  Architecture: ARM
>  Hash algo:sha1
>  Hash value:   79d5eeb892ef059566c04d98cdc6b30e92a665a2
> Default Configuration: 'conf@1'
> Configuration 0 (conf@1)
>  Description:  Linux kernel, FDT blob
>  Kernel:   kernel@1
>  FDT:  fdt@1
> ## Checking hash(es) for FIT Image at 1800 ...
>Hash(es) for Image 0 (kernel@1): sha1+
>Hash(es) for Image 1 (fdt@1): sha1+
>
> Attempting to boot causes it to hang after "Loading Kernel Image ... "
>
> Anyone got any ideas what might be wrong, or where to look to track it down?
> (Any change to mkimage-type steps in morty?)
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Thanks and BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] FriendlyArm Mini6410 ?

[Belisko Marek]

Hi Riko,

On Thu, Jun 15, 2017 at 7:53 AM, Riko Ho  wrote:
> Hello Everyone,
>
> I want to use Yocto for my FriendlyArm Mini6410,
> Where should I begin to start ?
Please read following thread:
https://lists.yoctoproject.org/pipermail/yocto/2014-June/020009.html
>
> Thanks
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] CMake project not building; building from local git repo possible

[Belisko Marek]

Hi Jakob,

On Tue, May 30, 2017 at 11:53 AM, Jakob Hasse
<jakob.ha...@smart-home-technology.ch> wrote:
> Hi Marek,
>
> On 30.05.2017 11:37, Belisko Marek wrote:
>>
>> Hi Jakob,
>>
>> On Tue, May 30, 2017 at 11:28 AM, Jakob Hasse
>> <jakob.ha...@smart-home-technology.ch> wrote:
>>>
>>> Hi Marek,
>>
>> please don't top post http://www.idallen.com/topposting.html :)
>>>
>>> Thanks for your answer!
>>> I did use a local repo folder since I find it more convenient to make
>>> quick
>>> changes that way, as it is the case right now.
>>
>> Source is fetched only once then it's keep in downloads directory so
>> better use then local repo.
>>>
>>> I applied your changes but I still get the same bitbake errors as before,
>>> as
>>> shown below. The CMake Error log says:
>>> ...
>>> error: unrecognized command line option '-Wmissing-variable-declarations'
>>> ...
>>> error: unrecognized command line option '-Wshorten-64-to-32'
>>
>> Can you give me some more info about poky version, target you're building
>> ...
>
>
> Build Configuration:
> BB_VERSION= "1.32.0"
> BUILD_SYS = "x86_64-linux"
> NATIVELSBSTRING   = "universal"
> TARGET_SYS= "arm-dey-linux-gnueabi"
> MACHINE   = "ccimx6ulstarter"
> DISTRO= "dey"
> DISTRO_VERSION= "2.2-r1"
> TUNE_FEATURES = "arm armv7ve vfp thumb neon callconvention-hard
> cortexa7"
> TARGET_FPU= "hard"
>
> We're using the digi embedded yocto here. I think I'll contact their
> support, too.
I think this would be the best ;) as it's probably custom patched build system.
> The arm-dey-linux-gnueabi looks like a normal arm-linux-gnueabi-gcc.
> Please tell me if you think you need more info.
>
> Cheers,
>
> Jakob
>
> --
> Jakob Hasse
> Software Developement
>
> E: jakob.ha...@smart-home-technology.ch
> T: +41 44 552 02 66
>
> Smart Home Technology GmbH
> www.smart-home-technology.ch
>

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] CMake project not building; building from local git repo possible

[Belisko Marek]

Hi Jakob,

On Tue, May 30, 2017 at 11:28 AM, Jakob Hasse
<jakob.ha...@smart-home-technology.ch> wrote:
> Hi Marek,
please don't top post http://www.idallen.com/topposting.html :)
>
> Thanks for your answer!
> I did use a local repo folder since I find it more convenient to make quick
> changes that way, as it is the case right now.
Source is fetched only once then it's keep in downloads directory so
better use then local repo.
>
> I applied your changes but I still get the same bitbake errors as before, as
> shown below. The CMake Error log says:
> ...
> error: unrecognized command line option '-Wmissing-variable-declarations'
> ...
> error: unrecognized command line option '-Wshorten-64-to-32'
Can you give me some more info about poky version, target you're building ...
> ...
>
> I tried to coment out the addition of the corresponding flags (in
> cmake/CFlags.cmake) with no improvement.
>
> Now I compiled with another arm-gcc version (digi embedded version of
> arm-gcc, 6.2.0) and I get a different error -.- :
> | DEBUG: Executing python function sysroot_cleansstate
> | DEBUG: Python function sysroot_cleansstate finished
> | DEBUG: Executing shell function do_configure
> | CMake Error: The source directory
> "/home/jakob/workspace/newuvalue/tmp/work/cortexa7hf-neon-dey-linux-gnueabi/stlink/0.1-r0/git"
> does not appear to contain CMakeLists.txt.
> | Specify --help for usage, or press the help button on the CMake GUI.
> | WARNING: exit code 1 from a shell command.
> | ERROR: Function failed: do_configure (log file is located at
> /home/jakob/workspace/newuvalue/tmp/work/cortexa7hf-neon-dey-linux-gnueabi/stlink/0.1-r0/temp/log.do_configure.3539)
>
> I have no idea why, but in the original source folder the CMakeLists.txt is
> there...
>
> Cheers,
> Jakob
>
>
> On 29.05.2017 21:24, Belisko Marek wrote:
>>
>> Hi Jakob,
>>
>> On Mon, May 29, 2017 at 6:29 PM, Jakob Hasse
>> <jakob.ha...@smart-home-technology.ch> wrote:
>>>
>>> Hello,
>>>
>>> I have two issues:
>>>
>>> 1.
>>> I innocently tried to include an open source version of the ST Link tools
>>> (https://github.com/texane/stlink) into my yocto image.
>>> I created a recipe fetching from git and got the error:
>>>
>>> | CMake Error at CMakeLists.txt:105 (install):
>>> |   install TARGETS given unknown argument "/lib".
>>> |
>>> |
>>> | CMake Error at CMakeLists.txt:135 (install):
>>> |   install TARGETS given unknown argument "/lib".
>>> |
>>> |
>>> | CMake Error at usr/lib/pkgconfig/CMakeLists.txt:12 (install):
>>> |   install FILES given unknown argument "/lib/pkgconfig/".
>>> |
>>> |
>>> | CMake Error at include/CMakeLists.txt:9 (install):
>>> |   install FILES given unknown argument "/lib".
>>> |
>>> |
>>> | CMake Error at include/CMakeLists.txt:12 (install):
>>> |   install FILES given unknown argument "/lib/stlink".
>>>
>>> I'm not sure whether it's a CMake problem since the project compiles
>>> absolutely fine on my host machine with native target (the binary also
>>> works
>>> fine in my case).
>>> Also, the CMake error log shows me errors about unrecognized CFlags
>>> (-Wmissing-variable-declarations, -Wshorten-64-to-32) which confuse me
>>> somewhat given the errors above.
>>> Then I checked out the source and changed the CMake file to exclude
>>> corresponding flags - with no difference, errors still remain.
>>> My recipe now looks like this:
>>>
>>> # comment
>>> SUMMARY = "ST-Link firmware flasher"
>>> DESCRIPTION = ""
>>> SECTION = "examples"
>>> LICENSE = "MIT"
>>> LIC_FILES_CHKSUM =
>>> "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
>>>
>>> DEPENDS = "libusb pkgconfig"
>>>
>>> SRC_URI = "file://stlink.tar.gz"
>>
>> Why don't use git protocol instead of link to fetched sources?
>>>
>>> FILES_${PN} += "${bindir}/st-flash"
>>>
>>> S = "${WORKDIR}/git"
>>
>> Here is my updated recipe:
>>
>> # comment
>> SUMMARY = "ST-Link firmware flasher"
>> DESCRIPTION = ""
>> SECTION = "examples"
>> LICENSE = "MIT"
>> LIC_FILES_CHKSUM =
>> "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
>>
>

Re: [yocto] CMake project not building; building from local git repo possible

[Belisko Marek]

Hi Jakob,

On Mon, May 29, 2017 at 6:29 PM, Jakob Hasse
 wrote:
> Hello,
>
> I have two issues:
>
> 1.
> I innocently tried to include an open source version of the ST Link tools
> (https://github.com/texane/stlink) into my yocto image.
> I created a recipe fetching from git and got the error:
>
> | CMake Error at CMakeLists.txt:105 (install):
> |   install TARGETS given unknown argument "/lib".
> |
> |
> | CMake Error at CMakeLists.txt:135 (install):
> |   install TARGETS given unknown argument "/lib".
> |
> |
> | CMake Error at usr/lib/pkgconfig/CMakeLists.txt:12 (install):
> |   install FILES given unknown argument "/lib/pkgconfig/".
> |
> |
> | CMake Error at include/CMakeLists.txt:9 (install):
> |   install FILES given unknown argument "/lib".
> |
> |
> | CMake Error at include/CMakeLists.txt:12 (install):
> |   install FILES given unknown argument "/lib/stlink".
>
> I'm not sure whether it's a CMake problem since the project compiles
> absolutely fine on my host machine with native target (the binary also works
> fine in my case).
> Also, the CMake error log shows me errors about unrecognized CFlags
> (-Wmissing-variable-declarations, -Wshorten-64-to-32) which confuse me
> somewhat given the errors above.
> Then I checked out the source and changed the CMake file to exclude
> corresponding flags - with no difference, errors still remain.
> My recipe now looks like this:
>
> # comment
> SUMMARY = "ST-Link firmware flasher"
> DESCRIPTION = ""
> SECTION = "examples"
> LICENSE = "MIT"
> LIC_FILES_CHKSUM =
> "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
>
> DEPENDS = "libusb pkgconfig"
>
> SRC_URI = "file://stlink.tar.gz"
Why don't use git protocol instead of link to fetched sources?
>
> FILES_${PN} += "${bindir}/st-flash"
>
> S = "${WORKDIR}/git"
Here is my updated recipe:

# comment
SUMMARY = "ST-Link firmware flasher"
DESCRIPTION = ""
SECTION = "examples"
LICENSE = "MIT"
LIC_FILES_CHKSUM =
"file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"

DEPENDS = "libusb pkgconfig"

SRCREV = "55c057296ad15fa6de9909206098bd4eed8f6311"

PV = "1.3.1+git${SRCPV}"

SRC_URI = "git://github.com/texane/stlink.git"

SRC_URI[md5sum] = "99fa2b1de041f62b7285a8f1870c891b"
SRC_URI[sha256sum] =
"8545752efe2be13c6dbadec48c93cd72be448147f38f0fe44050c0416827ca37"

S = "${WORKDIR}/git"

inherit cmake

Also it is necessary to patch a stlink before to pass configuration phase like:
diff --git a/CMakeLists.txt b/CMakeLists.txt
index afa7fde..4d2db6c 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1,9 +1,10 @@
 cmake_minimum_required(VERSION 2.8.7)
 project(stlink C)
+SET(CMAKE_INSTALL_PREFIX /usr/)
 set(PROJECT_DESCRIPTION "Open source version of the
STMicroelectronics Stlink Tools")
 set(STLINK_UDEV_RULES_DIR "/etc/udev/rules.d" CACHE PATH "Udev rules
directory")
 set(STLINK_MODPROBED_DIR "/etc/modprobe.d" CACHE PATH "modprobe.d directory")
-set(STLINK_LIBRARY_PATH "lib/${CMAKE_LIBRARY_PATH}" CACHE PATH
"Target lib directory")
+set(STLINK_LIBRARY_PATH "${CMAKE_INSTALL_PREFIX}/lib" CACHE PATH
"Target lib directory")

 option(STLINK_GENERATE_MANPAGES "Generate manpages with pandoc" OFF)

diff --git a/include/CMakeLists.txt b/include/CMakeLists.txt
index 0b5a443..e0851e4 100644
--- a/include/CMakeLists.txt
+++ b/include/CMakeLists.txt
@@ -2,13 +2,16 @@ configure_file(
"${PROJECT_SOURCE_DIR}/include/stlink/version.h.in"
"${CMAKE_BINARY_DIR}/include/stlink/version.h"
 )
+
+SET(CMAKE_INSTALL_PREFIX /usr/)
+
 file(GLOB STLINK_HEADERS
"stlink/*.h"
"${CMAKE_BINARY_DIR}/include/stlink/*.h"
 )
 install(FILES ${CMAKE_SOURCE_DIR}/include/stlink.h
-   DESTINATION include/${CMAKE_LIBRARY_PATH}
+   DESTINATION
"${CMAKE_INSTALL_PREFIX}/include/${CMAKE_LIBRARY_PATH}/stlink"
 )
 install(FILES ${STLINK_HEADERS}
-   DESTINATION include/${CMAKE_LIBRARY_PATH}/stlink
+   DESTINATION
"${CMAKE_INSTALL_PREFIX}/include/${CMAKE_LIBRARY_PATH}/stlink"
 )

Then it still fails to compile but I tried to compile it for arm so
maybe this is the reason. Hope it helps a bit ;).

>
> inherit cmake
>
> 2.
> For the last step I had to repack a tar.gz out of the checked out source
> folder, otherwise bitbake complained.
> Is it possible to base a yocto package on a local source folder using
> autotools or cmake class?. All the examples I found either use remote git
> repos + autotools/cmake or a local source folder without autotools/cmake.
>
> Cheers and many thanks in advance,
> Jakob
>
> --
> Jakob Hasse
> Software Developement
>
> E: jakob.ha...@smart-home-technology.ch
> T: +41 44 552 02 66
>
> Smart Home Technology GmbH
> www.smart-home-technology.ch
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA

Re: [yocto] [OE-core] [PATCH] recipes-support: Add recipe for libgpiod

[Belisko Marek]

On Tue, May 9, 2017 at 11:33 PM, Denys Dmytriyenko  wrote:
> Can libsoc help here? It's in meta-oe, but this libgpiod should be there 
> too...
t can but according description sysfs api is deprecated and libgpiod
implementing new gpio interface through char device. Sorry about to
posting to wrong ML.
>
> On Tue, May 09, 2017 at 02:24:18PM -0700, akuster808 wrote:
>> Marek,
>>
>> There is another mailing list that is geared towards the core
>> development and recipes like this that are targeted for the main
>> "meta" layer.
>>
>> You should resend this patch to: openembedded-c...@lists.openembedded.org.
>>
>> regards,
>>
>> Armin
>>
>>
>> On 05/09/2017 02:10 PM, Marek Belisko wrote:
>> >libgpiod - C library and tools for interacting with the linux GPIO
>> >character device
>> >
>> >Since linux 4.8 the GPIO sysfs interface is deprecated.
>> >User space should use the character device instead.
>> >This library encapsulates the ioctl calls and data structures behind a
>> >straightforward API.
>> >
>> >Signed-off-by: Marek Belisko 
>> >---
>> >  meta/recipes-support/libgpiod/libgpiod_0.2.bb | 25 
>> > +
>> >  1 file changed, 25 insertions(+)
>> >  create mode 100644 meta/recipes-support/libgpiod/libgpiod_0.2.bb
>> >
>> >diff --git a/meta/recipes-support/libgpiod/libgpiod_0.2.bb 
>> >b/meta/recipes-support/libgpiod/libgpiod_0.2.bb
>> >new file mode 100644
>> >index 000..fe2cd80
>> >--- /dev/null
>> >+++ b/meta/recipes-support/libgpiod/libgpiod_0.2.bb
>> >@@ -0,0 +1,25 @@
>> >+SUMMARY = "C library and tools for interacting with the linux GPIO 
>> >character device"
>> >+HOMEPAGE = "https://github.com/brgl/libgpiod;
>> >+
>> >+LICENSE = "LGPLv2.1+"
>> >+LIC_FILES_CHKSUM = "file://COPYING;md5=2caced0b25dfefd4c601d92bd15116de"
>> >+
>> >+UPSTREAM_CHECK_URI = "https://github.com/brgl/libgpiod/releases;
>> >+
>> >+SRC_URI = "https://github.com/brgl/libgpiod/archive/v${PV}.tar.gz;
>> >+
>> >+SRC_URI[md5sum] = "e3430f35b6efa842693d659c0bfb7ad5"
>> >+SRC_URI[sha256sum] = 
>> >"de1947f3cb2cc4174364af430309fe6238976658575655bdbd76c60cffa7df92"
>> >+
>> >+inherit autotools pkgconfig
>> >+
>> >+# enable tools
>> >+PACKAGECONFIG ?= "tools"
>> >+
>> >+PACKAGECONFIG[tests] = "--enable-tests,--disable-tests,kmod udev"
>> >+PACKAGECONFIG[tools] = "--enable-tools,--disable-tools,"
>> >+
>> >+PACKAGES += " ${PN}-tools"
>> >+
>> >+FILES_${PN} = "${libdir}/*"
>> >+FILES_${PN}-tools = "${bindir}/*"
>>
>> --
>> ___
>> Openembedded-core mailing list
>> openembedded-c...@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] make[2]: *** No rule to make target 'fitImage'. Stop.

[Belisko Marek]

On Tue, Mar 14, 2017 at 9:53 PM, Robert P. J. Day <rpj...@crashcourse.ca> wrote:
> On Tue, 14 Mar 2017, Belisko Marek wrote:
>
>> Hi Robert,
>>
>> On Tue, Mar 14, 2017 at 9:16 PM, Robert P. J. Day <rpj...@crashcourse.ca> 
>> wrote:
>> > On Mon, 13 Mar 2017, Robert P. J. Day wrote:
>> >
>> >>
>> >>   i'll start a new thread to focus on just this issue. again, building
>> >> core-image-minimal for mpc8315e-rdb, adding this to local.conf:
>> >>
>> >>   INHERIT += "kernel-fitimage" <-- do i need this line?
>> >>   KERNEL_IMAGETYPES_append = " fitImage"
>> >>
>> >> anyway, run:
>> >>
>> >>   $ bitbake virtual/kernel
>> >>
>> >> and eventually get:
>> >>
>> >>   make[2]: *** No rule to make target 'fitImage'.  Stop.
>> >
>> > ... snip ...
>> >
>> >   i would still love to figure out how to generate a simple FIT image
>> > when building core-image-minimal for mpc8315e-rdb.
>> >
>> >   first, based on what i read, my first attempt was to add the
>> > following line to local.conf:
>> >
>> >   KERNEL_IMAGETYPES_append = " fitImage"
>> You need probably also add:
>>
>> KERNEL_CLASSES += "kernel-fitimage"
>>
>> to local.conf
>
>   that *appears* to have solved the problem ... so why is it i didn't
> realize that? where is that written up that i somehow missed it?
It is not documented in yocto manual (I cannot find anything about
fitimage at all), so maybe it could be extended.
>
>   and would it not make sense that selecting FIT image in one variable
> should automatically set the other required variables?
I think something like that can be doable and it will save a lot of
time for people who want's to have it enabled.
>
> rday
>
> --
>
> 
> Robert P. J. Day Ottawa, Ontario, CANADA
> http://crashcourse.ca
>
> Twitter:   http://twitter.com/rpjday
> LinkedIn:   http://ca.linkedin.com/in/rpjday
> 
>

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] make[2]: *** No rule to make target 'fitImage'. Stop.

[Belisko Marek]

Hi Robert,

On Tue, Mar 14, 2017 at 9:16 PM, Robert P. J. Day  wrote:
> On Mon, 13 Mar 2017, Robert P. J. Day wrote:
>
>>
>>   i'll start a new thread to focus on just this issue. again, building
>> core-image-minimal for mpc8315e-rdb, adding this to local.conf:
>>
>>   INHERIT += "kernel-fitimage" <-- do i need this line?
>>   KERNEL_IMAGETYPES_append = " fitImage"
>>
>> anyway, run:
>>
>>   $ bitbake virtual/kernel
>>
>> and eventually get:
>>
>>   make[2]: *** No rule to make target 'fitImage'.  Stop.
>
> ... snip ...
>
>   i would still love to figure out how to generate a simple FIT image
> when building core-image-minimal for mpc8315e-rdb.
>
>   first, based on what i read, my first attempt was to add the
> following line to local.conf:
>
>   KERNEL_IMAGETYPES_append = " fitImage"
You need probably also add:

KERNEL_CLASSES += "kernel-fitimage"

to local.conf
>
> however:
>
>   $ bitbake virtual/kernel
>
>   ... snip ...
>
>   | NOTE: make -j 8 HOSTCC=gcc  HOSTCPP=gcc  -E uImage
>   CC=powerpc-poky-linux-gcc  -fuse-ld=bfd LD=powerpc-poky-linux-ld.bfd
>   | NOTE: make -j 8 HOSTCC=gcc  HOSTCPP=gcc  -E fitImage
>   CC=powerpc-poky-linux-gcc  -fuse-ld=bfd LD=powerpc-poky-linux-ld.bfd
>
>   ... snip ...
>
>   | make[2]: *** No rule to make target 'fitImage'.  Stop.
>   | Makefile:150: recipe for target 'sub-make' failed
>   | make[1]: *** [sub-make] Error 2
>   | Makefile:24: recipe for target '__sub-make' failed
>   | make: *** [__sub-make] Error 2
>
> which makes sense since there is no such target, "fitImage", in the
> kernel build structure.
>
>   what am i screwing up here? how do i generate a simple FIT image?
>
> rday
>
> --
>
> 
> Robert P. J. Day Ottawa, Ontario, CANADA
> http://crashcourse.ca
>
> Twitter:   http://twitter.com/rpjday
> LinkedIn:   http://ca.linkedin.com/in/rpjday
> 
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] live core-image-minimal 'Waiting for removable media ...' problem

[Belisko Marek]

Hi,

I'm adding new bsp layer for x86_64 machine and I successfully build
core-image-minimal. I burn iso file to usb key and after startup I can
see grub options. When choose boot option I can see kernel is booted
and init script from initrd is started but I see only : Waiting for
removable media and that's it (I have CONFIG_DEVTMPFS=y and also
CONFIG_DEVTMPFS_MOUNT=y). Any ideas what to check and why it's not
proceeding. I looked to initscrip and it looks for rootfs.img in
/run/media (maybe run folder doesn't exists?) Using jethro release
(maybe eudev issue?) Many thanks.

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Building on MacOS X

[Belisko Marek]

On Thu, Jan 12, 2017 at 4:39 PM, Tim Orling
 wrote:
> You can also build using Docker containers:
> https://github.com/crops/docker-win-mac-docs/wiki
Well the re is other limitation about slow filesystem access from
docker on osx. There is workaround to use nfs but it's not possible to
use nfs for building yocto - so it's kind of chicken-egg problem ;)
>
> On Jan 12, 2017, at 7:34 AM, Burton, Ross  wrote:
>
>
> On 12 January 2017 at 15:14, Roger Smith  wrote:
>>
>> Is there any documentation for running the Yocto build system on Mac OS X
>> or macOS as Apple now calls it? I am working with the Intel Aero board.
>> Before I go down the rabbit hole of fixing issues like this one (and I am
>> using the bash shell), I’d like to know if anyone has build it on os x
>> before.
>
>
> If you install all of the GNU tools using brew or similar and put them first
> on $PATH then you can get bitbake started.  Then you need to stub out the
> linux-specific bits in bitbake.  I've previously started on this work
> already
> (http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=ross/darwin).
> The next step is figuring out how to configure OE to build and link natively
> on OSX using LLVM instead of GCC.
>
> However all of this is mostly academic because in Sierra (iirc) onwards
> there is tighter security on processes, which means that pseudo won't work
> even if you port it to macOS.
>
> So unless you fancy some non-trivial engineering the short version is just
> use something like Docker to run a Linux system on your Mac.
>
> Ross
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Running an own script after kernel compilation

[Belisko Marek]

Hi,

On Thu, Apr 14, 2016 at 12:12 PM, Yegor Yefremov
 wrote:
> I have my own ITS file, that is required to create a FIT image. ITS
> file has a special configuration, that cannot be automatically created
> using Yocto's recipes. So I need a way to invoke my own script. How
> can I do it?
depends which yocto version you are using but you can use (reuse)
kernel-fitimage.bbclass present in jethro.
which will generate its file from kernel + dts you will define + with
that its will build FIT image. But not sure if it's really what you
need.
>
> Thanks.
>
> Yegor
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] building on os x

[Belisko Marek]

Hi,

I did check internet before asking but there is not much reference. So
sorry for stupid question but it is possible to build e.g.
core-image-minimal on os x natively? I read something about
meta-darwin but I'm not sure if it's what I'm looking for ( IIRC it's
for creating SDK for osx). Anybody tried that? Many thanks.

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] building on os x

[Belisko Marek]

On Mon, Dec 21, 2015 at 12:24 PM, Burton, Ross  wrote:
>
> On 21 December 2015 at 11:09, Jozef Maslik  wrote:
>>
>> Anyway, are there any activities or plans to fix and support osx?
>
>
> Well with El Capitan's improved security apparently crippling LD_PRELOAD (so
> I hear, unverified currently), Pseudo won't work, which means an alternative
> will need to be researched and implemented.  We really recommend using a VM.
> For what it's worth OSX supports hypervisors so something like
> https://github.com/mist64/xhyve is free and should be very efficient.
Ah great. Thanks for all valuable infos.
>
> Ross

BR,

marek


-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] PRINC functionality workaround

[Belisko Marek]

Hi Paul,

On Thu, Nov 26, 2015 at 12:03 PM, Paul Eggleton
<paul.eggle...@linux.intel.com> wrote:
> Hi Marek,
>
> On Thursday 26 November 2015 08:16:51 Belisko Marek wrote:
>> after upgrading to jethro release PRINC functionality was removed by
>> commit : a4d530bcf55f03258078c10a123e2717444e1060 on oe-core. PRINC
>> functionality was used in some of our recipes so I took part from
>> PRINC funtionality and put is to separate method (in bbclass) [0]
>
> You'll have to forgive me for asking the obvious question - why aren't you
> using the PR server?
basically we have some base layer which has e.g. PR="rev123" in bb
recipe. Then we have other layer where we extend functionality
to base recipe (add custom patches) and we was using PRINC so every
change in bbappend has increased PR.
PR is then finally used in our FW update scripts where we update only
when PR is changed.
So I would like to introduce kind of PRINC functionality with my change back.
>
>> I'm trying to use it in bbappend like:
>> inherit veryspecial_helpers
>> PR := ${increase_pr(5)} but this seems to be then evaluated as :
>> u-boot/2015.07-${increase_pr(5)} which is wrong and fails.
>>
>> Any ideas what is wrong with this approach? Maybe some brackets? Many
>> thanks.
>
> missing @ ?
Afters adding @ it complains:
 Failure expanding variable PR[:=], expression was ${@increase_pr(2)}
which triggered exception NameError: global name 'd' is not defined
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] PRINC functionality workaround

[Belisko Marek]

Hi,

after upgrading to jethro release PRINC functionality was removed by
commit : a4d530bcf55f03258078c10a123e2717444e1060 on oe-core. PRINC
functionality was used in some of our recipes so I took part from
PRINC funtionality and put is to separate method (in bbclass) [0]

I'm trying to use it in bbappend like:
inherit veryspecial_helpers
PR := ${increase_pr(5)} but this seems to be then evaluated as :
u-boot/2015.07-${increase_pr(5)} which is wrong and fails.

Any ideas what is wrong with this approach? Maybe some brackets? Many thanks.

[0] - http://pastebin.com/zCbVaBM9

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] fitimage and define multiple configurations

[Belisko Marek]

Hi,

I'm using yocto-1.8 and building minimal image for BBB. I want to use
FIT format for kernel build (to be able run same image on BB andf
BBB). So I changed beaglebone.conf following:

-KERNEL_IMAGETYPE = zImage
+KERNEL_CLASSES += kernel-fitimage
+KERNEL_IMAGETYPE = fitImage
KERNEL_DEVICETREE = am335x-bone.dtb am335x-boneblack.dtb

When build is finished I can see that fit image is build but only with
default configuration (kernel + first dtb).I'm expecting it should do
2 configurations like: kernel + dtb1 and kernel + dtb2. I can
understand it could be problematic when have multiple kernel images.
Is there any possibility to define mapping in conf for configurations?
I quickly check kernel-fitimage.bbclass but it seems it's not. Thanks,

BR,

marek
-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [DYLAN] RPATH issue with qt5's qtwebkit

[Belisko Marek]

Hi All,

On Sat, Aug 24, 2013 at 6:03 PM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
 On Sat, 2013-08-24 at 15:06 +0200, Erik Botö wrote:
 On Sat, Aug 24, 2013 at 3:36 AM, Trevor Woerner
 trevor.woer...@linaro.org wrote:
  Hi,
 
  When I try to include qtwebkit in my image from the dylan branch I end
  up
  with the following QA do_package_qa error [note that this does not happen
  with master]:
 
  ERROR: QA Issue: package qtwebkit contains bad RPATH
  /home/trevor/build/yocto/tmp/dylan/work/armv5te-poky-linux-gnueabi/qtwebkit/5.0.2-r0.0/build/lib
  in file
  /home/trevor/build/yocto/tmp/dylan/work/armv5te-poky-linux-gnueabi/qtwebkit/5.0.2-r0.0/packages-split/qtwebkit/usr/lib/qt5/libexec/QtWebProcess
 
  And the QA test is correct. When I objdump -x this binary I get:
 
  Dynamic Section:
NEEDED   libQt5WebKitWidgets.so.5
NEEDED   libQt5WebKit.so.5
NEEDED   libQt5Widgets.so.5
NEEDED   libQt5Core.so.5
NEEDED   libstdc++.so.6
NEEDED   libc.so.6
RPATH
  /home/trevor/build/yocto/tmp/rdk/work/armv5te-rdk-linux-gnueabi/qtwebkit/5.0.2-r0.0/build/lib
 
  Can anyone suggest any fixes or patches? Note I'm using 5.0.2.

 Try adding a .bbappend with the following content:

 #
 DEPENDS += chrpath-replacement-native
 EXTRANATIVEPATH += chrpath-native

 PRINC := ${@int(PRINC) + 1}

 do_install_append() {
 # Remove rpath from the offending binaries
 chrpath -d ${D}${OE_QMAKE_PATH_LIBEXECS}/QtWebProcess
 }
 #

 That should do it.

 Is this something everyone building qtwebkit is seeing? I had just
 assumed that it had something to do with other changes I do to
 meta-qt5, but if it affect everyone I guess it could be done in
 meta-qt5 instead of local bbappends.

 The above is a workaround, the proper fix is to track down why this is
 making its way in there in the first place and fix the problem at
 source.
Just my 2 cents.
I have similar issue some time ago and I fix it following way (it's
also workaround and maybe help somebody to find correct solution):
---
 Tools/qmake/mkspecs/features/rpath.prf |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Tools/qmake/mkspecs/features/rpath.prf
b/Tools/qmake/mkspecs/features/rpath.prf
index 8dbc42f..487f12f 100644
--- a/Tools/qmake/mkspecs/features/rpath.prf
+++ b/Tools/qmake/mkspecs/features/rpath.prf
@@ -9,13 +9,13 @@ equals(ROOT_BUILD_DIR, $$dirname(DESTDIR)):
RPATHDIR_RELATIVE_TO_DESTDIR = ../li
 linux-*:!isEmpty(RPATHDIR_RELATIVE_TO_DESTDIR) {
 # Do the rpath by hand since it's not possible to use ORIGIN in
QMAKE_RPATHDIR
 # this expands to $ORIGIN (after qmake and make), it does NOT
read a qmake var.
-QMAKE_RPATHDIR = \$\$ORIGIN/$${RPATHDIR_RELATIVE_TO_DESTDIR}
$${QMAKE_RPATHDIR}
+#QMAKE_RPATHDIR = \$\$ORIGIN/$${RPATHDIR_RELATIVE_TO_DESTDIR}
$${QMAKE_RPATHDIR}
 RPATH = $$join(QMAKE_RPATHDIR, :)

-QMAKE_LFLAGS += -Wl,-z,origin \'-Wl,-rpath,$${RPATH}\'
+#QMAKE_LFLAGS += -Wl,-z,origin \'-Wl,-rpath,$${RPATH}\'
 QMAKE_RPATHDIR =
 } else {
-QMAKE_RPATHDIR = $${ROOT_BUILD_DIR}/lib $${QMAKE_RPATHDIR}
+#QMAKE_RPATHDIR = $${ROOT_BUILD_DIR}/lib $${QMAKE_RPATHDIR}
 }

 # FIXME: For Qt5 this will only give correct rpath for the tools that
come with WebKit
-- 
1.7.9.5

 Cheers,

 Richard

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

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] omxplayer building for Rpi

[Belisko Marek]

Hello,

I'm trying to build omxplayer for Rpi board but seems libav and other
dependencies was removed (replaced by meta-oe). But libav was also
removed from meta-oe [1]. I was trying to use patches [2] but it
produce errors:
ERROR: Multiple .bb files are due to be built which each provide
virtual/libgles2
(/home/marek/projects/yocto/1.4.1/poky/meta-raspberrypi/recipes-graphics/userland/userland_git.bb
/home/marek/projects/yocto/1.4.1/poky/meta/recipes-graphics/mesa/mesa_9.0.2.bb).
 This usually means one provides something the other doesn't and should.
ERROR: Multiple .bb files are due to be built which each provide
virtual/egl 
(/home/marek/projects/yocto/1.4.1/poky/meta-raspberrypi/recipes-graphics/userland/userland_git.bb
/home/marek/projects/yocto/1.4.1/poky/meta/recipes-graphics/mesa/mesa_9.0.2.bb).
 This usually means one provides something the other doesn't and should.

Is my procedure correct?
Despite of fact there are error compilation continues.

Thanks,

marek

[1] - 
https://github.com/openembedded/meta-oe/commit/30ba23377ec568a58c43e466582506980b67baad

[2] - http://patches.openembedded.org/patch/55397/

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] MD5SUM recipe error.

[Belisko Marek]

Hi,

On Tue, Aug 20, 2013 at 1:38 PM, Zafrullah Syed
zafrullahme...@gmail.com wrote:
 Hi all,

 I am facing problems while build. Trying to build gumstix-console-image.

 I downloaded GNU hello world, extracted and ran MD5SUM against COPYING,
 added to my bitbake. Still it asks me to add MD5SUM or sha256sum.

 My hello_2.7.bb file is: http://pastebin.com/MDsCcSB9
 Error Log file: http://pastebin.com/ibZDpMZ9

 ERROR: Fetcher failure for URL:
 'ftp://ftp.gnu.org/gnu/hello/hello-2.7.tar.gz'. No checksum specified for
 /home/siguser/yocto/build/downloads/hello-2.7.tar.gz, please add at least
 one to the recipe:
 SRC_URI[md5sum] = fc01b05c7f943d3c42124942a2a9bb3a
 SRC_URI[sha256sum] =
 fd593b5bcf6d1bb6d7d1bb7eefdccdc0010cf2c4985ccb445ef490f768b927c0
It's written here ^^^. Just add those 2 lines to your recipe.
 ERROR: Function failed: Fetcher failure for URL:
 'ftp://ftp.gnu.org/gnu/hello/hello-2.7.tar.gz'. No checksum specified for
 /home/siguser/yocto/build/downloads/hello-2.7.tar.gz, please add at least
 one to the recipe:
 SRC_URI[md5sum] = fc01b05c7f943d3c42124942a2a9bb3a
 SRC_URI[sha256sum] =
 fd593b5bcf6d1bb6d7d1bb7eefdccdc0010cf2c4985ccb445ef490f768b927c0
 ERROR: Logfile of failure stored in:
 /home/siguser/yocto/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/hello-2.7-r0/temp/log.do_fetch.3686
 ERROR: Task 553
 (/home/siguser/yocto/poky/meta-bebot/recipes-bebot/hello/hello_2.7.bb,
 do_fetch) failed with exit code '1'
 NOTE: Tasks Summary: Attempted 3376 tasks of which 3375 didn't need to be
 rerun and 1 failed.
 No currently running tasks (2494 of 3389)




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


BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Fwd:

[Belisko Marek]

http://www.prinzicase.com/qnyigp.php?s=ot

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