martinayotte

  • Posts

    3891
  • Joined

  • Last visited

Everything posted by martinayotte

  1. I've received my OPi-Lite today ! I didn't get chance to follow every threads, is the RTL8189FTV soon be supported ? Also, I think a bug has been introduced recently : I've build tonight the image Armbian_5.14_Orangepilite_Debian_jessie_4.6.2.raw and it was hanging during boot : [ 7.575548] systemd[1]: Started udev Coldplug all Devices. [ 7.638570] systemd[1]: Mounting FUSE Control File System... [ 7.647639] systemd[1]: Mounted Configuration File System. [ 7.653293] systemd[1]: Starting Apply Kernel Variables... [ 7.670604] systemd[1]: Starting Create Static Device Nodes in /dev... [ 7.690248] systemd[1]: Starting Syslog Socket. [ 7.703836] systemd[1]: Listening on Syslog Socket. [ 7.713512] systemd[1]: Starting Journal Service... [ 7.722884] systemd[1]: Started Journal Service. [ 7.851371] systemd-udevd[227]: starting version 215 [ 8.339502] cpufreq: cpufreq_online: CPU0: Running at unlisted freq: 1008000 KHz I've then use the previous image I've built 2 weeks ago, at a time the image still common for all H3, the Armbian_5.12_Orangepih3_Debian_jessie_4.6.0.raw, and it booted properly.
  2. I think there should be some trade-offs somehow. That maybe why Wens suggested me to look at the "dynamic overlays" path, where basic pins will be present in mainline DT, but not activated a special peripherals until some overlays would be loaded.
  3. Hi @tkaiser, Unfortunately, this task isn't finished ... First, all my patches have been submitted to linux-sunxi mainline almost 3 months ago and nothing is merged yet. Several reasons lead to that : patches format, email issues, email headers corrupted, this last one is been solved/workarounded recently : Maxime Ripard told me that my tests using "git send-email" worked but earlier tests with "msmtp" didn't. I should now resend my patches soon as "v5"... Then, still the goal of the patches : kernel gurus which to avoid to beef up DTS, want to keep them as little as possible, claiming it take time to parse it (ridiculous statement here since we are not using 8bits MCU), and peripherals such I2C/SPI should not be enabled on all boards by default, stealing GPIOs (well, there so much GPIOs, is that really important to save them ?). @Wens suggested me strongly to go with overlays like C.H.I.P guys did. So, this is a new task for me : getting familiar with Dynamic Overlays loaded from UserSpace ! I will have to study that , recompile new kernel of the OF flag, tests, overlay prototypes, etc. I hope to met expectation, especially that "time is the missing ingredient" ! Ciao !
  4. Maybe I've been missing something, but to extract the patches from git only requires to do a "git format-patch" with a revisions range.
  5. I don't know if it is related to legacy (I would have to reinstall it to check), but on Mainline, there is no such w1-sunxi driver, only w1-gpio/w1-therm are required. Maybe you can try to comment out the w1-sunxi in /etc/modules-load.d/modules.conf and try again.
  6. Absolutely ! (if both SDCards are the same size or if the new one is bigger than the old one.) Otherwise, you should use the method described in the other thread.
  7. The general idea is to first get the bootloader written in the first sectors. So, TKaiser suggestion to "dd" the first 1MB is accomplishing this task. The second step is to have the partition sized properly with the SDCard size, so either fdisk or gparted can do that, deleting the partition and re-create new one that fit on the card. Third step is to format this partition, either mkfs.ext4 or gparted can be used. Fourth step is actually copying the whole rootfs from the orinal SD to the new one, to do that, both needs to be mounted, then a "tar piped in a tar" or "rsync" will copy the whole thing. Last step is to make sure to securely umount sdcards. Then, enjoy your backup ... :-)
  8. Maybe I could help here, if it is not tasks above my capacities. I could help on the DTS for example if something is missing.
  9. In my case, I'm using the https://github.com/duxingkei33/orangepi_PC_gpio_pyH3 derived from pyA20 from Olimex, but I didn't verified all the Pin GPIOs mapping.
  10. I've done some patches several weeks ago : http://forum.armbian.com/index.php/topic/617-wip-orange-pi-one-support-for-the-upcoming-orange-pi-one/page-10#entry5945
  11. Yes, that is the way to do, using dtc to decompile/recompile the dtb.
  12. Why do you say that H3 doesn't support device tree yet ? It does, but not using Legacy ! But maybe you mean it doesn't support "overlays" yet ...
  13. Also, I don't think RTL8192 would be any help here, as you mentioned "148f:7601 Ralink". This driver is part of the Mainline, but I don't think it is part of Legacy. /lib/modules/4.4.5-sunxi/kernel/drivers/net/wireless/mediatek/mt7601u/mt7601u.ko
  14. Are you running Legacy or Mainline ? In mainline, only the UART0 is exposed in the DTS. I've submitted a patch to linux-sunxi to have UART1/2/3 exposed (along with I2Cs), but they didn't merge my patch yet. https://groups.google.com/forum/#!topic/linux-sunxi/pON_W0tlI3g
  15. Personally, with my OPi-PC with Armbian 5.05, I've have no problem with smbclient connecting to Win7 shares, as long as I use proper credential ...
  16. Why are you using "-U%" ? Do you have the "armbianen" user existing on the Win7 machine ? Simply replace that with "-U <existing_win7_user>" ...
  17. I have 8188eu too, works without any glitch, even with Mainline kernels !
  18. For the kernel 4.x.x, the DTS for most UARTs except 0 and 1 were disabled. I've done a patch and submitted it to linux-sunxi mainline : https://groups.google.com/forum/#!topic/linux-sunxi/yYs-9KBrVEg You can do the same on your side, it will allowed the UART3/4/5 ... For the ttyAMA0, you can create a udev rules that will create that for you. On my side, with a zwave.me USB dongle, I've done that to create an even easier named symlink : /dev/zwave SUBSYSTEM=="tty", ATTRS{idVendor}=="0658", ATTRS{idProduct}=="0200", SYMLINK+="zwave", GROUP="martin", OWNER="martin"
  19. @tcmichals, I've posted a I2C+UART patch to linux-sunxi to get it into Mainline, but it could take awhile before getting it approved. You can grab it from there : https://groups.google.com/forum/#!topic/linux-sunxi/yYs-9KBrVEg For the SPI, I'm still struggling with it before submit, it was working fine under 4.4.5, but got terribly slow under 4.6.0-rc1, I don't know why, it is not related to my patches. In case you still wish them, it was originally posted there : http://forum.armbian.com/index.php?app=core&module=attach&section=attach&attach_id=162 ( from thread page-10, http://forum.armbian.com/index.php/topic/617-wip-orange-pi-one-support-for-the-upcoming-orange-pi-one/page-10 ) For the CPU/Therm, I don't know, I didn't investigate or try something out.
  20. Good to know ! Maybe I've messed up somehow with my own built kernel ... I will have to redo a new build soon.
  21. I means, this is only to diagnose/narrow if the issue was that eth0 was hanging during the apt-get.
  22. Did you tried with a WiFi dongle instead of eth0 ?
  23. Hopefully, the new commit from montjoie will fix all the remaining issues. (Because, I'm currently unable to make it work again with eth0 standalone, without any wlan0, I'm getting some "sun8i-emac 1c30000.ethernet: Re-run RX DMA 40000002")
  24. @ccfiel, Yes, the way you've installed my DTB was the good way (except the path is /boot/dtb/ ). BTW, I'm always keep backups of previous DTBs and use symlink to point to new one. Since I'm still using a WiFi dongle, maybe I've accidentally forgot to reapply the Ethernet patches. Let me check and I will resend new ZIP. EDIT : For the Ethernet, it is a bit strange ... I've looked and the patches were there. But I will investigate, also since I saw that Igor pushed new patches earlier today.