- 17 Mar, 2020 2 commits
-
-
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
-
Andre Przywara authored
There is really no reason to use and pass around a struct when its only member is the (fixed) base address. Remove the struct and just use the base address on its own inside the GPIO driver. Then set the base address automatically. This simplifies GPIO setup for users, which now don't need to deal with zeroing a struct and setting the base address anymore. Change-Id: I3060f7859e3f8ef9a24cc8fb38307b5da943f127 Signed-off-by: Andre Przywara <andre.przywara@arm.com>
-
- 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 7 commits
-
-
Andre Przywara authored
To initialise the arch timer configuration and some clock prescaler, we need to do two MMIO access *once*, early during boot. As tempting as it may sound, plat_reset_handler() is not the right place to do this, as it will be called on every CPU coming up, both for secondary cores as well as during warmboots. So this access will be done multiple times, and even during a rich OS' runtime. Whether doing so anyway is actually harmful is hard to say, but we should definitely avoid this if possible. Move the initialisation of these registers to C code in bl1_early_platform_setup(), where it will still be executed early enough (before enabling the console), but only once during the whole boot process. Change-Id: I081c41a5476d424411411488ff8f633e87d3bcc5 Signed-off-by: Andre Przywara <andre.przywara@arm.com>
-
Andre Przywara authored
To allow sharing the driver between the RPi3 and RPi4, move the random number generator driver into the generic driver directory. Change-Id: Iae94d7cb22c6bce3af9bff709d76d4caf87b14d1 Signed-off-by: Andre Przywara <andre.przywara@arm.com>
-
Andre Przywara authored
With the incoming support for the Raspberry Pi 4 boards, one directory to serve both versions will not end up well. Create an additional layer by inserting a "rpi" directory betweeen /plat and rpi3, so that we can more easily share or separate files between the two later. Change-Id: I75adbb054fe7902f34db0fd5e579a55612dd8a5f Signed-off-by: Andre Przywara <andre.przywara@arm.com>
-
Andre Przywara authored
To allow sharing the driver between the RPi3 and RPi4, move the mailbox driver into the generic driver directory. Change-Id: I463e49acf82b02bf004f3d56482b7791f3020bc0 Signed-off-by: Andre Przywara <andre.przywara@arm.com>
-
Andre Przywara authored
With the advent of Raspberry Pi 4 support, we need to separate some board specific headers between the RPi3 and RPi4. Rename and move the "rpi3_hw.h" header, so that .c files just include rpi_hw.h, and automatically get the correct version. Change-Id: I03b39063028d2bee1429bffccde71dddfe2dcde8 Signed-off-by: Andre Przywara <andre.przywara@arm.com>
-
Andre Przywara authored
The location of the MMIO window is different between a Raspberry Pi 3 and 4: the former has it just below 1GB, the latter below 4GB. The relative location of the peripherals is mostly compatible though. To allow sharing code between the two models, let's rename the symbol used for the MMIO base to the more generic RPI_IO_BASE name. Change-Id: I3c2762fb30fd56cca743348e79d72ef8c60ddb03 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>
-