[OpenWrt-Devel] source code for the device dsl-2730u

[NUCLEAR WAR]

This is the source code for the device dsl-2730u

http://pmdap.dlink.com.tw/PMD/GetAgileFile?itemNumber=GPL1300002&fileName=DSL-2730U_C1_GPL_20130111.7z&fileSize=2.14715066E8;

kernel Ver for the source is : 2.6.30


Model : DSL-2730U
H/W : C1
F/W: ME_1.00
CPU: 963281TAVNG
Flash size: 8 mb
Ram size : 32 mb

[Daniel Gimpelevich]

Post by NUCLEAR WAR
This is the source code for the device dsl-2730u
<http://pmdap.dlink.com.tw/PMD/GetAgileFile?itemNumber=GPL1300002&fileName=DSL-2730U_C1_GPL_20130111.7z&fileSize=2.14715066E8;>
kernel Ver for the source is : 2.6.30
Model : DSL-2730U
H/W : C1
F/W: ME_1.00
CPU: 963281TAVNG
Flash size: 8 mb
Ram size : 32 mb

I don't know whether this will be of much use. Florian, any hope of
reusing the binary ADSL modules in 3.x? They're there as unversioned .o,
to be linked into .ko out-of-tree. In any case, maybe more DT data can
be gleaned from this tarball.

[Bastian Bittorf]

Post by Daniel Gimpelevich
I don't know whether this will be of much use. Florian, any hope of
reusing the binary ADSL modules in 3.x? They're there as unversioned .o,

back in the old days we just used disassemblers, now we even
have tools which make c-code out of an .o - has anyone tried such tools
to open the source?

bye, bastian

[Daniel Gimpelevich]

Post by Bastian Bittorf

Post by Daniel Gimpelevich
I don't know whether this will be of much use. Florian, any hope of
reusing the binary ADSL modules in 3.x? They're there as unversioned .o,

back in the old days we just used disassemblers, now we even
have tools which make c-code out of an .o - has anyone tried such tools
to open the source?
bye, bastian

You mean the days before this?
http://en.wikipedia.org/wiki/Bowers_v._Baystate_Technologies
Any such effort to do this would need to be using the "clean-room"
method, which is exactly what OpenWrt jumpstarted for the brcm43xx
chips, leading to the modern "b43" driver, which OpenWrt then made use
of. IIRC, the whole process took about six years. There are other issues
involved with Broadcom's ADSL drivers in particular, too. I'll leave it
to Florian to either explain the situation for the Nth time, or link to
earlier explanations.

[Rafał Miłecki]

Post by Daniel Gimpelevich

Post by Bastian Bittorf

Post by Daniel Gimpelevich
I don't know whether this will be of much use. Florian, any hope of
reusing the binary ADSL modules in 3.x? They're there as unversioned .o,

back in the old days we just used disassemblers, now we even
have tools which make c-code out of an .o - has anyone tried such tools
to open the source?
bye, bastian

You mean the days before this?
http://en.wikipedia.org/wiki/Bowers_v._Baystate_Technologies
Any such effort to do this would need to be using the "clean-room"
method, which is exactly what OpenWrt jumpstarted for the brcm43xx
chips, leading to the modern "b43" driver, which OpenWrt then made use
of. IIRC, the whole process took about six years. There are other issues
involved with Broadcom's ADSL drivers in particular, too. I'll leave it
to Florian to either explain the situation for the Nth time, or link to
earlier explanations.

If someone write the specs, you can probably count on me (see b43, bgmac) ;)

[Bastian Bittorf]

Post by Daniel Gimpelevich
You mean the days before this?
http://en.wikipedia.org/wiki/Bowers_v._Baystate_Technologies
Any such effort to do this would need to be using the "clean-room"

hmmm, correct me but the drivers are GPL licenced (automatically) because
they are shipped with a GPL-kernel. only problem is you havent the
source. so simply make it and release anonymously? 8-) if you care i
will do. i'am sure no one will complain...

the question was more: are there tools available, which can generate
"good" c-code out of a mips-object file?

Post by Daniel Gimpelevich
method, which is exactly what OpenWrt jumpstarted for the brcm43xx
chips, leading to the modern "b43" driver, which OpenWrt then made use

b43 is another story, because there was a need/wish to use
linux-infrastructure instead of an self-implemented 80211 env
(which is what wl did)

bye, bastian

[Rafał Miłecki]

Post by Bastian Bittorf

