The following is some general information about Eagle IV product. This will 
also answer your questions:

-       There are two DSP versions available for Eagle IV: ISDN and POTS. We 
will send the ISDN one later:
        o       #define E4_ISDN_BIN_FILE    "e4_dsp_code_isdn.bin"
        o       #define E4_POTS_BIN_FILE    "e4_dsp_code_pots.bin"

-       For each DSP code there is a default cmv file. For some of the ISPs we 
might need to provide different cmv files. We can come up with a generic name 
for ISP specific cmvs. The driver first looks for the ISP cmv and if it is not 
found, then loads the default cmv file. So in the installation we ask for the 
ISP name and if it is in our database, we copy the related cmv file to the same 
directory which we keep default file. This way, user can go to the Eagle IV 
website and get the latest CMV file whenever it is updated.  

        o       #define DEFAULT_E4CMV_ISDN_FILE   CONF_DIR "/CMV4i.txt"
        o       #define DEFAULT_E4CMV_POTS_FILE   CONF_DIR "/CMV4p.txt"

-       The DSP code is the same for Windows and Linux driver. The DSP code in 
Windows is divided to 3 files for backward compatibility with older Windows 
operating systems. 

-       The DSP portion of the Eagle IV chipset has a new technology. So the 
core is completely different from Eagle I, II, and III. The DSP code for this 
core is released in binary form. There is no backward compatibility with 
pervious generations.

-       The CMV structure in Eagle IV is changed. There is no CMV name anymore; 
it is replaced with group code. The following is the new structure:

typedef struct
{
    uint16_t function;
    uint16_t group;
    uint16_t address;
    uint16_t index;
    union
    {
        uint16_t ushort[EAGLEIV_CMV_PAYLOAD_SIZE];
        uint32_t ulong[EAGLEIV_CMV_PAYLOAD_SIZE/2];
    } payload;
} e4_cmv_msg_t;

In Eagle I, II, and III we had CMV name (4 characters) but here we have 
command/group number. Valid values for group are from 1 to 8. In most cases, 
the return value for the CMV command is in the first two bytes of the payload. 
So in cmv text file I used CMD1 to CMD8 to represent group 1 to group 8. In the 
windows driver, for cmv text file, the old naming convention is used but I 
believe it will cause confusion between two products. 

Eagle IV cmv example:

To monitor the line status, the driver issues the command < command/group=2 
address=0 index=0 > and the result is 1 = IDLE, 5, 6=ADSL training and 7 is 
operational.

-       After plug-in, we load 8051 USB firmware once and then we read DSP code 
and configuration files and save them in the memory. We can load the DSP 
firmware to the modem several times ( and also cmvs in the cmv file ) but the 
USB firmware is loaded once after plug-in.

-       We need to modify the driver to detect the hardware and load the 
related DSP firmware for ISDN and POTS modems.  

-       In Windows there are two different drivers, one for Eagle IV and one 
for previous generations. Do you think we should do the same and create a new 
project? It is definitely a lot easier if we remove the old code and have a 
clean driver for Eagle IV.

-       If the header size is fixed, we can add that in the beginning of the 
DSP firmware. Do you want me to provide a DSP file which has the header file 
added to the beginning of the binary? In the driver we just need to ignore the 
header part and save the rest in the memory.

BTW, I opened an account in gna.org. The user name is "farinam"

Do you want me to go over the state machine? 

Best regards,
Farinam


-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Benoît Audouard
Sent: Monday, October 02, 2006 2:40 AM
To: ueagleatm-dev@gna.org
Subject: [Ueagleatm-dev] Re: eagle4

Re,
Le vendredi 29 septembre 2006 à 16:36 -0700, Farinam Farahmand a écrit :

> Ikanos is ready to collaborate with Ueagleatm team. We are considering
> the proposed "2-clause BSD" license for two portions of the Eagle IV
> Linux device driver: 
>   
> 1)      Eagle IV 8051 USB firmware binary --converted to a hex table. 
> 2)      Eagle IV datapump binary (L1Code.bin). 

ok, fine, that's very good news. 
Nothing more will be needed to get the modem to work ? Are there
versions for ISDN too ?
  
