Jump to content

NanoPI NEO / AIR

Per-Mattias Nordkvist
 Share

Recommended Posts

tkaiser

tkaiser

Posted
Posted

Nice, suitable heatsinks for the H3 would be these: http://www.ebay.de/itm/172290970476. Add a very small dab of heat conductive glue, for example http://www.ebay.de/itm/181026615992

 

 

Thanks for the insights and recommendations -- already ordered both and will test to compare with FA's and my default heatsinks.

 

Important UPDATE on OS images:

 

Armbian test images with vanilla kernel 4.6.7 also added to download page: http://www.armbian.com/nanopi-neo/

 

More experimental images based on 4.7.2 with USB OTG support (to be confirmed) and schedutil cpufreq governor available but not active by default here: http://kaiser-edv.de/tmp/w8JAAY/

 

This is Jessie boot log with 4.7.2 on a NanoPi NEO. Ethernet and throttling are working (the latter not that efficient as with legacy kernel but at least it protects the SoC from overheating). Please note that all vanilla kernel images currently suffer from random MAC addresses on reboot so better choose a static IP address configuration. Also keep in mind that current cpufreq scaling settings in mainline kernel don't know the 912 MHz operating point so with our default /etc/defaults/cpufrequtils contents you end up with 816 MHz max cpufreq (feel free to adjust, throttling works with these images).

 

On 4.7 it's possible to test with the new schedutil cpufreq governor. In case you want to try it out and push the envelope adjust /etc/default/cpufrequtils that it reads like this

ENABLE=true
MIN_SPEED=240000
MAX_SPEED=1200000
GOVERNOR=schedutil

Then reboot or restart cpufrequtils, test some stuff and check /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state before/after to compare with ondemand. Also use 'sudo armbianmonitor -m' in another shell while testing.

tkaiser

tkaiser

Posted
Posted

Docker is running on Neo with this image :thumbup:

 

Of course it's running -- depends on kernel version only. But Docker on the NEO? 256MB variant? ;)

 

Anyway: If I would want to use docker I would choose any of the other boards with more DRAM.

 

Important: the aforementioned mainline kernel Armbian images for NEO can also be used on all the other H3 boards that use the primitive voltage regulator only switching between 1.1V and 1.3V: NanoPi M1, Orange Pi One, Orange Pi Lite.

 

You can grab the images, boot your board with this and then simply execute the script lines below as root (using the correct board name of course as $MyBoard variable!):

MyBoard="Orange Pi Lite"
MyBoardName="$(echo "${MyBoard}" | tr '[:upper:]' '[:lower:]' | sed -e 's/\ //g')"
cat <<-EOF >/etc/armbian-release
# PLEASE DO NOT EDIT THIS FILE
BOARD=${MyBoardName}
ID="${MyBoard}"
VERSION=5.17
LINUXFAMILY=sun8i
BRANCH=dev
ARCH=arm
EOF
sed -i "s/nanopineo/${MyBoardName}/" /etc/hostname
sed -i "s/MAX_SPEED=\(.*\)/MAX_SPEED=1200000/" /etc/default/cpufrequtils
uname -r | grep -q '4.7' && sed -i "s/GOVERNOR=\(.*\)/GOVERNOR=schedutil/" /etc/default/cpufrequtils
echo "${MyBoardName}" | grep -q lite && echo "8189fs" >>/etc/modules

Please note: these are still test images and you won't be able to upgrade later if we provide official vanilla images (unless you're somewhat familiar with Debian's/Ubuntu's package management).

 

