From mboxrd@z Thu Jan  1 00:00:00 1970
From: Luca Olivetti <luca@ventoso.org>
Date: Fri, 17 Dec 2010 09:09:45 +0100
Subject: [ath9k-devel] ar9223 with caldata on flash (no eeprom) under
 openwrt
In-Reply-To: <4D013A9D.7080404@ventoso.org>
References: <4D013A9D.7080404@ventoso.org>
Message-ID: <4D0B1AC9.6040502@ventoso.org>
List-Id: <ath9k-devel.lists.ath9k.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: ath9k-devel@lists.ath9k.org

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