| 00:02.38 | *** join/#nslu2-linux rwhitby (n=rwhitby@nslu2-linux/rwhitby) |
| 00:11.35 | *** join/#nslu2-linux kfm82ibookg4 (n=kfm82@stanmade.dialup.fu-berlin.de) |
| 01:07.57 | dwery | Arrrrrrrrrrrrr! |
| 01:08.10 | dwery | http://rafb.net/paste/results/58sj4e91.html |
| 01:08.39 | dwery | nfsroot + open source ixp4xx eth driver + microcode downloading from redboot |
| 01:08.50 | dwery | now it's really late here.. I'll call it a day! |
| 01:16.45 | rwhitby | sweet |
| 01:32.11 | *** join/#nslu2-linux ByronT (n=byron-po@nslu2-linux/ByronT) |
| 03:29.17 | *** join/#nslu2-linux VoodooZ (i=palm3@modemcable214.50-82-70.mc.videotron.ca) |
| 03:30.08 | VoodooZ | test |
| 03:32.03 | dumfrac | VoodooZ: ack |
| 03:35.29 | VoodooZ | thanks |
| 03:35.54 | VoodooZ | I'm trying BitchX for the first time as it's easier than changing my firewall (NAT) |
| 03:36.10 | dumfrac | what is BitchX ? |
| 03:36.21 | VoodooZ | a text mode IRC client |
| 03:38.54 | dumfrac | what does it give you that other IRC clients don't provide ? |
| 03:40.35 | VoodooZ | well, for one I can run it remotely (from work) without having to resort to black magic to go around corporate firewalls. |
| 03:41.05 | VoodooZ | although I'm currently doing it using tinyproxy via an openssh tunnel to hide my "personal" surfing. |
| 03:41.39 | VoodooZ | It's the first time I try it so I'm just testing,,, |
| 03:41.42 | dumfrac | sneaky :-) |
| 03:41.46 | dumfrac | cool |
| 03:41.53 | dumfrac | seems to be working ! |
| 03:42.02 | VoodooZ | hehehe you have to be with corporation logging everything you do. |
| 03:42.28 | VoodooZ | I don't do anything illegal. I just monitor the channel from work. |
| 03:43.39 | 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 |
| 03:44.01 | VoodooZ | yeah, that's nice. |
| 03:44.34 | VoodooZ | sometime they just block stuff for obvious reasons (IRC is used for virus and other nasty stuff). |
| 03:44.43 | VoodooZ | Iguess I don't blame them. |
| 03:44.59 | VoodooZ | Especially now that I work in security/AV! |
| 03:45.22 | dumfrac | :-) |
| 03:45.49 | dumfrac | Have fun - I've got to get some sleep now |
| 03:57.56 | *** join/#nslu2-linux DrZimmerman (n=theo@84-72-181-62.dclient.hispeed.ch) |
| 03:59.23 | *** join/#nslu2-linux rwhitby-away (n=rwhitby@nslu2-linux/rwhitby) |
| 04:08.18 | *** join/#nslu2-linux gZV (n=Sinclair@p54A085FB.dip0.t-ipconnect.de) |
| 04:18.38 | *** join/#nslu2-linux jacques (n=jacques@nslu2-linux/jacques) |
| 04:27.07 | *** part/#nslu2-linux VoodooZ (i=palm3@modemcable214.50-82-70.mc.videotron.ca) |
| 04:48.10 | *** join/#nslu2-linux mithro (n=tim@lester.mithis.com) |
| 04:52.25 | *** join/#nslu2-linux tuv (n=tuv@unaffiliated/tuv) |
| 05:32.08 | *** join/#nslu2-linux rwhitby (n=rwhitby@nslu2-linux/rwhitby) |
| 05:32.17 | osas | speaking of irc, just got the dircproxy running on openslug |
| 05:32.52 | *** join/#nslu2-linux eno__ (n=eno@adsl-70-137-142-149.dsl.snfc21.sbcglobal.net) |
| 05:34.56 | osas | rwithby: NAiL pushed the sipsak package for me |
| 05:43.34 | NAiL | rwhitby: ping? Could you make a cert for osas? |
| 05:43.48 | rwhitby | NAiL: cert, or OE key? |
| 05:44.11 | rwhitby | osas: hi |
| 05:44.15 | osas | hi |
| 05:44.23 | NAiL | he's working on the stable tree, so a cert first. |
| 05:44.46 | rwhitby | NAiL: I thought you were the only one who would touch the stable tree |
| 05:44.55 | rwhitby | others check into monotone head first, and you transfer |
| 05:45.24 | rwhitby | (we only want one person with write access to the stable openslug tree) |
| 05:45.47 | NAiL | ok, then OE access, and I'll watch closely :) |
| 05:46.44 | osas | usually I test packages on the stable tree ... |
| 05:46.47 | 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 |
| 05:47.20 | NAiL | which is the "sane" way to handle it |
| 05:47.27 | osas | I don't know how stable is the head, that's why I prefer to compile them against the stable one |
| 05:48.05 | osas | som dunno what the rules are here ... |
| 05:48.17 | osas | s/som/so/ |
| 05:50.26 | NAiL | rwhitby is right though... you should commit to head first. Makes it easier to keep "stable" stable |
| 05:51.11 | osas | I agree with that. |
| 05:51.44 | osas | my next question is: is it safe to test a package against the stable tree and then make it available on the head? |
| 05:51.51 | NAiL | mostly |
| 05:52.00 | osas | ok then :) |
| 05:52.20 | NAiL | there's always some changes, and some changes might break a package |
| 05:52.54 | 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. |
| 05:53.06 | osas | yup |
| 05:53.26 | osas | in this case, I already have a new package: dircproxy |
| 05:53.50 | osas | I'm connecting through it :) |
| 05:53.59 | NAiL | ah |
| 05:54.28 | osas | http://dircproxy.securiweb.net/ |
| 05:54.54 | osas | 1.1.0 works out of the box |
| 05:55.39 | NAiL | cool |
| 05:55.53 | NAiL | just mail me a .bb, and I'll take a look |
| 05:56.02 | osas | ok |
| 06:00.38 | osas | e-mail sent |
| 06:02.45 | NAiL | thanks, I'll look at it after work |
| 06:03.52 | osas | k |
| 06:04.35 | *** join/#nslu2-linux mithro (n=tim@lester.mithis.com) |
| 06:28.37 | NAiL | btw, regarding PR |
| 06:28.55 | NAiL | when you change to a new release, the PR should be reset, not increased. |
| 06:29.05 | osas | oh ... |
| 06:29.31 | osas | I was checking the 12.1 against the previous one ... |
| 06:29.32 | NAiL | It's to keep track of revisions of the same-version package :) |
| 06:29.57 | osas | then 12.1 is not following the rule |
| 06:29.57 | NAiL | (ie, same tarball, just changes to the .bb) |
| 06:30.19 | NAiL | that happens. Especially if someone copies a .bb and forgets to reset PR |
| 06:30.29 | osas | I will keep in mind that |
| 06:30.40 | osas | now it's bed time for me :) |
| 06:31.25 | osas | thx for your help |
| 06:31.30 | osas | l8r |
| 06:38.41 | *** join/#nslu2-linux eiffel (n=eiffel@pD9572F11.dip0.t-ipconnect.de) |
| 06:49.43 | *** join/#nslu2-linux bullet (n=bullet@206-69.1-85.cust.bluewin.ch) |
| 06:52.36 | NAiL | nite |
| 07:13.09 | *** join/#nslu2-linux CieD (n=CieD@host86-136-77-105.range86-136.btcentralplus.com) |
| 07:41.23 | *** join/#nslu2-linux EvilDevil (n=miau@p54A6EE30.dip.t-dialin.net) |
| 07:56.32 | *** join/#nslu2-linux EvilDevil_ (n=miau@p54A6E75F.dip.t-dialin.net) |
| 08:08.53 | *** join/#nslu2-linux mithro (n=tim@ppp246-117.static.internode.on.net) |
| 08:25.23 | *** join/#nslu2-linux kolla (i=kolla@firda.uninett.no) |
| 08:31.17 | *** join/#nslu2-linux EvilDevil_ (n=miau@p54A6DDAF.dip.t-dialin.net) |
| 08:52.04 | CIA-8 | 03marcusb * r62 10debian/ixp400-accesslib/trunk/ixp400-accesslib/debian/patches/: Pointed svn:externals to new location archived/intel_eth. |
| 09:14.15 | CIA-8 | 03marcusb * r63 10debian/ixp400-accesslib/trunk/ixp400-accesslib/ixp_osal/os/linux/include/core/IxOsalOsTypes.h: Remove bogus setting of __ixp46X macro. |
| 09:14.45 | *** join/#nslu2-linux caplink811_log (n=caplink8@dslb-088-073-134-184.pools.arcor-ip.net) |
| 09:24.09 | CIA-8 | 03marcusb * r64 10debian/ixp400-accesslib/trunk/ixp400-accesslib/debian/README.Debian: Document use of -ixp4xx kernel flavour instead of obsolete -nslu2. |
| 09:25.51 | [g2] | dumfrac pong |
| 09:28.57 | CIA-8 | 03marcusb * r65 10debian/ixp400-eth/trunk/ixp400-eth/debian/patches/: Pointed svn:externals at new location in archived/intel_eth. |
| 09:45.36 | *** join/#nslu2-linux vmaster_ (n=vmaster@p549B7F5D.dip.t-dialin.net) |
| 10:18.03 | *** join/#nslu2-linux rwhitby (n=rwhitby@nslu2-linux/rwhitby) |
| 10:36.06 | *** join/#nslu2-linux matholio (n=matholio@203-217-80-60.dyn.iinet.net.au) |
| 10:36.13 | matholio | evening all |
| 10:42.27 | rwhitby | hi matholio |
| 10:52.33 | dwery | [g2]: the signatures are quite strange: |
| 10:52.35 | dwery | npe: unknown/NPE-A func: 3 rev: bc.f8 size: 1074721228 bytes id:5003bcf8 |
| 10:52.35 | dwery | npe: IXP465/NPE-A func: 81 rev: 2.0 size: 12848 bytes id:10810200 |
| 10:52.35 | dwery | npe: firmware loaded to NPE-A, func: 81, rev: 2.0, status: 82400000 |
| 10:52.35 | dwery | npe: IXP425/NPE-B func: 1 rev: 2.0 size: 12848 bytes id:01010200 |
| 10:52.35 | dwery | npe: firmware loaded to NPE-B, func: 1, rev: 2.0, status: 80800000 |
| 10:52.36 | dwery | npe: IXP425/NPE-C func: 1 rev: 2.0 size: 12848 bytes id:02010200 |
| 10:52.38 | dwery | npe: firmware loaded to NPE-C, func: 1, rev: 2.0, status: 80800000 |
| 10:52.40 | dwery | npe: unknown/NPE-O func: ed rev: f0.d size: 16 bytes id:feedf00d |
| 10:53.03 | dwery | it seems there's something like and end marked where magic == byteswap(id) |
| 10:54.28 | dwery | or baybe magic == id.. |
| 10:54.49 | rwhitby | dwery: hi |
| 10:55.19 | dwery | hi! |
| 10:55.48 | rwhitby | dwery: the read of microcode from redboot yesterday - how was that done? |
| 10:55.57 | dwery | mtd notifier callback |
| 10:56.00 | dwery | i'm refining the code |
| 10:59.12 | rwhitby | can it be generalised to any mtd partition (or even part of the final block) as a board code parameter? |
| 10:59.33 | dwery | yes |
| 10:59.36 | dwery | already done |
| 10:59.38 | rwhitby | sweet |
| 11:00.07 | rwhitby | so you're doing a patch for the nslu2 to read it from the last block? |
| 11:01.38 | CIA-8 | 03rwhitby * r75 10slugimage/trunk/slugimage: slugimage: Added the microcode flag back, and set the FIS directory table partition size correctly. |
| 11:02.43 | 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 |
| 11:03.56 | rwhitby | does it search anywhere in the partition for the magic numbers? |
| 11:04.00 | dwery | [g2] suggested to automatically load only firmwares for NPE B and C |
| 11:04.01 | dwery | yes |
| 11:04.19 | dwery | I need to understand if |
| 11:04.20 | dwery | npe: firmware at 11e88, unknown/NPE-A func: 3, rev: bc.f8, size: 1074721228, id:5003bcf8 |
| 11:04.24 | dwery | happened by chance |
| 11:04.27 | dwery | or is something else |
| 11:07.17 | rwhitby | dwery: you did the rtc driver, right? |
| 11:07.22 | dwery | yes |
| 11:08.21 | rwhitby | Just sent you an email regarding the RTC driver and Debian Etch. |
| 11:08.54 | NAiL | rwhitby: btw, do you know why bash isn't built in the fsg3 feed? |
| 11:09.11 | NAiL | I'm having some problems building the kernel |
| 11:09.12 | dwery | reading... |
| 11:09.18 | rwhitby | NAiL: dunno, it was marked as broken |
| 11:09.26 | NAiL | ok |
| 11:09.33 | rwhitby | NAiL: I've built kernel modules right now - will commit it. |
| 11:09.43 | dwery | rwhitby: haven't got the email yet |
| 11:09.52 | NAiL | ah, I'm not actually building a kernel for the fsg3 on the fsg3 ;-) |
| 11:09.59 | NAiL | I'm building a kernel for the n2100 :) |
| 11:10.18 | NAiL | but I haven't experienced any problems with the toolchain as of yet |
| 11:10.57 | 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. |
| 11:11.32 | NAiL | great work :) |
| 11:11.47 | rwhitby | Completely untested |
| 11:12.26 | NAiL | I'll see if I can get around to testing that later today |
| 11:12.36 | dwery | rwhitby: my udec works usually |
| 11:12.38 | dwery | udev |
| 11:12.49 | NAiL | Slowly getting my free time back :) |
| 11:13.15 | dwery | rwhitby: KERNEL=="rtc0", SYMLINK += "rtc" |
| 11:14.17 | dwery | i'm answering |
| 11:15.53 | rwhitby | modules should be independent of the softfloat/hardfloat thing that jacques identified yesterday |
| 11:15.57 | rwhitby | bbiab |
| 11:24.57 | dwery | rwhitby: did you run mc_grab on the nslu2? found any image? which version? |
| 11:25.45 | dwery | i need someone to run mc_grab on a BE machine |
| 11:29.43 | dwery | NAiL: BE/LE on any machine you might have ;) |
| 11:30.46 | dwery | anybody know the maximum image size that can be loaded in an NPE? |
| 11:31.10 | NAiL | I've got an fsg-3 running BE |
| 11:31.12 | NAiL | and a slug |
| 11:31.23 | NAiL | n2100 + another slug runs LE |
| 11:32.20 | NAiL | n2100 doesn't have the firmware though :-P |
| 11:33.01 | NAiL | could you make mc_grab available somewhere? Dunno if I get the time to compile anything today :-P |
| 11:34.17 | dwery | let me think |
| 11:34.38 | dwery | no, I don't have a compiled form here :( |
| 11:34.54 | dwery | it's in Documentation/networking/ixp4xx |
| 11:46.34 | CIA-8 | 03blaster8 * r517 10kernel/trunk/patches/2.6.18/ (45-eeprom-new-notifier.patch 66-hwmon-ad7418.patch): Refresh latest Loft patches |
| 11:51.24 | CIA-8 | 03blaster8 * r518 10kernel/trunk/patches/2.6.18/33-ixp4xx-net-driver-improve-mac-handling.patch: Refresh MAC Handling patch |
| 12:05.23 | dumfrac | [g2] ping |
| 12:17.20 | CIA-8 | 03blaster8 * r519 10kernel/trunk/patches/2.6.19/ (2 files): Move new 2.6.18 patches to 2.6.19 tree |
| 12:18.08 | [g2] | dumfrac pong |
| 12:18.21 | dumfrac | hi [g2] |
| 12:18.40 | [g2] | hey dumfrac :) |
| 12:18.42 | dumfrac | finally we connect :-) |
| 12:18.46 | [g2] | yeah :) |
| 12:19.00 | [g2] | feel free to e-mail anytime |
| 12:19.07 | [g2] | but I'm often here |
| 12:19.29 | 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 ? |
| 12:19.37 | dumfrac | s/dd/did |
| 12:20.06 | dumfrac | I didn't get a chacnce last night as I was fighting with Debian RTC stuff |
| 12:21.24 | [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 ? |
| 12:22.04 | dumfrac | yeah - it seemed to me that the offset check is what you were looking for in the comments you put in the code |
| 12:22.45 | [g2] | well the reason I didn't put it in case because the offset is a flashbase relative address |
| 12:23.02 | [g2] | one still needs to pickup the base flash address and that's the issue |
| 12:23.26 | [g2] | we're missing the 0x50000000 part |
| 12:24.35 | [g2] | I'm guessing that the specific memory address is hidden on purpose |
| 12:25.46 | 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 |
| 12:25.48 | [g2] | I'm guessing that's part of the reason there are methods on the object for erase, OTP, etc.. |
| 12:26.11 | dumfrac | makes sense |
| 12:26.32 | [g2] | so I'm fine with posting to MTD and cc'ing ecos-devel |
| 12:27.25 | [g2] | rwhitby mentioned giving it a little time (I think for review from bewoolie/jacmet) |
| 12:27.31 | 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) |
| 12:28.01 | [g2] | me too. And THX for all the testing. It really makes things easier |
| 12:28.12 | [g2] | "We enough eyes all problems are shallow" |
| 12:28.20 | [g2] | s/We/With/ |
| 12:29.00 | dumfrac | it's a pleasure - I'm having fun, and contributing to the Slug effort so I'm happy |
| 12:29.27 | [g2] | that's _exactly_ the way it's supposed to be :) |
| 12:29.37 | dumfrac | :-) |
| 12:30.18 | dumfrac | I'm now starting another d-i daily build test... |
| 12:31.04 | [g2] | dumfrac are you tracking dwery's latest changes ? |
| 12:32.07 | dumfrac | I'm not fully up to date on what he has been doing - can you fill me in |
| 12:32.34 | dwery | 0x00000000-0x00080000 : "RedBoot" |
| 12:32.34 | dwery | npe: searching for firmware... |
| 12:32.35 | dwery | npe: found at 0x11e7c, unknown/NPE-A func: 03, rev: c.8, size: 1074721228, id: 5003bcf8 |
| 12:32.35 | dwery | npe: found at 0x3f42c, IXP465/NPE-A func: 81, rev: 2.0, size: 12848, id: 10810200 |
| 12:32.35 | dwery | npe: found at 0x4265c, IXP425/NPE-B func: 01, rev: 2.0, size: 12848, id: 01010200 |
| 12:32.35 | dwery | npe: firmware loaded to NPE-B, func: 01, rev: 2.0, status: 82400000 |
| 12:32.37 | dwery | npe: found at 0x4588c, IXP425/NPE-C func: 01, rev: 2.0, size: 12848, id: 02010200 |
| 12:32.39 | dwery | npe: firmware loaded to NPE-C, func: 01, rev: 2.0, status: 80800000 |
| 12:33.14 | dumfrac | hi dwery |
| 12:33.28 | [g2] | dwery is automatically pulling the NPE microcode from Redboot from within the driver |
| 12:33.30 | dwery | hi! |
| 12:33.36 | dumfrac | so this is implemented in the redboot parsing ? |
| 12:34.57 | [g2] | dunno when it code is < 14 hours old I haven't looked at it yet |
| 12:35.08 | [g2] | s/when/where/ |
| 12:35.18 | dwery | mtd notifier |
| 12:36.24 | [g2] | dwery "The notifier master!" |
| 12:36.30 | dwery | :) |
| 12:36.54 | [g2] | jbowler has now been exceeded as notifier master |
| 12:37.19 | [g2] | the notifier master is dead, long live the notifier master :) |
| 12:37.33 | 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 ? |
| 12:38.12 | [g2] | dumfrac I'm wondering what's in the refresh. |
| 12:38.40 | dumfrac | [g2] the refresh ? |
| 12:39.15 | [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 |
| 12:40.35 | [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 ? |
| 12:40.59 | [g2] | We'll really need to think about what upstream will accept |
| 12:41.50 | dumfrac | that would be great for Debian - I think that is exactly what Debian is looking to ultimately do |
| 12:41.55 | dwery | [g2]: yes, it can be done |
| 12:42.46 | [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 |
| 12:43.13 | [g2] | I think early userspace may be the compromize |
| 12:44.07 | [g2] | s/mize/mise/ |
| 12:44.07 | 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 |
| 12:45.45 | dwery | gtg.. patch later today |
| 12:45.54 | [g2] | dwery THX cheers |
| 12:46.19 | dumfrac | [g2] and dwery: what is gtg ? |
| 12:46.30 | [g2] | got to go |
| 12:47.24 | dumfrac | see you later |
| 12:47.58 | dumfrac | ah right - I figured it out after I had sent the message :-) |
| 13:32.24 | *** join/#nslu2-linux kfm82ibook (n=kfm82@p54BEF3E8.dip.t-dialin.net) |
| 13:39.08 | *** join/#nslu2-linux bullet (n=bullet@206-69.1-85.cust.bluewin.ch) |
| 13:47.56 | *** join/#nslu2-linux blaster8 (n=blaster8@jeharrap.joh.cam.ac.uk) |
| 13:48.11 | [g2] | blaster8 welcome |
| 13:48.22 | blaster8 | hey there |
| 13:48.43 | [g2] | blaster8 I just tested the extra code for the 33-ixp4xx-mac patch |
| 13:48.51 | [g2] | it seems to work |
| 13:48.53 | blaster8 | ok? |
| 13:49.10 | blaster8 | the extra code in SVN or the extra code from Christian's email? |
| 13:50.04 | [g2] | lost you there :( |
| 13:50.32 | blaster8 | which extra code do you mean :) ? |
| 13:50.53 | [g2] | Ok here's my take where we are at |
| 13:51.27 | [g2] | a) I updated svn yesterday to delay copying the platform mac until ixmac_open |
| 13:51.34 | blaster8 | yes |
| 13:51.53 | [g2] | 2) you/christian updated it was bogus as it nails the mac as the platform mac |
| 13:52.19 | blaster8 | well, SVN hasn't changed |
| 13:52.30 | blaster8 | I've just refreshed/forward ported the patches |
| 13:52.51 | blaster8 | I sent the patch to Christian's code off to him so he could check it and incorporate it into his code base |
| 13:53.15 | blaster8 | but he raised the problem with MAC address setting which I forwarded to you |
| 13:53.35 | [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 |
| 13:54.08 | [g2] | I had sent out and e-mail earlier and just finished testing |
| 13:54.32 | [g2] | I didn't know if the default dev->hwaddr would be zero but it appears so |
| 13:55.11 | [g2] | so now I can ifdown/ change mac/ ifup and it works |
| 13:55.19 | [g2] | as it should :) |
| 13:55.22 | blaster8 | http://pastebin.ca/221039 |
| 13:55.27 | blaster8 | did you check this over |
| 13:55.52 | blaster8 | including the bit about the net driver not being supposed to change the MAC at interface up/down |
| 13:59.20 | [g2] | just read it |
| 14:00.26 | [g2] | ack on the upstream not accepting the change |
| 14:01.09 | blaster8 | he suggests an interesting alternative |
| 14:01.25 | blaster8 | eeprom notifier specifically handling the MAC address setting |
| 14:01.51 | [g2] | right. |
| 14:01.51 | blaster8 | this is a good thing (tm) in one way at least |
| 14:01.56 | blaster8 | to explain: |
| 14:02.24 | blaster8 | if userspace is going to have to set the MAC address (say...) |
| 14:02.42 | blaster8 | then how does it know, reliably, which interface to set it on |
| 14:02.48 | blaster8 | and how can it find out? |
| 14:03.23 | [g2] | well the old answer was easy. It's a machine specific issue |
| 14:03.28 | blaster8 | at least if the MAC address setting code is within kernelspace |
| 14:03.43 | blaster8 | then it can reliably find out which driver controls which interface |
| 14:04.12 | [g2] | it's a Loft/Avila/IXDP425 they all have there MAC at that place in EEPROM |
| 14:04.54 | [g2] | it's an machine specifc issue, just like the number of PCI enumerations |
| 14:05.02 | blaster8 | so we have to argue that we need a specialist MAC extractor piece of code |
| 14:05.15 | [g2] | nope |
| 14:05.19 | blaster8 | ? ok |
| 14:05.38 | [g2] | the kernel guys have basically said they don't want to maintain all that garbabe |
| 14:05.49 | [g2] | s/garbabe/garbage/ |
| 14:06.08 | [g2] | so they want to push that out to early userspace |
| 14:06.28 | blaster8 | well, I can see their point, to some extent |
| 14:06.37 | dwery | back |
| 14:06.39 | blaster8 | I mean, we need userspace to bring up the NPE anyway |
| 14:06.47 | dwery | [g2] I'm quite lost behind this mac thingy ;) |
| 14:06.48 | [g2] | well dwery doesn't :) |
| 14:06.55 | *** join/#nslu2-linux ByronT (i=byron-po@nslu2-linux/ByronT) |
| 14:07.23 | [g2] | dwery what do you mean ? |
| 14:07.52 | dwery | I mean the matter is becoming complex day after day |
| 14:08.04 | dwery | so.. I take care of the firmware |
| 14:08.12 | dwery | can you handle the mac thing? |
| 14:08.22 | [g2] | dwery sure |
| 14:08.26 | dwery | thanks! |
| 14:08.39 | [g2] | dwery thanks for showing me the way |
| 14:09.18 | [g2] | blaster8 ok so back the the sorted MAC issue |
| 14:09.20 | dwery | np |
| 14:09.32 | [g2] | s/the the/to the/ |
| 14:09.56 | blaster8 | [g2]: are you using an initramfs on the Loft? |
| 14:10.03 | [g2] | blaster8 nope |
| 14:10.16 | [g2] | blaster8 there are two problems |
| 14:10.26 | blaster8 | fire away |
| 14:11.17 | [g2] | 1) using the EEPROM MAC for compiled in ixp modules (loadable already works fine) |
| 14:11.29 | [g2] | 2) loading the NPE firmware |
| 14:12.58 | [g2] | dwery your patch deals with 2) right and you are still working on that correct ? |
| 14:13.10 | dwery | yes, will be in svn in 10/20 mins |
| 14:13.43 | [g2] | dwery ok are you changing the 33- patch at all ? |
| 14:13.49 | dwery | no |
| 14:13.54 | [g2] | ok super |
| 14:14.36 | [g2] | blaster8 so that leaves us with the following issue |
| 14:15.16 | blaster8 | right |
| 14:15.24 | [g2] | Some platform specific notifier just update the device MACs |
| 14:15.43 | [g2] | which begs the question of which devices get which macs |
| 14:16.15 | [g2] | in the Loft's case there can be 5 or 6 networking devices |
| 14:16.27 | [g2] | eth0/1 + 3 or 4 PCI devices |
| 14:16.43 | dwery | + two usb hubs, each with 7 devices |
| 14:16.50 | dwery | :) |
| 14:17.14 | [g2] | well you can have 120+ devices in theory on USB |
| 14:17.21 | dwery | ehehe..ok, back coding |
| 14:18.29 | [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 |
| 14:18.45 | [g2] | meaning something upstream can tolerate |
| 14:19.02 | blaster8 | well, we really need something upstream can tolerate now |
| 14:19.06 | blaster8 | for preference |
| 14:19.26 | [g2] | blaster8 the current open IXP driver is not in any shape to go upstream |
| 14:19.43 | [g2] | this is specific to that |
| 14:19.44 | blaster8 | ? it's not that bad |
| 14:19.58 | blaster8 | but no, it's not going upstream soon |
| 14:20.51 | [g2] | well there's lots of issues like moving it out of the IXP4xx tree and supporting the other Micro engines etc... |
| 14:22.17 | [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 |
| 14:23.30 | [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 |
| 14:24.13 | [g2] | but the nslu2 has bigger fish to fry like where the NPE microcode coming from and how does it get loaded |
| 14:25.49 | [g2] | blaster8 all clear ? agree / not agree ? |
| 14:28.13 | blaster8 | hold on |
| 14:30.40 | blaster8 | surely the Loft also cares where the NPE microcode comes from? |
| 14:32.33 | blaster8 | the Loft support patch and the Loft EEPROM notifier support patch should be separated |
| 14:32.42 | blaster8 | but the Loft patch needs reworking before it goes upstream too |
| 14:35.00 | dwery | yes.. we need to separate loft from avila/ixdp for clearness |
| 14:35.24 | blaster8 | no |
| 14:35.33 | blaster8 | avila needs to be separated from ixdp |
| 14:35.52 | blaster8 | as far as I can see, loft can probably stay together with avila |
| 14:36.14 | 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) |
| 14:36.36 | blaster8 | I'm not sure I like the look of that either :( |
| 14:36.43 | dwery | blaster8: right, I inverted the names |
| 14:36.53 | blaster8 | ok good |
| 14:36.56 | dwery | [g2]: fw patch in svn |
| 14:37.01 | dwery | never tested in BE |
| 14:37.12 | [g2] | dwery thx |
| 14:37.22 | dwery | I'd appreciate having relevant dmesg lines for every ixp4xx platform |
| 14:38.28 | blaster8 | dwery: I'm uncertain upstream are going to be happy about loading firmware from mtd partitions |
| 14:38.39 | dwery | only firmware with funcition == 1 will be loaded |
| 14:39.24 | dwery | blaster8: nor do I, but I don't want to loos time in creating an initram fs |
| 14:39.32 | blaster8 | hmm |
| 14:39.38 | dwery | I needed it in order for nfsroot to work so I just did it ;) |
| 14:39.49 | *** join/#nslu2-linux yvasilev (n=yvasilev@dune.math.cinvestav.mx) |
| 14:39.56 | [g2] | blaster8 our repo is a staging area for upstream |
| 14:39.56 | blaster8 | rwhitby won't like it, and I'm not a fan either |
| 14:40.24 | blaster8 | the prevailing attitude is: it's going upstream or its out |
| 14:40.43 | dwery | it's just there for convenience, it can be removed even today.. I just wanted to share it for a quick test |
| 14:40.44 | blaster8 | actually, we're already breaking those rules with what's in the 2.6.18 directory |
| 14:41.08 | dwery | the whole ixp4xx net driver breaks the rules :) |
| 14:41.22 | blaster8 | no, the ixp4xx is being prepared for upstream |
| 14:41.35 | dwery | being prepared means it shoudl reworked a lot |
| 14:41.41 | blaster8 | stuff which can't be sent upstream, because they won't accept it shouldn't be in SVN |
| 14:41.43 | dwery | they way it is it will never go in |
| 14:41.46 | [g2] | blaster8 and these changes are all specifically related to the ixp4xx driver |
| 14:41.48 | blaster8 | it's a fine distinction |
| 14:42.21 | blaster8 | I'm just saying we can't be adding features which upstream will tell us to go to hell with |
| 14:42.43 | dwery | i can remove from the repo at anytime, but I needed that feature for moving on something else |
| 14:43.05 | blaster8 | I think it should be in local trees unfortunately, sorry |
| 14:43.12 | dwery | ok, going to remove it. |
| 14:43.19 | dwery | [g2]: did you downloaded it |
| 14:43.23 | dwery | ? |
| 14:43.34 | blaster8 | dwery: when you remove it, it will still be there |
| 14:43.36 | blaster8 | :) |
| 14:43.41 | dwery | :) |
| 14:43.41 | [g2] | dwery not yet, but I'm sure you can e-mail |
| 14:43.46 | 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 |
| 14:43.52 | blaster8 | that link won't stop working |
| 14:43.56 | dwery | great. |
| 14:44.19 | blaster8 | can initramfs be built into the kernel? |
| 14:45.00 | dwery | done. |
| 14:45.01 | 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 |
| 14:45.01 | [g2] | blaster8 talk to rwhitby about what you want to do the nslu2-linux kernel repo about this ixp4xx driver stuff |
| 14:45.19 | blaster8 | think about it in terms of features |
| 14:45.31 | dwery | i'm now moving to pata/cd |
| 14:45.32 | dwery | cf |
| 14:45.44 | blaster8 | we can't put things in SVN which add features which upstream don't want |
| 14:45.58 | blaster8 | so the ixp4xx driver at the moment contains only features which upstream will want |
| 14:46.04 | [g2] | blaster8 you're missing the whole point |
| 14:46.07 | blaster8 | ? |
| 14:46.29 | *** join/#nslu2-linux dumfrac (n=dumfac@streamer.atd.ucar.edu) |
| 14:46.37 | [g2] | blaster8 you are being pedantic about the changes |
| 14:46.42 | blaster8 | indeed |
| 14:46.48 | [g2] | which is fine |
| 14:47.00 | blaster8 | because if we add features to SVN which people grow to depend on |
| 14:47.03 | blaster8 | then upstream reject them |
| 14:47.10 | blaster8 | we are in trouble |
| 14:47.17 | [g2] | you've been a tremenduous help in moving this stuff forward |
| 14:47.50 | [g2] | however you are confused about the upstream process and the quickest way to get there |
| 14:48.02 | blaster8 | ok, please explain |
| 14:48.43 | [g2] | you think that by having these patches in the open ixp4xx that we are intending to send them upstream |
| 14:49.05 | blaster8 | not quite, but go on |
| 14:49.14 | [g2] | where that's not the case. The open ixp4xx is immature and needs lov'in |
| 14:49.37 | dwery | [g2] is a careful daddy :) |
| 14:49.44 | blaster8 | indeed |
| 14:50.16 | blaster8 | ok, that's fine |
| 14:50.40 | [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 |
| 14:50.41 | blaster8 | but if we add a feature to the open ixp4xx which upstream won't accept, how is that good? |
| 14:51.15 | blaster8 | the status of ixp4xx driver in the repo is to help prepare it for upstream |
| 14:51.31 | blaster8 | unlike many of the other patches, this is going to be a much longer process, unfortunately |
| 14:51.53 | 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 |
| 14:52.21 | blaster8 | technically, even the eeprom notifier stuff is on a knife-edge |
| 14:52.39 | [g2] | blaster8 I've state my position about the patches make your decision |
| 14:52.56 | [g2] | i'ts trivial to pull the patches |
| 14:53.12 | blaster8 | what, the eeprom stuff? |
| 14:53.15 | blaster8 | if so, it's not our decision to make |
| 14:53.32 | blaster8 | We've queried whether upstream will accept them |
| 14:53.40 | blaster8 | If upstream say yes, then they stay |
| 14:53.56 | blaster8 | If upstream say no, then they go, at least from 2.6.19 |
| 14:53.57 | [g2] | who sent the notifer patch upstream ? |
| 14:54.01 | blaster8 | no-one |
| 14:54.16 | [g2] | so then what are you talking about ? |
| 14:54.29 | blaster8 | no, we are checking the principle |
| 14:54.46 | blaster8 | 'Can MAC addresses stored external from a NIC be set by the kernel?' |
| 14:54.58 | blaster8 | We've asked Deepak, and he hasn't got back to us |
| 14:55.49 | [g2] | blaster8 "set by the kernel" isn't nearly specific enough |
| 14:55.56 | blaster8 | it's the first step |
| 14:56.23 | [g2] | look upstream has made their intentions pretty clear (meaning early userspace) |
| 14:56.30 | blaster8 | no, they haven't |
| 14:56.31 | dwery | l-a-k is sometimes slow to accept changes... |
| 14:56.38 | dwery | we just need some patience |
| 14:56.46 | blaster8 | [g2]: they have not made themselves clear - hold on and I will show you |
| 14:57.27 | blaster8 | [g2]: http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=3596/1 |
| 14:57.30 | blaster8 | Note 5 |
| 14:57.43 | 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." |
| 14:57.50 | blaster8 | that's from Deepak in June |
| 14:58.19 | blaster8 | now we have an ixp4xx driver that may one day be suitable for kernel inclusion, we have asked him to clarify this statement |
| 14:58.46 | dwery | I would agree with deepak but there isn't a way to read eeprom without using the notifier patch |
| 14:59.14 | [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. " |
| 14:59.58 | 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 |
| 15:00.22 | [g2] | there's already a platform MAC, we are just discussing how it gets intitialized properly and under what conditions it works |
| 15:00.30 | [g2] | two actually |
| 15:00.53 | blaster8 | [g2]: I've forwarded you the email sent to Deepak by Rod last week |
| 15:01.07 | blaster8 | afaik there has been no reply |
| 15:01.46 | [g2] | blaster8 yeah Deepak has been really busy the last 6+ months, it's either 46x stuff or other things |
| 15:02.03 | 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 |
| 15:03.36 | *** join/#nslu2-linux l0c4lh0st (n=a@j147098.upc-j.chello.nl) |
| 15:03.44 | blaster8 | my suggestion would be to get initramfs going asap |
| 15:05.07 | [g2] | blaster8 you're totally missing the point |
| 15:05.11 | 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 |
| 15:05.22 | blaster8 | [g2]: how am I missing the point? |
| 15:06.28 | [g2] | there are others that have _zero_ interest in the concerns of "initramfs" etc.... |
| 15:06.35 | blaster8 | like? |
| 15:06.55 | [g2] | that's absolutely the correct technical thing to do and look into |
| 15:07.05 | [g2] | I personally plan on doing it myself |
| 15:07.28 | blaster8 | I'm confused by this statement: 'there are others that have _zero_ interest in the concerns of "initramfs" etc....' |
| 15:07.40 | blaster8 | who are the others? what are the concerns? |
| 15:08.16 | [g2] | commercial clients |
| 15:08.36 | *** join/#nslu2-linux VoodooZ (i=palm3@modemcable214.50-82-70.mc.videotron.ca) |
| 15:08.37 | blaster8 | that's fine |
| 15:08.43 | blaster8 | just keep it in your local tree |
| 15:09.25 | [g2] | blaster8 as I've said before, just say the word |
| 15:09.39 | blaster8 | it's not up to us [g2] |
| 15:09.43 | blaster8 | it's up to upstream |
| 15:09.52 | blaster8 | and they haven't made the pronouncement yet |
| 15:10.02 | blaster8 | (in fact we haven't even got to that question ;) ) |
| 15:10.11 | blaster8 | ok |
| 15:10.16 | [g2] | which makes this discussion mute |
| 15:10.21 | blaster8 | indeed |
| 15:10.54 | blaster8 | except for the fact that it may be a good idea to just do everything in user space |
| 15:11.19 | blaster8 | rather than working on kernel patches which we may have to jettison at a later date |
| 15:11.29 | blaster8 | just a suggestion, mind |
| 15:14.10 | dwery | I personally hate using early userspace and that's why I coded my own patch. |
| 15:14.33 | blaster8 | that's fine |
| 15:15.09 | blaster8 | but if upstream tells us that's what we have to do, we have little choice |
| 15:15.13 | dwery | sure |
| 15:15.15 | blaster8 | except to fork of course ;) |
| 15:15.22 | dwery | I haven't said we should keep the patch |
| 15:15.24 | dwery | :) |
| 15:15.41 | blaster8 | cool |
| 15:15.46 | dwery | but I will keep it for my own work ;) |
| 15:15.57 | blaster8 | it's an elegant solution |
| 15:16.54 | blaster8 | I'm sorry I'm having to act as self-appointed Kernel Repo police |
| 15:17.12 | dwery | np |
| 15:17.33 | dwery | back in the days it was rwhitby and me who pushed for "up or out" |
| 15:17.43 | blaster8 | hehe |
| 15:18.11 | dwery | as a result, I had to push up the whole new rtc class subsystem :-D |
| 15:19.39 | blaster8 | good thing too |
| 15:32.55 | dumfrac | does anybody know why CONFIG_GENERIC_TIME (11-ixp4xx-clocksource.patch) is not set in defconfig for svn 2.6.18 kernel ? |
| 15:35.25 | dwery | scsi 0:0:0:0: Direct-Access ATA SanDisk SDCFB-51 HDX PQ: 0 ANSI: 5 |
| 15:35.36 | dwery | SCSI device sda: 1000944 512-byte hdwr sectors (512 MB) |
| 15:36.33 | blaster8 | dumfrac: not sure, but... |
| 15:36.41 | blaster8 | well done dwery, if that's what I think it is |
| 15:36.51 | dwery | I hope so ;) |
| 15:37.04 | blaster8 | dumfrac: probably something to do with our clocksource backport |
| 15:37.20 | dumfrac | blaster8: clocksource backport ? |
| 15:37.36 | blaster8 | ixp4xx clocksource support is in 2.6.19-rc1, but not 2.6.18 |
| 15:37.43 | dwery | [g2]: |
| 15:37.43 | dwery | 9952+0 records in |
| 15:37.43 | dwery | 9952+0 records out |
| 15:37.43 | dwery | 5095424 bytes transferred in 5.349326 seconds (952536 bytes/sec) |
| 15:37.47 | dumfrac | so this patch is a backport ? |
| 15:37.52 | blaster8 | however, we need it in our 2.6.18 because it contains a fixup for our broken timer |
| 15:37.53 | dwery | that should be reading speed |
| 15:38.31 | dumfrac | the 66 MHz versus 66.666666 MHz issue ? |
| 15:38.36 | blaster8 | dumfrac: yes |
| 15:38.58 | dumfrac | ok - I'm going to try it out in Debian this evening |
| 15:39.11 | [g2] | dwery cool that's on the Loft with .19-rc3 ? |
| 15:39.21 | dwery | yes. without interrupts. |
| 15:39.28 | blaster8 | can you check if the kernel time keeps good time, dumfrac? |
| 15:39.40 | [g2] | nearly 1MBs |
| 15:39.50 | blaster8 | if it does, then I'd just leave it as it is... |
| 15:40.13 | dwery | [g2]: I must now do some sanity checks |
| 15:40.32 | [g2] | dwery any patches needed ? |
| 15:40.52 | dwery | yes, a small change to libata, loft platform + pata driver |
| 15:41.00 | 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 |
| 15:41.04 | dwery | I will be sending them to you in a few mins |
| 15:41.24 | [g2] | dwery super I'll be able to do some testing on that |
| 15:41.35 | dwery | [g2]: you moved to rc3? |
| 15:41.37 | blaster8 | [g2]: time to fix up Loft patches for upstream, then :) |
| 15:42.07 | dwery | yep. If someone can take care to separate the platforms |
| 15:42.14 | dwery | (loft/avila/ixdp) |
| 15:42.17 | dwery | I will add the other bits |
| 15:43.11 | [g2] | dwery when does the next window open ? |
| 15:43.24 | [g2] | for upstream changes ? |
| 15:43.27 | blaster8 | no idea |
| 15:43.35 | dwery | mm dunno.. but given the change required for libata |
| 15:43.44 | dwery | it will require a bit mor eprobably |
| 15:43.45 | blaster8 | but the sooner the patches are done, the better for merging |
| 15:43.52 | dwery | unless I manage to fix the interrupts.. |
| 15:44.12 | dwery | it seems I'm able to read what I write to the card |
| 15:44.54 | dwery | writing is 165455 bytes/sec |
| 15:45.13 | blaster8 | dwery: is this BE/LE compatible, in theory |
| 15:45.20 | dwery | I really hope so |
| 15:45.34 | blaster8 | you will need to test it, unfortunately |
| 15:45.34 | dwery | maybe [g2] will be able to test |
| 15:45.41 | dwery | as I have only LE environment |
| 15:45.46 | blaster8 | as 'no sane hardware developer should run ixp4xx LE' |
| 15:45.50 | [g2] | dwery 1st LE testing |
| 15:45.55 | blaster8 | (until we sort out data-coherent mode) |
| 15:46.02 | dwery | eheh.. in fact, the only reason |
| 15:46.20 | dwery | for me to use the NSLU2 it was that Peter K. enabled in in LE |
| 15:46.27 | dwery | so that Debian was usable. |
| 15:46.44 | dwery | without Peter I won't be there probably :) |
| 15:46.49 | dwery | so blame on him! :D |
| 15:47.28 | 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 |
| 15:47.36 | dwery | that would be good |
| 15:47.48 | blaster8 | another major upstream faf though |
| 15:48.20 | [g2] | blaster8 web-enabled Loft dev kit ? |
| 15:48.24 | blaster8 | yeah |
| 15:48.32 | blaster8 | hosted by ka6sox |
| 15:48.45 | blaster8 | software controlled power and remote serial connections |
| 15:49.17 | blaster8 | I'm going to try and fix up the same thing for the NSLU2 next summer at home |
| 15:49.19 | [g2] | ok. I'm waiting for lennert and christian to figure out how to progress |
| 15:49.27 | blaster8 | why? |
| 15:49.37 | blaster8 | Are they even talking? |
| 15:50.02 | [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 |
| 15:50.19 | [g2] | I trust lennert alot on upstream matters |
| 15:50.22 | blaster8 | well, it's not quite that simple |
| 15:50.27 | blaster8 | now there are crypto drivers too |
| 15:50.42 | dwery | blaster8: we have crypto? |
| 15:50.47 | blaster8 | yes |
| 15:50.51 | dwery | working? |
| 15:50.53 | blaster8 | but it's not released yet |
| 15:50.58 | blaster8 | well, apparently |
| 15:51.02 | [g2] | blaster8 again, it's GPL anyone _could_ send it upstream |
| 15:51.04 | dwery | it's downloadable? |
| 15:51.15 | blaster8 | no, still in private CVS |
| 15:51.18 | dwery | :( |
| 15:51.33 | blaster8 | should be out very soon - email Christian if you want to look at the code |
| 15:51.35 | [g2] | blaster8 however, it doesn't make any sense not to try and work hand-in-hand with christian |
| 15:51.43 | dwery | I'd love to benchmark some MD5 on NPE-A |
| 15:51.51 | blaster8 | NPE-A? |
| 15:51.59 | dwery | [g2]: I've sent the patches |
| 15:52.04 | blaster8 | Crypto is in NPE-C |
| 15:52.04 | [g2] | loft's have another NPE |
| 15:52.16 | blaster8 | NPE-A has not crypto support |
| 15:52.24 | dwery | doh! |
| 15:52.33 | [g2] | blaster8 we've got IXP425s |
| 15:52.40 | blaster8 | only NPE-C - and the crypto support co-exists with running an ethernet mac |
| 15:52.43 | [g2] | 533Mhz ones at that |
| 15:52.45 | blaster8 | [g2]: I worked this out :) |
| 15:52.50 | blaster8 | with your help, mind |
| 15:53.03 | dwery | oooh wel... too many NPEs :) |
| 15:53.06 | blaster8 | nota bene: 'crypto support co-exists with running an ethernet mac' |
| 15:53.20 | blaster8 | NPE-A is only useful as a DMA engine, with the Avila/Loft |
| 15:53.35 | dwery | now tell me that we also have code for that :) |
| 15:53.44 | [g2] | or with the Utopia/NPE-A stuff |
| 15:54.04 | [g2] | dwery has a header for that too |
| 15:54.25 | blaster8 | ok, fine |
| 15:54.32 | blaster8 | dwery: no code for DMA yet |
| 15:54.39 | dwery | ok :) |
| 15:54.46 | blaster8 | dwery: waiting on the updates to the DMA API before I push that |
| 15:55.02 | blaster8 | push, meaning, push someone else to write it (of course) |
| 15:55.02 | dwery | I just need some quick MD5 bashing machine... and awaiting for the Cell processor on the PS3 |
| 15:55.07 | dwery | blaster8: :D |
| 15:55.13 | blaster8 | :p |
| 15:55.40 | [g2] | s/MD5/SHA1/ |
| 15:55.55 | [g2] | MD5's have collisions |
| 15:56.34 | dwery | yes, In fact I have to collide it :) |
| 15:56.38 | dwery | need to resolve some MD5 |
| 15:57.16 | dwery | here is dmesg from pata driver http://rafb.net/paste/results/mKjlyG99.html |
| 15:57.59 | [g2] | dwery cool. I'm excited about that |
| 15:58.19 | dwery | I forgot I had a filesystem on the cf and blasted it with zeros ;) |
| 15:58.51 | dwery | ok, ext3 created succesfully on the cf |
| 15:58.55 | [g2] | WHOA! dwery you may be in big trouble |
| 15:58.59 | blaster8 | ? |
| 15:59.23 | dwery | the telco is going to cut my ADSL? :) |
| 15:59.41 | dwery | I cannot see anything else that could be called "big trouble" :) |
| 15:59.53 | [g2] | no, jbowler, just posted, I think he's gonna displace you as the "notifier master" ! |
| 16:00.12 | [g2] | lmao |
| 16:00.17 | dwery | he posted? |
| 16:00.24 | dwery | where? I would LOVE to have him bach here |
| 16:00.27 | dwery | back |
| 16:00.59 | [g2] | dwery check your mail |
| 16:01.08 | blaster8 | it's on nslu2-devel |
| 16:01.25 | blaster8 | he wants firmware pull from mtd in kernelspace too ;) |
| 16:02.31 | [g2] | jbowler has a Loft too |
| 16:02.44 | dwery | maybe I haven't received the email yet |
| 16:03.06 | [g2] | no you weren't on the original list, I just forwarded it to you |
| 16:03.17 | [g2] | but it is on the devel-list |
| 16:04.39 | 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. |
| 16:04.51 | dwery | [g2]: so please forward him my mtd patch :) |
| 16:05.34 | [g2] | dwery I'm sure you can just e-mail him the patch |
| 16:05.45 | [g2] | if you want me to I'll be happy to also |
| 16:05.49 | dwery | yes please |
| 16:05.59 | dwery | still testing the cf ;) |
| 16:06.52 | dwery | filesystem is ok. We just need BE validation, but I guess it will work |
| 16:07.02 | blaster8 | I've sent out a response to that mail with a couple of updates |
| 16:07.46 | [g2] | dwery I don't have the mtd patch handy can you e-mail ? |
| 16:08.02 | blaster8 | [g2]: it's still on the web |
| 16:08.08 | dwery | ok |
| 16:08.17 | 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 |
| 16:09.02 | [g2] | blaster8 again you missing the fact that I want to include other patches like the CF too |
| 16:09.28 | blaster8 | sorry, you said 'the mtd patch' |
| 16:09.57 | [g2] | blaster8 np, I asked for the "mtd patch", but that wasn't the _only_ thing I had in mind |
| 16:09.58 | blaster8 | the libata CF patch can go into 2.6.19-rc3 SVN ASAP :) |
| 16:10.16 | blaster8 | brb |
| 16:10.21 | [g2] | blaster8 I don't expect you to be a mind reader |
| 16:12.39 | dwery | [g2]: i've still problems with USB... please give it a try on rc3 when you have time |
| 16:12.56 | [g2] | dwery sure, most likely later today |
| 16:13.21 | [g2] | first I want to boot on 19-rc3 onto the CF drive |
| 16:13.30 | [g2] | then I can mount and test USB |
| 16:14.00 | dwery | I forgot you always booted from CF :) |
| 16:14.22 | [g2] | dwery no I always usually boot to USB |
| 16:14.56 | [g2] | however, I've been testing on 128MB units and a couple I got from someone have no USB |
| 16:16.38 | dwery | [g2]: which version of redboot do you have? |
| 16:16.48 | [g2] | 2.02 |
| 16:17.34 | [g2] | the one that fully supports the -m disk option for the CF |
| 16:17.34 | dwery | I wonder if they changed the NPE firmware |
| 16:18.08 | [g2] | there was a tweak in Mar '06 but I don't think NPE stuff changed |
| 16:18.24 | [g2] | dwery I've got all the source and have built my own RedBoots |
| 16:18.31 | [g2] | and flashed them :) |
| 16:18.41 | dwery | eheh ;) so it seems Christian understood how to reverse eng the NPE microcode |
| 16:18.51 | blaster8 | ? |
| 16:19.46 | dwery | I mean, I managed to do crypto.. so I thought I had to write some microcode for it, right? |
| 16:19.50 | dwery | s/I/He/ |
| 16:19.53 | blaster8 | no |
| 16:20.03 | dwery | wrong regexp :) |
| 16:20.11 | blaster8 | Crypto microcode can be downloaded from the Intel website |
| 16:20.23 | blaster8 | it just requires another layer of authentication |
| 16:20.28 | dwery | oh |
| 16:20.37 | blaster8 | VoodooZ: Some of the gentoo guys have |
| 16:20.50 | dwery | [g2]: your redboot has three microcodes, so I suppose the third one is crypto, right? |
| 16:21.00 | blaster8 | doubt it (export regulations) |
| 16:21.08 | blaster8 | but you never know... |
| 16:21.16 | VoodooZ | blaster8, yeah, was it joshin? But would that work with slugos4? |
| 16:21.38 | blaster8 | VoodooZ: possibly |
| 16:21.41 | VoodooZ | I had glibc2.5 build properly under HEAD but I'm not sure if I can just install it? |
| 16:21.47 | blaster8 | well, you can try |
| 16:21.55 | [g2] | dwery dunno if that's in there |
| 16:22.09 | [g2] | dwery I'd guess not |
| 16:22.11 | VoodooZ | yeah, I wish I had a second slug for testing as I can't flash my robot's board. |
| 16:22.22 | dwery | [g2]: so we have a misterious firmware :) |
| 16:22.30 | VoodooZ | I heard the slug stuff would need to be updated to use the EABI stuff. |
| 16:22.37 | *** join/#nslu2-linux yvasilev (n=yvasilev@dune.math.cinvestav.mx) |
| 16:22.42 | [g2] | dwery there's NPE-A support |
| 16:22.53 | dwery | [g2]: What's NPE-A used for? |
| 16:23.09 | [g2] | Utopia and other stuff |
| 16:23.13 | [g2] | TDM |
| 16:23.39 | [g2] | WAN interfaces etc... |
| 16:23.51 | blaster8 | can be used for Ethernet on IXP465 but not on 425 |
| 16:24.07 | dwery | [g2]: interesting. |
| 16:24.17 | dwery | ok, what can we really do with it?. i.e. something useful ;) |
| 16:24.31 | blaster8 | DMA engine |
| 16:24.43 | blaster8 | that's quite useful |
| 16:24.49 | dwery | nice |
| 16:24.55 | blaster8 | NPE-A ADSL drivers are under a stupid licence |
| 16:24.55 | dwery | what's Utopia? I can't remember |
| 16:25.03 | blaster8 | non-redistributable, or something |
| 16:25.03 | [g2] | dwery there are lots of applications |
| 16:25.26 | blaster8 | [g2]: but they all require the IXP-OSAL |
| 16:25.26 | [g2] | utopia is like the ATM MII interface |
| 16:25.54 | [g2] | but it's really a synchronuous interface |
| 16:26.04 | [g2] | and often used for other stuff |
| 16:26.23 | dwery | ok |
| 16:26.39 | [g2] | it comes in various widths and clock speeds |
| 16:26.45 | [g2] | like SCSI |
| 16:27.01 | blaster8 | but has no linux support :( |
| 16:28.44 | [g2] | blaster8 it would need a driver anyway |
| 16:28.55 | blaster8 | that's basically what I mean |
| 16:29.47 | [g2] | I'd guess crypto is 5x as hard to do |
| 16:30.11 | [g2] | so I'd put it at a .5 of the current driver non-crypto |
| 16:30.41 | [g2] | besides with the current drivers working, it'd be non-essential and development would be way quicker |
| 16:31.02 | [g2] | but the applications are probably pretty small |
| 16:35.16 | [g2] | bbl off to lunch |
| 16:35.31 | blaster8 | ok |
| 16:36.48 | *** join/#nslu2-linux kfm82sparcbsd (i=kfm82@p54BEF3EB.dip.t-dialin.net) |
| 16:41.32 | *** join/#nslu2-linux eno (n=eno@nslu2-linux/eno) |
| 16:43.37 | dwery | net speed test http://rafb.net/paste/results/PjMGE349.html |
| 16:43.46 | dwery | bbl |
| 16:44.07 | blaster8 | same here |
| 16:44.13 | blaster8 | bb next week |
| 16:44.31 | blaster8 | looking forward to seeing the upstream-ready loft patches in 2.6.19 :) |
| 17:03.30 | *** join/#nslu2-linux CieD (n=CieD@81.168.95.39) |
| 17:24.41 | *** join/#nslu2-linux AdamBaker (n=aab@userch028.dsl.pipex.com) |
| 17:31.02 | *** join/#nslu2-linux kfm82 (n=kfm82@p54BEF3EB.dip.t-dialin.net) |
| 17:47.40 | [g2] | dwery I got the CF patch but never the mtd patch :( |
| 17:48.35 | 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 |
| 17:50.41 | [g2] | I'll send him that URL |
| 17:50.55 | [g2] | as the wget returns html |
| 17:51.22 | dwery | i already sent the patches to jhon |
| 17:51.24 | dwery | john |
| 17:51.49 | dwery | did you placed the url around quotes, right? |
| 17:52.30 | [g2] | on on the wget ? |
| 17:53.05 | [g2] | doesn't make a different |
| 17:53.13 | [g2] | s/different/difference/ |
| 17:56.42 | *** join/#nslu2-linux DrZimmerman (n=theo@84-72-181-62.dclient.hispeed.ch) |
| 18:00.41 | *** part/#nslu2-linux dumfrac (n=dumfac@streamer.atd.ucar.edu) |
| 18:00.50 | *** join/#nslu2-linux Tobbe (n=tobbe@kbhn-vbrg-sr0-vl203-120.perspektivbredband.net) |
| 18:23.52 | 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' |
| 18:23.52 | dwery | returns a text file to me |
| 18:24.41 | [g2] | ah I used " |
| 18:25.30 | dwery | should be the same.. |
| 18:29.24 | [g2] | hmm... oddly it's different and a text file |
| 18:29.40 | [g2] | but good to know :) |
| 18:37.36 | [g2] | bbl |
| 18:53.04 | *** join/#nslu2-linux caplink811-log (n=caplink8@dslb-088-073-004-041.pools.arcor-ip.net) |
| 18:53.59 | *** join/#nslu2-linux kolla (i=kolla@firda.kolla.no) |
| 19:34.50 | *** join/#nslu2-linux [g2] (n=g2@nslu2-linux/g2) |
| 20:08.05 | *** join/#nslu2-linux likewise (n=chatzill@82-171-189-134.dsl.ip.tiscali.nl) |
| 20:08.31 | likewise | good evening |
| 20:24.12 | NAiL | and good night ;) |
| 20:24.35 | likewise | :-) |
| 20:24.44 | likewise | you're off? |
| 20:25.14 | NAiL | yeah |
| 20:25.23 | NAiL | Dead tired and have to get up early tomorrow |
| 20:25.40 | likewise | Sleep well then! |
| 20:25.47 | NAiL | thanks |
| 20:35.15 | *** join/#nslu2-linux rwhitby (n=rwhitby@nslu2-linux/rwhitby) |
| 21:04.11 | *** join/#nslu2-linux blaster8 (n=blaster8@nslu2-linux/blaster8) |
| 21:11.34 | *** join/#nslu2-linux eiffel (n=eiffel@pD9572F11.dip0.t-ipconnect.de) |
| 21:33.34 | *** join/#nslu2-linux HopsNBarley (n=andy24@pool-71-116-78-114.snfcca.dsl-w.verizon.net) |
| 21:38.04 | dwery | [g2]: good news |
| 21:38.12 | dwery | 29408+0 records in |
| 21:38.12 | dwery | 29408+0 records out |
| 21:38.12 | dwery | 15056896 bytes transferred in 14.148661 seconds (1064192 bytes/sec) |
| 21:38.23 | dwery | this is reading from CF with interrupts enabled |
| 21:38.39 | blaster8 | well done |
| 21:38.44 | [g2] | dwery great |
| 21:38.49 | blaster8 | does that mean you can knock the libata patch on the head? |
| 21:39.12 | dwery | and this is writing: |
| 21:39.12 | dwery | 11841+0 records in |
| 21:39.12 | dwery | 11840+0 records out |
| 21:39.12 | dwery | 6062080 bytes transferred in 11.571310 seconds (523889 bytes/sec) |
| 21:39.24 | blaster8 | twice as fast as before? |
| 21:39.27 | dwery | blaster8: need a few more tests but should be in svn within 30 mins |
| 21:39.36 | blaster8 | great wrok |
| 21:39.41 | blaster8 | s/wrok/work |
| 21:40.05 | blaster8 | leave the loft specific patches local for now - I'd really like to see this in SVN asap |
| 21:40.40 | dwery | well.. without loft patches isn't so useful but ok :) |
| 21:43.03 | dwery | read/write ops to the cf are quite a load for the cpu |
| 21:43.12 | blaster8 | well, it is PIO, right? |
| 21:44.44 | dwery | yes |
| 21:44.46 | dwery | :( |
| 21:45.01 | blaster8 | and no way of getting DMA access to that region? |
| 21:45.30 | blaster8 | actually CF DMA isn't great at the best of times, mind |
| 21:47.24 | blaster8 | silliness |
| 21:47.39 | blaster8 | kernel initramfs generation is at the beginning of the compile, not the end |
| 21:47.49 | blaster8 | so you can't package modules you've just built |
| 21:47.51 | blaster8 | d'oh |
| 21:50.04 | dwery | dunno if DMA is doable. |
| 21:50.19 | blaster8 | [g2] says no |
| 21:50.36 | blaster8 | it would be a major faf, and probably wouldn't be that much better performance wise |
| 21:50.47 | blaster8 | if you were running a hard drive, it would be different |
| 21:50.57 | dwery | but it might help the cpu |
| 21:51.08 | blaster8 | it would |
| 21:51.19 | dwery | but given the way the CF is wired |
| 21:51.29 | blaster8 | that is the problem AFAIK |
| 21:51.33 | dwery | it would probably require writing NPE microcode |
| 21:51.41 | blaster8 | DMA Engine? |
| 21:51.54 | [g2] | faf ? |
| 21:51.55 | dwery | the DMA engine should have the capability to toggle an I/O line |
| 21:52.05 | dwery | to handle this wiring. |
| 21:52.18 | dwery | anyway, we'll check later |
| 21:52.43 | blaster8 | faf - wasting time doing not very useful things |
| 21:52.44 | [g2] | I think the NPEs can see the EXP bus |
| 21:52.55 | [g2] | so in theory the code could be moved to the NPEs |
| 21:53.31 | [g2] | I'll have to look at the NPE again, but maybe NPE-A could baby-sit the EXP bus for the IDE driver |
| 21:53.43 | [g2] | but this is really pie-in-the-sky stuff |
| 21:53.53 | blaster8 | lets get it working first |
| 21:54.30 | blaster8 | dwery: do you know about kernel initialisation |
| 21:54.37 | blaster8 | i.e. what starts whenn |
| 21:54.57 | dwery | eheh.. I think only Linus knows that... it's very difficult to determine the order |
| 21:55.07 | dwery | it depends on initcalls and compilation |
| 21:55.31 | dwery | [g2]: then we need the NPEs istruction set :) |
| 21:55.47 | [g2] | dwery yeah :) |
| 21:56.04 | blaster8 | dwery: does initramfs load before drivers? |
| 21:56.13 | 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. |
| 21:56.18 | dwery | [g2] come on.. hand me that "for your eyes only" pdf |
| 21:56.24 | dwery | :) |
| 21:56.39 | dwery | blaster8: initram is supposed to load early |
| 21:56.48 | dwery | but I don't know the exact sequence |
| 21:56.55 | [g2] | rwhitby thx |
| 21:56.57 | rwhitby | BTW, loft-specific patches go in our SVN too. |
| 21:57.07 | rwhitby | we're trying to keep Loft in the fold, not push it out :-) |
| 21:57.26 | [g2] | rwhitby I _totally_ know |
| 21:57.47 | dwery | blaster8: Documentation/initrd.txt has am high level description of the sequence |
| 21:57.54 | blaster8 | thanks |
| 21:57.55 | rwhitby | guys, I need to take some time to re-read the backlogs |
| 21:58.06 | dwery | rwhitby: I'm about to push the compact flash driver |
| 21:58.13 | rwhitby | I think we should go in parallel down two paths: everything in kernel, and everything in early userspace |
| 21:58.30 | rwhitby | and then see how much we can get upstream once we have working code for both |
| 21:58.44 | dwery | rwhitby: should I leave out Loft specific bits from series? |
| 21:58.47 | [g2] | rwhitby I thought that's exactly what we were doing :) |
| 22:00.03 | rwhitby | dwery: good question |
| 22:00.22 | dwery | rwhitby: loft bits also requires 65-loft-config.patch which is not in the repo |
| 22:00.48 | rwhitby | should be added then |
| 22:01.14 | blaster8 | rwhitby: loft patches need to be cleaned up first |
| 22:02.02 | blaster8 | avila and loft need to be separated out from ixdp425 now we have the ixp4xx CF driver |
| 22:02.35 | rwhitby | guys, can we discuss this in about 2 hours time? |
| 22:02.46 | blaster8 | http://lxr.linux.no/source/arch/arm/mach-ixp4xx/ixdp425-setup.c?a=arm |
| 22:02.49 | [g2] | sure that's fine with me |
| 22:03.02 | rwhitby | (middle of morning kids routine here) |
| 22:04.07 | blaster8 | look, I'll clean up the loft patches |
| 22:04.13 | dwery | blaster8: thanks. |
| 22:04.25 | blaster8 | bloody hell, it's not even my device :p |
| 22:05.49 | dwery | nor is the avila :) |
| 22:06.19 | blaster8 | indeed |
| 22:06.24 | dwery | we need to find an avila for tests... |
| 22:06.36 | blaster8 | ask avila? |
| 22:07.02 | dwery | I don't even know how an avila looks like :) |
| 22:07.13 | CIA-8 | 03azummo * r523 10kernel/trunk/patches/2.6.19/ (96-pata-ixp4xx.patch series): IXP4XX generic Compact Flash PATA/libata driver |
| 22:07.38 | rwhitby | [g2]: good plan for the moment |
| 22:07.47 | rwhitby | back when I get to work |
| 22:07.52 | blaster8 | done |
| 22:10.53 | rwhitby | [g2]: put them in series, commented out. |
| 22:11.09 | rwhitby | (with a comment above saying why they are commented out, and what each depends on) |
| 22:11.11 | [g2] | rwhitby sure that's fine too |
| 22:11.29 | rwhitby | so someone can easily uncomment them to test them |
| 22:12.03 | CIA-8 | 03bzhou * r4282 10optware/trunk/make/gambit-c.mk: gambit-c: upstream upgrade to 4.0b20 |
| 22:57.53 | *** join/#nslu2-linux mithro (n=tim@ppp246-117.static.internode.on.net) |
| 23:02.38 | *** join/#nslu2-linux ecopperbech (n=copperbe@82-40-186-72.cable.ubr04.newm.blueyonder.co.uk) |
| 23:26.22 | *** join/#nslu2-linux yvasilev (n=yvasilev@189.140.152.251) |
| 23:56.53 | CIA-8 | 03blaster8 * r524 10kernel/trunk/patches/2.6.19/ (3 files): Prelimary Avila/Loft support, Non-functional |