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
