Re: [yocto] [meta-oe][PATCH] externalsrc:git submodule--helper list unsupported

[Quentin Schulz via lists.yoctoproject.org]

Hi John,

On 9/15/22 20:43, John Broadbent via lists.yoctoproject.org wrote:

From: John Edward Broadbent 

Git has removed support for "git submodule--helper list".
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_git_git_commit_31955475d1c283120d5d84247eb3fd55d9f5fdd9&d=DwIBaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=dPWGp0K5l_YXiJ9CQ0xgD9h8jzFwJf2ZGppZSv2ZZUvg_DVFfKt3g2SwAJdk6ATE&s=rTfHjnsYf5vusiYA_lI3L24FBLE9jU_hmbGFPELpuAg&e=

This change provides an alternate method for gathering the submodules
information.

Tested:
Build recipes with and without submodules

Signed-off-by: Carson Labrado 
Signed-off-by: John Edward Broadbent 
---
  meta/classes-recipe/externalsrc.bbclass | 19 ++-


meta layer is part of openembedded-core, so please re-send to the 
correct mailing list following the docs here 
https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded



  1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/meta/classes-recipe/externalsrc.bbclass 
b/meta/classes-recipe/externalsrc.bbclass
index ce753fce76..06a9548a20 100644
--- a/meta/classes-recipe/externalsrc.bbclass
+++ b/meta/classes-recipe/externalsrc.bbclass
@@ -230,15 +230,16 @@ def srctree_hash_files(d, srcdir=None):
  env['GIT_INDEX_FILE'] = tmp_index.name
  subprocess.check_output(['git', 'add', '-A', '.'], cwd=s_dir, 
env=env)
  git_sha1 = subprocess.check_output(['git', 'write-tree'], cwd=s_dir, 
env=env).decode("utf-8")
-submodule_helper = subprocess.check_output(['git', 'submodule--helper', 
'list'], cwd=s_dir, env=env).decode("utf-8")
-for line in submodule_helper.splitlines():
-module_dir = os.path.join(s_dir, line.rsplit(maxsplit=1)[1])
-if os.path.isdir(module_dir):
-proc = subprocess.Popen(['git', 'add', '-A', '.'], 
cwd=module_dir, env=env, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
-proc.communicate()
-proc = subprocess.Popen(['git', 'write-tree'], 
cwd=module_dir, env=env, stdout=subprocess.PIPE, stderr=subprocess.DEVNULL)
-stdout, _ = proc.communicate()
-git_sha1 += stdout.decode("utf-8")
+if os.path.exists(".gitmodules"):
+submodule_helper = subprocess.check_output(["git", "config", "--file", ".gitmodules", 
"--get-regexp", "path"], cwd=s_dir, env=env).decode("utf-8")
+for line in submodule_helper.splitlines():
+module_dir = os.path.join(s_dir, 
line.rsplit(maxsplit=1)[1])
+if os.path.isdir(module_dir):
+proc = subprocess.Popen(['git', 'add', '-A', '.'], 
cwd=module_dir, env=env, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
+proc.communicate()
+proc = subprocess.Popen(['git', 'write-tree'], 
cwd=module_dir, env=env, stdout=subprocess.PIPE, stderr=subprocess.DEVNULL)
+stdout, _ = proc.communicate()
+git_sha1 += stdout.decode("utf-8")


Are those git commands supported in 1.8.3.1 version of git? I'm asking 
because this is the minimal version of git we currently advertise as 
supported. If it is not, then we need to bump this requirement in the 
docs and check that all currently supported distributions have this new 
minimal version in their package feed or remove them from the list 
(which will also impact whether dunfell and kirkstone can receive this 
patch).


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58053): https://lists.yoctoproject.org/g/yocto/message/58053
Mute This Topic: https://lists.yoctoproject.org/mt/93707120/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Problem with make: *** No targets specified and no makefile found.

[Quentin Schulz via lists.yoctoproject.org]

Hi Kuzemko Aleksandr,

On 9/17/22 19:19, Kuzemko Aleksandr wrote:

I am trying adapt fbi recipe. 
(https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Kuzma30_meta-2Dmyconf_blob_main_recipes-2Dcore_fbi_fbi-5F1.31.bb&d=DwIFaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=gnSpmPTreYq9mxX4ptMTWTg0gTJw7RWcUWX8gKmcw8S8xDyWysHjWlYvrelWOfuf&s=js1u3ARo14dxKOe3T2TO2ZX6O_y6RGMtZ8eDqYtxUm4&e=
 )
When I run bitbake fbi I get

NOTE: Executing Tasks
ERROR: fbi-1.31-r0 do_compile: oe_runmake failed
ERROR: fbi-1.31-r0 do_compile: 
ExecutionError('/home/qtembed/b2qt/build-raspberrypi4-64/tmp/work/cortexa72-poky-linux/fbi/1.31-r0/temp/run.do_compile.4355',
 1, None, None)
ERROR: Logfile of failure stored in: 
/home/qtembed/b2qt/build-raspberrypi4-64/tmp/work/cortexa72-poky-linux/fbi/1.31-r0/temp/log.do_compile.4355
Log data follows:
| DEBUG: Executing python function autotools_aclocals
| DEBUG: SITE files ['endian-little', 'bit-64', 'arm-common', 'arm-64', 
'common-linux', 'common-glibc', 'aarch64-linux', 'common']
| DEBUG: Python function autotools_aclocals finished
| DEBUG: Executing shell function do_compile
| NOTE: make
| make: *** No targets specified and no makefile found.  Stop.
| ERROR: oe_runmake failed
| WARNING: exit code 1 from a shell command.
ERROR: Task 
(/home/qtembed/b2qt/sources/meta-myconfig/recipes-core/fbi/fbi_1.31.bb:do_compile)
 failed with exit code '1'
NOTE: Tasks Summary: Attempted 769 tasks of which 768 didn't need to be rerun 
and 1 failed.

I see empty 
home/qtembed/b2qt/build-raspberrypi4-64/tmp/work/cortexa72-poky-linux/fbi/1.31-r0/build
 directory. In 
home/qtembed/b2qt/build-raspberrypi4-64/tmp/work/cortexa72-poky-linux/fbi/1.31-r0/fbi-1.31
 I see extracted source code.
As I understand this error make is running in empty build dir, not in source.
How to fix this?



Maybe this has a broken autotools script, can you try to inherit 
autotools-brokensep instead of autotools?


c.f. https://docs.yoctoproject.org/ref-manual/classes.html#autotools-bbclass

Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58068): https://lists.yoctoproject.org/g/yocto/message/58068
Mute This Topic: https://lists.yoctoproject.org/mt/93747035/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] meta-swupdate integration with the custom Yocto image #dunfell

[Quentin Schulz via lists.yoctoproject.org]

Hi Mahendra Sondagar,

On 9/25/22 19:38, Mahendra Sondagar wrote:

Hey.. There
Hope all are doing well

I'm dealing with the swupdate with the my custom Yocto image created for 
STM32MP1 dk1 board
The intend is, to update the rootfs remotely

I have successfully integrated meta-swupdate layer with the custom Yocto image 
by adding the layers in to bblayer.conf file
The both layers meta-swupdate & meta-custom are parallel to each-others

To change the flags and setting with the swupdate, i have created the r 
*ecipes-myswupdate* file inside the meta-custom layers
The content of the recipes-myswupdate are as follows
.
└── swupdate
├── stm32mp1
│   ├── 09-swupdate-args
│   ├── defconfig
│   ├── sw-description
│   └── swupdate.cfg
└── swupdate_%.bbappend



Considering you're using SRC_URI unconditionally, I suggest you use:
.
├── swupdate
│   ├── 09-swupdate-args
│   ├── defconfig
│   ├── sw-description
│   └── swupdate.cfg
└── swupdate_%.bbappend


The content of the *swupdate_%.bbappend* are as follows

--

DESCRIPTION = "Example recipe generating SWU image"
SECTION = ""

LICENSE = ""

# Add all local files to be added to the SWU
# sw-description must always be in the list.
# You can extend with scripts or wahtever you need
SRC_URI += " \
file://sw-description \
file://09-swupdate-args \
file://swupdate.cfg \
"

# images to build before building swupdate image
IMAGE_DEPENDS = "core-image-full-cmdline virtual/kernel"

# images and files that will be included in the .swu image
SWUPDATE_IMAGES = "core-image-full-cmdline uImage"

# a deployable image can have multiple format, choose one
SWUPDATE_IMAGES_FSTYPES[core-image-full-cmdline] = ".ubifs"
SWUPDATE_IMAGES_FSTYPES[uImage] = ".bin"

inherit swupdate



I'm pretty sure you're not appending to the correct recipe, swupdate 
recipe is the SWUpdate recipe for building the SWUpdate update mechanism 
SW, it's not for building an image that is making use of SWUpdate mechanism.


I think you want to append to swupdate-image recipe or create your own 
inheriting swupdate-image?


Or probably both actually, one for adding your configuration files to 
the SWUpdate SW and the 
IMAGE_DEPENDS/SWUPDATE_IMAGES/SWUIPDATE_IMAGE_FSTYPES to the image recipe.


In any case, you're missing:
FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"
in your bbappend for adding files. c.f. 
https://docs.yoctoproject.org/ref-manual/variables.html#term-FILESEXTRAPATHS


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58158): https://lists.yoctoproject.org/g/yocto/message/58158
Mute This Topic: https://lists.yoctoproject.org/mt/93911152/21656
Mute #dunfell:https://lists.yoctoproject.org/g/yocto/mutehashtag/dunfell
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-rockchip][PATCH] layers: Add langdale to LAYERSERIES_COMPAT

[Quentin Schulz via lists.yoctoproject.org]

Hi Khem,

On 9/30/22 01:45, Khem Raj wrote:

Signed-off-by: Khem Raj 
---
  conf/layer.conf | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index a2661f9..0e28857 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -14,7 +14,7 @@ BBFILE_PRIORITY_rockchip = "1"
  # This should only be incremented on significant changes that will
  # cause compatibility issues with other layers
  LAYERVERSION_rockchip = "1"
-LAYERSERIES_COMPAT_rockchip = "kirkstone"
+LAYERSERIES_COMPAT_rockchip = "kirkstone langdale"


Considering that we have a branch for kirkstone already, maybe we can 
just switch to supporting langdale only?


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58230): https://lists.yoctoproject.org/g/yocto/message/58230
Mute This Topic: https://lists.yoctoproject.org/mt/94006954/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [PATCH yocto-autobuilder-helper] scripts: run-docs-build: make the workdir pristine between builds

[Quentin Schulz via lists.yoctoproject.org]

Hi all,

On 10/3/22 19:04, Quentin Schulz wrote:

From: Quentin Schulz 

It happened that the git repositories were dirty and resulted in
incorrect files being used. Let's use git clean -ffdx to force a
completely clean git repositories before and after checking out a branch
so that nothing is left from or to another branch build

Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 
---


Forgot to say this was not tested. Let's run this on the autobuilder and 
see if it helps? Is there a way to try without merging?


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58253): https://lists.yoctoproject.org/g/yocto/message/58253
Mute This Topic: https://lists.yoctoproject.org/mt/94095578/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [PATCH yocto-autobuilder-helper] scripts: run-docs-build: make the workdir pristine between builds

[Quentin Schulz via lists.yoctoproject.org]

Hi Luca,

On 10/3/22 23:15, Luca Ceresoli wrote:

Hi Quentin,

On Mon,  3 Oct 2022 19:04:01 +0200
"Quentin Schulz"  wrote:


From: Quentin Schulz 

It happened that the git repositories were dirty and resulted in
incorrect files being used. Let's use git clean -ffdx to force a
completely clean git repositories before and after checking out a branch
so that nothing is left from or to another branch build

Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 
---
  scripts/run-docs-build | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/scripts/run-docs-build b/scripts/run-docs-build
index c6b3965..69e3257 100755
--- a/scripts/run-docs-build
+++ b/scripts/run-docs-build
@@ -61,6 +61,7 @@ for branch in 1.46 $(git branch --remote --contains 
"$first_sphinx_commit" --for
  
  echo Building bitbake $branch branch

  git checkout $branch
+git clean -ffdx
  git checkout origin/master releases.rst
  make clean
  SPHINXOPTS="-j auto" make publish
@@ -80,7 +81,7 @@ for branch in 1.46 $(git branch --remote --contains 
"$first_sphinx_commit" --for
  fi
  
  cp -r ./_build/final/* $outputdir/bitbake/$branch

-git reset --hard
+git clean -ffdx


Sure this is correct? 'git clean -ffdx' does not revert changes to
tracked files, be them staged or not.



Nope, not sure this is correct. I misread git clean manpage, we should 
have a git reset --hard and git clean -ffdx. Now the question is when 
those are necessary because with this patch we do it twice, before and 
after the git checkout. I did this because I remember doing checkouts 
between branches of U-Boot/kernel and while the pre-checkout branch was 
not dirty, the after-checkout branch was dirty. I assume this might have 
something to do with build artifacts of the pre-checkout build that 
weren't .gitignored in the afer-checkout branch? Something that git 
clean -ffdx should tackle I think.


Sooo, I guess only having git reset --hard and git clean -ffdx before a 
checkout should be enough and we don't need them both before and after 
the checkout like I did in this patch?


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58262): https://lists.yoctoproject.org/g/yocto/message/58262
Mute This Topic: https://lists.yoctoproject.org/mt/94095578/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [PATCH yocto-autobuilder-helper] scripts: run-docs-build: make the workdir pristine between builds

[Quentin Schulz via lists.yoctoproject.org]

Hi Luka,

On 10/4/22 22:54, Luca Ceresoli wrote:

Hi Quentin,

On Tue, 4 Oct 2022 10:15:20 +0200
Quentin Schulz  wrote:


Hi Luca,

On 10/3/22 23:15, Luca Ceresoli wrote:

Hi Quentin,

On Mon,  3 Oct 2022 19:04:01 +0200
"Quentin Schulz"  wrote:
   

From: Quentin Schulz 

It happened that the git repositories were dirty and resulted in
incorrect files being used. Let's use git clean -ffdx to force a
completely clean git repositories before and after checking out a branch
so that nothing is left from or to another branch build

Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 
---
   scripts/run-docs-build | 10 +-
   1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/scripts/run-docs-build b/scripts/run-docs-build
index c6b3965..69e3257 100755
--- a/scripts/run-docs-build
+++ b/scripts/run-docs-build
@@ -61,6 +61,7 @@ for branch in 1.46 $(git branch --remote --contains 
"$first_sphinx_commit" --for
   
   echo Building bitbake $branch branch

   git checkout $branch
+git clean -ffdx
   git checkout origin/master releases.rst
   make clean
   SPHINXOPTS="-j auto" make publish
@@ -80,7 +81,7 @@ for branch in 1.46 $(git branch --remote --contains 
"$first_sphinx_commit" --for
   fi
   
   cp -r ./_build/final/* $outputdir/bitbake/$branch

-git reset --hard
+git clean -ffdx


Sure this is correct? 'git clean -ffdx' does not revert changes to
tracked files, be them staged or not.
   


Nope, not sure this is correct. I misread git clean manpage, we should
have a git reset --hard and git clean -ffdx. Now the question is when
those are necessary because with this patch we do it twice, before and
after the git checkout. I did this because I remember doing checkouts
between branches of U-Boot/kernel and while the pre-checkout branch was
not dirty, the after-checkout branch was dirty. I assume this might have
something to do with build artifacts of the pre-checkout build that
weren't .gitignored in the afer-checkout branch? Something that git
clean -ffdx should tackle I think.

Sooo, I guess only having git reset --hard and git clean -ffdx before a
checkout should be enough and we don't need them both before and after
the checkout like I did in this patch?


I think 'reset --hard' + 'clean -ffdx' only before the checkout should
be enough. However I'm not sure whether there are corner cases such as
a file that is .gitignored in commit A and versioned in commit B or
similar. Perhaps worth trying with reset+clean only before, and see


I guess it does not hurt to be on the safe side by having them before 
and after the git checkout then? Since the current issue went unnoticed 
for months...



what happens. However I don't know exactly the initial problem you're
trying to fix.



https://lore.kernel.org/yocto-docs/e50abe3c777e4a23a752a3ec25ad0...@axis.com/T/#t

Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58268): https://lists.yoctoproject.org/g/yocto/message/58268
Mute This Topic: https://lists.yoctoproject.org/mt/94095578/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] SRC_URI file://f.tar and destination

[Quentin Schulz via lists.yoctoproject.org]

Hi Mauro,

On 10/5/22 21:37, Mauro Ziliani wrote:

Hi all.

I'd like to explod a tar file into subdirectory of source file.


The recipe fetch the original source from a git repos.

I make a tar of folder I'd like to add to the original sources.


SRC_URI := "\
     git://git.myserver.com/project.git \
     file://added_folder.tar \
"

# S is ${WORKDIR}/git


Now added_folder.tar is exploded in ${WORKDIR} but I'd like to explod it 
in ${WORKDIR}/git



There is some parameter for file:// fetcher?



Can you try ;subdir= parameter?

c.f. 
https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-fetching.html#the-unpack


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58272): https://lists.yoctoproject.org/g/yocto/message/58272
Mute This Topic: https://lists.yoctoproject.org/mt/94143218/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] EXTRA_IMAGECMD:squashfs-xz support

[Quentin Schulz via lists.yoctoproject.org]

Hi Jason,

Sorry for the delay, your mail got lost in my pile of to-answer that 
never slims down apparently.


On 10/19/22 00:48, Bills, Jason M wrote:

Hello,

Just checking if EXTRA_IMAGECMD:squashfs-xz:append failing to apply is expected 
or if it should be fixed?



I just tested on Kirkstone release, yocto-4.0.4 tag. It works as expected.

Did you end up finding the issue or are you still after it?

Would you be able to give us more info? Which version of Yocto are you 
using? Can you try to find a small reproducer with ideally only poky (or 
at the very least public layers)?


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58424): https://lists.yoctoproject.org/g/yocto/message/58424
Mute This Topic: https://lists.yoctoproject.org/mt/94004657/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [PATCH yocto-autobuilder-helper v2] scripts: run-docs-build: make the workdir pristine between tries

[Quentin Schulz via lists.yoctoproject.org]

Hi all,

Gentle ping.

Cheers,
Quentin

On 10/13/22 14:17, Quentin Schulz wrote:

From: Quentin Schulz 

It happened that the git repositories were dirty and resulted in
incorrect files being used. Let's use git clean -ffdx to force a
completely clean git repositories before and after checking out a branch
so that nothing is left from or to another branch build. Also git reset
--hard to undo changes to tracked files.

Cc: Quentin Schulz 
Reported-by: Peter Kjellerstedt  
#https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.org_yocto-2Ddocs_e50abe3c777e4a23a752a3ec25ad0b2a-40axis.com_&d=DwIDAg&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=sjcVZJ-k5ISKZ9bP1v6Z8e45PceKIzwNAcLdpzaeA2PhyRTTUYU3K1UE3Wsqem3F&s=3-gBIoJfYKyqg6H4LFhHQOPdBGVvSUqi8kFfYVwJWcg&e=
Signed-off-by: Quentin Schulz 
---

v2:
  - re-added git reset --hard back,
  - added git reset --hard after git checkout too just to be on the safe
  side,
  - added Reported-by and the link to the discussion,

  scripts/run-docs-build | 9 +++--
  1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/scripts/run-docs-build b/scripts/run-docs-build
index c6b3965..970d8bc 100755
--- a/scripts/run-docs-build
+++ b/scripts/run-docs-build
@@ -61,6 +61,8 @@ for branch in 1.46 $(git branch --remote --contains 
"$first_sphinx_commit" --for
  
  echo Building bitbake $branch branch

  git checkout $branch
+git reset --hard
+git clean -ffdx
  git checkout origin/master releases.rst
  make clean
  SPHINXOPTS="-j auto" make publish
@@ -81,6 +83,7 @@ for branch in 1.46 $(git branch --remote --contains 
"$first_sphinx_commit" --for
  
  cp -r ./_build/final/* $outputdir/bitbake/$branch

  git reset --hard
+git clean -ffdx
  done
  
  if [ "$PUBLISH" -ne 0 ]; then

@@ -101,7 +104,7 @@ git checkout origin/master set_versions.py
  #latest_tag=$(git tag --contains "$first_sphinx_commit" --contains 
"$first_dunfell_sphinx_commit" --sort="version:refname" 'yocto-*' | tail -1 | sed 
's/yocto-//')
  latest_tag=$(./set_versions.py getlatest)
  git reset --hard
-git clean -f
+git clean -ffdx
  
  for branch in dunfell $(git branch --remote --contains "$first_sphinx_commit" --format '%(refname:lstrip=3)') $(git tag --contains "$first_sphinx_commit" --contains "$first_dunfell_sphinx_commit" 'yocto-*') transition; do

  if [ "$branch" = "HEAD" ]; then
@@ -116,6 +119,8 @@ for branch in dunfell $(git branch --remote --contains 
"$first_sphinx_commit" --
  
  echo Building $branch

  git checkout $branch
+git reset --hard
+git clean -ffdx
  
  if [ -e "${scriptdir}/docs-build-patches/${branch}/" ]; then

  echo Adding patch for $branch
@@ -161,7 +166,7 @@ for branch in dunfell $(git branch --remote --contains 
"$first_sphinx_commit" --
  
  cp -r ./_build/final/* $outputdir/$branch

  git reset --hard
-git clean -f
+git clean -ffdx
  done
  
  # Update bitbake switchers.js with the copy from master ypdocs

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58425): https://lists.yoctoproject.org/g/yocto/message/58425
Mute This Topic: https://lists.yoctoproject.org/mt/94302082/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Image dependent variables/files in included recipes

[Quentin Schulz via lists.yoctoproject.org]

Hi Maik,

On 11/17/22 16:22, Maik Vermeulen wrote:

Hi,

Depending on the image that's being built, e.g. development vs. production,
we would like to be able to include different user passwords and firewall
settings.

We know this can be achieved by just having two different recipes that do
the same thing, but with different variables or included files. However, we
were wondering if there is a neater way?

We saw this post:
https://urldefense.com/v3/__https://www.yoctoproject.org/pipermail/yocto/2018-June/041378.html__;!!OOPJP91ZZw!k-UkKru_mKI6U4p8UgDfH_VEh1-qar1kiQuqcmnyrETRAnubF79KykqR7VGaRu47i1Ws7n8CAagOJBqEFBB3goTxmBkgn8-qL3X383IHnKva$
which seems to do what we want, because one recipe can install
recipe-development, and the other can install recipe-production, while the
recipe itself can then implement what needs to happen for either.
However, other recipes included in the images can also depend on recipe,
and they shouldn't depend on one specifically. They should accept that
either recipe-development or recipe-production is included. Currently we
see that both the generic recipe and the specific recipe used by the image
are built and overwrite each other.

What would be a neat way to achieve two variants of a recipe, and having
different contents and settings in them?
Or, can we solve that other included recipes depend on one of the variants,
instead of on the generic one.



Development vs production is solved by using different distros.

You can then have the same recipe but with different files (see 
(DISTRO)OVERRIDES mechanism for SRC_URI file:// files, c.f. 
https://summit.yoctoproject.org/media/yocto-project-summit-2022-05/submissions/SCYYWD/resources/Demystifying_the_OVERRIDES_mec_2lZOP3n.pdf) 
and/or different variables via FOO:dev-distro or FOO:append:dev-distro 
for example.


You could also have different recipes both PROVIDES'ing the same virtual 
recipe and then have PREFERRED_PROVIDER_my-recipe = "my-recipe-dev" in 
your dev-distro.conf file.


Two distros is usually overkill when you have very small and 
non-invasive differences between your dev and prod images (e.g. an 
additional package, or a lone package that needs to be slightly 
different). In that scenario, a "drity" solution is to have two recipes 
and have the final image pick the appropriate package. But this quickly 
does not scale well once you have recipes/packages depending on those or 
if you have more than two flavors to support.


The best practice is to use two distros.

Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58588): https://lists.yoctoproject.org/g/yocto/message/58588
Mute This Topic: https://lists.yoctoproject.org/mt/95091628/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-rockchip][PATCH] rockchip-defaults: remove xf86-input-keyboard

[Quentin Schulz via lists.yoctoproject.org]

Hi Trevor,

On 11/19/22 14:45, Trevor Woerner wrote:

xf86-input-keyboard was removed from openembedded-core at its commit:
f1d7c33b64 (xf86-input-keyboard: remove the recipe, 2022-07-20). Therefore > 
remove it from the XSERVER definition.

Signed-off-by: Trevor Woerner 


Reviewed-by: Quentin Schulz 

Thanks,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58597): https://lists.yoctoproject.org/g/yocto/message/58597
Mute This Topic: https://lists.yoctoproject.org/mt/95132799/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] #kirkstone: boot script section not added in the fitimage

[Quentin Schulz via lists.yoctoproject.org]

Hi Sébastien,

On 11/14/22 14:50, sebastien.fabr...@gmail.com wrote:

Hello,

I am working on kirkstone. If UBOOT_ENV is specified and kernel-fitimage is in 
KERNEL_CLASSES, boot script section is not added in the fitimage.

In fitimage_assemble (kernel-fitimage.bbclass), the 3 rd step is not performed 
because boot directory is not in STAGING_DIR_HOST. Indeed, u-boot.inc installs 
UBOOT_ENV_BINARY in boot directory but boot is not in SYSROOT_DIRS so it is not 
present in kernel STAGING_DIR_HOST.

Should we add the following line in u-boot.inc ?

SYSROOT_DIRS:append = "${@' /boot' if d.getVar('UBOOT_ENV') else ''}"



The logic seems reasonable to me, yes. We could have used the deploy 
directory instead and depend on the do_deploy task instead of the 
do_populate_sysroot but I think it is actually safer to use the sysroot 
(because it is cleaned if a dependency changes, as opposed to the deploy 
directory that might be providing an old version, e.g. think one build 
with UBOOT_ENV set followed by one it isn't, the deployed artifact will 
still be present).


Though, please use += instead of :append.

I'm wondering also if we cannot just always have /boot in SYSROOT_DIRS 
for U-Boot recipe? I guess it's fine like this :)


Please send a patch,
Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58607): https://lists.yoctoproject.org/g/yocto/message/58607
Mute This Topic: https://lists.yoctoproject.org/mt/95018923/21656
Mute #kirkstone:https://lists.yoctoproject.org/g/yocto/mutehashtag/kirkstone
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] how to specify the package version via RDEPENDS in package group #bitbake

[Quentin Schulz via lists.yoctoproject.org]

Hi Martin,

On 11/23/22 06:25, Martin wrote:

thanks for reply, i original method was specified the package version in 
local.conf by PREFEREED_VERSION.

i wondering if configure package version in package group via RDEPENDS makes it 
possible? but it seems impossible.

what situations allow REDPENDS to specify a version? thanks.



As far as I remember, RDEPENDS is handled by the package manager when 
installing the package. So I imagine this is a way to make sure that a 
filesystem is not built with two packages that are incompatible at 
runtime by failing when creating the filesystem. The choice of which 
version to build is a responsibility of Bitbake which happens way before 
RDEPENDS.


Also, chant #1 of Yocto applies:
recipe data is local, config data is global.
So you cannot impact one recipe from another, this implies you cannot 
pick a version of one recipe from another, you can only say whether 
you're compatible with it.


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58627): https://lists.yoctoproject.org/g/yocto/message/58627
Mute This Topic: https://lists.yoctoproject.org/mt/95192012/21656
Mute #bitbake:https://lists.yoctoproject.org/g/yocto/mutehashtag/bitbake
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Get target machine

[Quentin Schulz via lists.yoctoproject.org]

Hi Iggy,

On 12/1/22 13:55, Iggy via lists.yoctoproject.org wrote:

Hi,

I have a .inc file that contains this information:

# Set the MACHINE string, expected to eventually replace the long list of
# build settings below
EXTRA_OECMAKE += "-DRDK_MACHINE=${@d.getVar('MACHINE', False)} "

# Set the region and platform type (defaults to Xi6 and UK)
EXTRA_OECMAKE_append_xione-uk = " -DRDK_PLATFORM=XI1 -DREGION=UK "
EXTRA_OECMAKE_append_xione-us = " -DRDK_PLATFORM=XI1 -DREGION=UK "

EXTRA_OECMAKE_append_llama-uk = " -DRDK_PLATFORM=LLAMA -DREGION=UK "
EXTRA_OECMAKE_append_llama-us = " -DRDK_PLATFORM=LLAMA -DREGION=UK "

I understand that the append lines add extra parameters to the make call. How 
does Yocto know which platform to use? I mean how does it choose xione-uk or 
llama-us for instance?



You are building for a specific machine (MACHINE in your local.conf or 
via command line argument for example), so Yocto definitely knows it.


Then your machine configuration file (the one in the form of 
.conf contains multiple MACHINEOVERRIDES in .inc files 
which define "families" under which your machine could be matched.


Since MACHINEOVERRIDES is part of OVERRIDES variable which is used to 
filter some variables "overrides", it'll just work (e.g. 
EXTRA_OECMAKE_append_).


Hope this helps,
Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58707): https://lists.yoctoproject.org/g/yocto/message/58707
Mute This Topic: https://lists.yoctoproject.org/mt/95380576/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: Private: Re: [yocto] Get target machine

[Quentin Schulz via lists.yoctoproject.org]

Hi Iggy,

Please keep the mailing list in copy.

On 12/2/22 02:58, j.ignatius via lists.yoctoproject.org wrote:

Thanks Quentin for your reply.

I found a number of product-config.in files under different target folders like 
xione-uk, xione-us, etc. These must be the machine configuration files.

How does yocto choose the right one? Are there some conditional expressions 
that do this? Could you give me an example?



You tell Yocto to build for a specific MACHINE (this is the name of the 
variable) either from the command line when calling bitbake or in your 
local.conf file in build/conf.


MACHINE is the filename without the extension where the configuration is 
located. e.g. xione-uk MACHINE definition will be in some layer in 
conf/machine/xione-uk.conf.


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58716): https://lists.yoctoproject.org/g/yocto/message/58716
Mute This Topic: https://lists.yoctoproject.org/mt/95402383/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Remove kernel image and modules from rootfs

[Quentin Schulz via lists.yoctoproject.org]

Hi Konstantin,

On 12/21/22 22:13, Konstantin Kletschke wrote:

Hi,

I am creating a rootfs/bootloader/kernel to run on a beaglebone black
usually and it works great.

So I have in conf/local.conf

MACHINE ?= "beaglebone-yocto"

and an own layer meta-insidem2m which defines some image settings in
recipes-core/images/insidem2m-s.bb among other recipes for packages and
package modification.

Now I wan't to create a rootfs without the kernel image and the kernel
modules to make it as small as possible to use it as a basis to run as a
docker image.

Now I wonder how to instruct bitbake to not put the kernel image (and
modules) into the rootfs.

I read this was done by

RDEPENDS_${KERNEL_PACKAGE_NAME}-base = ""

but this is now deprecated for kirkstone and should be done this way:

RRECOMMENDS:${KERNEL_PACKAGE_NAME}-base = ""



This makes sense, I'll send a patch updating the documentation to 
reflect this change. I thought we already had discussed about this and 
someone sent a patch but doesn't seem so :/



But rootfs always still is equipped with kernel and modules.
I tried all permutations of

#RDEPENDS_kernel-base = ""
#MACHINE_ESSENTIAL_EXTRA_RDEPENDS = ""
#RDEPENDS_kernel-base = ""
#PREFERRED_PROVIDER_virtual/kernel = "linux-dummy"
# Don't include kernels in standard images
##RDEPENDS:kernel-base = ""
#RRECOMMENDS:${KERNEL_PACKAGE_NAME}-base = ""
#MACHINE_EXTRA_RRECOMMENDS = ""
#RDEPENDS_${KERNEL_PACKAGE_NAME}-base = ""

in my conf/local.conf but no avail...

How is this done correctly?
Are there any variables to check I might have (being) set preventing me
to do this? Or is it necessary to split out a new MACHINE, i.e. can this
only be done in an own created machine which has to be split out?

I thought setting such at the bottom of conf/local.conf always "wins".



No.

So I believe you need to add:
MACHINE_EXTRA_RRECOMMENDS:beaglebone-yocto = ""
MACHINE_ESSENTIAL_EXTRA_RDEPENDS:remove:beaglebone-yocto = "kernel-image 
kernel-devicetree"

RRECOMMENDS:${KERNEL_PACKAGE_NAME}-base = ""
to your local.conf

I suggest you create your own machine configuration file which requires 
beaglebone-yocto.conf where you'll be able to set:

MACHINE_EXTRA_RRECOMMENDS = ""
MACHINE_ESSENTIAL_EXTRA_RDEPENDS = ""
RRECOMMENDS:${KERNEL_PACKAGE_NAME}-base = ""

since one is not supposed to share their local.conf :)

You can check the value of a variable by running bitbake-getvar -r 
virtual/kernel MACHINE_EXTRA_RRECOMMENDS for example.


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58892): https://lists.yoctoproject.org/g/yocto/message/58892
Mute This Topic: https://lists.yoctoproject.org/mt/95815345/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] bitbake controlling memory use

[Quentin Schulz via lists.yoctoproject.org]

Hi Ferry,

On 1/3/23 15:29, Ferry Toth wrote:

Hi Alex,

Op 03-01-2023 om 15:18 schreef Alexander Kanavin:

I have to note that even the most expensive 16 Gb RAM module is less
than 100 Euro, and can be obtained for half that much. Surely you
value your time more than that?


Of course. And if I didn't I could reduce the number of `PARALLEL_MAKE`.

But I have also seen bitbake attempting to build nodejs, nodejs-native 
and binutils in parallel.


I think by default there are 4 tasks, with 16 threads, each could 
require 1GB RAM. Would you say, in such a case Yocto requires 64GB RAM?


And with increasing #cores it gets worse.

Not that it is too expensive to throw hardware at it, but it seems to be 
a fundamental problem that I would like to resolve. In my spare time of 
course.




Just to add that bitbake now supports pressure thresholds (since 
Kirkstone release I believe): 
https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-ref-variables.html#term-BB_PRESSURE_MAX_MEMORY


If your recipes put enough pressure on RAM before one or two of nodejs, 
nodejs-native and binutils gets scheduled, it would prevent that. 
However I believe if the timing is just right (unfortunate) and there's 
not enough pressure when all three recipes do_compile start, they would 
all start and you would have the same issue.


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58899): https://lists.yoctoproject.org/g/yocto/message/58899
Mute This Topic: https://lists.yoctoproject.org/mt/82015730/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] lsusb

[Quentin Schulz via lists.yoctoproject.org]

Hi Ron,

On 12/24/22 20:17, Mistyron wrote:

On 2022-12-24 08:38, Markus Volk wrote:
Am Sa, 24. Dez 2022 um 08:34:49 -0800 schrieb Mistyron 
:
$ grep usb path/to/package.manifest   libusb-1.0-0   usbutils 
usbutils-python


lsusb is part of usbutils, so it is not explicitly listed, but should 
be included in your image
Oh, I think the cleanall didn't wipe the cache sufficiently, after I 
deleted contents in sstate-cache/ I get the following:

$ tar -tvf path/to/myimage-20221224185313.rootfs.tar.gz  | grep lsusb
lrwxrwxrwx 0/0   0 2018-03-09 04:34 ./usr/bin/lsusb -> 
/usr/bin/lsusb.usbutils

-rwxr-xr-x 0/0   14266 2018-03-09 04:34 ./usr/bin/lsusb.py
-rwxr-xr-x 0/0  247976 2018-03-09 04:34 ./usr/bin/lsusb.usbutils
-rw-r--r-- 0/0  43 2018-03-09 04:34 
./usr/lib/opkg/alternatives/lsusb


I would expect "$ lsusb" to work now when I copy this to my board 
(cannot est right now)


the package.manifest however still only lists:

libusb-1.0-0
usbutils
usbutils-python



The package.manifest only contains packages so it's normal that lsusb 
does not appear there since there's no package *named* lsusb.


E.g. there's no lsusb package in Debian, but you can install it on your 
system via the usbutils package.


However, one can check which package provides the libusb binary by running
oe-pkgdata-util find-path '*/libusb'
it should return usbutils I believe.

Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58901): https://lists.yoctoproject.org/g/yocto/message/58901
Mute This Topic: https://lists.yoctoproject.org/mt/95858084/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Remove kernel image and modules from rootfs

[Quentin Schulz via lists.yoctoproject.org]

Hi Konstantin,

On 1/3/23 16:58, Konstantin Kletschke wrote:

On Mon, Jan 02, 2023 at 05:11:35PM +0100, Quentin Schulz wrote:


but this is now deprecated for kirkstone and should be done this way:

RRECOMMENDS:${KERNEL_PACKAGE_NAME}-base = ""



This makes sense, I'll send a patch updating the documentation to reflect
this change. I thought we already had discussed about this and someone sent
a patch but doesn't seem so :/


Thank you :-)


