tkaiser

'Linux 3.4.113-sun8i (RetrOrangePi)' -- no idea what RetrOrangePi folks do to Armbian images

What about doing exactly this? 'armbianmonitor -U' (capital U) and then posting/pasting this stuff to e.g. https://pastebin.com?

Etcher has been developed to be platform independent (so not only Windows users can benefit from it but also users of other common operating systems). No one right in his mind will code the CLI variant in a different way than the UI application. Both UI and CLI variant therefore rely on the same code base and libs/modules: https://github.com/resin-io-modules And as a logical result even the CLI tool becomes somewhat bloated since that's the price you pay when using Electron apps. On the bright side: Etcher folks are aware of the problem and at least more recent versions are not that fat as older ones: bash-3.2# find /opt -name etcher | while read ; do du -sh "${REPLY}"; done 74M /opt/etcher-cli-v131/etcher 64M /opt/etcher-cli-v141/etcher 63M /opt/etcher-cli-v143/etcher Why do you ask these questions instead of giving some answers for people not using Windows? Do all Win32DiskImager installations on this planet got already (auto)updated to this 1.0 version or do users have to manually download the new version and replace the binary? Does verify happen automatically or is this an additional step that has to be chosen manually after burning?

You just need to understand where the bootloader on ARM boards lives and how to transfer this to an image or another SD card. Usually all this stuff lives inside the 1st MB of the SD card so cloning the first MB with dd the first time should just work. But if then later u-boot updates are provided via our Armbian repo you won't get updates on your backup image. Most probably the best idea is to merge the functionality present in our nand-sata-install tool with your backup script (since nand-sata-install has to take care about writing this bootloader stuff you can study there how it works -- it's the /usr/lib/u-boot/platform_install.sh include)

Yes, please. And if you're at it deleting all three posts from 2nd page since off-topic (we really should focus on stuff that's important)

This is 100% irrelevant just like some people reporting they never had trouble with Win32DiskImager or dd! It's about the average user and expectations. And the average user runs Windows for whatever reasons and has no clue about Windows being crippled by design when it's about handling removable media and 'foreign' filesystems. And the average user also has the naive assumption that burning to SD cards always works, that crappy/counterfeit SD cards do not exist and that 'transmission problems' caused by card readers or USB ports also do not exist. That's why it's so important to ONLY RECOMMEND ETCHER all the time.

Sure, works like a charm (though they introduced a bug on macOS with 1.4.x version which seems easy to fix): bash-3.2# /opt/etcher-cli-v131/etcher -y -d /dev/disk3 /Users/tk/OMV_4_Renegade.img Flashing [== ] 6% eta 5m46s And then bash-3.2# /opt/etcher-cli-v131/etcher -y -d /dev/disk3 /Users/tk/OMV_4_Renegade.img Flashing [========================] 100% eta 0s Validating [== ] 6% eta 2m11s You would check the exit code when running unattended: Exit codes: 0 - Success 1 - General Error 2 - Validation Error 3 - Cancelled They get tons of stupid 'bug reports' but always try to be polite and support the submitters and other participants even it's just coaching clueless Windows users who think Etcher has destroyed their SD card just due to their stupid Windows installations not able to deal with anything else than Microsoft developed filesystems (they burn Raspbian and complain later that their 16 GB card shrinked to 128 MB since Raspberry Pis need this small FAT partition to load the primary OS called ThreadX from it and Explorer and other Windows tools only display the FAT partition since not able to cope with ext4 or more than the first partition on removable media anyway)

