0

Having mostly used Yocto to get stuff done, rather than learning it proper, I figure I'm coming at the task of configuring display settings all wrong.

I have a custom board with a STM32MP157 and a LT8912B compatible bridge for driving a HDMI display from MIPI. I have a board support package that includes a Yocto build with a display-timings node in the devicetree. The Yocto build is 99.99% what I need, but the screen resolution doesn't match a display I want to work with.

Working from the perspective of a dumb user, I figure I need to:

  1. Avoid creating a yocto build environment and bitbakeing a new image with my very minor changes.
  2. Learn enough about the image to realise HDMI screen resolutions are dictated by the lt8912b devicetree node.
  3. Get a hold of a cross-compiling toolchain with dtc and friends (I'll need the compiler for my work anyway).
  4. Read the lt8912b devicetree docs to understand how the resolution is set.
  5. Read the display documentation to figure out the appropriate timings, since EDID tools are hard to come by when running a yocto image.
  6. Find and decompile the dtb file that is active in the build.
  7. Look through the resulting source and find the LT8912B node. Note both the existing properties and where it is in the hierarchy.
  8. Create a dtso overlay file, applying the correct path and properties overrides.
  9. Compile it using dtc and move to the target.
  10. Locate the compiled overlay correctly and point the bootloader to it.
  11. Reboot and see if it worked.
  12. Rinse and repeat for each mistake I make and experiment I run.

This happens to be the example of display resolution and lt8912b, but I follow much the same process for other experimental tweaks when working with yocto builds that are not my own. I admit, it's really really laborious. Is there a more efficient way? Or are there more efficient steps?

Improve this question
3
  • "Avoid creating a yocto build environment and bitbakeing a new image with my very minor changes." exactly what you need to do :) The whole point of oe & bitbake though is that this should work reliably and gives you a new image in a reproducible manner. Your steps 3, 4, 6, 7, 8, 9, 10 are pretty complicated and exactly covered by what you are trying to avoid in step 1, which, by the way, is exactly the step that gives you the cross-toolchains for steps 3. Commented Nov 18 at 11:34
  • @MarcusMüller ah! Starting with "someone else's yocto image is 99.99% what I want, now how do I change the screen res" and concluding with "first, create a yocto build environment" requires crossing some serious local optima for me. Thank you for describing the bridge so clearly. I will resist the new knowledge for a while, as is human, but will likely come to realise you're right. Commented Nov 18 at 12:07
  • That's quite human and understandable :) If you have someone else's Yocto image, you also have the scripts to generate an SDK that you need to compile software that runs on the target, by the way. But in your special case, you really likely want the change to affect the kernel image in your image, as the devicetree is likely to be baked into that, so that there might not be many shortcuts. Commented Nov 18 at 12:51

0

Reset to default

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.