All of lore.kernel.org
 help / color / mirror / Atom feed
From: Trevor Woerner <twoerner@gmail.com>
To: Bruce Ashfield <bruce.ashfield@gmail.com>
Cc: quentin.schulz@theobroma-systems.com, yocto@lists.yoctoproject.org
Subject: Re: [yocto] [meta-rockchip][PATCH] KERNEL_DEVICETREE: 32-bit re-org
Date: Wed, 4 Oct 2023 15:21:22 -0400	[thread overview]
Message-ID: <20231004192122.GA34066@localhost> (raw)
In-Reply-To: <CADkTA4NtDgLQN3Meq3fpEYSdFf++bUJVHSRPYjA4VUSEG-9QUw@mail.gmail.com>

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
> <quentin.schulz=theobroma-systems.com@lists.yoctoproject.org> 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


      reply	other threads:[~2023-10-04 19:21 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-03  4:19 [meta-rockchip][PATCH] KERNEL_DEVICETREE: 32-bit re-org Trevor Woerner
2023-10-03 10:32 ` [yocto] " Quentin Schulz
2023-10-03 13:38   ` Trevor Woerner
2023-10-04 13:45     ` Quentin Schulz
2023-10-04 13:46       ` Quentin Schulz
2023-10-04 14:39       ` Bruce Ashfield
2023-10-04 19:21         ` Trevor Woerner [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231004192122.GA34066@localhost \
    --to=twoerner@gmail.com \
    --cc=bruce.ashfield@gmail.com \
    --cc=quentin.schulz@theobroma-systems.com \
    --cc=yocto@lists.yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.