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

p.kaczmarek2 2319 35

Treść została przetłumaczona

Zobacz oryginalną wersję tematu

Report a violation of the law

Reply Cool? Ranking DIY | New topic

Notify about new articles

📢 Listen (AI):

» | Topic author Helpful post? (+8)

Post #1
21774649 08 Dec 2025 10:37

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.

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

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:
Code: C / C++
Log in, to see the code

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

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.
Code: C / C++
Log in, to see the code

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:
Code: C / C++
Log in, to see the code

From a distance you can see that there are quite a lot of pins. This is confirmed by the GPIO_PORT_MAX constant:
Code: C / C++
Log in, to see the code

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.
Code: C / C++
Log in, to see the code

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

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.
Code: C / C++
Log in, to see the code

Oddly enough, the returned value is not passed on directly, but is translated into other constants.
Code: C / C++
Log in, to see the code

For myself, I have prepared without translating to constants:
Code: C / C++
Log in, to see the code

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:
Code: C / C++
Log in, to see the 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:
Code: C / C++
Log in, to see the code

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

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.

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:

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

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):
Code: C / C++
Log in, to see the code

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.

Cool? Ranking DIY
Helpful post? Buy me a coffee.
About Author
p.kaczmarek2 p.kaczmarek2

Moderator Smart Home
Offline

Joined: 26 Dec 2014

Posts: 13978

Help: 631

Posts rating: 11765

Points: 134892
p.kaczmarek2 wrote 13978 posts with rating 11765, helped 631 times. Been with us since 2014 year.
ADVERTISEMENT
#2 21774740 08 Dec 2025 12:35

piotr_go piotr_go

DIY electronics designer

» | Helpful post? (+1)

Post #2
21774740 08 Dec 2025 12:35

Come on, for 25£ you can buy a tiny module (on RV1103) with better support.
#3 21774779 08 Dec 2025 13:09

LightOfWinter LightOfWinter

Level 38

» | Helpful post? (+2)

Post #3
21774779 08 Dec 2025 13:09

p.kaczmarek2 wrote:
I'll 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 ali_sdk project from GitHub.

Congratulations on the idea and the jam.
I like that you decided to fight with this hardware. I've always been curious about getting a chip like this and reprogramming it.
#4 21774969 08 Dec 2025 16:23

bulek01 bulek01

Level 17

» | Helpful post? (0)

Post #4
21774969 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 way. To me, for example, it gives the satisfaction of using something instead of throwing it away.
Cool that you were able to get so much going.

piotr_go wrote:
Come on, for 25£ you can buy a tiny module (on RV1103) with better support.

I have just been seeing these modules on aliexpress lately. I am considering whether to buy one for testing. My question is where can you buy them so cheaply?
The Pico Mini B version with 64MB RAM and 128MB flash buying two pieces the cheapest I can find for 34zl/pc on ali.
#5 21774999 08 Dec 2025 16:55

piotr_go piotr_go

DIY electronics designer

» | Helpful post? (0)

Post #5
21774999 08 Dec 2025 16:55

bulek01 wrote:
where can you buy them so cheaply?

On the homepage in "Multirabates" they were recently at 24£ (pico mini a).
I bought the "Luckfox Pico Pro Max RV1106" for 45zł.
#6 21777012 10 Dec 2025 16:27

maciej_333 maciej_333

Level 38

» | Helpful post? (0)

Post #6
21777012 10 Dec 2025 16:27

p.kaczmarek2 wrote:
Do any of you have this or a similar Ali chip and would be willing to try your hand at programming it?

I have a tuner with the M3801. I will have a look at it in my spare time. I once made a simple SDR receiver on its head: Link . Then I played around with MxL5007 from another tuner: Link . This is how another SDR was created. I am currently doing an approach to SDR on a head unit from a DVB-S tuner. It will be an AV2012 chip. I even have it already running on an STM32. What chip is in the head end of the tuner you are working on? I'm looking for a DVB-T tuner where there would be some kind of chip in the head unit with IQ outputs, rather than the usual p.cz.

Regarding the Mstar platform, I have managed to run Linux on the MSD7818. Even this could be considered a reasonably useful minicomputer along the lines of the Rapsberry, although quite a lot weaker than it.
ADVERTISEMENT
#7 21788762 23 Dec 2025 20:44

maciej_333 maciej_333

Level 38

» | Helpful post? (+1)

Post #7
21788762 23 Dec 2025 20:44

