logo elektroda
logo elektroda
X
logo elektroda

MagicHome RGBW LED Controller: LFS Error in Autoexec.bat on OBK v1.17.777 BL602

AndroidGeek 1245 14
ADVERTISEMENT
  • #1 21323186
    AndroidGeek
    Level 3  
    Posts: 8
    This is my first time posting in this forum so please pardon me if I formatted something incorrectly šŸ˜…
    Basically I have this MagicHome RGBW LED Controller Flashed with OBK version 1.17.777. I am trying to create an autoexec.bat file for LED scheduling purposes. But when I try to create these shows in the logs:
    Error:LFS:LFS media partition position 0x190000 while expected is 0x192000
    I know that LFS is now supported for BL602. Am I doing something wrong? Thanks in advance :) I've attached some images when trying to create bat file.

    Screenshot from a web browser showing a dialog box for creating a new file named autoexec.bat.
    Browser message with IP address 192.168.1.196 indicating an attempt to create an autoexec.bat file.
    File upload interface in a web application.

    AI: Could you please describe the steps you took to create the autoexec.bat file? This will help us understand if there might be an issue in the process.
    Going into the webapp and the Filesystem tab as usual.
    AI: What operating system and tools are you using to work with the MagicHome RGBW LED Controller? This info might help in troubleshooting the error.
    Nothing special, just using the stock OpenBeken Firmware.
  • ADVERTISEMENT
  • #2 21323255
    divadiow
    Level 38  
    Posts: 4879
    Help: 427
    Rate: 868
    hi. is this device recently flashed to OpenBeken? Did you use the OTA exploit method or flash over UART? If UART, what version of BLDevCube did you use?
  • #3 21323309
    AndroidGeek
    Level 3  
    Posts: 8
    >>21323255 I've used the mhflasher android app to flash the controller initially. This app: Link and then just used the OTA function on the web app to update the firmware.
  • #4 21323714
    divadiow
    Level 38  
    Posts: 4879
    Help: 427
    Rate: 868
    I've tested by converting a GRB MagicHome firmware to OBK using mhflasher. The version embedded in mhflasher is Build on Apr 18 2024 07:21:40 version 1.17.551 and although old, is still later than when LFS support was added: https://github.com/openshwprojects/OpenBK7231T_App/pull/1159

    I have am not seeing the same message you see in any logs, but I also cannot create any files, from any method, using the mhflasher OBK version or the latest.

    note the following from that github:

    Code: Text
    Log in, to see the code


    It's possible (probable?) the firmware on your MagicHome had the later partition layout and that's why LFS doesn't work.
  • ADVERTISEMENT
  • #5 21323762
    AndroidGeek
    Level 3  
    Posts: 8
    >>21323714 Is there any option or fix for this yet? Or do I need to compile custom OpenBeken firmware/modify OpenBeken's source code to support the newer layout (0x190000)? I'm not sure how to do that yet :(
  • #6 21323772
    divadiow
    Level 38  
    Posts: 4879
    Help: 427
    Rate: 868
    divadiow wrote:
    the firmware on your MagicHome had the later partition layout and that's why LFS doesn't work


    Having said that, your error log says lfs media partition starts at 0x19000, which is not the 0x1A2000 of the newer layout
  • #7 21323801
    AndroidGeek
    Level 3  
    Posts: 8
    >>21323772 I am not sure how to continue from here. I never tried to flash it via UART and just used the app. Does that mean I need to reflash it with an older version?
  • ADVERTISEMENT
  • Helpful post
    #8 21324171
    divadiow
    Level 38  
    Posts: 4879
    Help: 427
    Rate: 868
    that is an option, assuming 1.4.8 is OK with the flash ID of your particular BL602. You'll need to use 1.4.8 (or modify the partition_cfg_2M.toml file in the latest BLDC to match the older partition layout) to get the layout needed to get LFS support and be able to OTA to future OpenBK releases.

    However, I have been playing with the LFS addresses in src/littlefs/our_lfs.h - https://github.com/openshwprojects/OpenBK7231T_App/pull/1444/files

    Code: Text
    Log in, to see the code


    and my GRB MagicHome test is now able to create an autoexec.bat file with the result of that PR.

    Screenshot of the LittleFS file system editor in the OpenBK application.

    I attach the OTA file for you to try. This does mean you'd lose this function if you OTA upgrade to any general release firmwares
    Attachments:
    • OpenBL602_1444_merge_14ebed0e1e11_OTA.bin.xz.zip (414.47 KB) You must be logged in to download this attachment.
  • #9 21324172
    divadiow
    Level 38  
    Posts: 4879
    Help: 427
    Rate: 868
    I haven't done much testing and I don't know if this is a sound solution without issues, but worth a go

    Added after 4 [minutes]:

    btw the backup I have been testing from is with this from this GRB controller
    WiFi LED controller with QR code on the casing.

    is that what you have?
  • ADVERTISEMENT
  • #10 21324581
    AndroidGeek
    Level 3  
    Posts: 8
    Oh crap šŸ¤¦ā€ā™‚ļø I made a huge mistake. The controller I have is actually a RGBW Magic Home LED Controller

    Does that matter though? I tried the firmware you sent and got these from the logs:

    .file_max=0, .attr_max=0})
    Debug:LFS:lfs_mount -> 0
    Debug:API:LFS write of autoexec.bat len 0
    Debug:LFS:lfs_file_open(0x4201e7ec, 0x4202c8f8, "autoexec.bat", 103)
    Debug:LFS:lfs_file_open -> 0
    Debug:LFS:lfs_file_write(0x4201e7ec, 0x4202c8f8, 0x4202d016, 0)
    Debug:LFS:lfs_file_write -> 0
    Debug:LFS:lfs_file_truncate(0x4201e7ec, 0x4202c8f8, 0)
    Debug:LFS:lfs_file_truncate -> 0
    Debug:LFS:lfs_file_close(0x4201e7ec, 0x4202c8f8)
    Debug:LFS:lfs_file_close -> 0
    Debug:API:0 total bytes written
    Debug:API:GET of api/lfs/
    Debug:API:LFS read of 
    Debug:LFS:lfs_file_open(0x4201e7ec, 0x4202c710, "", 1)
    Debug:LFS:lfs_file_open -> -21
    Debug:API: is a folder
    Debug:LFS:lfs_dir_open(0x4201e7ec, 0x4202c770, "")
    Debug:LFS:lfs_dir_open -> 0
    Debug:API:opened folder  lfs result 0
    Debug:LFS:lfs_dir_read(0x4201e7ec, 0x4202c770, 0x4202bb70)
    Debug:LFS:lfs_dir_read -> 1
    Debug:LFS:lfs_dir_read(0x4201e7ec, 0x4202c770, 0x4202bb70)
    Debug:LFS:lfs_dir_read -> 1
    Debug:LFS:lfs_dir_read(0x4201e7ec, 0x4202c770, 0x4202bb70)
    Debug:LFS:lfs_dir_read -> 1
    Debug:LFS:lfs_dir_read(0x4201e7ec, 0x4202c770, 0x4202bb70)
    Debug:LFS:lfs_dir_read -> 0
    Debug:LFS:lfs_dir_close(0x4201e7ec, 0x4202c770)
    Debug:LFS:lfs_dir_close -> 0


    Do they have different partition layout? (The GRB, RGB and RGBW?) This the one I actually have. Editing the title now 😬

    RGBW Magic Home LED controller with a cable and QR code. LittleFS interface for managing files on a Magic Home LED controller. [/img]
  • #11 21324606
    divadiow
    Level 38  
    Posts: 4879
    Help: 427
    Rate: 868
    AndroidGeek wrote:
    I tried the firmware you sent and got these from the logs

    looks like it has the same media partition start address. your LFS is working it seems.

    Maybe all MagicHome BL602s have this partition layout and you're the first to want LFS after mhflasher OTA exploit, noticing it doesn't work with standard OBK firmware.

    The only thing custom in the PR firmware posted related to the partition addresses, you still configure OBK the same way to work with your specific device.

    out of interest, what script are you going to put in your autoexec?

    Added after 2 [minutes]:

    AndroidGeek wrote:
    Does that matter though?

    no :)

    Added after 1 [hours] 28 [minutes]:

    so if you peer inside the GRB firmware backup I have been testing with and go to where the partition table starts - 0xE000 - you can see the 0x190000 media partition start address is set in there in little-endian32 reverse-byte order.

    Screenshot of a hex editor showing the partition table for MagicHome firmware.

    to see which firmware backups I have (my repo holds a few MagicHome types) that contain the same hex string 6D656469610000000000001900 I added a new search option to my little script (born in here: https://www.elektroda.com/rtvforum/topic4074263.html#21217939) to find that hex in all bin files

    Screenshot of PowerShell commands for searching firmware partitions.

    TLDR: It seems Zengge/MH use a custom partition layout for their devices
  • #12 21324990
    AndroidGeek
    Level 3  
    Posts: 8
    >>21324606
    divadiow wrote:
    you're the first to want LFS after mhflasher OTA exploit, noticing it doesn't work with standard OBK firmware.

    :) And also I have no idea where do I start if I want it to run the latest versions of OBK and support LFS lol. I have no idea what you did, maybe you could send me some guides on how do I implement it on my own? Otherwise, I'm gonna be stuck in this version of yours haha

    divadiow wrote:
    out of interest, what script are you going to put in your autoexec?

    Just some led scheduling; such as setting it to turn on and off at a certain hour of the day, with adjusted brightness every hour. Basically, I'm using the MagicHome controller as a pwm signal sender to one of my DIY ReefLights driver for brightness and scheduling purposes (the driver is manual only hence I used the MagicHome led controller for wifi and the driver operates at 60-100VDC and 0-10VDC dimmer). And just stumbled across this forum and started using OBK :) I am also building a custom android app for it and works perfectly so far. I'm just in the process of adding timers and presets in the app so I will be needing the LFS for some custom scripts the device will run depending on the android app commands.
  • #13 21326241
    AndroidGeek
    Level 3  
    Posts: 8
    divadiow wrote:

    However, I have been playing with the LFS addresses in src/littlefs/our_lfs.h - https://github.com/openshwprojects/OpenBK7231T_App/pull/1444/files

    Code: Text
    Log in, to see the code


    I attach the OTA file for you to try. This does mean you'd lose this function if you OTA upgrade to any general release firmwares


    Ok so after reading the docs and building guide, I managed to build the firmware with lfs modifications. However I got a .bin file in the build_out folder. How do I "convert" this to an OTA file? I want to see if I can use the latest release and just modify the our_lfs.h every update temporarily.
  • #14 21326398
    divadiow
    Level 38  
    Posts: 4879
    Help: 427
    Rate: 868
    ah OK. sounds like you're compiling offline. I've only used the Github code/build/pr way which will result in a zip file that includes the BL602 OTA file with extension .bin.xz.ota

    List of various binary files, including a file with the extension .bin.xz.ota selected in a file manager.

    The start of this way of outlined in step 1 here: https://www.elektroda.com/rtvforum/topic4056286.html

    but basically

    -login to your github
    -fork https://github.com/openshwprojects/OpenBK7231T_App/ main branch
    -edit src/littlefs/our_lfs.h in your fork
    -commit changes
    -create pull request
    -wait for admin to approve
    -download build zip after approval and build run complete
  • #15 21327305
    max4elektroda
    Level 24  
    Posts: 746
    Help: 48
    Rate: 184
    When building locally I usually use the docker way to run the builds. The OTA files are then present with every build.
    See here https://github.com/openshwprojects/OpenBK7231T_App/tree/main/docker
    Actually you will need to comment out the last "remote" on the line 34 like this in "Makefile"
    	git submodule update --init --recursive #--remote

    to make docker run.

    If using online builds you don't even need to do a pull request, if allowing workflows in your local repository as shown here
    https://www.elektroda.com/rtvforum/topic4082682.html#21275413
    in the "Actions" tab of your new repository, the builds are done in your branch, too.

