TWL scripts, and booting pm-2.6.29 on Beagleboard
Hello everyone. I am attempting to get the branch named pm-2.6.29 of Kevin Hilman's linux-omap-pm repo to boot on a Beagleboard revision B5. The purpose of this is to apply some patches made by Russ Dill about a year ago [1] that allow a low-power sleep by adding some TWL scripts. I have been unable to determine whether these are working with the branch named pm (I am aware that the second and fourth patch are already applied, so I only need the first and third), so I figured it was best to start from the same point that Russ Dill started at, which he reports is pm-2.6.29 The trouble is that pm-2.6.29 does not boot (I boot from an SD card, use the config file named omap3_beagle_pm_defconfig, and use u-boot 2009.11) -- no output is printed after "Uncompressing Linux... done, booting the kernel." Normally, I would enable CONFIG_EARLY_PRINTK and provide some resulting output, but this option seems to be missing from the branch in question. I asking for help in one of the following: 1) Whether there is any alternative way to get useful output to diagnose why pm-2.6.29 is not booting. 2) How to apply the patch similarly to the current pm branch. (Have the relevant sections been moved to a generic file at board-3430sdp.c ? Is there anything else I need to know? Is there documentation on what exactly these scripts are doing?) 3) Whether there's any alternative way to achieve the same objectives of power savings. I appreciate your support in this. Peter Tseng [1] http://groups.google.com/group/beagleboard/browse_thread/thread/197a8ef6b46cc828/6e98db4cbe2cebaa -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Overo serial problems after resume, vs. Beagleboard
Hey there, I am seeing some discrepancies between the Overo (I believe I have a Water) and the Beagleboard (I have a Rev. B5) when resuming after a suspend to RAM. The setup: My kernel is built from the latest commit (commit ID 305f453e897e4673dd4c2b52ec7e2c4be2e2b035 [1]) of the branch named pm of Kevin Hilman's linux-omap-pm [2]. I take the omap3_pm_defconfig, and change the below options to Y as they seem to be needed to boot from SD card (Names given are names in menuconfig under Device Drivers-->MMC/SD/SDIO card support. Config symbols given in parentheses) - MMC block device driver (MMC_BLOCK) - TI OMAP High Speed Multimedia Card Interface support (MMC_OMAP_HS) - Secure Digital Host Controller Interface support (MMC_SDHC) My filesystem is omap3-console-image dated May 23 from Steve Sakoman's binaries [3]. I do need to note that I made a few changes: symlinked /sbin/init to /bin/busybox instead of /sbin/init.sysvinit and changed /etc/init.d/rcS and /etc/inittab to suit Busybox. My uBoot is also taken from Steve Sakoman, and also dated May 23. I use the same card for both the Beagle and the Overo. This reduces sources of confounding variables, as now the only difference is the hardware (and that I need a micro-SD adapter for the Beagle). For Beagle: Kernel command line: console=ttyS2,115200n8 mpurate=500 vram=12M omapfb.mode=dvi:1024x768mr...@60 omapfb.debug=y omapdss.def_disp=dvi root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait For Overo: Kernel command line: console=ttyS2,115200n8 vram=12M omapfb.mode=dvi:1024x768mr...@60 omapfb.debug=y omapdss.def_disp=dvi root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait The Overo connects to my computer through USB, on the port on the Summit board labeled CONSOLE. The Beagle connects to my computer through RS232, a null modem cable, and a USB to serial adapter. I use screen. The problem comes when I use echo mem > /sys/power/state to suspend to ram, and then press some key to wake up the system. The Beagleboard comes up just fine. On the other hand, the Overo initially looks like it comes up fine, but I can no longer type anything into the prompt that appears. This looks suspiciously similar to Han Wang's problem, but I did a little more exploring via a quick test script to see how far the system gets. r...@overo:~# cat test.sh echo "I went to sleep" > log echo mem > /sys/power/state echo "HEY I WOKE UP" echo "HEY I WOKE UP" >> log sync r...@overo:~# Interestingly enough, when I run this script and resume on the Overo, I can see HEY I WOKE UP both in the console and the file (after a restart so I can type something to read the file)! So the problem is simply that I cannot type anything, not that the system isn't waking up, otherwise it wouldn't even get to the echoes. (Blindly typing in things afterward, including echoing to a file, does not seem to have an effect, unfortunately) Any ideas on what might be causing this discrepancy and whether there's anything I can do to fix? I appreciate your time. Peter Tseng [1] http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=commit;h=305f453e897e4673dd4c2b52ec7e2c4be2e2b035 [2] http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=summary [3] http://www.sakoman.com/feeds/omap3/glibc/images/overo/ -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM suspend to disk?
On 05/01/2010 03:12 AM, Shilimkar, Santosh wrote: >> -Original Message- >> From: linux-omap-ow...@vger.kernel.org >> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin >> Hilman >> Sent: Saturday, May 01, 2010 3:36 AM >> To: Cliff Brake >> Cc: Peter Tseng; linux-omap@vger.kernel.org >> Subject: Re: ARM suspend to disk? >> >> Cliff Brake writes: >> >>> On Thu, Apr 29, 2010 at 1:58 PM, Kevin Hilman >>> wrote: >>> >>>> What do you expect to gain from suspend-to-disk + snapshot boot that >>>> you don't already get from suspend-to-RAM using off-mode? >>>> >>>> On OMAP, with off-mode enabled, a suspend to RAM puts the entire OMAP >>>> into full-chip off, and essentially reboots the ARM when waking up >>>> from suspend (or idle) already. >>> >>> What does the resume process look like in off mode? Does the resume >>> pass through the bootloader? If so, are the bits that detects resume >>> from "off" available in U-boot? >> >> No, it does not pass through the boot loader. >> >> In general terms, resume from off-mode is the same to "normal" resume (from >> retention) except that some additional state has to be restored before >> continuing where you left off since the ARM core (as well as most the >> OMAP itself) was turned off. >> > On suspend to disk topic, Raghu under Romit's guidance did a > prototype few months back as part of his internship using some of the earlier > ARM work. The whole system snapshot was stored to the MMC card and one > can take that MMC card on another board and continue from where it was > suspended. > > We should have these patches somewhere. > It would be interesting to see these. Are you able to find these patches somewhere? Peter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM suspend to disk?
On 04/29/2010 01:58 PM, Kevin Hilman wrote: > Peter Tseng writes: > >> I last posted a few weeks ago; I'm Peter Tseng, using the Gumstix Overo >> for a project. I'm interested in power management and a few related >> things. A few of the things I am interested in are suspend to disk and >> snapshot boot. >> >> I found a page on elinux.org with a few notes on the issue for ARM. >> However, it looks to be a bit outdated: >> http://elinux.org/Suspend_To_Disk_For_ARM >> >> I am wondering how applicable anything on this page is to the current >> omap-pm developments. Or, if not, any pointers on how it might be done - >> for example, if I felt like I should do some hacking to try to get this >> working and contribute these back, a general outline of what I might >> have to do) > > Not really and answer to your question since I don't know the answer, > but just curious about your goals, since there may be an easier way. > > What do you expect to gain from suspend-to-disk + snapshot boot that > you don't already get from suspend-to-RAM using off-mode? > > On OMAP, with off-mode enabled, a suspend to RAM puts the entire OMAP > into full-chip off, and essentially reboots the ARM when waking up > from suspend (or idle) already. > My goals: I am researching very low power devices - the ideal final goal is to make devices such as e-book readers that can last for several months (with regular use) on a single battery charge. The power management capabilities of the OMAP have been helpful, but it does appear (unless I am doing something wrong?) that even with off-mode enabled, a suspend to RAM does still draw a few milliwatts of power. Granted, this isn't much, but when we multiply that over several months, it does add up. So I'd like to know if there's a way to reach zero, hence my earlier questions. Peter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap-pm: omap3_pm_defconfig no longer booting on Overo
On 04/30/2010 02:54 PM, Kevin Hilman wrote: > Peter Tseng writes: > >> Since the rc5 tag, omap3_pm_defconfig from the pm branch no longer boots >> on the Gumstix Overo. >> I am certain that a build back in the rc3 days worked. Unfortunately, I >> don't know about rc4, or anything that happenend in the intervening time. >> >> Any clues on how to fix? If necessary, I'll provide what info I can to >> help diagnose the issue if told what to do. > > First step is to enable CONFIG_LL_DEBUG and CONFIG_EARLYPRINTK in the > defconfig (I should have these enabled by default in omap3_pm_defconfig) > > Then, boot adding 'earlyprintk' to your boot cmdline and post the > resulting bootlog here. Here it is. (Forgot to also send to mailing list the first time around) Peter Tseng reading uImage 2069060 bytes read Booting from mmc ... ## Booting kernel from Legacy Image at 8200 ... Image Name: Linux-2.6.34-rc5-10043-g94e884a Image Type: ARM Linux Kernel Image (uncompressed) Data Size:2068996 Bytes = 2 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. Linux version 2.6.34-rc5-10043-g94e884a (leftyl...@lefty) (gcc version 4.4.1 (Sourcery G++ Lite 2009q3-67) ) #61 PREEMPT Fri Apr 30 23:00:48 EDT 2010 CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c53c7f CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: Gumstix Overo bootconsole [earlycon0] enabled Memory policy: ECC disabled, Data cache writeback OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp ) SRAM: Mapped pa 0x4020 to va 0xfe40 size: 0x10 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024 Kernel command line: console=ttyS2,115200n8 vram=12M omapfb.mode=dvi:1024x768mr...@60 omapfb.debug=y omapdss.def_disp=dvi root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait earlyprintk PID hash table entries: 1024 (order: 0, 4096 bytes) Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 128MB 128MB = 256MB total Memory: 255540k/255540k available, 6604k reserved, 0K highmem Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xfff0 - 0xfffe ( 896 kB) DMA : 0xffc0 - 0xffe0 ( 2 MB) vmalloc : 0xd080 - 0xf800 ( 632 MB) lowmem : 0xc000 - 0xd000 ( 256 MB) modules : 0xbf00 - 0xc000 ( 16 MB) .init : 0xc0008000 - 0xc0035000 ( 180 kB) .text : 0xc0035000 - 0xc03da000 (3732 kB) .data : 0xc03da000 - 0xc041cf60 ( 268 kB) SLUB: Genslabs=9, HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 Hierarchical RCU implementation. NR_IRQS:402 Clocking rate (Crystal/Core/MPU): 26.0/331/500 MHz kernel BUG at arch/arm/mach-omap2/resource34xx.c:229! Unable to handle kernel NULL pointer dereference at virtual address pgd = c0004000 [] *pgd= Internal error: Oops: 805 [#1] PREEMPT last sysfs file: Modules linked in: CPU: 0Not tainted (2.6.34-rc5-10043-g94e884a #61) PC is at __bug+0x20/0x2c LR is at vprintk+0x394/0x404 pc : []lr : []psr: 41d3 sp : c03dbf18 ip : c03dbe68 fp : c03dbf24 r10: 001f r9 : 411fc083 r8 : 80027764 r7 : c03de2d4 r6 : r5 : c041dfa0 r4 : c03f3424 r3 : r2 : c03dbe68 r1 : 81d3 r0 : 003c Flags: nZcv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel Control: 10c5387f Table: 80004019 DAC: 0017 Process swapper (pid: 0, stack limit = 0xc03da2e8) Stack: (0xc03dbf18 to 0xc03dc000) bf00: c03dbf4c c03dbf28 bf20: c004c9fc c00392d8 c005598c c01ce138 c03dbf4c c03f3424 c03fa128 bf40: c03dbf6c c03dbf50 c0055c7c c004c920 c03f3424 c0031a10 0034 c002a014 bf60: c03dbf84 c03dbf70 c0055d08 c0055bf4 c03f40b0 c03f40b0 c03dbf94 c03dbf88 bf80: c0016114 c0055cb0 c03dbfac c03dbf98 c000e518 c001610c c041cf80 c002a018 bfa0: c03dbfbc c03dbfb0 c0012858 c000e43c c03dbfcc c03dbfc0 c000b458 c0012834 bfc0: c03dbff4 c03dbfd0 c0008a8c c000b42c c00086d8 c002a018 bfe0: 10c53c7d c041d320 c03dbff8 80008034 c0008934 Backtrace: [] (__bug+0x0/0x2c) from [] (init_opp+0xe8/0x118) [] (init_opp+0x0/0x118) from [] (resource_register+0x94/0xbc) r6: r5:c03fa128 r4:c03f3424 [] (resource_register+0x0/0xbc) from [] (resource_init+0x64/0x84) r6:c002a014 r5:0034 r4:c0031a10 r3:c03f3424 [] (resource_init+0x0/0x84) from [] (omap_pm_if_init+0x14/0x20) r5:c03f40b0 r4:c03f40b0 [] (omap_pm_if_init+0x0/0x20) from [] (omap2_init_common_hw+0xe8/0x19c) [] (omap2_init_common_hw+0x0/0x19c) from [] (overo_init_irq+0x30/0x4c) r5:c002a018 r4:c041cf80 [] (overo_init_irq+0x0/0x4c) from [] (init_IRQ+0x3
omap-pm: omap3_pm_defconfig no longer booting on Overo
Since the rc5 tag, omap3_pm_defconfig from the pm branch no longer boots on the Gumstix Overo. I am certain that a build back in the rc3 days worked. Unfortunately, I don't know about rc4, or anything that happenend in the intervening time. Any clues on how to fix? If necessary, I'll provide what info I can to help diagnose the issue if told what to do. Peter Tseng -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
ARM suspend to disk?
Hey there, I last posted a few weeks ago; I'm Peter Tseng, using the Gumstix Overo for a project. I'm interested in power management and a few related things. A few of the things I am interested in are suspend to disk and snapshot boot. I found a page on elinux.org with a few notes on the issue for ARM. However, it looks to be a bit outdated: http://elinux.org/Suspend_To_Disk_For_ARM I am wondering how applicable anything on this page is to the current omap-pm developments. Or, if not, any pointers on how it might be done - for example, if I felt like I should do some hacking to try to get this working and contribute these back, a general outline of what I might have to do) Thanks for your time, Peter Tseng -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-omap-pm troubles on Gumstix Overo
On 04/07/2010 11:56 AM, Kevin Hilman wrote: > What's your commandline? Kernel command line: console=ttyS2,115200n8 mpurate=500 vram=12M omapfb.mode=dvi:1024x768mr...@60 omapfb.debug=y omapdss.def_disp=dvi root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait On 04/07/2010 06:01 PM, Kevin Hilman wrote: > OK, after some more digging, the Overo was hitting the same boot > problem I've been trying to track on Zoom3. I have now fixed this and > the PM branch omap3_pm_defconfig should boot again for Overo and > Zoom3. > > I've updated the PM branch now which includes a fix for a problem > introduced in in 2.6.34 due to early enabling of interrupts (see > details on LKML[1]). Interstingly, this was seen on PM branch where I > use the SLUB allocator by default, and not on l-o master where the > SLAB allocator is still used by default. > > Please pull a fresh PM branch and see if you get it booting on Overo. Thanks, Kevin! Yes, I just pulled the pm branch and the Overo is booting again. A few quirks to note: 1) As I hadn't grabbed the fixes for the OMAP4 compilation problems, I had to uncheck OMAP4 in the System Types as before. 2) Since I was booting off an SD card, I had to go to Device Drivers-->MMC/SD/SDIO Card and have the following be built in (rather than be a module) - MMC block device driver - SDHC Interface support - TI OMAP High Speed Multimedia Card interface support 3) I have a few error messages with the framebuffer as the kernel is booting up. It does still work, however. See [1] below. 4) Suspend to memory (echo mem > /sys/power/state) works now, but when I wake up the board (via a keypress), I am no longer able to type anything at the prompt. Any clue about this one? Peter [1] open /dev/fb0: No such file or directory open /dev/fb0: No such file or directory expr: syntax error Linux Frame Buffer Device Configuration Version 2.1 (23/06/1999) (C) Copyright 1995-1999 by Geert Uytterhoeven Usage: fbset [options] [mode] Valid options: (Insert very long options list here) Starting PVR Usage: insmod filename [args] FATAL: Module omaplfb not found. mknod: missing operand after `0' Try `mknod --help' for more information. chmod: cannot access `/dev/pvrsrvkm': No such file or director -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
linux-omap-pm troubles on Gumstix Overo
Hey there, My name's Peter and I'm working with the linux-omap-pm kernel on the Gumstix Overo board for an academic project. Back when the linux-omap-pm branch was still on 2.6.33-rc8, I could compile and run the kernel on the Overo without any problems. Suspend to memory (via mem > /sys/power/state) worked just fine. Unfortunately, ever since 2.6.34-rcX releases started coming out, I have been running into problems: First of all, I was under the impression that omap3_pm_defconfig was supposed to more-or-less work "out of the box". This has not been the case, as when I try to compile: make ARCH=arm omap3_pm_defconfig make ARCH=arm -j4 uImage CROSS_COMPILE=/opt/arm-2009q3/bin/arm-none-linux-gnueabi- I get these error messages back. arch/arm/mach-omap2/omap44xx-smc.S: Assembler messages: arch/arm/mach-omap2/omap44xx-smc.S:30: Error: missing expression -- `smc' make[1]: *** [arch/arm/mach-omap2/omap44xx-smc.o] Error 1 make: *** [arch/arm/mach-omap2] Error 2 Fortunately, this is solved by using menuconfig and un-checking the OMAP4 in System Type (this shouldn't affect anything, as the Overo is using the OMAP3...) Unfortunately, after building that, when I try to boot the Overo, this is as far as it gets: ## Booting kernel from Legacy Image at 8200 ... Image Name: Linux-2.6.34-rc3-09551-gb301cc7 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:1994520 Bytes = 1.9 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. I have no idea if it simply hangs here, or it is working and simply not printing anything to the serial console. (If it helps at all, the processor *seems* warm, but I cannot be sure of this). To see if the problem can be solved by going back to 2.6.33, I do a git checkout of the corresponding branch: git checkout -b stable v2.6.33 I compile with the attached .config file, and the overo boots up just fine (though at some point in the process modprobe complains to me about omaplfb not found...) However, now when I try to suspend, I get this: r...@overo:~# echo mem > /sys/power/state PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.01 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. Suspending console(s) (use no_console_suspend to debug) PM: suspend of devices complete after 109.004 msecs PM: late suspend of devices complete after 0.274 msecs Class driver suspend failed for cpu0 PM: early resume of devices complete after 0.030 msecs PM: resume of devices complete after 343.597 msecs Restarting tasks ... done. The "Class driver suspend failed for cpu0" is what concerns me, and I've tried a lot of stuff and have remained unable to get suspend working again. To summarize, my questions are: 1. Why do the 2.6.34-rcX kernels stop at "Uncompressing Linux... done, booting the kernel."? 2. Why does the 2.6.33 kernel fail to suspend with "Class driver suspend failed for cpu0"? Did I incorrectly perform the git checkout, or did I misconfigure something? 3. And finally, for my future work, since I am interested in power management, is there a possible solution to suspending to disk? (Perhaps termed "hibernate") I would greatly appreciate any pointers in the right direction so I can get this working again. Thanks a lot for your time and attention. Peter Tseng # # Automatically generated make config: don't edit # Linux kernel version: 2.6.33 # Thu Mar 18 00:59:57 2010 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_GENERIC_GPIO=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_HARDIRQS=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_ARCH_HAS_CPUFREQ=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y CONFIG_OPROFILE_ARMV7=y CONFIG_VECTORS_BASE=0x CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_CONSTRUCTORS=y # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_LZO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set # # RCU Subsystem # CONFIG_TREE_RCU=y # CONFIG_TREE_PREEMPT_RCU is not set # CONFIG_TINY_RCU is not set # CONFIG_RCU_TRACE is not set CONFIG_RCU_FANOUT=32 # CONF