Below are pictures of the Opticam HD N2 tuner on the M3801:

Here, exactly, there is no connector that could be a UART. The CN2 connector is probably a JTAG. However, given that it is known on which pins the UART is, it is possible to determine where the paths go from it. TxD and RxD come here:

Both lines are pulled up to +5 V using 4.7 kΩ resistors. However, despite this, the voltage levels are +3.3 V. Furthermore, there are still capacitors between TxD and RxD and ground. A strange solution. Further analysis leads to the conclusion that the UART is also here:

I added wires to this and connected a converter to FT232:

After setting in a bit rate of 115200 b/s and 8E1 something can be received there:

No response to CR and attempt to start the tuner e.g. with some key held down. The only thing the tuner responds to is "c":

If the tuner starts up with a constant "c" being sent, there is a boot pause:

The display then shows "ASH":

However, still no response to anything but "c".

There was no boot logo on HDMI at startup. After booting:

Menu and tuner information:

I tried to read the flash memory through the programmer on the CH341 using the clip. The neoprogrammer detected this memory supposedly as 25Q32, but even then it did not detect the chip when trying to read it. For this attempt I desoldered the FB1 choke on the flash memory supply and had to desolder the RCA connector as there was no room for the clip. Unfortunately I don't have a hotair now to desolder the chip.
ADVERTISEMENT
#8 21792106 28 Dec 2025 18:23

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

» | Topic author Helpful post? (0)

Post #8
21792106 28 Dec 2025 18:23

How did you know about this sending 'c'? I at the time of writing the topic didn't know about it, I only recently read it in the code.

BootLoader_clut8loader3bootloader.c
Code: C / C++
Log in, to see the code

I can't see so far that 'c' does anything other than interrupt bootloader.

And did you manage to rip the flash?

I'm going to try and see if it's not possible to just re-solder this flash permanently onto the socket (whether the line length will allow) so as not to solder from scratch with each attempt.

Added after 1 [minutes]:

ASH I think the lib_ash_shell is?
https://github.com/jinfeng-geeya/3202C/blob/b.../SRC/lib/libapplet/libbootupg3/lib_ash.c#L252

Added after 1 [minutes]:

Here you would have a list of commands in that case:
https://github.com/jinfeng-geeya/3202C/blob/b...c2/SRC/lib/libapplet/libbootupg3/lib_ashcmd.c
Code: C / C++
Log in, to see the code

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
#9 21792190 28 Dec 2025 19:40

maciej_333 maciej_333

Level 38

» | Helpful post? (0)

Post #9
21792190 28 Dec 2025 19:40

p.kaczmarek2 wrote:
How do you know about this sending 'c'?

I determined this very primitively i.e. by trial and error. I pressed various keys in the terminal. The tuner only responded to 'c'. I tried sending many 'c's, because maybe some buffer will overflow and some variable will continue to be overwritten making something interesting happen. However, this does not happen. This would also be evident from the bit of code you inserted.

p.kaczmarek2 wrote:
I managed to rip the flash?

I don't have a hot air right now. Desoldering the flash and then soldering it again without it is a mean pleasure. Such a small chip could still be removed without this.

p.kaczmarek2 wrote:
Here you would have a list of commands in that case

I'll see if there is a response to these commands.
#10 21792826 29 Dec 2025 15:18

maciej_333 maciej_333

Level 38

» | Helpful post? (+1)

Post #10
21792826 29 Dec 2025 15:18

I played around with these commands. Sending 'comtest' with or without a parameter after booting the application resets the tuner. It's a bit more interesting after suspending boot via 'c'. There is, of course, ASH at the start:

The 'comtest<CR>' can now be sent:

The display will show:

Comtest command code:
Code: C / C++
Log in, to see the code

Link

From this it would appear that r101 in the display is some kind of error. The way the command is used in the console does not show up:
Code: C / C++
Log in, to see the code

However, after sending e.g. "comtest 50<CR>" a little more happens:

As you can see there is already an echo. The display shows "Conn":

It is difficult to tell what the <data_num> parameter means. Running comtest with a smaller <data_num> and sending that many characters does nothing. After sending any two characters, the display goes something like this:

Sending e.g. just "comtest<CR>" again does not change anything.

No response to the rest of the commands. There are two versions of these commands in the code. There is no response to either. It appears from the code ( link ) that you can send in the older version "version - r<CR>", but that still doesn't work. The only thing that happens is some sort of response to "version<CR>;" sent as many times after comtest:

However, it's more of a bug in the code.

Also note that you need to send the command in one transfer (minimal delays between characters), not by pressing keys in the terminal. Without this, there is no response from the tuner.

As you can see rather most of this code is cut out. Partly too, of course, the tuner's behaviour coincides with the code. I don't know if such an analysis is useful for anything.

Added after 1 [hour] 8 [minutes]:

I did the tuner update via flash drive: Link :

The software version is different:

The console also shows this:

Now the tuner responds to 's' and 'c':

In the case of 's' the echo is delayed. However, the 's' doesn't actually do anything. It does not pause the boot.

It looks like the 'comtest' is not a UART test, it is sort of initialising the console. Currently after sending 'comtest 50<CR>' it works slightly better 'version - r<CR>':

However, you have to send the command twice. The "reboot<CR>" also works:

However, after this command the 'O' is sent first, then the rest. Also 'burn<CR>' works, but this command has to be called probably with some image loaded into RAM beforehand. This has corrupted the flash content. I therefore need to fix this. In the console there was something like this:

It even deleted the bootloader.
#11 21792964 29 Dec 2025 16:49

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

» | Topic author Helpful post? (0)

Post #11
21792964 29 Dec 2025 16:49

I didn't know there were so many batches on chomikuj. Interesting find. If these burns could be embraced, the experiments with this ALI would go much faster, as I have to upload each attempt separately to the flash (soldering out the bone) for now.

Surely the order is address, transfer, and burn?

This code of theirs is weird:

And address did you set that burn something messed up?
Code: C / C++
Log in, to see the code

Here they supposedly check.

Added after 20 [minutes]:

As much as I would test it myself, I don't think my CH340 will handle the required UART parity.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
#12 21793111 29 Dec 2025 19:07

maciej_333 maciej_333

Level 38
» | Helpful post? (+1)

Post #12
21793111 29 Dec 2025 19:07

I have restarted this tuner. I found the batch for it: Link . The file that is in this topic is a bit too long. I don't know how it was read. However, after cutting the end in the hexeditor and thus shortening the file to 0x400000 B it is possible to program the memory. It turns out that the software version is identical to what it was with me originally. I then did an update with the file from Chomikuj and re-soldered the flash to read it. I am inserting the batch in the attachment. The update is very important because more commands work.

Regarding the flash desoldering itself, you can easily deal with such a small chip by the so-called "short circuit" method:

Attachments:

opticum_hd_n2_upgraded.bin Download (4 MB)
#13 21793173 29 Dec 2025 22:56

maciej_333 maciej_333

Level 38

» | Helpful post? (+1)

Post #13
21793173 29 Dec 2025 22:56

p.kaczmarek2 wrote:
Interesting find. If I could get these burns to work, then the experiments with this ALI would go much faster, because I currently have to upload each test separately to the flash (solder the die).

I don't know exactly how this works. From analysing the code, it seems to me that rather the transfer receives something via UART and writes it to memory. Here is the start of the code for this function: Link . You can find there, for example, a call to the packet_receive function: Link . You can see the outline of some textual communication protocol (probably "ASCII hex"). The packet is supposed to end with CR and LF. It would be good to run the dump first, but I don't think that command is there.

Added after 2 [hours] 57 [minutes]:

However, there is a dump. The code for the version of this feature on my tuner is here: Link :
Code: C / C++
Log in, to see the code

The implication is that initially there will be 'dup' on the display, then a flash length will be sent, there will be a wait for 'O', a dump will be sent and finally a CRC. While the dump is being sent, something is supposed to flash on the display.

You have to send a comtest after boot pause, e.g. "comtest 50<CR>" and then "dump<CR>". The latter has to be sent several times until the display shows "dup":

In the console it might look like this:

"NULL @ NULL NULL" is the size of the flash. However, it is not sent in text, but in binary. According to the ASCII code table, the '@' is 0x40. So the size is 0x00400000 B=4194304 (dec) B. This is the correct value. If the host sends something other than 'O', the display will show 'r801':

When an 'O' is sent in turn, a dump (binary) will be sent. A CRC will be added at the end. Obviously this takes a little time. During the transfer, the display flashes " | |":

In the terminal you have to set the write to file. The dump looks normal:

There is a CRC at the end:

This makes the file size 4 B larger than the flash size. It is difficult to say what the CRC algorithm is here. Initially, the CRC is initialised by 0xFFFFFFFFFF. This is some knowledge, because you still need to know the polynomial. It is not the common 0x04c11db7. However, this is not so important now.
#14 21793388 29 Dec 2025 23:52

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

» | Topic author Helpful post? (0)

Post #14
21793388 29 Dec 2025 23:52

Nice progress, and isn't that the same CRC they use for the partition table?
https://github.com/openshwprojects/AliUnpacker
https://github.com/openshwprojects/AliUnpacker/blob/main/iterate/crc.cpp
In this project is the code for their CRC, which correctly verifies the CRC of partitions that do not have the NCRC type

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
ADVERTISEMENT
#15 21794256 30 Dec 2025 22:37

maciej_333 maciej_333

Level 38
» | Helpful post? (+1)

Post #15
21794256 30 Dec 2025 22:37

p.kaczmarek2 wrote:
In this project is their CRC code, which correctly verifies the CRC of partitions that do not have the NCRC type

The problem is that I can't work out how to calculate the CRC. I tried to run the code you provided, which is the "MG_Compute_CRC" function. Unfortunately the CRC does not match. In the attachment I insert the dump I read with the command "dump<CR>". The last four bytes are precisely the CRC. Maybe you have an idea on this?

Regarding the flash programming via UART, proceed as follows:
1. Hold boot by sending 'c' during boot.

2. Send 'comtest 2<CR><CR><CR>. However, there should be a smaller parameter value and exceptionally two additional <CR>;. This ensures that the console works properly and you no longer need to send commands several times. So for "comtest 2<CR>" alone, the display is "Conn". Whereas after two additional <CR> there will be "R013":

3. Send "address 0<CR>". The parameter 0 here is the starting address in flash. However, it is aligned to the sector size, i.e. 4096 B (there are 4194303/4096=1024 sectors). For writing the whole flash it should be 0. If the address for the command "address <start_address><CR>" is larger than the flash size then there is an "r302" on the display and an 'E' is sent:

For the missing parameter it is 'r301':

With a valid address an 'O' will be sent and the display will remain what it was last. The address can be from 0 to 4194303.

4. Send 'transfer <data_length><CR>'. Here <data_length> is the size of the image to be sent probably in bytes. The display will show 'trn' and an 'O' will initially be sent:

There is then a wait for data packets. When a packet fails to arrive or is erroneous an 'E' is sent. I was able to determine that the length of the packet must be 2048 B (in the code it is supposedly 1024). The packets must have a CRC at the end, and the packet length takes the CRC into account. For this command too, there can be errors "r501" and "r502" shown on the display. The only thing available is to send raw and uncompressed image data. Uploading everything as a compressed image using 7zip will not work. This is a pity, as it would make things a lot easier.

5. Eventually, you have to send "burn<CR>" and then "reboot<CR>" to load the new image and run it.

To sum up, if I had a CRC, I would have already managed to make a flash write program via UART.

p.kaczmarek2 wrote:
This code of theirs is strange:

Yes, that's right. Something like this also occurs in other functions: Link regarding checking the argc variable (number of command parameters).

Attachments:

dump.bin Download (4 MB)
#16 21794337 31 Dec 2025 00:27

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

» | Topic author Helpful post? (0)

Post #16
21794337 31 Dec 2025 00:27

It works for me, maybe you fell in the endiannes trap? Order of bytes.

Added after 1 [minutes]:

Here's the source code: https://github.com/openshwprojects/AliUnpacker

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
#17 21794359 31 Dec 2025 01:50

maciej_333 maciej_333

Level 38

» | Helpful post? (0)

Post #17
21794359 31 Dec 2025 01:50

Thanks for the suggestions. I want to do this in LabVIEW. I made a code like this:

From the conditional compilation in your code, it would appear that this is the variant being used. Still need to think what is wrong here.
#18 21794459 31 Dec 2025 09:40

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

» | Topic author Helpful post? (0)

Post #18
21794459 31 Dec 2025 09:40

This is the first time I have seen such an environment. Why such a choice?
It still seems to me that the bswap32 call is missing there
Code: C / C++
Log in, to see the code

You have a little endian system on your computer, and those CRCs are probably in big endian.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
#19 21794579 31 Dec 2025 12:00

maciej_333 maciej_333

Level 38

» | Helpful post? (0)

Post #19
21794579 31 Dec 2025 12:00