Feelings and beliefs? Seriously? A burning tool's job is to flash an image without any modifications to an SD card or eMMC. As not only I outlined there exist a couple of reasons why this can fail. It's not just related to crappy SD cards or crappy card readers/writers but as I explained above even the USB port you plug the thing into can make a difference (for example USB front ports suffering from interference problems when cables between mainboard and ports are not properly shielded). A basic IT fundamental is to not stupidly trust into data traveling from source to destination unaltered. Almost every protocol we use nowadays implements on the fly checking for data integrity. For the simple reason that trusting into sending data from A to B and assuming that everything is fine at the destination is PLAIN STUPID. For example when transfering data between an SDIO, SATA or SAS host controller and flash/disk controller Cyclic Redundancy Check (CRC) is used to immediately verify data integrity and if data has been altered on its way the destination asks for a retransmit. Same is implemented in networking protocols (see TCP/IP) and almost everywhere else a verify happens on the fly. Since it's PLAIN STUPID to believe data corruption wouldn't occur. It occurs all the time and that's why engineers put CRC or stronger data integrity verify mechanisms into almost every protocol used today. Unfortunately sometimes the CRC mechanism is rather weak (so that data corruption when happenend generates a correct CRC and as such gets undetected) and unfortunately it's not implemented everywhere. Especially when it's about cheap consumer crap (SD cards and USB card readers) we can't trust into the results. So what do we need when we can't get 'on the fly' verify when burning SD cards? We need verify as an additional step. Why? Since it's PLAIN STUPID to trust into data integrity especially with such a mess like cheap card readers/writers and cheap and/or fake SD cards. The only reason Etcher has been developed in the first place was due to this: an insame amount of undetected data corruption when burning SD cards or thumb drives due to shitty tools that do not verify (Etcher has been developed by resin.io folks who make their money with helping their customers rolling out and updating software on fleets of IoT devices. Their main problem years ago was unsatisfied customers since they failed to burn the resin.io software to SD cards. Since all available tools were crap due to skipping the necessary verify step which is PLAIN STUPID. Etcher changed this!) For anyone recommending anything else than Etcher: Thank you a lot! You ensure that developers like us here at Armbian can not focus on improving Armbian but have to deal with 'bug reports' due to people failing to burn SD cards. Instead of spending time on development we have to waste our time on 'bugs' that aren't bugs but just the result of users been encouraged to use crappy tools. Thank you for wasting our and our users' time! Well done!

Can you imagine sending a PR defining a new sun50i-h5-orangepi-zero-plus2-v1.1.dts so that we can add to the board's documentation that users of the v1.1 rev should simply add fdtfile=sun50i-h5-orangepi-zero-plus2-v1.1.dtb to /boot/armbianEnv.txt, adjust /etc/default/cpufrequtils, reboot and are done?

