[U-Boot] [PATCH] x86: make X86IRQ per Kconfig switchable

[U-Boot] [PATCH] x86: make X86IRQ per Kconfig switchable

[Hannes Schmelzer]

This commit creates the freedom for boards to do nothing with the whole
IRQ stuff on x86 during u-boot.

This is especially important on older systems which have many legacy irq
and no ACPI support within BIOS, they get in trouble if, for example,
u-boot does mask all the interrupts on a PIC.

Signed-off-by: Hannes Schmelzer <oe5hpm@oevsv.at>

---

 arch/x86/Kconfig      | 8 ++++++++
 arch/x86/lib/Makefile | 2 +-
 include/_exports.h    | 2 +-
 3 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 00b69c6..d2b691f 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -736,6 +736,14 @@ config I8259_PIC
 	  slave) interrupt controllers. Include this to have U-Boot set up
 	  the interrupt correctly.
 
+config X86IRQ
+	bool
+	default y
+	help
+	  Provide basic IRQ initialization with dummy handlers and spurious IRQ
+	  catching. Provide also some exported high-level API for standalone
+	  applications (see doc/README.standalone).
+
 config APIC
 	bool
 	default y
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
index 1e8efcc..57cb87d 100644
--- a/arch/x86/lib/Makefile
+++ b/arch/x86/lib/Makefile
@@ -16,7 +16,7 @@ obj-$(CONFIG_SEABIOS) += coreboot_table.o
 obj-y	+= early_cmos.o
 obj-y	+= e820.o
 obj-y	+= init_helpers.o
-obj-y	+= interrupts.o
+obj-$(CONFIG_X86IRQ) += interrupts.o
 obj-y	+= lpc-uclass.o
 obj-y	+= mpspec.o
 obj-$(CONFIG_ENABLE_MRC_CACHE) += mrccache.o
diff --git a/include/_exports.h b/include/_exports.h
index 5416041..39e3e32 100644
--- a/include/_exports.h
+++ b/include/_exports.h
@@ -13,7 +13,7 @@
 	EXPORT_FUNC(putc, void, putc, const char)
 	EXPORT_FUNC(puts, void, puts, const char *)
 	EXPORT_FUNC(printf, int, printf, const char*, ...)
-#if (defined(CONFIG_X86) && !defined(CONFIG_X86_64)) || defined(CONFIG_PPC)
+#if (defined(CONFIG_X86IRQ) && !defined(CONFIG_X86_64)) || defined(CONFIG_PPC)
 	EXPORT_FUNC(irq_install_handler, void, install_hdlr,
 		    int, interrupt_handler_t, void*)
 
-- 
2.7.4

[U-Boot] [PATCH] x86: make X86IRQ per Kconfig switchable

[Bin Meng]

Hi Hannes,

On Tue, Oct 23, 2018 at 5:12 AM Hannes Schmelzer <oe5hpm@oevsv.at> wrote:
>
> This commit creates the freedom for boards to do nothing with the whole
> IRQ stuff on x86 during u-boot.
>
> This is especially important on older systems which have many legacy irq
> and no ACPI support within BIOS, they get in trouble if, for example,
> u-boot does mask all the interrupts on a PIC.
>

Can you elaborate more on what specific issues are here? x86 interrupt
was designed to keep backward compatible and I don't think current
codes will break anything.

> Signed-off-by: Hannes Schmelzer <oe5hpm@oevsv.at>
>
> ---
>
>  arch/x86/Kconfig      | 8 ++++++++
>  arch/x86/lib/Makefile | 2 +-
>  include/_exports.h    | 2 +-
>  3 files changed, 10 insertions(+), 2 deletions(-)
>

Regards,
Bin

[U-Boot] [PATCH] x86: make X86IRQ per Kconfig switchable

[Hannes Schmelzer]

On 10/23/2018 05:24 AM, Bin Meng wrote:
> Hi Hannes,
Hi Bing,
thanks for your response.
>
> On Tue, Oct 23, 2018 at 5:12 AM Hannes Schmelzer <oe5hpm@oevsv.at> wrote:
>> This commit creates the freedom for boards to do nothing with the whole
>> IRQ stuff on x86 during u-boot.
>>
>> This is especially important on older systems which have many legacy irq
>> and no ACPI support within BIOS, they get in trouble if, for example,
>> u-boot does mask all the interrupts on a PIC.
>>
> Can you elaborate more on what specific issues are here? x86 interrupt
> was designed to keep backward compatible and I don't think current
> codes will break anything.
I'm actually porting coreboot + u-boot as payload for a quite old board.
Having here some AMD Geode LX800 with companion chip CS5536 as southbridge.
I went into trouble during bringing up ATA (whis no pci device) within 
linux after u-boot did run on the machine, the driver didn't get any 
interrupts from the device.
The combination coreboot+seabios for example worked fine. So i've 
searched for differences.

The difference is, that seabios leaves the irq stuff untouched and 
u-boot not.

