Search the Community

Tido, why should I start recommending crap? Have a look at this (incomplete) list to get the idea that there is a little bit more than the few SBC vendors you personally know: https://en.wikipedia.org/wiki/Comparison_of_single-board_computers (you should really accept that there exist more than 5 vendors and there's no need to choose vendors that got somewhat known/famous for supporting product A -- Banana Pi/Pro -- and now are only dealing with totally incompatible products B, C and D) When I read "some kind of debian for a webserver/hotspot and some other things which my current rasperry pi B+ is doing way too slow" I'm not able to recommend anything since I neither know a single SBC suitable as 'hotspot' nor do I have an idea what specific criteria are needed for 'some other things'. For a webserver I would've a look at boards with high I/O and network bandwidth that are able to run with mainline kernel. But regarding AP mode and 'some other things' I still have not the slightest idea. Since if one of these other things would be HW accelerated video encoding/decoding recommendations might look totally different.

Maybe that's due to a missing relationship between btrfs and Armbian? The state of btrfs (amount of bugs fixed, performance, stability) depends on the kernel version you use. As a rule of thumb: the higher the kernel version the better the btrfs support. Therefore it makes absolutely no sense to collect a knowledge base regarding btrfs+Armbian since all the informations are already available somewhere else. IMO there are four things to consider when using btrfs on the boards we support: never use btrfs for important data with old kernel releases. Use mainline never use btrfs scrubbing together with redundancy and 'automatic failure correction' on systems that lack ECC RAM (applies to every device Armbian supports). When you can't rely on DRAM contents scrubbing might corrupt data that was ok before! btrfs transparent file compression might increase throughpout when I/O bandwidth is the bottleneck (USB, SATA write with A10/A20 devices) btrfs transparent file compression might decrease throughput when CPU utilisation is already the bottleneck (you should never try GZIP on slow ARM devices, only lzo/lz4) One real problem 'for' btrfs is that informations are scattered through various places and are mostly outdated (same applies to 'knowledge' or 'best practices' regarding SSDs, eg. there exist still people that try to prevent swap files being written to SSD since they refuse to understand wear-leveling). I would suggest doing some tests on your own and starting with 'compress,noatime,discard' as the only mount options (SSD detection works since ages but does not turn TRIM on automagically). And a final note: You should never forget that Linux is an operating system targeted also at servers. There are a few abstraction layers between the SSD cells (some inside the SSD -- the flash transaction layer implementing wear-leveling, garbage collection and so on -- some in the OS in the form of buffers, filesystem semantics like 'CoW' and so on) and the representation of data. Monitoring accesses at the filesystem and at the blockdevice layer looks significantly different.

Hi. I had to force my way through the upgrade script working. I haven't rebooted yet, but I'm crossing my fingers . Here are the three issues: 1. cubox-i shows as "unsupported" and the script dies. /proc/cpuinfo shows: Hardware : Freescale i.MX6 ... ...which isn't in the list in the script. 2. The script crashes and can't handle the situation where the apt-get upgrade prompts you about configuration files. For example, my /etc/bash.bashrc was different than the packaged version. The script won't take input and hangs. I see the "-y" in the script, but for some reason it doesn't seem to work right. 3. /boot/script.bin - a symlink is made to a nonexistent file. It looks like this isn't important, but I'm not sure. The /boot/bin directory doesn't exist. 4. "cubox-i" isn't in the selection list of "board"s. I hardcoded it at the top and the script seems to have progressed. Thanks!

Hi. I just came from the world of RPi. In raspbx there is a script that performs a full backup of the SD card. In my case helped by crond, overnight, I mount an SMB route, and the script dumps the differences in the image. The script is raspbx-backup. I do not know how to adapt to this new image, because now there is only one partition and before had two, Boot and rootfs. I only know how to read between the lines. For me this was a blessing because it could break anything and in five minutes was like new. #!/bin/bash # RasPBX backup utility, version 1.2 # Author: Gernot Bauer <gernot@raspbx.org> # # This file is part of RasPBX. # # RasPBX is free software: you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation, either version 2 of the License, or # (at your option) any later version. # # RasPBX is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # files MOUNTPATH=/media/bkup BOOTMOUNT=/boot DEFAULT_RPI_IMAGE_SIZE=3724 DEFAULT_BBB_IMAGE_SIZE=1828 DEFAULT_IMAGE_SIZE=$DEFAULT_RPI_IMAGE_SIZE # subroutines setup_lo() { DEVICE1=`/sbin/losetup -f` if [ -z "$DEVICE1" ] then echo "Error setting up loop device." exit 1 fi /sbin/losetup -f -o 1048576 --sizelimit 78643200 $IMAGE_FILE if [ $? -ne 0 ] then echo "Error setting up loop device." exit 1 fi DEVICE2=`/sbin/losetup -f` if [ -z "$DEVICE2" ] then echo "Error setting up loop device." /sbin/losetup -d $DEVICE1 exit 1 fi /sbin/losetup -f -o 80740352 $IMAGE_FILE if [ $? -ne 0 ] then echo "Error setting up loop device." /sbin/losetup -d $DEVICE1 exit 1 fi } delete_lo() { /sbin/losetup -d $DEVICE1 if [ $? -ne 0 ] then echo "Error removing loop device." /sbin/losetup -d $DEVICE2 exit 1 fi /sbin/losetup -d $DEVICE2 if [ $? -ne 0 ] then echo "Error removing loop device." exit 1 fi } mount_image() { if [ ! -d $MOUNTPATH ] then mkdir $MOUNTPATH fi mount $DEVICE2 $MOUNTPATH if [ $? -ne 0 ] then echo "Error mounting root partition. Wrong image file?" delete_lo exit 1 fi if [ ! -d ${MOUNTPATH}${BOOTMOUNT} ] then mkdir -p ${MOUNTPATH}${BOOTMOUNT} fi mount $DEVICE1 ${MOUNTPATH}${BOOTMOUNT}/ if [ $? -ne 0 ] then echo "Error mounting boot partition. Wrong image file?" umount ${MOUNTPATH} delete_lo exit 1 fi } unmount_image() { umount ${MOUNTPATH}${BOOTMOUNT} if [ $? -ne 0 ] then echo "Error unmounting boot partition." umount -l ${MOUNTPATH}${BOOTMOUNT} umount -l ${MOUNTPATH} delete_lo exit 1 fi umount ${MOUNTPATH} if [ $? -ne 0 ] then echo "Error unmounting root partition." umount -l ${MOUNTPATH} delete_lo exit 1 fi } create_image() { if [ -f $IMAGE_FILE ] then echo "Image file $IMAGE_FILE already exists!" echo "Please remove it manually or specify a different file." echo "Call \"raspbx-backup $IMAGE_FILE\" to make a backup to this file." exit 1 fi apt-get -y install dosfstools rsync parted if [ $? -ne 0 ] then echo "Error installing required tools." exit 1 fi echo "Creating image file. This will take a while..." SEEKMB=$(expr $IMAGE_SIZE - 1) dd bs=1M count=1 seek=$SEEKMB if=/dev/zero of=$IMAGE_FILE if [ $? -ne 0 ] then echo "Error creating image file." exit 1 fi LASTSECTOR=$(expr $IMAGE_SIZE \* 2048 - 1) sync parted $IMAGE_FILE << EOF mktable msdos unit s mkpart primary fat32 2048 155647 mkpart primary 157696 $LASTSECTOR quit EOF if [ $? -ne 0 ] then echo "Error creating partitions." exit 1 fi setup_lo mkfs.vfat $DEVICE1 if [ $? -ne 0 ] then echo "Error creating FAT partition." delete_lo exit 1 fi mkfs.ext4 $DEVICE2 if [ $? -ne 0 ] then echo "Error creating ext4 partition." delete_lo exit 1 fi mount_image mkdir ${MOUNTPATH}/dev ${MOUNTPATH}/media ${MOUNTPATH}/mnt ${MOUNTPATH}/proc ${MOUNTPATH}/run ${MOUNTPATH}/sys ${MOUNTPATH}/tmp if [ $? -ne 0 ] then echo "Error creating directories." unmount_image delete_lo exit 1 fi chmod a+rwxt ${MOUNTPATH}/tmp unmount_image delete_lo } do_backup () { if [ ! -f $IMAGE_FILE ] then echo "Image file $IMAGE_FILE does not exist." exit 1 fi setup_lo mount_image sync rsync -aDH --partial --numeric-ids --delete --force --exclude '/dev' --exclude '/media' --exclude '/mnt' --exclude '/proc' --exclude '/run' --exclude '/sys' --exclude '/tmp' --exclude 'lost\+found' --exclude '/etc/udev/rules.d/70-persistent-net.rules' / ${MOUNTPATH}/ if [ $? -ne 0 ] then echo "Error running backups." unmount_image delete_lo exit 1 fi unmount_image delete_lo } # start if [ `grep -c "/boot/uboot" /etc/fstab` -ne 0 ] then BOOTMOUNT=/boot/uboot DEFAULT_IMAGE_SIZE=$DEFAULT_BBB_IMAGE_SIZE fi # command line options for i in $* do case $i in *) IMAGE_FILE=$i ;; esac done if [ ! -z "$IMAGE_FILE" ] then do_backup exit 0 fi echo "RasPBX backup utility. Read the documentation here: http://raspbx.org/backup" echo echo "In the following process a new image file will be created, mirroring your" echo "complete system. The size of this file should be identical to the size" echo "of your SD card. Put this file onto a mounted USB thumb/hard drive or" echo "mounted network share. Don't put it on your SD card!" echo "Once the image file is set up backups can be made to it in an automated" echo "fashion with:" echo echo "raspbx-backup <path_to_image_file>" echo while [ -z "$IMAGE_FILE" ] do echo -n "Image file including full path: " read IMAGE_FILE done ROOT_PART=`cat /proc/cmdline | sed 's/.*root=\([^ ]*\).*/\1/'` ROOT_SIZE=0 SIZE_DETECTED=0 if [ ! -z "$ROOT_PART" ] then ROOT_SIZE=`sfdisk -s $ROOT_PART` fi if [ $ROOT_SIZE -gt 102400 ] then DEFAULT_IMAGE_SIZE=$(expr $ROOT_SIZE / 1024 + 65) SIZE_DETECTED=1 fi echo echo "Specify the size of the image file in MB. Defaults to $DEFAULT_IMAGE_SIZE MB, which" if [ $SIZE_DETECTED -eq 1 ] then echo "has been calculated from the actual size of your root partition." else echo "is the original RasPBX image file size (keep the default if you did not" echo "resize your root partition)." fi echo -n "Size in MB [$DEFAULT_IMAGE_SIZE]: " read IMAGE_SIZE if [ -z "$IMAGE_SIZE" ] then IMAGE_SIZE=$DEFAULT_IMAGE_SIZE fi echo create_image echo echo "Running backup now..." do_backup echo "Finished." exit 0

