#1 03/03/2010 18:14:31

goundoulf
Administrateur
Date d'inscription: 21/08/2007
Messages: 4544
Site web

Introduction about the OpenAdsl project

The goal of the OpenAdsl project is to investigate the possibility of making an open-source / free software (at least as much as possible) ADSL driver for modem-routers, including the neufbox 4 and TI AR7.

Platform-specific code should be separated from generic code so that code can be shared and efforts mutualized.

See for example https://dev.openwrt.org/ticket/6515

Think of OsmocomBB, but for ADSL

As for the legal aspects : http://bb.osmocom.org/trac/wiki/LegalAspects

Hors ligne

 

#2 03/03/2010 20:51:11

SGDA
Pachyderme
Lieu: 95170
Date d'inscription: 28/08/2007
Messages: 8050

Re: Introduction about the OpenAdsl project

Vaste programme.. mais pourquoi pas


XP Pro/Fedora 19 (Schrödinger's cat)

Hors ligne

 

#3 03/03/2010 22:24:09

VincentAlex
Modérateur
Lieu: Massy (91)
Date d'inscription: 01/10/2007
Messages: 2689
Site web

Re: Introduction about the OpenAdsl project

C'est bon pour obinou !


Environnement de développement : MacOsX/Fedora 12
Dépôt dropbox
http://www.fonera.be/status2-2379.png

Hors ligne

 

#4 04/03/2010 10:38:55

obinou
Administrateur
Lieu: Cahors, 46
Date d'inscription: 29/08/2007
Messages: 461

Re: Introduction about the OpenAdsl project

Hello !

Yes, the goal of this section is to centralize the code & the information we can get about ADSL.
I admit that I did some research on the subject recently: Since my goal is OpenWRT, the two major drawbacks for the general public is the non-availability of DSL layer and the VOIP layer. I decided to concentrate on DSL first.
To my amazement, I found out that almost all the documentation are available on the ITU Website , some of them even in french!
(Look for all norms starting by G99*)

On linux, several drivers already supports ADSL:
* USB Modem (eg. ueagle)
* PCI FPGA-Based card, including one in the mainline kernel : The SOLO whose driver is very clean & well-written.

Both, however does not look like the BCM6358 architecture: They "exposes" an ATM endpoint directly used by the Linux ATM layer upward. In other words all the complexity is masked in the card *firmware*, nothing is compiled on the host.

Exploring the the BCM6358 proprietary binary (and judging by its size, and the symbols withing the .ko files), it appears that the ADSL decoding is fully done in software: The DSP is merly used as a Numeric/Analog convertor.
(Yes - this is a poor design, but for a $80 box, one may not expect too much)

Fortunately, there IS a precedent: The TI-AR7 driver has been included as sources into OpenWRT for a while now, and at first glance it seems to have the same kind of logic. Of course it's not reusable as is, but the "glue logic" is.
The code in itself however is horrible: it is obviously a quick port from another OS, and do not reuse anything from Linux. The contrast with the SOLO driver is depressing...

So, my idea is to rewrite a clean and modular implementation of the required pieces to have a good DSL layer under Linux, in particular by following the "good practices": Layering, usage of the Linux "platform driver" infrastructure, maybe taking the SOLO driver as a starting point & fill-in the blanks for other implementations. In particular, I think an AR-7 DSL driver IS possible with what we have.
The goal is to keep the plateform-specific goal as small as possible.

Here is the required layers:

* Driver Model: We have to create a "DSL template driver", with all the logic inside: registration  of the driver, ATM interface handling, generic reporting layer.
There is some of this already done in the various drivers , non is unified.

* ATM SAR (Segmentation & Reassembly) : The DSL streams comes from multiple "small tunnels", hundred of them. This layer's work is to reassembly all of this into ATM Cells.
All of this is explained in the G99x standards.

* G992* Layers: This is THE big piece, because the specs are big & very mathematics. However, we have all the elements to do it, and we can exercise that with a TI AR7 modem like the Linksys AG241.
It Include Error detection and Error Correction (FEC & Reed Solomon)

* Low-level: This is the (hopefully thin) layer that "touches" the hardware of the box. If we can keep this small enough, we may expect that Efixo get the authorization to release just this thin layer, enabling the DSL on the 6358 to work !
From the TI AR7 driver, we found out that it works like this:
- The interrupts are used only on connection or disconnection of the cable.
- A "polling" is used, with a *very* precise timing. A specific clock is used,
- The polling takes place in the RAM: We must write to some space a fixed number of bytes, and read a precise number of byte every X microseconds.
These bytes we read are then passed through the Error Detection & Correction layers , then reassembly, before making them into regular ATM packets.

* Firmware loading. All DSL cards DO work with a binary firmware. I do not intend to rewrite that, since it does not runs on the processor but on the DSP.
We still have to handle the loading of it


For now I'm writing a template driver with "blanks" to be filled-in, that I will release soon as a OpenWRT module.
Then we will discuss that, change what we need, and then start filling the blanks.

Hors ligne

 

#5 04/03/2010 11:32:26

obinou
Administrateur
Lieu: Cahors, 46
Date d'inscription: 29/08/2007
Messages: 461

Re: Introduction about the OpenAdsl project

[This is the french translation of my message above. Please keep this thread in english if you can, to easy code & idea sharing]

Hello !

En effet lt but de cette section est de centraliser le code & les informations que l'on peux avoir sur l'ADSL.
J'admets que j'ai fait un peu de recherche sur le sujet récemment: Mon but étant OpenWRT, les deux problèmes majeurs sur les plate-formes BCM6358 sont la VOIP & L'ADSL. J'ai décidé de m'attaquer à l'ADSL d'abord.
A ma grande surprise, tous les documents sont dispo sur le site de l'ITU , y compris en Français!
Ce sont tous ceux qui commencent par G99*.


Sous linux plusieurs drivers supportent l'ADSL:
* Modems USB (eg: ueagle, cocoricco!)
* Carte PCI basée sur des FPGA, dont l'une en mainline: la SOLO dont le driver est très bien fait.

Ces deux modèles ne ressemblent pas à l'architecture du BCM6358: Ces matériels exposent directement une interface ATM utilisé ensuite normalement par linux. En d'autre terme, c'est le firmware de ces matériels qui prend en charge la complexité des protocoles ADSL, rien n'est fait sur la plateforme.

En explorant le binaire du driver propriétaire du BCM6358 (et a en juger par sa taille & les symboles présents dans le .ko), it semble que le décodage ADSL soit fait logiciellement, sur la plateforme. Le DSP ici est utilisé en simple numériseur de signal.
(Oui c'est pas terrible comme design, mais bon sur un modem à 70€ faut pas non plus s'attendre à des miracles)


Heureusement, on a un précédant: Le driver TI-AR7 a été inclus en tant que sources dans le projet OpenWRT depuis un moment, et a première vue, la logique est similaire. Il n'est pas réutilisable tel quel, mais la philosophie de fonctionnement l'est.
Le code en lui-même est déprimant, il n'a rien a voir avec la qualité de celui du driver SOLO,il a clairement été rapidement porté depuis un autre OS.

Mon idée est de reécrite une implémentation claire & modulaires des morceaux nécessaires pour avoir une couche DSL sous linux, en suivant les "bonnes pratiques" des drivers linux: Bien séparer les couches, utiliser le driver-model, réutiliser au maximum ce qui existe, peut-être en utilisant le driver SOLO comme point de départ, puis en remplissant les blancs au fur & a mesure.
L'objectif est de garder l'interface avec le matériel la plus petite possible.


Les couches nécessaires sont:

* Driver Model: Il nous faut créer un modèle générique de driver ADSL, comprenant toute la logique: Enregistrement du driver, gestion des interfaces ATM, remontées d'information/statistiques.
Ceci existe déjà un peu dans les autres drivers mais ce n'est pas unifié (en particuliers les statistiques & infos)


* ATM SAR (Segmentation & Reassembly) : Les flux DSL proviennent d'une multitudes de "micro-tunnels". Le but de la couche SAR est de ré-assembler ces canaux en cellules ATM.
Ceci est expliqué dans les normes ITU.

* Couches G992*: C'est LE gros morceau, parce-que les spécifications ITU sont grosse, complexes et matheuses. Par contre elles sont complètes, nous avons tous les éléments pour les faire, et on peux les tester avec un modem TI AR7 comme le AG241.
Cette couche inclue la détection & correction d'erreurs FEC & Reed-Solomon.

* Bas-niveau: Cette couche est celle qui viens "toucher" le matériel, idéalement la plus fine possible.
Si on peux la garder assez réduite, on peux espérer que Efixo aura l'autorisation de diffuser cette couche pour le BCM6358, permettant à l'ADSL de marcher !
Le driver TI-AR7 nous a appris que cette couche marche ainsi:
- Les interruptions sont utilisée uniquement pour la connexion/déconnexion du câble téléphonique,
- Un polling est utilisé pour récupérer ou injecter des données, avec un timer très précis, une horloge spécifique est utilisée,
- Ce polling est fait depuis la RAM: On dois écrire ou lire a des endroits précis, un nombre d'octets précis toute les X microsecondes.
En upstream, ces octets sont ensuite récupérer par la couche de détection/correction d'erreur, puis ré-assemblés avant de créer une cellule ATM.

* Chargement de firmware: Toute les cartes ADSL utilisent un firmware binaire. l'objectif n'est pas de réecrire ce firmware, sachant qu'il ne tourne pas sur le processeur de la plateforme mais sur le DSP (ou FPGA selon le cas).
Mais nous devons gérer son chargement & initialisation.

Pour le moment,je suis en train d'écrire un modèle générique de driver, avec ses "blancs" à remplir, que je publierais dès que possible en tant que module OpenWRT. Nous pourront alors en discuter, changer ce qui ne vas pas, et enfin commencer à remplir les blancs.

edit:typo

Dernière modification par obinou (04/03/2010 14:01:48)

Hors ligne

 

#6 04/03/2010 13:22:43

SGDA
Pachyderme
Lieu: 95170
Date d'inscription: 28/08/2007
Messages: 8050

Re: Introduction about the OpenAdsl project

Déjà un peu de mal avec les acronymes (DSP ?)
Pas compris
sachant qu'il ne tourne pas sur le processeur de la plateforme mais sur le DSL (ou FPGA selon le cas).
Ce polling est fait depuis la RAM: On dois écrire ou lire a des endroits précis, un nombre d'octets précis toute les X microsecondes.
est-ce compatible avec un empilement propre des layers ?


XP Pro/Fedora 19 (Schrödinger's cat)

Hors ligne

 

#7 04/03/2010 14:12:11

obinou
Administrateur
Lieu: Cahors, 46
Date d'inscription: 29/08/2007
Messages: 461

Re: Introduction about the OpenAdsl project

SGDA a écrit:

Déjà un peu de mal avec les acronymes (DSP ?)
Pas compris
sachant qu'il ne tourne pas sur le processeur de la plateforme mais sur le DSL (ou FPGA selon le cas).

DSP: Digital Signal Processor.
Un microprocesseur dont le jeu d'instruction machine est spécialisé dans l'exécution parallèle d'instructions complexes.
En particulier c'est très utile en traitement du signal (filtres, transformé de fourrier,..)
Sur ce genre d'opération, ce genre de puce est très efficace. Par contre, ya pas de pipelines d'exécution, pas de prédiction de branchements... c'est pas un processeur généraliste.

FPGA: Field Programmable Gate Array
Là c'est même mieux: La configuration des portes logique n'est pas fondu dans le silicium, elle est chargée a la mise sous tension de la puce depuis une eeprom a coté. C'est une généralisation des CPU, DSP... tu peux créer un CPU avec les instructions que tu veux, ou alors pas de CPU du tout: T'a juste des portes (des centaines de millions), dotn certaines relié a des fils de la puce. C'est tout.

Ces deux domaines sont très intéressants en eux-même, on trouve des cartes à FPGA pour 40€ ! Mais attention, c'est pas simple, et c'est addictif...


Ce polling est fait depuis la RAM: On dois écrire ou lire a des endroits précis, un nombre d'octets précis toute les X microsecondes.
est-ce compatible avec un empilement propre des layers ?

Ben pourquoi pas ? A partir du moment ou c'est le driver bas-niveau qui gère...

Quand je dis en mémoire, c'est dans un endroit précis défini a l'avance par le firmware & le driver !
En gros c'est comme du DMA, sauf qu'il n'y a pas d'interruptions pour dire que le transfert est fini.

Hors ligne

 

#8 04/03/2010 15:30:04

VincentAlex
Modérateur
Lieu: Massy (91)
Date d'inscription: 01/10/2007
Messages: 2689
Site web

Re: Introduction about the OpenAdsl project

Very interesting, but how to participate ? Must we wait you publish the template driver ?


Environnement de développement : MacOsX/Fedora 12
Dépôt dropbox
http://www.fonera.be/status2-2379.png

Hors ligne

 

#9 04/03/2010 15:50:01

goundoulf
Administrateur
Date d'inscription: 21/08/2007
Messages: 4544
Site web

Re: Introduction about the OpenAdsl project

you can read all the papers found on http://www.itu.int/rec/T-REC-G/fr smile

it's also possible to create a new category on the wiki and start explaining how ADSL works

Hors ligne

 

#10 04/03/2010 20:13:06

obinou
Administrateur
Lieu: Cahors, 46
Date d'inscription: 29/08/2007
Messages: 461

Re: Introduction about the OpenAdsl project

VincentAlex a écrit:

Very interesting, but how to participate ? Must we wait you publish the template driver ?

In any case, yes, please wait until I publish this as a discussion's starting point.

But even then, we will need development work, and a good knowledge of the linux drivers & network layer in general.

Once it works a little, we intend to test the driver on a specific setup, and especially NOT on public's FAI  DSL lines without approval (Efixo might help us here).

The major problem is that due to the way ADSL works, the frequencies that are injected into the cables might, and do leaks into neighbor cables during transit.

The ITU documents explains that, they have qualified the phenomenon and create the protocol accordingly , down to the electric level.

It is *essential* that we very carefully respect that, in the same way the mac802.11's kernel layer respect the norms regarding airwaves.
That's why the quality of the code is essential, and after seeing the TI AR7 code, i'm still amazed it works at all.
And, to be honest, it does not:
http://www.theregister.co.uk/2007/10/22 … _bt_fault/
http://www.ispreview.co.uk/cgi-bin/news … EkxmMzefhp
http://www.pcpro.co.uk/features/205983/ … r7-routers
http://www.thinkbroadband.com/news/3257 … -fore.html

These article must show you that this is NOT an easy job we are talking about:
The standards & the mathematics are complex, the hardware is not well-known and cheap, there may be bugs in the DSP firmware, or in the DSLAM.

For now I think we should limit ourself to ADSL1 only , maybe restricted to only one speed, not interleaved, and try out with that.

If it works, & the FAI do not strongly opposes, then some of us might try for a while, especially attentive to the neighbor's reaction (for example, if they notice problems or lower speed).

After a while (and some fixes) , only then I think we might post it on a mainstream mailing-list , openwrt for example, hopping to catch the attention of other members.

The goal here is to "play fair" with the FAI by avoiding what they fear most: Calls to the hotline, but still be strong against any takedown demands as we believe this is our right to write & execute this code, exactly like Harald for GSM. Especially since neither the FAI nor the chip manufacturer show any interest into spending time & money to make these drivers follow the linux development model.

Dernière modification par obinou (04/03/2010 23:54:37)

Hors ligne

 

#11 05/03/2010 09:22:48

SGDA
Pachyderme
Lieu: 95170
Date d'inscription: 28/08/2007
Messages: 8050

Re: Introduction about the OpenAdsl project

I don't understand if the final goal is rewritting adsl_phy.bin or building a set of clean layers above the original adsl_phy.bin (as it's done in b43.ko module).
Both cases need references of private Broadcom parts (hardware in the first case, software in the second one).
Hacking of the second one could be easiest... but more intrusive.
Both ways could be out of LegalAspects described by OsmocomBB.


XP Pro/Fedora 19 (Schrödinger's cat)

Hors ligne

 

#12 05/03/2010 09:58:54

obinou
Administrateur
Lieu: Cahors, 46
Date d'inscription: 29/08/2007
Messages: 461

Re: Introduction about the OpenAdsl project

SGDA a écrit:

I don't understand if the final goal is rewritting adsl_phy.bin

No.

or building a set of clean layers above the original adsl_phy.bin (as it's done in b43.ko module).

Yes.

Both cases need references of private Broadcom parts (hardware in the first case, software in the second one).

Yes, but not much: Just the hardware interface part (Like the registers used, how to communicate with the firmware & so on).
No "IP" , no intelligence is involved: This part as you say is done on the layers above and are already fully documented.

Hacking of the second one could be easiest... but more intrusive.

? I don't understand that. More Intrusive to what ?

Both ways could be out of LegalAspects described by OsmocomBB.

I don't think so. What we want from broadcom is JUST the interface: If all goes right, it's a thousand lines of code maximum. And as I said, the goal here is to simplify this enough so that Efixo may release that code, written from scratch, with broadcom approval. And since they will do that ONLY if it does not hurt their network...
Don't forget the limited scope I'm targeting: It's not tomorrow that this driver will be on every box.

And also, our first testing target is TI AR7 as a proof of concept.

Hors ligne

 

#13 06/03/2010 10:54:15

cuagn
(de nouveau out...)
Lieu: 84210 - Pernes les Fontaines
Date d'inscription: 30/08/2007
Messages: 2426
Site web

Re: Introduction about the OpenAdsl project

obinou a écrit:

Ces deux domaines sont très intéressants en eux-même, on trouve des cartes à FPGA pour 40€ ! Mais attention, c'est pas simple, et c'est addictif...

I think Obinou is talking of this nice tiny open logic sniffer, here


Windows 7 /Debian 8
plus un tas d'autres...

Hors ligne

 

#14 06/03/2010 20:34:55

obinou
Administrateur
Lieu: Cahors, 46
Date d'inscription: 29/08/2007
Messages: 461

Re: Introduction about the OpenAdsl project

cuagn a écrit:

I think Obinou is talking of this nice tiny open logic sniffer, here

Yes, and also this avnet kit, which seems more powerful that the small Actel FPGA of the logic-analyzer.

Hors ligne

 

#15 18/03/2010 15:46:57

vousavezunmsg
Moddeur bidouilleur
Date d'inscription: 28/08/2007
Messages: 77

Re: Introduction about the OpenAdsl project

Incoming contribution ; -)


non non, Contiki n'est pas une agence de voyage ; )
http://www.sics.se/contiki/

Hors ligne

 

#16 18/03/2010 16:12:08

goundoulf
Administrateur
Date d'inscription: 21/08/2007
Messages: 4544
Site web

Re: Introduction about the OpenAdsl project

good good smile

Hors ligne

 

#17 27/10/2010 16:03:36

goundoulf
Administrateur
Date d'inscription: 21/08/2007
Messages: 4544
Site web

Re: Introduction about the OpenAdsl project

So what are the latest news? smile

Hors ligne

 

#18 28/10/2010 23:23:14

obinou
Administrateur
Lieu: Cahors, 46
Date d'inscription: 29/08/2007
Messages: 461

Re: Introduction about the OpenAdsl project

Not much yet :-( My work has been taking all my time recently, but it's slowing down a bit, so I hope to have more time for me now.

Hors ligne

 

#19 14/01/2011 16:54:36

goundoulf
Administrateur
Date d'inscription: 21/08/2007
Messages: 4544
Site web

Re: Introduction about the OpenAdsl project

Some people are also interested on the OpenWrt forum: BCM 63xx chips - ADSL State of art

And in one post there's a link to a very interesting site: http://bcm63xx.sipsolutions.net

Remember http://bcm-specs.sipsolutions.net and http://bcm-v4.sipsolutions.net which led to the b43 driver: http://wireless.kernel.org/en/users/Drivers/b43/

Hors ligne

 

#20 09/06/2012 15:57:15

goundoulf
Administrateur
Date d'inscription: 21/08/2007
Messages: 4544
Site web

Re: Introduction about the OpenAdsl project

Hors ligne

 

Pied de page des forums