How to compile and run custom firmware for ALI M3801 and other chips from tuners?

p.kaczmarek2 08 Dec 2025 10:37 4 663 Cool? (+8)

📢 Listen (AI):

I will show here the first attempts and a simple "Hello world" for the ALI M3801 processor on the example of an old Comsat TE 1050 HD tuner based on the project ali_sdk from GitHub. I will then try to add new functionality to it - GPIO support. The project shown here is not a full Linux SDK, but on the contrary, it is a minimalist demo built from scratch to which most of the functionality has yet to be added.

Organising the working environment
You have to start with the programming method. I use the CH341, the clip didn't work for me - it can't see the memory. On the computer side I fire up NeoProgrammer.

CH341 programmer with SOP16 clip adapter next to Comsat TE 1050 HD tuner mainboard

The ALI M3801 is based on the MIPS architecture. I compile the firmware on Ubuntu, according to the readme from the demo author ( michal4132 ):

SDK build process for ALI M3801 shown in Ubuntu terminal window

I tried to compile these demos under Cygwin and WSL - without success. Only on Ubuntu did it work. Additionally, I had to compile the toolchain via crosstool-NG anyway - it took a while, with GCC alone grinding for over half an hour.

Hello World from the author
The presented repository includes a simple Hello World offering information display on the UART and a minimalist command line system:

The program in me runs correctly, but does not receive data from the RealTerm :

RealTerm terminal showing boot messages from an ALI M3801 device via UART

I will leave this problem for now, but will come back to it later.

GPIO support - buttons
I added the GPIO support on my own, I will outline the methodology here. I just searched by registers - the UART register is already used in the project - 0xb8018300 - a search by it on GitHub leads to some interesting projects. They are not complete, but you can approach other registers:
https://github.com/search?q=0xb8018300&type=code
This is how I came across the m36_gpio.h and m36_gpio.c files:
https://github.com/qttest1/PDK_GoBian/blob/a3...rs/aliminirpc/inc/asm/mach-ali/m36_gpio.h#L53
You can see here how the pins are organised on the M36XX platform - on the M3801 it may be similar.
First we have the four byte words for each port.

Then we have a mechanism to select a register for the pin index - the indexes are absolute, starting at 0. For example, to enable GPIO:

From a distance you can see that there are quite a lot of pins. This is confirmed by the GPIO_PORT_MAX constant:

I transferred these functions to the presented program and managed to make a simple pin scanner. the 8 pins are packed into a single byte and the results are displayed on the screen in a loop.

The GPIO readout is working - you can see the responses to the buttons:

Screenshot of RealTerm showing received serial data in hexadecimal format.

Reading chip id (chip ID)
I looked at other SDKs and saw an interesting bit that reads the chip ID. Everything here works in a similar way to pins - there is a special address for this.

Oddly enough, the returned value is not passed on directly, but is translated into other constants.

For myself, I have prepared without translating to constants:

The result:

I have ALI M3801 and I received 0x3811, but maybe it is some internal revision of the chip.

Faster button scan
I also wanted to improve the GPIO scan so that it displays what has changed. To start with I used the following code:

This didn't start - all I get is "Booting.... M" on the UART and silence. Perhaps the array didn't fit on the stack.
So I optimised the code so that one pin is one bit:

Bingo - you can now see which pins are the buttons from the programs. Interestingly, the main on/off button is not seen:

UART terminal screenshot showing GPIO pin state change messages.

Continued testing with UART
The complete lack of UART communication on the computer -> device line was giving me no peace of mind. I started by verifying the pins to see if I had indeed correctly identified where the RX of the microprocessor was.

Close-up of a tuner PCB with markings for USB, GND, RX, and TX pins

Everything is correct. We have TX, RX, 5 volts and ground in sequence. I also tried removing the pull up resistors (you can see them in the picture under the RX/TX pins), but to no avail.
In the end, I was interested in the UART configuration itself. After all, it has a parity bit set in it - even mode. A rather unusual setting. I tried turning it off:

Code snippet showing changed uart_set_mode parameter in entry.c file

It is immediately much better, but there are still problems:

Screenshot of RealTerm showing UART output and error messages from ALI M3801

I have looked at the information on the web about the CH341 I am using and I am coming to the conclusion that:
- CH341 does not handle parity bits correctly
- or more precisely, data with the even bit is not sent correctly (the receiver rejects it - bad parity or no parity?)
- but interestingly, when the device sends data with this bit to CH341, CH341 nevertheless receives it correctly, so in a way it misleads me by giving the impression that everything is ok....
I guess I'll have to check this with a logic analyser. I don't even have other USB to UART converters to compare.

