[U-Boot] u-boot: x86: interrupt mapping

[Bin Meng]

+Jian, Simon, ML, this info might be useful for other guys on the ML.

Hi Christian,


On Mon, Jul 18, 2016 at 11:02 PM, Christian Gmeiner
<christian.gmeiner at gmail.com> wrote:
> Hi Bin,
>
>
> 2016-06-28 3:15 GMT+02:00 Bin Meng <bmeng.cn at gmail.com>:
>> Hi Christian,
>>
>> On Mon, Jun 27, 2016 at 8:37 PM, Christian Gmeiner
>> <christian.gmeiner at gmail.com> wrote:
>>> Hi Bin
>>>
>>>
>>> 2016-06-27 14:05 GMT+02:00 Bin Meng <bmeng.cn at gmail.com>:
>>>> Hi Christian,
>>>>
>>>> On Mon, Jun 27, 2016 at 6:59 PM, Christian Gmeiner
>>>> <christian.gmeiner at gmail.com> wrote:
>>>>> Hi Bin,
>>>>>
>>>>> 2016-06-17 4:10 GMT+02:00 Bin Meng <bmeng.cn at gmail.com>:
>>>>>> Hi Christian,
>>>>>>
>>>>>> On Fri, Jun 17, 2016 at 4:13 AM, Christian Gmeiner
>>>>>> <christian.gmeiner at gmail.com> wrote:
>>>>>>> Hi Bin,
>>>>>>>
>>>>>>> I am writing you off-list to look for some help. I am currently
>>>>>>> porting u-boot-x86 onto a crownbay/tunnelcreek based device.
>>>>>>
>>>>>> What's the board? Is the board similar to Crown Bay?
>>>>>>
>>>>>
>>>>> Yes the design is heavily based on Crown Bay.
>>>>>
>>>>>>> I got the basis up and running quite fast, but interrupts/mp tables
>>>>>>> eats my nerves. Is there a good approach to get the interrupt
>>>>>>> mapping done correctly without try-and-error all the time? I have
>>>>>>> access to the schematics (which could help).
>>>>>>
>>>>>> If it is E6xx and Topcliff chipset based, you should just use the
>>>>>> interrupt mapping in the crownbay.dts as majority of the interrupt
>>>>>> mapping is the same within SoC.
>>>>>>
>>>>>
>>>>> After some hours debugging this issue I finally found the root cause for
>>>>> the non working interrupts. The old bootloader does ioapic init sutff.
>>>>>
>>>>> The old boot chain was: bios -> bootloader (vxworks 6.8 based) -> system
>>>>> (vxworks 5.5 based).
>>>>
>>>> When you talk 'bios', do you mean U-Boot?
>>>
>>> Nope. bios == bldk based bios.
>>>
>>> My job is to port the old used booting system (bldk, vxworks 6.8 based boot app,
>>> vxworks 5.5 runtime system) over to u-boot.
>>>
>>>>
>>>>>
>>>>> To get the following boot chain working I needed to hackup up the interrupt
>>>>> line assignment for pci devices.
>>>>>
>>>>> u-boot -> sytem
>>>>>
>>>>> +++ b/arch/x86/cpu/pci.c
>>>>> @@ -80,6 +80,10 @@ void pci_assign_irqs(int bus, int device, u8 irq[4])
>>>>>                 if (!line)
>>>>>                         continue;
>>>>>
>>>>> +#ifdef HACK
>>>>> +               line = pin + 15;
>>>>> +#endif
>>>>
>>>> I don't understand the hack here.
>>>
>>> I try my best to explain it. loaded system expects that the PCI
>>> devices interrupt
>>> lines are configured correctly. For instance without that hack the
>>> system failed to
>>> identify the sata device as interrupts were not working/wrong.
>>>
>>> The +15 comes from the fact that in the I/O APIC redirection table the entries
>>> 16-23 correspond to PCI Lines A-H.
>>>
>>
>> I think it should be +16?
>>
>
> Yeah..
>
>>
>>> Normally mp table usage should happen in the os - in my case vxw 5.5 image, but
>>> it does not support it and there too many devices in the field so a
>>> change in the os
>>> is not possible.
>>>
>>
>> I still do not get the hack here. Are you saying that the VxW 5.5
>> image does not support MPTable? Then why does it bother to use IOAPIC?
>> It can just use PIC and get the IRQ number from the interrupt line
>> register configured by U-Boot.
>>
>
> For the moment I have no answer to this question. I need to dive into
> the vxworks code, which
> is not what I like to do now (but needs to be done)-
>

Yes, please do track it down. The interrupt line register configured
by U-Boot should be enough for VxWorks to function under PIC mode.

> I have an other (wired) question you may could help out.
>
> http://www.mouser.com/pdfdocs/Intel_Platform_Controller_Hub_EG20T_datasheet.pdf
> (page 124)
>
> On my development board the uart_clk is connected to a oscillator and
> everything works as expected.
> But on the production devices the uart_clk is not connected and fsp
> hangs with post code 0x2e.
>

I am not sure about the meaning of post code 0x2e. Jian has some
working experience on Atom E6xx with U-Boot. Adding him.

> Now I would like to change the initial mux settings to use usb_48mhz
> but I am quite sure that I need
> to have the pci bus and its devices initialised already in order to
> change the CLKCFG register. Do you
> think there is an other way of accessing this register like fixed
> memory address etc?
>

Which register do you want to program for this uart_clk? If it's on
the PCI configuration space, you can use PCI config APIs to program.

> thanks
> --

Regards,
Bin