So I believe you need to add:
MACHINE_EXTRA_RRECOMMENDS:beaglebone-yocto = ""
MACHINE_ESSENTIAL_EXTRA_RDEPENDS:remove:beaglebone-yocto = "kernel-image
kernel-devicetree"
RRECOMMENDS:${KERNEL_PACKAGE_NAME}-base = ""
to your local.conf


Dear Quentin, this is correct. It worked this way.
I admit, I was not aware the config snippets I copied need to be
modified for the local.conf in a way the machine name has to be
appended!



So, you needed the extra :beaglebone-yocto because the machine 
configuration file is parsed after local.conf, therefore since 
beaglebone-yocto.conf file has:

MACHINE_EXTRA_RRECOMMENDS = "kernel-modules kernel-devicetree"
MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "kernel-image kernel-devicetree"
your local.conf changes would be overridden while parsing the machine 
configuration file.


By using the OVERRIDE mechanism, we kinda cheat this by making the 
variables in local.conf "more important" than the machine conf file's.


You don't need the :beaglebone-yocto OVERRIDE for the :remove but it's 
"better" this way so that if you build multiple machines with the same 
local.conf, you don't impact other machines as well.



I suggest you create your own machine configuration file which requires
beaglebone-yocto.conf where you'll be able to set:
MACHINE_EXTRA_RRECOMMENDS = ""
MACHINE_ESSENTIAL_EXTRA_RDEPENDS = ""
RRECOMMENDS:${KERNEL_PACKAGE_NAME}-base = ""


Meanwhile I did something similair, I cloned the machine
beaglebone-yocto into my tree with thos modifications on top and this
works too.



Would highly recommend not doing that though, having two configruation 
files with the same filename is not nice to your users, because then the 
order of inclusion of the layers will decide which file gets picked.


Create your own my-beaglebone and in there have:
MACHINEOVERRIDES =. "beaglebone-yocto:"
require conf/machine/beaglebone-yocto.conf

The first line will allow recipes to use the :beaglebone-yocto OVERRIDE 
to match both the original beaglebone-yocto and your my-beaglebone machines.



Thanks for your enormous useful hint to the modification needed for
local.conf and the tip to create a machine, inherit beaglebone-yocto and
modify those three variables.


You can check the value of a variable by running bitbake-getvar -r
virtual/kernel MACHINE_EXTRA_RRECOMMENDS for example.


Thank you, very useful.

Meanwhile I found out, for my puspose it could be useful to do something
like

CORE_IMAGE_BASE_INSTALL:remove = " packagegroup-core-boot 
packagegroup-base-extended"



Be careful, :remove are final, you cannot re-add its content later on. 
SO if you expect users to reuse and extend your image recipe while 
having :remove in there, you'll have unhappy users :)



in the image config, which might be even more useful for my approach to
my use case.

I now can approch my goal with local.conf, an additional machine or the
CORE_IMAGE_BASE_INSTALL modification.

One question though:

can the MACHINE variable only be modified in the local.conf (the
reference manual - glossary does not mention other places)?



It can be modified in any configuration file I believe, though 
local.conf is the only one that makes sense to me, anything else is bad 
practice.


However, you can pass MACHINE=my-beaglebone to bitbake, e.g.:
MACHINE=my-beaglebone bitbake my-image

would build my-image for this machine specifically.


If I go with the additional machine approach I am searching for a way to
build different images in my distro based on different machines. Is that
possible?



What exactly should be different between your images per machines? If 
we're talking about some specific BSP components differing (e.g. kernel, 
bootloader, tf-a, op-tee, etc... basically anything NOT userspace), it's 
better IMHO to specify those machine specific packages as 
MACHINE_EXTRA_RRECOMMENDS or MACHINE_ESSENTIAL_EXTRA_RDEPENDS in your 
machine configuration file. If it's something else, you can either 
(ab)use the OVERRIDE mechanism (:my-beaglebone) to specify packages to 
install only for one machine. E.g. in your image recipe:

IMAGE_INSTALL:append:my-beaglebone = " some-my-beaglebone-package"

If you want the same package but in different version or a different 
implementation (e.g. dropbear vs openssh, barebox vs uboot), have a look 
at virtual recipes (you can find consumers of those virtual recipes 
where virtual/somthing is used).


Finally, it might make more sense to just have multiple image recipes, 
each machine having its own image recipe for example.


Remember, distro is for 

Re: [yocto] SSTATE_DIR by MACHINE target?

[Quentin Schulz via lists.yoctoproject.org]

Hi Matt,

On 1/19/23 17:37, mattwood2...@gmail.com wrote:

Hi,

is it possible to have SSTATE_DIR overrides based on the MACHINE
target or SOC family?



What are you trying to do? Which problem are you trying to solve that 
would require this?



For example, is this valid:

SSTATE_DIR:sama5 = "/path/to/sstate_a5"
SSTATE_DIR:rpi = "/path/to/sstate_rpi"
...



It depends what exactly you want to do, because this would apply only to 
SSTATE cache for the recipes to build for the target. A Yocto build 
however is made of native and target recipes. The native recipes are 
compiled and run on the host, while target recipes are compiled on the 
host with native binaries from native recipes and run on the target. So 
native recipes would have their SSTATE cache in a common directory, 
whether you pick rpi or sama5 as your MACHINE.


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#59025): https://lists.yoctoproject.org/g/yocto/message/59025
Mute This Topic: https://lists.yoctoproject.org/mt/96380921/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] SSTATE_DIR by MACHINE target?

[Quentin Schulz via lists.yoctoproject.org]

Hi Matt,

On 1/20/23 14:23, mattwood2...@gmail.com wrote:

Hi Quentin,

I work with many different hardware platforms and architectures.  I keep my
SSTATE cache on a NAS drive and I was hoping to set up a site.conf that
would organize the full build  SSTATE cache by architecture.  It sounds
like this isn't exactly possible.



Except because of a personal preference of having things spatially 
separated, it doesn't make much sense to me. When you're building for 
multiple machines, some sstate-cache is shared. Such is the case of 
native recipes, but also some target architecture-specific recipes (e.g. 
something that is built for cortex-a55 cpu, will be reused for all 
machines based on this cpu). So it actually makes a lot of sense to 
share as much as possible between all your machines so that your builds 
are faster, feeding from other machines' builds, and you even save some 
space on your NAS.



I tried it and the SSTATE directory is still created in the default
location in the build directory instead of on my mount point.  I guess this
is the native SSTATE you are referring to.



You could have a .conf file specific to each machine and use it. Or also 
have this SSTATE_DIR variable directly in your machine.conf file. But 
again, I don't think there's much benefit in doing that :/


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#59027): https://lists.yoctoproject.org/g/yocto/message/59027
Mute This Topic: https://lists.yoctoproject.org/mt/96380921/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] ERROR: No recipes available for:

[Quentin Schulz via lists.yoctoproject.org]

Hi Murali,

On 2/17/23 06:59, Murali Krishna wrote:

Time: 0:00:00Loaded 3775 entries from dependency cache.ERROR: No recipes
available for:
/home/murali/test/sources/meta-boundary/recipes-browser/chromium/chromium_%.bbappend
/home/murali/test/sources/meta-boundary/recipes-bsp/u-boot/u-boot-fw-utils_2017.01.bbappend
/home/murali/test/sources/meta-boundary/recipes-bsp/u-boot/u-boot-script-boundary_git.bbappend
/home/murali/test/sources/meta-boundary/recipes-kernel/linux-firmware/linux-firmware_git.bbappend
/home/murali/test/sources/meta-boundary/recipes-mozilla/firefox/firefox_45.5.1esr.bbappendSummary:


bbappends are appending content to already existing recipes. There are 
two possible issues, for chromium_%.bbappend, no chromium recipe is 
found in the included layers, make sure the layer with chromium recipe 
is added with bitbake-layers add-layer.


For bbappends for version specific recipes, e.g. 
u-boot-fw-utils_2017.01.bbappend either u-boot-fw-utils recipe does not 
exist anymore, the layer containing it is not included in your build or 
the recipe does exist and the layer is included but the recipe is of a 
different version (e.g. 2019.07 or something like that).


I know u-boot-fw-utils has been renamed to libubootenv in some versions 
(don't remember if it was already the case in dunfell though).


But it is likely just a mismatch of the recipe version upon which the 
bbappend would be applied.


The fix is to find the new name of the recipe, update the bbappend to 
apply to the correct recipe version by changing its filename and/or add 
the necessary layers.


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#59240): https://lists.yoctoproject.org/g/yocto/message/59240
Mute This Topic: https://lists.yoctoproject.org/mt/97024538/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-rockchip][PATCH] nanopi-r4s: add

[Quentin Schulz via lists.yoctoproject.org]

Hi Trevor,

On 2/22/23 21:09, Trevor Woerner wrote:

Add a MACHINE definition for the FriendlyElec NanoPi R2S
https://urldefense.com/v3/__https://www.friendlyelec.com/index.php?route=product*product&product_id=284__;Lw!!OOPJP91ZZw!h-oSfHR_L6CGxqg2FDVatV20vOBPECbLP6rgKxl1ZfpRBpCKAywDT8kUfG-XYW_cCgvwd8DxfcDWrqwnYx8cY6nC-ubOB4w$

My testing shows that there still seems to be some issues with the SDcard
voltage regulator. The kernel has a number of fix attempts for this issue, but
I've seen it a couple times. Ejecting and re-inserting the SDcard gets past
the issue. Some SDcards show the issue, others don't.

Signed-off-by: Trevor Woerner 
---
  README |  1 +
  conf/machine/nanopi-r4s.conf   | 12 
  recipes-kernel/linux/linux-yocto%.bbappend |  1 +
  3 files changed, 14 insertions(+)
  create mode 100644 conf/machine/nanopi-r4s.conf

diff --git a/README b/README
index d66ed7e79bd2..286dafbe1020 100644
--- a/README
+++ b/README
@@ -29,6 +29,7 @@ Status of supported boards:
tinker-board-s
vyasa-rk3288
firefly-rk3288
+   nanopi-r4s
builds:
marsboard-rk3066
radxarock
diff --git a/conf/machine/nanopi-r4s.conf b/conf/machine/nanopi-r4s.conf
new file mode 100644
index ..e3323e03b61a
--- /dev/null
+++ b/conf/machine/nanopi-r4s.conf
@@ -0,0 +1,12 @@
+#@TYPE: Machine
+#@NAME: NanoPi R4S
+#@DESCRIPTION: NanoPi R2S is a high-end FriendlyElec mini-router based on the 
RK3399 SoC
+


s/R2S/R4S/

Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#59321): https://lists.yoctoproject.org/g/yocto/message/59321
Mute This Topic: https://lists.yoctoproject.org/mt/9716/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-raspberrypi] Enabling libcamera-apps

[Quentin Schulz via lists.yoctoproject.org]

Hi,

On 3/15/23 10:14, punctuation via lists.yoctoproject.org wrote:

Dear community,

how do I i include libcamera-apps in my image?

I have tried with:
IMAGE_INSTALL += "libcamera-apps"

But it doesn't find the libcamera-apps recipe.



It seems it is only available in langdale and master (mickledore) branch 
in meta-raspberrypi layer, c.f. 
https://layers.openembedded.org/layerindex/recipe/327281/


It is also called rpi-libcamera-apps.

Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#59429): https://lists.yoctoproject.org/g/yocto/message/59429
Mute This Topic: https://lists.yoctoproject.org/mt/97623603/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Compilation of z3gateway

[Quentin Schulz via lists.yoctoproject.org]

Hi Hassan,

I believe the issue is that the Makefile is not in your `S` directory.

You can run `pwd` in do_install and check where the Makefile is relative 
to this path and update S to point to this or make sure SRC_URI installs 
your file in the directory pointed to by S.


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#59676): https://lists.yoctoproject.org/g/yocto/message/59676
Mute This Topic: https://lists.yoctoproject.org/mt/98104663/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Need help with CMake cross compile using libxml2

[Quentin Schulz via lists.yoctoproject.org]

Hi Stephen,

On 4/11/23 02:00, Stephen Yu (Microchip) via lists.yoctoproject.org wrote:

Hello Community,

My CMake project needs to cross compile (.c sources) using libxml2.

   *   The CMakeLists.txt has "find_package(LibXml2)"
   *   The recipe.bb has
  *   "DEPENDS += "libxml2"
  *   "inherit cmake"



I think you may need to inherit pkgconfig class too if your cmake relies 
on this to find packages.


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#59677): https://lists.yoctoproject.org/g/yocto/message/59677
Mute This Topic: https://lists.yoctoproject.org/mt/98188210/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Rootless Podman

[Quentin Schulz via lists.yoctoproject.org]

Hi,

I, too, am using rootless podman on Fedora 38 (and 36 and 37 in the past).

I use kas container for building:

podman run -it --rm --userns=keep-id -e USER_ID=$UID -e GROUP_ID=$GID -v 
~/work/yocto/sstate-cache:$HOME/work/yocto/sstate-cache -v 
~/work/yocto/downloads/:$HOME/work/yocto/downloads -w $PWD -v 
"$PWD":"$PWD" -v "$SSH_AUTH_SOCK":"$SSH_AUTH_SOCK" -e SSH_AUTH_SOCK 
--security-opt label=disable --tmpfs /tmp ghcr.io/siemens/kas/kas:3.1 shell


You may want to not disable security labels and do it properly though :)

--tmpfs /tmp was essential. I don't remember the exact issue but this 
was raised in a GitHub issue by Trevor Woerner (added in Cc). I found 
this discussion in kas Google groups talking a bit more in-depth about 
this very topic: 
https://groups.google.com/g/kas-devel/c/Dm3OcBS-yao/m/u5CV9JrVAgAJ. See 
some other discussion here: 
https://lore.kernel.org/all/5a44f13b-f383-449c-8fb9-87bebef12...@0leil.net/T/#m381e450b92ac0a313be522600bbaa14a50b1fa78


For some of our debian (bullseye) based servers with many cores, we had 
to modify the pids_limit for podman too.


In /etc/containers/containers.conf, have:
pids_limit = 100

I was convinced I modified some wiki to list this somewhere but the 
search bar didn't return anything unfortunately :/


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60762): https://lists.yoctoproject.org/g/yocto/message/60762
Mute This Topic: https://lists.yoctoproject.org/mt/100627665/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Question: Sharing SSTATE_DIR and DL_DIR through Lustre/NFS for team work

[Quentin Schulz via lists.yoctoproject.org]

Hi all,

On 9/11/23 09:36, Alexander Kanavin via lists.yoctoproject.org wrote:

On Mon, 11 Sept 2023 at 06:22, Chen Qi via lists.yoctoproject.org
 wrote:


SSTATE_DIR and DL_DIR are writable. Sharing them among different builds
owned/controlled by the same user is OK, but sharing these writable
directories among different users does not seem to be a good idea.
You could consider using the PREMIRRORS and SSTATE_MIRRORS.


This is not accurate. SSTATE_DIR is designed to be shared in a
read-write fashion via NFS or other over the network filesystem
(between users on the same machine is also ok), and is heavily used
that way in Yocto CI.



But sharing the same SSTATE_DIR with people running cleansstate or 
manually removing entries is an issue as far as I remember. I don't know 
if mount allows to mount file systems with read and write but not erase 
permissions?


On a separate note, we've setup NFS donwload cache for Buildroot and 
Yocto and for one (maybe both?) we had an issue with filelocks. 
Basically we had one disk on one of the build servers which we exposed 
through NFS share to other build servers and users. However, the 
filelocks weren't respected when one was set in NFS (or ext4) and 
checked against in ext4 (or NFS respectively). So I suggest to be 
mindful about this when setting up your infrastructure and use the same 
FS across all users (you can mount a local FS with NFS as far as I 
remember).


I haven't done that yet but I believe one is supposed to share the 
hashequiv server too for max reusability? I am unfortunately not 
familiar with it but just wanted to raise this.


Cheers,
Quentin


Sharing DL_DIR is less important as it is not that large, and
downloading does not slow down the builds that much compared to the
the actual build (and only needs to happen once).

Li, your understanding is more or less completely correct. The
difficulties are mostly in scaling up, where you might hit the limits
of how many users can be served at the same time.

Alex






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60968): https://lists.yoctoproject.org/g/yocto/message/60968
Mute This Topic: https://lists.yoctoproject.org/mt/101284965/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Overriding package configuration as a distro

[Quentin Schulz via lists.yoctoproject.org]

Hi Logan,

On 9/18/23 16:43, Logan Grosz via lists.yoctoproject.org wrote:

You don't often get email from logan.grosz=b9c@lists.yoctoproject.org. Learn why 
this is important
Hi, all

I have two distros in the same meta layer, "A" and "B," and a recipe which installs a configuration file 
existing in a layer elsewhere. "A" and "B" should provide different configuration files, overriding the 
original configuration. It seems less than ideal to create a bbappend in this scenario as that would require the bbappend to know 
about the various distros and even handle the case where neither distro is chosen, some other "C" distro may be built 
for. My goal is a distro-centric configuration rather than a recipe/package-centric one. How can I do this? Does this align with 
the framework, or should I be looking into a different solution for this problem?



The distro name is already part of FILESOVERRIDES so you can just add 
your configuration file in a directory named after your distro. e.g. 
provided your distro is called logan-distro, the following makes it 
possible to override the configuration file from another layer:


```
# cat recipes-foo/bar/bar-1.0.0/logan-distro/file.conf
meh
# cat recipes-foo/bar/bar_1.0.0.bbappend
FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}-${PV}:"
```

no need to modify anything else if the file.conf file is added via 
SRC_URI mechanism, otherwise you'll need to add a bit more to the 
bbappend (or use patches instead), probably via a do_configure:prepend 
or even do_patch:append (I think the file fetcher also allows to install 
directly in the proper directory via subdir= parameter?).


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61034): https://lists.yoctoproject.org/g/yocto/message/61034
Mute This Topic: https://lists.yoctoproject.org/mt/101434764/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-rockchip][PATCH] rock5b: add

[Quentin Schulz via lists.yoctoproject.org]

Hi Trevor,

Looking good :) Thanks for looking into it, will be helpful to me in the 
upcoming weeks/months :)


On 9/22/23 04:51, Trevor Woerner via lists.yoctoproject.org wrote:

Add support for the Radxa Rock 5B
https://wiki.radxa.com/Rock5/5b

The device-tree for this board is better in the 6.5 (and later) kernels,
therefore set the kernel to linux-yocto-dev for now (eventually this won't be
needed as linux-yocto moves forward).

The Trusted Firmware A project (TF-A git://git.trustedfirmware.org/TF-A)
does not currently support the rk3588, but patches are in review. For
the time-being we're using the binary DDR/TPL initialization blob from
https://github.com/rockchip-linux/rkbin. Hopefully this can change if/when
TF-A gains support for the rk3588.



Because it's closed source, I cannot tell if DDR binary is based off 
TF-A but I would say it's likely not? It's fine like this but not 
entirely sure it's true.



The rk3588 comes in two variants: rk3588 and rk3588s. The "s" option is a
stripped-down version of the rk3588. In the Linux kernel these two SoCs are
kept separate, with the rk3588 building on the rk3588s, so we've mimicked that
same behaviour here.

Signed-off-by: Quentin Schulz 


I may have improperly wrote this in the github commit I sent you, but my 
professional mail address is:

quentin.sch...@theobroma-systems.com
:)


Signed-off-by: Trevor Woerner 
---
  README|  1 +
  conf/machine/include/rk3588.inc   |  8 ++
  conf/machine/include/rk3588s-base.inc | 16 
  conf/machine/include/rk3588s.inc  |  5 ++
  conf/machine/rock5b.conf  | 12 +++
  recipes-bsp/rkbin/rockchip-rkbin_git.bb   | 37 
  recipes-bsp/u-boot/u-boot%.bbappend   |  5 ++
  recipes-kernel/linux/linux-yocto-dev.bbappend |  3 +
  .../rockchip/remove-non-rockchip-arch-arm.cfg | 85 +++
  .../rockchip/remove-non-rockchip-arch-arm.scc |  1 +
  .../remove-non-rockchip-arch-arm64.cfg| 66 ++
  .../remove-non-rockchip-arch-arm64.scc|  1 +
  12 files changed, 240 insertions(+)
  create mode 100644 conf/machine/include/rk3588.inc
  create mode 100644 conf/machine/include/rk3588s-base.inc
  create mode 100644 conf/machine/include/rk3588s.inc
  create mode 100644 conf/machine/rock5b.conf
  create mode 100644 recipes-bsp/rkbin/rockchip-rkbin_git.bb
  create mode 100644 recipes-kernel/linux/linux-yocto-dev.bbappend
  create mode 100644 
recipes-kernel/linux/linux-yocto-dev/rockchip-kmeta/bsp/rockchip/remove-non-rockchip-arch-arm.cfg
  create mode 100644 
recipes-kernel/linux/linux-yocto-dev/rockchip-kmeta/bsp/rockchip/remove-non-rockchip-arch-arm.scc
  create mode 100644 
recipes-kernel/linux/linux-yocto-dev/rockchip-kmeta/bsp/rockchip/remove-non-rockchip-arch-arm64.cfg
  create mode 100644 
recipes-kernel/linux/linux-yocto-dev/rockchip-kmeta/bsp/rockchip/remove-non-rockchip-arch-arm64.scc

diff --git a/README b/README
index 286dafbe1020..032d9bbb6b34 100644
--- a/README
+++ b/README
@@ -30,6 +30,7 @@ Status of supported boards:
vyasa-rk3288
firefly-rk3288
nanopi-r4s
+   rock5b
builds:
marsboard-rk3066
radxarock
diff --git a/conf/machine/include/rk3588.inc b/conf/machine/include/rk3588.inc
new file mode 100644
index ..d358565a904d
--- /dev/null
+++ b/conf/machine/include/rk3588.inc
@@ -0,0 +1,8 @@
+# the rk3588s is a "stripped-down" version of the rk3588
+# in the kernel's device-tree the rk3588 builds on top of the rk3588s
+# so anything that is valid for the rk3588s is valid for the rk3588
+MACHINEOVERRIDES =. "rk3588:rk3588s:"


This is incorrect, this makes rk3588s have precedence over rk3588, which 
is wrong for rk3588-based devices. Why not have MACHINEOVERRIDES for 
rk3588s in rk3588s-base.inc instead?



+require conf/machine/include/rk3588s-base.inc
+
+SOC_FAMILY = "rk3588"
+require conf/machine/include/soc-family.inc


The two lines above actually do MACHINEOVERRIDES =. "rk3588"
so we don't need to repeat it.


diff --git a/conf/machine/include/rk3588s-base.inc 
b/conf/machine/include/rk3588s-base.inc
new file mode 100644
index ..ad74a1895ec0
--- /dev/null
+++ b/conf/machine/include/rk3588s-base.inc
@@ -0,0 +1,16 @@
+DEFAULTTUNE ?= "cortexa76-cortexa55-crypto"
+
+require conf/machine/include/arm/armv8-2a/tune-cortexa76-cortexa55.inc
+require conf/machine/include/rockchip-defaults.inc
+require conf/machine/include/rockchip-wic.inc
+
+KBUILD_DEFCONFIG ?= "defconfig"
+KERNEL_FEATURES:append:rk3588 = " 
bsp/rockchip/remove-non-rockchip-arch-arm64.scc"
+KERNEL_CLASSES = "kernel-fitimage"
+KERNEL_IMAGETYPE = "fitImage"
+
+PREFERRED_PROVIDER_trusted-firmware-a = "rockchip-rkbin"
+PREFERRED_PROVIDER_optee-os = "rockchip-rkbin"
+
+UBOOT_SUFFIX ?= "itb"
+UBOOT_ENTRYPOINT ?= "0x0600"
diff --git a/conf/machine/include/rk3588s.inc b/conf/machine/include/rk3588s.

Re: [yocto] [meta-rockchip][PATCH] rock5b: add

[Quentin Schulz via lists.yoctoproject.org]

Hi Trevor,

On 9/22/23 17:06, Trevor Woerner wrote:

On Fri 2023-09-22 @ 04:22:11 PM, Quentin Schulz wrote:

Hi Trevor,

Looking good :) Thanks for looking into it, will be helpful to me in the
upcoming weeks/months :)

On 9/22/23 04:51, Trevor Woerner via lists.yoctoproject.org wrote:

Add support for the Radxa Rock 5B
https://wiki.radxa.com/Rock5/5b

The device-tree for this board is better in the 6.5 (and later) kernels,
therefore set the kernel to linux-yocto-dev for now (eventually this won't be
needed as linux-yocto moves forward).

The Trusted Firmware A project (TF-A git://git.trustedfirmware.org/TF-A)
does not currently support the rk3588, but patches are in review. For
the time-being we're using the binary DDR/TPL initialization blob from
https://github.com/rockchip-linux/rkbin. Hopefully this can change if/when
TF-A gains support for the rk3588.



Because it's closed source, I cannot tell if DDR binary is based off TF-A
but I would say it's likely not? It's fine like this but not entirely sure
it's true.


Does this sound like I believe the binary blob is based on TF-A? If so I'll
need to reword. I'm literally trying to say the opposite. I.e. we can't use
TF-A yet so we're stuck using the blob... for now.



I can suggest:
"""
The upstream Trusted Firmware A project (TF-A 
git://git.trustedfirmware.org/TF-A) does not currently support the 
rk3588, but patches are in review. Until it gains support, we are stuck 
with blob provided by Rockchip in .
Similarly, U-Boot doesn't have support for DDR initialization on rk3588 
yet and only a blob has been provided by Rockchip in link>, so we've no choice but use that one until proper DDR init is 
added to U-Boot upstream.

"""

what do you think?


The rk3588 comes in two variants: rk3588 and rk3588s. The "s" option is a
stripped-down version of the rk3588. In the Linux kernel these two SoCs are
kept separate, with the rk3588 building on the rk3588s, so we've mimicked that
same behaviour here.

Signed-off-by: Quentin Schulz 


I may have improperly wrote this in the github commit I sent you, but my
professional mail address is:
quentin.sch...@theobroma-systems.com
:)


lol, I was wondering why that bounced.



Mystery solved :)




Signed-off-by: Trevor Woerner 
---
   README|  1 +
   conf/machine/include/rk3588.inc   |  8 ++
   conf/machine/include/rk3588s-base.inc | 16 
   conf/machine/include/rk3588s.inc  |  5 ++
   conf/machine/rock5b.conf  | 12 +++
   recipes-bsp/rkbin/rockchip-rkbin_git.bb   | 37 
   recipes-bsp/u-boot/u-boot%.bbappend   |  5 ++
   recipes-kernel/linux/linux-yocto-dev.bbappend |  3 +
   .../rockchip/remove-non-rockchip-arch-arm.cfg | 85 +++
   .../rockchip/remove-non-rockchip-arch-arm.scc |  1 +
   .../remove-non-rockchip-arch-arm64.cfg| 66 ++
   .../remove-non-rockchip-arch-arm64.scc|  1 +
   12 files changed, 240 insertions(+)
   create mode 100644 conf/machine/include/rk3588.inc
   create mode 100644 conf/machine/include/rk3588s-base.inc
   create mode 100644 conf/machine/include/rk3588s.inc
   create mode 100644 conf/machine/rock5b.conf
   create mode 100644 recipes-bsp/rkbin/rockchip-rkbin_git.bb
   create mode 100644 recipes-kernel/linux/linux-yocto-dev.bbappend
   create mode 100644 
recipes-kernel/linux/linux-yocto-dev/rockchip-kmeta/bsp/rockchip/remove-non-rockchip-arch-arm.cfg
   create mode 100644 
recipes-kernel/linux/linux-yocto-dev/rockchip-kmeta/bsp/rockchip/remove-non-rockchip-arch-arm.scc
   create mode 100644 
recipes-kernel/linux/linux-yocto-dev/rockchip-kmeta/bsp/rockchip/remove-non-rockchip-arch-arm64.cfg
   create mode 100644 
recipes-kernel/linux/linux-yocto-dev/rockchip-kmeta/bsp/rockchip/remove-non-rockchip-arch-arm64.scc

diff --git a/README b/README
index 286dafbe1020..032d9bbb6b34 100644
--- a/README
+++ b/README
@@ -30,6 +30,7 @@ Status of supported boards:
vyasa-rk3288
firefly-rk3288
nanopi-r4s
+   rock5b
builds:
marsboard-rk3066
radxarock
diff --git a/conf/machine/include/rk3588.inc b/conf/machine/include/rk3588.inc
new file mode 100644
index ..d358565a904d
--- /dev/null
+++ b/conf/machine/include/rk3588.inc
@@ -0,0 +1,8 @@
+# the rk3588s is a "stripped-down" version of the rk3588
+# in the kernel's device-tree the rk3588 builds on top of the rk3588s
+# so anything that is valid for the rk3588s is valid for the rk3588
+MACHINEOVERRIDES =. "rk3588:rk3588s:"


This is incorrect, this makes rk3588s have precedence over rk3588, which is
wrong for rk3588-based devices. Why not have MACHINEOVERRIDES for rk3588s in
rk3588s-base.inc instead?


+require conf/machine/include/rk3588s-base.inc
+
+SOC_FAMILY = "rk3588"
+require conf/machine/include/soc-family.inc


The two lines above actually do MACHINEOVERRIDES =. "rk3588"
so we don't need to 

Re: [yocto] [meta-rockchip][PATCH v2] rock5b: add

[Quentin Schulz via lists.yoctoproject.org]

Hi Trevor,

On 9/22/23 23:26, Trevor Woerner wrote:

Add support for the Radxa Rock 5B
https://wiki.radxa.com/Rock5/5b

The device-tree for this board is better in the 6.5 (and later) kernels,
therefore set the kernel to linux-yocto-dev for now (eventually this won't be
needed as linux-yocto moves forward).

Unfortunately the TF-A project does not currently have support for
the rk3588. Therefore, for the time-being, the only way to supply a
TPL/DDR-init for the rk3588 is to use the closed-source rkbin binaries
from Rockchip. If/when TF-A adds support for the rk3588 we can investigate
switching.

The rk3588 comes in two variants: rk3588 and rk3588s. The "s" option is a
stripped-down version of the rk3588. In the Linux kernel these two SoCs are
kept separate, with the rk3588 building on the rk3588s, so we've mimicked that
same behaviour here.

Signed-off-by: Quentin Schulz 
Signed-off-by: Trevor Woerner 
---
v2:
- fix the logic behind the MACHINEOVERRIDES to get the content, and
   ordering, correct
