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