Comments (72)
htot
commented on May 28, 2024
1
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.
from meta-intel-edison.
xlla
commented on May 28, 2024
1
@andy-shev @htot
I recheck the asli file and change RST pin to Active Low mode, it works now! it's wonderful! thank you so much!
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~~
from meta-intel-edison.
htot
commented on May 28, 2024
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.
from meta-intel-edison.
xlla
commented on May 28, 2024
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.
from meta-intel-edison.
htot
commented on May 28, 2024
Yes, because pin naming changed mraa needs to be patched.
from meta-intel-edison.
xlla
commented on May 28, 2024
should I upgrade to mraa 2.0 ?
I found gpio_chardev.c in 2.0 branch
from meta-intel-edison.
htot
commented on May 28, 2024
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.
from meta-intel-edison.
xlla
commented on May 28, 2024
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.
from meta-intel-edison.
andy-shev
commented on May 28, 2024
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.
from meta-intel-edison.
andy-shev
commented on May 28, 2024
(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)
from meta-intel-edison.
andy-shev
commented on May 28, 2024
Okay, I got my hands into it and it pretty much works (though requires some fixes against fbtft driver).
Stay tuned!
from meta-intel-edison.
htot
commented on May 28, 2024
Maybe I should get one myself just for fun.
from meta-intel-edison.
andy-shev
commented on May 28, 2024
Necessary kernel patches are pushed to eds-acpi branch. The ACPI tables are pushed to meta-acpi.
from meta-intel-edison.
xlla
commented on May 28, 2024
@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 [email protected] work with old fw-160606.
from meta-intel-edison.
andy-shev
commented on May 28, 2024
@andy-shev thanks for your hard work!
You are welcome!
I will try to test it later.
Tell me if you have any questions.
from meta-intel-edison.
andy-shev
commented on May 28, 2024
All fbtft patches are now in upstream in v5.5. I have also pushed ASL excerpts for SSD1306 to meta-acpi.
from meta-intel-edison.
htot
commented on May 28, 2024
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.
from meta-intel-edison.
andy-shev
commented on May 28, 2024
Closing as everything is in upstream and in corresponding edison-fw repositories.
from meta-intel-edison.
xlla
commented on May 28, 2024
@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.
from meta-intel-edison.
andy-shev
commented on May 28, 2024
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`=1
So, 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 :-)
from meta-intel-edison.
andy-shev
commented on May 28, 2024
@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).
from meta-intel-edison.
xlla
commented on May 28, 2024
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)
from meta-intel-edison.
xlla
commented on May 28, 2024
@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.
from meta-intel-edison.
xlla
commented on May 28, 2024
@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.
from meta-intel-edison.
htot
commented on May 28, 2024
@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.
from meta-intel-edison.
xlla
commented on May 28, 2024
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
from meta-intel-edison.
htot
commented on May 28, 2024
So what is your kernel command line then?
from meta-intel-edison.
xlla
commented on May 28, 2024
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?
from meta-intel-edison.
htot
commented on May 28, 2024
No, I mean actual command line from edison:
journalctl -b | grep "Command line"
from meta-intel-edison.
andy-shev
commented on May 28, 2024
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)
from meta-intel-edison.
andy-shev
commented on May 28, 2024
@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.
from meta-intel-edison.
andy-shev
commented on May 28, 2024
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!).
from meta-intel-edison.
xlla
commented on May 28, 2024
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?
from meta-intel-edison.
htot
commented on May 28, 2024
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=00
But 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
from meta-intel-edison.
xlla
commented on May 28, 2024
@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
from meta-intel-edison.
xlla
commented on May 28, 2024
@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?
from meta-intel-edison.
htot
commented on May 28, 2024
@xlla yes,yes and not that I know of :-)
from meta-intel-edison.
xlla
commented on May 28, 2024
@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.
from meta-intel-edison.
xlla
commented on May 28, 2024
@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
from meta-intel-edison.
xlla
commented on May 28, 2024
@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.
from meta-intel-edison.
htot
commented on May 28, 2024
@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.
from meta-intel-edison.
xlla
commented on May 28, 2024
@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.
from meta-intel-edison.
xlla
commented on May 28, 2024
@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
from meta-intel-edison.
xlla
commented on May 28, 2024
@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.
from meta-intel-edison.
andy-shev
commented on May 28, 2024
@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: westeri/meta-acpi@c6b00d8
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.
from meta-intel-edison.
andy-shev
commented on May 28, 2024
@andy-shev
In _CRS section, we use gpioIoGpioIo(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.
from meta-intel-edison.
andy-shev
commented on May 28, 2024
@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.
from meta-intel-edison.
andy-shev
commented on May 28, 2024
@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
from meta-intel-edison.
andy-shev
commented on May 28, 2024
@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?
from meta-intel-edison.
andy-shev
commented on May 28, 2024
@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.
from meta-intel-edison.
xlla
commented on May 28, 2024
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
from meta-intel-edison.
xlla
commented on May 28, 2024
I didn't see the patch to add MUX30 support to arduino.asli. Are you sure it's there?
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 want to learn how to drive a car first, at last, I am learned how to make a wheel :)
from meta-intel-edison.
xlla
commented on May 28, 2024
Are you sure you have my last patches to
fbtftin your kernel build?
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.
from meta-intel-edison.
andy-shev
commented on May 28, 2024
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.
Since you have fbtft patches applied I think that the problem in the muxing and pin configuration.
Of course as one more try you can take my kernel from GitHub (https://github.com/andy-shev/linux/tree/eds-acpi) and try with it.
Linux edison 5.5.0-edison-acpi-standard #1 SMP Wed Mar 4 15:25:14 UTC 2020 i686 i686 i386 GNU/Linux
Hmm... It's 32-bit one. Maybe I have to check 32-bit build with my SSD1306 OLED module.
Any possibility to take my kernel (see above) built as 64-bit?
[ 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
Hmm... You have crash somewhere, can you share full dmesg?
root@edison:~# gpioinfo 4
line 7: "MUX32_DIR" "oled-reset-mux" output active-high [used]
line 8: "MUX30_DIR" "oled-cmd-mux" output active-high [used]
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.
line 7: "DIG7_PU_PD" "oled-reset-pu" output active-high [used]
line 8: "DIG8_PU_PD" "oled-cmd-pu" input active-high [used]
I think you may leave DIG8 pull down (or whatever I have for SSD1306 case).
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
Hmm... I lack of ideas. As a last resort somebody can send me the module I will try myself.
from meta-intel-edison.
xlla
commented on May 28, 2024
@andy-shev
to isolate problems, I attach another ssd1306 i2c oled display.
use this table,
build a new acpi-tables.deb
disable kernel acpi table load.
install new acpi-tables.deb
create a config file to auto load i2c-dev mod, /etc/modules-load.d/fb.conf
in this round, even /dev/fb0 was missing
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.
from meta-intel-edison.
xlla
commented on May 28, 2024
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)
so, can we change those Soc pin mode by setting some u-boot env variables ?
otherwise, we can't restore arduino sketch function. #78
for ardunio edison board, it was designed to study principle or verify ideas, we want to change pin's function in user space.
from meta-intel-edison.
xlla
commented on May 28, 2024
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)
144is a pin number: https://elixir.bootlin.com/linux/latest/source/drivers/pinctrl/intel/pinctrl-merrifield.c#L242
PinFunction, is this section used to switch Soc pin mode? 144 - GP12 (pwm0) , parameter 3 - 0x0001 switch to pwm mode.
from meta-intel-edison.
andy-shev
commented on May 28, 2024
@andy-shev
to isolate problems, I attach another ssd1306 i2c oled display.
use this table,
build a new acpi-tables.deb
disable kernel acpi table load.
install new acpi-tables.deb
create a config file to auto load i2c-dev mod, /etc/modules-load.d/fb.conf
in this round, even /dev/fb0 was missing
I'm afraid fbtft does not support I2C bus connected devices.
I can use a python project to test spi screen now, keep the hardware wires untouched, the screen works.
This is actually good news!
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 64using 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-1line 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-highline 7: "MUX32_DIR" unused output active-high
line 8: "MUX30_DIR" unused output active-high
What about polarity of reset signal?
Is it active low or high? Same question about DC pin.
from meta-intel-edison.
andy-shev
commented on May 28, 2024
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)
so, can we change those Soc pin mode by setting some u-boot env variables ?
No, in DTS (and it requires to have support in pin control driver in U-Boot, which is absent right now).
otherwise, we can't restore arduino sketch function. #78
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.
for ardunio edison board, it was designed to study principle or verify ideas, we want to change pin's function in user space.
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.
from meta-intel-edison.
andy-shev
commented on May 28, 2024
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)
144is a pin number: https://elixir.bootlin.com/linux/latest/source/drivers/pinctrl/intel/pinctrl-merrifield.c#L242PinFunction, is this section used to switch Soc pin mode? 144 - GP12 (pwm0) , parameter 3 - 0x0001 switch to pwm mode.
Yes, that is the idea, but as I told above there is no ACPI <--> pin control bridge to accomplish it.
from meta-intel-edison.
xlla
commented on May 28, 2024
I'm afraid
fbtftdoes not support I2C bus connected devices.
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
Yes, that is the idea, but as I told above there is no ACPI <--> pin control bridge to accomplish it.
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,
so their related Soc pin mode must be switch correctly via hard code in kernel?
from meta-intel-edison.
andy-shev
commented on May 28, 2024
I'm afraid
fbtftdoes not support I2C bus connected devices.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.
It's interesting, but I don't think I2C is very popular for OLED / TFT screens.
And basically fbtft in the upstream in the frozen state (only bug fixes are accepted).
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).
Reset - active low , pull up need
dc - data mode , pull up
command, pull downYes, that is the idea, but as I told above there is no ACPI <--> pin control bridge to accomplish it.
I saw acpi-tables-load.service can dynamic load aml and take effect. how about this idea #76
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 PinFunction()) is in the TODO list.
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,
so their related Soc pin mode must be switch correctly via hard code in kernel?
We rely on the firmware (or in our case firmware followed by U-Boot) to set pin muxing correctly.
from meta-intel-edison.
htot
commented on May 28, 2024
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.
It's interesting, but I don't think I2C is very popular for OLED / TFT screens.
And basicallyfbtftin the upstream in the frozen state (only bug fixes are accepted).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).
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.
I saw acpi-tables-load.service can dynamic load aml and take effect. how about this idea #76
That is not really the idea. But configfs allows loading/unloading tables on the fly.
Afaik there is a limit to the # of load/unloads (256?).
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
PinFunction()) is in the TODO list.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,
so their related Soc pin mode must be switch correctly via hard code in kernel?
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.
We rely on the firmware (or in our case firmware followed by U-Boot) to set pin muxing correctly.
from meta-intel-edison.
xlla
commented on May 28, 2024
now I found ssd1307fb.c or ssd1306fb-i2c does support I2C device, but absence in our kernel tree.
I found it in another path, drivers/video/fbdev/ssd1307fb.c
I have built it, change acpi device to point it, but could not load it correctly.
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
from meta-intel-edison.
htot
commented on May 28, 2024
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!
from meta-intel-edison.
xlla
commented on May 28, 2024
Yes, it took me a long time to catch on to the ACPI tables, SSDT, aml, yocto development, oled screen spec, etc.
And there still so many terminologies, theories, practices to learn.
It can work is indeed a credit to you @htot @andy-shev
from meta-intel-edison.
htot
commented on May 28, 2024
Not me. But @andy-shev certainly.
from meta-intel-edison.
andy-shev
commented on May 28, 2024
@andy-shev @htot
I recheck the asli file and change RST pin to Active Low mode, it works now! it's wonderful! thank you so much!
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)
from meta-intel-edison.
xlla
commented on May 28, 2024
In my adventure, many files was changed, to avoid lost my work , I have committed them all.
I should to learn how pick up few files and create PR.
all changes in here
from meta-intel-edison.
andy-shev
commented on May 28, 2024
In my adventure, many files was changed, to avoid lost my work , I have committed them all.
I should to learn how pick up few files and create PR.
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
from meta-intel-edison.
andy-shev
commented on May 28, 2024
meta-acpi has now the patch to support SSD1331. Thanks!
from meta-intel-edison.
htot
commented on May 28, 2024
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.
from meta-intel-edison.
Related Issues (20)
- BTRFS rebooted crash HOT 2
- boot failure HOT 12
- Preempt-RT support HOT 4
- ACPI table is not loaded HOT 8
- Integration with Azure HOT 1
- How to use PWM mode? HOT 5
- altering the partition table prevents subsequent dfu updates HOT 3
- requirement for sudo to use flashall.sh HOT 4
- `make debian` broken on master and dunfell HOT 4
- SD card does not work on dunfell branch HOT 69
- SD card not detected properly in U-Boot HOT 9
- Can't use "configure_edison --setup" HOT 9
- Intel Edison can't boot new flashed image HOT 3
- There is no issue with the network, but numactl cannot be downloaded. HOT 2
- Initramfs unpacking failed: invalid magic at start of compressed archive HOT 4
- Issue Building Sumo Branch HOT 1
- Expired gpg keys HOT 3
- [Kirstone] List of required packages does not match YP
- npm i mraa fails HOT 3
- [Kirkstone] missing elfutils-native while building linux-yocto HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from meta-intel-edison.