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

[Bin Meng <bmeng.cn@gmail.com>]

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