Closed xlla closed 4 years ago
htot
commented
4 years ago 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.
xlla
commented
4 years ago I think create a asl and customize kernel is too difficult to me now, the best choice is use exist projects in user space. I have tested spi bus by connect mosi to miso, it works. root@edison:/media/sdcard/git/spidev-test# ./spidev_test -v -s 20000000 spi mode: 0x0 bits per word: 8 max speed: 20000000 Hz (20000 KHz) TX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D | ......@....?..................?. RX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D | ......@....?..................?. root@edison:/media/sdcard/git/spidev-test#
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.
htot
commented
4 years ago Yes, because pin naming changed mraa needs to be patched.
xlla
commented
4 years ago should I upgrade to mraa 2.0 ? I found gpio_chardev.c in 2.0 branch
htot
commented
4 years ago 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.
xlla
commented
4 years ago after upgrade mraa to v2.0, spi communication test pass. root@edison:/media/sdcard/test# ./test-spi received: 0 received: 0 received: 1 received: 2 received: 3 received: 4 received: 5 received: 6 received: 7 received: 8 received: 9
As your mentioned, intel_edison_fab_c.c need be update, the led blink test was failure even I use another free pin 7.
andy-shev
commented
4 years ago 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.
andy-shev
commented
4 years ago (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)
andy-shev
commented
4 years ago Okay, I got my hands into it and it pretty much works (though requires some fixes against fbtft driver). Stay tuned!
htot
commented
4 years ago Maybe I should get one myself just for fun.
andy-shev
commented
4 years ago Necessary kernel patches are pushed to eds-acpi branch. The ACPI tables are pushed to meta-acpi.
xlla
commented
4 years ago @andy-shev thanks for your hard work! I will try to test it later. recently I am try to patch intel_edison_fab_c.c to got it work with chardev. I have got mraa@2.0 work with old fw-160606.
andy-shev
commented
4 years ago @andy-shev thanks for your hard work!
You are welcome!
I will try to test it later.
Tell me if you have any questions.
andy-shev
commented
4 years ago All fbtft patches are now in upstream in v5.5. I have also pushed ASL excerpts for SSD1306 to meta-acpi.
htot
commented
4 years ago 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.
andy-shev
commented
4 years ago Closing as everything is in upstream and in corresponding edison-fw repositories.
xlla
commented
4 years ago @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. I have add a ssd1331.asli by mimic dev13035.asl, in Device section, I don't know how to fill _HID, should it unique? in _DSD, should ToUUID unique ? and do not know how to fill "compatible".
then I add oled-spi.asl, to include above file.
enabled CONFIG_FB_TFT_SSD1331 in kernel.
in edison.conf KERNEL_MODULE_AUTOLOAD += "fbtft_device" ACPI_TABLES ?= "arduino.asl oled-spi.asl"
connect ssd1331 screen to Edison Arduino breadboard. after flash firmware and reboot, nothing showed in screen, just black.
# 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.
andy-shev
commented
4 years ago I have add a ssd1331.asli by mimic dev13035.asl,
When you will be ready, I'll be glad to take a PR!
in Device section, I don't know how to fill _HID, should it unique?
In this case it's not unique, because we don't have real ACPI _HID by vendor.
in _DSD, should ToUUID unique ?
No, it's unique in general, but it's dedicated for properties format that is used (for any device) in the Linux kernel.
and do not know how to fill "compatible".
According to the driver: https://elixir.bootlin.com/linux/latest/source/drivers/staging/fbtft/fb_ssd1331.c#L197 Seems you have managed to find a correct one.
in edison.conf KERNEL_MODULE_AUTOLOAD += "fbtft_device" ACPI_TABLES ?= "arduino.asl oled-spi.asl"
This part @htot knows better.
connect ssd1331 screen to Edison Arduino breadboard.
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.
after flash firmware and reboot, nothing showed in screen, just black.
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:
gpioset `gpiofind TRI_STATE_ALL`=0
sleep 2
gpioset `gpiofind TRI_STATE_ALL`=1So, my recommendation to avoid Edison/Arduino board or at least minimize necessary muxing as much as possible.
[ 9.725673] graphics fb0: fb_ssd1331 frame buffer, 96x64, 12 KiB video memory, 4 KiB buffer memory, fps=20, spi5.1 at 16 MHz
Cool! You may imagine how long does it take to me to achieve this :-)
andy-shev
commented
4 years ago @xlla Do you have schematic how exactly you have connected the display? And see above answer.
By the way, you don't need fbtft_device module (and it's actually gone in newer kernels).
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).
xlla
commented
4 years ago According to the driver: ...Seems you have managed to find a correct one.
I haven't found, just simple change 1306 to 1331 :)
(see rather adafruit.asl for the example)
Alright, when I first read the info below, I thought it's an example about tinydrm so I did not read it. I will study it and manage to prepare muxing properly.
Otherwise, tinydrm is working very nice (see adafruit.asl).
Cool! You may imagine how long does it take to me to achieve this :-)
Yes, I could imagine! I have read those posts, to driver an oled screen using fbtft on edison, who need patch kernel, patch fbtft driver...Now I just write a little bit config, then it works! I am standing on the shoulders of giants :) BTW, I saw you had done some help for that fellow too in the end of that article.
@xlla Do you have schematic how exactly you have connected the display? And see above answer.
RST_PIN -> D9 DC_PIN -> D8 CS_PIN -> D10 SCLK_PIN -> D13 MOSI_PIN -> D11 VCC -> V3.3 GND -> GND (Edison Arduino board, J11 -> short 3,4)
xlla
commented
4 years ago @htot Could you tell me how to do a quick deploy? after modify asli/asl files, I built new kernel and copy bzImage-initramfs-edison.bin into ota, rename, then boot to sdcard, nothing changes, still old acpi settings there. has those acpi settings been build into u-boot or into rootfs? can I create a http server and just update relative package through apt-get? flashing giga bytes is very inefficient.
xlla
commented
4 years ago @andy-shev I want to check spi screen function in user space, because I have driven it successful in branch thud. Can I load acpi table spidev.asl and my customized ssd1331.asli both. I observed they are refer to same SPI host controller, Is it illegal? If so , maybe I can rmmod fbtft temperary and access spi device by interface /dev/spi5.1.
Or if I change _HID in ssd1331.asli to SPT0001, will it be recognized by kernel module fbtft and spi module simutaneously.
htot
commented
4 years ago @htot Could you tell me how to do a quick deploy? after modify asli/asl files, I built new kernel and copy bzImage-initramfs-edison.bin into ota, rename, then boot to sdcard, nothing changes, still old acpi settings there. has those acpi settings been build into u-boot or into rootfs?
Neither. They are built into the initramfs and loaded using configfs.
The tables that are built are listed here:
can I create a http server and just update relative package through apt-get? flashing giga bytes is very inefficient.
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.
xlla
commented
4 years ago 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
htot
commented
4 years ago So what is your kernel command line then?
xlla
commented
4 years ago 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?
htot
commented
4 years ago No, I mean actual command line from edison:
journalctl -b | grep "Command line"
andy-shev
commented
4 years ago According to the driver: ...Seems you have managed to find a correct one. I haven't found, just simple change 1306 to 1331 :)
Luck guess then :-)
@xlla Do you have schematic how exactly you have connected the display? And see above answer.
RST_PIN -> D9 DC_PIN -> D8
If you change them, i.e. D9 to D/C, then you may copy'n'paste MUX28 settings from adafruit.asl.
So, your *.asl file will look like
...enable SPI muxing...
...MUX28 settings (for D/C pin on D9, GPIO 183)...
...something similar should be done for D8 (presumable MUX30)...
#include arduino.asli
#include ssd1331.asli (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 GpioIo() and their properties in _DSD).
CS_PIN -> D10 SCLK_PIN -> D13 MOSI_PIN -> D11
These are good as long as you have enabled MUX_SPI.
VCC -> V3.3 GND -> GND (Edison Arduino board, J11 -> short 3,4)
andy-shev
commented
4 years ago @andy-shev I want to check spi screen function in user space, because I have driven it successful in branch thud.
Better approach is to use ConfigFS for that. That's how I'm experimenting with the peripheral at my desk.
andy-shev
commented
4 years ago 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
You are not supposed to have many tables since you are basing your peripheral on Edison/Arduino (hw) layer. Basically regular user of Edison/Arduino is supposed to have only one *.asl file which describes all hardware connected to the board. Splitting is more for advanced users (because order of loading and unloading really matters!).
xlla
commented
4 years ago empty.
root@edison:~# journalctl -b | grep "Command line" root@edison:~#
but I found it in terminal
=> run edsboot 11967136 bytes read in 530 ms (21.5 MiB/s) Valid Boot Flag Setup Size = 0x00004000 Magic signature found Using boot protocol version 2.0d Linux kernel version 5.4.0-edison-acpi-standard (oe-user@oe-host) #1 SMP Thu Feb 20 16:22:28 UTC 2020 Building boot_params at 0x00090000 Loading bzImage at address 100000 (11950752 bytes) Magic signature found Kernel command line: "quiet tty1 console=ttyS2,115200n8 root=/dev/mmcblk1 rootfstype=ext4 systemd.unit=multi-user.target hardware_id=00" Magic signature found
Should I pass acpi flag into it?
htot
commented
4 years ago I don't understand why you get nothing, that is not normal:
root@edison:~# journalctl -b | grep "Command line"
Feb 22 23:32:31 edison kernel: Command line: quiet debugshell=10 tty1 console=ttyS2,115200n8 root=/dev/mmcblk0p8 rootflags=subvol=@new rootfstype=btrfs systemd.unit=multi-user.target hardware_id=00But the reason I asked is that you want to have skiptables on the kernel command line. And you don't, so that explains:
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
xlla
commented
4 years ago @andy-shev I want to learn more about ACPI tables.
In arduino.asli,
It first define 4 gpiochips, NIO(n), all have same ToUUID("~bc9bbf4aa301)
under each Scope (NIO(n)) node, if any macro defined, then a node ToUUID("~1319f52a966b) create, is it just the information about a consumer at special line on gpiochip(n) ?
In the following Package, it likes defined a name of consumer and it's function.
Package () {"ssp5-fs1-pu", "SSPU"},
In consumer's function definition package, the ToUUID point to ("~bc9bbf4aa301), to mark the target line's status to used by current consumer's line-name.
for SSPU
Name (SSPU, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"gpio-hog", 1},
Package () {"gpios", Package () {10, 0}},
Package () {"input", 1},
Package () {"line-name", "ssp5-fs1-pu"},
}
})
parameter 1 of field "gpios" , is it the line number of current gpiochip? field "line-name", is it must unique? I saw name "i2c6-sda-mux" used twice.
for NIO4, the MUX19 and MUX30 was missing, used by pin D6 and D8.
all those functions are control the Muxs on arduino board, but how to control the Soc pin mode?
if I want to use a pwn pin, the correspoding Soc pin mode must be set to 1.
Under PWM0 node,
PinFunction(Exclusive, PullUp, 0x0001,
"\\_SB.FLIS", 0, ResourceConsumer, , ) { 144 }
what is the meaning of "144"? refer to manual, 4 pwm pin just related to (GP12, GP13, GP182, GP183)
if I want to use ADC, how to config acpi table? is there any new api other than
cat /sys/bus/iio/devices/iio:device1/in_voltage0_raw
xlla
commented
4 years ago @htot In edison.conf , is ACPI_FEATURES_edison used to define macro for acpi table compiler? If I choose arduino-all.asl, it has all thoses macro defined, then I does not need config ACPI_FEATURES_edison ?
any example there for use pwm function in acpi mode?
htot
commented
4 years ago @xlla yes,yes and not that I know of :-)
xlla
commented
4 years ago @andy-shev In _CRS section, we use gpioIo
GpioIo(Exclusive, PullUp, 0, 0, IoRestrictionOutputOnly,
"\\_SB.PCI0.GPIO", 0, ResourceConsumer, , ) { 48 }
what is PullUp infer? why we still need define DIG(n)_PU_PD_HOG in somewhere?
You are not supposed to have many tables since you are basing your peripheral on Edison/Arduino (hw) layer
Yes, I have my peripheral fixed on Edison board, but I want my spi screen drive by kernel module fbtft and sometimes just disable kernel module then access spi screen directly. So I can choose /dev/spidev5.1 or /dev/fb0 freely.
xlla
commented
4 years ago @htot My customized acpi table got loaded, but the correspoding aml file was gone, do I miss something.
in edison.conf
ACPI_TABLES ?= "arduino.asl oled-spi.asl spidev.asl"
root@edison:/media/sdcard/study/git/mraa# ls /sys/kernel/config/acpi/table/ arduino oled-spi spidev root@edison:/media/sdcard/study/git/mraa# ls /kernel/firmware/acpi/ arduino.aml spidev.aml
xlla
commented
4 years ago @andy-shev in ssd1306.asli, section _DSD,
Package () { "dc-gpios", Package () { ^OLED, 0, 0, 0 } },
Package () { "reset-gpios", Package () { ^OLED, 1, 0, 1 } },
does those two lines sorted as GpioIo's order in section _CRS ? does this label "dc-gpios" used as a consumer name appear in column 3 at gpioinfo of gpiochip0?
line 49: unnamed "dc" output active-high [used]
line 183: unnamed "reset" output active-low [used]
Package () { ^OLED, 0, 0, 0 }
what is the actual usage of those three number?
I have found some answer in gpio-properties.txt.
htot
commented
4 years ago @htot My customized acpi table got loaded, but the corresponding aml file was gone, do I miss something.
Probably. You didn't explain "how" you get the aml's loaded. Normally they are installed onto the initramfs and loaded at boot. Then when we switch_root, the initramfs disappears, so ls /kernel/firmware/acpi/ does not exist. So, in this case the real question is: why do you have ls /kernel/firmware/acpi/?
Otoh, if you put skiptables on the kernel command line, the tables won't be loaded at all. And ls /kernel/firmware/acpi/ still does not exist. In this case I would expect you copied the acpi-tables package and installed using dpkg or by (reinstalling) using apt-get.
It would really help if you write reproducible steps. Right now I have no idea what you are doing.
xlla
commented
4 years ago @andy-shev to free up pwm3, I connect RESET pin to D7, rename OLED to OLE0(I am not sure if this name format must be 3 letters + 1 number), please see ssd1331.asli and combine all related muxs, pullups, asli files in one file, please see oled-spi.asl, I also rename "oled-spi.aml" to "oledspi.aml" in section DefinitionBlock. (I am not sure if "-" in aml filename is illegal)
in edison.conf, left only 1 asl file
ACPI_TABLES ?= "oled-spi.asl" #ACPI_FEATURES_edison ?= "uart_2w i2c spi"
do bitbake cleansstate acpi-tables & bitbake acpi-tables & make image & flashall.sh now it even more worse:
root@edison:~# journalctl -b | grep "fb" Feb 15 17:20:01 edison kernel: pci 0000:00:01.3: reg 0x10: [mem 0xff3fb000-0xff3fb0ff] Feb 15 17:20:02 edison kernel: fbtft: module is from the staging directory, the quality is unknown, you have been warned. Feb 15 17:20:02 edison kernel: fb_ssd1331: module is from the staging directory, the quality is unknown, you have been warned. Feb 15 17:20:04 edison kernel: fb_ssd1331 spi-PRP0001:01: fbtft_property_value: width = 96 Feb 15 17:20:04 edison kernel: fb_ssd1331 spi-PRP0001:01: fbtft_property_value: height = 64 Feb 15 17:20:04 edison kernel: fb_ssd1331 spi-PRP0001:01: fbtft_property_value: buswidth = 8 Feb 15 17:20:04 edison kernel: fb_ssd1331 spi-PRP0001:01: Missing info about 'dc' gpio. Aborting. Feb 15 17:20:04 edison kernel: fb_ssd1331: probe of spi-PRP0001:01 failed with error -22
I can't find out why the gpio 'dc' info was missing. re-flash 3 times, no lucky.
xlla
commented
4 years ago @htot alright, I found the reason, there are 2 deb files in deb folder,
xlla@u18-1:~/develop/git/out/linux64/build/tmp/work$ ls -al ../deploy/deb/edison/acpi-tables_1.0-r0_i386.deb -rw-r--r-- 2 xlla xlla 2872 3月 1 20:33 ../deploy/deb/edison/acpi-tables_1.0-r0_i386.deb xlla@u18-1:~/develop/git/out/linux64/build/tmp/work$ ls -al ../deploy/deb/corei7-32/acpi-tables_1.0-r0_i386.deb -rw-r--r-- 2 xlla xlla 2642 10月 28 02:19 ../deploy/deb/corei7-32/acpi-tables_1.0-r0_i386.deb
and in my apt-get/sources.list.d/latest.list, "corei7-32" is prior to "edison", whenever I have modify acpi tables and re-create deb, apt-get install -reinstall acpi-tables, it is just installed old ones! after delete old wrong verson deb file and reinstall , latest acpi tables got deployed.
@andy-shev when latest acpi tables got loaded, fbtft got loaded too. I have slow down bus speed to 6Mhz. pull down and up tri_state_all, nothing in screen.
root@edison:~# dmesg |grep fb [ 0.171686] pci 0000:00:01.3: reg 0x10: [mem 0xff3fb000-0xff3fb0ff] [ 7.947374] fbtft: module is from the staging directory, the quality is unknown, you have been warned. [ 7.965430] fb_ssd1331: module is from the staging directory, the quality is unknown, you have been warned. [ 9.420549] fb_ssd1331 spi-PRP0001:01: fbtft_property_value: width = 96 [ 9.420569] fb_ssd1331 spi-PRP0001:01: fbtft_property_value: height = 64 [ 9.420584] fb_ssd1331 spi-PRP0001:01: fbtft_property_value: buswidth = 8 [ 9.420951] fb_ssd1331 spi-PRP0001:01: Missing info about 'dc' gpio. Aborting. [ 9.456429] fb_ssd1331: probe of spi-PRP0001:01 failed with error -22 [10595.309866] fb_ssd1331 spi-PRP0001:01: fbtft_property_value: width = 96 [10595.309884] fb_ssd1331 spi-PRP0001:01: fbtft_property_value: height = 64 [10595.309900] fb_ssd1331 spi-PRP0001:01: fbtft_property_value: buswidth = 8 [10595.458180] graphics fb0: fb_ssd1331 frame buffer, 96x64, 12 KiB video memory, 4 KiB buffer memory, fps=20, spi5.1 at 6 MHz
xlla
commented
4 years ago @andy-shev final schema, RST_PIN -> D7 DC_PIN -> D8 CS_PIN -> D10 SCLK_PIN -> D13 MOSI_PIN -> D11
line 48: unnamed "reset" output active-low [used]
line 49: unnamed "dc" output active-high [used]
...
line 109: unnamed unused input active-high
line 110: unnamed "cs" output active-high [used]
line 111: unnamed "cs" output active-high [used]
line 112: unnamed "cs" output active-high [used]
line 113: unnamed "cs" output active-high [used]
line 114: unnamed unused input active-high
line 115: unnamed 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 8: "SPI_FS_SEL" "ssp5-fs1-mux" output active-high [used]
line 9: "SPI_TXD_SEL" "ssp5-txd-mux" output active-high [used]
line 10: "SPI_RXD_SEL" "ssp5-rxd-mux" output active-high [used]
line 11: "SPI_CLK_SEL" "ssp5-clk-mux" output active-high [used]
line 12: "U16_IO1.4" unused input 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]
for DIG8_PU_PD, I think "cmd" should disable the external pullup resistor, so I set it as a high-impedance input.
andy-shev
commented
4 years ago @andy-shev I want to learn more about ACPI tables.
In arduino.asli,
It first define 4 gpiochips, NIO(n), all have same ToUUID("~bc9bbf4aa301)
under each Scope (NIO(n)) node, if any macro defined, then a node ToUUID("~1319f52a966b) create, is it just the information about a consumer at special line on gpiochip(n) ?
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)
In the following Package, it likes defined a name of consumer and it's function.
Package () {"ssp5-fs1-pu", "SSPU"}, In consumer's function definition package, the ToUUID point to ("~bc9bbf4aa301), to mark the target line's status to used by current consumer's line-name.
for SSPU
Name (SSPU, Package () { ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { Package () {"gpio-hog", 1}, Package () {"gpios", Package () {10, 0}}, Package () {"input", 1}, Package () {"line-name", "ssp5-fs1-pu"}, } })parameter 1 of field "gpios" , is it the line number of current gpiochip? field "line-name", is it must unique? I saw name "i2c6-sda-mux" used twice.
It must be unique in the same scope, For example Device() or Name() starts a new scope. Several GPIO controllers here are siblings in terms of scope (ACPI path).
for NIO4, the MUX19 and MUX30 was missing, used by pin D6 and D8.
You may try to add them in a way how MUX28 done, for example. Look at this commit as an example: https://github.com/westeri/meta-acpi/commit/c6b00d83579265e3a93a6e42347d5087073a97d6
Currently I have no time to look into this, sorry.
all those functions are control the Muxs on arduino board, but how to control the Soc pin mode?
From ACPI v6.2 there are special resources PinFunction() etc. Unfortunately there is no full support of this in the Linux kernel (ACPI <-> pin control subsystem layer is missed).
if I want to use a pwn pin, the correspoding Soc pin mode must be set to 1.
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).
Under PWM0 node,
PinFunction(Exclusive, PullUp, 0x0001, "\_SB.FLIS", 0, ResourceConsumer, , ) { 144 } what is the meaning of "144"? refer to manual, 4 pwm pin just related to (GP12, GP13, GP182, GP183)
144 is a pin number: https://elixir.bootlin.com/linux/latest/source/drivers/pinctrl/intel/pinctrl-merrifield.c#L242
if I want to use ADC, how to config acpi table?
I didn't quite get this. It depends on ADC chip. The bus it's connected to, etc.
is there any new api other than
cat /sys/bus/iio/devices/iio:device1/in_voltage0_raw
It's a new API, user space has libiio to support all this.
andy-shev
commented
4 years ago @andy-shev In _CRS section, we use gpioIo
GpioIo(Exclusive, PullUp, 0, 0, IoRestrictionOutputOnly, "\_SB.PCI0.GPIO", 0, ResourceConsumer, , ) { 48 } what is PullUp infer? why we still need define DIG(n)_PU_PD_HOG in somewhere?
Basically it works in conjunction with Active Low in _DSD(). It defines an initial (presumably not active) state. So, with PullUp we say that the signal will be deasserted and it's Active Low, so, it will issue electrically logical "1" on the pin (+1.8v in our case).
The second question has nothing to do with internal (SoC) pull biases. It's related to Edison/Arduino (see schematic for the details).
You are not supposed to have many tables since you are basing your peripheral on Edison/Arduino (hw) layer
Yes, I have my peripheral fixed on Edison board, but I want my spi screen drive by kernel module fbtft and sometimes just disable kernel module then access spi screen directly. So I can choose /dev/spidev5.1 or /dev/fb0 freely.
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.
andy-shev
commented
4 years ago @andy-shev in ssd1306.asli, section _DSD,
Package () { "dc-gpios", Package () { ^OLED, 0, 0, 0 } }, Package () { "reset-gpios", Package () { ^OLED, 1, 0, 1 } },does those two lines sorted as GpioIo's order in section _CRS ?
Yes, but it doesn't matter. The reference is defined by two first items in the inner Package(), i.e. OLED scope and 0 (for DC pin) or 1 (for Reset pin).
does this label "dc-gpios" used as a consumer name appear in column 3 at gpioinfo of gpiochip0?
Yes, but this is not important. It must be the same as in properties schema for the driver.
line 49: unnamed "dc" output active-high [used] line 183: unnamed "reset" output active-low [used] Package () { ^OLED, 0, 0, 0 } what is the actual usage of those three number?
I have found some answer in gpio-properties.txt.
Right, there is in-kernel documentation for this all.
andy-shev
commented
4 years ago @andy-shev to free up pwm3, I connect RESET pin to D7, rename OLED to OLE0(I am not sure if this name format must be 3 letters + 1 number),
Format is described in the ACPI specification (there allowed characters are listed, the length of the name should not be great than 4).
please see ssd1331.asli
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.
and combine all related muxs, pullups, asli files in one file, please see oled-spi.asl,
Again, I didn't check the pin numbers (7 and 8) in the muxing scheme, cmd better to rename to dc and I have no idea if you need external pull biases for them, otherwise looks good.
I also rename "oled-spi.aml" to "oledspi.aml" in section DefinitionBlock. (I am not sure if "-" in aml filename is illegal)
It doesn't matter. The internal names matters (parameters of DefinitionBlock()).
in edison.conf, left only 1 asl file
ACPI_TABLES ?= "oled-spi.asl"
ACPI_FEATURES_edison ?= "uart_2w i2c spi"
do bitbake cleansstate acpi-tables & bitbake acpi-tables & make image & flashall.sh now it even more worse:
root@edison:~# journalctl -b | grep "fb" Feb 15 17:20:01 edison kernel: pci 0000:00:01.3: reg 0x10: [mem 0xff3fb000-0xff3fb0ff] Feb 15 17:20:02 edison kernel: fbtft: module is from the staging directory, the quality is unknown, you have been warned. Feb 15 17:20:02 edison kernel: fb_ssd1331: module is from the staging directory, the quality is unknown, you have been warned. Feb 15 17:20:04 edison kernel: fb_ssd1331 spi-PRP0001:01: fbtft_property_value: width = 96 Feb 15 17:20:04 edison kernel: fb_ssd1331 spi-PRP0001:01: fbtft_property_value: height = 64 Feb 15 17:20:04 edison kernel: fb_ssd1331 spi-PRP0001:01: fbtft_property_value: buswidth = 8 Feb 15 17:20:04 edison kernel: fb_ssd1331 spi-PRP0001:01: Missing info about 'dc' gpio. Aborting. Feb 15 17:20:04 edison kernel: fb_ssd1331: probe of spi-PRP0001:01 failed with error -22 I can't find out why the gpio 'dc' info was missing. re-flash 3 times, no lucky.
Are you sure you have my last patches to fbtft in your kernel build?
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/commit/drivers/staging/fbtft?id=8b2d3aeeb7ec8110458ba59bf9c8b3af84f1139a
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/commit/drivers/staging/fbtft?id=4bcd9eae731083bb724faf68cce6021213308333
andy-shev
commented
4 years ago @andy-shev when latest acpi tables got loaded, fbtft got loaded too. I have slow down bus speed to 6Mhz. pull down and up tri_state_all, nothing in screen.
root@edison:~# dmesg |grep fb [ 0.171686] pci 0000:00:01.3: reg 0x10: [mem 0xff3fb000-0xff3fb0ff] [ 7.947374] fbtft: module is from the staging directory, the quality is unknown, you have been warned. [ 7.965430] fb_ssd1331: module is from the staging directory, the quality is unknown, you have been warned. [ 9.420549] fb_ssd1331 spi-PRP0001:01: fbtft_property_value: width = 96 [ 9.420569] fb_ssd1331 spi-PRP0001:01: fbtft_property_value: height = 64 [ 9.420584] fb_ssd1331 spi-PRP0001:01: fbtft_property_value: buswidth = 8 [ 9.420951] fb_ssd1331 spi-PRP0001:01: Missing info about 'dc' gpio. Aborting. [ 9.456429] fb_ssd1331: probe of spi-PRP0001:01 failed with error -22
Why do you have these messages?
[10595.309866] fb_ssd1331 spi-PRP0001:01: fbtft_property_value: width = 96 [10595.309884] fb_ssd1331 spi-PRP0001:01: fbtft_property_value: height = 64 [10595.309900] fb_ssd1331 spi-PRP0001:01: fbtft_property_value: buswidth = 8 [10595.458180] graphics fb0: fb_ssd1331 frame buffer, 96x64, 12 KiB video memory, 4 KiB buffer memory, fps=20, spi5.1 at 6 MHz
I didn't see the patch to add MUX30 support to arduino.asli. Are you sure it's there?
andy-shev
commented
4 years ago @andy-shev final schema, RST_PIN -> D7 DC_PIN -> D8 CS_PIN -> D10 SCLK_PIN -> D13 MOSI_PIN -> D11
So far so good :-)
line 48: unnamed "reset" output active-low [used] line 49: unnamed "dc" output active-high [used] ... 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 7: "MUX32_DIR" "oled-reset-mux" output active-high [used] line 8: "MUX30_DIR" "oled-cmd-mux" output active-high [used]
Okay, I found your patch against arduino.asli. Does it work now?
for DIG8_PU_PD, I think "cmd" should disable the external pullup resistor, so I set it as a high-impedance input.
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.
htot
commented
4 years ago 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.
xlla
commented
4 years ago @andy-shev
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 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, and /usr/bin/blink-led will pull down TRI_STATE_ALL always, I have amend it too, but can't display anything to device /dev/fb0
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.