El 25/04/11 13:54, Luca Olivetti ha escrit:
Hello,
some time ago I found this project for boards based on the infineon
vinetic and using lantiq's IFX_TAPI:
http://midge.vlad.org.ua/svn/trunk/openwrt-midge/package/oem-voip/
I adapted it to the danube, rewrote it to support multiple sip
El 02/08/14 14:20, John Crispin ha escrit:
Hi Luca,
a bit of nitpicking ...
if i look at
https://code.google.com/p/danube-voip/source/browse/libab/libab/* for
example, the license headers are missing.
could you add them either to the files or add a LICENSE file or similar
? i would
El 02/08/14 17:59, Luca Olivetti ha escrit:
El 02/08/14 14:20, John Crispin ha escrit:
Hi Luca,
a bit of nitpicking ...
if i look at
https://code.google.com/p/danube-voip/source/browse/libab/libab/* for
example, the license headers are missing.
could you add them either to the files
Hello,
I just received an usb wifi adapter that I wanted to use with an openwrt
router, but the Chinese lottery, instead of the expected chipset, gave
me an adapter based on the ralink/mediatek mt7601u.
I managed to make it work on the laptop with the supplied driver and a
couple of patches
El 19/09/14 19:24, Luca Olivetti ha escrit:
Hello,
I just received an usb wifi adapter that I wanted to use with an openwrt
router, but the Chinese lottery, instead of the expected chipset, gave
me an adapter based on the ralink/mediatek mt7601u.
I managed to make it work on the laptop
El 19/09/14 19:24, Luca Olivetti ha escrit:
I made an openwrt recipe but it doesn't work (I see the interface but as
soon as I try to ifconfig up it segfaults), I guess it's an endianness
problem (I also tried without the second patch, just in case).
I'm almost sure it's an endianness issue
El 19/09/14 21:58, Luca Olivetti ha escrit:
El 19/09/14 19:24, Luca Olivetti ha escrit:
I made an openwrt recipe but it doesn't work (I see the interface but as
soon as I try to ifconfig up it segfaults), I guess it's an endianness
problem (I also tried without the second patch, just in case
El 20/09/14 17:35, Luca Olivetti ha escrit:
OK, it's a matter of adding -DRT_BIG_ENDIAN to WFLAGS *but* it still
doesn't work: it progresses further (it reads most of the eeprom values
correctly, including the mac, but a couple of values are still different
from the laptop
El 22/09/14 01:51, Claudio Leite ha escrit:
I'm not sure the MediaTek driver still uses the old format from the
Ralink driver. If so, this might be helpful:
https://github.com/WRTnode/openwrt-packages/blob/master/ralink/ralink-wifi/files/lib/wifi/ralink.sh
I think that was for a project
El 22/09/14 09:54, Luca Olivetti ha escrit:
El 22/09/14 01:51, Claudio Leite ha escrit:
I'm not sure the MediaTek driver still uses the old format from the
Ralink driver. If so, this might be helpful:
https://github.com/WRTnode/openwrt-packages/blob/master/ralink/ralink-wifi/files/lib/wifi
The following patch adds a new uboot configuration for the arv7518PW board.
It's the same as the arv4518PW but with CONFIG_AR8216_SWITCH instead of
CONFIG_RTL8306_SWITCH.
The configuration for the arv752DPW22 also uses the ar8216 but the network
doesn't work.
Signed-off-by: Luca Olivetti l
Al 15/03/12 19:38, En/na John Crispin ha escrit:
On 15/03/12 19:33, Luca Olivetti wrote:
The configuration for the arv752DPW22 also uses the ar8216 but the network
doesn't work.
;-)
It didn't work for me, but a user on the forum says it works for him :-/
The only difference I could find
Al 15/03/12 20:16, En/na John Crispin ha escrit:
On 15/03/12 20:15, Luca Olivetti wrote:
Al 15/03/12 20:13, En/na Luca Olivetti ha escrit:
Al 15/03/12 19:38, En/na John Crispin ha escrit:
On 15/03/12 19:33, Luca Olivetti wrote:
The configuration for the arv752DPW22 also uses the ar8216
Al 29/03/11 18:30, En/na John Crispin ha escrit:
On 29/03/11 18:06, Luca Olivetti wrote:
Al 29/03/11 10:32, En/na John Crispin ha escrit:
AFAIS, the current in-kernel driver relies on regulatory domain for
frequency restrictions.
It could solve your current problem.
yes, the proposed patch
Al 25/03/12 19:01, En/na Luca Olivetti ha escrit:
Al 29/03/11 18:30, En/na John Crispin ha escrit:
On 29/03/11 18:06, Luca Olivetti wrote:
Al 29/03/11 10:32, En/na John Crispin ha escrit:
AFAIS, the current in-kernel driver relies on regulatory domain for
frequency restrictions.
It could
Al 28/03/12 00:49, En/na John Crispin ha escrit:
Hi Luca,
you were right, i was wrong, i am terribly sorry if the delay caused any
inconvenience to you
thanks for your understanding,
Don't worry, I waited for one year, I can wait a few days longer.
Bye
--
Luca
Al 28/03/2012 7:44, En/na John Crispin ha escrit:
On 28/03/12 01:42, Luca Olivetti wrote:
I can wait a few days longer.
what are you waiting for now ?
To revert the patch that uses a fixed regdomain and apply the one that
makes it dependent on a kernel command line switch.
http
Al 14/05/12 21:53, En/na Pieter Voorthuijsen ha escrit:
Hello,
I would like to know what kind of transfers speeds I can expect with
the recent ath9k driver.
On my xway chip in the dgn3500 I can create a 150Mbps connection. When
starting transfers, it peaks to 3,5Mib and after that drops
Al 23/05/12 19:23, En/na Luka Perkov ha escrit:
Other long hard nights how John said were spent trying to make wifi
and lan working...
At least your hard night was taken into consideration, mines were sitting in
patchwork for ~1 year, then wrongly applied and not credited.
Bye
--
Luca
As per the subject, the function ath_pci_fixup (in
arch/mips/lantiq/xway/pci-ath-fixup.c) is called very early in the boot
process, before ath9k_eeprom_probe (in arch/mips/lantiq/xway/ath_eep.c)
has had any possibility to call ltq_pci_ath_fixup.
The net result is that the fixup isn't done and the
Al 08/09/13 18:08, En/na Luca Olivetti ha escrit:
As per the subject, the function ath_pci_fixup (in
arch/mips/lantiq/xway/pci-ath-fixup.c) is called very early in the boot
process, before ath9k_eeprom_probe (in arch/mips/lantiq/xway/ath_eep.c)
has had any possibility to call ltq_pci_ath_fixup
Al 09/09/13 08:01, En/na John Crispin ha escrit:
On 08/09/13 18:50, Luca Olivetti wrote:
Al 08/09/13 18:08, En/na Luca Olivetti ha escrit:
As per the subject, the function ath_pci_fixup (in
arch/mips/lantiq/xway/pci-ath-fixup.c) is called very early in the boot
process, before
Al 29/03/2011 9:58, En/na John Crispin ha escrit:
So what's the part that I should clean up?
register_ath9k function, the fixups etc. the whole patch is a complete
mess, whoich is not understandable, let alone the fact that it does not
follow kernel code style
I copied that almost
Al 29/03/11 18:30, En/na John Crispin ha escrit:
On 29/03/11 18:06, Luca Olivetti wrote:
Al 29/03/11 10:32, En/na John Crispin ha escrit:
AFAIS, the current in-kernel driver relies on regulatory domain for
frequency restrictions.
It could solve your current problem.
yes, the proposed patch
Al 29/03/11 21:21, En/na Felix Fietkau ha escrit:
On 2011-03-29 6:38 PM, Luca Olivetti wrote:
Al 29/03/11 18:30, En/na John Crispin ha escrit:
On 29/03/11 18:06, Luca Olivetti wrote:
Al 29/03/11 10:32, En/na John Crispin ha escrit:
AFAIS, the current in-kernel driver relies on regulatory
The makefile was missing the source filename, so it would install a directory
instead of
the coefficients file, breaking voice applications.
Signed-off-by: Luca Olivetti l...@ventoso.org
---
Index: package/ltq-vmmc/Makefile
does the same only if in the kernel command line the parameter
ath9k_regdomain and/or ath9k_caps are specified, hence the
xway_cmdline parameter in image/Makefile has to be changed not
to clobber the command line set in u-boot.
Signed-off-by: Luca Olivetti l...@ventoso.org
---
Index: target
Al 04/04/11 19:48, En/na Luca Olivetti ha escrit:
The following patch adds ath9k support to the arv7518 board.
I forgot to say that it needs this patch in mac80211
http://patchwork.midlink.org/patch/727/
without it, initialization of the card would fail (no other harm should be
done
Al 04/04/11 19:57, En/na Felix Fietkau ha escrit:
On 2011-04-04 7:51 PM, Luca Olivetti wrote:
Al 04/04/11 19:48, En/na Luca Olivetti ha escrit:
The following patch adds ath9k support to the arv7518 board.
I forgot to say that it needs this patch in mac80211
http://patchwork.midlink.org
Al 04/04/11 20:17, En/na Luca Olivetti ha escrit:
Al 04/04/11 19:57, En/na Felix Fietkau ha escrit:
On 2011-04-04 7:51 PM, Luca Olivetti wrote:
Al 04/04/11 19:48, En/na Luca Olivetti ha escrit:
The following patch adds ath9k support to the arv7518 board.
I forgot to say that it needs
Al 04/04/2011 20:21, En/na Luca Olivetti ha escrit:
Al 04/04/11 20:17, En/na Luca Olivetti ha escrit:
Al 04/04/11 19:57, En/na Felix Fietkau ha escrit:
On 2011-04-04 7:51 PM, Luca Olivetti wrote:
Al 04/04/11 19:48, En/na Luca Olivetti ha escrit:
The following patch adds ath9k support
Hello,
I'm trying to use ucimap, and I'd like to see when a string option is
present, e.g.
struct uci_test {
struct ucimap_section_data map;
char *test;
};
static int
test_init(struct uci_map *map, void *section, struct uci_section *s)
{
return 0;
}
static int
Al 23/04/11 15:57, En/na Luca Olivetti ha escrit:
Hello,
I'm trying to use ucimap, and I'd like to see when a string option is
present, e.g.
Another question is how to see if a bool/int option is present using ucimap.
struct uci_test {
struct ucimap_section_data map;
char *test
Hello,
some time ago I found this project for boards based on the infineon
vinetic and using lantiq's IFX_TAPI:
http://midge.vlad.org.ua/svn/trunk/openwrt-midge/package/oem-voip/
I adapted it to the danube, rewrote it to support multiple sip accounts,
use uci instead of libconfig, simplified
Al 27/04/11 20:00, En/na John Zavgren ha escrit:
I read the documentation and I wrote two packages. Both are visible
via make menuconfig. Both compile. But, neither the application or
the KLM get picked up and packed into the root file image.
Did you select them as M or as *?
If the former,
Al 07/04/11 14:16, En/na Luca Olivetti ha escrit:
Al 04/04/2011 20:21, En/na Luca Olivetti ha escrit:
Al 04/04/11 20:17, En/na Luca Olivetti ha escrit:
Al 04/04/11 19:57, En/na Felix Fietkau ha escrit:
On 2011-04-04 7:51 PM, Luca Olivetti wrote:
Al 04/04/11 19:48, En/na Luca Olivetti ha
Al 07/05/11 23:23, En/na Andrej Vlašić ha escrit:
I also looked up at those arcadyan board configs, and some of them have
_EBU addess and _USB pin defined.
I know that on this router usb power is on gpio 29( gpl source says that )
So you'll have to define it for your board in
Al 08/05/11 11:13, En/na John Crispin ha escrit:
EBU - external bus unit
similar to STP but parallel. the xway has 4 x 16 bit ioport ranges that
can be mapped to a special memory location. data written to that
location is that physically written to the D0-15 lines on the memory
bus. in
Al 08/05/11 18:45, En/na John Crispin ha escrit:
Thank you for the detailed explanation.
I have an LVC373A (octal latch), so it's probably EBU, isn't it?
How do I try it?
Bye
try this lq_register_gpio_ebu(XYZ);
as the latch comes up in a undefined state, the values are random. to
Al 09/05/2011 0:31, En/na Luca Olivetti ha escrit:
It turns out that the ebu, in the gpio_led structure, uses gpio starting
from 32, so defining fake leds using gpios 32-40 I could map all missing
leds.
Since they're active low, I used lq_register_gpio_ebu(0xff), so they all
turn off as soon
Al 09/05/11 17:14, En/na John Crispin ha escrit:
The next question is, how can I control (some of) the leds from an
userspace program?
Opening the /sys/class/leds/led name/trigger file and alternatively
writing none or default-on?
Or the same but with the brightness file?
Writing a trigger
Al 10/05/11 00:51, En/na Luka Perkov ha escrit:
The board has standard EJTAG pinout. With urjtag I can dump only part of
flash:
If the board uses the brn bootloader, maybe you can use my quick'n'dirty
tool to dump the flash:
http://code.google.com/p/brndumper/
Bye
--
Luca
Al 10/05/11 23:36, En/na Andrej Vlašić ha escrit:
Mac address could be read from nvram (both primary and secondary
bootloader are modified u-boot), but the eeprom_data is the problem.
I dunno how to locate it inside my binary, is there any special hex
value which represents that?
It should
Al 11/05/11 00:29, En/na Luca Olivetti ha escrit:
Al 10/05/11 23:36, En/na Andrej Vlašić ha escrit:
Mac address could be read from nvram (both primary and secondary
bootloader are modified u-boot), but the eeprom_data is the problem.
I dunno how to locate it inside my binary, is there any
Al 11/05/11 00:38, En/na Luca Olivetti ha escrit:
Al 11/05/11 00:29, En/na Luca Olivetti ha escrit:
Al 10/05/11 23:36, En/na Andrej Vlašić ha escrit:
Mac address could be read from nvram (both primary and secondary
bootloader are modified u-boot), but the eeprom_data is the problem.
I dunno
Al 11/05/11 00:48, En/na Luca Olivetti ha escrit:
That seems to be the case: the file starts with
0x13 0x00 0x8c 0x16 - 168c:0013
which is a correct pci id for the ar5212
And for the ar2414 (the one the sx763 is using), see here:
http://linuxwireless.org/en/users/Drivers/ath5k/devices
Al 13/05/11 21:13, En/na Andrej Vlašić ha escrit:
I'm not sure that's the correct thing to do: in the ar71xx architecture
(using ath9k), they're writing some register that modify the pci id, maybe
in your file there's also some fixup data?
Thanx for the info about wlan, I found out that in
Al 04/04/11 19:48, En/na Luca Olivetti ha escrit:
The following patch adds ath9k support to the arv7518 board.
The pci fixup routine (needed since the ar9223 has no onboard
eeprom) is taken from the ar71xx:
https://dev.openwrt.org/browser/trunk/target/linux/ar71xx/files/arch/mips/ar71xx
Al 22/05/11 15:08, En/na Luca Olivetti ha escrit:
[Don't know why I still bother submitting it, since it will be duly ignored]
Al 04/04/11 19:48, En/na Luca Olivetti ha escrit:
The following patch adds ath9k support to the arv7518 board.
The pci fixup routine (needed since the ar9223 has
Al 02/07/11 19:42, En/na Luca Olivetti ha escrit:
Here's a revised version of the patch against current trunk.
I thought that patchwork would replace the patch here:
http://patchwork.openwrt.org/patch/849/
instead it created a new one:
http://patchwork.openwrt.org/patch/1169/
Bye
--
Luca
Al 02/07/11 19:58, En/na Florian Fainelli ha escrit:
0) @@ -0,0 +1,11 @@
+--- a/drivers/net/wireless/ath/ath9k/eeprom_def.c 2011-02-08
17:33:42.0 +0100
b/drivers/net/wireless/ath/ath9k/eeprom_def.c2011-02-20
17:51:47.0 +0100 +@@ -147,7 +152,7 @@
+
provide a netif_rx function, so they should not be affected by
this patch.
The same operating mode was committed here (at the time lantiq_etop used
netif_rx):
https://dev.openwrt.org/changeset/26353
but it got lost in the recent reorganization of the lantiq code.
Signed-off-by: Luca Olivetti l
Al 02/07/11 20:34, En/na John Crispin ha escrit:
On 02/07/11 20:15, Luca Olivetti wrote:
Al 02/07/11 19:58, En/na Florian Fainelli ha escrit:
0) @@ -0,0 +1,11 @@
+--- a/drivers/net/wireless/ath/ath9k/eeprom_def.c 2011-02-08
17:33:42.0 +0100
b/drivers/net/wireless/ath/ath9k
Al 02/07/11 20:54, En/na John Crispin ha escrit:
oops ... that got lost, i will also send it upstream to the lmo tree ...
Oh, I thought that was just an openwrt hack.
Bye
--
Luca
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
Al 02/07/11 20:49, En/na Luca Olivetti ha escrit:
Al 02/07/11 20:34, En/na John Crispin ha escrit:
On 02/07/11 20:15, Luca Olivetti wrote:
Al 02/07/11 19:58, En/na Florian Fainelli ha escrit:
0) @@ -0,0 +1,11 @@
+--- a/drivers/net/wireless/ath/ath9k/eeprom_def.c2011-02-08
17:33
Al 05/07/2011 1:04, En/na John Crispin ha escrit:
So, what's the final decision?
Should I forget about ath9k support on this board?
Bye
why always so huffy ?
Because, as you always say, I'm impatient ;-) since
has the open question of the patch possibly breaking ath9k on other
Al 05/07/11 22:47, En/na Matthias Buecher / Germany ha escrit:
But now I run into another issue with ltq-tapi:
Unsurprisingly, since, AFAIK, that's only meant for lantiq hardware,
so you should deselect it.
Did you select it in make menuconfig or was it selected automatically?
Bye
--
Luca
Al 18/07/11 22:17, En/na John Crispin ha escrit:
Hi,
found a board from arcadyan that has a ath9k eeprom inside flash. i'll
try to test merge his asap
The problem was the possible side effect of the ath9k patch on chipsets with
onboard eeprom.
With flash emulation the patch works as-is(apart
Al 25/07/11 15:16, En/na John Crispin ha escrit:
On 25/07/11 14:45, Luca Olivetti wrote:
Al 18/07/11 22:17, En/na John Crispin ha escrit:
Hi,
found a board from arcadyan that has a ath9k eeprom inside flash. i'll
try to test merge his asap
The problem was the possible side effect
Al 28/11/2011 10:35, En/na John Crispin ha escrit:
At least that's what's done for ath9k devices in the ar71xx platform
(and what I tried to do with this, now bitrotten, patch
http://patchwork.openwrt.org/patch/1169/)
is the performance issue that you patch has fixed ?
I don't think so,
Hello,
last time I tried to build openwrt (july 2011), it generated a uImage in the
build_dir.
Now it only generates a kernel.
The old directory from July (linux-lantiq_xway) contains:
vmlinux
vmlinux-ARV7518PW
vmlinux-ARV7518PW.lzma
vmlinuz.elf
uImage-ARV7518PW
The new directory after
Al 28/01/12 23:46, En/na John Crispin ha escrit:
How do I generate an uImage now?
Bye
Hi,
they should be located here
$ ls build_dir/linux-lantiq_danube/uImage-*
build_dir/linux-lantiq_danube/uImage-ARV7525PW
build_dir/linux-lantiq_danube/uImage-ARV752DPW22
Al 29/01/12 00:47, En/na Luca Olivetti ha escrit:
Al 28/01/12 23:46, En/na John Crispin ha escrit:
How do I generate an uImage now?
Bye
Hi,
they should be located here
$ ls build_dir/linux-lantiq_danube/uImage-*
build_dir/linux-lantiq_danube/uImage-ARV7525PW
build_dir/linux
Al 29/01/12 10:41, En/na John Crispin ha escrit:
Due to conflict that I didn't notice during svn update, I had an old
image/Makefile that depended on CONFIG_TARGET_lantiq_xway instead of
CONFIG_TARGET_lantiq_danube.
Bye
Well, I'm not that familiar with svn, but I thought it would mark
with wpa-psk2.
I did not change anything in the fixup code, so the difference in performance
is either due to changes in mac80211 or in my methodology to measure it (then I
used wget with the router in station mode, now I used iperf with the router in
ap mode).
Signed-off-by: Luca Olivetti l
Al 29/01/12 19:40, En/na Luca Olivetti ha escrit:
The following patch adds ath9k support to the arv7518 board.
I forgot: I observed a strange thing.
In the default (autogenerated?) /etc/config/wireless, the device was named
radio0, while the correct name is wlan0.
With that configuration, wlan0
Al 29/01/12 19:59, En/na Jo-Philipp Wich ha escrit:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi.
I forgot: I observed a strange thing. In the default (autogenerated?)
/etc/config/wireless, the device was named radio0, while the
correct name is wlan0.
No, its not the correct name.
Al 06/02/2012 19:08, En/na Florian Fainelli ha escrit:
Actually, I have never seen a single MIPS system out there having such a boot
ROM capability.
The danube has it.
Bye
--
Luca
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
Al 14/02/12 11:43, En/na Ithamar R. Adema ha escrit:
If ARM isn't a hard requirement I'd take a look at the Infineon/Lantiq
solutions, they support/are supported by OpenWRT and are commonly used for
routers with FXS features.
The problem is, the voice firmware available with openwrt is out
Al 14/02/12 20:31, En/na John Crispin ha escrit:
The problem is, the voice firmware available with openwrt is out of date
(the driver complains it's too old) and it crashes
the CID feature on the 2nd voice channel causes a crash in svd. inside
owsip this crash does not happen
Hello, I
Al 14/02/12 23:42, En/na Luca Olivetti ha escrit:
Al 14/02/12 20:31, En/na John Crispin ha escrit:
The problem is, the voice firmware available with openwrt is out of date
(the driver complains it's too old) and it crashes
the CID feature on the 2nd voice channel causes a crash in svd
Al 14/02/12 20:39, En/na Luka Perkov ha escrit:
In TAPI sources in OpenWrt is nice documentation, you only need doxygen
to build it.
Doxygen documentation is only useful as a complement to proper documentation
(which exists but it's not publicly available).
The difference is like night and
Al 15/02/12 17:28, En/na Ithamar R. Adema ha escrit:
On 02/15/2012 12:01 AM, Luca Olivetti wrote:
Doxygen documentation is only useful as a complement to proper documentation
(which exists but it's not publicly available).
The difference is like night and day.
The person asking
Al 21/02/2012 10:33, En/na lee.es...@nowonline.co.uk ha escrit:
Thanks John ... it was already configured and I had a reboot this
morning, interestingly though it doesn't actually look like the lantiq
driver ... the first backtrace I get once after boot, doesn't seem to be
a problem, the
Al 21/02/2012 10:56, En/na John Crispin ha escrit:
please build a kernel with KALLSYMS enable
Does it work now?
Last time I tried it, it didn't work, but it was a while ago
http://pastebin.ca/2072861
Bye
--
Luca
___
openwrt-devel mailing list
Al 21/02/2012 12:38, En/na John Crispin ha escrit:
On 21/02/12 12:36, Luca Olivetti wrote:
Al 21/02/2012 12:15, En/na John Crispin ha escrit:
On 21/02/12 12:13, Luca Olivetti wrote:
Al 21/02/2012 10:56, En/na John Crispin ha escrit:
please build a kernel with KALLSYMS enable
Does it work
Al 21/02/12 13:29, En/na Luca Olivetti ha escrit:
Al 21/02/2012 12:38, En/na John Crispin ha escrit:
On 21/02/12 12:36, Luca Olivetti wrote:
Al 21/02/2012 12:15, En/na John Crispin ha escrit:
On 21/02/12 12:13, Luca Olivetti wrote:
Al 21/02/2012 10:56, En/na John Crispin ha escrit:
please
Al 24/02/12 19:17, En/na Robert Ryan ha escrit:
I see eth0, eth0.1, eth0.2 devices but none of them appear to be functional.
I would expect at least the WAN port to work without switch drivers but
perhaps I'm mistaken. I can assign IPs and ping the local address but can't
ping to/from any
Al 27/02/12 18:45, En/na Robert Ryan ha escrit:
I've been looking around for the right place to patch this but I'm having
difficulty finding a similar file that's not lantiq-specific. Can anyone
point me in the right direction? I've looked in the entire
target/linux/ramips/rt305x and
En/na Luca Olivetti ha escrit:
En/na Luca Olivetti ha escrit:
I cannot really read german, and much less 40 pages of it ;-) but the
only way to know for sure is to open it and/or get a bootlog (arcadyan
makes many models, e.g. the speedport w700v is based on the amazon chipset).
I found
En/na John Crispin ha escrit:
http://img512.imageshack.us/my.php?image=dscn1845rl6.jpg
http://img443.imageshack.us/my.php?image=dscn1846ix5.jpg
http://img443.imageshack.us/my.php?image=dscn1847rp1.jpg
openwrt runs on the devices shown in the images. however, please do not
try to flash it yet,
En/na Brian J. Murrell ha escrit:
Release Candidate 1 for Kamikaze 8.09
[...]
Supported targets:
[...]
* Infineon Danube/TwinPass
So is it possible to load it on my arcadyan/smc7908?
If so, how? What's working and what isn't?
By browsing the repository I
En/na [EMAIL PROTECTED] ha escrit:
Hi,
voip and dsl are not working yet.
at the moment, the ifxmips is stable but mainly tested on eval kits
i have the arcaydian board running, but flashing it involves soldering
some resistors etc
it is not reliable yet. i hope to have more info by
Hello,
I'd like to know if ifxmips is currently flashable on an arcadyan based
router (isp7908-a) with the brn bootloader.
Looking at the sources I can see some references to brn in the mtd
driver, but there are no instructions anywhere about the ifxmips port,
on which boards it can be used,
En/na Andreas Mohr ha escrit:
ftdi_sio tty layer issue: http://www.pubbs.net/kernel/200910/12236/
Sorry for the reply not directly related to openwrt, but the past couple
of months I've been pulling at straws over a nightmarish problem and
maybe it's related.
At the above link it says:
En/na Ithamar R. Adema ha escrit:
Hi,
It seems ifxmips is one of the few MIPS architectures in OpenWRT that
does not use the mips multimachine support code.
Is it still being worked on?
I've been waiting for the last one and a half year for some
documentation on how to install it to my
En/na Ithamar R. Adema ha escrit:
http://thread.gmane.org/gmane.comp.embedded.openwrt.devel/1612
Hmmm, looking quickly at the thread it seems there is quite a bit of
experimentation to do to get it to work. Also note that all the phone
related features are closed-source, you can expect to get
En/na j...@phrozen.org ha escrit:
smc-7908-isp is mzon bsed and the drivers wont work on it
Nope, it's a danube.
Quoting Luca Olivetti l...@ventoso.org:
En/na Nico ha escrit:
* Infineon Danube/TwinPass with open DSL VoIP drivers (ifxmips)
Where can I find more information about
En/na j...@phrozen.org ha escrit:
whats the ARV number of the pcb ?
According to the label
ARV4518PW-A-LF-LT
http://img512.imageshack.us/i/dscn1845rl6.jpg/
(I uploaded some other photos but they are not there anymore).
Quoting Luca Olivetti l...@ventoso.org:
En/na Luca Olivetti ha
En/na j...@phrozen.org ha escrit:
we already support the followup version of this unit.
So maybe with some guidance I can get it working on mine?
any chance you can donate aunit ? i am having trouble finding a
supllier in germany.
As I already told you in private, I need my only unit and
Al 30/04/10 10:42, En/na Victor Pablos Ceruelo ha escrit:
I've been trying to collect some info on installing
openwrt in this unit.
https://forum.openwrt.org/viewtopic.php?pid=108245
Hey, this is the same one I have.
blogic is looking for one unit to port openwrt to it, he has it already
En/na Victor Pablos Ceruelo ha escrit:
Hi,
I'm looking for the less expensive way of sending packages to Germany
(from Spain).
As it is the only extra unit we have, I wanna be sure that it will
arrive there,
but postal services I'm looking at are really expensive.
Do you know how to send
Al 30/09/10 19:53, En/na John Crispin ha escrit:
we can make uboot for many of the other arcaydian boards and i will be
adding them to the wiki next week. however for the ARV4518 and ARV4519
we have no uboot yet due to a missing switch driver. i hope to find the
time soon to start hacking one,
En/na Luca Olivetti ha escrit:
Al 30/09/10 19:53, En/na John Crispin ha escrit:
we can make uboot for many of the other arcaydian boards and i will be
adding them to the wiki next week. however for the ARV4518 and ARV4519
we have no uboot yet due to a missing switch driver. i hope to find
En/na Jonas Gorski ha escrit:
The inclusion of the ar8216 driver in ar71xx most probably broke
networking for those devices.
The ag71xx driver currently unconditionally adds/removes the header
on ar8216 devices independent whether the header is enabled or not.
The ar8216 driver can handle that
En/na Felix Fietkau ha escrit:
On 2010-04-06 4:26 PM, Jonas Gorski wrote:
The inclusion of the ar8216 driver in ar71xx most probably broke
networking for those devices.
The ag71xx driver currently unconditionally adds/removes the header
on ar8216 devices independent whether the header is
En/na Luca Olivetti ha escrit:
En/na Jonas Gorski ha escrit:
On 2 November 2010 17:25, Luca Olivetti l...@ventoso.org wrote:
BTW, doesn't the ar8216 driver already modifies the function table of
the
attached device?
/* VID fixup only needed on ar8216 */
if (pdev-addr == 0
Al 02/11/10 17:35, En/na Jonas Gorski ha escrit:
This is only the half of it, it replaces the TX function, but it can't
overwrite the RX function. So it still needs help from the ethernet
driver. This is where this code comes into play:
if (ag-phy_dev) {
En/na Jonas Gorski ha escrit:
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
Yes, that will be my next step
header, if VLAN is enabled (you
Al 03/11/10 13:33, En/na Jonas Gorski ha escrit:
On 2 November 2010 21:24, Luca Olivettil...@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:
---
1 - 100 of 157 matches
Mail list logo