- improved the commit message around TF-A/rkbin
- correct Quentin's SoB line
---
  README|  1 +
  conf/machine/include/rk3588.inc   |  6 ++
  conf/machine/include/rk3588s.inc  | 17 
  conf/machine/rock5b.conf  | 12 +++
  recipes-bsp/rkbin/rockchip-rkbin_git.bb   | 37 
  recipes-bsp/u-boot/u-boot%.bbappend   |  5 ++
  recipes-kernel/linux/linux-yocto-dev.bbappend |  3 +
  .../rockchip/remove-non-rockchip-arch-arm.cfg | 85 +++
  .../rockchip/remove-non-rockchip-arch-arm.scc |  1 +
  .../remove-non-rockchip-arch-arm64.cfg| 66 ++
  .../remove-non-rockchip-arch-arm64.scc|  1 +
  11 files changed, 234 insertions(+)
  create mode 100644 conf/machine/include/rk3588.inc
  create mode 100644 conf/machine/include/rk3588s.inc
  create mode 100644 conf/machine/rock5b.conf
  create mode 100644 recipes-bsp/rkbin/rockchip-rkbin_git.bb
  create mode 100644 recipes-kernel/linux/linux-yocto-dev.bbappend
  create mode 100644 
recipes-kernel/linux/linux-yocto-dev/rockchip-kmeta/bsp/rockchip/remove-non-rockchip-arch-arm.cfg
  create mode 100644 
recipes-kernel/linux/linux-yocto-dev/rockchip-kmeta/bsp/rockchip/remove-non-rockchip-arch-arm.scc
  create mode 100644 
recipes-kernel/linux/linux-yocto-dev/rockchip-kmeta/bsp/rockchip/remove-non-rockchip-arch-arm64.cfg
  create mode 100644 
recipes-kernel/linux/linux-yocto-dev/rockchip-kmeta/bsp/rockchip/remove-non-rockchip-arch-arm64.scc

diff --git a/README b/README
index 286dafbe1020..032d9bbb6b34 100644
--- a/README
+++ b/README
@@ -30,6 +30,7 @@ Status of supported boards:
vyasa-rk3288
firefly-rk3288
nanopi-r4s
+   rock5b
builds:
marsboard-rk3066
radxarock
diff --git a/conf/machine/include/rk3588.inc b/conf/machine/include/rk3588.inc
new file mode 100644
index ..34f0627dc085
--- /dev/null
+++ b/conf/machine/include/rk3588.inc
@@ -0,0 +1,6 @@
+MACHINEOVERRIDES =. "rk3588:"
+
+# the rk3588s is a "stripped-down" version of the rk3588
+# in the kernel's device-tree the rk3588 builds on top of the rk3588s
+# so anything that is valid for the rk3588s is valid for the rk3588
+require conf/machine/include/rk3588s.inc
diff --git a/conf/machine/include/rk3588s.inc b/conf/machine/include/rk3588s.inc
new file mode 100644
index ..65d9054e88d8
--- /dev/null
+++ b/conf/machine/include/rk3588s.inc
@@ -0,0 +1,17 @@
+MACHINEOVERRIDES =. "rk3588s:"
+DEFAULTTUNE ?= "cortexa76-cortexa55-crypto"
+
+require conf/machine/include/arm/armv8-2a/tune-cortexa76-cortexa55.inc
+require conf/machine/include/rockchip-defaults.inc
+require conf/machine/include/rockchip-wic.inc
+
+KBUILD_DEFCONFIG ?= "defconfig"
+KERNEL_FEATURES:append:rk3588 = " 
bsp/rockchip/remove-non-rockchip-arch-arm64.scc"


I believe this is supposed to be an OVERRIDES for rk3588s and not rk3588 
since it applies to both (in addition of being in the rk3588s.inc file).


The rest looks fine otherwise :)

Thanks!

Cheers,
Quentin


+KERNEL_CLASSES = "kernel-fitimage"
+KERNEL_IMAGETYPE = "fitImage"
+
+PREFERRED_PROVIDER_trusted-firmware-a = "rockchip-rkbin"
+PREFERRED_PROVIDER_optee-os = "rockchip-rkbin"
+
+UBOOT_SUFFIX ?= "itb"
+UBOOT_ENTRYPOINT ?= "0x0600"
diff --git a/conf/machine/rock5b.conf b/conf/machine/rock5b.conf
new file mode 100644
index ..dc31a9f3a4e4
--- /dev/null
+++ b/conf/machine/rock5b.conf
@@ -0,0 +1,12 @@
+#@TYPE: Machine
+#@NAME: Radxa Rock5b
+#@DESCRIPTION: ROCK5 is the 5th generation of SBC designed by Radxa.
+#https://wiki.radxa.com/Rock5/5b
+
+require conf/machine/include/rk3588.inc
+
+PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-dev"
+KERNEL_DEVICETREE = "rockchip/rk3588-rock-5b.dtb"
+MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
+
+UBOOT_MACHINE = "rock5b-rk3588_defconfig"
diff --git a/recipes-bsp/rkbin/rockchip-rkbin_git.bb 
b/recipe

Re: [yocto] [meta-rockchip][PATCH v3] rock-5b: add

[Quentin Schulz via lists.yoctoproject.org]

Hi Trevor,

On 9/25/23 18:26, Trevor Woerner wrote:

Add support for the Radxa Rock 5B
https://wiki.radxa.com/Rock5/5b

The device-tree for this board is better in the 6.5 (and later) kernels,
therefore set the kernel to linux-yocto-dev for now (eventually this won't be
needed as linux-yocto moves forward).

Unfortunately the TF-A project does not currently have support for
the rk3588. Therefore, for the time-being, the only way to supply a
TPL/DDR-init for the rk3588 is to use the closed-source rkbin binaries
from Rockchip. If/when TF-A adds support for the rk3588 we can investigate
switching.

The rk3588 comes in two variants: rk3588 and rk3588s. The "s" option is a
stripped-down version of the rk3588. In the Linux kernel these two SoCs are
kept separate, with the rk3588 building on the rk3588s, so we've mimicked that
same behaviour here.

Signed-off-by: Quentin Schulz 
Signed-off-by: Trevor Woerner 
---
v3:
- change name from "rock5b" to "rock-5b", there seem to be more instances
   of the latter on the manufacturer's website than the former
- fix the MACHINEOVERRIDE in conf/machine/include/rk3588s.inc to be
   "rk3588s" and not "rk3588"

v2:
- fix the logic behind the MACHINEOVERRIDES to get the content, and
   ordering, correct
- improved the commit message around TF-A/rkbin
- correct Quentin's SoB line
---
  README|  1 +
  conf/machine/include/rk3588.inc   |  6 ++
  conf/machine/include/rk3588s.inc  | 17 
  conf/machine/rock-5b.conf | 12 +++
  recipes-bsp/rkbin/rockchip-rkbin_git.bb   | 37 
  recipes-bsp/u-boot/u-boot%.bbappend   |  5 ++
  recipes-kernel/linux/linux-yocto-dev.bbappend |  3 +
  .../rockchip/remove-non-rockchip-arch-arm.cfg | 85 +++
  .../rockchip/remove-non-rockchip-arch-arm.scc |  1 +
  .../remove-non-rockchip-arch-arm64.cfg| 66 ++
  .../remove-non-rockchip-arch-arm64.scc|  1 +
  11 files changed, 234 insertions(+)
  create mode 100644 conf/machine/include/rk3588.inc
  create mode 100644 conf/machine/include/rk3588s.inc
  create mode 100644 conf/machine/rock-5b.conf
  create mode 100644 recipes-bsp/rkbin/rockchip-rkbin_git.bb
  create mode 100644 recipes-kernel/linux/linux-yocto-dev.bbappend
  create mode 100644 
recipes-kernel/linux/linux-yocto-dev/rockchip-kmeta/bsp/rockchip/remove-non-rockchip-arch-arm.cfg
  create mode 100644 
recipes-kernel/linux/linux-yocto-dev/rockchip-kmeta/bsp/rockchip/remove-non-rockchip-arch-arm.scc
  create mode 100644 
recipes-kernel/linux/linux-yocto-dev/rockchip-kmeta/bsp/rockchip/remove-non-rockchip-arch-arm64.cfg
  create mode 100644 
recipes-kernel/linux/linux-yocto-dev/rockchip-kmeta/bsp/rockchip/remove-non-rockchip-arch-arm64.scc

diff --git a/README b/README
index 286dafbe1020..d4576d73c636 100644
--- a/README
+++ b/README
@@ -30,6 +30,7 @@ Status of supported boards:
vyasa-rk3288
firefly-rk3288
nanopi-r4s
+   rock-5b
builds:
marsboard-rk3066
radxarock
diff --git a/conf/machine/include/rk3588.inc b/conf/machine/include/rk3588.inc
new file mode 100644
index ..34f0627dc085
--- /dev/null
+++ b/conf/machine/include/rk3588.inc
@@ -0,0 +1,6 @@
+MACHINEOVERRIDES =. "rk3588:"
+
+# the rk3588s is a "stripped-down" version of the rk3588
+# in the kernel's device-tree the rk3588 builds on top of the rk3588s
+# so anything that is valid for the rk3588s is valid for the rk3588
+require conf/machine/include/rk3588s.inc
diff --git a/conf/machine/include/rk3588s.inc b/conf/machine/include/rk3588s.inc
new file mode 100644
index ..7bfc9474e96e
--- /dev/null
+++ b/conf/machine/include/rk3588s.inc
@@ -0,0 +1,17 @@
+MACHINEOVERRIDES =. "rk3588s:"
+DEFAULTTUNE ?= "cortexa76-cortexa55-crypto"
+
+require conf/machine/include/arm/armv8-2a/tune-cortexa76-cortexa55.inc
+require conf/machine/include/rockchip-defaults.inc
+require conf/machine/include/rockchip-wic.inc
+
+KBUILD_DEFCONFIG ?= "defconfig"
+KERNEL_FEATURES:append:rk3588s = " 
bsp/rockchip/remove-non-rockchip-arch-arm64.scc"
+KERNEL_CLASSES = "kernel-fitimage"
+KERNEL_IMAGETYPE = "fitImage"
+
+PREFERRED_PROVIDER_trusted-firmware-a = "rockchip-rkbin"
+PREFERRED_PROVIDER_optee-os = "rockchip-rkbin"
+
+UBOOT_SUFFIX ?= "itb"
+UBOOT_ENTRYPOINT ?= "0x0600"
diff --git a/conf/machine/rock-5b.conf b/conf/machine/rock-5b.conf
new file mode 100644
index ..d1371084becc
--- /dev/null
+++ b/conf/machine/rock-5b.conf
@@ -0,0 +1,12 @@
+#@TYPE: Machine
+#@NAME: Radxa Rock 5B
+#@DESCRIPTION: ROCK5 is the 5th generation of SBC designed by Radxa.
+#https://wiki.radxa.com/Rock5/5b
+
+require conf/machine/include/rk3588.inc
+
+PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-dev"
+KERNEL_DEVICETREE = "rockchip/rk3588-rock-5b.dtb"
+MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
+
+UBOOT_MACHINE = "rock5b-rk3588_defconfig"
diff --git a/recipes-bsp/rk

Re: [yocto] [meta-rockchip] [PATCH] Allow KERNEL_IMAGETYPE override v2

[Quentin Schulz via lists.yoctoproject.org]

Hi Anthony,

Thanks for the patch!

On 9/26/23 06:36, Anthony Davies via lists.yoctoproject.org wrote:

[You don't often get email from 
anthony.t.davies=gmail@lists.yoctoproject.org. Learn why this is important 
at https://aka.ms/LearnAboutSenderIdentification ]

From: Anthony Davies 

Apologies, this is the correct patch

Updated inc files to allow overriding KERNEL_IMAGETYPE in local.conf

Fixed bug where dtb couldnt be found when generating KERNEL_IMAGETYPE
other then fitImage image due to KERNEL_DEVICETREE containing the dtb
directory which is not available in the DEPLOY_DIR_IMAGE directory


Here we are missing your Signed-off-by.

I would highly suggest to split this into two separate commits, one for 
allowing to override the KERNEL_IMAGETYPE through local.conf and another 
one for the device tree thing.


On another topic, I really feel like this is more of an issue with the 
class handling KERNEL_DEVICETREE when we're not using a fitImage don't 
you think? Otherwise all layers will have to fix this one up and I don't 
think that's the right way to go.


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61119): https://lists.yoctoproject.org/g/yocto/message/61119
Mute This Topic: https://lists.yoctoproject.org/mt/101589776/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-rockchip] [PATCH] Allow KERNEL_IMAGETYPE override v2

[Quentin Schulz via lists.yoctoproject.org]

Hi Anthony,

On 9/26/23 10:25, Anthony Davies wrote:

Hi Quentin

Happy to contribute but not all that familiar with emailing patches, sorry.



The Signed-off-by needs to be present in the commit log already, it is 
not related to mailing list submission. It is added with git commit 
--signoff (or git commit -s), c.f. 
https://docs.yoctoproject.org/contributor-guide/submit-changes.html. 
You're not the first one to forget it (or not know about it), nor will 
you be the last one, so no worries :)



I lumped them together because if you modify the KERNEL_IMAGETYPE you
trigger the bug.



But... you're not modifying the KERNEL_IMAGETYPE, you're merely allow it 
to be changed. So you're technically not introducing a bug. And if we 
wanted to be pedantic, we could say that this bug can technically 
already be triggered by changing the KERNEL_IMAGETYPE in the machine 
configuration file (and not in local.conf).


If you want to make sure one cannot modify the KERNEL_IMAGETYPE and 
break the build, then you can add the commit handling the devicetree 
before the one allowing to override the image type.



I agree moving it out of the include file would be the best way to go
but if you dont have the directory in the KERNEL_DEVICETREE it will
fail to compile, quickly searching other layers are handling it
similar to how I have, probably just in a more robust way.



This means we really need to fix this in openembedded-core! We shouldn't 
rely on all layers to fix it themselves if we can avoid it.


Regards,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61121): https://lists.yoctoproject.org/g/yocto/message/61121
Mute This Topic: https://lists.yoctoproject.org/mt/101589776/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-rockchip] [PATCH] Allow KERNEL_IMAGETYPE override v2

[Quentin Schulz via lists.yoctoproject.org]

On 9/26/23 11:13, Quentin Schulz via lists.yoctoproject.org wrote:

Hi Anthony,

On 9/26/23 10:25, Anthony Davies wrote:

Hi Quentin

Happy to contribute but not all that familiar with emailing patches, 
sorry.




The Signed-off-by needs to be present in the commit log already, it is 
not related to mailing list submission. It is added with git commit 
--signoff (or git commit -s), c.f. 
https://docs.yoctoproject.org/contributor-guide/submit-changes.html. You're not the first one to forget it (or not know about it), nor will you be the last one, so no worries :)



I lumped them together because if you modify the KERNEL_IMAGETYPE you
trigger the bug.



But... you're not modifying the KERNEL_IMAGETYPE, you're merely allow it 
to be changed. So you're technically not introducing a bug. And if we 
wanted to be pedantic, we could say that this bug can technically 
already be triggered by changing the KERNEL_IMAGETYPE in the machine 
configuration file (and not in local.conf).


If you want to make sure one cannot modify the KERNEL_IMAGETYPE and 
break the build, then you can add the commit handling the devicetree 
before the one allowing to override the image type.



I agree moving it out of the include file would be the best way to go
but if you dont have the directory in the KERNEL_DEVICETREE it will
fail to compile, quickly searching other layers are handling it
similar to how I have, probably just in a more robust way.



This means we really need to fix this in openembedded-core! We shouldn't 
rely on all layers to fix it themselves if we can avoid it.




Could you please provide the error log, which version of OE-Core/poky 
you're building so we know a bit where to look :) ?


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61122): https://lists.yoctoproject.org/g/yocto/message/61122
Mute This Topic: https://lists.yoctoproject.org/mt/101589776/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-rockchip] [PATCH] Allow KERNEL_IMAGETYPE override v2

[Quentin Schulz via lists.yoctoproject.org]

Hi Anthony,

On 9/26/23 06:36, Anthony Davies via lists.yoctoproject.org wrote:

[You don't often get email from 
anthony.t.davies=gmail@lists.yoctoproject.org. Learn why this is important 
at https://aka.ms/LearnAboutSenderIdentification ]

From: Anthony Davies 

Apologies, this is the correct patch

Updated inc files to allow overriding KERNEL_IMAGETYPE in local.conf

Fixed bug where dtb couldnt be found when generating KERNEL_IMAGETYPE
other then fitImage image due to KERNEL_DEVICETREE containing the dtb
directory which is not available in the DEPLOY_DIR_IMAGE directory
---
  conf/machine/include/px30.inc | 2 +-
  conf/machine/include/rk3066.inc   | 2 +-
  conf/machine/include/rk3188.inc   | 2 +-
  conf/machine/include/rk3288.inc   | 2 +-
  conf/machine/include/rk3328.inc   | 2 +-
  conf/machine/include/rk3399.inc   | 2 +-
  conf/machine/include/rockchip-wic.inc | 5 -
  7 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/conf/machine/include/px30.inc b/conf/machine/include/px30.inc
index a3727fb..badcbcd 100644
--- a/conf/machine/include/px30.inc
+++ b/conf/machine/include/px30.inc
@@ -12,7 +12,7 @@ require conf/machine/include/rockchip-wic.inc

  KBUILD_DEFCONFIG ?= "defconfig"
  KERNEL_CLASSES = "kernel-fitimage"
-KERNEL_IMAGETYPE = "fitImage"
+KERNEL_IMAGETYPE ?= "fitImage"

  TFA_PLATFORM = "px30"
  TFA_BUILD_TARGET = "bl31"
diff --git a/conf/machine/include/rk3066.inc b/conf/machine/include/rk3066.inc
index fa97906..3510df2 100644
--- a/conf/machine/include/rk3066.inc
+++ b/conf/machine/include/rk3066.inc
@@ -11,4 +11,4 @@ SERIAL_CONSOLES = "115200;ttyS2"

  KBUILD_DEFCONFIG = "multi_v7_defconfig"
  KERNEL_FEATURES:append:rk3066 = " 
bsp/rockchip/remove-non-rockchip-arch-arm.scc"
-KERNEL_IMAGETYPE = "zImage"
+KERNEL_IMAGETYPE ?= "zImage"
diff --git a/conf/machine/include/rk3188.inc b/conf/machine/include/rk3188.inc
index bc96a0c..830f908 100644
--- a/conf/machine/include/rk3188.inc
+++ b/conf/machine/include/rk3188.inc
@@ -11,4 +11,4 @@ SERIAL_CONSOLES = "115200;ttyFIQ0"

  KBUILD_DEFCONFIG = "multi_v7_defconfig"
  KERNEL_FEATURES:append:rk3188 = " 
bsp/rockchip/remove-non-rockchip-arch-arm.scc"
-KERNEL_IMAGETYPE = "zImage"
+KERNEL_IMAGETYPE ?= "zImage"
diff --git a/conf/machine/include/rk3288.inc b/conf/machine/include/rk3288.inc
index b4c559d..e682c0b 100644
--- a/conf/machine/include/rk3288.inc
+++ b/conf/machine/include/rk3288.inc
@@ -11,6 +11,6 @@ SERIAL_CONSOLES = "115200;ttyS2"

  KBUILD_DEFCONFIG ?= "multi_v7_defconfig"
  KERNEL_FEATURES:append:rk3288 = " 
bsp/rockchip/remove-non-rockchip-arch-arm.scc"
-KERNEL_IMAGETYPE = "zImage"
+KERNEL_IMAGETYPE ?= "zImage"

  UBOOT_SUFFIX ?= "bin"
diff --git a/conf/machine/include/rk3328.inc b/conf/machine/include/rk3328.inc
index f9f8792..6be777c 100644
--- a/conf/machine/include/rk3328.inc
+++ b/conf/machine/include/rk3328.inc
@@ -13,7 +13,7 @@ require conf/machine/include/rockchip-wic.inc
  KBUILD_DEFCONFIG ?= "defconfig"
  KERNEL_FEATURES:append:rk3328 = " 
bsp/rockchip/remove-non-rockchip-arch-arm64.scc"
  KERNEL_CLASSES = "kernel-fitimage"
-KERNEL_IMAGETYPE = "fitImage"
+KERNEL_IMAGETYPE ?= "fitImage"

  TFA_PLATFORM = "rk3328"
  TFA_BUILD_TARGET = "bl31"
diff --git a/conf/machine/include/rk3399.inc b/conf/machine/include/rk3399.inc
index 88c87af..5a3f439 100644
--- a/conf/machine/include/rk3399.inc
+++ b/conf/machine/include/rk3399.inc
@@ -13,7 +13,7 @@ require conf/machine/include/rockchip-wic.inc
  KBUILD_DEFCONFIG ?= "defconfig"
  KERNEL_FEATURES:append:rk3399 = " 
bsp/rockchip/remove-non-rockchip-arch-arm64.scc"
  KERNEL_CLASSES = "kernel-fitimage"
-KERNEL_IMAGETYPE = "fitImage"
+KERNEL_IMAGETYPE ?= "fitImage"

  TFA_PLATFORM = "rk3399"
  TFA_BUILD_TARGET = "bl31"
diff --git a/conf/machine/include/rockchip-wic.inc 
b/conf/machine/include/rockchip-wic.inc
index 635288c..8ff6066 100644
--- a/conf/machine/include/rockchip-wic.inc
+++ b/conf/machine/include/rockchip-wic.inc
@@ -11,9 +11,12 @@ WKS_FILE_DEPENDS ?= " \
 virtual/bootloader \
 virtual/kernel \
 "
+
+KERNEL_DEVICETREE_BASENAME = "${@os.path.basename('${KERNEL_DEVICETREE}')}"
+


KERNEL_DEVICETREE is a space-separated list so we need to handle it this 
way I think?


Something like:
"""
${@os.path.basename(x) for x in (d.getVar("KERNEL_DEVICETREE") or 
"").split()

"""

but which is valid Python :) (not tested).

Otherwise, I guess this could be added to oe-core directly no? What do 
you think?


Cheers,
Quentin


  IMAGE_BOOT_FILES = " \
 ${KERNEL_IMAGETYPE} \
-   ${@bb.utils.contains('KERNEL_IMAGETYPE', 'fitImage', '', 
'${KERNEL_DEVICETREE}', d)} \
+   ${@bb.utils.contains('KERNEL_IMAGETYPE', 'fitImage', '', 
'${KERNEL_DEVICETREE_BASENAME}', d)} \
 "

  # use the first-defined ; pair in SERIAL_CONSOLES
--
2.34.1






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61127): https://lists.yoctoproject.org/g/yocto/message/61127
Mute This Topic:

Re: [yocto] [meta-rockchip][PATCH v4 2/2] rock-5b: add

[Quentin Schulz via lists.yoctoproject.org]

Hi Trevor,

On 9/27/23 04:42, Trevor Woerner wrote:
[...]

diff --git a/recipes-bsp/rkbin/rockchip-rkbin_git.bb 
b/recipes-bsp/rkbin/rockchip-rkbin_git.bb
new file mode 100644
index ..7fefb017053b
--- /dev/null
+++ b/recipes-bsp/rkbin/rockchip-rkbin_git.bb
@@ -0,0 +1,37 @@
+DESCRIPTION = "Rockchip Firmware and Tool Binaries"
+LICENSE = "Proprietary"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=15faa4a01e7eb0f5d33f9f2bcc7bff62"
+
+SRC_URI = "git://github.com/rockchip-linux/rkbin;protocol=https;branch=master"
+SRCREV = "b4558da0860ca48bf1a571dd33ccba580b9abe23"
+
+PROVIDES += "trusted-firmware-a"
+PROVIDES += "optee-os"
+
+inherit bin_package deploy
+
+S = "${WORKDIR}/git"
+
+COMPATIBLE_MACHINE = ""
+COMPATIBLE_MACHINE:rk3588s = "rk3588s"
+
+PACKAGE_ARCH = "${MACHINE_ARCH}"
+
+do_install() {
+   # Nothing in this recipe is useful in a filesystem
+   :
+}
+
+PACKAGES = "${PN}"
+ALLOW_EMPTY:${PN} = "1"
+
+do_deploy() {
+   # Prebuilt TF-A
+   install -m 644 ${S}/bin/rk35/rk3588_bl31_v*.elf 
${DEPLOYDIR}/bl31-rk3588.elf
+   # Prebuilt OPTEE-OS
+   install -m 644 ${S}/bin/rk35/rk3588_bl32_v*.bin 
${DEPLOYDIR}/tee-rk3588.bin
+   # Prebuilt U-Boot TPL (DDR init)
+   install -m 644 ${S}/bin/rk35/rk3588_ddr_lp4_2112MHz_lp5_2736MHz_v*.bin 
${DEPLOYDIR}/ddr-rk3588.bin
+}
+
+addtask deploy after do_install
diff --git a/recipes-bsp/u-boot/u-boot%.bbappend 
b/recipes-bsp/u-boot/u-boot%.bbappend
index 050f55e124d4..f7800625aaf1 100644
--- a/recipes-bsp/u-boot/u-boot%.bbappend
+++ b/recipes-bsp/u-boot/u-boot%.bbappend
@@ -11,6 +11,12 @@ DEPENDS:append = " python3-pyelftools-native"
  
  INIT_FIRMWARE_DEPENDS ??= ""
  
+EXTRA_OEMAKE:append:rk3588s = " \

+   BL31=${DEPLOY_DIR_IMAGE}/bl31-rk3588.elf \
+   ROCKCHIP_TPL=${DEPLOY_DIR_IMAGE}/ddr-rk3588.bin \
+   "
+INIT_FIRMWARE_DEPENDS:rk3588s = " rockchip-rkbin:do_deploy"
+


Mm thinking about this... I think we'll have a difficult time 
allowing rkbin for ddr.bin and upstream trusted-firmware-a from another 
recipe for bl31.elf because both would be installing the same bl31 file 
in the deploy directory. I guess we can postpone this problem until we 
have to handle it though because nothing comes to mind on how to handle 
this properly right now.


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61137): https://lists.yoctoproject.org/g/yocto/message/61137
Mute This Topic: https://lists.yoctoproject.org/mt/101610912/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-rockchip][PATCH] nanopi-r2s: add

[Quentin Schulz via lists.yoctoproject.org]

Hi Trevor,

On 10/2/23 16:11, Trevor Woerner via lists.yoctoproject.org wrote:

The NanoPi R2S is a mini router with edge computing and dual GbE ports by
FriendlyElec. It is based on the Rockchip RK3328 - a quad A53 core, 64-bit SoC
running at 1.2GHz with at least 1GB of DDR4 RAM. It has one USB 2.0 host and
is powered via a USB type-C connector (5V/2A).

https://www.friendlyelec.com/index.php?route=product/product&product_id=282

Signed-off-by: Trevor Woerner 
---
  README  |  1 +
  conf/machine/nanopi-r2s.conf| 11 +++
  recipes-kernel/linux/linux-yocto_%.bbappend |  1 +
  3 files changed, 13 insertions(+)
  create mode 100644 conf/machine/nanopi-r2s.conf

diff --git a/README b/README
index e815fb47ff5f..8451b4778c37 100644
--- a/README
+++ b/README
@@ -32,6 +32,7 @@ Status of supported boards:
nanopi-r4s
rock-5b
rock-pi-s
+   nanopi-r2s


Was about to "complain" that this was not alphabetically sorted 
anymore... but it's already the case above the git context :)


Looking good :)

Reviewed-by: Quentin Schulz 

Cheers,
Quentin


builds:
marsboard-rk3066
radxarock
diff --git a/conf/machine/nanopi-r2s.conf b/conf/machine/nanopi-r2s.conf
new file mode 100644
index ..4472c21f0217
--- /dev/null
+++ b/conf/machine/nanopi-r2s.conf
@@ -0,0 +1,11 @@
+#@TYPE: Machine
+#@NAME: NanoPi R2S
+#@DESCRIPTION: The NanoPi R2S is a mini router with edge computing and dual 
GbE ports by FriendlyElec
+#https://www.friendlyelec.com/index.php?route=product/product&product_id=282
+
+require conf/machine/include/rk3328.inc
+
+KERNEL_DEVICETREE = "rockchip/rk3328-nanopi-r2s.dtb"
+MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
+
+UBOOT_MACHINE = "nanopi-r2s-rk3328_defconfig"
diff --git a/recipes-kernel/linux/linux-yocto_%.bbappend 
b/recipes-kernel/linux/linux-yocto_%.bbappend
index 61c89f70d8dc..456182ee473d 100644
--- a/recipes-kernel/linux/linux-yocto_%.bbappend
+++ b/recipes-kernel/linux/linux-yocto_%.bbappend
@@ -14,6 +14,7 @@ COMPATIBLE_MACHINE:rock64 = "rock64"
  COMPATIBLE_MACHINE:rock-pi-e = "rock-pi-e"
  COMPATIBLE_MACHINE:nanopi-r4s = "nanopi-r4s"
  COMPATIBLE_MACHINE:rock-pi-s = "rock-pi-s"
+COMPATIBLE_MACHINE:nanopi-r2s = "nanopi-r2s"
  
  SRC_URI:append = " file://rockchip-kmeta;type=kmeta;name=rockchip-kmeta;destsuffix=rockchip-kmeta"

  SRC_URI:append:nanopi-r4s = " file://nanopi-r4s.scc"






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61192): https://lists.yoctoproject.org/g/yocto/message/61192
Mute This Topic: https://lists.yoctoproject.org/mt/101712596/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-rockchip][PATCH 1/3] u-boot: cleanup

[Quentin Schulz via lists.yoctoproject.org]

Hi Trevor,

On 10/1/23 15:08, Trevor Woerner via lists.yoctoproject.org wrote:

Clean up the u-boot bbappend recipe: group items together and re-order as per
the Yocto recipe style guide.

Signed-off-by: Trevor Woerner 
---
  recipes-bsp/u-boot/u-boot%.bbappend | 32 ++---
  1 file changed, 15 insertions(+), 17 deletions(-)

diff --git a/recipes-bsp/u-boot/u-boot%.bbappend 
b/recipes-bsp/u-boot/u-boot%.bbappend
index f7800625aaf1..e79c471cf5ce 100644
--- a/recipes-bsp/u-boot/u-boot%.bbappend
+++ b/recipes-bsp/u-boot/u-boot%.bbappend
@@ -1,27 +1,25 @@
-do_compile:append:rock2-square () {
-   # copy to default search path
-   if [ "${SPL_BINARY}" = "u-boot-spl-dtb.bin" ]; then
-   cp ${B}/spl/${SPL_BINARY} ${B}
-   fi
-}
-
-DEPENDS:append:rock-pi-4 = " gnutls-native"
  # various machines require the pyelftools library for parsing dtb files
  DEPENDS:append = " python3-pyelftools-native"
+DEPENDS:append:rock-pi-4 = " gnutls-native"
  
-INIT_FIRMWARE_DEPENDS ??= ""

-
+EXTRA_OEMAKE:append:px30 = " BL31=${DEPLOY_DIR_IMAGE}/bl31-px30.elf"
+EXTRA_OEMAKE:append:rk3328 = " BL31=${DEPLOY_DIR_IMAGE}/bl31-rk3328.elf"
+EXTRA_OEMAKE:append:rk3399 = " BL31=${DEPLOY_DIR_IMAGE}/bl31-rk3399.elf"
  EXTRA_OEMAKE:append:rk3588s = " \
BL31=${DEPLOY_DIR_IMAGE}/bl31-rk3588.elf \
ROCKCHIP_TPL=${DEPLOY_DIR_IMAGE}/ddr-rk3588.bin \
"
-INIT_FIRMWARE_DEPENDS:rk3588s = " rockchip-rkbin:do_deploy"
  
-EXTRA_OEMAKE:append:rk3399 = " BL31=${DEPLOY_DIR_IMAGE}/bl31-rk3399.elf"

-INIT_FIRMWARE_DEPENDS:rk3399 = " trusted-firmware-a:do_deploy"
-EXTRA_OEMAKE:append:rk3328 = " BL31=${DEPLOY_DIR_IMAGE}/bl31-rk3328.elf"
-INIT_FIRMWARE_DEPENDS:rk3328 = " trusted-firmware-a:do_deploy"
-EXTRA_OEMAKE:append:px30 = " BL31=${DEPLOY_DIR_IMAGE}/bl31-px30.elf"
+INIT_FIRMWARE_DEPENDS ??= ""
  INIT_FIRMWARE_DEPENDS:px30 = " trusted-firmware-a:do_deploy"
-
+INIT_FIRMWARE_DEPENDS:rk3328 = " trusted-firmware-a:do_deploy"
+INIT_FIRMWARE_DEPENDS:rk3399 = " trusted-firmware-a:do_deploy"
+INIT_FIRMWARE_DEPENDS:rk3588s = " rockchip-rkbin:do_deploy"
  do_compile[depends] .= "${INIT_FIRMWARE_DEPENDS}"
+
+do_compile:append:rock2-square () {
+   # copy to default search path
+   if [ "${SPL_BINARY}" = "u-boot-spl-dtb.bin" ]; then
+   cp ${B}/spl/${SPL_BINARY} ${B}
+   fi
+}



A bit too many things done at once which makes it difficult to check 
that no mistake happened. I could suggest to split into multiple commits:

1) move of do_compile override for rock2-square
2) move INIT_FIRMWARE_DEPENDS together
3) move EXTRA_OEMAKE together
4) move rock-pi-4 override

But I think there's nothing that sneaked in, so:
Reviewed-by: Quentin Schulz 

Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61194): https://lists.yoctoproject.org/g/yocto/message/61194
Mute This Topic: https://lists.yoctoproject.org/mt/101691819/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-rockchip][PATCH 2/3] rock-pi-e.conf: remove redundant MACHINEOVERRIDES

[Quentin Schulz via lists.yoctoproject.org]

Hi Trevor,

On 10/1/23 15:08, Trevor Woerner via lists.yoctoproject.org wrote:

The MACHINE name is already added to the MACHINEOVERRIDES implicitly, no need
to add it explicitly.

Signed-off-by: Trevor Woerner 


Reviewed-by: Quentin Schulz 

Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61195): https://lists.yoctoproject.org/g/yocto/message/61195
Mute This Topic: https://lists.yoctoproject.org/mt/101691821/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-rockchip][PATCH 3/3] rock-pi-s: add

[Quentin Schulz via lists.yoctoproject.org]

Hi Trevor,

On 10/1/23 15:08, Trevor Woerner via lists.yoctoproject.org wrote:

