15 15
mindee

NanoPI M4

Recommended Posts

dbe8a2f2236732bc929bedb89fd627a5bf0d2bac

 

Consumption test:

(Wifi off. With Gigabit LAN connection)

 

Idle: 2.30W    

1-Core: 4.40W    

2-Core: 6.70W    

4-Core: 7.75W    

6-Core: 8.85W

6-Core + IO : 9.50W

 

Idle:

d0d553740b23a79d9115dae985a18c6b46bf3781

 

Full+IO:

80c097d26fe68f4fcccca369aab98a3298c448dd

Share this post


Link to post
Share on other sites

Regarding hard discs. Getting 300 mbs on Samsung 840 ssd via single usb 3 adaptor.  Emmc is about twice as fast as a class A2 SD which is about 40mbs / 80 emmc. I'll get exact numbers as these are from memory!

 

Boot from ssd is noticeably quicker than both, despite some info coming from the emmc initially.  Boot time from seeing the first cursor to a compete desktop is about 2 or 3 seconds. 

 

I hope integration from web browsers to the gpu might happen, as that is the only thing stopping this sbc being a real desktop alternative.

Share this post


Link to post
Share on other sites
6 minutes ago, NicoD said:

You've got an undervoltage before it goes into the board.
I wonder what your USB voltage is?

2A is causing volt drop from the psu. It'll likely still be 5.1v at the source end.

 

Back in the day, Texas PLCs had a 5V psu. This had a remote sense which had to be connected to the CPU card. I don't recall the exact processor, but it was 5v logic levels and quite power hungry. Thin power cables caused all sorts of problems, even with the remote sense due to fast transient under voltage.

 

10w is dissipation is notably a lot for this smallish passive heatsink.

Share this post


Link to post
Share on other sites
41 minutes ago, dogshome said:

2A is causing volt drop from the psu. It'll likely still be 5.1v at the source end.

You say it yourself. 5.1V at the source, and only 4.92 that the board. That's a too big drop. Your cables have a too big resistance. I used cables rated at 4A that can't provide stable 2A at 5V. 90% of the sold USB type-C cables are just not ok above 2A.
The USB type c port is better, but the cables stayed the same.

Share this post


Link to post
Share on other sites
13 hours ago, NicoD said:

