**** BEGIN LOGGING AT Tue Nov 23 02:59:57 2010 Nov 23 05:30:14 xMff: nice Nov 23 05:32:13 ? Nov 23 07:55:15 sn9: y0 Nov 23 08:04:51 blogic: there is http://focus.ti.com/lit/ug/sprue36a/sprue36a.pdf but it's grossly unclear and ambiguous on a lot of points Nov 23 08:05:38 thepeople1: pong Nov 23 08:05:57 might infineon have anything that might say what's wrong with the vlynq code? Nov 23 08:06:38 hello Nov 23 08:06:54 loswillios: any clue who else might be able to help with that? Nov 23 08:08:14 sn9: what do you want ? Nov 23 08:08:17 context ? Nov 23 08:09:19 xMff: /usr/lib/lua/luci/controller/admin/network.lua needs to extend the dnsmasq test to cover the hosts page as well Nov 23 08:09:34 blogic: there is no link after software reset, and i don't know what to do to make there be one Nov 23 08:10:13 sn9: unfortunately not Nov 23 08:11:55 sn9: Nov 23 08:11:57 mail addr ? Nov 23 08:12:16 and stupid question, where you .de based ? Nov 23 08:12:24 .us Nov 23 08:12:37 kk Nov 23 08:13:24 not .kk, .us :P Nov 23 08:13:52 :D Nov 23 08:40:08 blogic: i don't know what key you encrypted with, but mine is 615BF434 Nov 23 09:15:50 * sn9 sighs at cleartext response to encrypted mail, quoting the entire original msg Nov 23 09:22:24 sn9: kk Nov 23 09:22:48 sn9: did you get the reply ? Nov 23 09:24:00 yes, but not what you first sent, because you used his key and yours, but not mine Nov 23 09:46:23 i know Nov 23 09:46:29 icedove is annoying Nov 23 09:46:42 anyhow i need to crypt all of the other mails aswell, i will send oyu a summary Nov 23 09:46:45 :) Nov 23 09:47:08 but looks like we found a contac Nov 23 09:47:11 +t Nov 23 09:51:29 in all likelihood, if we can just have someone say what's wrong once, we'll have it "just work" in short order Nov 23 09:53:26 i know that, oyu know that and most importantly lantiq knows that :D Nov 23 09:55:21 way faster than sifting through docs and errata trying to find where the code went wrong Nov 23 09:57:22 did it work in old revs ? Nov 23 09:58:56 i do not know what makes it work or not work, whether it be old revs or different hardware Nov 23 10:00:18 the code comments in actiontec's gpl tarball say that lack of a link after software reset of the bus is an internal error Nov 23 10:24:05 hcg * r24108 /trunk/target/linux/omap35xx/gumstix/config-2.6.36: [gumstix] Remove NAND support Nov 23 10:24:54 ok Nov 23 10:27:58 blogic: have you read through that pdf? Nov 23 10:46:13 nbd: building uclibc-0.9.32 with debugging info ends up in segfaulting at boot here (x86) Nov 23 12:06:33 hcg * r24109 /trunk/target/linux/omap35xx/gumstix/target.mk: [gumstix] Bump kernel version Nov 23 12:15:18 hcg * r24110 /trunk/target/linux/omap35xx/gumstix/ (defconfig.gumstix profiles/gumstix.mk): [gumstix] Fix ext4 build Nov 23 12:27:42 sn9: no Nov 23 12:27:50 sn9: ar7 is not my building site :) Nov 23 12:27:58 i am fighting with ifxmips tapi Nov 23 12:28:15 i am writing a new userland sip app, as the old has bugs that we cant find Nov 23 12:28:18 :) Nov 23 13:31:21 blogic: presumably this new userspace app can also work with kernel modules for other hardware, right? Nov 23 13:53:22 i am testing it atm on my laptop with oss Nov 23 13:53:33 there will be a compile option to use libtapi instead Nov 23 13:53:43 does it use dahdi? Nov 23 13:53:51 so any new hw will need either a sound card binding or a libtapi binding Nov 23 13:53:59 never heard of dahdi Nov 23 13:54:13 that's the kernel framework for asterisk Nov 23 13:54:56 freeswitch uses something different as well Nov 23 13:55:56 an alternative is some form of alsa, like i guess you're doing Nov 23 13:56:40 have you looked into markus rechberger's driver for the atcom au600 usb ata? Nov 23 13:57:16 sounds like making that work with your app would be trivial Nov 23 14:05:08 blogic: when you meet with the ar7 people from infineon, could you ask them something? Nov 23 14:08:59 build #36 of brcm47xx is complete: Failure [failed compile_2] Build details are at http://tksite.gotdns.org:8010/builders/brcm47xx/builds/36 Nov 23 14:12:11 acoul * r24111 /trunk/target/linux/generic/patches-2.6.37/ (12 files): linux/generic: refresh 2.6.37 patches Nov 23 14:16:10 acoul * r24112 /trunk/target/linux/brcm47xx/patches-2.6.37/ (150-cpu_fixes.patch 920-cache-wround.patch): linux/brcm47xx: Broadcom BCM4710 does not belong in the BMIPS4KC family. Nov 23 14:20:13 acoul * r24113 /trunk/target/linux/brcm47xx/patches-2.6.37/017-MIPS-BCM47xx-bmips4kc_fix.patch: linux/brcm47xx: add missing patch on r24112 Nov 23 14:22:30 danage: hit me Nov 23 14:22:37 danage: i will write the mail tomorrow or so Nov 23 14:34:03 build #31 of ps3 is complete: Failure [failed compile_3] Build details are at http://tksite.gotdns.org:8010/builders/ps3/builds/31 Nov 23 14:37:10 build #33 of ubicom32 is complete: Failure [failed compile_4] Build details are at http://tksite.gotdns.org:8010/builders/ubicom32/builds/33 Nov 23 14:43:46 acoul * r24114 /trunk/target/linux/generic/patches-2.6.37/160-netfilter_cisco_794x_iphone.patch: linux/generic: add 2.6.37 support for the Cisco 7941/7945 IP phones: http://lkml.org/lkml/2010/11/21/219 (thank you Kevin Cernekee) Nov 23 15:05:18 build #33 of pxcab is complete: Failure [failed compile_3] Build details are at http://tksite.gotdns.org:8010/builders/pxcab/builds/33 Nov 23 16:09:45 obsy * r24115 /packages/net/transmission/ (Makefile files/transmission.init): [packages] transmission: don't convert value for config file Nov 23 16:49:05 acoul * r24116 /trunk/target/linux/brcm47xx/patches-2.6.37/ (017-MIPS-BCM47xx-bmips4kc_fix.patch 150-cpu_fixes.patch): linux/brcm47xx: sync yhe BCM4710 fix with the upcoming upstream patch. Nov 23 16:51:11 it is just me or does current trunk not display menuconfig properly (q's instead of lines, for instance)? Nov 23 16:51:38 check your TERM setting Nov 23 16:52:05 a) it hasn't changed, b) it's xterm Nov 23 16:52:42 the change in behaviour happens with new pull, but the old pull still works right Nov 23 16:53:00 which rev? Nov 23 16:54:35 24112 Nov 23 16:54:39 sorry Nov 23 16:54:42 24114 Nov 23 16:54:53 and 24113 works? Nov 23 16:55:05 don't know, haven't tried it Nov 23 16:55:44 the one I was on before was 24010 Nov 23 16:56:30 so my guess is there's a bug to find Nov 23 16:56:44 find it Nov 23 16:56:47 I just wanted to know if anyone had seen it Nov 23 16:56:59 got other fish to fry atm Nov 23 16:57:04 k Nov 23 16:58:59 hmmmm..now it works Nov 23 16:59:02 weird Nov 23 16:59:35 I didn't do anything to either term or tree Nov 23 17:00:29 maybe it only shows up when you've not been in a working menuconfig before Nov 23 17:02:54 any idea how to change from the proprietary driver the b43 without losing the rest of my config settings? Nov 23 17:02:58 *to the Nov 23 17:03:34 and without missing components Nov 23 17:06:21 ok, besides b43, cfg8011, crda, and wpad-mini do I need anything? Nov 23 17:10:51 ping nbd, xMff Nov 23 17:10:57 pong Nov 23 17:11:12 have you committed the patch to uClibc 0.9.32 ? Nov 23 17:11:31 which patch? Nov 23 17:11:50 nbd: you were talking about it yesterday, fixed a segfault problem IIRC Nov 23 17:12:17 nbd: because 0.9.31 is giving me grief Nov 23 17:12:46 ah, the ldd stuff Nov 23 17:12:57 yes Nov 23 17:21:10 ok, great, thanks Nov 23 17:24:38 flyn * r24117 /packages/ (libs/libdmapsharing/Makefile net/dmapd/Makefile): Update dmapd and libdmapsharing to new upstream versions Nov 23 19:20:42 very cool feature ext4 as default, thanks Nov 23 19:56:54 btw coreutils fails to compile on 0.9.32 due to conflicting pthread_spin_init definition. I think coreutils will need a patch, but I haven't the time to work on right at the moment. Nov 23 19:57:57 [florian]: the openwrt/mainline implementation of vlynq protocols is very incomplete, and the more i add to it and extend it, the more frustrated i get, because it STILL does not work on this device Nov 23 20:24:40 cshore * r24118 /trunk/target/linux/brcm63xx/image/Makefile: Nov 23 20:24:40 [brcm63xx] image: Limited image name put into the info1 field to 16 characters Nov 23 20:24:40 and eliminted the OpenWRT revision. This makes using the image (router) name as Nov 23 20:24:40 the board name possible, so that boards with same real boardid but different Nov 23 20:24:40 GPIOs can be detected and the correct GPIOs used. Nov 23 20:35:11 nbd: i know it's been 4 years since you looked, and even longer for ejka, but would you by any chance remember whether there is any way to hardware-reset the vlynq bus? Nov 23 20:38:04 no idea Nov 23 20:38:19 does the reference code do it? Nov 23 20:38:36 no Nov 23 20:39:19 but the docs say this: Nov 23 20:40:46 Note: Not servicing read operations results in deadlock. The only way to recover from a deadlock Nov 23 20:40:46 situation is to perform a hard reset. Read operations are typically not serviced due to read Nov 23 20:40:47 requests that are issued to a non-existent remote VLYNQ device or they are not serviced Nov 23 20:40:47 due to trying to perform reads on the VLYNQ memory map prior to establishing the link. Nov 23 20:41:35 i think that might be happening Nov 23 20:52:19 <[florian]> sn9: that does not surprise me, vlynq is not an easy protocol in the end Nov 23 20:52:37 <[florian]> sn9: hardware resets of the vlynq devices are usually external gpios Nov 23 20:52:56 are they device-specific? Nov 23 20:54:15 <[florian]> I assume there are recommandations from TI on where to wire those resets Nov 23 20:54:16 <[florian]> so no Nov 23 20:55:46 vlynq? Nov 23 20:56:08 ah. i see Nov 23 20:56:37 <[florian]> sn9: the situation you describe may very well happen indeed Nov 23 20:57:02 <[florian]> sn9: a hard reset certainly means toggling the bus reset bit from the hot perspective Nov 23 20:57:10 yes Nov 23 20:57:23 any clues how to go about that? Nov 23 20:57:59 ping loswillios Nov 23 20:58:31 hmmm....in C is there a way to test if a function exists before trying to use it? Nov 23 20:58:37 no Nov 23 20:58:48 actually there is Nov 23 20:58:52 you can use weak references Nov 23 20:59:01 <[florian]> or you use a function pointer Nov 23 20:59:20 with weak references, you don't have to mess around with constructors or initialization functions Nov 23 20:59:25 [florian]; that's what i was thinking but I'm interested in weak references Nov 23 20:59:30 you can just test if a function is linked in Nov 23 20:59:32 <[florian]> cshore: allright Nov 23 20:59:52 <[florian]> sn9: does not VLYNQ_CTRL_RESET work on the local device? Nov 23 21:00:12 nbd: how do you do a weak reference? Nov 23 21:00:13 [florian]: that's the soft reset Nov 23 21:00:25 <[florian]> sn9: I suppose there is a hard reset bit as well Nov 23 21:00:28 nbd: is that a linking thing? Nov 23 21:00:58 [florian]: hard reset would need to be external to the bus, as you said Nov 23 21:00:59 in the function declaration you add __attribute__((weak)) Nov 23 21:01:12 then referencing that function will not generate a linker error Nov 23 21:01:42 and to test if it's linked in? Nov 23 21:01:45 ah, thats an gcc extension Nov 23 21:01:51 cshore: http://www.kolpackov.net/pipermail/notes/2004-March/000006.html Nov 23 21:01:58 <[florian]> sn9: what about using ar7_device_disable on the vlynq reset bits? Nov 23 21:02:20 xMff: thanks Nov 23 21:02:50 [florian]: i think i tried that Nov 23 21:03:07 wait Nov 23 21:03:13 which bits? Nov 23 21:03:27 I'm going to use that for mtd for the fixtrx and fiximagetag (brcm47xx and brcm63xx CRC fixup stuff) Nov 23 21:03:36 <[florian]> sn9: vlynq_low_data.reset_bit Nov 23 21:05:03 <[florian]> sn9: I am not sure if it toggles the remote device reset line, or it resets the host vlynq interface Nov 23 21:26:20 [florian]: reset_bit in the code operates on (void *)KSEG1ADDR(AR7_REGS_RESET + AR7_RESET_PEREPHERIAL), but gpio_bit operates on (void __iomem *)KSEG1ADDR(AR7_REGS_GPIO + AR7_GPIO_ENABLE) Nov 23 21:26:29 what's the difference? Nov 23 21:34:17 <[florian]> sn9: I do not know Nov 23 21:35:20 nbd, xMff, [florian]: any objections to : http://openwrt.pastebin.ca/2000253 (This is a prelude to adding brcm63xx crc fixup. It's not strictly necessary, but while I'm here...) Nov 23 21:35:37 nvm Nov 23 21:35:41 forgot svn add Nov 23 21:52:25 testing brcm47xx build now with a slightly modified version of that patch Nov 23 22:01:52 cshore: http://openwrt.pastebin.ca/2000267 (broken tabs, not to be used - just for rfc ;) Nov 23 22:02:50 KanjiMonster: I did 16 char image name and removed revision btw Nov 23 22:03:43 cshore: saw that and updated my git Nov 23 22:04:06 KanjiMonster: I see you figured out how to get the known cfe address for the boardid_fixup? Nov 23 22:04:25 oh, right I forgot the + and - Nov 23 22:05:07 you don't the check for ' ' anymore...it's now null-terminated Nov 23 22:05:17 ah, ok Nov 23 22:05:20 great Nov 23 22:05:39 I just noticed I can also replace the len < 16 with a len < BOARDID_LEN Nov 23 22:05:58 right Nov 23 22:06:39 or even if there's only the boardid, then I can just copy BOARDID_LEN bytes without worrying for the length Nov 23 22:07:07 right...strncmp is enough Nov 23 22:07:16 strncpy I mean Nov 23 22:08:46 looks goo to me, but you just include the +- thing in that patch (I mean modifying the image makefile) since it's only relevant with this patch Nov 23 22:09:15 just=should Nov 23 22:09:22 yes, anything else comes in separate patches :) Nov 23 22:09:41 ah, wait Nov 23 22:09:43 err yes Nov 23 22:14:11 cshore: should I create a separate image/Build/CFE? (currently thinking about adding the optional + into the CFE call, but cant think of it any clean way) Nov 23 22:22:43 yes, and the default calls should have - in front Nov 23 22:23:19 cshore: ot here, I assume you hadn't had time to look into extroot and sysupgrade? Nov 23 22:23:21 -$(call Imaga/Limit... IIRC Nov 23 22:24:10 ok Nov 23 22:24:28 xMff: not yet....it's on my todo list....as soon as I get this darn freeswitch build to work for me (the other stuff I'm working on while I wait for the umpteenth billion build) Nov 23 22:25:01 it would be good to at least have the "do not mount after sysupgrade" feature before final Nov 23 22:25:25 xMff: ok, I'll see what I can do Nov 23 22:25:33 the rest can be pushed later Nov 23 22:26:00 ok, today or tomorrow I'll do it Nov 23 22:26:26 ty Nov 23 22:45:36 swalker: fixed Nov 23 23:28:49 ping KanjiMonster Nov 24 00:21:19 hello, anyone have any advice for me on why -fno-builtin is not used in uClibc build? it seems to be causing segfaults for me with it missing. Nov 24 00:22:10 looks like its a standard compiler arg in uClibc's makefile(s), but not openwrt, at least not x86 Nov 24 00:22:23 hm, maybe openwrt overrides something there Nov 24 00:22:25 zandbelt * r24119 /packages/net/asterisk-1.6.x/Makefile: [packages] asterisk-1.6.x upgrade to 1.6.2.14 and add app_originate Nov 24 00:22:25 i'll take a look Nov 24 00:23:29 oh, right Nov 24 00:23:33 it does override CPU_CFLAGS Nov 24 00:23:48 i'll take care of this Nov 24 00:24:50 ok, i have a "large" thread on forum where i documented what it's doing to kismet on x96 Nov 24 00:25:45 not that you need to read it, but, just fyi, https://forum.openwrt.org/viewtopic.php?id=27407 Nov 24 00:26:51 nbd: thank you! Nov 24 00:32:31 did someone try update e2fsprogs again Nov 24 00:32:40 it's hanging Nov 24 00:33:09 which is why it's been held back Nov 24 00:35:48 nope, must be uClibc that's the problem Nov 24 00:38:00 nbd * r24120 /trunk/toolchain/uClibc/Makefile: uClibc: add back a few cflags that were being overwritten, might fix a few segfauls (thx, framer99) Nov 24 00:38:08 framer99: please test with this change Nov 24 00:38:22 will report back Nov 24 00:38:34 nbd: which version of uClibc? Nov 24 00:38:45 i use 0.9.32, but this applies to any Nov 24 00:39:39 wtf...there's no ext3 Nov 24 00:40:26 ok, has ext3 gone away in the latest kernel? Nov 24 00:40:42 at least as a separate module Nov 24 00:40:50 dunno, we use ext4 now Nov 24 00:41:33 nbd: I see...well nothing wrong with e2fsprogs I think Nov 24 00:42:08 The module I was using isn't present any more (ext3) Nov 24 00:49:11 ndb: initial test with just svn up/uclibc clean and rebuild, copy over libm to my target, kismet_client no longer segfaults! thanks Nov 24 00:49:44 i'll do a full rebuild and reflash next, but it takes a while on my build machine. Nov 24 00:54:35 cshore: as far as I understood, the ext4 module now has ext2/3 support included Nov 24 00:55:27 KanjiMonster: I was suspecting that....it just took me by suprise and meant I had no filesystem module Nov 24 00:57:10 nbd: any objection to http://openwrt.pastebin.ca/2000566 ? I've built it for 47xx and 63xx, and tested mtd on 63xx and it works there (I don't have 47xx to test with) Nov 24 01:04:15 ping xMff Nov 24 01:14:11 nbd: doing the full rebuild and just realized that on that inital test, i forgot to remove -fno-buitiln from target options in menuconfig, so ... it wasn't a valid test .. sorry, will ping you agin with i get real rebuild and test done Nov 24 01:14:26 ok Nov 24 01:14:48 cshore: can you post it to the list? i don't have time to review it in detail right now Nov 24 01:15:51 ok Nov 24 01:51:28 ping nbd: Nov 24 01:58:43 pong Nov 24 01:58:59 nbd: have you used e2sprogs with uClibc 0.9.32? Nov 24 01:59:13 no Nov 24 02:00:35 nbd: hmmm....I may have to drop back a version then....it seems to hang with 0.9.32 and worked before I updated my tree Nov 24 02:00:54 try updating to latest Nov 24 02:00:56 and rebuild Nov 24 02:01:11 the cflags change might help Nov 24 02:01:23 hmmm...right...will do Nov 24 02:02:15 do I need to kill the existing toolchain with make dirclean or make distclean? Nov 24 02:02:30 make dirclean, yes Nov 24 02:02:38 or maybe just clean uclibc Nov 24 02:02:55 but dirclean just in case might be better Nov 24 02:03:56 yeah, that's what I'll do **** ENDING LOGGING AT Wed Nov 24 02:59:58 2010