Original firmware for F133B F18-V3.2 after failed update, no power

estatu25 wrote:

cihaza 7010b opel yazan yazılımı yükledim logo ve radio açılıyor ve fakat dokunmatik çalışmıyor işlem yapamıyorum takılı kaldı o şekilde @ElektrodaBot @ElektrodaBot

Users posts before the question:
...

Initial assessment

From your description and the photos, this is not a complete hardware brick.
It is a firmware mismatch.

Your board is clearly marked:

- SoC: Allwinner F133-B
- Mainboard: F18-V3.2
- PCB date: 2024-07-31

The display label also appears to be something like:

- LC7A-RS070WST217-TAM0

So the important identifiers are F133-B + F18-V3.2 + the exact LCD/touch assembly.
The name “7010B Opel” is not sufficient to choose firmware.

---

Direct answer

If the unit shows logo and radio/audio works, but touch does not respond at all, then the firmware you installed is almost certainly using the wrong touchscreen driver or wrong touch configuration for your panel.

In other words:

- LCD initialization works
- main system boots
- audio path works
- touch controller does not match the firmware

So the unit is partially alive, but with the wrong software.

---

Why this happened

These generic MP5/car multimedia devices often look similar externally, but internally they use different:

- LCD panels
- touch controllers
- flash sizes
- board revisions
- GPIO mappings
- boot configurations

That is why a firmware called:

-

7010B

-

7018B

-

Opel

-

mtc-10.img

may boot on another board, but still leave:

- no touch,
- inverted image,
- no sound,
- no buttons,
- or total brick.

In your case, the symptom is very typical: wrong touch driver.

---

Important correction

A normal reset button usually does not restore original firmware.
It only restarts the device, unless that specific bootloader has a recovery mechanism.

Also, if touch is completely dead, this is usually not just a calibration problem.
Calibration helps when touch is shifted or mirrored.
Your case looks more like driver mismatch.

---

What you should do now

1. Stop flashing random files

Do not try more random “7010B”, “Opel”, or “MTC” files.

That is the fastest way to turn a partially recoverable unit into a full brick.

---

2. First try to regain control without touch

Before doing hardware programming, try these:

A. USB mouse
Connect a standard USB mouse to the device USB port.

Sometimes these F133-based units support a mouse cursor even when touch is dead.
If a cursor appears, you may be able to:

- enter settings,
- open update menu,
- flash correct firmware.

B. IR remote
If the unit came with a small remote, try it.

Sometimes menu navigation still works even when touch does not.

C. Physical buttons
If there are side/front keys:

- Power
- Mode
- Volume
- Menu/Home

test whether any of them can enter a settings or update screen.

---

3. Reflash only with firmware for the exact board

You need firmware matching as closely as possible:

Required match	Importance
F133-B	critical
F18-V3.2	critical
same flash memory type/size	very important
same LCD/touch module	very important
same front panel/button wiring	important

A file labeled only “7010B Opel” is not enough.

---

4. If you cannot control the screen: hardware-level recovery is the reliable path

If mouse/remote do not work, the proper repair path is:

A. Identify the SPI flash chip
Please post a sharp close-up of the 8-pin flash memory IC on the mainboard.

It is usually marked something like:

- 25Q64
- 25Q128
- W25Qxx
- GD25Qxx
- MX25Lxx

This matters because we need to know:

- chip type
- voltage
- capacity

B. Identify the touch controller
The touch controller may be:

- on the mainboard, or
- on the small PCB attached to the display/touch ribbon

Please post:

- a sharp photo near the display ribbon connector
- a photo of the front panel PCB
- the back side of the mainboard

This is often the missing piece.

C. Program the flash directly
If there is no other way, use:

- CH341A programmer
- SOIC8 clip
- software such as NeoProgrammer or AsProgrammer

Very important:
- Use 3.3 V, not 5 V
- First read and save backup at least 2 times
- Compare the two reads to confirm a good connection
- Then erase / write / verify

Because the unit still boots, even a bad dump can still contain useful board-specific data.

---

5. Possible alternative: boot/update from TF/microSD

Since this is an Allwinner F133-B platform, some variants can be recovered from:

- TF/microSD boot card
- vendor update card
- vendor USB update image

But this only works if you have the correct image format for this board family.
Not every

.img

file is interchangeable.

