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