[X]Assistant

[kostyamat]

This topic assumes the exchange of experience on porting Android / Linux based firmware for devices based on Intel Bay-Trail / Cherry-Trail SoC.

Instruments, examples and porting methods will be considered, mainly using a PC running Windows. Linux methods and tools are also welcome.
The topic is not intended to be an Encyclopedia. Any work on reading third-party resources and pulling a grain of knowledge on this topic will be encouraged by me personally by raising my reputation, BECAUSE ALL USERS HAVE A CONSCIENCE. ;)

Due to the fact that, as practice has shown, almost all devices based on this SoC use a similar disk partitioning structure and a similar firmware structure, it is assumed that romodels will exchange ideas and tips on this topic and not on the themes of their devices. What should dramatically improve the efficiency and speed of porting.

Since not all the devices are exactly the same, it is assumed that users using materials from this topic in their developments have a level of understanding of the subject matter much higher than average. From which it follows that no one can ever make any claims and accusations to the authors of the developments on this topic. Everything you do, you do at your own peril and risk.

Related Links

Instructions for running MIUI version 7 (Android 5.1) on devices with Intel Atom x5 Z8xxxx (Cherry Trail) processor - Addition
Tool for disassembling / assembling firmware and individual images
Image Processing under Windows
ANDROID IMG REPACK TOOLS
Editing framework-res.apk
Android update-script
Shell scripts for Android
Assembly instructions for ANDROID from sources
http: //forum.xda-devel...owthread.php? t = 2600364

Tools / Instructions for Windows

We work with boot.img (Tool \ instruction)
Port TWRP 2.8.7.0 to baytrail-T.
Disassembly / Assembly / Despair System.img
Deodexing KitKat firmware
Package to build custom firmware for TWRP'recovery.
Backup \ restore UEFI-BIOS firmware from under Android.
Automatic recovery of firmware ROM with UEFI-BIOS, from backup, during the start of Android (init.d & addon.d)
A set of tools for disassembling \ assembling \ desparsing \ sparsing system.imgimgExtractor.7z(1 MB)

NEWAn updated set of tools for disassembling \ assembling \ desparsing \ sparsing \ trimming system.img (now with support for android 5.xx)
http: //www.osforensics...mount-disk-images.htmlA tool for mounting a despair image system in Windows, with Ext2-4 support and the ability to edit the image on the fly.
We add support for NTFS & exFAT, as well as init.d & addon.d in stock firmware 4.4.
Increase the speaker volume. (init.d script)
USB GPS support (init.d)
Turning off verity boot to boot for the Cherry-trail platform
How to make refind work with tachim
Volume-Downloader

Android 5.1 source code for the Cherry-trail platformhttps://yadi.sk/d/lxq0ZdiYqpeXs

Linux profile topic on UEFI32 and Atom processors


The cap will be updated and supplemented. If you already have some groundwork in other or profile topics on the topic of porting / moding firmware, and you want to share them, send links to me inQMS.

Post has been editedvaalf - 28.11.17, 21:38

Reason for editing: Supplement

[Zyomich]

M

Topic moved to subsection "Porting Android OS".

[kostyamat]

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(4.89 MB)


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 being very hardware similar to each other, the devices still have their own characteristics, such as: the difference in touch panels, cameras, gyroscopes, LCD screens, etc. Therefore, more often than not, the core (zImage) from the donor will refuse to work for you, and even if it works, it is possible that the modules, both built into the kernel and external, will not fit your hardware and / or those will not appear. You can slip modules from your core to the donor's core, but most likely they will not work. Since the kernels must be compiled in the same version of the compiler with the same options and have a common kernel API (and it often changes even in minor updates). In short - hardly work.
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 onto reasonthe 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.imgin 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-zImageand rename it as the original.
  
• Go to the folder*****. img-ramdiskdelete folder therelib(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 filesinit. ****. rcon the subject of commandsinsmod(connecting kernel modules). It’s better to use a multi-window editor.Notepad +++by teamSearch. 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-baseand****. img-pagesizeat home and at the donor and rule at the donor "like at home".
  
• We collect, having loadedboot.imgdonor to the utility and pressing the buttonPACK.
  
• 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)

su
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

[kostyamat]

Disassembling \ assembling \ matching the system.img images.
Convenient and fast ways using a PC on Windows

For work you will need:

• A program for mounting images under Windows. Characterized by the fact that it supports most standard disk file systems in R / W mode, including EXT2-4, without external support drivers, with which Windows is not rich. Download the program herehttp: //www.osforensics...mount-disk-images.html
  