Please also note: when you want to test out OPi Lite this way then better remove the motd stuff prior to booting (rm /etc/update-motd.d/*) since due to missing network login will not be possible afterwards (or if you have any of the supported Ethernet dongles, choose the Debian Jessie image, attach the Ethernet dongle prior to boot since in Jessie this will be available as eth0 afterwards on the Lite -- no idea why this does not work with our Xenial images)

 

I tested the procedure above with an Orange Pi Lite and had to add the following to get WiFi working (thanks to @jernej and @martinayotte WiFi also works with mainline kernel):

root@orangepilite:~# grep -A2 "g wlan0" /etc/network/interfaces  
allow-hotplug wlan0
iface wlan0 inet dhcp
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

root@orangepilite:~# cat /etc/wpa_supplicant/wpa_supplicant.conf
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
network={
        ssid="Snort-Honeynet"
        psk="secret"
        key_mgmt=WPA-PSK
        priority=99
}

And a final note: I wasted almost 15 minutes with WiFi and got no IP address until I realized that connecting the antenna to the board would greatly improve WiFi capabilities. Once done everything worked perfectly ;)

 

Orange Pi Lite booting such a transformed NEO image: http://sprunge.us/dWbN  (in between booting on a NanoPi M1, that's where the 1GB DRAM in the logs originate from ;) )

 

this is probbly a stupid question but how do i get SPI back?

 

Please note, that we provided 4 test images and that part of the test is telling us what works and what does not work. It's not the question of how to 'bring stuff back' but to help developers improve things. And since you do not even tell which image you use it's absolutely impossible to give an answer (4.6.7 or 4.7.2? Ubuntu or Jessie? Maybe SPI needs device-tree overlays, at least with 4.7 Martin's patches didn't apply clean)

YonNomNom

YonNomNom

Posted
Posted

Apologies for my ignorance on the subject.

 

I have tested both 4.6.7 and 4.7.2 Xenial images and neither had a spi device in /dev/. 

tkaiser

tkaiser

Posted
Posted

Apologies for my ignorance on the subject.

 

I have tested both 4.6.7 and 4.7.2 Xenial images and neither had a spi device in /dev/. 

 

Please read through this thread: http://forum.armbian.com/index.php/topic/1537-397-maintainfix-dts-entries-for-some-devices-such-i2cspiw1/

 

In short: Without device tree nodes defined you won't get I2C or SPI or any other hardware features now without either patches or device-tree overlays (Martin provided a patch for). I lack the skills how to add this stuff, better open a new more general thread (and search through forums first please) how to deal with I2C, SPI and stuff like that with mainline kernel on H3 boards (where all this is WiP and stuff not being sent upstream now).

martinayotte

martinayotte

Posted
Posted

For those who are interested, here are some DT Overlay samples.

 

i2c-enable.dts :

 

 

// Enable the i2c interface
/dts-v1/;
/plugin/;

/ {
    compatible = "allwinner,sun8i-h3";

    fragment@0 {
    target-path = "/aliases";
    __overlay__ {
            /* Path to the i2c2 controller node */
            i2c0 = "/soc@01c00000/i2c@01c2ac00";
            i2c1 = "/soc@01c00000/i2c@01c2b000";
            i2c2 = "/soc@01c00000/i2c@01c2b400";
        };
    };
    fragment@1 {
        target = <&i2c0>;
        __overlay__ {
            status = "okay";
        };
    };
    fragment@2 {
        target = <&i2c1>;
        __overlay__ {
            clock-frequency = <400000>;
//            clock-frequency = <100000>;
            status = "okay";
        };
    };
    fragment@3 {
        target = <&i2c2>;
        __overlay__ {
            status = "okay";
        };
    };
};

 

 

spidev-enable.dts :

 

 

// Enable the spidev interface
/dts-v1/;
/plugin/;

/ {
    compatible = "allwinner,sun8i-h3";

    fragment@0 {
    target-path = "/aliases";
    __overlay__ {
            /* Path to the SPI controller nodes */
            spi0 = "/soc@01c00000/spi@01c68000";
            spi1 = "/soc@01c00000/spi@01c69000";
        };
    };
    fragment@1 {
        target = <&spi0>;
        __overlay__ {
            pinctrl-names = "default";
            pinctrl-0 = <&spi0_pins_a>, <&spi0_cs0_pins_a>;
            status = "okay";
            #address-cells = <1>;
            #size-cells = <0>;
            spidev@0 {
                compatible = "spidev";
                reg = <0x0>;
                spi-max-frequency = <1000000>;
            };
        };
    };
    fragment@2 {
        target = <&spi1>;

        __overlay__ {
            pinctrl-names = "default";
            pinctrl-0 = <&spi1_pins_a>,
                    <&spi1_cs0_pins_a>;
            status = "okay";
            #address-cells = <1>;
            #size-cells = <0>;

            spidev@1{
                compatible = "spidev";
                reg = <0>;
                spi-max-frequency = <1000000>;
            };
        };
    };
};

 

tao

tao

Posted
Posted

This is a little off topic, but issue 169 of Linux User and Developer has a one page article on the NanoPi NEO.  Although I was glad to see the article since I like the NEO, I was disappointed they didn't mention Armbian.  I'm glad FriendlyARM provides a distro for their hardware, but after checking out Armbian, there's no going back (for me).  I feel Armbian already offers much more then FA's distro, and once users realize the active development and positive atmosphere in this forum the adoption of Armbian for the NEO should be easy.

