**** BEGIN LOGGING AT Wed Feb 14 02:59:57 2007
Feb 14 09:14:23 <saladino> hi
Feb 14 09:31:06 <rwhitby> hi saladino
Feb 14 09:48:49 <CoreDump|home> rwhitby: what's the propper MACHINE for openslug / mokoslug? "nslu2be"or nslu2le?
Feb 14 09:50:44 <rwhitby> CoreDump|home: slugos with nslu2be or nslu2le
Feb 14 09:51:36 <CoreDump|home> I'm reading "Major changes to SlugOS build structure" ATM
Feb 14 09:51:42 <rwhitby> or mokoslug with nslu2le (I'm testing that one now)
Feb 14 09:52:15 <CoreDump|home> is the official stuff le or be?
Feb 14 09:52:31 <rwhitby> yeah, the changes are done for slugos.  if you want to run an Angstrom-derived distro (i.e. EABI), then wait for the mokoslug checkin shortly
Feb 14 09:52:48 <rwhitby> both - we release slugos as both BE and LE
Feb 14 09:52:59 <rwhitby> mokoslug will be LE only, cause EABI doesn't work BE
Feb 14 09:53:06 <rwhitby> linksys firmware is BE
Feb 14 09:53:11 <CoreDump|home> i see
Feb 14 09:53:19 <rwhitby> debian is LE too
Feb 14 09:54:02 <CoreDump|home> so it's DISTRO mokoslug and machine nslu2le
Feb 14 09:54:07 <CoreDump|home> ,)
Feb 14 09:54:14 <rwhitby> yep, in about 5 minutes time
Feb 14 09:56:26 <rwhitby> CoreDump|home: actually, I haven't done the 8MB image creation for mokoslug yet, so just do slugos/nslu2le
Feb 14 09:56:41 <CoreDump|home> will do
Feb 14 09:56:46 <rwhitby> (but be prepared to reflash from scratch with mokoslug later)
Feb 14 09:56:59 <CoreDump|home> no problem there
Feb 14 09:57:42 <rwhitby> actually, running slugos/nslu2le will be good for you to see what the turnup and sysconf utilities do, cause we want to replicate that functionality but do it properly this time so all of OE can use it (including using altboot for the turnup functionality)
Feb 14 09:58:18 <CoreDump|home> sound good to me
Feb 14 09:58:20 <CoreDump|home> I see that your wiki is kinda out-of-date when it comes to OE. Do you uses OE's .dev branch? You had your own branch in the past right?
Feb 14 09:58:32 <rwhitby> turnup to an external drive, then use "reflash" to upgrade the kernel/rootfs and see the "sysconf" stuff work.
Feb 14 09:58:41 <rwhitby> we use oe.org.dev directly.  no fork.
Feb 14 09:58:49 <CoreDump|home> okl just checking
Feb 14 09:58:59 <rwhitby> "wget www.nslu2-linux.org/Makefile ; make slugosle"
Feb 14 09:59:14 <CoreDump|home> err makefile?
Feb 14 09:59:35 <rwhitby> that's our "Master Makefile" which can build *any* nslu2-linux deliverable
Feb 14 09:59:52 <CoreDump|home> using bitbake?
Feb 14 09:59:54 <rwhitby> do the openembedded-essentials thing, then just run our Makefile.
Feb 14 10:00:05 <rwhitby> yep, it's just a wrapper around OE which does all the setting up stuff.
Feb 14 10:00:26 <CoreDump|home> hmmmmmmm. I guess I'll be a big supported or mokoslug then =D
Feb 14 10:00:28 <rwhitby> the directory structure you're used to will just be one level down under "slugosle"
Feb 14 10:00:58 <rwhitby> "make mokoslug" will work once I check in the conf file too"
Feb 14 10:01:56 <CoreDump|home> hmm need to setup a working local.conf first. Then I'll try building some stuff w/ bb. And when that works, I'll try the makefile thingy
Feb 14 11:17:19 <CoreDump|afk> mtn: misuse: layout of database /home/mhentges/openembedded/machines/nslu2/monotone/nslu2-linux.mtn doesn't match this version of monotone"
Feb 14 11:17:26 <CoreDump|afk> err
Feb 14 11:19:13 <CoreDump|afk> rwhitby: bitbake slugimage w/ DISTRO slugos and MACHINE nslu2le should do as well?
Feb 14 11:30:15 <rwhitby> slugos-image, yes
Feb 14 11:30:54 <rwhitby> CoreDump|afk: you need to do the database upgrade.
Feb 14 11:31:18 <rwhitby> alternatively, use the OE.db (which is 0.32 I think), and then do a make update to pull in the nslu2 stuff
Feb 14 11:31:29 <rwhitby> or wait for hours for the db migrate stuff
Feb 14 11:32:19 <CoreDump|afk> rwhitby: I have already set up an up-to-date OE env
Feb 14 11:32:27 <CoreDump|afk> I'm using latest .dev
Feb 14 11:32:32 <rwhitby> ok, that will be fine
Feb 14 11:32:55 <rwhitby> we push to monotone.nslu2-linux.org, which syncs with monotone.openembedded.org
Feb 14 11:32:58 <CoreDump|afk> I'll lat it compile while I now hurry to work. later!
Feb 14 11:33:02 <rwhitby> later
Feb 14 13:50:06 <VoodooZ> darn, my slugosbe 4.3 beta image's eth0 refuses to work. Which prevents me from installing a newer f/w
Feb 14 13:50:19 <VoodooZ> It's up but doesn't work.
Feb 14 13:51:12 <VoodooZ> unless it's because my old SysConf content from SlugOS 3.10 is not compatible?
Feb 14 13:58:24 <VoodooZ> Unless my ethernet cable got disconnected somehow.... How could I check link status?
Feb 14 16:01:08 <VoodooZ> rwhitby: I just flashed the latest slugosbe (pulled 12 hours ago) and it still doesn't load up the npe stuff. 
Feb 14 16:01:33 <VoodooZ> Do I need to wipe my sysconf or FIS stuff?
Feb 14 19:54:36 <rwhitby> VoodooZ: you need to flash the full 8MB image, including FIS directory (cause that's where the microcode is)
Feb 14 20:10:21 <VoodooZ> rwhitby: ah! That's why!
Feb 14 20:10:54 <VoodooZ> And how do I recommend I do that (using apex?). I did use reflash -i 
Feb 14 20:12:23 <VoodooZ> rwhitby: btw, I have patches to make the old zd1211 driver package work under 2.6.20 if you want them. (the new zd1211rw one is very beta so..)
Feb 14 20:14:08 <rwhitby> VoodooZ: sure
Feb 14 20:15:04 <VoodooZ> do you want me to email them? There's 3 patches and a revised .bb file.
Feb 14 20:18:18 <rwhitby> is there an OE package already ?
Feb 14 20:18:21 <VoodooZ> yep
Feb 14 20:18:23 <VoodooZ> zd1211
Feb 14 20:18:30 <rwhitby> can you update that?
Feb 14 20:18:53 <VoodooZ> I don't believe I have write access anymore plus my repo is a mess. (not for public consumption!)
Feb 14 20:19:14 <VoodooZ> but with enough hand holding I could try... up to you.
Feb 14 20:21:42 <VoodooZ> anyways, I'm leaving work now but I'll be back later... (with more questions! :) )
Feb 14 20:39:29 <rwhitby> VoodooZ: send them to me
Feb 14 20:47:20 <saladino> hi
Feb 14 22:05:11 <VoodooZ> rwhitby: How do I update the FIS partition to have the openNPE firmware? can I do it from the command line?
Feb 14 22:18:09 <VoodooZ> NAiL: hey
Feb 14 22:23:32 <VoodooZ> damn. I just reflash and tried overwriting my sysconf and I forgot the original root password!
Feb 14 22:26:46 <VoodooZ> rwhitby: I sent you the zd1211 stuff.
Feb 14 22:27:40 <VoodooZ> rwhitby: what are my options to re-init the FIS partitions with the new stuff? from apex? others?
Feb 14 22:27:41 <rwhitby> thx
Feb 14 22:27:48 <VoodooZ> no, thank you!
Feb 14 22:28:17 <rwhitby> get the FIS dir block from the image, and cat it into mtd from linux userland
Feb 14 22:32:37 <VoodooZ> ok, I've already unpack the 8Meg image, what file to what device? (I'm paranoid)
Feb 14 22:37:41 <CoreDump|home> hi
Feb 14 22:41:51 <CoreDump|home> SRC_URI = "http://www.intel.com/Please-Read-The-BB-File/IPL_ixp400NpeLibrary-2_3.zip"
Feb 14 22:41:58 <VoodooZ> rwhitby: ok, i've extracted the fis dir w/ slugimage. do i: cat FIS > /proc/mtd ??
Feb 14 22:42:13 <CoreDump|home> well, I did read it and there's nothing special about it. What's the point=
Feb 14 22:42:15 <CoreDump|home> ?
Feb 14 22:42:37 <rwhitby> CoreDump|home: you need to download the microcode directly from Intel and accept their license
Feb 14 22:42:46 <CoreDump|home> hrmm
Feb 14 22:42:53 <rwhitby> VoodooZ: make sure you cat to the *correct* mtdblock device
Feb 14 22:42:57 <CoreDump|home> my bb doesn't mention anything about it ;)
Feb 14 22:43:11 <rwhitby> CoreDump|home: that is the microcode which runs the internel ethernet NPE on the ixp4xx chi
Feb 14 22:43:21 <CoreDump|home> ahh
Feb 14 22:43:21 <rwhitby> Hmm - we need to fix the .bb then :-)
Feb 14 22:43:27 <CoreDump|home> indeed
Feb 14 22:43:37 <mwester> somebody else mentioned that the .bb file lost the explanatory text...
Feb 14 22:43:41 <rwhitby> we store it in a separate flash area, and the kernel loads it on boot.
Feb 14 22:43:41 <CoreDump|home> my RW access is b0rked ATM, sorry
Feb 14 22:44:10 <CoreDump|home> rwhitby: sounds painful
Feb 14 22:44:36 <rwhitby> CoreDump|home: it's all in the kernel now :-)
Feb 14 22:44:50 <CoreDump|home> =)
Feb 14 22:45:07 * CoreDump|home tries to navigate intel.com
Feb 14 22:45:52 <mwester> Now *that's* painful!
Feb 14 22:45:59 <VoodooZ> rwhitby: correct? hehehe good thing I asked you first! 
Feb 14 22:46:58 <VoodooZ> rwhitby: Here's my current /proc/mtd just to make sure:dev:    size   erasesize  name
Feb 14 22:47:01 <VoodooZ> mtd0: 00040000 00020000 "RedBoot"
Feb 14 22:47:04 <VoodooZ> mtd1: 00020000 00020000 "SysConf"
Feb 14 22:47:06 <VoodooZ> mtd2: 00100000 00020000 "Kernel"
Feb 14 22:47:09 <VoodooZ> mtd3: 00020000 00020000 "Ramdisk"
Feb 14 22:47:11 <VoodooZ> mtd4: 00660000 00020000 "Flashdisk"
Feb 14 22:47:14 <VoodooZ> mtd5: 00020000 00020000 "FIS directory"
Feb 14 22:47:28 <rwhitby> CoreDump|home: http://www.intel.com/design/network/products/npfamily/ixp400_current.htm
Feb 14 22:47:42 <VoodooZ> I thought the new structure was different though? or do i simply cat to mtd5?
Feb 14 22:47:46 <CoreDump|home> rwhitby: got it thanks
Feb 14 22:47:58 <rwhitby> VoodooZ: compare your current md5 against the file you are about to cat into it.  they should be the same size and you should be able to determine the differences with hexdump
Feb 14 22:48:19 <rwhitby> new structure is exactly the same without Apex
Feb 14 22:48:37 <VoodooZ> crap. now you lost me.
Feb 14 22:49:14 <VoodooZ> anyways, I have to play hockey in a few minutes so I'll be back later..
Feb 14 22:49:40 <VoodooZ> later
Feb 14 22:51:12 <CoreDump|home> this looks awfully complicated. mtd* for a _RAM_disk?
Feb 14 22:51:33 * CoreDump|home studies the wiki
Feb 14 22:57:10 <rwhitby> CoreDump|home: the Ramdisk partition is a bogus partition which has to be there cause of the Linksys RedBoot hacks.  It contains nothing.
Feb 14 22:57:20 <CoreDump|home> ahh
Feb 14 22:57:27 <CoreDump|home> what's FIS?
Feb 14 22:57:36 <rwhitby> RedBoot filesystem
Feb 14 22:58:04 <CoreDump|home> and flashdisk is /?
Feb 14 22:59:27 <rwhitby> yep
Feb 14 22:59:40 <CoreDump|home> ok =) 
Feb 14 22:59:47 <rwhitby> then you "turnup" / to an external disk (which is what altboot is going to do for us)
Feb 14 22:59:56 <CoreDump|home> right
Feb 14 23:00:08 <rwhitby> and altboot will even kexec a new kernel from external disk, right?
Feb 14 23:00:18 <CoreDump|home> well it could yeah
Feb 14 23:00:35 <rwhitby> that's why I'm interested in using it :-)
Feb 14 23:00:40 <CoreDump|home> heh
Feb 14 23:01:01 <CoreDump|home> sysconf is a known-good state of settings?
Feb 14 23:01:06 <rwhitby> (that will be the killer feature which convinces everyone to move away from our current pivot-root scripts)
Feb 14 23:01:38 <CoreDump|home> rwhitby: well, the "killer" feature would be a dd-wrt-style web configuration =)
Feb 14 23:01:52 <rwhitby> sysconf is network settings (in a form compatible with stock firmware, so set up your network settings in the stock firmware correctly first) and also a gzipped cpio archive of all CONFFFILES from your rootfs.
Feb 14 23:02:10 <CoreDump|home> you lost me
Feb 14 23:02:25 <rwhitby> well, you know how in OE some files are marked as CONFFILES?
Feb 14 23:02:30 <CoreDump|home> sure
Feb 14 23:02:49 <rwhitby> we save all those in sysconf, so you can reflash new firmware and restore all your configuration files
Feb 14 23:03:11 <rwhitby> (using the same sort of dialogue as you get when you ipkg upgrade and a configuration file has changed)
Feb 14 23:03:59 <CoreDump|home> ahh ok
Feb 14 23:05:07 <rwhitby> very handy for testing firmware updates
Feb 14 23:05:46 <CoreDump|home> indeed. Do we have RW access to this partition after / is booted?
Feb 14 23:05:55 <rwhitby> yes
Feb 14 23:06:08 <CoreDump|home> and does the RESET button copy sysconf into /?
Feb 14 23:06:23 <rwhitby> but if you want to overwrite the whole MTD block, you need to turnup to an external disk or ramdisk first
Feb 14 23:06:32 <rwhitby> no, sysconf save is manual
Feb 14 23:06:49 <rwhitby> and restore is automatic if a certain file is not already in the rootfs on first boot
Feb 14 23:07:04 <rwhitby> if sysconf is borked, then you need to get into redboot and erase it.
Feb 14 23:07:11 <CoreDump|home> sounds like a very nice feature indeed
Feb 14 23:07:34 <CoreDump|home> rwhitby: ok that sucks =)
Feb 14 23:07:43 <CoreDump|home> s/sucks/needs some polishing
Feb 14 23:08:21 <rwhitby> CoreDump|home: what needs polishing?
Feb 14 23:08:36 <rwhitby> (sysconf has never got borked for me ever)
Feb 14 23:09:08 <CoreDump|home> rwhitby: ah ok. I thought $USER could run into that problem
Feb 14 23:09:43 <CoreDump|home> so a forced restore is not possible ATM right? Say, if $USER wants to completely revert his box to a known state?
Feb 14 23:10:12 <rwhitby> sure - telnet into redboot and erase sysconf - instructions are in the wiki
Feb 14 23:10:22 <rwhitby> lots of $USERs do it, even for the stock firmware.
Feb 14 23:10:39 <rwhitby> (the stock firmware is more likely to bork sysconf)
Feb 14 23:11:07 <rwhitby> the upgrade protocol (which upslug2 uses) rewrites everything except redboot and sysconf
Feb 14 23:11:24 <CoreDump|home> don't get me wrong =) I just really don't think using redboot is one of the things a $USER should do
Feb 14 23:12:05 <CoreDump|home> since we have rw access to sysconf, that could be worked around =)
Feb 14 23:12:13 <rwhitby> agreed.
Feb 14 23:12:28 <CoreDump|home> NOTE: package slugos-image-1.0: completed
Feb 14 23:12:31 <CoreDump|home> w00t
Feb 14 23:12:34 <rwhitby> in normal operation, $USER never needs to get into redboot.
Feb 14 23:12:49 <rwhitby> even for upgrade, the reset button mode is the recommended one
Feb 14 23:13:18 <rwhitby> and SlugOS never borks the sysconf, so it's not an issue there.
Feb 14 23:14:12 <CoreDump|home> I was looking for install instruction for slugos ealier today but didn't come up with anything besided "Make sure you have access to redboot"
Feb 14 23:14:51 <CoreDump|home> rwhitby: don't mind me "complaining", polishing is what I do for fun heh
Feb 14 23:16:14 <CoreDump|home> ahh upslug while running slugos appears to be the key
Feb 14 23:17:01 <rwhitby> CoreDump|home: I love "complaints" from developers who are going to fix things :-)
Feb 14 23:17:14 <CoreDump|home> Oh I intend to ;)
Feb 14 23:18:01 <CoreDump|home> rwhitby: I can flash slugosle-4.3-beta-nslu2.bin from the linksys web interface right?
Feb 14 23:18:21 <rwhitby> CoreDump|home: maybe - but better to use the upgrade mode
Feb 14 23:18:42 <rwhitby> (since you will need to use that mode forever more after that)
Feb 14 23:19:13 <rwhitby> hold in reset on power-up, wait for the led to change colour and let go immediately,  red/green flashing means it's ready for upslug2.
Feb 14 23:19:51 <CoreDump|home> ahh, i was mistaken. I though upslug was a tool on the slug itself.
Feb 14 23:20:13 <rwhitby> no, it's the client to flash the slug using the built-in redboot upgrade mode protocol
Feb 14 23:20:17 * CoreDump|home found the right wiki page
Feb 14 23:22:14 * rwhitby tests upgrade from 3.10 to 4.3
Feb 14 23:24:50 <rwhitby> CoreDump|home: what do you have attached to the slug for storage?
Feb 14 23:25:50 <CoreDump|home> rwhitby: a 200G drive and if needed a 1Gb usb stick
Feb 14 23:27:52 <rwhitby> I would put a couple of ~1GB rootfs partitions and small swap partitions on the disk (so you can easily swap between different rootfs's), and then use the rest as data storage
Feb 14 23:28:07 <rwhitby> no real need for the usb stick if you have a disk permanently attached
Feb 14 23:29:10 <CoreDump|home> rwhitby: ok
Feb 14 23:29:26 <CoreDump|home> hey upslug2 is in debian testing already
Feb 14 23:29:29 * CoreDump|home cheers
Feb 14 23:29:49 <rwhitby> yep, nslu2 is well supported in debian now
Feb 14 23:39:29 <CoreDump|home> rwhitby: --rootfs=slugosle-4.3-beta-nslu2.bin" and _not_ the jffs2 file right?
Feb 14 23:40:10 <rwhitby> nope, you want -i *.bin
Feb 14 23:40:27 <rwhitby> (since you need to flash kernel, rootfs, and fis dir)
Feb 14 23:40:56 <CoreDump|home> hmmm
Feb 14 23:42:29 <CoreDump|home> ah I get it. *.bin has rootfs and fis dir, *rootfs* is the rootfs partition only
Feb 14 23:42:40 <rwhitby> yep
Feb 14 23:42:56 <CoreDump|home> but the kernel is still extra?
Feb 14 23:42:57 <rwhitby> *.bin is actaully a full 8MB image, including redboot, sysconf, ...
Feb 14 23:43:10 <rwhitby> *.bin has everything
Feb 14 23:43:20 <CoreDump|home> ok
Feb 14 23:44:08 <CoreDump|home> --image=blahh.bin it is then
Feb 14 23:44:09 <rwhitby> (and some of the things in it, like redboot and sysconf, don't actually get written by default, unless you use the dangerous rewrite everything switch in upslug2, or the Linksys EraseAll tool (which is known to brick slugs)
Feb 14 23:44:11 <rwhitby> yes
Feb 14 23:44:38 <CoreDump|home> rwhitby: yeah, rewriting redboot on each flash would suck bad =D
Feb 14 23:45:19 <rwhitby> oh, yeah.  we *never* overwrite the bootloader.
Feb 14 23:45:58 <rwhitby> the *only* $USER cases of bricks are when people used (against our strong public warnings) the Linksys EraseAll tool, and had a power failure (or cat incident) while flashing.
Feb 14 23:46:35 <CoreDump|home> !praise JTAg
Feb 14 23:47:16 <rwhitby> yeah, I've only needed to use JTAG once in over two years, when I was playing around with Apex bootloader replacement.
Feb 14 23:47:36 <CoreDump|home> =)
Feb 14 23:47:45 <CoreDump|home> slugos is booting
Feb 14 23:47:56 <rwhitby> and the only other developer brick I know of that needed Apex was when jacques used a very early prototype version of slugimage that had a bad bug in it.
Feb 14 23:48:03 <rwhitby> s/Apex/JTAG/
Feb 14 23:48:04 <apt_> rwhitby meant: and the only other developer brick I know of that needed JTAG was when jacques used a very early prototype version of slugimage that had a bad bug in it.
Feb 14 23:48:15 <rwhitby> CoreDump|home: do you have serial on it?
Feb 14 23:48:34 <CoreDump|home> rwhitby: not yet, had to order parts first
Feb 14 23:48:45 <CoreDump|home> what's the root p/w?
Feb 14 23:48:51 <rwhitby> ok, so you're getting the real $USER experience
Feb 14 23:48:58 <CoreDump|home> righto
Feb 14 23:49:02 <rwhitby> opeNSLUg
Feb 14 23:49:28 <CoreDump|home> excellent
Feb 14 23:49:35 <rwhitby> now turnup init
Feb 14 23:49:36 <CoreDump|home> "Free Your Slug"
Feb 14 23:51:45 <CoreDump|home> it sais I need to reboot. The settings are kept on flash right?
Feb 14 23:54:53 <rwhitby> yep
Feb 15 00:03:21 <rwhitby> CoreDump|home: ready for turnup disk?
Feb 15 00:05:13 <CoreDump|home> not yet
Feb 15 00:11:11 <rwhitby> bbiab
Feb 15 00:20:18 <CoreDump|home> rwhitby: I turnup disk -i a partition
Feb 15 00:21:29 * CoreDump|home reboots
Feb 15 00:23:27 <CoreDump|home> yay, that was easy
Feb 15 01:00:22 <rwhitby> sweet
Feb 15 01:02:35 <CoreDump|home> I forgot how much I hated the .dev branch
Feb 15 01:03:01 <rwhitby> CoreDump|home: test out "turnup ram" and then scp up a new image into /tmp, then use 'reflash' to flash the new image from inside linux
Feb 15 01:03:46 <CoreDump|home> wow, nice trick
Feb 15 01:04:25 <CoreDump|home> I'll try that another time =)
Feb 15 01:06:52 <rwhitby> of course when altboot supports kexec on nslu2, then we'll just boot into the new kernel from the external disk ...
Feb 15 01:08:39 <rwhitby> CoreDump|home: an altboot ram target would be useful for turnup :-)
Feb 15 01:08:48 <rwhitby> s/turnup/reflash/
Feb 15 01:08:51 <apt_> rwhitby meant: CoreDump|home: an altboot ram target would be useful for reflash :-)
Feb 15 01:11:51 <CoreDump|home> rwhitby: I found a problem with your namechange. MACHINE specific ipk's will be blahh_nslu2le.ipk, however, ipkg's arch.conf doesn't list nslu2* as valid ARCH
Feb 15 01:12:59 <rwhitby> Hmm. I thought I added nslu2* as a PACKAGE_EXTRA_ARCH
Feb 15 01:14:11 <rwhitby> ipkgarchs='all any noarch arm armv4 armv4t armv5e armv5te ixp4xxle nslu2le' in log.do_rootfs
Feb 15 01:14:24 <rwhitby> CoreDump|home: where are you experiencing the problem?
Feb 15 01:14:33 <CoreDump|home> altboot_0.0.0.bb ;)
Feb 15 01:14:47 <CoreDump|home> I pulled yesterday the last time tho
Feb 15 01:15:45 <rwhitby> hmm - you're right - the /etc/ipkg.conf doesn't have nslu2le in it.
Feb 15 01:16:38 <rwhitby> I thought that file would get PACKAGE_EXTRA_ARCHS and MACHINE added automatically
Feb 15 01:16:42 <CoreDump|home> s/ipkg.conf/arch.conf
Feb 15 01:16:49 <rwhitby> right
Feb 15 01:17:08 <CoreDump|home> DEBUG: Couldn't read keyboard ints! 
Feb 15 01:17:34 <CoreDump|home> this is altboot on the slug heh
Feb 15 01:17:45 <rwhitby> CoreDump|home: do you know where /etc/ipkg/arch.conf is generated?
Feb 15 01:17:58 <CoreDump|home> not off-hand, no
Feb 15 01:18:21 <rwhitby> looks like rootfs_ipk.bbclass
Feb 15 01:18:43 <CoreDump|home> somewhere along these lines, yes
Feb 15 01:18:47 <rwhitby> from PACKAGE_ARCHS
Feb 15 01:19:47 <rwhitby> PACKAGE_ARCHS = "all any noarch ${TARGET_ARCH} ${PACKAGE_EXTRA_ARCHS} ${MACHINE}" in bitbake.conf
Feb 15 01:20:03 <rwhitby> so it should get nslu2le from MACHINE
Feb 15 01:21:17 <rwhitby> Doh!  why is slugos-image removing it?
Feb 15 01:21:29 <CoreDump|home> he good question
Feb 15 01:22:09 <rwhitby> ah. that was from when MACHINE was "nslu2", not "nslu2le".  Now it is correct it should not be removed.  Thanks for finding that!
Feb 15 01:22:54 <CoreDump|home> np
Feb 15 01:23:30 <CoreDump|home> which bastardized version of "ps" is slugos using?
Feb 15 01:24:38 <rwhitby> probably busybox
Feb 15 01:26:26 <CoreDump|home> oh well, an error message that nobody (expect folks w/ serial port) can see can probably ignored
Feb 15 01:27:24 <rwhitby> heh - if I see it I won't be ignoring it :-)
Feb 15 01:27:41 <CoreDump|home> =D
Feb 15 01:27:57 <rwhitby> OK, arch.conf fixed and pushed.
Feb 15 01:28:06 * CoreDump|home cheers
Feb 15 01:28:41 <rwhitby> BTW, I always push directly to monotone.nslu2-linux.org using the Master Makefile, and that sync periodically to monotone.openembedded.org, so there is sometimes a delay before CIA reports it in #oe
Feb 15 02:23:57 <VoodooZ> I was reading your discussion w/ CoreDump|home: what does reflash -i update exactly? kernel, rootfs, fis?
Feb 15 02:27:03 <rwhitby> kernel and rootfs at least
Feb 15 02:27:46 <rwhitby> doesn't change FIS
Feb 15 02:28:21 <VoodooZ> ok, that's what I need now.. I guess I could also write the whole darn image to flash using apex but I'm afraid...
Feb 15 02:28:36 <VoodooZ> I'd rather do it from linux like you said...
Feb 15 02:29:28 <rwhitby> just do hexdump compares like I said, and then write it from linux
Feb 15 02:30:32 <VoodooZ> hexdump
Feb 15 02:30:35 <VoodooZ> hexdump
Feb 15 02:30:39 <VoodooZ> oops. 
Feb 15 02:30:59 <CoreDump|home> rwhitby: can we make the buzzer beep at will?
Feb 15 02:32:03 <rwhitby> sure
Feb 15 02:32:23 <CoreDump|home> what's the trick from the shell?
Feb 15 02:32:44 <rwhitby> run /bin/beep
Feb 15 02:33:12 <CoreDump|home> err, I didn't even try "beep" *cry*
Feb 15 02:33:39 <rwhitby> someone even got it to play jingle bells last christmas I think
Feb 15 02:34:00 <CoreDump|home> HEHEHE
Feb 15 02:34:14 <VoodooZ> rwhitby: ok, I've tried hexdump /dev/mtdblock5 and mtd5 but those are small compared to hexbump'ing FIS. yes I'm confused.
Feb 15 02:35:01 <rwhitby> VoodooZ: is the difference the new microcode added to FIS ?
Feb 15 02:36:27 <VoodooZ> sorry, I'm confused about what to diff.
Feb 15 02:37:00 <VoodooZ> can't I just overwrite the darn thing instead?
Feb 15 02:38:55 <VoodooZ> keep in mind that I don't know much about the whole mtd thing. Got any good tutorial?
Feb 15 02:42:52 <rwhitby> VoodooZ: /dev/mtdblock5 is your FIS directory partition
Feb 15 02:43:15 <rwhitby> it's current contents have the FIS directory entries, and the Trailer.
Feb 15 02:43:26 <rwhitby> the new contents have the microcode in the middle as well
Feb 15 02:43:46 <rwhitby> I want you to confirm that the start and the end of the block is unchanged, before you go writing it.
Feb 15 02:44:18 <rwhitby> Since you don't have RedBoot, if you stuff up the FIS are you will need to reload via serial (very slowly).
Feb 15 02:44:58 <VoodooZ> yeah, It's real slow!
Feb 15 02:46:00 <VoodooZ> I guess most people going from 3.10 -> 4.3 didn't have this issue because they used upgrade mode right?
Feb 15 02:46:17 <VoodooZ> I used reflash which doesn't update everything right?
Feb 15 02:52:15 <CoreDump|home> how can I boot to the flash rootfs after turnup disk?
Feb 15 02:52:40 <VoodooZ> turnup flash
Feb 15 02:53:08 <CoreDump|home> VoodooZ: thanks!
Feb 15 02:53:25 <VoodooZ> type turnup by itself for a full usage. I know because I keep forgetting! :)
Feb 15 02:53:39 <CoreDump|home> heh
Feb 15 02:54:12 <VoodooZ> now if I could to the point you are at.. :(
Feb 15 02:54:15 <rwhitby> CoreDump|home: altboot will do "turnup nfs" as well, right?
Feb 15 02:54:28 <CoreDump|home> yeah
Feb 15 02:54:41 <rwhitby> VoodooZ: where are you blocked?
Feb 15 02:55:16 <VoodooZ> at the same place as before. The FIS.
Feb 15 02:55:30 <rwhitby> ok, do you have the current contents in a file? what's the filename?
Feb 15 02:55:35 <VoodooZ> I want to start in a sane state as reflash doesn't flash everything
Feb 15 02:55:49 <VoodooZ> the FIS part extracted from the full image? yes.
Feb 15 02:56:02 <VoodooZ> and it's around 128kbytes.
Feb 15 02:56:20 <VoodooZ> Unless i screwed up of course.
Feb 15 02:58:09 <rwhitby> ok, good.
Feb 15 02:58:29 <rwhitby> now, hexdump -C /dev/mtdblock5 > orig.txt
Feb 15 02:58:43 <VoodooZ> done.
Feb 15 02:58:45 <rwhitby> hexdump -C fis-file > new.txt
Feb 15 02:58:59 <rwhitby> diff orig.txt new.txt
Feb 15 02:59:03 <rwhitby> pastebin the output
Feb 15 02:59:27 <VoodooZ> holy smoke! It's long!
Feb 15 02:59:37 <rwhitby> (both files should be the same size, with similar starting contents and trailer, but with very different middles)
**** ENDING LOGGING AT Thu Feb 15 02:59:57 2007