The 2 left USB3 ports or working over the same controller, so best to use one on the left, and one on the right. Then you can reach max speed on both together.
Read/Write speeds depend a lot on file sizes. Small files = slower. 
17-21MB/s seems very slow. Is it using a USB3 to SATA adapter? Test what speed the hdd`s is capable of with big files. Then compare with the results you get here.

 

Thanks for your suggestion, but I have to use this enclosure that uses one USB port only.

 

Although 17-21MB/sec (for large files) shown by rsync is quite slow, it is not unacceptable for me, I use it for my backup files only. First time copy took quite a long time, but my daily/weekly change data is not so much, so daily/weekly update to the backup takes only 1-2 minutes or even shorter.

 

Share this post


Link to post
Share on other sites
14 hours ago, NicoD said:

You've got an undervoltage before it goes into the board.
I wonder what your USB voltage is?

IDLE :

VDD_5V : 5.05V

VCC5V0_SYS : 5.03V

 

FULL:

VDD_5V : 4.85V

VCC5V0_SYS : 4.80V

 

Powered with a Meanwell GS25E-05, 16AWG wires (12.5mOhm/m).

 

The VDD_5V goes through the AO3415A mosfet. According to the specs it has a 42mOhm Rds(on). That mean a loss of 0.02V@idle and 0.1V@load.

I haven't measured the USB 5V voltage, but it's directly connected to VDD_5V over a RT9724GQW load switch I think (Rds(on): 100mOhm),

Share this post


Link to post
Share on other sites
On 12/21/2018 at 11:32 AM, edupv said:

For reference btrfs raid 1 rsync writing speed

 

I just want to report that the writing speed from cwrsync (windows 10)  to the btrfs raid 1 on NanoPo-M4 is 17MB/sec. (rsync option --info=progress2, during copying shows 21MB/sec, and then 17MB/sec when finished).

 

Note :

My 2 harddisks are on the same USB port (one enclosure contains two 2.5" hdd), not sure if each hdd on separated USB port will give better performance or not.

 

17-21MB/sec is the speed shown by cwrsync.

 

The dd command test results are as the following :

root@nanopim4:~# dd if=/dev/zero of=/bigdata/test1.img bs=1G count=1 oflag=dsync
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 30.4417 s, 35.3 MB/s
root@nanopim4:~# dd if=/dev/zero of=/bigdata/test1.img bs=4G count=1 oflag=dsync
0+1 records in
0+1 records out
2147479552 bytes (2.1 GB, 2.0 GiB) copied, 33.0011 s, 65.1 MB/s
root@nanopim4:~# dd if=/dev/zero of=/bigdata/test1.img bs=4G count=2 oflag=dsync
dd: warning: partial read (2147479552 bytes); suggest iflag=fullblock
0+2 records in
0+2 records out
4294959104 bytes (4.3 GB, 4.0 GiB) copied, 56.6536 s, 75.8 MB/s
root@nanopim4:~# dd if=/dev/zero of=/bigdata/test2.img bs=512 count=1000 oflag=dsync
1000+0 records in
1000+0 records out
512000 bytes (512 kB, 500 KiB) copied, 2.01652 s, 254 kB/s
root@nanopim4:~#

 

More tests :

root@nanopim4:~# dd if=/dev/zero of=/bigdata/test1.img bs=2G count=2 oflag=dsync
dd: warning: partial read (2147479552 bytes); suggest iflag=fullblock
0+2 records in
0+2 records out
4294959104 bytes (4.3 GB, 4.0 GiB) copied, 61.0895 s, 70.3 MB/s
root@nanopim4:~# dd if=/dev/zero of=/bigdata/test1.img bs=2G count=1 oflag=dsync
0+1 records in
0+1 records out
2147479552 bytes (2.1 GB, 2.0 GiB) copied, 27.7552 s, 77.4 MB/s
root@nanopim4:~#

 

Share this post


Link to post
Share on other sites

I just acquired nanopi-m4. I'm shooting with the latest nightly version of ubuntu bionic. When I turn off the card I have 2 bugs.
An image remains on the screen.
The card warms up hugely without stopping. The heater becomes extremely hot after 1 to 2 minutes while the power supply remains connected.

Share this post


Link to post
Share on other sites
9 hours ago, dragonlost said:

I'm shooting with the latest nightly version of ubuntu bionic.

What happens if you run a stable (non nightly) version of Armbian Bionic?

Share this post


Link to post
Share on other sites

So, did anyone notice issues with Apache + SSL?

 

I'm using Armbian Stretch  from here https://dl.armbian.com/nanopim4/Debian_stretch_default.7z and apparently when I enable SSL in Apache, large downloads just hang after a while.  I can't reproduce this issue with plain HTTP. Example on `wget` (same behaviour on a browser): 

    wget https://xyz---/test.bin
    --2019-01-13 18:22:22--  https://xyz---/test.bin
    Resolving xyz--- (xyz---)... 85.241.xxx.xxx
    Connecting to xyz--- (xyz---)|85.241.xxx.xxx|:443... connected.
    HTTP request sent, awaiting response... 200 OK
    Length: 1073741824 (1,0G) [application/octet-stream]
    Saving to: 'test.bin.2'
    
    test.bin.2                      39%[==================>                               ] 403,66M  11,6MB/s    eta 54s

It was downloading fine until it reached 403,66M, after this point nothing else happened. On the server side I get this:

ssl_engine_io.c(2135): [client 85.243.xxx.xxx:59904] OpenSSL: write 16413/16413 bytes to BIO#5588cd8c50 [mem: 5588a87c23] (BIO dump follows)
core_filters.c(525): [client 85.243.xxx.xxx:59904] core_output_filter: flushing because of THRESHOLD_MAX_BUFFER
core_filters.c(547): (70007)The timeout specified has expired: [client 85.243.xxx.xxx:59904] core_output_filter: writing data to the network
ssl_engine_io.c(2144): [client 85.243.xxx.xxx:59904] OpenSSL: I/O error, 16413 bytes expected to write on BIO#5588cd8c50 [mem: 5588a87c23]
(70007)The timeout specified has expired: [client 85.243.xxx.xxx:59904] AH01993: SSL output filter write failed.
ssl_engine_io.c(2135): [client 95.239.xxx.xxx:9937] OpenSSL: write 45/45 bytes to BIO#55bd9e23e0 [mem: 55bd9ec213] (BIO dump follows)
ssl_engine_io.c(2144): [client 95.239.xxx.xxx:9937] OpenSSL: I/O error, 5 bytes expected to read on BIO#55bd9e9d80 [mem: 55bd9ec213]

Here is the configuration of the VHosts serving this requests:

    <VirtualHost *:443>
        ServerName xyz---
        ServerAdmin tcb13---
        DocumentRoot /test
        ErrorLog /test/error.log
        CustomLog /test/access.log combined
    
        SSLEngine on
        SSLCertificateFile /mnt/SU1/letsencrypt/config/live/xyz---/fullchain.pem
        SSLCertificateKeyFile /mnt/SU1/letsencrypt/config/live/xyz---/privkey.pem
        Header always set Strict-Transport-Security "max-age=15768000"
    
        LogLevel trace6
    </VirtualHost>

I'm sure this isn't a network related problem because:

  1. Only happens with SSL enabled, on non-ssl vhosts I can download without issues;
  2. Other protocols (FTP and SCP) work just fine to download the same test file;
  3. No issues while testing the network with iperf3.

 

Some system info:

lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 9.6 (stretch)
Release:        9.6
Codename:       stretch

uname -a
Linux testxyz 4.4.162-rk3399 #41 SMP Fri Oct 26 14:03:47 CEST 2018 aarch64 GNU/Linux

apache2ctl -V | grep -i "Server version"
Server version: Apache/2.4.25 (Debian)
root@testxyz:~# dpkg -l |grep apache2
ii  apache2                         2.4.25-3+deb9u6                                       arm64        Apache HTTP Server
ii  apache2-bin                     2.4.25-3+deb9u6                                       arm64        Apache HTTP Server (modules and other binary files)
ii  apache2-data                    2.4.25-3+deb9u6                                       all          Apache HTTP Server (common files)
ii  apache2-utils                   2.4.25-3+deb9u6                                       arm64        Apache HTTP Server (utility programs for web servers)
ii  libapache2-mod-php7.3           7.3.0-2+0~20181217092659.24+stretch~1.gbp54e52f       arm64        server-side, HTML-embedded scripting language (Apache 2 module)

Thank you all.

Share this post


Link to post
Share on other sites

Meanwhile the iotop command is also broken:

iotop
Traceback (most recent call last):
File "/usr/sbin/iotop", line 17, in 
main()
File "/usr/lib/python3/dist-packages/iotop/ui.py", line 620, in main
main_loop()
File "/usr/lib/python3/dist-packages/iotop/ui.py", line 610, in 
main_loop = lambda: run_iotop(options)
File "/usr/lib/python3/dist-packages/iotop/ui.py", line 508, in run_iotop
return curses.wrapper(run_iotop_window, options)
File "/usr/lib/python3.5/curses/init.py", line 94, in wrapper
return func(stdscr, *args, **kwds)
File "/usr/lib/python3/dist-packages/iotop/ui.py", line 501, in run_iotop_window
ui.run()
File "/usr/lib/python3/dist-packages/iotop/ui.py", line 155, in run
self.process_list.duration)
File "/usr/lib/python3/dist-packages/iotop/ui.py", line 434, in refresh_display
lines = self.get_data()
File "/usr/lib/python3/dist-packages/iotop/ui.py", line 415, in get_data
return list(map(format, processes))
File "/usr/lib/python3/dist-packages/iotop/ui.py", line 388, in format
cmdline = p.get_cmdline()
File "/usr/lib/python3/dist-packages/iotop/data.py", line 292, in get_cmdline
proc_status = parse_proc_pid_status(self.pid)
File "/usr/lib/python3/dist-packages/iotop/data.py", line 196, in parse_proc_pid_status
key, value = line.split(':\t', 1)
ValueError: not enough values to unpack (expected 2, got 1)

 

Share this post


Link to post
Share on other sites

Hello to everybody.

I have a problem: everytime when i reboot the ip-adress increases. No other OS or System (Raspy, Tablet, Pc) does so.

Has somebody an idea to fix this?

 

Thank you

Share this post


Link to post
Share on other sites
27 minutes ago, schnitzel said:

No other OS or System


Most Armbian images do not have this problem as well.

 

27 minutes ago, schnitzel said:

Has somebody an idea to fix this?


It should be fixed, but our fix could also be broken - RK3399 has handull of small troubles which is why we actually don't provide end user support yet. When you are approaching with a problem, you always need to provide logs (armbianmonitor -u).

Share this post


Link to post
Share on other sites
Just now, TCB13 said:

Hello, can you confirm that my Apache/OpenSSL I/O issue might be something you guy already know about?


I didn't encounter them by myself, but I think somebody brought up troubles when copying large files via USB3 drives. Check older posts in this subforum.

Share this post


Link to post
Share on other sites
34 minutes ago, Igor said:


I didn't encounter them by myself, but I think somebody brought up troubles when copying large files via USB3 drives. Check older posts in this subforum.

 

Thank you for the answer, however if you look closely at my apache config I was trying to get the file from the eMMC card (because I was afraid of those issues you are taking about). I only had the SSL certifications on external media. Also tried with the certificates on the eMMC, same issue. I don't think its an USB3 issue because if I get a 10GB file stored on a USB disk via SCP it works just fine.

 

Another strange thing: if I wget the file on the device itself it works fine, it doesn't stop, so maybe a network issue and the OpenSSL errors aren't that important?

Share this post


Link to post
Share on other sites
Just now, TCB13 said:

Another strange thing: if I wget the file on the device itself it works fine, it doesn't stop, so maybe a network issue and the OpenSSL errors aren't that important?


Problems are outside user space levels otherwise we would notice such problems on other boards, but we don't. Kernel is the king and the troublemaker :) 

Share this post


Link to post
Share on other sites
1 hour ago, Igor said:


Problems are outside user space levels otherwise we would notice such problems on other boards, but we don't. Kernel is the king and the troublemaker :) 

 

I did have the same issue with downloads using wget on the device itself. It was fixed by an update 2 days ago (cleaned log bellow) I've no idea about which package update fixed the issue locally.

libsystemd0:arm64 (232-25+deb9u7) over (232-25+deb9u6)
libnss-myhostname:arm64 (232-25+deb9u7) over (232-25+deb9u6)
libpam-systemd:arm64 (232-25+deb9u7) over (232-25+deb9u6)
systemd (232-25+deb9u7) over (232-25+deb9u6)
udev (232-25+deb9u7) over (232-25+deb9u6)
libudev1:arm64 (232-25+deb9u7) over (232-25+deb9u6)
systemd-sysv (232-25+deb9u7) over (232-25+deb9u6)
php7.3-zip (7.3.1-1+0~20190113101756.25+stretch~1.gbp15aaa9) over (7.3.0-2+0~20181217092659.24+stretch~1.gbp54e52f)
php7.3-intl (7.3.1-1+0~20190113101756.25+stretch~1.gbp15aaa9) over (7.3.0-2+0~20181217092659.24+stretch~1.gbp54e52f)
php7.3-readline (7.3.1-1+0~20190113101756.25+stretch~1.gbp15aaa9) over (7.3.0-2+0~20181217092659.24+stretch~1.gbp54e52f)
php7.3-mysql (7.3.1-1+0~20190113101756.25+stretch~1.gbp15aaa9) over (7.3.0-2+0~20181217092659.24+stretch~1.gbp54e52f)
php7.3-xml (7.3.1-1+0~20190113101756.25+stretch~1.gbp15aaa9) over (7.3.0-2+0~20181217092659.24+stretch~1.gbp54e52f)
php7.3-opcache (7.3.1-1+0~20190113101756.25+stretch~1.gbp15aaa9) over (7.3.0-2+0~20181217092659.24+stretch~1.gbp54e52f)
php7.3-curl (7.3.1-1+0~20190113101756.25+stretch~1.gbp15aaa9) over (7.3.0-2+0~20181217092659.24+stretch~1.gbp54e52f)
php7.3-imap (7.3.1-1+0~20190113101756.25+stretch~1.gbp15aaa9) over (7.3.0-2+0~20181217092659.24+stretch~1.gbp54e52f)
php7.3-json (7.3.1-1+0~20190113101756.25+stretch~1.gbp15aaa9) over (7.3.0-2+0~20181217092659.24+stretch~1.gbp54e52f)
php7.3-mbstring (7.3.1-1+0~20190113101756.25+stretch~1.gbp15aaa9) over (7.3.0-2+0~20181217092659.24+stretch~1.gbp54e52f)
php7.3-cli (7.3.1-1+0~20190113101756.25+stretch~1.gbp15aaa9) over (7.3.0-2+0~20181217092659.24+stretch~1.gbp54e52f)
libapache2-mod-php7.3 (7.3.1-1+0~20190113101756.25+stretch~1.gbp15aaa9) over (7.3.0-2+0~20181217092659.24+stretch~1.gbp54e52f)]
php7.3-common (7.3.1-1+0~20190113101756.25+stretch~1.gbp15aaa9) over (7.3.0-2+0~20181217092659.24+stretch~1.gbp54e52f)
linux-dtb-rk3399 (5.70) over (5.65) 

update-initramfs: Deleting /boot/initrd.img-4.4.162-rk3399
Removing obsolete file uInitrd-4.4.162-rk3399

linux-image-rk3399 (5.70) over (5.65)
linux-stretch-root-nanopim4 (5.70) over (5.65)
linux-u-boot-nanopim4-default (5.70) over (5.65) 

php7.3 (7.3.1-1+0~20190113101756.25+stretch~1.gbp15aaa9) over (7.3.0-2+0~20181217092659.24+stretch~1.gbp54e52f) 

 

Share this post


Link to post
Share on other sites
On 1/17/2019 at 11:14 AM, Igor said:


Problems are outside user space levels otherwise we would notice such problems on other boards, but we don't. Kernel is the king and the troublemaker :) 

 

@Igor just found out the source of my problems. It's the on-board network.

 

I just added a cheap USB 3 to Ethernet adaptor and I'm able to download files without issues at all. Maybe there is some strange bug with the driver for the built in network? However I don't get why it only manifests itself on HTTPS, other protocols such as SSH work just fine.

 

Thank you all.

 

----------------

 

Update: I manage to find out that this issues are caused by TCP offloading. Disabling it with `ethtool -K eth0 rx off tx off` fixed the issue, no more errors on downloads.

Edited by TCB13

Share this post


Link to post
Share on other sites
On 1/18/2019 at 7:52 AM, TCB13 said:

 

@Igor just found out the source of my problems. It's the on-board network.

 

I just added a cheap USB 3 to Ethernet adaptor and I'm able to download files without issues at all. Maybe there is some strange bug with the driver for the built in network? However I don't get why it only manifests itself on HTTPS, other protocols such as SSH work just fine.

 

Thank you all.

 

----------------

 

Update: I manage to find out that this issues are caused by TCP offloading. Disabling it with `ethtool -K eth0 rx off tx off` fixed the issue, no more errors on downloads.

I have the same problem with you. When I download bittorrent file from web,the network crashed,and when I use usb network card,every work good.

Share this post


Link to post
Share on other sites
9 minutes ago, TCB13 said:

 

@littlema can you try 


ethtool -K eth0 rx off tx off

with the built in network adaptor and see if it helps?

 

Check my answer here to survive reboots https://unix.stackexchange.com/a/495378/23085 .

I try it in kernel 4.4.167.

Thank you for your help.

I am very excited that it can work very well.

But I also try it in the latest kernel 4.20,but get 'don't support the operation'.

I don't know why.

But I can have a good work in the 4.4.167.

Thank you very much!!!

Share this post


Link to post
Share on other sites
4 minutes ago, littlema said:

I try it in kernel 4.4.167.

Thank you for your help.

I am very excited that it can work very well.

But I also try it in the latest kernel 4.20,but get 'don't support the operation'.

I don't know why.

But I can have a good work in the 4.4.167.

Thank you very much!!!

 

Great, where did you get 4.20 from? Is there a link for it?

Share this post


Link to post
Share on other sites

linux newbe. just installed latest armbian from sd to mmc, configured wifi on my new nanoPi M4 2MB.

Will do NodeJS dev and Docker.

Thought NanoPi M4 board supports 4K HDMI desktop? But looks like 1920x1080 is highest possible resolution.

With FriendlyArm Ubuntu 18.04 same result.

 

Update; found looking at MickMake's NanoPI Neo4 review  #251 NanoPi NEO4: Smallest RK3399 SBC. What is real?

less /var/logs/Xorg.0.log 

xrandr --newmode "3840x2160"x0.0  297.00  3840 4016 4104 4400  2160 2168 2178 2250 +hsync +vsync 

xrandr --addmode HDMI-1 "3840x2160x0.0" 

xrandr –output HDMI-1 –mode "3840x2160x0.0" 

Edited by williamv
found solution

Share this post


Link to post
Share on other sites

Hi,

 

I have been struggling with a strange problem causing my Domoticz app to crash ever 5-10 days.

I have noted that my dmesg has a lot of these messages:

 

[3672676.299218] bcmsdh_sdmmc: Failed to Write byte F1:@0x1001f=00, Err: -5
[3672676.301072] bcmsdh_sdmmc: Failed to Write byte F1:@0x1001f=00, Err: -5
[3672676.302952] bcmsdh_sdmmc: Failed to Write byte F1:@0x1001f=00, Err: -5
[3672676.303863] bcmsdh_sdmmc: Failed to Read byte F1:@0x1001f=ff, Err: -5
[3672676.305737] bcmsdh_sdmmc: Failed to Read byte F1:@0x1001f=ff, Err: -5
[3672676.307589] bcmsdh_sdmmc: Failed to Read byte F1:@0x1001f=ff, Err: -5
[3672676.310518] bcmsdh_sdmmc: Failed to Write byte F1:@0x1001f=00, Err: -5
[3672676.312353] bcmsdh_sdmmc: Failed to Write byte F1:@0x1001f=00, Err: -5
[3672676.314268] bcmsdh_sdmmc: Failed to Write byte F1:@0x1001f=00, Err: -5
[3672676.315088] bcmsdh_sdmmc: Failed to Read byte F1:@0x1001f=ff, Err: -5
[3672676.316924] bcmsdh_sdmmc: Failed to Read byte F1:@0x1001f=ff, Err: -5
[3672676.318833] bcmsdh_sdmmc: Failed to Read byte F1:@0x1001f=ff, Err: -5
[3672676.319786] bcmsdh_sdmmc: Failed to Write byte F1:@0x1001f=00, Err: -5
[3672676.321644] bcmsdh_sdmmc: Failed to Write byte F1:@0x1001f=00, Err: -5
[3672676.323486] bcmsdh_sdmmc: Failed to Write byte F1:@0x1001f=00, Err: -5

 

I'm booting from an SD card with ARMBIAN 5.65 stable Ubuntu 18.04.1 LTS 4.4.162-rk3399 running off an USB3 SSD.

 

 

I need help to where these errors originate from - I guess it's the SD, right? But is it a driver/kernel issue or a HW issue??

 

Many thanks!

 

/M

 

 

Share this post


Link to post
Share on other sites
On 1/28/2019 at 11:26 AM, mio75 said:

Hi,

 

I have been struggling with a strange problem causing my Domoticz app to crash ever 5-10 days.

I have noted that my dmesg has a lot of these messages:

 


[3672676.299218] bcmsdh_sdmmc: Failed to Write byte F1:@0x1001f=00, Err: -5
[3672676.301072] bcmsdh_sdmmc: Failed to Write byte F1:@0x1001f=00, Err: -5
[3672676.302952] bcmsdh_sdmmc: Failed to Write byte F1:@0x1001f=00, Err: -5
[3672676.303863] bcmsdh_sdmmc: Failed to Read byte F1:@0x1001f=ff, Err: -5
[3672676.305737] bcmsdh_sdmmc: Failed to Read byte F1:@0x1001f=ff, Err: -5
[3672676.307589] bcmsdh_sdmmc: Failed to Read byte F1:@0x1001f=ff, Err: -5
[3672676.310518] bcmsdh_sdmmc: Failed to Write byte F1:@0x1001f=00, Err: -5
[3672676.312353] bcmsdh_sdmmc: Failed to Write byte F1:@0x1001f=00, Err: -5
[3672676.314268] bcmsdh_sdmmc: Failed to Write byte F1:@0x1001f=00, Err: -5
[3672676.315088] bcmsdh_sdmmc: Failed to Read byte F1:@0x1001f=ff, Err: -5
[3672676.316924] bcmsdh_sdmmc: Failed to Read byte F1:@0x1001f=ff, Err: -5
[3672676.318833] bcmsdh_sdmmc: Failed to Read byte F1:@0x1001f=ff, Err: -5
[3672676.319786] bcmsdh_sdmmc: Failed to Write byte F1:@0x1001f=00, Err: -5
[3672676.321644] bcmsdh_sdmmc: Failed to Write byte F1:@0x1001f=00, Err: -5
[3672676.323486] bcmsdh_sdmmc: Failed to Write byte F1:@0x1001f=00, Err: -5

 

I'm booting from an SD card with ARMBIAN 5.65 stable Ubuntu 18.04.1 LTS 4.4.162-rk3399 running off an USB3 SSD.

 

 

I need help to where these errors originate from - I guess it's the SD, right? But is it a driver/kernel issue or a HW issue??

 

Many thanks!

 

/M

 

 

 

I uploaded a "armbianmonitor -u" here: http://ix.io/1zCr

 

Does anybody have an idea what could be wrong?

 

Thanks!

Share this post


Link to post
Share on other sites
15 15