**** BEGIN LOGGING AT Fri Oct 20 02:59:58 2006 Oct 20 03:02:04 rwhitby: welcome back :-) Oct 20 03:02:25 rwhitby: did you get my last message about the SERCOMM header ? Oct 20 03:02:27 dumfrac: those 01- and 02- patches are *not* in our 2.6.19 SVN kernel repo. Where did you get them from? Oct 20 03:02:41 dumfrac: nope, this hotel internet connection keeps crapping out. Oct 20 03:02:43 from 2.6.18 Oct 20 03:03:19 rwhitby: the message was, is the start of the microcode location in the flash image supposed to have a SERCOMM header ? if so, slugimage has written the microcode to the image correctly Oct 20 03:03:52 http://svn.nslu2-linux.org/svnroot/kernel/trunk/patches/2.6.18/ Oct 20 03:05:05 yes, it is supposed to have a header, but the previous payload option didn't, so that could easily be a bug. Oct 20 03:05:10 what are you seeing? Oct 20 03:05:57 ok, I think the reason we didn't bring those patches to 2.6.19 is cause of the uncertainty of the FF break Oct 20 03:06:02 (instead of continue) Oct 20 03:06:03 the header is there, and it has the correct size Oct 20 03:06:42 so what's wrong then? Oct 20 03:07:00 oh, you said "correctly" Oct 20 03:07:13 I read it as "incorrectly" for some reason :-) Oct 20 03:07:38 so you're confirming correct operation. Good, cause I remember testing that. Oct 20 03:08:00 (we need the header so devio knows how much to read out) Oct 20 03:08:00 i was just checking that it was supposed to be there :-) yes, it looks like slugimage is working correctly Oct 20 03:08:04 ah right ! Oct 20 03:08:24 btw, from the irc logs on 2006.10.18: 12:36.10 blaster8 hack-of-the-day time :) Oct 20 03:08:50 what's that refer to? Oct 20 03:08:53 i think that they were discussion a solution to the 02-redboot-partition.patch problem :-) Oct 20 03:09:31 looking at redboot source now Oct 20 03:11:07 img->name[0] = (unsigned char)0xFF; Oct 20 03:11:08 fis_update_directory(); Oct 20 03:11:41 is this in the delete routine ? Oct 20 03:11:45 yes. Oct 20 03:12:05 hmm... so FF marks a partition as deleted ? Oct 20 03:12:07 so a delete of a block in the middle of the directory does not reclaim the space. Oct 20 03:12:10 correct. Oct 20 03:12:55 what i still don't understand is why the redboot parser doesn't ignore a paritition if the checksum isn't correct Oct 20 03:13:07 and redboot will read for the complete fisdir_size, skipping entries with 0xFF Oct 20 03:13:26 dumfrac: the kernel redboot parser does not use the checksums. Oct 20 03:13:38 ah - maybe it should :-) Oct 20 03:13:43 it's probably a "feature" Oct 20 03:14:15 well, this is a fly in the ointment for the microcode in the last block idea. Oct 20 03:14:24 it seems that using the checksums would be a way to make it work - i wonder how hard that is to implement Oct 20 03:14:24 and the apex environment in the last block idea too. Oct 20 03:15:58 trouble is that it's not a change that you can count on being there. Oct 20 03:16:23 and having the kernel read extra partitions starting at offset zero is fatal to redboot Oct 20 03:16:41 (jacques got a bricked slug by that with a very early slugimage prototype) Oct 20 03:16:51 i'm not following - what change can't one count on being out there ? Oct 20 03:17:12 you can't count on the kernel you are loading to have the change in it. Oct 20 03:17:24 ah Oct 20 03:17:39 So someone could flash an image with microcode in it, and then load an earlier kernel with the linksys firmware rootfs, and get a bricked slug. Oct 20 03:17:43 are there other first byte markers that redboot uses ? Oct 20 03:17:57 none other Oct 20 03:18:02 just FF for deleted Oct 20 03:18:06 tricky Oct 20 03:19:16 so each entry is 256 bytes, right? Oct 20 03:19:40 yes - i think that's what i determined from the fis header structure Oct 20 03:19:49 fis entry structure Oct 20 03:19:51 unfortunately that's way too small, even if we used apex skip regions. Oct 20 03:20:54 ok, I'm going to need to think about this one, and talk with Martin and Marc. Oct 20 03:21:33 (and remove that option from slugimage svn) Oct 20 03:22:17 ok - i need to go to sleep - early start - i'll let you know if i come up with any ideas Oct 20 03:23:11 03rwhitby * r74 10slugimage/trunk/slugimage: Removed the microcode option, as it seems that 0xFF does not terminate the FIS directory, it only disables that entry and other entries following it are still considered valid. Oct 20 03:23:32 I'll send out an email about it. Oct 20 03:23:43 thanks - that was my next question Oct 20 03:24:08 signing off for now Oct 20 03:49:56 03rwhitby * r504 10kernel/trunk/patches/2.6.18/ (02-redboot-partition.patch series): Removed 02-redboot-partition.patch - this is not a valid patch as it conflicts with the behaviour of the redboot source. 0xff denotes a deleted entry only which should be skipped, not the end of the directory. Oct 20 03:54:41 03rwhitby * r505 10kernel/trunk/patches/2.6.19/ (02-redboot-partition.patch series): Removed 02-redboot-partition.patch - this is not a valid patch as it conflicts with the behaviour of the redboot source. 0xff denotes a deleted entry only which should be skipped, not the end of the directory. Oct 20 03:59:34 03rwhitby * r506 10kernel/trunk/STATUS: Removed 02-redboot-partition.patch and updated the status for 01-mtdpart-redboot-config-byteswap.patch Oct 20 09:01:16 anyone know if there is an apache for openslug? ipkg appears to find a package but gets a 404 Oct 20 12:11:20 rwhitby: alive? Oct 20 12:12:01 yep, barely. Oct 20 12:12:17 (jet lag induced 3.5 hours sleep last night) Oct 20 12:12:22 ouch Oct 20 12:12:26 anywhere nice? Oct 20 12:12:34 nope. Chicago :-) Oct 20 12:12:37 heh Oct 20 12:13:59 i have the fix for the wiki left hand search bug Oct 20 12:14:07 its just a one liner, if you get the chance Oct 20 12:15:33 go for it. Oct 20 12:15:42 someone in the code for the search box is this Oct 20 12:15:46 *somewhere Oct 20 12:15:57 it needs changing to Oct 20 12:19:29 done and works. Thanks! Oct 20 12:19:51 np Oct 20 12:19:59 it was bugging me ;-) Oct 20 12:22:06 rwhitby: do you use thttpd on openslug at all? Oct 20 12:22:27 not at the moment, no. Oct 20 12:22:58 my fellow slugger us openslug, couldnt find/get an apache working for it and used thttpd - but it borks on serving large files (>1gb) Oct 20 12:23:02 *uses Oct 20 12:26:23 * rwhitby gives barnseenio public accolades for fixing the wiki search ... Oct 20 12:29:48 wb Oct 20 12:31:05 crappy hotel internet connection Oct 20 12:31:27 aha Oct 20 13:12:46 Thank you barnseenio! Oct 20 13:13:21 (Hey!!! Chicago is a nice place! :p) Oct 20 13:13:24 thanks :) Oct 20 13:13:54 mwester: Chicago is probably nice when it's not cold and you have more than 48 hours to enjoy it :-) Oct 20 13:14:23 hehe! And you're tired of winter and cold weather by now I'll bet! Oct 20 13:14:44 You're heading back this afternoon? Oct 20 13:15:21 Travel safely! Oct 20 13:18:33 thx Oct 20 13:18:47 24 hours to get here, 48 hours here, 24 hours to get home :-( Oct 20 13:31:52 no problem mwester Oct 20 15:34:15 barnseenio: besides apache and thttpd, you can also try lighttpd, cherokee, or nginx Oct 20 20:13:41 thanks eno, my friend got apache going in the end - it was a bunch of binaries, he found somewhere, rather than a package Oct 20 20:15:14 openslug.org and unslung.org might experience some hiccups as I change registrars on them... apologies to anyone affected Oct 20 20:22:55 ByronT: just a big thanks for doing this all! Oct 20 21:20:05 03bzhou * r4258 10optware/trunk/make/py-4suite.mk: py-4suite: upstream released 1.0 Oct 20 23:23:48 hi :> I am porting my project to the nslu2; does anyone know how to handle the rpl_malloc problem? autoconf generates the replacement automatically if it things that the build is not made vs. a GNU C library; what would be the way to handle that correctly? are replacement functions needed? Oct 20 23:49:11 Jin^eLD: which firmware? Oct 20 23:50:37 if optware, look at make/cherokee.mk for example Oct 20 23:51:42 search alloc in that file Oct 20 23:52:22 eno: no idea, I do not have a device, I have to ask the guy who is testing that for me Oct 20 23:52:47 ok, I will pass that info to him Oct 20 23:53:02 I know he is using Openslug/Unslug Oct 20 23:53:51 eno: would it make sense to add an option to configure which enforces that malloc will not be redefined? Oct 20 23:53:51 in the case of openembedded, one of the conf file should handle it already Oct 20 23:54:14 I found some wiki which suggested doing that Oct 20 23:54:32 that's what make/cherokee.mk does Oct 20 23:54:54 aha.. this cerokee.mk is part of the dev environment? Oct 20 23:55:40 $ grep alloc make/cherokee.mk ac_cv_func_malloc_0_nonnull=yes \ ac_cv_func_realloc_0_nonnull=yes \ Oct 20 23:55:55 ok I see Oct 20 23:55:57 it's another app Oct 20 23:56:04 aaah, ok Oct 20 23:56:08 that can serve as an example Oct 20 23:56:39 ok I understand, I actually wanted to do the same but make it an optional argument Oct 20 23:57:01 is there any way to detect that the build is being made for the nslu2, so I enable this feature automatically? Oct 20 23:57:50 openembedded handle this automatically, in optware you'll use ifeq in the .mk file Oct 20 23:58:47 hmm... actually I could install the whole environment and do the port myself, and then just let him test Oct 20 23:59:03 don't know why the idea did not come to my mind earlier Oct 21 00:00:22 anway, thanks for the hints Oct 21 00:00:30 np Oct 21 00:01:07 does anything else comes to your mind, anything important? things that I could add to my configure script in order to make it easier to cross compile? Oct 21 00:01:48 when cross compiling, you better do a native configure first Oct 21 00:02:06 then tweak the cross configure so that it has the same config.h output Oct 21 00:02:51 the actual process varies from one app to another Oct 21 00:02:55 I see Oct 21 00:03:05 well. configure is really a pain... I spent weeks with it Oct 21 00:03:07 :) Oct 21 00:03:15 but it is really good for multiplatform support Oct 21 00:03:58 my configure.ac is about 1000 lines already Oct 21 00:04:23 if your friend is working in openslug, then optware is not targeting that Oct 21 00:05:41 EXTRA_OECONF is the equiv in oe Oct 21 00:05:54 or EXTRA_OECONF_append_armeb Oct 21 00:05:55 03g2-tbillman * r507 10kernel/trunk/patches/2.6.18/ (02-mtdpart-redboot-byteswap-partition-truncate.patch series): Oct 21 00:05:55 1st cut for upstream RedBoot.c partition changes. This includes two changes which might be split out depending on Oct 21 00:05:55 feedback from mtd-linux. Oct 21 00:06:36 hmm Oct 21 00:07:27 to be honest I did not understand much of the last lines; probably because I am completely new to #oe/etc. Oct 21 00:08:07 I will definetely have to look into that Oct 21 00:10:49 look at openembedded/site/armeb-linux may help Oct 21 00:11:03 thanks! Oct 21 00:39:22 03g2-tbillman * r508 10kernel/trunk/patches/2.6.18/02-mtdpart-redboot-byteswap-partition-truncate.patch: Fix type in patch path. Oct 21 00:59:34 [g2]: I'll test 01-mtdpart-redboot-config-byteswap.patch this evening - it may take a while as I don't have a very fast build machine - also, I'll be testing it with the Debian 2.6.18 kernel, but I don't think that will be a problem Oct 21 00:59:57 [g2]: btw, thanks for the work on this patch Oct 21 01:04:18 [g2]: i guess I mean that I'll test 02-mtdpart-redboot-byteswap-partition-truncate.patch :-) Oct 21 02:05:52 <[g2]> dumfrac thx Oct 21 02:06:23 <[g2]> dumfrac nice to meet you, I've seen you e-mails Oct 21 02:06:33 <[g2]> s/you e-/your e-/ Oct 21 02:06:34 [g2] meant: dumfrac nice to meet you, I've seen your e-mails **** ENDING LOGGING AT Sat Oct 21 02:59:57 2006