Jump to content

martinayotte

Members
  • Posts

    3892
  • Joined

  • Last visited

Everything posted by martinayotte

  1. 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...
  2. 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.
  3. Could it be simply because of /etc/group membership ?
  4. 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.
  5. The "orangepi.org" 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.
  6. 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 httpredir.debian.org" ...
  7. 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.
  8. 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 !
  9. 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.
  10. All my OPi-PCs are powered with simple 5V 2A wall adaptors. http://www.ebay.ca/itm/AC-100V-240V-Converter-Adapter-DC-5V-2A-Power-Supply-US-plug-4-0mm-x-1-7mm-New-/351351652056
  11. I've tried the newest patch from montjoie, http://sunxi.montjoie.ovh/ethernet/0005-ethernet-add-sun8i-emac-driver.patch, but still have the " ERROR: TX is full" flood while trying the iperf test.
  12. 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.
  13. @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 ?
  14. 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.
  15. 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 ...
  16. 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 10.111.111.73 port 5001 connected with 10.111.111.11 port 43820 [ ID] Interval Transfer Bandwidth [ 4] 0.0-10.3 sec 39.8 MBytes 32.5 Mbits/sec ^Croot@orangepipc:~# iperf -c 10.111.111.11 connect failed: Connection refused root@orangepipc:~# iperf -c 10.111.111.11 ------------------------------------------------------------ Client connecting to 10.111.111.11, TCP port 5001 TCP window size: 43.8 KByte (default) ------------------------------------------------------------ [ 3] local 10.111.111.73 port 56344 connected with 10.111.111.11 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 10.111.111.80 port 5001 connected with 10.111.111.11 port 53540 [ ID] Interval Transfer Bandwidth [ 4] 0.0-10.4 sec 11.6 MBytes 9.41 Mbits/sec root@orangepipc:~# iperf -c 10.111.111.11 ------------------------------------------------------------ Client connecting to 10.111.111.11, TCP port 5001 TCP window size: 43.8 KByte (default) ------------------------------------------------------------ [ 3] local 10.111.111.73 port 56346 connected with 10.111.111.11 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 ...
  17. 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 !!!
  18. Hi Tkaiser, Were those integrated into Armbian patching process or should I try to apply them manually ?
  19. 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 ...
  20. 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.)
  21. I got those errors while playing with 4.5.0-rc6+. USB needs "twin-resets", both EHCI and OHCI. I had to patch the kernel with those patches from Hans : https://github.com/jwrdegoede/linux-sunxi/commit/0c28f012ac570a1a301503cee21734954495ab3b https://github.com/jwrdegoede/linux-sunxi/commit/22da4ea5fd499a77d44ed6ed013671963b7e5138 https://github.com/jwrdegoede/linux-sunxi/commit/bce1da6ba9eac77109099b8026128b5e1c44480a
  22. Do you mean with 4.4.x ? While doing some tests on my Olimex-Micro-A20, I've discovered that it was required there too. Maybe you had older version. This "spidev_dt_ids" list has been added in Mainline around November, I think. Before that, it wasn't required.
  23. For making SPI working, not only DTS need to be patched, but also the SPIdev driver itself to become HW SPI friendly. --- a/drivers/spi/spidev.c +++ b/drivers/spi/spidev.c @@ -695,6 +695,7 @@ static struct class *spidev_class; static const struct of_device_id spidev_dt_ids[] = { { .compatible = "rohm,dh2228fv" }, { .compatible = "lineartechnology,ltc2488" }, + { .compatible = "allwinner,sun4i-a10-spi" }, + { .compatible = "allwinner,sun6i-a31-spi" }, {}, }; MODULE_DEVICE_TABLE(of, spidev_dt_ids); Here is in attachment my updated patches ... BTW, to be able to submit those patches to Mainline in a near future, I had to do the same exercise directly on 4.5.0-rc6+, which I finally succeeded yesterday. (I still other issues with this 4.5.0-rc6+, but not related to my patches themselves) EDIT : The 4.5.0 has been released last Sunday, so I guess I will need to merge it again in the new 4.6.0-rcX branch ... ;-) orangepipc-patches.zip
  24. (quoting my self ...) While doing some tests on SPI from Python scripts, I figure out that there were bugs in orangepi_PC_gpio_pyH3-master, I've found them and fix them ! Since orangepi_PC_gpio_pyH3-master come from Olimex pyA20, I've decided to look there too, updating my Olimex A20-Micro, rebuild Armbian image, checking SPIs ... Same bugs, but also same issue of no SPI well defined in DTS for sun7i-a20-olinuxino-micro.dts ! I've some DTS edit, I hope to be able to prepare a patch for that too ..
  25. Unfortunately, my personal applications doesn't requires any needs from GPU, so I'm not the good guy to answer any thing here ...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines