tkaiser
-
Posts
5462 -
Joined
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by tkaiser
-
-
I got the impression there will never be SATA for the H3 as it is not natively supported by the SoC as in the A20?
Correct, http://linux-sunxi.org/Sunxi_devices_as_NAS#Requirements_.2F_which_device_to_choose still applies.
If it's about I/O bandwidth the A20 is still the best choice (in Allwinner land, SATA capable SoMs/SBC are also available with Marvell SoCs or i.MX6 -- see link above). If the rumours Olimex spread half a year ago are true we can expect a pin-compatible A20 successor with twice as much CPU cores in the 2nd half of next year.
And again H3: this SoC has 4 independent USB ports not just 2 (1 host and 1 dual role) as the octa-core A83T for example or the '64-bit' A64. So if it's really about I/O bandwidth the H3 outperforms these other 'more powerful' easily. Especially if they are combined with ultra-slow USB-to-SATA bridges like the on the Banana Pi M3 (GL830 -- to be avoided!).
-
Another USB addendum regarding H3 with mainline kernel. I attached a 3rd disk (behind a 'Sunplus Technology Co., Ltd SPIF215A SATA bridge').
The SSD utilising UASP is able to achieve 40 MB/s, the Barracuda behind the ASM1051 gets close to 29 MB/s (without blacklisting close to 38 MB/s -- measured with A20 some time ago) and the other disk behind the Sunplus bridge ~32 MB/s.
Testing all 3 in parallel: The SSD (UASP) already finished with a slight slow-down to 37.5 MB/s, the other two disks being way slower (15/17 MB/s). Especially when accessing disks in parallel UASP wins clearly.
Really looking forward to a H3 SBC with GBit Ethernet, no internal USB hub and especially no crappy USB-to-SATA bridge. Might also be used as a NAS then.
-
@tkaiser, do you mean you took Igor's image and replace the .dtb, reboot and perform USB benchmark tests using Serial?
Yes, there's not that much magic involved
Thanks to the hard working linux-sunxi devs and Igor (and all the contributors to Armbian in the meantime) it's 'enough' to rely on mainline u-boot/kernel and you get the stuff working that's currently possible. And you've the convenience being able to use the Armbian 'environment' since everything's already there where you expect it.
Exchanging the .dtb file simply made USB working (different devices, different definitions -- the OPi PC has the advantage that no USB hub is used to route all 4 available USB ports to the outside, on the OPi plus a hub is used due to the crappy USB-to-SATA-bridge there)
BTW: Just tested another disk using an enclosure with ASMedia ASM1051 (UASP blacklisted). Only 28 MB/s -- unfortunately I don't have the time to patch kernel sources again to deactivate blacklisting since this might make the difference.
Really looking forward using the H3 with mainline kernel. So much weird stuff to leave behind (starting with the moronic overvolting, crappy script.bin adjustments and so on)
-
I think we got UART and USB
Yeah! And since you included iozone to the list of default packages I'm proud to present the fastest USB 2.0 device in the world: The Orange Pi PC: 39 MB/s write and 41.5 MB/s read (average value of 4K/1M record size). I've never seen better results. Mainline kernel and UASP did the job.
All I did was overwriting the contents of the 'Plus' .dtb with the one from OPi PC followed by a reboot.
-
Since f2fs is not resizable after the first boot it's not an option to use it as default fs for Armbian.
BTW: The enclosures you ordered are crap or at least prone to overheating. On Banana Pi/Pro everything that gets hot is on the lower side of the PCB. The vents are pretty useless. Might look nice but doesn't help at all.
-
If you don't want to tweak the "dvfs" table yourself, you can also run a simple script at boot up which reduce the CPU frequency.
Nope, that's not enough since this doesn't solve the overvoltage problem! When you adjust the cpufreq to 1.2 GHz and do not alter the dvfs table then the H3 will be driven with 1.3V all the time (way too high), even if your cpufreq scaling settings clock it down to 60 MHz when idle. It still wastes huge amounts of energy, produces more heat than necessary and shortens its lifespan.
With sane dvfs settings Vcore will be reduced from 1.3V down to 1.04V when idling. This is a huge difference regarding temperature! Refraining from repairing Xunlong's broken dvfs table means frying your H3 at 1.3V minimum constantly.
The key factor is adjusting the dvfs table and that's simply done by converting script.bin to a fex file, exchange a few lines and convert back. I prepared a script that can be used on Debian based distros to do exactly that. Repairing the broken settings in script.bin and replacing it with the official linux-sunxi ones: http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=785
By reading the script you get the idea what's to be done if you want to repair dvfs settings manually.
-
MicroUSB is easy to get but the H3 needs a 5V2A (maybe i have one of these lying around, very tiny DC connector side) but wasn't that overkill if you didn't need to overvolt it to run their falsely advertised clock speed? Or maybe I am mistaking this and the MicroUSB cables I've been using could potentially undervolt it.
It's possible to both overvolt the CPU and undervolt the board
These are two different things. You define in the so called dvfs table a few operating points with a relationship between CPU clockspeed and voltage provided to the CPU cores. The basic principle is that you define the Vcore voltage as low as possible since this helps with consumption, temperatures and longevity. But the problem is that if you need higher clockspeeds you also have to increase the Vcore voltage to still let the chip run reliably.
There exist some recommended values from Allwinner for every SoC ("Vcore not lower than 1.04V and not higher than 1.2V for example") and responsible vendors follow these advices. Most H3 devices (OTT boxes) come with a dvfs table only containing 2 operating points:
- 1200 MHz @ 1.3V
- 1008 MHz @ 1.2V
This is OK and leads to a Vcore voltage of 1.3V when clocked at 1008 MHz or above and 1.2V when running slower (most devices are configured to clock lower when idle and to increase clockspeeds only under full load -- and only then Vcore increases also). Xunlong then simply stayed with 2 operating points and increased both cpufreq and Vcore voltage (necessary to reach the 1.53 GHz they advertise as "1.6 GHz"):
- 1536 MHz @ 1.5V
- 1200 MHz @ 1.3V
That means the H3 is always volted with the maximum all other devices use (1.3V) and if clockspeeds exceed 1200 MHz even with 1.5V (0.1V above the recommended upper limit). And this overvolting is the root cause for all the thermal problems Orange Pi users experienced in the past. I tried to document the overvolting/overclocking history here.
Regarding DC-IN it's something different. There you should supply 5V but since many USB cables are simply crap and micro USB has very tiny contacts you might run in undervoltage situations easily (DC-IN dropping below 4.6V or even lower). SoCs that are accompanied by a PMIC/PMU will be powered-off in such a situation by the PMU to prevent damage. The Orange Pi PC has no PMU but a few voltage regulators that might work even with 4.5V. But for connected USB peripherals or HDMI this is already way too low. Therefor the barrel plug the Orange Pi's are equipped with is an advantage compared to boards that use [micro] USB since you've to consider that DC-IN also has to provide power to external USB devices and other board components.
And as you can see above it always depends. When you want to use the Orange Pi PC just as a headless server and let it run at 1.2 GHz with a sane dvfs table the whole board's consumption won't exceed 3.5W so 5V/1A would already be enough. In case you attach 4 bus-powered USB drives even 5V/3A won't suffice (you would've to study the schematics or simply try it out to get a clue where the limits are)
-
This "up to 1.6 GHz" marketing chitchat is the source of all the heat problems the H3 is blamed for. But you can simply fix that by using better dvfs entries. In the meantime the linux-sunxi devs developed a dvfs table and thermal values (throttling and in case of emergency shutting CPU cores down) that work even without a heatsink in most situations.
Every Raspberry Pi has just a single USB 2.0 connection to the outside. All USB ports and network have to share this: http://linux-sunxi.org/Sunxi_devices_as_NAS#Network.2Fstorage_not_blocking_each_other
Given that we will see rather sooner than later the H3 being supported by mainline kernel (at least for the headless stuff you're talking about) the OPi PC might be worth a try (4 independent USB ports and also independent 100 Mbits/sec networking). Regarding encryption: Allwinner SoCs do contain a crypto engine called 'Security system' still being work in progress in mainline kernel: http://linux-sunxi.org/Mainlining_Effort#Major_drivers
But even without that the H3 should outperform any RPi 2 in your setup due to better I/O and network bandwidth. The H3's integer performance when clocked at 1.2 GHz is also better than the BCM2836's (even when clocking the latter with 1.0 Ghz which should work flawlessly even without a heatsink).
The RPi 2 is superiour in different areas due to driver support (both GPU and VPU) but as long as it's about integer performance and bandwidth (both I/O and network) the H3 wins.
-
4 small ODROID additions: For headless operation the XU4 can run already with mainline kernel and USB3 performance might even be better but up to now no one tried it out (UASP): http://forum.odroid.com/viewtopic.php?f=97&t=17349
And Hardkernel sells a 'shifter shield' to compensate for 1.8V GPIO levels: http://www.mikronauts.com/hardkernel/hardkernel-odroid-xu4-shifter-shield-review/
The ODROID-C1+ might also be an alternative, no Armbian support now, but Hardkernel maintains a clean 3.10.y LTS kernel tree and the S805 used there is so far the fastest passively cooled quad-core SoC I personally tested (since Actions Semi's S500 isn't able to run at the advertised 1.3 GHz over longer time without a fan)
-
Is there a device on the armbian list that is technically more powerful than the RPi?
Might apply to the quad-core i.MX6 devices, especially the Hummingboard with lots of RAM and mSATA SSD (at a price where I would already consider setting up an ESXi whitebox on x86 to virtualize everything
)The i.MX6 has its own drawbacks too (Ethernet speed limitation ~400 Mbits/sec and SATA 90-100 MB/s -- but if your application is somewhat network or I/O bound then it will outperm any RPi 2 easily).
If you're ready for an adventure I would get a cheap TV box based on Amlogic's S905 and DIY Linux: http://www.cnx-software.com/2015/12/06/how-to-run-headless-linux-on-amlogic-s905-devices-such-as-mini-mx-or-k1-plus/
The S905 is also Cortex-A53 but can be clocked higher than A64 and they ship with more recent u-boot/kernel (but I doubt we will ever see mainline kernel on the S905, something that might happen with the A64 next year)
-
Armbian support for Banana Pi M3? Most likely never since no one loves this SoC except of Nora Lee and Lion Wang. Since I offered to donate the board I've been asked by Hans de Goede to send my M3 to him so they could at least finish the 1st steps of mainline u-boot support (the A83T dev boards from Allwinner seem to be too unrealiable to work with). If I send it, maybe sometimes mainline kernel/u-boot will be ready (but I still doubt that) but no one will finish Armbian support. Since the M3's vendors are liars (Lion Wang claiming the M3 booted kernel 4.1 which is simply impossible given the state of support in u-boot alone) that only want to cash in on the original Banana Pi's popularity with new crappy boards every half year the best signal to send out regarding Banana Pi M3 is: Don't buy it, it will never work as intended due to crappy software/support.
Regarding LattePanda: No way to choose this device due to the crappy micro USB DC-IN connector, see the comments: http://www.cnx-software.com/2015/12/02/lattepanda-is-a-79-arduino-compatible-intel-atom-x5-board-running-windows-10-crowdfunding/#comment-507273
Then regarding those "Trail" x86 SoCs in general: You should read here through the comments: https://olimex.wordpress.com/2015/11/19/is-it-time-for-open-source-hardware-x86-olinuxino/(reading Olimex' blog is always a good idea because they share their knowledge, pick up good ideas from their community and a lot of knowledgeable people contribute in the comments)
-
The ODROID-XU4 is interesting and I would love to get access to any device using Marvell's 33DE3218 (also just slow Cortex-A53 but featuring both SATA and PCIe)
And if anyone would produce a useable board based on the Kirin 950 this would also be nice (that one being really fast due to Cortex-A72). But I fear missing Linux support would be the showstopper anyway...
-
You mentioned a new Orange Pi One coming soon for $10.
This is Steven Zhao, Xunlong founder.
-
tkaiser could you please post your modified compile.sh script for this purpose?
Nope, since all I have is my diff from back then: http://pastebin.com/hidkugaG
Please keep in mind that Igor sets a large commit interval for ext4, that you should think about using different storage than SD card if you want to do serious stuff and that F2FS is still not resizable so a general switch to it seems no good idea since you've to know the size of your installation medium prior to running the build script.
It should be quite easy to adjust Igor's current build scripts based on the infomations from the aforementioned thread (at least that was my hope and why I documented the stuff in detail).
-
Are you really running out of memory? Do you use RPi-Monitor for example to get a clue what happens during your load pikes?
I've seen many bad OS distros that run for example irqbalanced that does nothing else than eating up all your RAM (60 MB per day) until the machine swaps to death. And swapping on RPi is always bad since the SoC has only one single USB 2.0 connection to the outside. I would check that first since I find it a bit hard to believe you really need 2 GB RAM for your workload.
BTW: http://blog.hypriot.com/post/family_arm_hardware_for_docker_more_children/
-
Is it possible to burn the linux image onto emmc? Also, whenever I use the Arch Linux image that was recently released, my M3 keeps locking up and crashing.
Of course it's possible to burn images to eMMC -- see above. Regarding your experiences with any of the OS images they provide: Please open one, two or three new threads in their forum asking for help.
They won't answer as usual since their strategy is pretty clear: Using the 'Banana' brand trying to sell as much incompatible crap as possible. You can help others to avoid your mistake (buying the M3) by creating warning threads in their forum. I already gave up to participate there since their strategy seems to work (selling hardware without software/support and waiting again for the community to fix their mistakes)
And be prepared: They're just liars. Now a person called 'Nora Lee' claims being the Banana Pi PM from Foxconn. That's the very same person that produced this misleading marketing crap for the Banana Pi M2:
There she plays a video file being 26.2 MB in size and 5 minutes long as 'proof' that they've HW acceleration for 1080p video decoding in Linux. (details in this post). You can't believe a single word they tell. They're only interested in getting their hardware sold and don't care about anything else.
-
Another look at another SBC: The Orange Pi PC from Shenzen based Xunlong.
The company claims to have done the original ODM work for Banana Pi as Foxconn contractor and started with 2 'Orange Pi' models based on the same A20 SoC shortly thereafter: 'Orange Pi' and 'Orange Pi Mini' -- both supported by Armbian from the beginning.Then they released the 'Orange Pi Plus' based on a newer Allwinner SoC: the H3 (quad-core Cortex-A7 running at 1.2GHz). This SoC is intended for dirt-cheap OTT boxes, is equipped with 4 independent USB 2.0 PHYs and also an integrated 100 Mbits/sec Ethernet PHY (but can still provide GBit Ethernet using an external PHY like RTL8211 as Xunlong implemented it on the 'Plus').The 'Orange Pi 2 [Plus]' followed, then the $15 'Orange Pi PC' was released and a new 'Orange Pi One' has been recently announced to be available for less than $10. CNX provided a nice comparison table here (but keep in mind that "SATA" means not SATA but an ultra-slow GL830 USB-to-SATA bridge and that "4 USB ports" means "slow due to shared bandwidth and internal USB hub")In my opinion the only H3 based Orange Pis worth a look are the 'PC' and the upcoming 'One' since the H3's feature set is quite unimpressive but its design makes it possible to produce really cheap boxes/boards without that much additional components on the PCB (no PMU needed and already containing an internal Ethernet PHY and 4 USB PHYs).The H3 SoC has been blamed for overheating way too much but fortunately this is just the result of Xunlong trying to advertise their H3 based SBCs as being able to run at "up to 1.6 GHz" and community members providing OS images with overclocking in mind. They did a really bad job modifying both dvfs and thermal settings and therefore their forums are full of complaints that CPU cores are shut down due to overheating or that you would need large heatsinks and also a fan to be able to use the H3 reliably.Fortunately these issues have been resolved in the meantime, the linux-sunxi community moves forward really fast with u-boot/kernel mainlining efforts for the H3 and real OSHW designs will also follow soon (Olimex plans to release two SBC based on H3).So I believe we will be ready with Armbian support for Olimex' and Xunlong's boards as soon as mainline kernel will be ready for H3.Igor started already to support the H3 based Orange Pis in Armbian-- see below.Let's have a look at existing hardware: The $15 Orange Pi PC. For latest informations always rely on the linux-sunxi wiki.Getting startedTo power the board you've to provide 5V through the power barrel connector or GPIO pins 2/4/6 (2/4 are connected to the DC-IN test point and 6 to GND). You can not power the board through micro USB since unlike other sunxi devices the H3 comes without PMIC/PMU (therefore also no support for a battery)In case no SD card is inserted the SoC tries FEL boot mode through the micro USB port. OS images for the H3 can be found on the orangepi.org web site. As usual the manufacturer supplied images are broken more or less so better start with the ones from community member loboris (if you use them don't forget to donate!)Unfortunately these intensified Xunlong's overvolting/overclocking attempts and increased a few values even more. But fixing is easy: I created a simple script (for Debian based distros only) that temporarely converts script.bin and replaces the wrong values with the linux-sunxi ones (should work with other H3 based Orange Pis as well)On the left loboris' overvolted dvfs table while idling through all available cpufreqs and on the right after repair:
If you repaired dvfs/thermal settings you'll be surprised that you neither need a fan nor heatsink -- the H3 idles at 1.5W and exceeds ambient temperatures only by 20°C without a heatsink. But be prepared that thermal throttling might occur under high load if you safe the heatsink. You'll find a few comparisons with and without heatsink here: http://linux-sunxi.org/User:Tkaiser#Tests_with_just_a_heatsinkSince we want to use the OPi PC as cheap home automation controllers we evaluated the possible input voltage range. Good news: DC-IN voltage can vary between 4.5V - 5.5V when you neither need USB nor HDMI (DC-IN will be directly routed to the power pins of USB/HDMI).Also the cheap camera module Xunlong sells for the different H3 models works flawlessly with just 4.5V. This makes it possible to power the board through 'el cheapo' passive PoE using the 2 unused cable pairs in Cat 5/6/7 cables. Real PoE works with 48V to avoid voltage drops over longer distances and it's a bit crazy to try PoE with just 5V. But when you use similar distances between PoE injector and devices and inject for example ~6V then the voltage range of 4.5V-5.5V will be fine. I suggested to Xunlong's Steven Zhao already to adopt passive PoE on the next Orange Pi One directly -- but he didn't get back to me.I also developed a heavily undervolted dvfs table for headless useage (won't work with a connected HDMI display since the Vcore voltage seems too low for the display engine) that works here with 2 OPi PC without problems (tested under full load up to 1.2 GHz): http://linux-sunxi.org/User:Tkaiser#Headless_without_connected_USB_peripherals_and_4.5V_DC-IN ( don't think about adopting these settings unless you're willing to verify they work!)Consumption/temperatures in headless mode:The OPi PC idles at 240-600MHz: 1.5W, 20°C above ambient temperature. All thermal values being read-out internally using RPi-Monitor -- see below. I used also the H3 without heatsink so be prepared that temperatures are way lower if you attach a heatsink to the SoC.Full load (cpuburn-a7 and sysbench running in parallel) on all 4 CPU cores:240 MHz: not exceeding 2.0W, 25°C above ambient temperature600 MHz: not exceeding 2.5W, 32°C above ambient temperature1200 MHz: not exceeding 3.3W, 50°C above ambient temperature2 CPU cores deactivated and testing again:240 MHz: not exceeding 1.9W, 23°C above ambient temperature600 MHz: not exceeding 2.1W, 29°C above ambient temperature1200 MHz: not exceeding 2.8W, 40°C above ambient temperatureThe multithreaded performance of 4 x 600 MHz and 2 x 1200 MHz is identical but when running at 600 MHz on all 4 cores the H3 already outperforms older dual-core Allwinner SoCs like the A20 easily. And since the lower the clockspeeds the less the Vcore voltage the SoC stays cooler and consumes less. Using a quad-core SoC for IoT stuff seems like overkill but if you clock the SoC down the 4 cores make perfectly sense.Therefore we go with the following settings for 'IoT controllers' to ensure they don't exceed 2.5W consumption even under full load:echo interactive > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo 240000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq echo 600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
With 8 OPi PC and a passive PoE injector like this one with these settings you're able to power the whole setup with a regulated 6V/4A PSU easily. And you still have the ability to double the performance of any device temporarely through echoing 1200000 to scaling_max_freq when needed.Who would've thought that you can use H3 based Orange Pis as energy efficient IoT devices consuming between 1.5W and 2.5W without a heatsink since common knowledge was 'you need a fan!' just a few weeks ago.Camera moduleXunlong sells also a cheap $6 camera module for the H3 based Orange Pi models based on GalaxyCore's GC2035 2MP sensor. When you want to use it with the OPi PC you'll also need an expansion board. When you order you've to tell Xunlong that you're using the OPi PC and they send the board together with the module:
The image quality is really horrible but at least you're able to use it with fswebcam or motion. I prefer the lowest resolution possible (640x480 pixels after applying these patches) because it makes no sense to store images with higher resolutions. At least motion works with the 2 fps settings currently possible and you might use OPi PC + camera module for surveillance purposes to detect motion.Regarding consumption/temperatures: when running motion together with the camera continuously consumption increases by 500-600 mW and SoC temperatures by 2-3°C (clocked at 240-600 MHz)For our use cases the H3 matches perfectly. If you fix the overvoltage/overclocking problems Xunlong introduced then you get a device that consumes between 1.5W and 2.5W and being already more performant when running at 600 MHz than older dual-core Allwinner SoCs. Using a quad-core SoC for IoT things makes sense since the SoC can run at very low core voltages which really helps with saving energy.Other use casesRegarding I/O bandwidth the H3 provides 4 independant USB ports that might be able to benefit from UASP with mainline kernel soon. So any H3 device with GBit Ethernet would make a nice NAS device. But since the older A20 features native SATA a better solution for building a NAS would be to get a pcDuino 3 Nano Lite for the same price. Some background infos as usual in the wiki: http://linux-sunxi.org/Sunxi_devices_as_NASAt the moment some people are trying hard to get OpenELEC running on the H3 and also progress is made to use HW accelerated video decoding. Since this stuff is WiP you should monitor these threads closely:RPi-MonitorI adjusted RPi-Monitor templates for the H3 and also wrote a small daemon to be able to monitor temperature/consumption related to Vcore settings (using the dvfs table settings in script.bin). Please refer to the thread in the Orange Pi forums.All you've to do is to install RPi-Monitor in the usual way, stop it and then do the following (depending on your distro being wheezy/jessie based) followed by a reboot:cd / && wget -O - http://kaiser-edv.de/downloads/RPi-Monitor-for-H3.tgz | tar xzf - update-rc.d rpimonitor-helper defaults 90 10 systemctl enable rpimonitor-helper systemctl start rpimonitor-helper
Update: In the meantime this has become a simple one-liner confirmed to work an all Debian based OS images for H3 boards. And in case you're running Armbian then it's just a a simple 'sudo armbianmonitor -r' call that installs/adjusts everything needed on any H3 board.
-
I had a quick look into the operation of the A64 lichee SDK:
I let build.sh run with the following config (redirected output here):
export LICHEE_CHIP=sun50iw1p1 export LICHEE_PLATFORM=dragonboard export LICHEE_KERN_VER=linux-3.10 export LICHEE_BOARD=t1
And ended up with a typical Android boot.img, containing both kernel and initrd and being created by Android's mkbootimg:
mkbootimg --kernel output/bImage --ramdisk output/rootfs.cpio.gz --board sun50i --base 0x41000000 --kernel_offset 0x80000 --ramdisk_offset 0x01000000 -o output/boot.img
At this point you're able to stick boot.img together with any suitable rootfs but there's still a lot of work to do. Everything users expect at the usual locations doesn't exist and everything that can be adjusted easily everywhere else doesn't work here (no config.txt as known from Raspbian, no uEnv.txt/boot.cmd known from distros using u-boot in a sane way, no easy access to sun50iw1p1-t1.dtb since we're booting from ramdisk with /boot being empty). Same situation again as with every other Allwinner SoC family in the past
I'm really curious whether the Pine guys figure out how to solve this problem without delivering a virtual machine image with an installed Ubuntu and the lichee SDK to every user so they can recompile the whole BSP when they want to switch the HDMI resolution for example
Seems both Allwinner's kernel and u-boot still rely on sys_config.fex (I put an example online, this one containing even lower clockspeeds defined): http://pastebin.com/Vh0P9w8a
BTW: build.sh indicates that we're seeing a few other ARMv8 (64-bit) chip families from Allwinner all being called sun5Xi:
if [ -n "`echo ${LICHEE_CHIP} | grep "sun5[0-9]i"`" ]; then export ARCH=arm64 fi -
http://linux-sunxi.org/Sunxi_devices_as_NAS#Benchmarking_.2F_Identifying_bottlenecks
"Always test from bottom to top" means: Use iperf to identify whether it's network related.
-
4 cores running between 480-1344 MHz (DVFS table containing 1200MHz@1.3V as highest value) and the contents of the cpu_budget_cooling/gpu_cooling/thermal-zones nodes: good luck without a heatsink (throttling) or with micro USB as DC-IN (sudden power-off without throttling)
And OV5640 as camera? Really?
-
cpufreq:
Since the M2 already replaced my Odroid C1 I need an addition M2 for playing
. I cannot really measure it but M2 seems to be faster as C1, just by feeling...Integer performance of C1/C1+ (Amlogic X805) is superiour to A31s, if you're talking about GPU stuff (Android) then the A31s PowerVR might be faster.
Regarding dvfs/cpufreq settings: Your device is ~99% of time in the lowest state (480 MHz @ 1V). No idea what's wrong.
What 'internal sensor' do you refer to? We've seen a few funny read-outs of thermal sensors with mainline kernel so I would always handle these values with doubt.
You could load one of the crappy OS images provided by SinoVoip that use the crappy Allwinner 3.3.0 kernel and do a
find /sys -iname "*temp*"
Maybe you find a more reliable thermal source (that's the only good thing regarding Allwinner's kernels. Since they're targeted at tablet operation the SoCs started to contain a thermal sensor and they included a driver to do CPU/GPU budget cooling. And normally the values are accessible through sysfs).
But that won't help that much either. When I had the M2 here (just to donate it to the linux-sunxi folks after a few days) I didn't realized this sort of problems. But I didn't take care that much about since the general situation with SinoVoip made me really crazy: http://www.bananapi.com/index.php/forum/general-discussion-for-bpi-m2/895-status-quo-of-m2-regarding-software-support
-
The "SDK" has been leaked. Allwinner uses kernel 3.10.65 and u-boot-2014.07 built with
aarch64-linux-gnu-gcc (Linaro GCC 4.9-2015.01-3) 4.9.3 20150113 (prerelease)
BSP looks horrible as usual...
-
I've already integrated the kernel for Banana PI-R1 for Fedora. You always find the latest version
Latest version being 4.2.x? And do you realize that repackaging the work others have done is quite simple?
@Igor: Might be the best idea to close/delete this thread to prevent further misuse.
@gerhardw: 'Integrating' a new kernel build including some patches for a switch IC into a distribution that's already prepared for and using mainline u-boot/kernel isn't comparable to the challenges the Pine64 people try to delegate to the community now. All they have is the A64 BSP from Allwinner that's suited for Android device developers. And while this BSP might be a good choice for those sort of people that do not care about sane code, kernel versions or software at all (they just want to sell their tablets using Android Lollipop) the standard SDK/BSP makes it really hard to transform it into a flexible build environment necessary for any SBC.
I would suspect mainline kernel/u-boot will be ready maybe sometimes in 2016 so all the Pine64 guys can do is to try to find someone who knows the platform, who knows Linux, who knows Allwinner's horrible BSP and can disassemble the BSP into something flexible and useable (relying on Allwinner's outdated u-boot and 3.10 kernel in the meantime). Currently it seems they search for someone that does that for free
-
Another small update regarding the M3:
In SinoVoip's current 'official' forum (time will tell how long it takes until they abandon this and start over with the next one like they did already before) the same question regarding the M3 will be asked again and again "How can i boot from SATA?!". Even via PM again and again. Only by people who aren't willing to accept the only possible answer "You can't. Banana Pi M3 has no SATA".
It's that simple: the M3 has no SATA port. Just one single USB port is used to connect all externally available USB ports and a very slow USB-to-SATA bridge through an internal USB hub. It's really that limited. So the question could've be "How can I boot from USB?" instead. And the only valid answer to that is: "Why would you? Are you insane?"
Every M3 comes with 8 GB eMMC that is at least twice as fast as the crappy GL830 USB-to-SATA bridge. Storing the rootfs on USB this way means slowing things unnecessarily down. On the M3 your best bet is to boot from eMMC since this is the fastest storage option you have. This is different to other incompatible SBCs that are also called "Banana Pi" that lack eMMC and where you might benefit from the rootfs stored on USB or even SATA (M1). But on the M3 the approach to boot from USB especially using the ultra-slow onboard USB-to-SATA bridge is simply moronic.
Next thing: Since it is not SATA but only USB you can never rely on something like 'root=/dev/sda1' since a connected USB thumb drive might be /dev/sda on the next reboot and your rootfs will never be touched since being now /dev/sdb1. To escape from that you've to use partition UUIDs instead. I documented the whole stuff already where it belongs to and won't repeat it here again to prevent uneducated users from doing harm to their installations (again: Booting from USB on the M3 is adopting a strategy suited for different SBCs wrongly).
The best strategy to deal with the M3's 'SATA port' is to ignore it. Performance of a connected disk is unnecessarily low (especially writes -- see above) and using the SATA-power connector to power a disk means risking sudden power-offs more often than necessary since the M3 is prone to running in undervoltage/undercurrent situations. It's strongly recommended to turn off every power savings if you try to use a HDD this way since when your M3 is busy and disk spin-up leads to another 1A peak current needed then it's time to pick your solder iron to bypass the crappy micro USB connector unfortunately being used for DC-IN.
BTW: I updated my RPi-Monitor template for Banana Pi M3 or let's better say A83T/AXP813 to be able to also monitor the 'cooling states': http://linux-sunxi.org/User:Tkaiser#Preliminary_RPi-Monitor_template_for_A83T
If you've installed RPi-Monitor already, it's enough to stop it, then do as root
cd /etc/rpimonitor/ && wget -O - http://kaiser-edv.de/downloads/RPi-Monitor-for-A83T.tgz | tar xzf -
restart RPi-Monitor, and you're already done (of course you should do this in a two-step process and check the MD5 checksum ef7220daadad5726b32b0d2270d4bffd first)
build script FSFS root experimental build option
in Advanced users - Development
Posted
I really don't see the main advantage of F2FS compared to ext4 with a commit interval of 600 seconds
Regarding enclosures, heatsinks and fans: If you build the enclosure correctly (standing upright, use of convection, enough airflow) then not even a heatsink might be needed at all. If you look into the LeMaker forums, then a user called cyryllo (?) built a BanaNAS case for the original Banana Pi. That's the only one that doesn't ignore thermal challenges, everything he created later does a really bad job in this area as does *every* commercially available enclosure for Banana Pi/Pro. Again: SoC and PMU, the two parts that might overheat are on the bottom side of the PCB where no airflow at all is possible with this crappy enclosures.
That's maybe the only advantage of the Banana Pi M1+ (trying to be a clone of LeMaker's Pro): There SoC and PMU are on the upper PCB side.