Hi Luca,

I have the same problem with my WAG160Nv2: Broadcom 6358 SoC with Atheros 
AR9223 and calibration data
in the flash (unfortunately overwritten by my first boot of OpenWRT).


On 12/08/2010 12:53 PM, Luca Olivetti wrote:
> Al 05/12/10 15:38, En/na Luca Olivetti ha escrit:

>> Since the endianness of the ar71xx and the danube should be the
>> same, maybe the key is the layout of the data in caldata.

Are you sure that the endianess is the same? MIPS may run in big or little 
endian,
it is usually determined by external configuration (resistors).


>> This is what I have, byte by byte:
...
>> what I end up writing with the above loop is
>> 
>> 0x6000 -> 8c162900 0x6008 -> 10008002
>> 
>> etc.
>> 
>> and with that I seem to get the correct vid:pid with
>> 
>> pci_read_config_dword(dev, PCI_VENDOR_ID, &val); dev->vendor = val
>> & 0xffff; dev->device = (val >> 16) & 0xffff;
> 
> I could really use some help here :-/

AFAIR PCI access is _always_ in little endian.
So the original code:

       /* 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);
        } 

may just need a conversion of val to little endian before writing:
                __raw_writel(cpu_to_le32(val), mem + reg);

This should yield the same result as your code changes, e.g.

> 60 00 16 8C 00 29
-> val = 0x0029168c, cpu_to_le32(val) == 0x8c162900

I don't know if _raw_writel is the correct way to access PCI registers or
if there are other procs which hide the endian from the caller.

> Wifi is working but performance is atrocious (10% the throughput of a
> nearby card), so I'm not sure what I did is correct (even if the
> calibration data checksums ok).

I guess the data from your previous post is only the data used for the
PCI registers setup (vendor, product, subsys, ...) WLAN calibration stuff 
usually is much more.
Maybe you missed to load this part? With my device I have at offset 0x1000 a 
small area starting
with 0xa5 0x5a, just 80 bytes long. At offset 0x1200 I got other data, length ~ 
0xce0, which I guess
are the real WLAN calibration data. I haven't looked into the ath9k sources to 
find the structure
of the WLAN calibration data.


Regards,
Joerg.
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Reply via email to