Al 05/11/10 19:16, En/na Scott Nicholas ha escrit:
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-
Now that I have wired ethernet working, I'm tackling the wifi chip.
This router has an ar9223, with the calibration data stored in flash. I
copied the data in ath9k_platform_data (btw, I noticed that ar71xx
redefines it adding fields, should I copy the .h to my platform or is
there a better way
Al 24/11/10 14:18, En/na John Crispin ha escrit:
ok, can you send a patch in that case that makes use of the new pci hook
please so we can apply the patch + a use case
I use the same hook to add support for the atheros ar9223 (using ath9k)
in the arv4518pw.
+static struct ath9k_platform_data
En/na ngp ngp ha escrit:
split mach-arv4518 from mach-arv45xx. fix leds. include support for
ath5k wireless driver
Why didn't you add support for it in mach-arv45xx instead?
(Just asking, don't know what's the best policy, in my experiments with
the arv7518 I just added it to mach-arv45xx).
Al 21/11/10 19:19, En/na Luca Olivetti ha escrit:
Now that I have wired ethernet working, I'm tackling the wifi chip.
This router has an ar9223, with the calibration data stored in flash. I
copied the data in ath9k_platform_data (btw, I noticed that ar71xx
redefines it adding fields, sho
Al 04/12/10 15:42, En/na Luca Olivetti ha escrit:
Al 21/11/10 19:19, En/na Luca Olivetti ha escrit:
Now that I have wired ethernet working, I'm tackling the wifi chip.
This router has an ar9223, with the calibration data stored in flash. I
copied the data in ath9k_platform_data (btw, I no
Al 05/12/10 12:53, En/na Luca Olivetti ha escrit:
Al 04/12/10 15:42, En/na Luca Olivetti ha escrit:
Al 21/11/10 19:19, En/na Luca Olivetti ha escrit:
Now that I have wired ethernet working, I'm tackling the wifi chip.
This router has an ar9223, with the calibration data stored in fla
Al 05/12/10 15:38, En/na Luca Olivetti ha escrit:
This router has an ar9223, with the calibration data stored in flash. I
copied the data in ath9k_platform_data (btw, I noticed that ar71xx
redefines it adding fields, should I copy the .h to my platform or is
there a better way to avoid
Al 01/02/11 13:08, En/na Alexander Gordeev ha escrit:
Hi!
This patchset adds full USB support to ramips target. I've used dwc_otg
driver that was published on linuxppc-dev list. There were newer versions
of this driver since then but it's still a work in progress and there
were no major changes.
The following patch sets the gpio to activate usb on the arv7518pw
Signed-off-by: Luca Olivetti
---
Index: target/linux/lantiq/patches/400-mach-arv45xx.patch
===
--- target/linux/lantiq/patches/400-mach-arv45xx.patch (revisión
but since nobody replied when I asked, I did it
this way.
Note that the method described in
http://wiki.openwrt.org/doc/devel/patches
doesn't seem to work with mac80211, so I had to do the patch manually.
Signed-off-by: Luca Olivetti
---
Index:
package/mac80211/patches/410-ath9k-chec
ot
I could only test wifi in station mode and in the g band, and, while it
works, the performance is atrocious, however nobody helped so I cannot do
better.
Oh, and it needs the patch to mac80211 that I posted previously.
Signed-off-by: Luca Olivetti
---
Index: target/linux/lantiq/image/Mak
Al 26/02/11 16:23, En/na Joerg Albert ha escrit:
> Hi Luca,
>
> I have the same problem with my WAG160Nv2: Broadcom 6358 SoC with Atheros
> AR9223 and calibration data
> in the flash (unfortunately overwritten by my first boot of OpenWRT).
>
>
> On 12/08/2010 12:53
Al 26/02/11 17:22, En/na Luca Olivetti ha escrit:
>> may just need a conversion of val to little endian before writing:
>> __raw_writel(cpu_to_le32(val), mem + reg);
>>
>> This should yield the same result as your code changes, e.g.
>>
>>> 6
I'm still trying to make openwrt work on my router (now a lantiq target,
previously ifxmips) and I just noticed that the switch (an ar8216) doesn't
pass data between ports, i.e (warning, lousy ASCII art follows):
++
| Router with ar8216 |
++---+---+
Al 26/02/11 22:15, En/na Joerg Albert ha escrit:
> On 02/26/2011 06:21 PM, Luca Olivetti wrote:
>> Al 26/02/11 17:22, En/na Luca Olivetti ha escrit:
>
>>> Yes, I also have two areas beginning with 0xa5 0x5a, maybe you're right,
>>> the first one is just
>&
Al 27/02/11 12:11, En/na Maarten Bezemer ha escrit:
> On Sat, 2011-02-26 at 20:20 +0100, Luca Olivetti wrote:
>> I'm still trying to make openwrt work on my router (now a lantiq target,
>> previously ifxmips) and I just noticed that the switch (an ar8216) doesn't
>&g
Al 26/02/11 22:44, En/na Luca Olivetti ha escrit:
>> Maybe the vendor WLAN driver allowed override of the regdomain on
>> commandline.
>> Have you got access to any source code from the vendor of your device
>> (similar to the Linksys GPL tarballs etc.)?
>
>
Al 27/02/11 14:21, En/na Jonas Gorski ha escrit:
> Hi,
>
> On 26 February 2011 20:20, Luca Olivetti wrote:
>> I'm still trying to make openwrt work on my router (now a lantiq target,
>> previously ifxmips) and I just noticed that the switch (an ar8216) doesn't
Al 27/02/11 14:58, En/na Luca Olivetti ha escrit:
> Al 27/02/11 14:21, En/na Jonas Gorski ha escrit:
>> Hi,
>>
>> On 26 February 2011 20:20, Luca Olivetti wrote:
>>> I'm still trying to make openwrt work on my router (now a lantiq target,
>>> previously
Al 27/02/11 15:54, En/na Luca Olivetti ha escrit:
> Al 27/02/11 14:58, En/na Luca Olivetti ha escrit:
>> Al 27/02/11 14:21, En/na Jonas Gorski ha escrit:
>>> Hi,
>>>
>>> On 26 February 2011 20:20, Luca Olivetti wrote:
>>>> I'm still trying t
ovide a netif_rx function, so they should not be affected by
this patch.
Signed-off-by: Luca Olivetti
---
Index: target/linux/lantiq/patches/230-xway_etop.patch
===
--- target/linux/lantiq/patches/230-xway_etop.patch (revisión:
I'm quite confused by the various lantiq packages, I suppose they're for
the FXS ports, but no target is currently using them, I couldn't find any
documentation on their purpose or configuration.
The packages are
lqtapi
SUBMENU:=Voice over IP
TITLE:=Tapi drivers for Lantiq SoC
ltq-ifxos
SU
Al 27/02/11 20:30, En/na ralph.hem...@lantiq.com ha escrit:
> Hi Luca,
>
>> ltq-ifxos
> os abstraction layer - used to make the lantiq code
> portable across different embedded systems
>
>> ltq-kpi2udp
> handling of RTP packets within the kernel
>
>> ltq-tapi
> core driver - voice handling
>
>>
Al 27/02/11 21:21, En/na Luca Olivetti ha escrit:
> Al 27/02/11 20:30, En/na ralph.hem...@lantiq.com ha escrit:
>> Hi Luca,
>>
>>> ltq-ifxos
>> os abstraction layer - used to make the lantiq code
>> portable across different embedded systems
>>
>>>
Al 27/02/11 20:30, En/na ralph.hem...@lantiq.com ha escrit:
> maybe this is more of interest for you ?
> http://nbd.name/gitweb.cgi?p=owsip.git
> connect pjsip & tapi
Has it the features missing from tapi_sip?
from https://forum.openwrt.org/viewtopic.php?pid=120535#p120535
about tapi_sip:
"Outb
Al 28/02/11 11:11, En/na John Crispin ha escrit:
> On 27/02/11 21:59, Luca Olivetti wrote:
>> Al 27/02/11 20:30, En/na ralph.hem...@lantiq.com ha escrit:
>>
>>> maybe this is more of interest for you ?
>>> http://nbd.name/gitweb.cgi?p=owsip.git
>>> conn
nk that dsl1->dsl_a, dsl2->dsl_b, if that
isn't the case, then "dd" should be changed instead)
- "lzma d source dest" didn't work here (it should be "lzma -d -c source dest")
use lzcat instead
- (cosmetic) for consistency changed the only instan
Al 28/02/11 20:09, En/na John Crispin ha escrit:
>> Thank you for the clarification, but, does it have the features missing
>> from tapi_sip? (i.e., ringing, dialtone, dialling, etc.).
>>
>> Bye
>
> i am working on the remaining feature at the moment. currently basic
> calls work, but there are n
Al 27/02/11 21:31, En/na Luca Olivetti ha escrit:
> Al 27/02/11 21:21, En/na Luca Olivetti ha escrit:
>> Al 27/02/11 20:30, En/na ralph.hem...@lantiq.com ha escrit:
>>> Hi Luca,
>>>
>>>> ltq-ifxos
>>> os abstraction layer - used to make the la
Al 05/03/11 15:30, En/na Luca Olivetti ha escrit:
>
> Well, I tried with all packages selected properly but the result wasn't very
> encouraging.
>
> First this log message:
>
> IFX_MPS: CPU1 base address is invalid!
> IFX_MPS: firmware download error (-1)!
&g
Al 20/02/11 19:49, En/na Luca Olivetti ha escrit:
> ath9k doesn't check (and eventually swap) the endianness of caldata if
> platform_data is set.
>
> In my platform I have the caldata in flash (hence platform_data is set) but
> I need ath9k to swap the bytes, so I added a fi
Al 05/03/11 21:16, En/na John Crispin ha escrit:
>> Ok, I have to tell it where the firmware files are on the command line:
>>
>> root@OpenWrt:/lib/firmware# tapidemo --path /lib/firmware/
>> TAPI Demo Version 5.0.1.27
>> VAD is set to: IFX_TAPI_ENC_VAD_NOVAD - no voice activity detection.
>> Err
Al 05/03/11 21:25, En/na John Crispin ha escrit:
> On 05/03/11 21:20, Luca Olivetti wrote:
>> Al 05/03/11 21:16, En/na John Crispin ha escrit:
>>
>>>> Ok, I have to tell it where the firmware files are on the command line:
>>>>
>>>> root@Op
Al 05/03/11 22:04, En/na Luca Olivetti ha escrit:
> Al 05/03/11 21:25, En/na John Crispin ha escrit:
>> On 05/03/11 21:20, Luca Olivetti wrote:
>>> Al 05/03/11 21:16, En/na John Crispin ha escrit:
>>>
>>>>> Ok, I have to tell it where the firmware files
Al 06/03/11 13:15, En/na Luca Olivetti ha escrit:
> Will post patches once the pending ones are applied.
If you prefer, here's my cumulative patch that supersedes all patches
I previously posted for lantiq:
- gpio to activate usb on the arv7518pw
- improve support for the arv7518
Al 06/03/11 13:58, En/na Luca Olivetti ha escrit:
> Al 06/03/11 13:15, En/na Luca Olivetti ha escrit:
>
>> Will post patches once the pending ones are applied.
>
> If you prefer, here's my cumulative patch that supersedes all patches
> I previously posted for lantiq:
A
Al 06/03/11 19:05, En/na John Crispin ha escrit:
>
> i will merge the 2.6.37 update next week. this also obseltes extract.sh.
Because we'll then have an official voip firmware from lantiq or...?
Bye
--
Luca
___
openwrt-devel mailing list
openwrt-dev
Al 07/03/11 13:26, En/na John Crispin ha escrit:
> On 06/03/11 19:45, Luca Olivetti wrote:
>> Al 06/03/11 19:05, En/na John Crispin ha escrit:
>>
>>>
>>> i will merge the 2.6.37 update next week. this also obseltes extract.sh.
>>
>> Because we'll
Al 07/03/11 18:40, En/na John Crispin ha escrit:
> On 07/03/11 18:17, Luca Olivetti wrote:
>> Al 07/03/11 13:26, En/na John Crispin ha escrit:
>>> On 06/03/11 19:45, Luca Olivetti wrote:
>>>> Al 06/03/11 19:05, En/na John Crispin ha escrit:
>>>>
>>&g
Al 27/02/11 20:30, En/na ralph.hem...@lantiq.com ha escrit:
> maybe this is more of interest for you ?
> http://nbd.name/gitweb.cgi?p=owsip.git
> connect pjsip & tapi
Regarding this one, I see that owsip uses pjsip-ltq-tapi.
The initialization done in pjsip-ltq-tapi seems quite simpler than
the
Al 14/03/2011 6:43, En/na John Crispin ha escrit:
you will have to wait till i finished owsip and merge it in openwrt.
i know that you are really anxious, 95% of lantiq related mails are from
you, however, it is not ready.so you will have to wait.
Wait (1 year now) or pursue other alternatives
Al 14/03/11 13:16, En/na Luca Olivetti ha escrit:
> Al 14/03/2011 6:43, En/na John Crispin ha escrit:
>
>> you will have to wait till i finished owsip and merge it in openwrt.
>> i know that you are really anxious, 95% of lantiq related mails are from
>> you, however, it
Al 26/03/11 12:25, En/na Maarten Bezemer ha escrit:
> On Thu, 2011-03-24 at 17:57 -0500, Layne Edwards wrote:
>
>> I want to contribute, but I don't feel like I'm getting a warm
>> welcome.
>
> I feel the same way. Tried to contribute by fixing/patching things I
> found while using OpenWRT, but n
Al 28/03/11 21:44, En/na Mike Baker ha escrit:
> In all honesty I'd suggest opening a ticket on trac; I'm not sure who
> wrote the page suggesting they be emailed, but it defeats the purpose
> of having a bug tracking system.
Patches posted to the list go to patchwork (though I don't know if
it's
Al 29/03/2011 8:18, En/na John Crispin ha escrit:
Hi Luca,
i am about to merge some of your stuff. whilste looking over the rest i
noticed this ->
++ arv7518_ath9k_wmac_data.eeprom_data[0x208>>1]=0x82d4; /* Spain */
++ arv7518_ath9k_wmac_data.eeprom_data[0x20a>>1]=0x1f1f; /* as in st
Al 29/03/2011 9:32, En/na John Crispin ha escrit:
On 29/03/11 09:26, Luca Olivetti wrote:
Al 29/03/2011 8:18, En/na John Crispin ha escrit:
Hi Luca,
i am about to merge some of your stuff. whilste looking over the rest i
noticed this ->
++arv7518_ath9k_wmac_data.eeprom_data[0x208
Al 29/03/2011 9:48, En/na Luca Olivetti ha escrit:
I'll see what I can do for both issues (regdomain and generic), however
remember that I can only test with my router and wouldn't want to
mislead somebody else that it should also work with his.
BTW, if you can merge everything el
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 verbatim
Al 29/03/2011 9:59, En/na John Crispin ha escrit:
ok, so when the work is on your desk, its ok that it takes time, but
when it is on other peoples desks it is not ?! :)
interested in making wifi work (I'm not going to use it), besides,
performance is atrociously bad.
i guess you did somethin
Al 29/03/2011 10:32, En/na John Crispin ha escrit:
Hey Luis,
Sorry for intruding here, but are you guys using the in-kernel ath9k,
or the 'crap' vendor driver?
no intrusion ... happy about the comments. we are talking about latest
compat wireless ath9k.
AFAIS, the current in-kernel drive
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 rewrites the eep on the fly upon a read and
> fakes a ES reg. this is the patch we
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.
&
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:
>>>>
&
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
---
Index: package/ltq-vmmc/Makefile
===
--- package/ltq
patch 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
---
I
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
d
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 thi
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
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 to
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
test_a
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;
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 or as <*>?
If the form
Al 28/04/2011 0:16, En/na John Zavgren ha escrit:
Thanks for getting back to me... I'm still confused. I selected the
trivial package with the<*> option.
Try adding an empty Build/InstallDev section, e.g.
define Build/InstallDev
echo "InstallDev"
endef
Bye
--
Luca
_
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 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
Al 08/05/11 10:33, En/na John Crispin ha escrit:
>
> if it was 29 on ifxmips/ it will be 29 on lantiq/. only the stp and ebu
> gpios were mapped to new offsets. the first 32 gpios stayed the same.
Not related to the original question, but where I could find some documentation
on stp/ebu, what th
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 a
Al 08/05/11 20:16, En/na Andrej Vlašić ha escrit:
> About that usb gpio. I already tried 29 and some others to xway_register_dwc
> but it stays the same Disconnected port , and no power on it.
Are you sure?
I mean, I get the "DISCONNECTED PORT" message too if there's nothing
connected to the usb
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
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
t
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//trigger file and alternatively
>> writing "none" or "default-on"?
>> Or the same but with the "brightness" file?
>> Writin
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 17:25, En/na Andrej Vlašić ha escrit:
> Ok so I looked at that code, and below "// set clock gating" and there is:
> // set power
> writel(readl(DANUBE_PMU_PWDCR) & ~0x1, DANUBE_PMU_PWDCR);
> writel(readl(DANUBE_PMU_PWDCR) & ~0x40, DANUBE_PMU_PWDCR);
> writel(readl(DANU
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 shoul
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
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), b
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/u
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 ori
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/ar71
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 routin
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/
B
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 @@
>> +
x27;t 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 Oli
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
>
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
https:/
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 @@
>&
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
targets
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
[hadn't muck luck with this in the forum or in openwrt-users, I hope
this isn't too much noise for this list]
Hello, I have this router (labelled smc7908-isp) supplied by my isp for
double play (adsl+voip).
It is based on the infineon danube, the wifi chip is an atheros 2417,
the switch is a re
En/na John Crispin ha escrit:
> this board is an arcaydian design. we managed to boot openwrt on it last
> night. pci, net, gpi,led, button, wdt,... are working.
Good news!
> voipd and dsl are still missing.
Not so good, but I can wait (as long as I don't "break" the original
firmwarem, see b
En/na Jan Willies ha escrit:
> Luca Olivetti wrote:
>> En/na John Crispin ha escrit:
>>> which country / telco distributed the device ?
>> Spain, http://ya.com (now part of France Telecom but formerly part of
>> Deutsche Telekom, in fact I think that telekom in Germa
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 the firmware of the
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 bas
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 John Crispin ha escrit:
> since the weekend, wifi is workin on the arcaydian boards with danube
> though, so these boards can now be safely flashed
Is there a way for a clueless user like me to give it a try without
flashing? (considering that the brn bootloader allows to upload
somethin
En/na John Crispin ha escrit:
>> In case that's impossible, will flashing (how anyway?) preserve the brn
>> bootloader?
> no, you need to put u-boot on there
> i am trying to figure out a reliable way to reflash the brn loader etc...
Ok, I'll wait some more, I'm not in a hurry, I'm just salivati
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
>>
>> it's annex-a
>>
>> Bye
> so the 4518 is a 4519 without the analogue fxs port
You m
En/na John Crispin ha escrit:
>
> we will provide scripts in the next few days, that will explain how to
> do a full flash dump before puttin openwrt on the board.
>
> and the how to recover this image.
>
> also, the cpu has a serial bootloader inside the rom, just need to
Yes, I said that in
101 - 200 of 200 matches
Mail list logo