Further thinking about all this brought me to the point that the OS has 
no real chance to setup things correctly without an ACPI or MP Table 
from the boot-loader where the hardware may be described. PCI devices 
are working correctly, because the configuration space of the pci device 
describes the situation and OS can setup the things correctly. In my 
case coreboot doesn't provide none of these tables, instead it did setup 
the PIC and maybe many other things in the southbridge to a basically 
working state. So my idea was to instruct u-boot to leave the irq stuff 
untouched.
Further i think there is no need for manipulating the PIC during u-boot, 
unless we don't use any interrupt there.

But maybe i'm thinking here completely weird and another way would bring 
me faster to the goal of a working system. Please let me know.

cheers,
Hannes

[U-Boot] [PATCH] x86: make X86IRQ per Kconfig switchable

[Bin Meng]

Hi Hannes,

On Tue, Oct 23, 2018 at 3:08 PM Hannes Schmelzer <hannes@schmelzer.or.at> wrote:
>
>
> On 10/23/2018 05:24 AM, Bin Meng wrote:
>
> Hi Hannes,
>
> Hi Bing,
> thanks for your response.
>
> On Tue, Oct 23, 2018 at 5:12 AM Hannes Schmelzer <oe5hpm@oevsv.at> wrote:
>
> This commit creates the freedom for boards to do nothing with the whole
> IRQ stuff on x86 during u-boot.
>
> This is especially important on older systems which have many legacy irq
> and no ACPI support within BIOS, they get in trouble if, for example,
> u-boot does mask all the interrupts on a PIC.
>
> Can you elaborate more on what specific issues are here? x86 interrupt
> was designed to keep backward compatible and I don't think current
> codes will break anything.
>
> I'm actually porting coreboot + u-boot as payload for a quite old board.
> Having here some AMD Geode LX800 with companion chip CS5536 as southbridge.
> I went into trouble during bringing up ATA (whis no pci device) within linux after u-boot did run on the machine, the driver didn't get any interrupts from the device.
> The combination coreboot+seabios for example worked fine. So i've searched for differences.
>
> The difference is, that seabios leaves the irq stuff untouched and u-boot not.
>
> Further thinking about all this brought me to the point that the OS has no real chance to setup things correctly without an ACPI or MP Table from the boot-loader where the hardware may be described. PCI devices are working correctly, because the configuration space of the pci device describes the situation and OS can setup the things correctly. In my case coreboot doesn't provide none of these tables, instead it did setup the PIC and maybe many other things in the southbridge to a basically working state. So my idea was to instruct u-boot to leave the irq stuff untouched.
> Further i think there is no need for manipulating the PIC during u-boot, unless we don't use any interrupt there.
>
> But maybe i'm thinking here completely weird and another way would bring me faster to the goal of a working system. Please let me know.

I see you changed the "EXPORT_FUNC(irq_install_handler..)". Is there
any codes in your board support that calls such? Isn't not calling
interrupt_init() sufficient to fix your problem?

Regards,
Bin

[U-Boot] [PATCH] x86: make X86IRQ per Kconfig switchable

[Hannes Schmelzer]

On 11/18/18 3:07 PM, Bin Meng wrote:
> Hi Hannes,
Hi Bin,
> On Tue, Oct 23, 2018 at 3:08 PM Hannes Schmelzer <hannes@schmelzer.or.at> wrote:
>>
>> On 10/23/2018 05:24 AM, Bin Meng wrote:
>>
>> Hi Hannes,
>>
>> Hi Bing,
>> thanks for your response.
>>
>> On Tue, Oct 23, 2018 at 5:12 AM Hannes Schmelzer <oe5hpm@oevsv.at> wrote:
>>
>> This commit creates the freedom for boards to do nothing with the whole
>> IRQ stuff on x86 during u-boot.
>>
>> This is especially important on older systems which have many legacy irq
>> and no ACPI support within BIOS, they get in trouble if, for example,
>> u-boot does mask all the interrupts on a PIC.
>>
>> Can you elaborate more on what specific issues are here? x86 interrupt
>> was designed to keep backward compatible and I don't think current
>> codes will break anything.
>>
>> I'm actually porting coreboot + u-boot as payload for a quite old board.
>> Having here some AMD Geode LX800 with companion chip CS5536 as southbridge.
>> I went into trouble during bringing up ATA (whis no pci device) within linux after u-boot did run on the machine, the driver didn't get any interrupts from the device.
>> The combination coreboot+seabios for example worked fine. So i've searched for differences.
>>
>> The difference is, that seabios leaves the irq stuff untouched and u-boot not.
>>
>> Further thinking about all this brought me to the point that the OS has no real chance to setup things correctly without an ACPI or MP Table from the boot-loader where the hardware may be described. PCI devices are working correctly, because the configuration space of the pci device describes the situation and OS can setup the things correctly. In my case coreboot doesn't provide none of these tables, instead it did setup the PIC and maybe many other things in the southbridge to a basically working state. So my idea was to instruct u-boot to leave the irq stuff untouched.
>> Further i think there is no need for manipulating the PIC during u-boot, unless we don't use any interrupt there.
>>
>> But maybe i'm thinking here completely weird and another way would bring me faster to the goal of a working system. Please let me know.
> I see you changed the "EXPORT_FUNC(irq_install_handler..)". Is there
> any codes in your board support that calls such? Isn't not calling
> interrupt_init() sufficient to fix your problem?
I agree, that would also fix my problem.
But on the other hand it would leftover dead code in case if the 
interrupt stuff isn't needed.

