**** BEGIN LOGGING AT Sun Mar 06 23:59:56 2005 Mar 07 00:07:03 man...lots to read here since I fell asleep Mar 07 05:26:10 CONFIG_MD=y doesnt add anything to the kernel size as far as I can tell. The actual MD bit still gets built as a module, CONFIG_MD just tells it to think about doing the rest of it. Mar 07 05:27:06 root@devslug:~# modprobe input Mar 07 05:27:06 input: Unknown symbol hotplug_path Mar 07 05:27:06 input: Unknown symbol add_input_randomness Mar 07 05:27:06 FATAL: Error inserting input (/lib/modules/2.6.11/kernel/drivers/input/input.ko): Unknown symbol in module, or unknown parameter (see dmesg) Mar 07 05:27:16 input module doesn't like 2.6.11 - works fine on 2.6.9 Mar 07 05:27:39 look's like I'll need to go spelunking through the kernel source ... Mar 07 05:27:46 dyoung: yeah, we kept it for that reason Mar 07 05:28:15 we got it under the limit through other means :-) Mar 07 05:32:02 what is input used for? Mar 07 05:32:08 bluetooth Mar 07 05:32:16 hidp I think Mar 07 05:32:35 I might have to break that dependency instead .... Mar 07 06:16:28 This doesnt affect the size. Mar 07 06:17:17 its still at 1037020 for me. Mar 07 06:17:35 So now in theory if I had a pwc based camera handy, I could plug it in and it might work. Mar 07 07:57:49 ok, so I've disabled HIDP on bluetooth, and therefore the need for CONFIG_INPUT=m goes away, and 2.6.11 now stacks up as a candidate for AccessSlug. Mar 07 08:02:30 [g2]-food: I'm now comfortable with bumping the openslug baseline from 2.6.9 to 2.6.11 (with ext3 and jbd compiled in) Mar 07 09:32:28 [g2]: I've clobbered the flash drive and am preparing to runs some tests. Mar 07 09:32:37 <[g2]> great Mar 07 09:32:46 <[g2]> did you build bonnie ? :) Mar 07 09:32:58 <[g2]> lol Mar 07 09:34:54 I'm not seeing the error. Mar 07 09:34:59 ...wait. Mar 07 09:35:23 OK. This is different. I'm getting a watchdog timer failure Mar 07 09:35:55 <[g2]> ehci_watchdog Mar 07 09:36:18 That's the one. Mar 07 09:36:29 Is that what you have been seeing? Mar 07 09:38:55 <[g2]> beewoolie, yeah it says "irq26: Nobody cared" Mar 07 09:39:05 <[g2]> right before the trace Mar 07 09:39:18 <[g2]> like this http://www.nslu2-linux.org/wiki/OpenSlug/EhciIssue Mar 07 09:39:29 Well, the nobody cared part isn't really a problem. The watchdog problem may be. Mar 07 09:39:58 <[g2]> it's always the dog biting Mar 07 09:40:13 <[g2]> I thought they were together Mar 07 09:40:17 Odd. It looks like the filesystem on my flash drive is corrupt. Mar 07 09:42:49 <[g2]> hey! welcome kas11 Mar 07 09:43:06 :) @ [g2] Mar 07 09:43:13 <[g2]> we're just missing siddy Mar 07 09:43:27 who is probably asleep. Mar 07 09:43:50 <[g2]> it just 2:45 AM there :) Mar 07 09:44:14 There it is again. Mar 07 09:44:31 <[g2]> welcome to the club :), it's always the same thing Mar 07 09:45:29 It only happens when the drive has been used. A fresh fs is OK. Mar 07 09:45:39 <[g2]> nod Mar 07 09:45:51 <[g2]> usually only under some load Mar 07 09:49:31 <[g2]> could it be a pci bus timeout/retry ? Mar 07 09:53:29 do you have CONFIG_USB_DEBUG set?...doesn't that give an error report in the log (or console if you change loglevel)? Mar 07 09:54:34 <[g2]> I did but it didn't print out anything Mar 07 09:55:02 I think that the asm_do_IRQ call is being invoked from the interrupt handler. Mar 07 09:56:01 the nobody cared came from do_level_IRQ iirc Mar 07 09:56:40 I wonder if edge triggered IRQs are working in 2.6.11? Mar 07 09:57:04 <[g2]> these are level triggered Mar 07 09:59:15 Level triggered is probably OK. Mar 07 09:59:36 There are some oddities in this code. For example, I'm seeing the watchdog being initialized, but never started. Mar 07 10:00:35 I see it now. Someone is putting code in headers again. Mar 07 10:00:35 that was in a patch at some point Mar 07 10:03:05 <[g2]> beewoolie, which code what header ? Mar 07 10:03:28 ehci.h Mar 07 10:03:39 Are we seeing this problem in the linksys release fw? Mar 07 10:03:52 <[g2]> no Mar 07 10:04:01 <[g2]> but the device does lockup sometimes Mar 07 10:04:10 <[g2]> or get real-slow Mar 07 10:04:20 Probably contributes to poor sales. Mar 07 10:04:54 * [g2] wonders how many unit have been sold Mar 07 10:05:00 I think this is a bonafide error and it looks like something caused by the structure of the driver. Mar 07 10:05:25 <[g2]> great Mar 07 10:05:54 <[g2]> the puppy guys have issues with 2.6.10 on the x86 platform Mar 07 10:06:00 My read is that the driver is processing from the watchdog function while the CPU triggers another interrupt. Mar 07 10:06:20 <[g2]> a soft interrupt ? Mar 07 10:06:20 The second interrupt, however, cannot be processed because it is spurrious. Mar 07 10:06:58 I'm not precisely clear on the soft interrupt code. IIRC, the kernel can dispatch interrupts like threads. Mar 07 10:07:11 The key is the __irq_svc entry point. Mar 07 10:07:17 That is the hardware interrupt handler. Mar 07 10:07:41 You can see the asm_do_IRQ calls are coming from the irq_svc handler. Mar 07 10:07:50 <[g2]> __ in the driver book said to use these unless you know what you are doing :) Mar 07 10:08:06 Huh? Mar 07 10:08:18 <[g2]> it was a joke Mar 07 10:08:22 It looks like interrupts are being enabled when they shouldn't be. Mar 07 10:08:35 <[g2]> I saw exactly that in the trace Mar 07 10:08:42 <[g2]> but I didn't and still don't understand it Mar 07 10:08:44 It looked like a joke, but it's hard to parse. Mar 07 10:09:01 If I want to add some code to the kernel, what would I do? Mar 07 10:09:08 <[g2]> easy Mar 07 10:09:09 Do I edit the oe build and produce another image/ Mar 07 10:09:12 ? Mar 07 10:09:30 Also, now that I've put openslug on, how do I replace the kernel? Mar 07 10:09:43 Let me guess...mtdblock/ Mar 07 10:09:44 ? Mar 07 10:09:55 <[g2]> http://www.nslu2-linux.org/wiki/HowTo/TweakKernelOrPackagesInOE Mar 07 10:10:01 OK. Mar 07 10:10:21 <[g2]> the stamps dir is going to be different 2.6.11-r4 Mar 07 10:10:24 <[g2]> or r5 Mar 07 10:10:31 My hunch is that the ehci code is sometimes failing to properly clear the interrupt status. Mar 07 10:10:59 <[g2]> I'd love to see that Mar 07 10:11:45 <[g2]> I was looking at all the spin_locks earlier Mar 07 10:11:55 It could really be a problem with the ixp code. What I've seen of the sharp CPUs is that sometimes, we need to clear interrupts in more than one place. Mar 07 10:12:15 The interrupt controllers have one bit and the chips have another. Mar 07 10:12:25 As this is PCI, it's going to be even more messy. Mar 07 10:12:35 here goes nothing.... Mar 07 10:13:48 <[g2]> ~seen desaxena_away Mar 07 10:15:15 Once I have it...do I just reflash the kernel partition? Mar 07 10:16:06 <[g2]> I use tftp to load the linksys image (kernel and rootfs) then boot that from ram and use the web to reflash Mar 07 10:16:25 <[g2]> are you serial enabled on that unit ? Mar 07 10:16:47 <[g2]> I think dyoung and rwhitby upslug the image Mar 07 10:16:48 yeah. Mar 07 10:17:05 <[g2]> you might be able to do it with switchbox too Mar 07 10:17:09 Does that load the whole image? Mar 07 10:17:13 <[g2]> via .recovery Mar 07 10:17:20 <[g2]> upslug ? Mar 07 10:17:28 yeah. Mar 07 10:17:39 <[g2]> no, just the kernel and rootfs Mar 07 10:17:49 <[g2]> so it's the last to partition Mar 07 10:17:53 I'd like to keep the changes I've made to the root Mar 07 10:17:57 <[g2]> upslug DOES have an option to do that Mar 07 10:18:09 <[g2]> just boot the kernel Mar 07 10:19:06 <[g2]> change your kernel cmd line to boot directly to mtdblock4 and then just load the kernel in memory and boot Mar 07 10:19:24 PITA with redboot, tho. Mar 07 10:21:57 Well, that didn't work. I crashed. Mar 07 10:22:12 I suspect that the problem is the lack of a header on the kernel. Mar 07 10:32:03 [g2]: I'm having a hard time getting the partitions in openslug to add up. Mar 07 10:32:41 <[g2]> did you flash the kernel or load from ram ? Mar 07 10:32:51 Oh I clobbered it good. Mar 07 10:33:15 <[g2]> then just use the procedure and reflash kernel/rootfs Mar 07 10:33:28 That's not what I'm looking at. Mar 07 10:34:04 <[g2]> Redboot is still there right ? Mar 07 10:34:08 The partitions that the kernel showed me don't seem to add up. Either I'm tired, or there is something rotten in denmark. Mar 07 10:34:12 redboot is OK. Mar 07 10:34:25 <[g2]> they are overlaid Mar 07 10:34:32 mtd0: 00040000 00020000 "RedBoot" Mar 07 10:34:32 mtd1: 00020000 00020000 "SysConf" Mar 07 10:34:32 mtd2: 00100000 00020000 "Kernel" Mar 07 10:34:32 mtd3: 006a0000 00020000 "Ramdisk" Mar 07 10:34:32 mtd4: 00640000 00020000 "Flashdisk" Mar 07 10:34:33 mtd5: 00020000 00020000 "FIS directory" Mar 07 10:34:33 <[g2]> it's to make Redboot happy Mar 07 10:35:12 wow, one mention of room in -linux and the populace in here explodes Mar 07 10:35:32 Huh? Mar 07 10:36:10 OK. I'll use another upgrade procedure. Mar 07 10:36:37 <[g2]> when your not hosed Mar 07 10:36:45 My preferred avenue would be to fix the bootloading process before hitting these kernel issues. I'll spend a little time with this, but I'm not going to get all crazy on it. Mar 07 10:37:12 My experience tells me that it is wiser to get the foundation solid before troubleshooting upper layers. Mar 07 10:44:01 In fact, this is the first and last time I'm going to try this. I'd rather get apex running than troubleshoot this way. Mar 07 10:45:20 It didn't work. Mar 07 10:45:38 I'm getting a not-have eRcOmM Mar 07 10:47:46 I'm going to try to get the linksys fw back on. Mar 07 10:53:34 <[g2]> on phone Mar 07 11:16:57 beewoolie: you can just load the kernel into ram and run it with the jffs2 rootfs. Mar 07 11:17:01 this is from redboot command line Mar 07 11:17:27 See: http://www.nslu2-linux.org/wiki/HowTo/TestAnImageInRamUsingRedBoot Mar 07 11:17:42 I use that all the time to keep my existing rootfs, but test a new kernel. Mar 07 11:17:54 as long as the modules are still compatible, then you're ok Mar 07 11:20:04 the key is to use "move" to load the kernel and initrd into ram, then use "load" to replace the kernel in ram, then use "exec" to start it all off .... Mar 07 11:29:10 [g2]: is the trimmed 2.6.11 kernel working for you? Mar 07 11:31:27 <[g2]> rwhitby-web, seem ok when I did the pull earlier today Mar 07 11:32:11 what's next on the punchlist that I should look at ? Mar 07 11:33:37 * [g2] hugs rwhitby-away Mar 07 11:33:43 * [g2] hugs rwhitby-web Mar 07 11:33:57 <[g2]> beewoolie, wanted vfat modules Mar 07 11:34:09 <[g2]> I don't know if they are in there or not Mar 07 11:34:27 ok, I can add and test that easy enough tonight. Mar 07 11:34:41 <[g2]> and tune2fs if you get to it Mar 07 11:34:50 I've updated the defconfig to reflect reality from .config Mar 07 11:35:18 I'm going to go back to APEX. I'd rather have better tools for troubleshooting that all of the RedBoot mishugas. Mar 07 11:35:22 <[g2]> ok, so to match the 2.6.11 options Mar 07 11:35:22 is tune2fs an openslug package ? why would we have it in the base image and not just add it to openslug-packages? Mar 07 11:36:11 <[g2]> don't know where it is Mar 07 11:36:22 <[g2]> I just got off the phone a couple minutes ago Mar 07 11:37:20 <[g2]> oe needs a revere index Mar 07 11:37:25 <[g2]> reverse Mar 07 11:37:52 I usually just look up packages.debian.org with a package contents search Mar 07 11:37:59 e2fsprogs for tune2fs Mar 07 11:39:57 so ipkg install e2fsprogs should install it right now .... Mar 07 11:40:08 (it's already in the feed) Mar 07 11:40:09 <[g2]> it just built for me Mar 07 11:40:41 <[g2]> lemme check how big it is Mar 07 11:41:38 if it's not needed before ipkg is up and running after a clean boot, then it should just be a package rather than in the base image. Mar 07 11:41:55 <[g2]> nod. Mar 07 11:41:56 (as it is now) Mar 07 11:42:10 Isn't that true for mke2fs? Mar 07 11:42:46 <[g2]> tune2fs isn't being built Mar 07 11:43:01 <[g2]> just fdisk, mke2fs and 3 Mar 07 11:43:32 <[g2]> and e2fsck Mar 07 11:43:38 makefs's are required for creating an external disk onto which the packages you download are put :-) Mar 07 11:43:48 <[g2]> no fdisk there Mar 07 11:44:03 [g2]: do you mean "built" or "put into the base image" - two different things Mar 07 11:44:15 <[g2]> put into the image Mar 07 11:44:20 have you tried ipkg install e2fsprogs? Mar 07 11:44:29 <[g2]> I was looking in work Mar 07 11:44:36 <[g2]> work/install Mar 07 11:44:51 <[g2]> tmp/work/e2fsprogs-1.36-WIP-0408-r3 Mar 07 11:45:02 yep, tunefs is under sbin Mar 07 11:45:23 .../intall/e2fsprogs/sbin/tune2fs Mar 07 11:45:41 we only install the needed bits in the images, the rest is in the feed Mar 07 11:46:01 that OE package creates about five ipks - we install two and leave the other three in the feed for later Mar 07 11:46:45 correction, we install three: e2fsprogs-mke2fs e2fsprogs-fsck e2fsprogs-e2fsck Mar 07 11:47:23 if tune2fs is required for bootstrapping, then we can add that too .... Mar 07 11:47:28 what's the intended use for it? Mar 07 11:48:09 <[g2]> well have to figure it out for the flashdisk/hd base install Mar 07 11:48:53 yep, at the moment I've just added things that are used in the base scripts and bootstrap procedures (like the vegetable page) Mar 07 11:49:58 and left everything else in the feed, with the intention that people add what extras they want as a = in their local.conf (I do that for my bluetooth stuff for instance) Mar 07 11:50:22 the less we put in the base image by default, the greater the space available for people to choose what they want in *their* base image Mar 07 11:50:47 From my local,conf: OPENSLUG_EXTRA_DEPENDS = "bluez-utils-nodbus ppp" Mar 07 11:50:51 Mmmm Vegetables..... Mar 07 11:51:20 OPENSLUG_EXTRA_INSTALL = "kernel-module-hci-usb libbluetooth1 bluez-utils-nodbus kernel-module-ppp-generic kernel-module-slhc ..... Mar 07 11:51:28 AHA, Mar 07 11:51:29 <[g2]> OPENSLUG_EXTRA_RDEPENDS += "strace thttpd " Mar 07 11:51:33 THATS the line I want. Mar 07 11:51:39 <[g2]> just playing with thttpd Mar 07 11:51:47 EXTRA_INSTALL Mar 07 11:51:47 <[g2]> I want that plus php5 Mar 07 11:52:06 <[g2]> did I tell you my performance number with that ? Mar 07 11:53:23 So did we decide where to put openslug specific howtos? Mar 07 11:53:34 I'll read it in the log. i gotta get outta here. Mar 07 11:53:34 <[g2]> under the OpenSlug page Mar 07 11:53:36 back later Mar 07 11:53:45 like on the main openslug page? Mar 07 11:53:57 <[g2]> Sure we can have a howto there Mar 07 11:53:58 or make a howto section? Mar 07 11:53:59 OpenSlug/DoSomethingSoundingLikeAnActiveVerb Mar 07 11:54:13 just do it like on the Unslung page Mar 07 11:54:14 Right, but where do those link from? Mar 07 11:54:36 or create OpenSlug/HowTo ... but you can only have two levels Mar 07 11:54:49 they are inline in the Unslung HomePage Mar 07 11:55:10 Okay gotcha. Mar 07 11:55:35 so sometime we'll cleanup the Howto page to move stuff to the proper place? Mar 07 11:55:43 (the main how to page) Mar 07 11:56:02 One thing we have to do is make sure that nothing required goes into OPENSLUG_EXTRA_* ... that should be reserved for the builder's customisations. Mar 07 11:56:20 Anything that we always want or need to be in the base image should go directly in openslug-image.bb Mar 07 11:56:46 <[g2]> or openslug.conf Mar 07 11:56:52 NO Mar 07 11:56:56 that's the point Mar 07 11:57:48 OPENSLUG_EXTRA_* is for the person building a custom image to add stuff, not for the people who are defining the base image to use Mar 07 11:58:06 the base image stuff goes directly in openslug-image.bb, not in OPENSLUG_EXTRA_*. Mar 07 11:59:15 For example, the usbnet and usbserial modules are not part of the base image, they are a default customisation (i.e. you should be able to not include them by putting something in local.conf). Mar 07 11:59:16 <[g2]> we need to get the OE soup all straight and written up Mar 07 12:00:09 I moved a whole lot of stuff from openslug.conf to openslug-image.bb specifically for this reason. Mar 07 12:00:20 <[g2]> I think there are conventions that we should abide by Mar 07 12:00:31 <[g2]> and we need to make them know to all Mar 07 12:00:37 agreed Mar 07 12:00:40 <[g2]> are at least all with bk write perms Mar 07 12:01:15 <[g2]> And I think it makes a *bunch* of sense to set things up like that Mar 07 12:01:54 Hmm - I just realised that since local.conf is read first, then the plus-equals signs in openslug.conf for OPENSLUG_EXTRA_* should be ?= instead. Mar 07 12:02:37 so if you set it up in local.conf, then the stuff in openslug.conf is ignored (cause it is all optional - if you don't have that usbnet or usbserial hardware, then you don't want those modules in your base image) Mar 07 12:03:23 <[g2]> this is the kind of stuff that needs to be clarified for OE Mar 07 12:03:28 so those who don't customise get a reasonable default set of optional modules, and those who do customise have the maximum space available for their customisations (cause nothing optional is forced on them) Mar 07 12:04:04 <[g2]> ?= from my understanding is "Check if the variable is empty" and define it if it is not Mar 07 12:04:05 at least that was my intention when I created those OPENSLUG_EXTRA_* variables way back when .... Mar 07 12:04:29 <[g2]> I thought += just appends Mar 07 12:04:32 don't you mean "check if empty and define only if it is empty" Mar 07 12:04:47 yeah - that's why I'm saying that those plus-equals should be ?= Mar 07 12:05:35 we shouldn't be appending optional modules to the set that the customiser wants, we should only be providing a default set for the non-customiser. Mar 07 12:06:01 and any required modules (for which the customiser doesn't have a choice) go directly in openslug-image.bb **** BEGIN LOGGING AT Mon Mar 07 12:07:45 2005 Mar 07 12:10:07 <[g2]> Ok I'm looking at the cleaned up openslug-image Mar 07 12:10:10 <[g2]> .bb Mar 07 12:11:15 <[g2]> and the thought crosses my mind about the nslu2-linksys-firmware Mar 07 12:11:44 <[g2]> and nslu2-switchbox-firmware Mar 07 12:13:19 <[g2]> and I'm wondering if we can just layer the OpenSlug Redboot compatible stuff on top of a vanilla distro Mar 07 12:13:53 <[g2]> and also what it exactly means for the kernel configuration of the custom distro Mar 07 12:16:20 yep, I expect that openslug-image.bb will eventually split into openslug-redboot-image.bb and openslug-apex-image.bb Mar 07 12:16:59 and the changes should be confined to those two files only. everything else in the rootfs should be identical. Mar 07 12:17:50 so start creating an openslug-apex-image.bb, and when it is a viable alternative (it may well be that today), then we'll do the split. Mar 07 12:18:10 <[g2]> the only question I have is the defconfig Mar 07 12:18:21 <[g2]> and the issue that has with modules Mar 07 12:18:47 why would the defconfig be different (apart from cmdline, which I'm assuming apex will pass in) ? Mar 07 12:19:01 <[g2]> apex isn't limited to 1MB Mar 07 12:19:12 <[g2]> for the kernel, cause it in the rootfs Mar 07 12:19:59 right, so you would then have openslug-redboot-kernel and openslug-apex-kernel and the respective -image files would depend on the right one. just like we do with -standard and -able in unslung today. Mar 07 12:20:26 and openslug-image.bb builds both. Mar 07 12:20:46 (just like unslung-image.bb builds both unslung-standard and unslung-able) Mar 07 12:21:04 (it does this just be depending on openslug-redboot-image and openslug-apex-image) Mar 07 12:21:40 <[g2]> well -standard and -able are under the same constraints Mar 07 12:21:44 my point is that any packages like base-files and openslug-init should be the same between the two distro variants Mar 07 12:21:54 <[g2]> -redboot and -apex are different Mar 07 12:22:15 right, but the mechanism for differentiation is the same Mar 07 12:22:29 you still built two kernels, one rootfs, and two images. Mar 07 12:22:54 you *don't* want two rootfs's cause then your support load doubles. Mar 07 12:23:34 <[g2]> this is great stuff Mar 07 12:23:38 and you make sure that the major differences between the redboot kernel and the apex kernel is just that things have to be modules in the redboot kernel due to the size limit Mar 07 12:24:35 so the combination of static kernel and modules gives the same functionality for the redboot variant and the apex variant - the only difference is whether the functionality is built into a monolithic kernel or whether it has to be modules. Mar 07 12:24:59 I would still recommend not putting anything in the kernel which can reasonably be a module, cause we still have limited RAM Mar 07 12:25:12 <[g2]> but for the modules that flows though to the init scripts which become different Mar 07 12:25:47 hmm - is there some way to check whether an insmod is required or not? Mar 07 12:26:01 it's just whether you have to insmod or not, right? Mar 07 12:26:26 <[g2]> I think it can be added to /etc/modprobe.conf and the update-modules is supposed to flow through Mar 07 12:26:38 (i.e. the only difference in the init scripts between a redboot image and an apex image should be simply whether you have to insmod a module before you use it's functionality) Mar 07 12:26:39 <[g2]> I haven't fully sorted that out Mar 07 12:26:50 it *should* all just work in OE Mar 07 12:27:17 <[g2]> well there's still the bug in binutils between endianness and modules Mar 07 12:27:37 <[g2]> so OE can't precompute the module deps unless the native hw is BE Mar 07 12:28:01 it still works on second boot though, right? Mar 07 12:28:01 <[g2]> or we switch the slug to LE :) Mar 07 12:28:17 <[g2]> the get computed on the first boot Mar 07 12:28:28 <[g2]> so it works after they are computed Mar 07 12:28:50 <[g2]> and the alias solves the ixp425_eth issue Mar 07 12:28:53 yeah, so the second boot of a redboot image is indistinguishable from the first boot of something which has had the modules.dep precomputed in the image, right? Mar 07 12:29:45 <[g2]> pretty much, I mean there's the .configured thing and stuff like the dropbear key doesn't get regened etc.... Mar 07 12:29:45 anyway, these are implementation issues - do you agree with the general philosophy of how to support both redboot and apex with a common rootfs? Mar 07 12:30:31 <[g2]> generally for now yes Mar 07 12:30:48 <[g2]> I'm thinking about workflow Mar 07 12:30:54 <[g2]> and about what will be different Mar 07 12:31:39 <[g2]> and whether the openslug-kernel should be standard/fixed except for OE literate ppl Mar 07 12:32:31 <[g2]> which is a pretty small camp Mar 07 12:33:03 yeah, if you take the act of simply adding modules to the kernel, then the real kernel hackers is a small population. Mar 07 12:33:14 ... if you take out the act ... Mar 07 12:34:25 <[g2]> so for openslug-reboot, it'll be all modules Mar 07 12:34:44 <[g2]> and it just a little extra build time Mar 07 12:34:47 I propose that we start with the philosophy that the redboot and apex images are variants of openslug, with the same kernel and rootfs functionality, with different bootloader functionality, and with a different partitioning of that functionality between compiled-into-the-kernel and kernel-modules. Mar 07 12:35:21 so that the user experience *after* boot is identical for both Mar 07 12:35:32 Sounds good. :-0 Mar 07 12:36:46 if the user experience after boot is different, then I would propose that the redboot image be renamed to SlugPlus or something (assuming that the majority is using Apex by then) Mar 07 12:37:04 but I would prefer us *not* to go down that path Mar 07 12:37:33 What makes you think that the bootloader will change the runtime experience? Mar 07 12:37:48 <[g2]> several things Mar 07 12:38:10 beewoolie: I personally think that it should not. But [g2] disagrees with me I think. Mar 07 12:38:29 So I am preparing for that eventuality, even if it never arises. Mar 07 12:38:36 <[g2]> it's least common denominator design Mar 07 12:38:49 <[g2]> example Mar 07 12:38:56 <[g2]> switchbox needs nfs Mar 07 12:39:02 <[g2]> nfs is in openslug Mar 07 12:39:21 <[g2]> APEX won't need nfs Mar 07 12:39:38 <[g2]> APEX will have usb-serial console Mar 07 12:39:57 <[g2]> and the list goes on Mar 07 12:40:07 those all look like boot-time things to me ... Mar 07 12:40:34 <[g2]> its what's built into to the kernel Mar 07 12:40:42 my point of functionality commonality starts after /etc/init.d has finished. Mar 07 12:40:57 right, we've already said that the kernels will be different. what's the problem? Mar 07 12:41:11 <[g2]> After that thinks will be very similar Mar 07 12:41:14 <[g2]> things Mar 07 12:41:15 Hold on. The bootloader may support a serial console, but that shouldn't affect the user. The serial console can be available once the system boots. Mar 07 12:41:49 how does whether something is compiled into the kernel or whether it is a module, affect the user after-boot experience? Mar 07 12:41:58 Can't we use an initrd to smooth over the differences? Mar 07 12:42:24 <[g2]> ok lets look at openslug-image.bb for a second Mar 07 12:42:53 beewoolie: that's effectively what I am proposing. the redboot image uses the switchbox initrd to smooth over the boot differences. the only outstanding difference then is whether things are compiled into the kernel or whether they are modules. Mar 07 12:43:32 <[g2]> Under HIDDEN_PACKAGES mtd-utils-native slugimage-native nslu2-linksys-firmware nslu2-switchbox-firmware Mar 07 12:43:52 yep, in openslug-apex-image they would not be there Mar 07 12:44:13 well, slugimage would still be there, but would be called with different partitioning scheme probably Mar 07 12:44:39 and mtd-utils-native would still be there if the apex image has a jffs2 fs in the image Mar 07 12:44:47 but the other two are redboot-image specific Mar 07 12:45:11 <[g2]> slugimage is not needed at all Mar 07 12:45:17 virtual/kernel is different for redboot and apex images Mar 07 12:45:27 <[g2]> that's all redboot/sercom legacy stuff Mar 07 12:45:32 ok, so slugimage is redboot specific too. Mar 07 12:45:53 what builds the apex-image 8MB file? Mar 07 12:46:09 or is it just one big jffs2? Mar 07 12:46:12 <[g2]> who says it's and 8MB image ? Mar 07 12:46:21 <[g2]> it could just be the jffs2 Mar 07 12:46:32 <[g2]> or 2 of them Mar 07 12:47:00 yep, that would work - and in that case you don't need slugimage (or the version of slugimage which does the right stuff for images that include the apex bootloader) Mar 07 12:47:54 <[g2]> so lets posit this for a minute Mar 07 12:48:06 <[g2]> APEX is 1 block and 1 block config Mar 07 12:48:08 don't get hung up about how things are done today. Unslung moved from slugtool to slugimage. openslug will have other requirements. they just get factored in .... or the requirement for a slugimage tool goes away for openslug-apex. either way is fine Mar 07 12:48:15 <[g2]> then our JFFS2 is 7.75MB Mar 07 12:48:59 yep, so you'll probably want a tool to put all that together into something that you can post on the web for people to download and install .... Mar 07 12:49:10 <[g2]> and we just need to add the capability to switch to a ramdisk live and then unmount the jffs2 partition and reflash it Mar 07 12:49:42 and slugimage is versatile enough to do that with no redboot legacy things. or if it's not, then it would be made to be so. assuming you want a single file distribution. Mar 07 12:50:21 <[g2]> rwhitby-web, the tool is simply ipkg APEX Mar 07 12:50:33 <[g2]> ipkg install run Mar 07 12:50:42 <[g2]> bang, flush Redboot Mar 07 12:50:56 right, but what do you install first after you open your brand new linksys nslu2 box? Mar 07 12:51:37 <[g2]> Depends Mar 07 12:51:53 <[g2]> either a custom first image Mar 07 12:51:55 <[g2]> or Mar 07 12:52:06 what do you flash, and what do you use to flash, when you have stock firmware loaded, and you want to go via the most direct path to an openslug-apex image? Mar 07 12:52:10 <[g2]> the back-door that wipe Redboot Mar 07 12:52:31 right - I've been thinking an upslug EALL, with a monolithic 8MB image Mar 07 12:52:52 <[g2]> I'd re-write the upslug app Mar 07 12:53:05 <[g2]> that code looked nasty Mar 07 12:53:30 right - these are just tool names to represent concepts - obviously the functionality changes to suit new requirements Mar 07 12:54:27 the concept is a tool which flashes the full 8MB image including bootloader, config and rootfs, and then you just reset and you're booted into openslug-apex Mar 07 12:54:53 then the upgrade procedure may be different (ipkg install APEX-1.1, ipkg upgrade for rootfs) Mar 07 12:55:23 I already use ipkg upgrade for non-kernel changes on AccessSlug, rather than reflashing the rootfs Mar 07 12:55:47 <[g2]> as it should be Mar 07 12:56:04 yep, and if the packages have CONFFILES in them, then it even works :-) Mar 07 12:56:19 <[g2]> thanks to a good man! Mar 07 12:56:32 we'll get them all slowly .... Mar 07 12:56:37 <[g2]> nod Mar 07 12:57:06 so are we on the same page, with the task ahead being to flesh out the details on that page? Mar 07 12:57:30 <[g2]> I think things are very common Mar 07 12:57:55 that's all we've needed previously, so all is well with the world :-) Mar 07 12:58:20 <[g2]> we'll continue to learn and grow Mar 07 12:58:30 <[g2]> this is great stuff Mar 07 12:58:36 someone should put this in an OpenSlugRoadmap page ... Mar 07 12:58:42 <[g2]> and I appreciate you being so helpful and tolerant of me Mar 07 12:59:05 ditto :-) now let's have a group hug .... Mar 07 12:59:16 * [g2] give group hug Mar 07 12:59:19 <[g2]> gives Mar 07 12:59:24 <[g2]> hod! Mar 07 12:59:59 <[g2]> seriously I get the biggest kick out of John B. Mar 07 13:00:20 I can't work out yet whether fox knows anything or not .... Mar 07 13:00:44 <[g2]> he talks about what a loner he is and how he doesn't like to play with others Mar 07 13:00:55 <[g2]> but then sends a bunch of emails Mar 07 13:01:14 <[g2]> I think we'll win him over eventually Mar 07 13:01:36 yeah, we need his expertise on the team Mar 07 13:01:45 working in the same direction Mar 07 13:01:51 <[g2]> I'm happy he keeps e-mailing :) Mar 07 13:02:07 ok, I gotta go. Good discussion. Mar 07 13:02:14 <[g2]> nod. Thanks Mar 07 13:04:42 <[g2]> beewoolie, around ? Mar 07 13:39:59 Still here. Mar 07 13:41:27 <[g2]> hey Mar 07 13:41:41 Yo. Mar 07 13:42:07 This intel access library thing is kinda messy. Mar 07 13:42:15 <[g2]> nod. Mar 07 13:43:15 Dollface is on her way over. Do you have something quick? Mar 07 13:43:30 <[g2]> I just looking at the wiki Mar 07 13:43:34 <[g2]> enjoy Mar 07 13:43:40 <[g2]> I'll catch you tomorrow Mar 07 13:43:48 K. I wrote yet another page about upgrading the slug. Mar 07 13:44:02 <[g2]> I was just wondering how you were getting along with Redboot :) Mar 07 13:44:13 The procedure on the wiki is hard to read, and I think it needs a step to erase the flash (even though it shouldn't). Mar 07 13:44:33 You can browse my copy on wiki.buici.com. Mar 07 13:44:50 I'd have made the changes to the slug wiki, but I couldn't figure out how to do verbatim. Mar 07 13:44:51 <[g2]> SlugFirmwareInstallation Mar 07 13:44:57 Yeah. Mar 07 13:45:11 Nite. Mar 07 13:45:17 <[g2]> Ok. I'll read it tomorrow when I get up. Mar 07 13:45:18 <[g2]> Cheers Mar 07 15:38:39 deathly quiet. Mar 07 15:55:13 yep Mar 07 16:22:32 hmm - mt-daapd build fails - looks like they've moved the source ... Mar 07 18:14:48 building 2.6.11 for the feed now ... Mar 07 18:16:27 now, how to flash just the kernel ..... Mar 07 18:19:25 kern_header does the hard work, but we need a convenient tool .... Mar 07 18:19:55 cool, ipkg install kernel ;) Mar 07 18:20:37 yeah, we could easily do that with a postinst script Mar 07 18:20:53 just need a slug-flash tool Mar 07 18:22:33 we have the mtd-utils on there, so it's just a matter of putting it all together Mar 07 18:22:57 not sure how comfortable people will be with an automatic kernel flash from ipkg upgrade .... Mar 07 18:23:38 do it the gentoo-way, just download and let user do the installing Mar 07 18:24:03 (upgrade-kernel script) Mar 07 18:24:36 that's no fun ... Mar 07 18:25:23 or do it automigically if a config item is set. Mar 07 18:25:36 s/i/a/ Mar 07 18:54:44 kern_header zImage header Mar 07 18:54:55 cat header zImage > /dev/mtdblock2 Mar 07 18:55:00 that's it! Mar 07 19:00:05 ~hail rwhitby-away Mar 07 19:00:46 now the fun begins.... Mar 07 19:04:14 Does this also verify the flash? Mar 07 19:04:54 if [ $flash == ok ]; then reboot; fi Mar 07 19:05:49 nope, and if mtdblock2 has errors it will not find them. it's a quick and dirty, not the official way to do it Mar 07 19:07:24 can this not be compared with original? (kind of file compare) Mar 07 19:09:18 root@devslug:~# md5sum kernel.bin Mar 07 19:09:18 437df46ce11bb77d727181a461ed7f21 kernel.bin Mar 07 19:09:18 root@devslug:~# md5sum /dev/mtdblock2 Mar 07 19:09:18 90a5c3c67ad7cc58afbf3c195699e74d /dev/mtdblock2 Mar 07 19:09:39 trouble is that /dev/mtdblock2 is longer than what you write to it Mar 07 19:09:39 you forgot header Mar 07 19:09:48 kernel.bin includes header Mar 07 19:09:53 header + kernel is Mar 07 19:09:58 ok Mar 07 19:10:28 actually, scrub that - kernel.bin is the one where I ran out of room :-) Mar 07 19:11:05 root@devslug:~# cat header /boot/zImage-2.6.11 | md5sum Mar 07 19:11:06 347e1fbf3f482e568997658de5f26e88 - Mar 07 19:11:06 root@devslug:~# cat /dev/mtdblock2 | md5sum Mar 07 19:11:06 90a5c3c67ad7cc58afbf3c195699e74d - Mar 07 19:11:49 root@devslug:~# cat header /boot/zImage-2.6.11 | wc -c Mar 07 19:11:49 1036980 Mar 07 19:11:49 root@devslug:~# cat /dev/mtdblock2 | wc -c Mar 07 19:11:49 1048576 Mar 07 19:12:15 padding Mar 07 19:13:46 header + zImage + padding ==? /dev/mtdblock2 Mar 07 19:14:27 padding could be anything depending on what you had previously written to flash Mar 07 19:15:31 fill remaining space with zeros Mar 07 19:15:59 root@devslug:~# dd if=/dev/mtdblock2 bs=1036980 count=1 | md5sum Mar 07 19:15:59 1+0 records in Mar 07 19:15:59 1+0 records out Mar 07 19:15:59 347e1fbf3f482e568997658de5f26e88 - Mar 07 19:15:59 root@devslug:~# cat header /boot/zImage-2.6.11 | md5sum Mar 07 19:16:01 347e1fbf3f482e568997658de5f26e88 - Mar 07 19:16:21 YES! Mar 07 19:19:29 i hope my n00b-ish nonsense helped ;) Mar 07 19:26:22 ok, the feed is now 2.6.11 - you can update your rootfs with ipkg upgrade from there. Then flash the new kernel, reboot, and you're done. Mar 07 19:34:20 hmm - looks like we need diff installed in the base image so that ipkg upgrade will allow you to diff between the old and new versions of configuration files. Mar 07 19:36:14 ~84k Mar 07 19:42:08 crazy thought: can this be done from unslung? Mar 07 19:44:11 well, you can easily load the zImage and jffs2 image into a running unslung, and put them in /dev/mtdblock2 and 4. It may work Mar 07 19:48:26 easy upgarde/migration. very userfriendly Mar 07 19:49:11 but: how to migrate the packages (automagically)? Mar 07 19:49:18 we're not going to Mar 07 19:50:11 we migrate data, by keeping the default (but not required) disk partition scheme the same as unslung, and suggesting that people mount /dev/sda1 as /home Mar 07 19:50:34 but it's a fresh start for applications. OpenSlug does not carry any legacy from Unslung. Mar 07 19:51:24 bbiab (upgrading AccessSlug) Mar 07 19:55:53 running ipkg upgrade on AccessSlug now ... Mar 07 19:58:47 flashing new kernel .... Mar 07 19:59:47 root@nslu2:/boot# kern_header zImage-2.6.11 header Mar 07 19:59:47 root@nslu2:/boot# cat header zImage-2.6.11 > /dev/mtdblock2 Mar 07 19:59:47 root@nslu2:/boot# cat header zImage-2.6.11 | wc -l Mar 07 19:59:47 2816 Mar 07 19:59:48 root@nslu2:/boot# cat header zImage-2.6.11 | wc -c Mar 07 19:59:48 1036980 Mar 07 19:59:49 root@nslu2:/boot# cat header zImage-2.6.11 | md5sum Mar 07 19:59:51 347e1fbf3f482e568997658de5f26e88 - Mar 07 19:59:53 root@nslu2:/boot# dd if=/dev/mtdblock2 bs=1036980 count=1 | md5sum Mar 07 19:59:55 1+0 records in Mar 07 19:59:57 1+0 records out Mar 07 19:59:59 347e1fbf3f482e568997658de5f26e88 - Mar 07 20:00:02 root@nslu2:/boot# Mar 07 20:00:03 flash successful Mar 07 20:00:10 rebooting Mar 07 20:33:53 well, that didn't go as planned .... Mar 07 20:34:19 seems we need to have the kernel version as part of the ixp module package version Mar 07 20:34:46 otherwise the ixp modules are not ipkg upgraded, and therefore are not found on the reboot Mar 07 20:34:55 which means your slug has no network Mar 07 20:36:35 rebooting Mar 07 21:08:03 hi Mar 07 21:28:35 ok, AccessSlug is now updated to 2.6.11, and I've learnt a lot about what can go wrong with such an upgrade ..... Mar 07 21:29:56 and that's enough for tonight ... Mar 07 21:56:31 * dyoung-away gumble Mar 07 21:58:16 <[g2]> morning dyoung-away Mar 07 22:06:16 morning Mar 07 22:06:27 <[g2]> hi Mar 07 22:06:57 hey Mar 07 22:07:14 I just read your big conversation with rwhitby about the apex stuff. Mar 07 22:07:20 Is it close to reality? Mar 07 22:08:15 What's the IRC channel for APEX dev? Mar 07 22:08:32 openjtag Mar 07 22:08:38 thanks. Mar 07 23:02:20 * perlguru Leaving Mar 07 23:20:38 question...OE is really too heavyweight for me...would there be a benefit with me picking up the current codebase and basically continuing anyu2? Are there reasons why that code then couldn't be imported/merged with Openslug under OE? Mar 07 23:23:13 I ask because I seem to be responsible for a good bit of the work and I would prefer to get it squared away...but it isn't worth the effort if it won't fit within the OE/openslug framework. Mar 07 23:24:35 let me restate that...responsible for a good deal of the nslu2 specific driver code Mar 07 23:24:56 <[g2]> hi ka6sox-office Mar 07 23:25:01 <[g2]> hi kas11 Mar 07 23:25:10 hey, [g2] Mar 07 23:25:19 * [g2] was too quick on the tab-complete :) Mar 07 23:25:32 I would rebase on 2.6.11 Mar 07 23:26:27 I would look into using quilt as the patch system also Mar 07 23:27:06 kas11 is back! Mar 07 23:27:17 <[g2]> kas11, If you don't want to work with OE I understand that Mar 07 23:27:38 <[g2]> for kernel / driver work all you really need is the tool chain and the kernel source Mar 07 23:28:18 <[g2]> I think it'd be easy to make a tool chain available and also the kernel patches are pretty straight forward Mar 07 23:28:34 hiya, VoodooZ-work...I've been around...but they were keeping this place a secret from me ;) Mar 07 23:28:59 <[g2]> rwhitby was *very* close last night on a kernel reflash update procedure from the OpenSlug command line Mar 07 23:29:16 <[g2]> or you could load via tftp Mar 07 23:29:40 I think I have a working OE toolchain... Mar 07 23:30:08 <[g2]> well you just need to pull and bb openslug-image Mar 07 23:30:29 <[g2]> and wait a little while in between :) Mar 07 23:30:52 I debug from ram...it is just so much faster...I can turnaround in about 2 minutes Mar 07 23:31:24 <[g2]> You've made some very important contributions it's a great pleasure to have your assistance and help Mar 07 23:31:46 I have this thing about understanding what the hell I am doing...big black boxes just don't do it for me Mar 07 23:32:06 <[g2]> I think very soon, we may tag the release and it could be pretty stable then Mar 07 23:32:59 there is no sense in doing anything if it won't help with openslug... Mar 07 23:33:03 hi folks! Mar 07 23:33:21 <[g2]> siddy, Welcome ! Mar 07 23:33:32 kas11: Don't worry I just found out about this channel yesterday! Damn! No wonder it was so quiet in nslu2-linux! :) Mar 07 23:33:39 thx! I see you're trying to find that ehci-problem? Mar 07 23:33:41 if ya'll think you pretty well have it whipped, no prob... Mar 07 23:34:00 <[g2]> siddy, getting closer Mar 07 23:34:27 <[g2]> beewoolie thinks there's code in the ehci.h file Mar 07 23:34:52 [g2], it looks very strange, we get an interrupt we didn't activate. Mar 07 23:36:03 STS_FLR that is ("frame list rolled over"). I can't really explain why this thing is triggered without beeing activated in ehci_start. Mar 07 23:36:04 <[g2]> I'd have to check the logs, but iirc I think we getting and interrupt in the middle of interrupt processing and it should have been locked out Mar 07 23:42:29 [g2] so you are saying that you are ready to release a beta once you run down the cause of the ehci IRQ problem? Mar 07 23:43:15 <[g2]> kas11, that and verifying we can ship the Intel NPE binary drivers. Mar 07 23:43:55 <[g2]> and we can ship Beta for usbnet without the Intel, but that's not likely Mar 07 23:45:03 <[g2]> I'm sure there are some bugs in the sw, but it's really pretty stable except for the EHCI issue Mar 07 23:45:30 <[g2]> siddy, were you they guy that did the 50-hour torrent torture test on 2.6.11 the other day ? Mar 07 23:45:35 the csr has been a can of worms from day 1 Mar 07 23:45:46 [g2], yes. it crashed. :( Mar 07 23:45:46 <[g2]> nod. Mar 07 23:46:01 <[g2]> right after 50 hours Mar 07 23:46:37 [g2], well, approximately 50 hours, yes. I did some reboots in the middle, but overall just over 2 days. Mar 07 23:47:00 (which is far better than 2.6.9 btw) Mar 07 23:47:09 <[g2]> my point is that it's beta ready Mar 07 23:47:24 <[g2]> not production ready Mar 07 23:47:34 <[g2]> but not bad for the first beta Mar 07 23:48:37 <[g2]> kas11, I'd say we are about 75-80% of the way there to a full Release Mar 07 23:48:54 I still believe the PCI IRQ stuff is broken in 2 places Mar 07 23:49:17 <[g2]> the irq mapping is one right ? Mar 07 23:49:35 yes...and in irq2gpio Mar 07 23:58:41 <[g2]> kas11, does irq2gpio enable an extra interrupt ? Mar 07 23:59:21 thats what it looks like to me Mar 07 23:59:43 <[g2]> Ok I see 13 interrupts enable 0-12 **** ENDING LOGGING AT Mon Mar 07 23:59:56 2005