linux-kernel - Re: [PATCH v5 0/4] Add minimal boot support for Raspberry Pi 5

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0a041812-875b-42e3-b303-4d984b0f9a54@gmx.net>
Date: Sat, 1 Jun 2024 10:17:26 +0200
From: Stefan Wahren <wahrenst@....net>
To: Andrea della Porta <andrea.porta@...e.com>, Rob Herring
 <robh@...nel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Conor Dooley <conor+dt@...nel.org>,
 Florian Fainelli <florian.fainelli@...adcom.com>, Ray Jui
 <rjui@...adcom.com>, Scott Branden <sbranden@...adcom.com>,
 Broadcom internal kernel review list
 <bcm-kernel-feedback-list@...adcom.com>, Ulf Hansson
 <ulf.hansson@...aro.org>, Adrian Hunter <adrian.hunter@...el.com>,
 Kamal Dasu <kamal.dasu@...adcom.com>, Al Cooper <alcooperx@...il.com>,
 devicetree@...r.kernel.org, linux-rpi-kernel@...ts.infradead.org,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
 linux-mmc@...r.kernel.org
Subject: Re: [PATCH v5 0/4] Add minimal boot support for Raspberry Pi 5

Hi Andrea,

Am 31.05.24 um 14:59 schrieb Andrea della Porta:
> Hi Stefan,
>
> On 12:00 Fri 31 May     , Stefan Wahren wrote:
>> Hi Andrea,
>>
>> Am 30.05.24 um 12:11 schrieb Andrea della Porta:
>>> Hi,
>>>
>>> This patchset adds minimal support for the Broadcom BCM2712 SoC and for
>>> the on-board SDHCI controller on Broadcom BCM2712 in order to make it
>>> possible to boot (particularly) a Raspberry Pi 5 from SD card and get a
>>> console through uart.
>>> Changes to arm64/defconfig are not needed since the actual options work
>>> as they are.
>>> This work is heavily based on downstream contributions.
>>>
>>> Tested on Tumbleweed substituting the stock kernel with upstream one,
>>> either chainloading uboot+grub+kernel or directly booting the kernel
>>> from 1st stage bootloader. Steps to reproduce:
>>> - prepare an SD card from a Raspberry enabled raw image, mount the first
>>>     FAT partition.
>>> - make sure the FAT partition is big enough to contain the kernel,
>>>     anything bigger than 64Mb is usually enough, depending on your kernel
>>>     config options.
>>> - build the kernel and dtbs making sure that the support for your root
>>>     fs type is compiled as builtin.
>>> - copy the kernel image in your FAT partition overwriting the older one
>>>     (e.g. kernel*.img for Raspberry Pi OS or u-boot.bin for Tumbleweed).
>>> - copy arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b.dtb on FAT partition.
>>> - make sure you have a cmdline.txt file in FAT partition with the
>>>     following content:
>>>     # cat /boot/efi/cmdline.txt
>>>     root=/dev/mmcblk0p3 rootwait rw console=tty ignore_loglevel earlycon
>>>     console=ttyAMA10,115200
>>> - if you experience random SD issues during boot, try to set
>>>     initial_turbo=0 in config.txt.
>> was this an issue since the beginning of this series?
>>
> I experienced this even during early testing, using the complete downstream
> driver. It seems that when initual_turbo != 0, the fw can throttle the clock
> to reduce the boot time and it (directly or indirectly) may affect SD functionality.
> I believe that the probability of this to happen is likely a function of SD
> card speed, whether it requires timing tuning, initial_turbo exact value  and whether
> you are booting the kernel directly or chainloading u-boot + grub (or
> whatever combination of secondary stage bootloader). For example, your
> boot setup may have a timeout in the grub boot menu that is large enough for the clocks
> to settle and the boot process to end successfully, while faster boot time can lead
> to the issue described. Since this behaviour seems to depend on all of this factors and
> does not necessarily arise in practice, disabling initial_turbo is just a suggestion
> in case things go haywire.
yes in case the VPU changes the SD clock or one of the parent while the
ARM cores tries to boot, they won't be informed about these changes
which could ends up with the wrong SD clock frequency.

Thanks for your explanations
>
>> What kind of SD issues?
>>
> I wasn't able to boot from SD card due to clock issues.
>
>> Is there a downstream reference?
> Some (old) reference e.g.:
> https://forums.raspberrypi.com/viewtopic.php?t=112480#:~:text=It%20sets%20turbo%20mode%20from,have%20turbo%20during%20the%20boot.
>
> but there are probably more.
>
> Many thanks,
> Andrea