notro / fbtft

Linux Framebuffer drivers for small TFT LCD display modules. Development has moved to https://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/tree/drivers/staging/fbtft?h=staging-testing
1.85k stars 496 forks source link

iMX-7S with OLED C Click (MikroBus Standard) #465

Closed chaunnt closed 3 years ago

chaunnt commented 7 years ago

Can I use this driver with iMX-7S Board to enable & run OLED C Click display ?

chaunnt commented 7 years ago

I got linux kernel from https://github.com/WaRP7/linux-fslc/tree/4.1-1.0.x-imx/Documentation/devicetree/bindings

But when I run "modprobe fbtft_device name=pioled" to test it. It always return

spi_busnum_to_master(0) returned NULL

I 've checked SPI in menuconfig, spidev.ko was built and installed. I 've also modified imx7s-warp.dts => change ecspi1-2-3-4 from "Disabled" to "Okay"

notro commented 7 years ago

spi_busnum_to_master(0) returned NULL

This means that spi bus number 0 (zero) is not available when you load the module (spidev is not used).

chaunnt commented 7 years ago

actually, I search alot but I do not know how to enable SPI or spidev in my WARP7 board :( Sorry but I 've never worked in linux (embedded) before.

chaunnt commented 7 years ago

in my imx7s-warp.dts, I added

&ecspi1 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_ecspi1>; status = "okay"; };

&ecspi2 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_ecspi1>; status = "okay"; };

&ecspi3 { fsl,spi-num-chipselects = <0>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_ecspi3>; status = "okay"; spidev@0x00 { compatible = "spidev"; spi-max-frequency = <20000000>; reg = <0>; }; spidev@0x01 { compatible = "spidev"; spi-max-frequency = <20000000>; reg = <1>; }; };

