NanoPi M1


Recommended Posts

Armbian is a community driven open source project. Do you like to contribute your code?

Nope, since results are 100% predictable ;)

 

If you look at the hardware (or their fex file -- I did the latter since it's enough and we support this board since 3 weeks) then everything is identical to Orange Pi PC One with four exceptions: you can order 1GB DRAM instead of 512MB for $5 more, blue led instead of red one (but using the same pin mapping), more advanced power scheme (when you power the board through GPIO pins you can charge devices that are connected to the Micro USB OTG port -- but it's on my TODO list to check that with OPi PC also) and no the same primtive programmable voltage regulator switching between 1.1V and 1.3V.

 

So we know everything about thermal behaviour since it's identical to BPi M2+ Orange Pi One, we know what to expect from only 512 MByte RAM already, we most likely don't care that much whether we have a blue or a red led (since 3 weeks Armbian looks for red first and if not available uses the blue one to signal states) and that's it already.

 

If you compare to the manufacturers of other H3 boards there's one HUGE difference: The FriendlyARM people do care a lot about their customers and the software they provide. Have a look in their wiki, they also published a new version of Allwinner's BSP kernel we now use thanks to Igor, they published a new H3 user manual, their OS images doesn't suck unlike Xunlong's and SinoVoip's (I tried it out on Orange Pi One 3 weeks ago -- it's just exchanging the fex file). But that doesn't matter that much since Armbian's ready for NanoPi M1 already.

 

All that's needed is another entry in configuration.sh and these few lines of u-boot patch:

 

 

 

diff --git a/configs/FriendlyARM_NanoPi_M1_defconfig b/configs/FriendlyARM_NanoPi_M1_defconfig
new file mode 100644
index 0000000..2e7c095
--- /dev/null
+++ b/configs/FriendlyARM_NanoPi_M1_defconfig
@@ -0,0 +1,18 @@
+CONFIG_ARM=y
+CONFIG_ARCH_SUNXI=y
+CONFIG_MACH_SUN8I_H3=y
+CONFIG_DRAM_CLK=672
+CONFIG_DRAM_ZQ=3881979
+CONFIG_DRAM_ODT_EN=y
+# CONFIG_VIDEO is not set
+CONFIG_DEFAULT_DEVICE_TREE="sun8i-h3-orangepi-pc"
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_SPL=y
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_FLASH is not set
+# CONFIG_CMD_FPGA is not set
+CONFIG_CMD_GPIO=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_DM=y
+CONFIG_DM_GPIO=y
+CONFIG_SYS_CLK_FREQ=816000000 

 

 

 

I leave it up to Igor to decide whether he want the board to be included in next release or not (adding H3 boards is a matter of an hour, supporting them might ruin your nerves). Therefore the easy answer is: If you don't want to use Armbian then this FriendlyARM board is definitively worth a look since software/support look great. But regarding hardware we already know everything and so you can simply decide which of the many H3 based devices suits your needs (be careful: FriendlyARM's shipping costs for single units are rather high, I calculated a few weeks ago that it gets interesting when you need +25 or something like this)

Link to post
Share on other sites

TKaiser, thanks for the update.

 

Today i ordered M1 and M2 with 5MP camera and will give it a try when i get them. Can you suggest a PSU for the M1? (Rpi 3 psu can be used?).

I will try to do a tiny comparison about the cameras on  OPI 2MP, M1 5MP, Guitar 5MP and pine64+ 5MP when i get one (if i ever get it).

 

Just for the curious, there is a guy who is working on a project like this: http://www.pi3dscan.com/ , at first he was disappointed by the 2MP camera quality, he then used the latest GC2035 and got better results, and better than he expected. He told me he would update the results. I think he is using Armbian for the project. Let's hope he finish it and share the results.

Link to post
Share on other sites

Rpi 3 psu can be used?

 

Sure, should be one of the best variants (at least RPi foundation started with this mess to use the crappy Micro USB connector for powering SBCs). But you could also use DuPont jumper wires to provide power to the GPIO header pins.

 

