Re: [U-Boot] u-boot: x86: interrupt mapping
+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.... (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
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.... (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
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.... (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
[1] https://github.com/LongSoft/UEFITool
Best regards,
*Jian Luo DC-IA/EAH2*
Tel. +49(9352)18-4266
*Be**QIK *
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.... (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
Regards, Bin
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.... (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
Regards, Bin
Best regards,
*Jian Luo DC-IA/EAH2*
Tel. +49(9352)18-4266
*Be**QIK *
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.... (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
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.... (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
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.... (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
greets -- Christian Gmeiner, MSc
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 *
participants (3)
-
Bin Meng -
Christian Gmeiner -
Jian Luo