dmitry_z

To whom it may concern : found another not-working M.2 NVMe SSD DEM28-A28M61BWAQC https://www.innodisk.com/en/products/flash-storage/m2-sata/M2_P80_3ME2 PS It also equipped with Toshiba chips

Thanks to everyone who replied ! It was bad luck with Toshiba . Successfully verified 3 different M.2 SSD models : Samsung 970 EVO Kingston SA1000M8 Intel SSDPEKKW128G801 All three are working just fine (as it should be) , Samsung is the fastest . Beware of Toshiba KBG30ZMS256GA !

Yes, that Toshiba accidentally turned out to be the only M.2 NVMe SSD we currently have for testing. And looks like it's not a perfect fit. We ordered a couple of M.2 2280 SSDs - Samsung & Kingston , and will test with them when they will be delivered. And we constrained by time and money - don't want to waste them playing with multiple drives available on the market .. Thank you very much for your reply ! I'll update upon our results with Samsung and Kingston.

Hello to everyone , We have several T4 boards and can't get the NVMe SSD we currently have - Toshiba KBG30ZMS256GA - working ... Tried different 4.4 kernels and various distros . The SSD itself proofed to be working in Mikrotik RouterBoard RBM33G . Before we buy some other NVMe SSDs to try , I want to ask for advise . Is it ok to get such messages from kernel : # dmesg | grep -i pci PCI I/O : 0xffffffbffee00000 - 0xffffffbfffe00000 ( 16 MB) [ 0.119383] PCI/MSI: /interrupt-controller@fee00000/interrupt-controller@fee20000 domain created [ 1.540416] PCI: CLS 0 bytes, default 64 [ 1.948302] phy phy-pcie-phy.5: Looking up phy-supply from device tree [ 1.948312] phy phy-pcie-phy.5: Looking up phy-supply property in node /pcie-phy failed [ 1.950471] rockchip-pcie f8000000.pcie: GPIO lookup for consumer ep [ 1.950482] rockchip-pcie f8000000.pcie: using device tree for GPIO lookup [ 1.950510] of_get_named_gpiod_flags: parsed 'ep-gpios' property of node '/pcie@f8000000[0]' - status (0) [ 1.950757] rockchip-pcie f8000000.pcie: Looking up vpcie3v3-supply from device tree [ 1.950858] rockchip-pcie f8000000.pcie: Looking up vpcie1v8-supply from device tree [ 1.950870] rockchip-pcie f8000000.pcie: Looking up vpcie1v8-supply property in node /pcie@f8000000 failed [ 1.950884] rockchip-pcie f8000000.pcie: no vpcie1v8 regulator found [ 1.950892] rockchip-pcie f8000000.pcie: Looking up vpcie0v9-supply from device tree [ 1.950901] rockchip-pcie f8000000.pcie: Looking up vpcie0v9-supply property in node /pcie@f8000000 failed [ 1.950913] rockchip-pcie f8000000.pcie: no vpcie0v9 regulator found [ 1.971648] rockchip-pcie f8000000.pcie: invalid power supply [ 2.471703] rockchip-pcie f8000000.pcie: PCIe link training gen1 timeout! [ 2.471905] rockchip-pcie: probe of f8000000.pcie failed with error -110 [ 2.593787] ehci-pci: EHCI PCI platform driver Our system is current Armbian # uname -a Linux boise 4.4.174-rk3399 #31 SMP Sun Feb 10 00:37:23 CET 2019 aarch64 aarch64 aarch64 GNU/Linux The diagnostics is uploaded to http://ix.io/1EIL Many thanks in advance

Hello everyone, I'm trying to build a kernel so that OTG USB interface with Type-C connector could be accessed as usb0 network interface . If someone managed to solve this - please, share your experience .

Thank you so much, Martin ! UART2 is found on pins 11,13 indeed ! One more question: is it right to define in armbianEnv.txt param_pps_pin=PA7 and connect PPS wire to pin 29 ? I mean no mismatch here ?

Hello to everyone , I'm trying to read NMEA messages from GPS receiver via UART . But can't read anything on pins 8,10 & 38,40 .. What coulb be a reason ? GPS receiver is working fine , I can read it via USB-UART converter on the same board ... Thanks in advance ! Here's my system (UARTs are enabled via armbian config utility): root@orangepiprime:/boot# cat armbianEnv.txt verbosity=1 console=both overlay_prefix=sun50i-h5 rootdev=UUID=aca8c4ac-41d0-4e0b-ae7e-1d727baa4d43 rootfstype=ext4 overlays=pps-gpio uart1 uart2 uart3 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u root@orangepiprime:/boot# uname -a Linux orangepiprime 4.14.70-sunxi64 #274 SMP Wed Sep 19 12:09:30 CEST 2018 aarch64 GNU/Linux