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

Wed Jul 20 10:22:35 CEST 2016

Hi Jian,

>
> I took some time to recall what I did by patching FSP:
>
> - search in every PE32 and TE image section for binary sequence
> 81c9000100008908c6460e01
> and change to
> 81c9000102008908c6460e00
>

In the meantime I started by patching out every access to the uart bar, with
the same result as I get with your patching strategy.

> - then replace them in-place
>

So here is the next interesting problem. During fsp_init it looks like
fsp copies itself
to ram (IP 0xFFFD1C6C vs 0x3F5F64E1) and here it does a busy loop :(

At what place do you do the in-place patching? I hoped to do it at
init_board setup.

> The difference can be better understand if disassemblies are compared, eg:
>  Disassembly of section .data:
> @@ -3367,9 +3367,9 @@
>      25fc:    05 00 05 00 00           add    $0x500,%eax
>      2601:    8b 08                    mov    (%eax),%ecx
>      2603:    81 e1 ff ff f8 ff        and    $0xfff8ffff,%ecx
> -    2609:    81 c9 00 01 00 00        or     $0x100,%ecx
> +    2609:    81 c9 00 01 02 00        or     $0x20100,%ecx
> What I did here is setting BAUDSEL to SYS_25MHz.
>
>      260f:    89 08                    mov    %ecx,(%eax)
> -    2611:    c6 46 0e 01              movb   $0x1,0xe(%esi)
> +    2611:    c6 46 0e 00              movb   $0x0,0xe(%esi)
> Can't recall why I did this, maybe bypassing PLL altogether?
>
>      2615:    c6 46 0f 00              movb   $0x0,0xf(%esi)
>      2619:    c6 46 03 83              movb   $0x83,0x3(%esi)
>      261d:    c6 46 01 00              movb   $0x0,0x1(%esi)
>
> Since I don't rely on Topcliff UART for output, the baud rate recalculation
> is all skipped.
>

The same here... I am using a pci fpga based uart.

> Best regards,
>
> *Jian Luo
> DC-IA/EAH2*
>
> Tel.  +49(9352)18-4266
>
> *Be**QIK
> *
>
>
> On 19.07.2016 17:21, Christian Gmeiner wrote:
>>
>> Hi Jian,
>>
>>> 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
>>> by patching the original FSP. The waiting for Topcliff UART ready is
>>> completely
>>> bypassed in all UEFI blobs. You can use UEFITool [1] to extract blobs in
>>> the attached FSP for comparison.
>>>
>> Sooo... I did use the UEFITool to compare your fsp with mine and yeah...
>> some files are different.
>>
>> File_Raw_06A70056_3D0F_4A94_A743_5491CC9391D3_body.bin
>>
>> Section_PE32_image_47EA2673_2533_4C07_AABA_69CE5A7C5D35_PlatformLateInit_body.bin
>>
>> Section_PE32_image_47EA2673_2533_4C07_AABA_69CE5A7C5D35_PlatformLateInit_header.bin
>> Section_PE32_image_4D1F48D8_0498_4C09_8EDE_72F30B58B1F2_MpInit_body.bin
>> Section_PE32_image_74D3B506_EE9C_47ED_B749_41261401DA78_TCInitDxe_body.bin
>>
>> Section_TE_image_1BA0062E_C779_4582_8566_336AE8F78F09_Volume_Top_File_body.bin
>> Section_TE_image_52C05B14_0B98_496C_BC3B_04B50211D680_PeiCore_body.bin
>> Section_TE_image_86D70125_BAA3_4296_A62F_602BEBBB9081_DxeIpl_body.bin
>>
>> Section_TE_image_9618C0DC_50A4_496C_994F_7241F282ED01_PlatformEarlyInit_body.bin
>> Section_TE_image_9B3ADA4F_AE56_4C24_8DEA_F03B7558AE50_PcdPeim_body.bin
>>
>> Section_TE_image_D2C69B26_82E1_4A1B_AD35_ED0261B9F347_MemoryInitPei_body.bin
>>
>> File_PEI_module_47EA2673_2533_4C07_AABA_69CE5A7C5D35_PlatformLateInit_info.txt
>> File_PEI_module_4D1F48D8_0498_4C09_8EDE_72F30B58B1F2_MpInit_info.txt
>> File_PEI_module_74D3B506_EE9C_47ED_B749_41261401DA78_TCInitDxe_info.txt
>>
>> Section_Compressed_47EA2673_2533_4C07_AABA_69CE5A7C5D35_PlatformLateInit_info.txt
>> Section_Compressed_4D1F48D8_0498_4C09_8EDE_72F30B58B1F2_MpInit_info.txt
>> Section_Compressed_74D3B506_EE9C_47ED_B749_41261401DA78_TCInitDxe_info.txt
>>
>> Section_PE32_image_47EA2673_2533_4C07_AABA_69CE5A7C5D35_PlatformLateInit_info.txt
>>
>> Section_PEI_dependency_47EA2673_2533_4C07_AABA_69CE5A7C5D35_PlatformLateInit_info.txt
>>
>> Section_PEI_dependency_4D1F48D8_0498_4C09_8EDE_72F30B58B1F2_MpInit_info.txt
>>
>> Any hint at what to look for? Sadly I am not an UEFI guy.
>>
>> greets
>> --
>> Christian Gmeiner, MSc
>>
>> https://soundcloud.com/christian-gmeiner
>

greets
--
Christian Gmeiner, MSc

https://soundcloud.com/christian-gmeiner