• A set of tools and batch files that I gathered here on the forum, as well as "open spaces". DownloadimgExtractor.7z(1 MB)
  Thanks for them you can, and even need, tell the authors:vin2809andAnd_pda.

In the official firmware for our devices, system.img has the format of sparse. Who wants to know more about this format goes into trance andappeals to spirits, we just need to know that only such a format understands the droidboot when flashing the device, and that this format is absolutely not suitable for editing / replacing files. From this, the system.img from the firmware must first be "despairsed".

For this:

• We drag somewhere system.img from the archive with the firmware you need.
  
• Unzip the set of utilities in a folder on a PC disk. It should be noted that all these operations will require a lot of free disk space.
  
• Drag system.img on the batch file called Convert_img.bat.
  
• A new file will appear in the folder with the name new_ext4 _ ****. Img. This is already a "desparsen" image system with ext4 filesystem, it is already possible to work with it.

Let us consider several ways of moding / porting firmware.

Example number 1. You have changed something in the System section of your device and want to share your work with the owners of the same device.

Option One:(I will make a reservation right away that the method is far from ideal, as it imposes several restrictions and is quite laborious)

It is possible that your system will not have a busybox, but it is possible that the dd binary is present discretely, or as part of some other multi-team binary, then you can exclude the busybox from the command. If neither one nor the other is in the system, busybox will have to be thrown into the system. Download fresh herehttp: //www.busybox.net...es/latest/busybox-i586, rename and place in / system / xbin /. If your system somehow managed without this binary, then it is better to continue doing so, so installing it with the --install command should not be done; just throwing it up is useful.It is with the full installation of busybox that we can get a sparse image collector error, which I will talk about later.

In Terminal Emulator, on the device, we drive in this order of commands. (need root access)

su
busybox dd if = / dev / block / platform / intel / by-label / system of = / sdcard / system.img

Or, with the device connected by cable, in the Windows command line, in the ADB console.

adb root
adb shell
busybox dd if = / dev / block / platform / intel / by-label / system of = / sdcard / system.img

As a result, we get the system.img file on the SD card, the image of the system you edited.
This image can be mounted by putting the RW checkbox in the options, in the OSFmount program and you will have another virtual disk in the explorer. It can write, erase, edit files.
For subsequent assembly, enter the virtual disk, right in the explorer, in the address bar, name the drive letter with the mouse and drag it to the batch file called CreateSparseEXT4.bat. A new image will be created, suitable for flashing to the device using droidboot.

We will dwell on the ways of flashing modified firmware into your device later, and now I want to describe several fixes of problems that may arise at the stage of assembling a SPARSE image.


And then I got tired of writing: D To be continued .... Do not switch.

Post has been editedkostyamat - 09.11.15, 21:56

[kostyamat]

Porting TWRP v.2.8.7.0 to tablets

Before we start porting, we need TWRP itself, compiled from source, forumchanjemmini(clickable, + in the author's reputation) for the tabletCube i7 remix(there you can read about him)
TWRP from that theme supports landscape mode, and uses the skin of 1920x1080. He is likely, without changes, will work on most intel-boxes.
Possible nuances are connected only with the fact that you may have to change the name of the block devices of the eMMC sections in the /etc/recovery.fstab file in accordance with the partition table of your device.

Due to the fact that the Intel platform, instead of the name of block devices, such as / dev / block / mmcblk0p *, uses mount by partition name, like / dev / block / platform / intel / by-label / ****, and TWRP wants / dev / block / mmcblk0p *, this complicates life a little.

To simplify life, I suggest using the ROOT Explorer program (available on the forum), follow the path / dev / block / platform / intel / by-label / and look at which block device each section refers to. Or using the command in the terminal:

su
ls -l / dev / block / platform / intel / by label>/sdcard/partitions.txt

You will receive a file /sdcard/partitions.txt, in which you can see which block devices each section refers to.

So, proceed to porting:

• Disassemble your original boot.img (how to do this is described in two posts above)
  
• Disassemble recovery.img from the installer you downloaded from the original post of the author (link to the post above)
  
• We transfer the kernel and modules as described in the two posts above.
  
• Rules, if necessary, /etc/recovery.fstab
  
• If you want to be able to backup the ESP partition (it’s important if you are sewing factory firmware including ESP.img. Your previous backup may not start with the new bootloader.), Replace the line/ ESP vfat / dev / block / mmcblk0p1 length = 0on/ ESP vfat / dev / block / mmcblk0p1 flags = display = "ESP"; backup = 1 length = 0
  
• Copy the ueventd.modules.blacklist file from the unpacking of your boot to the unpacking recovery
  
• Do not forget to edit the "how are you" files ****. Img-base and ****. Img-pagesize
  
• Collect recovery.
  
• Use the batch file from the downloaded package for TWRP firmware to the device.

You may have problems with the image - stretched, flattened, wrong colors.
The solution is to replace the default skin in the / twres folder with one that supports the orientation and resolution of your screen.
For portrait mode and resolution from 800x1280 to 1080x1920, this universal skin is more or less suitable.twres.7z(705.37 KB)
I used itfor your port on Chuwi Vi8.
For the landscape mode, the skin, originally laid by the author, is quite suitable; it is also quite versatile.

If you managed to find good skins, under different resolutions - unsubscribe in this thread, and / or send me links in a personal, I will add to this post.

You can use the package install-ROM.zip, which I have specially prepared for this, to flash custom firmware. Read more here.

File Explorer Aroma for TWRP.

Enjoy porting. ;)

