**** BEGIN LOGGING AT Tue Oct 31 02:59:57 2006 Oct 31 05:41:24 * rwhitby gets procmail to interoperate with the FSG-3 built-in postfix Oct 31 06:44:35 03rwhitby * r4341 10optware/trunk/ (make/procmail.mk sources/procmail/config-fsg3.patch): procmail: added fsg-3 specific patch to match fsg-3 mail layout Oct 31 10:23:07 hello all Oct 31 10:23:48 I am trying to test the GPL NPE driver on the IXDP425 but I wonder what my options are regarding the firmware upload to the NPE. Oct 31 10:24:05 What happens if I disable this: [*] Use Firmware hotplug for Microcode download Oct 31 10:29:37 [g2]: ping Oct 31 11:27:09 <[g2]> dwery ping Oct 31 11:29:39 pong Oct 31 11:30:02 [g2]: pong Oct 31 11:30:21 <[g2]> dwery I booted a BE .19-rc3 kernel last night Oct 31 11:30:30 great. dmesg? Oct 31 11:30:38 <[g2]> yeah one sec Oct 31 11:32:28 <[g2]> http://pastebin.ca/230037 Oct 31 11:32:39 <[g2]> heh.. still there from last night Oct 31 11:33:07 did you enabled te microcode loader? Oct 31 11:33:30 <[g2]> but of course :) Oct 31 11:33:45 <[g2]> I'm guessing you are doing and endian centric search Oct 31 11:33:59 <[g2]> s/and/an/ Oct 31 11:33:59 [g2] meant: I'm guessing you are doing an endian centric search Oct 31 11:34:26 mmmm the partition name should match Oct 31 11:34:35 a nd "searching firmware" must pop up oin dmesg Oct 31 11:34:39 * [g2] double checks the config to be sure Oct 31 11:35:37 please also check that I've put that string in the code :) Oct 31 11:36:15 <[g2]> which string ? Oct 31 11:36:54 "searching firmware" Oct 31 11:37:41 printk("npe: searching for firmware...\n"); Oct 31 11:37:49 <[g2]> CONFIG_IXP4XX_FW_LOAD=y Oct 31 11:38:01 nope Oct 31 11:38:03 wrong CONFIG Oct 31 11:38:25 IXP4XX_NPE_FW_MTD Oct 31 11:38:30 do a make oldconfig Oct 31 11:38:42 gtg . Ill be back in 60/90 mins Oct 31 11:39:25 <[g2]> cheers Oct 31 11:42:21 <[g2]> dwery THX. sorry I lost the patch when I reverted the series file for something else Oct 31 12:49:12 [g2]: ping Oct 31 12:49:15 gaim crashed :( Oct 31 13:50:08 <[g2]> dwery pong Oct 31 13:50:19 [g2]: got results? Oct 31 13:50:29 <[g2]> did you see this ? Oct 31 13:50:31 <[g2]> dwery THX. sorry I lost the patch when I reverted the series file for something else Oct 31 13:51:42 <[g2]> sweet Oct 31 13:52:25 ok, drop me a not when you'll have the dmesg Oct 31 13:52:58 <[g2]> dwery http://pastebin.ca/230886 Oct 31 13:53:23 <[g2]> I just need to rebuild busybox to have ifconfig Oct 31 13:53:45 great Oct 31 13:53:57 you might try nfsroot Oct 31 13:54:23 <[g2]> dwery I'm running from jffs2 Oct 31 13:54:30 <[g2]> it's trivial to setup Oct 31 13:54:49 with nfsroot you can use the server pc to trow test files in the environment Oct 31 13:54:55 <[g2]> I've got a little script, I've been playing with it as a POC for my GPS product Oct 31 13:55:00 even easier :) Oct 31 13:55:01 nice Oct 31 13:55:20 <[g2]> yeah the Loft runs on 8 AAs for a while :) Oct 31 13:58:13 I use a debian nfs root for my tests Oct 31 13:58:19 so I can apt-get install everything :) Oct 31 14:00:28 <[g2]> dwery yeah remember I run sarge and etch normally too :) Oct 31 14:01:11 btwohci_hcd 0000:00:05.0: Found HC with no IRQ.  Check BIOS/PCI 0000:00:05.0 setup! ohci_hcd 0000:00:05.0: init 0000:00:05.0 fail, -19 PCI: enabling device 0000:00:05.1 (0140 -> 0142 Oct 31 14:01:17 usb problems? Oct 31 14:01:37 [g2]: dwery morning (UGT) Oct 31 14:01:47 GPSFan: 'morning! Oct 31 14:02:12 [g2]: saw you got a BE kernel going any luck with ethernet? Oct 31 14:02:24 <[g2]> GPSFan think so Oct 31 14:04:15 <[g2]> ping 192.168.1.10 Oct 31 14:04:15 <[g2]> PING 192.168.1.10 (192.168.1.10): 56 data bytes Oct 31 14:04:15 <[g2]> 64 bytes from 192.168.1.10: icmp_seq=0 ttl=64 time=5.6 ms Oct 31 14:04:29 yay! Oct 31 14:04:49 [g2]: yea! now to figure out wtf iw wrong with my build.. Oct 31 14:04:51 <[g2]> dwery except for PCI all seems happy Oct 31 14:05:14 GPSFan: was your pci ok? Oct 31 14:05:46 dwery: mine works fine, madwifi working on minipci would tend to confirm it too. Oct 31 14:06:10 ok guys, you both have a problem :) Oct 31 14:06:21 <[g2]> PCI: enabling device 0000:00:05.2 (0140 -> 0142) Oct 31 14:06:21 <[g2]> ehci_hcd 0000:00:05.2: Found HC with no IRQ. Check BIOS/PCI 0000:00:05.2 setup! Oct 31 14:06:27 <[g2]> Ok I know what my problem is Oct 31 14:06:35 dwery: yep, by combining the builds we should flush out all possibilities. Oct 31 14:06:39 <[g2]> the platform specific PCI setup isn't right Oct 31 14:06:52 I'd check the CONFIG_xxx PCI issues Oct 31 14:07:00 <[g2]> "With enough eyes all problems are shallow!" Oct 31 14:08:13 first of all, I'd check DIRECT PCI vs INDIRECT PCI Oct 31 14:08:13 <[g2]> it's INDIRECT Oct 31 14:08:13 <[g2]> oops... DIRECT Oct 31 14:08:13 should be ok Oct 31 14:08:13 <[g2]> this is an interrupt assignment issue Oct 31 14:08:13 <[g2]> the PCI is up, Oct 31 14:08:13 <[g2]> the individual devices are not Oct 31 14:08:14 yep, but given that the two paltforms are almost indentical Oct 31 14:08:20 <[g2]> they fail. I've been throught this before Oct 31 14:08:37 <[g2]> except for the PCI enumeration part Oct 31 14:08:44 right Oct 31 14:08:54 mmm think I've got it Oct 31 14:09:06 <[g2]> dwery the fix ? Oct 31 14:09:20 avila_map_irq is not suitable for the loft Oct 31 14:09:21 indirect is not set on my .config Oct 31 14:09:56 [g2]: you should clone avila_map_irq into loft_map_irq Oct 31 14:10:04 and add irqs to the table Oct 31 14:10:07 <[g2]> dwery but oddly is works in LE Oct 31 14:10:14 <[g2]> s/is/it/ Oct 31 14:10:14 [g2] meant: dwery but oddly it works in LE Oct 31 14:10:39 mmm Oct 31 14:10:40 <[g2]> unless there's a slight build difference Oct 31 14:11:19 then map_irq should be ok Oct 31 14:12:23 I gotta run out for a while, bbl.. Oct 31 14:13:13 bye Oct 31 15:31:36 03blaster8 * r541 10kernel/trunk/patches/2.6.19/ (KERNEL defconfig): Update to 2.6.19-rc4, update defconfig, add isl1208 rtc driver Oct 31 15:38:11 03blaster8 * r542 10kernel/trunk/ (STATUS patches/2.6.18/defconfig): Add isl1208 rtc driver to 2.6.18, clean docs Oct 31 15:47:14 03bzhou * r4342 10optware/trunk/make/py-lxml.mk: py-lxml: upstream upgrade to 1.1.2 Oct 31 15:50:28 03bzhou * r4343 10optware/trunk/make/ (libgmp.mk perl.mk): have host-build depend on host/.configured Oct 31 17:37:58 03bzhou * r4344 10optware/trunk/make/perl.mk: sharing perl host build is not feasible, revert to the old way Oct 31 18:06:46 03bzhou * r4345 10optware/trunk/make/dnsmasq.mk: dnsmasq: added missing rm, so IPK_VERSION can take effect Oct 31 20:00:19 <[g2]> dwery GPSFan the pci mystery is solved :) Oct 31 20:00:51 <[g2]> I'm running BE with CF/ USB 2.0 disk / Networking Oct 31 20:00:53 [g2]: great, what was it Oct 31 20:01:13 <[g2]> GPSFan makefile issue, I'll be checking in a update for the Loft Oct 31 20:01:33 <[g2]> the machine id wasn't getting set, so it was booting as an ixdp425 Oct 31 20:03:02 [g2]: been looking at the at the malformed ARP request packets that my ethernet is sending out , it looks like it is missing a 32bit value right after the mac address. the remaining bytes seem to be ordered correctly and of ok value. Oct 31 20:03:38 since the arp request isn't being seen by the target then nothing else happens. Oct 31 20:03:44 <[g2]> open source is a good thing (tm) :) Oct 31 20:04:04 [g2]: you better believe it... Oct 31 20:04:05 <[g2]> this is on a ping out of the box ? Oct 31 20:05:28 yes, from the avila I try to ping another machine on the net. Using ethereal I caputre all packets comming into the target. I then repeated this from another working machine anc compared the packet data. Oct 31 20:07:11 the packets are the same length, and the source mac address is in the same place and correct for the avila, but the next 32bits on the avila are missing. the remainder of the packet seems to be correct. Oct 31 20:07:38 and there are 32extra "0" bits at the end. Oct 31 20:09:58 * GPSFan reads Comer about ARP Oct 31 20:19:45 [g2]: coul you pastebin your .config from your working 2.6.19-rc3 tree? Oct 31 20:19:47 <[g2]> GPSFan dwery ok, on my BE punchlist is the temp conversion issue Oct 31 20:21:11 <[g2]> GPSFan are you in a super big hurry ? I was gonna do a make clobber and test the rebuilt BE then commit to SVN Oct 31 20:21:12 [g2]: after reading about ARP and reading the code, I can't believe the code is broken. It must be some sort of config issue that I have screwed up Oct 31 20:21:32 [g2]: no, it can wait as long as you need it to. Oct 31 20:21:49 <[g2]> GPSFan I can e-mail you the .config and Makefile if you want Oct 31 20:22:21 sure that'l be fine Oct 31 20:29:19 Freecom have created a forum for Optware use on the FSG-3: http://www.openfsg.com/forum/viewforum.php?f=18 Oct 31 20:32:36 03g2-tbillman * r543 10kernel/trunk/ (Makefile-BE patches/2.6.19/loft_defconfig-be): Temporary Loft BE files until I clean up the Makefile and default configs. Oct 31 20:35:24 [g2]: the Makefile already has an LE/BE switch Oct 31 20:36:13 does the existing le/be sed operations not do what you need? Oct 31 20:36:54 <[g2]> rwhitby there are a couple issues with the current makefile Oct 31 20:37:41 <[g2]> I don't think the sed stuff is very consistent or proper for all platforms Oct 31 20:38:52 <[g2]> also some other BIG endian options aren't tied in like the CPU support BIG_ENDIAN ARCH Oct 31 20:39:33 <[g2]> I think we may have some platform variance on JFFS2 endianness Oct 31 20:39:49 <[g2]> also, the MACH ID patches for BE need to be fixed up Oct 31 20:40:36 yep, so let's fix those things in the current Makefile Oct 31 20:40:49 <[g2]> rwhitby I'm planning on it Oct 31 20:40:53 ok, sweet :-) Oct 31 20:41:12 let me know if I can help. Oct 31 20:41:15 <[g2]> however, I don't want to hold up GPSFAN / dwery or others that want to test BE Oct 31 20:43:37 <[g2]> rwhitby Ok it looks like maybe only the Loft was broke with regard to setting the MACH ID in BE Oct 31 20:43:56 <[g2]> it appears that the NAS100d already sets the proper machine ID Oct 31 20:43:56 well, up until recently the loft kernel was an ixdp425 :-) Oct 31 20:44:18 yep, we update the Makefile as each machine converts to using it's own machid in the kernel source Oct 31 20:45:51 [g2]: so tell me the story about jffs2 endianness on the loft. Is it different to other BE devices? Oct 31 20:46:03 (i.e. that code worked fine for BE nslu2 and nas100d) Oct 31 20:46:24 <[g2]> rwhitby I've run both BE and LE jffs2 partitions Oct 31 20:46:45 <[g2]> there's an option on the creation of the jffs2 fs Oct 31 20:46:52 yes. Oct 31 20:46:57 <[g2]> I've run all 4 options Oct 31 20:47:06 yes. Oct 31 20:47:29 for all other slugos targets, we chose one and stuck with it. will you be doing the same? Oct 31 20:47:29 <[g2]> so the current makefile doesn't really support mixed mode Oct 31 20:47:51 if mixed mode is the choice for the loft, then the makefile will support it. Oct 31 20:48:02 the developer choices drive the makefile, not the other way around. Oct 31 20:48:45 <[g2]> I haven't tested performance on all 4 so I don't know if there a real advantage one way or another Oct 31 20:48:46 what's the choice for the loft? Oct 31 20:49:24 <[g2]> right now I'm running same endianness BE/BE and LE/LE Oct 31 20:49:29 in that case, how about making it BE like the other BE devices until you test performance? Oct 31 20:49:40 <[g2]> I've toyed with going all BE Oct 31 20:50:15 <[g2]> well there are a couple things: Oct 31 20:50:34 BTW, the reason why we chose going the same endianness as the processor is cause that's what the virgin kernel jffs2 driver will do be default. Oct 31 20:50:53 our patch for setting endianness directly has gone into the mtd cvs, but has not gone upstream. Oct 31 20:51:14 (there is some problem in the mtd project where they can't send cvs updates upstream) Oct 31 20:51:18 <[g2]> well there's also a "_NATIVE" option Oct 31 20:51:27 yes, that's part of our patch Oct 31 20:52:07 15-jffs2-endian-config.patch Oct 31 20:52:09 <[g2]> so are planning all _NATIVE_ by default ? Oct 31 20:52:36 yes, native is the default. we just make that explicit. Oct 31 20:52:49 we could decide to remove the patch and those lines from the Makefile. Oct 31 20:53:04 (and force people to run native) Oct 31 20:53:25 <[g2]> well that's what the current makefile is doing anyway right ? Oct 31 20:53:36 by default, yes. Oct 31 20:53:55 (people can always edit it, as you have done) Oct 31 20:54:20 <[g2]> rwhitby I'd like _not_ to have to edit the Makefile Oct 31 20:54:28 so we force the users of the Makefile to use native, but we retain the ability for power developers to change the makefile and easily change it. Oct 31 20:54:32 <[g2]> defconfigs sure, Makefile not Oct 31 20:54:37 [g2]: then choose native for the Loft :-) Oct 31 20:55:06 I'd also like to look at re-merging the defconfigs too. Oct 31 20:55:26 Now that we have second stage bootloader support on the NSLU2, and can do bigger than 1MB kernels, then it should be possible. Oct 31 20:56:00 (tbm just released a debian-installer image which contains apex as second stage bootloader, and a stock standard ixp4xx kernel) Oct 31 20:56:04 <[g2]> the root questions is are we building custom kernels or not Oct 31 20:56:23 <[g2]> cool Oct 31 20:56:30 eno? Oct 31 20:56:34 well, our svn kernel repo Makefile is designed to build a single kernel, so that we can easily test new changes on multiple platforms. Oct 31 20:56:49 it is not meant to be a production kernel delivery device (that's what we use OE for) Oct 31 20:57:25 <[g2]> well the OE kernel just has an override Oct 31 20:57:46 So I would strongly prefer to have a single defconfig in the svn kernel repo, so we're all testing the same thing, and then different distros can override that in OE Oct 31 20:58:21 gda_: yes Oct 31 20:58:52 [g2]: So we will loook at modifying the common defconfig to match what you need for the Loft Oct 31 20:59:12 (with regard to which modules are compiled in and such) Oct 31 20:59:56 (since the one svn kernel repo makefile produces multiple kernels where the only difference is the shim prepended) Oct 31 21:00:18 <[g2]> yeah it's a combine kernel Oct 31 21:00:30 03bzhou * r4346 10optware/trunk/make/xterm.mk: xterm: upstream upgrade to 222 Oct 31 21:00:35 anyway, food for thought. I need to get ready for work. Oct 31 21:00:51 <[g2]> nod. Have a great day! Oct 31 21:01:07 <[g2]> rwhitby I think it comes down to testing strategy Oct 31 21:01:44 eno: have a problem with clamav on ds101g Oct 31 21:01:46 03bzhou * r4347 10optware/trunk/make/dnsmasq.mk: dnsmasq: upstream upgrade to 2.34 Oct 31 21:02:56 gda_: any idea about the cause? Oct 31 21:02:58 eno: clamscan tries to unpack its database to /tmp Oct 31 21:03:37 "/tmp on /tmp type tmpfs (rw)" Oct 31 21:03:53 not enough space Oct 31 21:04:10 k, so maybe we should use /opt/tmp instead Oct 31 21:04:17 export TMPDIR=/opt/tmp ist a workaround Oct 31 21:04:58 I don't have enough perl knowledge to fix it in amavisd Oct 31 21:07:23 eno: can you help? Oct 31 21:08:16 i'm at work during a lunch break, the best i can do is to look at it tonight Oct 31 21:08:16 i'm not good at perl either Oct 31 21:08:29 eno:okay, I can wait. Oct 31 21:08:42 what needs to be done then? Oct 31 21:09:50 drif: someone has to look into amavisd, find the call for clamscan and put a "export TMPDIR=/opt/tmp" somehow before it Oct 31 21:10:01 drif: from what i understand, we need to have clamav use /opt/tmp as TMPDIR Oct 31 21:10:29 I might be able to help :P but not yet into this dev stuff.. Oct 31 21:11:06 gda_: my preference is to change inside clamav code Oct 31 21:11:20 this way it does not matter who is using it Oct 31 21:11:39 eno: tried to use -DP_tmpdir="/opt/tmp", didn't help Oct 31 21:12:05 drif: if you have x-build environment, try build clamav Oct 31 21:12:38 eno: clamav didn't build on my current ubuntu Oct 31 21:13:04 I've moved recently - all I have atm resembling unix are these two slugs running unslung Oct 31 21:14:21 clamav.mk expects mandir in /opt/man, but in my environment it gets /opt/share/man, have patched to use --mandir=/opt/man, will check in now Oct 31 21:15:25 03gda * r4348 10optware/trunk/make/clamav.mk: clamav: fixed man dir Oct 31 21:16:32 eno: for reference this is the exact error message: Oct 31 21:16:38 LibClamAV Error: Wrote 0 instead of 512 (/tmp/clamav-ad56436e9a7f3e18/main.ndb). Oct 31 21:16:38 cli_untgz: No space left on device Oct 31 21:23:19 gda_: P_tmpdir probably is not tested in all places of getenv("TMPDIR") Oct 31 21:23:49 It is in cli_gentemp Oct 31 21:24:53 there P_tmpdir is used, but it gets overwritten, wait a moment ... Oct 31 21:25:04 we can even do a sed -i -e 's|getenv("TMPDIR")|"/opt/tmp"|g' Oct 31 21:25:16 and see if that works Oct 31 21:26:43 strange, the P_tmpdir hack should have worked Oct 31 21:27:01 look at this: dir = cli_gentemp(NULL); Oct 31 21:27:22 char *cli_gentemp(const char *dir) Oct 31 21:27:22 { Oct 31 21:27:24 ... Oct 31 21:27:43 if(!dir) { Oct 31 21:27:43 if((mdir = getenv("TMPDIR")) == NULL) Oct 31 21:27:43 #ifdef P_tmpdir Oct 31 21:27:43 mdir = P_tmpdir; Oct 31 21:27:43 #else Oct 31 21:27:44 mdir = "/tmp"; Oct 31 21:27:46 #endif Oct 31 21:32:24 [g2]: I'll have a look at merging on the bus ride to work today Oct 31 21:32:53 eno: don't understand currently and have no time this night anymore, sorry Oct 31 21:32:59 n8 Oct 31 21:34:44 <[g2]> rwhitby ok. A some point soon we should chat about regression testing strategy Oct 31 23:51:52 /usrlist Oct 31 23:52:14 damn gaim.. :) Oct 31 23:53:23 yes, kopete is.. at least was.. like that Oct 31 23:53:55 I tried /oper with it, with password and all :P Oct 31 23:54:04 and it went directly onto the channel Oct 31 23:54:15 very amusing Oct 31 23:55:26 :) Nov 01 00:00:40 mwester: apparently on that bus now? :) Nov 01 00:06:29 I think rwhitby's on the bus - I'm in front of the TV set. Pity there's nothing on tonight... :( Nov 01 00:06:50 I'm at work now Nov 01 00:07:33 * mwester-laptop remembers that he's timezone-math impaired... Nov 01 00:08:24 and I'm the same with names it seems... Nov 01 00:09:03 and the best part is that there's a logger that's preserving this conversation :) Nov 01 00:09:32 I have my very own torment-machine set up as well ;P Nov 01 00:11:07 (I hope there's no moderator who's going to slap our wrists for not staying on-topic.) Nov 01 00:35:23 (if there is one - atleast he/she managed to freeze this derailed conversation altogether..) Nov 01 00:51:56 03bzhou * r4349 10optware/trunk/ (make/mtr.mk sources/mtr/control): mtr: upstream upgrade to 0.72, generate control file Nov 01 00:58:31 03bzhou * r4350 10optware/trunk/Makefile: promoted mtr for ds101g and mss Nov 01 01:03:12 <[g2]> mwester-laptop you don't time shift ? Nov 01 01:04:20 <[g2]> the OSD is looking sweet. I'll probably replace my TIVO soon Nov 01 01:06:00 I hate watching TV without my TiVo... but it doesn't have anything recorded that appeals to me tonight. Nov 01 01:06:32 I have "Who's Line is it" on BBC America on right now; that's usually pretty good. Nov 01 01:13:48 I've heard good things about it Nov 01 01:14:06 it's it +"anyway?" Nov 01 01:14:10 isn't Nov 01 01:17:06 [g2]: interesting discovery, if I ping my avila, from another box, the avila responds to the ARP request with a malformed ARP reply, which is missing the same 32bit field as the ARP request it sends when trying to ping another box. Seems like the receive side is working, but the tx side completely misses the field. Nov 01 01:17:43 <[g2]> GPSFan are you bridging at all or plain interface ? Nov 01 01:18:12 [g2]: I went through your .config changing various things in my .config to match. no effect.. ;>( Nov 01 01:18:29 <[g2]> GPSFan one minute... This is with the 2.4 rootfs right ? Nov 01 01:19:33 [g2]: it's with the 2.6 rootfs that came on the board, tweaked. no bridging, just a basic box with an ethernet interface. Nov 01 01:19:58 <[g2]> GPSFan when did they start shipping 2.6 ? Nov 01 01:20:14 <[g2]> do you want my busybox ? Nov 01 01:20:16 [g2]: you got me the kernel is 21.6.15-uc0 Nov 01 01:20:43 <[g2]> oh.. some snapgear thingy Nov 01 01:20:53 <[g2]> maybe uclibc based too Nov 01 01:21:00 [g2]: let me try my other rootfs that I built from scratch. Nov 01 01:28:59 [g2]: I get the same malformed packets with the busybox & uClibc rootfs I guilt several days ago. again, the RX seems to receive and reply to the ARP request, with an ARP response which is missing the 0x8035 protocol identifier. Nov 01 01:30:24 <[g2]> GPSFan did you look at the packet coming out of the NPE driver ? Nov 01 01:30:27 [g2]: could you compile a kernel for BE and just change the "is Loft" to is avila" in the config? Nov 01 01:31:00 [g2]: I looked at the packet comming out the ethernet wire. Nov 01 01:31:19 <[g2]> GPSFan I know the packet is bad on the wire Nov 01 01:31:33 <[g2]> assuming monitor is good Nov 01 01:32:04 <[g2]> my point is that the boundary between the interface and kernel is pretty clean Nov 01 01:32:20 <[g2]> we should be able to see where the packet is getting munged Nov 01 01:32:38 [g2]: I've no clue as to how to look at what's comming out of the NPE. Yes, and the madwifi driver woks jsut fine. using the same kernel. Nov 01 01:34:13 [g2]: you are using the asme sources and same patches and similar .config and getting a working NPE ethernet. Nov 01 01:34:24 s/same/same Nov 01 01:34:42 * GPSFan can't type again ;>( Nov 01 01:38:59 <[g2]> GPSFan I think so Nov 01 01:39:12 <[g2]> which leaves tool chain Nov 01 01:39:26 <[g2]> or Avila verus Loft Nov 01 01:39:59 <[g2]> GPSFan I'm also running the patch 33-mtd that loads the NPEs Nov 01 01:40:26 <[g2]> are you using a module ? Nov 01 01:40:39 * [g2] wonders if there's an initialization issue Nov 01 01:40:45 [g2]: that's why I asked for a kerenl built for avial from your toolchain/patchset. Nov 01 01:41:33 [g2]: are upi using the ucode from the on-board redboot? Nov 01 01:41:48 s/upi/you Nov 01 01:41:54 <[g2]> well the Availa kernel will may setup the PCI bus slightly diffferently Nov 01 01:42:00 <[g2]> yup on the code from RedBoot Nov 01 01:42:28 for the test I don't need the PCI to work. Nov 01 01:42:43 <[g2]> npe: found at 0x42f4c, IXP425/NPE-B func: 01, rev: 2.0, size: 12848, id: 01010200 Nov 01 01:42:43 <[g2]> npe: firmware loaded to NPE-B, func: 01, rev: 2.0, status: 82400000 Nov 01 01:43:31 <[g2]> GPSFan did you build with the Loft mach Id ? Nov 01 01:43:32 npe: found at 0x42f4c, IXP425/NPE-B func: 01, rev: 2.0, size: 12848, id: 01010200 Nov 01 01:43:32 npe: firmware loaded to NPE-B, func: 01, rev: 2.0, status: 92c00000 Nov 01 01:43:32 npe: found at 0x4617c, IXP425/NPE-C func: 01, rev: 2.0, size: 12848, id: 02010200 Nov 01 01:43:32 npe: firmware loaded to NPE-C, func: 01, rev: 2.0, status: 80800000 Nov 01 01:44:05 ooh! different status.. Nov 01 01:44:18 <[g2]> npe: found at 0x4617c, IXP425/NPE-C func: 01, rev: 2.0, size: 12848, id: 02010200 Nov 01 01:44:18 <[g2]> npe: firmware loaded to NPE-C, func: 01, rev: 2.0, status: 80800000 Nov 01 01:44:36 <[g2]> yeah try port 1 :) Nov 01 01:46:02 <[g2]> looks like the status difference is 0x108..... Nov 01 01:46:12 <[g2]> so 2 bits are different Nov 01 01:47:11 status is the same on npe-c any idea what the status bits mean? Nov 01 01:48:02 <[g2]> I haven't looked that closely at the new NPE code Nov 01 01:48:15 the other port behaves the same. Nov 01 01:48:16 <[g2]> but the new code is pretty lean Nov 01 01:48:36 <[g2]> GPSFan this is 2.6.19-rc3 Nov 01 01:48:41 yep Nov 01 01:49:34 <[g2]> give a shout if you want my kernel and jffs2 to try sometime Nov 01 01:50:22 [g2]: I was sure it was a config issue, untill I went through the 2 configs side by side, and made the network parts the same. Nov 01 01:51:02 [g2]: I'll take a copy of your kernel, if you don't mind. I can see if it init's the NPE and gets the same status. Nov 01 01:51:13 <[g2]> which rev of the nslu2-linux repo are you building from ? Nov 01 01:51:55 [g2]: that's a question I don't quite know how to answer. Nov 01 01:52:16 <[g2]> "svn info" is your friend Nov 01 01:53:02 540 Nov 01 01:53:36 <[g2]> 538 Nov 01 01:53:41 <[g2]> pretty close Nov 01 01:53:52 <[g2]> kernel sent :) Nov 01 01:54:16 <[g2]> no Intel IP --- Wheee Nov 01 01:54:20 [g2]: btw. about that xscale board: i'm getting a dump of the whole flash of a working wrv54g Nov 01 01:54:35 thanks, 540 is basically increased entropy and the libata stuff Nov 01 01:55:08 <[g2]> nbd you've been busy in #openjtag. I've been watching throughout the day Nov 01 01:55:22 yeah Nov 01 01:55:28 unfortunately the srst stuff doesn't work yet Nov 01 01:55:30 <[g2]> last I saw one of the reset lines didn't seem right Nov 01 01:55:36 something's weird about that board Nov 01 01:56:08 <[g2]> nbd did you ever see the "salted slug" ? Nov 01 01:56:13 no Nov 01 01:57:26 <[g2]> nbd: that's the low-res pic http://www.nslu2-linux.org/wiki/uploads/NSLU2-board-front-bare.jpg Nov 01 01:58:05 <[g2]> ~gs Nov 01 01:58:07 methinks gs is South Georgia and the South Sandwich islands, or ghostscript Nov 01 01:58:07 <[g2]> ~g2 Nov 01 01:58:09 Easy to use, portable and powerful 2D graphics library. URL: http://www.ap.univie.ac.at/users/ljubo/g2/g2.shtml Nov 01 01:58:16 <[g2]> ~[g2] Nov 01 01:58:17 well, [g2] is really cool, and an an all around nice guy! Also he is a real funny guy, the master of NSLU2 Buildroot and a known Slug Sacrificer. And editor of SlugNews. Nov 01 01:58:26 <[g2]> "Slug Sacrificer" Nov 01 01:58:54 <[g2]> I sent a slug to a guy that baked off the components and power-sanded to the metal Nov 01 01:58:58 heh SlugNews Nov 01 01:59:06 looks cool Nov 01 01:59:14 <[g2]> rwhitby I was just laughing at that too :) Nov 01 01:59:30 * nbd is thinking about getting himself a slug as well Nov 01 02:00:08 <[g2]> you really should just get an Avila board Nov 01 02:00:17 nbd: we should look at how nslu2-linux and openwrt can collaborate more Nov 01 02:00:25 rwhitby: definitely Nov 01 02:00:50 <[g2]> I would be able to build/run openwrt Nov 01 02:01:05 <[g2]> I'm running 2.6.19-rc3 Nov 01 02:01:07 [g2]: your kernel boots and the ehternet works. Nov 01 02:01:27 <[g2]> GPSFan super! Nov 01 02:01:29 nbd: who's in the openwrt core team these days? who do I need to speak to? Nov 01 02:01:51 [g2]: the status for npe-b is still the same as what I saw before. Nov 01 02:01:57 rwhitby: project leader is [mbm], and i'm the one leading the commit stats :) Nov 01 02:01:58 <[g2]> rwhitby Kaloz and nbd are working on the IXP port Nov 01 02:02:14 and Kaloz is the main guy working on ixp Nov 01 02:03:13 <[g2]> GPSFan but the ethernet works Nov 01 02:04:26 it does. Nov 01 02:04:53 nbd: sweet - so you and Kaloz are the ones to talk to :-) Nov 01 02:05:10 does anybody here know anything about the d-link dwl-7000ap? Nov 01 02:05:13 nbd: are you guys working from our kernel patchset? Nov 01 02:05:16 [g2]: my madwifi modules won't load but that's probably due to some versioning you have turned on. Nov 01 02:05:26 <[g2]> rwhitby nod. that's why I asked Kaloz to stop in here :) Nov 01 02:05:33 rwhitby: i haven't really started working on ixp yet Nov 01 02:05:51 rwhitby: but i will once i get my wrv54g board recovered Nov 01 02:06:15 nbd, Kaloz: we'd love you to work directly from our kernel patchset, and will be happy to give you write access to enable that if required. Nov 01 02:06:33 (and we'll make any changes needed to enable you to work from the same patchset) Nov 01 02:06:47 our goal is to not fragment the kernel work Nov 01 02:06:52 i agree Nov 01 02:07:05 things definitely should stay in sync there Nov 01 02:07:37 sweet - we'll get along fine then :-) Nov 01 02:08:27 btw. what build system are most of you using? i don't really know much about nslu2-linux, i just seem to remember that there was some oe based stuff and some stuff that looked like a fork of an old openwrt or uclibc buildroot Nov 01 02:09:35 <[g2]> nbd it's OE Nov 01 02:10:31 <[g2]> the optware stuff isn't in OE, but everything else is, except for the kernel repo which a staging area for upstream and inclusion in OE Nov 01 02:10:42 nbd: the optware packages are a fork of an early openwrt buildroot Nov 01 02:10:45 ah Nov 01 02:11:14 <[g2]> nbd what's the status of -ng ? Nov 01 02:11:53 it's just kamikaze now (the -ng fork has been folded back). i think it's pretty polished for some platforms, for others more kernel work is needed Nov 01 02:12:52 and of course some of the base system work is still unfinished, like scripts for the wifi configuration Nov 01 02:12:53 <[g2]> how many platforms are 2.6 now ? Nov 01 02:13:03 once I get my new fsg-3 working as my main internet gateway, I'm going to free up my wl500g and put openwrt on it Nov 01 02:13:05 all except for broadcom and ar7 Nov 01 02:13:20 the working ones are: Nov 01 02:13:56 broadcom, magicbox (embedded ppc), x86 (wrap, soekris), routerboard 532, aruba Nov 01 02:14:01 * [g2] hates the / eating Nov 01 02:14:32 oh, i forgot the uml target Nov 01 02:14:35 also 2.6 Nov 01 02:15:03 <[g2]> no QEMU targets ? :) Nov 01 02:15:13 the x86 one runs in qemu as well Nov 01 02:15:46 <[g2]> you guys target a 4MB or 8MB flash right ? Nov 01 02:16:07 yes, 4 mb flash is usable for most platforms Nov 01 02:16:31 enough for a base system with everything for standard routing needs Nov 01 02:16:49 <[g2]> how's mesh support ? Nov 01 02:17:11 olsrd is packaged, but not integrated in the config system yet Nov 01 02:19:34 [g2]: ethernet doesn't completely work, trying to copy files and not getting any errors, but not getting any files either. Nov 01 02:20:16 * [g2] scp's 30MB files with md5sum matches Nov 01 02:20:46 * [g2] tries with BE Nov 01 02:22:40 [g2]: I do not get complete files, thisgs seem to stall after about 3Kbytes. Nov 01 02:29:02 <[g2]> GPSFan Ok 41MB kernel tarball pulls and MD5sums Nov 01 02:29:12 <[g2]> pulling it locally takes like 20 seconds Nov 01 02:30:03 [g2]: ok, so there is a loft/avila issue in the your kernel, Ididn't expect it to even run, just boot.. Nov 01 02:31:16 but it did prove that the basic 2.6.19-rc3 code as built for loft is close to avila and I'll go on that premis to try and unravel this. Nov 01 02:31:18 <[g2]> GPSFan I'm not clear what you mean about the loft/avila issue with my kernel Nov 01 02:32:09 <[g2]> GPSFan copy the kernel I gave you and hammer the 2 instructions in the front to boot it as avila Nov 01 02:32:14 your kernel is built for loft, it's running on an avila. and the net isn't quite working. I don't consider that a real problem. Nov 01 02:32:28 ok will do. Nov 01 02:32:49 <[g2]> that kernel supports like 6 machines Nov 01 02:33:05 <[g2]> in theory :) Nov 01 02:33:31 <[g2]> ok like 26 seconds for 41MB Nov 01 02:33:44 set how many bytes to what value? Nov 01 02:34:37 <[g2]> 'wb 0xe3a01c03,4' 'wb 0xe3811051,4' \ Nov 01 02:34:56 <[g2]> those are the first 2 32-bit words in the file Nov 01 02:35:25 <[g2]> the last bytes (03 and 51) are the machine id in hex Nov 01 02:35:31 <[g2]> 0x351 = 849 Nov 01 02:37:32 <[g2]> GPSFan all clear ? Nov 01 02:40:16 ok so I should make the 0x351 0x34e for avila? Nov 01 02:44:06 [g2]: changed it and the kernel hangs afrer decompressing, much like the first one I built, before I changed the mach-type. Nov 01 02:44:45 <[g2]> GPSFan I think the Avila mach is 54x Nov 01 02:44:59 <[g2]> which would be a 1xx number Nov 01 02:45:02 <[g2]> one sec Nov 01 02:45:39 <[g2]> 526 Nov 01 02:46:04 <[g2]> 0x20E Nov 01 02:46:10 oops, my bad ;>) Nov 01 02:46:13 <[g2]> np Nov 01 02:46:28 <[g2]> it's really nbd :) Nov 01 02:47:18 ? Nov 01 02:47:46 [g2]: what's the reason that a BE build of Loft does not set CONFIG_CPU_BIG_ENDIAN ? Nov 01 02:47:55 (looking at the Makefile merge) Nov 01 02:48:50 <[g2]> CONFIG_CPU_BIG_ENDIAN=y Nov 01 02:49:16 not in the loft_defconfig in the kernel svn repo Nov 01 02:49:50 <[g2]> rwhitby look at loft_defconfig-be :) Nov 01 02:49:56 ok, so it looks like the only thing I need to change in the Makefile is to add the devio stuff for BE loft. Everything else is the same (JFFS2 endianness matches cpu endianness) Nov 01 02:50:03 <[g2]> loft_defconfig is the LE version Nov 01 02:50:33 <[g2]> the devio is already added for the machine id Nov 01 02:50:40 03rwhitby * r544 10kernel/trunk/Makefile: Makefile: added support for Loft BE Nov 01 02:51:22 [g2]: the proposal is to now remove Makefile-BE. If you want BE, just use Makefile (run "make ENDIAN=b foo") Nov 01 02:52:24 03rwhitby * r545 10kernel/trunk/Makefile: Makefile: added support for overridding the defconfig name Nov 01 02:52:36 make that "make ENDIAN=b DEFCONFIG=loft_defconfig foo" Nov 01 02:53:03 [g2]: now, what needs to be done to merge loft_defconfig-be into loft_defconfig (and have the differences done by the Makefile) ? Nov 01 02:53:42 <[g2]> rwhitby dunno, I just pulled 544 a couple seconds ago Nov 01 02:53:46 Does that mean that we could have a "make ENDIAN=b DEFCONFIG=dsmg600_defconfig" as well, or is this just for the loft stuff? Nov 01 02:53:50 (note that I still want to merge loft_defconfig into defconfig eventually, but this is an intermediate step to reduce forking) Nov 01 02:53:56 <[g2]> make that 545 Nov 01 02:54:07 mwester: you could do so. I'd like to not have all the defconfigs fork though. Nov 01 02:54:24 (so we continue to all be testing the same things, but on different devices) Nov 01 02:54:40 <[g2]> rwhitby there is no forking. they are kernel configs Nov 01 02:54:41 Now that we can do > 1MB kernels on nslu2, we should be able to have a single defconfig for all our devices. Nov 01 02:54:56 [g2]: I was talking about Makefile forking Nov 01 02:55:11 Agreed, it's just so tempting to have a kernel with the ARTOP IDE driver built in so we can skip the JFFS... Nov 01 02:55:13 <[g2]> ah... the -BE is just a very temporary file Nov 01 02:55:28 [g2]: agreed - a very temporary fork :-) Nov 01 02:55:39 which is going away *very* soon :-) Nov 01 02:56:03 mwester: can we have "defconfig-diff" files, which only have the differences wanted for that platform? Nov 01 02:56:14 (so that everything else remains common) Nov 01 02:56:21 If I had 1$ for every time someone told me that something "was just temporary".... :D Nov 01 02:56:28 mwester: exactly! Nov 01 02:56:44 if you don't actively work against it, entropy wins every time. Nov 01 02:56:46 re: defconfig-diff --- excellent idea! Nov 01 02:56:49 <[g2]> look there's a very simple rift afoot Nov 01 02:57:06 [g2]: what's the rift? Nov 01 02:57:25 (and how do we mend it) Nov 01 02:57:46 "make ENDIAN=b DEFCONFIG_OPTS='PATA_ARTOP=y;VIA_VELOCITY=m'" Nov 01 02:57:50 [g2]: ehternet works and files transfer correctly. Nov 01 02:58:02 <[g2]> GPSFan super! :) Nov 01 02:58:32 [g2]: yea! Nov 01 02:58:36 mwester: probably want to have that in a file by default (if a specific target wants to be permanently different), but overridable on the command line Nov 01 02:59:16 agreed - it's begging for typing mistakes, isn't it? **** ENDING LOGGING AT Wed Nov 01 02:59:57 2006