[Unable to boot Buster Legacy on NanoPi M4V2]

On 12/19/2020 at 12:18 PM, piter75 said:

Ok, it needs one more change to fix the boot issue (besides working bluetooth).

Right now the service type is set to forking but the brcm_patchram_plus_rk3399 binary is not forking so systemd treats it as not successfully activated / activating.

 

Change Type to exec and it should be properly treated by systemd.

I adjusted it in the PR too: https://github.com/armbian/build/pull/2480/commits/92729573cea1aa786432e1dce42d641019e8bcd4

I can confirm it works in the latest nightly build on my NanoPi M4 (original)  Thanks!

 

[edit]

I was able to make the requested changes on an imaged SD card by using a live distro on a skanky old laptop.  Gotta love Linux.  But after it successfully booted, the bluetooth module got an error.  I don't care as I'm not using it.  I might have typed it incorrectly.  Something about "before starting patchram download.  Newer chips do not generate these two bytes."  I can get more info if anyone wants it.

[NanoPI M4]

2 hours ago, williamv said:

with your samsung ssd i would expect a bit more. Have you tried the 5.4 kernel? (check other download options)

Still on 4.4 (stock Armbian Buster).  

[NanoPI M4]

On 3/29/2020 at 1:37 PM, TCB13 said:

My results with a NanoPi M4v2 + 8A custom power supply + Samsung nvme 256gb evo 960 pro:

 

$ dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync
16384+0 records in
16384+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2.72603 s, 394 MB/s

 

Kernel 4.4.213-rk3399

 

Slow isn't it ? I wonder what can be done to improve this.

 

Very nice.  For comparison, i ran this on my Nano Pi M4v1 with SATA hat and Sandisk SSD Plus.

$ dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync
16384+0 records in
16384+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 4.25152 s, 253 MB/s

 

[Special considerations upgrading Debian release (Stretch to Buster)?]

On 10/7/2019 at 12:44 PM, ynotssor said:

As root:

cp /etc/apt/sources.list /etc/apt/sources.list.backup
sed -i 's|stretch|buster|g' /etc/apt/sources.list
apt update && apt -y upgrade && apt -y dist-upgrade

It takes awhile, and welcome to Buster.

Just to confirm I did this on a NanoPi M4 running Armbian stretch (with OMV installed) and it was successful.  Now running Buster.  I had to answer some questions about local files different than maintainers.  Mostly I took Maintainers, but stayed with Local for things relevant to OMV such as Samba config. 

 

Also, after rebooting, run update/upgrade again.

[NanoPi M4 performance and consumption review]

On 4/29/2019 at 8:57 AM, razum2um said:

Hi,  I'd like to attach 3 samsung evo 1tb ssd to NanoPi M4 making whole thing as compat as possible (as such I don't consider miniITX on Intel)

The cost is less important than size. Now choosing which way:

 

1) via usb3

using https://www.aliexpress.com/item/USB-3-0-SATA-3-Cable-Sata-to-USB-Adapter-Up-to-6-Gbps-Support-2/32958928071.html?spm=a2g0s.8937460.0.0.2df52e0eq5jx9C 

and power by https://www.aliexpress.com/item/5A-USB-Cable-3-in-1-Fast-Charging-Fabric-Braide-Type-C-Micro-USB-Charger-Cable/32963726182.html?spm=a2g0s.8937460.0.0.2df52e0eq5jx9C which claims to output 5A

- pro: I hope to power everything from usb (I read ssds are quite power-effecient: https://www.anandtech.com/show/8747/samsung-ssd-850-evo-review/10) 

- contra: I'm not sure if this all works. From the first topic "even connect 2 SBCs to the USB -> the board crashed", but this guy used only 2A

Any thoughts, if the usb-c power supply above is ok? 

As I got from the thread NanoPi M4 cannot request more power from PSU, can it?

 

2) via NanoPi_M4_SATA_HAT

- pro: no need to sata-usb converters

- contra: I have to power sata. I don't know from where, since I'd like not to use standard desktop PSU.

Could you suggest a compact PSU for the sata hat?

 

I was using the Sabrant USB 3 -> SSD adapters, running Armbian (and OpenMediaVault) and kept having issues with the drive going off-line.  From googling and not really knowing what I'm doing, it appeared it was caused by  SSD power save stuff and I didn't know how to shut it off.  So I switched over to use the SATA hat (which I had previously tested as having equivalent performance via hdparm) and powered it with an old 12V power adapter with the correct barrel connector.  Works great and no crashes since.