[OpenWrt-Devel] inclusion of adm8668 / WRTU54G-TM

[Scott Nicholas]

I apoligize ahead of time. I am hardly a developer, but I've been
mucking around with the WRTU54G-TM since March. I was told to port to
2.6 to get included in trunk, and I did! I have tarball at
http://wrt.scottn.us/openwrt-trunk-adm8668.tar.gz

I tried to make it a patch with "svn diff", but it never included the
target/linux/adm8668/files so maybe a kind soul can do something with
it in tarball format, or just flame me.

I tried to keep it kinda minimal, and still need to re-do my quick
hack on tulip ethernet driver to be less agressive takeover..

Please direct me from here...

-Scott.

[Simon G]

Hi,

In case nothing happens, the trick is to do a svn add for all the extra
files and directories you have added, then do svn diff.
The svn add only adds locally. Its the svn ci (Check in or commit) that
would try to add them to the server.

Then you should get a better svn diff (Patch) to add here. If the devels.
are feeling happy they make use of your tar file though.

Regards,

Simon G.

Post by Scott Nicholas
I apoligize ahead of time. I am hardly a developer, but I've been

mucking around with the WRTU54G-TM since March. I was told to port to
2.6 to get included in trunk, and I did! I have tarball at

Post by Scott Nicholas
http://wrt.scottn.us/openwrt-trunk-adm8668.tar.gz
I tried to make it a patch with "svn diff", but it never included the

target/linux/adm8668/files so maybe a kind soul can do something with it
in tarball format, or just flame me.

Post by Scott Nicholas
I tried to keep it kinda minimal, and still need to re-do my quick hack

on tulip ethernet driver to be less agressive takeover..

Post by Scott Nicholas
Please direct me from here...
-Scott.
_______________________________________________
openwrt-devel mailing list
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[Stefan Monnier]

Post by Scott Nicholas
I apoligize ahead of time. I am hardly a developer, but I've been
mucking around with the WRTU54G-TM since March. I was told to port to
2.6 to get included in trunk, and I did! I have tarball at
http://wrt.scottn.us/openwrt-trunk-adm8668.tar.gz

That's very interesting. But I can't find anywhere a clear description
of the hardware it provides. Also, does your code support the phone
ports (e.g. can they work with asterisk?). What can you do with the
SIM thingies?


Stefan

[s***@scottn.us]

My findings are the phone ports will need VINETIC driver included in GPL sources only as binary.. And still yet a SIP program that uses it. The SIM chips could probably read a smartcard with correct driver, tho I cut the traces on mine for a USB port.

This port so far includes support for: serial console, ethernet, wifi (rt61). I have made changes for USB but did not include because it never enumerated... Tho 2.4 kernel usb worked..

The router has 64mb of ram and USB port with small modification and can be had for $15 usually. Is good machine. Would love to use phone ports but I haven't the programming skills.

-Scott

Sent via BlackBerry Bold 9700

-----Original Message-----
From: Stefan Monnier <***@iro.umontreal.ca>
Sender: openwrt-devel-***@lists.openwrt.org
Date: Sat, 16 Oct 2010 23:17:54
To: <openwrt-***@lists.openwrt.org>
Reply-To: OpenWrt Development List <openwrt-***@lists.openwrt.org>
Subject: Re: [OpenWrt-Devel] inclusion of adm8668 / WRTU54G-TM

Post by Scott Nicholas
I apoligize ahead of time. I am hardly a developer, but I've been
mucking around with the WRTU54G-TM since March. I was told to port to
2.6 to get included in trunk, and I did! I have tarball at
http://wrt.scottn.us/openwrt-trunk-adm8668.tar.gz

That's very interesting. But I can't find anywhere a clear description
of the hardware it provides. Also, does your code support the phone
ports (e.g. can they work with asterisk?). What can you do with the
SIM thingies?


Stefan

_______________________________________________
openwrt-devel mailing list
openwrt-***@lists.openwrt.org
https://lists.openwrt.org/mai

[Florian Fainelli]

Hi Scott,

Post by Scott Nicholas
I apoligize ahead of time. I am hardly a developer, but I've been
mucking around with the WRTU54G-TM since March. I was told to port to
2.6 to get included in trunk, and I did! I have tarball at
http://wrt.scottn.us/openwrt-trunk-adm8668.tar.gz

I had a quick review at the code, and I must say, it's fantastic! You made a
great port. Nothing looks ugly, on the contrary you have implemented the
target in a clean manner.

You should add your copyright lines and GPLv2 disclaimer on top of each .c file
in arch/mips/adm8668. Eventually also keep copyright from the original
porters.

Here are some coments on the way you created patches-2.6.35/100-adm8668.patch,
you should split the patch like this:

- create a patch which adds the target in arch/mips/Makefile and
arch/mips/Kconfig
- create a patch which adds your MTD map driver
- create a third patch which hacks the tulip network driver
- create a fourth patch for your UART

