Conflicting dtoverlays and framebuffer

Question

I have a RPi3 with latest standard kernel. I am making use of spi1. In config.txt I have the line:

dtoverlay=spi1-3cs.

I have 2 ADC's connected to spi1 and all seems fine, using an HDMI screen to monitor. I now want to reconnect a 2.4" touchscreen to spi0 that I had previously working fine before I started using spi1. In config.txt I have the line:

dtoverlay=rpi-display

If I type: ls /dev/fb* I can see that fb1 is not available. If I log the boot with dtdebug=on, the resulting log msg says:

loaded overlay rpi-display

But if I just comment out the line dtoverlay=spi1-3cs, fb1 is then listed, and if I then type: cat /proc/fb, it correctly lists fb1 as ili9341.

I have searched this site and done a detailed Google search but I have not been able to find anything hinting of the solution to this problem. I have tried all the trial-and error changes that I can think of. Any thoughts/ideas would be greatly appreciated.

Why is loading spi1 stopping my spi0 display driver from loading, and is there anything I can do about?

Answer 1

If you take a look at notro's fbtft documentation, specifically the the information about using your display as a Boot Console, there is some information about attaching displays to different ttys.

There is additional kernel documentation that describes mapping specific devices to specific ttys:

3. fbcon=map:<0123>

        This is an interesting option. It tells which driver gets mapped to
        which console. The value '0123' is a sequence that gets repeated until
        the total length is 64 which is the number of consoles available. In
        the above example, it is expanded to 012301230123... and the mapping
        will be:

        tty | 1 2 3 4 5 6 7 8 9 ...
        fb  | 0 1 2 3 0 1 2 3 0 ...

        ('cat /proc/fb' should tell you what the fb numbers are)

    One side effect that may be useful is using a map value that exceeds
    the number of loaded fb drivers. For example, if only one driver is
    available, fb0, adding fbcon=map:1 tells fbcon not to take over the
    console.

    Later on, when you want to map the console the to the framebuffer
    device, you can use the con2fbmap utility.

By setting your dtoverlay device to a specific tty, you can see if you can switch between this device and your HDMI device. Here is a boot/config.txt example:

# See /boot/overlays/README for all available options

#enable_uart=1
dtparam=spi=on,i2c_arm=on

#dtparam=audio=on
dtoverlay=rpi-display

gpu_mem=64
initramfs initramfs-linux.img followkernel

hdmi_group=2
#hdmi_mode=1
hdmi_mode=87
hdmi_cvt 1024 600 60 6 0 0 0
hdmi_drive=1

And an example of boot/cmdline.txt. Focus on fbcon and console entries:

root=/dev/mapper/pi-root cryptdevice=/dev/mmcblk0p3:pi-root:allow-discards rootfstype=ext4 rw rootwait fbcon=map:10 console=ttyAMA0,115200 console=tty1 selinux=0 plymouth.enable=0 smsc95xx.turbo_mode=N dwc_otg.lpm_enable=0 kgdboc=ttyAMA0,115200 elevator=noop logo.nologo

• fbcon=map:10
• console=ttyAMA0,115200
• console=tty1

Now that this is set up with the first overlay being assigned to the first tty, and you've restarted, the boot log/console should show up on your dtoverlay display after a short time. The other display (HDMI) becomes the next tty, so in this case, the second (tty2) tty.

Because they are on separate ttys, you will have to switch between them to input and potentially see the tty with CTRL+ALT+F1 and CTRL+ALT+F1

---

Notes

1. notro's fbtft documentation is the wiki for the repository before it was brought upstream. This means that some of the information is outdated, but this repo shows the mechanics behind dtoverlay and provides helpful information even today.