Power consumption (SBC Lynx)

Info Box Applies to SBC Lynx

Introduction

Providing theoretical power consumption values would be useless for the majority of system designers building their application upon SBC Lynx board. Practically speaking, these figures would be of no help when it comes to size power supply unit or to perform thermal design of real systems. Instead, several configurations have been tested in order to provide figures that are measured on real-world use cases.

Please note that SBC Lynx platform is extremely flexible, so it is virtually impossible to test for all possible configurations and applications on the market. The use cases here presented should cover most of real-world scenarios. However actual customer's application might require more power than values reported here or customer's use case may be differ significantly with respect to the ones here considered. Therefore, application-specific requirements have always to be taken into consideration in order to size power supply unit and to implement thermal management properly.

The following picture shows a simplified block diagram of the measurement system.

Simplified block diagram of the measurement system

Two custom power probes have been used:

• power probe #1 is connected to the input power rail (12V) supplying the entire system (including LCD panel logic and backlight if present)
• power probe #2 is connected to the input power rail of the PMIC NXP PF3000 (nominal voltage is 3.75V); this, in turn, powers the processor subsystem.

Heavy load configurations

Measurements have been performed on the following platform (also denoted as testbed1 in the rest of the document):

• SBC Lynx rev.0 (S-XUBB0000C0R) equipped with a plug-in board for 24-bit RGB LCD interfacing
• LCD p/n: KOE TX11D06vm2Apa (https://www.koe-europe.com/doc/TX11D06VM2APA.pdf)
• System software: XUELK 0.9.0, patched to include 24-bit RGB LCD support
• root file system mounted via NFS over Ethernet connection
• processor's LDO is enabled (required to perform voltage scaling).

The following table shows the summary result of data collected at different checkpoints:

Checkpoint	Board power consumption (probe #1) [mW]	Processor subsystem power consumption (probe #2) [mW]
U-Boot prompt	760	568
Linux prompt [1]	2390	1270
StressAppTest (LCD Blanked)	1980	1610
StressAppTest	2780	1620
Complete Stress Test	3070	1880

[1] In this condition, Linux kernel spends most of the time in idle state because user space applications and interrupt service routines run for very short periods. However, LCD is turned on (LCD power consumption is about 600mW).

Additional notes and reference:

• U-boot is set run processor at 396MHz
• At U-boot prompt the LCD interface and circuitry are turned off
• At Linux prompt, a fixed processor clock frequency of 528MHz has been set (via userspace governor)
• StressAppTest application is used to stress CPU and DDR3L RAM (https://github.com/stressapptest/stressapptest)
• A 4.3 inches 480x272 LCD is used to test the 24bit parallel video interface output. The LCD backlight is driven by the 12V VIN using an external circuitry; brightness is set to 100%
• Complete Stress Test includes the following tests:
  • StressAppTest
  • USB host: read/write/verify operations on a USB memory stick
  • USB otg tested as Host: read/write/verify operations on an USB memory stick
  • uSD card: read/write/verify operations
  • Ethernet: iperf TCP test running
  • NAND: stress test with mtd kernel modules.

Idle configurations

Some power-constrained applications can't afford to make use of deep-sleep mode when the system has nothing to do, because wake up process may take too long to complete. In such situations aggressive implementation of so-called idle mode can come to help. Basic assumption is that the system spends most of the time in a system idle condition (that is there are no user applications ready to run nor interrupt requests to serve).

Two idle configurations have been tested, detailed in the following sections. Nomenclature is the same used in the processor's data sheet.

Measurements have been performed on the following platform (also denoted as testbed2 in the rest of the document):

• SBC Lynx rev.0 (S-XUBB0000C0R)
• System software: XUELK 0.9.0
• UBIFS root file system mounted from Flash NAND
• processor's LDO is enabled (required to perform voltage scaling)
• Some hardware optimizations have been implemented to minimize power consumption:
  • CAN transceiver has been turned off
  • all the unneeded pull-ups on signals in the VDD_SNVS_IN voltage domain have been removed
  • RS232 transceiver is shutdown via unused processor's GPIO
  • RS485 polarization network has been removed.

System idle

In this case the default governor (interactive) is used.

root@sbc-lynx:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
interactive

Board power consumption (probe #1) [1] [mW]	Processor subsystem power consumption (probe #2) [1] [mW]
370	325

[1] 24MHz active oscillator power consumption is included. As the board under test is equipped with iMX6UL revision 1.0, active oscillator is required to implement the fix described by errata ERR009455. Typical consumption of this oscillator is about 20mW. Future revision of the board will be populated with silicon revision 1.1 or newer. Thus active oscillator will be removed. For more details please refer to Chip Errata for the i.MX 6UltraLite.

Low-power idle

In this case the powersave governor is used. As described in i.MX 6UltraLite Power Consumption Measurement application note, the use of this governor allows to reduce power consumption significantly in idle condition, as detailed in the following table.

Board power consumption (probe #1) [1] [mW]	Processor subsystem power consumption (probe #2) [1] [mW]
90	72

[1] 24MHz active oscillator power consumption is included. As the board under test is equipped with iMX6UL revision 1.0, active oscillator is required to implement the fix described by errata ERR009455. Typical consumption of this oscillator is about 20mW. Future revision of the board will be populated with silicon revision 1.1 or newer. Thus active oscillator will be removed. For more details please refer to Chip Errata for the i.MX 6UltraLite.

To configure the system to perform this test, the following commands have been used.

#!/bin/bash

echo 8 > /proc/sys/kernel/printk

ifconfig eth0 down

echo powersave > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

# Disable MPUART0 (RS232 transceiver)
# MPUART0_ON
echo 83 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio83/direction
echo 0 > /sys/class/gpio/gpio83/value

# MPUART0_DEN
echo 136 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio136/direction
echo 0 > /sys/class/gpio/gpio136/value

# MPUART0_RXEN
echo 137 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio137/direction
echo 0 > /sys/class/gpio/gpio137/value

# Disable MPUART1 (RS485 transceiver)
# MPUART1_ON
echo 84 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio84/direction
echo 0 > /sys/class/gpio/gpio84/value

The system automatically switch between low-power idle and normal idle states when needed:

root@sbc-lynx:~# ./idle.sh
root@sbc-lynx:~#
Bus freq set to 24000000 start...
Bus freq set to 24000000 done!

Bus freq set to 400000000 start...
Bus freq set to 400000000 done!

Bus freq set to 24000000 start...
Bus freq set to 24000000 done!

Bus freq set to 400000000 start...
Bus freq set to 400000000 done!

Bus freq set to 24000000 start...
Bus freq set to 24000000 done!

root@sbc-lynx:~#
root@sbc-lynx:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
powersave

It is worth to remember that the use of powersave governor has a drawback in terms of system reactivity, because processor is relatively slow to get out of the idle condition. This can lead to phenomena such as the UART RX FIFO overrun, shown in the following box. In this example, a relatively long command string has been pasted into the serial console terminal:

root@sbc-lynx:~# imx-uart 2020000.serial: Rx FIFO overrun
cat /sys/devices/system/cpu/cpugovernor
cat: /sys/devices/system/cpu/cpugovernor: No such file or directory
root@sbc-lynx:~#

Deep-sleep mode (aka suspend)

TBD intro

Measurements have been performed on the same conditions of testbed2 as described here

Board power consumption (probe #1) [1] [mW]	Processor subsystem power consumption (probe #2) [1] [mW]
63	51

[1] Power consumption of the following parts is excluded:

• CAN PHY
• RS485 polarization network
• RS232 and RS485 are in shutdown mode
• Ethernet link

To configure the system to perform the deep-sleep mode, the following commands have been used.

• Enable wakeup from console:

root@sbc-lynx:~# echo enabled > /sys/devices/soc0/soc.0/2000000.aips-bus/2000000.spba-bus/2020000.serial/tty/ttymxc0/power/wakeup

• Enter suspend to memory, and wakeup from suspend:

root@sbc-lynx:~# echo mem > /sys/power/state
PM: Syncing filesystems ...

Bus freq set to 400000000 start...
Bus freq set to 400000000 done!
done.
PM: Preparing system for mem sleep
Freezing user space processes ... (elapsed 0.001 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
PM: Entering mem sleep
Suspending console(s) (use no_console_suspend to debug)
PM: suspend of devices complete after 8.809 msecs
PM: suspend devices took 0.010 seconds
PM: late suspend of devices complete after 0.917 msecs
PM: noirq suspend of devices complete after 1.026 msecs
Disabling non-boot CPUs ...
PM: noirq resume of devices complete after 0.567 msecs
PM: early resume of devices complete after 0.715 msecs
gpmi-nand 1806000.gpmi-nand: mode:4 ,failed in set feature.
PM: resume of devices complete after 8.424 msecs
PM: resume devices took 0.010 seconds
PM: Finishing wakeup.
Restarting tasks ... done.
root@sbc-lynx:~#
Bus freq set to 24000000 start...
Bus freq set to 24000000 done!

root@sbc-lynx:~#

---