[TUTORIAL] Making Flashable ZIPs, EDIFY Script, ZIP Signing & Key Creation [19.01.13]
Recent Updates: Command Line Edify Script Tester, Further 'update-binary' info clarification, helpful links, additional credits. post#1
Hi all,
In the process of creating my [BOOTANIMATIONS - LINKS & INFO] thread I realised I needed to know more about how boot animations worked, as by default people tend to ask questions in that type of thread, so I wanted to be able to help.
This meant I came across the problem of creating flash-able ZIP files and Edify scripting and in the interests of sharing and helping this great community I would like to share what I have found and hopefully learn more through discussion, I certainly am no expert and am always willing to learn.
I have checked xda and various other websites whilst reseraching for this post and there is nothing that really explains all the basic concepts to just get up and running, also a lot of threads are quite old and focus on the old Amend scripting syntax or are a confusing mixture of the two.
I hope this helps people get started and that we can all collaborate to make this a thread a source of valuable information.
Contents:
Post #1: Tutorials
Post #2: Edify Commands
***Please, if there are any mistakes on this thread then let me know what I have done incorrectly in reply to this post and I will update the thread to correct it***
***As always, I accept no responsibiltiy for your handset, you modify it at your own risk, nobody is forcing you...be aware you can seriously bork your phone by flashing its internal partitions! Always make a nandroid back-up and think before you flash!***
***Have you made a nandroid back-up...no? Then make one!!***
You will need the following:
Android SDK, ADB & Fastboot set up for your handset.
Notepad++ [LINK]
7zip [LINK]
Setting up your zip directories:
you will need to create the following folder structure (these are case sensitive):
Code:
/META-INF/com/google/android
All flash-able zips include this file structure, the final folder 'android' will contain two files:
Code:
update-binary
updater-script
update-binary: I have been unable to find much information on the update-binary file other than they seem to be chip set specific (if anyone can shed further light on these I will include it here). For the sake of compatibility I have attached the update binary from the latest CyanogenMod Nightlies for the maguro at the bottom of this thread - You can of course download the latest nightly and extract the update-binary file yourself as the attached one will obviously begin to date (all credit to the great devs at CyanogenMod for this, many thanks).
Update: For more detailed info on the update binary you can find the sources in the bootable/recovery/updater directory at AndroidXRef here: [ xref: /bootable/recovery/updater/ ]. There is also an edify directory which looks like it handles the parsing of the script. Obviously with the sources there's nothing to stop you extending syntax/functionality should you wish given the fact the each zip comes with its own version. It will also help you understand how signature checking is handled.
Update II: For anybody having problems flashing it is worth ensuring you have an up to date version of the update-binary (obviously the one attached to this thread will gradually become out of date).
It is advisable to use the update-binary from the latest OTA image for your device, these images can be found in the following link:
Official Google OTA update URLs - efrant
updater-script: This we can create ourselves, to ensure it works properly we will use Notepad++.
Open Notepad++ and start a new file, with the following settings:
Format: Unix
Encoding: ANSI
Default Language: Normal Text
Save this file as:
File name: updater-script
File type: All types (*.*)
You can now edit this file, add the following text:
Code:
[COLOR="Red"]assert(getprop("ro.product.device") == "maguro" || getprop("ro.build.product") == "maguro");[/COLOR]
[COLOR="Green"]ui_print(" ");[/COLOR]
[COLOR="green"]ui_print("confirming device maguro");[/COLOR]
[COLOR="green"]ui_print(" ");[/COLOR]
[COLOR="green"]ui_print("success");[/COLOR]
[COLOR="green"]ui_print(" ");[/COLOR]
[COLOR="DarkOrange"]show_progress(0.200000, 5);[/COLOR]
[COLOR="green"]ui_print("mounting system");[/COLOR]
[COLOR="red"]mount("ext4", "EMMC", "/dev/block/platform/omap/omap_hsmmc.0/by-name/system", "/system");[/COLOR]
[COLOR="green"]ui_print(" ");[/COLOR]
[COLOR="DarkOrange"]show_progress(0.200000, 5);[/COLOR]
[COLOR="green"]ui_print("updating system files");[/COLOR]
[COLOR="red"]package_extract_dir("system", "/system");[/COLOR]
[COLOR="green"]ui_print(" ");[/COLOR]
[COLOR="DarkOrange"]show_progress(0.200000, 5);[/COLOR]
[COLOR="green"]ui_print("unmounting system");[/COLOR]
[COLOR="red"]unmount("/system");[/COLOR]
[COLOR="green"]ui_print(" ");[/COLOR]
[COLOR="DarkOrange"]show_progress(0.200000, 5);[/COLOR]
[COLOR="green"]ui_print("by yourusername");[/COLOR]
[COLOR="DarkOrange"]show_progress(0.200000, 5);[/COLOR]
[COLOR="green"]ui_print(" ");[/COLOR]
***EMPTY LINE***
Ok, I've colour coded this so we can break it down, the lines of code in RED are the actual commands, everything else is cosmetic.
assert(getprop("ro.product.device") == "maguro" || getprop("ro.build.product") == "maguro"); This is checking you are flashing the correct handset, this is not a requirement, but is best practice. Just insert another device name in the place of "maguro" if you so wish, or remove the command all together.
mount("ext4", "EMMC", "/dev/block/platform/omap/omap_hsmmc.0/by-name/system", "/system"); This is the specific mount point for the maguro system partition, if you wish to flash a different partition, data for instance you can get the mount points for your device by entering the following code over ADB:
Code:
adb shell "mount > /sdcard/PHONENAME_mountinfo.txt"
This will place a text file on your sdcard with the mount points for your specific device (remember to swap 'PHONENAME' with your device name e.g. 'maguro')
package_extract_dir("system", "/system"); This command extracts the files you wish to flash from the zip and flashes them to the phone, it is formatted as follows ("package-path", "/destination-path"). So for this example you are telling it to flash everything from the 'system' folder in your zip to the /system partition of your handset. You can obviously change these values for different partitions.
unmount("/system"); This simply unmounts whatever partition you previously mounted.
ui_print(" "); Shows text in the recovery whilst the flash is ongoing, you can put whatever you please between the speech marks, you must leave a space if you wish to have a blank line.
show_progress(0.200000, 5); Controls what the progress bar in the background is displaying, it is formatted as follows (fragment, seconds).
***EMPTY LINE*** This is not actually text, you simply need to leave a blank line at the end of your script before you save it for it to work.
FYI, this means in fact your script could look like this and still work:
Code:
[COLOR="Green"]ui_print(" ");[/COLOR]
[COLOR="DarkOrange"]show_progress(1.000000, 30);[/COLOR]
[COLOR="red"]mount("ext4", "EMMC", "/dev/block/platform/omap/omap_hsmmc.0/by-name/system", "/system");[/COLOR]
[COLOR="red"]package_extract_dir("system", "/system");[/COLOR]
[COLOR="red"]unmount("/system");[/COLOR]
[COLOR="Green"]ui_print(" ");[/COLOR]
***EMPTY LINE***
But that just isn't that pretty, or as deceptively complicated lol!
Make sure you save your edify script.
Files to flash:
You now need to create a further folder, this needs to be named based on where within the system you are flashing, for the sake of this example we are flashing to the system partition, so:
Code:
/META-INF/com/google/android
/system/app
Place whatever files you wish to flash within this file e.g:
Code:
/META-INF/com/google/android
/system/app/nameofapp.apk
Creating your .zip file:
Select both of your top directories and their contents 'META-INF' and 'system' and package them into a .zip file with 7zip using the following settings:
Archive: name_of_your_file
Archive Format: zip
Compression level: Store
Update mode: Add and replace files
And there you have it, your very own flash-able .zip file.
I have attached an example flashable .zip file that includes this updater-script and the above mentioned CM update-binary.
How to sign your update.zip:
You don't actually need to sign your zip file for it to work as most custom recoveries now support unsigned zips, for aspiring developers and the more cautious among us though, here is how.
You will need to download the following files:
SignApk [LINK]
Java JDK (Java Development Kit) & JRE (Java Runtime Environment) [LINK]
Install Java JRE and JDK and restart your PC.
You then need to create a folder in the root of your c:\ drive named 'signapk' and extract the contents of the SignApk download (signapk.jar, key.pk8, certificate.pem) to this folder.
Place your .zip file into the same folder and then open cmd line. Input the following commands (remeber to change the name of 'myupdate.zip' to the name of your file and 'myupdate-signed.zip' to whatever you want your resulting .zip to be named):
Code:
cd\signapk\
java -jar signapk.jar certificate.pem key.pk8 c:\signapk\myupdate.zip myupdate-signed.zip
You should find that you now have the the following files in your 'META-INF' folder: CERT.RSA, CERT.SF, MANIFEST.MF
This can also to be used to sign .apk files using the below command (same stipulations for file name changing applies as above):
Code:
java -jar signapk.jar certificate.pem key.pk8 c:\signapk\myapplication.apk myapplication-signed.apk
How to create your own private signing key & certificate:
You will need the following download:
OpenSSL [LINK]
The above signapk file includes test keys, if you want to create your own private keys for signing, here's what you need to do.
As before extract the OpenSSL files to a folder in the root of your c:\ drive, preferably named 'openssl' for ease of cmd line navigation. Then input the following:
Code:
cd\openssl\
openssl genrsa -out key.pem 1024
openssl req -new -key key.pem -out request.pem
openssl x509 -req -days 9999 -in request.pem -signkey key.pem -out certificate.pem
openssl pkcs8 -topk8 -outform DER -in key.pem -inform PEM -out key.pk8 -nocrypt
You can then replace 'key.pk8' & 'certificate.pem' with your own files.
I really hope this has helped folks out, if so please consider hitting the 'Thanks' button!
Happy flashing!
Testing your script before you flash:
If you would like to test if your script commands are valid and will run properly on your PC first before you use them on your handset, therefore removing the fear of borking your current install/handset in the process then head to this post:
Command Line Edify Script Tester by: trevd
This great tool developed by trevd currently has the following features:
Validates function name.
Validates function parameter count.
It is available for Linux and Windows, so head over and check it out. Be sure to click trevd's thanks button if you find this useful.
Other helpful links & threads:
xda-developers: Edify script language wiki
Edify scripts in CWM recovery by: NFHimself
Phandroid - Edify Script Language Reference by: Koumajutsu
Introduction to edify updater script by: kurotsugi
Intelligent EDIFY updater-script - (Decides things during flash) by: lotherius
Credits:
CyanogenMod for (update-binary)
Lorenz's Blog for (SignAPK & Info)
JoeSyr for (Help with File Permissions)
efrant for (Help with various commands)
trevd for (further update-binary clarification and source links)
osm0sis for (Helpful info & forum links & help with update-binary info)
Edify Scripting Commands
I would like to try and put together a guide to Edify scripting commands and what their function is to compliment my above tutorial, I hope again we can all collaborate to make this a helpful source of information to all budding devs...we all have to start somewhere right!?
***Please, if there are any mistakes in this post or if you can help by adding further info please post below, thanks***
Ok...
Check you are flashing the correct device:
Code:
assert(getprop("ro.product.device") == "maguro" || getprop("ro.build.product") == "maguro" || getprop("ro.product.board") == "maguro");
This will check your device is showing the correct name in the build.prop, in this case "maguro", you can obviously replace this with your device name.
To explain this a little further, you have told the script to check certain properties within your 'build.prop' file located in your /system folder. The above command ensures the following categories have the correct definitions before proceeding with the flash:
Code:
ro.product.device=
ro.build.product=
ro.product.board=
Here are the main build properties within your build.prop:
Code:
ro.build.id=
ro.build.display.id=
ro.build.version.incremental=
ro.build.version.sdk=
ro.build.version.codename=
ro.build.version.release=
ro.build.date=
ro.build.date.utc=
ro.build.type=
ro.build.user=
ro.build.host=
ro.build.tags=
ro.product.model=
ro.product.brand=
ro.product.name=
ro.product.device=
ro.product.board=
ro.product.cpu.abi=
ro.product.cpu.abi2=
ro.product.manufacturer=
ro.product.locale.language=
ro.product.locale.region=
ro.wifi.channels=
ro.board.platform=
ro.build.description=
ro.build.fingerprint=
ro.build.characteristics=
ro.cm.device=
Print text in the recovery during flashing process:
Code:
ui_print("Your text here");
Code:
ui_print(" ");
This simply prints a line of text in the recovery, it has no actual effect on the flashing process, if you want a blank line just leave a blank space as the second example.
Controlling the progress bar:
I believe I understand this correctly, if not please do post below with further clarification.
Code:
show_progress(0.000000, 0);
or
Code:
set_progress(0.000000);
You have two choices when controlling the progress bar, the first example allows you to define fractions of the progress bar and how long they will take to fill. The second example just allows you to specify that the bar fills to a certain fraction at whatever point during the flashing process.
The command is defined as: (progress bar fraction, duration in seconds to fill defined fraction);
For example the following code lines interspersed with your other commands would fill a fifth of the progress bar every five seconds:
Code:
show_progress(0.200000, 5);
ui_print(" ");
show_progress(0.200000, 5);
ui_print(" ");
show_progress(0.200000, 5);
ui_print(" ");
show_progress(0.200000, 5);
ui_print(" ");
show_progress(0.200000, 5);
This process will only complete if the script takes long enough to flash, therefore you need to be aware of what you are actually flashing and how long it will take when defining these values.
If you wish to just define a fraction without fill without a time scale you can use the following command:
Code:
set_progress(0.000000);
It is also best practice to include this element in your scripts as it will reassure people that their handset hasn't frozen during a flash.
Mount/Unmount a partition:
To mount a partition you need to use the following syntax:
Code:
mount("filesystem-type", "partition-type", "device-specific-location", "mount-point");
filesystem-type: "ext4" or "yaffs2" (maguro is ext4)
partition-type: "EMMC" or "MTD" (maguro is EMMC)
location: Device specific address
mount-point: /system etc
So far I have managed to define the following Maguro specific mount points:
Code:
"/dev/block/platform/omap/omap_hsmmc.0/by-name/system", "/system"
"/dev/block/platform/omap/omap_hsmmc.0/by-name/userdata", "/data"
"/dev/block/platform/omap/omap_hsmmc.0/by-name/cache", "/cache"
"/dev/block/platform/omap/omap_hsmmc.0/by-name/efs" "/factory"
"/dev/block/platform/omap/omap_hsmmc.0/by-name/userdata", "/mnt/sdcard"
"/dev/block/platform/omap/omap_hsmmc.0/by-name/boot"
Example command would be:
Code:
mount("ext4", "EMMC", "/dev/block/platform/omap/omap_hsmmc.0/by-name/system", "/system");
I have taken these mount points from the file output by the maguro when you enter the following adb command:
Code:
adb shell "mount > /sdcard/maguro_mountinfo.txt"
I have to admit I am a little in the dark about the "/factory" partition, any info would be greatly appreciated!
To unmount a partition you need to input the following command:
Code:
unmount("/system");
Obviously replace the mount partition with whatever partition you are working in.
Format a partition:
To format a partition you need to use the following syntax:
Code:
format("filesystem-type", "partition-type", "device-specific-location", "0");
Example:
Code:
format("ext4", "EMMC", "/dev/block/platform/omap/omap_hsmmc.0/by-name/system", "0");
Some scripts include the "0" and some do not, not sure exactly on the function difference when included or not, again clarification would be great.
Flashing the contents of your ZIP file:
To flash an entire directory:
Code:
package_extract_dir("system", "/system");
To flash a single file:
Code:
package_extract_file("boot.img", "/dev/block/platform/omap/omap_hsmmc.0/by-name/boot");
These commands are structured as follows:
Entire directory: ("zipfileSource", "destination-partition");
Single File: ("file", "device-specific-mountpoint");
Deleting folders & files:
You can delete multiple folders or files using just one command, as follows:
To delete files:
Code:
delete("file-path-1", "file-path-2", "file-path-3);
To delete folders/directories:
Code:
delete_recursive("directory-path-1", "directory-path-2", "directory-path-3");
Setting Permissions
Here are the basics for setting permissions.
If you want to research the reasons behind this, there is some useful information on Linux permissions here: chmod wiki, linuxquestions.org linux wiki.
Thanks to JoeSyr for his input and help understanding this section of the tutorial.
Set permissions of a file or set of files:
Code:
set_perm(uid, gid, mode, "filepath1", "filepath2")
Example:
Code:
set_perm(0, 0, 06755, "/system/xbin/su");
uid - user id
gid - group id
mode - permission mode
filepath... - file to set permission on
Set permissions of a directory or set of directories and all files and folders within them:
Code:
set_perm_recursive(uid, gid, dirmode, filemode, "dirpath1", "dirpath2")
Example:
Code:
set_perm_recursive(0, 0, 0755, 0644, "/system");
uid - user id
gid - group id
dirmode - permission to set to directories contained within the specified directory
filemode - permission to set to files contained within the specified directory
dirpath... - directory to set permission on
Permissions syntax explained...so I can understand it lol (if I do then anyone can!):
The following are the pre-defined Android UID's & GID's. Taken from the following link: Android UIDs and GIDs
Code:
AID_ROOT 0 /* traditional unix root user */
AID_SYSTEM 1000 /* system server */
AID_RADIO 1001 /* telephony subsystem, RIL */
AID_BLUETOOTH 1002 /* bluetooth subsystem */
AID_GRAPHICS 1003 /* graphics devices */
AID_INPUT 1004 /* input devices */
AID_AUDIO 1005 /* audio devices */
AID_CAMERA 1006 /* camera devices */
AID_LOG 1007 /* log devices */
AID_COMPASS 1008 /* compass device */
AID_MOUNT 1009 /* mountd socket */
AID_WIFI 1010 /* wifi subsystem */
AID_ADB 1011 /* android debug bridge (adbd) */
AID_INSTALL 1012 /* group for installing packages */
AID_MEDIA 1013 /* mediaserver process */
AID_DHCP 1014 /* dhcp client */
AID_SHELL 2000 /* adb and debug shell user */
AID_CACHE 2001 /* cache access */
AID_DIAG 2002 /* access to diagnostic resources */
/* The 3000 series are intended for use as supplemental group id's only. */
/* They indicate special Android capabilities that the kernel is aware of. */
AID_NET_BT_ADMIN 3001 /* bluetooth: create any socket */
AID_NET_BT 3002 /* bluetooth: create sco, rfcomm or l2cap sockets */
AID_INET 3003 /* can create AF_INET and AF_INET6 sockets */
AID_NET_RAW 3004 /* can create raw INET sockets */
AID_MISC 9998 /* access to misc storage */
AID_NOBODY 9999
AID_APP 10000 /* first app user */
"root", AID_ROOT
"system", AID_SYSTEM
"radio", AID_RADIO
"bluetooth", AID_BLUETOOTH
"graphics", AID_GRAPHICS
"input", AID_INPUT
"audio", AID_AUDIO
"camera", AID_CAMERA
"log", AID_LOG
"compass", AID_COMPASS
"mount", AID_MOUNT
"wifi", AID_WIFI
"dhcp", AID_DHCP
"adb", AID_ADB
"install", AID_INSTALL
"media", AID_MEDIA
"shell", AID_SHELL
"cache", AID_CACHE
"diag", AID_DIAG
"net_bt_admin", AID_NET_BT_ADMIN
"net_bt", AID_NET_BT
"inet", AID_INET
"net_raw", AID_NET_RAW
"misc", AID_MISC
"nobody", AID_NOBODY
You will need to also understand the way file permissions are represented:
Example = drwxrwxrwx
-Use Root Explorer to find the UID, GID, and permissions for a file. Permissions are the string that looks like some variation on 'rwxr-xr--' next to each file. Long press and choose "change owner" to get the UID and GID. You just want the number next to "owner" and "group", respectively.
-If you're replacing a file, look up these settings for the existing copy and use them. If you're adding a file, just find a file that does the same functions and copy what it has (for example, installing an app to /system/app? Just look at these settings for any other app in that directory).
-MODE is technically a 4-bit string, but the first character can be omitted. There doesn't seem to be any android file permissions with the first character set. For good practice, I think it's safe to assume you can always use a leading 0 unless you know otherwise for something specific. Or, just use a 3-digit MODE, which says to leave those settings as they are (disabled by default). (I.e. 0644=644).
The next 9 characters define the file permissions. These permissions are
given in groups of 3 each.
The first 3 characters are the permissions for the owner of the file or directory.
Example = -rwx------
The next 3 are permissions for the group that the file is owned by.
Example = ----rwx---
The final 3 characters define the access permissions for everyone not part of the group.
Example = -------rwx
There are 3 possible attributes that make up file access permissions.
r - Read permission. Whether the file may be read. In the case of a
directory* this would mean the ability to list the contents of the
directory.
w - Write permission. Whether the file may be written to or modified. For
a directory* this defines whether you can make any changes to the contents
of the directory. If write permission is not set then you will not be able
to delete* rename or create a file.
x - Execute permission. Whether the file may be executed. In the case of a
directory* this attribute decides whether you have permission to enter*
run a search through that directory or execute some program from that
directory
You set these permissions using the following binary based numerical system:
Code:
0: --- No Permissions (the user(s) cannot do anything)
1: --x Execute Only (the user(s) can only execute the file)
2: -w- Write Only (the user(s) can only write to the file)
3: -wx Write and Execute Permissions
4: r-- Read Only
5: r-x Read and Execute Permissions
6: rw- Read and Write Permissions
7: rwx Read, Write and Execute Permissions
Default Linux permissions:
For Files:
"Read" means to be able to open and view the file
"Write" means to overwrite or modify the file
"eXecute" means to run the file as a binary
For Directories:
"Read" means to be able to view the contents of the directory
"Write" means to be able to create new files/directories within the directory
"eXecute" means to be able to "Change Directory" (cd) into the directory
Most of the time you set "Read" and "eXecute" together on directories (kind of useless when set by themselves)
Interestingly through further research it seems this system is based on the Octal Binary system...I may be wrong...
Code:
Octal
Binary is also easily converted to the octal numeral system, since octal uses a radix of 8, which is a power of two (namely, 23, so it takes exactly three binary digits to represent an octal digit).
The correspondence between octal and binary numerals is the same as for the first eight digits of hexadecimal in the table above.
Binary 000 is equivalent to the octal digit 0, binary 111 is equivalent to octal 7, and so forth.
Octal Binary
0 000
1 001
2 010
3 011
4 100
5 101
6 110
7 111
Converting from octal to binary proceeds in the same fashion as it does for hexadecimal:
658 = 110 1012
178 = 001 1112
And from binary to octal:
1011002 = 101 1002 grouped = 548
100112 = 010 0112 grouped with padding = 238
And from octal to decimal:
658 = (6 × 81) + (5 × 80) = (6 × 8) + (5 × 1) = 5310
1278 = (1 × 82) + (2 × 81) + (7 × 80) = (1 × 64) + (2 × 8) + (7 × 1) = 8710
Flash boot partition
This uses the following command but with some caveats:
Code:
write_raw_image("path to boot.img", "boot");
An example of this commands use would be to flash a custom kernel, as far as I can tell though you need to place the boot.img in a temp file before the actual flash (clarification on this would be helpful). You would therefore use the following commands as part of your edify script:
Code:
package_extract_file("boot.img","/tmp/boot.img");
write_raw_image("/tmp/boot.img", "device-specific-boot-partition-mount-point");
delete("/tmp/boot.img");
It seems this may only be for specific handsets though e.g HTC, having looked through quite a few updater-script files from maguro zips it seems this can just be flashed directly with the following command:
Code:
package_extract_file("boot.img", "/dev/block/platform/omap/omap_hsmmc.0/by-name/boot");
Many thanks for further clarification on this particular command from efrant below:
I feel more comfortable using something like this:
Code:
package_extract_file("boot.img", "/tmp/boot.img");
run_program("/sbin/busybox", "dd", "if=/tmp/radio.img", "of=/dev/block/platform/omap/omap_hsmmc.0/by-name/boot");
delete("/tmp/boot.img")
The second line is using the "dd" command to flash the image.
The dd command (included in busybox) is:
Code:
dd if=xxx of=yyy
where xxx is the source image/partition and yyy is the target image/partition. So, for example, to flash a radio image stored in /sdcard called xxlf1.img to a GNex, it would be:
Code:
busybox dd if=/sdcard/xxlf1.img of=/dev/block/platform/omap/omap_hsmmc.0/by-name/radio (I've added "busybox" the the beginning, just to be explicit.)
So, to put it in edify format, it becomes:
Code:
run_program("/sbin/busybox", "dd", "if=/sdcard/xxlf1.img", "of=/dev/block/platform/omap/omap_hsmmc.0/by-name/radio");
However, as I said, I believe your one line:
Code:
package_extract_file("boot.img", "/dev/block/platform/omap/omap_hsmmc.0/by-name/boot");
would work.
Further Commands:
In progress...
So, this is by no means an exhaustive list and I would appreciate it that if I have made any mistakes people make me aware in this thread and I can update this tutorial.
I would also like to add further commands and their uses, if people can provide more I will add them too.
I hope this helps people out! Many thanks!
Thx for your work. Will try it when I back @ home.
Mfg Daniel
Gesendet von meinem Galaxy Nexus mit Tapatalk 2
very interesting 3ad.i'm learning right now how to make these,yours guide resolve me a lot of questions!thanks mate!+1
Awesome. Thank you!
Thanks for the feedback folks!
Top post updated with guides for:
Signing ZIP files
Creating private ZIP signing keys
I have updated the second post with edify commands:
Contents:
Post #1: Tutorials
Post #2: Edify Commands
I would like to expand and update this information to help both others and myself learn, if people can help with more commands or any corrections this would be much appreciated!
Thanx a lot . Ive been looking into editing apks and themeing and this answers a lot of my questions. Exactly what I've been looking for.
Sent from my Galaxy Nexus using XDA
graffitiwriter said:
Thanx a lot . Ive been looking into editing apks and themeing and this answers a lot of my questions. Exactly what I've been looking for.
Click to expand...
Click to collapse
Many thanks for the feedback.
Everything I know about Android has been learned from internet research and tutorials. So as far as I can I like to then re-share the things I have learned in way that I understand in the hope it will in turn help others!
wilskywalker said:
Many thanks for the feedback.
Everything I know about Android has been learned from internet research and tutorials. So as far as I can I like to then re-share the things I have learned in way that I understand in the hope it will in turn help others!
Click to expand...
Click to collapse
Me too. What I've been doing is opening other people's flashable .zips and making changes that I needed to make so I can flash what I wanted to flash. I have something that I want to change in a ROM I've been helping to work on, and your guide will help in the setup process.
dsmryder said:
Me too. What I've been doing is opening other people's flashable .zips and making changes that I needed to make so I can flash what I wanted to flash. I have something that I want to change in a ROM I've been helping to work on, and your guide will help in the setup process.
Click to expand...
Click to collapse
Glad my guide helped out buddy! This community has helped me to learn so much, it's nice to give something back.
I'm looking to create a script that deletes system apps/sounds I don't want upon updating CM9 (nightly). I've taken a script from a different device and modified, what I hope is, accordingly. I only edited the mounts to: ext4 /dev/block/platform/omap/omap_hsmmc.0/by-name /system and of course the apps I want to delete upon first boot. Edit removed the detailed path as per someone's advice.
Does this look like it will accomplish my objective?
Edit: Annnnnnnd it doesn't.
Code:
#!/system/bin/sh
#mount system rw
mount -o remount, rw -t /system
#apps to delete
#send installed apps to /data/packages
pm list packages -f > /data/packages
for i in HoloSpiralWallpaper LiveWallpapers LiveWallpapersPicker MagicSmokeWallpapers Music PhaseBeam RomManager VisualizationWallpapers
do
if [ -e /system/app/$i.apk ]
then
rm -f /system/app/$i.apk
grep $i.apk /data/packages > /data/pname
pname2=$(sed 's/\(.*=\)\(.*\)/\2/' /data/pname)
pm uninstall $pname2
fi
done
rm -f /data/packages
rm -f /data/pname
#delete camera_click sound
if [ -e /system/media/audio/ui/camera_click.ogg ]
then
rm -f /system/media/audio/ui/camera_click.ogg
fi
#delete camera_focus sound
if [ -e /system/media/audio/ui/camera_focus.ogg ]
then
rm -f /system/media/audio/ui/camera_focus.ogg
fi
#mount system ro
mount -o remount,ro -t /system
Source: http://forum.xda-developers.com/showthread.php?t=1050288
CMNein said:
I'm looking to create a script that deletes system apps/sounds I don't want upon updating CM9 (nightly). I've taken a script from a different device and modified, what I hope is, accordingly. I only edited the mounts to: ext4 /dev/block/platform/omap/omap_hsmmc.0/by-name /system and of course the apps I want to delete upon first boot. Edit removed the detailed path as per someone's advice.
Does this look like it will accomplish my objective?
Edit: Annnnnnnd it doesn't.
Code:
#!/system/bin/sh
#mount system rw
mount -o remount, rw -t /system
#apps to delete
#send installed apps to /data/packages
pm list packages -f > /data/packages
for i in HoloSpiralWallpaper LiveWallpapers LiveWallpapersPicker MagicSmokeWallpapers Music PhaseBeam RomManager VisualizationWallpapers
do
if [ -e /system/app/$i.apk ]
then
rm -f /system/app/$i.apk
grep $i.apk /data/packages > /data/pname
pname2=$(sed 's/\(.*=\)\(.*\)/\2/' /data/pname)
pm uninstall $pname2
fi
done
rm -f /data/packages
rm -f /data/pname
#delete camera_click sound
if [ -e /system/media/audio/ui/camera_click.ogg ]
then
rm -f /system/media/audio/ui/camera_click.ogg
fi
#delete camera_focus sound
if [ -e /system/media/audio/ui/camera_focus.ogg ]
then
rm -f /system/media/audio/ui/camera_focus.ogg
fi
#mount system ro
mount -o remount,ro -t /system
Source: http://forum.xda-developers.com/showthread.php?t=1050288
Click to expand...
Click to collapse
Hey buddy,
This looks like an init.d script to me, this is different to Edify. init.d scripts are placed in the /system/etc/init.d folder and performs actions when you boot the phone.
Your post has piqued my interest in init.d scripting though, might have to make it my next thing to learn!
wilskywalker said:
Hey buddy,
This looks like an init.d script to me, this is different to Edify. init.d scripts are placed in the /system/etc/init.d folder and performs actions when you boot the phone.
Your post has piqued my interest in init.d scripting though, might have to make it my next thing to learn!
Click to expand...
Click to collapse
Yes init.d, wasn't sure if you'd have insight or not, but glad to have piqued your interest
Sent from my Galaxy Nexus
CMNein said:
Yes init.d, wasn't sure if you'd have insight or not, but glad to have piqued your interest
Click to expand...
Click to collapse
Sorry I couldn't help more buddy.
Interest definitely piqued though...only problem is that I am currently trying to teach myself HTML5, C++ and Edify as well...lol!
Whenever I am working on a particular project I always get sidetracked and end up trying to learn a whole new language...the only reason I started investigating Edify was so I could flash bootanimations and that led to this tutorial!
Hi, I just recently set out to teach myself making flashable zips and this was one of the more helpful guides that I found. Especially helps that it's for my phone, which eliminates a good chunk of confusion, and that it's recent, since a lot of guides that I've found seem to be a bit outdated.
However, you don't say anything about setting permissions and that's the topic that I've had the most trouble finding clear documentation for. I see it included enough that I figure that it's good practice to cover any time you're pushing files with a flash, instead of just assuming that you can run fix permissions afterwards out of habit. Without a background working with linux permissions this was all a lot to absorb, and googling terms was frustratingly unhelpful, but hopefully this goes on to help someone else.
Syntax:
Code:
set_perm (UID, GID, MODE, "PATH");
set_perm_recursive(UID, GID, DIRMODE, FILEMODE, "PATH");
So, I think I get this, but the UID and GID aspects, and the leading digit of mode still leaves me feeling like I can do this right, but not fully understand why. Here's what I'm working with:
-UID and GID set the ownership of the file/directory. List of options in android found here:
http://android-dls.com/wiki/index.php?title=Android_UIDs_and_GIDs
I've only ever seen this specified as 0 (root access) or 1000 (system access) in examples I've opened to look at. I'm not sure I entirely understand when to use 1000, but it seems like a good rule of thumb that pushing anything to a dir that usually requires root to access, set to 0.
-MODE is summed up nicely here, and it seems like for the most part you want to use a leading 0, or omit it (leave settings as is).
-And then path is just the file or directory in question. Multiple paths can be specified in the same command if desired.
So in general, a zip that pushes a file to an existing directory should include a line in the installer-script that sets the right permissions. Android seems to keep things pretty simple, so chances are you can browse to the directory and just check the permissions for anything there and use them. For example, everything in /system/app is set to rw-r--r--, which is 644. So if you wanted to push a file to /system/app, you'd use this:
Code:
set_perm (0, 0, 0644, "/system/app/[filename]");
.
If you are pushing multiple files to /system/app, you could use this:
Code:
set_perm (0, 0, 0644 "/system/app/[filename1]", "system/app/[filename2]");
Edit: I'm not sure I see an easy way to use set_perm_recursive to just cover all bases unless you're dealing with a folder that you know has only one uniform permission setting across the board (such as /system/app or /data/app). But if you're pushing a bunch of system apps, for example, you could use this:
Code:
set_perm_recursive (0, 0, 0755, 0644 "/system/app");
and it should have the same effect on the /system/app folder as just running fix permissions in recovery would do.
If I have anything wrong here please let me know. Gonna go tinker with it and try to make a working zip now as a test.
JoeSyr said:
Hi, I just recently set out to teach myself making flashable zips and this was one of the more helpful guides that I found. Especially helps that it's for my phone, which eliminates a good chunk of confusion, and that it's recent, since a lot of guides that I've found seem to be a bit outdated.
However, you don't say anything about setting permissions and that's the topic that I've had the most trouble finding clear documentation for...
...If I have anything wrong here please let me know. Gonna go tinker with it and try to make a working zip now as a test.
Click to expand...
Click to collapse
Ahh, permissions, this is my next set of commands in post #2. I really don't understand the whole permissions thing currently, so was having trouble writing it in simple terms for all to understand...if that makes sense!?
If you are happy, I would like to include your findings in the second post with all the commands (I may re-word/re-order etc for clarity as we learn more) I will of course credit you for all your help!?
I am literally trying to learn about setting permissions currently as well so its great to collaborate, this was what I was hoping for when I started this tutorial.
Ok, I have been researching Android file permissions and commands all afternoon, there really is not much documentation to be found.
I have found the info I think I need to add this to my tutorial, just need to make sense of it myself first and put it in some sort of understandable order!
Big update coming soon...
wilskywalker said:
Ahh, permissions, this is my next set of commands in post #2. I really don't understand the whole permissions thing currently, so was having trouble writing it in simple terms for all to understand...if that makes sense!?
If you are happy, I would like to include your findings in the second post with all the commands (I may re-word/re-order etc for clarity as we learn more) I will of course credit you for all your help!?
I am literally trying to learn about setting permissions currently as well so its great to collaborate, this was what I was hoping for when I started this tutorial.
Click to expand...
Click to collapse
Yes by all means feel copy and/or adapt anything I've written, and if I give the impression that I know what I'm talking about I'm happy to try and explain things as well.
I'll let you decide for yourself how much of an explanation you want to include in your guide, personally I'm going through and teaching myself a lot here, but I think I've just about figured out what you *need to know* to use the set_perm function in edify. You basically need one tool and the ability to do basic math in your head:
-Use Root Explorer to find the UID, GID, and permissions for a file. Permissions are the string that looks like some variation on 'rwxr-xr--' next to each file. Long press and choose "change owner" to get the UID and GID. You just want the number next to "owner" and "group", respectively.
-If you're replacing a file, look up these settings for the existing copy and use them. If you're adding a file, just find a file that does the same functions and copy what it has (for example, installing an app to /system/app? Just look at these settings for any other app in that directory).
-The permission string is a nine-character string. It is rwx repeated three times, each of which stands for one number. Within each rwx block, read r as 4, w as 2, and x as 1. A dash indicates 0 instead of whichever number. So, learn to read rwxrwxrwx as (4+2+1)|(4+2+1)|(4+2+1)=777; rwxr-xr-- is (4+2+1)|(4+0+1)|(4+0+0)=754, etc. This is what you enter for MODE, with one additional note:
-MODE is technically a 4-bit string, but the first bit is special and can be omitted. I've looked around, and have yet to find a single file on my phone that has anything set for the first bit. For good practice, I think it's safe to assume you can always use a leading 0 unless you know otherwise for something specific. Or, just use a 3-digit MODE, which says to leave those settings as they are (disabled by default). (I.e. 0644=644).
As another note, I personally use ES File Explorer w/ root access in my day-to-day tasks because I like the interface, but it will not give you UID or GID, or let you chance these settings.
For really understanding why this is all done this way, I think it helps to really get a grasp for why linux permissions work the way that they do (read this page) and how they are manipulated (this page). Then, consider that a lot of that is built on the assumption that there are multiple humans in the same environment, but android is built on the premise of one person and their phone. Security is largely reduced to limiting the abilities of apps (which all get their own user id, as though apps are a bunch of people signing into computers and trying to look at each others' files). Groups are pre-defined here, and the usual setup is that apps get to effectively request group permissions when installed, otherwise most things in userland don't get access to much other than writing and reading the sdcard.
Sort of makes you appreciate the work done to get phones rooted and turn them from a pallet of pre-defined actions set by OEMs into real computers.
wilskywalker said:
...
Format a partition:
To format a partition you need to use the following syntax:
Code:
format("filesystem-type", "partition-type", "device-specific-location", "0");
Example:
Code:
format("ext4", "EMMC", "/dev/block/platform/omap/omap_hsmmc.0/by-name/system", "0");
Some scripts include the "0" and some do not, not sure exactly on the function difference when included or not, again clarification would be great.
...
Click to expand...
Click to collapse
How to format boot? There is no that menu in CWM and TWRP
Hi!
As with Galaxy S2, I have ported the u-boot bootloader to the Galaxy Nexus. It can be chainloaded from samsung bootloader (loaded instead of linux kernel) safely.
It could be useful to have multiple ROMs on one device or test other OS like Ubuntu or Genode.
Detailed installation guide is available at Ksys Labs LLC wiki http://ksyslabs.org/doku.php?id=gnex_uboot .I'll just copy-paste it here
Happy hacking and don't forget to visit our wiki at http://ksyslabs.org !
===== Rationale ======
There were a couple reasons to port u-boot to Galaxy Nexus
* Security: we cannot trust the proprietary samsung bootloader
* Implementing dual-boot for original and custom firmware
* Booting Genode operating system
===== Demo =====
===== Compilation from source =====
Source code is in https://github.com/Ksys-labs/uboot-tuna
There exist two branches of interest
* master - contains the official stable releases. may be force-pushed and rebased, beware
* tuna-fosdem-hacks contains the u-boot that was used for FOSDEM 2013 to demo booting Genode
To compile, you need to have the ARM cross-compiler. I recommend codesourcery 2010q1-188 because that's what I'm using and some users reported that newer compilers produce broken binaries.
There are two ways to use the u-boot. One is flashing it instead of the Samsung SBL bootloader. The other one is chainloading it from the SBL.
Flashing instead of SBL has the following advantages
* Faster boot time than chainloading
* Ability to use the standard partitioning layout
There is a number of issues and therefore we do not recommend flashing it instead of SBL
* No Fastboot support (preliminary USB RNDIS and DHCP BOOTP support is available), you'll have to use OMAPFlash to restore the device if you flash a non-working kernel
* No display initialization. You'll have to disable the "Check for Bootloader initialization" option in kernel config
By default, the chainloaded version is compiled. It is loaded (by the SBL) to the address **0x81808000**.
If you want to build the SBL replacement version, edit the **include/configs/omap4_tuna.h** file and uncomment the **#define TUNA_SPL_BUILD** line. X-loader loads the bootloader to the address **0xa0208000**.
Code:
export PATH=/home/alexander/handhelds/armv6/codesourcery/bin:$PATH
export ARCH=arm
export CROSS_COMPILE=arm-none-eabi-
U_BOARD=omap4_tuna
make clean
make distclean
make ${U_BOARD}_config
make -j8 ${U_BOARD}
mkbootimg --kernel u-boot.bin --ramdisk /dev/null -o u-boot.aimg
===== Installation =====
==== Chainloaded Mode ====
You'll need the root access to your device.
You can take the prebuilt u-boot here. http://ksyslabs.org/lib/exe/fetch.php?media=gnex-uboot-chainloaded.img
The u-boot has the support for android boot images. When flashed instead of the SBL, it boots the kernel off the "Boot" partition. When chainloaded, it looks for the kernel in **/system/boot/vmlinux.uimg** . Additionally, it first looks for the **/system/boot/boot.scr.uimg** so you can put custom commands there and override the kernel image.
It also supports booting custom images from **/sdcard/boot/vmlinux.uimg** and **/sdcard/boot/boot.scr.uimg**
If you need larger images, I suggest that you use the **tuna-fosdem-hacks** branch, format the cache partition to ext2 and put the files to **/cache/media/boot/**
push the files to your device via adb
Code:
adb push gnex-uboot-chainloaded.img /sdcard/
adb hell
now, in the device shell, do the following
Code:
su
cat /dev/block/platform/omap/omap_hsmmc.0/by-name/boot > /sdcard/vmlinux.uimg
mount -o remount,rw /system
mkdir /system/boot
cp /sdcard/vmlinux.uimg /system/boot/
cat /sdcard/gnex-uboot-chainloaded.img > /dev/block/platform/omap/omap_hsmmc.0/by-name/boot
sync
reboot
Instead of installing gnex-uboot-chainloaded.img via dd, you can use fastboot
Code:
fastboot flash:raw boot u-boot.img
===== Replacing samsung bootloader =====
OMAP4 devices cannot be bricked completely because the CPU has a firmware loader in the OTP (one-time programmable) memory. When the device is powered, it tries booting from USB.
Make sure to have an old version of x-loader (PRIMEKK14) because newer ones have the security hole which allowed booting unsigned bootloaders fixed. The installation procedure is roughly the same, but use **sbl** partition. And also install xloader from http://ksyslabs.org/lib/exe/fetch.php?media=gnex-xloader-working.img
Code:
adb push gnex-xloader-working.img /sdcard/
Code:
cat /sdcard/gnex-xloader-working.img > /dev/block/platform/omap/omap_hsmmc.0/by-name/xloader
There exists a Samsung recovery tool which can unbrick the devices with corrupted xloader/SBL. You will need a computer running Windows XP.
Search the internet for the archive named "OMAPFlash_tuna.zip" which has md5 "ddbf07a1d36b044c40af5788a83b5395". We cannot upload it here because of the unclear license status.
===== Making images =====
You can either use Android's mkbootimg to produce ANDROID! type images (not recommended) or u-boot's mkimage (in the u-boot tools directory) to make boot images. Using ANDROID! format is discouraged because the loader code in the u-boot is buggy and may fail in some corner cases such as large images.
==== making a custom boot image ====
Code:
mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n linux -d zImage vmlinux.uimg
#alternatively, just do that when compiling linux
#do not forget to add mkimage to your PATH variable
make uImage
==== making a custom boot script ====
Code:
mkimage -A arm -O linux -T script -C none -a 0x84000000 -e 0x84000000 -n android -d boot.scr boot.scr.uimg
===== Booting Modes =====
The bootloader supports several boot modes. Each boot mode is indicated by the color of the LED and activated by a combination of hardware buttons. It also supports the Android "reboot to recovery" and "reboot to bootloader" features
* Normal Boot -> no keys are pressed, cyan LED
* Recovery Boot -> Volume Up key pressed, green LED
* Custom Boot -> Volume Down key pressed, blue LED
* USB RNDIS mode -> both Volume keys pressed, purple LED
===== Pitfalls =====
* No Fastboot or DFU (RNDIS BOOTP is untested) -> not a big deal if you're chainloading, right?
* Serial number is always 0123456789abcdef or sth like that. Anyone to fix that?
* UART support is quirky. The device will likely hang if booted with the UART cable. Workaround: boot without the UART cable and plug right after the purple LED flashes.
===== A sample boot script for android =====
Make a boot.scr.uimg from it and push it to the correct location.
Code:
setenv bootargs "mem=1G vmalloc=768M omap_wdt.timer_margin=30 mms_ts.panel_id=18
no_console_suspend console=ttyFIQ0";
setenv loaddaddr 0x82000000;
setenv devtype mmc;
setenv devnum 0;
setenv kernel_part 0xc;
setenv kernel_name /media/boot/vmlinux.uimg;
echo Load Address: ${loaddaddr};
echo cmdline:${bootargs};
if ext4load ${devtype} ${devnum}:${kernel_part} ${loaddaddr} ${kernel_name}; then
bootm ${loaddaddr};
exit 0;
elif ext2load ${devtype} ${devnum}:${kernel_part} ${loaddaddr} ${kernel_name}; then
bootm ${loaddaddr};
exit 0;
else
echo failed to boot custom image;
fi
Nice!
Before there actually wasn't any dual boot stuff for Nexus but now there is really much....
I will laugh if someone ports still another dual boot loader to Nexus, E.g BootiQi dual boot loader or what it is..., (for Jét it is JétQi) but I don't remember the original dual boot files names...
Any toro support?
Sent from my Galaxy Nexus using xda app-developers app
saber.srod said:
Any toro support?
Sent from my Galaxy Nexus using xda app-developers app
Click to expand...
Click to collapse
You may try it out. It is flashed instead of kernel, not overwriting the bootloader, so should be safe. As we don't have any Toro devices, we're not particularly interested in providing support for them unless someone steps up with a patch
Also, make sure to have an old version of x-loader (PRIMEKK14) because newer ones have the security hole which allowed booting unsigned bootloaders fixed.
Click to expand...
Click to collapse
do you have PRIMEKK14 file?
cause I couldn't find it on this thread:
http://forum.xda-developers.com/showthread.php?t=1587498
or this one is PRIMEKK14?
http://ksyslabs.org/lib/exe/fetch.php?media=gnex-xloader-working.img
any enlightenment please?
savantist said:
do you have PRIMEKK14 file?
cause I couldn't find it on this thread:
http://forum.xda-developers.com/showthread.php?t=1587498
or this one is PRIMEKK14?
http://ksyslabs.org/lib/exe/fetch.php?media=gnex-xloader-working.img
any enlightenment please?
Click to expand...
Click to collapse
The latter one is the one I'm using on my phone so it should work.
sp3dev said:
The latter one is the one I'm using on my phone so it should work.
Click to expand...
Click to collapse
I wanna use the chainloaded method, so first thing I should do is fastboot-ing that .img just like another bootloader file? then chainload the u-boot file?
but it looks like I'm replacing samsung SBL (replacing SBL method) if I do that, doesn't it?
savantist said:
I wanna use the chainloaded method, so first thing I should do is fastboot-ing that .img just like another bootloader file? then chainload the u-boot file?
but it looks like I'm replacing samsung SBL (replacing SBL method) if I do that, doesn't it?
Click to expand...
Click to collapse
Yes, you can actually fastboot it via
"fastboot flash:raw boot u-boot.img"
and no, you don't need to mess with xloader for chainloading
sp3dev said:
Yes, you can actually fastboot it via
"fastboot flash:raw boot u-boot.img"
and no, you don't need to mess with xloader for chainloading
Click to expand...
Click to collapse
so it's ok to do chainloading in PRIMELC03 bootloader? If yes, I'm success...
finally "The Great Sp3dev"
nice work like always,
playing with it now,let's see where it goes
Sent from my Galaxy Nexus using xda premium
sp3dev said:
The latter one is the one I'm using on my phone so it should work.
Click to expand...
Click to collapse
ah, I bricked my phone with your gnex-xloader-working using following script... It is only 128K. Is that right?
Code:
cat /sdcard/gnex-xloader-working.img > /dev/block/platform/omap/omap_hsmmc.0/by-name/xloader
Is PRIMEKK14 bootloader the only one to work since we only have http://forum.xda-developers.com/showthread.php?t=1587498 this thread for bootloader and there's no flashable version of PRIMEKK14?
I use OMAPFlash to save it having PRIMEKK15 bootloader and I do not have the courage to do it again...
dlhxr said:
ah, I bricked my phone with your gnex-xloader-working using following script... It is only 128K. Is that right?
Code:
cat /sdcard/gnex-xloader-working.img > /dev/block/platform/omap/omap_hsmmc.0/by-name/xloader
Is PRIMEKK14 bootloader the only one to work since we only have http://forum.xda-developers.com/showthread.php?t=1587498 this thread for bootloader and there's no flashable version of PRIMEKK14?
I use OMAPFlash to save it having PRIMEKK15 bootloader and I do not have the courage to do it again...
Click to expand...
Click to collapse
Oh well, I specially edited the post so that chainloaded users don't flash loader. You only need the xloaded if you flash u-boot instead of SBL. Otherwise, treat u-boot just as linux kernel.
As for replacing bootloader, I guess PRIMEKK15 should also work, I just didn't notice when the security check was introduced. Yeah, use OMAPFlash to recover anyway. And note that you cannot use my precompiled u-boot to replace SBL. As written in the beginning of the post, you need to change a define in config and recompile because the load address and partition layout are different for chainloading and direct booting cases.
Very nice! Keep the good work up! :good:
sp3dev said:
Oh well, I specially edited the post so that chainloaded users don't flash loader. You only need the xloaded if you flash u-boot instead of SBL. Otherwise, treat u-boot just as linux kernel.
As for replacing bootloader, I guess PRIMEKK15 should also work, I just didn't notice when the security check was introduced. Yeah, use OMAPFlash to recover anyway. And note that you cannot use my precompiled u-boot to replace SBL. As written in the beginning of the post, you need to change a define in config and recompile because the load address and partition layout are different for chainloading and direct booting cases.
Click to expand...
Click to collapse
Some feedback here. I flashed u-boot to boot partition and save the original boot image to /system/boot/vmlinux.uimg.
Without any key pressed it shows
Code:
Wrong Image Format for boot command
Error: can't get kernel image!
Not booting xxxxxxxxx
Fail to boot
The characters on the screen does not show well and some of them can't be recognized....
When I press the volume up, it boot into recovery.
When I press the volume down, it shows
Code:
File not found /media/boot/vmlinux.uimg
Unrecognized filesystem type
Fail to boot
Something is wrong with my procedure?
Another small question. I want to make a zip to flash the U-boot, but always failed. I have to use fastboot command to flash gnex-uboot-chainloaded.img to boot.img.
What is in my updater-script.
Code:
mount("ext4", "EMMC", "/dev/block/platform/omap/omap_hsmmc.0/by-name/system", "/system");
package_extract_file("gnex-uboot-chainloaded.img", "/tmp/gnex-uboot-chainloaded.img");
package_extract_file("META-INF/com/google/android/switch_boot.sh", "/tmp/switch_boot.sh");
set_perm(0, 0, 0777, "/tmp/switch_boot.sh");
run_program("/tmp/switch_boot.sh");
set_perm(0, 0, 0777, "/system/boot/vmlinux.uimg");
unmount("/system");
What is in my switch_boot.sh
Code:
#!/sbin/sh
cat /dev/block/platform/omap/omap_hsmmc.0/by-name/boot > /tmp/vmlinux.uimg
mkdir /system/boot
cp /tmp/vmlinux.uimg /system/boot/
cat /tmp/gnex-uboot-chainloaded.img /dev/block/platform/omap/omap_hsmmc.0/by-name/boot
It seems the last line doesn't work...
Code:
cat /tmp/gnex-uboot-chainloaded.img /dev/block/platform/omap/omap_hsmmc.0/by-name/boot
If I use the following command in updater-script,
Code:
package_extract_file("gnex-uboot-chainloaded.img", "/dev/block/platform/omap/omap_hsmmc.0/by-name/boot");
The device enters bootloader directly showing no boot image after reboot....
dlhxr said:
If I use the following command in updater-script,
Code:
package_extract_file("gnex-uboot-chainloaded.img", "/dev/block/platform/omap/omap_hsmmc.0/by-name/boot");
The device enters bootloader directly showing no boot image after reboot....
Click to expand...
Click to collapse
That's because SBL expects the boot partition to contain the image in ANDROID! format. It creates the image itself when you flash via fastboot with the ":raw" suffix.
Try that
Code:
mkbootimg --kernel gnex-uboot-chainloaded.img --ramdisk /dev/null -o u-boot.aimg
Not sure why the original boot image didn't work for you. Are you copying the boot.img to vmlinux.uimg or the raw zImage? you should do the former, the u-boot expects either the "ANDROID!" image or the one made with mkimage.
If anything, you could try repacking the boot image yourself or try mine to see if it boots (it's for jb 4.1.1 though)
http://rghost.ru/44686398
chainloading method, in fact it works on PRIMELC03 too...
btw,
if I flash the xloader (replacing bootloader method), then how am I gonna back to original samsung bootloader/PRIMELC03 since there isn't fastboot support in your u-boot bootloader?
using odin? or omapflash? :crying:
thanks.
savantist said:
chainloading method, in fact it works on PRIMELC03 too...
Click to expand...
Click to collapse
ok, I probably didn't make it clear enough. chainloading works with any bootloader and is safe.
savantist said:
btw,
if I flash the xloader (replacing bootloader method), then how am I gonna back to original samsung bootloader/PRIMELC03 since there isn't fastboot support in your u-boot bootloader?
using odin? or omapflash? :crying:
thanks.
Click to expand...
Click to collapse
if you can boot android or recovery, thenuse dd it to /dev/block/blah-blah-blah, otherwise - omapflash.
sp3dev said:
ok, I probably didn't make it clear enough. chainloading works with any bootloader and is safe.
if you can boot android or recovery, thenuse dd it to /dev/block/blah-blah-blah, otherwise - omapflash.
Click to expand...
Click to collapse
you wrote it on wrong part on first page yesterday, makes me little bit confused, but it's corrected now...
but to do "replacing bootloader method", one should flash PRIMEKK14 or PRIMEKK15 bootloader before, right?
wow... omapflash...
savantist said:
you wrote it on wrong part on first page yesterday, makes me little bit confused, but it's corrected now...
but to do "replacing bootloader method", one should flash PRIMEKK14 or PRIMEKK15 bootloader before, right?
wow... omapflash...
Click to expand...
Click to collapse
well, some bootloaders after PRIMEKK may work, but I have not tested and we had some new phones with the recent firmware versions from stock, and u-boot failed to work there until xloader was downgraded
Hi,
I started to play with kernel hacking/configuration and I found the annoying red message
After a lot of research i found that we can get rid of it by adding at the end of boot.img file the SEANDROIDENFORCE text string, as following
echo SEANDROIDENFORCE >> boot.img
Best regards,
Marc
serdeliuk said:
Hi,
I started to play with kernel hacking/configuration and I found the annoying red message
After a lot of research i found that we can get rid of it by adding at the end of boot.img file the SEANDROIDENFORCE text string, as following
echo SEANDROIDENFORCE >> boot.img
Best regards,
Marc
Click to expand...
Click to collapse
Thanks.. Work bro..
diphons said:
Thanks.. Work bro..
Click to expand...
Click to collapse
Yeah, I'd like recommend to find a solution to get also rid of "set warranty bit kernel/recovery", the yellow warning is really annoying!
I was able to append the boot.img file with SEANDROIDENFORCE text string.
But how do you exactly write it back?
I'm on samsung note 4.
Code:
adb reboot recovery
adb shell
dd if=/dev/block/bootdevice/by-name/BOOT of=/sdcard/boot.img
echo SEANDROIDENFORCE >> /sdcard/boot.img
If i try to switch if and of path, I get an error
Code:
dd if=/sdcard/boot.img of=/dev/block/bootdevice/by-name/BOOT
dd: writing '/dev/block/bootdevice/by-name/BOOT': No space left on device
UnknownPlanet said:
I was able to append the boot.img file with SEANDROIDENFORCE text string.
But how do you exactly write it back?
Code:
adb reboot recovery
adb shell
dd if=/dev/block/bootdevice/by-name/BOOT of=/sdcard/boot.img
echo SEANDROIDENFORCE >> /sdcard/boot.img
If i try to switch if and of path, I get an error
Code:
dd if=/sdcard/boot.img of=/dev/block/bootdevice/by-name/BOOT
dd: writing '/dev/block/bootdevice/by-name/BOOT': No space left on device
Click to expand...
Click to collapse
In order to write the boot.img you need to use fastboot/bootloader mode of your device, adb reboot bootloader, then use `fastboot flash boot boot.img`
Alternatively, you can put the boot.img on your /sdcard boot to twrp then `cat boot.img > /dev/your/boot/partition`
The no space left on the device means that your file is bigger than the destination which is unusual if you built that boot img, from your example it seems that you save your partition and do not use a built boot.img
serdeliuk said:
In order to write the boot.img you need to use fastboot/bootloader mode of your device, adb reboot bootloader, then use `fastboot flash boot boot.img`
Alternatively, you can put the boot.img on your /sdcard boot to twrp then `cat boot.img > /dev/your/boot/partition`
Click to expand...
Click to collapse
It doesn't work, I'm on samsung note 4. I also have latest TWRP installed.
fastboot device keep saying:
< waiting for any device >
UnknownPlanet said:
It doesn't work, I'm on samsung note 4. I also have latest TWRP installed.
fastboot device keep saying:
< waiting for any device >
Click to expand...
Click to collapse
you need to find how to boot your device in bootloader mode, usually volDOWN+power together
serdeliuk said:
Alternatively, you can put the boot.img on your /sdcard boot to twrp then `cat boot.img > /dev/your/boot/partition`
Click to expand...
Click to collapse
Still error
Code:
~ # cat /sdcard/boot.img > /dev/block/bootdevice/by-name/BOOT
cat: write error: No space left on device
serdeliuk said:
The no space left on the device means that your file is bigger than the destination which is unusual if you built that boot img, from your example it seems that you save your partition and do not use a built boot.img
Click to expand...
Click to collapse
I use Custom ROM of Hani Base v1.01 here:
[ROM][6.0.1][TW][N910C/H/U] Hani Base v1.01 [18-04-2016][Deodexed][PreRooted]
Welcome to Hani Base ROM thread! Samsung Galaxy Note 4 SM-N910C N910CXXU2DPCB TW 6.0.1 THREAD INDEX: I. INTRODUCTION II. FEATURES III. DOWNLOADS IV. HOW TO FLASH #_____________________________# #include ...
forum.xda-developers.com
I have succcessfuly get and edit the boot.img but I don't know how to flash it back. Forking to make another whole custom ROM is not an option. I won't learn anything.
It's just a tiny append why so difficult.
serdeliuk said:
you need to find how to boot your device in bootloader mode, usually volDOWN+power together
Click to expand...
Click to collapse
There's no bootloader in my samsung note 4, adb reboot bootloader goes to system instead.
Home+Power+VolumeDown enters the download mode, but even then fastboot device still doesn't respond.
Do I need to use Odin or what?
You may need to ask questions about your boot options on the dedicated channel for your device, i do not own such device, but download mode is the fastboot mode as far as can remember, "fastboot devices" should show your device listed when in download mode.
Your steps to flash the boot.img fail because the file is bigger than your boot partition, does not fit there, you may need to seek for help form the img developers to see what to do. You can try to flash the boot.img on recovery partitions which is usually bigger and reboot to recovery, but pay attention, if you don't know how to go back to fastboot mode you are stuck with a bricked device
I was able to flash it without any change in the boot partition size by editing it manually using hex editor.
These are my steps
Code:
adb reboot recovery
adb shell "dd if=/dev/block/bootdevice/by-name/BOOT of=/sdcard/boot.img"
adb pull /sdcard/boot.img
I use Frhed hex editor to edit the last 16 bytes of boot.img into SEANDROIDENFORCE
Code:
adb push boot.img /sdcard/boot.img
adb shell "dd if=/sdcard/boot.img of=/dev/block/bootdevice/by-name/BOOT"
The problem right now is that, the red text is still there. What should be my next step?
UnknownPlanet said:
I was able to flash it without any change in the boot partition size by editing it manually using hex editor.
These are my steps
Code:
adb reboot recovery
adb shell "dd if=/dev/block/bootdevice/by-name/BOOT of=/sdcard/boot.img"
adb pull /sdcard/boot.img
I use Frhed hex editor to edit the last 16 bytes of boot.img into SEANDROIDENFORCE
Code:
adb push boot.img /sdcard/boot.img
adb shell "dd if=/sdcard/boot.img of=/dev/block/bootdevice/by-name/BOOT"
The problem right now is that, the red text is still there. What should be my next step?
Click to expand...
Click to collapse
I don't know if editing the boot.img works, probably should do, however, i found this solution poking around with third party device trees and worked for my samsung galaxy tab, if do not work on your phone then you may need to dig a bit deeper, however, if you use a third party image maybe you ask them why you have that on your screen, maybe they have another fix. Probably a bit of more info can be found here https://github.com/osm0sis/dhtbsign but i didn't spent time to read it. You can ask the developer about more info.
Your solution of device tree / dhtb is impressive on it's own, that's another big learning curve.
But I think I know the problem, because the Custom ROM Hani Base above is using H-Vitamin Kernal which is SELinux Permissive. No matter how I edit the boot.img file the red text message will always appears, unless I flash it with another kernel which is SELinux Enforcing.
UPDATE
This is even weirder.
By updating SuperSU into the latest version, the red text is missing from system mode. It still persist in recovery mode tough, because, well twrp need full access to begin with.
No Magisk here, it was an old custom ROM.
All official app from playstore is now gone but the official xda thread still remain:
[STABLE][2017.05.27] SuperSU v2.82
*** Urgent Update Notice *** We are deeply sorry about the installation errors and failures happened in v2.80. The new update v2.81 has rolled out on XDA and Play Store to fix the problem occured in v2.80. Chainfire has also...
forum.xda-developers.com
From reading the last pages of the thread, I got the official site of chainfire to download it.
SuperSU Download
The file name is
sr5-supersu-v2.82-sr5-20171001224502.zip
Just flash it with latest TWRP and you're done.
I still don't understand how could updating SuperSU could fix the problem.
But what a long journey, thank you so much @serdiluk , I learn so much things.
A long time ago, I posted in a forum thread about my difficulty in trying to revive my M2003J15SG and after having my ethereal Windows install bricked. I switched to Fedora and tried my hand there, where surprisingly, things worked very well. I'm not calling this a guide because I'm basically piecing this together from my bash_history and recollection. I have used the word guide too many times to keep that sentence but yeah, it may be shaky in some places.
Disclaimer
Code:
/*
* Your warranty is... still valid?
*
* I am not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns.
*
* I have removed the part about laughing at you because I'm not a meanie :3
*
* But yeah, this text is as-is. We provide this work to you without
* warranty of any kind, express or implied and in no event shall the authors
* be liable for any claim, damages or other liability in any way, shape or form,
* arising from, out of, in connection with the work
*
*/
A few things to note
This is an attempt to document my experience with BROM recovery of a phone that I bricked because I flashed an incorrect littlekernel image. If you're able to use other methods (using fastboot, recovery mode, hell, even preloader mode, you should probably go with that, this is a last resort).
This guide does involve opening your device, you will need a heat gun, a few picks and a screwdriver. No, this is not optional.
If you've read the excellent guide by VD171 on bypassing authentication and flashing, you may notice the important text that states
> Once you get "Protection disabled" at the end, without disconnecting phone and usb, run SP Flash Tool
That's because if you do disconnect and attempt to reconnect your device, it won't be recognized anymore. On Windows, this manifests as the infamous "USB device not recognized" error. This isn't you installing incorrect drivers, that's the device behaving erratically.
To have a second go at it, you have to press Vol Up + Power for about 60 seconds before you can retry.
To enter BROM mode, you need to press Vol Down and no other key, and then plug in your device.
This guide while being Fedora-specific, could be translated to other Linux distros assuming you have the necessary packages installed and have the appropriate permissions and udev rules set
This model of device doesn't need the kamakiri-specific kernel patch
On RHEL-like distros like Rocky Linux and... RHEL, you may need to disable SELinux. I have mine disabled at install so I'm not sure how this guide will behave with SELinux enforcement enabled.
Click to expand...
Click to collapse
Ingredients
Stock MIUI ROM V11.0.5.0.QJOMIXM (the fastboot variant), which you can get from XiaomiFirmwareUpdater
SP Flash Tool v5.2020 for Linux, which you can get from SPFlashTools
VD171's readback_ui_bak.xml, which you can get from their XDA Forums thread
VD171's scatterfiles for V11.0.5.0.QJOMIXM, which you can get from their XDA forums thread
You'll specifically need MT6768_Android_scatter--V11.0.5.0.QJOMIXM--boundary_false.txt and MT6768_Android_scatter--V11.0.5.0.QJOMIXM--download_true--boundary_false.txt
mtkclient, an MTK device exploit kit, which you can find on their GitHub (you'll need their master branch, not their releases, so there'll be instructions on how to fetch it)
A box of chocolate chip cookies
Click to expand...
Click to collapse
a) Preparing the computer
Step 0: Extract all ingredients and put them into one directory for ease of access
You can do this via the command line or through your file manager, it's just for convinence. This guide will assume that everything is done in one neat folder.
Click to expand...
Click to collapse
Step 1: Install all the dependencies you'll need
Bash:
sudo dnf install android-tools git libusb-devel python3 python3-pip systemd-udev
Step 2: Prevent Linux from interfering with MediaTek serial connections
Bash:
sudo touch /etc/udev/rules.d/20-mm-blacklist-mtk.rules
echo "ATTRS{idVendor}==\"0e8d\", ENV{ID_MM_DEVICE_IGNORE}=\"1\"" | sudo tee /etc/udev/rules.d/20-mm-blacklist-mtk.rules
echo "ATTRS{idVendor}==\"6000\", ENV{ID_MM_DEVICE_IGNORE}=\"1\"" | sudo tee -a /etc/udev/rules.d/20-mm-blacklist-mtk.rules
Step 3: Clone mtkclient and install its dependencies
Bash:
git clone https://github.com/bkerler/mtkclient
cd mtkclient
pip3 install -r requirements.txt
python3 setup.py build
sudo python3 setup.py install
Step 4: Install mtkclient's bundled udev rules
Bash:
sudo usermod -a -G dialout $USER
sudo cp Setup/Linux/*.rules /etc/udev/rules.d
Step 5: Reload udev rules
Bash:
sudo udevadm control --reload-rules
sudo udevadm trigger
Step 6: Return to previous directory
Bash:
cd ..
b) Preparing the device
This is where you basically follow this iFixit guide for the purposes of just disconnecting the battery cable. So, just stop at Step 12, then put the back cover on just flush enough that you can now click the volume and power buttons and insert a cable into the USB-port but not too much so that you have to go through the effort of reopening it again (because, well, you'll have to).
Attempting to skip this will yield you STATUS_EXT_RAM_EXCEPTION.
Click to expand...
Click to collapse
c) Backing everything up
Alongside ROM and userdata, your EMMC contains your IEMI, your bootloader lock state, MAC addresses, calibration data, the whole nine yards. It's always a good idea to back things up before we get started.
Step 1: Copy readback_ui_bak.xml to the SP Flash Tool directory
Bash:
cp ./readback_ui_bak.xml ./SP_Flash_Tool_v5.2020_Linux/readback_ui_bak.xml
Step 2: Connecting your device and applying the exploit
Start off by running the exploit.
Bash:
cd mtkclient
chown +x mtk
./mtk payload
Once it says Preloader - Status: Waiting for PreLoader VCOM, please connect mobile, hold down Vol Down and connect your phone to the computer. If everything goes according to plan, you'll get an output similar to this.
Code:
Port - Device detected :)
Preloader - CPU: MT6768/MT6769(Helio P65/G85 k68v1)
Preloader - HW version: 0x0
Preloader - WDT: 0x10007000
Preloader - Uart: 0x11002000
Preloader - Brom payload addr: 0x100a00
Preloader - DA payload addr: 0x201000
Preloader - CQ_DMA addr: 0x10212000
Preloader - Var1: 0x25
Preloader - Disabling Watchdog...
Preloader - HW code: 0x707
Preloader - Target config: 0xe7
Preloader - SBC enabled: True
Preloader - SLA enabled: True
Preloader - DAA enabled: True
Preloader - SWJTAG enabled: True
Preloader - EPP_PARAM at 0x600 after EMMC_BOOT/SDMMC_BOOT: False
Preloader - Root cert required: False
Preloader - Mem read auth: True
Preloader - Mem write auth: True
Preloader - Cmd 0xC8 blocked: True
Preloader - Get Target info
Preloader - BROM mode detected.
Preloader - HW subcode: 0x8a00
Preloader - HW Ver: 0xca00
Preloader - SW Ver: 0x0
Preloader - ME_ID: [redacted]
Preloader - SOC_ID: [redacted]
PLTools - Loading payload from mt6768_payload.bin, 0x264 bytes
PLTools - Kamakiri / DA Run
Kamakiri - Trying kamakiri2..
Kamakiri - Done sending payload...
PLTools - Successfully sent payload: [redacted]/mtkclient/mtkclient/payloads/mt6768_payload.bin
Click to expand...
Click to collapse
Step 3: Open SP Flash Tool
Bash:
cd ../SP_Flash_Tool_v5.2020_Linux
chmod +x flash_tool
sudo ./flash_tool
Yes, I'm aware, it's technically not advisable to grant superuser privileges to, a flashing tool but... I can't get it to work otherwise, if you know how to make it work on Fedora, drop a comment.
Click to expand...
Click to collapse
Step 4: Load the Download Agent (DA)
Click "Choose" and go to (common directory)/mtkclient/mtkclient/Loader/xiaomi_9_DA_6765_6785_6768_6873_6885_6853.bin
Click to expand...
Click to collapse
Step 5: Configure SP Flash Tool
Go to Options > Option
In General, uncheck "Storage Lifecycle Check"
In Connection, select "UART"
COM Port: /dev/ttyACM0 (it may not be the exact number, it'll just look something similar to this)
Baud rate: 921600
In Download
Uncheck "USB Checksum"
Uncheck "Storage Checksum"
Click to expand...
Click to collapse
Step 6: Backup device contents
Start by going to the "Readback" tab, it should already be populated with values that correspond to images from pgpt to otp. If you are presented with an empty table, you've need to go back and check if you've copied readback_ui_bak.xml to the correct directory.
If it shows up, then click "Read Back" and if all goes according to plan, you should see the green checkmark show up eventually.
Click to expand...
Click to collapse
d) Flashing stock firmwareStep 1: Copy scatterfiles to ROM directory
Bash:
cp ./MT6768_Android_scatter--V11.0.5.0.QJOMIXM--boundary_false.txt ./merlin_global_images_V11.0.5.0.QJOMIXM_20200609.0000.00_10.0_global/images/MT6768_Android_scatter--V11.0.5.0.QJOMIXM--boundary_false.txt
cp ./MT6768_Android_scatter--V11.0.5.0.QJOMIXM--download_true--boundary_false.txt ./merlin_global_images_V11.0.5.0.QJOMIXM_20200609.0000.00_10.0_global/images/MT6768_Android_scatter--V11.0.5.0.QJOMIXM--download_true--boundary_false.txt
Step 2: Flash the firmware
Return to the "Download" tab and select the MT6768_Android_scatter--V11.0.5.0.QJOMIXM--boundary_false.txt scatterfile we just copied in the ROM's images directory
Select "Firmware Upgrade" from the drop-down menu and then hit "Download". If all goes according to plan, you should see a green checkmark.
Click to expand...
Click to collapse
Step 3: Restore bootloader status (optional)
In case you had an unlocked bootloader before imploding your phone and don't want to bother with Xiaomi's rigmarole, then by restoring seccfg, you should get it back.
Step 3.1: Copy over seccfg from our backup
You're probably going to be using a new terminal window because SP Flash is still running, navigate to your common directory first. The backup we did earlier stored all the images within the SP Flash Tool directory. We need to use sudo because flash_tool was running with root privileges and so, was writing with root privileges as well.
Bash:
sudo cp ./SP_Flash_Tool_v5.2020_Linux/seccfg ./merlin_global_images_V11.0.5.0.QJOMIXM_20200609.0000.00_10.0_global/images/seccfg
Step 3.2: Change the scatterfile, select the image and flash it
Change the scatterfile to MT6768_Android_scatter--V11.0.5.0.QJOMIXM--download_true--boundary_false.txt and un-select everything except seccfg
Select "Download Only" from the drop-down menu and then hit "Download". Fingers crossed, green checkmark, you should get your unlock back.
Click to expand...
Click to collapse
Step 4: Reconnect your battery and first boot
If you've reached this point and everything has worked as expected, reconnect your battery, long press the Power button and you should be greeted with a boot animation and hopefully a functioning phone.
Click to expand...
Click to collapse
e) Packing it up
Basically, just... follow the iFixit guide from Step b) in reverse and seal up your phone. I don't use this phone regularly so I never bothered sealing it, relying only on the plastic clips. You probably should but that's outside the scope of this journal.
Click to expand...
Click to collapse
f) Upgrading to Android 11 (optional)
As of this writing, LineageOS supports this device under the codename merlinx (the x is because of a conflict with the Moto G3 Turbo, which shares the same codename) and according to their install documentation, they expect a base of Android 11 and this guide flashes Android 10.
I personally used the V12.5.4.0.RJOMIXM firmware (available from XiaomiFirmwareUpdater, again, use the fastboot version) but I did an ever-so-slight change. The entire song-and-dance of needing the bypass exploit is because of "upgrades" made to the payload. I modified flash_all.sh to omit flashing the payload and the modification looks something like this (the other comment-outs were already there in the file)
Bash:
(...)
#fastboot $* flash preloader `dirname $0`/images/preloader_merlin.bin
#if [ $? -ne 0 ] ; then echo "Flash preloader error"; exit 1; fi
#fastboot $* flash efuse `dirname $0`/images/efuse.img
#if [ $? -ne 0 ] ; then echo "Flash efuse error"; exit 1; fi
fastboot $* flash logo `dirname $0`/images/logo.bin
if [ $? -ne 0 ] ; then echo "Flash logo error"; exit 1; fi
fastboot $* flash tee1 `dirname $0`/images/tee.img
"Flash preloader error"; exit 1; fi
(...)
I also commented out the reboot command at the end so I could flash LineageOS's recovery and flash the OS that I wanted.
Bash:
(...)
#fastboot $* reboot
#if [ $? -ne 0 ] ; then echo "Reboot error"; exit 1; fi
(...)
Of course, you need to boot into fastboot mode (by taking a turned off device and pressing Power + Vol Down) before you execute the script
Code:
cd merlin_global_images_V12.5.4.0.RJOMIXM_20220325.0000.00_11.0_global
chmod +x flash_all.sh
./flash_all.sh
Click to expand...
Click to collapse
Sources
https://github.com/bkerler/mtkclient
https://github.com/bkerler/mtkclient/issues/94
https://www.hovatek.com/blog/my-experience-unbricking-a-dead-boot-lg-stylo-6/
https://forum.xda-developers.com/t/...omi-redmi-10x-4g-xiaomi-redmi-note-9.4221065/
https://forum.xda-developers.com/t/...for-merlin-redmi-10x-4g-redmi-note-9.4238149/
https://forum.xda-developers.com/t/...omi-redmi-10x-4g-xiaomi-redmi-note-9.4223107/
https://forum.xda-developers.com/t/...omi-redmi-10x-4g-xiaomi-redmi-note-9.4223093/
Wow !
Really amazing guide !
Nice, nice
Thank you very much for contribution