Guys, As promised the output. The data read is the data read from the SPROM. As you can see the default read16 routine outputs only useless information. Bcm43xx_read32 only outputs the low 16 bits for the 4 byte aligned addresses (as expected), and only doing 2 8 bit accesses (one for the low byte and one for the high byte) clearly doesn't work very well either. Using the code as described in the previous post, the data in the last table looks promising, but for the low byte on the word boundary addresses.
Regards, Rogier default bcm43xx_read16 routine: FDFD FDFD FDFD FDFD FDFD FDFD FDFD 0600 FDFD FDFD FDFD FDFD FDFD FDFD FDFD FDFD FDFD 0600 FDFD FDFD FDFD FDFD FDFD FDFD FDFD FDFD FDFD 0600 FDFD FDFD FDFD FDFD FDFD FDFD FDFD FDFD FDFD 0600 FDFD FDFD FDFD FDFD FDFD FDFD FDFD FDFD FDFD 0600 FDFD FDFD FDFD FDFD FDFD FDFD FDFD FDFD FDFD 0600 FDFD FDFD FDFD FDFD FDFD FDFD using bcm43xx_read32 routine: 00000000 00001010 00000000 00001000 00000000 00008000 00000000 00000002 00000000 00001800 00000000 00000000 00000000 0000FFFF 0000A002 0000FFFF 00000000 0000FFFF 00000000 0000FFFF 00000000 0000FFFF 00000000 0000FFFF 00000000 0000FFFF 00000000 0000FFFF 00000000 0000FFFF 0000A002 0000FFFF 00000000 0000FFFF 00000000 0000FFFF 00000000 00004BB9 00000000 0000FFFF 00000000 0000FFFF 00000000 0000FFFF 00000000 0000FFFF 0000A002 000014AA 00000000 0000FE9F 00000000 0000FFFF 00000000 0000FFFF 00000000 0000FFFF 00000000 00003A49 00000000 00005553 00000000 0000FFFF 0000A002 0000BE02 Reading high byte and low byte separately: 0000 0000 0004 003C 0002 0000 000C 0002 0010 0000 0014 0000 0018 00FF 001C 00FF 0020 00FF 0024 00FF 0002 00FF 002C 00FF 0030 00FF 0034 00FF 0038 00FF 003C 00FF 0040 00FF 0044 00FF 0002 00B9 004C 00FF 0050 00FF 0054 00FF 0058 00FF 005C 00AA 0060 009F 0064 00FF 0002 00FF 006C 00FF 0070 0049 0074 0053 0078 00FF 007C 0002 Using the code described in the previous post: 4001 0000 1205 103C 43A0 8000 000D 0002 1011 1800 0015 0000 FF19 FFFF FFA0 FFFF FF21 FFFF FF25 FFFF FF29 FFFF FF2D FFFF FFA0 FFFF FF35 FFFF 0039 FFFF FF3D FFFF FF41 FFFF FFA0 FFFF 0049 4BB9 234D FFFF FF51 FFFF FF55 FFFF FFA0 FFFF 305D 14AA FA61 FE9F FF65 FFFF 0069 FFFF FFA0 FFFF 0071 3A49 FF75 5553 FF79 FFFF FF7D BE02 On Mon, 15 May 2006, Rogier Stam wrote: > Johannes Berg wrote: > > >On Sat, 2006-05-13 at 00:37 +0800, Rogier Stam wrote: > > > > > >>I should have written it differently :) The default mode is indeed > >>little endian (however snapgear (distro), redboot and uClinux default > >>use big endian unless you change it), but I run the processor in big > >>endian. For word accesses the IXP425 automatically does the byteswapping > >>part to ensure that the PCI bus gets written as little endian. So in > >>short, the bcm4306 which is connected to the PCI bus (little endian) > >>gets written to by the processor running in big endian mode. I wasn't > >>aware about the PCI bus being treated in a different endianness, that > >>one I had to look up :) > >> > >> > > > >PCI is always LE. > > > > > > > >>My actual mac address should be 00904BB9238F. Lately though, the MAC > >>address the driver reports is fe:dd:06:00:fe:dd, although that one has > >>varied before also. > >> > >> > > > >That looks very strange, not even the bits are there properly, not even > >bit-reversed or something. > > > > > > > >>Looking more into the issue (and asking around) I found the IXP425 > >>processor has a problem whenever 16 bit pci reads are done (described > >>here: http://developer.intel.com/design/network/applnots/300375.htm). > >>Could this be causing the problem? > >> > >> > > > >I guess it could. Not being a hardware engineer or even close I don't > >really understand the appnote, sorry. > > > > > > > >>As the driver uses 16 bit PCI reads rather regularly (bcm43xx_read16), I > >>was wondering if it was possible to do byte or dword reads instead, then > >>converting this to 16 bit. As an experiment I have tried modifying the > >>bcm43xx_read16 routine to do two byte reads then converting this to a > >>word, and also 1 dword read (checking for correct address alignment) and > >>converting this to a word. But so far I have not been successfull yet. > >>In fact, doing this conversion (2x8bit or 1x32) read instead still gives > >>me an SPROM checksum error (same as with 16 bit reads), but also an > >>error that the tssi2dbm table could not be generated. > >>If anyone has some suggestions, I'd be very much open to it. Also note, > >>I tried doing the 32 bit and 2x 8 bit read in the hopes that the > >>hardware supports it (something which (according to PCI specification > >>2.2) is up to the hardware implementer). I'm not even sure it does. > >> > >> > > > >I'd think the hardware allows only 16-bit accesses to the 16-bit > >registers and 32-bit accesses to the 32-bit registers. Not sure though. > >The SPROM might be accessible as word- or byte-reads. > > > >Can you hack up the driver to just export the SPROM as byte-reads and > >see what that gives us? > > > >johannes > > > > > Hi Johannes, > > Just a quick reply. I haven't had much access to the machine this > weekend, I did do the test though (I'll post the results (printk > messages I added) later). In short, 32 bit transfers definetly don't > work. The high 16 bits always read 0, and ofcourse it can only read > addresses aligned on 4 byte boundaries (reading on 2 byte boundary reads > back all 0). The low 16 bits seem to read correct values. Reading back > 16 bits produces a garbled output (usually all registers read F7DD or > some such). Reading back 8 bits also produces odd results. I tried > replacing the 16 bit read in bcm43xx_read16 with two byte reads, and > printing out all registers. This produces garbled contents on all bytes. > Using the following routine instead of bcm43xx_read16 in > bcm43xx_sprom_read produces mostly correct results, but unfortunately > not on all words: > static inline > u16 bcm43xx_spromread16( struct bcm43xx_private *bcm, u16 offset ) > { > u16 result; > void __iomem *mmio_addr=bcm->mmio_addr + core_offset( bcm ) + > offset; > > ioread8( mmio_addr ); > ioread8( mmio_addr + 1 ); > result=(u16) ioread8( mmio_addr ); > ioread8( mmio_addr ); > result+=(((u16) ioread8( mmio_addr + 1)) << 8); > return result; > } > > Note that in the following I mean with a 2 byte aligned address address > 0x2, 0x6, 0xA, etc, and with a 4 byte aligned address 0x0, 0x4, 0x8, etc.. > This produces correct readouts on the high bytes of all words, and of > the low bytes on all 4 byte aligned words. The low byte on all 2 byte > aligned words seems to be an index value or something as it counts up. > My description might be a little vague, I'll post the results tomorrow > so you guys can see what I mean. The reasoning behind me thinking the > output is correct is that I can read most bytes of the correct MAC > address back, and part of the MAC address (using the above mentioned > code) seems to show up correctly on wlan0. > It does however not solve the checksum error, which would be logical as > not all data is correct. > I'll try a few more combinations to see if i can get the high byte to > reliably show up also. > I agree that this is not a good workaround, a dirty one in fact. But > seeing as the other option is a hardware modification I can't do I'm > afraid I have little choice.... > > This however does lead me to conclude that the bug most likely is not in > the sourcecode, but in the 16 bit PCI transfers :( > I'm open to any suggestions you guys might have. > > Regards, > > Rogier > _______________________________________________ Bcm43xx-dev mailing list [email protected] http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
