FAQ
TL;DR: Beken dumps pack a CRC16 every 34 bytes; “Every 32 bytes of data is followed by 2 bytes of crc.” Extract the 01PE table (64‑byte entries) from the first 2 MiB, then parse it to get exact bootloader/app/OTA offsets for OpenBeken. [Elektroda, divadiow, post #21734412]
Why it matters: This lets you decide if you must flash a QIO bootloader or adjust OTA to avoid bricking.
Who this is for: OpenBeken/Tuya/Beken tinkerers who need reliable partition offsets from raw flash dumps so OTA and backups work consistently.
Quick Facts
- CRC pattern: firmware dumps interleave 32 bytes of data with a 2‑byte CRC16, repeating every 34 bytes. [Elektroda, divadiow, post #21734412]
- 01PE FAL entries are 64 bytes; scanning only the first 2 MiB and taking the last valid group lets the CLI decode partitions. [Elektroda, divadiow, post #21734412]
- Typical offsets seen: bootloader 0x00000000, app 0x00010000, download 0x0012A000–0x00132000; app sizes around 1,083,136 bytes. [Elektroda, p.kaczmarek2, post #21737515]
- Some Tuya BK7238/BK7252U dumps have no 01PE, so this method will not return partitions. [Elektroda, divadiow, post #21734412]
- OBK’s BKPartitions driver can detect and log partitions on‑device after CRC handling and sanity checks. [Elektroda, p.kaczmarek2, post #21737153]
How do I extract Beken partition info from a full flash dump?
Run a combined workflow: 1) strip the interleaved CRC (32+2 bytes), 2) scan the first 2 MiB for 01PE entries and extract the last valid group, 3) feed that file to rt_partition_tool_cli to print the table. The provided combined_uncrc_extract_run.py automates all three steps. [Elektroda, divadiow, post #21735502]
Why does the RT‑Thread GUI show nothing on a 2 MiB dump, but the CLI works?
The GUI expects a clean partition blob, while full dumps include CRC16 bytes every 34 bytes and other data. After removing CRCs and isolating the 01PE group, the CLI parses and prints partitions correctly. “It will work with the CLI.” [Elektroda, divadiow, post #21734412]
What is the “01PE” table and why are entries 64 bytes apart?
01PE is the FAL (Flash Abstraction Layer) magic used by Beken/RT‑Thread bootloaders to list partitions. Each entry is 64 bytes. Searching the first 2 MiB for contiguous 01PE entries (i, i+64, …) yields the active table that tools can decode. [Elektroda, divadiow, post #21734412]
Can OpenBeken detect partitions on the device without a PC?
Yes. The BKPartitions driver scans flash for 01PE, applies sanity checks, and logs partition name, flash type, offset, and size at boot or on command. Example logs show bootloader at 0x0, app at 0x10000, and download near 0x12A000–0x132000. [Elektroda, p.kaczmarek2, post #21737153]
Will this approach work on all Tuya/Beken variants?
No. Some Tuya BK7238 and 4 MB BK7252U dumps contain no 01PE; the scan returns nothing. In those cases, you need a different strategy (e.g., vendor bootloader knowledge or alternate tooling). That’s an expected edge case. [Elektroda, divadiow, post #21734412]
What offsets are typical on BK7231N/T devices?
Logs show common layouts: bootloader 0x00000000 (64K), app 0x00010000 (~1,083,136 bytes), and download around 0x0012A000 or 0x00132000 (≈664–680K). Values vary by build, so always read the actual table before OTA. [Elektroda, p.kaczmarek2, post #21737515]
How do I handle duplicate or multiple 01PE groups?
De‑duplicate entries and prefer the last valid group in the first 2 MiB window. 4 MB dumps can show repeated entries; sorting and deduping by address/name normalizes the output before use. [Elektroda, divadiow, post #21734412]
Could OTA fail even if I flashed the app?
Yes. OpenBeken writes OTA to a fixed offset; if the bootloader checks another offset, OTA will fail. Read the partition table first or flash a bootloader aligned with OBK’s OTA expectations (e.g., QIO release). [Elektroda, divadiow, post #21734412]
What CRC16 parameters are used when validating 34‑byte records?
Use CRC16 with polynomial 0x8005 and initial value 0xFFFF over each 32‑byte data block; the following 2 bytes store the CRC (little‑endian). Validating avoids blindly stripping bytes from unrelated data. [Elektroda, p.kaczmarek2, post #21737854]
Why does CRC checking stop working part‑way through my dump?
Not all regions use the 32+2 CRC scheme. During checks, validation can start failing (example: at offset 57,528), so switch to raw parsing or limit the CRC‑aware window to the confirmed region. [Elektroda, p.kaczmarek2, post #21737860]
Can OBK use partition scanning to pick a safe LFS/OTA offset automatically?
Yes, that’s the idea behind the BKPartitions work. OBK can scan 01PE, validate lengths, and pick offsets to reduce user error on non‑standard layouts. It’s already printing partitions from live devices. [Elektroda, p.kaczmarek2, post #21737153]
What’s special about the Uascent bootloader OTA address?
“If I remember it correctly, Uascent bootloader OTA address is 0x147000.” Using that address risks overwriting LFS and RF/config partitions unless the layout matches. Adjust tools or replace the bootloader. [Elektroda, insmod, post #21737549]
How do I quickly run the extraction on Windows? (3‑step How‑To)
- Run combined_uncrc_extract_run.py to remove CRC and extract the last 01PE group. 2. The script emits _partitions.bin. 3. It launches rt_partition_tool_cli.exe to print partition name/offset/size. [Elektroda, divadiow, post #21735502]
Why search for 01PE instead of reading a constant offset?
Because the table’s location varies across devices and builds. Screenshots show different 01PE offsets even for similar chips, so fixed addresses are unreliable. Searching ensures you use the active table. [Elektroda, divadiow, post #21735714]
Where can I find sample dumps to test my parser?
A public repository of IoT flash dumps is linked from the thread. Use these to validate your extraction and dedup logic across chip variants and sizes. [Elektroda, divadiow, post #21734412]
Is TLV (MAC/RF) detection useful with partition scanning?
Yes. After parsing partitions, TLV detection helps locate MAC, RF, and calibration data so you can preserve and restore them where OpenBeken expects. This is valuable during cross‑SDK migrations. [Elektroda, divadiow, post #21738157]
