logo elektroda
logo elektroda
X
logo elektroda

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

divadiow 2010 3
ADVERTISEMENT
  • 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 34  
    Offline 
    divadiow wrote 2828 posts with rating 489, helped 254 times. Live in city Bristol. Been with us since 2023 year.
  • ADVERTISEMENT
  • #2 21275413
    max4elektroda
    Level 20  
    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 34  
    nice! even easier!

    thank you
  • #4 21350246
    divadiow
    Level 34  
    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
ADVERTISEMENT