Re: [OpenWrt-Devel] [PATCH][include] Reduce configuration file entropy

[Matthias Buecher / Germany]

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  >
> 
> 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  >
> ---
> 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 
> ===
> --- include/scan.mk  (revision 36502)
> +++ include/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

[Matthias Buecher / Germany]

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  <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  <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  <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

Re: [OpenWrt-Devel] [PATCH] [package] dropbear: Supports IdleTimeout uci config option

[Matthias Buecher / Germany]

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  >
> Date: Thu, 6 Sep 2012 16:45:29 -0300
> Subject: [PATCH] [package] dropbear: Supports IdleTimeout uci config option
> 
> Signed-off-by: Jonh Wendell  >
> ---
>  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
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] tools/firmware-utils/trx: new option -c to set flags in trx headers

[Matthias Buecher / Germany]

Signed-off by: Matthias Buecher 

- - - -

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 
@@ -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 
@@ -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 [

Re: [OpenWrt-Devel] [patch] orion/generic: enhanced image makefile - updated

[Matthias Buecher / Germany]

Just a short reminder.

As the first mail got mangled here's an updated patch (now have "Toggle Word 
Wrap" for Thunderbird).
It's the same makefile just using "-sysupgrade" and "-factory" in the image 
names to avoid questions about which image to use (same as ar71xx, brcm63xx, 
etc.) 

http://patchwork.openwrt.org/patch/2330/ should be updated with this mail.

Kind regards
Maddes


Following is the commit comment:

- - - -

* 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
* Use for "-sysupgrade" and "-factory" in image names (like ar71xx, brcm63xx, 
etc.) to avoid questions about which image to use

Signed-off by: Matthias Buecher 

- - - -

Patch inline for comments and also attached.

Index: target/linux/orion/image/generic.mk
===
--- target/linux/orion/image/generic.mk (revision 32896)
+++ 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 n

[OpenWrt-Devel] [PATCH] build system: reproduceable order in packageinfo and targetinfo

[Matthias Buecher / Germany]

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 



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] build system: reproduceable order in packageinfo and targetinfo

[Matthias Buecher / Germany]

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 


Addtional 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, 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

[Matthias Buecher / Germany]

* 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 


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

[Matthias Buecher / Germany]

On 07.04.2012 20:28, Imre Kaloz wrote:
> On Fri, 06 Apr 2012 18:31:13 +0200, 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).
> 
> 
> 
> 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

Re: [OpenWrt-Devel] [PATCH] flexible kernel mtd size for orion_generic targets

[Matthias Buecher / Germany]

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 
> 
> 
> 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 - 
> ++.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

[OpenWrt-Devel] [PATCH] flexible kernel mtd size for orion_generic targets

[Matthias Buecher / Germany]

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 


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 - 
++  .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 = (CONFIG_OPENWRT_KERNEL_MTD_SIZE * 1024),

Re: [OpenWrt-Devel] WBMR-HP-G300H flash image for flashing from original FW?

[Matthias Buecher / Germany]

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!

[Matthias Buecher / Germany]

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

[Matthias Buecher / Germany]

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 
>>>
>>>
>>> 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 
>>> -   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
>>>  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
>>> i

Re: [OpenWrt-Devel] [PATCH] update wrt350nv2-builder to v2.4 and use new functionality for target orion_generic

[Matthias Buecher / Germany]

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 
>>
>>
>> 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 
>> -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
>>  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

Re: [OpenWrt-Devel] [patch] target orion_generic: use magic_long in sysupgrade

[Matthias Buecher / Germany]

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 
> 
> 
> 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

[Matthias Buecher / Germany]

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 
> 
> 
> 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 
> - 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
>  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;
>   ad

[OpenWrt-Devel] [PATCH] update wrt350nv2-builder to v2.4 and use new functionality for target orion_generic

[Matthias Buecher / Germany]

Signed-off-by: Matthias Bücher 


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 
-   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
 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] target orion_generic: use magic_long in sysupgrade

[Matthias Buecher / Germany]

Signed-off-by: Matthias Bücher 


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] Orion generic target: enhanced image makefile

