**** BEGIN LOGGING AT Tue Jan 17 02:59:58 2006 Jan 17 03:06:48 tbm: looks like mknod running under fakeroot on DebianSlug doesn't actually create character device nodes, but just plain files. Jan 17 03:07:06 and that causes my d-i initrd to not boot Jan 17 03:39:25 is there any fdisk replacement for unslung? or someone found out how to create partitions with it? Jan 17 03:42:05 actually nothing, I think I got it Jan 17 04:36:32 'morgen Jan 17 04:49:07 drif: it's on the wiki - custom partition sizes Jan 17 04:52:45 hmm Jan 17 04:54:01 the new zd1211 drivers are annoying Jan 17 04:54:31 They make a bunch of assumptions in the Makefile... Jan 17 04:55:14 rwhitby: do you know where the kernel source/headers are staged? Jan 17 04:55:27 or, is there a variable I can use that contains the path? Jan 17 12:07:00 NAIL: ${KERNEL_STAGING_DIR} Jan 17 12:07:46 tbm: my investigations last night showed that the stock LinkSys RedBoot ends up copying the zImage to address 0 (actually 0x6000000, but that's the same memory). This overwrites the parameters RedBoot puts at 0x100 for the kernel. Jan 17 12:08:22 Consequently although RedBoot exec -c ... does create the parameter list it gets overwritten - so if you are testing things using that it has no effect, the compiled in command line is used. Jan 17 12:10:03 jbowler: I had "root=/dev/ram initrd=0x01000000,10M" in the built-in command line. Would that be ok? Jan 17 12:15:12 tbm: it depends on exactly how you got the initrd loaded (i.e. exactly what RedBoot commands you used) Jan 17 12:15:49 I think that command line will look at +16MByte, which does exist Jan 17 12:17:02 jbowler: I used load -r -b 0x01000000 initrd.gz Jan 17 12:17:07 load -r -b 0x01d00000 kernel Jan 17 12:17:09 exec 0x01d00000 Jan 17 12:17:19 can you tell me what exatly I have to do to get it working? Jan 17 12:17:37 I can tell you what that does... Jan 17 12:17:52 The load should be fine - it should just set the memory to the contents of initrd.gz Jan 17 12:22:02 The exec sets the '[physical] starting address' to 0x1d00000, it then sets up an ATAG list at 0x100, overwrites it by copying the kernel to 0x0 (you can't prevent this, other than by using 'go') and branchs to the entry point (it says what that is just before it does so, but it should be 0x6000000). Jan 17 12:22:22 The latter is an alias for the memory at 0x0 Jan 17 12:23:14 I can't see anything there which would overwrite the initrd, but I guess it is possible the zImage decompressor does that. Jan 17 12:23:35 Since the zImage is at 0 it has to put the decompressed version somewhere else... Jan 17 12:25:38 The easy way to debug it is to dump the bytes at phys_to_virt(0x1000000) in the machine startup (that how I worked out that the ATAG overwrite is happening). Jan 17 13:23:56 hi can anyone help me if i try to make a update i always get this error : Connecting to ipkg.nslu2-linux.org[66.159.209.6]:80... failed: Address family not supported by protocol. Jan 17 13:23:56 Retrying. Jan 17 13:40:08 03jbowler * 10kernel/2.6.15/ (5 files): Jan 17 13:40:08 update machine fixup patches, remove loft one Jan 17 13:40:08 add a patch to byte swap the command line if required Jan 17 13:56:50 03repvik * r227 10/releases/OpenSlug-2.7-beta/openembedded/packages/meta/openslug-packages.bb: Remove groff from feed again. Jan 17 14:08:35 03jbowler * 10kernel/2.6.15/defconfig: Make CMDLINE generic in defconfig (remove the machine specific root stuff) Jan 17 14:13:19 03repvik * r228 10/releases/OpenSlug-2.7-beta/openembedded/packages/meta/openslug-packages.bb: Remove irssi from feed until it builds Jan 17 16:23:21 03marceln * 10unslung/ (make/digitemp.mk sources/digitemp/Makefile.patch): BUG FIX: No /opt/lib in rpath (digitemp_DS2490 not running) Jan 17 17:13:37 03bzhou * 10unslung/make/ion.mk: ion3 upstream upgrade to 20060107, builds fine, some day we'll be able to run it Jan 17 20:04:01 6 months since the last firmware, any news on unslung? **** ENDING LOGGING AT Wed Jan 18 03:00:03 2006