**** BEGIN LOGGING AT Mon Mar 07 23:59:56 2005 Mar 08 00:00:10 well, what would be INTD ought to be left maked Mar 08 00:00:19 masked too Mar 08 00:00:50 <[g2]> I'd think so Mar 08 00:01:08 <[g2]> but isn't power being used on the INTD line Mar 08 00:01:54 it is an output to clr the F/F as I recall Mar 08 00:02:36 <[g2]> ok, do you remember where the power-button comes in ? Mar 08 00:02:54 <[g2]> I know the reset button triggers correctly Mar 08 00:03:18 * [g2] needs to hunt down the GPIO for power-down anyway Mar 08 00:04:12 reset is on a gpio...power button goes to the F/F and F/F Q goes to gpio iirc Mar 08 00:05:53 Tiersten rang all that out I think Mar 08 00:09:12 ok..cancel that...gpio8 is the power off interrupt so irq2gpio is ok Mar 08 00:10:00 <[g2]> I'm in irqs.h looking for the def Mar 08 00:10:31 <[g2]> which is missing :) Mar 08 00:13:56 shows up in nslu2-io.c Mar 08 00:14:11 * [g2] checking Mar 08 00:14:21 <[g2]> but it's not defined in irqs.h Mar 08 00:14:25 int22/gpio5 Mar 08 00:15:41 <[g2]> all right, so this may very be a problem or not Mar 08 00:16:23 line 41 in irqs.h...gpio5...gets mapped to int22 in irq2gpio Mar 08 00:16:46 nslu2-io picks it up there Mar 08 00:18:18 <[g2]> nod. On the gpio5 getting mapped to irq 22 Mar 08 00:18:24 line 66 in nslu2-io Mar 08 00:18:27 yep Mar 08 00:20:10 and that works...although not correctly Mar 08 00:21:30 afaik, it just pulls the plug...shutdown scripts need to close everything before it pulls the plug Mar 08 00:21:57 <[g2]> it does shutdown everything, but then doesn't pull the plug Mar 08 00:23:35 something above must have gotten implemented...it would pull the plug here when I was last working on it Mar 08 00:24:03 I never fully worked out the /proc interface Mar 08 00:24:45 <[g2]> I'm wondering if we've got a timer conflict Mar 08 00:25:37 <[g2]> kas11, I nslu2-io isn't required is it ? Mar 08 00:25:50 <[g2]> I could build without it correct ? Mar 08 00:26:06 <[g2]> clearly the leds etc wouldn't work Mar 08 00:26:21 that is where leds, reset and buzzer are Mar 08 00:26:42 <[g2]> I understand that Mar 08 00:26:55 <[g2]> I'm saying I can run without that stuff Mar 08 00:26:57 otherwise, I guess not Mar 08 00:27:43 <[g2]> clearly from a testing perspective, if I remove nslu2-io and build, and test and the problem is still there, then nslu2-io is clearly *not* involved at all Mar 08 00:27:45 you have handlers for the other stuff elsewhere? Mar 08 00:28:15 oic...no, it isn't necessary...but it can't see it being involved Mar 08 00:29:01 <[g2]> you can't see it being involved in the EHCI issue ? Mar 08 00:30:03 really, we need to figure out what params are coming in to the pci setup...nobody cared is saying it is an IRQ problem.. Mar 08 00:30:24 <[g2]> right Mar 08 00:30:40 <[g2]> And I was going to get rid of a couple IRQs for testing purposes Mar 08 00:30:52 slot and pin....they are coming from PCI config...and I have no idea what the values really are Mar 08 00:32:03 I saw something yesterday that had 12 and 13 as the slot..don't know what that maps to but it is apt to be a problem Mar 08 00:32:49 <[g2]> right I'm just trying to understand how it's all mapped and check each and every one of our 13 ints Mar 08 00:32:54 I don't understand the swizzle thing...and I tend to worry about things in have no understanding of Mar 08 00:32:57 <[g2]> lucky 13 :) Mar 08 00:33:19 <[g2]> swizzle thing ? Mar 08 00:33:45 I would put a printk in to see what slot and pin are Mar 08 00:34:00 <[g2]> I'm just grep'ing for them Mar 08 00:34:42 <[g2]> #define NSLU2_PCI_INTA_PIN 11 Mar 08 00:34:42 <[g2]> #define NSLU2_PCI_INTB_PIN 10 Mar 08 00:34:42 <[g2]> #define NSLU2_PCI_INTC_PIN 9 Mar 08 00:34:42 <[g2]> /#define NSLU2_PCI_INTD_PIN 8 Mar 08 00:34:43 pci_swizzle...they mix the INTs for some reason....sharing, priority,??? Mar 08 00:35:25 <[g2]> nslu2.h hey you wrote that :) Mar 08 00:35:50 <[g2]> / GPIO 8 is used as the power input so is not free for use as a PCI IRQ Mar 08 00:35:50 <[g2]> / kas11 11-2-04 Mar 08 00:36:01 <[g2]> :) Mar 08 00:36:04 but it is pin, not PIN ;) Mar 08 00:36:39 I know...that is why I keep bugging you about it...it is prolly broken... Mar 08 00:37:02 <[g2]> I think you setup a test for me and I'm failing badly :) Mar 08 00:38:13 some people think that slot is 0 based, others not...pin is 1 based....I still haven't drilled deep enough to find how they are derived Mar 08 00:39:13 <[g2]> PCI: bus0: Fast back to back transfers disabled Mar 08 00:39:13 <[g2]> dmabounce: registered device 0000:00:01.0 on pci bus Mar 08 00:39:13 <[g2]> dmabounce: registered device 0000:00:01.1 on pci bus Mar 08 00:39:13 <[g2]> dmabounce: registered device 0000:00:01.2 on pci bus Mar 08 00:39:33 <[g2]> is the lowest number the slot ? Mar 08 00:40:09 <[g2]> obviously we'd need to check the code that does the printk Mar 08 00:41:03 <[g2]> PCI: enabling device 0000:00:01.0 (0140 -> 0142) Mar 08 00:41:03 <[g2]> ohci_hcd 0000:00:01.0: OHCI Host Controller Mar 08 00:41:03 <[g2]> ohci_hcd 0000:00:01.0: irq 28, pci mem 0x48000000 Mar 08 00:41:03 <[g2]> ohci_hcd 0000:00:01.0: new USB bus registered, assigned bus number 1 Mar 08 00:41:03 <[g2]> hub 1-0:1.0: USB hub found Mar 08 00:41:04 <[g2]> hub 1-0:1.0: 3 ports detected Mar 08 00:41:06 <[g2]> PCI: enabling device 0000:00:01.1 (0140 -> 0142) Mar 08 00:41:08 <[g2]> ohci_hcd 0000:00:01.1: OHCI Host Controller Mar 08 00:41:14 <[g2]> ohci_hcd 0000:00:01.1: irq 27, pci mem 0x48001000 Mar 08 00:41:16 <[g2]> ohci_hcd 0000:00:01.1: new USB bus registered, assigned bus number 2 Mar 08 00:41:43 <[g2]> so is 1.0 bus 1 Mar 08 00:41:45 <[g2]> and 1.1 bus 2 Mar 08 00:41:47 <[g2]> ? Mar 08 00:41:59 <[g2]> or is that something totally different ? Mar 08 00:44:40 printk("nslu2_map_irq: slot: %d pin: %d irq: %d\n"); at line 66 in nslu2-pci.c Mar 08 00:46:57 this is pci bus...usb bus is different...dmabounce above is pci bus...but may have been renumerated there Mar 08 00:49:08 <[g2]> kas11, right before the return ? Mar 08 00:49:30 that is prolly slot and pin...that would make sense...but then original code was wrong...it subtracts 2 ... 1 each for slot and pin having a lower limit of 1 I think Mar 08 00:49:56 yes...right before return irq Mar 08 00:52:54 the code does require that slot and pin be >= 1 Mar 08 00:53:30 * [g2] flashing Mar 08 00:54:21 <[g2]> I probably could have just loaded the kernel even without the rootfs for seeing those messages :) Mar 08 00:54:23 <[g2]> oh well Mar 08 00:54:42 this will also say if this somehow gets called later...and the plain printks will show up on the console Mar 08 00:54:53 <[g2]> nod. Mar 08 00:54:54 trut Mar 08 00:55:01 true Mar 08 00:56:29 <[g2]> slu2_map_irq: slot: 3 pin: 2 irq: -1071818384 Mar 08 00:56:29 <[g2]> nslu2_map_irq: slot: 3 pin: 2 irq: -1071818384 Mar 08 00:56:29 <[g2]> nslu2_map_irq: slot: 3 pin: 2 irq: -1071818384 Mar 08 00:57:33 rut ro Mar 08 00:58:55 opps....i forgot the parameter list Mar 08 00:59:31 printk("nslu2_map_irq: slot: %d pin: %d irq: %d\n", slot,pin,irq); Mar 08 00:59:54 sorry 'bout that...I need coffee Mar 08 01:01:33 <[g2]> Hey like I'm the crack code reviewer :) Mar 08 01:02:21 <[g2]> I only see there calls Mar 08 01:02:55 more like the original author was on crack Mar 08 01:03:47 should get 3 calls with more reasonable data now Mar 08 01:08:41 <[g2]> nslu2_map_irq: slot: 1 pin: 1 irq: 28 Mar 08 01:08:41 <[g2]> nslu2_map_irq: slot: 1 pin: 2 irq: 27 Mar 08 01:08:41 <[g2]> nslu2_map_irq: slot: 1 pin: 3 irq: 26 Mar 08 01:09:11 <[g2]> so pins are 1-relative Mar 08 01:09:29 ok...that works right then...as long as we never get another call that isn't the problem Mar 08 01:09:39 yep Mar 08 01:09:53 <[g2]> cool Mar 08 01:10:08 and ehci is getting 26 as expected Mar 08 01:10:28 <[g2]> nod. Mar 08 01:11:09 so..... Mar 08 01:12:05 <[g2]> INTD isn't mapped and isn't cleared Mar 08 01:12:15 <[g2]> which is probably unrelated Mar 08 01:12:26 <[g2]> but would be nice to clear up Mar 08 01:12:36 http://kerneltrap.org/node/3414 Mar 08 01:14:37 <[g2]> yes we are aware of the noirqdebug Mar 08 01:14:45 <[g2]> we are looking to fix the driver issue Mar 08 01:15:23 <[g2]> bewoolie thinks its related to code being in ehci.h Mar 08 01:16:37 need to diff it against 2.6.7 Mar 08 01:20:55 - The "IRQ XX: Nobody Cared" is almost completely gone, but it still Mar 08 01:20:55 shows up once in a while. As far as I can tell, the problem has to Mar 08 01:20:55 do with a small race between acking the GPIO IRQ register and Mar 08 01:20:55 unmasking of interrupts. Will hook up PCI analyze- The "IRQ XX: Nobody Cared" is almost completely gone, but it still Mar 08 01:20:55 shows up once in a while. As far as I can tell, the problem has to Mar 08 01:20:57 do with a small race between acking the GPIO IRQ register and Mar 08 01:20:59 unmasking of interrupts. Will hook up PCI analyzer next week and Mar 08 01:21:01 see exactly what's happening. Note that tnx to rmk's changes, Mar 08 01:21:03 you'll now get a big stack dump when this happens. :)r next week and Mar 08 01:21:05 see exactly what's happening. Note that tnx to rmk's changes, Mar 08 01:21:07 you'll now get a big stack dump when this happens. :) Mar 08 01:21:15 that was from dsaxena Mar 08 01:22:17 that would be load dependent Mar 08 01:22:58 <[g2]> can't we just put a tiny spinlock around that ? Mar 08 01:23:32 <[g2]> wow g2 really tosses one out here Mar 08 01:23:46 <[g2]> slow down on that keyboard pal Mar 08 01:26:25 *g* Mar 08 01:27:24 it is a long standing problem perhaps caused by some int handlers not returning IRQ_HANDLED Mar 08 01:28:37 <[g2]> the question is in my mind, is the hw errata or sw errata ? Mar 08 01:29:04 uh huh...good question Mar 08 01:48:43 this does the same thing under 2.6.11? Mar 08 01:49:00 <[g2]> yep 2.6.9 and 2.6.11 Mar 08 01:51:42 it looks like ehci tries to run without irqs if the 721010 locks up...maybe IRQs are still being generated Mar 08 03:34:04 it would seem true that only gpios that really get used as interrupt inputs should get unmasked...0,1,2,3,6,7 and 8 ought to be masked Mar 08 03:35:22 <[g2]> beewoolie-away, welcome Mar 08 03:35:53 <[g2]> what code were you talking about in here ? the stats or something else http://lxr.linux.no/source/drivers/usb/host/ehci.h?a=arm Mar 08 03:36:31 <[g2]> port_speed ? Mar 08 03:42:06 Howdy folks. Mar 08 03:42:17 <[g2]> Howdy partner! Mar 08 03:43:37 The watchdog timer action functions are in this header. Poor style, IMHO. I consider this over-optimization. Mar 08 03:44:06 [g2]: I've gotten the access library to build, but I doubt it will work as is. Still, it is helpful to have something that compiles and links. Mar 08 03:44:52 <[g2]> great Mar 08 03:47:39 <[g2]> beewoolie-away, did you see the note kas11 posted earlier about what dsaxena wrote about the "nobody cared" interrupt ? Mar 08 03:47:52 when you get nobody cared, is USB dead or still running? Mar 08 03:48:09 <[g2]> the interrupt ? Mar 08 03:48:29 yeah, int26: nobody cared Mar 08 03:48:32 <[g2]> I think USB continues on Mar 08 03:48:51 <[g2]> it tries to be fault tolerant because some chips are defective Mar 08 03:48:59 <[g2]> and lose ints Mar 08 03:49:10 so it is maybe trying to run without interrupts at that point Mar 08 03:49:31 <[g2]> and an interrupt then occurs ? Mar 08 03:50:13 <[g2]> but the timer has expired and the dog has bitten Mar 08 03:50:13 the last one...after that there aren't anymore....maybe...I am just quessing Mar 08 03:51:16 it would be nice to know what got returned when nobody cared Mar 08 03:52:33 The nobody returned error means that no handler returned IRQ_HANDLED. Mar 08 03:54:08 ...or that all returned IRQ_NONE. Mar 08 03:58:46 <[g2]> OK, what does this mean http://lxr.linux.no/source/arch/arm/kernel/irq.c?a=arm#L166 Mar 08 03:59:23 <[g2]> root@LKG0F9D2C:~# dmesg | grep unbal Mar 08 03:59:23 <[g2]> enable_irq(22) unbalanced from c00111d8 Mar 08 03:59:23 <[g2]> enable_irq(29) unbalanced from c00111e0 Mar 08 03:59:57 <[g2]> That seems to indicate something about the depth Mar 08 04:09:46 Looks like a request to enable the irq without disabling it. Mar 08 04:10:05 Annoying, but not a problem in of itself. Mar 08 04:10:13 However, it may indicate that the driver is wonky. Mar 08 04:10:24 What are the 22 and 29 irqs? Mar 08 04:10:48 Notice line 121. Mar 08 04:11:55 <[g2]> root@LKG0F9D2C:~# cat /proc/interrupts Mar 08 04:11:55 <[g2]> CPU0 Mar 08 04:11:55 <[g2]> 0: 0 csr Mar 08 04:11:55 <[g2]> 1: 93 csr Mar 08 04:11:55 <[g2]> 2: 87 csr Mar 08 04:11:56 <[g2]> 3: 16 ixp425_eth Mar 08 04:11:58 <[g2]> 5: 481431 IXP4xx Timer Tick Mar 08 04:12:00 <[g2]> 15: 6964 serial Mar 08 04:12:02 <[g2]> 22: 0 n2_pb Mar 08 04:12:04 <[g2]> 26: 0 ehci_hcd Mar 08 04:12:06 <[g2]> 27: 0 ohci_hcd Mar 08 04:12:08 <[g2]> 28: 0 ohci_hcd Mar 08 04:12:11 <[g2]> 29: 0 n2_rb Mar 08 04:12:14 <[g2]> Err: 0 Mar 08 04:12:19 <[g2]> power button and reset button from the nslu2-io code Mar 08 04:12:47 check. Mar 08 04:13:05 [g2]: Can you tell me again where to get the source code for the redboot patches we use? Mar 08 04:13:29 <[g2]> sluggo in cvs ? Mar 08 04:14:09 also, it looked like openslug boots the kernel faster than the linksys fw. I am guessing that the kernel is enabling the cache during kernel decompression. Is this your understanding. Mar 08 04:14:20 Ah. CVS. that would mean it is available in sourceforge... Mar 08 04:14:59 * [g2] is helpless Mar 08 04:15:16 <[g2]> so many thinks to know so little time Mar 08 04:16:00 <[g2]> I check the dmesg because I've got both around, Mar 08 04:16:21 Unslung 3.18, right? Mar 08 04:16:27 <[g2]> Machine: Linksys NSLU2 Mar 08 04:16:27 <[g2]> Warning: bad configuration page, trying to continue Mar 08 04:16:27 <[g2]> Memory policy: ECC disabled, Data cache writeback Mar 08 04:16:39 <[g2]> that's interesting Mar 08 04:16:51 <[g2]> no I've got the linksys not Unslung Mar 08 04:17:30 <[g2]> Linux version 2.4.22-xfs (root@sure_linux) (gcc version 3.2.1) #379 Wed Jul 7 15:59:25 CST 2004 Mar 08 04:17:30 <[g2]> CPU: XScale-IXP425/IXC1100 revision 1 Mar 08 04:17:30 <[g2]> Machine: Intel IXDP425 Development Platform Mar 08 04:17:30 <[g2]> Warning: bad configuration page, trying to continue Mar 08 04:17:30 <[g2]> Security risk: creating user accessible mapping for 0x60000000 at 0xff00f000 Mar 08 04:17:31 <[g2]> Security risk: creating user accessible mapping for 0x51000000 at 0xf1000000 Mar 08 04:17:34 <[g2]> On node 0 totalpages: 8192 Mar 08 04:17:35 It isn't really important. I just wondered. It's something that I've been considering to make the system boot faster. Mar 08 04:17:36 <[g2]> zone(0): 8192 pages. Mar 08 04:17:48 <[g2]> looks like it Mar 08 04:18:12 <[g2]> Calibrating delay loop... 131.48 BogoMIPS Mar 08 04:18:12 <[g2]> Memory: 32MB = 32MB total Mar 08 04:18:12 <[g2]> Memory: 20356KB available (1301K code, 242K data, 236K init) Mar 08 04:18:12 <[g2]> Dentry cache hash table entries: 4096 (order: 3, 32768 bytes) Mar 08 04:18:12 <[g2]> Inode cache hash table entries: 2048 (order: 2, 16384 bytes) Mar 08 04:18:13 <[g2]> Mount cache hash table entries: 512 (order: 0, 4096 bytes) Mar 08 04:18:15 <[g2]> Buffer cache hash table entries: 1024 (order: 0, 4096 bytes) Mar 08 04:18:32 how come there are no ehci interrupts ? Mar 08 04:18:50 <[g2]> because nothing is plugg in :) Mar 08 04:18:55 <[g2]> plugged Mar 08 04:18:56 ic Mar 08 04:19:26 <[g2]> do you note the ixp425_eth ints ? Mar 08 04:19:35 Did dyoung share his user manual for the NEC chip? Mar 08 04:19:47 <[g2]> I don't have it Mar 08 04:21:23 I had the impression that the ethernet driver was running in a polled mode. Mar 08 04:21:41 <[g2]> it was until a week or so ago Mar 08 04:21:44 OK. I'm still coming up donuts. Where is the kernel patch source. Mar 08 04:22:06 The sf searches aren't coming up with source, only an unslung 3.18 binary. Mar 08 04:22:46 <[g2]> http://cvs.sourceforge.net/viewcvs.py/nslu/ Mar 08 04:23:09 Wierd. The CVS link on sf doesn't show that. Mar 08 04:23:44 It shows 0 commits. Makes me think it is empty. Mar 08 04:23:54 <[g2]> I got there via the "Browse CVS ..." from this page http://sourceforge.net/cvs/?group_id=116564 Mar 08 05:48:09 nslu2-linux.thestuffguy.com/ds Mar 08 05:51:22 <[g2]> http://nslu2-linux.thestuffguy.com/ds Mar 08 05:57:35 Hmm? Mar 08 05:57:52 I heard dyoung and datasheet. So put there for your enjoyment. **** ENDING LOGGING AT Tue Mar 08 05:59:47 2005 **** BEGIN LOGGING AT Tue Mar 08 06:00:04 2005 **** ENDING LOGGING AT Tue Mar 08 06:03:44 2005 **** BEGIN LOGGING AT Tue Mar 08 06:04:03 2005 Mar 08 06:20:17 nice Mar 08 06:20:39 those should come in handy ... Mar 08 06:20:44 <[g2]> ipkg upgrading the kernel looks nice Mar 08 06:20:47 <[g2]> :) Mar 08 06:21:08 kernel went fine. The only problem was the ixp modules. Mar 08 06:21:41 <[g2]> that's what I was saying to kegoth the other day about the "inherit module" stuff Mar 08 06:21:45 if the ixp modules are simply recompiled, and the version number is not bumped for the new kernel, then the old 2.6.9 modules stay on your slug Mar 08 06:22:08 and without network, it's a bitch to get the 2.6.11 modules onto the slug ... Mar 08 06:22:30 <[g2]> Redboot or serial Mar 08 06:22:38 flash key Mar 08 06:22:55 another reason to have flash key support compiled in :-) Mar 08 06:23:20 <[g2]> so why don't the module numbers get bumped ? Mar 08 06:23:29 we need to get the kernel version into the ixp modules ${PV} somehow Mar 08 06:23:56 cause the ixp modules are built separately, and nothing changes in them. Mar 08 06:24:15 whereas all other module ipks are regenerated with new version numbers for the new kernel Mar 08 06:24:26 <[g2]> they have a dependency on the kernel though Mar 08 06:25:05 right, but that doesn't make them reinstall (cause the old kernel is still there, and that dependency would only serve to reinstall the old kernel) Mar 08 06:27:02 <[g2]> there should be some way on kernel bumps to trigger a bb -c clean foo .... Mar 08 06:27:25 <[g2]> that'd work-around the issue right ? Mar 08 06:31:54 it would still need to change the version number on the ixp module ipks. just a recompile is not enough, cause that doesn't trigger the slug to download the new version (cause the version number hasn't changed) Mar 08 06:32:17 Speaking of i xp drivers.... Mar 08 06:32:34 how much of a PITA will it be to add a version tag to the ones in the repo now? Mar 08 06:32:50 that is, ixpfoo_1.4 for instance. Mar 08 06:33:22 dyoung: what do you mean? the ipks have a version already Mar 08 06:33:27 They do? Mar 08 06:33:44 yeah, they get it from ${PV}. Mar 08 06:33:45 Working from memory. Checking. Mar 08 06:34:01 Aha okay Mar 08 06:34:05 <[g2]> rwhitby, I was saying that if the openslug-kernel is bump and you do a bb -c clean ixp425_eth ixp400 before or rm -rf the work dirs then it'll be fire right ? Mar 08 06:34:44 <[g2]> or I'm sure we could put something in the rootfs ipkg to check for kernel version match Mar 08 06:34:56 [g2]: no, cause the ixp modules will still be rebuilt with the same ipkg version number, and therefore will *not* be downloaded by an ipkg upgrade (which relies on the version number changing) Mar 08 06:35:06 <[g2]> not rootfs ipkg, but openslug-image Mar 08 06:35:20 the ipk version number has to change for it to be downloaded to the slug Mar 08 06:35:42 your suggestion will work for openslug-image, but not for ipkg upgrade from the feed Mar 08 06:36:04 Ok, so in openslug.conf, might it be a good idea to set PREFERRED_VERSION_ixp4xx ?= "1.4" and ixp425_eth ?= "1.1" ? Mar 08 06:36:07 <[g2]> ah... ok Mar 08 06:36:27 the right package would end up in the feed, but since the the version number hasn't changed, it won't get downloaded to the slug on an ipkg upgrade Mar 08 06:36:53 <[g2]> ok let's purge 2.6.9 :) Mar 08 06:37:14 we need the ixp .bb files to somehow get the kernel version number, or else we will have the same problem when we move to 2.6.12 ... Mar 08 06:37:14 <[g2]> There can only be ONE version to unite them all Mar 08 06:37:28 all feed packages are now built against 2.6.11 Mar 08 06:37:31 2.6.9 is gone Mar 08 06:37:45 and the repo builds 2.6.11 by default now Mar 08 06:37:59 <[g2]> I've been staring at kernel code for hours.... I'm just a little silly Mar 08 06:38:42 <[g2]> rwhitby, that's a really clever idea btw Mar 08 06:41:27 <[g2]> Hey the kernel configures the mini-cache does anything really use it ? Mar 08 06:45:03 dunno Mar 08 06:45:05 back later Mar 08 06:59:15 dyoung: Looking at the redboot code, it looks like I only have to make two calls to the ICP library to load the firmware. If there is more init necessary, well it could get sticky. Mar 08 07:00:25 IXNpeDl the npeLib ? Mar 08 07:00:51 Its making my head all whizzy looking at this stuff. Mar 08 07:02:10 dyoung: The redboot only make one call before calling the download function. It initializes the Q manager. Mar 08 07:02:30 Well, it also inits some sort of memory management, but I'm hoping to avoid that. Mar 08 07:02:56 Okay, cool. Hopefully its not painful. Mar 08 07:03:20 There are a whole mess of ifs and unknowns floating around. Mar 08 07:03:56 dyoung: btw, thx for the usb docs. Mar 08 07:04:35 np. I started reading them. That made my head spin too. Mar 08 09:26:25 [g2]-away: I think we need an update-kernel script Mar 08 09:26:53 <[g2]-away> rwhitby-web, instead of an ipkg ? Mar 08 09:28:12 <[g2]> rwhitby-web, with the jffs2 file and a running system, I think everything needed is in the rootfs Mar 08 09:29:02 <[g2]> the script should be pretty easy Mar 08 09:29:27 the script should be the manual step that someone runs after ipkg upgrade kernel Mar 08 09:29:51 <[g2]> except we are missing mtdram support Mar 08 09:29:53 (it would be a redboot only thing, cause apex would just pick up the new kernel on next boot out of jffs2, right?) Mar 08 09:30:21 you can write the kernel mtd partition with impunity, it is not accessed by the running kernel Mar 08 09:30:46 <[g2]> I'm talking about mounting the jffs2 image :) Mar 08 09:31:19 Here's something amusing. Mar 08 09:31:24 oh - are we discussing two different things here? Mar 08 09:31:37 I was discussing an update-kernel script - what are you discussing? Mar 08 09:32:03 <[g2]> update-kernel script pulling the kernel out of the jffs2 image that it's already in Mar 08 09:32:14 I posted the sf list about my work with getting the access library to build with linux 2.6. Mar 08 09:32:31 <[g2]> and .... Mar 08 09:33:02 I think that my effort is puny and probably not very interesting since I'm only trying to get the NPE to init. Mar 08 09:33:19 and as far as I know, the kernel driver for the ixp ethernet device still uses the 1.4 library. Mar 08 09:33:39 [g2]: ok, let's start again. You're running from either jffs2 rootfs or external rootfs. You run "ipkg upgrade kernel". It puts a new file in /boot (either in the jffs2 rootfs, or the external rootfs, whichever you are running). Mar 08 09:33:57 Well, ranslam told another user: Mar 08 09:33:58 Some, you should check http://www.nslu2-linux.org. There is a lot of Mar 08 09:33:59 Work there that is a MASSIVE and enthusiastic continuation of what Mar 08 09:33:59 Is done on ixp4xx-osdg.fs.net. Mar 08 09:34:32 for redboot, you then need to run update-kernel to transfer that zImage file into /dev/mtdblock1. Mar 08 09:34:47 <[g2]> beewoolie-away, url for the post ? Mar 08 09:35:26 for apex, if you are running from external rootfs, you just need to mount the jffs2 partition (mount -t jffs2 /dev/mtdblockX /media/foo) and copy the zImage file into /media/foo/boot. Mar 08 09:36:04 that's what I'm discussing :-) Where does missing mtdram support come into the picture? Mar 08 09:36:10 <[g2]> rwhitby-web, that's the point you can't just mount -t jffs2 unless the device is a real mtd device Mar 08 09:36:32 <[g2]> try mounting -t jffs2 on your PC Mar 08 09:36:39 yes - we're on the slug here, so it is a real mtd device Mar 08 09:36:51 you only run ipkg upgrade on the slug, not on a PC Mar 08 09:37:01 <[g2]> my point is that if your running on the jffs2 then you can't mount it Mar 08 09:37:28 if you're running on the jffs2, then you don't need to mount it, the new kernel has been installed into the correct place already. Mar 08 09:37:47 <[g2]> no, this is the next kernel and jffs2 Mar 08 09:37:52 (I'm assuming that apex will boot the kernel from /boot in the jffs2 partition, right?) Mar 08 09:38:03 <[g2]> not yet Mar 08 09:38:17 <[g2]> beewoolie-away, is just teaching it ext2 right now Mar 08 09:38:17 right, but when it does, that's what it will do, right? Mar 08 09:38:21 <[g2]> ya Mar 08 09:39:00 <[g2]> when APEX is done, I imagine it'll support multiple rootfs so there's always a free one Mar 08 09:39:23 <[g2]> but lets start with a single one that needs to be replaced Mar 08 09:39:38 so for the alternate jffs2, you can just mount that too (cause you and it are on a slug). I still don't see where mtdram comes into the picture ... Mar 08 09:39:48 doesn't matter how many you have, they are still jffs2 partitions on the slug, so you can mount them directly. Mar 08 09:39:56 <[g2]> rwhitby-web, you can't Mar 08 09:40:20 are they not /dev/mtdblockX partitions? Mar 08 09:40:21 <[g2]> by alternative you mean APEX with two full rootfs's Mar 08 09:40:38 <[g2]> and it's the other one ? mtdblock+1 Mar 08 09:40:44 yes Mar 08 09:40:51 <[g2]> ok, sure that works Mar 08 09:41:01 or even just the running partition. it still works Mar 08 09:41:16 <[g2]> ok lets stay there for a moment Mar 08 09:41:35 <[g2]> let's assume we have 1 7.75MB jffs2 partition Mar 08 09:41:50 <[g2]> 1 block APEX, 1 block APEX config, rest jffs2 Mar 08 09:41:54 in all cases, either ipkg upgrade has already put the kernel in the right place (/boot in the running jffs2 partition), or you can easily mount the jffs2 partition where it needs to be copied to. Mar 08 09:42:31 <[g2]> actually, for APEX this is a non issue Mar 08 09:42:50 <[g2]> because will be flashing the full parition and APEX will be pulling the kernel from /boot Mar 08 09:43:05 <[g2]> and all the kernel modules from the proper spot Mar 08 09:43:37 yes, you'll be flashing full parition on first install. won't you want to support ipkg upgrade after that? Mar 08 09:43:40 <[g2]> it can be an ipkg install Mar 08 09:44:37 <[g2]> well lets discuss each scenario redboot and apex Mar 08 09:44:45 this conversation is jumping all over the place, and really irritating me. can we stick to one line of thought? Mar 08 09:44:46 <[g2]> we can start with either one Mar 08 09:44:47 amen Mar 08 09:45:02 ok, first is redboot. Mar 08 09:45:15 <[g2]> ok Mar 08 09:45:34 <[g2]> redboot has switchbox Mar 08 09:45:39 initial install is flash the full image using normal linksys web interface, or redboot fis write (or upslug) Mar 08 09:45:54 <[g2]> ok Mar 08 09:45:57 after that, you use ipkg upgrade to keep up to date. Mar 08 09:46:26 ipkg upgrade writes a new kernel (zImage, no header) into /boot on your current rootfs (which may be jffs2, or external disk, or even NFS). Mar 08 09:46:53 then you need to run the new update-kernel script to add a header to that zImage, and flash it into /dev/mtdblock1. Mar 08 09:47:13 ipkg upgrade upgrade all the other kernel modules for you, and then you reboot and you're done. Mar 08 09:47:25 that's the end of the redboot case. agreed? Mar 08 09:48:08 <[g2]> I see it a little different Mar 08 09:48:28 <[g2]> I think the ipkg kernel upgrade should include the kernel and all the modules Mar 08 09:49:25 <[g2]> then, the .configured is erased and when we reboot, the dependencies and other stuff gets run like first boot Mar 08 09:49:34 <[g2]> except for the sysconfsetup possibly Mar 08 09:50:00 ok, in reality typing "ipkg upgrade" upgrades both the kernel and all the kernel modules at the same time, so we are saying the same thing. Mar 08 09:51:17 <[g2]> then you must reboot to finish the module dep generation and other scripts as necessary Mar 08 09:51:27 yes Mar 08 09:51:39 so we're set for redboot? Mar 08 09:52:32 (I'll assume yes) now, for the apex with single big jffs2 partition which includes kernel in /boot case .... Mar 08 09:53:06 in this case, ipkg upgrade already puts the kernel in the right place, and also upgrades all the modules Mar 08 09:53:15 <[g2]> yes Mar 08 09:53:30 so all we need to do is delete .configured, and reboot. Mar 08 09:53:35 <[g2]> except the details of removing the .configure and stuff is not fully enumerated Mar 08 09:53:53 right - some postinst script will need to do that Mar 08 09:53:57 <[g2]> it's something like that Mar 08 09:54:22 ok, so the next case is apex with a single jffs2 partition, but you're running rootfs from an external hard disk Mar 08 09:54:29 <[g2]> I've looked a little at the scripts, but I certainly don't know all the issues or have all the answers Mar 08 09:55:09 in this case, ipkg upgrade will put the new kernel and modules on the external hard disk, and you'll need to copy them over to the jffs2 (assuming that apex *always* gets the kernel from the jffs2 - I may be wrong in that assumption) Mar 08 09:55:58 when you tell apex to boot from external disk, does it get absolutely everything from that external disk, or does it still get some stuff from jffs2 (apart from the config block) ? Mar 08 09:56:13 <[g2]> my assumption is that APEX just pulls the kernel out of the rootfs and would pull any modules from there too Mar 08 09:56:29 Ahem, pull modules? Mar 08 09:56:29 which rootfs? the one in jffs2 or the one on external disk? Mar 08 09:56:45 <[g2]> the cmdline root= Mar 08 09:56:53 <[g2]> APEX don't care Mar 08 09:57:05 <[g2]> it just needs driver support Mar 08 09:57:21 <[g2]> which goes in order ext2, jffs2, usb Mar 08 09:57:26 The only way for the bootloader to do module tricks is with an initrd. Mar 08 09:57:27 ok, so the assumption then is that apex always gets the kernel from the same filesystem that it loads as the rootfs Mar 08 09:57:56 beewoolie-away: my contention is still that anything required to load rootfs from somewhere needs to be compiled into the kernel Mar 08 09:57:58 <[g2]> I think so Mar 08 09:58:00 That's fine. It isn't going to care. Mar 08 09:58:07 Right. Mar 08 09:58:16 rwhitby-web: right right . Mar 08 09:58:59 in the same way that for unslung, anything that switchbox needs to get to jffs2 or usb hard disk is compiled into the kernel Mar 08 09:59:42 beewoolie-away: will apex support loading kernel and rootfs from nfs ? Mar 08 09:59:57 Ah. well, nfs is an interesting issue. Mar 08 10:00:09 I'm trying to link the intel library as we speak. Mar 08 10:00:14 (at the moment, switchbox does support that, but it has to load the modules required from the jffs2) Mar 08 10:00:29 It is possible that we'll get full support eventually, but I wouldn't bet it will be easy. Mar 08 10:00:52 ok, and I guess with apex you can put nfs modules in the kernel cause it can be as big as you like Mar 08 10:00:59 I think we'd be better served with an initrd for nfs. Mar 08 10:01:07 ...compile nfs into the kernel... Mar 08 10:01:15 whichever. Mar 08 10:01:25 ok, cool. Mar 08 10:01:51 would that initrd live in the jffs2 rootfs somewhere, or would it require a separate mtd partition? Mar 08 10:02:07 If someone wants to use nfs for that, I think we can assume that flash will be available for the setup. Mar 08 10:02:14 It seems kinda redundant. Mar 08 10:02:32 Unless we're talking about some sort of failsafe recovery. Mar 08 10:03:15 beewoolie-away: sorry, didn't quite get what you meant there. Would that initrd live in the jffs2 rootfs somewhere, or would it require a separate mtd partition? Mar 08 10:03:18 rwhitby-web: I'm OK with adding FS drivers for jffs2 if that is necessary. We can put our files wherever it is most convenient. Mar 08 10:03:32 Better? Mar 08 10:03:40 yes, thanks :-) Mar 08 10:03:54 beewoolie-away: Would you have any objections if I borrow some of your ideas and patching to put together a ixp4xx 1.5 package to be used in OE? Mar 08 10:04:18 I'm going to hold short of promising network support until we can get APEX to boot the kernel *and* the network interfaces are active. Mar 08 10:04:31 Your Glue is nice. its way better than the ugly hack I did. Mar 08 10:04:38 dyoung-web: Go for it. My work so far is pretty ugly. Mar 08 10:05:01 I think that it might be worthwhile to figure out how to disable library features. Mar 08 10:05:17 beewoolie-away: cool. we're laying out the architecture in preparation, but not requiring any promises Mar 08 10:05:43 [g2]: so I think we're clear on the apex single jffs2 rootfs partition case, right? Mar 08 10:06:09 ipkg upgrade just upgrades whereever your rootfs currently is, and doesn't touch anything else. Mar 08 10:06:16 <[g2]> well we can reflash the full partition, and just re-install the packages Mar 08 10:06:33 <[g2]> that's for jffs2 Mar 08 10:06:35 you could, but then you loose all your customisations Mar 08 10:06:50 <[g2]> on the hd you can just install the files Mar 08 10:07:05 <[g2]> I'm trying to reconcile the difference between the two Mar 08 10:07:14 ok, slow down, we're getting disjoint again Mar 08 10:07:22 <[g2]> I guess you could just overwrite the files in the jffs2 Mar 08 10:07:22 beewoolie-away: Thanks! Mar 08 10:07:54 if you're running rootfs from the internal jffs2 partition, then ipkg upgrade overwrites those files in place, and you're done (delete .configured, etc, etc.) Mar 08 10:08:42 if you're running rootfs from an external disk, then ipkg upgrade overwrites the files on the external disk and doesn't touch the internal jffs2. again, you're done (cause apex will be booting from the external disk again, and will pick up the new kernel and modules) Mar 08 10:09:05 <[g2]> ok, so for APEX jffs2 or hd and redboot hd, it just overwrites the files in place runs the post inst and reboots Mar 08 10:09:18 if you're running rootfs from an external disk, and you want to upgrade the internal jffs2 rootfs instead, then that's an open question with a number of ways to do it. Mar 08 10:09:50 <[g2]> actually that's easy too Mar 08 10:09:50 no, for redboot hd you still need to also run update-kernel to write the kernel into /dev/mtdblock1 Mar 08 10:10:12 for all redboot cases you need to run update-kernel to write the header plus zImage into /dev/mtdblock1 Mar 08 10:10:22 <[g2]> actually the post inst could check for the kernel partition Mar 08 10:10:28 <[g2]> or the bootloader :) Mar 08 10:10:54 I don't think we want postinst scripts writing to kernel partitions. It should be a separate manual step. Mar 08 10:11:30 <[g2]> well /lib is already hosed Mar 08 10:11:48 no, /lib may well have both 2.6.9 and 2.6.11 directories under it ... Mar 08 10:12:08 <[g2]> then we're gonna have space constraints Mar 08 10:12:30 <[g2]> and the install is going to have to do some intelligent checking Mar 08 10:12:30 yes on the jffs2, no on a hard disk Mar 08 10:12:36 <[g2]> nod. Mar 08 10:13:00 <[g2]> what about the same kernel rev ? Mar 08 10:13:28 anyway, the assumption is that we *don't* have 2.6.9 and 2.6.11 directories at the same time (and that is also the default ipkg behaviour), so you are right that /lib is hosed if you are changing kernel version Mar 08 10:14:19 <[g2]> so we wipe /boot and /lib/2.6.x and install all the files Mar 08 10:14:23 I still think that the flash of kernel mtd partition should be manual, but I can be easily convinced otherwise (I'd personally like it to be automatic, but the first person I asked the other night - giel - didn't want it to be automatic) Mar 08 10:14:26 <[g2]> then replace the kernel Mar 08 10:14:51 yes, that's what "ipkg upgrade" followed by "update-kernel" does exactly. Mar 08 10:15:18 <[g2]> is all there there now ? Mar 08 10:15:22 ipkg upgrade by default removes all the 2.6.9 stuff before installing the 2.6.11 stuff Mar 08 10:15:45 update-kernel hasn't been written yet, but it is a simple shell script with tools that we already have in the image. Mar 08 10:15:54 <[g2]> so the only thing we are missing is the .configured Mar 08 10:16:03 I did it manually with existing tools last night Mar 08 10:16:18 right. Mar 08 10:17:31 <[g2]> Ok what a crazy idea Mar 08 10:17:33 if you're running rootfs from an external disk, and you want to upgrade the internal jffs2 rootfs instead, then we can either have a script to do that, or maybe we can do it with passing a dest to ipkg. anyway, I think that's a second-tier problem that we don't try to solve now. Mar 08 10:17:42 <[g2]> Ok want a crazy idea Mar 08 10:17:51 no :-) Mar 08 10:18:02 but I know you'll tell me anyway :-) Mar 08 10:18:14 <[g2]> I can keep a cool secret Mar 08 10:18:51 (and you're ideas usually aren't that crazy anyway...) Mar 08 10:19:09 <[g2]> sometimes they are! :) Mar 08 10:20:36 * [g2] wonders what it would be like if we stuck APEX in where the current kernel lives mtdblock2 Mar 08 10:20:48 Does that pretty much conclude that thread? Mar 08 10:20:56 so that's the redboot and apex single big jffs2 partitions cases both covered I think. Mar 08 10:21:00 * dyoung-web been patiently waiting his turn. Mar 08 10:21:18 the last case is [g2]'s idea of two full rootfs's - is that still a serious proposal? Mar 08 10:21:34 <[g2]> down the road Mar 08 10:21:43 * rwhitby-web thanks dyoung-web for being patient - others in the nslu2-linux channel could learn from his zen skills Mar 08 10:22:00 <[g2]> dyoung-web, what's up Mar 08 10:22:17 ~praise dyong-web Mar 08 10:22:19 [g2]: so we don't need to worry about that now - and I think it's just the same as the other apex cases anyway Mar 08 10:22:20 I can wait. I wanted to discuss ixp drivers a bit. Mar 08 10:22:24 ~praise dyoung-web Mar 08 10:22:31 * [g2] thanks beewoolie-away too Mar 08 10:22:32 * beewoolie-away frowns Mar 08 10:22:37 All hail dyoung-web! Mar 08 10:22:45 * beewoolie-away grins Mar 08 10:22:47 (no jbot here Mar 08 10:23:15 dyoung-web: I think we're done on the ipkg upgrade and update-kernel script discussion Mar 08 10:23:22 <[g2]> nod. Mar 08 10:23:23 Okay cool. Mar 08 10:23:26 <[g2]> ixp 1.5 Mar 08 10:23:28 <[g2]> ? Mar 08 10:23:55 * rwhitby-web goes off to get some food, and will read the ixp discussion with interest after lunch .... Mar 08 10:23:59 1/ If noone has any objections, I'm going to add the lines in openslug.conf to prefer ixp4xx-csr version 1.4 and ixp425_eth version 1.1 Mar 08 10:24:11 yep Mar 08 10:24:30 <[g2]> those are the current versions Mar 08 10:24:34 nice move. get it in first :-) Mar 08 10:24:38 2/ our current 1.4 patchset patches the driver name from ixp to eth / Mar 08 10:24:53 Do we want to preserve that patch? Mar 08 10:25:20 I think so, it saves us having to patch all sorts of other OE base files and init scripts stuff Mar 08 10:25:24 <[g2]> doesn't matter Mar 08 10:25:38 <[g2]> no that's handled by the alias Mar 08 10:25:39 [g2]: I know those are the current version, I dont want it to break for everyone else when I push a broken ixp4xx-csr_1.5 ;-) Mar 08 10:26:09 [g2]: the modprobe is handled by the alias, but anything that uses ifconfig would not be handled by the alias Mar 08 10:26:21 IMHO, it would be better to leave the name as is and use an alias. Mar 08 10:26:42 I thought that we could tell the kernel to use an alias, too. Mar 08 10:26:46 <[g2]> rwhitby-web, it's the other way around Mar 08 10:27:18 as long as I can say "ifconfig eth0 foo" and have it work on the ixp driver, then it's fine. Mar 08 10:27:20 <[g2]> ifup brings up eth0 by the /etc/network/interfaces file Mar 08 10:27:43 # ip link set ixp0 name eth0 Mar 08 10:27:52 <[g2]> the alias says for eth0 substitute ixp425_eth Mar 08 10:27:53 right - but I suspect there are other places where eth0 is referenced directly Mar 08 10:27:56 The kernel is no wiser. Mar 08 10:28:12 beewoolie-away: ok, cool - I wasn't aware of that aliasing Mar 08 10:28:26 I was only aware of the modprobe aliasing Mar 08 10:28:29 It's what took the place of the wonky eth:# stuff in 2.4 Mar 08 10:28:39 Or perhaps earlier. Mar 08 10:29:23 ok, so I agree with beewoolie-away that we should keep the name as is and use an alias Mar 08 10:29:24 <[g2]> dyoung-web, you call you can keep eth0 in or try ixp Mar 08 10:29:38 <[g2]> ok that's fine by me Mar 08 10:30:06 dyoung-web: is there a 3/ ? Mar 08 10:30:40 Hmm. The call isn't working for me. I may be wrong about it working. Mar 08 10:30:41 * rwhitby-web is interested, but still hungry Mar 08 10:30:47 manga! Mar 08 10:31:26 if the interface name alias doesn't work, then we should patch the driver to use ethX Mar 08 10:31:46 (path of least resistance) Mar 08 10:31:50 Oh wait. it's even funnier! I change my ethernet interface from eth0 to foo. Mar 08 10:32:13 <[g2]> modprobe kung_foo Mar 08 10:32:21 We just need to see if the command works for changing ixp0 to eth0. Mar 08 10:32:27 * beewoolie-away rofl Mar 08 10:33:04 <[g2]> Ahhh.... net_foo versus kung_foo ..... battle at 11:00 Mar 08 10:33:07 It looks like it works as long as the interface is not running. I cannot change the name of the active ethernet link, but other links can be changed. Mar 08 10:33:31 We can put it in the rc.boot (like) script. Mar 08 10:34:35 <[g2]> dyoung-web, is there #3 ? Mar 08 10:35:04 I have two things to say A, and 2. Mar 08 10:43:46 Here's a depressing factoid. Mar 08 10:43:59 The size of apex with the NPE library linked in... Mar 08 10:44:07 -rwxrwxr-x 1 elf elf 221464 2005-03-08 18:42 apex.bin* Mar 08 10:44:36 without... Mar 08 10:44:42 -rwxrwxr-x 1 elf elf 25112 2005-03-08 18:44 apex.bin Mar 08 10:45:29 I can feel the enthusiasm droop. Mar 08 10:45:35 <[g2]> personally, I see no need for CSR/NPE support in APEX Mar 08 10:45:43 Well, that all depends. Mar 08 10:45:51 <[g2]> we can easily support two full rootfs's Mar 08 10:45:56 My doesn't the ixp interface come up? Mar 08 10:46:05 <[g2]> Why ? Mar 08 10:46:24 I've been under the impression that it was because of some init performed in the bootloader. Mar 08 10:46:36 That may not be true, but this was one way to find out. Mar 08 10:47:15 <[g2]> dunno Mar 08 10:47:21 <[g2]> dyoung is the MAN Mar 08 10:47:37 <[g2]> he's poking around with the 1.5 Mar 08 10:47:47 That's what I just got to link. Mar 08 10:48:14 <[g2]> I don't know if anyone has had that working Mar 08 10:48:19 <[g2]> jacques, was playing with it too Mar 08 10:48:30 It took some finagling to get it to build. Mar 08 10:49:05 I put the patches and other doodads on my wiki. Mar 08 10:50:34 [g2]: not having ixp-eth support in apex would limit it's audience to those with serial or a usb-serial or usb-net adapter, wouldn't it? you wouldn't be able to use apex with just stock hardware and nothing else ... Mar 08 10:50:57 <[g2]> sure Mar 08 10:51:02 rwhitby-web: Did you eat yet? Mar 08 10:51:18 nope. did some work while waiting for dyoung's #3 or not. Mar 08 10:51:24 <[g2]> with two full rootfs ? and the reset button/power button to toggle between the boots ? Mar 08 10:51:34 rwhitby-web: It ought to be the case that the lack of ixp NPE support in the bootloader is irrelevent. Mar 08 10:51:59 The only thing that it means is that there won't be a telnet console. Mar 08 10:52:05 beewoolie-away: a key feature of redboot that we use today is the ability to telnet into it to interrupt the boot process. Mar 08 10:52:22 We're going to provide a button/LED UI for handling failsafe. Mar 08 10:52:35 that's the "software only, no change to stock hardware, no additional peripherals required" recovery solution today. Mar 08 10:53:09 I get what you mean. I don't like the fact that the ethernet interface is so difficult to support. Mar 08 10:53:23 <[g2]> I don't get what he means Mar 08 10:53:24 I also believe that it isn't really necessary for most people. Mar 08 10:53:45 understood and agree. I'm looking at it from a camp#2 moving into camp#3 user's point of view. Mar 08 10:54:00 (agree about the difficult to support that is) Mar 08 10:54:07 I believe we'll be able to provide the same level of safety if we handle the network with a failsafe rootfs in flash. Mar 08 10:54:39 ok, so the question then becomes whether the space required for the failsafe rootfs is bigger or smaller than the space required for ixp support in apex .... Mar 08 10:54:52 One thing I discovered is that the linux portion of the library might be part of the problem. Mar 08 10:55:06 (looking at it from the point of view of someone who wants a internal-jffs2 only system) Mar 08 10:55:13 It might be worthwhile to write an adapter of the core library that doesn't require all of the linux pieces. Mar 08 10:55:35 Sort of. There is also the question of how much work it is. Mar 08 10:55:49 right. but that's a once-off cost :-) :-) Mar 08 10:56:00 If it takes three weeks of work, then there is little chance I'll be able to do that in the next, oh, year or so. Mar 08 10:56:26 Remember, this is just the ethernet interface. We'll also need the tcp/ip stack. Mar 08 10:56:34 Or a facsimile thereof. Mar 08 10:57:17 all I am saying is that there is a user segment who wants to use the slug as a stand-alone internal jffs2 rootfs box, and will want recovery somehow (either by telnetting in, or by pushing buttons). We just need to consider the tradeoffs before ruling out one or the other. Mar 08 10:57:25 I'm not saying that I don't want it. I am saying that it might be a steep climb for, IMHO what is a nominal advantage. Mar 08 10:57:42 For those people, they may need to stick to RedBoot. Mar 08 10:58:04 fully agree. the difficulty has to be part of the trade-off equation, and yes we still have redboot. Mar 08 10:58:20 will apex with ixp and tcp/ip be bigger or smaller than current redboot? Mar 08 10:58:23 I think that it might be a reasonable exchange to say that network support, or something like it, requires a little extra hardware *if* they want all of the fancy features we add to APEX. Mar 08 10:58:30 Don't know. Mar 08 10:58:36 Cannot say. Mar 08 10:58:51 The linked version I've got right now is already larger, but I don't know why it is so big. Mar 08 10:59:04 I am using 1.5 of the library. Mar 08 10:59:16 And I am using the linux adapter for the library. Mar 08 10:59:37 Way to may ifs and harumphs in there to say anything for sure. Mar 08 10:59:41 I don't even know if it works. Mar 08 11:00:18 if apex with ixp and tcp/ip is the same number of 128K erase blocks as current redboot, then I fully agree that we should tell people to buy a little extra hardware for recovery if they want to use apex Mar 08 11:01:13 if apex with ixp and tcp/ip comes in smaller (in 128K erase blocks) than current redboot, then the option of a ixp-network-aware apex becomes interesting Mar 08 11:01:20 Even if it is small, I think it is reasonable to say that there are some features of RedBoot that are not available in APEX. Mar 08 11:01:36 in our redboot, or redboot in general? Mar 08 11:01:48 Frankly, I don't want to support this behavior on the part of Intel and other vendors. Mar 08 11:02:06 <[g2]> Right Mar 08 11:02:18 ok, I can fully understand an ideological decision, and won't argue with that at all. Mar 08 11:02:31 <[g2]> that's the icing Mar 08 11:02:34 getting the network driver to work in this puny little bootloader is kinda overboard. Mar 08 11:03:01 <[g2]> truth is a second rootfs and reset is equally recoverable as telnet to a different network address Mar 08 11:03:14 If their code were well behaved, I might be more inclined. It just isn't pretty and I don't know what it will take to get it working. Mar 08 11:03:29 agreed. all I am saying is that if widespread take-up of apex on the slug is one of your goals (which it may or may not be), then ixp and tcp/ip would be required to get the widest reach into the userbase. Mar 08 11:03:50 <[g2]> that it totally conjecture Mar 08 11:03:59 I agree, though. Mar 08 11:04:12 [g2]: agreed that second rootfs is equivalent, but it takes us valuable jffs2 space for internal jffs2-only boxes. Mar 08 11:04:23 It would be best if I could get everything working. Mar 08 11:04:49 beewoolie-away: and I'm not trying to push apex toward widesread adoption - that's your baby, not mine. Mar 08 11:04:49 At this point, I think we know where the low-hanging fruit lies. Mar 08 11:05:03 rwhitby-away: Understood. Mar 08 11:05:16 I don't have an agenda either way. Mar 08 11:05:21 you guys will make the decisions - I'm just raising the viewpoints that you might not be considering .... Mar 08 11:05:29 what I do want is a better way to get a slug bootstrapped. Mar 08 11:06:09 It may be that all I need to do is go back to 1.4 to get a reasonably small loader with NPE support. Mar 08 11:06:21 dyoung: you hear that? Mar 08 11:06:23 For my personal agenda, I have serial ports on both my slugs, and have never telnetted into redboot in my life. I do, however, load images into redboot over the network using the ixp port. Mar 08 11:07:42 sorry, I got distracted. Mar 08 11:07:46 so for testing new images, being able to load a new image over the network using the on-board ethernet port is a key decision point about what boot-loader I use. cause all my other usb ports (including those on the connected hubs) are used already, and I don't want to be plugging and unplugging things just to test new images. Mar 08 11:08:06 <[g2]> dyoung-web, I thought we pissed you off :) Mar 08 11:08:08 I'll need to finish that conversation later. Mar 08 11:08:14 <[g2]> by talking too much Mar 08 11:08:14 maybe 15 min. Mar 08 11:08:53 having to climb up where the slugs are and switch things about is more hassle (for me personally) than having to type arcane redboot commands .... Mar 08 11:09:42 it would be disappointing if we couldn't use the same ethernet port that we use in normal functional mode, to load new images into the boot loader. Mar 08 11:10:02 but I'm not the one writing the code, so it's not my decision. Mar 08 11:10:03 rwhitby-web: But we should be able to do the upgrades from a running system. Mar 08 11:10:46 yeah, that's fine for the normal user. but you and I do stuff every day that the "normal upgrade procedure" doesn't cut it for :-) Mar 08 11:10:47 Believe me, I see your point. You already have a serial line running to your slug. Would a USB interface be so bad? Mar 08 11:11:14 All my USB ports (including the 4 port hub connected) are full. Mar 08 11:11:30 USB can be multiplexed using a hub. serial cannot. Mar 08 11:11:43 yes, ethernet is too, so there is incentive there. Mar 08 11:12:35 needing a usb-etherner adapter for the boot loader would also take up a spare slot on my router which I don't have either :-) Mar 08 11:13:13 and another IP address ... (not that that matters, but it's one more you have to remember when typing in commands) Mar 08 11:13:21 So, do you have a serial line to each of your slugs? Mar 08 11:13:26 yes Mar 08 11:13:34 but most people don't. Mar 08 11:13:44 One case at a time. Mar 08 11:14:21 So, for you, a recovery rootfs with the network tools would work OK. it would take up flash space, but it would work. Mar 08 11:14:39 No need to get to the device buttons. Mar 08 11:14:52 actually, no, cause I hope to run AccessSlug completely from internal jffs2 (as I do today) Mar 08 11:15:09 How does that change things? Mar 08 11:15:25 a recovery rootfs takes up valuable flash space Mar 08 11:17:05 I got that part. Aside from the flash space, though, it would work. Mar 08 11:17:23 If I can get to the bootloader from my laptop (which I do today via a usb-serial cable connected from my wireless router to the slug), and load an image from a http or tftp server which is already on the same network as the ixp port is connected, then I can use the full flash for normal functionality, and still recover without having to have physical access to the slug (as long as I also have the power-on hack, which I do) Mar 08 11:17:45 yes, apart from the flash space, a recovey rootfs is equivalent (if not better) than a recovery shell Mar 08 11:18:15 Okay I'll leave the eth naming patch alone for now; and leave it as ixp until things break. Its a one line patch anyways. Mar 08 11:18:34 (catching up the log, sorry) Mar 08 11:18:35 My suspicion is that for the average user, we'll be serving them better with a USB console Mar 08 11:18:40 dyoung-web: sounds good - it will at least show us where the broken things are :-) Mar 08 11:19:03 They can manage several slugs with a single USB connection and no hardware modes. Mar 08 11:19:07 s/modes/mods/ Mar 08 11:19:18 what's on the other end of the USB cable? Mar 08 11:20:08 [what I really want at the moment, is something which makes the slug USB port look like a local USB port on my windows laptop :-)] Mar 08 11:20:21 (but that's for a completely different application) Mar 08 11:20:38 [with the data going over the network from the laptop to the slug] Mar 08 11:20:46 the idea is that with a USB hub, the should be able to control several slugs. Mar 08 11:20:47 rwhitby-web, funny you should mention that. Mar 08 11:20:57 I was just poking around for that protocol. Mar 08 11:21:14 I think that's the gadget stuff. Mar 08 11:21:22 beewoolie-away: the should be able to control several slugs? Mar 08 11:21:25 USB gadget or some such thing. Mar 08 11:21:33 The user's laptop. Mar 08 11:21:36 Or whatever. Mar 08 11:21:50 over the network, or from a physical usb connection? Mar 08 11:22:09 Instead of running a serial cable to each, and having to switch wires, a single USB connection at the latop should be able to connect to the slugs. Mar 08 11:22:20 Serial console. Mar 08 11:22:24 USB console. Mar 08 11:22:37 (over the network is what I require - I almost never have a physical connection between the laptop and the slugs) Mar 08 11:22:44 Geez, I've totally forgotten what I was thinking about re: ixp driver already. Mar 08 11:22:51 You said that you have a serial port on each slug now. Mar 08 11:23:24 yes - two usb-serial cables. one with the usb end on the wireless router, the other with the usb end on the other slug. Mar 08 11:24:05 You're already doing what a simple USB console would do, no? Mar 08 11:24:06 I control redboot on AccessSlug from the wireless router command line (an Asus WL-500g) via ssh and microcom running on the wireless router. Mar 08 11:24:08 well, it cant have been that important. I'll fuss about it later if I remember. Mar 08 11:24:29 dyoung-web: I thought you were going to change the default ixp driver versions. Mar 08 11:24:30 I control redboot on DevSlug from AccessSlug via ssh and microcom running on AccessSlug. Mar 08 11:24:32 <[g2]> dyoung-web what's up with 1.5 ? Mar 08 11:24:47 no physical connection between laptop and either slug - all done wirelessly. Mar 08 11:25:03 <[g2]> from a treo Mar 08 11:25:13 yes - from the other side of the world. Mar 08 11:25:15 I don't know all of those components. Just because you use a wireless USB doesn't change the fact that it is USB. Mar 08 11:25:18 anyone could do that. Mar 08 11:25:28 no, I don't use wireless usb. Mar 08 11:25:38 my wireless router has a linux command line, and a usb port. Mar 08 11:25:44 What is a wireless router? Mar 08 11:25:53 Asus WL-500g Mar 08 11:26:01 I'm gonna change the default to the current veresion of 1.4/1.1 in oe before a 1.5 push. Mar 08 11:26:22 You said two USB serial cables before connectect to a wireless router. Mar 08 11:27:00 one connected to wireless router's usb port. other connected to the other slug's usb port. Mar 08 11:27:10 All I'm saying is that you're using a serial to usb adapter and getting access to the slug with that. We can replace the serial with USB only. Mar 08 11:27:35 USB to USB. Mar 08 11:28:23 I have a usb->serial cable. the serial end is plugged into the slug's serial port. the usb end is plugged into the wireless router which sits next to the slug. Mar 08 11:28:43 so I don't use a usb port on the slug for bootloader stuff. I use the serial port on the slug for bootloader stuff Mar 08 11:28:46 Uh huh. Mar 08 11:29:06 You had to modify your slug to do that. Mar 08 11:29:12 Most users won't want to do that. Mar 08 11:29:12 yes. Mar 08 11:29:16 agreed. Mar 08 11:29:22 They will be better served with a USB console. Mar 08 11:29:42 that's why I'm asking what's on the other end of a cable for this "usb console"? Mar 08 11:29:56 The same thing you are using. Mar 08 11:30:04 one end of the usb cable is plugged into the slug. what is the other end plugged into? Mar 08 11:30:21 How about a wireless router? Mar 08 11:30:33 and what do you run on the thing it is plugged into, to talk to the slug? Mar 08 11:30:41 wireless router is good :-) Mar 08 11:31:06 It doesn't matter. You're already doing the same thing. Mar 08 11:31:28 oh - do you mean that I can run microcom on the wireless router, and talk to apex via a usb cable to the slug (without needing a usb-serial adapter) ? Mar 08 11:31:58 does apex act like a pl2303 or something? Mar 08 11:32:15 (from the point of view of the program running on the wireless router) Mar 08 11:32:16 I don't know much about this router. I'm thinking that most people will have a server that connects to the slug console. A server or a laptop, in my case. Mar 08 11:32:32 same thing. what runs on the server ? Mar 08 11:32:56 That's the feature I want to add. It should be possible to use a USB device as a console with APEX. Mar 08 11:32:59 what is the command-line program which runs on linux on the box which is connected to the other end of the usb cable, which gives me access to the apex command line? Mar 08 11:33:24 It ought to look like a serial device. /dev/ttyUSB0. We'd then be able to run minicom. Mar 08 11:33:49 ok, excellent. Sorry that I was not able to make my question clear. That solution would be perfect for most users. Mar 08 11:34:20 There are loads of details that I'm glossing over, but I believe this is feasible if not easy. Mar 08 11:34:37 There are already people using embedded systems to emulate network devices (over USB). Mar 08 11:34:44 cool - that is a *really* good solution! Mar 08 11:34:51 I glad you think so. Mar 08 11:35:09 beewoolie-away is the MAN. ;-) Mar 08 11:35:10 OK. Now, I want to make it clear that I think you are correct about the network Mar 08 11:35:27 I agree that it would be ideal to be able to access ethernet from APEX. Mar 08 11:35:42 it also means that people using usb-serial cables use exactly the same program and commands as people using the usb console solution Mar 08 11:35:45 I'm going to put some thinking to this to see if there is a way to do so feasibly. Mar 08 11:35:54 I would hope so. Mar 08 11:36:11 It should be a complete replacement for the serial console. Mar 08 11:36:24 Even the kernel could use it. Mar 08 11:36:30 yep - a killer feature for apex. Mar 08 11:36:32 beewoolie-away: Would it be possible to just load the microcode from the npelib download? Mar 08 11:36:41 its the ugly C file. Mar 08 11:36:48 ok, now I really gotta go eat :-) Mar 08 11:36:50 or do we really need ixnpedl ? Mar 08 11:36:51 dyoung: Well, the code is kinda complex. I don't understand it well enough to do that. Mar 08 11:37:00 Moreover, I don't know why it should be necessary. Mar 08 11:37:14 rwhitby-lunch: thanks for the convo. Mar 08 11:37:42 beewoolie-away: thank you too - sorry I wasn't clear in my descriptions Mar 08 11:37:43 dyoung-web: I'm told you're the man with the ixp stuff. Mar 08 11:37:57 who said that? Mar 08 11:38:03 rwhitby-lunch: That's the whole idea. You make sure that I'm being clear. Mar 08 11:38:22 dyoung-web: a little bird told me. Mar 08 11:38:30 or was it a butterfly. Mar 08 11:38:51 <[g2]> OK usb-host-to-host adapters cost $19 here and setup full IP networks Mar 08 11:38:55 anyway, what I don't yet know is why the IXP interface fails to start when we boot from APEX. Mar 08 11:39:03 beewoolie-away: should I go back through all of the test steps again just to be sure I'm not hallucinating? Mar 08 11:39:06 <[g2]> AND it runs on my slug to my PC Mar 08 11:39:19 [g2]: What is the interface at the PC? Mar 08 11:39:22 It is a network adapter? Mar 08 11:39:41 <[g2]> no it's a usb- host-to-host adapter Mar 08 11:39:44 dyoung-web: What do you mean? Mar 08 11:39:49 <[g2]> stright out of the kernel config Mar 08 11:39:54 <[g2]> straight Mar 08 11:40:09 So, what device does it implement in the kernel? Mar 08 11:40:15 <[g2]> eth2 Mar 08 11:40:32 OK. Then it's emulating ethernet. Mar 08 11:40:35 Not ideal. Mar 08 11:41:06 <[g2]> I belive you are confused about about your usb connections Mar 08 11:41:08 I suppose we could make do, though, if we supported telnet in APEX. Not idea, though. Mar 08 11:41:18 <[g2]> you can't plug to slaves together Mar 08 11:41:22 Really. USB is a packet protocol. Mar 08 11:41:56 <[g2]> or in this case to hosts Mar 08 11:42:10 My understanding is that there are semantic differences, but the host controllers can do both modes. Mar 08 11:42:25 <[g2]> OTG can Mar 08 11:42:35 ? OTG Mar 08 11:42:37 <[g2]> dunno about our NEC chip Mar 08 11:42:41 <[g2]> On-the-Go Mar 08 11:42:44 OTG? Mar 08 11:43:05 <[g2]> is the latest after high-speed Mar 08 11:43:23 Hmm. USB OTG. Mar 08 11:43:26 <[g2]> plug it in to the camera it acts like a host Mar 08 11:43:40 <[g2]> plug it into the pc acts like a slave Mar 08 11:43:46 otg can switch between host and device Mar 08 11:43:58 <[g2]> it's not master-slave challenged Mar 08 11:45:21 IIRC, the Sharp host controller can handle both, but it might have different outputs for the two modes. I didn't think it could auto detect, but I did think it could handle either end of the conversation. Mar 08 11:45:42 That would throw a wrench in the works. Mar 08 11:45:55 <[g2]> dyoung-web, FYI http://www.tweakers.net/reviews/557/1 Mar 08 11:46:53 I saw that article, but didn't read it. Most of those controllers a bogus. At least, they used to be. Mar 08 11:47:06 They used to all be software raid controllers. Mar 08 11:47:29 <[g2]> I skipped to the conclusion Mar 08 11:47:39 <[g2]> on of the board uses the Intel IOP Mar 08 11:47:47 <[g2]> which I was looking at the other day Mar 08 11:48:03 <[g2]> but *hugs* to all you a**-kickers out there! Mar 08 11:48:20 If there is a microcontroller on board, then maybe it's worth a look. Those tended to be pricey. Mar 08 11:48:26 <[g2]> thanks for all your help and enlightening me to many issues I missed Mar 08 11:48:38 rwhitby: Did you even taste it? Mar 08 11:48:54 Canteen had shut :-( Mar 08 11:49:01 <[g2]> DOH! Mar 08 11:49:24 np - I eat too much usually anyway :-) Mar 08 11:49:46 <[g2]> rwhitby, shows his love by giving up food for his pals Mar 08 11:49:58 <[g2]> ROFLMAO Mar 08 11:50:17 dyoung-web: BTW, I updated my ixp patch and makefile. Mar 08 11:50:36 <[g2]> is that in the latest APEX or else where Mar 08 11:50:36 the big advantage I see to having the bootloader use the ixp ethernet port for all communications, is that it doesn't require any other hardware or ports over and above the minimum that you have connected for normal operation anyway. Mar 08 11:51:25 <[g2]> IMHO the NRE isn't worth it Mar 08 11:51:55 yes, it's a non-free driver. yes, it's difficult to do. yes, you can do it other ways by connecting other bits of hardware. But using the ixp port is the path of least resistance for all the users. Mar 08 11:52:14 I agree that the NRE might be the killer. That doesn't change what the ideal is :-) Mar 08 11:52:25 ~nre Mar 08 11:52:36 once-off development effort Mar 08 11:52:37 <[g2]> Non-Recurring-Engineering Mar 08 11:52:42 NPE. I think he means NPE. Mar 08 11:53:02 rwhitby: I don't think anyone disagrees with the idea. Mar 08 11:53:05 ~rwhitby-bot-snack Mar 08 11:53:10 the NRE required to make the NPE work :-) Mar 08 11:53:18 dyoung-web: Aw gee :-) Mar 08 11:53:24 MRE? Mar 08 11:53:37 Okay if someone says MR8 I'm gonna have a fit. Mar 08 11:53:49 RX7 ? Mar 08 11:54:03 <[g2]> I used to have the turbo Mar 08 11:54:03 I one the sandbox... Mar 08 11:54:11 The MR8 is a survival ration. It looks and taste like particle board. Mar 08 11:54:31 Powerbar for the armed forces. Mar 08 11:54:49 They dont go bad. Ever. Mar 08 11:54:56 * dyoung-web shudderse Mar 08 11:55:04 * rwhitby could use an MR8 now .... Mar 08 11:55:15 <[g2]> nite all Mar 08 11:55:21 Remember that this all may be moot if we cannot get the IXP interface running without the library. In other words, we may have to get it running just to boot the sucker. Mar 08 11:55:24 [g2]: nite Mar 08 11:55:24 sorry for making you miss lunch rwhitby. Mar 08 11:55:26 night [g2] - thansk for the discussions Mar 08 11:55:36 night [g2] Mar 08 11:55:39 <[g2]> thx for all the discussions Mar 08 11:55:40 dyoung-web: no-one makes me do anything - it's my choice Mar 08 11:55:59 True. Mar 08 11:56:00 <[g2]> dyoung-web, the logger see to be missing traffic Mar 08 11:56:04 But still. Mar 08 11:56:27 dyoung-web: thanks for the thought, anyway :-) Mar 08 11:56:28 yeah, nslu2-logger is a little sluggish today. Mar 08 11:57:23 <[g2]-away> beewoolie-away, Oh one last thing Mar 08 11:57:45 <[g2]-away> The ehci-hcd irq handler Mar 08 11:57:46 hmm. Mar 08 11:57:49 Yeah. Mar 08 11:58:10 I was thinking that we should tap, eh, dave about it. Mar 08 11:58:21 He might see something in the dump that we don.t Mar 08 11:58:33 <[g2]-away> I'm wondering if there's a race between when the irq status is read and updated and the watchdog timer could be biting in between Mar 08 11:58:49 I don't think so. I looked at that part of the code. Mar 08 11:59:04 dyoung-web: "rwhitby-web, funny you should mention that." (re usb replication over network) - did you find anything? Mar 08 11:59:30 I think I remember something about it on the mailing list a long time ago .... Mar 08 11:59:44 <[g2]-away> beewoolie-away, I'd like to talk to you about that tomorrow sometime Mar 08 11:59:48 <[g2]-away> thx Mar 08 11:59:48 k. Mar 08 11:59:53 niteynite Mar 08 12:00:02 dyoung-web: it was some research thing somewhere .... Mar 08 12:00:06 <[g2]-away> sweet dreams all Mar 08 12:00:30 night [g2]-away Mar 08 12:00:46 I think jacques mentioned it the last time. Was recently trying to find that link. Mar 08 12:01:36 dyoung-web: Does the IXP need PCI? Mar 08 12:01:47 I mean the NPE. does it need PCI? Mar 08 12:05:26 Not sure. Mar 08 12:08:45 Yes it does. Mar 08 12:09:01 the usb chip is the only thing on PCI, isn't it? you could check looking at /proc/pci ... Mar 08 12:09:18 (according to some stuff in the npe epk at least) Mar 08 12:10:23 In the same cdl file it some stuff to make "libextras" which is the only part I think you need to load the microcode. Mar 08 12:11:04 I gotta go forage, back later. Mar 08 12:14:40 damn - I just found the link Mar 08 12:14:41 http://usbip.naist.jp/ Mar 08 12:14:51 he'll see it in the logs Mar 08 12:15:02 DYOUNG DYOUNG DYOUNG Mar 08 12:15:11 LOOK HERE LOOK HERE LOOK HERE Mar 08 12:15:24 there. that'll do it Mar 08 12:20:28 dyoung: well it would be handy to know if the USB worked, then. Mar 08 12:24:12 this is cool: http://www.thinkgeek.com/gadgets/tools/69d3/ Mar 08 12:24:18 I need one of those .... Mar 08 12:25:12 Is it small enough for SMD? Mar 08 12:26:32 dunno Mar 08 12:28:40 :-( "We do not recommend it for soldering of large metallic components that require a lot of heat transfer or for soldering sensitive electronic components that may be damaged by fast-rising temperatures or high electrical current. (Momentary high-amperage current will be created during active soldering.)" Mar 08 12:28:56 Ooo. Mar 08 12:29:02 perhaps I don't want one after all ... Mar 08 12:29:37 I think what we need to do to diagnose the network driver failing to work in Linux is to debug the driver itself. That way, we can see what it stopping it from initializing. Mar 08 12:30:09 I also think that the best bet for getting a working ethernet interface in APEX will be to use the 1.4 library. Mar 08 12:42:54 Later rwhitby. Mar 08 16:50:23 and waiting for jbot to join ;) Mar 08 18:05:42 It builds. Mar 08 18:10:53 Unfortunately, when it gets to making the module, it grumbles about having some undefined bits. Mar 08 18:11:20 in_irq, BIT, exit_files, clean_dcache_range, invalidate_dcache_range Mar 08 18:11:38 so I end up with a 1282 byte kernel module. Mar 08 18:16:39 dyoung, what's that? Mar 08 18:17:05 oh the USB over IP thing? Mar 08 18:18:40 No, this is CSR-1.5 Mar 08 18:18:47 Any idea where those calls come from? Mar 08 18:19:18 I have a proper sized ixp400.o; it just freaks out about those items when it tries to make a kernel module. Mar 08 18:20:58 maybe something not quite right in the 2.6 patch ? Mar 08 18:21:15 CSR 1.5 still doesn't support 2.6 out of the box does it ? Mar 08 18:21:16 Could be, I should review the old one. Mar 08 18:21:28 No it doesnt. I had to do some *really* ugly things. Mar 08 18:21:45 Thankfully beewoolie had a solution to the ugliest part. Mar 08 18:22:01 cool, he's quite a useful guy to have around :-) Mar 08 18:22:18 Yeah, hes the man. Mar 08 18:22:40 Oh well, I was hoping to have csr 1.5 working tonight; but I dont think thats gonna happen. Mar 08 18:22:56 hmm there are several messages on the list titled "Linux 2.6 and the 1.5 access library" Mar 08 18:23:03 http://sourceforge.net/mailarchive/forum.php?forum_id=36304 Mar 08 18:23:10 Which list ... thanks! Mar 08 18:23:13 I havent readt them yet - may be totally unrelated Mar 08 18:23:37 Bewoolie was talking about that earlier today. Apparently we're famous. Mar 08 18:24:12 Gelloglue referened us by name at some point. Mar 08 18:24:44 lol Mar 08 18:24:46 last message: Mar 08 18:24:49 Some, you should check http://www.nslu2-linux.org. There is a lot of Mar 08 18:24:49 Work there that is a MASSIVE and enthusiastic continuation of what Mar 08 18:24:49 Is done on ixp4xx-osdg.fs.net. Mar 08 18:25:25 hehe MASSIVE Enthusiasm! ;-) Mar 08 18:26:07 maybe something here will be of use: http://wiki.buici.com/bin/view/Main/IXPAccessLibrary Mar 08 18:26:17 http://wiki.buici.com/twiki/pub/Main/IXPAccessLibrary/ixp400_xscale_1.5_linux26.patch Mar 08 18:26:24 Yeah, I have that file. Mar 08 18:26:40 that alone almost is enough to make it go. Mar 08 18:27:27 A bit of additional makefile hacking was required. Mar 08 18:27:39 Well, with luck it'll be under control this week. Mar 08 18:28:46 I really appreciate your doing this - it's not remotely easy Mar 08 18:29:06 Well, dont thank me until it actually works. ;-) Mar 08 18:30:05 :-) Mar 08 18:31:27 AHA, there it is. Mar 08 18:31:40 ? Mar 08 18:31:40 ixOsCacheMMU.h Mar 08 18:32:15 steal some bits from the old patch. Mar 08 18:32:35 + * 2.6 kernels do not export the required cache functions. Mar 08 18:33:16 heh Mar 08 18:33:32 that should get you at least clean_dcache_range and invalidate_dcache_range Mar 08 18:34:13 these "in_irq, BIT, exit_files" however, look more like something not properly included or defined Mar 08 18:34:30 they are too generic to be exorted funcs IMHO Mar 08 18:34:36 exported Mar 08 18:35:16 googling tells me in_irq is probably related to spin locking. Mar 08 18:35:38 but I didnt really get into it yet. Mar 08 18:36:39 surely they aren't macros ? Mar 08 18:40:57 BIT sounds familiar. Mar 08 18:41:03 I think I ran into that one before. Mar 08 18:41:18 the other 2 will need some research. Mar 08 18:42:48 well BIT actually looks like a macro I guess Mar 08 18:52:12 * rwhitby-away dances cause he finally got his dial-in modem working on OpenSlug .... Mar 08 18:53:10 you can't dial-in to a 56K or V.90 modem - you have to tell it to go down to V.34 before it will accept an incoming call negotiation. at least that's my experience .... Mar 08 18:53:21 hmm interesting Mar 08 18:55:36 and of course every single modem has a different AT command to tell it to go down to V.34 .... Mar 08 18:56:09 and of course all the sites that have AT command set documents first on google want you to pay for them ... Mar 08 18:56:35 what??? Mar 08 18:56:37 bastage Mar 08 18:58:28 anyway, now that frees up the wrt54gs for some new firmware .... Mar 08 18:59:11 hmm Mar 08 18:59:12 2.6.11.2 is out Mar 08 19:00:57 hmm, some intresting stuff in here: http://kernel.org/pub/linux/kernel/v2.6/testing/cset/ Mar 08 19:01:16 patch from lennert in there .. Mar 08 19:01:23 [ARM] Fix build error in rtctime.c Mar 08 19:01:23 Oops, it broke. Glue the bits back together, replacing yrs with Mar 08 19:01:23 tm->tm_year + 1900. Mar 08 19:06:31 do we use edge triggered interrupts? Mar 08 19:06:32 [quote] I will not merge untested changes into Linus' tree. Mar 08 19:10:21 yep I saw that :-) Mar 08 19:11:28 Anyone gonna try it? Mar 08 19:12:38 Oh what the hell. Mar 08 19:12:45 I'm tired of looking at ixp stuff anwaysw. Mar 08 19:12:48 heh Mar 08 19:13:15 The main reason is there are two interesting sounding patches to USB that might be relavent. Mar 08 19:13:41 the edge triggered interrupt one is one, and the other is the one about the URB handler going funky. Mar 08 19:13:53 yeah Mar 08 19:17:18 Bitbaking. Mar 08 19:18:30 Its a good time to stop working on ixp stuff, managed to hose that include file. Mar 08 19:39:36 Flashing Mar 08 19:42:50 drum roll..... Mar 08 19:44:00 Booting Mar 08 19:45:15 ..... Mar 08 19:45:32 (first boot, taking a bit to generate the dropbear key) Mar 08 19:47:20 Whats a surefire way to trigger it? Mar 08 19:48:23 I just dd'd 200M from /dev/zero to bigassfile..../ Mar 08 19:49:09 now try the converse Mar 08 19:49:21 cat the file to /dev/null Mar 08 19:51:29 Ah, there it is. Mar 08 19:51:39 catting to /deb/null set it off. Mar 08 19:51:50 :-( Mar 08 19:52:29 at least you can reproduce the problem :) Mar 08 19:52:41 now fix it! Mar 08 19:53:23 :) Mar 08 19:56:37 Is this even worth pushing? Mar 08 19:56:44 The change is trivial Mar 08 19:57:40 we're already on the bleeding edge, so we might as well stay there .... Mar 08 19:58:27 stay on the bleeding edge we're alreadey on, or to a even more bleeding edge? ;-) Mar 08 19:59:13 stay on the bleeding edge that is moving forward Mar 08 19:59:54 now, I have to remember how to revert from openwrt to sveasoft now .... Mar 08 20:02:48 Okay, so I made a new bb for it, would it be better to simply use the old 2.6.11.bb and pull the 2.6.11.2 source instead? or.. ?? Mar 08 20:03:00 that patchset wosk out of the box Mar 08 20:03:10 s/wosk/works Mar 08 20:03:32 update the 2.6.11.bb I say ... Mar 08 20:03:50 Ok Mar 08 20:26:36 <[g2]> jacques, dyoung so 2.6.11.2 is a go ? Mar 08 20:27:08 sounds like it works but doesn't fix anything Mar 08 20:27:17 <[g2]> nod Mar 08 20:27:18 it will be as soon as I boot this image. Mar 08 20:27:23 <[g2]> just like .11 Mar 08 20:27:25 Its starting to annoy me. Mar 08 20:27:48 if I have to upslug it one more time I'm gonna just push it and let someone else test it. Mar 08 20:28:09 <[g2]> did rwhitby-away finish the ipkg upgrade ? :) Mar 08 20:28:13 like that. Mar 08 20:28:15 GAH Mar 08 20:28:17 ok Mar 08 20:28:29 <[g2]> or was he just chatting all night :) Mar 08 20:28:46 <[g2]> I'm rubbing off on you guys Mar 08 20:29:29 um, I was at work all your night .... Mar 08 20:30:01 <[g2]> good I'm just winding you up to get started coding ! :) Mar 08 20:30:31 I'm reflashing my wrt54gs at the moment .... Mar 08 20:30:43 <[g2]> Talisman ? Mar 08 20:31:19 alchemy 7 Mar 08 20:31:54 I'm getting this: Mar 08 20:31:56 ERROR-Can't get read lock on the repository. Mar 08 20:31:56 pull: remote locked, trying again... Mar 08 20:31:59 <[g2]> just an update or was there a feature you wanted to play with ? Mar 08 20:32:14 jacques, that was probably me locking the repo while pushing over my crappy link Mar 08 20:32:23 ok Mar 08 20:32:40 now that I've moved the dial-in modem over to AccessSlug, I can finally play with the firmware on the wrt54gs. Mar 08 20:33:00 pull is working now Mar 08 20:33:23 sorry abut that. My crappy link apologizes. Mar 08 20:33:42 np Mar 08 20:34:18 [g2] I was hoping to have csr-1.5 up by the time you woke up; but its going to be kind of involved. It all compiles, but there are subtle issues that need addressing. Mar 08 20:34:46 <[g2]> dyoung, what's new and exciting in 1.5 ? Mar 08 20:34:59 I dunno, I cant load it yet. ;-) Mar 08 20:35:23 AFAICT, its net benefit for us will be almost nothing. Mar 08 20:36:22 The endian-ness is a compile time option; so if someone wanted to run their nslu2 in le for some reason it would still be a PITA. Mar 08 20:36:44 some stuff is streamlined. Mar 08 20:36:48 there's a lot of that null net benefit going around lately ;-) Mar 08 20:36:50 but most of it is bulkier. Mar 08 20:36:53 <[g2]> and performance would suck even more Mar 08 20:37:21 so at this point, CSR-1.5 is mostly acedemic to me. Mar 08 20:37:38 <[g2]> swap every packet from Network order to LE and back Mar 08 20:38:24 They added a OS Interface layer which is being a PITA. Mar 08 20:39:01 <[g2]> For me, I want to do the following: Mar 08 20:39:09 <[g2]> 1/ Bury the EHCI issue Mar 08 20:39:19 In theory I ought to be able to patch the hell out of it to make it 2.6 compatible; but the rest of it has som ebuild issues anyways. Mar 08 20:39:41 (the OS Interface layer that is) Mar 08 20:39:48 <[g2]> 2/ Have a smooth upgrade path like we discussed last night Mar 08 20:40:08 <[g2]> 3 / performance test the box and know it's limits and weaknesses Mar 08 20:40:12 <[g2]> 4 / packages Mar 08 20:40:21 like: unslung -> openslug? Mar 08 20:40:33 no Mar 08 20:40:34 <[g2]> perlguru, more just opeslug Mar 08 20:40:43 <[g2]> straight from OE Mar 08 20:41:05 ah, ipkg upgrade kernel Mar 08 20:41:37 <[g2]> I mean we are *so* close Mar 08 20:42:55 <[g2]> and 1.5 APEX support Mar 08 20:43:11 and Wiki updates Mar 08 20:45:18 perlguru: thanks!!! we were looking for a volunteer .... Mar 08 20:45:25 nod. Mar 08 20:46:33 <[g2]> anybody run on the new 0.45 dropbear client yet ? Mar 08 20:46:40 <[g2]> s/client/server/ Mar 08 20:46:49 ok, i want to help. but i am not openslugged yet. i am trying to build a openslug image on my laptop first Mar 08 20:47:44 * [g2] has *really* been toying with creating an iso with every thing needed to run in qemu to just compile or make changes on Mar 08 20:48:16 <[g2]> SoftDevSlug Mar 08 20:48:35 0.45 looks worthwhile - small number of bug fixes Mar 08 20:53:57 <[g2]> rwhitby-away, where's that openslug packages bb ? Mar 08 20:54:15 meta/openslug-packages.bb Mar 08 20:54:25 next to openslug-image Mar 08 20:54:39 <[g2]> thx Mar 08 20:54:54 <[g2]> I was going to try and play with adding the kernel upgrade Mar 08 20:55:08 <[g2]> given that I need to upgrade to the 11.2 Mar 08 20:55:15 <[g2]> and it's built Mar 08 20:56:46 <[g2]> weren't you going to add diffutils to there ? Mar 08 20:56:57 <[g2]> on that's in openslug-image Mar 08 20:57:00 <[g2]> oh Mar 08 20:57:03 I put it in the base image Mar 08 20:57:07 <[g2]> nod Mar 08 20:57:18 <[g2]> chicken-egg issue Mar 08 20:57:33 it was a borderline decision - it could go in -packages if anyone objected Mar 08 20:57:46 <[g2]> nbd Mar 08 20:58:08 since it is only used for upgrades, you could argue that you must be in a position to ipkg install it yourself Mar 08 20:58:45 if dyoung bumped the PR, then nudi should build 2.6.11.2 now and upload it to the feed Mar 08 20:58:56 I bumped the PR. Mar 08 20:58:58 <[g2]> Ok, so should there be a meta package grabs the two ixpmodules, all the kernel-modules-* and the kernel..nslu2 ? Mar 08 20:59:21 no, just ipkg upgrade Mar 08 20:59:53 <[g2]> then install all the proper packages Mar 08 21:00:45 it will upgrade all ipks on your slug Mar 08 21:00:45 including all those you just listed Mar 08 21:00:45 (as long as the version is bumped, which is has been for the kernel) Mar 08 21:01:06 ? Mar 08 21:01:45 ipkg upgrade won't install anything you don't already have (unless due to a dependency) Mar 08 21:02:01 it just installs new versions of the packages you have already Mar 08 21:02:52 <[g2]> so lets say you add some extra bt module Mar 08 21:03:02 yep Mar 08 21:03:20 <[g2]> since it wasn't in my original install that won't get pulled Mar 08 21:03:32 if I edit defconfig, and bump the kernel PR, then that new module will go to the feed when I run make on nudi Mar 08 21:03:38 it won't get installed unless you ask for it Mar 08 21:03:52 or something else you ask for requires it Mar 08 21:04:33 <[g2]> but all the other kernel modules would Mar 08 21:05:03 I need to check if they have the kernel PR in their version, or just the PV. Mar 08 21:05:24 <[g2]> kernel-image-2.6.11 - 2.6.11-r5 - Mar 08 21:05:25 <[g2]> kernel-module-ehci-hcd - 2.6.11-r5 - Mar 08 21:05:25 <[g2]> kernel-module-lockd - 2.6.11-r8 - Mar 08 21:05:25 <[g2]> kernel-module-nfs - 2.6.11-r8 - Mar 08 21:05:26 we'll see soon - nudi is building 2.6.11.2 now Mar 08 21:05:57 ok, looks like they track the full kernel PV + PR Mar 08 21:06:39 if you're ipkg upgrading, you need to be careful about ixp modules Mar 08 21:07:04 ixp400-csr is not in the feed, and ixp425-eth's version won't have changed Mar 08 21:07:43 <[g2]> I'd be pulling from my feed Mar 08 21:08:16 <[g2]> " /media/hdd/ipk/Packages or something like that Mar 08 21:08:38 oh, ok. Mar 08 21:09:00 <[g2]> but they probably didn't get rebuilt Mar 08 21:09:32 <[g2]> but a bb -c clean would rebuild them or erasing the stamp|work files Mar 08 21:13:52 <[g2]> followed by bb openslug-image Mar 08 21:14:08 yep Mar 08 21:14:08 <[g2]> rwhitby-away, did you add that ipkg rebuild thing to the nslu2 ? Mar 08 21:14:23 ? Mar 08 21:14:31 <[g2]> ipkg-make index thingy Mar 08 21:14:57 um - I dunno Mar 08 21:15:11 I think it was already there, but you need python installed Mar 08 21:15:30 <[g2]> kinda excessive for jffs2 only :) Mar 08 21:15:52 yep - why do you think I set up the official feed :-) Mar 08 21:16:41 * rwhitby-away muses on how often self-interest can be made to look like altruism .... Mar 08 21:16:41 <[g2]> cause you're OCD Mar 08 21:17:18 <[g2]> generating movtivation is truly underated Mar 08 21:20:04 <[g2]> 6/ find out about the minicachce Mar 08 21:23:16 Hmm. Alchemy has a bug which doesn't let me select my 9:30 timezone, even though it's in the drop-down list on the web page. Mar 08 21:23:26 :-( Now I have to work out how to access the Mar 08 21:23:31 CVS again and fix it ... Mar 08 21:28:39 looks like peteru is using the serial kit I sent him to upgrade to openslug .... Mar 08 21:29:05 [g2] nod Mar 08 21:29:41 Few people have the ability to truely motivate. Mar 08 21:29:53 I dont. Mar 08 21:30:20 <[g2]> sure you do, just tell rwhitby he "can't" Mar 08 21:30:33 heh Mar 08 21:30:33 <[g2]> :) Mar 08 21:30:49 "hey, rwhitby, you can't have ixp support in Apex" .... Mar 08 21:30:59 Hey rwhitby, I heard that its not possible to integrate CSR-1.5 into Linux 2.6.... Mar 08 21:31:14 ;-) Mar 08 21:31:38 * rwhitby-away doesn't do that low-level stuff :-) Mar 08 21:32:09 <[g2]> yeah, rwhitby-away will have to wait for the real coders to fix that Mar 08 21:32:18 <[g2]> :) Mar 08 21:32:23 exactly. Mar 08 21:32:23 Since i have the ixp400.o file, it shouldnt be too much of a stretch to get those 6 missing references resolved. Mar 08 21:32:41 But my brain turned off around 2 hours ago. Mar 08 21:33:06 * rwhitby-away 's only contribution to ixp modules was a "sleep 2" in the makefile Mar 08 21:33:10 hehe Mar 08 21:33:16 And I recycled it too. ;-) Mar 08 21:34:45 kergoth is talkative tonight .... Mar 08 21:36:34 he skipped sleep Mar 08 21:40:02 that was enough damage for one night. ;-) Mar 08 21:40:34 rwhitby-zzzz, dyoung-zzzz night! and sleep well! Mar 08 21:40:40 night Mar 08 21:42:31 `night everyone who's going to sleep Mar 08 21:48:56 ok, just sent the email off to Sveasoft to see if my developer status can be reinstated :-) Mar 08 21:49:24 (I don't think it was revoked, I've just forgotten where everything is ...) Mar 08 21:49:50 Yeah, you've been slacking on that project, spendingtoo much time with nslu2. Mar 08 21:50:08 RLB, RLW, etc, etc. Mar 08 21:51:47 yeah, but I only ever fixed the bugs that affected me in Sveasoft firmware ... Mar 08 21:56:25 morning Mar 08 21:56:44 morning Mar 08 23:12:43 * perlguru Leaving **** ENDING LOGGING AT Tue Mar 08 23:59:56 2005