Czy wolisz polską wersję strony elektroda?
Nie, dziękuję Przekieruj mnie tamI have a question. When we boot, the software written to this ROM is around 16 MB. If the original program is still on it, where does it copy to? If I buy a CH431 flash ROM, will the program still be on it when I read the ROM? If we are reading from the ROM, how does the program we are installing write to the ROM? Where is the factory program installed? Can you help me?
Yes. I can help, and the main idea is this:
Your question mixes three different memories, so the first important step is to separate them clearly:
| Memory | What it is | Volatile? | Typical role |
|---|---|---|---|
| BROM / Boot ROM | Very small ROM inside the SoC | No | First code executed after power-on |
| SPI NOR flash | External nonvolatile storage chip, often 8/16/32 MB | No | Stores bootloader, kernel, rootfs, app |
| RAM / DDR | Working memory | Yes | Where code executes fast and where data lives while system is running |
On the F133, Allwinner documents an on-chip BROM and support for booting from SPI NOR, SPI NAND, eMMC, or SD. The F133 product brief also shows 64 MB DDR2 in the package. (bbs.aw-ol.com)
A practical boot flow is usually:
That means the external 16 MB flash is primarily storage, while RAM is the workspace for execution. However, one correction is important: you should not assume the system always copies the entire 16 MB image into RAM in one shot. Often only the needed boot stages, kernel, and selected data are loaded; some content may remain stored in flash and be read later as needed. The key point is that the original firmware image remains on flash unless something erases or overwrites it. This is consistent with the F133 boot model and with standard flash-based embedded boot design. (bbs.aw-ol.com)
A useful mental model is:
Internal BROM -> finds boot medium
External SPI flash -> stores firmware permanently
RAM/DDR -> temporary execution space after boot startsSo when you ask, “If the original program is still on it, where does it copy to?”, the answer is:
This is why power can be removed and the device still boots again later: the permanent image is in the flash, not in RAM. (bbs.aw-ol.com)
I assume you meant CH341A, not CH431. Flashrom’s official documentation lists ch341a_spi as a supported programmer for SPI flash ROMs. Its manual states that:
-r reads flash contents into a file,-w writes a file into flash,So if the board’s flash currently contains the factory firmware, and you connect a CH341A and perform a read, you should obtain that firmware image as a binary dump. A read operation does not inherently erase the chip. In normal engineering practice, reading is used specifically to make a backup before any modification. (flashrom.org)
There are two different purchase cases:
You buy a CH341A programmer
You buy a new replacement flash chip
This is the part that confuses many people, but it is straightforward once memory roles are separated.
There are several valid mechanisms:
A. Bootloader / updater running from RAM
A bootloader can load itself or its flash-writing routine into RAM, then erase and program the external flash. Microchip’s official documentation on self-programming explains the same general principle: a bootloader section can perform flash updates, and when execution is from RAM, the CPU can continue while flash programming proceeds. (ww1.microchip.com)
B. ROM recovery mode
The F133 BROM includes a FEL module, and Allwinner’s documentation says FEL is responsible for writing external data to local NVM. That means the chip has a built-in recovery/download path independent of the normal application firmware. (bbs.aw-ol.com)
C. External programmer
A CH341A writes the flash directly over SPI while you treat the flash chip as a raw memory device. Flashrom’s manual describes the write flow as erase → write → verify. (flashrom.org)
So the short answer is: the device is not simultaneously depending on the same flash bytes for instruction fetch while those exact bytes are being erased/programmed. The update logic is normally executing from another place: RAM, ROM, or another protected region. (bbs.aw-ol.com)
For an F133 system configured to boot from SPI NOR flash, the factory firmware is typically stored in that external SPI NOR flash device. The on-chip BROM is far too small and is intended only for bootstrapping and recovery; Allwinner explicitly describes it as the primary loader that selects media and handles FEL/medium boot. (bbs.aw-ol.com)
Therefore:
If you replace the external flash with a blank chip, the SoC still has its internal BROM, but it may fail normal boot because there is no valid external boot image. Depending on board configuration, it may then require recovery/programming via FEL or another supported boot source. (bbs.aw-ol.com)
From current official flashrom documentation, CH341A remains a supported SPI flash programmer, and flashrom continues to document direct commands for read and write using ch341a_spi. The same documentation also still warns about the electrical issues of some common CH341A board variants, especially voltage handling on older black boards. (flashrom.org)
For the F133 specifically, currently available Allwinner documentation still describes:
A current engineering trend in embedded products is to keep:
Think of the system like this:
The warehouse keeps the original goods. The workbench is where actual work happens. If you update the warehouse inventory, you do it while the workers are already operating from the bench or from a separate supervisor-controlled procedure. (bbs.aw-ol.com)
Another useful point: in casual conversation many people say “ROM,” but on modern boards this is often actually flash memory, which is electrically rewritable. That is why you can both read it and reprogram it. Flashrom’s own naming reflects this historical convention by using the phrase “flash ROM.” (flashrom.org)
If your goal is to inspect or preserve the factory firmware, do this:
Typical commands with flashrom and a CH341A are documented as:
flashrom -p ch341a_spi -r backup.bin
flashrom -p ch341a_spi -w newimage.binThose example commands are shown in flashrom’s CH341A documentation. (flashrom.org)
Potential challenges:
If you want to go deeper, the next useful technical topics are:
A very practical next step is to identify your flash device marking, for example a Winbond or Macronix part number, because that determines voltage, capacity, erase size, and protection behavior. (flashrom.org)
In simple terms:
If you want, I can next give you a very practical step-by-step procedure for:
User question
Now, if I get this CH431B programmer and use it, will I be able to flash my device's factory firmware, or will the factory firmware be erased during the update?
Artificial Intelligence Response
Direct answer to the question
Yes — you can use that programmer to flash the factory firmware back onto the device, but only if you first have a valid copy of that factory firmware image. Simply reading the flash chip does not erase anything. However, when you perform a write/program operation, the programmer software will typically erase the target chip or the sectors being updated, then write the new image. In other words: read = non-destructive; write = destructive to the old contents being replaced. (flashrom.org)
So the safe workflow is:
That backup is what lets you restore the original factory state later. (flashrom.org)
Detailed problem analysis
A USB SPI programmer in the CH341A/B family is just an external interface to the flash memory. Flashrom explicitly supports CH341A/B programmers, and its documented operations are probe, read, write, verify, and erase. (flashrom.org)
The critical distinction is between these operations:
-r)-v)-E)-w)This behavior is described directly in the flashrom manual:
-rreads the ROM contents into a file, while-wwrites a file and first automatically erases the chip before programming it. (flashrom.org)So, if your question is:
“Can I preserve the factory firmware?”
Yes — by doing a read backup first. That operation is non-destructive. (flashrom.org)
“Will the factory firmware remain on the chip after I flash a new image?”
Generally no — the old contents in the area being written will be erased/overwritten during the write process. (flashrom.org)
“Can I later restore the original factory firmware?”
Yes — if you saved a good dump of the original contents, you can write that dump back later. (docs.mrchromebox.tech)
A further nuance: not every update has to overwrite the entire chip. Flashrom supports layout- or region-based operations, such as writing only selected regions in some firmware layouts. In those cases, only the addressed region is modified, not necessarily the full device image. (flashrom.org)
Current information and trends
Current flashrom documentation still lists CH341A/B among supported programmers, which is relevant because many low-cost USB SPI tools sold today are based on that family. (flashrom.org)
A current practical concern is voltage compatibility. Flashrom’s own CH341A/B documentation warns that some common black CH341A boards are wired in a way that can put nearly 5 V on signals going to EEPROM/flash devices, which is unsafe for many 3.3 V parts. The same documentation notes that many flash chips are normally 3.3 V, and some devices require 1.8 V adapters. (flashrom.org)
Industry practice has also shifted toward preserving device-specific data when reflashing. Recent unbricking/manual-flashing guides emphasize that a backup is critical, and that items such as VPD/HWID or other board-specific data may need to be preserved when replacing firmware images. (docs.mrchromebox.tech)
Supporting explanations and details
Think of the flash chip as a rewritable storage medium:
Also note that many tools do not simply “paste over” old data. Flash memory technology normally requires erase-before-write behavior. Flashrom explicitly documents that its write flow includes reading the old contents, erasing, writing, and then verifying. (flashrom.org)
If your goal is to restore the exact factory state, the best source is usually:
Your own dump is preferable because it may contain device-unique information not present in a generic downloaded image. Recent firmware guides explicitly call out preservation of device-specific data for successful recovery. (docs.mrchromebox.tech)
Ethical and legal aspects
From a legal and support standpoint, reflashing firmware can void warranties or conflict with vendor support procedures, depending on the product. From a privacy/security standpoint, a full flash dump may contain device-specific identifiers or configuration data, so treat backups as sensitive files and do not share them casually. The preservation of unique board/device data is a real technical concern in current firmware workflows. (docs.mrchromebox.tech)
Safety-wise, the main hardware risk is using the wrong voltage or wrong pin orientation. Flashrom’s CH341A/B documentation explicitly warns about problematic board variants and instructs users to check the flash chip datasheet for the correct voltage. (flashrom.org)
Practical guidelines
Recommended procedure:
Confirm the flash chip part number.
Check whether it is a 3.3 V or 1.8 V device before connecting power from the programmer. (flashrom.org)
Use the programmer only to detect/read first.
With flashrom, probing and reading are separate from erase/write operations. (flashrom.org)
Make a backup before any write.
This is strongly recommended in both flashrom documentation and current external-flashing guides. (flashrom.org)
Prefer two reads and compare them.
This is good engineering practice to catch poor clip contact or in-circuit bus interference.
Only then perform the write.
Expect the old contents in the programmed region to be erased and replaced. (flashrom.org)
Verify after writing.
Flashrom normally verifies after a write unless verification is disabled. (flashrom.org)
Possible disclaimers or additional notes
Suggestions for further research
Before you proceed, the most useful next checks are:
If you want, I can help you determine that from:
Brief summary
Short version:
If you send me the exact programmer listing and the flash chip model, I can tell you whether you need a 1.8 V adapter, what software to use, and the safest exact backup/flash sequence.