Re: [linux-yocto] [linux-yocto-rt v5.0/standard/preempt-rt/base][PATCH 1/1] i915: Use local irq lock instead of irq disable regions
I've refreshed all the 5.0 -rt versions, so this no longer applies.
Can you check the latest changes on the branches and re-send if this
is still required.
Bruce
On Tue, May 28, 2019 at 11:56 PM Liwei Song wrote:
>
> From: Jiping Ma
>
> Use a local_irq_lock as a replacement for irq off regions. We keep
> the semantic of irq-off in regard to the pool->lock and remain preemptible.
>
> BUG: sleeping function called from invalid context at
> kernel/locking/rtmutex.c:974
> in_atomic(): 0, irqs_disabled(): 1, pid: 192, name: systemd-udevd
> CPU: 2 PID: 192 Comm: systemd-udevd Not tainted 4.18.17-rt8-yocto-preempt-rt
> #1
> Hardware name: NUC5i3MYBE, BIOS MYBDWi30.86A.0017.2014.1127.1854 11/27/201
> Call Trace:
> dump_stack+0x4f/0x73
> ? migrate_enable+0x9e/0x3d0
> ___might_sleep.cold.19+0xca/0xdb
> rt_spin_lock+0x37/0x60
> i915_request_retire+0x226/0x4a0 [i915]
> i915_retire_requests+0xa2/0x110 [i915]
> i915_gem_switch_to_kernel_context+0x2c/0x150 [i915]
> ? __i915_request_add+0x27d/0x3f0 [i915]
> i915_gem_init+0x323/0x470 [i915]
> i915_driver_load+0xb3d/0xdf0 [i915]
> i915_pci_probe+0x2b/0x40 [i915]
> local_pci_probe+0x46/0x90
> pci_device_probe+0x119/0x1a0
> driver_probe_device+0x22f/0x300
> __driver_attach+0xbd/0xd0
> ? driver_probe_device+0x300/0x300
> bus_for_each_dev+0x7b/0xc0
> driver_attach+0x1e/0x20
> bus_add_driver+0x1a4/0x1e0
> driver_register+0x70/0xc0
> __pci_register_driver+0x7f/0x90
> ? 0xc02fb000
> i915_init+0x55/0x58 [i915]
> do_one_initcall+0x53/0x236
> ? __might_sleep+0x4a/0x80
> ? kmem_cache_alloc_trace+0x124/0x230
> ? do_init_module+0x27/0x210
> do_init_module+0x60/0x210
> load_module+0x20dc/0x25f0
> ? vfs_read+0x129/0x150
> ? vfs_read+0x129/0x150
> __se_sys_finit_module+0xc3/0xe0
> ? __se_sys_finit_module+0xc3/0xe0
> __x64_sys_finit_module+0x1a/0x20
> do_syscall_64+0x4d/0xf0
> entry_SYSCALL_64_after_hwframe+0x44/0xa9
> RIP: 0033:0x7ff026d71ba9
>
> Signed-off-by: Jiping Ma
> Signed-off-by: Liwei Song
> ---
> drivers/gpu/drm/i915/i915_request.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_request.c
> b/drivers/gpu/drm/i915/i915_request.c
> index ca95ab2f4cfa..4f01dc2ef3b3 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_request.c
> @@ -27,9 +27,12 @@
> #include
> #include
> #include
> +#include
>
> #include "i915_drv.h"
>
> +static DEFINE_LOCAL_IRQ_LOCK(pendingb_lock);
> +
> static const char *i915_fence_get_driver_name(struct dma_fence *fence)
> {
> return "i915";
> @@ -270,6 +273,8 @@ static void free_capture_list(struct i915_request
> *request)
> static void __retire_engine_request(struct intel_engine_cs *engine,
> struct i915_request *rq)
> {
> + unsigned long flags;
> +
> GEM_TRACE("%s(%s) fence %llx:%d, global=%d, current %d\n",
> __func__, engine->name,
> rq->fence.context, rq->fence.seqno,
> @@ -278,7 +283,7 @@ static void __retire_engine_request(struct
> intel_engine_cs *engine,
>
> GEM_BUG_ON(!i915_request_completed(rq));
>
> - local_irq_disable();
> + local_lock_irqsave(pendingb_lock, flags);
>
> spin_lock(>timeline.lock);
> GEM_BUG_ON(!list_is_first(>link, >timeline.requests));
> @@ -296,7 +301,7 @@ static void __retire_engine_request(struct
> intel_engine_cs *engine,
> }
> spin_unlock(>lock);
>
> - local_irq_enable();
> + local_unlock_irqrestore(pendingb_lock, flags);
>
> /*
> * The backing object for the context is done after switching to the
> --
> 2.18.1
>
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] v4.18.x - stable updates comprising v4.18.39
On Thu, May 23, 2019 at 11:09 PM Paul Gortmaker wrote: > > Bruce, Yocto kernel folks: > > Here is the next 4.18.x stable update "extension" primarily created > for the Yocto project, continuing from the previous v4.18.38 release. > > There are about 180 commits here, based on commits chosen from what were > used in the 4.19.39/40/41 stable releases -- so another "batch" release, > if you will. I don't think any one subsystem is over-represented, so we > can count this as a "normal" stable release case. > > Since there isn't anything else news-worthy to report, I'll remind > people once again that these updates will most likely draw to a close > in a few months, so 4.18.x users should start planning accordingly. > > I've put this 4.18.x queue through the usual testing; build testing > on x86-64/32, ARM-64/32, PPC and MIPS, plus some static analysis > and finally some sanity runtime tests on x86-64. > > I did the signed tag just as per the previously released versions. > Please find a signed v4.18.39 tag using this key: > > http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6 > > in the repo in the kernel.org directory here: > > > https://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git/?h=linux-4.18.y > git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git > thanks Paul, this is now merged Bruce > for merge to standard/base in linux-yocto-4.18 and then out from there > into the other base and BSP branches. > > For those who are interested, the evolution of the commits is here: > > https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.18.git/ > > This repo isn't needed for anything; it just exists for transparency and > so people can see the evolution of the raw commits that were originally > selected to create this 4.18.x release. > > Paul. -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [linux-yocto-rt v5.0/standard/preempt-rt/base][PATCH 1/1] genirq: invoke kthread_cancel_work_sync on RT kernel to aviod compile error
I'm doing full updates on the 5.0 -rt at the moment, so I'll pickup
this fix along with the reset of the recent -rt changes upstream.
Bruce
On Thu, May 23, 2019 at 5:55 AM Liwei Song wrote:
>
> fix following compile error:
>
> kernel/irq/manage.c:388:20: error: passing argument 1 of 'cancel_work_sync'
> from incompatible pointer type
>
> The compile error was got with CONFIG_PREEMPT_RT_BASE enabled,
> On RT kernel work_struct was replaced by kthread_work, so here
> we should use kthread_cancel_work_sync() instead of cancel_work_sync()
> to fix it.
>
> Signed-off-by: Liwei Song
> ---
> kernel/irq/manage.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
> index f72bd3a357da..143f87bbff48 100644
> --- a/kernel/irq/manage.c
> +++ b/kernel/irq/manage.c
> @@ -385,7 +385,11 @@ irq_set_affinity_notifier(unsigned int irq, struct
> irq_affinity_notify *notify)
> raw_spin_unlock_irqrestore(>lock, flags);
>
> if (old_notify) {
> +#ifdef CONFIG_PREEMPT_RT_BASE
> + kthread_cancel_work_sync(_notify->work);
> +#else
> cancel_work_sync(_notify->work);
> +#endif
> kref_put(_notify->kref, old_notify->release);
> }
>
> --
> 2.18.1
>
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
[yocto] Python module not found when using autotools
Hi all,
I am trying to write a bitbake file for a project. The project uses
autotools for configuring the project before building it.
While configuring it, it searches for several python modules, where some of
them are custom modules I wrote the bitbake recipe for.
Even though the python module builds and installs correctly to the sysroot
directory, it is not found in the configure step.
python-soundcloud_0.5.0.bb
*---*
*LICENSE = "MIT"LIC_FILES_CHKSUM =
"file://LICENSE;md5=31fa3a9dc818e0087893d63583d2d21a"SRC_URI[md5sum] =
"40c1d32afd019ed11ec1fbee3e84e31f"SRC_URI[sha256sum] =
"aad2003592cec945f835f158f7b41ba8bf805c5738a2fcc5629668ea1df653d5"DEPENDS_${PN}
= "${PYTHON_PN}-modules"PYPI_PACKAGE = "soundcloud"*
*inherit setuptools pypiRDEPENDS_${PN} = "${PYTHON_PN}-modules"*
---
*python-soundcloud is succesfully installed to
"BUILD/sysroots/raspberrypi3/usr/lib/python2.7/site-packages/soundcloud"*
tizonia.bb
---
*SUMMARY = "Tizonia Library"DESCRIPTION = "Tizonia"LICENSE =
"LGPL-3.0"LIC_FILES_CHKSUM =
"file://COPYING.LESSER;md5=e6a600fd5e1d9cbde2d983680233ad02"SRC_URI =
"git://github.com/tizonia/tizonia-openmax-il.git;protocol=https
"SRCREV =
"9004bc40b89eeafb04b28fbb2b772e47dd62fdc9"S = "${WORKDIR}/git"DEPENDS =
"mediainfo log4c python-pip python-soundcloud"*
*inherit autotools ccache pkgconfig pythonnativeRDEPENDS_${PN} = "libstdc++
mediainfo log4c python-soundcloud"EXTRA_OECONF += "-C"*
---
*The error message I get from bitbake:*
*| checking for python2.7... (cached)
/home/developer/build-webos-ose/BUILD/sysroots/x86_64-linux/usr/bin/python-native/python|
checking for a version of Python >= '2.1.0'... yes| checking for a version
of Python >= '2.7'... yes| checking for the distutils Python package...
yes| checking for Python include path...
-I/home/developer/build-webos-ose/BUILD/sysroots/raspberrypi3/usr/include/python2.7|
checking for Python library path...
-L/home/developer/build-webos-ose/BUILD/sysroots/raspberrypi3/usr/lib
-lpython2.7| checking for Python site-packages path...
/home/developer/build-webos-ose/BUILD/sysroots/x86_64-linux/usr/lib/python2.7/site-packages|
checking python extra libraries... -lpthread -ldl -lpthread -lutil -lm|
checking python extra linking flags... -Xlinker -export-dynamic| checking
consistency of all components of python development environment... yes|
checking python module: soundcloud... no| configure: error: failed to find
required module soundcloud*
Does somebody know what I am doing wrong? I cannot figure it out, any help
is appreciated!
Cheers,
Serkan
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] umip: remove umip bbappend
This patch is for meta-cgl Thanks, --Hongzhi On 5/30/19 10:23 AM, Hongzhi.Song wrote: umip has been removed, so its bbappend should be removed too. Signed-off-by: Hongzhi.Song --- meta-cgl-common/recipes-extended/umip/umip_%.bbappend | 1 - 1 file changed, 1 deletion(-) delete mode 100644 meta-cgl-common/recipes-extended/umip/umip_%.bbappend diff --git a/meta-cgl-common/recipes-extended/umip/umip_%.bbappend b/meta-cgl-common/recipes-extended/umip/umip_%.bbappend deleted file mode 100644 index 2858472..000 --- a/meta-cgl-common/recipes-extended/umip/umip_%.bbappend +++ /dev/null @@ -1 +0,0 @@ -PARALLEL_MAKE = "" -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] umip: remove umip bbappend
umip has been removed, so its bbappend should be removed too. Signed-off-by: Hongzhi.Song --- meta-cgl-common/recipes-extended/umip/umip_%.bbappend | 1 - 1 file changed, 1 deletion(-) delete mode 100644 meta-cgl-common/recipes-extended/umip/umip_%.bbappend diff --git a/meta-cgl-common/recipes-extended/umip/umip_%.bbappend b/meta-cgl-common/recipes-extended/umip/umip_%.bbappend deleted file mode 100644 index 2858472..000 --- a/meta-cgl-common/recipes-extended/umip/umip_%.bbappend +++ /dev/null @@ -1 +0,0 @@ -PARALLEL_MAKE = "" -- 2.8.1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto 2.7: SSTATEPOSTUNPACKFUNCS_remove not working
Thanks, not sure I follow: 'SSTATEPOSTUNPACKFUNCS_remove' is not valid any more and previously only worked because there was a bug? Also, what about running bitbake-dumpsig on the task sigdata and finding a line containing "_remove of" (and nothing else) That doesn't seem quite right... Cheers, Wolfgang ‐‐‐ Original Message ‐‐‐ On Wednesday, May 29, 2019 2:27 PM, Richard Purdie wrote: > On Wed, 2019-05-29 at 21:17 +, Wolfgang Tolkien wrote: > > > Hi there, > > I'm upgrading from Yocto 2.5 to 2.7. I have a recipe that (for > > legacy reasons) builds a 32bit "-native" executable. I am disabling > > uninative by setting > > SSTATEPOSTUNPACKFUNCS_remove = "uninative_changeinterp" > > This worked well with Yocto 2.5, but with Yocto 2.7 I'm getting > > ERROR: When reparsing virtual:native:my-32bit- > > recipe_1.0.bb.do_populate_sysroot, the basehash value changed from > > to > > ERROR: When reparsing virtual:native:my-32bit- > > recipe_1.0.bb.do_populate_lic, the basehash value changed from > > to > > ERROR: my-32bit-recipe-native-1.0-r0 do_populate_sysroot: Taskhash > > mismatch versus for virtual:native:my-32bit- > > recipe_1.0.bb.do_populate_sysroot > > [... lots of these...] > > I suspect the reason this appeared is a bugfix in bitbake: > > http://git.yoctoproject.org/cgit.cgi/poky/commit/bitbake?id=f7f5e30667e1ad8e1ca76ee331be2843f2976bfa > > which means this removal is now correctly being accounted for in the > checksum. In your particularly case you were relying on the bug :( > > Cheers, > > Richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto 2.7: SSTATEPOSTUNPACKFUNCS_remove not working
On Wed, 2019-05-29 at 21:17 +, Wolfgang Tolkien wrote: > Hi there, > > I'm upgrading from Yocto 2.5 to 2.7. I have a recipe that (for > legacy reasons) builds a 32bit "-native" executable. I am disabling > uninative by setting > > SSTATEPOSTUNPACKFUNCS_remove = "uninative_changeinterp" > > This worked well with Yocto 2.5, but with Yocto 2.7 I'm getting > > ERROR: When reparsing virtual:native:my-32bit- > recipe_1.0.bb.do_populate_sysroot, the basehash value changed from > to > ERROR: When reparsing virtual:native:my-32bit- > recipe_1.0.bb.do_populate_lic, the basehash value changed from > to > ERROR: my-32bit-recipe-native-1.0-r0 do_populate_sysroot: Taskhash > mismatch versus for virtual:native:my-32bit- > recipe_1.0.bb.do_populate_sysroot > [... lots of these...] I suspect the reason this appeared is a bugfix in bitbake: http://git.yoctoproject.org/cgit.cgi/poky/commit/bitbake?id=f7f5e30667e1ad8e1ca76ee331be2843f2976bfa which means this removal is now correctly being accounted for in the checksum. In your particularly case you were relying on the bug :( Cheers, Richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto 2.7: SSTATEPOSTUNPACKFUNCS_remove not working
Hi there,
I'm upgrading from Yocto 2.5 to 2.7. I have a recipe that (for legacy reasons)
builds a 32bit "-native" executable. I am disabling uninative by setting
SSTATEPOSTUNPACKFUNCS_remove = "uninative_changeinterp"
This worked well with Yocto 2.5, but with Yocto 2.7 I'm getting
ERROR: When reparsing
virtual:native:my-32bit-recipe_1.0.bb.do_populate_sysroot, the basehash value
changed from to
ERROR: When reparsing virtual:native:my-32bit-recipe_1.0.bb.do_populate_lic,
the basehash value changed from to
ERROR: my-32bit-recipe-native-1.0-r0 do_populate_sysroot: Taskhash mismatch
versus for
virtual:native:my-32bit-recipe_1.0.bb.do_populate_sysroot
[... lots of these...]
My debugging efforts so far:
Running 'bitbake-dumpsig 1.0-r0.do_populate_sysroot.sigdata.' on the
failed build I'm seeing:
[...]
Variable RECIPE_SYSROOT_NATIVE value is ${WORKDIR}/recipe-sysroot-native
Variable SSTATECREATEFUNCS value is sstate_hardcode_path
Variable SSTATEPOSTCREATEFUNCS value is
Variable SSTATEPOSTINSTFUNCS value is
Variable SSTATEPOSTUNPACKFUNCS value is sstate_hardcode_path_unpack
_remove of
Variable SSTATE_BUILDDIR value is None
Variable SSTATE_EXTRAPATH value is
Variable SSTATE_INSTDIR value is None
[...]
Note the "_remove of" after the line containing SSTATEPOSTUNPACKFUNCS.
This is not present on Yocto 2.5 and (I'm assuming) is the culprit here.
Unfortunately I don't know where it comes from.
My current solution:
patch uninative.bbclass to prevent it from processing anything other than
x86-64 binaries:
commit a72ed63fc43d1841b6a219cb32a19d48d161904d (HEAD -> warrior)
Author: Wolfgang Tolkien
Date: Wed May 29 14:10:48 2019 -0700
make uninative processing skip non- x86-64 binaries
diff --git a/meta/classes/uninative.bbclass b/meta/classes/uninative.bbclass
index ba99fb6e8f..714d996916 100644
--- a/meta/classes/uninative.bbclass
+++ b/meta/classes/uninative.bbclass
@@ -161,6 +161,8 @@ python uninative_changeinterp () {
continue
if not elf.isDynamic():
continue
+if elf.machine() != 0x3E:
+continue
subprocess.check_output(("patchelf-uninative",
"--set-interpreter", d.getVar("UNINATIVE_LOADER"), f), stderr=subprocess.STDOUT)
}
Any help would be appreciated!
Thanks,
Wolfgang--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [opkg-utils PATCH] Makefile: fixed for-loop in install receipe
From: Joshua DeWeese
The install receipe would have copied all the manpages to each of the
section folders. This change will do what I believe the original
author had intended.
Signed-off-by: Joshua DeWeese
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 69a1c5a..817a8c1 100644
--- a/Makefile
+++ b/Makefile
@@ -23,7 +23,7 @@ install: all
for m in $(MANPAGES); \
do \
install -d $(DESTDIR)$(mandir)/man$${m##*.}; \
- install -m 644 $(MANPAGES) $(DESTDIR)$(mandir)/man$${m##*.}; \
+ install -m 644 "$$m" $(DESTDIR)$(mandir)/man$${m##*.}; \
done
.PHONY: install all
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] prelink-cross with -fno-plt
Hi Mark, Thank you for your reply and no problem -- I chose to benchmark ssh-add with it. It contains no `.plt`. The results are as follows: Without prelink (ran prelink -auv): 26019: 26019: runtime linker statistics: 26019: total startup time in dynamic loader: 1321674 cycles 26019: time needed for relocation: 797948 cycles (60.3%) 26019: number of relocations: 624 26019: number of relocations from cache: 3 26019: number of relative relocations: 9691 26019:time needed to load objects: 389972 cycles (29.5%) Could not open a connection to your authentication agent. 26019: 26019: runtime linker statistics: 26019:final number of relocations: 630 26019: final number of relocations from cache: 3 With prelink (ran prelink -av): 1930: 1930: runtime linker statistics: 1930: total startup time in dynamic loader: 462288 cycles 1930: time needed for relocation: 48730 cycles (10.5%) 1930: number of relocations: 7 1930: number of relocations from cache: 134 1930: number of relative relocations: 0 1930:time needed to load objects: 286076 cycles (61.8%) Could not open a connection to your authentication agent. 1930: 1930: runtime linker statistics: 1930:final number of relocations: 9 1930: final number of relocations from cache: 134 I also tested against execstack, which for sure had the assertion fire on. Without prelink: 27736: 27736: runtime linker statistics: 27736: total startup time in dynamic loader: 1955954 cycles 27736: time needed for relocation: 755440 cycles (38.6%) 27736: number of relocations: 247 27736: number of relocations from cache: 3 27736: number of relative relocations: 1353 27736:time needed to load objects: 710384 cycles (36.3%) /usr/bin/execstack: no files given 27736: 27736: runtime linker statistics: 27736:final number of relocations: 251 27736: final number of relocations from cache: 3 With prelink: 3268: 3268: runtime linker statistics: 3268: total startup time in dynamic loader: 1421206 cycles 3268: time needed for relocation: 199396 cycles (14.0%) 3268: number of relocations: 3 3268: number of relocations from cache: 88 3268: number of relative relocations: 0 3268:time needed to load objects: 696886 cycles (49.0%) /usr/bin/execstack: no files given 3268: 3268: runtime linker statistics: 3268:final number of relocations: 5 3268: final number of relocations from cache: 88 So, it looks like prelink is working on these :) On Tue, May 28, 2019 at 2:57 PM Mark Hatle wrote: > Sorry for my delayed reply. I was out on a business trip. > > Did you try this with the ld.so statistics to see if the relocations were > indeed > reduced at runtime? > > One of my worries with these changes (since I am not an ELF expert either) > is > that we make a change that doesn't actually do anything -- but people > expect it to. > > $ LD_DEBUG=help /lib/ld-linux.so.2 > Valid options for the LD_DEBUG environment variable are: > > libsdisplay library search paths > reloc display relocation processing > files display progress for input file > symbols display symbol table processing > bindingsdisplay information about symbol binding > versionsdisplay version dependencies > scopes display scope information > all all previous options combined > statistics display relocation statistics > unused determined unused DSOs > helpdisplay this help message and exit > > To direct the debugging output into a file instead of standard output > a filename can be specified using the LD_DEBUG_OUTPUT environment variable. > > I believe that it's the 'statistics' option. > > LD_DEBUG=statistics > > Should result in something like: > > 128820: runtime linker statistics: > 128820: total startup time in dynamic loader: 1974661 cycles > 128820: time needed for relocation: 354639 cycles > (17.9%) > 128820: number of relocations: 90 > 128820: number of relocations from cache: 3 > 128820: number of relative relocations: 1201 > 128820:time needed to load objects: 1303654 cycles > (66.0%) > 128820: > 128820: runtime linker statistics: > 128820:final number of relocations: 94 > 128820: final number of relocations from
[yocto] Creating a special file as a dependency., .. how do I cause a recipe to execute
I would like to create a directory structure under TMPDIR as part of the
installation of my bitbake environment... I later create a jffs2 image from
${TMPDIR}/myapptmp/*.
(If it matters, I'm doing this because I want all my proprietary software
installed in a separate partition in the QSPI that gets mounted to a
separate /app directory) on boot.
So, I have my do_install function do things like this:
MY_STAGING_DIR=${TMPDIR}/mytmp
install -d ${MY_STAGING_DIR}
install -d ${MY_STAGING_DIR}/bin
install -d ${MY_STAGING_DIR}/script
...
And my recipe also states things like this:
FILES_${PN} = " \
${TMPDIR}/mytmp \
${TMPDIR}/mytmp /bin \
${TMPDIR}/mytmp /script \
...
However, when I delete this directory and run my recipe's do_install
function, I don't see the temporary directory getting created.
On the other hand, if I edit my recipe (say, to insert debugging to figure
out what is going on) and run it again, I see the temporary directory is
created..
I suppose I could delete the temp directory every time I change code,... if
I remember every time, this would be great. On the other hand, how can I
make the recipe run the do_install when the output object (temp directory)
is not there?
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Building single package as image, respecting dependencies
Hello Paul, thank you for your suggestion. I will look into it. Meanwhile I worked around my issue by building all python3 packages, but excluding them from the rootfs. Then they get installed into a separate 'rootfs', which I pack as a squashfs image. It might not be that elegant, but it works. Regards, NOrman Mit freundlichen Grüßen / Best regards Norman Stetter SW ENWICKLUNG EMBEDDED SYSTEMS Garz & Fricke GmbH 21079 Hamburg Direct: +49 40 791899 - 477 Fax: +49 40 791899 - 39 norman.stet...@garz-fricke.com www.garz-fricke.com WE MAKE IT YOURS! Sitz der Gesellschaft: D-21079 Hamburg Registergericht: Amtsgericht Hamburg, HRB 60514 Geschäftsführer: Matthias Fricke, Manfred Garz, Marc-Michael Braun > -Ursprüngliche Nachricht- > Von: Paul Barker [mailto:p...@betafive.co.uk] > Gesendet: Tuesday, May 28, 2019 11:37 AM > An: Norman Stetter ; Burton, Ross > > Cc: yocto@yoctoproject.org > Betreff: Re: [yocto] Building single package as image, respecting > dependencies > > On 24/05/2019 15:28, Norman Stetter wrote: > > Is there no way to simply force bitbake to only build the packages I > > want, ignoring dependencies? We used to build the image like this > > before, using PTXDist. > > > > Everything else seems to be a dirty hack. > > Can you just collect the extra packages (ipk/deb/rpm as appropriate), put > them in a package feed and install them on-target as required? > > The package feed doesn't have to be on a webserver, you could put it in a > directory in a separate partition on the target if that's what you need. > > Thanks, > > -- > Paul Barker > Managing Director & Principal Engineer > Beta Five Ltd -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-sunxi maintained?
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 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
Re: [yocto] meta-sunxi maintained?
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 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 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
Re: [yocto] Using the SDK and CMAKE GNUInstallDirs for multilib target
Hi,
I found in cmake.bbclass
cmake \
${OECMAKE_GENERATOR_ARGS} \
$oecmake_sitefile \
${OECMAKE_SOURCEPATH} \
-DCMAKE_INSTALL_PREFIX:PATH=${prefix} \
-DCMAKE_INSTALL_BINDIR:PATH=${@os.path.relpath(d.getVar('bindir'),
d.getVar('prefix'))} \
-DCMAKE_INSTALL_SBINDIR:PATH=${@os.path.relpath(d.getVar('sbindir'),
d.getVar('prefix'))} \
-DCMAKE_INSTALL_LIBEXECDIR:PATH=${@os.path.relpath(d.getVar('libexecdir'),
d.getVar('prefix'))} \
-DCMAKE_INSTALL_SYSCONFDIR:PATH=${sysconfdir} \
-DCMAKE_INSTALL_SHAREDSTATEDIR:PATH=${@os.path.relpath(d.getVar('sharedstatedir'),
d. getVar('prefix'))} \
-DCMAKE_INSTALL_LOCALSTATEDIR:PATH=${localstatedir} \
-DCMAKE_INSTALL_LIBDIR:PATH=${@os.path.relpath(d.getVar('libdir'),
d.getVar('prefix'))} \
-DCMAKE_INSTALL_INCLUDEDIR:PATH=${@os.path.relpath(d.getVar('includedir'),
d.getVar('prefix'))} \
-DCMAKE_INSTALL_DATAROOTDIR:PATH=${@os.path.relpath(d.getVar('datadir'),
d.getVar('prefix'))} \
-DCMAKE_INSTALL_SO_NO_EXE=0 \
-DCMAKE_TOOLCHAIN_FILE=${WORKDIR}/toolchain.cmake \
-DCMAKE_NO_SYSTEM_FROM_IMPORTED=1 \
${EXTRA_OECMAKE} \
-Wno-dev
so it looks all CMAKE_INSTALL paths are actually managed by cmake class.
/Måns
Den tis 28 maj 2019 kl 18:47 skrev Måns Zigher :
>
> Hi,
>
> Not really a Yocto question but I am trying to build an application
> using our SDK. We are using CMake to build and are using
> GNUInstallDIrs for managing our install paths. I thought
> GNUInstallDirs should have the detected that the SDK was a multilib
> which it dose in regards to finding packages since it will look for
> libraries under /usr/lib64 but when looking into GNUInstallDirs it
> will explicitly not try and detect if CMAKE_INSTALL_LIBDIR should be
> lib or lib64 when CMAKE_CROSSCOMPILING is set which it is when using
> the SDK. When building the same application in our image build it
> works as expected and GNUInstallDirs will detect that it is a multilib
> dir and install it under /usr/lib64. Could anyone point me to how we
> manage this in poky/OE so I could potentially copy that to our SDK
> build?
>
> BR
> Måns Zigher
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-sunxi maintained?
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 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: >> >> >> > >> >> >> > > >> >> >> >
Re: [yocto] meta-sunxi maintained?
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. Regards, Dimitris 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 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 < > ebut...@users.sourceforge.net> wrote: > >> >> > >> >> On Tue, May 28, 2019 at 12:06 PM Dimitris Tassopoulos < > dimt...@gmail.com> 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,
[yocto] Static gcc library in SDK
Hi all, I need to link some applications with "--static" flag. To do so I need to add some static libraries in the SDK, that I've added with SDKIMAGE_FEATURES_append = " staticdev-pkgs" However, I still miss "libgcc_s.a" and I cannot find a way to add it. Any suggestions? Thanks, Gabriele -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-sunxi maintained?
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'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 >> >>
Re: [yocto] meta-sunxi maintained?
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. 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 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 < > dimt...@gmail.com> 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?
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
[yocto] initramfs in rootfs included
Hello, is it possible to include an initramfs image in the rootfs? If so, how can I do that? I want to create a single image including everything: kernel, device tree, rootfs and initramfs. The initramfs shall contain a custom startup to mount / using overlayfs before calling pivot_root. A single image is important in order to ease the usage of rauc for updates. I know about INITRAMFS_IMAGE_BUNDLE which includes the initramfs into the kernel. This would be great too and creates an kernel containing the initramfs, but unfortunately this kernel is _not_ included in the rootfs, only the kernel without initramfs. I tried creating a custom image, based on core-image-minimal-initramfs, but failed at some point as do_image depends on do_rootfs which depends on do_package. AFAIK the files to install for a package are installed during do_install which come before do_package, so this does not work. So I'm wondering how to get an initramfs image into the rootfs. Best regards, Alexander -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
