**** BEGIN LOGGING AT Tue Mar 27 02:59:58 2012 Mar 27 11:13:22 nbd * r31080 /trunk/package/hostapd/ (53 files in 2 dirs): hostapd: update to 20120326 Mar 27 11:15:00 nbd * r31081 /trunk/package/ (2 files in 2 dirs): wpa_supplicant: use wext driver for hostap and madwifi Mar 27 11:18:02 nbd: did you check whether hostapdstill remains in foreground when encountering a bad ht40 config? Mar 27 11:31:03 is that why it was causing such strange issues with the improper ht40 setting? Mar 27 11:31:55 <[florian]> mystica555: what strange issues? Mar 27 11:32:03 <[florian]> there can be multiple strange issues with ht40 :) Mar 27 11:32:31 the issue whereby br-lan was in a very strange state blocking all communication over it due to an improper ht40 setting Mar 27 11:33:21 ie, that one setting made the difference between br-lan coming up properly, and being configured yet passing no data Mar 27 13:05:38 jow_laptop: it quits with error messages Mar 27 13:05:52 at least when i set channel 1, ht40- Mar 27 13:52:14 nbd * r31082 /trunk/package/madwifi/files/lib/wifi/madwifi.sh: Mar 27 13:52:14 madwifi: modify madwifi.sh to support IBSS WPA-NONE Mar 27 13:52:14 Signed-off-by: Antonio Quartulli Mar 27 13:52:20 nbd * r31083 /trunk/package/mac80211/files/lib/wifi/mac80211.sh: Mar 27 13:52:20 mac80211: modify mac80211.sh to in order to support IBSS-RSN Mar 27 13:52:20 Signed-off-by: Antonio Quartulli Mar 27 13:52:27 nbd * r31084 /trunk/ (3 files in 3 dirs): Mar 27 13:52:27 ath9k: make endian check optional Mar 27 13:52:27 Turns out it triggers on some AR71xx devices where no swapping should be done. Mar 27 13:52:27 Enable endian check for the lantiq target. Mar 27 13:57:48 <[florian]> Lekensteyn: hey there Mar 27 13:57:51 'lo Mar 27 13:58:19 can I safely try trunk or are there things to watch for on ar7? Mar 27 13:58:28 <[florian]> you can safely try it Mar 27 13:58:46 do I still have to edit the load address and kernel entry? Mar 27 13:59:03 <[florian]> since your bootloader seems to have a non-standard one, yes Mar 27 13:59:14 the kernel is loaded to address 94000000 instead of 94100000 Mar 27 13:59:17 k Mar 27 13:59:24 <[florian]> but you will need to figure out in the end how to use the standard load address Mar 27 14:00:19 nbd * r31085 /trunk/package/hostapd/files/wpa_supplicant.sh: Mar 27 14:00:20 wpa_supplicant: modify wpa_supplicant.sh in order to support IBSS-RSN/WPA-NONE Mar 27 14:00:20 Based on patch by: Antonio Quartulli Mar 27 14:00:23 <[florian]> I guess using the lzma-loader you patched to have its entry point at 0x94000000 you should be able to circumvent this Mar 27 14:00:26 nbd * r31086 /trunk/package/hostapd/files/wpa_supplicant-full.config: Mar 27 14:00:26 wpa_supplicant: add CONFIG_IBSS_RSN=y compilation option Mar 27 14:00:26 Signed-off-by: Antonio Quartulli Mar 27 14:01:20 I haven't fiddled with lzma-loader I think Mar 27 14:01:36 <[florian]> well, first get the kernel working with it's load address changed Mar 27 14:01:45 the kernel loads.. half Mar 27 14:02:04 it halts after setup_arch Mar 27 14:02:05 <[florian]> you should figure out exactly where it hangs Mar 27 14:02:13 yh, I'm doing that right now Mar 27 14:02:24 <[florian]> in mm_init_owner()? Mar 27 14:02:44 <[florian]> this might be because you have registered too much ram that's what's physically available Mar 27 14:03:06 <[florian]> if your bootloader does not have an exception vector to show the exception, it might just fail silently Mar 27 14:04:47 according to http://wiki.openwrt.org/toh/siemens/sx551 I should have 32MiB RAM Mar 27 14:04:47 <[florian]> the way the available amount of physical memory is determined is a little awkward Mar 27 14:05:10 <[florian]> because it's writing to a memory address until the read-back value does not match Mar 27 14:05:42 <[florian]> at some point I should see whether we cannot use the ram controller instead to figure out the amount of physical ram Mar 27 14:05:52 <[florian]> it might be a safer guess Mar 27 14:07:10 <[florian]> can you show me the partial bootlog of the kernel you have again? Mar 27 14:07:25 <[florian]> I would like to check whether the physical memory computation is what causes it to fail Mar 27 14:07:43 <[florian]> also, are you entirely sure you returned from setup_arch()? Mar 27 14:07:55 no it did not return Mar 27 14:08:04 <[florian]> ah that's a very valuable info! Mar 27 14:08:16 it did made to the last printk() I made Mar 27 14:08:22 but does not return Mar 27 14:08:32 anyone got any idea why the txpower my Rt3050-based devices is limited to 0 in recent trunk? Mar 27 14:08:37 Are printk() synchronous? Mar 27 14:08:42 nbd * r31087 /trunk/package/hostapd/files/wpa_supplicant.sh: wpa_supplicant: fix regressions introduced by the ibss-rsn changes Mar 27 14:08:51 <[florian]> Lekensteyn: no Mar 27 14:09:04 <[florian]> but early_printk()/putc/puts are Mar 27 14:09:09 <[florian]> because they poll the uart's register Mar 27 14:09:25 <[florian]> well, at that point, prink defaults to early_printk if I recall right Mar 27 14:09:28 <[florian]> so they are synchronous Mar 27 14:09:43 <[florian]> where in the ar7 code is it hanging? Mar 27 14:10:02 assembly or C? Mar 27 14:10:15 <[florian]> in C Mar 27 14:10:25 at the end of setup_arch Mar 27 14:10:32 arch/mips/kernel/setup.c Mar 27 14:10:59 <[florian]> which function exactly? Mar 27 14:11:05 The last printk after plat_smp_setup shows up, but in the caller (start_kernel) it does not print anything anymore Mar 27 14:11:18 want me to make a paste? Mar 27 14:11:23 <[florian]> please do Mar 27 14:12:12 <[florian]> also, if you have any modifications in arch/mips/ar7 can you show them to me as well? Mar 27 14:15:08 http://pastebin.com/qv0SSbq1 Mar 27 14:15:20 ah, the addresses have not been included Mar 27 14:17:16 svn diff: http://pastebin.com/vFqk2zzB Mar 27 14:17:47 <[florian]> +FEATURES += pci usb2 Mar 27 14:17:47 <[florian]> ? Mar 27 14:17:49 from https://forum.openwrt.org/viewtopic.php?id=33600 Mar 27 14:17:57 it has a USB port Mar 27 14:18:04 <[florian]> but we don't support the usb controller Mar 27 14:18:10 <[florian]> and it does not have pci at all Mar 27 14:18:18 <[florian]> anyway Mar 27 14:18:28 well, it made sense to me so I added it, I have not tested it Mar 27 14:18:36 it has a very small rom Mar 27 14:18:55 <[florian]> the usb controller on these ar7 SoC is not support, and is not some standard controller Mar 27 14:19:29 <[florian]> the determined memory size is correct, so it's not the issue Mar 27 14:23:13 nbd * r31088 /trunk/package/mac80211/files/lib/wifi/mac80211.sh: mac80211: add hostapd socket option to wpa_supplicant for IBSS RSN as well Mar 27 14:31:28 <[florian]> Lekensteyn: does the bootloader accept loading an elf file directly? Mar 27 14:31:55 iirc not Mar 27 14:32:02 <[florian]> flat binary only? Mar 27 14:32:16 <[florian]> if that's the case, you might want to change the kernel entry point in arch/mips/Makefile Mar 27 14:32:25 <[florian]> and objcopy the vmlinux file to produce a vmlinux.bin Mar 27 14:32:28 <[florian]> and try to load that Mar 27 14:32:39 <[florian]> I suspect there might be something wrong with the lzma-loader and the kernel Mar 27 14:32:39 what kind of file is the openwrt-ar7-squashfs.bin generated? Mar 27 14:33:26 <[florian]> it's a combined kernel+ rootfs file with no header Mar 27 14:34:35 what kind of header should I prepend to it? Mar 27 14:34:48 <[florian]> it depends on your bootloader Mar 27 14:34:53 <[florian]> how are you currenty loading your kernel Mar 27 14:34:55 <[florian]> ? Mar 27 14:35:52 I use backfire/build_dir/linux-ar7/vmlinux as code Mar 27 14:36:02 (after lzma'ing it) Mar 27 14:36:24 <[florian]> that file is actually an ELF file Mar 27 14:36:37 <[florian]> so your bootloader understand uncompressing an lzma elf file and loading it? Mar 27 14:36:53 is it? Mar 27 14:37:02 linux-x.x.x/vmlinux is an elf, yes Mar 27 14:37:20 <[florian]> so is $(KDIR)/vmlinux Mar 27 14:37:35 nope Mar 27 14:37:51 $(KDIR)/vmlinux is an ELF 32-bit LSB executable, MIPS, MIPS32 version 1 (SYSV), statically linked, with unknown capability 0xf41 = 0x756e6700, with unknown capability 0x70100 = 0x3040000, not stripped Mar 27 14:38:11 <[florian]> are you kidding me? Mar 27 14:38:24 no, sorry if it appears so Mar 27 14:38:42 <[florian]> both files are ELF kernels, one is unstripped and with all sections Mar 27 14:38:59 <[florian]> the other is stripped with all sections we think are useless Mar 27 14:41:08 <[florian]> but it should not matter for your loader Mar 27 14:42:05 <[florian]> what you are rather using is the following: Mar 27 14:42:16 <[florian]> a vmlinux binary file is produced, which is then compressed by lzma Mar 27 14:42:22 <[florian]> and then linked with the lzma-loader binary Mar 27 14:42:27 <[florian]> which is what you actually load Mar 27 14:43:03 I did not use the vmlinux.lzma file, it would not load Mar 27 14:43:19 the options in the LZMA header were different Mar 27 14:43:26 so I manually lzma the vmlinuz file Mar 27 14:43:36 *x Mar 27 14:44:24 it does load the Linux kernel, so where could it go wrong? Mar 27 14:44:33 <[florian]> it could go wrong anywhere Mar 27 14:44:47 <[florian]> what puzzles, me are these two lines: Mar 27 14:45:21 <[florian]> +LOADADDR:=0x94000000 Mar 27 14:45:21 <[florian]> +KERNEL_ENTRY:=0x94010000 Mar 27 14:45:29 otherwise it would not boot Mar 27 14:45:38 it then drops to recovery shell Mar 27 14:45:44 not even recovery mode, Mar 27 14:46:00 Lekensteyn: if sx551 has brn boot, maybe this can help you: https://dev.openwrt.org/changeset/30532 Mar 27 14:46:00 <[florian]> ok, well, that means that you are using the lzma-loader Mar 27 14:48:06 <[florian]> Delboy_: yes, looks like it should be applicable to ar7 too Mar 27 14:49:08 I'll get trunk, a moment Mar 27 14:50:45 ok, I've now trunk Mar 27 14:51:23 <[florian]> you will need to rebuild the ar7 target first Mar 27 14:51:37 yea, takes a long time for the toolchain :( Mar 27 14:51:45 <[florian]> unfortunately yeah Mar 27 15:24:45 * Lekensteyn is still waiting - at gcc/final/complete stage - i5-460M... Mar 27 15:46:14 [florian]: ok, build is ready, what do I need to apply for testing? Mar 27 16:09:33 hauke * r31089 /trunk/target/linux/brcm47xx/patches-3.2/ (13 files): brcm47xx: update usb driver to the version send for mainline kernel integartion Mar 27 16:15:08 how is LOADADDR <-> KERNEL_ENTRY supposed to work? (and what is EVA_LOADADDR?) Mar 27 16:27:46 <[florian]> LOADADDR is the adress where the kernel is loaded in RAM Mar 27 16:27:53 <[florian]> while KERNEL_ENTRY is the realy kernel entry point Mar 27 16:28:00 <[florian]> the address of the 'kernel_entry' symbol Mar 27 16:28:21 <[florian]> EVA_LOADADDR is the load address for the "eva" bootloader found on fritz!box Mar 27 16:29:13 if I make a change in target/linux/ar7/image/Makefile, do I need to run `make clean` (or even rm -rf ...) first? Mar 27 16:29:18 <[florian]> no Mar 27 16:29:24 <[florian]> you just need to re-run make target/linux/install Mar 27 16:30:51 I don't see a chance in the address (objdump) Mar 27 16:31:49 <[florian]> it can also be queried using the $(CROSS)nm Mar 27 16:32:08 94000000: 090c57ac j 0x94315eb0 Mar 27 16:32:09 <[florian]> but in general, you just want to use the one that is already defined in arch/mips/ar7/Platform Mar 27 16:32:29 the default did not seem to work on backfire Mar 27 16:32:43 the kernel is unzpped to 0x94000000 Mar 27 16:32:48 not 0x941... Mar 27 16:33:18 <[florian]> well that's the load address Mar 27 16:33:23 <[florian]> but not the entry point address Mar 27 16:33:38 I have not touched kernel_entry now Mar 27 16:33:48 just loadaddr and ramsize Mar 27 16:34:00 <[florian]> you should certainly never change kernel_entry Mar 27 16:34:13 <[florian]> and let the bootloader/intermediate handle the relocation for you Mar 27 16:35:23 flashing with modified loadaddr,ramsize now. I wonder Mar 27 16:36:02 boot shell, I guess I have to clean the kernel source somehow Mar 27 16:37:04 [florian]: Did you get your ar9341 board's usb working? Mar 27 16:37:37 <[florian]> vinceonfire: I have not touched it yet Mar 27 16:38:17 ah, `make clean` in $(KDIR) works in trunk (it failed in backfire) Mar 27 16:39:19 [florian]: if you get a minute, can you have a look at 1999 and 2000? Mar 27 16:39:54 <[florian]> philipp64|laptop should not 2000 also apply to 3.3? Mar 27 16:41:55 I am so confused. Mar 27 16:42:26 ath79_register_usb(); has already added to mach, But USB doest't work at all. Mar 27 16:42:45 <[florian]> vinceonfire: well, still you did not try blogic's advice to see the usb modules refcount Mar 27 16:45:25 I plug in a usb disk,nothing shows in ttl message. Mar 27 16:46:13 [florian]: are you sure that I shouldn't touch kernel_entry? It fails to boot (drops to menu) and the address in assembly does not seem valid (it jumps to an address after the code) Mar 27 16:47:11 ummm... good catch, also 3.3. Mar 27 16:49:38 but... 3.3 isn't in include/kernel-version.mk ... Mar 27 16:55:43 oh, nevermind... my clone is out of date by a bit. Mar 27 16:59:40 mirko * r31090 /feeds/xorg/lib/qt4/Makefile: [packages/qt4] add myself as maintainer Mar 27 16:59:54 mirko * r31091 /trunk/target/linux/xburst/patches-2.6.37/600-remove-set-but-unused-var.patch: [target/xburst] remove set but unused variable which leads into compiling errors with GCC >= 4.6.0 Mar 27 17:01:51 mirko * r31092 /packages/lang/python/patch: [packages/python] level up python to version 2.7.3rc2 - thanks to Cybjit (ticket #11157) Mar 27 17:07:34 [florian]: fixed Mar 27 17:26:32 [florian]: the only way to get booting work is changing the load address in build_dir/linux-ar7/linux-2.6.37.6/arch/mips/ar7/Platform, KERNEL_ENTRY seems to be used by the EVA loader only Mar 27 17:37:42 <[florian]> Lekensteyn: no I think you should try to use lzma-loader and have it being loaded at 0x94000000 and let the kernel entry point unchanged Mar 27 17:38:03 hauke * r31093 /trunk/target/linux/brcm47xx/patches-3.2/ (20 files): brcm47xx: update sprom patches like they are in the mainline kernel Mar 27 17:38:24 *facepalm* Mar 27 17:38:44 I had not considering pinging/ssh'ing Mar 27 17:38:56 now that I did, a ssh server is listening... ping replies... Mar 27 17:39:04 the serial has just not been setup Mar 27 17:39:06 <[florian]> so it's working, but maybe the console is on the wrong uart :) ? Mar 27 17:39:27 <[florian]> that would have been very silly from them, but why not :) Mar 27 17:39:30 I have honestly no idea how that works :O Mar 27 17:40:13 <[florian]> usually the bootloader setups the command-line, but in your case, it would be better to force it Mar 27 17:40:40 should I add console=ttyS0,119200 or sth to the command line? Mar 27 17:41:02 <[florian]> yes, 115200 is better ;) Mar 27 17:42:53 is it always ttyS0 btw? Mar 27 17:43:13 <[florian]> so far yes, it has always been on ttyS0 Mar 27 17:43:28 <[florian]> but you can allow the console to be on multiple uarts at the same time Mar 27 17:43:40 <[florian]> console=ttyS0,ttyS1,115200 or something like that should work Mar 27 17:44:08 console=ttyS0,115200 console=ttyS1,115200 according to http://www.mjmwired.net/kernel/Documentation/serial-console.txt Mar 27 17:44:27 <[florian]> indeed Mar 27 17:48:26 should default SSH keys go into trunk/target/linux/ar7/base-files/etc/dropbear/authorized_keys? Mar 27 17:54:10 Lekensteyn make files folder in your openwrt root, then mkdir -p files/etc/dropbear/ and copy files in there, Mar 27 17:54:59 and anythins in files will be build into image, just follow correct path for example files/etc/config/ i put here network and wireless stuff and build into image. Mar 27 17:55:16 okay thanks Mar 27 18:18:11 florian * r31094 /trunk/target/linux/x86/geos/target.mk: Mar 27 18:18:12 [x86] geos: add 'tc' and kmod-sched for bonding Mar 27 18:18:12 The Geos2 includes 2 ADSL+ interfaces, and as such it needs to have the TEQL scheduler for bonding. Mar 27 18:18:12 Signed-off-by: Philip Prindeville Mar 27 18:18:15 florian * r31095 /trunk/target/linux/generic/config-3.3: [kernel/3.3] add missing INET_UDP_DIAG symbol Mar 27 18:18:19 florian * r31096 /trunk/target/linux/generic/ (2 files in 2 dirs): Mar 27 18:18:19 [generic] ppp: Fix high softirq utilization with pppoa Mar 27 18:18:19 Users of the Geos platform are reporting high CPU utilization. Mar 27 18:18:19 This seems to be rooted in a problem with the TX queue restart in PPP. Mar 27 18:18:19 Signed-off-by: Philip Prindeville Mar 27 18:41:18 Is the ssh program stored in vmlinux? Mar 27 18:48:08 *facepalm 1* that was my own machine that I ssh'd. Mar 27 19:21:58 [florian]: thanks. Mar 27 19:22:13 btw, David pointed this out to me: https://dev.openwrt.org/ticket/11169 ... Mar 27 19:22:22 when is that populated with the list of interfaces? Mar 27 19:22:39 I'm thinking that if it came up after PPP was up then it would be complete. Mar 27 19:24:02 <[florian]> no idea, I am not familiar enough with luci/ppp to tell Mar 27 19:24:13 <[florian]> I have reassigned the bug to jow_laptop hopefully he can sched some light on this Mar 27 19:26:41 good, thanks. Mar 27 19:27:11 I tweaked the dnsmasq script to generate a flat file as /var/etc/dnsmasq.conf as he and I had discussed. Mar 27 19:27:33 makes debugging dnsmasq configuration issues easier than having to run "ps" and hope that none of the args got dropped... Mar 27 19:27:49 I don't even think "wide" mode for busybox's "ps" is on by default. Mar 27 19:28:00 hopefully that too will be accepted soon. Mar 27 19:28:01 <[florian]> there is still cat /proc//cmdline which allows you to debug this Mar 27 19:28:25 right, forgot about that. Mar 27 19:28:37 <[florian]> but yeah, enabling wide output by default might make sense Mar 27 19:28:47 <[florian]> can you check the busybox size difference? Mar 27 19:29:09 sure... is it just the size of /bin/busybox alone? Mar 27 19:29:09 <[florian]> I don't think it will matter much Mar 27 19:29:18 <[florian]> yes Mar 27 19:29:30 <[florian]> all applets are symlinks to busybox so that's the only thing to check Mar 27 19:30:12 ok, wasn't sure if there were .so's involved or not. Mar 27 19:30:26 <[florian]> nope, not with busybox fortunately Mar 27 19:37:31 same size. Mar 27 19:46:52 <[florian]> yeah it's already enabled by default actually Mar 27 19:51:02 florian * r31097 /packages/net/lighttpd/Makefile: (log message trimmed) Mar 27 19:51:03 [package] lighttpd: configure with OpenSSL support only if the user asks for it Mar 27 19:51:03 SSL support adds a quite large dependency to lighttpd when compiled Mar 27 19:51:03 in. On a 32 bit platform, libcrypto is roughly 1MB, to which one must Mar 27 19:51:03 add the size of libssl (roughly 250KB). This is 2 to 5 times the size Mar 27 19:51:03 of a typical lighttpd embedded installation. Mar 27 19:51:04 SSL support is only needed if one enables the SSL engine in the Mar 27 19:51:04 florian * r31098 /packages/net/wavemon/Makefile: Mar 27 19:51:05 [package] wavemon: Bump to v0.7.4 Mar 27 19:51:05 Signed-off-by: Jonathan McCrohan Mar 27 19:51:06 florian * r31099 /packages/libs/libmodbus/Makefile: Mar 27 19:51:06 [package] libmodbus: bump to 3.0.2 Mar 27 19:51:07 This patch updates libmodbus from version 2.0.3 to the latest stable Mar 27 19:51:07 release 3.0.2 Mar 27 20:00:33 juhosg * r31100 /trunk/target/linux/ramips/ (12 files in 10 dirs): Mar 27 20:00:33 ramips: rt305x: add add support for the Asus WL-330N board Mar 27 20:00:33 [juhosg: reorder several lines in order to keep things sorted Mar 27 20:00:33 alphabetically] Mar 27 20:00:33 Signed-off-by: Frédéric Leroy Mar 27 20:00:34 juhosg * r31101 /trunk/target/linux/ramips/ (3 files in 3 dirs): Mar 27 20:00:35 ramips: rt305x: build image for the DIR-615 rev D boards Mar 27 20:00:35 Patch from #10105. Mar 27 20:08:25 juhosg * r31102 /trunk/target/linux/ar71xx/files/arch/mips/ath79/ (mach-tl-wr703n.c mach-tl-wr741nd-v4.c): ar71xx: fix button polarity on TL-WR703N and TL-WR741N v4 Mar 27 20:08:26 juhosg * r31103 /trunk/target/linux/ar71xx/config-3.3: ar71xx: sync 3.3 config Mar 27 20:08:29 juhosg * r31104 /trunk/target/linux/ar71xx/ (config-3.2 config-3.3): ar71xx: disable CONFIG_{I2C,SPI}_GPIO Mar 27 20:08:34 juhosg * r31105 /trunk/package/kernel/modules/ (001-depends.mk other.mk): package/kernel: allow to build RTC modules for 3.x Mar 27 20:08:34 juhosg * r31107 /trunk/target/linux/ar71xx/ (Makefile base-files/etc/diag.sh config-3.2 config-3.3): ar71xx: use modules for LED triggers Mar 27 20:08:36 juhosg * r31108 /trunk/target/linux/ar71xx/files/arch/mips/ath79/ (8 files): (log message trimmed) Mar 27 20:08:36 ar71xx: remove the built-in MTD maps of several boards Mar 27 20:08:36 We are passing the MTD layout via the kernel command line, so Mar 27 20:08:36 it makes no sense to duplicate it in mach-* files. The patch Mar 27 20:08:36 removes the built-in MTD maps of the following boards: Mar 27 20:08:37 * AP113 Mar 27 20:08:37 * ALFA N2/N5 Mar 27 20:08:38 juhosg * r31109 /trunk/target/linux/ar71xx/image/Makefile: ar71xx: reclaim the 'user_property' partition on WHR-* boards Mar 27 20:08:38 juhosg * r31106 /trunk/package/kernel/modules/leds.mk: package/kernel: create packages for the LED Timer/Default ON triggers Mar 27 20:08:40 juhosg * r31110 /trunk/target/linux/ar71xx/ (files/arch/mips/ath79/mach-zcn-1523h.c image/Makefile): Mar 27 20:08:40 ar71xx: remove the built-in MTD map of the Zcomax devices Mar 27 20:08:40 Pass the mtd_layout via the kernel command line instead. Mar 27 20:08:41 juhosg * r31111 /trunk/target/linux/ar71xx/ (files/arch/mips/ath79/mach-pb92.c image/Makefile): Mar 27 20:08:41 ar71xx: remove the built-in MTD map of the PB92 board Mar 27 20:08:53 juhosg * r31118 /trunk/target/linux/ar71xx/ (11 files in 3 dirs): (log message trimmed) Mar 27 20:08:53 ar71xx: boost SPI flash read performance Mar 27 20:08:53 mtd_speedtest results: Mar 27 20:08:54 page read speed Mar 27 20:08:54 old new delta Mar 27 20:08:55 DB120 929 KiB/s 2597 KiB/s +179.55% Mar 27 20:08:55 TL-WR1043ND v1 754 KiB/s 2166 KiB/s +187.27% Mar 27 20:20:29 where does the network config file go from the base-files package? in the build and staging dirs I only see the system config file present... Mar 27 20:29:58 wow, some wr1043nd loving , thx Mar 27 21:45:38 jow_laptop: ping Mar 27 23:56:54 hmm... I see there are hotplug.d/ files in package/ppp/files.old/ but not in package/ppp/files/ ... why is that? **** ENDING LOGGING AT Wed Mar 28 02:59:58 2012