tkaiser

Since I had Pinebook today in my hands again after a long time I wonder what's missing to move it from WiP to supported section? We should collect/include @James Kingdon's patches of course to get everything working with Pine's new eMMC modules Then I had to realize that profile-sync-daemon isn't enabled so this needs a fix too And then I wonder whether we shouldn't install zram-config by default? And do you think it would be a good idea to ask Pinebook users after account creation whether they've 11" or 14" (to adjust /etc/X11/xorg.conf.d/50-pine64-pinebook-touchpad.conf) or could this be stuff for armbian-config?

Well, then manfid 0x45 would fit (SANDISK_SEM) though 'date: 07/2001' just looks wrong. Would be interesting to query this module about 'Device Health' (search for mmc-utils here for example).

This does not look like FORESEE eMMC (different oemid/manfid). Do you know what's written on the module?

To ease testing there's now http://kaiser-edv.de/tmp/NumpU5/Armbian_5.32_Pinebook-a64_Ubuntu_xenial_default_3.10.107_desktop.img.xz with patch applied. Works on a 16GB eMMC: http://sprunge.us/bSOE (seems we could try to stop pulseaudio in nand-sata-install but at least my short tries were all unsuccessful and I've to admit that I don't understand how this pulseaudio stuff works at all)

And the question is: BroadPwn fixed or not? Are you able to play with the files from http://kaiser-edv.de/tmp/NumpU4/brcmfmac43430-sdio-broadpwn-fix.tar with your AP6212 rev0 and report back?

I threw the following patch in and rebuilt u-boot: http://kaiser-edv.de/tmp/NumpU5/linux-u-boot-pinebook-a64_5.32_arm64.deb -- at least on my Pinebook with 16 GB eMMC everything ok after 'dpkg -i linux-u-boot-pinebook-a64_5.32_arm64.deb && reboot'. @James Kingdon are you able to test this too? diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index d160bd5..c9f0b9e 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -2272,7 +2272,7 @@ static int mmc_complete_init(struct mmc *mmc) err = sunxi_switch_to_best_bus(mmc); if (err) { MMCINFO("switch to best speed mode fail\n"); - return err; + /* return err; */ } init_part(&mmc->block_dev); /* it will send cmd17 */

Let me test this later with the 16GB eMMC on my Pinebook -- if it's sufficient we might provide a small u-boot package to fix this. Related: the 'performance' numbers you provided for your 64 GB eMMC are better at small block sizes than the 16 GB eMMC I tested but seem to be limited to the 'usual' 23 MB/s sequential barrier we see with SD cards on Pinebook and other Allwinner devices (due to using the slowest SDIO mode there). Can you please provide output from 'armbianmonitor -u' now and also re-test the 64 GB module after switching to performance cpufreq governor ('cpufreq-set -g performance' )?

Yes. And I sent you to two lines of the customize-image.sh example (for a reason). Anyway...

By looking at the huge example provided?

Since I assume you're running mainline kernel (since posting here) this should be fixed (each device getting a unique MAC address on 'firstrun') from now on with new installations: https://github.com/armbian/build/commit/537efa4241eb65df6928dfeea7f81f760ec5a4fb

But now you have /var/log/nand-sata-install.log on your SD card so it would be great if you can provide 'armbianmonitor -u' output.

Yes, that's due to mount -o compress-force=zlib $2 ${TempDir}/rootfs || mount $2 ${TempDir}/rootfs

At least as long as the interface is not controlled by NM it works (tested 20 days ago when I benchmarked my first Armbian build on ROCK64). So we might add a NM hook too but since their way of doing things isn't that persistent a systemd service might be the better idea... What about this in the meantime? diff --git a/packages/bsp/common/etc/init.d/armhwinfo b/packages/bsp/common/etc/init.d/armhwinfo index 96345fa..1900085 100755 --- a/packages/bsp/common/etc/init.d/armhwinfo +++ b/packages/bsp/common/etc/init.d/armhwinfo @@ -253,6 +253,8 @@ prepare_board() { echo 7 >/sys/class/net/eth0/queues/rx-0/rps_cpus echo 32768 >/proc/sys/net/core/rps_sock_flow_entries echo 32768 >/sys/class/net/eth0/queues/rx-0/rps_flow_cnt + # preliminary rx/tx offloading workaround + /sbin/ethtool -K eth0 rx off tx off ;; nanopim3) # dw-mci on cpu1, USB host on cpu2, GbE on cpu3, USB OTG on cpu4, video-codec on cpu5 for i in $(awk -F':' '/dw-mci/{print $1}' </proc/interrupts | sed 's/\ //g'); do

