Documentation on firmware file formats, and A12 modifications?

[Entropy512]

I'm trying to poke at one of my cameras, a Xiaomi Mi Sphere 360 - also sold under the brand name "MAdventure". It uses an Ambarella A12S with a Xilinx Spartan-6 FPGA hung off of it to do ???? (I suspect that while the A12S does support two sensors, perhaps Xiaomi/MADV found a need to have some additional translation or multiplexing logic.

There seems to be a lot of documentation on A7/A9 "typical" firmware files, with one of the better examples being https://github.com/digdat0/phantom-f.../amba_fwpak.py - but there's little to no information on what changes to the format might be present for A12S units that I can find. Is there any documentation on A12S firmware file formats anywhere? For someone versed in Ambarella firmware file formats, do the firmwares at http://ez-team.com/xiaomi.html look familiar in structure? Looking at firmware in ghex and comparing to that DJI unpacker's documentation, my firmware file MIGHT be a somewhat similar structure IF Xiaomi were lazy and have a blank model name string in the header. The file starts with 36 bytes of zeros (32 characters zero+padded plus a uint32 version number of 0 would be consistent with this), followed by a uint32 that I'm guessing is the CRC. However there are enough differences that amba_fwpak does NOT like operating on the file.

For the most recent firmware listed on the page above, http://ez-team.com/xiaomi/firmware/1...15.5.18497.zip - a UBIFS filesystem can be extracted that is about 23MB in size. What I'm looking to change MIGHT reside in here, however since it seems like Ambarella firmware images perform a CRC, I'd need a proper repacker in order to make modifications to this UBIFS partition (such as enabling telnet without an autoexec.ash script such as https://github.com/sybond/MiSphere-hack

Right now my hopes for things that might be achievable:
1) Replace the broken DNG ColorMatrix1 entries with a color matrix that doesn't suck, so people don't constantly have to grab my DCP profile from the Mi Sphere Facebook group
1a) Stretch goal - instead of just replacing ColorMatrix1, embed all relevant color profile tags in the metadata
2) Increase the delay between shots when bracketing so that bracketing and DNG raw can be used together
3) Drop the preview livestream bitrate as low as possible so the camera can be used in noisy WLAN environments without crashing. (If the preview stream backs up, the camera hangs.)

[nutsey]

Hi,

1) How does the default matrix look like?
2) I believe it can be done with a script.
3) Bitrate values are usually stored in Primary partitions not Linux (UBI).

[Entropy512]

Hi,

1) How does the default matrix look like?
2) I believe it can be done with a script.
3) Bitrate values are usually stored in Primary partitions not Linux (UBI).

1) Very poor - the colors are very flat and in some cases way off. Some examples are in https://sites.google.com/view/h360/misphere-converter - further examples are in https://www.facebook.com/groups/Miji...7567378638382/ (which uses the full dual-illuminant DCP profile I generated). This only is affecting the DNG metadata. The camera's ISP pipeline is properly adjusted, JPEGs are generated using an appropriate color matrix. This issue is pretty easy to work around, but it would be nice to not have to always have the workarounds present on your PC and fix the metadata itself.

2) That would be highly useful. Right now DNG bracketing has two issues - first is that the WLAN remote control app doesn't allow those options to be selected together. Second is that if using an alternative control mechanism such as pysphere ( https://github.com/rnbguy/pysphere ) - the firmware crashes because it tries to capture the second image before the first one has been saved to SD.

3) Not surprising. It would be nice to figure out how to unpack this partition for analysis and potential repacking.