[linux-yocto][v6.1/standard/preempt-rt/nxp-sdk-6.1/nxp-soc & v6.1/standard/nxp-sdk-6.1/nxp-soc][PATCH 1/1] ARM: imx: use raw_spin_lock instead of spin_lock

2023-10-09 Thread Xiaolei Wang via lists.yoctoproject.org
Use raw_spin_lock instead of spin_lock,
this patch fixes the following warning:

Hardware name: Freescale i.MX7 Dual (Device Tree)
 unwind_backtrace from show_stack+0x18/0x1c
 show_stack from dump_stack_lvl+0x40/0x4c
 dump_stack_lvl from __might_resched+0x140/0x1b4
 __might_resched from rt_spin_lock+0x28/0x74
 rt_spin_lock from imx_gpcv2_set_lpm_mode+0x1c/0xbc
 imx_gpcv2_set_lpm_mode from imx7d_enter_low_power_idle+0x7c/0x30c
 imx7d_enter_low_power_idle from cpuidle_enter_state+0xe8/0x328
 cpuidle_enter_state from cpuidle_enter+0x3c/0x50
 cpuidle_enter from do_idle+0x218/0x268
 do_idle from cpu_startup_entry+0x20/0x24
 cpu_startup_entry from rest_init+0xbc/0xd8
 rest_init from arch_post_acpi_subsys_init+0x0/0x18

Signed-off-by: Xiaolei Wang 
---
 arch/arm/mach-imx/gpcv2.c | 30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-imx/gpcv2.c b/arch/arm/mach-imx/gpcv2.c
index 62e8b0089348..4e7034c79ad7 100644
--- a/arch/arm/mach-imx/gpcv2.c
+++ b/arch/arm/mach-imx/gpcv2.c
@@ -109,7 +109,7 @@ static u32 gpcv2_saved_imrs[IMR_NUM];
 static u32 gpcv2_saved_imrs_m4[IMR_NUM];
 static u32 gpcv2_mf_irqs[IMR_NUM];
 static u32 gpcv2_mf_request_on[IMR_NUM];
-static DEFINE_SPINLOCK(gpcv2_lock);
+static DEFINE_RAW_SPINLOCK(gpcv2_lock);
 
 void imx_gpcv2_add_m4_wake_up_irq(u32 hwirq, bool enable)
 {
@@ -122,10 +122,10 @@ void imx_gpcv2_add_m4_wake_up_irq(u32 hwirq, bool enable)
return;
 
mask = 1 << hwirq % 32;
-   spin_lock_irqsave(_lock, flags);
+   raw_spin_lock_irqsave(_lock, flags);
gpcv2_wake_irqs[idx] = enable ? gpcv2_wake_irqs[idx] | mask :
gpcv2_wake_irqs[idx] & ~mask;
-   spin_unlock_irqrestore(_lock, flags);
+   raw_spin_unlock_irqrestore(_lock, flags);
 }
 
 static int imx_gpcv2_irq_set_wake(struct irq_data *d, unsigned int on)
@@ -137,10 +137,10 @@ static int imx_gpcv2_irq_set_wake(struct irq_data *d, 
unsigned int on)
BUG_ON(idx >= IMR_NUM);
 
mask = 1 << d->hwirq % 32;
-   spin_lock_irqsave(_lock, flags);
+   raw_spin_lock_irqsave(_lock, flags);
gpcv2_wake_irqs[idx] = on ? gpcv2_wake_irqs[idx] | mask :
  gpcv2_wake_irqs[idx] & ~mask;
-   spin_unlock_irqrestore(_lock, flags);
+   raw_spin_unlock_irqrestore(_lock, flags);
 
return 0;
 }
@@ -226,7 +226,7 @@ void imx_gpcv2_set_lpm_mode(enum mxc_cpu_pwr_mode mode)
unsigned long flags;
u32 val1, val2;
 
-   spin_lock_irqsave(_lock, flags);
+   raw_spin_lock_irqsave(_lock, flags);
 
