Jump to content

Recommended Posts

Posted

Hi all,

 

We are now using ARMbian build tools as our 1st choice for all future DietPi SBC images.

Currently, we support these devices that use ARMbian at their base:

  • BPI Pro
  • BPI M2+
  • OPI PC
  • NanoPi Neo

 

I'd like to increase this so we can support more boards with the same ARM SoC (eg: H3). Unfortunately, like most, i do not have access to every SBC out there.

As we do further manual optimizations to the ARMbian images, after compile (eg: DietPi-RAMlog, DietPi-RAMdisk, package removals, prep for DietPi scripts etc etc), having the SBC device is essential to creating our image.

 

I'am curious to know if the following is true:

  • Are the Sun8i compiled kernels and modules the same for all devices with that SoC (H3), or are they unique for the device?
  • Is it just a case of matching the ARM SoC (eg: H3), use an existing Sun8i or Sun7i compiled image, then update the /boot/script.bin for the specific device?

Example:

  • Compile ARMbian for NanoPi Neo
  • We can now use this image for all H3 devices, as long as we copy the unique script.bin from /boot/bin for each device?

Thanks.

 

 

 

Another Question:

Whats in the packages linux-jessie-root-*? They seem to have alot of dependencies, is python really necessary?:

root@DietPi:~# apt-get install linux-jessie-root-orangepipc
The following NEW packages will be installed:
  dh-python file iso-codes libmagic1 libmpdec2 libpython-stdlib
  libpython2.7-minimal libpython2.7-stdlib libpython3-stdlib
  libpython3.4-minimal libpython3.4-stdlib libsqlite3-0
  linux-jessie-root-orangepipc lsb-release mime-support python
  python-apt-common python-minimal python2.7 python2.7-minimal python3
  python3-apt python3-minimal python3.4 python3.4-minimal
0 upgraded, 25 newly installed, 0 to remove and 0 not upgraded.
Need to get 11.7 MB of archives.
After this operation, 53.3 MB of additional disk space will be used.
Do you want to continue? [Y/n]

Thanks guys

Posted
  • Are the Sun8i compiled kernels and modules the same for all devices with that SoC (H3), or are they unique for the device?

Kernel is the same for one SoC, main differences for H3 boards are:

  • U-boot compile-time configuration
  • /boot/script.bin symlink
  • /etc/armbian-release configuration file
  • min/max frequency in /etc/default/cpufrequtils
  • /etc/modules - list of modules loaded at boot, i.e. for IR receiver, onboard wireless or USB serial gadget for headless boards

 

Whats in the packages linux-jessie-root-*? They seem to have alot of dependencies, is python really necessary?:

Different configuration files: https://github.com/igorpecovnik/lib/blob/master/makeboarddeb.sh

Python (python3-apt package specifically) is needed for MOTD update checker component (this)

Posted

Thanks zador.blood.stained,

 

 

min/max frequency in /etc/default/cpufrequtils

 
We don't install cpufreq on DietPi, gov and optional max freq is applied during boot to /sys/devices/system/cpu with script
 
Q: Is the .fex (script.bin) file responsible for these unique min/max clocks and vcore voltages (if i remember correctly)?


NanoPi Neo:
min=240 Mhz
max=1200 Mhz
 
BPi M2+
min=648 Mhz
max=1200 Mhz


 
 

U-boot compile-time configuration

 Q: On a default compile.sh and configuration.sh, what situations would render this unique to the device, if any?

 

/etc/modules

Ah yes, i see. modules available in /etc/modules are unique to the device.

It appears compiled modules are the same across all sun8i compiled images.

Q: Is it safe to say ARMbian builds the same modules on all devices and kernels?

 