Would it be better to have 'config X86IRQ_SKIPINIT' (default no) for 
example instead my 'config X86IRQ' with default yes and make some #ifdef 
within interrupt.c?
> Regards,
> Bin
cheers,
Hannes

[U-Boot] [PATCH] x86: make X86IRQ per Kconfig switchable

[Bin Meng]

Hi Hannes,

On Mon, Nov 19, 2018 at 6:29 AM Hannes Schmelzer <hannes@schmelzer.or.at> wrote:
>
>
> On 11/18/18 3:07 PM, Bin Meng wrote:
> > Hi Hannes,
> Hi Bin,
> > On Tue, Oct 23, 2018 at 3:08 PM Hannes Schmelzer <hannes@schmelzer.or.at> wrote:
> >>
> >> On 10/23/2018 05:24 AM, Bin Meng wrote:
> >>
> >> Hi Hannes,
> >>
> >> Hi Bing,
> >> thanks for your response.
> >>
> >> On Tue, Oct 23, 2018 at 5:12 AM Hannes Schmelzer <oe5hpm@oevsv.at> wrote:
> >>
> >> This commit creates the freedom for boards to do nothing with the whole
> >> IRQ stuff on x86 during u-boot.
> >>
> >> This is especially important on older systems which have many legacy irq
> >> and no ACPI support within BIOS, they get in trouble if, for example,
> >> u-boot does mask all the interrupts on a PIC.
> >>
> >> Can you elaborate more on what specific issues are here? x86 interrupt
> >> was designed to keep backward compatible and I don't think current
> >> codes will break anything.
> >>
> >> I'm actually porting coreboot + u-boot as payload for a quite old board.
> >> Having here some AMD Geode LX800 with companion chip CS5536 as southbridge.
> >> I went into trouble during bringing up ATA (whis no pci device) within linux after u-boot did run on the machine, the driver didn't get any interrupts from the device.
> >> The combination coreboot+seabios for example worked fine. So i've searched for differences.
> >>
> >> The difference is, that seabios leaves the irq stuff untouched and u-boot not.
> >>
> >> Further thinking about all this brought me to the point that the OS has no real chance to setup things correctly without an ACPI or MP Table from the boot-loader where the hardware may be described. PCI devices are working correctly, because the configuration space of the pci device describes the situation and OS can setup the things correctly. In my case coreboot doesn't provide none of these tables, instead it did setup the PIC and maybe many other things in the southbridge to a basically working state. So my idea was to instruct u-boot to leave the irq stuff untouched.
> >> Further i think there is no need for manipulating the PIC during u-boot, unless we don't use any interrupt there.
> >>
> >> But maybe i'm thinking here completely weird and another way would bring me faster to the goal of a working system. Please let me know.
> > I see you changed the "EXPORT_FUNC(irq_install_handler..)". Is there
> > any codes in your board support that calls such? Isn't not calling
> > interrupt_init() sufficient to fix your problem?
> I agree, that would also fix my problem.
> But on the other hand it would leftover dead code in case if the
> interrupt stuff isn't needed.
>
> Would it be better to have 'config X86IRQ_SKIPINIT' (default no) for
> example instead my 'config X86IRQ' with default yes and make some #ifdef
> within interrupt.c?

I checked the interrupt.c. Isn't turning off CONFIG_I8259_PIC and
CONFIG_APIC already done the trick for your board? I don't think
initializing the IRQ vectors stuff will break your ATA driver in
Linux.

Regards,
Bin

[U-Boot] [PATCH] x86: make X86IRQ per Kconfig switchable

[Hannes Schmelzer]