So yes, SD-card recovery is possible on some units, but only with the correct F18-V3.2 image.

---

What your photos already tell us

From the photos, I can already say:

- this is not a classic old 7010B board type,
- it is a newer F133-B / F18-V3.2 platform,
- therefore older “7010B” firmware packages are unsafe,
- the screen label may help identify the proper panel,
- the green daughterboard is probably not the cause of the touch problem.

So the main mistake was choosing firmware by product name instead of PCB/platform.

---

Best practical recovery order

Use this order:

1. Try USB mouse
2. Try IR remote / hard keys
3. Do not flash random images
4. Find exact F133-B / F18-V3.2 firmware
5. If still no control: read/write SPI flash with CH341A

---

What to upload next

Please add these clear, close photos:

1. Back side of the mainboard
2. 8-pin flash chip marking
3. Area around LCD/touch ribbon connector
4. Any small IC on the display/touch board
5. The full text from the display sticker

If you upload those, I can help you determine:

- where the flash chip is,
- whether the touch controller is visible,
- and whether recovery should be done by SD/USB or directly by programmer.

---

Brief summary

Your device is most likely soft-bricked by incompatible firmware, not physically damaged.

Logo + radio working + no touch = wrong touch driver/configuration, not necessarily bad LCD hardware.

The correct direction is:

- stop random flashing,
- try USB mouse first,
- then recover using exact F133-B / F18-V3.2 firmware,
or if needed,
- program the SPI flash directly with CH341A.

If you want, send the next close-up photos and I will mark which IC is the flash memory and what to check next.

estatu25 wrote:

@ElektrodaBot B5308 MP5 DE ALLWİNNER F133 kullanıyor img dosyasını bulabilirmiyiz

