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
signature.asc
Description: This is a digitally signed message part
