[OpenWrt-Devel] batman and Kernel 2.6.26-rc8rc9
The batman layer3 kernel module does not appear to compile on the 2.6.26-rc8 rc9 kernels. Is this a known bug? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] 3/4 Latest Asterisk 1.4.21
On 7/13/08, Michael Geddes [EMAIL PROTECTED] wrote: Update to asterisk 1.4.21 (yes there's a 1.4.21.1 but I haven't tested it) Not sure why, but this hit GMail's spam filter for me. Just an FYI - hope it made it to everyone else. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Patches to fix AVR32 and lk 2.6.25+ stuff
Bas Mevissen wrote: Please check https://dev.openwrt.org/cgi-bin/trac.fcgi/ticket/3755 for a fix for kmod-ebtables package not being built on 2.6.25+ kernels. OK, comment here was the it would cause performance degradation. But is that also the case when the ebtables modules are not loaded? See my added comment on this ticket. Another question: can you let OpenWRT configuration options depend on the kernel configuration? And is that something wise to do? Idea is to disable the kmod-ebtables when ebtables is not defined in the kernel. Same for kmod-i2c-core. (see https://dev.openwrt.org/cgi-bin/trac.fcgi/ticket/3756) Regards, Bas. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [ANN] LuCI - Lua Configuration Interface
Hello Everyone, you may have noticed LuCI the Lua Configuration Interface in the official release announcement for Kamikaze 8.08 As there was not much information about this project in the past and we noticed several people asking in different places for it we like to make a little announcement here: LuCI is a new approach for a web user interface for OpenWRT. It aims to be free, clean and extensible. While most similar configuration interfaces make heavy use of the Shell-scripting language LuCI uses the Lua programming language and splits up the interface into logical parts like models and views, uses object-oriented libraries and templating. That ensures a higher performance, smaller installation size, faster runtimes and what is most important: better maintainibility. To the project status: LuCI is already quite stable and we are doing last improvements and bugfixes before the first RC version. At the moment all base-system networking and configuration stuff can be edited via LuCI plus a few more applications like firewalling and port-forwarding stuff, a statistics collector with rrdtool-graphs, OLSR and QoS support are included. We are always looking for people to maintain, improve or create web interface components. Maybe you would like to implement a webinterface page for your favorite application: It's not that difficult. If you want to contribute feel free to contact us. Any help whether it may be development, designing, translation or documentation stuff is highly appreciated. You will find all project-related links including a more detailed project description, the sourcecode repositories, screenshots and howtos on our current project website: http://luci.freifunk-halle.net Greetings Cyrus and Jow Lead Developers of LuCI ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] Add SPI over GPIO driver
This adds a driver that lets you drive an SPI bus over
generic GPIO pins.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
This driver is used in OpenWrt since quite some time, so please
consider for inclusion in mainline.
Index: linux-next/include/linux/spi/spi_gpio.h
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-next/include/linux/spi/spi_gpio.h 2008-07-14 20:52:48.0
+0200
@@ -0,0 +1,53 @@
+/*
+ * spi_gpio interface to platform code
+ *
+ * Copyright (c) 2008 Piotr Skamruk
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef _LINUX_SPI_SPI_GPIO
+#define _LINUX_SPI_SPI_GPIO
+
+#include linux/types.h
+#include linux/spi/spi.h
+
+
+/** struct spi_gpio_platform_data - Data definitions for a SPI-GPIO device.
+ * This structure holds information about a GPIO-based SPI device.
+ *
+ * @pin_clk: The GPIO pin number of the CLOCK pin.
+ *
+ * @pin_miso: The GPIO pin number of the MISO pin.
+ *
+ * @pin_mosi: The GPIO pin number of the MOSI pin.
+ *
+ * @pin_cs: The GPIO pin number of the CHIPSELECT pin.
+ *
+ * @cs_activelow: If true, the chip is selected when the CS line is low.
+ *
+ * @no_spi_delay: If true, no delay is done in the lowlevel bitbanging.
+ *Note that doing no delay is not standards compliant,
+ *but it might be needed to speed up transfers on some
+ *slow embedded machines.
+ *
+ * @boardinfo_setup: This callback is called after the
+ * SPI master device was registered, but before the
+ * device is registered.
+ * @boardinfo_setup_data: Data argument passed to boardinfo_setup().
+ */
+struct spi_gpio_platform_data {
+ unsigned int pin_clk;
+ unsigned int pin_miso;
+ unsigned int pin_mosi;
+ unsigned int pin_cs;
+ bool cs_activelow;
+ bool no_spi_delay;
+ int (*boardinfo_setup)(struct spi_board_info *bi,
+ struct spi_master *master,
+ void *data);
+ void *boardinfo_setup_data;
+};
+
+#endif /* _LINUX_SPI_SPI_GPIO */
Index: linux-next/drivers/spi/spi_gpio.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-next/drivers/spi/spi_gpio.c 2008-07-14 21:03:40.0 +0200
@@ -0,0 +1,242 @@
+/*
+ * Bitbanging SPI bus driver using GPIO API
+ *
+ * Copyright (c) 2008 Piotr Skamruk
+ * Copyright (c) 2008 Michael Buesch
+ *
+ * based on spi_s3c2410_gpio.c
+ * Copyright (c) 2006 Ben Dooks
+ * Copyright (c) 2006 Simtec Electronics
+ * and on i2c-gpio.c
+ * Copyright (C) 2007 Atmel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/delay.h
+#include linux/spinlock.h
+#include linux/workqueue.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/spi/spi.h
+#include linux/spi/spi_bitbang.h
+#include linux/spi/spi_gpio.h
+#include linux/gpio.h
+
+
+struct spi_gpio {
+ struct spi_bitbang bitbang;
+ struct spi_gpio_platform_data *info;
+ struct platform_device *pdev;
+ struct spi_board_info bi;
+};
+
+
+static inline struct spi_gpio *spidev_to_sg(struct spi_device *dev)
+{
+ return dev-controller_data;
+}
+
+static inline void setsck(struct spi_device *dev, int val)
+{
+ struct spi_gpio *sp = spidev_to_sg(dev);
+ gpio_set_value(sp-info-pin_clk, val ? 1 : 0);
+}
+
+static inline void setmosi(struct spi_device *dev, int val)
+{
+ struct spi_gpio *sp = spidev_to_sg(dev);
+ gpio_set_value(sp-info-pin_mosi, val ? 1 : 0);
+}
+
+static inline u32 getmiso(struct spi_device *dev)
+{
+ struct spi_gpio *sp = spidev_to_sg(dev);
+ return gpio_get_value(sp-info-pin_miso) ? 1 : 0;
+}
+
+static inline void do_spidelay(struct spi_device *dev, unsigned nsecs)
+{
+ struct spi_gpio *sp = spidev_to_sg(dev);
+
+ if (!sp-info-no_spi_delay)
+ ndelay(nsecs);
+}
+
+#define spidelay(nsecs) do { \
+ /* Steal the spi_device pointer from our caller.\
+* The bitbang-API should probably get fixed here... */ \
+ do_spidelay(spi, nsecs);\
+ } while (0)
+
+#define EXPAND_BITBANG_TXRX
+#include linux/spi/spi_bitbang.h
+
+static u32 spi_gpio_txrx_mode0(struct spi_device *spi,
+ unsigned nsecs, u32 word, u8 bits)
+{
+ return bitbang_txrx_be_cpha0(spi, nsecs, 0, word, bits);
+}
+
+static u32 spi_gpio_txrx_mode1(struct spi_device *spi,
+
[OpenWrt-Devel] [PATCH] Add dynamic MMC-over-SPI-GPIO driver
This driver provides a sysfs interface to dynamically create
and destroy GPIO-based MMC/SD card interfaces.
So an MMC or SD card can be connected to generic GPIO pins
and be configured dynamically from userspace.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
This driver is used in OpenWrt since quite some time, so please
consider for inclusion in mainline.
See the attached OpenWrt initscript for an example on how to use
the sysfs interface. Documentation should also be added. I'll submit
a patch for that, later.
Index: linux-next/drivers/mmc/host/mmc_over_spigpio.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-next/drivers/mmc/host/mmc_over_spigpio.c 2008-07-14
21:04:51.0 +0200
@@ -0,0 +1,339 @@
+/*
+ * Driver for driving an MMC card over a bitbanging GPIO SPI bus.
+ *
+ * Copyright 2008 Michael Buesch [EMAIL PROTECTED]
+ *
+ * Licensed under the GNU/GPL. See COPYING for details.
+ */
+
+#include linux/platform_device.h
+#include linux/list.h
+#include linux/mutex.h
+#include linux/spi/spi_gpio.h
+
+
+/* This is the maximum speed in Hz */
+#define GPIOMMC_MAXSPEED 500 /* Hz */
+
+
+#define DRIVER_NAMEspi-gpio-mmc
+#define PFXDRIVER_NAME :
+
+
+#define GPIOMMC_MAX_NAMELEN15
+#define GPIOMMC_MAX_NAMELEN_STR__stringify(GPIOMMC_MAX_NAMELEN)
+
+struct gpiommc_pins {
+ unsigned int gpio_di; /* Card DI pin */
+ unsigned int gpio_do; /* Card DO pin */
+ unsigned int gpio_clk; /* Card CLK pin */
+ unsigned int gpio_cs; /* Card CS pin */
+};
+
+struct gpiommc_device {
+ char name[GPIOMMC_MAX_NAMELEN + 1];
+ struct platform_device *pdev;
+ struct platform_device *spi_pdev;
+ struct gpiommc_pins pins;
+ u8 mode; /* SPI_MODE_X */
+ struct spi_board_info boardinfo;
+
+ struct list_head list;
+};
+
+
+static LIST_HEAD(gpiommc_devices_list);
+static DEFINE_MUTEX(gpiommc_mutex);
+
+
+MODULE_DESCRIPTION(SPI-GPIO based MMC driver);
+MODULE_AUTHOR(Michael Buesch);
+MODULE_LICENSE(GPL);
+
+
+static int gpiommc_boardinfo_setup(struct spi_board_info *bi,
+ struct spi_master *master,
+ void *data)
+{
+ struct gpiommc_device *d = data;
+
+ /* Bind the SPI master to the MMC-SPI host driver. */
+ strlcpy(bi-modalias, mmc_spi, sizeof(bi-modalias));
+
+ bi-max_speed_hz = GPIOMMC_MAXSPEED;
+ bi-bus_num = master-bus_num;
+ bi-mode = d-mode;
+
+ return 0;
+}
+
+static int gpiommc_probe(struct platform_device *pdev)
+{
+ static int instance;
+ struct gpiommc_device *d = platform_get_drvdata(pdev);
+ struct spi_gpio_platform_data pdata;
+ int err = -ENOMEM;
+
+ d-spi_pdev = platform_device_alloc(spi-gpio, instance++);
+ if (!d-spi_pdev)
+ goto out;
+
+ memset(pdata, 0, sizeof(pdata));
+ pdata.pin_clk = d-pins.gpio_clk;
+ pdata.pin_miso = d-pins.gpio_do;
+ pdata.pin_mosi = d-pins.gpio_di;
+ pdata.pin_cs = d-pins.gpio_cs;
+ pdata.cs_activelow = 1;
+ pdata.no_spi_delay = 1;
+ pdata.boardinfo_setup = gpiommc_boardinfo_setup;
+ pdata.boardinfo_setup_data = d;
+
+ err = platform_device_add_data(d-spi_pdev, pdata, sizeof(pdata));
+ if (err)
+ goto err_free_pdev;
+ err = platform_device_register(d-spi_pdev);
+ if (err)
+ goto err_free_pdata;
+
+ printk(KERN_INFO PFX MMC-Card \%s\
+ attached to GPIO pins %u,%u,%u,%u\n,
+ d-name, d-pins.gpio_di, d-pins.gpio_do,
+ d-pins.gpio_clk, d-pins.gpio_cs);
+out:
+ return err;
+
+err_free_pdata:
+ kfree(d-spi_pdev-dev.platform_data);
+ d-spi_pdev-dev.platform_data = NULL;
+err_free_pdev:
+ platform_device_put(d-spi_pdev);
+ return err;
+}
+
+static int gpiommc_remove(struct platform_device *pdev)
+{
+ struct gpiommc_device *d = platform_get_drvdata(pdev);
+
+ platform_device_unregister(d-spi_pdev);
+ printk(KERN_INFO PFX MMC-Card \%s\ removed\n, d-name);
+
+ return 0;
+}
+
+static void gpiommc_free(struct gpiommc_device *d)
+{
+ kfree(d);
+}
+
+static struct gpiommc_device *gpiommc_alloc(struct platform_device *pdev,
+ const char *name,
+ const struct gpiommc_pins *pins,
+ u8 mode)
+{
+ struct gpiommc_device *d;
+
+ d = kmalloc(sizeof(*d), GFP_KERNEL);
+ if (!d)
+ return NULL;
+
+ strcpy(d-name, name);
+ memcpy(d-pins, pins, sizeof(d-pins));
+ d-mode = mode;
+ INIT_LIST_HEAD(d-list);
+
+ return d;
+}
+
+/* List must be locked. */
+static struct gpiommc_device *gpiommc_find_device(const char *name)
+{
+
[OpenWrt-Devel] Gargoyle -- another (new) web interface for OpenWrt Kamikaze
It is ironic that the LuCI team decided to make an announcement regarding their project today. I have also been working on a new (open source) web interface for Kamikaze called Gargoyle, and am now releasing the first beta version, which can be found at gargoyle-router.com. The decision to release now was made completely independently of this announcement, and was made some time ago based on the progress of the project. It is just a coincidence that these announcements come on the same day. Right up front I want to emphasize that Gargoyle is, like both LuCI and X-Wrt a front-end for OpenWrt and NOT a fork. It can be installed as a set of packages on top of a default installation of Kamikaze 7.09, as well as via firmware images. Currently it is designed to run on top of Kamikaze 7.09 and not the trunk, but as soon as another stable version is released it will be engineered to run on top of that. However, several features included in the current trunk have been incorporated (e.g. the new UCI) and are installed as packages on top of the default Kamikaze release. I have chosen to incorporate the features this way so that the interface could be built around a stable version vs. the ever-changing trunk. Gargoyle takes a very different philosophical approach to interface design than X-Wrt or what I've seen of the new LuCI. Both X-Wrt and LuCI seem to be designed with the goal of providing the absolute maximum functionality possible. However, this often comes at the expense of making the interface more difficult to use, and can turn off novice users. There seems to be a belief that open-source software should be designed for power-users, without much thought to those with less expertise. Currently all router web interfaces that place a strong emphasis on ease-of-use are proprietary (their licenses do not permit redistribution of modified versions of their code without the author's permission). Gargoyle aims to be the first open-source web interface that places a strong emphasis on usability, and aimed at less experienced users. Because Gargoyle runs on top of OpenWrt, a more experienced user can also configure extra functionality relatively easily. Gargoyle includes a custom bandwidth monitoring package, a customized version of minihttpd , a new package for performing dynamic dns updates (similar to the ddns-scripts package which I submitted a few months ago, but written in C to be faster and linked to MatrixSSL to allow updates via https) and a custom set of QoS scripts (I found the current default OpenWrt implementation a bit convoluted). The modified web server does not, however, provide any of the interface code -- it's mostly modified to allow password protecting the interface more appropriately. The backend of the interface uses haserl, like X-wrt, but does not rely heavily on these shell-scripts. The interface is mostly javascript, which makes the interface feel faster than if it relied heavily on server-side scripts. Gargoyle is an open-source project and contributions are very, very welcome. I am releasing it under the terms of the GPL v2.0, with an exception/clarification that states that it may be modified to configure proprietary back-end software so long as all portions of the web interface are released under the terms of the GPL. See the FAQ (gargoyle-router.com/faq.html#qfoss) for more details. It is likely that the other web interface project(s) may benefit from some of the components that I've created, and also very likely that Gargoyle could benefit from some components of other open-source interfaces. I would be happy to share knowledge/code/ideas with other projects, even though the goals/philosophy of the projects may differ -- please contact me if interested. More information / documentation is available at gargoyle-router.com for those interested. Eric ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [ANN] LuCI - Lua Configuration Interface
Hi, Sounds good, but perhaps not for everyone. This will be integrated into the main firmware or will it always be a package? I'm not concerned about it being installed per default in the OpenWrt-built firmware, but will it be difficult to remove overall or will the LuCI code be mixed up with non-GUI scripts? Like Eric with Gargoyle, I also already have a GUI for kamikaze. I will not bore you with defaults, other than to say it completely separates UI from data by using a completely static web application (which can be put on the router or into a desktop app!) while only requiring very minimal 'data services' scripts on the router. It is also not specific to OpenWrt, is very suitable for a desktop GUI or built into a back-end web application, all using the same VERY simple XML GUI logic. As for LuCI, I would like to know more about why Lua and hence LuCI? You say It's not that difficult. - yet it does require learning a new language for most people and I don't see the huge benefit over using traditional shell scripts. It might be faster, but is that at the cost of complexity? It might be simple (once you know it), but enough to attract new developers? I also agree with Eric, that the 'kitchen sink' doesn't really make for a good router interface. It might be useful for more advanced users - who know and understand all the options of a program, but not for your target audience, imho. And, as a application developer, I'm less interested in spending time making a 'smart' GUI for my application if it is limited to LuCI -- I would rather spend my time on something a bit more portable as my application also isn't limited to OpenWrt. That is at least some feedback. That notwithstanding, good work and great project! David On Mon, 2008-07-14 at 20:05 +0200, Steven Barth wrote: Hello Everyone, you may have noticed LuCI the Lua Configuration Interface in the official release announcement for Kamikaze 8.08 As there was not much information about this project in the past and we noticed several people asking in different places for it we like to make a little announcement here: LuCI is a new approach for a web user interface for OpenWRT. It aims to be free, clean and extensible. While most similar configuration interfaces make heavy use of the Shell-scripting language LuCI uses the Lua programming language and splits up the interface into logical parts like models and views, uses object-oriented libraries and templating. That ensures a higher performance, smaller installation size, faster runtimes and what is most important: better maintainibility. To the project status: LuCI is already quite stable and we are doing last improvements and bugfixes before the first RC version. At the moment all base-system networking and configuration stuff can be edited via LuCI plus a few more applications like firewalling and port-forwarding stuff, a statistics collector with rrdtool-graphs, OLSR and QoS support are included. We are always looking for people to maintain, improve or create web interface components. Maybe you would like to implement a webinterface page for your favorite application: It's not that difficult. If you want to contribute feel free to contact us. Any help whether it may be development, designing, translation or documentation stuff is highly appreciated. You will find all project-related links including a more detailed project description, the sourcecode repositories, screenshots and howtos on our current project website: http://luci.freifunk-halle.net Greetings Cyrus and Jow Lead Developers of LuCI ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] ARM Kernel crash
Hi all, I have a problem with a program crashing an ARM kernel - and crashing it hard. The program uses the Tun/Tap driver, but I'm not certain that is the issue. I haven't seen this behavior on any other architecture - anyone know of known problems with tun/tap or other issues with ARM? I tried to debug the kernel while running under QEmu, but gdb just drops the remote connection with no other info. Any ideas about the problem or how to go about debugging it would be appreciated. Best regards, David ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
