Please keep it on-list. This is really important to get this debugged properly.
On Thursday 19 November 2009 00:23:18 Oncaphillis wrote: > On 11/18/2009 11:59 PM, Michael Buesch wrote: > >> What kind of device is that? Some laptop? I only knew about embedded > >> devices > >> using these wireless cards without sprom. > >> Is the card connected via (mini)pci? Or is it on-board? > >> > >> What we need is a way to identify the card so we avoid accessing > >> the dangling bus to the sprom. I'd like to avoid the read-the-first-word- > >> and-check-if-its-all-ones approach, because accesses a dangling bus. > >> That's obviously no good and can hang the CPU due to missing bus acks. > >> > >> What's the lspci -vvnn output for the card? > >> > > > > Note that the chipcommon revision on the card is 0x16. That's a pretty high > > number. > > I wonder if they changed something and there actually _is_ an sprom on the > > card, > > but there's just a new way to access it (or the shadow area has to be > > mapped through > > chipcommon first or something like that)... > > > It's an acer aspire one d250 netbook Nice. Is it possible to open the device and take a picture of the card? It's trivial to find out this way whether it has a SPROM or not, because it's a separate chip. Is it this device? http://hax0rpedia.com/index.php/Disassembeling_the_AAO_D250 Can you open the lower-right cover shown here: http://hax0rpedia.com/index.php/File:Aao_d250_step2.jpg and take a closeup picture of the wireless card? Also probably a picture of the backside of the card. That'd require removing the card, though. We really need to find out somehow if there is a SPROM chip on the device and if that's the case how to access it. > You may have a look at the full lspci -vvnn output at: Nice, thanks. > I did a "read the first word". Surprisingly it succeeds the first time. > After that I may still read 32bit words. When the module tries to read > the sprom the second time looking for a larger sprom the first read16 > fails. Well, my guess is that _any_ subsequent 16bit read would fail from then on, because it was still waiting for the bus-ack of the first one. If the bus really is dangling, we must avoid to access it in the first place. > Should I try to dump out the full 16k area reported for the device ? I don't think that would be useful. -- Greetings, Michael. _______________________________________________ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
