[PATCH RFC] ARM: dts: bcm2711: Fix DMA constrains for newer BCM2711 boards
Stefan Wahren
stefan.wahren at i2se.com
Thu May 19 11:48:57 PDT 2022
Am 18.05.22 um 22:18 schrieb Florian Fainelli:
>
>
> On 5/4/2022 2:43 PM, Stefan Wahren wrote:
>> Hi,
>>
>> Am 13.04.22 um 18:27 schrieb Stefan Wahren:
>>> The commit 3d2cbb644836 ("ARM: dts: bcm2711: Move emmc2 into its own
>>> bus")
>>> assumed that all bootloader pass the FDT modified by the firmware to
>>> the
>>> kernel. But this is not always the case (e.g. Fedora) and cause boot
>>> issues for boards with a BCM2711 C0 SoC (RPi 400, CM4, newer RPi 4 B)
>>> which does have different DMA constraints.
>>>
>>> Since we are not able to detect the SoC revision, let's assume a
>>> BCM2711
>>> C0 SoC for bcm2711.dtsi and move the restricted DMA constrains to a
>>> separate RPi 4 B board file just for the old SoC revision.
>>>
>>> Fixes: 3d2cbb644836 ("ARM: dts: bcm2711: Move emmc2 into its own bus")
>>> Signed-off-by: Stefan Wahren <stefan.wahren at i2se.com>
>> since there wasn't any feedback yet, i want to ping ...
>
> Could not we just rely on the VPU patching the Device Tree instead of
> having to differentiate the 2711 revision and having to use different
> DTS/DTBs?
As long as every bootloader in the boot chain take care everything is
fine. The problem is the VPU firmware is closed source, so only a few
people knows about the hardware differences. So the idea was to make it
more transparent and yes i'm also not happy with this patch.
>
> Also, can we consider that the older B0 are less predominant in the
> wild than the C0 nowadays, especially with the shortages going on is
> that even remotely the case?
So your idea is to make C0 the default and let the firmware patch the B0
part? I must confess that i never tested this.
More information about the linux-arm-kernel
mailing list