martinayotte Posted November 21, 2016 Posted November 21, 2016 Yes, I've read the irclog you've provided. I don't know why it should not have been done that way in first place. Something Mainline gurus are taking shortcuts ... ;-)
dgp Posted November 22, 2016 Posted November 22, 2016 I haven't tested Icenowy's branch so I don't know if it works but it's basically the same thing. I just added code to get the interrupt pin from the device tree node and the "platform" code for the driver to toggle the power etc. The platform stuff shouldn't actually be needed. A regulator in the mmc node and a pwrseq node in the device sub node is the right solution and that does work but I thought that could be causing the firmware crash so I implemented that stuff. With the platform code you can unload the module and reload the module which is faster than rebooting to test. I'm working on cleaning up the driver. For example they've been lazy in a few places and are using global variables to move state around instead of properly allocating the structures for that instance of the device. At the moment you couldn't have two chips connected for example. That doesn't matter for the pi zero but because they have global variables in the module instead of doing the setup of the device in the probe function called by the sdio subsystem in the kernel they are doing unneeded synchronisation between the sdio probe function and the module init function. They are also passing around a struct with function pointers to the sdio bus functions which would make sense if the chip had alternative interfaces but other parts of the code rely on the interface being sdio so it's totally useless. And their debugfs code doesn't unregister correctly so once the module unloads if you access anything in debugfs it causes a kernel panic... I don't have much time to work on this so it'll probably be a few weeks before I have something that is relatively clean and works. 1
tkaiser Posted November 22, 2016 Posted November 22, 2016 @dgp: Thank you for sharing your work and insights. Since I already damaged partially my OPi Zero I can't continue with Wi-Fi but in case any of the Armbian devs wants to give it a try I would currently rely on your repo. On the other hand providing 'beta' images with mainline kernel for those H3 devices did not led to that much useful feedback (to improve things) it's more or less wasting time (now).
wanab33ninja Posted November 22, 2016 Posted November 22, 2016 @tkaiser: I have 17 opi zero boards, happy to do any tests for you or anyone else to get this platform working. I am working on a remote solar powered IoT setup.
dgp Posted November 23, 2016 Posted November 23, 2016 @tkaiser: I have 17 opi zero boards, happy to do any tests for you or anyone else to get this platform working. I am working on a remote solar powered IoT setup. Unless you need SPI (which is planned for 4.10 apparently) you should be able to do everything you want with the mainline kernel and the current xradio driver. Once SPI is supported it should be possible to put a very small rootfs (buildroot generated or similar) on the SPI flash and have a system that that's a bit more reliable than a complete linux distro running on SD cards. 1
wanab33ninja Posted November 23, 2016 Posted November 23, 2016 @dgp I don't need SPI, mainline + wifi is all I need. I tried the image posted by tkaiser and the image on the armbian page. Both failed for me (after I sign in for the first time, and change my password, it reboots. Then when I try to sign in again, it locks up and reboots). I have a ttl adapter, so I can post the messages if you'd like. Otherwise, is there another image that I can try out? I looked at building it myself, but there's no config file in the repo for the orange pi zero.
wanab33ninja Posted November 23, 2016 Posted November 23, 2016 I was able to ctrl C right after I logged in with my new root password for the first time. Here's the traceback (on Armbian_5.24.161122_Orangepizero_Ubuntu_xenial_3.4.113) Password: Last login: Wed Nov 23 00:17:47 UTC 2016 on ttyS0 ^CTraceback (most recent call last): File "/etc/update-motd.d/40-updates", line 139, in <module> refreshdata() File "/etc/update-motd.d/40-updates", line 101, in refreshdata if not (depcache.marked_install(pkg) or depcache.marked_upgrade(pkg)): KeyboardInterrupt .[0;31mThank you for choosing Armbian! Support: .[1m.[39mwww.armbian.com.[0m Creating new account. Please provide a username (eg. your forename):
lanefu Posted November 24, 2016 Posted November 24, 2016 Quite the opposite, I think you would have to tweak code to be able to use WiringOP with this board. Please have a look through https://github.com/BPI-SINOVOIP/BPI-WiringPi/commit/149207ce9dd8eccc17fb38951f03246f1390c90c (the adoptions BPi folks made to WiringPi after they discovered that their 40 pin header has different mappings) http://tech.scargill.net/size-matters-neo-air/#comment-26973 (me trying to explain stuff I never used) $Someone with all the H3 boards on his desk could maybe provide an universal WiringOP lib? Is there a H2 datasheet floating around like the awesome H3 datasheet that has all the possible pin functions etc? I got some zeros in the other day and I'm going to see if i can make my WiringPi-Python-OP build work with it... which i think means i'll go ahead and fork WiringOP this weekend and take a stab at it. Also i noticed (as you mentioned on another post) that bin2fex fails on the zero fex. Should I try to find an older bin2fex or newer?
tkaiser Posted November 24, 2016 Posted November 24, 2016 which i think means i'll go ahead and fork WiringOP this weekend and take a stab at it. Also i noticed (as you mentioned on another post) that bin2fex fails on the zero fex. Just take latest version from github repo since I changed all 'machine' entries in there to be compatible with mainline kernel. Reason behind: stop producing yet another WiringOP library, join development efforts and produce a single lib suitable for all H2+ and H3 boards: http://tech.scargill.net/banana-pi-m2/#comment-27946 What about forking WiringOP one last time, adding board auto detection (@jernej's read_fex code works flawlessly -- when executed as root) and creating one package that will be installed on sun8i boards automagically? IMO we're not that far away from that since in linux-sunxi and FriendlyARM wiki pin headers are documented (only exception the 'great' Banana Pi M2+), the fex changes to detect the board at runtime are already there so only someone who knows what he's doing (definitely not me if it's about GPIO low-level stuff) is needed to get the job done? Maybe creating a task for this so that others might be able to contribute in a reasonable way? Please see in the aforementioned thread in a few comments above for links to expansion header pin mappings and here for OPi Zero schematics (H2+ is just a stripped down H3, no GbE MAC and no 4K HDMI output are the known exceptions so far). 1
manuti Posted November 24, 2016 Posted November 24, 2016 Orange boys are very busy nowadays new add-on board for 2$ for the Orange Pi Zero https://es.aliexpress.com/item/New-Orange-Pi-Zreo-Expansion-board-Interface-board-Development-board-beyond-Raspberry-Pi/32770665186.html?detailNewVersion=&categoryId=200004017 2
tkaiser Posted November 24, 2016 Posted November 24, 2016 On 24.11.2016 at 5:08 PM, manuti said: Orange boys are very busy nowadays new add-on board for 2$ for the Orange Pi Zero Sweet! I hope the pins on the TRRS jack are still the same (and the AV cable they sell is still wrong in the same way as before ) The next such HAT should add 2 JMS568 USB-to-SATA bridges and provide one normal SATA jack and one mSATA: The Zero NAS 1
zador.blood.stained Posted November 24, 2016 Posted November 24, 2016 @jernej's read_fex code works flawlessly -- when executed as root Since I don't see immediate issues with reading stuff, we may add udev rule to change ownership for the sysfs path to allow accessing this from non-root user. 1
lanefu Posted November 24, 2016 Posted November 24, 2016 Just take latest version from github repo since I changed all 'machine' entries in there to be compatible with mainline kernel. Reason behind: stop producing yet another WiringOP library, join development efforts and produce a single lib suitable for all H2+ and H3 boards: http://tech.scargill.net/banana-pi-m2/#comment-27946 What about forking WiringOP one last time, adding board auto detection (@jernej's read_fex code works flawlessly -- when executed as root) and creating one package that will be installed on sun8i boards automagically? IMO we're not that far away from that since in linux-sunxi and FriendlyARM wiki pin headers are documented (only exception the 'great' Banana Pi M2+), the fex changes to detect the board at runtime are already there so only someone who knows what he's doing (definitely not me if it's about GPIO low-level stuff) is needed to get the job done? Maybe creating a task for this so that others might be able to contribute in a reasonable way? Challenge Accepted. WiringOtherPi here we come... As you know I only barely know what I'm doing, but there's plenty of bright minds to steer us straight. I'll scribble some things and kick off a task. I need to do some groking on how much different GPIO stuff is or isn't with mainline 1
tkaiser Posted November 24, 2016 Posted November 24, 2016 Since I don't see immediate issues with reading stuff, we may add udev rule to change ownership for the sysfs path to allow accessing this from non-root user. Great. And access to GPIO stuff could be done the same way (members of group 'gpio' have access and maybe 1st user will be added to this group automagically). I'll scribble some things and kick off a task. I need to do some groking on how much different GPIO stuff is or isn't with mainline This is something we need @martinayotte to jump in as well. He already provided patches to add I2C and SPI with mainline kernel as DT overlays. Maybe there's more stuff needed but it would be really great to start this in an organized way. My (naive) assumption is that it should be possible to get this as easy as with RPi + Raspbian now to use at least those cheap H2+/H3 devices for this IoT/sensor/actor/whatever stuff without headaches. Regardless of kernel version or device in question
jernej Posted November 24, 2016 Posted November 24, 2016 I need to do some groking on how much different GPIO stuff is or isn't with mainline GPIO sysfs interface should be the same on both, mainline and BSP, kernels. I checked that a month or so back. I think the only work which needs to be done here is identifying differences between the boards and implement this in a sane way. 2
lanefu Posted November 24, 2016 Posted November 24, 2016 Alrighty -- WiringOtherPi task thread here 1
dgp Posted November 25, 2016 Posted November 25, 2016 Refactoring (Fix the structure and back filling the existing code until it works) the xr819 driver is taking some time so I have created a branch that incorporates some changes that make the driver work properly with a DT based system and added some usage instructions: https://github.com/fifteenhex/xradio/tree/original Aside from that a mainline based branch that has a DT for the pi zero and has working ethernet etc is available here: https://github.com/fifteenhex/linux/tree/orangepizero I will add a defconf for the pi zero sometime today. Uboot with a defconf for the pi zero is here: https://github.com/fifteenhex/u-boot/tree/orangepizero 1
tkaiser Posted November 25, 2016 Posted November 25, 2016 Great news: linux-sunxi community got boot from SPI NOR flash to work: http://linux-sunxi.org/Orange_Pi_Zero#Mainline_U-Boot Apritzel also managed to hack the function of the 'power button' to become a FEL button instead (so you're able to boot from SD card by pressing the button even if a 'firmware' is already stored in SPI flash -- useful only for OPi PC 2 now since Zero is missing the button). What's missing still? SPI NOR flash soldered on the Zero by default as it's already the case with OPi PC 2. So please make some noise to convince Xunlong soldering the same 16 Mb (2 MB) flash on the Zero starting with next production batch. Please leave feedback in OrangePi forum and on Aliexpress! 2
farrukh Posted November 26, 2016 Posted November 26, 2016 Got mine delivered (Lahore, Pakistan) earlier this week but only just managed to test it. Everything is running smooth so far except wifi which has huge latency problem. Tried disabling power management but no luck. I know it's just early days with xradio driver but is this known issue? Some info and ping results: zero@orangepizero:~$ sudo iwconfig wlan0 IEEE 802.11bgn ESSID:"XS 2.4G" Mode:Managed Frequency:2.462 GHz Access Point: xx:xx:xx:xx:xx:xx Bit Rate=39 Mb/s Tx-Power=20 dBm Retry long limit:7 RTS thr:off Fragment thr:off Encryption key:off Power Management:off Link Quality=60/70 Signal level=-50 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:54 Invalid misc:0 Missed beacon:0 ping 192.168.5.174 64 bytes from 192.168.5.174: icmp_seq=0 ttl=64 time=3562.208 ms 64 bytes from 192.168.5.174: icmp_seq=3 ttl=64 time=546.935 ms 64 bytes from 192.168.5.174: icmp_seq=4 ttl=64 time=1003.713 ms 64 bytes from 192.168.5.174: icmp_seq=5 ttl=64 time=587.229 ms
dgp Posted November 26, 2016 Posted November 26, 2016 I know it's just early days with xradio driver but is this known issue? Which version of the xradio driver? Anyhow you are probably missing interrupts.
farrukh Posted November 26, 2016 Posted November 26, 2016 Which version of the xradio driver? Anyhow you are probably missing interrupts. The one that came with latest Armbian: zero@orangepizero:~$ sudo modinfo xradio_wlan filename: /lib/modules/3.4.113-sun8i/kernel/drivers/net/wireless/xradio/xradio_wlan.ko alias: xradio_core license: GPL description: XRadioTech WLAN driver core author: XRadioTech depends: mac80211 intree: Y vermagic: 3.4.113-sun8i SMP preempt mod_unload modversions ARMv7 p2v8 parm: macaddr:First MAC address (charp)
tkaiser Posted November 26, 2016 Posted November 26, 2016 To improve Wi-Fi situation with legacy kernel someone knowledgeable with an interest in Wi-Fi should work through https://forum.armbian.com/index.php/topic/2808-orange-pi-zero-went-to-the-market/?p=20329 then backport all changes to Allwinner's 3.4 release and send a pull request. I fear no one from Armbian 'core team' will do due to lack of time/interest/ressources.
dgp Posted November 26, 2016 Posted November 26, 2016 The one that came with latest Armbian: It's probably a problem with interrupts. I suspect the latency you are seeing is because interrupts aren't waking up the driver so it's only reading data when it wakes up when waiting for an interrupt or tx event times out. Take a look at /proc/interrupts. I think with the legacy kernel the wifi interrupts might be grouped with MMC1.
farrukh Posted November 26, 2016 Posted November 26, 2016 It's probably a problem with interrupts. I suspect the latency you are seeing is because interrupts aren't waking up the driver so it's only reading data when it wakes up when waiting for an interrupt or tx event times out. Take a look at /proc/interrupts. I think with the legacy kernel the wifi interrupts might be grouped with MMC1. zero@orangepizero:~$ cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 10: 1412 0 0 0 sunxi_gpio_irq_chip xradio_irq 29: 15485 12709 32435 5753 GIC arch_timer 30: 0 0 0 0 GIC arch_timer 32: 519 0 0 0 GIC uart0 38: 24 0 0 0 GIC twi0 39: 18 0 0 0 GIC twi1 43: 0 0 0 0 GIC PA 49: 1412 0 0 0 GIC PG 50: 0 0 0 0 GIC sunxi_timer0 63: 0 0 0 0 GIC Thermal 69: 0 0 0 0 GIC sunxi-ir 72: 0 0 0 0 GIC sunxi-rtc alarm 77: 0 0 0 0 GIC PL 81: 0 0 0 0 GIC arisc_hwmsgbox_irq 82: 0 0 0 0 GIC sunxi_dmac 90: 0 0 0 0 GIC cedar_dev 92: 34964 0 0 0 GIC sunxi-mmc 93: 40990 0 0 0 GIC sunxi-mmc 97: 0 0 0 0 GIC spi0 104: 0 0 0 0 GIC ehci_hcd:usb1 105: 0 0 0 0 GIC ohci_hcd:usb5 106: 0 0 0 0 GIC ehci_hcd:usb2 107: 0 0 0 0 GIC ohci_hcd:usb6 108: 0 0 0 0 GIC ehci_hcd:usb3 109: 0 0 0 0 GIC ohci_hcd:usb7 110: 0 0 0 0 GIC ehci_hcd:usb4 111: 0 0 0 0 GIC ohci_hcd:usb8 114: 5 0 0 0 GIC gmac0 IPI0: 0 0 0 0 CPU wakeup interrupts IPI1: 0 0 0 0 Timer broadcast interrupts IPI2: 3202 25919 2854 3949 Rescheduling interrupts IPI3: 141 161 38 162 Function call interrupts IPI4: 1 3 5 1 Single function call interrupts IPI5: 0 0 0 0 CPU stop interrupts IPI6: 0 0 0 0 CPU backtrace IPI7: 0 0 0 0 completion interrupts Err: 0
Vasim Valeev Posted December 1, 2016 Posted December 1, 2016 It's probably a problem with interrupts. I suspect the latency you are seeing is because interrupts aren't waking up the driver so it's only reading data when it wakes up when waiting for an interrupt or tx event times out. Take a look at /proc/interrupts. I think with the legacy kernel the wifi interrupts might be grouped with MMC1. I have same issue (ping through WiFi ranges from 1 to 500 ms). People did found a solution - repeating ping with high frequency (20 small pings per second or more - "ping -s 1 -i 0.05 <orange-ip>"). Seems like a stupid incoming packets grouping in the driver to save power by processing large number of packets at once.
farrukh Posted December 1, 2016 Posted December 1, 2016 Designed a case for it. Available on thingiverse if anyone interested - http://www.thingiverse.com/thing:1918590 12
willmore Posted December 2, 2016 Posted December 2, 2016 I like the case! I just printed one. I flipped the colors. Seemed more sense to make the orange design in orange. I had to do a little trimming on the antenna hole and around the USB jack--near the back, mine have a fold that sticks out a tiny bit, maybe 0.2 or 0.3mm. 30 seconds with a hobby knife and it fit together just fine. I used M3x8 self tapping screws instead of machine screws--because I have a ton. They worked just fine. I would like you post, but I just signed up for the forum to make this reply and I guess the forum doesn't trust me with that kind of power, yet. So, here's my verbal thumbs up to you!
dewabrata Posted December 2, 2016 Posted December 2, 2016 hi all im very beginner for orange pi zero, in this board there is no hdmi port, so how i can view for display the first installation? many thanks for the response and help
Igor Posted December 2, 2016 Posted December 2, 2016 hi all im very beginner for orange pi zero, in this board there is no hdmi port, so how i can view for display the first installation? many thanks for the response and help You should go for OPi One or similar board if you need HDMI ... but you only need a display or better, serial console, only in case of troubles. Attach to network, look for boards IP on router and connect via SSH. Just check documentation. 1
dewabrata Posted December 2, 2016 Posted December 2, 2016 You should go for OPi One or similar board if you need HDMI ... but you only need a display or better, serial console, only in case of troubles. Attach to network, look for boards IP on router and connect via SSH. Just check documentation. Thanks for your help, maybe I want to get the information is how I can set the console, or connect with a vnc, if orange pi zero do not have a port for video output such as for example hdmi port or video port, of course I cant do nothing without user interface. thanks fot your help
Recommended Posts