[OpenWrt-Devel] [PATCH] mvebu: enable auto recovery all the time
This will have the autorecovery mechanism enabled permanently.
This patch depends on patch
"Fix for mvebu (WRT1900AC/WRT1200AC/etc) boot counter"
Signed-off-by: Rob Mosher
---
target/linux/mvebu/base-files/etc/init.d/u-boot_env | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/target/linux/mvebu/base-files/etc/init.d/u-boot_env
b/target/linux/mvebu/base-files/etc/init.d/u-boot_env
index bf038b2..d67c0a4 100755
--- a/target/linux/mvebu/base-files/etc/init.d/u-boot_env
+++ b/target/linux/mvebu/base-files/etc/init.d/u-boot_env
@@ -8,8 +8,14 @@ boot() {
case $(mvebu_board_name) in
armada-385-linksys-caiman|armada-385-linksys-cobra|armada-xp-linksys-mamba)
- fw_setenv auto_recovery off
+ # make sure auto_recovery in uboot is turned on
+ AUTO_RECOVERY_ENA="`fw_printenv -n auto_recovery`"
+ if [ "$AUTO_RECOVERY_ENA" != "yes" ] ; then
+ fw_setenv auto_recovery yes
+ fi
mtd resetbc s_env
+ sync
+
;;
esac
}
--
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH V2] Fix for mvebu (WRT1900AC/WRT1200AC/etc) boot counter
Good point. It looks like Linksys actually just did the same thing as
well in their firmware. Anyway, this patch is just to fix the boot
counter, I'll submit another to leave auto recovery on.
On 8/18/2015 9:00 PM, Claudio Leite wrote:
* Rob Mosher (nyt-open...@countercultured.net) wrote:
Auto recovery is enabled when flashing, so if it goes wrong, you can get
back to your previous image. Otherwise, I don't think there's a need for it
as all it does is switch which kernel/root partitions are booted which
shouldn't ever change unless flashing (famous last words?).
The use case for leaving it on is for somebody without serial console
access who tries something slightly risky and breaks the active image.
Say, an image that gets far enough to get to mtd resetbc and set
auto_recovery to off, but not actually work (no network, etc.) There are
also enough cases of people messing up their active images on the
WRT1900AC forum thread, one way or another.
If auto_recovery were kept on, they could then use that trick posted
in the wiki ("Stock Firmware Recovery") to manually trigger the
auto recovery to flip back to the other image. (that of course assumes
the other firmware works, but again, this isn't a great recovery
mechanism...)
I tested a build with this patch but auto_recovery kept to "on" and it
works as expected after many reboots. I also manually triggered the
auto_recovery flip, which also worked as expected. So, it seems like it
doesn't really cost anything to keep it on (not yet, at least) while
providing a fringe benefit.
-Claudio
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH V2] Fix for mvebu (WRT1900AC/WRT1200AC/etc) boot counter
* Rob Mosher (nyt-open...@countercultured.net) wrote:
> Auto recovery is enabled when flashing, so if it goes wrong, you can get
> back to your previous image. Otherwise, I don't think there's a need for it
> as all it does is switch which kernel/root partitions are booted which
> shouldn't ever change unless flashing (famous last words?).
The use case for leaving it on is for somebody without serial console
access who tries something slightly risky and breaks the active image.
Say, an image that gets far enough to get to mtd resetbc and set
auto_recovery to off, but not actually work (no network, etc.) There are
also enough cases of people messing up their active images on the
WRT1900AC forum thread, one way or another.
If auto_recovery were kept on, they could then use that trick posted
in the wiki ("Stock Firmware Recovery") to manually trigger the
auto recovery to flip back to the other image. (that of course assumes
the other firmware works, but again, this isn't a great recovery
mechanism...)
I tested a build with this patch but auto_recovery kept to "on" and it
works as expected after many reboots. I also manually triggered the
auto_recovery flip, which also worked as expected. So, it seems like it
doesn't really cost anything to keep it on (not yet, at least) while
providing a fringe benefit.
-Claudio
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH V2] Fix for mvebu (WRT1900AC/WRT1200AC/etc) boot counter
Auto recovery is enabled when flashing, so if it goes wrong, you can get
back to your previous image. Otherwise, I don't think there's a need
for it as all it does is switch which kernel/root partitions are booted
which shouldn't ever change unless flashing (famous last words?).
root@ZOMGWTFBBQWIFI:/lib/upgrade# cat linksys.sh
#
# Copyright (C) 2014-2015 OpenWrt.org
#
linksys_get_target_firmware() {
cur_boot_part=`/usr/sbin/fw_printenv -n boot_part`
target_firmware=""
if [ "$cur_boot_part" = "1" ]
then
# current primary boot - update alt boot
target_firmware="kernel2"
fw_setenv boot_part 2
fw_setenv bootcmd "run altnandboot"
elif [ "$cur_boot_part" = "2" ]
then
# current alt boot - update primary boot
target_firmware="kernel1"
fw_setenv boot_part 1
fw_setenv bootcmd "run nandboot"
fi
# re-enable recovery so we get back if the new firmware is broken
fw_setenv auto_recovery yes
echo "$target_firmware"
}
[...]
On 8/18/2015 8:16 PM, Claudio Leite wrote:
* Rob Mosher (nyt-open...@countercultured.net) wrote:
+++ b/target/linux/mvebu/base-files/etc/init.d/u-boot_env
@@ -9,6 +9,7 @@ boot() {
case $(mvebu_board_name) in
armada-385-linksys-caiman|armada-385-linksys-cobra|armada-xp-linksys-mamba)
fw_setenv auto_recovery off
With s_env now properly updated, is there still a reason to turn off
auto_recovery?
I know it's generally a poor recovery mechanism, but as long as it
doesn't interfere with booting OpenWrt it might be better than nothing.
+ mtd resetbc s_env
;;
esac
}
--
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH V2] Fix for mvebu (WRT1900AC/WRT1200AC/etc) boot counter
* Rob Mosher (nyt-open...@countercultured.net) wrote:
> +++ b/target/linux/mvebu/base-files/etc/init.d/u-boot_env
> @@ -9,6 +9,7 @@ boot() {
> case $(mvebu_board_name) in
>
> armada-385-linksys-caiman|armada-385-linksys-cobra|armada-xp-linksys-mamba)
> fw_setenv auto_recovery off
With s_env now properly updated, is there still a reason to turn off
auto_recovery?
I know it's generally a poor recovery mechanism, but as long as it
doesn't interfere with booting OpenWrt it might be better than nothing.
> + mtd resetbc s_env
> ;;
> esac
> }
> --
> 2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] PATCH two patches for the AP121 reference board (ar9331)
hi!
these are my first OpenWRT patches, sorry if i'm breaking any rules.
one of them fixes board name detection (and thus sysupgrade); the
other one adds a 8M flash target and rearranges the kernel size so
that the firmware files get built properly.
they are attached in the issue tracker also:
https://dev.openwrt.org/ticket/17885
https://dev.openwrt.org/ticket/14571
it would be great if they could get into CC final.
--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Few facts are more revealing than the direction people travel when
they vote with their feet.”
— Don Boudreaux, http://bit.ly/afZgx2
Index: target/linux/ar71xx/image/Makefile
===
--- target/linux/ar71xx/image/Makefile (revision 46302)
+++ target/linux/ar71xx/image/Makefile (working copy)
@@ -909,7 +909,8 @@
ap96_mtdlayout=mtdparts=spi0.0:192k(u-boot)ro,64k(u-boot-env)ro,6144k(rootfs),1728k(kernel),64k(art)ro,7872k@0x4(firmware)
ap113_mtd_layout=mtdparts=spi0.0:64k(u-boot),3008k(rootfs),896k(uImage),64k(NVRAM),64k(ART),3904k@0x1(firmware)
ap121_mtdlayout_2M=mtdparts=spi0.0:64k(u-boot)ro,1216k(rootfs),704k(kernel),64k(art)ro,1920k@0x1(firmware)
-ap121_mtdlayout_4M=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,2752k(rootfs),896k(kernel),64k(nvram),64k(art)ro,3648k@0x5(firmware)
+ap121_mtdlayout_4M=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,2448k(rootfs),1200k(kernel),64k(nvram),64k(art)ro,3648k@0x5(firmware)
+ap121_mtdlayout_8M=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,6144k(rootfs),1600k(kernel),64k(nvram),64k(art)ro,7744k@0x5(firmware)
ap132_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,1408k(kernel),6400k(rootfs),64k(art),7808k@0x5(firmware)
ap135_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,14528k(rootfs),1472k(kernel),64k(art)ro,16000k@0x5(firmware)
ap136_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,6336k(rootfs),1408k(kernel),64k(mib0),64k(art)ro,7744k@0x5(firmware)
@@ -1801,6 +1802,7 @@
$(eval $(call
SingleProfile,AthLzma,64k,AP113,ap113,AP113,ttyS0,115200,$$(ap113_mtd_layout),RK))
$(eval $(call
SingleProfile,AthLzma,64k,AP121_2M,ap121-2M,AP121,ttyATH0,115200,$$(ap121_mtdlayout_2M),RKuImage))
$(eval $(call
SingleProfile,AthLzma,64k,AP121_4M,ap121-4M,AP121,ttyATH0,115200,$$(ap121_mtdlayout_4M),RKuImage))
+$(eval $(call
SingleProfile,AthLzma,64k,AP121_8M,ap121-8M,AP121,ttyATH0,115200,$$(ap121_mtdlayout_8M),RKuImage))
$(eval $(call
SingleProfile,AthLzma,64k,AP121MINI,ap121-mini,AP121-MINI,ttyATH0,115200,$$(ap121_mtdlayout_4M),RKuImage))
$(eval $(call
SingleProfile,AthLzma,64k,AP132,ap132,AP132,ttyS0,115200,$$(ap132_mtdlayout),KRuImage))
$(eval $(call
SingleProfile,AthLzma,64k,AP135,ap135-020,AP135-020,ttyS0,115200,$$(ap135_mtdlayout),RKuImage))
@@ -1971,7 +1973,7 @@
$(eval $(call
SingleProfile,ZyXEL,64k,NBG_460N_550N_550NH,nbg460n_550n_550nh,NBG460N,ttyS0,115200,NBG-460N))
-$(eval $(call MultiProfile,AP121,AP121_2M AP121_4M))
+$(eval $(call MultiProfile,AP121,AP121_2M AP121_4M AP121_8M))
$(eval $(call MultiProfile,AP136,AP136_010 AP136_020))
$(eval $(call MultiProfile,EWDORIN, EWDORINAP EWDORINRT EWDORIN16M))
$(eval $(call MultiProfile,OPENMESH,OM2P OM5P MR600 MR900))
From 87c575fa7d7af18cafd55a682a8c6a492a9ff170 Mon Sep 17 00:00:00 2001
From: Attila Lendvai
Date: Wed, 5 Aug 2015 17:58:11 +0200
Subject: [PATCH] AP121: fix board detection in ar71xx.sh
---
target/linux/ar71xx/base-files/lib/ar71xx.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index 4c10ab2..52faf08 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -344,7 +344,7 @@ ar71xx_board_detect() {
*AP113)
name="ap113"
;;
- *AP121)
+ *"AP121 reference board")
name="ap121"
;;
*AP121-MINI)
--
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH V2] Fix for mvebu (WRT1900AC/WRT1200AC/etc) boot counter
The uboot boot counter was never reset after a successful boot.
This patch prevents bootcmd and boot_part from becoming out of sync
after a sysupgrade and ensures the proper partition is booted.
Signed-off-by: Jonas Gorski
Signed-off-by: Rob Mosher
---
package/system/mtd/Makefile| 2 +-
package/system/mtd/src/Makefile| 1 +
package/system/mtd/src/linksys_bootcount.c | 114 +
package/system/mtd/src/mtd.c | 12 +++
package/system/mtd/src/mtd.h | 1 +
.../linux/mvebu/base-files/etc/init.d/u-boot_env | 1 +
6 files changed, 130 insertions(+), 1 deletion(-)
create mode 100644 package/system/mtd/src/linksys_bootcount.c
diff --git a/package/system/mtd/Makefile b/package/system/mtd/Makefile
index 8d7bb44..ae1922f 100644
--- a/package/system/mtd/Makefile
+++ b/package/system/mtd/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
include $(INCLUDE_DIR)/kernel.mk
PKG_NAME:=mtd
-PKG_RELEASE:=20
+PKG_RELEASE:=21
PKG_BUILD_DIR := $(KERNEL_BUILD_DIR)/$(PKG_NAME)
STAMP_PREPARED := $(STAMP_PREPARED)_$(call confvar,CONFIG_MTD_REDBOOT_PARTS)
diff --git a/package/system/mtd/src/Makefile b/package/system/mtd/src/Makefile
index 27ac339..40a165e 100644
--- a/package/system/mtd/src/Makefile
+++ b/package/system/mtd/src/Makefile
@@ -10,6 +10,7 @@ obj.brcm47xx = $(obj.brcm)
obj.bcm53xx = $(obj.brcm)
obj.brcm63xx = imagetag.o
obj.ramips = $(obj.seama)
+obj.mvebu = linksys_bootcount.o
ifdef FIS_SUPPORT
obj += fis.o
diff --git a/package/system/mtd/src/linksys_bootcount.c
b/package/system/mtd/src/linksys_bootcount.c
new file mode 100644
index 000..95f75fe
--- /dev/null
+++ b/package/system/mtd/src/linksys_bootcount.c
@@ -0,0 +1,114 @@
+/*
+ * Linksys boot counter reset code for mtd
+ *
+ * Copyright (C) 2013 Jonas Gorski
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License v2
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include "mtd.h"
+
+#define BOOTCOUNT_MAGIC0x20110811
+
+struct bootcounter {
+ uint32_t magic;
+ uint32_t count;
+ uint32_t checksum;
+};
+
+static char page[2048];
+
+int mtd_resetbc(const char *mtd)
+{
+ struct mtd_info_user mtd_info;
+ struct bootcounter *curr = (struct bootcounter *)page;
+ unsigned int i;
+ int last_count = 0;
+ int num_bc;
+ int fd;
+ int ret;
+
+ fd = mtd_check_open(mtd);
+
+ if (ioctl(fd, MEMGETINFO, &mtd_info) < 0) {
+ fprintf(stderr, "failed to get mtd info!\n");
+ return -1;
+ }
+
+ num_bc = mtd_info.size / mtd_info.writesize;
+
+ for (i = 0; i < num_bc; i++) {
+ pread(fd, curr, sizeof(*curr), i * mtd_info.writesize);
+
+ if (curr->magic != BOOTCOUNT_MAGIC && curr->magic !=
0x) {
+ fprintf(stderr, "unexpected magic %08x, bailing out\n",
curr->magic);
+ goto out;
+ }
+
+ if (curr->magic == 0x)
+ break;
+
+ last_count = curr->count;
+ }
+
+ /* no need to do writes when last boot count is already 0 */
+ if (last_count == 0)
+ goto out;
+
+
+ if (i == num_bc) {
+ struct erase_info_user erase_info;
+ erase_info.start = 0;
+ erase_info.length = mtd_info.size;
+
+ /* erase block */
+ ret = ioctl(fd, MEMERASE, &erase_info);
+ if (ret < 0) {
+ fprintf(stderr, "failed to erase block: %i\n", ret);
+ return -1;
+ }
+
+ i = 0;
+ }
+
+ memset(curr, 0xff, mtd_info.writesize);
+
+ curr->magic = BOOTCOUNT_MAGIC;
+ curr->count = 0;
+ curr->checksum = BOOTCOUNT_MAGIC;
+
+ ret = pwrite(fd, curr, mtd_info.writesize, i * mtd_info.writesize);
+ if (ret < 0)
+ fprintf(stderr, "failed to write: %i\n", ret);
+ sync();
+out:
+ close(fd);
+
+ return 0;
+}
diff --git a/package/system/mtd/src/mtd.c b/package/system/mtd/src/mtd.c
index 741b57b..0247630 100644
--- a/package/system/mtd/src/mtd.c
+++ b/package/system/mtd/src/mtd.c
@@ -640,6 +
Re: [OpenWrt-Devel] [PATCH v3] Add Minibox v1.0 support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stijn Segers wrote: > This patch adds Gainstrong Minibox v1.0 into trunk. I have addressed the > following issues: > - all caps prefix > - added vendor > > I have built images and asked for testing on the forums, the image has > been confirmed working but the LED is off during normal operation (I > assume > this is the possible LED polarity issue Karl Palsson was talking about?) > > Questions: > > - Can I simply set gpio_led minibox_v1_leds_gpio to active.low = 1 or isn't > that how it works? Yup, that's exactly how it works, and is indeed what I was getting earlier. Test that out and make sure that when you modify the leds files in /sys/class/leds/x/brightness that 255 means led is on/lit, and 0 means off/dark. Cheers, Karl P -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJV05kOAAoJEBmotQ/U1cr2VbwQAKoXshakR92v+RHsrCxttIfi 8jS2BzWGQWhWQOGPkMPevDlX+kLYUrySliLALmZYWCuvXimkFXb5k9BsQycOy02n ZV5aZEkdUWwqISnVVqKuhCnDuP5RSEdkTleCs6+BzdqMAOYmgSl5eEmxaZWO0QeH 652xyvis+JhmLyw/jjn6pjbHgeUazpyfYwMWAJQ7iQUfQy2BGBUgQbtlX2nm0H4y gonY6LUl8xyikV/d8IagzOMViGvPZ0w4oV1bx7xG5a6jmHKrvnXD+5yqv13Fq5+v aHh5q243MPm5LG+qxsDS/Y5BAv2IxZ8sdzmdQPwbuhbH5JXEDNZhJZllznNITwEh Wzg+VqMDNnpxlVR9UsMU6mnqjDieGngermw0kfaCiLyRL7JNyCfSEWSgfQFXjrSk Tc83AdQ+D39ymPyLm0uP9ylvg3pL9/TqO34R26OB4mOdeiQJA3fBqVoKSZzQbmz6 4V3PY+eKD/GOabjaSZLRhOXjykhFqkv9K8E1F12jGlryy9ZrPFSk5+d/lsRGOBJ7 JfIJeQ1/746KkYk79YbFgqgjGYIqGvc+GSq4QXRPT+UCh+TONxQOCkSf3OQ2egMX XpvWu9dcSlK7glrBOYURHKPNiUvmUYl1Fx5OKBQlSuBi1nblDi40NSpYaCYMcT8g T2Oxf6TjYzGh+fJ7gvlY =cbeg -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v3] Add Minibox v1.0 support
This patch adds Gainstrong Minibox v1.0 into trunk. I have addressed the
following issues:
- all caps prefix
- added vendor
I have built images and asked for testing on the forums, the image has
been confirmed working but the LED is off during normal operation (I assume
this is the possible LED polarity issue Karl Palsson was talking about?)
Questions:
- Can I simply set gpio_led minibox_v1_leds_gpio to active.low = 1 or isn't
that how it works?
- Should I give the 799 minibox kernel support patch a number that follows
the existing patches more closely (e.g. 750) or doesn't that matter?
Thanks
Signed-off by: Stijn Segers
---
target/linux/ar71xx/base-files/etc/diag.sh | 3 +
.../ar71xx/base-files/etc/uci-defaults/02_network | 1 +
target/linux/ar71xx/base-files/lib/ar71xx.sh | 6 ++
.../ar71xx/base-files/lib/upgrade/platform.sh | 1 +
target/linux/ar71xx/config-4.1 | 1 +
.../ar71xx/files/arch/mips/ath79/mach-minibox-v1.c | 84 ++
target/linux/ar71xx/generic/profiles/minibox-v1.mk | 17 +
target/linux/ar71xx/image/Makefile | 9 +++
.../799-MIPS-ath79-add-minibox-v1-support.patch| 39 ++
9 files changed, 161 insertions(+)
create mode 100644 target/linux/ar71xx/files/arch/mips/ath79/mach-minibox-v1.c
create mode 100644 target/linux/ar71xx/generic/profiles/minibox-v1.mk
create mode 100644
target/linux/ar71xx/patches-4.1/799-MIPS-ath79-add-minibox-v1-support.patch
diff --git a/target/linux/ar71xx/base-files/etc/diag.sh
b/target/linux/ar71xx/base-files/etc/diag.sh
index 36de775..342c68c 100644
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -219,6 +219,9 @@ get_status_led() {
smart-300)
status_led="nc-link:green:system"
;;
+ minibox-v1)
+ status_led="minibox-v1:green:system"
+ ;;
oolite)
status_led="oolite:red:system"
;;
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 686fce9..49f6b55 100644
--- a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
+++ b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
@@ -425,6 +425,7 @@ dir-615-e4 |\
hiwifi-hc6361 |\
ja76pf |\
mc-mac1200r|\
+minibox-v1 |\
mynet-n600 |\
oolite |\
qihoo-c301 |\
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index e1f345e..4f9735f 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -119,6 +119,9 @@ tplink_board_detect() {
"3C0001"*)
model="OOLITE"
;;
+ "3C0002"*)
+ model="Minibox_v1"
+ ;;
"070300"*)
model="TP-Link TL-WR703N"
;;
@@ -502,6 +505,9 @@ ar71xx_board_detect() {
*"MAC1200R")
name="mc-mac1200r"
;;
+ *"Minibox v1.0")
+ name="minibox-v1"
+ ;;
*MR12)
name="mr12"
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index c1962e4..0b7b84c 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -314,6 +314,7 @@ platform_check_image() {
el-mini | \
gl-inet | \
mc-mac1200r | \
+ minibox-v1 |\
onion-omega | \
oolite | \
smart-300 | \
diff --git a/target/linux/ar71xx/config-4.1 b/target/linux/ar71xx/config-4.1
index 21c4601..49f2ac1 100644
--- a/target/linux/ar71xx/config-4.1
+++ b/target/linux/ar71xx/config-4.1
@@ -79,6 +79,7 @@ CONFIG_ATH79_MACH_HORNET_UB=y
CONFIG_ATH79_MACH_JA76PF=y
CONFIG_ATH79_MACH_JWAP003=y
CONFIG_ATH79_MACH_MC_MAC1200R=y
+CONFIG_ATH79_MACH_MINIBOX_V1=y
CONFIG_ATH79_MACH_MR12=y
CONFIG_ATH79_MACH_MR16=y
CONFIG_ATH79_MACH_MR600=y
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-minibox-v1.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-minibox-v1.c
new file mode 100644
index 000..7c26cab
--- /dev/null
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-minibox-v1.c
@@ -0,0 +1,84 @@
+/*
+ * Minibox v1.0 board support
+ *
+ *
+ * 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 "common.h"
+#include "dev-eth.h"
+#include "dev-gpio-buttons.h"
+#include "dev-leds-gpio.h"
+#include "dev-m25p80.h"
+#include "dev-usb.h"
+#include "dev-wmac.h"
+#include "machtypes.h"
+
+#define MINIBOX_V1_GPIO_BTN_RESET 11
+
+#define MINIBOX_V1_GPIO_LED_SYSTEM 1
+
+#define MINIBOX_V1_KEYS_POLL_I
Re: [OpenWrt-Devel] [PATCH v3] lantiq: get more status information from xDSL
Hi John, I have just seen that you are not CC'ed here yet. Could you please have a look at Florian's patch [0] and merge it, since quite a few people seem to be interested in this kind of functionality? Regards, Martin [0] http://patchwork.ozlabs.org/patch/504567/ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Mount mmc block
2015-08-18 20:39 GMT+02:00 : > On Tue, 18 Aug 2015 11:59:11 +0200 > Baptiste Clenet wrote: > >> mount -t -ext3 /dev/mmcblk0p1 /mnt/mmc/ I tried with FAT16 as well > > is ist better so? > > mount -t ext3 /dev/mmcblk0p1 /mnt/mmc/ > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > The solution was to format the emmc and create an ext4 file system. Thanks. -- Baptiste ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Mount mmc block
On Tue, 18 Aug 2015 11:59:11 +0200 Baptiste Clenet wrote: > mount -t -ext3 /dev/mmcblk0p1 /mnt/mmc/ is ist better so? mount -t ext3 /dev/mmcblk0p1 /mnt/mmc/ pgpan_NcA7ana.pgp Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Fix for mvebu (WRT1900AC/WRT1200AC/etc) boot counter
What's SOB?
Kaloz sent me the E4500 patch and told me less than a day to get it
included into CC for the mvebu stuff. I just applied it, fixed some
very minor compile things, tested it, and sent in the patch since he
went idle on IRC and I had to get to work after staying up all night. I
was going to reverse engineer the linksys recovery binary but he
presented this instead. I'm not trying to take any credit for this,
just trying to get the router working properly and understood the CC
deadline was fast approaching. I'm new to the patch
generation/submitting here so apologize if this stepped on any toes.
Yes, it compiles without warnings and it works. Once it's run the boot
counter no longer increments until a new image is flashed. It should
probably be renamed to something other than fixtrx as well. If you want
to modify it properly or have suggestions on what to clean up I'm all ears.
On 8/18/2015 12:10 PM, Jonas Gorski wrote:
On Tue, Aug 18, 2015 at 4:21 PM, Rob Mosher
wrote:
The uboot boot counter was never reset after a successful boot.
This patch prevents bootcmd and boot_part from becoming out of sync
after a sysupgrade and ensures the proper partition is booted.
Signed-off-by: Rob Mosher
Hm, that code looks awfully familiar ... right, I wrote it! So what
happened to my SOB?
---
package/system/mtd/Makefile| 2 +-
package/system/mtd/src/Makefile| 1 +
package/system/mtd/src/mvebu.c | 100 +
.../linux/mvebu/base-files/etc/init.d/u-boot_env | 1 +
4 files changed, 103 insertions(+), 1 deletion(-)
create mode 100644 package/system/mtd/src/mvebu.c
diff --git a/package/system/mtd/Makefile b/package/system/mtd/Makefile
index 8d7bb44..ae1922f 100644
--- a/package/system/mtd/Makefile
+++ b/package/system/mtd/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
include $(INCLUDE_DIR)/kernel.mk
PKG_NAME:=mtd
-PKG_RELEASE:=20
+PKG_RELEASE:=21
PKG_BUILD_DIR := $(KERNEL_BUILD_DIR)/$(PKG_NAME)
STAMP_PREPARED := $(STAMP_PREPARED)_$(call confvar,CONFIG_MTD_REDBOOT_PARTS)
diff --git a/package/system/mtd/src/Makefile b/package/system/mtd/src/Makefile
index 27ac339..3424dd2 100644
--- a/package/system/mtd/src/Makefile
+++ b/package/system/mtd/src/Makefile
@@ -10,6 +10,7 @@ obj.brcm47xx = $(obj.brcm)
obj.bcm53xx = $(obj.brcm)
obj.brcm63xx = imagetag.o
obj.ramips = $(obj.seama)
+obj.mvebu = mvebu.c
Does this even compile?
ifdef FIS_SUPPORT
obj += fis.o
diff --git a/package/system/mtd/src/mvebu.c b/package/system/mtd/src/mvebu.c
new file mode 100644
index 000..0929a97
--- /dev/null
+++ b/package/system/mtd/src/mvebu.c
@@ -0,0 +1,100 @@
+/*
+ * GPL Header ...
You didn't even bother inserting a proper GPL license header here.
+ */
+
+
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include "mtd.h"
+
+#define BOOTCOUNT_MAGIC0x20110811
+
+struct bootcounter {
+ uint32_t magic;
+ uint32_t count;
+ uint32_t checksum;
+};
+
+static char page[2048];
+
+int mtd_fixtrx(const char *mtd, size_t offset)
+{
+ struct mtd_info_user mtd_info;
+ struct bootcounter *curr = (struct bootcounter *)page;
+ unsigned int i;
+ int last_count = 0;
+ int num_bc;
+ int fd;
+ int ret;
+
+ fd = mtd_check_open(mtd);
+
+ if (ioctl(fd, MEMGETINFO, &mtd_info) < 0) {
+ fprintf(stderr, "failed to get mtd info!");
or fix the missing newline here.
+ return -1;
+ }
+
+ num_bc = mtd_info.size / mtd_info.writesize;
+
+ for (i = 0; i < num_bc; i++) {
+ pread(fd, curr, sizeof(*curr), i * mtd_info.writesize);
+
+ if (curr->magic != BOOTCOUNT_MAGIC && curr->magic !=
0x) {
+ printf("unexpected magic %08x, bailing out\n",
curr->magic);
+ goto out;
+ }
+
+ if (curr->magic == 0x)
+ break;
+
+ last_count = curr->count;
+ }
+
+ /* no need to do writes when last boot count is already 0 */
+ if (last_count == 0)
+ goto out;
+
+
+ if (i == num_bc) {
+ struct erase_info_user erase_info;
+ erase_info.start = 0;
+ erase_info.length = mtd_info.size;
+
+ /* erase block */
+ ret = ioctl(fd, MEMERASE, &erase_info);
+ if (ret < 0) {
+ printf("failed to erase block: %i\n", ret);
+ return -1;
+ }
+
+ i = 0;
+ }
+
+ memset(curr, 0xff, mtd_info.writesize);
+
+ curr->magic = BOOTCOUNT_MAGIC;
+ curr->count = 0;
+ curr->checksum = BOOTCOUNT_MAGIC;
+
+ ret = pwrite(fd, curr, mtd_info.writesize, i * mtd_info.writesize);
+ if (ret < 0
Re: [OpenWrt-Devel] Recommended settings ip6 DNS server / dnsmasq
> Thanks ! I could update my docs and add acknowledgment for your kind > help.http://wiki.openwrt.org/doc/howto/freebox?&#acknowledgmentsremerciements > The only missing part in stateful only configuration is the the default IPv6 > gateway fe80::5642:49ff:fe87: on local network. > Do you know how to propagate the gateway automatically using DHCP6? It is not possible, DHCPv6 doesn't carry routes. So you still need RAs even with ra_management set to 2. OpenWrt announces itself as default router via RAs if it has an IPv6 default route itself and there is a suitable global address prefix on the interface (if option ra is set to server). ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Recommended settings ip6 DNS server / dnsmasq
Le mardi 18 août 2015 à 13:49 +0200, Steven Barth a écrit : > Where you have option dhcpv6 and option ra you can add an option > ra_management > and set it to 0, 1 or 2. > > 0 means stateless only, > 1 means stateless + stateful (default) > 2 means stateful only > > Please note that stateful is not supported by all clients, e.g. all > android-based devices > will not have IPv6 connectivity with setting 2. Thanks ! I could update my docs and add acknowledgment for your kind help.http://wiki.openwrt.org/doc/howto/freebox?&#acknowledgmentsremerciements The only missing part in stateful only configuration is the the default IPv6 gateway fe80::5642:49ff:fe87: on local network. Do you know how to propagate the gateway automatically using DHCP6? Kind regards,Gnutella smime.p7s Description: S/MIME cryptographic signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Fix for mvebu (WRT1900AC/WRT1200AC/etc) boot counter
On Tue, Aug 18, 2015 at 4:21 PM, Rob Mosher
wrote:
> The uboot boot counter was never reset after a successful boot.
> This patch prevents bootcmd and boot_part from becoming out of sync
> after a sysupgrade and ensures the proper partition is booted.
>
> Signed-off-by: Rob Mosher
Hm, that code looks awfully familiar ... right, I wrote it! So what
happened to my SOB?
> ---
> package/system/mtd/Makefile| 2 +-
> package/system/mtd/src/Makefile| 1 +
> package/system/mtd/src/mvebu.c | 100
> +
> .../linux/mvebu/base-files/etc/init.d/u-boot_env | 1 +
> 4 files changed, 103 insertions(+), 1 deletion(-)
> create mode 100644 package/system/mtd/src/mvebu.c
>
> diff --git a/package/system/mtd/Makefile b/package/system/mtd/Makefile
> index 8d7bb44..ae1922f 100644
> --- a/package/system/mtd/Makefile
> +++ b/package/system/mtd/Makefile
> @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
> include $(INCLUDE_DIR)/kernel.mk
>
> PKG_NAME:=mtd
> -PKG_RELEASE:=20
> +PKG_RELEASE:=21
>
> PKG_BUILD_DIR := $(KERNEL_BUILD_DIR)/$(PKG_NAME)
> STAMP_PREPARED := $(STAMP_PREPARED)_$(call confvar,CONFIG_MTD_REDBOOT_PARTS)
> diff --git a/package/system/mtd/src/Makefile b/package/system/mtd/src/Makefile
> index 27ac339..3424dd2 100644
> --- a/package/system/mtd/src/Makefile
> +++ b/package/system/mtd/src/Makefile
> @@ -10,6 +10,7 @@ obj.brcm47xx = $(obj.brcm)
> obj.bcm53xx = $(obj.brcm)
> obj.brcm63xx = imagetag.o
> obj.ramips = $(obj.seama)
> +obj.mvebu = mvebu.c
Does this even compile?
>
> ifdef FIS_SUPPORT
>obj += fis.o
> diff --git a/package/system/mtd/src/mvebu.c b/package/system/mtd/src/mvebu.c
> new file mode 100644
> index 000..0929a97
> --- /dev/null
> +++ b/package/system/mtd/src/mvebu.c
> @@ -0,0 +1,100 @@
> +/*
> + * GPL Header ...
You didn't even bother inserting a proper GPL license header here.
> + */
> +
> +
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#include "mtd.h"
> +
> +#define BOOTCOUNT_MAGIC0x20110811
> +
> +struct bootcounter {
> + uint32_t magic;
> + uint32_t count;
> + uint32_t checksum;
> +};
> +
> +static char page[2048];
> +
> +int mtd_fixtrx(const char *mtd, size_t offset)
> +{
> + struct mtd_info_user mtd_info;
> + struct bootcounter *curr = (struct bootcounter *)page;
> + unsigned int i;
> + int last_count = 0;
> + int num_bc;
> + int fd;
> + int ret;
> +
> + fd = mtd_check_open(mtd);
> +
> + if (ioctl(fd, MEMGETINFO, &mtd_info) < 0) {
> + fprintf(stderr, "failed to get mtd info!");
or fix the missing newline here.
> + return -1;
> + }
> +
> + num_bc = mtd_info.size / mtd_info.writesize;
> +
> + for (i = 0; i < num_bc; i++) {
> + pread(fd, curr, sizeof(*curr), i * mtd_info.writesize);
> +
> + if (curr->magic != BOOTCOUNT_MAGIC && curr->magic !=
> 0x) {
> + printf("unexpected magic %08x, bailing out\n",
> curr->magic);
> + goto out;
> + }
> +
> + if (curr->magic == 0x)
> + break;
> +
> + last_count = curr->count;
> + }
> +
> + /* no need to do writes when last boot count is already 0 */
> + if (last_count == 0)
> + goto out;
> +
> +
> + if (i == num_bc) {
> + struct erase_info_user erase_info;
> + erase_info.start = 0;
> + erase_info.length = mtd_info.size;
> +
> + /* erase block */
> + ret = ioctl(fd, MEMERASE, &erase_info);
> + if (ret < 0) {
> + printf("failed to erase block: %i\n", ret);
> + return -1;
> + }
> +
> + i = 0;
> + }
> +
> + memset(curr, 0xff, mtd_info.writesize);
> +
> + curr->magic = BOOTCOUNT_MAGIC;
> + curr->count = 0;
> + curr->checksum = BOOTCOUNT_MAGIC;
> +
> + ret = pwrite(fd, curr, mtd_info.writesize, i * mtd_info.writesize);
> + if (ret < 0)
> + printf("failed to write: %i\n", ret);
> + sync();
> +out:
> + close(fd);
> +
> + return 0;
> +}
> diff --git a/target/linux/mvebu/base-files/etc/init.d/u-boot_env
> b/target/linux/mvebu/base-files/etc/init.d/u-boot_env
> index 82f36cb..2869dd6 100755
> --- a/target/linux/mvebu/base-files/etc/init.d/u-boot_env
> +++ b/target/linux/mvebu/base-files/etc/init.d/u-boot_env
> @@ -9,6 +9,7 @@ boot() {
> case $(mvebu_board_name) in
>
> armada-385-linksys-caiman|armada-385-linksys-cobra|armada-xp-linksys-mamba)
> fw_setenv auto_recovery off
> + mtd fixtrx s_env
> ;;
> esac
> }
> --
> 2.1.4
> ___
Re: [OpenWrt-Devel] Mount mmc block
On 18.08.2015 15:15, Baptiste Clenet wrote: > mount -t -ext3 On 18.08.2015 15:15, Baptiste Clenet wrote: > /dev/mmcblk0p1 11610 3781632 6 ***FAT16*** mounting FAT16 with ext3 param fails ? tune2fs is a part of e2fsprogs and probably cannot handle FAT16 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] Fix for mvebu (WRT1900AC/WRT1200AC/etc) boot counter
The uboot boot counter was never reset after a successful boot.
This patch prevents bootcmd and boot_part from becoming out of sync
after a sysupgrade and ensures the proper partition is booted.
Signed-off-by: Rob Mosher
---
package/system/mtd/Makefile| 2 +-
package/system/mtd/src/Makefile| 1 +
package/system/mtd/src/mvebu.c | 100 +
.../linux/mvebu/base-files/etc/init.d/u-boot_env | 1 +
4 files changed, 103 insertions(+), 1 deletion(-)
create mode 100644 package/system/mtd/src/mvebu.c
diff --git a/package/system/mtd/Makefile b/package/system/mtd/Makefile
index 8d7bb44..ae1922f 100644
--- a/package/system/mtd/Makefile
+++ b/package/system/mtd/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
include $(INCLUDE_DIR)/kernel.mk
PKG_NAME:=mtd
-PKG_RELEASE:=20
+PKG_RELEASE:=21
PKG_BUILD_DIR := $(KERNEL_BUILD_DIR)/$(PKG_NAME)
STAMP_PREPARED := $(STAMP_PREPARED)_$(call confvar,CONFIG_MTD_REDBOOT_PARTS)
diff --git a/package/system/mtd/src/Makefile b/package/system/mtd/src/Makefile
index 27ac339..3424dd2 100644
--- a/package/system/mtd/src/Makefile
+++ b/package/system/mtd/src/Makefile
@@ -10,6 +10,7 @@ obj.brcm47xx = $(obj.brcm)
obj.bcm53xx = $(obj.brcm)
obj.brcm63xx = imagetag.o
obj.ramips = $(obj.seama)
+obj.mvebu = mvebu.c
ifdef FIS_SUPPORT
obj += fis.o
diff --git a/package/system/mtd/src/mvebu.c b/package/system/mtd/src/mvebu.c
new file mode 100644
index 000..0929a97
--- /dev/null
+++ b/package/system/mtd/src/mvebu.c
@@ -0,0 +1,100 @@
+/*
+ * GPL Header ...
+ */
+
+
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include "mtd.h"
+
+#define BOOTCOUNT_MAGIC0x20110811
+
+struct bootcounter {
+ uint32_t magic;
+ uint32_t count;
+ uint32_t checksum;
+};
+
+static char page[2048];
+
+int mtd_fixtrx(const char *mtd, size_t offset)
+{
+ struct mtd_info_user mtd_info;
+ struct bootcounter *curr = (struct bootcounter *)page;
+ unsigned int i;
+ int last_count = 0;
+ int num_bc;
+ int fd;
+ int ret;
+
+ fd = mtd_check_open(mtd);
+
+ if (ioctl(fd, MEMGETINFO, &mtd_info) < 0) {
+ fprintf(stderr, "failed to get mtd info!");
+ return -1;
+ }
+
+ num_bc = mtd_info.size / mtd_info.writesize;
+
+ for (i = 0; i < num_bc; i++) {
+ pread(fd, curr, sizeof(*curr), i * mtd_info.writesize);
+
+ if (curr->magic != BOOTCOUNT_MAGIC && curr->magic !=
0x) {
+ printf("unexpected magic %08x, bailing out\n",
curr->magic);
+ goto out;
+ }
+
+ if (curr->magic == 0x)
+ break;
+
+ last_count = curr->count;
+ }
+
+ /* no need to do writes when last boot count is already 0 */
+ if (last_count == 0)
+ goto out;
+
+
+ if (i == num_bc) {
+ struct erase_info_user erase_info;
+ erase_info.start = 0;
+ erase_info.length = mtd_info.size;
+
+ /* erase block */
+ ret = ioctl(fd, MEMERASE, &erase_info);
+ if (ret < 0) {
+ printf("failed to erase block: %i\n", ret);
+ return -1;
+ }
+
+ i = 0;
+ }
+
+ memset(curr, 0xff, mtd_info.writesize);
+
+ curr->magic = BOOTCOUNT_MAGIC;
+ curr->count = 0;
+ curr->checksum = BOOTCOUNT_MAGIC;
+
+ ret = pwrite(fd, curr, mtd_info.writesize, i * mtd_info.writesize);
+ if (ret < 0)
+ printf("failed to write: %i\n", ret);
+ sync();
+out:
+ close(fd);
+
+ return 0;
+}
diff --git a/target/linux/mvebu/base-files/etc/init.d/u-boot_env
b/target/linux/mvebu/base-files/etc/init.d/u-boot_env
index 82f36cb..2869dd6 100755
--- a/target/linux/mvebu/base-files/etc/init.d/u-boot_env
+++ b/target/linux/mvebu/base-files/etc/init.d/u-boot_env
@@ -9,6 +9,7 @@ boot() {
case $(mvebu_board_name) in
armada-385-linksys-caiman|armada-385-linksys-cobra|armada-xp-linksys-mamba)
fw_setenv auto_recovery off
+ mtd fixtrx s_env
;;
esac
}
--
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v4 1/4] sunxi: don't copy DTS files to BIN_DIR
Matthias Schiffer wrote: The DTS files aren't useful (other targets don't copy them either) and clutter BIN_DIR with files unrelated to the chosen profile. Signed-off-by: Matthias Schiffer [snip] Thanks Matthias, I've committed the series in r46604-46608. Regards, Zoltan H ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v3] ramips: add support for Planex DB-WRT01
This patch add support for Planex DB-WRT01. DANBOARD route on
the MT7620A SoC with two Ethernet port and a 802.11n 2.4 GHz radio.
DANBOARD is Cartoon character.
Signed-off-by: YuheiOKAWA
---
target/linux/ramips/base-files/etc/board.d/01_leds | 3 +
.../linux/ramips/base-files/etc/board.d/02_network | 1 +
target/linux/ramips/base-files/etc/diag.sh | 1 +
target/linux/ramips/base-files/lib/ramips.sh | 3 +
.../ramips/base-files/lib/upgrade/platform.sh | 1 +
target/linux/ramips/dts/DB-WRT01.dts | 100 +
target/linux/ramips/image/Makefile | 2 +
7 files changed, 111 insertions(+)
create mode 100644 target/linux/ramips/dts/DB-WRT01.dts
diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds
b/target/linux/ramips/base-files/etc/board.d/01_leds
index 71cf3ac..a9959e3 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -87,6 +87,9 @@ d105)
ucidef_set_led_default "power" "POWER" "$board:red:power" "1"
set_usb_led "$board:green:usb"
;;
+db-wrt01)
+ ucidef_set_led_default "power" "power" "$board:orange:power" "1"
+ ;;
dcs-930l-b1)
ucidef_set_led_default "power" "POWER" "$board:red:power" "1"
ucidef_set_led_netdev "wifi" "WiFi" "$board:blue:wps"
diff --git a/target/linux/ramips/base-files/etc/board.d/02_network
b/target/linux/ramips/base-files/etc/board.d/02_network
index 6a2f042..02cd682 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -61,6 +61,7 @@ ramips_setup_interfaces()
;;
3g-6200n|\
ai-br100|\
+ db-wrt01|\
dir-300-b7|\
dir-320-b1|\
dir-610-a1|\
diff --git a/target/linux/ramips/base-files/etc/diag.sh
b/target/linux/ramips/base-files/etc/diag.sh
index a4911b0..f886b5d 100644
--- a/target/linux/ramips/base-files/etc/diag.sh
+++ b/target/linux/ramips/base-files/etc/diag.sh
@@ -94,6 +94,7 @@ get_status_led() {
y1s)
status_led="$board:blue:power"
;;
+ db-wrt01|\
esr-9753)
status_led="$board:orange:power"
;;
diff --git a/target/linux/ramips/base-files/lib/ramips.sh
b/target/linux/ramips/base-files/lib/ramips.sh
index 5cafd45..5b6808e 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -97,6 +97,9 @@ ramips_board_detect() {
*"DAP-1350")
name="dap-1350"
;;
+ *"DB-WRT01")
+ name="db-wrt01"
+ ;;
*"DCS-930")
name="dcs-930"
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index 53e7070..844ed5d 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -36,6 +36,7 @@ platform_check_image() {
cf-wr800n|\
d105|\
dap-1350|\
+ db-wrt01|\
dcs-930|\
dcs-930l-b1|\
dir-300-b1|\
diff --git a/target/linux/ramips/dts/DB-WRT01.dts
b/target/linux/ramips/dts/DB-WRT01.dts
new file mode 100644
index 000..d0fbaf3
--- /dev/null
+++ b/target/linux/ramips/dts/DB-WRT01.dts
@@ -0,0 +1,100 @@
+/dts-v1/;
+
+/include/ "mt7620a.dtsi"
+
+/ {
+ compatible = "ralink,mt7620a-soc";
+ model = "Planex DB-WRT01";
+
+ palmbus@1000 {
+ gpio1: gpio@638 {
+ status = "okay";
+ };
+
+ spi@b00 {
+ status = "okay";
+
+ m25p80@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "en25q64";
+ reg = <0 0>;
+ linux,modalias = "m25p80", "mx25l6405d";
+ spi-max-frequency = <1000>;
+
+ partition@0 {
+ label = "u-boot";
+ reg = <0x0 0x3>;
+ read-only;
+ };
+
+ partition@3 {
+ label = "u-boot-env";
+ reg = <0x3 0x1>;
+ read-only;
+ };
+
+ factory: partition@4 {
+ label = "factory";
+ reg = <0x4 0x1>;
+ read-only;
+ };
+
+ partition@5 {
+
Re: [OpenWrt-Devel] Mount mmc block
2015-08-18 11:59 GMT+02:00 Baptiste Clenet : > Hi, > > I'm trying to mount a emmc block on /mnt/mmc on a Ralink MT7628 board: > > root@OpenWrt:/# ls /dev/mmcblk0p1 > /dev/mmcblk0p1 > root@OpenWrt:/# ls /mnt/mmc/ > root@OpenWrt:/# mount -t -ext3 /dev/mmcblk0p1 /mnt/mmc/ > mount: mounting /dev/mmcblk0p1 on /mnt/mmc/ failed: No such device > > Am I missing something here? /mnt/mmc and /dev/mmcblk0p1 both exist. > > Regards, > > -- > Baptiste I'm using Kernel 4.1.0 btw. I tried to find the filesystem of /dev/mmcblk0p1 with root@OpenWrt:/# tune2fs -l /dev/mmcblk0p1 tune2fs 1.42.12 (29-Aug-2014) tune2fs: Bad magic number in super-block while trying to open /dev/mmcblk0p1 Couldn't find valid filesystem superblock. root@OpenWrt:/# fdisk Disk /dev/mmcblk0: 3875 MB, 3875536896 bytes 235 heads, 20 sectors/track, 1610 cylinders Units = cylinders of 4700 * 512 = 2406400 bytes Device Boot Start End Blocks Id System /dev/mmcblk0p1 11610 3781632 6 FAT16 How may I mount this partition? -- Baptiste ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Recommended settings ip6 DNS server / dnsmasq
> I could solve all issues and write a complete HOWTO (in French only at > first).http://wiki.openwrt.org/doc/howto/freebox That is nice to hear. > OpenWRT seems to provide at the same time stateful and stateless > adressing. Where you have option dhcpv6 and option ra you can add an option ra_management and set it to 0, 1 or 2. 0 means stateless only, 1 means stateless + stateful (default) 2 means stateful only Please note that stateful is not supported by all clients, e.g. all android-based devices will not have IPv6 connectivity with setting 2. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Recommended settings ip6 DNS server / dnsmasq
Le lundi 17 août 2015 à 20:32 +0200, Steven Barth a écrit : > is clearly a stateful address (/128) and your host got the host-id > 953 for stateful adressing. You should see the lease on the router > in the WebUi or under /tmp/hosts/odhcpd. There you can also see the > duid you need for adding the static lease. Dear Steven, I could solve all issues and write a complete HOWTO (in French only at first).http://wiki.openwrt.org/doc/howto/freebox My only question would be : OpenWRT seems to provide at the same time stateful and stateless adressing. Whatever I do, I always receive an IPv6 based on MAC when I would like my station to have only a stateful address. On the converse, if I request a stateless address, I also reveive a stateful address. Is there a way to avoid this? Kind regards, Gnutella smime.p7s Description: S/MIME cryptographic signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [package] base-files: sysupgrade: quote source image name
get_image() eval a filename without quoting it, resulting in errors with
filenames containing characters that need to be escaped.
$ sysupgrade -T -f ./cfg\(12\).tar.gz img.bin; echo $?
Image check 'platform_check_image' failed.
Invalid config file. Please use only .tar.gz files
1
$ mv cfg\(12\).tar.gz cfg_12.tar.gz
$ mv img\(1\).bin img.bin
sysupgrade -T -f ./cfg_12.tar.gz img.bin; echo $?
0
Enclose the content of $from in double quotes.
Signed-off-by: Adrien Schildknecht
---
package/base-files/files/lib/upgrade/common.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/package/base-files/files/lib/upgrade/common.sh
b/package/base-files/files/lib/upgrade/common.sh
index 189ef69..761b4c1 100644
--- a/package/base-files/files/lib/upgrade/common.sh
+++ b/package/base-files/files/lib/upgrade/common.sh
@@ -184,14 +184,14 @@ get_image() { # [ ]
*) cmd="cat";;
esac
if [ -z "$conc" ]; then
- local magic="$(eval $cmd $from 2>/dev/null | dd bs=2 count=1
2>/dev/null | hexdump -n 2 -e '1/1 "%02x"')"
+ local magic="$(eval $cmd \"$from\" 2>/dev/null | dd bs=2
count=1 2>/dev/null | hexdump -n 2 -e '1/1 "%02x"')"
case "$magic" in
1f8b) conc="zcat";;
425a) conc="bzcat";;
esac
fi
- eval "$cmd $from 2>/dev/null ${conc:+| $conc}"
+ eval "$cmd \"$from\" 2>/dev/null ${conc:+| $conc}"
}
get_magic_word() {
--
2.5.0
___
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 Minibox V1.0 support
On 18/08/2015 12:21, Karl Palsson wrote:
> John Crispin wrote:
>
>
>> On 17/08/2015 23:25, Karl Palsson wrote:
>>> Personally I'd like to see Gainstrong mentioned _somewhere_ in the patch
>>> itself.
>>>
+--- a/arch/mips/ath79/machtypes.h
b/arch/mips/ath79/machtypes.h
+@@ -74,6 +74,7 @@ enum ath79_mach_type {
+ ATH79_MACH_JA76PF2, /* jjPlus JA76PF2 */
+ ATH79_MACH_JWAP003, /* jjPlus JWAP003 */
+ ATH79_MACH_HORNET_UB, /* ALFA Networks Hornet-UB */
++ ATH79_MACH_MINIBOX_V1, /* MINIBOX V1.0 */
>>>
>
>> Its a comment, but feel free to send a patch to modify the comment.
>
> And my review comment is that retyping the define is useless, most of
> the defines use the comment to include a full name, normally including
> the vendor, in this case Gainstrong. This entire patch has no mention
> of the word Gainstrong in it at all, just "minibox" in various
> capitalizations. Do you have a particular reason to _encourage_
> omitting useful, common information? Is there a reason that this
> version as submitted would be _preferable_ to a version that followed
> the existing examples and included useful vendor information? Is there
> any reason that I would want to send a _patch_ to fix someone else's
> patch, that hasn't even been merged?
>
>
>>> Maybe here? Otherwise that comment is pretty irrelevant...
>>>
+ ATH79_MACH_MR12,/* Cisco Meraki MR12 */
+ ATH79_MACH_MR16,/* Cisco Meraki MR16 */
+ ATH79_MACH_MR600V2, /* OpenMesh MR600v2 */
>>>
>>> The ALLCAPS_PREFIX_ in the board file is... special? Have you seen that
>>> anywhere else?
>
>> -EPARSE
>
>
>
> -EAGAIN?
>
>>> +static const char *MINIBOX_V1_part_probes[] = {
>>> +static struct flash_platform_data MINIBOX_V1_flash_data = {
>>> +static struct gpio_led MINIBOX_V1_leds_gpio[] __initdata = {
>>> +static struct gpio_keys_button MINIBOX_V1_gpio_keys[] __initdata = {
>>> +static void __init MINIBOX_V1_setup(void)
>
these certainly need to be fixed ...
> I've never seen all caps used in the prefix of methods in board files.
> Truly, I'm not widely read, but that would seem to be very out of style.
> Is this a style you wish to encourage? If so, please let the community know
> so we can patch other files to bring them inline.
aha, its a rethoric question ... no, that that is not encouraged and
please don't send patches for that kind of stuff as it would not make
much sense
>
> Sincerely,
> Karl Palsson
>
>
___
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 Minibox V1.0 support
I can adapt the patch and send in a v3 of that's preferred.
Stijn
Op 17-aug.-2015 23:25 schreef Karl Palsson :
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Personally I'd like to see Gainstrong mentioned _somewhere_ in the patch
> itself.
>
> > +--- a/arch/mips/ath79/machtypes.h
> > b/arch/mips/ath79/machtypes.h
> > +@@ -74,6 +74,7 @@ enum ath79_mach_type {
> > + ATH79_MACH_JA76PF2, /* jjPlus JA76PF2 */
> > + ATH79_MACH_JWAP003, /* jjPlus JWAP003 */
> > + ATH79_MACH_HORNET_UB, /* ALFA Networks Hornet-UB */
> > ++ ATH79_MACH_MINIBOX_V1, /* MINIBOX V1.0 */
>
> Maybe here? Otherwise that comment is pretty irrelevant...
>
> > + ATH79_MACH_MR12, /* Cisco Meraki MR12 */
> > + ATH79_MACH_MR16, /* Cisco Meraki MR16 */
> > + ATH79_MACH_MR600V2, /* OpenMesh MR600v2 */
>
>
>
>
> The ALLCAPS_PREFIX_ in the board file is... special? Have you seen that
> anywhere else?
>
>
> Stijn Segers wrote:
> > This patch adds Gainstrong Minibox V1.0 into trunk.
> >
> > Don't have the device myself, so can't check on a possible
> > LED polarity issue, but I have built images and asked for testing
> > on the forum.
> >
> > Signed-off by: Stijn Segers
> > ---
> > target/linux/ar71xx/base-files/etc/diag.sh | 3 +
> > .../ar71xx/base-files/etc/uci-defaults/02_network | 1 +
> > target/linux/ar71xx/base-files/lib/ar71xx.sh | 6 ++
> > .../ar71xx/base-files/lib/upgrade/platform.sh | 1 +
> > target/linux/ar71xx/config-4.1 | 1 +
> > .../ar71xx/files/arch/mips/ath79/mach-minibox-v1.c | 85
> >++
> > target/linux/ar71xx/generic/profiles/minibox-v1.mk | 17 +
> > target/linux/ar71xx/image/Makefile | 9 +++
> > .../799-MIPS-ath79-add-minibox-v1-support.patch | 39 ++
> > 9 files changed, 162 insertions(+)
> > create mode 100644
> >target/linux/ar71xx/files/arch/mips/ath79/mach-minibox-v1.c
> > create mode 100644 target/linux/ar71xx/generic/profiles/minibox-v1.mk
> > create mode 100644
> >target/linux/ar71xx/patches-4.1/799-MIPS-ath79-add-minibox-v1-support.patch
> >
> > diff --git a/target/linux/ar71xx/base-files/etc/diag.sh
> > b/target/linux/ar71xx/base-files/etc/diag.sh
> > index 561c5da..8820609 100644
> > --- a/target/linux/ar71xx/base-files/etc/diag.sh
> > +++ b/target/linux/ar71xx/base-files/etc/diag.sh
> > @@ -216,6 +216,9 @@ get_status_led() {
> > smart-300)
> > status_led="nc-link:green:system"
> > ;;
> > + minibox-v1)
> > + status_led="minibox-v1:green:system"
> > + ;;
> > oolite)
> > status_led="oolite:red:system"
> > ;;
> > 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 2893e62..5506e3f 100755
> > --- a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
> > +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
> > @@ -417,6 +417,7 @@ dir-615-e4 |\
> > hiwifi-hc6361 |\
> > ja76pf |\
> > mc-mac1200r|\
> > +minibox-v1 |\
> > mynet-n600 |\
> > oolite |\
> > qihoo-c301 |\
> > diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
> > b/target/linux/ar71xx/base-files/lib/ar71xx.sh
> > index 256bd10..13324c3 100755
> > --- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
> > +++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
> > @@ -119,6 +119,9 @@ tplink_board_detect() {
> > "3C0001"*)
> > model="OOLITE"
> > ;;
> > + "3C0002"*)
> > + model="MINIBOX_V1"
> > + ;;
> > "070300"*)
> > model="TP-Link TL-WR703N"
> > ;;
> > @@ -499,6 +502,9 @@ ar71xx_board_detect() {
> > *"MAC1200R")
> > name="mc-mac1200r"
> > ;;
> > + *"MiniBox V1.0")
> > + name="minibox-v1"
> > + ;;
> > *MR12)
> > name="mr12"
> > ;;
> > diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
> > b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
> > index 76d8c5b..228b2df 100755
> > --- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
> > +++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
> > @@ -313,6 +313,7 @@ platform_check_image() {
> > el-mini | \
> > gl-inet | \
> > mc-mac1200r | \
> > + minibox-v1 |\
> > onion-omega | \
> > oolite | \
> > smart-300 | \
> > diff --git a/target/linux/ar71xx/config-4.1
> > b/target/linux/ar71xx/config-4.1
> > index 1e31a01..2ff4a66 100644
> > --- a/target/linux/ar71xx/config-4.1
> > +++ b/target/linux/ar71xx/config-4.1
> > @@ -78,6 +78,7 @@ CONFIG_ATH79_MACH_HORNET_UB=y
> > CONFIG_ATH79_MACH_JA76PF=y
> > CONFIG_ATH79_MACH_JWAP003=y
> > CONFIG_ATH79_MACH_MC_MAC1200R=y
> > +CONFIG_ATH79_MACH_MINIBOX_V1=y
> > CONFIG_ATH79_MACH_MR12=y
> > CONFIG_ATH79_MACH_MR16=y
> > CONFIG_ATH79_MACH_MR600=y
> > diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-minibox-v1.c
> > b/target/linux/ar71xx/files/arch/mips/ath79/mach-minibox-v1.c
> > new file mode 100644
> > index 000..c9fbbe5
> > --- /dev/null
> > +++
[OpenWrt-Devel] [PATCH] rules.mk : remove GCC 4.4 and GCC 4.5 conditional
gcc 4.4 was removed in r44957 gcc: remove 4.4.7 (only used by avr32) gcc 4.5 was removed in r36149 Signed-off-by: Dirk Neukirchen --- rules.mk | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/rules.mk b/rules.mk index 58b9f3e..819bea5 100644 --- a/rules.mk +++ b/rules.mk @@ -143,7 +143,7 @@ ifndef DUMP -include $(TOOLCHAIN_DIR)/info.mk export GCC_HONOUR_COPTS:=0 TARGET_CROSS:=$(if $(TARGET_CROSS),$(TARGET_CROSS),$(OPTIMIZE_FOR_CPU)-openwrt-linux$(if $(TARGET_SUFFIX),-$(TARGET_SUFFIX))-) -TARGET_CFLAGS+= -fhonour-copts $(if $(CONFIG_GCC_VERSION_4_4)$(CONFIG_GCC_VERSION_4_5),,-Wno-error=unused-but-set-variable) +TARGET_CFLAGS+= -fhonour-copts -Wno-error=unused-but-set-variable TARGET_CPPFLAGS+= -I$(TOOLCHAIN_DIR)/usr/include ifeq ($(CONFIG_USE_MUSL),y) TARGET_CPPFLAGS+= -I$(TOOLCHAIN_DIR)/include/fortify @@ -201,7 +201,7 @@ HOST_CPPFLAGS:=-I$(STAGING_DIR_HOST)/include -I$(STAGING_DIR_HOST)/usr/include HOST_CFLAGS:=-O2 $(HOST_CPPFLAGS) HOST_LDFLAGS:=-L$(STAGING_DIR_HOST)/lib -L$(STAGING_DIR_HOST)/usr/lib -ifeq ($(CONFIG_GCC_VERSION_4_4)$(CONFIG_GCC_VERSION_4_6)$(CONFIG_EXTERNAL_TOOLCHAIN),) +ifeq ($(CONFIG_GCC_VERSION_4_6)$(CONFIG_EXTERNAL_TOOLCHAIN),) TARGET_AR:=$(TARGET_CROSS)gcc-ar TARGET_RANLIB:=$(TARGET_CROSS)gcc-ranlib TARGET_NM:=$(TARGET_CROSS)gcc-nm -- 2.5.0 ___ 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 Minibox V1.0 support
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
John Crispin wrote:
>
>
> On 17/08/2015 23:25, Karl Palsson wrote:
> > Personally I'd like to see Gainstrong mentioned _somewhere_ in the patch
> > itself.
> >
> >> +--- a/arch/mips/ath79/machtypes.h
> >> b/arch/mips/ath79/machtypes.h
> >> +@@ -74,6 +74,7 @@ enum ath79_mach_type {
> >> + ATH79_MACH_JA76PF2, /* jjPlus JA76PF2 */
> >> + ATH79_MACH_JWAP003, /* jjPlus JWAP003 */
> >> + ATH79_MACH_HORNET_UB, /* ALFA Networks Hornet-UB */
> >> ++ ATH79_MACH_MINIBOX_V1, /* MINIBOX V1.0 */
> >
>
> Its a comment, but feel free to send a patch to modify the comment.
And my review comment is that retyping the define is useless, most of
the defines use the comment to include a full name, normally including
the vendor, in this case Gainstrong. This entire patch has no mention
of the word Gainstrong in it at all, just "minibox" in various
capitalizations. Do you have a particular reason to _encourage_
omitting useful, common information? Is there a reason that this
version as submitted would be _preferable_ to a version that followed
the existing examples and included useful vendor information? Is there
any reason that I would want to send a _patch_ to fix someone else's
patch, that hasn't even been merged?
>
> > Maybe here? Otherwise that comment is pretty irrelevant...
> >
> >> + ATH79_MACH_MR12,/* Cisco Meraki MR12 */
> >> + ATH79_MACH_MR16,/* Cisco Meraki MR16 */
> >> + ATH79_MACH_MR600V2, /* OpenMesh MR600v2 */
> >
> > The ALLCAPS_PREFIX_ in the board file is... special? Have you seen that
> > anywhere else?
>
> -EPARSE
>
>
- -EAGAIN?
>> +static const char *MINIBOX_V1_part_probes[] = {
>> +static struct flash_platform_data MINIBOX_V1_flash_data = {
>> +static struct gpio_led MINIBOX_V1_leds_gpio[] __initdata = {
>> +static struct gpio_keys_button MINIBOX_V1_gpio_keys[] __initdata = {
>> +static void __init MINIBOX_V1_setup(void)
I've never seen all caps used in the prefix of methods in board files.
Truly, I'm not widely read, but that would seem to be very out of style.
Is this a style you wish to encourage? If so, please let the community know
so we can patch other files to bring them inline.
Sincerely,
Karl Palsson
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAEBAgAGBQJV0wcWAAoJEBmotQ/U1cr2FUAQALqSPtknCawz8zqL5mfmjC4N
ynsNs6y3YQ8ZOc6RVTMdCLTvtNZmE1NZcrk7nAKVzrZBpXDCB6j6iPIal7fkM55m
+mrilQUwj2ZdFJ0Egfj4QFsdqc6LIth5WalpnkNqrnBsDEgUpUX6Vs+Xb8alJFhC
Iv+ILHvEif2ejlhM7Z/k39EzGsnDxLHUBY/tyJoVtJbOisO4oL73PXigjpx8cdrY
LcUoB3I84Pi2eLCo+iA2YOBioc3dR+ZY/lpSp+h0HF3XP8CYePsjbAa7H0LOJzC/
M44uXJoeGYQFSv23sVt6SZKFjFF6+rthMrf1WDLTH9NHU4venJsX/7Jn1XcVhcte
6QEZ60IYBTbXzw2GrN+p6dWYtGZia+blECXjhDCRqH6/72GdoD/XnVly4fH9M9HE
ekSjBMCCd7P6AWCwzf1z1Kg9adUQWOaajwSFyW75psb9f3p44tU8bpt0d82/aFam
+oCtcgjGoU6O7ndgH5QIYERIk9O65CZu90VQh5G2B1cYn1OE2ODoGMGr/yXNOWbs
t01vrbDtKKmkkpuyXwtDIulq8sOQhrAw0O37c7bIgGsH1CYUipEFyTDw2ngSalsO
7V3xsIRHK4/JHI4wUi17kK9r1h+5FSvFQIkHZuEyDR6/mdZ+GsO4zCf+YTghRjaK
bl+7Nsr+645uGFMuFfpb
=8o2o
-END PGP SIGNATURE-
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Mount mmc block
Hi, I'm trying to mount a emmc block on /mnt/mmc on a Ralink MT7628 board: root@OpenWrt:/# ls /dev/mmcblk0p1 /dev/mmcblk0p1 root@OpenWrt:/# ls /mnt/mmc/ root@OpenWrt:/# mount -t -ext3 /dev/mmcblk0p1 /mnt/mmc/ mount: mounting /dev/mmcblk0p1 on /mnt/mmc/ failed: No such device Am I missing something here? /mnt/mmc and /dev/mmcblk0p1 both exist. Regards, -- Baptiste ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 00/25] ramips: massive code cleanups
That wasn't less discouraging -- you shouldn't pathologize a behaviour if you simply want to express that they're being dicks. Piotr, thanks for your work, keep it up! On 18.08.2015 06:14, Jonathan Bennett wrote: > Those sort of emails are always just a bit discouraging. Keep in mind > that they tend to come from people that are slightly autistic or have > Aspergers. 0x7E86809F.asc Description: application/pgp-keys ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 00/25] ramips: massive code cleanups
Hello,
2015-08-18 6:04 GMT+02:00 郭传鈜 :
> Hi!
> I just wonder why you chose to use the board name in LED
> names?
Please, take a look at first version of my series and discussion about
"device:color:led-name" convention: [1].
I thought that OpenWrt uses different convention:
"manufacturer:color:led-name", but if you look deeper, we have both
approaches in code.
As an example, take a look at current version of diag.sh script in
ar71xx target [2].
There is exactly the same mix as it was in ramips target before my
cleans - some of boards follow upstream convention and rest don't.
> Sometimes we can use the same dts file for different boards.For
> example, in ar71xx wr841nd-v3 wr941nd-v2 and wr941nd-v3 shares
> mach-tl-wr941nd-v2.c(I haven't found such examples in ramips target.)I
> think the LED name will be a bit strange in this situation:-(
Yes, that's good point and I was thinking about the same problem.
IMHO, using same LED names for different boards is a mistake (assuming
that we switch to upstream convention).
Take TL-MR3420 v2 as an example ([3]) - for me it's not a TL-WR841N v8
"clone". They are similar from hardware POV (same platform, almost the
same specification), but manufacturer gave them different model names,
not without a reason.
That means all boards should have own names for LEDs. Question is how
to do it without duplicating and increasing code size.
What's more, what should we do with boards like TL-WR841N/ND vx -
should they share same code and use something like
"tl-wr841nx-vx:color:led-name" convention or separate that too
("tl-wr841n-v8:...", "tl-wr841nd-v8...", "tl-wr841nd-v7:..:", etc.)?
And what to do with clones like Mercury or Fast?
Maybe we should have separate mach-* files for all supported boards,
but then... what about DRY (don’t repeat yourself)?
Cheers,
Piotr
[1] http://patchwork.ozlabs.org/patch/500071/
[2]
https://dev.openwrt.org/browser/trunk/target/linux/ar71xx/base-files/etc/diag.sh
[3]
https://dev.openwrt.org/browser/trunk/target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wr841n-v8.c#L254
> 2015-08-17 19:24 GMT+08:00 Piotr Dymacz :
>> 2015-08-17 8:28 GMT+02:00 John Crispin :
>>> Hi,
>>>
>>> just merged the whole lot. thanks a lot. what do you want to do next
>>> lantiq or ar71xx ? :) personally i would prefer ar71xx ;)
>>> [...]
>>
>> Hello John,
>>
>> It seems that there are some people who don't like the changes (see
>> below), but they don't have enough courage to use their real name and
>> post their comments on the list.
>>
>> I will back with answers for your and Michael Heimpold (I'm sorry, I
>> didn't spot your e-mail before!) questions in few days. Now I'm really
>> busy with other things.
>>
>> Cheers,
>> Piotr Dymacz
>>
>> ---
>>
>> 2015-08-17 13:05 GMT+02:00 West Fuck :
>>> https://dev.openwrt.org/changeset/46617
>>>
>>> of all the bugs on related system you have choosen to change board and led
>>> names? why do you stick your nose into something that is not relevant? is it
>>> because your'e stupid fucking excuse for human being? you couldn't even make
>>> your uboot work without errors on some boards so why don't you stick to your
>>> own crap instead of acting like your're doing something
>> ___
>> 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
