search

openshwprojects / OpenBK7231T_App

Open source firmware (Tasmota/Esphome replacement) for BK7231T, BK7231N, BL2028N, T34, XR809, W800/W801, W600/W601, BL602 and LN882H
https://openbekeniot.github.io/webapp/devicesList.html
1.45k stars 271 forks source link

[Feature Request] Include version and chip family in OTA RBL file #840

Open Cossid opened 1 year ago

Cossid commented 1 year ago

There appear to be 24 bytes from offset 0x1c through 0x33 (24 bytes) in the OTA RBL file where you can set custom version information. Currently on the BK7231 families that is currently being filled in with -o by OpenBeken followed by null bytes (well, one byte is 0x01 instead of 0x00, but doesn't appear like that matters/is important). It would be helpful if useful metadata could be added here. Tuya always included 1.00 and some other garbage bytes here. It would be nice if we could get something like 1.17.130-bk7231t or 1.17.130-bk7231n here for Beken platforms. A version is currently being set in the UG file, but there are not enough unused bytes there to include platform information.

The reason for this request is because Tuya-CloudCutter currently has to rely on file names to protect users from flashing that wrong firmware, but filenames are not reliable (users can rename them). If version/platform metadata were stored in the OTA RBL file, we could verify the actual file contents instead of the filename.

As with any change, if you decide to follow this pattern, verify this doesn't break anything for you. If you decide against, that is fine CloudCutter will always have filename protection, it's just less fool-proof.

openshwprojects commented 1 year ago

Thank you, it seems like a very good idea! I wouldn't say it's a top priority (because if I understand correctly, user would have to willingly rename OpenBK7231T to OpenBK7231N or vice versa to break), but still a good to have feature. I will add to my waiting queue, but I am not sure if I can do this even next week, so if you can, please consider just adding some meaningful format yourself and opening a pull request. Otherwise you'll have to wait a bit for me to get through other issues (both here and on Elektroda).

Cossid commented 1 year ago

I don't even know where it is in your code, I'd suspect in the packaging tool chain, not code. I am perfectly fine with waiting. Naming convention checks are already in place on CloudCutter, and we're now including binaries that meet the correct naming conventions for it to work appropriately, this would just help protect users when they do something outside of what is included by default.