Post by Daniel Gimpelevich
You mean the days before this?
http://en.wikipedia.org/wiki/Bowers_v._Baystate_Technologies
Any such effort to do this would need to be using the "clean-room"

hmmm, correct me but the drivers are GPL licenced (automatically) because
they are shipped with a GPL-kernel. only problem is you havent the
source. so simply make it and release anonymously? 8-) if you care i
will do. i'am sure no one will complain...
the question was more: are there tools available, which can generate
"good" c-code out of a mips-object file?

Not that obvious. Read about GPL & linking, etc.

Post by Bastian Bittorf

Post by Daniel Gimpelevich
method, which is exactly what OpenWrt jumpstarted for the brcm43xx
chips, leading to the modern "b43" driver, which OpenWrt then made use

b43 is another story, because there was a need/wish to use
linux-infrastructure instead of an self-implemented 80211 env
(which is what wl did)

Not really. RE team didn't just release disassembled code, but wrote
the whole specs.

[Christoph Thielecke]

Hiho,

Post by Bastian Bittorf
hmmm, correct me but the drivers are GPL licenced (automatically) because
they are shipped with a GPL-kernel. only problem is you havent the
source. so simply make it and release anonymously? 8-) if you care i
will do. i'am sure no one will complain...

I would be become happy if acx100 (http://acx100.sourceforge.net/, driver for
TNETW1130 (ACX111) / TNETW1100 (ACX100) / TNETW1450) would be a clean gpl
source and ready to integrate into mainline.
This driver has same problem :(

Or is there are still a solution yet?

Still using very old avm driver (on very old kernel) for avm fritz wlan usb on
testmachine :(


With best regards

Christoph

[Daniel Gimpelevich]

Post by Christoph Thielecke
Hiho,

Post by Bastian Bittorf
hmmm, correct me but the drivers are GPL licenced (automatically) because
they are shipped with a GPL-kernel. only problem is you havent the
source. so simply make it and release anonymously? 8-) if you care i
will do. i'am sure no one will complain...

I would be become happy if acx100 (http://acx100.sourceforge.net/, driver for
TNETW1130 (ACX111) / TNETW1100 (ACX100) / TNETW1450) would be a clean gpl
source and ready to integrate into mainline.
This driver has same problem :(
Or is there are still a solution yet?
Still using very old avm driver (on very old kernel) for avm fritz wlan usb on
testmachine :(
With best regards
Christoph
_______________________________________________
openwrt-devel mailing list
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

It is my understanding that Lantiq determined that they now own the
rights to the proprietary code that leaked into the acx-mac80211 driver
and gave OpenWrt the official go-ahead to use it under the GPL. I could
be wrong, but AFAIK, the status of this driver is no longer an issue.
What IS still an issue is the lack of a usable driver for the
TNETW1350A, because no one has the inclination to write it. The current
upstream maintainer of acx-mac80211, Oliver Winker, said that such a
driver would much more closely resemble the wl1251 driver than the acx
driver, but the wl1251 maintainers know nothing about the TNETW1350A.

[Christoph Thielecke]

Hello,

Post by Daniel Gimpelevich

Post by Christoph Thielecke
I would be become happy if acx100 (http://acx100.sourceforge.net/, driver
for TNETW1130 (ACX111) / TNETW1100 (ACX100) / TNETW1450) would be a clean
gpl source and ready to integrate into mainline.
This driver has same problem :(

It is my understanding that Lantiq determined that they now own the
rights to the proprietary code that leaked into the acx-mac80211 driver
and gave OpenWrt the official go-ahead to use it under the GPL. I could
be wrong, but AFAIK, the status of this driver is no longer an issue.

If that is true, Rafał maybe could help to get it into mainline :)

Post by Daniel Gimpelevich
What IS still an issue is the lack of a usable driver for the
TNETW1350A, because no one has the inclination to write it. The current
upstream maintainer of acx-mac80211, Oliver Winker, said that such a
driver would much more closely resemble the wl1251 driver than the acx
driver, but the wl1251 maintainers know nothing about the TNETW1350A.

:(

Its seems there some devices which have it so it could be useful :)


With best regards

Christoph

[Florian Fainelli]

Post by Christoph Thielecke
Hello,

Post by Daniel Gimpelevich

Post by Christoph Thielecke
I would be become happy if acx100 (http://acx100.sourceforge.net/, driver
for TNETW1130 (ACX111) / TNETW1100 (ACX100) / TNETW1450) would be a clean
gpl source and ready to integrate into mainline.
This driver has same problem :(

It is my understanding that Lantiq determined that they now own the
rights to the proprietary code that leaked into the acx-mac80211 driver
and gave OpenWrt the official go-ahead to use it under the GPL. I could
be wrong, but AFAIK, the status of this driver is no longer an issue.

If that is true, Rafał maybe could help to get it into mainline :)

An attempt was made before, and until the acx-mac80211 codebase is not
considered clean enough, there won't be any possible merging. Added
Oliver in CC who can tell you more.

Post by Christoph Thielecke

Post by Daniel Gimpelevich
What IS still an issue is the lack of a usable driver for the
TNETW1350A, because no one has the inclination to write it. The current
upstream maintainer of acx-mac80211, Oliver Winker, said that such a
driver would much more closely resemble the wl1251 driver than the acx
driver, but the wl1251 maintainers know nothing about the TNETW1350A.

:(
Its seems there some devices which have it so it could be useful :)
With best regards
Christoph
_______________________________________________
openwrt-devel mailing list
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[Florian Fainelli]

Post by Bastian Bittorf

Post by Daniel Gimpelevich
You mean the days before this?
http://en.wikipedia.org/wiki/Bowers_v._Baystate_Technologies
Any such effort to do this would need to be using the "clean-room"

hmmm, correct me but the drivers are GPL licenced (automatically) because
they are shipped with a GPL-kernel. only problem is you havent the
source. so simply make it and release anonymously? 8-) if you care i
will do. i'am sure no one will complain...

Not if these are external kernels, and they are.

Post by Bastian Bittorf
the question was more: are there tools available, which can generate
"good" c-code out of a mips-object file?

IDA + HexRays usually does an excellent job for popular architectures.

Post by Bastian Bittorf

Post by Daniel Gimpelevich
method, which is exactly what OpenWrt jumpstarted for the brcm43xx
chips, leading to the modern "b43" driver, which OpenWrt then made use

b43 is another story, because there was a need/wish to use
linux-infrastructure instead of an self-implemented 80211 env
(which is what wl did)

It's the same with the Broadcom DSL drivers, they use their own ATM
stack (not linux-atm).
--
Florian

[Florian Fainelli]

Post by Daniel Gimpelevich

Post by NUCLEAR WAR
This is the source code for the device dsl-2730u
<http://pmdap.dlink.com.tw/PMD/GetAgileFile?itemNumber=GPL1300002&fileName=DSL-2730U_C1_GPL_20130111.7z&fileSize=2.14715066E8;>
kernel Ver for the source is : 2.6.30
Model : DSL-2730U
H/W : C1
F/W: ME_1.00
CPU: 963281TAVNG
Flash size: 8 mb
Ram size : 32 mb

I don't know whether this will be of much use. Florian, any hope of
reusing the binary ADSL modules in 3.x? They're there as unversioned .o,
to be linked into .ko out-of-tree. In any case, maybe more DT data can
be gleaned from this tarball.

We can't do anything serious out of this, the broadcom xDSL drivers make
use of a heavily modified struct sk_buff which is subject to changes
from one kernel version to another.
--
Florian

[Daniel Gimpelevich]

Post by Florian Fainelli
We can't do anything serious out of this, the broadcom xDSL drivers make
use of a heavily modified struct sk_buff which is subject to changes
from one kernel version to another.
--
Florian

This was always the problem, and short of the type of monumental effort
it would take to rewrite them to use linux-atm that b43 took, the only
thing that _could_ be done for the time being would be creating some
sort of abstraction layer around Broadcom's object code. I do not know
in what different forms the xDSL drivers appeared in other tarballs, but
I'm guessing some of them might be less or more suitable for this than
others. Since Broadcom reimplements huge sections of the kernel
themselves, I would expect they make rather minimal use of kernel ABI's,
and maintaining a backward-compatibility layer to accommodate a single
binary blob (as was done for one for the 2.6.11 kernel for a while) is
not feasible, but as you can see, we keep seeing newer tarballs with
blobs for newer kernel versions, so complete breakdowns in ABI
compatibility are never permanent.

I understand the decision not to put forth the effort to do this, and I
understand that all efforts to negotiate a compromise with Broadcom like
the one reached for wifi have failed, but what would it take to create
more leverage? I know that at some point, the French ISP Neuf wanted to
broker some sort of agreement which also failed, proving that ISP's do
not have such standing with Broadcom, so which device manufacturer could
best be approached to assist?