[U-Boot] [PATCH] arm: omap5: am57/dra7: Fix SRAM_SCRATCH_SPACE_ADDR and SRAM_ROM_VECT_BASE
From: Andrew Bradford andrew.bradford@kodakalaris.com
Both am57xx and dra7xx have 512 kiB of SRAM and the mapping within that SRAM is the same as omap5 (which has only 128 kiB) except for a much larger "Download image" area. So, fix am57xx and dra7xx location for SRAM_SCRATCH_SPACE_ADDR to mimmic omap5's locating of this area to a memory region defined by the TRM as "Reserved" immediately following the "Download image" region and fix the ROM code interrupt vector address SRAM_ROM_VECT_BASE to properly match the TRM.
Signed-off-by: Andrew Bradford andrew.bradford@kodakalaris.com --- arch/arm/include/asm/arch-omap5/omap.h | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/arm/include/asm/arch-omap5/omap.h b/arch/arm/include/asm/arch-omap5/omap.h index 2fd5cda..b9e4783 100644 --- a/arch/arm/include/asm/arch-omap5/omap.h +++ b/arch/arm/include/asm/arch-omap5/omap.h @@ -179,21 +179,19 @@ struct s32ktimer { * and indicates the area for the downloaded image. We use all of that * space for download and once up and running may use other parts of the * map for our needs. We set a scratch space that is at the end of the - * OMAP5 download area, but within the DRA7xx download area (as it is - * much larger) and do not, at this time, make use of the additional - * space. + * download area in an area marked reserved in the TRM. */ #if defined(CONFIG_DRA7XX) || defined(CONFIG_AM57XX) #define NON_SECURE_SRAM_START 0x40300000 #define NON_SECURE_SRAM_END 0x40380000 /* Not inclusive */ +#define SRAM_SCRATCH_SPACE_ADDR 0x4037E000 +#define SRAM_ROM_VECT_BASE 0x4037F000 #else #define NON_SECURE_SRAM_START 0x40300000 #define NON_SECURE_SRAM_END 0x40320000 /* Not inclusive */ -#endif #define SRAM_SCRATCH_SPACE_ADDR 0x4031E000 - -/* base address for indirect vectors (internal boot mode) */ #define SRAM_ROM_VECT_BASE 0x4031F000 +#endif
/* CONTROL_SRCOMP_XXX_SIDE */ #define OVERRIDE_XS_SHIFT 30
On Fri, Aug 05, 2016 at 12:14:23PM -0400, Andrew Bradford wrote:
From: Andrew Bradford andrew.bradford@kodakalaris.com
Both am57xx and dra7xx have 512 kiB of SRAM and the mapping within that SRAM is the same as omap5 (which has only 128 kiB) except for a much larger "Download image" area. So, fix am57xx and dra7xx location for SRAM_SCRATCH_SPACE_ADDR to mimmic omap5's locating of this area to a memory region defined by the TRM as "Reserved" immediately following the "Download image" region and fix the ROM code interrupt vector address SRAM_ROM_VECT_BASE to properly match the TRM.
Signed-off-by: Andrew Bradford andrew.bradford@kodakalaris.com
arch/arm/include/asm/arch-omap5/omap.h | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/arm/include/asm/arch-omap5/omap.h b/arch/arm/include/asm/arch-omap5/omap.h index 2fd5cda..b9e4783 100644 --- a/arch/arm/include/asm/arch-omap5/omap.h +++ b/arch/arm/include/asm/arch-omap5/omap.h @@ -179,21 +179,19 @@ struct s32ktimer {
- and indicates the area for the downloaded image. We use all of that
- space for download and once up and running may use other parts of the
- map for our needs. We set a scratch space that is at the end of the
- OMAP5 download area, but within the DRA7xx download area (as it is
- much larger) and do not, at this time, make use of the additional
- space.
*/
- download area in an area marked reserved in the TRM.
#if defined(CONFIG_DRA7XX) || defined(CONFIG_AM57XX) #define NON_SECURE_SRAM_START 0x40300000 #define NON_SECURE_SRAM_END 0x40380000 /* Not inclusive */ +#define SRAM_SCRATCH_SPACE_ADDR 0x4037E000 +#define SRAM_ROM_VECT_BASE 0x4037F000 #else #define NON_SECURE_SRAM_START 0x40300000 #define NON_SECURE_SRAM_END 0x40320000 /* Not inclusive */ -#endif #define SRAM_SCRATCH_SPACE_ADDR 0x4031E000
-/* base address for indirect vectors (internal boot mode) */ #define SRAM_ROM_VECT_BASE 0x4031F000 +#endif
So, this is totally following existing examples. But on further review, I don't like the existing examples, which, hey, is my fault, I wrote them. I don't like that mostly we put the scratch space into a "reserved" area (which may or may not trample ROM and that could be bad in some corner cases). Looking things over, we claim we need a maximum of 0x228 bytes of scratch space and we currently use more like 0x8a bytes of it. However, depending on the platform we are on, we may claim between 8 and 32 KiB for all of this. And stack in SPL is elsewhere in these defines and not a worry. I'm build testing a patch now and will boot test it on a good subset of the hardware before posting that should address all of this. Thanks for bringing it up!
participants (2)
-
Andrew Bradford -
Tom Rini