**** BEGIN LOGGING AT Sun Nov 10 02:59:58 2013 Nov 10 04:40:10 ant_home, I wander how it did work. It looks like I found an error in locomo backlight handling. Nov 10 04:42:54 In locomo_m62332_sendbit (arch/arm/common/locomo.c) change second 'r &= ~(LOCOMO_DAC_SCLOEB);' line to read 'r &= ~(LOCOMO_DAC_SDAOEB);' Nov 10 04:55:45 ant_home, and most probably you need to have obj-... += backlight/ in the end of drivers/video/Makefile, instead of it being somewhere in the middle Nov 10 08:13:09 whee, fantastic, combined kexecboot into a recovery.img for android, so first kexecboot can start, then when you can quit and enter recovery mode Nov 10 08:13:23 CM recovery Nov 10 08:15:17 cool! write post about it and give us a link :) Nov 10 08:18:49 was about to upload the image to my server and xda it ;) Nov 10 08:19:34 just barely made it within 5 megs too, got adb too since its recovery :D Nov 10 08:19:41 couldnt make room for bash though Nov 10 08:21:37 try another shell Nov 10 08:22:11 dash e.g. Nov 10 08:24:13 http://threader.zapto.org/experimental/s7/kexecboot-recovery/recovery-kex.img Nov 10 08:24:35 there is a shell trough busybox Nov 10 08:24:37 or cm recovery Nov 10 08:24:41 so we have as hell Nov 10 08:24:43 shell Nov 10 08:24:44 :D Nov 10 08:24:45 ah, ok then Nov 10 08:25:25 for which tablet/phone is this image? Nov 10 08:25:46 gm Nov 10 08:25:49 hi Jay7 Nov 10 08:26:36 Jay7, huawei s7 , a qsd8x50 Nov 10 08:27:14 ant_home: hi Nov 10 08:27:57 ant_home: may be good idea to place link to bikerer's post on kexecboot.org site ;) Nov 10 08:28:50 * Jay7 afk for some hours Nov 10 08:30:04 see ya jay! thanks :> Nov 10 08:34:03 ant_home, gm Nov 10 08:34:30 How is your kid feeling, btw? Nov 10 08:40:32 37+* Nov 10 08:40:52 :( Nov 10 08:44:22 I have sent your an idea regarding lcd. I'm not 100% sure that it is the reason of 'stalled' pictures, but it is worth trying. Nov 10 08:45:41 gtg/bbl Nov 10 08:46:45 ah, yes, I'll test in a few mins Nov 10 08:47:44 finishing the mtd-tests Nov 10 08:47:53 all fine until now Nov 10 08:52:20 hum, now, how to boot android then :D Nov 10 09:09:59 aah excellent :D Nov 10 09:10:16 android booted just fine with the initrd thinige Nov 10 09:10:39 uuh Nov 10 09:11:05 nvm :D Nov 10 09:36:46 funny, i lost adb when booting android ? Nov 10 09:58:40 http://forum.xda-developers.com/showthread.php?t=2520663 still no photos though, probably wont be until later, promised a friend i would help tare something down, and burn it :D Nov 10 10:38:00 lumag: the difference is that i get a white screen Nov 10 10:38:42 iirc this happened postponing backlight Nov 10 10:38:53 maybe need a precise line Nov 10 10:41:37 before vfb.o ? Nov 10 10:41:46 no idea... Nov 10 10:50:43 heh. the abd enabling at boot is lost, i have to re-enable it in the menu of android Nov 10 10:56:11 hm, ok, no its lost completely Nov 10 10:57:04 and then it crashes Nov 10 10:57:28 must be failing to launch adbd Nov 10 11:04:02 hmm, does not like sleep modes either Nov 10 11:25:33 lumag: mtd_torturetest: Page 0 has 512 bytes/3584 bits failing verify, starting at offset 0x0 Nov 10 11:25:33 Offset Read Written Nov 10 11:25:33 0x00000000: 80 80 80 80 80 80 80 80 *** ff ff ff ff ff ff ff ff Nov 10 11:25:43 that same 808080 status Nov 10 11:27:03 as ubi had Nov 10 11:27:05 sa1100: Chip not ready for buffer write. Xstatus = 80808080, status = 80808080 Nov 10 12:04:09 uhm, is RAMDISK i a valid config entry? Nov 10 12:04:23 since kexec supports it Nov 10 15:06:40 ugh, had to add a bunch of "oneshot" to every service in init.rc for the thing not to go bananas Nov 10 16:09:45 bikerer: http://kexecboot.org/documentation/how_to_write_config Nov 10 16:10:16 i.e. no RAMDISK Nov 10 16:13:43 started trying to add it Nov 10 16:13:53 but doesnt seem to make much difference Nov 10 16:13:54 bbl Nov 10 16:13:57 initrd or ramdisk Nov 10 18:24:22 lumag: about chip not ready: http://mhonarc.axis.se/jffs-dev/msg00703.html Nov 10 18:32:08 I've sent this as well to linux-mtd Nov 10 18:37:32 This is over my understanding of mtd... Nov 10 18:38:13 an old post about ipaq was...overheating... Nov 10 18:38:34 http://pastebin.com/y92ZZsuF Nov 10 18:38:49 ^^ I've sent this logs to linux-mtd Nov 10 18:40:00 note how mtd_stresstest fails with count > 15 Nov 10 18:40:11 loops? loks? Nov 10 18:40:36 I have to catch dwmw2, he wrote this code 13 yrs ago Nov 10 18:40:41 :p Nov 10 18:41:14 oh, about collie, any other idea for backlight? Nov 10 18:43:39 wher would you put it in Makefile? Nov 10 18:49:17 fwiw Nov 10 18:49:19 root@collie:~# cat /proc/interrupts Nov 10 18:49:19 CPU0 Nov 10 18:49:19 1: 0 GPIO-l ac Nov 10 18:49:19 12: 167 SC LCD Nov 10 18:49:19 17: 1953 SC sa11x0-uart Nov 10 18:49:20 26: 8257 SC ost0 Nov 10 18:49:22 35: 5440 GPIO-h pata_pcmcia Nov 10 18:49:24 41: 2 GPIO-h main full Nov 10 18:49:26 43: 2 GPIO-h PCMCIA0 CD Nov 10 18:49:28 49: 0 LOCOMO locomokbd Nov 10 18:49:30 Err: 0 Nov 10 18:51:04 and iomem Nov 10 18:51:06 root@collie:~# cat /proc/iomem Nov 10 18:51:06 00000000-00ffffff : sa1100-mtd Nov 10 18:51:06 00000000-00ffffff : sa1100 Nov 10 18:51:07 20000000-2fffffff : PCMCIA socket 0 Nov 10 18:51:09 20000000-23ffffff : io Nov 10 18:51:11 28000000-2bffffff : attribute Nov 10 18:51:13 2c000000-2fffffff : memory Nov 10 18:51:15 40000000-40001fff : locomo.0 Nov 10 18:51:17 40800000-40800fff : sharp-scoop Nov 10 18:51:19 80000000-8000ffff : sa11x0-udc Nov 10 18:51:21 80010000-8001ffff : sa11x0-uart.1 Nov 10 18:51:23 80010000-80010023 : sa11x0-uart Nov 10 18:51:25 80030000-80030023 : sa11x0-ir Nov 10 18:51:27 80040060-8004007b : sa11x0-ir Nov 10 18:51:29 80050000-8005ffff : sa11x0-uart.3 Nov 10 18:51:31 80050000-80050023 : sa11x0-uart Nov 10 18:51:35 80060000-8006ffff : sa11x0-mcp Nov 10 18:51:37 80060000-8006ffff : sa11x0-mcp Nov 10 18:51:39 80070000-8007ffff : sa11x0-ssp Nov 10 18:51:41 90010000-9001003f : sa1100-rtc Nov 10 18:51:43 90050000-9005ffff : irqs Nov 10 18:51:45 90060028-9006002b : sa11x0-ir Nov 10 18:51:47 90060030-90060033 : sa11x0-mcp Nov 10 18:51:49 90060030-90060033 : sa11x0-mcp Nov 10 18:51:51 b0000000-b00000bf : sa11x0-dma Nov 10 18:51:53 b0100000-b010ffff : sa11x0-fb Nov 10 18:51:55 b0100000-b010ffff : LCD Nov 10 18:51:57 c0000000-c3ffffff : System RAM Nov 10 18:51:59 c0008000-c07e6a8f : Kernel code Nov 10 18:52:01 c0852000-c0932fc7 : Kernel data Nov 10 18:52:05 c4848040-c484804f : locomokbd Nov 10 18:52:07 root@collie:~# Nov 10 19:04:07 * lumag_ is finishing with cleaned up locomo Nov 10 19:05:23 Hope updated locomo backlight will be more robust Nov 10 19:09:09 ant_home, few questions about collie kernels. Nov 10 19:09:34 I checked up the current OE's kernel. In quemu, but... Nov 10 19:10:30 1) Is lzma fast enough on real hw? It is rather slow in qemu. Nov 10 19:10:52 2) Do we really need all raid modules? I rather doubt somebody will have raids on Zaurii Nov 10 19:53:50 sure, the yocto kernel is huge Nov 10 19:54:19 unfortunately some features are not opt-in so we need a specific fragment to 'unset' i.e. raid Nov 10 19:54:45 atm I've only tried to standardize the features, building around linux-yocto Nov 10 19:54:57 about lzma, it was neede by linux-kexecboot Nov 10 19:55:01 that's all Nov 10 19:56:51 ah, ok Nov 10 19:57:48 I'd remove llvm, kprobe, profiling etc Nov 10 20:04:11 lumag_: cpu freq cannot be disabled Nov 10 20:04:38 and there are no ARM CPU freq drivers... Nov 10 20:04:55 iirc this is a 2.6.32/33 change Nov 10 20:05:51 Edit arch/arm/Kconfig, remove "select CPU_FREQ" under ARCH_SA1100 Nov 10 20:05:56 fwiw I've suspended/&resumed now on collie ;) Nov 10 20:06:04 he-he. Nov 10 20:06:24 btw the backlight dims off by itself after some time Nov 10 20:06:34 As I said once sa1100 is somewhat better than pxa. There is no place to do things completely wrong. Nov 10 20:06:35 even in kexecboot menu Nov 10 20:06:47 That is VT blanking I think Nov 10 20:07:08 someone said that unbtil recently sa1100 was broken because of missing freq table...you? linusw? Nov 10 20:07:31 Dunno. There were patches to fix that. Nov 10 20:07:47 There is a problem with cpu_freq Nov 10 20:08:04 sa1110 driver depends on availability of dram timings table. Nov 10 20:08:33 So each sa1110 _board_ that wants to support cpu_freq should select correct symbol Nov 10 20:08:49 ah, that table Nov 10 20:09:04 And then it should provide used dram timings in drivers/cpufreq/*sa1110* Nov 10 20:09:22 No, there also was some problem with sa1100 (or sa1110) frequencies table. Nov 10 20:10:24 * lumag_ is trying to catch linusw with a question regarding pinctrl. Nov 10 20:10:29 hm.. sorry.. 1110 vs. 1100 Nov 10 20:10:45 bluelightning: we lost linusw bouncing patches :/ Nov 10 20:10:57 until tomorrow... Nov 10 20:11:05 He doesn't show on irc Nov 10 20:11:15 Ah, maybe due to the merge window he is hiding Nov 10 20:11:18 ant_home, yes Nov 10 20:11:24 during week usually Nov 10 20:12:07 sa1100 did not support SDRAM, sa1110 does. But it does that so strangely, that cpufreq driver needs to know dram timings Nov 10 20:12:26 heh, the engineers Nov 10 20:12:40 ant_home, regarding backlight. Nov 10 20:13:05 Could you please try the following fixups: Nov 10 20:13:14 1) fix in m62332 code Nov 10 20:13:22 2) move obj-y += backlight/ down Nov 10 20:13:46 3) in locomolcd_probe remove if (machine_is_poodle()) Nov 10 20:14:02 so call locomolcd_power(1) unconditionally on probe Nov 10 22:21:36 lumag_: I've sent vid 3 after those changes Nov 10 22:23:40 seems a bit a progress somehow... Nov 10 22:24:23 So display is not garbled, but no "new" picture Nov 10 22:25:07 less garbled but not 'cleared' Nov 10 22:25:52 repeatable, now I always see the logo but is misplaced Nov 10 22:27:09 Hmm. Which logo? OE logo or kernel tux? Nov 10 22:27:33 is always the same...kexecboot-kernel, launched kernel, psplash Nov 10 22:27:49 I show you how it is on poodle if you want Nov 10 22:32:20 I'm asking because on your video I saw 'bad' OE psplash, kexecboot, your fingers and then kexecboot, kexecboot, kexecboot. Nov 10 22:33:06 You say on poodle video is correct. Nov 10 22:33:10 That is strange. Nov 10 22:33:18 poodle and collie share locomolcd Nov 10 22:35:26 poodle is much quicker to decompress, even with 32M ram Nov 10 22:35:48 see video so you see what I expect from collie as well Nov 10 22:36:31 detection takes long because of th ejffs2 mtd2, mtd3 is ubi Nov 10 22:37:14 ant_home, do you see any screen changes after you press enter on collie? I don't see any on your video. Nov 10 22:37:43 er.. iphone ate the last part of the video... Nov 10 22:38:06 but no, there isn't any clear 'reset' like on poodle Nov 10 22:38:33 What kernel config are you basing upon? OE? Nov 10 22:38:47 yes Nov 10 22:40:31 It really looks like sa1100fb is broken. Nov 10 22:40:37 However I fail to see how it can be. Nov 10 22:40:47 seems it works on h3600 Nov 10 22:40:54 Yes Nov 10 22:41:02 w/out locomo Nov 10 22:41:20 At least linusw said that he ported backlight/etc w/o any issues Nov 10 22:41:42 locomolcd is also working Nov 10 22:41:50 Hmm. Nov 10 22:41:58 * lumag_ has an idea Nov 10 22:42:05 locomo + pxa = ok Nov 10 22:42:12 locomo + sa1100 = ko Nov 10 22:42:57 or maybe just pxa vs. sa1100 framebuffer... Nov 10 22:49:19 Would you mind adding #define DEBUG as the first line of sa1100fb.c and then grepping dmesg for sa1100-fb? Nov 10 22:50:54 Ah, and btw: did you succeed building kernel w/o CPU_FREQ? Nov 10 22:55:59 should I change m62332 as well? Nov 10 22:58:03 Yes. Nov 10 22:58:09 All 3 workarounds + debug Nov 10 22:58:18 ok Nov 10 22:59:04 I'm really trying to understand what goes on with fb driver. Nov 10 23:00:42 As I still did not implement sa1100 fb qemu emulation :( Nov 10 23:02:54 just #define DEBUG Nov 10 23:02:55 ? Nov 10 23:04:10 ah, ok, dev_dbg Nov 10 23:04:24 building Nov 10 23:05:16 I'm not a fan of 'dynamic_debug'/etc. Nov 10 23:06:33 I've learned that with mtd Nov 10 23:06:48 still scared by debugfs Nov 10 23:07:17 at this point, gdb as you once told me ;) Nov 10 23:07:33 I like debugfs Nov 10 23:08:26 /sys/kernel/debug/gpio, was my favourite for long debugging sessions Nov 10 23:08:28 never spent enough time to learn it... Nov 10 23:08:46 And /sys/kernel/debug/asoc for sound card issues Nov 10 23:08:59 btw, there are 3 patches speeding build of kernel (hardlinks) Nov 10 23:09:17 linux-yocto was taking 15-16 mins, let see now Nov 10 23:16:07 built Nov 10 23:19:42 well, nothing... maybe device debug is disabled.. checking Nov 10 23:24:43 hm.. debugfs is mounted Nov 10 23:28:29 root@collie:~# cat /sys/kernel/debug/gpio Nov 10 23:28:30 GPIOs 0-27, gpio: Nov 10 23:28:30 gpio-1 (ac in ) in hi Nov 10 23:28:30 gpio-20 (main battery full ) in lo Nov 10 23:28:30 gpio-26 (main battery low ) in hi Nov 10 23:28:30 GPIOs 28-39, sharp-scoop: Nov 10 23:28:32 gpio-28 (main charge on ) out hi Nov 10 23:28:34 gpio-35 (flash Vpp enable ) out lo Nov 10 23:28:36 GPIOs 40-49, no-bus/ucb1x00, ucb1x00: Nov 10 23:28:38 gpio-47 (main battery ) out lo Nov 10 23:28:40 gpio-48 (backup battery ) out lo Nov 10 23:28:42 gpio-49 (main batte Nov 10 23:29:17 ry temp ) out lo Nov 10 23:33:02 lumag: fwiw LCD (or backlight) is OFF on resume after suspend Nov 10 23:39:04 eh.. DEBUG must be defined before... Nov 10 23:39:15 ok, redoing Nov 10 23:42:51 n/p Nov 10 23:42:56 I'm really interested in dmesg Nov 10 23:45:22 seems kernel build gained 25% speed Nov 10 23:45:28 overall Nov 10 23:45:45 10 mins instead of 15-16 Nov 10 23:46:05 on my old quad Nov 10 23:58:18 lumag_: http://pastebin.com/NcJV1Rp4 Nov 10 23:59:38 Didn't check register values (will do tomorrow), but it looks sane. Nov 11 00:00:03 ok Nov 11 00:00:36 In the dead end we can just do a git bisect :) Nov 11 00:00:45 see the resume Nov 11 00:00:45 collie login: root Nov 11 00:00:46 root@collie:~# apm --suspend Nov 11 00:00:46 PM: Syncing filesystems ... done. Nov 11 00:00:46 Freezing user space processes ... (elapsed 0.01 seconds) done. Nov 11 00:00:46 Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. Nov 11 00:00:47 Suspending console(s) (use no_console_suspend to debug) Nov 11 00:00:49 sd 0:0:0:0: [sda] Stopping disk Nov 11 00:00:51 sa11x0-fb sa11x0-fb: backlight off Nov 11 00:00:53 sa11x0-fb sa11x0-fb: Disabling LCD controller Nov 11 00:00:55 sa11x0-fb sa11x0-fb: LCD power off Nov 11 00:00:59 PM: suspend of devices complete after 825.581 msecs Nov 11 00:01:01 PM: late suspend of devices complete after 2.907 msecs Nov 11 00:01:03 PM: noirq suspend of devices complete after 2.626 msecs Nov 11 00:01:05 PM: noirq resume of devices complete after 729.023 msecs Nov 11 00:01:07 PM: early resume of devices complete after 2.343 msecs Nov 11 00:01:09 sa11x0-fb sa11x0-fb: LCD power on Nov 11 00:01:11 sa11x0-fb sa11x0-fb: Enabling LCD controller Nov 11 00:01:13 sa11x0-fb sa11x0-fb: DBAR1: 0xc3ac0fe0 Nov 11 00:01:15 sa11x0-fb sa11x0-fb: DBAR2: 0xc3ad3c00 Nov 11 00:01:17 sa11x0-fb sa11x0-fb: LCCR0: 0x000000b9 Nov 11 00:01:19 sa11x0-fb sa11x0-fb: LCCR1: 0x0a1d1130 Nov 11 00:01:21 sa11x0-fb sa11x0-fb: LCCR2: 0x020000ef Nov 11 00:01:23 sa11x0-fb sa11x0-fb: LCCR3: 0x00fffffe Nov 11 00:01:25 sa11x0-fb sa11x0-fb: backlight on Nov 11 00:01:29 ata1.00: configured for PIO0 Nov 11 00:01:31 sd 0:0:0:0: [sda] Starting disk Nov 11 00:01:33 PM: resume of devices complete after 318.849 msecs Nov 11 00:01:35 Restarting tasks ... done. Nov 11 00:01:37 root@collie:~# Nov 11 00:01:45 Still no picture on screen? Nov 11 00:01:56 BTW: what will happen to screen if you do dd if=/dev/urandom of=/dev/fb0? Nov 11 00:03:05 nothing after resume...I'll reboot Nov 11 00:03:43 all is black even if backlight is on... Nov 11 00:05:26 now after eboot all is white (building backlight at the end) Nov 11 00:05:47 nothing happens on screen Nov 11 00:07:40 hmm.. sa11x0-fb sa11x0-fb: dma period = 1372168 ps, clock = 0 kHz Nov 11 00:07:46 0 kHz ? Nov 11 00:09:32 Heh. Nov 11 00:09:35 cpu_freq in charge Nov 11 00:09:50 ah, this is built w/out Nov 11 00:10:22 No it was not. Nov 11 00:10:34 At least from what I understand. Nov 11 00:12:31 my bad..., maybe I didn't remove it from the .config but just from the Kconfig Nov 11 00:12:41 s/maybe/surely/ Nov 11 00:12:52 it has been readded Nov 11 00:14:16 sorry Nov 11 00:14:30 had network outage Nov 11 00:14:34 np, I'l ldo a last build and go Nov 11 00:15:49 wait a minute. Nov 11 00:16:46 No/ Nov 11 00:16:52 I will think about it Nov 11 00:17:02 Maybe we really need to implement dram timings Nov 11 00:17:20 ask linusw tomorrow Nov 11 00:17:40 you guys can better talk each other ;) Nov 11 00:18:07 I'm happy to monkey-build Nov 11 00:18:27 ant_home, proper solution would be to read clock from cpu, rather than asking cpufreq for it, Nov 11 00:18:33 I will think tomorrow. Nov 11 00:18:42 Great that you have eyes to notice that. Nov 11 00:29:26 afaik thesing hardcoded it Nov 11 00:29:52 right when he introduced cpufreq for collie Nov 11 00:30:01 strange eh Nov 11 00:30:56 anyway, gn Nov 11 00:30:59 and thx Nov 11 00:31:04 bye **** ENDING LOGGING AT Mon Nov 11 02:59:58 2013