Could you open an account at https://gna.org so that we give you access
to the projects ?

> To go ahead with this proposal, we would like to focus on Eagle IV
> modems only. To do this, we need to put the 8051 USB firmware in a
> separate file which includes the "2-clause BSD" header. With every
> release of the Eagle IV data pump binary (L1Code.bin), we will provide a
> text file which contains the license as well as release information.   
  
> I will be the main contact person during this process. I will be
> responsible for getting answers to legal and technical question.

ok, that's a good start. Once done for eagle4, it will be easier to
achieve as well for others.
Indeed, we'll need the same licensing for other USB firmware + DSPcode
which are still distributed, it can be seen afterwards though.
Maybe, in parallel, you could launch the same legal research for
previous versions of USB firmware & DSPcode. Furthermore, we do not see
the reason why you could not have the source code available for older
ones (adi930 & eagleI, for example) or what could prevent Ikanos from
releasing it under a libre license, if you're the copyright owner, as
those chipsets are nearly obsolete ?
Does the proposed planning seem realistic for eagle4 licensing (by 15th
october). How long do you think it will take for previous
firmware/DSPcode ? (1 month ?).

BTW, you may see as well with your communication department how you
could advertise the fact that you are contributing to libre software,
this can be seen as a positive effort.

> 1 - I will send out the license proposal for USB firmware and Eagle IV
> data pump (L1Code.bin) for review and will get back to you with the
> modified version. 

Do not send the files on the mailing-list as that may be over a
megabyte, maybe you'll be able to upload them either on a ftp server at
Ikanos or via sftp at gna.org, just warn the public mailing-list when
available (giving md5sum to verify them properly).
The recommended format would be the one used by ueagle-atm or the
current format will do (no more BNM ?), if we can transform it.

> 2 - It was recommended to have a dedicated driver for Eagle IV to avoid
> licensing problems. 

Really ?!
As the copyright owner of your changes you can choose the license for
them. When including them in eagle-usb, it automatically makes them
distributed as GPL (as a derived work of eagle-usb). 
This is partly what currently prevents us from including your changes in
the drivers ueagle-atm (for Linux) and ueagle (for *BSD), as we want to
keep respectively dual licensing BSD+GPL and BSD. 
To work on ueagle-atm / ueagle, you'll have to commit the changes
directly on our svn / cvs (which you're entitled to, as copyright owner)
or provide them separately with BSD licensing.
So, could a dual BSD + GPL be applied to new developments so that they
may be integrated either in usbatm or ueagle-atm or ueagle more easily ?

> 3 - CMV commands in Eagle IV are completely different. None of the
> previous CMVS are applicable to this new product. 

We'll need values that simply work and their meaning. I hope they still
work by country / ISP (type of DSLAM in fact) as adding the type of
modem will make configuration a bit more complex (well, adding some
specific files should do for the functionality). 
We'll be documenting all this at 
http://atm.eagle-usb.org/wakka.php?wiki=DocEagle4

> 4 - I understand that there is a need for documentation here but I
> prefer to provide answers to the questions in the emails. I will do my
> best to answer the questions in detail. 
> 
> Please list the questions you have and I'll get the answers for you. 

ok, we'll be preparing more questions while you obtain licensing
information for USB firmware & DSPcode. Do not hesitate to send some
documentation though, as it will avoid unnecessary guessing and multiple
copy/paste...
Here are some of them : 

1. does it exist now the functionality to force a reinit of the modem
(without unplugging it/replugging) and (re-)send the USB firmware (then
DSPcode) ?

2. why are CMV / DSPcode different between windows driver and linux
one ?
For windows, 3 cmv files : cmv4.txt, cmv4p.txt, cmv4i.txt, DSPcode file
completely different : like L1E4*.bin
For Linux, 1 CMV file, DSPcode in one *bin (perhaps is it identical to
the windows ones, once concatenated ?)

3. Could the driver manage different DSPcode, depending on the modem
perhaps ? (You already told us that DSPcode was backward compatible for
eagleIII, is it still the case for eagleIV ?)

4. We had previously seen that technically, a header / description could
be added to BNM files : format s-record motorola see
http://home.socal.rr.com/awi/srecords.htm
The proposed patch is to put : "2-clause BSD" in the S0 record (text is
available ?) => did you check this possibility ?

We'll see if we use https://gna.org/bugs/?group=eagleusb to track
questions/answers then put the resulting documentation at
http://atm.eagle-usb.org/wakka.php?wiki=DocEagle4 if you accept the
license for documentation on our wiki
http://atm.eagle-usb.org/wakka.php?wiki=WikiLicense
You could directly put your answers on it as this is a wiki freely
editable (see the link "ParametresUtilisateur" to register and "Editer
cette page" to edit the content, not forgetting to save it with button
"Sauver", you cannot break anything as all changes are archived).

More to come ;-)

