[02/14] ARM: ARMv7M: Enlarge vector table to 256 entries
diff mbox

Message ID 1423763164-5606-3-git-send-email-mcoquelin.stm32@gmail.com
State New
Headers show

Commit Message

Maxime Coquelin Feb. 12, 2015, 5:45 p.m. UTC
From Cortex-M4 and M7 reference manuals, the nvic supports up to 240
interrupts. So the number of entries in vectors table is 256.

This patch adds the missing entries, and change the alignement, so that
vector_table remains naturally aligned.

Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
---
 arch/arm/kernel/entry-v7m.S | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

Comments

Geert Uytterhoeven Feb. 12, 2015, 8:34 p.m. UTC | #1
On Thu, Feb 12, 2015 at 6:45 PM, Maxime Coquelin
<mcoquelin.stm32@gmail.com> wrote:
> From Cortex-M4 and M7 reference manuals, the nvic supports up to 240
> interrupts. So the number of entries in vectors table is 256.
>
> This patch adds the missing entries, and change the alignement, so that
> vector_table remains naturally aligned.

Shouldn't this depend on ARCH_STM32, or some other M4 or M7 specific
Kconfig option, to avoid wasting the space on other CPUs?

>
> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> ---
>  arch/arm/kernel/entry-v7m.S | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/kernel/entry-v7m.S b/arch/arm/kernel/entry-v7m.S
> index 8944f49..29a461b 100644
> --- a/arch/arm/kernel/entry-v7m.S
> +++ b/arch/arm/kernel/entry-v7m.S
> @@ -117,9 +117,9 @@ ENTRY(__switch_to)
>  ENDPROC(__switch_to)
>
>         .data
> -       .align  8
> +       .align  10
>  /*
> - * Vector table (64 words => 256 bytes natural alignment)
> + * Vector table (256 words => 1024 bytes alignment)
>   */
>  ENTRY(vector_table)
>         .long   0                       @ 0 - Reset stack pointer
> @@ -138,6 +138,6 @@ ENTRY(vector_table)
>         .long   __invalid_entry         @ 13 - Reserved
>         .long   __pendsv_entry          @ 14 - PendSV
>         .long   __invalid_entry         @ 15 - SysTick
> -       .rept   64 - 16
> -       .long   __irq_entry             @ 16..64 - External Interrupts
> +       .rept   256 - 16
> +       .long   __irq_entry             @ 16..256 - External Interrupts
>         .endr
> --
> 1.9.1

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Maxime Coquelin Feb. 13, 2015, 8:42 a.m. UTC | #2
Hi Geert,

2015-02-12 21:34 GMT+01:00 Geert Uytterhoeven <geert@linux-m68k.org>:
> On Thu, Feb 12, 2015 at 6:45 PM, Maxime Coquelin
> <mcoquelin.stm32@gmail.com> wrote:
>> From Cortex-M4 and M7 reference manuals, the nvic supports up to 240
>> interrupts. So the number of entries in vectors table is 256.
>>
>> This patch adds the missing entries, and change the alignement, so that
>> vector_table remains naturally aligned.
>
> Shouldn't this depend on ARCH_STM32, or some other M4 or M7 specific
> Kconfig option, to avoid wasting the space on other CPUs?

Actually, the STM32F429 has 90 interrupts, so it would need 106
entries in the vector table.
The maximum of supported interrupts is not only for Cortex-M4 and M7,
this is also true for Cortex-M3.

I see two possibilities:
 1 - We declare the vector table for the maximum supported number of
IRQs, as this patch does.
        - Pro: it will be functionnal with all Cortex-M MCUs
        - Con: Waste of less than 1KB for memory
 2 - We introduce a config flag that provides the number of interrupts
        - Pro: No more memory waste
        - Con: Need to declare a per MCU model config flag.

Then, regarding the natural alignment, is there a way to ensure it
depending on the value of a config flag?
Or we should keep it at the maximum value possible?

Any feedback will be appreciated, especially from Uwe who maintains
the efm32 machine.