HarfTarf

HarfTarf

Posted
Posted

This is a little off topic, but issue 169 of Linux User and Developer has a one page article on the NanoPi NEO.  Although I was glad to see the article since I like the NEO, I was disappointed they didn't mention Armbian.  I'm glad FriendlyARM provides a distro for their hardware, but after checking out Armbian, there's no going back (for me).  I feel Armbian already offers much more then FA's distro, and once users realize the active development and positive atmosphere in this forum the adoption of Armbian for the NEO should be easy.

 

 

 

Is this the article youre talking about?

tao

tao

Posted
Posted

Yes .. that's the article I read.  Thanks for sharing an electronic version.  I don't think it has anything this forum doesn't already know, but for me it was fun to see since I really like the neo.

Ratin

Ratin

Posted
Posted
Hi Dear Tkaiser!
Thank you for your great work in Modifying Linux to prepare a better OS for our IOT projects. :)
 
But, there is some problem with beta images that released in Armbian Site that i couldnt solve them till now :
 

OS Checked :

Armbian_5.17_Nanopineo_Debian_jessie_4.6.7

Armbian_5.17_Nanopineo_Debian_jessie_4.7.2

Armbian_5.17_Nanopineo_Debian_jessie_3.4.112

Armbian_5.17_Nanopineo_Ubuntu_xenial_3.4.112

 

1. Connecting WiFi Dongle (MAIN PROBLEM) : Mine is EDUP 802.11N Dongle that works properly in Raspberry pi B+,

But in Any Armbian OS in Nanopi NEo , I cant use it. Error is :

[   52.823742] rtl8192cu: Chip version 0x10
[   52.921565] rtl8192cu: MAC address: e8:4e:06:32:29:2d
[   52.927211] rtl8192cu: Board Type 0
[   52.931436] rtlwifi: rx_max_size 15360, rx_urb_num 8, in_ep 1
[   52.937967] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw.bin
[   52.945062] usbcore: registered new interface driver rtl8192cu
[   52.951813] rtlwifi: Firmware rtlwifi/rtl8192cufw.bin not available
[   53.010557] Error: Driver 'rtl8192cu' is already registered, aborting... 

Dongle's LED not even turn  on, let alone blink!

 

2. USB OTG Doesn't work in Armbian_5.17_Nanopineo_Debian_jessie _4.7.2  . may be additional setting needed in may Windows laptop for that? i dont know !

 

3. Alsamixer, Amixer, aplay,.... not installed or enabled by default in last beta version of Vanilla version. For must use of IOT , it is better tat be Enabled .

 

 

Would you please give me some help for fix this problems? :P  

HarfTarf

HarfTarf

Posted
Posted

I don't have your same WiFi dongle, but try this file: http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/plain/rtlwifi/rtl8192cufw.bin

 

 

 

 

 

Hi Dear Tkaiser!

Thank you for your great work in Modifying Linux to prepare a better OS for our IOT projects. :)

 

But, there is some problem with beta images that released in Armbian Site that i couldnt solve them till now :

 

OS Checked :

Armbian_5.17_Nanopineo_Debian_jessie_4.6.7

Armbian_5.17_Nanopineo_Debian_jessie_4.7.2

Armbian_5.17_Nanopineo_Debian_jessie_3.4.112

Armbian_5.17_Nanopineo_Ubuntu_xenial_3.4.112

 

1. Connecting WiFi Dongle (MAIN PROBLEM) : Mine is EDUP 802.11N Dongle that works properly in Raspberry pi B+,

But in Any Armbian OS in Nanopi NEo , I cant use it. Error is :

[   52.823742] rtl8192cu: Chip version 0x10
[   52.921565] rtl8192cu: MAC address: e8:4e:06:32:29:2d
[   52.927211] rtl8192cu: Board Type 0
[   52.931436] rtlwifi: rx_max_size 15360, rx_urb_num 8, in_ep 1
[   52.937967] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw.bin
[   52.945062] usbcore: registered new interface driver rtl8192cu
[   52.951813] rtlwifi: Firmware rtlwifi/rtl8192cufw.bin not available
[   53.010557] Error: Driver 'rtl8192cu' is already registered, aborting...
Dongle's LED not even turn on, let alone blink!

 

2. USB OTG Doesn't work in Armbian_5.17_Nanopineo_Debian_jessie _4.7.2 . may be additional setting needed in may Windows laptop for that? i dont know !

 

