dreamlayers

Why is so much of the eMMC unused at the start? In the old script, the first partition starts at 700M (M = million bytes), and in Armbian 23.11.1, that has been increased to 1000M. These are the parted commands: parted -s "${DEV_EMMC}" mklabel msdos parted -s "${DEV_EMMC}" mkpart primary fat32 1000M 1512M parted -s "${DEV_EMMC}" mkpart primary ext4 1513M 100% BTW The Armbian 23.11.1 version also contains the umount /var/log.hdd fix from the post above.

I connected the ABOX to an 24LC21 I2C EEPROM programmed with the Protron PLTV-26 EDID, also connecting the hot plug detect line to the +5V line. Then I monitored I2C communication using a logic analyser. Here is the I2C activity I observed: Quickly after startup, there is a sequential read of 8 bytes from memory address 0xF8 on I2C address 0x52. That is what https://github.com/superna9999/linux/wiki/Amlogic-HDMI-Boot-Dongle is talking about. It is safe. This won't corrupt EDID. (Note that some EEPROMS like the 24LC21 do not care about the lowest order 3 bits of the address and the pins that select the address, and respond to I2C addresses 0x50 through 0x57. Also note that the contents of the EEPROM wrap around, so even a 128 byte EEPROM can be used. A read to memory address 0xF8 on the 24LC21 ends up reading address (0xF8 & 0x7F) == 0x78. So you can put the boot string at address 0x78 through 0x7F on a 128 bit EEPROM.) Then, just under a second later, accesses to I2C address 0x54 start: Two reads from EEPROM address 1. Write 1 to EEPROM address 2. Write 0 to EEPROM address 0x20. Those writes do the corruption. Then 1.5 seconds later the EDID is finally read, using a sequence of individual byte reads from I2C address 0x50. It has already been corrupted by this point, by the two earlier writes. I think this is the firmware reading it, for the initial video mode. About 12 seconds later there are more EDID reads. I think that's the Linux kernel doing it. HDMI 2.0 puts the Status and Control Data Channel (SCDC) at I2C address 0x54. There, at address 2 you have "source version" and at address 0x20 you have "TMDS config". So, the firmware is attempting to write to those things. It is only allowed to access the SCDC if the EDID contains the HF-VSDB structure and the "SCDC present" bit there is set. But it is accessing SCDC without first checking the EDID. Another device, the EZCOO EZ-SW21HA21 HDMI audio extractor switch. also inappropriately accesses this SCDC. Edit: I don't know where is the source for the exact U-Boot found in this box, but https://github.com/endlessm/u-boot-s905x/blob/9149dd46279da8c347f36b7ca3164f660cfd6581/arch/arm/cpu/armv8/gxb/hdmitx20/hdmitx_set.c#L300 shows code which causes this EDID corruption. There, scdc_wr_sink() writes to I2C address 0x54, and in scdc_prepare() it is used to do the two writes that corrupt my EDID.

Where can I find armbian-ddbr? I do have /usr/sbin/ddbr however, and maybe that should be used instead?

I have an OTT TV Box, model ABOX-A1 ( 1G + 8G, S905X ). It is running Armbian 23.11.1 bookworm. How can I have hardware video decoding? Hardware video decoding support seems present in the 6.1.63-current-meson64 kernel. It seems only the V4L2 M2M API is present. Some firmware seems missing. I was getting "meson-vdec c8820000.video-codec: Direct firmware load for meson/vdec/gxl_h264.bin failed with error -2" in dmesg. I don't know what package I need to install. I was thinking maybe firmware-linux-nonfree, but that conflicts with armbian-firmware due to firmware-ralink. The files are available at https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/meson/vdec though, and I downloaded gxl_*.bin from there and put them in /lib/firmware/meson/vdec/ . I've tried Kodi, mpv and ffmpeg, in Wayfire and at the text console. Kodi always uses lots of CPU, and mpv crashes whenever I use --hwdec=v4l2m2m-copy. The best result was "ffplay -vcodec h264_v4l2m2m file.mp4" at the console. That at least actually seems to use hardware decoding because I see this output: driver 'meson-vdec' on card 'Amlogic Video Decoder' in mplane mode. But the CPU utilization is actually worse, about 300%, compared to below 200% without -vcodec h264_v4l2m2m. Edit: After installing mpv 0.37.0-1 and its dependencies from trixie (Debian testing), I definitely got hardware acceleration in mpv --hwdec=v4l2m2m-copy. CPU usage was less that 100% on one core. However, there were still problems with dropped frames and audio/video desynchronization, so I don't recommend this. Kodi CPU usage seems decreased too, often below 200% playing the same file, but this is still terrible for playing 720p H.264. It's not worth messing up your packages with a mix from two Debian versions only to get this. Edit: The Kodi 2:20.1+dfsg-1 from Bookworm doesn't have the DRM PRIME options in "Settings > Player > Videos", so I guess it doesn't support acceleration? The Kodi 2:20.4+dfsg-1 from Trixie does have those options, and enabling them makes the video disappear. I've tried setting "PRIME Render Method" to EGL and Direct-To-Plane, and both failed in a similar way.

If you have an image of what was on eMMC before, I think you should be able to boot Linux from SD or USB and then write that image to eMMC from there.

I've attached it again here. s905x-p212_audio_fix.tar.xz

I used a different file name for the fixed dtb: meson-gxl-s905x-p212-sound.dtb. Because of that I don't think it should be overwritten when the kernel is updated. I don't expect updates to remove the entire directory, but even then, surely there is some space on the boot partition where I can put my custom dtb so it doesn't get deleted.

I am using Armbian_23.11.1_Aml-s9xx-box_bookworm_current_6.1.63_minimal.img.xz

I have an OTT TV Box, model ABOX-A1 ( 1G + 8G, S905X ). Inside it looks very similar to NEXBOX A95X. When it starts up while connected to a Protron PLTV-26 TV, the TV EDID gets changed. This happens both with the original Android and when booting Armbian. I don't think it's due to Armbian. I wonder if it is due to startup code on eMMC or SOC ROM. The changes happen at every startup and are always the same. It writes a 1 at EEPROM offset 2, and a 0 at offset 0x20. Normally, the EDID EEPROM chip is at I2C address 0x50, and many devices write protect it. On this TV it responds to addresses from 0x50 to 0x57 according to i2cdetect, and it is not write protected. The Amlogic SOC can read from I2C address 0x52 to force a particular boot mode: https://github.com/superna9999/linux/wiki/Amlogic-HDMI-Boot-Dongle . I guess this means it also writes to the EEPROM at I2C address 0x52. Fortunately, I had an EDID backup from before, and the change was easy to undo via i2cset from my Raspberry Pi. Armbian also provides access to the HDMI I2C bus on this TV box, so it should be possible to fix this using it, as long as HDMI gets unplugged before the next startup. A TV with a writeable EDID that can be accessed at address 0x52 could be used to force a boot mode. Though the Protron PLTV-26 only has a 128 byte EEPROM, and the string for forcing boot mode needs to be at EEPROM offset 0xF8 through 0xFF, requiring at least a 256 byte EEPROM. It would be nice if I could alter something on eMMC to prevent this. If it is in ROM, I need to not use it with that TV, open up the TV to write protect the EEPROM, or break a HDMI cable or adapter to prevent communication with the EEPROM.

I wanted a stable version because I thought that would involve less problems. Replacing the device tree only means replacing a single file and it is an easy fix that should easily persist across updates. I see that the weekly development builds at https://github.com/armbian/community/releases/tag/24.2.0-trunk.103 involving "Aml_s9xx_box" all use 6.1.66 kernel, and the patch is clearly not there: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts?h=v6.1.66 . It clearly is in 6.6.1 and later: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts?h=v6.6.1 To fix this problem, builds need to either transition to the 6.6 kernel, or add the patch before building the 6.1 kernel.

I have an OTT TV Box, model ABOX-A1 ( 1G + 8G, S905X ). Inside it looks very similar to NEXBOX A95X discussed at https://www.savagemessiahzine.com/forum/index.php?showtopic=770346 . It has an analog AV port, with a 3PEAK TPF632A audio line driver on the output. So, all the digital audio stuff is inside the S905X SOC, and maybe some GPIO switches mute of that analog output chip. I first booted Devmfc_Debian-Bookworm_6.1.57-meson64_Minimal-23.10.12.img.xz from https://github.com/devmfc/debian-on-amlogic and had sound on the analog output. (The later Devmfc_Debian-Bookworm_6.6.1-meson64_Minimal-23.11.09.img.xz did not work.) I used its aml-multiboot-setup.sh script to set up automatic boot from USB or SD if they're present, without needing to hold the button in the bottom of the AV port. Then I decided I'd rather run Armbian, and I got Armbian_23.11.1_Aml-s9xx-box_bookworm_current_6.1.63_minimal.img.xz running from a USB drive. (I couldn't run Armbian_23.11.1_Aml-s9xx-box_bookworm_current_6.1.63.img.xz and some others, but I'm not 100% sure that I didn't do something wrong that prevented them from running.) This works fine, except there are absolutely no audio devices, either for HDMI or analog audio. I saw that the kernel modules that seem needed were present, but they weren't loaded and loading them didn't help. I guess they only work if the device tree informs Linux about that hardware being present. Using grep gx-sound-card /boot/dtb/amlogic/*s905x* I see only meson-gxl-s905x-khadas-vim.dtb, meson-gxl-s905x-libretech-cc.dtb, and meson-gxl-s905x-libretech-cc-v2.dtb contain that. I had had tried meson-gxl-s905x-p212.dtb and meson-gxl-s905x-nexbox-a95x.dtb so far, and neither have sound. Then I found https://github.com/torvalds/linux/commit/7e01e14e9f75385910d1e42f97a5e98f36244967 "arm64: dts: meson: add audio playback to S905X-P212 dts". After applying that patch, rebuilding the .dtb, and rebooting, I got a sound device. I could play audio files, and that took the appropriate amount of time, as if audio was going somewhere, but there was no analog audio output. Then, changing some things via amixer got it to work. These changes must have persisted, because I shut down, removed power, and booted again, and analog audio worked without having to do anything. I am attaching the altered .dtb file, the .dts file with the patch applied, and amixer output showing the current configuration with working analog audio. If you don't get audio, you can diff your amixer output against that output and see what might need to be changed. If you want to build the .dtb file yourself, note that the dtc program cannot handle the C preprocessor include directives found in these files. So, you first need to run them through the C preprocessor, and then you need to run dtc on the preprocessed output. Use something like cpp -nostdinc -I include -I arch -undef -x assembler-with-cpp arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts ~/p212.dtsp To obtain the source code, I simply used https://github.com/armbian/build to start a build of a minimal Armbian system, telling it I want to custom configure the kernel. Then when the kernel configuration menu came up, I killed that, knowing all the files I needed were present. s905x-p212_audio_fix.tar.xz