arhi
-
Posts
36 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by arhi
-
-
also having weird issue with compiling kernel, stmpe_ts module is nowhere to be found in the kernel configuration, I added it manually to .config and loaded it and then it shown but, weird, also the ili_9340 and ili9341 modules, they are built but I don't see them neither in the configuration of the kernel.. something fishy is going on
-
15 hours ago, martinayotte said:
Bringing SPIDEV isn't related to framebuffer. It can only provide you access to the display from userspace program such python script.
To make it attached as framebuffer, you need much more complex DT overlays such the ones found where : https://github.com/notro/fbtft/blob/master/dts
I'm not smart enough to figure out how to make the DTS from scratch myself... I tried to modify the DTS that works on RPI to work on OPI but had zero success... then I finally got this to work in a way I see the /dev/fb1 on pc2 by adding "overlays=spi-spidev spi-add-cs1" to Env, and by loding fbtft_device with additional parameters..
modprobe fbtft_device name=pitft gpios=reset:24,dc:25
it all then start to "behave" like it's working, new framebuffer device is created, ili module is loaded etc etc ... but screen don't show no data
.. at this point I suspect the gpios part is problematic as those gpio24 and gpio25 are rpi numbering, the scheme is different on opi so I tried reset:5,dc:6 but nothing happened .. so now I'm searching for other solution
-
I started first with orangepi pc2 (H5) but now trying the same thing on orangepi one (h3) -
trying to make ili9340 module work
it works flawlesly on rpi with raspbian so the hw module works (and the fb_ili9340 module in kernel talks to it properly)
debug info I pulled from rpi
pi@octopi:~ $ uname -a Linux octopi 4.14.79-v7+ #1159 SMP Sun Nov 4 17:50:20 GMT 2018 armv7l GNU/Linux root@octopi:~# lsmod Module Size Used by xt_tcpudp 16384 1 iptable_mangle 16384 1 xt_DSCP 16384 1 bnep 20480 2 hci_uart 36864 1 btbcm 16384 1 hci_uart serdev 20480 1 hci_uart bluetooth 368640 24 hci_uart,bnep,btbcm ecdh_generic 28672 1 bluetooth fb_ili9340 16384 0 fbtft 45056 1 fb_ili9340 syscopyarea 16384 1 fbtft sysfillrect 16384 1 fbtft sysimgblt 16384 1 fbtft fb_sys_fops 16384 1 fbtft stmpe_ts 16384 0 joydev 20480 0 evdev 24576 4 brcmfmac 307200 0 brcmutil 16384 1 brcmfmac cfg80211 573440 1 brcmfmac rfkill 28672 6 bluetooth,cfg80211 snd_bcm2835 32768 0 gpio_backlight 16384 0 i2c_bcm2835 16384 0 snd_soc_bcm2835_i2s 16384 0 snd_soc_core 188416 1 snd_soc_bcm2835_i2s snd_compress 20480 1 snd_soc_core snd_pcm_dmaengine 16384 1 snd_soc_core snd_pcm 98304 4 snd_pcm_dmaengine,snd_soc_bcm2835_i2s,snd_bcm2835,snd_soc_core spi_bcm2835 16384 0 snd_timer 32768 1 snd_pcm snd 69632 5 snd_compress,snd_timer,snd_bcm2835,snd_soc_core,snd_pcm uio_pdrv_genirq 16384 0 fixed 16384 0 uio 20480 1 uio_pdrv_genirq ip_tables 24576 1 iptable_mangle x_tables 32768 4 iptable_mangle,ip_tables,xt_tcpudp,xt_DSCP ipv6 425984 45 root@octopi:~# root@octopi:/dev/input# ls -la total 0 drwxr-xr-x 4 root root 220 Jan 3 02:59 . drwxr-xr-x 15 root root 3420 Jan 3 02:59 .. drwxr-xr-x 2 root root 120 Jan 3 02:59 by-id drwxr-xr-x 2 root root 140 Jan 3 02:59 by-path crw-rw---- 1 root input 13, 64 Jan 3 02:59 event0 crw-rw---- 1 root input 13, 65 Jan 3 02:59 event1 crw-rw---- 1 root input 13, 66 Jan 3 02:59 event2 crw-rw---- 1 root input 13, 67 Jan 3 02:59 event3 crw-rw---- 1 root input 13, 63 Jan 3 02:59 mice crw-rw---- 1 root input 13, 32 Jan 3 02:59 mouse0 crw-rw---- 1 root input 13, 33 Jan 3 02:59 mouse1 root@octopi:/dev/input# root@octopi:/dev/input# udevadm info -q all /dev/input/event3 P: /devices/platform/soc/3f204000.spi/spi_master/spi0/spi0.1/stmpe-ts/input/input3/event3 N: input/event3 S: input/by-path/platform-3f204000.spi-platform-stmpe-ts-event E: DEVLINKS=/dev/input/by-path/platform-3f204000.spi-platform-stmpe-ts-event E: DEVNAME=/dev/input/event3 E: DEVPATH=/devices/platform/soc/3f204000.spi/spi_master/spi0/spi0.1/stmpe-ts/input/input3/event3 E: ID_INPUT=1 E: ID_INPUT_TOUCHSCREEN=1 E: ID_PATH=platform-3f204000.spi-platform-stmpe-ts E: ID_PATH_TAG=platform-3f204000_spi-platform-stmpe-ts E: MAJOR=13 E: MINOR=67 E: SUBSYSTEM=input E: USEC_INITIALIZED=5285899
on the armbian, no matter what I do I can't get the fb_ili9340 to create /dev/fb1
the module loads ok and displays no errors but no /dev/fb1dmesg shows
... [ 139.389950] fbtft: module is from the staging directory, the quality is unknown, you have been warned. [ 139.395122] fb_ili9340: module is from the staging directory, the quality is unknown, you have been warned. root@orangepione:~#
I see fb0 (hdmi monitor) and spidev0.0 devices
root@orangepione:~# ls -la /dev/fb* /dev/spi* crw-rw---- 1 root video 29, 0 Jan 5 23:28 /dev/fb0 crw------- 1 root root 153, 0 Jan 5 23:28 /dev/spidev0.0 root@orangepione:~#
I modified armbianEnv
root@orangepione:/boot# cat armbianEnv.txt verbosity=1 logo=disabled console=both disp_mode=1920x1080p60 overlay_prefix=sun8i-h3 rootdev=UUID=e753a023-12c8-405e-b8f7-6b4e3ae873d0 rootfstype=ext4 overlays=spi-spidev spi-add-cs1 param_spidev_spi_bus=0 param_spidev_max_freq=32000000 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u root@orangepione:/boot#
tried without spi-add-cs1 too, without max_freq...
it's based on stretch and mainline ... I can try old kernel too if that makes sense..
___ ____ _ ___ / _ \ _ __ __ _ _ __ __ _ ___ | _ \(_) / _ \ _ __ ___ | | | | '__/ _` | '_ \ / _` |/ _ \ | |_) | | | | | | '_ \ / _ \ | |_| | | | (_| | | | | (_| | __/ | __/| | | |_| | | | | __/ \___/|_| \__,_|_| |_|\__, |\___| |_| |_| \___/|_| |_|\___| |___/ Welcome to ARMBIAN 5.46 user-built Debian GNU/Linux 9 (stretch) 4.14.48-sunxi System load: 1.47 1.15 0.51 Up time: 3 min Memory usage: 15 % of 493MB IP: 192.168.89.115 CPU temp: 60°C Usage of /: 30% of 3.4G root@orangepione:/boot# uname -a Linux orangepione 4.14.48-sunxi #2 SMP Wed Jun 6 01:50:17 CEST 2018 armv7l GNU/Linux -
same issue with stretch
now on rpi I had to edit config.txt to add
dtparam=i2c_arm=on dtparam=i2c1=on dtparam=i2s=on dtparam=spi=on dtoverlay=pitft28-resistive:rotate=90,speed=32000000,fps=20 start_x=0
not sure how to do same thing for armbian?
-
tried xenial, not working
same behavior ..
on rpi using stretch and 4.14.79 same module works there's new /dev/fb1 created etc etc... touch screen also working..
now trying to build armbian with stretch instead bionic/xenial to try it out, maybe I get lucky
-
trying to get ili9340 to work on orangepi pc2 on bionic 4.14.91 ... there's a fb_ili9340 module in the staging directory, modprobe passes and the only thing in dmesg is warning it's staging nothing else but when I check /dev/fb* there's only /dev/fb0 (the original hdmi output on my monitor), there's no /dev/fb1
anyone can land a hand? give a hint?
-
I'v seen many dead SD cards, from camera's opi's, rpi's .. but never like this, that it lies to you that writes go trough but it's just silently ignoring them .. one more thing to check for in future
as for spending 1-2$ for usb-uart, I think I have more then a 100 of those around the house
.. electronics is my passion and you need those non stop and everywhere I just trusted in hdmi (for the first time to be honest, the darn thing arrived few days ago and I was thinking if I might want to setup octoprint or some custom made system with some touch screen since I'm making a new enclosure for multiple printers with heated chambers, special part for all the electronics etc etc.. so the screen was "handy" .. well, one learn while one lives
-
29 minutes ago, chwe said:
So I'll move this one two to the famous crappy SD-Card/PSU section as well
PSU was the first thing I tested. Then I made IMG of the card (worked flawlesly), then loaded that img on linux, fsckd it and it had errors that were easily fixed and stored back into IMG. Then I dd img to the card and it went "ok" ... but nothing was solved .. running in circles, on and on and ... when you suggested serial it's when I seen the darn thing was not able to fsck the card...
This is no-name, made in corea, 8G class 6 SD card that came with one of the raspbery pi boards I think or with some other hardware... but it's bin working 24/7 for few years so I don't care if it died it was worth it and the way it died is actually interesting - it switched to read-only mode. What I do dislike is that it does not report ANY error for writing. Any write you execute is "ok", and of course you read it ok from cache so you think it's there. You remove the card and dang no changes made.
QuoteCan you format it with whatever you use.. and then let F3 or h2testw running and post the result you get here
nope, I dd /dev/zero to card and it shows that card is zeroed, I remove card, return it and the old content is there... no way to write anything to card, it's ignoring writes (silently) ...
Quotewell... I quoted this just for fun...
the problem is my mini 7" hdmi screen was already there as I'm conteplating some project so I hooked the screen instead of uart and was expecting "same output" .. but looks like that "both" thing don't really work
Thanks again! now copying, resizing, copying, repairing... to move this to a higher quality kingstop 4G card
-
looks like a dead bloody card
... you write to it, it ignores writes ?!?!?!?! have not had this before .. wow .. well you learn something new every day thanks for help I'd probbly never put the serial on my own -
well, hooking up serial was def a good idea... more info (useful info) there ..
Autoboot in 1 seconds, press <Space> to stop switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 3550 bytes read in 223 ms (14.6 KiB/s) ## Executing script at 43100000 U-boot loaded from SD Boot script loaded from mmc 166 bytes read in 192 ms (0 Bytes/s) 4086840 bytes read in 526 ms (7.4 MiB/s) 5818864 bytes read in 595 ms (9.3 MiB/s) Found mainline kernel configuration 26231 bytes read in 452 ms (56.6 KiB/s) 374 bytes read in 549 ms (0 Bytes/s) Applying kernel provided DT overlay sun8i-h3-i2c0.dtbo 4179 bytes read in 407 ms (9.8 KiB/s) Applying kernel provided DT fixup script (sun8i-h3-fixup.scr) ## Executing script at 44000000 ## Loading init Ramdisk from Legacy Image at 43300000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 4086776 Bytes = 3.9 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 43000000 Booting using the fdt blob at 0x43000000 Loading Ramdisk to 49c1a000, end 49fffbf8 ... OK reserving fdt memory region: addr=43000000 size=7000 Loading Device Tree to 49c10000, end 49c19fff ... OK Starting kernel ... Uncompressing Linux... done, booting the kernel. Loading, please wait... Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems done. Begin: Will now check root file system ... fsck from util-linux 2.25.2 [/sbin/fsck.ext4 (1) -- /dev/mmcblk0p1] fsck.ext4 -a -C0 /dev/mmcblk0p1 /dev/mmcblk0p1: recovering journal /dev/mmcblk0p1: Superblock needs_recovery flag is clear, but journal has data. /dev/mmcblk0p1: Run journal anyway /dev/mmcblk0p1: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. (i.e., without -a or -p options) fsck exited with status code 4 done. Failure: File system check of the root filesystem failed The root filesystem on /dev/mmcblk0p1 requires a manual fsck Rebooting automatically due to panic= boot argument
weird fsck failure but I did a fsck of an image already and wrote the image on top of the SD already ... hm .. weird .. will have to put the card directly on to linux and do fsck of the card that might work..
-
noone likes videos but at least I didn't enclose video in word document
I have bunch of usb/uart adapters around will attach one now but I doubt I'll see anything new since boot is already set to send data to both devices so I doubt I'll get more on uart but to be on the safe side - testing in few minutes
now I don't mind editing and compiling boot.cmd but any arts you think would be useful?
-
not sure what *** Warning - bad CRC, using default environment
actually means .. is it reporting crc error in bootloader? sd card? what's "default env" in this context ?
looks like safest thing to do is reinstall the darn thing and restore backup from image
the weirdest thing, it was working great for a while, then I did "find / -type f -exec grep 101 {} \; " and after 5-6 minutes it crashed linux and wouldn't boot after that
-
-
clear, so I should make new files on the build env I have, that makes sense ... anyhow I Was not changing boot.cmd, the url https://docs.armbian.com/User-Guide_Fine-Tuning/#how-to-toogle-verbose-boot said it's enough to change verbosity= line in /boot/armbianEnv.txt from 1 to higher number (7 is max) and touch /boot/.force-verbose so I did not touch /boot/boot.cmd (and boot.cmd is already set to "both" so both serial and hdmi are showing output) .. problem is nothing in output makes sense
lemme try to record it with hero as phone camera fails to properly focus
-
15 minutes ago, chwe said:
install the u-boot tools (forgot the package name) and then mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr.. if you make changes to boot.cmd
problem is I can't get the darn thing to boot ... can't install anything on it... can edit sd card outside on the regular x86 linux that's all
-
I understood I only need to add verbosity not that I need to recompile it ... how to recompile it on i386/amd64 linux?
-
didn't help
.. starting kernel... pause ... reboot
-
16 hours ago, chwe said:
https://docs.armbian.com/User-Guide_Fine-Tuning/#how-to-toggle-boot-output
you might mount your sd-card on a linux machine and do it by your own.
thanks, increased verbosity, and created /boot/.force-verbose so let's see if that will show where the problem is
-
Something happened to my armbian, I executed rather simple find --execute grep ... troughout the whole sd card, it froze and will not boot any more .. attached a hdmi display (orangepi one is the board in question) and I see it boots the kernel and then just "rebooting..." and reboots and does that in a loop...
on a normal linux running grub bootloader I'd stop the boot and add "single" to the kernel parameters, it will ignore all the boot scripts and after booting the kernel would drop me directly into shell as root so I can investigate wth is going on... anything similar I can do to armbian?
-
On 12/30/2017 at 8:02 AM, Igor said:
Armbian is a community project. If you made something that is generally usable, push it upstream and
Yes, but the "fix" is part of the OPI library not part of the Armbian and it's rather simple, just adds arbitrary delay (500ms) before accessing direction file.. problem is, while this works, it's an ugly patch ... for me it works but the lib accesses few different files in sequence and it's possible with different load, different sd card, different cpu the other files might also be a problem so in theory there should be some test of permissions all of those sysfs files are accessed with some configurable timeout.. but since python is really not my strong suit I just hacked it to get it to work for me.. I would never push a hack like this upstream...
now this type of race condition is not something I had with rpi and I heard some kernel configs for armbian are different and might work so hoped there's a "ready" solution
.. it's anyhow the library issue not the armbian issue in the first place.
anyhow thanks for those links will check them out asap
p.s. happy new 2018
--- 1/OPi/GPIO.py +++ 2/OPi/GPIO.py @@ -239,6 +239,7 @@ Methods """ import warnings +import time from OPi.constants import IN, OUT from OPi.constants import LOW, HIGH # noqa: F401 @@ -358,6 +359,7 @@ def setup(channel, direction, initial=None, pull_up_down=None): else: raise e + time.sleep(0.5) sysfs.direction(pin, direction) _exports[channel] = direction if direction == OUT and initial is not None: -
The armbian I am running
Welcome to ARMBIAN 5.31 stable Debian GNU/Linux 8 (jessie) 4.11.5-sun8i
and few other versions that I tried have same issue with accessing GPIO from python as non root, and I, of course, need to access GPIO as non root
however I setup permissions for /dev and /sys and whatever udev rules I configure there is some race condition and I can't get access to GPIO as a non root from python
typical error is something like:
:IOError: [Errno 13] Permission denied: '/sys/class/gpio/gpio1/direction'
So I solved it by some hack of the OPi.GPIO library and udev rules that are not really feasible "always" so I'm trying to figure out if there's a combo of armbian distro and kernel where this works "out of the box" to use on other orangepi boxes I'm setting up?
-
thanks, so def. a race condition where opi lib is faster then chown/chmod
.. thanks, I'll try, it's acceptable solution for me if it works -
forgot to say, originally the error was on export but added to rclocal echo1 > export and that triggers the udev rule so now is stuck opn direction
-
I have seen this old thread but since last post was long time ago and it was shell based I decided to go with new one ...
I have the udev setup (you can see some old versions inside commented out too)
root@orangepizeroplus2:~# cat /etc/udev/rules.d/60-python-pifacecommon.rules #KERNEL=="spidev*", GROUP="gpio", MODE="0660" #SUBSYSTEM=="gpio*", ACTION=="add|change", RUN+="/usr/bin/find /sys/class/gpio -exec /bin/chmod g+u {} + -exec /bin/chown :gpio {} +" #KERNEL=="gpio*", GROUP="gpio", MODE="0660" #SUBSYSTEM=="gpio*", ACTION=="add|change", RUN+="/usr/bin/find /sys/class/gpio -exec /bin/chmod g+u {} + -exec /bin/chown :gpio {} +" KERNEL=="spidev*", GROUP="gpio", MODE="0660" KERNEL=="gpio*", MODE:="0660", GROUP:="gpio" SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c '\ chown -R root:gpio /sys/class/gpio ; \ chmod -R 777 /sys/class/gpio ;\ chown -R root:gpio /sys/devices/virtual/gpio ;\ chmod -R 777 /sys/devices/virtual/gpio; \ chown -R root:gpio /sys/devices/platform/soc/*.gpio/gpio ;\ chmod -R 777 /sys/devices/platform/soc/*.gpio/gpio; \ chmod -R 777 /sys/class/gpio/gpio1/* ;\ chgrp gpio /sys/class/gpio/gpio1/* ;\ chgrp -R gpio /sys/devices/platform/sunxi-pinctrl/gpio ;\ chmod -R ug+rw /sys/devices/platform/sunxi-pinctrl/gpio ' " #SUBSYSTEM=="gpio", PROGRAM="/bin/sh -c '/bin/chown -R root:gpio /sys/devices/soc.0/*pinctrl/gpio'" #SUBSYSTEM=="gpio", PROGRAM="/bin/sh -c '/bin/chmod -R ug+rw /sys/devices/soc.0/*pinctrl/gpio'" root@orangepizeroplus2:~#and when I do it step by step from shell I kinda get it working but a simple
GPIO.setmode(GPIO.BOARD) GPIO.setup(self.pin, GPIO.IN)
fails .. depending on the number of restarts it fails on /sys/class/gpio/gpio1/direction or in one other file there ..
python user is in gpio group, all files are 777...
IOError: [Errno 13] Permission denied: '/sys/class/gpio/gpio1/direction' root@orangepizeroplus2:~# ls -la /sys/class/gpio/gpio1/direction -rwxrwxrwx 1 root gpio 4096 Sep 21 07:52 /sys/class/gpio/gpio1/direction
looks like some race, OPi:GPIO is trying to access them faster then udev is chowning and chmoding files... I'm banging my head for days no more ideas
system is:
Welcome to ARMBIAN 5.32 user-built Debian GNU/Linux 8 (jessie) 3.4.113-sun8i root@orangepizeroplus2:~# uname -a Linux orangepizeroplus2 3.4.113-sun8i #4 SMP PREEMPT Thu Sep 21 03:24:39 CEST 2017 armv7l GNU/Linux
I can change the system to any other one (other kernel, other whatever..) if that will help, I was going with the older kernel hoping this will solve the problem, having identical problem with
Welcome to ARMBIAN 5.27 stable Debian GNU/Linux 8 (jessie) 4.10.11-sun8i root@orangepione:~# uname -a Linux orangepione 4.10.11-sun8i #2 SMP Tue Apr 18 17:55:20 CEST 2017 armv7l GNU/Linux
so, if anyone have any idea what to try I'd really appreciate some help
orangepi one and ili9340
in Allwinner sunxi
Posted
I know, seen all those in the saved config ... "but" when I'm going trough the menu of armbian shown config (I assume the script calls make menuconfig) in the menus I don't see the option to not build ili drivers (they are always on, I have no issues with that but it's just weird) and the config option for the stmpe_ts never shows in the menus ?!?!? now for the stmpe if I add a line in config enabling it and load that config I see the stmpe in the menus then, but not before that, weird...