**** BEGIN LOGGING AT Sat Nov 08 03:00:00 2014 Nov 08 14:40:56 hello lumag_, bluelightning Nov 08 14:41:08 hello ant__ Nov 08 14:44:45 ant__, hacking around support for headphones on collie. Nov 08 14:47:50 ah, missing since 2.4... Nov 08 14:48:23 sooner or later we/you should fix power mgmt ;) Nov 08 14:48:53 ant__, do you mean offline charging? Nov 08 14:49:18 I mean all..battery recharge, suspend, power off... Nov 08 14:51:32 ant__, suspend/resume should work. Nov 08 14:52:33 charging also should work. Nov 08 14:53:06 power off. That is a tricky question. Nov 08 14:53:14 In 2.4 it was done via suspend. Nov 08 14:53:37 The userspace will properly shutdown. Then the kernel would put itself into suspend. Nov 08 14:53:48 s/itself/cpu/ Nov 08 14:53:58 Note - this is about collie only for now Nov 08 14:54:44 When any event happens (not talking about what is an event) the cpu would wake up and ping kernel - resume. Nov 08 14:55:38 On resume kernel will check and if it was in 'shutdown' state and if the event is 'proper' - on button pressed, it will reboot. Nov 08 14:56:00 Otherwise (e.g. AC inserted/removed) - the kernel will just ping charger and suspend again. Nov 08 14:59:51 In early 2.6 era, rpurdie wrote sharpsl_pm - a similar framework. Nov 08 15:00:54 However it had several drawbacks - it required hooks and hacks in several drivers. Nov 08 15:01:42 For tosa it was a complete disaster - it had to driver AC97 link when main ASoC part is still 'suspended'. It was a constant source of hangups on suspend/resume. Nov 08 15:02:21 For collie sharpsl_pm support was never finished IIRC. Nov 08 15:03:50 So when adding support for the battery on collie, thesing (?) dropped sharpsl_pm support for collie alltogether. Nov 08 15:04:57 poodle should be in much worse state. I don't think that ads driver will properly read battery/temp on poodle. Nov 08 15:05:05 And charger also seems missing. Nov 08 15:05:31 It should be easy to add if/when I have time. Nov 08 15:05:48 charger I mean. Not the battery readings. Nov 08 15:29:17 In fact I'm doing fun stuff (audio) instead of doing really necessary thing - refactoring all locomo drivers to use regmap access. Nov 08 15:35:25 I don't have yet the big picture of the kernel Nov 08 15:35:53 anyways seems locomo is needing care as well Nov 08 15:36:56 power man is pervasive, I see Nov 08 15:37:38 Maybe (I say maybe!) the firmware can help us with power off. Nov 08 15:37:49 I think smthg is wrong for collie anyway, wrt power states Nov 08 15:37:56 The issue is that on ARM there is no real 'power off'. It is either working, or suspended. Nov 08 15:37:59 What is wrong? Nov 08 15:38:45 https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-power Nov 08 15:39:10 "freeze" can only be present if "standby" is Nov 08 15:39:10 present. Nov 08 15:39:22 on collie we have freeze and indeed it freezes ;) Nov 08 15:40:00 root@collie:~# cat /sys/power/state Nov 08 15:40:00 freeze mem Nov 08 15:40:00 root@collie:~# Nov 08 15:40:35 "freeze" - "suspend-to-idle", always present. Nov 08 15:40:45 mem seems to be sa1100 standby Nov 08 15:40:59 dunno about sa1100 idle Nov 08 15:41:05 don't see it... Nov 08 15:42:27 after # echo mem > /sys/power/state Nov 08 15:42:31 PM: Syncing filesystems ... done. Nov 08 15:42:32 Freezing user space processes ... (elapsed 0.002 seconds) done. Nov 08 15:42:32 Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. Nov 08 15:42:32 Suspending console(s) (use no_console_suspend to debug) Nov 08 15:42:32 sd 0:0:0:0: [sda] Stopping disk Nov 08 15:42:32 PM: suspend of devices complete after 817.431 msecs Nov 08 15:42:34 PM: late suspend of devices complete after 5.070 msecs Nov 08 15:42:36 PM: noirq suspend of devices complete after 4.734 msecs Nov 08 15:42:38 PM: noirq resume of devices complete after 729.836 msecs Nov 08 15:42:40 PM: early resume of devices complete after 3.981 msecs Nov 08 15:42:42 sd 0:0:0:0: [sda] Starting disk Nov 08 15:42:44 Reset Partition Config. Register: 1 Partition of 4 planes Nov 08 15:42:46 cfi_cmdset_0001: Simultaneous Operations disabled Nov 08 15:42:48 ata1.01: NODEV after polling detection Nov 08 15:42:52 ata1.00: configured for PIO0 Nov 08 15:42:54 PM: resume of devices complete after 324.890 msecs Nov 08 15:42:56 Restarting tasks ... done. Nov 08 15:42:58 root@collie:~# Nov 08 15:43:00 it resumes just pressing on/off Nov 08 15:43:23 Yes, that is normal suspend-to-RAM Nov 08 15:43:29 after # echo freeze > /sys/power/state Nov 08 15:43:39 ...how to wake up? Nov 08 15:43:59 iirc some irq Nov 08 15:44:07 kb does nothing Nov 08 15:44:39 Maybe it is just not handled. For collie there is no real reason to use freeze (IIUC). Nov 08 15:45:10 charger led stays on Nov 08 15:46:10 I'd expect it to resume quicker from freeze (sa1100 idle?) than from mem (sa1100-standby?) Nov 08 15:46:53 do you think mem is just 'suspend to ram'? Nov 08 15:47:20 Yes. Nov 08 15:47:48 so it is not sa1100 standby? Nov 08 15:48:10 Yes. Nov 08 15:48:44 reading now sa-1100_devel_manual Nov 08 15:48:53 reference manual calls that 'sleep' mode/ Nov 08 15:49:14 idle is a normal procedure - when CPU has nothing to do, it will call idle. Nov 08 15:49:28 BTW: I found why you cannot resume from 'freeze'. Nov 08 15:49:42 There is a nice ooops there, on suspend. Nov 08 15:49:53 ^_^ Nov 08 15:51:00 brb Nov 08 15:51:33 I suspect, because freeze_ops is not set by anybody except acpi. Nov 08 15:52:21 I'm taking the kid to grandma's..I'll have quiet in a few mins... Nov 08 15:54:24 I see. Crazy Intel guys. 'freeze' is always supported. Nov 08 15:54:26 Geee. Nov 08 16:17:00 ok, I'm back Nov 08 16:17:03 silence... Nov 08 16:17:55 so the idle is the same as the old good x86? Nov 08 16:18:03 cpuidle etc... Nov 08 16:18:10 epic times Nov 08 16:19:37 You can set one of leds to trigger on idle Nov 08 16:20:55 I've seen somewhere is sa1100 code the seq of 3 instructions putting it to 'suspend' Nov 08 16:21:03 searching... Nov 08 16:21:48 arch/arm/mm/proc-sa1100.S Nov 08 16:23:27 No/ Nov 08 16:23:34 arch/arm/mach-sa1100/sleep.S Nov 08 16:23:59 yes, that one Nov 08 16:24:31 this is definitely 'sleep' Nov 08 16:28:29 actually the sequence seems the same for idle... Nov 08 16:28:46 15 instruction / disable clock switch Nov 08 16:28:56 read instruction cache line Nov 08 16:31:44 doh, it uses another register... Nov 08 16:31:58 <------>mcr<--->p15, 0, r1, c15, c2, 2 Nov 08 16:32:01 vs Nov 08 16:32:20 mcr p15, 0, r0, c15, c2, 2 Nov 08 16:32:27 (dev. manual) Nov 08 16:34:07 this is really hard for me to follow Nov 08 16:35:17 I spent months on a single mtd chip..I'd need years for the sa-1100 ;) Nov 08 18:55:23 ant__, sorry got detached from PC a while ago. Kids... Nov 08 18:55:23 idle is a 3 instruction sequence. Nov 08 18:55:23 And the core of it is the last instruction - wait for interrupt. Nov 08 18:55:23 So the CPU stalls at that moment till an IRQ arrives. Then the execution continues from the next instruction. Nov 08 18:55:23 In cpu_sa1100_do_idle after WFI come few instructions (to undo idle effects) and then plain ret. Nov 08 18:55:25 On newer ARM cores there are several idle modes, but the idea is the same. Nov 08 18:55:29 All devices will store their states (in suspend callbacks) and prepare for a period of inactivity. Nov 08 18:55:31 Most (if not all) clocks exiting CPU will be stopped. Nov 08 18:55:33 In the end, CPU saves its state in RAM, prepares DRAM for self-refresh (because the CPU will not refresh memory) - tell me if I need to describe that. Nov 08 18:55:36 And puts itself to sleep. Basically it is a special kind of reset. Nov 08 18:55:38 The CPU is kept in reset state till the special kind of event arrives. Nov 08 18:55:40 Then CPU exits from reset. Control passes to bootloader. It analyses the reasons of reset (battery fault, suspend, hardware reset, soft reset). Nov 08 18:55:43 If the CPU comes from suspend, bootloader quickly passes control to the kernel already present in memory. Nov 08 18:55:46 The kernel then has to restore all the state. Nov 08 18:55:48 So suspend is a veeery long story. Nov 08 19:03:13 what's special here on collie is that dram are 'static' Nov 08 19:06:59 'sdram' Nov 08 19:22:31 No-no. Nov 08 19:22:31 On collie it is a normal SDRAM Nov 08 19:22:32 it is not static. Nov 08 19:22:32 SRAM (static ram) is very expensive. Nov 08 19:23:39 hm..why did I think it had sram? Nov 08 19:23:45 bah Nov 08 19:24:07 Memory controller was changed between sa1100 and sa1110 Nov 08 19:24:16 Do you need manuals for sa1110? Nov 08 19:24:41 not really thx ;) Nov 08 19:25:14 I just try to grasp some knowledge but the full picture is too wide Nov 08 19:26:03 for today my to-do is to unbreak kexecboot...oe decided to make the zImage symlink absolute Nov 08 19:26:29 I am playing with readlink and co. Nov 08 19:56:49 Ah, so it is absolute, but inside chroot. Nov 08 19:56:56 s/chroot/mount point/ Nov 08 19:57:04 That is unfortunate. Nov 08 20:10:15 that's also agaisnt standards (symlinks in the same dir) Nov 08 20:10:58 I have a patch allowing to define kexecboot mountpoint Nov 08 20:11:39 (/mnt was hardcoded) Nov 08 20:12:01 I'm testing now the readlink patch but smthg is wrong... Nov 08 20:13:10 http://pastebin.com/dCthPwdY Nov 08 20:14:20 I want to respect the case zImage is not a symlink Nov 08 20:14:32 (that case works obviously...) Nov 08 20:15:47 I'd suggest to use readlinkat. Nov 08 20:16:28 Or no. Ignore me for a moment Nov 08 20:16:35 http://git.kernel.org/cgit/libs/klibc/klibc.git/tree/usr/klibc/readlink.c Nov 08 20:16:40 ^ is readlinkat... Nov 08 20:17:11 ant__, readlink does not 0-terminate a buffer. Nov 08 20:17:15 I don't understand 100% firts fd arg Nov 08 20:17:43 yes, buf[len] = '\0'; Nov 08 20:18:09 So, what does not work? Nov 08 20:18:31 heh..I don't have output... Nov 08 20:18:45 Also if you place buf in a stack (lock variable) it will not be usable after function returns. Nov 08 20:19:07 At all? Nov 08 20:19:22 stderr might be going to some obscure place. Nov 08 20:19:52 seems I lack initial console... Nov 08 20:20:26 I know that for the test it is a symlink Nov 08 20:20:58 so I expect to see the buf Nov 08 20:21:01 Do you have any output from kexecboot at all? Nov 08 20:21:19 no, even recompiling with printk and bug on Nov 08 20:21:28 and --enable-debug in kexecboot Nov 08 20:21:38 Also you will need tty and console in kernel. Nov 08 20:21:40 and debug in cmdline Nov 08 20:22:08 Another issue. Do you really have /dev/console in kexecboot cpio file? Nov 08 20:22:12 I'd suggest to check. Nov 08 20:22:28 no, we start with empty and mount devtmpfs Nov 08 20:22:36 I had to add USE_DEVFS = "0" to my initramfs image file. Nov 08 20:22:44 devtmpfs won't help having the console. Nov 08 20:22:48 (it's a configure option, we don't use device-table-minimal anymore) Nov 08 20:23:13 Or maybe you need to open/bind it to fds 0 Nov 08 20:23:16 it was working with 2.6 and up to 3.10 at least... Nov 08 20:23:24 I'd suggest to add /dev/console for a moment. Nov 08 20:23:34 right Nov 08 20:24:20 sorry Nov 08 20:24:53 I'm just an oldschooler. If something breaks, I want my /bin/sh to have /dev/console to barf on me Nov 08 20:24:54 ah..ok...readlink error: No such file or directory Nov 08 20:24:59 :) Nov 08 20:25:11 that was on a 'relative' symlink Nov 08 20:25:53 http://pastebin.com/XskPF1Km Nov 08 20:26:49 That is what readlinkat is for. Nov 08 20:26:59 /boot/boot/zImage is the symlink Nov 08 20:27:12 You can either play magic with changing dir to /mnt/boot, call readlink, then jump back. Nov 08 20:27:23 I'm mouning on /boot in kexecboot Nov 08 20:27:33 Or you can open /mnt/boot, pass it as 1st arg to readlinkat and jump back. Nov 08 20:27:44 hm.. Nov 08 20:28:25 Moreover I'd do it in a very strange manner. Nov 08 20:28:37 (note, I'm paranoid of a kind). Nov 08 20:28:53 To really read the link, I'd: Nov 08 20:29:02 that's the offending commit Nov 08 20:29:03 http://cgit.openembedded.org/openembedded-core/commit/meta/classes/kernel.bbclass?id=78ee4d8b1782445caecce8331e68efe83fc32044 Nov 08 20:29:09 root = open('/); Nov 08 20:29:17 newroot = open('/mnt/'); Nov 08 20:29:40 ah, ok, readlinkat needs an opened file descriptor Nov 08 20:30:32 chdir('/mnt'); Nov 08 20:30:35 chroot('.'); Nov 08 20:30:46 chdir('/boot'); Nov 08 20:30:50 if you see in kexecboot.c I think we have to mangle it Nov 08 20:30:57 <------>/* Append kernelpath as last arg of kexec */ Nov 08 20:30:58 <------>load_argv[idx] = check_symlink(item->kernelpath); Nov 08 20:31:14 readlink('zImage'); Nov 08 20:31:19 fchdir(root); Nov 08 20:31:23 chroot('.'); Nov 08 20:31:44 don't do that. Nov 08 20:31:58 Don't return a part of stack. Nov 08 20:32:05 Do an strdup. Nov 08 20:32:32 lumag: it's quicker if you cook up a patch for me to test ;) Nov 08 20:32:48 No-no, I'm a kernel guy. Nov 08 20:33:14 Also I'd suggest to use lstat to actually check if it is a symlink and the size of buffer you will need for your readlink call. Nov 08 20:33:31 my readlink page has a nice example with lstat Nov 08 20:34:42 ...no race condition between the calls. ? Nov 08 20:34:46 that one? Nov 08 20:40:33 lstat or chroot? Nov 08 21:41:04 jeez.. klibc issues... Nov 08 21:41:42 implicit declaration of function 'lstat' (it is done with fstatat) Nov 08 21:41:53 and.. Nov 08 21:41:53 | util.c:460:24: error: storage size of 'sb' isn't known Nov 08 21:41:53 | struct stat sb; Nov 08 21:42:05 hat's strange... Nov 08 21:54:56 let me check Nov 08 21:56:31 #include ? Nov 08 21:56:51 yes, on top of util.c Nov 08 21:57:04 (I'm adding a func here) Nov 08 21:58:01 http://pastebin.com/4MpQhZS3 Nov 08 21:59:03 note I don't want to follow the symlink...I just have to prepend MOUNTPOINT to item->kernelpath if the symlink is absolute Nov 08 21:59:23 if it is a file ot a relative symlink don't change it Nov 08 22:00:04 zImage -> zImage-3.xxxx ok Nov 08 22:00:14 zImage -> /boot/zImage-3.xxxx bad Nov 08 22:00:50 bad because kexec tries to follow a broken symlink Nov 08 22:01:52 (we are in /MOUNTPOOINT and the correct path is MOUNTPOINT/zImage-3.xxxx) Nov 08 22:02:14 err.. MOUNTPOINT/boot/zImage-3.xxxx Nov 08 22:03:03 so much trouble for a discutible little change in OE... Nov 08 22:33:04 heh Nov 08 22:33:04 readlink error: No such file or directory Nov 08 22:33:05 Segmentation fault Nov 08 22:33:11 wow Nov 09 00:07:54 gn **** ENDING LOGGING AT Sun Nov 09 02:59:59 2014