Date   

netkit-ftp for yocto

lavkhush2208@...
 

Hello Guys
I have installed netkit-ftp-0.17-r0 version successfully but i am not able to get -4 and -6 option with using ftp -help

$ ftp -help
   Usage: { ftp | pftp } [-46pinegvtd] [hostname]

       -p: enable passive mode (default for pftp)
       -i: turn off prompting during mget
       -n: inhibit auto-login
       -e: disable readline support, if present
       -g: disable filename globbing
       -v: verbose mode
       -t: enable packet tracing [nonfunctional]
       -d: enable debugging

not getting ipv4 and ipv6 option
       -4: use IPv4 addresses only
       -6: use IPv6, nothing else

if some package or something is missing, please update me so that i can modify.

T&R
lavkhush


Re: [meta-raspberrypi][PATCH] xserver-xorg: remove xshmfence configure option

Khem Raj
 



On Wed, Dec 8, 2021 at 7:03 PM Yu, Mingli <mingli.yu@...> wrote:
From: Mingli Yu <mingli.yu@...>

After the commit [1] introduced in openembedded-core layer,
some configure options is't carried over include xshmfence
option, so remove the xshmfence configure option to silence
the below warning.
  WARNING: xserver-xorg-2_21.1.1-r0 do_configure: QA Issue: xserver-xorg: invalid PACKAGECONFIG: xshmfence [invalid-packageconfig]

That’s ok to remove it but more importantly does it work now without this option 

[1] https://git.openembedded.org/openembedded-core/commit/?id=e05abd87ee5d23750c641d0129d9c83db68ee2e8

Signed-off-by: Mingli Yu <mingli.yu@...>
---
 recipes-graphics/xorg-xserver/xserver-xorg_%.bbappend | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-graphics/xorg-xserver/xserver-xorg_%.bbappend b/recipes-graphics/xorg-xserver/xserver-xorg_%.bbappend
index 25829c2..ee4812f 100644
--- a/recipes-graphics/xorg-xserver/xserver-xorg_%.bbappend
+++ b/recipes-graphics/xorg-xserver/xserver-xorg_%.bbappend
@@ -1,4 +1,4 @@
-OPENGL_PKGCONFIGS:rpi = "dri glx ${@bb.utils.contains('MACHINE_FEATURES', 'vc4graphics', 'dri3 xshmfence glamor', '', d)}"
+OPENGL_PKGCONFIGS:rpi = "dri glx ${@bb.utils.contains('MACHINE_FEATURES', 'vc4graphics', 'dri3 glamor', '', d)}"

 # when using userland graphic KHR/khrplatform.h is provided by userland but virtual/libgl is provided by mesa-gl where
 # we explicitly delete KHR/khrplatform.h since its already coming from userland package
--
2.17.1





[meta-raspberrypi][PATCH] xserver-xorg: remove xshmfence configure option

Yu, Mingli
 

From: Mingli Yu <mingli.yu@...>

After the commit [1] introduced in openembedded-core layer,
some configure options is't carried over include xshmfence
option, so remove the xshmfence configure option to silence
the below warning.
WARNING: xserver-xorg-2_21.1.1-r0 do_configure: QA Issue: xserver-xorg: invalid PACKAGECONFIG: xshmfence [invalid-packageconfig]

[1] https://git.openembedded.org/openembedded-core/commit/?id=e05abd87ee5d23750c641d0129d9c83db68ee2e8

Signed-off-by: Mingli Yu <mingli.yu@...>
---
recipes-graphics/xorg-xserver/xserver-xorg_%.bbappend | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-graphics/xorg-xserver/xserver-xorg_%.bbappend b/recipes-graphics/xorg-xserver/xserver-xorg_%.bbappend
index 25829c2..ee4812f 100644
--- a/recipes-graphics/xorg-xserver/xserver-xorg_%.bbappend
+++ b/recipes-graphics/xorg-xserver/xserver-xorg_%.bbappend
@@ -1,4 +1,4 @@
-OPENGL_PKGCONFIGS:rpi = "dri glx ${@bb.utils.contains('MACHINE_FEATURES', 'vc4graphics', 'dri3 xshmfence glamor', '', d)}"
+OPENGL_PKGCONFIGS:rpi = "dri glx ${@bb.utils.contains('MACHINE_FEATURES', 'vc4graphics', 'dri3 glamor', '', d)}"

