Re: [OpenWrt-Devel] [PATCH 2/2] ipq40xx: add support for Aruba AP-303
El 16/11/23 a les 11:06, Robert Marko ha escrit: I asked here https://forum.openwrt.org/t/apboot-dump-for-aruba-iap11-ap303-or-compatible-u-boot/177595/2 I have shared a dump from my AP11 that worked with OpenWrt. But please make sure they did not enable secure boot in the mean time. Thank you, that worked. I'll update the forum post on how to flash it. I don't have a wiki account to update the device page though. Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] ipq40xx: add support for Aruba AP-303
El 17/12/19 a les 12:52, David Bauer ha escrit: 3. Configure the bootargs and bootcmd for OpenWrt. $ setenv bootargs_openwrt "setenv bootargs console=ttyMSM1,9600n8" $ setenv nandboot_openwrt "run bootargs_openwrt; ubi part aos1; ubi read 0x8500 kernel; bootm 0x8500" $ setenv ramboot_openwrt "run bootargs_openwrt; setenv ipaddr 192.168.1.105; setenv serverip 192.168.1.75; netget; set fdt_high 0x8700; bootm" $ setenv bootcmd "run nandboot_openwrt" $ saveenv Hello, as explained here https://forum.openwrt.org/t/aruba-iap-11-apboot-downgrade-invalid-instant-small-business-image/120921 it is no longer possible to install openwrt because they have removed the bootm command from apboot. I asked here https://forum.openwrt.org/t/apboot-dump-for-aruba-iap11-ap303-or-compatible-u-boot/177595/2 for the old apboot image (it's possible to flash the spi from the new apboot) but I'm wondering if it would be possible to compile a compatible u-boot for this AP? Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: fix for lantiq (danube) usb
El 5/7/20 a les 22:37, Martin Blumenstingl ha escrit: Hi Luca, On Sun, Jul 5, 2020 at 3:07 PM Luca Olivetti wrote: El 5/7/20 a les 13:59, Luca Olivetti ha escrit: escrit: I'm recompiling again in case I misplaced the section in my previous test. In ~30-40 minutes it should be ready and I'll report back. Success! I probably did something wrong before. I'm attaching the patch against 19.07.3 and my device, but I think the same should be done for trunk and other devices with a similar dts. please let me know if I should be sending the patch for master (previously known as "trunk"). I have no way of testing it, but with your test results I'm confident that it'll work Well, yes, I think so. Even if the usb still has issues, at least it initializes and somewhat works. If you look at the "related tasks" in bug https://bugs.openwrt.org/index.php?do=details_id=1634 you'll see that it also affects the arv752dpw and ar9 (and most probably all other boards where the regulator is misplaced), I'm confident the fix is the same, though I have no way of testing it. Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: fix for lantiq (danube) usb
El 5/7/20 a les 15:14, Luca Olivetti ha escrit: but I'm happy enough that this is fixed now. Any chance of having a working rtl8812au driver? ;-) Well, not even the rt73 one works fine: I configured it as an AP, I can connect just fine but then, when I try to push some data (connecting to fast.com[*]) it hangs the router and it reboots after a few seconds. I don't think the cause is the rt73 driver (it's been quite stable on linux forever) but the dwc2 driver on this board. Just a guess though. [*] I'm currently using the router as a repeater with the single radio configured both as a wds client and as an AP, I wanted to see if using another radio would improve the performance. Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: fix for lantiq (danube) usb
El 5/7/20 a les 15:07, Luca Olivetti ha escrit:
El 5/7/20 a les 13:59, Luca Olivetti ha escrit: escrit:
I'm recompiling again in case I misplaced the section in my previous
test. In ~30-40 minutes it should be ready and I'll report back.
Success!
I probably did something wrong before.
I'm attaching the patch against 19.07.3 and my device, but I think the
same should be done for trunk and other devices with a similar dts.
Now it would be nice to also remove these harmless warnings ("supply
vusb_[da] not found" and "Mode Mismatch Interrupt"):
# dmesg | grep dwc2
[5.769881] dwc2 1e101000.usb: 1e101000.usb supply vusb_d not found,
using dummy regulator
[5.776840] dwc2 1e101000.usb: 1e101000.usb supply vusb_a not found,
using dummy regulator
[5.784970] dwc2 1e101000.usb: dwc2_core_reset() HANG! Soft Reset
GRSTCTL=8001
[5.930874] dwc2 1e101000.usb: DWC OTG Controller
[5.934191] dwc2 1e101000.usb: new USB bus registered, assigned bus
number 1
[5.941041] dwc2 1e101000.usb: irq 62, io mem 0x1e101000
[ 239.438602] dwc2 1e101000.usb: Mode Mismatch Interrupt: currently in
Host mode
[ 239.444386] dwc2 1e101000.usb: Mode Mismatch Interrupt: currently in
Host mode
[ 239.638464] usb 1-1: new high-speed USB device number 2 using dwc2
[ 239.643522] dwc2 1e101000.usb: Mode Mismatch Interrupt: currently in
Host mode
[ 239.650233] dwc2 1e101000.usb: Mode Mismatch Interrupt: currently in
Host mode
but I'm happy enough that this is fixed now.
Any chance of having a working rtl8812au driver? ;-)
Bye
--
Luca
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: fix for lantiq (danube) usb
El 5/7/20 a les 13:59, Luca Olivetti ha escrit: escrit:
I'm recompiling again in case I misplaced the section in my previous
test. In ~30-40 minutes it should be ready and I'll report back.
Success!
I probably did something wrong before.
I'm attaching the patch against 19.07.3 and my device, but I think the
same should be done for trunk and other devices with a similar dts.
Signed-off-by: Luca Olivetti
Bye
--
Luca
diff --git a/target/linux/lantiq/files-4.14/arch/mips/boot/dts/ARV7518PW.dts b/target/linux/lantiq/files-4.14/arch/mips/boot/dts/ARV7518PW.dts
index 72f3a686b5..62b67d40eb 100644
--- a/target/linux/lantiq/files-4.14/arch/mips/boot/dts/ARV7518PW.dts
+++ b/target/linux/lantiq/files-4.14/arch/mips/boot/dts/ARV7518PW.dts
@@ -106,6 +106,18 @@
gpios = < 6 GPIO_ACTIVE_LOW>;
};
};
+
+ usb_vbus: regulator-usb-vbus {
+ compatible = "regulator-fixed";
+
+ regulator-name = "USB_VBUS";
+
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+
+ gpio = < 14 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
};
{
@@ -146,18 +158,6 @@
lantiq,open-drain = <1>;
};
};
-
- usb_vbus: regulator-usb-vbus {
- compatible = "regulator-fixed";
-
- regulator-name = "USB_VBUS";
-
- regulator-min-microvolt = <500>;
- regulator-max-microvolt = <500>;
-
- gpio = < 14 GPIO_ACTIVE_HIGH>;
- enable-active-high;
- };
};
{
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: fix for lantiq (danube) usb
El 5/7/20 a les 13:53, Martin Blumenstingl ha escrit: have you tried moving it out of the node (and placing it similar to what for example target/linux/lantiq/files-5.4/arch/mips/boot/dts/lantiq/vr9_bt_homehub-v5a.dts in master uses)? Yes, no change no change means the regulator-fixed driver is still not probed? Yes, it's not probed/available it's working fine for me on my BT Home Hub 5A, so I'm surprised to find that it's not working for you. Here's what I'm seeing: # find /proc/device-tree/ -name "regulator-usb-vbus" /proc/device-tree/regulator-usb-vbus # grep "regulator-usb-vbus" /sys/kernel/debug/gpio gpio-495 (|regulator-usb-vbus ) out hi I'm recompiling again in case I misplaced the section in my previous test. In ~30-40 minutes it should be ready and I'll report back. Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: fix for lantiq (danube) usb
El 5/7/20 a les 13:29, Martin Blumenstingl ha escrit:
Hi Luca,
On Sun, Jul 5, 2020 at 1:07 PM Luca Olivetti wrote:
[...]
I put a printk in every step of reg_fixed_regulator_probe
(drivers/regulator/fixed.c) and it seems it isn't called at all (my
strings are indeed compiled in fixed.o).
Why is that? Perhaps an error in the dts?
unfortunately you have only given an extract of your changes instead
of the full patch, which means I don't have much context and have to
guess
No, now I was talking about the original dts.
I checked and it seems the same as other devices in 19.07.3, the only
difference is the section (most devices have it in the first section
while here it is in the section) and the name after the colon
(most use no name at all after the colon or the same as before, i.e.
here it would be usb_vbus: usb_vbus ).
This is the definition in the dts
usb_vbus: regulator-usb-vbus {
compatible = "regulator-fixed";
regulator-name = "USB_VBUS";
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
gpio = < 14 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
assuming that board uses GPIO 14 with polarity "active high" this part
seems correct to me
have you tried moving it out of the node (and placing it similar
to what for example
target/linux/lantiq/files-5.4/arch/mips/boot/dts/lantiq/vr9_bt_homehub-v5a.dts
in master uses)?
Yes, no change
Bye
--
Luca
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: fix for lantiq (danube) usb
El 3/7/20 a les 23:18, Luca Olivetti ha escrit:
El 3/7/20 a les 19:49, John Crispin ha escrit:
On 03.07.20 19:47, Luca Olivetti wrote:
El 3/7/20 a les 19:37, John Crispin ha escrit:
Why not use the gpio regulator ?
Because I don't know how :-(
https://www.kernel.org/doc/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml
Oh, I see, but that's the one I had to *remove* because it didn't work.
Bye
CONFIG_REGULATOR_GPIO is not enabled in the kernel config
I think the correct one is CONFIG_REGULATOR_FIXED_VOLTAGE, which was
already in the configuration, hence adding CONFIG_REGULATOR_GPIO has no
effect.
I put a printk in every step of reg_fixed_regulator_probe
(drivers/regulator/fixed.c) and it seems it isn't called at all (my
strings are indeed compiled in fixed.o).
Why is that? Perhaps an error in the dts?
I checked and it seems the same as other devices in 19.07.3, the only
difference is the section (most devices have it in the first section
while here it is in the section) and the name after the colon
(most use no name at all after the colon or the same as before, i.e.
here it would be usb_vbus: usb_vbus ).
This is the definition in the dts
usb_vbus: regulator-usb-vbus {
compatible = "regulator-fixed";
regulator-name = "USB_VBUS";
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
gpio = < 14 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
Oh, and is there a quick way to test modifications to the dts? Every
time I invoke make, even for a trivial change, it takes 40 minutes.
Bye
--
Luca
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: fix for lantiq (danube) usb
El 3/7/20 a les 19:49, John Crispin ha escrit: On 03.07.20 19:47, Luca Olivetti wrote: El 3/7/20 a les 19:37, John Crispin ha escrit: Why not use the gpio regulator ? Because I don't know how :-( https://www.kernel.org/doc/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml Oh, I see, but that's the one I had to *remove* because it didn't work. Bye CONFIG_REGULATOR_GPIO is not enabled in the kernel config I think the correct one is CONFIG_REGULATOR_FIXED_VOLTAGE, which was already in the configuration, hence adding CONFIG_REGULATOR_GPIO has no effect. Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: fix for lantiq (danube) usb
El 3/7/20 a les 21:31, Luca Olivetti ha escrit:
I suppose it's the call to devm_regulator_get_optional, which should
lead to regulator/core.c
static struct regulator_dev *regulator_dev_lookup(struct device *dev,
const char *supply)
{
struct regulator_dev *r = NULL;
struct device_node *node;
struct regulator_map *map;
const char *devname = NULL;
regulator_supply_alias(, );
/* first do a dt based lookup */
if (dev && dev->of_node) {
node = of_get_regulator(dev, supply);
if (node) {
r = of_find_regulator_by_node(node);
if (r)
return r;
/*
* We have a node, but there is no device.
* assume it has not registered yet.
*/
I added a printk here and it's exactly as I supposed.
Now what?
return ERR_PTR(-EPROBE_DEFER);
}
}
Bye
--
Luca
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: fix for lantiq (danube) usb
El 3/7/20 a les 21:10, John Crispin ha escrit:
On 03.07.20 21:07, Luca Olivetti wrote:
El 3/7/20 a les 20:07, Luca Olivetti ha escrit:
El 3/7/20 a les 20:06, John Crispin ha escrit:
On 03.07.20 19:57, Luca Olivetti wrote:
El 3/7/20 a les 19:49, John Crispin ha escrit:
On 03.07.20 19:47, Luca Olivetti wrote:
El 3/7/20 a les 19:37, John Crispin ha escrit:
Why not use the gpio regulator ?
Because I don't know how :-(
https://www.kernel.org/doc/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml
Oh, I see, but that's the one I had to *remove* because it didn't
work.
Bye
CONFIG_REGULATOR_GPIO is not enabled in the kernel config
So it's just a matter of adding it to
target/linux/lantiq/xway/config-4.14 after
CONFIG_REGULATOR=y
CONFIG_REGULATOR_FIXED_VOLTAGE=y
?
(and put back the entry I removed in the dts)
Bye
correct
Thank you, I'm building it now (but my system is slow). I'll report
back if it works.
Nope, it doesn't
printk the driver with a salt shaker and see if it loads and if so where
it breaks
I'm not sure I understand, but I visually checked the code and the only
part where it could return -EPROBE_DEFER is here in dwc/hcd.c
static int dwc2_vbus_supply_init(struct dwc2_hsotg *hsotg)
{
int ret;
hsotg->vbus_supply = devm_regulator_get_optional(hsotg->dev,
"vbus");
if (IS_ERR(hsotg->vbus_supply)) {
ret = PTR_ERR(hsotg->vbus_supply);
hsotg->vbus_supply = NULL;
return ret == -ENODEV ? 0 : ret;
}
return regulator_enable(hsotg->vbus_supply);
}
I suppose it's the call to devm_regulator_get_optional, which should
lead to regulator/core.c
static struct regulator_dev *regulator_dev_lookup(struct device *dev,
const char *supply)
{
struct regulator_dev *r = NULL;
struct device_node *node;
struct regulator_map *map;
const char *devname = NULL;
regulator_supply_alias(, );
/* first do a dt based lookup */
if (dev && dev->of_node) {
node = of_get_regulator(dev, supply);
if (node) {
r = of_find_regulator_by_node(node);
if (r)
return r;
/*
* We have a node, but there is no device.
* assume it has not registered yet.
*/
return ERR_PTR(-EPROBE_DEFER);
}
}
But since I don't really understand what's happening here, I don't know
how to fix it.
I only know that if I remove the regulator from the dts the function
completes (since "node" is not found) and I can then enable the gpio
manually.
Bye
--
Luca
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: fix for lantiq (danube) usb
El 3/7/20 a les 20:07, Luca Olivetti ha escrit: El 3/7/20 a les 20:06, John Crispin ha escrit: On 03.07.20 19:57, Luca Olivetti wrote: El 3/7/20 a les 19:49, John Crispin ha escrit: On 03.07.20 19:47, Luca Olivetti wrote: El 3/7/20 a les 19:37, John Crispin ha escrit: Why not use the gpio regulator ? Because I don't know how :-( https://www.kernel.org/doc/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml Oh, I see, but that's the one I had to *remove* because it didn't work. Bye CONFIG_REGULATOR_GPIO is not enabled in the kernel config So it's just a matter of adding it to target/linux/lantiq/xway/config-4.14 after CONFIG_REGULATOR=y CONFIG_REGULATOR_FIXED_VOLTAGE=y ? (and put back the entry I removed in the dts) Bye correct Thank you, I'm building it now (but my system is slow). I'll report back if it works. Nope, it doesn't # dmesg | grep dwc2 [5.751540] dwc2 1e101000.usb: 1e101000.usb supply vusb_d not found, using dummy regulator [5.758454] dwc2 1e101000.usb: 1e101000.usb supply vusb_a not found, using dummy regulator [5.76] dwc2 1e101000.usb: dwc2_core_reset() HANG! Soft Reset GRSTCTL=8001 [5.912432] dwc2 1e101000.usb: DWC OTG Controller [5.915747] dwc2 1e101000.usb: new USB bus registered, assigned bus number 1 [5.922594] dwc2 1e101000.usb: irq 62, io mem 0x1e101000 [5.927811] dwc2 1e101000.usb: startup error -517 [5.932278] dwc2 1e101000.usb: USB bus 1 deregistered [5.937340] dwc2 1e101000.usb: dwc2_hcd_init() FAILED, returning -517 [ 50.308465] dwc2 1e101000.usb: 1e101000.usb supply vusb_d not found, using dummy regulator [ 50.315362] dwc2 1e101000.usb: 1e101000.usb supply vusb_a not found, using dummy regulator [ 50.360539] dwc2 1e101000.usb: DWC OTG Controller [ 50.363823] dwc2 1e101000.usb: new USB bus registered, assigned bus number 1 [ 50.370726] dwc2 1e101000.usb: irq 62, io mem 0x1e101000 [ 50.375988] dwc2 1e101000.usb: startup error -517 [ 50.380385] dwc2 1e101000.usb: USB bus 1 deregistered [ 50.385438] dwc2 1e101000.usb: dwc2_hcd_init() FAILED, returning -517 [ 50.457833] dwc2 1e101000.usb: 1e101000.usb supply vusb_d not found, using dummy regulator [ 50.464747] dwc2 1e101000.usb: 1e101000.usb supply vusb_a not found, using dummy regulator [ 50.472906] dwc2 1e101000.usb: dwc2_core_reset() HANG! Soft Reset GRSTCTL=8001 [ 50.632565] dwc2 1e101000.usb: DWC OTG Controller [ 50.635942] dwc2 1e101000.usb: new USB bus registered, assigned bus number 1 [ 50.642733] dwc2 1e101000.usb: irq 62, io mem 0x1e101000 [ 50.647992] dwc2 1e101000.usb: startup error -517 [ 50.652411] dwc2 1e101000.usb: USB bus 1 deregistered [ 50.657463] dwc2 1e101000.usb: dwc2_hcd_init() FAILED, returning -517 [ 50.767275] dwc2 1e101000.usb: 1e101000.usb supply vusb_d not found, using dummy regulator [ 50.774183] dwc2 1e101000.usb: 1e101000.usb supply vusb_a not found, using dummy regulator [ 50.782345] dwc2 1e101000.usb: dwc2_core_reset() HANG! Soft Reset GRSTCTL=8001 [ 51.098453] dwc2 1e101000.usb: DWC OTG Controller [ 51.101832] dwc2 1e101000.usb: new USB bus registered, assigned bus number 1 [ 51.108645] dwc2 1e101000.usb: irq 62, io mem 0x1e101000 [ 51.113845] dwc2 1e101000.usb: startup error -517 [ 51.118306] dwc2 1e101000.usb: USB bus 1 deregistered [ 51.123355] dwc2 1e101000.usb: dwc2_hcd_init() FAILED, returning -517 [ 86.412437] dwc2 1e101000.usb: 1e101000.usb supply vusb_d not found, using dummy regulator [ 86.419349] dwc2 1e101000.usb: 1e101000.usb supply vusb_a not found, using dummy regulator [ 86.427592] dwc2 1e101000.usb: dwc2_core_reset() HANG! Soft Reset GRSTCTL=8001 [ 86.620575] dwc2 1e101000.usb: DWC OTG Controller [ 86.623972] dwc2 1e101000.usb: new USB bus registered, assigned bus number 1 [ 86.630735] dwc2 1e101000.usb: irq 62, io mem 0x1e101000 [ 86.636020] dwc2 1e101000.usb: startup error -517 [ 86.640421] dwc2 1e101000.usb: USB bus 1 deregistered [ 86.645483] dwc2 1e101000.usb: dwc2_hcd_init() FAILED, returning -517 Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: fix for lantiq (danube) usb
El 3/7/20 a les 20:06, John Crispin ha escrit: On 03.07.20 19:57, Luca Olivetti wrote: El 3/7/20 a les 19:49, John Crispin ha escrit: On 03.07.20 19:47, Luca Olivetti wrote: El 3/7/20 a les 19:37, John Crispin ha escrit: Why not use the gpio regulator ? Because I don't know how :-( https://www.kernel.org/doc/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml Oh, I see, but that's the one I had to *remove* because it didn't work. Bye CONFIG_REGULATOR_GPIO is not enabled in the kernel config So it's just a matter of adding it to target/linux/lantiq/xway/config-4.14 after CONFIG_REGULATOR=y CONFIG_REGULATOR_FIXED_VOLTAGE=y ? (and put back the entry I removed in the dts) Bye correct Thank you, I'm building it now (but my system is slow). I'll report back if it works. Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: fix for lantiq (danube) usb
El 3/7/20 a les 19:49, John Crispin ha escrit: On 03.07.20 19:47, Luca Olivetti wrote: El 3/7/20 a les 19:37, John Crispin ha escrit: Why not use the gpio regulator ? Because I don't know how :-( https://www.kernel.org/doc/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml Oh, I see, but that's the one I had to *remove* because it didn't work. Bye CONFIG_REGULATOR_GPIO is not enabled in the kernel config So it's just a matter of adding it to target/linux/lantiq/xway/config-4.14 after CONFIG_REGULATOR=y CONFIG_REGULATOR_FIXED_VOLTAGE=y ? (and put back the entry I removed in the dts) Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: fix for lantiq (danube) usb
El 3/7/20 a les 19:37, John Crispin ha escrit: Why not use the gpio regulator ? Because I don't know how :-( https://www.kernel.org/doc/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml Oh, I see, but that's the one I had to *remove* because it didn't work. Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
fix for lantiq (danube) usb
Hello,
around 2 years ago, this patch
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=6eaf8b3d89571992a0aa7142cfab3f1dcef3c802#patch7
broke the usb on my arv7518pw: when it tries to power up the usb it
returns error -537 (EPROBE_DEFER, see
https://bugs.openwrt.org/index.php?do=details_id=1634).
[ 5.431505] dwc2 1e101000.usb: 1e101000.usb supply vusb_d not found,
using dummy regulator
[ 5.438418] dwc2 1e101000.usb: 1e101000.usb supply vusb_a not found,
using dummy regulator
[ 5.446581] dwc2 1e101000.usb: dwc2_core_reset() HANG! Soft Reset
GRSTCTL=8001
[ 5.593255] dwc2 1e101000.usb: DWC OTG Controller
[ 5.596565] dwc2 1e101000.usb: new USB bus registered, assigned bus number 1
[ 5.603417] dwc2 1e101000.usb: irq 62, io mem 0x1e101000
[ 5.608632] dwc2 1e101000.usb: startup error -517
[ 5.613124] dwc2 1e101000.usb: USB bus 1 deregistered
[ 5.618080] dwc2 1e101000.usb: dwc2_hcd_init() FAILED, returning -517
If I revert the above patch, the usb initializes correctly, but there's
no 5V on the port so it doesn't work.
I hacked a fake led on gpio 14 so I can turn on the 5V from user space,
and the usb works (I tried with a memory stick and an rt73 wifi stick,
an rtl8812au doesn't work but I think because its driver is ... meh).
What's the proper way to turn on the 5V on gpio 14 (i.e. fix the
-EPROBE_DEFER error)?
I suppose that the issue also affects other danube based devices, but I
can only test the one I have.
This is against 19.07.3
--- a/target/linux/lantiq/files-4.14/arch/mips/boot/dts/ARV7518PW.dts
+++ b/target/linux/lantiq/files-4.14/arch/mips/boot/dts/ARV7518PW.dts
@@ -105,6 +105,10 @@
label = "arv7518pw:red:wps";
gpios = < 6 GPIO_ACTIVE_LOW>;
};
+ usbpw {
+ label = "arv7518pw:green:usbpw";
+ gpios = < 14 GPIO_ACTIVE_HIGH>;
+ };
};
};
@@ -147,17 +151,6 @@
};
};
- usb_vbus: regulator-usb-vbus {
- compatible = "regulator-fixed";
-
- regulator-name = "USB_VBUS";
-
- regulator-min-microvolt = <500>;
- regulator-max-microvolt = <500>;
-
- gpio = < 14 GPIO_ACTIVE_HIGH>;
- enable-active-high;
- };
};
{
@@ -232,7 +225,6 @@
{
status = "okay";
- vbus-supply = <_vbus>;
};
{
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] ath9k_htc: Target is unresponsive
This is the message I get when I plug a tp-link tl-wn722n (which is working fine both in an ubuntu desktop and on a mageia laptop): [ 547.804000] usb 1-1: new high-speed USB device number 5 using ifxusb_hcd [ 548.02] usb 1-1: ath9k_htc: Firmware htc_9271.fw requested [ 549.296000] usb 1-1: ath9k_htc: Transferred FW: htc_9271.fw, size: 50980 [ 550.304000] ath9k_htc 1-1:1.0: ath9k_htc: Target is unresponsive [ 550.308000] ath9k_htc: Failed to initialize the device Just to exclude a problem with the usb port, I tried with an rt73 based stick I have and it works fine. I have a different firmware on my desktop system, I tried it but the result is the same. This is with openwrt trunk on an astoria arv7518pw (lantiq xway) $ git log -1 commit eaa347ab30256a87be70c13d876b76fe64ab7755 Author: jogo jogo@3c298f89-4303-0410-b956-a3cf2f4a3e73 Date: Fri May 22 22:51:37 2015 + arm64: enable new errata backported to 3.18 3.18.13 introduced a bunch of new errata, enable them to be on the safe side. Signed-off-by: Jonas Gorski j...@openwrt.org git-svn-id: svn://svn.openwrt.org/openwrt/trunk@45715 3c298f89-4303-0410-b956-a3cf2f4a3e73 # opkg list-installed | grep ath9k kmod-ath9k - 3.18.14+2015-03-09-3 kmod-ath9k-common - 3.18.14+2015-03-09-3 kmod-ath9k-htc - 3.18.14+2015-03-09-3 Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath9k_htc: Target is unresponsive
El 25/05/15 a les 17:27, Bruno Randolf ha escrit: On 05/25/2015 03:38 PM, Luca Olivetti wrote: This is the message I get when I plug a tp-link tl-wn722n (which is working fine both in an ubuntu desktop and on a mageia laptop): [ 547.804000] usb 1-1: new high-speed USB device number 5 using ifxusb_hcd [ 548.02] usb 1-1: ath9k_htc: Firmware htc_9271.fw requested [ 549.296000] usb 1-1: ath9k_htc: Transferred FW: htc_9271.fw, size: 50980 [ 550.304000] ath9k_htc 1-1:1.0: ath9k_htc: Target is unresponsive [ 550.308000] ath9k_htc: Failed to initialize the device Just to exclude a problem with the usb port, I tried with an rt73 based stick I have and it works fine. I have a different firmware on my desktop system, I tried it but the result is the same. This is with openwrt trunk on an astoria arv7518pw (lantiq xway) Maybe a problem with the USB power supply. Can you try with a powered USB hub? Yes, I thought so, but I don't have a powered usb hub :-/ Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath9k_htc: Target is unresponsive
El 25/05/15 a les 17:59, Luca Olivetti ha escrit: El 25/05/15 a les 17:27, Bruno Randolf ha escrit: On 05/25/2015 03:38 PM, Luca Olivetti wrote: This is the message I get when I plug a tp-link tl-wn722n (which is working fine both in an ubuntu desktop and on a mageia laptop): [ 547.804000] usb 1-1: new high-speed USB device number 5 using ifxusb_hcd [ 548.02] usb 1-1: ath9k_htc: Firmware htc_9271.fw requested [ 549.296000] usb 1-1: ath9k_htc: Transferred FW: htc_9271.fw, size: 50980 [ 550.304000] ath9k_htc 1-1:1.0: ath9k_htc: Target is unresponsive [ 550.308000] ath9k_htc: Failed to initialize the device Just to exclude a problem with the usb port, I tried with an rt73 based stick I have and it works fine. I have a different firmware on my desktop system, I tried it but the result is the same. This is with openwrt trunk on an astoria arv7518pw (lantiq xway) Maybe a problem with the USB power supply. Can you try with a powered USB hub? Yes, I thought so, but I don't have a powered usb hub :-/ Well, I'm not sure it's just a power problem: I tried an usb memory stick that declares 500mA consumption, and I get this: [ 144.512000] scsi 1:0:0:0: Direct-Access Freecom DATABAR 1.00 PQ: 0 ANSI: 2 [ 144.524000] sd 1:0:0:0: [sda] 7829504 512-byte logical blocks: (4.00 GB/3.73 GiB) [ 144.712000] usb 1-1: reset high-speed USB device number 3 using ifxusb_hcd [ some more resets] [ 146.772000] sd 1:0:0:0: [sda] Write Protect is off [ 146.776000] sd 1:0:0:0: [sda] Mode Sense: 03 00 00 00 [ 146.952000] usb 1-1: reset high-speed USB device number 3 using ifxusb_hcd [ some more resets] [ 149.02] sd 1:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 149.204000] usb 1-1: reset high-speed USB device number 3 using ifxusb_hcd [ some more resets] [ etc. ] no problems with a stick that declares a 200mA consumption. That would seem to corroborate the power problem *but* if I flash barrier breaker the same 500mA memory stick works just fine. The wifi stick still doesn't work though: [ 552.516000] usb 1-1: new high-speed USB device number 4 using ifxusb_hcd [ 552.74] usb 1-1: ath9k_htc: Firmware htc_9271.fw requested [ 553.112000] usb 1-1: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272 [ 554.416000] usb 1-1: Service connection timeout for: 256 [ 554.42] ath9k_htc 1-1:1.0: ath9k_htc: Unable to initialize HTC services [ 554.424000] ath9k_htc: Failed to initialize the device [ 554.432000] usb 1-1: ath9k_htc: USB layer deinitialized So I suspect that it's a combination of power *and* a regression in the ifxusb_hcd driver. Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath9k_htc: Target is unresponsive
El 25/05/15 a les 18:57, Caleb James DeLisle ha escrit: I've seen a similar issue with the toshiba wlm20u2 where it says it's transferring htc_9271.fw but that's actually the wrong fw so the device crashes, the solution for me was to specify the device as AR9280_USB in the ath9k_hif_usb_ids struct as per the following: https://github.com/cjdelisle/athdrvrs/blob/master/ath9k/hif_usb.c#L59 No, htc_9721.fw is the correct one for this device (at least it is both on the laptop and the desktop). Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] mediatek mt7601u?
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/ralink.sh I think that was for a project targeting MT7260 SoC's before the mac80211 driver was extended to support them. Thank you. No, this driver just uses wireless extensions, i.e., this is what it says in the README I updated my package with a /lib/wifi/wext.sh adapted from an old revision of mac80211.sh (back when it still used ifconfig). It works with uci but luci still has some problems (since it has some hardcoded defaults it only offers wpa authentication for mac80211, atheros or prism2). Oh, and it seems it doesn't work at all if I leave it enabled at boot time, but if I disable it in /etc/config/wireless and bring it up after a while it works. Anyway, here it is: https://code.google.com/p/mt7601-openwrt/ Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] mediatek mt7601u?
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 targeting MT7260 SoC's before the mac80211 driver was extended to support them. Thank you. No, this driver just uses wireless extensions, i.e., this is what it says in the README ** Build for being controlled by NetworkManager or wpa_supplicant wext functions Please set 'HAS_WPA_SUPPLICANT=y' and 'HAS_NATIVE_WPA_SUPPLICANT_SUPPORT=y'. = #cd wpa_supplicant-x.x = #./wpa_supplicant -Dwext -ira0 -c wpa_supplicant.conf -d And in fact it works just fine on the laptop with NetworkManager It can also be configured to use the ralink driver, but it doesn't support the same iwpriv options as the above script (for starters it only works in STA mode), at least from a quick glance at it ** Build for being controlled by WpaSupplicant with Ralink Driver Please set 'HAS_WPA_SUPPLICANT=y' and 'HAS_NATIVE_WPA_SUPPLICANT_SUPPORT=n'. = #cd wpa_supplicant-0.5.7 = #./wpa_supplicant -Dralink -ira0 -c wpa_supplicant.conf -d Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] mediatek mt7601u?
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), but then it doesn't recognize the received frames and eventually the router reboots. I suspect that the driver hasn't been tested with RT_BIG_ENDIAN (in fact it hadn't even been compiled, since one of the structures was missing a ;) but it's too big a mess for me to follow. I think found the issue: one bitpacked structure had to be reversed (I don't understand why is it necessary since all bitpacked struct have two symmetric definitions, one for big endian and the other for little endian, but since the code did it for all other structures I tried to do it for this one as well). Now the interface starts correctly, I can scan for access points with iwlist and associate to an open one with iwconfig (didn't test anything more). The problem is that, while the interface shows up in the luci interface, I have can see no scan result and when I configure the essid and a wpa passphrase it doesn't associate. Does luci only work with interfaces that support iw (this one doesn't)? Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] mediatek mt7601u?
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). I'm almost sure it's an endianness issue. In the laptop dmesg I see MAC[Ver:Rev=0x76010500] while in the router MAC[Ver:Rev=0x00050176] 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), but then it doesn't recognize the received frames and eventually the router reboots. I suspect that the driver hasn't been tested with RT_BIG_ENDIAN (in fact it hadn't even been compiled, since one of the structures was missing a ;) but it's too big a mess for me to follow. Maybe I should ask on the linux-wireless list? Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] mediatek mt7601u?
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 http://www.mediatek.com/en/downloads/mt7601u-usb/ (it's actually 3.0.0.4, not 3.0.0.2) http://www.arnelborja.com/compiling-rt2870-wifi-driver-in-fedora/ http://www.spinics.net/lists/linux-wireless/msg126291.html 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 suppose that nobody tried this chipset with openwrt (at least google doesn't think so), but there's no harm in asking, right? Oh, the router usb port it's fine, at least it works with another usb wifi adapter (rt73). TIA -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] mediatek mt7601u?
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 with the supplied driver and a couple of patches http://www.mediatek.com/en/downloads/mt7601u-usb/ (it's actually 3.0.0.4, not 3.0.0.2) http://www.arnelborja.com/compiling-rt2870-wifi-driver-in-fedora/ http://www.spinics.net/lists/linux-wireless/msg126291.html 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 put it here https://code.google.com/p/mt7601-openwrt/source/browse/ Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] mediatek mt7601u?
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. In the laptop dmesg I see MAC[Ver:Rev=0x76010500] while in the router MAC[Ver:Rev=0x00050176] Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] voip package for the infineon danube (sip client using the FXS ports)
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 accounts, use uci instead of libconfig, simplified the operation, etc. If somebody would like to test it, the result is here: http://code.google.com/p/danube-voip/ And now I finally managed to add a luci interface to it. Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] voip package for the infineon danube (sip client using the FXS ports)
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 feel better to know the license when merging these packages. Mmh, libab comes from the original midge distribution (of course with my changes to adapt it to this router), and the license files are missing even there. Now the midge repository is on github (the original repository doesn't exist anymore) here https://github.com/ZigFisher/Midge/tree/master/package/oem-voip/files/src and libab has no explicit license, however the whole midge distribution it's licensed under the GPL version 2 http://flyrouter.net/doku.php#copyright Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] voip package for the infineon danube (sip client using the FXS ports)
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 or add a LICENSE file or similar ? i would feel better to know the license when merging these packages. Mmh, libab comes from the original midge distribution (of course with my changes to adapt it to this router), and the license files are missing even there. Now the midge repository is on github (the original repository doesn't exist anymore) here https://github.com/ZigFisher/Midge/tree/master/package/oem-voip/files/src and libab has no explicit license, however the whole midge distribution it's licensed under the GPL version 2 http://flyrouter.net/doku.php#copyright Also, flyrouter.net links to this page: http://zftlab.org/pages/2014070600.html where it says midge linux gpl sources on github, linking to the above repository. Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] lantiq: ath_pci_fixup cannot work since it's called before ath9k_eeprom_probe
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 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 wireless adapter doesn't work. What can I change to revert the order of those calls? (i'm lost in the 75 levels of indirection, I had it working 3 years ago but then the levels of indirection where only 63 ;-) Found the solution, change the call from late_initcall(of_ath9k_eeprom_init) to subsys_initcall(of_ath9k_eeprom_init). Now I have to see why it doesn't get the mac address and the regdomain from the eeprom (things, again, that I had working but it seems this platform is an easy target for being broken again and again). Bye ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel this is wrong. the eeprom needs to be probed after spi. I don't know if it's right or wrong, I *do* know that this way it works, with late_initcall it doesn't. I see that before revision 36778 (probably the one that broke it) it was arch_initcall. What I'm sure about is that the eeprom must be probed *before* pci fixup (re-read the first message that explains the problem). Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] lantiq: ath_pci_fixup cannot work since it's called before ath9k_eeprom_probe
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 wireless adapter doesn't work. What can I change to revert the order of those calls? (i'm lost in the 75 levels of indirection, I had it working 3 years ago but then the levels of indirection where only 63 ;-) Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] lantiq: ath_pci_fixup cannot work since it's called before ath9k_eeprom_probe
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.
The net result is that the fixup isn't done and the wireless adapter
doesn't work.
What can I change to revert the order of those calls? (i'm lost in the
75 levels of indirection, I had it working 3 years ago but then the
levels of indirection where only 63 ;-)
Found the solution, change the call from
late_initcall(of_ath9k_eeprom_init)
to
subsys_initcall(of_ath9k_eeprom_init).
Now I have to see why it doesn't get the mac address and the regdomain
from the eeprom (things, again, that I had working but it seems this
platform is an easy target for being broken again and again).
Bye
--
Luca
Index: target/linux/lantiq/patches-3.8/0037-owrt-lantiq-wifi-and-ethernet-eeprom-handling.patch
===
--- target/linux/lantiq/patches-3.8/0037-owrt-lantiq-wifi-and-ethernet-eeprom-handling.patch (revisión: 37909)
+++ target/linux/lantiq/patches-3.8/0037-owrt-lantiq-wifi-and-ethernet-eeprom-handling.patch (copia de trabajo)
@@ -202,7 +202,7 @@
+{
+ return platform_driver_probe(ath9k_eeprom_driver, of_ath9k_eeprom_probe);
+}
-+late_initcall(of_ath9k_eeprom_init);
++subsys_initcall(of_ath9k_eeprom_init);
+
+
+static int ath5k_pci_plat_dev_init(struct pci_dev *dev)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] lantiq - fix p2601hnfx leds
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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] lantiq + ath9k: what to expect?
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 to ~2. Is this normal? With the original firmware transfer speeds of 6Mib were possible very limited testing at the beginning of the year gave me 25Mbps, while I previously got only 5Mbps: http://patchwork.openwrt.org/patch/1798/ Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] lantiq cumulative patch
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://patchwork.openwrt.org/patch/1798/ And to credit me instead of someone else. Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] lantiq cumulative 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 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 can accept as is into owrt Can or can't? Bye cannot And now, a year later, after constantly ignoring my patches that made the modification to the regdomain optional (with a command line switch), you go and check in a patch that does exactly what you said wasn't acceptable. Unbelievable. I'm still waiting for you to revert such an unacceptable commit. Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] lantiq cumulative patch
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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] lantiq cumulative patch
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 rewrites the eep on the fly upon a read and fakes a ES reg. this is the patch we can accept as is into owrt Can or can't? Bye cannot And now, a year later, after constantly ignoring my patches that made the modification to the regdomain optional (with a command line switch), you go and check in a patch that does exactly what you said wasn't acceptable. Unbelievable. Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] uboot-lantiq, add arv7518PW board
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...@ventoso.org --- Index: files/include/configs/arv7518PW.h === --- files/include/configs/arv7518PW.h (revisión: 0) +++ files/include/configs/arv7518PW.h (revisión: 0) @@ -0,0 +1,16 @@ +#ifndef __CONFIG_H_7518 +#define __CONFIG_H_7518 + +#define CONFIG_ARV7518 1 +#define CONFIG_ARCADYANARV7518PW + +#define CONFIG_SYS_MAX_RAM 64*1024*1024 +#define CONFIG_USE_DDR_PSC_64 1 +#defineCONFIG_SYS_PROMPT ARV7518 = + +//#define CONFIG_RMII 1 +#define CONFIG_AR8216_SWITCH 1 + +#include arcadyan-common.h + +#endif Cambios de propiedades en files/include/configs/arv7518PW.h ___ Añadido: svn:eol-style + native Index: Makefile === --- Makefile(revisión: 29891) +++ Makefile(copia de trabajo) @@ -76,6 +76,9 @@ Package/uboot-lantiq-arv752DPW22_flash=$(call Package/uboot-lantiq-template,arv752DPW22_flash,NOR) Package/uboot-lantiq-arv752DPW22_ramboot=$(call Package/uboot-lantiq-template,arv752DPW22_ramboot,RAM) Package/uboot-lantiq-arv752DPW22_brnboot=$(call Package/uboot-lantiq-template,arv752DPW22_brnboot,BRN) +Package/uboot-lantiq-arv7518PW_flash=$(call Package/uboot-lantiq-template,arv7518PW_flash,NOR) +Package/uboot-lantiq-arv7518PW_ramboot=$(call Package/uboot-lantiq-template,arv7518PW_ramboot,RAM) +Package/uboot-lantiq-arv7518PW_brnboot=$(call Package/uboot-lantiq-template,arv7518PW_brnboot,BRN) DDR_CONFIG_arv3527P_ramboot:=arcadyan_psc166_32 DDR_CONFIG_arv4518PW_ramboot:=arcadyan_psc166_64 @@ -85,6 +88,7 @@ DDR_CONFIG_arv452CPW_ramboot:=arcadyan_psc166_32 DDR_CONFIG_arv752DPW_ramboot:=arcadyan_psc166_64 DDR_CONFIG_arv752DPW22_ramboot:=arcadyan_psc166_64 +DDR_CONFIG_arv7518PW_ramboot:=arcadyan_psc166_64 define Build/Prepare $(PKG_UNPACK) @@ -173,4 +177,7 @@ $(eval $(call BuildPackage,uboot-lantiq-arv752DPW22_flash)) $(eval $(call BuildPackage,uboot-lantiq-arv752DPW22_brnboot)) $(eval $(call BuildPackage,uboot-lantiq-arv752DPW22_ramboot)) +$(eval $(call BuildPackage,uboot-lantiq-arv7518PW_flash)) +$(eval $(call BuildPackage,uboot-lantiq-arv7518PW_brnboot)) +$(eval $(call BuildPackage,uboot-lantiq-arv7518PW_ramboot)) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] uboot-lantiq, add arv7518PW board
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 in the arv752DPW22 is this piece of code: #ifdef CONFIG_SWITCH_PORT0 *DANUBE_GPIO_P0_ALTSEL0 = ~(1CONFIG_SWITCH_PIN); *DANUBE_GPIO_P0_ALTSEL1 = ~(1CONFIG_SWITCH_PIN); *DANUBE_GPIO_P0_OD |= (1CONFIG_SWITCH_PIN); *DANUBE_GPIO_P0_DIR |= (1CONFIG_SWITCH_PIN); *DANUBE_GPIO_P0_OUT |= (1CONFIG_SWITCH_PIN); #elif defined(CONFIG_SWITCH_PORT1) *DANUBE_GPIO_P1_ALTSEL0 = ~(1CONFIG_SWITCH_PIN); *DANUBE_GPIO_P1_ALTSEL1 = ~(1CONFIG_SWITCH_PIN); *DANUBE_GPIO_P1_OD |= (1CONFIG_SWITCH_PIN); *DANUBE_GPIO_P1_DIR |= (1CONFIG_SWITCH_PIN); *DANUBE_GPIO_P1_OUT |= (1CONFIG_SWITCH_PIN); #endif (since arv752DPW22 defines CONFIG_SWITCH_PORT1). I don't know if that's what's causing problems with the network, anyway having a prompt corresponding to the board is neater ;-) Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] uboot-lantiq, add arv7518PW board
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 but the network doesn't work. ;-) It didn't work for me, but a user on the forum says it works for him :-/ OTOH another user says that the arv752DPW22 uboot doesn't work on his Easybox 802A is arv752DPW 803 is arv752DPW22 https://forum.openwrt.org/viewtopic.php?pid=160991#p160991 Luca please inform blogic about my mistake. It is Easybox 803A. Thanx! Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Issue including AR8316 (AR8216) support in RT3052 build
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 arch/mips/include/asm/mach-ralink but can't find anything Probably files/drivers/net/ramips.c, it uses netif_rx instead of netif_receive_skb Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Issue including AR8316 (AR8216) support in RT3052 build
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 external devices. Any assistance would be greatly appreciated. If the AR8316 is like the AR8216 (they use the same driver), it adds vlan headers to incoming packets, and the ethernet driver needs to be patched like this: https://dev.openwrt.org/browser/trunk/target/linux/lantiq/patches/200-owrt-netif_receive_skb.patch Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Frequent reboot WBMR Lantiq
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 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 most likely a error your end hints appreciated Bye most likely you activated it in kernel_menuconfig and not menuconfig Thank you, I don't remember how I activated it at the time, but I'll try now with menuconfig. I tried and I had the exact same crash, then I tried with a make dirclean before make, and it doesn't crash now. Is there a way to avoid rebuilding everything? Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Frequent reboot WBMR Lantiq
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 second one is the Oops! So is the problem the eth0: tx ring full?? I've seen this too once on a different lantiq router, adsl was not connected, I was just running iperf to test the throughput of the wifi adapter. Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Frequent reboot WBMR Lantiq
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 openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Frequent reboot WBMR Lantiq
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 now? Last time I tried it, it didn't work, but it was a while ago http://pastebin.ca/2072861 most likely a error your end hints appreciated Bye most likely you activated it in kernel_menuconfig and not menuconfig Thank you, I don't remember how I activated it at the time, but I'll try now with menuconfig. Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ARM-Based Hardware with analog phone ports
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 for this information says he's working for a large telco, somehow I don't think he'll have any problems getting the TAPI documentation if they're going to do a product with Lantiq hardware. That's true, in that case the documentation is outstanding The fact that there is no _open_ documentation available (yet) does not make it unusable I know, I managed to add various features to an existing program using TAPI, but it wasn't easy, almost impossible if I had to start from scratchand couldn't find documentation on some chines site ;-) Last time I checked the Linux kernel is full of badly documented features ;-) and of many source files were the only comment is the GPL notice ;-) Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ARM-Based Hardware with analog phone ports
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 of date (the driver complains it's too old) and it crashes, and there's no publicly available documentation (though one can manage to find some outdated documentation in unofficial sites). Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ARM-Based Hardware with analog phone ports
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 could not find how owsip implements caller id, could you point me to the file where it does it, so I can check what it does differently wrt svd? TIA -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ARM-Based Hardware with analog phone ports
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. inside owsip this crash does not happen Hello, I could not find how owsip implements caller id, could you point me to the file where it does it, so I can check what it does differently wrt svd? Ok, found it, the difference is that you only use IFX_TAPI_CID_ST_CLI and I also use IFX_TAPI_CID_ST_NAME (one or both, depending on what's available). Could you try with both and see if it crashes? I also plan to use IFX_TAPI_CID_ST_DATE, since some handset use it to set the internal clock. Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ARM-Based Hardware with analog phone ports
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 day. Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Low level boot on MIPS CPUs
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 https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] lantiq: how do I generate an uImage?
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 the conflicting files with instead of keeping the old one, hence I was expecting an error during the build. Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] lantiq: add ath9k support to the arv7518
The following patch adds ath9k support to the arv7518 board.
It supersedes
http://patchwork.openwrt.org/patch/849/
http://patchwork.openwrt.org/patch/1169/
(there are no modifications in the code but the patch bitrotted since then).
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-3.2/arch/mips/ath79/pci-ath9k-fixup.c
https://dev.openwrt.org/browser/trunk/target/linux/ar71xx/files-3.2/arch/mips/ath79/pci-ath9k-fixup.h
with a couple of changes (removed the switch on the soc, added a cpu_to_le32
in the call to __raw_writel).
As I said, the ar9223 has no onboard eeprom, so it uses the system
flash, which holds the fixup data as well as the calibration data,
however the regdomain in the system flash is set at 0, and it will
setup the card to the most restrictive mode (i.e. channels 12 and
13 aren't available).
The original firmware overrides the regdomain and the device capabilities
(I suppose that arcadyan uses the same caldata all over the world and then
customizes the firmware instead of properly set the regdomain).
The 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.
It also modifies ath9k in mac80211 to unconditionally check (and fix) the
endianness of the emulated eeprom.
To be on the safe side this modification (the last hunk of the patch) should be
applied only for this device (I don't think it should cause any harm anyway)
but I don't know how to do it.
While at the time of the previous patches I only got 5Mbps, now I get 25Mbps
with no encryption and 23Mbps 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...@ventoso.org
---
Index: target/linux/lantiq/image/Makefile
===
--- target/linux/lantiq/image/Makefile (revisión: 29937)
+++ target/linux/lantiq/image/Makefile (copia de trabajo)
@@ -10,7 +10,7 @@
JFFS2_BLOCKSIZE = 64k 128k 256k
ase_cmdline=-console=ttyLTQ0,115200 rootfstype=squashfs,jffs2
-xway_cmdline=-console=ttyLTQ1,115200 rootfstype=squashfs,jffs2
+xway_cmdline=console=ttyLTQ1,115200 rootfstype=squashfs,jffs2
falcon_cmdline=-console=ttyLTQ0,115200 rootfstype=squashfs,jffs2
define CompressLzma
Index: target/linux/lantiq/patches/750-arv75xx-ath9k.patch
===
--- target/linux/lantiq/patches/750-arv75xx-ath9k.patch (revisión: 0)
+++ target/linux/lantiq/patches/750-arv75xx-ath9k.patch (revisión: 0)
@@ -0,0 +1,28 @@
+--- a/arch/mips/lantiq/xway/Kconfig
b/arch/mips/lantiq/xway/Kconfig
+@@ -8,6 +8,7 @@ config LANTIQ_MACH_EASY50712
+
+ config LANTIQ_MACH_ARV45XX
+ bool ARV45XX
++ select LANTIQ_PCI_ATH9K_FIXUP
+ default y
+
+ config LANTIQ_MACH_NETGEAR
+@@ -24,6 +25,9 @@ config LANTIQ_MACH_WBMR
+
+ endmenu
+
++config LANTIQ_PCI_ATH9K_FIXUP
++ def_bool n
++
+ endif
+
+ if SOC_AMAZON_SE
+--- a/arch/mips/lantiq/xway/Makefile
b/arch/mips/lantiq/xway/Makefile
+@@ -12,4 +12,5 @@ obj-$(CONFIG_LANTIQ_MACH_FRITZ3370) += m
+ obj-$(CONFIG_LANTIQ_MACH_ARV45XX) += mach-arv45xx.o
+ obj-$(CONFIG_LANTIQ_MACH_NETGEAR) += mach-netgear.o
+ obj-$(CONFIG_LANTIQ_MACH_GIGASX76X) += mach-gigasx76x.o
++obj-$(CONFIG_LANTIQ_PCI_ATH9K_FIXUP) += pci-ath9k-fixup.o
+ obj-$(CONFIG_LANTIQ_MACH_WBMR) += mach-wbmr.o
Index: target/linux/lantiq/files-3.1/arch/mips/lantiq/xway/pci-ath9k-fixup.c
===
--- target/linux/lantiq/files-3.1/arch/mips/lantiq/xway/pci-ath9k-fixup.c
(revisión: 0)
+++ target/linux/lantiq/files-3.1/arch/mips/lantiq/xway/pci-ath9k-fixup.c
(revisión: 0)
@@ -0,0 +1,105 @@
+/*
+ * Adapted from: Atheros AP94 reference board PCI initialization
+ *
+ * Copyright (C) 2009-2010 Gabor Juhos juh...@openwrt.org
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include linux/pci.h
+#include linux/delay.h
+
+/* this is ugly but this constant isn't available in an header file */
+#define LTQ_PCI_MEM_BASE 0x1800
+
+struct ath9k_fixup {
+ u16 *cal_data;
+ unsignedslot;
+};
+
+static int ath9k_num_fixups;
+static struct ath9k_fixup ath9k_fixups[2];
+
+static void ath9k_pci_fixup(struct pci_dev *dev)
+{
+ void __iomem *mem;
+ u16 *cal_data = NULL;
+ u16 cmd;
+ u32 bar0;
+ u32 val;
+ unsigned i
Re: [OpenWrt-Devel] [PATCH] lantiq: add ath9k support to the arv7518
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 would disappear until an rmmod and insmod of ath9k (either at boot or invoking wifi). I could see nothing in dmesg. Once modified /etc/config/wireless with the correct name, wlan0 no longer disappeared. Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] lantiq: add ath9k support to the arv7518
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. The radio0 name is an internal identifer, it does not relate to any interface. Your appearing/disappearing wlan0 is merely a coincidence, it has nothing to do with the naming of the wireless configuration. With that configuration, wlan0 would disappear until an rmmod and insmod of ath9k (either at boot or invoking wifi). Which is actually the intended behavior. There should be no wlanX as long as the driver is unconfigured. You are right, the problem wasn't the name but the option disabled 1 and since I modified both at once I thought the name was to blame. I didn't expect option disabled 1 to make the device completely disappear from ifconfig/iwconfig, I just thought it would let it in the down state. Anyway, everything is OK then, thank you. Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] lantiq: how do I generate an uImage?
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 today build (linux-lantiq_danube) contains only vmlinux and vmlinux.elf After the svn update I did a make dirclean and a make oldconfig. The image is configured as an initramfs: I used to tftpboot the uImage-ARV7518PW for testing. I also checked under bin but I can only find u-boot and the packages there. How do I generate an uImage now? Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] lantiq: how do I generate an uImage?
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 build_dir/linux-lantiq_danube/uImage-ARV7525PW-jffs2-128k build_dir/linux-lantiq_danube/uImage-ARV752DPW22-jffs2-128k build_dir/linux-lantiq_danube/uImage-ARV7525PW-jffs2-256k build_dir/linux-lantiq_danube/uImage-ARV752DPW22-jffs2-256k build_dir/linux-lantiq_danube/uImage-ARV7525PW-jffs2-64k build_dir/linux-lantiq_danube/uImage-ARV752DPW22-jffs2-64k They're not there, just vmlinux and vmlinux.elf Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] lantiq: how do I generate an uImage?
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-lantiq_danube/uImage-ARV752DPW22 build_dir/linux-lantiq_danube/uImage-ARV7525PW-jffs2-128k build_dir/linux-lantiq_danube/uImage-ARV752DPW22-jffs2-128k build_dir/linux-lantiq_danube/uImage-ARV7525PW-jffs2-256k build_dir/linux-lantiq_danube/uImage-ARV752DPW22-jffs2-256k build_dir/linux-lantiq_danube/uImage-ARV7525PW-jffs2-64k build_dir/linux-lantiq_danube/uImage-ARV752DPW22-jffs2-64k They're not there, just vmlinux and vmlinux.elf 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 -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 2/2] mac80211: add pci ids to ath5k
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, since I had (and still have) no clue on what to do. It seems than the ifxmips branch has a saner architecture for 3.x kernels (files instead of patches), so I'll see if I can adapt that old patch and check if things have improved. Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] lantiq: add ath9k support to the arv7518
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 the performance issue). The main thing that bothers me is why I had to do the endianness check and had to use cpu_to_le32, while the ar71xx platform needs neither of those (and, according to the config, should work with the same endianness as the lantiq platform). I hope you can shed some light on these issues. Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] lantiq: add ath9k support to the arv7518
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 of the ath9k patch on chipsets with onboard eeprom. With flash emulation the patch works as-is(apart the performance issue). The main thing that bothers me is why I had to do the endianness check and had to use cpu_to_le32, while the ar71xx platform needs neither of those (and, according to the config, should work with the same endianness as the lantiq platform). I hope you can shed some light on these issues. Bye never looked at how ar71xx does it. The pci fixup is taken straight from the ar71xx (however I had to use cpu_to_le32 while the ar71xx code writes the data directly without conversion). The caldata in flash should be the same (however I had to patch ath9k to change the endianness). From the stock firmware bootlog I see that the stock firmware did the both things (fixup and endianness). Note also how it changes country code on the fly: Autoconfig PCI channel 0x8062A99C Scanning bus 00, I/O 0x1ae0:0x1b01, Mem 0x1800:0x1a01 00:0e.0 Class 0200: 168c:ff1d (rev 01) Mem at 0x1800 [size=0x1] Scanning bus 00 Found 00:70 [168c/ff1d] 000200 00 Fixups for bus 00 Bus scan for 00 returning with max=00 ff1d168c 2b6 201 8000 1800000 000 ee1c168c0 400 100 [HWLAN] ifno=2 irno=7 port=0x [PCI] devtag=0070 probe=800e4ab8 pci_find_slot bus 0 devfn 70 dev-bus-number 0 dev-devfn 70 pci_find_slot bus 0 devfn 70 dev-bus-number 0 dev-devfn 70 # We detect Merlin (PCI) without EEPROM # pci_find_slot bus 0 devfn 70 dev-bus-number 0 dev-devfn 70 pci_find_slot bus 0 devfn 70 dev-bus-number 0 dev-devfn 70 pci_find_slot bus 0 devfn 70 dev-bus-number 0 dev-devfn 70 [HWLAN] devtag = 0070 [HWLAN] Vendor ID 0x168c [HWLAN] Device ID 0x29 [HWLAN] Base Addr 0xb800 [HWLAN] SVendor ID 0x168c [HWLAN] SDevice ID 0xee1c [HWLAN] Revision ID 0x1 [HWLAN] interrupt vector 0x1 ath_pci_probe : pdev=0x80d7497c PCI_CACHE_LINE_SIZE : 8 after PCI_LATENCYTIMER pcibios_set_master lat=0x80 pci_read_config_dword( dev_id, 0x40 ) return 32896 ath_pci_probe : dev-name wifi0 T_WIFI_INT=26 dev=0x810d2a48 dev-priv=0x81f74d20 call ath_attach 1 : dev 810d2a48 name 810d32ec wifi0 ATH_INIT_TQUEUE() : 800fb3f4 ??? ATH_INIT_TQUEUE() : 8010645c ??? ATH_INIT_TQUEUE() : 8010d850 ??? ATH_INIT_TQUEUE() : 800f6314 ??? ATH_INIT_TQUEUE() : 800f9a80 ??? ATH_INIT_TQUEUE() : 800fb3f4 ??? ATH_INIT_TQUEUE() : 800f6264 ??? ATH_INIT_TQUEUE() : 800f65e4 ??? ahp-ah_iniModes[23]: 0x986c 0x06903081 0x06903081 0x0a193881 0x0a193881 0x06903881 EEPROM : EEP_MAP_DEFAULT ! Powertable magic: a55a ar5416CheckEepromDef: Read Magic = 0xA55A need_swap = True. EEPROM Endianness is not native.. Changing regDmn[0] 0 regDmn[1] 1f change it to 1f1f [HWLAN] Set HWLAN MAC as LAN MAC .. ath_getchannels nchan=22 ath_getchannels nchan=22 ath_getchannels nchan=22 match:9 Chan Freq RegPwr HT CTL CTL_U CTL_L DFS 1 2412n 20 HT20 101 N 2 2417n 20 HT20 101 N 3 2422n 20 HT40 101 N 4 2427n 20 HT40 101 N 5 2432n 20 HT40 111 N 6 2437n 20 HT40 111 N 7 2442n 20 HT40 111 N 8 2447n 20 HT40 111 N 9 2452n 20 HT40 111 N 10 2457n 20 HT40 110 N 11 2462n 20 HT40 110 N 12 2467n 20 HT20 110 N 13 2472n 20 HT20 110 N ath_countrycode : 724 ATH_INIT_TQUEUE() : 800f56a0 ??? ATH_INIT_TQUEUE() : 800f56a0 ??? ATH_INIT_TQUEUE() : 800f56a0 ??? what bothers me however is the performance issue. Maybe it's related to the above issues? Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] lantiq: add ath9k support to the arv7518
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 been answered ? no it has not...
...I made the question 3 months ago, and I don't want to wait 3 more
months to raise it again.
so until that is resolved we cant add the patch.
as you may have noticed i have been pushing lots of patches the last few
days and am still in the middle of it ...
so, if you have more insight into the
+- if (!ath9k_hw_use_flash(ah)) {
++ if (1) {
issue let me know.
otherwise you need to wait until i verified it
Just wanted to know if you or somebody else is going to check it or
should I forget about it. If the latter, I won't ask more questions.
Bye
--
Luca
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Orion doesn't build anymore
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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] lantiq: add ath9k support to the arv7518
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:42.0 +0100
b/drivers/net/wireless/ath/ath9k/eeprom_def.c 2011-02-20
17:51:47.0 +0100 +@@ -147,7 +152,7 @@
+ return false;
+ }
+
+-if (!ath9k_hw_use_flash(ah)) {
++if (1) {
This looks wrong.
Why?
See http://patchwork.openwrt.org/patch/849/ for the previous discussion.
Bye
because it will break devices which dont have the eeprom inside the flash
Are you sure?
Mind me, I could be wrong, but looking at eeprom.c:
int ath9k_hw_eeprom_init(struct ath_hw *ah)
{
int status;
if (AR_SREV_9300_20_OR_LATER(ah))
ah-eep_ops = eep_ar9300_ops;
else if (AR_SREV_9287(ah)) {
ah-eep_ops = eep_ar9287_ops;
} else if (AR_SREV_9285(ah) || AR_SREV_9271(ah)) {
ah-eep_ops = eep_4k_ops;
} else {
ah-eep_ops = eep_def_ops;
}
if (!ah-eep_ops-fill_eeprom(ah))
return -EIO;
status = ah-eep_ops-check_eeprom(ah);
return status;
}
So when it reaches check_eeprom (where the endianness check is done),
it has already called fill_eeprom, which copies the data in ram,
so it shouldn't matter if the device has an onboard eeprom or uses the flash
to
emulate it.
Felix said that the endianness check should be done unconditionally, maybe
he knows better.
So, what's the final decision?
Should I forget about ath9k support on this board?
Bye
--
Luca
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] lantiq: add ath9k support to the arv7518
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 no onboard
eeprom) is taken from the ar71xx:
https://dev.openwrt.org/browser/trunk/target/linux/ar71xx/files/arch/mips/ar71xx/pci-ath9k-fixup.c
https://dev.openwrt.org/browser/trunk/target/linux/ar71xx/files/arch/mips/ar71xx/pci-ath9k-fixup.h
with a couple of changes.
As I said, the ar9223 has no onboard eeprom, so it uses the system
flash, which holds the fixup data as well as the calibration data,
however the regdomain in the system flash is set at 0, and it will
setup the card to the most restrictive mode (i.e. channels 12 and
13 aren't available).
The original firmware overrides the regdomain and the device capabilities
(I suppose that arcadyan uses the same caldata all over the world and then
customizes the firmware instead of properly set the regdomain).
The 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.
Here's a revised version of the patch against current trunk.
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).
The current patch now includes the modification to ath9k, without an extra field
(endianness is checked unconditionally).
At the risk of being called impatient, I'd like some feedback
(and some help in fixing the performance issues I encountered).
The performance problem is still there (I get ~5Mbps) but I'm not asking for
help, since I already know I won't get any.
Signed-off-by: Luca Olivetti l...@ventoso.org
---
Index: target/linux/lantiq/image/Makefile
===
--- target/linux/lantiq/image/Makefile (revisión: 27363)
+++ target/linux/lantiq/image/Makefile (copia de trabajo)
@@ -10,7 +10,7 @@
JFFS2_BLOCKSIZE = 64k 128k 256k
ase_cmdline=-console=ttyLTQ1,115200 rootfstype=squashfs,jffs2
-xway_cmdline=-console=ttyLTQ1,115200 rootfstype=squashfs,jffs2
+xway_cmdline=console=ttyLTQ1,115200 rootfstype=squashfs,jffs2
falcon_cmdline=-console=ttyLTQ0,115200 rootfstype=squashfs,jffs2
define CompressLzma
Index: target/linux/lantiq/patches-2.6.39/750-arv75xx-ath9k.patch
===
--- target/linux/lantiq/patches-2.6.39/750-arv75xx-ath9k.patch (revisión: 0)
+++ target/linux/lantiq/patches-2.6.39/750-arv75xx-ath9k.patch (revisión: 0)
@@ -0,0 +1,266 @@
+--- a/arch/mips/lantiq/xway/Kconfig
b/arch/mips/lantiq/xway/Kconfig
+@@ -8,6 +8,7 @@ config LANTIQ_MACH_EASY50712
+
+ config LANTIQ_MACH_ARV45XX
+ bool ARV45XX
++ select LANTIQ_PCI_ATH9K_FIXUP
+ default y
+
+ config LANTIQ_MACH_NETGEAR
+@@ -20,6 +21,9 @@ config LANTIQ_MACH_GIGASX76X
+
+ endmenu
+
++config LANTIQ_PCI_ATH9K_FIXUP
++ def_bool n
++
+ endif
+
+ if SOC_AMAZON_SE
+--- a/arch/mips/lantiq/xway/Makefile
b/arch/mips/lantiq/xway/Makefile
+@@ -8,4 +8,5 @@ obj-$(CONFIG_LANTIQ_MACH_EASY50601) += m
+ obj-$(CONFIG_LANTIQ_MACH_ARV45XX) += mach-arv45xx.o
+ obj-$(CONFIG_LANTIQ_MACH_NETGEAR) += mach-netgear.o
+ obj-$(CONFIG_LANTIQ_MACH_GIGASX76X) += mach-gigasx76x.o
++obj-$(CONFIG_LANTIQ_PCI_ATH9K_FIXUP) += pci-ath9k-fixup.o
+ obj-y += dev-dwc_otg.o
+--- /dev/null
b/arch/mips/lantiq/xway/pci-ath9k-fixup.c
+@@ -0,0 +1,105 @@
++/*
++ * Adapted from: Atheros AP94 reference board PCI initialization
++ *
++ * Copyright (C) 2009-2010 Gabor Juhos juh...@openwrt.org
++ *
++ * This program is free software; you can redistribute it and/or modify it
++ * under the terms of the GNU General Public License version 2 as published
++ * by the Free Software Foundation.
++ */
++
++#include linux/pci.h
++#include linux/delay.h
++
++/* this is ugly but this constant isn't available in an header file */
++#define LTQ_PCI_MEM_BASE 0x1800
++
++struct ath9k_fixup {
++ u16 *cal_data;
++ unsignedslot;
++};
++
++static int ath9k_num_fixups;
++static struct ath9k_fixup ath9k_fixups[2];
++
++static void ath9k_pci_fixup(struct pci_dev *dev)
++{
++ void __iomem *mem;
++ u16 *cal_data = NULL;
++ u16 cmd;
++ u32 bar0;
++ u32 val;
++ unsigned i;
++
++ for (i = 0; i ath9k_num_fixups; i++) {
++ if (ath9k_fixups[i].cal_data == NULL)
++ continue;
++
++ if (ath9k_fixups[i].slot != PCI_SLOT(dev-devfn))
++ continue;
++
++ cal_data = ath9k_fixups[i].cal_data;
++ break;
++ }
++
++ if (cal_data == NULL
Re: [OpenWrt-Devel] [PATCH] lantiq: add ath9k support to the arv7518
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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] lantiq: add ath9k support to the arv7518
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 @@
+return false;
+}
+
+- if (!ath9k_hw_use_flash(ah)) {
++ if (1) {
This looks wrong.
Why?
See http://patchwork.openwrt.org/patch/849/ for the previous discussion.
Bye
--
Luca
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] lantiq_etop.c: use netif_receive_skb provided by the ar8216 driver
The following patch uses netif_receive_skb (if present) from the phy driver.
When used with an ar8216, it will fix incoming packets in case vlan
mode is enabled (the ar8216 driver already intercepts outgoing packets).
Other switches currently used by the lantiq platform (adm6996 and rtl8306)
don'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 Olivetti l...@ventoso.org
---
Index:
target/linux/lantiq/patches-2.6.39/0011-MIPS-Lantiq-Add-ethernet-driver.patch
===
---
target/linux/lantiq/patches-2.6.39/0011-MIPS-Lantiq-Add-ethernet-driver.patch
(revisión: 27363)
+++
target/linux/lantiq/patches-2.6.39/0011-MIPS-Lantiq-Add-ethernet-driver.patch
(copia de trabajo)
@@ -126,7 +126,7 @@
--- /dev/null
+++ b/drivers/net/lantiq_etop.c
-@@ -0,0 +1,813 @@
+@@ -0,0 +1,817 @@
+/*
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
@@ -284,8 +284,12 @@
+
+ skb_put(skb, len);
+ skb-dev = ch-netdev;
-+ skb-protocol = eth_type_trans(skb, ch-netdev);
-+ netif_receive_skb(skb);
++ if (priv-phydev priv-phydev-netif_receive_skb) {
++ priv-phydev-netif_receive_skb(skb);
++ } else {
++ skb-protocol = eth_type_trans(skb, ch-netdev);
++ netif_receive_skb(skb);
++ }
+}
+
+static int
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] lantiq: add ath9k support to the arv7518
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/eeprom_def.c 2011-02-20
17:51:47.0 +0100 +@@ -147,7 +152,7 @@
+ return false;
+ }
+
+- if (!ath9k_hw_use_flash(ah)) {
++ if (1) {
This looks wrong.
Why?
See http://patchwork.openwrt.org/patch/849/ for the previous discussion.
Bye
because it will break devices which dont have the eeprom inside the flash
Are you sure?
Mind me, I could be wrong, but looking at eeprom.c:
int ath9k_hw_eeprom_init(struct ath_hw *ah)
{
int status;
if (AR_SREV_9300_20_OR_LATER(ah))
ah-eep_ops = eep_ar9300_ops;
else if (AR_SREV_9287(ah)) {
ah-eep_ops = eep_ar9287_ops;
} else if (AR_SREV_9285(ah) || AR_SREV_9271(ah)) {
ah-eep_ops = eep_4k_ops;
} else {
ah-eep_ops = eep_def_ops;
}
if (!ah-eep_ops-fill_eeprom(ah))
return -EIO;
status = ah-eep_ops-check_eeprom(ah);
return status;
}
So when it reaches check_eeprom (where the endianness check is done),
it has already called fill_eeprom, which copies the data in ram,
so it shouldn't matter if the device has an onboard eeprom or uses the flash to
emulate it.
Felix said that the endianness check should be done unconditionally, maybe
he knows better.
Bye
--
Luca
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] lantiq_etop.c: use netif_receive_skb provided by the ar8216 driver
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://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] lantiq: add ath9k support to the arv7518
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/pci-ath9k-fixup.c https://dev.openwrt.org/browser/trunk/target/linux/ar71xx/files/arch/mips/ar71xx/pci-ath9k-fixup.h with a couple of changes. As I said, the ar9223 has no onboard eeprom, so it uses the system flash, which holds the fixup data as well as the calibration data, however the regdomain in the system flash is set at 0, and it will setup the card to the most restrictive mode (i.e. channels 12 and 13 aren't available). The original firmware overrides the regdomain and the device capabilities (I suppose that arcadyan uses the same caldata all over the world and then customizes the firmware instead of properly set the regdomain). The 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. 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). At the risk of being called impatient, I'd like some feedback (and some help in fixing the performance issues I encountered). Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Gigaset SX763
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 original fw, they just added that pci id to madwifi drivers, will see after I manage to get wlan up how to fix that. Ah, ok, maybe that's the correct approach then. In my original firmware (that's not Linux), the id changes automagically from ff1d to 0029 (according to the bootlog), then I found the code in ar71xx to do the fixup. It's possible that there's no such possibility with ath5k. Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Gigaset SX763
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 be the data starting at offset 0x7a in your file (0xa5,0x5a), but I could be wrong (I have a chipset using ath9k, so I didn't look at how ath5k works). Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Gigaset SX763
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 special hex value which represents that? It should be the data starting at offset 0x7a in your file (0xa5,0x5a), but I could be wrong (I have a chipset using ath9k, so I didn't look at how ath5k works). I see that you also had to change the pci id table to recognize your wifi chip. 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? See https://dev.openwrt.org/browser/trunk/target/linux/ar71xx/files/arch/mips/ar71xx/pci-ath9k-fixup.c https://dev.openwrt.org/browser/trunk/target/linux/ar71xx/files/arch/mips/ar71xx/pci-ath9k-fixup.h and how I adapted it to the danube (again, for ath9k, not ath5k) http://patchwork.midlink.org/patch/849/ Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Gigaset SX763
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 how to locate it inside my binary, is there any special hex value which represents that? It should be the data starting at offset 0x7a in your file (0xa5,0x5a), but I could be wrong (I have a chipset using ath9k, so I didn't look at how ath5k works). I see that you also had to change the pci id table to recognize your wifi chip. 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? 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 Unfortunately I have no idea what you should do with that data See https://dev.openwrt.org/browser/trunk/target/linux/ar71xx/files/arch/mips/ar71xx/pci-ath9k-fixup.c https://dev.openwrt.org/browser/trunk/target/linux/ar71xx/files/arch/mips/ar71xx/pci-ath9k-fixup.h and how I adapted it to the danube (again, for ath9k, not ath5k) http://patchwork.midlink.org/patch/849/ Bye ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Gigaset SX763
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 note the pci subsystem 0x2051, and there's a couple of 0x51, 0x20 in your file. Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Gigaset SX763
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 as the kernel calls lq_register_gpio_ebu (contrary to leds controlled by real gpio, they're lit at power on, the original firmware turns them off very soon). 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 module? (and how since the trigger comes from user space)? Open the gpio directly? (again, how?) Some other way? TIA -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Gigaset SX763
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 module? (and how since the trigger comes from user
space)?
Open the gpio directly? (again, how?)
Some other way?
TIA
Hi luca,
if it is a gpio
cd /sys/class/gpio
echo 13 export
echo out gpio13/direction
echo 0/1 gpio13/brightness
for a led in userland echo default-on /sys/class/leds/led name/trigger
or in kernel space use the default trigger as shown in this patch
https://lists.openwrt.org/pipermail/openwrt-devel/2008-January/001618.html
also look at /etc/init.d/led it allows you to setup your leds based on
a uci file
so ideally you give your leds a default brightness / trigger in the
kernel code and then setup the others in userland via uci depending on
which works best / makes sense for the specific case
Well, none of the above ;-)
For almost all the leds there's already a suitable trigger module (be it
network activity, usb, heartbeat, etc., so it's just a matter of enabling it
like you said above, but there are some leds that I'd like to control from
a C application (specifically fxs1, fxs2 and voip),
so I'd like to know if there's an api for it, or I just open, e.g.,
/sys/class/leds/soc:green:fxs1/trigger, and fprintf default-on to turn it
on and none to turn it off (i.e., like the above shell commands but from C).
I just wanted to know if is there a more elegant way.
Note that those 3 leds are controlled by the ebu driver, and I assigned them
to the gpio_led structure, i.e.:
static struct gpio_led
arv7518pw_leds_gpio[] __initdata = {
{ .name = soc:green:power, .gpio = 2, .active_low = 1, },
{ .name = soc:green:adsl, .gpio = 4, .active_low = 1, },
{ .name = soc:green:internet, .gpio = 5, .active_low = 1, },
{ .name = soc:green:wlan, .gpio = 6, .active_low = 1, },
{ .name = soc:red:internet, .gpio = 8, .active_low = 1, },
{ .name = soc:green:usb, .gpio = 19, .active_low = 1, },
{ .name = soc:green:voip, .gpio = 32, .active_low = 1, },
{ .name = soc:green:fxs1, .gpio = 33, .active_low = 1, },
{ .name = soc:green:fxs2, .gpio = 34, .active_low = 1, },
/* no fxo on this board but the led is there, unlabeled */
{ .name = soc:red:fxo, .gpio = 35, .active_low = 1, },
{ .name = soc:yellow:wps, .gpio = 36, .active_low = 1, },
{ .name = soc:red:wps, .gpio = 38, .active_low = 1, },
};
so I'm not sure I can use the /sys/class/gpio method
(the echo xxx /sys/class/leds/yyy/trigger method works, that's how it tested
from userspace).
Bye
--
Luca
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Gigaset SX763
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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Gigaset SX763
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 addition a CS line is toggled. this allows you to use a 8-16bit latch to latch out the data. a common chip used for this is 74*373 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 -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Gigaset SX763
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 work around this, we pass a default value that gets applied. for example if oyu have a 8 bit latch XYZ-0x80 would result in 1 pin high and 7 low ... 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 as the kernel calls lq_register_gpio_ebu (contrary to leds controlled by real gpio, they're lit at power on, the original firmware turns them off very soon). Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Gigaset SX763
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 the call to xway_register_dwc (mach-arv45xx.c). Also this board doesn't have wlan eeprom, instead it is read by a wlan driver from a file inside fw. If someone has some answers on how to modify current ath5k driver, would like to know. The code in mach-arv45xx.c (arv45xx_register_ath5k) should already take care of that. Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] lantiq: add ath9k support to the arv7518
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 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). I think we should make the endian check unconditional in ath9k. No need to add another field to ath9k_platform.h Well, I cannot say, I just wanted to avoid to breaking working devices. Which I probably did (since I didn't patch, e.g., ar71xx, to add the field) :( Well, what's the final decision? The new field or the unconditional check? (And why atheros made it conditional in the first place?). Also, I checked and the endianness of the various ar71xx devices using ath9k should be the same as mine, so I don't understand why it works on those devices (does it?) and it doesn't on mine. Note that, in the fixup code, the same magic as the ar71xx (0xa55a) works, while I had to change __raw_writel(val, mem + reg); to __raw_writel(cpu_to_le32(val), mem + reg); I'm quite confused. Next we can discuss the performance problem (maybe the root cause is the same, e.g. I'm doing something stupid without realizing). No decision yet? Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] trivial questions about packages
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, they will just be compiled but not installed. If the latter, did you define both a Build/InstallDev (it can be empty and a Package/yourpackage/install section in the makefile? Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] voip package for the infineon danube (sip client using the FXS ports)
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 the operation, etc. If somebody would like to test it, the result is here: http://code.google.com/p/danube-voip/ Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] ucimap doesn't allow an empty string as a parameter?
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_add(struct uci_map *map, void *section)
{
struct uci_test *a = section;
if (a-test) {
/* option present */
do_something();
} else {
/* option absent */
do_something_else();
}
return 0;
}
static struct uci_optmap test_uci_map[] =
{
{
UCIMAP_OPTION(struct uci_test, test),
.type = UCIMAP_STRING,
.name = test,
}
};
static struct uci_sectionmap test_sectionmap = {
UCIMAP_SECTION(struct uci_test, map),
.type = testsection,
.init = test_init,
.add = test_add,
.options = test_uci_map,
.n_options = ARRAY_SIZE(test_uci_map),
.options_size = sizeof(struct uci_optmap),
};
However it seem I cannot distinguish if the option was absent or it was
an empty string (i.e., in both cases a-test is NULL) and I need to
treat both cases differently.
Is there a way to do it?
Bye
--
Luca
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ucimap doesn't allow an empty string as a parameter?
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;
};
static int
test_init(struct uci_map *map, void *section, struct uci_section *s)
{
return 0;
}
static int
test_add(struct uci_map *map, void *section)
{
struct uci_test *a = section;
if (a-test) {
/* option present */
do_something();
} else {
/* option absent */
do_something_else();
}
return 0;
}
static struct uci_optmap test_uci_map[] =
{
{
UCIMAP_OPTION(struct uci_test, test),
.type = UCIMAP_STRING,
.name = test,
}
};
static struct uci_sectionmap test_sectionmap = {
UCIMAP_SECTION(struct uci_test, map),
.type = testsection,
.init = test_init,
.add = test_add,
.options = test_uci_map,
.n_options = ARRAY_SIZE(test_uci_map),
.options_size = sizeof(struct uci_optmap),
};
However it seem I cannot distinguish if the option was absent or it was
an empty string (i.e., in both cases a-test is NULL) and I need to
treat both cases differently.
Is there a way to do it?
Bye
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] lantiq: add ath9k support to the arv7518
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 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). I think we should make the endian check unconditional in ath9k. No need to add another field to ath9k_platform.h Well, I cannot say, I just wanted to avoid to breaking working devices. Which I probably did (since I didn't patch, e.g., ar71xx, to add the field) :( Well, what's the final decision? The new field or the unconditional check? (And why atheros made it conditional in the first place?). Also, I checked and the endianness of the various ar71xx devices using ath9k should be the same as mine, so I don't understand why it works on those devices (does it?) and it doesn't on mine. Note that, in the fixup code, the same magic as the ar71xx (0xa55a) works, while I had to change __raw_writel(val, mem + reg); to __raw_writel(cpu_to_le32(val), mem + reg); I'm quite confused. Next we can discuss the performance problem (maybe the root cause is the same, e.g. I'm doing something stupid without realizing). Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] lantiq: add ath9k support to the arv7518
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/pci-ath9k-fixup.c
https://dev.openwrt.org/browser/trunk/target/linux/ar71xx/files/arch/mips/ar71xx/pci-ath9k-fixup.h
with a couple of changes.
As I said, the ar9223 has no onboard eeprom, so it uses the system
flash, which holds the fixup data as well as the calibration data,
however the regdomain in the system flash is set at 0, and it will
setup the card to the most restrictive mode (i.e. channels 12 and
13 aren't available).
The original firmware overrides the regdomain and the device capabilities
(I suppose that arcadyan uses the same caldata all over the world and then
customizes the firmware instead of properly set the regdomain).
The 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 l...@ventoso.org
---
Index: target/linux/lantiq/image/Makefile
===
--- target/linux/lantiq/image/Makefile (revisión: 26437)
+++ target/linux/lantiq/image/Makefile (copia de trabajo)
@@ -9,7 +9,7 @@
JFFS2_BLOCKSIZE = 64k 128k 256k
-xway_cmdline=-console=ttyS1,115200 rootfstype=squashfs,jffs2
+xway_cmdline=console=ttyS1,115200 rootfstype=squashfs,jffs2
falcon_cmdline=-console=ttyS0,115200 rootfstype=squashfs,jffs2
define CompressLzma
Index: target/linux/lantiq/patches/750-arv75xx-ath9k.patch
===
--- target/linux/lantiq/patches/750-arv75xx-ath9k.patch (revisión: 0)
+++ target/linux/lantiq/patches/750-arv75xx-ath9k.patch (revisión: 0)
@@ -0,0 +1,257 @@
+--- a/arch/mips/lantiq/xway/Kconfig
b/arch/mips/lantiq/xway/Kconfig
+@@ -16,8 +16,12 @@ config LANTIQ_MACH_EASY4010
+
+ config LANTIQ_MACH_ARV45XX
+ bool ARV45XX
++ select LANTIQ_PCI_ATH9K_FIXUP
+ default y
+
+ endmenu
+
++config LANTIQ_PCI_ATH9K_FIXUP
++ def_bool n
++
+ endif
+--- a/arch/mips/lantiq/xway/Makefile
b/arch/mips/lantiq/xway/Makefile
+@@ -4,4 +4,5 @@ obj-$(CONFIG_LANTIQ_MACH_EASY50812) += m
+ obj-$(CONFIG_LANTIQ_MACH_EASY50712) += mach-easy50712.o
+ obj-$(CONFIG_LANTIQ_MACH_EASY4010) += mach-easy4010.o
+ obj-$(CONFIG_LANTIQ_MACH_ARV45XX) += mach-arv45xx.o
++obj-$(CONFIG_LANTIQ_PCI_ATH9K_FIXUP) += pci-ath9k-fixup.o
+ obj-y += dev-dwc_otg.o
+--- /dev/null
b/arch/mips/lantiq/xway/pci-ath9k-fixup.c
+@@ -0,0 +1,105 @@
++/*
++ * Adapted from: Atheros AP94 reference board PCI initialization
++ *
++ * Copyright (C) 2009-2010 Gabor Juhos juh...@openwrt.org
++ *
++ * This program is free software; you can redistribute it and/or modify it
++ * under the terms of the GNU General Public License version 2 as published
++ * by the Free Software Foundation.
++ */
++
++#include linux/pci.h
++#include linux/delay.h
++
++/* this is ugly but this constant isn't available in an header file */
++#define LQ_PCI_MEM_BASE 0x1800
++
++struct ath9k_fixup {
++ u16 *cal_data;
++ unsignedslot;
++};
++
++static int ath9k_num_fixups;
++static struct ath9k_fixup ath9k_fixups[2];
++
++static void ath9k_pci_fixup(struct pci_dev *dev)
++{
++ void __iomem *mem;
++ u16 *cal_data = NULL;
++ u16 cmd;
++ u32 bar0;
++ u32 val;
++ unsigned i;
++
++ for (i = 0; i ath9k_num_fixups; i++) {
++ if (ath9k_fixups[i].cal_data == NULL)
++ continue;
++
++ if (ath9k_fixups[i].slot != PCI_SLOT(dev-devfn))
++ continue;
++
++ cal_data = ath9k_fixups[i].cal_data;
++ break;
++ }
++
++ if (cal_data == NULL)
++ return;
++
++ if (*cal_data != 0xa55a) {
++ pr_err(pci %s: invalid calibration data\n, pci_name(dev));
++ return;
++ }
++
++ pr_info(pci %s: fixup device configuration\n, pci_name(dev));
++
++ mem = ioremap(LQ_PCI_MEM_BASE, 0x1);
++ if (!mem) {
++ pr_err(pci %s: ioremap error\n, pci_name(dev));
++ return;
++ }
++
++ pci_read_config_dword(dev, PCI_BASE_ADDRESS_0, bar0);
++ pci_write_config_dword(dev, PCI_BASE_ADDRESS_0, LQ_PCI_MEM_BASE);
++ pci_read_config_word(dev, PCI_COMMAND, cmd);
++ cmd |= PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY;
++ pci_write_config_word(dev, PCI_COMMAND, cmd);
++
++ /* set pointer to first reg address */
++ cal_data += 3;
++ while (*cal_data != 0x) {
++ u32 reg;
++ reg = *cal_data++;
++ val = *cal_data++;
++ val |= (*cal_data++) 16;
++
++ __raw_writel(cpu_to_le32(val), mem
Re: [OpenWrt-Devel] [PATCH] lantiq: add ath9k support to the arv7518
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). ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] lantiq: add ath9k support to the arv7518
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/patch/727/ without it, initialization of the card would fail (no other harm should be done). I think we should make the endian check unconditional in ath9k. No need to add another field to ath9k_platform.h Well, I cannot say, I just wanted to avoid to breaking working devices. Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] lantiq: add ath9k support to the arv7518
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 this patch in mac80211 http://patchwork.midlink.org/patch/727/ without it, initialization of the card would fail (no other harm should be done). I think we should make the endian check unconditional in ath9k. No need to add another field to ath9k_platform.h Well, I cannot say, I just wanted to avoid to breaking working devices. Which I probably did (since I didn't patch, e.g., ar71xx, to add the field) :( Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ltq-vmmc, fix voice coefficients installation
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 === --- package/ltq-vmmc/Makefile (revisión: 26437) +++ package/ltq-vmmc/Makefile (copia de trabajo) @@ -74,6 +74,7 @@ FW_FILE=fw_voip_danube-12.1.0.1.0.tar.gz FW_MD5SUM:=51868b88dee9dbc65d3dbba355ded91c FW_DOWNLOAD:=1 + COEF_SRC:=danube_bbd_fxs.bin COEF_TARGET:=danube_bbd_fxs.bin COEF_FILE:=coef_voip_danube-0.9.0.tar.gz COEF_MD5SUM:=c8ac6592b304b03829a8123560e15710 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] lantiq cumulative patch
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 from the ar71xx architecture (which has also other features that lantiq should borrow, like, e.g., the same /etc/config/network is not suitable for every profile). But then, I'm not an openwrt developer, so what should I know? Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] lantiq cumulative patch
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 rewrites the eep on the fly upon a read and fakes a ES reg. this is the patch we can accept as is into owrt Can or can't? Bye cannot Would 0x67 be acceptable? Bye -- Luca ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] lantiq cumulative 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 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 can accept as is into owrt
Can or can't?
Bye
cannot
Would 0x67 be acceptable?
What regdomain is programmed into the EEPROM by default?
It is set at 0. The original firmware (which isn't Linux but it seems it's
using a version of ath9k) overrides ir too.
See this extract from the bootlog:
EEPROM : EEP_MAP_DEFAULT !
Powertable magic: a55a
ar5416CheckEepromDef: Read Magic = 0xA55A
need_swap = True.
EEPROM Endianness is not native.. Changing
regDmn[0] 0
regDmn[1] 1f
change it to 1f1f
[HWLAN] Set HWLAN MAC as LAN MAC ..
ath_getchannels nchan=22
ath_getchannels nchan=22
ath_getchannels nchan=22 match:9
Chan Freq RegPwr HT CTL CTL_U CTL_L DFS
1 2412n 20 HT20 101 N
2 2417n 20 HT20 101 N
3 2422n 20 HT40 101 N
4 2427n 20 HT40 101 N
5 2432n 20 HT40 111 N
6 2437n 20 HT40 111 N
7 2442n 20 HT40 111 N
8 2447n 20 HT40 111 N
9 2452n 20 HT40 111 N
10 2457n 20 HT40 110 N
11 2462n 20 HT40 110 N
12 2467n 20 HT20 110 N
13 2472n 20 HT20 110 N
ath_countrycode : 724
And what does the driver do with it if you leave out the override?
It will set a default world regdomain (the most restrictive):
static const struct ieee80211_regdomain *ath_default_world_regdomain(void)
{
/* this is the most restrictive */
return ath_world_regdom_64;
}
static const struct
ieee80211_regdomain *ath_world_regdomain(struct ath_regulatory *reg)
{
switch (reg-regpair-regDmnEnum) {
case 0x60:
case 0x61:
case 0x62:
return ath_world_regdom_60_61_62;
case 0x63:
case 0x65:
return ath_world_regdom_63_65;
case 0x64:
return ath_world_regdom_64;
case 0x66:
case 0x69:
return ath_world_regdom_66_69;
case 0x67:
case 0x68:
case 0x6A:
return ath_world_regdom_67_68_6A;
default:
WARN_ON(1);
return ath_default_world_regdomain();
}
}
But I was asking if it's not acceptable to set the regdomain to Spain or
if it's not acceptable to change it at all.
Bye
--
Luca
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
