Re: "Home Grown" Daughterboards for Sale?

Greg,

> Well, I think we're missing some critical information and code in the 
> release. While the code may compile and run, there are configuration 
> options that would be greatly assisted if Actiontec could provide us with 
> a copy of the .config that they use to build their production kernels. I 
> do not believe that Actiontec is using the same code base they have 
> released in their production loads.
> 
> What we need to do is create a bullet point list of information that we 
> still need and provide it to Actiontec. Jason, for the remainder of the 
> time that he is there, will do his best to get us what he can. He is 
> moving to Monterey in April and won't be continuing with Actiontec.

Time's a wastin'!!  That sounds like a great plan!

So far I've discovered several things:

(1) Missing ".config" file for the production release.  I'm guessing that 
this is required under GPL because of how that file is normally derived 
from GPL'ed source.  However, this is just the "tip of the iceberg" w.r.t. 
"missing stuff".

(2) Missing kernel module "cnxtserial_buildin".  My work-around was to add 
manual exports of the kernel symbols "ldiscs" and "GPIO_SetGPIOIRQRoutine" 
in order to get the supplied object module to "insmod" without errors. 
Although this patch appears to work, we are stuck using the existing 
uClinux release and the module file "/lib/modules/cnxtserial_buildin.o" in 
the current Actiontec release ROM file system.  This may be true 
"proprietary code" and not subject to GPL. [sigh]

(2) Missing MTD device "mapping" driver, likely named "mtdflash".  Looking 
at the production release of "linux.bin" with "strings", the source code 
for this file *should be* located on someone's hard disk in this directory:

   /home/smao/debug/steven/topdir_for_tiburon/linux/drivers/mtd/maps

Also, there should be a modified version of "Config.in" there as well. 
Depending upon how this code was written, not supplying these source files 
may be a violation of GPL.  BTW: Based on the "debug" message I see on the 
console, this MTD "mapper" most likely uses the routines in "cnxtflash.c" 
to do it's work.

(3) The following file likely has been modified in the "release" version:

       /opt/uClinux/linux/arch/armnommu/mach-cx821xx/cnxtflash.c

One can determine this by looking at log messages on the console.  Some 
research would be needed to determine if this file is subject to GPL.

(4) A number of missing "user" programs.  Because I've been concentrating 
on re-building the kernel, I don't have a complete list.  One of these is 
"testcgi" which is the CGI-BIN program the the Web server "boa" uses for 
controlling the modem.  What *is* supplied as source code is an empty 
"stub" (i.e., /opt/uClinux/user/boa/src/testcgi.c").  The production 
release version actually does something very different than "test CGI 
requests"! :-)  Given it has the same name, it must be derived from the 
same code...GPL therefore applies!

> Incidentally, if anyone is looking to hire a good engineer, I think I 
> might know someone in the Montery area! ;)

He's moving to a very nice area!  Does he have a job!?  We hire telecommuters!

> Jason and I spoke this morning about the Flash Loader source code and 
> wether it can be released, or if it is still under the Conexxant IP 
> restriction. He was going to check on it.

Thanks for looking into this!  I'm hopeful...

> He did mention that the Linux based Flash Loader code has been blessed 
> for release, but he doesn't know wether it was included in the actual 
> download archive. I'd take a look through that code and see if it is in 
> there. If so, we might be able to use that to write a Windows based one.. 
> Or.. just use the Linux one on the Development workstations that we're 
> building the code from! ;)

A Linux-based USB flash re-load beats the heck out of a DOS-based one. 
However, some people (like me!) need both...I run Linux under VMware on my 
Windows laptop.  USB "pass-thru" is usually "iffy".

Also, at times, being able to recover a Actiontec Dual PC modem that is 
designed primarily to plug into Windows PCs, using one of those normally 
nearby PCs, is usually the easiest thing to setup.

Just give me the source code and I'll "make it sew"! :-)

>>Craig
>>ps. I have not tried to compile the Actiontec kernel
> 
> Your insight might be really valuable, given the experience that you have 
> with other platforms. Are you able to at least attempt a compilation given 
> the information that we've compiled so far and let us know what you run 
> into?

Craig: Feel free to contact me directly and I'll give you a "core-dump" on 
what I've discovered so far.

Best regards,

Bruce

-- 
  Bruce D. Lightner
  Lightner Engineering
  La Jolla, California
  Voice: +1-858-551-4011
  FAX: +1-858-551-0777
  Email: lightner-2huV/[email protected]
  URL: http://www.lightner.net/lightner/bruce/

__
ActionHack Mailing List - ActionHack-W7/[email protected]
http://www.express.org/mailman/listinfo/actionhack
http://www.embeddedlinuxinterfacing.com/wiki.php/ActiontecDualModem