[U-Boot] [PATCH] x86: make X86IRQ per Kconfig switchable

From: Hannes Schmelzer <hannes@schmelzer.or.at>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] x86: make X86IRQ per Kconfig switchable
Date: Tue, 23 Oct 2018 09:08:28 +0200	[thread overview]
Message-ID: <890d7d66-485e-f5b0-5fc7-95de3a823ab9@schmelzer.or.at> (raw)
In-Reply-To: <CAEUhbmUDHwTmVoaixb+rzVJd4yzLkttTddVyZ-yHfaGaHW_ktA@mail.gmail.com>

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 <oe5hpm@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.

cheers,
Hannes