[PATCH v2 1/2] dt-bindings: interconnect: qcom: make sc7280 aggre{1,2}-noc clocks optional

[PATCH v2 1/2] dt-bindings: interconnect: qcom: make sc7280 aggre{1,2}-noc clocks optional

[Brian Norris]

We've found that some device firmware does not expose all the QoS
resources necessary to manage these interconnects, and that the driver
code that starts using them crashes. Leave 'clocks' as optional for
qcom,sc7280-aggre1-noc and qcom,sc7280-aggre2-noc instead.

Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Brian Norris <briannorris@chromium.org>
---

Changes in v2:
 * new in v2

 .../interconnect/qcom,sc7280-rpmh.yaml         | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/interconnect/qcom,sc7280-rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,sc7280-rpmh.yaml
index 81c3dff53992..5dbd0563ac17 100644
--- a/Documentation/devicetree/bindings/interconnect/qcom,sc7280-rpmh.yaml
+++ b/Documentation/devicetree/bindings/interconnect/qcom,sc7280-rpmh.yaml
@@ -82,17 +82,17 @@ allOf:
           items:
             - description: RPMH CC IPA clock
 
+  # QoS clocks are only valid for aggre{1,2}-noc. Some TZ firmware do not
+  # expose even these, so they remain optional.
   - if:
-      properties:
-        compatible:
-          contains:
-            enum:
-              - qcom,sc7280-aggre1-noc
-              - qcom,sc7280-aggre2-noc
+      not:
+        properties:
+          compatible:
+            contains:
+              enum:
+                - qcom,sc7280-aggre1-noc
+                - qcom,sc7280-aggre2-noc
     then:
-      required:
-        - clocks
-    else:
       properties:
         clocks: false
 
-- 
2.51.0.261.g7ce5a0a67e-goog

[PATCH v2 2/2] arm64: dts: qcom: sc7280: Drop aggre{1,2}_noc QOS clocks on Herobrine

[Brian Norris]

Ever since these two commits

  fbd908bb8bc0 ("interconnect: qcom: sc7280: enable QoS configuration")
  2b5004956aff ("arm64: dts: qcom: sc7280: Add clocks for QOS configuration")

Herobrine systems fail to boot due to crashes like the following:

[    0.243171] Kernel panic - not syncing: Asynchronous SError Interrupt
[    0.243173] CPU: 7 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0 #1 c5464041cff584ced692726af2c4400fa2bde1db
[    0.243178] Hardware name: Qualcomm Technologies, Inc. sc7280 CRD platform (rev5+) (DT)
[    0.243180] Call trace:
[    0.243182]  dump_backtrace+0x104/0x128
[    0.243194]  show_stack+0x24/0x38
[    0.243202]  __dump_stack+0x28/0x38
[    0.243208]  dump_stack_lvl+0x28/0xb8
[    0.243211]  dump_stack+0x18/0x30
[    0.243215]  panic+0x134/0x340
[    0.243219]  nmi_panic+0x48/0x98
[    0.243227]  arm64_serror_panic+0x6c/0x80
[    0.243245]  arm64_is_fatal_ras_serror+0xd8/0xe0
[    0.243261]  do_serror+0x5c/0xa8
[    0.243265]  el1h_64_error_handler+0x34/0x48
[    0.243272]  el1h_64_error+0x7c/0x80
[    0.243285]  regmap_mmio_read+0x5c/0xc0
[    0.243289]  _regmap_bus_reg_read+0x78/0xf8
[    0.243296]  regmap_update_bits_base+0xec/0x3a8
[    0.243300]  qcom_icc_rpmh_probe+0x2d4/0x490
[    0.243308]  platform_probe+0xb4/0xe0
[...]

Specifically, they fail in qcom_icc_set_qos() when trying to write the
QoS settings for qhm_qup1. Several of the previous nodes (qhm_qspi,
qhm_qup0, ...) seem to configure without crashing.

We suspect that the TZ firmware on these devices does not expose QoS
regions to Linux. The right solution here might involve deleting both
'clocks' and 'reg', but 'reg' would cause more problems. Linux is
already OK with a missing 'clocks', since pre-2b5004956aff DTBs need to
be supported, so we go with an easier solution.

Fixes: fbd908bb8bc0 ("interconnect: qcom: sc7280: enable QoS configuration")
Fixes: 2b5004956aff ("arm64: dts: qcom: sc7280: Add clocks for QOS configuration")
Signed-off-by: Brian Norris <briannorris@chromium.org>
---

Changes in v2:
 * Update notes about TZ firmware

 arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
index 2ba4ea60cb14..6237fc7a13ca 100644
--- a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
@@ -394,6 +394,16 @@ &vreg_l2c_1p8 {
 
 /* ADDITIONS TO NODES DEFINED IN PARENT DEVICE TREE FILES */
 
+/* TZ firmware on these devices seems to not expose QoS regions to the OS. */
+&aggre1_noc {
+	/delete-property/ clocks;
+};
+
+/* TZ firmware on these devices seems to not expose QoS regions to the OS. */
+&aggre2_noc {
+	/delete-property/ clocks;
+};
+
 &edp_panel {
 	/* Our board provides power to the qcard for the eDP panel. */
 	power-supply = <&vreg_edp_3p3>;
-- 
2.51.0.261.g7ce5a0a67e-goog

Re: [PATCH v2 1/2] dt-bindings: interconnect: qcom: make sc7280 aggre{1,2}-noc clocks optional

[Rob Herring (Arm)]

On Mon, 25 Aug 2025 15:55:56 -0700, Brian Norris wrote:
> We've found that some device firmware does not expose all the QoS
> resources necessary to manage these interconnects, and that the driver
> code that starts using them crashes. Leave 'clocks' as optional for
> qcom,sc7280-aggre1-noc and qcom,sc7280-aggre2-noc instead.
> 
> Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> ---
> 
> Changes in v2:
>  * new in v2
> 
>  .../interconnect/qcom,sc7280-rpmh.yaml         | 18 +++++++++---------
>  1 file changed, 9 insertions(+), 9 deletions(-)
> 

Acked-by: Rob Herring (Arm) <robh@kernel.org>

Re: [PATCH v2 2/2] arm64: dts: qcom: sc7280: Drop aggre{1,2}_noc QOS clocks on Herobrine

[Konrad Dybcio]

On 8/26/25 12:55 AM, Brian Norris wrote:
> Ever since these two commits
> 
>   fbd908bb8bc0 ("interconnect: qcom: sc7280: enable QoS configuration")
>   2b5004956aff ("arm64: dts: qcom: sc7280: Add clocks for QOS configuration")
> 
> Herobrine systems fail to boot due to crashes like the following:
> 
> [    0.243171] Kernel panic - not syncing: Asynchronous SError Interrupt
> [    0.243173] CPU: 7 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0 #1 c5464041cff584ced692726af2c4400fa2bde1db
> [    0.243178] Hardware name: Qualcomm Technologies, Inc. sc7280 CRD platform (rev5+) (DT)
> [    0.243180] Call trace:
> [    0.243182]  dump_backtrace+0x104/0x128
> [    0.243194]  show_stack+0x24/0x38
> [    0.243202]  __dump_stack+0x28/0x38
> [    0.243208]  dump_stack_lvl+0x28/0xb8
> [    0.243211]  dump_stack+0x18/0x30
> [    0.243215]  panic+0x134/0x340
> [    0.243219]  nmi_panic+0x48/0x98
> [    0.243227]  arm64_serror_panic+0x6c/0x80
> [    0.243245]  arm64_is_fatal_ras_serror+0xd8/0xe0
> [    0.243261]  do_serror+0x5c/0xa8
> [    0.243265]  el1h_64_error_handler+0x34/0x48
> [    0.243272]  el1h_64_error+0x7c/0x80
> [    0.243285]  regmap_mmio_read+0x5c/0xc0
> [    0.243289]  _regmap_bus_reg_read+0x78/0xf8
> [    0.243296]  regmap_update_bits_base+0xec/0x3a8
> [    0.243300]  qcom_icc_rpmh_probe+0x2d4/0x490
> [    0.243308]  platform_probe+0xb4/0xe0
> [...]
> 
> Specifically, they fail in qcom_icc_set_qos() when trying to write the
> QoS settings for qhm_qup1. Several of the previous nodes (qhm_qspi,
> qhm_qup0, ...) seem to configure without crashing.
> 
> We suspect that the TZ firmware on these devices does not expose QoS
> regions to Linux. The right solution here might involve deleting both
> 'clocks' and 'reg', but 'reg' would cause more problems. Linux is
> already OK with a missing 'clocks', since pre-2b5004956aff DTBs need to
> be supported, so we go with an easier solution.

Just to make sure I'm reading this right - the clocks enable just fine,
but it's the writes to the QoS settings that trigger the hang?
Any chance skipping qhm_qup1 specifically makes things better?

Could you please share your exact software version (which I assume is really
just the version of TF-A in this case) so I can try and reproduce it?

Konrad

Re: [PATCH v2 2/2] arm64: dts: qcom: sc7280: Drop aggre{1,2}_noc QOS clocks on Herobrine

[Brian Norris]

Hi Konrad,

On Tue, Sep 02, 2025 at 02:02:15PM +0200, Konrad Dybcio wrote:
> On 8/26/25 12:55 AM, Brian Norris wrote:
> > Ever since these two commits
> > 
> >   fbd908bb8bc0 ("interconnect: qcom: sc7280: enable QoS configuration")
> >   2b5004956aff ("arm64: dts: qcom: sc7280: Add clocks for QOS configuration")
> > 
> > Herobrine systems fail to boot due to crashes like the following:
> > 
> > [    0.243171] Kernel panic - not syncing: Asynchronous SError Interrupt
> > [    0.243173] CPU: 7 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0 #1 c5464041cff584ced692726af2c4400fa2bde1db
> > [    0.243178] Hardware name: Qualcomm Technologies, Inc. sc7280 CRD platform (rev5+) (DT)
> > [    0.243180] Call trace:
> > [    0.243182]  dump_backtrace+0x104/0x128
> > [    0.243194]  show_stack+0x24/0x38
> > [    0.243202]  __dump_stack+0x28/0x38
> > [    0.243208]  dump_stack_lvl+0x28/0xb8
> > [    0.243211]  dump_stack+0x18/0x30
> > [    0.243215]  panic+0x134/0x340
> > [    0.243219]  nmi_panic+0x48/0x98
> > [    0.243227]  arm64_serror_panic+0x6c/0x80
> > [    0.243245]  arm64_is_fatal_ras_serror+0xd8/0xe0
> > [    0.243261]  do_serror+0x5c/0xa8
> > [    0.243265]  el1h_64_error_handler+0x34/0x48
> > [    0.243272]  el1h_64_error+0x7c/0x80
> > [    0.243285]  regmap_mmio_read+0x5c/0xc0
> > [    0.243289]  _regmap_bus_reg_read+0x78/0xf8
> > [    0.243296]  regmap_update_bits_base+0xec/0x3a8
> > [    0.243300]  qcom_icc_rpmh_probe+0x2d4/0x490
> > [    0.243308]  platform_probe+0xb4/0xe0
> > [...]
> > 
> > Specifically, they fail in qcom_icc_set_qos() when trying to write the
> > QoS settings for qhm_qup1. Several of the previous nodes (qhm_qspi,
> > qhm_qup0, ...) seem to configure without crashing.
> > 
> > We suspect that the TZ firmware on these devices does not expose QoS
> > regions to Linux. The right solution here might involve deleting both
> > 'clocks' and 'reg', but 'reg' would cause more problems. Linux is
> > already OK with a missing 'clocks', since pre-2b5004956aff DTBs need to
> > be supported, so we go with an easier solution.
> 
> Just to make sure I'm reading this right - the clocks enable just fine,
> but it's the writes to the QoS settings that trigger the hang?

Yes.

> Any chance skipping qhm_qup1 specifically makes things better?

Yes, it seems so. Or specifically, this diff:

--- a/drivers/interconnect/qcom/sc7280.c
+++ b/drivers/interconnect/qcom/sc7280.c
@@ -52,12 +52,6 @@ static struct qcom_icc_node qhm_qup1 = {
 	.id = SC7280_MASTER_QUP_1,
 	.channels = 1,
 	.buswidth = 4,
-	.qosbox = &(const struct qcom_icc_qosbox) {
-		.num_ports = 1,
-		.port_offsets = { 0x8000 },
-		.prio = 2,
-		.urg_fwd = 0,
-	},
 	.num_links = 1,
 	.links = { SC7280_SLAVE_A1NOC_SNOC },
 };

> Could you please share your exact software version (which I assume is really
> just the version of TF-A in this case) so I can try and reproduce it?

I'm not much of an expert on the makeup of QCOM firmware, but reading my
firmware logs, that'd be:

  coreboot-v1.9308_26_0.0.22-32067-g641732a20a

and

  BL31: v2.8(debug):v2.8-776-g0223d1576

IIUC, the latter points to TF-A hash:

  0223d15764ed Merge "feat(docs): allow verbose build" into integration

Brian

Re: [PATCH v2 2/2] arm64: dts: qcom: sc7280: Drop aggre{1,2}_noc QOS clocks on Herobrine

[Konrad Dybcio]

On 9/11/25 9:00 PM, Brian Norris wrote:
> Hi Konrad,
> 
> On Tue, Sep 02, 2025 at 02:02:15PM +0200, Konrad Dybcio wrote:
>> On 8/26/25 12:55 AM, Brian Norris wrote:
>>> Ever since these two commits
>>>
>>>   fbd908bb8bc0 ("interconnect: qcom: sc7280: enable QoS configuration")
>>>   2b5004956aff ("arm64: dts: qcom: sc7280: Add clocks for QOS configuration")
>>>
>>> Herobrine systems fail to boot due to crashes like the following:
>>>
>>> [    0.243171] Kernel panic - not syncing: Asynchronous SError Interrupt
>>> [    0.243173] CPU: 7 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0 #1 c5464041cff584ced692726af2c4400fa2bde1db
>>> [    0.243178] Hardware name: Qualcomm Technologies, Inc. sc7280 CRD platform (rev5+) (DT)
>>> [    0.243180] Call trace:
>>> [    0.243182]  dump_backtrace+0x104/0x128
>>> [    0.243194]  show_stack+0x24/0x38
>>> [    0.243202]  __dump_stack+0x28/0x38
>>> [    0.243208]  dump_stack_lvl+0x28/0xb8
>>> [    0.243211]  dump_stack+0x18/0x30
>>> [    0.243215]  panic+0x134/0x340
>>> [    0.243219]  nmi_panic+0x48/0x98
>>> [    0.243227]  arm64_serror_panic+0x6c/0x80
>>> [    0.243245]  arm64_is_fatal_ras_serror+0xd8/0xe0
>>> [    0.243261]  do_serror+0x5c/0xa8
>>> [    0.243265]  el1h_64_error_handler+0x34/0x48
>>> [    0.243272]  el1h_64_error+0x7c/0x80
>>> [    0.243285]  regmap_mmio_read+0x5c/0xc0
>>> [    0.243289]  _regmap_bus_reg_read+0x78/0xf8
>>> [    0.243296]  regmap_update_bits_base+0xec/0x3a8
>>> [    0.243300]  qcom_icc_rpmh_probe+0x2d4/0x490
>>> [    0.243308]  platform_probe+0xb4/0xe0
>>> [...]
>>>
>>> Specifically, they fail in qcom_icc_set_qos() when trying to write the
>>> QoS settings for qhm_qup1. Several of the previous nodes (qhm_qspi,
>>> qhm_qup0, ...) seem to configure without crashing.
>>>
>>> We suspect that the TZ firmware on these devices does not expose QoS
>>> regions to Linux. The right solution here might involve deleting both
>>> 'clocks' and 'reg', but 'reg' would cause more problems. Linux is
>>> already OK with a missing 'clocks', since pre-2b5004956aff DTBs need to
>>> be supported, so we go with an easier solution.
>>
>> Just to make sure I'm reading this right - the clocks enable just fine,
>> but it's the writes to the QoS settings that trigger the hang?
> 
> Yes.
> 
>> Any chance skipping qhm_qup1 specifically makes things better?
> 
> Yes, it seems so. Or specifically, this diff:
> 
> --- a/drivers/interconnect/qcom/sc7280.c
> +++ b/drivers/interconnect/qcom/sc7280.c
> @@ -52,12 +52,6 @@ static struct qcom_icc_node qhm_qup1 = {
>  	.id = SC7280_MASTER_QUP_1,
>  	.channels = 1,
>  	.buswidth = 4,
> -	.qosbox = &(const struct qcom_icc_qosbox) {
> -		.num_ports = 1,
> -		.port_offsets = { 0x8000 },
> -		.prio = 2,
> -		.urg_fwd = 0,
> -	},
>  	.num_links = 1,
>  	.links = { SC7280_SLAVE_A1NOC_SNOC },
>  };

As I attempt to find a board that would boot with your sw stack,
could I ask you to check if commenting any of the three writes in

drivers/interconnect/qcom/icc-rpmh.c : qcom_icc_set_qos()

specifically causes the crash?

FWIW they're supposed to be independent so you don't have to test
all possible combinations

Konrad

> 
>> Could you please share your exact software version (which I assume is really
>> just the version of TF-A in this case) so I can try and reproduce it?
> 
> I'm not much of an expert on the makeup of QCOM firmware, but reading my
> firmware logs, that'd be:
> 
>   coreboot-v1.9308_26_0.0.22-32067-g641732a20a
> 
> and
> 
>   BL31: v2.8(debug):v2.8-776-g0223d1576
> 
> IIUC, the latter points to TF-A hash:
> 
>   0223d15764ed Merge "feat(docs): allow verbose build" into integration
> 
> Brian

Re: [PATCH v2 2/2] arm64: dts: qcom: sc7280: Drop aggre{1,2}_noc QOS clocks on Herobrine

[Brian Norris]

On Fri, Sep 12, 2025 at 03:10:16PM +0200, Konrad Dybcio wrote:
> As I attempt to find a board that would boot with your sw stack,
> could I ask you to check if commenting any of the three writes in
> 
> drivers/interconnect/qcom/icc-rpmh.c : qcom_icc_set_qos()
> 
> specifically causes the crash?
> 
> FWIW they're supposed to be independent so you don't have to test
> all possible combinations

It seems as if any one of them will cause the crash. I had to comment
out all 3 to avoid crashing.

Brian

Re: [PATCH v2 2/2] arm64: dts: qcom: sc7280: Drop aggre{1,2}_noc QOS clocks on Herobrine

[Brian Norris]

Hi Konrad,

On Fri, Sep 12, 2025 at 12:37:29PM -0700, Brian Norris wrote:
> On Fri, Sep 12, 2025 at 03:10:16PM +0200, Konrad Dybcio wrote:
> > As I attempt to find a board that would boot with your sw stack,
> > could I ask you to check if commenting any of the three writes in
> > 
> > drivers/interconnect/qcom/icc-rpmh.c : qcom_icc_set_qos()
> > 
> > specifically causes the crash?
> > 
> > FWIW they're supposed to be independent so you don't have to test
> > all possible combinations
> 
> It seems as if any one of them will cause the crash. I had to comment
> out all 3 to avoid crashing.

I'm curious if you had any follow-up here. Are you still looking for an
alternative to this patch?

Brian

Re: [PATCH v2 2/2] arm64: dts: qcom: sc7280: Drop aggre{1,2}_noc QOS clocks on Herobrine

[Konrad Dybcio]

On 1/9/26 1:33 AM, Brian Norris wrote:
> Hi Konrad,
> 
> On Fri, Sep 12, 2025 at 12:37:29PM -0700, Brian Norris wrote:
>> On Fri, Sep 12, 2025 at 03:10:16PM +0200, Konrad Dybcio wrote:
>>> As I attempt to find a board that would boot with your sw stack,
>>> could I ask you to check if commenting any of the three writes in
>>>
>>> drivers/interconnect/qcom/icc-rpmh.c : qcom_icc_set_qos()
>>>
>>> specifically causes the crash?
>>>
>>> FWIW they're supposed to be independent so you don't have to test
>>> all possible combinations
>>
>> It seems as if any one of them will cause the crash. I had to comment
>> out all 3 to avoid crashing.
> 
> I'm curious if you had any follow-up here. Are you still looking for an
> alternative to this patch?

Sorry Brian, it seems like all the "ready to grab" firmware image links
for this platform are dead where I would normally look, which prevented
me from being able to poke at this..

Would there happen to be another place where I can grab them from,
perhaps some CrOS CI?

Konrad

Re: [PATCH v2 2/2] arm64: dts: qcom: sc7280: Drop aggre{1,2}_noc QOS clocks on Herobrine

[Brian Norris]

Hi Konrad,

On Tue, Feb 17, 2026 at 11:46:19AM +0100, Konrad Dybcio wrote:
> On 1/9/26 1:33 AM, Brian Norris wrote:
> > Hi Konrad,
> > 
> > On Fri, Sep 12, 2025 at 12:37:29PM -0700, Brian Norris wrote:
> >> On Fri, Sep 12, 2025 at 03:10:16PM +0200, Konrad Dybcio wrote:
> >>> As I attempt to find a board that would boot with your sw stack,
> >>> could I ask you to check if commenting any of the three writes in
> >>>
> >>> drivers/interconnect/qcom/icc-rpmh.c : qcom_icc_set_qos()
> >>>
> >>> specifically causes the crash?
> >>>
> >>> FWIW they're supposed to be independent so you don't have to test
> >>> all possible combinations
> >>
> >> It seems as if any one of them will cause the crash. I had to comment
> >> out all 3 to avoid crashing.
> > 
> > I'm curious if you had any follow-up here. Are you still looking for an
> > alternative to this patch?
> 
> Sorry Brian, it seems like all the "ready to grab" firmware image links
> for this platform are dead where I would normally look, which prevented
> me from being able to poke at this..

I'll say, I'm not really surprised. The firmware here is probably not in
any maintained nor widely used state.

> Would there happen to be another place where I can grab them from,
> perhaps some CrOS CI?

I don't really know of one right now. I expect the CI is not active.

To speak practically here: there are likely no real users of this
development board, and if I'm the only one actively trying to use it
with upstream Linux as a development vehicle, I can simply carry this
change locally. It's probably not worth a lot of people bending over
backward for it, unless I'm wrong and there are more people using it. I
was just hopeful that I could reduce some friction for myself, and the
limited (possibly zero) population who might also run into problems
here.

Unless you really want to move forward, I'll move this from my mental
back burner to cold storage :)

Thanks for your time,
Brian

Re: [PATCH v2 2/2] arm64: dts: qcom: sc7280: Drop aggre{1,2}_noc QOS clocks on Herobrine

[Konrad Dybcio]

On 3/2/26 10:31 PM, Brian Norris wrote:
> Hi Konrad,
> 
> On Tue, Feb 17, 2026 at 11:46:19AM +0100, Konrad Dybcio wrote:
>> On 1/9/26 1:33 AM, Brian Norris wrote:
>>> Hi Konrad,
>>>
>>> On Fri, Sep 12, 2025 at 12:37:29PM -0700, Brian Norris wrote:
>>>> On Fri, Sep 12, 2025 at 03:10:16PM +0200, Konrad Dybcio wrote:
>>>>> As I attempt to find a board that would boot with your sw stack,
>>>>> could I ask you to check if commenting any of the three writes in
>>>>>
>>>>> drivers/interconnect/qcom/icc-rpmh.c : qcom_icc_set_qos()
>>>>>
>>>>> specifically causes the crash?
>>>>>
>>>>> FWIW they're supposed to be independent so you don't have to test
>>>>> all possible combinations
>>>>
>>>> It seems as if any one of them will cause the crash. I had to comment
>>>> out all 3 to avoid crashing.
>>>
>>> I'm curious if you had any follow-up here. Are you still looking for an
>>> alternative to this patch?
>>
>> Sorry Brian, it seems like all the "ready to grab" firmware image links
>> for this platform are dead where I would normally look, which prevented
>> me from being able to poke at this..
> 
> I'll say, I'm not really surprised. The firmware here is probably not in
> any maintained nor widely used state.
> 
>> Would there happen to be another place where I can grab them from,
>> perhaps some CrOS CI?
> 
> I don't really know of one right now. I expect the CI is not active.
> 
> To speak practically here: there are likely no real users of this
> development board, and if I'm the only one actively trying to use it
> with upstream Linux as a development vehicle, I can simply carry this
> change locally. It's probably not worth a lot of people bending over
> backward for it, unless I'm wrong and there are more people using it. I
> was just hopeful that I could reduce some friction for myself, and the
> limited (possibly zero) population who might also run into problems
> here.
> 
> Unless you really want to move forward, I'll move this from my mental
> back burner to cold storage :)

I'd really like to get to the bottom of this, especially since TF-A
support for this SoC lives on.. +Jorge & Sumit who are working on this
maybe you can repro/find the culprit

Konrad