ROCK Pi S is a Rockchip RK3308 based SBC from Radxa. It contains a 64-bit
quad core processor, USB, ethernet, wireless connectivity, and voice
detection engine in 1.7-inches square. The ROCK Pi S comes in two RAM sizes
256MB or 512MB DDR3, and uses sdmmc card for OS and storage. Optionally, some
versions of the ROCK Pi S provide on-board storage via 1Gb/2Gb/4Gb/8Gb of
SLC NAND flash.

"S" stands for "small square" since the total board size of the rock-pi-s is
1.7-inches square.

This BSP assumes booting from sdmmc, and using ttyS0 for the serial console
(similar to Raspberry Pi).

Signed-off-by: Trevor Woerner 
---
  README  |  1 +
  conf/machine/include/rk3308.inc | 18 ++
  conf/machine/rock-pi-s.conf | 11 +++
  recipes-bsp/rkbin/rockchip-rkbin_git.bb | 17 +
  recipes-bsp/u-boot/u-boot%.bbappend | 11 +++
  recipes-kernel/linux/linux-yocto_%.bbappend |  1 +
  6 files changed, 59 insertions(+)
  create mode 100644 conf/machine/include/rk3308.inc
  create mode 100644 conf/machine/rock-pi-s.conf

diff --git a/README b/README
index d4576d73c636..e815fb47ff5f 100644
--- a/README
+++ b/README
@@ -31,6 +31,7 @@ Status of supported boards:
firefly-rk3288
nanopi-r4s
rock-5b
+   rock-pi-s
builds:
marsboard-rk3066
radxarock
diff --git a/conf/machine/include/rk3308.inc b/conf/machine/include/rk3308.inc
new file mode 100644
index ..19cabafdfac0
--- /dev/null
+++ b/conf/machine/include/rk3308.inc
@@ -0,0 +1,18 @@
+SOC_FAMILY = "rk3308"
+
+DEFAULTTUNE ?= "cortexa35-crypto"
+
+require conf/machine/include/soc-family.inc
+require conf/machine/include/arm/armv8a/tune-cortexa35.inc
+require conf/machine/include/rockchip-defaults.inc
+require conf/machine/include/rockchip-wic.inc
+
+SERIAL_CONSOLES = "150;ttyS0"
+
+KBUILD_DEFCONFIG ?= "defconfig"
+KERNEL_FEATURES:append:rk3308 = " 
bsp/rockchip/remove-non-rockchip-arch-arm64.scc"


I'm starting to wonder if we shouldn't make this a pn-linux-yocto (and 
other flavors) override as well because we would make it difficult for 
other people to NOT include this. e.g. if they have their own recipe 
where KERNEL_FEATURES is used for example. Anyway, not specific to this 
SoC include file so not a blocker.



+KERNEL_CLASSES = "kernel-fitimage"
+KERNEL_IMAGETYPE = "fitImage"
+
+UBOOT_SUFFIX ?= "itb"
+UBOOT_ENTRYPOINT ?= "0x0600"
diff --git a/conf/machine/rock-pi-s.conf b/conf/machine/rock-pi-s.conf
new file mode 100644
index ..79ea73c6b47e
--- /dev/null
+++ b/conf/machine/rock-pi-s.conf
@@ -0,0 +1,11 @@
+#@TYPE: Machine
+#@NAME: Radxa Rock Pi S
+#@DESCRIPTION: ROCK Pi S is a Rockchip RK3308 based SBC by Radxa. "S" stands for 
"small square"
+#https://wiki.radxa.com/RockpiS
+
+require conf/machine/include/rk3308.inc
+
+KERNEL_DEVICETREE = "rockchip/rk3308-rock-pi-s.dtb"
+MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
+
+UBOOT_MACHINE = "rock-pi-s-rk3308_defconfig"
diff --git a/recipes-bsp/rkbin/rockchip-rkbin_git.bb 
b/recipes-bsp/rkbin/rockchip-rkbin_git.bb
index 7fefb017053b..49e1e682eb7d 100644
--- a/recipes-bsp/rkbin/rockchip-rkbin_git.bb
+++ b/recipes-bsp/rkbin/rockchip-rkbin_git.bb
@@ -1,9 +1,12 @@
  DESCRIPTION = "Rockchip Firmware and Tool Binaries"
  LICENSE = "Proprietary"
+LICENSE:rk3308 = "CLOSED"
  LIC_FILES_CHKSUM = "file://LICENSE;md5=15faa4a01e7eb0f5d33f9f2bcc7bff62"
+LIC_FILES_CHKSUM:rk3308 = "file://README;md5=39cc9df955478b8df26158d489fdcc95"
  
  SRC_URI = "git://github.com/rockchip-linux/rkbin;protocol=https;branch=master"

  SRCREV = "b4558da0860ca48bf1a571dd33ccba580b9abe23"
+SRCREV:rk3308 = "e65b97b511f1349156702db40694454c141d8fe2"
  


Could you please say a few words about this change? It seems that there 
are still binaries for it in the SRCREV we already point to. I assume 
newer should be better (though it's not always the case), so wondering 
what's prompted this change?



Oooh, there is no TPL with uart0m0 support anymore... honestly not 
sure it's a good idea to stay on a old blob version just for that? I 
assume you should only be missing the uart in TPL but the moment you 
reach the SPL the console should appear, doesn't it?



  PROVIDES += "trusted-firmware-a"
  PROVIDES += "optee-os"
@@ -14,6 +17,7 @@ S = "${WORKDIR}/git"
  
  COMPATIBLE_MACHINE = ""

  COMPATIBLE_MACHINE:rk3588s = "rk3588s"
+COMPATIBLE_MACHINE:rk3308 = "rk3308"
  
  PACKAGE_ARCH = "${MACHINE_ARCH}"
  
@@ -26,6 +30,19 @@ PACKAGES = "${PN}"

  ALLOW_EMPTY:${PN} = "1"
  
  do_deploy() {

+   :
+}
+
+do_deploy:append:rk3308() {
+   # Prebuilt TF-A
+   install -m 644 ${S}/bin/rk33/rk3308_bl31_v*.elf 
${DEPLOYDIR}/bl31-rk3308.elf
+   # Prebuilt OPTEE-OS
+   install -m 644 ${S}/bin/rk33/rk3308_bl32_v*.bin 
${DEPLOYDIR}/tee-rk3308.bi

Re: [yocto] [meta-rockchip][PATCH] virtual/tpl: add

[Quentin Schulz via lists.yoctoproject.org]

Hi Trevor,

On 10/3/23 02:08, Trevor Woerner via lists.yoctoproject.org wrote:

Be more obvious regarding the roles of TF-A vs rkbin: both provide a TPL for
Rockchip SoCs, but only one should be used.



No, they don't.

U-Boot TPL is either a blob provided by Rockchip via the rockchip-rkbin 
(the one we call ddr-*.bin) recipe or directly generated by U-Boot 
recipe itself.


rockchip-rkbin has a blob for TF-A called bl31.elf which is TF-A but for 
which we don't have sources. If we had the sources, we could use 
trusted-firmware-a recipe instead.


The both of them are actually required because:
1) U-Boot TPL does the DDR init, which is essential
2) TF-A is required on Aarch64 platforms to be able to boot a Linux kernel


Signed-off-by: Trevor Woerner 
---
  conf/machine/include/px30.inc| 1 +
  conf/machine/include/rk3328.inc  | 1 +
  conf/machine/include/rk3399.inc  | 1 +
  conf/machine/include/rk3588s.inc | 2 +-
  recipes-bsp/rkbin/rockchip-rkbin_git.bb  | 2 +-
  recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend | 2 ++
  6 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/conf/machine/include/px30.inc b/conf/machine/include/px30.inc
index a3727fbfca66..04cbd092a00d 100644
--- a/conf/machine/include/px30.inc
+++ b/conf/machine/include/px30.inc
@@ -14,6 +14,7 @@ KBUILD_DEFCONFIG ?= "defconfig"
  KERNEL_CLASSES = "kernel-fitimage"
  KERNEL_IMAGETYPE = "fitImage"
  
+PREFERRED_PROVIDER_virtual/tpl = "trusted-firmware-a"


TPL is provided by upstream U-Boot for PX30 so better use that one. If 
it wasn't (or you don't want to use it), the proper change would be to 
use rockchip-rkbin for it.



  TFA_PLATFORM = "px30"
  TFA_BUILD_TARGET = "bl31"
  
diff --git a/conf/machine/include/rk3328.inc b/conf/machine/include/rk3328.inc

index f9f8792ca521..7f8673f062d1 100644
--- a/conf/machine/include/rk3328.inc
+++ b/conf/machine/include/rk3328.inc
@@ -15,6 +15,7 @@ KERNEL_FEATURES:append:rk3328 = " 
bsp/rockchip/remove-non-rockchip-arch-arm64.sc
  KERNEL_CLASSES = "kernel-fitimage"
  KERNEL_IMAGETYPE = "fitImage"
  
+PREFERRED_PROVIDER_virtual/tpl = "trusted-firmware-a"


Ditto.


  TFA_PLATFORM = "rk3328"
  TFA_BUILD_TARGET = "bl31"
  
diff --git a/conf/machine/include/rk3399.inc b/conf/machine/include/rk3399.inc

index 88c87af3a03e..09be584468b8 100644
--- a/conf/machine/include/rk3399.inc
+++ b/conf/machine/include/rk3399.inc
@@ -15,6 +15,7 @@ KERNEL_FEATURES:append:rk3399 = " 
bsp/rockchip/remove-non-rockchip-arch-arm64.sc
  KERNEL_CLASSES = "kernel-fitimage"
  KERNEL_IMAGETYPE = "fitImage"
  
+PREFERRED_PROVIDER_virtual/tpl = "trusted-firmware-a"


Ditto.


  TFA_PLATFORM = "rk3399"
  TFA_BUILD_TARGET = "bl31"
  
diff --git a/conf/machine/include/rk3588s.inc b/conf/machine/include/rk3588s.inc

index 7bfc9474e96e..e66ad565585b 100644
--- a/conf/machine/include/rk3588s.inc
+++ b/conf/machine/include/rk3588s.inc
@@ -10,7 +10,7 @@ KERNEL_FEATURES:append:rk3588s = " 
bsp/rockchip/remove-non-rockchip-arch-arm64.s
  KERNEL_CLASSES = "kernel-fitimage"
  KERNEL_IMAGETYPE = "fitImage"
  
-PREFERRED_PROVIDER_trusted-firmware-a = "rockchip-rkbin"


This was actually correct.


+PREFERRED_PROVIDER_virtual/tpl = "rockchip-rkbin" >   PREFERRED_PROVIDER_optee-os = 
"rockchip-rkbin"
  
  UBOOT_SUFFIX ?= "itb"

diff --git a/recipes-bsp/rkbin/rockchip-rkbin_git.bb 
b/recipes-bsp/rkbin/rockchip-rkbin_git.bb
index 7fefb017053b..887a7fb61853 100644
--- a/recipes-bsp/rkbin/rockchip-rkbin_git.bb
+++ b/recipes-bsp/rkbin/rockchip-rkbin_git.bb
@@ -5,7 +5,7 @@ LIC_FILES_CHKSUM = 
"file://LICENSE;md5=15faa4a01e7eb0f5d33f9f2bcc7bff62"
  SRC_URI = "git://github.com/rockchip-linux/rkbin;protocol=https;branch=master"
  SRCREV = "b4558da0860ca48bf1a571dd33ccba580b9abe23"
  
-PROVIDES += "trusted-firmware-a"

+PROVIDES += "virtual/tpl"


Do not remove trusted-firmware-a PROVIDES, it is necessary to be able to 
select which recipe provides trusted-firmware-a (either rockchip-rkbin 
or trusted-firmware-a).


You can add virtual/tpl though.


  PROVIDES += "optee-os"
  
  inherit bin_package deploy

diff --git a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend 
b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
index c9ad84c24857..f6566212746e 100644
--- a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
+++ b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
@@ -2,6 +2,8 @@
  # toolchain
  DEPENDS:append:rk3399 = " gcc-arm-none-eabi-native"
  
+PROVIDES += "virtual/tpl"

+


This is incorrect.

It should be added to u-boot%.bbappend instead. And I think what we want 
to do is not possible.


So basically, my understand of what you're trying to do is to allow the 
selection of the TPL via a virtual recipe.


The TPL is used in U-Boot only and should be there before do_compile is 
executed. So the virtual recipe should have executed its own do_dep

Re: [yocto] [meta-rockchip] [PATCH] Allow KERNEL_IMAGETYPE override v3

[Quentin Schulz via lists.yoctoproject.org]

Hi Anthony,

On 10/3/23 02:43, Anthony Davies via lists.yoctoproject.org wrote:

[You don't often get email from 
anthony.t.davies=gmail@lists.yoctoproject.org. Learn why this is important 
at https://aka.ms/LearnAboutSenderIdentification ]

From: Anthony Davies 

Updated inc files to allow overriding KERNEL_IMAGETYPE in local.conf

Signed-off-by: Anthony Davies 


Reviewed-by: Quentin Schulz 

Unrelated to this patch set, KERNEL_IMAGETYPE actually defaults to 
zImage so we could just avoid doing it again in rk3066, rk3188, rk3328.


Also, for newer versions of patch series, please use:
git format-patch -v3
or
git send-email -v3

and it should create a mail with:
[PATCH v3] in there
because with the current subject being
Allow KERNEL_IMAGETYPE override v3
this would be the commit title inside the git repo and this is the kind 
of information we don't necessarily need in the git repo :) (but thanks 
for thinknig about adding it, it makes it easier to follow which patch 
mail is the latest version :) ).


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61212): https://lists.yoctoproject.org/g/yocto/message/61212
Mute This Topic: https://lists.yoctoproject.org/mt/101725871/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-rockchip][PATCH v2 0/4] u-boot cleanup

[Quentin Schulz via lists.yoctoproject.org]

Hi Trevor,

On 10/3/23 02:47, Trevor Woerner via lists.yoctoproject.org wrote:

The U-Boot bbappend recipe was in need of some cleanups.

v2:
- breakup the original 1 patch into 4 to make the steps easier to
   audit/verify.

Trevor Woerner (4):
   u-boot cleanup: move task
   u-boot cleanup: group dependencies
   u-boot cleanup: group EXTRA_OEMAKE
   u-boot cleanup: organize DEPENDS



Perfect :)

Reviewed-by: Quentin Schulz 

Cheers,
Quentin


  recipes-bsp/u-boot/u-boot%.bbappend | 32 ++---
  1 file changed, 15 insertions(+), 17 deletions(-)






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61213): https://lists.yoctoproject.org/g/yocto/message/61213
Mute This Topic: https://lists.yoctoproject.org/mt/101725918/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-rockchip] [PATCH] Stop u-boot sections partition table

[Quentin Schulz via lists.yoctoproject.org]

Hi Anthony,

On 10/3/23 03:26, Anthony Davies via lists.yoctoproject.org wrote:

From: Anthony Davies 

When checking the partition table of builds using this layer you get
numerous extra partitions due to each bootloader entry creating a
partition. --no-table on these entries should stop this from happening.

Signed-off-by: Anthony Davies 


While this is annoying in some aspects, it's also very nice when you 
want to flash a new U-Boot manually for example. You just need to flash 
the raw file in the partition directly instead of having to figure out 
which offset to use. FWIW, I actually do flash by offset instead of by 
partition and I have to remember the offsets for different products (we 
don't use Rockchip's defaults :) ) and I guess this would make things 
easier.


So,
Reviewed-by: Quentin Schulz 

Up to Trevor to decide what to do with the patch :)

Cheers,
Quentin


---
  wic/rockchip.wks | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/wic/rockchip.wks b/wic/rockchip.wks
index 1cc30ae..eb50d8c 100644
--- a/wic/rockchip.wks
+++ b/wic/rockchip.wks
@@ -15,11 +15,11 @@
  #   boot32768   229376
  #   root262144  -   (suggested)
  
-part loader1--offset 32 --fixed-size 4000K--source rawcopy --sourceparams="file=${SPL_BINARY}"

-part reserved1  --offset 4032   --fixed-size 64K
-part reserved2  --offset 4096   --fixed-size 4096K
-part loader2--offset 8192   --fixed-size 4096K--source rawcopy   
  
--sourceparams="file=u-boot.${UBOOT_SUFFIX}"
-part atf--offset 12288  --fixed-size 4096K
+part loader1--offset 32 --fixed-size 4000K--source rawcopy   
--no-table--sourceparams="file=${SPL_BINARY}"
+part reserved1  --offset 4032   --fixed-size 64K   
  --no-table
+part reserved2  --offset 4096   --fixed-size 4096K 
  --no-table
+part loader2--offset 8192   --fixed-size 4096K--source rawcopy   
--no-table
--sourceparams="file=u-boot.${UBOOT_SUFFIX}"
+part atf--offset 12288  --fixed-size 4096K 
  --no-table
  part /boot  --offset 16384  --size   114688K --active --source 
bootimg-partition --fstype=vfat --label boot --use-uuid 
--sourceparams="loader=u-boot"
  part /--source rootfs 
   --fstype=ext4 --label root --use-uuid
  







-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61214): https://lists.yoctoproject.org/g/yocto/message/61214
Mute This Topic: https://lists.yoctoproject.org/mt/101726546/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-rockchip] [PATCH] machine include files use weak defaults

[Quentin Schulz via lists.yoctoproject.org]

Hi Anthony,

On 10/3/23 04:34, Anthony Davies via lists.yoctoproject.org wrote:

From: Anthony Davies 

This allows defaults to be set per machine.conf but also allows
overrides in local.conf.



NACK to the whole patch.

??= has a very different behavior than ?= and is weaker than ?=. c.f. 
https://elinux.org/images/3/33/YPS2022.05_d1s02_overrides.pdf slides 15 
to 20.


DEFAULTTUNE is already weakly set in the tune include files so this 
would basically result in a no-op.


I don't understand what your needs are frankly.

local.conf shouldn't be used for changing those things except for 
debugging purposes. What I recommend if you need to change those is to 
create your own machine configuration file in your own layer which 
require the "base" SoC configuration file from meta-rockchip.


e.g.
my-rk3588-device.conf
"""
DEFAULTTUNE = "cortexa76-cortexa55"

require conf/machine/include/rk3588.inc
"""

If you want to reuse an existing machine conf file but only override a 
few things, you can also do the same trick:


my-rock-5b-device.conf
"""
DEFAULTTUNE = "cortexa76-cortexa55"

require conf/machine/rock-5b.conf
"""

Finally, if you REALLY have to change it from local.conf, you can use 
OVERRIDES, e.g.:


DEFAULTTUNE:rk3588 = "cortexa76-cortexa55"

But I would really recommend against using this.

Can you tell us more about your needs?

Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61215): https://lists.yoctoproject.org/g/yocto/message/61215
Mute This Topic: https://lists.yoctoproject.org/mt/101727464/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-rockchip][PATCH] KERNEL_DEVICETREE: 32-bit re-org

[Quentin Schulz via lists.yoctoproject.org]

Hi Trevor,

On 10/3/23 06:19, Trevor Woerner via lists.yoctoproject.org wrote:

The upstream kernel reorganized the 32-bit arch/arm device-tree directory 
structure
to separate out the device-trees by manufacturer (similar to the organization
of the arch/arm64 device-trees). Update the references to 32-bit arm
device-trees to match.



Does this work with linux-yocto and linux-yocto-dev from master or do we 
need to add some logic to support both (do you want to?).


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61216): https://lists.yoctoproject.org/g/yocto/message/61216
Mute This Topic: https://lists.yoctoproject.org/mt/101728482/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-rockchip] [PATCH] Allow KERNEL_IMAGETYPE override v3

[Quentin Schulz via lists.yoctoproject.org]

Hi Trevor,

On 10/3/23 16:03, Trevor Woerner wrote:

On Tue 2023-10-03 @ 12:17:13 PM, Quentin Schulz wrote:

Hi Anthony,

On 10/3/23 02:43, Anthony Davies via lists.yoctoproject.org wrote:

[You don't often get email from 
anthony.t.davies=gmail@lists.yoctoproject.org. Learn why this is important 
at https://aka.ms/LearnAboutSenderIdentification ]

From: Anthony Davies 

Updated inc files to allow overriding KERNEL_IMAGETYPE in local.conf

Signed-off-by: Anthony Davies 


Reviewed-by: Quentin Schulz 

Unrelated to this patch set, KERNEL_IMAGETYPE actually defaults to zImage so
we could just avoid doing it again in rk3066, rk3188, rk3328.

Also, for newer versions of patch series, please use:
git format-patch -v3
or
git send-email -v3

and it should create a mail with:
[PATCH v3] in there
because with the current subject being
Allow KERNEL_IMAGETYPE override v3
this would be the commit title inside the git repo and this is the kind of
information we don't necessarily need in the git repo :) (but thanks for
thinknig about adding it, it makes it easier to follow which patch mail is
the latest version :) ).


Would "git send-email -v3" also add the "meta-rockchip"?


I assume anything you can pass to git-format-patch can be passed to 
git-send-email, so git send-email --subject-prefix="meta-rockchip][PATCH 
v3" probably would work just as fine? However these parameters only work 
if you pass a gitrev and not a patch


c.f. https://git-scm.com/docs/git-send-email#_description
"""
Patches can be specified as files, directories (which will send all 
files in the directory), or directly as a revision list. In the last 
case, any format accepted by git-format-patch[1] can be passed to git 
send-email, as well as options understood by git-format-patch[1].

"""

Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61221): https://lists.yoctoproject.org/g/yocto/message/61221
Mute This Topic: https://lists.yoctoproject.org/mt/101725871/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-rockchip][PATCH] KERNEL_DEVICETREE: 32-bit re-org

[Quentin Schulz via lists.yoctoproject.org]

Hi Trevor,

On 10/3/23 15:38, Trevor Woerner wrote:

On Tue 2023-10-03 @ 12:32:08 PM, Quentin Schulz wrote:

Hi Trevor,

On 10/3/23 06:19, Trevor Woerner via lists.yoctoproject.org wrote:

The upstream kernel reorganized the 32-bit arch/arm device-tree directory 
structure
to separate out the device-trees by manufacturer (similar to the organization
of the arch/arm64 device-trees). Update the references to 32-bit arm
device-trees to match.



Does this work with linux-yocto and linux-yocto-dev from master or do we
need to add some logic to support both (do you want to?).


This doesn't work at all. I figured this was an easy one, made the tweak,
submitted it, then added it to my jenkins builder to verify overnight. Woke up
to find the do_image_wic() tasks failed. It's the same layout as the 64-bit
machines but I'll have to dig in to figure out why it didn't work.

As for the linux-yocto vs linux-yocto-dev question I'll take a look. This
happened with linux-yocto, so I would assume it is already the case with
linux-yocto-dev. But if oe-core supports multiple versions of linux-yocto,
that might be the tricky bit and yes, I would look into supporting both for
the time-being until the transition period ends.



This was done in v6.5-rc1 so anything before won't work sadly.

master branch of poky supports 6.1 6.4 and 6.5 for linux-yocto 
(linux-yocto-dev being typically newer than the latest linux-yocto and 
the latest linux-yocto already having the change, I'll omit the change 
for linux-yocto-dev).


For reference, denix on IRC suggested you look at 
https://git.openembedded.org/openembedded-core/commit/?id=04ab57d20009d85eb566e83ae6fe1dcea4db7300 
for what we're trying to do here. But I think this isn't applying to how 
the DTB is found but rather where it's put and this is too late for us.


I think we need to modify get_real_dtb_path_in_kernel in 
meta/classes-recipe/kernel-devicetree.bbclass instead.


We could handle it this way for example to allow a fallback:
"""
get_real_dtb_path_in_kernel:arm () {
dtb="$1"
dtb_path="${B}/arch/${ARCH}/boot/dts/$dtb"
# Handle pre-v6.5 layout for Aarch32/ARM DTB
if [ ! -e "$dtb_path" ]; then
dtb_path="${B}/arch/${ARCH}/boot/dts/$(basename "$dtb")"
fi
if [ ! -e "$dtb_path" ]; then
dtb_path="${B}/arch/${ARCH}/boot/$dtb"
fi
# Handle pre-v6.5 layout for Aarch32/ARM DTB
if [ ! -e "$dtb_path" ]; then
dtb_path="${B}/arch/${ARCH}/boot/$(basename "$dtb")"
fi

echo "$dtb_path"
}
"""
(to be determined if "arm" is a valid OVERRIDES, otherwise we need to 
check against "ARCH" bb variable; also not sure about the second 
basename if it's necessary at all).


Then you would just have KERNEL_DEVICETREE done the same way as in this 
patch:

KERNEL_DEVICETREE = "rockchip/rk3066a-marsboard.dtb"

and we wouldn't have to handle it on the recipe level.

Otherwise, we could do the following:
RK_KERNEL_DEVICETREE = "rockchip/rk3066a-marsboard.dtb"
KERNEL_DEVICETREE ?= "${RK_KERNEL_DEVICETREE}"

then have a bbappend for all old-layout recipes:
linux-yocto-rt_6.1.bbappend
linux-yocto-tiny_6.1.bbappend
linux-yocto_6.1.bbappend
linux-yocto-rt_6.4.bbappend
linux-yocto-tiny_6.4.bbappend
linux-yocto_6.4.bbappend

KERNEL_DEVICETREE:arm = "${@' '.join(os.path.basename(dtb) for dtb in 
d.getVar('RK_KERNEL_DEVICETREE').split())}"


or something like that. We probably want to have something a bit more 
precise than just arm to avoid breaking other arm machine conf files 
which do not define RK_KERNEL_DEVICETREE, maybe 
KERNEL_DEVICETREE:rockchip:arm if that is even resolving properly.



Although... any BSP layer supporting 32-bit machines will have similar issues,
so perhaps there's a better way to solve this in oe-core?

Adding Bruce in Cc, I hope he doesn't mind being summoned like this. 
Maybe you have an idea on how to handle both the new and old layout for 
ARM/Aarch32 DTB in the kernel for the KERNEL_DEVICETREE variable?


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61235): https://lists.yoctoproject.org/g/yocto/message/61235
Mute This Topic: https://lists.yoctoproject.org/mt/101728482/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-rockchip][PATCH] KERNEL_DEVICETREE: 32-bit re-org

[Quentin Schulz via lists.yoctoproject.org]

With Bruce in Cc for real this time :)

On 10/4/23 15:45, Quentin Schulz wrote:

Hi Trevor,

On 10/3/23 15:38, Trevor Woerner wrote:

On Tue 2023-10-03 @ 12:32:08 PM, Quentin Schulz wrote:

Hi Trevor,

On 10/3/23 06:19, Trevor Woerner via lists.yoctoproject.org wrote:
The upstream kernel reorganized the 32-bit arch/arm device-tree 
directory structure
to separate out the device-trees by manufacturer (similar to the 
organization

of the arch/arm64 device-trees). Update the references to 32-bit arm
device-trees to match.



Does this work with linux-yocto and linux-yocto-dev from master or do we
need to add some logic to support both (do you want to?).


This doesn't work at all. I figured this was an easy one, made the tweak,
submitted it, then added it to my jenkins builder to verify overnight. 
Woke up
to find the do_image_wic() tasks failed. It's the same layout as the 
64-bit

machines but I'll have to dig in to figure out why it didn't work.

As for the linux-yocto vs linux-yocto-dev question I'll take a look. This
happened with linux-yocto, so I would assume it is already the case with
linux-yocto-dev. But if oe-core supports multiple versions of 
linux-yocto,
that might be the tricky bit and yes, I would look into supporting 
both for

the time-being until the transition period ends.



This was done in v6.5-rc1 so anything before won't work sadly.

master branch of poky supports 6.1 6.4 and 6.5 for linux-yocto 
(linux-yocto-dev being typically newer than the latest linux-yocto and 
the latest linux-yocto already having the change, I'll omit the change 
for linux-yocto-dev).


For reference, denix on IRC suggested you look at 
https://git.openembedded.org/openembedded-core/commit/?id=04ab57d20009d85eb566e83ae6fe1dcea4db7300 for what we're trying to do here. But I think this isn't applying to how the DTB is found but rather where it's put and this is too late for us.


I think we need to modify get_real_dtb_path_in_kernel in 
meta/classes-recipe/kernel-devicetree.bbclass instead.


We could handle it this way for example to allow a fallback:
"""
get_real_dtb_path_in_kernel:arm () {
 dtb="$1"
 dtb_path="${B}/arch/${ARCH}/boot/dts/$dtb"
     # Handle pre-v6.5 layout for Aarch32/ARM DTB
 if [ ! -e "$dtb_path" ]; then
     dtb_path="${B}/arch/${ARCH}/boot/dts/$(basename "$dtb")"
 fi
 if [ ! -e "$dtb_path" ]; then
     dtb_path="${B}/arch/${ARCH}/boot/$dtb"
 fi
     # Handle pre-v6.5 layout for Aarch32/ARM DTB
 if [ ! -e "$dtb_path" ]; then
     dtb_path="${B}/arch/${ARCH}/boot/$(basename "$dtb")"
 fi

 echo "$dtb_path"
}
"""
(to be determined if "arm" is a valid OVERRIDES, otherwise we need to 
check against "ARCH" bb variable; also not sure about the second 
basename if it's necessary at all).


Then you would just have KERNEL_DEVICETREE done the same way as in this 
patch:

KERNEL_DEVICETREE = "rockchip/rk3066a-marsboard.dtb"

and we wouldn't have to handle it on the recipe level.

Otherwise, we could do the following:
RK_KERNEL_DEVICETREE = "rockchip/rk3066a-marsboard.dtb"
KERNEL_DEVICETREE ?= "${RK_KERNEL_DEVICETREE}"

then have a bbappend for all old-layout recipes:
linux-yocto-rt_6.1.bbappend
linux-yocto-tiny_6.1.bbappend
linux-yocto_6.1.bbappend
linux-yocto-rt_6.4.bbappend
linux-yocto-tiny_6.4.bbappend
linux-yocto_6.4.bbappend

KERNEL_DEVICETREE:arm = "${@' '.join(os.path.basename(dtb) for dtb in 
d.getVar('RK_KERNEL_DEVICETREE').split())}"


or something like that. We probably want to have something a bit more 
precise than just arm to avoid breaking other arm machine conf files 
which do not define RK_KERNEL_DEVICETREE, maybe 
KERNEL_DEVICETREE:rockchip:arm if that is even resolving properly.


Although... any BSP layer supporting 32-bit machines will have similar 
issues,

so perhaps there's a better way to solve this in oe-core?

Adding Bruce in Cc, I hope he doesn't mind being summoned like this. 
Maybe you have an idea on how to handle both the new and old layout for 
ARM/Aarch32 DTB in the kernel for the KERNEL_DEVICETREE variable?


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61236): https://lists.yoctoproject.org/g/yocto/message/61236
Mute This Topic: https://lists.yoctoproject.org/mt/101728482/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-rockchip][PATCH 3/3] rock-pi-s: add

[Quentin Schulz via lists.yoctoproject.org]

Hi Trevor,

On 10/3/23 15:56, Trevor Woerner wrote:

On Mon 2023-10-02 @ 06:17:15 PM, Quentin Schulz wrote:

Hi Trevor,

On 10/1/23 15:08, Trevor Woerner via lists.yoctoproject.org wrote:

ROCK Pi S is a Rockchip RK3308 based SBC from Radxa. It contains a 64-bit
quad core processor, USB, ethernet, wireless connectivity, and voice
detection engine in 1.7-inches square. The ROCK Pi S comes in two RAM sizes
256MB or 512MB DDR3, and uses sdmmc card for OS and storage. Optionally, some
versions of the ROCK Pi S provide on-board storage via 1Gb/2Gb/4Gb/8Gb of
SLC NAND flash.

"S" stands for "small square" since the total board size of the rock-pi-s is
1.7-inches square.

This BSP assumes booting from sdmmc, and using ttyS0 for the serial console
(similar to Raspberry Pi).

Signed-off-by: Trevor Woerner 
---
   README  |  1 +
   conf/machine/include/rk3308.inc | 18 ++
   conf/machine/rock-pi-s.conf | 11 +++
   recipes-bsp/rkbin/rockchip-rkbin_git.bb | 17 +
   recipes-bsp/u-boot/u-boot%.bbappend | 11 +++
   recipes-kernel/linux/linux-yocto_%.bbappend |  1 +
   6 files changed, 59 insertions(+)
   create mode 100644 conf/machine/include/rk3308.inc
   create mode 100644 conf/machine/rock-pi-s.conf

diff --git a/README b/README
index d4576d73c636..e815fb47ff5f 100644
--- a/README
+++ b/README
@@ -31,6 +31,7 @@ Status of supported boards:
firefly-rk3288
nanopi-r4s
rock-5b
+   rock-pi-s
builds:
marsboard-rk3066
radxarock
diff --git a/conf/machine/include/rk3308.inc b/conf/machine/include/rk3308.inc
new file mode 100644
index ..19cabafdfac0
--- /dev/null
+++ b/conf/machine/include/rk3308.inc
@@ -0,0 +1,18 @@
+SOC_FAMILY = "rk3308"
+
+DEFAULTTUNE ?= "cortexa35-crypto"
+
+require conf/machine/include/soc-family.inc
+require conf/machine/include/arm/armv8a/tune-cortexa35.inc
+require conf/machine/include/rockchip-defaults.inc
+require conf/machine/include/rockchip-wic.inc
+
+SERIAL_CONSOLES = "150;ttyS0"
+
+KBUILD_DEFCONFIG ?= "defconfig"
+KERNEL_FEATURES:append:rk3308 = " 
bsp/rockchip/remove-non-rockchip-arch-arm64.scc"


I'm starting to wonder if we shouldn't make this a pn-linux-yocto (and other
flavors) override as well because we would make it difficult for other
people to NOT include this. e.g. if they have their own recipe where
KERNEL_FEATURES is used for example. Anyway, not specific to this SoC
include file so not a blocker.


I'm not 100% sure what you're recommending, but if there's a better way that
is more flexible for the users, it sounds good to me.



