**** BEGIN LOGGING AT Sun Jan 23 02:59:57 2011 Jan 23 03:15:18 nbd: ping Jan 23 03:16:05 well, if Felix isn't around, perhaps someone else can tell me... if I bump libnl, what do I need to do to test wprobe* ? Jan 23 03:32:07 nbd: felix, I tried to build wprobe-export, but it failed. I don't think it was related to the libnl change, from the error messages. Jan 23 06:52:02 swalker * r25069 /packages/net/tor/Makefile: [packages] tor: update to 0.2.1.29 (CVE-2011-0427) Jan 23 06:52:39 swalker * r25070 /packages/net/tor-alpha/ (Makefile patches/001-torrc.patch): [packages] tor-alpha: update to 0.2.2.21-alpha (CVE-2011-0427), refresh patches Jan 23 07:03:33 hmm. sysupgrade doesn't seem to be respecting -n on atheros (reflashing a ubiquiti nanastation5) Jan 23 07:15:15 i *don't* want to save config! Jan 23 07:15:40 and yet, there are a bunch of unwanted files in /overlay Jan 23 07:15:54 wtf? Jan 23 08:56:30 philipp64|laptop: pong Jan 23 08:56:35 why do you want to bump libnl Jan 23 08:56:39 yup Jan 23 08:56:46 all of our core packages use libnl-tiny? Jan 23 08:57:15 swalker sent me a list of all packages that are seriously out of date... libnl was one. Jan 23 08:57:56 also, I'm working with Karl H. to add new functionailty to ATM. Jan 23 08:58:01 ah, ok Jan 23 08:58:23 you can bump the package Jan 23 08:58:36 so netlink signaling on DSL... and carrier indication in PPP Jan 23 08:58:49 libnl-tiny has its own set of header files anyway Jan 23 08:59:08 that is, DSL will report link state via netlink. Jan 23 08:59:25 like is currently done for Wifi. Jan 23 08:59:41 sounds good Jan 23 09:00:43 what's the size difference between libnl and libnl-tiny? Jan 23 09:01:35 libnl-tiny is api compatible to libnl 2.0, but provides only a subset (only generic netlink) Jan 23 09:01:45 and i made lots of changes to reduce the size of the library even more Jan 23 09:02:04 libnl was too bloated Jan 23 09:02:25 If libnl is present, can we link with that? Jan 23 09:02:35 yes Jan 23 09:02:58 if you only use genl, you can probably also use libnl-tiny without modifying the source code Jan 23 09:03:08 what would need to change to make the Makefiles be conditional? Jan 23 09:03:23 look at what hostapd, crda, etc. do Jan 23 09:03:32 ok. Jan 23 09:03:34 it's just a different include path and a different library to link against Jan 23 09:18:18 so, because packages are optional and can be uninstalled, I should only test for ifeq ($(CONFIG_PACKAGE_libnl),y) right? not: ifneq ($(CONFIG_PACKAGE_libnl),) ... Jan 23 09:19:39 what do you want to use this check for? Jan 23 09:35:18 so, that's the right way to flash a new image on ubnt ns5 to *not* retain the old config? Jan 23 09:35:26 so what's* Jan 23 09:36:24 normally sysupgrade -n should be enough Jan 23 09:36:25 nbd: if the user has selected CONFIG_PACKAGE_libnl, then we should link against that... otherwise, we should link against libnl-tiny. Jan 23 09:36:53 philipp64|laptop: better make this config option explicit Jan 23 09:36:57 nbd: okay, i'll look harder at why it doesn't seem to be doing the right thing Jan 23 09:37:16 russell--: can you show me the output of sysupgrade -v -n? Jan 23 09:45:21 nbd: i'll have to run it again ... hang on Jan 23 09:53:23 nbd: http://paste.openwrt.org/f7225b63e Jan 23 09:55:51 after the sysupgrade, when it comes back up, i have 204k of data in /overlay Jan 23 09:56:50 it does not appear to be saving the config Jan 23 09:57:05 the issue is likely to be a different one Jan 23 09:57:19 probably the end-of-filesystem marker does not end up in the right place Jan 23 09:58:29 is there a way to remediate? Jan 23 09:58:50 like dd if=/dev/zero over /overlay or something similar? Jan 23 09:59:29 /overlay is mounted from /dev/mtdblock3 Jan 23 10:00:08 what's the eraseblock size of your flash? Jan 23 10:00:24 i have to leave now, will look into this later Jan 23 10:00:32 okay, thanks Jan 23 10:00:46 (fwiw, it's a 4M flash device) Jan 23 10:22:14 nbd: here are some details from the device: http://paste.openwrt.org/f4b0de349 Jan 23 10:29:43 nbd: I'll follow this up in the morning... http://fpaste.org/kA5s/ Jan 23 12:09:12 blogic * r25071 /trunk/package/uboot-lantiq/ (26 files in 6 dirs): [uboot-lantiq] add support for arv4518 and arv752DWP22 boards Jan 23 12:09:12 blogic * r25072 /trunk/target/linux/lantiq/ (9 files in 3 dirs): (log message trimmed) Jan 23 12:09:12 [lantiq] Jan 23 12:09:12 * fix pci support for more than 1 device Jan 23 12:09:12 * fixes ioport mappings Jan 23 12:09:13 * adds support for arcor easybox 803/arv752DWP22 Jan 23 12:09:14 * gpio direction was not set properly during a gpio_request() Jan 23 12:09:14 * usb compile warning Jan 23 12:12:47 blogic * r25073 /trunk/target/linux/lantiq/patches/260-pci.patch: [lantiq] remove deadcode from [25072] Jan 23 12:25:38 blogic: will the lantiq target work on Samsung G3010 ifxmips? Jan 23 12:25:59 hmmm Jan 23 12:26:06 was that danbe of amazon ? Jan 23 12:26:14 yes Jan 23 12:26:20 whoich Jan 23 12:26:21 ? Jan 23 12:26:27 danube or amazon ? Jan 23 12:27:19 anyhow Jan 23 12:27:25 lantiq will support samazon Jan 23 12:27:31 oh, I think danube http://wiki.openwrt.org/oldwiki/openwrtdocs/hardware/samsung/smt_g3010#hardware.info Jan 23 12:27:45 not sure though Jan 23 12:27:53 amaozon Jan 23 12:28:03 yes Jan 23 12:28:13 i am planning to merge amazon -> lantiq Jan 23 12:28:17 i did amazon_se last week Jan 23 12:28:24 need to only commit it in owrt Jan 23 12:28:36 cool Jan 23 12:28:41 but first i need to fix some machtypes and remove ifxmips Jan 23 12:28:57 and update owsip to make sip work for everyone Jan 23 12:51:26 blogic * r25074 /trunk/target/linux/lantiq/ (image/Makefile patches/400-mach-arv45xx.patch): [lantiq] adds machtype for ARV7518PW Jan 23 13:12:05 updated openwrt/upstream, https://home.comcast.net/~sdwalker/uscan/index.html Jan 23 13:42:40 nbd: seeing some werid stuff on wrt160nl in sta mode (r25061): Jan 23 13:42:50 1. console outputs this: ath: Could not stop RX, we could be confusing the DMA engine when we start RX up ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020 Jan 23 13:43:16 and but it still seems to associate with unsecured connections Jan 23 13:43:49 2. it does not associate with psk2 APs Jan 23 13:44:27 this possibly a fix? https://dev.openwrt.org/ticket/7973 Jan 23 13:48:00 seeing same console outputs for the failed psk2 setup Jan 23 14:03:42 build #55 of etrax is complete: Failure [failed compile_3] Build details are at http://tksite.gotdns.org:8010/builders/etrax/builds/55 Jan 23 15:11:26 hi Jan 23 15:12:40 stupid question but what is the best way to check out a specific svn version of the packages when I do scripts/feeds update; scripts/feeds install -a Jan 23 15:12:41 ? Jan 23 15:23:16 add @rev to the feed urls in feeds.conf Jan 23 15:23:42 merci! Jan 23 15:31:48 works Jan 23 15:33:06 i noticed a strange bug in libnet: include/libnet.h line 117 Jan 23 15:33:09 #define 1 Jan 23 15:33:19 which is of course, a buildbreak Jan 23 15:33:39 This seems to be the case with the current packages feed Jan 23 15:33:58 just cross-checking now if it also happens in the older version (known to work) Jan 23 16:06:25 xMff: did you see this: http://en.qi-hardware.com/irclogs/latest.log.html#t09:58, do you think this will work? Jan 23 16:07:40 xiangfu: you mean the ncurses depend? Jan 23 16:08:00 xMff: yes. Jan 23 16:08:07 yes Jan 23 16:08:40 xMff: ok. then how about the idea on libiconv? Jan 23 16:08:54 though I'd stuff -lncurses into a variable that is either empty or with -lncurses and then just use the var Jan 23 16:10:24 xiangfu: for iconv full we thought about putting each variant into a separate dir again and then provide symbolic macros like $(ICONV_DEPENDS), $(ICONV_CFLAGS), $(ICONV_LDFLAGS) Jan 23 16:10:41 xiangfu: but that is a bit of work I haven't started yet Jan 23 16:12:03 xiangfu: but I am open to other suggestions Jan 23 16:12:17 tbh I don't fully get the idea from the log Jan 23 16:12:28 can you explain some more? Jan 23 16:16:50 xMff: it's like: we have three packages : iconv-full iconv-stub iconv, both -full and -stub install to the same place, no "/usr/lib/libiconv-full" any more, Jan 23 16:17:53 then 'libiconv' is just an empty "SHELL" for other packages who have depends on the name of "libiconv" Jan 23 16:19:00 then the 'empty shell libiconv' DEPNEDS:= +CONFIG_PACKAGE_libiconv-full:libiconv-full +CONFIG_PACKAGE_libiconv-stub:libiconv-stub Jan 23 16:19:46 so we may have two line in .config CONFIG_PACKAGE_libiconv-full=y and CONFIG_PACKAGE_libiconv=y Jan 23 16:19:55 yes Jan 23 16:19:57 for build full version. Jan 23 16:20:30 I plan to test this this week, but I am slow on this. I plan to test tomorrow. Jan 23 16:20:41 I mean the new plan :) Jan 23 16:21:55 ah, now I understand Jan 23 16:22:05 you want to implement an indirection Jan 23 16:22:20 xMff: yes. Jan 23 16:22:21 program -> libiconv -> libiconv-{full,stub} Jan 23 16:22:29 xMff: correct Jan 23 16:22:56 the real solution would be to add "provides" support to openwrt Jan 23 16:23:09 opkg supports this concept but it cannot be expressed within the build system Jan 23 16:24:20 however, your idea sounds good Jan 23 16:24:32 we need to see how many build time issues arise Jan 23 16:25:05 especially due to the difference between posix iconv api and gnu style iconv api Jan 23 16:25:41 at least glib2 needs special treatment, it must get different configure args depending on the iconv variant Jan 23 16:25:42 ok. Jan 23 16:26:02 there was/is a ticket on that Jan 23 16:26:36 https://dev.openwrt.org/ticket/8594 Jan 23 16:27:08 thanks, just try to search the ticket. Jan 23 16:28:30 xMff: (I guess it report by kyak, because we have a glib2 with --with-libiconv=gnu in openwrt-packages added by kyak) Jan 23 16:28:37 yep Jan 23 16:30:16 the glib2 makefile can evaluate the config vars, something like CONFIGURE_ARGS += $(if $(CONFIG_PACKAGE_libiconv-full),--with-libiconv=gnu) should work Jan 23 16:30:59 if it turns out that this is needed in many places we should turn it into a macro Jan 23 16:31:49 luckily the most "heavy" programs go through glib2 Jan 23 16:32:10 the other iconv users are happy with both variants without needing special flags Jan 23 16:33:07 my idea was to add an include/iconv.mk similar to include/autotools.mk which provides some global facilities to deal with iconv Jan 23 16:33:48 so you can do DEPENDS:=$(ICONV_VARIANT) in your package definition and do not end up with stray dependencies Jan 23 16:34:41 for -stub the ICONV_VARIANT would be empty, thus no dep at all, for -full it would contain "libiconv-full" so that opkg gains a dependency Jan 23 16:34:47 sounds reasonable so far? Jan 23 16:35:32 packages dealing with iconv would then need an "include iconv.mk" in their Makefiles to source the convenience macros Jan 23 16:36:05 we did something comparable for python (include/python.mk) to deal with python specific operations Jan 23 16:36:28 xMff: so for -full. I must set the TARGET_LDFLAGS+= $(STAGING_DIR)/usr/lib/libiconv-full . right? Jan 23 16:36:36 yep Jan 23 16:36:50 this could be automatically done by iconv.mk Jan 23 16:37:11 so as soon as you include it, it populates your cflags, ldflags depending on .config choices Jan 23 16:37:38 this will propably cover ~90% of the cases Jan 23 16:37:51 this leaves one unresolved issue Jan 23 16:38:20 if libiconf-stub is selected and once built, its header ends up in staging/usr/include/ Jan 23 16:38:25 so it will always take precedence Jan 23 16:39:04 even if you add -I$(STAGING_DIR)/usr/lib/libiconv-full/include Jan 23 16:39:31 therfore I'd move it into a "hidden" dir again Jan 23 16:39:47 e.g. $(STAGING_DIR)/usr/lib/libiconv-stub/include Jan 23 16:40:17 downside is that we need to touch any package using iconv then, no automatisms anymore Jan 23 16:40:48 yes. Jan 23 16:41:45 if we have iconv.mk, we can build the iconv-stub and iconv-full at same time, right? do we need them two in one rootfs? Jan 23 16:42:02 yes, both can be built then Jan 23 16:42:15 the -stub does not result in any actual runtime file Jan 23 16:42:46 and if the dependencies are properly set (empty for -stub, libiconv-full for -full) then no dummy package is needed either Jan 23 16:45:46 in a second phase we could deal with libintl in a similar way Jan 23 16:49:36 xMff: yes. Jan 23 16:49:44 xMff: understand now. thanks. Jan 23 16:58:55 hi Jan 23 16:58:59 OutBackDingo: ping Jan 23 16:59:13 tripolar: pong Jan 23 16:59:21 OutBackDingo sent you the patch again Jan 23 16:59:30 ok cool thanks Jan 23 16:59:36 the one i sent you last time was the one i sent some months ago to the ml Jan 23 16:59:54 OutBackDingo: please apply it and tell me if it works Jan 23 17:00:03 will do Jan 23 18:23:55 nbd: hi, it seems that 560-mac80211_wds_sta_fix.patch needs to be renewed for wireless-testing 2010-01-19. it produces an error while compiling. Jan 23 18:25:48 tornado: no, you need to remove the patch from your local tree Jan 23 18:26:01 it was merged upstream, that's why it's not in package/mac80211/patches in svn anymore Jan 23 18:26:53 nbd: oh sorry for my mistake Jan 23 19:13:59 blogic: ping Jan 23 19:16:46 blogic * r25075 /trunk/target/linux/lantiq/ (5 files in 2 dirs): Jan 23 19:16:46 [lantiq] Jan 23 19:16:46 * adds arv4518pw mach support Jan 23 19:16:46 * fixes arv4525pw Jan 23 19:16:46 * make sure all mach names have the same style Jan 23 19:16:46 * move code around Jan 23 19:16:52 yes ? Jan 23 19:22:22 did you get a chance to try the br2684ctl stuff? Jan 23 19:30:46 jow * r25076 /packages/net/samba3/Makefile: [packages] samba3: mark conffiles Jan 23 19:31:10 jow * r25077 /packages/net/ntpclient/Makefile: [packages] ntpclient: mark conffile Jan 23 19:38:59 blogic: guess you're still testing it. Jan 23 19:39:42 not started Jan 23 19:39:46 sunday and stuff :) Jan 23 19:44:09 tatorttime!!! Jan 23 20:13:49 hmmm... strange buildbreak in zlib Jan 23 20:14:14 http://pastebin.com/1vNksiXx ... did anybody encounter this already (before I dig into the details)? Jan 23 20:19:37 nbd: got a minute? Jan 23 20:21:45 yes Jan 23 20:23:26 did you look at the paste I put up last night? Jan 23 20:24:37 which one? Jan 23 20:25:03 http://fpaste.org/4uyY/ Jan 23 20:27:16 your modifications do not do any rebuild checks if the setting changed Jan 23 20:27:29 also i think depending on the libnl/libnl-tiny package selection is a bad idea Jan 23 20:27:42 because it creates unexpected side effects Jan 23 20:28:06 well, maybe, but more to the point it fails to link. Jan 23 20:28:21 also, you cannot use values that depend on .config in the DEPENDS field Jan 23 20:29:13 then I don't know how to do it. Jan 23 20:29:39 do you really need libnl at the moment? Jan 23 20:30:04 for the netlink development stuff, yeah. Jan 23 20:30:14 what kind of netlink interface does this stuff use? Jan 23 20:30:34 any patches that i can look at that implement the kernel side? Jan 23 20:30:57 i'd suggest leaving everything that uses libnl-tiny alone for now Jan 23 20:31:02 Karl is working on it. Jan 23 20:31:45 libnl-tiny and libnl can coexist on the same system Jan 23 20:31:49 and libnl-tiny is not very big Jan 23 20:31:57 so it's not a big deal right now Jan 23 20:32:10 and once the atm stuff with the netlink interface is in, i could add the missing pieces to libnl-tiny Jan 23 20:32:15 so you wouldn't need libnl anymore Jan 23 20:34:59 why not just patch libnl's Makefiles to build two libraries, not one? like libnl-core and libnl-rest? Jan 23 20:35:15 that way we don't have to keep patching it when we do a version bump... Jan 23 20:35:34 you don't like patches, do you? ;) Jan 23 20:36:24 I don't like maintaining them or being a burden when doing version bumps. Jan 23 20:36:56 philipp64|laptop: my size reductions aren't just a library split Jan 23 20:37:13 i reworked a lot of the code to make it even smaller Jan 23 20:37:29 can that be upstreamed? Jan 23 20:38:03 probably not Jan 23 20:38:47 libnl was designed in a way that the data structures would not be visible for users of the libraries Jan 23 20:38:51 i changed that Jan 23 20:39:05 so that i could make lots of tiny functions inline Jan 23 20:39:14 helps the compiler generate better code Jan 23 20:42:23 but it means you can never have a fixed ABI. Jan 23 20:43:25 i'm not really interested in a fixed ABI Jan 23 20:44:33 all i need is API compatibility to libnl-2.0 Jan 23 20:44:55 a fixed ABI is an underpinning to being able to update an installed, running system. Jan 23 20:45:05 openwrt systems aren't meant to be upgraded like regular linux distros Jan 23 20:45:14 otherwise, you can't install individual packages... you have to install everything. Jan 23 20:45:48 question: if I have a files/etc/resolv.conf file which I want to have installed by default.... Jan 23 20:45:52 openwrt systems are upgraded via sysupgrade, not opkg Jan 23 20:45:53 there seems to be a problem: Jan 23 20:46:10 make[3]: [package/rootfs-prepare] Error 2 (ignored) Jan 23 20:46:12 cp: not writing through dangling symlink `/media/SeagateSWRaid0V/mangroveOS/seed/trunk/backfire.trunk/build_dir/target-i386_uClibc-0.9.30.1/root-x86/./etc/resolv.conf' Jan 23 20:46:14 make[3]: *** [package/rootfs-prepare] Error 1 Jan 23 20:47:30 of course, resolv.conf -> /tmp/resolv.conf Jan 23 20:47:55 so, what is the best way to pre-install a resolv.conf file in every image that I make ? Jan 23 20:51:20 aroscha2: https://dev.openwrt.org/attachment/ticket/3508/buildroot--copy-over-symlinks Jan 23 20:51:26 might be a GNUism Jan 23 20:52:00 I mena the proposed patch Jan 23 20:52:03 i'm working on a different patch now Jan 23 20:52:10 one that doesn't depend on GNU stuff Jan 23 20:53:49 i will try, thx xMff Jan 23 20:54:28 aahhh the next issue :) Jan 23 20:54:31 haha Jan 23 20:54:46 ettercap buildbreak Jan 23 20:54:54 again? Jan 23 20:55:01 ec_plugins.c: In function 'plugin_filter': Jan 23 20:55:03 ec_plugins.c:134: error: expected ')' before 'LT_MODULE_EXT' Jan 23 20:55:05 make[6]: *** [ettercap-ec_plugins.o] Error 1 Jan 23 20:55:07 no, something else Jan 23 20:55:10 I found out what the problem is Jan 23 20:55:26 if you go to package/ettercap/src/ec_cplugins.c Jan 23 20:55:43 you will see that the thing before LT_MODULE_EXT is not #defined Jan 23 20:56:05 because it is only defined in a windows mingw #ifdef'ed section Jan 23 20:56:08 backfire? Jan 23 20:56:13 yup Jan 23 20:56:16 backfire trunk Jan 23 20:56:25 yeah ok. I need to merge the autofail stuff Jan 23 20:56:52 well, I guess the ettercap package should be fixed Jan 23 20:56:58 but that is easy Jan 23 20:57:20 talk less, patch more Jan 23 20:57:27 ;-) Jan 23 20:59:20 nbd: can we add a script to the build process that spots inconsistencies in the .config file versus a kmod you might be trying to build? Jan 23 20:59:27 nbd * r25078 /trunk/package/Makefile: allow files/ to overwrite existing symlinks (fixes #3508) Jan 23 20:59:36 philipp64|laptop: what kind of inconsistencies? Jan 23 21:00:33 let's say your config-default turns on a symbol that is mutually exclusive with a DEPENDS of a kmod... as one example. Jan 23 21:00:54 or you're trying to explicitly build a kmod, but not all of it's dependencies have been turned on. Jan 23 21:02:30 do you have any specific examples for both cases? Jan 23 21:03:42 not right now because after many hours of staring at it I eventually worked it out in both cases... :-) Jan 23 21:03:47 nbd * r25079 /branches/backfire/package/Makefile: backport files/ symlink overwrite fix from r25078 Jan 23 21:03:55 let me know when you have specific examples Jan 23 21:04:05 then we'll discuss this further Jan 23 21:04:28 aroscha2: symlink issue fixed now Jan 23 21:04:30 I think part of it might also have had to do with the fact that if you touch a config-default or a Makefile or a *.mk, that doesn't cause "package/index" to be rebuilt. Jan 23 21:04:38 nbd: thx.... Jan 23 21:04:39 maybe it should. Jan 23 21:05:41 nbd: how easy would it be to change that? Jan 23 21:06:36 config-* is currently not used as input for the menuconfig data used by kmod-* Jan 23 21:10:37 philipp64|laptop: hard Jan 23 21:10:42 to change Jan 23 21:11:54 ahh... so developers just have to remember make package/index... Jan 23 21:15:54 i don't think you mean package/index Jan 23 21:16:08 because that just generates the index in bin/$(TARGET)/packages Jan 23 21:21:40 hmm i hate that : make -r world: build failed. Please re-run make with V=99 to see what's going on Jan 23 21:22:05 Epsylon3: that's why I always build with V=99, just in case ;) Jan 23 21:22:08 i think a 2>errors.log could be used to logs errors Jan 23 21:22:29 in the default case (not V=) Jan 23 21:23:01 make V=99 2>warnings.txt Jan 23 21:23:21 i have make that... for the V99, but... Jan 23 22:55:38 Hi. I am looking for a suitable USB-eJTAG adaptor to use on broadcom routers. I was wondering if someone could provide advice on which adaptors they are using Jan 23 23:07:32 good question :) in fact never tested the jtag Jan 23 23:07:45 i ve one somewhere... got from micro4u Jan 23 23:08:14 http://www.micro4you.com/store/open-arm-jtag-usb/prod_100.html Jan 23 23:09:08 this one is cheaper : http://www.micro4you.com/store/colink-arm-jtag-usb/prod_111.html Jan 23 23:10:20 but maybe not compatible Jan 23 23:10:43 hardware is one thing, software is the other Jan 23 23:11:03 The issue that I am finding for the ones I have tested here is that there is no support in the Open Source packages that are available Jan 23 23:11:56 I was hoping that someone had something working. Jan 23 23:12:04 there is software to talk to the jtag adapter, and then the software to talk to the target board Jan 23 23:12:24 in fact jtag is is used to debug the cpu Jan 23 23:12:27 in asm Jan 23 23:12:34 you can step over code Jan 23 23:12:50 or in c with the good editor Jan 23 23:12:59 ide Jan 23 23:13:22 what do you want to do with that ? Jan 23 23:13:33 for tty, a serial to usb is faster Jan 23 23:13:48 CP2102 (5 USD only) Jan 23 23:14:08 only 3 wires, its self powered (3.3V) Jan 23 23:14:40 serial != jtag ;-) Jan 23 23:15:04 sure Jan 23 23:15:14 right now, debugging is not the priority. I would be happy to just load the firmware. I just need to load CFE for now Jan 23 23:15:20 stuffa: I was recommended this one: http://www.amontec.com/jtagkey-tiny.shtml Jan 23 23:15:35 xMff: ack. the jtagkey tiny iss nice Jan 23 23:15:39 but only used with arm so far, it should be compatible to the broadcom jtag ports though Jan 23 23:16:02 s/broadcom/mips/ Jan 23 23:16:05 whatever Jan 23 23:16:11 yeah, i've got one that i've used with arm devices, with openocd Jan 23 23:16:34 JTAG Baudrate up to 6Mbits/sec Jan 23 23:16:36 nice :) Jan 23 23:18:09 Ok. Ill try one of those next - thanks. Jan 23 23:18:14 and compatible to SPI and I2C :) Jan 23 23:21:46 Ouch - the freight is more than the Jtag adaptor Jan 23 23:22:00 yes. openocd needs some more fixed and more mips support Jan 23 23:22:25 the hw is ok for mips. just needs a adapter for converting the pinout from 20pin arm to 14pin mips ejtag Jan 23 23:22:56 I can make the adaptor easy enough Jan 23 23:28:23 what are those 6pin jtag (in phones) Jan 23 23:29:57 Epsylon3: proprietary pinout Jan 23 23:30:10 the only 6pin conn which i know of arent jtag Jan 23 23:30:22 pdi and isp (atmel avr new and old) Jan 23 23:30:36 TRST-N TDI TMS TCK TDO GND Jan 23 23:31:06 i know of no standartized single-row pinout. propably some vendor standard Jan 23 23:31:24 yah its not in row Jan 23 23:31:33 in phone generaly Jan 23 23:31:53 pins are different on each phone (or brand) Jan 23 23:32:18 like that http://forum.xda-developers.com/attachment.php?attachmentid=308666&d=1271170469 Jan 23 23:32:29 http://www.amontec.com/pub/amt_ann003.pdf Jan 23 23:33:28 yea ok Jan 23 23:33:36 lot of unused wires :) Jan 23 23:34:33 one gnd could be enough if the cable is not 5 meters Jan 23 23:34:49 nah. keep it short Jan 23 23:36:25 the 26 pins with a full row of gnd... its to make cables shielded (to gnd) Jan 23 23:36:39 easy to sold like Jan 23 23:36:45 solder (sigh) Jan 23 23:38:33 shield would be something different than just interleaving. its to make it work properly at all Jan 23 23:38:43 its quite high clocks on these lines. Jan 23 23:38:56 depending on your jtag interface. Jan 23 23:39:14 active jtags like the ibm riscwatch easily drive 2 digit mhz Jan 23 23:39:47 digit ? Jan 23 23:39:54 bytes ? Jan 23 23:41:04 Epsylon3: >10mhz Jan 23 23:42:26 oh ok, on arm ? Jan 23 23:42:46 ibm riscwatch is ppc Jan 23 23:42:52 just was an arbitrary example Jan 23 23:43:06 yea Jan 23 23:43:11 i think for arm most people use cheaper simpler jtag at lower clocks Jan 23 23:43:15 but arm also have separate cores Jan 23 23:43:28 so maybe you can do weird things :p Jan 23 23:43:31 what has that to do with jtag clocks? Jan 23 23:43:45 you are connected to the arm9 Jan 23 23:44:00 often, there is a second core Arm11 on SoC Jan 23 23:44:19 for Java, multimedia, crypto etc Jan 23 23:44:38 then these are either daisy-chained (possible with jtag) or come out as as one jtag per chip, only daisy chaining internal components Jan 23 23:46:03 yea, maybe (ive read many things on S3C6410) was tryiing to port to linux :p Jan 23 23:46:12 Samsung chip Jan 23 23:46:32 of a Windows mobile phone... Jan 23 23:46:45 but i bought a motorola defy ;) Jan 23 23:46:53 port? i think there are ports already for it Jan 23 23:47:06 in fact no, was an ACER M900 Jan 23 23:47:22 and was dead 6 months after launch Jan 23 23:47:32 build #62 of ps3 is complete: Failure [failed compile_3] Build details are at http://tksite.gotdns.org:8010/builders/ps3/builds/62 Jan 23 23:47:38 replaced by firsts Acer Liquid Jan 23 23:48:05 Acer Nxx Jan 23 23:48:29 Epsylon3: http://blog.openinkpot.org/2010/05/iriver-story-firmware-source-code.html Jan 23 23:48:35 S Jan 23 23:48:46 thats a iriver ebook tablet. which uses the 6410 Jan 23 23:49:00 atleast soc support should be quite complete Jan 23 23:49:17 afaik it came from samsung itself or got outsourced/contracted by samsung Jan 23 23:49:18 yea... but the Acer was windows Jan 23 23:49:26 no linux stuff, so no gpl code Jan 23 23:49:28 Epsylon3: doesnt matter. same soc Jan 23 23:49:42 yea... i bought a little tablet for that Jan 23 23:49:44 SmartQ5 Jan 23 23:49:47 same SoC Jan 23 23:50:00 and made some low level stuff for it :) Jan 23 23:50:17 like a linux shell bootable from SDCard Jan 23 23:50:30 and a bootloader with LCD/USB support Jan 23 23:50:35 Qi Jan 23 23:50:43 added LCD support Jan 23 23:51:02 but, i dont had the time to check the pinout Jan 23 23:51:41 i wrote most of this page : http://htc-linux.org/wiki/index.php?title=M900 Jan 23 23:53:06 http://tanguy.ath.cx/?q=M900 Jan 23 23:53:09 my web site :) Jan 23 23:53:36 a made a special app on WinMo to check gpios :) Jan 23 23:54:03 186 gpios ! Jan 23 23:54:04 nbd: are we good to commit the libnl version bump? Jan 23 23:54:12 and multiplexed also Jan 23 23:55:25 philipp64|laptop: did you test if l2tpv3tun still compiles with it? Jan 24 00:00:02 is there a package with "iftop" Jan 24 00:01:02 yea :) ./packages/net/iftop/Makefile Jan 24 00:01:26 nbd: fail... http://fpaste.org/zR7G/ Jan 24 00:03:15 build #64 of pxcab is complete: Failure [failed compile_3] Build details are at http://tksite.gotdns.org:8010/builders/pxcab/builds/64 Jan 24 00:03:42 nbd: any ideas? Jan 24 00:07:11 probably a libnl api change Jan 24 00:25:51 euh... about uci-defaults Jan 24 00:26:03 set system.xxx=yyy Jan 24 00:26:09 commit system Jan 24 00:26:14 will add ? Jan 24 00:26:19 or replace ? Jan 24 00:26:33 or do nothing if it exists Jan 24 00:32:41 nbd: any further thoughts on my sysupgrade problem? Jan 24 00:35:25 russell--: not yet Jan 24 00:56:07 nbd: can you update the app? or patch it? Jan 24 01:01:45 philipp64|laptop: no Jan 24 01:01:47 i don't have time for this Jan 24 01:50:40 vfat: Unknown symbol fat_time_unix2fat Jan 24 01:50:46 fat: Unknown symbol load_nls Jan 24 01:51:09 (vfat fs module) Jan 24 02:22:30 ^^ DLNA is working :) Jan 24 02:22:46 now i need to mount my tv to the router via usb :p Jan 24 02:25:22 nbd: quick question... what the heck happened to nl_handle_alloc() in nl2.0? Jan 24 02:25:57 it probably became nl_socket_alloc Jan 24 02:43:01 nbd: got it... can you test it? http://fpaste.org/R66R/ **** ENDING LOGGING AT Mon Jan 24 02:59:58 2011