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

Reply via email to