Re: [OE-core] [PATCH 2/2] libubootenv: do not use hardcoded lib

2020-01-14 Thread Bedel, Alban
On Tue, 2020-01-14 at 13:56 +0800, Chen Qi wrote:
> 
> +-install (TARGETS ubootenv DESTINATION lib)
> ++install (TARGETS ubootenv DESTINATION ${CMAKE_INSTALL_LIBDIR})
> + install (FILES libuboot.h DESTINATION include)
> + install (TARGETS fw_printenv DESTINATION bin)
> + install (TARGETS fw_setenv DESTINATION bin)

It seems odd to me to not fix all the hard coded install paths at once.
Either fix all of them or add a comment that explain why these should
be hard coded.

Alban


signature.asc
Description: This is a digitally signed message part
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [warrior][PATCH] kernel-uboot: compress arm64 kernels

2019-09-25 Thread Bedel, Alban
On Wed, 2019-09-25 at 08:49 +, Bonnans, Laurent wrote:
> On 9/25/19 2:23 AM, akuster808 wrote:
> 
> > On 9/24/19 12:23 AM, Bedel, Alban wrote:
> > > On Tue, 2019-09-03 at 09:41 +, Bedel, Alban wrote:
> > > > On Wed, 2019-07-31 at 13:53 +, Bedel, Alban wrote:
> > > > > AArch64 images are not self-decompressing, thus usually much
> > > > > larger.
> > > > > Boot times can be reduced by compressing them in FIT and
> > > > > uImages.
> > > > > 
> > > > > This commit is a backport of commit a725d188b5 (kernel-uboot:
> > > > > compress
> > > > > arm64 kernels) and commit 60bc7e180e (kernel-uboot: remove
> > > > > useless
> > > > > special casing of arm64 Image) from master. Both commit were
> > > > > melted
> > > > > into one to avoid some useless churn.
> > > > Was this patch overlooked, or is there a reason it is not
> > > > considered
> > > > in
> > > > the next round of update for warrior? Without this patch kernel
> > > > images
> > > > are too large to fit in the flash of the system I'm using.
> > > > Furthermore
> > > > it is not trivial to fix this in my own layer.
> > > Please, I really like to get an answer here. I'm fine if there is
> > > a
> > > reason why this patch is not considered for warrior, but just
> > > getting
> > > ignored is very frustrating.
> > This appears to be a performance enhancement which does not fall
> > into
> > the criteria for back porting to a stable branch.
> > 
> > - armin
> 
> Just to bring all the elements on the table:
> 
> It's possible to argue that it is more of a fix for a performance 
> regression, as the sub-optimal approach was introduced in
> 1aa417df604d2627c56232a7a2c396c6b085d74b and  the patch
> in question is equivalent to a revert.

Also it is not a question of performance, but of storage space. This
commit effectively broke every board which doesn't have enough storage
for an uncompressed kernel.

> For example, the pyro branch does not seem to have the issue.
> 
> I don't know if it makes a difference in terms of criteria for a 
> backport but I agree that the problem is indeed made worse because it
> is quite hard to override in user layers.

That's exactly my problem, I really don't see how that could be fixed
in my own layer. Furthermore, unlike ARM or X86, ARM64 doesn't support
self decompressing kernel, so that can't be workarounded from the
kernel itself.

Alban


signature.asc
Description: This is a digitally signed message part
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [warrior][PATCH] kernel-uboot: compress arm64 kernels

2019-09-24 Thread Bedel, Alban
On Tue, 2019-09-03 at 09:41 +, Bedel, Alban wrote:
> On Wed, 2019-07-31 at 13:53 +0000, Bedel, Alban wrote:
> > AArch64 images are not self-decompressing, thus usually much
> > larger.
> > Boot times can be reduced by compressing them in FIT and uImages.
> > 
> > This commit is a backport of commit a725d188b5 (kernel-uboot:
> > compress
> > arm64 kernels) and commit 60bc7e180e (kernel-uboot: remove useless
> > special casing of arm64 Image) from master. Both commit were melted
> > into one to avoid some useless churn.
> 
> Was this patch overlooked, or is there a reason it is not considered
> in
> the next round of update for warrior? Without this patch kernel
> images
> are too large to fit in the flash of the system I'm using.
> Furthermore
> it is not trivial to fix this in my own layer.

Please, I really like to get an answer here. I'm fine if there is a
reason why this patch is not considered for warrior, but just getting
ignored is very frustrating.

Alban



signature.asc
Description: This is a digitally signed message part
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [warrior][PATCH] kernel-uboot: compress arm64 kernels

2019-09-03 Thread Bedel, Alban
On Wed, 2019-07-31 at 13:53 +, Bedel, Alban wrote:
> AArch64 images are not self-decompressing, thus usually much larger.
> Boot times can be reduced by compressing them in FIT and uImages.
> 
> This commit is a backport of commit a725d188b5 (kernel-uboot:
> compress
> arm64 kernels) and commit 60bc7e180e (kernel-uboot: remove useless
> special casing of arm64 Image) from master. Both commit were melted
> into one to avoid some useless churn.

Was this patch overlooked, or is there a reason it is not considered in
the next round of update for warrior? Without this patch kernel images
are too large to fit in the flash of the system I'm using. Furthermore
it is not trivial to fix this in my own layer.

Alban

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [OE-Core][warrior][PATCH] rng-tools: start rngd early in the boot process again

2019-09-03 Thread Bedel, Alban
On Fri, 2019-08-23 at 13:41 -0300, Fabio Berton wrote:

> Without this change, images with systemd hang on shutdown/reboot.

I already submitted a patch[1] to fix this which is currently under
review. It is the very same patch with a slightly different log
message as the changes from commit edf7606822 (rng-tools: fix rngd
blocks system shutdown) was not applied on warrior.

Alban

[1]: https://patchwork.openembedded.org/patch/163540/

> On Fri, Aug 23, 2019 at 1:39 PM Fabio Berton
>  wrote:
> > From: "Bedel, Alban" 
> > 
> > It do make sense to start rngd early in the boot process because
> > otherwise we would need to track every service that might need
> > entropy
> > and explicitly configure it to start after rngd.
> > 
> > When used with systemd rngd blocked the shutdown process because it
> > simply missed the proper unit configuration. As the systemd
> > documentation explains, when using DefaultDependencies=no one also
> > have to explicitly configure the unit to properly stop at some
> > point.
> > This is normaly achieved by having Before=shutdown.target and
> > Conflicts=shutdown.target set for the unit.
> > 
> > To have rngd started early again we reverte the changes done to
> > rngd.service in commit edf7606822 (rng-tools: fix rngd blocks
> > system
> > shutdown). To have it properly stopped on shutdown we also add
> > Before=shutdown.target and Conflicts=shutdown.target.
> > 
> > Signed-off-by: Alban Bedel 
> > Signed-off-by: Richard Purdie 
> > (cherry picked from commit
> > a74e7df33e2c8ab2152e3217c0a5df3f65971713)
> > ---
> >  meta/recipes-support/rng-tools/rng-tools/rngd.service | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/meta/recipes-support/rng-tools/rng-tools/rngd.service
> > b/meta/recipes-support/rng-tools/rng-tools/rngd.service
> > index f0355db14fc..5c8253b5fba 100644
> > --- a/meta/recipes-support/rng-tools/rng-tools/rngd.service
> > +++ b/meta/recipes-support/rng-tools/rng-tools/rngd.service
> > @@ -2,7 +2,8 @@
> >  Description=Hardware RNG Entropy Gatherer Daemon
> >  DefaultDependencies=no
> >  After=systemd-udev-settle.service
> > -Before=sysinit.target
> > +Before=sysinit.target shutdown.target
> > +Conflicts=shutdown.target
> > 
> >  [Service]
> >  ExecStart=@SBINDIR@/rngd -f -r /dev/hwrng
> > --
> > 2.20.1
> > 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] QA check for package arch less specific than one of the dependency

2019-09-02 Thread Bedel, Alban
Hi all,

in a layer I'm using I noticed that some recipes used the default
generic architecture although they (build) depend on machine specific
recipes. As far as understand this is generally incorrect, a recipe
should never have a build dependency that has a more specific
architecture than the recipe itself.

Assuming this is correct would it be possible to have a QA check to
verify this? I gave it a shot but didn't found how I could get the
architecture of other recipes, any pointer on how that could be
realised?

Thanks,
Alban Bedel

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [warrior][PATCH] boost: Fix build and enable context and coroutines on aarch64

2019-08-15 Thread Bedel, Alban
Like for ARM bjam need some hints about the ABI to properly build on
aarch64. While at it also enable context and coroutine as these are
supported on aarch64.

