**** BEGIN LOGGING AT Wed Oct 25 02:59:57 2006
Oct 25 03:09:43 <VoodooZ> test
Oct 25 03:11:37 <dumfrac> VoodooZ: ack
Oct 25 03:15:03 <VoodooZ> thanks
Oct 25 03:15:29 <VoodooZ> I'm trying BitchX for the first time as it's easier than changing my firewall (NAT)
Oct 25 03:15:44 <dumfrac> what is BitchX ?
Oct 25 03:15:55 <VoodooZ> a text mode IRC client
Oct 25 03:18:29 <dumfrac> what does it give you that other IRC clients don't provide ?
Oct 25 03:20:10 <VoodooZ> well, for one I can run it remotely (from work) without having to resort to black magic to go around corporate firewalls.
Oct 25 03:20:39 <VoodooZ> although I'm currently doing it using tinyproxy via an openssh tunnel to hide my "personal" surfing.
Oct 25 03:21:13 <VoodooZ> It's the first time I try it so I'm just testing,,,
Oct 25 03:21:16 <dumfrac> sneaky :-)
Oct 25 03:21:20 <dumfrac> cool
Oct 25 03:21:27 <dumfrac> seems to be working !
Oct 25 03:21:36 <VoodooZ> hehehe you have to be with corporation logging everything you do.
Oct 25 03:22:02 <VoodooZ> I don't do anything illegal. I just monitor the channel from work.
Oct 25 03:23:14 <dumfrac> I'm lucky in that I work for a place that does some amount of logging for security purposes, but they don't really care (yet) what people run
Oct 25 03:23:36 <VoodooZ> yeah, that's nice.
Oct 25 03:24:09 <VoodooZ> sometime they just block stuff for obvious reasons (IRC is used for virus and other nasty stuff).
Oct 25 03:24:17 <VoodooZ> Iguess I don't blame them.
Oct 25 03:24:33 <VoodooZ> Especially now that I work in security/AV!
Oct 25 03:24:56 <dumfrac> :-)
Oct 25 03:25:24 <dumfrac> Have fun - I've got to get some sleep now
Oct 25 05:11:51 <osas> speaking of irc, just got the dircproxy running on openslug
Oct 25 05:14:30 <osas> rwithby: NAiL pushed the sipsak package for me
Oct 25 05:23:08 <NAiL> rwhitby: ping? Could you make a cert for osas?
Oct 25 05:23:22 <rwhitby> NAiL: cert, or OE key?
Oct 25 05:23:45 <rwhitby> osas: hi
Oct 25 05:23:49 <osas> hi
Oct 25 05:23:57 <NAiL> he's working on the stable tree, so a cert first. 
Oct 25 05:24:20 <rwhitby> NAiL: I thought you were the only one who would touch the stable tree
Oct 25 05:24:29 <rwhitby> others check into monotone head first, and you transfer
Oct 25 05:24:58 <rwhitby> (we only want one person with write access to the stable openslug tree)
Oct 25 05:25:21 <NAiL> ok, then OE access, and I'll watch closely :)
Oct 25 05:26:18 <osas> usually I test packages on the stable tree ...
Oct 25 05:26:21 <rwhitby> well, packages are submitted to head, and then people request the openslug package manager add them to the stable feed when they have been proven by multiple people using them successfully in head
Oct 25 05:26:54 <NAiL> which is the "sane" way to handle it
Oct 25 05:27:01 <osas> I don't know how stable is the head, that's why I prefer to compile them against the stable one
Oct 25 05:27:39 <osas> som dunno what the rules are here ...
Oct 25 05:27:51 <osas> s/som/so/
Oct 25 05:27:52 <jbot> osas meant: so dunno what the rules are here ...
Oct 25 05:30:00 <NAiL> rwhitby is right though... you should commit to head first. Makes it easier to keep "stable" stable
Oct 25 05:30:45 <osas> I agree with that.
Oct 25 05:31:17 <osas> my next question is: is it safe to test a package against the stable tree and then make it available on the head?
Oct 25 05:31:25 <NAiL> mostly
Oct 25 05:31:34 <osas> ok then :)
Oct 25 05:31:54 <NAiL> there's always some changes, and some changes might break a package
Oct 25 05:32:28 <NAiL> but if it's a new package, testing against stable and committing to head isn't such a bad thing. Ie, it won't break other builds.
Oct 25 05:32:40 <osas> yup
Oct 25 05:33:00 <osas> in this case, I already have a new package: dircproxy
Oct 25 05:33:24 <osas> I'm connecting through it :)
Oct 25 05:33:33 <NAiL> ah
Oct 25 05:34:02 <osas> http://dircproxy.securiweb.net/
Oct 25 05:34:28 <osas> 1.1.0 works out of the box
Oct 25 05:35:13 <NAiL> cool
Oct 25 05:35:27 <NAiL> just mail me a .bb, and I'll take a look
Oct 25 05:35:36 <osas> ok
Oct 25 05:40:12 <osas> e-mail sent
Oct 25 05:42:19 <NAiL> thanks, I'll look at it after work
Oct 25 05:43:26 <osas> k
Oct 25 06:08:18 <NAiL> btw, regarding PR
Oct 25 06:08:29 <NAiL> when you change to a new release, the PR should be reset, not increased.
Oct 25 06:08:39 <osas> oh ...
Oct 25 06:09:08 <osas> I was checking the 12.1 against the previous one ...
Oct 25 06:09:08 <NAiL> It's to keep track of revisions of the same-version package :)
Oct 25 06:09:31 <osas> then 12.1 is not following the rule
Oct 25 06:09:31 <NAiL> (ie, same tarball, just changes to the .bb)
Oct 25 06:09:53 <NAiL> that happens. Especially if someone copies a .bb and forgets to reset PR
Oct 25 06:10:04 <osas> I will keep in mind that
Oct 25 06:10:16 <osas> now it's bed time for me :)
Oct 25 06:10:59 <osas> thx for your help
Oct 25 06:11:04 <osas> l8r
Oct 25 06:32:10 <NAiL> nite
Oct 25 08:31:38 <CIA-8> 03marcusb * r62 10debian/ixp400-accesslib/trunk/ixp400-accesslib/debian/patches/: Pointed svn:externals to new location archived/intel_eth.
Oct 25 08:53:48 <CIA-8> 03marcusb * r63 10debian/ixp400-accesslib/trunk/ixp400-accesslib/ixp_osal/os/linux/include/core/IxOsalOsTypes.h: Remove bogus setting of __ixp46X macro.
Oct 25 09:03:42 <CIA-8> 03marcusb * r64 10debian/ixp400-accesslib/trunk/ixp400-accesslib/debian/README.Debian: Document use of -ixp4xx kernel flavour instead of obsolete -nslu2.
Oct 25 09:05:24 <[g2]> dumfrac pong
Oct 25 09:08:34 <CIA-8> 03marcusb * r65 10debian/ixp400-eth/trunk/ixp400-eth/debian/patches/: Pointed svn:externals at new location in archived/intel_eth.
Oct 25 10:15:45 <matholio> evening all
Oct 25 10:22:00 <rwhitby> hi matholio 
Oct 25 10:32:05 <dwery> [g2]: the signatures are quite strange:
Oct 25 10:32:07 <dwery> npe: unknown/NPE-A func:  3 rev: bc.f8 size: 1074721228 bytes id:5003bcf8
Oct 25 10:32:07 <dwery> npe: IXP465/NPE-A func: 81 rev: 2.0 size: 12848 bytes id:10810200
Oct 25 10:32:07 <dwery> npe: firmware loaded to NPE-A, func: 81, rev: 2.0, status: 82400000
Oct 25 10:32:07 <dwery> npe: IXP425/NPE-B func:  1 rev: 2.0 size: 12848 bytes id:01010200
Oct 25 10:32:07 <dwery> npe: firmware loaded to NPE-B, func: 1, rev: 2.0, status: 80800000
Oct 25 10:32:08 <dwery> npe: IXP425/NPE-C func:  1 rev: 2.0 size: 12848 bytes id:02010200
Oct 25 10:32:10 <dwery> npe: firmware loaded to NPE-C, func: 1, rev: 2.0, status: 80800000
Oct 25 10:32:12 <dwery> npe: unknown/NPE-O func: ed rev: f0.d size:    16 bytes id:feedf00d
Oct 25 10:32:36 <dwery> it seems there's something like and end marked where magic == byteswap(id)
Oct 25 10:34:00 <dwery> or baybe magic == id..
Oct 25 10:34:21 <rwhitby> dwery: hi
Oct 25 10:34:52 <dwery> hi!
Oct 25 10:35:20 <rwhitby> dwery: the read of microcode from redboot yesterday - how was that done?
Oct 25 10:35:29 <dwery> mtd notifier callback
Oct 25 10:35:32 <dwery> i'm refining the code
Oct 25 10:38:44 <rwhitby> can it be generalised to any mtd partition (or even part of the final block) as a board code parameter?
Oct 25 10:39:06 <dwery> yes
Oct 25 10:39:09 <dwery> already done
Oct 25 10:39:11 <rwhitby> sweet
Oct 25 10:39:39 <rwhitby> so you're doing a patch for the nslu2 to read it from the last block?
Oct 25 10:41:11 <CIA-8> 03rwhitby * r75 10slugimage/trunk/slugimage: slugimage: Added the microcode flag back, and set the FIS directory table partition size correctly.
Oct 25 10:42:15 <dwery> i'm working on a loft now, but you can simply change the mtd parition name in .config and it will read from it
Oct 25 10:43:28 <rwhitby> does it search anywhere in the partition for the magic numbers?
Oct 25 10:43:32 <dwery> [g2] suggested to automatically load only firmwares for NPE B and C
Oct 25 10:43:33 <dwery> yes
Oct 25 10:43:51 <dwery> I need to understand if
Oct 25 10:43:53 <dwery> npe: firmware at 11e88, unknown/NPE-A func:  3, rev: bc.f8, size: 1074721228, id:5003bcf8
Oct 25 10:43:56 <dwery> happened by chance
Oct 25 10:44:00 <dwery> or is something else
Oct 25 10:46:49 <rwhitby> dwery: you did the rtc driver, right?
Oct 25 10:46:55 <dwery> yes
Oct 25 10:47:54 <rwhitby> Just sent you an email regarding the RTC driver and Debian Etch.
Oct 25 10:48:26 <NAiL> rwhitby: btw, do you know why bash isn't built in the fsg3 feed?
Oct 25 10:48:44 <NAiL> I'm having some problems building the kernel
Oct 25 10:48:45 <dwery> reading...
Oct 25 10:48:51 <rwhitby> NAiL: dunno, it was marked as broken
Oct 25 10:48:58 <NAiL> ok
Oct 25 10:49:05 <rwhitby> NAiL: I've built kernel modules right now - will commit it.
Oct 25 10:49:16 <dwery> rwhitby: haven't got the email yet
Oct 25 10:49:24 <NAiL> ah, I'm not actually building a kernel for the fsg3 on the fsg3 ;-)
Oct 25 10:49:32 <NAiL> I'm building a kernel for the n2100 :)
Oct 25 10:49:51 <NAiL> but I haven't experienced any problems with the toolchain as of yet
Oct 25 10:50:30 <CIA-8> 03rwhitby * r4281 10optware/trunk/ (3 files in 2 dirs): fsg3-kernel-modules: Initial version - builds the modules, but doesn't package properly yet.
Oct 25 10:51:04 <NAiL> great work :)
Oct 25 10:51:19 <rwhitby> Completely untested
Oct 25 10:51:59 <NAiL> I'll see if I can get around to testing that later today
Oct 25 10:52:08 <dwery> rwhitby:  my udec works usually
Oct 25 10:52:10 <dwery> udev
Oct 25 10:52:21 <NAiL> Slowly getting my free time back :)
Oct 25 10:52:47 <dwery> rwhitby: KERNEL=="rtc0", SYMLINK += "rtc"
Oct 25 10:53:49 <dwery> i'm answering
Oct 25 10:55:26 <rwhitby> modules should be independent of the softfloat/hardfloat thing that jacques identified yesterday
Oct 25 10:55:29 <rwhitby> bbiab
Oct 25 11:04:30 <dwery> rwhitby: did you run mc_grab on the nslu2? found any image? which version?
Oct 25 11:05:17 <dwery> i need someone to run mc_grab on a BE machine
Oct 25 11:09:16 <dwery> NAiL: BE/LE on any machine you might have ;)
Oct 25 11:10:19 <dwery> anybody know the maximum image size that can be loaded in an NPE?
Oct 25 11:10:42 <NAiL> I've got an fsg-3 running BE
Oct 25 11:10:44 <NAiL> and a slug
Oct 25 11:10:55 <NAiL> n2100 + another slug runs LE
Oct 25 11:11:52 <NAiL> n2100 doesn't have the firmware though :-P
Oct 25 11:12:34 <NAiL> could you make mc_grab available somewhere? Dunno if I get the time to compile anything today :-P
Oct 25 11:13:49 <dwery> let me think
Oct 25 11:14:10 <dwery> no, I don't have a compiled form here :(
Oct 25 11:14:26 <dwery> it's in Documentation/networking/ixp4xx
Oct 25 11:26:06 <CIA-8> 03blaster8 * r517 10kernel/trunk/patches/2.6.18/ (45-eeprom-new-notifier.patch 66-hwmon-ad7418.patch): Refresh latest Loft patches
Oct 25 11:30:56 <CIA-8> 03blaster8 * r518 10kernel/trunk/patches/2.6.18/33-ixp4xx-net-driver-improve-mac-handling.patch: Refresh MAC Handling patch
Oct 25 11:44:56 <dumfrac> [g2] ping
Oct 25 11:56:52 <CIA-8> 03blaster8 * r519 10kernel/trunk/patches/2.6.19/ (2 files): Move new 2.6.18 patches to 2.6.19 tree
Oct 25 11:57:40 <[g2]> dumfrac pong
Oct 25 11:57:54 <dumfrac> hi [g2]
Oct 25 11:58:12 <[g2]> hey dumfrac :)
Oct 25 11:58:14 <dumfrac> finally we connect :-)
Oct 25 11:58:19 <[g2]> yeah :)
Oct 25 11:58:32 <[g2]> feel free to e-mail anytime
Oct 25 11:58:39 <[g2]> but I'm often here 
Oct 25 11:59:01 <dumfrac> what is the status of the redboot.c patch ? are you pretty happy with it or dd you want me to try out the test I proposed ?
Oct 25 11:59:09 <dumfrac> s/dd/did
Oct 25 11:59:38 <dumfrac> I didn't get a chacnce last night as I was fighting with Debian RTC stuff
Oct 25 12:00:56 <[g2]> dumfrac I've been pretty happy witht he latest patch.  Are you referring to the offset check versus the current adjustment and erasesize check ?
Oct 25 12:01:36 <dumfrac> yeah - it seemed to me that the offset check is what you were looking for in the comments you put in the code
Oct 25 12:02:17 <[g2]> well the reason I didn't put it in case because the offset is a flashbase relative address
Oct 25 12:02:35 <[g2]> one still needs to pickup the base flash address and that's the issue
Oct 25 12:02:59 <[g2]> we're missing the 0x50000000 part
Oct 25 12:04:07 <[g2]> I'm guessing that the specific memory address is hidden on purpose
Oct 25 12:05:18 <dumfrac> ah right - I hadn't thought of that - I wanted to know what the priority on the patch was because I have some Debian tests to do
Oct 25 12:05:20 <[g2]> I'm guessing that's part of the reason there are methods on the object for erase, OTP, etc..
Oct 25 12:05:44 <dumfrac> makes sense
Oct 25 12:06:04 <[g2]> so I'm fine with posting to MTD and cc'ing ecos-devel
Oct 25 12:06:57 <[g2]> rwhitby mentioned giving it a little time (I think for review from bewoolie/jacmet)
Oct 25 12:07:16 <dumfrac> ok, sounds good - we can always change it in the future if need be, but for now, it seems to pretty solid (always works for me in my testing)
Oct 25 12:07:35 <[g2]> me too. And THX for all the testing. It really makes things easier
Oct 25 12:07:49 <[g2]> "We enough eyes all problems are shallow"
Oct 25 12:07:52 <[g2]> s/We/With/
Oct 25 12:07:52 <jbot> [g2] meant: "With enough eyes all problems are shallow"
Oct 25 12:08:33 <dumfrac> it's a pleasure - I'm having fun, and contributing to the Slug effort so I'm happy
Oct 25 12:08:59 <[g2]> that's _exactly_ the way it's supposed to be :)
Oct 25 12:09:09 <dumfrac> :-)
Oct 25 12:09:52 <dumfrac> I'm now starting another d-i daily build test...
Oct 25 12:10:36 <[g2]> dumfrac are you tracking dwery's latest changes ?
Oct 25 12:11:40 <dumfrac> I'm not fully up to date on what he has been doing - can you fill me in
Oct 25 12:12:06 <dwery> 0x00000000-0x00080000 : "RedBoot"
Oct 25 12:12:07 <dwery> npe: searching for firmware...
Oct 25 12:12:07 <dwery> npe: found at 0x11e7c, unknown/NPE-A func: 03, rev: c.8, size: 1074721228, id: 5003bcf8
Oct 25 12:12:07 <dwery> npe: found at 0x3f42c, IXP465/NPE-A func: 81, rev: 2.0, size: 12848, id: 10810200
Oct 25 12:12:07 <dwery> npe: found at 0x4265c, IXP425/NPE-B func: 01, rev: 2.0, size: 12848, id: 01010200
Oct 25 12:12:07 <dwery> npe: firmware loaded to NPE-B, func: 01, rev: 2.0, status: 82400000
Oct 25 12:12:09 <dwery> npe: found at 0x4588c, IXP425/NPE-C func: 01, rev: 2.0, size: 12848, id: 02010200
Oct 25 12:12:11 <dwery> npe: firmware loaded to NPE-C, func: 01, rev: 2.0, status: 80800000
Oct 25 12:12:46 <dumfrac> hi dwery
Oct 25 12:13:00 <[g2]> dwery is automatically pulling the NPE microcode from Redboot from within the driver
Oct 25 12:13:02 <dwery> hi!
Oct 25 12:13:08 <dumfrac> so this is implemented in the redboot parsing ?
Oct 25 12:14:29 <[g2]> dunno when it code is < 14 hours old I haven't looked at it yet
Oct 25 12:14:40 <[g2]> s/when/where/
Oct 25 12:14:41 <jbot> [g2] meant: dunno where it code is < 14 hours old I haven't looked at it yet
Oct 25 12:14:50 <dwery> mtd notifier
Oct 25 12:15:31 * [g2] plan for the rest of the week -- become one with notifiers :)
Oct 25 12:15:56 <[g2]> dwery "The notifier master!"
Oct 25 12:16:02 <dwery> :)
Oct 25 12:16:26 <[g2]> jbowler has now been exceeded as notifier master
Oct 25 12:16:51 <[g2]> the notifier master is dead, long live the notifier master :)
Oct 25 12:17:05 <dumfrac> is this in 45-eeprom-new-notifier.patch and is this generic for the slug and loft or specific to one or the other ?
Oct 25 12:17:44 <[g2]> dumfrac I'm wondering what's in the refresh. 
Oct 25 12:18:12 <dumfrac> [g2] the refresh  ?
Oct 25 12:18:47 <[g2]> the original was general for the ixmac_open fix (a delayed MAC assignment) plus a loft notifier which actually pulls the MACs from EEPROM
Oct 25 12:20:07 <[g2]> I'd guess the MTD notifier could be hooked to pull the MAC straight out of Flash in the other platforms (NSLU2, etc...).  dwery thoughts ?
Oct 25 12:20:31 <[g2]> We'll really need to think about what upstream will accept
Oct 25 12:21:22 <dumfrac> that would be great for Debian - I think that is exactly what Debian is looking to ultimately do
Oct 25 12:21:27 <dwery> [g2]: yes, it can be done
Oct 25 12:22:18 <[g2]> dumfrac the issue is that I think L-A-K is looking to push this stuff out of the kernel. I think that's the underlying issue
Oct 25 12:22:45 <[g2]> I think early userspace may be the compromize
Oct 25 12:23:39 <[g2]> s/mize/mise/
Oct 25 12:23:39 <dumfrac> ah right - I thought at one stage that Rod was looking for a userspace script to interface with the driver and get the MAC address and the same thing could be done with the firmware
Oct 25 12:23:39 <jbot> [g2] meant: I think early userspace may be the compromise
Oct 25 12:25:17 <dwery> gtg.. patch later today
Oct 25 12:25:26 <[g2]> dwery THX cheers
Oct 25 12:25:51 <dumfrac> [g2] and dwery: what is gtg ?
Oct 25 12:26:02 <[g2]> got to go
Oct 25 12:26:56 <dumfrac> see you later
Oct 25 12:27:30 <dumfrac> ah right - I figured it out after I had sent the message :-)
Oct 25 13:27:43 <[g2]> blaster8 welcome
Oct 25 13:27:54 <blaster8> hey there
Oct 25 13:28:15 <[g2]> blaster8 I just tested the extra code for the 33-ixp4xx-mac patch
Oct 25 13:28:23 <[g2]> it seems to work 
Oct 25 13:28:25 <blaster8> ok?
Oct 25 13:28:42 <blaster8> the extra code in SVN or the extra code from Christian's email?
Oct 25 13:29:36 <[g2]> lost you there :(
Oct 25 13:30:04 <blaster8> which extra code do you mean :) ?
Oct 25 13:30:24 <[g2]> Ok here's my take where we are at
Oct 25 13:30:58 <[g2]> a) I updated svn yesterday to delay copying the platform mac until ixmac_open
Oct 25 13:31:06 <blaster8> yes
Oct 25 13:31:25 <[g2]> 2) you/christian updated it was bogus as it nails the mac as the platform mac
Oct 25 13:31:51 <blaster8> well, SVN hasn't changed
Oct 25 13:32:01 <blaster8> I've just refreshed/forward ported the patches
Oct 25 13:32:22 <blaster8> I sent the patch to Christian's code off to him so he could check it and incorporate it into his code base
Oct 25 13:32:47 <blaster8> but he raised the problem with MAC address setting which I forwarded to you
Oct 25 13:33:07 <[g2]> sure.  I've got an updated fix that does the dev->hwaddr check  for a zero mac and only uses the platform/random mac then
Oct 25 13:33:40 <[g2]> I had sent out and e-mail earlier and just finished testing
Oct 25 13:34:04 <[g2]> I didn't know if the default dev->hwaddr would be zero but it appears so
Oct 25 13:34:43 <[g2]> so now I can ifdown/ change mac/ ifup and it works
Oct 25 13:34:51 <[g2]> as it should :)
Oct 25 13:34:54 <blaster8> http://pastebin.ca/221039
Oct 25 13:34:59 <blaster8> did you check this over
Oct 25 13:35:23 <blaster8> including the bit about the net driver not being supposed to change the MAC at interface up/down
Oct 25 13:38:52 <[g2]> just read it
Oct 25 13:39:58 <[g2]> ack on the upstream not accepting the change
Oct 25 13:40:41 <blaster8> he suggests an interesting alternative
Oct 25 13:40:57 <blaster8> eeprom notifier specifically handling the MAC address setting
Oct 25 13:41:22 <[g2]> right.
Oct 25 13:41:23 <blaster8> this is a good thing (tm) in one way at least
Oct 25 13:41:28 <blaster8> to explain:
Oct 25 13:41:56 <blaster8> if userspace is going to have to set the MAC address (say...)
Oct 25 13:42:14 <blaster8> then how does it know, reliably, which interface to set it on
Oct 25 13:42:20 <blaster8> and how can it find out?
Oct 25 13:42:54 <[g2]> well the old answer was easy.  It's a machine specific issue
Oct 25 13:43:00 <blaster8> at least if the MAC address setting code is within kernelspace
Oct 25 13:43:15 <blaster8> then it can reliably find out which driver controls which interface
Oct 25 13:43:43 <[g2]> it's a Loft/Avila/IXDP425 they all have there MAC at that place in EEPROM
Oct 25 13:44:26 <[g2]> it's an machine specifc issue, just like the number of PCI enumerations
Oct 25 13:44:34 <blaster8> so we have to argue that we need a specialist MAC extractor piece of code
Oct 25 13:44:47 <[g2]> nope
Oct 25 13:44:51 <blaster8> ? ok
Oct 25 13:45:10 <[g2]> the kernel guys have basically said they don't want to maintain all that garbabe
Oct 25 13:45:20 <[g2]> s/garbabe/garbage/
Oct 25 13:45:21 <jbot> [g2] meant: the kernel guys have basically said they don't want to maintain all that garbage
Oct 25 13:45:40 <[g2]> so they want to push that out to early userspace
Oct 25 13:46:00 <blaster8> well, I can see their point, to some extent
Oct 25 13:46:06 * [g2] too
Oct 25 13:46:08 <dwery> back
Oct 25 13:46:10 <blaster8> I mean, we need userspace to bring up the NPE anyway
Oct 25 13:46:19 <dwery> [g2] I'm quite lost behind this mac thingy ;)
Oct 25 13:46:20 <[g2]> well dwery doesn't :)
Oct 25 13:46:55 <[g2]> dwery what do you mean ?
Oct 25 13:47:24 <dwery> I mean the matter is becoming complex day after day
Oct 25 13:47:35 <dwery> so.. I take care of the firmware
Oct 25 13:47:43 <dwery> can you handle the mac thing?
Oct 25 13:47:54 <[g2]> dwery sure
Oct 25 13:47:57 <dwery> thanks!
Oct 25 13:48:10 <[g2]> dwery thanks for showing me the way
Oct 25 13:48:49 <[g2]> blaster8 ok so back the the sorted MAC issue
Oct 25 13:48:52 <dwery> np
Oct 25 13:49:04 <[g2]> s/the the/to the/
Oct 25 13:49:04 <jbot> [g2] meant: blaster8 ok so back to the sorted MAC issue
Oct 25 13:49:27 <blaster8> [g2]: are you using an initramfs on the Loft?
Oct 25 13:49:35 <[g2]> blaster8 nope
Oct 25 13:49:47 <[g2]> blaster8 there are two problems
Oct 25 13:49:58 <blaster8> fire away
Oct 25 13:50:48 <[g2]> 1) using the EEPROM MAC for compiled in ixp modules (loadable already works fine)
Oct 25 13:51:01 <[g2]> 2) loading the NPE firmware
Oct 25 13:52:29 <[g2]> dwery your patch deals with 2) right and you are still working on that correct ?
Oct 25 13:52:42 <dwery> yes, will be in svn in 10/20 mins
Oct 25 13:53:14 <[g2]> dwery ok are you changing the 33- patch at all ?
Oct 25 13:53:21 <dwery> no
Oct 25 13:53:25 <[g2]> ok super
Oct 25 13:54:08 <[g2]> blaster8 so that leaves us with the following issue
Oct 25 13:54:47 <blaster8> right
Oct 25 13:54:55 <[g2]> Some platform specific notifier just update the device MACs
Oct 25 13:55:15 <[g2]> which begs the question of which devices get which macs
Oct 25 13:55:46 <[g2]> in the Loft's case there can be 5 or 6 networking devices
Oct 25 13:55:58 <[g2]> eth0/1 + 3 or 4 PCI devices
Oct 25 13:56:14 <dwery> + two usb hubs, each with 7 devices
Oct 25 13:56:22 <dwery> :)
Oct 25 13:56:45 <[g2]> well you can have 120+ devices in theory on USB
Oct 25 13:56:53 <dwery> ehehe..ok, back coding
Oct 25 13:58:00 <[g2]> blaster8 so for now I think the code (with the latest fix) is about as close as we are going to get until there's a proper upstream resolution on the issue
Oct 25 13:58:17 <[g2]> meaning something upstream can tolerate
Oct 25 13:58:33 <blaster8> well, we really need something upstream can tolerate now
Oct 25 13:58:38 <blaster8> for preference
Oct 25 13:58:57 <[g2]> blaster8 the current open IXP driver is not in any shape to go upstream
Oct 25 13:59:15 <[g2]> this is specific to that
Oct 25 13:59:15 <blaster8> ? it's not that bad
Oct 25 13:59:30 <blaster8> but no, it's not going upstream soon
Oct 25 14:00:22 <[g2]> well there's lots of issues like moving it out of the IXP4xx tree and supporting the other Micro engines etc...
Oct 25 14:01:49 <[g2]> so that means the Loft specific notifier patch simply needs to be moved from the 65- patch to a 3x-loft-eeprom-notifer patch
Oct 25 14:03:01 <[g2]> and someone can add a MTD patch for the nslu2 or other platforms to hande the cases where the make is pull from RedBoot/Config where-ever
Oct 25 14:03:44 <[g2]> but the nslu2 has bigger fish to fry like where the NPE microcode coming from and how does it get loaded
Oct 25 14:05:21 <[g2]> blaster8 all clear ? agree / not agree ?
Oct 25 14:08:16 <blaster8> hold on
Oct 25 14:10:12 <blaster8> surely the Loft also cares where the NPE microcode comes from?
Oct 25 14:12:05 <blaster8> the Loft support patch and the Loft EEPROM notifier support patch should be separated
Oct 25 14:12:14 <blaster8> but the Loft patch needs reworking before it goes upstream too
Oct 25 14:14:32 <dwery> yes.. we need to separate loft from avila/ixdp for clearness
Oct 25 14:14:56 <blaster8> no
Oct 25 14:15:05 <blaster8> avila needs to be separated from ixdp
Oct 25 14:15:23 <blaster8> as far as I can see, loft can probably stay together with avila
Oct 25 14:15:46 <CIA-8> 03azummo * r520 10kernel/trunk/patches/2.6.19/ (33-ixp4xx-net-driver-mtd-load-fw.patch series): Load ixp4xx npe firmware from mtd partition (RedBoot)
Oct 25 14:16:07 <blaster8> I'm not sure I like the look of that either :(
Oct 25 14:16:15 <dwery> blaster8: right, I inverted the names
Oct 25 14:16:25 <blaster8> ok good
Oct 25 14:16:27 <dwery> [g2]: fw patch in svn
Oct 25 14:16:33 <dwery> never tested in BE
Oct 25 14:16:43 <[g2]> dwery thx
Oct 25 14:16:53 <dwery> I'd appreciate having relevant dmesg lines for every ixp4xx platform
Oct 25 14:18:00 <blaster8> dwery: I'm uncertain upstream are going to be happy about loading firmware from mtd partitions
Oct 25 14:18:11 <dwery> only firmware with funcition == 1 will be loaded
Oct 25 14:18:55 <dwery> blaster8: nor do I, but I don't want to loos time in creating an initram fs
Oct 25 14:19:03 <blaster8> hmm
Oct 25 14:19:09 <dwery> I needed it in order for nfsroot to work so I just did it ;)
Oct 25 14:19:27 <[g2]> blaster8 our repo is a staging area for upstream
Oct 25 14:19:27 <blaster8> rwhitby won't like it, and I'm not a fan either
Oct 25 14:19:55 <blaster8> the prevailing attitude is: it's going upstream or its out
Oct 25 14:20:14 <dwery> it's just there for convenience, it can be removed even today.. I just wanted to share it for a quick test
Oct 25 14:20:16 <blaster8> actually, we're already breaking those rules with what's in the 2.6.18 directory
Oct 25 14:20:40 <dwery> the whole ixp4xx net driver breaks the rules :)
Oct 25 14:20:53 <blaster8> no, the ixp4xx is being prepared for upstream
Oct 25 14:21:07 <dwery> being prepared means it shoudl reworked a lot
Oct 25 14:21:13 <blaster8> stuff which can't be sent upstream, because they won't accept it shouldn't be in SVN
Oct 25 14:21:15 <dwery> they way it is it will never go in
Oct 25 14:21:18 <[g2]> blaster8 and these changes are all specifically related to the ixp4xx driver
Oct 25 14:21:19 <blaster8> it's a fine distinction
Oct 25 14:21:52 <blaster8> I'm just saying we can't be adding features which upstream will tell us to go to hell with
Oct 25 14:22:15 <dwery> i can remove from the repo at anytime, but I needed that feature for moving on something else
Oct 25 14:22:36 <blaster8> I think it should be in local trees unfortunately, sorry
Oct 25 14:22:43 <dwery> ok, going to remove it.
Oct 25 14:22:51 <dwery> [g2]: did you downloaded it
Oct 25 14:22:54 <dwery> ?
Oct 25 14:23:05 <blaster8> dwery: when you remove it, it will still be there
Oct 25 14:23:08 <blaster8> :)
Oct 25 14:23:12 <dwery> :)
Oct 25 14:23:12 <[g2]> dwery not yet, but I'm sure you can e-mail
Oct 25 14:23:18 <blaster8> http://trac.nslu2-linux.org/kernel/browser/trunk/patches/2.6.19/33-ixp4xx-net-driver-mtd-load-fw.patch?rev=520&format=txt
Oct 25 14:23:24 <blaster8> that link won't stop working
Oct 25 14:23:28 <dwery> great.
Oct 25 14:23:51 <blaster8> can initramfs be built into the kernel?
Oct 25 14:24:31 <dwery> done.
Oct 25 14:24:32 <CIA-8> 03azummo * r521 10kernel/trunk/patches/2.6.19/ (33-ixp4xx-net-driver-mtd-load-fw.patch series): removed due uncertainity about upstream acceptance
Oct 25 14:24:32 <[g2]> blaster8 talk to rwhitby about what you want to do the nslu2-linux kernel repo about this ixp4xx driver stuff
Oct 25 14:24:50 <blaster8> think about it in terms of features
Oct 25 14:25:02 <dwery> i'm now moving to pata/cd
Oct 25 14:25:03 <dwery> cf
Oct 25 14:25:16 <blaster8> we can't put things in SVN which add features which upstream don't want
Oct 25 14:25:29 <blaster8> so the ixp4xx driver at the moment contains only features which upstream will want
Oct 25 14:25:35 <[g2]> blaster8 you're missing the whole point
Oct 25 14:25:38 <blaster8> ?
Oct 25 14:26:09 <[g2]> blaster8 you are being pedantic about the changes
Oct 25 14:26:14 <blaster8> indeed
Oct 25 14:26:19 <[g2]> which is fine
Oct 25 14:26:31 <blaster8> because if we add features to SVN which people grow to depend on
Oct 25 14:26:35 <blaster8> then upstream reject them
Oct 25 14:26:42 <blaster8> we are in trouble
Oct 25 14:26:49 <[g2]> you've been a tremenduous help in moving this stuff forward
Oct 25 14:27:23 <[g2]> however you are confused about the upstream process and the quickest way to get there
Oct 25 14:27:34 <blaster8> ok, please explain
Oct 25 14:28:15 <[g2]> you think that by having these patches in the open ixp4xx that we are intending to send them upstream
Oct 25 14:28:37 <blaster8> not quite, but go on
Oct 25 14:28:45 <[g2]> where that's not the case.  The open ixp4xx is immature and needs lov'in
Oct 25 14:29:08 <dwery> [g2] is a careful daddy :)
Oct 25 14:29:15 <blaster8> indeed
Oct 25 14:29:47 <blaster8> ok, that's fine
Oct 25 14:30:12 <[g2]> blaster8 so you and rwhitby and anybody else can decide what you want to have in the repo and I'll abide by your decisions
Oct 25 14:30:12 <blaster8> but if we add a feature to the open ixp4xx which upstream won't accept, how is that good?
Oct 25 14:30:46 <blaster8> the status of ixp4xx driver in the repo is to help prepare it for upstream
Oct 25 14:31:02 <blaster8> unlike many of the other patches, this is going to be a much longer process, unfortunately
Oct 25 14:31:25 <blaster8> but, as I see it, that process will not be made shorter by adding features to the driver which upstream are unlikely to accept
Oct 25 14:31:52 <blaster8> technically, even the eeprom notifier stuff is on a knife-edge
Oct 25 14:32:10 <[g2]> blaster8 I've state my position about the patches make your decision
Oct 25 14:32:27 <[g2]> i'ts trivial to pull the patches
Oct 25 14:32:35 <blaster8> what, the eeprom stuff?
Oct 25 14:32:47 <blaster8> if so, it's not our decision to make
Oct 25 14:33:04 <blaster8> We've queried whether upstream will accept them
Oct 25 14:33:11 <blaster8> If upstream say yes, then they stay
Oct 25 14:33:27 <blaster8> If upstream say no, then they go, at least from 2.6.19
Oct 25 14:33:29 <[g2]> who sent the notifer patch upstream ?
Oct 25 14:33:32 <blaster8> no-one
Oct 25 14:33:48 <[g2]> so then what are you talking about ?
Oct 25 14:34:01 <blaster8> no, we are checking the principle
Oct 25 14:34:17 <blaster8> 'Can MAC addresses stored external from a NIC be set by the kernel?'
Oct 25 14:34:29 <blaster8> We've asked Deepak, and he hasn't got back to us
Oct 25 14:35:21 <[g2]> blaster8 "set by the kernel" isn't nearly specific enough
Oct 25 14:35:27 <blaster8> it's the first step
Oct 25 14:35:55 <[g2]> look upstream has made their intentions pretty clear (meaning early userspace)
Oct 25 14:36:01 <blaster8> no, they haven't
Oct 25 14:36:01 <dwery> l-a-k is sometimes slow to accept changes...
Oct 25 14:36:10 <dwery> we just need some patience
Oct 25 14:36:18 <blaster8> [g2]: they have not made themselves clear - hold on and I will show you
Oct 25 14:36:58 <blaster8> [g2]: http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=3596/1
Oct 25 14:37:02 <blaster8> Note 5
Oct 25 14:37:15 <blaster8> "I would like to see a clean version of the driver in the tree before we put this type of workaround into the tree. Ideally the driver would be a platform device driver so that the board level code can pass the MAC address instead of needing a notifier."
Oct 25 14:37:22 <blaster8> that's from Deepak in June
Oct 25 14:37:51 <blaster8> now we have an ixp4xx driver that may one day be suitable for kernel inclusion, we have asked him to clarify this statement
Oct 25 14:38:18 <dwery> I would agree with deepak but there isn't a way to read eeprom without using the notifier patch
Oct 25 14:38:45 <[g2]> blaster8 I'm guessing you are referring to "so that the board level code can pass the MAC address instead of needing a notifier. "
Oct 25 14:39:30 <blaster8> Not really, I'm referring to the principle that externally stored MAC addresses can be set by the kernel rather than by early userspace
Oct 25 14:39:53 <[g2]> there's already a platform MAC, we are just discussing how it gets intitialized properly and under what conditions it works
Oct 25 14:40:02 <[g2]> two actually
Oct 25 14:40:24 <blaster8> [g2]: I've forwarded you the email sent to Deepak by Rod last week
Oct 25 14:40:39 <blaster8> afaik there has been no reply
Oct 25 14:41:17 <[g2]> blaster8 yeah Deepak has been really busy the last 6+ months, it's either 46x stuff or other things
Oct 25 14:41:34 <blaster8> so that email is where we are now in the negotiations with upstream about setting externally stored MAC addresses by the kernel - i.e. at a very early stage
Oct 25 14:43:15 <blaster8> my suggestion would be to get initramfs going asap
Oct 25 14:44:39 <[g2]> blaster8 you're totally missing the point
Oct 25 14:44:42 <blaster8> if we can get a solid debian-compatible initramfs containing mdev and ixp4xx modules together with firmware extraction from mtd partitions and MAC address setting from userspace we don't even need to deal with upstream at all
Oct 25 14:44:53 <blaster8> [g2]: how am I missing the point?
Oct 25 14:46:00 <[g2]> there are others that have _zero_ interest in the concerns of "initramfs" etc....
Oct 25 14:46:07 <blaster8> like?
Oct 25 14:46:26 <[g2]> that's absolutely the correct technical thing to do and look into
Oct 25 14:46:36 <[g2]> I personally plan on doing it myself
Oct 25 14:46:59 <blaster8> I'm confused by this statement: 'there are others that have _zero_ interest in the concerns of "initramfs" etc....'
Oct 25 14:47:11 <blaster8> who are the others? what are the concerns?
Oct 25 14:47:47 <[g2]> commercial clients
Oct 25 14:48:08 <blaster8> that's fine
Oct 25 14:48:14 <blaster8> just keep it in your local tree
Oct 25 14:48:56 <[g2]> blaster8 as I've said before, just say the word
Oct 25 14:49:11 <blaster8> it's not up to us [g2]
Oct 25 14:49:14 <blaster8> it's up to upstream
Oct 25 14:49:24 <blaster8> and they haven't made the pronouncement yet
Oct 25 14:49:34 <blaster8> (in fact we haven't even got to that question ;) )
Oct 25 14:49:42 <blaster8> ok
Oct 25 14:49:48 <[g2]> which makes this discussion mute
Oct 25 14:49:52 <blaster8> indeed
Oct 25 14:50:25 <blaster8> except for the fact that it may be a good idea to just do everything in user space
Oct 25 14:50:50 <blaster8> rather than working on kernel patches which we may have to jettison at a later date
Oct 25 14:51:00 <blaster8> just a suggestion, mind
Oct 25 14:53:41 <dwery> I personally hate using early userspace and that's why I coded my own patch.
Oct 25 14:54:05 <blaster8> that's fine
Oct 25 14:54:41 <blaster8> but if upstream tells us that's what we have to do, we have little choice
Oct 25 14:54:44 <dwery> sure
Oct 25 14:54:46 <blaster8> except to fork of course ;)
Oct 25 14:54:53 <dwery> I haven't said we should keep the patch
Oct 25 14:54:55 <dwery> :)
Oct 25 14:55:13 <blaster8> cool
Oct 25 14:55:18 <dwery> but I will keep it for my own work ;)
Oct 25 14:55:29 <blaster8> it's an elegant solution
Oct 25 14:56:25 <blaster8> I'm sorry I'm having to act as self-appointed Kernel Repo police
Oct 25 14:56:43 <dwery> np
Oct 25 14:57:04 <dwery> back in the days it was rwhitby and me who pushed for "up or out"
Oct 25 14:57:15 <blaster8> hehe
Oct 25 14:57:42 <dwery> as a result, I had to push up the whole new rtc class subsystem :-D
Oct 25 14:59:10 <blaster8> good thing too
Oct 25 15:12:27 <dumfrac> does anybody know why CONFIG_GENERIC_TIME (11-ixp4xx-clocksource.patch) is not set in defconfig for svn 2.6.18 kernel ?
Oct 25 15:14:56 <dwery> scsi 0:0:0:0: Direct-Access     ATA      SanDisk SDCFB-51 HDX  PQ: 0 ANSI: 5
Oct 25 15:15:07 <dwery> SCSI device sda: 1000944 512-byte hdwr sectors (512 MB)
Oct 25 15:16:05 <blaster8> dumfrac: not sure, but...
Oct 25 15:16:13 <blaster8> well done dwery, if that's what I think it is
Oct 25 15:16:22 <dwery> I hope so ;)
Oct 25 15:16:35 <blaster8> dumfrac: probably something to do with our clocksource backport
Oct 25 15:16:51 <dumfrac> blaster8: clocksource backport ?
Oct 25 15:17:07 <blaster8> ixp4xx clocksource support is in 2.6.19-rc1, but not 2.6.18
Oct 25 15:17:14 <dwery> [g2]: 
Oct 25 15:17:14 <dwery> 9952+0 records in
Oct 25 15:17:14 <dwery> 9952+0 records out
Oct 25 15:17:14 <dwery> 5095424 bytes transferred in 5.349326 seconds (952536 bytes/sec)
Oct 25 15:17:19 <dumfrac> so this patch is a backport ?
Oct 25 15:17:23 <blaster8> however, we need it in our 2.6.18 because it contains a fixup for our broken timer
Oct 25 15:17:25 <dwery> that should be reading speed
Oct 25 15:18:02 <dumfrac> the 66 MHz versus 66.666666 MHz issue ?
Oct 25 15:18:08 <blaster8> dumfrac: yes
Oct 25 15:18:29 <dumfrac> ok - I'm going to try it out in Debian this evening
Oct 25 15:18:42 <[g2]> dwery cool that's on the Loft with .19-rc3 ?
Oct 25 15:18:52 <dwery> yes. without interrupts.
Oct 25 15:19:00 <blaster8> can you check if the kernel time keeps good time, dumfrac?
Oct 25 15:19:11 <[g2]> nearly 1MBs
Oct 25 15:19:21 <blaster8> if it does, then I'd just leave it as it is...
Oct 25 15:19:44 <dwery> [g2]: I must now do some sanity checks
Oct 25 15:20:03 <[g2]> dwery any patches needed ?
Oct 25 15:20:24 <dwery> yes, a small change to libata, loft platform + pata driver
Oct 25 15:20:31 <dumfrac> I think that it doesn't - ntp keeps on getting further and further out of sync unless I do tickadj 10101 so I suspect that it needs the patch
Oct 25 15:20:35 <dwery> I will be sending them to you in a few mins
Oct 25 15:20:55 <[g2]> dwery super I'll be able to do some testing on that
Oct 25 15:21:06 <dwery> [g2]: you moved to rc3?
Oct 25 15:21:09 <blaster8> [g2]: time to fix up Loft patches for upstream, then :)
Oct 25 15:21:38 <dwery> yep. If someone can take care to separate the platforms
Oct 25 15:21:45 <dwery> (loft/avila/ixdp)
Oct 25 15:21:48 <dwery> I will add the other bits
Oct 25 15:22:42 <[g2]> dwery when does the next window open ?
Oct 25 15:22:55 <[g2]> for upstream changes ?
Oct 25 15:22:58 <blaster8> no idea
Oct 25 15:23:06 <dwery> mm dunno.. but given the change required for libata
Oct 25 15:23:15 <dwery> it will require a bit mor eprobably
Oct 25 15:23:16 <blaster8> but the sooner the patches are done, the better for merging
Oct 25 15:23:23 <dwery> unless I manage to fix the interrupts..
Oct 25 15:23:43 <dwery> it seems I'm able to read what I write to the card
Oct 25 15:23:56 * [g2] wants to run bonnie++
Oct 25 15:24:25 <dwery> writing is 165455 bytes/sec
Oct 25 15:24:44 <blaster8> dwery: is this BE/LE compatible, in theory
Oct 25 15:24:51 <dwery> I really hope so
Oct 25 15:25:05 <blaster8> you will need to test it, unfortunately
Oct 25 15:25:05 <dwery> maybe [g2] will be able to test
Oct 25 15:25:12 <dwery> as I have only LE environment
Oct 25 15:25:17 <blaster8> as 'no sane hardware developer should run ixp4xx LE'
Oct 25 15:25:21 <[g2]> dwery 1st LE testing 
Oct 25 15:25:26 <blaster8> (until we sort out data-coherent mode)
Oct 25 15:25:33 <dwery> eheh.. in fact, the only reason
Oct 25 15:25:51 <dwery> for me to use the NSLU2 it was that Peter K. enabled in in LE
Oct 25 15:25:58 <dwery> so that Debian was usable.
Oct 25 15:26:15 <dwery> without Peter I won't be there probably :)
Oct 25 15:26:20 <dwery> so blame on him! :D
Oct 25 15:26:59 <blaster8> as soon as [g2] gets a web-enabled Loft development kit online we should be able to start making baby steps towards making LE properly supported
Oct 25 15:27:07 <dwery> that would be good
Oct 25 15:27:19 <blaster8> another major upstream faf though
Oct 25 15:27:51 <[g2]> blaster8 web-enabled Loft dev kit ?
Oct 25 15:27:56 <blaster8> yeah
Oct 25 15:28:03 <blaster8> hosted by ka6sox
Oct 25 15:28:16 <blaster8> software controlled power and remote serial connections
Oct 25 15:28:48 <blaster8> I'm going to try and fix up the same thing for the NSLU2 next summer at home
Oct 25 15:28:50 <[g2]> ok. I'm waiting for lennert and christian to figure out how to progress
Oct 25 15:28:58 <blaster8> why?
Oct 25 15:29:08 <blaster8> Are they even talking?
Oct 25 15:29:33 <[g2]> I know I could have the IXP upstream in several weeks as I've spoked to lennert about how long it would take him to get it upstream
Oct 25 15:29:50 <[g2]> I trust lennert alot on upstream matters
Oct 25 15:29:53 <blaster8> well, it's not quite that simple
Oct 25 15:29:58 <blaster8> now there are crypto drivers too
Oct 25 15:30:14 <dwery> blaster8: we have crypto?
Oct 25 15:30:18 <blaster8> yes
Oct 25 15:30:22 <dwery> working?
Oct 25 15:30:24 <blaster8> but it's not released yet
Oct 25 15:30:29 <blaster8> well, apparently
Oct 25 15:30:33 <[g2]> blaster8 again, it's GPL anyone _could_ send it upstream
Oct 25 15:30:35 <dwery> it's downloadable?
Oct 25 15:30:46 <blaster8> no, still in private CVS
Oct 25 15:30:49 <dwery> :(
Oct 25 15:31:04 <blaster8> should be out very soon - email Christian if you want to look at the code
Oct 25 15:31:07 <[g2]> blaster8 however, it doesn't make any sense not to try and work hand-in-hand with christian
Oct 25 15:31:15 <dwery> I'd love to benchmark some MD5 on NPE-A
Oct 25 15:31:22 <blaster8> NPE-A?
Oct 25 15:31:30 <dwery> [g2]: I've sent the patches
Oct 25 15:31:35 <blaster8> Crypto is in NPE-C
Oct 25 15:31:36 <[g2]> loft's have another NPE
Oct 25 15:31:47 <blaster8> NPE-A has not crypto support
Oct 25 15:31:55 <dwery> doh!
Oct 25 15:32:04 <[g2]> blaster8 we've got IXP425s
Oct 25 15:32:11 <blaster8> only NPE-C - and the crypto support co-exists with running an ethernet mac
Oct 25 15:32:14 <[g2]> 533Mhz ones at that
Oct 25 15:32:17 <blaster8> [g2]: I worked this out :)
Oct 25 15:32:21 <blaster8> with your help, mind
Oct 25 15:32:34 <dwery> oooh wel... too many NPEs :)
Oct 25 15:32:38 <blaster8> nota bene: 'crypto support co-exists with running an ethernet mac'
Oct 25 15:32:52 <blaster8> NPE-A is only useful as a DMA engine, with the Avila/Loft
Oct 25 15:33:06 <dwery> now tell me that we also have code for that :)
Oct 25 15:33:15 <[g2]> or with the Utopia/NPE-A stuff
Oct 25 15:33:35 <[g2]> dwery has a header for that too
Oct 25 15:33:56 <blaster8> ok, fine
Oct 25 15:34:03 <blaster8> dwery: no code for DMA yet
Oct 25 15:34:10 <dwery> ok :)
Oct 25 15:34:18 <blaster8> dwery: waiting on the updates to the DMA API before I push that
Oct 25 15:34:33 <blaster8> push, meaning, push someone else to write it (of course)
Oct 25 15:34:33 <dwery> I just need some quick MD5 bashing machine... and awaiting for the Cell processor on the PS3
Oct 25 15:34:38 <dwery> blaster8: :D
Oct 25 15:34:44 <blaster8> :p
Oct 25 15:35:11 <[g2]> s/MD5/SHA1/
Oct 25 15:35:26 <[g2]> MD5's have collisions 
Oct 25 15:36:05 <dwery> yes, In fact I have to collide it :)
Oct 25 15:36:09 <dwery> need to resolve some MD5
Oct 25 15:36:47 <dwery> here is dmesg from pata driver http://rafb.net/paste/results/mKjlyG99.html
Oct 25 15:37:30 <[g2]> dwery cool. I'm excited about that
Oct 25 15:37:49 <dwery> I forgot I had a filesystem on the cf and blasted it with zeros ;)
Oct 25 15:38:22 <dwery> ok, ext3 created succesfully on the cf
Oct 25 15:38:26 <[g2]> WHOA! dwery you may be in big trouble
Oct 25 15:38:30 <blaster8> ?
Oct 25 15:38:55 <dwery> the telco is going to cut my ADSL? :)
Oct 25 15:39:12 <dwery> I cannot see anything else that could be called "big trouble" :)
Oct 25 15:39:24 <[g2]> no, jbowler, just posted, I think he's gonna displace you as the "notifier master" !
Oct 25 15:39:43 <[g2]> lmao 
Oct 25 15:39:48 <dwery> he posted?
Oct 25 15:39:55 <dwery> where? I would LOVE to have him bach here
Oct 25 15:39:58 <dwery> back
Oct 25 15:40:30 <[g2]> dwery check your mail
Oct 25 15:40:39 <blaster8> it's on nslu2-devel
Oct 25 15:40:57 <blaster8> he wants firmware pull from mtd in kernelspace too ;)
Oct 25 15:42:02 <[g2]> jbowler has a Loft too
Oct 25 15:42:15 <dwery> maybe I haven't received the email yet
Oct 25 15:42:37 <[g2]> no you weren't on the original list, I just forwarded it to you
Oct 25 15:42:48 <[g2]> but it is on the devel-list
Oct 25 15:44:10 <dwery> [g2]: thanks, I've got the email. It seems that some emails in -devel do not reach me. Il'' have to check my spamassassing.
Oct 25 15:44:22 <dwery> [g2]: so please forward him my mtd patch :)
Oct 25 15:45:05 <[g2]> dwery I'm sure you can just e-mail him the patch
Oct 25 15:45:16 <[g2]> if you want me to I'll be happy to also
Oct 25 15:45:20 <dwery> yes please
Oct 25 15:45:30 <dwery> still testing the cf ;)
Oct 25 15:46:23 <dwery> filesystem is ok. We just need BE validation, but I guess it will work
Oct 25 15:46:33 <blaster8> I've sent out a response to that mail with a couple of updates
Oct 25 15:47:17 <[g2]> dwery I don't have the mtd patch handy can you e-mail ?
Oct 25 15:47:33 <blaster8> [g2]: it's still on the web
Oct 25 15:47:40 <dwery> ok
Oct 25 15:47:48 <blaster8> http://trac.nslu2-linux.org/kernel/browser/trunk/patches/2.6.19/33-ixp4xx-net-driver-mtd-load-fw.patch?rev=520&format=txt
Oct 25 15:48:33 <[g2]> blaster8 again you missing the fact that I want to include other patches like the CF too
Oct 25 15:48:59 <blaster8> sorry, you said 'the mtd patch'
Oct 25 15:49:28 <[g2]> blaster8 np, I asked for the "mtd patch", but that wasn't the _only_ thing I had in mind
Oct 25 15:49:29 <blaster8> the libata CF patch can go into 2.6.19-rc3 SVN ASAP :)
Oct 25 15:49:47 <blaster8> brb
Oct 25 15:49:52 <[g2]> blaster8 I don't expect you to be a mind reader
Oct 25 15:52:10 <dwery> [g2]: i've still problems with USB... please give it a try on rc3 when you have time
Oct 25 15:52:27 <[g2]> dwery sure, most likely later today
Oct 25 15:52:52 <[g2]> first I want to boot on 19-rc3 onto the CF drive
Oct 25 15:53:01 <[g2]> then I can mount and test USB
Oct 25 15:53:31 <dwery> I forgot you always booted from CF :)
Oct 25 15:53:53 <[g2]> dwery no I always usually boot to USB
Oct 25 15:54:27 <[g2]> however, I've been testing on 128MB units and a couple I got from someone have no USB
Oct 25 15:56:09 <dwery> [g2]: which version of redboot do you have? 
Oct 25 15:56:19 <[g2]> 2.02
Oct 25 15:57:05 <[g2]> the one that fully supports the -m disk option for the CF
Oct 25 15:57:05 <dwery> I wonder if they changed the NPE firmware
Oct 25 15:57:39 <[g2]> there was a tweak in Mar '06 but I don't think NPE stuff changed
Oct 25 15:57:55 <[g2]> dwery I've got all the source and have built my own RedBoots
Oct 25 15:58:02 <[g2]> and flashed them :)
Oct 25 15:58:12 <dwery> eheh ;)  so it seems Christian understood how to reverse eng the NPE microcode
Oct 25 15:58:22 <blaster8> ?
Oct 25 15:59:17 <dwery> I mean, I managed to do crypto.. so I thought I had to write some microcode for it, right?
Oct 25 15:59:21 <dwery> s/I/He/
Oct 25 15:59:21 <jbot> dwery meant: He mean, I managed to do crypto.. so I thought I had to write some microcode for it, right?
Oct 25 15:59:24 <blaster8> no
Oct 25 15:59:34 <dwery> wrong regexp :)
Oct 25 15:59:36 * VoodooZ still wonders if anybody got glibc 2.4/2.5 working on the slug...
Oct 25 15:59:42 <blaster8> Crypto microcode can be downloaded from the Intel website
Oct 25 15:59:54 <blaster8> it just requires another layer of authentication
Oct 25 15:59:59 <dwery> oh
Oct 25 16:00:08 <blaster8> VoodooZ: Some of the gentoo guys have
Oct 25 16:00:21 <dwery> [g2]: your redboot has three microcodes, so I suppose the third one is crypto, right?
Oct 25 16:00:31 <blaster8> doubt it (export regulations)
Oct 25 16:00:39 <blaster8> but you never know...
Oct 25 16:00:47 <VoodooZ> blaster8, yeah, was it joshin? But would that work with slugos4?
Oct 25 16:01:09 <blaster8> VoodooZ: possibly
Oct 25 16:01:12 <VoodooZ> I had glibc2.5 build properly under HEAD but I'm not sure if I can just install it?
Oct 25 16:01:18 <blaster8> well, you can try
Oct 25 16:01:26 <[g2]> dwery dunno if that's in there
Oct 25 16:01:40 <[g2]> dwery I'd guess not
Oct 25 16:01:42 <VoodooZ> yeah, I wish I had a second slug for testing as I can't flash my robot's board.
Oct 25 16:01:53 <dwery> [g2]: so we have a misterious firmware :)
Oct 25 16:02:01 <VoodooZ> I heard the slug stuff would need to be updated to use the EABI stuff.
Oct 25 16:02:14 <[g2]> dwery there's NPE-A support
Oct 25 16:02:24 <dwery> [g2]: What's NPE-A used for?
Oct 25 16:02:40 <[g2]> Utopia and other stuff
Oct 25 16:02:44 <[g2]> TDM
Oct 25 16:03:10 <[g2]> WAN interfaces etc...
Oct 25 16:03:22 <blaster8> can be used for Ethernet on IXP465 but not on 425
Oct 25 16:03:38 <dwery> [g2]: interesting.
Oct 25 16:03:48 <dwery> ok, what can we really do with it?. i.e. something useful ;)
Oct 25 16:04:02 <blaster8> DMA engine
Oct 25 16:04:14 <blaster8> that's quite useful
Oct 25 16:04:20 <dwery> nice
Oct 25 16:04:26 <blaster8> NPE-A ADSL drivers are under a stupid licence
Oct 25 16:04:26 <dwery> what's Utopia? I can't remember
Oct 25 16:04:34 <blaster8> non-redistributable, or something
Oct 25 16:04:34 <[g2]> dwery there are lots of applications
Oct 25 16:04:57 <blaster8> [g2]: but they all require the IXP-OSAL
Oct 25 16:04:57 <[g2]> utopia is like the ATM MII interface
Oct 25 16:05:25 <[g2]> but it's really a synchronuous interface
Oct 25 16:05:35 <[g2]> and often used for other stuff
Oct 25 16:05:54 <dwery> ok
Oct 25 16:06:10 <[g2]> it comes in various widths and clock speeds
Oct 25 16:06:16 <[g2]> like SCSI
Oct 25 16:06:32 <blaster8> but has no linux support :(
Oct 25 16:08:15 <[g2]> blaster8 it would need a driver anyway
Oct 25 16:08:28 <blaster8> that's basically what I mean
Oct 25 16:09:21 <[g2]> I'd guess crypto is 5x as hard to do
Oct 25 16:09:43 <[g2]> so I'd put it at a .5 of the current driver non-crypto
Oct 25 16:10:14 <[g2]> besides with the current drivers working, it'd be non-essential and development would be way quicker
Oct 25 16:10:33 <[g2]> but the applications are probably pretty small
Oct 25 16:14:47 <[g2]> bbl off to lunch
Oct 25 16:15:02 <blaster8> ok
Oct 25 16:23:08 <dwery> net speed test http://rafb.net/paste/results/PjMGE349.html
Oct 25 16:23:17 <dwery> bbl
Oct 25 16:23:38 <blaster8> same here
Oct 25 16:23:44 <blaster8> bb next week
Oct 25 16:24:02 <blaster8> looking forward to seeing the upstream-ready loft patches in 2.6.19 :)
Oct 25 17:27:11 <[g2]> dwery I got the CF patch but never the mtd patch :(
Oct 25 17:28:05 <dwery> [g2]: http://trac.nslu2-linux.org/kernel/browser/trunk/patches/2.6.19/33-ixp4xx-net-driver-mtd-load-fw.patch?rev=520&format=txt
Oct 25 17:30:12 <[g2]> I'll send him that URL
Oct 25 17:30:26 <[g2]> as the wget returns html
Oct 25 17:30:53 <dwery> i already sent the patches to jhon
Oct 25 17:30:55 <dwery> john
Oct 25 17:31:20 <dwery> did you placed the url around quotes, right?
Oct 25 17:32:00 <[g2]> on on the wget ?
Oct 25 17:32:36 <[g2]> doesn't make a different
Oct 25 17:32:43 <[g2]> s/different/difference/
Oct 25 17:32:43 <jbot> [g2] meant: doesn't make a difference
Oct 25 18:03:22 <dwery> [g2]:  wget 'http://trac.nslu2-linux.org/kernel/browser/trunk/patches/2.6.19/33-ixp4xx-net-driver-mtd-load-fw.patch?rev=520&format=txt' 
Oct 25 18:03:23 <dwery> returns a text file to me
Oct 25 18:04:12 <[g2]> ah I used "
Oct 25 18:05:01 <dwery> should be the same..
Oct 25 18:08:55 <[g2]> hmm... oddly it's different and a text file
Oct 25 18:09:10 <[g2]> but good to know :)
Oct 25 18:17:06 <[g2]> bbl
Oct 25 19:48:01 <likewise> good evening
Oct 25 20:03:42 <NAiL> and good night ;)
Oct 25 20:04:01 <likewise> :-)
Oct 25 20:04:14 <likewise> you're off?
Oct 25 20:04:43 <NAiL> yeah
Oct 25 20:04:53 <NAiL> Dead tired and have to get up early tomorrow
Oct 25 20:05:10 <likewise> Sleep well then!
Oct 25 20:05:17 <NAiL> thanks
Oct 25 21:17:33 <dwery> [g2]: good news
Oct 25 21:17:41 <dwery> 29408+0 records in
Oct 25 21:17:42 <dwery> 29408+0 records out
Oct 25 21:17:42 <dwery> 15056896 bytes transferred in 14.148661 seconds (1064192 bytes/sec)
Oct 25 21:17:52 <dwery> this is reading from CF with interrupts enabled
Oct 25 21:18:08 <blaster8> well done
Oct 25 21:18:13 <[g2]> dwery great
Oct 25 21:18:19 <blaster8> does that mean you can knock the libata patch on the head?
Oct 25 21:18:41 <dwery> and this is writing:
Oct 25 21:18:41 <dwery> 11841+0 records in
Oct 25 21:18:41 <dwery> 11840+0 records out
Oct 25 21:18:41 <dwery> 6062080 bytes transferred in 11.571310 seconds (523889 bytes/sec)
Oct 25 21:18:54 <blaster8> twice as fast as before?
Oct 25 21:18:57 <dwery> blaster8: need a few more tests but should be in svn within 30 mins
Oct 25 21:19:06 <blaster8> great wrok
Oct 25 21:19:10 <blaster8> s/wrok/work
Oct 25 21:19:35 <blaster8> leave the loft specific patches local for now - I'd really like to see this in SVN asap
Oct 25 21:20:10 <dwery> well.. without loft patches isn't so useful but ok :)
Oct 25 21:22:33 <dwery> read/write ops to the cf are quite a load for the cpu
Oct 25 21:22:41 <blaster8> well, it is PIO, right?
Oct 25 21:24:14 <dwery> yes
Oct 25 21:24:15 <dwery> :(
Oct 25 21:24:31 <blaster8> and no way of getting DMA access to that region?
Oct 25 21:25:00 <blaster8> actually CF DMA isn't great at the best of times, mind
Oct 25 21:26:54 <blaster8> silliness
Oct 25 21:27:08 <blaster8> kernel initramfs generation is at the beginning of the compile, not the end
Oct 25 21:27:18 <blaster8> so you can't package modules you've just built
Oct 25 21:27:20 <blaster8> d'oh
Oct 25 21:29:34 <dwery> dunno if DMA is doable. 
Oct 25 21:29:49 <blaster8> [g2] says no
Oct 25 21:30:05 <blaster8> it would be a major faf, and probably wouldn't be that much better performance wise
Oct 25 21:30:16 <blaster8> if you were running a hard drive, it would be different
Oct 25 21:30:26 <dwery> but it might help the cpu
Oct 25 21:30:37 <blaster8> it would
Oct 25 21:30:49 <dwery> but given the way the CF is wired
Oct 25 21:30:58 <blaster8> that is the problem AFAIK
Oct 25 21:31:01 <dwery> it would probably require writing NPE microcode
Oct 25 21:31:10 <blaster8> DMA Engine?
Oct 25 21:31:24 <[g2]> faf ?
Oct 25 21:31:24 <dwery> the DMA engine should have the capability to toggle an I/O line
Oct 25 21:31:35 <dwery> to handle this wiring.
Oct 25 21:31:48 <dwery> anyway, we'll check later
Oct 25 21:32:12 <blaster8> faf - wasting time doing not very useful things
Oct 25 21:32:13 <[g2]> I think the NPEs can see the EXP bus
Oct 25 21:32:25 <[g2]> so in theory the code could be moved to the NPEs
Oct 25 21:33:01 <[g2]> I'll have to look at the NPE again, but maybe NPE-A could baby-sit the EXP bus for the IDE driver
Oct 25 21:33:13 <[g2]> but this is really pie-in-the-sky stuff
Oct 25 21:33:23 <blaster8> lets get it working first
Oct 25 21:34:00 <blaster8> dwery: do you know about kernel initialisation
Oct 25 21:34:06 <blaster8> i.e. what starts whenn
Oct 25 21:34:27 <dwery> eheh.. I think only Linus knows that... it's very difficult to determine the order
Oct 25 21:34:37 <dwery> it depends on initcalls and compilation
Oct 25 21:35:01 <dwery> [g2]: then we need the NPEs istruction set :)
Oct 25 21:35:17 <[g2]> dwery yeah :)
Oct 25 21:35:33 <blaster8> dwery: does initramfs load before drivers?
Oct 25 21:35:43 <CIA-8> 03rwhitby * r522 10kernel/trunk/patches/2.6.19/33-ixp4xx-net-driver-mtd-load-fw.patch: mtd-load: put it back in, but not in the series file. this is the way to handle patches still under discussion.
Oct 25 21:35:48 <dwery> [g2] come on.. hand me that "for your eyes only" pdf
Oct 25 21:35:53 <dwery> :)
Oct 25 21:36:09 <dwery> blaster8: initram is supposed to load early
Oct 25 21:36:16 * [g2] doesn't have that pdf
Oct 25 21:36:18 <dwery> but I don't know the exact sequence
Oct 25 21:36:25 <[g2]> rwhitby thx
Oct 25 21:36:26 <rwhitby> BTW, loft-specific patches go in our SVN too.
Oct 25 21:36:36 <rwhitby> we're trying to keep Loft in the fold, not push it out :-)
Oct 25 21:36:55 <[g2]> rwhitby I _totally_ know
Oct 25 21:37:17 <dwery> blaster8: Documentation/initrd.txt has am high level description of the sequence
Oct 25 21:37:24 <blaster8> thanks
Oct 25 21:37:24 <rwhitby> guys, I need to take some time to re-read the backlogs
Oct 25 21:37:35 <dwery> rwhitby: I'm about to push the compact flash driver
Oct 25 21:37:43 <rwhitby> I think we should go in parallel down two paths:  everything in kernel, and everything in early userspace
Oct 25 21:37:59 <rwhitby> and then see how much we can get upstream once we have working code for both
Oct 25 21:38:13 <dwery> rwhitby: should I leave out Loft specific bits from series?
Oct 25 21:38:16 <[g2]> rwhitby I thought that's exactly what we were doing :)
Oct 25 21:39:32 <rwhitby> dwery: good question
Oct 25 21:39:51 <dwery> rwhitby: loft bits also requires 65-loft-config.patch which is not in the repo
Oct 25 21:40:17 <rwhitby> should be added then
Oct 25 21:40:43 <blaster8> rwhitby: loft patches need to be cleaned up first
Oct 25 21:41:32 <blaster8> avila and loft need to be separated out from ixdp425 now we have the ixp4xx CF driver
Oct 25 21:42:04 <rwhitby> guys, can we discuss this in about 2 hours time?
Oct 25 21:42:15 <blaster8> http://lxr.linux.no/source/arch/arm/mach-ixp4xx/ixdp425-setup.c?a=arm
Oct 25 21:42:19 <[g2]> sure that's fine with me
Oct 25 21:42:31 <rwhitby> (middle of morning kids routine here)
Oct 25 21:43:20 * [g2] suggests the Loft patches and experiments be in the repo but not in the series file for a short time
Oct 25 21:43:36 <blaster8> look, I'll clean up the loft patches
Oct 25 21:43:42 <dwery> blaster8: thanks.
Oct 25 21:43:54 <blaster8> bloody hell, it's not even my device :p
Oct 25 21:45:19 <dwery> nor is the avila :)
Oct 25 21:45:49 <blaster8> indeed
Oct 25 21:45:53 <dwery> we need to find an avila for tests...
Oct 25 21:46:05 <blaster8> ask avila?
Oct 25 21:46:31 <dwery> I don't even know how an avila looks like :)
Oct 25 21:46:43 <CIA-8> 03azummo * r523 10kernel/trunk/patches/2.6.19/ (96-pata-ixp4xx.patch series): IXP4XX generic Compact Flash PATA/libata driver
Oct 25 21:47:08 <rwhitby> [g2]: good plan for the moment
Oct 25 21:47:16 <rwhitby> back when I get to work
Oct 25 21:47:21 <blaster8> done
Oct 25 21:50:23 <rwhitby> [g2]: put them in series, commented out.
Oct 25 21:50:39 <rwhitby> (with a comment above saying why they are commented out, and what each depends on)
Oct 25 21:50:41 <[g2]> rwhitby sure that's fine too
Oct 25 21:50:58 <rwhitby> so someone can easily uncomment them to test them
Oct 25 21:51:33 <CIA-8> 03bzhou * r4282 10optware/trunk/make/gambit-c.mk: gambit-c: upstream upgrade to 4.0b20
Oct 25 23:36:22 <CIA-8> 03blaster8 * r524 10kernel/trunk/patches/2.6.19/ (3 files): Prelimary Avila/Loft support, Non-functional
Oct 25 23:44:40 <CIA-8> 03blaster8 * r525 10kernel/trunk/patches/2.6.19/08-avila-loft-setup.patch: Fix obvious issue, still broken
Oct 26 00:25:15 <CIA-8> 03blaster8 * r526 10kernel/trunk/patches/2.6.19/ (7 files): Add non-broken Loft support, refresh other patches, update defconfig
**** ENDING LOGGING AT Thu Oct 26 02:59:57 2006