3. Alsamixer, Amixer, aplay,.... not installed or enabled by default in last beta version of Vanilla version. For must use of IOT , it is better tat be Enabled .

 

 

Would you please give me some help for fix this problems? :P

sagt3k

sagt3k

Posted
Posted

Hi I'm newbie

 

Congratulations for ARMBIAN. Then ... I have a NanoPI NEO 512mb, and I have installed on uSD a image of "Armbian_5.17_Nanopineo_Debian_jessie_4.6.7"

 

OK, after the boot I insert a wifi-dongle RTL8192cu, but i don't see nothing ..

root@nanopineo:~# lsusb
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

What I'm wrong?

Thanks

sagt3k

tkaiser

tkaiser

Posted
Posted

Thx for reporting this. The reason is maybe both stupid and simple: We use with the mainline kernel images the device tree configuration for Orange Pi One on all those boards that have the same primitive voltage regulator (since boards are rather similar otherwise and this differrentiation is necessary to get throttling / dvfs / cpufreq scaling working).

 

In OPi One's mainline device tree config only usb0 (OTG) and usb1 are defined while the one physically exposed USB port on NanoPi NEO is usb3 for whatever reasons. So the best you could do is to google 'device tree for dummies' and use the dtc tool we provide to convert from .dtb to .dts, adjust USB port definitions and convert back to .dtb.

 

I can't promise to fix that anytime soon with mainline kernel images since 

  • dealing with these device tree patches is a time-consuming mess
  • these images are still test images and not meant for daily/productive usage
  • we provided them to get feedback to get an idea what's necessary to support the whole fleet of H3 devices fully with mainline kernel (so thanks for reporting but I can't provide a quick fix and just the DIY hint)
sagt3k

sagt3k

Posted
Posted

Thanks for your fast reply.
I can wait for the neo NanoPI. However I am using the most stable versions also on a OrangePI one. I need a stable version on NanoPI neo.
I take this opportunity to also make a note of this problem:

root@nanopineo:/sys/class/leds# ls
orangepi:green:pwr  orangepi:red:status

On NanoPi NEO on /sys/class/leds there is' something of orange and NanoPI Neo has green and blue leds. Don't worry great job !!

Thanks

tkaiser

tkaiser

Posted
Posted

On NanoPi NEO on /sys/class/leds there is' something of orange and NanoPI Neo has green and blue leds.

 

The only real difference regarding leds between Nanos and Oranges is that the red led on the latter is blue on the former but still same pin used. And since we currently use Orange Pi One device tree definitions for both Oranges and Nanos their blue led became red in sysfs ;)

 

