TonyMac32

Thank you for the update, I'll have to take a look, I thought the patch was there, I might be able to look at it tonight (I've been out of the office for a while)

Same! Life has been a bit tough lately, I've been supporting my wife through her recent surgery, she gets to come home this week (3rd week in hospital/rehabilitation)

The u-boot source code should be able to help, I remember a regulator being involved. Sent from my Pixel using Tapatalk

My understanding is either should work, but I haven't spent any real time on it. Sent from my Pixel using Tapatalk

I have not personally gotten the OTG to work in the Linux kernel, although it should as UMS works with U-boot.

I will double check this, but my "Le Potato" board seems to have no trouble with 4K screens (I don't often test this feature, it's my main monitor, I don't have a second test monitor so the test is a little disruptive of my work flow) [edit[ It took it a long time to bring up the desktop on this 5.3 RC kernel, but Le Potato:

I have not been tracking the TV boxes topic, I more or less thought it had gone stale. Mainline support is fairly good, the addition of VIM 1 in existing Meson64-dev was very straightforward. I merged it due to the simplicity, and the fact it is more SBC than TV box, and @ning had put in the work.

dump the EDID for all involved, that will probably be helpful

I would say yes, but BayLibre is also involved in the u-boot/kernel support of the Libre Computer boards, so I would guess all the current WIP is baked in. As far as it goes though, I set the resolution to 1024x768 and pluged it into my 4K screen and had no problem. Jumped it to 1080p, also no worry. Tried 4K and it failed. The bootloader started in 4k successfully a few times, so my assumption is it is attempting to use the recommended resolution it gets back from the monitor, only something is going wrong a lot of the time, whether it is the HDMI support itself *or* it is the clock source/divider.

Armbian uses a single partition for everything for basic usability. Android has all of these split up into a whole bunch of partitions. https://source.android.com/devices/bootloader/partitions-images OTA updates and sandboxing make that better for Android, for us it's more practical to have a normal desktop-style configuration. A lot of burning tools for ARM set-top box processors though expect that android layout, so it makes burning our image difficult if not impossible.

@Ravelo I'll have to take a look. Often these tools assume the Android partition structure, which we don't use, thus they throw errors. Sent from my Pixel using Tapatalk

Their tools are designed around Android, and I've only used them in that context on TV boxes. Sent from my Pixel using Tapatalk

How else do you deploy 3rd party images to a board? Very few have UMS support to flash directly. Sent from my Pixel using Tapatalk

Possibly, but making a 32-bit image for a 64-bit SoC is covered for those willing to do it themselves elsewhere in the forums. I see no real advantages. S805X is to the S905X what the H2+ is to the H3. both are Meson GXL's. Interesting, my 4K monitor is a Samsung, and it is 4K that appears to be the tripping point. Perhaps a discussion with @Neil Armstrong may be helpful, although I've bothered him with these sort of issues before.

Let me know if anyone experiences HDMI issues, my 2 monitors are somehow always problematic, but the u-boot video drivers appear to have some quirks to them just plain angers my hardware. My Waveshare 7" HDMI works fine other than some technicolor effects on the handoff from U-boot to the kernel. With my 4K the board appears to be trying to jump 4k60 and the monitor simply rejects it outright, the HDMI-DVI adapter just doesn't like to work randomly, it seems to stem from U-boot.