Further plans
This UART does not work very stably and in addition receiving is solved in a blocking way for the processor, and too slow debouncing causes characters to be lost. It is imperative to run this based on interrupts, just how? There is residual information on the web, no full documentation of what registers to set.
I'll try to search as much information as I can about it, and potentially test - you need to add an ISR (function to handle the interrupt) and check that it calls. Maybe increment the volatile variable in it and in the main loop detect the change. Add to that a simple menu operation, since my buttons already work, and have different functions that set registers so I can quickly test different options.

Materials for further analysis and searches
UART register addresses - 0xb8018300 and 0xb8001600:
https://github.com/search?q=0xb8018300+&type=code
https://github.com/search?q=0xb8001600+&type=code
ALI_SOC_BASE base address - 0xb8000000:
https://github.com/search?q=ALI_SOC_BASE+&type=code
https://github.com/search?q=0xb8000000+&type=code
Other circuit types (my 0x3811 is not here):

Interrupts?
https://github.com/zhe2lucifer/linux-kernel-z...s/modules/aliarch/mips/ali/m36/m36_irq.c#L327
https://github.com/zhe2lucifer/linux-kernel-z...b/6.8.3.2-dev/arch/mips/kernel/irq_cpu.c#L101

Summary
The project found is promising, but necessarily requires the implementation of interrupts for the UART and then a simple bootloader. This can be quite difficult due to the lack of documentation on the subject, but I will try to move forward with it and report the results soon.
I've also attempted to simulate the Mips core based on libraries from Python - I can already do the assembler this way, but it doesn't simulate anything but instructions, so it's more of a curiosity. I will present this in a separate topic.
Do any of you have this or a similar Ali chip and would be willing to try your hand at programming it? Any help welcome, on the fly I am trying to move on with this and am looking for similar tuners.

About Author

p.kaczmarek2 wrote 13420 posts with rating 11260 , helped 617 times. Been with us since 2014 year.

Comments

Add a comment

piotr_go 08 Dec 2025 12:35

Come on, for 25£ you can buy a tiny module (on RV1103) with better support. [Read more]

LightOfWinter 08 Dec 2025 13:09

Congratulations on the idea and the jam. I like that you decided to fight with this hardware. I've always been curious about how to get a chip like this and reprogram it. [Read more]

bulek01 08 Dec 2025 16:23

Using things instead of throwing them away I think is nice, but yes unfortunately it is very time-consuming when there is no documentation and financially it is often not profitable if you look at it that... [Read more]

piotr_go 08 Dec 2025 16:55

On the homepage in "Multirabates" they were recently at 24£ (pico mini a). I bought the "Luckfox Pico Pro Max RV1106" for 45zł. [Read more]

FAQ

