Re: [OpenWrt-Devel] Howto debug init scripts like preinit?
Daniel Dickinson csh...@csolve.net writes: You won't see anything from preinit with set -x because when preinit is first called there is no stdin/stdout. One of the things preinit does is attach itself to a terminal, if there is one (otherwise it just connects to a pseudo-terminal) Would putting /dev/console in the root filesystem solve this? Fakeroot could be used for that without requiring real root for image generation. -- Thanks, Feri. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] brcm47xx 2.6.33 update patch
Peter Wagner tripo...@gmx.at writes: Am Mittwoch 03 März 2010 00:22:30 schrieb Peter Wagner: CONFIG_CMDLINE=root=/dev/mtdblock2 rootfstype=squashfs,jffs2 noinitrd console=ttyS0,115200 is missing in config-2.6.33 for brcm47xx OH my failure - it seems this option isnt needed any more Before I fall in the same trap: could you please explain why not? -- Thanks, Feri. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] bridged client with ebtables snat?
Stefan Bethke s...@lassitu.de writes: Am 19.01.2010 um 00:09 schrieb Ferenc Wagner: Meanwhile, is there a fundamental reason why this scheme can't work, or do I simply overlook something? You probably don't need ebtables. With a routing setup (instead of bridging) and proxy arp, basic IP should work just fine. But things that depend on unique MAC addresses will need special treatment, like DHCP. Maybe tie a DHCP proxy to eth0? The point of the exercise is to avoid running anything at all on the router. The hardware at hand is a WAP54g access point (with 2MB flash and 8MB RAM), so running any user space process is quite a challange. Currently udhcpc works (with MUCH sweat), but the default dhclient- script does not... So I'm after a pure kernel solution, if at all possible. If nothing else works, I'm even willing to invoke the ugly layer 2 nat hack (any code pointers?), but would prefer a better solution, of course. -- Thanks, Feri. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Not really inline patches
Matthew King matthew.k...@monnsta.net writes: Sorry about that. I guess what MIME means by inline isn't what everyone else means. If you view the source and ignore the MIME wrappings they are inline in sort of the way intended... I can assure you that in a MIME capable MUA your patches display just prefectly. -- Feri. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] WRT-54-G / bcm47xx / kernel2.6 / wifi_b43 / debugFS
Spudz76 spud...@gmail.com writes: On Sun, 2010-01-10 at 12:02 +0100, Ferenc Wagner wrote: Felix Fietkau n...@openwrt.org writes: On 2010-01-08 6:24 PM, Ferenc Wagner wrote: Stefan Bethke s...@lassitu.de writes: Am 08.01.2010 um 16:57 schrieb Ferenc Wagner: However, I failed to use it in client mode: it associates with the AP, but doesn't receive IP packets (I simply bridge it to the LAN, and try DHCP from the laptop). See the numerous forum posts on why client bridging does not work. You'll need to run udhcp on the router itself, or configure a fixed ip. Many thanks for the quick pointer! I guess you're referring to https://dev.openwrt.org/ticket/5749, right? I can accept that there are technical reasons which make client bridging impossible, but don't fully understand them from the ticket. And I'm curious, so I'd be grateful for some further explanation or pointers. Why is the source MAC address missing from the packet (travelling in which direction)? The source MAC is missing in packets from STA-AP The destination MAC is missing in packets from AP-STA These MACs are missing, because they are unnecessary when not using bridging, so they left them out in the standard. This also serves as MAC spoofing protection, as you cannot fake your MAC address without associating with a different ID. Thanks for the explanation and the picture, I understand the problem now. Isn't this something that could be worked around by ebtables snat? Or is that what's considered an ugly layer 2 nat hack by nbd in the ticket? Why is this any worse than IPv4 NAT? I agree that WDS is the right tool for such jobs, but that isn't always an option. In many (most?) cases, the wifi driver does not allow you to modify the MAC address. It's all about spoof protections as was mentioned before. Sorry, I don't get why I'd want to modify the MAC address (of the wifi card?), would you please explain? Even if I did, that really shouldn't be a problem with the rise of softmac drivers, should it? greater than the 24Mbit/s or so maximum you would otherwise see over normal 54Mbit 802.11g (wifi overhead plus tunnel overhead plus bridge overhead brings it down to around 50% of the link rate because each 1500-byte packet ends up being almost twice that). I don't get you again. Bridge overhead is zero (in packet size), as far as I know. OpenVPN overhead depends on the exact setup, but without security it can be less than 10 bytes. I don't know much about 802.11, but I feel like its overhead is in the 30 bytes range, not near 1 kB... -- Regards, Feri. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] WRT-54-G / bcm47xx / kernel2.6 / wifi_b43 / debugFS
Felix Fietkau n...@openwrt.org writes: On 2010-01-08 6:24 PM, Ferenc Wagner wrote: Stefan Bethke s...@lassitu.de writes: Am 08.01.2010 um 16:57 schrieb Ferenc Wagner: However, I failed to use it in client mode: it associates with the AP, but doesn't receive IP packets (I simply bridge it to the LAN, and try DHCP from the laptop). See the numerous forum posts on why client bridging does not work. You'll need to run udhcp on the router itself, or configure a fixed ip. Many thanks for the quick pointer! I guess you're referring to https://dev.openwrt.org/ticket/5749, right? I can accept that there are technical reasons which make client bridging impossible, but don't fully understand them from the ticket. And I'm curious, so I'd be grateful for some further explanation or pointers. Why is the source MAC address missing from the packet (travelling in which direction)? The source MAC is missing in packets from STA-AP The destination MAC is missing in packets from AP-STA These MACs are missing, because they are unnecessary when not using bridging, so they left them out in the standard. This also serves as MAC spoofing protection, as you cannot fake your MAC address without associating with a different ID. Thanks for the explanation and the picture, I understand the problem now. Isn't this something that could be worked around by ebtables snat? Or is that what's considered an ugly layer 2 nat hack by nbd in the ticket? Why is this any worse than IPv4 NAT? I agree that WDS is the right tool for such jobs, but that isn't always an option. -- Thanks, Feri. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] WRT-54-G / bcm47xx / kernel2.6 / wifi_b43 / debugFS
Bastian Bittorf bitt...@bluebottle.com writes: today i successfully tried a snapshot (r18405) and was very lucky to have an working opensource broadcom driver, which uses minstrel rate selection algo, is stable and fast. (only ibss/adhoc-mode tested) Hi, I've done similarly with r19022 on a WAP54G. The opensource wireless driver indeed works, at least in ad-hoc mode I could exchange packets with my laptop next to it. However, I failed to use it in client mode: it associates with the AP, but doesn't receive IP packets (I simply bridge it to the LAN, and try DHCP from the laptop). TxPower goes to the maximum (27 dBm), sensitivity is unknown to iwconfig. Communicating with the same (remote, thus low quality) AP is no problem with the binary 2.4 driver in WhiteRussian (in the same bridged setup). Any ideas where I should start looking and what for? I can probably enable debugfs as described elsewhere in this thread, but I don't even know what to expect to see there, so guidance is most appreciated. -- Thanks, Feri. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] brcm47xx/linux-2.6.30
Hauke Mehrtens ha...@hauke-m.de writes: Ferenc Wagner wrote: How well is Linux 2.6.30 on brcm47xx supposed to work? The flash driver seems to have some problem at least: flash init: 0x1c00 0x0200 Physically mapped flash: Found 1 x16 devices at 0x0 in 16-bit bank Intel/Sharp Extended Query Table at 0x0035 Using auto-unlock on power-up/resume cfi_cmdset_0001: Erase suspend on write enabled Flash device: 0x20 at 0x1fc0 bootloader size: 262144 Creating 4 MTD partitions on Physically mapped flash: 0x-0x0004 : cfe 0x0004-0x001f : linux 0x00116000-0x001f : rootfs mtd: partition rootfs doesn't start on an erase block boundary -- force read-only mtd: partition rootfs_data created automatically, ofs=65C, len=F9C3 0x065c-0x001f : rootfs_data mtd: partition rootfs_data is out of reach -- disabled 0x001f-0x0020 : nvram Splitting rootfs arrives at a wrong offset/length pair. (Otherwise the kernel boots into userspace just fine.) I looks like your flash chip is only 2MB big, that is too small for an image with kernel 2.6. Yes, for a prebuilt image, but not for a manually trimmed-down one. Did it boot with kernel 2.6.28? If yes, please post the the same output with that kernel. Sure, here it is (with a higher log level, from dmesg): flash init: 0x1c00 0x0200 Physically mapped flash: Found 1 x16 devices at 0x0 in 16-bit bank Intel/Sharp Extended Query Table at 0x0035 Using auto-unlock on power-up/resume cfi_cmdset_0001: Erase suspend on write enabled Flash device: 0x20 at 0x1fc0 bootloader size: 262144 Updating TRX offsets and length: old trx = [0x001c, 0x090c, 0x000a8800], len=0x00181000 crc32=0xcde8e3d0 new trx = [0x001c, 0x090c, 0x000a8800], len=0x000a8800 crc32=0xd5a3c0a2 Done Creating 4 MTD partitions on Physically mapped flash: 0x-0x0004 : cfe 0x0004-0x001f : linux 0x000e8800-0x001f : rootfs mtd: partition rootfs doesn't start on an erase block boundary -- force read-only mtd: partition rootfs set to be root filesystem mtd: partition rootfs_data created automatically, ofs=1B, len=4 0x001b-0x001f : rootfs_data 0x001f-0x0020 : nvram Or with a bigger 2.6.28 kernel: Creating 4 MTD partitions on Physically mapped flash: 0x-0x0004 : cfe 0x0004-0x001f : linux 0x00110800-0x001f : rootfs mtd: partition rootfs doesn't start on an erase block boundary -- force read-only mtd: partition rootfs_data created automatically, ofs=1D, len=2 0x001d-0x001f : rootfs_data 0x001f-0x0020 : nvram But also 2.6.30 booted into user space, as I wrote above. -- Thanks, Feri. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [patch] disable bridge firewalling in sysctl.conf by default
Matthias Buecher / Germany m...@maddes.net writes: The bridge firewalling is caused by CONFIG_BRIDGE_NETFILTER=y (bool), which is enabled by kmod-ebtables. As it is bool it can not be outsourced into an installable module. I wonder why it isn't possible to avoid loading ebtables... But can't check now, I'm mostly offline. -- Cheers, Feri. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [patch] disable bridge firewalling in sysctl.conf by default
Matthias Buecher / Germany m...@maddes.net writes: On 13.08.2009 11:08, Ferenc Wagner wrote: Matthias Buecher / Germany m...@maddes.net writes: The bridge firewalling is caused by CONFIG_BRIDGE_NETFILTER=y (bool), which is enabled by kmod-ebtables. As it is bool it can not be outsourced into an installable module. I wonder why it isn't possible to avoid loading ebtables... But can't check now, I'm mostly offline. ebtables is not installed/loaded (it's a module). OK, so you don't actually load the ebtables module, and you don't expect iptables to filter your bridged traffic. Not unreasonable. When compiling ebtables for OpenWrt, then CONFIG_BRIDGE_NETFILTER=y is set, which enables bridge firewalling inside the kernel's netfilter (not a module). I think it's more a problem that the default behaviour is subject to change between different OpenWRT builds. CONFIG_BRIDGE_NETFILTER should be y or n always, irrespective of kmod-ebtables, to avoid user confusion, in my opinion. Maybe it's indeed best to enable it in the kernel konfig, and disable by sysctl, as Matthias suggests. -- Cheers, Feri. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] stderr should be a copy of stdout, not stdin
Signed-off-by: Ferenc Wagner wf...@niif.hu
diff --git a/package/base-files/files/etc/preinit
b/package/base-files/files/etc/preinit
index 4e706f1..2dadb36 100755
--- a/package/base-files/files/etc/preinit
+++ b/package/base-files/files/etc/preinit
@@ -59,7 +59,7 @@ dd if=/dev/console of=/dev/null bs=1 count=0 /dev/null
2/dev/null {
M1=/dev/console
}
-exec $M0 $M1 20
+exec $M0 $M1 21
echo - preinit -
echo Press CTRL-C for failsafe
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] proc is already mounted in /etc/preinit, no use doing it again
Signed-off-by: Ferenc Wagner wf...@niif.hu
diff --git a/target/linux/brcm-2.4/base-files/etc/preinit.arch
b/target/linux/brcm-2.4/base-files/etc/preinit.arch
index 25d11d9..18b6ae5 100755
--- a/target/linux/brcm-2.4/base-files/etc/preinit.arch
+++ b/target/linux/brcm-2.4/base-files/etc/preinit.arch
@@ -20,8 +20,6 @@ failsafe() {
ash --login
}
-mount none /proc -t proc
-
insmod diag
set_state preinit
echo '/sbin/hotplug.failsafe' /proc/sys/kernel/hotplug
diff --git a/target/linux/olpc/base-files/etc/preinit.arch
b/target/linux/olpc/base-files/etc/preinit.arch
index f29f0d4..91a4569 100644
--- a/target/linux/olpc/base-files/etc/preinit.arch
+++ b/target/linux/olpc/base-files/etc/preinit.arch
@@ -1,2 +1 @@
-mount -t proc none /proc
grep 'failsafe=' /proc/cmdline export FAILSAFE=true
diff --git a/target/linux/x86/base-files/etc/preinit.arch
b/target/linux/x86/base-files/etc/preinit.arch
index 00db8b4..08b25be 100644
--- a/target/linux/x86/base-files/etc/preinit.arch
+++ b/target/linux/x86/base-files/etc/preinit.arch
@@ -1,2 +1 @@
-mount -t proc none /proc
grep 'failsafe=' /proc/cmdline /dev/null export FAILSAFE=true
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] If inserting switch_core failed, do not waste time trying the switch drivers
Signed-off-by: Ferenc Wagner wf...@niif.hu
diff --git a/target/linux/brcm-2.4/base-files/etc/preinit.arch
b/target/linux/brcm-2.4/base-files/etc/preinit.arch
index 18b6ae5..fd73e37 100755
--- a/target/linux/brcm-2.4/base-files/etc/preinit.arch
+++ b/target/linux/brcm-2.4/base-files/etc/preinit.arch
@@ -46,10 +46,12 @@ check_module () {
return $?
}
-insmod switch-core
-check_module switch-robo || check_module switch-adm || {
- check_module bcm57xx activate_gpio=0x4 cpu_port=8u*
-} || rmmod switch-core
+if insmod switch-core; then
+ check_module switch-robo ||
+ check_module switch-adm ||
+ check_module bcm57xx activate_gpio=0x4 cpu_port=8u* ||
+ rmmod switch-core
+fi
[ -d /proc/switch/eth0 ] {
echo 1 /proc/switch/eth0/reset
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCHv2] If inserting switch_core failed, do not waste time trying the switch drivers
Signed-off-by: Ferenc Wagner wf...@niif.hu
diff --git a/target/linux/brcm-2.4/base-files/etc/preinit.arch
b/target/linux/brcm-2.4/base-files/etc/preinit.arch
index 18b6ae5..9491056 100755
--- a/target/linux/brcm-2.4/base-files/etc/preinit.arch
+++ b/target/linux/brcm-2.4/base-files/etc/preinit.arch
@@ -46,10 +46,12 @@ check_module () {
return $?
}
-insmod switch-core
-check_module switch-robo || check_module switch-adm || {
- check_module bcm57xx activate_gpio=0x4 cpu_port=8u*
-} || rmmod switch-core
+if insmod switch-core; then
+ check_module switch-robo ||
+ check_module switch-adm ||
+ { check_module bcm57xx activate_gpio=0x4 cpu_port=8u*; } ||
+ rmmod switch-core
+fi
[ -d /proc/switch/eth0 ] {
echo 1 /proc/switch/eth0/reset
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] Add the gpio_keys input module to menuconfig
Signed-off-by: Ferenc Wagner wf...@niif.hu Index: package/kernel/modules/other.mk === --- package/kernel/modules/other.mk (revision 16393) +++ package/kernel/modules/other.mk (working copy) @@ -674,6 +674,23 @@ $(eval $(call KernelPackage,input-polldev)) +define KernelPackage/input-gpio-keys + SUBMENU:=$(OTHER_MENU) + TITLE:=GPIO key support + DEPENDS:= @GPIO_SUPPORT +kmod-input-core + KCONFIG:=CONFIG_KEYBOARD_GPIO + FILES:=$(LINUX_DIR)/drivers/input/keyboard/gpio_keys.$(LINUX_KMOD_SUFFIX) + AUTOLOAD:=$(call AutoLoad,60,gpio_keys) +endef + +define KernelPackage/input-gpio-keys/description + This driver implements support for buttons connected + to GPIO pins of various CPUs (and some other chips). +endef + +$(eval $(call KernelPackage,input-gpio-keys)) + + define KernelPackage/input-gpio-buttons SUBMENU:=$(OTHER_MENU) TITLE:=Polled GPIO buttons input device ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] How to extract the quilt kernel patches?
Hi, I appended the quilt patch series of the kernel under build_dir/. Is there a mechanism or some best practice to extract them into the version-controlled part of the tree? Or how to work with this machinery in general? I also noticed that make kernel_menuconfig does some magic to update the config* files under target/. Is there some writeup on what it does exactly? It does pretty well, which is nice, but the lack of understanding leaves an uncomfortable feeling in me... -- Thanks, Feri. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [RFC PATCH] Using Linux 2.6 LED class and input layer instead of broadcom-diag
Hi,
For a couple of days I've been playing with wiring up the LEDs and
buttons (OK, there's only one of each) of a WAP54Gv2 device with the
newish generic Linux 2.6 LED class and input layer.
As it turns out, there's no problem with the LED, after registering
it as a platform device /sys/class/leds/gpio:green:wlan appears and
works with the available triggers without a hitch.
The reset button needs more tweaking, because on one hand the GPIO IRQ
interface is inadequate and on the other hand the gpio_keys kernel
module is way too rigid. However, after fixing these the prototype
starts working.
I think this approach has technical merits: using the generic kernel
interfaces cuts down on home-grown code and provides free add-ons,
like the various LED trigger modules for example. On the other hand,
it surely incurs some size increase, which may or may not be
acceptable for OpenWRT. I can't provide hard numbers yet, but it
doesn't seem too bad.
The third part of broadcom-diag, namely, board identifiction, is
something which has to predate platform device registration, as
detecting GPIO wiring is impossible in general, and isn't described in
firmware either, AFAIK (how wonderful that would be!) It could even
move into user space, if we don't want to use it earlier.
After this, /sbin/hotplug.failsafe could be replaced by a read from
/dev/event0.
Please comment on the idea in general or the implementation in
particular. The latter is more a proof of concept than anything,
though, so be gentle... All are platform/* patches.
Not for general consumption: hard wires WAP54Gv2 in the platform
setup code. Board detection could be added here, if early
availability is desired.
Index: b/arch/mips/bcm47xx/setup.c
===
--- a/arch/mips/bcm47xx/setup.c
+++ b/arch/mips/bcm47xx/setup.c
@@ -39,6 +39,9 @@
#include asm/time.h
#include asm/fw/cfe/cfe_api.h
#include linux/pm.h
+#include linux/leds.h
+#include linux/input.h
+#include linux/gpio_keys.h
#include include/nvram.h
@@ -222,3 +225,73 @@ static int __init bcm47xx_register_gpiod
return 0;
}
device_initcall(bcm47xx_register_gpiodev);
+
+/* FIXME __initdata ? */
+struct gpio_led wap54gv2_leds[] = {
+ {
+ .name = gpio:green:wlan,
+ .default_trigger = default-on, /* provide diagnostics */
+ .gpio = 5,
+ .active_low = 1
+ }
+};
+
+struct gpio_led_platform_data wap54gv2_leds_pdata = {
+ .num_leds = sizeof wap54gv2_leds / sizeof *wap54gv2_leds,
+ .leds = wap54gv2_leds,
+};
+
+struct platform_device wap54gv2_gpio_led_device = {
+ .name = leds-gpio,
+ .id = -1,
+ .dev = {
+ .platform_data = wap54gv2_leds_pdata
+ }
+};
+
+static int __init wap54gv2_register_gpio_leds(void)
+{
+ if (platform_device_register(wap54gv2_gpio_led_device)) {
+ printk(KERN_ERR bcm47xx: registering wap54gv2 GPIO LED device failed\n);
+ return -ENODEV;
+ }
+
+ return 0;
+}
+device_initcall(wap54gv2_register_gpio_leds);
+
+struct gpio_keys_button wap54gv2_buttons[] = {
+ {
+ .code = KEY_R,
+ .gpio = 0,
+ .active_low = 0,
+ .desc = reset,
+ .type = EV_KEY,
+ .wakeup = 0,
+ .debounce_interval = 1000 /* msecs */
+ }
+};
+
+struct gpio_keys_platform_data wap54gv2_buttons_pdata = {
+.buttons = wap54gv2_buttons,
+.nbuttons = sizeof wap54gv2_buttons / sizeof *wap54gv2_buttons
+};
+
+struct platform_device wap54gv2_gpio_button_device = {
+ .name = gpio-keys,
+ .id = -1,
+ .dev = {
+ .platform_data = wap54gv2_buttons_pdata
+ }
+};
+
+static int __init wap54g_register_gpio_buttons(void)
+{
+ if (platform_device_register(wap54gv2_gpio_button_device)) {
+ printk(KERN_ERR bcm47xx: registering wap54gv2 GPIO button device failed\n);
+return -ENODEV;
+}
+
+ return 0;
+}
+device_initcall(wap54g_register_gpio_buttons);
We need a way to enable/disable GPIO interrupts. Only handles
chipco, I don't know what to do with extif.
Index: b/include/linux/ssb/ssb_embedded.h
===
--- a/include/linux/ssb/ssb_embedded.h
+++ b/include/linux/ssb/ssb_embedded.h
@@ -14,5 +14,6 @@ u32 ssb_gpio_outen(struct ssb_bus *bus,
u32 ssb_gpio_control(struct ssb_bus *bus, u32 mask, u32 value);
u32 ssb_gpio_intmask(struct ssb_bus *bus, u32 mask, u32 value);
u32 ssb_gpio_polarity(struct ssb_bus *bus, u32 mask, u32 value);
+void ssb_gpio_irq_enable(struct ssb_bus *bus, int value);
#endif /* LINUX_SSB_EMBEDDED_H_ */
Index: b/drivers/ssb/embedded.c
===
--- a/drivers/ssb/embedded.c
+++ b/drivers/ssb/embedded.c
@@ -135,6 +135,20 @@ u32 ssb_gpio_polarity(struct ssb_bus *bu
}
EXPORT_SYMBOL(ssb_gpio_polarity);
+void ssb_gpio_irq_enable(struct ssb_bus *bus, int enabled)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(bus-gpio_lock, flags);
+ if (ssb_chipco_available(bus-chipco))
+ ssb_chipco_irq_mask(bus-chipco, SSB_CHIPCO_IRQ_GPIO,
+
Re: [OpenWrt-Devel] opkg remove ifconfig opkg install 'ip'
Malte S. Stretz m...@apache.org writes: On Thursday 18 June 2009 16:22:54 Jo-Philipp Wich wrote: today I've written a proof-of-concept for getting rid of oldstyle networking aka 'ifconfig'. You do realize that this oldstyle networking stuff uses busybox internals while switching to ip will introduce yet another few kilobytes of bloat? busybox also has a builtin ip; I don't know if it has all the features needed but if it has, the images could get even smaller without the external ip and without the builtin ifconfig. The ip applet is not enabled currently, and I don't know if it's smaller than the ifconfig applet. -- Feri. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] opkg remove ifconfig opkg install 'ip'
Malte S. Stretz m...@apache.org writes: On Thursday 18 June 2009 18:20:06 Ferenc Wagner wrote: Malte S. Stretz m...@apache.org writes: On Thursday 18 June 2009 16:22:54 Jo-Philipp Wich wrote: today I've written a proof-of-concept for getting rid of oldstyle networking aka 'ifconfig'. You do realize that this oldstyle networking stuff uses busybox internals while switching to ip will introduce yet another few kilobytes of bloat? busybox also has a builtin ip; I don't know if it has all the features needed but if it has, the images could get even smaller without the external ip and without the builtin ifconfig. The ip applet is not enabled currently, and I don't know if it's smaller than the ifconfig applet. I know that its not enabled per default and don't know either if it is smaller (but I'm currently compiling to see what the difference is). But even if it is the same size as ifconfig, the per default installed ip package (the binary has about 200k) would become obsolete. If busybox can do all the stuff it does that means. So maybe $((script + (busybox + ip_applet - ifconfig_applet))) $((ip + (busybox - ip_applet + ifconfig_applet))... we'll see. Along the same lines, do you think the external bridge-tools is worth staying installed by default, given that the busybox brctl applet is already included? I didn't notice any missing functionality until now. If not error messages... -- Cheers, Feri. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Getting brcm47xx run on WAP54g (2 MB flash)
Michael Buesch m...@bu3sch.de writes: On Monday 15 June 2009 12:58:18 Ferenc Wagner wrote: Bastian Bittorf bitt...@bluebottle.com writes: * Ferenc Wagner wf...@niif.hu [14.06.2009 14:45]: For my purposes using a region with smaller blocks for jffs2 would be a big gain, as currently I've got a single 64 KB erase block for it, which obviously does not fly. Is it really possible? AFAIK the blocksize is fixed/hardlocked for this flashchip to 64k. Ever played with 'printk-patch' or similar things the get a smaller kernel? Not yet. But would that by me another 64k? I don't think so... By optimising the kernel for size I'm at 4 (!) erase blocks now, so I'd need one more to get an operating jffs2. But this agains gives me the feeling that jffs2 is rather inefficient at using flash space: I need 384k to store a single byte! :/ I wonder how much more I could store there in this case... I am running a OpenWRT with a 2.6 kernel on a WAP54G. It's rather difficult to get it stripped down, but it _does_ work. The device does run in production since several months. Thanks, that's good to know! Don't you feel like putting this into the Wiki and linking it from the WAP54g page from WiP? :) So what are the issues? It turns out RAM is _not_ an issue. Just disable all services that are not absolutely required (dhcp, etc...) and you'll get enough free RAM. The issue is flash. In fact the 5 erase blocks are the issue. Exactly. First start with disabling _everything_ that is not needed to keep the device alife. It took me some time to learn that hotplug2 and udevtrigger is needed... In the kernel and in the openwrt config (busybox config, too). Thanks for reminding me of BusyBox. The menuconfig interface hides that submenu, like, completely! The second step is to search for big flash consumers. It turns out the crypto modules do consume a large amount of flash. Even if the functionality is already compiled into the kernel image itself. Which of them are really needed, btw? Attached is a patch which strips down several hundred kiB of flash space. I think it doesn't apply anymore to current trunk, but you might get the idea. Yes, I was experimenting with things like this. But there's some more to do, as it seems. Another rather big flash consumer is the b43 driver firmware. There's an option in openwrt config to include only the necessary firmware files. Use it. Yes, that's pretty important. I've found it already. And did you try optimising your kernel for size (CONFIG_CC_OPTIMIZE_FOR_SIZE)? I'm not sure if this is any useful for you running a 2.4 image, but I just wanted to drop it into the discussion. Have fun! No, I'm running 2.6, so this was immensely useful. Thank you very much! A question, though: after you managed to get your 5th erase block and had a working jff2, did you actually use it for anything else than setting up a couple of variables, like eg. operating mode and IP addresses? Because if not, then I think a startup/shutdown script pair, which translated between nvram variables and /etc/config, could work just as well, without requiring us to squeeze things this bad. -- Regards, Feri. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Getting brcm47xx run on WAP54g (2 MB flash)
Hi! I'm trying to get Kamikaze brcm47xx run on a WAP54g v2. It has only 2 MB flash, so the process involves a lot of trial and error. So for basic testing I decided to go with an NFS root setup to avoid the need to reflash after each filesystem change. This works OK after disabling ifconfig $ifname 0.0.0.0 down at the end of target/linux/brcm-2.4/base-files/etc/preinit.arch. (It took some time to realize it's hard linked to brcm47xx. Nasty...) Why is that ifconfig there at all? (A side note: from time to time I'm swamped with 0 length 000 mode files in build_dir. That means a flood of errors from find etc. Anybody knows why they are created?) Now to my main points: 1. I can also boot new kernels without flashing from CFE (v1.0.37) by boot -elf 1.2.3.4:vmlinux.elf Dandy. But setenv -p STARTUP boot -elf 1.2.3.4:vmlinux.elf; doesn't make this automatic on next reboot, contrary to documentation: STARTUP has the value go; again. What do I miss here? 2. This method is limited to kernels smaller that 3 MB uncompressed, as trying to load larger ones overwrites CFE itself which has: Text (code) segment: 0x8030 - 0x80309420 (37920) This is documented in OpenWrtDocs/KamikazeHowto as CFE/PMON TFTP maximum image size limitation, with a note that it could be worked around in principle. But is there a working solution available? (Even lzma-loader could do the job if it read the compressed image by TFTP instead of from a flash partition or did some other clever trick...) 3. Using Ctrl-C on the console to enter failsafe mode does not work: some ^C-s appear on the screen, that's all. Is it a bad terminal setting, or what? 4. Why isn't /dev/console opened as stdin/stdout/stderr at the beginning of /etc/preinit? How is it possible to have no console at all? Why is /dev/pty/ptmx trickery needed? 5. http://xinu.mscs.mu.edu/Flash_driver says that different erase block layouts are possible across a single flash chip (at least that's what I understand from it). For my purposes using a region with smaller blocks for jffs2 would be a big gain, as currently I've got a single 64 KB erase block for it, which obviously does not fly. Is it really possible? 6. Otherwise I'd have to go back to using nvram for configuration, as wasting another 64 KB flash for that isn't really an option on this device. Or perhaps using cache/erase/write on a single block through FTL and another filesystem... I'd be grateful for any insight on this. 7. On the other hand, probably quite some space could be gained by disabling CONFIG_BLOCK, if squashfs didn't depend on it. What do you think, is this dependency hard, or could be reasonably get rid of? (By the squashfs developers, of course.) 8. Why is noinitrd on the command line? 9. I compiled FILE_LOCKING out of my kernel, and it broke busybox lock at least, giving funny effects in failsafe mode. Should I expect futher serious breakage? 10. That's all for now, thanks for reading this far. 11. Thanks as well for incorporating my broadcom-diag patch so quickly. :) 12. This hardware (WAP54g v2) is marked work in progess on the Wiki. Who is working on this? We should make contact. -- Regards, Feri. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