Why? These things are complex, they have an SDIO interface to access the flash media and an USB controller to present the storage as mass storage device. And of course there's a controller running a software that can be buggy. So why shouldn't be there firmware updates? Since I fear a lot of people still do not get that every burning tool that does not verify burning results is CRAP I just did an experiment. We recently replaced a bunch of crappy Intenso TF cards with SanDisk Ultra A1 at a customer so now I have something crappy to play with. Also involved: a crappy USB SD card reader/writer: I put the TF card into the SD card adapter, then the adapter into the USB reader and attach the reader to an USB3 port of my laptop. Try to burn an Armbian image and Etcher reports an error already while burning. This is repeatable with 4 of those crappy 4 GB TF cards (I stopped then testing). Is Etcher the problem? Of course NOT! Trying it also with ddrescue and same situation: ddrescue also already reports an error while burning: bash-3.2# ddrescue --force /Users/tk/OMV_4_Renegade.img /dev/rdisk2 GNU ddrescue 1.20 Press Ctrl-C to interrupt rescued: 434765 kB, errsize: 0 B, current rate: 2228 kB/s ipos: 434765 kB, errors: 0, average rate: 10351 kB/s opos: 434765 kB, run time: 42s, remaining time: 5m time since last successful read: 0s Copying non-tried blocks... Pass 1 (forwards) ddrescue: Write error: Input/output error So do I have 4 failing SD cards? NOPE! Since when I use my laptop's internal SD card reader (also USB attached BTW) it works with all 4 crappy TF cards: Etcher happily reports that burning now succeeded successfully and the same with ddrescue: bash-3.2# ddrescue --force /Users/tk/OMV_4_Renegade.img /dev/rdisk2 GNU ddrescue 1.20 Press Ctrl-C to interrupt rescued: 3904 MB, errsize: 0 B, current rate: 8192 kB/s ipos: 3904 MB, errors: 0, average rate: 10357 kB/s opos: 3904 MB, run time: 6m 17s, remaining time: n/a time since last successful read: 0s Finished The above external USB card reader/writer does not fail with good SD cards (Samsung EVO/EVO+ or SanDisk Ultra/Extreme/Plus A1) so for whatever reasons it's the combination of crappy SD card and crappy reader. What can we learn from this? Stop using and recommending crappy burning tools that do NOT VERIFY. Win32DiskImager most probably would've written simply garbage with the above combination since it doesn't implement VERIFY (only latest 1.0 version implements an optional AKA useless verify step). And then the user is in trouble since usually minor corruption issues look like software faults later on (that are considered 'Armbian bugs' then, reported as such and wasting our developer time and the user's time too) I ran into this issue 2 years ago with the internal SD card reader/writer of my build PC back then. Images written with dd becoming slightly corrupted over time which resulted in weird software failures and kernel panics. I wasted a day to get the clue that it's related to the card reader being the culprit. I then used the external USB reader/writer shown above which also started to corrupt images weeks later. But only when attached to the USB front ports. When attaching the same reader to the back ports of the PC everything went fine. So it was obviously a simple cabling issue between mainboard and the front USB ports/devices (the internal card reader at the front is also USB attached). Seriously: VERIFY is important. Please don't be stupid and skip this step. Don't be even more stupid and use tools that do not allow to verify burning results.

That's irrelevant. They're all running ThreadX (that's bootcode.bin and the start*.elf stuff that has to reside on the 1st partition of the SD card that has to be FAT formatted since otherwise the VC4's primary bootloader can't load ThreadX). Raspberry Pis are no ARM SBC but VideoCore IV SBC (with badly integrated ARM cores that run a secondary OS, most of the times Linux). The raspbx-backup script doesn't work with any SBC Armbian supports since it's designed for VideoCore SBC (that need a FAT partition with the closed source ThreadX on it). ARM SoCs work differently than VideoCore SoCs: here u-boot/SPL are written to the beginning of the SD card somewhere. It's not on a filesystem and therefore can't be copied with rsync that acts above the filesystem layer. You can study how it's done per board family by checking the write_uboot_platform and uboot_custom_postprocess functions here: https://github.com/armbian/build/tree/master/config/sources (Le Potato is meson64) TL;DR: ARM SBC are not VideoCore SBC and therefore tools that are designed to work with VC4 won't work on ARM SBC.

Great. Etcher reported something went wrong when burning (already checked your card and card reader?) and the result was as expected: What's wrong with this?

Does this tool always verify burning results? Does this tool always verify burning results? Does this tool always verify burning results?

Tested also with Rock64 (slightly slower memory). We get there 3.63 kH/s with our old setting limiting Rock64 to 1.3 GHz. After lastest commit at 1.4 GHz Rock64 scores 3.88 kH/s as expected (little bit slower compared to Renegade due to different DRAM)

SanDisk Extreme A1 32GB

Or it's just an RK3328 limit? Tested again with Rock64 (but an early developer sample) and got 835 Mbits/sec in TX direction: https://pastebin.com/raw/cwqag6e8

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.

The Armada 1500 family consists of totally different SoCs, the '1500 Mini Plus' is pretty uninteresting, the whole business unit is now part of Synaptics who locked everything away and this is the status of upstream support: https://github.com/torvalds/linux/tree/master/arch/arm/mach-berlin Good luck.

Me not since I hate censorship (freezing/manipulating threads). BPi M3 is not listed here https://www.armbian.com/download/?tx_maker=sinovoip so far and if it remains like this I'm fine with it. We all know that SinoVoip has a great history of false advertising (and misleading announcements) so I would prefer if Igor replaces in such 'announcements' like this all details with a simple link to this forum. So users thinking about buying this board have a way to inform themselves without any censorship involved (the 'sinovoip team bpi' monkey over in their forum reportedly censored over and over again) Wrt 'equivalent SBCs' IMO there exists no such thing. It's always about use cases and that's what potential buyers have to think about first. But as far as I noticed the average BPi M3 buyer got fooled by the impression he gets 'native SATA' on the M3 just like on the older Bananas and that people think '8 cores' make up for great computing power (which is BS especially on a board with a broken thermal design and no way to attach a suitable heatsink).

Sure, 'the Allwinner syndrome'. Once the SoC is EOL and can not be purchased any more the brave souls over at linux-sunxi finished mainline kernel support. Situation 3-4 years ago was different but today I really have no clue why to waste a single second on anything Allwinner that is not also cheap as hell (talking about the small OPi and NanoPi boards) or makes good use of Allwinner's battery support (PineBook, Olimex' Teres, Olimex Lime/Lime2 boards that use the battery to provide full 'UPS functionality' since also powering USB and SATA devices via step up converters) Banana Pi M3 with its outdated 32-bit Cortex-A7 little cores and the totally unsupported PowerVR GPU is even more expensive than faster little.LITTLE designs like NanoPi Fire3 or even true big.LITTLE designs like ODROID XU4/HC1/HC2 (the latter also with an USB-to-SATA bridge but USB3 based and more than 25 times faster than the crappy GL830 on the M3).

