Re: [OpenWrt-Devel] [PATCH 1/4] ar71xx: add option to wake up phys on mdio reset
2013.12.17. 1:12 keltezéssel, Felix Kaechele írta:
The bootloader on the WD My Net N750 disables the ports on it's internal
AR8327N switch by powering them down. The stock firmware then brings the
ports back up again by starting the auto negotiation process on each
port.
There is one big disadvantage of this approach: In tests I noticed that
PHYs on this platform that are powered down can be written but not read.
As a result the scan on the mdio bus fails to detect the ports on the
switch.
This workaround adds an option to the mdio bus platform data that
enables toggling of an early reset of all available PHYs before the mdio
bus scan is performed. On the test platform this brings the PHYs back to
life in time to be detected by the mdio bus scan.
Signed-off-by: Felix Kaechele hef...@fedoraproject.org
---
.../linux/ar71xx/files/arch/mips/ath79/dev-eth.c | 4 +--
.../linux/ar71xx/files/arch/mips/ath79/dev-eth.h | 2 ++
.../mips/include/asm/mach-ath79/ag71xx_platform.h | 1 +
.../net/ethernet/atheros/ag71xx/ag71xx_mdio.c | 30
++
4 files changed, 24 insertions(+), 13 deletions(-)
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/dev-eth.c
b/target/linux/ar71xx/files/arch/mips/ath79/dev-eth.c
index 4a2b1db..742218b 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/dev-eth.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/dev-eth.c
@@ -39,7 +39,7 @@ static struct resource ath79_mdio0_resources[] = {
}
};
-static struct ag71xx_mdio_platform_data ath79_mdio0_data;
+struct ag71xx_mdio_platform_data ath79_mdio0_data;
struct platform_device ath79_mdio0_device = {
.name = ag71xx-mdio,
@@ -60,7 +60,7 @@ static struct resource ath79_mdio1_resources[] = {
}
};
-static struct ag71xx_mdio_platform_data ath79_mdio1_data;
+struct ag71xx_mdio_platform_data ath79_mdio1_data;
Making the ath79_mdio[01]_data visible is not strictly related to the patch. I
would do it in a separate change ...
struct platform_device ath79_mdio1_device = {
.name = ag71xx-mdio,
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/dev-eth.h
b/target/linux/ar71xx/files/arch/mips/ath79/dev-eth.h
index bc608da..08a59ef 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/dev-eth.h
+++ b/target/linux/ar71xx/files/arch/mips/ath79/dev-eth.h
@@ -39,6 +39,8 @@ void ath79_register_eth(unsigned int id);
extern struct ag71xx_switch_platform_data ath79_switch_data;
+extern struct ag71xx_mdio_platform_data ath79_mdio0_data;
+extern struct ag71xx_mdio_platform_data ath79_mdio0_data;
... and the second line should refer to ath79_mdio*1*_data.
extern struct platform_device ath79_mdio0_device;
extern struct platform_device ath79_mdio1_device;
void ath79_register_mdio(unsigned int id, u32 phy_mask);
diff --git
a/target/linux/ar71xx/files/arch/mips/include/asm/mach-ath79/ag71xx_platform.h
b/target/linux/ar71xx/files/arch/mips/include/asm/mach-ath79/ag71xx_platform.h
index 656a6ef..333daa9 100644
---
a/target/linux/ar71xx/files/arch/mips/include/asm/mach-ath79/ag71xx_platform.h
+++
b/target/linux/ar71xx/files/arch/mips/include/asm/mach-ath79/ag71xx_platform.h
@@ -53,6 +53,7 @@ struct ag71xx_mdio_platform_data {
u8 is_ar7240:1;
u8 is_ar9330:1;
u8 is_ar934x:1;
+ u8 wake_phys:1;
To be honest, I would like to avoid any board specific workaround in the
ag71xx/mdio driver. Even if there is no other alternative to make it working on
the My Net N750 , this should be done in a more generic way.
It would be better to add a 'void (*reset)(struct mii_bus *bus);' callback to
the ag71xx_mdio_platform_data and call that from the ag71xx_mdio_reset function.
In that way, the extra functionality can be implemented within the board
specific code.
unsigned long mdio_clock;
unsigned long ref_clock;
};
diff --git
a/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_mdio.c
b/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_mdio.c
index ec88233..0f3ed63 100644
---
a/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_mdio.c
+++
b/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_mdio.c
@@ -156,10 +156,22 @@ static int ag71xx_mdio_get_divider(struct ag71xx_mdio
*am, u32 *div)
return -ENOENT;
}
+static int ag71xx_mdio_write(struct mii_bus *bus, int addr, int reg, u16 val)
+{
+ struct ag71xx_mdio *am = bus-priv;
+
+ if (am-pdata-builtin_switch)
+ ar7240sw_phy_write(bus, addr, reg, val);
+ else
+ ag71xx_mdio_mii_write(am, addr, reg, val);
+ return 0;
+}
+
static int ag71xx_mdio_reset(struct mii_bus *bus)
{
struct ag71xx_mdio *am = bus-priv;
u32 t;
+ int i;
int err;
err = ag71xx_mdio_get_divider(am, t);
@@ -181,6
Re: [OpenWrt-Devel] [PATCH 1/2] ar71xx: sysupgrade for My Net Wi-Fi Range Extender
2013.11.30. 20:14 keltezéssel, Christian Lamparter írta: I have applied the patches except the last one. On the WRT160NL, the preinit fixup is needed when the *-factory.bin image is flashed from the original web UI. Ok, so the factory web update did something with the trx header in the image? (Is it because the WRT160NL saves the settings by appending it to the image? At least the my rext has a dedicated nvram partition or is there something else going on?) The factory web update only writes trx-len bytes from the image to the flash, so the trx-len field must cover the entire image including the 0xdeadc0de marker. During first boot after flashing, the JFFS2 EOF marker will be erased which breaks the CRC value. -Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH][1/2] update Userspace support for the WA850/WA750
2013.11.29. 23:53 keltezéssel, Martijn Zilverschoon írta: Once again this patch complains that it is corrupt, but for some reason the last line of the mbox file is missing. That seemed also be the case with other patches as well. this command does do the trick however, sed in this case only adds a newline to the end of the file when it is missing. wget http://patchwork.openwrt.org/patch/4487/mbox/ -O - | sed '$a\' | git am -s Maybe it is worth looking into, or maybe tell me what I do wrong? I don't think that it is a patchwork issue because patches from other users are fine usually. However I don't know how you are submitting the patches, so I don't know what you are doing wrong. Maybe gmail causes the corruption. Ideally you should send patches inline instead of attaching that to the mail Additionally the Signed-off-by line should be part of the patch itself. because the other patch was submitted the same way and it doesn't have issues. Your previous patches also had the missing last line issue, but I have fixed those manually. -Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/2] ar71xx: sysupgrade for My Net Wi-Fi Range Extender
2013.11.30. 3:59 keltezéssel, Christian Lamparter írta:
...
+get_image_magic() {
+ local mtddev=$1
+ dd bs=8 count=1 skip=0 if=$mtddev 2/dev/null | hexdump -v -n 8 -e '1/1
%02x'
+}
This function is not used anywhere.
Uh, that's right! (this needs to be fixes)
AFICT, there are apparently two incompatible devices WD devices.
Both start with the same 4-Byte WDHN magic. However after
that, things get complicated.
1. the Starfish Platform (this is my range extender) uses STFH
(the full magic is WDHNSTFH).
2. the Seahorse Platform uses SHRS (WDHNSHRS).
This is why for wd hardware we need to check all 8 bytes.
Ok.
+
+mynet_rext_check_image() {
The function can be used for the wrt160nl as well. It would be better to
rename
it to cybertan_check_image or something similar.
Thanks! [Don't forget to close the WRT160NL ticket ;-)]
+ local magic=$(get_magic_long $1)
+ local fw_magic=$(get_magic_long `find_mtd_part \firmware\`)
+
+ [ $fw_magic != $magic ] {
+ echo Invalid image, ID mismatch, got:$magic, but
need:$fw_magic
+ return 1
+ }
+
+ return 0;
+}
+
+platform_do_upgrade_mynet_rext() {
+ default_do_upgrade $ARGV
+ mtd -o 32 fixtrx firmware
+}
Although this works, but it causes an extra erase of the first block of the
firmware partition. We should patch the sysupgrade file on the host while
we are building that and we should skip this extra step.
Can you try the attached patches instead please?
Didn't work. tried it twice, but sysupgrade bricked the device
(uboot complains about: Bad CRC).
Sorry about that. My WRT160NL uses an old bootloader which does not checks the
CRC at all. :)
However, it should be fixed now(tm).
I've attached my patches (add/merge them to your series):
0001-ar71xx-sysupgrade-for-My-Net-Wi-Fi-Range-Extender:
This is an update version of your 0003. Now, the script
really checks if all 8 byte matches.
[This replaces your 0003-ar71xx-sysupgrade...]
0002-firmware-utils-trx-fix-two-bugs: This fixes two bugs
in trx.c (The CRC32 wasn't calculated correctly if -F was
enabled).
0003-ar71xx-remove-trx-fixup: The preinit fixup is no longer
needed. We can delete the files and make the initial images
smaller.
I have applied the patches except the last one. On the WRT160NL, the preinit
fixup is needed when the *-factory.bin image is flashed from the original web
UI.
-Gabor
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: Kernel support update tl-wr842n_v2 added missing usb led
2013.11.18. 21:49 keltezéssel, Martijn Zilverschoon írta: Just a small oversight my part, added the support for the USB led Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: user space support update tl-wr842n_v2 add default led support
2013.11.18. 22:13 keltezéssel, Martijn Zilverschoon írta: Small update to uci_defaults/01_leds, to support the usb led Signed-off-by: Martijn Zilverschoon thefriedzom...@gmail.com Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/2] ag71xx: add F1E specific feature bit definitions to AR934X register file
2013.11.24. 3:31 keltezéssel, Christian Lamparter írta: The F1E Phy (AR8035?) requires additional bits to be set in order to provide a fast and reliable connection over gigabit links. When enabled, the link doesn't suffer anymore from a small package loss under load and the performance is improved quite a bit as well. (203 mbit/s vs 112 mbit/s, iperf tcp). Signed-off-by: Christian Lamparter chunk...@googlemail.com Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] ar71xx: improve support for the My Net Wi-Fi Range Extender device
2013.11.24. 3:34 keltezéssel, Christian Lamparter írta: This patch improves support for the device considerably. 1. The wifi didn't work in the initial release. This was because the WMAC of the AR9340 is not connected to the antennas. (However, it can pick up wifi signals, if they are strong enough!) Instead there's a dedicated AR9300 chip on the same board, which works. 2. Ethernet throughput is improved. iperf shows that the hardware can sustain more than 200Mbit/s and no longer drops any packages when the link is under load. Signed-off-by: Christian Lamparter chunk...@googlemail.com Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: rssi leds for My Net WiFi Range Extender
2013.11.24. 3:58 keltezéssel, Christian Lamparter írta: The device has three extra LEDs which indicate the quality of the wireless link. Thanks to rssileds, this feature now works out of the box. Signed-off-by: Christian Lamparter chunk...@googlemail.com Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [Patch] ar71xx: fix switch port map for the Sitecom WLR-8100
2013.11.27. 21:16 keltezéssel, Dirk Neukirchen írta: There was no way to determine a working config, because the switch (ar8337) was not working previously. Signed-off-by: Dirk Neukirchen dirkneukirc...@web.de Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH][1/2] update Userspace support for the WA850/WA750
2013.11.29. 10:21 keltezéssel, Martijn Zilverschoon írta: Patch for adding the default uci values of the rssileds application for the tp-link -tl-wa850re and the tl-wa750re for the The patch is corrupt: $ wget http://patchwork.openwrt.org/patch/4478/mbox/ -O - | git am -s --2013-11-29 21:29:57-- http://patchwork.openwrt.org/patch/4478/mbox/ Resolving patchwork.openwrt.org (patchwork.openwrt.org)... 188.40.166.11 Connecting to patchwork.openwrt.org (patchwork.openwrt.org)|188.40.166.11|:80... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/plain] Saving to: `STDOUT' [ = ] 2,467 10.9K/s in 0.2s 2013-11-29 21:29:58 (10.9 KB/s) - written to stdout [2467] Applying: update Userspace support for the WA850/WA750 fatal: corrupt patch at line 28 Patch failed at 0001 update Userspace support for the WA850/WA750 Also a Signed-off-by line is missing. Please fix it. Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH][2/2] AR71xx: Update profile for the wa750/wa850 to include rssileds by default
The patch is corrupt: $ wget http://patchwork.openwrt.org/patch/4479/mbox/ -O - | git am -s --2013-11-29 21:34:09-- http://patchwork.openwrt.org/patch/4479/mbox/ Resolving patchwork.openwrt.org (patchwork.openwrt.org)... 188.40.166.11 Connecting to patchwork.openwrt.org (patchwork.openwrt.org)|188.40.166.11|:80... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/plain] Saving to: `STDOUT' [ = ] 1,184 --.-K/s in 0.001s 2013-11-29 21:34:09 (826 KB/s) - written to stdout [1184] Applying: AR71xx: Update profile for the wa750/wa850 to include rssileds by default fatal: corrupt patch at line 22 Patch failed at 0001 AR71xx: Update profile for the wa750/wa850 to include rssileds by default Also a Signed-off-by line is missing. Please fix it. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/2] Initial NAND support for WNDR4300
2013.11.10. 11:58 keltezéssel, Stefan Agner írta: Nevermind, the second time it worked: [2.71] UBI: attaching mtd8 to ubi0 [2.74] UBI: EOF marker found, PEBs from 17 will be erased [2.74] UBI: scanning is finished [2.77] gluebi (pid 1): gluebi_resized: got update notification for unknown UBI device 0 volume 1 [2.78] UBI: volume 1 (rootfs_data) re-sized from 1 to 146 LEBs [2.79] UBI: attached mtd8 (name ubiroot, size 23 MiB) to ubi0 [2.80] UBI: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes [2.81] UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 2048 [2.81] UBI: VID header offset: 2048 (aligned 2048), data offset: 4096 [2.82] UBI: good PEBs: 184, bad PEBs: 0, corrupted PEBs: 0 [2.82] UBI: user volume: 2, internal volumes: 1, max. volumes count: 128 [2.83] UBI: max/mean erase counter: 1/0, WL threshold: 4096, image sequence number: 1699075075 [2.84] UBI: available PEBs: 0, total reserved PEBs: 184, PEBs reserved for bad PEB handling: 20 [2.85] UBI: background thread ubi_bgt0d started, PID 263 [2.86] mtd: device 12 (rootfs) set to be root filesystem [2.87] VFS: Mounted root (squashfs filesystem) readonly on device 31:12. Probably because I made no make clean before building the new image with those EOF marker? Yes, that was the reason. Without make clean, the required kernel patch has not been applied. -Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: wndr4300: set official mac addresses
2013.11.10. 18:34 keltezéssel, Stefan Agner írta: Get the factory assigned mac addresses stored in the caldata partition and asign them to lan, wan and radio1. Signed-off-by: Stefan Agner ste...@agner.ch Applied with some changes. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [1/3] ar71xx: Add kernel support for the WR842N/ND v2
2013.11.10. 20:31 keltezéssel, Martijn Zilverschoon írta: Patch to add kernel support for the TP-LINK WR842N/ND v2 Signed-off-by: Martijn Zilverschoon thefriedzom...@gmail.com Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [2/3] ar71xx: add profile for the WR842N/ND v2
2013.11.10. 20:32 keltezéssel, Martijn Zilverschoon írta: Patch to add the profile for the TP-LINK WR842N/ND v2 Signed-off-by: Martijn Zilverschoon thefriedzom...@gmail.com Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [2/3] ar71xx: add profile for the WR842N/ND v2
2013.11.11. 14:17 keltezéssel, Martijn Zilverschoon írta: Signed-off-by: Martijn Zilverschoon thefriedzom...@gmail.com 2013/11/11 Martijn Zilverschoon thefriedzom...@gmail.com: Patch to add the profile for the TP-LINK WR842N/ND v2 Small update, because of a change in the Makefile. Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: Add kernel support for the TP-Link WA750RE / WA850RE range extender
2013.11.04. 10:15 keltezéssel, Martijn Zilverschoon írta: Patch to add kernel support for the TP-LINK WA750RE and the WA850RE range extender Signed-off-by: Martijn Zilverschoon thefriedzom...@gmail.com Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] ar71xx: Use KEY_RESTART key code for the reset button on WD My Net N600 boards
2013.11.08. 22:21 keltezéssel, Christian Lamparter írta: Signed-off-by: Christian Lamparter chunk...@googlemail.com Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ag71xx: fix ag71xx_probe error path
2013.11.10. 10:42 keltezéssel, Catalin Patulea írta: Signed-off-by: Catalin Patulea c...@vv.carleton.ca Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ag71xx: fix a race involving netdev registration
2013.11.03. 9:16 keltezéssel, Catalin Patulea írta: In particular, phy_connect before register_netdev. This is because register_netdev runs the netdev notifiers, which can race with the rest of the initialization in ag71xx_probe. In my case this manifested in two ways: 1) If ag71xx is compiled as a module and inserted after netifd has started, netifd is notified by register_netdev before the call to ag71xx_phy_connect. netifd tries to bring the interface up, which calls ag71xx_open, which in turn enters ag71xx_phy_start. This keys off ag-phy_dev (which is still NULL) and thinks this is a fixed-link board, and enters ag71xx_link_adjust. This looks at ag-speed which is not yet initialized and hits the BUG() in the switch (ag-speed) in ag71xx_link_adjust. This is the wrong code path for ag71xx_phy_start - my board has PHYs that need to be brought up with phy_start. Doing ag71xx_phy_connect before register_netdev ensures that ag-phy_dev is non-NULL before ag71xx_phy_start is ever called. 2) When ag71xx is built into the kernel, and netconsole is enabled, there is a gap in the initial burst of replayed printks right after the netdev comes up. My assumption is that netconsole is also triggered by a netdev notifier, and part of this printk burst happens before the call into ag71xx_phy_connect, so part of the burst is lost while the PHY comes up. This patch fixes the gap - all the printks before eth0 comes up are bursted in full when netconsole initializes. ag71xx_phy_connect_xxx no longer runs with a registered netdev, so the logging has been adjusted accordingly to avoid unregistered net_device or eth%d messages in dmesg. Signed-off-by: Catalin Patulea c...@vv.carleton.ca Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/2] mtd_get_mac_ascii bugfix
2013.11.07. 17:23 keltezéssel, Daniel Gimpelevich írta:
The mtd_get_mac_ascii utility function was broken. This fixes it.
Signed-off-by: Daniel Gimpelevich dan...@gimpelevich.san-francisco.ca.us
Index: package/base-files/files/lib/functions.sh
===
--- a/package/base-files/files/lib/functions.sh (revision 38679)
+++ b/package/base-files/files/lib/functions.sh (working copy)
@@ -248,15 +248,13 @@
local part
local mac_dirty
- . /lib/functions.sh
-
part=$(find_mtd_part $mtdname)
if [ -z $part ]; then
echo mtd_get_mac_ascii: partition $mtdname not found! 2
return
fi
- mac_dirty=$(strings $part | sed -n 's/'$key'=//p')
+ mac_dirty=$(strings $part | sed -n 's/^'$key'=//p')
# canonicalize mac
printf %02x:%02x:%02x:%02x:%02x:%02x 0x${mac_dirty//:/ 0x}
}
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/2] mtd_get_mac_ascii bugfix
2013.11.08. 13:20 keltezéssel, Gabor Juhos írta: 2013.11.07. 17:23 keltezéssel, Daniel Gimpelevich írta: The mtd_get_mac_ascii utility function was broken. This fixes it. Signed-off-by: Daniel Gimpelevich dan...@gimpelevich.san-francisco.ca.us Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/2] Initial NAND support for WNDR4300
Hi Stefan, ... Correct. I had to modify ubox to make it work correctly with JFFS2 on emulated MTD devices. On my device, when using ubox without any patchs, I get errors, but it worked somehow... Weird. For me it was working only at the first boot after flashing the image, but any modifications in the fs has been lost after subsequent reboots. I already tested UBIFS on the device by manually overlaying it, technically things look good. But to support proper UBIFS instead of JFFS2 we would need another bunch of changes to ubox and also quite a lot of changes to the init scripts. What do you think, were to begin on this matter? I have no idea, I did not look into that too deep yet. AFAIK the WAN port is not connected to the second ethernet interface, so we are using VLANs to separate that from the LAN ports. It is working, but currently it uses the same MAC address as the LAN interface. Additionally, this MAC address is a randomly genereated one. We should read the correct MAC from the flash and set the interface MAC addresses based on that. You're right, its already configured correctly on eth0.2. Just tested the WAN port, looks good on my device. Thanks for your great work! Having mainline OpenWRT on it, I really like this device! ;) -Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/2] tools: adapt addpattern for WD's Range Extender
2013.11.02. 21:13 keltezéssel, Christian Lamparter írta: A few things had to be changed to add support for these devices: - support code patterns with 8 characters - new board definition for the range extender device Signed-off-by: Christian Lamparter chunk...@googlemail.com Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] ar71xx: add My Net Wi-Fi Range Extender device
2013.11.02. 21:14 keltezéssel, Christian Lamparter írta: This patch adds a new device definition for a Western Digital device. The hardware seems to be based on Qualcomm Atheros DB120 design. Signed-off-by: Christian Lamparter chunk...@googlemail.com Applied with some changes. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/2] Initial NAND support for WNDR4300
Hi Stefan, Sorry for the dealy. This replaces my patch sent in September. I rebased the changes to master as of today. Also I altered the functionality; The image now uses squashfs and JFFS2 on UBI (using GLUEBI) in order to provide proper NAND support. Its not the final solution, but works right now out of the box regarding user space utilites. Would be nice to see this initial support upstream. I have applied both patches, although I did several modifications in those. By creating a file system manually I tested using UBIFS instead of JFFS2 as the overlaying file system, it seems to work. However, userspace utilities (ubox) need to be altered in order to support this properly. Correct. I had to modify ubox to make it work correctly with JFFS2 on emulated MTD devices. Gabor, I also noticed that the WAN port on this device does not work yet. I looked into the code, the platform code only registers one ethernet device right now. Do you know whats missing there to make WAN working? AFAIK the WAN port is not connected to the second ethernet interface, so we are using VLANs to separate that from the LAN ports. It is working, but currently it uses the same MAC address as the LAN interface. Additionally, this MAC address is a randomly genereated one. We should read the correct MAC from the flash and set the interface MAC addresses based on that. -Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Ramips Seama sysupgrade image
2013.10.20. 19:36 keltezéssel, Flávio Silveira írta: Any news on this? Original Message Subject: Ramips Seama sysupgrade image Date: Mon, 7 Oct 2013 13:23:54 -0300 From: Flávio Silveira f...@terra.com.br To: OpenWrt Development List openwrt-devel@lists.openwrt.org Good afternoon, I have a question about sysupgrade image for Ramips routers that uses Seama. Shouldn't sysupgrade image contain the same magic as factory image? Currently generated sysupgrade image for my router (D-Link DIR-610 A1) doesn't have it, causing sysupgrade to reject the image. The sysupgrade image should contain a seama header, otherwise the bootloader will not load the kernel. I'm confident that it was working on the DIR-645 when I have added support for that. It seems that the Seama image generation is broken in trunk since r36169. Not only the sysupgrade images are broken but the factory images as well. -Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Ramips Seama sysupgrade image
2013.10.22. 21:17 keltezéssel, Flávio Silveira írta: ... It seems that the Seama image generation is broken in trunk since r36169. Not only the sysupgrade images are broken but the factory images as well. -Gabor The factory images are ok, at least for my DIR-610, but sysupgrade doesn't seem to contain seama header, The factory images have no JFFS2 EOF markers, and probably that is the reason why did you see these jffs2 warnings on your board: http://codepad.org/JyXaTjrA are you working on this? Not at the moment, but I will look into that later this week. Let me know if you want me to test anything Ok. -Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [packages] add sysprof tool
2013.08.22. 9:17 keltezéssel, Janusz Dziedzic írta: Add sysprof - preformance profiler for Linux - to the development tools. Patches for mips/arm are from openembedded code. sysprof-cli outfile get required events/stack frames. Next outfile can be loaded/displayed on PC using sysprof. Tool using: - PERF events - /proc/kallsyms for kernel symbols You should compile kernel with profiling enabled, debug information, symbol table information. Signed-off-by: Janusz Dziedzic janusz.dzied...@tieto.com Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Update tig to 1.2.1. See http://jonas.nitro.dk/tig/NEWS.html for details.
2013.08.30. 19:35 keltezéssel, Francisco Borges írta: Signed-off-by: Francisco Borges francisco.bor...@gmail.com Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [packages] Update mosquitto to 1.2
2013.08.22. 18:01 keltezéssel, Karl Palsson írta: From: Karl Palsson ka...@remake.is Updates mosquitto, the MQTT broker, and client libraries to version 1.2. Full changelog here: http://mosquitto.org/2013/08/version-1-2-released/ Added missing library depends to suit updated requirements in OpenWrt. Fixed missing symlinks. Signed-off-by: Karl Palsson ka...@remake.is Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [packages] avahi: Clean up dependencies
2013.09.06. 9:59 keltezéssel, Helmut Schaa írta: libavahi does not require libdaemon nor libgdbm. Move the dependencies into the right avahi sub-packages to allow smaller footprint when only using libavahi. Signed-off-by: Helmut Schaa helmut.sc...@googlemail.com Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [packages] lighttpd: update to 1.4.32
2013.09.05. 13:18 keltezéssel, mgeral...@yahoo.de írta: This patch updates the lighttpd package to version 1.4.32 The makefile has been reworked and uses a macro for module creation The config file has been updated to include module dependant configuration from conf.d subdirectory Signed-off-by: Gerald Matzka mgeral...@yahoo.de Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [packages] zabbix: update to version 2.0.8
2013.09.16. 22:26 keltezéssel, Jiri Slachta írta: Signed-off-by: Jiri Slachta slac...@cesnet.cz Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Update wifidog to 20130917 version
2013.09.17. 23:18 keltezéssel, Etienne CHAMPETIER írta: This update: -adds a ProxyPort option (to use a local transparent proxy) -changes http return code to 302 (was 307, but wifidog speaks http 1.0, and we really need 303) (it was causing some trouble with, for exemple, opera) -switch to github repo -correct a small typo -add drop, log, ulog target for FirewallRule This is only compile tested, but 3 people are asking for it https://github.com/wifidog/wifidog-gateway/issues/8 Signed-off-by: Etienne CHAMPETIER etienne.champet...@free.fr Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [Patch][packages] libshout: fix libshout compile
2013.09.23. 11:56 keltezéssel, Dirk Neukirchen írta: libvorbisidec 1.0.2+svn18153 uses ogg/ogg.h now instead of its own that was provided previously issue reported: https://forum.openwrt.org/viewtopic.php?id=45843 Signed-off-by: Dirk Neukirchen dirkneukirc...@web.de Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [Patch][packages] libshout: update libshout to 2.3.1 , refresh patches
2013.09.23. 11:58 keltezéssel, Dirk Neukirchen írta: update package libshout to 2.3.1 and refresh patches Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH][package] uob-nomad: fix compilation
2013.09.23. 17:48 keltezéssel, Dirk Neukirchen írta: fix compilation - by integrating net-tools-1.60-STRIP.patch from Jiri Popelka jpope...@redhat.com - if_tr.h is no longer in kernel Signed-off-by: Dirk Neukirchen dirkneukirc...@web.de Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH][packages] remotefs: update remotefs , change to repo to git
2013.09.23. 17:55 keltezéssel, Dirk Neukirchen írta: - sourceforge uses git use that - update to latest version: it fixes a compile bug of the old git version (missing md5_crypt) Signed-off-by: Dirk Neukirchen dirkneukirc...@web.de Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] [packages] ser2net: bump to 2.9.1
2013.09.26. 22:24 keltezéssel, Yegor Yefremov írta: This version fixes a segmentation fault due to a missing buffer wrap. Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [packages] shflags: Fix getting sources
2013.10.01. 13:33 keltezéssel, Diego Lopez Recas írta: Freecwmp does not export a git repository for shflags anymore. This fix makes OpenWrt get the sources directly from the svn repository of the shflags googlecode project. Signed-off-by: Diego López Recas suelt...@gmail.com mailto:suelt...@gmail.com Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [packages] alpine: New package (v2)
2013.09.30. 19:27 keltezéssel, Antti Seppälä írta: Add Alpine v. 2.10 console mail client as new package to OpenWrt. Alpine stands for Alternatively Licensed Program for Internet News and Email and is suitable for both the inexperienced email user as well as for the most demanding power user. This is a v2 of my previous patch fixing build issues in certain flavours of Linux. Thanks to Szymon Zygmunt for reporting. Signed-off-by: Antti Seppälä a.sepp...@gmail.com Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: fix WLAN 5 GHz LED init on dir-825-c1
2013.10.02. 23:56 keltezéssel, Sebastian Kemper írta: Fixes the 5 GHz LED. The same function has no effect on the 2.4 GHz LED at all, so we might as well remove it. Signed-off-by: Sebastian Kemper sebastian...@gmx.net Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH][packages] xupnpd: Add new package
2013.10.13. 21:36 keltezéssel, Álvaro Fernández Rojas írta: Package based on: http://tsdemuxer.googlecode.com/svn/trunk/xupnpd/src/contrib/OpenWrt/ Light DLNA Media Server which provides services for sharing IPTV unicast streams over local area network. Signed-off-by: Álvaro Fernández Rojas nolt...@gmail.com Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 03/10] mkfwimage: Increase RSPRO maximum size to 0xF00000 (15 MiB)
2013.10.10. 13:02 keltezéssel, Bruno Randolf írta: RSPRO has 16MiB of Flash, using the following layout: [2.93] 0x-0x0003 : RedBoot [2.94] 0x0003-0x0013 : kernel [2.95] 0x0013-0x00ff : rootfs [2.96] 0x00ff-0x00fff000 : FIS directory [2.97] 0x00fff000-0x0100 : RedBoot config Firmware images contain kernel and rootfs, so they can use up to 0xFF - 0x3 = 0xFC (15,75MiB) of space. We don't include the RedBoot and FIS partitions and leave an extra 0xC (768KiB) of space. This is based on revision 18410 which sets the limit to 0xB0 (11 MiB). Signed-off-by: Bruno Randolf b...@einfach.org Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCHv2] ar71xx: Fix sysupgrades for Allnet and OpenMesh devices
2013.10.18. 11:08 keltezéssel, Sven Eckelmann írta: Both Allnet and OpenMesh sysupgrade uses fw_setenv from uboot-envtools to change different settings in the uboot environment. uboot-envtools version 2013.01 introduced a filesystem lock /var/lock/fw_printenv.lock to guarantee mutually exclusive access to the uboot environment. But the path /var doesn't exist on the sysupgrade ramfs. An upgrade on these devices fails since r36033 ([package] uboot-envtools: upgrade to version 2013.01.01) with following messages: Error opening lock file /var/lock/fw_printenv.lock failed to update U-Boot environment Creating the /var/lock path before running fw_setenv is therefore a requirement unless the locking functionality in fw_setenv is removed or replaced with optional locking. Signed-off-by: Sven Eckelmann s...@open-mesh.com Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] This upgrades haveged from 1.4 to 1.7c (closes #13979)
2013.09.09. 18:28 keltezéssel, Christian Pointner írta: Signed-off-by: Christian Pointner equi...@chaos-at-home.org Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SoC NAND driver ar934x/OpenWRT support on WNDR4300
2013.09.25. 11:26 keltezéssel, Gabor Juhos írta: Now I tried to create a UBI volume using the initramfs-Kernel. I get this kernel crash dump: # ubiattach -m 8 /dev/ubi_ctrl [ 3712.32] UBI: attaching mtd8 to ubi0 [ 3712.51] UBI: scanning is finished [ 3712.52] UBI: empty MTD device detected [ 3712.52] CPU 0 Unable to handle kernel paging request at virtual address , epc == , ra == 802094fc [ 3712.53] Oops[#1]: [ 3712.53] CPU: 0 PID: 1216 Comm: ubiattach Not tainted 3.10.12 #10 [ 3712.53] task: 878b5d50 ti: 8654c000 task.ti: 8654c000 [ 3712.53] $ 0 : 0001 8037c810 [ 3712.53] $ 4 : 87826010 0001 01ff 0200 [ 3712.53] $ 8 : 0005 80064830 [ 3712.53] $12 : d8197822 [ 3712.53] $16 : 878261b8 87826010 86e34000 [ 3712.53] $20 : 0200 86e34500 86e34d00 0007 [ 3712.53] $24 : [ 3712.53] $28 : 8654c000 8654dae8 802094fc [ 3712.53] Hi: [ 3712.53] Lo: 0010 [ 3712.53] epc : (null) [ 3712.53] Not tainted [ 3712.53] ra: 802094fc nand_write_subpage_hwecc+0xa0/0x1c4 Hm, this is a NULL pointer dereference. It seems that the nand_write_subpage_hwecc function tries to run a callback which is not initialized by the ar934x-nfc driver. I will look into that later. FYI, I have disabled writing of subpages in the driver. It is not supported by the controller if hardware ECC is used. At least I was not able to make it work. In the past, I have tested the ar934x-nfc driver (w/o hw ECC) with the modules provided by the mtdtests package and it passed all tests. Ideally, it should be tested again with hw ECC support but that is quite dangerous on devices which are using a NAND flash only. It passes all MTD tests now. Tested on the first MB of the reserved area on a on the WNDR4300: root@OpenWrt:/# cat /proc/mtd dev:size erasesize name mtd0: 0004 0002 u-boot mtd1: 0004 0002 u-boot-env mtd2: 0004 0002 caldata mtd3: 0008 0002 pot mtd4: 0020 0002 language mtd5: 0008 0002 config mtd6: 0030 0002 traffic_meter mtd7: 0012 0002 kernel mtd8: 017e 0002 rootfs mtd9: 0190 0002 firmware mtd10: 0004 0002 caldata_backup mtd11: 0010 0002 test mtd12: 05f0 0002 reserved root@OpenWrt:/# insmod /lib/modules/3.10.12/mtd_readtest.ko dev=11 [ 53.39] [ 53.39] = [ 53.40] mtd_readtest: MTD device: 11 [ 53.40] mtd_readtest: MTD device size 1048576, eraseblock size 131072, page size 2048, count of eraseblocks 8, pages per eraseblock 64, OOB size 64 [ 53.42] mtd_readtest: scanning for bad eraseblocks [ 53.42] mtd_readtest: scanned 8 eraseblocks, 0 are bad [ 53.43] mtd_readtest: testing page read [ 53.76] mtd_readtest: finished [ 53.77] = root@OpenWrt:/# insmod /lib/modules/3.10.12/mtd_speedtest.ko dev=11 [ 115.18] [ 115.18] = [ 115.19] mtd_speedtest: MTD device: 11 [ 115.19] mtd_speedtest: MTD device size 1048576, eraseblock size 131072, page size 2048, count of eraseblocks 8, pages per eraseblock 64, OOB size 64 [ 115.21] mtd_speedtest: scanning for bad eraseblocks [ 115.22] mtd_speedtest: scanned 8 eraseblocks, 0 are bad [ 115.23] mtd_speedtest: testing eraseblock write speed [ 115.48] mtd_speedtest: eraseblock write speed is 4162 KiB/s [ 115.49] mtd_speedtest: testing eraseblock read speed [ 115.80] mtd_speedtest: eraseblock read speed is 3313 KiB/s [ 115.81] mtd_speedtest: testing page write speed [ 116.07] mtd_speedtest: page write speed is 4129 KiB/s [ 116.07] mtd_speedtest: testing page read speed [ 116.39] mtd_speedtest: page read speed is 3303 KiB/s [ 116.40] mtd_speedtest: testing 2 page write speed [ 116.65] mtd_speedtest: 2 page write speed is 4162 KiB/s [ 116.66] mtd_speedtest: testing 2 page read speed [ 116.97] mtd_speedtest: 2 page read speed is 3303 KiB/s [ 116.98] mtd_speedtest: Testing erase speed [ 116.99] mtd_speedtest: erase speed is 170666 KiB/s [ 116.99] mtd_speedtest: Testing 2x multi-block erase speed [ 117.00] mtd_speedtest: 2x multi-block erase speed is 341333 KiB/s [ 117.01] mtd_speedtest: Testing 4x multi-block erase speed [ 117.02] mtd_speedtest: 4x multi-block erase speed is 341333 KiB/s [ 117.02] mtd_speedtest: Testing 8x multi-block erase speed [ 117.03] mtd_speedtest: 8x multi-block erase speed is 341333 KiB/s [ 117.04] mtd_speedtest: Testing 16x multi-block erase speed [ 117.05] mtd_speedtest: 16x multi-block erase
Re: [OpenWrt-Devel] Target kernel config changes not triggering rebuild?
2013.09.24. 16:56 keltezéssel, Paul Fertser írta: Hello, Gabor Juhos juh...@openwrt.org writes: Yes, the 'Image/Build/Cameo' macro is broken. Don't need to send a patch, I'm working on that already. Great cleanup and the fixes on top, thank you! Can you please explain what is this mac partition about, what does it hold? I know wireless eeprom is in the last art partition and that seems to be all that's needed, at least on my other wr741nd device. The WR741ND has no such partition. To be precise, there is an user_cfg partition before the wifi calibration data. That is used by the factory firmware to store user specific settigns. We are reusign that because the factory firmware can reinitialize that with the factory reset option. On the DIR-600-Ex, the 'mac' partition contains the board specific MAC addresses at least, and it seems that there are other data as well. I guess that the original firmware uses this data to reinialize the nvram variables during factory reset. If that partition is erased, and someone wants to use the original software again, it will not be able to do a factory reset. I also faced a strange issue which forced me to open the device and attach the serial (and for no evident reason tftpboot didn't work either, the device kept sending me arp requests ignoring my replies, so I had to use Ymodem). Apparently, after I did git pull; make oldconfig; make and sysupgraded, the resulting images ended up missing the appropriate firmware partition splitters so it couldn't mount the rootfs after the reboot. I have no real clue how that might have happened but make target/linux/clean; make gave me a new sysupgrade image that work fine. If you are rebuilding a kernel after a kernel configuration change, it will use the modified configuration. However if the generic/platform specific kernel patches are modified, or some patches has been added/deleted those will not be used without a target/linux/clean. Thank you again for your work. Np. -Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SoC NAND driver ar934x/OpenWRT support on WNDR4300
2013.09.24. 23:07 keltezéssel, Stefan Agner írta: Am 2013-09-24 19:09, schrieb Gabor Juhos: A dd command with conv=noerror leads to a image witch is 16KiB smaller than it should be. Don't use dd on NAND flashes. Use the nanddump utility from the mtd-utils package instead. Ok I understand that /dev/mtdblock[x] is not the way to handle NAND, but reading should work anyway. Yes, it should work. However the mtdblock layer can't handle bad blocks/ecc errors so that throws error messages. By using nanddump I could successfully dump the images, although the ECC check corrected bitflips. I guess that when using this NAND through mtdblock, this leads to an I/O error (since its the exactly same place, 2880*512 = 0x00168000). root@OpenWrt:/tmp# dd if=/dev/mtdblock10 of=/tmp/gaga [ 1350.92] end_request: I/O error, dev mtdblock10, sector 2880 [ 1350.92] Buffer I/O error on device mtdblock10, logical block 360 [ 1351.00] end_request: I/O error, dev mtdblock10, sector 2880 [ 1351.00] Buffer I/O error on device mtdblock10, logical block 360 dd: /dev/mtdblock10: Input/output error root@OpenWrt:/tmp# nanddump /dev/mtd10 /tmp/wndr4300-mtd10-nanddump.img --omito ob --bb=skipbad ECC failed: 0 ECC corrected: 48 Number of bad blocks: 0 Number of bbt blocks: 0 Block size 131072, page size 2048, OOB size 64 Dumping data starting at 0x and ending at 0x0190... ECC: 16 corrected bitflip(s) at offset 0x00168000 But this is not a showstopper than, since the driver seems to work correctly using the mtd interface. Did you write/erase the any of the partitions by any chance? Hm, I think I played around mounting the jffs2 partition once.. this should be after the CRC checked squashfs, but maybe I used the wrong mtd. This would explain the error. I reflashed the image, since then it boots fine even after using nanddump etc. from initram Ok. Even if you have used the correct mtd device, writing something into that can cause bit-flips in other erase blocks due to the common 'Write Disturb' problem. Now I tried to create a UBI volume using the initramfs-Kernel. I get this kernel crash dump: # ubiattach -m 8 /dev/ubi_ctrl [ 3712.32] UBI: attaching mtd8 to ubi0 [ 3712.51] UBI: scanning is finished [ 3712.52] UBI: empty MTD device detected [ 3712.52] CPU 0 Unable to handle kernel paging request at virtual address , epc == , ra == 802094fc [ 3712.53] Oops[#1]: [ 3712.53] CPU: 0 PID: 1216 Comm: ubiattach Not tainted 3.10.12 #10 [ 3712.53] task: 878b5d50 ti: 8654c000 task.ti: 8654c000 [ 3712.53] $ 0 : 0001 8037c810 [ 3712.53] $ 4 : 87826010 0001 01ff 0200 [ 3712.53] $ 8 : 0005 80064830 [ 3712.53] $12 : d8197822 [ 3712.53] $16 : 878261b8 87826010 86e34000 [ 3712.53] $20 : 0200 86e34500 86e34d00 0007 [ 3712.53] $24 : [ 3712.53] $28 : 8654c000 8654dae8 802094fc [ 3712.53] Hi: [ 3712.53] Lo: 0010 [ 3712.53] epc : (null) [ 3712.53] Not tainted [ 3712.53] ra: 802094fc nand_write_subpage_hwecc+0xa0/0x1c4 Hm, this is a NULL pointer dereference. It seems that the nand_write_subpage_hwecc function tries to run a callback which is not initialized by the ar934x-nfc driver. I will look into that later. In the past, I have tested the ar934x-nfc driver (w/o hw ECC) with the modules provided by the mtdtests package and it passed all tests. Ideally, it should be tested again with hw ECC support but that is quite dangerous on devices which are using a NAND flash only. -Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] How to enable Seama firmware parser for Ramips?
2013.09.24. 23:57 keltezéssel, Flávio Silveira írta: Jacek Kikiewicz wrote: Don't you have to have partition called rootfs in your definition? Then it should pick it up... Regards, Jacek Hi Jacek, thanks for your quick answer. I don't know, ít's not what I'm seeing in others dts files and when I was starting to port this device I was told to keep only u-boot, u-boot-env and devdata partitions from stock firmware, but I decided to put u-boot-env together with devdata. Here is stock boot log: http://codepad.org/stXQWQSQ Looking at https://dev.openwrt.org/changeset/38114 it seems the parser is disabled for anything else besides ar71xx. Yes, it is disabled by default because it is only tested on ar71xx so far. However it should work on ramips as well, and it will be enabled once I have a chance to test it on the DIR-645. If you want to try it on the DIR-610, you can enable it in the kernel config: 'Device Drivers Memory Technology Device (MTD) support OpenWrt specific MTD options Seama firmware parser' Also, when I look at the parser code itself, it seems that it searches for rootfs in firmware partition, after the kernel https://dev.openwrt.org/browser/trunk/target/linux/generic/files/drivers/mtd/mtdsplit_seama.c?rev=38114 Correct. The Seama images are starting with the kernel and the rootfs is placed after that. At least on the devices I have. -Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] atheros: fix kernel warning about usage of reset gpio
2013.09.17. 22:15 keltezéssel, Michael Heimpold írta: During a reset the gpiolib warns about using the reset gpio without explicit requesting it before: [ 147.93] [ cut here ] [ 147.93] WARNING: at drivers/gpio/gpiolib.c:103 gpio_ensure_requested+0x68/0xcc() [ 147.93] autorequest GPIO-5 [ 147.93] Modules linked in: ath5k ath mac80211 ipv6 cfg80211 compat arc4 crypto_blkcipher aead gpio_button_hotplug [ 147.93] Call Trace: [ 147.93] [8004e3bc] dump_stack+0x8/0x34 [ 147.93] [80058430] warn_slowpath_common+0x78/0xa4 [ 147.93] [800584e4] warn_slowpath_fmt+0x2c/0x38 [ 147.93] [80166f18] gpio_ensure_requested+0x68/0xcc [ 147.93] [80167264] gpio_direction_output+0xdc/0x168 [ 147.93] [8004aba8] ar2315_restart+0x28/0x54 [ 147.93] [80069778] sys_reboot+0x178/0x1c0 [ 147.93] [80043670] stack_done+0x20/0x40 [ 147.93] [ 147.93] ---[ end trace 2c7a53d8549562d6 ]--- This is fixed with this patch by using another gpiolib api call which includes the missing request. Signed-off-by: Michael Heimpold m...@heimpold.de Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Add hwmon driver for ADT7410
2013.09.22. 0:55 keltezéssel, Hartmut Knaack írta: Add support for the ADT7410 hwmon driver, a high precision I2C temperature sensor. Signed-off-by: Hartmut Knaack knaac...@gmx.de Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Add support for industrial-io and AD799x
2013.09.22. 0:55 keltezéssel, Hartmut Knaack írta: Add support for industrial IO core and (still staging) driver for AD799x, a high precision I2C ADC family. Signed-off-by: Hartmut Knaack knaac...@gmx.de Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SoC NAND driver ar934x/OpenWRT support on WNDR4300
2013.09.23. 22:07 keltezéssel, Stefan Agner írta: Am 2013-09-23 21:08, schrieb Gabor Juhos: It should be possible to fix the board via JTAG. At least it seems that the PCB has an unpopulated JTAG header. Yes I thought about this too, but since I didn't found an openocd configuration which should work with this SoC, I didn't even tried it. I guess I would download U-Boot to RAM and try to reflash U-Boot from there, right? Yes, that would be the simplest method. Do you have a working JTAG toolchain for this SoC? Nope, I did not have to use JTAG on any AR934x based boards yet. Today I tested the driver. After adding the relevant Kernel configuration (CONFIG_MTD_NAND_AR934X_HW_ECC) I could successfully read from the device, data look good. However, when I tried to dd the whole kernel I get some errors: # dd if=/dev/mtdblock7 of=/tmp/wndr4300-mtd7-kernel.img [ 325.31] end_request: I/O error, dev mtdblock7, sector 424 [ 325.31] Buffer I/O error on device mtdblock7, logical block 53 [ 325.34] end_request: I/O error, dev mtdblock7, sector 536 [ 325.34] Buffer I/O error on device mtdblock7, logical block 67 [ 325.38] end_request: I/O error, dev mtdblock7, sector 424 [ 325.38] Buffer I/O error on device mtdblock7, logical block 53 dd: /dev/mtdblock7: Input/output error My first guess was this is/are bad blocks. But U-Boot seems not to support this idea: ar7240 nand bad Device 0 bad blocks: ar7240 Maybe U-Boot's bad block management doesn't work with those information... Despite what U-Boot says, those still can be bad blocks. The ar934x-ncf driver has no special bad block handling yet. A dd command with conv=noerror leads to a image witch is 16KiB smaller than it should be. Don't use dd on NAND flashes. Use the nanddump utility from the mtd-utils package instead. After working only with initramfs, the default Firmware doesn't boot anymore: ** check rootfs image ** Verifying Checksum ...Bad Data CRC This CRC checks the rootfs. Netgear put another uImage header just before the rootfs partition (but still in the kernel partition). It looks like the Kernel already changed something on NAND, which causes this Bad Data CRC... I then flashed the latest Netgear Firmware again. Guess what, I could successfully dd the whole kernel... But dd the rootfs still has Buffer I/O errors. Any idea what could go wrong here? I think it would be a good idea to figure out whats wrong before doing further steps... Well, the hardware ECC support in ar934x-nfc driver might contain some bugs. However, I don't think that the kernel writes anything into the flash by itself. Did you write/erase the any of the partitions by any chance? -Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SoC NAND driver ar934x/OpenWRT support on WNDR4300
2013.09.22. 22:43 keltezéssel, Stefan Agner írta: Am 2013-09-17 08:18, schrieb Gabor Juhos: 2013.09.16. 1:06 keltezéssel, Stefan Agner írta: It is done in software in the ar934x-nfc driver. The NAND controller of the AR934x SoCs also supports hardware based ECC calculation but that is not yet implemented in the driver. The hardware based ECC might use a different OOB layout and that would cause similar problems if thas is enabled in the bootloader. I checked that in the original firmware, they definitly use hardware NAND, in both, the Kernel and Bootloader (actually its the same driver). Yes, I have found that in the meantime. I guess that it would be easy to figure out if the bootloader uses a different OOB layout or not. I saw your commits 38069-38071, did you test them on a actual device? I have used a WNDR4300 for testing. I erased my U-Boot when I used nand erase clean, somehow my command line got parsed wrong :-( Sad, but that happens sometimes. I also did that on a few boxes already. I'll try to get a new device and test your changes. It should be possible to fix the board via JTAG. At least it seems that the PCB has an unpopulated JTAG header. The kernel automatically sets the rootfs partition to be the root filesystem if the 'CONFIG_MTD_ROOTFS_ROOT_DEV' option is set. Thanks, this was a missing piece in my mind :-) ;-) I split those targets, will send a patch as soon as I've got something useful. Ok. -Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] DIR-615 E4 (and possibly DIR600A1, DIR601A, FR54RTR, DIR825C1, DIR835A1) factory image padding size
Hi, When I tried to flash DIR-615 E4 with OpenWrt factory image via the vendor's web-interface, it refused to accept the new firmware. After some digging I think I found the issue and it possibly affects also DIR600A1, DIR601A, FR54RTR, DIR825C1 and DIR835A1. The way Cameo7240 profile currently works is to take uImageLzma, pad it to the multiple of 0x1 (64KiB), append squashfs padded to 0x2A, then append the signature (like AP99-AR7240-RT-091105-05 in my case). I think that worked initially when the resulting compressed kernel size was between 0xB0001 and 0xC, so with the rootfs the sum was 0x36. However, the current build gave me openwrt-ar71xx-generic-uImage-lzma.bin of size 0xF8570, so the resulting combined image was 0x4 bigger than it should have been. Yes, the 'Image/Build/Cameo' macro is broken. Now that the kernel partition size is determined automatically (by uImage splitting), it doesn't matter anymore how big is the kernel, what matters is to get the combined image of the right size. I can confirm that after I reduced the padding of the rootfs, the result was accepted by the stock vendor's firmware and now I run OpenWrt just fine :) Do you want me to prepare the patch that should fix DIR-615E4 images? Can other Cameo users speak up, is it the same for you, should the factory generation be fixed too in the same way? Don't need to send a patch, I'm working on that already. -Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/4] ar71xx: fix LAN LEDs for dir-825-c1
2013.09.20. 20:50 keltezéssel, Sebastian Kemper írta: This patches fixes the lan led configuration. The new configuration is identical to the one in mach-db120.c and it works. The previous one didn't work at all. Signed-off-by: Sebastian Kemper sebastian...@gmx.net Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/4] ar71xx: let HW switch control WAN LED on dir-825-c1
2013.09.20. 20:59 keltezéssel, Sebastian Kemper írta: Enable GPIO 20. This hands off control of the blue planet led to the integrated switch. Consequently, remove the led configuration for the blue planet led. Remove also the configuration for the orange planet led as both share the same look-out. Please don't remove that. Apart from the fact that both LEDs are behind the same icon you can still control the amber LED separately. -Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/4] ar71xx: let HW switch control WAN LED on dir-825-c1
2013.09.21. 15:51 keltezéssel, Sebastian Kemper írta: Enable GPIO 20. This hands off control of the blue planet led to the integrated switch. Consequently, remove the led configuration for the blue planet led. Signed-off-by: Sebastian Kemper sebastian...@gmx.net Applied with a minor whitespace change. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 4/4] ar71xx: enable wlan2g led in the default configuration of dir-825-c1
2013.09.20. 21:08 keltezéssel, Sebastian Kemper írta: Enable the wlan2g led in the default configuration of dir-825-c1. Signed-off-by: Sebastian Kemper sebastian...@gmx.net Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/4] ar71xx: vanity changes for dir-825-c1
2013.09.21. 15:56 keltezéssel, Sebastian Kemper írta: This patch - changes the color names from orange to amber - changes the name of GPIO 13 from WIFI_BGN (wifi_bgn) to WLAN_2G (wlan2g) to be more consistent with the other routers' files - changes the descriptions of the hardware keys to be a tad more explicit Signed-off-by: Sebastian Kemper sebastian...@gmx.net Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/5] [ar71xx] fix LAN LEDs for dir-825-c1
Hi Sebastian,
Please use the 'ar71xx:' prefix instead of [ar71xx] in the subject of ar71xx
specific patches.
Hello list,
Please don't use salutation part in patches. Everything before the marker line
'---' will be included into the commit message, so I have to remove this line
manually before applying the patch.
This patch removes the custom LAN LED configuration for the switch.
Without it the LAN LEDs are actually working.
I also tried the same configuration that is used in mach-db120.c. That
worked as well. But I think why add it when it's not needed.
I would fix it instead. It would make it independent from the bootloader.
Signed-off-by: Sebastian Kemper sebastian...@gmx.net
The marker line '---' is missing.
-Gabor
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
index c1bd8d6..c2ddfa8 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
@@ -139,14 +139,6 @@ static struct ar8327_pad_cfg dir825c1_ar8327_pad0_cfg = {
.rxclk_delay_sel = AR8327_CLK_DELAY_SEL2,
};
-static struct ar8327_led_cfg dir825c1_ar8327_led_cfg = {
- .led_ctrl0 = 0xc737c737,
- .led_ctrl1 = 0x,
- .led_ctrl2 = 0x,
- .led_ctrl3 = 0x0030c300,
- .open_drain = false,
-};
-
static struct ar8327_platform_data dir825c1_ar8327_data = {
.pad0_cfg = dir825c1_ar8327_pad0_cfg,
.port0_cfg = {
@@ -156,7 +148,6 @@ static struct ar8327_platform_data dir825c1_ar8327_data =
{
.txpause = 1,
.rxpause = 1,
},
- .led_cfg = dir825c1_ar8327_led_cfg,
};
static struct mdio_board_info dir825c1_mdio0_info[] = {
@@ -236,8 +227,6 @@ static void __init dir825c1_setup(void)
static void __init dir835a1_setup(void)
{
- dir825c1_ar8327_data.led_cfg = NULL;
-
ath79_register_leds_gpio(-1, ARRAY_SIZE(dir835a1_leds_gpio),
dir835a1_leds_gpio);
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/5] [ar71xx] add gpio that lets the switch control the WAN LED on dir-825-c1
2013.09.19. 23:50 keltezéssel, Sebastian Kemper írta:
Hello list,
Activating GPIO 20 hands over the control of the blue planet LED (WAN
LED) to the switch. Add this so we can put it to use.
Signed-off-by: Sebastian Kemper sebastian...@gmx.net
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
index c2ddfa8..8d9e7af 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
@@ -36,6 +36,8 @@
#define DIR825C1_GPIO_LED_BLUE_PLANET18
#define DIR825C1_GPIO_LED_WIFI_BGN 13
+#define DIR825C1_GPIO_LED_SWITCH_CONTROL 20
+
#define DIR825C1_GPIO_BTN_RESET 17
#define DIR825C1_GPIO_BTN_WPS16
@@ -82,6 +84,11 @@ static struct gpio_led dir825c1_leds_gpio[] __initdata = {
.gpio = DIR825C1_GPIO_LED_WIFI_BGN,
.active_low = 1,
},
+ {
+ .name = d-link:none:wan_led_switch_ctrl,
+ .gpio = DIR825C1_GPIO_LED_SWITCH_CONTROL,
+ .active_low = 1,
+ },
This looks quite ugly. The GPIO line should be configured directly from the
board setup code instead of adding a dummy LED. See the 'gpio_request_one()'
call in mach-tew-712br.c for example.
-Gabor
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/5] [ar71xx] vanity changes for dir-825-c1
2013.09.20. 8:11 keltezéssel, Sebastian Kemper írta: On Thu, Sep 19, 2013 at 11:55:13PM +0200, Sebastian Kemper wrote: Hello list, This patch - changes the color names from orange to amber - changes the name of GPIO 13 from WIFI_BGN (wifi_bgn) to WLAN_2G (wlan2g) to be more consistent with the other routers' files - changes the descriptions of the hardware keys to be a tad more explicit Signed-off-by: Sebastian Kemper sebastian...@gmx.net Hello list, It seems vanity comes at a price :) I forgot about the diagnostic LED; target/linux/ar71xx/base-files/etc/diag.sh needs an update otherwise it won't blink. I'll send an extra patch for this tonight. Please send a fixed version of the original patch instead of a separate one. -Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 5/5] [ar71xx] add to the default LED configuration of dir-825-c1
2013.09.20. 0:04 keltezéssel, Sebastian Kemper írta: Hello list, This patch adds to the default LED configuration. The blue power LED defaults to on. With the activation of wan_led_switch_ctrl we hand off control of the blue planet LED to the hardware switch; this means also that it will be enabled when the router starts. WLAN_2G LED also enabled by default. I haven't yet figured out how to setup GPIO 32 for WLAN_5G. Hopefully that will follow later :) Signed-off-by: Sebastian Kemper sebastian...@gmx.net diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds index f55f1fe..5e8e505 100755 --- a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds @@ -70,9 +70,15 @@ dir-615-e4) ucidef_set_led_switch lan4 LAN4 d-link:green:lan4 switch0 0x10 ;; -dir-825-b1 | \ +dir-825-b1) + ucidef_set_led_usbdev usb USB d-link:blue:usb 1-1 + ;; + dir-825-c1) ucidef_set_led_usbdev usb USB d-link:blue:usb 1-1 + ucidef_set_led_default wan Switch controls blue planet LED d-link:none:wan_led_switch_ctrl 1 This line should be removed along with the LED definition in mach-dir-825-c1.c file. + ucidef_set_led_default power Power Blue: on d-link:blue:power 1 Once the LED name will be fixed in diag.sh, this line will be obsolete as well. + ucidef_set_led_wlan wlan2g WLAN 2.4 GHz LED d-link:blue:wlan2g phy0tpt ;; hornet-ub) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 4/5] [ar71xx] set proper wan mac during initial configuration on dir-825-c1
2013.09.19. 23:58 keltezéssel, Sebastian Kemper írta: Hello list, I sent a patch earlier and received some advice on how to do it better. Here is my 2nd attempt. For the record: This kind of explanation should not be in the commit message. If you have notes about the patch it should be written after the marker line. The goal remains to set the WAN MAC address to the one on the sticker on the bottom of the unit. Currently it is not used at all. But some users expect the WAN interface to have the MAC address that is written on the sticker. Signed-off-by: Sebastian Kemper sebastian...@gmx.net Applied with a slightly modified commit message. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [v2][ar71xx] Add support for Netgear WNR2200 wireless router
2013.09.13. 12:55 keltezéssel, Dirk Neukirchen írta: On 01.09.2013 20:14, Gabor Juhos wrote: Yes, it is necessary. The coding style of the mach-wnr2200.c file is horrible: Additionally, a board specific patch is missing from 'target/linux/ar71xx/patches-3.10'. Thanks, Gabor I didn't have time earlier but here is v2. checkpatch warns about line length on 2 occasions but I don't think that breaking that line is really necessary I don't have a WNR2200 so I cannot test but it compiles. Some gpio is from dd-wrt but i left that commented out Changes: - fixed comments - fixed indentation - WNR220_GPIO_USB_POWER - WNR2200_GPIO_USB_POWER - add linux/gpio.h dependency - comment out gpio stuff from dd-wrt for now Signed-off-by: Dirk Neukirchen dirkneukirc...@web.de Applied with some changes. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [v2][ar71xx] Add support for Netgear WNR2200 wireless router
2013.09.19. 19:26 keltezéssel, Roman A. aka BasicXP írta: There are some small mistakes I found: 1) target/linux/ar71xx/base-files/etc/diag.sh, line 179 Shouldn't the LED be green instead of the amber one? In other devices it is. It would be more consistent but I don't really care. 2) target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2200.c, line 95 Typo, it says anber, should be amber Fixed in r38062. -Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [ar71xx] add support for TP-Link TL-MR13U
2013.09.17. 2:45 keltezéssel, Oleg Titov írta: This patch adds support for TP-Link TL-MR13U router with built-in 10AH rechargeable battery. The patch is based on kamwanlai's patch: https://forum.openwrt.org/viewtopic.php?pid=206746#p206746 Updated to accommodate recent changes introduced with: ar71xx: remove fs_* variables from image/Makefile Signed-off-by: Oleg Titov oleg.ti...@gmail.com Applied with some small changes. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SoC NAND driver ar934x/OpenWRT support on WNDR4300
2013.09.14. 13:00 keltezéssel, Joris írta: Hello list, I posted an initial, quite horrible, patch to the forums to try and get the WNDR4300 working. I am not that experienced in either posting to lists or embedded development, so please do inform me of any mistakes I may have made. If that is the problem, swapping must be enabled in the ar934x-nfc driver as well by an 'ath79_nfc_set_swap_dma(true)' call before ath79_register_nfc(). See the mach-rb2011.c file [1] for example. That is good to know and probably quite quick to test (which is easy for me to say as I have not found the courage yet to solder a serial connection). IMHO, the optimal solution would be the following: Add direct support to squashfs in order to be able to use that on top of plain UBI volumes. Create two UBI volumes and use squashfs on the first and UBIFS on the second volume. This would be much cleaner solution than the 'ubi-gluebi-mtdblock-squashfs' combination. It would indeed be a cleaner solution, however I gather from [2] that performance differences are minimal. Furthermore, direct support for UBI-SquashFS is not in mainline, according to [5], and the latest proposed patch I could find went AWOL after someone gave comments [6]. The referred solution also uses an intermediate layer. Under direct support I mean that the the squashfs code should be extended, in order to able to use an UBI volume directly without any intermediate layer. Looking at the current layout [7], I think an initial solution would be to use mtd8 'rootfs' as single UBI volume and layering SquashFS on top via gluebi and mtdblock_ro. Of course, if the amount of work is comparable for direct versus gluebi, the direct scenario makes more sense. For the gluebi based solution, every component is available in the mainline kernel so this would be the simplest way. However, I still don't like the complexity of it. For 'ubi-ubiblk-squashfs' patches are also available on various mailing lists but those must be actualized for the current kernel probably. It seems that this is the last version of the patch: http://lists.infradead.org/pipermail/linux-mtd/2012-December/045274.html For the direct solution, there are no public patches available. For the overlay, we could use the existing mtd12 'reserved' (for what, I wonder) as JFFS2 since that already includes bad block management. Using mtd12 would have the added advantage of providing a _huge_ amount of storage, while keeping the original layout of the flash, so it should be easy to revert to stock that way. One other thing which bothers me: U-Boot checks the rootfs CRC. If these FS are on the same UBI volume, doesn't get NAND pages of the whole MTD changed (wear leveling?) No AFAIK. The UBI layer only uses the erase sectors of a given UBI volume for wear leveling. So _if_ one UBI volume was used this would be true, but since your proposal includes two UBI volumes, it works around the CRC check, right? Yes, in theory. Although I don't exactly know which part of the rootfs partition is covered by the CRC value. -Gabor Joris 1. https://dev.openwrt.org/browser/trunk/target/linux/ar71xx/files/arch/mips/ath79/mach-rb2011.c#L235 2. http://elinux.org/Flash_Filesystem_Benchmarks 3. http://lists.infradead.org/pipermail/linux-mtd/2013-February/045794.html 4. https://dev.openwrt.org/browser/trunk/target/linux/ar71xx/image/Makefile#L63 5. http://elinux.org/Flash_Filesystem_Benchmarks_Protocol#Tested_filesystems 6. https://lkml.org/lkml/2011/10/1/51 7. http://wiki.openwrt.org/toh/netgear/wndr4300#visual.representation ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SoC NAND driver ar934x/OpenWRT support on WNDR4300
2013.09.16. 1:06 keltezéssel, Stefan Agner írta: Hi Gabor, [resend, forgot mailing list in to list] In the early reference driver of the NAND controller, the data from the DMA has been swapped. On later reference drivers, this swapping has been removed. To match with the reference driver, the current ar934x-nfc driver does not swaps the data by default. If U-Boot on the WNDR4300 swaps the data then that can cause ECC errors in all NAND pages. If that is the problem, swapping must be enabled in the ar934x-nfc driver as well by an 'ath79_nfc_set_swap_dma(true)' call before ath79_register_nfc(). See the mach-rb2011.c file [1] for example. I enabled this swapping, but without luck. Still can't mount filesystems flashed using U-boot. I guess that Netgears driver somehow uses the EC header differently (is this done in software?)Currently, I need to boot initramfs to flash/create root filesystems. But this has alsoadvantages, since I can use all those UBI utilities... It is done in software in the ar934x-nfc driver. The NAND controller of the AR934x SoCs also supports hardware based ECC calculation but that is not yet implemented in the driver. The hardware based ECC might use a different OOB layout and that would cause similar problems if thas is enabled in the bootloader. I guess that it would be easy to figure out if the bootloader uses a different OOB layout or not. 1. Flash an image from U-Boot. 2. Boot an initramfs based image, and read the image back via the 'nanddump' utility including the OOB data. 3. Write the same image to the same partition from the initramfs based kernel. 4. Dump it again and check what is the difference in the OOB data between the two. UBI/squahsfs should be working, at least it has been tested by Free Electrons [2] on older kernels. In my opinion, it makes no sense to use JFFS2 on an UBI volume. That would complicate things with no good reason. For JFFS2, two immediate layers are needed in order to make it work on UBI volumes whereas UBIFS can work directly on that. Agree IMHO, the optimal solution would be the following: Add direct support to squashfs in order to be able to use that on top of plain UBI volumes. Create two UBI volumes and use squashfs on the first and UBIFS on the second volume. This would be much cleaner solution than the 'ubi-gluebi-mtdblock-squashfs' combination. I'm going to try squashfs on UBI. I see that Free Electrons refers with squashfs-ubiblk to that combination. As far as I can see, it should be easy as referring to the UBI volume as root device (e.g. /dev/ubiblk0_0). One other thing which bothers me: U-Boot checks the rootfs CRC. If these FS are on the same UBI volume, doesn't get NAND pages of the whole MTD changed (wear leveling?) No AFAIK. The UBI layer only uses the erase sectors of a given UBI volume for wear leveling. Hm, but this would still change CRC, wouldn't it? IIRC, wear leveling is not used on static (read-only ) UBI volumes, but I'm unsure about that. The kernel command line is fixed in U-Boot, so we would have to generate an image with fixed (e.g. CONFIG_CMDLINE_OVERRIDE=y) cmdline. Any other idea? Is this the first Netgear target which encounters this problem? We are using the patch-cmdline tool to inject a board specific command line into the kernel for almost all boards [4]. Ok ic. As far as I see theres no root= configuration injected. Does the kernel has some hard coded defaults? The kernel automatically sets the rootfs partition to be the root filesystem if the 'CONFIG_MTD_ROOTFS_ROOT_DEV' option is set. -Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] AA backport request: r34577 ar71xx: TP-LINK also has a family TL-WDR
2013.09.17. 8:07 keltezéssel, Matthias Schiffer írta: Hi, can r34577 be backported to the Attitude Adjustment branch? We're currently working on an automated update system for our AA-based firmware, and without this patch TL-WDR models aren't recognized correctly. Done: https://dev.openwrt.org/changeset/38012 -Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SoC NAND driver ar934x/OpenWRT support on WNDR4300
Hi Stefan, In between I found out that the driver works fine if I erase/write the NAND first using the driver itself. But when I try to flash something using the stock U-Boot bootloader, the driver still complains as outlined in my first message. Right now I have a running kernel and root filesystem generated using git master. I generated these files by altering the ar71xx generic subtarget (included UBIFS, NAND driver etc.) I then flashed the kernel using stock U-Boot. To flash the root fs I used the already working initramfs and generated the UBI volume by hand, then used ubiupdatevol to write the generated *.ubifs image. Due to manual flashing, the default boot commands don't work since magics and CRCs are wrong. Beside that, there is no overlay right now, I have a read/writeable root fs. My goal is to generate a easily flashable (TFTP recovery or whatever) image for this router. Since I'm new to OpenWRT development I might be wrong with all this, so please help me/correct me... When the image is written by U-Boot, the rootfs won't be readable by the ar934x kernel driver (my initial problem). Any idea how to work around this? In the early reference driver of the NAND controller, the data from the DMA has been swapped. On later reference drivers, this swapping has been removed. To match with the reference driver, the current ar934x-nfc driver does not swaps the data by default. If U-Boot on the WNDR4300 swaps the data then that can cause ECC errors in all NAND pages. If that is the problem, swapping must be enabled in the ar934x-nfc driver as well by an 'ath79_nfc_set_swap_dma(true)' call before ath79_register_nfc(). See the mach-rb2011.c file [1] for example. If this does not help, then I have no idea what causes the read failures. As far as I can see, there is only xburst which _use_ UBIFS right now. The ar71xx/nand target use YAFFS2 (at least this is what the kernel has included). The question is, should I include UBIFS to the NAND subtarget and transfer this device to this subtarget? Or should I create a new target (so there would be three generic = squashfs/jffs2, nand = YAFFS2, ubi = ubi/ubifs). The nand subtarget is mainly for Mikrotik devices. Those needs yaffs2 support in order to keep it compatible with RouterBOOT. The yaffs2 fs will not be used for other boards so a separate subtarget would be better. Which is the NAND fs combination for OpenWRT in future anyway? I see following combinations (rootfs/rootfs_data): - UBI/squashfs, UBI/JFFS2 (using gluebi, stacking of FS, are these tested and working combinations? Too complicated?) UBI/squahsfs should be working, at least it has been tested by Free Electrons [2] on older kernels. In my opinion, it makes no sense to use JFFS2 on an UBI volume. That would complicate things with no good reason. For JFFS2, two immediate layers are needed in order to make it work on UBI volumes whereas UBIFS can work directly on that. - UBI/UBIFS(ro), UBI/UBIFS (I read that UBIFS doesnt allow to be a overlayfs since it lacks whiteout feature.. Is this true?) It is true for ubifs in mainline linux kernels. Overlayfs relies on symlink xattr support which is not present in mailine yet. We have a experimental patch for that in OpenWrt (see 550-ubifs-symlink-xattr-support.patch in target/linux/generic/patches-*). A more complete patchset has been posted to the linux-mtd list a few months ago [3], but i don't know the actual status of those patches. Additionally, there is a minor problem using UBIFS for the read only part. The resulting ubifs image is much larger than a corresponding squashfs image even if xz compression is used in ubifs. It is not a big problem because NAND flashes are usually larger than the generally used 4/8/16MB NOR flashes but it simply wastes space. IMHO, the optimal solution would be the following: Add direct support to squashfs in order to be able to use that on top of plain UBI volumes. Create two UBI volumes and use squashfs on the first and UBIFS on the second volume. This would be much cleaner solution than the 'ubi-gluebi-mtdblock-squashfs' combination. One other thing which bothers me: U-Boot checks the rootfs CRC. If these FS are on the same UBI volume, doesn't get NAND pages of the whole MTD changed (wear leveling?) No AFAIK. The UBI layer only uses the erase sectors of a given UBI volume for wear leveling. The kernel command line is fixed in U-Boot, so we would have to generate an image with fixed (e.g. CONFIG_CMDLINE_OVERRIDE=y) cmdline. Any other idea? Is this the first Netgear target which encounters this problem? We are using the patch-cmdline tool to inject a board specific command line into the kernel for almost all boards [4]. Or maybe go straight forward and just wipe the whole device, flash a U-Boot without integrity checks, use the whole NAND... (would be a one way thing... is there a solution where user can do this without opening the device..) I don't want
Re: [OpenWrt-Devel] [PATCH] ar71xx: add support for TL-MR3040 v2 (correction)
2013.09.12. 23:17 keltezéssel, Mads Hansen írta: Changed two instances of TL-MR3040 to TL-MR3040-v1 and TL-MR3040-v2, respectively. The kernel uses the 'TL-MR3040' string to identify the board. I bet on that the resulting image won't work with this change. -Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [ar71xx] add wireless bgn led support for dir-825-c1
2013.09.13. 12:33 keltezéssel, Sebastian Kemper írta: Hello list, I checked the GPL code drop from D-Link and tried to get the wireless and LAN switch LEDs to light up. I found some references in AthSDK/www/DIR-825_C1/bsp.h as well as AthSDK/www/DIR-825_C1/rootfs/etc/sysconfig/S2gpio.sh, but in the end I only got the led for 2.4GHz to work. Anyway, here's the patch. Signed-off-by: Sebastian Kemper sebastian...@gmx.net Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: add support for TL-MR3040 v2
2013.09.12. 15:03 keltezéssel, Mads Hansen írta: This patch adds support for building firmware images for the TP-Link TL-MR3040 v2. Tested and working on v2.1 hardware. Signed-off-by: Mads Hansen d...@taba.se Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: make failsafe for TL-WR720N-v3 work on port labelled as LAN.
2013.08.31. 10:16 keltezéssel, Yousong Zhou írta: Failsafe listens on eth0 by default, but due to the order of eth registration eth0 previously corresponded to the port labelled as WAN. This may cause some inconvenience since people have to plug the cable out from LAN into WAN when accessing failsafe mode and then plug back when recovery is done. Signed-off-by: Yousong Zhou yszhou4t...@gmail.com --- A previous version of this patch [1] has been sent but was not receiving any response and now can not be applied without conflict. [1] http://patchwork.openwrt.org/patch/3765/ .../ar71xx/base-files/etc/uci-defaults/02_network |1 - .../files/arch/mips/ath79/mach-tl-wr720n-v3.c |2 +- 2 files changed, 1 insertions(+), 2 deletions(-) diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network index 176c485..482ad6b 100755 --- a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network @@ -234,7 +234,6 @@ pb42 |\ pb44 |\ routerstation|\ tl-wr710n |\ -tl-wr720n-v3|\ wpe72) ucidef_set_interfaces_lan_wan eth1 eth0 ;; diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wr720n-v3.c b/target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wr720n-v3.c index 80e8df6..71d18d2 100644 --- a/target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wr720n-v3.c +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wr720n-v3.c @@ -98,8 +98,8 @@ static void __init tl_wr720n_v3_setup(void) ath79_init_mac(ath79_eth1_data.mac_addr, mac, 2); ath79_register_mdio(0, 0x0); - ath79_register_eth(0); ath79_register_eth(1); + ath79_register_eth(0); ath79_register_wmac(ee, mac); } Swapping the registration order would cause problems for existing users. If someone upgrades from a previous version of OpenWrt and keeps the existing configuration then ethernet will be broken on that board. This should be resolved in user-space rather than in the kernel. -Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [x86] alix2: update to LINUX_VERSION 3.10.9
2013.08.23. 7:10 keltezéssel, Russell Senior írta: Initial whack at updating alix2 to a current kernel. It builds and runs without problems so far. I copied target/linux/config-3.8, target/linux/x86/alix2/config-3.8, and target/linux/patches-3.8 to their 3.10 equivalents and tweaked until it built. The patches required no changes. Signed-off-by: Russell Senior russ...@personaltelco.net Applied with minor changes. Thanks, GAbor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v3] [package] spi-gpio-custom: create custom SPI devices via GPIO lines
2013.08.29. 11:23 keltezéssel, Marco Burato írta: This module is based on i2c-gpio-custom and allows to configure an SPI bus via GPIO lines and expose it to userspace without rebuilding the kernel. This is maily intended to connect microcontrollers and other simple SPI devices without making an ad-hoc kernel driver. Signed-off-by: Marco Burato zmaster.a...@gmail.com Applied with minor changes. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [ar71xx] [kernel] Configure OBS4 line on TL-WR841N-v8/MR3420v2 its also fixes USB Power on MR3420v2 at last
2013.09.02. 15:00 keltezéssel, Dmytro írta: This time we took the information from the source of GPL: http://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg18970.html Confirmed and tested: https://dev.openwrt.org/ticket/13201#comment:41 Thanks to oguretsagressive for testing. Signed-off-by: Dmytro dioptimi...@gmail.com Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Add RouterBOARD 951Ui-2HnD Support
2013.08.29. 0:11 keltezéssel, David Hutchison írta: This patch enables OpenWRT to be ran on the RouterBOARD 951Ui-2HnD. GPIO 2 enables or disables the POE on port 5. By default we enable GPIO2. GPIO 20 controls the USB Power, by default it enables the USB port. Attached is 624-MIPS-ath79-RB951u-support.patch Signed-off-by: Davey Hutchison dhutchi...@bluemesh.net --- target/linux/ar71xx/files/arch/mips/ath79/mach-rb95x.c +++ target/linux/ar71xx/files/arch/mips/ath79/mach-rb95x.c Please use strip level 1 for the patches. The current form fails with 'git am': $ wget http://patchwork.openwrt.org/patch/4017/mbox/ -O - | git am ... Applying: Add RouterBOARD 951Ui-2HnD Support error: linux/ar71xx/files/arch/mips/ath79/mach-rb95x.c: does not exist in index Patch failed at 0001 Add RouterBOARD 951Ui-2HnD Support When you have resolved this problem run git am --resolved. If you would prefer to skip this patch, instead run git am --skip. To restore the original branch and stop patching run git am --abort. $ git am --abort Additionally the whitespaces are corrupted in the patch, so it is not working even with 'git am -p0': $ wget http://patchwork.openwrt.org/patch/4017/mbox/ -O - | git am -p0 ... Applying: Add RouterBOARD 951Ui-2HnD Support error: patch failed: target/linux/ar71xx/files/arch/mips/ath79/mach-rb95x.c:37 error: target/linux/ar71xx/files/arch/mips/ath79/mach-rb95x.c: patch does not apply Patch failed at 0001 Add RouterBOARD 951Ui-2HnD Support When you have resolved this problem run git am --resolved. If you would prefer to skip this patch, instead run git am --skip. To restore the original branch and stop patching run git am --abort. $ git am --abort Quilt fails as well: $ wget http://patchwork.openwrt.org/patch/4017/mbox/ -O 4017.patch quilt import -p0 4017.patch quilt push ... 2013-09-01 14:48:41 (13.6 KB/s) - `4017.patch' saved [3898] Importing patch 4017.patch (stored as patches/4017.patch) Applying patch patches/4017.patch patching file target/linux/ar71xx/files/arch/mips/ath79/mach-rb95x.c Hunk #1 succeeded at 37 with fuzz 2. Hunk #2 succeeded at 90 with fuzz 2. Hunk #3 FAILED at 245. 1 out of 3 hunks FAILED -- rejects in file target/linux/ar71xx/files/arch/mips/ath79/mach-rb95x.c Patch patches/4017.patch does not apply (enforce with -f) Please try again. Additionally, please put the '624-MIPS-ath79-RB951u-support.patch' into the patch. Thanks, GAbor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [ar71xx] Add support for Netgear WNR2200 wireless router
2013.09.01. 19:04 keltezéssel, Dirk Neukirchen írta: On 01.09.2013 16:01, Gabor Juhos wrote: 2013.08.28. 13:48 keltezéssel, Aidan Kissane írta: This patch adds OpenWRT support for the Netgear WNR2200 (N300) wireless router with USB. Technical details of this router can be found at http://www.netgear.com/home/products/wirelessrouters/work-and-play/WNR2200.aspx and http://wikidevi.com/wiki/Netgear_WNR2200 The patch includes a new ar71xx/files/arch/mips/ath79/mach-wnr2200.c file and corresponding updates to the base-files/etc/diag.sh, base-files/etc/uci-defaults/02_network, ar71xx/base-files/lib/ar71xx.sh, ar71xx/config-3.10, ar71xx/generic/profiles/netgear.mk and ar71xx/image/Makefile files. Signed-off-by: Aidan Kissane aidankissane at googlemail.com Sorry, the patch is still corrupted like the previous version. -Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel Not original submitter but I had some problems with badly formatting too - its just difficult to fix with standard mail clients like thunderbird because of those hidden options TB: http://kb.mozillazine.org/Plain_text_e-mail_%28Thunderbird%29#Completely_Plain_Email nevertheless the following patch applies Indeed, it does apply now. (dunno if next is necessary for reformatting) Yes, it is necessary. The coding style of the mach-wnr2200.c file is horrible: [juhosg@mag2 openwrt (wnr2200)]$ ./scripts/checkpatch.pl -f target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2200.c --terse target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2200.c:24: ERROR: do not use C99 // comments target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2200.c:41: ERROR: do not use C99 // comments target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2200.c:42: ERROR: do not use C99 // comments ... target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2200.c:164: ERROR: code indent should use tabs where possible target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2200.c:164: WARNING: please, no spaces at the start of a line target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2200.c:166: ERROR: code indent should use tabs where possible target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2200.c:166: WARNING: please, no spaces at the start of a line total: 96 errors, 72 warnings, 170 lines checked [juhosg@mag2 openwrt (wnr2200)]$ Additionally, a board specific patch is missing from 'target/linux/ar71xx/patches-3.10'. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Add RouterBOARD 951Ui-2HnD Support
2013.08.28. 7:46 keltezéssel, Вячеслав Адаманов írta: Gabor Juhos, tell me, is it possible to port RB / SXT 2nDr2 Lite 2? Or are have any of the nuances for which it can not or imposible. Although I don't know the hardware details of the SXT Lite boards but it should be possible. -Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx Fix of mach file for WNDAP360, removed register USB device
2013.08.26. 14:57 keltezéssel, Jacek Kikiewicz írta: Resending to group as this didn't get to patchwork... Because the patch was damaged by your mail-client, which is true for this version as well... Removing one line in mach-wldap360.c Apparently registering usb device on newest trunk causes this AP not to boot... Since there is no USB socket in that device anyway this can be simply removed (and device boots then no problem). Signed-off-by: Jacek Kikiewicz ja...@aol.pl Despite the whitespace/long-line issues, I have applied the patch because it was simple enough. However please fix your mail-client or use a different one for sending patches next time. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [ar71xx] Add support for Netgear WNR2200 wireless router
2013.08.23. 16:08 keltezéssel, Aidan Kissane írta: This patch adds OpenWRT support for the Netgear WNR2200 (N300) wireless router with USB. Technical details of this router can be found at http://www.netgear.com/home/products/wirelessrouters/work-and-play/WNR2200.aspx and http://wikidevi.com/wiki/Netgear_WNR2200 The patch includes a new ar71xx/files/arch/mips/ath79/mach-wnr2200.c file and corresponding updates to the base-files/etc/diag.sh, base-files/etc/uci-defaults/02_network, ar71xx/base-files/lib/ar71xx.sh, ar71xx/config-3.10, ar71xx/generic/profiles/netgear.mk and ar71xx/image/Makefile files Signed-off-by: Aidan Kissane aidankiss...@googlemail.com The patch is broken: $ wget http://patchwork.openwrt.org/patch/3972/mbox/ -O - | git am -s --2013-08-27 13:17:36-- http://patchwork.openwrt.org/patch/3972/mbox/ Resolving patchwork.openwrt.org (patchwork.openwrt.org)... 188.40.166.11 Connecting to patchwork.openwrt.org (patchwork.openwrt.org)|188.40.166.11|:80... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/plain] Saving to: `STDOUT' [ = ] 12,774 15.4K/s in 0.8s 2013-08-27 13:17:56 (15.4 KB/s) - written to stdout [12774] Applying: Add support for Netgear WNR2200 wireless router fatal: corrupt patch at line 281 Patch failed at 0001 Add support for Netgear WNR2200 wireless router When you have resolved this problem run git am --resolved. If you would prefer to skip this patch, instead run git am --skip. To restore the original branch and stop patching run git am --abort. $ Please fix you mail-client or use a different one. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Add RouterBOARD 951Ui-2HnD Support
2013.08.26. 21:31 keltezéssel, Vasilis Tsiligiannis írta: Στις Δευ 26 Αυγ 2013 11:02:54 David Hutchison έγραψε: This patch enables OpenWRT to be ran on the RouterBOARD 951Ui-2HnD. GPIO 2 enables or disables the POE on port 5. By default we enable GPIO2. GPIO 20 controls the USB Power, by default it enables the USB port. GPIO 20 is also exposed on the RouterBOARD 951G if anyone was curious. I did not include that in this patch. I need some assistance creating a proper patch for the RouterBOARD 951U. I have the RouterBOARD 951U working, and will include all of the code necessary. ... I think you might have some whitespace or formatting errors above + +rb95x_wlan_init(); +ath79_register_usb(); + + ath79_register_leds_gpio(-1, ARRAY_SIZE(rb951ui_leds_gpio), + rb951ui_leds_gpio); +} + +MIPS_MACHINE(ATH79_MACH_RB_951U, 951HnD, MikroTik RouterBOARD 951Ui-2HnD, + rb951ui_setup); Here is the part I am confused on. There are two files machtypes.h and prom.c. We need to add ATH79_MACH_RB_951U to machtypes.h. I'm not sure where in the target directory machtypes.h is. It appears that both files are managed by a *.patch file in the patches directory. Does the PATCH submitted need to be a patch of a patch file? or a new patch? Should target/linux/ar71xx/ath79/patches/610-MIPS-ath79-openwrt-machines.patch be modified, or add a 612-MIPS-ath79-openwrt-rb951u.patch ? I beleive it should be a patch of 610-MIPS-ath79-openwrt-machines.patch I prefer to have a separate patch (62*-) for that. It is much easier to resolve conflicts that way. -Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] TEW632BRP has buttons 'active low', fix board config.
2013.07.18. 18:27 keltezéssel, Nikolay Martynov írta: Looks like trunk@37090 has changed the logic that determines if router's button was pressed. This resulted in TEW632BRP always booting into failsafe mode because it detected pressed button (which was not pressed). Measure with voltmeter has shown that buttons on this router are actually active-low. This patch reflects this fact in board configuration and fixes 'load info failsafe mode' issue. Note: it looks like Trendnet TEW632BRP and a close relative to TEW-652BRP V1.0 and D-Link DIR-615C1, so same problem may exist on those routers as well. This patch doesn't affect routers other than 632BRP and unfortunately I do not have hardware to test this issue with other routers. This patch fixes #13893 and is tested on actuall Trendnet TEW632BRP. Signed-off-by: Nikolay Martynov mar.ko...@gmail.com Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [ar71xx] extended support for TP-Link TL-MR10U in trunk
2013.07.23. 0:59 keltezéssel, Oleg Titov írta: Extended support for TP-Link TL-MR10U in Buildroot added. Supports current trunk. Based on andelf's patch http://andelf.diandian.com/post/2013-05-22/40050677370 Signed-off-by: Oleg Titov oleg.ti...@gmail.com Applied with some changes. However I had to apply the changes manually, because the whitespaces in the patch were damaged. Please verify that I did not make a mistake. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: add TP-LINK TL-WR941N v6 support
2013.05.29. 4:40 keltezéssel, Andelf írta: TL-WR941N v6 use almost same IC as WDR3500. Signed-off-by: ShuYu Wang and...@gmail.com Applied with minor changes. Thanks! -Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Add support for WIFI button on tp-link tl-mr3220v2
2013.06.01. 22:34 keltezéssel, Vittorio G (VittGam) írta: Hi, The TP-LINK TL-MR3220 v2 has a button on the left side labeled WIFI. This is GPIO 24. This patch adds the support for this button. Signed-off-by: Vittorio Gambaletta open...@vittgam.net Applied, thanks. -Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: add TP-LINK TL-MR10U
2013.05.16. 12:44 keltezéssel, Cezary Jackiewicz írta: Small router with 4MB flash, 32MB RAM http://www.tp-link.com.cn/product_300.html Signed-off-by: Cezary Jackiewicz cezary.jackiew...@gmail.com Applied, thanks. -Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Fix TL-MR10U usb power
2013.05.26. 18:21 keltezéssel, Cezary Jackiewicz írta: MR10U is closer to MR3040 than WR703N. This changes also enable USB power on GPIO18. Signed-off-by: Cezary Jackiewicz cezary.jackiew...@gmail.com Applied, thanks. -Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Typo in detect TL-MR10U/TL-MR11U
2013.05.26. 18:23 keltezéssel, Cezary Jackiewicz írta: At offset 0x40, signature for TL-MR10U/TL-MR11U begin from 0x00, not 0x10/0x11. Signed-off-by: Cezary Jackiewicz cezary.jackiew...@gmail.com Applied, thanks. -Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: set eth0 mac address to match bottom label of the OM2P LC
2013.05.23. 21:34 keltezéssel, lindner_ma...@yahoo.de írta: Signed-off-by: ma...@open-mesh.com CC: Gabor Juhos juh...@openwrt.org Applied, thanks. -Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: Fix AP135 partition layout
2013.05.07. 9:55 keltezéssel, Sujith Manoharan írta: From: Sujith Manoharan c_man...@qca.qualcomm.com Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: Fix AP135 PCI
2013.05.02. 11:12 keltezéssel, Sujith Manoharan írta: From: Sujith Manoharan c_man...@qca.qualcomm.com AP135 has a pluggable PCIE slot unlike AP136. Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [ar71xx] Add description for -W option into usage output of mktplinkfw
2013.04.29. 7:05 keltezéssel, Yousong Zhou írta: Add description for -W hwrev option into usage output of mktplinkfw. Signed-off-by: yousongyszhou4t...@gmail.com --- I came across this when reading target/linux/ar71xx/image/Makefile and could not find what -W was for. This is a small patch tries to help make the project better. ;) Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [ar71xx] Two 617- numbered patches exist in target/linux/ar71xx/patches-3.8/ directory
2013.04.29. 6:46 keltezéssel, Yousong Zhou írta: Update the numbering of kernel patch for supporting Netgear WNR2000v3 from 617 to 618. Signed-off-by: yousong yszhou4t...@gmail.com --- The patch was broken, but I have applied it manually. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
