On 02/27/2010 01:45 PM, Gábor Stefanik wrote: > > So, a quick status update, from what I've found yesterday: > > 1. We get the PMU setup wrong. Bit 0x200 is being set, despite the > PMU being rev1. Also, PMU setup is done too early - at least wl reads > the SPROM before setting up the PMU. A write of 0xcbb to offset 0x618 > is also missing - I seem to remember that this change has been tried > already, to no avail; but it may be a prerequisite of the real fix. > 2. Just before the SPROM readout, we are missing a "Set 0x8000 in > MMIO offset 0x280a". This looks curiously like "PCI-E Miscellaneous > Configuration", from http://bcm-v4.sipsolutions.net/PCI-E - and > indeed, the value read out from 0x280a is identical to offset 0xa in > my SPROM. So, the right thing to do here is probably "Switch to the > PCIE core, set 0x8000 in MIMO offset 0x80a (or maybe 0x1000a?), switch > back to ChipCommon". I don't know what core is active during this > write, as mmiotrace doesn't catch pci_read/write_config_dword calls. > Larry, do you know a way to monitor PCI config space access in a way > that can be matched (e.g. using timestamps) to the MMIO trace?
The printk's I sent yesterday can have timing info, but the timestamps would not be exactly coordinated - printk values seem to be generated when logged, not when requested. > 3. Right after the SPROM is read, wl writes zeros to MMIO offsets > 0x58 and 0x5c (32-bit), then does the PMU setup. These are not valid > registers for ChipCommon and PCIE, but for 802.11, they fall directly > into the DMA area! So, if these writes happened with the 802.11 core > active, they are probably significant. That sounds promising. I think I found the section, which will have the following specs: 1. If the Chip Common revision >= 20 a. Save the current core index a. Set core to chip common a. Write 0 to GPIO Pullup (register 0x58) a. Write 0 to GPIO Pulldown (register 0x5C) a. Restore the original core 1. If PMU Control Enabled a. Init the PMU ... A quick look ar the code suggests this should go into ssb_chipcommon_init() just after the return for not having a chip common. In addition, chip common will already be selected, thus that part can be skipped. > I second Larry's question: where are the specs for the PMU init code? >From what Michael replied, they do not exist in a public place other that the reference code for embedded systems. I have started them - there is now a PMU Init page and I'll fill them in as I can. If you have a specific routine, let me know. Larry _______________________________________________ Bcm43xx-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
