tkaiser

As soon as a moderator deletes here the first post I'm out. I dealt with so many morons already that are enabled to censor since they got moderator status somewhere and I can't stand it any more (people being dumb not understanding what others write and misusing their powers. It's as easy as this). If people are reluctant to accept facts simply answer every new post of them with 'Please read $subforum first and answer our initial questions in post #2'. Such threads once they're marked as [solved -- SD card issue] can be moved to the specific subforum and make for a great read enabling the next users to learn from. Also it seems you simply not understood what I proposed (not a burnin but simply CRASHING boards that are underpowered WITHIN SECONDS)

Horrible idea (censorship). Spotting those boring 'underpowering' issues is a good idea, collecting all those [solved] threads in the repective subforum should happen all the time and yeah, when such new threads are started it should be simple link to this subforum so users can educate themselves. IMO that's the whole purpose of this subforum: collecting a bunch of threads that are basically all the same so the collection allows new users to learn from others' mistakes already made.

Interesting, maybe a packaging fix is needed. No idea and won't look into further. Current situation is that most needed bits are part of Armbian repo, everyone can build/improve legacy images and wrt 'full support' we need a wiki page and some copy&paste work (using Beelink X2 mainline stuff it's mostly just that + testing which I can't since not owning the device). Desktop and CLI image as well as 'support package' with individual packages: http://kaiser-edv.de/tmp/NumpU8/ 45a44de60feb7b388ad77c456ff58917 Armbian_5.34_Sunvell-r69_Support_Package.tar.gz f3eb7ae54762e37df11a069d4193fddb Armbian_5.34_Sunvell-r69_Ubuntu_xenial_default_3.4.113_desktop.img.xz 44fdbd858437df4c1cfce81f0d92a8a6 Armbian_5.34_Sunvell-r69_Ubuntu_xenial_default_3.4.113.img.xz (No Debian yet of course since Stretch needs a newer kernel than the smelly Allwinner 3.4)

The nice thing when used this RAID variant in NAS situations on GbE equipped H3/H5 boards is that the larger the available DRAM the less you realize that IO write speeds are limited to below 40MB/s since all NAS writes end up in filesystem buffers first and will later be flushed to disk. So with an OPi Plus 2E or OPi Prime you can transfer up to 1.5GB of data at +70MB/s and only then it slows down to ~35MB/s. On the boards with less memory this can happen already after just a few hundred MB written.

Well, that was what we observed one year ago on Orange Pi Zero prior to disabling wi-fi powermanagement (it reads off in your and @t.munzer's iwconfig output). Anyway new image finished uploading: http://kaiser-edv.de/tmp/NumpU8/Armbian_5.34_Sunvell-r69_Ubuntu_xenial_default_3.4.113.img.xz In my opinion the fex file is fine now (looking at it not that much from an Armbian perspective but more having users of other projects in mind like H3Droid, RetrOrangePi, Lakka or @jernej's OpenELEC who hopefully can use the fex 1:1). For Armbian we would need mainline kernel/u-boot support contributed by volunteers.

That's Ethernet (so packets in this direction travel over the other interface -- which might have slightly improved your wifi numbers before, it's not that easy to correctly measure wifi performance when more than one interface is active and two or more interfaces are connected to the same subnet). Anyway we already know we can't expect wonders from XR819, it works somewhat ok-ish (see @t.munzer results) and anyone wanting to have decent Wi-Fi performance can always add an RTL8211AU 2x2 MIMO dongle anyway (well, that needs most probably mainline kernel support so someone has to hack together a .dts and submit upstream) Ok, then blue and visible led is connected to PA15 (and labeled wrongly red) and there's another rather invisible led connected to PL10 and wrongly labeled green. To make things worse I decided to now label the blue one green just to get almost consistent boot behaviour on all H2+/H3 boards (blue led labeled green will light up when kernel starts to load, at the time login is possible it will blink 3 times and then turn into solid mode again): https://github.com/armbian/build/commit/6981e324192dd6aad06e9ebd1a21a4c2f5c47d32 Will now create the Xenial image again (just check the timestamps at the download location). So now two contributions are IMO needed to consider switching from 'community supported' OS image to fully supported: Someone has to create a device page in linux-sunxi wiki Someone has to submit pull requests with u-boot config (576 MHz DRAM clock, 1008MHz CPU clock and MMC2 setting for eMMC) and a patch adding DT for the board (please keep in mind that 3.4 LTS kernel support ended already half a year ago)

I didn't recreate the image since I want to fix all open issues in one batch so only fixed in local Github repo copy. I fear the link has to be created somehow otherwise behaviour expected...

