**** BEGIN LOGGING AT Mon Nov 18 02:59:59 2013 Nov 18 14:03:38 http://threader.zapto.org/experimental/s7/kexecboot-recovery/SDC11407-.png screenshot for your site Nov 18 22:23:10 hi Nov 18 22:28:09 lumag_: still debugging the kexecboot kernel. stuck after uncompressing kernel...booting Nov 18 22:28:59 lumag_: this is the diff (for pxa poodle) between the two kernels Nov 18 22:29:06 http://pastebin.com/A20JNcte Nov 18 22:29:22 maybe SLOB/SLAB ? Nov 18 22:48:22 ant_home, hello Nov 18 22:48:32 For such problems: Nov 18 22:48:36 1) Enable DEBUG_LL Nov 18 22:49:03 fwiw the initramfs can be booted by the production kernel Nov 18 22:49:03 Depending on kernel version you should either select 'none' option or 'pxa uart1' if it is available. Nov 18 22:49:22 then pass 'debug earlyprintk' as the kernel arguments Nov 18 22:49:23 I'm startiing to think this is a fallback of the changes in kernel.bbclass Nov 18 22:49:35 which are *decompressing* the cpio Nov 18 22:49:55 That is correct. Nov 18 22:50:00 lumag_ ok, I'll do now Nov 18 22:50:12 You decompress cpio.xz so that you have 'initramfs.cpio' Nov 18 22:50:29 Then kernel compresses that kernel with the compression algorithm you selected during kconfig Nov 18 22:50:55 we build it with special options for 32MB ram Nov 18 22:51:07 is it respected by the kernel if recompressing? Nov 18 22:51:25 note this exact problem made poodle unusable for 3-4 years ;) Nov 18 22:51:53 anyway here all Z I have are failing to boot the linux-kexecboot Nov 18 22:51:54 Try selecting another cpio or kernel compressor. Nov 18 22:52:51 ok, for curiosity, let me revert the kernel.bbclass changes now... Nov 18 22:52:52 You can use poodle qemu emulation: http://repo.or.cz/w/qemu/lumag.git/shortlog/refs/heads/devel2 Nov 18 22:53:10 ah, ok, great ;) Nov 18 22:53:22 atm I copy the zImage on a card and boot it Nov 18 22:53:23 unfortunately that is not the upstream qemu Nov 18 22:53:53 promising Nov 18 22:54:47 lumag_: don't forget the collie-mtd tests ;) Nov 18 22:55:34 Where are 'special options for 32Mb' passed? Nov 18 22:55:47 in zaurus.inc Nov 18 22:56:04 renamed as XZ now Nov 18 22:56:10 I should have guessed Nov 18 22:56:26 I checked poodle.conf, but not zaurus.inc Nov 18 22:56:35 the defaults are insane for Z Nov 18 22:59:15 Unfortunately the kernel will ignore that -2e Nov 18 22:59:42 One should patch scripts/xz_wrap.sh Nov 18 22:59:46 hm.. defaults in image_types.bbclass are insane..dunno what kernel defaults are Nov 18 23:03:02 remember only c700 and poodle were failing for that reason Nov 18 23:03:17 now c860 (64MB) and collie are failing Nov 18 23:03:20 as well Nov 18 23:06:47 lumag_: anyway if it is decompressed all the options are nonsense... Nov 18 23:07:03 that patch was a mess... Nov 18 23:10:10 ant_home, so poodle kexecboot fails, but poodle kernel works, did I get it right? Nov 18 23:10:26 or plain kernel also fails? Nov 18 23:10:45 it did boot reverting the changes in kernel.bbclass ;) Nov 18 23:10:51 bluelightning: err Nov 18 23:11:14 plain kernbel + cpio was ok (added in boot.cfg) Nov 18 23:11:26 now let me reboot collie for test Nov 18 23:11:49 I'm using the configs on github in my fork of meta-hh Nov 18 23:13:19 lumag_ : nice, poodle survives to n cycles of kexec, with the kernel on SD kexecing itself Nov 18 23:16:33 Oh. BTW. If you are playing with poodle, Nov 18 23:16:39 lumag_: on poodle outstanding issue is the restart instead of poweroff when in kexecboot Nov 18 23:17:12 can you please check my locomo branch on it. https://github.com/lumag/linux/tree/locomo Nov 18 23:18:05 On some of zaurii (e.g. collie) it might be impossible to implement normal 'shutdown'. Nov 18 23:18:21 E.g. collie 2.4 used very nice technique for 'shutdown'. Nov 18 23:18:45 If I got it right (sorry, tons of spaghetti code there) - it replaced shutdown with suspend. Nov 18 23:19:39 Then on resume it would check the resume cause and if it was not 'ON' button (or reset) it will suspend again Nov 18 23:19:48 lumag_: the trick I use is to switch the battery lid before shutdown. then it stays 'off' Nov 18 23:20:05 this in kexecboot env Nov 18 23:20:24 you explained me it is never off, yes Nov 18 23:20:33 oh. Nov 18 23:20:37 then it should be simple Nov 18 23:21:51 works wit kerel 3.10 / kexecboot 0.6 as well Nov 18 23:21:53 Just a dirty patch of using raw register writes. Nov 18 23:22:13 pls go, we love dirty patches in meta-hh ;) Nov 18 23:27:59 I will check the original 2.4 kernel. Nov 18 23:29:11 I have dumped the mtd if you need it Nov 18 23:31:09 lumag_: ok, also C860 is booting 3.10+kexecboot 0.6 so it is indeed kernel.bbclass Nov 18 23:31:31 I've sent another msg about it to oe-core ML Nov 18 23:31:38 sigh..another one... Nov 18 23:32:33 now collie... Nov 18 23:32:46 in a few mins Nov 18 23:41:59 I'll upload the kernels on kexecboot.org Nov 18 23:42:21 collie stays at 2.6.31 until we have SD/MMC back ;) Nov 18 23:57:32 ant_home, I will think about sd/mmc. Tomorow... Nov 18 23:57:58 great, thx Nov 19 00:05:49 ok, collie boots as well Nov 19 00:05:59 3.10 + kexecboot 0.6 Nov 19 00:18:49 ant_home, I checked the kernels. Nov 19 00:19:07 At least 3.5, which I have here. Nov 19 00:19:33 You can safely pass compressed initramfs to INITRAMFS_SOURCE. Kernel will not recompress it. Nov 19 00:19:51 Also it will completely ignore INITRAMFS_COMPRESSION_* variables Nov 19 00:19:57 Well not completely. Nov 19 00:20:28 It will copy your _compressed_ initramfs to the usr/initramfs_data.cpio.EXT, where EXT depends on the selected INITRAMFS_COMPRESSION_* Nov 19 00:22:09 However kernel should completely ignore that extension. Nov 19 00:22:17 Hmm. Some problems during build later. Nov 19 00:25:43 No, it was my fault. Nov 19 00:25:53 So we can completely skip that 'uncompress' stage in kernel.bbclass Nov 19 00:26:07 s/can/should/ Nov 19 00:26:38 I've removed the whole task from the classes Nov 19 00:27:24 http://pastebin.com/nqjNRG8P Nov 19 00:31:13 Shan't we use INITRAMFS_TASK? Nov 19 00:31:49 Ah, I see. Nov 19 00:32:02 The kernel.bbclass supports more cases that we (hh) really use. Nov 19 00:32:34 I'd suggest for now to just drop the decompression part of copy_initramfs() Nov 19 00:33:06 Or does the current code (bundle_initramfs/copy_initramfs/etc) cause any side effects for us? Nov 19 00:33:09 Except for decompression Nov 19 00:34:16 it was so simple and so clean before... Nov 19 00:35:18 RP is also unsatisfied as I read on the ML so will be fixed soon I hope Nov 19 00:36:44 ok then Nov 19 00:37:19 I would suggest to report that we can drop decompression from kernel.bbclass and things will work. Nov 19 00:37:27 Provided you have selected correct decompressor Nov 19 00:37:45 "FWIW I would *love* to simplify this code and have one good/efficient Nov 19 00:37:45 codepath everyone uses. The initramfs decompression code looks nasty to Nov 19 00:37:45 me for example and I agree with your thoughts on that." Nov 19 00:37:50 RP Nov 19 00:39:50 time to sleep a bit Nov 19 00:39:52 gn **** ENDING LOGGING AT Tue Nov 19 02:59:59 2013