glow

Oh, I hadn't realized it was so closely related to the Orange Pi 2G-IOT. Out of curiosity I'll take a look at that, but since it may not make it to an armbian supported board my interest may fade quickly. I like my armbian systems. :-) Thank you for the input … and thanks for showing me where to ask generic questions like this.

First, I apologize if this is the wrong section of the forum for this question. I will keep watch on the response and learn for future posts. I apologize if I got it wrong. I was looking at Orange Pi devices on aliexpress and noticed the "Orange Pi i96 256MB Cortex-A5 32bit with WIFI and Bluetooth". Looks like a cool device, but I haven't found mention if it in the forum and it's not in the downloads section ... Will the Orange Pi i96 be included as a target device? And will the on-board WiFi be a disaster like the Orange Pi Zero on-board WiFI, or is it possible the i96 on-board WiFi will be usable? I really hope they learned from the zero and chose a better chipset.

@nopnop2002 - does your configuration work for more than 20 minutes when running some sort of graphic program? My original setup would work well too, but then after awhile (8-20 minutes) it would crash. In my case I was running a pygame program.

I had a problem like this too and never found a solution using legacy. However, moving over to mainline worked for me. My displays have been running for months without crashes. There are caveats however - it didn't work out of the box, But, there are some good threads in this forum where a few people helped me and others get up and running. Search "pygame lcd" and you'll find the threads. It took some time and several tries I almost gave up, but I finally got it working. Try it, and post your progress in the forum. I'll come back in a few days and see if there is anything I can contribute. You might get lucky and the smart people who helped me might chime in first. I wish you luck! Stay with it, it'll be worth it and you'll be able to keep armbian.

That's good news. I realized I could/should have looked this up myself in the data sheets, but I wanted to be certain before I bought a zero 2. Thank you. It looks like I can get the zero 2 on aliexpress with an H3 or H5. So many choices.

Did they improve the wifi on the orange pi zero plus 2, or does the wifi have the same problems as the orange pi zero?

Nice work @adrb! Thank you for taking the time to capture the information. It'll be very useful.

@adrb A tutorial would be greatly appreciated. Since mainline topics are now separated from legacy it'll be much easier to find. I suggest starting a new thread in h2 & h3 mainline section (the section this thread is in) and go from there. And thank you!

I'm not sure if this is relevant, but I recently had to start using mainline on my orange pi zero since pygame was constantly crashing with legacy. Of course, the onboard wifi isn't available in this release so I started to test the usb wifi gadgets I had on hand. Some failed miserably. However the COMFAST CF-WU810N 2.4GHz 802.11b/g/n works like a charm. No additional drivers necessary. Just configure wifi. I've very pleased with the functionality and performance of my current setup and wanted to mention that it's very well for me. One noteworthy item, however. To get the wifi device to be called wlan0 rather than a long name with the address in the name I created the following link and rebooted: sudo ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules armbian mods and developers -- thank you for providing mainline. I understand it's experimental and a never-ending cause for painful reiterations of similar problems, but for my personal projects it's working well. I had hit a dead-end with legacy and mainline has been solid for some time now. Also, I like the separation of mainline on the forum. I think that's a big win.

If you are using mainline I have a suggestion. If you're using legacy, this doesn't apply. In another thread @ldiaz helped me get an spi display working. The solution was to add the following to the end of /boot/armbianEnv.txt and reboot. overlays=spi-spidev param_spidev_spi_bus=1 But like I said, this is for mainline, not legacy.

This is not directly relevant, but I wanted mention something as a follow up. My immediate goal is to use the display as output (no input needed). When I tried running my pygame programs I got the following message and my pygame programs would not run. pygame.error: Unable to open mouse Since I don't care about a mouse [at this time] I added a line after the device identifier and it seems to be working: os.putenv('SDL_FBDEV','/dev/fb0') os.putenv('SDL_MOUSEDEV', '/dev/null') # workaround for unable to open mouse error pygame.init() If this is really dumb, please let me know. For now, I'm back to being a kid in a candy shop.

I thank you too @ldiaz. Like @a-p I added overlays=spi-spidevparam_spidev_spi_bus=1 to armbianEnv and when I modprobe (using busnum=1 l like you said ) I got a console window on my display. Progress! I appreciate your sticking with us on this. I was about to give up.

