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 *