This is intended to be a repository for info on the MStar/SigmaStar SoCs and the associated mainling effort.
This will probably never get as big as linux-sunxi so github pages should be more than enough.
Before MStar was bought out by MediaTek the company offered a wide range of SoCs focused at STB and camera applications. Since the company was bought by MediaTek the camera SoC part of the company has been spun out into the fully owned subsidiary called Sigmastar. The camera SoCs that are now marketed by Sigmastar will be the main focus here.
It’s worth noting that the MStar/Sigmastar camera SoCs seem to be derived from the SoCs made by Alpha Imaging Technology which was merged into MStar at some point.
A: The name is a parody of linux-sunxi for Allwinner SoCs. MStar in Chinese is chenxing and the newer SigmaStar name is xingchen.
A: No. There is no relationship between this site and the vendor. This is a “community” (community meaning one fat guy with a multimeter right now) research effort.
A: Yes, they said without an NDA and project in place they cannot help. Signing an NDA would be a bad idea for code that is going mainline.
A: No.
A: Please use github’s dicussion feature for now.
A: Please don’t. Extract the parts that are licensed in a friendly way (i.e. GPLv2 or BSD) and push them onto github or somewhere and link that instead.
The exception to this rule is where the SDK has already been leaked to github. For example there are some copies of the SDKs that seem to have been uploaded by manufacturers that are actually trying to comply with the licenses covering the kernel, u-boot etc and uploaded the entire SDK.
Basically, if someone else leaks their copy of an SDK that’s their problem.
A: Maybe. If they are already easy to download then putting them here for non-profit educational/research purposes should be ok. IANAL but as far as I can tell github is in the US and fair use applies.
Materials that are behind an NDA wall like those in the SDKs might be interesting but most of the information they contain can be worked out from the kernel sources or about stuff contained the proprietary modules we don’t really care about anyways.
For most chips u-boot is loaded by loading the SPL as IPL-CUST from the IPL so that blob is needed. The mercury5 however can boot with the u-boot SPL as the IPL so no blobs are required. Getting the other chips to boot without the vendor IPL is mostly a case of doing the DDR setup in the SPL.
| load u-boot SPL from boot ROM | load u-boot SPL from vendor IPL | load u-boot from SPI NOR | load u-boot from SPI NAND | load u-boot from SD | |
|---|---|---|---|---|---|
| infinity1 | yes | yes | |||
| infinity2m | yes | wip | yes | ||
| infinity3 | yes | yes | |||
| infinity5 | wip | wip | |||
| infinity6 | wip | wip | |||
| infinity6b0 | wip | wip | |||
| mercury5 | yes, SD | yes | yes | yes | |
| pioneer3 |
| boots to shell from initramfs | boots to shell from local storage | full system from local storage with network etc | boots without blobs (no vendor IPL) | smp | |
|---|---|---|---|---|---|
| infinity1 | yes | yes | yes | ||
| infinity2m | yes | yes | yes | ||
| infinity3 | yes | yes | yes | ||
| infinity5 | |||||
| infinity6 | wip | wip | wip | ||
| infinity6b0 | yes | wip | wip | ||
| mercury5 | yes | yes | yes | yes | |
| pioneer3 |
This table is an attempt to collect all of the different part numbers for the different families and the resources that have been found to reverse engineer each of them.
If possible the data codes will have the earliest and latest known date codes so that we can tell roughly when each type of chip was produced.
| family | part | date codes | process size | sample device acquired | boot rom dumped | firmware dumped | SDK acquired | product brief acquired | datasheet acquired |
|---|---|---|---|---|---|---|---|---|---|
| cedric | |||||||||
| mst786 | yes | ||||||||
| infinity1 | yes[0] | ||||||||
| msc313 | 1647B | yes | yes | ||||||
| msc313d | 1638B | ||||||||
| infinity2m | yes | ||||||||
| msr620 | |||||||||
| msr620q | 1717S | ||||||||
| ssr621d | 1945S | yes | yes | yes | |||||
| ssd201 | yes | ||||||||
| ssd202d | yes | ||||||||
| infinity3 | yes[0] | ||||||||
| msc313e | 1744B | yes | yes | yes | yes | ||||
| 1916S | |||||||||
| msc316dc | 1929S | yes | same as msc313e | yes | yes | ||||
| msc316q | yes | ||||||||
| msc318 | yes | ||||||||
| infinity6 | |||||||||
| ssc323 | 1928S | ||||||||
| 1936J | |||||||||
| ssc325 | 1937S | yes | yes | yes | |||||
| ssc333 | 28nm | ||||||||
| ssc333de | 28nm | ||||||||
| infinity6b0 | |||||||||
| ssc335 | 28nm | ||||||||
| ssc336d | 22nm | ||||||||
| ssc336q | 22nm | ||||||||
| ssc337de | 28nm | yes | |||||||
| ssc338q | 22nm | ||||||||
| ssc338g | 22nm | ||||||||
| ssc339g | 22nm | ||||||||
| mercury2 | yes | ||||||||
| msc8328 | 1744 | yes | |||||||
| mercury5 | |||||||||
| ssc8336 | 1915S | yes | yes | ||||||
| ssc8336n | 1918S | yes | yes | yes | |||||
| 1936S | |||||||||
| ssc8339d | 1838A | yes | |||||||
| pioneer3 | |||||||||
| ssd210 | |||||||||
| ssd212 | |||||||||
| misc | |||||||||
| ssa330d | yes | ||||||||
| ssa530g | yes | ||||||||
| ssd222 | yes |
See mainlining
Spotted a chip that isn’t here? Please see adding new chips.
MStar used to make a lot of MIPS based SoCs for STBs. These aren’t that interesting in themselves but the IP blocks used in the MIPS SoCs were carried forward to the later ARM chips so any datasheets that can be found for the MIPS SoCs might help with reverse engineering the current ARM based ones.
IP camera chips with video encoder and camera interface
Probably a replacement for the recording side, has video decoder, framebuffer etc.
SSD202D - Dual Cortex A7 with 128MB of DDR3 in a QFN128
Updated version of the infinity1
Doesn’t seem to exist.
Seems to be a version of the infinity3 that can handle higher resoltion sensors.
Updated version of the infinity3.
These seem to be i6e based on the build tag found in a kernel image for the SSC8629
This seems to be an evolution of the infinity2m chips.
Dash camera SoC.
Dash camera SoC based on the infinity3.
According to the code that is in the wild and SigmaStars page there are some Cortex-A53 based chips.
https://wemp.app/posts/1d5e4d06-dab5-408d-8349-7721957ca66e
Injoinic seem to be the recommended PMIC vendor for these chips. Maybe like the Allwinner/Xpowers relationship?
Silan MEMs accelerometers seem to be used for a lot of the dash cam devices.
See IP.
See ISP.
To get the device tree out of the kernel you can use binwalk + extract-dtb and dtc.
binwalk -e <firmware.bin>
extract-dtb.py <extracted firmware dir><uncompressed kernel blob>
dtc -I dtb -O dts -o out.dts <extracted dtb that looks right>
See wheretobuy