Bastian Bittorf <bitt...@bluebottle.com> writes:
> * Ferenc Wagner <wf...@niif.hu> [14.06.2009 14:45]:
>
>> Why is that ifconfig there at all?
>
> because I didn't found the time till now, to make a function
> ifconfig() which is made known @common_func and translates the known
> calls to 'ip'. Give me some weeks and i will send a patch to discard
> 'ifconfig' ... (i promised this at WCW2009...)
Heh, I meant what its purpose was, not why it isn't an ip command
instead. :) Btw. ifconfig up started to spit out a page allocation
failure (attached at the end of this mail) but seems to work otherwise
OK...
>> 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?
>
> 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...
Anyway, I've got some more questions now...
12. nvram info says I've got 32k of nvram:
924 bytes used / 31844 bytes available (2.82%)
But a full 64k erase block is reserved for it:
0x001f0000-0x00200000 : "nvram"
Is it used double-buffered to protect against interrupted updates?
13. What does the bridge-utils package provide beyond brctl in busybox?
14. Isn't -C $(LINUX_DIR) included twice here?
./include/kernel-build.mk: $(_SINGLE)$(MAKE) -C $(LINUX_DIR)
$(KERNEL_MAKEOPTS) $$@
$(KERNEL_MAKEOPTS) always contains "-C $(LINUX_DIR)", doesn't it?
./include/kernel-defaults.mk:KERNEL_MAKEOPTS := -C $(LINUX_DIR) \
15. I have the impression that compat-wireless uses the "previous"
kernel config. After switching of LED support and recompiling:
$ nm
build_dir/linux-brcm47xx/compat-wireless-2009-06-02/net/mac80211/mac80211.ko |
fgrep _led_
U ieee80211_led_assoc
U ieee80211_led_exit
U ieee80211_led_init
U ieee80211_led_radio
U ieee80211_led_rx
U ieee80211_led_tx
After enabling it again, the above are all defined inside the module...
I didn't test it throughly, just bringing it up case it rings a bell.
16. Should the custom LED code in broadcom-diag be replaced by using
the led class in Linux 2.6? As a test, I added the below block to
arch/mips/bcm47xx/setup.c, and it works pretty good.
17. Hooking the reset button to into gpio-keys (included) didn't work
out this well, though: it blackholed all user space serial console
output. It probably clashes with diag.ko as well, and I don't
even know how to test it. Investigating further, but I'm curious
about your (general) opinion.
Thanks,
Feri.
Attach this to arch/mips/bcm47xx/setup.c to register platform GPIO
leds and buttons (the GPIO numbers are WAP54g v2 specific):
struct gpio_led wap54gv2_leds[] = {
{
.name = "leds-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);
------------------------------------------------------------
The page allocation failure from ifconfig (I guess it isn't readily
usable without the kernel symbol table, but anyway. It's
reproducible, so possible to debug, but I'd be grateful for some
guidance):
root@(none):/# ifconfig eth0 up
ifconfig: page allocation failure. order:0, mode:0x20
Call Trace:[<8002fba8>] 0x8002fba8
[<80013b58>] 0x80013b58
[<80013b58>] 0x80013b58
[<80068f9c>] 0x80068f9c
[<80085868>] 0x80085868
[<80085a98>] 0x80085a98
[<80085b2c>] 0x80085b2c
[<80085d98>] 0x80085d98
[<801728b0>] 0x801728b0
[<801743f4>] 0x801743f4
[<8014d3cc>] 0x8014d3cc
[<8014d5dc>] 0x8014d5dc
[<8014d51c>] 0x8014d51c
[<80085d50>] 0x80085d50
[<80151170>] 0x80151170
[<80151118>] 0x80151118
[<800645d8>] 0x800645d8
[<8017d760>] 0x8017d760
[<80179760>] 0x80179760
[<8017bd48>] 0x8017bd48
[<8017bc54>] 0x8017bc54
[<8017c7a8>] 0x8017c7a8
[<80076af0>] 0x80076af0
[<801cd5ec>] 0x801cd5ec
[<801ccf84>] 0x801ccf84
[<8017d2e4>] 0x8017d2e4
[<8017d2d8>] 0x8017d2d8
[<80168d30>] 0x80168d30
[<80097c04>] 0x80097c04
[<80097c04>] 0x80097c04
[<80097d04>] 0x80097d04
[<80169d14>] 0x80169d14
[<80089c3c>] 0x80089c3c
[<80169d9c>] 0x80169d9c
[<80098224>] 0x80098224
[<800031d0>] 0x800031d0
[<800031d0>] 0x800031d0
Mem-Info:
Normal per-cpu:
CPU 0: hi: 0, btch: 1 usd: 0
Active_anon:38 active_file:299 inactive_anon:36
inactive_file:257 dirty:0 writeback:0 unstable:0
free:34 slab:0 mapped:140 pagetables:15 bounce:0
Normal free:136kB min:360kB low:448kB high:540kB active_anon:152kB
inactive_anon:144kB active_file:1196kB inactive_file:1028kB present:8128kB
pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0
Normal: 0*4kB 1*8kB 0*16kB 0*32kB 0*64kB 1*128kB 0*256kB 0*512kB 0*1024kB
0*2048kB 0*4096kB = 136kB
556 total pagecache pages
2048 pages RAM
613 pages reserved
454 pages shared
1151 pages non-shared
root@(none):/# b44: eth0: Link is up at 100 Mbps, half duplex.
b44: eth0: Flow control is off for TX and off for RX.
br0: port 1(eth0) entering learning state
br0: topology change detected, propagating
br0: port 1(eth0) entering forwarding state
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