If we're talking about Linux -> Linux then choosing btrfs on both sides would be the best solution since you can then create consistent syncs (impossible with rsync!) in fewer time more safely. Just create a btrfs snapshot on the client device (and flush open databases before) and send the snapshot to the remote server using 'btrfs send/receive'. I don't now whether btrfs' FAR format (to transport the snapshot) uses the source's checksums and compares with the destination's in the meantime but that's something a subsequent rsync (--dry-)run could provide. We do syncing with a similiar approach (relying on Solaris and ZFS but also using snapshots and 'zfs send/receive') through VPNs for quite some time and never experienced any problems since the transmitted data was also checked/retransmitted at the TCP/IP layer. Well, I know that saying 'forget about well known mechanisms and become an early adopter' sounds somewhat weird when it's about backup. But if no one starts implementing/testing new methods things can't improve and the word won't be spread (that there exist far better alternatives to well known tools in the meantime)

In my eyes it's relatively easy (disclaimer: I used/contributed to Bananian first but switched very fast to Armbian over a year ago). Simply count boards supported OS 'variants' commits made amount of available documentation active contributors and decide then. Nico (the individual behind Bananian) is focused on one secure headless distribution (keep that in mind if you use insufficient tools like sftp since 'performance' might be influenced massively by the SSH ciphers being negotiated between 'client' and 'server'!) but doesn't spend that much time on further development in the meantime. I wouldn't say Bananian is a bad choice but the 'speed' of development already scares me a bit. As an example: Bananian uses an ugly hack (provided by me) to read out the SoC temperature. In the meantime better alternatives exist and I made suggestions to Nico to improve this. But no interest, they still just try to maintain these ugly hacks. Unfortunately this is true for other areas as well. I would believe we'll see a lot of improvements in and around Armbian this year therefore the choice is easy