Kind regards,
Maxime
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Uwe Kleine-König Feb. 13, 2015, 10 a.m. UTC | #3
On Fri, Feb 13, 2015 at 09:42:46AM +0100, Maxime Coquelin wrote:
> Hi Geert,
> 
> 2015-02-12 21:34 GMT+01:00 Geert Uytterhoeven <geert@linux-m68k.org>:
> > On Thu, Feb 12, 2015 at 6:45 PM, Maxime Coquelin
> > <mcoquelin.stm32@gmail.com> wrote:
> >> From Cortex-M4 and M7 reference manuals, the nvic supports up to 240
> >> interrupts. So the number of entries in vectors table is 256.
> >>
> >> This patch adds the missing entries, and change the alignement, so that
> >> vector_table remains naturally aligned.
> >
> > Shouldn't this depend on ARCH_STM32, or some other M4 or M7 specific
> > Kconfig option, to avoid wasting the space on other CPUs?
> 
> Actually, the STM32F429 has 90 interrupts, so it would need 106
> entries in the vector table.
> The maximum of supported interrupts is not only for Cortex-M4 and M7,
> this is also true for Cortex-M3.
> 
> I see two possibilities:
>  1 - We declare the vector table for the maximum supported number of
> IRQs, as this patch does.
>         - Pro: it will be functionnal with all Cortex-M MCUs
>         - Con: Waste of less than 1KB for memory
>  2 - We introduce a config flag that provides the number of interrupts
>         - Pro: No more memory waste
>         - Con: Need to declare a per MCU model config flag.
I'd vote for 2, something like:

	config CPUV7M_NUM_IRQ
		int
		default 90 if STM32F429
		default 38 if EFM32GG
		default 240

then there is a working default and platforms being short on memory can
configure as appropriate. (The only down side is that if we create
multi-platfrom images at some time in the future either all or none of
the supported platforms must provide a value here.)
 
> Then, regarding the natural alignment, is there a way to ensure it
> depending on the value of a config flag?
The exact wording in ARMARMv7-M is:

	The Vector table must be naturally aligned to a power of two
	whose alignment value is greater than or equal
	to (Number of Exceptions supported x 4), with a minimum
	alignment of 128 bytes.

> Or we should keep it at the maximum value possible?
So we need:

	.align x

with x being max(7, ceil(log((CPUV7M_NUM_IRQ + 16) * 4, 2))). So the
alignment needed is between 7 and 10.

If the assembler supports an expression here I'd use that. But before
adding strange hacks to generate the right value there better go for a
static value like:

	/* The vector table must be naturally aligned */
	#if CONFIG_CPUV7M_NUM_IRQ <= 112
	.align 9 /* log2((112 + 16) * 4) */
	#else
	.align 10
	#endif

Further steps would be:

	CONFIG_CPUV7M_NUM_IRQ <= 48 -> .align 8
	CONFIG_CPUV7M_NUM_IRQ <= 16 -> .align 7

Probably it's not worth to add the respective #ifdefs here.

Best regards
Uwe
Maxime Coquelin Feb. 15, 2015, 2:34 p.m. UTC | #4
2015-02-13 11:00 GMT+01:00 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
> On Fri, Feb 13, 2015 at 09:42:46AM +0100, Maxime Coquelin wrote:
>> Hi Geert,
>>
>> 2015-02-12 21:34 GMT+01:00 Geert Uytterhoeven <geert@linux-m68k.org>:
>> > On Thu, Feb 12, 2015 at 6:45 PM, Maxime Coquelin
>> > <mcoquelin.stm32@gmail.com> wrote:
>> >> From Cortex-M4 and M7 reference manuals, the nvic supports up to 240
>> >> interrupts. So the number of entries in vectors table is 256.
>> >>
>> >> This patch adds the missing entries, and change the alignement, so that
>> >> vector_table remains naturally aligned.
>> >
>> > Shouldn't this depend on ARCH_STM32, or some other M4 or M7 specific
>> > Kconfig option, to avoid wasting the space on other CPUs?
>>
>> Actually, the STM32F429 has 90 interrupts, so it would need 106
>> entries in the vector table.
>> The maximum of supported interrupts is not only for Cortex-M4 and M7,
>> this is also true for Cortex-M3.
>>
>> I see two possibilities:
>>  1 - We declare the vector table for the maximum supported number of
>> IRQs, as this patch does.
>>         - Pro: it will be functionnal with all Cortex-M MCUs
>>         - Con: Waste of less than 1KB for memory
>>  2 - We introduce a config flag that provides the number of interrupts
>>         - Pro: No more memory waste
>>         - Con: Need to declare a per MCU model config flag.
> I'd vote for 2, something like:
>
>         config CPUV7M_NUM_IRQ
>                 int
>                 default 90 if STM32F429
>                 default 38 if EFM32GG
>                 default 240
>
> then there is a working default and platforms being short on memory can
> configure as appropriate. (The only down side is that if we create
> multi-platfrom images at some time in the future either all or none of
> the supported platforms must provide a value here.)

Ok, I'm fine doing this way.
I will implement this in the v2 if Russel is fine with the proposal too.

