On Saturday 27 February 2010 20:45:50 Gábor Stefanik wrote: > 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
Well, 0x280a and 0x80a basically is not the same in my part of the world. To ask it again: Is it possible that the 0x2000 bit of the address comes from some random burp/bug in the tracing code? It _really_ doesn't make any sense, because it's beyond the mapped space of the device. > 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? > 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! The writes (_if_ they happen on the 802.11 core) fall into the interrupt status and masks of the 8th DMA engine (they do not fall into the MMIO of the DMA engines). We don't use the 8th engine. It probably is a good idea to write zeros to the mask register anyway, so I'll spin up a quick test patch. -- Greetings, Michael. _______________________________________________ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
