My tools:
- I have a SAMA5D3xEK evaluation board (with the D34) - this is the big one with all the bells and whistles that they don't sell anymore.
- I've been using Yocto (Morty 2.2.2 Branch) via command line.
- I've also been using meta-atmel, meta-openembedded, meta-qt5, etc. (again Morty version).

My problem:
I've built the "atmel-qt5-demo-image" multiple times. Each time, I can get the kernel, rootfs, etc. to boot and load but the screen always winds up with some weird line pattern, random popcorn static, or completely blank. There is absolutely no meaningful display data.

Here's what I've done:
- I've validated my hardware (and revalidated a couple times throughout) by loading the stock demo image (linux4sam/bin/view/Linux4SAM/Sama5d3xekMainPage). Aside from some poor touchscreen calibration it worked each time.
- Using the "How To" on Linux4Sam as a template, I built my own atmel demo image (as I mentioned above, a couple times).
- I addressed version compatibility issues and any fatal errors until I could get a successful build.
- Once I could build to completion I worked to eliminate any warnings that looked like they led to display problems (mesa, weston, wayland, related warnings).

With an image that builds without warnings but does not show anything on the display, I went a little deeper:

- I used putty to log into the SAMA5 and navigate it's file structure. I navigated to /usr/bin where weston is stored and tried to force it to execute. I got the following errors:

Now, I note that there looks to be multiple issues in the error output but I think the root cause is the fact that systemd does not seem to be running (I got "command not found" when I typed in "systemd --test"), nor does it seem to exist in the image. I know that it is included in the Morty 2.2.2 variant of Yocto.

Finally, my questions:
- Can anyone tell me where to go from here?
- Am I chasing the right problem or is lack of systemd a non-issue?
- Is there something that can exclude systemd from the build?
- Have I misunderstood how this demo runs it's interface (i.e., weston)?
- Does anyone see any additional messages that should I should start investigating deeper as potential root causes to my overall problem (the screen is not coming up)?

Any nudge in the right direction would be appreciated. I know I have a lot more to read and learn but I feel like I'm missing something and my learning process has been stagnating.

Kerberosity wrote:Each time, I can get the kernel, rootfs, etc. to boot and load but the screen always winds up with some weird line pattern, random popcorn static, or completely blank. There is absolutely no meaningful display data.

Sounds like the frame buffer memory (that was previously setup by U-Boot) is getting stepped on. Since that's not likely to happen with Linux, it usually means that there is no frame buffer device in your Linux kernel.

Kerberosity wrote:- Can anyone tell me where to go from here?
- Am I chasing the right problem or is lack of systemd a non-issue?

No, you're chasing the wrong problem(s).

Kerberosity wrote:- Have I misunderstood how this demo runs it's interface (i.e., weston)?

Yes, you misunderstand this demo software, since the name of the Atmel demo indicates it uses Qt5.
Weston is not involved at all.

Kerberosity wrote:- Does anyone see any additional messages that should I should start investigating deeper as potential root causes to my overall problem (the screen is not coming up)?

The kernel boot log has no output from the HLCDC driver, which is expected since the Linux4SAM maintainers for some reason removed the display driver from the Device Tree for the SAMA5D3x-EK boards after Linux version 4.1 or Linux4SAM release 5.2.
Without the HLCDC driver, there is no driver for the display hardware.
Consequently the DRM subsystem has no device for its output, and and DRM requests get rejected.

IOW you might have gotten closer to the root cause of the display issue if you had used a basic tool like modetest or simple utilities like fb-test and fbv instead trying to install an unnecessary display server .

Thanks! I needed some hints and you gave me a whole bunch of research topics. I found the display driver (weston) in the meta-atmel layer and assumed (erroneously, obviously) that that was how they were operating the display. In addition to working the problem, I will work on learning my diagnostic tools to avoid that in the future.