[OpenWrt-Devel] [PATCH] support for unbranded XDX-RN502J ralink board
This patch adds support for routers using a PCB marked XDX-RN502J
V2.0, such as some unbranded routers like this:
http://www.mediafire.com/?8acv87h6snn9fj6
http://www.mediafire.com/?do7xonw7scor4kn
http://www.mediafire.com/?1ad49zvx3e7jyix
http://www.mediafire.com/?i46cqiq66maa197
http://www.aliexpress.com/product-fm/516397994-Free-Shipping-300M-3G-WAN-Wireless-N-WiFi-USB-AP-Router-2-Antennas-wholesalers.html
some reports also state the Aceex 22Y uses the same board.
more information can be found in the following openwrt forum post
https://forum.openwrt.org/viewtopic.php?id=34878
the patch was made against OpenWrt svn rev 30708
Signed-off-by: bruno schwander
Index: target/linux/ramips/files/arch/mips/ralink/rt305x/Kconfig
===
--- target/linux/ramips/files/arch/mips/ralink/rt305x/Kconfig (revision 30708)
+++ target/linux/ramips/files/arch/mips/ralink/rt305x/Kconfig (working copy)
@@ -116,6 +116,11 @@
select RALINK_DEV_GPIO_BUTTONS
select RALINK_DEV_GPIO_LEDS
+config RT305X_MACH_XDX_RN502J
+ bool "Unknown board XDX-RN502J"
+ select RALINK_DEV_GPIO_BUTTONS
+ select RALINK_DEV_GPIO_LEDS
+
endmenu
endif
Index: target/linux/ramips/files/arch/mips/ralink/rt305x/Makefile
===
--- target/linux/ramips/files/arch/mips/ralink/rt305x/Makefile (revision 30708)
+++ target/linux/ramips/files/arch/mips/ralink/rt305x/Makefile (working copy)
@@ -34,3 +34,4 @@
obj-$(CONFIG_RT305X_MACH_WL341V3) += mach-wl341v3.o
obj-$(CONFIG_RT305X_MACH_WL351)+= mach-wl351.o
obj-$(CONFIG_RT305X_MACH_WR6202) += mach-wr6202.o
+obj-$(CONFIG_RT305X_MACH_XDX_RN502J)+= mach-xdx-rn502j.o
Index: target/linux/ramips/files/arch/mips/ralink/rt305x/mach-xdx-rn502j.c
===
--- target/linux/ramips/files/arch/mips/ralink/rt305x/mach-xdx-rn502j.c
(revision 0)
+++ target/linux/ramips/files/arch/mips/ralink/rt305x/mach-xdx-rn502j.c
(revision 0)
@@ -0,0 +1,79 @@
+/*
+ * Unknown router name/model, PCB marked with XDX-RN502J
+ *
+ * Copyright (C) 2011 Bruno Schwander br...@tinkerbox.org
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include "devices.h"
+
+#define XDXRN502J_GPIO_BUTTON_RESET12
+#define XDXRN502J_GPIO_LED_WIFI7
+#define XDXRN502J_GPIO_LED_POWER 9
+
+#define XDXRN502J_BUTTONS_POLL_INTERVAL20
+#define XDXRN502J_BUTTONS_DEBOUNCE_INTERVAL (3 *
XDXRN502J_BUTTONS_POLL_INTERVAL)
+
+
+static struct gpio_led xdxrn502j_leds_gpio[] __initdata = {
+ {
+ .name = "xdxrn502j:green:wifi",
+ .gpio = XDXRN502J_GPIO_LED_WIFI,
+ .active_low = 1,
+ }, {
+ .name = "xdxrn502j:green:power",
+ .gpio = XDXRN502J_GPIO_LED_POWER,
+ .active_low = 1,
+ }
+};
+
+static struct gpio_keys_button xdxrn502j_gpio_buttons[] __initdata = {
+ {
+ .desc = "reset",
+ .type = EV_KEY,
+ .code = KEY_RESTART,
+ .debounce_interval = XDXRN502J_BUTTONS_DEBOUNCE_INTERVAL,
+ .gpio = XDXRN502J_GPIO_BUTTON_RESET,
+ .active_low = 1,
+ }
+};
+
+#define XDXRN502J_GPIO_MODE \
+ ((RT305X_GPIO_MODE_GPIO << RT305X_GPIO_MODE_UART0_SHIFT) | \
+RT305X_GPIO_MODE_MDIO)
+
+static void __init xdxrn502j_init(void)
+{
+ rt305x_gpio_init(XDXRN502J_GPIO_MODE);
+
+ rt305x_register_flash(0);
+
+rt305x_esw_data.vlan_config = RT305X_ESW_VLAN_CONFIG_W;
+ rt305x_register_ethernet();
+
+ ramips_register_gpio_leds(-1, ARRAY_SIZE(xdxrn502j_leds_gpio),
+ xdxrn502j_leds_gpio);
+
+ ramips_register_gpio_buttons(-1, XDXRN502J_BUTTONS_POLL_INTERVAL,
+ARRAY_SIZE(xdxrn502j_gpio_buttons),
+xdxrn502j_gpio_buttons);
+
+ rt305x_register_wifi();
+ rt305x_register_wdt();
+ rt305x_register_usb();
+}
+
+MIPS_MACHINE(RAMIPS_MACH_XDXRN502J, "XDXRN502J", "XDX RN502J",
+xdxrn502j_init);
Index: target/linux/ramips/files/arch/mips/include/asm/mach-ralink/machine.h
===
--- target/linux/ramips/files/arch/mips/include/asm/mach-ralink/machine.h
(revision 30708)
+++ target/linux/ramips/files/arch/mips/include/asm/mach-ralink/machine.h
(working copy)
@@ -48,6 +48,7 @@
RAMIPS_MACH_WL351, /* Sitecom WL-351 v1 002 */
RAMIPS_MACH_WR512_
Re: [OpenWrt-Devel] [PATCH] support for unbranded XDX-RN502J ralink board
That router is made by Win-star I believe, its sold to anyone and everyone.
On Sat, Feb 25, 2012 at 7:44 PM, bruno schwander wrote:
> This patch adds support for routers using a PCB marked XDX-RN502J
> V2.0, such as some unbranded routers like this:
>
> http://www.mediafire.com/?8acv87h6snn9fj6
> http://www.mediafire.com/?do7xonw7scor4kn
> http://www.mediafire.com/?1ad49zvx3e7jyix
> http://www.mediafire.com/?i46cqiq66maa197
>
>
> http://www.aliexpress.com/product-fm/516397994-Free-Shipping-300M-3G-WAN-Wireless-N-WiFi-USB-AP-Router-2-Antennas-wholesalers.html
>
> some reports also state the Aceex 22Y uses the same board.
>
> more information can be found in the following openwrt forum post
> https://forum.openwrt.org/viewtopic.php?id=34878
>
> the patch was made against OpenWrt svn rev 30708
>
> Signed-off-by: bruno schwander
>
>
>
> Index: target/linux/ramips/files/arch/mips/ralink/rt305x/Kconfig
> ===
> --- target/linux/ramips/files/arch/mips/ralink/rt305x/Kconfig (revision
> 30708)
> +++ target/linux/ramips/files/arch/mips/ralink/rt305x/Kconfig (working
> copy)
> @@ -116,6 +116,11 @@
>select RALINK_DEV_GPIO_BUTTONS
>select RALINK_DEV_GPIO_LEDS
>
> +config RT305X_MACH_XDX_RN502J
> + bool "Unknown board XDX-RN502J"
> + select RALINK_DEV_GPIO_BUTTONS
> + select RALINK_DEV_GPIO_LEDS
> +
> endmenu
>
> endif
> Index: target/linux/ramips/files/arch/mips/ralink/rt305x/Makefile
> ===
> --- target/linux/ramips/files/arch/mips/ralink/rt305x/Makefile (revision
> 30708)
> +++ target/linux/ramips/files/arch/mips/ralink/rt305x/Makefile (working
> copy)
> @@ -34,3 +34,4 @@
> obj-$(CONFIG_RT305X_MACH_WL341V3) += mach-wl341v3.o
> obj-$(CONFIG_RT305X_MACH_WL351)+= mach-wl351.o
> obj-$(CONFIG_RT305X_MACH_WR6202) += mach-wr6202.o
> +obj-$(CONFIG_RT305X_MACH_XDX_RN502J)+= mach-xdx-rn502j.o
> Index: target/linux/ramips/files/arch/mips/ralink/rt305x/mach-xdx-rn502j.c
> ===
> --- target/linux/ramips/files/arch/mips/ralink/rt305x/mach-xdx-rn502j.c
> (revision 0)
> +++ target/linux/ramips/files/arch/mips/ralink/rt305x/mach-xdx-rn502j.c
> (revision 0)
> @@ -0,0 +1,79 @@
> +/*
> + * Unknown router name/model, PCB marked with XDX-RN502J
> + *
> + * Copyright (C) 2011 Bruno Schwander br...@tinkerbox.org
> + *
> + * This program is free software; you can redistribute it and/or modify
> it
> + * under the terms of the GNU General Public License version 2 as
> published
> + * by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "devices.h"
> +
> +#define XDXRN502J_GPIO_BUTTON_RESET12
> +#define XDXRN502J_GPIO_LED_WIFI7
> +#define XDXRN502J_GPIO_LED_POWER 9
> +
> +#define XDXRN502J_BUTTONS_POLL_INTERVAL20
> +#define XDXRN502J_BUTTONS_DEBOUNCE_INTERVAL (3 *
> XDXRN502J_BUTTONS_POLL_INTERVAL)
> +
> +
> +static struct gpio_led xdxrn502j_leds_gpio[] __initdata = {
> + {
> + .name = "xdxrn502j:green:wifi",
> + .gpio = XDXRN502J_GPIO_LED_WIFI,
> + .active_low = 1,
> + }, {
> + .name = "xdxrn502j:green:power",
> + .gpio = XDXRN502J_GPIO_LED_POWER,
> + .active_low = 1,
> + }
> +};
> +
> +static struct gpio_keys_button xdxrn502j_gpio_buttons[] __initdata = {
> + {
> + .desc = "reset",
> + .type = EV_KEY,
> + .code = KEY_RESTART,
> + .debounce_interval = XDXRN502J_BUTTONS_DEBOUNCE_INTERVAL,
> + .gpio = XDXRN502J_GPIO_BUTTON_RESET,
> + .active_low = 1,
> + }
> +};
> +
> +#define XDXRN502J_GPIO_MODE \
> + ((RT305X_GPIO_MODE_GPIO << RT305X_GPIO_MODE_UART0_SHIFT) | \
> +RT305X_GPIO_MODE_MDIO)
> +
> +static void __init xdxrn502j_init(void)
> +{
> + rt305x_gpio_init(XDXRN502J_GPIO_MODE);
> +
> + rt305x_register_flash(0);
> +
> +rt305x_esw_data.vlan_config = RT305X_ESW_VLAN_CONFIG_W;
> + rt305x_register_ethernet();
> +
> + ramips_register_gpio_leds(-1, ARRAY_SIZE(xdxrn502j_leds_gpio),
> + xdxrn502j_leds_gpio);
> +
> + ramips_register_gpio_buttons(-1, XDXRN502J_BUTTONS_POLL_INTERVAL,
> +ARRAY_SIZE(xdxrn502j_gpio_buttons),
> +xdxrn502j_gpio_buttons);
> +
> + rt305x_register_wifi();
> + rt305x_register_wdt();
> + rt305x_register_usb();
> +}
> +
> +MIPS_MACHINE(RAMIPS_MACH_XDXRN502J, "XDXRN502J", "XDX RN502J",
> +xdxrn502j_init);
> Index:
> target/linux/ramips/files/arch/mips/include/
Re: [OpenWrt-Devel] [PATCH] Updated kernel patch in trunk to support brcm47xx BCMA NAND flash
Hi Tathagata Das,
I had a look at bthe patch and added some comments, if bcma_nflash_init
is not needed any more where is struct bcma_nflash initilized?
Hauke
On 02/23/2012 02:27 PM, Tathagata Das wrote:
> Hi,
> Attached is the updated kernel patch to support brcm47xx BCMA NAND flash. I
> have used latest trunk source code to create this patch.
> Thanks to Florian and Hauke for their comments.
>
> Regards,
> Tathagata
>
> diff -Naur a/arch/mips/bcm47xx/bus.c b/arch/mips/bcm47xx/bus.c
> --- a/arch/mips/bcm47xx/bus.c 2012-02-17 16:34:21.0 +0530
> +++ b/arch/mips/bcm47xx/bus.c 2012-02-23 18:22:17.0 +0530
> @@ -2,6 +2,7 @@
> * BCM947xx nvram variable access
> *
> * Copyright (C) 2011 Hauke Mehrtens
> + * Copyright (C) 2011-2012 Tathagata Das
> *
> * This program is free software; you can redistribute it and/or modify it
> * under the terms of the GNU General Public License as published by the
> @@ -92,3 +93,9 @@
> sflash->numblocks = scc->sflash.numblocks;
> sflash->size = scc->sflash.size;
> }
> +
> +void bcm47xx_nflash_struct_bcma_init(struct bcm47xx_nflash *nflash, struct
> bcma_drv_cc *bcc)
> +{
> + nflash->nflash_type = BCM47XX_BUS_TYPE_BCMA;
> + nflash->bcc = bcc;
> +}
> diff -Naur a/arch/mips/bcm47xx/nvram.c b/arch/mips/bcm47xx/nvram.c
> --- a/arch/mips/bcm47xx/nvram.c 2012-02-17 16:34:22.0 +0530
> +++ b/arch/mips/bcm47xx/nvram.c 2012-02-23 18:20:57.0 +0530
> @@ -4,6 +4,7 @@
> * Copyright (C) 2005 Broadcom Corporation
> * Copyright (C) 2006 Felix Fietkau
> * Copyright (C) 2010-2011 Hauke Mehrtens
> + * Copyright (C) 2011-2012 Tathagata Das
> *
> * This program is free software; you can redistribute it and/or modify it
> * under the terms of the GNU General Public License as published by the
> @@ -21,6 +22,7 @@
> #include
> #include
> #include
> +#include
>
> char nvram_buf[NVRAM_SPACE];
> EXPORT_SYMBOL(nvram_buf);
> @@ -159,6 +161,53 @@
> return 0;
> }
>
> +static int early_nvram_init_nflash(void)
> +{
> + struct nvram_header *header;
> + u32 off;
> + int ret;
> + int len;
> + u32 flash_size = bcm47xx_nflash.size;
> + u8 tmpbuf[NFL_SECTOR_SIZE];
> + int i;
> + u32 *src, *dst;
> +
> + /* check if the struct is already initilized */
> + if (!flash_size)
> + return -1;
> +
> + cfe_env = 0;
> +
> + off = FLASH_MIN;
> + while (off <= flash_size) {
> + ret = bcma_nflash_read(bcm47xx_nflash.bcc, off,
> NFL_SECTOR_SIZE, tmpbuf);
> + if (ret != NFL_SECTOR_SIZE) {
> + goto done;
> + }
> + header = (struct nvram_header *)tmpbuf;
> + if (header->magic == NVRAM_HEADER) {
> + goto found;
> + }
> + off <<= 1;
> + }
> +
> + ret = -1;
> + goto done;
> +
> +found:
> + len = header->len;
> + header = (struct nvram_header *) KSEG1ADDR(NAND_FLASH1 + off);
> + src = (u32 *) header;
> + dst = (u32 *) nvram_buf;
> + for (i = 0; i < sizeof(struct nvram_header); i += 4)
> + *dst++ = *src++;
> + for (; i < len && i < NVRAM_SPACE; i += 4)
> + *dst++ = *src++;
> + ret = 0;
> +done:
> + return ret;
> +}
> +
> static void early_nvram_init(void)
> {
> int err = 0;
> @@ -185,6 +234,10 @@
> err = early_nvram_init_sflash();
> if (err < 0)
> printk(KERN_WARNING "can not read from flash:
> %i\n", err);
> + } else if (bcm47xx_bus.bcma.bus.drv_cc.flash_type ==
> BCMA_NFLASH) {
> + err = early_nvram_init_nflash();
> + if (err < 0)
> + printk(KERN_WARNING "can not read from nflash:
> %i\n", err);
> } else {
> printk(KERN_WARNING "unknow flash type\n");
> }
I am not happy with the flash driver usage in arch/bcm47xx/ entirely and
will change it some time so I am ok with this.
> diff -Naur a/arch/mips/bcm47xx/setup.c b/arch/mips/bcm47xx/setup.c
> --- a/arch/mips/bcm47xx/setup.c 2012-02-17 16:34:22.0 +0530
> +++ b/arch/mips/bcm47xx/setup.c 2012-02-23 18:21:15.0 +0530
> @@ -4,6 +4,7 @@
> * Copyright (C) 2006 Michael Buesch
> * Copyright (C) 2010 Waldemar Brodkorb
> * Copyright (C) 2010-2011 Hauke Mehrtens
> + * Copyright (C) 2011-2012 Tathagata Das
> *
> * This program is free software; you can redistribute it and/or modify it
> * under the terms of the GNU General Public License as published by the
> @@ -47,6 +48,7 @@
> EXPORT_SYMBOL(bcm47xx_bus_type);
>
> struct bcm47xx_sflash bcm47xx_sflash;
> +struct bcm47xx_nflash bcm47xx_nflash;
>
> static void bcm47xx_machine_restart(char *command)
> {
> @@ -359,6 +361,9 @@
>
> if (bcm47xx_bus.bcma.bus.drv_cc.flash_type == BCMA_SFLASH)
>
Re: [OpenWrt-Devel] Ask a question related SDIO on Linux StarterKit with Ubiquiti RouterStation Pro on openwrt
hi peter! i see, which means you use gpio pins "J33" of rspro, right? And i saw your other email about asking of luci interface. http://luci.subsignal.org/trac here is toppage of luci and there is informations which describe how to create luci-pages and luci API. If you have more question about luci, you should join luci-devlist and ask there. i belive someone would answer your question. matsu 2012/2/24 peter.meng : > HI,Matsu > > Sorry for miss-describe before . > I just use gpio that implement mmc based on spi (spi bitbang gpio) , > this means i not use the GL827L . > I want to used this method to connect a wifi card since my sdio > controler doesn't ready currently . > > Thanks and Regards > Peter Meng > > 2012/2/24 Kentaro Matsuyama : >> Hello peter! >> >>> I just used dd command to test SD before and can mount it after add >>> "kmod-nls-cp437" >> Congratulation! If you don't mind, can you tell me how exactly to work SDIO? >> >>> I have a stupid question need you help again . >>> I use the kernel module gpiommc/spi_gpio_old/mmc_spi/mmc_block . >>> I see following explain from Linux kernel /Documentation/gpiommc.txt >>> As i understand these module provide the function that enable the SPI >>> mode of SDIO. >>> My question is how to use this to enable/configure the 1-bit and 4-bit >>> mode of SDIO ? >>> So If my sdio card doesn't support SPI mode of SDIO , it will doesn't >>> woks . right ? >> umm... I have no idea. >> Which card do you use? is that wifi sdio card? >> >> matsu >> >> (2012年02月24日 18:37), peter.meng wrote: >>> HI,Matsu >>> >>> Thank you very much . >>> I just used dd command to test SD before and can mount it after add >>> "kmod-nls-cp437" >>> >>> I have a stupid question need you help again . >>> I use the kernel module gpiommc/spi_gpio_old/mmc_spi/mmc_block . >>> I see following explain from Linux kernel /Documentation/gpiommc.txt >>> As i understand these module provide the function that enable the SPI >>> mode of SDIO. >>> My question is how to use this to enable/configure the 1-bit and 4-bit >>> mode of SDIO ? >>> So If my sdio card doesn't support SPI mode of SDIO , it will doesn't >>> woks . right ? >>> >>> >>> gpio_data_in= The SPI data-IN GPIO pin number. >>> gpio_data_out = The SPI data-OUT GPIO pin number. >>> gpio_clock = The SPI Clock GPIO pin number. >>> gpio_chipselect = The SPI Chipselect GPIO pin number. >>> >>> -my command >>> echo 1 > gpio_data_in >>> echo 2 > gpio_data_out >>> echo 3 > gpio_clock >>> echo 4 > gpio_chipselect >> >> 2012/2/24 peter.meng : >>> HI,Matsu >>> >>> Thank you very much . >>> I just used dd command to test SD before and can mount it after add >>> "kmod-nls-cp437" >>> >>> I have a stupid question need you help again . >>> I use the kernel module gpiommc/spi_gpio_old/mmc_spi/mmc_block . >>> I see following explain from Linux kernel /Documentation/gpiommc.txt >>> As i understand these module provide the function that enable the SPI >>> mode of SDIO. >>> My question is how to use this to enable/configure the 1-bit and 4-bit >>> mode of SDIO ? >>> So If my sdio card doesn't support SPI mode of SDIO , it will doesn't >>> woks . right ? >>> >>> >>> gpio_data_in= The SPI data-IN GPIO pin number. >>> gpio_data_out = The SPI data-OUT GPIO pin number. >>> gpio_clock = The SPI Clock GPIO pin number. >>> gpio_chipselect = The SPI Chipselect GPIO pin number. >>> >>> -my command >>> echo 1 > gpio_data_in >>> echo 2 > gpio_data_out >>> echo 3 > gpio_clock >>> echo 4 > gpio_chipselect >>> >>> >>> 2012/2/23 Kentaro Matsuyama : hello peter > I change the gpio with hardware engineer's help and SDIO(based on > gpio, not the GL827L) works currently . > But i can't mount it . > I can see following message when i plug an SD card . > > [ 243.86] mmc1: host does not support reading read-only switch. > assuming write-enable. > [ 243.87] mmc1: new SDHC card on SPI > [ 243.88] mmcblk0: mmc1: SD08G 7.42 GiB > [ 243.94] mmcblk0: p1 wow, great! Is that hardware hack? so now you can use SDIO device like wifi sdio card? that's very interesting... > mount -t vfat /dev/mmcblk0 /mnt > mount: mounting /dev/mmcblk0 on /mnt failed: No such device sorry, i forget to write "kmod-nls-cp437" in last email. I think that's why you can't mount. Good luck! matsu 2012/2/23 peter.meng : > HI，Matsu > > I change the gpio with hardware engineer's help and SDIO(based on > gpio, not the GL827L) works currently . > But i can't mount it . > I can see following message when i plug an SD card . > > [ 243.86] mmc1: host does not support reading read-only switch. > assuming write-enable. > [ 243.87] m
[OpenWrt-Devel] [PATCH] sysupgrade: try harder during an error
Remembering the old days, where we had floppy-drives?
Now we have MTD. sad but true, in case of any error during
sysupgrade regarding mtd, there are no further checks
and we are f*cked:
###
Performing system upgrade...
Unlocking linux ...
Writing from to linux ... [e]MTD do_erase_oneblock():
software
timeout
Failed to erase block
Upgrade completed
Rebooting system...
SQUASHFS error: lzma returned unexpected result 0x1
SQUASHFS error: Unable to read fragment cache block [933aa]
SQUASHFS error: Unable to read page, block 933aa, size 39b4
...
###
This patch does an infinite loop when an error occurs,
and will never go further until it works fine. if we will not
do this, we have an b0rken box anyway.
The above log from serial console shows that this case
can happen. this box works fine in our laboratory with
an 100 Euro power-supply without any problems.
(meaning: this is not a brick, was just a random mtd-error)
Some things to discuss:
* built 'verify'-option into mtd for fearful poeple
* does mtd really throws an exitcode != 0 in case of an error?
Signed-off-by: Bastian Bittorf
From c9d4e7a8c4f6befcc13e4dc329adb7c5646fee76 Mon Sep 17 00:00:00 2001
From: Bastian Bittorf
Date: Sat, 25 Feb 2012 15:56:02 +0100
Subject: [PATCH] sysupgrade/mtd: try to write in an infinite loop, still everything was fine
---
package/base-files/files/lib/upgrade/common.sh | 46
1 files changed, 31 insertions(+), 15 deletions(-)
diff --git a/package/base-files/files/lib/upgrade/common.sh b/package/base-files/files/lib/upgrade/common.sh
index e97958b..e8c1724 100644
--- a/package/base-files/files/lib/upgrade/common.sh
+++ b/package/base-files/files/lib/upgrade/common.sh
@@ -196,25 +196,41 @@ default_do_upgrade() {
do_upgrade() {
v "Performing system upgrade..."
- if type 'platform_do_upgrade' >/dev/null 2>/dev/null; then
- platform_do_upgrade "$ARGV"
- else
- default_do_upgrade "$ARGV"
- fi
- [ "$SAVE_CONFIG" -eq 1 -a -n "$USE_REFRESH" ] && {
- v "Refreshing partitions"
- if type 'platform_refresh_partitions' >/dev/null 2>/dev/null; then
- platform_refresh_partitions
+ while true; do
+ if type 'platform_do_upgrade' >/dev/null 2>/dev/null; then
+ platform_do_upgrade "$ARGV" && break
else
- refresh_mtd_partitions
- fi
- if type 'platform_copy_config' >/dev/null 2>/dev/null; then
- platform_copy_config
- else
- jffs2_copy_config
+ default_do_upgrade "$ARGV" && break
fi
+
+ v "do_upgrade failed, trying again"
+ done
+
+ [ "$SAVE_CONFIG" -eq 1 -a -n "$USE_REFRESH" ] && {
+ v "Refreshing partitions"
+
+ while true; do
+ if type 'platform_refresh_partitions' >/dev/null 2>/dev/null; then
+platform_refresh_partitions && break
+ else
+refresh_mtd_partitions && break
+ fi
+
+ v "refresh_partitions failed, trying again"
+ done
+
+ while true; do
+ if type 'platform_copy_config' >/dev/null 2>/dev/null; then
+platform_copy_config && break
+ else
+jffs2_copy_config && break
+ fi
+
+ v "copy_config failed, trying again"
+ done
}
+
v "Upgrade completed"
[ -n "$DELAY" ] && sleep "$DELAY"
ask_bool 1 "Reboot" && {
--
1.7.0.4___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] sysupgrade: try harder during an error
On 02/25/2012 07:13 AM, Bastian Bittorf wrote:
Remembering the old days, where we had floppy-drives?
Now we have MTD. sad but true, in case of any error during
sysupgrade regarding mtd, there are no further checks
and we are f*cked:
###
Performing system upgrade...
Unlocking linux ...
Writing from to linux ... [e]MTD do_erase_oneblock():
software
timeout
This has frustrated me too. I don't know what the root
cause is, but what I have seen is that the mtd utility
needs to retry sometimes, and that [e] condition
is a temporary "Out of memory" error. At least, on ar71xx.
Here's what I did:
Index: src/mtd.c
===
--- src/mtd.c (revision 30710)
+++ src/mtd.c (working copy)
@@ -462,16 +462,21 @@
if (!quiet)
fprintf(stderr, "\b\b\b[w]");
- if ((result = write(fd, buf + offset, buflen)) < buflen) {
- if (result < 0) {
- fprintf(stderr, "Error writing image.\n");
- exit(1);
- } else {
- fprintf(stderr, "Insufficient space.\n");
- exit(1);
- }
- }
- w += buflen;
+int try;
+for (try = 0; try < 3; try++) {
+ if ((result = write(fd, buf + offset, buflen)) < buflen) {
+if (result < 0) {
+ fprintf(stderr, "Error writing image: %s (try %d of 3).\n",
strerror(errno), try + 1);
+ if (try < 2) continue;
+ exit(1);
+} else {
+ fprintf(stderr, "Insufficient space.\n");
+ exit(1);
+}
+ }
+ w += buflen;
+ break;
+}
I have seen this fail once, twice, and then still succeed. But this
doesn't solve the root cause, and I think I'm still seeing complete
failures here on occasion. This just significantly mitigates it.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] sysupgrade: try harder during an error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. I think it should be handled in mtd, rewriting the complete image only because a single block had a transient erase problem is a bit excessive imo. It also means that sysupgrade would loop forever in case of a really fatal issue, like when the image is too large for the given mtd partition. I'd say the mtd util should perform 3-5 consecutive tries in case of a block erase problem and then finally exit with a non zero code to notify the caller about the problem. The exit code could convey the nature of the problem, e.g. erase issue or mtd too short; this would allow sysupgrade to take appropriate actions without brute-forcing the flash into death. ~ Jow -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9JErwACgkQdputYINPTPNlFgCeNaKCXiYIC+jxf2WhGxl7vAG8 988AnAzsUbpU14L5cXIBa3ESqSt3ymns =ouxM -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Alix 2D13 on latest trunk, traces in dmesg on bootup?
Does anyone else have any thoughts into this? Other suggestions I can
try? Seems someone else is seeing the same issue as I've found the
following output sitting on pastebin:
http://pastebin.com/djNfNa3t
These errors match the errors I'm seeing on my system exactly.
I've since reverted to trunk@29844 with a patch kicking it up to the
3.0.18 kernel and I don't see these errors. I went ahead and opened a
ticket on this for tracking purposes:
alix2 - trace messages in dmesg on bootup
https://dev.openwrt.org/ticket/11020
Thanks,
Adam
On 2/22/12 1:02 AM, Adam Gensler wrote:
Just build another one, this time with the following:
# target
CONFIG_TARGET_x86=y
CONFIG_TARGET_x86_alix2=y
CONFIG_DEVEL=y
CONFIG_TOOLCHAINOPTS=y
CONFIG_KERNEL_KALLSYMS=y
#CONFIG_KERNEL_DEBUG_KERNEL=y
#CONFIG_KERNEL_DEBUG_INFO=y
Boots fine, no traces showing up.
Not sure what that means exactly. Buts it's 100% reproducible on three
different alix boards with images from two different build machines.
Adam
On 2/22/12 12:50 AM, Philip Prindeville wrote:
Try leaving CONFIG_KERNEL_KALLSYMS and turn off CONFIG_KERNEL_DEBUG_* ...
On 2/21/12 10:34 PM, Adam Gensler wrote:
Hi Philip,
I suspected that might have been the problem so I did another build real
quick, but I removed your extra commands, and the problem returned in
that build.
So, I ran yet another build, this time, with the following options:
# target
CONFIG_TARGET_x86=y
CONFIG_TARGET_x86_alix2=y
CONFIG_DEVEL=y
CONFIG_TOOLCHAINOPTS=y
#CONFIG_KERNEL_KALLSYMS=y
CONFIG_KERNEL_DEBUG_KERNEL=y
CONFIG_KERNEL_DEBUG_INFO=y
Note, I commented out the "CONFIG_KERNEL_KALLSYMS=y". The problems
happens when that is disabled. If I turn that back on,
"CONFIG_KERNEL_KALLSYMS=y", the trace messages disappear.
Adam
On 2/22/12 12:30 AM, Philip Prindeville wrote:
Actually, that shouldn't have fixed your problem! (Unless
Heisenberg's Principle comes into effect.)
It was supposed to give us a useful stack trace, however.
You might have had a corrupt build.
Can you try it on several boxes and see if it's reproducible?
-Philip
On 2/21/12 10:10 PM, Adam Gensler wrote:
Hi Philip,
I rebuilt an image with those additional options added. It resolved
the
call traces I was seeing in dmesg. None of them show up now. I'll
admit,
I'm not super familiar with the inner-workings of kernel building. Can
you provide some insight into why this seems to have resolved the
issue?
Attached is the dmesg output from the new image, just in case.
Thanks,
Adam
On 2/21/12 10:31 PM, Philip Prindeville wrote:
On 2/21/12 8:15 PM, Adam Gensler wrote:
Hi all,
I have a handful of Alix 2D13 platforms I've been running trunk
images
on for a while now. I noticed that it was recently kicked up to
kernel
3.2.2. When it boots up now there's a number of traces from insmod.
Attached is the complete output of the boot sequence.
The image was built clean, in a clean pull of trunk, using the
default
alix2 target. I've seen this on multiple alix boards, on images
built on
two completely separate build servers so I don't think its
related to
how I'm building the image.
Any suggestions on how to troubleshoot this?
Thanks in advance,
Adam
Please do the following:
% mkdir ~/.openwrt
% cat>> ~/.openwrt/defconfig
CONFIG_DEVEL=y
CONFIG_TOOLCHAINOPTS=y
CONFIG_KERNEL_KALLSYMS=y
CONFIG_KERNEL_DEBUG_KERNEL=y
CONFIG_KERNEL_DEBUG_INFO=y
^D
% rm -rf tmp .config
% make defconfig
% make target/linux/{clean,compile} world V=99
%
and try it again.
Thanks,
-Philip
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] sysupgrade: try harder during an error
> cause is, but what I have seen is that the mtd utility > needs to retry sometimes, and that [e] condition > is a temporary "Out of memory" error. At least, on ar71xx. out of memory doesnt satisfy me. on our boxes we remove all (!) running programs and unload all (!) kernel-modules before invoking sysupgrade. we have about 25 megabytes of free memory just before sysupgrading... [some mtd-code snippet] > I have seen this fail once, twice, and then still succeed. But > this > doesn't solve the root cause, and I think I'm still seeing > complete > failures here on occasion. This just significantly mitigates it. the question is: what to do to handle such an error. reboot doesnt help: maybe open telnet/dropbear and fire a failsafe-like mode with 192.168.1.1? but retrying X times is better than nothing... bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] sysupgrade: try harder during an error
> It also means that sysupgrade would loop forever in case of a > really > fatal issue, like when the image is too large for the given mtd > partition. maybe we should limit the loop to X times? > I'd say the mtd util should perform 3-5 consecutive tries in case > of a > block erase problem and then finally exit with a non zero code to > notify > the caller about the problem. > > The exit code could convey the nature of the problem, e.g. erase > issue > or mtd too short; this would allow sysupgrade to take appropriate > actions without brute-forcing the flash into death. that sounds very good to me. a non-reliable sysupgrade is a real showstopper for the professional world. one of the important goals of openwrt is to change the bad update-handling of embedded targets. so a kernel-update from time to time should be possible without having to fear. in our (special) mesh-network case it's a lot more problematic, because we do everything over the air and often the devices are nearly unreachable. in our last update-session we lost 180 routers (but a lot more didn't have any problems during this upgrade). (meaning: even 1% fail is too much) bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] sysupgrade: try harder during an error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > maybe we should limit the loop to X times? That would still mean needlessly rewriting good blocks X times. Your loop approaches the problem several layers too high. ~ Jow -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9JJ50ACgkQdputYINPTPO42wCbB3HyHViFXIzYfG3hVeglnVf4 AjUAoJOyr1Sj8lFIL1/q6KQ+YuIqnCWK =+qW6 -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] sysupgrade: try harder during an error
> That would still mean needlessly rewriting good blocks X times. > Your loop approaches the problem several layers too high. you are right. so "just" the error-handling within the sysupgrade-script. fire telnet + landev? (because reboot = dead/brick) bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] sysupgrade: try harder during an error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > so "just" the error-handling within the > sysupgrade-script. fire telnet + landev? Yes, that'd be a good solution - plus maybe netmsg to send the usual UDP broadcast stating that something is broken. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9JKaMACgkQdputYINPTPM+iQCgiNHpmC3SvUY+dmCtw5VAhK1L jTYAnjil488CzKAXJmvMjntRc+Q5VaTu =BW0W -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] sysupgrade: try harder during an error
On 02/25/2012 10:15 AM, Bastian Bittorf wrote: cause is, but what I have seen is that the mtd utility needs to retry sometimes, and that [e] condition is a temporary "Out of memory" error. At least, on ar71xx. out of memory doesnt satisfy me. And? I'm telling you what the error is at this level; I'm the only one who's reported this; I've not claimed the resolution is satisfactory. You are free to dig further and find the underlying cause, which is probably kernel related. I'd for one would be grateful. My machine too has significant free memory, but I suspect the memory relates to some kernel memory issues, rather than megabytes of free user space memory. Chill. And I recommend use of your shift key ;-) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] sysupgrade: try harder during an error
> My machine too has significant free memory, but I suspect > the memory relates to some kernel memory issues, rather > than megabytes of free user space memory. > > Chill. And I recommend use of your shift key ;-) Thanks for your feedback. I'am fine with shift 8-) and just misunderstood you... bye, Bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] add easydns support to ddns-scripts
Signed-off-by: Galen Seitz Signed-off-by: Russell Senior --- net/ddns-scripts/files/usr/lib/ddns/services |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/net/ddns-scripts/files/usr/lib/ddns/services b/net/ddns-scripts/files/usr/lib/ddns/services index 82461d2..1e6b6b9 100644 --- a/net/ddns-scripts/files/usr/lib/ddns/services +++ b/net/ddns-scripts/files/usr/lib/ddns/services @@ -54,3 +54,6 @@ # namecheap.com "namecheap.com" "http://dynamicdns.park-your-domain.com/update?host=[USERNAME]&domain=[DOMAIN]&password=[PASSWORD]&ip=[IP]"; + +# easydns.com dynamic DNS +"easydns.com" "http://[USERNAME]:[PASSWORD]@api.cp.easydns.com/dyn/tomato.php?hostname=[DOMAIN]&myip=[IP]"; -- 1.7.9 -- Russell Senior, President russ...@personaltelco.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Alix 2D13 on latest trunk, traces in dmesg on bootup?
A couple of other things to try. I build with:
CONFIG_USE_EGLIBC=y
CONFIG_EGLIBC_VERSION_2_13=y
and I use the default gcc.
On 2/25/12 10:48 AM, Adam Gensler wrote:
> Does anyone else have any thoughts into this? Other suggestions I can
> try? Seems someone else is seeing the same issue as I've found the
> following output sitting on pastebin:
>
> http://pastebin.com/djNfNa3t
>
> These errors match the errors I'm seeing on my system exactly.
>
> I've since reverted to trunk@29844 with a patch kicking it up to the
> 3.0.18 kernel and I don't see these errors. I went ahead and opened a
> ticket on this for tracking purposes:
>
> alix2 - trace messages in dmesg on bootup
> https://dev.openwrt.org/ticket/11020
>
> Thanks,
> Adam
>
> On 2/22/12 1:02 AM, Adam Gensler wrote:
>> Just build another one, this time with the following:
>>
>> # target
>> CONFIG_TARGET_x86=y
>> CONFIG_TARGET_x86_alix2=y
>> CONFIG_DEVEL=y
>> CONFIG_TOOLCHAINOPTS=y
>> CONFIG_KERNEL_KALLSYMS=y
>> #CONFIG_KERNEL_DEBUG_KERNEL=y
>> #CONFIG_KERNEL_DEBUG_INFO=y
>>
>> Boots fine, no traces showing up.
>>
>> Not sure what that means exactly. Buts it's 100% reproducible on three
>> different alix boards with images from two different build machines.
>>
>> Adam
>>
>> On 2/22/12 12:50 AM, Philip Prindeville wrote:
>>> Try leaving CONFIG_KERNEL_KALLSYMS and turn off CONFIG_KERNEL_DEBUG_* ...
>>>
>>> On 2/21/12 10:34 PM, Adam Gensler wrote:
Hi Philip,
I suspected that might have been the problem so I did another build real
quick, but I removed your extra commands, and the problem returned in
that build.
So, I ran yet another build, this time, with the following options:
# target
CONFIG_TARGET_x86=y
CONFIG_TARGET_x86_alix2=y
CONFIG_DEVEL=y
CONFIG_TOOLCHAINOPTS=y
#CONFIG_KERNEL_KALLSYMS=y
CONFIG_KERNEL_DEBUG_KERNEL=y
CONFIG_KERNEL_DEBUG_INFO=y
Note, I commented out the "CONFIG_KERNEL_KALLSYMS=y". The problems
happens when that is disabled. If I turn that back on,
"CONFIG_KERNEL_KALLSYMS=y", the trace messages disappear.
Adam
On 2/22/12 12:30 AM, Philip Prindeville wrote:
> Actually, that shouldn't have fixed your problem! (Unless
> Heisenberg's Principle comes into effect.)
>
> It was supposed to give us a useful stack trace, however.
>
> You might have had a corrupt build.
>
> Can you try it on several boxes and see if it's reproducible?
>
> -Philip
>
>
> On 2/21/12 10:10 PM, Adam Gensler wrote:
>> Hi Philip,
>>
>> I rebuilt an image with those additional options added. It resolved
>> the
>> call traces I was seeing in dmesg. None of them show up now. I'll
>> admit,
>> I'm not super familiar with the inner-workings of kernel building. Can
>> you provide some insight into why this seems to have resolved the
>> issue?
>>
>> Attached is the dmesg output from the new image, just in case.
>>
>> Thanks,
>> Adam
>>
>>
>> On 2/21/12 10:31 PM, Philip Prindeville wrote:
>>> On 2/21/12 8:15 PM, Adam Gensler wrote:
Hi all,
I have a handful of Alix 2D13 platforms I've been running trunk
images
on for a while now. I noticed that it was recently kicked up to
kernel
3.2.2. When it boots up now there's a number of traces from insmod.
Attached is the complete output of the boot sequence.
The image was built clean, in a clean pull of trunk, using the
default
alix2 target. I've seen this on multiple alix boards, on images
built on
two completely separate build servers so I don't think its
related to
how I'm building the image.
Any suggestions on how to troubleshoot this?
Thanks in advance,
Adam
>>>
>>> Please do the following:
>>>
>>> % mkdir ~/.openwrt
>>> % cat>> ~/.openwrt/defconfig
>>> CONFIG_DEVEL=y
>>> CONFIG_TOOLCHAINOPTS=y
>>> CONFIG_KERNEL_KALLSYMS=y
>>> CONFIG_KERNEL_DEBUG_KERNEL=y
>>> CONFIG_KERNEL_DEBUG_INFO=y
>>> ^D
>>> % rm -rf tmp .config
>>> % make defconfig
>>> % make target/linux/{clean,compile} world V=99
>>> %
>>>
>>> and try it again.
>>>
>>> Thanks,
>>>
>>> -Philip
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] NFS root during development
On Fri, Feb 24, 2012 at 11:25 AM, Christian Gagneraud
wrote:
> Hi there,
>
> I'm currently trying to add a new device (based on a ATSAM9G20), and during
> development I would like to boot it on a NFS root.
> Unfortunately I noticed that a couple of firstboot/preinit/init scripts are
> messing up with either the rootfs and/or the network configuration.
> Does anyone has any tricks for using a NFS root?
You need init=/etc/preinit on the kernel command line in uboot.
nfsargs=setenv bootargs console=ttyS0,115200n8 root=/dev/nfs rw
nfsroot=${serverip}:${rootpath} ip=:eth0:dhcp loglevel=7
init=/etc/preinit
> Especially I would like to:
> - Avoid root remounting (or make openwrt aware onf the NFS root)
> - Avoid mtd checking and stuff
> - Avoid network interface reconfiguration (especially the hotplug call on
> eth0 in /etc/rc.d/S10boot)
>
> Regards,
> Chris
>
>
> --
> Christian Gagneraud,
> Embedded systems engineer.
> Techworks Marine
> 1 Harbour road
> Dun Laoghaire
> Co. Dublin
> Ireland
> Tel: + 353 (0) 1 236 5990
> Web: http://www.techworks.ie/
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
--
Jon Smirl
jonsm...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