Please get back to me when your M1 arrives. I need your help to quickly verify whether they really use a programmable voltage generator (it's just an 'sudo armbianmonitor -r' to install RPi-Monitor followed by two simple 'stress' runs at different clock speeds :)

 

I'm also curious how fast they are fixing this security issue we've been made aware of and fixed yesterday: https://github.com/friendlyarm/h3_lichee/issues/1

 

And please keep me updated with camera progress! BTW: I think we missed adding latest camera fixes for H3 boards in Armbian 5.10 :(

Link to post
Share on other sites

Please get back to me when your M1 arrives. I need your help to quickly verify whether they really use a programmable voltage generator (it's just an 'sudo armbianmonitor -r' to install RPi-Monitor followed by two simple 'stress' runs at different clock speeds :)

Looking at schematic CPU voltage is controlled by simple GPIO controlled regulator similar to OPi One. Or do you want to confirm software/kernel settings?

Link to post
Share on other sites

Or do you want to confirm software/kernel settings?

 

The latter. After proposing to adopt FriendlyARM's changes to OPi One/Lite also (not just 2 but 4 dvfs operating points and min cpufreq below lowest dvfs operating point) I remembered that I ran into issues when I played with OPi One back then.

 

The FriendlyARM changes should help with performance by modifying throttling behaviour but I want to confirm if we run into issues. IIRC the dvfs code sometimes switched to the higher voltage when the actual CPU clockspeed was below the lowest defined dvfs operating point (480 MHz vs. 648 MHz). But in case your Orange Pi One arrives in time on wednesday you could also have a look.

 

Currently the stuff FriendlyARM provides seems pretty accurate so I would trust in the schematic. It's more about walking through the following dvfs operating points while running 'stress -c 2 -m 2' and monitoring temperatures (and even better measure voltage): 1200 1008 816 648 480.

Link to post
Share on other sites

Small update: The really friendly FriendlyARM people were the first to react on the Allwinner sun8i legacy kernel security alert we informed all affected vendors about. In the meantime they also tested our Armbian image and confirmed that it works.

 

Unfortunately due to our still broken H3 board auto detection NanoPi M1 will currently be treated as either Orange Pi One or PC (depending on DRAM size). Major drawbacks until we fix auto detection (hopefully with next release):

  • change /etc/hostname so that it reads nanopim1
  • fix dvfs settings manually in /boot/bin/nanopim1.bin as outlined here (I made a mistake when trying to improve dvfs settings prior to 5.10 release)
  • then do as root a 'ln -sf /boot/bin/nanopim1.bin /boot/script.bin' -- this will lead to lower temperatures since appropriate voltage switching based on CPU clockspeed will be back again

At least dvfs (settings dynamic voltage frequency scaling) will be fixed with next release and I hope also the board auto detection issues will be resolved then.

Link to post
Share on other sites

Hi,

 

It took me longer than expected but my Nanopi M1 is ready running armbian.

 

@tkaiser

I made the changes you asked.

 

@all

 

I'm ready to make whatever test you need. My Nanopi only has 512Mo of RAM if that's important to you.

Link to post
Share on other sites

Fine, would be good if you install RPi-Monitor by simply doing an

sudo armbianmonitor -r

(might take up to 5 minutes), then please verify if it's running (the URL will be outputted by armbianmonitor) and then run the following and get back to here with the RPi-Monitor graph disabling the load numbers and count of CPU cores:

stress -m 2 -c 2 &
for i in 1200 1008 816 648 480; do
    echo ${i}000 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
    sleep 300
done
pkill stress
echo 1200000 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

Thx!

Link to post
Share on other sites

Never used stress before but I think it's not working well.

 

I'll try to explain, I've opened two ssh connections to the nanopi. On one I start stress in foreground, As soon as I type anything (ls for example) on the other ssh window I got this :

root@nanopim1:~# stress -m 2 -c 2
stress: info: [4373] dispatching hogs: 2 cpu, 0 io, 2 vm, 0 hdd
stress: FAIL: [4373] (416) <-- worker 4377 got signal 9
stress: WARN: [4373] (418) now reaping child worker processes
stress: FAIL: [4373] (452) failed run completed in 25s

dmesg output show this :

[  946.072340] Out of memory: Kill process 5359 (stress) score 348 or sacrifice child
[  946.072352] Killed process 5359 (stress) total-vm:263848kB, anon-rss:192556kB, file-rss:8kB
[  946.102159] stress: page allocation failure: order:0, mode:0x220da

I have no heatsink on my H3 CPU but it doesn't seem linked to temperature.

Link to post
Share on other sites

I have no heatsink on my H3 CPU but it doesn't seem linked to temperature.

 

Nope, it's an 'out of memory' situation. Please replace the stress call with

sysbench --test=cpu --cpu-max-prime=2000000 run --num-threads=4

instead and use 'pkill sysbench' to kill the task afterwards. IIRC that should word.

Link to post
Share on other sites

Sorry for the delay, the weather was so good that playing with the nano pi was lower in my priority list ;).

 

Here is the rpi monitor output. As I said this is without any fan or heatsink and the room temperature is 22.1 °C (mesured by a DS18B20). The soc gets very hot !!!!!

 

post-915-0-80047300-1462647636_thumb.png

 

 

Link to post
Share on other sites

Ok, the heat sink is on the way and I'll make sure to add holes to the 3D printed case.

 

The latter is nearly useless (since some holes here and there do not lead to the massive amount of airflow that would be needed to enhance the efficiency of an applied heatsink -- stuff you can simply try out using RPi-Monitor) and you only need a heatsink if you care about 'top performance' since throttling does the job to protect the SoC.

 

Most recent ARM SoCs are specified to work in temperature ranges where you would burn your fingers when touching them. But that's nothing to worry about as long as you're using a kernel that implements throttling (applies to sun8i legacy kernel but not mainline now -- patches already exist but none of us managed to apply them together with the other needed H3 patches so far)

Link to post
Share on other sites

sorry for the offtopic

 

I don't really care about high performance, I just need a computer that's small enough to be hidden (to please my wife) and that does no use much current as it's has to be up day and night. My current setup with a banana pi has a normal load15 of 0.1 (and is at 600MHz 99% of the time). When it was hosting some websites, the load15 never exceeded 0.5. I simply don't want it to burn / crash / or reboot as as soon as I create a big bzip2 using pbzip2 (parallel) or I make a mistake in a program and use 100% of one core.

 

So I also put a heat sink on my banana pi just to be on the safe side (it's also on the side to ease convection). If I follow you (and the RPI monitor graph) it's not needed at all for the H3, interesting to know !

 

Thanks

Link to post
Share on other sites

I simply don't want it to burn / crash / or reboot as as soon as I create a big bzip2 using pbzip2 (parallel) or I make a mistake in a program and use 100% of one core.

 

Then provide a stable power source and don't think about temperatures (throttling will jump in if load peaks make it necessary). Apart from that it might help with longevity if temperatures are lower (disclaimer: I'm no hardware guy) and in case you have an instable power source improving heat dissipation is always counterproductive since then throttling isn't that aggressive and since voltage drops occur under high loads chances increase that CPU gets clocked higher, is driven with a higher VDD_CPUX core voltage and then the critical supplied DC-IN voltage falls below a certain treshold.

 

This is what seems to be hard to understand. The relationship between higher VDD_CPUX voltage (the SoC is fed with through a programmable voltage generator switching from eg. 1.1V to 1.3V which increases consumption) and dropping DC-IN voltage (eg. from 4.6V down to 4.3V which might already insufficient). The only relationship with temperatures is the aforementioned one: Improve heat dissipation only if you can provide a stable power source with stabilised 5V.

 

On Banana Pi (A20/AXP209) it's easy to measure since drivers are available for the PMU: http://forum.lemaker.org/forum.php?mod=viewthread&tid=8312&extra=page%3D1  and the difference between a crappy USB cable with AWG 26 or 28 rating and good short one with only AWG 20 can be seen here: http://goughlui.com/2014/10/01/usb-cable-resistance-why-your-phonetablet-might-be-charging-slow/

 

H3 has no PMU so you would need a multimeter to measure. And unfortunately the FriendlyARM folks chose the crappy Micro USB connector to power the board. In case you run into stability issues think about providing power through the GPIO header (pin 4: 5V, pin 6: GND)

Link to post
Share on other sites

About the A20, I knew about the drivers and I checked everything when I put the server into "production" : 5,16V / 270mA idle and 5.01V / 570 ~ 700mA under heavy CPU / MEM / SSD / network load.

 

I has never failed me since (2 reboots and always my fault).

 

I always use good quality 2A certified USB power supply and use an old ATX power supply for testing purpose, I have way more power that any of the SBC I have tested can use.

Link to post
Share on other sites

TKaiser,

 

Sorry if it is a little off topic but you ask me to update about the camera progress. I have not received the M1 yet, i asked for 1GB so it may take a bit longer for them to ship the board. Anyway i have been experimenting with guitar and the 5MP camera so we have a parameter and we can expect something similar on the M1 with 5MP.

I just grabbed some images to get the framerate, here are some values:

640x480 => 31 fps
1280x720 =>  17 fps
1920x1080 => 10 fps
1600x1200 => 3 fps
2595x1944 => 5 fps - working!!!

I can't say much about the quality of the images yet but 1600x1200 has the sharpness image among all and little noise, 3 fps is a problem for video. All this test was made with a dark room, so we could expect different results with good light condition. The camera is AF but does not work the way it works on Android.

 

* Update: About the AF, it is working with 640x480 (not above) and not as 'aggressive' as in Android . https://drive.google.com/open?id=0B7A7OPBC-aN7NlN2SnhFQmgtVkE

 

Let's see how the Nano Pi driver will perform.

 

PS:

I have guitar with 3D GPU and HW accel. working but could not make VPU works as i wanted/needed and PowerVR blitting seems behind Mali 400 MP2 while 3D not.

 

@lex

Link to post
Share on other sites

As a side note, I changed the hostname / fex (as explained by tkaiser) and tried to upgrade my 5.10 install. I got this error

Setting up libdpkg-perl (1.17.27) ...
Setting up dpkg-dev (1.17.27) ...
Setting up initramfs-tools (0.120+deb8u2) ...
update-initramfs: deferring update (trigger activated)
Setting up linux-firmware-image-sun8i (5.13) ...
Setting up linux-headers-sun8i (5.13) ...
Compiling headers - please wait ...
Setting up linux-image-sun8i (5.13) ...
update-initramfs: Generating /boot/initrd.img-3.4.112-sun8i
Setting up linux-jessie-root-nanopim1 (5.11) ...
Setting up linux-u-boot-nanopim1-default (5.11) ...
Setting up openssl (1.0.1t-1+deb8u2) ...
Processing triggers for libc-bin (2.19-18+deb8u4) ...
Processing triggers for systemd (215-17+deb8u4) ...
Processing triggers for initramfs-tools (0.120+deb8u2) ...
/boot/initrd.img-3.4.112-sun8i does not exist. Cannot update.
root@nanopim1:~# ls /boot/
bin/                      boot.scr                  uInitrd
bin.old/                  config-3.4.112-sun8i      .verbose
boot.bmp                  script.bin                vmlinuz-3.4.112-sun8i
boot.cmd                  System.map-3.4.112-sun8i  zImage



Link to post
Share on other sites

I got some new NanpPC-T3 and NanoPi M1 and M3.

 

Just after ordering I see on the FA web site that they have a new heat-sink with a little fan. hey are only shown in the photos for the M3 printed ousing. They look good and I'll get some to test. I can give a couple away if anyone wants to do exhaustive testing and see what we really have here.

 

http://www.friendlyarm.com/index.php?route=product/product&product_id=131

Link to post
Share on other sites

Just a short question. I'm new to the nanopi-M1:

 

 

What's the difference running friendlyarm's default debian or armbian? Can I use their X710 display when running armbian (out of the box)?

 

any info appreciated

 

thx

 

Link to post
Share on other sites

What's the difference running friendlyarm's default debian or armbian? Can I use their X710 display when running armbian (out of the box)?

 

To your 2nd question first: You should keep in mind that H3 used on NanoPi M1 is not a tablet but an OTT box SoC (therefore no interfaces for 'raw' access to LCD displays, only HDMI 1.4 and CVBS available). So without a HDMI converter board you can not use any LCD display. Be careful when choosing any 1024x600 pixel DVI/HDMI connected LCD display: No driver (resolution) support currently so H3 is only able to be used with displays implementing the standard 16:9 aspect ratios (480p, 720p, 1080p).

 

Regarding FA's OS images vs Armbian: I tested two of their images when they were released (on an Orange Pi PC of course since M1 was not available back then) and to be honest: the quality of their OS images might be the best of all $fruit Pi vendors. They do many things different than Armbian (we for example resize the rootfs partition on first boot and provide the h3disp utility, what they do is documented in their wiki) and IMO the most important differences are:

  • we use already mainline u-boot (this is one of the two reasons temperature readouts with Armbian are lower compared to H3 OS images that rely on Allwinner's 2011.09 u-boot version)
  • Armbian behaves identical on all +40 SBCs we support (this is only important if you deal with different SBCs and that's the main reason for me to contribute to Armbian: I hate dealing with vendor supplied OS images and all the weird stuff and dumb settings they contain -- FA's being the exception, FA does a really great job with software too)

Why not investing some time and testing out both. We as well as FA would love to get feedback what to improve.

 

BTW: FriendlyARM's tech support contacted me a few days ago and asked how many FA boards we at Armbian would need as developer samples. Igor and me asked for NanoPi NEO and M3 (the latter more out of curiousity whether octa-core boards exist that are not strange). We report back when the boards arrive (Armbian support for NEO already almost done, unfortunately the octa-core M3 seems not that interesting since only an old 32-bit kernel is available for this Cortex-A53 SoC)

 

Until now FA seems to be a pretty supportive vendor caring about correct documentation, good software and support. So choosing any FA board you're in the lucky position to need Armbian not that much ;)

Link to post
Share on other sites

BTW: Our images for NanoPi M1 contain a mismatch between minimal clockspeeds defined with cpufreq-utils and within fex file which is responsible for logs filled with errors and prevents throttling working correctly. For a workaround and a try to fix please have a look at: http://www.cnx-software.com/2016/02/13/received-your-orange-pi-one-youll-need-to-tweak-your-fex-file-script-bin/#comment-529075

 

(final fix will come next week)

Link to post
Share on other sites
Guest
This topic is now closed to further replies.