It's not a question of endianess. In LabVIEW I display the CRC as HEX (not decimal), so if I had the order wrong, it would be immediately apparent. For some reason the C code doesn't want to work properly there. So I have rewritten the "MG_Compute_CRC" function into graphical code:

Now the CRC calculated in LabVIEW is as follows:

In the file it is the same:

I also ran this fast version of the CRC with the "MG_Table_Driven_CRC" function. It works correctly and actually faster, but I don't need it.

Now it remains to encapsulate this in what is known as SUBVI, which is the LabVIEW equivalent of a function from C, and to do the rest of the code.

p.kaczmarek2 wrote:
This is the first time I have seen such an environment. Why such a choice?

For embedded systems I normally use the C language. Regarding the PC I now only use LabVIEW. I find it extremely convenient and readable. It is cool, especially if you need to do something with measurement equipment. The environment is second to none for measurement systems. However, it can also be treated as a 'normal' programming language.
#20 21794617 31 Dec 2025 12:33

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home
» | Topic author Helpful post? (+1)

Post #20
21794617 31 Dec 2025 12:33

Interesting, maybe when I find the time I'll try it out.

Since there is a CRC, is it now possible to send data to the Flash? I'd help out with a little C tool for this, but I think I seriously need to order an FTDI first. Personally, I'd most like to get hold of a minimal environment that would upload and fire the program via UART to Ali, preferably with an automatic reset of the whole thing. It would then be possible to do further combinations. In the mini-project I showed in the first post, the UART still doesn't work stably, because it is based on polling, you have to run interrupts.

I'm attaching the source code of the bootloader for the 3602. Not everything has sources, but there are .a files. As luck would have it, I also have the application and OTA codes.

Attachments:

ali3602-BootLoader.rar Download (1.41 MB)

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
#21 21794965 31 Dec 2025 17:00

maciej_333 maciej_333

Level 38

» | Helpful post? (0)

Post #21
21794965 31 Dec 2025 17:00

It appears that 2048 B packets should not be sent. However, it is 1024 + CRC. Hence, a packet with a total length of 1028 B is sent. I am currently already able to send the image to memory using the "transfer" function.

p.kaczmarek2 wrote:
Since there is a CRC, is it now possible to send data to Flash memory?

I've got quite a bit of progress already. It looks like it should be doable by now. Actually the code in LabVIEW can be compiled and run without the environment (you need to install the runtime and NI VISA drivers).

Since we are talking about Ali chips here, I have an interesting head unit from a Ferguson Ariva 150 Combo DVB-S/DVB-T tuner:

There is a MxL5007T (head) that is well known to me:

I have already run this chip with very good results in SDR. The second chip is the mysterious M3100 (demodulator):

It probably outputs MPEG-TS. However, maybe it can be programmed to read the I and Q components via SPI. The problem is that I can find absolutely nothing about it. Have you perhaps even seen any code, schematic, pinout etc.?
#22 21794980 31 Dec 2025 17:19

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home
» | Topic author Helpful post? (+1)

Post #22
21794980 31 Dec 2025 17:19

I see no direct mention of the ALI M3100 so far. Only I have about the M3326C, M3327, M3328, M3329, M3330.

M3101 I have. First page:

The rest in the appendix.

I haven't checked thoroughly so far, but maybe it's a different version of this circuit?

But I don't think it's that, because it's the main processor.

Attachments:

585046784-ALI-M3101-DVB-T.pdf Download (143.84 KB)

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
#23 21795327 01 Jan 2026 02:53

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

» | Topic author Helpful post? (+1)

Post #23
21795327 01 Jan 2026 02:53

I know where I have seen M3100. These are pics from someone outside the forum:

Cabletech URZ0083 DVB-T decoder

