Hi Hannes,
On Mon, Nov 19, 2018 at 5:45 PM Hannes Schmelzer <han...@schmelzer.or.at> wrote:
>
> On 11/19/18 10:35 AM, Bin Meng wrote:
> > Hi Hannes,
> Hi Bin,
> > 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.
> Basically yes. But if i disable the CONFIG_I8259_PIC the reset of the
> interrupt stuff gets into trouble:
>
> arch/x86/lib/built-in.o: In function `irq_install_handler':
> /home/schmelzerh/work/u-boot/arch/x86/lib/interrupts.c:67: undefined
> reference to `unmask_irq'
> arch/x86/lib/built-in.o: In function `irq_free_handler':
> /home/schmelzerh/work/u-boot/arch/x86/lib/interrupts.c:86: undefined
> reference to `mask_irq'
> arch/x86/lib/built-in.o: In function `do_irq':
> /home/schmelzerh/work/u-boot/arch/x86/lib/interrupts.c:107: undefined
> reference to `mask_irq'
> /home/schmelzerh/work/u-boot/arch/x86/lib/interrupts.c:112: undefined
> reference to `unmask_irq'
> /home/schmelzerh/work/u-boot/arch/x86/lib/interrupts.c:113: undefined
> reference to `specific_eoi'
>
> This is because after disabling APIC and PIC no function for
> enable/disable interrupt is left.
> Or with other words, without APIC nor PIC the rest of the irq stuff
> doesn't make sense on x86.
Thanks for the trying. So the root cause for your board is now clear.
I think we should fix the build dependency when turning off
CONFIG_I8259_PIC instead.
Regards,
Bin
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
