+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