Hmm... and what about simply re-using what's known to work: https://github.com/ayufan-rock64/linux-build/blob/master/package/root/etc/network/if-up.d/rock64-offload?

Yes, ayufan said he had problems with Ethernet -- we talked today in #ROCK64 channel and I tested with 1GB production board (and offloading active): https://pastebin.com/aAzkEYEB (somewhat low performance in one direction but IMO not critical) and then next batch of boards got DRAM 'downgraded' which seems to cause problems for him. Anyway: I tested with production board and without tx/rx offloading fix/workaround Ethernet stopped to work after ~30 seconds as it's the case with the pre-production boards too.

AFAIK not. Please see here for a workaround and progress: https://github.com/armbian/build/commit/d5c6bf69db29fd8cd0b929aa15d7fc056cb02441#commitcomment-23724640

I'm struggling with XU4/HC1 and the try to have the rootfs on a connected USB disk. All attempts end up with: Gave up waiting for root file system device. Common problems: - Boot args (cat /proc/cmdline) - Check rootdelay= (did the system wait long enough?) - Missing modules (cat /proc/modules; ls /dev) ALERT! /dev/sda1 does not exist. Dropping to a shell! Rebooting automatically due to panic= boot argument I tried USB disks on USB3 and USB2 ports, according to leds and spin-up sound the SSDs/HDDs get power but device doesn't show up. I remember vaguely that we had such issues on other platforms where it was just a small missing bit in kernel config. But I don't get it even after spending an hour on searching around. 2 times boot log with high verbosity, maybe someone else has a clue: https://pastebin.com/ffnQK2Pm

The forum software tells me 'Max total size 12.46MB' which is not even sufficient to cover topics like OMV (my dir sharing OMV related pictures has already 15MB in size). But at least copy&paste now works again! Thanks @Igor -- now if BBcode would also work the forum software would become usable again...

I didn't touch themes or anything else. All I want is a simple and reliable way to post/format contents without being nagged by an interactive forum software. Is there really no possibility to use SIMPLE and RELIABLE ways to enter contents? The usual img, code, spoiler tags that work everywhere else? In the meantime I am not able to even paste text without formatting being applied! Paste, wait for the interactive nag screen appearing asking for 'Paste as plain text instead', clicking there around ... so annoying... Posting tutorial like stuff has become a real PITA here

The nand-sata-install script on all installations out there got broken in the meantime after switching to UUIDs to identify filesystems. 'SD uuid' should be a single line but is two lines (check your log above) and therefore /etc/fstab has been created wrongly. A line with the correct UUID and no more entries followed by a line with the wrong UUID followed by the / parameters. Can't work. Please try replacing /usr/sbin/nand-sata-install with latest version on Github: https://raw.githubusercontent.com/armbian/build/master/packages/bsp/common/usr/sbin/nand-sata-install and report back.

Nope, this shit https://forum.armbian.com/index.php?/topic/5098-mini-review-rock64-sata-cable/&tab=comments#comment-38798 happens way too often. An insanely shitty software called invision sitting in my browser and destroying things I want to share). That's it. As soon as the Armbian forum can be accessed without this interactive CRAP (using BBcode or $whatever sane option) I'm back. And no, I don't want to consult their sales clerks!

---

