logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

Beken Flash Dump Partition Info Extraction with RT-Threads Partition Tool - Development Thoughts?

divadiow 1536 49
Best answers

How can I extract partition offsets and lengths from Beken flash dumps by locating the RT-Threads partition table, and is this worth integrating into OBK or Easy Flasher?

You can turn this into a combined workflow that strips Beken CRC bytes, scans the dump for the FAL partition table magic `0x45503130` (`"01PE"`), and then extracts offsets and lengths, but it should validate CRCs and not rely on the current blind `uncrc` script alone [#21735648][#21737854][#21752598] The RT-Threads/Beken table is the `fal_partition` struct from `fal_def.h`, with fields for partition name, flash name, offset, length, and reserved data, so once found the CLI can print usable partition info [#21752598] This looks like a reasonable feature to add to Easy Flasher or OBK, but the thread recommends getting a correct CRC16 path in place first because not all data is CRCed and the existing script does not actually check CRCs [#21737851][#21737854][#21737860] The approach did work on some BK-T and BK-N dumps after fixes, so it is useful for backups and standard layouts [#21737153][#21737515] However, it is not a guaranteed way to infer a safe OTA target on every device; one example said a Uascent bootloader OTA address of `0x147000` would overwrite LFS/RF/config, so dynamic partition scanning may still be needed [#21737549][#21737552] TLV detection was also suggested as an extra check, especially for locating MAC and RF data for restoration [#21738157]
Generated by the language model.
ADVERTISEMENT
Report a violation of the law
Reply | New topic
  • #31 21737582
    divadiow
    Level 38  
    Posts: 4859
    Help: 424
    Rate: 860
    Code: Text
    Log in, to see the code
  • ADVERTISEMENT
  • #32 21737587
    insmod
    Level 31  
    Posts: 1353
    Help: 160
    Rate: 425
    Another
    Attachments:
    • bk7231n_bootloader_enc_crc.bin (62.22 KB) You must be logged in to download this attachment.
  • #33 21737592
    divadiow
    Level 38  
    Posts: 4859
    Help: 424
    Rate: 860
    wait. what. wtf. i've added rbl to 132000 to first booting BL and it's OTAd and OBK boots.

    insmod wrote:
    same binary crc'ed with old encrypt and 0 0 0 0 flags.


    not uascent key?

    Added after 2 [minutes]:

    >>21737587

    Code: Text
    Log in, to see the code


    M_ALT does not boot btw
  • #34 21737596
    insmod
    Level 31  
    Posts: 1353
    Help: 160
    Rate: 425
    >>21737592
    First with encrypt_n with uascent keys, then added partitions and then crc'ed it with zero keys.
    OTA works because i've changed tuya keys to uascent at 0x3c, 16 bytes length in bk7231n_bootloader.bin (not encrypted one).
  • ADVERTISEMENT
  • #35 21737601
    divadiow
    Level 38  
    Posts: 4859
    Help: 424
    Rate: 860
    ooh ok. ok.

    ah, linking to ..?
    insmod wrote:
    Tuya keys are at 0x48-0x57


    I didn't follow that up
  • ADVERTISEMENT
  • #36 21737604
    insmod
    Level 31  
    Posts: 1353
    Help: 160
    Rate: 425
    >>21737601
    Oops, i've changed it at wrong address, 0x48-0x57 is correct.
    If OTA completes, does it boot?
  • #37 21737608
    divadiow
    Level 38  
    Posts: 4859
    Help: 424
    Rate: 860
    insmod wrote:
    If OTA completes, does it boot?


    yes.

    with the BL from here + rbl at 12A000 =

    Code: Text
    Log in, to see the code
  • ADVERTISEMENT
  • #38 21737609
    insmod
    Level 31  
    Posts: 1353
    Help: 160
    Rate: 425
    Here's a fixed one
    Attachments:
    • bk7231n_bootloader_enc_crc.bin (62.22 KB) You must be logged in to download this attachment.
  • #39 21737612
    divadiow
    Level 38  
    Posts: 4859
    Help: 424
    Rate: 860
    insmod wrote:
    Here's a fixed one


    same experience

    Code: Text
    Log in, to see the code
  • #40 21737614
    insmod
    Level 31  
    Posts: 1353
    Help: 160
    Rate: 425
    Does ota work on M/zero keys?
    If not, then here's enc & crc bootloader for M
    Attachments:
    • bk7231n_bootloader_enc_crc.bin (62.22 KB) You must be logged in to download this attachment.
  • Helpful post
    #41 21737626
    divadiow
    Level 38  
    Posts: 4859
    Help: 424
    Rate: 860
    M_ALT does boot on zero-keys BK7231N module. OTA does work

    Code: Text
    Log in, to see the code


    OpenBK7231M_ALT_QIO_1.18.206.bin -> OpenBK7231N_1.18.204.rbl

    old-SDK M QIO does not boot still because of this: https://www.elektroda.com/rtvforum/topic4107851.html#21725511

    PR not submitted for change yet

    These are test devices btw

    Uascent key = blue CB3S from Matter mini switch
    Zero key = white UAM026 from Uascent bulb (yes a Uascent with zero keys)

    Two NiceMCU WB3S_V1 modules on a blue background with yellow labels. Two microcontroller boards on a blue surface, with USB-C ports and wireless modules

    Added after 4 [minutes]:

    >>21737614

    this does not boot on M

    Added after 2 [minutes]:

    UAM026 = BL2028N https://www.elektroda.com/rtvforum/topic4111089.html#21477454
  • Helpful post
    #42 21737638
    insmod
    Level 31  
    Posts: 1353
    Help: 160
    Rate: 425
    >>21737626
    Strange, but doesn't matter then.
    Attached uascent-encrypted non-crc bootloader for beken_packager.
    Attachments:
    • bk7231n_bootloader_uascent_enc.bin (58.55 KB) You must be logged in to download this attachment.
  • #43 21737644
    divadiow
    Level 38  
    Posts: 4859
    Help: 424
    Rate: 860
    Ok cool. We'll feed that into the build for the uascent section and can finally, hopefully, release Uascent QIO in the BK7231N zip?

    Added after 1 [hours] 51 [minutes]:

    I'll give that a go. I should be almost there a with a branch only 10 days ago I think.

    @p.kaczmarek2 partition detection is still a useful thing in itself though? This doesn't affect that adventure?

    I can imagine using partition detection on backups mostly, but maybe it'd be useful for when a user reports OTA not working and they've flashed app, but not QIO, maybe to a BK7238 or a non-Tuya BK-T?
  • #44 21737851
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14416
    Help: 650
    Rate: 12371
    I think I can add it to Easy Flasher as well. Still, first I want to verify the CRC - do you have a correct CRC16 implementation for that at hand?
    Helpful post? Buy me a coffee.
  • #45 21737853
    divadiow
    Level 38  
    Posts: 4859
    Help: 424
    Rate: 860
    well, the uncrc.py I've been using to date appears to have worked without issues on the many dumps I've played with this past week. Does that provide enough info/confirmation of what you require?

    Code: Python
    Log in, to see the code
  • #46 21737854
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14416
    Help: 650
    Rate: 12371
    nevermind, i got it
    C code verifying CRC and copying data, with memmove() line highlighted.

    Added after 1 [minutes]:

    Your uncrc does not actually check the CRC. So you can run it with any data and it will work blindly.

    You should rather code:
    Code: C / C++
    Log in, to see the code
    Helpful post? Buy me a coffee.
  • #47 21737858
    divadiow
    Level 38  
    Posts: 4859
    Help: 424
    Rate: 860
    ah ok ok. cool. cheers.
  • #48 21737860
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14416
    Help: 650
    Rate: 12371
    Also ,it seems that not all data is CRCed. For me this check begins to fail at 57528 offset.
    Helpful post? Buy me a coffee.
  • #49 21738157
    divadiow
    Level 38  
    Posts: 4859
    Help: 424
    Rate: 860
    oh?

    Also, TLV detection is useful, especially if using, for example, M QIO but then not knowing where the mac and RF is for restoration to the offset OBK expects it to be.
  • #50 21752598
    Apache02
    Level 7  
    Posts: 3
    Help: 1
    Rate: 3
    https://github.com/Apache02/bk7252-cam/blob/main/tools/uncrc
    https://github.com/Apache02/bk7252-cam/blob/main/tools/crc


    Why do you talking about TLV, OTA and other staff when can simply flash app partition?

    Structure of partitions table described in https://github.com/YangAlex66/bdk_rtt/blob/release/v3.0/packages/fal/inc/fal_def.h
    Code: text Expand Select all Copy to clipboard
    struct fal_partition
{
    uint32_t magic_word;

    /* partition name */
    char name[FAL_DEV_NAME_MAX];
    /* flash device name for partition */
    char flash_name[FAL_DEV_NAME_MAX];

    /* partition offset address on flash device */
    long offset;
    size_t len;

    uint32_t reserved;
};


    Quote:
    starting "01PE"

    is uint32_t magic_word which equals to FAL_PART_MAGIC_WROD which equals to 0x45503130


    My example of fal partitions table detection:
    https://github.com/Apache02/bk7252-cam/blob/m...c/shell/shell_commands_beken/commands/fal.cpp
Reply | New topic
Report a violation of the law

Topic summary

✨ The discussion focuses on extracting Beken flash dump partition information using the RT-Threads Partition Tool to facilitate OpenBK* firmware conversions and enable OTA updates. The main challenge is identifying partition offsets and lengths, particularly the "01PE" partition table signature, which varies in location and requires handling little-endian reverse byte order and CRC16 checksums embedded every 34 bytes. A combined Python script (combined_uncrc_extract_run.py) was developed to remove CRC16 checksums and extract partition tables from firmware dumps, followed by using the RT-Thread partition tool CLI to parse and display partition layouts. The tool supports different partition table formats (fal64 and fal48) and outputs partition names, flash types, addresses, and sizes. Attempts to integrate partition detection directly into OpenBK firmware were discussed, including scanning flash memory for "01PE" signatures and skipping CRCs. The conversation also covers challenges with bootloader compatibility, encryption, and CRC validation, especially for Uascent and Tuya bootloaders on BK7231N and BK7231T chips. Testing showed that OTA functionality depends on correct partition offsets and bootloader keys, with some success in creating replacement bootloaders that support OTA on non-standard layouts. The importance of TLV detection for MAC and RF data restoration was noted. Suggestions include adding partition detection to flashing tools like Easy Flasher and improving CRC16 verification in scripts. Overall, the approach aids in troubleshooting OTA failures by accurately identifying partition layouts and offsets in Beken-based devices.
Generated by the language model.
Today's popular

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

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)

  1. 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]
Generated by the language model.
ADVERTISEMENT