**** BEGIN LOGGING AT Mon Oct 17 02:59:56 2005 Oct 17 03:28:28 03rwhitby * 10debian/ (configs/nslu2_defconfig patches/linux-2.6.12-nslu2.patch): Updated to backported 2.6.14 patchset Oct 17 03:57:00 03rwhitby * 10kernel/2.6.12/40-missing-exports.patch: Added the missing-exports patch from openembedded Oct 17 03:57:55 03rwhitby * 10debian/patches/linux-2.6.12-nslu2.patch: Added the missing-exports patch from openembedded Oct 17 04:03:26 03rwhitby * 10kernel/2.6.12/40-missing-exports.patch: Fixed the missing-exports patch Oct 17 04:03:40 03rwhitby * 10debian/patches/linux-2.6.12-nslu2.patch: Fixed the missing-exports patch Oct 17 04:51:11 03koen 07org.openembedded.dev * rb7f6ccdd... 10/packages/libgpewidget/libgpewidget_cvs.bb: libgpewidget: update PV in the cvs .bb Oct 17 07:41:06 [g2], have you measured the current consumption of the 533Mhz Loft? Oct 17 07:43:52 03repvik * r220 10/releases/OpenSlug-2.7-beta/conf/distro/openslug-bbfiles.conf: Update openvpn from 2.0rc1 to 2.0. Fixes inline compiler bug Oct 17 07:43:54 <[g2]> VoodooZ_Log not yet Oct 17 07:44:16 <[g2]> but it shouldn't be too touch Oct 17 07:44:26 <[g2]> the 533 is cool enough to put my finger on Oct 17 07:44:29 ok, I was just day-dreaming about one and how much faster my vision stuff would be. Oct 17 07:44:41 jelle: The feed is recompiling now, so it should be up in ~10 mins Oct 17 07:44:52 the slug is already pretty hungry at .5 amp with all the extra junk on the board. Oct 17 07:45:21 Then again, these things are not designed for battery operation so... Oct 17 07:45:28 <[g2]> nod Oct 17 07:45:47 Just get a big enough battery :-P Oct 17 07:46:07 <[g2]> I did notice we've got the Indirect mapping of the PCI turned on by default Oct 17 07:46:14 hehehe. Not always possible unfortunately. more juice = more weight. Oct 17 07:46:34 <[g2]> I've been testing today without it Oct 17 07:47:37 What's the difference? Oct 17 07:47:47 I have no idea what indirect mapping is Oct 17 07:47:55 <[g2]> it's for the PCI mapping Oct 17 07:48:30 Any performance difference? Oct 17 07:50:07 [g2]: I had noticed that too ans asked here but got no answer Oct 17 07:50:38 given that the characteristics of the slug, direct mapping should b eok Oct 17 07:51:59 <[g2]> I don't have any hard data Oct 17 07:52:43 <[g2]> I've found the smoking gun with large files and thttpd Oct 17 07:53:10 can you compare the performances? Oct 17 07:53:27 <[g2]> dwery before and after ? Oct 17 07:53:32 yep Oct 17 07:53:40 <[g2]> it's really a little complicated Oct 17 07:53:58 yeah. I don't know which kind of benchmark could be used Oct 17 07:54:12 <[g2]> meaning one has to disable most or all daemons and have a really similar setup Oct 17 07:54:39 <[g2]> with the daemons running suff moves around by a few MBs each run Oct 17 07:55:02 <[g2]> so that means either lots of runs or a specially crafted test setup Oct 17 07:57:58 everything works fine with direct mapping? Oct 17 07:58:15 <[g2]> so far Oct 17 07:58:21 ok, I'll switch too Oct 17 07:58:34 <[g2]> I haven't run into any issue yet Oct 17 07:59:03 <[g2]> dwery I was thinking I'd write up a patch to make it run time selectable if its is setup in an initialization area Oct 17 07:59:22 mmmm Oct 17 07:59:41 <[g2]> then based on memory size one could set it up or not Oct 17 08:00:15 for memory do you mean RAM? Oct 17 08:00:20 <[g2]> in the NSLU2 and Initial Lofts it'd be off, but some future lofts with >64MB might turn it on Oct 17 08:00:31 <[g2]> yes Oct 17 08:00:36 I think we are talking about memory space in the PCI... Oct 17 08:01:04 not system memory Oct 17 08:01:56 <[g2]> right it's the mapping of the PCI window size Oct 17 08:02:30 <[g2]> I don't know if that's per devices or bus or what Oct 17 08:04:07 probably bus Oct 17 08:05:35 <[g2]> dwery I found the issue with thttpd and large files Oct 17 08:05:49 <[g2]> it mmaps the files up to around 1GB Oct 17 08:05:53 how? Oct 17 08:05:55 aaa Oct 17 08:06:00 <[g2]> so we wiind up swapping Oct 17 08:06:32 <[g2]> which is just totally crazy to me Oct 17 08:07:02 <[g2]> that reminds me I've got to go bug lennert about the swapping code Oct 17 08:45:52 the only pci device on the slug is the usb controller and it's addressing requrtements are quite low Oct 17 08:45:58 so i think direct addressing works just fine Oct 17 08:46:50 it seems it doesn't support fast back to back transfers Oct 17 08:48:06 [g2]: do you think there's space for optimizations? Oct 17 08:52:14 03jbowler * 10upslug2/ (configure.ac nslu2_upgrade.cc nslu2_upgrade.h pcap_wire.cc): Oct 17 08:52:14 Improved pcap_wire.cc which uses getifaddrs Oct 17 08:52:16 Improved Wire error which includes the provision of a .what message Oct 17 08:52:19 configure.ac checks for getifaddrs **** BEGIN LOGGING AT Tue Oct 18 05:18:59 2005 Oct 18 05:21:13 rwhitby: ok Oct 18 05:21:30 rwhitby: how's the installer work going? Oct 18 05:22:13 Jacmet: preseeding wasn't in sarge, so I either have to wait until we have armeb unstable to the point where I can compile the installer, or start back-porting features to sarge. Oct 18 05:22:33 rwhitby: why not do the work on arm instead? Oct 18 05:22:39 E.G. little endian Oct 18 05:24:20 Jacmet: that's why I'm getting the LE patches in place - so I can compile the correct LE kernel. Oct 18 05:24:32 rwhitby: or are you only interested in BE? Oct 18 05:24:37 rwhitby: Ok Oct 18 05:25:19 rwhitby: could you send a status mail to the dev list? I'm afraid I don't have time to actively monitor everything on IRC.. Oct 18 05:25:38 the list seems to have died lately Oct 18 05:26:06 dwery-away is pushing things upstream Oct 18 05:26:58 jbowler is making sure that ucslugc works both BE and LE Oct 18 05:27:29 rwhitby: I thought everything was pushed upstream by now (with the possible exception of the RTC)? What is missing? Oct 18 05:27:51 Jacmet: acceptance by upstream :-) Oct 18 05:27:57 rwhitby: true Oct 18 05:28:38 but in any case, I'm working on getting the same patchset into our debonaras feeds (be and le) as a kernel package Oct 18 05:29:36 rwhitby: ok, is the idea to remove the patches from OE and let OE use the ones from sf.net CVS? Oct 18 05:29:58 eventually, yes. once everyone is behind the patches in cvs Oct 18 05:30:22 jbowler is updating OE manually at the moment to make sure it's a staged, tested transition. Oct 18 05:30:29 rwhitby: ok **** ENDING LOGGING AT Tue Oct 18 05:31:02 2005 **** BEGIN LOGGING AT Tue Oct 18 05:32:10 2005 Oct 18 05:32:11 Jacmet: ok Oct 18 05:32:24 jbowler was also working on the npe stuff in OE Oct 18 05:32:30 rwhitby: yeah, so we better make sure we don't have multiple people doing the same work Oct 18 05:33:00 ok, I thought you were going to check in the NPE patches to sf.net cvs next to the kernel patches? Oct 18 05:34:18 Jacmet: I don't have the ability to test them, so I didn't want to check in something that I hadn't tested. Oct 18 05:35:05 it would be nice if we had all the kernel stuff located at one place instead of bits in cvs, others in OE, something in mailing lists, random web pages, .. Oct 18 05:35:09 rwhitby: ok Oct 18 05:35:23 the kernel stuff is afterall distribution independent Oct 18 05:35:43 yeah, that's the intention of the kernel cvs repository Oct 18 05:36:12 ok Oct 18 05:37:19 if you're able to test the NPE patches, feel free to add them to the kernel cvs repository Oct 18 05:37:21 rwithby: you have an ASUS WL-550 don't you? Oct 18 05:37:34 copperbeech: wl-500gx Oct 18 05:37:45 and wl-530 Oct 18 05:37:49 that's the one with USB 2.0 ? Oct 18 05:37:53 yep Oct 18 05:38:05 nice - gan't seem to get them anywhere over here (UK) Oct 18 05:38:14 managed to get hold of a wl-500g Oct 18 05:38:33 are you running oleg's firmware? Oct 18 05:38:38 are you using oleg's firmware to customise it? Oct 18 05:38:41 (and optware packages on that?) Oct 18 05:38:46 *jinx* Oct 18 05:39:11 yeah, I added the optware support to oleg's firmware. Oct 18 05:39:12 rwhitby: I'm not really that interested in the NPE stuff - I find the code ugly, it's under a crap license and I have a USB<>ethernet adaptor - but it's interesting for other people as it makes installation easier Oct 18 05:39:13 well I've got a slug at the moment and my trusty old netgear router is stillrunning fine - I'm getting one for my brother. Oct 18 05:39:28 rwhitby: E.G. I'm not that motivated to work on it ;) Oct 18 05:39:40 rwhitby: why are you btw not able to test the patches? Oct 18 05:40:02 Digging around at wl500.info, I'm really coming to appreciate the order of the NSLU2 wiki and all the people qwriting how-tos and documentation... Oct 18 05:40:07 Jacmet: not set up to run LE kernel yet Oct 18 05:40:20 They have some great forum's but I'm finding it hard to see what is 'official' Oct 18 05:40:37 rwhitby: but you'll be soon as you already checked in the patches Oct 18 05:40:42 copperbeech: yep, the difference was intentional :-) Oct 18 05:40:53 :-) Oct 18 05:41:01 Jacmet: yeah, we're just trying to get nslu2-linux.org back up again at the moment. Oct 18 05:41:03 rwhitby: are you happy with the wl500gx? I'm considering to buy one Oct 18 05:41:18 Jacmet: it's my production internet gateway Oct 18 05:41:32 I got rid of the wrt54g and wrt54gs to get the wl500gx Oct 18 05:41:40 rwhitby: part of the NPE patch is also needed for BE, isn't it? Oct 18 05:41:56 rwhitby: ok Oct 18 05:42:10 just out of intrest - why was the CFP on the Miniconf marked as Off-topic? Oct 18 05:42:15 Jacmet: to tell you the truth, all that NPE stuff is way above my head. if it didn't work, I wouldn't have a clue how to start debugging it. Oct 18 05:42:38 mithro: it was? by who? Oct 18 05:42:55 seemed right on topic to me. Oct 18 05:43:02 Subject: [nslu2-general] Offtopic: LCA 2006 Embedded Miniconf - Call For Participation Oct 18 05:43:03 Date: Mon, 17 Oct 2005 20:44:38 +0200 Oct 18 05:43:23 rwhitby: ok - we need one who's sufficiently knowledgable and motivated to do the work ;) Oct 18 05:43:31 we just have to find one ;) Oct 18 05:43:51 i didn't put the "Offtopic:" in there Oct 18 05:43:58 mithro: ok, I guess the nslu2-general guys felt it was offtopic there. it wasn't an end-user question Oct 18 05:44:10 it was definitely on-topic and unchanged on nslu2-linux Oct 18 05:45:45 Jacmet: yeah. that's the main problem I see with the LE work - we don't have the same level of confidence in the ixp le module as the BE version which we've been using for a year and are comfortable with. And most people will want to use the built-in ethernet. Oct 18 05:46:09 but that shouldn't stop motivated people working on it :-) Oct 18 05:46:36 rwhitby: True - we haven't been using v2.0 on BE before though Oct 18 05:46:58 rwhitby: but the best way to get confidence is to make a alpha/beta release so it can get some testing Oct 18 05:47:02 Jacmet: yeah, I'm a bit uncomfortable with that too until it has been tested more. Oct 18 05:47:36 rwhitby: I don't see any problem with it as long as it is clearly marked as alpha quality Oct 18 05:47:53 Jacmet: for the debian be stuff, I want to only change one thing at a time :-) Oct 18 05:48:40 rwhitby: did you get your usb<>ethernet adaptor working in LE? Oct 18 05:48:54 (i.e. keep with the debian 2.6.12 kernel, with known good nslu2 patches, and ixp modules that are well tested) Oct 18 05:49:15 Jacmet: that's the next step after getting the 2.6.12 kernel compiled with the 2.6.14 back-ported patchset Oct 18 05:49:45 I figure there's no point in just replicating what you have done, so I'm moving the ball upfield by using the latest patchset on the debian kernel source. Oct 18 05:50:02 I also want to start with the debian defconfig - that's tomorrrow's job. Oct 18 05:50:06 rwhitby: if you get it working we can do the installer work on LE (without the ixp stuff if needed) and port to BE once the unstable buildds are running Oct 18 05:50:52 Jacmet: that's exactly my plan Oct 18 05:51:10 rwhitby: Ok, where do I come in? What can I do to help? Oct 18 05:51:33 Jacmet: by updating your stuff to use the 2.6.12 kernel and the patchset from the cvs repo. Oct 18 05:51:47 (and starting with a debian defconfig) Oct 18 05:52:05 rwhitby: Ok, that should just be a simple recompilation Oct 18 05:52:26 rwhitby: I have been keeping an eye on dwery's patches, and I think they look fine Oct 18 05:52:49 rwhitby: do you have the installer build working with a nslu2 kernel/modules? Oct 18 05:53:00 yep, it's my back-porting of dwery's patches to 2.6.12 that I need tested Oct 18 05:53:19 yes, I have the BE installer from sarge working with ixp, but it needs serial due to no preseed support. Oct 18 05:53:47 I get the installer to produce a jffs2 image, and then put that together with the kernel with slugimage and SerComm it over to the slug Oct 18 05:53:57 rwhitby: so it should be easy to build it for unstable/LE with the same kernel source Oct 18 05:54:08 yep Oct 18 05:54:28 rwhitby: why jffs2 instead of the standard initd? Oct 18 05:54:31 initrd even Oct 18 05:54:49 Jacmet: so I could play with /preseed.cfg without having to reflash or reload things from redboot Oct 18 05:54:50 rwhitby: have you documented the build steps anywhere? Oct 18 05:55:00 Jacmet: "debian" module in nslu cvs Oct 18 05:55:32 rwhitby: reloading from redboot is easy though - don't you have a tftp server? Oct 18 05:55:36 rwhitby: ok Oct 18 05:55:50 I do, but I get bored typing load -r -v -b all the time :-) Oct 18 05:55:54 rwhitby: can I check in LE stuff to there? Oct 18 05:56:07 rwhitby: create a script ;) Oct 18 05:56:20 Jacmet: yes, feel free to add stuff to that repo Oct 18 05:56:34 ok Oct 18 05:56:39 i need to get around to updating the miniconf website Oct 18 05:57:33 rwhitby: I'll test the kernel tonight and write the results to the ml Oct 18 05:58:51 thx Oct 18 05:59:08 rwhitby: you're welcome Oct 18 05:59:12 can you test it with jbowler's latest upslug2 which does the LE stuff automagically? Oct 18 05:59:41 (or the devio scripts that he posted which do the prepends on vmlinuz) Oct 18 06:02:23 03justinp 07org.openembedded.dev * r1a138e22... 10/: Oct 18 06:02:23 efl, e17: update to newest versions Oct 18 06:02:23 - fixed e-modules build on amd64 Oct 18 06:02:23 - new options evas-xrender-x11 is not disabled for fb builds Oct 18 06:02:23 - stage new Evas_Engine_XRender_X11.h header Oct 18 06:02:24 - remove e-utils from e-image, currently broken Oct 18 06:02:47 rwhitby: hi Oct 18 06:03:05 dwery: g'day Oct 18 06:03:24 dwery: Jacmet is going to test the back-ported 2.6.12 patchset tonight Oct 18 06:03:34 great. I wished I had more time Oct 18 06:04:05 Is the wiki broken right now? I can only get the main page and nothing else. Oct 18 06:05:08 VoodooZ_Log: have you read the message on nslu2-linux? Oct 18 06:05:26 http://groups.yahoo.com/group/nslu2-linux/message/9462 Oct 18 06:06:22 rwhitby: the prepending of the le swap code and machine code setup is something that will be implemented in upslug? Oct 18 06:06:35 dwery: it's already in upslug2 Oct 18 06:07:16 oh. Oct 18 06:07:23 oops. Nope. just got in. still sipping my hot coffee. we'll check Oct 18 06:10:46 rwhitby: i can't see it. I mean the arm assembly code that should be prepended to the kernel.. ? Oct 18 06:13:37 dwery: I'm only relaying information - I haven't checked it myself as I can't use upslug2 from my vmware natted session. Oct 18 06:13:45 ack Oct 18 06:14:57 you've checked the latest upslug2 cvs ? Oct 18 06:15:03 yes Oct 18 06:15:06 but maybe it's delayed Oct 18 06:15:20 co with :ext: Oct 18 06:15:58 i think i did it, will check. Oct 18 06:17:20 jbowler wrote: "I've checked in the remaining changes for upslug2-9 (into the sourceforge Oct 18 06:17:21 CVS). Assuming this stuff works OK on Mac (with ./configure --libpcap) this Oct 18 06:17:21 will become release 9 and should remain stable for some time (all the LE Oct 18 06:17:21 handling is in there - 9 recognises a little endian kernel and does the Oct 18 06:17:21 right thing.)" Oct 18 06:17:44 I assumed the "right thing" stuff is what we are talking about. Oct 18 06:17:47 i think jbowlers is referring to writing the kernel in the correct way Oct 18 06:17:57 not prepending the kernel with machine swap code Oct 18 06:18:08 s/swap/le enable/ Oct 18 06:18:08 ah, ok. then there is another message with devio scripts to do that. Oct 18 06:18:18 yes, i saw that message Oct 18 06:18:27 i think it would be easire to have it in upslug Oct 18 06:18:40 I believe that's the plan Oct 18 06:18:43 the machine id code is required for both be and le Oct 18 06:18:47 yep Oct 18 06:19:13 but maybe not everyone will use upslug.. i.e. tftp kernel tests] Oct 18 06:19:15 I need to add it to slugimage too. Oct 18 06:19:32 but I need debian package devio before that .... Oct 18 06:19:44 need to ... Oct 18 06:19:45 yep. are you a debian dev? Oct 18 06:20:01 nope. but we will put it in the debonaras feed. Oct 18 06:20:17 (in parallel with me trying to get a package sponsor) Oct 18 06:20:40 note that the debonaras feed can include both BE and LE packages Oct 18 06:21:36 i'd need an i386 package :) Oct 18 06:21:52 debonaras feed can include those too :-) Oct 18 06:21:58 great :-D Oct 18 06:23:10 I can try building upslug2 again, didnt really work for me last time, but this is like 12-20 days ago. (building on i386) Oct 18 06:25:24 When the webpages are back up that is, my cvs foo is in the subzero range. =/ **** ENDING LOGGING AT Tue Oct 18 06:34:10 2005 **** BEGIN LOGGING AT Tue Oct 18 06:36:14 2005 Oct 18 06:36:44 but are you trying with current cvs or old version? Oct 18 06:38:28 cvs -z3 co upslug2 , after logging in. **** ENDING LOGGING AT Tue Oct 18 06:38:32 2005 **** BEGIN LOGGING AT Tue Oct 18 06:48:13 2005 Oct 18 06:48:28 widrone: don't think you'll require v4 anyhow.. Oct 18 06:48:36 dwery: I will Oct 18 06:48:40 rwhitby: ok Oct 18 06:48:43 thanks Oct 18 06:49:12 dwery: should be a no brainer - it already prepends the sercomm header Oct 18 06:49:47 Jacmet: you mean the byteswap script? Oct 18 06:50:21 eFfeM: monotone may be up now Oct 18 06:50:50 rwhitby, tnx, I'll give it a try Oct 18 06:52:21 wiki should be back up too (albeit it will be very slow for a while until the motherboard is fixed) Oct 18 06:54:44 i can confirm that the wiki is up (and indeed reacts slow) Oct 18 07:12:29 anyone know who looks after the apache package? Oct 18 07:17:33 dwery: yes Oct 18 07:18:39 i havent noticed the one i have now prepended the sercomm header :) Oct 18 07:20:34 dwery: the flashimage.py one does -> http://peter.korsgaard.com/articles/debian-nslu2.php#kernel-to-flash Oct 18 07:20:41 ah ok Oct 18 07:21:12 for testing purposes, i'd need a byteswap + machine id + le bit Oct 18 07:21:17 should i mix them ? :) Oct 18 07:21:19 dwery: I'll combine them into a single script with some commandline arguments to enable/disable stuff Oct 18 07:21:26 thanks! Oct 18 07:21:39 i use tftp for testing and upslug to flash Oct 18 07:21:47 dwery: you're welcome Oct 18 07:22:12 dwery: me 2 - or actually, I use tftp + flashimage.py for flashing Oct 18 07:23:24 but upslug would give me a complete image with a RedBoot fis table and everything I guess Oct 18 07:24:12 yes. and the fis table work really fine! Oct 18 07:25:49 dwery: ok Oct 18 07:27:19 why do we actually create the fis table? The Redboot build doesn't use it, and it kinda silly wasting a complete sector (128K) when we could just as wel hardcode it or provide it on the cmdline Oct 18 07:27:55 not that flash waste really matters for debian - but for the jffs2 based dists it would Oct 18 07:28:47 03hrw 07org.openembedded.dev * r5e3c9065... 10/: Oct 18 07:28:47 opie-console 1.2.1: CVS backported patch for OPIE bug #1647 Oct 18 07:28:47 - Opie-console doesn't respect scroll-bar on left side. Oct 18 07:29:49 hardcoding is wrong :) Oct 18 07:30:43 anyway, we will need a script to parse the mac addresses out of ht esysconf Oct 18 07:30:50 s/ht e/the/ Oct 18 07:31:57 dwery: ok, but what does sysconf have to do with the fis table? Oct 18 07:32:05 nothing Oct 18 07:32:16 the fis is here to avoid hardcondig Oct 18 07:32:29 it was an unrelated note Oct 18 07:33:19 dwery: well, hardcoding on the cmdline isn't that bad - you can just recompile the kernel if you want to change it - you'll have to flash a new kernel anyway to update the fis table with upslug Oct 18 07:34:25 yes, but having it non harcoded would allow an user to choice the layout, upload it with upslug and then use whatever kernel he wants without recompiling Oct 18 07:39:24 dwery: yes, at the expense of 128KB of flash - it's always a tradeoff Oct 18 07:39:41 of course. but given that 99% of user does not like to recompile the kernel :) Oct 18 07:39:49 the few who care could always hardcode Oct 18 07:41:27 dwery: but are normal users going to create a custom fis table and manually run upslug? Oct 18 07:42:30 there's a lot of people who is playing with embedded without knowing how to recompile.. i know that's bad.. but given the level of questions asked on l-a-k i'm not surprised Oct 18 07:42:44 upslug will create a fis automatically Oct 18 07:42:49 from a jffs file Oct 18 07:42:51 image Oct 18 07:43:27 dwery: ahh ok Oct 18 07:43:34 * Jacmet never used upslug Oct 18 07:43:42 want to report a build error on the head Oct 18 07:43:53 :D Oct 18 07:44:08 monotone: selected update target 5e3c9065200ccb7610d6d0a5bc70c6bf0983bb9f Oct 18 07:44:08 monotone: help required for 3-way merge Oct 18 07:44:08 monotone: [ancestor] packages/linux/nslu2-kernel/2.6.14/30-i2c-x1205.patch Oct 18 07:44:08 monotone: [ left] packages/linux/nslu2-kernel/2.6.14/30-i2c-x1205.patch Oct 18 07:44:08 monotone: [ right] packages/linux/nslu2-kernel/2.6.14/30-i2c-x1205.patch Oct 18 07:44:09 monotone: [ merged] packages/linux/nslu2-kernel/2.6.14/30-i2c-x1205.patch Oct 18 07:44:11 no external 3-way merge command found Oct 18 07:44:13 monotone: misuse: merge of 'packages/linux/nslu2-kernel/2.6.14/30-i2c-x1205.patch' : 'ccba459da602ef50e8a8b3b884ed99034cc72f89' -> '2ad451c13d171b14e6a5eae026bb1e879db9b9e7' vs '645dc172ea76f224e4d4a6aabe2a6e787370be8c' failed Oct 18 07:44:27 what did I do to deserve this :-) Oct 18 07:44:29 dwery: but given the limitations in the sercomm redboot there isn't much flexibility anyway - the kernel has to be at a fixed location and has a fixed size, and the initrd as well - the rest could be dedicated to jffs2 Oct 18 07:44:33 and how do I get rid of this? Oct 18 07:44:56 eh, this is of course for openslug Oct 18 07:46:22 Jacmet: I;'m not saying you should not be allowed to do this, i'm saying that for a normaluser it's easier to use upslug than recompiling the kernel with partition offsets in the command line. given the the slug ships with a sysconf area it would be fine to preserve it for a roll back and/or to use the configuration data within Oct 18 07:47:08 dwery: ok Oct 18 07:48:06 dwery: I still need to figure out why setting the cmdline in RedBoot doesn't work - it works with a standard RedBoot Oct 18 07:48:30 and as far as I could see in the sercomm patch they don't mess with anything related to that Oct 18 07:48:37 dunno.. i think i heard it was buggy... Oct 18 07:49:33 dwery: the problem is ofcause debugging it - with jtag it should be easy to dump the RAM contents right after exec Oct 18 09:07:05 rwhitby: why do you need 90-arm-le.patch in 2.6.12? Oct 18 09:07:06 does any of you have the eth LE patch somewhere close? all links seem dead to me Oct 18 09:07:41 ferrix: it's checked in to monotone (packages/ixp4xx and packages/ixp425-eth) Oct 18 09:26:49 jbowler: the patch isn't needed, and should be removed Oct 18 09:32:42 Some clarification is required I think, I'll post a status message to nslu2-developers Oct 18 09:57:03 03jacmet * 10kernel/2.6.12/90-arm-le.patch: not needed as upslug2 prepends the asm to do this Oct 18 09:59:45 jacmet: you need to prepend the sequence to the zImage before passing it to upslug2/slugimage/reflash Oct 18 10:00:32 jbowler: ok, I thought upslug2 did that Oct 18 10:00:41 I haven't looked into it yet Oct 18 10:02:48 No, that wouldn't be sufficient. Oct 18 10:03:38 jbowler: what wouldn't? Oct 18 10:14:26 jacmet: changes to upslug2 are not sufficient on their own - slugimage, reflash and the Debian installation script would need to be changed too. Oct 18 10:17:32 jbowler: ehh, if you say so - we are only talking about prepending the few instructions to fix up the machine id and (optionally) switch into LE, right? Oct 18 10:20:29 03hrw 07org.openembedded.dev * rf262fbec... 10/: Oct 18 10:20:29 openzaurus-3.5.4.conf: tweaked feeds list to use DISTRO_VERSION and added upgrades/${MACHINE} feed Oct 18 10:20:29 - kernel (or other machine specific) upgrades goes to upgrades/${MACHINE}/ feed Oct 18 10:20:29 which need to be named without "/" to protect ipkg from failing Oct 18 10:22:15 jacmet: yes, that's correct (two instructions for machine type, an additional 4 for LE) Oct 18 10:24:31 If it isn't done to zImage it has to be done everywhere that zImage gets used. Oct 18 10:38:19 03koen 07org.openembedded.dev * r0967efd0... 10/: powernowd: add 0.96, it doesn't have an initscript yet, though Oct 18 11:14:41 jbowler-away: ok, I would just do it to the zImage once Oct 18 11:45:32 rwhitby-nslu2: I don't see a defconfig in CVS for 2.6.12 anywhere? Oct 18 12:54:28 Jacmet: the defconfig I'm using for debian is in the debian cvs repo in configs. I want to move to one which is derived from ixp4xx_defconfig for the kernel repo. Note that the one in the debian repo needs to be derived from the debian ixp4xx defconfig too (at the moment it's the OE defconfig). Oct 18 12:56:01 jbowler-away: I thought we were going to change slugimage and reflash and the debian install scripts to do the devio prepend stuff. It just hasn't been done yet. Oct 18 12:59:34 Jacmet: the reason for using the FIS directory is because that last erase block has to be there anyway for the Sercomm trailer, and we don't want to hard-code a partition scheme in the kernel (as different distros will want different flash partition schemes). So it's a redboot table which the kernel reads (even though redboot itself doesn't read it). Oct 18 13:00:25 so there is now wastage of flash, for the nslu2 the last block cannot be used for anything else anyway. Oct 18 13:01:21 and nslu2 redboot doesn't support setting cmdline arguments. Oct 18 13:05:24 jbowler-away: ok, just read your email to -developers. so what i can do is get the debian kernel build scripts to do the prepend too. Oct 18 13:19:01 03rwhitby * 10debian/patches/linux-2.6.12-nslu2.patch: 90-arm-le.patch removed Oct 18 13:19:15 Jacmet: should 90-arm-le.patch be removed from 2.6.14 dir too? (you removed it from 2.6.12 only) Oct 18 14:14:24 rwhitby-nslu2: upslug2 supports a payload in the space between the FIS directory and the trailer, likewise it is possible to put stuff in the unused 'Ramdisk' partition. Oct 18 14:42:06 x1205 driver in Greg KH tree. Oct 18 14:47:26 03justinp 07org.openembedded.dev * r7b483e2e... 10/: Add missing patch Oct 18 15:15:33 jbowler-away: agreed. I mean't that the last block cannot be part of a ramdisk or jffs2 partition. Oct 18 15:16:20 (well, I guess it could be part of a ramdisk initrd which was carefully crafted to end just before the sercomm trailer) Oct 18 15:16:32 but it can't be part of a jffs2 partition Oct 18 17:29:15 hi Oct 18 17:55:27 Is the native tree fixed yet? Oct 18 18:12:10 ... Oct 18 18:14:57 hi Oct 18 18:26:41 03jbowler 07org.openembedded.dev * r94103b1b... 10/: ucslugc, openslug: add mdadm 1.12 to packages Oct 18 18:26:43 03jbowler 07org.openembedded.dev * r92098070... 10/: Oct 18 18:26:44 uclibc: add uClibc.machine, uClibc.distro + empty defaults in uclibc.inc Oct 18 18:26:44 - Change uclibc 0.9.28 ucslugc builds (only) to use the new mechanism Oct 18 18:26:44 - to select ucslugc arm and armeb config Oct 18 18:26:45 - There is no change to any build config (including ucslugc), just a Oct 18 18:26:47 - change in mechanism. Oct 18 19:18:48 Anyone know what stray syscall exit means? Oct 18 22:11:32 rwhitby-away: regarding fis table: ahh, I forgot about all this nonstandard sercomm stuff - another reason to update redboot / move to apex Oct 18 22:14:33 rwhitby-away: yes, I'll remove it from 2.6.14 as well Oct 18 22:27:50 03jacmet * 10kernel/2.6.14/90-arm-le.patch: not needed as we'll prepend the instructions to do this to the zImage Oct 18 22:31:12 rwhitby-away: are you sure that the redboot doesn't support cmdline? It has been in Redboot for ages and according to help exec it is supported Oct 19 00:51:43 03rwhitby * 10debian/Makefile: Added initial support for big vs little endian compiles. **** ENDING LOGGING AT Wed Oct 19 03:00:21 2005