@++
Ben'. aka baud123

> 
> -----Original Message-----

> Date: Mon, 25 Sep 2006 08:51:02 +0200
> From: Beno?t Audouard <[EMAIL PROTECTED]>
> Subject: [Ueagleatm-dev] eagle4 chipset
> To: ueagleatm-dev@gna.org
> Message-ID: <[EMAIL PROTECTED]>
> Content-Type: text/plain
> 
> Hi all and Ikanos people, hi Farinam (welcome back)
> 
> As some of you may have seen on the forum 
> http://forum.eagle-usb.org/viewforum.php?f=11
> or our wiki
> http://dev.eagle-usb.org/wakka.php?wiki=SagemFast800E4En
> 
> A new Eagle(tm) chipset  is available : eagle4 
> It's not yet supported by ueagle-atm (though already shipped by
> orange.fr ISP for example).
> 
> We were a bit disappointed not to have been involved earlier in the
> developments, we would have recommended developing for ueagle-atm as it
> is already included in the Linux kernel (and ueagle in *BSD). 
> Anyway, a driver based on eagle-usb (hence GPL) has been developed by
> Ikanos (thank you Farinam), hence GPL.
> Sagem sent us this driver which is currently being tested.
> 
> We would like to provide Ikanos with our feedback, but first : things
> need to be a bit organized, in an open-way :
> - using our public mailing-list when possible
> - provide eagle-usb.org team with a correct licensing for the
> USB-firmware and DSPcode, the proposal remaining 2-clause BSD
>  http://atm.eagle-usb.org/wakka.php?wiki=FirmwareLicensing
> This license seemed appropriate last time the subject was discussed
> (with ADI at the time, in the meantime maybe things have changed and
> source-code could be available for older firmwares like adi930 or
> eagleI ?)
> I hope you'll understand this step by step approach : we enjoyed your
> feedback for eagle3 (a technical success story IMHO), nevertheless
> licensing is as important as technical aspects.
> 
> Farinam, could you identify for us an entitled person that can address
> the licensing item ?
> Would you agree to use our cvs/svn for developments ? (it only requires
> an account at https://gna.org we would add you to allow you to benefit
> from our development infrastructure).
> Farinam : first, we'll have some  questions about conception, if you
> have any documentation (with a license like "GFDL without invariant
> sections" or CC-BY-SA, preferably), see proposed licensing at
> http://atm.eagle-usb.org/wakka.php?wiki=FirmwareLicensing#doc
> Notably our questions would be : why a dedicated driver to eagle4 ?
> which new protocol for this driver (CMV, other commands) ? 
> More to come, once the license issue is addressed.
> 
> Here is a tentative planning, since our requests through Sagem begun by
> late-july, we hope Ikanos already begun to identify what needs to be
> done :
> - could you answer by end of september for approval of the identified
> steps (and identify an entitled person for licensing issues) ?
> - we'd like to have license issue clarified by 15th October, so that
> real work can begin for end-user's sake. Does this seem possible ?
> 
> Looking forward to working collaboratively with Ikanos,
> 
> Best Regards,
> Ben'. aka baud123



_______________________________________________
Ueagleatm-dev mailing list
Ueagleatm-dev@gna.org
https://mail.gna.org/listinfo/ueagleatm-dev


_______________________________________________
Ueagleatm-dev mailing list
Ueagleatm-dev@gna.org
https://mail.gna.org/listinfo/ueagleatm-dev

Reply via email to