This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM625: Directions to expose framebuffer to HDMI and OLDI displays

Part Number: AM625

Tool/software:

Dear all,

We are running a custom board based on the AM6254, which drives an HDMI output from Video Port 2 and an OLDI touch panel from Video Port 1

In our initial setup only the hdmi nodes are created on the device tree. HDMI comes up and if we write into /dev/fb0 we can see the HDMI display updating.

In the next step we add the OLDI output. Now, if we write into /dev/fb0 the display that updates is the OLDI panel, while the HDMI panel remains unchanged.

There is only one /dev/fb# in the system.

Before I dive into a neverending crusade with framebuffer support I'd like to know if:

  • It is reasonable to expect two framebuffer /dev/fb# devices to be exposed when driving HDMI and OLDI simultaneously?
  • Are there guidelines to achieve this?

From my read of the simple-framebuffer device tree binding, it seems possible to declare arbitrary framebuffers as long as we know the memory addresses that feed the matching display. With this in mind I'm wondering whether these memory addresses are constant and available to declare framebuffer devices.

Best regards,

António Oliveira

  • Hi,
    Let me look into internally and get back to you by tomorrow.

  • Thanks, Divyansh,

    Perhaps I can provide a bit more detail about some decisions we are facing based on the result of tests we intend to do.

    Our product is driving one display over HDMI using a legacy framebuffer. HDMI is driven from Video Port 2 of the AM6254.

    In the next generation we are adding a touchscreen display which will contain an independent GUI. This display is connected through OLDI, ie, driven by video port 1 of the AM6254.

    At the moment, to be comfortable with the hardware design we'd like to see simultaneous output to HDMI and OLDI using independent graphics on each display using either a legacy framebuffer OR DRM based technology.

    Considering the features of the AM62 and it's BSP (we are running SDK11), what would be the best path forward?

    If you could kindly point us at resources that would help setting up a dual-display setup we'd be much appreciated.

    Best regards,

    António

  • Hi,
    Simply by enabling the k3-am625-sk-microtips-mf101hie-panel.dtbo overlay, you can enable OLDI, and DPI is enabled by default (you'll need DPI to HDMI bridge on your custom board). Weston by default has support for extended display over the two; OLDI and HDMI.
    In case you don't want to use weston and only DRM, it is non-trivial to have independent display without a windowing service.
    You can checkout some application like this:

    //Find connector and crtc ID using kmsprint for the below command
    modetest -M tidss -s 50@48:1920x1080 -s -s 40@38:1920x1200

    You can also refer to 3rd Party solutions as shown at https://www.kdab.com/why-kdab/trusted-partner/software-excellence-for-texas-instruments/  which showcase dual display in AM62x.

  • Hi Divyansh,

    Thanks for the feedback. From the documentation that we read in the meantime it became clear that the SDK doesn't support a framebuffer on a per-display basis.

    It is also our understanding that wayland/weston work well with the dual display setup. Leveraging this setup is likely to induct significant changes to our codebase. We are analysing internally and gathering information to make a well-informed decision. It is possible that we decide to drop the framebuffer altogether and make the switch to a wayland enabled setup.

    Best regards,

    António

  • Just for the purpose of closure and searchability, I'm adding this reply to share what we ended up doing.

    We enabled weston and wayland on our image and weston came up pretty much out-of-the-box for both displays. With a bit of tweaking we got the displays to work as we wanted (still in progress, but with encouraging results).

    Our application uses LVGL and, with a little bit of patching, was made able to output to both displays using the wayland driver, independently. We are considering opening a PR for LVGL since the current v9.2 only works with a single window per process.

    I hope this helps anyone looking to work with the two displays on the AM62.

    All the best,

    António