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