>
>> Then, regarding the natural alignment, is there a way to ensure it
>> depending on the value of a config flag?
> The exact wording in ARMARMv7-M is:
>
>         The Vector table must be naturally aligned to a power of two
>         whose alignment value is greater than or equal
>         to (Number of Exceptions supported x 4), with a minimum
>         alignment of 128 bytes.
>
>> Or we should keep it at the maximum value possible?
> So we need:
>
>         .align x
>
> with x being max(7, ceil(log((CPUV7M_NUM_IRQ + 16) * 4, 2))). So the
> alignment needed is between 7 and 10.
>
> If the assembler supports an expression here I'd use that. But before
> adding strange hacks to generate the right value there better go for a
> static value like:
>
>         /* The vector table must be naturally aligned */
>         #if CONFIG_CPUV7M_NUM_IRQ <= 112
>         .align 9 /* log2((112 + 16) * 4) */
>         #else
>         .align 10
>         #endif
>
> Further steps would be:
>
>         CONFIG_CPUV7M_NUM_IRQ <= 48 -> .align 8
>         CONFIG_CPUV7M_NUM_IRQ <= 16 -> .align 7
>
> Probably it's not worth to add the respective #ifdefs here.

I will go for the  #ifdefs.

Thanks,
Maxime

>
> Best regards
> Uwe
>
> --
> Pengutronix e.K.                           | Uwe Kleine-König            |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Rob Herring Feb. 15, 2015, 10:42 p.m. UTC | #5
On Fri, Feb 13, 2015 at 2:42 AM, Maxime Coquelin
<mcoquelin.stm32@gmail.com> wrote:
> Hi Geert,
>
> 2015-02-12 21:34 GMT+01:00 Geert Uytterhoeven <geert@linux-m68k.org>:
>> On Thu, Feb 12, 2015 at 6:45 PM, Maxime Coquelin
>> <mcoquelin.stm32@gmail.com> wrote:
>>> From Cortex-M4 and M7 reference manuals, the nvic supports up to 240
>>> interrupts. So the number of entries in vectors table is 256.
>>>
>>> This patch adds the missing entries, and change the alignement, so that
>>> vector_table remains naturally aligned.
>>
>> Shouldn't this depend on ARCH_STM32, or some other M4 or M7 specific
>> Kconfig option, to avoid wasting the space on other CPUs?
>
> Actually, the STM32F429 has 90 interrupts, so it would need 106
> entries in the vector table.
> The maximum of supported interrupts is not only for Cortex-M4 and M7,
> this is also true for Cortex-M3.
>
> I see two possibilities:
>  1 - We declare the vector table for the maximum supported number of
> IRQs, as this patch does.
>         - Pro: it will be functionnal with all Cortex-M MCUs
>         - Con: Waste of less than 1KB for memory

The waste depends on the alignment size as well and could be up to
almost 2KB worst case. It varies depending on the padding. We should
try to place it so it always aligned and the wasted space is
minimized.

Rob

>  2 - We introduce a config flag that provides the number of interrupts
>         - Pro: No more memory waste
>         - Con: Need to declare a per MCU model config flag.
>
> Then, regarding the natural alignment, is there a way to ensure it
> depending on the value of a config flag?
> Or we should keep it at the maximum value possible?
>
> Any feedback will be appreciated, especially from Uwe who maintains
> the efm32 machine.
>
> Kind regards,
> Maxime
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Maxime Coquelin Feb. 19, 2015, 4:13 p.m. UTC | #6
Hi Rob,

2015-02-15 23:42 GMT+01:00 Rob Herring <robherring2@gmail.com>:
> On Fri, Feb 13, 2015 at 2:42 AM, Maxime Coquelin
> <mcoquelin.stm32@gmail.com> wrote:
>> Hi Geert,
>>
>> 2015-02-12 21:34 GMT+01:00 Geert Uytterhoeven <geert@linux-m68k.org>:
>>> On Thu, Feb 12, 2015 at 6:45 PM, Maxime Coquelin
>>> <mcoquelin.stm32@gmail.com> wrote:
>>>> From Cortex-M4 and M7 reference manuals, the nvic supports up to 240
>>>> interrupts. So the number of entries in vectors table is 256.
>>>>
>>>> This patch adds the missing entries, and change the alignement, so that
>>>> vector_table remains naturally aligned.
>>>
>>> Shouldn't this depend on ARCH_STM32, or some other M4 or M7 specific
>>> Kconfig option, to avoid wasting the space on other CPUs?
>>
>> Actually, the STM32F429 has 90 interrupts, so it would need 106
>> entries in the vector table.
>> The maximum of supported interrupts is not only for Cortex-M4 and M7,
>> this is also true for Cortex-M3.
>>
>> I see two possibilities:
>>  1 - We declare the vector table for the maximum supported number of
>> IRQs, as this patch does.
>>         - Pro: it will be functionnal with all Cortex-M MCUs
>>         - Con: Waste of less than 1KB for memory
>
> The waste depends on the alignment size as well and could be up to
> almost 2KB worst case. It varies depending on the padding. We should
> try to place it so it always aligned and the wasted space is
> minimized.

