jpegqs

You need to rebuild the U-Boot with this patch to disable the read limit. Then write the patched U-Boot to an SD-card with Armbian and boot into loader mode with the card inserted. It's also possible to patch the binary code of the original U-Boot from EMMC, but it's long to explain.

This comment describes a recovery method without shorting the pins. I haven't tried this method.

Please give at least compiled dtb's for your TV-boxes. I tried to rebuild the image for legacy kernel with the latest Armbian-build, and now HDMI doesn't work at all. Update: The problem seems to be that the TV boxes use gmac0, the driver of which is RK630_PHY, and this driver is not enabled in linux-rk35xx-vendor.config. compatible = "ethernet-phy-id0044.1400", "ethernet-phy-ieee802.3-c22"; #define RK630_PHY_ID 0x00441400 Update2: Still doesn't work, even with this driver (preinstalled Android uses this driver).

Is it like this in the dts file or did you do it another way? - ethernet0 = &gmac1; + ethernet0 = &gmac0; &gmac0 { - status = "disabled"; + status = "okay"; }; I tried this in rk3528-mangopi-m28k.dts but no luck.

Armbian now supports MangoPI M28K (BOARD=mangopi-m28k BRANCH=vendor), which uses kernel 6.1. HDMI-audio works with dtb from MangoPI. But now Ethernet port doesn't work, neither with this dtb, nor with what I did for the old kernel.

Most likely this: But did you notice that this is a "minimal" build? You need to install desktop packages if you need a desktop.

No. I don't know what you're talking about. I didn't make any changes to armbi_root, whatever this is. Sounds like a fake flash media that reports more capacity than it actually has.

There's an unsolved problem with the RK3528 video driver, it is necessary to connect an HDMI cable or turn on the monitor a few seconds after turning on the TV-box. Also, at the first boot there is nothing on screen, because first you need to enter the Armbian configuration script using ssh (over a LAN connection).

With BRCMFMAC driver or BCMDHD driver? Or did it work with both drivers?

The preinstalled Android on the RK3528 uses the BCMDHD driver, which is located in the "drivers/net/wireless/rockchip_wlan/rkwifi/bcmdhd" directory. As you can see, Rockchip has its own driver for Broadcom. Which is missing some patches. I'm pretty sure that these patches must include this line: {BCM4335_CHIP_ID, 1, DONT_CARE, "bcm4335b0_ag", "bcm4335"}, There's number of repositories on Github that have this line (link). But they have no history of driver updates.

I tried to use the firmware from Android, it ends with this: [dhd] ======== PULL WL_REG_ON(-1) LOW! ======== [WLAN_RFKILL]: rockchip_wifi_power: 0 [WLAN_RFKILL]: rockchip_wifi_power: toggle = false wifi power off [WLAN_RFKILL]: rockchip_wifi_power: toggle = false [WLAN_RFKILL]: wifi shut off power [GPIO106-0] [dhd] ANDROID-ERROR) failed to power up wifi chip, max retry reached ** But I don't care about WiFi because: 1) I don't like anything wireless, 2) WiFi in cheap TV boxes is of crap quality. How to try the same:

I have patches here, but read this thread first. Do not install it to EMMC.

Are there legal reasons to request TV box manufacturers to publish the patches they used for Android? Although Chinese companies will likely ignore this, there is no real leverage over them.

But the GPU (Mali-450) is 10-years old. It's not only slow, but doesn't support many OpenGL extensions, so Doom 3 refuse to run, and Quake 3 has glitches (these games are older than the GPU).

The heatsink is held on by glue, you need to carefully insert a thin knife into the gap until the knife passes through the glue. I removed the heatsink today and replaced the glue with a thermal pad. Because at the factory the heatsink was poorly glued to the edge of the chip, so the chip overheats under heavy load. It's too late, but maybe it will be useful to someone.

Attention: do not try to install Armbian on EMMC, you may brick the TV-box: At least until it's known why this happens and how to avoid it.

That's a build with my patches and hacks. There are some problems. I haven't tried installing it because it's enough for me that it works from the SD card. I rewrote the original U-Boot and nothing broke. This means U-Boot is not signed. Maybe it's SPL. What if you write a copy of the bootloaders from Android onto an SD card, will the bootloader use them? Or does it only check EMMC. There is also this report:

I can guess that at the beginning of initialization the driver checks for an HDMI connection, if there is a connection, then some error occurs in the driver. If HDMI is connected after, then the error no longer occurs. I don't know where the problem code might be.

The patch you suggest checking applies to code that doesn't exist in the 5.10 kernel. I don't understand exactly how this works. I was able to connect a 10 year old LG monitor. But it didn't work when I connected it to the TV-box and turned on the TV-box. It worked when I first turned on the TV-box, and then after a few seconds I connected HDMI from the turned on monitor. But you can simply turn on the monitor after turning on the TV box. Preinstalled Android from this TV-box always sees HDMI connection, so this is a software problem.

This may be related to specific devices. One person wrote to me that it works for him. Last week I did some tests. A cheap Chinese TV (on the common v59 controller) and a small no-name display for Raspberry Pi do not work. But it works with the ASUS monitor. And both work after booting the TV-box with the connected ASUS monitor.

I published my patches on GitHub. This is still half-baked, so I won't create a pull request to Armbian for now.

Can you explain how to open it without breaking the case?

You need to rebuild U-Boot with CONFIG_ROCKCHIP_USB_BOOT=y in defconfig. Then write it to the EMMC. USB 3.x flash drives will not work.

I think it's good to keep preinstalled Android because Android contains the settings and firmware needed to use the hardware. I see no point in rewriting Android when you can boot from an SD card. I think this is due to a buggy code that initializes HDMI to display the logo. It doesn't work if the logo can't be found. Not only that, it can (pseudo-randomly) crash in U-Boot if it can't find the logo. I solved this problem with a patch to U-Boot. This patch creates a gray square instead of a logo.

I share the monitor between my computer and TV-box. I connect power to the TV-box and switch to HDMI from the TV-box through the monitor menu. If I boot from a USB flash drive (you need the correct build of U-Boot written on the EMMC), then I always manage to switch the monitor to see the Armbian boot logo, or even the logo from U-Boot, then HDMI always works. If I boot from an SD card, Armbian boots much faster and I don't have much time to switch the monitor to the TV-box. It seems to me that HDMI does not work when Armbian does not see the connected monitor at some boot stage. I believe this is a problem similar to the one described in this thread. I did not open the DQ08 box because I don't see how to do this without damaging the case. I also have the H96MAX M1 (on the same chip) that I opened. I also don’t understand what multitool you are talking about, I haven't used it. I used rkflashtool.