TL;DR: DIY firmware on ALI M3801 (MIPS) now boots a UART "Hello World" and scans up to 159 GPIOs; “The ALI M3801 is based on the MIPS architecture.” [Elektroda, p.kaczmarek2, post #21774649]

Why it matters: This helps you revive old DVB tuners, learn low-level MIPS, and prototype custom I/O without buying new boards.

For: hardware hackers, reverse‑engineers, and tuner modders who ask “how do I compile, flash, and talk to ALI M3801?”

Quick Facts

- CPU/SoC: ALI M3801; minimal bare‑metal demo built from scratch, not a full Linux SDK. [Elektroda, p.kaczmarek2, post #21774649]
- UART bases seen in code: 0xb8018300 and 0xb8001600; UART prints OK, RX initially problematic. [Elektroda, p.kaczmarek2, post #21774649]
- GPIO count observed: up to index 159, scanned via port registers; live button reads confirmed. [Elektroda, p.kaczmarek2, post #21774649]
- Build environment: Ubuntu + crosstool‑NG toolchain; Cygwin/WSL failed; GCC build took "over half an hour." [Elektroda, p.kaczmarek2, post #21774649]
- SPI flashing: CH341 programmer with NeoProgrammer; SOIC clip couldn’t detect memory. [Elektroda, p.kaczmarek2, post #21774649]

What chips does this walkthrough target?

It focuses on ALI M3801 from a Comsat TE 1050 HD tuner and references similar ALI M36xx register maps found via public code. The shared demo is a minimalist, bare‑metal project intended to be extended (GPIO, UART, interrupts). It is not a full vendor SDK. [Elektroda, p.kaczmarek2, post #21774649]

How do I compile and run the Hello World on ALI M3801?

Use Ubuntu, build a MIPS toolchain with crosstool‑NG, compile the ali_sdk demo, then flash the image via CH341. Finally, connect UART to see the kprintf output and command loop. 1) Build toolchain; 2) make the demo; 3) flash and open UART. “Main function” prints on boot. [Elektroda, p.kaczmarek2, post #21774649]

Why did the toolchain fail on Cygwin or WSL?

The author reports builds failed on Cygwin and WSL, while the same sources compiled successfully on Ubuntu after generating the cross‑compiler. Expect platform quirks in POSIX tooling and long GCC builds. Use native Ubuntu for reliability. [Elektroda, p.kaczmarek2, post #21774649]

Which UART addresses and settings should I start with?

Code and searches point to UART registers at 0xb8018300 and 0xb8001600. Initial UART TX worked, but RX misbehaved until parity settings were changed. Begin with no parity, then test framing. Keep a terminal ready to confirm prints. [Elektroda, p.kaczmarek2, post #21774649]

My CH341 adapter won’t receive data—how do I fix UART RX?

Observed behavior: CH341 mishandled even parity on TX towards the device; disabling parity improved results. The device’s TX to CH341 still appeared correct, which can mislead debugging. Quote: “It is immediately much better.” Validate with a logic analyzer if issues persist. [Elektroda, p.kaczmarek2, post #21774649]

How many GPIOs can I read, and what’s the quick way to scan them?

The demo scans indexed GPIOs up to 159 via port control registers, printing live changes. Use input direction on all pins, sample, and compress eight bits per byte for fast display. This enables identifying front‑panel buttons quickly. [Elektroda, p.kaczmarek2, post #21774649]

Why did my GPIO change‑detector hang at boot?

A large per‑pin integer array on the stack prevented progress (UART showed only “Booting.... M”). Switching to a bit‑packed state array resolved it. Edge case: stack size limits can break early boot loops. [Elektroda, p.kaczmarek2, post #21774649]

How do I read the ALI chip ID on this platform?

Read from ALI_SOC_BASE (0xb8000000), then shift right by 16. The author’s board returned 0x3811, likely an internal revision of M3801. This direct read avoids remapping to vendor enums. [Elektroda, p.kaczmarek2, post #21774649]

What’s the plan for reliable UART I/O?

Move from blocking reads to an interrupt‑driven UART with an ISR that updates a volatile flag or buffer. Then implement a simple menu to tweak registers quickly. Lack of full docs means experimenting with known IRQ code paths. [Elektroda, p.kaczmarek2, post #21774649]

What hardware and software were used to flash the firmware?

A CH341 programmer with NeoProgrammer was used; a test clip failed to detect flash memory, so a direct connection was used. Confirm TX, RX, 5V, and GND pins before flashing to avoid miswiring. [Elektroda, p.kaczmarek2, post #21774649]

Is hacking an old ALI tuner worth it versus buying a new module?

If you want speed and support, a tiny RV1103 class module costs about £25 and has better resources. If you want learning and reuse, hacking the tuner is rewarding but time‑intensive. [Elektroda, piotr_go, post #21774740]

Where can I find a low‑cost alternative board example?

One user bought a Luckfox Pico Pro Max (RV1106) for 45 zł and noted homepage multirabates listing Pico Mini A at £24. Prices fluctuate, but deals exist on vendor homepages. [Elektroda, piotr_go, post #21774999]

What is MIPS in this context?

MIPS refers to the CPU architecture used by the ALI M3801. You compile a MIPS cross‑toolchain and build bare‑metal code that runs directly on the SoC’s cores without Linux. [Elektroda, p.kaczmarek2, post #21774649]

How do I quickly verify front‑panel buttons over GPIO?

Initialize every GPIO as input, then loop and pack eight pins into one byte for printing. A bit change indicates a button event. Statistic: the scanner covered up to 159 indices on the author’s unit. [Elektroda, p.kaczmarek2, post #21774649]

Why can’t I see the main power button as a GPIO?

The demo detected several buttons, but not the primary on/off key. That switch can be on a different controller path or latched circuit rather than a simple GPIO. Treat it as an outlier. [Elektroda, p.kaczmarek2, post #21774649]

Any minimal 3‑step build-and‑flash recipe I can copy?

On Ubuntu, build a MIPS toolchain with crosstool‑NG and compile the ali_sdk demo.
Flash the image via CH341 using NeoProgrammer; verify wiring.
Open UART, disable parity, and confirm "Main function" prints. “Only on Ubuntu did it work.” [Elektroda, p.kaczmarek2, post #21774649]