**** BEGIN LOGGING AT Fri Nov 08 02:59:58 2013 Nov 08 09:36:57 gm bluelightning Nov 08 09:37:33 collie in its glory: http://pastebin.com/r6V20nFb Nov 08 09:38:30 morning ant_work Nov 08 09:38:44 \o/ Nov 08 09:39:39 SD/MMC should not be so hard Nov 08 09:40:12 here the key lineis : Using auto-unlock on power-up/resume Nov 08 09:41:22 I'll keep the misdetection-tests for winter holidays...moving on Nov 08 09:43:29 pls apply the patches then we'll ask lumag to send them upstream (will be much faster if from him ;) Nov 08 09:43:45 or from LinusW Nov 08 09:51:33 ant_work: done Nov 08 09:51:48 thx Nov 08 09:52:00 btw http://cgit.openembedded.org/ -> 502 Bad Gateway Nov 08 09:52:17 yes, I just complained to Khem about that Nov 08 09:52:42 since yesterday was behaving strange: to see the files youhad to click on RAW Nov 08 09:52:47 or PLAIN fwiw Nov 08 09:53:00 yes, that was the problem I originally reported Nov 08 09:53:09 khem fixed that but now it's as you see it Nov 08 09:53:13 fine ;) Nov 08 09:55:22 oops.. I didn't want to start a flame war with RP ;) Nov 08 09:55:41 I'll stay apart and let the others comment Nov 08 09:56:03 (I still have to test the fix btw) Nov 08 10:11:42 bluelightning: I'd like to get rid of the device-tables we have in meta-hh Nov 08 10:12:16 or alternatively long ago I've sent this patch http://patches.openembedded.org/patch/7729/ Nov 08 10:12:46 it is nonsense keeping our copy, all kernels > 2.6.30 have devtmpfs Nov 08 10:12:46 the question is do we still need it? Nov 08 10:12:57 for old kernels... Nov 08 10:13:07 right, and we haven't killed all old kernels yet Nov 08 10:13:42 there are still old devices I hope to support whose kernel changes never went anywhere near mainline (e.g. h2200) Nov 08 10:14:03 maybe one day I'll give up, but for now the dream is still alive ;) Nov 08 10:14:30 I seem to have read that h4xxx is mainline Nov 08 10:19:33 bluelightning: do you have the adapter for 3600 to read CF cards? Nov 08 10:19:39 somewhere? Nov 08 10:20:02 linusw would try -sato but I fear size is too big for MTD Nov 08 10:20:37 so maybe you coul try it instead.... Nov 08 10:21:54 yes I have an h3600 sleeve Nov 08 10:22:11 several of them actually Nov 08 10:22:52 need to dig out my box of that stuff Nov 08 10:34:10 I have 3 patches from linusw Nov 08 10:34:17 I'l ask him to send to the ML Nov 08 10:40:34 sent Nov 08 10:41:51 bounced :D Nov 08 10:44:33 ? Nov 08 10:44:46 ant_work: I've tried to subscribe anyway who knows maybe it will start working later today Nov 08 10:44:51 ah right Nov 08 10:45:09 subscription is mandatory for sending to OE lists Nov 08 10:45:19 sane Nov 08 10:45:52 but yet another password Nov 08 10:46:14 (I'm lazy n that regard) Nov 08 10:53:03 bluelightning: I've seen xserver is upgraded. We may try to get rid of the .bbappend as rburton said Nov 08 10:53:40 I'm a bit confused because kdrive was dead then revived Nov 08 10:57:11 kdrive was revived? Nov 08 10:58:12 now and then I think I see it in the commits Nov 08 13:03:17 bluelightning: did opie-snes work? Nov 08 13:05:35 there are sources around for GTK Nov 08 13:05:36 http://www.snes9x.com/phpbb3/viewtopic.php?f=8&t=3703 Nov 08 13:06:20 wel.. If you're having trouble, upgrade Compiz. Nov 08 13:10:35 maybe lumag knows what this patch means: [PATCHv5][ 1/5] fbdev: Add the lacking FB_SYNC_* for matching the DISPLAY_FLAGS_* Nov 08 13:10:46 Without that fix, drivers using the fb_videomode_from_videomode Nov 08 13:10:46 function will not be able to get certain information because Nov 08 13:10:46 some DISPLAY_FLAGS_* have no corresponding FB_SYNC_* Nov 08 13:10:52 Hello ant_work bluelightning Nov 08 13:10:58 hi there ;) Nov 08 13:11:27 where is that patch in question? Nov 08 13:11:45 lakml 2.02 pm cest Nov 08 13:13:07 cet now...since 2 weeks Nov 08 13:38:08 hi lumag Nov 08 13:38:19 ant_work: I haven't tested it in a very long time Nov 08 13:43:21 lumag: today I'll verify comadj & co Nov 08 13:43:34 this old readings are different than mines http://brooknet.no-ip.com/~lex/public/zaurus/serial/ Nov 08 13:43:48 mines http://logs.nslu2-linux.org/livelogs/kexecboot/kexecboot.20131102.txt Nov 08 13:47:40 bluelightning: I'll test soon Nov 08 13:51:36 hm comadj = 117 vs. COMADJ 9d (157) Nov 08 13:52:54 ok, I'll readd 0x00fe0000-0x01000000 : "angel stuff" Nov 08 13:58:44 ant_work, you can go to service menu and verify what comadj settings will work for you. Nov 08 13:59:43 maybe they changed some part Nov 08 14:00:58 heh, yes, on collie reflashing the old Sharp image doesn't rerstore that params Nov 08 14:01:22 but the settings are ok for Sharp ROM and for linux-2.6.31 so... Nov 08 14:02:00 ant_work, http://paste.debian.net/64671/ Nov 08 14:02:06 lumag: the regression appears with the transition 2.6.31 - 32 Nov 08 14:02:43 ah, ok, I'll add this Nov 08 14:03:04 do we have an image with working irda ? ;) Nov 08 14:03:49 Opie should work Nov 08 14:03:57 good Nov 08 14:04:20 With this patch after enabling discovery you should at least be able to discover this device. Nov 08 14:05:13 I'm still on serial console, though :/ Nov 08 14:18:54 ant_work, you can enable irda with ifconfig Nov 08 14:19:14 And discovery either with irattach or through procfs Nov 08 15:32:11 lumag: desesperate I'm grepping for ffff0051 Nov 08 15:32:25 ? Nov 08 15:32:27 lumag: uboot-> http://itee.uq.edu.au/~listarch/microblaze-uclinux/archive/2009/01/msg00005.html Nov 08 15:32:40 they get that during detection Nov 08 15:36:12 and about parallel bus: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/31501/focus=31735 Nov 08 15:39:17 It looks like in our case second cfi chip does not react to 'Q' command. Nov 08 15:41:26 Maybe address lines are wrong Nov 08 15:42:53 Hmm. No Nov 08 15:43:02 adressing is correct (according to service manual) Nov 08 15:50:11 lumag..hm.. I think we see the data contained in the flash then Nov 08 15:50:23 I don't think so Nov 08 15:50:33 is empty Nov 08 15:50:35 http://lists.infradead.org/pipermail/linux-mtd/2008-July/022252.html Nov 08 15:51:20 it is as you say: the second chip doen't get the query Nov 08 15:51:39 wrong address or maybe is reset before answering Nov 08 15:52:41 That is what I tried to counteract by asking you: Nov 08 15:52:49 1) to insert delays into cfi code Nov 08 15:52:56 2) by lowering timings in MSC0 Nov 08 15:53:25 yep, I have all the logs Nov 08 15:53:35 I'll test thi sas well Nov 08 16:58:33 lumag: once OE gitserver is up again pls check the new collie patches Nov 08 16:59:05 unlock is ok, verified on cold boot and reboot Nov 08 17:00:52 maybe you've missed it, this is the log with all the patches applied http://pastebin.com/r6V20nFb Nov 08 17:02:46 ant_work, ok Nov 08 17:04:19 would you readd the top partition or only during development? Nov 08 17:04:38 (not that many 'users' have collie now) Nov 08 17:10:40 bbl Nov 08 22:23:53 ant_home, hello Nov 08 22:24:05 Currently building collie kernel & initramfs, Nov 08 22:24:13 but looks good from overall POV Nov 08 22:44:27 hi lumag_ Nov 08 22:45:09 * ant_home rebuilding from scratch Nov 08 22:46:31 lumag_: you'll see failure on do_rootfs for ubi images. Ignore Nov 08 22:46:48 size is a bit too much Nov 08 22:46:57 kernel needs diet Nov 08 22:57:44 bluelightning: hi there Nov 08 22:57:53 hi ant_home Nov 08 22:58:12 do you know the actual way to avoid to build oversized images? Nov 08 22:58:42 or after, like sizecheck for kernel Nov 08 22:59:46 ROOTFS_SIZE ? Nov 08 23:10:17 I don't think we have an oversize check for images Nov 08 23:10:43 I believe there is a bug against me to add such a check for poky-tiny, so I guess that would mean adding that generic feature first Nov 09 00:00:35 ant_home, I'm currently reworking locomo support, so I'd suggest to postpone locomo-spi work for a couple of days. Nov 09 00:00:44 If you don't mind Nov 09 02:18:23 hmm Nov 09 02:18:28 what os use procd? Nov 09 02:19:22 if console=null then early init doesnt mknod. or do /dev/console.. it should go to /dev/null. Nov 09 02:33:13 how does kexecboot differ in this aspect? **** ENDING LOGGING AT Sat Nov 09 02:59:58 2013