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

[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@gmail.com> wrote:
> Hi Bin,
>
>
> 2016-06-28 3:15 GMT+02:00 Bin Meng <bmeng.cn@gmail.com>:
>> Hi Christian,
>>
>> On Mon, Jun 27, 2016 at 8:37 PM, Christian Gmeiner
>> <christian.gmeiner@gmail.com> wrote:
>>> Hi Bin
>>>
>>>
>>> 2016-06-27 14:05 GMT+02:00 Bin Meng <bmeng.cn@gmail.com>:
>>>> Hi Christian,
>>>>
>>>> On Mon, Jun 27, 2016 at 6:59 PM, Christian Gmeiner
>>>> <christian.gmeiner@gmail.com> wrote:
>>>>> Hi Bin,
>>>>>
>>>>> 2016-06-17 4:10 GMT+02:00 Bin Meng <bmeng.cn@gmail.com>:
>>>>>> Hi Christian,
>>>>>>
>>>>>> On Fri, Jun 17, 2016 at 4:13 AM, Christian Gmeiner
>>>>>> <christian.gmeiner@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

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

[Christian Gmeiner]

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?

greets
--
Christian Gmeiner, MSc

https://soundcloud.com/christian-gmeiner

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

[Jian Luo]

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
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.
>
> greets
> --
> Christian Gmeiner, MSc
>
> https://soundcloud.com/christian-gmeiner
[1] https://github.com/LongSoft/UEFITool

Best regards,

*Jian Luo
DC-IA/EAH2*

Tel.  +49(9352)18-4266

*Be**QIK
*

-------------- next part --------------
A non-text attachment was scrubbed...
Name: fsp.bin
Type: application/octet-stream
Size: 139264 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160719/508318ef/attachment-0001.bin>

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

[Bin Meng]

Hi Jian,

On Tue, Jul 19, 2016 at 4:03 PM, Jian Luo <Jian.Luo4@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?

> 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

[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@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
*

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

[Christian Gmeiner]

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

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

[Jian Luo]

Hi Christian,

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

- then replace them in-place

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.

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

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

[Christian Gmeiner]

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

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

[Jian Luo]

Hi Christian,

On 20.07.2016 10:22, Christian Gmeiner wrote:
> 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 :(
I don't think it's a busy loop. This Bug?:
https://patchwork.ozlabs.org/patch/446555/

>
> At what place do you do the in-place patching? I hoped to do it at
> init_board setup.
I mean in UEFITool select the "PE32 image section", right click "Extract 
body", do binary patching using your favorite hex editor, right click 
"Replace body".
>> 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.
Maybe you can try the fsp.bin I sent, to see if it runs
>
Since it's a bit off-topic, should we exchange information w/o ccing the 
list?

Best regards,

*Jian Luo
DC-IA/EAH2*

Tel.  +49(9352)18-4266

*Be**QIK
*