Zador, it's definitely too early to try the scripts out. I just collect pieces of code 'known to work' but the most important script's contents now is the structure and my assumptions the script code might express (eg. showing that a few variables used in Armbian might require more work if changed in the future -- eg. $ID containing the board's name) In the meantime I came to the conclusion that the armbianmonitor approach has to co-exist with rpimonitor (or any monitoring solution one might use). That means we only provide a set of data sources (through symlinks, template's contents and a daemon approach where it's necessary to not only collect data but to provide a more intelligent representation that can be used by any monitoring tool -- eg. the whole battery stuff) that any user might use or not. Eg. when someone installed RPi-Monitor on his own and extended the configuration in /etc/rpimonitor extensively (using environment sensors for example) we won't overwrite anything but provide template contents instead that can be easily adopted by the user by either including our templates in his data.conf or simply copy&paste from our templates to get the data sources armbianmonitor provides into his own customised templates) Regarding your questions/suggestions: I would take the actual set of data sources RPi-Monitor uses (just modify it slightly, eg. leave out the 'firmware' version since this doesn't apply to the boards Armbian supports). The board specific things are just thermal and/or consumption stuff so we will provide a huge amount of data even when board/kernel does not support these special read-outs (the _DealWithNewBoard_ case). Apart from this board specific stuff (great for supporting users if they experience stability issues due to hardware/power problems!) the most added value will be generated by dynamic template creation for disk/filesystem stuff and also 'monitoring' itself. Filesystems: Still not sure whether we should use a config file (one watchpath per line, eg. /, /data and so on) and create templates dynamically based on the config file's contents (risking that people create templates that won't work) or simply abandon /etc/armbianmonitoring/filesystems.conf and parse the output of 'df' instead (creating templates for / and the mountpoint of every other sd* disk device automagically) Disks: I also came to the conclusion that smartd won't work in our situation (due to preventing spin-down). It's necessary to specify the tool (hddtemp or smartctl), the smartctl mode (nothing for SATA connected disks but eg. '-d sat' or '-d usbprolific' and so on for USB disks) and the appropriate command line to get temperature values if hddtemp can not be used, eg. /sbin/hdparm -C DISK | egrep -q "standby|sleeping" || /usr/sbin/smartctl -d sat -a DISK | awk -F" " '/Temperature_Cel/ {printf $10}' I made many tests with different USB enclosures the last days, just to learn that hddtemp is crap (to be expected, the code is really old). I'll come up with a disk readme that will be hosted on Github together with the scripts if they're worth a try (at the moment they aren't -- just look into it to get an idea where I want to rely or have to interact with Armbian 'basics') Regarding representation of data. IMO the UI of choice is the web interface of RPi-Monitor (very lightweight using HTML5 and doing all the rendering work in the client's browser). RPi-Monitor already supports defining warning/error tresholds so UI elements change automagically their color if tresholds will be exceeded. Then I plan to consistently provide the ability to use all the data sources we collect through SNMP (net-snmp package and a simple config file that can be used with an include rule). This might be an interesting 'business' feature for Armbian. Instead of buying an insanely overpriced networked thermal sensor for a rack cabinet (from APC for example) one could use a cheap SBC in the rack providing the very same data through SNMP and also doing a couple of other things. If monitoring is enabled and rpimonitord collects data in its many RRD databases then also all sorts of queries are possible. Eg. modify the motd stuff to not only show actual temperature, load, memory useage, whatever while logging in but the peak values from the last 24/48/168 hours (simply using rrdfetch). Also calling 'logger -t armbianmonitor' with actual values when collecting data in daemon mode is easy. There exist countless possibilities if basics are fixed. At the moment I need just a little feedback from you guys doing the development of Armbian's build scripts to get a feeling whether the idea to also maintain one more included script (and a bunch of templates in case basics change!) scares you too much or not. As an example: Changing the board's names ($ID in armhwinfo) in the future would also require to adjust the contents of setup-armbian-monitoring-environment. Also when something happens as your axp209_sysconfig stuff: the immediate need to extend templates will arise In the meantime I discovered that there aren't that much dependencies between Armbian and armbianmonitor as I thought in the beginning. But there still are some and the efforts to maintain this stuff has to be considered. Therefore I still wait for some comments on this... and develop the scripts and template stuff in the meantime (useable for both rpimonitord and net-snmp). If it's ready for try-out I will either push the stuff through Igor into Armbian's repo or provide it in an own repo. At the moment the script code is just meant for you other Armbian coders to look through and provide feedback regarding dependencies. BTW: Another interesting RPi-Monitor feature is the 'addons' functionality. In case the user chooses armbianmonitor 'debug' functionality we could activate some of those addons (eg. displaying the 'top' 10 processes through RPi-Monitor's web UI or anything else that helps with debugging strange problems)

Be very very careful. There exist no correct specification regarding GPIO pin layout for the Banana Pi M2: http://www.bananapi.com/index.php/forum/general-discussion-for-bpi-m2/411-m2-gpio-defininiton?start=6#2648 All the glorious 'Team BPi' (that provided so much crappy software and wrong informations and is responsible for missing informations and support) did, is to steal the above picture from http://www.raspberrypi-spy.co.uk and remove their logo. Don't expect that any pin mapping is correct, it's just a manipulated picture stolen from somewhere else. Please crawl through the two most horrible forums ever to get a clue how much of this stuff simply is wrong: http://www.bananapi.com/index.php/forum/general-discussion-for-bpi-m2 (this is 'Team BPi's former official Banana Pi forum abandoned a few months ago) http://forum.banana-pi.org/c/bpi-m2 (this is the current official forum -- maybe they already prepare to abandon this and start over with a fresh one somewhere else? At least the most moronic marketing person ever that normally floods the forum with useless crap is quiet. Not a single @sinovoip post the last days!) The best thing you can do with a M2 is to use it as headless server or throw it into the bin. Ok, to be a bit more constructive: UART pin mappings depend on the device tree definitions when using Armbian (mainline kernel only available for M2). Maybe others can assist you. I won't waste my time with any of 'Team BPi's products any more (R1, M2, M3 -- I'm sure they already develop an M4 and M5).

A20 is simply the wrong SoC since it lacks the necessary interconnects. What you're thinking about might work with the i.MX6 Quad for example. It features SATA II (90-100 MB/s in both directions), a somewhat limited GbE implementation (400 Mbits/sec -- you might want to use this with RGMII and an external GBit Ethernet PHY for WAN) and a single PCIe 2.x lane to be used with a GbE PCIe controller connected to the BCM53125 for example. Then you've a quad core Cortex-A9 solution utilising up to 4 GB RAM (twice as much as with any Allwinner SoC) and acting like a router should act. How the BCM53125 behaves in this mode is irrelevant, you need not even drivers for this IC since it should be a dumb layer 2 switch. But you could also use MDIO to define additional VLANs (and you might even rely on VLANs for routing purposes if you don't care about security). In case you really care about powerful Wi-Fi too you would've to rely on a SoC made for that (providing a few more PCIe lanes to be used with different Wi-Fi mini-PCIe cards or combine i.MX6 with PCIe switches maybe just to realise that you're running in bandwidth issues). A good example is Marvell Armada 38x as used on the Clearfog or Turris Omnia. Again regarding the i.MX6: The Dual core variants have also PCIe (so you can combine the internal GbE MAC with a 2nd real PCIe NIC) but lack SATA therefore the quad core variant would be the best solution to build something comparable to Lamobo R1 that does NOT suck (Utilite Standard/Pro both use an Intel I211 as 2nd NIC that shows way better performance than the i.MX6's internal GbE implementation). There exist many vendors selling i.MX6 based SoM solutions so this would be the route to go to get something comparable to the R1 for 30 bucks more (the SoC alone is more expensive than an A20 and an additional PCIe controller increases costs also) But for a router/NAS combination encryption performance might also be interesting and so I would have a look at hardware accelerated encryption (Freescale's CAAM or Marvell's CESA). I would assume Marvell wins and the Turris folk will try hard to get CESA drivers upstream. Then Armbian support for the Clearfog might automagically benefit from this too.

Update: I adjusted the contents of the http://kaiser-edv.de/downloads/sunxi-monitor.tar.gzarchive (MD5 checksum: 6822bcd7fe5cb2403eed9747e7cfff52) in the following way: Now 2 templates exist: /etc/rpimonitor/template/axp209_cpu_pmu_temp.conf /etc/rpimonitor/template/axp209_cpu_pmu_temp_r1.conf The first will be used by default and calculates consumption correctly when being used with Olimex' Lime boards or the Lamobo R1 while running on battery (consumption calculated based on battery voltage read out through sysfs from AXP209 PMU). The axp209_cpu_pmu_temp_r1.conf template should only be used when you're trying to provide DC-IN through the battery connector on the Lamobo R1 (to compensate the crappy DC-IN 'solution' -- this is not necessary when using Olimex' boards). In this case (providing more than 4.2V on the LiPo connector and therefore disabling the charger) the voltage read-out doesn't work and 5V are hardcoded. Therefore nothing changes unless you're an unfortunate Lamobo R1 user since you might need to misuse the battery connector for DC-IN and then have to adjust the contents of /etc/rpimonitor/template/sunxi_axp209.conf to reference axp209_cpu_pmu_temp_r1.conf instead of axp209_cpu_pmu_temp.conf.

It's a bit hard to answer your questions since basically you write just 'I did it right but it doesn't work' (providing no informations for others to follow the steps you did). It seem's you're using the old Allwinner 3.4.x kernel so please have a look at http://linux-sunxi.org/Sunxi-tools#script-extractorto verify if/whether you exchanged anything correctly. I'm assuming you're using Armbian with legacy kernel (do you?) so it should work the way you did but if you rely on different OS images there might script.bin exist somewhere that will never be read by bootloader/kernel (the crappy OS images for Banana Pis from SinoVoip are a good example for this).

There's no need for a script. Simply lookup the UUID and use it in fstab. All the necessary steps are also outlined in the aforementioned Ubuntu link. And in case you want to upgrade to Jessie in the future and sometimes boot without the disk consider setting the 'nofail' option in fstab since otherwise booting will... fail... without available disk.

That's an Ubuntu feature: https://help.ubuntu.com/community/AutomaticallyMountPartitions You might try to follow the steps outlined in the link above and try it using the udisks package in Wheezy (but be prepared that many software packages in Wheezy are really outdated!). I would simply create the mountpoint and an fstab entry using the disk's UUID if you've not to deal with different disks all the time.

I have tried with bridge mode and without authentication. My android fail to connect and I have no traces in syslog or hostapd output. Does exist a way to try with a kernel 3.18 for example?

Whether the BCM53125 is capable or not has to be confirmed. If it can not be configured to separate 1 GbE PHY from the other 4 at startup the switch is not useable for routing purposes. Since BroadCom usually doesn't send out the informations you need unless you sign an NDA and order high numbers of components I doubt we will ever know. Anyway it's not useable together with the A20 as far as I understand (since you can only combine the internal EMAC/GMAC with either one externel Fast or GbE PHY). Therefore the whole idea to use this switch for routing purposes is still just a moronic idea that can't work. It's that simple, just try to accept it. A device that interconnects the networks it has to separate by default can not be called a router. After powering on or when the configuration is not appropriate it's just a dumb layer 2 switch that might be configured to use VLANs (and it has to be confirmed if the VLAN implementation is sufficient from a security point of view). Regarding the power issues nothing has been 'solved'. Only workarounds exist and both the manufacturer of the device and resellers leave it up to you to find the description of possible workarounds somewhere else. I already linked exactly to this thread for a reason: http://www.bananapi.com/index.php/forum/general/391-why-the-sata-disk-doesnt-work-on-bpi-r1?start=36#3624 If we only had to deal with software issues maybe this device could be recommended. But the many hardware design flaws (power, Wi-Fi, heat) can't be fixed and as we've seen recently the manufacturer simply doesn't give a shit about these issues. Foxconn/SinoVoip replaced the DC-IN barrel jack on Banana Pi M3 pre-production samples with the crappy micro USB connector and results are as expected. Sudden power-offs already with slight load: http://forum.banana-pi.org/t/banana-pi-bpi-m3-android-5-1-1-image-update/754/5 The manufacturer only cares whether you buy his products and not whether you can use them too. Only possible conclusion: Avoid these products or fool yourself.

Did you have a look at the schematics how the switch is powered? No, since you weren't able to do so. Lesson learned: Never ever buy a device again from a vendor not providing at least schematics. Better buy from vendors following the OSHW approach. You care about a device being marketed as being capable of doing this and that and it's not the case? Lesson learned: Never ever buy a device again from such a vendor using lies as part of their product marketing. It's that simple: Avoid any product from this vendor and you're done. We discussed some alternatives to the R1 in this thread: http://forum.armbian.com/index.php/topic/372-hardware-mod-bpi-r1/ The idea the R1 is based on is good. But implementation is simply crap. And on top of that the vendor actively prevented the community to jump in and fix his many software mistakes. Just have a look at the forums at bananapi.com -- we had to reverse engineer the power scheme to get a SATA disk working, they provided not a single working OS image and so on... this vendor's business model relies solely on producing hardware and let the community fix the software without being helpful at all. Again: Please remember: It's just a dumb layer 2 switch connecting all ports that can be configured through MDIO when Linux is up and running and the driver is loaded and you configured everything correctly and no bugs in the driver exist. In case you brick your device (after a denial of service attack filling your SD card with log messages for example) or when it boots it's always just a dumb layer 2 switch. If you want to use a router then the worst case scenario is defined as: WAN and LAN are disconnected. It always needs a running OS, an user-defined routing table and optionally appropriate firewall rules to allow packets to cross the border. With a switch board (yes, it's not a router board, it's a dumb switch board) like the R1 the worst case always means: WAN and LAN are connected on layer 2. To use this hardware as a router is moronic (applies to a whole bunch of cheap so called 'routers' as well)

Hi! Thanks again for your comments zador. My tune2fs output on the nand system (armbian 3.8 on NAND) is: root@siamserver:~# tune2fs -l /dev/nand2 tune2fs 1.42.5 (29-Jul-2012) Filesystem volume name: <none> Last mounted on: / Filesystem UUID: 31cdf62b-f9d8-4571-8df8-5d7be293b5e7 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize Filesystem flags: unsigned_directory_hash Default mount options: user_xattr acl Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 241440 Block count: 964608 Reserved block count: 48230 Free blocks: 218388 Free inodes: 159688 First block: 0 Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 235 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8048 Inode blocks per group: 503 Flex block group size: 16 Filesystem created: Fri Oct 30 11:50:19 2015 Last mount time: Thu Dec 31 22:00:06 2009 Last write time: Thu Dec 31 22:00:06 2009 Mount count: 13 Maximum mount count: -1 Last checked: Fri Oct 30 11:50:19 2015 Check interval: 0 (<none>) Lifetime writes: 5808 MB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Required extra isize: 28 Desired extra isize: 28 Journal inode: 8 Default directory hash: half_md4 Directory Hash Seed: 90bab9a4-3bb6-4584-a0b9-3c041c01265c Journal backup: inode blocks On the SD card system (data partition on armbian 4.7 legacy kernel): root@siamserver(ro):~# tune2fs -l /dev/mmcblk0p2 tune2fs 1.42.12 (29-Aug-2014) Filesystem volume name: siamdb Last mounted on: /data Filesystem UUID: d1d3e3fd-3861-45ab-a3f5-a746df6b1681 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize Filesystem flags: signed_directory_hash Default mount options: user_xattr acl Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 256512 Block count: 1048576 Reserved block count: 52428 Free blocks: 683870 Free inodes: 247434 First block: 0 Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 281 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8016 Inode blocks per group: 501 Flex block group size: 16 Filesystem created: Tue Dec 8 09:24:13 2015 Last mount time: Fri Dec 18 18:29:27 2015 Last write time: Fri Dec 18 18:29:27 2015 Mount count: 839 Maximum mount count: -1 Last checked: Fri Dec 11 17:10:32 2015 Check interval: 0 (<none>) Lifetime writes: 1554 MB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Required extra isize: 28 Desired extra isize: 28 Journal inode: 8 Default directory hash: half_md4 Directory Hash Seed: 4efda314-91f3-4745-b9ee-1893be445276 Journal backup: inode blocks I think both have journal enabled, so this won't explain the problem either - or am I missing something! regards

The only feature that's interesting on the Raspberry Pi is that one can use the VPU correctly now (after a few years). We use RPi B+ as IP camera (even when the CPU core is clocked with just 200 MHz the VPU is able to provide a 1080p@30 fps h.264 encoded video stream) or for digital signage, often combined. In the meantime also lightweight distros exist like http://dietpi.com For everything else the RPi is always the worst choice due to its one single USB 2.0 connection to the outside. Supporting the RPi would mean Armbian either focuses on a completely new use case (desktop stuff -- VPU) or on a completely new user base (clueless people).

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)

Have you try this way: root=UUID=e139ce78-9841-40fe-8823-96a304a09859 I'll recreate similar scenario later just to make sure.

Hi, I tried UUID and PARTUUID but none of them works. Maybe this is a U-BOOT issue. root@cubietruck:/home/lampra# grep -a --null-data U-Boot /dev/mmcblk0 U-Boot U-Boot SPL 2015.07-armbian-sun7i (Oct 11 2015 - 15:34:22) I will post a question at the sunxi irc

Try to set desired root by it's UUID. It should work. https://help.ubuntu.com/community/UsingUUID edit /boot/boot.cmd and change parameter root= , save, recompile, reboot.

Another update regarding software / OS images. In the meantime they released a few more images: http://www.banana-pi.org/download.html As usual without MD5/SHA1 checksums so you can not check whether your download is corrupted or not. But even if they would provide checksums it won't help since SinoVoip simply doesn't give a sh*t about anything other than selling hardware. Numerous downloads are corrupted (see here or here or here) and they simply don't react even if customers complain multiple times. At the moment they are also clueless how to flash a Linux image onto eMMC using FEL mode (this only works with the Android images using PhoenixSuit/LiveSuit) so in case you want to start a Linux image from the internal eMMC storage you would have to first flash it to an SD card, then boot from this card, then transfer the image using dd to /dev/mmcblk1. I did it through the network as follows: ssh tk@macbookpro-tk "dd if=/Users/tk/Downloads/ubuntu-mate-15.10-desktop-armhf-raspberry-pi-2-bpi-m3-sd-emmc-20151203.img bs=4m" | dd of=/dev/mmcblk1 Three times dd quit unexpectedly while writing to eMMC, then I simply lowered the maximum cpufrequency down to 1008 MHz and it worked. Seems there's a bug when writing to eMMC so be prepared to experience filesystem corruptions if you're booting from eMMC. At least you can use eMMC this way, the M3 boots from there when no SD card is present. I tried then their Ubuntu 15.10 image and had a laugh: They ship with enabled irqbalanced! It's a well known fact that irqbalancing doesn't work on ARM based SBCs and has a memory leak on platforms that lack PCI/PCIe. So be prepared that irqbalanced will eat up all your RAM over time and then the whole system has to be rebooted. It's completely weird to release an OS image for an ARM SBC with an enabled irqbalanced. Now they ship also with a small script called bpi-bootsel (source here) which can be used to overwrite the 1st sectors of the boot media to change the display resolution (all their images based on Allwinner's 3.3/3.4 kernel for Banana Pi M2/M3 still lack support for script.bin!). In /usr/lib/u-boot/bananapi/ there exist 2 subdirs with a few handpicked archives to provide a few display configurations (details here). And while this is a small step in the right direction it also means they do it still wrong since they're continually fixing critical bugs for the M3 that should also be applied to the 1st sectors (there's where u-boot, hardware initialisation and a kernel image lives -- don't expect this stuff being easily accessible in /boot/). In other words: The new OS images they provide now are already outdated and cut-off from important fixes they commit in the meantime to their BSP github repo. Just a few words regarding the BSP: The initial Readme.md was just wrongly copy&paste from the Banana Pi M2 and of course misses the most important information: How to setup a build environment (details here). Back to the OS images. I dropped Ubuntu 15.10 since I already have my own image upgraded (apt-get install update-manager-core && do-release-upgrade sometimes works as expected ). Then I tried their so called "Armbian 4.7" image: It's the same outdated u-boot/kernel stuff missing the last fixes combined with a crippled Armbian rootfs. Of course nearly all Armbian features don't work and it's not worth the time to further explore this crap. They did not even adjust the thermal read-outs or prevent kernel messages from spamming to console as it will happen from time to time when thermal throttling occurs -- see their own image below. It seems it's as with the M2 half a year ago and as a Banana Pi M3 user you'll have to wait until the community jumps in and provides OS images that aren't that crappy. Close to unbelievable but unfortunately true.

dmesg | grep usb [ 0.399281] usbcore: registered new interface driver usbfs [ 0.403635] usbcore: registered new interface driver hub [ 0.407825] usbcore: registered new device driver usb [ 0.442458] [usb_manager]: CONFIG_USB_SW_SUNXI_USB0_OTG [ 0.446259] [sw_hcd0]: usb host driver initialize........ [ 0.450484] [sw_hcd0]: open_usb_clock [ 0.475713] [sw_hcd0]: platform is usb host [ 0.520661] [sw_hcd0]: sw_usb_host0_disable start [ 0.537521] [sw_hcd0]: close_usb_clock [ 0.539983] [sw_hcd0]: sw_usb_host0_disable end [ 1.465566] usbcore: registered new interface driver usb-storage [ 1.474093] usbcore: registered new interface driver ums-alauda [ 1.479090] usbcore: registered new interface driver ums-cypress [ 1.486738] usbcore: registered new interface driver ums-datafab [ 1.491930] usbcore: registered new interface driver ums_eneub6250 [ 1.496925] usbcore: registered new interface driver ums-freecom [ 1.501851] usbcore: registered new interface driver ums-isd200 [ 1.506932] usbcore: registered new interface driver ums-jumpshot [ 1.511784] usbcore: registered new interface driver ums-karma [ 1.516867] usbcore: registered new interface driver ums-onetouch [ 1.521892] usbcore: registered new interface driver ums-realtek [ 1.526804] usbcore: registered new interface driver ums-sddr09 [ 1.531731] usbcore: registered new interface driver ums-sddr55 [ 1.536553] usbcore: registered new interface driver ums-usbat [ 1.821906] usb 3-1: new full-speed USB device number 2 using sw-ohci [ 1.827147] usbcore: registered new interface driver usbhid [ 1.830028] usbhid: USB HID core driver [ 2.191211] usb 4-1: new high-speed USB device number 2 using sw-ehci [ 2.621450] usb 4-1.1: new high-speed USB device number 3 using sw-ehci [ 2.769636] scsi1 : usb-storage 4-1.1:1.0 [ 2.871453] usb 4-1.2: new full-speed USB device number 4 using sw-ehci [ 3.101461] usb 4-1.3: new full-speed USB device number 5 using sw-ehci [ 4.990008] usbcore: registered new interface driver usbserial [ 5.000132] usbcore: registered new interface driver usbserial_generic [ 5.008092] usbserial: USB Serial Driver core [ 5.031642] usbcore: registered new interface driver ftdi_sio [ 5.102168] usb 3-1: Detected FT232RL [ 5.133077] usb 3-1: Number of endpoints 2 [ 5.168007] usb 3-1: Endpoint 1 MaxPacketSize 64 [ 5.191657] usb 3-1: Endpoint 2 MaxPacketSize 64 [ 5.220910] usb 3-1: Setting MaxPacketSize 64 [ 5.246835] usb 3-1: FTDI USB Serial Device converter now attached to ttyUSB0 [ 5.356697] usb 4-1.2: Detected FT232RL [ 5.381334] usb 4-1.2: Number of endpoints 2 [ 5.389025] usb 4-1.2: Endpoint 1 MaxPacketSize 64 [ 5.394416] usb 4-1.2: Endpoint 2 MaxPacketSize 64 [ 5.399036] usb 4-1.2: Setting MaxPacketSize 64 [ 5.415289] usb 4-1.2: FTDI USB Serial Device converter now attached to ttyUSB1 [ 5.424796] usb 4-1.3: Detected FT232RL [ 5.428032] usb 4-1.3: Number of endpoints 2 [ 5.435922] usb 4-1.3: Endpoint 1 MaxPacketSize 64 [ 5.440169] usb 4-1.3: Endpoint 2 MaxPacketSize 64 [ 5.443777] usb 4-1.3: Setting MaxPacketSize 64 [ 5.464739] usb 4-1.3: FTDI USB Serial Device converter now attached to ttyUSB2 [ 1146.326270] usb 4-1: clear tt 1 (9041) error -110 [ 4057.151681] usb 4-1: clear tt 1 (9051) error -110 [14647.266733] usb 4-1: clear tt 1 (9041) error -110 [183851.069396] usb 4-1: USB disconnect, device number 2 [183851.073556] usb 4-1.1: USB disconnect, device number 3 [183851.084548] usb 4-1.2: USB disconnect, device number 4 [183851.105603] usb 4-1.3: USB disconnect, device number 5 [183886.688101] usb 4-1: new high-speed USB device number 6 using sw-ehci [183901.844742] usb 4-1: device descriptor read/64, error -110 [183917.112428] usb 4-1: device descriptor read/64, error -110 [183917.343435] usb 4-1: new high-speed USB device number 7 using sw-ehci [183932.861216] usb 5-1: new full-speed USB device number 2 using sw-ohci [183933.078461] usb 5-1: not running at top speed; connect to a high speed hub [183933.097990] scsi2 : usb-storage 5-1:1.0 [188674.645430] usb 5-1: USB disconnect, device number 2 lsusb Bus 003 Device 002: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub uname -r Debian Wheezy 3.4.109-sun7i blkid /dev/sda1: UUID="f64f5613-ce08-49e9-b13a-356dcdcb1893" TYPE="ext4" /dev/mmcblk0p1: UUID="fbd8dfce-58fb-45a1-93d7-16895308a8d8" TYPE="ext4"

Можно, надо переÑобрать u-boot Ñ Ð¸Ð·Ð¼ÐµÐ½ÐµÐ½Ð½Ð¾Ð¹ конфигурацией и монтировать корневую Ñ„Ñ Ð¿Ð¾ uuid, иначе при уÑтановке карты во второй Ñлот вÑе поломаетÑÑ)