**** BEGIN LOGGING AT Fri Aug 03 02:59:57 2007 Aug 03 03:08:15 ryd * r8326 /packages/net/olsrd/ (Makefile patches/110-cflags.patch): fix segfault and set right dependency Aug 03 03:32:15 ryd * r8327 /packages/net/olsrd/Makefile: adding txtinfo plugin (by tetzlav at leipzig.freifunk.net) Aug 03 07:18:19 <[florian]> sn9: pong Aug 03 07:21:13 [florian]: taken a look yet? Aug 03 07:21:32 <[florian]> sn9: not yet, just arrived, will do Aug 03 07:22:24 <_trine> good morning Aug 03 07:26:00 <[florian]> hi _trine Aug 03 07:26:06 [florian]: huh? Aug 03 07:26:14 <[florian]> wrt: just shut up Aug 03 07:26:29 <_trine> hehe Aug 03 07:27:00 <_trine> we must be the early contingent Aug 03 07:27:19 or late, depending on time zone Aug 03 07:27:33 Fri Aug 3 00:26:59 PDT 2007 Aug 03 07:27:48 <_trine> the usa guys are normally in bed by this time Aug 03 07:27:55 <_trine> you are a late bird Aug 03 07:28:00 depends on where in the usa Aug 03 07:28:33 it's not that late here yet Aug 03 07:28:39 florian * r8328 /trunk/ (7 files in 6 dirs): Make jffs2 images work with rdc, add a sitecom wl-153 profile and kernel config, fix rt61 installation (thanks to Daniel Gimpelevich) Aug 03 07:28:44 <[florian]> sn9: thanks ! Aug 03 07:29:27 <_trine> I have been watching you over the days trying to sort out the firmware problem Aug 03 07:29:35 <_trine> its interesting Aug 03 07:29:44 <[florian]> _trine: which firmware problem ? Aug 03 07:30:14 <_trine> have you not been trying to recover the image of a unit? Aug 03 07:30:28 <_trine> and were talking about different options Aug 03 07:30:38 <_trine> such as removing the chip Aug 03 07:30:43 <_trine> and reading it Aug 03 07:30:46 <[florian]> ah, this was not me, but rather sn9 or crazy_imp Aug 03 07:30:53 <_trine> yes Aug 03 07:30:54 <[florian]> or am I crazy ? Aug 03 07:31:07 <_trine> flo Aug 03 07:31:16 _trine is crazy_imp? Aug 03 07:31:31 <_trine> [florian]: ask your wife that question ,, mine would reply that i am Aug 03 07:31:36 <_trine> :) Aug 03 07:31:54 <_trine> sn9: yes i think you are correct Aug 03 07:32:16 ah, i figured out how to get the image Aug 03 07:32:23 <_trine> how Aug 03 07:32:48 what [mbm] tried to do with it gave me the idea Aug 03 07:33:36 see, part of the image is available for download from the sitecom website Aug 03 07:33:51 so it's ok to overwrite that part Aug 03 07:34:16 warning: do not try this without a working serial connection Aug 03 07:35:17 you need to create the following file: Aug 03 07:36:04 00000000 43 53 59 53 00 00 00 00 00 00 00 00 57 52 52 4d |CSYS........WRRM| Aug 03 07:36:04 00000010 00 00 00 00 |....| Aug 03 07:36:04 00000014 Aug 03 07:36:38 feed that file to sitecom's firmware upgrader Aug 03 07:36:49 <_trine> is that code to cp the image Aug 03 07:36:54 it will temporarily brick the device Aug 03 07:37:19 it's a fake upgrade image Aug 03 07:37:46 it will cause the crippled redboot not to shadow the kernel Aug 03 07:38:04 thus, you can then netboot it successfully Aug 03 07:38:18 <_trine> very good Aug 03 07:38:46 but only if you Ctrl-C over the serial at the right time Aug 03 07:39:30 <_trine> how do you tell when 'the right time is' is it a bit of guesswork? Aug 03 07:39:52 you could just hold it down while powering up the device Aug 03 07:40:23 <_trine> we use ctl C to get into redboot on the foneras Aug 03 07:40:33 after you're sure it's bricked, though Aug 03 07:42:56 with the changes just committed, you can build specifically for the WL-153 Aug 03 07:43:40 since i don't have such a device, i based the code on second-hand information Aug 03 08:02:29 [florian]: you forgot to commit the fix for jffs2 images Aug 03 08:03:33 you committed everything except that Aug 03 08:04:32 <[florian]> is it in rdc.patch ? Aug 03 08:04:37 yes Aug 03 08:04:47 <[florian]> ugh Aug 03 08:06:01 florian * r8329 /trunk/tools/firmware-utils/src/airlink.c: Fix the jffs2 images with rdc devices (thanks to Daniel Gimpelevich) Aug 03 08:07:16 <[florian]> thanks Aug 03 09:31:45 florian * r8330 /trunk/docs/ (Makefile network.tex wireless.tex): Add some more documentation Aug 03 15:59:20 juhosg * r8331 /trunk/target/linux/adm5120-2.6/files/ (arch/mips/adm5120/platform.c drivers/usb/host/adm5120-hcd.c): Aug 03 15:59:20 [adm5120] USB driver fixes Aug 03 15:59:20 * fix compiler warning in adm5120-hcd.c Aug 03 15:59:20 * allocate mem_resource with the correct size Aug 03 15:59:20 * fix driver name in the platform device structure Aug 03 17:31:48 juhosg * r8332 /trunk/target/linux/adm5120-2.6/files/drivers/usb/host/adm5120-hcd.c: [adm5120] fix reset function in USB driver Aug 03 17:59:29 nbd: how many targets still haven't moved from .21 to .22? Aug 03 18:00:58 i ask because i think .23 already has devicescape Aug 03 18:02:30 i was wondering whether it would be too awkward to add .23 support to generic-2.6 already Aug 03 18:04:25 the devicescape api changed a couple of weeks ago, making management of drivers that use it have to be updated simultaneously Aug 03 18:05:05 ugh. i am not making sense today Aug 03 18:21:58 <[florian]> sn9: are you on drugs ? Aug 03 18:23:23 [florian]: is the idea of supporting .23 this early that crazy? Aug 03 18:23:37 <[florian]> not at all Aug 03 18:23:44 <[florian]> just joking Aug 03 18:24:57 well, mac80211 is no reason for switching to .23 Aug 03 18:25:05 most of mac80211 is in .22 already Aug 03 18:25:10 and the rest can be backported easily Aug 03 18:25:26 not just because of devicescape Aug 03 18:26:02 also because a significant number of patches maintained for .22 are in there, too Aug 03 18:26:36 well, i have absolutely nothing against porting the patches for .23 already Aug 03 18:26:54 i just don't think we should switch yet Aug 03 18:27:03 i was weighing the backporting of mac80211 against the forward porting to .23 Aug 03 18:27:08 every single kernel update we had so far took quite a bit of time for sorting out bugs Aug 03 18:28:12 mac80211 cannot be backported without breaking bcm43xx-mac80211 Aug 03 18:28:29 i think that's included in .23 also Aug 03 18:28:50 our mac80211 tree already contains stuff that is newer than what is in .22 Aug 03 18:29:02 we pulled stuff from wireless-dev and michael buesch's tree Aug 03 18:58:58 heh, wireless-dev still isn't merged into the torvalds tree Aug 03 19:19:21 sn9: I've been trying to keep up-to-date with Michael Buesch's tree, and commit to openwrt when things build/work Aug 03 19:19:42 sn9: However, life has intervened recently, and I haven't been doing as much as I'd have liked to Aug 03 19:29:17 noz: http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?t=4028 Aug 03 19:33:02 sn9: Read it... I have very little experience with wireless - I've got the bcm43xx driver working in unencrypted mode, and that's about it so far. Aug 03 19:33:28 you mean the mac80211 branch? Aug 03 19:33:52 Yes. In my limited experience, the mac80211 stack is difficult to work with as yet, as the userspace tools are all but non-existent Aug 03 19:34:31 There is supposed to be a wireless-ext compatibility layer hack for it, but that's yet another layer in the way Aug 03 19:34:51 It feels like walking on quicksand. Aug 03 19:35:49 more and more drivers are depending on it Aug 03 19:36:01 sn9: Oops. Missed your last through finger trouble Aug 03 19:36:21 no, i waited Aug 03 19:36:27 OK! Aug 03 19:37:22 Depending on what? The mac80211 stack? Aug 03 19:37:32 yes Aug 03 19:38:04 in openwrt, it's just bcm and rt right now, but upstream, there are more Aug 03 19:38:25 I've tried to investigate the netlink method of communicating with it, but without much luck so far. Aug 03 19:41:41 If you can find out any more (in fact any) information about the nl80211 part, and any userspace tools to talk to it, or even plans and discussions, I'd be *very* pleased to read them Aug 03 19:42:38 I need to devote some serious time to it, probably with kgdb, but it's time I don't have right now. Aug 03 20:20:27 noz: http://marc.info/?l=linux-wireless&m=117533365015655&w=2 Aug 03 20:22:35 forget the userspace utils besides iwconfig Aug 03 20:24:19 a resync with the linville and bu3sch trees won't hurt that much Aug 03 21:01:02 sn9: Thanks for the link. Useful inof, but not directly relevant yet, as neither of us can even get WEP working, let alone WPA! Aug 03 21:01:12 s/inof/info/ Aug 03 21:01:59 gotta try unencrypted first Aug 04 01:37:22 blogic * r8333 /trunk/target/linux/amazon-2.6/files/ (2 files in 2 dirs): rewrite of the amazon irq code Aug 04 01:55:43 blogic * r8334 /trunk/target/linux/amazon-2.6/files/ (arch/mips/amazon/setup.c include/asm-mips/amazon/amazon.h): removed volatile register derefs from amazon setup code **** ENDING LOGGING AT Sat Aug 04 02:59:56 2007