Re: [OpenWrt-Devel] [PATCH][include] Reduce configuration file entropy
On 01.05.2013 01:21, Jonh Wendell wrote: didn't try the patch, but I'm all for it, as it fixes a really annoying behavior. 2013/4/30 Sergey Ryazanov ryazanov@gmail.com mailto:ryazanov@gmail.com Reducing entropy of configuration file, which is introduced by find utility, by applying sorting to its output. Find is used here to scan packages and targets subdirectories. Its output, known for its random ordering, determines the base order of configuration options. So let's fix that. Signed-off-by: Sergey Ryazanov ryazanov@gmail.com mailto:ryazanov@gmail.com --- I develop a custom firmware and I keep configuration file along with sources in repository. I was faced with following situation: after I modify the configuration by 'make menuconfig', some untouched configuration options could change its position in the file, what caused svn to generate very long diff. This patch is the attempt to solve this situation. Index: include/scan.mk http://scan.mk === --- include/scan.mk http://scan.mk (revision 36502) +++ include/scan.mk http://scan.mk (working copy) @@ -39,7 +39,7 @@ $(FILELIST): rm -f $(TMP_DIR)/info/.files-$(SCAN_TARGET)-* - $(call FIND_L, $(SCAN_DIR)) $(SCAN_EXTRA) -mindepth 1 $(if $(SCAN_DEPTH),-maxdepth $(SCAN_DEPTH)) -name Makefile | xargs grep -HE 'call (Build/DefaultTargets|Build(Package|Target)|.+Package)' | sed -e 's#^$(SCAN_DIR)/##' -e 's#/Makefile:.*##' | uniq $@ + $(call FIND_L, $(SCAN_DIR)) $(SCAN_EXTRA) -mindepth 1 $(if $(SCAN_DEPTH),-maxdepth $(SCAN_DEPTH)) -name Makefile | xargs grep -HE 'call (Build/DefaultTargets|Build(Package|Target)|.+Package)' | sed -e 's#^$(SCAN_DIR)/##' -e 's#/Makefile:.*##' | uniq | sort $@ What about `sort -u` instead of `uniq | sort` ? $(TMP_DIR)/info/.files-$(SCAN_TARGET).mk: $(FILELIST) ( \ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [package] dropbear: Supports IdleTimeout uci config option
Sorry if my previous mail sounded like a command - was not intended.
It's all about opinion. I prefer Do not add issues/mistakes/typos, if
you know about them.
You decide as its your contribution. And I'm only a contributor myself.
Maddes
On 06.09.2012 22:34, Jonh Wendell wrote:
hi!
before making the patch, I've read https://dev.openwrt.org/ticket/6992
I decided to go CamelCase to keep the current style and let the change
happen when that bug is fixed.
makes sense?
2012/9/6 Matthias Buecher / Germany m...@maddes.net
mailto:m...@maddes.net
Please use lowercase options like all other packages do.
Unfortunately DropBear is one package that has several Camel writings.
I wish that Attitude Adjustment would change this to lower case.
Maddes
On 06.09.2012 21:48, Jonh Wendell wrote:
Once this patch is accepted, I'll update the wiki page
http://wiki.openwrt.org/doc/uci/dropbear
From 9509ba3a76b014155671cbea72a07caafaf27970 Mon Sep 17 00:00:00 2001
From: Jonh Wendell jonh.wend...@oiwifi.com.br
mailto:jonh.wend...@oiwifi.com.br
mailto:jonh.wend...@oiwifi.com.br mailto:jonh.wend...@oiwifi.com.br
Date: Thu, 6 Sep 2012 16:45:29 -0300
Subject: [PATCH] [package] dropbear: Supports IdleTimeout uci config
option
Signed-off-by: Jonh Wendell jonh.wend...@oiwifi.com.br
mailto:jonh.wend...@oiwifi.com.br
mailto:jonh.wend...@oiwifi.com.br mailto:jonh.wend...@oiwifi.com.br
---
package/dropbear/files/dropbear.init |3 +++
1 file changed, 3 insertions(+)
diff --git a/package/dropbear/files/dropbear.init
b/package/dropbear/files/dropbear.init
index c909d28..5c03b32 100755
--- a/package/dropbear/files/dropbear.init
+++ b/package/dropbear/files/dropbear.init
@@ -81,6 +81,9 @@ dropbear_start()
[ -f ${val} ] append args -r ${val}
config_get val ${section} dsskeyfile
[ -f ${val} ] append args -d ${val}
+# H) idle timeout
+config_get val ${section} IdleTimeout 0
+[ ${val} -ne 0 ] append args -I ${val}
# execute program and return its exit code
[ ${verbosed} -ne 0 ] echo ${initscript}: section ${section}
starting ${PROG} ${args}
--
1.7.9.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org mailto:openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
--
Jonh Wendell
http://www.bani.com.br
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Matthias Maddes Bücher
--
http://www.maddes.net/
Home: Earth / Germany / Ruhr-Area
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] tools/firmware-utils/trx: new option -c to set flags in trx headers
Signed-off by: Matthias Buecher m...@maddes.net
- - - -
Setting the trx header flags can be very useful, for instance when
reverting/switching from DD-Wrt to OpenWrt.
It can emulate DD-Wrt's -noheader option with -c 1, so the image can be
flashed correctly, e.g. on Buffalo WZR-HP-G300NH with DD-Wrt installed.
But it also allows to set any value necessary.
Patch inline for comments and also attached.
Index: tools/firmware-utils/src/trx.c
===
--- tools/firmware-utils/src/trx.c (revision 32896)
+++ tools/firmware-utils/src/trx.c (working copy)
@@ -16,8 +16,11 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
-/* July 29, 2004
+/*
+ * Copyright (C) 2005-2012 OpenWrt.org
*
+ * July 29, 2004
+ *
* This is a hacked replacement for the 'trx' utility used to create
* wrt54g .trx firmware files. It isn't pretty, but it does the job
* for me.
@@ -41,6 +44,10 @@
* extend trx header struct for new version
* assume v1 for as default
* Add option -2 to allow v2 header
+ *
+ * July 27, 2012 - maddes
+ *
+ * Add option -c to allow specifying the flags in the header
*/
#include stdio.h
@@ -85,7 +92,8 @@
void usage(void)
{
fprintf(stderr, Usage:\n);
- fprintf(stderr, trx [-2] [-o outfile] [-m maxlen] [-a align] [-b
absolute offset] [-x relative offset]\n);
+ fprintf(stderr, trx [-2] [-o outfile] [-m maxlen] [-a align] [-c flag
value]\n);
+ fprintf(stderr, [-b absolute offset] [-x relative offset]\n);
fprintf(stderr, [-f file] [-f file [-f file [-f file (v2
only)]]]\n);
exit(EXIT_FAILURE);
}
@@ -103,10 +111,11 @@
uint32_t cur_len, fsmark=0;
unsigned long maxlen = TRX_MAX_LEN;
struct trx_header *p;
- char trx_version = 1;
+ uint16_t trx_version = 1;
unsigned char binheader[32];
+ uint16_t trx_flags = 0;
- fprintf(stderr, mjn3's trx replacement - v0.81.1\n);
+ fprintf(stderr, mjn3's trx replacement - v0.81.1 (OpenWrt.org
2012-07-27)\n);
if (!(buf = malloc(maxlen))) {
fprintf(stderr, malloc failed\n);
@@ -121,7 +130,7 @@
in = NULL;
i = 0;
- while ((c = getopt(argc, argv, -:2o:m:a:x:b:f:A:F:)) != -1) {
+ while ((c = getopt(argc, argv, -:2o:m:a:x:b:f:A:F:c:)) != -1) {
switch (c) {
case '2':
/* take care that nothing was written to buf so
far */
@@ -243,11 +252,25 @@
}
break;
+ case 'c':
+ errno = 0;
+ n = strtoul(optarg, e, 0);
+ if (errno || (e == optarg) || *e) {
+ fprintf(stderr, -c: illegal numeric
string\n);
+ usage();
+ }
+ if ((n 0) || (n 0x)) {
+ fprintf(stderr, WARNING: current flag
value exceeds 16 bits (and is truncated)\n);
+ trx_flags = n 0x;
+ } else {
+ trx_flags = n;
+ }
+ break;
default:
usage();
}
}
- p-flag_version = STORE32_LE((trx_version 16));
+ p-flag_version = STORE32_LE((trx_version 16) + trx_flags);
if (!in) {
fprintf(stderr, we require atleast one filename\n);
Index: tools/firmware-utils/src/trx.c
===
--- tools/firmware-utils/src/trx.c (revision 32896)
+++ tools/firmware-utils/src/trx.c (working copy)
@@ -16,8 +16,11 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
-/* July 29, 2004
+/*
+ * Copyright (C) 2005-2012 OpenWrt.org
*
+ * July 29, 2004
+ *
* This is a hacked replacement for the 'trx' utility used to create
* wrt54g .trx firmware files. It isn't pretty, but it does the job
* for me.
@@ -41,6 +44,10 @@
* extend trx header struct for new version
* assume v1 for as default
* Add option -2 to allow v2 header
+ *
+ * July 27, 2012 - maddes
+ *
+ * Add option -c to allow specifying the flags in the header
*/
#include stdio.h
@@ -85,7 +92,8 @@
void usage(void)
{
fprintf(stderr, Usage:\n);
- fprintf(stderr, trx [-2] [-o outfile] [-m maxlen] [-a align] [-b
absolute offset] [-x relative offset]\n);
+ fprintf(stderr, trx [-2] [-o outfile] [-m maxlen] [-a align] [-c flag
value]\n);
+ fprintf(stderr, [-b absolute offset] [-x relative offset]\n);
fprintf(stderr, [-f file] [-f file [-f file [-f file (v2
[OpenWrt-Devel] [PATCH] build system: reproduceable order in packageinfo and targetinfo
A) Use `sort -u` instead of just `uniq` B) First add kernel packages alphabetically sorted, then all others alphabetically sorted. This allows other packages to override kernel configs if necessary. Note: If find has no action for matches then also pruned folders are included in the result list, therefore specify the default action -print explicitly. Signed-off-by: Matthias Bücher m...@maddes.net Additional info: The current order of packages in tmp/.packageinfo (and targets in tmp/.targetinfo) is random. This is a problem when a package has to override a kernel config. For example the nfs-root package I currently work on has to set CONFIG_NFS_FS=y to work properly, so the package has to be after kmod-fs-nfs (CONFIG_NFS_FS=m) which is not possible with a random order. Patch is attached to avoid mangling (as with first sent mail), and following as text for review/comments. Index: include/scan.mk === --- include/scan.mk (revision 32786) +++ include/scan.mk (working copy) @@ -39,7 +39,12 @@ $(FILELIST): rm -f $(TMP_DIR)/info/.files-$(SCAN_TARGET)-* - $(call FIND_L, $(SCAN_DIR)) $(SCAN_EXTRA) -mindepth 1 $(if $(SCAN_DEPTH),-maxdepth $(SCAN_DEPTH)) -name Makefile | xargs grep -HE 'call (Build/DefaultTargets|Build(Package|Target)|.+Package)' | sed -e 's#^$(SCAN_DIR)/##' -e 's#/Makefile:.*##' | uniq $@ + rm -f $@ +ifeq ($(SCAN_DIR),package) +# Special case packages: kernel first; allows other packages to override kernel configs + $(call FIND_L, 'package/kernel') $(SCAN_EXTRA) -mindepth 1 $(if $(SCAN_DEPTH),-maxdepth $(SCAN_DEPTH)) -name Makefile -print | xargs grep -HE 'call (Build/DefaultTargets|Build(Package|Target)|.+Package)' | sed -e 's#^$(SCAN_DIR)/##' -e 's#/Makefile:.*##' | sort -u $@ +endif + $(call FIND_L, $(SCAN_DIR)) $(SCAN_EXTRA) -mindepth 1 $(if $(SCAN_DEPTH),-maxdepth $(SCAN_DEPTH)) -wholename 'package/kernel' -prune -o -name Makefile -print | xargs grep -HE 'call (Build/DefaultTargets|Build(Package|Target)|.+Package)' | sed -e 's#^$(SCAN_DIR)/##' -e 's#/Makefile:.*##' | sort -u $@ $(TMP_DIR)/info/.files-$(SCAN_TARGET).mk: $(FILELIST) ( \ Index: include/scan.mk === --- include/scan.mk (revision 32786) +++ include/scan.mk (working copy) @@ -39,7 +39,12 @@ $(FILELIST): rm -f $(TMP_DIR)/info/.files-$(SCAN_TARGET)-* - $(call FIND_L, $(SCAN_DIR)) $(SCAN_EXTRA) -mindepth 1 $(if $(SCAN_DEPTH),-maxdepth $(SCAN_DEPTH)) -name Makefile | xargs grep -HE 'call (Build/DefaultTargets|Build(Package|Target)|.+Package)' | sed -e 's#^$(SCAN_DIR)/##' -e 's#/Makefile:.*##' | uniq $@ + rm -f $@ +ifeq ($(SCAN_DIR),package) +# Special case packages: kernel first; allows other packages to override kernel configs + $(call FIND_L, 'package/kernel') $(SCAN_EXTRA) -mindepth 1 $(if $(SCAN_DEPTH),-maxdepth $(SCAN_DEPTH)) -name Makefile -print | xargs grep -HE 'call (Build/DefaultTargets|Build(Package|Target)|.+Package)' | sed -e 's#^$(SCAN_DIR)/##' -e 's#/Makefile:.*##' | sort -u $@ +endif + $(call FIND_L, $(SCAN_DIR)) $(SCAN_EXTRA) -mindepth 1 $(if $(SCAN_DEPTH),-maxdepth $(SCAN_DEPTH)) -wholename 'package/kernel' -prune -o -name Makefile -print | xargs grep -HE 'call (Build/DefaultTargets|Build(Package|Target)|.+Package)' | sed -e 's#^$(SCAN_DIR)/##' -e 's#/Makefile:.*##' | sort -u $@ $(TMP_DIR)/info/.files-$(SCAN_TARGET).mk: $(FILELIST) ( \ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [patch] orion/generic: enhanced image makefile
* Creation of uImage for WNR854T only done once (before 2x for jffs2 build and 1x for squashfs build) * Got rid of unneccessary padding of rootfs partition * ARM zImages always need a machine id, therefore do not copy generic (=no id) uImage to BIN_DIR, instead copy zImage * Generalized functions for easier re-using and enhancing (e.g. D-Link DNS 323 implementation would be only a couple lines) * Copy rootfs partitions to BIN_DIR, just like it is done for D-Link DNS 323 * Use variables to allows easily changing for custom builds, e.g. kernel mtd size for symbols * Size check of kernel files to avoid builds that break devices Signed-off by: Matthias Buecher m...@maddes.net Patch inline for comments and also attached if it gets mangled. Index: target/linux/orion/image/generic.mk === --- target/linux/orion/image/generic.mk (revision 32495) +++ target/linux/orion/image/generic.mk (working copy) @@ -1,5 +1,5 @@ # -# Copyright (C) 2008-2011 OpenWrt.org +# Copyright (C) 2008-2012 OpenWrt.org # # This is free software, licensed under the GNU General Public License v2. # See /LICENSE for more information. @@ -12,91 +12,207 @@ ### use round brackets for make variables, and curly brackets for shell variables + +## Kernel mtd partition size in KiB +KERNEL_MTD_SIZE:=1024 + +# Netgear WNR854T: erase size is 128KiB = 0x0002 = 131072 +ERASE_SIZE_WNR854T:=128 +UIMAGE_FILE_NAME_WNR854T:=uImage + +# Linksys WRT350N v2: erase size is 64KiB = 0x0001 = 65536 +ERASE_SIZE_WRT350Nv2:=64 + +# define JFFS2 sizes for include/image.mk +JFFS2_BLOCKSIZE:=64k 128k + + +### +### Image/Prepare +### + define Image/Prepare ### Dummy comment for indented calls of Image/Prepare - cp $(LINUX_DIR)/arch/arm/boot/uImage $(KDIR)/uImage + cp '$(LINUX_DIR)/arch/arm/boot/zImage' '$(BIN_DIR)/$(IMG_PREFIX)-zImage' endef + +### +### Image/BuildKernel +### + define Image/BuildKernel ### Dummy comment for indented calls of Image/BuildKernel - # Orion Kernel uImages - # WRT350N v2: mach id 1633 (0x661) - echo -en \x06\x1c\xa0\xe3\x61\x10\x81\xe3 $(KDIR)/wrt350nv2-zImage - cat $(LINUX_DIR)/arch/arm/boot/zImage $(KDIR)/wrt350nv2-zImage - $(STAGING_DIR_HOST)/bin/mkimage -A arm -O linux -T kernel \ - -C none -a 0x8000 -e 0x8000 -n 'Linux-$(LINUX_VERSION)' \ - -d $(KDIR)/wrt350nv2-zImage $(KDIR)/wrt350nv2-uImage - cp $(KDIR)/wrt350nv2-uImage $(BIN_DIR)/openwrt-wrt350nv2-uImage - # WNR854T: mach id 1801 (0x709) - echo -en \x07\x1c\xa0\xe3\x09\x10\x81\xe3 $(KDIR)/wnr854t-zImage - cat $(LINUX_DIR)/arch/arm/boot/zImage $(KDIR)/wnr854t-zImage - $(STAGING_DIR_HOST)/bin/mkimage -A arm -O linux -T kernel \ - -C none -a 0x8000 -e 0x8000 -n 'Linux-$(LINUX_VERSION)' \ - -d $(KDIR)/wnr854t-zImage $(KDIR)/wnr854t-uImage - cp $(KDIR)/wnr854t-uImage $(BIN_DIR)/openwrt-wnr854t-uImage + + ## Netgear WNR854T: mach id 1801 (0x0709) +$(call Image/BuildKernel/ARM/zImage,wnr854t,\x07\x1c\xa0\xe3\x09\x10\x81\xe3) +$(call Image/BuildKernel/ARM/uImage,wnr854t) + ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),y) # nothing more to do for a ramdisk build +$(call Image/BuildKernel/JFFS2uImage,wnr854t,$(ERASE_SIZE_WNR854T),$(UIMAGE_FILE_NAME_WNR854T)) +$(call Image/Default/FileSizeCheck,$(KDIR)/wnr854t-uImage.jffs2,$(shell expr $(KERNEL_MTD_SIZE) \* 1024)) + endif + + ## Linksys WRT350N v2: mach id 1633 (0x0661) +$(call Image/BuildKernel/ARM/zImage,wrt350nv2,\x06\x1c\xa0\xe3\x61\x10\x81\xe3) +$(call Image/BuildKernel/ARM/uImage,wrt350nv2) + ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),y) # nothing more to do for a ramdisk build +$(call Image/Default/FileSizeCheck,$(KDIR)/wrt350nv2-uImage,$(shell expr $(KERNEL_MTD_SIZE) \* 1024)) + endif +endef + +define Image/BuildKernel/ARM/zImage + # merge machine id and regular zImage into one file + # parameters: 1 = machine name, 2 = machine id as string in quotes + # $(BOARD) kernel zImage for $(1) + echo -en $(2) '$(KDIR)/$(1)-zImage' + cat '$(LINUX_DIR)/arch/arm/boot/zImage' '$(KDIR)/$(1)-zImage' + cp '$(KDIR)/$(1)-zImage' '$(BIN_DIR)/openwrt-$(1)-zImage' +endef + +define Image/BuildKernel/ARM/uImage + # create uImage from zImage + # parameters: 1 = machine name + # $(BOARD) kernel uImage for $(1) + '$(STAGING_DIR_HOST)/bin/mkimage' -A arm -O linux -T kernel \ + -C none -a 0x8000 -e 0x8000 -n 'Linux-$(LINUX_VERSION)' \ + -d '$(KDIR)/$(1)-zImage' '$(KDIR)/$(1)-uImage' + cp '$(KDIR)/$(1)-uImage' '$(BIN_DIR)/openwrt-$(1)-uImage' +endef + +define Image/BuildKernel/JFFS2uImage + # create JFFS2 partition with uImage file (result is already padded to erase size) + # parameters: 1 = machine name, 2 = erase size in KiB, 3 = uImage file name + # $(BOARD) kernel uImage for $(1) in JFFS2-$(2)k partition + rm -rf '$(TMP_DIR)/$(1)_jffs2_uimage' + mkdir '$(TMP_DIR)/$(1)_jffs2_uimage' + cp
Re: [OpenWrt-Devel] [PATCH] flexible kernel mtd size for orion_generic targets
http://patchwork.openwrt.org/patch/2046/
On 06.04.2012 18:31, Matthias Buecher / Germany wrote:
Add an image option for the Orion Generic targets, that allows to
specify the kernel mtd partition size.
The option takes care for necessary size extension when building with
symbols.
The value is also used for image generation (padding).
Plus:
- creation of ARM uImage generalized in image makefile
- sanitizing pathes in image makefile
- rebase of 300-dns323_partition_map.patch for current 3.0.18 kernel
Signed-off-by: Matthias Bücher m...@maddes.net
Patch is attached to prevent mail mangling and inline for comments:
Index: target/linux/orion/image/Config.in
===
--- target/linux/orion/image/Config.in(revision 0)
+++ target/linux/orion/image/Config.in(revision 0)
@@ -0,0 +1,18 @@
+config KERNEL_OPENWRT_KERNEL_MTD_SIZE
+ int
+ prompt Kernel MTD partition size in KiB (512 - 2048 in steps of 128)
+ range 512 2048
+ depends TARGET_orion
+ default 1152 if TARGET_orion_generic KERNEL_KALLSYMS
+ default 1024 if TARGET_orion_generic
+ default 1536 if TARGET_orion_dns323
+ help
+ Defines the size of the kernel's MTD partition in KiB (1 KiB =
1024
bytes).
+ This value is used in the device patches for defining the MTD
partitions.
+ Make sure that all patches for all devices make use of this
value.
+ The value is also used in the image file for correct padding
and more.
+ It is recommended to choose a size in 128KiB steps (biggest
erase size,
+ e.g. Netgear WNR854T).
+ Orion Generic target:
+ Before kernel 2.6.35: 1024KiB for all
+Since kernel 2.6.35: 1152KiB for kernel with symbols
Index: target/linux/orion/patches/020-flexible_kernel_mtd_size.patch
===
--- target/linux/orion/patches/020-flexible_kernel_mtd_size.patch
(revision 0)
+++ target/linux/orion/patches/020-flexible_kernel_mtd_size.patch
(revision 0)
@@ -0,0 +1,16 @@
+--- a/arch/arm/mach-orion5x/Kconfig
b/arch/arm/mach-orion5x/Kconfig
+@@ -155,6 +155,13 @@ config MACH_RD88F6183AP_GE
+ Say 'Y' here if you want your kernel to support the
+ Marvell Orion-1-90 (88F6183) AP GE RD.
+
++config OPENWRT_KERNEL_MTD_SIZE
++int
++prompt OpenWrt hack: Kernel MTD partition size in KiB
++default 1024
++help
++Defines the size of the kernel's MTD partition in KiB (1 KiB =
1024
bytes).
++This is just a help construct for OpenWrt to pass a value to the
kernel build process.
+ endmenu
+
+ endif
Index: target/linux/orion/patches/100-wrt350nv2_openwrt_partition_map.patch
===
---
target/linux/orion/patches/100-wrt350nv2_openwrt_partition_map.patch
(revision 31201)
+++
target/linux/orion/patches/100-wrt350nv2_openwrt_partition_map.patch
(working copy)
@@ -5,13 +5,13 @@
.name = kernel,
.offset = 0x,
-.size = 0x0076,
-+.size = 0x0010, // change to kernel mtd size
here (1/3)
++.size = (CONFIG_OPENWRT_KERNEL_MTD_SIZE * 1024),
// original was
0x001A (1664KiB)
}, {
.name = rootfs,
-.offset = 0x001a,
-.size = 0x005c,
-+.offset = 0x0010, // change to kernel mtd size
here (2/3)
-+.size = 0x0065, // adopt to kernel mtd size
here (3/3) =
0x0075 - kernel mtd size
++.offset = (CONFIG_OPENWRT_KERNEL_MTD_SIZE * 1024),
// original was
0x001A (1664KiB)
++.size = (0x0075 - (CONFIG_OPENWRT_KERNEL_MTD_SIZE
* 1024)), //
exclude area with eRcOmM signature
}, {
.name = lang,
.offset = 0x0076,
Index: target/linux/orion/patches/101-wnr854t_partition_map.patch
===
--- target/linux/orion/patches/101-wnr854t_partition_map.patch
(revision
31201)
+++ target/linux/orion/patches/101-wnr854t_partition_map.patch(working
copy)
@@ -1,6 +1,18 @@
--- a/arch/arm/mach-orion5x/wnr854t-setup.c
+++ b/arch/arm/mach-orion5x/wnr854t-setup.c
-@@ -67,6 +67,10 @@ static struct mtd_partition wnr854t_nor_
+@@ -58,15 +58,19 @@ static struct mtd_partition wnr854t_nor_
+ {
+ .name = kernel,
+ .offset = 0x,
+-.size = 0x0010,
++.size = (CONFIG_OPENWRT_KERNEL_MTD_SIZE * 1024),
+ }, {
+ .name = rootfs
Re: [OpenWrt-Devel] [PATCH] flexible kernel mtd size for orion_generic targets
On 07.04.2012 20:28, Imre Kaloz wrote: On Fri, 06 Apr 2012 18:31:13 +0200, Matthias Buecher / Germany m...@maddes.net wrote: Add an image option for the Orion Generic targets, that allows to specify the kernel mtd partition size. The option takes care for necessary size extension when building with symbols. The value is also used for image generation (padding). snip As I've told this before, I can't accept the idea nor the design. If you need a kernel with more things compiled in for testing, you can tftpboot it and you won't be limited by the partitions. Imre Hello Imre, it's not about flashing a kernel with more modules integrated for me. It's about a normal image with symbols for others. It takes a lot of time to explain someone on the forum or in mails what and how to get a working image with symbols, just to get an oops report with symbols. (With a kernel plus symbols nbd could find an alignment error and he told me there will be more not yet found.) The solution is very simple and clean, plus everybody can build an image with symbols without any source changes, compilation issues or runtime issues. While others want to build an even smaller image than the default one due to their special demands. Of course it would be much easier to give the mtd partitions via the kernel command line just like it is done for ar71xx targets. But I do not have the knowledge to develop this for all Orion targets, also I do not have the devices to test (although Nilfred would be willing to sacrifice his WNR854T). Another solution for different kernel sizes would be to use a dynamic mtd partition uImage split similar as it is done for Lantiq targets. I already created the code for this, which could even go into the generic patches as it doesn't have the logic errors of the Lantiq targets. It would be great if there would be a solution for this on Orion, but also a general OpenWrt way would help lots of people willing to help on oops reports and willing to contribute. Any help is greatly appreciated. Regards Maddes ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] flexible kernel mtd size for orion_generic targets
Add an image option for the Orion Generic targets, that allows to
specify the kernel mtd partition size.
The option takes care for necessary size extension when building with
symbols.
The value is also used for image generation (padding).
Plus:
- creation of ARM uImage generalized in image makefile
- sanitizing pathes in image makefile
- rebase of 300-dns323_partition_map.patch for current 3.0.18 kernel
Signed-off-by: Matthias Bücher m...@maddes.net
Patch is attached to prevent mail mangling and inline for comments:
Index: target/linux/orion/image/Config.in
===
--- target/linux/orion/image/Config.in (revision 0)
+++ target/linux/orion/image/Config.in (revision 0)
@@ -0,0 +1,18 @@
+config KERNEL_OPENWRT_KERNEL_MTD_SIZE
+ int
+ prompt Kernel MTD partition size in KiB (512 - 2048 in steps of 128)
+ range 512 2048
+ depends TARGET_orion
+ default 1152 if TARGET_orion_generic KERNEL_KALLSYMS
+ default 1024 if TARGET_orion_generic
+ default 1536 if TARGET_orion_dns323
+ help
+ Defines the size of the kernel's MTD partition in KiB (1 KiB =
1024
bytes).
+ This value is used in the device patches for defining the MTD
partitions.
+ Make sure that all patches for all devices make use of this
value.
+ The value is also used in the image file for correct padding
and more.
+ It is recommended to choose a size in 128KiB steps (biggest
erase size,
+ e.g. Netgear WNR854T).
+ Orion Generic target:
+ Before kernel 2.6.35: 1024KiB for all
+ Since kernel 2.6.35: 1152KiB for kernel with symbols
Index: target/linux/orion/patches/020-flexible_kernel_mtd_size.patch
===
--- target/linux/orion/patches/020-flexible_kernel_mtd_size.patch
(revision 0)
+++ target/linux/orion/patches/020-flexible_kernel_mtd_size.patch
(revision 0)
@@ -0,0 +1,16 @@
+--- a/arch/arm/mach-orion5x/Kconfig
b/arch/arm/mach-orion5x/Kconfig
+@@ -155,6 +155,13 @@ config MACH_RD88F6183AP_GE
+ Say 'Y' here if you want your kernel to support the
+ Marvell Orion-1-90 (88F6183) AP GE RD.
+
++config OPENWRT_KERNEL_MTD_SIZE
++ int
++ prompt OpenWrt hack: Kernel MTD partition size in KiB
++ default 1024
++ help
++ Defines the size of the kernel's MTD partition in KiB (1 KiB =
1024
bytes).
++ This is just a help construct for OpenWrt to pass a value to the
kernel build process.
+ endmenu
+
+ endif
Index: target/linux/orion/patches/100-wrt350nv2_openwrt_partition_map.patch
===
---
target/linux/orion/patches/100-wrt350nv2_openwrt_partition_map.patch
(revision 31201)
+++
target/linux/orion/patches/100-wrt350nv2_openwrt_partition_map.patch
(working copy)
@@ -5,13 +5,13 @@
.name = kernel,
.offset = 0x,
- .size = 0x0076,
-+ .size = 0x0010, // change to kernel mtd size
here (1/3)
++ .size = (CONFIG_OPENWRT_KERNEL_MTD_SIZE * 1024),
// original was
0x001A (1664KiB)
}, {
.name = rootfs,
- .offset = 0x001a,
- .size = 0x005c,
-+ .offset = 0x0010, // change to kernel mtd size
here (2/3)
-+ .size = 0x0065, // adopt to kernel mtd size
here (3/3) =
0x0075 - kernel mtd size
++ .offset = (CONFIG_OPENWRT_KERNEL_MTD_SIZE * 1024),
// original was
0x001A (1664KiB)
++ .size = (0x0075 - (CONFIG_OPENWRT_KERNEL_MTD_SIZE
* 1024)), //
exclude area with eRcOmM signature
}, {
.name = lang,
.offset = 0x0076,
Index: target/linux/orion/patches/101-wnr854t_partition_map.patch
===
--- target/linux/orion/patches/101-wnr854t_partition_map.patch (revision
31201)
+++ target/linux/orion/patches/101-wnr854t_partition_map.patch (working
copy)
@@ -1,6 +1,18 @@
--- a/arch/arm/mach-orion5x/wnr854t-setup.c
+++ b/arch/arm/mach-orion5x/wnr854t-setup.c
-@@ -67,6 +67,10 @@ static struct mtd_partition wnr854t_nor_
+@@ -58,15 +58,19 @@ static struct mtd_partition wnr854t_nor_
+ {
+ .name = kernel,
+ .offset = 0x,
+- .size = 0x0010,
++ .size = (CONFIG_OPENWRT_KERNEL_MTD_SIZE * 1024),
+ }, {
+ .name = rootfs,
+- .offset = 0x0010,
+- .size = 0x0066,
++ .offset =
Re: [OpenWrt-Devel] WBMR-HP-G300H flash image for flashing from original FW?
On 23.02.2012 19:21, John Crispin wrote: On 23/02/12 19:19, Christoph Thielecke wrote: Hello, after got this device I'm just wonder a little bit why there is no image for flashing from original dd-wrt web interface. It should not hard to build this bin file (as for brcm47xx). It would be make life easier if there is the possibility to flash directly from dd-wrt webif. With best regards Christoph most likely true... i will investigate how to do so DD-Wrt normally awaits a TRX flash image (HDR0 header) with the noheader flag set. See https://forum.openwrt.org/viewtopic.php?pid=154817#p154817 Maddes ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Let's fix the OpenWrt patch acceptance problem!
On 23.01.2012 20:33, Felix Fietkau wrote: As you've probably noticed, we've had issues keeping up with the workload of incoming patches. There is quite a bit of work involved in taking care of incoming patches, not just review. Patches need to be compile tested, ideally also runtime tested, and checked for dependency issues. Most of the time, this work is left up to the limited number of people that have SVN access. People often complain that it's hard to get involved, because it takes a long time to get SVN access, and the rules for that may not always be clear. In my opinion, the main issue is not that we don't give out SVN access fast enough, it's that people consider SVN access necessary for contributing in the first place. If we change the way patches are accepted to no longer depend on that, it becomes much easier for people to start. To be able to do that properly, it is important that patches still get reviewed and tested, but we can decentralize this work to split it up among a bigger group. One way to do this would be to have a group of people - with or without SVN access - maintaining a git tree with proposed changes to /trunk or /packages. This tree should be frequently rebased to latest SVN. This allows any developer with SVN access to spend a few minutes a day looking over the tree, giving it a quick sanity check, and then flushing all changes into SVN. With proper care by the tree maintainers, author attribution and review annotations can be easily put into the commit messages to ensure that they are preserved during the commit to SVN. With such a tree, the typical lifetime of a patch could look somewhat like this: - User proposes a patch on the list. - Core developer does a superficial review on patchwork, assigns it to the patch team, possibly with comments on what to test or look out for - Somebody from the patch team picks up the patch, tests it, ACKs it. - Patch gets added to the proposed-changes tree. - A developer with SVN access flushes the proposed-changes tree into SVN. One nice thing about this workflow is that aside from a few scripts to simplify dealing with constantly rebased git trees, we have all the tools we need to implement this. Does this proposal make sense? Do we have any volunteers that are willing to organize and take care of maintaining the tree and compile testing and reviewing the incoming changes? Sounds promising. Count me in for target/linux/orion Maddes ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] update wrt350nv2-builder to v2.4 and use new functionality for target orion_generic
Who is actively responsible for the Orion targets?
(Kaloz did not react on my mails in December.)
Maddes
On 16.12.2011 20:03, Matthias Buecher / Germany wrote:
http://patchwork.openwrt.org/patch/1646/
On 04.12.2011 20:52, Matthias Buecher / Germany wrote:
Signed-off-by: Matthias Bücher m...@maddes.net
Patch is attached and inline for comments
Regards
Maddes
Index: tools/wrt350nv2-builder/Makefile
===
--- tools/wrt350nv2-builder/Makefile(revision 29422)
+++ tools/wrt350nv2-builder/Makefile(working copy)
@@ -1,5 +1,5 @@
#
-# Copyright (C) 2006-2010 OpenWrt.org
+# Copyright (C) 2006-2011 OpenWrt.org
#
# This is free software, licensed under the GNU General Public License v2.
# See /LICENSE for more information.
@@ -8,7 +8,7 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=wrt350nv2-builder
-PKG_VERSION:=2.3
+PKG_VERSION:=2.4
HOST_BUILD_DIR:=$(BUILD_DIR_HOST)/${PKG_NAME}-$(PKG_VERSION)
Index: tools/wrt350nv2-builder/src/wrt350nv2-builder.c
===
--- tools/wrt350nv2-builder/src/wrt350nv2-builder.c (revision 29422)
+++ tools/wrt350nv2-builder/src/wrt350nv2-builder.c (working copy)
@@ -1,8 +1,8 @@
/*
- WRT350Nv2-Builder 2.3 (previously called buildimg)
+ WRT350Nv2-Builder 2.4 (previously called buildimg)
Copyright (C) 2008-2009 Dirk Teurlings i...@upexia.nl
- Copyright (C) 2009-2010 Matthias Buecher (http://www.maddes.net/)
+ Copyright (C) 2009-2011 Matthias Buecher (http://www.maddes.net/)
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
@@ -33,6 +33,9 @@
:u-boot 0 /path/to/u-boot.bin
#version0x2020
+ Additionally since v2.4 an already complete image can be used:
+ :image 0
/path/to/openwrt-wrt350nv2-[squashfs|jffs2-64k].img
+
args:
1 wrt350nv2.par parameter file describing the
image layout
2 wrt350nv2.img output file for linksys style
image
@@ -62,6 +65,8 @@
https://forum.openwrt.org/viewtopic.php?pid=92928#p92928
Changelog:
+ v2.4 - added :image definition for parameter file, this allows
+ to use a complete sysupgrade image without any kernel size check
v2.3 - allow jffs by adding its magic number (0x8519)
added parameter option -i to ignore unknown magic numbers
v2.2 - fixed checksum byte calculation for other versions than 0x2019
@@ -92,7 +97,7 @@
// version info
-#define VERSION 2.3
+#define VERSION 2.4
char program_info[] = WRT350Nv2-Builder v%s by Dirk Teurlings
i...@upexia.nl and Matthias Buecher (http://www.maddes.net/)\n;
// verbosity
@@ -112,6 +117,7 @@
mtd_info mtd_kernel = { kernel, 0, 0, NULL, 0L, { 0, 0 } };
mtd_info mtd_rootfs = { rootfs, 0, 0, NULL, 0L, { 0, 0 } };
+mtd_info mtd_image = { image, 0, 0, NULL, 0L, { 0, 0 } };
mtd_info mtd_uboot = { u-boot, 0, 0, NULL, 0L, { 0, 0 } };
#define ROOTFS_END_OFFSET 0x0076
@@ -281,6 +287,8 @@
mtd = mtd_rootfs;
} else if (!strcmp(string1,
mtd_uboot.name)) {
mtd = mtd_uboot;
+ } else if (!strcmp(string1,
mtd_image.name)) {
+ mtd = mtd_image;
}
if (!mtd) {
@@ -404,20 +412,24 @@
// add files
if (!exitcode) {
- for (i = 1; i = 3; i++) {
+ for (i = 1; i = 4; i++) {
addsize = 0;
padsize = 0;
switch (i) {
case 1:
+ mtd = mtd_image;
+ padsize = ROOTFS_MIN_OFFSET -
mtd-filesize;
+ break;
+ case 2:
mtd = mtd_kernel;
break;
- case 2:
+ case 3:
mtd = mtd_rootfs;
addsize = mtd-filesize;
padsize = ROOTFS_MIN_OFFSET -
mtd_kernel.size - mtd-filesize;
break;
- case 3:
+ case 4:
mtd = mtd_uboot;
addsize = mtd-filesize;
break;
@@ -723,7 +735,6 @@
int i;
mtd_info *mtd;
- int mandatory;
int noupdate;
int sizecheck;
int magiccheck;
@@ -934,28 +945,30
Re: [OpenWrt-Devel] [PATCH] update wrt350nv2-builder to v2.4 and use new functionality for target orion_generic
Is anybody so kind and can commit this patch.
http://patchwork.openwrt.org/patch/1645/
Thanks
Maddes
On 04.12.2011 20:52, Matthias Buecher / Germany wrote:
Signed-off-by: Matthias Bücher m...@maddes.net
Patch is attached and inline for comments
Regards
Maddes
Index: tools/wrt350nv2-builder/Makefile
===
--- tools/wrt350nv2-builder/Makefile (revision 29422)
+++ tools/wrt350nv2-builder/Makefile (working copy)
@@ -1,5 +1,5 @@
#
-# Copyright (C) 2006-2010 OpenWrt.org
+# Copyright (C) 2006-2011 OpenWrt.org
#
# This is free software, licensed under the GNU General Public License v2.
# See /LICENSE for more information.
@@ -8,7 +8,7 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=wrt350nv2-builder
-PKG_VERSION:=2.3
+PKG_VERSION:=2.4
HOST_BUILD_DIR:=$(BUILD_DIR_HOST)/${PKG_NAME}-$(PKG_VERSION)
Index: tools/wrt350nv2-builder/src/wrt350nv2-builder.c
===
--- tools/wrt350nv2-builder/src/wrt350nv2-builder.c (revision 29422)
+++ tools/wrt350nv2-builder/src/wrt350nv2-builder.c (working copy)
@@ -1,8 +1,8 @@
/*
- WRT350Nv2-Builder 2.3 (previously called buildimg)
+ WRT350Nv2-Builder 2.4 (previously called buildimg)
Copyright (C) 2008-2009 Dirk Teurlings i...@upexia.nl
- Copyright (C) 2009-2010 Matthias Buecher (http://www.maddes.net/)
+ Copyright (C) 2009-2011 Matthias Buecher (http://www.maddes.net/)
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
@@ -33,6 +33,9 @@
:u-boot 0 /path/to/u-boot.bin
#version0x2020
+ Additionally since v2.4 an already complete image can be used:
+ :image 0
/path/to/openwrt-wrt350nv2-[squashfs|jffs2-64k].img
+
args:
1 wrt350nv2.par parameter file describing the
image layout
2 wrt350nv2.img output file for linksys style
image
@@ -62,6 +65,8 @@
https://forum.openwrt.org/viewtopic.php?pid=92928#p92928
Changelog:
+ v2.4 - added :image definition for parameter file, this allows
+to use a complete sysupgrade image without any kernel size check
v2.3 - allow jffs by adding its magic number (0x8519)
added parameter option -i to ignore unknown magic numbers
v2.2 - fixed checksum byte calculation for other versions than 0x2019
@@ -92,7 +97,7 @@
// version info
-#define VERSION 2.3
+#define VERSION 2.4
char program_info[] = WRT350Nv2-Builder v%s by Dirk Teurlings
i...@upexia.nl and Matthias Buecher (http://www.maddes.net/)\n;
// verbosity
@@ -112,6 +117,7 @@
mtd_info mtd_kernel = { kernel, 0, 0, NULL, 0L, { 0, 0 } };
mtd_info mtd_rootfs = { rootfs, 0, 0, NULL, 0L, { 0, 0 } };
+mtd_info mtd_image = { image, 0, 0, NULL, 0L, { 0, 0 } };
mtd_info mtd_uboot = { u-boot, 0, 0, NULL, 0L, { 0, 0 } };
#define ROOTFS_END_OFFSET0x0076
@@ -281,6 +287,8 @@
mtd = mtd_rootfs;
} else if (!strcmp(string1,
mtd_uboot.name)) {
mtd = mtd_uboot;
+ } else if (!strcmp(string1,
mtd_image.name)) {
+ mtd = mtd_image;
}
if (!mtd) {
@@ -404,20 +412,24 @@
// add files
if (!exitcode) {
- for (i = 1; i = 3; i++) {
+ for (i = 1; i = 4; i++) {
addsize = 0;
padsize = 0;
switch (i) {
case 1:
+ mtd = mtd_image;
+ padsize = ROOTFS_MIN_OFFSET -
mtd-filesize;
+ break;
+ case 2:
mtd = mtd_kernel;
break;
- case 2:
+ case 3:
mtd = mtd_rootfs;
addsize = mtd-filesize;
padsize = ROOTFS_MIN_OFFSET -
mtd_kernel.size - mtd-filesize;
break;
- case 3:
+ case 4:
mtd = mtd_uboot;
addsize = mtd-filesize;
break;
@@ -723,7 +735,6 @@
int i;
mtd_info *mtd;
- int mandatory;
int noupdate;
int sizecheck;
int magiccheck
Re: [OpenWrt-Devel] [patch] target orion_generic: use magic_long in sysupgrade
Is anybody so kind and can commit this patch too.
http://patchwork.openwrt.org/patch/1645/
Thanks
Maddes
On 04.12.2011 20:21, Matthias Buecher / Germany wrote:
Signed-off-by: Matthias Bücher m...@maddes.net
Patch is attached and inline for comments
Regards
Maddes
Index: target/linux/orion/generic/base-files/lib/upgrade/platform.sh
===
--- target/linux/orion/generic/base-files/lib/upgrade/platform.sh
(revision 29422)
+++ target/linux/orion/generic/base-files/lib/upgrade/platform.sh
(working copy)
@@ -1,3 +1,7 @@
+#
+# Copyright (C) 2010-2011 OpenWrt.org
+#
+
# use default image for PART_NAME
# use default for platform_do_upgrade()
@@ -6,17 +10,20 @@
local hardware=`sed -n /Hardware/s/.*:.//p /proc/cpuinfo`
local magic=$(get_magic_word $1)
+ local magic_long=$(get_magic_long $1)
case ${hardware} in
- # hardware with padded uImage + padded rootfs
+ # hardware with a direct uImage partition
+ # image header format as described in U-Boot's include/image.h
+ # see
http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=include/image.h
'Linksys WRT350N v2')
- [ ${magic} != '2705' ] {
- echo Invalid image type ${magic}.
+ [ ${magic_long} != '27051956' ] {
+ echo Invalid image type ${magic_long}.
return 1
}
return 0
;;
- # Netgear WNR854T has extra header before uImage
+ # Netgear WNR854T (has uImage as file inside a JFFS2 partition)
'Netgear WNR854T')
[ ${magic} != '8519' ] {
echo Invalid image type ${magic}.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Matthias Maddes Bücher
--
http://www.maddes.net/
Home: Earth / Germany / Ruhr-Area
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] update wrt350nv2-builder to v2.4 and use new functionality for target orion_generic
Correction:
http://patchwork.openwrt.org/patch/1646/
On 16.12.2011 20:01, Matthias Buecher / Germany wrote:
Is anybody so kind and can commit this patch.
http://patchwork.openwrt.org/patch/1645/
Thanks
Maddes
On 04.12.2011 20:52, Matthias Buecher / Germany wrote:
Signed-off-by: Matthias Bücher m...@maddes.net
Patch is attached and inline for comments
Regards
Maddes
Index: tools/wrt350nv2-builder/Makefile
===
--- tools/wrt350nv2-builder/Makefile (revision 29422)
+++ tools/wrt350nv2-builder/Makefile (working copy)
@@ -1,5 +1,5 @@
#
-# Copyright (C) 2006-2010 OpenWrt.org
+# Copyright (C) 2006-2011 OpenWrt.org
#
# This is free software, licensed under the GNU General Public License v2.
# See /LICENSE for more information.
@@ -8,7 +8,7 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=wrt350nv2-builder
-PKG_VERSION:=2.3
+PKG_VERSION:=2.4
HOST_BUILD_DIR:=$(BUILD_DIR_HOST)/${PKG_NAME}-$(PKG_VERSION)
Index: tools/wrt350nv2-builder/src/wrt350nv2-builder.c
===
--- tools/wrt350nv2-builder/src/wrt350nv2-builder.c (revision 29422)
+++ tools/wrt350nv2-builder/src/wrt350nv2-builder.c (working copy)
@@ -1,8 +1,8 @@
/*
-WRT350Nv2-Builder 2.3 (previously called buildimg)
+WRT350Nv2-Builder 2.4 (previously called buildimg)
Copyright (C) 2008-2009 Dirk Teurlings i...@upexia.nl
-Copyright (C) 2009-2010 Matthias Buecher (http://www.maddes.net/)
+Copyright (C) 2009-2011 Matthias Buecher (http://www.maddes.net/)
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
@@ -33,6 +33,9 @@
:u-boot 0 /path/to/u-boot.bin
#version0x2020
+Additionally since v2.4 an already complete image can be used:
+:image 0
/path/to/openwrt-wrt350nv2-[squashfs|jffs2-64k].img
+
args:
1 wrt350nv2.par parameter file describing the
image layout
2 wrt350nv2.img output file for linksys style
image
@@ -62,6 +65,8 @@
https://forum.openwrt.org/viewtopic.php?pid=92928#p92928
Changelog:
+v2.4 - added :image definition for parameter file, this allows
+ to use a complete sysupgrade image without any kernel size check
v2.3 - allow jffs by adding its magic number (0x8519)
added parameter option -i to ignore unknown magic numbers
v2.2 - fixed checksum byte calculation for other versions than 0x2019
@@ -92,7 +97,7 @@
// version info
-#define VERSION 2.3
+#define VERSION 2.4
char program_info[] = WRT350Nv2-Builder v%s by Dirk Teurlings
i...@upexia.nl and Matthias Buecher (http://www.maddes.net/)\n;
// verbosity
@@ -112,6 +117,7 @@
mtd_info mtd_kernel = { kernel, 0, 0, NULL, 0L, { 0, 0 } };
mtd_info mtd_rootfs = { rootfs, 0, 0, NULL, 0L, { 0, 0 } };
+mtd_info mtd_image = { image, 0, 0, NULL, 0L, { 0, 0 } };
mtd_info mtd_uboot = { u-boot, 0, 0, NULL, 0L, { 0, 0 } };
#define ROOTFS_END_OFFSET 0x0076
@@ -281,6 +287,8 @@
mtd = mtd_rootfs;
} else if (!strcmp(string1,
mtd_uboot.name)) {
mtd = mtd_uboot;
+} else if (!strcmp(string1,
mtd_image.name)) {
+mtd = mtd_image;
}
if (!mtd) {
@@ -404,20 +412,24 @@
// add files
if (!exitcode) {
-for (i = 1; i = 3; i++) {
+for (i = 1; i = 4; i++) {
addsize = 0;
padsize = 0;
switch (i) {
case 1:
+mtd = mtd_image;
+padsize = ROOTFS_MIN_OFFSET -
mtd-filesize;
+break;
+case 2:
mtd = mtd_kernel;
break;
-case 2:
+case 3:
mtd = mtd_rootfs;
addsize = mtd-filesize;
padsize = ROOTFS_MIN_OFFSET -
mtd_kernel.size - mtd-filesize;
break;
-case 3:
+case 4:
mtd = mtd_uboot;
addsize = mtd-filesize;
break;
@@ -723,7 +735,6 @@
int i;
mtd_info *mtd;
-int mandatory;
int noupdate;
int sizecheck
[OpenWrt-Devel] [patch] target orion_generic: use magic_long in sysupgrade
Signed-off-by: Matthias Bücher m...@maddes.net
Patch is attached and inline for comments
Regards
Maddes
Index: target/linux/orion/generic/base-files/lib/upgrade/platform.sh
===
--- target/linux/orion/generic/base-files/lib/upgrade/platform.sh
(revision 29422)
+++ target/linux/orion/generic/base-files/lib/upgrade/platform.sh
(working copy)
@@ -1,3 +1,7 @@
+#
+# Copyright (C) 2010-2011 OpenWrt.org
+#
+
# use default image for PART_NAME
# use default for platform_do_upgrade()
@@ -6,17 +10,20 @@
local hardware=`sed -n /Hardware/s/.*:.//p /proc/cpuinfo`
local magic=$(get_magic_word $1)
+ local magic_long=$(get_magic_long $1)
case ${hardware} in
-# hardware with padded uImage + padded rootfs
+# hardware with a direct uImage partition
+# image header format as described in U-Boot's include/image.h
+# see
http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=include/image.h
'Linksys WRT350N v2')
- [ ${magic} != '2705' ] {
- echo Invalid image type ${magic}.
+ [ ${magic_long} != '27051956' ] {
+ echo Invalid image type ${magic_long}.
return 1
}
return 0
;;
-# Netgear WNR854T has extra header before uImage
+# Netgear WNR854T (has uImage as file inside a JFFS2 partition)
'Netgear WNR854T')
[ ${magic} != '8519' ] {
echo Invalid image type ${magic}.
Index: target/linux/orion/generic/base-files/lib/upgrade/platform.sh
===
--- target/linux/orion/generic/base-files/lib/upgrade/platform.sh (revision 29422)
+++ target/linux/orion/generic/base-files/lib/upgrade/platform.sh (working copy)
@@ -1,3 +1,7 @@
+#
+# Copyright (C) 2010-2011 OpenWrt.org
+#
+
# use default image for PART_NAME
# use default for platform_do_upgrade()
@@ -6,17 +10,20 @@
local hardware=`sed -n /Hardware/s/.*:.//p /proc/cpuinfo`
local magic=$(get_magic_word $1)
+ local magic_long=$(get_magic_long $1)
case ${hardware} in
- # hardware with padded uImage + padded rootfs
+ # hardware with a direct uImage partition
+ # image header format as described in U-Boot's include/image.h
+ # see http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=include/image.h
'Linksys WRT350N v2')
- [ ${magic} != '2705' ] {
- echo Invalid image type ${magic}.
+ [ ${magic_long} != '27051956' ] {
+ echo Invalid image type ${magic_long}.
return 1
}
return 0
;;
- # Netgear WNR854T has extra header before uImage
+ # Netgear WNR854T (has uImage as file inside a JFFS2 partition)
'Netgear WNR854T')
[ ${magic} != '8519' ] {
echo Invalid image type ${magic}.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] update wrt350nv2-builder to v2.4 and use new functionality for target orion_generic
Signed-off-by: Matthias Bücher m...@maddes.net
Patch is attached and inline for comments
Regards
Maddes
Index: tools/wrt350nv2-builder/Makefile
===
--- tools/wrt350nv2-builder/Makefile(revision 29422)
+++ tools/wrt350nv2-builder/Makefile(working copy)
@@ -1,5 +1,5 @@
#
-# Copyright (C) 2006-2010 OpenWrt.org
+# Copyright (C) 2006-2011 OpenWrt.org
#
# This is free software, licensed under the GNU General Public License v2.
# See /LICENSE for more information.
@@ -8,7 +8,7 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=wrt350nv2-builder
-PKG_VERSION:=2.3
+PKG_VERSION:=2.4
HOST_BUILD_DIR:=$(BUILD_DIR_HOST)/${PKG_NAME}-$(PKG_VERSION)
Index: tools/wrt350nv2-builder/src/wrt350nv2-builder.c
===
--- tools/wrt350nv2-builder/src/wrt350nv2-builder.c (revision 29422)
+++ tools/wrt350nv2-builder/src/wrt350nv2-builder.c (working copy)
@@ -1,8 +1,8 @@
/*
- WRT350Nv2-Builder 2.3 (previously called buildimg)
+ WRT350Nv2-Builder 2.4 (previously called buildimg)
Copyright (C) 2008-2009 Dirk Teurlings i...@upexia.nl
- Copyright (C) 2009-2010 Matthias Buecher (http://www.maddes.net/)
+ Copyright (C) 2009-2011 Matthias Buecher (http://www.maddes.net/)
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
@@ -33,6 +33,9 @@
:u-boot 0 /path/to/u-boot.bin
#version0x2020
+ Additionally since v2.4 an already complete image can be used:
+ :image 0
/path/to/openwrt-wrt350nv2-[squashfs|jffs2-64k].img
+
args:
1 wrt350nv2.par parameter file describing the
image layout
2 wrt350nv2.img output file for linksys style
image
@@ -62,6 +65,8 @@
https://forum.openwrt.org/viewtopic.php?pid=92928#p92928
Changelog:
+ v2.4 - added :image definition for parameter file, this allows
+ to use a complete sysupgrade image without any kernel size check
v2.3 - allow jffs by adding its magic number (0x8519)
added parameter option -i to ignore unknown magic numbers
v2.2 - fixed checksum byte calculation for other versions than 0x2019
@@ -92,7 +97,7 @@
// version info
-#define VERSION 2.3
+#define VERSION 2.4
char program_info[] = WRT350Nv2-Builder v%s by Dirk Teurlings
i...@upexia.nl and Matthias Buecher (http://www.maddes.net/)\n;
// verbosity
@@ -112,6 +117,7 @@
mtd_info mtd_kernel = { kernel, 0, 0, NULL, 0L, { 0, 0 } };
mtd_info mtd_rootfs = { rootfs, 0, 0, NULL, 0L, { 0, 0 } };
+mtd_info mtd_image = { image, 0, 0, NULL, 0L, { 0, 0 } };
mtd_info mtd_uboot = { u-boot, 0, 0, NULL, 0L, { 0, 0 } };
#define ROOTFS_END_OFFSET 0x0076
@@ -281,6 +287,8 @@
mtd = mtd_rootfs;
} else if (!strcmp(string1,
mtd_uboot.name)) {
mtd = mtd_uboot;
+ } else if (!strcmp(string1,
mtd_image.name)) {
+ mtd = mtd_image;
}
if (!mtd) {
@@ -404,20 +412,24 @@
// add files
if (!exitcode) {
- for (i = 1; i = 3; i++) {
+ for (i = 1; i = 4; i++) {
addsize = 0;
padsize = 0;
switch (i) {
case 1:
+ mtd = mtd_image;
+ padsize = ROOTFS_MIN_OFFSET -
mtd-filesize;
+ break;
+ case 2:
mtd = mtd_kernel;
break;
- case 2:
+ case 3:
mtd = mtd_rootfs;
addsize = mtd-filesize;
padsize = ROOTFS_MIN_OFFSET -
mtd_kernel.size - mtd-filesize;
break;
- case 3:
+ case 4:
mtd = mtd_uboot;
addsize = mtd-filesize;
break;
@@ -723,7 +735,6 @@
int i;
mtd_info *mtd;
- int mandatory;
int noupdate;
int sizecheck;
int magiccheck;
@@ -934,28 +945,30 @@
if ((!exitcode) (par_filename)) {
lprintf(DEBUG, checking mtd data...\n);
- for (i = 1; i = 3; i++) {
-
[OpenWrt-Devel] [patch] Orion generic target: enhanced image makefile
This patch is a complete overhaul of the image makefile for the Orion
generic target.[BR] Code is written in a way that it can be reused
several times in the image file, but can also be easily adopted to other
targets (BuildKernel, Sysupgrade image, etc.).[BR] Only working images
are generated, e.g. only JFFS images for the erase size (WRT350Nv2 =
64k, WNR854T = 128k).
Signed-off-by: Matthias Buecher mail@…
Corresponding ticket 10205: https://dev.openwrt.org/ticket/10205
Index: target/linux/orion/image/generic.mk
===
--- target/linux/orion/image/generic.mk (revision 28391)
+++ target/linux/orion/image/generic.mk (working copy)
@@ -1,90 +1,151 @@
#
-# Copyright (C) 2008-2010 OpenWrt.org
+# Copyright (C) 2008-2011 OpenWrt.org
#
# This is free software, licensed under the GNU General Public License v2.
# See /LICENSE for more information.
#
+### DO NOT INDENT LINES CONTAINING $(call xyz) AS THIS MAY CHANGE THE
CONTEXT
+### OF THE FIRST LINE IN THE CALLED VARIABLE (NOTE: variable!)
+### see
http://www.gnu.org/software/make/manual/html_node/Call-Function.html#Call-Function
+
+
+###
+### Image/Prepare
+###
+
define Image/Prepare
- cp $(LINUX_DIR)/arch/arm/boot/uImage $(KDIR)/uImage
+### Dummy comment for indented calls of Image/Prepare
+ cp $(LINUX_DIR)/arch/arm/boot/zImage $(BIN_DIR)/$(IMG_PREFIX)-zImage
endef
+
+###
+### Image/BuildKernel
+###
+
define Image/BuildKernel
- # Orion Kernel uImages
- # WRT350N v2: mach id 1633 (0x661)
- echo -en \x06\x1c\xa0\xe3\x61\x10\x81\xe3 $(KDIR)/wrt350nv2-zImage
- cat $(LINUX_DIR)/arch/arm/boot/zImage $(KDIR)/wrt350nv2-zImage
+### Dummy comment for indented calls of Image/BuildKernel
+ # Netgear WNR854T: mach id 1801 (0x0709)
+$(call
Image/BuildKernel/Default,wnr854t,\x07\x1c\xa0\xe3\x09\x10\x81\xe3)
+ # Linksys WRT350N v2: mach id 1633 (0x0661)
+$(call
Image/BuildKernel/Default,wrt350nv2,\x06\x1c\xa0\xe3\x61\x10\x81\xe3)
+endef
+
+define Image/BuildKernel/Default
+ # parameters: 1 = machine name, 2 = machine id as string
+ # Orion Kernel uImage for $(1)
+ # merge machine id and regular zImage into one file
+ echo -en $(2) $(KDIR)/$(1)-zImage
+ cat $(LINUX_DIR)/arch/arm/boot/zImage $(KDIR)/$(1)-zImage
+ # create uImage from file created in previous steps
$(STAGING_DIR_HOST)/bin/mkimage -A arm -O linux -T kernel \
-C none -a 0x8000 -e 0x8000 -n 'Linux-$(LINUX_VERSION)' \
- -d $(KDIR)/wrt350nv2-zImage $(KDIR)/wrt350nv2-uImage
- cp $(KDIR)/wrt350nv2-uImage $(BIN_DIR)/openwrt-wrt350nv2-uImage
- # WNR854T: mach id 1801 (0x709)
- echo -en \x07\x1c\xa0\xe3\x09\x10\x81\xe3 $(KDIR)/wnr854t-zImage
- cat $(LINUX_DIR)/arch/arm/boot/zImage $(KDIR)/wnr854t-zImage
- $(STAGING_DIR_HOST)/bin/mkimage -A arm -O linux -T kernel \
- -C none -a 0x8000 -e 0x8000 -n 'Linux-$(LINUX_VERSION)' \
- -d $(KDIR)/wnr854t-zImage $(KDIR)/wnr854t-uImage
- cp $(KDIR)/wnr854t-uImage $(BIN_DIR)/openwrt-wnr854t-uImage
+ -d $(KDIR)/$(1)-zImage $(KDIR)/$(1)-uImage
+ # copy uImage to bin dir
+ cp $(KDIR)/$(1)-uImage $(BIN_DIR)/openwrt-$(1)-uImage
endef
-define Image/Build/Netgear
- # Orion Netgear Images
- mkdir $(KDIR)/netgear_image
- cp $(KDIR)/wnr854t-uImage $(KDIR)/netgear_image/uImage
- $(STAGING_DIR_HOST)/bin/mkfs.jffs2 -m none -p -l -q -e 128KiB -o
$(KDIR)/wnr854t-uImage.jffs2 -d $(KDIR)/netgear_image
- rm -rf $(KDIR)/netgear_image
+
+###
+### Image/Build
+###
+
+define Image/Build
+### Dummy comment for indented calls of Image/Build
+$(call Image/Build/$(1),$(1))
+ # Netgear WNR854T: erase size is 128k = 0x0002 = 131072
+$(call Image/Build/Netgear/wnr854t,$(1),128k,1048576,NG_WNR854T)
+ # Linksys WRT350N v2: erase size is 64k = 0x0001 = 65536
+$(call Image/Build/Linksys/wrt350nv2,$(1),64k,1048576)
+endef
+
+define Image/Build/squashfs
+$(call prepare_generic_squashfs,$(KDIR)/root.squashfs)
+endef
+
+define Image/Build/Default/sysupgrade
+ # parameters: 1 = rootfs type, 2 = machine name, 3 = pad size (erase
or kernel size)
+ # Orion $(1) sysupgrade image for $(2)
+ # sysupgrade image
( \
- dd if=$(KDIR)/wnr854t-uImage.jffs2 bs=1024k conv=sync; \
- dd if=$(KDIR)/root.$(1) bs=128k conv=sync; \
- ) $(BIN_DIR)/openwrt-$(2)-$(1).img
+ dd if=${KDIR}/$(2)-uImage bs=$(3) conv=sync; \
+ dd if=${KDIR}/root.$(1); \
+ ) ${BIN_DIR}/openwrt-$(2)-$(1).img
+endef
+
+define Image/Build/Default/webupgrade
+ # parameters: 1 = rootfs type, 2 = machine name, 3 = header
+ # Orion $(1) webupgrade image for $(2)
+ # webupgrade image
$(STAGING_DIR_HOST)/bin/add_header $(3)
$(BIN_DIR)/openwrt-$(2)-$(1).img $(BIN_DIR)/openwrt-$(2)-$(1)-webupgrade.img
endef
-define Image/Build/Linksys
- # Orion Linksys Images
- # sysupgrade image
- ( \
- dd
[OpenWrt-Devel] [patch] Flexible kernel size support, split linux partition to rootfs after uimage
Hello OpenWrt developers,
this is a cross-platform issue where I need your expertise.
As I build for Orion with kernel symbols the kernel is normally bigger
than the 1MB mtd partition.
That's why I'm interested in having support for flexible kernel sizes.
This would also allow people to reduce kernel size and gain more JFFS2
space.
While following the OpenWrt development I came across ticket #8781,
where in comment #6 [1] it was hinted to the Lantiq platform that
provides a patch [2] that splits a linux partition into a rootfs
partition after the uImage.
Unfortuantely that patch from the Lantiq platform bricked my device.
Reason was that it does not deal correctly with the Endianness of the
uImage header.
In my case (Linksys WRT350N v2, platform Orion/ARM) the kernel and
rootfs partition got so huge, that my U-Boot partition at the end of the
flash was overwritten during boot.
Hence I did a rework of that patch, which is attached (and also inline
for comments).
As I'm not a hardware and/or Linux guru I do not know if this reworked
patch is 100% correct, although I tried to keep it totally close to the
generic rootfs_split.patch [3].
I couldn't test it on devices with a different Endianness than my
Linksys WRT350N v2 [4].
Still the code has no size checks against the parent mtd, because the
generic rootfs_split.patch has also none.
It would be great if you could review the reworked patch and maybe add
it to the generic patches.
Maybe someone could also verify it on the Lantiq platform.
Or is a script solution as described in ticket #8781 the preferred way?
Or how is it done for the WRT54G devices?
To enable the patch add CONFIG_MTD_UIMAGE_SPLIT=y to your platform's
config-default.
The uImage must be padded to the erase size of the device, and the
rootfs must be following immediately behind it.
Tip: To test new code which can destroy your flash, boot a ramdisk
build. This way no writes are done to the flash. - Now I know.
Thanks for your time and reading
Maddes
P.S.:
a) Maybe CONFIG_MTD_LINUX_UIMAGE_SPLIT would be a better fitting name
for the config setting.
b) I also attach the changes for the Orion platform generic subtarget to
enable the new uImage/linux split.
[1] https://dev.openwrt.org/ticket/8781#comment:6
[2]
https://dev.openwrt.org/browser/trunk/target/linux/lantiq/patches-3.0/210-mtd_uimage_split.patch
[3]
https://dev.openwrt.org/browser/trunk/target/linux/generic/patches-3.0/400-rootfs_split.patch
[4] http://wiki.openwrt.org/toh/linksys/wrt350nv2
--- a/drivers/mtd/Kconfig
+++ b/drivers/mtd/Kconfig
@@ -41,6 +41,10 @@ config MTD_ROOTFS_SPLIT
bool Automatically split 'rootfs' partition for squashfs
default y
+config MTD_UIMAGE_SPLIT
+ bool Automatically split 'linux' partition with uImage for rootfs
+ default y
+
config MTD_REDBOOT_PARTS
tristate RedBoot partition table parsing
---help---
--- a/drivers/mtd/mtdcore.h
+++ b/drivers/mtd/mtdcore.h
@@ -13,7 +13,7 @@ extern struct mtd_info *__mtd_next_devic
extern int add_mtd_device(struct mtd_info *mtd);
extern int del_mtd_device(struct mtd_info *mtd);
extern int add_mtd_partitions(struct mtd_info *, const struct
mtd_partition *,
- int);
+ int, int, struct mtd_info *);
extern int del_mtd_partitions(struct mtd_info *);
#define mtd_for_each_device(mtd) \
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -446,7 +446,7 @@ int mtd_device_register(struct mtd_info
const struct mtd_partition *parts,
int nr_parts)
{
- return parts ? add_mtd_partitions(master, parts, nr_parts) :
+ return parts ? add_mtd_partitions(master, parts, nr_parts, 0, NULL) :
add_mtd_device(master);
}
EXPORT_SYMBOL_GPL(mtd_device_register);
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -861,6 +861,196 @@ static int refresh_rootfs_split(struct m
}
#endif /* CONFIG_MTD_ROOTFS_SPLIT */
+#ifdef CONFIG_MTD_UIMAGE_SPLIT
+/*
+ * adopted from OpenWrt's generic patch rootfs_split.patch
+ */
+
+#define UIMAGE_SPLIT_NAME rootfs
+#define UIMAGE_REMOVED_NAME removed
+
+/*
+ * image header format as described in U-Boot's include/image.h
+ * see
http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=include/image.h
+ */
+#define IH_MAGIC 0x27051956 /* Image Magic Number */
+#define IH_NMLEN 32 /* Image Name Length*/
+/*
+ * Legacy format image header,
+ * all data in network byte order (aka natural aka bigendian).
+ */
+typedef struct image_header {
+ uint32_tih_magic; /* Image Header Magic Number*/
+ uint32_tih_hcrc;/* Image Header CRC Checksum*/
+ uint32_tih_time;/* Image Creation Timestamp */
+ uint32_tih_size;/* Image Data Size */
+ uint32_tih_load;/* Data Load Address
Re: [OpenWrt-Devel] [PATCH 5/5] [orion] kernel and its mtd size
On 20.09.2011 01:02, Patrick Florek wrote: I just compiled a new Firmware for the Marvell Orion Generic Platform (wrt350n v2). I build it with the standard config and failed on creation of the firmware image. Error is that the kernel size is bigger than his space in the filesystem. Should i increase the size for it. How o i set the offset? 1.5M or 2M? Greetings Patrick Did you compile with kernel symbols? I did some days ago with r28247 and my WRT350Nv2 uImage was 1.050.976 Bytes in size (1MB is only 1.048.576). So add another 64KB to the kernel mtd partition (local modification for you), or disable kernel symbols (saves lots of bytes). Where to change this is shown in the 3rd attachment of ticket #5339 [1], and you have to update the image script for Orion too. [1] https://dev.openwrt.org/ticket/5339 Maddes ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Orion doesn't build anymore
I was able to build r27771 with a clean trunk. Maybe try a distclean before. Normally I compile trunk only, no extra feeds, distclean first then I use Select all packages. Do you have another modification in target/linux/orion/, maybe in config-default? Maddes On 01.08.2011 15:58, Maarten Bezemer wrote: The crypto.mk patch still seems to be missing in the trunk. Could someone apply it? As it is required to build OpenWRT for Orion. Thanks, Maarten Index: package/kernel/modules/crypto.mk === --- package/kernel/modules/crypto.mk(revision 27861) +++ package/kernel/modules/crypto.mk(working copy) @@ -447,7 +447,7 @@ define KernelPackage/crypto-mv-cesa TITLE:=Marvell crypto engine - DEPENDS:=+kmod-crypto-manager +kmod-crypto-aes @TARGET_kirkwood||TARGET_orion + DEPENDS:=+kmod-crypto-manager +kmod-crypto-aes +kmod-crypto-sha1 +kmod-crypto-hmac @TARGET_kirkwood||TARGET_orion KCONFIG:=CONFIG_CRYPTO_DEV_MV_CESA FILES:=$(LINUX_DIR)/drivers/crypto/mv_cesa.ko AUTOLOAD:=$(call AutoLoad,09,mv_cesa) On Wed, 2011-07-06 at 11:54 +0200, Maarten Bezemer wrote: On Tue, 2011-07-05 at 22:47 +0200, Matthias Buecher / Germany wrote: Thanks Maarten, now kernel compiles again. One of your patches had a typo (COFIG instead of CONFIG), corrected it and recreated it for the latest trunk revision. You're welcome, as I said I experienced similar problems just before you did and just created them (although, somehow I got the CONFIG wrong and it still was working...) Since these patches seem work, should I 'officially' submit them as patches to get them patched into the trunk? Greetings, Maarten ___ 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 Matthias Maddes Bücher -- http://www.maddes.net/ Home: Earth / Germany / Ruhr-Area ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [patch] bump package wing to 20110709
The attached patch will bump the wing package to a more current version. This version has less compile issues and solves ticket #9722 [1]. Signed by: Matthias Buecher mail at maddes.net Thanks to Roberto Riggio for this help. [1] https://dev.openwrt.org/ticket/9722 Index: net/wing/Makefile === --- net/wing/Makefile (revision 27623) +++ net/wing/Makefile (working copy) @@ -8,9 +8,9 @@ include $(TOPDIR)/rules.mk PKG_NAME:=wing -PKG_VERSION:=20110329 -PKG_RELEASE:=2 -PKG_REV:=4ef2a352b29c26ce76d8b3d7c6897d301362a101 +PKG_VERSION:=20110709 +PKG_RELEASE:=1 +PKG_REV:=6aaea18b8e199781dc600681882cb2648f43ec38 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2 PKG_SOURCE_URL:=git://github.com/rriggio/click.git Index: net/wing/Makefile === --- net/wing/Makefile (revision 27623) +++ net/wing/Makefile (working copy) @@ -8,9 +8,9 @@ include $(TOPDIR)/rules.mk PKG_NAME:=wing -PKG_VERSION:=20110329 -PKG_RELEASE:=2 -PKG_REV:=4ef2a352b29c26ce76d8b3d7c6897d301362a101 +PKG_VERSION:=20110709 +PKG_RELEASE:=1 +PKG_REV:=6aaea18b8e199781dc600681882cb2648f43ec38 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2 PKG_SOURCE_URL:=git://github.com/rriggio/click.git ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] pjsip doesn't build in trunk Orion due libgcc issue
A current log and error description is available in ticket #9017 [1] Thanks in advance Maddes [1] https://dev.openwrt.org/ticket/9017 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] perf doesn't build on Debian
Hi everybody, I'm unable to resolve the dependencies for package perf in trunk, also `make menuconfig` throws errors about the perf package. Detailed log is available in ticket #9696 [1] . Regards Maddes [1] https://dev.openwrt.org/ticket/9696 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Orion doesn't build anymore
On 06.07.2011 11:54, Maarten Bezemer wrote: On Tue, 2011-07-05 at 22:47 +0200, Matthias Buecher / Germany wrote: Thanks Maarten, now kernel compiles again. One of your patches had a typo (COFIG instead of CONFIG), corrected it and recreated it for the latest trunk revision. You're welcome, as I said I experienced similar problems just before you did and just created them (although, somehow I got the CONFIG wrong and it still was working...) Since these patches seem work, should I 'officially' submit them as patches to get them patched into the trunk? Greetings, Maarten After getting rid of Lantiq packages for Orion in r27494, there are still issues related to crypto-hash when enabling Select all packages: make[3]: Entering directory `/home/maddes/openwrt/trunk/package/kernel' IPKG_TMP=/home/maddes/openwrt/trunk/tmp/ipkg IPKG_INSTROOT=/home/maddes/openwrt/trunk/build_dir/target-arm_v5t_uClibc-0.9.32_eabi/root-orion IPKG_CONF_DIR=/home/maddes/openwrt/trunk/staging_dir/target-arm_v5t_uClibc-0.9.32_eabi/etc IPKG_OFFLINE_ROOT=/home/maddes/openwrt/trunk/build_dir/target-arm_v5t_uClibc-0.9.32_eabi/root-orion /home/maddes/openwrt/trunk/staging_dir/host/bin/opkg --offline-root /home/maddes/openwrt/trunk/build_dir/target-arm_v5t_uClibc-0.9.32_eabi/root-orion --force-depends --force-overwrite --force-postinstall --force-maintainer --add-dest root:/ --add-arch all:100 --add-arch orion:200 install /home/maddes/openwrt/trunk/bin/orion/packages/kernel_2.6.37.6-1_orion.ipk Installing kernel (2.6.37.6-1) to root... Configuring kernel. for flag in hold; do IPKG_TMP=/home/maddes/openwrt/trunk/tmp/ipkg IPKG_INSTROOT=/home/maddes/openwrt/trunk/build_dir/target-arm_v5t_uClibc-0.9.32_eabi/root-orion IPKG_CONF_DIR=/home/maddes/openwrt/trunk/staging_dir/target-arm_v5t_uClibc-0.9.32_eabi/etc IPKG_OFFLINE_ROOT=/home/maddes/openwrt/trunk/build_dir/target-arm_v5t_uClibc-0.9.32_eabi/root-orion /home/maddes/openwrt/trunk/staging_dir/host/bin/opkg --offline-root /home/maddes/openwrt/trunk/build_dir/target-arm_v5t_uClibc-0.9.32_eabi/root-orion --force-depends --force-overwrite --force-postinstall --force-maintainer --add-dest root:/ --add-arch all:100 --add-arch orion:200 flag $flag kernel; done Setting flags for package kernel to hold. mkdir -p /home/maddes/openwrt/trunk/bin/orion/packages /home/maddes/openwrt/trunk/build_dir/linux-orion_generic/packages/ipkg-orion/kmod-crypto-hash/CONTROL mkdir -p /home/maddes/openwrt/trunk/build_dir/linux-orion_generic/packages/ipkg-orion/kmod-crypto-hash/lib/modules/2.6.37.6 cp -fpR -L /home/maddes/openwrt/trunk/build_dir/linux-orion_generic/linux-2.6.37.6/crypto/crypto_hash.ko /home/maddes/openwrt/trunk/build_dir/linux-orion_generic/packages/ipkg-orion/kmod-crypto-hash/lib/modules/2.6.37.6/ cp: cannot stat `/home/maddes/openwrt/trunk/build_dir/linux-orion_generic/linux-2.6.37.6/crypto/crypto_hash.ko': No such file or directory make[3]: *** [/home/maddes/openwrt/trunk/bin/orion/packages/kmod-crypto-hash_2.6.37.6-1_orion.ipk] Error 1 make[3]: Leaving directory `/home/maddes/openwrt/trunk/package/kernel' I will try with HASH2 config symbol only, so I will remove HASH config symbol. We'll see. Maddes ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Lantiq TAPI driver also build for other platforms
On 06.07.2011 21:09, John Crispin wrote: On 06/07/11 20:32, Matthias Buecher / Germany wrote: On 06.07.2011 11:54, Maarten Bezemer wrote: On Tue, 2011-07-05 at 22:47 +0200, Matthias Buecher / Germany wrote: Thanks Maarten, now kernel compiles again. One of your patches had a typo (COFIG instead of CONFIG), corrected it and recreated it for the latest trunk revision. You're welcome, as I said I experienced similar problems just before you did and just created them (although, somehow I got the CONFIG wrong and it still was working...) Since these patches seem work, should I 'officially' submit them as patches to get them patched into the trunk? Greetings, Maarten After getting rid of Lantiq packages for Orion in r27494, there are hi, after applying your ltq-tapi patch earlier, i just reverted it and applied a different fix. if this new fix causes any problems let me know John Hi John, I just retested with r27498 and no Lantiq packages were build. Thanks. Maddes ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Orion doesn't build anymore / kmod-crypto-hash and kmod-crypto-core
On 06.07.2011 11:54, Maarten Bezemer wrote: On Tue, 2011-07-05 at 22:47 +0200, Matthias Buecher / Germany wrote: Thanks Maarten, now kernel compiles again. One of your patches had a typo (COFIG instead of CONFIG), corrected it and recreated it for the latest trunk revision. You're welcome, as I said I experienced similar problems just before you did and just created them (although, somehow I got the CONFIG wrong and it still was working...) Since these patches seem work, should I 'officially' submit them as patches to get them patched into the trunk? Greetings, Maarten I rebuild Orion/Generic with r27498, used Select all packages (no feeds installed) and still get an issue with kmod-crypto-hash. By closer looking at the log I found a weird warning message: WARNING: kmod-crypto-core is not available in the kernel config mkdir -p /home/maddes/openwrt/trunk/bin/orion/packages /home/maddes/openwrt/trunk/build_dir/linux-orion_generic/packages/ipkg-orion/kmod-crypto-hash/CONTROL mkdir -p /home/maddes/openwrt/trunk/build_dir/linux-orion_generic/packages/ipkg-orion/kmod-crypto-hash/lib/modules/2.6.37.6 cp -fpR -L /home/maddes/openwrt/trunk/build_dir/linux-orion_generic/linux-2.6.37.6/crypto/crypto_hash.ko /home/maddes/openwrt/trunk/build_dir/linux-orion_generic/packages/ipkg-orion/kmod-crypto-hash/lib/modules/2.6.37.6/ cp: cannot stat `/home/maddes/openwrt/trunk/build_dir/linux-orion_generic/linux-2.6.37.6/crypto/crypto_hash.ko': No such file or directory make[3]: *** [/home/maddes/openwrt/trunk/bin/orion/packages/kmod-crypto-hash_2.6.37.6-1_orion.ipk] Error 1 make[3]: Leaving directory `/home/maddes/openwrt/trunk/package/kernel' ERROR: package/kernel failed to build. ... make[3]: Entering directory `/home/maddes/openwrt/trunk/package/kernel' IPKG_TMP=/home/maddes/openwrt/trunk/tmp/ipkg IPKG_INSTROOT=/home/maddes/openwrt/trunk/build_dir/target-arm_v5t_uClibc-0.9.32_eabi/root-orion IPKG_CONF_DIR=/home/maddes/openwrt/trunk/staging_dir/target-arm_v5t_uClibc-0.9.32_eabi/etc IPKG_OFFLINE_ROOT=/home/maddes/openwrt/trunk/build_dir/target-arm_v5t_uClibc-0.9.32_eabi/root-orion /home/maddes/openwrt/trunk/staging_dir/host/bin/opkg --offline-root /home/maddes/openwrt/trunk/build_dir/target-arm_v5t_uClibc-0.9.32_eabi/root-orion --force-depends --force-overwrite --force-postinstall --force-maintainer --add-dest root:/ --add-arch all:100 --add-arch orion:200 install /home/maddes/openwrt/trunk/bin/orion/packages/kernel_2.6.37.6-1_orion.ipk Installing kernel (2.6.37.6-1) to root... Configuring kernel. for flag in hold; do IPKG_TMP=/home/maddes/openwrt/trunk/tmp/ipkg IPKG_INSTROOT=/home/maddes/openwrt/trunk/build_dir/target-arm_v5t_uClibc-0.9.32_eabi/root-orion IPKG_CONF_DIR=/home/maddes/openwrt/trunk/staging_dir/target-arm_v5t_uClibc-0.9.32_eabi/etc IPKG_OFFLINE_ROOT=/home/maddes/openwrt/trunk/build_dir/target-arm_v5t_uClibc-0.9.32_eabi/root-orion /home/maddes/openwrt/trunk/staging_dir/host/bin/opkg --offline-root /home/maddes/openwrt/trunk/build_dir/target-arm_v5t_uClibc-0.9.32_eabi/root-orion --force-depends --force-overwrite --force-postinstall --force-maintainer --add-dest root:/ --add-arch all:100 --add-arch orion:200 flag $flag kernel; done Setting flags for package kernel to hold. mkdir -p /home/maddes/openwrt/trunk/bin/orion/packages /home/maddes/openwrt/trunk/build_dir/linux-orion_generic/packages/ipkg-orion/kmod-crypto-hash/CONTROL mkdir -p /home/maddes/openwrt/trunk/build_dir/linux-orion_generic/packages/ipkg-orion/kmod-crypto-hash/lib/modules/2.6.37.6 cp -fpR -L /home/maddes/openwrt/trunk/build_dir/linux-orion_generic/linux-2.6.37.6/crypto/crypto_hash.ko /home/maddes/openwrt/trunk/build_dir/linux-orion_generic/packages/ipkg-orion/kmod-crypto-hash/lib/modules/2.6.37.6/ cp: cannot stat `/home/maddes/openwrt/trunk/build_dir/linux-orion_generic/linux-2.6.37.6/crypto/crypto_hash.ko': No such file or directory make[3]: *** [/home/maddes/openwrt/trunk/bin/orion/packages/kmod-crypto-hash_2.6.37.6-1_orion.ipk] Error 1 make[3]: Leaving directory `/home/maddes/openwrt/trunk/package/kernel' make[2]: *** [package/kernel/install] Error 2 Does this make sense to anyone? Maddes ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Orion doesn't build anymore
Thanks Maarten, now kernel compiles again. One of your patches had a typo (COFIG instead of CONFIG), corrected it and recreated it for the latest trunk revision. Index: package/kernel/modules/crypto.mk === --- package/kernel/modules/crypto.mk(revision 27463) +++ package/kernel/modules/crypto.mk(working copy) @@ -41,7 +41,9 @@ define KernelPackage/crypto-hash TITLE:=CryptoAPI hash support - KCONFIG:=CONFIG_CRYPTO_HASH + KCONFIG:= \ + CONFIG_CRYPTO_HASH \ + CONFIG_CRYPTO_HASH2 FILES:=$(LINUX_DIR)/crypto/crypto_hash.ko AUTOLOAD:=$(call AutoLoad,02,crypto_hash) $(call AddDepends/crypto) @@ -447,7 +449,7 @@ define KernelPackage/crypto-mv-cesa TITLE:=Marvell crypto engine - DEPENDS:=+kmod-crypto-manager +kmod-crypto-aes @TARGET_kirkwood||TARGET_orion + DEPENDS:=+kmod-crypto-manager +kmod-crypto-aes +kmod-crypto-sha1 +kmod-crypto-hmac @TARGET_kirkwood||TARGET_orion KCONFIG:=CONFIG_CRYPTO_DEV_MV_CESA FILES:=$(LINUX_DIR)/drivers/crypto/mv_cesa.ko AUTOLOAD:=$(call AutoLoad,09,mv_cesa) But now I run into another issue with ltq-tapi: ... Set the kernel architecture to arm configure: error: The lib_ifxos include directory is not valid! make[3]: *** [/home/maddes/openwrt/trunk/build_dir/linux-orion_generic/drv_tapi-3.13.0/.configured_] Error 1 make[3]: Leaving directory `/home/maddes/openwrt/trunk/package/ltq-tapi' ... Maddes On 04.07.2011 21:52, Maarten Bezemer wrote: I noticed the same yesterday, but did not get to it to submit the patches. In order to automatically select the kmod-crypto-sha1 and kmod-crypto-hmac packages the fix-crypto-mv-cesa.patch needs to be applied For some reasons the linux source expects CONFIG_CRYPTO_HASH2 instead (?) of CONFIG_CRYPTO_HASH. See attached fix-crypto-hash.patch Maybe for the crypto-hash patch the CONFIG_CRYPTO_HASH part needs to be removed? I am not a real Linux kernel developer so I do not know. Having both at least does not give errors. With both patches applied the Orion target builds again without problems when kmod-mv-cesa is selected Greetings, Maarten On Mon, 2011-07-04 at 20:24 +0200, Matthias Buecher / Germany wrote: Hi everybody, I just got back to OpenWrt development after 6 months and recognized that the Orion platform doesn't build anymore. According to ticket #9209 [1] this happened ~3 months ago. Can anybody please help, so I can continue developing some packages for my platform. Thanks in advance Maddes [1] https://dev.openwrt.org/ticket/9209 ___ 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 Matthias Maddes Bücher -- http://www.maddes.net/ Home: Earth / Germany / Ruhr-Area Index: package/kernel/modules/crypto.mk === --- package/kernel/modules/crypto.mk (revision 27463) +++ package/kernel/modules/crypto.mk (working copy) @@ -41,7 +41,9 @@ define KernelPackage/crypto-hash TITLE:=CryptoAPI hash support - KCONFIG:=CONFIG_CRYPTO_HASH + KCONFIG:= \ + CONFIG_CRYPTO_HASH \ + CONFIG_CRYPTO_HASH2 FILES:=$(LINUX_DIR)/crypto/crypto_hash.ko AUTOLOAD:=$(call AutoLoad,02,crypto_hash) $(call AddDepends/crypto) @@ -447,7 +449,7 @@ define KernelPackage/crypto-mv-cesa TITLE:=Marvell crypto engine - DEPENDS:=+kmod-crypto-manager +kmod-crypto-aes @TARGET_kirkwood||TARGET_orion + DEPENDS:=+kmod-crypto-manager +kmod-crypto-aes +kmod-crypto-sha1 +kmod-crypto-hmac @TARGET_kirkwood||TARGET_orion KCONFIG:=CONFIG_CRYPTO_DEV_MV_CESA FILES:=$(LINUX_DIR)/drivers/crypto/mv_cesa.ko AUTOLOAD:=$(call AutoLoad,09,mv_cesa) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Lantiq TAPI driver also build for other platforms
On 06.07.2011 00:38, Luca Olivetti wrote: Al 05/07/11 22:47, En/na Matthias Buecher / Germany ha escrit: But now I run into another issue with ltq-tapi: Unsurprisingly, since, AFAIK, that's only meant for lantiq hardware, so you should deselect it. Did you select it in make menuconfig or was it selected automatically? It was selected automatically by Build all packages. I adopted the platform exclusion from the other Lantiq packages. Let's hope this will be the last compilation issue for Orion. Good night Maddes Index: package/ltq-tapi/Makefile === --- package/ltq-tapi/Makefile (revision 27463) +++ package/ltq-tapi/Makefile (working copy) @@ -60,10 +60,12 @@ $(call Build/Configure/Default) endef -define Build/InstallDev +ifdef CONFIG_TARGET_lantiq + define Build/InstallDev $(INSTALL_DIR) $(1)/usr/include/drv_tapi $(CP) --dereference $(PKG_BUILD_DIR)/include/* $(1)/usr/include/drv_tapi (cd $(1)/usr/include/drv_tapi ln -s . include ln -s ../ifxos/ifx_types.h .) -endef + endef +endif $(eval $(call KernelPackage,ltq-tapi)) Index: package/ltq-tapi/Makefile === --- package/ltq-tapi/Makefile (revision 27463) +++ package/ltq-tapi/Makefile (working copy) @@ -60,10 +60,12 @@ $(call Build/Configure/Default) endef -define Build/InstallDev +ifdef CONFIG_TARGET_lantiq + define Build/InstallDev $(INSTALL_DIR) $(1)/usr/include/drv_tapi $(CP) --dereference $(PKG_BUILD_DIR)/include/* $(1)/usr/include/drv_tapi (cd $(1)/usr/include/drv_tapi ln -s . include ln -s ../ifxos/ifx_types.h .) -endef + endef +endif $(eval $(call KernelPackage,ltq-tapi)) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Orion doesn't build anymore
Hi everybody, I just got back to OpenWrt development after 6 months and recognized that the Orion platform doesn't build anymore. According to ticket #9209 [1] this happened ~3 months ago. Can anybody please help, so I can continue developing some packages for my platform. Thanks in advance Maddes [1] https://dev.openwrt.org/ticket/9209 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] r25090 breaks compilation of Orion with 2.6.32
They were present in the machine_desc structure in arch/arm/include/asm/mach/arch.h until 2.6.36.2 (incl. 2.6.32.27). Which kernel version did you compile? Maddes P.S.: Please do not use '--' in a signature that is not placed at the bottom of a mail. Thanks. Original Message Subject: Re: [OpenWrt-Devel] r25090 breaks compilation of Orion with 2.6.32 Date: Mon, 24 Jan 2011 23:00:40 +0100 From: Tanguy Pruvot tanguy.pru...@gmail.com Reply-To: Tanguy Pruvot tanguy.pru...@gmail.com, OpenWrt Development List openwrt-devel@lists.openwrt.org To: OpenWrt Development List openwrt-devel@lists.openwrt.org These keys doesn't exists on other machines... even in 2.6.36 .phys_io .io_pg_offst No problems with that for the wnr834t (compiled successfully) r25090 [1] breaks the possibility to compile trunk with 2.6.32. The patch from ticket #8241 [2] is a much cleaner solution just like it is done in the kernel source Maddes [1] https://dev.openwrt.org/changeset/25090 [2] https://dev.openwrt.org/attachment/ticket/8241/orion_dt2_2.6.37.2.patch On 21.01.2011 19:11, Matthias Buecher / Germany wrote: Anyone please? Maddes On 07.01.2011 00:44, Matthias Buecher / Germany wrote: Hi developers, can someone please commit the patch of ticket #8241 [1] to trunk. The patch is needed to compile Orion with new kernel release 2.6.37. Tried to contact Imre several times but got no reply. The patch is very simple, easy to review and keeps backward compatibility. Thanks in advance Maddes [1] https://dev.openwrt.org/attachment/ticket/8241/orion_dt2_2.6.37.2.patch ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] r25090 breaks compilation of Orion with 2.6.32
My mail was about 2.6.32 with trunk not 2.6.37. I use this to find issues with current trunk and the kernel release of backfire. Maddes On 24.01.2011 23:48, Tanguy Pruvot wrote: I used trunk (from git) WNR854T | Kamikaze (r25091) git://nbd.name/openwrt.git made a pull today and got the 2.6.37 setting... compiled fine : Linux version 2.6.37 (root@epsybox) (gcc version 4.3.3 (GCC) ) #1 Mon Jan 24 22:58:22 CET 2011 Le lundi 24 janvier 2011 à 23:20:50, vous écriviez : They were present in the machine_desc structure in arch/arm/include/asm/mach/arch.h until 2.6.36.2 (incl. 2.6.32.27). Which kernel version did you compile? Maddes Original Message Subject: Re: [OpenWrt-Devel] r25090 breaks compilation of Orion with 2.6.32 Date: Mon, 24 Jan 2011 23:00:40 +0100 From: Tanguy Pruvot tanguy.pru...@gmail.com Reply-To: Tanguy Pruvot tanguy.pru...@gmail.com, OpenWrt Development List openwrt-devel@lists.openwrt.org To: OpenWrt Development List openwrt-devel@lists.openwrt.org These keys doesn't exists on other machines... even in 2.6.36 .phys_io .io_pg_offst No problems with that for the wnr834t (compiled successfully) r25090 [1] breaks the possibility to compile trunk with 2.6.32. The patch from ticket #8241 [2] is a much cleaner solution just like it is done in the kernel source Maddes [1] https://dev.openwrt.org/changeset/25090 [2] https://dev.openwrt.org/attachment/ticket/8241/orion_dt2_2.6.37.2.patch On 21.01.2011 19:11, Matthias Buecher / Germany wrote: Anyone please? Maddes On 07.01.2011 00:44, Matthias Buecher / Germany wrote: Hi developers, can someone please commit the patch of ticket #8241 [1] to trunk. The patch is needed to compile Orion with new kernel release 2.6.37. Tried to contact Imre several times but got no reply. The patch is very simple, easy to review and keeps backward compatibility. Thanks in advance Maddes [1] https://dev.openwrt.org/attachment/ticket/8241/orion_dt2_2.6.37.2.patch ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [patch] ticket #8241 necessary to compile 2.6.37 for Orion
Hi developers, can someone please commit the patch of ticket #8241 [1] to trunk. The patch is needed to compile Orion with new kernel release 2.6.37. Tried to contact Imre several times but got no reply. The patch is very simple, easy to review and keeps backward compatibility. Thanks in advance Maddes [1] https://dev.openwrt.org/attachment/ticket/8241/orion_dt2_2.6.37.2.patch ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Reminder: Clean-up of generic patches 014 and 089 for 2.6.36+
Hi there, can please somebody commit ticket #8324 [1]. It removes unnecessary parts from the patches, which is already inside the kernel source at a different location. Additionally it tidies them up in a big way. Thanks Maddes [1] https://dev.openwrt.org/ticket/8324 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Kernel build error on kmod-md-raid456 with current trunk
Hi there, when building all packages on trunk then kernel compilation stops. Created ticket #8384 [1] for this error. Maddes [1] https://dev.openwrt.org/ticket/8384 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH][orion]Kernelpatches for kernel 2.6.36
Not necessary. 2.6.36.1 compiles fine with the current patches/ (which is for the current kernel). The patches-2.6.32/ is to compile trunk with the Backfire kernel. Maddes On 25.11.2010 21:29, Michael Kämmerer wrote: In present trunk (r24146) for target orion, patchfiles reside in dir patches and patches-2.6.32. Makefile uses kernel 2.6.36.1. The enclosed patchfile copies the needed patches for kernel 2.6.36. Signed-off-by: Michael Kaemmerer mrk_at_h3c_._de -- ___ 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] triggerhappy: update to 0.1.6
Inline is better for commenting the patch, as the comment can be placed directly at the discussed location. But a mangled patch is hard to apply. If it is attached it normally doesn't get mangled, but then commenting is harder as the relevant code is not shown. So if you are sure that the patch is not mangled by your mail client (no wraps, no tabs to spaces), then inline is definitely preferred. Maybe setting some options in your mail client will avoid this behaviour. Maddes On 22.11.2010 08:52, Stefan Tomanek wrote: Please attach patches as files next time, since inlining often screws them up (in this case spaces - tabs). Although https://dev.openwrt.org/wiki/SubmittingPatches says otherwise? Send a mail to openwrt-devel at lists.openwrt.org with the following contents: [...] 4. Your actual patch, inline, not word wrapped or whitespace mangled. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] triggerhappy: update to 0.1.6
On 22.11.2010 09:35, Stefan Tomanek wrote: Dies schrieb Matthias Buecher / Germany (m...@maddes.net): So if you are sure that the patch is not mangled by your mail client (no wraps, no tabs to spaces), then inline is definitely preferred. Maybe setting some options in your mail client will avoid this behaviour. Can you point me to the line where any mangling took place? I just checked the list reply of my own message, which looks completely fine to me, but when checking your reply, I noticed some tabs being replaced by spaces inside the quoted patch. I don't think mutt does any mangling, since the message itself is generated by git format-patch and sent as it is. Hadn't a look at your patch, maybe also his mail client mangles the mail when only displayed. I'm using Thunderbird 3.1 and my current settings mangle the mail when I reply. As far as I know your setup shouldn't mangle the patch. Can someone confirm? (Note to myself: finally try to setup TB correctly) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Remove obsolete patches
Had some minutes before I leave, attached is the 089 rebasement patch.
Maddes
On 13.11.2010 09:19, Matthias Buecher / Germany wrote:
I think generic patch 089 must be rebased when 014 is removed.
Maddes
On 12.11.2010 18:14, Guillaume LECERF wrote:
Signed-off-by: Guillaume LECERF glec...@gmail.com
---
.../014-cfi_show_amd_extended_table_version.patch | 30
.../014-cfi_show_amd_extended_table_version.patch | 30
2 files changed, 0 insertions(+), 60 deletions(-)
delete mode 100644
target/linux/generic/patches-2.6.36/014-cfi_show_amd_extended_table_version.patch
delete mode 100644
target/linux/generic/patches-2.6.37/014-cfi_show_amd_extended_table_version.patch
diff --git
a/target/linux/generic/patches-2.6.36/014-cfi_show_amd_extended_table_version.patch
b/target/linux/generic/patches-2.6.36/014-cfi_show_amd_extended_table_version.patch
deleted file mode 100644
index 55a6c2e..000
---
a/target/linux/generic/patches-2.6.36/014-cfi_show_amd_extended_table_version.patch
+++ /dev/null
@@ -1,30 +0,0 @@
a/drivers/mtd/chips/cfi_cmdset_0002.c
-+++ b/drivers/mtd/chips/cfi_cmdset_0002.c
-@@ -371,6 +371,8 @@ static struct cfi_fixup fixup_table[] =
- static void cfi_fixup_major_minor(struct cfi_private *cfi,
- struct cfi_pri_amdstd *extp)
- {
-+ // manufacturers defined in include/linux/mtd/cfi.h
-+
-if (cfi-mfr == CFI_MFR_SAMSUNG cfi-id == 0x257e
-extp-MajorVersion == '0')
-extp-MajorVersion = '1';
-@@ -403,6 +405,9 @@ struct mtd_info *cfi_cmdset_0002(struct
-
-mtd-reboot_notifier.notifier_call = cfi_amdstd_reboot;
-
-+ printk( CFI mfr 0x%08x\n, cfi-mfr); // TODO: Is there a more
general place to print this info?
-+ printk( CFI id 0x%08x\n, cfi-id);
-+
-if (cfi-cfi_mode==CFI_MODE_CFI){
-unsigned char bootloc;
-__u16 adr = primary?cfi-cfiq-P_ADR:cfi-cfiq-A_ADR;
-@@ -420,7 +425,7 @@ struct mtd_info *cfi_cmdset_0002(struct
- * Valid primary extension versions are: 1.0, 1.1, 1.2,
1.3, 1.4
- * see:
http://www.amd.com/us-en/assets/content_type/DownloadableAssets/cfi_r20.pdf,
page 19
- *
http://www.amd.com/us-en/assets/content_type/DownloadableAssets/cfi_100_20011201.pdf
--*
http://www.spansion.com/Support/Datasheets/s29ws-p_00_a12_e.pdf
-+*
http://www.spansion.com/Support/AppNotes/CFI_Spec_AN_03.pdf
- */
-if (extp-MajorVersion != '1' ||
-(extp-MajorVersion == '1' (extp-MinorVersion
'0' || extp-MinorVersion '4'))) {
diff --git
a/target/linux/generic/patches-2.6.37/014-cfi_show_amd_extended_table_version.patch
b/target/linux/generic/patches-2.6.37/014-cfi_show_amd_extended_table_version.patch
deleted file mode 100644
index 6da34f7..000
---
a/target/linux/generic/patches-2.6.37/014-cfi_show_amd_extended_table_version.patch
+++ /dev/null
@@ -1,30 +0,0 @@
a/drivers/mtd/chips/cfi_cmdset_0002.c
-+++ b/drivers/mtd/chips/cfi_cmdset_0002.c
-@@ -392,6 +392,8 @@ static struct cfi_fixup fixup_table[] =
- static void cfi_fixup_major_minor(struct cfi_private *cfi,
- struct cfi_pri_amdstd *extp)
- {
-+ // manufacturers defined in include/linux/mtd/cfi.h
-+
-if (cfi-mfr == CFI_MFR_SAMSUNG cfi-id == 0x257e
-extp-MajorVersion == '0')
-extp-MajorVersion = '1';
-@@ -431,6 +433,9 @@ struct mtd_info *cfi_cmdset_0002(struct
-
-mtd-reboot_notifier.notifier_call = cfi_amdstd_reboot;
-
-+ printk( CFI mfr 0x%08x\n, cfi-mfr); // TODO: Is there a more
general place to print this info?
-+ printk( CFI id 0x%08x\n, cfi-id);
-+
-if (cfi-cfi_mode==CFI_MODE_CFI){
-unsigned char bootloc;
-__u16 adr = primary?cfi-cfiq-P_ADR:cfi-cfiq-A_ADR;
-@@ -448,7 +453,7 @@ struct mtd_info *cfi_cmdset_0002(struct
- * Valid primary extension versions are: 1.0, 1.1, 1.2,
1.3, 1.4
- * see:
http://cs.ozerki.net/zap/pub/axim-x5/docs/cfi_r20.pdf, page 19
- *
http://www.spansion.com/Support/AppNotes/cfi_100_20011201.pdf
--*
http://www.spansion.com/Support/Datasheets/s29ws-p_00_a12_e.pdf
-+*
http://www.spansion.com/Support/AppNotes/CFI_Spec_AN_03.pdf
- */
-if (extp-MajorVersion != '1' ||
-(extp-MajorVersion == '1' (extp-MinorVersion
'0' || extp-MinorVersion '4'))) {
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Remove obsolete patches
Generic 014 is also something I'm currently working on, and it is not
really obsolete.
The printk() definitely helps to identify hardware, especially not
supported one.
The other changes help developers to find the correct spots for
enhancements.
You may remove the blocks with the comments, but the prints should be
left in.
Maddes
On 12.11.2010 18:14, Guillaume LECERF wrote:
Signed-off-by: Guillaume LECERF glec...@gmail.com
---
.../014-cfi_show_amd_extended_table_version.patch | 30
.../014-cfi_show_amd_extended_table_version.patch | 30
2 files changed, 0 insertions(+), 60 deletions(-)
delete mode 100644
target/linux/generic/patches-2.6.36/014-cfi_show_amd_extended_table_version.patch
delete mode 100644
target/linux/generic/patches-2.6.37/014-cfi_show_amd_extended_table_version.patch
diff --git
a/target/linux/generic/patches-2.6.36/014-cfi_show_amd_extended_table_version.patch
b/target/linux/generic/patches-2.6.36/014-cfi_show_amd_extended_table_version.patch
deleted file mode 100644
index 55a6c2e..000
---
a/target/linux/generic/patches-2.6.36/014-cfi_show_amd_extended_table_version.patch
+++ /dev/null
@@ -1,30 +0,0 @@
a/drivers/mtd/chips/cfi_cmdset_0002.c
-+++ b/drivers/mtd/chips/cfi_cmdset_0002.c
-@@ -371,6 +371,8 @@ static struct cfi_fixup fixup_table[] =
- static void cfi_fixup_major_minor(struct cfi_private *cfi,
- struct cfi_pri_amdstd *extp)
- {
-+// manufacturers defined in include/linux/mtd/cfi.h
-+
- if (cfi-mfr == CFI_MFR_SAMSUNG cfi-id == 0x257e
- extp-MajorVersion == '0')
- extp-MajorVersion = '1';
-@@ -403,6 +405,9 @@ struct mtd_info *cfi_cmdset_0002(struct
-
- mtd-reboot_notifier.notifier_call = cfi_amdstd_reboot;
-
-+printk( CFI mfr 0x%08x\n, cfi-mfr); // TODO: Is there a more
general place to print this info?
-+printk( CFI id 0x%08x\n, cfi-id);
-+
- if (cfi-cfi_mode==CFI_MODE_CFI){
- unsigned char bootloc;
- __u16 adr = primary?cfi-cfiq-P_ADR:cfi-cfiq-A_ADR;
-@@ -420,7 +425,7 @@ struct mtd_info *cfi_cmdset_0002(struct
- * Valid primary extension versions are: 1.0, 1.1, 1.2,
1.3, 1.4
- * see:
http://www.amd.com/us-en/assets/content_type/DownloadableAssets/cfi_r20.pdf,
page 19
- *
http://www.amd.com/us-en/assets/content_type/DownloadableAssets/cfi_100_20011201.pdf
-- *
http://www.spansion.com/Support/Datasheets/s29ws-p_00_a12_e.pdf
-+ *
http://www.spansion.com/Support/AppNotes/CFI_Spec_AN_03.pdf
- */
- if (extp-MajorVersion != '1' ||
- (extp-MajorVersion == '1' (extp-MinorVersion
'0' || extp-MinorVersion '4'))) {
diff --git
a/target/linux/generic/patches-2.6.37/014-cfi_show_amd_extended_table_version.patch
b/target/linux/generic/patches-2.6.37/014-cfi_show_amd_extended_table_version.patch
deleted file mode 100644
index 6da34f7..000
---
a/target/linux/generic/patches-2.6.37/014-cfi_show_amd_extended_table_version.patch
+++ /dev/null
@@ -1,30 +0,0 @@
a/drivers/mtd/chips/cfi_cmdset_0002.c
-+++ b/drivers/mtd/chips/cfi_cmdset_0002.c
-@@ -392,6 +392,8 @@ static struct cfi_fixup fixup_table[] =
- static void cfi_fixup_major_minor(struct cfi_private *cfi,
- struct cfi_pri_amdstd *extp)
- {
-+// manufacturers defined in include/linux/mtd/cfi.h
-+
- if (cfi-mfr == CFI_MFR_SAMSUNG cfi-id == 0x257e
- extp-MajorVersion == '0')
- extp-MajorVersion = '1';
-@@ -431,6 +433,9 @@ struct mtd_info *cfi_cmdset_0002(struct
-
- mtd-reboot_notifier.notifier_call = cfi_amdstd_reboot;
-
-+printk( CFI mfr 0x%08x\n, cfi-mfr); // TODO: Is there a more
general place to print this info?
-+printk( CFI id 0x%08x\n, cfi-id);
-+
- if (cfi-cfi_mode==CFI_MODE_CFI){
- unsigned char bootloc;
- __u16 adr = primary?cfi-cfiq-P_ADR:cfi-cfiq-A_ADR;
-@@ -448,7 +453,7 @@ struct mtd_info *cfi_cmdset_0002(struct
- * Valid primary extension versions are: 1.0, 1.1, 1.2,
1.3, 1.4
- * see:
http://cs.ozerki.net/zap/pub/axim-x5/docs/cfi_r20.pdf, page 19
- *
http://www.spansion.com/Support/AppNotes/cfi_100_20011201.pdf
-- *
http://www.spansion.com/Support/Datasheets/s29ws-p_00_a12_e.pdf
-+ *
http://www.spansion.com/Support/AppNotes/CFI_Spec_AN_03.pdf
- */
- if (extp-MajorVersion != '1' ||
- (extp-MajorVersion == '1' (extp-MinorVersion
'0' || extp-MinorVersion '4'))) {
___
openwrt-devel mailing list
Re: [OpenWrt-Devel] [PATCH] Remove obsolete patches
On 12.11.2010 21:33, Guillaume LECERF wrote: 2010/11/12 Matthias Buecher / Germany m...@maddes.net: Generic 014 is also something I'm currently working on, and it is not really obsolete. The printk() definitely helps to identify hardware, especially not supported one. The other changes help developers to find the correct spots for enhancements. You may remove the blocks with the comments, but the prints should be left in. I already pushed the printk upstream, at a more generic place, i.e. in cfi_probe.c :: cfi_chip_setup() : http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.36.y.git;a=commitdiff;h=771a115a6df06c45cf783e24c3f1f08b3e9aac4c Sorry, didn't see that yet. Then generic 014 is obsolete starting from 2.6.36. Although the additional comments help when developing, especially the link from 014 points directly to the 1.4 definition instead of a device description. Thanks Maddes ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Build Issues: Packages not build for kernel 2.6.35, e.g. USB
I found the problematic section: mkdir -p /home/maddes/openwrt/trunk/bin/orion/packages /home/maddes/openwrt/trunk/build_dir/linux-orion_generic/packages/ipkg-orion/kmod-pppol2tp/CONTROL mkdir -p /home/maddes/openwrt/trunk/build_dir/linux-orion_generic/packages/ipkg-orion/kmod-pppol2tp/lib/modules/2.6.35.8 cp -fpR -L /home/maddes/openwrt/trunk/build_dir/linux-orion_generic/linux-2.6.35.8/drivers/net/pppol2tp.ko /home/maddes/openwrt/trunk/build_dir/linux-orion_generic/packages/ipkg-orion/kmod-pppol2tp/lib/modules/2.6.35.8/ cp: cannot stat `/home/maddes/openwrt/trunk/build_dir/linux-orion_generic/linux-2.6.35.8/drivers/net/pppol2tp.ko': No such file or directory make[3]: *** [/home/maddes/openwrt/trunk/bin/orion/packages/kmod-pppol2tp_2.6.35.8-1_orion.ipk] Error 1 The full log of the kernel compilation [1MB] is available here: ftp://ftp.maddes.net/openwrt/trunk/orion/build_23900/flash/compilelog.orion_generic.release-luci+ipv6.23900M.20101106_215019.log Regards Maddes On 07.11.2010 00:25, Matthias Buecher / Germany wrote: Hello everybody, I experienced a weird problem when upgrading the Orion platform to kernel 2.6.35: Several packages are not build although they are selected in `make menuconfig`. I assume that the build system is not setting all necessary configs for 2.6.35 and maybe later. Or must be something special set for the platform? Ticket for upgrading Orion to 2.6.35: https://dev.openwrt.org/ticket/8183 Any help is greatly appreciated Maddes ___ 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] Build Issues: Packages not build for kernel 2.6.35, e.g. USB
It turned out that the package kmod-pppol2tp doesn't compile with 2.6.35 on any platform. So I create a defect ticket for it: #8195. https://dev.openwrt.org/ticket/8195 Maddes On 07.11.2010 15:06, Matthias Buecher / Germany wrote: I found the problematic section: mkdir -p /home/maddes/openwrt/trunk/bin/orion/packages /home/maddes/openwrt/trunk/build_dir/linux-orion_generic/packages/ipkg-orion/kmod-pppol2tp/CONTROL mkdir -p /home/maddes/openwrt/trunk/build_dir/linux-orion_generic/packages/ipkg-orion/kmod-pppol2tp/lib/modules/2.6.35.8 cp -fpR -L /home/maddes/openwrt/trunk/build_dir/linux-orion_generic/linux-2.6.35.8/drivers/net/pppol2tp.ko /home/maddes/openwrt/trunk/build_dir/linux-orion_generic/packages/ipkg-orion/kmod-pppol2tp/lib/modules/2.6.35.8/ cp: cannot stat `/home/maddes/openwrt/trunk/build_dir/linux-orion_generic/linux-2.6.35.8/drivers/net/pppol2tp.ko': No such file or directory make[3]: *** [/home/maddes/openwrt/trunk/bin/orion/packages/kmod-pppol2tp_2.6.35.8-1_orion.ipk] Error 1 The full log of the kernel compilation [1MB] is available here: ftp://ftp.maddes.net/openwrt/trunk/orion/build_23900/flash/compilelog.orion_generic.release-luci+ipv6.23900M.20101106_215019.log Regards Maddes On 07.11.2010 00:25, Matthias Buecher / Germany wrote: Hello everybody, I experienced a weird problem when upgrading the Orion platform to kernel 2.6.35: Several packages are not build although they are selected in `make menuconfig`. I assume that the build system is not setting all necessary configs for 2.6.35 and maybe later. Or must be something special set for the platform? Ticket for upgrading Orion to 2.6.35: https://dev.openwrt.org/ticket/8183 Any help is greatly appreciated Maddes ___ 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] Build Issues: Packages not build for kernel 2.6.35, e.g. USB
Hello everybody, I experienced a weird problem when upgrading the Orion platform to kernel 2.6.35: Several packages are not build although they are selected in `make menuconfig`. I assume that the build system is not setting all necessary configs for 2.6.35 and maybe later. Or must be something special set for the platform? Ticket for upgrading Orion to 2.6.35: https://dev.openwrt.org/ticket/8183 Any help is greatly appreciated Maddes ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Separate image creation per profile/target possible?
On 03.11.2010 15:50, Luka Perkov wrote:
On Sun, Oct 31, 2010 at 05:46:23PM +0100, Matthias Buecher / Germany wrote:
also had a look at other targets yesterday, and the adm5120 platform
has subtarget dependent image make files (just a simple include
$(SUBTARGET).mk) and even Profile dependent make rules.
Took all infos from Luka and Kaloz together and adapted this to Orion,
the result is available in ticket #8154
https://dev.openwrt.org/ticket/8154
Please next time make one patch, that you can easy review! Like the one
in this mail.
I prefer copying and moving files than removing/adding them with a patch.
This way the history of the files is kept inside the repository.
I admit that checking my delta patch may be not the simplest, but it's
also not that difficult.
The reviewer only has to keep in mind that it's a copy of the original
makefile and therefore has to see it as a patch for the original makefile.
Please have a look.
I think this is good patch:
* separates harddisk and generic subtargets
- you can build larger kernel image for other devices because it does
not break when kernel size is larger than 1048576 (WNR350Nv2)
* builds wrt350nv2-builder and upslug2 only when needed
* moves unnecessary files from base-files
@Imre and others: What do you think?
This is patch from Matthias Buecher but in one file.
--
Index: target/linux/orion/base-files/etc/uci-defaults/hardware
--- target/linux/orion/base-files/etc/uci-defaults/hardware (revision 23820)
+++ target/linux/orion/base-files/etc/uci-defaults/hardware (working copy)
@@ -1,54 +0,0 @@
-#!/bin/sh
-#
-# Copyright (C) 2010 OpenWrt.org
-#
-# This is free software, licensed under the GNU General Public License v2.
-# See /LICENSE for more information.
-#
-
-#
-# This script sets system defaults for the hardware on firstboot
-#
-
-local hardware=`sed -n /Hardware/s/.*:.//p /proc/cpuinfo`
-
-wrt350nv2_default() {
-# leds
- uci batch __EOF
-set system.power_led=led
-set system.power_led.name='Power LED (green)'
-set system.power_led.sysfs='wrt350nv2:green:power'
-set system.power_led.default='1'
-set system.wifi_led=led
-set system.wifi_led.name='Wireless LED (green)'
-set system.wifi_led.sysfs='wrt350nv2:green:wireless'
-set system.wifi_led.trigger='netdev'
-set system.wifi_led.dev='wlan0'
-set system.wifi_led.mode='link tx rx'
-set system.wifi_led.default='0'
-commit system
-__EOF
-
-# add mac address from U-Boot partition to lan and wan devices
- MTD=`grep -e 'u-boot' /proc/mtd`
- MTD=`echo ${MTD} | sed 's/[a-z]*\([0-9]*\):.*/\1/'`
- [ -n ${MTD} ] {
- MACADDR=`dd if=/dev/mtdblock${MTD} bs=1 skip=262048 count=6
2/dev/null | hexdump -e '1/1 %02x'`
- MACADDR2=$(( 0x${MACADDR} + 1))
- MACADDR2=`printf %012x ${MACADDR2}`
-
- MACADDR=`echo ${MACADDR} | sed 's/\(..\)/\1:/g' | sed 's/:$//'`
- MACADDR2=`echo ${MACADDR2} | sed 's/\(..\)/\1:/g' | sed
's/:$//'`
-
- uci set network.eth0.macaddr=${MACADDR}
- uci set network.lan.macaddr=${MACADDR}
- uci set network.wan.macaddr=${MACADDR2}
- uci commit network
- }
-}
-
-case ${hardware} in
- 'Linksys WRT350N v2')
- wrt350nv2_default
- ;;
-esac
Index: target/linux/orion/base-files/lib/upgrade/platform.sh
--- target/linux/orion/base-files/lib/upgrade/platform.sh (revision 23820)
+++ target/linux/orion/base-files/lib/upgrade/platform.sh (working copy)
@@ -1,31 +0,0 @@
-# use default image for PART_NAME
-# use default for platform_do_upgrade()
-
-platform_check_image() {
- [ ${ARGC} -gt 1 ] { echo 'Too many arguments. Only flash file
expected.'; return 1; }
-
- local hardware=`sed -n /Hardware/s/.*:.//p /proc/cpuinfo`
- local magic=$(get_magic_word $1)
-
- case ${hardware} in
- # hardware with padded uImage + padded rootfs
- 'Linksys WRT350N v2')
- [ ${magic} != '2705' ] {
- echo Invalid image type ${magic}.
- return 1
- }
- return 0
- ;;
- # Netgear WNR854T has extra header before uImage
- 'Netgear WNR854T')
- [ ${magic} != '8519' ] {
- echo Invalid image type ${magic}.
- return 1
- }
- return 0
- ;;
- esac
-
- echo Sysupgrade is not yet supported on ${hardware}.
- return 1
-}
Index: target/linux/orion/generic/base-files/etc/uci-defaults/hardware
--- target/linux/orion/generic/base-files/etc/uci-defaults/hardware
(revision 23820)
+++ target/linux/orion/generic/base-files/etc/uci-defaults/hardware
(working copy)
@@ -0,0 +1,54 @@
+#!/bin/sh
+#
+# Copyright (C) 2010 OpenWrt.org
+#
+# This is free software, licensed under the GNU General Public License v2.
+# See /LICENSE
Re: [OpenWrt-Devel] Separate image creation per profile/target possible?
Hello, thanks Imre and Luka for your replies. #1 My intention to use profiles for Orion is that these routers have different wifi hardware and some have USB (WRT350Nv2) while some have not (WNR854T). That would be the reason for profiles inside the generic target. #2 The difference between generic and harddisk after a first glance seems to be mainly USB support. So this would be the reason for a merge of these two targets. (=yes to Luka's question) #3 Seperated image Makefiles for targets and/or profiles would be great, as the Freecom DT2 image creation messes up the root file system (currently worked around) when compiling generic subtarget for SquashFS/JFFS2 devices. And Freecom looks like hard disk only, isn't it? This point is more important to me than merging the two subtargets, as this would clean up several things. Kind regards Matthias Maddes Bücher On 28.10.2010 08:33, Imre Kaloz wrote: Hi, On Thu, 28 Oct 2010 00:48:16 +0200, Matthias Buecher / Germany m...@maddes.net wrote: I want to transfer the Orion platform from subtargets to profiles. Is there a possibility to have a separated image makefile for each profile? Example: For profiles/100-wrt350nv2.mk with define Profile/WRT350Nv2 I would like to use image/100-wrt350nv2.mk (or image/WRT350Nv2.mk). If the image makefile can be specified, then it would be great to use it also for profiles/100-wrt350nv2_madwifi.mk with define Profile/WRT350Nv2_madwifi. On 28.10.2010 08:33, Imre Kaloz wrote: This doesn't make any sense. I don't see the need of profiles at all, and subtargets are used for kernel related changes. Could you explain why would this be useful? Imre On 28.10.2010 04:50, Luka Perkov wrote: I'm not sure I follow... Did you mean transfer existing Orion subtargets to profiles (I mean: generic harddisk) ? This file: https://dev.openwrt.org/browser/trunk/target/linux/orion/Makefile Best regards, Luka Perkov ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Separate image creation per profile possible?
Hi there, I want to transfer the Orion platform from subtargets to profiles. Is there a possibility to have a separated image makefile for each profile? Example: For profiles/100-wrt350nv2.mk with define Profile/WRT350Nv2 I would like to use image/100-wrt350nv2.mk (or image/WRT350Nv2.mk). If the image makefile can be specified, then it would be great to use it also for profiles/100-wrt350nv2_madwifi.mk with define Profile/WRT350Nv2_madwifi. Regards Maddes ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Official way how to reset to factory defaults
On a squashfs image just call firstboot and your router will be like it has just been flashed. Maddes On 24.09.2010 20:21, Lukáš Macura wrote: Hello to all, please, we are working with asus wl-500gp and backfire on it. We need to write script which will reset device to factory defaults. I used command mtd -r erase rootfs_data it works but after reboot, there is kernel crash, probably because bad jffs header after erase? It need tobe booted again to work properly. Please which is oficial way? It is possible to use sysupgrade -n, but I do not want to upgrade image, I only want to erase overlay device. Thank you, Lukas Macura ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Dropbear init script fix for trunk/backfire
Hi there, I had the need to bind one Dropbear instance to multiple ports, so I copied the latest Dropbear init script from Trunk onto my Backfire 10.03.1-rc2 installation. When checking the script's functionality I recognized that r20960 [1] for ticket #7149 [2] allowed to enter an ip address, but no support for multiple ports. Additionally it added an unnecessary scan for interfaces. Hence I attached a fix for the script to the ticket [2]. Would be great if this could go to Trunk and soon to Backfire too. Also I would ask all of you about your opinion on ticket #6992 [3]. Right now I would just change all UCI options for Dropbear to lowercase to make it consistent with all other packages, but Luci and X-Wrt would have to be adopted too. People using UCI on the command line will recognize the change by a simple `uci show`. Comments? Thanks for your time Matthias Maddes Bücher [1] https://dev.openwrt.org/changeset/20960 [2] https://dev.openwrt.org/attachment/ticket/7149 [3] https://dev.openwrt.org/ticket/6992 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [backfire] Busybox update?
Hello OpenWrt team, is it planned to update Busybox for 10.03.1? Maddes ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Builds since yesterday afternoon not succeeding
Just read this thread today and want to mention, that if you run into build problems you should issue a make distclean (not dirclean) to get rid of all old stuff and extra packages (create patches of your manual changes first, so you can later re-apply them). Remember that trunk is ongoing development (equals alpha state) and that build problems and clean-ups are normal things there. Tip: Create a simple batch script to keep your downloads when doing a distclean like this... (ftp://ftp.maddes.net/maddes.net/openwrt/distclean_build.sh) mv dl dl_save make distclean mv dl_save dl My two cents Maddes On 27.07.2010 11:40, Joseph Roback wrote: Seems people are filing tickets about it now... https://dev.openwrt.org/ticket/7674 I had the same thing happen to me with uhttpd, (minus the lua stuff), where the build system didn't build openssl first. It seems that the build goes straight to 'install' targets, skipping the 'compile' targets. Also, when this was happening to me, `make dirclean' hasn't enough to fix it. I had to checkout from svn, which I think is very strange. The dirclean target isn't cleaning everything its supposed to, or we need another target that basically starts us at the beginning without having to go back to svn checkout... I think in the long run, having a correct build system is worth every penny. Why deal with this time-after-time. Additionally, having a correct build will make parallel builds better and with all these cores today, parallel builds are essential to not wasting an entire afternoon waiting for code to compile. Joe On Jul 26, 2010, at 9:38 PM, Jim Henderson wrote: On Tue, 27 Jul 2010 01:56:19 +0200, Benjamin Cama wrote: I'll give that a try. It's a little confusing, though, having builds that don't build, might it not be worth tracking down why and addressing that root cause, if only to prevent a repeat of the discussion? Yes, it's confusing. Maybe it should be in a FAQ. Finding the root cause may be interesting, but I think that to most people here, the benefits don't outweight the cost of tracking down these bugs. Fair enough - that trick did work for me, so I've got 22390 built. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits ___ 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] problem with big integer on openwrt
If awk of Busybox has a range limit issue, then try calculating in the
shell itself:
echo $(( `echo 255.255.255.255 | awk -F\. '{printf (%i*256*256*256)
+ (%i*256*256) + (%i*256) + (%i), $1, $2, $3, $4}'` ))
Awk creates the formular, while ash calculates it via $((
Maddes
On 15.07.2010 11:46, Gioacchino Mazzurco wrote:
Hey all I have a big problem with openwrt!
In a bash shell if i write this command
printf %d\n `echo 255.255.255.255 | awk -F\. '{printf %d,
($4)+($3*256)+($2*256*256)+($1*256*256*256)}'`
i obtain
2147483647
that is wrong!
If i put the same command in my gentoo bash shell i obtain 4294967295
that is the good value how to fix this ?
___
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] Is r22145 not a little bit short-sighted?
Just saw r22145 and was wondering why this has been changed. What if 2.8 changes again the suffix? Re-replace everything? If someone is still compiling 2.4 for any reason with latest trunk he will have problems (lots of manual changes). I think the previous situation was a good general solution for all times coming. Only the check could have been against = 2.6 This is just my two cents for QA. No offense to the committer, I know this was just a clean-up. Kind regards Maddes -- http://www.maddes.net/ Home: Earth / Germany / Ruhr-Area ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [patch] add md5sum of kernel 2.6.35-rc3
Updates MD5SUM of kernel 2.6.35 to RC3. Signed off by: Matthias Buecher m...@maddes.net Index: include/kernel-version.mk === --- include/kernel-version.mk (revision 21899) +++ include/kernel-version.mk (working copy) @@ -26,8 +26,8 @@ ifeq ($(LINUX_VERSION),2.6.34) LINUX_KERNEL_MD5SUM:=10eebcb0178fb4540e2165bfd7efc7ad endif -ifeq ($(LINUX_VERSION),2.6.35-rc2) - LINUX_KERNEL_MD5SUM:=6b6b76e689e11b70b2e53f9482006929 +ifeq ($(LINUX_VERSION),2.6.35-rc3) + LINUX_KERNEL_MD5SUM:=aa9383b655787bac2f369a0b8b6fee76 endif # disable the md5sum check for unknown kernel versions @@ -38,4 +38,3 @@ KERNEL_BASE=$(firstword $(subst -, ,$(LINUX_VERSION))) KERNEL=$(call merge_version,$(wordlist 1,2,$(call split_version,$(KERNEL_BASE KERNEL_PATCHVER=$(call merge_version,$(wordlist 1,3,$(call split_version,$(KERNEL_BASE - ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] r21770 by florian also needed for 2.6.32 and 2.6.33 to build compat-wireless
trunk/target/linux/generic-2.6/patches-2.6.34/976-ssb_add_dma_dev.patch applies to 2.6.32.15 without any changes, should be the same for 2.6.33 too. Maddes ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] New Kernel 2.6.32.15
Just tested 2.6.32.15 on the Backfire branch for Orion CPU. Only the package carl9170 didn't compile and a few patches had some offsets. * MD5SUM: ifeq ($(LINUX_VERSION),2.6.32.15) LINUX_KERNEL_MD5SUM:=1cbbf16e93bbe03368172872690600c0 endif * Patches: Applying patch generic/007-squashfs_make_lzma_available.patch patching file include/linux/decompress/mm.h Hunk #1 succeeded at 63 (offset 10 lines). Hunk #2 succeeded at 85 (offset 10 lines). Applying patch generic/030-pci_disable_common_quirks.patch patching file drivers/pci/quirks.c Hunk #3 succeeded at 2519 with fuzz 1 (offset 1 line). Applying patch generic/840-unable_to_open_console.patch patching file init/main.c Hunk #1 succeeded at 807 (offset -5 lines). Applying patch generic/980-vm_exports.patch patching file kernel/sched.c Hunk #1 succeeded at 6113 (offset 8 lines). Applying patch generic/999-use_preinit_as_init.patch patching file init/main.c Hunk #1 succeeded at 831 (offset -5 lines). * carl9170 build error: CC [M] /home/maddes/openwrt/backfire/build_dir/linux-orion_generic/carl9170-1.0.1.1/drivers/net/wireless/ath/carl9170/main.o /home/maddes/openwrt/backfire/build_dir/linux-orion_generic/carl9170-1.0.1.1/drivers/net/wireless/ath/carl9170/main.c: In function 'ar9170_alloc': /home/maddes/openwrt/backfire/build_dir/linux-orion_generic/carl9170-1.0.1.1/drivers/net/wireless/ath/carl9170/main.c:1104: error: 'IEEE80211_HW_NOISE_DBM' undeclared (first use in this function) /home/maddes/openwrt/backfire/build_dir/linux-orion_generic/carl9170-1.0.1.1/drivers/net/wireless/ath/carl9170/main.c:1104: error: (Each undeclared identifier is reported only once /home/maddes/openwrt/backfire/build_dir/linux-orion_generic/carl9170-1.0.1.1/drivers/net/wireless/ath/carl9170/main.c:1104: error: for each function it appears in.) make[5]: *** [/home/maddes/openwrt/backfire/build_dir/linux-orion_generic/carl9170-1.0.1.1/drivers/net/wireless/ath/carl9170/main.o] Error 1 make[4]: *** [_module_/home/maddes/openwrt/backfire/build_dir/linux-orion_generic/carl9170-1.0.1.1/drivers/net/wireless/ath/carl9170] Error 2 make[4]: Leaving directory `/home/maddes/openwrt/backfire/build_dir/linux-orion_generic/linux-2.6.32.15' make[3]: *** [/home/maddes/openwrt/backfire/build_dir/linux-orion_generic/carl9170-1.0.1.1/.built] Error 2 make[3]: Leaving directory `/home/maddes/openwrt/backfire/package/carl9170' ERROR: package/carl9170 failed to build. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] mtd / Samsung flash chips
Salut Florian, you took care of ticket #6552 [1] and committed the patch into trunk. It came out that the patch broke compiling the Orion platform, that was reported in ticket #7348 [2]. Inside this ticket the reporter of #6552 and I came to a much cleaner approach. Would be great if you could have a look at it. Kind regards Matthias Maddes Bücher [1] https://dev.openwrt.org/ticket/6552 [2] https://dev.openwrt.org/ticket/7348 -- http://www.maddes.net/ Home: Earth / Germany / Ruhr-Area ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] different mtd erase size for a specific partion possible?
Today I checked out how to access the U-Boot variables of my WRT350N v2
(Orion) from Linux.
Installed uboot-envtools and created a fitting /etc/fw_env.config:
# WRT350N v2
# MTD device nameDevice offsetEnv. sizeFlash sector size
/dev/mtd50x0003c0000x20000x1000
I can read all U-Boot env vars, but not change any.
This seems to be a problem of the huge erase site 0x0001 of mtd.
Can I specify a separate erase size for the U-Boot partition?
static struct mtd_partition wrt350n_v2_nor_flash_partitions[] = {
{
...
}, {
.name = u-boot,
.offset = 0x007c,
.size = 0x0004,
}, {
...
},
};
linux: arch/arm/mach-orion5x/wrt350n-v2-setup.c
OpenWrt: target/linux/orion/patches/100-openwrt_partition_map.patch
Maddes
--
http://www.maddes.net/
Home: Earth / Germany / Ruhr-Area
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] different mtd erase size for a specific partion possible?
Both, backfire and latest trunk.
Can you hint me where this patch is?
Maddes
On 25.05.2010 21:59, Bernhard Loos wrote:
There is already a patch for this in openwrt, so it should work (in theory).
Do you use trunk or backfire or something older?
2010/5/25 Matthias Buecher / Germany m...@maddes.net:
Today I checked out how to access the U-Boot variables of my WRT350N v2
(Orion) from Linux.
Installed uboot-envtools and created a fitting /etc/fw_env.config:
# WRT350N v2
# MTD device nameDevice offsetEnv. sizeFlash sector size
/dev/mtd50x0003c0000x20000x1000
I can read all U-Boot env vars, but not change any.
This seems to be a problem of the huge erase site 0x0001 of mtd.
Can I specify a separate erase size for the U-Boot partition?
static struct mtd_partition wrt350n_v2_nor_flash_partitions[] = {
{
...
}, {
.name = u-boot,
.offset = 0x007c,
.size = 0x0004,
}, {
...
},
};
linux: arch/arm/mach-orion5x/wrt350n-v2-setup.c
OpenWrt: target/linux/orion/patches/100-openwrt_partition_map.patch
Maddes
--
http://www.maddes.net/
Home: Earth / Germany / Ruhr-Area
___
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] different mtd erase size for a specific partion possible?
So I can mark the partition with MTD_ERASE_PARTIAL, but I can not see
how I can limit erase size to 0x1000 so that only mtd offsets 0x3c000 to
0x3dfff gets erased.
The last 128 bytes (0x3ff80 - 3) of the mtd partition on WRT350N v2
are very important and shouldn't be touched.
Or should this work out of the box with uboot-envtools?
Maddes
On 25.05.2010 23:14, Bernhard Loos wrote:
https://dev.openwrt.org/browser/trunk/target/linux/generic-2.6/patches-2.6.32/222-partial_eraseblock_write.patch
2010/5/25 Matthias Buecher / Germany m...@maddes.net:
Both, backfire and latest trunk.
Can you hint me where this patch is?
Maddes
On 25.05.2010 21:59, Bernhard Loos wrote:
There is already a patch for this in openwrt, so it should work (in theory).
Do you use trunk or backfire or something older?
2010/5/25 Matthias Buecher / Germany m...@maddes.net:
Today I checked out how to access the U-Boot variables of my WRT350N v2
(Orion) from Linux.
Installed uboot-envtools and created a fitting /etc/fw_env.config:
# WRT350N v2
# MTD device nameDevice offsetEnv. sizeFlash sector size
/dev/mtd50x0003c0000x20000x1000
I can read all U-Boot env vars, but not change any.
This seems to be a problem of the huge erase site 0x0001 of mtd.
Can I specify a separate erase size for the U-Boot partition?
static struct mtd_partition wrt350n_v2_nor_flash_partitions[] = {
{
...
}, {
.name = u-boot,
.offset = 0x007c,
.size = 0x0004,
}, {
...
},
};
linux: arch/arm/mach-orion5x/wrt350n-v2-setup.c
OpenWrt: target/linux/orion/patches/100-openwrt_partition_map.patch
Maddes
--
http://www.maddes.net/
Home: Earth / Germany / Ruhr-Area
___
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] different mtd erase size for a specific partion possible?
Tried to set that flag, but can not find the right spot.
Any help?
Maddes
On 26.05.2010 00:08, Bernhard Loos wrote:
It should work out of the box with the patch.
It will (should) set the erase size to the right value.
2010/5/26 Matthias Buecher / Germany m...@maddes.net:
So I can mark the partition with MTD_ERASE_PARTIAL, but I can not see
how I can limit erase size to 0x1000 so that only mtd offsets 0x3c000 to
0x3dfff gets erased.
The last 128 bytes (0x3ff80 - 3) of the mtd partition on WRT350N v2
are very important and shouldn't be touched.
Or should this work out of the box with uboot-envtools?
Maddes
On 25.05.2010 23:14, Bernhard Loos wrote:
https://dev.openwrt.org/browser/trunk/target/linux/generic-2.6/patches-2.6.32/222-partial_eraseblock_write.patch
2010/5/25 Matthias Buecher / Germany m...@maddes.net:
Both, backfire and latest trunk.
Can you hint me where this patch is?
Maddes
On 25.05.2010 21:59, Bernhard Loos wrote:
There is already a patch for this in openwrt, so it should work (in
theory).
Do you use trunk or backfire or something older?
2010/5/25 Matthias Buecher / Germany m...@maddes.net:
Today I checked out how to access the U-Boot variables of my WRT350N v2
(Orion) from Linux.
Installed uboot-envtools and created a fitting /etc/fw_env.config:
# WRT350N v2
# MTD device nameDevice offsetEnv. sizeFlash sector size
/dev/mtd50x0003c0000x20000x1000
I can read all U-Boot env vars, but not change any.
This seems to be a problem of the huge erase site 0x0001 of mtd.
Can I specify a separate erase size for the U-Boot partition?
static struct mtd_partition wrt350n_v2_nor_flash_partitions[] = {
{
...
}, {
.name = u-boot,
.offset = 0x007c,
.size = 0x0004,
}, {
...
},
};
linux: arch/arm/mach-orion5x/wrt350n-v2-setup.c
OpenWrt: target/linux/orion/patches/100-openwrt_partition_map.patch
Maddes
--
http://www.maddes.net/
Home: Earth / Germany / Ruhr-Area
___
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
___
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] [PATCH] Add md5sums of latest stable kernels (2.6.32.13 and 2.6.34)
New stable kernel releases are available, especially 2.6.34 is interessting. The Orion platform compiles fine with 2.6.32.12. No re-basing of platform patches needed. Attached are two patches (-p0) for trunk. Add md5sums of latest stable kernels (2.6.32.13 and 2.6.34) Signed off by: Matthias Bücher m...@maddes.net Update Orion to kernel 2.6.32.13. Signed off by: Matthias Bücher m...@maddes.net Index: include/kernel-version.mk === --- include/kernel-version.mk (revision 21485) +++ include/kernel-version.mk (working copy) @@ -20,14 +20,17 @@ ifeq ($(LINUX_VERSION),2.6.32.12) LINUX_KERNEL_MD5SUM:=bc87db696ed4be729334584493d6d98d endif +ifeq ($(LINUX_VERSION),2.6.32.13) + LINUX_KERNEL_MD5SUM:=e66b1ec7eeb1a5f5d279574c6a2f3655 +endif ifeq ($(LINUX_VERSION),2.6.33.2) LINUX_KERNEL_MD5SUM:=80c5ff544b0ee4d9b5d8b8b89d4a0ef9 endif ifeq ($(LINUX_VERSION),2.6.33.3) LINUX_KERNEL_MD5SUM:=f651e9aafb2f910812257a63bcd639f2 endif -ifeq ($(LINUX_VERSION),2.6.34-rc5) - LINUX_KERNEL_MD5SUM:=c09ea93cd4e2684ebb506866c65a4c9f +ifeq ($(LINUX_VERSION),2.6.34) + LINUX_KERNEL_MD5SUM:=10eebcb0178fb4540e2165bfd7efc7ad endif # disable the md5sum check for unknown kernel versions Index: target/linux/orion/Makefile === --- target/linux/orion/Makefile (revision 21485) +++ target/linux/orion/Makefile (working copy) @@ -13,7 +13,7 @@ SUBTARGETS=generic harddisk CFLAGS=-Os -pipe -march=armv5t -mtune=xscale -funit-at-a-time -LINUX_VERSION:=2.6.32.12 +LINUX_VERSION:=2.6.32.13 include $(INCLUDE_DIR)/target.mk ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Add md5sums of latest stable kernels (2.6.32.13 and 2.6.34)
The 2.6.34 md5sum was added in r21498, so only 2.6.32.13 is missing. #1 Add md5sum of kernel 2.6.32.13. Signed off by: Matthias Bücher m...@maddes.net #2 Update Orion to kernel 2.6.32.13. Signed off by: Matthias Bücher m...@maddes.net On 17.05.2010 20:01, Matthias Buecher / Germany wrote: New stable kernel releases are available, especially 2.6.34 is interessting. The Orion platform compiles fine with 2.6.32.12. No re-basing of platform patches needed. Attached are two patches (-p0) for trunk. Add md5sums of latest stable kernels (2.6.32.13 and 2.6.34) Signed off by: Matthias Bücher m...@maddes.net Update Orion to kernel 2.6.32.13. Signed off by: Matthias Bücher m...@maddes.net Index: include/kernel-version.mk === --- include/kernel-version.mk (revision 21498) +++ include/kernel-version.mk (working copy) @@ -20,6 +20,9 @@ ifeq ($(LINUX_VERSION),2.6.32.12) LINUX_KERNEL_MD5SUM:=bc87db696ed4be729334584493d6d98d endif +ifeq ($(LINUX_VERSION),2.6.32.13) + LINUX_KERNEL_MD5SUM:=e66b1ec7eeb1a5f5d279574c6a2f3655 +endif ifeq ($(LINUX_VERSION),2.6.33.2) LINUX_KERNEL_MD5SUM:=80c5ff544b0ee4d9b5d8b8b89d4a0ef9 endif Index: target/linux/orion/Makefile === --- target/linux/orion/Makefile (revision 21485) +++ target/linux/orion/Makefile (working copy) @@ -13,7 +13,7 @@ SUBTARGETS=generic harddisk CFLAGS=-Os -pipe -march=armv5t -mtune=xscale -funit-at-a-time -LINUX_VERSION:=2.6.32.12 +LINUX_VERSION:=2.6.32.13 include $(INCLUDE_DIR)/target.mk ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [backfire] WRT54G flash space problem
It may not downsize the packages themselves, but moving kernel mods from rootfs to the kernel image will reduce the rootfs size. Leaving more space for JFFS2 rootfs_data. Having a K setting for kernel options would be great. Will try to have a look at it during the next weeks. Thanks for all your help Maddes On 10.05.2010 17:20, edgar.sol...@web.de wrote: there is partly in https://dev.openwrt.org/browser/trunk/include/kernel-defaults.mk line 101 you can actually add CONFIG_KERNEL_* entries to your .config and they are copied over as CONFIG_* to the kernel config. All that's missing is a menuconfig interface for that. But at least for routers using lzma squashfs for the initial image this will probably not downsize anything. .. ede On 10.05.2010 16:19, Stefan Monnier wrote: In 'make menuconfig' I included them with 'Y' instead of 'M'. According to my (newbie) knowledge that adds them to the kernel image. Can somebody please confirm my understanding? Or at least prove me wrong? :D Damn! I thought you had found a clever way to get them compiled into the kernel. I still hope some day someone will write the extra code needed so that make menuconfig can be told to build some modules right into the kernel. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [backfire] WRT54G flash space problem
Kernel and rootfs are in two different mtd partitions on the WRT54G: # dmesg ... Creating 5 MTD partitions on Physically mapped flash: 0x-0x0004 : cfe 0x0004-0x003f : linux 0x000bc000-0x0021 : rootfs mtd: partition rootfs doesn't start on an erase block boundary -- force read-only 0x003f-0x0040 : nvram 0x0021-0x003f : rootfs_data ... So it is moved from rootfs to linux in this case. Maddes On 10.05.2010 22:53, edgar.sol...@web.de wrote: but wouldn't the increase in the kernel image actually equal the decrease in the squash image and therefore the size of the rootfs_data stay the same? Both are lzma compressed. ..ede On 10.05.2010 19:16, Matthias Buecher / Germany wrote: It may not downsize the packages themselves, but moving kernel mods from rootfs to the kernel image will reduce the rootfs size. Leaving more space for JFFS2 rootfs_data. Having a K setting for kernel options would be great. Will try to have a look at it during the next weeks. Thanks for all your help Maddes On 10.05.2010 17:20, edgar.sol...@web.de wrote: there is partly in https://dev.openwrt.org/browser/trunk/include/kernel-defaults.mk line 101 you can actually add CONFIG_KERNEL_* entries to your .config and they are copied over as CONFIG_* to the kernel config. All that's missing is a menuconfig interface for that. But at least for routers using lzma squashfs for the initial image this will probably not downsize anything. .. ede On 10.05.2010 16:19, Stefan Monnier wrote: In 'make menuconfig' I included them with 'Y' instead of 'M'. According to my (newbie) knowledge that adds them to the kernel image. Can somebody please confirm my understanding? Or at least prove me wrong? :D Damn! I thought you had found a clever way to get them compiled into the kernel. I still hope some day someone will write the extra code needed so that make menuconfig can be told to build some modules right into the kernel. Stefan ___ 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] [backfire] WRT54G flash space problem
The linux partition spans over the kernel and the complete rootfs for flashing. The maximum kernel size is 0x000bc000 (begin of rootfs) minus 0x0004 (begin of linux) equals 0x0007c000 (496KB). Maddes On 10.05.2010 23:34, edgar.sol...@web.de wrote: are these sizes fixed or calculated according the space requirement? Looks like the linux size is fixed, what is the maximum size for a kernel on wrt54g? .. ede On 10.05.2010 23:28, Matthias Buecher / Germany wrote: Kernel and rootfs are in two different mtd partitions on the WRT54G: # dmesg ... Creating 5 MTD partitions on Physically mapped flash: 0x-0x0004 : cfe 0x0004-0x003f : linux 0x000bc000-0x0021 : rootfs mtd: partition rootfs doesn't start on an erase block boundary -- force read-only 0x003f-0x0040 : nvram 0x0021-0x003f : rootfs_data ... So it is moved from rootfs to linux in this case. Maddes On 10.05.2010 22:53, edgar.sol...@web.de wrote: but wouldn't the increase in the kernel image actually equal the decrease in the squash image and therefore the size of the rootfs_data stay the same? Both are lzma compressed. ..ede On 10.05.2010 19:16, Matthias Buecher / Germany wrote: It may not downsize the packages themselves, but moving kernel mods from rootfs to the kernel image will reduce the rootfs size. Leaving more space for JFFS2 rootfs_data. Having a K setting for kernel options would be great. Will try to have a look at it during the next weeks. Thanks for all your help Maddes On 10.05.2010 17:20, edgar.sol...@web.de wrote: there is partly in https://dev.openwrt.org/browser/trunk/include/kernel-defaults.mk line 101 you can actually add CONFIG_KERNEL_* entries to your .config and they are copied over as CONFIG_* to the kernel config. All that's missing is a menuconfig interface for that. But at least for routers using lzma squashfs for the initial image this will probably not downsize anything. .. ede On 10.05.2010 16:19, Stefan Monnier wrote: In 'make menuconfig' I included them with 'Y' instead of 'M'. According to my (newbie) knowledge that adds them to the kernel image. Can somebody please confirm my understanding? Or at least prove me wrong? :D Damn! I thought you had found a clever way to get them compiled into the kernel. I still hope some day someone will write the extra code needed so that make menuconfig can be told to build some modules right into the kernel. Stefan ___ 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] [backfire] WRT54G flash space problem
On 10.05.2010 23:47, Bernhard Loos wrote: 2010/5/10 Bernhard Loos bernhardl...@googlemail.com: 2010/5/10 Matthias Buecher / Germany m...@maddes.net: The linux partition spans over the kernel and the complete rootfs for flashing. The maximum kernel size is 0x000bc000 (begin of rootfs) minus 0x0004 (begin of linux) equals 0x0007c000 (496KB). Maddes This is not the maximum kernel size, it's only the current kernel size. You could probably get a few kb more flash space (32 at average) by changing the aligment of the rootfs, squashfs is read only, so it doesn't have to start at an erase block boundary. To clarify myself, the size is calculated dynamically, so compiling stuff into the kernel doesn't gain much. Thanks. This is different to my other router (WRT350Nv2, Orion CPU). On 10.05.2010 23:34, edgar.sol...@web.de wrote: are these sizes fixed or calculated according the space requirement? Looks like the linux size is fixed, what is the maximum size for a kernel on wrt54g? .. ede On 10.05.2010 23:28, Matthias Buecher / Germany wrote: Kernel and rootfs are in two different mtd partitions on the WRT54G: # dmesg ... Creating 5 MTD partitions on Physically mapped flash: 0x-0x0004 : cfe 0x0004-0x003f : linux 0x000bc000-0x0021 : rootfs mtd: partition rootfs doesn't start on an erase block boundary -- force read-only 0x003f-0x0040 : nvram 0x0021-0x003f : rootfs_data ... So it is moved from rootfs to linux in this case. Maddes On 10.05.2010 22:53, edgar.sol...@web.de wrote: but wouldn't the increase in the kernel image actually equal the decrease in the squash image and therefore the size of the rootfs_data stay the same? Both are lzma compressed. ..ede On 10.05.2010 19:16, Matthias Buecher / Germany wrote: It may not downsize the packages themselves, but moving kernel mods from rootfs to the kernel image will reduce the rootfs size. Leaving more space for JFFS2 rootfs_data. Having a K setting for kernel options would be great. Will try to have a look at it during the next weeks. Thanks for all your help Maddes On 10.05.2010 17:20, edgar.sol...@web.de wrote: there is partly in https://dev.openwrt.org/browser/trunk/include/kernel-defaults.mk line 101 you can actually add CONFIG_KERNEL_* entries to your .config and they are copied over as CONFIG_* to the kernel config. All that's missing is a menuconfig interface for that. But at least for routers using lzma squashfs for the initial image this will probably not downsize anything. .. ede On 10.05.2010 16:19, Stefan Monnier wrote: In 'make menuconfig' I included them with 'Y' instead of 'M'. According to my (newbie) knowledge that adds them to the kernel image. Can somebody please confirm my understanding? Or at least prove me wrong? :D Damn! I thought you had found a clever way to get them compiled into the kernel. I still hope some day someone will write the extra code needed so that make menuconfig can be told to build some modules right into the kernel. Stefan ___ 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 ___ 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] [backfire] WRT54G flash space problem
I could finally install everything onto my 4MB WRT54g v2.2. Avoided ntpclient plus dependencies with the patch from #7316. Added BusyBox's ether-wake to the build. Put all kmods (2) I needed into the kernel. This freed up enough JFFS2 space to normally install OpenVPN and a web-interface (here webif). Would be great if #7316 and its dependency #7312 could be committed to trunk and backfire. After this I would also update the ntpclient package to reduce flash mem usage for it too, Kind regards Maddes P.S.: Thanks Bastian for all the quick infos. On 04.05.2010 16:27, Matthias Buecher / Germany wrote: Can I save space in the flash mem when I add all needed packages directly to the image? Or is the JFFS2 compression as good as the compression of the read-only squashfs? I'm also going to replace ntpclient with rdate. As the clock of the WRT54G is very inaccurate it will not be sufficient to update the clock every 24h when my provider restarts the connection. Will have to add a cron job for rdate. Maddes On 30.04.2010 22:23, Matthias Buecher / Germany wrote: I wanted to upgrade my mom's WRT54G v2.2 from WR 0.9 to Backfire 10.03. But during installation the flash space got full and OpenVPN couldn't be installed. First I built an image without luci, then all packages fit into the flash mem. But when installing webif I got the same disk full error for it. Putting all needed kmods directly into the kernel didn't free enough space. Then I checked the sizes and dependencies of the needed packages between WR and Backfire. It turned out that OpenVPN installation grew by 148KB, and that BF had some more dependencies than WR. What is the smallest version of Luci possible? (luci-admin-mini + ???) Can OpenVPN be compiled to a smaller size? Is there a reason why OpenVPN grew so much, besides being a newer version? Is there a reason why OpenVPN needs zlib, besides being a newer version? Any help greatly appreciated Maddes Here is the list of the packages I need, plus a size comparison between WR 0.9 - Backfire. iptables-mod-[conntrack-]extra 8603 - 15081 kmod-ipt-[conntrack-]extra 14188 - 10446 ntpclient 11397 - 17461 librt n/a - 1102 ddns-scripts (ez-ipudate) 26368 - 6570 openvpn137843 - 195446 (+58KB, 2.0.8 - 2.1.1) kmod-tun 4944 - 4860 libopenssl 445303 - 500879 (+55KB, 0.9.8d - 0.9.8m) liblzo29113 - 28782 zlibn/a - 35023 (+35KB) sslh n/a - 7333 etherwake (ether-wake) 4799 - 6078 webif 155712 - 168862 webif-theme-xwrt 3765 -n/a haserl 8210 - 12277 uhttpd(in busybox?) - 22110 ___ 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] [backfire] WRT54G flash space problem
Re-checked the configs from my last build (available at ftp://ftp.maddes.net/openwrt/backfire/brcm-2.4/build_21402/squashfs/) In the menu config it is CONFIG_PACKAGE_kmod-tun=y, but in the kernel and final/used config it is CONFIG_TUN=m. So the better squashfs compression was what helped me. Thanks for the clarification, much appreciated. Maddes On 09.05.2010 18:28, Matthias Buecher / Germany wrote: Sorry, my description was inaccurate. In 'make menuconfig' the sign is '*' when pressing 'Y' and in the resulting config file it is '=Y'. @Bernhard: So this adds kernel modules to the squashfs image and not to the kernel image, and therefore I only benefitted from the better squashfs compression? Is this what you mean? Maddes On 09.05.2010 18:19, Bernhard Loos wrote: Actually, Y in menuconfig doesn't add the modules into the kernel, they will still be kernel modules. It only places the modules directly in the image and is in no way different from Y for programs. M creates packages for the modules/program without placing it in the image. If you want to compile a module into the kernel, you have to choose Y in kernel_menuconfig. Bernhard 2010/5/9 edgar.sol...@web.de: That's how it works. Y adds kernel modules to the kernel, and programs to the image. ..ede On 09.05.2010 18:10, Matthias Buecher / Germany wrote: In 'make menuconfig' I included them with 'Y' instead of 'M'. According to my (newbie) knowledge that adds them to the kernel image. Can somebody please confirm my understanding? Or at least prove me wrong? :D Maddes On 09.05.2010 17:56, Stefan Monnier wrote: Put all kmods (2) I needed into the kernel. How? Stefan ___ 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] [patch] missing uci get functions in lib/config/uci.sh
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Created a patch that adds two new functions to lib/config/uci.sh: uci_get() and uci_get_state() The counterparts to the existing uci_set() and uci_set_state() functions. A second patch changes packages to use the new functions, as several packages read UCI values with /sbin/uci in different and sometimes weird ways, e.g. 2/dev/null instead of uci -q. Both patches documented in ticket #7312 at https://dev.openwrt.org/ticket/7312 Kind regards Matthias Maddes Bücher -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvlcK4ACgkQUXXT+9wZdbUmgACfSZU9QLtwNOj4zlAgC6R/1mGw 3YkAoOph30R9q309zJGu+ncxjVWmvuZq =gLcU -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [patch] enhance rdate to support ntpclient functionalities (interval, interface)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 While trying to reduce flash mem usage for my old WRT54G with 4MB I created a patch that adds ntpclient functionalties to rdate. Additionally ntp servers are separated into a new config file to reduce JFFS2 usage even further. Patch and changes are documented in ticket #7316 at https://dev.openwrt.org/ticket/7316 Please apply to trunk and Backfire. CC: backf...@openwrt.org Kind regards Matthias Maddes Bücher -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvl1L8ACgkQUXXT+9wZdbWrAACgqN7ogEIBDELqvGnp5SArvT7n q0gAn2IXmTZEiL/vpUXnMTFC+WrCDWud =p9lF -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [backfire] WRT54G flash space problem
Can I save space in the flash mem when I add all needed packages directly to the image? Or is the JFFS2 compression as good as the compression of the read-only squashfs? I'm also going to replace ntpclient with rdate. As the clock of the WRT54G is very inaccurate it will not be sufficient to update the clock every 24h when my provider restarts the connection. Will have to add a cron job for rdate. Maddes On 30.04.2010 22:23, Matthias Buecher / Germany wrote: I wanted to upgrade my mom's WRT54G v2.2 from WR 0.9 to Backfire 10.03. But during installation the flash space got full and OpenVPN couldn't be installed. First I built an image without luci, then all packages fit into the flash mem. But when installing webif I got the same disk full error for it. Putting all needed kmods directly into the kernel didn't free enough space. Then I checked the sizes and dependencies of the needed packages between WR and Backfire. It turned out that OpenVPN installation grew by 148KB, and that BF had some more dependencies than WR. What is the smallest version of Luci possible? (luci-admin-mini + ???) Can OpenVPN be compiled to a smaller size? Is there a reason why OpenVPN grew so much, besides being a newer version? Is there a reason why OpenVPN needs zlib, besides being a newer version? Any help greatly appreciated Maddes Here is the list of the packages I need, plus a size comparison between WR 0.9 - Backfire. iptables-mod-[conntrack-]extra 8603 - 15081 kmod-ipt-[conntrack-]extra 14188 - 10446 ntpclient 11397 - 17461 librt n/a - 1102 ddns-scripts (ez-ipudate) 26368 - 6570 openvpn137843 - 195446 (+58KB, 2.0.8 - 2.1.1) kmod-tun 4944 - 4860 libopenssl 445303 - 500879 (+55KB, 0.9.8d - 0.9.8m) liblzo29113 - 28782 zlibn/a - 35023 (+35KB) sslh n/a - 7333 etherwake (ether-wake) 4799 - 6078 webif 155712 - 168862 webif-theme-xwrt 3765 -n/a haserl 8210 - 12277 uhttpd(in busybox?) - 22110 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] How to create an OpenWrt Package Makefile for source without a Makefile
Tried to create an OpenWrt of a small VoIP proxy for a friend. Unfortunately the source itself does not have a Makefile. It just says Use: gcc -o mjproxy md5.c mjproxy.c. How must the Build/Compile section look like for such a case? Looked at wiki and forum, but couldn't find any fitting information. If I missed a link then please tell me. Thanks in advance. Following is the current result of the OpenWrt Package Makefile. [packages] net/magicjack-proxy/Makefile # # Copyright (C) 2010 OpenWrt.org # # This is free software, licensed under the GNU General Public License v2. # See /LICENSE for more information. # include $(TOPDIR)/rules.mk PKG_NAME:=magicjack-proxy PKG_VERSION:=1 PKG_RELEASE:=1 PKG_SOURCE:=mjproxy.c.tar.gz PKG_SOURCE_URL:=http://www.mediafire.com/file/yzwmjzotmyy PKG_MD5SUM:=01262075cc72ad804f1d6b5dc181113b PKG_INSTALL:=1 include $(INCLUDE_DIR)/package.mk define Package/magicjack-proxy SECTION:=net CATEGORY:=Network TITLE:=MagicJack Proxy URL:=http://www.magicjacksupport.com/post42750.html#42750 # DEPENDS:= endef define Package/magicjack-proxy/description Proxy for MagicJack (VoIP service provider, http://www.magicjack.com/) endef #define Package/magicjack-proxy/conffiles #endef define Build/Compile #No Makefile available #gcc -o mjproxy md5.c mjproxy.c #ToDo: How to do it the right OpenWrt way? #???$(call Build/Compile/Default) $(MAKE) -C $(PKG_BUILD_DIR) \ $(TARGET_CONFIGURE_OPTS) \ CFLAGS=$(TARGET_CFLAGS) \ USELIBWRAP= \ all endef define Package/magicjack-proxy/install $(INSTALL_DIR) $(1)/usr/bin $(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/bin/mjproxy $(1)/usr/bin/ endef $(eval $(call BuildPackage,magicjack-proxy)) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] How to create an OpenWrt Package Makefile for source without a Makefile
Thanks to Mirko and Florian, I got it compiled and my friend will test tomorrow. Hmm, adding a Makefile via a patch to the original source looks like double work to me, but a valid idea. My friend and I are currently trying to get in contact with the author to get this addressed. If all goes well, I will create an enhancement ticket to add the MagicJack Proxy to the packages feed. Thanks for all your help Maddes On 02.05.2010 21:54, Stefan Monnier wrote: Tried to create an OpenWrt of a small VoIP proxy for a friend. Unfortunately the source itself does not have a Makefile. It just says Use: gcc -o mjproxy md5.c mjproxy.c. You've had answers to your question, but I'll point out that a better answer might be to provide a Makefile. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [backfire] WRT54G flash space problem
I wanted to upgrade my mom's WRT54G v2.2 from WR 0.9 to Backfire 10.03. But during installation the flash space got full and OpenVPN couldn't be installed. First I built an image without luci, then all packages fit into the flash mem. But when installing webif I got the same disk full error for it. Putting all needed kmods directly into the kernel didn't free enough space. Then I checked the sizes and dependencies of the needed packages between WR and Backfire. It turned out that OpenVPN installation grew by 148KB, and that BF had some more dependencies than WR. What is the smallest version of Luci possible? (luci-admin-mini + ???) Can OpenVPN be compiled to a smaller size? Is there a reason why OpenVPN grew so much, besides being a newer version? Is there a reason why OpenVPN needs zlib, besides being a newer version? Any help greatly appreciated Maddes Here is the list of the packages I need, plus a size comparison between WR 0.9 - Backfire. iptables-mod-[conntrack-]extra 8603 - 15081 kmod-ipt-[conntrack-]extra 14188 - 10446 ntpclient 11397 - 17461 librt n/a - 1102 ddns-scripts (ez-ipudate) 26368 - 6570 openvpn137843 - 195446 (+58KB, 2.0.8 - 2.1.1) kmod-tun 4944 - 4860 libopenssl 445303 - 500879 (+55KB, 0.9.8d - 0.9.8m) liblzo29113 - 28782 zlibn/a - 35023 (+35KB) sslh n/a - 7333 etherwake (ether-wake) 4799 - 6078 webif 155712 - 168862 webif-theme-xwrt 3765 -n/a haserl 8210 - 12277 uhttpd(in busybox?) - 22110 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [backfire][bug] setting LAN mac address, makes router inaccessible from LAN
On 29.04.2010 21:03, Jo-Philipp Wich wrote: Hmm, I got used to the fact that wan and lan mac are often the same on various routers... but when settings all bridge ports to the same mac, wouldn't that break arp etc.? ~ Jow If you do not set the LAN mac address, then all bridge ports will have the same mac address (confirmed on WRT350Nv2 and WRT54G v2.2). So this is not an issue, but the solution. Otherwise the switch doesn't work (at least on WRT350Nv2 and WRT54G v2.2). Use ifconfig | grep HWaddr to check your own router(s). Having different mac addresses for the WAN port and the LAN bridge works for me on WRT350Nv2 (not yet tested on WRT54G v2.2). I do not know what you refer to exactly with break arp. But I can tell you that when you change the LAN mac address, then also all switches of the network should be restarted to clear their ARP tables. Otherwise packets won't be routed until their ARP table entries get invalid. Maddes ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [backfire][bug] setting LAN mac address, makes router inaccessible from LAN
When changing the LAN mac address on a WRT54G v2.2 the router becomes inaccessible from the LAN (no ping, no SSH, etc.). The same happens on a WRT350Nv2 (Orion CPU), therefore it seems to be a general issue. Only revived the router back via serial access, as Backfire brcm47xx (Linux 2.6) provides no WLAN to access the router. So for others without serial access or JTAG, this issue is like a bricked router. This issue should definitely be on the known problems page [1] and verified on other devices. The patch from ticket #7111 [2] also fixed this issue on the WRT54G. Could the developers and/or patch team commit this to trunk and Backfire. Thanks in advance Maddes [1] https://dev.openwrt.org/milestone/Backfire%2010.03 (not listed anymore on https://dev.openwrt.org/milestone/) [2] https://dev.openwrt.org/ticket/7111 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [patch] Add kernel 2.6.32.11 to Backfire
Add MD5 sum of kernel 2.6.32.11 to Backfire. Signed off by: Matthias Buecher m...@maddes.net Index: target/linux/orion/Makefile === --- target/linux/orion/Makefile (revision 21152) +++ target/linux/orion/Makefile (working copy) @@ -13,7 +13,7 @@ SUBTARGETS=generic harddisk CFLAGS=-Os -pipe -march=armv5t -mtune=xscale -funit-at-a-time -LINUX_VERSION:=2.6.32.10 +LINUX_VERSION:=2.6.32.11 include $(INCLUDE_DIR)/target.mk ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [backfire] [bug] no reboot possible after firstboot
This works. Thanks. On 21.04.2010 22:14, Jo-Philipp Wich wrote: Try /bin/busybox reboot ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [Backfire] [bug] webif doesn't ask for user and password on initial connection, seems uhttpd related
Still the same issue with Backfire (10.03, r21131). r21122 didn't help. Maddes On 16.04.2010 21:47, Travis Kemen wrote: Ahhh, that is why it failed, password was set via the command line, hmm I will have see if uhttpd can be changed to mimic the old way (better IMO) or work around it. Travis On Fri, Apr 16, 2010 at 2:41 PM, Matthias Buecher / Germany m...@maddes.net wrote: I set the root password way before I installed packages. Here's how I installed Backfire: 1. Set root password via telnet to enable ssh 2. Configure network 3. Install other packages 4. Remove luci 5. Install webif Maddes On 16.04.2010 21:38, Travis Kemen wrote: It is supposed to be generated when the password is first set. Travis On Fri, Apr 16, 2010 at 2:29 PM, Matthias Buecher / Germany m...@maddes.net wrote: Checked with `opkg files webif | grep httpd` and that file is missing in the webif package. Maddes On 16.04.2010 21:26, Matthias Buecher / Germany wrote: Created /etc/httpd.conf with the two lines from jow. Then restarted via `/etc/init.d/uhttpd restart` It's working now as expected. Thanks for the help. Maddes On 16.04.2010 21:18, Jo-Philipp Wich wrote: /cgi-bin/webif/:root:\$p\$root /cgi-bin/webif/:admin:\$p\$root /cgi-bin/webif/:root:$p$root /cgi-bin/webif/:admin:$p$root No backslashes :) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [Backfire] [bug] webif doesn't ask for user and password on initial connection, seems uhttpd related
Unfortunately X-Wrt's r4894 was not added to X-Wrt's Backfire branch. When I compiled with the X-Wrt feed I still got the unfixed version. Hence I changed feeds.conf.default to src-svn xwrt http://x-wrt.googlecode.com/svn/trunk;, compiled and tested again. It worked fine for me. Please consider bring it to the X-Wrt Backfire branch. Thanks a lot Maddes On 25.04.2010 19:52, Travis Kemen wrote: This was fixed in x-wrt trunk. Travis On Sun, Apr 25, 2010 at 11:45 AM, Jo-Philipp Wich x...@subsignal.org wrote: r21122 didn't help. r21122 wasn't meant to fix it. X-Wrt still has to ship the httpd.conf. ~ Jow ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [backfire] [bug] no reboot possible after firstboot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 With Backfire I can not reboot the device after I issued a firstbot. This was working fine in previous trunk builds, e.g. 19875 from end of February. Have used it often to restart from scratch and test in a clean environment. r...@router:~# firstboot firstboot has already been run jffs2 partition is mounted, only resetting files @router:/root# reboot - -ash: reboot: not found Maddes -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvPWWQACgkQUXXT+9wZdbXM/ACeKaQB96L71Eg3lZJ5Qpga0rzH laAAoPDyUS1DbQzdcHNLY/eX5CI85123 =OyO9 -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] iptables NAT not being updated on WAN changes
Also tried /etc/init.d/firewall restart after restarting the network? Maddes On 18.04.2010 16:38, Nuno Gonçalves wrote: I have internet connections at eth0.2 and eth1. Config is like this: config interface wan option ifname eth1 option protodhcp After boot connection is ok. Computers behind router get NATed internet. Then I do ifdown wan, change eth1 to eth0.2 and ifup wan. Computers start getting Destination port unreachable to ping request. Inside the router I can ping the internet. Rebooting (with eth1 or eth0.2 selected, doesn't care) brings NATed connection back. /etc/init.d/network restart doesn't. r...@openwrt:/# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere anywherestate RELATED,ESTABLISHED ACCEPT all -- anywhere anywhere syn_flood tcp -- anywhere anywheretcp flags:FIN,SYN,RST,ACK/SYN input_rule all -- anywhere anywhere input all -- anywhere anywhere Chain FORWARD (policy DROP) target prot opt source destination zone_wan_MSSFIX all -- anywhere anywhere ACCEPT all -- anywhere anywherestate RELATED,ESTABLISHED forwarding_rule all -- anywhere anywhere forwardall -- anywhere anywhere reject all -- anywhere anywhere Chain OUTPUT (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere anywherestate RELATED,ESTABLISHED ACCEPT all -- anywhere anywhere output_rule all -- anywhere anywhere output all -- anywhere anywhere Chain forward (1 references) target prot opt source destination zone_lan_forward all -- anywhere anywhere zone_wan_forward all -- anywhere anywhere Chain forwarding_lan (1 references) target prot opt source destination Chain forwarding_rule (1 references) target prot opt source destination Chain forwarding_wan (1 references) target prot opt source destination Chain input (1 references) target prot opt source destination zone_lan all -- anywhere anywhere zone_wan all -- anywhere anywhere Chain input_lan (1 references) target prot opt source destination Chain input_rule (1 references) target prot opt source destination Chain input_wan (1 references) target prot opt source destination Chain output (1 references) target prot opt source destination zone_lan_ACCEPT all -- anywhere anywhere zone_wan_ACCEPT all -- anywhere anywhere Chain output_rule (1 references) target prot opt source destination Chain reject (5 references) target prot opt source destination REJECT tcp -- anywhere anywhere reject-with tcp-reset REJECT all -- anywhere anywhere reject-with icmp-port-unreachable Chain syn_flood (1 references) target prot opt source destination RETURN tcp -- anywhere anywheretcp flags:FIN,SYN,RST,ACK/SYN limit: avg 25/sec burst 50 DROP all -- anywhere anywhere Chain zone_lan (1 references) target prot opt source destination input_lan all -- anywhere anywhere zone_lan_ACCEPT all -- anywhere anywhere Chain zone_lan_ACCEPT (2 references) target prot opt source destination ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere Chain zone_lan_DROP (0 references) target prot opt source destination DROP all -- anywhere anywhere DROP all -- anywhere anywhere Chain zone_lan_MSSFIX (0 references) target prot opt source destination TCPMSS tcp -- anywhere anywheretcp flags:SYN,RST/SYN TCPMSS clamp to PMTU Chain zone_lan_REJECT (1 references) target prot opt source destination reject all -- anywhere anywhere reject all -- anywhere anywhere Chain zone_lan_forward (1 references) target prot opt source destination zone_wan_ACCEPT all -- anywhere anywhere forwarding_lan all -- anywhere anywhere zone_lan_REJECT all -- anywhere anywhere Chain zone_wan (1 references) target prot opt source destination ACCEPT udp -- anywhere anywhereudp dpt:68 ACCEPT icmp -- anywhere
Re: [OpenWrt-Devel] iptables NAT not being updated on WAN changes
You have to take care of it. Maddes On 18.04.2010 23:41, Nuno Gonçalves wrote: From: Matthias Buecher / Germany m...@maddes.net To: OpenWrt Development List openwrt-devel@lists.openwrt.org Subject: Re: [OpenWrt-Devel] iptables NAT not being updated on WAN changes Message-ID: 4bcb1ad8.3000...@maddes.net Content-Type: text/plain; charset=UTF-8 Also tried /etc/init.d/firewall restart after restarting the network? Maddes Restarting the firewall works. Is that something that I should do manually or just a bug? Regards ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [Backfire] [bug] webif doesn't ask for user and password on initial connection, seems uhttpd related
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Due to the problem I rebuild a Backfire image from r20886 with the config from http://downloads.openwrt.org/backfire/10.03/orion/OpenWrt.config opkg shows the following related to uhttpd and webif: uhttpd - 8 haserl - 0.9.26-1 webif - 0.3-4893 luci was replaced by webif the following way: opkg --autoremove --force-removal-of-dependent-packages remove luci-core luci-theme-base luci-nixio opkg install webif A file called httpd.conf is nowhere available. Searched via `find / - -name '*http*'`. But there is /etc/config/uhttpd from uci, so I attached this. The uci file for uhttpd is available in /rom and /overlay but has no differences, so it contains still the defaults. Maddes On 16.04.2010 20:40, Jo-Philipp Wich wrote: What version of uhttpd? What are the contents of /etc/httpd.conf ? ~ Jow -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvIsiwACgkQUXXT+9wZdbVrLACfbvKnF/H8PUDZAY4DGE1AMRzK pUsAoJ8WuEcv8njteC0Sh+pCEem0Dli1 =CxaS -END PGP SIGNATURE- # Server configuration config uhttpd main # HTTP listen addresses, multiple allowed list listen_http0.0.0.0:80 # list listen_http[::]:80 # HTTPS listen addresses, multiple allowed list listen_https 0.0.0.0:443 # list listen_https [::]:443 # Server document root option home /www # Certificate and private key for HTTPS. # If no listen_https addresses are given, # the key options are ignored. option cert /etc/uhttpd.crt option key /etc/uhttpd.key # CGI url prefix, will be searched in docroot. # Default is /cgi-bin option cgi_prefix /cgi-bin # Lua url prefix and handler script. # Lua support is disabled if no prefix given. # option lua_prefix /luci # option lua_handler /usr/lib/lua/luci/sgi/uhttpd.lua # CGI/Lua timeout, if the called script does not # write data within the given amount of seconds, # the server will terminate the request with # 504 Gateway Timeout response. option script_timeout 60 # Network timeout, if the current connection is # blocked for the specified amount of seconds, # the server will terminate the associated # request process. option network_timeout 30 # Basic auth realm, defaults to local hostname # option realmOpenWrt # Configuration file in busybox httpd format # option config /etc/httpd.conf # Certificate defaults for px5g key generator config cert px5g # Validity time option days 730 # RSA key size option bits 1024 # Location option country DE option stateBerlin option location Berlin # Common name option commonname OpenWrt -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEABECAAYFAkvIsi0ACgkQUXXT+9wZdbW+YgCgwpAc5sSIwg/Nh2lQ9tJ5I4/F CncAoMW3iKUtp8j8KhZ295vlH4Hs/mp0 =8NtD -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [Backfire] [bug] webif doesn't ask for user and password on initial connection, seems uhttpd related
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yes, it is missing. Where should it come from? OpenWrt or X-Wrt? Any clues what the content should look like? Are uci changes needed too? Maddes On 16.04.2010 20:56, Travis Kemen wrote: You should a /etc/httpd.conf file, if not, then this is the issue. Travis On Fri, Apr 16, 2010 at 1:53 PM, Matthias Buecher / Germany m...@maddes.net wrote: Due to the problem I rebuild a Backfire image from r20886 with the config from http://downloads.openwrt.org/backfire/10.03/orion/OpenWrt.config opkg shows the following related to uhttpd and webif: uhttpd - 8 haserl - 0.9.26-1 webif - 0.3-4893 luci was replaced by webif the following way: opkg --autoremove --force-removal-of-dependent-packages remove luci-core luci-theme-base luci-nixio opkg install webif A file called httpd.conf is nowhere available. Searched via `find / -name '*http*'`. But there is /etc/config/uhttpd from uci, so I attached this. The uci file for uhttpd is available in /rom and /overlay but has no differences, so it contains still the defaults. Maddes On 16.04.2010 20:40, Jo-Philipp Wich wrote: What version of uhttpd? What are the contents of /etc/httpd.conf ? ~ Jow # Server configuration config uhttpd main # HTTP listen addresses, multiple allowed list listen_http0.0.0.0:80 # list listen_http[::]:80 # HTTPS listen addresses, multiple allowed list listen_https 0.0.0.0:443 # list listen_https [::]:443 # Server document root option home /www # Certificate and private key for HTTPS. # If no listen_https addresses are given, # the key options are ignored. option cert /etc/uhttpd.crt option key /etc/uhttpd.key # CGI url prefix, will be searched in docroot. # Default is /cgi-bin option cgi_prefix /cgi-bin # Lua url prefix and handler script. # Lua support is disabled if no prefix given. # option lua_prefix /luci # option lua_handler /usr/lib/lua/luci/sgi/uhttpd.lua # CGI/Lua timeout, if the called script does not # write data within the given amount of seconds, # the server will terminate the request with # 504 Gateway Timeout response. option script_timeout 60 # Network timeout, if the current connection is # blocked for the specified amount of seconds, # the server will terminate the associated # request process. option network_timeout 30 # Basic auth realm, defaults to local hostname # option realmOpenWrt # Configuration file in busybox httpd format # option config /etc/httpd.conf # Certificate defaults for px5g key generator config cert px5g # Validity time option days 730 # RSA key size option bits 1024 # Location option country DE option stateBerlin option location Berlin # Common name option commonname OpenWrt - -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEABECAAYFAkvIsi0ACgkQUXXT+9wZdbW+YgCgwpAc5sSIwg/Nh2lQ9tJ5I4/F CncAoMW3iKUtp8j8KhZ295vlH4Hs/mp0 =8NtD - -END PGP SIGNATURE- ___ 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 -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvItqMACgkQUXXT+9wZdbU6wgCgsY2jFm7OgPUiov/6NENmzySd oioAoP2PrTMcrA11xmrraV0uQdjY9Moe =lIYv -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Changeset 20803 for kernel 2.6.33.2 incomplete
Changeset 20803 ( https://dev.openwrt.org/changeset/20803 ) updated the patches for 2.6.33.2, but adding this version to include/kernel-version.mk was forgotten (see https://dev.openwrt.org/browser/trunk/include/kernel-version.mk ). Maddes ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [patch] wrong mac address on bridge devices
Reminder to add ticket #7111 and also #7113 to trunk and backport to Backfire. Thanks Maddes On 07.04.2010 19:45, Matthias Buecher / Germany wrote: Documented in https://dev.openwrt.org/ticket/7111, so it will not be forgotten. Maddes On 03.04.2010 17:13, Matthias Buecher / Germany wrote: Sorry, forgot the signed-off part: Set mac address for bridge also on sub-devices * cc: backf...@openwrt.org Signed-off by: Matthias Buecher m...@maddes.net and Peter van Valderen p.v.valde...@gmail.com On 02.04.2010 21:21, Matthias Buecher / Germany wrote: If a mac address is set for the lan bridge, e.g. network.lan.macaddr=00:1a:70:a0:38:80 then it is only set on the bridge itself and not the sub-devices br-lanLink encap:Ethernet HWaddr 00:1A:70:A0:38:80 lan1 Link encap:Ethernet HWaddr 00:00:00:00:51:81 lan2 Link encap:Ethernet HWaddr 00:00:00:00:51:81 lan3 Link encap:Ethernet HWaddr 00:00:00:00:51:81 lan4 Link encap:Ethernet HWaddr 00:00:00:00:51:81 The attached patch (really simple) also sets the mac address on the sub-devices. It is tested and used for some weeks on LinkSys WRT350Nv2 by some forum members. It is also a prerequisite for the next WRT350Nv2 patch. Kind regards Matthias Maddes Bücher ___ 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] Backfire 10.03 Released
Wow, that fast (not to say hasty): three RCs and the release in only two weeks. I wasn't even able to test RC3 before the release came out. Maddes On 07.04.2010 09:02, Nico wrote: OpenWrt Release 10.03, codename Backfire. The OpenWrt team will humbly like to announce the final version of the 10.03 release, codenamed Backfire. ___ __ | |.-.-.-.| | | |..| |_ | - || _ | -__| || | | || _|| _| |___|| __|_|__|__||||__| || |__| W I R E L E S S F R E E D O M Backfire (10.03, r20728) -- * 1/3 shot KahluaIn a shot glass, layer Kahlua * 1/3 shot Bailey's on the bottom, then Bailey's, * 1/3 shot Vodka then Vodka. --- The OpenWrt 10.03 backfire source code can be checked out at: svn://svn.openwrt.org/openwrt/branches/backfire/ Further information on how to checkout the Backfire source code is found at: https://dev.openwrt.org/wiki/GetSource Highlights and changes since last stable release: * Linux 2.6.32 long term support kernel, uClibc 0.9.30 * Support for mac80211 based drivers, such as ath5k, ath9k and b43 * Support for alternative libc implementations * New web server uhttpd (busybox httpd now disabled, as default) * Extended support for X.org with GTK+, QT etc. * New switch configuration format for Broadcom devices. See: http://wiki.openwrt.org/doc/uci/network#switch * New wpa-supplicant and hostapd multicall binary wpad * Initial mac80211 wireless support for Broadcom radios * Modular preinit system * Optional support for rootfs on external media * Support for the TRX v2 format required by newer devices such as the Linksys WRT54G3GV2-VF * New /etc/openwrt_release machine-readable file with detailed release version information New platforms: * Atheros AP81: Ubiquiti Router Station Pro, TP-Link TL-WR1043ND, Netgear WNDR3700, etc. (ar71xx) * Broadcom ADSL modem/router chipsets (brcm63xx) * Cavium Networks Octeon based boards (octeon) * Cobalt Networks MIPS-based servers (cobalt) * Infineon Danube/TwinPass with open DSL VoIP drivers (ifxmips) * Ingenic XBurst: QI Ben NanoNote (xburst/qi-lb60) * Intel Tolapai SoC (x86/ep80579) * Marvell Kirkwood: SheevaPlug, GuruPlug, OpenRD... (kirkwood) * Marvell Orion SoC (orion) Known Issues: * Currently 5 GHz channels do not work with mac80211 based drivers due to DFS regulatory issues. More detailed information available at: https://dev.openwrt.org/milestone/Backfire%2010.03 Special thanks to marcant.net for offering buildbot assistance Yours truly, -- The release management team Andy Boyett Nicolas Thill ___ 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] set mac address for bridge also on sub-devices
Documented in https://dev.openwrt.org/ticket/7111, so it will not be forgotten. Maddes On 03.04.2010 17:13, Matthias Buecher / Germany wrote: Sorry, forgot the signed-off part: Set mac address for bridge also on sub-devices * cc: backf...@openwrt.org Signed-off by: Matthias Buecher m...@maddes.net and Peter van Valderen p.v.valde...@gmail.com On 02.04.2010 21:21, Matthias Buecher / Germany wrote: If a mac address is set for the lan bridge, e.g. network.lan.macaddr=00:1a:70:a0:38:80 then it is only set on the bridge itself and not the sub-devices br-lanLink encap:Ethernet HWaddr 00:1A:70:A0:38:80 lan1 Link encap:Ethernet HWaddr 00:00:00:00:51:81 lan2 Link encap:Ethernet HWaddr 00:00:00:00:51:81 lan3 Link encap:Ethernet HWaddr 00:00:00:00:51:81 lan4 Link encap:Ethernet HWaddr 00:00:00:00:51:81 The attached patch (really simple) also sets the mac address on the sub-devices. It is tested and used for some weeks on LinkSys WRT350Nv2 by some forum members. It is also a prerequisite for the next WRT350Nv2 patch. Kind regards Matthias Maddes Bücher ___ 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] set mac address for bridge also on sub-devices
Sorry, forgot the signed-off part: Set mac address for bridge also on sub-devices * cc: backf...@openwrt.org Signed-off by: Matthias Buecher m...@maddes.net and Peter van Valderen p.v.valde...@gmail.com On 02.04.2010 21:21, Matthias Buecher / Germany wrote: If a mac address is set for the lan bridge, e.g. network.lan.macaddr=00:1a:70:a0:38:80 then it is only set on the bridge itself and not the sub-devices br-lanLink encap:Ethernet HWaddr 00:1A:70:A0:38:80 lan1 Link encap:Ethernet HWaddr 00:00:00:00:51:81 lan2 Link encap:Ethernet HWaddr 00:00:00:00:51:81 lan3 Link encap:Ethernet HWaddr 00:00:00:00:51:81 lan4 Link encap:Ethernet HWaddr 00:00:00:00:51:81 The attached patch (really simple) also sets the mac address on the sub-devices. It is tested and used for some weeks on LinkSys WRT350Nv2 by some forum members. It is also a prerequisite for the next WRT350Nv2 patch. Kind regards Matthias Maddes Bücher ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [patch] set mac address for bridge also on sub-devices
If a mac address is set for the lan bridge, e.g.
network.lan.macaddr=00:1a:70:a0:38:80
then it is only set on the bridge itself and not the sub-devices
br-lanLink encap:Ethernet HWaddr 00:1A:70:A0:38:80
lan1 Link encap:Ethernet HWaddr 00:00:00:00:51:81
lan2 Link encap:Ethernet HWaddr 00:00:00:00:51:81
lan3 Link encap:Ethernet HWaddr 00:00:00:00:51:81
lan4 Link encap:Ethernet HWaddr 00:00:00:00:51:81
The attached patch (really simple) also sets the mac address on the
sub-devices.
It is tested and used for some weeks on LinkSys WRT350Nv2 by some forum
members.
It is also a prerequisite for the next WRT350Nv2 patch.
Kind regards
Matthias Maddes Bücher
--
http://www.maddes.net/
Home: Earth / Germany / Ruhr-Area
Index: package/base-files/files/lib/network/config.sh
===
--- package/base-files/files/lib/network/config.sh (revision 20654)
+++ package/base-files/files/lib/network/config.sh (working copy)
@@ -115,6 +115,8 @@
config_get iftype $config type
case $iftype in
bridge)
+ local macaddr
+ config_get macaddr $config macaddr
[ -x /usr/sbin/brctl ] {
ifconfig br-$config 2/dev/null /dev/null {
local newdevs devices
@@ -139,7 +141,7 @@
# result in another setup_interface() call, so we simply stop processing
# the current event at this point.
}
-ifconfig $iface up 2/dev/null /dev/null
+ifconfig $iface ${macaddr:+hw ether ${macaddr}} up 2/dev/null /dev/null
return 1
}
;;
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Backfire 10.03-rc2 - luci issues
Happens to me on Linksys WRT350Nv2 (Orion CPU): Adminstration - System - System: XML Parsing Error: unclosed token Location: http://10.0.0.254/cgi-bin/luci/;stok=160e97786ece60ac94533c0785be4583/admin/system/system/ Line Number 264, Column 3: input type=submit class=cbi-button cbi-button-fieldadd value= ^ (pointing onto input) Adminstration - System - LEDs: XML Parsing Error: unclosed token Location: http://10.0.0.254/cgi-bin/luci/;stok=160e97786ece60ac94533c0785be4583/admin/system/leds/ Line Number 368, Column 53:div class=cbi-value id=cbi-system-wifi_led-devlabel class=cbi-value-title for=cbid.system.wifi_led.dev ^ (pointing onto label) Maddes On 01.04.2010 00:05, Nico wrote: *** Release Candidate 2 *** The OpenWrt Team would like to announce a second release candidate (RC2) of the next major release, codenamed Backfire. Testing of this build will help refine the code in preparation of RC3 and the final release. Binaries can be downloaded at http://downloads.openwrt.org/backfire/10.03-rc2/ Changes since Backfire RC1: * Kernel updated to 2.6.32.10 * New web server (uhttpd) for the web interface, supporting SSL/TLS and CGI, replaces busybox httpd applet * Support for .trx v2 firmware image format added (needed for Linksys WRT54G3GV2-VF) New packages: * cyassl * px5g * uhttpd New targets: * kirkwood (Marvell Kirkwood: SheevaPlug, GuruPlug, OpenRD...) * xburst (Ingenic XBurst: QI Ben NanoNote) Known Issues: * Encounters of spurious log messages every second on some brcm-2.4 brcm47xx installs * Kernel modules missing on ixp4xx * Under rare circumstances, certain LuCI pages may crash due to a bug in the Lua VM More detailed informations available at https://dev.openwrt.org/milestone/Backfire%2010.03-rc2 Note: due to some last minute build problems, ifxmips is not included in RC2, but will be included in RC3 and final Backfire release. Special thanks to marcant.net [1] for offering buildbot assistance :) 1. http://marcant.net/ Yours truly, -- The release management team Andy Boyett Nicolas Thill ___ 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] Backfire 10.03-rc1
Do I understand correctly that kernel 2.6.32.9 is one of the preferred
kernels for Backfire, and not 2.6.30.10?
(see https://dev.openwrt.org/changeset/20410 and Nico's [2])
Just want to make sure.
Maddes
P.S.:
Will install it onto my LinkSys WRT350Nv2 this weekend if time permits.
On 24.03.2010 18:15, Nico wrote:
Backfire 10.03-rc1 is still based on trunk @ 20254. In Backfire
10.03-rc1 milestone in Trac [1], you can find the diff used attached
[2] at the end of the page.
1. https://dev.openwrt.org/milestone/Backfire%2010.03-rc1
2.
https://dev.openwrt.org/attachment/milestone/Backfire%2010.03-rc1/backfire-10.03-rc1-trunk-r20254.diff
Regards,
--
-{Nico}
Bruno Wolff III wrote:
On Wed, Mar 24, 2010 at 17:10:25 +0100,
Nico n...@openwrt.org wrote:
*** Release Candidate 1 ***
The OpenWrt Team would like to announce a release candidate (RC1) of the
next major release, codenamed Backfire. Testing of this build will help
refine the code in preparation of the final release.
Binaries can be downloaded at
http://downloads.openwrt.org/backfire/10.03-rc1/
Is there a separate branch for backfire or is it trunk?
(I want some extra things built in, and so am interested in doing builds
that use the same code as backfire but with a couple of different build
options.)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Backfire 10.03-rc1
Sorry, a typo, meant 2.6._32_.10 not .30.10.
On 25.03.2010 22:15, Matthias Buecher / Germany wrote:
Do I understand correctly that kernel 2.6.32.9 is one of the preferred
kernels for Backfire, and not 2.6.30.10?
(see https://dev.openwrt.org/changeset/20410 and Nico's [2])
Just want to make sure.
Maddes
P.S.:
Will install it onto my LinkSys WRT350Nv2 this weekend if time permits.
On 24.03.2010 18:15, Nico wrote:
Backfire 10.03-rc1 is still based on trunk @ 20254. In Backfire
10.03-rc1 milestone in Trac [1], you can find the diff used attached
[2] at the end of the page.
1. https://dev.openwrt.org/milestone/Backfire%2010.03-rc1
2.
https://dev.openwrt.org/attachment/milestone/Backfire%2010.03-rc1/backfire-10.03-rc1-trunk-r20254.diff
Regards,
--
-{Nico}
Bruno Wolff III wrote:
On Wed, Mar 24, 2010 at 17:10:25 +0100,
Nico n...@openwrt.org wrote:
*** Release Candidate 1 ***
The OpenWrt Team would like to announce a release candidate (RC1) of the
next major release, codenamed Backfire. Testing of this build will help
refine the code in preparation of the final release.
Binaries can be downloaded at
http://downloads.openwrt.org/backfire/10.03-rc1/
Is there a separate branch for backfire or is it trunk?
(I want some extra things built in, and so am interested in doing builds
that use the same code as backfire but with a couple of different build
options.)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Backfire 10.03-rc1
If 2.6.32.10 will be *the* desired version, then Orion can be just
switched to it.
My WRT350Nv2 is really running fine with it.
File: target/linux/orion/Makefile
No need to rebase any patches.
Maddes
On 25.03.2010 22:57, Nico wrote:
It seems 2.6.32.10 applies on all targets at 2.6.32.9, so I have no
problem switching to 2.6.32.10. Ideally, it would be great if all
targets at 2.6.32.x could be switched to the same version (coherency)
and such updates be committed before Friday evening.
--
-{Nico}
On 25/03/10 22:44, Matthias Buecher / Germany wrote:
Sorry, a typo, meant 2.6._32_.10 not .30.10.
On 25.03.2010 22:15, Matthias Buecher / Germany wrote:
Do I understand correctly that kernel 2.6.32.9 is one of the preferred
kernels for Backfire, and not 2.6.30.10?
(see https://dev.openwrt.org/changeset/20410 and Nico's [2])
Just want to make sure.
Maddes
P.S.:
Will install it onto my LinkSys WRT350Nv2 this weekend if time permits.
On 24.03.2010 18:15, Nico wrote:
Backfire 10.03-rc1 is still based on trunk @ 20254. In Backfire
10.03-rc1 milestone in Trac [1], you can find the diff used attached
[2] at the end of the page.
1. https://dev.openwrt.org/milestone/Backfire%2010.03-rc1
2.
https://dev.openwrt.org/attachment/milestone/Backfire%2010.03-rc1/backfire-10.03-rc1-trunk-r20254.diff
Regards,
--
-{Nico}
Bruno Wolff III wrote:
On Wed, Mar 24, 2010 at 17:10:25 +0100,
Nico n...@openwrt.org wrote:
*** Release Candidate 1 ***
The OpenWrt Team would like to announce a release candidate (RC1) of the
next major release, codenamed Backfire. Testing of this build will help
refine the code in preparation of the final release.
Binaries can be downloaded at
http://downloads.openwrt.org/backfire/10.03-rc1/
Is there a separate branch for backfire or is it trunk?
(I want some extra things built in, and so am interested in doing builds
that use the same code as backfire but with a couple of different build
options.)
___
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] WRT160NL new bootloader fix
Is the script set to executable (+x) in the image? This is typical for scripts that are presebt but not running, and often overlooked. Maddes On 20.03.2010 04:02, Otto Solares wrote: It works on squashfs but didn't on pure jffs2 which I pressume was our only environment difference. The logcat diff between jffs2 and squashfs seems to be: +user.info sysinit: Trying to fix trx header in firmware at 0x20... +user.info sysinit: New crc32: 0x407d9371, rewriting block +user.info sysinit: Done. +user.warn kernel: jffs2_scan_eraseblock(): End of filesystem marker found at 0x0 +user.warn kernel: jffs2_build_filesystem(): unlocking the mtd device... done. +user.warn kernel: jffs2_build_filesystem(): erasing all blocks after the end marker... done. +user.info sysinit: copying files ... done +user.info kernel: mini_fo: using base directory: / +user.info kernel: mini_fo: using storage directory: /jffs Obviously it's not running on pure jffs2 images but it seems to me a bug in the firstboot scripts unrelated to your patch... - Otto On Fri, Mar 19, 2010 at 08:12:24PM -0600, Otto Solares wrote: Rechecked and yes, I'm using your latest patch and at boot the file /lib/firstboot/25_fixtrx is there but next boot lose the firmware. BTW I'm just using pure jffs2 image, will test squashfs and let you know. - Otto On Sat, Mar 20, 2010 at 02:27:29AM +0100, Bernhard Loos wrote: Are you really sure, you used the second patch I posted and the firstboot script is included in the image? 2010/3/20 Otto Solares so...@guug.org: On Fri, Mar 19, 2010 at 06:34:03PM -0600, Otto Solares wrote: On Fri, Mar 19, 2010 at 11:25:40AM -0600, Otto Solares wrote: On Fri, Mar 19, 2010 at 04:53:34PM +0100, Bernhard Loos wrote: Does this happen directly after flashing or only after a reboot? After the first reboot. If openwrt does come up at least once, could you run mtd -o 32 fixtrx firmware and give me the output? Yes, it comes up once and for the next reboot/power-cycle it lose the firmware and waits for a TFTP firmware. I'm not near this new WRT160NL so I'll send you the output later. r...@openwrt:~# mtd -o 32 fixtrx firmware Trying to fix trx header in firmware at 0x20... New crc32: 0x73ea777a, rewriting block Done. FYI after this command it always boots fine now. - Otto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [patch] Update Orion to kernel 2.6.32.10
Update Orion to Linux kernel 2.6.32.10 Signed off by: Matthias Buecher m...@maddes.net The most simple, a single line in the Makefile. All patches applied cleanly. Everything compiled well. Index: target/linux/orion/Makefile === --- target/linux/orion/Makefile (revision 20245) +++ target/linux/orion/Makefile (working copy) @@ -13,7 +13,7 @@ SUBTARGETS=generic harddisk CFLAGS=-Os -pipe -march=armv5t -mtune=xscale -funit-at-a-time -LINUX_VERSION:=2.6.32.9 +LINUX_VERSION:=2.6.32.10 include $(INCLUDE_DIR)/target.mk ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [patch] Update Orion to kernel 2.6.32.10
On 17.03.2010 21:01, Travis Kemen wrote: On Wed, Mar 17, 2010 at 5:26 AM, Matthias Buecher / Germany m...@maddes.net wrote: Update Orion to Linux kernel 2.6.32.10 Signed off by: Matthias Buecher m...@maddes.net The most simple, a single line in the Makefile. All patches applied cleanly. Everything compiled well. Kaloz will have to handle this as he maintains this arch. Travis Ok, just for the record, I'm running a 2.6.32.10 build of trunk r20245 on WRT350N v2. Plus iptables-mod-conntrack-extra, OpenVPN, Etherwake, X-Wrt, SSLH, ntpclient, sudo, ddns-scripts. Right now all is working fine, but it is currently only one full day in production :) Maddes ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [Backfire] opkg.conf pointing to current snapshot packages
Just flashed Backfire 10.03-beta for Orion from http://downloads.openwrt.org/backfire/10.03-beta/orion/ and recognized that opkg is pointing to src/gz snapshots http://downloads.openwrt.org/snapshots/trunk/orion/packages instead of src/gz backfire http://downloads.openwrt.org/backfire/10.03-beta/orion/packages This way people are testing trunk packages and not the backfire beta packages. For Orion I would also recommend to use the current state plus kernel 2.6.32.10. Kind regards Maddes ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [Backfire] opkg.conf pointing to current snapshot packages
Yes, I did. To verify I manually downloaded some packages and compared their MD5 checksum with the listing in Packages and Packages.gz: r...@router:/tmp# wget http://downloads.openwrt.org/backfire/10.03-beta/orion/packages/kmod-ipt-conntrack-extra_2.6.30.10-1_orion.ipk Connecting to downloads.openwrt.org (78.24.191.177:80) kmod-ipt-conntrack-e 100% |*.| 10734 --:--:-- ETA r...@router:/tmp# md5sum kmod-ipt-conntrack-extra_2.6.30.10-1_orion.ipk c189cac9e4dc9c0ccfbb9390f9578245 kmod-ipt-conntrack-extra_2.6.30.10-1_orion.ipk Package: kmod-ipt-conntrack-extra Version: 2.6.30.10-1 Filename: kmod-ipt-conntrack-extra_2.6.30.10-1_orion.ipk Size: 10734 MD5Sum: ba0a174f7169a0eeabea3efa6482210f Download works, size fits but MD5 checksum is different. On my desktop I get the same result for the download as on my router. I would assume wrong Packages[.gz] uploaded, at least for Orion Maddes On 16.03.2010 22:56, Travis Kemen wrote: Did you do a opkg update before installing like the errors say to do? Travis On Tue, Mar 16, 2010 at 4:52 PM, Matthias Buecher / Germany m...@maddes.net wrote: On 16.03.2010 21:42, Bruno Wolff III wrote: On Tue, Mar 16, 2010 at 19:14:59 +0100, Matthias Buecher / Germany m...@maddes.net wrote: Just flashed Backfire 10.03-beta for Orion from http://downloads.openwrt.org/backfire/10.03-beta/orion/ and recognized that opkg is pointing to src/gz snapshots http://downloads.openwrt.org/snapshots/trunk/orion/packages instead of src/gz backfire http://downloads.openwrt.org/backfire/10.03-beta/orion/packages This way people are testing trunk packages and not the backfire beta packages. I ended up scp'ing particular packages to my test router and installing them. So I did actually test a few backfire packages of interest. I changed /etc/opkg.conf to point to the Orion packages but always get MD5 errors: Installing iptables-mod-conntrack-extra (1.4.6-1) to root... Downloading http://downloads.openwrt.org/backfire/10.03-beta/orion/packages/iptables-mod-conntrack-extra_1.4.6-1_orion.ipk. Installing kmod-ipt-conntrack-extra (2.6.30.10-1) to root... Downloading http://downloads.openwrt.org/backfire/10.03-beta/orion/packages/kmod-ipt-conntrack-extra_2.6.30.10-1_orion.ipk. Installing kmod-ipt-conntrack-extra (2.6.30.10-1) to root... Collected errors: * opkg_install_pkg: Package kmod-ipt-conntrack-extra md5sum mismatch. Either the opkg or the package index are corrupt. Try 'opkg update'. * opkg_install_cmd: Cannot install package iptables-mod-conntrack-extra. * opkg_install_pkg: Package kmod-ipt-conntrack-extra md5sum mismatch. Either the opkg or the package index are corrupt. Try 'opkg update'. * opkg_install_cmd: Cannot install package kmod-ipt-conntrack-extra. Maddes ___ 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
