Re: [PATCH v2 2/5] arm64: dts: qcom: Add AYN QCS8550 Common

[Aaron Kling]

On Fri, Mar 13, 2026 at 7:11 PM Val Packett <val@xxxxxxxxxxxx> wrote:
>
>
> On 3/13/26 3:21 PM, Aaron Kling wrote:
> > On Fri, Mar 13, 2026 at 12:48 PM Dmitry Baryshkov
> > <dmitry.baryshkov@xxxxxxxxxxxxxxxx> wrote:
> >> On Fri, Mar 13, 2026 at 12:34:21PM -0500, Aaron Kling wrote:
> >>> On Fri, Mar 13, 2026 at 3:37 AM Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote:
> >>>> On Fri, Mar 13, 2026 at 05:19:27AM +0200, Dmitry Baryshkov wrote:
> >>>>> On Wed, Mar 11, 2026 at 08:39:37PM -0500, Aaron Kling wrote:
> >>>>>> On Wed, Mar 11, 2026 at 7:49 PM Val Packett <val@xxxxxxxxxxxx> wrote:
> >>>>>>> On 3/11/26 2:44 PM, Aaron Kling wrote:
> >>>>>>>
> >>>>>>>> From: Teguh Sobirin <teguh@xxxxxxxx>
> >>>>>>>>
> >>>>>>>> This adds a base dtb of everything common between the AYN QCS8550
> >>>>>>>> devices. It is intended to be extended by device specific overlays.
> >>>>>>>>
> >>>>>>>> Signed-off-by: Teguh Sobirin <teguh@xxxxxxxx>
> >>>>>>>> Co-developed-by: Aaron Kling <webgeek1234@xxxxxxxxx>
> >>>>>>>> Signed-off-by: Aaron Kling <webgeek1234@xxxxxxxxx>
> >>>>>>>> ---
> >>>>>>>>    arch/arm64/boot/dts/qcom/Makefile                  |    1 +
> >>>>>>>>    arch/arm64/boot/dts/qcom/qcs8550-ayntec-common.dts | 1777 ++++++++++++++++++++
> >>>> Common is not a board, NAK. This could only be DTSI if you provide some
> >>>> sort of HARDWARE arguments explaining the common parts of schematics or
> >>>> hardware design.
> >>>>
> >>>> Not enough. We do not add compatibles not representing actual hardware,
> >>>> just to streamline boot image handling.
> >>>>
> >>>> Plus this code is not even truly correct.
> >>>>
> >>>> We do not write DTS to fulfill broken Android boot process.
> >>> I have been trying rather hard to find a reasonable compromise between
> >>> mainline requirements and a normal Android use case, something I can
> >>> actually ship to normal users. This seemed fairly reasonable to me,
> >>> since it can generate standalone dtb's transparently. But if my use
> >>> case can never meet submission requirements, then why am I even here,
> >>> getting shamed for working on Android? If I have to fork the
> >>> device-tree anyways to fit my requirements, then there's no reason for
> >>> me to put the time and effort in to submitting something I can't use.
> >>> I'd be better off just keeping everything out of tree as googles
> >>> kernel-platform supports. And never look at mainline qcom again.
> >> Well... It's a tough argument. Getting your DTs into mainline would help
> >> occasional users that would like to run something else than Android
> >> (PmOS or some other distro). Also it ensures that you can run Android
> >> even when Google (Qualcomm) EOL the current SM8550 msm-something tree.
> > Oh, I'm not working on the downstream kernel either way. The question
> > is whether device support gets mainlined or if I keep all support out
> > of tree and only update when Google forks the ack from a new lts.
>
> IMO landing everything with proper upstream style and having minimal
> customization/patching during your Android build process to convert it
> into a base dtb + dtbos setup (or a blank base + everything as dtbos
> one?) during would already be really valuable.

The end goal was to get everything possible merged before the 7.x lts
and use Googles Android Common Kernel repo as-is from that version on,
no vendor specific fork. Perhaps overly idealistic, but still the
goal. There would be a few android specific device tree things needed
in out of tree extensions, but that's trivial with the kernel-platform
build setup. Including a common dtsi and extending that out of tree to
a base dtb is trivial, if said dtsi doesn't get nack'ed as was already
threatened if I don't provide documentation I can't possibly obtain.
But if the device specific parts are a dts that already include the
common dtsi, extending those, cutting out the common include, and
turning it into a dtso is potentially not possible. And even if it is,
the method would probably be approaching a crime against humanity. And
if I have to fork the main kernel anyways, I'm losing a large piece of
why I'm trying to upstream things in the first place: cutting direct
maintenance of that repo out of my workflow and only needing to push
fixes when new issues are found.

An empty base dtb is an interesting thought, but I don't think it will
work with abl. There's been this whole back and forth in other threads
about how abl will fail to apply any dtbo, even an empty one, if it
can't find certain labels in the base dtb to apply changes to. I would
expect even more of those to pop up if I tried to minimize the base
dtb. And then there's still the issue of extending a dts into a dtso
that might not be possible. Which brings things back around to having
to fork at least the device specific parts out of tree to make dtso's,
if they can't be a dtso in-tree.

> >> Speaking about the boot process. I remember that historically it was
> >> possible to pass several DTBs in the the Android boot image. Is it no
> >> longer the case? Is there any way to identify the boards (I think
> >> historical code was using qcom,board-id for that)? Then you would be
> >> able to squash all your DTBs in a single boot image.
> > That functionality is still there, the concatenated dtb slot in the
> > vendor_boot image. Unfortunately for this context, the odm did not
> > change those ids per hardware variant. I think they just left them at
> > the hdk or qrd default that came with the bsp. I do have to jump some
> > software hoops to slot in the correct dtbo to the dtbo partition
> > during inline updates because of this, but it's not terrible. And
> > that's not something I can reasonably do for the vendor_boot image. To
> > my knowledge, there is no way for the bootloader to tell these devices
> > apart and any attempt to do so would require a custom abl build,
> > probably per variant, which would then desync the boot firmware from
> > the official OS, plus make first install more difficult for users,
> > both of which I'm trying not to do.
>
> Leaving the default board ID is a classic… but on many old Android
> phones you (read: an intermediate bootloader) can use the cmdline
> injected by ABL to distinguish between models. Nothing like that here?

Maybe something like the panel params, but two of the variants share a
ddic, so that might not even be sufficient. But if I add u-boot to the
boot sequence, then I lose a lot of things that abl handles and have
to set them up in u-boot. Things like loading init_boot and
vendor_boot ramdisks, handling bootconfig, avb parameters, etc etc. Or
drastically change the aosp device tree configs to disable those
things and in doing so become non-compliant with current aosp
expectations. Long story short: chainloading another bootloader and
staying compliant with vts is a *lot* of effort I really don't want to
do. Booting android on qcom via u-boot is certainly possible and I've
seen others doing so, but those have deviated a lot from the OS
expectations, and the more deviations there are, the larger the chance
that unexpected things go horribly wrong.

Aaron