**** BEGIN LOGGING AT Fri Sep 28 02:59:56 2012 Sep 28 08:24:15 dromede: have you found the bug making menu redraw 6 times (iirc)? Sep 28 08:25:08 strangely the menu is only slow on spitz (maybe on akita too). On c7x0(vga) and on poodle(qvga) is ok Sep 28 08:26:15 fwiw I've also seen that pressing a key triggers multiple events (matrix driver ?) Sep 28 08:29:54 dromede: thanks, I'll review when have time Sep 28 08:30:15 ant_work: he found and sent me quick fix for this Sep 28 08:38:50 ah, ok, great Sep 28 09:20:28 do c7x0 and spitz use the same keyboard driver? Sep 28 10:01:21 yes, https://patchwork.kernel.org/patch/77252/ Sep 28 10:01:43 tosa too Sep 28 10:58:04 can you confirm that a key triggers multiple events on the corgi as it does on spitz? Sep 28 11:20:49 yes Sep 28 11:21:22 hm Sep 28 11:21:48 for poodle too, I discovered that when it was missing kernel keymap Sep 28 11:22:00 it's no wonder why it works well on the poodle, much less pixels to deal with (qvga) Sep 28 11:22:11 but i can't explain why it's faster on corgi Sep 28 11:22:21 it's a different fb driver Sep 28 11:22:26 really? Sep 28 11:22:35 corgi doesn't use pxafb? Sep 28 11:23:27 ah Sep 28 11:23:29 w100fb Sep 28 11:23:40 yes Sep 28 11:24:21 well then it's faster on corgi devices because the framebuffer is in video memory Sep 28 11:24:48 as opposed to system memory on spitz devices Sep 28 11:25:22 and i guess w100fb handles rotation aswell Sep 28 11:26:10 my guess rotation is the main difference in menu performance Sep 28 11:26:21 i did try using kexecboot in portrait mode on akita Sep 28 11:26:35 the difference in performance was _very_ noticeable Sep 28 11:27:19 i made it draw in portrait mode and directly on the fb Sep 28 11:27:24 lot's of flicker Sep 28 11:27:26 but very fast too Sep 28 11:32:31 c7x0 does not need rotation Sep 28 11:32:41 right Sep 28 11:32:46 well, then that's probably it Sep 28 11:32:48 probably is in hw, right Sep 28 11:33:26 if only they left the w100 chip in newer zaurii models... Sep 28 11:34:07 heh, remember that we lost the accelerated X driver ... Sep 28 11:34:19 bitrot Sep 28 11:34:29 you still have kdrive Sep 28 11:34:54 in OE I'd say it's finally deprecated, so tslib Sep 28 11:35:12 kdrive was removed from OE-Core Sep 28 11:35:42 anyway, I'd like to remove the #ifdef zaurus from kexecboot...with a partition parser Sep 28 11:36:25 I'm very near to repartition on the fly with BLKPG iocl but it's much more clean if the kernel does read the partitioning at boot... Sep 28 11:37:59 if the Zaurus is the only device needing 'fake' partitioning at runtime, there is lttle sense to adapt kexecboot Sep 28 11:38:41 well, the suspend/resume bug is finally fixed, that was my main focus&concern Sep 28 11:38:50 now i can focus on other kernel issues Sep 28 11:38:52 thats great wrt kernel Sep 28 11:39:12 i'll spend some time with the mtd subsystem Sep 28 11:39:18 i don't know when but i will Sep 28 11:39:19 unfortunately I'm pretty sure poodle and c7x0 have some issues Sep 28 11:39:30 with recharging Sep 28 11:40:14 i.e. all is fine after cold-coot (remove and reinsert battery) Sep 28 11:40:34 how shoul I properly verify the device is really charging? Sep 28 11:40:56 a multimeter will know for sure Sep 28 11:41:05 well, yes Sep 28 11:41:24 so corgi and poodle have trouble with online charging ? Sep 28 11:41:45 it's long I don't debug but yes, smthg strange Sep 28 11:42:01 i.e. after kexecboot kernel boots, charging led goes off Sep 28 11:42:22 reinsert the cable again, it should turn on Sep 28 11:42:24 and I suspect it isn't recharging while in kexecboot Sep 28 11:42:59 the old 2.6 kernels did not have this problem Sep 28 11:43:31 i am aware of this bug, i know where it happens Sep 28 11:43:47 as i said, when the led goes off, simply reinsert the cable Sep 28 11:44:20 the led will stay on and the device will charge Sep 28 11:44:22 not ethat at least poodle, sometimes need the same treatment even after battery is removed Sep 28 11:44:29 ..sometimes... Sep 28 11:47:07 (note that the same poodle doesn't 'power-off' but restarts, unless battery switch is open :) Sep 28 11:47:22 kernel is not 100 Sep 28 11:47:26 % Sep 28 11:47:32 :/ Sep 28 11:48:14 anyway, I'm testing the new kernels built with minimal provided fragments Sep 28 11:48:21 they boot Sep 28 11:48:39 3.4? Sep 28 11:48:59 yes, but my point is about the features Sep 28 11:49:12 we'll use the standard KTYPE Sep 28 11:49:33 so we'll get a pre-fixed skeleton where we can add our config fragments Sep 28 11:50:00 i'm not familiar with the linux-yocto kernel build system Sep 28 11:50:01 but Sep 28 11:50:02 I'm pretty sure Yocto crow has exensivelytested the feature-set with oe-core images Sep 28 11:50:25 strange that vanilla 3.4 will boot Sep 28 11:50:30 can i see your kernel config? Sep 28 11:50:34 th point is: the usb modules, the filesystems, the debug level...all is defined in small .cfg files Sep 28 11:50:40 for 3.4? Sep 28 11:50:59 iirc I did boot 3.4 months ago Sep 28 11:51:10 I have the recipe only locally Sep 28 11:51:26 i just want to see the defconfig Sep 28 11:51:35 I don't know if it is worth to update the 3.2 or commit directly the 3.4 Sep 28 11:51:52 heh, the point is that you will not able to 'check' by seeing the defconfigs Sep 28 11:52:19 fragments are sparse, you'll need a bitbake -c menuconfig and inspect your build dir Sep 28 11:52:48 yes, i want the one from the kernel build dir Sep 28 11:52:48 frragments are in /meta of the kernel recipe you have in your WORKDIR Sep 28 11:53:10 3.4 shouldn't boot, that's my point Sep 28 11:53:12 hm... maybe I can send you some older pre-work with full defconfig... Sep 28 11:53:16 but i hope i'm wrong Sep 28 11:53:21 please do Sep 28 11:53:26 I'll test in a few hours Sep 28 11:53:30 spitz? Sep 28 11:53:33 if i'm wrong, that's one less patch to worry about Sep 28 11:53:36 yes please Sep 28 11:53:54 iirc I booted poodle and corgi Sep 28 11:54:08 spitz was under dust until your ZGRom Sep 28 11:54:10 :) Sep 28 11:54:41 seriously, there are much more devs on spitz so I take care of the others Sep 28 11:57:32 for those models, one idea could be having a ZGRom and another rescue image on nand, the game/ROMS on CF/SD Sep 28 11:57:45 we'll need toresize the nand, though Sep 28 12:00:45 ZGrom will go public later this week Sep 28 12:00:47 ...but atm we would not be able to boot the ZGRom from jffs2/ubi :/ Sep 28 12:01:07 how big was it, uncompressed? Sep 28 12:01:34 around ~150mb Sep 28 12:01:47 and that's just the apps/emu/engines Sep 28 12:01:59 engines expect game data in the same directory Sep 28 12:02:01 hm, do you have any jffs2 image to check the size? Sep 28 12:02:08 no Sep 28 12:02:25 nand in not suitable for current ZGrom rootfs design Sep 28 12:02:43 can't you make a link? Sep 28 12:02:53 or even unionfs? Sep 28 12:03:07 it wasn't a priority Sep 28 12:03:12 ah, ok Sep 28 12:03:18 sd/cf cards are dirt cheap these days Sep 28 12:03:26 heh, true Sep 28 12:03:27 so i didn't bother much with nand Sep 28 12:03:40 on Z it's still faster Sep 28 12:03:51 true, but not by much Sep 28 12:04:01 nand might make an impact on boot time Sep 28 12:04:25 yes, boot from ubifs *is fast* Sep 28 12:04:36 but that's about it, no game engine/emulator would benefit from nand Sep 28 12:05:25 pixman is giving me grief, i cant build it Sep 28 12:05:38 looking at the logs, it's trying to apply the same patch twice Sep 28 12:06:18 heh, I remember to have read on spitz the CF contrroller can hog the bus and thus the LCD can be disturbed Sep 28 12:06:45 that was true for wifi cards, yes Sep 28 12:06:56 this never happened to me with cf flash cards Sep 28 12:07:14 and the wifi card issue can be fixed with proper bus arbiter configuration Sep 28 12:07:44 this is one example of the code where linux-yocto should do the right thing Sep 28 12:08:18 i.e. we don't define any of those kernel parameters and rely on yosto configuration Sep 28 12:08:23 *yocto Sep 28 12:09:02 I'm still a bit dubios, they tested deeply on x86 and on beagleboard Sep 28 12:09:22 currently, there is no way to configure the bus arbiter at runtime Sep 28 12:09:31 i wrote a very nice sysfs interface for it Sep 28 12:09:38 ah, ok Sep 28 12:09:38 and i lost the patch :/ Sep 28 12:09:41 :/ Sep 28 12:11:24 I hope to be able to reduce the defconfig to a few kb. Now I'm at 11-12Kb but there is much more to clean Sep 28 12:12:03 and what's the size of the 3.4 linux-yocto zImage? Sep 28 12:13:30 hm, this is interesting Sep 28 12:13:48 both OE-Core meta and meta-openembedded have pixman recipe Sep 28 12:13:53 *recipes Sep 28 12:14:23 actually no Sep 28 12:14:40 there's a bbappend in meta-oe Sep 28 12:15:05 that includes two identical patches Sep 28 12:16:25 hm, that can't be right Sep 28 12:16:32 http://cgit.openembedded.org/meta-openembedded/log/?qt=grep&q=pixman Sep 28 12:16:39 2012-09-10 pixman: drop patches, merged to oe-core Sep 28 12:17:30 mayb you are not up-to date Sep 28 12:17:51 hmm, i'm using combo-layer to update all of my layers Sep 28 12:18:47 yep, misconfigured combo-layer Sep 28 12:18:47 good Sep 28 12:22:05 maybe we should add a bbappend for pixman in meta-handhelds Sep 28 12:22:17 current recipe completely disables iwmmxt detection Sep 28 12:22:35 and pixman received a lot of iwmmxt optimisations in the last two years Sep 28 12:22:47 most of the mmx code was converted to iwmmxt code Sep 28 12:31:45 good idea Sep 28 12:33:26 now, we don't want meta-handheld to depend on meta-oe Sep 28 12:33:36 just take care of oe-core's recipe Sep 28 12:33:43 of course Sep 28 12:33:51 (why is th e.bbappend in meta-oe now?) Sep 28 12:34:08 PRINC := "${@int(PRINC) + 1}" Sep 28 12:34:14 that's all it contains Sep 28 12:34:52 seems to me absolutely cruft Sep 28 12:35:08 maybe JaMa forgot to drop the recipe too Sep 28 12:35:16 maybe Sep 28 12:35:35 the bbappend in meta-handheld would only contain a single variable Sep 28 12:35:42 or meybe he has some .bbapend in shr layer... Sep 28 12:36:02 but before that i have to test whether the current gcc can actually compile pixman with iwmmxt code Sep 28 12:38:34 don't know why/when it has been disabled. Sep 28 12:39:09 i think it had something to do with cpu detection routines messing with qemu Sep 28 12:51:46 iirc only a few packages have been built for iwmmxt. Toolchain does support it, though Sep 28 15:15:06 i've uploaded ZGrom kernel changes to my github Sep 28 15:15:14 https://github.com/mkatic/linux/commits/3.2-stable Sep 28 17:08:36 dromede: pls see if you have time to refactor my last pending patch for kexecboot / ubi. Jay7 is short of time :) Sep 28 17:09:56 I could do a little better, creating a function for the common code reading the last two digit of e.g. /dev/mtd12 Sep 28 17:10:08 that's all :) Sep 28 17:10:24 th ememory allocation in that part of code is rather ugly :/ Sep 28 17:12:52 wow, lot of patches for spitz :/ Sep 28 17:13:25 no problem for adding patches in our meta-handheld layer :) Sep 28 17:14:27 to move forward we/I had to discard most of the patches. Dmitry agreed about collie and tosa. corgi and spitz were vanilla Sep 28 17:14:47 we only kept some keymaps Sep 28 17:15:24 do you see value in keeping 3.2? Sep 28 17:16:03 it's a bit sad most of linux-yocto rework/polishing has been done with 3.4... Sep 28 17:16:19 I'd jump on 3.4 this weekend if possible Sep 28 17:17:57 heading home now, bbl Sep 28 17:37:54 bluelightning: is there any good way of crosscompiling packages that need to run just compiled binaries ? Sep 28 17:38:05 with OE ofcourse Sep 28 17:41:58 dromede: I'm not sure I understand the question... ? Sep 28 17:42:18 take exult for instance Sep 28 17:42:30 it compiles a tool that generates headers at compile time Sep 28 17:42:38 ah ok Sep 28 17:42:47 right Sep 28 17:43:32 so, if the tool can actually be built for the host and generate valid output for cross-compilation, then usually we just build a native version (possibly cut-down to only build the tools) and then build the target version with the latter depending on the former Sep 28 17:44:23 are there any examples of this in oe-core? Sep 28 17:44:27 if the tool actually must be run in the target environment in order to generate valid output (e.g. gobject-introspection), there's no out-of-the-box solution, but it would have to involve running it in qemu Sep 28 17:44:37 dromede: well, Qt; that's a somewhat large example Sep 28 17:45:09 ok, thanks Sep 28 17:46:00 there are probably others though **** ENDING LOGGING AT Sat Sep 29 02:59:57 2012