ARM platforms: Add support for SEPARATE_CODE_AND_RODATA
The arm_setup_page_tables() function used to expect a single set of
addresses defining the extents of the whole read-only section, code
and read-only data mixed up, which was mapped as executable.
This patch changes this behaviour. arm_setup_page_tables() now
expects 2 separate sets of addresses:
- the extents of the code section;
- the extents of the read-only data section.
The code is mapped as executable, whereas the data is mapped as
execute-never. New #defines have been introduced to identify the
extents of the code and the read-only data section. Given that
all BL images except BL1 share the same memory layout and linker
script structure, these #defines are common across these images.
The slight memory layout differences in BL1 have been handled by
providing values specific to BL1.
Note that this patch also affects the Xilinx platform port, which
uses the arm_setup_page_tables() function. It has been updated
accordingly, such that the memory mappings on this platform are
unchanged. This is achieved by passing null values as the extents
of the read-only data section so that it is ignored. As a result,
the whole read-only section is still mapped as executable.
Fixes ARM-software/tf-issues#85
Change-Id: I1f95865c53ce6e253a01286ff56e0aa1161abac5
diff --git a/include/plat/common/common_def.h b/include/plat/common/common_def.h
index 9fac9fa..d6b7772 100644
--- a/include/plat/common/common_def.h
+++ b/include/plat/common/common_def.h
@@ -80,5 +80,44 @@
.ep_info.pc = BL2_BASE, \
}
-#endif /* __COMMON_DEF_H__ */
+/*
+ * The following constants identify the extents of the code & read-only data
+ * regions. These addresses are used by the MMU setup code and therefore they
+ * must be page-aligned.
+ *
+ * When the code and read-only data are mapped as a single atomic section
+ * (i.e. when SEPARATE_CODE_AND_RODATA=0) then we treat the whole section as
+ * code by specifying the read-only data section as empty.
+ *
+ * BL1 is different than the other images in the sense that its read-write data
+ * originally lives in Trusted ROM and needs to be relocated in Trusted SRAM at
+ * run-time. Therefore, the read-write data in ROM can be mapped with the same
+ * memory attributes as the read-only data region. For this reason, BL1 uses
+ * different macros.
+ *
+ * Note that BL1_ROM_END is not necessarily aligned on a page boundary as it
+ * just points to the end of BL1's actual content in Trusted ROM. Therefore it
+ * needs to be rounded up to the next page size in order to map the whole last
+ * page of it with the right memory attributes.
+ */
+#if SEPARATE_CODE_AND_RODATA
+#define BL_CODE_BASE (unsigned long)(&__TEXT_START__)
+#define BL_CODE_LIMIT (unsigned long)(&__TEXT_END__)
+#define BL_RO_DATA_BASE (unsigned long)(&__RODATA_START__)
+#define BL_RO_DATA_LIMIT (unsigned long)(&__RODATA_END__)
+
+#define BL1_CODE_LIMIT BL_CODE_LIMIT
+#define BL1_RO_DATA_BASE (unsigned long)(&__RODATA_START__)
+#define BL1_RO_DATA_LIMIT round_up(BL1_ROM_END, PAGE_SIZE)
+#else
+#define BL_CODE_BASE (unsigned long)(&__RO_START__)
+#define BL_CODE_LIMIT (unsigned long)(&__RO_END__)
+#define BL_RO_DATA_BASE 0
+#define BL_RO_DATA_LIMIT 0
+#define BL1_CODE_LIMIT round_up(BL1_ROM_END, PAGE_SIZE)
+#define BL1_RO_DATA_BASE 0
+#define BL1_RO_DATA_LIMIT 0
+#endif /* SEPARATE_CODE_AND_RODATA */
+
+#endif /* __COMMON_DEF_H__ */