BTW: People wanting to switch between legacy and vanilla kernel should start to access the led sysfs entries using wildcards. Accessing /sys/class/leds/*green*/trigger will work with both kernels on all sunxi boards (and this is how Armbian deals with this). If you start to use full sysfs paths you would have to differentiate between +50 different paths depending on board and kernel version (well, if you think about it's really weird that we support now +40 SBC, all of them with 4 distros each and most of them with 2 kernel versions)

tsgan

tsgan

Posted
Posted

It seems when using Armbian_5.17_Nanopineo_Ubuntu_xenial_4.6.7 image all USB ports are not working on NanoPI NEO.

Tried to attach usb stick to USB port (built in), as well as using USB pins, it doesn't detect it.

Carlos

Carlos

Posted
Posted

Hi

I need some help please. I surprised myself by getting my Neo up and running using the original Armbian image that was on this site for the Neo. I was also able to download and run HQPlayer NAA on my neo. (Not bad for never having anything to do with unix before.)

When the new Vanilla image became available I flashed that to my micro sd and restarted the Neo. No flashing blue light as per original install. No IP Address showing on my router. My guess is that whatever tells the Neo to boot from SD is corrupted?

Any suggestions greatly appreciated.

tkaiser

tkaiser

Posted
Posted

It seems when using Armbian_5.17_Nanopineo_Ubuntu_xenial_4.6.7 image all USB ports are not working on NanoPI NEO.

 

One USB port is working but that is on the unpopulated GPIO header -- reason / possible fix above in #167.

 

When the new Vanilla image became available I flashed that to my micro sd and restarted the Neo. No flashing blue light as per original install. No IP Address showing on my router. My guess is that whatever tells the Neo to boot from SD is corrupted?

 

Maybe. It's never the question if hardware will die, only when. When I started with the NEO I had to realize that the board very often stopped at the u-boot prompt. It seems that noisy DC-IN leads to noise on the serial RX line which will be interpreted by u-boot as keystrokes and prevents autoboot. Therefore using a serial console is highly recommended (and funnily the moment you connect a serial adapter this 'u-boot got stuck on command line' will also not happen anymore)

bzfrp

bzfrp

Posted
Posted

Hello,
Thanks for your excellent distribution!
I have NanoPi NEO + heatsink + box (all official from friendlyarm). I installed Jessie legacy because I need the USB audio output. I installed the mpd package +  upmpdcli ( http://www.lesbonscomptes.com/upmpdcli/) + shairport -sync. This SBC is perfect for creating a UPnP audio player and airplay audio player. Here the load during playback of FLAC files

 

 

root@nanopineo:~/shairport-sync# armbianmonitor -m
Stop monitoring using [ctrl]-[c]
Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU
15:32:27:  912MHz  0.01   2%   0%   1%   0%   0%   0%   49°C
15:32:32:  240MHz  0.00   2%   0%   1%   0%   0%   0%   49°C
15:32:38:  240MHz  0.00   2%   0%   1%   0%   0%   0%   49°C
15:32:43:  240MHz  0.00   2%   0%   1%   0%   0%   0%   49°C
15:32:48:  240MHz  0.00   2%   0%   1%   0%   0%   0%   49°C
15:32:53:  240MHz  0.00   2%   0%   1%   0%   0%   0%   50°C
15:32:59:  240MHz  0.00   2%   0%   1%   0%   0%   0%   49°C
15:33:04:  240MHz  0.08   2%   0%   1%   0%   0%   0%   49°C
15:33:09:  240MHz  0.08   2%   0%   1%   0%   0%   0%   49°C
15:33:14:  240MHz  0.07   2%   0%   1%   0%   0%   0%   49°C
15:33:20:  240MHz  0.06   2%   0%   1%   0%   0%   0%   49°C
15:33:25:  240MHz  0.06   2%   0%   1%   0%   0%   0%   49°C
15:33:30:  240MHz  0.05   2%   0%   1%   0%   0%   0%   49°C
15:33:36:  240MHz  0.05   2%   0%   1%   0%   0%   0%   49°C
15:33:41:  240MHz  0.05   2%   0%   1%   0%   0%   0%   49°C
15:33:46:  912MHz  0.04   2%   0%   1%   0%   0%   0%   49°C
15:33:51:  240MHz  0.04   2%   0%   1%   0%   0%   0%   49°C
15:33:56:  240MHz  0.04   2%   0%   1%   0%   0%   0%   49°C
15:34:02:  240MHz  0.03   2%   0%   1%   0%   0%   0%   49°C
15:34:07:  240MHz  0.10   2%   0%   1%   0%   0%   0%   50°C
15:34:12:  240MHz  0.09   2%   0%   1%   0%   0%   0%   49°C
15:34:18:  240MHz  0.09   2%   0%   1%   0%   0%   0%   49°C
15:34:23:  240MHz  0.08   2%   0%   1%   0%   0%   0%   49°C
15:34:28:  240MHz  0.07   2%   0%   1%   0%   0%   0%   49°C
15:34:33:  240MHz  0.07   2%   0%   1%   0%   0%   0%   49°C
15:34:39:  240MHz  0.06   2%   0%   1%   0%   0%   0%   49°C
15:34:44:  240MHz  0.06   2%   0%   1%   0%   0%   0%   49°C
15:34:49:  240MHz  0.05   2%   0%   1%   0%   0%   0%   49°C
15:34:54:  912MHz  0.05   2%   0%   1%   0%   0%   0%   49°C
15:35:00:  240MHz  0.04   2%   0%   1%   0%   0%   0%   49°C
15:35:05:  240MHz  0.04   2%   0%   1%   0%   0%   0%   50°C
15:35:10:  240MHz  0.04   2%   0%   1%   0%   0%   0%   49°C
15:35:15:  240MHz  0.03   2%   0%   1%   0%   0%   0%   49°C
15:35:21:  240MHz  0.03   2%   0%   1%   0%   0%   0%   49°C
15:35:26:  240MHz  0.03   2%   0%   1%   0%   0%   0%   49°C
15:35:31:  240MHz  0.03   2%   0%   1%   0%   0%   0%   50°C
15:35:37:  240MHz  0.02   2%   0%   1%   0%   0%   0%   49°C
15:35:42:  240MHz  0.02   2%   0%   1%   0%   0%   0%   49°C
15:35:47:  912MHz  0.09   2%   0%   1%   0%   0%   0%   49°C
15:35:52:  240MHz  0.09   2%   0%   1%   0%   0%   0%   49°C
15:35:58:  240MHz  0.08   2%   0%   1%   0%   0%   0%   49°C
15:36:03:  240MHz  0.07   2%   0%   1%   0%   0%   0%   49°C
15:36:08:  240MHz  0.23   2%   0%   1%   0%   0%   0%   49°C
15:36:13:  240MHz  0.21   2%   0%   1%   0%   0%   0%   49°C
...

 

 

tkaiser

tkaiser

Posted
Posted

Build a supercomputer with Nano PI Neos!´

 

Well, unless U7 problem is resolved (I still hope for next PCB revision) I would at least not try to do HPC stuff on a NEO cluster. The NEO has the slowest DRAM implementation of all H3 boards now and at least I was able to deadlock the board reliably at 1.2 GHz with FA's heatsink (I don't know whether they test their boards with the same heavy stuff like us).

 

I also thought about cluster use cases but after torturing those little beasts with our usual workloads am not that convinced any more. Nice and tiny IoT nodes though :)

