On Fri, Aug 05, 2016 at 12:14:23PM -0400, Andrew Bradford wrote:
> From: Andrew Bradford <andrew.bradf...@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.bradf...@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
> +#endifSo, 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! -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