This helps maintaining the patches when the target needs to be updated to a
newer kernel, and eases upstream submission.

The led support should be reworked to:
- create a gpiolib driver for ADM8668 which can be used not only for LEDs, but
in a generic manner
- define a gpio-leds platform_device so that you get your leds directly exposed
to userspace in /sys/class/leds

Almost all targets in OpenWrt implement gpiolib/gpio-leds, you can have a look
at ar71xx, ar7, bcm63xx for instance.

Unless I am mistaking, you have not included the make-lzma tool that you call
in image/Makefile to build the final image, can you post it as a separate patch
to trunk/tools?

Post by Scott Nicholas
I tried to make it a patch with "svn diff", but it never included the
target/linux/adm8668/files so maybe a kind soul can do something with
it in tarball format, or just flame me.
I tried to keep it kinda minimal, and still need to re-do my quick
hack on tulip ethernet driver to be less agressive takeover..

Yes, the changes you made there are quite intrusive, but I suppose that you
should be able to make the driver work on adm8668 without much troubles, and
especially without deleting parts of the driver for other architectures. Here
are some specific comments:

- #ifdef CONFIG_ADM8668, then if (tp->chip_id == IFADMNET) looks redundant to
me, and you should be able to just check on tp->chip_id right?

- if ((tp->chip_id == IFADMNET) && (csr6 & 1))
skb_pull(skb, 2);
looks like you need a switch driver maybe? I suppose you must strip from bytes
from the received ethernet frame?
OpenWrt has quite some switch drivers which can be runtime registered by a
network driver thanks to phylib. The tulip driver has not been converted to
using phylib, and this might be quite some work to cover all the various
flavors of the chip out there, so keeping your change might be the easiest way
to do it

I would love seeing a bootlog of that device, along with some showing of
/proc/cpuinfo, /proc/iomem, /proc/ioports to make sure your porting is
allright ;)

Thanks for your work!
--
Florian

[Florian Fainelli]

Hi again Scott,

Post by Florian Fainelli
Hi Scott,

Post by Scott Nicholas
I apoligize ahead of time. I am hardly a developer, but I've been
mucking around with the WRTU54G-TM since March. I was told to port to
2.6 to get included in trunk, and I did! I have tarball at
http://wrt.scottn.us/openwrt-trunk-adm8668.tar.gz

I had a quick review at the code, and I must say, it's fantastic! You made
a great port. Nothing looks ugly, on the contrary you have implemented the
target in a clean manner.
You should add your copyright lines and GPLv2 disclaimer on top of each .c
file in arch/mips/adm8668. Eventually also keep copyright from the
original porters.
Here are some coments on the way you created
- create a patch which adds the target in arch/mips/Makefile and
arch/mips/Kconfig
- create a patch which adds your MTD map driver
- create a third patch which hacks the tulip network driver
- create a fourth patch for your UART
This helps maintaining the patches when the target needs to be updated to a
newer kernel, and eases upstream submission.
- create a gpiolib driver for ADM8668 which can be used not only for LEDs,
but in a generic manner
- define a gpio-leds platform_device so that you get your leds directly
exposed to userspace in /sys/class/leds
Almost all targets in OpenWrt implement gpiolib/gpio-leds, you can have a
look at ar71xx, ar7, bcm63xx for instance.
Unless I am mistaking, you have not included the make-lzma tool that you
call in image/Makefile to build the final image, can you post it as a
separate patch to trunk/tools?

Forget about this comment, it built just fine here.

Post by Florian Fainelli

Post by Scott Nicholas
I tried to make it a patch with "svn diff", but it never included the
target/linux/adm8668/files so maybe a kind soul can do something with
it in tarball format, or just flame me.
I tried to keep it kinda minimal, and still need to re-do my quick
hack on tulip ethernet driver to be less agressive takeover..

Yes, the changes you made there are quite intrusive, but I suppose that you
should be able to make the driver work on adm8668 without much troubles,
and especially without deleting parts of the driver for other
- #ifdef CONFIG_ADM8668, then if (tp->chip_id == IFADMNET) looks redundant
to me, and you should be able to just check on tp->chip_id right?
- if ((tp->chip_id == IFADMNET) && (csr6 & 1))
skb_pull(skb, 2);
looks like you need a switch driver maybe? I suppose you must strip from
bytes from the received ethernet frame?
OpenWrt has quite some switch drivers which can be runtime registered by a
network driver thanks to phylib. The tulip driver has not been converted to
using phylib, and this might be quite some work to cover all the various
flavors of the chip out there, so keeping your change might be the easiest
way to do it
I would love seeing a bootlog of that device, along with some showing of
/proc/cpuinfo, /proc/iomem, /proc/ioports to make sure your porting is
allright ;)
Thanks for your work!
--
Florian