Hello NXP team,
I am currently experimenting with the T1040RDB and the T1040's low power modes.
I have aquired the SDK kernel source (commit 43cecda943a6c40a833b588801b0929e8bd48813) from http://git.freescale.com/git/cgit.cgi/ppc/sdk/linux.git and compiled it for the T1040RDB.
I booted the T1040RDB from NFS rootfs provided by the SDK, with above kernel and dtb. Bootup is successful.
See attached the kernel .config file.
Trying a simple wakeup from standby with the debug console ttyS0:
echo enabled > /sys/class/tty/ttyS0/power/wakeup
echo standby > /sys/power/state
This results in following console output:
PM: Syncing filesystems ... done.
mmc0: card b368 removed
Freezing user space processes ... (elapsed 0.001 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
Unable to handle kernel paging request for data at address 0x00000000
Faulting instruction address: 0xc002b2fc
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=8 CoreNet Generic
Modules linked in:
CPU: 3 PID: 1831 Comm: sh Not tainted 3.12.37-rt51-01312-g43cecda-dirty #13
task: e7340030 ti: e9c72000 task.ti: e9c72000
NIP: c002b2fc LR: c02dc080 CTR: c002b400
REGS: e9c73cf0 TRAP: 0300 Not tainted (3.12.37-rt51-01312-g43cecda-dirty)
MSR: 00029002 <CE,EE,ME> CR: 82242428 XER: 20000000
DEAR: 00000000, ESR: 00000000
GPR00: c02dc080 e9c73da0 e7340030 e92e9a00 c07b61b0 00000003 c0903805 01ffff3f
GPR08: c0910000 00000000 84000000 000001ca 22242422 100fc29c 100f0000 00000000
GPR16: 00000000 100f46b8 100f46a8 00000000 100f48c4 100874c0 100f0000 100e9dd8
GPR24: 00000001 00000002 e9c73f18 c08bdb08 00000001 e9c73df8 c08e98f8 e92e9a00
NIP [c002b2fc] fsl_set_power_except+0x2c/0x130
LR [c02dc080] dpm_for_each_dev+0x60/0xb0
Call Trace:
[e9c73da0] [c0903320] logbuf_lock+0x0/0x8 (unreliable)
[e9c73dd0] [c02dc080] dpm_for_each_dev+0x60/0xb0
[e9c73df0] [c002b520] qoriq_suspend_begin+0x30/0x70
[e9c73e10] [c0072c8c] suspend_devices_and_enter+0x4c/0x500
[e9c73e80] [c00733f0] pm_suspend+0x2b0/0x350
[e9c73ea0] [c0071eb4] state_store+0xb4/0xc0
[e9c73ec0] [c0169f60] sysfs_write_file+0x100/0x1b0
[e9c73ef0] [c0102c38] vfs_write+0xc8/0x1e0
[e9c73f10] [c010333c] SyS_write+0x4c/0xc0
[e9c73f40] [c000ff94] ret_from_syscall+0x0/0x3c
--- Exception: c01 at 0xfeedb08
LR = 0xfe89574
Instruction dump:
00000000 9421ffd0 7c0802a6 bf810020 7c7f1b79 90010034 7c9c2378 41c20024
813f004c 3c80c07b 388461b0 38a00003 <80690000> 4bfef2bd 2f830000 41de00c8
---[ end trace 248bd446994a111d ]---
However when I boot the RDB from Flash with the kernel and rootfs that were already pre-installed on the T1040RDB
(Linux version 3.8.13-rt9-QorIQ-SDK-T1040-BSP0.2 (jenkins@mars) (gcc version 4.7.3 (GCC) ) #1 SMP Thu Mar 6 22:21:26 CST 2014),
console wakeup seems to work.
root@t1040rdb:~# echo enabled > /sys/class/tty/ttyS0/power/wakeup
root@t1040rdb:~# echo standby > /sys/power/state
PM: Syncing filesystems ... done.
mmc0: card b368 removed
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)
< wakeup is possible here with console >
I poked around a little bit in arch/powerpc/platforms/85xx/qoriq_pm.c
I commented out the
if (dev && !strncmp(dev->bus->name, "usb", 3))
block, leaving only the
ret = of_property_read_u32_array(dev->of_node, "sleep",
value, 2);
command.
Now following console output happens:
PM: Syncing filesystems ... done.
mmc0: card b368 removed
Freezing user space processes ... (elapsed 0.001 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
tty ttyS0: Can not set wakeup sources
Suspending console(s) (use no_console_suspend to debug)
< here, the board goes into suspend and cannot be woken up by console >
More debugging showed the ret return value is 0xffffffea, likely corresponding to -EINVAL, meaning the requested property does not exist.
I am a little bit confused of what I might have done wrong.
Can you advise or point me in the right direction?
I will gladly provide more information if needed.
Best regards,
Stefan Lange
Original Attachment has been moved to: .config.zip
Hello Stefan Lange,
The feature that UART wakes up the sleep system is not supported in the latest SDK 1.9 release. This feature had already been supported in the previous QorIQ-SDK-T1040-BSP0.2 release.
I have already create a new work in our internal system(QSDK-2818) to require this feature is the latest Linux Kernel, please wait for the patch from the development team later.
Have a great day,
Yiping
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Since when is a kernel crash the way that the system advertises a feature as "not supported"? Since when is fixing kernel crashes "new work" rather than a bug fix? And since you say it worked in a previous release, doesn't that make this a regression?
Hello Scott,
The UART wakeup mode is not addressed in T1040RM, we cannot make sure whether it can work stably, so don't recommend the customer to use it. Please refer to QSDK-2818 in our internal defect tracking system.
Thanks,
Yiping
Hello Stefan Lange,
According to the RCPM chapter of T1040 RM, it supports the following wakeup source, not including UART.
The feature of waking on UART does not be supported when doing sleep/deep sleep.
It may work in the SDK released previously, but reference manual does not mention it, that is, the functionality is not supported officially.
If it is really needed, I need to contact the HW team to verify it to see if the functionality can work properly from the view point of hardware. Then require the software team to support it in SDK if the hardware is stable.
Is it possible for you to select other wake up mode rather than UART console in your product design?
Have a great day,
Yiping
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Hello Yiping,
thank you for your response, this is good to know.
I will work with USB wakeup for the moment, to test wakeup and low power functionality as such.
I will check internally whether UART wakeup functionality is such a hard requirement and come back to you if neccessary.
Thank you again for your support!
Best regards,
Stefan