[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <03524012-0f88-4990-811e-1e76c2b8e7af@broadcom.com>
Date: Wed, 14 Aug 2024 12:48:42 -0700
From: Florian Fainelli <florian.fainelli@...adcom.com>
To: Stefan Wahren <wahrenst@....net>,
Naresh Kamboju <naresh.kamboju@...aro.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>, open list <linux-kernel@...r.kernel.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
lkft-triage@...ts.linaro.org, Linux Regressions <regressions@...ts.linux.dev>
Cc: krzk+dt@...nel.org, Rob Herring <robh@...nel.org>,
Arnd Bergmann <arnd@...db.de>, Dan Carpenter <dan.carpenter@...aro.org>,
Anders Roxell <anders.roxell@...aro.org>
Subject: Re: next-20240814: bcm2711-rpi-4-b boot failed
On 8/14/24 09:19, Stefan Wahren wrote:
> Hi Naresh,
>
> Am 14.08.24 um 17:26 schrieb Naresh Kamboju:
>> On Wed, 14 Aug 2024 at 20:54, Naresh Kamboju
>> <naresh.kamboju@...aro.org> wrote:
>>> The arm64 kernel booting on bcm2711-rpi-4-b boot failed with today's
>>> Linux
>>> next-20240814 tag. The boot failed with half boot log [1]
>>>
>>> Reported-by: Linux Kernel Functional Testing <lkft@...aro.org>
>>>
>>> GOOD: next-20240813
>>> BAD: next-20240814
>>>
>>> The first investigation show the following to changes and I have
>>> reverted the
>>> following two commits and the boot test is back to pass [2].
>>>
>>> $ git log --oneline next-20240813..next-20240814
>>> arch/arm64/boot/dts/broadcom/
>>> 6e7b99d720da6 ARM: dts: bcm271x: add missing properties to local_intc
>>> eb81f43c901ff ARM: dts: bcm2837/bcm2712: adjust local intc node names
>>>
>> Anders bisected down to first bad commit as,
>> 6e7b99d720da ("ARM: dts: bcm271x: add missing properties to
>> local_intc")
> thank you for the report and sorry about that mess. I don't why i was
> under the impression they were harmless DT properties. I look into this,
> so a revert is the proper solution for now.
Without the 'interrupt-controller' of_irq_init() would not be picking up
the interrupt-controller@...00000 node and it would not attempt to
register the driver. We can see that the GIC is still the primary
interrupt controller for that system:
[ 0.000000] Root IRQ handler: gic_handle_irq
my suspicion here is that irq-bcm2836.c still wants to own the inter
processor operations and calls set_smp_ipi_range() which then replaces
what the GIC has installed, thus diverting all interrupts towards
itself, when it should not, and that won't work as there is no
coordination with the ARM GIC driver. Stefan do you know how the VPU
decides between one interrupt controller versus the other, assuming
there is even a choice offered to users? Is it via adding/removing the
'interrupt-controller' property, or is it via the more conventional
'status' property?
FWIW, I did changes back in the days to support the 7211 sister chip of
2711:
https://lore.kernel.org/lkml/20191015185919.GA26464@bogus/T/
Dropping the patch for now, thanks!
--
Florian
Powered by blists - more mailing lists