Da Xue

You can only use soft dual edge interrupts with meson before SM1.

This depends on the Armbian default device tree mode for the USB controller. The top left port next to Ethernet is an dual mode capable port so Armbian might have it set to device by default. On Libre Computer official images, they're set to host mode.

https://wiki.archlinux.org/title/Display_Power_Management_Signaling

4K is not a problem with the proper encoding. You need to use gstreamer on Armbian or official images. gst123 if you are using weston.

RTL8821CU is upstreamed in Linux 6.2. Armbian uses an out-of-tree driver for it. Chromium on X11 is very laggy since it's not accelerated. Your best bet is to use the official Ubuntu server images and run Chromium snap on weston.

Need to see your actual overlay. But I would test the overlay first by just disabling serial and then using gpioset to test those GPIOs first. Then worry about bitbang I2C driver. Not familiar with Armbian's dt overlay system myself.

The hardware video encoder is not supported in anything but Android or the buildroot BSP. It's a very simplistic hardware encoder so it will probably not get upstream support.

I2C?

Armbian's I2C overlay probably doesn't have the proper biasing https://github.com/libre-computer-project/libretech-wiring-tool/blob/master/libre-computer/aml-s905x-cc/dt/i2c-b.dts You can either re-hack the overlay or use our images along with the libretech-wiring-tool.

You have to check the logs. It could be a number of things.

Any specific links to the code?

@Martin Harris Go online and look for Debian VNC instructions. Raspbian is 99% Debian now with Bullseye so regular Linux instructions will work just fine.

Patriot and MicroCenter cards are using cheap internal controllers and flash to hit cost low cost. Stick with Tier 1 like SanDisk and Samsung. Even Kington uses crappy flash in some products.

I don't think Armbian currently supports the SPI. People might be working on this but in the meantime, you can use the official images for SPI: http://distro.libre.computer/ci/ https://github.com/libre-computer-project/libretech-wiring-tool

you have to add an systemd service to launch on tty when you hit multiuser.target

uvc cameras can be used with guvcviewer and mjpegstreamer

Just for other people's reference, you need to set alsamixer configs properly.

So the issue is in the dwmac u-boot driver. Leaving it on in u-boot and it will corrupt memory somewhere between 1GB and 2GB. Disabling dwmac fixes it but you also have to add phy initialization code to Linux driver.

We are working with Amlogic and BayLibre to get to the root of the ethernet issues on mainline for Amlogic chips. We should have a resolution soon. One was caused by double poking a register in Designware's IP. There's a secondary issue we are looking into.

The I2C pins for pin 3 and 5 are actually the GPIO_AO UART pins. You have to use software gpio-bitbang for I2C on those pins. https://docs.google.com/spreadsheets/d/1pAtz8v2gnkkrAdNrhhrpICkTNQ8cd1ObduUsphcbqp4/edit#gid=0

I sent a patch upstream for this issue. Hopefully it solves this issue for anybody running across this on H3/H5 boards.

@RussianNeuroMancer I didn't see this thread or I would have checked it out. This has to do with the delay in mmc initialization. Sometimes it's too fast and something hasn't stabilized. One method to delay it is to enable SPL debug. I have SD cards that just refuse to work but work flawlessly when I turn on debug. There's a delay somewhere that's missing in the u-boot code. In sunxi_mmc.c sunxi_mmc_core_init, you need to raise the udelay to 5ms or 10ms. I didn't do extensive testing but it fixes nearly all mmc problems.

ttyAML0 is on header 2J1 and it's by default the debug UART You can enable additional UARTs by download this: https://raw.githubusercontent.com/libre-computer-project/libretech-overlays/for-4.13.y/overlays/meson-gxl-s905x-libretech-cc-uarta.dts and using armbian-add-overlays. UART A is on pin 8 and 10. See the header reference: https://docs.google.com/spreadsheets/d/1U3z0Gb8HUEfCIMkvqzmhMpJfzRqjPXq7mFLC-hvbKlE/edit?usp=sharing

If my memory is correct, the TEST_N line is output only and would reset the board if it was set to input. I vaguely remember something like this: https://lore.kernel.org/lkml/1533117623-27856-1-git-send-email-narmstrong@baylibre.com/T/

@N6MQD You have to do the following: wget https://raw.githubusercontent.com/libre-computer-project/libretech-overlays/for-4.13.y/overlays/meson-gxl-s905x-libretech-cc-i2c-ao.dts wget https://raw.githubusercontent.com/libre-computer-project/libretech-overlays/for-4.13.y/overlays/meson-gxl-s905x-libretech-cc-ds3231-i2c-ao.dts sudo armbian-add-overlay meson-gxl-s905x-libretech-cc-i2c-ao.dts sudo armbian-add-overlay meson-gxl-s905x-libretech-cc-ds3231-i2c-ao.dts Try running `i2cdetect -y 0` first to make sure that the SDA/SCK doesn't need a pull up resistor. If it does, connect 2 4K pull up from 3.3V to SDA and SCK. You know you need a pull up if i2cdetect shows every address or many addresses that aren't on the bus.