Hi Hannes, On Mon, Nov 19, 2018 at 6:29 AM Hannes Schmelzer <han...@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 <han...@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 <oe5...@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 mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
