diff mbox

arm, omap2, sram: On HS/EMU devices, only 64K internal SRAM is available.

Message ID 1444715655-30077-1-git-send-email-hs@denx.de (mailing list archive)
State New, archived
Headers show

Commit Message

Heiko Schocher Oct. 13, 2015, 5:54 a.m. UTC
Of this, secure content (including PPA) uses initial
portion of the SRAM. This chunk is not (and shouldn't
be) accessible from the public code.

The minimum size of this chunk (0x350) is used in this
patch. Available size is rounded off to 63K.

Both values would require a change if size of secure
content grows beyond 0x350.

Signed-off-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Ayoub Zaki <Ayoub.Zaki@bosch-si.com>
---

 arch/arm/mach-omap2/sram.c | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

Comments

Tony Lindgren Oct. 14, 2015, 5:49 p.m. UTC | #1
* Heiko Schocher <hs@denx.de> [151012 22:58]:
> Of this, secure content (including PPA) uses initial
> portion of the SRAM. This chunk is not (and shouldn't
> be) accessible from the public code.
> 
> The minimum size of this chunk (0x350) is used in this
> patch. Available size is rounded off to 63K.
> 
> Both values would require a change if size of secure
> content grows beyond 0x350.

Makes sense to me. And something similar is needed at least for
dm814x to get rid of the imprecise abort during boot with
commit bbeb92095159 ("ARM: 8422/1: enable imprecise aborts during
early kernel startup") applied.

Is this needed as a fix to the -rc cycle, or can this wait for
v4.4?

Regards,

Tony


> Signed-off-by: Heiko Schocher <hs@denx.de>
> Signed-off-by: Ayoub Zaki <Ayoub.Zaki@bosch-si.com>
> ---
> 
>  arch/arm/mach-omap2/sram.c | 25 +++++++++++++++++++++++++
>  1 file changed, 25 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/sram.c b/arch/arm/mach-omap2/sram.c
> index cd488b8..2e7c00f 100644
> --- a/arch/arm/mach-omap2/sram.c
> +++ b/arch/arm/mach-omap2/sram.c
> @@ -47,6 +47,28 @@
>  
>  #define GP_DEVICE		0x300
>  
> +/**
> + * Size of chunk used by secure content in the HS/EMU devices.
> + *
> + * This size is not fixed. It depends upon the implementation of PPA.
> + * May need to be modified if the size grows.
> + */
> +#define AM33XX_HS_HEADER_SIZE   0x0350
> +
> +/**
> + * Start of public SRAM on HS/EMU devices.
> + */
> +#define AM33XX_SRAM_PA		0x40300000
> +#define AM33XX_SRAM_PUB_PA	(AM33XX_SRAM_PA + AM33XX_HS_HEADER_SIZE)
> +
> +/**
> + * Size of public SRAM available on HS/EMU devices.
> + *
> + * This size also depends upon AM33XX_HS_HEADER_SIZE.
> + * Current value is derived from nearest round-off.
> + */
> +#define AM33XX_SRAM_PUB_SIZE		0xfc00	/* 63K */
> +
>  #define ROUND_DOWN(value,boundary)	((value) & (~((boundary)-1)))
>  
>  static unsigned long omap_sram_start;
> @@ -99,6 +121,9 @@ static void __init omap_detect_sram(void)
>  			} else {
>  				omap_sram_size = 0x8000; /* 32K */
>  			}
> +		} else if (soc_is_am33xx()) {
> +			omap_sram_start = AM33XX_SRAM_PUB_PA;
> +			omap_sram_size  = AM33XX_SRAM_PUB_SIZE;
>  		} else {
>  			omap_sram_start = OMAP2_SRAM_PUB_PA;
>  			omap_sram_size = 0x800; /* 2K */
> -- 
> 2.1.0
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tony Lindgren Oct. 14, 2015, 10:20 p.m. UTC | #2
* Tony Lindgren <tony@atomide.com> [151014 10:56]:
> * Heiko Schocher <hs@denx.de> [151012 22:58]:
> > Of this, secure content (including PPA) uses initial
> > portion of the SRAM. This chunk is not (and shouldn't
> > be) accessible from the public code.
> > 
> > The minimum size of this chunk (0x350) is used in this
> > patch. Available size is rounded off to 63K.
> > 
> > Both values would require a change if size of secure
> > content grows beyond 0x350.
> 
> Makes sense to me. And something similar is needed at least for
> dm814x to get rid of the imprecise abort during boot with
> commit bbeb92095159 ("ARM: 8422/1: enable imprecise aborts during
> early kernel startup") applied.
>
> Is this needed as a fix to the -rc cycle, or can this wait for
> v4.4?

Actually I think we may have a regression somwhere. If you look
at commit 8b9a2810b02e ("ARM: OMAP4+: Move SRAM data to DT")
this should all be handled by drivers/misc/sram.c nowadays.

So for most SoCs, we should completely skip the plat-omap/sram.c
code.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Heiko Schocher Oct. 15, 2015, 3:57 a.m. UTC | #3
Hello Tony,

Am 14.10.2015 um 19:49 schrieb Tony Lindgren:
> * Heiko Schocher <hs@denx.de> [151012 22:58]:
>> Of this, secure content (including PPA) uses initial
>> portion of the SRAM. This chunk is not (and shouldn't
>> be) accessible from the public code.
>>
>> The minimum size of this chunk (0x350) is used in this
>> patch. Available size is rounded off to 63K.
>>
>> Both values would require a change if size of secure
>> content grows beyond 0x350.
>
> Makes sense to me. And something similar is needed at least for
> dm814x to get rid of the imprecise abort during boot with
> commit bbeb92095159 ("ARM: 8422/1: enable imprecise aborts during
> early kernel startup") applied.
>
> Is this needed as a fix to the -rc cycle, or can this wait for
> v4.4?

I need it for an upcoming boards support, so 4.4 is fine for me,
thanks!

bye,
Heiko
>
> Regards,
>
> Tony
>
>
>> Signed-off-by: Heiko Schocher <hs@denx.de>
>> Signed-off-by: Ayoub Zaki <Ayoub.Zaki@bosch-si.com>
>> ---
>>
>>   arch/arm/mach-omap2/sram.c | 25 +++++++++++++++++++++++++
>>   1 file changed, 25 insertions(+)
>>
>> diff --git a/arch/arm/mach-omap2/sram.c b/arch/arm/mach-omap2/sram.c
>> index cd488b8..2e7c00f 100644
>> --- a/arch/arm/mach-omap2/sram.c
>> +++ b/arch/arm/mach-omap2/sram.c
>> @@ -47,6 +47,28 @@
>>
>>   #define GP_DEVICE		0x300
>>
>> +/**
>> + * Size of chunk used by secure content in the HS/EMU devices.
>> + *
>> + * This size is not fixed. It depends upon the implementation of PPA.
>> + * May need to be modified if the size grows.
>> + */
>> +#define AM33XX_HS_HEADER_SIZE   0x0350
>> +
>> +/**
>> + * Start of public SRAM on HS/EMU devices.
>> + */
>> +#define AM33XX_SRAM_PA		0x40300000
>> +#define AM33XX_SRAM_PUB_PA	(AM33XX_SRAM_PA + AM33XX_HS_HEADER_SIZE)
>> +
>> +/**
>> + * Size of public SRAM available on HS/EMU devices.
>> + *
>> + * This size also depends upon AM33XX_HS_HEADER_SIZE.
>> + * Current value is derived from nearest round-off.
>> + */
>> +#define AM33XX_SRAM_PUB_SIZE		0xfc00	/* 63K */
>> +
>>   #define ROUND_DOWN(value,boundary)	((value) & (~((boundary)-1)))
>>
>>   static unsigned long omap_sram_start;
>> @@ -99,6 +121,9 @@ static void __init omap_detect_sram(void)
>>   			} else {
>>   				omap_sram_size = 0x8000; /* 32K */
>>   			}
>> +		} else if (soc_is_am33xx()) {
>> +			omap_sram_start = AM33XX_SRAM_PUB_PA;
>> +			omap_sram_size  = AM33XX_SRAM_PUB_SIZE;
>>   		} else {
>>   			omap_sram_start = OMAP2_SRAM_PUB_PA;
>>   			omap_sram_size = 0x800; /* 2K */
>> --
>> 2.1.0
>>
>
Heiko Schocher Oct. 15, 2015, 4:26 a.m. UTC | #4
Hello Tony,

Am 15.10.2015 um 00:20 schrieb Tony Lindgren:
> * Tony Lindgren <tony@atomide.com> [151014 10:56]:
>> * Heiko Schocher <hs@denx.de> [151012 22:58]:
>>> Of this, secure content (including PPA) uses initial
>>> portion of the SRAM. This chunk is not (and shouldn't
>>> be) accessible from the public code.
>>>
>>> The minimum size of this chunk (0x350) is used in this
>>> patch. Available size is rounded off to 63K.
>>>
>>> Both values would require a change if size of secure
>>> content grows beyond 0x350.
>>
>> Makes sense to me. And something similar is needed at least for
>> dm814x to get rid of the imprecise abort during boot with
>> commit bbeb92095159 ("ARM: 8422/1: enable imprecise aborts during
>> early kernel startup") applied.
>>
>> Is this needed as a fix to the -rc cycle, or can this wait for
>> v4.4?
>
> Actually I think we may have a regression somwhere. If you look
> at commit 8b9a2810b02e ("ARM: OMAP4+: Move SRAM data to DT")
> this should all be handled by drivers/misc/sram.c nowadays.
>
> So for most SoCs, we should completely skip the plat-omap/sram.c
> code.

Yes, correct. So it should be enough for changing the DT, thanks.

bye,
Heiko
diff mbox

Patch

diff --git a/arch/arm/mach-omap2/sram.c b/arch/arm/mach-omap2/sram.c
index cd488b8..2e7c00f 100644
--- a/arch/arm/mach-omap2/sram.c
+++ b/arch/arm/mach-omap2/sram.c
@@ -47,6 +47,28 @@ 
 
 #define GP_DEVICE		0x300
 
+/**
+ * Size of chunk used by secure content in the HS/EMU devices.
+ *
+ * This size is not fixed. It depends upon the implementation of PPA.
+ * May need to be modified if the size grows.
+ */
+#define AM33XX_HS_HEADER_SIZE   0x0350
+
+/**
+ * Start of public SRAM on HS/EMU devices.
+ */
+#define AM33XX_SRAM_PA		0x40300000
+#define AM33XX_SRAM_PUB_PA	(AM33XX_SRAM_PA + AM33XX_HS_HEADER_SIZE)
+
+/**
+ * Size of public SRAM available on HS/EMU devices.
+ *
+ * This size also depends upon AM33XX_HS_HEADER_SIZE.
+ * Current value is derived from nearest round-off.
+ */
+#define AM33XX_SRAM_PUB_SIZE		0xfc00	/* 63K */
+
 #define ROUND_DOWN(value,boundary)	((value) & (~((boundary)-1)))
 
 static unsigned long omap_sram_start;
@@ -99,6 +121,9 @@  static void __init omap_detect_sram(void)
 			} else {
 				omap_sram_size = 0x8000; /* 32K */
 			}
+		} else if (soc_is_am33xx()) {
+			omap_sram_start = AM33XX_SRAM_PUB_PA;
+			omap_sram_size  = AM33XX_SRAM_PUB_SIZE;
 		} else {
 			omap_sram_start = OMAP2_SRAM_PUB_PA;
 			omap_sram_size = 0x800; /* 2K */