ej0rge

Members
  • Content Count

    18
  • Joined

  • Last visited

 Content Type 

Forums

Member Map

Store

Crowdfunding

Raffles

Applications

Calendar

Everything posted by ej0rge

  1. I am very confused. Did you run "sudo apt --add-architecture armhf" and not just "apt --add-architecture"? Also it's libc6 not livc6. try "sudo apt-get install libhybris:armhf" I don't have the specific experience with libhybris but i do have multiarch working on my H5
  2. I have the waveshare 2.8 A tft and touch panel working on the Orange Pi PC2 with one long dtoverlay. Some of my inspiration came from here: Like i said one dtoverlay, both fbtft and the touch panel, no other overlays needed. I admit i am a neophyte and it might be possible to trim this one slightly and use it in combination with the CS1 dtoverlay but it wasn't clear to me how that would work. I am using a 6 inch hand-made cable to connect my waveshare 2.8 A but it is wired straight through on only the needed wires for touch and tft. As I've said before it should work just the same with a 3.2 B. May work on PC Prime as-is, should work on other orange pi boards with minor changes (compatible arch and the assignment of pin 26 varies from board to board). For orange pi zero, zero plus (H3 and H5), maybe some others, instances of PA21 should be changed to PA10. Check your pinouts to be sure. The spi speed of 1.6mhz for the tft is a safe example, I have run up to 4mhz without issues and might be able to go higher but i am leaving the safe default in place for this post. one caveat: as i said i don't have a use for the touch panel in my application. I tested it by catting /dev/input/mouse1 and running a fingernail over the touch panel. I got output. yay. More tweaks might be needed, but the driver is fundamentally working and all the overrides are included in the dts waveshare_32b_28a_opipc2.dts
  3. I don't have specific experience with widevine but debian-derived distributions including armbian are capable of hosting multiple ABIs. Your s912 is aarm64 but is backward compatible with armhf. Your 32-bit arm binary is armhf. Similar to how an amd64 system is backward compatible with an i386 system. You start with dpkg --add-architecture armhf then apt-get update Then you install 32-bit versions of everything you need for your 32-bit netflix, etc with "apt-get install foo:armhf" and so on. I've only done this on a small scale, but if you get lucky and everything you need is in the distribution, it's pretty painless. the "ldd" command will tell you what libraries a dynamically linked binary needs to have around. more info here: https://wiki.debian.org/Multiarch/HOWTO
  4. Got it. TFT at least. reset_gpios needed to be 0 0 1 instead of 0 0 0. Yes i should really find where the referece is for what the syntax means instead of trying to intuit it. I'll see if i can tease the touch into working though i don't really need it for my application. Edit: probably gonna start with copypasta from this but with the correct gpio pins: https://github.com/armbian/sunxi-DT-overlays/blob/master/examples/spi-ads7846.dts So far I have only tested this on my orange pi pc2 running 5.4.20 waveshare_32b_28a_opi.dts
  5. Thanks for that. - i was unsure about whether that line needed to change. It loads now, but the screen is still white, so i guess i have more troubleshooting to do. The touch device also is not working. [ 8.040102] ads7846: probe of spi1.1 failed with error -22 [ 8.041249] fbtft: module is from the staging directory, the quality is unknown, you have been warned. [ 8.060153] fb_ili9340: module is from the staging directory, the quality is unknown, you have been warned. [ 8.062524] fbtft_of_value: buswidth = 8 [ 8.062534] fbtft_of_value: debug = 0 [ 8.062537] fbtft_of_value: rotate = 90 [ 8.062539] fbtft_of_value: fps = 25 [ 8.062542] fbtft_of_value: txbuflen = 32768 I should clarify, while I'm not a programmer, I have been using linux for roughly as long as it has existed, and in a previous life i worked for a now-long-dead embedded linux vendor in QA. But that was almost 20 years ago and if i knew anything about uboot at the time i have forgotten it. I am also not sure device trees were a thing in 2001. Maybe i should say, as far as my embedded hacking skills are concerned, I have yet to find if there is anything under the rust.
  6. OK, this is probably related: Is there a way to get a more informative error message?
  7. Yeah, nothing that looks like it is directly related. the only mention of spi is where it complains about not being able to create a device for spi flash that might not exist. During the uboot part of bootup it complains about no boot.env and that might be related. Maybe it's not reading armbianEnv.txt at all? I think i might hook up the serial console so i can log the whole boot process.
  8. Ok, thanks. Where should i look for any output generated by this?
  9. I am trying to figure out how to create a dtoverlay to allow my waveshare 2.8a fbtft screen to work. I understand that i the 5.x.y kernels, a dtoverlay is required. I'm starting with the waveshare32b.dts for raspberry pi, found here: https://github.com/swkim01/waveshare-dtoverlays Should be compatible with the 2.8a per waveshare wiki. I'm trying to modify it in sort of the same way as was done in this thread, for another display: The board I'm using for this is an orangepi pc2. But i don't' actually know what I'm doing. What I've come up with so far is this: /* * Device Tree overlay for waveshare 3.2inch B and 2.8inch A TFT LCD * */ /dts-v1/; /plugin/; / { compatible = "allwinner,sun8i-h3", "allwinner,sun50i-h5"; fragment@0 { target = <&spi1>; __overlay__ { status = "okay"; spidev@0{ status = "disabled"; }; spidev@1{ status = "disabled"; }; }; }; fragment@1 { target = <&pio>; __overlay__ { waveshare32b_pins: waveshare32b_pins { allwinner,pins = "pa1", "pa0", "pa3" ; allwinner,function = "gpio_in"; }; }; }; fragment@2 { target = <&spi1>; __overlay__ { /* needed to avoid dtc warning */ #address-cells = <1>; #size-cells = <0>; waveshare32b: waveshare32b@0{ compatible = "ilitek,ili9340"; reg = <0>; pinctrl-names = "default"; pinctrl-0 = <&waveshare32b_pins>; spi-max-frequency = <16000000>; txbuflen = <32768>; rotate = <90>; fps = <25>; bgr = <0>; buswidth = <8>; reset-gpios = <&pio 0 0 0>; dc-gpios = <&pio 0 3 0>; debug = <0>; }; waveshare32b_ts: waveshare32b-ts@1 { compatible = "ti,ads7846"; reg = <1>; spi-max-frequency = <2000000>; interrupts = <17 2>; /* high-to-low edge triggered */ interrupt-parent = <&gpio>; pendown-gpio = <&pio 0 1 0>; ti,x-plate-ohms = /bits/ 16 <60>; ti,pressure-max = /bits/ 16 <255>; }; }; }; __overrides__ { speed = <&waveshare32b>,"spi-max-frequency:0"; txbuflen = <&waveshare32b>,"txbuflen:0"; rotate = <&waveshare32b>,"rotate:0"; fps = <&waveshare32b>,"fps:0"; bgr = <&waveshare32b>,"bgr:0"; debug = <&waveshare32b>,"debug:0"; swapxy = <&waveshare32b_ts>,"ti,swap-xy?"; }; }; There are no errors from armbian-add-overlay, but when i reboot the screen is not working, fbtft is not loaded, and i see no messages in dmesg that look like they relate to my efforts. So, any clues? Does anything jump out as being wrong?
  10. Looking through the git logs i found this commit: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/commit/drivers/staging/fbtft?h=staging-testing&id=2962db71c7030868b6859d09b2138b55297df95e Which explains why the 5.4.y kernels don't include fbtft_device, and clarifies that the only way to use one of these devices in the 5.4.y kernel is with a dtoverlay. The reference for that would seem to be here: https://github.com/notro/fbtft/wiki/FBTFT-RPI-overlays Naturally, the rpi overlays will have to be, uh, adjusted, to use them on any platform that is not an rpi. I can't claim to have a deep understanding of how the device trees work, i'm just pretty sure that something that specifies a broadcom platform aint gonna work on an allwinner, rockchip, etc. If i feel a need for masochism i might look into it again. Maybe get some more usd cards so i can keep my working 4.19.y setup static.
  11. I don't want to talk about how long i beat my head against this but i have it working so i thought i would share. First, in the 5.4.y kernels, the fbtft_device module seems to be missing? So i am using 5.90 oragepizero ubuntu bionic next 4.19.57 as my image, kernel is upgraded to 4.19.62-sunxi via regular apt-get upgrade. I have a genuine waveshare 2.8 A rpi lcd. Waveshare states repeatedly that it is compatible with the 3.2 B rpi lcd except for the screen size and number of buttons, so this should work for the 3.2 B lcd as well. This blog post was pretty helpful: https://kaspars.net/blog/spi-display-orange-pi-zero But it leaves out the necessity of enabling the spi bus overlays. So, using armbian-config, go into system -> hardware -> and enable spi-spidev and (I think?) spi-add-cs1 (as recommended by some other posts i have seen). Then edit (as root) /boot/armbianEnv.txt and add these lines: param_spidev_spi_bus=1 param_spidev_spi_cs=1 extraargs="fbcon=map:8" edit /etc/modules-load.d/modules.conf and add these lines: fbtft fbtft_device create /etc/modprobe.d/fbtft.conf containing this line: options fbtft_device rotate=90 name=waveshare32b busnum=1 gpios=dc:3,reset:0 speed=32000000 Here's the kicker though. According to the wiki page for this lcd, the lcd cable select is connected to pin 24 and the touchscreen cs pin is on pin 26 https://www.waveshare.com/wiki/2.8inch_RPi_LCD_(A) But i only had a white screen until i removed the "CS=1" argument from the options line. I don't' get it. Maybe this means i can't use the touch screen, but I'm not sure i want it for my application. But if someone can explain what the logic is there, that would be great. My plan is to ultimately install retropie on it, and remix the "mini commodore pet" retropie enclosure to fit an opi zero instead of a raspberry pi. I've looked at retrorangepi and they don't really target this kind of configuration so that seems like the way to go.
  12. Try changing the cpufreq governor to "userspace" or "performance"
  13. While I am certainly sympathetic to the cause, i found a solution that works (an old Stretch image) and my elderly parents are able to use their 11 year old photo printer and 15 year old scanner over the network instead of by booting up an old Vista machine. So I'm not going to break it. It's on a reasonably secure network and i don't care if it ever sees a single package update as long as it keeps working. I'll read that thread and see if it makes sense to me to give it a try, just to see and report back, on a completely different sd card. The Zero uses a different wifi part than the Lite, doesn't it? I guess I can personally verify that it's not the xr819 next time i am over there. While i was arguing with the current Buster and Bionic issues, I could sit and watch the nmtui-connect screen and it would lose connection anywhere from a couple seconds to a few minutes. And sometimes it would reject the wpa-psk key which i presume was a similar sort of failure. it would also randomly connect to any of the 4 google wifi points regardless of the fact that one of them was 5 feet away from it. Which may just be normal bad behavior.
  14. According to sunxi wiki, opi lite has RTL8189FTV wifi.
  15. fwiw i tried an older debian stretch image with the 4.19.38 kernel and now the wifi is stable, so i think it can be argued that this is in fact a bug in the current kernel.
  16. I have this exact issue. The strange thing is that it happens with the Google Wifi mesh network at my parents house, where i intended to install the device as a print and scan server, but not at home on my wifi. It will stay connected anywhere from a few seconds to 5 or 6 minutes.