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

[Jian Luo]

Hi Bin,

On 19.07.2016 10:10, Bin Meng wrote:
> Hi Jian,
>
> On Tue, Jul 19, 2016 at 4:03 PM, Jian Luo <Jian.Luo4 at boschrexroth.de> wrote:
>> Hallo Christian,
>>
>>
>> On 19.07.2016 08:02, Christian Gmeiner wrote:
>>
>> Hi Bin
>>
>> 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.
>>
>> 0x2e == POST_PRE_MRC (arch/x86/include/asm/post.h)
>>
>> 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.
>>
>> There a handful of registers I would need to program but all of them are
>> accessible via pic config space. E.g CLKCFG:
>>
>> Size: 32-bit Default: 20000C00 Power Well: Core
>> Access PCI Configuration B:D:F D0:F0 Offset Start: Offset End: 500h 503h
>>              Memory Mapped I/O BAR: PKTHubCTLBASE Offset: 500h
>>
>>
>> As I need to program those registers before fsp_init I must setup the pci
>> bus by myself, change the register values and call fsb_init routine.
>> Correct?
>>
>> My board had this problem too. I however toke a different approach
> Great, I got you :)
>
>> by patching the original FSP. The waiting for Topcliff UART ready is
> How did you patch the original FSP? Did you reverse engineering the FSP?
Only at where it hangs. With the help of an ECM-XDP3 Debugger.
Then I made a wild guess that in all compressed PE32 sections have the 
same problem.
Yepp, dirty hack.
>
>> completely
>> bypassed in all UEFI blobs. You can use UEFITool [1] to extract blobs in
>> the attached FSP for comparison.
>>
>> greets
>> --
>> Christian Gmeiner, MSc
>>
>> https://soundcloud.com/christian-gmeiner
>>
>> [1] https://github.com/LongSoft/UEFITool
>>
> Regards,
> Bin

Best regards,

*Jian Luo
DC-IA/EAH2*

Tel.  +49(9352)18-4266

*Be**QIK
*