On 11/19/18 2:59 AM, Bin Meng wrote:
> Hi Hannes,
Hi Bin,
> On Mon, Nov 19, 2018 at 6:29 AM Hannes Schmelzer <hannes@schmelzer.or.at> wrote:
>>
>> On 11/18/18 3:07 PM, Bin Meng wrote:
>>> Hi Hannes,
>> Hi Bin,
>>> On Tue, Oct 23, 2018 at 3:08 PM Hannes Schmelzer <hannes@schmelzer.or.at> wrote:
>>>> On 10/23/2018 05:24 AM, Bin Meng wrote:
>>>>
>>>> Hi Hannes,
>>>>
>>>> Hi Bing,
>>>> thanks for your response.
>>>>
>>>> On Tue, Oct 23, 2018 at 5:12 AM Hannes Schmelzer <oe5hpm@oevsv.at> wrote:
>>>>
>>>> This commit creates the freedom for boards to do nothing with the whole
>>>> IRQ stuff on x86 during u-boot.
>>>>
>>>> This is especially important on older systems which have many legacy irq
>>>> and no ACPI support within BIOS, they get in trouble if, for example,
>>>> u-boot does mask all the interrupts on a PIC.
>>>>
>>>> Can you elaborate more on what specific issues are here? x86 interrupt
>>>> was designed to keep backward compatible and I don't think current
>>>> codes will break anything.
>>>>
>>>> I'm actually porting coreboot + u-boot as payload for a quite old board.
>>>> Having here some AMD Geode LX800 with companion chip CS5536 as southbridge.
>>>> I went into trouble during bringing up ATA (whis no pci device) within linux after u-boot did run on the machine, the driver didn't get any interrupts from the device.
>>>> The combination coreboot+seabios for example worked fine. So i've searched for differences.
>>>>
>>>> The difference is, that seabios leaves the irq stuff untouched and u-boot not.
>>>>
>>>> Further thinking about all this brought me to the point that the OS has no real chance to setup things correctly without an ACPI or MP Table from the boot-loader where the hardware may be described. PCI devices are working correctly, because the configuration space of the pci device describes the situation and OS can setup the things correctly. In my case coreboot doesn't provide none of these tables, instead it did setup the PIC and maybe many other things in the southbridge to a basically working state. So my idea was to instruct u-boot to leave the irq stuff untouched.
>>>> Further i think there is no need for manipulating the PIC during u-boot, unless we don't use any interrupt there.
>>>>
>>>> But maybe i'm thinking here completely weird and another way would bring me faster to the goal of a working system. Please let me know.
>>> I see you changed the "EXPORT_FUNC(irq_install_handler..)". Is there
>>> any codes in your board support that calls such? Isn't not calling
>>> interrupt_init() sufficient to fix your problem?
>> I agree, that would also fix my problem.
>> But on the other hand it would leftover dead code in case if the
>> interrupt stuff isn't needed.
>>
>> Would it be better to have 'config X86IRQ_SKIPINIT' (default no) for
>> example instead my 'config X86IRQ' with default yes and make some #ifdef
>> within interrupt.c?
> I checked the interrupt.c. Isn't turning off CONFIG_I8259_PIC and
> CONFIG_APIC already done the trick for your board? I don't think
> initializing the IRQ vectors stuff will break your ATA driver in
> Linux.
No. Have a look to the function interrupt.c

int i8259_init(void)
{
     u8 i;

     /* Mask all interrupts */
     outb(0xff, MASTER_PIC + IMR);
     outb(0xff, SLAVE_PIC + IMR);
     .....
}

This has nothing todo with some APIC, the i8259 is the legacy XT-PIC.
And here all interrupts get masked, so the ATA irq doesn't come through 
anymore.
> Regards,
> Bin
cheers,
Hannes

[U-Boot] [PATCH] x86: make X86IRQ per Kconfig switchable

[Bin Meng]

Hi Hannes,

On Mon, Nov 19, 2018 at 5:31 PM Hannes Schmelzer <hannes@schmelzer.or.at> wrote:
>
> On 11/19/18 2:59 AM, Bin Meng wrote:
> > Hi Hannes,
> Hi Bin,
> > On Mon, Nov 19, 2018 at 6:29 AM Hannes Schmelzer <hannes@schmelzer.or.at> wrote:
> >>
> >> On 11/18/18 3:07 PM, Bin Meng wrote:
> >>> Hi Hannes,
> >> Hi Bin,
> >>> On Tue, Oct 23, 2018 at 3:08 PM Hannes Schmelzer <hannes@schmelzer.or.at> wrote:
> >>>> On 10/23/2018 05:24 AM, Bin Meng wrote:
> >>>>
> >>>> Hi Hannes,
> >>>>
> >>>> Hi Bing,
> >>>> thanks for your response.
> >>>>
> >>>> On Tue, Oct 23, 2018 at 5:12 AM Hannes Schmelzer <oe5hpm@oevsv.at> wrote:
> >>>>
> >>>> This commit creates the freedom for boards to do nothing with the whole
> >>>> IRQ stuff on x86 during u-boot.
> >>>>
> >>>> This is especially important on older systems which have many legacy irq
> >>>> and no ACPI support within BIOS, they get in trouble if, for example,
> >>>> u-boot does mask all the interrupts on a PIC.
> >>>>
> >>>> Can you elaborate more on what specific issues are here? x86 interrupt
> >>>> was designed to keep backward compatible and I don't think current
> >>>> codes will break anything.
> >>>>
> >>>> I'm actually porting coreboot + u-boot as payload for a quite old board.
> >>>> Having here some AMD Geode LX800 with companion chip CS5536 as southbridge.
> >>>> I went into trouble during bringing up ATA (whis no pci device) within linux after u-boot did run on the machine, the driver didn't get any interrupts from the device.
> >>>> The combination coreboot+seabios for example worked fine. So i've searched for differences.
> >>>>
> >>>> The difference is, that seabios leaves the irq stuff untouched and u-boot not.
> >>>>
> >>>> Further thinking about all this brought me to the point that the OS has no real chance to setup things correctly without an ACPI or MP Table from the boot-loader where the hardware may be described. PCI devices are working correctly, because the configuration space of the pci device describes the situation and OS can setup the things correctly. In my case coreboot doesn't provide none of these tables, instead it did setup the PIC and maybe many other things in the southbridge to a basically working state. So my idea was to instruct u-boot to leave the irq stuff untouched.
> >>>> Further i think there is no need for manipulating the PIC during u-boot, unless we don't use any interrupt there.
> >>>>
> >>>> But maybe i'm thinking here completely weird and another way would bring me faster to the goal of a working system. Please let me know.
> >>> I see you changed the "EXPORT_FUNC(irq_install_handler..)". Is there
> >>> any codes in your board support that calls such? Isn't not calling
> >>> interrupt_init() sufficient to fix your problem?
> >> I agree, that would also fix my problem.
> >> But on the other hand it would leftover dead code in case if the
> >> interrupt stuff isn't needed.
> >>
> >> Would it be better to have 'config X86IRQ_SKIPINIT' (default no) for
> >> example instead my 'config X86IRQ' with default yes and make some #ifdef
> >> within interrupt.c?
> > I checked the interrupt.c. Isn't turning off CONFIG_I8259_PIC and
> > CONFIG_APIC already done the trick for your board? I don't think
> > initializing the IRQ vectors stuff will break your ATA driver in
> > Linux.
> No. Have a look to the function interrupt.c
>
> int i8259_init(void)
> {
>      u8 i;
>
>      /* Mask all interrupts */
>      outb(0xff, MASTER_PIC + IMR);
>      outb(0xff, SLAVE_PIC + IMR);
>      .....
> }
>
> This has nothing todo with some APIC, the i8259 is the legacy XT-PIC.
> And here all interrupts get masked, so the ATA irq doesn't come through
> anymore.

