**** BEGIN LOGGING AT Thu Jun 28 02:59:57 2007 Jun 28 04:03:10 03bzhou * r6323 10optware/trunk/make/zile.mk: zile: 2.2.34 -> 2.2.35 Jun 28 04:32:32 I'm having some trouble getting a kernel greater than 2.6.17 to correctly parse my fis redboot partition. I noticed that the ecos-cvs revision puts the "Redboot Config" within the last block. Do you suppose this is causing a problem? Jun 28 04:48:52 Here is a the boot messages from different kernels I tried hoping to narrow down what changes affected my configuration. Notice how 2.6.16 works as expected, 2.6.17 kind of works and >= 2.6.18 don't work (again work as in parse redboot partition) at all. http://rafb.net/p/P8uepT12.txt Jun 28 06:04:41 jeffvr: which platform and firmware? Jun 28 06:06:16 jeffvr: that mtd output smells like wrong endianness to me. does your kernel have the patches in there that swap the FIS directory when required? Jun 28 06:43:18 rwhitby: I didn't apply any of the patches to swap the FIS directory when required. The system is running in Big endian mode. Jun 28 06:45:40 rwhitby: The platform is a custom build very similar to the nslu hardware. One big difference regarding flash is that I switched over to Spansion flash of 64MB. Jun 28 06:47:49 rwhitby: I recall this patch your referring too. I'll go take a closer look at the description. Do you recall if this was something that was needed for >=2.6.17 Kernels when running in BigEndian mode? Jun 28 06:52:49 jeffvr: it depends in which endianness you flash the FIS directory (or which endianness your bootloader is) Jun 28 06:55:17 The bootloader is Big Endian. Jun 28 06:55:52 are you flashing the fis dir, or is the bootloader writing it? Jun 28 06:57:02 The bootloader is writing it. I issue an "fis init" command and redboot creates the fis partition in the last block. Jun 28 06:57:47 I was kind of concerned with the physmap driver's abilities to parse the fis partions when redboot puts the config at the end of this block. Jun 28 06:59:41 I checked older redboot configurations and they had a seperate partion. I didn't see an obviouse way to override this in the redboot commands. Do you think that could be an issue? Jun 28 07:02:01 To try and be as clear as possible the fis directory starts at 0x53FE0000 and the Redboot config starts at 0x53FFE000. Jun 28 07:26:13 03oleo * r6324 10optware/trunk/ (make/openobex.mk platforms/packages-openwrt-brcm24.mk): openobex: add pkg-config search PATH Jun 28 07:50:52 It looks like a patch was made for supporting the FIS directory and the redboot configuration in the same block has been dealt with. Jun 28 07:50:59 http://lists.infradead.org/pipermail/linux-mtd-cvs/2006-December/005679.html Jun 28 07:56:09 This patch is in 2.6.21.6 which I tried as well and had the same results as 2.6.18 even thought 2.6.18 didn have this patch . So my problem must be related to the probe error. Jun 28 07:56:28 http://rafb.net/p/P8uepT12.txt Jun 28 08:00:31 jeffvr: fis and config in a single block is a common situation (but not one that we deal with in any of the devices that nslu2-linux supports) Jun 28 08:01:34 the 2.6.17 log you've got there is the classic "ran off the end of the fis directory and started treating config as partition entries' problem Jun 28 08:01:47 as for the 2.6.18 - dunno why that isn't working. Jun 28 08:02:03 (forget what I said about endianness - I misread the 2.6.17 failure) Jun 28 08:02:43 jeffvr: did you change flash chip between 2.6.16 and 2.6.18 ? Jun 28 08:03:57 03oleo * r6325 10optware/trunk/ (4 files in 3 dirs): joe: do not link with c99 when not available Jun 28 09:05:18 waiting for openwrt-brcm2 feed ... Jun 28 09:14:37 oleo: who are you waiting for, to do what? Jun 28 09:15:14 maybe you or eno. duno. Jun 28 09:15:52 has the toolchain and set of packages been fully built on nudi? Jun 28 09:16:27 (eno does that, then I set up the feed on the mirrors, then the packages are pushed to the feeds) Jun 28 09:16:48 yes. http://trac.nslu2-linux.org/optware/changeset/6308 Jun 28 09:18:46 ok, eno and I will need to coordinate now Jun 28 09:19:44 I've don some cleanups then. The only thing that bothers me is that somehow rpath does not work for me. I am using ldconfig or LD_LIBRARY_PATH=/opt/lib to solve this. Jun 28 09:19:56 any suggestion? Jun 28 09:20:16 gtg Jun 28 09:21:51 you must get rpath to work Jun 28 09:22:00 LD_LIBRARY_PATH is not used in Optware Jun 28 10:52:25 03oleo * r6326 10optware/trunk/ (4 files in 2 dirs): transmission: r2199->r2220 - some check waiting fixes Jun 28 11:20:19 I do not have idea why RPATH does not work on openwrt-brcm24 Jun 28 11:20:57 I've checked for example readelf -d zsh|grep RPATH and got Jun 28 11:21:07 0x0000000f (RPATH) Library rpath: [/opt/lib] Jun 28 11:21:54 So binaries do have this compiled in. Jun 28 11:28:46 If for example I check root@oleo:/opt/bin# ./ldd wc Jun 28 11:28:46 libiconv.so.2 => not found Jun 28 11:28:46 libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2aaed000) Jun 28 11:28:46 libc.so.0 => /lib/libc.so.0 (0x2ab3c000) Jun 28 11:28:46 ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x2aaa8000) Jun 28 11:29:38 unless I configure LD_LIBRARY_PATH or /etc/ld.so.conf with ldconfig Jun 28 11:36:20 I think that tis is not problem with my build but with openwrt loader. strace ./wc --help shows Jun 28 11:36:31 execve("./wc", ["./wc", "--help"], [/* 9 vars */]) = 0 Jun 28 11:36:31 svr4_syscall() = -1 ERRNO_4090 (Unknown error 4090) Jun 28 11:36:31 stat("/etc/ld.so.cache", 0x7fff7ad8) = -1 ENOENT (No such file or directory) Jun 28 11:36:31 open("/lib/libiconv.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) Jun 28 11:36:31 open("/lib/libiconv.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) Jun 28 11:36:31 open("/usr/lib/libiconv.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) Jun 28 11:36:33 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aaae000 Jun 28 11:36:35 write(2, "", 0) = 0 Jun 28 11:36:37 write(2, "./wc", 4./wc) = 4 Jun 28 11:36:39 write(2, ": can\'t load library \'", 22: can't load library ') = 22 Jun 28 11:36:41 write(2, "libiconv.so.2", 13libiconv.so.2) = 13 Jun 28 11:36:43 write(2, "\'\n", 2' Jun 28 11:36:45 ) = 2 Jun 28 11:36:46 munmap(0x2aaae000, 4096) = 0 Jun 28 11:36:49 exit(16) = ? Jun 28 11:36:51 Process 15601 detached Jun 28 11:37:08 rwhitby eno: any suggestions? Jun 28 11:45:37 OK. I've found answer myself. .config:# LDSO_RUNPATH is not set in openwrt config. So there is no hope that rpath will be bused unless openwrt guys change uClibc config. Jun 28 11:46:15 What can we do? Jun 28 11:52:13 Kaloz : Can you comment this? Jun 28 12:07:10 03oleo * r6327 10optware/trunk/Makefile: iftop: add include/ncurses search path Jun 28 12:15:25 oleo: but you force a certain location with -rpath, right? Jun 28 12:18:46 yes. Jun 28 12:19:43 with LDFLAGS+=-Wl,-rpath,/opt/lib Jun 28 12:23:58 does that affect prelinking in any way? Jun 28 12:24:14 uClibc .config LDSO_RUNPATH is not set and thus RPATH is ignored in openwrt/trunk/toolchain_build_mipsel/uClibc-0.9.28.2/ldso/ldso/dl-elf.c:#ifdef __LDSO_RUNPATH__ Jun 28 12:24:51 read and understood that :) my question is if it affects prelinking or not :) Jun 28 12:24:59 I want to look into that soon Jun 28 12:25:49 I can set LD_LIBRARY path. And I've built ldconfig of mu own and solved the problem also with /etc/ld.so.cache Jun 28 12:26:48 But that is not the point. Library clash can occur if app cannot set its rpath. Jun 28 12:27:21 well, with prelinking you tell the binary where to look for the libs Jun 28 12:27:41 (so maybe prelinking would simply solve the rpath thing?) Jun 28 12:28:36 I must confess that I doo not understand what do you mean with prelinking. Jun 28 12:28:58 http://crast.us/james/articles/prelink.php Jun 28 12:29:02 http://en.wikipedia.org/wiki/Prelinking Jun 28 12:29:05 or that one Jun 28 12:30:24 Kaloz: note that none of the standard openwrt apps will be compiled with -rpath, so it won't affect any prelinking plans at all Jun 28 12:30:52 rwhitby: sure thing. this is why I've said I leave the decision up to mbm or nbd Jun 28 12:31:04 rwhitby: what i'm trying to figure out if it would be redundant or not Jun 28 12:31:19 (eg. if you cna prelink to a certain file at a certain location) Jun 28 12:32:11 oleo: what is the size penalty of enabling LDSO_RUNPATH in uclibc library? Jun 28 12:32:56 size? I've seen 10 lines in dl-elf.c Jun 28 12:33:56 11 to be exact. Jun 28 12:36:52 Ok. I understand this prelinking now. Not sure if it works with uClibc. But This prelinking did not convinced me that this is a right way go. Jun 28 12:37:49 I didn't say it is. I'v just said it seems to be another way to go what can give us additional speedup Jun 28 12:37:55 bbl Jun 28 13:05:12 rwhitby: (regarding jeffvr's stuff earlier) the logs are from the same hardware; just trying different kernels Jun 28 13:23:54 Kaloz rwitby: there is no prelinking possible for uClibc. Not shure if it would help in any way. We are not running big apps with many DSOs in embeded world. Se we can do old plain search for libraries. And RPATH is imporatant mechanism for "out of core" apps to suggest its searches. Jun 28 13:30:27 Enabling LDSO_RUNPATH will not increase size of OpenWRT distros any my suggestion is to include it in .config. Jun 28 14:08:57 oleo: yeah, but we have way slower storage stuff, so this would help on the other way around.. shame it doesn't work (yet) Jun 28 14:12:06 So I can hope that Kemikaze would get LDSO_RUNPATH and ldconfig soon? Jun 28 14:13:07 hope dies last ;) but yeah Jun 28 14:16:02 Anyway I am missing C99 math suport too. I've tought to liftup my own uclibc toolchain with independent loader to Kamikaze. It works very well for oleg, ddwrt, whiterussian, ... Jun 28 14:18:20 we have most c99 stuff enabled - probably 1% of the people need the others Jun 28 14:18:33 well, we had at least last time i've checked Jun 28 14:18:51 but probably you should ask these questions on #openwrt-devel instead :) Jun 28 14:19:00 bbl again Jun 28 14:19:13 # DO_C99_MATH is not set Jun 28 14:19:41 ok. by Jun 28 14:23:12 rwhitby: openwrt-brcm24 packages are ready on nudi Jun 28 14:23:44 just read the log, looks like even the feed is open, openwrt needs some small fix Jun 28 14:24:23 oleo, please check in your latest make/iftop.mk Jun 28 14:30:24 03bzhou * r6328 10optware/trunk/make/py-paste.mk: py-paste: 1.3 -> 1.4 Jun 28 14:30:50 03bzhou * r6329 10optware/trunk/make/py-pastedeploy.mk: py-pastedeploy: 1.3 -> 1.3.1 Jun 28 14:31:15 03bzhou * r6330 10optware/trunk/make/py-pastescript.mk: py-pastescript: 1.3.4 -> 1.3.5 Jun 28 16:10:48 03gda * r6331 10optware/trunk/make/esniper.mk: esniper: 1-16-0 -> 1-16-1 Jun 28 17:55:10 eno: ok. will recheck iftop.mk Jun 28 18:01:50 oleo: thx. you probably have the fix already, just forgot to commit it. Jun 28 18:55:16 03gda * r6332 10optware/trunk/make/eaccelerator.mk: eaccelerator: force rebuild against new php version Jun 28 20:29:39 03oleo * r6333 10optware/trunk/make/iftop.mk: iftop: add ncurses search path - missing part to #6327 Jun 28 21:40:08 03bzhou * r6334 10optware/trunk/ (make/iftop.mk sources/iftop/ sources/iftop/big-endian.patch): iftop: shorter binary name & big-endian patch Jun 28 22:03:30 don't know what is wrong with my build environment, but I can't build the php-fcgi-ipk Jun 28 22:04:22 would be nice if someone could try to get iconv support into php-fcgi Jun 28 22:05:17 03bzhou * r6335 10optware/trunk/make/iftop.mk: iftop: only patch on big-endian platforms Jun 28 22:07:59 03bzhou * r6336 10optware/trunk/make/iftop.mk: iftop: force to look just for ncurses Jun 28 22:27:51 eno: ok, will add the feed dirs and start autobuild for them Jun 28 22:29:37 bye Jun 28 22:36:22 rwhitby: I have the 2.6.17 kernel patched with the combined FIS directory and configuration area. This fixed this kernel version for our hardware. Jun 28 22:39:36 So, this kernel version is recent enough even though I'm very curious about kernels 2.6.18 to 21. To date I've used the intel supplied NPE patches and would like to try the open source version from hohnstaedt.de. Jun 28 22:42:52 I compiled the version into the Kernel and cated the microcode into the device node. No luck though. I'm suspiciouse of some larger problem because the pro100+ pci card I'm trying to use for development doesn't work either?!? Loopback works though. :) Jun 28 22:49:17 jeffvr: there is an even newer version of the ethernet driver that we are using for 2.6.22 Jun 28 22:49:47 see our kernel svn repo: http://svn.nslu2-linux.org/svnroot/kernel/trunk/patches/2.6.22/ Jun 28 22:49:59 41 and 42 are the latest ethernet driver Jun 28 22:50:27 jeffvr: you're going to send us a free one of these boards you are developing, right ;-) Jun 28 22:55:18 Cool, I'll go check that out. Jun 28 22:58:48 As for the new board. It's a proprietary platform but if you wanted one I could probably get you one or two. I wouldn't be able to give you a schematic though, and without it a lot of the board isn't worth much. It does have quit a bit of ram (256MB) and flash(64MB) though. Jun 29 00:10:09 hey Im trying to get a ups manager running on the nslu2 w/ unslung firmware (like genpower) Jun 29 00:10:28 can anyone help? Jun 29 00:10:50 hallert: don't ask to ask, just ask. Jun 29 00:14:12 how would I go about compiling the source on a x86 gentoo box for the nslu2 Jun 29 00:32:55 hallert wasn't very patient ... Jun 29 00:33:18 some people seem to think we're just sitting here waiting to answer their questions ... Jun 29 00:35:04 oleo: openwrt core devs are happy to include LDSO_RUNPATH support - can you please send me a patch for review? Jun 29 01:51:35 rwhitby: i was trying to apply those 41/42 patches to our 2.6.17 kernel, but they didn't go cleanly Jun 29 01:51:56 opello: those patches are for 2.6.22 only Jun 29 01:52:13 when i fixed the hunks that failed, it wouldn't build; any suggestions for a kernel that old? 0.3.1 builds (shows 0.3.0 in the messages) but didn't seem to work after sending the firmware to the device node Jun 29 01:52:21 ah, makes sense :) Jun 29 01:52:23 we have patches that use Christian's driver in other dirs in that svn repo Jun 29 01:52:38 (note the 2.6.22 in the repo pathname) Jun 29 01:52:44 right, i saw Jun 29 01:52:49 figured i'd give it a try anyway Jun 29 01:54:06 my suggestion for a kernel that old is to update to a newer kernel ;-) Jun 29 01:54:21 heh yeah; we're still trying to get the flash working in those Jun 29 01:54:30 2.6.18 at least Jun 29 01:54:43 yeah, that's the best case scenario Jun 29 01:55:22 We only started using the open source driver at 2.6.18, and then the newer open source driver at 2.6.22 Jun 29 01:58:58 the only thing holding us back from 2.6.18 is this: http://rafb.net/p/uChCkx93.txt Jun 29 01:59:18 which we've been trying to figure out the changes from 17 to 18 in the mtd stuff, but haven't found anything obvious that would prevent the probe from succeeding Jun 29 02:00:47 did your flash chip change from 2.16.17 to 2.6.18 ? Jun 29 02:02:07 no, just trying different kerenl builds on the same hardware Jun 29 02:02:21 kernel* Jun 29 02:15:17 kind of strange :/ Jun 29 02:35:48 i applied the patch to fix the redboot config in the same block as the FIS configuration; but as i figured it didn't fix the flash chip probing Jun 29 02:41:08 rwhitby: any thoughts? i can't seem ti figure anything out Jun 29 02:41:27 what kind of flash chip is it? Jun 29 02:41:46 same as the nslu2? Jun 29 02:42:11 no :( it's a spansion 64mb chip Jun 29 02:44:15 just thought you might have some insight on other chips Jun 29 02:46:05 03bzhou * r6337 10optware/trunk/make/zile.mk: zile: 2.2.35 -> 2.2.36 Jun 29 02:51:40 03rwhitby * r879 10kernel/trunk/ (3 files in 2 dirs): Updated to 2.6.21.5 Jun 29 02:54:10 opello: nope, I have no insight into other chips. only thought would be to check the kernel defconfig to see if anything in that area changed for 2.6.18 **** ENDING LOGGING AT Fri Jun 29 02:59:56 2007