how to get spi screen work in ACPI enable kernel. #74
Comments
|
I believe the idea is acpi table configures the wiring and makes the presence of the display known to the kernel. The kernel driver takes the display. So, you need a display for which a kernel driver exists. And need to create a asl. And then I don't know who you get text or graphics on the device from user space, I haven't tried. I think @andy-shev can tell you more. We can certainly use some documentation in this area. |
|
I think create a asl and customize kernel is too difficult to me now, the best choice is use exist projects in user space. but the spi example in official document "Intel ® Edison Tutorial: SPI, PWM, and More GPIO" was failure, it use the edison as master to communicate with an arduino board through spi, maybe spi function in mraa need be patch. |
|
Yes, because pin naming changed mraa needs to be patched. |
|
should I upgrade to mraa 2.0 ? |
|
Probably. But this https://github.com/intel-iot-devkit/mraa/blob/master/src/x86/intel_edison_fab_c.c is the file that needs updating. |
|
after upgrade mraa to v2.0, spi communication test pass. As your mentioned, intel_edison_fab_c.c need be update, the led blink test was failure even I use another free pin 7. |
|
The idea of upstream is to use the kernel interfaces as much as possible. This will bring an advantage that user space program won't be dependent to one platform with a heavily patched kernel. So, for the OLED / TFT panels, connected to SPI, we have two drivers in the kernel now: a) tinydrm framework with set of individual panel drivers, and b) fbtft driver with support of many other panels. The b) variant is not (yet) suitable for ACPI and thus requires some (in-kernel) coding. Otherwise, tinydrm is working very nice (see adafruit.asl). The user space interface is the Frame Buffer device which is quite long time standard for slow displays. |
|
(And yes, I have SSD1306 SparkFun module to play with, though have no time to see how we can enable it in ACPI with minimum effort) |
|
Okay, I got my hands into it and it pretty much works (though requires some fixes against fbtft driver). |
|
Maybe I should get one myself just for fun. |
|
Necessary kernel patches are pushed to eds-acpi branch. The ACPI tables are pushed to meta-acpi. |
|
@andy-shev thanks for your hard work! |
You are welcome!
Tell me if you have any questions. |
|
All fbtft patches are now in upstream in v5.5. I have also pushed ASL excerpts for SSD1306 to meta-acpi. |
|
The ASl edison: Add support for SparkFun OLED block (DEV-13035) is already in Warrior as well as v5.4 with patches. I am expecting to move to v5.5 with Zeus soon. |
|
Closing as everything is in upstream and in corresponding edison-fw repositories. |
|
@andy-shev I am a newbie in this field, please pardon me for keep asking those question. tinydrm does not support my screen, so I choose fbtft. then I add oled-spi.asl, to include above file. enabled CONFIG_FB_TFT_SSD1331 in kernel. in edison.conf connect ssd1331 screen to Edison Arduino breadboard. # dmesg |grep fb
[ 0.171313] pci 0000:00:01.3: reg 0x10: [mem 0xff3fb000-0xff3fb0ff]
[ 8.049723] fbtft: module is from the staging directory, the quality is unknown, you have been warned.
[ 8.057346] fb_ssd1331: module is from the staging directory, the quality is unknown, you have been warned.
[ 9.580736] fb_ssd1331 spi-PRP0001:00: fbtft_property_value: width = 96
[ 9.580755] fb_ssd1331 spi-PRP0001:00: fbtft_property_value: height = 64
[ 9.580771] fb_ssd1331 spi-PRP0001:00: fbtft_property_value: buswidth = 8
[ 9.725673] graphics fb0: fb_ssd1331 frame buffer, 96x64, 12 KiB video memory, 4 KiB buffer memory, fps=20, spi5.1 at 16 MHz
root@edison:/media/sdcard/git/fbtest# lsmod |grep fb
fb_ssd1331 16384 1
fbtft 32768 1 fb_ssd1331
root@edison:/media/sdcard/git/fbtest# fbset
mode "96x64-0"
# D: 0.000 MHz, H: 0.000 kHz, V: 0.000 Hz
geometry 96 64 96 64 16
timings 0 0 0 0 0 0 0
accel false
rgba 5/11,6/5,5/0,0/0
endmode
I then clone this project to do a test. root@edison:/media/sdcard/git/fbtest# ls /dev/fb* /dev/fb0 root@edison:/media/sdcard/git/fbtest# ./fbtest -f /dev/fb0 Using drawops cfb16 (16 bpp packed pixels) Available visuals: Monochrome Grayscale 32 Truecolor 5:6:5:0 Using visops truecolor Running all tests test001: PASSED test002: PASSED test003: PASSED test004: PASSED test005: PASSED test006: PASSED test008: PASSED Screen size too small for this test test010: PASSED Benchmarking... 10x10 squares: 49.68 Mpixels/s Benchmarking... 20x20 squares: 110.13 Mpixels/s Benchmarking... 50x50 squares: 222.14 Mpixels/s test012: PASSED Benchmarking... R5 circles: 19.20 Mpixels/s Benchmarking... R10 circles: 41.14 Mpixels/s Benchmarking... R25 circles: 101.24 Mpixels/s test013: PASSED It seems fb driver was loaded, fb node was created, test was passed, but nothing appears on screen. |
When you will be ready, I'll be glad to take a PR!
In this case it's not unique, because we don't have real ACPI _HID by vendor.
No, it's unique in general, but it's dedicated for properties format that is used (for any device) in the Linux kernel.
According to the driver: https://elixir.bootlin.com/linux/latest/source/drivers/staging/fbtft/fb_ssd1331.c#L197
This part @htot knows better.
A-ha! This may be a culprit. For Edison/Arduino layer you must to set up proper muxing (see rather adafruit.asl for the example). I can guess that D/C pin is always in Command state, that's why everything is fine, though data is being discarded. Also see below.
Yeah, I think you are quite close (you managed to have /dev/fb0 — it's basically 98% of job being done!). Perhaps GPIOs aren't configured properly. And also there is an issue with Edison/Arduino that you may have to toggle TRI_STATE_ALL, workaround some like this one: So, my recommendation to avoid Edison/Arduino board or at least minimize necessary muxing as much as possible.
Cool! You may imagine how long does it take to me to achieve this :-) |
|
@xlla Do you have schematic how exactly you have connected the display? And see above answer. I also just realized that you probably have v5.4 kernel, you need either plenty of patches or latest one, i.e. v5.5 or any newer (v5.6-rc2 or v5.6-rc3 next Monday). |
I haven't found, just simple change 1306 to 1331 :)
Alright, when I first read the info below, I thought it's an example about tinydrm so I did not read it.
Yes, I could imagine!
RST_PIN -> D9 |
|
@htot Could you tell me how to do a quick deploy? |
|
@andy-shev I want to check spi screen function in user space, because I have driven it successful in branch thud. Or if I change _HID in ssd1331.asli to SPT0001, will it be recognized by kernel module fbtft and spi module simutaneously. |
Neither. They are built into the initramfs and loaded using configfs. The tables that are built are listed here:
The most efficient is to turn off automatic loading of acpi table from the initramfs, compile them manually and load manually. You can then even remove them from memory without reboot. |
root@edison:~# rmdir /sys/kernel/config/acpi/table/oled-spi root@edison:~# rmdir /sys/kernel/config/acpi/table/arduino root@edison:~# apt-get install acpi-tables Reading package lists... Done Building dependency tree Reading state information... Done The following NEW packages will be installed: acpi-tables 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 2642 B of archives. After this operation, 0 B of additional disk space will be used. Get:1 http://xxxx:11111/corei7-32 ./ acpi-tables 1.0-r0 [2642 B] Fetched 2642 B in 0s (41.9 kB/s) Selecting previously unselected package acpi-tables. (Reading database ... 35804 files and directories currently installed.) Preparing to unpack .../acpi-tables_1.0-r0_i386.deb ... Unpacking acpi-tables (1.0-r0) ... Setting up acpi-tables (1.0-r0) ... root@edison:~# systemctl enable acpi-tables-load Created symlink /etc/systemd/system/basic.target.wants/acpi-tables-load.service → /lib/systemd/system/acpi-tables-load.service. root@edison:~# fw_setenv acpi 'quiet skiptables' root@edison:~# reboot root@edison:~# systemctl status acpi-tables-load ● acpi-tables-load.service - ACPI tables load service Loaded: loaded (/lib/systemd/system/acpi-tables-load.service; enabled; vendor preset: enabled) Active: inactive (dead) since Sat 2020-02-15 17:20:08 UTC; 20s ago Process: 569 ExecStart=/usr/bin/acpi-tables-load (code=exited, status=0/SUCCESS) Main PID: 569 (code=exited, status=0/SUCCESS) Feb 15 17:20:08 edison systemd[1]: Started ACPI tables load service. Feb 15 17:20:08 edison acpi-tables-load[569]: mkdir: cannot create directory '/sys/kernel/config/acpi/table/arduino': File exists Feb 15 17:20:08 edison systemd[1]: acpi-tables-load.service: Succeeded. root@edison:~# fw_printenv |grep acpi acpi=quiet skiptables It seems kernel acpi table does be bypassed, /sys/kernel/config/acpi/table/arduino has been created after reboot and before acpi-tables-load.service |
|
So what is your kernel command line then? |
There are so many variable, maybe this, mmc-bootargs=run do_bootargs_rootfs; run do_audio_support; setenv bootargs ${bootargs_rootfs} ${bootargs_console} ${bootargs_debug} g_multi.ethernet_config=${bootargs_ethconfig} systemd.unit=${bootargs_target}.target hardware_id=${hardware_id} g_multi.iSerialNumber=${serial#} g_multi.dev_addr=${usb0addr} ${audio_support}
I am not found any cmd reference env variable {acpi}, does it built in u-boot? |
|
No, I mean actual command line from edison: |
Luck guess then :-)
If you change them, i.e. D9 to D/C, then you may copy'n'paste So, your *.asl file will look like (Or you can use other Dx pin on the connector, see hd44780.asl for D5 muxing and hd44780.asli for line number and its properties, for example. Or for the start you may wire reset pin from display to the deasserted state) In any case don't forget to amend ssd1331.asli accordingly (GPIO line numbers in
These are good as long as you have enabled
|
This is described in the _DSD hierarchy support document (it's really a bit long for the comment here): https://www.kernel.org/doc/Documentation/acpi/DSD-properties-rules.txt (also see the links there)
It must be unique in the same scope, For example
You may try to add them in a way how MUX28 done, for example. Look at this commit as an example: westeri/meta-acpi@c6b00d8 Currently I have no time to look into this, sorry.
From ACPI v6.2 there are special resources
For now it can be done only thru U-Boot (with expanding pin control driver to cover it), or via hard coded board file in the Linux kernel (former is slightly better, since it can be upstreamed, the latter won't be upstreamed ever).
I didn't quite get this. It depends on ADC chip. The bus it's connected to, etc.
It's a new API, user space has |
Basically it works in conjunction with Active Low in The second question has nothing to do with internal (SoC) pull biases. It's related to Edison/Arduino (see schematic for the details).
If you want to do this run-time without reboot, the Config FS approach is the only choice. Otherwise we recommend to have initramfs approach when the table is loaded as soon as possible from initramfs archive. |
Yes, but it doesn't matter. The reference is defined by two first items in the inner
Yes, but this is not important. It must be the same as in properties schema for the driver.
Right, there is in-kernel documentation for this all. |
Format is described in the ACPI specification (there allowed characters are listed, the length of the name should not be great than 4).
I didn't check GPIO numbers according to the schematic, but assuming they are correct everything else looks good. One note, though, that DC pin pull up configuration better to be set to command value (if it's Active high and command means '1', then PullUp, if it's Active low or command is '0', then PullDown), because it might be dangling in unknown state which is not good.
Again, I didn't check the pin numbers (
It doesn't matter. The internal names matters (parameters of
Are you sure you have my last patches to |
Why do you have these messages?
I didn't see the patch to add MUX30 support to arduino.asli. Are you sure it's there? |
So far so good :-)
Okay, I found your patch against arduino.asli. Does it work now?
I don't know that hardware, I mean the OLED you are using, In SSD1306 I simple used internal pull down. I guess it's a right thing to do (at least for me it works), but should be tested on real hardware of course. |
|
This thread is starting to become a help page on how to write an acpi table. When @xlla is done I'll try to see if I can rewrite it into a page for our documentation. |
I have upgrade kernel to v5.5, still can't see anything on spi screen. root@edison:~# uname -a Linux edison 5.5.0-edison-acpi-standard #1 SMP Wed Mar 4 15:25:14 UTC 2020 i686 i686 i386 GNU/Linux root@edison:~# dmesg |grep fb [ 0.174943] pci 0000:00:01.3: reg 0x10: [mem 0xff3fb000-0xff3fb0ff] [ 7.568579] systemd-journald[477]: File /var/log/journal/ecbca1259a044761b2fb3d992c250b0d/system.journal corrupted or uncleanly shut down, renaming and replacing. [ 8.141108] fbtft: module is from the staging directory, the quality is unknown, you have been warned. [ 8.156551] fb_ssd1331: module is from the staging directory, the quality is unknown, you have been warned. [ 9.832628] fb_ssd1331 spi-PRP0001:01: fbtft_property_value: width = 96 [ 9.832649] fb_ssd1331 spi-PRP0001:01: fbtft_property_value: height = 64 [ 9.832664] fb_ssd1331 spi-PRP0001:01: fbtft_property_value: buswidth = 8 [ 9.986702] graphics fb0: fb_ssd1331 frame buffer, 96x64, 12 KiB video memory, 4 KiB buffer memory, fps=20, spi5.1 at 6 MHz [ 13.539565] Modules linked in: spi_pxa2xx_platform dw_dmac usb_f_mass_storage usb_f_rndis u_ether usb_f_acm u_serial libcomposite pwm_lpss_pci pwm_lpss snd_sof_pci snd_sof_intel_byt snd_sof_intel_hda_common snd_sof_intel_ipc intel_mrfld_adc snd_sof intel_mrfld_pwrbtn snd_sof_xtensa_dsp snd_soc_acpi_intel_match snd_soc_acpi spi_pxa2xx_pci brcmfmac brcmutil hci_uart btbcm ti_ads7950 fb_ssd1331(C) industrialio_triggered_buffer kfifo_buf fbtft(C) mmc_block extcon_intel_mrfld sdhci_pci cqhci sdhci led_class mmc_core intel_soc_pmic_mrfld [ 13.540090] EIP: 0xb7efb8e5 root@edison:~# gpioinfo 4 gpiochip4 - 16 lines: line 0: "MUX33_DIR" "uart1-rx-oe" output active-high [used] line 1: "MUX31_DIR" "uart1-tx-oe" output active-high [used] line 2: "MUX29_DIR" unused input active-high line 3: "MUX27_DIR" unused input active-high line 4: "MUX24_DIR" unused input active-high line 5: "MUX21_DIR" unused input active-high line 6: "MUX19_DIR" unused output active-high line 7: "MUX32_DIR" "oled-reset-mux" output active-high [used] line 8: "MUX30_DIR" "oled-cmd-mux" output active-high [used] line 9: "MUX28_DIR" unused input active-high line 10: "MUX26_DIR" "ssp5-fs1-oe" output active-high [used] line 11: "MUX23_DIR" "ssp5-txd-oe" output active-high [used] line 12: "MUX20_DIR" "ssp5-rxd-oe" output active-high [used] line 13: "MUX18_DIR" "ssp5-clk-oe" output active-high [used] line 14: "MUX22_SEL" "ssp5-txd-mux" output active-high [used] line 15: "MUX25_SEL" "ssp5-fs1-mux" output active-high [used] root@edison:~# gpioinfo 2 gpiochip2 - 16 lines: line 0: "DIG0_PU_PD" "uart1-rx-pu" input active-high [used] line 1: "DIG1_PU_PD" "uart1-tx-pu" input active-high [used] line 2: "DIG2_PU_PD" unused input active-high line 3: "DIG3_PU_PD" unused input active-high line 4: "DIG4_PU_PD" unused input active-high line 5: "DIG5_PU_PD" unused input active-high line 6: "DIG6_PU_PD" unused input active-high line 7: "DIG7_PU_PD" "oled-reset-pu" output active-high [used] line 8: "DIG8_PU_PD" "oled-cmd-pu" input active-high [used] line 9: "DIG9_PU_PD" unused input active-high line 10: "DIG10_PU_PD" "ssp5-fs1-pu" input active-high [used] line 11: "DIG11_PU_PD" "ssp5-txd-pu" input active-high [used] line 12: "DIG12_PU_PD" "ssp5-rxd-pu" input active-high [used] line 13: "DIG13_PU_PD" "ssp5-clk-pu" input active-high [used] line 14: "U39_IO1.6" unused input active-high line 15: "U39_IO1.7" unused input active-high I have notice /usr/bin/blink-led will operate "MUX18_DIR", I manual change it to another free pin D6, |
I want to learn how to drive a car first, at last, I am learned how to make a wheel :) |
Yes, I have checked fbtft-core.c in build/tmp/work-shared/edison/kernel-source/drivers/staging/fbtft/, it does include all amendment of those two patches. |
Since you have
Hmm... It's 32-bit one. Maybe I have to check 32-bit build with my SSD1306 OLED module.
Hmm... You have crash somewhere, can you share full dmesg?
By the way, have you checked Edison/Arduino schematics to understand which GPIO line is actually muxed by these settings? Okay, I see that D7 and D8 is easy to connect, there is no complex muxing on top of them. So, above should be correct then.
I think you may leave DIG8 pull down (or whatever I have for SSD1306 case).
Hmm... I lack of ideas. As a last resort somebody can send me the module I will try myself. |
|
@andy-shev root@edison:~# dmesg |grep fb [ 0.175322] pci 0000:00:01.3: reg 0x10: [mem 0xff3fb000-0xff3fb0ff] [ 8.138422] systemd-journald[470]: File /var/log/journal/ecbca1259a044761b2fb3d992c250b0d/system.journal corrupted or uncleanly shut down, renaming and replacing. [ 14.171535] fbtft: module is from the staging directory, the quality is unknown, you have been warned. [ 14.195576] fb_ssd1306: module is from the staging directory, the quality is unknown, you have been warned. root@edison:~# lsmod |grep i2c i2c_dev 20480 0 root@edison:~# modinfo fbtft filename: /lib/modules/5.5.0-edison-acpi-standard/kernel/drivers/staging/fbtft/fbtft.ko license: GPL depends: staging: Y retpoline: Y intree: Y name: fbtft vermagic: 5.5.0-edison-acpi-standard SMP mod_unload 686 parm: debug:override device debug level (ulong) root@edison:~# modinfo fb_ssd1306 filename: /lib/modules/5.5.0-edison-acpi-standard/kernel/drivers/staging/fbtft/fb_ssd1306.ko license: GPL author: Noralf Tronnes description: SSD1306 OLED Driver alias: platform:ssd1306 alias: spi:ssd1306 alias: platform:fb_ssd1306 alias: spi:fb_ssd1306 alias: of:N*T*Csolomon,ssd1306C* alias: of:N*T*Csolomon,ssd1306 depends: fbtft staging: Y retpoline: Y intree: Y name: fb_ssd1306 vermagic: 5.5.0-edison-acpi-standard SMP mod_unload 686 root@edison:~# modinfo i2c-dev filename: /lib/modules/5.5.0-edison-acpi-standard/kernel/drivers/i2c/i2c-dev.ko license: GPL description: I2C /dev entries driver author: Frodo Looijaard and Simon G. Vogl depends: retpoline: Y intree: Y name: i2c_dev vermagic: 5.5.0-edison-acpi-standard SMP mod_unload 686 I can use a python project to test spi screen now, keep the hardware wires untouched, the screen works. root@edison:~# welcome.py --display ssd1331 --width 96 --gpio-data-command 8 --gpio-reset 7 --spi-port 5 --spi-device 1 --interface spi --gpio gpiod --spi-bus-speed 1000000 Version: luma.oled 3.4.0 (luma.core 1.13.0) Display: ssd1331 Interface: spi Dimensions: 96 x 64 ------------------------------------------------------------ using libgpiod... no need cleanup init spi... init bitbang ... clk:None, sda:None, ce:None config luma.core.dc, 8 - mux30 config luma.core.reset, 7 - mux32 spi port-5, device-1 line 48: unnamed "luma.core.reset" output active-high [used] line 49: unnamed "luma.core.dc" output active-high [used] line 7: "DIG7_PU_PD" unused output active-high line 8: "DIG8_PU_PD" unused input active-high line 7: "MUX32_DIR" unused output active-high line 8: "MUX30_DIR" unused output active-high I can driven another i2c ssd1306 screen simultaneously in another session. welcome.py --display ssd1306 --i2c-port 6 Version: luma.oled 3.4.0 (luma.core 1.13.0) Display: ssd1306 Interface: i2c Dimensions: 128 x 64 both screen works well, it prove my hardware was fine, wires connection was right. |
so, can we change those Soc pin mode by setting some u-boot env variables ? for ardunio edison board, it was designed to study principle or verify ideas, we want to change pin's function in user space. |
PinFunction, is this section used to switch Soc pin mode? 144 - GP12 (pwm0) , parameter 3 - 0x0001 switch to pwm mode. |
I'm afraid
This is actually good news!
What about polarity of reset signal? |
No, in DTS (and it requires to have support in pin control driver in U-Boot, which is absent right now).
For now the only thing to configure pins is a boot time (from Linux perspective). In the Linux driver may only switch pins to GPIO mode, and that's it.
I understand that. Unfortunately Intel abandoned IoT sector and thus there is a little activity in the direction of supporting pin reconfiguration at run-time. |
Yes, that is the idea, but as I told above there is no ACPI <--> pin control bridge to accomplish it. |
at first I think it can switch underlay device transparently, now I found ssd1307fb.c or ssd1306fb-i2c does support I2C device, but absence in our kernel tree. Reset - active low , pull up need
dc - data mode , pull up
command, pull down
I saw acpi-tables-load.service can dynamic load aml and take effect. how about this idea #76 If that just is an idea then _SB.PCI0.pwm0 and _SB.PCI0.SPI6 does not work in now? I am not found more PinFunction usage other than pwm0 and spi6, but i2c and spi does work, |
It's interesting, but I don't think I2C is very popular for OLED / TFT screens. Nevertheless we may have it in the kernel here, if @htot will have time and will to do that. But see above, priority of that would be low, since we have more important back log (for me, upstreaming USB DR is #1 now, followed by true switch to ACPI (removing SFI and friends from upstream completely).
This is doubtful feature, because it means you have not fixed hardware and from electrical point of view it can make the real damages to the hardware. The mechanism: 1) power off; 2) change tables / boot loader / etc; 3) boot again pretty much workable solution. That's why pin muxing will be quite unlikely upstreamed. Though, ACPI table mechanism (as been showed by these special keywords, like
We rely on the firmware (or in our case firmware followed by U-Boot) to set pin muxing correctly. |
If the driver is in the vanilla kernel, we can add a 'kernel fragment' to build it. I would take that patch from @xlla. But if it is out of tree you need to patch the kernel yourself.
That is not really the idea. But configfs allows loading/unloading tables on the fly.
There was the idea where we could create a method in acpi that changes pin mode. And that we could trigger from user space. I forgot about the details.
|
I found it in another path, drivers/video/fbdev/ssd1307fb.c root@edison:~# modprobe ssd1307fb root@edison:~# lsmod |grep fb ssd1307fb 24576 0 backlight 20480 1 ssd1307fb root@edison:~# modprobe fbtft root@edison:~# lsmod |grep fb fbtft 32768 0 ssd1307fb 24576 0 backlight 20480 1 ssd1307fb root@edison:~# ls /dev/fb ls: cannot access '/dev/fb': No such file or directory root@edison:~# lsmod |grep i2c i2c_dev 20480 0 root@edison:~# ls -l /sys/class/graphics/ total 0 lrwxrwxrwx 1 root root 0 Mar 19 23:58 fbcon -> ../../devices/virtual/graphics/fbcon I think maybe it does not support acpi entry, then I try to load by manual root@edison:~# echo ssd1306fb 0x3c > /sys/class/i2c-adapter/i2c-1/new_device [ 1679.686402] ssd1307fb 1-003c: No device tree data found! root@edison:~# echo ssd1307fb 0x3c > /sys/class/i2c-adapter/i2c-1/new_device [ 1699.797480] i2c i2c-1: Failed to register i2c client ssd1307fb at 0x3c (-16) -sh: echo: write error: Device or resource busy root@edison:~# echo ssd1306fb 0x3c > /sys/class/i2c-adapter/i2c-1/new_device [ 1717.675712] i2c i2c-1: Failed to register i2c client ssd1306fb at 0x3c (-16) -sh: echo: write error: Device or resource busy |
|
@andy-shev @htot Last login: Fri Mar 20 01:41:51 CST 2020 on ttyS2 root@edison:~# /usr/bin/acpi-tables-load oled-spi install oled-spi ... done. root@edison:~# lsmod |grep fb fb_ssd1331 16384 1 fbtft 32768 1 fb_ssd1331 root@edison:~# ls /dev/fb0 /dev/fb0 root@edison:/mnt/study/git/fbtest# ./fbtest Using drawops cfb16 (16 bpp packed pixels) Available visuals: Monochrome Grayscale 32 Truecolor 5:6:5:0 Using visops truecolor Running all tests test001: PASSED test002: PASSED test003: PASSED test004: PASSED test005: PASSED test006: PASSED test008: PASSED Screen size too small for this test test010: PASSED Benchmarking... 10x10 squares: 15.41 Mpixels/s Benchmarking... 20x20 squares: 31.62 Mpixels/s Benchmarking... 50x50 squares: 69.86 Mpixels/s test012: PASSED Benchmarking... R5 circles: 5.33 Mpixels/s Benchmarking... R10 circles: 12.31 Mpixels/s Benchmarking... R25 circles: 24.88 Mpixels/s test013: PASSED root@edison:/mnt/study/git/fbtest# ls /sys/class/graphics/ fb0 fbcon root@edison:/mnt/study/git/fbtest# cat /sys/class/vtconsole/vtcon1/name (M) frame buffer device root@edison:/mnt/study/git/fbtest# fbset mode "96x64-0" # D: 0.000 MHz, H: 0.000 kHz, V: 0.000 Hz geometry 96 64 96 64 16 timings 0 0 0 0 0 0 0 accel false rgba 5/11,6/5,5/0,0/0 endmode line 48: unnamed "reset" output active-low [used] line 49: unnamed "dc" output active-high [used] line 7: "DIG7_PU_PD" "oled-reset-pu" input active-high [used] line 8: "DIG8_PU_PD" "oled-dc-pu" input active-high [used] Cheers~~ |
|
Ok wow! This has been quite a journey you have undertaken. If you would write like a tutorial page on who to get such a device working that would be great! |
|
Yes, it took me a long time to catch on to the ACPI tables, SSDT, aml, yocto development, oled screen spec, etc. |
|
Not me. But @andy-shev certainly. |
Glad to hear this! Now, can you cleanup and submit a PR with changes you have done so far? (first patch to amend arduino.asli, i.e. adding necessary muxes, second one adding two files. i.e. ssd1331.asli and ssd1331.asl) |
|
In my adventure, many files was changed, to avoid lost my work , I have committed them all. |
A good chance to dive into Git. Keywords to be helpful in this case: interactive rebase, squash, soft reset. PtoGit is a very, very good book (and it's free): https://git-scm.com/book/en/v2 |
|
|
|
Great! @xlla would you like to write a page on getting "the ACPI tables, SSDT, aml, yocto development, oled screen spec, etc."? It would be of great benefit to other developers, starting from scratch to working device. |
I want to driver oled screen in spi mode, it is need additional pins, RST and D/C
in master(thud) branch, x86 32bit mode,
acpi settings:
ACPI_TABLES ?= "arduino.asl spidev.asl"
ACPI_FEATURES_edison ?= "uart_2w i2c spi"
should I use arduino-all.asl? I saw there is a macro for spi, #define MUX_SPI
to simplify operation, I choice pin7 & pin8 for D/C , RST; so I don't need set any Mux or Soc pin mode.
I think I should set these pins to output by set gpio255/223 and gpio256/224, but I don't know how to find them with libgpiod,
root@edison:~# gpiofind 'U34_IO0.7'
nothing found.
or if I set mode to LINE_REQ_DIR_OUT in libgpiod for gpio48/49 , all necessary setting will done automatically?
and I guest name of gpio48/49 is DIG7_PU_PD/DIG8_PU_PD, is it right?
and if I choice some pin need configure mux and soc pin mode, how find their name in libgpiod?
and if I want made all those operation automatically, how to write correct asl file? I found adafruit.asl is very close to my goal, but I don't know how to get start, would you please give me some advice.
The text was updated successfully, but these errors were encountered: