TonyMac32

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.

Thanks goes to @Neil Armstrong and BayLibre, they've been handling mainlining Amlogic. I simply curate any additional patches and keep things playing nice with the build system.

Welcome to "wip" images! 😉. I have not taken a look at the device tree yet, that was my goal for tonight/tomorrow. :-)

Thank you for the submission, and the pending 5.3 RC PR.

Quick update that the VIM 1 is a CSC entry in the build system now.

I'll try to give it a look tomorrow, I finished my exploration of the La Frite tonight.

OK, so, if you are the sort to build it yourself, you can. It's under WIP/CSC, and is currently kernel 5.2.y. You can do a couple things, one is to flash the image (using etcher) to a USB keyfob, the other is to update your firmware, then use a USB A to A cable from the closest USB port to the IR sensor. Power up, hitting escape to interrupt the boot process, then type in ums 0 mmc 0 to get the device to show up on the host computer. The use etcher to flash the image right to the eMMC on the La Frite.

_ _____ _ _ | | __ _ | ___| __(_) |_ ___ | | / _` | | |_ | '__| | __/ _ \ | |__| (_| | | _|| | | | || __/ |_____\__,_| |_| |_| |_|\__\___| Welcome to Ubuntu Bionic with Armbian Linux 5.2.8-meson64 System load: 1.23 0.45 0.17 Up time: 5 min Memory usage: 11 % of 967MB IP: CPU temp: 55°C Usage of /: 4% of 56G Well then. Give me a few to get it committed.

Added a wip target to the build system, it is dev kernel only, and builds just fine, however booting is another issue I've not spent a lot of time with yet: Found U-Boot script /boot/boot.scr 3048 bytes read in 11 ms (270.5 KiB/s) ## Executing script at 08000000 154 bytes read in 5 ms (29.3 KiB/s) ## Error: Can't overwrite "ethaddr" himport_r: can't insert "ethaddr=00:50:43:84:fb:2f" into hash table 8101414 bytes read in 217 ms (35.6 MiB/s) 16093192 bytes read in 416 ms (36.9 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC No FDT memory address configured. Please configure the FDT address via "fdt addr <address>" command. Aborting! 232 bytes read in 26 ms (7.8 KiB/s) Applying kernel provided DT fixup script (meson-fixup.scr) ## Executing script at 34000000 ## Loading init Ramdisk from Legacy Image at 13000000 ... Image Name: uInitrd Created: 2019-08-12 5:04:59 UTC Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 8101350 Bytes = 7.7 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ERROR: Did not find a cmdline Flattened Device Tree Could not find a valid device tree The device tree is there in the /boot/fdt/amlogic folder, and the script is the same for Le Potato/ Khadas Vim/Nanopi K2 and works. [some minutes elapse] I think I found it, the printenv (had to figure out the UART, not an easy task) shows me fdtfile=libre-computer/aml-s805x-ac/platform.dtb ...which is completely wrong in a normal context, where it should match the linux device tree: meson-gxl-s805x-libretech-ac.dtb I'll try to figure that out later.

Yes, we need to really get the mainline working properly.

Yes, both Le Potato and the new CSC for Khadas' VIM (both Meson-GXL) can boot directly from eMMC without any special effort out of the box. I don't have an eMMC for K2 or C2, but will review the u-boot image building process and see if anything is amiss and the boards are simply "dealing" with the issue on SD. Sent from my Pixel using Tapatalk

I am still confused by this, for GXL nand-sata-install works just fine (just ran it on Le Potato)

http://linux-meson.com/doku.php Not really that far ahead of mainline, A vast majority of the G12A labelled work is common to G12B (The Odroid N2 SoC): https://patchwork.kernel.org/patch/11025369/