Thanks for your comment. Finally, i find out that i made a mistake. The uart(8250) have not been restore after resume, instead, it use the configuration got from boot. The uart have not been restored correctly, so that "ls" can not output result correctly resulting in it seems that the busybox can not work correctly. Now, i still have a question about the uart: why the "printk" can work correctly, but the "printf" not?

Before this, i believe that the "printk" work correctly, then the uart work ok. but now, i need more reconsidaration about the relation between the "printk", "printf" and "uart". Can anyone give me some suggestion? Any comment is welcome, thanks a lot.

在 2012年3月9日 下午10:08，Chenglie He chengjie.he@linaro.org写道：

Hi,

I am doing this on A9, echo mem >/sys/power/state is right, will trigger kernel to sleep.

-jack

On 7 March 2012 23:05, yang gqyang hustgqyang@gmail.com wrote:

...

dear all: I am working on arm cortex a8 now, trying to implement "suspend to ram" based on linux 3.0.8. Before i start my work, the soc already support standby(the cpu is on wfi state), so in order to implement "suspend to ram", i think i just need to implement the arch-specific related api. The "suspend to ram" works like this: "echo mem > /sys/power/state" -> enter_state -> suspend_devices_and_enter ->suspend_ops->enter(state) Is that right? Do you think the "suspend to ram" can be realized in this way? In order to power off the cortex A8, i save all the writable co-processor and all modes's state register set, and restore them when resuming. All the code seems work ok, because when I just does not power off the cortex-A8 and jump to excute the resume code, the system works well. But, when I power off the cpu, and wake up and excute resume code, the kernel seem ok, but the busybox toolkit does not work proper, eg: "ls" can not output the result through serial port. i add "printk statement" trying to locate the reason, but at this time, the "ls" work fine. hence, i doubt something must be corrupted after resume. I have checked all the state register and co-processor, having not found any exception, and I also compared all the dram data before power off and after wake up, nothing have changed. Right now, I do not know what has happened, and what should I do to locate the real problem to make the busybox works ok. I also want to know does the linux kernel 3.0.8 support "suspend to ram" like this: "echo mem > /sys/power/state" -> enter_state -> suspend_devices_and_enter ->suspend_ops->enter(state)? Can anyone give me some suggestion? Any comment is welcome, thanks a lot.

...

-- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

---

linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev

hi yang,

在 2012年3月10日 下午10:37，yang gqyang hustgqyang@gmail.com 写道：

Thanks for your comment.  Finally, i find out that i made a mistake.  The uart(8250) have not been  restore after resume, instead, it use the configuration got from boot. The  uart have not been restored correctly, so that "ls" can not output result  correctly resulting in it seems that the busybox can not work correctly.  Now, i still have a question about the uart: why the "printk" can work  correctly, but the "printf" not?

Before this, i believe that the "printk" work correctly, then the uart  work ok. but now, i  need more reconsidaration about  the relation between the "printk", "printf" and "uart".  Can anyone give me some suggestion? Any comment is welcome, thanks a  lot.

printk use "struct console" driver, it doesn't depend on a device node for userspace. printf actaully depends on uart_driver and a /dev/ttySx device node, stdout and stderr are redirected to /dev/ttySx uart is just a hardware which can be a tty or kernel console output.

-barry