val1 = readl_relaxed(gpc_base + GPC_LPCR_A7_BSC);
val2 = readl_relaxed(gpc_base + GPC_SLPCR);
@@ -283,7 +283,7 @@ void imx_gpcv2_set_lpm_mode(enum mxc_cpu_pwr_mode mode)
writel_relaxed(val1, gpc_base + GPC_LPCR_A7_BSC);
writel_relaxed(val2, gpc_base + GPC_SLPCR);
 
-   spin_unlock_irqrestore(_lock, flags);
+   raw_spin_unlock_irqrestore(_lock, flags);
 }
 
 void imx_gpcv2_set_plat_power_gate_by_lpm(bool pdn)
@@ -329,7 +329,7 @@ void imx_gpcv2_set_cpu_power_gate_by_wfi(u32 cpu, bool pdn)
unsigned long flags;
u32 val;
 
-   spin_lock_irqsave(_lock, flags);
+   raw_spin_lock_irqsave(_lock, flags);
val = readl_relaxed(gpc_base + GPC_LPCR_A7_AD);
 
if (cpu == 0) {
@@ -355,7 +355,7 @@ void imx_gpcv2_set_cpu_power_gate_by_wfi(u32 cpu, bool pdn)
}
}
writel_relaxed(val, gpc_base + GPC_LPCR_A7_AD);
-   spin_unlock_irqrestore(_lock, flags);
+   raw_spin_unlock_irqrestore(_lock, flags);
 }
 
 void imx_gpcv2_set_cpu_power_gate_by_lpm(u32 cpu, bool pdn)
@@ -363,7 +363,7 @@ void imx_gpcv2_set_cpu_power_gate_by_lpm(u32 cpu, bool pdn)
unsigned long flags;
u32 val;
 
-   spin_lock_irqsave(_lock, flags);
+   raw_spin_lock_irqsave(_lock, flags);
 
val = readl_relaxed(gpc_base + GPC_LPCR_A7_AD);
if (cpu == 0) {
@@ -384,7 +384,7 @@ void imx_gpcv2_set_cpu_power_gate_by_lpm(u32 cpu, bool pdn)
}
 
writel_relaxed(val, gpc_base + GPC_LPCR_A7_AD);
-   spin_unlock_irqrestore(_lock, flags);
+   raw_spin_unlock_irqrestore(_lock, flags);
 }
 
 void imx_gpcv2_set_cpu_power_gate_in_idle(bool pdn)
@@ -395,7 +395,7 @@ void imx_gpcv2_set_cpu_power_gate_in_idle(bool pdn)
for_each_possible_cpu(cpu)
imx_gpcv2_set_cpu_power_gate_by_lpm(cpu, pdn);
 
-   spin_lock_irqsave(_lock, flags);
+   raw_spin_lock_irqsave(_lock, flags);
 
imx_gpcv2_set_m_core_pgc(pdn, GPC_PGC_C0);
if (num_online_cpus() > 1)
@@ -424,7 +424,7 @@ void imx_gpcv2_set_cpu_power_gate_in_idle(bool pdn)
gpc_base + GPC_PGC_ACK_SEL_A7);
imx_gpcv2_enable_rbc(false);
}
-   spin_unlock_irqrestore(_lock, flags);
+   raw_spin_unlock_irqrestore(_lock, flags);
 }
 
 void imx_gpcv2_set_mix_phy_gate_by_lpm(u32 pdn_index, u32 pup_index)
@@ -468,10 +468,10 @@ int 

Re: [linux-yocto][linux-yocto v6.1] fix patch for marvell cn96xx

2023-10-09 Thread Ruiqiang Hao via lists.yoctoproject.org

The condition being removed wasn't in exactly the same
place on the -rt brances, so I fixedup the patch when
applying it.

Both branches should be fixed.
I just realized that RT branch and Standard branch are different when 
processing merges,
this patch is not applicable on the RT branch.

I will send a pull-request later to fix this.

Thanks,
Ruiqiang


From: Bruce Ashfield 
Sent: Monday, October 9, 2023 20:02
To: Hao, Ruiqiang 
Cc: linux-yocto@lists.yoctoproject.org 
Subject: Re: [linux-yocto][linux-yocto v6.1] fix patch for marvell cn96xx

CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know 
the content is safe.

In message: [linux-yocto][linux-yocto v6.1] fix patch for marvell cn96xx
on 09/10/2023 Ruiqiang Hao wrote:

> Hi Bruce,
>
> Please help to merge this patch into our linux-yocto repo.
>
> repo:
>   linux-yocto
> branch:
>   v6.1/standard/cn-sdkv5.15/octeon
>   v6.1/standard/preempt-rt/cn-sdkv5.15/octeon

The condition being removed wasn't in exactly the same
place on the -rt brances, so I fixedup the patch when
applying it.

Both branches should be fixed.

Bruce

>
> Thanks,
> Ruiqiang

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



[yocto] M+ & H bugs with Milestone Movements WW40

2023-10-09 Thread Stephen Jolley
All,

YP M+ or high bugs which moved to a new milestone in WW40 are listed below:
Priority Bug ID Short Description Changer Owner Was Became
Medium+ 3362  Improve
dependency analysis tools randy.macl...@windriver.com
richard.pur...@linuxfoundation.org 0.0.0 5.99
4530  gconv data
needs virtual providers randy.macl...@windriver.com
bernhard.guil...@begu.org 0.0.0 5.0 M1
10820  devtool:
-d/--debug doesn't show bitbake debug output randy.macl...@windriver.com
pi...@pidge.org 4.3 M3 4.3 M4
11704  Add other
resource monitoring options to conf/local.conf STOPTASKS/ABORT
randy.macl...@windriver.com randy.macl...@windriver.com 4.3 M3 5.0 M2
13919  Multi
License GPLv3 -lic cannot be installed into the image because it has
incompatible license randy.macl...@windriver.com anilrat...@gmail.com 4.3 M3
5.99
14007  When qemu
hangs, try to create a snapshot or core file. randy.macl...@windriver.com
randy.macl...@windriver.com 4.3 M3 5.0 M1
14157  git
fetcher: consider using different git commands for repo packing,
eliminating "git pack-redundant" randy.macl...@windriver.com
newco...@yoctoproject.org 4.3 M3 5.99
14385  mode of
sstate files created under pseudo randy.macl...@windriver.com
pi...@pidge.org 4.3 M3 4.3 M4
14443  valgrind
none/tests/amd64/fb_test_amd64 ptest intermittent failure
randy.macl...@windriver.com randy.macl...@windriver.com 4.3 M3 5.0 M1
14693  cmake-native
do_configure fails when rebuilding without sstate on NIS hosts
randy.macl...@windriver.com randy.macl...@windriver.com 4.3 M3 5.0 M1
14710  Improve
cargo fetcher test cases randy.macl...@windriver.com
randy.macl...@windriver.com 4.3 M3 5.0 M2
14723  patches not
applied by devtool when using overrides in SRC_URI
randy.macl...@windriver.com pi...@pidge.org 4.3 M3 4.3 M4
14837  devtool
modify doesnt fetch all the crates on rust based recipes
randy.macl...@windriver.com pi...@pidge.org 4.3 M3 4.3 M4
15023  Cannot
build SDK with api-documentation enabled randy.macl...@windriver.com
pi...@pidge.org 4.3 M3 4.3 M4
15061  Rust
multilib sdks broken randy.macl...@windriver.com
deepthi.hem...@windriver.com 4.3 M3 4.3 M4
15071  AB-INT
PTEST: strace ptest intermittent failure in syscall-times-ms.gen
randy.macl...@windriver.com randy.macl...@windriver.com 4.3 M3 4.3 M4
15074  syncfs
probe fails with newer compilers randy.macl...@windriver.com
pi...@pidge.org 4.3
M3 4.3 M4
15145  module conf
files missing when KERNEL_SPLIT_MODULES=0 randy.macl...@windriver.com
george.tho...@gmail.com 4.3 M3 5.0 M1
15172  tzdata
recipe: build tzdata.zi zoneinfo file randy.macl...@windriver.com
randy.macl...@windriver.com 4.3 M3 5.0 M1

Thanks,



*Stephen K. Jolley*

*Yocto Project Program Manager*