Signed-off-by: Alban Bedel 
---
 meta/recipes-support/boost/boost.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-support/boost/boost.inc 
b/meta/recipes-support/boost/boost.inc
index 9be3717fd6..c2e2cbb352 100644
--- a/meta/recipes-support/boost/boost.inc
+++ b/meta/recipes-support/boost/boost.inc
@@ -33,6 +33,7 @@ BOOST_LIBS_append_x86 = " context coroutine"
 BOOST_LIBS_append_x86-64 = " context coroutine"
 BOOST_LIBS_append_powerpc = " context coroutine"
 BOOST_LIBS_append_arm = " context coroutine"
+BOOST_LIBS_append_aarch64 = " context coroutine"
 # need consistent settings for native builds (x86 override not applied for 
native)
 BOOST_LIBS_remove_class-native = " context coroutine"
 # does not compile
@@ -151,6 +152,7 @@ BJAM_OPTS_append_x86-x32 = " abi=x32 address-model=64"
 
 # cross compiling for arm fails to detect abi, so provide some help
 BJAM_OPTS_append_arm = " abi=aapcs architecture=arm"
+BJAM_OPTS_append_aarch64 = " abi=aapcs address-model=64 architecture=arm"
 
 do_configure() {
cp -f ${S}/boost/config/platform/linux.hpp 
${S}/boost/config/platform/linux-gnueabi.hpp
-- 
2.20.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [warrior][PATCH] rng-tools: fix very long shutdown delay with systemd

2019-07-31 Thread Bedel, Alban
The systemd service file has DefaultDependencies=no but is not
properly configured to also stop the unit. Because of this the unit
keep running after shutdown but systemd still waits for it to finish to
then later resort to a hard kill. All this take 1m30s with the default
configuration.

To fix this problem add the missing Before=shutdown.target and
Conflicts=shutdown.target to have systemd stop the unit on shutdown.

Signed-off-by: Alban Bedel 
---
 meta/recipes-support/rng-tools/rng-tools/rngd.service | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-support/rng-tools/rng-tools/rngd.service 
b/meta/recipes-support/rng-tools/rng-tools/rngd.service
index f0355db14f..5c8253b5fb 100644
--- a/meta/recipes-support/rng-tools/rng-tools/rngd.service
+++ b/meta/recipes-support/rng-tools/rng-tools/rngd.service
@@ -2,7 +2,8 @@
 Description=Hardware RNG Entropy Gatherer Daemon
 DefaultDependencies=no
 After=systemd-udev-settle.service
-Before=sysinit.target
+Before=sysinit.target shutdown.target
+Conflicts=shutdown.target
 
 [Service]
 ExecStart=@SBINDIR@/rngd -f -r /dev/hwrng
-- 
2.20.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [warrior][PATCH] kernel-uboot: compress arm64 kernels

2019-07-31 Thread Bedel, Alban
AArch64 images are not self-decompressing, thus usually much larger.
Boot times can be reduced by compressing them in FIT and uImages.

This commit is a backport of commit a725d188b5 (kernel-uboot: compress
arm64 kernels) and commit 60bc7e180e (kernel-uboot: remove useless
special casing of arm64 Image) from master. Both commit were melted
into one to avoid some useless churn.

Signed-off-by: Alban Bedel 
---
 meta/classes/kernel-uboot.bbclass | 4 
 1 file changed, 4 deletions(-)

diff --git a/meta/classes/kernel-uboot.bbclass 
b/meta/classes/kernel-uboot.bbclass
index 2364053f31..87f02654fa 100644
--- a/meta/classes/kernel-uboot.bbclass
+++ b/meta/classes/kernel-uboot.bbclass
@@ -3,10 +3,6 @@ uboot_prep_kimage() {
vmlinux_path="arch/${ARCH}/boot/compressed/vmlinux"
linux_suffix=""
linux_comp="none"
-   elif [ -e arch/${ARCH}/boot/Image ] ; then
-   vmlinux_path="vmlinux"
-   linux_suffix=""
-   linux_comp="none"
elif [ -e arch/${ARCH}/boot/vmlinuz.bin ]; then
rm -f linux.bin
cp -l arch/${ARCH}/boot/vmlinuz.bin linux.bin
-- 
2.20.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] kernel-uboot: remove useless special casing of arm64 Image

2019-07-23 Thread Bedel, Alban
Since commit a725d188b5 (kernel-uboot: compress arm64 kernels)
arm64 Image files are handled exactly like in the default case, making
this special case pointless. Remove it to make the code simpler.

Signed-off-by: Alban Bedel 
---
 meta/classes/kernel-uboot.bbclass | 4 
 1 file changed, 4 deletions(-)

diff --git a/meta/classes/kernel-uboot.bbclass 
b/meta/classes/kernel-uboot.bbclass
index 0457c5d1d1..87f02654fa 100644
--- a/meta/classes/kernel-uboot.bbclass
+++ b/meta/classes/kernel-uboot.bbclass
@@ -3,10 +3,6 @@ uboot_prep_kimage() {
vmlinux_path="arch/${ARCH}/boot/compressed/vmlinux"
linux_suffix=""
linux_comp="none"
-   elif [ -e arch/${ARCH}/boot/Image ] ; then
-   vmlinux_path="vmlinux"
-   linux_suffix=".gz"
-   linux_comp="gzip"
elif [ -e arch/${ARCH}/boot/vmlinuz.bin ]; then
rm -f linux.bin
cp -l arch/${ARCH}/boot/vmlinuz.bin linux.bin
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] rng-tools: start rngd early in the boot process again

2019-07-23 Thread Bedel, Alban
It do make sense to start rngd early in the boot process because
otherwise we would need to track every service that might need entropy
and explicitly configure it to start after rngd.

When used with systemd rngd blocked the shutdown process because it
simply missed the proper unit configuration. As the systemd
documentation explains, when using DefaultDependencies=no one also
have to explicitly configure the unit to properly stop at some point.
This is normaly achieved by having Before=shutdown.target and
Conflicts=shutdown.target set for the unit.

To have rngd started early again we reverte the changes done to
rngd.service in commit edf7606822 (rng-tools: fix rngd blocks system
shutdown). To have it properly stopped on shutdown we also add
Before=shutdown.target and Conflicts=shutdown.target.

Signed-off-by: Alban Bedel 
---
 meta/recipes-support/rng-tools/rng-tools/rngd.service | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/recipes-support/rng-tools/rng-tools/rngd.service 
b/meta/recipes-support/rng-tools/rng-tools/rngd.service
index 49d5de294f..a29074 100644
--- a/meta/recipes-support/rng-tools/rng-tools/rngd.service
+++ b/meta/recipes-support/rng-tools/rng-tools/rngd.service
@@ -1,5 +1,9 @@
 [Unit]
 Description=Hardware RNG Entropy Gatherer Daemon
+DefaultDependencies=no
+After=systemd-udev-settle.service
+Before=sysinit.target shutdown.target
+Conflicts=shutdown.target
 
 [Service]
 EnvironmentFile=-@SYSCONFDIR@/default/rng-tools
-- 
2.20.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] boost: Fix build and enable context and coroutines on aarch64