KERNEL_FEATURES:append:rk3308:pn-linux-yocto = " 
bsp/rockchip/remove-non-rockchip-arch-arm64.scc"
KERNEL_FEATURES:append:rk3308:pn-linux-yocto-rt = " 
bsp/rockchip/remove-non-rockchip-arch-arm64.scc"
KERNEL_FEATURES:append:rk3308:pn-linux-yocto-tiny = " 
bsp/rockchip/remove-non-rockchip-arch-arm64.scc"
KERNEL_FEATURES:append:rk3308:pn-linux-yocto-dev = " 
bsp/rockchip/remove-non-rockchip-arch-arm64.scc"


for example would only apply to linux-yocto recipes and nothing else. 
Not THAT important we need to fix it up now :)





+KERNEL_CLASSES = "kernel-fitimage"
+KERNEL_IMAGETYPE = "fitImage"
+
+UBOOT_SUFFIX ?= "itb"
+UBOOT_ENTRYPOINT ?= "0x0600"
diff --git a/conf/machine/rock-pi-s.conf b/conf/machine/rock-pi-s.conf
new file mode 100644
index ..79ea73c6b47e
--- /dev/null
+++ b/conf/machine/rock-pi-s.conf
@@ -0,0 +1,11 @@
+#@TYPE: Machine
+#@NAME: Radxa Rock Pi S
+#@DESCRIPTION: ROCK Pi S is a Rockchip RK3308 based SBC by Radxa. "S" stands for 
"small square"
+#https://wiki.radxa.com/RockpiS
+
+require conf/machine/include/rk3308.inc
+
+KERNEL_DEVICETREE = "rockchip/rk3308-rock-pi-s.dtb"
+MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
+
+UBOOT_MACHINE = "rock-pi-s-rk3308_defconfig"
diff --git a/recipes-bsp/rkbin/rockchip-rkbin_git.bb 
b/recipes-bsp/rkbin/rockchip-rkbin_git.bb
index 7fefb017053b..49e1e682eb7d 100644
--- a/recipes-bsp/rkbin/rockchip-rkbin_git.bb
+++ b/recipes-bsp/rkbin/rockchip-rkbin_git.bb
@@ -1,9 +1,12 @@
   DESCRIPTION = "Rockchip Firmware and Tool Binaries"
   LICENSE = "Proprietary"
+LICENSE:rk3308 = "CLOSED"
   LIC_FILES_CHKSUM = "file://LICENSE;md5=15faa4a01e7eb0f5d33f9f2bcc7bff62"
+LIC_FILES_CHKSUM:rk3308 = "file://README;md5=39cc9df955478b8df26158d489fdcc95"
   SRC_URI = 
"git://github.com/rockchip-linux/rkbin;protocol=https;branch=master"
   SRCREV = "b4558da0860ca48bf1a571dd33ccba580b9abe23"
+SRCREV:rk3308 = "e65b97b511f1349156702db40694454c141d8fe2"


Could you please say a few words about this change? It seems that there are
still binaries for it in the SRCREV we already point to. I assume newer
should be better (though it's not always the case), so wondering what's
prompted this change?


Oooh, there is no TPL with uart0m0 support anymore... honestly not sure
it's a good idea

Re: [yocto] [meta-rockchip][kirkstone][PATCH] rk3588(s): add

[Quentin Schulz via lists.yoctoproject.org]

Hi Trevor,

On 10/5/23 11:00, Quentin Schulz wrote:

From: Trevor Woerner 

Unfortunately the TF-A project does not currently have support for
the rk3588. Therefore, for the time-being, the only way to supply a
TPL/DDR-init for the rk3588 is to use the closed-source rkbin binaries
from Rockchip. If/when TF-A adds support for the rk3588 we can investigate
switching.

The rk3588 comes in two variants: rk3588 and rk3588s. The "s" option is a
stripped-down version of the rk3588. In the Linux kernel these two SoCs are
kept separate, with the rk3588 building on the rk3588s, so we've mimicked that
same behaviour here.

Signed-off-by: Quentin Schulz 
Signed-off-by: Trevor Woerner 
[backported from f8af59dd7cd7 ("rock-5b: add")]
[removed support for rock-5b since no decent linux-yocto support in kirkstone]
[removed KERNEL_FEATURES and kmeta since no decent linux-yocto support in 
kirkstone]
[renamed INIT_FIRMWARE_DEPENDS to ATF_DEPENDS]


^^^ This is actually something we probably need to discuss?

This makes it harder to backport patches from the master branch to 
kirkstone because we have to be careful to rename those variables before 
applying the patch (even if somehow it applies cleanly).


On the other hand, migrating to the new name means we break the current 
behavior for downstream users of meta-rockchip.


Cheers,
Quentin


[tested on downstream board with downstream kernel and u-boot]
Signed-off-by: Quentin Schulz 
---
  conf/machine/include/rk3588.inc |  6 
  conf/machine/include/rk3588s.inc| 16 +++
  recipes-bsp/rkbin/rockchip-rkbin_git.bb | 37 +
  recipes-bsp/u-boot/u-boot%.bbappend |  6 
  4 files changed, 65 insertions(+)
  create mode 100644 conf/machine/include/rk3588.inc
  create mode 100644 conf/machine/include/rk3588s.inc
  create mode 100644 recipes-bsp/rkbin/rockchip-rkbin_git.bb

diff --git a/conf/machine/include/rk3588.inc b/conf/machine/include/rk3588.inc
new file mode 100644
index 000..34f0627
--- /dev/null
+++ b/conf/machine/include/rk3588.inc
@@ -0,0 +1,6 @@
+MACHINEOVERRIDES =. "rk3588:"
+
+# the rk3588s is a "stripped-down" version of the rk3588
+# in the kernel's device-tree the rk3588 builds on top of the rk3588s
+# so anything that is valid for the rk3588s is valid for the rk3588
+require conf/machine/include/rk3588s.inc
diff --git a/conf/machine/include/rk3588s.inc b/conf/machine/include/rk3588s.inc
new file mode 100644
index 000..3da226e
--- /dev/null
+++ b/conf/machine/include/rk3588s.inc
@@ -0,0 +1,16 @@
+MACHINEOVERRIDES =. "rk3588s:"
+DEFAULTTUNE ?= "cortexa76-cortexa55-crypto"
+
+require conf/machine/include/arm/armv8-2a/tune-cortexa76-cortexa55.inc
+require conf/machine/include/rockchip-defaults.inc
+require conf/machine/include/rockchip-wic.inc
+
+KBUILD_DEFCONFIG ?= "defconfig"
+KERNEL_CLASSES = "kernel-fitimage"
+KERNEL_IMAGETYPE = "fitImage"
+
+PREFERRED_PROVIDER_trusted-firmware-a = "rockchip-rkbin"
+PREFERRED_PROVIDER_optee-os = "rockchip-rkbin"
+
+UBOOT_SUFFIX ?= "itb"
+UBOOT_ENTRYPOINT ?= "0x0600"
diff --git a/recipes-bsp/rkbin/rockchip-rkbin_git.bb 
b/recipes-bsp/rkbin/rockchip-rkbin_git.bb
new file mode 100644
index 000..7fefb01
--- /dev/null
+++ b/recipes-bsp/rkbin/rockchip-rkbin_git.bb
@@ -0,0 +1,37 @@
+DESCRIPTION = "Rockchip Firmware and Tool Binaries"
+LICENSE = "Proprietary"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=15faa4a01e7eb0f5d33f9f2bcc7bff62"
+
+SRC_URI = "git://github.com/rockchip-linux/rkbin;protocol=https;branch=master"
+SRCREV = "b4558da0860ca48bf1a571dd33ccba580b9abe23"
+
+PROVIDES += "trusted-firmware-a"
+PROVIDES += "optee-os"
+
+inherit bin_package deploy
+
+S = "${WORKDIR}/git"
+
+COMPATIBLE_MACHINE = ""
+COMPATIBLE_MACHINE:rk3588s = "rk3588s"
+
+PACKAGE_ARCH = "${MACHINE_ARCH}"
+
+do_install() {
+   # Nothing in this recipe is useful in a filesystem
+   :
+}
+
+PACKAGES = "${PN}"
+ALLOW_EMPTY:${PN} = "1"
+
+do_deploy() {
+   # Prebuilt TF-A
+   install -m 644 ${S}/bin/rk35/rk3588_bl31_v*.elf 
${DEPLOYDIR}/bl31-rk3588.elf
+   # Prebuilt OPTEE-OS
+   install -m 644 ${S}/bin/rk35/rk3588_bl32_v*.bin 
${DEPLOYDIR}/tee-rk3588.bin
+   # Prebuilt U-Boot TPL (DDR init)
+   install -m 644 ${S}/bin/rk35/rk3588_ddr_lp4_2112MHz_lp5_2736MHz_v*.bin 
${DEPLOYDIR}/ddr-rk3588.bin
+}
+
+addtask deploy after do_install
diff --git a/recipes-bsp/u-boot/u-boot%.bbappend 
b/recipes-bsp/u-boot/u-boot%.bbappend
index de1f2ca..c611377 100644
--- a/recipes-bsp/u-boot/u-boot%.bbappend
+++ b/recipes-bsp/u-boot/u-boot%.bbappend
@@ -7,6 +7,12 @@ do_compile:append:rock2-square () {
  
  ATF_DEPENDS ??= ""
  
+EXTRA_OEMAKE:append:rk3588s = " \

+   BL31=${DEPLOY_DIR_IMAGE}/bl31-rk3588.elf \
+   ROCKCHIP_TPL=${DEPLOY_DIR_IMAGE}/ddr-rk3588.bin \
+   "
+ATF_DEPENDS:rk3588s = " rockchip-rkbin:do_deploy"
+
  EXTRA_OEMAKE:append:rk3399 = " BL31=${DEPLOY_DIR_IMAGE}/bl31-rk3399.elf"
  ATF_DEPENDS:rk3399 = " trusted-firmware-a:do_deploy"
  EXTRA_OEMAKE:append:rk3328 

Re: [yocto] [meta-rockchip] [PATCH v2] rock-3a add

[Quentin Schulz via lists.yoctoproject.org]

Hi Anthony,

On 10/7/23 01:26, Anthony Davies via lists.yoctoproject.org wrote:

From: Anthony Davies 

Add support for the Radxa Rock 3A
https://wiki.radxa.com/Rock3/3a

The TF-A project does not currently have support for
the rk3568. Therefore, for the time-being, the only way to supply a
TPL/DDR-init for the rk3568 is to use the closed-source rkbin binaries
from Rockchip. If/when TF-A adds support for the rk3588 we can investigate
switching.

recipes-bsp/rkbin/rockchip-rkbin_git.bb was modified to allow a machine
override to allow both rk3568 and rk3588s to use differnet binary blobs

Signed-off-by: Anthony Davies 
---
  README  |  1 +
  conf/machine/include/rk3568.inc | 17 +
  conf/machine/rock-3a.conf   | 12 
  recipes-bsp/rkbin/rockchip-rkbin_git.bb | 16 +++-
  recipes-bsp/u-boot/u-boot%.bbappend |  5 +
  5 files changed, 50 insertions(+), 1 deletion(-)
  create mode 100644 conf/machine/include/rk3568.inc
  create mode 100644 conf/machine/rock-3a.conf

diff --git a/README b/README
index 8104474..3357b47 100644
--- a/README
+++ b/README
@@ -32,6 +32,7 @@ Status of supported boards:
nanopi-r4s
rock-5b
nanopi-r2s
+rock-3a


Please use the same indentation here so it's aligned with the other boards.

It's 2 tabs for the indentation there it seems.


builds:
marsboard-rk3066
radxarock
diff --git a/conf/machine/include/rk3568.inc b/conf/machine/include/rk3568.inc
new file mode 100644
index 000..5382b58
--- /dev/null
+++ b/conf/machine/include/rk3568.inc
@@ -0,0 +1,17 @@
+MACHINEOVERRIDES =. "rk3568:"
+DEFAULTTUNE ?= "cortexa55"
+
+require conf/machine/include/arm/armv8-2a/tune-cortexa55.inc
+require conf/machine/include/rockchip-defaults.inc
+require conf/machine/include/rockchip-wic.inc
+
+KBUILD_DEFCONFIG ?= "defconfig"
+KERNEL_FEATURES:append:rk3568 = " 
bsp/rockchip/remove-non-rockchip-arch-arm64.scc"
+KERNEL_CLASSES ??= "kernel-fitimage"
+KERNEL_IMAGETYPE ??= "fitImage"
+
+PREFERRED_PROVIDER_trusted-firmware-a = "rockchip-rkbin"
+PREFERRED_PROVIDER_optee-os = "rockchip-rkbin"
+
+UBOOT_SUFFIX ?= "itb"
+UBOOT_ENTRYPOINT ?= "0x0600"
diff --git a/conf/machine/rock-3a.conf b/conf/machine/rock-3a.conf
new file mode 100644
index 000..2ed83a3
--- /dev/null
+++ b/conf/machine/rock-3a.conf
@@ -0,0 +1,12 @@
+#@TYPE: Machine
+#@NAME: Radxa Rock 3a
+#@DESCRIPTION: ROCK3 is a series of Rockchip RK3566/RK3568 based
+#SBC(Single Board Computer) and Compute Module by Radxa.
+#https://wiki.radxa.com/Rock3
+
+require conf/machine/include/rk3568.inc
+
+KERNEL_DEVICETREE = "rockchip/rk3568-rock-3a.dtb"
+MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
+
+UBOOT_MACHINE = "rock-3a-rk3568_defconfig"
diff --git a/recipes-bsp/rkbin/rockchip-rkbin_git.bb 
b/recipes-bsp/rkbin/rockchip-rkbin_git.bb
index 7fefb01..273f394 100644
--- a/recipes-bsp/rkbin/rockchip-rkbin_git.bb
+++ b/recipes-bsp/rkbin/rockchip-rkbin_git.bb
@@ -14,6 +14,7 @@ S = "${WORKDIR}/git"
  
  COMPATIBLE_MACHINE = ""

  COMPATIBLE_MACHINE:rk3588s = "rk3588s"
+COMPATIBLE_MACHINE:rk3568 = "rk3568"
  
  PACKAGE_ARCH = "${MACHINE_ARCH}"
  
@@ -25,7 +26,16 @@ do_install() {

  PACKAGES = "${PN}"
  ALLOW_EMPTY:${PN} = "1"
  
-do_deploy() {

+do_deploy:rk3568() {
+   # Prebuilt TF-A
+   install -m 644 ${S}/bin/rk35/rk3568_bl31_v*.elf 
${DEPLOYDIR}/bl31-rk3568.elf
+   # Prebuilt OPTEE-OS
+   install -m 644 ${S}/bin/rk35/rk3568_bl32_v*.bin 
${DEPLOYDIR}/tee-rk3568.bin
+   # Prebuilt U-Boot TPL (DDR init)
+   install -m 644 ${S}/bin/rk35/rk3568_ddr_1560MHz_v1.18.bin 
${DEPLOYDIR}/ddr-rk3568.bin
+}
+
+do_deploy:rk3588s() {
# Prebuilt TF-A
install -m 644 ${S}/bin/rk35/rk3588_bl31_v*.elf 
${DEPLOYDIR}/bl31-rk3588.elf
# Prebuilt OPTEE-OS
@@ -34,4 +44,8 @@ do_deploy() {
install -m 644 ${S}/bin/rk35/rk3588_ddr_lp4_2112MHz_lp5_2736MHz_v*.bin 
${DEPLOYDIR}/ddr-rk3588.bin
  }
  
+do_deploy() {

+# Needed as a default perhaps a bb.fatal with a message saying an override 
needs to be set
+}
+


Well, we could, but also... the recipe won't be used until you add to 
COMPATIBLE_MACHINE, which means the recipe should have been working by 
the time you add it. Not entirely sure how much we want to prevent users 
to shoot their own foot honestly. But I guess it's such a small change 
that adding it is probably better than just arguing whether we need it 
or not, so maybe send another patch to add the bb.fatal :) ?


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61281): https://lists.yoctoproject.org/g/yocto/message/61281
Mute This Topic: https://lists.yoctoproject.org/mt/101808918/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-rockchip] [PATCH v3] rock-3a add

[Quentin Schulz via lists.yoctoproject.org]

Hi Trevor,

On 10/25/23 15:56, Trevor Woerner via lists.yoctoproject.org wrote:

Hi Anthony,

Thanks for working on this.

On Mon 2023-10-16 @ 09:43:45 PM, anthony.t.dav...@gmail.com wrote:

From: Anthony Davies 

Add support for the Radxa Rock 3A
https://wiki.radxa.com/Rock3/3a

The TF-A project does not currently have support for
the rk3568. Therefore, for the time-being, the only way to supply a
TPL/DDR-init for the rk3568 is to use the closed-source rkbin binaries
from Rockchip. If/when TF-A adds support for the rk3588 we can investigate
switching.

recipes-bsp/rkbin/rockchip-rkbin_git.bb was modified to allow a machine
override to allow both rk3568 and rk3588s to use differnet binary blobs

Signed-off-by: Anthony Davies 
---
  README  |  1 +
  conf/machine/include/rk3568.inc | 17 +
  conf/machine/rock-3a.conf   | 12 
  recipes-bsp/rkbin/rockchip-rkbin_git.bb | 16 +++-
  recipes-bsp/u-boot/u-boot%.bbappend |  5 +
  5 files changed, 50 insertions(+), 1 deletion(-)
  create mode 100644 conf/machine/include/rk3568.inc
  create mode 100644 conf/machine/rock-3a.conf

diff --git a/README b/README
index 8104474..3357b47 100644
--- a/README
+++ b/README
@@ -32,6 +32,7 @@ Status of supported boards:
nanopi-r4s
rock-5b
nanopi-r2s
+rock-3a


There's still an issue with indents/tabs.


builds:
marsboard-rk3066
radxarock
diff --git a/conf/machine/include/rk3568.inc b/conf/machine/include/rk3568.inc
new file mode 100644
index 000..5382b58
--- /dev/null
+++ b/conf/machine/include/rk3568.inc
@@ -0,0 +1,17 @@
+MACHINEOVERRIDES =. "rk3568:"
+DEFAULTTUNE ?= "cortexa55"
+
+require conf/machine/include/arm/armv8-2a/tune-cortexa55.inc
+require conf/machine/include/rockchip-defaults.inc
+require conf/machine/include/rockchip-wic.inc
+
+KBUILD_DEFCONFIG ?= "defconfig"
+KERNEL_FEATURES:append:rk3568 = " 
bsp/rockchip/remove-non-rockchip-arch-arm64.scc"
+KERNEL_CLASSES ??= "kernel-fitimage"
+KERNEL_IMAGETYPE ??= "fitImage"
+
+PREFERRED_PROVIDER_trusted-firmware-a = "rockchip-rkbin"
+PREFERRED_PROVIDER_optee-os = "rockchip-rkbin"
+
+UBOOT_SUFFIX ?= "itb"
+UBOOT_ENTRYPOINT ?= "0x0600"
diff --git a/conf/machine/rock-3a.conf b/conf/machine/rock-3a.conf
new file mode 100644
index 000..2ed83a3
--- /dev/null
+++ b/conf/machine/rock-3a.conf
@@ -0,0 +1,12 @@
+#@TYPE: Machine
+#@NAME: Radxa Rock 3a
+#@DESCRIPTION: ROCK3 is a series of Rockchip RK3566/RK3568 based
+#SBC(Single Board Computer) and Compute Module by Radxa.
+#https://wiki.radxa.com/Rock3
+
+require conf/machine/include/rk3568.inc
+
+KERNEL_DEVICETREE = "rockchip/rk3568-rock-3a.dtb"
+MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
+
+UBOOT_MACHINE = "rock-3a-rk3568_defconfig"
diff --git a/recipes-bsp/rkbin/rockchip-rkbin_git.bb 
b/recipes-bsp/rkbin/rockchip-rkbin_git.bb
index 7fefb01..ad5593c 100644
--- a/recipes-bsp/rkbin/rockchip-rkbin_git.bb
+++ b/recipes-bsp/rkbin/rockchip-rkbin_git.bb
@@ -14,6 +14,7 @@ S = "${WORKDIR}/git"
  
  COMPATIBLE_MACHINE = ""

  COMPATIBLE_MACHINE:rk3588s = "rk3588s"
+COMPATIBLE_MACHINE:rk3568 = "rk3568"
  
  PACKAGE_ARCH = "${MACHINE_ARCH}"
  
@@ -25,7 +26,16 @@ do_install() {

  PACKAGES = "${PN}"
  ALLOW_EMPTY:${PN} = "1"
  
-do_deploy() {

+do_deploy:rk3568() {
+   # Prebuilt TF-A
+   install -m 644 ${S}/bin/rk35/rk3568_bl31_v*.elf 
${DEPLOYDIR}/bl31-rk3568.elf
+   # Prebuilt OPTEE-OS
+   install -m 644 ${S}/bin/rk35/rk3568_bl32_v*.bin 
${DEPLOYDIR}/tee-rk3568.bin
+   # Prebuilt U-Boot TPL (DDR init)
+   install -m 644 ${S}/bin/rk35/rk3568_ddr_1560MHz_v1.18.bin 
${DEPLOYDIR}/ddr-rk3568.bin
+}
+
+do_deploy:rk3588s() {
# Prebuilt TF-A
install -m 644 ${S}/bin/rk35/rk3588_bl31_v*.elf 
${DEPLOYDIR}/bl31-rk3588.elf
# Prebuilt OPTEE-OS
@@ -34,4 +44,8 @@ do_deploy() {
install -m 644 ${S}/bin/rk35/rk3588_ddr_lp4_2112MHz_lp5_2736MHz_v*.bin 
${DEPLOYDIR}/ddr-rk3588.bin
  }
  
+do_deploy() {

+  bbfatal "COMPATIBLE_MACHINE requires a corressponding do_deploy:() 
override"
+}
+


This is not related to adding support for rock3a.



In a way it is, but would benefit in being in a different commit I agree.

So basically Anthony's issue (if I remember correctly) was that if 
you're not overriding the default do_deploy, the recipe will pass but 
install the wrong files with the wrong names, without telling you.


So instead, the thought was to make do_deploy fail by default (with 
bbfatal) unless it is overridden (e.g. for rk3588s and rk3568) so that 
people adding support for new SoCs don't wonder what's missing.


I could see a commit with a diff like:
"""
-do_deploy() {
+do_deploy:rk3588s() {
# Prebuilt TF-A
   	install -m 644 ${S}/bin/rk35/rk3588_bl31_v*.elf 
${DEPLOYDIR}/bl31-rk3588.elf

# Prebuilt OPTEE-OS
@@ -34,4 +44,8 @@ do_deploy() {
  	install -m 644 
${S}/bin/rk35/rk3588_ddr_l

Re: [yocto] [meta-rockchip] [PATCH v3] rock-3a add

[Quentin Schulz via lists.yoctoproject.org]

Hi Trevor,

On 10/25/23 16:42, Trevor Woerner wrote:

On Wed 2023-10-25 @ 04:22:17 PM, Quentin Schulz wrote:

Hi Trevor,

On 10/25/23 15:56, Trevor Woerner via lists.yoctoproject.org wrote:

Hi Anthony,

Thanks for working on this.

On Mon 2023-10-16 @ 09:43:45 PM, anthony.t.dav...@gmail.com wrote:

From: Anthony Davies 

Add support for the Radxa Rock 3A
https://wiki.radxa.com/Rock3/3a

The TF-A project does not currently have support for
the rk3568. Therefore, for the time-being, the only way to supply a
TPL/DDR-init for the rk3568 is to use the closed-source rkbin binaries
from Rockchip. If/when TF-A adds support for the rk3588 we can investigate
switching.

recipes-bsp/rkbin/rockchip-rkbin_git.bb was modified to allow a machine
override to allow both rk3568 and rk3588s to use differnet binary blobs

Signed-off-by: Anthony Davies 
---
   README  |  1 +
   conf/machine/include/rk3568.inc | 17 +
   conf/machine/rock-3a.conf   | 12 
   recipes-bsp/rkbin/rockchip-rkbin_git.bb | 16 +++-
   recipes-bsp/u-boot/u-boot%.bbappend |  5 +
   5 files changed, 50 insertions(+), 1 deletion(-)
   create mode 100644 conf/machine/include/rk3568.inc
   create mode 100644 conf/machine/rock-3a.conf

diff --git a/README b/README
index 8104474..3357b47 100644
--- a/README
+++ b/README
@@ -32,6 +32,7 @@ Status of supported boards:
nanopi-r4s
rock-5b
nanopi-r2s
+rock-3a


There's still an issue with indents/tabs.


builds:
marsboard-rk3066
radxarock
diff --git a/conf/machine/include/rk3568.inc b/conf/machine/include/rk3568.inc
new file mode 100644
index 000..5382b58
--- /dev/null
+++ b/conf/machine/include/rk3568.inc
@@ -0,0 +1,17 @@
+MACHINEOVERRIDES =. "rk3568:"
+DEFAULTTUNE ?= "cortexa55"
+
+require conf/machine/include/arm/armv8-2a/tune-cortexa55.inc
+require conf/machine/include/rockchip-defaults.inc
+require conf/machine/include/rockchip-wic.inc
+
+KBUILD_DEFCONFIG ?= "defconfig"
+KERNEL_FEATURES:append:rk3568 = " 
bsp/rockchip/remove-non-rockchip-arch-arm64.scc"
+KERNEL_CLASSES ??= "kernel-fitimage"
+KERNEL_IMAGETYPE ??= "fitImage"
+
+PREFERRED_PROVIDER_trusted-firmware-a = "rockchip-rkbin"
+PREFERRED_PROVIDER_optee-os = "rockchip-rkbin"
+
+UBOOT_SUFFIX ?= "itb"
+UBOOT_ENTRYPOINT ?= "0x0600"
diff --git a/conf/machine/rock-3a.conf b/conf/machine/rock-3a.conf
new file mode 100644
index 000..2ed83a3
--- /dev/null
+++ b/conf/machine/rock-3a.conf
@@ -0,0 +1,12 @@
+#@TYPE: Machine
+#@NAME: Radxa Rock 3a
+#@DESCRIPTION: ROCK3 is a series of Rockchip RK3566/RK3568 based
+#SBC(Single Board Computer) and Compute Module by Radxa.
+#https://wiki.radxa.com/Rock3
+
+require conf/machine/include/rk3568.inc
+
+KERNEL_DEVICETREE = "rockchip/rk3568-rock-3a.dtb"
+MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
+
+UBOOT_MACHINE = "rock-3a-rk3568_defconfig"
diff --git a/recipes-bsp/rkbin/rockchip-rkbin_git.bb 
b/recipes-bsp/rkbin/rockchip-rkbin_git.bb
index 7fefb01..ad5593c 100644
--- a/recipes-bsp/rkbin/rockchip-rkbin_git.bb
+++ b/recipes-bsp/rkbin/rockchip-rkbin_git.bb
@@ -14,6 +14,7 @@ S = "${WORKDIR}/git"
   COMPATIBLE_MACHINE = ""
   COMPATIBLE_MACHINE:rk3588s = "rk3588s"
+COMPATIBLE_MACHINE:rk3568 = "rk3568"
   PACKAGE_ARCH = "${MACHINE_ARCH}"
@@ -25,7 +26,16 @@ do_install() {
   PACKAGES = "${PN}"
   ALLOW_EMPTY:${PN} = "1"
-do_deploy() {
+do_deploy:rk3568() {
+   # Prebuilt TF-A
+   install -m 644 ${S}/bin/rk35/rk3568_bl31_v*.elf 
${DEPLOYDIR}/bl31-rk3568.elf
+   # Prebuilt OPTEE-OS
+   install -m 644 ${S}/bin/rk35/rk3568_bl32_v*.bin 
${DEPLOYDIR}/tee-rk3568.bin
+   # Prebuilt U-Boot TPL (DDR init)
+   install -m 644 ${S}/bin/rk35/rk3568_ddr_1560MHz_v1.18.bin 
${DEPLOYDIR}/ddr-rk3568.bin
+}
+
+do_deploy:rk3588s() {
# Prebuilt TF-A
install -m 644 ${S}/bin/rk35/rk3588_bl31_v*.elf 
${DEPLOYDIR}/bl31-rk3588.elf
# Prebuilt OPTEE-OS
@@ -34,4 +44,8 @@ do_deploy() {
install -m 644 ${S}/bin/rk35/rk3588_ddr_lp4_2112MHz_lp5_2736MHz_v*.bin 
${DEPLOYDIR}/ddr-rk3588.bin
   }
+do_deploy() {
+  bbfatal "COMPATIBLE_MACHINE requires a corressponding do_deploy:() 
override"
+}
+


This is not related to adding support for rock3a.



In a way it is, but would benefit in being in a different commit I agree.

So basically Anthony's issue (if I remember correctly) was that if you're
not overriding the default do_deploy, the recipe will pass but install the
wrong files with the wrong names, without telling you.

So instead, the thought was to make do_deploy fail by default (with bbfatal)
unless it is overridden (e.g. for rk3588s and rk3568) so that people adding
support for new SoCs don't wonder what's missing.

I could see a commit with a diff like:
"""
-do_deploy() {
+do_deploy:rk3588s() {
# Prebuilt TF-A
install -m 644 ${S}/bin/rk35/rk3588_bl31_v*.elf
${DEPLOYDIR}/bl31-rk3588.elf

Re: [yocto] [meta-rockchip][PATCH] rockchip-rkbin: fail if lacking an override

[Quentin Schulz via lists.yoctoproject.org]

Hi Trevor,

Looks good to me,

Reviewed-by: Quentin Schulz 

Cheers,
Quentin

On 10/25/23 16:57, Trevor Woerner via lists.yoctoproject.org wrote:

Looking forward, rkbin should only be used by specific Rockchip platforms
for which TF-A support is not (yet?) available. If rkbin gets added by
accident without an override, add a bbfatal to let the user know an
override is required.

Signed-off-by: Trevor Woerner 
---
  recipes-bsp/rkbin/rockchip-rkbin_git.bb | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/recipes-bsp/rkbin/rockchip-rkbin_git.bb 
b/recipes-bsp/rkbin/rockchip-rkbin_git.bb
index f9e680d16cb9..a3ab34189041 100644
--- a/recipes-bsp/rkbin/rockchip-rkbin_git.bb
+++ b/recipes-bsp/rkbin/rockchip-rkbin_git.bb
@@ -25,7 +25,7 @@ do_install() {
  PACKAGES = "${PN}"
  ALLOW_EMPTY:${PN} = "1"
  
-do_deploy() {

+do_deploy:rk3588s() {
# Prebuilt TF-A
install -m 644 ${S}/bin/rk35/rk3588_bl31_v*.elf 
${DEPLOYDIR}/bl31-rk3588.elf
# Prebuilt OPTEE-OS
@@ -34,4 +34,8 @@ do_deploy() {
install -m 644 ${S}/bin/rk35/rk3588_ddr_lp4_2112MHz_lp5_2736MHz_v*.bin 
${DEPLOYDIR}/ddr-rk3588.bin
  }
  
+do_deploy() {

+   bbfatal "COMPATIBLE_MACHINE requires a corresponding do_deploy:() 
override"
+}
+
  addtask deploy after do_install






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61574): https://lists.yoctoproject.org/g/yocto/message/61574
Mute This Topic: https://lists.yoctoproject.org/mt/102179996/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-rockchip][PATCH 3/3] rock-pi-s: add

[Quentin Schulz via lists.yoctoproject.org]

Hi Trevor,

On 10/30/23 18:26, Trevor Woerner wrote:

On Wed 2023-10-04 @ 04:23:31 PM, Quentin Schulz wrote:

On 10/3/23 15:56, Trevor Woerner wrote:

On Mon 2023-10-02 @ 06:17:15 PM, Quentin Schulz wrote:

diff --git a/recipes-bsp/rkbin/rockchip-rkbin_git.bb 
b/recipes-bsp/rkbin/rockchip-rkbin_git.bb
index 7fefb017053b..49e1e682eb7d 100644
--- a/recipes-bsp/rkbin/rockchip-rkbin_git.bb
+++ b/recipes-bsp/rkbin/rockchip-rkbin_git.bb
@@ -1,9 +1,12 @@
DESCRIPTION = "Rockchip Firmware and Tool Binaries"
LICENSE = "Proprietary"
+LICENSE:rk3308 = "CLOSED"
LIC_FILES_CHKSUM = "file://LICENSE;md5=15faa4a01e7eb0f5d33f9f2bcc7bff62"
+LIC_FILES_CHKSUM:rk3308 = "file://README;md5=39cc9df955478b8df26158d489fdcc95"
SRC_URI = 
"git://github.com/rockchip-linux/rkbin;protocol=https;branch=master"
SRCREV = "b4558da0860ca48bf1a571dd33ccba580b9abe23"
+SRCREV:rk3308 = "e65b97b511f1349156702db40694454c141d8fe2"


Could you please say a few words about this change? It seems that there are
still binaries for it in the SRCREV we already point to. I assume newer
should be better (though it's not always the case), so wondering what's
prompted this change?


Oooh, there is no TPL with uart0m0 support anymore... honestly not sure
it's a good idea to stay on a old blob version just for that? I assume you
should only be missing the uart in TPL but the moment you reach the SPL the
console should appear, doesn't it?


Exactly, I would prefer to be able to capture all of the console output all in
one place. It's annoying they randomly decided to change uarts for every other
update. As far as I'm concerned one binary blob is a good (or bad) as the
next, and if this one gives me diagnostic info in the console, then it wins
:-)



I think this is a bit too much to hope for :) In the commit logs for ddr-bin
updates in rkbin, I've seen a few mentions to DDR init stability/reliability
for example. So saying it's all the same is probably incorrect.


I did a test with the rk3308 binaries from the latest commit of rkbin that
don't support uart0. Specifically I tested with 
rk3308_ddr_589MHz_uart4_m0_v2.07.bin:
this also works.

Also, it's a lot less hassle to build (rather than rolling back to a release
that has a uart0 console for the rk3308). However, even though the console is
set to uart4, this binary also outputs a lot of data to uart0. I've tried both
1,500,000 baud (the standard rockchip baud) and 115,200 baud: neither are able
to interpret the data. U-Boot, apparently, doesn't try to reset the serial
port either, because the garbage output continues until the Linux kernel
finally takes over. Or perhaps maybe the gibberish that I'm seeing is from
U-Boot outputting to an uninitialized serial port?



So, the TPL (ddr.bin) we get from rockchip-rkbin isn't configurable and 
it outputs something on some UART controller for the user to be able to 
debug stuff.


Then, if U-Boot isn't properly supported (which is sadly often the case 
in the beginning or, for poorly supported SoCs... forever), it just 
simply does nothing for configuring the debug serial (or initializes the 
"wrong" one). I don't remember exactly if U-Boot does something with the 
serial device defined as main output in the DTB used by U-Boot or if it 
just expects the SPL to properly set up everything.


I think this should be fixed in U-Boot itself in any case. See what I 
had to do for PX30 a year ago for example: 
https://source.denx.de/u-boot/u-boot/-/commit/d0af506625ff909b123a298e435a95ae1b8ee3e7


I haven't looked into it in depth, but it seems only UART2 is supported 
currently on RK3308, c.f. 
https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/mach-rockchip/rk3308/rk3308.c?ref_type=heads#L178



Roll back to older rkbin checkout:
PRO:
- supports console on uart0 (same as linux kernel) and all messages from
   rkbin, u-boot, linux kernel, and console appear legibly on the terminal
CON:
- more cumbersome to build (recipe requires a bunch of rk3308-based
   overrides), perhaps a separate rkbin recipe would be better?
- uses older ddr initialization code

Use latest rkbin:
PRO:
- simpler recipe, no overrides necessary, simpler build
- uses the latest code (might include bug fixes or other improvements?)
CON:
- spews a bunch of gibberish to the serial console (from rkbin? from u-boot?
   from both?)
- the first legible messages only start once the linux kernel takes over,
   therefore the user can't interact with U-Boot (should they so wish)


This would be a blocker to me if I were to use this board, so I second 
your decision of going for older rkbin for now.


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61575): https://lists.yoctoproject.org/g/yocto/message/61575
Mute This Topic: https://lists.yoctoproject.org/mt/101691822/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-

Re: [yocto] Problem when adding own tasks

[Quentin Schulz via lists.yoctoproject.org]

Hi,

On 11/11/23 18:05, Khem Raj via lists.yoctoproject.org wrote:

On Sat, Nov 11, 2023 at 4:04 AM athragared via lists.yoctoproject.org
 wrote:


Hello everyone, this is my first mail here, I hope this is the right "channel" 
for my question.

I am currently using the 'Kirkstone' branch of yocto and I have encountered a 
problem. I have written a .bbappend file for systemd in my own layer. Here I 
have written my own python function as follows:

python do_my_own_function(){
 # do something
}
addtask my_own_function before do_install

This seems to work most of the time. However, I would like to execute my own 
function AFTER the do_install. However, this does not seem to work.


Code says _before_ but you say you wanted it _after_ do_install is
run, so maybe change the directive to before, moreover, add anchors on
both sides
to ensure its run in certain order so maybe say before do_package
after do_install.



To add to Khem's answer, a task is only run if it is required.

A task is required because some other task requires it or if the user 
does (e.g. via bitbake -c  ).


When one adds a task **after** another one (taskB after taskA), the 
latter won't be run unless explicitly. This is why Khem was suggesting 
to add "before do_package" because do_package is a task that is very 
commonly executed during a normal package build. It is not necessarily 
where in the build process you want it to be, so think a bit before 
inserting a task between two other tasks, since both extremities matter.


Cheers,
Quentin


you can also look into postfuncs/prefuncs

do_install[postfuncs] += "do_my_own_function"


If I delete the build folder before building the image and then look in the 
log.task_order file I see that my own function is NOT executed. Other people on 
stackoverflow seem to have observed this problem as well.



So I wanted to ask how to solve the problem or debug it further?


Regards







-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61667): https://lists.yoctoproject.org/g/yocto/message/61667
Mute This Topic: https://lists.yoctoproject.org/mt/102524578/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Remove Python dependency from target package only

[Quentin Schulz via lists.yoctoproject.org]

Hi Holger,

On 1/22/24 14:33, Sebert, Holger.ext via lists.yoctoproject.org wrote:

[You don't often get email from 
holger.sebert.ext=karlstorz@lists.yoctoproject.org. Learn why this is 
important at https://aka.ms/LearnAboutSenderIdentification ]

Hi Richard,

Von: Richard Purdie 

Try:

PACKAGECONFIG:remove:class-target:pn-libxml2 = "python"



Tried it, but same error appears (“Python not found” in libxml2-native).



What does
bitbake-getvar -r libxml2-native PACKAGECONFIG
and
bitbake-getvar -r libxml2 PACKAGECONFIG

return?

I'm not entirely sure if the former will work since bitbake-getvar 
expects a recipe and libxml2 isn't really a recipe on its own.


If the former doesn't work, we need to check for 
PACKAGECONFIG:class-native and PACKAGECONFIG:class-target in 
bitbake-getvar -r libxml2 PACKAGECONFIG to debug this further.


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#62220): https://lists.yoctoproject.org/g/yocto/message/62220
Mute This Topic: https://lists.yoctoproject.org/mt/103871920/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-rockchip][PATCH] u-boot: make rock-pi-e patches only for rock-pi-e

[Quentin Schulz via lists.yoctoproject.org]

Hi Trevor,

On 1/24/24 18:51, Trevor Woerner via lists.yoctoproject.org wrote:

The U-Boot patches that were added recently are only for the rock-pi-e
MACHINE, therefore only apply them when building for rock-pi-e.

Fixes: b5bba3a01197 ("rock-pi-e: apply upstream PHY fix")
Signed-off-by: Trevor Woerner 


Reviewed-by: Quentin Schulz 

What a nice timing, got "bothered" by this a few hours ago but got 
sidetracked :)


I **think** this would make more sense in a u-boot_2024.01.bbappend 
though, since it'll likely only apply on top of that version :)


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#62261): https://lists.yoctoproject.org/g/yocto/message/62261
Mute This Topic: https://lists.yoctoproject.org/mt/103937031/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-rockchip][PATCH 1/4] rockchip.wks: specify fstype

[Quentin Schulz via lists.yoctoproject.org]

Hi Trevor,

On 2/12/24 21:23, Trevor Woerner via lists.yoctoproject.org wrote:

If the wks file doesn't specify, the fstype is assumed to be vfat. Most of
the partitions in the Rockchip layout don't have filesystems. Implicitly
setting the fstype to vfat causes wic to format the partitions. Also,
it doesn't make sense to format the rawcopy partitions as vfat, just to
immediately overwrite them with binaries.

Signed-off-by: Trevor Woerner 


Makes sense,

Reviewed-by: Quentin Schulz 

Thanks,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#62495): https://lists.yoctoproject.org/g/yocto/message/62495
Mute This Topic: https://lists.yoctoproject.org/mt/104319693/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-rockchip][PATCH 2/4] rockchip.wks: add all Rockchip partitions

[Quentin Schulz via lists.yoctoproject.org]

Hi Trevor,

On 2/12/24 21:23, Trevor Woerner via lists.yoctoproject.org wrote:

Rockchip defines the expected layout/map of the default storage device.
Fill out the wks description so it matches.

https://opensource.rock-chips.com/wiki_Partitions

Signed-off-by: Trevor Woerner 
---
  wic/rockchip.wks | 18 --
  1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/wic/rockchip.wks b/wic/rockchip.wks
index b14ec0d1690a..8dc4d20f2f54 100644
--- a/wic/rockchip.wks
+++ b/wic/rockchip.wks
@@ -9,16 +9,22 @@
  # wic uses 1KB blocks. The following table uses 512 byte sectors:
  #
  #   Partition   Start SectorNumber of Sectors
-#   loader1 64  8000(idbloader / U-Boot SPL)
-#   reserved1   8064128
-#   reserved2   81928192
+#   loader1 64  7104(idbloader / U-Boot SPL)
+#   vstorage7168512 (serial number, MAC address, etc)
+#   reserved7680384 (not used)
+#   reserved1   806464  (legacy DRM key)
+#   uboot_env   812864  (U-Boot environment)
+#   reserved2   81928192(legacy parameters, ATAGS, etc)
  #   loader2 16384   8192(U-Boot proper)
-#   atf 24576   8192
+#   atf 24576   8192(trusted OS e.g. ATR, OP-TEE, etc)
  #   boot32768   229376
  #   root262144  -   (suggested)
  
-part loader1--offset 32 --fixed-size 4000K--fstype=none--source rawcopy   --sourceparams="file=${SPL_BINARY}"

-part reserved1  --offset 4032   --fixed-size 64K  --fstype=none
+part loader1--offset 32 --fixed-size 3552K--fstype=none--source 
rawcopy   --sourceparams="file=${SPL_BINARY}"
+part vstorage   --offset 3584   --fixed-size 256K --fstype=none
+part reserved   --offset 3840   --fixed-size 192K --fstype=none
+part reserved1  --offset 4032   --fixed-size 32K  --fstype=none
+part uboot_env  --offset 4064   --fixed-size 32K  --fstype=none
  part reserved2  --offset 4096   --fixed-size 4096K--fstype=none
  part loader2--offset 8192   --fixed-size 4096K--fstype=none--source 
rawcopy   
--sourceparams="file=u-boot.${UBOOT_SUFFIX}"
  part atf--offset 12288  --fixed-size 4096K--fstype=none



This is... quite dangerous. I assume people access raw partitions via 
their index number, and now they would be changed, making it harder to 
do partial updates. It depends how one sees this file, but could be seen 
as immutable for existing partitions to avoid backward compatibility issues.


I was wondering whether there is support for partition labels or 
something like that for raw partitions, but doesn't seem like it. Which 
is quite odd, wouldn't that kind of information be stored in the 
partition table for example?


Also, maybe use sectors for offsets and fixed-sizes since you document 
them this way? S is the suffix for it.


Random thought, but we could probably also get the env from U-Boot 
recipe (or any other recipe that generates one) (if one is generated) 
and install it into uboot_env partition?


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#62496): https://lists.yoctoproject.org/g/yocto/message/62496
Mute This Topic: https://lists.yoctoproject.org/mt/104319694/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-rockchip][PATCH 3/4] remove /boot partition from wic:bootimg-paritition

[Quentin Schulz via lists.yoctoproject.org]

Hi Trevor,

On 2/12/24 21:23, Trevor Woerner via lists.yoctoproject.org wrote:

In order to boot successfully, most Rockchip SoCs require a specific
partitioning scheme which was defined many years (and many SoCs) ago. That
partitioning scheme places the SPL and U-Boot at specific offsets at the
start of the boot block device:

https://opensource.rock-chips.com/wiki_Partitions

The Rockchip partitioning scheme goes on to also define the locations and
sizes of a number of additional partitions, including the "boot" and "root"
partitions.

Since both the SPL and U-Boot have already been placed on the block device,
the "boot" partition only contains the extlinux config file and the
kernel+dtb/fitImage; it doesn't contain any bootloader artifacts (other
than the extlinux config).

The locations and sizes of the SPL and U-Boot partitions are hard
dependencies since the BOOTROM etched inside the Rockchip SoCs is > programmed 
to blindly load and run what it finds at these locations. The


What matters is the location of TPL+SPL, U-Boot proper can be 
programmatically be put anywhere (not where TPL+SPL is of course :) ). 
The SPL actually stores in itself where to look for U-Boot proper in the 
storage media (and different storage media may have different locations, 
we have this for Puma RK3399 which has a differnet location for U-Boot 
proper on SPI-NOR and on eMMC/SD card). We do this on Puma RK3399 and 
Ringneck PX30 for example (but we're not using this wks file so this 
isn't really relevant). Also, IIRC, the BootROM tries a few locations 
for the TPL+SPL in the boot storage medium (e.g. every 32KB offsets for 
the first 2/3/4).


Also, "blindly" is a bit of a stretch, the BootROM checks for a magic 
header value and then another magic string (e.g. RK33 for RK3399 and 
PX30). RK3568 and RK3588 have a different header layout also (headerv1 
vs headerv2). There's also secure boot that is possible, doing a bunch 
of extra checks directly from the BootROM, etc. :)



locations, sizes, and contents of the "boot" and "root" partitions are
not so rigid since it is U-Boot which interacts with them. U-Boot is very
flexible with how it finds boot components, and in its support for various
devices, filesystems, sizes, etc.

Both oe-core's U-Boot metadata and wic's bootimg-partition script contain
logic to generate the extlinux pieces required for a bootloader to boot
a Linux system. If both are enabled, the wic pieces silently clobber the
U-Boot pieces. However, the mechanisms contained in the U-Boot metadata are
much more flexible, from a user's point of view, than the mechanisms in
bootimg-partition.

Also, if a user wishes to setup some sort of A/B redundant update
mechanism, they must have redundant root partitions (in order to update
their filesystem contents) but they also need to have redundant boot
partitions if they wish to update the kernel as part of their update
mechanism. Pairing redundant kernel partitions with redundant filesystem
partitions becomes unnecessarily complicated. Therefore it makes sense
to combine the kernel and the filesystem into the same partition so that
both the kernel and filesystem are updated, or rolled back, in lock-step
as one unit. Specific kernel versions and configurations often have
dependencies on user-space components and versions.



And now users would have to update a potentially multi-gigabyte image 
only to update their kernel or dtb :)



The boot partition is not going away. This patch simply transfers
responsibility for its creation to the more flexible U-Boot mechanism and
includes the kernel as part of the same partition as the root filesystem.


This means the boot partition is going away :) which is confirmed by the 
change in wic/rockchip.wks.


I think you meant to say the boot directory is not going away, or rather 
the content of the boot partition is not going away?



Not only does it add flexibility, it also makes update schemes more
straightforward. Although having a separate /boot partition is a
"requirement" of the Rockchip partitioning scheme, it is not an actual
hard requirement when using a flexible, open-source bootloader (such as
U-Boot) instead of using Rockchip's proprietary miniloader, preloader, and
trust.img.



The upgrade path from current state to the new one is not 
straightforward though? The boot partition would disappear IF the 
partition table is reflashed (which is rarely done I guess?) Otherwise 
it would still exist, with the old and never-to-be-updated-again kernel 
binaries in the /boot partition (which does very much still exist unless 
you reflash the partition table AND flash on the / partition with the 
update mechanism). This also means that a rollback is impossible.



Boot-tested on:
nanopi-m4b, nanopi-r2s, nanopi-r4s, roc-rk3328-cc, rock-3a,
rock-pi-4b, rock-5a, rock-5b, rock-pi-e, rock-pi-s, rock64

Signed-off-by: Trevor Woerner 
---
  conf/machine/include/rockchip-defaults.inc |  2 ++
  conf/mac

Re: [yocto] [meta-rockchip][PATCH 4/4] wks file cleanup

[Quentin Schulz via lists.yoctoproject.org]

Hi Trevor,

On 2/12/24 21:23, Trevor Woerner via lists.yoctoproject.org wrote:

Cleanup the elements of the wic/rockchip.wks file so they take up less
horizontal space.

Signed-off-by: Trevor Woerner 


Reviewed-by: Quentin Schulz 

Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#62499): https://lists.yoctoproject.org/g/yocto/message/62499
Mute This Topic: https://lists.yoctoproject.org/mt/104319697/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-rockchip][PATCH 2/4] rockchip.wks: add all Rockchip partitions

[Quentin Schulz via lists.yoctoproject.org]

Hi Trevor,

On 2/15/24 20:20, Trevor Woerner wrote:

On Thu 2024-02-15 @ 06:06:42 PM, Quentin Schulz wrote:

Hi Trevor,

On 2/12/24 21:23, Trevor Woerner via lists.yoctoproject.org wrote:

Rockchip defines the expected layout/map of the default storage device.
Fill out the wks description so it matches.

https://opensource.rock-chips.com/wiki_Partitions

Signed-off-by: Trevor Woerner 
---
   wic/rockchip.wks | 18 --
   1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/wic/rockchip.wks b/wic/rockchip.wks
index b14ec0d1690a..8dc4d20f2f54 100644
--- a/wic/rockchip.wks
+++ b/wic/rockchip.wks
@@ -9,16 +9,22 @@
   # wic uses 1KB blocks. The following table uses 512 byte sectors:
   #
   #   Partition   Start SectorNumber of Sectors
-#   loader1 64  8000(idbloader / U-Boot SPL)
-#   reserved1   8064128
-#   reserved2   81928192
+#   loader1 64  7104(idbloader / U-Boot SPL)
+#   vstorage7168512 (serial number, MAC address, etc)
+#   reserved7680384 (not used)
+#   reserved1   806464  (legacy DRM key)
+#   uboot_env   812864  (U-Boot environment)
+#   reserved2   81928192(legacy parameters, ATAGS, etc)
   #   loader2 16384   8192(U-Boot proper)
-#   atf 24576   8192
+#   atf 24576   8192(trusted OS e.g. ATR, OP-TEE, etc)
   #   boot32768   229376
   #   root262144  -   (suggested)
-part loader1--offset 32 --fixed-size 4000K--fstype=none--source 
rawcopy   --sourceparams="file=${SPL_BINARY}"
-part reserved1  --offset 4032   --fixed-size 64K  --fstype=none
+part loader1--offset 32 --fixed-size 3552K--fstype=none--source 
rawcopy   --sourceparams="file=${SPL_BINARY}"
+part vstorage   --offset 3584   --fixed-size 256K --fstype=none
+part reserved   --offset 3840   --fixed-size 192K --fstype=none
+part reserved1  --offset 4032   --fixed-size 32K  --fstype=none
+part uboot_env  --offset 4064   --fixed-size 32K  --fstype=none
   part reserved2  --offset 4096   --fixed-size 4096K--fstype=none
   part loader2--offset 8192   --fixed-size 4096K--fstype=none
--source rawcopy   
--sourceparams="file=u-boot.${UBOOT_SUFFIX}"
   part atf--offset 12288  --fixed-size 4096K--fstype=none



This is... quite dangerous. I assume people access raw partitions via their
index number, and now they would be changed, making it harder to do partial
updates. It depends how one sees this file, but could be seen as immutable
for existing partitions to avoid backward compatibility issues.


I don't think that's a huge problem, but I could be wrong. People will see
their builds fail, investigate, update, and move on?



Why would the builds fail? This is a runtime issue IMO. E.g. they flash 
idbloader.img to mmcblkXp0 and u-boot.itb to mmcblkXp3 but now they 
would need to flash the latter to mmcblkXp6. And if they have a device 
that was flashed with the old partition table and another device with 
the new partition table, they need some kind of userspace logic to 
figure out which is which? They could also be flashing at an offset on 
mmcblkX itself, but then this change wouldn't impact them in any way.



But I think I saw something in wic about not adding a partition to the table,
or not giving it a number? So it might be possible to define these partitions
and not change the numbers? I could look into it a bit more.



That makes sense, but then.. what would the change in this commit 
actually bring to the table? I guess as documentation?


[...]


Random thought, but we could probably also get the env from U-Boot recipe
(or any other recipe that generates one) (if one is generated) and install
it into uboot_env partition?


That's exactly where I'm going with this. I already have a spreadsheet
listing all the rockchip devices, and their U-Boot environment configurations
(location, size, etc) to see which ones come with environment configurations,
and to make sure they're all the correct location and size for those that do
(they are). I also already have Yocto pieces generating and placing
the U-Boot environment in the U-Boot environment partition (via wic) but
haven't submitted the patches yet (as well as generating a correct
/etc/fw_env.config file. My next step is to add in env support in U-Boot for
those missing it.


Cool.

Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#62516): https://lists.yoctoproject.org/g/yocto/message/62516
Mute This Topic: https://lists.yoctoproject.org/mt/104319694/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https:

Re: [yocto] [meta-rockchip][PATCH 3/4] remove /boot partition from wic:bootimg-paritition

[Quentin Schulz via lists.yoctoproject.org]

On 2/16/24 09:25, Trevor Woerner wrote:

On Thu 2024-02-15 @ 06:45:59 PM, Quentin Schulz wrote:

Hi Trevor,

On 2/12/24 21:23, Trevor Woerner via lists.yoctoproject.org wrote:

[...]

+UBOOT_EXTLINUX_KERNEL_IMAGE ?= "/boot/${KERNEL_IMAGETYPE}"


FWIW, I don't think /boot is required. bootstd/bootmeth in U-Boot (upstream
at the very least) will check for / and then /boot prefix for the paths in
extlinux.conf. Not providing /boot means if someone still wants to use a
separate boot partition, they wouldn't have to update this variable. But
since it's overridable, this is basically up to your preference.