Users posts before the question:
```
Data: 03/04/2026
Treść: First of all, thank you for y...

Initial assessment

Yes, we can try to find the correct software, but as of April 14, 2026 I could not verify an official downloadable

.img

for the exact B5308 / F18-V3.2 / F133-B unit from an authoritative source. Your Elektroda thread does confirm the important context: this is an F133B / F18-V3.2 case, the SPI flash was identified as BoyaMICRO 25Q128, and the previously flashed Opel image reaches logo/FM and then freezes. (elektroda.com)

From the photos you added, the useful identifiers are now much better than just “B5308”:

- SoC: Allwinner F133-B
- Mainboard: F18-V3.2
- Board date: 2024-07-31
- LCD label: LM-RG070NS217-A0
- Touch FPC label: FOG-RS070WS48B1-A0
- SPI flash family: 25Q128 class

That is enough to stop guessing and search more intelligently.

---

Direct answer

Short answer:
Maybe, but not by searching “B5308 IMG” alone.

For your device, the correct match must be based on:

1. board revision:

F18-V3.2

2. SoC:

F133-B

3. LCD/touch assembly:

LM-RG070NS217-A0

+

FOG-RS070WS48B1-A0

4. preferably the same touch controller IC on the flex

So:

- Yes, we can continue searching.
- No, I would not trust any random

7010B

,

Opel

, or generic

B5308

image.
- If no exact

.img

is found, a full 16 MB SPI dump from the same board/panel is often more useful than an update image.

---

Detailed problem analysis

Allwinner’s own F133 brief says the F133-A/B family is used in car MP5 products and supports SD/eMMC, SPI NOR/NAND, USB host/OTG, and SDIO. That means your platform can realistically be recovered either by a correct vendor update package or by directly reprogramming the SPI flash; however, the exact boot/update path still depends on how this specific board was built. (allwinnertech.com)

The behavior you described earlier is very important:

- wrong Opel file boots,
- logo appears,
- FM/radio screen appears,
- touch does not work / device freezes.

From an engineering standpoint, that is much more consistent with a firmware mismatch than with dead hardware. In practice, this usually means one or more of these do not match the firmware:

- touch controller driver,
- touch GPIO/reset/interrupt pins,
- LCD init sequence,
- panel timing,
- key mapping,
- UI/application build for that board family.

So the unit is likely not fully bricked. It is more likely running the wrong image.

---

Why “B5308” is not enough

“B5308 MP5 DE” is probably a sales/product family label, not the real firmware identity.

For firmware matching, these are much stronger keys:

Use for search	Priority
F18-V3.2	Critical
F133-B	Critical
LM-RG070NS217-A0	Very important
FOG-RS070WS48B1-A0	Very important
25Q128	Important
portable 7" CarPlay MP5	Helpful

Do not prioritize these weak identifiers:

-

7010B

-

Opel

-

B5308

alone

Those names are too generic and often lead to a partially booting but unusable firmware.

---

Very important distinction:

.img

vs raw flash dump

Please keep this distinction clear:

1. Vendor update

.img

- used for SD-card / vendor update process
- size may vary
- may contain partitions, resources, bootloader pieces, etc.
- may still be board-specific

2. Raw programmer dump

.bin

- direct copy of the SPI flash chip
- for a 25Q128, the full dump should be 16,777,216 bytes
- ideal if using a CH341A or similar programmer

So if you cannot find the original

.img

, a known-good 16 MB dump from the same board can still save the device.

---

Best practical path now

Option A — Best and safest: read the SPI flash first
Because you already identified a 25Q128 flash, the smartest next step is:

1. use CH341A or equivalent programmer,
2. read the chip twice,
3. save:
-

read1.bin

-

read2.bin

4. compare them,
5. if identical, keep that backup safe.

Why this matters:

- even a “bad” current dump may still contain
- board config,
- panel config,
- touch config,
- calibration,
- version strings.

This is often enough to identify what image family the device really wants.

Voltage warning
Use 3.3 V only on the flash chip.

---

Option B — Search for the exact match before flashing anything else

Search with combinations like:



Also try these combinations:



If you find any candidate file, do not flash immediately.

First check:

- filename,
- size,
- strings inside with HxD or another hex editor,
- any occurrence of:
-

F18

-

F133

-

RG070

-

FOG-RS070

-

ctp

-

touch

-

panel

---

What I suspect from your photos

From the hardware labels, I suspect the display/touch assembly is the real discriminator here, not the “B5308” name.

In other words, the correct software is probably:

- same F18-V3.2 mainboard
- same LCD
- same touch flex/controller

Even another F133 portable monitor image may still fail if the touch IC differs.

One of your close-up photos of the touch area suggests there is a specific capacitive touch controller on the flex, but the marking is still too blurry to trust. That chip marking can be decisive.

---

What you should upload next

To increase the chance of locating a compatible image or adapting one, the most useful next items are:

1. full SPI flash backup (

read1.bin

/

read2.bin

)
2. sharp macro photo of the touch controller IC on the touch flex
3. exact marking of the 8-pin flash chip
4. if possible, a photo of the unit’s sticker/case label
5. if you find any candidate

.img

, upload:
- filename
- exact size
- where it came from

Then I can help you decide whether it is:

- likely safe,
- definitely wrong,
- or worth testing only via programmer.

---

My recommendation

If this were on my workbench, I would do it in this order:

1. Stop flashing random images
2. Read the 25Q128 flash
3. Search by F18-V3.2 + panel/touch labels
4. Prefer a same-board raw dump over a random

.img

5. Only after comparison:
- write known-good dump, or
- try exact matching update image

---

Brief summary

- I did not find a verified official B5308/F18-V3.2

.img

today.
- Your case is still recoverable.
- The important identifiers are F133-B + F18-V3.2 + LM-RG070NS217-A0 + FOG-RS070WS48B1-A0.
- The previous Opel/7010B file is almost certainly the wrong firmware family.
- The best next step is a full 16 MB SPI readout from the 25Q128 chip.

I verified the Elektroda thread details and the official Allwinner F133 brief, but neither provided a board-specific firmware download; that is why the missing piece is still an exact vendor image or a same-hardware flash dump. (elektroda.com)

If you want, in the next message I can help you with one of these two routes:

1. how to read the 25Q128 safely, or
2. how to inspect a candidate

.img

before flashing it.

estatu25 wrote:

@ElektrodaBot

Added after 1 [minutes]:

I couldn't find a suitable image file and I couldn't obtain it on another device. How and where can I download the image file?

Users posts before the ques...

Direct answer

As of April 19, 2026, I could not verify a public, exact

.img

update file for your F18-V3.2 / Allwinner F133-B unit. Your Elektroda thread confirms the important hardware identifiers: F18-V3.2, BoyaMICRO 25Q128, and the 7-inch panel/touch assembly labels you photographed. (elektroda.com)

What you can download right now

The only publicly downloadable firmware files I found that are genuinely relevant are in the

dan-os/B5300-reverse-engineering

GitHub repository. That repository is for a B5300-class Allwinner F133-B CarPlay display, and it contains an “original firmware backups” folder with two raw firmware files:
-

F133-20220107_HZ-BX-B5678-UI3-V1.9-20240419-1616.bin

-

F133-20220117_HZ-BX-MIPI-F1026-FM-1.4SDK-20240712-0947.bin

The repo states these are original, unmodified firmware backups. (github.com)

Both of those files are shown by GitHub as 16 MB files, and each file page has a “Download raw file” option. So if you want an actual downloadable firmware candidate, this is the first place I would check. (github.com)

Very important: these are

.bin

, not confirmed

.img

Those GitHub files are raw SPI-flash dumps (

.bin

), not verified microSD update images (

.img

) for your exact board. The same repository’s documentation explains that it is dumping the SPI flash ROM to

firmware.bin

, and its flashing page says the recovery process is to flash a new

firmware.bin

back to the SPI flash chip. (github.com)

So, if your question is strictly “where do I download a file?”, the answer is:
Download the

.bin

candidates from that GitHub repository.
But if your question is “where do I download the exact microSD

.img

for my F18-V3.2 board?”, I could not verify a public exact match. (github.com)

Why random

7010B

/

Opel

files are a bad idea

There is a useful clue in the FCC paperwork for the B5300 family: the model-difference document lists many aliases under the same product family, including 7010, 7010B, 7018, 7018B, and others. That explains why searching only by a generic sales name often finds “almost compatible” firmware, but not necessarily the correct LCD/touch configuration for your exact hardware. (fcc.report)

That also matches your real-world symptom: in your Elektroda thread, the Opel/7010B file boots far enough to show the logo and FM/radio screen, but the unit then freezes / loses touch control. That is classic wrong firmware family or wrong panel/touch configuration, not a trustworthy match. (elektroda.com)

How to download the candidate files

If you want to try the public files I found, do it this way:

1. Open the B5300 reverse-engineering repository.
2. Go to the folder

firmware/examples/B5300/original

.
3. Open one of the two 16 MB

.bin

files.
4. On the file page, use “Download raw file.” (github.com)

But do not write them by microSD as if they were update images

For this platform, the safer interpretation is that these public files are for programmer-based recovery. The same repo recommends reading the flash first, verifying the dump, and only then flashing. Official flashrom documentation also supports using a CH341A/B programmer to read and write SPI flash, and it shows the basic commands:
-

flashrom -p ch341a_spi -r filename.bin

-

flashrom -p ch341a_spi -w filename.bin

(flashrom.org)

Safety note

If you go the CH341A route, use 3.3 V, not 5 V. The official flashrom CH341A/B documentation specifically warns that the common black CH341A board can expose nearly 5 V on its outputs unless corrected, while the blue board is normally set for 3.3 V operation. (flashrom.org)

Practical recommendation for your exact case

For your hardware, I would proceed in this order:

- Do not flash more random 7010B / Opel

.img

files.
- If possible, read your BoyaMICRO 25Q128 first and save a backup.
- Then compare / try only the B5300-class 16 MB

.bin

candidates from the GitHub repository.
- If you only have microSD and no programmer, then I would not risk these

.bin

files directly; in that case you still need either:
- the exact vendor

.img

, or
- a full dump from another identical F18-V3.2 unit. (elektroda.com)

One more technical point

The official Allwinner F133 brief confirms that the F133-A/B platform is used in car MP5 devices and supports SPI NOR/NAND flash as well as SD/eMMC storage. So a raw SPI backup/restore path is completely consistent with this hardware family. (allwinnertech.com)

Brief summary

So, the honest answer is:

- Exact public

.img

for your F18-V3.2: I did not verify one.
- Public firmware you can actually download now: yes — two 16 MB

.bin

files from the B5300 reverse-engineering GitHub repository. (github.com)
- Best use of those files: with CH341A + flashrom, after making a verified backup first. (flashrom.org)

If you want, in the next reply I can give you either:

1. a step-by-step CH341A backup/restore procedure for your BoyaMICRO 25Q128, or
2. a risk comparison of the two GitHub

.bin

files to decide which one is less dangerous to test first.