horai

Ok, you mean the display, that's the NOTRO driver, but I guess my note was about hardware 3D acceleration and most of the sites at the time I was trying to run it were claiming that hardware 3D acceleration is possible only with legacy kernel not with the mainline kernel. With legacy kernel, it's possible to accelerate 3D graphics and image it on ILI9431, but adding touch capability of the display was an issue for me.

Ok, great, thank you very much, as soon as possible, I'll try the mainline kernel for software GPIO chip select, hopefully it will work. I hope I'll find a tutorial, how to perform it, if you have a hint how to perform it or a link, I would be very grateful if you could share it. Hopefully the display will work with the new kernel, I'll sacrifice OpenGL acceleration. Anyway, with the ads7846_device module, I noticed it's not compiled as a module for the 3.4.113 kernel, therefore I downloaded the source code from https://github.com/notro/fbtft/wiki/fbtft_device. It also has a Makefile which looks like it is compiling it as a module and also installs it as a module to kernel directory.I ran modprobe for the module with only one exception that I had to put ./ in from of the module name and be present in the kernel directory with module, but the behaviour while loading was anyway strange.

For the display there is fbtft_device loadable module which chains the fbtft module and loads it automatically (when parameters of fbtft_device set up properly) I guess the same applies to touch layer via https://github.com/notro/fbtft_tools/wiki/ads7846_device where all the parameters are specified. which probably loads the module ads7846 automatically, I guess my problem is that I have both attached to SPI0, but no CS is provided for touchscreen, data are probably mangled it it cannot register the module, but I also connected the touch layer alone as I have done with display and alone the display works, but touch device alone does not work, maybe I have set up CS incorrectly. SPI1 is of no issue as there is no PIN for MOSI and MISO pins exposed on the header, I did not notice, moreover I thought they both SPI0 and SPI1 can share MOSI, MISO lines, but this probably applies only to Master - Slave, not to two masters. So we end up on what you have said in the beginning that for this purpose we will need to multiplex SPI0_CS. Just one last question, it is not possible to tell kernel how to multiplex it in some configuration file, to assign CS=0 to screen and CS=1 to touch? If we would have 4 SPI devices, we would connect all their 4 CS hardware pins to Orange PI hardware pin PI SPI0_CS (pin 24) and tell the OS to multiplex it or we will assing some arbitrary 3 other hardware GPIO pins for CS1,2,3? According to the documentation, I did not see any other hardware pin to be possible to alternate the function of SPI0_CS of any enumeration, only PIN 24 (PC3) . If I understand all that correctly, the only way to run both these devices is to place their CS pins together on SPI0_CS hardware pin of Orange Pi and tell the kernel to multiplex CS on one hardware PIN 24 (PC3), is it correct?

I would love to use mainline kernel, but so far it will be way too much complicated for me as I have Mali400 hardware acceleration (I am not sure whether it is possible to have it on mainline kernel, some sites say yes, I even saw source code to build the driver) set up already. Moreove there is no stable release for OP Lite yet and I only need to resolve the touchscreen for me than I'll play with mainline on differend SD card.