This is a good example of working ahead. The next thing I have queued up is
a meta-rauc-rockchip example that works generically on all (most?) rockchip
boards. As part of the U-Boot script I need to make the A/B logic work, it
needs the "/boot" in there otherwise it doesn't work; therefore it's best to
set it up properly now.



Mmmm I'm interested to see why it fails without the /boot thing? Let's 
see when we get patches :)



+UBOOT_EXTLINUX_LABELS ?= "default"
+UBOOT_EXTLINUX_MENU_DESCRIPTION:default ?= "${MACHINE}"
+
+MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "u-boot-extlinux"


Is the image actually bootable if we do NOT have u-boot-extlinux installed?
I'm challenging the RRECOMMENDS basically. And wondering whether
MACHINE_ESSENTIAL_EXTRA_* is always included (it seems like RDEPENDS one is
part of packagegroup-core-boot which is virtually installed in all images).


I can double-check, but I'm pretty sure that line was added explicitly after
testing and noticing that it was needed. If we remove the extlinux artifacts
from the image, what boot method is U-Boot supposed to use?



I'm not saying it is not needed, I'm thinking _RRECOMMENDS is too weak 
and it should be _RDEPENDS instead?


I'm not sure the wic image (or rather the rootfs) is proper basically if 
u-boot-extlinux is not installed.


As for what U-Boot does if it doesn't find an extlinux.conf, it depends 
on what U-Boot is configured to do. If I rememebr correctly, most (all) 
Rockchip boards now use bootflow by default.


You can check the content of the bootcmd environment variable, that's 
what's started when the user does nothing to interrupt the boot.


For me on Jaguar RK3588:
"""
> printenv bootcmd
bootcmd=bootflow scan -lb
"""

remove the -b flag so it doesn't boot and you should have something 
reasonable.