mmarks

mmarks

Posted
Posted

A quick update on my software and hardware experiments. I received three Neo  boards from FA yesterday. I ordered the FA heatsinks to go with them, but I thought I would try just using a RPI heatsink on the H3 to see if it was enough. The boards came without any USB and RJ45 hardware. Just the bare board, so I've ordered some MagJacks from Sparkfun. I'll hardwire the USB for now. I don't see an option on the FA website to buy the hardware so be warned you may get bare boards.

 

I loaded Armbian 5.17 Jessie 4.6.7 on a 16GB uSD card and set up a serial debug port on the 5 pin header. Armbian booted and ran perfectly. Powered from the usb OTG port it draws about 250-400 mA depending on load. With just a small square RPI heatsink on the CPU it idles at 240 MHz at ~28C. Not much over ambient here in Texas. Loaded up it gets up to high 30s but I haven't run a real stress test yet. I'm not planning on running it too hard for my application. I'll switch to the bigger FA heatsink if I need to. The thermal pad looks too thick to be really effective but you never know.

 

I tried using a powered OTG splitter dongle to see if I could use a USB Ethernet dongle on the OTG port but although the Ethernet dongle got power and the board powered up my ethernet device did not show up in lsusb. Not sure what the problem is there.

 

Like others I need SPI, I2C and GPIO for my applications so I'll try playing with the device overlays once I get this board safely on the network.

 

Once again THANKS for the great work on Armbian. I appreciate the hard work.

sagt3k

sagt3k

Posted
Posted

Hi to everybody

I'm using jessie legacy 3.4.x on NanoPi NEO. I need help... I need to set max 2 cores at startup and max 600MHz.

How to do?

Thanks

Sagt3k

sagt3k

sagt3k

Posted
Posted

Hi gnash

 

I read that in the first 1 or 2 minutes after the boot is very difficult to set the number of processors and frequency. Then in /etc/rc.local call a script and let the sleep for 2min after start the commands. It seems to work. Thanks

If someone has a more elegant way to solve the problem is .... welcome !!

#!/bin/bash
sleep 120
echo 0 > /sys/devices/system/cpu/cpu3/online  #disable CPU3
echo 0 > /sys/devices/system/cpu/cpu2/online  #disable CPU2
echo 480000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq  #set max frequency at 480MHz
exit 0

Now after the reboot I have 65°c. My CPU has a heat sink compatible raspberry.

In attached file You can see, immediately after booting I stress CPU with "stress -c 4". After 2 minutes start the script that set max 2CPU e max 480Mhz.

post-2095-0-37364700-1472982411_thumb.jpg

tkaiser

tkaiser

Posted
Posted

Well, of course you can do it as complicated as you want but the whole thing is pretty easy using our new h3consumption tool: http://forum.armbian.com/index.php/topic/1878-testers-wanted-h3consumption-to-be-included-into-future-armbian-releases/

 

I read that in the first 1 or 2 minutes after the boot is very difficult to set the number of processors and frequency.

 

 

That's simply because Armbian ships with cpufrequtils. So stuff in /etc/rc.local will be called and does $something, then a few seconds later cpufrequtils gets started and does something else. Easy solution: Use h3consumption since this knows where to adjust what.

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

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept