+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.gmei...@gmail.com> wrote: > Hi Bin, > > > 2016-06-28 3:15 GMT+02:00 Bin Meng <bmeng...@gmail.com>: >> Hi Christian, >> >> On Mon, Jun 27, 2016 at 8:37 PM, Christian Gmeiner >> <christian.gmei...@gmail.com> wrote: >>> Hi Bin >>> >>> >>> 2016-06-27 14:05 GMT+02:00 Bin Meng <bmeng...@gmail.com>: >>>> Hi Christian, >>>> >>>> On Mon, Jun 27, 2016 at 6:59 PM, Christian Gmeiner >>>> <christian.gmei...@gmail.com> wrote: >>>>> Hi Bin, >>>>> >>>>> 2016-06-17 4:10 GMT+02:00 Bin Meng <bmeng...@gmail.com>: >>>>>> Hi Christian, >>>>>> >>>>>> On Fri, Jun 17, 2016 at 4:13 AM, Christian Gmeiner >>>>>> <christian.gmei...@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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot