logo elektroda
logo elektroda
X
logo elektroda

Demonstration: How to Customize and Build OpenBeken Firmware Directly in Your Browser

divadiow 3564 3

TL;DR

  • A browser-based workflow customizes and builds OpenBeken firmware for BK7231N devices, demonstrated on a Moes Tuya Matter bulb needing a corrected TLV partition address.
  • GitHub overrides place a custom BkDriverFlash.c under platforms/BK7231N, then prebuild.sh is edited to enable the submodule override during build.
  • The key change moves BK_PARTITION_RF_FIRMWARE from 0x1D0000 to 0x1E3000.
  • After committing and opening a pull request, Actions runs the build and the Details pages expose the downloadable binaries.
  • First-time pull requests require administrator approval before the build starts, and the ZIP includes all platform binaries even when only BK7231N changed.
Generated by the language model.
ADVERTISEMENT
📢 Listen (AI):
  • For the most common devices based on platforms supported by OpenBeken, the general firmware releases cater to most users' needs. Occasionally a device comes up that can only be partially made working with the standard firmware. Devices like the TH03 temperature and humidity sensor with segment display driven by a GN6932. To save space, the GN6932 driver was disabled by default.

    For Beken firmwares, and others, enablement of a driver usually requires a change to the SDK, which are in submodules of the main app, in conjunction with a change to code in the main app. This typically requires creating your own fork of the main app and submodule, cloning to your PC, making the required changes to both forks, messing around with Git to get those changes in your submodule fork pushed upstream into the main app so you can eventually open a PR (pull request) to initiate a firmware build.

    Thanks to @max4elektroda the process is a little easier now and can be completed in the browser. The idea was conceived here and later detailed here after release.

    Using this new technique, the process of making a change to the OpenBK7231N submodule code through to downloading your compiled custom binaries will now be demonstrated. This demonstration relates to changes required to get OpenBeken fully working on a Moes Tuya Matter bulb but it serves as a template for the process to follow to make any number of customisations to OpenBeken.



    Anyone wanting to convert their Moes Tuya Matter Beken device to OpenBeken, with the correct TLV partition address set in the build, no longer has to use the older binaries in PR (pull request) 1340 or mess around in the OpenBK7321N submodule, pushing changes upstream to a PR in the main app to start the build workflow. Changes can be made within the main app that are then applied to the submodule at build time.

    PR 1340 required changes to BkDriverFlash.c here https://github.com/openshwprojects/OpenBK7231..._os/beken378/func/user_driver/BkDriverFlash.c

    Create your own custom build on the latest code

    -Register for a GitHub account and login

    -Navigate to https://github.com/openshwprojects/OpenBK7231T_App and create your own fork of the main app
    GitHub interface for the OpenBK7231T_App repository

    -Customize your fork name or stick with the original
    GitHub screen for creating a fork of the OpenBK7231T_App repository.

    -In your fork navigate to the platforms folder then BK7231N

    -Click Add file -> Create new file
    Screenshot showing the GitHub interface on the OpenBK7231T_App page with the Create new file option selected.

    -Type "override/" then the name of each folder of the rest of the submodule path followed by a "/" until you get the empty file to create - "BkDriverFlash.c" in this case.
    Eventually you'll have created this path and file sdk/OpenBK7231N/platforms/bk7231n/bk7231n_os/beken378/func/user_driver/BkDriverFlash.c under OpenBK7231T_App/platforms/BK7231N (Note: I missed the c in "func" in my screenshots - so imagine it's there!)

    Screenshot of a GitHub repository with file editing view.

    -Copy the raw content of the real BkDriverFlash.c from the submodule location into the empty file space just created -
    GitHub editor interface displaying the BkDriverFlash.c file.

    -Make the required changes to the content of the file - in this case we're changing the start address of the BK_PARTITION_RF_FIRMWARE from 0x1D0000 to 0x1E3000
    Code snippet in a GitHub repository with a new partition start address.

    -Commit your changes, giving your commit a short meaningful descriptive name
    Commit changes window on GitHub with message and Commit changes button highlighted.

    You'll see that your file is created and your main branch is 1 commit ahead of the base repository.
    Screenshot of the GitHub repository OpenBK7231T_App showing the BkDriverFlash.c file

    -Navigate back up to BK7231N folder and open the prebuild.sh file
    Screenshot of pre_build.sh file in GitHub repository

    -Edit this file by clicking the pencil icon on the right and then uncomment (remove the "#" from the beginning of) lines 11, 12, 14, 15, 16, 17, 19, 23, 25, 26, 27 and 29 and click "commit changes...". Use default or set custom commit message for this change.

    -navigate to the root of your fork and you'll see you're now 2 commits ahead of the base repo. The "2 commits ahead" link is clickable where you'll see a summary of your changes

    Screenshot of the OpenBK7231T_App GitHub repository showing the main branch view. Screenshot of comparing changes in OpenBK7231T_App code on GitHub.

    -Create a pull request to the base repository. Give it a decent title, description optional, and finally submit the PR with "Create pull request" at the bottom
    Screenshot of a pull request creation form on GitHub for the OpenBK7231T_App project.

    -If this is your first PR then you'll have to wait for the administrator to approve the build. You'll see your PR listed in here https://github.com/openshwprojects/OpenBK7231T_App/pulls and the build paused under Actions https://github.com/openshwprojects/OpenBK7231T_App/actions

    Screenshot showing the GitHub Actions page for the OpenBK7231T_App project.
    Screenshot of a pending GitHub workflow approval.

    -Once approved, the build will run and if all is well, successfully.
    Screenshot from GitHub showing a pull request with all tests successfully passed.

    -Review the status of the override script success by expanding Build (platform you made changes to) -> Run make
    Build screen of the OpenBK7231N project showing the execution steps of the process.

    Example success:
    Code: Text
    Log in, to see the code


    To get to your binaries click one of the blue "Details" links and navigate to the bottom of the "Summary" page
    Screenshot showing a GitHub page with build results for OpenBK7231T_App.

    The zip file will contain all platform binaries even though your changes are only effective in the platform to which a change was made - BK7231N in this case

    Screenshot showing the contents of a ZIP archive with various binary files and disk images.

    Your custom firmware is ready to be OTA or UART flashed to your device.

    Cool? Ranking DIY
    About Author
    divadiow
    Level 38  
    Offline 
    divadiow wrote 4869 posts with rating 863, helped 424 times. Live in city Bristol. Been with us since 2023 year.
  • ADVERTISEMENT
  • #2 21275413
    max4elektroda
    Level 24  
    Posts: 745
    Help: 47
    Rate: 183
    Thanks for your good work to make a more detailed documentation on how to use this feature.

    I hope it's o.k. if I add some more information by showing a different approach on how to do the same change for this firmware with a "simple" sed command.

    I wanted it to make as simple as possible, so you can even use it if you have only limited possibilities to add something to the repository, e.g. if you are using a smartphone w/o a real keyboard.
    In this case I prefer to do as much as possible by copying and avoid text input if ever possible.

    So the first challenge is to get the path to the code file you want to change.
    My proposal is to navigate to this file in the git tree.
    There you use the "copy path" and have it in your clipboard (relative to the SDKs home):
    Screenshot of a GitHub repository for the BkDriverFlash.c file in the OpenBK7231N project.

    platforms/bk7231n/bk7231n_os/beken378/func/user_driver/BkDriverFlash.c


    we only need to prepend the rest of the path from App-directory to the sdk to get the final path:

    sdk/OpenBK7231N/platforms/bk7231n/bk7231n_os/beken378/func/user_driver/BkDriverFlash.c


    Alternatively you can simply copy the path from the browser URL and remove the unneded part.

    While we are here at the location of the file, let's check the line we want to change.
    First use browsers "search" to look for [BK_PARTITION_RF_FIRMWARE]
    (additional information we get: There is only one match, thats good if we e.g. want to change a value that is present multiple times in the file)!


    Inside this code block, we want to do the change:
    
        [BK_PARTITION_RF_FIRMWARE] =
        {
            .partition_owner           = BK_FLASH_EMBEDDED,
            .partition_description     = "RF Firmware",
            .partition_start_addr      = 0x1D0000,// for rf related info
            .partition_length          = 0x1000,
            .partition_options         = PAR_OPT_READ_EN | PAR_OPT_WRITE_DIS,
        },
    

    $$\texttt{ .partition_start_addr = 0x1D0000,}$$

    should be changed to

    $$\texttt{.partition_start_addr = 0x1E3000,}$$

    so a quick second search:

    even the value $$\texttt{ 0x1D0000,}$$ is unique, so we can simply generally change "all" occurrences of
    $$\texttt{ 0x1D0000,}$$ to $$\texttt{ 0x1E3000,}$$ and will not break anything else with only one simple sed line.

    So this is what we have at the moment:

    The path to the file we want to change (we prepended sdk/OpenBK7231N/ to the path we copied):

    sdk/OpenBK7231N/platforms/bk7231n/bk7231n_os/beken378/func/user_driver/BkDriverFlash.c

    we combine this with the sed to a simple script (and add some output, just to check what we have done):

    FILE=sdk/OpenBK7231N/platforms/bk7231n/bk7231n_os/beken378/func/user_driver/BkDriverFlash.c
    # show content before sed
    echo "BK_PARTITION_RF_FIRMWARE before prebuild.sh:"
    grep -A 6 BK_PARTITION_RF_FIRMWARE $FILE
    # do the sed
    sed -i "s/0x1D0000,/0x1E3000,/" $FILE
    # show content after sed
    echo "BK_PARTITION_RF_FIRMWARE after change from prebuild.sh:"
    grep -A 6 BK_PARTITION_RF_FIRMWARE $FILE


    As I said, this is a special case, we know the replacement of all values will only change the single line.
    But in a more general approach we could combine the replacement with a "range" or even a line inside the file to make sure, we only change the value(s) we want to be changed.
    In this case we see the line to change is line 70, so we can use this sed command to only replace this line

    If we don't need the file path several times, we could also combine it to a single line:

    sed -i "70 s/0x1D0000,/0x1E3000,/" sdk/OpenBK7231N/platforms/bk7231n/bk7231n_os/beken378/func/user_driver/BkDriverFlash.c


    This line is the minimum needed in the script to make this approach work, everything else is comment or debug output.

    Now we know what to do to change the file the way we want and can start.

    You need to be signed in to git to do the next steps!

    Navigate to the git URL for OpenBeken:

    https://github.com/openshwprojects/OpenBK7231T_App

    and fork the repository with "+ create a new fork"
    Browser window on GitHub page of OpenBK7231T_App project with an option to create a new fork.

    Assuming this is your first approach, you will need to activate "workflows" once:
    So open "your" fork and as the very first step go to the "Actions" tab.
    If you read:

    "Workflows aren’t being run on this forked repository"

    That's not what we want, since the workflows are exactly what you need to get our (online) build to be done. So allow workflows with the button "I understand my workflows, go ahead and enable them".
    GitHub actions page for a forked repository OpenBK7231T_App_Moes_Matter.

    After that, return to "Code" again - you are ready for your change to the code now.
    To bring the script to work, navigate to the git folder with the pre_build.sh (in platforms/BK7231N):

     https://github.com/<your git name>/<the forks name>/tree/main/platforms/BK7231N/pre_build.sh


    Here use "edit in place":
    Screenshot of the GitHub interface with the pre_build.sh file open.
    You can append the script at the end of the comments (that's easy e.g. on a phone), or simply delete the content and only paste your new script there:

    Screenshot showing an online editor with the pre_build.sh file open in the OpenBK7231T_App_Moes_Matter repository on GitHub.
    And then commit the change you made. Give some additional information, if you like an decide, if you want to create a new branch (e.g. if you later plan to do other changes on the "original" fork) or simply change main branch (let's do this here).
    GitHub commit window with edited script file pre_build.sh.
    That's it, we have done our work. So what now?

    Action(s) is what we want ;-)
    So go to "Actions" again and you should see there is something going on ;-).
    Screenshot of the GitHub Actions panel displaying workflow run information.
    You can click the link of our commit to see some details.

    Now you will need some patience until everything is done, but you can take a look for "your" platform BK7231N, and see, what happened during "make":
    User interface of the OpenBK7231N build process displaying code.

    That looks good, so when everything is done, you can use the resulting "Artifacts" to get the firmware you made.

    Go back to the "Summary" page and find the desired file at the end of the page.
    Summary of actions in the continuous integration process on GitHub
    In the downloaded zip, there is the result of our work, the firmware for BK7231N with changed values!


    Done!
  • ADVERTISEMENT
  • #3 21275420
    divadiow
    Level 38  
    Posts: 4869
    Help: 424
    Rate: 863
    nice! even easier!

    thank you
  • #4 21350246
    divadiow
    Level 38  
    Posts: 4869
    Help: 424
    Rate: 863
    divadiow wrote:
    Occasionally a device comes up that can only be partially made working with the standard firmware. Devices like the TH03 temperature and humidity sensor with segment display driven by a GN6932. To save space, the GN6932 driver was disabled by default.

    this was a bad example. TMGN enablement only requires a change to the main app https://github.com/openshwprojects/OpenBK7231T_App/pull/1469