# when using userland graphic KHR/khrplatform.h is provided by userland but virtual/libgl is provided by mesa-gl where
# we explicitly delete KHR/khrplatform.h since its already coming from userland package
--
2.17.1


Re: [meta-rockchip][PATCH] u-boot: Replace virtual/trusted-firmware-a with trusted-firmware-a

Khem Raj
 



On Wed, Dec 8, 2021 at 6:03 PM Trevor Woerner <twoerner@...> wrote:
On Wed 2021-12-08 @ 01:15:26 PM, Khem Raj wrote:
> meta-arm has dropped exporting virtual/trusted-firmware-a and expects
> direct use of trusted-firmware-a on depends sections
>
> Signed-off-by: Khem Raj <raj.khem@...>
> ---
>  recipes-bsp/u-boot/u-boot%.bbappend | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Oops, looks like we both noticed this at about the same time.
Since both our patches are identical, I simply added your SoB line.

Cool



Thanks!


Re: [meta-rockchip][PATCH] u-boot: remove "virtual" keyword in dependency

Trevor Woerner
 

On Wed 2021-12-08 @ 03:29:14 PM, Trevor Woerner wrote:
The latest trusted-firmware-a recipe in meta-arm no longer considers
trusted-firmware-a to have potentially multiple providers.

Signed-off-by: Trevor Woerner <twoerner@...>
---
recipes-bsp/u-boot/u-boot%.bbappend | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Applied to meta-rockchip (with Khem's SoB added) master.


Re: [meta-rockchip][PATCH] u-boot: Replace virtual/trusted-firmware-a with trusted-firmware-a

Trevor Woerner
 

On Wed 2021-12-08 @ 01:15:26 PM, Khem Raj wrote:
meta-arm has dropped exporting virtual/trusted-firmware-a and expects
direct use of trusted-firmware-a on depends sections

Signed-off-by: Khem Raj <raj.khem@...>
---
recipes-bsp/u-boot/u-boot%.bbappend | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Oops, looks like we both noticed this at about the same time.
Since both our patches are identical, I simply added your SoB line.

Thanks!


Re: [meta-rockchip][PATCH] trusted-firmware-a: Drop 0001-Fix-build-with-gcc-11.patch

Trevor Woerner
 

On Wed 2021-12-08 @ 11:54:04 AM, Khem Raj wrote:
This has been included upstream see [1]

[1] https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/+/f943b7c8e292e3aad2fcbdd0a37505f62b3b4c87%5E%21/#F0

Signed-off-by: Khem Raj <raj.khem@...>
---
.../files/0001-Fix-build-with-gcc-11.patch | 34 -------------------
.../trusted-firmware-a_%.bbappend | 1 -
2 files changed, 35 deletions(-)
delete mode 100644 recipes-bsp/trusted-firmware-a/files/0001-Fix-build-with-gcc-11.patch
Applied to meta-rockchip master. Thanks!


Re: [docs] [PATCH yocto-autobuilder-helper] scripts/run-docs-build: stop using the "transition" branch

Tim Orling
 



On Wed, Dec 8, 2021 at 2:08 PM Nicolas Dechesne <nicolas.dechesne@...> wrote:


On Wed, Dec 8, 2021 at 10:57 PM Michael Opdenacker <michael.opdenacker@...> wrote:
Quentin, Nico,

On 12/3/21 11:51 AM, Quentin Schulz wrote:
>
> I think all our issues always come down to this weird and inefficient
> organization we have for docs and common files between doc releases.
> We'll need to settle on something one day because I don't think what
> we're doing today is working :/


Thanks for your reviews. Good to know that the "transition" branch is
still in use in spite of what I wrongly believed.
It indeed, it's a good idea to see what other projects are doing. Maybe
what we are doing is unnecessarily complicated.

Look at Python docs (https://docs.python.org/) for example. They have a
switcher as we do, and also a left bar the latest versions and a
separate page for all versions. However, such versions are only shown on
the top page. When you enter one of the documents though for a given
version, the left bar is used for navigation between sections instead,
and you no longer have references to other versions.

docs.pythong.org is where we stole the idea of the switcher ;-) 
Would anyone be able to figure out if their 'publishing' script is available anywhere? if we could mimic that somehow that might be good. 

 

Let's keep thinking about this, to find an easier to manage solution.
Thanks again
Michael.

--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com





Re: [docs] [PATCH yocto-autobuilder-helper] scripts/run-docs-build: stop using the "transition" branch

Nicolas Dechesne
 



On Wed, Dec 8, 2021 at 10:57 PM Michael Opdenacker <michael.opdenacker@...> wrote:
Quentin, Nico,

On 12/3/21 11:51 AM, Quentin Schulz wrote:
>
> I think all our issues always come down to this weird and inefficient
> organization we have for docs and common files between doc releases.
> We'll need to settle on something one day because I don't think what
> we're doing today is working :/


Thanks for your reviews. Good to know that the "transition" branch is
still in use in spite of what I wrongly believed.
It indeed, it's a good idea to see what other projects are doing. Maybe
what we are doing is unnecessarily complicated.

Look at Python docs (https://docs.python.org/) for example. They have a
switcher as we do, and also a left bar the latest versions and a
separate page for all versions. However, such versions are only shown on
the top page. When you enter one of the documents though for a given
version, the left bar is used for navigation between sections instead,
and you no longer have references to other versions.

docs.pythong.org is where we stole the idea of the switcher ;-) 
Would anyone be able to figure out if their 'publishing' script is available anywhere? if we could mimic that somehow that might be good. 
 

Let's keep thinking about this, to find an easier to manage solution.
Thanks again
Michael.

--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


Re: [docs] [PATCH yocto-autobuilder-helper] scripts/run-docs-build: stop using the "transition" branch

Michael Opdenacker
 

Quentin, Nico,

On 12/3/21 11:51 AM, Quentin Schulz wrote:

I think all our issues always come down to this weird and inefficient
organization we have for docs and common files between doc releases.
We'll need to settle on something one day because I don't think what
we're doing today is working :/

Thanks for your reviews. Good to know that the "transition" branch is
still in use in spite of what I wrongly believed.
It indeed, it's a good idea to see what other projects are doing. Maybe
what we are doing is unnecessarily complicated.

Look at Python docs (https://docs.python.org/) for example. They have a
switcher as we do, and also a left bar the latest versions and a
separate page for all versions. However, such versions are only shown on
the top page. When you enter one of the documents though for a given
version, the left bar is used for navigation between sections instead,
and you no longer have references to other versions.

Let's keep thinking about this, to find an easier to manage solution.
Thanks again
Michael.

--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


[meta-rockchip][PATCH] u-boot: Replace virtual/trusted-firmware-a with trusted-firmware-a

Khem Raj
 

meta-arm has dropped exporting virtual/trusted-firmware-a and expects
direct use of trusted-firmware-a on depends sections

Signed-off-by: Khem Raj <raj.khem@...>
---
recipes-bsp/u-boot/u-boot%.bbappend | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-bsp/u-boot/u-boot%.bbappend b/recipes-bsp/u-boot/u-boot%.bbappend
index 7916e45..9108a36 100644
--- a/recipes-bsp/u-boot/u-boot%.bbappend
+++ b/recipes-bsp/u-boot/u-boot%.bbappend
@@ -8,9 +8,9 @@ do_compile:append:rock2-square () {
ATF_DEPENDS ??= ""

EXTRA_OEMAKE:append:rk3399 = " BL31=${DEPLOY_DIR_IMAGE}/bl31-rk3399.elf"
-ATF_DEPENDS:rk3399 = " virtual/trusted-firmware-a:do_deploy"
+ATF_DEPENDS:rk3399 = " trusted-firmware-a:do_deploy"
EXTRA_OEMAKE:append:rk3328 = " BL31=${DEPLOY_DIR_IMAGE}/bl31-rk3328.elf"
-ATF_DEPENDS:rk3328 = " virtual/trusted-firmware-a:do_deploy"
+ATF_DEPENDS:rk3328 = " trusted-firmware-a:do_deploy"

do_compile[depends] .= "${ATF_DEPENDS}"

--
2.34.1


Re: Trouble building core-image-minimal-initramfs for j7-evm target #grub

Tom Rini
 

On Wed, Dec 08, 2021 at 12:06:49PM -0800, chiefsleepyeye@... wrote:
I'm on the "dunfell" branch and trying to build core-image-minimal-initramfs for a j7-evm target.  When I do that I get the following error:


* Solver encountered 1 problem(s):
* Problem 1/1:
*   - nothing provides grub needed by
initramfs-module-install-1.0-r1.aarch64
*
* Solution 1:
*   - do not ask to install a package providing initramfs-module-install
If I build for the genericx86-64 target it builds successfully.  I think the problem is with it needing "grub" for the j7-evm target because I don't believe grub is needed nor built for that target.  The bootloader in that case is u-boot.  Is there something I need to do to tell it the bootloader is u-boot rather than grub maybe?  Anyone have any ideas and/or guidance?  Thanks in advance.
Note that using grub-efi on aarch64 is expected and normal, building
"grub" is not. I think the core-image-minimal-initramfs recipes and/or
initramfs-module-install recipes need a bit of tweaking.

--
Tom


[meta-rockchip][PATCH] u-boot: remove "virtual" keyword in dependency

Trevor Woerner
 

The latest trusted-firmware-a recipe in meta-arm no longer considers
trusted-firmware-a to have potentially multiple providers.

Signed-off-by: Trevor Woerner <twoerner@...>
---
recipes-bsp/u-boot/u-boot%.bbappend | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-bsp/u-boot/u-boot%.bbappend b/recipes-bsp/u-boot/u-boot%.bbappend
index 7916e45..9108a36 100644
--- a/recipes-bsp/u-boot/u-boot%.bbappend
+++ b/recipes-bsp/u-boot/u-boot%.bbappend
@@ -8,9 +8,9 @@ do_compile:append:rock2-square () {
ATF_DEPENDS ??= ""

EXTRA_OEMAKE:append:rk3399 = " BL31=${DEPLOY_DIR_IMAGE}/bl31-rk3399.elf"
-ATF_DEPENDS:rk3399 = " virtual/trusted-firmware-a:do_deploy"
+ATF_DEPENDS:rk3399 = " trusted-firmware-a:do_deploy"
EXTRA_OEMAKE:append:rk3328 = " BL31=${DEPLOY_DIR_IMAGE}/bl31-rk3328.elf"
-ATF_DEPENDS:rk3328 = " virtual/trusted-firmware-a:do_deploy"
+ATF_DEPENDS:rk3328 = " trusted-firmware-a:do_deploy"

do_compile[depends] .= "${ATF_DEPENDS}"

--
2.34.0.rc1.14.g88d915a634


[meta-rockchip][PATCH] trusted-firmware-a: Drop 0001-Fix-build-with-gcc-11.patch

Khem Raj
 

This has been included upstream see [1]

[1] https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/+/f943b7c8e292e3aad2fcbdd0a37505f62b3b4c87%5E%21/#F0

Signed-off-by: Khem Raj <raj.khem@...>
---
.../files/0001-Fix-build-with-gcc-11.patch | 34 -------------------
.../trusted-firmware-a_%.bbappend | 1 -
2 files changed, 35 deletions(-)
delete mode 100644 recipes-bsp/trusted-firmware-a/files/0001-Fix-build-with-gcc-11.patch

diff --git a/recipes-bsp/trusted-firmware-a/files/0001-Fix-build-with-gcc-11.patch b/recipes-bsp/trusted-firmware-a/files/0001-Fix-build-with-gcc-11.patch
deleted file mode 100644
index 7956717..0000000
--- a/recipes-bsp/trusted-firmware-a/files/0001-Fix-build-with-gcc-11.patch
+++ /dev/null
@@ -1,34 +0,0 @@
-From d4c60a312271e000e8339f0b47a302c325313758 Mon Sep 17 00:00:00 2001
-From: Khem Raj <raj.khem@...>
-Date: Tue, 11 May 2021 11:46:30 -0700
-Subject: [PATCH] Fix build with gcc 11
-
-Fixes
-plat/rockchip/rk3399/drivers/dram/dram.c:13:22: error: ignoring attribute 'section (".pmusram.data")' because it conflicts with previous 'section (".sram.data")' [-Werror=attributes]
-
-See [1]
-
-[1] https://developer.trustedfirmware.org/T925
-
-Upstream-Status: Pending
-Signed-off-by: Khem Raj <raj.khem@...>
----
- plat/rockchip/rk3399/drivers/dram/dram.h | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/plat/rockchip/rk3399/drivers/dram/dram.h b/plat/rockchip/rk3399/drivers/dram/dram.h
-index 0eb12cf29..5572b1612 100644
---- a/plat/rockchip/rk3399/drivers/dram/dram.h
-+++ b/plat/rockchip/rk3399/drivers/dram/dram.h
-@@ -149,7 +149,7 @@ struct rk3399_sdram_params {
- uint32_t rx_cal_dqs[2][4];
- };
-
--extern __sramdata struct rk3399_sdram_params sdram_config;
-+extern struct rk3399_sdram_params sdram_config;
-
- void dram_init(void);
-
---
-2.31.1
-
diff --git a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
index f7777a7..074d0e0 100644
--- a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
+++ b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
@@ -8,7 +8,6 @@ COMPATIBLE_MACHINE:append:rk3328 = "|rk3328"
FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
SRC_URI += "\
file://serial-console-baudrate.patch \
- file://0001-Fix-build-with-gcc-11.patch \
file://0001-dram-Fix-build-with-gcc-11.patch \
file://0001-plat_macros.S-Use-compatible-.asciz-asm-directive.patch \
file://0001-pmu-Do-not-mark-already-defined-functions-as-weak.patch \
--
2.34.1


Re: [docs] [PATCH yocto-autobuilder-helper] scripts/run-docs-build: make all versions list releases known to master

Michael Opdenacker
 

Hi Quentin,

Thanks for the review and for your suggestions.

On 12/3/21 10:34 AM, Quentin Schulz wrote:
Hi Michael,

On Wed, Dec 01, 2021 at 02:49:31PM +0100, Michael Opdenacker wrote:
This allows all versions of Bitbake and Yocto Project manuals
to see the manuals for the latest versions.

This also simplifies the release process, not having to update the
releases.rst file for all releases every time a new release is made.

Note that such synchronization is already done for the
switchers.js file (but in a different way). This way, advertised
releases are in sync with switchers.js.
Why don't we migrate this different method (find) to the one you
implement in this commit too?

I could see a variable storing all "force-latest" files or someting like
that to make it obvious why they have a specific handling.

I tried, but I stumble on the need to copy the latest switchers.js from
yocto-docs to the Bitbake branches too.

And since the Bitbake branches need to be checked out and processed
first, I hesitate to add a special extra step to checkout the yocto-docs
repo before. Possible but adding complexity.

So, if I don't use this way for the Bitbake branches, I still need a
find command at the end...

If you don't think about any better idea, I'd propose to stick to this
version of the patch.

Cheers
Michael.

--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


Re: [oe] Help with Inclusive Language in OpenEmbedded/Yocto Project

Scott Murray
 

On Mon, 6 Dec 2021, Jon Mason wrote:

This email is a follow-up from the session held on Friday at the
OpenEmbedded Developer's Virtual Meeting (see
https://www.openembedded.org/wiki/OEDVM_Nov_2021)

The session was not recorded, but the slides can be found at
https://docs.google.com/presentation/d/146ueVVTMeA8JI43wqv5kFmdYEygqqmfGH0z1VRL2bDA/edit?usp=sharing

The outcome from the discussion was that inclusive language changes
are something that we want to accomplish in the kirkstone release
timeframe (with an exception for the "master" branch name, which will
be handled at a future date).

There has already been a pass at collecting the needed changes at
https://wiki.yoctoproject.org/wiki/Inclusive_language

This is not as simple as a find/replace of offending words. There is
a desire for backward compatibility or to provide some kind of "you
want X, which is now Y" (which complicates things).

The intention of this email is to see who is interested in helping
out. Once we know how many people are available and what time frames,
we can plan out a roadmap. So, please email me (or respond to this
thread publicly) and I'll add you to the list. There will then be a
follow-up zoom call in the next week or so to plan out the roadmap.

We will document the roadmap and everything else on the YP wiki page above.

Questions and comments are welcome, but not interested in debating the
necessity or timeframe of this task. It has already been decided.
I am also interested in helping move this forward, please count me in.

Scott


[meta-raspberrypi] Changing rootfstype to squashfs

Beek, Léon van de
 

Dear all,

 

My goal is to have a squashfs rootfstype and ext4 data partition that get combined in an overlayfs and switched to the root during boot.

I managed to get the overlayfs and switching of root working thanks to meta-readonly-rootfs and some changes locally, but only with 2 ext4 partitions and not with a squashfs partition.

I changed the rootfs to squash fs by changing the following 2 things:

  • Change to --fstype=squashfs in .wks file
  • Change IMAGE_FSTYPE to “squashfs wic.bz2” although I believe this is only necessary to get a .squashfs rootfs file

 

Please note I am running the image on a raspberrypi3-64, and I also noticed that the cmdline.txt still had rootfstype=ext4, but after changing this to squashfs I got a kernel panic with error:

“Not syncing: vfs: Unable to mount root fs on unknown-blick(179,6)”

Which I believe means in this case that the kernel module for Squashfs is not loaded? Could someone help me out how to load this module or point out something else I am missing?

 

Kind regards,

Léon


Re: Behaviour of .bbappend when default script is not present

tomzy
 

Hi,

You could also consider using the `BBFILES_DYNAMIC`[1] variable, this way your bbappend
would only apply when there is `meta-raspberrypi` in the build configuration. Your bbappend
could be placed in custom layer under
`dynamic-layers/raspberrypi/recipes-bsp/bootfiles/
rpi-cmdline.bbappend` path and than in its
layer.conf file add

BBFILES_DYNAMIC += " \
    raspberrypi:${LAYERDIR}/dynamic-layers/raspberrypi/recipes-*/*/*.bbappend \
"

Looks like the best option to add kernel command parameters is to use `
rpi-cmdline.bbappend`
with dynamic-layers as mentioned above. You should add changes to CMDLINE[2] variable

[1]https://docs.yoctoproject.org/ref-manual/variables.html#term-BBFILES_DYNAMIC
[2]https://github.com/agherzan/meta-raspberrypi/blob/master/recipes-bsp/bootfiles/rpi-cmdline.bb#L39

Regards
--
Tomasz Żyjewski
Embedded Systems Engineer
GPG: 5C495EA3EBEECA59
https://3mdeb.com | @3mdeb_com


Re: Behaviour of .bbappend when default script is not present

Konrad Weihmann <kweihmann@...>
 

You can either use BBMASK in your local.conf to remove the bbappend from the parsing tree or set BB_DANGLINGAPPENDS_WARNONLY in your specific build.

both can be added to your specific kas yaml without any issues

[1] https://docs.yoctoproject.org/ref-manual/variables.html#term-BB_DANGLINGAPPENDS_WARNONLY

On 08.12.21 10:26, Beek, Léon van de wrote:
Dear all,
My situation is as follows:
* Using Kas container to build and enable easy CI, I have 2 .yaml
files creating my 2 builds for 2 different machines: RaspberryPi and
Qemu.
* Qemu yaml file does not contain meta-raspberrypi repo
* Custom distro that extends poky has a script rpi-cmdline.bbappend
that appends script with the same name from meta-raspberrypi
* Rpi-cmdline.bbappend is used to simply add 2 kernel commands to
cmdline.txt
* Rpi-cmdline.bbappend contains line on top with: COMPATIBLE_MACHINE =
"^rpi$"
When running the Qemu build, Bitbake will say that the default .bb file is not present for the rpi-cmdline.bbappend script, which of course is true, but I don’t want to include the meta-raspberrypi repo in my sources for this build as well.
It seems like the “COMPATIBLE_MACHINE = "^rpi$"” is only regarded after parsing the script, which still requires the default script to be present.
I’ve searched the internet but have not found a way of achieving my goal so far, so my question is:
Is there any way of having this .bbappend file present without the default .bb file there? Or maybe there is a better solution to add kernel command parameters to cmdline without using this rpi only script?
Thanks in advance.
Kind regards,
Léon van de Beek


Behaviour of .bbappend when default script is not present

Beek, Léon van de
 

Dear all,

 

My situation is as follows:

 

  • Using Kas container to build and enable easy CI, I have 2 .yaml files creating my 2 builds for 2 different machines: RaspberryPi and Qemu.
  • Qemu yaml file does not contain meta-raspberrypi repo
  • Custom distro that extends poky has a script rpi-cmdline.bbappend that appends script with the same name from meta-raspberrypi
  • Rpi-cmdline.bbappend is used to simply add 2 kernel commands to cmdline.txt
  • Rpi-cmdline.bbappend contains line on top with: COMPATIBLE_MACHINE = "^rpi$"

 

When running the Qemu build, Bitbake will say that the default .bb file is not present for the rpi-cmdline.bbappend script, which of course is true, but I don’t want to include the meta-raspberrypi repo in my sources for this build as well.

It seems like the “COMPATIBLE_MACHINE = "^rpi$"” is only regarded after parsing the script, which still requires the default script to be present.

 

I’ve searched the internet but have not found a way of achieving my goal so far, so my question is:

Is there any way of having this .bbappend file present without the default .bb file there? Or maybe there is a better solution to add kernel command parameters to cmdline without using this rpi only script?

 

Thanks in advance.

 

Kind regards,

Léon van de Beek

 

1901 - 1920 of 57389