root@DietPi:~# ls -lha /lib/modules/3.4.112-sun8i/kernel/drivers/net/wireless/
total 212K
drwxr-xr-x 21 root root 4.0K Aug  6 18:24 .
drwxr-xr-x  7 root root 4.0K Aug  6 18:24 ..
-rw-r--r--  1 root root  51K Aug  6 18:08 at76c50x-usb.ko
drwxr-xr-x  5 root root 4.0K Aug  6 18:24 ath
drwxr-xr-x  2 root root 4.0K Aug  6 18:24 bcmdhd
drwxr-xr-x  4 root root 4.0K Aug  6 18:24 brcm80211
drwxr-xr-x  2 root root 4.0K Aug  6 18:24 hostap
drwxr-xr-x  2 root root 4.0K Aug  6 18:24 iwmc3200wifi
drwxr-xr-x  2 root root 4.0K Aug  6 18:24 libertas
drwxr-xr-x  2 root root 4.0K Aug  6 18:24 libertas_tf
drwxr-xr-x  2 root root 4.0K Aug  6 18:24 mwifiex
drwxr-xr-x  2 root root 4.0K Aug  6 18:24 p54
-rw-r--r--  1 root root  43K Aug  6 18:08 rndis_wlan.ko
drwxr-xr-x  2 root root 4.0K Aug  6 18:24 rt2x00
drwxr-xr-x  2 root root 4.0K Aug  6 18:24 rtl8188eu
drwxr-xr-x  2 root root 4.0K Aug  6 18:24 rtl8189ES_linux
drwxr-xr-x  2 root root 4.0K Aug  6 18:24 rtl8189fs
drwxr-xr-x  3 root root 4.0K Aug  6 18:24 rtl818x
drwxr-xr-x  2 root root 4.0K Aug  6 18:24 rtl8723bs
drwxr-xr-x  4 root root 4.0K Aug  6 18:24 rtlwifi
drwxr-xr-x  2 root root 4.0K Aug  6 18:24 wl1251
drwxr-xr-x  2 root root 4.0K Aug  6 18:24 wl12xx
-rw-r--r--  1 root root  31K Aug  6 18:08 zd1201.ko
drwxr-xr-x  2 root root 4.0K Aug  6 18:24 zd1211rw
root@DietPi:~#

 

 

Posted

We don't install cpufreq on DietPi, gov and optional max freq is applied during boot to /sys/devices/system/cpu with script

 

Q: Is the .fex (script.bin) file responsible for these unique min/max clocks and vcore voltages (if i remember correctly)?

 

 

NanoPi Neo:

min=240 Mhz

max=1200 Mhz

 

BPi M2+

min=648 Mhz

max=1200 Mhz

 

 

 

