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
