Re: [OpenWrt-Devel] [PATCH] busybox: enable CONFIG_HOSTNAME
Hi Stefan, With your patch, system.hostname is still broken, and you have to reconfigure all zabbix agent. I prefer to patch zabbix (if busybox hostname is a nogo) Regards, Etienne Stefan Hellermann a écrit : >Hi Etienne, > >we don't really need busybox hostname, we can read it directly from >/proc/sys/kernel/hostname >and save a fork every time zabbix needs the hostname. > >Patch against the packages repository. > >Signed-off-by: Stefan Hellermann > >diff --git a/admin/zabbix/Makefile b/admin/zabbix/Makefile >index 5ee8425..2836354 100644 >--- a/admin/zabbix/Makefile >+++ b/admin/zabbix/Makefile >@@ -99,12 +99,6 @@ As it uses libiwinfo, it works with all wifi devices >supported by openwrt. > See http://wiki.openwrt.org/doc/howto/zabbix for ready to use zabbix >templates. > endef > >- >-define Package/zabbix-agentd/config >- select BUSYBOX_CONFIG_HOSTNAME if !PACKAGE_net-tools-hostname >- select BUSYBOX_CONFIG_UNAME if !PACKAGE_coreutils-uname >-endef >- > CONFIGURE_ARGS+= \ > --enable-agent \ > --enable-server \ >diff --git a/admin/zabbix/patches/010-change-agentd-config.patch >b/admin/zabbix/patches/010-change-agentd-config.patch >index 58424e9..a79fc72 100644 >--- a/admin/zabbix/patches/010-change-agentd-config.patch >+++ b/admin/zabbix/patches/010-change-agentd-config.patch >@@ -50,7 +50,15 @@ > ### Option: HostnameItem > #Item used for generating Hostname if it is undefined. > #Ignored if Hostname is defined. >-@@ -213,7 +204,7 @@ Hostname=Zabbix server >+@@ -140,6 +131,7 @@ Hostname=Zabbix server >+ # Mandatory: no >+ # Default: >+ # HostnameItem=system.hostname >++HostnameItem=vfs.file.contents[/proc/sys/kernel/hostname] >+ >+ ### Option: RefreshActiveChecks >+ #How often list of active checks is refreshed, in seconds. >+@@ -213,7 +205,7 @@ Hostname=Zabbix server > # Include= > > # Include=/usr/local/etc/zabbix_agentd.userparams.conf > > > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] busybox: enable CONFIG_HOSTNAME
Hi Etienne,
yes, "system.hostname" is still broken, and "system.users.num" is also
broken, the last one needs busybox who.
I'm using "agent.hostname" instead of "system.hostname", I don't need
"system.users.num" and deploy my configuration files from a central place.
But you're right, it's probably easier to just add hostname and maybe who
to busybox. Additionally we should apply the first hunk of my patch to
remove the selects on BUSYBOX_CONFIG_{HOSTNAME,UNAME}
What do the maintainers of openwrt/busybox think? Is it useful to have a
hostname binary on a router/access point? Maybe for shell scripts or
some web-interface? If yes, can you add it?
Otherwise we should patch zabbix to default to read the hostname from
/proc/sys/kernel/hostname. The configuration change in my patch below is
not enough, as it will not update already deployed systems.
Regards,
Stefan
2014/1/21 Etienne CHAMPETIER
> Hi Stefan,
>
> With your patch, system.hostname is still broken, and you have to
> reconfigure all zabbix agent.
> I prefer to patch zabbix (if busybox hostname is a nogo)
>
> Regards,
> Etienne
>
> Stefan Hellermann a écrit :
>
> >Hi Etienne,
> >
> >we don't really need busybox hostname, we can read it directly from
> >/proc/sys/kernel/hostname
> >and save a fork every time zabbix needs the hostname.
> >
> >Patch against the packages repository.
> >
> >Signed-off-by: Stefan Hellermann
> >
> >diff --git a/admin/zabbix/Makefile b/admin/zabbix/Makefile
> >index 5ee8425..2836354 100644
> >--- a/admin/zabbix/Makefile
> >+++ b/admin/zabbix/Makefile
> >@@ -99,12 +99,6 @@ As it uses libiwinfo, it works with all wifi devices
> >supported by openwrt.
> > See http://wiki.openwrt.org/doc/howto/zabbix for ready to use zabbix
> >templates.
> > endef
> >
> >-
> >-define Package/zabbix-agentd/config
> >- select BUSYBOX_CONFIG_HOSTNAME if !PACKAGE_net-tools-hostname
> >- select BUSYBOX_CONFIG_UNAME if !PACKAGE_coreutils-uname
> >-endef
> >-
> > CONFIGURE_ARGS+= \
> > --enable-agent \
> > --enable-server \
> >diff --git a/admin/zabbix/patches/010-change-agentd-config.patch
> >b/admin/zabbix/patches/010-change-agentd-config.patch
> >index 58424e9..a79fc72 100644
> >--- a/admin/zabbix/patches/010-change-agentd-config.patch
> >+++ b/admin/zabbix/patches/010-change-agentd-config.patch
> >@@ -50,7 +50,15 @@
> > ### Option: HostnameItem
> > #Item used for generating Hostname if it is undefined.
> > #Ignored if Hostname is defined.
> >-@@ -213,7 +204,7 @@ Hostname=Zabbix server
> >+@@ -140,6 +131,7 @@ Hostname=Zabbix server
> >+ # Mandatory: no
> >+ # Default:
> >+ # HostnameItem=system.hostname
> >++HostnameItem=vfs.file.contents[/proc/sys/kernel/hostname]
> >+
> >+ ### Option: RefreshActiveChecks
> >+ #How often list of active checks is refreshed, in seconds.
> >+@@ -213,7 +205,7 @@ Hostname=Zabbix server
> > # Include=
> >
> > # Include=/usr/local/etc/zabbix_agentd.userparams.conf
> >
> >
> >
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] busybox: enable CONFIG_HOSTNAME
* Stefan Hellermann [21.01.2014 10:09]: > What do the maintainers of openwrt/busybox think? Is it useful to have a > hostname binary on a router/access point? Maybe for shell scripts or > some web-interface? If yes, can you add it? is the applet 'hostname' really just needed for getting the hostname? (or more, because it can do some thinks like e.g. 'nisdomainname') maybe it the zabbix-case, you can add a file /bin/hostname with: #!/bin/sh uci get system.@system[0].hostname bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] busybox: enable CONFIG_HOSTNAME
Hi all, for the hostname problem we can just update zabbix to 2.2.x see https://svn.zabbix.com/browse/ZBX-5616 For the who part, is there a way to know the number of connected users in /proc or ... - Mail original - > De: "Bastian Bittorf" > À: "OpenWrt Development List" > Envoyé: Mardi 21 Janvier 2014 10:14:52 > Objet: Re: [OpenWrt-Devel] [PATCH] busybox: enable CONFIG_HOSTNAME > > * Stefan Hellermann [21.01.2014 10:09]: > > What do the maintainers of openwrt/busybox think? Is it useful to > > have a > > hostname binary on a router/access point? Maybe for shell scripts > > or > > some web-interface? If yes, can you add it? > > is the applet 'hostname' really just needed for getting the hostname? > (or more, because it can do some thinks like e.g. 'nisdomainname') > > maybe it the zabbix-case, you can add a file /bin/hostname with: > > #!/bin/sh > uci get system.@system[0].hostname > > bye, bastian > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] busybox: backport dd conv=swab from 1.22
Some boards have the WLAN EEPROM stored in flash in big-endian format,
whereas the driver requires the EEPROM in little-endian format. The
conv=swab option in dd is particularly useful in this case. This patch
backports this feature from busybox-1.22.
Signed-off-by: Matti Laakso
---
Index: trunk/package/utils/busybox/patches/008-backport-dd-conv-swab.patch
===
--- trunk/package/utils/busybox/patches/008-backport-dd-conv-swab.patch
(revision 0)
+++ trunk/package/utils/busybox/patches/008-backport-dd-conv-swab.patch
(working copy)
@@ -0,0 +1,97 @@
+--- a/coreutils/dd.c
b/coreutils/dd.c
+@@ -10,7 +10,7 @@
+
+ //usage:#define dd_trivial_usage
+ //usage: "[if=FILE] [of=FILE] " IF_FEATURE_DD_IBS_OBS("[ibs=N] [obs=N]
") "[bs=N] [count=N] [skip=N]\n"
+-//usage: " [seek=N]" IF_FEATURE_DD_IBS_OBS("
[conv=notrunc|noerror|sync|fsync]")
++//usage: " [seek=N]" IF_FEATURE_DD_IBS_OBS("
[conv=notrunc|noerror|sync|fsync|swab]")
+ //usage:#define dd_full_usage "\n\n"
+ //usage: "Copy a file with converting and formatting\n"
+ //usage: "\n if=FILE Read from FILE instead of stdin"
+@@ -30,6 +30,7 @@
+ //usage: "\n conv=noerrorContinue after read errors"
+ //usage: "\n conv=sync Pad blocks with zeros"
+ //usage: "\n conv=fsync Physically write data out before
finishing"
++//usage: "\n conv=swab Swap every pair of bytes"
+ //usage: )
+ //usage: "\n"
+ //usage: "\nNumbers may be suffixed by c (x1), w (x2), b (x512), kD
(x1000), k (x1024),"
+@@ -155,9 +156,10 @@ int dd_main(int argc UNUSED_PARAM, char
+ FLAG_SYNC= 1 << 1,
+ FLAG_NOERROR = 1 << 2,
+ FLAG_FSYNC = 1 << 3,
++ FLAG_SWAB= 1 << 4,
+ /* end of conv flags */
+- FLAG_TWOBUFS = 1 << 4,
+- FLAG_COUNT = 1 << 5,
++ FLAG_TWOBUFS = 1 << 5,
++ FLAG_COUNT = 1 << 6,
+ };
+ static const char keywords[] ALIGN1 =
+ "bs\0""count\0""seek\0""skip\0""if\0""of\0"
+@@ -167,7 +169,7 @@ int dd_main(int argc UNUSED_PARAM, char
+ ;
+ #if ENABLE_FEATURE_DD_IBS_OBS
+ static const char conv_words[] ALIGN1 =
+- "notrunc\0""sync\0""noerror\0""fsync\0";
++ "notrunc\0""sync\0""noerror\0""fsync\0""swab\0";
+ #endif
+ enum {
+ OP_bs = 0,
+@@ -185,11 +187,11 @@ int dd_main(int argc UNUSED_PARAM, char
+ OP_conv_sync,
+ OP_conv_noerror,
+ OP_conv_fsync,
++ OP_conv_swab,
+ /* Unimplemented conv=XXX: */
+ //nocreat do not create the output file
+ //excl fail if the output file already exists
+ //fdatasync physically write output file data before finishing
+- //swab swap every pair of input bytes
+ //lcase change upper case to lower case
+ //ucase change lower case to upper case
+ //block pad newline-terminated records with spaces to cbs-size
+@@ -207,12 +209,14 @@ int dd_main(int argc UNUSED_PARAM, char
+ struct {
+ int flags;
+ size_t oc;
++ ssize_t prev_read_size; /* for detecting swab failure */
+ off_t count;
+ off_t seek, skip;
+ const char *infile, *outfile;
+ } Z;
+ #define flags (Z.flags )
+ #define oc (Z.oc )
++#define prev_read_size (Z.prev_read_size)
+ #define count (Z.count )
+ #define seek(Z.seek )
+ #define skip(Z.skip )
+@@ -375,6 +379,27 @@ int dd_main(int argc UNUSED_PARAM, char
+* conv=noerror just ignores input bad blocks */
+ n = 0;
+ }
++ if (flags & FLAG_SWAB) {
++ uint16_t *p16;
++ ssize_t n2;
++
++ /* Our code allows only last read to be odd-sized */
++ if (prev_read_size & 1)
++ bb_error_msg_and_die("can't swab %lu byte
buffer",
++ (unsigned long)prev_read_size);
++ prev_read_size = n;
++
++ /* If n is odd, last byte is not swapped:
++ * echo -n "qwe" | dd conv=swab
++ * prints "wqe".
++ */
++ p16 = (void*) ibuf;
++ n2 = (n >> 1);
++ while (--n2 >= 0) {
++ *p16 = bswap_16(*p16);
++ p16++;
++ }
++ }
+ if ((size_t)n == ibs)
+ G.in_full++;
+ else {
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://
[OpenWrt-Devel] [PATCH] lantiq: do an endianness swap to the RT2860 eeprom for ARV752DPW(22)
ARV752DPW and ARV752DPW22 have the RT2860 eeprom stored in flash as big-endian, but the driver needs it in little-endian format. We have to swab it before handing it over. This requires my earlier patch for busybox. Funnily enough, ARV752DPW works also with the incorrect eeprom, but undoubtedly unoptimally. I have a hunch that also the two other Lantiq boards would require this swabbing, but I'm not sure, so I just swab it in the two boards that I have tested. Signed-off-by: Matti Laakso --- Index: trunk/target/linux/lantiq/base-files/etc/hotplug.d/firmware/10-rt2x00-eeprom === --- trunk/target/linux/lantiq/base-files/etc/hotplug.d/firmware/10-rt2x00-eeprom (revision 39319) +++ trunk/target/linux/lantiq/base-files/etc/hotplug.d/firmware/10-rt2x00-eeprom (working copy) @@ -10,6 +10,7 @@ local part=$1 local offset=$2 local count=$3 + local swab=$4 local mtd . /lib/functions.sh @@ -17,9 +18,13 @@ mtd=$(find_mtd_part $part) [ -n "$mtd" ] || \ rt2x00_eeprom_die "no mtd device found for partition $part" - - dd if=$mtd of=/lib/firmware/$FIRMWARE bs=1 skip=$offset count=$count || \ - rt2x00_eeprom_die "failed to extract from $mtd" + if [ $swab -gt 0 ]; then + dd if=$mtd of=/lib/firmware/$FIRMWARE bs=2 skip=$offset count=$count conv=swab || \ + rt2x00_eeprom_die "failed to extract from $mtd" + else + dd if=$mtd of=/lib/firmware/$FIRMWARE bs=1 skip=$offset count=$count || \ + rt2x00_eeprom_die "failed to extract from $mtd" + fi } [ -e /lib/firmware/$FIRMWARE ] && exit 0 @@ -29,9 +34,12 @@ "RT2860.eeprom" ) local board=$(lantiq_board_id) case $board in - ARV7510PW22|ARV7525PW|ARV752DPW|ARV752DPW22) - rt2x00_eeprom_extract "board_config" 1040 512 + ARV752DPW|ARV752DPW22) + rt2x00_eeprom_extract "board_config" 1040 256 1 ;; + ARV7510PW22|ARV7525PW) + rt2x00_eeprom_extract "board_config" 1040 512 0 + ;; *) rt2x00_eeprom_die "board $board is not supported yet" ;; ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] busybox: backport dd conv=swab from 1.22
Hello Matti,
I was the one who sent the patch for getting swab support in busybox.
Here you can find the patch that I sent:
https://dl.dropboxusercontent.com/u/4708147/busybox/bb_swab.patch
However, Denys Vlasenko committed a modified version of the patch because,
according to him, my version was too heavy and made busybox too big for small
systems:
http://git.busybox.net/busybox/commit/?id=b941316ae5313be523b64f0a9151ee4decb2b35b
As you can see his version doesn't support swapping odd files. That's why I
recommended him to warn the user in that situation:
http://git.busybox.net/busybox/commit/?id=5b9910f0a4a1b7976c46e6f849aaa263180e5521
I don't know if we should backport his version or mine, it depends on OpenWrt
developers.
Take in mind that my version is taken directly from the GNU version of dd
without considering any program sizes or optimizations.
BTW, the ARV7510PW22 needs the EEPROM swapping too.
Regards,
Álvaro.
El 21/01/2014 14:57, Matti Laakso escribió:
> Some boards have the WLAN EEPROM stored in flash in big-endian format,
> whereas the driver requires the EEPROM in little-endian format. The
> conv=swab option in dd is particularly useful in this case. This patch
> backports this feature from busybox-1.22.
>
> Signed-off-by: Matti Laakso
> ---
>
> Index: trunk/package/utils/busybox/patches/008-backport-dd-conv-swab.patch
> ===
> --- trunk/package/utils/busybox/patches/008-backport-dd-conv-swab.patch
> (revision 0)
> +++ trunk/package/utils/busybox/patches/008-backport-dd-conv-swab.patch
> (working copy)
> @@ -0,0 +1,97 @@
> +--- a/coreutils/dd.c
> b/coreutils/dd.c
> +@@ -10,7 +10,7 @@
> +
> + //usage:#define dd_trivial_usage
> + //usage: "[if=FILE] [of=FILE] " IF_FEATURE_DD_IBS_OBS("[ibs=N]
> [obs=N] ") "[bs=N] [count=N] [skip=N]\n"
> +-//usage: "[seek=N]" IF_FEATURE_DD_IBS_OBS("
> [conv=notrunc|noerror|sync|fsync]")
> ++//usage: "[seek=N]" IF_FEATURE_DD_IBS_OBS("
> [conv=notrunc|noerror|sync|fsync|swab]")
> + //usage:#define dd_full_usage "\n\n"
> + //usage: "Copy a file with converting and formatting\n"
> + //usage: "\nif=FILE Read from FILE instead of stdin"
> +@@ -30,6 +30,7 @@
> + //usage: "\nconv=noerrorContinue after read errors"
> + //usage: "\nconv=sync Pad blocks with zeros"
> + //usage: "\nconv=fsync Physically write data out before
> finishing"
> ++//usage: "\nconv=swab Swap every pair of bytes"
> + //usage:)
> + //usage: "\n"
> + //usage: "\nNumbers may be suffixed by c (x1), w (x2), b (x512), kD
> (x1000), k (x1024),"
> +@@ -155,9 +156,10 @@ int dd_main(int argc UNUSED_PARAM, char
> + FLAG_SYNC= 1 << 1,
> + FLAG_NOERROR = 1 << 2,
> + FLAG_FSYNC = 1 << 3,
> ++FLAG_SWAB= 1 << 4,
> + /* end of conv flags */
> +-FLAG_TWOBUFS = 1 << 4,
> +-FLAG_COUNT = 1 << 5,
> ++FLAG_TWOBUFS = 1 << 5,
> ++FLAG_COUNT = 1 << 6,
> + };
> + static const char keywords[] ALIGN1 =
> + "bs\0""count\0""seek\0""skip\0""if\0""of\0"
> +@@ -167,7 +169,7 @@ int dd_main(int argc UNUSED_PARAM, char
> + ;
> + #if ENABLE_FEATURE_DD_IBS_OBS
> + static const char conv_words[] ALIGN1 =
> +-"notrunc\0""sync\0""noerror\0""fsync\0";
> ++"notrunc\0""sync\0""noerror\0""fsync\0""swab\0";
> + #endif
> + enum {
> + OP_bs = 0,
> +@@ -185,11 +187,11 @@ int dd_main(int argc UNUSED_PARAM, char
> + OP_conv_sync,
> + OP_conv_noerror,
> + OP_conv_fsync,
> ++OP_conv_swab,
> + /* Unimplemented conv=XXX: */
> + //nocreat do not create the output file
> + //excl fail if the output file already exists
> + //fdatasync physically write output file data before finishing
> +-//swab swap every pair of input bytes
> + //lcase change upper case to lower case
> + //ucase change lower case to upper case
> + //block pad newline-terminated records with spaces to cbs-size
> +@@ -207,12 +209,14 @@ int dd_main(int argc UNUSED_PARAM, char
> + struct {
> + int flags;
> + size_t oc;
> ++ssize_t prev_read_size; /* for detecting swab failure */
> + off_t count;
> + off_t seek, skip;
> + const char *infile, *outfile;
> + } Z;
> + #define flags (Z.flags )
> + #define oc (Z.oc )
> ++#define prev_read_size (Z.prev_read_size)
> + #define count (Z.count )
> + #define seek(Z.seek )
> + #define skip(Z.skip )
> +@@ -375,6 +379,27 @@ int dd_main(int argc UNUSED_PARAM, char
> + * conv=noerror just ignores input bad blocks */
> + n = 0;
> + }
> ++if (flags & FLAG_SW
[OpenWrt-Devel] BT Home Hub 2B support - nand driver patch (for comment only)
Together with other contributors at the now defunct psidoc site, I
have produced a device tree and some patches to get the BT Home Hub 2B
(Lantiq Danube-S) working with recent trunk builds. More work is needed
before they are ready for submitting, but before going any further, I'd
be very grateful for some advice from John Crispin or anyone else who
wants to chip in.
The Home Hub 2B has both nand and nor flash connected to the ebu, plus
an ath9k pci wireless card, and the main difficulty is getting all three
working at the same time without interfering with each other. The nand
driver currently in trunk works fine, provided that open-drain is
enabled on the ebu cs1 pin, and provided that wireless is off. However,
the only way to get the nor chip to work reliably seems to be disable
open-drain on ebu cs1, at which point the nand driver generates jffs2
errors. Regardless whether open-drain is enabled or not, switching on
wireless also causes jffs2 errors.
The solution we are using (basically an updated version of a patch
produced by BTSimonh for the 3.3.8 kernel) is to disable open drain on
ebu cs1 and patch the nand driver as follows:
- move locking from the individual read and write functions to the
chip select function, so that an entire read or write operation can
complete uninterrupted;
- mask pci request lines during nand access;
- additional waiting after each nand command.
An option in the device tree enables or disables the above.
The latest version of my patch is appended to the message, for comment
only - I am not submitting it at this stage.
It solves the problem, and the factory firmware does something similar,
but it feels like a hack to work round a bug elsewhere. Could it not be
that that the ebu needs to be set up differently for this hardware
configuration? Is some chip select logic needed in the nor driver?
I'd love to understand what the settings in the ebu registers actually
do, but am I right in thinking that there are no publicly available
datasheets for Lantiq SOCs?
Any enlightenment you can provide will be gratefully received.
Thank you,
Ben Mulvihill
--- a/drivers/mtd/nand/xway_nand.c 2014-01-21 20:21:11.0 +0100
+++ b/drivers/mtd/nand/xway_nand.c 2014-01-21 20:29:16.0 +0100
@@ -54,8 +54,28 @@
#define NAND_CON_CSMUX (1 << 1)
#define NAND_CON_NANDM 1
+#define DANUBE_PCI_REG32( addr )(*(volatile u32 *)(addr))
+#define PCI_CR_PR_OFFSET (KSEG1+0x1E105400)
+#define PCI_CR_PC_ARB (PCI_CR_PR_OFFSET + 0x0080)
+
static u32 xway_latchcmd;
+/*
+ * req_mask provides a mechanism to prevent interference between
+ * nand and pci (probably only relevant for the BT Home Hub 2B).
+ * Setting it causes the corresponding pci req pins to be masked
+ * during nand access, and also moves ebu locking from the read/write
+ * functions to the chip select function to ensure that the whole
+ * operation runs with interrupts disabled.
+ * In addition it switches on some extra waiting in xway_cmd_ctrl().
+ * This seems to be necessary if the ebu_cs1 pin has open-drain disabled,
+ * which in turn seems to be necessary for the nor chip to be recognised
+ * reliably, on a board (Home Hub 2B again) which has both nor and nand.
+ */
+
+static __be32 req_mask = 0;
+static int pci_masked = 0;
+
static void xway_reset_chip(struct nand_chip *chip)
{
unsigned long nandaddr = (unsigned long) chip->IO_ADDR_W;
@@ -80,15 +100,36 @@
static void xway_select_chip(struct mtd_info *mtd, int chip)
{
+ static unsigned long flags;
switch (chip) {
case -1:
ltq_ebu_w32_mask(NAND_CON_CE, 0, EBU_NAND_CON);
ltq_ebu_w32_mask(NAND_CON_NANDM, 0, EBU_NAND_CON);
+
+ if (req_mask) {
+ BUG_ON(!pci_masked);
+ /* Unmask all external PCI request */
+ DANUBE_PCI_REG32(PCI_CR_PC_ARB) &= ~(req_mask << 16);
+ pci_masked = 0;
+
+ spin_unlock_irqrestore(&ebu_lock, flags);
+ }
+
break;
case 0:
+ if (req_mask) {
+ BUG_ON(pci_masked);
+ spin_lock_irqsave(&ebu_lock, flags);
+
+ /* Mask all external PCI request */
+ DANUBE_PCI_REG32(PCI_CR_PC_ARB) |= (req_mask << 16);
+ pci_masked = 1;
+ }
+
ltq_ebu_w32_mask(0, NAND_CON_NANDM, EBU_NAND_CON);
ltq_ebu_w32_mask(0, NAND_CON_CE, EBU_NAND_CON);
+
break;
default:
BUG();
@@ -101,6 +142,12 @@
unsigned long nandaddr = (unsigned long) this->IO_ADDR_W;
unsigned long flags;
+ if (req_mask) {
+ if (cmd != NAND_CMD_STATUS)
+ ltq_ebu_w32(EBU_NAND_WAIT, 0); /* Clear nand ready */
+ }
+
+
if (ctrl & NAND_CTRL_CHANGE) {
[OpenWrt-Devel] [PATCH] packages: libdaemon: prevent an erroneous error message
Signed-off-by: Michael Heimpold
---
I sent this patch already upstream to Lennart Poettering, however,
he didn't respond yet.
libs/libdaemon/Makefile|4 +--
.../patches/001-daemon_set_verbosity.patch | 30
2 files changed, 32 insertions(+), 2 deletions(-)
create mode 100644 libs/libdaemon/patches/001-daemon_set_verbosity.patch
diff --git a/libs/libdaemon/Makefile b/libs/libdaemon/Makefile
index 68e3e36..6a828cb 100644
--- a/libs/libdaemon/Makefile
+++ b/libs/libdaemon/Makefile
@@ -1,5 +1,5 @@
#
-# Copyright (C) 2006 OpenWrt.org
+# Copyright (C) 2006-2014 OpenWrt.org
#
# This is free software, licensed under the GNU General Public License v2.
# See /LICENSE for more information.
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
PKG_NAME:=libdaemon
PKG_VERSION:=0.14
-PKG_RELEASE:=2
+PKG_RELEASE:=3
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
PKG_SOURCE_URL:=http://0pointer.de/lennart/projects/libdaemon/
diff --git a/libs/libdaemon/patches/001-daemon_set_verbosity.patch
b/libs/libdaemon/patches/001-daemon_set_verbosity.patch
new file mode 100644
index 000..d0c66c7
--- /dev/null
+++ b/libs/libdaemon/patches/001-daemon_set_verbosity.patch
@@ -0,0 +1,30 @@
+From 013963ba35e8fe8897211c0acf5ee98f9a871fc1 Mon Sep 17 00:00:00 2001
+From: Michael Heimpold
+Date: Fri, 10 Jan 2014 19:38:51 +0100
+Subject: [PATCH] daemon_set_verbosity: fix erroneous error message
+
+When calling this function with a value other than LOG_DEBUG
+the error message was triggered erroneously.
+
+Signed-off-by: Michael Heimpold
+---
+
+ libdaemon/dlog.c |2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/libdaemon/dlog.c b/libdaemon/dlog.c
+index 1cc0566..cc2b918 100644
+--- a/libdaemon/dlog.c
b/libdaemon/dlog.c
+@@ -42,7 +42,7 @@ static int daemon_verbosity_level = LOG_INFO;
+ void daemon_set_verbosity(int verbosity_prio) {
+
+ /* Allow using negative verbosity levels to hide _all_ messages */
+-if (verbosity_prio > 0 && (verbosity_prio & LOG_PRIMASK) != LOG_PRIMASK)
++if (verbosity_prio > 0 && (verbosity_prio & LOG_PRIMASK) !=
verbosity_prio)
+ daemon_log(LOG_ERR, "The value %d is not a valid priority value",
verbosity_prio);
+
+ daemon_verbosity_level = verbosity_prio & LOG_PRIMASK;
+--
+1.7.10.4
+
--
1.7.10.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] is anybody working on supporting Linksys WRT1900ac ?
> "JC" == John Crispin writes: JC> * unit most likely runs on a ghz arm soc made by marvell IIRC, semiaccurate reported that it uses an atom processor. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] is anybody working on supporting Linksys WRT1900ac ?
On 21/01/2014 21:35, James Cloos wrote: >> "JC" == John Crispin writes: > JC> * unit most likely runs on a ghz arm soc made by marvell > > IIRC, semiaccurate reported that it uses an atom processor. > > -JimC > -- > James Cloos OpenPGP: 1024D/ED7DAEA6 i beg to differ, please get your facts right :) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] BT Home Hub 2B support - nand driver patch (for comment only)
Hi Ben,
oh dear, how i hate the ebu ...
i will start by testing this patch on the fritz3370 where i have been
seeing jffs2 errors.
in general i am all for merging this, i will need a few days to think
about this.
John
On 21/01/2014 20:50, Ben Mulvihill wrote:
> Together with other contributors at the now defunct psidoc site, I
> have produced a device tree and some patches to get the BT Home Hub 2B
> (Lantiq Danube-S) working with recent trunk builds. More work is needed
> before they are ready for submitting, but before going any further, I'd
> be very grateful for some advice from John Crispin or anyone else who
> wants to chip in.
>
> The Home Hub 2B has both nand and nor flash connected to the ebu, plus
> an ath9k pci wireless card, and the main difficulty is getting all three
> working at the same time without interfering with each other. The nand
> driver currently in trunk works fine, provided that open-drain is
> enabled on the ebu cs1 pin, and provided that wireless is off. However,
> the only way to get the nor chip to work reliably seems to be disable
> open-drain on ebu cs1, at which point the nand driver generates jffs2
> errors. Regardless whether open-drain is enabled or not, switching on
> wireless also causes jffs2 errors.
>
> The solution we are using (basically an updated version of a patch
> produced by BTSimonh for the 3.3.8 kernel) is to disable open drain on
> ebu cs1 and patch the nand driver as follows:
> - move locking from the individual read and write functions to the
>chip select function, so that an entire read or write operation can
>complete uninterrupted;
> - mask pci request lines during nand access;
> - additional waiting after each nand command.
> An option in the device tree enables or disables the above.
> The latest version of my patch is appended to the message, for comment
> only - I am not submitting it at this stage.
>
> It solves the problem, and the factory firmware does something similar,
> but it feels like a hack to work round a bug elsewhere. Could it not be
> that that the ebu needs to be set up differently for this hardware
> configuration? Is some chip select logic needed in the nor driver?
> I'd love to understand what the settings in the ebu registers actually
> do, but am I right in thinking that there are no publicly available
> datasheets for Lantiq SOCs?
>
> Any enlightenment you can provide will be gratefully received.
>
> Thank you,
>
> Ben Mulvihill
>
> --- a/drivers/mtd/nand/xway_nand.c2014-01-21 20:21:11.0 +0100
> +++ b/drivers/mtd/nand/xway_nand.c2014-01-21 20:29:16.0 +0100
> @@ -54,8 +54,28 @@
> #define NAND_CON_CSMUX (1 << 1)
> #define NAND_CON_NANDM 1
>
> +#define DANUBE_PCI_REG32( addr )(*(volatile u32 *)(addr))
> +#define PCI_CR_PR_OFFSET (KSEG1+0x1E105400)
> +#define PCI_CR_PC_ARB(PCI_CR_PR_OFFSET + 0x0080)
> +
> static u32 xway_latchcmd;
>
> +/*
> + * req_mask provides a mechanism to prevent interference between
> + * nand and pci (probably only relevant for the BT Home Hub 2B).
> + * Setting it causes the corresponding pci req pins to be masked
> + * during nand access, and also moves ebu locking from the read/write
> + * functions to the chip select function to ensure that the whole
> + * operation runs with interrupts disabled.
> + * In addition it switches on some extra waiting in xway_cmd_ctrl().
> + * This seems to be necessary if the ebu_cs1 pin has open-drain disabled,
> + * which in turn seems to be necessary for the nor chip to be recognised
> + * reliably, on a board (Home Hub 2B again) which has both nor and nand.
> + */
> +
> +static __be32 req_mask = 0;
> +static int pci_masked = 0;
> +
> static void xway_reset_chip(struct nand_chip *chip)
> {
> unsigned long nandaddr = (unsigned long) chip->IO_ADDR_W;
> @@ -80,15 +100,36 @@
>
> static void xway_select_chip(struct mtd_info *mtd, int chip)
> {
> + static unsigned long flags;
>
> switch (chip) {
> case -1:
> ltq_ebu_w32_mask(NAND_CON_CE, 0, EBU_NAND_CON);
> ltq_ebu_w32_mask(NAND_CON_NANDM, 0, EBU_NAND_CON);
> +
> + if (req_mask) {
> + BUG_ON(!pci_masked);
> + /* Unmask all external PCI request */
> + DANUBE_PCI_REG32(PCI_CR_PC_ARB) &= ~(req_mask << 16);
> + pci_masked = 0;
> +
> + spin_unlock_irqrestore(&ebu_lock, flags);
> + }
> +
> break;
> case 0:
> + if (req_mask) {
> + BUG_ON(pci_masked);
> + spin_lock_irqsave(&ebu_lock, flags);
> +
> + /* Mask all external PCI request */
> + DANUBE_PCI_REG32(PCI_CR_PC_ARB) |= (req_mask << 16);
> + pci_masked = 1;
> + }
> +
> ltq_ebu_w32_mask(0, NAND_CON_NANDM, EBU_NAND_CON);
>
Re: [OpenWrt-Devel] BT Home Hub 2B support - nand driver patch (for comment only)
On Tue, 21 Jan 2014, Ben Mulvihill wrote: The nand driver currently in trunk works fine, provided ... what is the current status of nand flash support? I asked about this within the last couple of weeks and was told that supporing devices with nand flash would require major surgery to the squashfs code to allow it to deal with badblocks. has this been done? was I misinformed on what the problem is? or is this still a problem and devices with nand flash can work, but only if they avoid squashfs? David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] is anybody working on supporting Linksys WRT1900ac ?
Hi John, On Jan 21, 2014, at 21:41 , John Crispin wrote: > > On 21/01/2014 21:35, James Cloos wrote: >>> "JC" == John Crispin writes: >> JC> * unit most likely runs on a ghz arm soc made by marvell >> >> IIRC, semiaccurate reported that it uses an atom processor. That truly was reported on semiaccurate.com as an atom part: http://semiaccurate.com/2014/01/06/linksys-wrt1900ac-spritual-successor-wrt54g/ (but later updated with a correction) >> >> -JimC >> -- >> James Cloos OpenPGP: 1024D/ED7DAEA6 > i beg to differ, please get your facts right :) Well, his facts were that semi accurate reported it as an atom, and they did. :) ahoy SM > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] is anybody working on supporting Linksys WRT1900ac ?
On Thu, Jan 16, 2014 at 4:32 AM, Aaron Z wrote: > Perhaps marketing is watching this thread? It now reads: > "Open Source is a vehicle for other communities, such as DD-WRT, Open WRT, > and Tomato, to create their own custom versions of open source firmware for > the product. OpenWRT developers will be provided hardware and SDKs/APIs to > begin creating custom firmware for the WRT1900AC." Optimistic read of this suggests that they will release some kind of patches to adopt in various projects? > "An OpenWRT custom firmware for WRT1900AC is planned to be available for > download online at availability in the spring 2014." So OpenWRT will be the custom firmware? Will they then ship something of their own? Based on what? OpenWRT? Best regards, Maciej ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] is anybody working on supporting Linksys WRT1900ac ?
> "SM" == Sebastian Moeller writes: SM> That truly was reported on semiaccurate.com as an atom part: SM> http://semiaccurate.com/2014/01/06/linksys-wrt1900ac-spritual-successor-wrt54g/ Thanks for finding that! SM> (but later updated with a correction) -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] busybox: backport dd conv=swab from 1.22
2014/1/21 Matti Laakso : > Some boards have the WLAN EEPROM stored in flash in big-endian format, > whereas the driver requires the EEPROM in little-endian format. The > conv=swab option in dd is particularly useful in this case. This patch > backports this feature from busybox-1.22. Since this is a backport, can you also keep the original commit log message? This might help tracking this specific commit if/when we updated to a newer busybox version. Thanks! -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] is anybody working on supporting Linksys WRT1900ac ?
2014/1/21 James Cloos : >> "SM" == Sebastian Moeller writes: > > SM> That truly was reported on semiaccurate.com as an atom part: > SM> > http://semiaccurate.com/2014/01/06/linksys-wrt1900ac-spritual-successor-wrt54g/ > > Thanks for finding that! > > SM> (but later updated with a correction) Knowing Linksys/Belkin, rev 1 could be one vendor, rev 2 could be another one, and then they will realize that they can save some money by reducing the flash size and use VxWorks instead of Linux (wait, this happened before). -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] BT Home Hub 2B support - nand driver patch (for comment only)
Hi John,
Thank you. I had assumed this would probably only be of any use
on the HH2B. If you are going to try it (or bits of it) out on
the fritz3370, I should perhaps add that BTSimonh's patch for
the 3.3.8 kernel (I take it he didn't ever submit it here?)
also reset the chip in the chip select function (at the
end of case 0) and masked out NANDM at the end of the probe
function. I removed those changes because they didn't seem to
make any difference.
But could the errors on the fritz3370 simply be due to wrong
pinmux settings?
Ben
On Tue, 2014-01-21 at 21:43 +0100, John Crispin wrote:
> Hi Ben,
>
> oh dear, how i hate the ebu ...
>
> i will start by testing this patch on the fritz3370 where i have been
> seeing jffs2 errors.
>
> in general i am all for merging this, i will need a few days to think
> about this.
>
> John
>
> On 21/01/2014 20:50, Ben Mulvihill wrote:
> > Together with other contributors at the now defunct psidoc site, I
> > have produced a device tree and some patches to get the BT Home Hub 2B
> > (Lantiq Danube-S) working with recent trunk builds. More work is needed
> > before they are ready for submitting, but before going any further, I'd
> > be very grateful for some advice from John Crispin or anyone else who
> > wants to chip in.
> >
> > The Home Hub 2B has both nand and nor flash connected to the ebu, plus
> > an ath9k pci wireless card, and the main difficulty is getting all three
> > working at the same time without interfering with each other. The nand
> > driver currently in trunk works fine, provided that open-drain is
> > enabled on the ebu cs1 pin, and provided that wireless is off. However,
> > the only way to get the nor chip to work reliably seems to be disable
> > open-drain on ebu cs1, at which point the nand driver generates jffs2
> > errors. Regardless whether open-drain is enabled or not, switching on
> > wireless also causes jffs2 errors.
> >
> > The solution we are using (basically an updated version of a patch
> > produced by BTSimonh for the 3.3.8 kernel) is to disable open drain on
> > ebu cs1 and patch the nand driver as follows:
> > - move locking from the individual read and write functions to the
> >chip select function, so that an entire read or write operation can
> >complete uninterrupted;
> > - mask pci request lines during nand access;
> > - additional waiting after each nand command.
> > An option in the device tree enables or disables the above.
> > The latest version of my patch is appended to the message, for comment
> > only - I am not submitting it at this stage.
> >
> > It solves the problem, and the factory firmware does something similar,
> > but it feels like a hack to work round a bug elsewhere. Could it not be
> > that that the ebu needs to be set up differently for this hardware
> > configuration? Is some chip select logic needed in the nor driver?
> > I'd love to understand what the settings in the ebu registers actually
> > do, but am I right in thinking that there are no publicly available
> > datasheets for Lantiq SOCs?
> >
> > Any enlightenment you can provide will be gratefully received.
> >
> > Thank you,
> >
> > Ben Mulvihill
> >
> > --- a/drivers/mtd/nand/xway_nand.c 2014-01-21 20:21:11.0 +0100
> > +++ b/drivers/mtd/nand/xway_nand.c 2014-01-21 20:29:16.0 +0100
> > @@ -54,8 +54,28 @@
> > #define NAND_CON_CSMUX (1 << 1)
> > #define NAND_CON_NANDM 1
> >
> > +#define DANUBE_PCI_REG32( addr )(*(volatile u32 *)(addr))
> > +#define PCI_CR_PR_OFFSET (KSEG1+0x1E105400)
> > +#define PCI_CR_PC_ARB (PCI_CR_PR_OFFSET + 0x0080)
> > +
> > static u32 xway_latchcmd;
> >
> > +/*
> > + * req_mask provides a mechanism to prevent interference between
> > + * nand and pci (probably only relevant for the BT Home Hub 2B).
> > + * Setting it causes the corresponding pci req pins to be masked
> > + * during nand access, and also moves ebu locking from the read/write
> > + * functions to the chip select function to ensure that the whole
> > + * operation runs with interrupts disabled.
> > + * In addition it switches on some extra waiting in xway_cmd_ctrl().
> > + * This seems to be necessary if the ebu_cs1 pin has open-drain disabled,
> > + * which in turn seems to be necessary for the nor chip to be recognised
> > + * reliably, on a board (Home Hub 2B again) which has both nor and nand.
> > + */
> > +
> > +static __be32 req_mask = 0;
> > +static int pci_masked = 0;
> > +
> > static void xway_reset_chip(struct nand_chip *chip)
> > {
> > unsigned long nandaddr = (unsigned long) chip->IO_ADDR_W;
> > @@ -80,15 +100,36 @@
> >
> > static void xway_select_chip(struct mtd_info *mtd, int chip)
> > {
> > + static unsigned long flags;
> >
> > switch (chip) {
> > case -1:
> > ltq_ebu_w32_mask(NAND_CON_CE, 0, EBU_NAND_CON);
> > ltq_ebu_w32_mask(NAND_CON_NANDM, 0, EBU_NAND_CON);
> > +
> > + if (req_mask)
Re: [OpenWrt-Devel] BT Home Hub 2B support - nand driver patch (for comment only)
I should perhaps have said "provided there are no bad blocks on the part of the nand occupied by the squashfs", and "provided that ubox mount_root is patched so that it distinguishes between jffs2 on nor and jffs2 on nand". But I suspect I shouldn't really be using a squashfs image on nand at all. I'd also be interested to know if anything is planned along the lines of what David mentioned. Ben Mulvihill On Tue, 2014-01-21 at 12:55 -0800, David Lang wrote: > On Tue, 21 Jan 2014, Ben Mulvihill wrote: > > > The nand driver currently in trunk works fine, provided ... > > what is the current status of nand flash support? I asked about this within > the > last couple of weeks and was told that supporing devices with nand flash > would > require major surgery to the squashfs code to allow it to deal with badblocks. > > has this been done? was I misinformed on what the problem is? or is this > still a > problem and devices with nand flash can work, but only if they avoid squashfs? > > David Lang > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] Zabbix: update to 2.2.1
With this new version of zabbix we do not need
uname and hostname anymore, see
https://svn.zabbix.com/browse/ZBX-5616
Only compile tested for now
Signed-off-by: Etienne CHAMPETIER
---
admin/zabbix/Makefile | 10 ++
admin/zabbix/patches/001-cross_compile.patch | 6 +++---
admin/zabbix/patches/002-fix-res_send-on-uclibc.patch | 14 +++---
admin/zabbix/patches/002-uclibc_loadavg.patch | 8
admin/zabbix/patches/010-change-agentd-config.patch | 8
5 files changed, 20 insertions(+), 26 deletions(-)
diff --git a/admin/zabbix/Makefile b/admin/zabbix/Makefile
index 5ee8425..9088447 100644
--- a/admin/zabbix/Makefile
+++ b/admin/zabbix/Makefile
@@ -8,12 +8,12 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=zabbix
-PKG_VERSION:=2.0.8
+PKG_VERSION:=2.2.1
PKG_RELEASE:=1
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
PKG_SOURCE_URL:=@SF/zabbix
-PKG_MD5SUM:=8fef9e6f499295211dd9b2a9db96464b
+PKG_MD5SUM:=558497839b13a548f533eb2fc951a4e3
PKG_INSTALL:=1
@@ -99,12 +99,6 @@ As it uses libiwinfo, it works with all wifi devices
supported by openwrt.
See http://wiki.openwrt.org/doc/howto/zabbix for ready to use zabbix templates.
endef
-
-define Package/zabbix-agentd/config
- select BUSYBOX_CONFIG_HOSTNAME if !PACKAGE_net-tools-hostname
- select BUSYBOX_CONFIG_UNAME if !PACKAGE_coreutils-uname
-endef
-
CONFIGURE_ARGS+= \
--enable-agent \
--enable-server \
diff --git a/admin/zabbix/patches/001-cross_compile.patch
b/admin/zabbix/patches/001-cross_compile.patch
index 8716e84..cf8b6d8 100644
--- a/admin/zabbix/patches/001-cross_compile.patch
+++ b/admin/zabbix/patches/001-cross_compile.patch
@@ -1,6 +1,6 @@
a/configure.in 2012-06-21 21:32:23.707912790 +
-+++ b/configure.in 2012-06-21 21:33:36.213554564 +
-@@ -802,25 +802,8 @@
+--- a/configure.in
b/configure.in
+@@ -804,25 +804,8 @@ dnl
dnl Check for %qu format (FreeBSD 4.x)
dnl FreeBSD 4.x does not support %llu
diff --git a/admin/zabbix/patches/002-fix-res_send-on-uclibc.patch
b/admin/zabbix/patches/002-fix-res_send-on-uclibc.patch
index 3190659..7072f03 100644
--- a/admin/zabbix/patches/002-fix-res_send-on-uclibc.patch
+++ b/admin/zabbix/patches/002-fix-res_send-on-uclibc.patch
@@ -1,6 +1,6 @@
a/configure.in 2013-02-14 18:29:28.145419003 +0100
-+++ b/configure.in 2013-02-14 18:28:42.873418092 +0100
-@@ -149,6 +149,10 @@
+--- a/configure.in
b/configure.in
+@@ -151,6 +151,10 @@ if test "x$found_resolv" != "xyes"; then
AC_MSG_ERROR([Unable to do DNS lookups (libresolv check failed)])
fi
LIBS="${LIBS} ${RESOLV_LIBS}"
@@ -11,9 +11,9 @@
dnl *
dnl * *
a/src/libs/zbxsysinfo/common/net.c 2012-06-21 19:49:46.610567432 +
-+++ b/src/libs/zbxsysinfo/common/net.c 2012-06-21 19:50:35.816628541 +
-@@ -418,6 +418,7 @@
+--- a/src/libs/zbxsysinfo/common/net.c
b/src/libs/zbxsysinfo/common/net.c
+@@ -421,6 +421,7 @@ static int dns_query(AGENT_REQUEST *requ
#else /* not _WINDOWS */
res_init(); /* initialize always, settings might have changed */
@@ -21,7 +21,7 @@
if (-1 == (res = res_mkquery(QUERY, zone, C_IN, type, NULL, 0, NULL,
buf, sizeof(buf
return SYSINFO_RET_FAIL;
-@@ -436,6 +437,11 @@
+@@ -439,6 +440,11 @@ static intdns_query(AGENT_REQUEST *requ
_res.retry = retry;
res = res_send(buf, res, answer.buffer, sizeof(answer.buffer));
diff --git a/admin/zabbix/patches/002-uclibc_loadavg.patch
b/admin/zabbix/patches/002-uclibc_loadavg.patch
index 6effabb..4bf3f77 100644
--- a/admin/zabbix/patches/002-uclibc_loadavg.patch
+++ b/admin/zabbix/patches/002-uclibc_loadavg.patch
@@ -1,5 +1,5 @@
a/src/libs/zbxsysinfo/linux/cpu.c 2013-02-12 12:27:22.0 +0100
-+++ b/src/libs/zbxsysinfo/linux/cpu.c 2013-02-14 18:38:02.517429349 +0100
+--- a/src/libs/zbxsysinfo/linux/cpu.c
b/src/libs/zbxsysinfo/linux/cpu.c
@@ -21,6 +21,45 @@
#include "sysinfo.h"
#include "stats.h"
@@ -43,6 +43,6 @@
+}
+#endif
+
- int SYSTEM_CPU_NUM(const char *cmd, const char *param, unsigned flags,
AGENT_RESULT *result)
+ int SYSTEM_CPU_NUM(AGENT_REQUEST *request, AGENT_RESULT *result)
{
- chartmp[16];
+ char*type;
diff --git a/admin/zabbix/patches/010-change-agentd-config.patch
b/admin/zabbix/patches/010-change-agentd-config.patch
index 58424e9..cf5083e 100644
--- a/admin/zabbix/patches/010-change-agentd-config.patch
+++ b/admin/zabbix/patches/010-change-agentd-config.patch
@@ -24,7 +24,7 @@
### Option: LogFileSize
# Maximum size of log file in MB.
# 0 - disable automatic log rotation.
-@@ -105,6 +99,7 @@ Server=127.0.0.1
+@@ -104,6 +98,7 @@ Server=127.0.0.1
# Range: 0-100
# Default:
# StartAgents=3
@@ -32,7 +32,7 @@
# Acti
Re: [OpenWrt-Devel] BT Home Hub 2B support - nand driver patch (for comment only)
On 21/01/2014 21:55, David Lang wrote: > On Tue, 21 Jan 2014, Ben Mulvihill wrote: > >> The nand driver currently in trunk works fine, provided ... > > what is the current status of nand flash support? I asked about this > within the last couple of weeks and was told that supporing devices > with nand flash would require major surgery to the squashfs code to > allow it to deal with badblocks. > > has this been done? was I misinformed on what the problem is? or is > this still a problem and devices with nand flash can work, but only if > they avoid squashfs? > Hi David, Daniel is working on splitting the mount_root, block, extroot and all the other mtd/block related tools to a new repo called fstools. While doing so we are doing some cleanup of the code. i expect this to hit trunk within the next week. Once this is done we will add nand specific features to the repo. Once that is done, openwrt should have proper support for ubi including functional sysupgrade support (using ubi-format) ... John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] BT Home Hub 2B support - nand driver patch (for comment only)
Hi,
i am pretty sure the pinmux is set correctly on the board, however i
will reverify it.
do you have a link to btsimonh's 3.3.8 patch ?
John
On 21/01/2014 23:52, Ben Mulvihill wrote:
> Hi John,
>
> Thank you. I had assumed this would probably only be of any use
> on the HH2B. If you are going to try it (or bits of it) out on
> the fritz3370, I should perhaps add that BTSimonh's patch for
> the 3.3.8 kernel (I take it he didn't ever submit it here?)
> also reset the chip in the chip select function (at the
> end of case 0) and masked out NANDM at the end of the probe
> function. I removed those changes because they didn't seem to
> make any difference.
> But could the errors on the fritz3370 simply be due to wrong
> pinmux settings?
>
> Ben
>
>
>
>
>
> On Tue, 2014-01-21 at 21:43 +0100, John Crispin wrote:
>> Hi Ben,
>>
>> oh dear, how i hate the ebu ...
>>
>> i will start by testing this patch on the fritz3370 where i have been
>> seeing jffs2 errors.
>>
>> in general i am all for merging this, i will need a few days to think
>> about this.
>>
>> John
>>
>> On 21/01/2014 20:50, Ben Mulvihill wrote:
>>> Together with other contributors at the now defunct psidoc site, I
>>> have produced a device tree and some patches to get the BT Home Hub 2B
>>> (Lantiq Danube-S) working with recent trunk builds. More work is needed
>>> before they are ready for submitting, but before going any further, I'd
>>> be very grateful for some advice from John Crispin or anyone else who
>>> wants to chip in.
>>>
>>> The Home Hub 2B has both nand and nor flash connected to the ebu, plus
>>> an ath9k pci wireless card, and the main difficulty is getting all three
>>> working at the same time without interfering with each other. The nand
>>> driver currently in trunk works fine, provided that open-drain is
>>> enabled on the ebu cs1 pin, and provided that wireless is off. However,
>>> the only way to get the nor chip to work reliably seems to be disable
>>> open-drain on ebu cs1, at which point the nand driver generates jffs2
>>> errors. Regardless whether open-drain is enabled or not, switching on
>>> wireless also causes jffs2 errors.
>>>
>>> The solution we are using (basically an updated version of a patch
>>> produced by BTSimonh for the 3.3.8 kernel) is to disable open drain on
>>> ebu cs1 and patch the nand driver as follows:
>>> - move locking from the individual read and write functions to the
>>>chip select function, so that an entire read or write operation can
>>>complete uninterrupted;
>>> - mask pci request lines during nand access;
>>> - additional waiting after each nand command.
>>> An option in the device tree enables or disables the above.
>>> The latest version of my patch is appended to the message, for comment
>>> only - I am not submitting it at this stage.
>>>
>>> It solves the problem, and the factory firmware does something similar,
>>> but it feels like a hack to work round a bug elsewhere. Could it not be
>>> that that the ebu needs to be set up differently for this hardware
>>> configuration? Is some chip select logic needed in the nor driver?
>>> I'd love to understand what the settings in the ebu registers actually
>>> do, but am I right in thinking that there are no publicly available
>>> datasheets for Lantiq SOCs?
>>>
>>> Any enlightenment you can provide will be gratefully received.
>>>
>>> Thank you,
>>>
>>> Ben Mulvihill
>>>
>>> --- a/drivers/mtd/nand/xway_nand.c 2014-01-21 20:21:11.0 +0100
>>> +++ b/drivers/mtd/nand/xway_nand.c 2014-01-21 20:29:16.0 +0100
>>> @@ -54,8 +54,28 @@
>>> #define NAND_CON_CSMUX (1 << 1)
>>> #define NAND_CON_NANDM 1
>>>
>>> +#define DANUBE_PCI_REG32( addr )(*(volatile u32 *)(addr))
>>> +#define PCI_CR_PR_OFFSET (KSEG1+0x1E105400)
>>> +#define PCI_CR_PC_ARB (PCI_CR_PR_OFFSET + 0x0080)
>>> +
>>> static u32 xway_latchcmd;
>>>
>>> +/*
>>> + * req_mask provides a mechanism to prevent interference between
>>> + * nand and pci (probably only relevant for the BT Home Hub 2B).
>>> + * Setting it causes the corresponding pci req pins to be masked
>>> + * during nand access, and also moves ebu locking from the read/write
>>> + * functions to the chip select function to ensure that the whole
>>> + * operation runs with interrupts disabled.
>>> + * In addition it switches on some extra waiting in xway_cmd_ctrl().
>>> + * This seems to be necessary if the ebu_cs1 pin has open-drain disabled,
>>> + * which in turn seems to be necessary for the nor chip to be recognised
>>> + * reliably, on a board (Home Hub 2B again) which has both nor and nand.
>>> + */
>>> +
>>> +static __be32 req_mask = 0;
>>> +static int pci_masked = 0;
>>> +
>>> static void xway_reset_chip(struct nand_chip *chip)
>>> {
>>> unsigned long nandaddr = (unsigned long) chip->IO_ADDR_W;
>>> @@ -80,15 +100,36 @@
>>>
>>> static void xway_select_chip(struct mtd_info *mtd, int chip)
>>> {
>>> + static
Re: [OpenWrt-Devel] BT Home Hub 2B support - nand driver patch (for comment only)
On Tue, Jan 21, 2014 at 08:50:03PM +0100, Ben Mulvihill wrote:
> Any enlightenment you can provide will be gratefully received.
I have not tested this patch yet but it could be related to your
problem...
Luka
>From ad77bb90cbebcd107e81722e1fbdcff91fe55614 Mon Sep 17 00:00:00 2001
From: Antonios Vamporakis
Date: Sun, 29 Dec 2013 23:40:15 +0100
Subject: [PATCH 03/14] lantiq: resolve EBU conflict between NAND and PCI
Stop PCI IRQs from taking over the EBU wile NAND is accessed.
Signed-off-by: Antonios Vamporakis
---
.../0203-xway-fix-nand-pci-conflict.patch | 19 +++
1 file changed, 19 insertions(+)
create mode 100644
target/linux/lantiq/patches-3.10/0203-xway-fix-nand-pci-conflict.patch
diff --git
a/target/linux/lantiq/patches-3.10/0203-xway-fix-nand-pci-conflict.patch
b/target/linux/lantiq/patches-3.10/0203-xway-fix-nand-pci-conflict.patch
new file mode 100644
index 000..f4b5793
--- /dev/null
+++ b/target/linux/lantiq/patches-3.10/0203-xway-fix-nand-pci-conflict.patch
@@ -0,0 +1,19 @@
+--- a/drivers/mtd/nand/xway_nand.c
b/drivers/mtd/nand/xway_nand.c
+@@ -80,13 +80,16 @@ static void xway_reset_chip(struct nand_
+
+ static void xway_select_chip(struct mtd_info *mtd, int chip)
+ {
++ static unsigned long csflags;
+
+ switch (chip) {
+ case -1:
+ ltq_ebu_w32_mask(NAND_CON_CE, 0, EBU_NAND_CON);
+ ltq_ebu_w32_mask(NAND_CON_NANDM, 0, EBU_NAND_CON);
++ spin_unlock_irqrestore(&ebu_lock, csflags);
+ break;
+ case 0:
++ spin_lock_irqsave(&ebu_lock, csflags);
+ ltq_ebu_w32_mask(0, NAND_CON_NANDM, EBU_NAND_CON);
+ ltq_ebu_w32_mask(0, NAND_CON_CE, EBU_NAND_CON);
+ break;
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] BT Home Hub 2B support - nand driver patch (for comment only)
It was originally posted at http://sourceforge.net/projects/hh2b4ever/files/ The file is 904-MIPS-lantiq-nand.patch in http://sourceforge.net/projects/hh2b4ever/files/Patches-20120414.zip There is also a compilation of bits and pieces from the original factory firmware, including the nand driver, in http://sourceforge.net/projects/hh2b4ever/files/Original%20Open% 20Source/ Ben On Wed, 2014-01-22 at 00:43 +0100, John Crispin wrote: > Hi, > > i am pretty sure the pinmux is set correctly on the board, however i > will reverify it. > > do you have a link to btsimonh's 3.3.8 patch ? > > John > > > On 21/01/2014 23:52, Ben Mulvihill wrote: > > Hi John, > > > > Thank you. I had assumed this would probably only be of any use > > on the HH2B. If you are going to try it (or bits of it) out on > > the fritz3370, I should perhaps add that BTSimonh's patch for > > the 3.3.8 kernel (I take it he didn't ever submit it here?) > > also reset the chip in the chip select function (at the > > end of case 0) and masked out NANDM at the end of the probe > > function. I removed those changes because they didn't seem to > > make any difference. > > But could the errors on the fritz3370 simply be due to wrong > > pinmux settings? > > > > Ben > > > > > > > > > > > > On Tue, 2014-01-21 at 21:43 +0100, John Crispin wrote: > >> Hi Ben, > >> > >> oh dear, how i hate the ebu ... > >> > >> i will start by testing this patch on the fritz3370 where i have been > >> seeing jffs2 errors. > >> > >> in general i am all for merging this, i will need a few days to think > >> about this. > >> > >> John > >> > >> On 21/01/2014 20:50, Ben Mulvihill wrote: > >>> Together with other contributors at the now defunct psidoc site, I > >>> have produced a device tree and some patches to get the BT Home Hub 2B > >>> (Lantiq Danube-S) working with recent trunk builds. More work is needed > >>> before they are ready for submitting, but before going any further, I'd > >>> be very grateful for some advice from John Crispin or anyone else who > >>> wants to chip in. > >>> > >>> The Home Hub 2B has both nand and nor flash connected to the ebu, plus > >>> an ath9k pci wireless card, and the main difficulty is getting all three > >>> working at the same time without interfering with each other. The nand > >>> driver currently in trunk works fine, provided that open-drain is > >>> enabled on the ebu cs1 pin, and provided that wireless is off. However, > >>> the only way to get the nor chip to work reliably seems to be disable > >>> open-drain on ebu cs1, at which point the nand driver generates jffs2 > >>> errors. Regardless whether open-drain is enabled or not, switching on > >>> wireless also causes jffs2 errors. > >>> > >>> The solution we are using (basically an updated version of a patch > >>> produced by BTSimonh for the 3.3.8 kernel) is to disable open drain on > >>> ebu cs1 and patch the nand driver as follows: > >>> - move locking from the individual read and write functions to the > >>>chip select function, so that an entire read or write operation can > >>>complete uninterrupted; > >>> - mask pci request lines during nand access; > >>> - additional waiting after each nand command. > >>> An option in the device tree enables or disables the above. > >>> The latest version of my patch is appended to the message, for comment > >>> only - I am not submitting it at this stage. > >>> > >>> It solves the problem, and the factory firmware does something similar, > >>> but it feels like a hack to work round a bug elsewhere. Could it not be > >>> that that the ebu needs to be set up differently for this hardware > >>> configuration? Is some chip select logic needed in the nor driver? > >>> I'd love to understand what the settings in the ebu registers actually > >>> do, but am I right in thinking that there are no publicly available > >>> datasheets for Lantiq SOCs? > >>> > >>> Any enlightenment you can provide will be gratefully received. > >>> > >>> Thank you, > >>> > >>> Ben Mulvihill > >>> > >>> --- a/drivers/mtd/nand/xway_nand.c2014-01-21 20:21:11.0 > >>> +0100 > >>> +++ b/drivers/mtd/nand/xway_nand.c2014-01-21 20:29:16.0 > >>> +0100 > >>> @@ -54,8 +54,28 @@ > >>> #define NAND_CON_CSMUX (1 << 1) > >>> #define NAND_CON_NANDM 1 > >>> > >>> +#define DANUBE_PCI_REG32( addr )(*(volatile u32 *)(addr)) > >>> +#define PCI_CR_PR_OFFSET (KSEG1+0x1E105400) > >>> +#define PCI_CR_PC_ARB(PCI_CR_PR_OFFSET + 0x0080) > >>> + > >>> static u32 xway_latchcmd; > >>> > >>> +/* > >>> + * req_mask provides a mechanism to prevent interference between > >>> + * nand and pci (probably only relevant for the BT Home Hub 2B). > >>> + * Setting it causes the corresponding pci req pins to be masked > >>> + * during nand access, and also moves ebu locking from the read/write > >>> + * functions to the chip select function to ensure that the whole > >>> + * operation run