&iomuxc { pinctrl-names = "default"; ecspi3 { pinctrl_ecspi3: ecspi3grp { fsl,pins = < MX7D_PAD_ECSPI2_SCLKMKBUS_ESPI3_SCLK 0x80000000 MX7D_PAD_ECSPI2_MOSI__MKBUS_ESPI3_MOSI 0x80000000 MX7D_PAD_ECSPI2_MISOMKBUS_ESPI3_MISO 0x80000000 MX7D_PAD_ECSPI2_SS0__MKBUS_ESPI3_SS0_B 0x80000000

; }; imx7d-sdb { ................. ................. pinctrl_ecspi1: ecspi1grp { fsl,pins = < MX7D_PAD_ECSPI1_SCLKMKBUS_UART5_TXD 0x80000000 MX7D_PAD_ECSPI1_MOSIMKBUS_UART5_RXD 0x80000000 ; }; pinctrl_ecspi2: ecspi2grp { fsl,pins = < MX7D_PAD_ECSPI2_SCLKMKBUS_ESPI3_SCLK 0x80000000 MX7D_PAD_ECSPI2_MOSIMKBUS_ESPI3_MOSI 0x80000000 MX7D_PAD_ECSPI2_MISO__MKBUS_ESPI3_MISO 0x80000000 MX7D_PAD_ECSPI2_SS0__MKBUS_ESPI3_SS0_B 0x80000000 ; }; ..... };

But error occured when I build imx7s-warp.dtb file. Error: arch/arm/boot/dts/imx7s-warp.dts:388.5-6 syntax error FATAL ERROR: Unable to parse input tree make[1]: [arch/arm/boot/dts/imx7s-warp.dtb] Error 1 make: [imx7s-warp.dtb] Error 2

chaunnt commented 7 years ago

I correct it. === Now DTS file is ..... &iomuxc { pinctrl-names = "default"; ecspi3 { pinctrl_ecspi3: ecspi3grp { fsl,pins = < MX7D_PAD_ECSPI2_SCLKGPIO4_IO20 0x80000000 MX7D_PAD_ECSPI2_MOSIGPIO4_IO21 0x80000000 MX7D_PAD_ECSPI2_MISOGPIO4_IO22 0x80000000 MX7D_PAD_ECSPI2_SS0GPIO4_IO23 0x80000000 / NOT SURE /

; }; }; imx7d-sdb { ...... pinctrl_ecspi2: ecspi2grp { fsl,pins = < MX7D_PAD_ECSPI2_SCLKGPIO4_IO20 0x80000000 MX7D_PAD_ECSPI2_MOSIGPIO4_IO21 0x80000000 MX7D_PAD_ECSPI2_MISOGPIO4_IO22 0x80000000 MX7D_PAD_ECSPI2_SS0GPIO4_IO23 0x80000000 / NOT SURE / ; }; pinctrl_i2c1: i2c1grp { fsl,pins = < MX7D_PAD_I2C1_SDAI2C1_SDA 0x4000007f MX7D_PAD_I2C1_SCLI2C1_SCL 0x4000007f ; };

Next error is: Reference to non-existent node or label "pinctrl_spi1" I can not find pinctrl_spi1 usage or definition anywhere

notro commented 7 years ago

This question is better asked in a forum with knowledge about the board.

chaunnt commented 7 years ago

Thank you notro. we will modify it and back again

chaunnt commented 7 years ago

Hi notro After I modify my dts file. I'm now can enable spidev. I have folder /dev/spidev1.0 I run to test some command.

  1. dmesg | grep spi => OK spi_imx 30830000.ecspi: registered master spi1 spi spi1.0: spi_imx_setup: mode 4, 8 bpw, 20000000 hz spi spi1.0: setup mode 0, cs_high, 8 bits/w, 20000000 Hz max --> 0 spi_imx 30830000.ecspi: registered child spi1.0 spi_imx 30830000.ecspi: probed

  2. modprobe fbtft => OK

  3. modprobe fb_ssd1351 => OK (My OLED display is Oled C Click and it is using SSD1351 controller)

  4. modprobe fbtft_devices name=pioled debug=3 => Still this error spi_busnum_to_master(0) returned NULL

chaunnt commented 7 years ago

Hi notro Sorry for my naive. I realize I use wrong bus num Now, i run "modprobe fbtft_devices name=pioled debug=3 busnum=1 Then output seem ok

btft_device: module is from the staging directory, the quality is unknown, you have been warned. fbtft_device: SPI devices registered: fbtft_device: spidev spi1.0 20000kHz 8 bits mode=0x04 fbtft_device: 'fb' Platform devices registered: fbtft_device: display not supported: 'ssd1351' modprobe: ERROR: could not insert 'fbtft_device': Invalid argument root@imx7s-warp:~# modprobe fbtft_device name=pioled debug=3 busnum=1 fbtft_device: module is from the staging directory, the quality is unknown, you have been warned. fbtft_device: SPI devices registered: fbtft_device: spidev spi1.0 20000kHz 8 bits mode=0x04 fbtft_device: 'fb' Platform devices registered: fbtft_device: Deleting spi1.0 fb_ssd1351 spi1.0: fbtft_gamma_parse_str() str= fb_ssd1351 spi1.0: 0 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 4 4 4 4 4 4 4 4 4 4 4 4 fb_ssd1351 spi1.0: fbtft_request_gpios: 'reset' = GPIO24 fb_ssd1351 spi1.0: fbtft_request_gpios: 'dc' = GPIO25 fb_ssd1351 spi1.0: fbtft_verify_gpios() fb_ssd1351 spi1.0: init_display() fb_ssd1351 spi1.0: fbtft_reset() fb_ssd1351 spi1.0: set_var() fb_ssd1351 spi1.0: Display update: 1073 kB/s (29.814 ms), fps=0 (0.000 ms) fb_ssd1351 spi1.0: set_gamma() Console: switching to colour frame buffer device 16x16 graphics fb0: fb_ssd1351 frame buffer, 128x128, 32 KiB video memory, 4 KiB DMA buffer memory, fps=20, spi1.0 at 20 MHz fbtft_device: GPIOS used by 'pioled': fbtft_device: 'reset' = GPIO24 fbtft_device: 'dc' = GPIO25 fbtft_device: SPI devices registered: fbtft_device: fb_ssd1351 spi1.0 20000kHz 8 bits mode=0x02

Then /dev/fb0 folder is created. But this is only for test fbtft. I think I should create my own device in fbtft_device. But I want to ask about these line.

            .display = {
                .buswidth = 8,
            },
            .bgr = true,
            .gpios = (const struct fbtft_gpio []) {
                { "reset", 24 },
                { "dc", 25 },
                {},
            },
            .gamma =    "0 2 2 2 2 2 2 2 " \
                    "2 2 2 2 2 2 2 2 " \
                    "2 2 2 2 2 2 2 2 " \
                    "2 2 2 2 2 2 2 3 " \
                    "3 3 3 3 3 3 3 3 " \
                    "3 3 3 3 3 3 3 3 " \
                    "3 3 3 4 4 4 4 4 " \
                    "4 4 4 4 4 4 4"

==

notro commented 7 years ago

is gamma needed for OLED display ? I use OLED C Click (MikroBus standard)

Not to make it work, but you might need to change the default to get the best colors.

where can i get number "24", "25"

These are the gpio numbers you connect to. These numbers differ among boards and there can be multiple gpio controllers. Here's the ones available on a Pi running the mainline kernel:

$ ls -l /sys/class/gpio/
total 0
-rwxrwx--- 1 root gpio 4096 Jun  1 22:03 export
lrwxrwxrwx 1 root gpio    0 Jun  1 22:03 gpiochip458 -> ../../devices/platform/soc/20200000.gpio/gpio/gpiochip458
-rwxrwx--- 1 root gpio 4096 Jun  1 22:03 unexport

$ cat /sys/class/gpio/gpiochip458/{base,ngpio}
458
54

$ sudo cat /sys/kernel/debug/gpio
gpiochip0: GPIOs 458-511, parent: platform/20200000.gpio, pinctrl-bcm2835:
 gpio-458 (SDA0                )
 gpio-459 (SCL0                )
 gpio-460 (SDA1                )
 gpio-461 (SCL1                )
 gpio-462 (GPIO_GCLK           )
 gpio-463 (GPIO5               )
 gpio-464 (GPIO6               )
 gpio-465 (SPI_CE1_N           )
 gpio-466 (SPI_CE0_N           )
 gpio-467 (SPI_MISO            )
 gpio-468 (SPI_MOSI            )
 gpio-469 (SPI_SCLK            )
 gpio-470 (GPIO12              )
 gpio-471 (GPIO13              )
 gpio-472 (TXD0                )
 gpio-473 (RXD0                |discharge           ) out lo
 gpio-474 (GPIO16              )
 gpio-475 (GPIO17              )
 gpio-476 (GPIO18              )
 gpio-477 (GPIO19              )
 gpio-478 (GPIO20              )
 gpio-479 (GPIO21              )
 gpio-480 (GPIO22              )
 gpio-481 (GPIO23              |panel-on            ) out lo
 gpio-482 (GPIO24              |reset               ) out lo
 gpio-483 (GPIO25              |busy                ) in  lo
 gpio-484 (GPIO26              )
 gpio-485 (GPIO27              )
 gpio-486 (SDA0                )
 gpio-487 (SCL0                )
 gpio-488 (NC                  )
 gpio-489 (LAN_RUN             )
 gpio-490 (CAM_GPIO1           )
 gpio-491 (NC                  )
 gpio-492 (NC                  )
 gpio-493 (PWR_LOW_N           |PWR                 ) out lo
 gpio-494 (NC                  )
 gpio-495 (NC                  )
 gpio-496 (USB_LIMIT           )
 gpio-497 (NC                  )
 gpio-498 (PWM0_OUT            )
 gpio-499 (CAM_GPIO0           )
 gpio-500 (NC                  )
 gpio-501 (NC                  )
 gpio-502 (ETHCLK              )
 gpio-503 (PWM1_OUT            )
 gpio-504 (HDMI_HPD_N          )
 gpio-505 (STATUS_LED          |ACT                 ) out lo
 gpio-506 (SD_CLK_R            )
 gpio-507 (SD_CMD_R            )
 gpio-508 (SD_DATA0_R          )
 gpio-509 (SD_DATA1_R          )
 gpio-510 (SD_DATA2_R          )
 gpio-511 (SD_DATA3_R          )

do i need to define more than "reset","dc" gpio ? "AN", "INT", "PWM","RST"

Those seems the be microbus signal names. AN is mapped to R/W which seems to be on the controller. INT to EN which is controlling power? PWM to D/C on the controller (dc) RST is reset

chaunnt commented 7 years ago

Hi Notro

Thank for your kindly support

  1. About gamma -> I understand. I will keep it default.
  2. About number "24" ,"25" When I run command "cat /sys/kernel/debug/gpio" . it returns as below:

root@imx7s-warp:~# cat /sys/kernel/debug/gpio GPIOs 0-31, platform/30200000.gpio, 30200000.gpio: gpio-24 (fb_ssd1351 ) out lo
gpio-25 (fb_ssd1351 ) out lo

GPIOs 32-63, platform/30210000.gpio, 30210000.gpio:

GPIOs 64-95, platform/30220000.gpio, 30220000.gpio:

GPIOs 96-127, platform/30230000.gpio, 30230000.gpio: gpio-119 (spi_imx ) out lo

GPIOs 128-159, platform/30240000.gpio, 30240000.gpio: gpio-138 (brcm_reg ) out lo
gpio-145 (bt_reg ) out lo

GPIOs 160-191, platform/30250000.gpio, 30250000.gpio:

GPIOs 192-223, platform/30260000.gpio, 30260000.gpio: gpio-193 (Back ) in lo

And when I run command "ls -l /sys/class/gpio/"

root@imx7s-warp:~# ls -l /sys/class/gpio/ --w------- 1 root root 4096 May 24 12:10 export lrwxrwxrwx 1 root root 0 May 24 12:10 gpiochip0 -> ../../devices/platform/soc/30000000.aips-bus/30200000.gpio/gpio/gpiochip0 lrwxrwxrwx 1 root root 0 May 24 12:10 gpiochip128 -> ../../devices/platform/soc/30000000.aips-bus/30240000.gpio/gpio/gpiochip128 lrwxrwxrwx 1 root root 0 May 24 12:10 gpiochip160 -> ../../devices/platform/soc/30000000.aips-bus/30250000.gpio/gpio/gpiochip160 lrwxrwxrwx 1 root root 0 May 24 12:10 gpiochip192 -> ../../devices/platform/soc/30000000.aips-bus/30260000.gpio/gpio/gpiochip192 lrwxrwxrwx 1 root root 0 May 24 12:10 gpiochip32 -> ../../devices/platform/soc/30000000.aips-bus/30210000.gpio/gpio/gpiochip32 lrwxrwxrwx 1 root root 0 May 24 12:10 gpiochip64 -> ../../devices/platform/soc/30000000.aips-bus/30220000.gpio/gpio/gpiochip64 lrwxrwxrwx 1 root root 0 May 24 12:10 gpiochip96 -> ../../devices/platform/soc/30000000.aips-bus/30230000.gpio/gpio/gpiochip96 --w------- 1 root root 4096 May 24 12:10 unexport

But when I use "echo" command

root@imx7s-warp:~# cd /sys/class/gpio root@imx7s-warp:/sys/class/gpio# for i in seq 1 224

do echo "connect PIN GPIO$i"

export pin to use

echo $i > export

set PIN signal direction (IN or OUT)

echo out >gpio$i/direction

set PIN signal value (0: Off (Low), 1: On (High))

echo 1 > gpio$i/value

sleep for 1 second

sleep 1

done

I can get GPIO number of PIN (I echo 1/0 for each gpio and check it with LED light) as below

RST = GPIO 198

PWM = GPIO 200

INT = GPIO 199

AN = ?

3.3V = ?

CS = GPIO 119

SCK = GPIO 116

MISO = GPIO 118

MOSI = GPIO 117

About "pin name", I checked with many document and found out: here in "Document" section of this link (below Image) https://shop.mikroe.com/click/display/oled-c

chaunnt commented 7 years ago

After I run my custom device I got this

root@imx7s-warp:~# modprobe fbtft_device name=oledc busnum=1 debug=3 fbtft_device: module is from the staging directory, the quality is unknown, you have been warned. fbtft_device: SPI devices registered: fbtft_device: spidev spi1.0 20000kHz 8 bits mode=0x04 fbtft_device: 'fb' Platform devices registered: fbtft_device: Deleting spi1.0 fb_ssd1351 spi1.0: fbtft_gamma_parse_str() str= fb_ssd1351 spi1.0: 0 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 4 4 4 4 4 4 4 4 4 4 4 4 fb_ssd1351 spi1.0: fbtft_request_gpios: 'dc' = GPIO16 fb_ssd1351 spi1.0: fbtft_verify_gpios() fb_ssd1351 spi1.0: init_display() fb_ssd1351 spi1.0: set_var() fb_ssd1351 spi1.0: Display update: 1074 kB/s (29.766 ms), fps=0 (0.000 ms) fb_ssd1351 spi1.0: set_gamma() Console: switching to colour frame buffer device 16x16 graphics fb0: fb_ssd1351 frame buffer, 128x128, 32 KiB video memory, 4 KiB DMA buffer memory, fps=20, spi1.0 at 20 MHz fbtft_device: GPIOS used by 'oledc': fbtft_device: 'AN' = GPIO1 fbtft_device: 'RST' = GPIO2 fbtft_device: 'en' = GPIO15 fbtft_device: 'dc' = GPIO16 fbtft_device: SPI devices registered: fbtft_device: fb_ssd1351 spi1.0 20000kHz 8 bits mode=0x02

Next, i run "dmesg -c" command and get this

mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 root@imx7s-warp:~# fb_ssd1351 spi1.0: blank(blank=true)

But my screen is still black :(

notro commented 7 years ago
fb_ssd1351 spi1.0: fbtft_request_gpios: 'dc' = GPIO16
...
fbtft_device: 'AN' = GPIO1
fbtft_device: 'RST' = GPIO2
fbtft_device: 'en' = GPIO15
fbtft_device: 'dc' = GPIO16

fbtft only understands 'reset' and 'dc'. reset is used when the driver loads to reset the controller, and dc is used on every transfer to distinguish between control bytes and data/pixel bytes.

chaunnt commented 7 years ago

Thank you. I will modify it

chaunnt commented 7 years ago

I modified it

.name = "oledc", .spi = &(struct spi_board_info) { .modalias = "fb_ssd1351", .max_speed_hz = 20000000, .mode = SPI_MODE_2, .platform_data = &(struct fbtft_platform_data) { .display = { .buswidth = 8, }, .bgr = true, .gpios = (const struct fbtft_gpio []) { { "reset", 198 }, { "en", 199 }, { "dc", 200 }, {}, }, .gamma = "0 2 2 2 2 2 2 2 " \ "2 2 2 2 2 2 2 2 " \ "2 2 2 2 2 2 2 2 " \ "2 2 2 2 2 2 2 3 " \ "3 3 3 3 3 3 3 3 " \ "3 3 3 3 3 3 3 3 " \ "3 3 3 4 4 4 4 4 " \ "4 4 4 4 4 4 4" } }

I use 198, 199, 200 because when I use "echo 1 > gpioXXX/value" I see that led light will be ON when I run for GPIO198, 199, 200 But display is still black :( I run as below:

  1. modprobe fbtft
  2. modprobe fb_ssd1351
  3. modprobe fbtft_device name=oledc debug=3 busnum=1
  4. dmesg -c

But result keep displaying many texts on console .......

mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 ...........

chaunnt commented 7 years ago

I also tried

cp /dev/urandom /dev/fb0 cp: write error: No space left on device

But screen is no hope

notro commented 7 years ago

.mode = SPI_MODE_2,

Why mode 2? The 2 other ssd1351 displays in fbtft_device use mode 0. This sets MOSI/CLK signal inversion.

{ "en", 199 },

fbtft doesn't support 'en'. If this is backlight, you could use 'led' or '_led' if it is inverted.

You need to overrride the default width/height:

                .display = {
                    .buswidth = 8,
                    .width = 98,
                    .height = 98,
                },

mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2

That's debug output from the spi controller driver: http://elixir.free-electrons.com/linux/latest/source/drivers/spi/spi-imx.c#L309

chaunnt commented 7 years ago

Thank you notro. I modified it and run again but display is still black. As i investigated, i found that AN (EN) PIN is disabled by i.MX7. And I think it may affect display since display need AN PIN connected to read/write data. Now I will try to change read/write data to CS PIN. Don't know how to start but start to learn now :)

chaunnt commented 7 years ago

This is output at current status. (Now I plug lithium pin to board also)

root@imx7s-warp:~# modprobe fbtft fbtft: module is from the staging directory, the quality is unknown, you have been warned. root@imx7s-warp:~# modprobe fb_ssd1351 fb_ssd1351: module is from the staging directory, the quality is unknown, you have been warned. root@imx7s-warp:~# modprobe fbtft_device name=oledc debug=3 busnum=1 fbtft_device: module is from the staging directory, the quality is unknown, you have been warned. fbtft_device: SPI devices registered: fbtft_device: spidev spi1.0 20000kHz 8 bits mode=0x04 fbtft_device: 'fb' Platform devices registered: fbtft_device: Deleting spi1.0 fb_ssd1351 spi1.0: fbtft_gamma_parse_str() str= fb_ssd1351 spi1.0: 0 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 4 4 4 4 4 4 4 4 4 4 4 4 fb_ssd1351 spi1.0: fbtft_request_gpios: 'reset' = GPIO198 fb_ssd1351 spi1.0: fbtft_request_gpios: 'dc' = GPIO200 fb_ssd1351 spi1.0: fbtft_request_gpios: 'led' = GPIO199 fb_ssd1351 spi1.0: fbtft_verify_gpios() fb_ssd1351 spi1.0: init_display() fb_ssd1351 spi1.0: fbtft_reset() fb_ssd1351 spi1.0: set_var() fb_ssd1351 spi1.0: Display update: 978 kB/s (18.394 ms), fps=0 (0.000 ms) fb_ssd1351 spi1.0: set_gamma() Console: switching to colour frame buffer device 12x12 graphics fb0: fb_ssd1351 frame buffer, 96x96, 18 KiB video memory, 4 KiB DMA buffer memory, fps=20, spi1.0 at 20 MHz fbtft_device: GPIOS used by 'oledc': fbtft_device: 'reset' = GPIO198 fbtft_device: 'dc' = GPIO200 fbtft_device: 'led' = GPIO199 fbtft_device: SPI devices registered: fbtft_device: fb_ssd1351 spi1.0 20000kHz 8 bits mode=0x00

And after I run "dmesg -c" There are some strange line appeared ....

Bus freq set to 24000000 start... Bus freq set to 24000000 done! cpu=0 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 mx51_ecspi_clkdiv: fin: 60000000, fspi: 20000000, post: 0, pre: 2 ....

After that, it usually freeze my terminal (can not input anything)

chaunnt commented 7 years ago

If everything OK, I think display should enable & init display something when I run commands as below:

modprobe fbtft modprobe fb_ssd1351 modprobe fbtft_device...............

Is it right ?

chaunnt commented 7 years ago

When I run modprobe fbtft_device....... modprobe fbtft modprobe fb_ssd1351 it keep display no matter what i do stop or ctrl +C fb_ssd1351 spi1.0: fbtft_update_display(start_line=40, end_line=47) fb_ssd1351 spi1.0: fbtft_update_display(start_line=40, end_line=47) fb_ssd1351 spi1.0: fbtft_update_display(start_line=40, end_line=47) fb_ssd1351 spi1.0: fbtft_update_display(start_line=40, end_line=47) .......................

notro commented 7 years ago

If everything OK, I think display should enable & init display something when I run commands as below:

This is an OLED so it will remain black when initialized since the initial framebuffer is zeroed.

graphics fb0: fb_ssd1351 frame buffer, 96x96, 18 KiB video memory, 4 KiB DMA buffer memory, fps=20, spi1.0 at 20 MHz

I use fbcon to put a console on the display when I do a quick test. My fbtft devices are on /dev/fb1 because hdmi takes fb0, but yours are fb0. I wonder if fbcon automatically connects to your display when it's loaded?

fb_ssd1351 spi1.0: fbtft_update_display(start_line=40, end_line=47)

If you get these on the console, it's because you have enabled them in fbtft with verbose= AND the console loglevel is set to print debug messages.

If I where to troubleshoot this I would:

  1. Check that SPI works using a tool like this: https://github.com/rm-hull/spidev-test
  2. Dig up the example code for the display and drive the display from userspace using some spi library.
chaunnt commented 7 years ago

This is an OLED so it will remain black when initialized since the initial framebuffer is zeroed.

I see.

I use fbcon to put a console on the display when I do a quick test. My fbtft devices are on /dev/fb1 because hdmi takes fb0, but yours are fb0. I wonder if fbcon automatically connects to your display when it's loaded?

I do not know fbcon is loaded & connected or not. So I rebuild imx7s-warp.dtb file with modules fbcon.ko. Then I run "modprobe fbcon". it return

root@imx7s-warp:~# modprobe fbcon Console: switching to colour frame buffer device 12x12

Next, I run "fbcon=map:0" ('0' is get from command "cat /proc/fb") and it do not return anything on terminal.

Current status: Screen is still BLACK

I'm trying to use con2fbmap (autoconf command is error, i'm investigating) it is in fbset package but Yocto can not use "apt-get" to get this package :( (It is strange that I can call "fbset" command but not con2fbmap)

chaunnt commented 7 years ago

There is an error when I tried to use fbset to run

~fbset mode "96x96-0"

D: 0.000 MHz, H: 0.000 kHz, V: 0.000 Hz

geometry 96 96 96 96 16 timings 0 0 0 0 0 0 0 accel false rgba 5/11,6/5,5/0,0/0 endmode ~cp /dev/urandom /dev/fb0 ~fbset -fb /dev/fb0 fbset: FBIOGET_VSCREENINFO: Inappropriate ioctl for device

chaunnt commented 7 years ago

when I read this link: https://github.com/notro/fbtft/wiki/Build-kernel-and-fbtft-drivers#configure-devices I see this section. But when i checked in menuconfig, there is nothing like this. I search in source code either but do not see anything ? Is it related to my problem "Screen is still Black" ? If yes, do you know which kernel version / repository has this source code ?

By default two console fonts is available: VGA8x8 and VGA8x16 To enable more fonts:

[] Select compiled-in fonts [ ] VGA 8x8 font (NEW) -- VGA 8x16 font [ ] Mac console 6x11 font (not supported by all drivers) (NEW) [ ] console 7x14 font (not supported by all drivers) (NEW) [ ] Pearl (old m68k) console 8x8 font (NEW) [ ] Acorn console 8x8 font (NEW) [ ] Mini 4x6 font (NEW) [ ] Sparc console 8x16 font (NEW) [ ] Sparc console 12x22 font (not supported by all drivers) (NEW) [ ] console 10x18 font (not supported by all drivers) (NEW)

chaunnt commented 7 years ago

About 'reset' & 'dc' pin.

fb_ssd1351 spi1.0: fbtft_request_gpios: 'reset' = GPIO198 fb_ssd1351 spi1.0: fbtft_request_gpios: 'dc' = GPIO200

is it equivalent to /sys/class/gpio198 & /sys/class/gpio200 ?

notro commented 7 years ago

fbcon isn't necessary, I was just wondering if it connected to the device when it was probed. But if you're using yocto it might not be enabled at all.

Writing to /dev/fb0 should appear on the screen.

is it equivalent to /sys/class/gpio198 & /sys/class/gpio200 ?

Yes.

chaunnt commented 7 years ago

Writing to /dev/fb0 should appear on the screen.

I think so too. when I run "cp /dev/urandom /dev/fb0", screen should display something.

fbcon isn't necessary, I was just wondering if it connected to the device when it was probed. But if you're using yocto it might not be enabled at all.

I will check with NXP (producer)

chaunnt commented 7 years ago

~cp /dev/urandom /dev/fb0 ~fbset -fb /dev/fb0 fbset: FBIOGET_VSCREENINFO: Inappropriate ioctl for device

when i run fbset, it return this

chaunnt commented 7 years ago

I use my raspberrypi3 to test Oled display . I use "pioled" with different gpios because pioled has same controller ssd1351. I run step as below:

enable SPI in raspi-config sudo modprobe fbtft_device name=pioled debug=3 busnum=1 gpios=reset:20,dc:26 dmesg [ 77.151618] fbtft: module is from the staging directory, the quality is unknown, you have been warned. [ 77.156698] fbtft_device: module is from the staging directory, the quality is unknown, you have been warned. [ 77.157740] spidev spi0.0: spidev spi0.0 500kHz 8 bits mode=0x00 [ 77.157758] spidev spi0.1: spidev spi0.1 500kHz 8 bits mode=0x00 [ 77.157795] bcm2708_fb soc:fb: soc:fb id=-1 pdata? no [ 77.157844] spidev spi0.0: Deleting spi0.0 [ 77.158874] fbtft_device: GPIOS used by 'pioled': [ 77.158892] fbtft_device: 'reset' = GPIO20 [ 77.158908] fbtft_device: 'dc' = GPIO26 [ 77.158929] spidev spi0.1: spidev spi0.1 500kHz 8 bits mode=0x00 [ 77.158944] spi spi0.0: fb_ssd1351 spi0.0 20000kHz 8 bits mode=0x00 [ 77.170522] fb_ssd1351: module is from the staging directory, the quality is unknown, you have been warned. [ 77.171531] fb_ssd1351 spi0.0: fbtft_gamma_parse_str() str= [ 77.171555] fb_ssd1351 spi0.0: 0 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 4 4 4 4 4 4 4 4 4 4 4 4 [ 77.171634] fb_ssd1351 spi0.0: fbtft_request_gpios: 'reset' = GPIO20 [ 77.171658] fb_ssd1351 spi0.0: fbtft_request_gpios: 'dc' = GPIO26 [ 77.171673] fb_ssd1351 spi0.0: fbtft_verify_gpios() [ 77.171686] fb_ssd1351 spi0.0: fbtft_reset() [ 77.305640] fb_ssd1351 spi0.0: Display update: 2352 kB/s, fps=0 [ 77.306176] graphics fb1: fb_ssd1351 frame buffer, 128x128, 32 KiB video memory, 4 KiB DMA buffer memory, fps=20, spi0.0 at 20 MHz

After this

con2fbmap 1 1

=> Result is the same :( :( only LED Light is ON (3.3V) Note: I do not see any /dev/fb1 is generated. (after run fbset, there will be /dev/fb0 (my monitor) /dev/fb1 (my added OLED)

I also tried

cp /dev/urandom /dev/fb1 cp: error writing ‘/dev/fb1’: File too large cp: failed to extend ‘/dev/fb1’: File too large

I start thinking problem come from this OLED :) :) :) Not driver or WARP7 board

notro commented 7 years ago

Based on this statement on the product page: It carries the PSP27801 OLED display, the same one that we have used on Hexiwear.

I have tracked down these files: https://developer.mbed.org/teams/Hexiwear/code/Hexi_OLED_SSD1351/file/ae5fad429790/OLED_info.h https://developer.mbed.org/teams/Hexiwear/code/Hexi_OLED_SSD1351/file/ae5fad429790/Hexi_OLED_SSD1351.cpp

Based on that, you should use this controller initialization:

    write_reg(par, 0xfd, 0x12);
    write_reg(par, 0xfd, 0xb1);
    write_reg(par, 0xae);
    write_reg(par, 0xb3, 0xf1);
    write_reg(par, 0xca, 0x5f);
    write_reg(par, 0xa0, 0x60);
    write_reg(par, 0x15, 0x00, 0x5f);
    write_reg(par, 0x75, 0x00, 0x5f);
    write_reg(par, 0xa1, 0x80);
    write_reg(par, 0xa2, 0x60);
    write_reg(par, 0xb1, 0x32);
    write_reg(par, 0xbe, 0x05);
    write_reg(par, 0xa6);
    write_reg(par, 0xc1, 0x8a, 0x51, 0x84);
    write_reg(par, 0xc7, 0xcf);
    write_reg(par, 0xb4, 0xa0, 0xb5, 0x55);
    write_reg(par, 0xb6, 0x01);
    write_reg(par, 0xaf);

Compare with this to see the difference from the default: http://elixir.free-electrons.com/linux/latest/source/drivers/staging/fbtft/fb_ssd1351.c#L36

Or as an fbtft_device argument:

init=-1,0xfd,0x12,-1,0xfd,0xb1,-1,0xae,-1,0xb3,0xf1,-1,0xca,0x5f,-1,0xa0,0x60,-1,0x15,0x00,0x5f,-1,0x75,0x00,0x5f,-1,0xa1,0x80,-1,0xa2,0x60,-1,0xb1,0x32,-1,0xbe,0x05,-1,0xa6,-1,xc1,0x8a,0x51,0x84,-1,0xc7,0xcf,-1,0xb4,0xa0,0xb5,0x55,-1,0xb6,0x01,-1,0xaf,-3

You can't use pioled straight up, because it is 128x128.

chaunnt commented 7 years ago

Based on this statement on the product page: It carries the PSP27801 OLED display, the same one that we have used on Hexiwear.

I checked init sequence of SSD1351 with sequence in Sample of Mikroe. It a bit different. Differences are order of signal in sequence & how it write command (Low DC & CS, then High again) We can found it in here: https://shop.mikroe.com/click/display/oled-c#heading1 => Download sample and open it with Mikroe Compiler or Package Manager

chaunnt commented 7 years ago

1 more thing that I should mention before. AN & 3.3V PIN has no signal when we are checking with Led light. (Power led light of Oled display is ON by using "echo 1 > gpio200/value" command) It may affect this display

notro commented 7 years ago

The library in the download section only mentions the SEPS114A controller for the previous version of the display and not the ssd1351.

chaunnt commented 7 years ago

Thank you. I 've created 3 driver with 3 init sequence :) But it still failed. I will use them for further test after modification. Since the driver worked correctly as you suggested, I think problem may come from Hardware. (display or board). I will check it with producer. But 1 more thing, Display require 4 PIN: AN (GPIO??? - R/W), RST(GPIO198 - reset - RS), INT(GPIO199 - EN), PWM (GPIO200 - d/c) But in fbtft driver, we only defined "dc:200, reset:198". is it ok with just only 2 parameter ? Note: AN PIN is disabled by i.MX and they suggested me change to use CS PIN (GPIO119).

notro commented 7 years ago

I have traced the signals to the datasheet descriptions:

AN -> R/W -> PSP27801:R/W#: This pin is read / write control input pin connecting to the MCU interface. RST -> RST -> PSP27801:RES#: This pin is reset signal input. PWM -> D/C -> PSP27801:D/C#: This pin is Data/Command control pin connecting to the MCU. INT -> EN -> TPS61041:EN: This is the enable pin of the device. Pulling this pin to ground forces the device into shutdown mode reducing the supply current to less than 1 μA. This pin should not be left floating and needs to be terminated.

What's AN and why is it broken out on the header?

I really don't understand why. This is what the ssd1351 datasheet has to say:

This pin is read / write control input pin connecting to the MCU interface. When 6800 interface mode is selected, this pin will be used as Read/Write (R/W#) selection input. Read mode will be carried out when this pin is pulled HIGH and write mode when LOW. When 8080 interface mode is selected, this pin will be the Write (WR#) input. Data write operation is initiated when this pin is pulled LOW and the chip is selected. When serial interface is selected, this pin R/W (WR#) must be connected to VSS

The display is wired for serial only, so why make it available... AFAIU the AN pin should be connected to GND.

So to summarise my understanding of this: AN -> GND RST -> fbtft:reset PWM -> fbtft:dc INT -> 3.3v

The TPS61041 generates 15V for the display from 3.3v.

chaunnt commented 7 years ago

So to summarise my understanding of this: AN -> GND RST -> fbtft:reset PWM -> fbtft:dc INT -> 3.3v

The TPS61041 generates 15V for the display from 3.3v.

I will try this first with my raspberryPi3. If this make display OK, then I will have to talk with NXP. I'm really confusing that they 've already designed WARP7 with mikroBus but when I plug it with other device (mikrobus), they need me to wire up with different PIN :) Then why should "mikrobus standard" be existed ? it is funny.

chaunnt commented 7 years ago

RST -> fbtft:reset PWM -> fbtft:dc INT -> 3.3v

In RaspberryPi3, display can enable by this, we using PIN as above, but the power up sequence may not right. we have to run as below:

  1. run fbtft_device command
  2. run dmesg command
  3. Change PIN as above. => Enabled screen If we switch step 2 <=> 3 , screen will not enable

it is default display, we can not monitor it. (we used command "con2fb")

AN -> GND

We think AN PIN have some problems. Then it can not read/write anything to display.

In WARP7, we are applying same method

chaunnt commented 7 years ago

About problem of 3.3V PIN in my board (WARP7). There may be hardware problem. I tried

echo 195 > /sys/class/gpio/export echo out > /sys/class/gpio/gpio195/direction # Set output echo 0 > /sys/class/gpio/gpio195/value # Output Low echo 1 > /sys/class/gpio/gpio195/value # Output High

But it can not enable.

I notice when I run echo command or do nasty thing with those PIN. some time, led light which connected to 3.3V PIN, can be ON. But led light went out right after that.

chaunnt commented 7 years ago

Bad luck :( I connect 3.3V & R/W PIN of display to others PIN (free PIN) of WARP7 but nothing happen. Screen do not enable like it did in Raspberry. I checked free PIN also has out signal. (I even tried with 5V PIN)

chaunnt commented 7 years ago

After a while trying manything. now I do not even display anything on Raspberry Currently, i do as below: PIN Plug

RASPBERRY <====> OLED C 3.3V -------------- 3.3V 3.3V -------------- EN GPIÔ26 ---------------- DC GPIO20 ---------------- RST GND ---------------- GND SPIMOSI --------------- SD1 SPIMISO --------------- SD0 SPISCK --------------- SCK GPIO06 --------------- CS (I think do not need) GND --------------- AN (R/W)

command run:

  1. modprobe fbtft_device name=oledc busnum=0
  2. dmesg
  3. con2fb 1 1
  4. con2fb 1
johnphilby commented 4 years ago

After a while trying manything. now I do not even display anything on Raspberry

@chaunnt were you able to get this working? I have sort of your same problem on the mikroBus.

chaunnt commented 4 years ago

not any clues :) I change to use LCD display, BTW in my case, mikroBus was customized by producer

github-actions[bot] commented 3 years ago

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days.