- 01 Apr, 2020 1 commit
-
-
Andre Przywara authored
The plat_helpers.S file was almost identical between its RPi3 and RPi4 versions. Unify the two files, moving it into the common/ directory. This adds a plat_rpi_get_model() function, which can be used to trigger RPi4 specific action, detected at runtime. We use that to do the RPi4 specific L2 cache initialisation. Change-Id: I2295704fd6dde7c76fe83b6d98c7bf998d4bf074 Signed-off-by:Andre Przywara <andre.przywara@arm.com>
-
- 17 Mar, 2020 2 commits
-
-
Andre Przywara authored
The Broadcom 283x SoCs feature multiple UARTs: the mostly used "Mini-UART", which is an 8250 compatible IP, and at least one PL011. While the 8250 is usually used for serial console purposes, it suffers from a design flaw, where its clock depends on the VPU clock, which can change at runtime. This will reliably mess up the baud rate. To avoid this problem, people might choose to use the PL011 UART for the serial console, which is pin-mux'ed to the very same GPIO pins. This can be done by adding "miniuart-bt" to the "dtoverlay=" line in config.txt. To prepare for this situation, use the newly gained freedom of sharing one console_t pointer across different UART drivers, to introduce the option of choosing the PL011 for the console. This is for now hard-coded to choose the Mini-UART by default. A follow-up patch will introduce automatic detection. Signed-off-by: -
Andre Przywara authored
In the wake of the upcoming unification of the console setup code between RPi3 and RPi4, extend the "clock-less" setup scheme to the RPi3. This avoid programming any clocks or baud rate registers, which makes the port more robust against GPU firmware changes. Signed-off-by:
-
- 30 Dec, 2019 1 commit
-
-
Andre Przywara authored
So far we have seen two different clock setups for the Raspberry Pi 4 board, with the VPU clock divider being different. This was handled by reading the divider register and adjusting the base clock rate accordingly. Recently a new GPU firmware version appeared that changed the clock rate *again*, though this time at a higher level, so the VPU rate (and the apparent PLLC parent clock) did not seem to change, judging by reading the clock registers. So rather than playing cat and mouse with the GPU firmware or going further down the rabbit hole of exploring the whole clock tree, let's just skip the baud rate programming altogether. This works because the GPU firmware actually sets up and programs the debug UART already, so we can just use it. Pass 0 as the base clock rate to let the console driver skip the setup, also remove the no longer needed clock code. Signed-off-by:
-
- 25 Sep, 2019 3 commits
-
-
Andre Przywara authored
Now that we have the SMP pens in the first page of DRAM, we can get rid of all the fancy RPi3 memory regions that our RPi4 port does not really need. This avoids using up memory all over the place, restricting ATF to just run in the first 512KB of DRAM. Remove the now unused regions. This also moves the SMP pens into our first memory page (holding the firmware magic), where the original firmware put them, but where there is also enough space for them. Since the pens will require code execution privileges, we amend the memory attributes used for that page to include write and execution rights. Change-Id: I131633abeb4a4d7b9057e737b9b0d163b73e47c6 Signed-off-by: -
Andre Przywara authored
The Raspberry Pi GPU firmware checks for a magic value at offset 240 (0xf0) of the armstub8.bin image it loads. If that value matches, it writes the kernel load address and the DTB address into subsequent memory locations. We can use these addresses to avoid hardcoding these values into the BL31 image, to make it more flexible and a drop-in replacement for the official armstub8.bin. Reserving just 16 bytes at offset 240 of the final image file is not easily possible, though, as this location is in the middle of the generic BL31 entry point code. However we can prepend an extra section before the actual BL31 image, to contain the magic and addresses. This needs to be 4KB, because the actual BL31 entry point needs to be page aligned. Use the platform linker script hook that the generic code provides, to add an almost empty 4KB code block before the entry point code. The very first word contains a branch instruction to jump over this page, into the actual entry code. This also gives us plenty of room for the SMP pens later. Change-Id: I38caa5e7195fa39cbef8600933a03d86f09263d6 Signed-off-by: -
Andre Przywara authored
The Raspberry Pi 4 is a single board computer with four Cortex-A72 cores. From a TF-A perspective it is quite similar to the Raspberry Pi 3, although it comes with more memory (up to 4GB) and has a GIC. This initial port though differs quite a lot from the existing rpi3 platform port, mainly due to taking a much simpler and more robust approach to loading the non-secure payload: The GPU firmware of the SoC, which is responsible for initial platform setup (including DRAM initialisation), already loads the kernel, device tree and the "armstub" into DRAM. We take advantage of this, by placing just a BL31 component into the armstub8.bin component, which will be executed first, in AArch64 EL3. The non-secure payload can be a kernel or a boot loader (U-Boot or EDK-2), disguised as the "kernel" image and loaded by the GPU firmware. So this is just a BL31-only port, which directly drops into EL2 and executes whatever has been loaded as the "kernel" image, handing over the DTB address in x0. Change-Id: I636f4d1f661821566ad9e341d69ba36f6bbfb546 Signed-off-by:
-
