|author||Andre Przywara <email@example.com>||2016-05-01 22:48:02 +0100|
|committer||Andre Przywara <firstname.lastname@example.org>||2016-06-02 01:29:47 +0100|
sun50i: move ATF into SRAM A2
On some boards there are issues with SRAM C, so we move ATF to run from SRAM A2 for now. It actually gives us > 32KB of working space, so a debug version works here as well. SRAM A2 is documented to be secure only, which seems like a good fit for secure monitor runtime code. But apparently this is not really true, since it's still accessible for the non-secure side. Also SRAM A2 is tighly coupled to the arisc (OpenRISC controller) and thus not the ideal place to be hogged with ARM code. Signed-off-by: Andre Przywara <email@example.com>
1 files changed, 8 insertions, 6 deletions
diff --git a/plat/sun50iw1p1/sunxi_def.h b/plat/sun50iw1p1/sunxi_def.h
index 024d6d8..e8825c5 100644
@@ -62,13 +62,15 @@
#define SUNXI_MAX_DRAM_SIZE (2ull<<30) /*2G*/
- * This puts ATF into SRAM C. The first 32KB (@0x18000) are used by FEL to
- * hold the FEL stack backups, so leave this free and start after that.
- * On my board some memory later in SRAM C was unreliable, so having it
- * compiled with DEBUG=1 showed weird errors. It should be checked if this
- * just a faulty SoC I have, and if, how wide spread this bug is.
+ * This puts ATF into SRAM A2. The first 16KB (@0x40000) are used by the
+ * OpenRISC exception vectors and are actually only sparsely implemented
+ * to match the OpenRISC vector table layout (one word every 256 Bytes).
+ * According to the manual SRAM A2 should be hardwired to be secure only,
+ * but this is apparently not true.
+ * This SRAM is tightly coupled to the OpenRISC controller, so it's not the
+ * ideal place to put ATF into, but worked better than SRAM C for me.
-#define SUNXI_TRUSTED_MONITOR_BASE 0x00020000 /* 32KB into SRAM C */
+#define SUNXI_TRUSTED_MONITOR_BASE 0x00044000 /* 16KB into SRAM A2 */
#define SUNXI_TRUSTED_MONITOR_SIZE (64 << 10) /* 64 KByte */
//sec os area