**** BEGIN LOGGING AT Fri Dec 07 02:59:57 2007 Dec 07 03:53:12 03bzhou * r7429 10optware/trunk/make/template.mk: template: small improvement Dec 07 04:51:27 rwhitby: nice. I've been using apex for at least 2 years now.. unless I have to flash using apex? Dec 07 04:51:58 Last time I flashed apex itself it was because of a change with FIS I believe.. anything else since? Dec 07 04:52:33 I tried to read up but the newsgroup was very quiet... I'm excited to try glibc 2.5 too.. Dec 07 04:54:24 wow. lots of new apex stuff too. I guess I'll start with flashing the latest apex.. Unless there's a working apex package already? Dec 07 05:10:44 VoodooZ: the latest 8MB flash image has redboot as primary bootloader and apex as secondary bootloader. Dec 07 05:43:59 03bzhou * r7430 10optware/trunk/make/swi-prolog.mk: swi-prolog: changed to enable savespace Dec 07 13:40:00 rwhitby: does that mean both booloaders are part of the image? Sorry. I'm a bit lost.. Dec 07 13:41:26 first question: Is it safe to use the apex package? After that is done I'll have to figure out how to flash the new load and "enable it".. Dec 07 13:47:46 VoodooZ: redboot is part of the image, but is never flashed (we assume you've still got it there). Dec 07 13:47:46 apex is part of the image, and is flashed where the kernel used to be. Dec 07 13:47:46 the kernel is then flashed in the next block after apex (apex is a single block), and apex allows the kernel to extend into the block where the ramdisk used to start (which is otherwise unused when you're using a jffs2 rootfs) Dec 07 13:47:46 the jffs2 partition starts in the same spot whether or not you have apex in there. Dec 07 13:47:46 (unless your kernel increases in size by 128Kb) Dec 07 13:47:48 Apex as a second stage loader is perfectly safe, cause you've still got the RedBoot hardware reset button upgrade mode in place before apex starts. Dec 07 15:04:56 rwhitby: ok. I see. I guess I'd still be considered "Special" as I replaced redboot with Apex a long time ago.. so I probably want to point apex directly to the kernel to bypass this whole secondary apex thing? Dec 07 19:31:06 Hey there, wondering if there's a release date/target for the new debian firmware? Dec 07 20:25:33 PriceChild: best place to ask would be in the Debian channels on OFTC Dec 07 20:25:54 (nslu2-linux doesn't need to release Debian images separately any more - it's done by Debian directly as part of the normal process Dec 07 20:28:38 Thanks very much rwhitby. Dec 07 23:22:02 rwhitby: ok. apex 1.5.13 built and flashed... Dec 07 23:22:37 Now, to install the new image I wonder if I should just bypass reflash and do it from apex... Dec 07 23:23:07 .13? wow - I need to update Dec 07 23:23:22 I'm on 1.5.8 Dec 07 23:23:36 yeah, i noticed the one you guys use as a bb package is not even listed on his page.. Dec 07 23:23:51 1.5.13 adds EABI or something like that.. Dec 07 23:24:15 actually, it's AEABI and "IXP42x using inline initialization" Dec 07 23:24:23 means anything to you? Dec 07 23:25:15 yeah, that means he's included some patches :-) Dec 07 23:25:54 root@SRX2:~$ reflash -i slugosbe-4.7-beta-nslu2.bin Dec 07 23:25:55 reflash: slugosbe-4.7-beta-nslu2.bin: bad Kernel size (1435444, max 1048576) Dec 07 23:26:10 Does it mean my reflash is too old or? Dec 07 23:32:01 reflash can't handle the big kernel Dec 07 23:33:29 not even the latest version? Dec 07 23:33:57 what's my options? fis write? apex? Dec 07 23:40:43 ok, so if I remember right, one can simply dd stuff directly to /dev/mtd*? but do I use /dev/mtdblockx or /dev/mtdx? Dec 07 23:42:27 03slug 07slugos-3.10-beta * r420 10slugos/openembedded/packages/vsftpd/vsftpd_2.0.3.bb: vsftpd: Added missing -lcap Dec 07 23:42:40 osas: that's the fix Dec 07 23:43:09 k Dec 07 23:46:36 it appears that 'cat zImage-nslu2be.bin > /dev/mtdblock2' doesn't work either.. (cat: Write Error: No space left on device) :( Dec 07 23:51:15 VoodooZ: you need to slugimage it to get the fis directory correct Dec 07 23:51:47 or edit your fis directory manually using hexedit :-) Dec 07 23:53:30 I'm game... but I thought I already did something like that last time (year ago)?? Dec 07 23:53:53 root@SRX2:~$ cat /proc/mtd Dec 07 23:53:54 dev: size erasesize name Dec 07 23:53:54 mtd0: 00040000 00020000 "RedBoot" Dec 07 23:53:54 mtd1: 00020000 00020000 "SysConf" Dec 07 23:53:54 mtd2: 00100000 00020000 "Kernel" Dec 07 23:53:56 mtd3: 00020000 00020000 "Ramdisk" Dec 07 23:53:58 mtd4: 00660000 00020000 "Flashdisk" Dec 07 23:54:01 mtd5: 00020000 00020000 "FIS directory" Dec 07 23:54:31 * mwester wonders why not just flash the entire .bin to the NSLU2, and be done with it? Dec 07 23:54:36 In my case I wouldn't use the secondary apex and would boot directly to the kernel Dec 07 23:55:10 mwester: could probably do that but then I wouldn't be learning anything.. Dec 07 23:55:23 Ah, ok - didn't know you already had apex installed. Dec 07 23:55:39 Plus, I've always been a "special" user and need as little boot overhead.. Dec 07 23:55:47 yep. Dec 07 23:56:03 it's a for a robot so need the quickest boot possible.. Dec 07 23:56:23 I wonder if there's been any improvement regarding that since last year... Dec 07 23:56:38 It's gotten slower, if that's what you mean. Dec 07 23:56:43 darn. Dec 07 23:57:09 I'll have to clean it up in my build, again... Dec 07 23:57:23 There's a lot you can probably strip out. the volatiles stuff, the delay for dhcp, etc. Dec 07 23:58:18 yeah.. I meant in terms of initscripts optimizations (ala initrd-ng or upstart) Dec 08 00:32:47 03bzhou * r7431 10optware/trunk/ (3 files in 2 dirs): python30: 3.0a1 -> 3.0a2 Dec 08 00:52:59 03bzhou * r7432 10optware/trunk/make/python30.mk: python30: some minor incremental changes Dec 08 00:57:12 rwhitby: is the new updated FIS directory contained in the complete image? If so I'll just flash the whole thing (below bootloader).. Dec 08 01:10:19 ok. no wonder It doesn't work... my kernel size is 1435428 bytes! damn build is busted I guess.. Dec 08 01:15:50 now, is there a place I can get a summary of space usage in the kernel? Dec 08 01:16:18 Anybody built head slugosbe-image in the last day or so? how big is your resulting zImage? Thanks **** ENDING LOGGING AT Sat Dec 08 02:59:57 2007