[url=https://obrazki.elektroda.pl/7240899100_1767232358.png] [/url]

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
#24 21795502 01 Jan 2026 13:22

maciej_333 maciej_333

Level 38

» | Helpful post? (0)

Post #24
21795502 01 Jan 2026 13:22

From this it would appear that the M3100 and M3101 are something completely different. The latter is another SoC in the style of the M3801 and its ilk. The M3100, on the other hand, is actually a demodulator of some sort. I wanted to desolder it from this board to use the MxL5007T itself (an excellent chip for SDR), but I don't think I'll do that for now. Maybe someday something about the M3100 will surface somewhere.
#25 21795510 01 Jan 2026 13:31

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

» | Topic author Helpful post? (+1)

Post #25
21795510 01 Jan 2026 13:31

I still found something like this:

https://www.gutek.com.pl/tunery_cabletech_urz0083_urz0086_recenzja.htm

Perhaps the author - @@GUTEK@ ? - knows something more.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
#26 21797046 02 Jan 2026 23:27

maciej_333 maciej_333

Level 38

» | Helpful post? (0)

Post #26
21797046 02 Jan 2026 23:27

I have already made a preliminary version of the flash writing program via UART in LabVIEW. It is generally in line with the description and observations I gave earlier. Regarding the command "burn<CR>", it should be noted that a write probably only occurs if the inserted image is different from the current one. Furthermore, this command does not necessarily feel like writing to certain flash locations. It does not write to those places where all settings such as volume, channel list etc. are present.

Below is the program code in LabVIEW:

This is the so-called Block Diagram, a kind of source code. No subroutines (SUBVI, something like functions) here, of course. The user panel (the so-called Front Panel) looks like this:

The programme is completely automatic. It aligns the image size itself to the packets that are written to the flash. The completion is done by 0xFF. In addition, there is a reboot after writing. I also figured out how to reset the tuner when there is an application loaded. There are no M3801 leads, so not even sure where any RST/NRST style lead is. However, you can use the STAND-BY key that is on the remote control board and thus on the front panel:

Generally it comes out that this key is connected directly to some GPIO/processor interrupt line. The rising/falling edge turns the device on or off. Hence it occurred to me to primitively control this line, e.g. with an RTS on a USB<->UART converter. So such a solution was created:

I have used an additional 'splitter' diode here. This ensures that when there is a high level on the RTS line, while the SW1 key is pressed, there will be no short circuit on the RTS. I have not checked if there is any external pull-up resistor for SW1. As you can see by controlling RTS appropriately you can reset the tuner when the application is loaded.

The tuner board during testing:

Added diode:

To run the program, simply switch on the tuner with the USB<->UART converter module attached, select the image file, COM port number and address in flash. Then simply run the program by clicking Run in LabVIEW (on any of the panels):

So far it seems to be working somehow. Uploading small images is quite fast. Could you insert some of your compiled image with a description of where in the flash (offset) it should be uploaded? This would allow me to do a final test.

Then I will compile it and make the program available with the graphic code. It will not be such a small tool. There is still something to be installed there. However, you don't need a LabVIEW licence for this. You can also install LabVIEW Community Edition which is free (same functionality, no commercial projects possible).
#27 21797094 03 Jan 2026 00:22

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home
» | Topic author Helpful post? (0)

Post #27
21797094 03 Jan 2026 00:22

The solution presented in the first post is uploaded to address 0x0 and replaces the entire factory flash, so we have yet to determine where after the bootloader the jump is made or if there is a command to make the jump to a given offset.

I have one batch saved, it is completed with 0x00 to the size of the 4MB batch, but can be trimmed.

This is the programme from the paragraph "Better button scan". I won't give 100% certainty that it's ok, but I've almost certainly saved it to myself as already tested.

If you need to offload the tool to pure C then I can help, as long as I understand how it works in LabView.

Attachments:

ali_sdk_padded-chipID_and_inputs_scan_indexed.zip Download (18.94 KB)

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
#28 21797468 03 Jan 2026 14:37

maciej_333 maciej_333

Level 38
» | Helpful post? (+1)

Post #28
21797468 03 Jan 2026 14:37

I uploaded via UART and my program in LabVIEW your example. I shortened the file, of course, so as not to wait for more than 4 MB to be uploaded. Generally it works, but since the bootloader was overwritten, the command "reboot<CR>" somehow didn't work. A bit strange, actually, as everything was in RAM after all. So the power had to be switched off and then on again.

When running this example, you can pick up something like this:
Code: text Expand Select all Copy to clipboard
Booting... Main function stack end: 82000000 stack start: 82008000 heap start: 8100093c heap end: 8100893c cause: 9000004c x: 1.230000 y: 1.250000 result: 25.729999 cause: 9000004c chip id raw: 3811 UP Pin 9 is now UP! UP Pin 12 is now UP! UP Pin 13 is now UP! UP Pin 14 is now UP! UP Pin 21 is now UP! UP Pin 23 is now UP! UP Pin 24 is now UP! UP Pin 25 is now UP! UP Pin 26 is now UP! UP Pin 27 is now UP! UP Pin 28 is now UP! UP Pin 29 is now UP! UP Pin 31 is now UP! UP Pin 32 is now UP! UP Pin 33 is now UP! UP Pin 34 is now UP! UP Pin 35 is now UP! UP Pin 36 is now UP! UP Pin 37 is now UP! UP Pin 38 is now UP! UP Pin 39 is now UP! UP Pin 43 is now UP! UP Pin 44 is now UP! UP Pin 45 is now UP! UP Pin 46 is now UP! UP Pin 50 is now UP! UP Pin 51 is now UP! UP Pin 52 is now UP! UP Pin 53 is now UP! UP Pin 54 is now UP! UP Pin 56 is now UP! UP Pin 59 is now UP! UP Pin 60 is now UP! UP Pin 61 is now UP! UP Pin 62 is now UP! UP Pin 63 is now UP! UP Pin 64 is now UP! UP Pin 72 is now UP! UP Pin 73 is now UP! UP Pin 75 is now UP! UP Pin 76 is now UP! UP Pin 77 is now UP! UP Pin 92 is now UP! UP Pin 93 is now UP!

No response to the keys on the board. Then the echo works (sometimes only after some time after start-up):

However, you have to send characters very slowly, otherwise bushes come out and there are erroneous frames. So the problem with the stability of the UART operation is rather not on the converter side. I have an FTDI and it is not good either.

In the attachment I insert the sources in LabVIEW (*.VI files) and the compiled program (builds directory). Pre-install the so called Runtime version 2015: Link and NI VISA (drivers for RS232, USB, ethernet, GPIB etc): Link (version 15.5). When you start the application, you select the COM port number, the image file and enter the address (offset). The address should be aligned to the flash sector size (4096 B). From the code, if this is not done, the bootloader will align it anyway. However, the code will then not be inserted where it needs to be. So, the address should be an integer multiple of 4096. Next, it is enough to have the tuner connected (running and with the application loaded) according to the scheme above. Finally click Run (single start, not continuous):

Eventually you have to wait for the image to be uploaded and reboot.

p.kaczmarek2 wrote:
If you need to offload the tool to pure C then I can help, as long as I understand how it works in LabView.

I don't know altogether if it's worth it. Now as if you already know exactly where the application is in flash and how to compress it before loading, this could also be added to LabVIEW.

Attachments:

ali_labview.rar Download (500.44 KB)
#29 21797499 03 Jan 2026 15:00

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

» | Topic author Helpful post? (0)

Post #29
21797499 03 Jan 2026 15:00

maciej_333 wrote:

However, you have to send characters very slowly, otherwise bushes come out and there are erroneous frames. So the problem with the stability of the UART operation is not likely to lie with the converter.

I wrote about this in the first post - the mini SDK I presented here has no UART interrupt support and the UART relies on polling. By the way, the author of the SDK also knows about the problems himself, I talked to him on GitHub. This means that embracing the factory bootloader and a workflow for uploading the batch conveniently would help a lot in further work.

maciej_333 wrote:

Generally works, but since the bootloader was overwritten, the command "reboot<CR>" somehow didn't work.

Can you elaborate on this? I was thinking of trying to upload to some offset that the original bootloader jumps to, so that you can use the original bootloader to upload new programs. Did you just upload to 0x0?

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
#30 21797615 03 Jan 2026 16:51

maciej_333 maciej_333

Level 38

» | Helpful post? (0)

Post #30
21797615 03 Jan 2026 16:51

p.kaczmarek2 wrote:

maciej_333 wrote:
Generally works, but since the bootloader was overwritten, the "reboot" command somehow didn't work.

Can you elaborate on this? I was thinking of trying to upload to some offset that the original bootloader jumps to, so that you can use the original bootloader to upload new programs. Did you just upload to 0x0?

I have currently uploaded this to offset 0x00000000. The bootloader has of course been overwritten. However, even after writing to flash it was still working after all what was in the RAM loaded beforehand. Hence, it seems that the "reboot" command should work this one more time. Presumably it is just a reboot, not a simple CPU reset, and hence the effect.

Ultimately, of course, the program would be loaded with some sort of offset so as not to overwrite the bootloader. For that, however, you need to keep the file format as it is in flash and there is still a lot to learn.
Create an account, log in here. You will receive points by participating in discussions.
Join this discussion.

Install Elektroda application

Reply Cool? Ranking DIY | New topic

Notify about new articles

📢 Listen (AI):

Report a violation of the law

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]