MitchD

Members
  • Content Count

    35
  • Joined

  • Last visited


Reputation Activity

  1. Like
    MitchD reacted to adrb in OrangePi Zero, mainline kernel, SPI LCD + touchscreen   
    It's simple guide, presenting how to setup LCD (ili9431) with integrated touchscreen (tsc2046) on mainline kernel (4.11). It may be not fully "armbian way", since I'm pretty new in armbian
     
    In case that somebody is interested, I recently bought couple those displays from here
     
    Few basic informations:
     
    1. OrangePiZero has two SPI buses. First one is usually occupied by build in memory. So we can only use bus1
    2. tsc2046 chip is fully compatible with ads7846, and we have drivers for it since years now
    3. Maximum clock frequency for ads7846 is 3.25Mhz, but don't expect that it will work with that.  Reasonable value is something beetween 0.5-2Mhz. Lower frequency, if you observing misbehavior.
    4. Probably most important information  ili9431 and tsc2046 poorly cooperate on shared bus. I don't know exactly why, because I don't have access to logic analyzer,  but it's proven fact (at least on my equipment). You have to lower bus frequency to 2MHz (highest common value), and even then it work very unstable.  My educated guess is that, missed interrupt from touchscreen (when SPI is busy with sending data to LCD) makes it stop making further attempts to communicate. Or maybe there is some incompatibility on electrical level, I really don't know.
    5. My electrical setup (keep in mind it's 3.3V)
     
    OPIZ - LCD (ili9431)
    PA13 - CS
    PA14 - SCK
    PA16 - SDO
    PA15 - SDI
    PA03 - DC
    PA00 - RESET
    PA06 - controls transistor which is driving current to LCD pin. You may also connect LCD pin to VCC, and leave PA06 floating.
     
    And here is part for touchscreen. We are going to use emulated spi bus with bitbang. At this point bitbang isn't compiled in armbian kernel - we will take care of this later.
     
    OPIZ - LCD (tsc2046)
    PA10 - T_CS
    PA18 - T_IRQ
    PA19 - T_CLK
    PA11 - T_DIN
    PA12 - T_DO
     
    Configuration for the first spi bus:
     
    Configuration for touchscreen driver:
     
    Compile and add those DTS with "armbian-add-overlay" command.
    Next, download armbian sources and cross compile kernel - without any modifications, just to make sure that everything is compiling without issues:
    # mkdir armbian # cd armbian # git clone https://github.com/armbian/build.git # git clone https://github.com/igorpecovnik/lib # cp lib/compile.sh . # ./compile.sh BRANCH=dev BOARD=orangepizero KERNEL_ONLY=yes PROGRESS_DISPLAY=plain RELEASE=jessie Enable required modules :
    echo "CONFIG_SPI_BITBANG=m" >> lib/config/kernel/linux-sun8i-dev.config echo "CONFIG_SPI_GPIO=m" >> lib/config/kernel/linux-sun8i-dev.config ... and recompile kernel, then install deb packages from output directory. You may also copy drivers, it may be faster for testing but it's not advised for "serious" deployment.
    Loading modules at startup:
    # cat > /etc/modprobe.d/fb_ili9341.conf << _EOF_ options fbtft_device custom name=fb_ili9341 gpios=dc:3,reset:0,led:6 speed=16000000 busnum=1 _EOF_ # echo fbtft_device >> /etc/modules # echo ads7846 >> /etc/modules If you connected LED pin to VCC, then you should omit that ",led:6" in configuration above. 
     
    I hope that this will help anyone who want to connect LCD display and build simple touchscreen based Orange Pi Zero terminal

     
     
  2. Like
    MitchD reacted to ldiaz in pygame on orange pi zero mainline kernel   
    Hi
    Im using main-line/dev version not legacy. The GPIO are those of the SPI1 interface + some extra for additional signals required. in my case gpios=dc:0,led:3,reset:1. For display only its not needed to install any overlay only notro's fbtft. In case that what to use the touch screen then you need to use a device tree overlay using with spidev and spi-add-cs1 overlays. (attached my version) For touch you need and additional CS GPIO defined in spi-add-cs1 and one more for IRQ from the touch screen. I picked "PA7".  
    regards,
    touch.dts
  3. Like
    MitchD reacted to Andrea Bondavalli in fix for 24/32bit H3 audio capture   
  4. Like
    MitchD got a reaction from Igor in Testers wanted Real Time Kernel image builds for H3 boards   
    You can find a 4.11.9 rt patch here: https://www.kernel.org/pub/linux/kernel/projects/rt/4.11/older/
     
    I have a vanilla mainline kernel with that patch applied and it works for me. I think armbian uses a separate github directory, so you might need to tweak the patch. 
  5. Like
    MitchD reacted to Igor in Testers wanted Real Time Kernel image builds for H3 boards   
    Have you try those perhaps:
     
     
  6. Like
    MitchD reacted to boobypi in Launch legacy kernel from mainline uboot is possible?   
    example of command (tested on OP PC) to boot openwrt in ram from a tftp server (sharing dtb, uimage and rootfs) :
    setenv ipaddr 192.168.x.x setenv serverip 192.168.x.x setenv netmask 255.255.255.0 setenv kernel_addr_r 0x42000000 setenv fdt_addr_r 0x43000000 setenv ramdisk_addr_r 0x43300000 setenv rootfsaddr 0x43300000 setenv tftpLoadUBoot tftpboot 0x42000000 openwrt-sunxi-uImage setenv tftpLoadDTB tftpboot 0x43000000 dtb setenv tftpLoadROOTFSRAM tftpboot 0x43300000 openwrt-sunxi-root.ext4 setenv tftpLoadCMD run tftpLoadUBoot tftpLoadDTB tftpLoadROOTFSRAM setenv bootargs console=ttyS0,115200 mem=512M earlyprintk root=/dev/ram0 rw ramdisk_size=200000 initrd=0x43300000,100M saveenv run tftpLoadCMD bootm 0x42000000 - 0x43000000 - 0x43300000  
  7. Like
    MitchD reacted to Igor in Fully Preemptible kernels   
    Available for:
     
    4.13.10 cubox (Cubox-i, Hummingboards)
    4.13.10 mvebu64 (Espressobin)
    4.9.58  odroidxu4 (Odroid XU3/XU4)
    4.13.10 rockchip (Tinkerboard, MiQi)
    4.13.10 sunxi (All Allwinner 32bit boards)
    4.13.10 sunxi64 (All Allwinner 64bit boards)
     
    https://dl.armbian.com/_misc/realtime-kernel

    Requirements:

    - Armbian OS. Ubuntu or Debian bases.
    - root credentials

    Download: *dtb and *image packages at a minimum and install them with dpkg -i *.deb ... If you want to stay on this kernel, freeze upgrades in armbian-config -> system -> freeze kernel upgrades.

    Remember that those kernels are bleeding edge, made from upstream sources and may have troubles. Consider them as is/experimental, without end-user support. If you want to build them - patches are present but .disabled and might not apply cleanly with more recent sources without adjustements.
     
    What is RT?
  8. Like
    MitchD reacted to Igor in RT patches for sun8i kernel?   
    I can't help you when you use buildroot ... you are adding unnecessary complexity to the problem and on the end, you will be disappointed on the RT performance with the old legacy kernel. Go for new 4.13 kernel, add appropriate RT patch to userpatches/kernel/sunxi-next/ recompile kernel and install .deb packages. Can't be more simple than this.
     
  9. Like
    MitchD reacted to MX_Master in Has anybody a good latency after the RT-PREEMPT patch?   
    I'm using the armbian toolset without any kernel tweaks. Just RT patch, option 5. Without any PREEMPT debug.
    I think it's time to make some tweaks to the kernel.. 
  10. Like
    MitchD got a reaction from MX_Master in Has anybody a good latency after the RT-PREEMPT patch?   
    Cool, I didn't know RT patches for 4.13 were out already! Thats great news, I should bump up my version. Are you building your kernel using the armbian toolset or your own?
     
    Another point is that mine is specifically for the nanopi neo, which doesn't involve any HDMI setup or clocking. I'm not sure if that affects the results of cyclictest, but it might, as the HDMI subsystem must involve interrupts to the kernel. Armbian also ships with irqutils, which balances the irqs over the 4 cores (or 3, as you have one isolated). I have no idea if that matters either. 
     
    I'm using my stuff for audio, and having the full RT kernel helps with audio dropouts on my USB device. Using alsa (no jack) I can get it down to ~10ms round trip. Without RT it was more like ~30ms. I've found the best test of any RT system is how it responds with your application.
  11. Like
    MitchD reacted to MX_Master in Has anybody a good latency after the RT-PREEMPT patch?   
    Thanks, MitchD!
     
     
    Your results are very good! I'll try to learn more about your environment.
     
    By the way, I found the new RT patch for the mainline kernel 4.13. I build a fresh desktop Ubuntu Xenial image with this RT patch. Setup the isolcpus=3. And my new latency results are
    master@orangepione:~/rt-tests$ sudo ./cyclictest -a -t -n -p80 # /dev/cpu_dma_latency set to 0us policy: fifo: loadavg: 4.81 2.25 1.02 6/382 3797 T: 0 ( 3376) P:80 I:1000 C: 237748 Min: 5 Act: 30 Avg: 15 Max: 136 T: 1 ( 3377) P:80 I:1500 C: 158502 Min: 5 Act: 17 Avg: 16 Max: 103 T: 2 ( 3378) P:80 I:2000 C: 118876 Min: 5 Act: 44 Avg: 18 Max: 113 T: 3 ( 3379) P:80 I:2500 C: 95101 Min: 6 Act: 17 Avg: 13 Max: 98 It's much better!
  12. Like
    MitchD got a reaction from MX_Master in Has anybody a good latency after the RT-PREEMPT patch?   
    Sure thing! Here are my results:
    # cyclictest -p 80 -t5 -n -a # /dev/cpu_dma_latency set to 0us policy: fifo: loadavg: 0.12 0.17 0.08 1/93 193           T: 0 (  186) P:80 I:1000 C: 551057 Min:      5 Act:    8 Avg:    8 Max:      29 T: 1 (  187) P:80 I:1500 C: 367371 Min:      5 Act:    8 Avg:    7 Max:      44 T: 2 (  188) P:80 I:2000 C: 275529 Min:      7 Act:    8 Avg:    7 Max:      13 T: 3 (  189) P:80 I:2500 C: 220423 Min:      7 Act:    8 Avg:    7 Max:      11 T: 4 (  190) P:80 I:3000 C: 183685 Min:      5 Act:    8 Avg:    7 Max:      24 I have isolcpus=2,3 running, and I'm running a mainline 4.11 kernel with the rt patch, as well as an ethernet patch and usb otg patch. It is also a buildroot environment, so I'm not sure how much that is skewing these results in my favor. 
    # uname -a Linux nanopi-neo 4.11.9-rt7 #1 SMP PREEMPT RT Fri Sep 22 10:38:22 CDT 2017 armv7l GNU/Linux
     
  13. Like
    MitchD reacted to MX_Master in Has anybody a good latency after the RT-PREEMPT patch?   
    Hi. MitchD. Thanks for the fast reply.
     
    I see you got 42 us with cmd cyclictest -p 80 -t5 -n. With same cmd my results is about 250 us.
    master@orangepione:~/rt-tests$ sudo ./cyclictest -p 80 -t4 -n # /dev/cpu_dma_latency set to 0us policy: fifo: loadavg: 2.46 1.56 0.66 1/293 4110 T: 0 ( 3498) P:80 I:500 C: 335436 Min: 8 Act: 27 Avg: 24 Max: 235 T: 1 ( 3499) P:80 I:1000 C: 167700 Min: 7 Act: 32 Avg: 27 Max: 158 T: 2 ( 3500) P:80 I:1500 C: 111787 Min: 8 Act: 27 Avg: 24 Max: 128 T: 3 ( 3501) P:80 I:2000 C: 83830 Min: 7 Act: 32 Avg: 25 Max: 150 But when I use the -a parameter ( cyclictest -p 80 -t5 -n -a ) the latency becomes really wild.
    Can you test your config with this cmd?
    cyclictest -p 80 -t5 -n -a  
  14. Like
    MitchD got a reaction from MX_Master in Has anybody a good latency after the RT-PREEMPT patch?   
    You can find discussion about this in another post on this forum: 
     
    I find you don't get great latency in the legacy kernel, whereas my post with the mainline kernel has a max latency of 42 us. 
     
  15. Like
    MitchD reacted to zador.blood.stained in How to change OTG mode from serial to HID keyboard on the Orange pi zero?   
    https://github.com/armbian/build/issues/593
  16. Like
    MitchD reacted to Igor in How to change OTG mode from serial to HID keyboard on the Orange pi zero?   
    Try toggling: https://github.com/armbian/build/blob/master/config/fex/orangepizero.fex#L504
     
     
    Afaik it should work. Perhaps unloading is not working as it should. This kernel is from some other times ... removal from /etc/modules and reboot might be needed.
     
    Nobody is working on H3 legacy kernels anymore  Modern kernel will be here soon.
     
    @Abdullah Seba Technical support is our free will. Our expense and we tend to rest on Sundays.
  17. Like
    MitchD got a reaction from Abdullah Seba in How to change OTG mode from serial to HID keyboard on the Orange pi zero?   
    Which kernel are you using? If you are using mainline, I understand than the OTG options aren't there yet.
     
    If on legacy, you can try: modprobe -r g_serial
    followed by: modprobe g_hid
     
    From there, see if any new devices are created.  Full documentation is here: https://www.kernel.org/doc/Documentation/usb/gadget_hid.txt
  18. Like
    MitchD reacted to tkaiser in NanoPi Duo (plus Mini Shield)   
    Just for the record: These 65°C are just a number set here: https://github.com/friendlyarm/linux/blob/sunxi-4.11.y/arch/arm/boot/dts/sun8i-h3-nanopi.dtsi#L158
     
    Ondrej used this and the other numbers when he started to code DVFS/THS stuff last year, AFAIK no one so far has looked into H3 thermal/throttling stuff from a user perspective ('Are these settings sufficient') and the only time I looked into it it was pretty obvious that the way throttling currently works with mainline kernel on those boards with primitive voltage regulation (switching only between 1.1V and 1.3V) is worse compared to BSP/legacy kernel.
  19. Like
    MitchD reacted to tkaiser in H6 boards: Orange Pi One Plus, Orange Pi 3 Plus and Pine H64   
    What do we know now? Not much  -- most importantly that some details will change and 'board available soon'.
     
    We have a H6 Product Brief available and a few selected developers already had a look into user manual (NDA situation right now, so not possible to get any answers from them  )
     
    So all we know is really just:
    H6 is limited wrt DRAM (2GB DDR4/DDR3/DDR3L max), I know the DRAM manufacturer from the modules in my Beelink X2 but have forgotten the name The Ampak module might be an AP6356S providing dual-band/dual-antenna Wi-Fi + BT 4.1 Gigabit Ethernet (H6 is said to have a 2nd Fast Ethernet MAC/PHY but no idea how/whether exposed here -- maybe available on pin headers to be combined with an external MagJack like it's possible on ROCK64 or NanoPi Duo)  One HDMI is a v2.0a output for sure, the other can be another HDMI output (LCD to HDMI converter) or maybe also a HDMI to TS input (depends on the type of chip behind the left HDMI port) eMMC on board One of the USB receptacles is blue (USB3 SuperSpeed), the other is USB2 and I would believe the remaining USB2 port is available on pins 36/38 of the mPCIe connector allowing to attach 'miniPCIe WWAN modems' (to be combined with the SIM card slot -- AFAIK these modems use USB at a 3.3V logic level) the mPCIe slot also exposes H6's single PCIe 2.x lane there's AV, optical audio out and an IR receiver (positioned IMO somewhat strangely since if rotated 90° on the PCB side next to its actual location OPi 3 Plus combined with a little enclosure would already make up for a complete TV box)
  20. Like
    MitchD reacted to tkaiser in Being apart of the next biggest thing since sliced technical bread.   
    Well, being told we're 'apart of the next biggest thing' (and not being 'a part' of it) is one thing, the other is
     
     
    Playing the role of the 'wrong' Steve isn't a great idea anyway especially since you're asking for the impossible (a Linux kernel running as app inside a sandboxed environment on top of a XNU kernel having any access to low level stuff)  
     
  21. Like
    MitchD reacted to giri@nwrk.biz in Armbian on LY-F1/Gooseberry/Topwise A721 [Make old tablets great again]   
    Yeah, I made a tablet optimized image using matchbox and some custom scripts (to toggle keyboard etc.). It also has an desktop mode. I tried to use as few dependencies as possible.
    I also got hardware accelerated video to work with gstreamer. This may come handy for some dlna/upnp related stuff.
     
    No I did not try to write it to nand. It just felt to unflexible for me. But it should not be a problen to repack an flashable image with the tools you find in the sunxi wiki and on xda.
    But imo it may make more sense to use the nand as additional internal storage
  22. Like
    MitchD reacted to giri@nwrk.biz in Armbian on LY-F1/Gooseberry/Topwise A721 [Make old tablets great again]   
    Hey guys!
     
    Cheap Android tablets based on allwinner chipsets were pretty common back in 2012. Recently I found an tablet equipted with an Allwinner A10 SoC (LY-F1) lying lonely around on my fathers desk. He bought that tablet back then because of the cheap price, but never really used it. Luckily my father also saved an Android 4.0.4 ROM he downloaded from the suppliers website back then, because all websites of this supplier are offline now.
     
    After playing around with my OPiZ and seeing how well the sunxi/armbian kernel works, I thounght myself i should try to boot linux from this tablet. At first I tried to pack an image that can be directly written onto the devices 8GB NAND storage, but soon found out that the device tries to boot from SD by default. After doing some research I found out that this device uses an PCB called Topwise A721 which was also sold as standalone board named 'Gooseberry'. This PCB was used in many Chinese Tablets back in 2012.
     
    My next logical step was to burn the only avaiable armbian image for the A10 (pcduino2) and see if it boots. At first I thougth it did not work, because the screen kept blank and the tablet did not give any response, but after plugging the SD card back into my PC i saw that the filesystem was extended to the max 16GB of my SD :). (Hooray, no dissasembly and fiddeling around with UART needed)

    So next I extracted the script.bin (attached to this post) from the android image and replaced it with the symlink on the armbian image. And voila even the screen works out of the box  The only problem I have now is, that I do not have an USB mini OTG cable (I already ordered one) to plug in an keyboard and do further testing. LOL, just found an mini USB OTG in an USB Adapter set I bought some time ago. The desktop environment boots up fine!
     
    The tablet itself has an mini HDMI port, so this may be useful for me! 
     
    Picture of tablet with Armbian login + desktop:
     
    I'll report back when I have done further testing!
     
    EDIT1:
    To enable wireless networking 8192cu has to be added to etc/modules (legacy kernel ofc).
     
    EDIT2:
    Audio works out of the box. 
     
    EDIT3:
    I now added following kernel modules to etc/modules (most of them are loaded on the android image too!):
    This should enable GPU HW acceleration, enables the touchscreen of the tablet and the touch keys.
     
    Touch key info:
    Scancodes:
    BACK: 10x02, 0x82
    HOME: ^[0x01, 0x81
    MENU: 20x03, 0x83
     
    Keycodes:
    BACK: 2
    HOME: 1
    MENU: 3
     
    EDIT4:
    Things I could not get to work:
    camera module (missing kernel module? gc030809 or wrong I2C address?)
    Volume HW keys.
     
    EDIT5:
    Cam somewhat works with cheese after changing gc030809 to gc0308 in script.bin (Yeah silly me, its because cheese tries to use OpenGL rendering.)
    Cam works pretty nice with mplayer, making fotos using fswebcam also works!
     
    EDIT6:
    I made working configurations for the armbian build system (files attached!).
     
    EDIT7:
    Configs are upstream, but not officially supported
     
    EDIT8:
    I am currently working on an tablet optimized image.
     
    Awesome how nearly everything worked out of the box! Armbian on this tablet outperforms the original android image by far!
    Moral of the story, check any old chinese tablets lying around and make them great again using linux
     
    script.bin
    linux-topwise-a721-default.config
    topwise-a721.fex
    topwise-a721.conf
  23. Like
    MitchD reacted to Igor in Testers wanted Real Time Kernel image builds for H3 boards   
    https://cdn.kernel.org/pub/linux/kernel/projects/rt/4.11/

    No idea if it works.
  24. Like
    MitchD got a reaction from Igor in Testers wanted Real Time Kernel image builds for H3 boards   
    You can find a 4.11.9 rt patch here: https://www.kernel.org/pub/linux/kernel/projects/rt/4.11/older/
     
    I have a vanilla mainline kernel with that patch applied and it works for me. I think armbian uses a separate github directory, so you might need to tweak the patch. 
  25. Like
    MitchD reacted to StuxNet in Need help for Orange Pi Zero OS Installation   
    Ummm?... because Q4OS only supports Pinebook, Pine64 and Raspberry Pi as per their downloads page. Unless I'm missing something. Even if I am, that would mean their "ARM port" download is trying to do something similar to Armbian by being compatible with multiple devices. Aside from chromebooks, tablets, etc... I think you'd be hard pressed to find an argument for using Q4OS over Armbian especially for OPiZero. Maybe that's just me though.
     
    https://q4os.org/downloads1.html

    So what's your reasoning as to why you opt for Q4OS over Armbian?