We bring the Chinese to mind for 200 rubles, put “Touchwiz”

In continuation of the previous article about “Lumia”. There are backups, there is a full dump, so why not continue modding the device? On the hardware side, there are some interesting projects – for example, screwing on an AUX FM transmitter (there will be a chip like some old Nokia flagships), putting a battery from a tablet for several amperes, soldering a board from a power bank so that you can charge something else from your phone. But hard modding one way or another requires intervention in the design of the device, and since this device is intact, I don’t want to violate its integrity. But I will try to show in detail the porting of the firmware from another similar device to this device! Why is this needed? For example, if you have a device on such a chipset with a brick – with a firmware that has flown off, hanging on the splash screen, and no one has ever laid out the firmware under it. Thus, it can be raised. In addition, zakosy and under ayos, and under WP are very braking in themselves. Putting a “half stock” can significantly speed up the device and extend its life. Interesting? Welcome!

Training

First of all, we need recovery – from under recovery we can connect to adb, and change something without completely rebuilding the system image. Since porting firmware is digging into configs and replacing drivers, completely changing the image is not only a long time, but also harmful to the NAND flash drive. We take CWM recovery from some device on a similar chipset, I took it from Fly IQ238 (the only difference is that the fly has ext2, and I have yaffs2) and it started up without changes. In the case of smartphones on other platforms (for example, mtk nand and mtk emmc – they have slightly different fstab’s) – we take native recovery, unpack using AndImgTool and replace the fstab’s of the donor and native. We collect the same AndImgTool back, and flash it with our native flasher (researchdownload):

Now we write adb devices.

Excellent! In the case of the sc6820, you need to mount /system/ to access the shell. To do this, go to mounts & storage, and poke mount / system /. Now the shell should work. Root is not needed, cwm mounts the partition as rw (you can read and write). However, there is another nuance! We disassemble the native boot.img with the same AndImgTool, open the build prop and set ro.debuggabe 1, ro.secure 0 and rebuild back. We sew the finished archive onto the device – now you have adb even at the boot stage, for example, if the touch does not work and you can’t activate adb from the settings.

We put the adb plugin for the total commander, sew up the desired firmware and go to patch it. Launched? Okay, so the system image is also in yaffs2 (or ext2, depending on the platform of your device). It is advisable to make wipes.

We fix jambs

Oops, is the display upside down? What a shame, go to build.prop, and change hwrotation to 0 (or 180), and send the device to reboot:

If everything looks too bold, it means that the donor firmware has a different display resolution, respectively, and a different dpi, especially for that device. We change dpi (lcd_density) to the one that was in stock, and then adjust it to the ideal.

Oops, and I don’t have a touchscreen. I understood how the firewood loading mechanism works in Spreadtrum devices, however, part of the firewood is still tightly linked to the kernel – this is the display driver (s) (there can be several supported displays in one firmware), cameras, and the power controller driver. Without a gearbox driver, charging does not go on, and the device hangs at 0% (that is, it turns off immediately without charging). On Spreadtrum devices, the kernel modules are in /system/sps, and the symlinks of some are thrown into lib/modules. All this is loaded into init.sp8800.3rdparty.inc (in boot.img). What to do if there is no touchscreen? We copy the entire sps native folder with a replacement, if necessary, you can throw symlinks (or just copy again) modules to lib/hw/. Sound, wifi, bt, radio module – all this will be picked up automatically, as it is compatible between devices.

Reloaded – wow! The touchscreen worked. Taxi, it seems to be good, but something is missing. So maybe if we have root access, we can immediately drop su and put superuser?

If suddenly your device does not see the battery, then you need to transplant your kernel into the donor boot.img. To do this, we replace the zImage from the original to the donor, and in the donor 3rdparty.rc we change the path to load your touchscreen driver (or if you are too lazy to do it, just create a symlink on gt9xx_ts.ko (your touch may be different) in system/lib/modules or sps/, depending on the firmware.You can peep the path in the same 3rdparty.rc). We do the same with default.prop as in the first part of the article. We flash the donor boot, and all the sensors should pick up. Final loading and…

Everything is working! Excellent! It took me ~ 1 hour to port, and half a day yesterday, to analyze what and how it works for spreadrooms. However, this is not just a visual improvement – the firmware from “Samsung” runs noticeably faster, and does not slow down, like its analogue with the WP interface. Thus, it is possible to adapt the firmware for devices on which it is impossible to find native firmware – we are looking for the firmware where the touch works, and where the display works, and we make one of the two! So why send the device to the trash, if you can make use of it?