I don't understand. If you disable CONFIG_I8259_PIC in your board
config, it will not touch 8259.

Regards,
Bin

[U-Boot] [PATCH] x86: make X86IRQ per Kconfig switchable

[Hannes Schmelzer]

On 11/19/18 10:35 AM, Bin Meng wrote:
> Hi Hannes,
Hi Bin,
> On Mon, Nov 19, 2018 at 5:31 PM Hannes Schmelzer <hannes@schmelzer.or.at> wrote:
>> On 11/19/18 2:59 AM, Bin Meng wrote:
>>> Hi Hannes,
>> Hi Bin,
>>> On Mon, Nov 19, 2018 at 6:29 AM Hannes Schmelzer <hannes@schmelzer.or.at> wrote:
>>>> On 11/18/18 3:07 PM, Bin Meng wrote:
>>>>> Hi Hannes,
>>>> Hi Bin,
>>>>> On Tue, Oct 23, 2018 at 3:08 PM Hannes Schmelzer <hannes@schmelzer.or.at> wrote:
>>>>>> On 10/23/2018 05:24 AM, Bin Meng wrote:
>>>>>>
>>>>>> Hi Hannes,
>>>>>>
>>>>>> Hi Bing,
>>>>>> thanks for your response.
>>>>>>
>>>>>> On Tue, Oct 23, 2018 at 5:12 AM Hannes Schmelzer <oe5hpm@oevsv.at> wrote:
>>>>>>
>>>>>> This commit creates the freedom for boards to do nothing with the whole
>>>>>> IRQ stuff on x86 during u-boot.
>>>>>>
>>>>>> This is especially important on older systems which have many legacy irq
>>>>>> and no ACPI support within BIOS, they get in trouble if, for example,
>>>>>> u-boot does mask all the interrupts on a PIC.
>>>>>>
>>>>>> Can you elaborate more on what specific issues are here? x86 interrupt
>>>>>> was designed to keep backward compatible and I don't think current
>>>>>> codes will break anything.
>>>>>>
>>>>>> I'm actually porting coreboot + u-boot as payload for a quite old board.
>>>>>> Having here some AMD Geode LX800 with companion chip CS5536 as southbridge.
>>>>>> I went into trouble during bringing up ATA (whis no pci device) within linux after u-boot did run on the machine, the driver didn't get any interrupts from the device.
>>>>>> The combination coreboot+seabios for example worked fine. So i've searched for differences.
>>>>>>
>>>>>> The difference is, that seabios leaves the irq stuff untouched and u-boot not.
>>>>>>
>>>>>> Further thinking about all this brought me to the point that the OS has no real chance to setup things correctly without an ACPI or MP Table from the boot-loader where the hardware may be described. PCI devices are working correctly, because the configuration space of the pci device describes the situation and OS can setup the things correctly. In my case coreboot doesn't provide none of these tables, instead it did setup the PIC and maybe many other things in the southbridge to a basically working state. So my idea was to instruct u-boot to leave the irq stuff untouched.
>>>>>> Further i think there is no need for manipulating the PIC during u-boot, unless we don't use any interrupt there.
>>>>>>
>>>>>> But maybe i'm thinking here completely weird and another way would bring me faster to the goal of a working system. Please let me know.
>>>>> I see you changed the "EXPORT_FUNC(irq_install_handler..)". Is there
>>>>> any codes in your board support that calls such? Isn't not calling
>>>>> interrupt_init() sufficient to fix your problem?
>>>> I agree, that would also fix my problem.
>>>> But on the other hand it would leftover dead code in case if the
>>>> interrupt stuff isn't needed.
>>>>
>>>> Would it be better to have 'config X86IRQ_SKIPINIT' (default no) for
>>>> example instead my 'config X86IRQ' with default yes and make some #ifdef
>>>> within interrupt.c?
>>> I checked the interrupt.c. Isn't turning off CONFIG_I8259_PIC and
>>> CONFIG_APIC already done the trick for your board? I don't think
>>> initializing the IRQ vectors stuff will break your ATA driver in
>>> Linux.
>> No. Have a look to the function interrupt.c
>>
>> int i8259_init(void)
>> {
>>       u8 i;
>>
>>       /* Mask all interrupts */
>>       outb(0xff, MASTER_PIC + IMR);
>>       outb(0xff, SLAVE_PIC + IMR);
>>       .....
>> }
>>
>> This has nothing todo with some APIC, the i8259 is the legacy XT-PIC.
>> And here all interrupts get masked, so the ATA irq doesn't come through
>> anymore.
> I don't understand. If you disable CONFIG_I8259_PIC in your board
> config, it will not touch 8259.
Basically yes. But if i disable the CONFIG_I8259_PIC the reset of the 
interrupt stuff gets into trouble:

