Send users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://rt2x00.serialmonkey.com/mailman/listinfo/users_rt2x00.serialmonkey.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of users digest..."
Today's Topics:
1. Re: [PATCH] rt2x00: Fix efuse EEPROM reading on PPC32.
(David Joshua Geary)
2. Re: Porting Rt2x00 to PIC24 (Ytai Ben-Tsvi)
----------------------------------------------------------------------
Message: 1
Date: Sat, 19 Nov 2011 08:12:59 +1100
From: David Joshua Geary <[email protected]>
To: [email protected]
Subject: Re: [rt2x00-users] [PATCH] rt2x00: Fix efuse EEPROM reading
on PPC32.
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 17/11/11 12:00, [email protected] wrote:
> diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c
> b/drivers/net/wireless/rt2x00/rt2800lib.c
> index 3f183a1..1ba079d 100644
> --- a/drivers/net/wireless/rt2x00/rt2800lib.c
> +++ b/drivers/net/wireless/rt2x00/rt2800lib.c
> @@ -3771,7 +3771,7 @@ static void rt2800_efuse_read(struct rt2x00_dev
> *rt2x00dev, unsigned int i)
> /* Apparently the data is read from end to start */
> rt2800_register_read_lock(rt2x00dev, EFUSE_DATA3, ®);
> /* The returned value is in CPU order, but eeprom is le */
> - rt2x00dev->eeprom[i] = cpu_to_le32(reg);
> + *(u32 *)&rt2x00dev->eeprom[i] = cpu_to_le32(reg);
> rt2800_register_read_lock(rt2x00dev, EFUSE_DATA2, ®);
> *(u32 *)&rt2x00dev->eeprom[i + 2] = cpu_to_le32(reg);
> rt2800_register_read_lock(rt2x00dev, EFUSE_DATA1, ®);
Thank you so much (Gertjan, Ivo, and everyone else who has helped with
rt2x00 so far). This patch (with a little massaging because the code in
Linux 3.1.0-rc4 which I am using looks a little different), combined
with ivd's suggestion on Freenode #rt2x00 to disable hardware encryption
successfully got this ageing PowerPC online.
There are still issues, but I am extraordinarily happy about the current
functionality.
1. Software encryption works but hardware encryption does not work
(Again suspect endianness issues since hardware encryption works on an x86)
2. The console gets spammed with messages of the form
2.1. 'phy0 -> rt2x00mac_conf__tx: Info - Configured TX queue X -' ...
2.2. 'cfg80211: Calling CRDA to update world regulatory domain'
I don't know how current these issues are since I am using Linux
3.1.0-rc4 which is neither the current stable release nor the current
mainline release.
I don't know how much the rt2x00 code has changed in the Linux 3.2-rc2
release compared to the Linux 3.1.0-rc4 release...
- --
David Joshua Geary
UNE Linux User Group: [email protected] <http://lugune.dyndns.org>
I don't care what software you use so long as
we only exchange files in open data formats
Open-Document <http://en.wikipedia.org/wiki/Open_Document>
Ogg <http://en.wikipedia.org/wiki/Ogg>
PDF <http://en.wikipedia.org/wiki/Pdf>
- -----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.10 (GNU/Linux)
mQINBE0JY54BEAD2D3ckM+FTElSG6w89L1PkeB+m8+8K5ZJZKfLJXWv7NNTRS5DC
uJd/OrlQwC4Ecwkp4HqmjF8jYzCeLEnC7SR6VU3j05l1vR7pZvphUx7lYBbhXbV/
ykBQBK9AWQwf1ve3G2+hGRAeYmhSzen3Px06aBq4/nr3adF1JFekV5CyCuHxDriT
p7HMqEwCvRExnaJD45VKzCQiCYLDYkgVc5u+yBWHd92Jk0DHtm6T/CuoLsoYPIgU
Jy8sNFdGE9cC3Nb6Ay/Je4FUlKqu9xNej7KGF0SNVjfD7+bMlB37uaDSk1vLGkmg
rhnR78YTdZ2iE2hcbae8l/N9aFWUHfxnuHEew/imTJgaBOMOp6k3FGIFG+1qznnG
UlXBMR7gY5jyPKTLe0iJo5MCylKeS56uyDgGv8FtGD73MRqGxktR5b8Zv4Wjv0cz
S4yBT8dvAYohw8UeRF4EKQlmxX7rusaipXCe/lGyuytfNFJ77EHMESzVkM/da0qk
Zt2sotf83XXE+h6lsUDee1whNDtNvaYmTziKZVHJ3olP3kg+FglgoWKG/y5QQHtW
ASa4tnlnNFVGJaOBVnVOq5RsrmQ+YSmYsm/OfjzAthc3QM5BhQhB381y4lKtFo1S
G7qChNSpA29ea1Muqgz3fDlP3m4iHo1AFvBTgpvEIh/Eb8MXSmeHxmEk0QARAQAB
tD9EYXZpZCBHZWFyeSAoR01haWwgRW1haWwgU2lnbmluZyBLZXkpIDxiaWFuY2Eu
dXJhbnVzQGdtYWlsLmNvbT6JAjgEEwECACIFAk0JY54CGyMGCwkIBwMCBhUIAgkK
CwQWAgMBAh4BAheAAAoJEMR6DgDuR4IfvsUQALCnZfpyz39BQT609n0m+wLZg8CX
uTnCf1m+oZj5W11oqqZd0XcHc1o4n6F6VNvSULHCgNYP6kOnJHliBX53Qdr7muJz
qQSwtywaS6oQUHWJk++youkvBqV/A4tiggEsXKzdQx/F+o2sIWQ4VGR3NlLkOJa4
xddVAGLuYHmOt1OenwfFXUFodmcPSWwnyVu9E8cm7iZxdg66u/fEraY4pC2yI2Zi
T0c1NRVA6ytqo/t4V2wmysZLj9r+O3q88ncUTg1qcVNS32eEVxZJS1R0y7MyM+Gr
lh6OI+VrhkfQ/DawvsAqHxxgMWMrzBQUa9ss7mPlawZWOSBiBLtckYHpPJje21ze
EPzhPub7EnXfenLWIHG2+O0FIkPIu5OSRwHtAgkTXBXtrzzyMIU/cFsuI0D2Da6m
w4QSlEAb8hWGS5LqaM/8i+eaTDL7XgZ9Z7OibS4lzcUnZZOW5dzHIqDVK77c57If
rG2cin/GChsYrlckN1XrvlulSXYu08D/xL4f39sUZexiyYZtLoWas+MvOboGgc8o
MfE7U92gXb1l4hm3iKXHzaYdBC1YqxMdgy9RBDaSbHq3n0pFpCGW8SURtuOlkVbq
kgwPq6v1obb0ZvpE3cLPN8PhqSWxbM4sEYYo6jDAaTRkv/Cy/faEQuCJ+wmVT2bu
deYspeWy73rGANavuQINBE0JY54BEADD+h4XyQmbyfNrsmPjHlqJtmZHojtiZZKZ
nKoawdLex/L7XJBXfNhTu1kwCV2fW1HibyUW/a5m41H9ked5gScR8bEn02liXc6c
Ad6rAMSY9H2/5+FXcGPJqV/9VJTNC8FTEADmJzHzENLDcpil1jXkYDwSn5wYYsmS
1GtT4jsRkGZYzXerPs3JfpxTFuVQWTsodyzfs+YwnNVIcAX4yBrg5WSRPlbHC0WP
VQxqFVdDDq0RN11+2sM6BYVvnL1fX69TN4MAPhBjbYalIt0Ls9dGjn/aiB0E1nEn
QfRcQb939gJQV5LLKxICc9Qa/GfMFjt6OYArZ8RzMvIs7WGdFXG0GuU/DjHRI65U
f7Ed7bGZw9S0ZAjawH8q1/JeUkNtbMCz5oRvvhYTXOw3WLXCeTPALJ6XU7fRTY48
rIDxpvoxyE4mMoNnn1ZE5rcIbCza0tDD3FUPae6i6Mixnk0hXGirwnwPuJyFi3Io
zibtMzuoju7l2gKzhZVcp4HlERhGTcEPfCaVIGy3j0k0nfc+hCySA59fXfs6UK5T
URhSKLb8+R/Ne0Fyiyg8ASdS8HPIs8Njw4CppfWX5Ds5NgwF5OALlYHkIKjn07Kc
+bGO+WWJvnZfo2fdjgPPs4ECaJL7L5RuVuy26QnPMLgAUNJLgGjugGoE0pOLSwmj
f3xOB4GlowARAQABiQIfBBgBAgAJBQJNCWOeAhsMAAoJEMR6DgDuR4If6LAQAIAx
WHngmPZ1vzraRVadFnQrYr4bpBT+Hznwm91HtAup8HgutSiulOY1Kbpra1avjmQi
MYCRQqDeOsFGirOomterbU18sXX7YBFbAT0c+rHoSdtFP2JTkSzN0Ocs1mZZuLfu
Dw/DSAaxlpkKQUJ5xn+qAOPr0fX2HbNcTc9kKYPNJJ9n7WtPhG6hC7ehjHis2jSz
Am3Ik+5gNZjaNkHsanaGTfx3mo/jf2AUGydB2quYPz8DFyTYN6q+VZ6+Vzy08RGz
MLWwM/SSMhT+GXrhSeuAiO26a70T0XTbhliccUDlG6ORPQ+ydzkffNQB35OfIkbA
+SoiDf1txduWDeJxblZ3feYqwBcjBBJU/ofEigH32z0ZOsFpWcJTsXSB2RyoJT+Y
Pb426uZYYTi2ZtWGcDtwRzK2lXM3WIHnoduFY5LIXq51c+cP2u8a461pmrlTvixE
y+IfX/zHfvSUnJDpnO4sA770oCHBUsbmU14oPdr+Kla67jqpjujap1ITRA96bcNm
K7O3vOKqbkAoy4w9ogCbBHrH1/8M+iRWA+0Iim+zhYSeEmjLszeecII9MH3u8CS0
DjLhpLrX6WG7F9fr0xAnc3Dui+qBm/q1dKenCKauUYWRgDPUXzP32oIiw/bXBp/4
qKbhUOJTXVVns4OnvPNzFoCvcNS6G/3ZGlX/6duU
=kv+y
- -----END PGP PUBLIC KEY BLOCK-----
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJOxspXAAoJEMR6DgDuR4IfVnYP/1qCfTnVUngJgJSJmHCuhAfW
2c17D0PIs5hb3I01BwfzivJYJXrfJ8EcxRcQlAZgOp/+elZ7SpsdcWIHhSBxiNMh
HgEFOJOEq8QPr6dFSn5giperFb3/YDP2waS2IzkWvG9Jx2Mkey7kIyF1xvatb7ZV
j22tTDgBeteD83LkzfqNubPt5VqzDjK7wHQFiRzEeRimINTNTfWUGG2qB5sce6fn
vh+VGdk5knSeMHtL+qWyelrq9DMLuG33mIQpZWIDzzjM66yyQZCdM3ozuH4/YTVd
xxoFvIihJM3vWn5Dr5vZNZX8VD5xJ9Hdi6j35M4r3fBZbnSCK9D+Gg7gUN9LX3aw
Ozpr4jOS1oCEAT4AEZSR5rUpIAdd+v3pCNBz+B1aSa/S6nvMdE78dJ1Df/6cSbi5
vZxpn4yK7193ZOtDw2GAACzMHpdS8d/ZvPmRSXypQmmBDfmLuHOOXOOst22GNW0e
Ytb9AQ41t2HuK1xLja8/YeibzIQ8Pk2FCODqBcFYw2qcZKKshGe7b8Rx7BxRskuM
3XJoqZPreChbQao3MWxUoEznUCWKts/0IypwiU4gYvV7j69mbbl2o3riUrCQhT7i
J7SPqXJqkodogWjUxBai6GRPOIbjj53r3Tfu/6ZrX+1eCbs/z5/gTkFcLzz7nlqA
OP0a5dXZyRjTXJAojNHQ
=1eMO
-----END PGP SIGNATURE-----
------------------------------
Message: 2
Date: Fri, 18 Nov 2011 13:18:52 -0800
From: Ytai Ben-Tsvi <[email protected]>
To: [email protected]
Subject: Re: [rt2x00-users] Porting Rt2x00 to PIC24
Message-ID:
<CANfwwrBMD9pVfCgOZ2wv7wKqBtCEBKKngAaS==8f7hyvcdk...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Due to the apparent lack of public interest, let me try a different
strategy :)
Can anyone share where the original authors of the RA5370 drivers got their
information on the device spec? I couldn't seem to find it anywhere on the
web and reverse engineering the driver code seems complicated and possibly
unnecessary.
Thanks again,
Ytai
On Thu, Nov 3, 2011 at 10:14 PM, Ytai Ben-Tsvi <[email protected]> wrote:
> Thanks, Peter!
> Let me try to explain my reasoning, so you might be able to tell me what
> I'm thinking wrong.
> On the USB layer, there's just a bulk in endpoint and several bulk out
> endpoint - from what I'm seen they're just used in parallel in order to
> increase throughput. That layer I can easily implement on the PIC - I've
> done similar things several times in the past. This would need no code from
> the rt2x00 library.
>
> On top of that there should be a MAC layer and some code for configuring
> the dongle (I've seen the driver actually downloads firmware to the dongle
> during initialization etc.) Without looking too closely at the code, my
> intuition tells me that this should be a fairly clean piece of C-code in
> rt2x00, i.e. without too many OS dependencies - just a protocol
> implementation that gets a stream of data and generates a stream of data
> and exposes a well-defined API upwards.
>
> Then there's IP and TCP. Microchip are already providing a TCP/IP stack
> for PIC24. So it would probably require some effort to make an adapter
> between the APIs, but essentially the functionality provided by the MAC
> layer has got to be pretty much the same regardless of the API used.
>
> To summarize, I'm interested mostly in an implementation of the MAC layer
> as well as the chipset-specific configuration logic.
>
> If you (or anyone) could provide me some overview explaining how the code
> is organized, the dependencies, etc. I could probably dig out what I need.
> Also - is there a document provided by RALink such as a datasheet or
> reference manual for their chipset? In other words, what did the authors of
> rt2x00 use as reference? My attempts to search for such a document on the
> Web failed, and I could find only the RALink driver code, the rt2x00 code
> and some marketing brochures...
>
> Feel free to be very critical regarding everything I wrote above - I don't
> know anything about WiFi and am mostly using my Engineering-foo that
> sometimes misleads me :)
>
> Thanks,
> Ytai
>
>
> On Thu, Nov 3, 2011 at 4:49 PM, Peter Stuge <[email protected]> wrote:
>
>> Ytai Ben-Tsvi wrote:
>> > Next up is hopefully Wifi. I purchased a simple RT5370-based dongle
>> > and would like to write (or much better: port) a driver for it to
>> > run on the PIC.
>> ..
>> > Would also value your opinion on how feasible you think porting
>> > this driver to a microcontroller would be
>>
>> Microcontroller can mean many things.. PIC24 are small, and getting
>> all the software that you need for using the wifi is not really a
>> matter of porting, since none of the Linux infrastructure is
>> available, but rather it is a matter of re-implementing all the
>> drivers for the PIC24 machine you're working with.
>>
>> USB communication with the dongle is one thing, you can extract the
>> knowledge needed for that from the Linux driver, but that's only the
>> layer at the very bottom - you also need 802.11 and TCP/IP, none of
>> which are remotely usable for the PIC24 if you look at copying them
>> from Linux.
>>
>> Sorry if I seem blunt now, but the project is a little like saying
>> that you want to enter into a rally championship with a box car. :\
>>
>>
>> //Peter
>>
>> _______________________________________________
>> users mailing list
>> [email protected]
>>
>> http://rt2x00.serialmonkey.com/mailman/listinfo/users_rt2x00.serialmonkey.com
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/attachments/20111118/fb7fe221/attachment-0001.html>
------------------------------
_______________________________________________
users mailing list
[email protected]
http://rt2x00.serialmonkey.com/mailman/listinfo/users_rt2x00.serialmonkey.com
End of users Digest, Vol 33, Issue 20
*************************************
