Yes, you can provision modules with no display attached. Serve the image with autoinstall enabled, or reach the installer GUI over VNC on port 5900. When startup fails on a custom carrier, suspect the board before the missing screen: the documented fault was an I2C bus jammed by two untied pins, fixed by tying SODIMM 53 and 55 to 1.8 V.
Yes, an embedded module installs its OS with no display attached, and the vendor's installer image is built for exactly that case. Its compositor configuration forces the video output on with nothing plugged in, the GUI also answers over VNC on port 5900, and with autoinstall enabled in the image your server hands out, the module installs and reboots with no interaction at all. When that flow fails on a custom carrier board, the missing screen is the wrong suspect. In the case this article follows, the installer GUI never started because an I2C bus was jammed by two pins the carrier left untied, and the fix was two pull-ups to 1.8 V.
What the installer does with no screen
The image ships a compositor configuration that assumes headless use. The output named HDMI-A-1 is forced on at 640x480@60, so the GUI renders with no monitor present. The same configuration loads a screen-share module whose command starts a second compositor instance on the VNC backend, and the GUI is reachable there on the default port 5900.
Two paths do the whole job without a screen:
| Path | What you set up | What happens |
|---|---|---|
| Autoinstall | An image server on the bench LAN, image config set to autoinstall true |
The module installs on boot and reboots into your image, no input |
| Interactive headless | A VNC client on a PC on the same LAN | You get the installer GUI on port 5900 and pick the image yourself |
Neither path reads a monitor. Both run on the vendor's development carriers with no display attached, and that is the reference your own PCB has to meet.
Symptoms and what each points to
Failed to create wl_displayandCould not load the Qt platform plugin "wayland"in/var/volatile/tezi.log. The installer front end started with no compositor behind it. The same message lists the plugins it could have used:minimal,offscreen,vnc,wayland. Thatvncentry is the built-in network route, and it works even when the local display path is dead.Arbitration lostfollowed bycontroller timed outfrom the I2C controller, early indmesg. Something on the carrier is holding the bus, and every transfer the driver attempts fails. This is the line that means hardware, and it names the bus to fix./sys/class/drm/card0-HDMI-A-1/statusreadsconnectedon a board with no HDMI port. The graphics stack believed a display was present. A missing connector stopped nothing./var/volatile/weston.logis empty or cut short. The compositor never got far enough to hand the installer a display, which is what produced the plugin error above it.tezictl image-listanswers from the serial console. The installer back end is alive; only the layer below the GUI is stuck.
Checks in order
Run them top to bottom; each one removes a suspect. The screen half of an embedded controller gets the same method in troubleshooting an embedded controller video display.
| Check | Command or action | What it tells you |
|---|---|---|
| Module versus carrier | Boot the module on the vendor's development carrier, no display | If it installs there, your module and image are good and the fault is on your PCB |
| Bus faults | Read dmesg for Arbitration lost |
Hits in the first 10 s name the jammed bus and put the fault in hardware |
| Video connector | cat /sys/class/drm/card0-HDMI-A-1/status |
connected on a board with no port: the video path is up, take it off the suspect list |
| Compositor | cat /var/volatile/weston.log |
Shows how far the compositor got before it stalled |
| Installer back end | tezictl image-list |
Lists the available images: only the GUI layer is affected |
| GUI over the network | Point a VNC client at the board's address, port 5900 | The GUI appears: the whole headless path works |
The first row is the decisive one. A module that installs on the vendor's carrier and dies on yours has already split module from board for you.
The fix: hold the bus pins like the development carrier
The jammed bus is the module's second I2C bus, on SODIMM pins 53 and 55. The vendor's development carriers tie both pins to the 1.8 V rail; the failing custom PCB omitted that tie, and the bus lost arbitration until the driver gave up on every transfer. Reproduce the development carrier's treatment on your board: pull both lines to 1.8 V. Do the rework with the board unpowered, and pull to that rail only, because a pull to a higher rail puts overvoltage on pins built for 1.8 V logic.
There is no software side to this fix. The vendor had no configuration switch that substitutes for the missing pull-up, so this is a schematic change: every copy of the custom PCB carries the same omission, and the change belongs in the revision before the production run.
A good boot after the rework looks like this: no arbitration entries in dmesg, the compositor reaching its shell in weston.log, the installer starting with no display attached, and the GUI answering a VNC client. With autoinstall true in the served image, the module then installs and reboots on its own.
Scenario: the same module on two boards
One module, two boards, one image. On the vendor's development carrier with no display attached, the installer starts and autoinstall begins. Move the same module to the custom PCB and boot: dmesg records Arbitration lost at 2.918 s, then controller timed out at 3.940 s and again at 4.996 s. The gaps are 3.940 - 2.918 = 1.022 s and 4.996 - 3.940 = 1.056 s: three bus faults inside the first 5 s of boot, each transfer abandoned after about 1 s. The boot continues, the compositor never delivers a display, and /var/volatile/tezi.log ends with the Wayland plugin error. The connector status still reads connected, so the video chain is not the fault.
The only difference between the two boards is two pins. Tie SODIMM 53 and 55 to 1.8 V. On the next boot the bus is quiet, the installer starts with no screen, the GUI answers on port 5900, and autoinstall pulls the image from the server. Same module, same image; only the carrier changed.
Run the batch
Set the bench up once: an image server on the LAN, autoinstall true in the image config, and a VNC client on your PC for the odd unit that needs a hand. Per device, the operator does two things: seat the module and apply power. The module finds the server, installs, and reboots into your image. A USB stick carrying the same image behaves the same way and suits one-offs and rework.
When these headless modules later feed screens people watch, choose the display side deliberately: live factory data display: signage or dashboard separates the two jobs, and the andon board guide sizes a line-side board. For a notice board that plays from a card and needs no provisioning at all, see shop-floor signage.
Recommendation: Before the production run, boot one module on the vendor's development carrier with no display, then on your own PCB, autoinstall enabled on both. If the install runs on the first board and dies on the second, read dmesg for Arbitration lost, tie the bus pins the development carrier ties (SODIMM 53 and 55 on this module family), and put the pull-ups in the board revision. Leave HDMI out of the design; the installer does not need it.
Questions
Do I need to fake an HDMI connection so the installer starts?
No. The shipped configuration forces the video output on at 640x480@60 and starts a VNC backend beside it, so the GUI has two ways up with nothing plugged in. Faking a connection on the connector pins changes nothing here: the failing boards reported the HDMI connector as connected while the install still died, because the fault was on the I2C bus.
Does autoinstall work from USB media as well as from a network server?
Yes. Autoinstall is a flag in the image configuration itself, set to autoinstall true, so the identical image installs unattended from a USB stick or from a server on your bench LAN. Use the server for a batch, where each device needs only power and a network cable, and keep a stick for single units and rework.
The log says no Qt platform plugin could be initialized. Is my image broken?
No. That message appears when the GUI starts before any compositor is available to it, and on a jammed carrier the compositor never arrives. The image is fine: the same module and the same image run on the vendor's development carrier. Clear the bus fault, boot again, and the plugin error goes with it.
Which pins hold the I2C bus, and how do I check the rework?
SODIMM 53 and 55, tied to 1.8 V the way the development carrier ties them. After the rework, power the board and measure each pin: an idle I2C line with its pull-up in place sits at the rail, so both should read 1.8 V, and the next dmesg read should carry no arbitration entries.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.