arch/x86/lib/built-in.o: In function `irq_install_handler':
/home/schmelzerh/work/u-boot/arch/x86/lib/interrupts.c:67: undefined 
reference to `unmask_irq'
arch/x86/lib/built-in.o: In function `irq_free_handler':
/home/schmelzerh/work/u-boot/arch/x86/lib/interrupts.c:86: undefined 
reference to `mask_irq'
arch/x86/lib/built-in.o: In function `do_irq':
/home/schmelzerh/work/u-boot/arch/x86/lib/interrupts.c:107: undefined 
reference to `mask_irq'
/home/schmelzerh/work/u-boot/arch/x86/lib/interrupts.c:112: undefined 
reference to `unmask_irq'
/home/schmelzerh/work/u-boot/arch/x86/lib/interrupts.c:113: undefined 
reference to `specific_eoi'

This is because after disabling APIC and PIC no function for 
enable/disable interrupt is left.
Or with other words, without APIC nor PIC the rest of the irq stuff 
doesn't make sense on x86.
> Regards,
> Bin
cheers,
Hannes

[U-Boot] [PATCH] x86: make X86IRQ per Kconfig switchable

[Bin Meng]

Hi Hannes,

On Mon, Nov 19, 2018 at 5:45 PM Hannes Schmelzer <hannes@schmelzer.or.at> wrote:
>
> On 11/19/18 10:35 AM, Bin Meng wrote:
> > Hi Hannes,
> Hi Bin,
> > On Mon, Nov 19, 2018 at 5:31 PM Hannes Schmelzer <hannes@schmelzer.or.at> wrote:
> >> On 11/19/18 2:59 AM, Bin Meng wrote:
> >>> Hi Hannes,
> >> Hi Bin,
> >>> On Mon, Nov 19, 2018 at 6:29 AM Hannes Schmelzer <hannes@schmelzer.or.at> wrote:
> >>>> On 11/18/18 3:07 PM, Bin Meng wrote:
> >>>>> Hi Hannes,
> >>>> Hi Bin,
> >>>>> On Tue, Oct 23, 2018 at 3:08 PM Hannes Schmelzer <hannes@schmelzer.or.at> wrote:
> >>>>>> On 10/23/2018 05:24 AM, Bin Meng wrote:
> >>>>>>
> >>>>>> Hi Hannes,
> >>>>>>
> >>>>>> Hi Bing,
> >>>>>> thanks for your response.
> >>>>>>
> >>>>>> On Tue, Oct 23, 2018 at 5:12 AM Hannes Schmelzer <oe5hpm@oevsv.at> wrote:
> >>>>>>
> >>>>>> This commit creates the freedom for boards to do nothing with the whole
> >>>>>> IRQ stuff on x86 during u-boot.
> >>>>>>
> >>>>>> This is especially important on older systems which have many legacy irq
> >>>>>> and no ACPI support within BIOS, they get in trouble if, for example,
> >>>>>> u-boot does mask all the interrupts on a PIC.
> >>>>>>
> >>>>>> Can you elaborate more on what specific issues are here? x86 interrupt
> >>>>>> was designed to keep backward compatible and I don't think current
> >>>>>> codes will break anything.
> >>>>>>
> >>>>>> I'm actually porting coreboot + u-boot as payload for a quite old board.
> >>>>>> Having here some AMD Geode LX800 with companion chip CS5536 as southbridge.
> >>>>>> I went into trouble during bringing up ATA (whis no pci device) within linux after u-boot did run on the machine, the driver didn't get any interrupts from the device.
> >>>>>> The combination coreboot+seabios for example worked fine. So i've searched for differences.
> >>>>>>
> >>>>>> The difference is, that seabios leaves the irq stuff untouched and u-boot not.
> >>>>>>
> >>>>>> Further thinking about all this brought me to the point that the OS has no real chance to setup things correctly without an ACPI or MP Table from the boot-loader where the hardware may be described. PCI devices are working correctly, because the configuration space of the pci device describes the situation and OS can setup the things correctly. In my case coreboot doesn't provide none of these tables, instead it did setup the PIC and maybe many other things in the southbridge to a basically working state. So my idea was to instruct u-boot to leave the irq stuff untouched.
> >>>>>> Further i think there is no need for manipulating the PIC during u-boot, unless we don't use any interrupt there.
> >>>>>>
> >>>>>> But maybe i'm thinking here completely weird and another way would bring me faster to the goal of a working system. Please let me know.
> >>>>> I see you changed the "EXPORT_FUNC(irq_install_handler..)". Is there
> >>>>> any codes in your board support that calls such? Isn't not calling
> >>>>> interrupt_init() sufficient to fix your problem?
> >>>> I agree, that would also fix my problem.
> >>>> But on the other hand it would leftover dead code in case if the
> >>>> interrupt stuff isn't needed.
> >>>>
> >>>> Would it be better to have 'config X86IRQ_SKIPINIT' (default no) for
> >>>> example instead my 'config X86IRQ' with default yes and make some #ifdef
> >>>> within interrupt.c?
> >>> I checked the interrupt.c. Isn't turning off CONFIG_I8259_PIC and
> >>> CONFIG_APIC already done the trick for your board? I don't think
> >>> initializing the IRQ vectors stuff will break your ATA driver in
> >>> Linux.
> >> No. Have a look to the function interrupt.c
> >>
> >> int i8259_init(void)
> >> {
> >>       u8 i;
> >>
> >>       /* Mask all interrupts */
> >>       outb(0xff, MASTER_PIC + IMR);
> >>       outb(0xff, SLAVE_PIC + IMR);
> >>       .....
> >> }
> >>
> >> This has nothing todo with some APIC, the i8259 is the legacy XT-PIC.
> >> And here all interrupts get masked, so the ATA irq doesn't come through
> >> anymore.
> > I don't understand. If you disable CONFIG_I8259_PIC in your board
> > config, it will not touch 8259.
> Basically yes. But if i disable the CONFIG_I8259_PIC the reset of the
> interrupt stuff gets into trouble:
>
> arch/x86/lib/built-in.o: In function `irq_install_handler':
> /home/schmelzerh/work/u-boot/arch/x86/lib/interrupts.c:67: undefined
> reference to `unmask_irq'
> arch/x86/lib/built-in.o: In function `irq_free_handler':
> /home/schmelzerh/work/u-boot/arch/x86/lib/interrupts.c:86: undefined
> reference to `mask_irq'
> arch/x86/lib/built-in.o: In function `do_irq':
> /home/schmelzerh/work/u-boot/arch/x86/lib/interrupts.c:107: undefined
> reference to `mask_irq'
> /home/schmelzerh/work/u-boot/arch/x86/lib/interrupts.c:112: undefined
> reference to `unmask_irq'
> /home/schmelzerh/work/u-boot/arch/x86/lib/interrupts.c:113: undefined
> reference to `specific_eoi'
>
> This is because after disabling APIC and PIC no function for
> enable/disable interrupt is left.
> Or with other words, without APIC nor PIC the rest of the irq stuff
> doesn't make sense on x86.