Sorry, I just notice I didn't replied to all. That was my question:

Do you mean by forcing its location in the arch/arm/kernel/vmlinux.lds.S file?

Regards,
Maxime

>
> Rob
>
>>  2 - We introduce a config flag that provides the number of interrupts
>>         - Pro: No more memory waste
>>         - Con: Need to declare a per MCU model config flag.
>>
>> Then, regarding the natural alignment, is there a way to ensure it
>> depending on the value of a config flag?
>> Or we should keep it at the maximum value possible?
>>
>> Any feedback will be appreciated, especially from Uwe who maintains
>> the efm32 machine.
>>
>> Kind regards,
>> Maxime
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Rob Herring Feb. 19, 2015, 4:35 p.m. UTC | #7
On Thu, Feb 19, 2015 at 10:13 AM, Maxime Coquelin
<mcoquelin.stm32@gmail.com> wrote:
> Hi Rob,
>
> 2015-02-15 23:42 GMT+01:00 Rob Herring <robherring2@gmail.com>:
>> On Fri, Feb 13, 2015 at 2:42 AM, Maxime Coquelin
>> <mcoquelin.stm32@gmail.com> wrote:
>>> Hi Geert,
>>>
>>> 2015-02-12 21:34 GMT+01:00 Geert Uytterhoeven <geert@linux-m68k.org>:
>>>> On Thu, Feb 12, 2015 at 6:45 PM, Maxime Coquelin
>>>> <mcoquelin.stm32@gmail.com> wrote:
>>>>> From Cortex-M4 and M7 reference manuals, the nvic supports up to 240
>>>>> interrupts. So the number of entries in vectors table is 256.
>>>>>
>>>>> This patch adds the missing entries, and change the alignement, so that
>>>>> vector_table remains naturally aligned.
>>>>
>>>> Shouldn't this depend on ARCH_STM32, or some other M4 or M7 specific
>>>> Kconfig option, to avoid wasting the space on other CPUs?
>>>
>>> Actually, the STM32F429 has 90 interrupts, so it would need 106
>>> entries in the vector table.
>>> The maximum of supported interrupts is not only for Cortex-M4 and M7,
>>> this is also true for Cortex-M3.
>>>
>>> I see two possibilities:
>>>  1 - We declare the vector table for the maximum supported number of
>>> IRQs, as this patch does.
>>>         - Pro: it will be functionnal with all Cortex-M MCUs
>>>         - Con: Waste of less than 1KB for memory
>>
>> The waste depends on the alignment size as well and could be up to
>> almost 2KB worst case. It varies depending on the padding. We should
>> try to place it so it always aligned and the wasted space is
>> minimized.
>
> Sorry, I just notice I didn't replied to all. That was my question:
>
> Do you mean by forcing its location in the arch/arm/kernel/vmlinux.lds.S file?

Yes, that is one way. Or we might be able to just be smarter about how
we arrange the code. The first thing to do is figure out how much
space we waste and what comes before it.

Rob

>
> Regards,
> Maxime
>
>>
>> Rob
>>
>>>  2 - We introduce a config flag that provides the number of interrupts
>>>         - Pro: No more memory waste
>>>         - Con: Need to declare a per MCU model config flag.
>>>
>>> Then, regarding the natural alignment, is there a way to ensure it
>>> depending on the value of a config flag?
>>> Or we should keep it at the maximum value possible?
>>>
>>> Any feedback will be appreciated, especially from Uwe who maintains
>>> the efm32 machine.
>>>
>>> Kind regards,
>>> Maxime
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch
diff mbox

diff --git a/arch/arm/kernel/entry-v7m.S b/arch/arm/kernel/entry-v7m.S
index 8944f49..29a461b 100644
--- a/arch/arm/kernel/entry-v7m.S
+++ b/arch/arm/kernel/entry-v7m.S
@@ -117,9 +117,9 @@  ENTRY(__switch_to)
 ENDPROC(__switch_to)
 
 	.data
-	.align	8
+	.align	10
 /*
- * Vector table (64 words => 256 bytes natural alignment)
+ * Vector table (256 words => 1024 bytes alignment)
  */
 ENTRY(vector_table)
 	.long	0			@ 0 - Reset stack pointer
@@ -138,6 +138,6 @@  ENTRY(vector_table)
 	.long	__invalid_entry		@ 13 - Reserved
 	.long	__pendsv_entry		@ 14 - PendSV
 	.long	__invalid_entry		@ 15 - SysTick
-	.rept	64 - 16
-	.long	__irq_entry		@ 16..64 - External Interrupts
+	.rept	256 - 16
+	.long	__irq_entry		@ 16..256 - External Interrupts
 	.endr