Hi,
I'm looking into support for RTL8188FU with the vendor driver next to
me. There is a driver called rtl8188eu in staging. Is there a way to
figure out the difference between E and F?
Then there is rtl8xxxu outside of staging claiming to support
RTL8188[CR]U. No idea what C & R is and how much difference there is
towards F or E.
Any suggestions what would be the best way towards support for the F
chip?
Sebastian
On 10/1/19 11:03 AM, Sebastian Andrzej Siewior wrote:
> Hi,
>
> I'm looking into support for RTL8188FU with the vendor driver next to
> me. There is a driver called rtl8188eu in staging. Is there a way to
> figure out the difference between E and F?
> Then there is rtl8xxxu outside of staging claiming to support
> RTL8188[CR]U. No idea what C & R is and how much difference there is
> towards F or E.
>
> Any suggestions what would be the best way towards support for the F
> chip?
A quick Internet search shows me that the RTL8188FU is a low-cost chip used on
Raspberry PI and other similar low-cost systems.
The USB group at Realtek is notorious for their lack of support for Linux
drivers. The ones they release have lots of dead code used for Windows and
FreeBSD drivers, and they have lots of code that applies to other chips. With
other drivers that I have placed at GitHub, some of the commits that remove dead
code will remove as many of 10K lines.
You should be able to find the code that differs between 8188EU and 8188FU to
see what is different.
The 8188RU is a special variant of the 8188EU. I have no idea what an 8188CU is.
Your only starting point is the driver that is next to you!
Larry
On 2019-10-01 11:47:44 [-0500], Larry Finger wrote:
> A quick Internet search shows me that the RTL8188FU is a low-cost chip used
> on Raspberry PI and other similar low-cost systems.
>
> The USB group at Realtek is notorious for their lack of support for Linux
> drivers. The ones they release have lots of dead code used for Windows and
> FreeBSD drivers, and they have lots of code that applies to other chips.
> With other drivers that I have placed at GitHub, some of the commits that
> remove dead code will remove as many of 10K lines.
yeah, seen that.
> You should be able to find the code that differs between 8188EU and 8188FU
> to see what is different.
So you would recommend to try to merge it to the staging driver.
> The 8188RU is a special variant of the 8188EU. I have no idea what an 8188CU is.
>
> Your only starting point is the driver that is next to you!
Thank you for your reply.
> Larry
Sebastian
On 10/1/19 12:46 PM, Sebastian Andrzej Siewior wrote:
> On 2019-10-01 11:47:44 [-0500], Larry Finger wrote:
>> A quick Internet search shows me that the RTL8188FU is a low-cost chip used
>> on Raspberry PI and other similar low-cost systems.
>>
>> The USB group at Realtek is notorious for their lack of support for Linux
>> drivers. The ones they release have lots of dead code used for Windows and
>> FreeBSD drivers, and they have lots of code that applies to other chips.
>> With other drivers that I have placed at GitHub, some of the commits that
>> remove dead code will remove as many of 10K lines.
>
> yeah, seen that.
>
>> You should be able to find the code that differs between 8188EU and 8188FU
>> to see what is different.
>
> So you would recommend to try to merge it to the staging driver.
If that is what you read, that is not what I meant.
The staging driver is really old and does not support nl80211 and friends. If
you are willing to undertake a 6 to 12-month rewrite of the driver you have, and
it supports RTL8188EU, then a replacement of the staging driver would be what
you should do. If you do not want to make that kind of time commitment, then a
GitHub repo would be your best bet; however, GitHub already has 5 such repos for
the rtl8188fu. As far as I can tell, none of them are yours.
The first thing I would do is clone the v5.2.2.4 branch of lwfinger/rtl8188eu at
GitHub, add the USB ID for your device, and see if that works. I expect it will.
If so, that would get you quite a ways toward the changes needed to get that
driver into staging.
Larry
On 2019-10-01 13:52:30 [-0500], Larry Finger wrote:
> If that is what you read, that is not what I meant.
>
> The staging driver is really old and does not support nl80211 and friends.
> If you are willing to undertake a 6 to 12-month rewrite of the driver you
> have, and it supports RTL8188EU, then a replacement of the staging driver
> would be what you should do. If you do not want to make that kind of time
> commitment, then a GitHub repo would be your best bet; however, GitHub
> already has 5 such repos for the rtl8188fu. As far as I can tell, none of
> them are yours.
>
> The first thing I would do is clone the v5.2.2.4 branch of
> lwfinger/rtl8188eu at GitHub, add the USB ID for your device, and see if
> that works. I expect it will. If so, that would get you quite a ways toward
> the changes needed to get that driver into staging.
Thank you for clearing that up.
> Larry
Sebastian
On 2019-10-01 13:52:30 [-0500], Larry Finger wrote:
> The first thing I would do is clone the v5.2.2.4 branch of
> lwfinger/rtl8188eu at GitHub, add the USB ID for your device, and see if
> that works. I expect it will. If so, that would get you quite a ways toward
> the changes needed to get that driver into staging.
Adding the id didn't help. I added "hal/Hal8188FPwrSeq.o" next to
"hal/Hal8188EPwrSeq.o". Some parts were different.
After loading the firmware the driver said that the firmware wasn't
active. So I tweaked the firmware loading part a little. The signature
of the firmware in my driver is 0x88F0 instead of 0x88E0 and the
"normal-nic" firmware has 20306 bytes. By loading the "other" firmware
the firmware and driver says that it is "alive".
I disabled the "IOL" bits (like rtw_IOL_applied() which returns false).
It took long and didn't seem to succeed. My driver lacks most of the
code, rtw_IOL_applied() isn't referenced anyway and the ifdef isn't set.
I would continue to add more pieces in order to get it working unless
you have a different advice.
> Larry
Sebastian
On 3/4/20 4:21 AM, Sebastian Andrzej Siewior wrote:
> On 2019-10-01 13:52:30 [-0500], Larry Finger wrote:
>> The first thing I would do is clone the v5.2.2.4 branch of
>> lwfinger/rtl8188eu at GitHub, add the USB ID for your device, and see if
>> that works. I expect it will. If so, that would get you quite a ways toward
>> the changes needed to get that driver into staging.
>
> Adding the id didn't help. I added "hal/Hal8188FPwrSeq.o" next to
> "hal/Hal8188EPwrSeq.o". Some parts were different.
> After loading the firmware the driver said that the firmware wasn't
> active. So I tweaked the firmware loading part a little. The signature
> of the firmware in my driver is 0x88F0 instead of 0x88E0 and the
> "normal-nic" firmware has 20306 bytes. By loading the "other" firmware
> the firmware and driver says that it is "alive".
> I disabled the "IOL" bits (like rtw_IOL_applied() which returns false).
> It took long and didn't seem to succeed. My driver lacks most of the
> code, rtw_IOL_applied() isn't referenced anyway and the ifdef isn't set.
>
> I would continue to add more pieces in order to get it working unless
> you have a different advice.
I have no further advice. There are quite likely a number of routines that will
differ as the 8188FU chip is quite likely a lot different from the 8188EU, even
though both are 802.11n devices.
Larry
On 2020-03-04 12:16:54 [-0600], Larry Finger wrote:
>
> I have no further advice. There are quite likely a number of routines that
> will differ as the 8188FU chip is quite likely a lot different from the
> 8188EU, even though both are 802.11n devices.
That is more complicated than I assumed. Even the "generic" hal layer is
different. Sometimes there are additional bits, sometimes the bits are
moved (to/from the HW-specific hal layer), sometimes the bits the are
different (like BIT0|BIT1 vs BIT1). Without having any kind of
documentation I can't even tell how essential the difference is.
Right now I went function by function and compared the code and *hoped*
that I didn't miss anything. I get USB errors later and I can't tell if
there is something that I missed/did wrong _or_ did not yet modify. I'm
worried that by the time I'm done, I did something wrong and no idea
where to look for the bug.
I stumbled over the version define:
The driver on github is
|include/rtw_version.h:#define DRIVERVERSION "v5.2.2.4_25483.20171222"
and mine is
|include/rtw_version.h:#define DRIVERVERSION "v5.7.4_33085.20190419"
Going by the date, they are more than a year apart. (Side note: the
driver in staging is from 2013.)
Is it possible to obtain a more recent version of the 8188EU driver from
realtek? That should ease the integration of the "two" drivers since the
generic bits should be the same…
What would be the challenges to get the 8188f Realtek driver upstream?
Looking at the todo list for the staging driver, it is mostly clean up
and checkpatch kind of thing. The more difficult/non mechanic task is to
convince the driver to use lib80211/mac80211 layer.
> Larry
Sebastian
On Tue, Mar 10, 2020 at 03:48:09PM +0100, Sebastian Andrzej Siewior wrote:
> What would be the challenges to get the 8188f Realtek driver upstream?
> Looking at the todo list for the staging driver, it is mostly clean up
> and checkpatch kind of thing. The more difficult/non mechanic task is to
> convince the driver to use lib80211/mac80211 layer.
Tht mac80211 layer stuff is probably the biggest issue.
thanks,
greg k-h