For me:
"""
=> bootflow scan -lae
Scanning for bootflows in all bootdevs
Seq  Method   State   UclassPart  Name  Filename
---  ---  --       


Scanning global bootmeth 'efi_mgr':
  0  efi_mgr  ready   (none)   0  
Scanning bootdev 'mmc@fe2e.bootdev':
  1  extlinux media   mmc  0  m...@fe2e.bootdev.whol
 ** No partition found, err=-2: No such file or directory
  2  script   media   mmc  0  m...@fe2e.bootdev.whol
 ** No partition found, err=-2: No such file or directory
  3  efi  media   mmc  0  m...@fe2e.bootdev.whol
 ** No partition found, err=-2: No such file or directory
  4  pxe  basemmc  0  m...@fe2e.bootdev.whol
 ** No media/partition found, err=-524: Unknown error
  5  extlinux media   mmc  1  m...@fe2e.bootdev.part
 ** No partition found, err=-22: Invalid argument
  6  script   media   mmc  1  m...@fe2e.bootdev.part
 ** No partition found, err=-22: Invalid argument
  7  efi  media   mmc  1  m...@fe2e.bootdev.part
 ** No partition found, err=-22: Invalid argument
  8  pxe  basemmc  1  m...@fe2e.bootdev.part
 ** No media/partition found, err=-524: Unknown error
  9  extlinux media   mmc  2  m...@fe2e.bootdev.part
 ** No partition found, err=-22: Invalid argument
  a  script   media   mmc  2  m...@fe2e.bootdev.part
 ** No partition found, err=-22: Invalid argument
  b  efi  media   mmc  2  m...@fe2e.bootdev.part
 ** No partition found, err=-22: Invalid argument
  c  pxe  basemmc  2  m...@fe2e.bootdev.part
 ** No media/partition found, err=-524: Unknown error
  d  extlinux media   mmc  3  m...@fe2e.bootdev.part
 ** No partition found, err=-22: Invalid argument
  e  script   media   mmc  3  m...@fe2e.bootdev.part
 ** No partition found, err=-22: Invalid argument
  f  efi  media   mmc  3  m...@fe2e.bootdev.part
 ** No partition found, err=-22: Invalid argument
 10  pxe  basemmc  3  m...@fe2e.bootdev.part
 ** No media/partition found, err=-524: Unknown error
 11  extlinux media   mmc  4  m...@fe2e.bootdev.part
 ** No partition found, err=-22: Invalid argument
 12  script   media   mmc  4  m...@fe2e.bootdev.part
 ** No partit

Re: [yocto] [meta-rockchip][PATCH v2 2/4] rockchip.wks: add all Rockchip partitions

[Quentin Schulz via lists.yoctoproject.org]

Hi Trevor,

On 2/16/24 09:29, Trevor Woerner via lists.yoctoproject.org wrote:

Rockchip defines the expected layout/map of the default storage device.
Fill out the wks description so it matches.

https://opensource.rock-chips.com/wiki_Partitions

Note: in the Rockchip layout, not all partitions are expected to show up
in the gpt partition table. This patch uses "--no-table" to only number the
partitions that are numbered in the Rockchip wiki, as well as to give these
partitions the partition numbers indicated in the wiki.

Note: there is a mistake in the Rockchip table (which I've copied
verbatim here). Going by the values of the "Start Sector", the size of
the "reserved1" partition is listed as being 2x its actual size/number of
sectors.

Expected:
Partition   Start Sector   Number of SectorsPartition Size  
   PartNum in GPTRequirements
MBR 0  1   0001 512   0.5KB
Primary GPT 1  000163  003F 32256 31.5KB
loader1 64 004071041bc0 4096000   2.5MB 
   1 preloader (miniloader or U-Boot SPL)
Vendor Storage  7168   1c00512 0200 262144256KB 
 SN, MAC and etc.
Reserved Space  7680   1e00384 0180 196608192KB 
 Not used
reserved1   8064   1f80128 0080 65536 64KB  
 legacy DRM key
U-Boot ENV  8128   1fc064  0040 32768 32KB
reserved2   8192   200081922000 4194304   4MB   
 legacy parameter
loader2 16384  400081922000 4194304   4MB   
   2 U-Boot or UEFI
trust   24576  600081922000 4194304   4MB   
   3 trusted-os like ATF, OP-TEE
boot32768  8000229376  00038000 117440512 112MB 
   4 kernel, dtb, extlinux.conf, ramdisk
rootfs  262144 0004-   -- -MB   
   5 Linux system

Prior to this patch:
# fdisk -l /dev/mmcblk1
GPT PMBR size mismatch (1504727 != 30375935) will be corrected by write.
The backup GPT table is not on the end of the device.
Disk /dev/mmcblk1: 14.48 GiB, 15552479232 bytes, 30375936 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: ----4D9B9EF0

Device  Start End Sectors   Size Type
/dev/mmcblk1p1 6480638000   3.9M Microsoft basic data
/dev/mmcblk1p2   80648191 12864K Microsoft basic data
/dev/mmcblk1p3   8192   163838192 4M Microsoft basic data
/dev/mmcblk1p4  16384   245758192 4M Microsoft basic data
/dev/mmcblk1p5  24576   327678192 4M Microsoft basic data
/dev/mmcblk1p6  32768  330955  298188 145.6M Microsoft basic data
/dev/mmcblk1p7 330956 1504693 1173738 573.1M Linux filesystem

New:
# fdisk -l /dev/mmcblk1
GPT PMBR size mismatch (1504727 != 30375935) will be corrected by write.
The backup GPT table is not on the end of the device.
Disk /dev/mmcblk1: 14.48 GiB, 15552479232 bytes, 30375936 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: ----4D9B9EF0

Device  Start End Sectors   Size Type
/dev/mmcblk1p1 6471677104   3.5M Linux filesystem
/dev/mmcblk1p2  16384   245758192 4M Linux filesystem
/dev/mmcblk1p3  24576   327678192 4M Linux filesystem
/dev/mmcblk1p4  32768  330955  298188 145.6M Microsoft basic data
/dev/mmcblk1p5 330956 1504693 1173738 573.1M Linux filesystem

Signed-off-by: Trevor Woerner 
---
changes in v2:
- expand the commit message to show past, expected, and new behaviour
- spell out that vstorage stands for "vendor storage"
---
  wic/rockchip.wks | 20 +---
  1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/wic/rockchip.wks b/wic/rockchip.wks
index b14ec0d1690a..034443d90050 100644
--- a/wic/rockchip.wks
+++ b/wic/rockchip.wks
@@ -9,17 +9,23 @@
  # wic uses 1KB blocks. The following table uses 512 byte sectors:
  #
  #   Partition   Start SectorNumber of Sectors
-#   loader1 64  8000(idbloader / U-Boot SPL)
-#   reserved1   8064128
-#   reserved2   81928192
+#   loader1 64  7104(i

Re: [yocto] [meta-rockchip][PATCH v2 3/4] remove /boot partition

[Quentin Schulz via lists.yoctoproject.org]

Hi Trevor,

On 2/16/24 09:29, Trevor Woerner via lists.yoctoproject.org wrote:

In order to boot successfully, most Rockchip SoCs require a specific
partitioning scheme which was defined many years (and many SoCs) ago. That
partitioning scheme places the SPL and U-Boot at specific offsets at the
start of the boot block device:

https://opensource.rock-chips.com/wiki_Partitions

The Rockchip partitioning scheme goes on to also define the locations and
sizes of a number of additional partitions, including the "boot" and "root"
partitions.

Since both the SPL and U-Boot have already been placed on the block device,
the "boot" partition only contains the extlinux config file and the
kernel+dtb/fitImage; it doesn't contain any bootloader artifacts (other
than the extlinux config).

The location and size of the SPL partition is a hard dependency since the


Just because I like being pedantic, I don't thhink the size is a hard 
dependency. The location is (well there are a few possible though :) ), 
but the size is part of the header(s) that is parsed by the BootROM, the 
BootROM will only fetch what it needs as far as I remember. It's a bit 
of convoluted code but it's done in tools/rkcommon.c in U-Boot source code.


What we can say though is that the TPL+SPL has a maximum size, since it 
needs to fit inside the SRAM. But I don't think any SoC has been 
released by Rockchip that has 2.5MiB of SRAM, it's usually a few tens of 
KiB max only. Anyway, the message is fine, just wanted to give a bit 
more info there.


[...]


diff --git a/conf/machine/include/rockchip-extlinux.inc 
b/conf/machine/include/rockchip-extlinux.inc
new file mode 100644
index ..3af7ed629e34
--- /dev/null
+++ b/conf/machine/include/rockchip-extlinux.inc
@@ -0,0 +1,12 @@
+UBOOT_EXTLINUX ?= "1"
+UBOOT_EXTLINUX_ROOT ?= "root=PARTLABEL=root"
+UBOOT_EXTLINUX_FDTDIR ?= "${@bb.utils.contains('KERNEL_IMAGETYPE', 'fitImage', '', 
'/boot', d)}"
+NONFITDT ?= "${@d.getVar('KERNEL_DEVICETREE').split('/')[1]}"


Maybe keep the comment explaining the logic of this line?


+UBOOT_EXTLINUX_FDT ?= "${@bb.utils.contains('KERNEL_IMAGETYPE', 'fitImage', '', 
'${NONFITDT}', d)}"
+UBOOT_EXTLINUX_CONSOLE ?= "earlycon console=tty1 
console=${RK_CONSOLE_DEVICE},${RK_CONSOLE_BAUD}n8"
+UBOOT_EXTLINUX_KERNEL_ARGS ?= "rootwait rw rootfstype=ext4"
+UBOOT_EXTLINUX_KERNEL_IMAGE ?= "/boot/${KERNEL_IMAGETYPE}"
+UBOOT_EXTLINUX_LABELS ?= "default"
+UBOOT_EXTLINUX_MENU_DESCRIPTION:default ?= "${MACHINE}"
+
+MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "u-boot-extlinux"


Going back to the mail I sent a few minutes ago on the v1 (which was 
sent after your v2 was sent :) ), I have a gut feeling we need _RDEPENDS 
here and not _RRECOMMENDS.


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#62519): https://lists.yoctoproject.org/g/yocto/message/62519
Mute This Topic: https://lists.yoctoproject.org/mt/104389371/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-rockchip][PATCH 3/4] remove /boot partition from wic:bootimg-paritition

[Quentin Schulz via lists.yoctoproject.org]

Hi Trevor,

On 2/18/24 18:28, Trevor Woerner wrote:

On Fri 2024-02-16 @ 10:31:36 AM, Quentin Schulz wrote:



On 2/16/24 09:25, Trevor Woerner wrote:

On Thu 2024-02-15 @ 06:45:59 PM, Quentin Schulz wrote:

Hi Trevor,

On 2/12/24 21:23, Trevor Woerner via lists.yoctoproject.org wrote:

[...]

+UBOOT_EXTLINUX_KERNEL_IMAGE ?= "/boot/${KERNEL_IMAGETYPE}"


FWIW, I don't think /boot is required. bootstd/bootmeth in U-Boot (upstream
at the very least) will check for / and then /boot prefix for the paths in
extlinux.conf. Not providing /boot means if someone still wants to use a
separate boot partition, they wouldn't have to update this variable. But
since it's overridable, this is basically up to your preference.


This is a good example of working ahead. The next thing I have queued up is
a meta-rauc-rockchip example that works generically on all (most?) rockchip
boards. As part of the U-Boot script I need to make the A/B logic work, it
needs the "/boot" in there otherwise it doesn't work; therefore it's best to
set it up properly now.



Mmmm I'm interested to see why it fails without the /boot thing? Let's see
when we get patches :)


I'm working on getting rauc working with meta-rockchip generically so it works
with all the MACHINES in meta-rockchip. The patch won't be part of
meta-rockchip, but rather be part of a meta-rauc-community/meta-rauc-rockchip
I hope to submit upstream at some point.

Basically rauc works with U-Boot via a boot script. To make that script more
flexible I'm borrowing a variable form meta-rockchip in the rauc U-Boot script
to actually do the booting of the kernel/fitImage/etc. So while U-Boot might
be smart enough to check a bunch of places looking for the thing to boot, the
rauc boot script isn't quite so smart. It's my script to write, and I could
add such logic, but that would just inflate the script for questionable gain.



This seems like you're not using extlinux.conf when using rauc but using 
one of the variables used to build the extlinux.conf to do some 
magic/logic in rauc?


In any case, not a blocker.

Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#62554): https://lists.yoctoproject.org/g/yocto/message/62554
Mute This Topic: https://lists.yoctoproject.org/mt/104319696/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-rockchip][PATCH v3 1/5] rockchip.wks: specify offsets in sectors

[Quentin Schulz via lists.yoctoproject.org]

Hi Trevor,

On 2/19/24 18:48, Trevor Woerner via lists.yoctoproject.org wrote:

In WIC, size arguments can be optionally specified using one of a variety
of suffixes (e.g. K, M, G, etc.) thanks to sizetype(). One such suffix being
"s/S" for handling sector sizes which are assumed to be 512 bytes, rather than
the other size suffixes which are multiples of 1024 bytes.

Using the s/S sizetype allows the definition to match the documentation.
Unfortunately we can not use the s/S suffix for --fixed-size.

Signed-off-by: Trevor Woerner 


Reviewed-by: Quentin Schulz 

Thanks,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#62555): https://lists.yoctoproject.org/g/yocto/message/62555
Mute This Topic: https://lists.yoctoproject.org/mt/104451453/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-rockchip][PATCH v3 3/5] rockchip.wks: add most Rockchip partitions

[Quentin Schulz via lists.yoctoproject.org]

Hi Trevor,

On 2/19/24 18:48, Trevor Woerner via lists.yoctoproject.org wrote:

Rockchip defines the expected layout/map of the default storage device.
Fill out the wks description so it matches.

 https://opensource.rock-chips.com/wiki_Partitions

There are 2 partitions at the start that can not be specified in
rockchip.wks due to a limitation in wic which assumes all sizes (e.g.
--size or --fixed-size) are specified in units of 1024 bytes. Due to the
fact these partitions don't fall on 1024-byte boundaries, they can not be
specified at this time.

Note: in the Rockchip layout, not all partitions are expected to show up
in the gpt partition table. This patch uses "--no-table" to only number the
partitions that are numbered in the Rockchip wiki, as well as to give these
partitions the partition numbers indicated in the wiki.

Note: there is a mistake in the Rockchip table (which I've copied verbatim
here in this commit message but corrected in rockchip.wks). Going by the
values of the "Start Sector", the size of the "reserved1" partition is
listed as being 2x its actual size/number of sectors.

Expected:
 Partition   Start Sector   Number of SectorsPartition Size 
PartNum in GPTRequirements
 MBR 0  1   0001 512   0.5KB
 Primary GPT 1  000163  003F 32256 
31.5KB
 loader1 64 004071041bc0 4096000   
2.5MB1 preloader (miniloader or U-Boot SPL)
 Vendor Storage  7168   1c00512 0200 262144
256KB  SN, MAC and etc.
 Reserved Space  7680   1e00384 0180 196608
192KB  Not used
 reserved1   8064   1f80128 0080 65536 64KB 
  legacy DRM key
 U-Boot ENV  8128   1fc064  0040 32768 32KB
 reserved2   8192   200081922000 4194304   4MB  
  legacy parameter
 loader2 16384  400081922000 4194304   4MB  
2 U-Boot or UEFI
 trust   24576  600081922000 4194304   4MB  
3 trusted-os like ATF, OP-TEE
 boot32768  8000229376  00038000 117440512 
112MB4 kernel, dtb, extlinux.conf, ramdisk
 rootfs  262144 0004-   -- -MB  
5 Linux system

Prior to this patch:
 # fdisk -l /dev/mmcblk1
 GPT PMBR size mismatch (1504727 != 30375935) will be corrected by 
write.
 The backup GPT table is not on the end of the device.
 Disk /dev/mmcblk1: 14.48 GiB, 15552479232 bytes, 30375936 sectors
 Units: sectors of 1 * 512 = 512 bytes
 Sector size (logical/physical): 512 bytes / 512 bytes
 I/O size (minimum/optimal): 512 bytes / 512 bytes
 Disklabel type: gpt
 Disk identifier: ----4D9B9EF0

 Device  Start End Sectors   Size Type
 /dev/mmcblk1p1 6480638000   3.9M Microsoft basic data
 /dev/mmcblk1p2   80648191 12864K Microsoft basic data
 /dev/mmcblk1p3   8192   163838192 4M Microsoft basic data
 /dev/mmcblk1p4  16384   245758192 4M Microsoft basic data
 /dev/mmcblk1p5  24576   327678192 4M Microsoft basic data
 /dev/mmcblk1p6  32768  330955  298188 145.6M Microsoft basic data
 /dev/mmcblk1p7 330956 1504693 1173738 573.1M Linux filesystem

New:
 # fdisk -l /dev/mmcblk1
 GPT PMBR size mismatch (1504727 != 30375935) will be corrected by 
write.
 The backup GPT table is not on the end of the device.
 Disk /dev/mmcblk1: 14.48 GiB, 15552479232 bytes, 30375936 sectors
 Units: sectors of 1 * 512 = 512 bytes
 Sector size (logical/physical): 512 bytes / 512 bytes
 I/O size (minimum/optimal): 512 bytes / 512 bytes
 Disklabel type: gpt
 Disk identifier: ----4D9B9EF0

 Device  Start End Sectors   Size Type
 /dev/mmcblk1p1 6471677104   3.5M Linux filesystem
 /dev/mmcblk1p2  16384   245758192 4M Linux filesystem
 /dev/mmcblk1p3  24576   327678192 4M Linux filesystem
 /dev/mmcblk1p4  32768  330955  298188 145.6M Microsoft basic data
 /dev/mmcblk1p5 330956 1504693 1173738 573.1M Linux filesystem

Reviewed-by: Quentin Schulz 
Signed-off-by: Trevor Woerner 
---
changes in v3:
- tweaked to accommodate offsets specified in sectors
- clarified that the first 2 partitions can not be added
- change name of vstorage to v_storage
- fixed typo (ATR -> ATF)
- added Quentin's tag

changes in v2:
- expand the commit message to show past, 

Re: [yocto] [meta-rockchip][PATCH v3 4/5] remove /boot partition

[Quentin Schulz via lists.yoctoproject.org]

Hi Trevor,

On 2/19/24 18:48, Trevor Woerner via lists.yoctoproject.org wrote:

In order to boot successfully, most Rockchip SoCs require a specific
partitioning scheme which was defined many years (and many SoCs) ago. That
partitioning scheme places the SPL and U-Boot at specific offsets at the
start of the boot block device:

 https://opensource.rock-chips.com/wiki_Partitions

The Rockchip partitioning scheme goes on to also define the locations
of a number of additional partitions, including the "boot" and "root"
partitions.

Since both the SPL and U-Boot have already been placed on the block device,
the "boot" partition only contains the extlinux config file and the
kernel+dtb/fitImage; it doesn't contain any bootloader artifacts (other
than the extlinux config).

The location of the SPL partition is a hard dependency since the BOOTROM
etched inside the Rockchip SoCs is programmed to load and run a validated
binary it finds at this location. The locations of the "boot" and "root"
partitions are not so rigid since it is U-Boot which interacts with them.
U-Boot is very flexible with how it finds boot components, and in its
support for various devices, filesystems, sizes, etc.

Both oe-core's U-Boot metadata and wic's bootimg-partition script contain
logic to generate the extlinux pieces required for a bootloader to boot
a Linux system. If both are enabled, the wic pieces silently clobber the
U-Boot pieces. However, the mechanisms contained in the U-Boot metadata are
much more flexible, from a user's point of view, than the mechanisms in
wic's bootimg-partition.

If a user wishes to setup some sort of A/B redundant update mechanism, they
must have redundant root partitions (in order to update their filesystem
contents) but they also need to have redundant boot partitions if they
wish to update the kernel as part of their update mechanism. Pairing
redundant kernel partitions with redundant filesystem partitions becomes
unnecessarily complicated. Therefore it makes sense to combine the kernel
and the filesystem into the same partition so that both the kernel and
filesystem are updated, or rolled back, in lock-step as one unit. Specific
kernel versions and configurations often have dependencies on user-space
components and versions.

The /boot location is not going away. This patch simply transfers
responsibility for its creation to the more flexible U-Boot mechanism
and includes the kernel as part of the same partition as the root
filesystem. Not only does it add flexibility, it also makes update schemes
more straightforward. Although having a separate /boot partition is a
"requirement" of the Rockchip partitioning scheme, it is not an actual
hard requirement when using a flexible, open-source bootloader (such as
U-Boot) instead of using Rockchip's proprietary miniloader, preloader, and
trust.img.

Build-tested for all boards.
Run-tested on:
nanopi-m4-2gb, nanopi-m4b, nanopi-r2s, nanopi-r4s, roc-rk3328-cc,
rock-3a, rock-5a, rock-5b, rock-pi-4b, rock-pi-e, rock-pi-s,
rock64

Signed-off-by: Trevor Woerner 


Reviewed-by: Quentin Schulz 

Thanks,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#62557): https://lists.yoctoproject.org/g/yocto/message/62557
Mute This Topic: https://lists.yoctoproject.org/mt/104451459/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-rockchip][PATCH v3 3/5] rockchip.wks: add most Rockchip partitions

[Quentin Schulz via lists.yoctoproject.org]

Hi Trevor,

On 2/21/24 20:02, Trevor Woerner wrote:

On Wed 2024-02-21 @ 07:38:41 PM, Quentin Schulz wrote:

Hi Trevor,

On 2/19/24 18:48, Trevor Woerner via lists.yoctoproject.org wrote:

Rockchip defines the expected layout/map of the default storage device.
Fill out the wks description so it matches.

  https://opensource.rock-chips.com/wiki_Partitions

There are 2 partitions at the start that can not be specified in
rockchip.wks due to a limitation in wic which assumes all sizes (e.g.
--size or --fixed-size) are specified in units of 1024 bytes. Due to the
fact these partitions don't fall on 1024-byte boundaries, they can not be
specified at this time.

Note: in the Rockchip layout, not all partitions are expected to show up
in the gpt partition table. This patch uses "--no-table" to only number the
partitions that are numbered in the Rockchip wiki, as well as to give these
partitions the partition numbers indicated in the wiki.

Note: there is a mistake in the Rockchip table (which I've copied verbatim
here in this commit message but corrected in rockchip.wks). Going by the
values of the "Start Sector", the size of the "reserved1" partition is
listed as being 2x its actual size/number of sectors.

Expected:
  Partition   Start Sector   Number of SectorsPartition 
Size PartNum in GPTRequirements
  MBR 0  1   0001 512   
0.5KB
  Primary GPT 1  000163  003F 32256 
31.5KB
  loader1 64 004071041bc0 4096000   
2.5MB1 preloader (miniloader or U-Boot SPL)
  Vendor Storage  7168   1c00512 0200 262144
256KB  SN, MAC and etc.
  Reserved Space  7680   1e00384 0180 196608
192KB  Not used
  reserved1   8064   1f80128 0080 65536 
64KB   legacy DRM key
  U-Boot ENV  8128   1fc064  0040 32768 32KB
  reserved2   8192   200081922000 4194304   4MB 
   legacy parameter
  loader2 16384  400081922000 4194304   4MB 
 2 U-Boot or UEFI
  trust   24576  600081922000 4194304   4MB 
 3 trusted-os like ATF, OP-TEE
  boot32768  8000229376  00038000 117440512 
112MB4 kernel, dtb, extlinux.conf, ramdisk
  rootfs  262144 0004-   -- -MB 
 5 Linux system

Prior to this patch:
  # fdisk -l /dev/mmcblk1
  GPT PMBR size mismatch (1504727 != 30375935) will be corrected by 
write.
  The backup GPT table is not on the end of the device.
  Disk /dev/mmcblk1: 14.48 GiB, 15552479232 bytes, 30375936 sectors
  Units: sectors of 1 * 512 = 512 bytes
  Sector size (logical/physical): 512 bytes / 512 bytes
  I/O size (minimum/optimal): 512 bytes / 512 bytes
  Disklabel type: gpt
  Disk identifier: ----4D9B9EF0

  Device  Start End Sectors   Size Type
  /dev/mmcblk1p1 6480638000   3.9M Microsoft basic data
  /dev/mmcblk1p2   80648191 12864K Microsoft basic data
  /dev/mmcblk1p3   8192   163838192 4M Microsoft basic data
  /dev/mmcblk1p4  16384   245758192 4M Microsoft basic data
  /dev/mmcblk1p5  24576   327678192 4M Microsoft basic data
  /dev/mmcblk1p6  32768  330955  298188 145.6M Microsoft basic data
  /dev/mmcblk1p7 330956 1504693 1173738 573.1M Linux filesystem

New:
  # fdisk -l /dev/mmcblk1
  GPT PMBR size mismatch (1504727 != 30375935) will be corrected by 
write.
  The backup GPT table is not on the end of the device.
  Disk /dev/mmcblk1: 14.48 GiB, 15552479232 bytes, 30375936 sectors
  Units: sectors of 1 * 512 = 512 bytes
  Sector size (logical/physical): 512 bytes / 512 bytes
  I/O size (minimum/optimal): 512 bytes / 512 bytes
  Disklabel type: gpt
  Disk identifier: ----4D9B9EF0

  Device  Start End Sectors   Size Type
  /dev/mmcblk1p1 6471677104   3.5M Linux filesystem
  /dev/mmcblk1p2  16384   245758192 4M Linux filesystem
  /dev/mmcblk1p3  24576   327678192 4M Linux filesystem
  /dev/mmcblk1p4  32768  330955  298188 145.6M Microsoft basic data
  /dev/mmcblk1p5 330956 1504693 1173738 573.1M Linux filesystem

Reviewed-by: Quentin Schulz 
Signed-off-by: Trevor Woerner 
---
changes in v3:
- tweaked to accommodate offsets specified in sectors
- clarified that the first 2 partitions can no

Re: [yocto] [meta-rockchip][PATCH 3/4] remove /boot partition from wic:bootimg-paritition

[Quentin Schulz via lists.yoctoproject.org]

Hi Trevor,

On 2/21/24 20:18, Trevor Woerner wrote:

On Wed 2024-02-21 @ 07:31:17 PM, Quentin Schulz wrote:

Hi Trevor,

On 2/18/24 18:28, Trevor Woerner wrote:

On Fri 2024-02-16 @ 10:31:36 AM, Quentin Schulz wrote:



On 2/16/24 09:25, Trevor Woerner wrote:

On Thu 2024-02-15 @ 06:45:59 PM, Quentin Schulz wrote:

Hi Trevor,

On 2/12/24 21:23, Trevor Woerner via lists.yoctoproject.org wrote:

[...]

+UBOOT_EXTLINUX_KERNEL_IMAGE ?= "/boot/${KERNEL_IMAGETYPE}"


FWIW, I don't think /boot is required. bootstd/bootmeth in U-Boot (upstream
at the very least) will check for / and then /boot prefix for the paths in
extlinux.conf. Not providing /boot means if someone still wants to use a
separate boot partition, they wouldn't have to update this variable. But
since it's overridable, this is basically up to your preference.


This is a good example of working ahead. The next thing I have queued up is
a meta-rauc-rockchip example that works generically on all (most?) rockchip
boards. As part of the U-Boot script I need to make the A/B logic work, it
needs the "/boot" in there otherwise it doesn't work; therefore it's best to
set it up properly now.



Mmmm I'm interested to see why it fails without the /boot thing? Let's see
when we get patches :)


I'm working on getting rauc working with meta-rockchip generically so it works
with all the MACHINES in meta-rockchip. The patch won't be part of
meta-rockchip, but rather be part of a meta-rauc-community/meta-rauc-rockchip
I hope to submit upstream at some point.

Basically rauc works with U-Boot via a boot script. To make that script more
flexible I'm borrowing a variable form meta-rockchip in the rauc U-Boot script
to actually do the booting of the kernel/fitImage/etc. So while U-Boot might
be smart enough to check a bunch of places looking for the thing to boot, the
rauc boot script isn't quite so smart. It's my script to write, and I could
add such logic, but that would just inflate the script for questionable gain.



This seems like you're not using extlinux.conf when using rauc but using one
of the variables used to build the extlinux.conf to do some magic/logic in
rauc?


I'm using sed to search and replace a tag in a U-Boot script template with
UBOOT_EXTLINUX_KERNEL_IMAGE which my U-Boot bbappend then turns into a U-Boot
script that handles the rauc A/B logic.

Specifically once it figures out whether to use A or B,
UBOOT_EXTLINUX_KERNEL_IMAGE is what is booted.

So keeping the initial "/boot/" part of UBOOT_EXTLINUX_KERNEL_IMAGE is useful
to me so the U-Boot script can find what it needs to boot in the filesystem
image. I could strip that prefix from the variable and include it as part of
the script template, but the current way provides the most flexibility. In
theory the fitImage could be located anywhere in the filesystem and the U-Boot
script would be able to find, load, and run it.


Would be nice if you had some code somewhere we could use as a base for 
discussion :)


FWIW, upstream U-Boot seems to have some interest using VBL/VBE for A/B 
mechanism, this seems to be pushed by Google? So maybe something to look 
there in the future.


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#62565): https://lists.yoctoproject.org/g/yocto/message/62565
Mute This Topic: https://lists.yoctoproject.org/mt/104319696/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-rockchip][PATCH] enable stored U-Boot environment

[Quentin Schulz via lists.yoctoproject.org]

Hi Trevor,

On 3/21/24 18:53, Trevor Woerner via lists.yoctoproject.org wrote:

When U-Boot is built it is compiled with a set of environment variables
(and their values) built into the U-Boot binary. U-Boot can be configured
to use storage to load and/or store environment variables which can persist
over reboots. This storage could be (but not limited to) a chunk of an MMC
device, it could be in SPI, or simply a file in the device's filesystem. If
this storage-based environment is valid (checksum is verified) U-Boot will
use these values over any same values which are built-in.

By default some of the MACHINES in this BSP layer are configured to use
a persistent U-Boot environment, others are not. It all depends on what
is set in the specific defconfig file for the device found in upstream,
mainline U-Boot. This is, apparently, random.

If you want to ensure that you have access to an on-boot-device, persistent
U-Boot environment, simply add the following to MACHINE_FEATURES in your
configuration:

rk-u-boot-env

If you have enabled this feature, you now have a second choice to make:
do you want your build to include the U-Boot environment in the image or
not? The default environment, as generated by U-Boot, can be included in
the generated wic image. If it is included, then flashing the image will
also flash the default U-Boot environment variables and settings, wiping
out anything that might have been there already. If it is not included then
your device will either continue using whatever environment happens to be
there, or will not use any stored environment if the stored environment has
not been set or is invalid. The variable which governs this behaviour is:

RK_IMAGE_INCLUDES_UBOOT_ENV

By default this is set to "0", meaning that by default the image does
not contain the U-Boot environment. To enable this behaviour, set this
variable to "1" in your configuration. This variable only takes effect if
the rk-u-boot-env MACHINE_FEATURE is enabled, and has no effect otherwise.

The script:

scripts/dump-uboot-env-from-yocto-image.sh

can be used on your wic file to see the contents of the U-Boot environment
partition at build time.

Signed-off-by: Trevor Woerner 
---
  README| 45 +++
  classes/rk-u-boot-env.bbclass |  1 +
  conf/machine/include/rockchip-wic.inc | 10 +
  .../rockchip-enable-environment-mmc.cfg   |  4 ++
  .../rockchip-enable-environment-mmc0.cfg  |  1 +
  .../rockchip-enable-environment-mmc1.cfg  |  1 +
  recipes-bsp/u-boot/u-boot_%.bbappend  | 24 ++
  scripts/dump-uboot-env-from-yocto-image.sh| 29 
  wic/rockchip.wks  |  2 +-
  9 files changed, 116 insertions(+), 1 deletion(-)
  create mode 100644 classes/rk-u-boot-env.bbclass
  create mode 100644 
recipes-bsp/u-boot/files/rk-u-boot-env/rockchip-enable-environment-mmc.cfg
  create mode 100644 
recipes-bsp/u-boot/files/rk-u-boot-env/rockchip-enable-environment-mmc0.cfg
  create mode 100644 
recipes-bsp/u-boot/files/rk-u-boot-env/rockchip-enable-environment-mmc1.cfg
  create mode 100755 scripts/dump-uboot-env-from-yocto-image.sh

diff --git a/README b/README
index 4c30f7529353..e357e093d45f 100644
--- a/README
+++ b/README
@@ -67,6 +67,51 @@ Notes:

in the configuration (e.g. conf/local.conf).
  
+U-Boot Environment:

+--
+   When U-Boot is built it is compiled with a set of environment variables
+   (and their values) built into the U-Boot binary. U-Boot can be 
configured
+   to use storage to load and/or store environment variables which can 
persist
+   over reboots. This storage could be (but not limited to) a chunk of an 
MMC
+   device, it could be in SPI, or simply a file in the device's 
filesystem. If
+   this storage-based environment is valid (checksum is verified) U-Boot 
will
+   use these values over any same values which are built-in.
+
+   By default some of the MACHINES in this BSP layer are configured to use
+   a persistent U-Boot environment, others are not. It all depends on what
+   is set in the specific defconfig file for the device found in upstream,
+   mainline U-Boot. This is, apparently, random.
+
+   If you want to ensure that you have access to an on-boot-device, 
persistent


If I'm not mistaken the current implementation in this patchseries 
forces the use of an SD card, so I wouldn't say it "ensures that you 
have access to an on-boot-device".



+   U-Boot environment, simply add the following to MACHINE_FEATURES in your
+   configuration:
+
+   rk-u-boot-env
+
+   If you have enabled this feature, you now have a second choice to make:
+   do you want your build to include the U-Boot environment in the image or
+   not? The default environment, as generated by U-Boot, can be included in
+   the generated wic imag

Re: [yocto] Implicit RPROVIDES somewhere ?

[Quentin Schulz via lists.yoctoproject.org]

Hi Joel,

On 4/16/24 16:50, Joel GUITTET via lists.yoctoproject.org wrote:

You don't often get email from 
jguittet.opensource=witekio@lists.yoctoproject.org. Learn why this is 
important
Hello,

I have a target with multilib aarch64+arm.
I'm building a library "foo" that DEPENDS of library "bar". I need the library "foo" to 
be installed in the rootfs, but not the library "bar" (for specific reason in my project).


It'd be nice to know what those specific reasons are, maybe they are not 
reasonable in the context of building with Yocto :) (and we may be able 
to suggest other options, like rather fixing the software build system 
instead of hacking deep into Yocto if there's no other option).



The recipe of library "foo" DEPENDS of "bar" but no RDEPENDS is used.

arm arch: I observe that the library "foo" is installed in "/usr/lib", and library 
"bar" is not installed, as expected.
aarch64 arch: I observe that the library "foo" is installed in "/usr/lib64", and library 
"bar" is installed in "/usr/lib64" as well, which is not what I want !!

It seems there is like an implicit RDEPENDS there, but only for the aarch64 
architecture.



Packages providing SONAME entries in a shared library/binary from 
another package are always part of RDEPENDS so I would start there.


https://docs.yoctoproject.org/overview-manual/concepts.html#automatically-added-runtime-dependencies

You can check by using readelf or objdump on your libraries/binaries in 
foo packages. I **think** bitbake also tells you about this implicit 
dependency and the reason for it if you increase the debug level (-D -DD 
or even -DDD?).


It could very well be that your SW is built differently for aarch64 than 
for arm and it actually links against libbar. THen you would need to fix 
your piece of SW to not link against it.


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#62939): https://lists.yoctoproject.org/g/yocto/message/62939
Mute This Topic: https://lists.yoctoproject.org/mt/105558513/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Implicit RPROVIDES somewhere ?

[Quentin Schulz via lists.yoctoproject.org]

Hi Joel,

On 4/16/24 19:09, Joel GUITTET via Lists.Yoctoproject.Org wrote:

You don't often get email from 
jguittet.opensource=witekio@lists.yoctoproject.org. Learn why this is 
important
Hello Quentin,

Thanks for the quick reply on this question!

The reason of this organisation is that my customer is responsible of providing library "bar" (he cannot share the source code 
with me), and we are responsible of providing library "foo". It's not confortable for sure, but it's the actual state. So my 
customer provides me the "bar" libraries (arm and aarch64) compiled (so files), that I copy/paste in my layer. And then I build 
"foo" libraries that are linked to "bar" and additionally I have to install only the "foo" libraries in the 
rootfs.



So far so good. Not an uncommon setup, bar recipe would be following the 
prebuilt binary section in the documentation. 
https://docs.yoctoproject.org/dev-manual/prebuilt-libraries.html


The thing I do not understand is why you do NOT want bar on the rootfs? 
Your foo shared library explicitly states that it requires libbar.so to 
be able to run, why do you not want libbar.so in your rootfs?



The library that is building "foo" have nothing specific to the architecture. The IMAGE_INSTALL has 
"lib32-foo" and "foo".
But something to mention that may have an impact here : because of this organization 
above my recipe that is building "foo" have the following (else I don't succeed 
to build):


This smells like bad build system/instructions for the foo recipe. All 
libraries built by Yocto should be versioned, I highly recommend to fix 
your foo SW to have some version in there to not have to deal with this. 
It's best practice and will help you in the long run anyway (actually 
trying to figure out which version the customer is using by simply 
looking at the filename for example). But I don't think that should 
impact libfoo being added or not.




FILES_SOLIBSDEV = ""
INSANE_SKIP:${PN} += "dev-so"
INSANE_SKIP:${PN} += "file-rdeps"



This INSANE_SKIP isn't that common and I don't think it's that good of 
an idea?


There's one thing I missed is that you're building with multilib. Do you 
actually have a lib32-bar package and a bar package? Is your libbar.so 
available in both aarch32 and aarch64 architectures?


I assume that the automagic RDEPENDS got broken for lib32-foo and you 
are not seeing it because of

INSANE_SKIP:${PN} += "file-rdeps"

It's probably trying to locate a multilib lib32 package containing 
libbar.so but cannot find any and complains about it. The aarch64 
package does find a package for libbar.so so it adds it automatically.


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#62942): https://lists.yoctoproject.org/g/yocto/message/62942
Mute This Topic: https://lists.yoctoproject.org/mt/105558513/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Implicit RPROVIDES somewhere ?

[Quentin Schulz via lists.yoctoproject.org]

Hi Joel,

On 4/18/24 10:50, Joel GUITTET via Lists.Yoctoproject.Org wrote:

Hello Quentin,

Yes not uncommon setup except my prebuilt libraries don't match the initial 
expectations:
1. The filename must have the version appended, for example: libbar.so.1.2.3. 
(can be easily renamed by the way)
2. The library must have the ELF tag SONAME set to the major version of the 
library, for example: libbar.so.1. (it has no SONAME at all and it's not 
possible to have it, and not wanted to patch the library before using it to 
build libfoo).



libbar not being versioned is common too, so that should be covered by 
the docs? libfoo though, as being built by Yocto should really be 
versioned itself. It doesn't need to use versioned libs as dependencies 
(though it would really be a good idea ;) ).



My customer don't want me to add the bar libraries in the rootfs. he ask me to 
add only the foo libraries, for both architectures aarch64 and arm. Yes I have 
bar libraries pre-compiled for both aarch64 and arm too. So this is lib32-bar 
and bar.



Your customer is requesting an image that cannot work? I'm not sure to 
understand his logic? What are they trying to prevent to happen? If they 
want to go this route, maybe using dlopen instead of linking against 
would be better maybe? This way the auto RDEPENDS mechanism wouldn't 
find it?


I assume he wants to share the bar library himself and not through your 
image... An option is just to ask him to build the image himself instead 
by providing all the layers and setup to him, and he'll have the ability 
to build an image with whatever he wants in it, but an image that 
actually works.




I assume that the automagic RDEPENDS got broken for lib32-foo and you are
not seeing it because of INSANE_SKIP:${PN} += "file-rdeps"
It's probably trying to locate a multilib lib32 package containing
libbar.so but cannot find any and complains about it. The aarch64 package
does find a package for libbar.so so it adds it automatically.



Interesting remark. Maybe I have to play with the INSANE_SKIP(s). > So the "file-rdeps" skip breaks the RDEPENDS on lib32-foo, which 
permit me to not integrate lib32-bar in the rootfs (what I want), but 
it's maybe not working with aarch64 ? Is there a "aarch64-file-rdeps" or 
similar (I don't think so) that could help to break the RDEPENDS of my 
library foo on the library bar ?




You won't be able to further break the build system by using 
INSANE_SKIP. INSANE_SKIP is for silencing warnings/errors. It's usually 
when one messes things up but says "trust me I know what I'm doing" to 
Yocto.


So here, your build is broken for lib32-foo but you silenced it. To 
achieve what you want, you need to break it for foo, and then silence it 
as well.


Digging a bit, maybe EXCLUDE_FROM_SHLIBS could be used in foo recipe to 
exclude bar package. I guess you could also look into making the bar 
recipe use PRIVATE_LIBS for libbar.so.


But honestly, this is just going against what Yocto should be used for, 
so try to find some compromise with your customer to do things properly :)


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#62960): https://lists.yoctoproject.org/g/yocto/message/62960
Mute This Topic: https://lists.yoctoproject.org/mt/105558513/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Wic Image Generation

[Quentin Schulz via lists.yoctoproject.org]

Hi Brati,

On 4/16/24 10:36, Bratiranjan Acharya via lists.yoctoproject.org wrote:

You don't often get email from bratiranjan12=gmail@lists.yoctoproject.org. Learn 
why this is important


-- Forwarded message -
From: Bratiranjan Acharya 
mailto:bratiranja...@gmail.com>>
Date: Thu, 11 Apr 2024 at 11:12
Subject: Wic Image Generation
To: mailto:yocto@lists.yoctoproject.org>>


Hi,
I want to create a Wic image from total scratch. Like, i have a "gpt.bin" which creates 
the partition and put the required images in it. But, i want to reate a wic image which will do the 
same. So, for that do i need that "gpt.bin"? like, as per my knowledge wic cannot create 
the gpt partition please do correct me if am wrong. And i dont even have any .bbclass file which 
can help to create the wic image so please help me to generate this wic image from total scratch, 
what are the steps i need to follow, where i need to put the wks file and how i can write in the 
wks file.

FOR Eg: I need to have 6 partitions where i have a active and backup 
bootloader,kernel,rootfs so for that how we can write the wks file.



Have a look at what is done in meta-rockchip:
https://git.yoctoproject.org/meta-rockchip/tree/wic/rockchip.wks

This creates a wic image with 9 partitions and a GPT partition table.

Maybe https://docs.yoctoproject.org/dev-manual/wic.html could be useful 
as well. I'm not entirely sure we provide enough documentation for the 
wks file in the docs, so probably something we can improve, patches 
welcome :)


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#62976): https://lists.yoctoproject.org/g/yocto/message/62976
Mute This Topic: https://lists.yoctoproject.org/mt/105458322/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Wic Image Generation

[Quentin Schulz via lists.yoctoproject.org]

Hi Brati,

Please always use the "Answer all" button so that the mailing list is 
still in copy.


On 4/22/24 11:47, Bratiranjan Acharya wrote:

Hi,

I've reviewed the information you shared. Can you clarify one thing for me?
In the last line, "bootloader --ptable gpt," what does it entail? Here's
the scenario: I have a gpt.bin file that creates all the necessary
partitions, but I'm aiming to generate a wic image instead. What steps
should I take? Do I still require the gpt.bin file, or is there an
alternative approach?



bootloader --ptable gpt

will generate the GPT table based on the partitions defined in the same 
file.


wic is capable of generating the GPT table for you.

I believe wic source code is in 
https://git.openembedded.org/openembedded-core/tree/scripts/lib/wic.


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#62977): https://lists.yoctoproject.org/g/yocto/message/62977
Mute This Topic: https://lists.yoctoproject.org/mt/105458322/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Command line Variable

[Quentin Schulz via lists.yoctoproject.org]

Hi Brati,


On 5/7/24 7:17 AM, Bratiranjan Acharya via lists.yoctoproject.org wrote:

Hello there! I've recently experimented with incorporating the following
lines into my recipe file:
BB_ENV_PASSTHROUGH_ADDITIONS = "BUILD_ID"
BUILD_ID ?= "none"
However, despite these additions, I encountered a persistent issue. Even
after executing the command "BUILD_ID=123456 bitbake custom-img" the value
of BUILD_ID consistently defaults to "none." I'm curious if there's an
alternative approach worth exploring. Any insights would be greatly
appreciated!



https://docs.yoctoproject.org/bitbake/2.8/bitbake-user-manual/bitbake-user-manual-ref-variables.html#term-BB_ENV_PASSTHROUGH_ADDITIONS

"""
You must set this variable in the external environment in order for it 
to work.

