[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 at 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 at 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