Topic summary

✨ The discussion revolves around issues faced while creating an autoexec.bat file for scheduling on a MagicHome RGBW LED Controller flashed with OpenBeken (OBK) version 1.17.777. The user encounters an error related to the LFS media partition, indicating a mismatch in expected partition positions. Various users provide insights into flashing methods, firmware versions, and partition layouts, suggesting that the user may need to revert to an older firmware version (1.4.8) or modify the partition configuration to resolve the issue. A successful workaround is shared, involving adjustments to the LFS addresses in the firmware, allowing the creation of the autoexec.bat file. The user also expresses interest in building a custom Android app for LED scheduling and seeks guidance on compiling firmware with LFS support.
Generated by the language model.

FAQ

TL;DR: LFS fails due to a partition-layout mismatch; a 64KB shift changed addresses. ā€œIf layout is not as expected, little fs won’t work.ā€ Fix by editing our_lfs.h to 0x190000 or reflashing to the 1.4.8 layout. For MagicHome BL602 on OBK v1.17.x seeing 0x190000 vs 0x192000. [Elektroda, divadiow, post #21323714]

Why it matters: This FAQ helps MagicHome BL602 + OpenBeken users fix LFS so timers, scripts, and presets persist without surprises.

Quick Facts

Why do I get ā€œLFS media partition position 0x190000 while expected is 0x192000ā€?

Your device uses a different partition layout. OBK’s LFS expects 0x192000 from BLDevCube 1.4.8, but MagicHome images often place media at 0x190000. BLDevCube 1.8.9 also shifted sizes by 64KB, reinforcing the mismatch. OBK blocks LFS when addresses don’t match to avoid corruption. Update the LFS start or reflash to a matching layout. [Elektroda, divadiow, post #21323714]

What’s the fastest fix without UART flashing?

Install a custom OBK that sets LFS_BLOCKS_START (and MIN) to 0x190000 in src/littlefs/our_lfs.h, then OTA it. This aligns OBK’s LFS with your MagicHome layout, enabling autoexec.bat and file writes. Note that stock OTA updates will overwrite this fix unless rebuilt each time. [Elektroda, divadiow, post #21324171]

Will LFS keep working after I OTA to general OpenBeken releases?

No. A stock release will restore standard LFS addresses, and your 0x190000 layout will fail again. To keep LFS without custom builds, reflash the device to the older 1.4.8-style layout so stock OBK and LFS agree on addresses. [Elektroda, divadiow, post #21324171]

Do RGB, GRB, and RGBW MagicHome BL602 controllers use different layouts?

They appear to share a Zengge/MagicHome custom layout with media at 0x190000. Color variant does not change the BL602 partitioning. ā€œIt seems Zengge/MH use a custom partition layout.ā€ Use the LFS 0x190000 fix or reflash to the standard layout. [Elektroda, divadiow, post #21324606]

How do I build a custom OBK OTA with the LFS 0x190000 fix?

  1. Fork OpenBK7231T_App on GitHub and edit src/littlefs/our_lfs.h to set 0x190000.
  2. Commit, enable Actions, and trigger a build (or open a PR).
  3. Download the artifact ZIP; use the .bin.xz.ota file to update your device. [Elektroda, divadiow, post #21326398]

I built locally and only see a .bin. How do I generate an OTA file?

Use the Docker build method in the project. Comment out the last ā€œremoteā€ on Makefile line 34, run the Docker build, and collect the produced .bin.xz.ota from build outputs. This works without making a PR. [Elektroda, max4elektroda, post #21327305]

Can I reflash to the standard layout so stock OBK LFS works long-term?

Yes. Flash with BLDevCube 1.4.8 or adjust partition_cfg_2M.toml to the older layout, then flash. Confirm your flash ID is supported. After this, LFS works with stock releases, and you can OTA future OBK firmware safely. [Elektroda, divadiow, post #21324171]

How can I confirm my media partition start address?

  1. Open a firmware backup and locate the partition table around offset 0xE000.
  2. Look for the ASCII ā€œmediaā€ entry, then read the following little‑endian address bytes.
  3. MagicHome examples show 0x190000 there (byte-reversed), confirming the layout. [Elektroda, divadiow, post #21324606]

My logs show LFS mount success, but autoexec.bat writes 0 total bytes. Is LFS working?

Yes, if lfs_mount and file_open return 0, LFS operates. A zero‑byte write usually means you submitted an empty file or payload. Try writing actual content, then refresh the file list. The helper confirmed LFS was working after the address fix. [Elektroda, divadiow, post #21324606]

Does the mhflasher OTA exploit affect LFS compatibility?

Yes. Devices first converted via mhflasher can retain a vendor layout with media at 0x190000. Stock OBK expects different addresses, so LFS fails until you patch LFS start or reflash to the standard layout. This mismatch surfaced once LFS features were used. [Elektroda, divadiow, post #21324606]

Which BLDevCube version should I use if I choose UART flashing?

Use BLDevCube 1.4.8 for the older, OBK-aligned layout. Newer 1.8.9 increased firmware size by 64KB and shifts partitions, causing LFS address mismatches with stock OBK. Align partitions first to restore native LFS support. [Elektroda, divadiow, post #21324171]

What can I store in autoexec.bat on a MagicHome RGBW controller?

Typical uses include LED on/off schedules, hourly brightness adjustments, and presets. One user drives a 0–10V dimmer using PWM from the controller and needs autoexec scripts for timers and presets triggered from an Android app. LFS enables reliable storage for these scripts. [Elektroda, AndroidGeek, post #21324990]

What if LFS still fails even after changes?

Edge case: OBK intentionally disables LFS when the layout differs to prevent damage. ā€œIf layout is not as expected, little fs won’t work.ā€ Your lighting control still runs, but file storage remains unavailable until you realign partitions or use a custom build. [Elektroda, divadiow, post #21323714]

Where do GitHub build artifacts appear, and what file do I flash?

Open your fork’s Actions tab after the workflow completes. Download the artifact ZIP and flash the BL602-specific .bin.xz.ota file via the OBK web updater. This bundle includes everything needed for OTA deployment. [Elektroda, divadiow, post #21326398]
Generated by the language model.
ADVERTISEMENT