[Matthias Buecher / Germany]

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 

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
-   ( \
-   

[OpenWrt-Devel] [patch] Flexible kernel size support, split linux partition to rootfs after uimage

[Matthias Buecher / Germany]

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 ""
+
+/*
+ * 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 

Re: [OpenWrt-Devel] [PATCH 5/5] [orion] kernel and its mtd size

[Matthias Buecher / Germany]

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

[Matthias Buecher / Germany]

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

[Matthias Buecher / Germany]

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 
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] procps change in r27585 has bad conditions

[Matthias Buecher / Germany]

The change in r27585 will fail with future major versions of gcc:
"#if __GNUC__ < 4 || __GNUC_MINOR__ < 3"
1.0 = ok
4.0 = ok
5.0 = FAIL

correct would be:
"#if __GNUC__ < 4 || (__GNUC__ == 4 && __GNUC_MINOR__< 3)"
1.0 = ok
4.0 = ok
5.0 = ok

Just my two cents
Maddes
___
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

[Matthias Buecher / Germany]

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

[OpenWrt-Devel] pjsip doesn't build in trunk Orion due libgcc issue

[Matthias Buecher / Germany]

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

Re: [OpenWrt-Devel] [PATCH] Orion doesn't build anymore / kmod-crypto-hash and kmod-crypto-core

[Matthias Buecher / Germany]

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] Lantiq TAPI driver also build for other platforms

[Matthias Buecher / Germany]

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

[Matthias Buecher / Germany]

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

[Matthias Buecher / Germany]

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

Re: [OpenWrt-Devel] [PATCH] Orion doesn't build anymore

[Matthias Buecher / Germany]

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

[OpenWrt-Devel] Orion doesn't build anymore

[Matthias Buecher / Germany]

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

[Matthias Buecher / Germany]

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 
>> Reply-To: Tanguy Pruvot ,  OpenWrt Development
>> List 
>> To: OpenWrt Development List 
> 
>> 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

[Matthias Buecher / Germany]

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 
Reply-To: Tanguy Pruvot ,  OpenWrt Development
List 
To: OpenWrt Development List 

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

[Matthias Buecher / Germany]

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] [patch] ticket #8241 necessary to compile 2.6.37 for Orion

[Matthias Buecher / Germany]

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

[Matthias Buecher / Germany]

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] Kernel build error on kmod-md-raid456 with current trunk

[Matthias Buecher / Germany]

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

[OpenWrt-Devel] Reminder: Clean-up of generic patches 014 and 089 for 2.6.36+

[Matthias Buecher / Germany]

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

Re: [OpenWrt-Devel] [PATCH][orion]Kernelpatches for kernel 2.6.36

[Matthias Buecher / Germany]

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 
> --
> 
> 
> 
> 
> ___
> 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

[Matthias Buecher / Germany]

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] triggerhappy: update to 0.1.6

[Matthias Buecher / Germany]

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  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] Remove obsolete patches

[Matthias Buecher / Germany]

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 
>> ---
>>  .../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;
>> -

Re: [OpenWrt-Devel] [PATCH] Remove obsolete patches

[Matthias Buecher / Germany]

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 
> ---
>  .../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
___
o

Re: [OpenWrt-Devel] [PATCH] Remove obsolete patches

[Matthias Buecher / Germany]

On 12.11.2010 21:33, Guillaume LECERF wrote:
> 2010/11/12 Matthias Buecher / Germany :
>> 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] [PATCH] Remove obsolete patches

[Matthias Buecher / Germany]

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 
> ---
>  .../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 < 

Re: [OpenWrt-Devel] Build Issues: Packages not build for kernel 2.6.35, e.g. USB

[Matthias Buecher / Germany]

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

Re: [OpenWrt-Devel] Build Issues: Packages not build for kernel 2.6.35, e.g. USB

[Matthias Buecher / Germany]

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] Build Issues: Packages not build for kernel 2.6.35, e.g. USB

[Matthias Buecher / Germany]

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?

[Matthias Buecher / Germany]

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}."
> - retu

Re: [OpenWrt-Devel] Separate image creation per profile/target possible?

[Matthias Buecher / Germany]

Hi again,

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 have a look.

Thanks for all your help
Maddes


On 30.10.2010 20:38, Luka Perkov wrote:
> Hi,
> 
> On Fri, Oct 29, 2010 at 10:11:09PM +0200, Matthias Buecher / Germany wrote:
>> #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.
> 
> You can have profiles in subtargets. Look at ifxmips/danube:
> 
> https://dev.openwrt.org/browser/trunk/target/linux/ifxmips/danube
>  
>> #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)
> 
> No, it is not only USB support it is also support for the hard disks,
> raid and file system which gets built in the kernel. Not like modules
> when you select the same stuff from 'make menuconfig'. You might want
> this behavior if your kernel MTD is big!
> 
>> #3
>> Separated 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?
> 
> Well, currently yes. I have made working patches for D-Link DNS323
> storage device:
> 
> http://dns323.lukaperkov.net/
> 
> I'm still testing them although they seem to work just fine. I will
> submit them again "soon" with a daemon that I'm now writing for this
> device.
> DNS323 is going to be a subtarget by itself.
> 
> Luka
> ___
> 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] Separate image creation per profile/target possible?

[Matthias Buecher / Germany]

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
>  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?

[Matthias Buecher / Germany]

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

[Matthias Buecher / Germany]

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

[Matthias Buecher / Germany]

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

Re: [OpenWrt-Devel] mac80211 / openwrt - some complaints

[Matthias Buecher / Germany]

On 13.09.2010 13:22, Bastian Bittorf wrote:
> Zitat von Jo-Philipp Wich :
> 
>>> 5) there is no way to manipulate crond using UCI
>>
>> Should be trivial to implement.
> 
> i will send a patch...("ehrenwort!")

Something similar is available via webif (X-Wrt). May have a look there.

>>> 7) there is no way to start/stop/restart rdate
>>
>> "ifup wan". Its a hotplug driven mechanism, doing it as init script
> 
> yes, i read the script: but in a mesh-network, we have
> no wan 8-), so how to call the script in a clear way?
> (e.g. from cron)

see https://forum.openwrt.org/viewtopic.php?id=24719
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [backfire] Busybox update?

[Matthias Buecher / Germany]

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

[Matthias Buecher / Germany]

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

[Matthias Buecher / Germany]

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?

[Matthias Buecher / Germany]

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

[Matthias Buecher / Germany]

Updates MD5SUM of kernel 2.6.35 to RC3.

Signed off by: Matthias Buecher 
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

[Matthias Buecher / Germany]

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

[Matthias Buecher / Germany]

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

Re: [OpenWrt-Devel] different mtd erase size for a specific partion possible?

[Matthias Buecher / Germany]

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 :
>> 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 :
>>>> 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 :
>>>>>> 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

Re: [OpenWrt-Devel] different mtd erase size for a specific partion possible?

[Matthias Buecher / Germany]

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 :
>> 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 :
>>>> 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?

[Matthias Buecher / Germany]

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 :
>> 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] different mtd erase size for a specific partion possible?

[Matthias Buecher / Germany]

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] mtd / Samsung flash chips

[Matthias Buecher / Germany]

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

Re: [OpenWrt-Devel] [PATCH] Add md5sums of latest stable kernels (2.6.32.13 and 2.6.34)

[Matthias Buecher / Germany]

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 


#2
Update Orion to kernel 2.6.32.13.

Signed off by: Matthias Bücher 


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 
> 
> 
> 
> Update Orion to kernel 2.6.32.13.
> 
> Signed off by: Matthias Bücher 
> 

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

[OpenWrt-Devel] [PATCH] Add md5sums of latest stable kernels (2.6.32.13 and 2.6.34)

[Matthias Buecher / Germany]

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 



Update Orion to kernel 2.6.32.13.

Signed off by: Matthias Bücher 
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] [backfire] WRT54G flash space problem

[Matthias Buecher / Germany]

On 10.05.2010 23:47, Bernhard Loos wrote:
> 2010/5/10 Bernhard Loos :
>> 2010/5/10 Matthias Buecher / Germany :
>>> 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

[Matthias Buecher / Germany]

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

[Matthias Buecher / Germany]

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

[Matthias Buecher / Germany]

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

[Matthias Buecher / Germany]

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  :
>>> 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

Re: [OpenWrt-Devel] [backfire] WRT54G flash space problem

[Matthias Buecher / Germany]

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  :
>> 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

Re: [OpenWrt-Devel] [backfire] WRT54G flash space problem

[Matthias Buecher / Germany]

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

Re: [OpenWrt-Devel] [backfire] WRT54G flash space problem

[Matthias Buecher / Germany]

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

[OpenWrt-Devel] [trunk] lzma patch for ARM missing in target/linux/generic-2.6/patches-2.6.33

[Matthias Buecher / Germany]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Please copy
"target/linux/generic-2.6/patches-2.6.32/055-lzma_arm_kernel.patch" to
"target/linux/generic-2.6/patches-2.6.33/".

Thanks
Matthias "Maddes" Bücher

-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvl2v8ACgkQUXXT+9wZdbUyEQCfVxlhtVE1NJ9cPG/Q2GGFtwSH
g9kAnA+BYeW6R5o9UNk5Mmn0QC5WKSA5
=Qszl
-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)

[Matthias Buecher / Germany]

-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

[OpenWrt-Devel] [patch] missing uci get functions in lib/config/uci.sh

[Matthias Buecher / Germany]

-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

Re: [OpenWrt-Devel] [backfire] WRT54G flash space problem

[Matthias Buecher / Germany]

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

Re: [OpenWrt-Devel] How to create an OpenWrt Package Makefile for source without a Makefile

[Matthias Buecher / Germany]

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] How to create an OpenWrt Package Makefile for source without a Makefile

[Matthias Buecher / Germany]

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

[OpenWrt-Devel] [backfire] WRT54G flash space problem

[Matthias Buecher / Germany]

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

[Matthias Buecher / Germany]

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

Re: [OpenWrt-Devel] [backfire][bug] setting LAN mac address, makes router inaccessible from LAN

[Matthias Buecher / Germany]

On 29.04.2010 10:34, edgar.sol...@web.de wrote:
> 
>> 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.
>>
> 
> Wouldn't it still be possible to tftp flash the router? Looks like it ..
> ede

Yes, it is possible under special circumstances.
Still, mentioning and fixing the issue is the correct solution.

I tried to follow the instructions at [1] but with no success.
For successful TFTPing I needed serial access to set "boot_wait" to on.

#1 Failsafe mode:
Just tested again with brcm-2.4 and brcm47xx 2.6, pressing "Reset" when
the DMZ led lights up, the router really went into failsafe and a telnet
daemon was started (checked via serial access).
But I can not access the router, no ping, no telnet and therefore no
firstboot to fix the wrong setup.
Seems that LAN connection is not available at all.

#2 TFTP:
The referred TFTP link [2] does not exist on the new oldwiki.
So I digged it from the real old wiki [3].

First I do not think that the normal end user has "boot_wait" set to
"on" in nvram, so most will get stuck here.

Even I needed over 20 tries to finally put the file via the "ping in
another window" method. Most users will stop trying earlier.
Used the following command:
  tftp -i 192.168.1.1 put openwrt-wrt54g-squashfs_backfire_10.03.bin

[1] http://nuwiki.openwrt.org/oldwiki/openwrtdocs/troubleshooting
[2] http://nuwiki.openwrt.org/oldwiki/openwrtviatftp
[3]
http://oldwiki.openwrt.org/OpenWrtDocs%282f%29Installing%282f%29TFTP.html

___
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

[Matthias Buecher / Germany]

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

Re: [OpenWrt-Devel] [Backfire] [bug] webif doesn't ask for user and password on initial connection, seems uhttpd related

[Matthias Buecher / Germany]

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  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

Re: [OpenWrt-Devel] [Backfire] [bug] webif doesn't ask for user and password on initial connection, seems uhttpd related

[Matthias Buecher / Germany]

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
>  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
>>>>  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] no reboot possible after firstboot

[Matthias Buecher / Germany]

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

[OpenWrt-Devel] [patch] Add kernel 2.6.32.11 to Backfire

[Matthias Buecher / Germany]

Add MD5 sum of kernel 2.6.32.11 to Backfire.

Signed off by: Matthias Buecher 

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

[OpenWrt-Devel] [patch] Update Orion to kernel 2.6.32.11

[Matthias Buecher / Germany]

Updates Orion target to kernel 2.6.32.11
CC: backf...@openwrt.org

Signed off by: Matthias Buecher 

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

[OpenWrt-Devel] [backfire] [bug] no reboot possible after firstboot

[Matthias Buecher / Germany]

-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

[Matthias Buecher / Germany]

You have to take care of it.

Maddes

On 18.04.2010 23:41, Nuno Gonçalves wrote:
>> From: Matthias Buecher / Germany 
>> To: OpenWrt Development List 
>> 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] iptables NAT not being updated on WAN changes

[Matthias Buecher / Germany]

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  

Re: [OpenWrt-Devel] [Backfire] [bug] [SOLVED] webif doesn't ask for user and password on initial connection, seems uhttpd related

[Matthias Buecher / Germany]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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
>  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 :)

-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvIvVMACgkQUXXT+9wZdbVl9wCeJYcpeHpTF9anQmRpUuSwBAMs
xa0An1L4MG67mnm7iPD+Hp4v8P9u1fkH
=c1ZK
-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] [SOLVED] webif doesn't ask for user and password on initial connection, seems uhttpd related

[Matthias Buecher / Germany]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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 :)
> 

-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvIuqcACgkQUXXT+9wZdbWjfQCfXM9MbLI2gbW764WCj6Lv8Lnl
gWQAoP3P1Aay8ydlk8og+5Ngb+uPHjMR
=C7iX
-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] [SOLVED] webif doesn't ask for user and password on initial connection, seems uhttpd related

[Matthias Buecher / Germany]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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 :)

-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvIub8ACgkQUXXT+9wZdbWzYwCg/KvJY8U6C2zCU3M++77syvOl
ZToAn1HvNSLxAqwI8aljKUzKApSMfueT
=V90f
-END PGP SIGNATURE-
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel