Parse \ edit \ build boot.img
Boot.img is an android boot partition image and includes a kernel (zImage - a packed kernel image) + InitRamDisk (some pseudo-disk located in the main memory of the device, including: initial folder tree, start scripts, some binaries, kernel modules, etc. )
To disassemble boot.img we will use this utility.unpack_repack_boot.7z
The utility is very easy to use and does not need a separate review - open the boot.img program and press the unpack button. IвЂ™ll note that in order to correctly assemble your boot.img back, you need to open your original boot.img in the program again and press - pack. As a result, you will receive a new file with the same name + date / time of creation.
Consider an example based on porting a boot from another donor device, for subsequent collaboration with the donor system.
It should be borne in mind that the hardware being very similar to each other, the devices still have their own characteristics, such as: the difference in the touch panels, cameras, gyroscopes, LSD screens, etc. Therefore, most often, the kernel (zImage) from a donor you will refuse to work, and even if it is working, it is possible modules is embedded in the core and external, are not suitable to your hardware and \ or those simply will not appear. Tuck-ins from its core nucleus donor can be, but most likely they will not work. Since the kernel must be skompelirovany in one version of the same compiler options and have a common kernel API (and it often varies even in minor updates). In short - it is unlikely to succeed.
I want to note that the android kernel, being a Linux kernel, still has significant differences. ItвЂ™s like a Linux kernel wrapped in a вЂњshellвЂќ using the android version of the API. Therefore, you will hardly be able to cross already with a hedgehog, that is, the core of say KitKat with System Lollipop. Theoretically, this is possible, but almost just Sisyphean labor.
Another difficulty in porting kernels from the device to the device is the fact that the output to the LCD screen depends on the GOP driver in UEFI and the model of the LCD matrix of a particular device. At the same time, judging by the dmesg output, the donor core correctly determines the resolution and frame rate of the matrix, but alas ... there is no display on the screen. In this case, HDMI output works fine, as a rule. : girl_cray:
From the foregoing: You can port, and even need, your favorite firmware from other brethren on
the processor,But only within the current android for your device, using the native core and modules. But what if you are lucky ?! It is quite possible to find a donor, which is similar in hardware to yours and the core of which fully works on your device, minus trifles, such as: an inverted or "enlarged" touch, inverted cameras or a gyroscope. This suggests that it is possible to work with such a kernel, and those little things and improper operation of the equipment can be corrected by editing / replacing files in the donor's system. So:
- Put the native and donor (renamed)boot.img in the folder to the utility.
- Unpack both images.
- We open folders with the unpacked contents in different windows of the conductor.
- We copy with replacement in unpacking of the donor*****. img-zImage and rename it as the original.
- Go to the folder*****. img-ramdisk delete folder there lib (it contains external kernel modules) and copy in its place the same folder from the decompression of our native boot.
- Then, usingAkelPAD \ Notepad +++ , the standard Notepad cannot be used when editing Linux files, we sequentially review all the files init. ****. rc on the subject of commands insmod (connecting kernel modules). ItвЂ™s better to use a multi-window editor. Notepad +++ by team Search . We verify the files and rule the donor as it is written here.
- We are looking for and check the sections starting withchown system system / sys / bus / i2c / devices , we rule as in the native file, it is very important.
- Copy with replacement, from unpacking a native boot to unpacking a donor, fileueventd.modules.blacklist
- We verify the contents of files****. img-base and ****. img-pagesize at home and at the donor and rule at the donor "like at home".
- We collect, having loadedboot.img donor to the utility and pressing the button PACK .
- New file - you can flash in the tablet.
If you did find a donor whose core displays a picture on your device but the touch does not work:
The reason may lie in the fact that there are no modules (drivers) in the donor's core that are responsible for the operation of your wheelbarrow (trite - the donor has a different chip).
You can check it this way (by checking the result in the /sdcard/drivers.txt files received during the work of the native and donor kernels. The drivers for the tach, loaded from the outside and integrated into the kernel, are in the name _TS or _ts)
ls / sys / bus / i2c / drivers>/sdcard/drivers.txt
If one of the drivers of the wheelbarrow is missing from the donor list, alas, you are not lucky. Throw out of your kernel, the fastest will not work.This is an approximate instruction, it will be supplemented as additional experience is accumulated, both positive and negative. : D Post has been editedkostyamat - 14.01.16, 08:30