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

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
• RFS mounted via NFS
• 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	854
Linux prompt [1]	1000
StressAppTest	1200
StressAppTest + LCD	2220
Complete Stress Test + LCD	2880

[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 600mA).

Additional notes and reference:

• U-boot is set to work at 396MHz
• At Linux prompt, a fixed clock frequency of 528MHz has been set (userspace governor)
• All the measures include Ethernet link at 100M
• StressAppTest application is used to stress CPU and DDR3 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 at 100% brightness
• Complete Stress Test includes the following tests:
  • StressAppTest
  • USB Host: read/write/verify on an USB stick
  • USB otg tested as Host: read/write/verify on an USB stick
  • uSD card: read/write/verify
  • ETH: iperf TCP test at 100M
  • NAND: stress test with mtd kernel modules

Idle configurations

Some power-constrained applications can't afford to make use of deep-sleep mode because wake up process takes 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).

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
• RFS mounted via UBIFS in Flash NAND
• processor's LDO is enabled (required to perform voltage scaling)
• Some HW modifications are required to obtain the minimum power consumption:
  • CAN Transceiver SN65HVD232 (U4) is removed, beaceuse it doesn't have low power functionality
  • All the unneeded pull-ups on signals in the VDD_SNVS_IN voltage domain are removed
  • LCD_DATA14 is connected to MPUART0_ON signal in order to shutdown RS232 transceiver
• Power monitors: two custom current probes have been used
  • power probe #1 is connected to the input power rail at 12V
  • power probe #2 is connected to the input power rail of the PMIC NXP PF3000; this, in turn, powers NXP iMX6UL processor, DDR3L SDRAM, Flash memories, Ethernet PHY, TBD

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

Please note that the consumption measured by power probe #2 takes into account PMIC PF3000 too. TBD

System idle

In this case the default interactive governor is used.

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

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

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

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

[2] 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],[2] [mW]	Processor subsystem power consumption (probe #2) [1],[2] [mW]
90	68-74

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

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

[2] 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. Here is an example of an entire command pasted into the serial console leading to the Rx FIFO overrun issue:

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 as described in testbed2

Board power consumption (probe #1) [1] [mW]	Processor subsystem power consumption (probe #2) [1] [mW]
57-66	47-53

[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:~#

---