They're stable until the whole thingie gets instable again. Powering through Micro USB is ALWAYS WRONG and spending time on such support dramas like yours (especially again and again) is only wasting time for everyone. Seriously: @Igor and @zador.blood.stained: Why can't we add this to firstrun? Saves everyone a lot of time, efforts and trouble. Users will complain in the beginning but in half a year it gets accepted as most simple test for shitty hardware designs equipped with Micro USB for powering: 'If Armbian is available, try this out first. If it not boots then there's something wrong with powersupply' Of course we can introduce a new board config setting, eg. BOARD_DESIGNER_IS_MORON or PROBABLY_UNDERPOWERED or something like that to limit such an underpowering test only to hardware design fails like this board here, MiQi, Pine64 and the other Micro USB victims... BTW: Can a moderator please move the thread where it belonged to from post #1 on: https://forum.armbian.com/index.php?/forum/31-sd-card-and-power-supply/

Thank you for testing and yeah, stupid mistake by me naming board config sunvellr69.csc and fex file differently sunvell-r69.fex. Fixed. Still interested in the output from iperf3 -R -c 192.168.6.22 echo "heartbeat" > /sys/class/leds/green_led/trigger (iperf3 testing in reverse direction and trying out the led connected to PL10 pin (according to vendor fex, IIRC we have another device with dual color led and there it's also PL10/PA15). Currently we know there's a blue led connected to PA15 (and labeled wrongly) so would be interesting to see whether's reaction to toggling PL10 too.

I asked myself which of those top links I ever clicked on and came to the conclusion: none except 'Google site search' (Is this new? Or since when is this available? I usually never looked into the top header since it's of zero use to me). With the pinned header for me it's worse since no advantages but wasted space on screen and jumping to individual posts I end up with scrolling first since the first lines of each post aren't visible:

That's insane! Do the cables get warm or even hot under load? Better search for '22 AWG Jumper Wires' (and avoid 'buy cheap --> buy twice') or cut the ultra thin ones you use to minimal length.

What's the reason for this?

After this commit I built an Ubuntu Xenial image: http://kaiser-edv.de/tmp/NumpU8/Armbian_5.34_Sunvellr69_Ubuntu_xenial_default_3.4.113.img.xz (MD5 sum: 06e5a14865f0be6861f7e11babdd8bb3) New image: http://kaiser-edv.de/tmp/NumpU8/Armbian_5.34_Sunvell-r69_Ubuntu_xenial_default_3.4.113.img.xz (MD5 sum: 44fdbd858437df4c1cfce81f0d92a8a6) Still feedback wanted but only based on this image (none for other devices, really): Wi-Fi working / which 'performance' led functionality (there should be two leds and both accessible through sysfs as @guidol demontrated already with one of them) Stability (should be fixed already since max cpufreq limited to 1008 MHz as in vendor's Android settings) nand-sata-install still working (it's based on boot config from OPi Zero 2 Plus whatever so u-boot clocks DRAM with 408 MHz until first throttling happens then DRAM freq switches to 576 MHz)

Hmm... there should be no need to execute scripts any more if you did the modifications above. According to dmesg output it already worked at startup and still loading the xradio_wlan module twice seems to be necessary. What about a quick check with 'nmtui-connect' to see whether Wi-Fi really works? And maybe even a quick iperf3 test to confirm that data can be transmitted? That would finally confirm fex settings so anyone interested in supporting this device long-term could then start to hack a .dts for the board suitable for mainline kernel (fairly easy when starting with the DT for OPi Zero and then adding the necessary node for eMMC/mmc2 and different pin mappings for XR819. It would also be a great idea to create a device page in linux-sunxi wiki similar to the one for Beelink X2 at least documenting Wi-Fi settings and DVFS situation (no voltage regulation and 1.2V VDD_CPUX) Maybe caused by the sound drivers? Usually crashes at shutdown are related to driver hassles. You could try to remove all the snd_* entries from /etc/modules so that only the two xradio lines remain.

Of course. All data gone. Nope, it's just metadata (small checksums used to verify data integrity) but no parity data like it's used with RAID5/6 and of course you can't reconstruct data from this type of metadata. On H3/H5 boards that are limited by USB2 an interesting alternative could be a mdraid RAID10 with far layout using 2 disks (you don't need 4 for RAID10 and you should always use RAID10 if you wanted to use RAID1 on Linux in the meantime). This way you get full redundancy and protection against a drive fail while doubling at least read performance. This is an OPi Plus 2E with 2 SSDs in UAS capable JMS567 disk enclosures using a RAID10 with rather small chunk size (default ist 512K) and a btrfs on top: mdadm --create /dev/md127 --verbose --level=10 --raid-devices=2 --layout=f2 --chunk=4 /dev/sda /dev/sdc RAID-10 made of Intel 540S and Samsung PM851 with 4k chunk size: random random kB reclen write rewrite read reread read write 102400 4 7044 7549 8654 8824 7058 7011 102400 16 14815 14508 25361 25344 21222 14731 102400 128 26835 26558 46249 47619 44310 26084 102400 512 26882 29306 51175 51847 51979 28552 102400 1024 29347 29960 51424 52177 52287 29056 102400 16384 30129 30715 74614 77384 78568 29954 4096000 4 36556 35967 81080 82749 4096000 1024 36335 35705 81314 81422

So SD cards became intelligent in the meantime and know what a partition table is? No, impossible. Which tool did you use to write the image, how does F3 or H2testw test results for each card look like and what does 'armbianmonitor -u' reports (the '### mmc' section)?

No it's not since this change is already part of the adopted fex: https://github.com/armbian/build/blob/160f9ea9fbb3e71b4f155d9bcf54c7fea635b90f/config/fex/sunvell-r69.fex#L428 (it's the entry for mmc0, the others shouldn't be changed). It makes no sense to fiddle around with the Beelink fex file on this device. And then it's REALLY IMPORTANT to clear the SPL header on all SD cards where an OS image has been written to before as outlined here: https://docs.armbian.com/User-Guide_Getting-Started/#how-to-install-to-emmc-nand-sata-usb Since otherwise SD card has higher boot priority and then an SD card without bootloader will lead to a bricked device. What about helping with the remaining problems?

And for me it would be interesting whether it works now or not In the meantime I remembered a bit more (eg this). So please do echo 'blacklist dhd' >/etc/modprobe.d/dhd.conf echo -e "xradio_wlan\nsndspdif\nsunxi_sndspdif\nsunxi_spdif\nsunxi_spdma\nsunxi-cir\nxradio_wlan" >/etc/modules sed -i -e 's/Beelink X2/Sunvell R69/' -e 's/beelinkx2/sunvellr69/' /etc/armbian-release Followed by a reboot. If dmesg and iwconfig output look reasonable then please armbianmonitor -u output. Well, the new fex adopts the vendor's setting obviously taking care of a fixed VDD_CPUX voltage of 1.2V so we limit maximum cpufreq to 1008 MHz now which should result in (more) stable operation compared to allowing 1200 MHz before. If you're somewhat skilled (I'm not) you could search for testpoints on the PCB near the SoC and measure yourself whether the assumption is true or not.

I forgot to mention that of course contents of /etc/modules have to be adjusted prior to such tests (at least removing the xradio occurences there).

Hmm... let's stop. Too much waste of time. The contents of /etc/modules have to be checked (since dhd driver for Broadcom/Ampak seems to be loaded which is conflicting with xradio) and all the 'magic' needed to deal with this other TV box (Beelink X2) has to be moved out of the way (see armhwinfo for example -- different batches of X2 have different Wi-Fi modules so we had to add a few ugly hacks here and there but I fail to remember what we did exactly).

Boring. Why not using an Armbian image where 8189es is known to work (legacy)? So someone can boot this image on the device, extract contents of script.bin and upload that and output from dmesg, lsmod and iwconfig to an online pasteboard service.

Please output from modprobe xradio_wlan sleep 1 modprobe xradio_wlan armbianmonitor -u

That one worked, imported the stuff into Armbian's build system and did then the usual modifications: https://github.com/armbian/build/commits/master So hopefully when you grab latest version of the fex file there you get Wi-Fi running after loading the xradio module. Some fex contents seemed to be weird (eg. PL06 as wake-up source) but when walking through the whole contents it became obvious that PL06 is not needed and the box does not implement voltage regulation. According to fex H2+ is fed with 1.2V all the time and max cpufreq therefore limited to 1008 MHz (reasonable choice). The thermal settings are funny since starting with 80°C and allowing to go up to as much as 115"C. On the other hand the throttling settings were 'typical Allwinner' so with the default Android you boot with 4 cores active and as soon as you do anything heavy one CPU core after the other gets killed. Those settings should be more sane now. Another problem: DRAM according to the Android fex is clocked with 576 MHz while the Beelink X2 image uses AFAIK 624 MHz already in u-boot. So in case instabilities occur a better base than an Armbian image for Beelink X2 might be one of the eMMC equipped H3 boards with single bank DRAM config (since those are clocking DRAM by default with 408 MHz). That's eg. NanoPi Air or Orange Pi Zero Plus 2 H3 (what a stupid name!)

Then the base image you're using is not the one for Beelink X2 but for another board that does not feature eMMC (eg. OPi Zero). See the sprunge.us links from @t.munzer from yesterday or the day before in this thread. This is something different and with legacy kernel most probably just a fex setting (or not, too tired to get into details) Anyway, it gets boring wasting my spare time helping people who obviously tried to buy as cheap as possible (since why choosing such an unsupported TV box over a dev board where schematics and documentation are available and none of the issues here are a problem?)

Why Android? Why not booting back in Armbian and doing a 'mount /dev/mmcblk1p2 /mnt'? Interesting 'thermal performance' but both runs not suitable to test for DVFS stability since throttling is way too heavy on your box.