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.l...@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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
