Re: [yocto] [meta-rockchip][PATCH 3/4] remove /boot partition from wic:bootimg-paritition
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.
> > > > +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
Re: [yocto] [meta-rockchip][PATCH v2 3/4] remove /boot partition
On Fri 2024-02-16 @ 11:06:03 AM, Quentin Schulz wrote:
> 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.
I appreciate pedantic, so don't hesitate to jump in. In fact up until this
point we have been playing fast and loose with the partition sizes, so I
already had proof that the sizing was not a hard dependency. And I never mind
in-depth explanations and experiences.
>
> [...]
>
> > 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?
Done. But tweaked a little. The reasons for having it before (as part of the
boot files is slightly different than the reason for keeping it for EXTLINUX,
but very similar.
>
> > +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.
Ah got it. I misunderstood your comments. I thought you had been asking
whether it was necessary at all and I was pointing out that without that
package being added to the rootfs it wouldn't work.
Not a problem, I've upgraded it from a recommendation to a dependency.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#62535): https://lists.yoctoproject.org/g/yocto/message/62535
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 v2 2/4] rockchip.wks: add all Rockchip partitions
On Fri 2024-02-16 @ 10:48:59 AM, Quentin Schulz wrote: > 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:
Re: [yocto] WHAT IS YOCTO PROJECT ACTUALLY MEAN?
Thanks for your reply. I have go through your recommend article, and I have a question. " Yocto is an open source collaboration project " and in my opinion " open source collaboration project" is a process of create and maintain open source software, so what open source software does Yocto maintain? -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#62533): https://lists.yoctoproject.org/g/yocto/message/62533 Mute This Topic: https://lists.yoctoproject.org/mt/104425785/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] WHAT IS YOCTO PROJECT ACTUALLY MEAN?
I think you could start with this page https://www.yoctoproject.org/development/technical-overview/ Alex On Sun 18. Feb 2024 at 11.56, wrote: > Hi everyone, > > I am new to Yocto and sorry for my poor english. I have a question is > that, what actually Yocto is?. I am so confuse about this term. Of courses > i have done some research and the definition on the internet is "*Yocto is an > open source collaboration project that helps developers create custom > Linux-based systems*", but what does that actually mean. Is Yocto is a > combine of some tool like Kbuild, mkimage to build Linux kernel and Uboot > for example. Please help me clear this mist > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#62532): https://lists.yoctoproject.org/g/yocto/message/62532 Mute This Topic: https://lists.yoctoproject.org/mt/104425785/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [yocto-autobuilder-helper] [PATCH] Add bitbake-extra-tests to cover taskexp ncurses UI.
Signed-off-by: Richard Purdie
---
config.json | 4
scripts/bitbake-extra-tests | 14 ++
2 files changed, 18 insertions(+)
create mode 100755 scripts/bitbake-extra-tests
diff --git a/config.json b/config.json
index 3032fd7..3a2ab49 100644
--- a/config.json
+++ b/config.json
@@ -276,6 +276,10 @@
"step4" : {
"shortname" : "OEQA core tests",
"EXTRACMDS" : ["oe-test core"]
+},
+"step5" : {
+"shortname" : "Bitbake extra tests",
+"EXTRACMDS" : ["${SCRIPTSDIR}/bitbake-extra-tests"]
}
},
"reproducible" : {
diff --git a/scripts/bitbake-extra-tests b/scripts/bitbake-extra-tests
new file mode 100755
index 000..39f248d
--- /dev/null
+++ b/scripts/bitbake-extra-tests
@@ -0,0 +1,14 @@
+#!/bin/bash
+TASK_EXP_UNIT_TEST=1 bitbake -g -u taskexp_ncurses zlib acl
+if [ $? -ne 0 ]; then
+exit 1
+fi
+TASK_EXP_UNIT_TEST=1 bitbake -g -u taskexp_ncurses zlib acl foo
+if [ $? -ne 1 ]; then
+exit 1
+fi
+TASK_EXP_UNIT_TEST_NOTERM=1 bitbake -g -u taskexp_ncurses quilt
+if [ $? -ne 0 ]; then
+exit 1
+fi
+
--
2.40.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#62531): https://lists.yoctoproject.org/g/yocto/message/62531
Mute This Topic: https://lists.yoctoproject.org/mt/104426629/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] WHAT IS YOCTO PROJECT ACTUALLY MEAN?
Hi everyone, I am new to Yocto and sorry for my poor english. I have a question is that, what actually Yocto is?. I am so confuse about this term. Of courses i have done some research and the definition on the internet is " *Yocto is an open source collaboration project that helps developers create custom Linux-based systems* ", but what does that actually mean. Is Yocto is a combine of some tool like Kbuild, mkimage to build Linux kernel and Uboot for example. Please help me clear this mist -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#62530): https://lists.yoctoproject.org/g/yocto/message/62530 Mute This Topic: https://lists.yoctoproject.org/mt/104425785/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][yocto-kernel-cache yocto-6.1][PATCH] nxp-imx8: Enable nxp-imx8 CAAM
Enable nxp-imx8 CAAM. Signed-off-by: Xiaolei Wang --- bsp/nxp-imx8/nxp-imx8.cfg | 6 ++ 1 file changed, 6 insertions(+) diff --git a/bsp/nxp-imx8/nxp-imx8.cfg b/bsp/nxp-imx8/nxp-imx8.cfg index e5548296..5de6ed4a 100644 --- a/bsp/nxp-imx8/nxp-imx8.cfg +++ b/bsp/nxp-imx8/nxp-imx8.cfg @@ -615,3 +615,9 @@ CONFIG_FSL_IMX9_DDR_PMU=y # CONFIG_TEE=y CONFIG_OPTEE=y + +# +# CAAM drivers +# +CONFIG_CRYPTO_DEV_FSL_CAAM=y +CONFIG_CRYPTO_DEV_FSL_CAAM_SECVIO=y -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13580): https://lists.yoctoproject.org/g/linux-yocto/message/13580 Mute This Topic: https://lists.yoctoproject.org/mt/104424866/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