📢 Listen (AI):

FAQ

TL;DR: This browser-only OpenBeken method cuts the job to 2 commits and one GitHub Actions run; one contributor called the sed variant "even easier". It helps BK7231N users who need a small firmware patch, such as changing BK_PARTITION_RF_FIRMWARE from 0x1D0000 to 0x1E3000, without cloning repos locally. [#21275420]

Why it matters: You can patch OpenBK7231N from a phone or browser, build against current code, and download ready-to-flash binaries without a local SDK setup.

Browser workflow Best for Main edit Input effort Best evidence in logs
Override-file method Larger or reusable patches Copy full BkDriverFlash.c into platforms/BK7231N/override/... Higher PREBUILD: replacing file
sed in prebuild.sh One-line or tiny patches Edit prebuild.sh with a replacement command Lower before/after grep output

Key insight: The critical feature is the prebuild stage. It lets the main app apply a file override or a sed patch to the OpenBK7231N SDK submodule during build time, so you no longer need to push SDK changes upstream just to test a custom binary.

Quick Facts

  • The demonstrated BK7231N patch changes BK_PARTITION_RF_FIRMWARE start address from 0x1D0000 to 0x1E3000, a delta of 0x13000, to suit the Moes Tuya Matter bulb build. [#21273290]
  • In the full override workflow, your fork first becomes 1 commit ahead, then 2 commits ahead after editing prebuild.sh, which gives a quick sanity check before opening a PR. [#21273290]
  • The override-enabled example requires uncommenting 12 lines in platforms/BK7231N/prebuild.sh: 11, 12, 14, 15, 16, 17, 19, 23, 25, 26, 27, 29. [#21273290]
  • The smartphone-friendly method can reduce the actual patch to 1 line: sed -i "70 s/0x1D0000,/0x1E3000,/" .../BkDriverFlash.c, using file line 70 to target the change precisely. [#21275413]

How do I customize and build OpenBeken firmware directly in the browser using a GitHub fork of OpenBK7231T_App?

You fork OpenBK7231T_App, edit the needed files in GitHub, and let GitHub Actions build the firmware online. 1. Create your fork and log in. 2. Add an override file or edit platforms/BK7231N/prebuild.sh, then commit. 3. Open a pull request or trigger Actions, wait for approval if required, and download the artifacts from the workflow summary. The demonstrated flow shows a fork becoming 1 commit ahead, then 2 commits ahead before build. [#21273290]

What is the override mechanism in OpenBK7231T_App, and how does it replace files inside the OpenBK7231N SDK submodule at build time?

The override mechanism lets the main app inject a replacement file into the SDK submodule during the prebuild stage. You create a matching path under platforms/BK7231N/override/..., place the modified file there, and enable the relevant prebuild.sh lines. The build log then shows PREBUILD: replacing file, followed by the original SDK path and the override path, confirming the replacement happened before make compiled OpenBK7231N. [#21273290]

How can I modify BkDriverFlash.c in a browser-only workflow to change BK_PARTITION_RF_FIRMWARE from 0x1D0000 to 0x1E3000 for a BK7231N device?

You can do it entirely in GitHub by copying BkDriverFlash.c into the override path and editing one value. Create platforms/BK7231N/override/sdk/OpenBK7231N/platforms/bk7231n/bk7231n_os/beken378/func/user_driver/BkDriverFlash.c, paste the original file, and change BK_PARTITION_RF_FIRMWARE from 0x1D0000 to 0x1E3000. Commit the file, then enable the override lines in prebuild.sh so the build uses your edited version. [#21273290]

Why did PR 1340 require changing BkDriverFlash.c for the Moes Tuya Matter bulb, and what problem does the new TLV partition address solve?

PR 1340 changed BkDriverFlash.c because the Moes Tuya Matter bulb needed a different TLV-related partition layout than the default build used. The shown fix moves BK_PARTITION_RF_FIRMWARE from 0x1D0000 to 0x1E3000, so users no longer need older PR binaries when building for that device. The thread states this custom TLV partition address can now be set from the main app workflow instead of editing the submodule upstream first. [#21273290]

What do I need to uncomment in platforms/BK7231N/prebuild.sh to enable the file override build process for OpenBeken?

You need to uncomment 12 specific lines in platforms/BK7231N/prebuild.sh. The thread lists lines 11, 12, 14, 15, 16, 17, 19, 23, 25, 26, 27, and 29. Removing the leading # on those lines enables the override-file workflow, after which your fork should show 2 commits ahead if you already committed the replacement BkDriverFlash.c file. [#21273290]

Where do I find the compiled OpenBeken binaries and artifacts after a GitHub Actions build finishes successfully?

You find them at the bottom of the GitHub Actions workflow summary page. Click a blue Details link for the finished run, open the Summary view, and scroll to the artifacts section. The downloaded ZIP contains all platform binaries, even though the demonstrated change only affects BK7231N. You can then use the custom firmware for OTA or UART flashing. [#21273290]

Why is my first pull request build paused in OpenBK7231T_App Actions, and what approval step is required before the workflow runs?

Your first PR build pauses because an administrator must approve it before Actions continues. The thread says first-time pull requests appear in the repository PR list while the build stays paused in Actions. After the approval step, the workflow runs normally and produces artifacts if the build succeeds. This safeguard applies before the custom binaries are generated. [#21273290]

What is BK_PARTITION_RF_FIRMWARE in OpenBeken, and how does its start address affect firmware behavior on Beken devices?

BK_PARTITION_RF_FIRMWARE is a firmware partition entry that stores RF-related information, and its start address must match the device’s required flash layout. In the example block, its description is "RF Firmware", its default start is 0x1D0000, and its length is 0x1000. Changing that start address to 0x1E3000 alters where the firmware expects that RF-related region, which is why the Moes Tuya Matter bulb needed a custom build. [#21275413]

How does the simple sed-based prebuild.sh method compare with the full override-file method for patching OpenBK7231N in the browser?

The sed method is better for tiny edits, while the override-file method is better for larger or reusable patches. The sed approach can work with a single line and minimal typing, which makes it suitable on a smartphone. The override-file path is longer to set up, but it preserves the full edited source file and is easier to review. One contributor described the sed route as "even easier," which fits one-line changes like 0x1D0000 to 0x1E3000. [#21275420]

What is a Git submodule in the context of OpenBK7231T_App and OpenBK7231N, and why did custom driver changes traditionally require edits in both repositories?

"Git submodule" is a repository link that embeds one project inside another, tracking external code without copying its history into the main app. In this thread, OpenBK7231N is the SDK submodule used by OpenBK7231T_App. Traditionally, enabling a driver meant changing the SDK submodule and the main app together, then pushing both so a PR could build the firmware. The new browser workflow avoids that two-repository edit for many cases. [#21273290]

How can I use a sed command inside prebuild.sh to patch a single line in BkDriverFlash.c when working from a smartphone or other limited-input device?

You can patch one exact line by placing a single sed command in prebuild.sh. The demonstrated command is sed -i "70 s/0x1D0000,/0x1E3000,/" sdk/OpenBK7231N/platforms/bk7231n/bk7231n_os/beken378/func/user_driver/BkDriverFlash.c. It targets line 70, which reduces risk when the same value might appear elsewhere. This method was proposed specifically for limited-input devices such as smartphones without a real keyboard. [#21275413]

What should I check in the GitHub Actions logs to confirm that the OpenBeken prebuild override script actually replaced the intended SDK file?

Check the Build (platform you made changes to) job and expand Run make. A successful override shows prebuild found for OpenBK7231N, PREBUILD script!, and PREBUILD: replacing file, followed by both the original SDK path and the override path. If you use the sed method, verify the before-and-after grep output around BK_PARTITION_RF_FIRMWARE instead. Those log lines prove the patch ran before compilation. [#21273290]

Which browser-only workflow is best for making small OpenBeken firmware patches on BK7231N: editing an override file or editing prebuild.sh with sed?

Editing prebuild.sh with sed is best for small BK7231N patches. It can shrink the change to 1 command, works well on a phone, and avoids copying a full source file into an override tree. Use the override-file method when you need multiple edits, easier diff review, or a reusable replacement file. For a single address swap on line 70 of BkDriverFlash.c, sed is the faster option. [#21275413]

Why was the TH03 GN6932 example later described as a bad example, and how is TMGN enablement handled in newer OpenBeken changes?

It was called a bad example because that case no longer needed SDK-submodule patching. A later post says TMGN enablement only requires a change in the main app, not the earlier submodule-heavy workflow that the TH03 example implied. The correction points readers to main-app pull request 1469, which means the older example overstated the need for dual-repository customization in that specific case. [#21350246]

What troubleshooting steps help when an OpenBeken custom browser build succeeds but the expected BK7231N-specific change does not appear in the final firmware?

First, verify the patch actually ran for BK7231N, not just the overall workflow. Check that prebuild.sh was enabled, the override path exactly matches the SDK path, and the log shows either PREBUILD: replacing file or the expected grep before-and-after output. Also confirm you downloaded the correct artifact, because the ZIP contains all platform binaries even when only BK7231N changed. A successful build can still miss your edit if the path, line target, or commented lines are wrong. [#21273290]
Generated by the language model.
ADVERTISEMENT