**** BEGIN LOGGING AT Tue Aug 16 02:59:57 2011 Aug 16 09:46:29 Jay7, ping Aug 16 09:46:44 pong Aug 16 09:47:11 have you read last logs? Aug 16 09:48:05 I can think that th ekeymap patch does reorder he things and the strange keypresses we had are now filtered Aug 16 09:48:19 I can't imagine gcc4.6 does th emiracle Aug 16 09:49:10 * ant_work extracts crumbs and died insect shaking the keyboard upside down Aug 16 09:49:26 ant_work: did you mean our menu NULL problem? Aug 16 09:49:31 yes Aug 16 09:49:42 which is not reproducible now with keymap pathc Aug 16 09:49:51 the kernel built yesterday is immune. I tried 4-5 reboots Aug 16 09:50:30 iirc we had 3 event codes on keypress Aug 16 09:50:37 maybe the action was triggered Aug 16 09:50:59 ah, and the event rate is much better Aug 16 09:51:25 menu-scroll is ok Aug 16 09:54:04 hm Aug 16 09:54:17 try just build in same env but w/o keymap patch :) Aug 16 09:55:27 yes, and hope it freezes again Aug 16 09:55:30 btw Aug 16 09:55:46 -#define SCAN_INTERVAL<><------>(HZ/10) +#define SCAN_INTERVAL<><------>(HZ/20) Aug 16 09:55:55 this is the real difference Aug 16 09:56:08 I'll see if that can apply on clamshells too Aug 16 09:57:57 ant_work: may be gcc4.6? Aug 16 09:58:22 I can hardly think but I'll try Aug 16 09:59:05 btw, better to upload the working kernel on ltg ;) Aug 16 09:59:49 ah, an interesting issue Aug 16 10:00:02 as it is, oe-core images have a broken /boot Aug 16 10:00:11 there is zImage-2.6.23.3 Aug 16 10:00:25 but no symlink zImage Aug 16 10:00:41 so, as default in boot.cfg we expect /boot/zImage Aug 16 10:00:48 result: nothing Aug 16 10:01:13 (I thought kexec was broken and even applied part of the kexec-tools gcc4.6 patch :) Aug 16 10:01:28 we should put a warning there Aug 16 10:02:39 i.e. KERNEL = ENOFILE Aug 16 10:09:49 this will increase scanning time for one stat() per kernel Aug 16 10:15:20 so what's this keymap patch? do we now have sane keypresses? Aug 16 10:15:32 hi bluelightning Aug 16 10:15:35 this seems to affect a lot of machines Aug 16 10:15:46 hi ant_work Aug 16 10:17:00 http://www.rpsys.net/openzaurus/patches/locomo_kbd_tweak-r2.patch Aug 16 11:37:31 hi all Aug 16 11:39:48 lumag: hi Aug 16 11:43:56 Jay7, ant_work, do you have any known-working kexecboot for tosa? So that I won't scratch nand to hell. Aug 16 11:44:56 lumag: today's build by ant_work :) Aug 16 11:49:02 Jay7, strange. My attempts with kexecboot failed this night Aug 16 11:49:35 let's wait for his anwer Aug 16 11:50:01 as I understand he have working kexecboot even w/o that null pointer problem Aug 16 11:50:16 lumag: read log (url in topic) Aug 16 11:50:55 Jay7, gui is stalled for me. Aug 16 11:52:02 http://git.linuxtogo.org/?p=groups/kexecboot/kexecboot.git;a=commit;h=cb755f90d23635ac1780d9b895a85e0487060b7a Aug 16 11:52:09 this commit should be working Aug 16 11:52:18 before new UI and other changes Aug 16 11:53:48 ok, I'll try this evening (no device here) Aug 16 11:56:33 BTW: I've added some debug stuff to kexecboot. Here is what I get right after boot in qemu: Aug 16 11:56:41 Read event type 14, code 0 (0x0) value 3e8 Aug 16 11:56:41 Read event type 14, code 1 (0x1) value fa Aug 16 11:56:56 14 is EV_REP Aug 16 11:59:45 hm.. what this mean? :) Aug 16 12:00:19 Dunno. It means I read those events from input devices. Aug 16 12:01:01 hm.. Aug 16 12:01:14 dunno too Aug 16 12:01:45 event processing should be improved anyway Aug 16 12:02:03 it reads now one event per select() call.. Aug 16 12:02:17 I'm sure this is wrong.. Aug 16 12:03:01 and to enable touchscreen/mouse handling we need some syncronization in events processing code.. Aug 16 12:14:21 hi, I'm back Aug 16 12:14:39 about tosa, no idea which was last working 2.6.3x Aug 16 12:18:42 lumag: stalled gui can have two origins Aug 16 12:18:48 1) missing devices Aug 16 12:19:02 2) missing zImage in /boot Aug 16 12:20:05 now, about the NULL in System Menu, it did happen on c7x0 and spitz too but very rarely Aug 16 12:20:20 so for the locomo patch :) Aug 16 12:20:42 maybe is indeed bad gcc4.5.x Aug 16 12:22:45 ant_work, I saw on console that kexecboot detected two event devices (matrix and gpio-keys) and detected two partitions with configs. So I see 3 menu entries. But kbd keys didn't work :( Aug 16 12:23:32 ah, maybe I did something wrong with tosa defconfig Aug 16 12:23:41 but afaik tosa has specific driver Aug 16 12:25:24 iirc the oldest one here http://projects.linuxtogo.org/frs/?group_id=55 Aug 16 12:25:35 is a working 2.6.24 Aug 16 12:25:46 lumag: ah, btw Aug 16 12:25:54 lumag: press right key Aug 16 12:26:12 it moves selection down Aug 16 12:26:48 can't remember what key select item.. check my latest email Aug 16 12:27:04 Jay7, O Aug 16 12:27:08 Jay7, I'll try :) Aug 16 12:37:18 lumag: check this patchset for 2.6.24 (of you) http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/obsolete/linux/linux-kexecboot_2.6.24.bb?h=org.openembedded.dev Aug 16 12:37:55 ant_work, Most of those patches went in into mainline kernel (in some form) Aug 16 12:38:03 ok, as I tought Aug 16 12:38:09 but see the locomo case... Aug 16 12:38:23 Yes. Aug 16 12:40:08 i.e. #define SCAN_INTERVAL (HZ/10) Aug 16 12:40:33 it looks like 10 was good with 2.6.2x Aug 16 12:43:08 Probably HZ changed from 100 to 250 ticks per second. Aug 16 12:43:31 ah, it is that HZ..... Aug 16 12:43:39 I see Aug 16 12:50:30 * Jay7 detached Aug 16 12:51:26 it looks like we are using default, is not defconfig Aug 16 13:40:54 bluelightning: I don't know if I should insist with koen to have klibc in meta-oe or rather ask for pull in oe-core directly Aug 16 13:41:31 there is actually little/no-benefit including meta-oe Aug 16 13:41:31 the question for oe-core is, is almost everyone likely to need it? Aug 16 13:42:04 well, it is initramfs stuff, I'd say almost generic Aug 16 13:42:21 surely not for everyone Aug 16 13:42:50 is a bit like uclibc Aug 16 13:43:30 it's likely to be needed by more than one meta- layer, so meta-oe is probably the right place for it Aug 16 13:43:42 definitely shouldn't be duplicated in multiple meta- layers Aug 16 13:43:59 nested question is: how to gropu the klibc variant of recipes? Aug 16 13:44:06 *group Aug 16 13:44:10 meta-klibc ? Aug 16 13:44:25 see e.g. kexec-tools Aug 16 13:44:35 is in oe-core Aug 16 13:44:55 where to put kexec-tools-klibc? Aug 16 13:45:20 would it be appropriate to make it a class and then use BBCLASSEXTEND? Aug 16 13:45:36 (klibc) Aug 16 13:46:07 recipes can need specific patches/hack to build against klibc Aug 16 13:47:04 in fact not in most cases Aug 16 13:47:36 yes, but are any of those not possible to do with a class? Aug 16 13:49:52 if it's possible to use a klibc class + BBCLASSEXTEND then it would mean you could just add a bunch of bbappends into meta-oe together with everything else and avoid duplication Aug 16 13:49:59 hmm.. for helloworld is just "inherit klibc" Aug 16 13:50:15 right, so that would be OK Aug 16 13:50:20 but remember we build static Aug 16 13:50:56 is that a problem? Aug 16 13:52:24 atm only for kexec-tools Aug 16 13:53:07 kexecboot-klibc is just two lines added Aug 16 13:53:15 9 # the binary is statically linked against klibc Aug 16 13:53:16 10 inherit klibc Aug 16 13:53:16 11 Aug 16 13:53:16 12 require kexecboot.inc Aug 16 13:53:55 nandlogical-klibc idem, minor things Aug 16 13:53:57 3 inherit klibc Aug 16 13:53:57 4 Aug 16 13:53:57 5 do_compile() { Aug 16 13:53:57 6 ${CC} ${CFLAGS} ${LDFLAGS} -static -I${STAGING_INCDIR} nandlogical.c -o nandlogical Aug 16 13:53:57 7 } Aug 16 13:54:43 the issue is with kexec-tools Aug 16 13:54:54 http://git.shr-project.org/git/?p=meta-smartphone.git;a=blob;f=meta-zaurus/recipes-bsp/kexec-tools/kexec-tools-klibc_2.0.2.bb Aug 16 13:55:02 this could be a bbappend maybe... Aug 16 13:55:18 bluelightning: see our point Aug 16 13:55:36 less recipes = easier Aug 16 13:57:43 hmm, kexec-tools probably has to be its own recipe if it's a different name and adding things to SRC_URI Aug 16 13:58:46 but the rest should be OK Aug 16 13:59:04 btw I guess you didn't get an answer to your license question about klibc? Aug 16 13:59:16 looks like it's both BSD and GPLv2 Aug 16 14:00:00 and thus you could possibly say it's only GPLv2, since you could never distribute the whole under BSD Aug 16 14:00:11 (although I am not a lawyer) Aug 16 14:02:10 no idea, there is a #klibc channel now. I'll reask there Aug 16 14:09:16 bluelightning: there is an immediate issue wrt jffs2 - RP says play with EXTRA_IMAGECMD but in this case I don't know if mkfs.jffs2 will accept --output defined twice Aug 16 14:09:31 http://git.shr-project.org/git/?p=meta-smartphone.git;a=blob;f=meta-zaurus/conf/machine/include/zaurus.inc Aug 16 14:10:10 vs. http://cgit.openembedded.org/cgit.cgi/openembedded-core/tree/meta/classes/image_types.bbclass Aug 16 14:10:33 I hack it -IMAGE_CMD_jffs2 = + IMAGE_CMD_jffs2 ?= Aug 16 14:10:53 because this is parsed after local.conf. When it was in bitbake.conf we could override it Aug 16 14:11:08 er, so why do you need to override --output? Aug 16 14:11:24 following RP suggestion to merge the strings Aug 16 14:11:48 puttin all in ${EXTRA_IMAGECMD}" Aug 16 14:12:15 tbh I did hack it and forgot Aug 16 14:12:31 yes, but why is the --output setting already used by image_types.bbclass not appropriate? Aug 16 14:20:02 sumtool plays on the copyi in --output=${T}/${IMAGE_NAME}.rootfs.jffs2 Aug 16 14:22:34 what is ${T} ? Aug 16 14:23:21 honestly I would say leave it as-is... what benefit would you get by changing to use EXTRA_IMAGECMD_jffs2 ? Aug 16 14:25:24 avoid to touch image_types.bbclass Aug 16 14:25:34 that's the 'advantage' Aug 16 14:26:03 in fact long ago the extras were --pad --little-endian --eraseblock=${ERASEBLOCKSIZE} -n Aug 16 14:26:31 that is enough for a regular jffs2. Aug 16 14:26:56 if we want the summary.jffs2 we need the bit of code with sumtool Aug 16 14:27:03 and yes, it boots faster Aug 16 14:42:57 bluelightning: see the first patch here, the original sin ;) Aug 16 14:42:59 http://cgit.openembedded.org/cgit.cgi/openembedded-core/log/meta/classes/image_types.bbclass Aug 16 14:44:05 third patch was a good try but forgot the image _types class is parsed after local.conf Aug 16 14:44:55 or would have setIMAGE_CMD_jffs2 ?= for the sake of precision Aug 16 16:07:18 Jay7: heh Aug 16 16:07:41 reading a patch for hx4700 Aug 16 16:07:43 > + status = pxa_ssp_read_reg(ssp, SSSR); Aug 16 16:07:43 > + ret = (status & (sssr | SSSR_RFS)) ? IRQ_HANDLED : IRQ_NONE; Aug 16 16:07:43 Please avoid ternary ops. Aug 16 16:07:48 ^^^ ^_^ Aug 16 16:27:48 hehe.. Aug 16 16:32:03 lumag_gone: 10x for the patch Aug 16 16:32:40 wrt klibc, I'll prefer to have it in oe-core Aug 16 16:40:14 Jay7: feel free to propose it... Aug 16 20:41:17 Jay7: we have to propose kexecboot for oe-core too Aug 16 20:42:10 ant__: not sure about kexecboot but having klibc in oe-core may be useful Aug 16 20:42:30 because most initramfs have tools compiled with klibc Aug 16 20:42:35 after all kexecboot was sponsored by ELC Aug 16 20:42:52 well, CELF Aug 16 20:43:05 or what is called now.. (Linux Foundation ?) Aug 16 20:43:16 ant__: LF imho Aug 16 20:43:29 wow.. Omegamoon was here Aug 16 20:43:33 ah, yes Aug 16 20:43:55 I'm building a collie kernel with the same patches as for poodle Aug 16 20:44:06 I'll upload in ltg in a few mins Aug 16 21:04:10 ok, others follow Aug 16 22:19:51 * Jay7 -> sleep Aug 16 23:02:52 lumag_gone: new roundup http://projects.linuxtogo.org/frs/?group_id=55 Aug 16 23:04:00 I tested on c7x0/C860, poodle/5600, spitz/3200 **** ENDING LOGGING AT Wed Aug 17 02:59:57 2011