NUCLEAR WAR | 31 Jan 05:12 2013
Picon

source code for the device dsl-2730u

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
_______________________________________________
openwrt-devel mailing list
openwrt-devel <at> lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Daniel Gimpelevich | 31 Jan 05:22 2013
Picon
Picon

[brcm63xx] Re: source code for the device dsl-2730u

On Thu, 2013-01-31 at 04:12 +0000, NUCLEAR WAR wrote: 
> 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 | 31 Jan 08:55 2013

Re: [brcm63xx] Re: source code / disassembler / decompiler

* Daniel Gimpelevich <daniel <at> gimpelevich.san-francisco.ca.us> [31.01.2013 08:48]:
> 
> 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 | 31 Jan 16:40 2013
Picon
Picon

Re: [brcm63xx] Re: source code / disassembler / decompiler

On Thu, 2013-01-31 at 08:55 +0100, Bastian Bittorf wrote: 
> * Daniel Gimpelevich <daniel <at> gimpelevich.san-francisco.ca.us> [31.01.2013 08:48]:
> > 
> > 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 | 31 Jan 16:51 2013
Picon

Re: [brcm63xx] Re: source code / disassembler / decompiler

2013/1/31 Daniel Gimpelevich <daniel <at> gimpelevich.san-francisco.ca.us>:
> On Thu, 2013-01-31 at 08:55 +0100, Bastian Bittorf wrote:
>> * Daniel Gimpelevich <daniel <at> gimpelevich.san-francisco.ca.us> [31.01.2013 08:48]:
>> >
>> > 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) ;)

--

-- 
Rafał
_______________________________________________
openwrt-devel mailing list
openwrt-devel <at> lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Bastian Bittorf | 31 Jan 16:55 2013

Re: [brcm63xx] Re: source code / disassembler / decompiler

* Daniel Gimpelevich <daniel <at> gimpelevich.san-francisco.ca.us> [31.01.2013 16:47]:
> 
> 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?

> 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 | 31 Jan 17:01 2013
Picon

Re: [brcm63xx] Re: source code / disassembler / decompiler

2013/1/31 Bastian Bittorf <bittorf <at> bluebottle.com>:
> * Daniel Gimpelevich <daniel <at> gimpelevich.san-francisco.ca.us> [31.01.2013 16:47]:
>>
>> 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.

>> 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.

--

-- 
Rafał
_______________________________________________
openwrt-devel mailing list
openwrt-devel <at> lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Christoph Thielecke | 31 Jan 17:13 2013
Picon
Picon

Re: [brcm63xx] Re: source code / disassembler / decompiler

Hiho,

> > 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
--

-- 
Linux User Group Wernigerode
http://www.lug-wr.de/
_______________________________________________
openwrt-devel mailing list
openwrt-devel <at> lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Daniel Gimpelevich | 31 Jan 17:34 2013
Picon
Picon

acx-mac80211 (was Re: [brcm63xx] Re: source code / disassembler / decompiler)

On Thu, 2013-01-31 at 17:13 +0100, Christoph Thielecke wrote: 
> Hiho,
> 
> > > 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
> openwrt-devel <at> lists.openwrt.org
> 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 | 31 Jan 17:58 2013
Picon
Picon

Re: acx-mac80211 (was Re: [brcm63xx] Re: source code / disassembler / decompiler)

Hello,

> > 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 :)

> 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
--

-- 
Linux User Group Wernigerode
http://www.lug-wr.de/
_______________________________________________
openwrt-devel mailing list
openwrt-devel <at> lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Florian Fainelli | 31 Jan 18:48 2013

Re: acx-mac80211 (was Re: [brcm63xx] Re: source code / disassembler / decompiler)


On 01/31/2013 05:58 PM, Christoph Thielecke wrote:
> Hello,
>
>>> 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.

>
>> 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
> openwrt-devel <at> lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
_______________________________________________
openwrt-devel mailing list
openwrt-devel <at> lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Florian Fainelli | 31 Jan 17:00 2013

Re: [brcm63xx] Re: source code / disassembler / decompiler


On 01/31/2013 04:55 PM, Bastian Bittorf wrote:
> * Daniel Gimpelevich <daniel <at> gimpelevich.san-francisco.ca.us> [31.01.2013 16:47]:
>>
>> 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.

>
> 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.

>
>> 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 | 31 Jan 17:03 2013

Re: [brcm63xx] Re: source code for the device dsl-2730u


On 01/31/2013 05:22 AM, Daniel Gimpelevich wrote:
> On Thu, 2013-01-31 at 04:12 +0000, NUCLEAR WAR wrote:
>> 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 | 31 Jan 18:01 2013
Picon
Picon

Re: [brcm63xx] Re: source code for the device dsl-2730u

On Thu, 2013-01-31 at 17:03 +0100, Florian Fainelli wrote:
> 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?

Gmane