Hi Hannes, 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? Regards, Bin _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot