Hi Hannes,
On Mon, Nov 19, 2018 at 6:28 PM Bin Meng <bmeng...@gmail.com> wrote:
>
> 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.
>
Could you please take a look and testing
http://patchwork.ozlabs.org/project/uboot/list/?series=76752?
Regards,
Bin
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