The above thing is a $10 accessory that can be ordered together with ROCK64 (and maybe other Pine Inc. devices like Pine64 or Pinebook?). It's an USB-to-SATA bridge (JMicron JMS578 based) to be used together with 2.5" SSD/HDD or 3.5" HDD. For the latter purpose it's equipped with a separate power jack suitable for the usual 12V 5.5/2.1mm power barrels (centre positive) you find PSUs with literally everywhere. TL;DR: If you want to add storage to your ROCK64 order this cable too. It works great with both 2.5" and 3.5" disks and it's somewhat sad it's not available separately since it's a great storage companion for many other devices too. Basics first: Mechanical quality of USB jack is excellent, Pine folks took care that the jack fits really tightly in USB receptacles so USB3 contact issues should not be an issue here (tested on ODROID-XU4 which is my worst device in this regard. The Pine adapter worked great and these pretty nice XU4 USB3 storage performance numbers were produced with Pine's adapter) The device is not really black but it's just a very dark but translucent plastic. If it's connected to an USB port and thereby powered a solid blue led is shining through. Disk activity is shown with a blinking red led in parallel. If you hate blinking leds like me turning the device 180° over is sufficient JMS578 as USB-to-SATA bridge is an excellent choice since amazingly fast, 'USB Attached SCSI' capable, same with 'SCSI / ATA translation' and even TRIM (though software support for this still missing in Linux) When combined with 2.5" disks the whole power consumption happens through the USB cable. Keep in mind that USB2 ports are rated for 500mA and USB3 ports for 900mA max. ROCK64 AFAIK allows 650mA on the USB2 ports and 950 mA on the USB3 ports. In other words: chances are great to run in underpowering problems when you connect 2.5" disks to the USB2 ports and run heavy loads on it (see below). 3.5" HDDs need not only 5V but also 12V. Usually the motor spinning the platters is on the 12V rail while internal electronics and the stepper motors to move around the head(s) are on the 5V rail. Please always keep in mind that Pine's SATA cable unlike any 'real' 3.5" HDD disk enclosure uses the separately provided 12V only to feed pins 13-15 on the SATA power connector. 5V consumption for the JMS578 and the disk's 5V rail has still to be provided by the device the SATA cable is connected to since coming from the USB power lines. On 'real' disk enclosures the 12V are internally also used to generate the 5V so an external disk is NOT powered in any way by the connected host. With this cable it's different! Below is the standard SATA power connector pinout. 3.3V are usually not used, 12V are needed for 3.5" HDDs and 5V are always required. The JMS578 bridge chip needs some 5V juice too which is also taken from the connected host/board via USB power lines. We already have a lot of performance numbers with fast SSDs connected to JMS578 (see https://forum.armbian.com/index.php?/topic/1925-some-storage-benchmarks-on-sbcs/&do=findComment&comment=34192 or there for example) so let's focus on real-world use cases this time: A large 3.5" HDD connected to a ROCK64 serving as a NAS or backup disk. Let's start with some consumption numbers with an idle ROCK64. In the meantime I've 3 different ROCK64 generations on my desk (1st dev sample with 2GB and unusable USB3, 2nd gen dev sample with 4 GB and now a production board with 1 GB DRAM and a different Gigabit Ethernet PHY). Measurements done without PSU taken into account: Pre-production board, 4GB, RTL8211E PHY: Idle, Fast Ethernet active, nothing connected: 1100mW Idle, GbE active, nothing connected: 1430mW Production board, 1GB, RTL8211F PHY: Idle, Fast Ethernet active, nothing connected: 1180mW Idle, GbE active, nothing connected: 1300mW Idle, GbE active, JMS578 connected: 1720mW Idle, GbE active, JMS578 with sleeping disk: 2850mW With RTL8211E PHY the difference between GbE and Fast Ethernet was 330mW (on most GbE boards with 8211E it's exactly like this: ~350mW) and now with RTL8211F the difference is just 120mW (difference on ODROID-C2 which also uses 8211F is 230mW). When adding the JMS578 cable w/o connected disk consumption increases by 400mW. In this (rather useless) mode the JMS578 hides itself on the USB bus (lsusb output shows nothing -- interestingly on ODROID HC1 which also relies on JMS578 this is different) and obviously JMS578's USB and SATA PHYs are powered off. As soon as a disk is connected but sent to sleep JMS578 now consumes +1.5W and appears on the USB bus (now JMS578 has to power 2 highspeed PHYs: USB3 and SATA 3.0). So with production ROCK64 boards minimal idle consumption is 1.2W (PSU's own consumption excluded). But as soon as we connect this cable with a disk behind idle consumption more than doubles (+1550mW) even if we send the disk to sleep. That's bad news for use cases that require a connected disk only running from time to time since now the JMS578 consumes more energy than the board itself. Edit: I discovered recently that the HDD I was testing with has a rather high standby/sleep consumption so the +1550mW are not JMS578 alone but maybe even largely the Seagate Barracuda. See here for details but keep in mind that while on ODROID HC2 also a JMS578 is used it runs a different firmware which influences idle consumption behaviour a lot. More details on JMS578 firmwares: https://forum.armbian.com/topic/3317-orange-pi-zero-nas-expansion-board-with-sata-msata/?do=findComment&comment=43735 What are the options? With ROCK64 production boards we're fortunately able to toggle power provided to USB ports: https://forum.pine64.org/showthread.php?tid=5001 So the SATA cable connected to an USB2 port would allow to regain lowest idle consumption since we could unmount the disk when not needed, then send the disk to sleep using 'hdparm -y' (JMS578 fully supports 'SCSI / ATA translation so you can access every disk feature with hdparm or other low level tools!) and finally switch JMS578 off by cutting power on the USB2 port. My personal use case is a ROCK64 with a huge 3.5" HDD to backup various macOS devices in the household. Backup performance is close to irrelevant and the only events needing top 'NAS performance' would be large restores or 'desaster recovery'. In other words: for normal backup operation once a day it would be sufficient to connect the disk to an USB2 port. Nope, doesn't work any more, see below for details. How does performance look like with a 7.2k 3.5" HDD (Seagate Barracuda from a few years ago): The Barracuda is totally empty so able to achieve nice maximum sequential performance scores since testing only on the outer tracks (~170 MB/s): USB3 / UAS (7.9W vs. 3.3W) random random kB reclen write rewrite read reread read write 102400 4 11738 23147 25131 25087 1091 948 102400 16 62218 77830 84257 84768 4246 4136 102400 512 150052 148303 154342 163817 58563 97809 102400 1024 148290 148324 156772 164963 85125 113412 102400 16384 149840 149248 144297 151440 153146 133806 1024000 16384 167750 169544 172970 174205 160859 151406 When connected to an USB2 port performance drops a lot (maxing out at ~37MB/s): USB2 / UAS (6.4W vs. 3.3W) random random kB reclen write rewrite read reread read write 102400 4 7735 7849 6821 7925 998 916 102400 16 17687 19040 20793 19430 3624 4096 102400 512 33472 33662 33738 34329 26020 33683 102400 1024 33836 34030 34855 35505 29941 28791 102400 16384 34294 34373 35599 36694 36174 33714 1024000 16384 33600 34516 36576 36902 36372 34111 I tested backing up the same MacBook Air twice with ~70 GB data using Gigabit Ethernet (the usual Thunderbolt Ethernet adapter) and time difference was negligible comparing HDD connected to USB2 or USB3. When backing up through Wi-Fi there is no difference any more since Wi-Fi is the bottleneck. In other words: from a performance point of view for this use case connecting the SATA cable to an USB2 port and being able to totally cut power to both cable/JMS578 (+1.5W consumption) and a sleeping 3.5" disk (less than 0.1W consumption with almost all disks) is worth the efforts. Once your MacBook gets stolen you simply disconnect the backup HDD from the USB2 and reattach it to an USB3 port and start the restore on your new device with +80 MB/s (Gigabit Ethernet now being the bottleneck) What about power requirements? ROCK64 only provides up to 650 mA on the USB2 ports! I tried to test this precisely with my usual 'monitoring PSU' approach. All I was getting were some nice kernel panics due to UNDERPOWERING. The Banana Pro I used to provide power (and measure consumption) simply does not provide enough current so Linux on ROCK64 started to fail in many funny ways once USB accesses happened. So I had to revert on measuring with PSU included with a cheap powermeter (more realistic but not that precise). When measuring only the 12V rail of my 3.5" Barracuda the disk consumed up to 18W when spinning up. In normal operation (either idle or with any workload) 12V consumption varied between 6W and 8W (12V only needed to spin the platters). The 5V power requirements for JMS578 + 3.5" HDD disk were as follows: USB2: 6.4W vs. 3.3W (full load vs. idle). Numbers with 5V PSU included so we're talking about needed power provided on an USB2 port of approximately ~3W which fits perfectly in the power budget of ROCK64's USB2: 650mA * 5V == 3250mW USB3: 7.9W vs. 3.3W (full load vs. idle). Numbers again with 5V PSU included so we're talking about needed power provided on an USB3 port of approximately ~4W which fits perfectly in the power budget of ROCK64's USB3: 950mA * 5V == 4750mW At least with my 3.5" HDD it worked pretty well to let it operate on both USB2 and USB3 ports when board powering was appropriate (with insufficient powering all weird sorts of issues popped up. My favourite was a kernel panic when issueing 'lsusb' after 30 seconds. Once I powered ROCK64 reliably all these 'software issues' were gone immediately -- again and again: insufficient powering is one of the most severe problem sources)

As with all H5 boards. On the other hand the FriendlyELEC OS images try very hard to be an Armbian copy anyway (they use an outdated version of our motd display stuff, include our monitoring work partially but for whatever reasons do not include some important performance tweaks applied by /etc/init.d/armhwinfo -- maybe we need to change the name to /etc/init.d/armhwtuning ) If you want to use it as a NAS then I would start with their OMV images (said to contain almost all performance tweaks we developed over there) and switch over to Armbian later if we're ready and you're not satisfied with FriendlyELEC's software offerings (I'm somewhat puzzled that they're still on kernel 4.11.2)

Based on the kernel version you're most probably running my latest OMV build? If that's the case it might be related to zram (since I realized too late that with a btrfs rootfs no 'vm.swappiness=0' is set but the default applies (60 IIRC, please check with sysctl and report back whether disabling zram changes something or not).