Thanks for the trying. So the root cause for your board is now clear.
I think we should fix the build dependency when turning off
CONFIG_I8259_PIC instead.

Regards,
Bin

[U-Boot] [PATCH] x86: make X86IRQ per Kconfig switchable

[Bin Meng]

Hi Hannes,

On Mon, Nov 19, 2018 at 6:28 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Hannes,
>
> On Mon, Nov 19, 2018 at 5:45 PM Hannes Schmelzer <hannes@schmelzer.or.at> wrote:
> >
> > On 11/19/18 10:35 AM, Bin Meng wrote:
> > > Hi Hannes,
> > Hi Bin,
> > > On Mon, Nov 19, 2018 at 5:31 PM Hannes Schmelzer <hannes@schmelzer.or.at> wrote:
> > >> On 11/19/18 2:59 AM, Bin Meng wrote:
> > >>> Hi Hannes,
> > >> Hi Bin,
> > >>> On Mon, Nov 19, 2018 at 6:29 AM Hannes Schmelzer <hannes@schmelzer.or.at> wrote:
> > >>>> On 11/18/18 3:07 PM, Bin Meng wrote:
> > >>>>> Hi Hannes,
> > >>>> Hi Bin,
> > >>>>> On Tue, Oct 23, 2018 at 3:08 PM Hannes Schmelzer <hannes@schmelzer.or.at> wrote:
> > >>>>>> On 10/23/2018 05:24 AM, Bin Meng wrote:
> > >>>>>>
> > >>>>>> Hi Hannes,
> > >>>>>>
> > >>>>>> Hi Bing,
> > >>>>>> thanks for your response.
> > >>>>>>
> > >>>>>> On Tue, Oct 23, 2018 at 5:12 AM Hannes Schmelzer <oe5hpm@oevsv.at> wrote:
> > >>>>>>
> > >>>>>> This commit creates the freedom for boards to do nothing with the whole
> > >>>>>> IRQ stuff on x86 during u-boot.
> > >>>>>>
> > >>>>>> This is especially important on older systems which have many legacy irq
> > >>>>>> and no ACPI support within BIOS, they get in trouble if, for example,
> > >>>>>> u-boot does mask all the interrupts on a PIC.
> > >>>>>>
> > >>>>>> Can you elaborate more on what specific issues are here? x86 interrupt
> > >>>>>> was designed to keep backward compatible and I don't think current
> > >>>>>> codes will break anything.
> > >>>>>>
> > >>>>>> I'm actually porting coreboot + u-boot as payload for a quite old board.
> > >>>>>> Having here some AMD Geode LX800 with companion chip CS5536 as southbridge.
> > >>>>>> I went into trouble during bringing up ATA (whis no pci device) within linux after u-boot did run on the machine, the driver didn't get any interrupts from the device.
> > >>>>>> The combination coreboot+seabios for example worked fine. So i've searched for differences.
> > >>>>>>
> > >>>>>> The difference is, that seabios leaves the irq stuff untouched and u-boot not.
> > >>>>>>
> > >>>>>> Further thinking about all this brought me to the point that the OS has no real chance to setup things correctly without an ACPI or MP Table from the boot-loader where the hardware may be described. PCI devices are working correctly, because the configuration space of the pci device describes the situation and OS can setup the things correctly. In my case coreboot doesn't provide none of these tables, instead it did setup the PIC and maybe many other things in the southbridge to a basically working state. So my idea was to instruct u-boot to leave the irq stuff untouched.
> > >>>>>> Further i think there is no need for manipulating the PIC during u-boot, unless we don't use any interrupt there.
> > >>>>>>
> > >>>>>> But maybe i'm thinking here completely weird and another way would bring me faster to the goal of a working system. Please let me know.
> > >>>>> I see you changed the "EXPORT_FUNC(irq_install_handler..)". Is there
> > >>>>> any codes in your board support that calls such? Isn't not calling
> > >>>>> interrupt_init() sufficient to fix your problem?
> > >>>> I agree, that would also fix my problem.
> > >>>> But on the other hand it would leftover dead code in case if the
> > >>>> interrupt stuff isn't needed.
> > >>>>
> > >>>> Would it be better to have 'config X86IRQ_SKIPINIT' (default no) for
> > >>>> example instead my 'config X86IRQ' with default yes and make some #ifdef
> > >>>> within interrupt.c?
> > >>> I checked the interrupt.c. Isn't turning off CONFIG_I8259_PIC and
> > >>> CONFIG_APIC already done the trick for your board? I don't think
> > >>> initializing the IRQ vectors stuff will break your ATA driver in
> > >>> Linux.
> > >> No. Have a look to the function interrupt.c
> > >>
> > >> int i8259_init(void)
> > >> {
> > >>       u8 i;
> > >>
> > >>       /* Mask all interrupts */
> > >>       outb(0xff, MASTER_PIC + IMR);
> > >>       outb(0xff, SLAVE_PIC + IMR);
> > >>       .....
> > >> }
> > >>
> > >> This has nothing todo with some APIC, the i8259 is the legacy XT-PIC.
> > >> And here all interrupts get masked, so the ATA irq doesn't come through
> > >> anymore.
> > > I don't understand. If you disable CONFIG_I8259_PIC in your board
> > > config, it will not touch 8259.
> > Basically yes. But if i disable the CONFIG_I8259_PIC the reset of the
> > interrupt stuff gets into trouble:
> >
> > arch/x86/lib/built-in.o: In function `irq_install_handler':
> > /home/schmelzerh/work/u-boot/arch/x86/lib/interrupts.c:67: undefined
> > reference to `unmask_irq'
> > arch/x86/lib/built-in.o: In function `irq_free_handler':
> > /home/schmelzerh/work/u-boot/arch/x86/lib/interrupts.c:86: undefined
> > reference to `mask_irq'
> > arch/x86/lib/built-in.o: In function `do_irq':
> > /home/schmelzerh/work/u-boot/arch/x86/lib/interrupts.c:107: undefined
> > reference to `mask_irq'
> > /home/schmelzerh/work/u-boot/arch/x86/lib/interrupts.c:112: undefined
> > reference to `unmask_irq'
> > /home/schmelzerh/work/u-boot/arch/x86/lib/interrupts.c:113: undefined
> > reference to `specific_eoi'
> >
> > This is because after disabling APIC and PIC no function for
> > enable/disable interrupt is left.
> > Or with other words, without APIC nor PIC the rest of the irq stuff
> > doesn't make sense on x86.
>
> Thanks for the trying. So the root cause for your board is now clear.
> I think we should fix the build dependency when turning off
> CONFIG_I8259_PIC instead.
>

Could you please take a look and testing
http://patchwork.ozlabs.org/project/uboot/list/?series=76752?

Regards,
Bin