[OpenWrt-Devel] [PATCH 1/1] adm8668 target: fix firstboot with new MTD map driver.
my-mkimage previously did not include the fs_mark of deadc0de because
upon formatting of jffs2 partition, U-Boot's CRC validation would not
allow the image to boot. This new MTD map will shrink the
kernel+rootfs+fs_mark image and recalculate the CRC, so that only the
kernel is part of the image validation. This also improves boot time,
since less is copied from FLASH-RAM. This is mostly from brcm47xx,
just with u-boot image vs TRX partitions.
Signed-off-by: Scott Nicholas scott.nicho...@scottn.us
Index: target/linux/adm8668/image/Makefile
===
--- target/linux/adm8668/image/Makefile (revision 24978)
+++ target/linux/adm8668/image/Makefile (working copy)
@@ -16,11 +16,14 @@
$(MAKE) -C lzma-loader \
KDIR=$(KDIR) \
clean compile
+ rm -f $(KDIR)/fs_mark
+ touch $(KDIR)/fs_mark
+ $(call prepare_generic_squashfs,$(KDIR)/fs_mark)
endef
define Image/Build
./my-mkimage $(KDIR)/loader.bin $(KDIR)/root.squashfs \
- $(BIN_DIR)/$(IMG_PREFIX)-$(1).bin
+ $(KDIR)/fs_mark $(BIN_DIR)/$(IMG_PREFIX)-$(1).bin
endef
$(eval $(call BuildImage))
Index: target/linux/adm8668/image/my-mkimage
===
--- target/linux/adm8668/image/my-mkimage (revision 24978)
+++ target/linux/adm8668/image/my-mkimage (working copy)
@@ -1,26 +1,33 @@
#!/bin/sh
# my-mkimage
-# This will just pad the kernel partition to 64k boundary, then add rootfs.
-# but we have to be fancy because u-boot mkimage is going to add 64
byte header.
+# This will pad given files to 64k boundaries to make a single u-boot image.
+# we have to be fancy because u-boot mkimage is going to add 64 byte
header, ...
+# and i only know basic arithmetic.. ;)
#
# Copyright (C) 2010 Scott Nicholas neutronsc...@scottn.us
-PATH_LOADER=$1
-PATH_ROOTFS=$2
-OUTPUT=$3
-
-# todo - check arguments...? nah...
-if [ -x $OUTPUT ]; then
- echo usage: $0 loader.bin root.squashfs output.bin
+[ $# -lt 2 ] {
+ echo usage: $0 loader.bin [rootfs.squashfs [fs_mark [...]]] output.bin
exit
-fi
+}
-OLDSIZE=$(stat -c%s $PATH_LOADER)
+OLDSIZE=$(stat -c%s $1)
NEWSIZE=$(((OLDSIZE / 65536 + 1) * 65536 - 64))
+dd if=$1 of=vmlinuz.tmp bs=$NEWSIZE conv=sync /dev/null 21
-dd if=$PATH_LOADER of=vmlinuz.tmp bs=$NEWSIZE conv=sync
-cat $PATH_ROOTFS vmlinuz.tmp
-../../../../staging_dir/host/bin/mkimage -A mips -O linux -T kernel
-C none -a 0x40 -e 0x40 -n ADM8668 Linux Kernel(2.4.31) -d
vmlinuz.tmp $OUTPUT
-rm vmlinuz.tmp
+shift
+appends=$(($# - 1))
-printf '\n\nOk done, now your squashfs starts on an erase boundary of
%x :)\n\n' $((NEWSIZE+64))
+echo
+while [ $appends -gt 0 ]; do
+ dd if=$1 of=temp bs=64k conv=sync /dev/null 21
+ printf ### '%s' starts at 0x%x\n `basename $1` $((NEWSIZE+64))
+ cat temp vmlinuz.tmp
+ shift
+ appends=$((appends-1))
+ NEWSIZE=$(stat -c%s vmlinuz.tmp)
+done
+echo
+
+../../../../staging_dir/host/bin/mkimage -A mips -O linux -T kernel
-C none -a 0x8040 -e 0x8040 -n ADM8668 Linux Kernel(2.4.31)
-d vmlinuz.tmp $1
+rm temp vmlinuz.tmp
Index: target/linux/adm8668/files/drivers/mtd/maps/adm8668.c
===
--- target/linux/adm8668/files/drivers/mtd/maps/adm8668.c (revision 24978)
+++ target/linux/adm8668/files/drivers/mtd/maps/adm8668.c (working copy)
@@ -1,125 +1,341 @@
/*
- * Copyright (C) 2010 Scott Nicholas neutronsc...@scottn.us
+ * Copyright (C) 2010 Scott Nicholas neutronsc...@scottn.us
+ * Copyright (C) 2006 Felix Fietkau n...@openwrt.org
+ * Copyright (C) 2005 Waldemar Brodkorb w...@openwrt.org
+ * Copyright (C) 2004 Florian Schirmer (j...@tuxbox.org)
*
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
+ * original functions for finding root filesystem from Mike Baker
*
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
*
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
Re: [OpenWrt-Devel] [PATCH] base-files: refactoring load_modules()
On Sun, Jan 16, 2011 at 6:00 PM, Stefan Monnier monn...@iro.umontreal.ca wrote: As an outsider, I'd just like to say that I find this new code more complex for very little benefit. really? more lines maybe, but straightforward and not hacky. I guess it's a question of taste, but to me that current code is clean, straightforward, and concise. About as good as it gets. Stefan I like Bastian's refactorings using only ash builtins. if ever a micro image is needed, sed/awk can go away. yes? I don't think the amount of lines really matters much once it all gets squashed into a squashfs anyway. The readability and removal of dependencies gets two thumbs up. Just this noob's two cents, Scott ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] 802.1Q VLAN support for Infineon ADM6996 switch chip
Hello, On Sun, Jan 9, 2011 at 2:54 AM, Peter Lebbing pe...@digitalbrains.com wrote: Hello developers, I have written a switch driver for the Infineon ADM6996 switch chip, which in my case is in a D-Link DSL-G624T modem/router. It implements 802.1Q based VLAN support, via the swconfig interface. Other fancy features of the switch chip are not (yet) implemented. My machine also uses an ADM6996, but there are at least two very different ones. 6996F and 6996M are two which I came across. Can you tell me which this is for? I haven't looked at my datasheet in some months to recall enough to identify if this would work. But hopefully, eventually, this will help my target as well down the line. Thank you very much for your contributions. Regards, Scott Nicholas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] rt61pci performance
I've an idea... On Fri, Oct 22, 2010 at 5:56 AM, Helmut Schaa helmut.sc...@googlemail.com wrote: Hi, CC'ed rt2x00 list ... Am Donnerstag 21 Oktober 2010 schrieb Scott Nicholas: On Thu, Oct 21, 2010 at 12:25 PM, Helmut Schaa helmut.sc...@googlemail.com wrote: I fully agree. The same also applies to rt2800pci SoCs (rt305x) which are working quite good already (in terms of WiFi) but also show more CPU usage then the legacy drivers. IMO it would really make sense to work on improving rt2x00 mac80211 instead of putting much work in a maybe-better-behaving but unmaintainable driver. For example you could start by profiling rt61pci (if your platform supports perf counters) to see if you can find any obvious bottlenecks. My platform SoC is MIPS32 4Kc core which does not seem to do profiling... I wonder if some reports made on different machine would help steer me in the correct direction, and if anyone has access to rt61pci that could do this.. I don't have a rt61pci card but since it shares a lot of base code with rt2800pci we should be able to find some suitable starting points. Ivo, any ideas (or starting points) what we could do to improve CPU usage in rt2x00 on embedded systems? Thanks, Helmut I haven't looked at much code lately, have been busy. But I wanted to replace u-boot on my router with netconsole enabled. My ethernet is similar to DEC21140-pci and Linksys/Infineon copied that driver and changed little. netconsole doesn't work, and tftp transfers have always taken a couple timeouts before they start. I've also been skipping around in the book See MIPS Run and yesterday found a DEC21140 datasheet to decode the TX status descriptor. The issue here is that the packet DMA address is physical, and nowhere is the cache flushed/write-backed or whatever. So it spins in a loop waiting for the packet to transmit, and it'll timeout, then enter the send routine again later and loop another million times and hopefully for some odd reason the memory has been written and it works the 2nd-3rd time. I wonder then, if this is similar issue for rt61pci. Since it's primary target would be x86 and their DMA is completely coherent, eh? This wouldn't probably explain the performance on the RDC/i486 clone that Florian mentioned though, and I am not very educated at the low-level workings of such things, but that's what I came up with. -- scott ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Could someone help me with an MTD / CRC32 problem?
On Sat, Nov 13, 2010 at 5:42 PM, Luka Perkov open...@lukaperkov.net wrote: On Wed, Nov 10, 2010 at 09:45:36PM -0500, Scott Nicholas wrote: I want my target to work on firstboot. I look how other targets will make image with 'deadc0de' at start of what will become jffs. This means I have to change the image CRC32 so that when it gets formatted, this part is not checked by u-boot next boot... The bootloader is old U-Boot. I cannot get crc32 calculated correctly.. I need to re-calculate the header and data CRC32, but we'll start with header since it's short and hopefully once I figure it out the data one will follow. Any ideas?? The first seed of '0' seems correct too from u-boot mkimage sources. :( pleas i've spent too long on this 1 bug. maybe other targets even do it different to ensure old parts of flash are erased? i still would like to resize image in flash on first boot. would allow squashfs replace without kernel. As now, kernel+squashfs are at the mercy of this crc. Maybe it's something simple I'm overlooking... My U-Boot bootm command: Marvell ? bootm bootm [addr [arg ...]] - boot application image stored in memory passing arguments 'arg ...'; when booting a Linux kernel, 'arg' can be the address of an initrd image This command calculates checksum for both kernel and ramdisk (kernel located at addr1 and ramdisk located at addr2) and then boots kernel: Marvell bootm addr1 addr2 This command calculates checksum only for kernel (kernel located at addr1) and then boots kernel: Marvell bootm addr1 Are you trying to make checksum for kernel and for ramdisk? OpenWrt does not use ramdisk this way. If you compile your image as ramdisk you get just one file. Thanks for the attempt, but I solved it. It was not an issue with bootloader at all. What I was trying to do is change the way MTD partitions are made in kernel to autodetect squashfs offset, and re-write the image header in flash so that the jffs marker (deadc0de) is not checked upon boot, much like brcm47xx target. Because once jffs formats this segment of flash, the crc32 changes, and U-boot would not boot the image. U-boot used crc32(0, data, len) which made me want to use crc32_le(0, data, len) but looking more at U-boot's crc32 function it actually XOR'd it with 0x before AND after. oops. R, Scott. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ag71xx: Fix ar8216 devices and remove the ar8216 workaround.
My suggestion was for the ifxmips.c ethernet driver in Linux, not
U-boot. A dirty hack to remove the filter upon initialization.
/target/linux/ifxmips/files/arch/mips/include/asm/mach-ifxmips/ifxmips.h
seems to lack the ENETS_CFG register, so I suggested that #define.
Then have a look at how other set_mac_address is made. adm5120 switch
driver calls eth_set_mac and then it's own function.. so you can set
the ndo_set_mac_address to ifxmips_set_macaddress and define something
like theirs. first tho define them in the ifxmips.h (ensure i'm right
about these, compare to linux and u-boot includes)
#define ENETS_CFG ((volatile u32
*)(IFXMIPS_PPE32_MEM_MAP + 0x1850))
#define ENET_MAC_DA0 ((volatile u32 *)(IFXMIPS_PPE32_MEM_MAP
+ (0x061B * 4)))
#define ENET_MAC_DA1 ((volatile u32 *)(IFXMIPS_PPE32_MEM_MAP
+ (0x061C * 4)))
static int ifxmips_set_mac_address(struct net_device *dev, void *p)
{
int ret;
struct sockaddr *addr = p;
ret = eth_mac_addr(dev, p);
if (ret)
return ret;
memcpy(ENET_MAC_DA0, addr-sa_data, ETH_ALEN);
return 0;
}
maybe?
R,
Scott.
On Fri, Nov 5, 2010 at 4:21 AM, Luca Olivetti l...@ventoso.org wrote:
En/na Scott Nicholas ha escrit:
Correct thing would be to initalize the values better in
ifxmips_mii_chip_init, so that filtering is not on, or to change
filter in set_mac?
I don't think that the u-boot initialization should be touched, it's ok as
it is.
I think that the correct thing to do would be to amend the ifxmips.c
ethernet driver to properly set promiscuous mode and the mac address, e.g.
to define functions for ndo_set_mac_address and ndo_change_rx_flags, but
that's the part I don't know how to do: I don't think I can simply access
memory mapped register like uboot does, can I?
Bye
--
Luca
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ag71xx: Fix ar8216 devices and remove the ar8216 workaround.
Correct thing would be to initalize the values better in
ifxmips_mii_chip_init, so that filtering is not on, or to change
filter in set_mac?
The first way should be easy. Maybe quickest work-around is turn off
that filter ?
#define ENETS_CFG ((u32 *)(IFXMIPS_PPE32_MEM_MAP + 0x1850))
at end of ifxmips_mii_chip_init:
ifxmips_w32(ifxmips_r32(ENETS_CFG) ~(128), ENETS_CFG);
Better way would to know the hardware and the default value for this register...
R,
Scott
On Thu, Nov 4, 2010 at 7:25 PM, Luca Olivetti l...@ventoso.org wrote:
Al 04/11/10 23:04, En/na Jonas Gorski ha escrit:
On 4 November 2010 19:44, Luca Olivettil...@ventoso.org wrote:
It turns out that the mac was different than the one set in u-boot.
For some reason the switch doesn't accept a different mac than the
initial
one (though in u-boot I can change the mac at will, once it boots linux
it
has to be the same mac).
Is this a feature of the ar8216, a bug or an error on my part?
This sounds more like the ethernet mac uses a different mac than linux
thinks it does, so the outgoing frames have the wrong linux source
address and the replies get silently dropped (assuming the ethernet
mac has a non-promiscuous mode or something like that).
Ah, I think I know what happens. Most probably the default for the ethernet
port in the danube chip is to not do any mac filtering, but during
initialization u-boot sets the mac address *and* sets the mac filtering
(from ifx_etop.c, ENET_MAC_DA0, ENET_MAC_DA1 and ENETS_CFG appears to be
registers of the danube chip):
static int lq_eth_init(struct eth_device *dev, bd_t * bis)
{
int i;
uchar *enetaddr = dev-enetaddr;
debug(lq_eth_init %x:%x:%x:%x:%x:%x\n,
enetaddr[0], enetaddr[1], enetaddr[2], enetaddr[3],
enetaddr[4], enetaddr[5]);
*ENET_MAC_DA0 = (enetaddr[0]24) + (enetaddr[1]16) +
(enetaddr[2] 8) + enetaddr[3];
*ENET_MAC_DA1 = (enetaddr[4]24) + (enetaddr[5]16);
*ENETS_CFG |= 128; /* enable filter for unicast packets */
but in the linux driver .ndo_set_mac_address = eth_mac_addr, so changing the
mac in linux does nothing to the chip, hence the filtering with the mac set
in u-boot takes place.
If u-boot doesn't touch the network, the linux driver will work regardless
of the mac because there's no hardware filtering.
Unfortunately I don't know how to modify the driver to do the right thing.
Bye
--
Luca
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ag71xx: Fix ar8216 devices and removethe ar8216 workaround.
Sorry if I'm misguiding, didn't follow the entire thread just beginning and
this.
maybe just try tcpdump. Find which extra bytes are there, and see how the phy
driver is handling all this.
Such that, maybe it has a flag saying to handle priority tags, but it doesn't
get set, yet you have them...
Is similar problem I had with adm8668..
-scott
Sent via BlackBerry Bold 9700
-Original Message-
From: Jonas Gorski jonas.gorski+open...@gmail.com
Sender: openwrt-devel-boun...@lists.openwrt.org
Date: Wed, 3 Nov 2010 13:33:47
To: OpenWrt Development Listopenwrt-devel@lists.openwrt.org
Reply-To: OpenWrt Development List openwrt-devel@lists.openwrt.org
Subject: Re: [OpenWrt-Devel] [PATCH] ag71xx: Fix ar8216 devices and remove
the ar8216 workaround.
On 2 November 2010 21:24, Luca Olivetti l...@ventoso.org wrote:
Well, I tried but I failed (unsurprisingly since I know nothing about Linux
network code).
This is a danube based board and this is the patch I tried:
--- trunk/target/linux/ifxmips/files-2.6.33/drivers/net/ifxmips.c.orig
2010-11-02 17:53:28.187618000 +0100
+++ trunk/target/linux/ifxmips/files-2.6.33/drivers/net/ifxmips.c 2010-11-02
20:02:13.871765000 +0100
@@ -141,8 +141,14 @@
skb_put(skb, len);
skb-dev = dev;
- skb-protocol = eth_type_trans(skb, dev);
- netif_rx(skb);
+ if (priv-phydev) {
+ printk(KERN_INFO using ar8216 netif_rx\n);
+ priv-phydev-netif_rx(skb);
+ } else {
+ printk(KERN_INFO cannot see ar8216 here!!!\n);
+ skb-protocol = eth_type_trans(skb, dev);
+ netif_rx(skb);
+ }
priv-stats.rx_packets++;
priv-stats.rx_bytes += len;
The printks are to see what path the code took, it takes the correct one
but still the network doesn't work (but I still can see the arp entries).
The code looks good. I don't know much about proper kernel debugging,
so my next step would be e.g. printk'ing the first 16 bytes of
received packets, so you have the ethernet header + the atheros
header, if VLAN is enabled (you should only see the atheros header in
this case).
So you should probably either see:
[dst mac] [src mac] [0x80 0x0?] [first two bytes of content]
or
[ath header] [dst mac] [src mac] [0x81 0x00]
I think the atheros header should look something like [0x10 0x8src_port]).
Btw, you should have ethX: AR8216 switch driver attached. line in
your kernel log, do you see it?
Regards
Jonas
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] quietly grep in mmc_over_gpio.init
The mmc_over_gpio package spits out configfs on /config type configfs
(rw,relatime) after first run. This fixes it.
Signed-off-by: Scott Nicholas scott.nicho...@scottn.us
--- a/package/mmc_over_gpio/files/mmc_over_gpio.init2010-10-12
22:40:48.230463672 -0400
+++ b/package/mmc_over_gpio/files/mmc_over_gpio.init2010-10-31
01:00:50.941151180 -0400
@@ -37,7 +37,7 @@
mount_configfs() {
# FIXME: This should probably be done somewhere else.
- mount | grep configfs
+ mount | grep -q configfs
if [ $? -eq 0 ]; then
# already mounted
return 0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] rt61pci performance
rt2x00/rt61pci wireless driver eats all the CPU. Any other boards use this? Anyone with experience with this driver know if there was a better version than the current compat-wireless in svn? Sent via BlackBerry Bold 9700 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] rt61pci performance
That's what I was afraid of. Tho there is some CPU usage with legacy driver using 2.4 kernel, it is sooo much worse with rt2x00. Softirqs take 50% and kernel other 50% (almost, I rounded up a bit). Won't be worth submitting my work if no one would use it due bad wifi. So I'll backport some changes to my backfire-2.4 build and maybe see what sort of effort it will take to compile the SoftAP legacy driver to 2.6. Although it came in GPL tarball, I've not seen any softap drivers elsewhere so I'll have to verify license first .. -scott --Original Message-- From: Florian Fainelli Sender: Florian Fainelli To: openwrt-devel@lists.openwrt.org To: scott.nicho...@scottn.us Subject: Re: [OpenWrt-Devel] rt61pci performance Sent: Oct 21, 2010 7:35 AM Hello Scott, On Thursday 21 October 2010 13:08:47 scott.nicho...@scottn.us wrote: rt2x00/rt61pci wireless driver eats all the CPU. Any other boards use this? Anyone with experience with this driver know if there was a better version than the current compat-wireless in svn? I think this is inherent to the design of the driver and possibly of the hardware. I have seen high CPU usages on RDC (i486 clone) as well. -- Florian Sent via BlackBerry Bold 9700 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] rt61pci performance
Helmut, On Thu, Oct 21, 2010 at 12:25 PM, Helmut Schaa helmut.sc...@googlemail.com wrote: I fully agree. The same also applies to rt2800pci SoCs (rt305x) which are working quite good already (in terms of WiFi) but also show more CPU usage then the legacy drivers. IMO it would really make sense to work on improving rt2x00 mac80211 instead of putting much work in a maybe-better-behaving but unmaintainable driver. For example you could start by profiling rt61pci (if your platform supports perf counters) to see if you can find any obvious bottlenecks. My platform SoC is MIPS32 4Kc core which does not seem to do profiling... I wonder if some reports made on different machine would help steer me in the correct direction, and if anyone has access to rt61pci that could do this.. -Scott ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] inclusion of adm8668 / WRTU54G-TM
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. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] inclusion of adm8668 / WRTU54G-TM
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 monn...@iro.umontreal.ca Sender: openwrt-devel-boun...@lists.openwrt.org Date: Sat, 16 Oct 2010 23:17:54 To: openwrt-devel@lists.openwrt.org Reply-To: OpenWrt Development List openwrt-devel@lists.openwrt.org Subject: Re: [OpenWrt-Devel] inclusion of adm8668 / WRTU54G-TM 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-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
