**** BEGIN LOGGING AT Mon Oct 24 02:59:57 2005 Oct 24 06:34:10 03bzhou * 10unslung/make/py-cherrypy.mk: upstream upgrade from 2.0.0 to 2.1.0 Oct 24 10:55:54 03jbowler 07org.openembedded.dev * rafc082b3... 10/packages/ixp4xx/ixp4xx-csr_2.0.bb: ixp4xx-csr: move to NPE library 2_0_5 in 2.0 Oct 24 10:55:57 03jbowler 07org.openembedded.dev * r0119bfeb... 10/packages/linux/ (8 files in 2 dirs): nslu2-kernel: delete unused patches, add Debian config in 2.6.14 Oct 24 11:30:38 03koen 07org.openembedded.dev * r79617854... 10/conf/machine/h2200.conf: h2200.conf: change jffs2 pagesize to 4k to have more space in flashi Oct 24 11:52:12 damn, jtag over a byteblaster is sloooow :/ Oct 24 11:54:00 <[g2]> Jacmet what are you flashing ? Oct 24 11:54:10 <[g2]> or is it a read/verify ? Oct 24 11:57:34 [g2]: I'm simply doing a memory dump to figure out where the screwed sercomm redboot places the kernel cmdline/ATAGs Oct 24 11:58:15 [g2]: it's been running for ~ 15 mins and I'm at around 200 kb now ;) Oct 24 11:58:16 <[g2]> Jacmet bad news the screwed Redboot from sercom doesn't pass ro use cmdline/ATAGs Oct 24 11:59:06 <[g2]> I think it takes 40-50 to flash redboot with JTAG Oct 24 11:59:07 [g2]: sure? that functionaly has basically been in redboot from the beginning, and I didn't see anything affecting that in the sercomm patch Oct 24 11:59:17 <[g2]> yep Oct 24 11:59:25 <[g2]> it's a bastardized version of Redboot Oct 24 11:59:49 [g2]: that I know ;) Oct 24 11:59:55 <[g2]> we were all over this like white on rice July/August '04 Oct 24 12:00:03 <[g2]> maybe sept too Oct 24 12:00:07 [g2]: ohh, ok Oct 24 12:00:25 [g2]: did you find where in the sercomm stuff they fucked up the exec? Oct 24 12:01:08 <[g2]> iirc it's a pretty fixed boot process that runs the sercom check and boot Oct 24 12:01:54 [g2]: yes, the additional sercomm commands (boot, upgrade, .. are, but exec looks like the standard redboot one Oct 24 12:02:00 <[g2]> Redboot was replaced by a few ppl Oct 24 12:02:22 <[g2]> I mean a standard version of Redboot Oct 24 12:02:48 <[g2]> I replaced it with APEX for the fatslug and on a couple other slugs Oct 24 12:03:17 [g2]: Ok, getting a std redboot going should be fairly easy if the npe crap doesn't give too much trouble Oct 24 12:03:42 <[g2]> Hopefully, I'll have get all the souces for the current version I'm running now on the Loft that support booting from CF/Microdrive Oct 24 12:04:01 <[g2]> s/souces/souces this week/ Oct 24 12:04:08 [g2]: ok - did you get the cf driver running under 2.6? Oct 24 12:04:45 <[g2]> I haven't played with it much since a week or two ago Oct 24 12:04:54 <[g2]> that's may appear this week also Oct 24 12:05:07 ok, great Oct 24 12:05:37 [g2]: so the lofts are basically ready to ship now or what? Oct 24 12:05:38 <[g2]> I've been loading my rootfs off /dev/sdaX for I think close to two weeks Oct 24 12:06:06 <[g2]> yeah pretty muchl. there's some I2C drivers and a little clean up Oct 24 12:06:39 <[g2]> The boxes are getting made and after I see one the box production will be turned on Oct 24 12:06:44 ok Oct 24 12:06:47 cool Oct 24 12:06:53 <[g2]> I've been very happy with the boards overall Oct 24 12:08:07 <[g2]> even thought I don't use it very much anymore the load -m disk hda1:/boot/zImage is sweet Oct 24 12:08:33 [g2]: exactly Oct 24 12:08:49 <[g2]> what I'd like to do in the next couple months is teach Redboot to look across the PCI/USB bus to do Oct 24 12:08:59 <[g2]> -m disk sda1:/boot/zImage Oct 24 12:09:18 [g2]: that's going to be hard as redboot/ecos doesn't have any usb host support Oct 24 12:09:28 <[g2]> There's a minor switch on the loft to go to either a 4MB or 8MB NOR flash Oct 24 12:09:33 [g2]: I think uboot would be the way to go for such stuff Oct 24 12:09:55 <[g2]> My version has lspci Oct 24 12:10:15 <[g2]> bewoolie did the ext2 drivers for APX Oct 24 12:10:16 [g2]: I'm using redboot for some projects at work, but I'm seriously considering to switch to uboot for the added features Oct 24 12:10:18 <[g2]> bewoolie did the ext2 drivers for APEX Oct 24 12:10:29 <[g2]> which version 2.01 ? Oct 24 12:10:32 [g2]: yes, ecos/redboot has pci, but it doesn't have usb host Oct 24 12:10:37 03jbowler 07org.openembedded.dev * rf0e6ce1b... 10/conf/distro/ (nslu2-dist.conf ucslugc.conf): ucslugc: correct UCSLUG_EXTRA_BBFILES, damaged by change to nslu2-dist.conf in distro conf Oct 24 12:10:48 [g2]: no, standard cvs (it's on ppc) Oct 24 12:11:06 [g2]: yes, redboot also has ext2 and fat support Oct 24 12:11:11 + jffs2 Oct 24 12:11:12 <[g2]> for a bulk device with just reading 1 block at a time I don't think it would be too terrible Oct 24 12:11:35 [g2]: perhaps not, but probably more work than simply compiling uboot ;) Oct 24 12:11:44 uboot supports tons of stuff Oct 24 12:12:13 <[g2]> I'll bet uboot doesn't have NPE support :) Oct 24 12:12:19 <[g2]> or NPE LE Oct 24 12:12:30 <[g2]> the 2.01 is running the 1.5 IAL Oct 24 12:12:43 [g2]: probably not, I think the only supported ixp42x board uses an intel nic on pci Oct 24 12:13:00 <[g2]> I'm using the NPE Oct 24 12:13:18 but uboot supports usb host, lcd, a heck of a lot of file systems, .. Oct 24 12:13:26 [g2]: yes I know Oct 24 12:13:52 [g2]: but I guess it shouldn't be that hard to move the npe support from redboot to uboot Oct 24 12:13:54 <[g2]> ah.. you meant uboot only non-NPE etherent Oct 24 12:14:15 yes exactly Oct 24 12:14:22 <[g2]> it's really a non-issue for the Loft in going to the 4/8MB NOR flash Oct 24 12:14:31 [g2]: ok Oct 24 12:14:40 <[g2]> so it's all icing on the cake Oct 24 12:14:51 [g2]: does setting the kernel cmdline with exec -c "blah" work on the loft? Oct 24 12:15:09 <[g2]> for over a month :) Oct 24 12:15:24 <[g2]> probably close to 6 weeks now Oct 24 12:15:35 [g2]: great, was any special hacking needed or is it just a sercomm screwup? Oct 24 12:15:37 <[g2]> full config et... Oct 24 12:15:49 <[g2]> scripts etc... Oct 24 12:15:54 ok Oct 24 12:16:08 <[g2]> when power is applied it's just on Oct 24 12:16:14 .. like a normal redboot instead of the silly sercomm version ;) Oct 24 12:16:21 <[g2]> exactly Oct 24 12:16:27 <[g2]> it's actually like a normal PC Oct 24 12:16:59 <[g2]> it's loading kernel from a partition in JFFS2 and booting direclty to the rootfs on sda7 Oct 24 12:17:14 <[g2]> it was sda1/3 and 5 for a while Oct 24 12:17:50 <[g2]> so a full debian BE with Postfix, Courier, Spamassasin, thttp, iptables, etc... just boot Oct 24 12:17:55 <[g2]> boots Oct 24 12:18:10 nice Oct 24 12:18:40 <[g2]> there's just the forward port of the i2c driver to 2.6 from 2.4 and the CF/Microdriver for nice Oct 24 12:18:55 <[g2]> all the drivers work in 2.4 so the hw is good Oct 24 12:19:03 <[g2]> is simply a forward port Oct 24 12:20:29 <[g2]> So this weeks plan is build and flash Redboot from scratch and put together the debian roots and I've got a kernel so an initial full system will be ready to go Oct 24 12:20:59 <[g2]> I'll be starting the 24/7 testing soon Oct 24 12:21:57 <[g2]> it's run fine 24/7 for a many days, but I'll really start load testing on it's own network/setup soon Oct 24 13:03:43 [g2]: the i2c driver required porting? Oct 24 13:15:40 hey all Oct 24 13:15:48 anyone free to offer some help Oct 24 13:16:23 ah sorry wrong channel Oct 24 13:16:25 heading to general Oct 24 14:19:12 rwhitby: ping Oct 24 14:27:16 dwery: gu Oct 24 14:28:46 rwhitby: Had no time to test tha jffs2 thing :) Oct 24 14:29:12 what's interesting in R63? Oct 24 14:29:27 it has a commercial ntfs driver in it. Oct 24 14:29:43 (paragon software) Oct 24 14:30:50 ow Oct 24 14:30:51 wow Oct 24 14:31:47 but is that really useful on a nas? Oct 24 14:34:12 it is for people who want to attach a drive direct from their windows machine Oct 24 14:41:20 oh Oct 24 14:42:34 anything else really useful? :-D Oct 24 14:45:24 like maybe they fixed some kernel bugs for us :) Oct 24 14:48:15 you know that it's a 2.4.x kernel, right? Oct 24 14:48:51 uhm.. no.. I think none of my slugs actually runned it :) Oct 24 14:50:53 it seems my slugs have different rtc compensation values.. maybe they actually even tried to calibrate them Oct 24 14:51:24 What compensation value you talking about? Oct 24 14:51:47 It's highly unlikely that they're calibrating them BTW Oct 24 14:52:51 the x1205 has two compensation registers Oct 24 14:52:59 and you can calibrate them Oct 24 14:53:16 The trimming ones? Aren't they done by Xicor? Oct 24 14:53:29 actual trimming must be done on the final board Oct 24 14:53:32 withj xtal Oct 24 14:53:35 and everything else Oct 24 14:53:44 otherwise is not much useful imho Oct 24 14:54:20 Unless it is part of the driver I don't see it being changed Oct 24 14:54:53 if they have calibrated it, it must have been done with come custom utility Oct 24 14:54:54 anyway Oct 24 14:55:26 It really is unlikely that they've done this. It's not worth the extra time for them. Considering how crap the time keeping was for the initial releases of the firmware I don't think they care Oct 24 14:55:43 Their "fix" was to put in a cronjob that periodically resynced the kernel clock to the hardware clock Oct 24 14:55:54 Which is a total hack since you're got to have massive jumps Oct 24 14:55:59 you're going to have Oct 24 14:56:05 yep . anyway the values are exported with /proc/driver/rtc in the latest development version Oct 24 14:56:22 of the x1205 driver. Oct 24 14:56:45 digital_trim : -30 ppm Oct 24 14:56:45 analog_trim : 18.750 pF Oct 24 14:57:53 How close are the two nslu2s? Oct 24 14:58:11 mm.. can't check the other on right now.. Oct 24 14:58:57 maybe we can make an utility to calculate the compensation Oct 24 14:59:29 adjtimex Oct 24 14:59:39 comparing the hwclock with an ntp reference and bypassing the sw clock Oct 24 15:00:02 <[g2]> dwery not the i2c the actual devices on the i2c Oct 24 15:00:21 [g2]: which ones weren't available on 2.6? Oct 24 15:02:01 <[g2]> the on the board Oct 24 15:02:21 <[g2]> the chips on the board temp/voltage sensor, stuff like that Oct 24 15:02:25 dwery: 18.750pF is the maximum. It looks like the values are just random and whatever it came from at the factory Oct 24 15:02:25 ah ok Oct 24 15:02:38 Tiersten: probably Oct 24 15:02:45 Ditto for the digital_trim Oct 24 15:02:50 111 = -30 Oct 24 15:03:27 <[g2]> dwery Tiersten don't things run faster/slower at different temps Oct 24 15:03:52 <[g2]> so they'd need to be calibrated for a temp range ? Oct 24 15:04:01 yes, but the variation should be minimum Oct 24 15:04:35 <[g2]> generally yes, but between summer and winter there might be 5C diff Oct 24 15:04:39 Yes. You calibrate for the average temperature that the device is expected to be used in. The difference should be minimal unless you happen to live in the Sahara Oct 24 15:04:42 5C is nothing Oct 24 15:04:57 <[g2]> heh Oct 24 15:05:16 The datasheet says it's got internal compensation for it Oct 24 15:06:00 20C - 30C is the best range according to the datasheet. If you can keep it within those values then it'll be most accurate Oct 24 15:06:34 jbot, status Oct 24 15:06:35 Since Tue Oct 18 07:11:25 2005, there have been 122 modifications, 816 questions, 0 dunnos, 0 morons and 857 commands. I have been awake for 6d 14h 55m 41s this session, and currently reference 109445 factoids. I'm using about 19016 kB of memory. With 0 active forks. Process time user/system 19760.63/1110.91 child 0.04/0.01 Oct 24 15:51:16 03rwhitby * 10debian/configs/nslu2_defconfig-2.6.14-rc5: copied from -rc4 Oct 24 16:06:01 03rwhitby * 10debian/Makefile: Added the "packages" target for building kernel packages. Oct 24 17:10:45 03jbowler 07org.openembedded.dev * r361ee8eb... 10/packages/samba/samba_3.0.20.bb: Oct 24 17:10:45 samba: fix uclibc builds (struct timespec) in 3.0.20 Oct 24 17:10:45 - configure.in has an AC_TRY_COMPILE check for the existence of Oct 24 17:10:45 - struct timespec which fails on uclibc even though struct timespec is Oct 24 17:10:45 - defined, this causes the build to fail. Fix by supplying a cached Oct 24 17:10:46 - 'yes' value in all cases. Oct 24 17:55:40 03jbowler 07org.openembedded.dev * rcb5dc9f4... 10/conf/distro/ (nslu2-dist.conf ucslugc.conf): Oct 24 17:55:40 ucslugc: reintroduce support for UCSLUGC_* names in parallel with NSLU2_* (all versions) Oct 24 17:55:40 - the old name form was removed accidentally, reintroduced the original Oct 24 17:55:40 - names to support existing ucslugc local.conf files. Oct 24 17:55:43 03jbowler 07org.openembedded.dev * rc1622bb4... 10/conf/distro/openslug.conf: Oct 24 17:55:44 openslug: move to new configuration file organisation, use IAL 2.0, remove zImage (all versions) Oct 24 17:55:46 - configuration changes plus a move to use IAL 2.0 for the ethernet Oct 24 17:55:48 - support and to remove zImage from the default rootfs. This makes Oct 24 17:55:50 - a lot more space (now around 1MByte) available in the rootfs. Oct 25 02:06:16 03hrw 07org.openembedded.dev * r1b69a3e7... 10/packages/nano/ (nano_1.3.5.bb nano_1.3.9.bb nano-1.3.5 nano-1.3.9): nano: upgraded development version to 1.3.9 Oct 25 02:06:19 03hrw 07org.openembedded.dev * r16aa4270... 10/packages/nano/nano_1.2.1.bb: nano: fixed SRC_URI for 1.2.1 release Oct 25 02:55:54 03hrw 07org.openembedded.dev * r8f2796ff... 10/packages/opie-notes/ (opie-notes.inc opie-notes_0.3.bb opie-notes_cvs.bb): Oct 25 02:55:54 opie-notes: added version 0.3 and CVS Oct 25 02:55:54 - this is OPIE application but will get own version numbers **** ENDING LOGGING AT Tue Oct 25 02:59:58 2005