2019-07-18 Thread Bedel, Alban
Like for ARM bjam need some hints about the ABI to properly build on
aarch64. While at it also enable context and coroutine as these are
supported on aarch64.

Signed-off-by: Alban Bedel 
---
 meta/recipes-support/boost/boost.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-support/boost/boost.inc 
b/meta/recipes-support/boost/boost.inc
index 9be3717fd6..c2e2cbb352 100644
--- a/meta/recipes-support/boost/boost.inc
+++ b/meta/recipes-support/boost/boost.inc
@@ -33,6 +33,7 @@ BOOST_LIBS_append_x86 = " context coroutine"
 BOOST_LIBS_append_x86-64 = " context coroutine"
 BOOST_LIBS_append_powerpc = " context coroutine"
 BOOST_LIBS_append_arm = " context coroutine"
+BOOST_LIBS_append_aarch64 = " context coroutine"
 # need consistent settings for native builds (x86 override not applied for 
native)
 BOOST_LIBS_remove_class-native = " context coroutine"
 # does not compile
@@ -151,6 +152,7 @@ BJAM_OPTS_append_x86-x32 = " abi=x32 address-model=64"
 
 # cross compiling for arm fails to detect abi, so provide some help
 BJAM_OPTS_append_arm = " abi=aapcs architecture=arm"
+BJAM_OPTS_append_aarch64 = " abi=aapcs address-model=64 architecture=arm"
 
 do_configure() {
cp -f ${S}/boost/config/platform/linux.hpp 
${S}/boost/config/platform/linux-gnueabi.hpp
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core