Post has been editedkostyamat - 05.04.16, 03:40

[jemmini]

[email protected], 00:52

Reserve, for example, porting Recovery (CWM, TWRP)

Cube i7 Remix - Discussion (Post by jemmini # 44312325)

[Beholder]

For chuwi hi8, which donor firmware with lolipop is better to take? I want to try to dig. Perc 3736F

[Lomaster_Serg]

Beholder @ 11/15/2015, 19:25

In the official firmware for our devices, system.img has the format of sparse. Who wants to know more about this format, enters into a trance and addresses the spirits, we only need to know that only such a format understands the droidboot when flashing the device, and that this format is absolutely not suitable for editing / replacing files. From this, the system.img from the firmware must first be "despairsed".

good day! Only today I noticed this topic on the forum, before that I spent 3 evenings to find the whole kitchen to work with the images of my CUWI VI10. dance with a tambourine:make_ext4fs_new.rar(946.43 KB)
I myself have been using this prog myself for a week already. without labor I ported and adapted remixos with it
I analyze the images of the system with these:ImgExtractor_1_3_7.rar(79.92 KB)

And I take the boot and rekoveri and collect it with these:AndImgTool_1_3_0.rar(198.91 KB)


Post has been editedserg2327 - 01.01.16, 20:53

[Allegator]

[email protected], 19:42

good day! Only today I noticed this topic on the forum,

and if I had read it, they would have seen that all these tools are already there!

[Lomaster_Serg]

[email protected], 20:09

and if I had read it, they would have seen that all these tools are already there!

Well, yes .., now I noticed, when I downloaded the archive and looked in .. but I still didn’t understand a little point about:

Kostyamat @ 11/04/2015, 23:31

system.img from the firmware, you must first "desparsit"

I never "desparsil" anything, I sorted it out a dozen times, edited it and then collected through the "CreateSparseEXT4.bat" batch file and everything works
I understand that you need to despair before mounting the image of the prog from the cap? By the way, I got one question for a local guru, when editing files in an image through this program and subsequent collection, the image remains the same length as before the manipulations?
Because I ran into a small problem when unpacking / editing / packing, I cannot create an image of the required length and
This leads to the fact that after the firmware, all the programs do not determine the actual size of the partition, but according to the stitched image and as a result, from under the droid, nothing in the system is ever superfluous. I know the banal solution to this problem, but I would like to find a way to create an image of the required length.
Sorry, maybe I’m writing something funny, I just don’t have much experience in this ... and I would like to receive advice on this issue.

And by the way, to work with the bootloaders, I laid out a completely different program

Post has been editedserg2327 - 02.01.16, 10:47

[Lomaster_Serg]

Guys, help with advice, teach how to create an image of the required length on Windows ..! Because of this, I have problems with the implantation of root rights into the firmware!

Post has been editedserg2327 - 03.01.16, 15:42

[_Tori_]

serg2327,
I always did something like this:
- Created an empty file of the right size
- Connect it as a disk image
- Formatted a new virtual disk in the desired file system
Here's a program that can do all this:В® Linux DeployYou can look at the scripts in her working folder.

[l33tn00b]

serg2327,Look for make_ext4fs.exe and use it with it (there is an option to create an image of the partition of the desired length)

[kostyamat]

[email protected], 19:29

I never "desparsil" anything, I sorted it out a dozen times, edited it and then collected through the "CreateSparseEXT4.bat" batch file and everything works
I understand that you need to despair before mounting the image of the prog from the cap? By the way, I got one question for a local guru, when editing files in an image through this program and subsequent collection, the image remains the same length as before the manipulations?

Despair need not only to mount OSFmount. Sparse is not a “clean” image at all, but of the type of archived FS, with the possibility of filling fragments into the device. If you want to mount and edit it, you must first turn it into a normal dd-image, and in order to upload it to the device via the droidboot, you will again turn it into a sparse-image.

[email protected], 19:29

Because I ran into a small problem when unpacking / editing / packing, I cannot create an image of the required length and
This leads to the fact that after the firmware, all the programs do not determine the actual size of the partition, but according to the stitched image and as a result, from under the droid, nothing in the system is ever superfluous. I know the banal solution to this problem, but I would like to find a way to create an image of the required length.
Sorry, maybe I’m writing something funny, I just don’t have much experience in this ... and I would like to receive advice on this issue.

I have already answered you in PM, but I will also answer here, so that people can understand too.
In the CreateSparseEXT4 batch file, in the line make_ext4fs -s -A Fix.txt -J -l 1031794688% newimage%% 1 system, replace the value 1031794688 with the one you need. This value is the size of your system partition in kilobytes. In this case, 1031794688 = 998MB.
In this line, there is also an option pointing to a certain Fix.txt. In this file, you can enter the values ​​of file permissions that are different from the default ones.

Post has been editedkostyamat - 03.01.16, 23:01

[Lomaster_Serg]

today launched the firmwareLevaon the devicechuwi vi10thanks to some instructions from this topic, but the firmware lacks an inexpensive one,
The wi-fi and bluetooth modules do not work, the screen auto-rotate also does not work and the camera works but sideways! My knowledge of other axes did not help me to solve any of these problems, maybe someone has experience porting firmware on Intel stones? Share your experience, if not difficult, it hurts to bring the firmware to mind!

Post has been editedserg2327 - 06.01.16, 18:16

[kostyamat]

serg2327,
Left from Teklast? If yes, you will not bring to mind, it is verified, and not only by me. It is really hunchbacked at the level of the framework. If you do not burn with the desire to add the necessary pieces, spill. Cameras, touch, gyroscope and other completely solvable.

[Lomaster_Serg]

kostyamat,
Everything would be fine, but I can not fix anything on their stock firmware .. tell me at least about the camera and the gyroscope.

[Beholder]

[email protected], 06:46

Beholder @ 01/08/2016, 21:58
...
He is.
Hmm, I'll try what you describe, thanks. I understand the firmware in / etc / firmware?

Yes, there and not only there. There are a lot of things there that you need to transfer from your firmware. But this is not for this topic. Such things we are here We are discussing the porting of firmware to devices with a baytrail-t Z3735-70 processor.

Tell in details. Another / lib / hw probably, and where else to look?

[kostyamat]

serg2327,
Beholder,

Replace with files from your native firmware in:
/ system / etc / firmware /
/ system / etc / atoisp /
/ system / vendor / firmware /
/ system / usr / idc
/ system / usr / icu
Replace all xml files in / system / etc /

/ lib / hw / no need to touch. It is also desirable not to touch anything without the need of /system/build.prop
One more thing - if your screen resolution is very much lower than that of the donor, you need to change the value of the parameter ro.sf.lcd_density = to a smaller one, preferably native to your device. For example, for Chuwi Vi8, with a screen of 8 "and a resolution of 1280x800, the value 190 is native. Otherwise, you can get a bootlap, when loading, the framework will not be able to boot. There are also funny things, for example, in RemixOS, the native launcher supports only two dpi values , 160 and 320. With other values, it crashes.

Good luck. :)

Posted 10/01/2016 07:23:

Beholder,
On the account of WiFi on the broadcaster, contact Agafonoff, the author of CWM-recovery, to your device. He did this in Remix for Vi8 Ultimate. Call in the topic, let him share his experience, it will be useful for you and other users, even me. ;)
One more thing, you are trying to do firmware 5.0. Keep in mind, the collector of sparse-images, from this topic, does not know how to properly collect images of android 5.0. It turns out not working. Sew through droidboot will not work. Then I will lay out a batch file for firmware via the adb image without sparsing.

Post has been editedkostyamat - 10.01.16, 07:30

[Allegator]

If you port Android 5, everything works except for the screen sensor. Is it really to start?

Post has been editedAllegator - 10.01.16, 18:30

[_Tori_]

Allegator,
What kind of sensor?