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

divadiow 22 Oct 2024 20:19 3 3567 Cool? (+4)

📢 Listen (AI):

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.

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

-Customize your fork name or stick with the original

-In your fork navigate to the platforms folder then BK7231N

-Click Add file -> Create new file

-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!)

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

-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

-Commit your changes, giving your commit a short meaningful descriptive name

You'll see that your file is created and your main branch is 1 commit ahead of the base repository.

-Navigate back up to BK7231N folder and open the prebuild.sh file

-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

-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

-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

-Once approved, the build will run and if all is well, successfully.

-Review the status of the override script success by expanding Build (platform you made changes to) -> Run make

Example success:

To get to your binaries click one of the blue "Details" links and navigate to the bottom of the "Summary" page

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

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

About Author

divadiow wrote 4870 posts with rating 863 , helped 424 times. Live in city Bristol. Been with us since 2023 year.

Comments

Add a comment

max4elektroda 24 Oct 2024 16:24

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... [Read more]

divadiow 24 Oct 2024 16:30

nice! even easier! thank you [Read more]

divadiow 16 Dec 2024 07:39

this was a bad example. TMGN enablement only requires a change to the main app https://github.com/openshwprojects/OpenBK7231T_App/pull/1469 [Read more]

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.