Huh? The A80 predecessor was big.LITTLE but this here is just little.LITTLE (just like with Vim2 or NanoPi M3 or NanoPi Fire3) and all these other boards combining two clusters made of slow CPU cores have pretty decent kernel support. Or are you talking about uninteresting EOLed Allwinner SoCs only? I already though about a detection for those poor little.LITTLE designs since 'armbianmonitor -m' output is highly misleading sometimes showing different clockspeeds for the two clusters that clock in reality always identical.

There is no SATA on this board. It's important to not spread wrong rumours. Banana Pi M3 just like Orange Pi Plus simply uses the most crappy USB2-to-SATA bridge on earth: Slow as hell: https://www.cnx-software.com/2017/03/16/suptronics-x800-2-5-sata-drive-expansion-board-and-cases-for-raspberry-pi-23-and-odroid-c2-boards/#comment-540228 Broken: https://www.cnx-software.com/2017/03/16/suptronics-x800-2-5-sata-drive-expansion-board-and-cases-for-raspberry-pi-23-and-odroid-c2-boards/#comment-540247 What's the purpose of providing an Armbian image for this board? Encouraging users to buy it since 'Armbian support is there'? Why not better spending the time on fixing the forum (broken on iOS at least, a huge fixed Armbian logo on top of each thread prevents reading thread titles and top post) Are you aware that SinoVoip produced a new M3 batch now using an incompatible eMMC, needing some fancy instructions to get their own images working?

The latter. That's the main difference between @ayufan's attempt and mine. And no, haven't had a look at the patch failures and am currently away from any build host... or to be more precise from the SSD carrying the VM and all the cached stuff:

If @jscax is using a default/legacy image it's pretty easy to lower DRAM clockspeed with 'h3consumption -D'. And yes, undervoltage might be the culprit (the Micro USB nightmare).

If a board crashed or freezes nothing will be written to syslog so searching for the strings that appeared in the logfile long before the crash/freeze happened is pretty much useless. We provide diagnosis tools, check the output of 'armbianmonitor -m' yourself (maybe post a few lines after an hour of operation) and please post the output from 'armbianmonitor -u' (since without no one has a clue which branch and kernel you're running and so on). @Igor: Is this patch not applied any more? https://github.com/armbian/build/blob/master/patch/u-boot/u-boot-sunxi/adjust-default-dram-clockspeeds.patch#L244