These values have to be in sync on all H3 boards that use a programmable voltage regulator (two don't: Beelink X2 and the BPi M2+, so there it doesn't matter what's defined in dvfs section and only the [cooler_table] stuff matters). Currently we have a bug in our settings for Nano Pi M1 (240 MHz min in cpufrequtils config but only 480 MHz allowing in fex file through [cooler_table] entries).

 

Please be aware that especially for H3 boards a few things might change in the future since we're currently doing some research how we can run these boards with minimum consumption. We found out that lowering DRAM clock greatly helps with lowering consumption which requires a kernel patch. In case we find out that this patch lowering minimum DRAM clock triggers side effects on the larger H3 devices we might come to the conclusion to activate this kernel patch only for 'low-power' boards like Nano Pi NEO/Air or Orange Pi One/Lite (but I doubt that we will go this route, using a single kernel per $LINUXFAMILIY is nothing you give up for small gains in another area).

 

Further readings (maybe interesting for you since 'DietPi' suggests it's also about low consumption):

Posted

Q: Is the .fex (script.bin) file responsible for these unique min/max clocks and vcore voltages (if i remember correctly)?

Yes, you can't set CPU frequency lower than min_freq and higher than max_freq from [dvfs_table] section.

 

 Q: On a default compile.sh and configuration.sh, what situations would render this unique to the device, if any?

 

 

$ grep -r BOOTCONFIG config/boards
config/boards/armada.conf:BOOTCONFIG=armada_38x_clearfog_config
config/boards/aw-som-a20.conf:BOOTCONFIG=Awsom_defconfig
config/boards/bananapi.conf:BOOTCONFIG=Bananapi_defconfig
config/boards/bananapim2.conf:BOOTCONFIG=Sinovoip_BPI_M2_defconfig
config/boards/bananapim2plus.conf:BOOTCONFIG=Sinovoip_BPI_M2_plus_defconfig
config/boards/bananapipro.conf:BOOTCONFIG=Bananapro_defconfig
config/boards/beelinkx2.conf:BOOTCONFIG=orangepi_pc_defconfig
config/boards/cubieboard.conf:BOOTCONFIG=Cubieboard_config
config/boards/cubieboard2.conf:BOOTCONFIG=Cubieboard2_config
config/boards/cubieboard4.conf.disabled:BOOTCONFIG=Cubieboard4_defconfig
config/boards/cubietruck.conf:BOOTCONFIG=Cubietruck_config
config/boards/cubox-i.conf:BOOTCONFIG=mx6_cubox-i_config
config/boards/guitar.conf:BOOTCONFIG=s500_defconfig
config/boards/lamobo-r1.conf:BOOTCONFIG=Lamobo_R1_defconfig
config/boards/lime-a10.conf:BOOTCONFIG=A10-OLinuXino-Lime_defconfig
config/boards/lime.conf:BOOTCONFIG=A20-OLinuXino-Lime_defconfig
config/boards/lime2.conf:BOOTCONFIG=A20-OLinuXino-Lime2_defconfig
config/boards/micro.conf:BOOTCONFIG=A20-OLinuXino_MICRO_config
config/boards/nanopim1.conf:BOOTCONFIG=FriendlyARM_NanoPi_M1_defconfig
config/boards/nanopineo.conf:BOOTCONFIG=FriendlyARM_NanoPi_M1_defconfig
config/boards/odroidc1.conf:BOOTCONFIG=odroidc_config
config/boards/odroidc2.conf:BOOTCONFIG=odroidc2_config
config/boards/odroidxu4.conf:BOOTCONFIG=odroid_config
config/boards/olinux-som-a13.conf:BOOTCONFIG=A13-OLinuXino_defconfig
config/boards/orangepi.conf:BOOTCONFIG=Orangepi_defconfig
config/boards/orangepi2.conf:BOOTCONFIG=orangepi_2_defconfig
config/boards/orangepih3.conf.disabled:BOOTCONFIG=orangepi_h3_defconfig
config/boards/orangepilite.conf:BOOTCONFIG=orangepi_one_defconfig
config/boards/orangepimini.conf:BOOTCONFIG=Orangepi_mini_defconfig
config/boards/orangepione.conf:BOOTCONFIG=orangepi_one_defconfig
config/boards/orangepipc.conf:BOOTCONFIG=orangepi_pc_defconfig
config/boards/orangepipcplus.conf:BOOTCONFIG=orangepi_pc_defconfig
config/boards/orangepiplus.conf:BOOTCONFIG=orangepi_plus_defconfig
config/boards/orangepiplus2e.conf:BOOTCONFIG=orangepi_pc_defconfig
config/boards/pcduino2.conf:BOOTCONFIG=Linksprite_pcDuino
config/boards/pcduino3.conf:BOOTCONFIG=Linksprite_pcDuino3_defconfig
config/boards/pcduino3nano.conf:BOOTCONFIG=Linksprite_pcDuino3_Nano_defconfig
config/boards/pine64.conf:BOOTCONFIG=pine64_defconfig
config/boards/pine64plus.conf:BOOTCONFIG=pine64_plus_defconfig
config/boards/roseapple.conf:BOOTCONFIG=actduino_bubble_gum_v10_defconfig
config/boards/toradex.conf.disabled:BOOTCONFIG=colibri_imx6_defconfig
config/boards/udoo-neo.conf:BOOTCONFIG=udoo_neo_config
config/boards/udoo.conf:BOOTCONFIG=udoo_qdl_config

 

 

You can find and compare u-boot configs for A10/A20/H3 boards in mainline u-boot sources.

TL;DR main differences for H3 boards:

CONFIG_MMC_SUNXI_SLOT_EXTRA - eMMC support

CONFIG_SYS_EXTRA_OPTIONS="SATAPWR=SUNXI_GPG(11)" - onboard USB-to-SATA bridge support

CONFIG_USB1_VBUS_PIN - USB power related configuration

CONFIG_SY8106A_POWER - support for voltage regulator

CONFIG_DRAM_CLK - different DRAM frequency

 

Q: Is it safe to say ARMbian builds the same modules on all devices and kernels?

No. Depends on kernel version, user requests and default kernel configuration.

Posted

Thanks guys, exactly the info I was after.

 

Yep, so uboot settings can be unique to the device, rather than just the SoC type:

 

 

OPi PC = CONFIG_DRAM_CLK=624
OPi Lite = CONFIG_DRAM_CLK=672

 

 

 

So in theory, if I want to use an existing image for a device, I'd need to match the device I want to target, with another device that has the same uboot configuration.

 

Q: Does the .fex (.bin) override the uboot clocks/power regulation etc, rendering the unique uboot settings void?

 

 

 

 

edit:

 

 

Further readings (maybe interesting for you since 'DietPi' suggests it's also about low consumption):

Thanks. I'am all for getting everything little thing out of the device, including power usage  :).

Prime example is the Odroid C1/C2. The HK images have the CPU set to Performance gov by default, we use Ondemand which reduces power consumption when idle by 0.1w~ and heat by 3-5'c.

 

@tkaiser Not sure how I could help at the moment. Do you have some settings that need stability testing for the NanoPi Neo? I can leave it running and report results.

Posted

Q: Does the .fex (.bin) override the uboot clocks/power regulation etc, rendering the unique uboot settings void?

 

 

 

First: All H3 devices should use 624 MHz DRAM clockspeed in u-boot ATM -- if this differs then it's a mistake. Then: this might change with regards to NanoPi NEO and Air if we decide that we want to provide settings (and a daemon on top) that controls power, then both DRAM and CPU clockspeed might be reduced already in u-boot so that maximum consumption while booting doesn't exceed 1W for example. Unfortunately my NanoPi dev samples still did not arrive so further tests are postponed.

 

Fex settings still do matter but only in situations when H3 legacy kernel starts to throttle since then DRAM clockspeed from fex file will be used (can be disabled in kernel config but this is a useful feature for low-power operations to automagically increase also DRAM clockspeed when overall load increases)

 

So there's not much to test at the moment, just being patient (I learned that the last weeks since my attempt to do consumption measurements relies on '30 min averaged values' which are pretty precise to my surprise)

 

BTW: Currently testing with DietPi on a RPi 3 and both idle as well as maximum consumption need some explanation. But tests are still running (need additional hours to be reliable enough) and I will add the stuff to the other thread later (maybe tomorrow -- time for beergarden now)

Posted

Thanks Tkaiser,

 

 

BTW: Currently testing with DietPi on a RPi 3 and both idle as well as maximum consumption need some explanation. But tests are still running (need additional hours to be reliable enough) and I will add the stuff to the other thread later (maybe tomorrow -- time for beergarden now)

 

Would be interesting to see the results, and, if needed, work on improving those results.

 

I still havn't found a way of physically disabling the onboard BCM wifi/bt. The best we have at the moment is module blacklists, but the chip will still be drawing power i'd assume.

Posted

Would be interesting to see the results, and, if needed, work on improving those results.

 

Here somewhat off-topic but anyway: I noticed slightly higher idle consumption when running DietPi, also sysbench execution time when no throttling is active is slightly higher (which could be an indication for constant background activity?): http://forum.armbian.com/index.php/topic/1748-sbc-consumptionperformance-comparisons/?view=getlastpost

 

I won't investigate further regarding Raspberries since I've only one single use case for these devices: HW accelerated video encoding. Therefore I will only do some consumption measurements with the Zero and 3 different cameras in this area and won't look into more details regarding DietPi on the other RPi models.

 

But just as a summarized conclusion regarding RPi 3 (and DietPi):

  • RPi 3 shows a higher idle consumption than RPi 2 most probably due to WiFi/BT always being powered on (blacklisting drivers and removing hardware from DT doesn't change consumption numbers a lot according to several forum posts)
  • With DietPi idle consumption is even higher (reason unknown)
  • Disabling CPU cores on RPi 3 shows weird effects (idle consumption with only one CPU core active increases by 360 mW and difference between idle and single-core sysbench is +1120 mW which is totally weird since in quad-core operation difference between idle and sysbench is +2385 mW so a single sysbench thread should only add +600mW max)
  • Throttling on RPi 3 seems to be implemented very inefficiently with only 2 DVFS operating points and voltage switching obviously way too slow (adding a few more operating points at the upper frequency range would greatly improve performance in throttling situations!)

So there's a lot to do to improve RPi 3 consumption numbers but this would be totally off-topic here since we won't support Raspberries anytime soon and not that much knowledge regarding this platform is available here. Maybe this is something for RPi forums to discuss further (tried to get an account there but still not received an email).

 

In case you want to further investigate: how to use your Banana Pro as 'monitoring PSU' explained (with template and code stubs) in post #26 here (results are pretty accurate based on the RPi numbers and all you need is a little time to set things up and patience when doing real measurements)

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines