**** BEGIN LOGGING AT Sun Dec 09 02:59:56 2007 Dec 09 03:09:36 slugos 3.10 stable release feeds have finally been re-added to the autobuilder. Dec 09 03:27:33 mwester: I thought I found an rpm for python-bazaar for fedora but it requires python 2.4 specifically.. fedora 8 uses 2.5 Dec 09 03:27:49 damn thing is not available anywhere it seems. Dec 09 03:28:05 who requires that? Dec 09 03:35:43 VoodooZ: just sync up again (make update) - rwhitby fixed the problem. Dec 09 03:36:36 the bzr one? Dec 09 03:37:11 I'm doing the migrate db thing... long! Dec 09 03:54:24 mwester: thanks. bb works now. I'll keep checking here for your kernel diet patch.. Dec 09 04:10:30 rwhitby: 2.6.21 kernels don't work with SlugOS -- ipkg keeps downloading the 2.6.23 kernel modules from the feeds. This is a bit of a problem... Dec 09 05:57:09 03bzhou * r7436 10optware/trunk/ (3 files in 2 dirs): vlc: ignore libsysfs.h to build on slugos* Dec 09 06:49:03 VoodooZ: sync up and rebuild -- you should end up with a slimmer and trimmer kernel. You'll have to install kernel modules manually, or ipkg will attempt to install 2.6.23 kernel modules on the 2.6.21 kernel. Feed problem. Dec 09 08:35:18 mwester: ok, I'll remove the 2.6.23 ipkgs from the feed Dec 09 08:38:56 mwester: they're gone from the master now - should disappear from mirrors on the next feed push Dec 09 09:29:24 mwester: slugosle mirrors should be good now, slugosbe mirrors soon. Dec 09 16:49:25 hi Dec 09 16:49:41 which is a good place to buy and nslu2? Dec 09 17:56:32 03bzhou * r7437 10optware/trunk/make/netatalk.mk: netatalk: enable afp3 with large file support Dec 09 19:02:51 mwester, rwhitby: thanks. I'll give it a spin.. Dec 09 19:17:47 mwester: after changing my interface to the appropriate subnet (192.168.1.x), i was still unable to communicate with the slug. Dec 09 19:18:28 mwester: my lan utilizes 192.168.0.x subnet, so i had to change the settings on eth0 interface. Dec 09 19:19:23 mwester: i also tried connecting ethernet cable directly to the slug with appropriate 192.168.1.x settings on eth0 Dec 09 21:43:41 03bzhou * r7438 10optware/trunk/make/ushare.mk: ushare: 1.1 -> 1.1a Dec 09 21:48:49 03bzhou * r7439 10optware/trunk/make/yougrabber.mk: yougrabber: 0.29.1 -> 0.29.2 Dec 10 01:04:00 mwester: Thanks. My build was successful and 1003528bytes in size... Dec 10 01:04:24 Now, I have to figure out how to flash it using apex my first attempt appears to fail.. Dec 10 01:24:37 do I have to erase a flash block before I write to it in Apex or? writing the kernel to it doesn't give me the same checksum... Dec 10 01:50:15 do I have to flash a ramdisk? and if so where is it? In the 8m image? Dec 10 01:50:48 * VoodooZ thinks he's knee deep in slug dong! Dec 10 02:03:37 if there is one it will be in the flash image yes. Dec 10 02:03:55 along with the bootloader/kernel/config partions. Dec 10 02:04:04 using slugimage tool right? Dec 10 02:04:36 normally I would have done it from linux using reflash but I screwed around too much and now only have access to apex... Dec 10 02:04:57 There is no ramdisk with the SlugOS kernel. Dec 10 02:05:15 ok. so technically my current FIS dir is useless? Dec 10 02:05:37 Erase the MTD region for the kernel, then flash the kernel there -- boot to that address, and you should see the kernel decompress on the serial port. Dec 10 02:05:59 btw, how big is a flash block in apex? checksum in ram and flash don't match...so I'm wondering if I need to erase first.. Dec 10 02:06:05 No, your FIS dir will be unchanged Dec 10 02:06:29 aside from Redboot who uses it anyways? mtd driver in linux? Dec 10 02:06:33 The flash block size should be an attribute of the hardware, not the bootloader. Dec 10 02:06:49 ok. how big? I'm just paranoid to erase too much... Dec 10 02:06:55 If you erase and flash the MTD partition for the kernel, it will align to a flash block size. Dec 10 02:07:09 What does your FIS directory look like? Dec 10 02:07:23 fis: Dec 10 02:07:23 nor:0x00000000+0x00040000 RedBoot Dec 10 02:07:23 nor:0x00040000+0x00020000 SysConf Dec 10 02:07:23 nor:0x00060000+0x00100000 Kernel Dec 10 02:07:23 @0x00000000+0x00000010 (skip) Dec 10 02:07:25 nor:0x00160000+0x00020000 Ramdisk Dec 10 02:07:27 @0x00000000+0x00000010 (skip) Dec 10 02:07:30 nor:0x00180000+0x00660000 Flashdisk Dec 10 02:07:32 nor:0x007e0000+0x00020000 FIS directory Dec 10 02:08:09 are those 2 16bytes skips special trailers? Still needed? Dec 10 02:09:01 the problem is apex's erase function only takes one address argument so I was worried about the block size.. Dec 10 02:09:12 Ok. You should be able to erase the Kernel partition, and reflash. It won't break anything. Yes the the skips are the funky parts in the image for the (brain damaged) redboot on the NSLU2. Dec 10 02:09:27 Does it not take an address and a length? Dec 10 02:09:41 apex> help erase Dec 10 02:09:41 erase DST Erases the DST region. The default length is 1 which will erase a single flash block. APEX will report an error if the DST driver does not support an erase function. e.g. erase nor:0 # Erase first flash block Dec 10 02:09:55 Ah. Dec 10 02:09:57 Yuck. Dec 10 02:10:15 thus why I'm a bit paranoid.. Dec 10 02:10:21 128k? Dec 10 02:10:41 A flash block is a lot smaller than that -- usually several k bytes. Dec 10 02:11:51 plus, the fis driver of apex only works for reads... Dec 10 02:12:04 so dump & copy (from).. Dec 10 02:12:16 so I can't do 'erase fis://Kernel' Dec 10 02:12:39 unless it's a compile time option? Dec 10 02:12:57 I ended up using a binary from apex's site for the nslu2.. Dec 10 02:12:57 flash block size is 0x20000 IIRC Dec 10 02:13:16 (The FIS directory is one flash block in size) Dec 10 02:13:28 128k then. Dec 10 02:13:41 Bytes or bits? Dec 10 02:13:53 good point! Dec 10 02:14:23 If you just specify it using the math from the fis dir, you should be fine. Dec 10 02:14:34 I'll try.. Dec 10 02:15:14 Yep, 128K Bytes it is. Dec 10 02:15:28 so I did: erase nor:0x00060000 Dec 10 02:15:44 but I would need to do that for multiple block no? Dec 10 02:16:05 That's what I would expect -- where's the number of blocks, or the ending address go in the command line? Dec 10 02:16:07 I thought I remembered seeing a way to specify how many blocks.. Dec 10 02:16:21 Is there nothing on the wiki? Dec 10 02:16:21 I'll check the web site again.. Dec 10 02:17:30 actually, looking at 'help fill': fill -4 0xe5 0x100+256 # Write 64 0x000000e5's # & set default fill width to 4 Dec 10 02:17:58 so -8? Dec 10 02:18:19 The APEX site says it's something like nor:0x00060000+0x00100000, if I read it correctly. Dec 10 02:18:48 Or perhaps nor:0x00060000+0x000FFFFF Dec 10 02:19:04 I'll try ... Dec 10 02:19:32 I guess it's not a big deal if I clobber the 16byte trailer right? Dec 10 02:19:55 Nope, that can be recreated. What can't be fixed is if you erase apex. Dec 10 02:20:42 that's why I'm asking for help. paranoia saves lives! :) Dec 10 02:20:58 ok.. seems to work as dumping the region shows all 0xFFs.. Dec 10 02:21:08 now to flashing.. Dec 10 02:21:12 :) Dec 10 02:21:51 first I have to xreceive the darn image which takes forever... Dec 10 02:25:37 Yes!! checksum now matches! Dec 10 02:26:11 btw, what's the official kernel command line? Mine seems to have been resetted when I flashed Apex... Dec 10 02:26:38 It nows uses: console=ttyS0,115200 root=/dev/ram by default which I doubt is good.. Dec 10 02:27:15 Should be one built into the kernel, actually, that might work. But mine says: Dec 10 02:27:19 I found this one in slugos.inc: root=/dev/mtdblock4 rootfstype=jffs2 rw init=/linuxrc Looks a bit more familiar Dec 10 02:27:41 console=ttyS0,115200n8 root=/dev/mtdblock4 rootfstype=jff Dec 10 02:27:41 s2 rw init=/linuxrc noirqdebug Dec 10 02:27:51 (one one line - sorry, bad paste) Dec 10 02:27:53 ok. Dec 10 02:27:59 that looks more like it.. Dec 10 02:28:16 I think the apex binary I got came with old defaults... Dec 10 02:28:25 easy to change later.. I'll test it first.. Dec 10 02:28:48 I guess I'll flash the jffs2 the same way now.. Dec 10 02:29:09 Yep :) Dec 10 02:29:12 I won't touch the ramdisk.. Dec 10 02:29:56 I'm curious though, is slugos still using a ramdisk/initrd? (somewhere else perhaps?) Dec 10 02:34:44 No Dec 10 02:34:57 Did it at one time? Dec 10 02:35:06 It boots directly to the jffs2 Dec 10 02:36:53 ok. thanks. Just re-learning all this.. xmodem xfer in progress... I'll finish flashing later though as I have to go play hockey.. Dec 10 02:37:01 Thanks for all your great help.. much appreciated.. Dec 10 02:38:26 Enjoy your game! **** ENDING LOGGING AT Mon Dec 10 02:59:57 2007