On Thu, Nov 19, 2009 at 12:39 AM, Michael Buesch <m...@bu3sch.de> wrote: > 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.
Hmm... this kinda reminds me of when the SPROM died on my Asus 4318, causing it to display as a "14e4:0008", and freeze immediately upon any SPROM read/write attempt. Quite possibly we have something similar here (there is an SPROM, but it's broken - without an SPROM, the card AFAIK can't even produce a valid PCI ID). > > 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 > -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) _______________________________________________ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
