**** BEGIN LOGGING AT Sat Jun 07 02:59:59 2014 Jun 07 03:27:04 <5EXAA8SU8> build #534 of ar71xx is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx/builds/534 Jun 07 03:54:22 <5EXAA8SU8> build #186 of mxs is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/mxs/builds/186 Jun 07 04:05:30 <5EXAA8SU8> build #558 of xburst is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/xburst/builds/558 Jun 07 04:20:45 <5EXAA8SU8> build #545 of ixp4xx is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/ixp4xx/builds/545 Jun 07 06:28:46 <5EXAA8SU8> build #465 of mpc52xx is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/mpc52xx/builds/465 Jun 07 06:31:57 <5EXAA8SU8> build #586 of ar7 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/ar7/builds/586 Jun 07 06:43:03 looks like sysupgrade config saving is broken on WRT54GS v1.0 Jun 07 06:43:25 'sysupgrade' leads to broken boot (have to reflash using tftp), 'sysupgrade -n' is ok but obviously resets configuration Jun 07 06:57:40 looks a lot like https://dev.openwrt.org/ticket/8960 Jun 07 07:00:08 hmm.. target/linux/brcm47xx/base-files/etc/uci-defaults/09_fix_crc contains 'mtd fixtrx firmware' Jun 07 07:00:13 but my /etc/uci-defaults is empty.. Jun 07 07:01:22 I guess incremental build doesn't notice change in target Jun 07 07:02:15 actually no that doesn't make sense, of course it does, it's a different subdir of staging_dir Jun 07 07:06:11 I don't understand why fixtrx after boot though. if the system booted, the CRC must be correct? seems to make more sense to do it after 'mtd write', as suggested in the bug report Jun 07 07:07:10 <5EXAA8SU8> build #622 of lantiq is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/lantiq/builds/622 Jun 07 07:14:59 I guess https://dev.openwrt.org/changeset/32866 attempts to do this trx fixup after 'mtd write -j' Jun 07 07:15:02 but it doesn't seem to be working.. Jun 07 07:16:52 hmmmm also trx_fixup != mtd_fixtrx Jun 07 07:24:10 <5EXAA8SU8> build #643 of brcm47xx is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/brcm47xx/builds/643 Jun 07 08:18:59 hmm Jun 07 08:19:08 looks like mtd_fixtrx writes trx->len = erasesize Jun 07 08:19:25 which is 0x20000 on my system so the CRC only covers the first erase block Jun 07 08:20:51 the new trx_fixup tries to do len=0x581000 which is the full size of the trx file Jun 07 08:21:01 but I guess the CRC gets calculated wrong and this causes the boot breakage Jun 07 08:25:18 I wonder if checksum takes a long time in the bootloader, ie. is there an advantage to only checksumming first erase block Jun 07 08:48:02 morning Jun 07 08:48:12 how is configuring buildboot? Jun 07 08:48:15 *who ;) Jun 07 08:48:34 i wanted to ask for enabling "mips74k" builds for brcm47xx Jun 07 10:37:13 cyrus r41038 trunk/package/network/services/odhcpd/Makefile * odhcpd: improve DHCPv4 range defaults Jun 07 11:25:40 what stage is luci2 roughly at these days? alpha, beta? is it ready for real basic usage? Jun 07 11:36:58 ausjke: not yet Jun 07 11:37:15 ausjke: good basic, lacking support for some important configuration Jun 07 11:43:22 zajec: ok, thanks Jun 07 11:55:51 nbd r41039 trunk/package/system/procd/files/hotplug.json * procd: Fix USB cellular modems hotplug events Jun 07 12:06:34 nbd r41040 trunk/package/kernel/mac80211/Makefile * mac80211: b43: fix B43_USE_SSB dependency Jun 07 15:21:19 nbd r41041 trunk/ (10 files in 4 dirs) Jun 07 15:21:19 brcm47xx: add a "legacy" subtarget that is usable for low-end 802.11g devices like WRT54G Jun 07 15:43:19 hauke r41042 trunk/target/linux/brcm47xx/base-files/etc/init.d/netconfig * bcm47xx: use eth0 for switch name Jun 07 15:44:11 hauke r41043 trunk/target/linux/brcm47xx/mips74k/config-default * brcm47xx: mips74k: optimize kernel config Jun 07 15:50:13 eigma: i checked with a working unit, zero volts is normal for TDO Jun 07 16:16:21 nbd r41044 trunk/toolchain/ musl/Config.version musl/common.mk * musl: update to version 1.1.2 Jun 07 16:16:25 nbd r41045 trunk/package/base-files/files/etc/init.d/sysfixtime Jun 07 16:16:25 base-files: fix argument order to date in sysfixtime so that it also works with musl Jun 07 16:59:18 does arm_cortex-a9+neon_gcc-4.8-linaro_eglibc-2.19_eabi work? it failed to compile on openwrt Jun 07 16:59:37 include/gnu/stubs.h:10:29: fatal error: gnu/stubs-hard.h: No such file or directory Jun 07 17:00:10 the toolchain in openwrt trunk does not like the combination of neon+armhf Jun 07 17:00:23 when eglibc is chosen, that is Jun 07 17:02:32 hauke r41046 trunk/package/kernel/broadcom-wl/src/glue/wl_glue.c * broadcom-wl: fix build with bcma or ssb deactivated Jun 07 17:03:20 hauke r41047 trunk/package/kernel/broadcom-diag * broadcom-diag: remove broadcom-diag Jun 07 17:06:15 hauke r41048 trunk/target/linux/ brcm47xx/patches-3.10/400-arch-bcm47xx.patch brcm47xx/patches-3.10/820-wgt634u-nvram-fix.patch * brcm47xx: remove old gpio and nvram interfaces Jun 07 17:07:42 DonkeyHotei: I saw your message, I don't know what to suggest though, sorry.. Jun 07 17:23:08 nbd r41049 trunk/target/linux/ brcm47xx/Makefile brcm47xx/legacy/target.mk * brcm47xx: move the low_mem feature flag to the legacy subtarget Jun 07 17:28:21 Hauke: cleaning, hooray! :) Jun 07 17:30:15 zajec: this is my current compiler optimisation patch: http://pastebin.com/QfXumXCt Jun 07 17:30:56 i have a custom feed that overrides an existing PKG_NAME, but it does not show up under menuconfig unless I changed it to a different PKG_NAME, even after I tried feeds install -p custom Jun 07 17:31:39 can I set my feed to have higher preference than an existing package? Jun 07 17:35:37 Hauke: i've patches for generating images Jun 07 17:35:42 Hauke: let me send them Jun 07 17:36:02 Hauke: will you review/apply them? Jun 07 17:36:06 please :) Jun 07 17:36:15 I could put my custom feed at the top of feeds.conf.default, however it will generate lots of warning as : package/Makefile:160: warning: overriding commands for target `package/live/dist' Jun 07 17:36:48 package/Makefile:160 is $(eval $(call subdir,$(curdir))) Jun 07 17:37:12 somehow the makefile detects an existing package with the same name? Jun 07 17:37:40 hauke r41050 trunk/ (5 files in 5 dirs) * brcm47xx: activate some compiler optimizations for 74K CPUs Jun 07 17:38:27 <5EXAA8SU8> build #633 of atheros is complete: Failure [failed svn compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/atheros/builds/633 Jun 07 17:38:28 Hauke: does this decrease size in some more visible way? Jun 07 17:38:41 zajec: no not really Jun 07 17:39:31 <5EXAA8SU8> build #523 of au1000 is complete: Failure [failed svn compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/au1000/builds/523 Jun 07 17:40:16 <5EXAA8SU8> build #557 of sibyte is complete: Failure [failed shell shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/sibyte/builds/557 Jun 07 17:40:24 <5EXAA8SU8> build #623 of lantiq is complete: Failure [failed svn compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/lantiq/builds/623 Jun 07 17:40:35 <5EXAA8SU8> build #495 of iop32x is complete: Failure [failed svn compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/iop32x/builds/495 Jun 07 17:41:28 <5EXAA8SU8> build #177 of mvebu is complete: Failure [failed svn compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/mvebu/builds/177 Jun 07 17:41:39 <5EXAA8SU8> build #588 of rb532 is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/rb532/builds/588 Jun 07 17:41:40 <5EXAA8SU8> build #482 of gemini is complete: Failure [failed svn compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/gemini/builds/482 Jun 07 17:42:14 <5EXAA8SU8> build #588 of ppc44x is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/ppc44x/builds/588 Jun 07 17:42:33 <5EXAA8SU8> build #298 of mpc85xx is complete: Failure [failed svn compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/mpc85xx/builds/298 Jun 07 17:42:45 <5EXAA8SU8> build #487 of adm5120 is complete: Failure [failed svn compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/adm5120/builds/487 Jun 07 17:43:37 <5EXAA8SU8> build #100 of sunxi is complete: Failure [failed svn compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/sunxi/builds/100 Jun 07 17:43:49 <5EXAA8SU8> build #445 of octeon is complete: Failure [failed svn compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/octeon/builds/445 Jun 07 17:44:42 <5EXAA8SU8> build #83 of pxa is complete: Failure [failed svn compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/pxa/builds/83 Jun 07 17:44:54 <5EXAA8SU8> build #86 of cns21xx is complete: Failure [failed svn compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/cns21xx/builds/86 Jun 07 17:45:46 <5EXAA8SU8> build #84 of mpc83xx is complete: Failure [failed svn compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/mpc83xx/builds/84 Jun 07 17:45:58 <5EXAA8SU8> build #85 of bcm53xx is complete: Failure [failed svn compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/bcm53xx/builds/85 Jun 07 17:46:50 <5EXAA8SU8> build #83 of brcm2708 is complete: Failure [failed svn compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/brcm2708/builds/83 Jun 07 17:47:03 <5EXAA8SU8> build #85 of realview is complete: Failure [failed svn compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/realview/builds/85 Jun 07 17:47:54 <5EXAA8SU8> build #82 of omap is complete: Failure [failed svn compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/omap/builds/82 Jun 07 17:48:07 <5EXAA8SU8> build #83 of adm8668 is complete: Failure [failed svn compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/adm8668/builds/83 Jun 07 17:48:58 <5EXAA8SU8> build #83 of malta is complete: Failure [failed svn compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/malta/builds/83 Jun 07 17:49:11 <5EXAA8SU8> build #83 of cns3xxx is complete: Failure [failed svn compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/cns3xxx/builds/83 Jun 07 17:50:02 <5EXAA8SU8> build #84 of x86_64 is complete: Failure [failed svn compile_9] Build details are at http://buildbot.openwrt.org:8010/builders/x86_64/builds/84 Jun 07 17:56:45 Hauke: it should be OK to move some devices firmware to be based on mips74k subtarget, right? Jun 07 17:56:51 (just asking to be sure) Jun 07 17:56:58 yes Jun 07 17:57:09 thanks :0 Jun 07 18:10:07 any way to override missing package dependencies in IB? seeing a few postinst failures as well Jun 07 18:15:59 Hauke: i think we'll soon end with "generic" being used for tg3 devices only (now nbd added "legacy" subtarget) Jun 07 18:16:20 Hauke: so it does not make sense to use "generic" (with ssb & bcma) for ssb devices with tg3 Jun 07 18:16:32 Hauke: should we make another subtarget for ssb devices with tg3? Jun 07 18:16:48 Hauke: or should we extend "legacy" to include tg3 as well? Jun 07 18:17:43 Hauke: in other works... should we have "legacy" (with b44 + tg3) and "mips74k" (bgmac) Jun 07 18:17:46 Hauke: or "legacy-b44", "legacy-tg3" and "mips74k"? Jun 07 18:18:09 I would not use tg3 in legacy, because it is so big Jun 07 18:18:11 Hauke: nbd complained that tg3 is biiig, and that's true Jun 07 18:18:21 Hauke: so 3 subtargets? Jun 07 18:18:32 legacy-b44, legacy-tg3 and mips74k? Jun 07 18:21:43 as i told hauke, the best choise woth tg3 SoC integrated "emulation" makes a light-version of the tg3 without all the useless "serverparts" and extra modules ;-) Jun 07 18:22:09 same way as for broadcom-wl for older and newer devices / small / full driver. Jun 07 18:23:16 Faulp3lz: that's prettty obvious ;) it's always the best to have light build without unndeeded modules ;) Jun 07 18:23:42 Faulp3lz: the thing about tg3 devices is that they are *very* similar to what nbd called "legacy" Jun 07 18:24:07 all devices using a bcm4705 have at least 32 MB of ram and most of them 8 MB flash so space is not a so big problem Jun 07 18:24:11 and they are all eol Jun 07 18:24:12 the question for me is: is a kernel tg3 module really nessassary for a brcm4704 with external b53 switch ? just for "emulation" without a real tg3 chip ? Jun 07 18:24:51 no idea what do you mean by "emulation" Jun 07 18:24:56 what is emulated and where Jun 07 18:25:01 there is a real tg3 chip in it, it is integrated into the SoC Jun 07 18:25:08 @hauke: in case you use this devices for LTE you need the space for the mbim-subsystem and buffers. more and more users uses openwrt of native LTE without the outdated ppp ;-) Jun 07 18:25:23 qmi is another bummer that needs space Jun 07 18:25:46 Hauke: yeah, tg3 based devices have some flash space, but still there is no point to use "generic" ,since they won't need "bcma" Jun 07 18:25:57 Hauke: ok, I'll add new subtarget then Jun 07 18:26:08 yes and generic would only be needed for these chips Jun 07 18:26:18 right Jun 07 18:26:21 so I am for removig generic and create a new tg3 subtarget Jun 07 18:26:33 then we have an image for every generation Jun 07 18:26:40 yup Jun 07 18:27:00 @all: i have a problem on my wrt610nV1 ONLY: see this ticket: https://dev.openwrt.org/ticket/16587 Jun 07 18:27:05 Hauke: is BCM4305 the only SoC with tg3? Jun 07 18:27:11 yes Jun 07 18:27:14 thx Jun 07 18:27:20 can someone with a device which have same cpu check the kmod-button functions ? Jun 07 18:27:47 for me works wrt54g3gv2-VF and E3000 and wrt610nV2 without any issues. 1times "pressed" / 1 times "released" Jun 07 18:28:26 i don't think there is aything like kmod-button Jun 07 18:28:28 but pressing on on a v1 modell the wps key for 1 second, there is a continous pressed/released/pressed/released thats stops usualy after 15-20 seconds from itself Jun 07 18:28:32 at least brcm47xx doesn't use it i believe Jun 07 18:28:45 NO hardware ISSUE!! all my 3 v1er have the same issue Jun 07 18:29:34 well, this still can be hardware issue Jun 07 18:29:41 just by design or sth ;) Jun 07 18:31:11 normally we get one irq when the button gets pressed and one when released Jun 07 18:31:55 zajec: i don't think we should have a legacy-tg3 target Jun 07 18:32:02 :| Jun 07 18:32:03 why? Jun 07 18:32:06 zajec: for those corner cases, the 'generic' one should work just fine Jun 07 18:32:23 nbd: what corner case we may have except for tg3? Jun 07 18:32:27 tg3 based devices are few and rare Jun 07 18:32:35 afaik Jun 07 18:32:45 i think generic will be used for tg3 devices only Jun 07 18:32:50 i don't see any other use of "generic" Jun 07 18:33:00 or people who want to use the same build across different devices Jun 07 18:33:40 well, there isn't ar71xx build that works on all devices ;) Jun 07 18:33:50 not sure if someone really cares about that Jun 07 18:34:16 zejc: see my ticket, this is exactly what is in logfile. and it triggers wlan/off the same amount i queue. Jun 07 18:34:20 either way, i don't have a strong opinion on this Jun 07 18:34:25 and brcm47xx is not my target Jun 07 18:34:35 Hauke: any thoughs? Jun 07 18:34:38 so feel free to do what you guys think is the right approach Jun 07 18:34:45 pressing the wps key very very short results in the same issues with s short loop. some times 6 loops, sometimes 30 loops Jun 07 18:34:57 hold the button pressed startet the loop, too Jun 07 18:34:59 Hauke: it's still you target... it's up to you ;) Jun 07 18:35:07 Hauke: i can agree with what u think/decide Jun 07 18:36:26 i tell this with the button, because in the old broadcom-diag this never happends the last years in this router Jun 07 18:36:32 nbd: how would the release build of brcm47xx work with many subtargets? Jun 07 18:38:05 every subtarget has to be built individually Jun 07 18:38:16 like a separate target Jun 07 18:38:20 ok Jun 07 18:38:20 found out at this moment a human workarround: pressing MINIMUM for 1 second not trigger the loop Jun 07 18:38:32 so the number of subtarget should be kept as small as possible Jun 07 18:38:36 pressing a very short moment, lets say 0,1 second (just a touch) trigger the loop Jun 07 18:39:17 when we add a new subtarget for tg3 it will just be ~10 KB smaller then the generic one removed by the not needed kernel modules or something like this Jun 07 18:39:59 or a little bit more we can get rid of bcma and nand Jun 07 18:41:56 i think i found the problem with the wps-button: Jun 07 18:42:20 when the function call wifi down in the resulting script, this wifi up/down triggers the loop Jun 07 18:43:01 so when the wps button is uses for other functions, that it works. looks like broadcom-wl interfer with the kmod-gpio or button-driver shortly Jun 07 18:44:00 that makes sense, because the presssed/released loop stops as soon, as when booth wl0 and wl1 reinitiated and are up or down finaly Jun 07 18:45:45 <5EXAA8SU8> build #634 of orion is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/634 Jun 07 18:51:35 Hauke: dropping bcma and nand can give big savings Jun 07 18:51:51 Hauke: but BCM4705 have 8 MiB flashes anyway Jun 07 18:51:56 how big? Jun 07 18:52:02 Hauke: let me check Jun 07 18:52:21 CONFIG_BCM47XX_BCMA; 3946 B Jun 07 18:52:24 CONFIG_MTD_NAND; 15938 B Jun 07 18:52:30 CONFIG_BCMA; 12572 B Jun 07 18:52:38 B43LEGACY; 44168 B Jun 07 18:52:52 bgmac; 7832 B Jun 07 18:53:00 I got these numbers some time ago Jun 07 18:53:08 they may slightly different now Jun 07 18:53:18 but more or less it looks like above Jun 07 18:53:22 bgmac and b43legecy are extra modules and can be deactivated by choosing a different profile or using the image builder Jun 07 18:53:43 so it is 30KB Jun 07 18:53:59 so should be keep "generic"? Jun 07 18:54:03 with bcma, etc. Jun 07 18:57:19 yes Jun 07 18:57:23 ok Jun 07 18:57:27 i'm fine with that Jun 07 18:57:36 and it should also build all images Jun 07 18:58:00 err Jun 07 18:58:12 what? why? Jun 07 18:58:33 why not use optimized subtargets for device-specific images?! Jun 07 18:58:39 if you want to use the same image on all devices Jun 07 18:59:03 that makes no sense Jun 07 18:59:17 openwrt-wndr3400_v2-squashfs.chk will never run on "all devices" Jun 07 18:59:18 zajec: consider the build time overhead for releases/snapshots Jun 07 18:59:19 only on one Jun 07 19:00:17 yes but building openwrt-wndr3400_v2-squashfs.chk from the generic image takes less than a secound Jun 07 19:00:41 a full build of the mips74 target takes some hours Jun 07 19:01:03 hauke: for our LTE-Router-Project, we really need this 8MB for the complete QMI and CDC/NCM/MBIM-Subsystem, which included a lot of extra modules and userspace things ;-) Jun 07 19:01:03 so the build bots will probably just build the generic image all the time Jun 07 19:01:10 <5EXAA8SU8> build #628 of cobalt is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/cobalt/builds/628 Jun 07 19:01:22 so... not a single end-user will make use of our recent optimizations?! Jun 07 19:01:49 zajec: for the mips74k it makes sense to run a separate build Jun 07 19:01:59 because of the big impact of the optimizations Jun 07 19:02:13 for the releases we will build the subtargets at least I hope so Jun 07 19:02:24 reducing a bit of bloat on devices that already have at least 8M flash and 32M RAM is not enough to justify adding another subtarget Jun 07 19:02:27 alright, that sounds better Jun 07 19:02:44 but for the legacy subtarget, reducing bloat is essential Jun 07 19:02:47 because of device constraints Jun 07 19:03:11 so there's always a tradeoff involved Jun 07 19:03:11 @nbd: mips74k works very nice now without all the tg3 things and unneeded extras, so i got a lot of extra space for things like "snmp-static" Jun 07 19:03:45 snmp is on my list of things to rewrite ;) Jun 07 19:04:03 nbd: i got lost... i think you just said that: 1) it makes sense to have separated build for mips74k 2) reducing bloat is essential for legacy Jun 07 19:04:12 mini-snmp needs a 64bit counter patch that was posted a while ago in an still open wticket Jun 07 19:04:15 so do you want to have separated builds for both: legacy and mips74k? Jun 07 19:04:23 zajec: yes Jun 07 19:04:31 but not necessarily for tg3 Jun 07 19:04:34 right now after 4GB on the interfaces you got no more traffic with mini-snmp Jun 07 19:04:36 ok :) Jun 07 19:04:42 i misunderstood sth earlier Jun 07 19:05:05 i believe Hauke meant we should use "generic" for all images Jun 07 19:05:28 generic should be functional for all images (aside from the ones where it's too big) Jun 07 19:05:35 nbd: anyway, tthat sounds great for me Jun 07 19:05:45 nbd: could you enable separated builds for mips74k, please? Jun 07 19:05:48 I think generic should build images for all devices and mips74k and legecy should build images for the devices they support Jun 07 19:05:52 nbd: do you manage buildbot? Jun 07 19:05:59 <5EXAA8SU8> build #483 of mcs814x is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/mcs814x/builds/483 Jun 07 19:06:06 Hauke: oh, wait Jun 07 19:06:10 my main goal is for routers like the MR3420 with only 4MB flash to have a minimum support for ncm/qmi, because usual "cable/dsl" is not the only usage in 2014 any more :) Jun 07 19:06:20 Hauke: you meant "generic" building single images for all devices Jun 07 19:06:23 Hauke: that's ok! Jun 07 19:06:46 Hauke: i misunderstood you want "generic" to build images for all devices Jun 07 19:06:56 so generic would create a image for openwrt-wndr3400_v2-squashfs.chk and mips74k would create one Jun 07 19:07:29 what' the point of generating images for (e.g.) WNDR3400 twice? Jun 07 19:07:45 why not just generate it using mips74k subtarget? Jun 07 19:07:46 @nbd: in the ROOter project there is a much much smaller QMI-Script/solution instead the big solution you updated a few days ago :) Jun 07 19:08:25 Hauke: if we use separated subtarget for "mips74k", why we should want "generic" build image for WNDR3400 Jun 07 19:08:29 Faulp3lz: details? Jun 07 19:08:59 note that i still don't really care about obscure scripts hidden away in zip files somewhere Jun 07 19:09:11 i don't have time to dig through that kind of stuff myself Jun 07 19:09:36 nbd: do you manage buildbot? could you enable building "mips74k" subtarget? Jun 07 19:09:42 i don't Jun 07 19:09:46 scripts has just 17k and can replace the uqmi lib Jun 07 19:09:47 who does/ Jun 07 19:09:53 thepeople Jun 07 19:09:59 haha ;) Jun 07 19:10:15 can you contact thepeople for me, please? ;) Jun 07 19:10:33 details in this complete openwrt-extension: http://ofmodemsandmen.com/download/customFWscripts.zip Jun 07 19:10:56 there is all-in-one script in /etc/qmihelp Jun 07 19:11:04 when i first read that url, i was wondering what kind of sandmen use modems ;) Jun 07 19:11:08 that is enough to handle entire qmi things you relly need Jun 07 19:11:43 nbd this projects donīt use ppp since 2 years. it fully supports qmi/cdc/ncm and cdc-ether at all Jun 07 19:12:08 nearly ALL on the worldwide market existing modems are support with just this extension scripts Jun 07 19:12:36 it will always be updated as add on all few weeks for the latest trunk and has ne messing LucI pages as add ons, too Jun 07 19:13:20 just place the content in your compile folder "files" and you can use ALL lte devices in native mode with wirespeed on ANY hardware that has usb Jun 07 19:14:02 4MB flash is enough to have full lte/umts support and really no one need ppp for sticks any longer, it is outdated since 2 years Jun 07 19:15:08 in hotplug.d is a replacement 3g-script that overwrite tha actual one, here all the plugin/out and different sticks are detected, handled and loaded Jun 07 19:15:18 <5EXAA8SU8> build #599 of uml is complete: Failure [failed shell compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/uml/builds/599 Jun 07 19:15:55 nbd r41051 trunk/package/network/utils/uqmi/Makefile Jun 07 19:15:55 uqmi: use -ffunction-sections and --gc-sections, reduces binary size from 57k to 29k Jun 07 19:16:11 Faulp3lz: the size diff between that script and uqmi just got smaller ;) Jun 07 19:16:17 NIIIICE :) better Jun 07 19:16:41 <5EXAA8SU8> build #664 of brcm63xx is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/brcm63xx/builds/664 Jun 07 19:16:51 the scripting is quick&dirty. reason is to handly really ALL devices on the market, not just a few ones Jun 07 19:18:03 the ROOter uses only 16k in one single file to handle QMI-devices completly. libuqmi is not needed for this, that is the reason i tell you :) Jun 07 19:18:16 of course, netifd is not included in this "older" scripting Jun 07 19:19:45 more importent: in the discussion forum for the project a lof of peoples fixed some buffer and command problems for different qualcomm devices. Jun 07 19:20:16 now if only those people would start sending patches Jun 07 19:20:22 it can make sense, that you check your uqmi lib for updates comming from this small 16k scripts Jun 07 19:20:33 patches that aren't based on custom script hackery that ignores the infrastructure we're building Jun 07 19:21:02 the problem is, that this people are a small group of worldwide umts and lte users, not developers and the most people just handle "scripting" Jun 07 19:21:12 i know you problem with sending patches, really Jun 07 19:21:34 maybe you guys should find somebody that has time to clean it up a bit and turn it into patches Jun 07 19:21:40 and with this infrastructure i will help to implement this things to the native openwrt system Jun 07 19:21:48 because no matter how often you remind me of these hacks, i'm not going to do that work myself Jun 07 19:22:27 in the moment is is unusable because it overwrite many original file to make it very good work - with hard sideeffects on "normal openWrt" that uses dsl lines as backup, etc. Jun 07 19:23:17 for me it is the biggest help, when the simpled kernel drivers are up to date and working, that is the biggest help :) Jun 07 19:26:46 <5EXAA8SU8> build #194 of imx6 is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/imx6/builds/194 Jun 07 19:51:34 <5EXAA8SU8> build #568 of avr32 is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/568 Jun 07 21:50:37 nice benchmark Jun 07 21:50:51 that is a bigger gain then I thought Jun 07 21:51:05 :) Jun 07 21:52:02 nice work Jun 07 21:52:22 just broadcom-wl does not work any more Jun 07 21:52:26 yeah Jun 07 21:52:27 :/ Jun 07 21:52:31 bad closed source stuff Jun 07 21:52:46 i don't care too much... but I guess ppl do :( Jun 07 21:53:13 i wish there were anyone else caring about b43 Jun 07 21:53:37 Hauke: what would currently be recommended for a WRT350Nv1? Jun 07 21:54:33 DonkeyHotei: it's BCM4705 with BCM4321 https://wikidevi.com/wiki/Linksys_WRT350N_v1 Jun 07 21:54:45 using... PCMCIA? Jun 07 21:54:46 really? Jun 07 21:54:48 huh Jun 07 21:54:52 zajec: i'm aware Jun 07 21:55:23 just, it always required broadcom-wl before Jun 07 21:55:45 DonkeyHotei: does b43 detect this wireless chipset? Jun 07 21:56:00 i'm not sure if b43 works on BCM4321 on PCMCIA Jun 07 21:56:06 i'm actually quire curious Jun 07 21:56:23 last i checked it did not, and anyway b43 doesn't do multivap Jun 07 21:56:37 DonkeyHotei: do you maybe have a log? Jun 07 21:56:45 showing ssb/b43 failing? Jun 07 21:56:49 would be interesting for me Jun 07 21:57:22 this was ages ago, just said lp-phy was unsupported Jun 07 21:59:18 err Jun 07 21:59:22 it's BCM4321 Jun 07 21:59:26 it's N-PHY, not LP-PHY Jun 07 21:59:37 errr, that Jun 07 21:59:50 Hauke: can you please find a solution for the 74k WITH broadcom-wl for now ? dual 2,4/5GHz devices still depends on the propitary driver Jun 07 22:00:30 Faulp3lz: someone has to recompile the closed source part with the new compiler optimisations Jun 07 22:00:34 * zajec looking for someone interested in hacking b43 for 5 GHz support ;) Jun 07 22:00:47 I do not have the source code Jun 07 22:00:53 looks like with this problem all the popular E2000/E3000E4000/E4500+ router no longer have 5GHz working Jun 07 22:00:57 zajec: how far are you with 5GHz support? Jun 07 22:01:01 ...and nbd no longer makes brcm :( Jun 07 22:01:12 Hauke: i can scan Jun 07 22:01:21 Hauke: i can auth and assoc Jun 07 22:01:26 I can't get DHCP address :| Jun 07 22:01:28 it's werid Jun 07 22:01:40 when no one have the closed sources, i think its better to make an "option", not a new default from it, what do you think ? Jun 07 22:01:42 is sending data frames possible? Jun 07 22:01:54 that's whats need to be checked Jun 07 22:02:00 i need to setup some card in monitor mode Jun 07 22:02:03 and see what happens Jun 07 22:02:29 preferably a non-bcm card Jun 07 22:02:56 I tried to get brcmsmac beaconing working in 5GHz mode but it always broke down and then I gave up Jun 07 22:03:38 but brcmsmac has a very strange architecture with all these abstraction layers Jun 07 22:03:49 hehe Jun 07 22:03:50 that's true Jun 07 22:03:52 problem i see without the propitary driver: no more wlan-leds, VAPs are a problem, and the broadcom-wds is different Jun 07 22:03:55 that's a real maze ;) Jun 07 22:04:11 just to make it easy to replace the core code with more recent wl code which never happened Jun 07 22:04:16 Faulp3lz: what do you mean by WLAN LEDs? Jun 07 22:04:42 the b43 always has on some models a non working wlan-led, only the propitary one, its an old longtime problem Jun 07 22:05:14 i'd like to see bcm63xx adsl and bcm33xx cable drivers supported Jun 07 22:05:16 performance on NA chipset is another thing compared with propitary driver i foigured out by myself Jun 07 22:05:45 I think the api between the driver and the ucode changed and that broke led support Jun 07 22:05:57 brcmsmac has a different wlan led handling Jun 07 22:06:05 bcm63xx itself is not problem, but the firmware for the datadump is propitary and can not go into the public. that is unchanged since a few years :( Jun 07 22:07:14 hauke: how is status with 5GHz AN AND 3 VAPs with brcmsmac now ? good performance ? stable ? still alive after 5 days of usage without human reset ? Jun 07 22:07:37 5GHz ap mode does not work with brcmsmac Jun 07 22:07:47 vaps do not work with brmcsmac Jun 07 22:08:01 right, was my last info, and b43 itīs the same, or here no N-mode Jun 07 22:08:02 performance is bad, better than b43, but still bad Jun 07 22:08:23 so what is the solution? Jun 07 22:08:32 so there is still for the E-series and a lot of asus routers no other way as the propitary driver. Jun 07 22:08:55 revert the mips16 thing as long as someone can get a new propitary drivers. Jun 07 22:09:19 you can build a generic image and use broadcom-wl Jun 07 22:09:27 i thing a lot of people not realize this change from today and thousands of people have with actual trunk no more wireless or compile error :) Jun 07 22:10:03 better say: at this moment i MUST build such image :) lol Jun 07 23:17:40 <5EXAA8SU8> build #546 of ixp4xx is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/ixp4xx/builds/546 Jun 08 00:43:34 gcc configure: error: unrecognized option: `-mfloat-abi=softfp' Jun 08 00:43:56 however -mfloat-abi is indeed a correct ARM option, one configure errs? Jun 08 00:52:51 about new brcm47xx target.mk: https://dev.openwrt.org/ticket/16727 :) Jun 08 02:51:09 so, no armhf for openwrt? tried a few hours here Jun 08 02:53:47 just pure "soft" for floating point? not even "softfp" or "hard" for ARM A8/A9? **** ENDING LOGGING AT Sun Jun 08 02:59:59 2014