On Wed 2023-10-04 @ 10:39:14 AM, Bruce Ashfield wrote:
> On Wed, Oct 4, 2023 at 9:59 AM Quentin Schulz via lists.yoctoproject.org
> <[email protected]> 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?
> >
>
> My last run in with this may have been before some of the most recent
> device tree handling patches, and/or I may have been doing it wrong.
>
> But my solution was to simply override the variable in a kernel version
> specific bbappend, and not do it in the conf files.
>
> But of course, if that variable is being interpreted by a different class in
> the global namespace, then the kernel bbappend approach isn't going
> to work anymore.
>
> I've stayed away from utilities or searching, etc, rather just a way for the
> configuration to specify directly what to find, as anything that searches
> ends up being fragile.
The biggest tangle is that the master branch supports 6.1, 6.4, and 6.5.
Getting something to work with one version at at time isn't hard; getting it
to work simultaneously with all 3 (and others?) is the tricky part.
In a perfect world we could have linux-kernel-version-specific machine conf
sections/files... but that would be crazy!
I've been poking at this from different angles off-and-on for the last couple
days. The more I look at it, the more I like what meta-ti-bsp did. That's
probably what I'm going to do:
conf/machine/MACHINE.conf file has:
- KERNEL_DEVICETREE that just lists the bare dtb file (without directories)
- KERNEL_DEVICETREE_PREFIX that lists possible directory names
recipes-kernel/linux/linux-yocto% bbappends have logic to check combinations
of KERNEL_DEVICETREE_PREFIX+KERNEL_DEVICETREE to find the actual dtb.
Something probably also needs to be added to IMAGE_BOOT_FILES so wic works
too.
NOTE: given that this is meta-rockchip, the KERNEL_DEVICETREE_PREFIX could
simply be known to be "rockchip" a-priori; it doesn't necessarily need to be
that flexible.
And the real catch is that this is only a problem today because a specific OE
branch has both pre- and post- cleanup kernel versions. If the OE branches
didn't mix the two, this wouldn't be a problem. And someday once master has
moved away from having both pre- and post- cleanup kernel versions, we can
throw all this infrastructure out (on master) going forward.
Best regards,
Trevor
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61241): https://lists.yoctoproject.org/g/yocto/message/61241
Mute This Topic: https://lists.yoctoproject.org/mt/101728482/21656
Group Owner: [email protected]
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
