- 17 Mar, 2020 3 commits
-
-
Andre Przywara authored
The Raspberry Pi has two different UART devices pin-muxed to GPIO 14&15: One ARM PL011 one and the 8250 compatible "Mini-UART". A dtoverlay parameter in config.txt will tell the firmware to switch between the two: it will setup the right clocks and will configure the pinmuxes accordingly. To autodetect the user's choice, we read the pinmux register and check its setting: ALT5 (0x2) means the Mini-UART is used, ALT0 (0x4) points to the PL011. Based on that we select the UART driver to initialise. This will allow console output in any case. Change-Id: I620d3ce68de6c6576599f2a405636020e1fd1376 Signed-off-by: Andre Przywara <andre.przywara@arm.com>
-
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 <andre.przywara@arm.com> Change-Id: I8cf2522151e09ff4ff94a6d396aec6fc4b091a05
-
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: Andre Przywara <andre.przywara@arm.com> Change-Id: Ida83a963bb18a878997e9cbd55f8ceac6a2e1c1f
-
- 25 Feb, 2020 1 commit
-
-
Andre Przywara authored
Since now the generic console_t structure holds the UART base address as well, let's use that generic location and drop the UART driver specific data structure at all. Change-Id: I5c2fe3b6a667acf80c808cfec4a64059a2c9c25f Signed-off-by: Andre Przywara <andre.przywara@arm.com>
-
- 09 Dec, 2019 1 commit
-
-
Jan Kiszka authored
The hooks were populated but the power down left the CPU in limbo-land. What we need to do - until there is a way to actually power off - is to turn off the MMU and enter the spinning loop as if we were cold-booted. This allows the on-call to pick up the CPU again. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Change-Id: Iefc7a58424e3578ad3dd355a7bd6eaba4b412699
-
- 25 Sep, 2019 2 commits
-
-
Andre Przywara authored
Now that we have the armstub magic value in place, the GPU firmware will write the kernel load address (and DTB address) into our special page, so we can always easily access the actual location without hardcoding any addresses into the BL31 image. Make the compile-time defined PRELOADED_BL33_BASE macro optional, and read the BL33 entry point from the magic location, if the macro was not defined. We do the same for the DTB address. This also splits the currently "common" definition of plat_get_ns_image_entrypoint() to be separate between RPi3 and RPi4. Change-Id: I6f26c0adc6fce2df47786b271c490928b4529abb Signed-off-by: Andre Przywara <andre.przywara@arm.com>
-
Andre Przywara authored
At the moment the UART input clock rate is hard coded at compile time. This works as long as the GPU firmware always sets up the same rate, which does not seem to be true for the Raspberry Pi 4. In preparation for being able to change this at runtime, add a base clock parameter to the console setup function. This is still hardcoded for the Raspberry Pi 3. Change-Id: I398bc2f1e9b46f7af9a84cb0b33cbe8e78f2d900 Signed-off-by: Andre Przywara <andre.przywara@arm.com>
-
- 13 Sep, 2019 3 commits
-
-
Andre Przywara authored
As the PSCI "power" management functions for the Raspberry Pi 3 port will be shared with the upcoming RPi4 support, we need to prepare them for dealing with the GIC interrupt controller. Splitting this code just for those simple calls to the generic GIC routines does not seem worthwhile, so just use a #define the protect the GIC code from being included by the existing RPi3 code. Change-Id: Iaca6b0214563852b28ad4a088ec45348ae8be40d Signed-off-by: Andre Przywara <andre.przywara@arm.com>
-
Andre Przywara authored
The existing Raspberry Pi 3 port sports a number of memory regions, which are used for several purposes. The upcoming RPi4 port will not use all of those, so make the SHARED_RAM region optional, by only mapping it if it has actually been defined. This helps to get a cleaner RPi4 port. Change-Id: Id69677b7fb6ed48d9f238854b610896785db8cab Signed-off-by: Andre Przywara <andre.przywara@arm.com>
-
Andre Przywara authored
To be able to share code more easily between the existing Raspberry Pi 3 and the upcoming Raspberry Pi 4 platform, move some code which is not board specific into a "common" directory. Change-Id: I9211ab2d754b040128fac13c2f0a30a5cc8c7f2c Signed-off-by: Andre Przywara <andre.przywara@arm.com>
-