"""

So it needs to be outside any file from Bitbake, just have it in the 
shell environment before calling Bitbake.


Also, this variable was name something different before Kirkstone so it 
depends on which version of Yocto you're using here, c.f. 
https://docs.yoctoproject.org/migration-guides/migration-4.0.html?highlight=bb_env_passthrough_additions#inclusive-language-improvements


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#63042): https://lists.yoctoproject.org/g/yocto/message/63042
Mute This Topic: https://lists.yoctoproject.org/mt/105954779/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Strange errors while executing poky/meta/recipes-devtools/gcc/gcc-cross_13.2.bb using scarthgap release

[Quentin Schulz via lists.yoctoproject.org]

Hi Zoran,

On 5/16/24 2:28 PM, Zoran via lists.yoctoproject.org wrote:

[You don't often get email from 
zoran.stojsavljevic=gmail@lists.yoctoproject.org. Learn why this is 
important at https://aka.ms/LearnAboutSenderIdentification ]

Hello all,

I have a really strange error while compiling gcc-cross_13.2 ?!

Here is the error appearing:
ERROR: Task 
(/home/vuser/projects2/yocto/yocto_test2/bbb-yocto/poky/meta/recipes-devtools/gcc/gcc-cross_13.2.bb:do_gcc_stash_builddir)


Please provide the full log of the error.


failed with exit code '1'

I eliminate this error using the following addition, just to see if
the compiling will go further:

I edited poky/meta/recipes-devtools/gcc/gcc-cross.inc and added the
following line:

--- a/meta/recipes-devtools/gcc/gcc-cross.inc
+++ b/meta/recipes-devtools/gcc/gcc-cross.inc
@@ -131,6 +131,7 @@ do_packagedata[noexec] = "1"
  do_package_write_ipk[noexec] = "1"
  do_package_write_rpm[noexec] = "1"
  do_package_write_deb[noexec] = "1"
+do_gcc_stash_builddir[noexec] = "1" <<<===

It does pass further, till the next error:
ERROR: Task 
(/home/vuser/projects2/yocto/yocto_test2/bbb-yocto/poky/meta/recipes-devtools/gcc/gcc-cross_13.2.bb:do_populate_sysroot)
failed with exit code '1'

I did not take the same path, since I could not ignore the
do_populate_sysroot() task.

Does anybody have any info on such an occurrence in scarthgap release (5.0.1)?



5.0.1 doesn't exist, there's only a 5.0 tag right now, from which commit 
of the master/scarthgap branch are you running exactly?


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#63116): https://lists.yoctoproject.org/g/yocto/message/63116
Mute This Topic: https://lists.yoctoproject.org/mt/106133618/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Strange errors while executing poky/meta/recipes-devtools/gcc/gcc-cross_13.2.bb using scarthgap release

[Quentin Schulz via lists.yoctoproject.org]

Hi Zoran,

On 5/17/24 1:28 PM, Zoran Stojsavljevic wrote:

Remember how Fedora 40 is unsupported?  If you want to use
Fedora 40 then you’ll need to join in with the effort to support GCC 14.1, 
which involves fixing problems like this.

If you don’t want to do that, then use a supported host distribution.


I have to give you credit for this one. I will try to apply an
external patch for gcc 14 as per Martin's advice, and see what I can
do furthermore.

I have been with Fedora since 2012 (Fedora 14), and I have not once,
not twice, but quite a few times serious issues with Fedora.

Fedora is a test distro for RHELs. I did not understand this till
recently. And also for kernel.org .

Well. Learning in the meantime also ArchLinux (alternative to it is an
Ubuntu, I also used it for a couple (maybe 4) of years in parallel
with Fedora ).


I've been daily running Fedora but I'm always updating as soon there is 
a new one available... which means I never get official support for 
building the current Yocto release. I only use kas containers to build 
which is in a way pretty useful because then most colleagues would build 
through this container as well, abstract their local distro and 
everybody benefits from a more reusable/reused sstate-cache. There are 
also CROPS container IIRC but kas works for me and we use it for layer 
setup, so two features in the same tool is a nice to have.


But by all means, if you can and want to help supporting newer releases 
of Fedora/, send patches so others benefit from it :)


Good luck and looking forward to seeing patches :)

Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#63135): https://lists.yoctoproject.org/g/yocto/message/63135
Mute This Topic: https://lists.yoctoproject.org/mt/106133618/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Workaround for uid_map error on Ubuntu 24.04

[Quentin Schulz via lists.yoctoproject.org]

Hi Étienne,

On 5/19/24 10:34 PM, Etienne Cordonnier via lists.yoctoproject.org wrote:

You don't often get email from ecordonnier=snap@lists.yoctoproject.org. Learn why 
this is important
Hi all,
in order to build poky on Ubuntu 24.04, I have needed this workaround to fix the error 
"Errno 1 Operation not permitted" when disable_network (from 
bitbake/lib/bb/utils.py) attempts to write to the file /proc/self/uid_map:

$ sudo apparmor_parser -R /etc/apparmor.d/unprivileged_userns

For details, see https://bugs.launchpad.net/ubuntu/+source/dash/+bug/2056555



Thanks for bringing this up. I think we should have this documented in 
yocto-docs? So adding the mailing list in Cc


@Michael do you have some idea on how and where to integrate this? (Or 
maybe you have some suggestion/patch ready Étienne?).


Thanks,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#63146): https://lists.yoctoproject.org/g/yocto/message/63146
Mute This Topic: https://lists.yoctoproject.org/mt/106192359/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [Basic]: bitbake menuconfig not reflected changes from custom defconfig

[Quentin Schulz via lists.yoctoproject.org]

Hi Ashish,

On 5/22/24 6:31 PM, emailaddress.ashish via lists.yoctoproject.org wrote:

You don't often get email from emailaddress.ashish=gmail@lists.yoctoproject.org. 
Learn why this is important
Hi All ,

I am trying basic kernel config change using qemuarm64.
I have modified the config using bitbake -c menuconfig virtual/kernel & and 
copied it to my custom layer

After doing an cleansstate when i launch bitbake menuconfig i dont see my 
changes.
COMMAND: bitbake -c cleansstate virtual/kernel
COMMAND: bitbake -c menuconfig virtual/kernel

Below is my debug info:

vmmachine@testuser:~/yocto-nanbield/meta-test/recipes-kernel$ tree
bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
.
└── linux
 ├── linux-yocto
 │   └── testdefconfig


Should be named defconfig.


 └── linux-yocto_%.bbappend


vmmachine@testuser:~/yocto-nanbield/meta-test/recipes-kernel$ cat 
linux/linux-yocto_%.bbappend
FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"
SRC_URI += "file://testdefconfig"



Should be file://defconfig

Try with those changes and report afterwards if it still does not work :)

Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#63168): https://lists.yoctoproject.org/g/yocto/message/63168
Mute This Topic: https://lists.yoctoproject.org/mt/106246210/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [docs] [yocto] Workaround for uid_map error on Ubuntu 24.04

[Quentin Schulz via lists.yoctoproject.org]

Hi Michael,

On 5/23/24 10:45 AM, Michael Opdenacker wrote:


On 5/21/24 at 16:31, Etienne Cordonnier via lists.yoctoproject.org wrote:
The way I see to patch this at the moment is to print instructions for 
the users to run this command manually when this specific error 
happens (we can't run it automatically as part of bitbake since it 
needs sudo, and also it decreases the security on the machine 
so end-users should be aware of it). I can send a patch if you want, 
but this isn't really a clean solution.


Ubuntu 24.04 is not yet supported by yocto officially, and I hope the 
Ubuntu bug will be fixed before yocto officially supports 24.04. What 
people could do to help at this point is add themselves to the Ubuntu 
launchpad bug as "affected user". This would raise the "Bug heat" 
score and hopefully will increase the bug priority as well.



Right, I don't know how to document a workaround for a version that we 
don´t support yet.


True, I was being overly optimistic :) I assume we'll support 24.04 at 
some point. The issue I foresee is that some people have a tendency of 
not upgrading their systems, so... even if Canonical fixes their own 
stuff in upgrades, we may still need to document it?


What about a wiki page for work-arounds on not-supported-yet versions? 
That's something we could refer to in the documentation.




I'd be very happy if we don't mention the wiki page, nobody maintains 
that sadly (or let's say, not as much as yocto-docs :) ), and we 
had/have heavily outdated information there. For the time being, we 
could have it in the wiki yes, hopefully web search engine would return 
it when looking up for the error message/keywords, but I would try not 
to add a link to the docs. Once we support 24.04, then we could document 
it somehow in a note/warning/info pane?


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#63183): https://lists.yoctoproject.org/g/yocto/message/63183
Mute This Topic: https://lists.yoctoproject.org/mt/106259056/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Raspberry CM4 does not load audremap overlay

[Quentin Schulz via lists.yoctoproject.org]

Hi Federico,

On 5/23/24 5:03 PM, Federico via lists.yoctoproject.org wrote:

You don't often get email from farias=automac@lists.yoctoproject.org. Learn why 
this is important
   Hello, I'm new to the Yocto and Raspberry community, so let me know if I'm 
doing something wrong please.
I am trying to compile with Yocto Kirkstone (also tried newer branches), for a 
Raspberry Pi CM4 (emmc) + Official IO Board. I chose the Raspberrypi4 machine 
config, is this the correct one for the CM4 32bits?

I just build the core-image-base with the alsa package. I enabled in local.conf 
dtparam=audio=on and also dtoverlay=audremap to route the audio to pins 12 and 
13 (pwm).
This works fine with the official raspberry distro (only Bullseye onwards) but 
it doesn't work here. With the aplay -L command only the HDMI audio appears, 
not the headphones.

The SO image works fine, it boots and outputs audio via HDMI.
I also tried enabling pwm audio with other commands in local.conf like:
audio_pwm_mode2
dtoverlay=audremap, pins_12_13
dtoverlay=pwm1
and the same above with pins 40 & 41



I assume when you say local.conf you mean the one in the build 
directory? build/conf/local.conf? If so, this is used by BitBake and 
interpreted as BitBake code, so this is just creating a new variable 
called dtoverlay and setting it to pwm1. If something makes use of that 
variable... who knows! So, this isn't the place to put this code.


I think, what you want is what's described here: 
https://meta-raspberrypi.readthedocs.io/en/latest/extra-build-config.html#manual-additions-to-config-txt


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#63187): https://lists.yoctoproject.org/g/yocto/message/63187
Mute This Topic: https://lists.yoctoproject.org/mt/106264000/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] query on building rabbitmq-c

[Quentin Schulz via lists.yoctoproject.org]

Hi Simon,

On 5/30/24 7:21 PM, SIMON BABY via lists.yoctoproject.org wrote:

Hello Alexander,

Thank you for helping this out.

I can see packages-split with below files:

sbaby@eadlng-build-machine:~/workspace/05162024_NIC/741819_NICOPS/build/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/rabbitmq-c/0.11.0-r0/packages-split/rabbitmq-c-tools$
ls -ll usr/bin/
total 104
-rwxr-xr-x 2 sbaby sbaby 22284 Mar 31  2021 amqp-consume
-rwxr-xr-x 2 sbaby sbaby 18184 Mar 31  2021 amqp-declare-queue
-rwxr-xr-x 2 sbaby sbaby 18184 Mar 31  2021 amqp-delete-queue
-rwxr-xr-x 2 sbaby sbaby 18176 Mar 31  2021 amqp-get
-rwxr-xr-x 2 sbaby sbaby 18184 Mar 31  2021 amqp-publish

sbaby@eadlng-build-machine:~/workspace/05162024_NIC/741819_NICOPS/build/tmp/work/cortexa7hf-neon-vfpv4-poky-linux-gnueabi/rabbitmq-c/0.11.0-r0/packages-split$
ls -ll rabbitmq-c/usr/lib/
total 80
lrwxrwxrwx 1 sbaby sbaby20 Mar 31  2021 librabbitmq.so.4 ->
librabbitmq.so.4.5.0
-rwxr-xr-x 2 sbaby sbaby 79204 Mar 31  2021 librabbitmq.so.4.5.0



However, On the target I could not see the amqp-* binaries under /usr/bin.
But I see the library librabbitmq.so.4.5.0. Is this expected? Do we need
only the library to execute some client code with rabbitmq-c  api ?

root@sama7g5ek-sd:~# ls -ll /usr/lib/librabbitmq.so.4.5.0
-rwxr-xr-x 1 root root 79204 Mar  9  2018 /usr/lib/librabbitmq.so.4.5.0

root@sama7g5ek-sd:~# ls -ll /usr/bin/amqp-consume
ls: cannot access '/usr/bin/amqp-consume': No such file or directory
root@sama7g5ek-sd:~#
root@sama7g5ek-sd:~#
root@sama7g5ek-sd:~#
root@sama7g5ek-sd:~#
root@sama7g5ek-sd:~# ls -ll /usr/bin/amqp-*
ls: cannot access '/usr/bin/amqp-*': No such file or directory



The rabbitmq-c recipe generates multiple packages. One of those is 
rabbitmq-c (named identically to the recipe) and another, 
rabbitmq-c-tools. If you want the binaries, you need to install 
rabbitmq-c-tools in your image as well (via e.g. IMAGE_INSTALL variable).


One can know which package to install by using

oe-pkgdata-util find-path '/usr/bin/amqp-*'

this will list the package(s) that contains files matching the regular 
expression.


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#63246): https://lists.yoctoproject.org/g/yocto/message/63246
Mute This Topic: https://lists.yoctoproject.org/mt/106378618/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] meta-rockchip: rk3568 GPU support

[Quentin Schulz via lists.yoctoproject.org]

Hi Marek,

On 6/27/24 11:49 AM, Marek Belisko via lists.yoctoproject.org wrote:

You don't often get email from marek.belisko=gmail@lists.yoctoproject.org. Learn 
why this is important
Hi,

I'm just checking how to enable GPU acceleration for e.g. gstreamer for cm3-io 
board using rk3568 CPU. I saw that mesa have some options but not for rk356x 
CPU's:
PACKAGECONFIG:append:rk3288 = " kmsro panfrost"
PACKAGECONFIG:append:rk3399 = " kmsro panfrost"
PACKAGECONFIG:append:rock64 = " kmsro lima"
PACKAGECONFIG:append:px30 = " kmsro panfrost"


I've added a cm3-io machine and will post a patch soon (snippet below)
require conf/machine/include/rk3568.inc

KERNEL_DEVICETREE = "rockchip/rk3566-radxa-cm3-io.dtb"
MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"

UBOOT_MACHINE = "radxa-cm3-io-rk3566_defconfig"

Any ideas please?



We have it enabled on the master branch already, c.f. 
https://git.yoctoproject.org/meta-rockchip/commit/?id=9b20f029184798b4193945bbf286505e88b97da6


You can send patches to backport it to other branches if you want?

Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#63397): https://lists.yoctoproject.org/g/yocto/message/63397
Mute This Topic: https://lists.yoctoproject.org/mt/106905857/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] meta-rockchip: rk3568 GPU support

[Quentin Schulz via lists.yoctoproject.org]

Hi Marek,

On 6/27/24 2:07 PM, Belisko Marek wrote:

Hi Quentin,
On Thu, Jun 27, 2024 at 1:49 PM Quentin Schulz 
wrote:


Hi Marek,

On 6/27/24 11:49 AM, Marek Belisko via lists.yoctoproject.org wrote:

You don't often get email from marek.belisko=

gmail@lists.yoctoproject.org. Learn why this is important<
https://aka.ms/LearnAboutSenderIdentification>

Hi,

I'm just checking how to enable GPU acceleration for e.g. gstreamer for

cm3-io board using rk3568 CPU. I saw that mesa have some options but not
for rk356x CPU's:

PACKAGECONFIG:append:rk3288 = " kmsro panfrost"
PACKAGECONFIG:append:rk3399 = " kmsro panfrost"
PACKAGECONFIG:append:rock64 = " kmsro lima"
PACKAGECONFIG:append:px30 = " kmsro panfrost"


I've added a cm3-io machine and will post a patch soon (snippet below)
require conf/machine/include/rk3568.inc

KERNEL_DEVICETREE = "rockchip/rk3566-radxa-cm3-io.dtb"
MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"

UBOOT_MACHINE = "radxa-cm3-io-rk3566_defconfig"

Any ideas please?



We have it enabled on the master branch already, c.f.

https://git.yoctoproject.org/meta-rockchip/commit/?id=9b20f029184798b4193945bbf286505e88b97da6

You can send patches to backport it to other branches if you want?


Thanks I'll probably backport it to scharthgap. I think I mixed things up.
panfrost is used for GPU acceleration. I need vpu acceleration (gstreamer


Correct, Panfrost = GPU.


decode h264) so I've enabled hantro driver
but gstreamer is still taking a lot of cpu. Maybe gstreamer support is not
yet added? According this:
https://wiki.pine64.org/wiki/Mainline_Hardware_Decoding it should work so
I'm puzzled.



I would suggest to ask LibreElec folks for help on that topic, I know 
they have at least one person working on RK356x and RK3588 boards so 
they should be able to help with this. #linux-rockchip on libera.chat 
has a few people that could probably help with that.


FWIW, with Rockchip 5.10 kernel on RK3588, I still had a lot more CPU 
usage for video decoding than I expected for VDPU, so maybe define 
"taking a lot of cpu" whenever asking there, it's a bit too vague and 
subjective :)


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#63399): https://lists.yoctoproject.org/g/yocto/message/63399
Mute This Topic: https://lists.yoctoproject.org/mt/106905857/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [Yocto][QA] patches : QA Issue: Missing Upstream-Status in patch

[Quentin Schulz via lists.yoctoproject.org]

Hi Yann,

On 7/11/24 3:50 PM, Yann CARDAILLAC via lists.yoctoproject.org wrote:

You don't often get email from ycnakajsph=gmail@lists.yoctoproject.org. Learn why 
this is important
Well, I'm not really sure I would need it in most cases.

For instance today I was modifying an existing device tree to make it fit my 
board, that's not necessarily going to last.



I assume it'll make it to your upstream repo which contains this device 
tree, so there'll be no patch in Yocto after your debugging session ends.



Or say I have a package, which is from my company and doesn't have any reason 
to get out of it.



If it's from your company, you own the repo where the source code is 
stored, so fix the source code in the repo once you're done with the 
debugging session.



As an integrator I need to modify the build system, let's say something in the 
makefile, or maybe there's simply stuff that I don't want on my system.



If it is source code from your company, then fix it in the repo. If it's 
from a third party that isn't public, send them the patch so you 
eventually don't have to maintain this on your own, if it's public and 
open-source code, contribute back so you don't have to maintain this 
patch once you upgrade to a new version of the package (as part of a 
full Yocto upgrade or not).



So I'll make a patch.

Why would Yocto be authority for the way my commits are formatted? In all the 
above cases I don't see why.



You can disable the warning, we're just strongly recommending you to 
follow the format we came up with. Why? Because we've had years/decades 
of experience with handling patches we only had in layers. We went 
through the pain (and still go) of finding out if the patch is 
necessary, if it was sent upstream, if so, should we rework it based on 
newer versions of that patch, was it merged upstream, if so in which 
form and when, was it rejected, if so, why, security issue, broken 
logic, etc...
Where and how was the patch submitted etc. It also encourages us to 
contribute upstream, which means they then know the build system(s) 
compiling the source code and their usecases so they have it in mind for 
future development.


Yocto/OE needs to be opinionated (it factually cannot, because not 
implementing something like this if it's suggested means we have the 
opinion it's not necessary), but for most parts, it's still very very 
flexible, so feel free to disable the check we put in place to prevent 
people shooting their own foot :)


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#63477): https://lists.yoctoproject.org/g/yocto/message/63477
Mute This Topic: https://lists.yoctoproject.org/mt/107142644/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Pokysdk-linux libc cannot find a version of GLIBC

[Quentin Schulz via lists.yoctoproject.org]

Hi Hannes,

On 7/14/24 6:06 PM, diersen-hannes via lists.yoctoproject.org wrote:

You don't often get email from diersen-hannes=web...@lists.yoctoproject.org. Learn 
why this is important

Hello,

I am using ZephyrSDK to develop some embedded software. I have tried to install it on my 
"new" laptop, which is now running Fedora 40. From my understanding, Zephyr 
uses PokySDK to create the build environment for cross-compilation. However, I cannot get 
it working.

As I mentioned in this issue on the Zephyr project page 
(https://github.com/zephyrproject-rtos/sdk-ng/issues/741), I encounter an error 
when trying to build. The error message is as follows:


/home/hannes/zephyr-sdk-0.16.8/sysroots/x86_64-pokysdk-linux/usr/bin/dtc: 
/home/hannes/zephyr-sdk-0.16.8/sysroots/x86_64-pokysdk-linux/lib/libc.so.6: 
version `GLIBC_2.38' not found (required by /lib64/libstdc++.so.6) 
/home/hannes/zephyr-sdk-0.16.8/sysroots/x86_64-pokysdk-linux/usr/bin/dtc: 
/home/hannes/zephyr-sdk-0.16.8/sysroots/x86_64-pokysdk-linux/lib/libc.so.6: 
version `GLIBC_2.33' not found (required by /lib64/libstdc++.so.6) 
/home/hannes/zephyr-sdk-0.16.8/sysroots/x86_64-pokysdk-linux/usr/bin/dtc: 
/home/hannes/zephyr-sdk-0.16.8/sysroots/x86_64-pokysdk-linux/lib/libc.so.6: 
version `GLIBC_2.32' not found (required by /lib64/libstdc++.so.6) 
/home/hannes/zephyr-sdk-0.16.8/sysroots/x86_64-pokysdk-linux/usr/bin/dtc: 
/home/hannes/zephyr-sdk-0.16.8/sysroots/x86_64-pokysdk-linux/lib/libc.so.6: 
version `GLIBC_2.36' not found (required by /lib64/libstdc++.so.6) 
/home/hannes/zephyr-sdk-0.16.8/sysroots/x86_64-pokysdk-linux/usr/bin/dtc: 
/home/hannes/zephyr-sdk-0.16.8/sysroots/x86_64-pokysdk-linux/lib/libc.so.6: 
version `GLIBC_2.34' not found (required by /lib64/libstdc++.so.6)

Unfortunately, my issue has received only a small number of replies. Running 
ldd --version shows that I have GLIBC 2.38 installed on my PC. I tried to 
create a symlink to my local GLIBC installation, but it didn’t help.

In any case, this shouldn’t be necessary since PokySDK should provide all the 
necessary libraries needed for cross-compiling, or am I misunderstanding 
something?

I hope this is the right place to ask, as I am unsure how to resolve this issue.



Zephyr SDK seems to be using a patched poky from 3.2.3.

1) It is **VERY** outdated (like hasn't seen an update in three years), 
c.f. https://wiki.yoctoproject.org/wiki/Releases
2) Fedora 40 isn't among the support distros, c.f. 
https://docs.yoctoproject.org/3.2.3/ref-manual/ref-system-requirements.html#supported-linux-distributions


Therefore:
3) Try to figure out if there isn't a newer version of the Zephyr SDK 
that uses something newer than this and hopefully without patched layers,
4) Do not use Fedora 40 for building it, you can use containers instead. 
CROPS comes to mind though I haven't used it or kas-container (no clue 
how to use it outside of a kas setup). I don't even know if we support 
Fedora 40 on the master branch yet (there was some issues related with 
GCC being too recent and breaking yet unpatched package recipes (which 
is common every time GCC has a major version bumped, someone just have 
to do the work of fixing or silencing warnings))).


Otherwise there may be something to do with disabling uninative also, 
but I also have no experience with it.


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#63492): https://lists.yoctoproject.org/g/yocto/message/63492
Mute This Topic: https://lists.yoctoproject.org/mt/107215980/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Add qtbase and qtwayland to core-image-minimal

[Quentin Schulz via lists.yoctoproject.org]

Hi,

On 7/22/24 8:40 AM, Poornesh G ( India - Bangalore ) via 
lists.yoctoproject.org wrote:

You don't often get email from poornesh.g=mindteck@lists.yoctoproject.org. Learn 
why this is important
Greetings !

I have built a yocto for RK3568 (scarthgap) with core-image-minmal. I have LCD in 
my custom carrier board , I have enabled wayland & weston by adding the below 
lines in local.conf.

# For weston
DISTRO_FEATURES:remove = "x11 "
DISTRO_FEATURES:append = " wayland pam"
IMAGE_INSTALL:append = " wayland weston weston-init weston-examples 
rockchip-libmali"

After this I could successfully see display . Now I need to add Qt into the 
source , can anyone suggest me to include QT without having any conflict with 
Wayland / Weston.  I am getting the below error in my case.


---
| QPA backends:
|   DirectFB ... no
|   EGLFS .. no
|   LinuxFB  no
|   VNC  yes
| Qt Sql:
|   SQL item models  yes
| Qt Widgets:
|   GTK+ ... no
|   Styles . Fusion Windows
| Qt PrintSupport:
|   CUPS ... no
| Qt Sql Drivers:
|   DB2 (IBM) .. no
|   InterBase .. no
|   MySql .. no
|   OCI (Oracle) ... no
|   ODBC ... no
|   PostgreSQL . no
|   SQLite2  no
|   SQLite . no
| Using system provided SQLite . no
|   TDS (Sybase) ... no
| Qt Testlib:
|   Tester for item models . yes
|
| Note: -hostbindir is not a subdirectory of -hostprefix.
| Note: -hostlibdir is not a subdirectory of -hostprefix.
| Note: -hostdatadir is not a subdirectory of -hostprefix.
|
| WARNING: No QPA platform plugin enabled! This will
| produce a Qt that cannot run GUI applications.
| See "Platform backends" in the output of --help.
|
| ERROR: Feature 'opengl-desktop' was enabled, but the pre-condition '(config.win32 && 
!config.winrt && !features.opengles2 && (config.msvc || libs.opengl))
|   || (!config.watchos && !config.win32 && !config.wasm 
&& libs.opengl)' failed.
|
| ERROR: The OpenGL functionality tests failed!


You're likely missing some opengl distro feature?

Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#63547): https://lists.yoctoproject.org/g/yocto/message/63547
Mute This Topic: https://lists.yoctoproject.org/mt/107480923/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] rockchip: chromium HW accelerated

[Quentin Schulz via lists.yoctoproject.org]

Hi Marek,

On 7/25/24 12:22 PM, Marek Belisko via lists.yoctoproject.org wrote:

You don't often get email from marek.belisko=gmail@lists.yoctoproject.org. Learn 
why this is important
Hi,

I would like to ask if anyone tried on scrathgap accelerated chromium for radxa 
cm3 using the mainline rockchip layer. I've enabled chromium it was compiled 
properly but getting below:

[1860:1860:0805/093227.660753:ERROR:filesystem_posix.cc(63)] mkdir : No such 
file or directory (2)
chrome_crashpad_handler: --database is required
Try 'chrome_crashpad_handler --help' for more information.
[1860:1876:0805/093228.292318:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse 
server address: Unknown address type (examples of valid types are "tcp" and on UNIX 
"unix")
[1860:1876:0805/093228.292474:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse 
server address: Unknown address type (examples of valid types are "tcp" and on UNIX 
"unix")
[1860:1876:0805/093228.292569:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse 
server address: Unknown address type (examples of valid types are "tcp" and on UNIX 
"unix")
[1860:1876:0805/093228.292849:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse 
server address: Unknown address type (examples of valid types are "tcp" and on UNIX 
"unix")
Fontconfig error: No writable cache directories
Fontconfig error: No writable cache directories
libEGL warning: MESA-LOADER: failed to open rockchip: 
/usr/lib/dri/rockchip_dri.so: cannot open shared object file: No such file or 
directory (search paths /usr/lib/dri, suffix _dri)

libEGL warning: MESA-LOADER: failed to open rockchip: 
/usr/lib/dri/rockchip_dri.so: cannot open shared object file: No such file or 
directory (search paths /usr/lib/dri, suffix _dri)

libEGL warning: MESA-LOADER: failed to open zink: /usr/lib/dri/zink_dri.so: 
cannot open shared object file: No such file or directory (search paths 
/usr/lib/dri, suffix _dri)

[1888:1888:0805/093228.660850:FATAL:gpu_init.cc(593)] Passthrough is not 
supported, GL is egl, ANGLE is
[  585.551873] audit: type=1701 audit(1501925548.664:112): auid=4294967295 uid=0 gid=0 
ses=4294967295 pid=1888 comm="chromium-bin" 
exe="/usr/lib/chromium/chromium-bin" sig=5 res=1
[1860:1876:0805/093228.748702:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse 
server address: Unknown address type (examples of valid types are "tcp" and on UNIX 
"unix")
[1860:1876:0805/093228.748903:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse 
server address: Unknown address type (examples of valid types are "tcp" and on UNIX 
"unix")
Fontconfig error: No writable cache directories
Fontconfig error: No writable cache directories
[1860:1876:0805/093229.134377:ERROR:bus.cc(407)] Failed to connect to the bus: Could not parse 
server address: Unknown address type (examples of valid types are "tcp" and on UNIX 
"unix")
[1860:1876:0805/093229.134507:ERROR:bus.cc(407)] Failed to connect to the bus: 
Could not parse server address

and it won't start. Could it be mesa related (assuming from above errors).



Yes it's very likely mesa related.

https://git.yoctoproject.org/meta-rockchip/tree/recipes-graphics/mesa/mesa_%25.bbappend?h=scarthgap 
is what you have in the scarthgap branch.


https://git.yoctoproject.org/meta-rockchip/tree/recipes-graphics/mesa/mesa_%25.bbappend?h=master 
is what you have in the master branch. One needs to backport the patches 
for rk3566 and rk3568 to scarthgap branch. Would you mind sending those 
patches (after testing of course :) )?


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#63571): https://lists.yoctoproject.org/g/yocto/message/63571
Mute This Topic: https://lists.yoctoproject.org/mt/107540138/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Missing patch status (upstream status)

[Quentin Schulz via lists.yoctoproject.org]

Hi David,

On 8/5/24 2:37 PM, David Daniel via lists.yoctoproject.org wrote:

Hi all

I realized that my project does not build anymore. Now a patch status
is required - but even when I put it in (the patch status), the error
does not go away:

ERROR: bootcommander-1.0-r0 do_patch: QA Issue: Missing Upstream-Status in patch
/mnt/data/yocto/bf133/meta-bf133/recipes-bsp/bootcommander/files/openblt-cmake-add-install.patch
Please add according to 
https://docs.yoctoproject.org/contributor-guide/recipe-style-guide.html#patch-upstream-status
 . [patch-status]
ERROR: bootcommander-1.0-r0 do_patch: Fatal QA errors were found, failing task.
ERROR: Logfile of failure stored in: 
/mnt/data/yocto/bf133/build/tmp/work/ppc64e5500-vrag-linux/bootcommander/1.0/temp/log.do_patch.1483178
ERROR: Task 
(/mnt/data/yocto/bf133/meta-bf133/recipes-bsp/bootcommander/bootcommander_1.0.bb:do_patch)
 failed with exit code '1'

What I did add was something like:

Fix the installation path for CMake based installs.

Upstream-Status: Pending



Seems about right, maybe you can send the full git log of that patch so 
we can check if there's some weird character somewhere or somehow the 
pattern matching is misbehaving?




Can anyone plase tell me what is going on there? What is the


For the whole discussion we had about a month ago: 
https://lore.kernel.org/yocto/CAC3TgAK9+yDoz=3emvD6GTB6PNNe7=o5w6hkGpWm0juwt_X=p...@mail.gmail.com/


If something isn't clear or you have something to add, feel free to 
answer there or here.



correct syntax / requirements - in the docs I really cannot see
anything at all that could lead me to the correct answer (gotten
from 
https://docs.yoctoproject.org/contributor-guide/recipe-style-guide.html#patch-upstream-status
).

Can I turn this off? I would really like to be able to apply patches
whenever I think this is necessary / appropriate and not have bitbake
rule me out on this.



Yes you can turn it off. See thread linked above on how to do it and why 
not to do it.


Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#63653): https://lists.yoctoproject.org/g/yocto/message/63653
Mute This Topic: https://lists.yoctoproject.org/mt/107730684/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Where to send patches for ptest?

[Quentin Schulz via lists.yoctoproject.org]

Hi Jose, Jörg,

On 8/19/24 6:19 PM, Jose Quaresma via lists.yoctoproject.org wrote:

Hi Jörg,

Jörg Sommer via lists.yoctoproject.org  escreveu (segunda, 19/08/2024 à(s)
16:48):


Hi,

where does the development of ptest happen? What's the right place to send
patches to?



The git repo was available at
https://git.yoctoproject.org/ptest-runner2/tree/README.md
 From the README the paches should be sent to the
yocto@lists.yoctoproject.org.



Actually, it should probably be yocto-patc...@losts.yoctoproject.org now?

c.f. https://lists.yoctoproject.org/g/yocto/message/62856
https://lists.yoctoproject.org/g/yocto/message/62858
https://lists.yoctoproject.org/g/yocto/message/62859

Maybe send a patch to update the README as well?

Thanks!
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#63727): https://lists.yoctoproject.org/g/yocto/message/63727
Mute This Topic: https://lists.yoctoproject.org/mt/107983379/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [yocto-autobuilder2] [PATCH] schedulers: Drop nanbield

[Quentin Schulz via lists.yoctoproject.org]

Hi Richard,

On 8/23/24 11:26 AM, Richard Purdie via lists.yoctoproject.org wrote:

The nanbield release is out of maintenance now, stop running metrics for it.



FYI, Dunfell too is EOL and still appears in there.

Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#63736): https://lists.yoctoproject.org/g/yocto/message/63736
Mute This Topic: https://lists.yoctoproject.org/mt/108053276/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Using python3-cantools in bb file PP Phil Phil  Reply  Reply all  Forward   To: yocto@lists.yoctoproject.org Fri 8/23/2024 8:41 AM Greetings, I'm trying to get use python3 with cantoo

[Quentin Schulz via lists.yoctoproject.org]

Hi Phil,

On 8/23/24 10:58 AM, Phil Phil via lists.yoctoproject.org wrote:

You don't often get email from heidegg=hotmail@lists.yoctoproject.org. Learn why 
this is important
Greetings,

I'm trying to get use python3 with cantools in a bitbake recipe.

Usually this is installed via pip.
python3 -m pip install cantools
I'm trying to use it in a bb recipe in the following way:


BB recipe:

inherit python3native
DEPENDS += "python3-pip python3-cantools"


python3-cantools-native if you want to run things during the build process.

Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#63737): https://lists.yoctoproject.org/g/yocto/message/63737
Mute This Topic: https://lists.yoctoproject.org/mt/108053426/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-