Re: [OpenWrt-Devel] Adding entries to the crontab
(crontab -l 2/dev/null | grep -v cron_prog; echo * * * * * /bin/cron_prog) | crontab - 2/dev/null That's why using the crontab command is a bit tricky, because you're using your host machine command when you're building a new firmware including your package (instead of installing the firmware in an existing firmware). In the example I gave (it was not specifically for /etc/crontab, but it's more or less the same) you can prefix the files path you are modifying with '$${IPKG_INSTROOT}' as in $${IPKG_INSTROOT}/etc/inetd.conf'. So I would personnally stick with 'echo' instead of 'crontab'. Cheers, ben. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Adding entries to the crontab
So iiuc I should echo to $${IPKG_INSTROOT}/etc/crontabs/root ? 2008/7/20 Benoît Ganne [EMAIL PROTECTED]: (crontab -l 2/dev/null | grep -v cron_prog; echo * * * * * /bin/cron_prog) | crontab - 2/dev/null That's why using the crontab command is a bit tricky, because you're using your host machine command when you're building a new firmware including your package (instead of installing the firmware in an existing firmware). In the example I gave (it was not specifically for /etc/crontab, but it's more or less the same) you can prefix the files path you are modifying with '$${IPKG_INSTROOT}' as in $${IPKG_INSTROOT}/etc/inetd.conf'. So I would personnally stick with 'echo' instead of 'crontab'. Cheers, ben. ___ 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
Re: [OpenWrt-Devel] [ANN] LuCI - Lua Configuration Interface
Hi, I think this is a good idea. Though, it isn't the 'break-up' I imagined when I first started reading your message. I just assumed the LuCI webif was minimal with the option of adding tabs -- much like the original webif. I suppose the questions I still have about the LuCI webif project are: 1) will it try to only configure UCI files, or will it generally be creating application configuration files? 2) will it become the driving force in defining the UCI variables and their meanings? In my mind, there are several distinct elements: - creating application configuration files for the packages needed to implement 'features'. - defining and the logic of 'feature settings' (for lack of a better term) expressed in UCI, for example LAN DHCP Network being written into UCI config/dnsmasq or config/chilli based on the option Hotspot Enabled. - and the web interface to configure it. The first element is largely the task of shell scripts for core settings, and the rest is LuCI. The more you keep the elements separate, the easier it is to switch out the pieces, which I believe is a key element in getting a broader contributor community over those interested in this specific web presentation. I would even add another element above the webif for: - configuration and status web services (API) to further decouple the features (gathering status, setting UCI) from the presentation layer. Cheers, David On Sat, 2008-07-19 at 20:13 +0200, Steven Barth wrote: Hello Everyone, much work has been done this week and thanks to your feedback and opinions we are happy to inform you about the latest project updates. After the recent discussions about user-friendly vs. full-featured interfaces we decided to split up LuCI into two parts LuCI Administration and LuCI Essentials. Administration is the usual full-featured power-user interface while Essentials serves the non-power-user's needs by just providing the most important configuration settings in a simplified user-friendly way. Essentials contains configuration and status pages for basic Network, Wifi and System settings and can be extended with modules for Portforwarding, QoS, DDNS, UPNP, Time-Synchronization Everything of course with theme and translation support. You will find some screenshots of Essentials here: http://luci.freifunk-halle.net/WebUI/Screenshots/Essentials Build instructions - as usual - can be found here: http://luci.freifunk-halle.net/Installation LuCI Essentials (as well as LuCI Administration and the additional modules) can be found in your build configuration under Administration - LuCI - Webinterface Components after adding the LuCI OpenWRT feed to your buildroot. Greetings Cyrus ___ 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] Missing wireless and DHCP server on fresh SVN build?
Hi all, 1) This might be a very default question, but Google was not my friend this time :(. When I compile a fresh build from SVN, the router fails to start up wireless (lan is ok) and dhcp. So I have to fix my ip to connect to the router, but the wlan led ain't running... And neither can I see any wireless network. What should I do to fix this? My hardware is a Linksys WRT54GL. 2) On another note: is there a possibility to immediately set the root password and not start up the telnet daemon at first boot? Thanks! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Missing wireless and DHCP server on fresh SVN build?
2) On another note: is there a possibility to immediately set the root password and not start up the telnet daemon at first boot? Disable telnetd in your busybox configuration and either place a prepared passwd file in ${BUILDROOT}/files/etc/passwd (copied from packages/base-files/files/etc/passwd would be a good start) or modify the passwd file in base-files. Note that if you add in things like tor and certain other packages, they'll want to append to the default one. Always check build_dir/${ARCH}/root-${TARGET}/etc/passwd to make sure it's what you want to be on the firmware. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v3] 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. Simple spelling fixes since v2. 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-20 21:40:38.0 +0200 @@ -0,0 +1,73 @@ +/* + * spi_gpio interface to platform code + * + * Copyright (c) 2008 Piotr Skamruk + * Copyright (c) 2008 Michael Buesch + * + * 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; +}; + +/** + * SPI_GPIO_PLATDEV_NAME - The platform device name string. + * + * The name string that has to be used for platform_device_alloc + * when allocating a spi-gpio device. + */ +#define SPI_GPIO_PLATDEV_NAME spi-gpio + +/** + * spi_gpio_next_id - Get another platform device ID number. + * + * This returns the next platform device ID number that has to be used + * for platform_device_alloc. The ID is opaque and should not be used for + * anything else. + */ +int spi_gpio_next_id(void); + +#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-20 21:40:38.0 +0200 @@ -0,0 +1,251 @@ +/* + * 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 +#include asm/atomic.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
[OpenWrt-Devel] [PATCH v3] Add GPIO-based MMC/SD driver
This driver hooks up the mmc_spi and spi_gpio modules so that MMC/SD cards can be used on a GPIO based bus by bitbanging the SPI protocol in software. This driver provides a configfs interface to dynamically create and destroy GPIO-based MMC/SD card interfaces. It also provides a platform device interface API. See Documentation/gpiommc.txt for details. Signed-off-by: Michael Buesch [EMAIL PROTECTED] --- This driver is used in OpenWrt since quite some time, so please consider for inclusion in mainline. Changes since v2: The sysfs interface has been replaced by a configfs interface. Although I don't really like the bloat this adds (this is a driver for embedded machines), I do like the much cleaner interface and I think it's worth the bloat. Index: linux-next/drivers/mmc/host/gpiommc.c === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-next/drivers/mmc/host/gpiommc.c 2008-07-20 21:40:47.0 +0200 @@ -0,0 +1,608 @@ +/* + * Driver an MMC/SD card on a bitbanging GPIO SPI bus. + * This module hooks up the mmc_spi and spi_gpio modules and also + * provides a configfs interface. + * + * Copyright 2008 Michael Buesch [EMAIL PROTECTED] + * + * Licensed under the GNU/GPL. See COPYING for details. + */ + +#include linux/mmc/gpiommc.h +#include linux/platform_device.h +#include linux/list.h +#include linux/mutex.h +#include linux/spi/spi_gpio.h +#include linux/configfs.h +#include linux/gpio.h +#include asm/atomic.h + + +#define PFXgpio-mmc: + + +struct gpiommc_device { + struct platform_device *pdev; + struct platform_device *spi_pdev; + struct spi_board_info boardinfo; +}; + + +MODULE_DESCRIPTION(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; + struct gpiommc_platform_data *pdata = d-pdev-dev.platform_data; + + /* Bind the SPI master to the MMC-SPI host driver. */ + strlcpy(bi-modalias, mmc_spi, sizeof(bi-modalias)); + + bi-max_speed_hz = pdata-max_bus_speed; + bi-bus_num = master-bus_num; + bi-mode = pdata-mode; + + return 0; +} + +static int gpiommc_probe(struct platform_device *pdev) +{ + struct gpiommc_platform_data *mmc_pdata = pdev-dev.platform_data; + struct spi_gpio_platform_data spi_pdata; + struct gpiommc_device *d; + int err; + + err = -ENXIO; + if (!mmc_pdata) + goto error; + +#ifdef CONFIG_MMC_SPI_MODULE + err = request_module(mmc_spi); + if (err) { + printk(KERN_WARNING PFX + Failed to request mmc_spi module.\n); + } +#endif /* CONFIG_MMC_SPI_MODULE */ + + /* Allocate the GPIO-MMC device */ + err = -ENOMEM; + d = kzalloc(sizeof(*d), GFP_KERNEL); + if (!d) + goto error; + d-pdev = pdev; + + /* Create the SPI-GPIO device */ + d-spi_pdev = platform_device_alloc(SPI_GPIO_PLATDEV_NAME, + spi_gpio_next_id()); + if (!d-spi_pdev) + goto err_free_d; + + memset(spi_pdata, 0, sizeof(spi_pdata)); + spi_pdata.pin_clk = mmc_pdata-pins.gpio_clk; + spi_pdata.pin_miso = mmc_pdata-pins.gpio_do; + spi_pdata.pin_mosi = mmc_pdata-pins.gpio_di; + spi_pdata.pin_cs = mmc_pdata-pins.gpio_cs; + spi_pdata.cs_activelow = mmc_pdata-pins.cs_activelow; + spi_pdata.no_spi_delay = mmc_pdata-no_spi_delay; + spi_pdata.boardinfo_setup = gpiommc_boardinfo_setup; + spi_pdata.boardinfo_setup_data = d; + + err = platform_device_add_data(d-spi_pdev, spi_pdata, + sizeof(spi_pdata)); + if (err) + goto err_free_pdev; + err = platform_device_add(d-spi_pdev); + if (err) + goto err_free_pdata; + platform_set_drvdata(pdev, d); + + printk(KERN_INFO PFX MMC-Card \%s\ + attached to GPIO pins di=%u, do=%u, clk=%u, cs=%u\n, + mmc_pdata-name, mmc_pdata-pins.gpio_di, + mmc_pdata-pins.gpio_do, + mmc_pdata-pins.gpio_clk, + mmc_pdata-pins.gpio_cs); + + return 0; + +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); +err_free_d: + kfree(d); +error: + return err; +} + +static int gpiommc_remove(struct platform_device *pdev) +{ + struct gpiommc_device *d = platform_get_drvdata(pdev); + struct gpiommc_platform_data *pdata = d-pdev-dev.platform_data; + + platform_device_unregister(d-spi_pdev); + printk(KERN_INFO PFX GPIO based MMC-Card \%s\
Re: [OpenWrt-Devel] Missing wireless and DHCP server on fresh SVN build?
Hi Stephen, I know 2.6 doesn't support yet the broadcom driver :(... I completely bricked (and yes, I tried everything but the JTAG method) my router with flashing an SVN image of the 2.6 kernel :). When I flash the original firmware or dd-wrt, it has wireless... But not with the latest SVN version of OpenWRT? When I do ifup wl0 it says the interface is unknown, and when I run something like iwconfig (I can't remember exactly anymore, but it's the program started by /etc/init.d/network to check for wireless) it says wl0 is disabled? Thanks if you could make some sense for me :) 2008/7/21 Steffen Hoffmann [EMAIL PROTECTED]: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, since nobody else stepped in until now, I'll try and share some of my limited knowledge: Steven Van Ingelgem, 20.07.2008 18:37: Hi all, 1) This might be a very default question, but Google was not my friend this time :(. When I compile a fresh build from SVN, the router fails to start up wireless (lan is ok) and dhcp. So I have to fix my ip to connect to the router, but the wlan led ain't running... And neither can I see any wireless network. What should I do to fix this? My hardware is a Linksys WRT54GL. Well, you flashed an image for Broadcom with kernel 2.4 (brcm-2.4 folder)? The images based on 2.6 doesn't support wireless at all these days. Issues with not yet ready free driver replacements for proprietary software pieces, as far as I understood ... Greetings Steffen Hoffmann -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIg7ae31DJeiZFuHcRAnKxAJ9iAVlXqYkBC+I5L/DRJYqTgW1STwCglMvb bOlW8VRg93lm6bZ/F7wqE6k= =7lEH -END PGP SIGNATURE- ___ 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