arox

As stated in the tutorial, you should assign an address to the bridge only.
 
The bridge forward everything on data link layer and the interface of the bridge then form/extract IP packet. Otherwise you will have a hard time to manage kernel routing tables...

find . -type d | awk -F/ '{printf("%"4*NF"s|-- %s\n", " ",$NF)}'
 
(find in current dir all files of type directory and process them threw awk with "/" field separator to print a space with 4 times number of fields width, then a bar and two dash and the last field.
 
awk is your friend

"time" is "built in" into the shell.
 
In order to use the full version described by "man", you should first install the full version in /usr/bin/time :
 
# apt-get install time.
 
And call it with the full path.
 
Also, when man fail to give doc because a package is missing, just google "man cmd".

"time" is "built in" into the shell.
 
In order to use the full version described by "man", you should first install the full version in /usr/bin/time :
 
# apt-get install time.
 
And call it with the full path.
 
Also, when man fail to give doc because a package is missing, just google "man cmd".

Many seems to think that theirs has to be very long and powerful (if you understand what I mean). In fact, a well designed enclosure can assume this function. And in any case the quality of the thermal interface is more important than anything else.

Manufacturers will always add all hardware features that does not cost a lot : i.e. crappy cheap wifi and so on, because they do not bother to provide good drivers.
 
In the other hand, RAM is always priced a lot and thermal design bad. If I want a SBC for specific use case like computing (and not a X86 server), I want it to be passively cooled and energy efficient. Storage is also a choice : either emmc, either a good bus design for drives.
 
I simply cannot find a SBC for a use case because they are all designed for "general purpose" like a RPI or expensive with no guarantee of software support.
 

I don't understand your point.
 
The problem when designing a distributed system is to ensure reliability when systems crash, reboot or the network disconnects. For systems like SBC or microcontrollers, you have to detect crash and assure recovery, maintenance and debugging on system without screen and keyboard - and avoid corrupted storage problems. For network, you must provide reconnect procedures (witch also suppose that the disconnection has been detected), frequents with over-the-air networks, or in case of peer restart.
 
I use (and you were aiming to do so ?) MQTT with a local broker for that reason. I first so that others used it on this forum and initially thought I didn't need it. But I changed my mind : MQTT allows to deploy a multiple "publisher" / "subscriber" loosely connected network with a trivial message protocol and some option to control reliability of message delivery. Even with that, you will have to carefully design your agents to handle crash, disconnections, sensor errors or network failures. At least, I have found that the Eclipse MQTT broker "mosquitto" is reliable.
 
Basically you can handle MQTT disconnects at application level with a 15 lines of python code MQTT client (if you don't bother to have some samples lost). Sensors error handling is more difficult (often needs reboot). Wifi problems depends on drivers and hardware (so carefully choose the SBC and wifi controller). To ensure reliability of unattended systems connected by wifi is even more difficult in particular with SD cards, rw root fs and OS targeted at graphical UI use case ...
 
I am not sure smtp is a good idea for IoT. It is reliable but slow. MQTT is a messaging protocol with open subscription (no recipient list) and 1 second latency if you implement your broker.  Much more like a "software bus". Ideal in a local network behind a firewall were you don't even need to bother with credentials. If you like complex and heavy solutions or like to be worked up, try Nodered in a Docker container.
 
Well, that is just my point of view ... but I have lost track of the number of agents at my home for a long time. Fortunately, bugs (hardware, software or design) remind me of some regularly.

I have exactly the same need, except I am looking for two identical boards : it is my KISS (*) version of a cluster of application, storage and backup server with disk redundancy. One application and storage online server and an other offline backup/archive server with the same content + the archives. So I can switch the boards in case of failure or restore the content of last day in case of file loss.
 
I use two BPI M1 at present - one having lost its USB ports. One SSD for app and one bigger HDD for bkp. 
So ? SATA is "has been" and is over-performed my new standards but it fulfill my present requirements, and it is a cheap and conservative solution. TRS-80 is wright : the best is to use USB3 and a converter (you will experience a huge improvement comparing BPI), so you are not limited on the choice of the boards and will continue to use the disks for years. Just, some return of experience will be valuable for choosing one : for my desktop, I buyed a uASP able JMicron controller which is allegedly not compatible with a via controller and seems a bit power hungry. 
 
So any modern Rockchip 64 bits, reasonably priced fanless boards that do not consume to much power would do the trick for me. (2 boards and 2 "good" adapters). And with OS on disk, no need for eMMC. 
 
(*) KISS : Keep it simple stupid. Security is antinomic with complexity. And when you experience a hardware failure many years after having put in place the machine and forgotten everything about how it works, the last thing you need is complexity and deprecated, out-of-date, not retro-compatible or not replaceable software or hardware.

I have exactly the same need, except I am looking for two identical boards : it is my KISS (*) version of a cluster of application, storage and backup server with disk redundancy. One application and storage online server and an other offline backup/archive server with the same content + the archives. So I can switch the boards in case of failure or restore the content of last day in case of file loss.
 
I use two BPI M1 at present - one having lost its USB ports. One SSD for app and one bigger HDD for bkp. 
So ? SATA is "has been" and is over-performed my new standards but it fulfill my present requirements, and it is a cheap and conservative solution. TRS-80 is wright : the best is to use USB3 and a converter (you will experience a huge improvement comparing BPI), so you are not limited on the choice of the boards and will continue to use the disks for years. Just, some return of experience will be valuable for choosing one : for my desktop, I buyed a uASP able JMicron controller which is allegedly not compatible with a via controller and seems a bit power hungry. 
 
So any modern Rockchip 64 bits, reasonably priced fanless boards that do not consume to much power would do the trick for me. (2 boards and 2 "good" adapters). And with OS on disk, no need for eMMC. 
 
(*) KISS : Keep it simple stupid. Security is antinomic with complexity. And when you experience a hardware failure many years after having put in place the machine and forgotten everything about how it works, the last thing you need is complexity and deprecated, out-of-date, not retro-compatible or not replaceable software or hardware.

My rational is that my "desktop machine" is *just* a (32 bits/4GB) Vivaldi-Browser-node in a network of arm (and now xtensa) fanless nodes. And with multi-head and support of usable multimedia tools I can simplify and improve my organization. (I was using 3 hosts, 3 screens with 1 kbd/mouse before).
 
I was able to use a BPI M1 for so long because it's just a node (and thanks to Igor's work).
 

Thank you for sharing that because it is hard to choose a SBC and disastrous to make the wrong choice. 
 
I buy SBC for projects. Projects require a limited number of feature for the SBC but good hardware and software for the purpose, and are time consuming : it implies not only the SBC itself but housing, electronic, cooling, powering, backups, storage, network, documentation, installation, wiring, maintenance, (useful and remote) logging, access, scalability and of course software stability.
 
This is why software and hardware stability is crucial : the project can simply not reach an end without stability and other projects must wait. Making a bad choice implies a lot of work done for nothing.
 
The most difficult for me was finding a solution for my desktop machine : I have just replaced my Banana PI M1 with a RPI4 ! Because :
- video driver now allow youtube video to run smoothly !
- video drivers allow using vlc and mplayer with acceleration quite "out of the box".
- it offers 2 hdmi output !
- USB3 allow to use a cheap SSD and nor rely on ?!*§@¤ SD Card or limited offer on eMMC solutions ! (but I couldn't use UASP with a JMicron controler)
- it is scalable with 2, 4, 8G RAM versions
- you can find cheap and efficient passive cooling housing !
- RPI is supported by my toolchains for espressif micro controllers (esp-idf, nodemcu, arduino).
(I still run on 32 bit because stability is more important than performance).
 
So my project really started when I could check all those requirements were fulfilled :  reorganize my workspace, servers, audio and TV setup, backups, archiving, project tools and management ...
 
Other vendors seems to me to lay behind for desktop : at least offering cheap multihead solution and memory for hungry browsers ?
 
So my other needs are - at present - much more easy : I use *old* SBC. BPI M1 for storage because (disastrous SATA performance is not a problem (yet) for my usage) and they are stable and power efficient for file/archive servers - just using an out-of-date armbian disto with 3.1.110 kernel. RPI zero for CAMs and TV tuner (need to be upgraded for stability and SDcard elimination). My Network Firewall / Gateway / proxy / MQTT server is a tiny nanopi (need to be replaced but I want something as power efficient that can also handle TVhat tuner.
 
My wifi gateway is a Gl-inet / openwrt device. My GPIO servers (IoT) are migrating to esp32 one after the other.
I wish I could have installed a mesh network. But I never could make Bluetooth work reliably on linux ! So I use wifi and reconnect handlers - because it rarely work smoothly out-of-the-box. (And all my SBC also need power and remote access control). When we loose count of network nodes, there is always something out of service somewhere.
So ?
 
It implies a lot of work - for armbian developers and maintainers as well for end users - to handle *useful* projects. SBC providers cannot simply assemble the last components for TV box or smartphone and "rely on community". For my use cases, Hardware power and functionality is nothing without software, and hardware and software is nothing until it has been integrated in a box with other components, wiring, and security (backup, documentation, spare parts, network ...).
 
Perhaps I am not a typical user ?

"Different people, different needs!"
 
Well, my first Unix workstation was a microVax (Digital Equipment). One tiny mips and it ran X11 !
 
My new H3 BPI boasts :
SMP: Total of 4 processors activated (19200.00 BogoMIPS)
LOL
 
I should say my new BPI M2+ is not the best card I ever saw, but eMMC is very valuable. It replaces now a RPI-B as firewall/gateway with 10 times cpu power and IO bandwith but with half the consumption (2 Ethernet - GbE + USB, wifi, Bluetooth, no display = 2,5 W - PSU has 75% efficiency). The (2nd level) http proxy cache can now run on the gateway thanks to eMMC).
 
I will test DRAM lower frequency after reinstalling the mail gateways.

Hi all,
 
I wrote a blog post about some of the issues with the Raspberry Pi that you can find scattered around this and other forums. Hopefully it will save us time from repeating ourselves over and over again.
 
As we know, people don't read the forums until it's too late.

https://ownyourbits.com/2019/02/02/whats-wrong-with-the-raspberry-pi/
 
Thanks tkaiser, I took a sample output from your vcgencmd script.

We're not talking about a development board that makes accessing the hardware and especially the boot process easy but a rather expensive surveillance device people buy for whatever bizarre reasons. The technical details are so f*cking boring that everyone who disassembles the spy tool to get access to this boring PCB IMO must be mad.  
 
If someone wants to waste a lot of time please contribute to Armbian in a more sensible way instead of wasting your time on hardware not worth a look with a target audience (for Linux on this thing) that does not exist.
 

I suppose that some manufacturer spare money by not registring an address. Nanopi air should anyway have one.
 
For my part, what I donnot understand is the 115200 in hciattach command : AP62XX is a serial module, and all BT traffic is routed in HCI over serial communication link. So how could someone reach 3 Mb/s of data rate over a 115200 b/s line ?!?. I always change this for 1500000. Otherwise an a2dp link drop packets for example.
 
Another funny thing is the usage of 11:xx...etc or 43:xx...etc addresses. By default the system load a BNEP module, but dont try to configure a NAP acces point with that : it will try to use the address as an ethernet address in BNEP emulation - and fail with bad reporting because an address with an even first byte is illegal for Ethernet.
 
I use a Nanopi neo 4.14.14 kernel with btusb dongle to create ppp/rfcomm links. I previously used a Nanopi air or a BPIM2+ 3.4.17 kernel for BNEP links. With nanopis or bpi I crash the kernel every other day. So did you achieve some stability with that ?
 
Anyway, with BR/EDR mode and bluez, I need to reset the controller periodicaly because it became anable to create basic link (ACL) after some time when forming  multiple piconet. So I also experiment with BLE.
 
I tested Bluepy - wich can handle "central" (but not peripheral) role in python. But I doubt to achieve stability and low latency in connected mode. So I am now developping my own trivial mesh protocol by advertising/scanning transmission with gatt/paypal in golang on RPI (and chip with some tweak in scan report demux) ...
 
I didnt try bleno/noble. It seems to shunt BLUEZ insane routing through dbus/xml unstable/undocumented messaging API (as do also gatt/paypal) and handle itself the HCI interface. I am not sure about the difference in socket interface in both implementation ?
 
I am not sure of the role of 4343A0.hcd or so files downloaded by hciattach. If this is the firmware for BT controller, there certainly is a lot of bugs in this and we need more robust version ?

I had the same problem with NanoPi Neo Air and bluetooth as mantabernd
 
hciconfig -a  didn't show any device
and hciattach timed out:
hciattach /dev/ttyS3 bcm43xx 115200 flow bdaddr 43:29:B1:55:01:01 bcm43xx_init Initialization timed out.  
The other replies here by Larry Bank and thc013 helped me solve it. 
 
uname -a Linux nanopiair 4.14.52-sunxi #581 SMP Fri Jun 29 10:05:07 UTC 2018 armv7l armv7l armv7l GNU/Linux  
I first used armbian-config to install BT support.
Then I edited the /boot/armbianEnv.txt to add uart3 overlay and param_uart3_rtscts=1 to enable rts and cts.
Since I was unsure if it was supposed to be uart1 or uart3 I looked at the schematic here and saw it was connected tu uart3: http://wiki.friendlyarm.com/wiki/images/9/98/NanoPi-NEO-Air-1608-Schematic.pdf
My armbianEnv.txt:
verbosity=1 logo=disabled console=both disp_mode=1920x1080p60 overlay_prefix=sun8i-h3 param_uart3_rtscts=1 overlays=uart3 usbhost1 usbhost2 rootdev=UUID=91977eb8-39b7-4db4-ac8b-2eb075f6eef2 rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u  
Then I edited /etc/default/ap6212 to change from ttyS1 to ttyS3:
# # Default it is called to be uncertain wich MAC address the chipset has. # Therefore it is recommendable to set the MAC address manually. # This can be done by setting the variable MAC_ADDR with a chosen value. # If this variable is empty or not set the default 11:22:33:44:55:66 will be chosen. MAC_ADDR=43:29:B1:55:01:01 # PORT=ttyS3  
After a restart I run these commands:
# rfkill unblock all # echo "0" > /sys/class/rfkill/rfkill0/state # echo "1" > /sys/class/rfkill/rfkill0/state # echo " " > /dev/ttyS3 # devmem2 0x1f00060 b 1 # echo 205 > /sys/class/gpio/export # echo out > /sys/class/gpio/gpio205/direction # echo 0 > /sys/class/gpio/gpio205/value # echo 1 > /sys/class/gpio/gpio205/value # hciattach /dev/ttyS3 bcm43xx 115200 flow bdaddr 43:29:B1:55:01:01 # hciconfig hci0 up From the schematic I found that BT_RST_N is connected to GPIOG13. I didn't find any documentation (anyone know where it is?) saying which gpio number GPIOG13 maps to but I found that GPIOG11 maps to 203 ( http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO_Air ).
 
After running above commands hciconfig -a returns this:
# hciconfig -a hci0: Type: Primary Bus: UART BD Address: 43:29:B1:55:01:01 ACL MTU: 1021:8 SCO MTU: 64:1 UP RUNNING RX bytes:983 acl:0 sco:0 events:46 errors:0 TX bytes:2719 acl:0 sco:0 commands:46 errors:0 Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH SNIFF Link mode: SLAVE ACCEPT Name: 'nanopiair' Class: 0x000000 Service Classes: Unspecified Device Class: Miscellaneous, HCI Version: 4.0 (0x6) Revision: 0x6a LMP Version: 4.0 (0x6) Subversion: 0x2209 Manufacturer: Broadcom Corporation (15)  
The last step will be to add the script to /etc/init.d/ap6212-bluetooth (same as above but with the variables for port and mac_option) :
rfkill unblock all echo "0" > /sys/class/rfkill/rfkill0/state echo "1" > /sys/class/rfkill/rfkill0/state echo " " > /dev/$PORT devmem2 0x1f00060 b 1 echo 205 > /sys/class/gpio/export echo out > /sys/class/gpio/gpio205/direction echo 0 > /sys/class/gpio/gpio205/value echo 1 > /sys/class/gpio/gpio205/value sleep 0.1 hciattach /dev/$PORT bcm43xx 115200 flow bdaddr $MAC_OPTIONS hciconfig hci0 up  

You didn't tell what BT device you use and what usage you intend to do with BT.
 
The BT chips on board (AP6212 for example) need an "hciattach" process - sometimes tricky with the init system. USB dongle need not.
 
You probably will need a bluetoothd process (and check that it does not put your "hci0" device down). And then you will need the dbus running (and configured) -- even if BT is the only app needing that sort of thing on a "minimal system".

Had a little time to test this today, as expected, it's junk.  Being copper it moves heat quickly, having no real fins or the like it simply has nowhere to move it to.  It can handle "smoothing out" the heavy thermal loads, but it simply can't move enough heat.

If I understand well ... You fail to clone a Linux image with a Windows/Mac software and complain Linux is bad ?!?
 
Linux is not user friendly very much (for beginners). It was from the start a unix derivative and a study project from a student. And SBC are not user friendly - and SBC other than RPI are even less. So what use complaining and why not instead buy a full Intel (tm) with Windows (tm) computer ?
 
And if sofware for your SBC is not as good as expected, why not complain to the manufacturer which sell "development cards" and rely on "developper community" without helping them in return ?

If I understand well ... You fail to clone a Linux image with a Windows/Mac software and complain Linux is bad ?!?
 
Linux is not user friendly very much (for beginners). It was from the start a unix derivative and a study project from a student. And SBC are not user friendly - and SBC other than RPI are even less. So what use complaining and why not instead buy a full Intel (tm) with Windows (tm) computer ?
 
And if sofware for your SBC is not as good as expected, why not complain to the manufacturer which sell "development cards" and rely on "developper community" without helping them in return ?

Right, my comment on eMMC is purely about reducing/removing interconnects, the primary failure point in most systems.  Speed is secondary in such embedded systems.  I would ideally use the SD card only for data storage, for instance data logging/etc.  

Better use ddrescue for this (apt install gddrescue). Then to get an idea how much to shrink the partition one could mount /dev/loop0p1 (in case it's a single partition image -- better check /proc/partitions) and look at the output from 'df -k' then und umount the partition. And in case it's not about to create an image that gets burned directly after but to archive an image (compressed) then it's a good idea to mount the shrinked partition and zero out all empty space:
dd if=/dev/zero of=/mnt/loop0p1/zeroes bs=1M || (sync ; rm /mnt/loop0p1/zeroes ; umount /mnt/loop0p1)  
 
Why re-inventing the wheel? The way better alternative is /etc/init.d/resize2fs start. And cloning already existing installations is dangerous for a variety of reasons since you end up with same SSH keys on all devices and on some boards MAC addresses of Ethernet or Wi-Fi are stored in files below /etc (so you end up with duplicate MAC addresses in your network causing all sorts of 'funny' troubles).
 
If anyone starts to think about cloning Armbian installations that were already booted (and ran /etc/init.d/firstrun therefore), it's strongly recommended to read and understand this script (except the useless do_firstrun_automated_user_configuration function). Since the best idea is to prepare the installation to clone in a way that on new boards both /etc/init.d/firstrun and /etc/init.d/resize2fs get started again (even if a full expand is not wanted, better shrink the partition before to an absolute minimum and use the documented tweaks to control resizing later)

I use a BPI M1 as file server. I use 2.5i disk because it doesn't need 12V, don't make noise, is less cumbersome ... and if I want better access time I use an SSD !
 
So, in order to avoid problems, I power the disk directly, that is : not threw BPI and I power the BPI through the disk power connector. Soldering is not a problem : you can use screw terminals. But you need the connectors and be sure of your polarity !
 
My experience with powering 5V boards and accessories is that you must avoid multiple connectors interfaces. Micro USB is not top, but USB-A is still worse and in fact there are very few connectors able to deliver peak power reliably on 5V. I use a PSUs with voltage adjustment capability and screw terminals and for a server, I use as little connectors as possible and I don't power accessories (USB or HDMI adapter) threw the board : only so were I able to solve stability problems.
 
In fact, I have had so many problems that from now on I will only use soldering and screw terminals !

Hmm... I fail to understand somehow. On OPiZ-3 temperature with thumb pressed on seems to decrease by 5°C from 63°C to 58°C (if it has been +60°C in reality the drop should be larger and it might hurt a bit). And on OPiZ-1 temp decreases from 44°C to 42°C while 'finger burns'?
 
This 'thumb test' is always my first try to detect whether we're looking at numbers without meaning or not (over a year ago we had a situation with A20 boards reporting temperatures even below 0°C at an ambient temperature of ~25°C and when pressing the thumb on A20 temperature further decreased below 0°C which is a clear sign that these numbers are simply way off). So do OPiZ-2 and OPiZ-3 feel any different when you press your thumb on H3 there?

Thumb test please: let 'armbianmonitor -m' run, then press your thumb for 15 seconds on H2+ and provide output from OPiZ-1 and OPiZ-3 (for both also 'armbianmonitor -u' output, at least '### cpuinfo' section!)