[ath9k-devel] ar9223 with caldata on flash (no eeprom) under openwrt

[ath9k-devel] ar9223 with caldata on flash (no eeprom) under openwrt

[Luca Olivetti]

[asked this on openwrt-devel with no replies, hope I have more luck here]

Hello,

I have a router based on the infineon danube (mips) with an ar9223 as 
the wifi chip.
The chip has no eeprom and uses the system flash for calibration data.
I'm trying to run openwrt on it, and since there's another mips based 
family of boards running openwrt with ath9k and caldata in flash (the 
ar71xx), I "stole" most of the code from it trying to adapt it to my board.
The first hurdle is that the chip identifies itself as 168c:ff1d instead 
of 168c:0029. I see that the ar71xx does a fixup writing some registers 
from caldata, so I did the same, but I ended up with a strange 
endianness problem (strange because both platforms are mips based and 
should have the same endianness).
I blindly adapted the code from here (since I don't have documentation 
of the registers of the ar9223):

https://dev.openwrt.org/browser/trunk/target/linux/ar71xx/files/arch/mips/ar71xx/pci-ath9k-fixup.c

         /* set pointer to first reg address */
         cal_data += 3;
         while (*cal_data != 0xffff) {
                 u32 reg;
                 reg = *cal_data++;
                 val = *cal_data++;
                 val |= (*cal_data++) << 16;

                 __raw_writel(val, mem + reg);
                 udelay(100);
         }

         pci_read_config_dword(dev, PCI_VENDOR_ID, &val);
         dev->vendor = val & 0xffff;
         dev->device = (val >> 16) & 0xffff;