I used different hardware, including a brand new opi zero that looks to have spi flash but it behaves the same; Briefly, using a mainline image, apt-get update/install, and install python-pygame. After modprobe using bus 0 the backlight on the display lights up, but nothing I do after that shows up on the display.. It remains white. My goal is to get pygame to display (I don't want to X windows), and I'm not interested in input at this time. I only want to display information. I've tried to add the overlay information as suggested to armbianEnv in /boot, tried busnum 1 (error) as well as 0 (creates /dev/fb0), and tried con2fbmap. When using legacy pygame scripts work. I'll retry the suggestions made by @ldiaz to be sure I haven't overlooked anything. Hopefully I'll find a step I overlooked and it'll start working.

I'm comfortable in nix environments, but overlays are new to me. I last recall using 'overlays' on a heathkit with 4k ram, but that's a different story. I've verified my pin connections - they are identical to yours. Since I'm new to overlays I followed your earlier message and added the following to the end of /boot/armbianEnv.txt overlays= <other overlays> spi-spidev param_spidev_spi_bus=1 After reboot there are no /dev/sp* devices. (there weren't any before the reboot either, perhaps the /dev/spi* devices are specifically tied to spi memory, and not the spi bus??? at no time do I have an /dev/spi* entry) modprobe fbtft_device custom name=fb_ili9341 gpios=dc:0,led:3,reset:1 speed=16000000 busnum=1 rotate=0 bgr=1 generates an error modprobe: ERROR: could not insert 'fbtft_device': Invalid argument and dmesg shows: [ 112.942447] fbtft: module is from the staging directory, the quality is unknown, you have been warned. [ 112.949365] fbtft_device: module is from the staging directory, the quality is unknown, you have been warned. [ 112.951171] spi spi0.0: spi-nor spi0.0 10000kHz 8 bits mode=0x00 [ 112.951279] fbtft_device: spi_busnum_to_master(1) returned NULL [ 112.957422] fbtft_device: failed to register SPI device if I then change busnum=0 in modprobe it works and dmesg shows [ 144.264907] fbtft_device: module is from the staging directory, the quality is unknown, you have been warned. [ 144.266482] spi spi0.0: spi-nor spi0.0 10000kHz 8 bits mode=0x00 [ 144.266595] spi spi0.0: Deleting spi0.0 [ 144.267381] fbtft_device: GPIOS used by 'fb_ili9341': [ 144.267390] fbtft_device: 'dc' = GPIO0 [ 144.267396] fbtft_device: 'led' = GPIO3 [ 144.267402] fbtft_device: 'reset' = GPIO1 [ 144.267419] spi spi0.0: fb_ili9341 spi0.0 16000kHz 8 bits mode=0x00 [ 144.282605] fb_ili9341: module is from the staging directory, the quality is unknown, you have been warned. [ 144.635818] Console: switching to colour frame buffer device 30x40 [ 144.637480] graphics fb0: fb_ili9341 frame buffer, 240x320, 150 KiB video memory, 16 KiB buffer memory, fps=20, spi0.0 at 16 MHz I have another brand new zero so my next step is use it with another display and a fresh mainline image and see if I get the same results. I remember my excitement when I used the same hw with a legacy image and it worked like a charm. Too bad the programs would crash after running for a substantial period of time.

@ldiaz I'm not sure how to explain my results with busnum -- my zero does not have spi flash on it (the space for the chip on the back is empty). Does your zero have spi flash memory?

You are not hijacking the thread at all! Your experience is very close to mine, and I started this thread. In your case, have you tried to use busnum=0? Modprobe completes without errors for me with busnum 0 works, but not busnum 1.

@ldiaz - you had to install notro's fbtft in mainline? I've been trying to get things to work with the fb included in the distro. Since I could get the backlight to respond with modprobe and the messages looked like it created a good /dev/fb0 I thought it was okay as-is. If you added notro's fbtft, would you tell me specifics on what you added (which src/bin's you downloaded and installed)?

Touch is possible, but not something I did in any of my projects. There are additional pins on the display for touch that will need to be connected, and if you use x windows the display may need to be calibrated.

My 2.4" il9341 display has the following connections. I've used legacy and have this display 2.4"" 240x320 SPI TFT LCD Serial 240*320 ILI9341 pin 21 - miso 15 - led 23 - sck 19 - mosi 13 - dc 11 - reset 24 - cs 06 - gnd 01 - vcc

rlsten -- do you want info for legacy? I've got my 2.4" working well on that, but pygame won't run for long periods without throwing an error. That's why I'm moving up to the newer mainline environment with the current kernel. For legacy I did not need to make script.bin changes, only had to add python-pygame package, and no overlay work.

Thanks for the lead! But when I use busnum 1 I get an error modprobe: ERROR: could not insert 'fbtft_device': Invalid argument Using busnum 0 executes with no terminal messages, the backlight turns on and the screen is all white, and dmesg looks good. But I can't get any pygame programs to work even if I add os.putenv('SDL_FBDEV','/dev/fb0') before pygame.init(). Argh!

If I might ask a rather broad question -- has anyone got an il9341 2.4" TF display to work with mainline kernel on an orange pi zero? I can get the device to register with modprobe, and the backlight becomes active, but I haven't been able to get anything else happen to the display. I'm wondering just how far in over my head I am.

When I run pygame for any significant length of time on legacy kernel it crashes with a kernel timeout error. I haven't been able to get past this, and from what I tell, it should be fixed in later kernels. So, I'm trying my hand with the mainline kernel, and I have two hurdles I haven't been able to pass yet. I'm using an Orange Pi Zero, hardware Ethernet, mainline distro, with a 2.4" SPI TFT LCD. Frame buffer is /dev/fb0 created with modprobe fbtft_device custom name=fb_ili9341 gpios=reset:1,dc:0,led:3 speed=48000000 rotate=90 busnum=0 txbuflen=65536 Whenever I create a display I get an error that it cannot open mouse. The following toy world program: #! /usr/bin/env python import pygame screen = pygame.display.set_mode((320, 240)) while 1: pass returns: Traceback (most recent call last): File "./bar", line 5, in <module> screen = pygame.display.set_mode((320, 240)) pygame.error: Unable to open mouse Using the same hardware with the legacy distro does not give the same error. On larger programs I'm also getting a slew of ALSA messages too, but I'm not sure how critical they are. I'm hoping they're informational, but I'll look at them closer when I get past the mouse error. I'll include them here to be complete in case they are critical to the main issue: I know mainline is experimental and not supported, but since I've hit a dead-end on legacy I thought I'd work on this distro before moving to other systems. Please hit me up with any suggestions, or share the laugh with me if I'm doing something really dumb.