Ok, just to sum it up. The device has 2x master SPI controller and to each master there are two SPI slaves therefore we have up to 4 CS, but we have two physical pins one PIN SPI0_CS1 (pin 8) and SPI1_CS0 (pin 24) (Raspberry which has two physical PINS SPI0_CE1(CS1) and SPI0_CE0(CS0), but only one master. In case we have 4 SPI devices for Orange Pi, we place all 2 CS pins from those SPI0_CS (pin 24) and the other 2 pins to SPI1_CS (pin 8), but 0 and 1 are multiplexed. In my case where I need to connect display driver and touchscreen driver, can't I connect display driver on SPI0 and touchscreen driver on SPI1? Chipselect set for both to 0 as they are each on different master? But from the 3.2 section I see that SPI1_CS is disconnected by default therefore I have to enable it and configure as function SPI1_CS, right? Because of the fact that the display worked, I think SPI0_CS works as CS for spi bus 0 by default. The key point for me is that ads7846_device kernel module has a parameter called 'bus' so I think I can tell kernel that it should seek for touchscreen on bus 1.The only thing I am worried about is that even though I load this module and also the module ads7846 via modprobe, no output comes out, no message in dmesg and also ads7846_device is not loaded in lsmod. Do you think that because it does not have CS connected, it does not register the module? What I don't understand is the two masters share MOSI, MISO, DO,DI? Sorry to ask stupid questions, but I am a newbie.

On this advertisement they also mention 2x chipselects: http://linuxgizmos.com/orange-pi-sbc-tempts-raspberry-pi-clone-fans/

Ok, I was confused by a pinout image I found for Orange Pi: https://github.com/rm-hull/luma.led_matrix/issues/27 There are SPI_CE0 and SPI_CE1, but on the picture, there is only one chip select depicted, I thought that there are SPI_CE1,2 are two chip selects, I thought that maybe the other one is configurable. Could you also please explain to me one more thing? In this documentation http://dl.linux-sunxi.org/H3/Allwinner_H3_Datasheet_V1.0.pdf page 454, there is reference to SPI and there is mentioned: Four chip selects to support multiple peripheral Polarity and phase of the Chip Select (SPI_SS) and SPI Clock (SPI_SCLK) are configurable That does not mean that there are no more chip selects? And if you type dmesg | grep spi, I get this output: lisunxi_spi_chan_cfg()1376 - [spi-0] has no spi_regulator. sunxi_spi_chan_cfg()1376 - [spi-1] has no spi_regulator.ke this: Please, could you also tell me why there is spi-0 and spi-1? I thought that it might have 2 SPI masters each with 2 slaves altogether 4 chipselects. Two slaves are sharing one master.

Dear all, were any of you able to run xpt2046 touchscreen touch controller? I am struggling to resolve it, I followed many hints but now I am stuck, here is my opened topic for what I have done so far, maybe it helps someone else. Thank you very much for all the help.

spi xp2046 device needs patching and recompiling even though SPI ili9341 works from scratch on the same board with spi xpt2046 which does not work? There is even a kernel driver ads7846 in kernel firmware package, I guess those are the proper externally compiled modules to the same kernel, just loadable, not packaged to the distribution due to space issues. I am a newbie so I don't see the reason why display on SPI is working and touchscreen on SPI is not working and needs a lot of extra work to be done. I opened a new topic about this here just to see what I have done so far. Thank you very much for all the help Best regards, Ivo

Dear all, I would like to kindly ask you for a help. My goal is to enable touchscreen. I was able to run the display according to this connection and command: MOSI - 19, MISO - 21, SCK (SPI_CLK) - 23, CS - 24, RESET, DC and LED - 11, 13, 15. power supply and ground as usual sudo modprobe fbtft_device custom name=fb_ili9341 gpios=reset:1,dc:0,led:3 speed=48000000 fps=25 rotate=90 bgr=1 txbuflen=65536 I understood that the pin layout is slightly different from Raspberry Pi and I have to follow pinout table on: https://linux-sunxi.org/Xunlong_Orange_Pi_One BUT I also wanted to touch layer to be working, therefore I installed package 'linux-firmware-image-sun8i' which contains driver ads7846 which should be compatible with xpt2046. Connected the touch and tft layer pins according to pin layout found for Raspberry PI : T_IRQ Panel Touch Interrupt = GPIO25 (corresponding to Orange Pi pin 22 = PA2) T_DO Touch Data Out = GPIO09 T_DIN Touch Data In = GPIO10 T_CS Touch Chip Select = SPI_CE1_N T_CLK Touch Clock = GPIO11 SDO (MISO) TFT Data Out SPI_MISO = GPIO09 LED Backlight GPIO18 -- see note (corresponding to Orange Pi pin 15 = PA3) SCK TFT Clock SPI_CLK = GPIO11 SDI (MOSI) TFT Data In SPI_MOSI = GPIO10 D/C TFT Data / Command = GPIO24 (corresponding to Orange Pi pin 13 = PA0) RESET Reset = GPIO23 (corresponding to Orange Pi pin 11 = PA1) CS TFT Chip Select = SPI_CE0_N = GPIO08 GND Ground = GND VCC 3V3 supply +3V3 And ran command sudo modprobe ads7846, but with no success I also followed page https://forum.armbian.com/index.php?/topic/1384-please-add-new-hardware/, compiling and installing ads7846_device, went to directory /lib/modules/3.4.113-sun8i/extra and ran command: sudo modprobe ads7846_device model=7846 cs=1 gpio_pendown=2 speed=2000000 keep_vref_on=1 x_plate_ohms=60 pressure_max=255 x_min=200 x_max=3900 y_min=200 y_max=3900 OR sudo modprobe ./ads7846_device pressure_max=255 y_min=190 y_max=3850 gpio_pendown=2 x_max=3850 x_min=230 x_plate_ohms=60 Again no success, therefore I tried to change T_CLK Touch Clock pin to pin 10 (PA14) T_CS Touch Chip Select to pin 8 (PA13) and I thought it requires SPI1 and repeated to commands, again no success. When I ran the TFT screen without touch layer pins connected, it works very good but with pins for touch layer connected even the display is not working, only LED backlight is on, moreover there is no modifo result for proper module parameters neither dmesg output when invoking modprobe related to both ads7846 and ads7846_device modules, I guess there might be some SPI devices collision, but I am SPI newbie. I guess no need to install overlays as this is legacy kernel with modules calling via command line. The display is OK, I tested both functionalities on different device. Thank you very much for any help Best regards, Ivo

Dear all, were you able to run the display touchscreen controller? I ran modprobe ads7846, but even dmesg yields nothing and there is no more device in /dev/input/

Thank you for prompt reply, I am using 5V power supply with 2.5A output, I guess this should be enough and standard HDMI cable. I am also running Raspberry on the same TV and cable with no problems even the Orange Pi works and I can work in console, I suspected Vim and X11 probably use something I am not familiar with, anyway, I'll try to use another cable, TV and power supply. All can be seen here: https://www.youtube.com/channel/UCofsIJz81fIkeltL4njHUhw I already tried h3-disp before posting this, I just want to exclude a failed unit.

Dear all, Recently I purchased Orange Pi Lite. I installed recommended Armbian with Legacy 3.4.113 kernel as there is no mainline image yet. When pushing the power button a logo appears, the screen goes black and after 10 seconds command prompt with login appears with no dmesg output on screen while loading kernel image and services that all is already loaded but no output shown. So far, I am happy with it, BUT when I run Vim command to open certain file, I see it opens the file and screen dimms in few seconds to complete darkness, the only way how to get out of this black screen is to switch to another console, when I switch back, it again appears and dimms to black as usual. The same problem I experience with X11. Has anyone experiences same problem? Do you happen to know what to cause might be? I suspect the TV does not communicate over HDMI properly and maybe the TV is going to some safe mode, but I guess it was designed for HDMI standard and so far I did not find anyone on the forum to experience at least similar problem, moreover I would somehow understand that running X11 could possibly cause some problems due to framebuffer and driver issues, but why Vim in console does the same problem? I also think that the blank booting process is also not properly done as any Linux distribution I used, I either has some boot screen or simply shows the booting process line by line, maybe it tries to use framebuffer but fails and does not fall back printing mode without framebuffer. Could any please give me a hint? I am going to find another TV to try it on. Thank you very much Best regards, Ivo

Hello, thank you very much, I did not handle SDL properly. Now it runs super fast hardware accelerated on this small display, only text textures are missing. Anyway, it's amazing what this hardware can do. Please, if you have some other more efficient way how to run this emulator (probably without X windows), me and I guess many other people would be very greateful for posting it. Thank you very much Ivo

Dear Sir, I am really excited by the capabilities of Orange Pi. I recently purchased Orange Pi Lite and wanted to reproduce running of the emulator depicted in your video, but I am really struggling to proceed any further with reasonable performance. Therefore I would like to kindly ask you for a help. I will briefly described my way. I am running Pi Lite on Armbian. I decided to compile Mupen64Plus this way: Before the standalone compilation, I installed the display according to your instructions finally obtaining /dev/fb8 as a display driver output. Then I installed Mali 400 hardware acceleration support via X11 following instructions here: http://linux-sunxi.org/Mali_binary_driver. I paid attention to installation of libdri2 which I think is necessary to obtain X11 fbturbo driver GLES acceleration.Anyway I ended up with compiled 'test' utility which was unable to draw mentioned triangles, anyway I proceeded to emulator compilation. I did this way: ./m64p_build.sh USE_GLES=1 NEON=1 to get GLES support, with a bit of tweaking and installing sdl 2.0, I was able to get the binaries. Without GLES the emulator runs on that tiny screen well, but it's very slow, probably not because of limited SPI framerate, but I guess because of lack of hardware acceleration but build with GLES=1 provides me binaries which refuse to run under X11. Anyway, the final error I got to is this: Core Error: SDL_SetVideoMode failed: GLX is not supported Video Error: Failed to set 32-bit video mode Core status: Rom closed Actually this output is with GLX option disable in X11, I guess GLX support is for pure OpenGL not for GLES, but somehow it's searching for GLX, maybe it's related to SDL layer only and X11 works correctly. I am running this emulator via X11 because I don't know whether it has support for DirectFB or anything else, but am I able to run this emulator in console with hardware acceleration via GLES? Anyway, maybe I have to recompile SDL with GLES support to proceed further with my error even though I have SDL2 which looks like it has support at least for OpenGL or maybe I am missing some essential piece of information or maybe I don't understand the matter fully and my way is not even possible. All Mali packages and Xorg packages, SDL are installed from repositories. Thank you very much Best regards Ivo