• Posts

  • Joined

  • Last visited

Everything posted by martinayotte

  1. Yes ! this is a known issue, it is cause by autodetection been broken when executed on Mainline, since some drivers not present yet in DTS. (Like the CPU temperature is not working, at least on by boards with 4.6.0-rc1) For HDMI, there is some code from Jef Moine if you wish to try it out and compile you own kernel, hoping this will be merged soon in Sunxi MainLine. (
  2. From the messages above, especially 'command not found' and 'No such file or directory', it look like a "chroot" has been executed wrongly during the install. Maybe this specific package has something wrong ... I bet that any other apt-get will work
  3. Although the OPi+ and RaspberryPi headers are similar, the GPIOs are not exactly matching, so maybe you will need to tweak the software accordingly. You can also purchase the USB dongle and use OpenZWave software (which is what I did) . EDIT : While working/answering this other thread, I've suddenly got a flash in my head : If this Razberry board only using UART3, then it is simply that those are not enabled by default in either FEX (Legacy) or DTB (Mainline). In this other thread, I've provided a new DTB for OrangePi-PC.
  4. Looking at my v4.6.0-rc1 source tree, I see that those are not enabled in DTS yet, present but without any pins assigned. So, it need to be tweaked soon using a patch. EDIT : I've done it ! here is in attachment my latest sun8i-h3-orangepi-pc.dtb-4.6-PATCHED (ttyS0 to ttyS3, which also include my I2C stuff added few weeks ago) EDIT2 : I've done some loopback tests, ttyS1 and ttyS3 are working fine, but for unknown reason, ttyS2 doesn't work, although same DTS recipe has been done.
  5. Yes ! with V4.x kernel, all the serials are present in DTS. For Legacy, maybe the FEX needs to be tweaked, you can look at it by using bin2fex (and fex2bin if you need to change something)
  6. The UART on header pin 8/10 is not /dev/ttyS0 ! The /dev/ttyS0 is the UART attached to the small 3 pins header next to DC Barrel. The one on the header pin 8/10 is the UART3, therefore, as @candratech mentioned, it should be /dev/ttyS3...
  7. Using this 4.6.0-rc1 image, I was able to install several packages using apt-get, but of course, I was still using my USB-WiFi dongle as network connection.
  8. Could it be simply because of /etc/group membership ?
  9. I've compiled 4.6.0-rc1 yesterday (and ported my previous I2C patches from 4.4.5). It is booting properly. So, that is strange that your 4.6-rc is freezing during U-Boot.
  10. The "" forum is terribly slow sometime, and even some pages appeared incomplete. My account never been confirmed after several months. Their emails are either never sent or, as you said, maybe blocked.
  11. You have plenty of those errors in your log ... This is because your orangepi doesn't have DNS to resolve IPAddr of this server. To confirm, simply try "ping" ...
  12. Yes, the onboard Ethernet issue on OPiOne is the same as OPiPC. You need to use USB WiFi dongle and enable its connection in /etc/network/interface.
  13. Of course, I would try to put 2 litters of milk in a 750ml bottle ... But the beauty of "tar piped in another tar" is that you can even do it across SSH. (For full backup, you still need to be aware of not including backup of special folders, such as "/lost+found" or "/proc" ) Or course, the rsync method is good too !
  14. What do you means ? The first "tar" is reading filesystem ext2/ext4 without any issues, wherever the file blocks are located, and the second "tar" restore them on the PC, so there is no 16GB limit.
  15. All my OPi-PCs are powered with simple 5V 2A wall adaptors.
  16. I've tried the newest patch from montjoie,, but still have the " ERROR: TX is full" flood while trying the iperf test.
  17. I have some USB-RS485 dongle plugged on OPi-PC (with Armbian 4.4.5) and running some code which scan RS485 buses for several days/weeks, and USB never stopped, it still working.
  18. @candratech, Thanks for the patches, I didn't get change to try it out, too many things to do for daily job ... Is your tests succeeded with better throughput for eth0 without the "ERROR: TX is full" flood ?
  19. Yes, I had to patch reset-controller.h too, as shown in the patches. For my SPI timeout issue, I didn't resolve it yet. From what I know, when working on SPI with 4.4.5, I've tried to change the max speed in DTS, and it had no effect on real speed seen with logic analyser. So, I doubt it will fix the timeout issue on 4.5.0+, but I will give it a second try tomorrow.
  20. Unfortunately, I think the "Sparkling wine" should even been downgraded to "7-Up" : Doing a SSH to the eth0 IP, I've then turned of the Wifi to keep only the eth0 routing ! Even the shell is reacting badly, typing is not showing the echo instantaneously sometimes, I need to keep typing blindly and hit enter to finally get the echo. And even the DNS doesn't seems to work in my case, although it is still present in /etc/resolv.conf. Doing the iperf tests again, it completely become frozen ... Looking at the /dev/ttyS0 serial : flood of sun8i-emac 1c30000.ethernet: ERROR: TX is full ...
  21. For the patches, since most were already applied, I've applied manually the 0001-ethernet-add-sun8i-emac-driver.patch follow by 0005-ethernet-add-sun8i-emac-driver.patch, but both looks the same. For iperf, you will be deceived ... I didn't provide any options except -c/-s, tested on both directions, first thru the R8188eu Wifi : root@orangepipc:~# iperf -s ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) ------------------------------------------------------------ [ 4] local port 5001 connected with port 43820 [ ID] Interval Transfer Bandwidth [ 4] 0.0-10.3 sec 39.8 MBytes 32.5 Mbits/sec ^Croot@orangepipc:~# iperf -c connect failed: Connection refused root@orangepipc:~# iperf -c ------------------------------------------------------------ Client connecting to, TCP port 5001 TCP window size: 43.8 KByte (default) ------------------------------------------------------------ [ 3] local port 56344 connected with port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 45.2 MBytes 37.8 Mbits/sec and then thru eth0 : root@orangepipc:~# iperf -s ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) ------------------------------------------------------------ [ 4] local port 5001 connected with port 53540 [ ID] Interval Transfer Bandwidth [ 4] 0.0-10.4 sec 11.6 MBytes 9.41 Mbits/sec root@orangepipc:~# iperf -c ------------------------------------------------------------ Client connecting to, TCP port 5001 TCP window size: 43.8 KByte (default) ------------------------------------------------------------ [ 3] local port 56346 connected with port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.1 sec 28.5 MBytes 23.7 Mbits/sec So, lets keep Champagne for another day, and open simple Sparkling wine instead ...
  22. Ok ! While waiting for your answer, I started applying but only the newest. (btw, the second one and the last one seems to be the same patch). Rebuilt it, no more errors in dmesg every 15 secs, but still an error : [ 10.245720] sun8i-emac 1c30000.ethernet eth0: eth0: PHY ID 00000044 at 0 IRQ poll (1c30000.ethernet:00) [ 10.255561] sun8i-emac 1c30000.ethernet eth0: Link is Up - Unsupported (update phy.c)/Half - flow control off [ 10.265570] sun8i-emac 1c30000.ethernet: MDC auto : 0 [ 10.270635] sun8i-emac 1c30000.ethernet: sun8i_emac_set_mac_address [ 10.276934] sun8i-emac 1c30000.ethernet: sun8i_emac_set_macaddr slot 0 9a 9 52 94 51 69 [ 10.285332] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 12.245781] sun8i-emac 1c30000.ethernet: sun8i_emac_adjust_link link=0 duplex=0 speed=a Did it worked on your side ? EDIT : Oh !!! BINGO !!! Doing "ifdown eth0; ifup eth0" manually, I got an IP from DHCP ! The EMAC is working ! Champagne, guys !!!
  23. Hi Tkaiser, Were those integrated into Armbian patching process or should I try to apply them manually ?
  24. I've finally got the latest dev 4.5.0+ to compile and boot with the USB patches. Unfortunately for the EMAC, I'm seeing the following error in dmesg almost every 15 secs : [ 16.585685] sun8i-emac 1c30000.ethernet: sun8i_emac_xmit xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx len=342 [ 16.594789] sun8i-emac 1c30000.ethernet: sun8i_emac_xmit found slot 3 at 0xf10b2030 (slot=4) [ 16.603304] sun8i-emac 1c30000.ethernet: sun8i_emac_dma_interrupt 40000125 [ 16.610188] sun8i-emac 1c30000.ethernet: sun8i_emac_complete_xmit [ 16.616291] sun8i-emac 1c30000.ethernet: sun8i_emac_complete_xmit found slot to clean 3 at 0xf10b2030 0 f9000156 (len=342) [ 16.627340] sun8i-emac 1c30000.ethernet: TX DMA currddesc=7ec4e040 [ 16.633524] sun8i-emac 1c30000.ethernet: Re-run TX DMA 40000002 [ 16.639447] sun8i-emac 1c30000.ethernet: Unhandled interrupt TX_EARLY_INT [ 16.646243] sun8i-emac 1c30000.ethernet: sun8i_emac_rx_from_ddesc from 03 0xf10b0030 len=346 status=15a0320 st=5dc [ 16.656614] sun8i-emac 1c30000.ethernet: Init ddesc 03 at 0xf10b0030 buff=ee6bfe30 6dbe2c42 status=(80000000 5dc) len=1500 Also, unfortunately, my I2C/SPI patches don't seems to work too ... I will continue investigate on that since they were working fine under 4.5.0-rc6+ ... At least, with the USB working, I've a USB-Wifi dongle working for the networking. EDIT: for the I2C/SPI patches, I had forgot one of the patches on top level DTS. Now I2C is working, SPI device appears, but it is timing out ...
  25. Me too, I'm still struggling to get a build from dev. I will continue investigation today ... (I'm even getting trouble with the latest next 4.4.6, it is building, but not booting.)