But if I do it this way I get an id of 2900:8c16, which is obviously 
byte swapped from the correct one (and that's what puzzles me, note that 
the ar71xx code checks for the 0xa55a magic at the beginning of caldata, 
and that's exactly what I have).

So I changed the

                val = *cal_data++;
                val |= (*cal_data++) << 16;

to

                val = swab16(*cal_data++) << 16;
                val |= swab16(*cal_data++);

and now I get the correct id, but I'm not sure it's right.

This is what I have at the beginning of caldata, byte by byte:

A5 5A              (magic)
00 00 00 03        (bytes skipped by the above routine)
60 00 16 8C 00 29  (it appears to be vid:pid, at register 0x6000)
60 08 00 01 02 80
60 2C 16 8C 20 91  (another vid:pid?)
50 00 16 8C 00 2A  (yet another?)
50 08 00 01 02 80  (same data as at 0x6008)
50 2C 16 8C 20 91  (same data as@0x602C)
50 64 0C C0 05 04
50 6C 38 11 00 03
40 04 07 3B 00 40
40 74 00 03 00 00
40 00 00 00 01 C2
60 34 00 44 00 00
FF FF 00 00 00 00  (end of data)


what I end up writing with the above loop is

0x6000 -> 8c162900
0x6008 -> 10008002

etc.


Since I'm using openwrt, I also made the changes so that ath9k uses the 
caldata from flash, it checksums ok, the wifi works, I can associate but 
the performance is 10% of what I can achieve with a nearby card, hence 
my doubts on both operations (the pci fixup and the reading of caldata 
from flash).

Bye
-- 
Luca

[ath9k-devel] ar9223 with caldata on flash (no eeprom) under openwrt

[Luca Olivetti]

En/na Luca Olivetti ha escrit:
> [asked this on openwrt-devel with no replies, hope I have more luck here]

It seems I hadn't :-(
Do I suck so badly at formulating questions?

> 
> Hello,
> 
> I have a router based on the infineon danube (mips) with an ar9223 as 
> the wifi chip.
> The chip has no eeprom and uses the system flash for calibration data.
> I'm trying to run openwrt on it, and since there's another mips based 
> family of boards running openwrt with ath9k and caldata in flash (the 
> ar71xx), I "stole" most of the code from it trying to adapt it to my board.
> The first hurdle is that the chip identifies itself as 168c:ff1d instead 
> of 168c:0029. I see that the ar71xx does a fixup writing some registers 
> from caldata, so I did the same, but I ended up with a strange 
> endianness problem (strange because both platforms are mips based and 
> should have the same endianness).
> I blindly adapted the code from here (since I don't have documentation 
> of the registers of the ar9223):
> 
> https://dev.openwrt.org/browser/trunk/target/linux/ar71xx/files/arch/mips/ar71xx/pci-ath9k-fixup.c
> 
>          /* set pointer to first reg address */
>          cal_data += 3;
>          while (*cal_data != 0xffff) {
>                  u32 reg;
>                  reg = *cal_data++;
>                  val = *cal_data++;
>                  val |= (*cal_data++) << 16;
> 
>                  __raw_writel(val, mem + reg);
>                  udelay(100);
>          }
> 
>          pci_read_config_dword(dev, PCI_VENDOR_ID, &val);
>          dev->vendor = val & 0xffff;
>          dev->device = (val >> 16) & 0xffff;
> 
> But if I do it this way I get an id of 2900:8c16, which is obviously 
> byte swapped from the correct one (and that's what puzzles me, note that 
> the ar71xx code checks for the 0xa55a magic at the beginning of caldata, 
> and that's exactly what I have).
> 
> So I changed the
> 
>                 val = *cal_data++;
>                 val |= (*cal_data++) << 16;
> 
> to
> 
>                 val = swab16(*cal_data++) << 16;
>                 val |= swab16(*cal_data++);
> 
> and now I get the correct id, but I'm not sure it's right.
> 
> This is what I have at the beginning of caldata, byte by byte:
> 
> A5 5A              (magic)
> 00 00 00 03        (bytes skipped by the above routine)
> 60 00 16 8C 00 29  (it appears to be vid:pid, at register 0x6000)
> 60 08 00 01 02 80
> 60 2C 16 8C 20 91  (another vid:pid?)
> 50 00 16 8C 00 2A  (yet another?)
> 50 08 00 01 02 80  (same data as at 0x6008)
> 50 2C 16 8C 20 91  (same data as at 0x602C)
> 50 64 0C C0 05 04
> 50 6C 38 11 00 03
> 40 04 07 3B 00 40
> 40 74 00 03 00 00
> 40 00 00 00 01 C2
> 60 34 00 44 00 00
> FF FF 00 00 00 00  (end of data)
> 
> 
> what I end up writing with the above loop is
> 
> 0x6000 -> 8c162900
> 0x6008 -> 10008002
> 
> etc.
> 
> 
> Since I'm using openwrt, I also made the changes so that ath9k uses the 
> caldata from flash, it checksums ok, the wifi works, I can associate but 
> the performance is 10% of what I can achieve with a nearby card, hence 
> my doubts on both operations (the pci fixup and the reading of caldata 
> from flash).

-- 
Luca

[ath9k-devel] ar9223 with caldata on flash (no eeprom) under openwrt

[Peter Stuge]

Luca Olivetti wrote:
> > [asked this on openwrt-devel with no replies, hope I have more luck here]
> 
> It seems I hadn't :-(
> Do I suck so badly at formulating questions?

Not at all.

Sadly this list is rather useless for detailed technical discussion.


//Peter

[ath9k-devel] ar9223 with caldata on flash (no eeprom) under openwrt

[Adrian Chadd]

I think a large part of the problem here is that the focus of the
active technical developers is elsewhere. You should see what trouble
I've had getting questions answered here for the pre-AR9200 stuff. :-)

Eg, trying to figure out the above - I have no idea. "10% of expected
performance" is pretty low, but is it a hardware poking problem, or is
it a wifi configuration problem? How do you know, for example, that
all of the board PCI/interrupt stuff is setup right? Are there any
other PCI devices that are working at the correct throughput?

The fact the PCI IDs are different may also be of interest. Have you
done some digging to try and establish why that is the case?

Finally, is there any vendor-supplied code for this board?


Adrian

On 17 December 2010 16:23, Peter Stuge <peter@stuge.se> wrote:
> Luca Olivetti wrote:
>> > [asked this on openwrt-devel with no replies, hope I have more luck here]
>>
>> It seems I hadn't :-(
>> Do I suck so badly at formulating questions?
>
> Not at all.
>
> Sadly this list is rather useless for detailed technical discussion.
>
>
> //Peter
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>

[ath9k-devel] ar9223 with caldata on flash (no eeprom) under openwrt

[Luca Olivetti]

En/na Adrian Chadd ha escrit:
> I think a large part of the problem here is that the focus of the
> active technical developers is elsewhere.

Where?

> You should see what trouble
> I've had getting questions answered here for the pre-AR9200 stuff. :-)
> 
> Eg, trying to figure out the above - I have no idea. "10% of expected
> performance" is pretty low, but is it a hardware poking problem, or is
> it a wifi configuration problem? How do you know, for example, that
> all of the board PCI/interrupt stuff is setup right?

Well, I don't, I just hope that it is so.

> Are there any
> other PCI devices that are working at the correct throughput?
>

IIRC the wifi chip is the only device on PCI (but I could be wrong, I'll 
double check when I can).


> The fact the PCI IDs are different may also be of interest. Have you
> done some digging to try and establish why that is the case?

Most probably because the device has no internal eeprom. Apparently the 
ar71xx platform had the same kind of problem, fixed by poking some 
registers with the data from the flash, but I don't have any ar71xx 
device to test, I just inferred that from the openwrt code (hence my 
original question)

> Finally, is there any vendor-supplied code for this board?

No, the board originally uses a propietary os with no documentation (and 
much less sources) available (in fact they went out of their way to 
obfuscate the original firmware in order to make it difficult to load 
alternatives), however

1) from the log messages it seems it's using ath9k (i.e. the messages 
are exactly the same as the ones I found in ath9k sources)

2) even the original firmware identifies it as ff1d, but then it sees it 
as 0029 (just like after the pci fixup I copied from the ar71xx but with 
the endianness problem I asked about).

Bye
-- 
Luca