[U-Boot] arm builds fail with with CONFIG_USE_IRQ

[Chris Packham]

On Mon, Jul 14, 2014 at 3:35 PM, Chris Packham <judge.packham at gmail.com> wrote:
> On Mon, Jul 14, 2014 at 3:29 PM, Chris Packham <judge.packham at gmail.com> wrote:
>> Hi,
>>
>> (apologies in advance for whatever the gmail web client does to this email).
>>
>> In commit 41623c91 (arm: move exception handling out of start.S files)
>> code was moved to arch/arm/lib/vectors.S which wrapped symbols like
>> IRQ_STACK_START and FIQ_STACK_START using the config flag
>> CONFIG_USE_IRQ. As far as I can tell vector.S doesn't include anything
>> like common.h or config.h in order to get any of the CONFIG_xyz
>> defines.
>>
>> Picking on sheevaplug for no particular reason I get the following
>> error when I have a config with the options set to sheevaplug:USE_IRQ.
>>
>> arch/arm/lib/board.c: In function ‘board_init_f’:
>> arch/arm/lib/board.c:423:14: error: ‘CONFIG_STACKSIZE_IRQ’ undeclared
>> (first use in this function)
>> arch/arm/lib/board.c:423:14: note: each undeclared identifier is
>> reported only once for each function it appears in
>> arch/arm/lib/board.c:423:35: error: ‘CONFIG_STACKSIZE_FIQ’ undeclared
>> (first use in this function)
>
> Oops that's actually a compile error due to sheevaplug not defining
> those config options rather than not the linker error for
> IRQ_STACK_START and FIQ_STACK_START that I was trying to demonstrate.
>

This is the actual error once I've enabled enough config for interrupts.

arch/arm/lib/built-in.o: In function `interrupt_init':
/home/chrisp/src/u-boot/arch/arm/lib/interrupts.c:37: undefined
reference to `IRQ_STACK_START'
/home/chrisp/src/u-boot/arch/arm/lib/interrupts.c:37: undefined
reference to `FIQ_STACK_START'


>>
>> I don't see any arm targets in u-boot master with CONFIG_USE_IRQ set
>> so I guess this would have been easy to miss. We have one out of tree
>> board that uses interrupts so I noticed when I tried to update to
>> v2014.07-rc2 and have confirmed it's still a problem with -rc4.
>>
>> I think it's just a matter of adding #include <common.h> to vectors.S
>> and I'll follow up with a patch to that effect shortly but I though
>> maybe I was missing some other detail.
>>
>> Thanks,
>> Chris