Heisath

You could just add some larger capacitor in parallel to the power bank. If chosen right it should surpress the voltage spike and buffer enough so it does not drop. Might even use more than one to get a better frequency response. Or put a 5.2 volt zener / tvs diode across the board to protect it from the spike. I can edit this with some wiring later if needed. EDIT: Some wiring idea: Use some resistor voltage divider on the powerbank input (eg. 10k to 10k which gives you 0.5) to get some measurement to your sbc. With the given voltages this would be: 5V in -> 5V * (10k / (10k + 10k)) = 5V * 0.5 = 2.5V . If you feed this to some GPIO you can either use some analog pin to measure it directly (and initiate shutdown if it goes to low) or you can hook it up to some digital one if you only want to know wether it is high or low. Might need to change the resistor ratio then. Do not exceed your max gpio voltage! On the Powerbank output add either D1 or D2 (zener or transient voltage surpressor diodes) rated for slightly above 5V. These will get rid of nasty voltage spikes for you. Additionally use some small capacitor (to remove high frequency ripple) and some larger one in parallel (to reduce low frequency ripple / voltage drops) to buffer over the voltage drop when powerbank is switching on / off. Cheers, count-doku

I am confused now. #armbian tells us that v20.02 has been released. Where was the release date 28.02. defined? First post in this thread still says "Release Date: 2020-02-?? (will update thread)". Is it always going to be ~1month after feature freeze? Probably. How does work continue now? Does somebody port fixes from 20.02 to master? I assume we will continue development on master so it would make sense, to get all fixes from 20.02 over to it. What happens with rc0 and rc1 ? Just stale and delete at some point? Regards, count-doku

I have no idea why dd would not work, but as a workaround you could: use Win32Diskimager to create an *.img file from your old sd card. Than use Win32DiskImager or Etcher to burn that file to the new sd card. Worked good for me.

I agree with the previous posters. Any supported / recommended board will run stable with most features working if you use good PSU (not micro-usb), sd card (or even better root on emmc or sata) and is sufficiently cooled. I'd suggest you go for boards with good mainline linux support (ie. 4.19 or 5.4) because more hardware is supported & if something breaks there are possibly more people fixing it versus boards which only have some old vendor kernel. Apart from that unfortunately it is like you said, not every feature works on every board. In my experience this is mainly due to hardware producers advertising (hardware) functions although there is no real software support for it. Or randomly changing hardware (see espressobin) which breaks existing software... I suggest thinking about stuff you really need and picking a board afterwards. (You probably don't need an "Eierlegendewollmilchsau"). Personal experience: I'm running a Router/NAS based on ClearfogPro with M.2 SSD for OS, 2x HDD for storage (with mPCIe-SATA bridge) for about 3 years now with no problems (apart from stuff which I broke be installing dev kernels and so on). So, I am sending in the Clearfog Army!

@TRS-80you did realize those are AMD processors, right? So there's probably no Intel ME in there In case you were worrying because AMD processors might contain the same, well true. Regarding the firmware for the board (which is coreboot) you can check the firmware https://github.com/pcengines/coreboot/ maybe this helps?

Please try a 19.x build. https://dl.armbian.com/orangepizeroplus2-h3/archive/ The 20.02 ones are only RC (release candidates), it is a bug / mistake that the general link points to them.

Hey, just realized if users currently go to dl.armbian.com, example: https://dl.armbian.com/clearfogpro/ and select the buster_current download directly, they get the RC releases. This is probably not wanted behaviour. Cheers, count-doku

