From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-183.mta0.migadu.com (out-183.mta0.migadu.com [91.218.175.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4F3A419F40B for ; Sat, 28 Feb 2026 21:28:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.183 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772314117; cv=none; b=CRTFjhdNCxpAzQToj1EAFPgmL0U+OxNIRPofYOtTc13z4OpDFcQX504deDl2BsIFryvtP/S5J+UCy7KKe76Mohq+FtBZTpMA7eMw5JbFJnE8MkbZNd5Gxj7YXHE7NJ5qzKKrAtXKdcvM01RsCLuN74yeMybgl9rE48ssrRXMBw4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772314117; c=relaxed/simple; bh=JHfkwcQgJSlz2GM0sgnpNaNxj1ZXE/S9TRi/hKsJgrI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=K98vhop3ZW/WrMxznV6tgcM1zUSdb+HUa/o9OG8MI0fTIVZxQr09rovNHwSutuPLS64e2YXzl68UB841E+gPtAIwCAOzvEyMhfQs2Em59fBp89D5d6n2vu09ZXjS+8G/SgvEbovNzPQwJEYJ2smZ4ySY5ucqxHNTTiigGM4roL4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=packett.cool; spf=pass smtp.mailfrom=packett.cool; dkim=pass (2048-bit key) header.d=packett.cool header.i=@packett.cool header.b=inrtWo1o; arc=none smtp.client-ip=91.218.175.183 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=packett.cool Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=packett.cool Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=packett.cool header.i=@packett.cool header.b="inrtWo1o" Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packett.cool; s=key1; t=1772314102; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2drmw23LMhAgqnFvPZArzH0QWWWznsj4GGf5ZiSEOsg=; b=inrtWo1ogxteJXPqsWDrYMM3i44qox2INfkGkt0RqUdMGn9W2FQe87It27cRrU/p2IspfU uj3iT56Bouh/7gJ9tCykH1XFiVZEHHtZvXN/JA9xgGLwK1moFpPItdNZmCFapakhmOgPYU ufUHMOe2EtsNlHQcwfNYXW/KXastyHjbK44eVlXrqPGX4kfQHJxyEe/wvBKZj/lDbk+mA0 KMffRQKyV+6ozSeDIRTFFGEkhWVM98Ej9uiFh6M0zaMvenmmLEFkOLkgZm+G63QSIyVcXh P8snT4+pm0uVcQXB6iNWEmDqzm0pX6FCdGPOFdoiwUt8WCHLnmmL6l6DZ4vcMg== Date: Sat, 28 Feb 2026 18:28:13 -0300 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH v2] arm64: dts: qcom: sm8550: Fix DTBO boot failure To: Aaron Kling , Bjorn Andersson Cc: Krzysztof Kozlowski , Konrad Dybcio , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Kumar Sharma , linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Pavan Kondeti References: <20260207-sm8550-abl-dtbo-v2-1-83afaa6f3ce9@gmail.com> <487e4605-0a21-48d6-8b77-9ce2799ad212@kernel.org> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Val Packett In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On 2/16/26 11:27 PM, Aaron Kling wrote: > On Fri, Feb 13, 2026 at 10:02 PM Bjorn Andersson wrote: >> On Fri, Feb 13, 2026 at 04:50:25PM -0600, Aaron Kling wrote: >>> On Fri, Feb 13, 2026 at 2:34 PM Bjorn Andersson wrote: >>>> On Wed, Feb 11, 2026 at 09:10:39AM -0600, Aaron Kling wrote: >>>>> On Mon, Feb 9, 2026 at 1:51 AM Krzysztof Kozlowski wrote: […] >>>>> My use case here is an open source Android rom. I would like to think >>>>> that android would be a supported use case. Not necessarily a driving >>>>> force for decisions, but at least supported. And I'm using the >>>>> standard boot image v4 setup with dtb on vendor_boot and dtbo's on the >>>>> dedicated partition. This isn't some weird and wacko setup, it's what >>>>> the vast majority of devices this soc is used in are designed for. >>>> Android isn't a weird and wacko setup; but I'm guessing that the >>>> proposed changes aren't related to running Android, nor are they related >>>> to dependencies of the overlays, but it rather relate to some >>>> runtime-generated overlay that ABL wants to apply? >>> I honestly can't say what the underlying cause is. A couple of us have >>> looked at the public abl source and weren't able to find what causes >>> this issue. We just know that this issue happens when abl tries to >>> apply a dtbo off the dtbo partition. So yes, in technicality this is >>> not an android specific issue. I mention android because having a dtbo >>> is generally expected in the aosp setup. In my specific use case, I >>> have four devices from the same odm, where it's simple to split the >>> common part into a dts, then the device specific parts into dtso's, >>> allowing for a single software build to support all four devices. >>> Requiring everything to be baked into a dts would require separate >>> vendor_boot images per device, and thus completely separate build >>> targets. […] >> Sounds like it, but I don't know what it is that ABL is expecting to be >> able to insert. [0] seems to mostly say "I added this and then it works" >> :( What everyone (well, postmarketOS community at least) has been doing when running mainline kernels on ABL devices is `fastboot erase dtbo`(*). Which is why we don't have any DTBO target nodes anywhere upstream. If you want to intentionally use ABL DTBO, and you're absolutely sure you **don't** reference these nodes in the DTBOs you're making, then indeed it might be some "runtime overlay" coming from ABL code.. but have you tried adding these nodes in the DTBOs themselves? Wait, also, what is the build process for your DTBOs? Could there be some weird Android build thing that inserts references to these nodes? Have you tried decompiling them with dtc and looking at the resulting dts? Also have you looked into intermediate bootloaders as an alternative? postmarketOS uses lk2nd on ancient devices and U-Boot on modern ones; these bootloaders can dynamically choose (or even modify) a DTB based on runtime detection (like ABL cmdline). Might be hard/strange to fit that into the Android world but well, that's Android's fault :) (*) except on some old SoCs where we need a "blank" dtbo that just has qcom,board-id! https://github.com/barni2000/dtbo-lk2nd (cursed) ~val