(*Cell*:(208) 244-4460

* *Email*: *s
jolley.yp...@gmail.com *

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



[yocto] Enhancements/Bugs closed WW40!

2023-10-09 Thread Stephen Jolley
All,

The below were the owners of enhancements or bugs closed during the last
week!
Who Count
tim.orl...@konsulko.com 2
randy.macl...@windriver.com 2
ross.bur...@arm.com 1
Grand Total 5

Thanks,



*Stephen K. Jolley*

*Yocto Project Program Manager*

(*Cell*:(208) 244-4460

* *Email*: *s
jolley.yp...@gmail.com *

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



[yocto] Current high bug count owners for Yocto Project 4.3

2023-10-09 Thread Stephen Jolley
All,

Below is the list of top 25 bug owners as of the end of WW40 who have open
medium or higher bugs and enhancements against YP 4.3. There are 1 possible
workday left until the final release candidates for YP 4.3 needs to be
released.
Who Count
michael.opdenac...@bootlin.com 34
ross.bur...@arm.com 30
richard.pur...@linuxfoundation.org 24
david.re...@windriver.com 23
randy.macl...@windriver.com 16
bruce.ashfi...@gmail.com 13
jpewhac...@gmail.com 10
pi...@pidge.org 7
yash.shi...@windriver.com 5
alexandre.bell...@bootlin.com 3
tim.orl...@konsulko.com 2
sundeep.kokko...@windriver.com 2
pa...@zhukoff.net 2
jon.ma...@arm.com 2
alexis.loth...@bootlin.com 2
yoann.con...@smile.fr 1
tvgamb...@gmail.com 1
thr...@amazon.de 1
thomas.per...@bootlin.com 1
sakib.sa...@windriver.com 1
p.lob...@welotec.com 1
mark.asselst...@windriver.com 1
louis.ran...@syslinbit.com 1
jens.ge...@desy.de 1
fathi.bou...@linaro.org 1
Grand Total 185

Thanks,



*Stephen K. Jolley*

*Yocto Project Program Manager*

(*Cell*:(208) 244-4460

* *Email*: *s
jolley.yp...@gmail.com *

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



[yocto] Yocto Project Newcomer & Unassigned Bugs - Help Needed

2023-10-09 Thread Stephen Jolley
All,

The triage team is starting to try and collect up and classify bugs which a
newcomer to the project would be able to work on in a way which means
people can find them. They're being listed on the triage page under the
appropriate heading:
https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs Also please
review:
https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and
how to create a bugzilla account at:
https://bugzilla.yoctoproject.org/createaccount.cgi

The idea is these bugs should be straight forward for a person to help work
on who doesn't have deep experience with the project. If anyone can help,
please take ownership of the bug and send patches! If anyone needs
help/advice there are people on irc who can likely do so, or some of the
more experienced contributors will likely be happy to help too.

Also, the triage team meets weekly and does its best to handle the bugs
reported into the Bugzilla. The number of people attending that meeting has
fallen, as have the number of people available to help fix bugs. One of the
things we hear users report is they don't know how to help. We (the triage
team) are therefore going to start reporting out the currently 411
unassigned or newcomer bugs.

We're hoping people may be able to spare some time now and again to help
out with these. Bugs are split into two types, "true bugs" where things
don't work as they should and "enhancements" which are features we'd want
to add to the system. There are also roughly four different "priority"
classes right now, “4.3”, “4.4”, "4.99" and "Future", the more
pressing/urgent issues being in "4.3" and then “4.4”.

Please review this link and if a bug is something you would be able to help
with either take ownership of the bug, or send me (sjolley.yp...@gmail.com)
an e-mail with the bug number you would like and I will assign it to you
(please make sure you have a Bugzilla account). The list is at:
https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer_Bugs

Thanks,



*Stephen K. Jolley*

*Yocto Project Program Manager*

(*Cell*:(208) 244-4460

* *Email*: *s
jolley.yp...@gmail.com *

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



[yocto] Auto-mount causing "transport endpoint is not connected error"

2023-10-09 Thread Logan Grosz via lists.yoctoproject.org
Hi, all

I am attempting to set up removable drive auto-mounting. I am doing so with a 
tweaked version of meta/recipes-core/udev/udev-extraconf/mount.sh​.

My version is as follows

```
#!/bin/sh
#
# Called from udev
#
# Attempt to mount any added block devices and umount any removed devices
#
# This way ripped from mickledore poky with some modifications

MOUNT_BASE="/run/media/"
MOUNT="/bin/mount"
UMOUNT="/bin/umount"

for line in `grep -h -v ^# /etc/udev/mount.ignorelist 
/etc/udev/mount.ignorelist.d/*`
do
if [ ` expr match "$DEVNAME" "$line" ` -gt 0 ];
then
logger "udev/mount.sh" "[$DEVNAME] is marked to ignore"
exit 0
fi
done

automount() {
name="`basename "$DEVNAME"`"

$MOUNT $DEVNAME 2> /dev/null

# If the device isn't mounted at this point, it isn't
# configured in fstab
grep -q "^$DEVNAME " /proc/mounts && return

# Get the unique name for mount point
get_label_name "${DEVNAME}"

# Only go for auto-mounting when the device has been cleaned up in 
remove
# or has not been identified yet
if [ -e "/tmp/.automount-$basename" ]; then
logger "mount.sh/automount" "[$MOUNT_BASE/name$] is already 
cached"
return
fi

! test -d "$MOUNT_BASE/$name" && mkdir -p "$MOUNT_BASE/$name"
# Silent util-linux's version of mounting auto
if [ "x`readlink $MOUNT`" = "x/bin/mount.util-linux" ] ;
then
MOUNT="$MOUNT -o silent"
fi

# If filesystem type is vfat, change the ownership group to 'disk', and
# grant it with  w/r/x permissions.
case $ID_FS_TYPE in
vfat|fat)
MOUNT="$MOUNT -o umask=007,gid=`awk -F':' 
'/^disk/{print $3}' /etc/group`"
;;
swap)
return ;;
lvm*|LVM*)
return ;;
# TODO
*)
;;
esac

if ! $MOUNT -t auto $DEVNAME "$MOUNT_BASE/$name"
then
logger "mount.sh/automount" "$MOUNT -t auto $DEVNAME 
\"$MOUNT_BASE/$name\" failed!"
rm_dir "$MOUNT_BASE/$name"
else
logger "mount.sh/automount" "Auto-mount of [$MOUNT_BASE/$name] 
successful"
# The actual device might not be present in the remove event so 
blkid cannot
# be used to calculate what name was generated here. Simply 
save the mount
# name in our tmp file.
echo "$MOUNT_BASE/$name" > "/tmp/.automount-$basename"
fi
}

rm_dir() {
# We do not want to rm -r populated directories
if test "`find "$1" | wc -l | tr -d " "`" -lt 2 -a -d "$1"
then
! test -z "$1" && rm -r "$1"
else
logger "mount.sh/automount" "Not removing non-empty directory 
[$1]"
fi
}

get_label_name() {
# Get the LABEL or PARTLABEL
LABEL=`/sbin/blkid | grep "$1:" | grep -o 'LABEL=".*"' | cut -d '"' -f2`
# If the $DEVNAME has a LABEL or a PARTLABEL
if [ -n "$LABEL" ]; then
name="${LABEL}"
else
name="USB Drive"
fi

n=1;
prefix=$name
while [ -d $MOUNT_BASE/$name ]
do
name=$prefix-$n
((n++))
done
}

# No ID_FS_TYPE for cdrom device, yet it should be mounted
basename="`basename "$DEVNAME"`"
name=$basename
[ -e /sys/block/$basename/device/media ] && media_type=`cat 
/sys/block/$basename/device/media`

if [ "$ACTION" = "add" ] && [ -n "$DEVNAME" ] && [ -n "$ID_FS_TYPE" -o 
"$media_type" = "cdrom" ]; then
# Note the root filesystem can show up as /dev/root in /proc/mounts,
# so check the device number too
if expr $MAJOR "*" 256 + $MINOR != `stat -c %d /`; then
automount
fi
fi

if [ "$ACTION" = "remove" ] || [ "$ACTION" = "change" ] && [ -x "$UMOUNT" ] && 
[ -n "$DEVNAME" ]; then
tmpfile=`find /tmp | grep "\.automount-${basename}$"`
if [ ! -e "/sys/$DEVPATH" -a -e "$tmpfile" ]; then
logger "mount.sh/remove" "cleaning up $DEVNAME, was mounted by 
the auto-mounter"
for mnt in `cat /proc/mounts | grep "$DEVNAME" | cut -f 2 -d " 
" `
do
$UMOUNT $mnt
done

# Remove mount directory created by the auto-mounter
# and clean up our tmp cache file
rm_dir `cat $tmpfile`
rm "$tmpfile"
fi
fi
```

The udev rules are identical to that from poky. Unfortunately, every time I 
insert my USB drive I get a file created /run/media/LABEL​, upon when I run ls 
-la /run/media/LABEL​, I receive an error, ls: cannot access 
'/run/media/LABEL': Transport endpoint is not connected​.

I am on 

Re: [yocto] Password added succesfully but defaults to autologin

2023-10-09 Thread MOHAMMED HASSAN
Let me know if I am making any mistakes here. Also let me know if you need any 
other piece of information to help me on this issue.

Thanks,
Hassan

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



Re: [yocto] continuous security updates for the Linux system

2023-10-09 Thread MOHAMMED HASSAN
On Mon, Oct 9, 2023 at 07:11 AM, Michael Opdenacker wrote:

> 
> Hi Hassan
> 
> On 09.10.23 at 15:22, MOHAMMED HASSAN wrote:
> 
>> On Mon, Oct 9, 2023 at 06:12 AM, Josef Holzmayr wrote:
>> 
>> Please see https://wiki.yoctoproject.org/wiki/System_Update
>> 
>> Thanks for your reply. I am aware of the system_updates feature though
>> still yet to implement. Is it possible to update the yocto version (i
>> use dunfell) to the latest one, to update the linux version(mine is
>> 5.4.180) to the latest and to update the tools to the latest using
>> these features. Actually i have no clarity with this so I am asking.
> 
> 
> Which version of Yocto are you using? If you have one that is still
> supported (like Kirkstone or Dunfell), I'd recommend to stick to these
> and just rebuild with the latest release update. This way you have the
> latest vulnerability fixes supported by the Yocto Project. Once a new
> image is generated, you can deploy it using one of the tools Josef
> mentioned.
> 
> Moving to the latest version of Yocto will represent more work, all the
> more as the latest one should be replaced this month.
> 
> As far as the Linux kernel is concerned, I'd rather work with a stable
> LTS kernel ( https://kernel.org/category/releases.html ), as I guess the
> Yocto Project releases can't match the stable kernels in terms of
> vulnerability fixes and how quickly they are deployed. That's my own
> opinion though.
> 
> 

Hi Michael,
Thanks for your reply.
I am currently using dunfell 3.1.11 and my kernel release is Linux 
5.4.180-amlogic. Going by your suggestion i should rebuild to the latest 
dunfell update i.e 3.1.28. Moving to kirkstone would take more work.
I will search on how to update my yocto release version and get into it.

Thanks
Hassan

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



Re: [yocto] continuous security updates for the Linux system

2023-10-09 Thread Michael Opdenacker via lists.yoctoproject.org

Hi Hassan

On 09.10.23 at 15:22, MOHAMMED HASSAN wrote:

On Mon, Oct 9, 2023 at 06:12 AM, Josef Holzmayr wrote:

Please see https://wiki.yoctoproject.org/wiki/System_Update

Thanks for your reply. I am aware of the system_updates feature though 
still yet to implement. Is it possible to update the yocto version (i 
use dunfell) to the latest one, to update the linux version(mine is 
5.4.180) to the latest and to update the tools to the latest using 
these features. Actually i have no clarity with this so I am asking.



Which version of Yocto are you using? If you have one that is still 
supported (like Kirkstone or Dunfell), I'd recommend to stick to these 
and just rebuild with the latest release update. This way you have the 
latest vulnerability fixes supported by the Yocto Project. Once a new 
image is generated, you can deploy it using one of the tools Josef 
mentioned.


Moving to the latest version of Yocto will represent more work, all the 
more as the latest one should be replaced this month.


As far as the Linux kernel is concerned, I'd rather work with a stable 
LTS kernel (https://kernel.org/category/releases.html), as I guess the 
Yocto Project releases can't match the stable kernels in terms of 
vulnerability fixes and how quickly they are deployed. That's my own 
opinion though.


I hope this helps
Cheers
Michael.

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


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



Re: [yocto] continuous security updates for the Linux system

2023-10-09 Thread Adrian Freihofer
Hi

Would it be possible to extend the
https://wiki.yoctoproject.org/wiki/System_Update table with compatible
backends? Ideally the license of the backends should also be
transparent. OE/Yocto should not end up with a vendor lock in when it
comes to a standard update mechanism. In the end it's about a solution
with client and server, where a client alone is usually pretty
worthless.

Regards,
Adrian

On Mon, 2023-10-09 at 06:22 -0700, MOHAMMED HASSAN wrote:
> On Mon, Oct 9, 2023 at 06:12 AM, Josef Holzmayr wrote:
> > Please see https://wiki.yoctoproject.org/wiki/System_Update
> >  
> Thanks for your reply. I am aware of the system_updates feature
> though still yet to implement. Is it possible to update the yocto
> version (i use dunfell) to the latest one, to update the linux
> version(mine is 5.4.180) to the latest and to update the tools to the
> latest using these features. Actually i have no clarity with this so
> I am asking.
> 
> Thanks and regards,
> Hassan
> 
> 
> 


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



Re: [yocto] continuous security updates for the Linux system

2023-10-09 Thread MOHAMMED HASSAN
On Mon, Oct 9, 2023 at 06:12 AM, Josef Holzmayr wrote:

> 
> Please see https://wiki.yoctoproject.org/wiki/System_Update
> 
> 

Thanks for your reply. I am aware of the system_updates feature though still 
yet to implement. Is it possible to update the yocto version (i use dunfell) to 
the latest one, to update the linux version(mine is 5.4.180) to the latest and 
to update the tools to the latest using these features. Actually i have no 
clarity with this so I am asking.

Thanks and regards,
Hassan

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



Re: [yocto] continuous security updates for the Linux system

2023-10-09 Thread Josef Holzmayr
Please see https://wiki.yoctoproject.org/wiki/System_Update

Full disclosure: I work for Mender, which is one of the mentioned OTA
solutions - mender.io

Greetz,
Josef

On Mon, Oct 9, 2023 at 2:56 PM MOHAMMED HASSAN 
wrote:

> Hi guys,
> I want to know more about security updates in yocto.
> So generally we update our distros when we get pop-ups about security
> updates and it's done. But what if my device is installed at a
> remote location? How does security update take place in the case of yocto?
> How can we do it?
> Any other relevant information is graciously welcomed.
>
>
> Thanks and Regards,
> Hassan
>
> 
>
>

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



[yocto] continuous security updates for the Linux system

2023-10-09 Thread MOHAMMED HASSAN
Hi guys,
I want to know more about security updates in yocto.
So generally we update our distros when we get pop-ups about security
updates and it's done. But what if my device is installed at a
remote location? How does security update take place in the case of yocto?
How can we do it?
Any other relevant information is graciously welcomed.


Thanks and Regards,
Hassan

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



Re: [linux-yocto][linux-yocto v6.1] fix patch for marvell cn96xx

2023-10-09 Thread Bruce Ashfield
In message: [linux-yocto][linux-yocto v6.1] fix patch for marvell cn96xx
on 09/10/2023 Ruiqiang Hao wrote:

> Hi Bruce,
> 
> Please help to merge this patch into our linux-yocto repo.
> 
> repo:
>   linux-yocto
> branch:
>   v6.1/standard/cn-sdkv5.15/octeon
>   v6.1/standard/preempt-rt/cn-sdkv5.15/octeon

The condition being removed wasn't in exactly the same
place on the -rt brances, so I fixedup the patch when
applying it.

Both branches should be fixed.

Bruce

> 
> Thanks,
> Ruiqiang

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



Re: [linux-yocto] [PATCH] nxp-imx7: enable CONFIG_I2C kernel config explicitly

2023-10-09 Thread Bruce Ashfield
merged.

Bruce

In message: [PATCH] nxp-imx7: enable CONFIG_I2C kernel config explicitly
on 09/10/2023 Meng Li wrote:

> The CONFIG_I2C kernel config is not enabled if setup WRLinux project
> with nodistro parameter, so add it into BSP cfg file.
> 
> Signed-off-by: Meng Li 
> ---
>  bsp/nxp-imx7/nxp-imx7.cfg | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/bsp/nxp-imx7/nxp-imx7.cfg b/bsp/nxp-imx7/nxp-imx7.cfg
> index 37438785..930c697e 100644
> --- a/bsp/nxp-imx7/nxp-imx7.cfg
> +++ b/bsp/nxp-imx7/nxp-imx7.cfg
> @@ -86,6 +86,7 @@ CONFIG_SERIAL_FSL_LPUART_CONSOLE=y
>  
>  CONFIG_NVMEM_IMX_OCOTP=y
>  
> +CONFIG_I2C=y
>  CONFIG_I2C_CHARDEV=y
>  CONFIG_I2C_IMX=y
>  
> -- 
> 2.34.1
> 

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



[yocto] Password added succesfully but defaults to autologin

2023-10-09 Thread MOHAMMED HASSAN
Hi guys,
I am trying to set up a login password for my hardware but the problem is
that my device uses automatic login. I checked online to comment out
automatic login but it seems like
my /lib/systemd/system/serial-getty\@.service contains the line
"ExecStart=-/sbin/agetty -8 -L %I 921600 $TERM --autologin root" but before
building the image i checked my service file and "ExecStart=-/sbin/agetty
-8 -L %I @BAUDRATE@ $TERM". There is no mention of autologin and in my
image recipe file I have not enabled it.
After removing the line manually and reloading the service I can use the
login creds to login but ssh login returns the message "permission denied".

I have attached the relevant files for your reference. Let me know if you
need more information.

Regards,
Hassan


amlogic-yocto.bb
Description: Binary data
#  SPDX-License-Identifier: LGPL-2.1+
#
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=Serial Getty on %I
Documentation=man:agetty(8) man:systemd-getty-generator(8)
Documentation=http://0pointer.de/blog/projects/serial-console.html
PartOf=dev-%i.device
ConditionPathExists=/dev/%i
After=dev-%i.device systemd-user-sessions.service plymouth-quit-wait.service getty-pre.target
After=rc-local.service

# If additional gettys are spawned during boot then we should make
# sure that this is synchronized before getty.target, even though
# getty.target didn't actually pull it in.
Before=getty.target
IgnoreOnIsolate=yes

# IgnoreOnIsolate causes issues with sulogin, if someone isolates
# rescue.target or starts rescue.service from multi-user.target or
# graphical.target.
Conflicts=rescue.service
Before=rescue.service

[Service]
Environment="TERM=xterm"
ExecStart=-/sbin/agetty -8 -L %I @BAUDRATE@ $TERM
Type=idle
Restart=always
UtmpIdentifier=%I
TTYPath=/dev/%I
TTYReset=yes
TTYVHangup=yes
KillMode=process
IgnoreSIGPIPE=no
SendSIGHUP=yes

[Install]
WantedBy=getty.target


systemd-serialgetty.bb
Description: Binary data

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61283): https://lists.yoctoproject.org/g/yocto/message/61283
Mute This Topic: https://lists.yoctoproject.org/mt/101849757/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] rock-3a add

2023-10-09 Thread Anthony Davies
Hi Quentin,

On Mon, 9 Oct 2023 at 19:25, Quentin Schulz
 wrote:
>
> 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.

This would be my vim converting my \t to spaces. I will update and resend.

>
> >   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 

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

2023-10-09 Thread 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]
-=-=-=-=-=-=-=-=-=-=-=-