Hi, I recently built a NAS using the APU2E4 (https://pcengines.ch/apu2e4.htm) which gives you 4 cores (I think all APU2 have 4 cores so smaller versions should work just fine), and 4GB RAM. 3 Gbit LAN, 1 SATA, 2xmPCIe (which give you up to 8 SATA), and mSATA (you could use a breakout board or some actual mSATA drive for ssd / os). It is working pretty good. Installation was a breeze, stock debian with mainline kernel works nicely. Thanks to being x64 and not some ARM all hardware worked out of the box. Performance using ext4 harddisk drives and LAN peaked at about 120MB/s write (which is the max of the drives I assume). I did not test any cluster fs. Remember that you might need to build your own cooling solution, the boards ship only with some "heatspreader" (aka alu plate) which normally transfers heat to their enclosure. Regards, count-doku

That depends on the board. But mostly u-boot sits directly on the device (before the partition) and then loads the kernel etc. from /boot. Same as on x86 grub gets also installed to mbr...

You could just use dd to backup your sd into some image automatically? Might be big depending on the size of the sd card. Or just dd it to the image once, and for automatic backups mount the image as loop, and rsync /boot. No need to backup bootloader each time

Well if you are booting from sd now, you could use dd, etcher, win32diskimager or another tool to create a full image of the sd card. Then just write that to a backup sd. Or copy /boot to new sd with rsync and write bootloader manually.

Hi Xavier, Kernel 5.5 is currently not supported by us. Our current kernel 4.19 has complete hardware support, dev kernel (5.4; which you need to compile yourself with https://github.com/armbian/build) should also have working PWM. If you need to use Kernel 5.5 you are on your own, you can try to use the patches from 5.4 (https://github.com/armbian/build) to get PWM working... Cheers, count-doku

Hey I just tested this myself, I did: git clone https://github.com/armbian/build cd build git checkout v19.08 sudo ./compile.sh EXPERT=yes LIB_TAG="v19.08" RELEASE=jessie Selected "Orange Pi PC", "Full image" and installation failed as you indicated: [ .... ] Fingerprinting [ o.k. ] Building package [ linux-jessie-root-orangepipc ] [ o.k. ] Building desktop package [ armbian-jessie-desktop_5.99_all ] [ o.k. ] Starting rootfs and image building process for [ orangepipc jessie ] [ o.k. ] Checking for local cache [ jessie-cli-armhf.fd2...6e9.tar.lz4 ] [ .... ] searching on servers [ o.k. ] ... remote not found [ Creating new rootfs cache for jessie ] [ o.k. ] Installing base system [ Stage 1/2 ] E: unrecognized or invalid option --components= [ error ] ERROR in function create_rootfs_cache [ debootstrap.sh:147 ] [ error ] Debootstrap base system first stage failed [ o.k. ] Process terminated [ o.k. ] Unmounting [ /home/user/build/.tmp/rootfs-default-orangepipc-jessie-no-no/ ] [ error ] ERROR in function unmount_on_exit [ image-helpers.sh:66 ] [ error ] debootstrap-ng was interrupted [ o.k. ] Process terminated So yes there seems to be a problem creating the root fs for jessie. We will not fix this because it is out of support. If you look inside the output folder though, you can see that the 3.4.y kernel was successfully created & packaged. So maybe you can use some more current (working) build and go back from there. You can downgrade your kernel with the debs created. And you could also change your apt.lists (in a running more recent install) and downgrade your stretch or whatever to jessie. Alternatively have a look at the buildscript and try to fix the sources yourself or get the rootfs from somewhere else. Maybe Orange Pi vendor? Kind regards, count-doku

Apart from that 3.3V levels work just fine, the board should actually be 3.3V probably only the label has been shortened.

Hi, I updated the gdoc sheet from lanefu for mvebu. Regarding the notes: Kernel 4.14 (legacy) Kernel 4.19 (current) Kernel 5.4 (dev) all work stable on mvebu (Helios & Clearfog). U-Boot 2019 is still a bit problematic on Clearfog with dev, will try to fix that until 20.05 otherwise just use U-Boot 2018 there aswell. Debian Stretch was not tested, as it is marked as unsupported on the download page ( https://www.armbian.com/clearfog/ ) . Maybe that was a typo and should have been Debian Buster @lanefu? Cheers, count-doku

Looks good, I like the definitive freeze / release dates. I will do remaining work (mostly testing recent mvebu changes on Helios4) today. Another dev: @aprayoga EDIT: Not worth the extra post, I completed testing on Helios4 and Clearfog looks good: mvebu-legacy Helios4 lk 4.14.y u-boot 2018.11-armbian http://ix.io/27Ou Clearfog (Pro) lk 4.14.y u-boot 2018.01-armbian * SFP working but only up to 1Gbps http://ix.io/27OL mvebu-current Helios4 lk 4.19.y u-boot 2019.04-armbian http://ix.io/27Ox Clearfog (Pro) lk 4.19.y u-boot 2018.01-armbian * SFP working but only up to 1Gbps http://ix.io/27OM

Hi, sometimes we change the layout / text which is shown in MOTD, example: Armbian 19.11.7 Buster ttyS0 clearfogpro login: root Password: Last login: Tue Jan 14 11:27:45 UTC 2020 from 192.168.1.11 on pts/0 ____ _ __ ____ / ___| | ___ __ _ _ __ / _| ___ __ _ | _ \ _ __ ___ | | | |/ _ \/ _` | '__| |_ / _ \ / _` | | |_) | '__/ _ \ | |___| | __/ (_| | | | _| (_) | (_| | | __/| | | (_) | \____|_|\___|\__,_|_| |_| \___/ \__, | |_| |_| \___/ |___/ Welcome to Armbian buster with Linux 4.19.95-mvebu System load: 1.96 0.71 0.25 Up time: 1 min Memory usage: 8 % of 1001MB IP: 192.168.1.39 CPU temp: 37°C Usage of /: 12% of 29G root@clearfogpro:~# cat /etc/armbian armbian-image-release armbian-release armbianmonitor/ armbian.txt root@clearfogpro:~# cat /etc/armbian-release # PLEASE DO NOT EDIT THIS FILE BOARD=clearfogpro BOARD_NAME="Clearfog Pro" BOARDFAMILY=mvebu BUILD_REPOSITORY_URL=https://github.com/armbian/build BUILD_REPOSITORY_COMMIT=ae1737ee DISTRIBUTION_CODENAME=buster DISTRIBUTION_STATUS=supported VERSION=19.11.8 LINUXFAMILY=mvebu BRANCH=current ARCH=arm IMAGE_TYPE=user-built BOARD_TYPE=conf INITRD_ARCH=arm KERNEL_IMAGE_TYPE=Image root@clearfogpro:~# vs. login as: root root@cfp-router.clearfog.home's password: ____ _ __ ____ / ___| | ___ __ _ _ __ / _| ___ __ _ | _ \ _ __ ___ | | | |/ _ \/ _` | '__| |_ / _ \ / _` | | |_) | '__/ _ \ | |___| | __/ (_| | | | _| (_) | (_| | | __/| | | (_) | \____|_|\___|\__,_|_| |_| \___/ \__, | |_| |_| \___/ |___/ Welcome to Debian Buster with Armbian Linux 4.19.95-mvebu System load: 0.06 0.12 0.09 Up time: 22:41 hours Memory usage: 34 % of 1002MB Zram usage: 6 % of 501Mb IP: 1 92.168.1.3 CPU temp: 50°C Ambient temp: 25°C Usage of /: 7% of 459G [ General system configuration (beta): armbian-config ] Last login: Wed Jan 15 14:02:07 2020 from 192.168.1.11 root@cfp-router:~# cat /etc/armbian-release # PLEASE DO NOT EDIT THIS FILE BOARD=clearfogpro BOARD_NAME="Clearfog Pro" BOARDFAMILY=mvebu BUILD_REPOSITORY_URL=https://github.com/armbian/build BUILD_REPOSITORY_COMMIT=e261c6f8 VERSION=5.91 LINUXFAMILY=mvebu BRANCH=default ARCH=arm IMAGE_TYPE=stable BOARD_TYPE=conf INITRD_ARCH=arm KERNEL_IMAGE_TYPE=zImage root@cfp-router:~# If you compare the welcome messages you will see, that there are some tiny differences. Both install run the same kernel (updated to that with self-built debs). Additionally the armbian-release does not seem to update. I assume this is normal behaviour, because when updating the system via apt-upgrade (or dpkg with new debs) the rootfs does not get updated. Is there a way to fix/update this? Or just copy the files from a generated full img? Regards, count-doku

Honestly? I would not. The frequency with which issues about Espressobin pop up here is worse than for other NAS boards. Just skip through a thread like: I would not say Espressobin is not working, but your saying: And I am not sure you will have that experience with Espressobin. --- If you are just looking for a simple NAS board, maybe have a look at a Helios4 (if you can get them still somewhere) or Helios64 (just released). Or check out Clearfogbase (which has no SATA put pcie) or the PCEngines APU2 series: https://pcengines.ch/apu2.htm (these are x64 boards which run a mainline debian, no ARM although their power consumption is equally low). This is not meant to keep you from getting an Espressobin, but to point out possible alternatives, so you can compare them. Regards, count-doku

I think the problem is, for WOL (Wake on LAN) the devices needs to be networking, so if it is completely halted that does not work -> no WOL. You are probably looking for something to "Boot on Lan". You could try to design that on your own, just get another device (which is energy efficient like ESP32 or so) to monitor for WOL request and use it to "push" the physical button on the Helios (via transistor or relay). This way you can halt the Helios completely (maybe even use a relay to disconnect the power) and reboot it from extern.

Yes it is the latest (current) version. Work is still underway for kernel 5.4.y... (You can build an image yourself if you want to try it)

Hi, these PIN Names are possibly considered "general knowledge" once you worked with some microprocessors or similiar. Most are just abbreviations. And the different functions on a pin. I'll try to explain some of them based on the linked OrangePi Extension header table (from their wiki): 3.3V -> obviously 3.3V output TWI0_SDA / PA12 / GPIO12: TWI0_SDA -> Two Wire Interface also known as I²C | SDA -> Serial Data PA12 -> Pin from internal pin register a, number 12 GPIO -> General Purpose Input/Output Pin Number 12 the last two are essentially the same with the first one based on the internal registers and the other one just numerated over all pins. TWI0_SCK / PA11 / GPIO11: TWI0_SCK -> Two Wire Interface (i2c) | SCK -> Serial Clock GND -> ground, minus, (-), return or whatever you're gonna call it. UART2_RX -> Universial Asynchronous Receiver and Transmitter 2 -> also known as Serial Port (RS232 like) | RX -> Receiving or Receiver. This pin is read by software. UART2_TX -> see above, TX -> Transmitter. This pin gets set by software (and sends the data) UART2_CTS -> see above, CTS -> Clear to Send. Used for flow control, to tell the partner you are ready to receive. (or they are cleared to send) (Googling for UART, USART or RS232 will probably give good explanations on this) SPI1_MOSI: SPI -> Serial Peripheral Interface -> Another kind of serial port. -> google. MOSI -> Master Out / Slave In -> this is the transmitting port for a master perspective SPI1_MISO -> Master In / Slave Out -> receiving port SPI1_CLK -> the clock signal. Just search for spi for more info. SIM_CLK / PA_EINT7: SIM_CLK -> can probably attach a SIM Card here (then this will be the clock line). I don't know stuff about sim cards though. PA_EINT7 -> Internal Port Register A, External Interrupt 7. Read about Hardware Interrupts for microprocessors for more info. Essentially a software component can be instantly triggered on some predefined signal on this pin. The rest has the same prefixes, so you can probably deduce the meaning by using the internet. If something remains unclear, just ask. Kind regards, count-doku

Looks good! Congrats to the Kobol team for designing another interesting NAS board. Is the 12V 10A power supply neccessary though? I mean thats 120W, with that much power one can easily run a real x86... How much does the board itself consume?

Is there maybe a problem with the driver which occurs because you connect all 3 network adapters with each other (via the switch)? only logical conclusion for me, because you said connecting to all 3 with different devices works. Maybe some layer 2/3 routing problem?

Hi, I bought this relatively new WiFi card from sinovoip based on the MT7615. http://forum.banana-pi.org/t/bpi-mt7615-802-11-ac-wifi-4x4-dual-band-pcie-module-mass-production-version/10037 The kernel drivers for this are already in mainline linux (starting from 5.3 I think). I'm trying to use it on the clearfogpro though, which only runs up to kernel 4.19 right now (tried compiling 5.3 but it fails). So I wanted to backport the driver to 4.19. Unfortunately multiple things changed and trying to get the driver to compile broke lots of other stuff. So I came around to backports https://backports.wiki.kernel.org/index.php/Main_Page their documentation isn't really great for starters so I am unsure how to use this with Armbian. Has anyone used backports with armbian build system and might give me some pointers? Or is there a better way to get the driver working? Or has it even been done somewhere and I just don't find it? Greetings, count-doku

Hey there are multiple things you need to check. Are you using Clearfog Pro or Base? In the title you write Pro but from the Logs it looks like you are using a Base image. This might cause problems. Apart from that check the position of the mPCIe card vs. the kernel and uboot you are using. Use this table as a guide: https://docs.google.com/spreadsheets/d/1VggzrfFibH0cmpSGW2FyoJW-d936Y2amwwKutUwX4-8/edit#gid=0 Greetings, count-doku