Related
*** PLEASE READ CAREFULLY BEFORE INSTALLING OR FLASHING ANY SOFTWARE POSTED IN THIS THREAD ***
The software posted here is for TESTING purposes only, The Polaris Android Linux development team or any of the posters of software or links to software on this thread, take absolutely no responsibility or liability for damage caused by the result of installing or flashing software or links to software found on this thread - correctly or otherwise, you do so on the sole understanding that you do so at your own risk.
Previous thread was closed because too big you can find lot of information into it with the search button : http://forum.xda-developers.com/showthread.php?t=555000
Hello to all of you, Android user.
This thread is the right place to talk about non-kernel related discussions, questions and requests.
Please, remember that the thread is public, so don't use bad word
So...have fun
-------------------------------------------------------------------------------------------------------------------------------
01-09-09 - new link to files for working wifi
http://www.4shared.com/dir/19593527/...a/sharing.html
From Google Code Vogue-Android:
01-09-09 - Initrd - works with unpartitioned cards, otherwise no changes.
01-09-09 - Rootfs - works with unpartitioned cards, otherwise no changes.
Reserved for future use
Reserved for future use.
Reserved for future use,
Reserved for future use-
what packages do i have to dload? everything?
nicandris said:
what packages do i have to dload? everything?
Click to expand...
Click to collapse
From the first link (4share), you took all but rootfs and initrd, these one you could download it from the other links
You should put name Android in the title to know about what is this thread
whitealien said:
You should put name Android in the title to know about what is this thread
Click to expand...
Click to collapse
Thanks for the suggestion
@Mormy
Could you give us your startup/default haret script? With script whitch you uploaded to 4shared, graphics don't work properly.
Good thing to open a clean thread to speak about testing
I'm currently testing the SquashFs version, latest on http://code.google.com/p/vogue-android/downloads/list
With this system.sqsh : http://vogue-android.googlecode.com/files/hero.zip
And this base files : http://vogue-android.googlecode.com/files/squashfsbasefiles.zip
It's very stable. With this build I haven't got anymore the 'reload UI' problem when I go back to home screen.
But it's very slow. It takes more time to launch application, wake up the phone, open settings... But the scrolling is normally fast.
Wifi doesn't work for me with it.
Maybe I'll try this one tonight : system-090109r1.img on http://code.google.com/p/vogue-hero/downloads/list
I didn't understood how works the last one with 'userinit.sh' system, so I think I will not try it
Averne said:
@Mormy
Could you give us your startup/default haret script? With script which you uploaded to 4shared, graphics don't work properly.
Click to expand...
Click to collapse
I've tried Neocore and won't start either with the 4share startup and with mine.
By the way, this the one I usually have:
Code:
set RAMSIZE 0x08000000
set MTYPE 1723
set KERNEL zImage
set initrd initrd.gz
#
# The following kernel parameters are useful
# ppp.username - The username used to connect to the network when dialing
# ppp.password - The password used to connect to the network when dialing
# ppp.apn - Set apn of your provider
# ppp.nostart - Set ppp.nostart=1 to disable starting the ppp connection on boot
# msm_sdcc.msmsdcc_fmax - The maximum frequency (in Hz) used by the SD controller
# pm.sleep_mode - The mode used when the phone is off
# 0=Power Collapse Suspend, 1=Power Collapse, 2=Apps Sleep,
# 3=Slow Clock and Wait for Interrupt 4=Wait for Interrupt
# Default is 1, use 1 for best power savings
# board-htcpolaris.panel_type - Panel type used to power the panel off and on
# 0=Don't power off the panel (Default)
# 1=Sony 2=Topoly 3=Topoly (probably just the same as 2)
# lcd.density - Defaults to 160, 128 shows more on screen
#
set cmdline "board-htcpolaris.panel_type=3 ppp.apn=tre.it ppp.username=none ppp.password=none pm.sleep_mode=1 mddi.width=324 mddi.height=432 no_console_suspend board-htcpolaris-battery.battery_capacity=1350 clock-7x00.mddi=0xa51 mddi_client_vogue.vsync=0"
boot
Averne said:
@Mormy
Could you give us your startup/default haret script? With script whitch you uploaded to 4shared, graphics don't work properly.
Click to expand...
Click to collapse
Try with '1' instead of '3' for "board-htcpolaris.panel_type" property.
Averne said:
@Mormy
Could you give us your startup/default haret script? With script whitch you uploaded to 4shared, graphics don't work properly.
Click to expand...
Click to collapse
if you mean neocore then yes that is broken in this kernel.
if you are having display issues, then try changing the panel type or try to be more specific on what you mean by "graphics dont work properly".
Ok, this is my default.txt file:
Code:
set RAMSIZE 0x08000000
set MTYPE 1723
set KERNEL zImage
set initrd initrd.gz
set cmdline "board-htcpolaris.panel_type=0 ppp.apn=orange ppp.username=orange ppp.password=orange pm.sleep_mode=1 mddi.width=336 mddi.height=448 lcd.density=160 no_console_suspend board-htcpolaris-battery.battery_capacity=1350 mddi_client_vogue.vsync=0"
boot
With this settings display works fine, but you must disconnect usb cable before press [Run] button in haret.
Hi ,
with the last files taken from bally site I have wifi working but data connection li ke previous release taken from vogue-android sometime starts sometimes no.
And with this files I can't start calling it creashes.
No Gps..
Why start up logo is changed? and button mapping?
Averne said:
Ok, this is my default.txt file:
Code:
set RAMSIZE 0x08000000
set MTYPE 1723
set KERNEL zImage
set initrd initrd.gz
set cmdline "board-htcpolaris.panel_type=0 ppp.apn=orange ppp.username=orange ppp.password=orange pm.sleep_mode=1 mddi.width=336 mddi.height=448 lcd.density=160 no_console_suspend board-htcpolaris-battery.battery_capacity=1350 mddi_client_vogue.vsync=0"
boot
With this settings display works fine, but you must disconnect usb cable before press [Run] button in haret.
Click to expand...
Click to collapse
why have you got lcd density set at 160 and width and height at 336x448?
this is not my startup file. you should try that first.
Does somebody know what are the benefits of using 'squash FS' system instead of old standard system.img?
Kiiv said:
Does somebody know what are the benefits of using 'squash FS' system instead of old standard system.img?
Click to expand...
Click to collapse
if you are really interested: (from http://groups.google.com/group/andr...ad/e4ce4f06f982d51b/30fa2b5deb6533b2?lnk=raot)
I think it would be a good idea to compress /system/bin and /system/
lib at least with squashfs, I have done this on a couple ubuntu and
gentoo systems and it actually increased performance and space
significantly!
Reasons (short version): decompressing data is faster than reading it
from the hard drive, in most current computers, especially when you
have multiple programs reading from the disk, causing thrashing, and/
or when the data on the disk is fragmented. You can read more details
about what was done and the results on http://forums.gentoo.org/viewtopic-p-4732709.html#4732709
Squashfs is intended for general read-only file system use and in
constrained block device/memory system, it can also be combined with a
union mount system like unionfs and aufs for read/write access.
We will be able to improve android boot time, app launch time, and
increase space, what more could we ask for? Maybe a little bit more
ram? Whats up with compcache too?
So now we just need to compile squashfs-tools for android and
experiment, im pretty damn excited to try this!
Also ubifs has lzo compression, not sure how that would work either,
it seems ubifs is favored over jffs2 and yaffs2
Well right now it looks squashfs+lzma wont be in the kernel until
2.6.30 found this via:
http://www.squashfs-lzma.org/
So I think we are left with UbiFS with lza compression but I have no
idea on how to add it to the kernel, and test this out, im really
interested in seeing some results and doing some benchmarks, if
someone more knowledgeable than me can help out that would be awesome
defcon
found a nice pdf comparing the filesystems:
http://free-electrons.com/doc/flash-filesystems.pdf
Benchmarks Of Yaffs2, JFFS2, SquashFS, & UBIFS:
http://free-electrons.com/pub/conferences/2008/elce/flash-filesystems...
Seems like people are already using ubifs on android:
http://groups.google.com/group/android-porting/browse_thread/thread/a...
Reference:
http://forums.gentoo.org/viewtopic-p-4732709.html#4732709
http://jt0.org/news/squashing_usr_and_the_2629_kernel
Hum, thank you for the link
So I don't understand why it's slower with squash FS on my phone... I will try to find other discussions on the subject.
Hello folks,
it's me again (RaymanFX aka Chris Hesse) and I want to introduce you to a little, but important project.
My goal is to finally be able to backup the 'boot' partition of our device in CWM and TWRP or others !
How can we get to that ?
Well, I already have an exact plan on how to do it.
1. Step : examining the boot partition (LNX) size and offsets
2. Step : invoke a kernel hack to parse the partition layers to the system at runtime (WARNING : This will only work on a hack-enabled kernel) - I will provide one.
3. Step : re-enable 'boot' partition backup (in TWRP, e.g.) I will recompile TWRP with newest code when the time is right
Ok, so what do we have ?
1. To examine these partition layout sizes and offsets, we have to strip of the hex value of !ANDROID or ANDROID! of /dev/block/mmcblk0 using the dd command.
I already did this.
Here's how to do it :
Code:
iMac21:~ RaymanFX$ adb shell
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
~ # dd if=/dev/block/mmcblk0 of=/sdcard/20m.bin bs=1M count=20
20+0 records in
20+0 records out
20971520 bytes (20.0MB) copied, 1.271406 seconds, 15.7MB/s
~ # exit
iMac21:~ RaymanFX$ adb pull /sdcard/20m.bin /Users/RaymanFX/Desktop
2413 KB/s (20971520 bytes in 8.487s)
Then open a hex editor and search for the sring value 'ANDROID!' and copy that value.
Mine is :
Code:
0x37FFED
Now we have to convert this to get the sizes and offsets we need (I work together with Dees_Troy to resolve this).
-> To be fixed soon !
2. When we proceed, we need to invoke a kernel hack at compile time, so every old kernel needs to be recompiled.
-> I will provide a recompiled and hack-enabled harmony kernel soon
Code:
Here will be the required code fix; commit at my GitHub
3. And last but not least :
A new version of TWRP needs to be compiled to re-include the boot partition for the nandroid system, i will compile one with the newest updates once the previous steps are made.
As always, I need assistance to proceed faster with your help.
I can do everything on my own, but it will take time. What I need the most urgent is someone to convert the hex values to get the offset and size values.
One for me
The recompiled harmony kernel and information for kernel devs will be posted here.
Last one, open disscussion now !
NOTE : THIS IS A [DEV] THREAD, SO PLEASE DON'T CLUTTER IT WITH QUESTIONS THAT DON'T BELONG IN HERE. IF YOU WANT TO SUPPORT ME, HIT THE 'THANKS' BUTTON TO KEEP ME MOTIVATED !
Hmm, sounds intriguing. Why would we want to backup our boot partition exactly? Sorry, I just had to ask. Why wouldn't we be able to poll the partition via adb, or is this to make it possible via a GUI? Or are you talking about the boot loader? Argh, I'm confused...
hanthesolo said:
Hmm, sounds intriguing. Why would we want to backup our boot partition exactly? Sorry, I just had to ask. Why wouldn't we be able to poll the partition via adb, or is this to make it possible via a GUI? Or are you talking about the boot loader? Argh, I'm confused...
Click to expand...
Click to collapse
so we can back up kernel, each time we restore a rom from CWM it does not restore kernel so we have to reflash that.
hanthesolo said:
Hmm, sounds intriguing. Why would we want to backup our boot partition exactly? Sorry, I just had to ask. Why wouldn't we be able to poll the partition via adb, or is this to make it possible via a GUI? Or are you talking about the boot loader? Argh, I'm confused...
Click to expand...
Click to collapse
The 'boot' partition (LNX, in our case) stores the whole kernel and the ramdisk, combined as a boot image.
This means if I am successful, we can just backup the kernel in recovery along with the rom, like other android devices already do.
E.g. when you flash a new rom, but backed up the old one first, you have to flash a kernel compatible with the rom manually when going back to your backup as of now.
After my work has succeeded, you can just restore the old android, which restores the kernel automatically.
RaymanFX said:
The 'boot' partition (LNX, in our case) stores the whole kernel and the ramdisk, combined as a boot image.
This means if I am successful, we can just backup the kernel in recovery along with the rom, like other android devices already do.
E.g. when you flash a new rom, but backed up the old one first, you have to flash a kernel compatible with the rom manually when going back to your backup as of now.
After my work has succeeded, you can just restore the old android, which restores the kernel automatically.
Click to expand...
Click to collapse
Okay, I thought so, I just needed confirmation. Bad question #3: why can't we did the kernel partition, and restore it that way?
hanthesolo said:
Okay, I thought so, I just needed confirmation. Bad question #3: why can't we did the kernel partition, and restore it that way?
Click to expand...
Click to collapse
Ask this to ASUS !
Those guys gave us a crappy partition layout, meaning we only have /staging for flashing boot and recovery blobs, NO REAL PARTITIONS holding those files. -> UNITL NOW ! I examined the boot offset and size ...
Seems like the recovery ad boot partition share the same offsets and sizes .. will check this
EDIT : Progress : I have the offsets and sizes right at my hands !
See : My hex offset is 0x37ffed, I take this and convert it to decimal ()10 ... then I get 3669997, which fits our definitions perfectly (7chars).
Now, we have to divide this by the block layer size (512), we get 7167.962890625, which is ugly.
The second one has hex offset at 0x87ffe8, decimal at 8912872, decided by 512 makes 17407.953125
Very nice work, seems like more and more people are learning to dev.
RaymanFX said:
Ask this to ASUS !
Those guys gave us a crappy partition layout, meaning we only have /staging for flashing boot and recovery blobs, NO REAL PARTITIONS holding those files. -> UNITL NOW ! I examined the boot offset and size ...
Seems like the recovery ad boot partition share the same offsets and sizes .. will check this
EDIT : Progress : I have the offsets and sizes right at my hands !
See : My hex offset is 0x37ffed, I take this and convert it to decimal ()10 ... then I get 3669997, which fits our definitions perfectly (7chars).
Now, we have to divide this by the block layer size (512), we get 7167.962890625, which is ugly.
The second one has hex offset at 0x87ffe8, decimal at 8912872, decided by 512 makes 17407.953125
Click to expand...
Click to collapse
Oh, okay, ouch, this sounds like it is going to be a LOT if fun to do . I thought it would be possible because the uodater-script flashes kernels to mmcblk0p4, but I guess that was staging, not the actual kernel partition (this also explains why I got a fliesize if 500ish MB the other day when I dd'ed the partition). Good luck to you, and I will try to help the next time I am bored/have free time.
The important stuff is in the header (raw?) of mmcblk0, so it should be possible to just use dd.
K900 said:
The important stuff is in the header (raw?) of mmcblk0, so it should be possible to just use dd.
Click to expand...
Click to collapse
... so ?
Look at my first post, this is exactly what I did. Stripped off the first 20M and found the offsets. I am getting assistance from Dees_Troy and the TF300 devs to ensure everything is going the right way.
RaymanFX said:
... so ?
Look at my first post, this is exactly what I did. Stripped off the first 20M and found the offsets. I am getting assistance from Dees_Troy and the TF300 devs to ensure everything is going the right way.
Click to expand...
Click to collapse
What I mean is patching the kernel to make it a 'partition' is dangerous and can cause unexpected results, so dd and a modified recovery should be used instead.
K900 said:
What I mean is patching the kernel to make it a 'partition' is dangerous and can cause unexpected results, so dd and a modified recovery should be used instead.
Click to expand...
Click to collapse
Believe me, they can't be used. We need the kernel patch. The guys from tf300 tried anything, but using the kernel hack was the only way to make this possible.
And if (not possible in theory) the hack would cause problems, we can always flash a different one since the /staging-flash is not affected at all
RaymanFX said:
Believe me, they can't be used. We need the kernel patch. The guys from tf300 tried anything, but using the kernel hack was the only way to make this possible.
And if (not possible in theory) the hack would cause problems, we can always flash a different one since the /staging-flash is not affected at all
Click to expand...
Click to collapse
There should be other solutions that don't involve uber ugly kernel hacks. I'll see if I can get more info since I have some docs regarding the boot process on generic Tegra boards and reusing same methods (likely bypassing ASUS bootloaders altogether) should be possible, at least now that we have nvflash access for all.
Hey Rayman, any word on this getting up and going? It will kick tail if you do. No more multiple zips then which means more space for me.
According to my research with others in the #asus-transformer channel on Freenode, the correct values are 0x380000 and 0x880000
380000 to decimal becomes: 3670016
3670016 / 512 = 7168 so 7168 is your first offset
880000 to decimal becomes: 8912896
8912896 / 512 = 17408 so 17408 is your second offset
The difference between the 2 values is hex 500000, decimal 5242880.
5242880 / 512 = 10240 which is your size for both.
Of course, after you build a kernel with the correct source and offsets, you'll want to dd dump the partitions and verify with a hex editor that you're getting the right stuff. Both partitions should start with "ANDROID!". You'll also want to unpack the contents of the dd images with unpackbootimg or something and determine which one is recovery and which one is boot. Most likely the first one is recovery.
Technically some of the other people are right. You can probably use dd with the right seek and size values to flash and dump the partitions without modifying the kernel, but modifying the kernel makes for a cleaner, simpler setup. We've used the kernel approach on the TF201, TF300T, and TF700T with much success.
Hope that helps.
Dees_Troy said:
According to my research with others in the #asus-transformer channel on Freenode, the correct values are 0x380000 and 0x880000
380000 to decimal becomes: 3670016
3670016 / 512 = 7168 so 7168 is your first offset
880000 to decimal becomes: 8912896
8912896 / 512 = 17408 so 17408 is your second offset
The difference between the 2 values is hex 500000, decimal 5242880.
5242880 / 512 = 10240 which is your size for both.
Of course, after you build a kernel with the correct source and offsets, you'll want to dd dump the partitions and verify with a hex editor that you're getting the right stuff. Both partitions should start with "ANDROID!". You'll also want to unpack the contents of the dd images with unpackbootimg or something and determine which one is recovery and which one is boot. Most likely the first one is recovery.
Technically some of the other people are right. You can probably use dd with the right seek and size values to flash and dump the partitions without modifying the kernel, but modifying the kernel makes for a cleaner, simpler setup. We've used the kernel approach on the TF201, TF300T, and TF700T with much success.
Hope that helps.
Click to expand...
Click to collapse
From my research
Code:
Position 3670016 / 512 = 7168
Position 8912896 / 512 = 17408
Diff
5242880
10240
From nvflash flash.cfg
SOS Size 5242880 / 512 = 10240
LNX Size 8388608 / 512 = 16384
Also, I already have a kernel compiled. I'll test later.
Just thinking about this thing and wondering about the linux-based (or are they also based on other architectures?) blob tools as a possible workaround? Ignore this if it seems silly. I haven't thought about this sort of thing for a long time and not at all on the transformer.
-
When any of the many kernel/ROM installer scripts take off and do their thing, they use the compiled (usually for linux, but some sort of combo binary and script) blob tools , I thought from Rayman as well (but it's been awhile since I've played with the source and the tools themselves.
Is there any reason why an android version of those couldn't be built and used inside either cwm or tw* to perform both the backup and retrieval of the kernel? I realize it would have to churn out an installer type script somewhere in the backup directory and run it upon restore, but would something like this be one of the multiple possible solutions? I'm guessing there is some obvious reason I've not looked into yet, like a dependency upon some other API or utility that is in a full linux system, but not in an android OS.. (but I don't know).
I suppose the good news of this would be that numbers tied to the partition wouldn't be of much importance since blobbing works OK without them, but there might also be a down side to adding a completely different type of backup/restore paradigm just for the kernel to a nice little piece of code (cwm/tw*) that works for everything else.
hachamacha said:
Just thinking about this thing and wondering about the linux-based (or are they also based on other architectures?) blob tools as a possible workaround? Ignore this if it seems silly. I haven't thought about this sort of thing for a long time and not at all on the transformer.
-
When any of the many kernel/ROM installer scripts take off and do their thing, they use the compiled (usually for linux, but some sort of combo binary and script) blob tools , I thought from Rayman as well (but it's been awhile since I've played with the source and the tools themselves.
Is there any reason why an android version of those couldn't be built and used inside either cwm or tw* to perform both the backup and retrieval of the kernel? I realize it would have to churn out an installer type script somewhere in the backup directory and run it upon restore, but would something like this be one of the multiple possible solutions? I'm guessing there is some obvious reason I've not looked into yet, like a dependency upon some other API or utility that is in a full linux system, but not in an android OS.. (but I don't know).
I suppose the good news of this would be that numbers tied to the partition wouldn't be of much importance since blobbing works OK without them, but there might also be a down side to adding a completely different type of backup/restore paradigm just for the kernel to a nice little piece of code (cwm/tw*) that works for everything else.
Click to expand...
Click to collapse
That would be an option as well I suppose. Take the image and call blobpack and build a blob to be flashed on reboot. Although, if we could 'dd' it cleanly without causing issues with other devices, that would be an ideal solution. Until then, this kernel change will work.
Whenever there's an over-the-air (OTA) update sent-out or made available (either leaked or official), there's always a large number of users that end-up reporting that their installations have failed with the infamous and dreaded "E:Error in /sdcard/xxx.zip (Status 7) installation aborted." error message. So, I decided to try to write an app that would help folks figure-out what the issues might be so that they can get their OTA update installed.
The OTA Verifier app can be used to evaluate an over-the-air (OTA) update.zip or other flashable .zip file before you attempt the install or afterwards to help you figure-out why the installation may have failed. OTA Verifier will point-out what files and conditions are being tested so that you can more easily attempt to correct these issues.
Play Market Link (free!): OTA Verifier (beta)
Do I have to be rooted to use this?
No, but rooted devices will have more conditions that the app will be able to test/evalute because it will have access to protected files that non-rooted devices don't.
Will the app actually do the installation or change anything on my device?
No. The app will only evaluate the expressions and conditions contained inside the updater-script file inside the .zip file that's trying to be installed. None of the functions or commands that try to modify your device (i.e., delete/patch/format/extract, etc.) will be evaluated or executed. The app basically operates in "read-only" mode with respect to the .zip file being evaluated.
Will this app work on older devices or flashable .zip files that use the amend update-script files?
No, this app evaluates and interprets the newer edify updater-script files (notice the "r" in "updater").
How do I use this app?
Install and launch the app
Click the "Select File" button and navigate to desired .zip file
Long-press (press and hold) the file entry for the desired .zip file
Click the "Verify OTA .zip" file pop-up
Wait for the app to process the file (should take under a minute, depending on your device)
View the displayed results (text will also be copied to the clipboard)
Miscellaneous info:
1. Savvy root users probably already know that after a failed .zip file installation, you should be able to view the /cache/recovery/log file to view the information about what might have failed. OTA Verifier will try to uncover all of the issues and not just the first one that causes the installation to fail.
2. While I wrote this app principally to evaluate OTA update.zip files, the edify updater-script files are used and written by ROM devs and others who created flashable .zip files. This app can be used to evaluate those file's updater-script files, too.
How does this all work?
Here's the basic outline/structure of what the app does:
1. the .zip file is selected by the user via the file selector
2. list of frozen system apps are identified for later reporting
3. the updater-script file is extracted from the META-INF/com/google/android folder in the .zip file
4. this updater-script file is parsed and converted into reverse polish notation (RPN) for execution
5. edify functions that might modify your device are NOT evaluated; these include apply_patch, delete, delete_recursive, format, mount, package_extract_dir/file, run_program, set_perm[_recursive], symlink, unmount, write_raw_image, etc.
6. note: the update-binary executable is not used by or involved in this app; the edify script interpreter that the app uses was written by me, in Java, specifically for this app
7. the remaining edify script functions that test conditions (such as apply_patch_check, apply_patch_space, assert, concat, file_exists, file_getprop, getprop, greater_than_int, if-then-else-endif, ifelse, is_substring, less_than_int, read_file, ui_print, and various operators (!, !=, &&, (, ), ;, ||, +, ==)) are evaluated using an operand/operator stack from the RPN expression parsed from the updater-script statements
8. expressions that fail (return a null-string) or are bypassed (usually because a resource (file/partition) is protected/secured against read-access) are reported for the user
9. after the entire script has been processed, the results are displayed in a pop-up window on the device and the text of those results are copied to the clipboard
Planned / future features:
- preferences / settings
- logging of the output to a file on the /sdcard
- test if .zip file is signed or not
- display more stats
- "explanation mode" to interpret, in English, what the edify commands are testing
Successfully tested on:
Samsung Galaxy Nexus (CDMA) 4.1.1
Samsung Galaxy Nexus (GSM) 4.1.2
Asus Nexus 7 tablet 4.1.2
Motorola Droid X 2.3.4
The following edify commands/functions/operators are supported:
Code:
[COLOR="blue"]apply_patch_check[/COLOR] // apply_patch_check ( <filepath>, <sha1-checksum> [ , <sha1-checksum> ... ] )
// apply_patch_check ( <compoundvalue> )
<compoundvalue> := [ EMMC : <filepath> : <sha1-size> : <sha1-checksum> [ <sha1-size> : <sha1-checksum> ... ]
[ MTD : <dev-block> : <sha1-size> : <sha1-checksum> [ <sha1-size> : <sha1-checksum> ... ]
[ vfat : <dev-block> : <sha1-size> : <sha1-checksum> [ <sha1-size> : <sha1-checksum> ... ]
<dev-block> := filename in /dev/block
[COLOR="Blue"]apply_patch_space[/COLOR] // apply_patch_space ( <bytes> )
[COLOR="blue"]assert[/COLOR] // assert ( <expression> )
[COLOR="blue"]concat[/COLOR] // conact ( <string> , <string> )
[COLOR="blue"]file_exists[/COLOR] // file_exists ( <filepath> )
[COLOR="blue"]file_getprop[/COLOR] // file_getprop ( <filepath>, <propertyname> )
[COLOR="blue"]getprop[/COLOR] // getprop ( <propertyname> )
[COLOR="blue"]greater_than_int[/COLOR] // greater_than_int ( <integer>, <integer> )
[COLOR="blue"]if then else endif[/COLOR] // if <condition> then <expression> [ else <expression> ] endif
[COLOR="blue"]ifelse[/COLOR] // ifelse ( <condition>, <then-expression> [ <else-expression> ] )
[COLOR="blue"]is_substring[/COLOR] // is_substring ( <string> , <string> )
[COLOR="blue"]less_than_int[/COLOR] // less_than_int ( <integer>, <integer> )
[COLOR="blue"]read_file[/COLOR] // read_file ( <filepath> )
[COLOR="blue"]ui_print[/COLOR] // ui_print ( <string> ) parsed & executed, but output not displayed
[COLOR="blue"]![/COLOR] // logical NOT operator
[COLOR="blue"]!=[/COLOR] // not equals operator
[COLOR="blue"]&&[/COLOR] // logical AND operator
[COLOR="blue"]([/COLOR] // open paren: precedence / grouping
[COLOR="blue"])[/COLOR] // close paren: precedence / grouping
[COLOR="blue"];[/COLOR] // sequence/imperative (terminates & separates statements)
[COLOR="blue"]||[/COLOR] // logical OR operator
[COLOR="blue"]+[/COLOR] // string concatenation operator
[COLOR="blue"]==[/COLOR] // equals operator
[COLOR="blue"]#[/COLOR] // comment line
The following edify functions are NOT supported (the majority of them because they are intended to modify your device):
Code:
[COLOR="blue"]apply_patch[/COLOR]
[COLOR="blue"]delete[/COLOR]
[COLOR="blue"]delete_recursive[/COLOR]
[COLOR="blue"]format[/COLOR]
[COLOR="blue"]mount[/COLOR]
[COLOR="blue"]package_extract_dir[/COLOR]
[COLOR="blue"]package_extract_file[/COLOR]
[COLOR="blue"]run_program[/COLOR]
[COLOR="blue"]set_perm[/COLOR]
[COLOR="blue"]set_perm_recursive[/COLOR]
[COLOR="blue"]symlink[/COLOR]
[COLOR="blue"]unmount[/COLOR]
[COLOR="blue"]write_raw_image[/COLOR]
[COLOR="blue"]is_mounted[/COLOR] // innocuous, but still not supported
[COLOR="blue"]stdout[/COLOR] // innocuous, but still not supported
[COLOR="blue"]show_progress[/COLOR] // innocuous, but still not supported
[COLOR="blue"]set_progress[/COLOR] // innocuous, but still not supported
Keywords:
OTA, over-the-air, updater-script, edify, amend
Screenshots:
updated 9-May-2014
updated to version 1.3
Updated app with root-enabled file browser for navigating to protected/secured directories like /cache to select OTA's update zip file.
Full change log to date:
[v1.3 - 04-Nov-2012]:
- for rooted devices, change file browser to allow navigating and selecting .zip files in protected directories (like /cache)
[v1.2 - 29-Oct-2012]:
- minor fix to handle two reports of null pointer exceptions
[v1.1 - 28-Oct-2012]:
- remove unused SD card write permission
[v1.0 - 28-Oct-2012]:
- initial Play Market release
This is pretty cool.
Any chance you could direct me to an explanation for sha1-size (for apply_patch_check) is though? I'm working on some edify scripting stuff and trying to incorporate some asserts for a specific bootloader (important to what I'm doing), and this is honestly the best reference I've found for it yet.
osm0sis said:
This is pretty cool.
Any chance you could direct me to an explanation for sha1-size (for apply_patch_check) is though? I'm working on some edify scripting stuff and trying to incorporate some asserts for a specific bootloader (important to what I'm doing), and this is honestly the best reference I've found for it yet.
Click to expand...
Click to collapse
You bet!
I'm heading home from work here soon and I'll dig-up the details for you .
(yeah, I scoured the internet for detailed information on Edify scripting as well as reviewed the actual Google/Android code--there's not a complete compendium, unfortunately).
I'll ping you back after a bit...
Cheers!
osm0sis said:
Any chance you could direct me to an explanation for sha1-size (for apply_patch_check) is though?
Click to expand...
Click to collapse
Okay, here's what I know about the apply_patch_check command:
There are basically two formats:
Code:
apply_patch_check // apply_patch_check ( <filepath>, <sha1-checksum> [ , <sha1-checksum> ... ] )
// apply_patch_check ( <compoundvalue> )
<compoundvalue> := [ EMMC : <filepath> : <sha1-size> : <sha1-checksum> [ <sha1-size> : <sha1-checksum> ... ]
[ MTD : <dev-block> : <sha1-size> : <sha1-checksum> [ <sha1-size> : <sha1-checksum> ... ]
[ vfat : <dev-block> : <sha1-size> : <sha1-checksum> [ <sha1-size> : <sha1-checksum> ... ]
The first of which is what I think you typically see in updater-script files where you have a filename, followed by one or more SHA1 digests. Here's an example:
assert(apply_patch_check("/system/app/ApplicationsProvider.apk", "41bb5aaaa2791e68b55622fcca13f0e4efa757b2", "fc845332ae7f706824de73f64ae47f93866ad245"));
The second format is what I call a compound value format, where the file or partition to be checked and the SHA1 digests to be compared, are all concatenated together in a single, colon-separated value. For example:
assert(apply_patch_check("EMMC:/dev/block/platform/omap/omap_hsmmc.0/by-name/boot:4247552:3f4d4f9549d307d152f8503983ee4ff5f46b0a43:4470784:fbd13c778b34fdb7917c1ccee6389aa9b13a92bd"));
In the above, I've colored the sizes in red of file/partition on which to compute the SHA1 checksum (colored in black). I figured this out and verified this by using dd to copy the portions of the partition in question and calculating the SHA1 checksums on it.
My app only supports parsing and evaluating two sets of lengths/SHA1s for the compound format at this time (that's all I've encountered so far in the scripts that I've viewed).
Does that help and/or answer your questions?
Cheers!
Thanks! Yeah that helps a lot, but unfortunately it doesn't seem to solve the problem I've been seeing..
Using dd to grab the partition img I can sha1sum that and that SHA1 doesn't allow it to pass the assert, or even a direct sha1_check of the partition.
Code:
run_program("/sbin/busybox", "dd", "if=/dev/block/platform/sdhci-tegra.3/by-name/USP"), "of=/tmp/bootloader.img")
ui_print(sha1_check(read_file("/tmp/bootloader.img"))); = 8c206a1a87599f532ce68675536f0b1546900d7a (also, bootloader.img is 2097152 in size)
ui_print(sha1_check(read_file("/dev/block/platform/sdhci-tegra.3/by-name/USP"))); = da39a3ee5e6b4b0d3255bfef95601890afd80709
assert(apply_patch_check("EMMC:/dev/block/platform/sdhci-tegra.3/by-name/USP:2097152:8c206a1a87599f532ce68675536f0b1546900d7a")); = Fail
They just don't match and I'm completely baffled by it. I can work around it by using dd to pull the img first and using that for my asserts but it's not as clean as I'd like it.
osm0sis said:
Yeah that helps but I guess unfortunately it doesn't entirely solve the problem I've been seeing.
Using dd to grab the partition img I can sha1sum that and that SHA1 doesn't allow it to pass the assert, or even a direct sha1_check of the partition.
They just don't match and I'm completely baffled by it. I can work around it by using dd to pull the img and using that for my asserts but it's not as clean as I'd like it.
Click to expand...
Click to collapse
Is it for the Gnex or the N7 (I have those same devices)?
I'd be happy to test something for you...just PM me or send me an email ([email protected]).
I don't know if you're using my app to test with, but you can also manually run the update-binary directly on/from your phone (i.e., you don't have to run it in recovery, but you obviously need to be careful what your updater-script does ).
I'm still looking for the exact syntax in my notes, but I'll edit this post when I find it...brb.
~ ~ ~
edit: http://wiki.opticaldelusion.org/wiki/Update-binary shows this:
update-binary <api> <pipefd> <zip>
Click to expand...
Click to collapse
I know I did this during my early testing, but I can't remember the exact syntax...I'll try it and re-re-edit .
Man thanks so much, PM sent.
Sorry for cluttering up your thread with this semi-OT stuff.
osm0sis said:
Man thanks so much, PM sent.
Sorry for cluttering up your thread with this semi-OT stuff.
Click to expand...
Click to collapse
LOL, not a problem...it's all Edify-related and updater-script related...I'm betting that's what'll lead most folks here.
Happy to help .
==================
Detailed Analysis
==================
- you have no frozen system apps (good!)
- there were 2 failed expressions; see below for the details about these tests that will cause your OTA install to fail
- there were no bypassed expressions (good!)
-------------------------------
statistics:
frozen system apps: 0
success count: 526
fail count: 2
ignore count: 1587
partition count: 2
protected count: 2
bypassed count: 0
-------------------------------
updater-script analysis details:
FAILED: line #268:
assert(apply_patch_check("/system/app/XT9IME.apk", "8aba56a4406128e78f5729753252c3d93bc21cb4", "965b437bce65018eeb31ff9a381c3687542099e0"));
----------------------
FAILED: line #1038:
assert(apply_patch_check("EMMC:/dev/block/platform/sdhci-tegra.3/by-name/LNX:5013504:c48f8e86c73fb2c2ba1794f5ec98e27c9e206ed5:5060608:319331fae14fec8a88063751475fce26bae328e0"));
So a question, could this failure above be causing my 32 GB nexus 7 to have system update issues? (Not necessarily XT9IME.apk (which I shouldn't have deleted), more the other one) Is there a fix?
Sent from my Nexus 7 using Tapatalk HD
---------- Post added at 10:44 AM ---------- Previous post was at 10:39 AM ----------
==================
Detailed Analysis
==================
- you have no frozen system apps (good!)
- there were 2 failed expressions; see below for the details about these tests that will cause your OTA install to fail
- there were no bypassed expressions (good!)
-------------------------------
statistics:
frozen system apps: 0
success count: 526
fail count: 2
ignore count: 1587
partition count: 2
protected count: 2
bypassed count: 0
-------------------------------
updater-script analysis details:
FAILED: line #268:
assert(apply_patch_check("/system/app/XT9IME.apk", "8aba56a4406128e78f5729753252c3d93bc21cb4", "965b437bce65018eeb31ff9a381c3687542099e0"));
----------------------
FAILED: line #1038:
assert(apply_patch_check("EMMC:/dev/block/platform/sdhci-tegra.3/by-name/LNX:5013504:c48f8e86c73fb2c2ba1794f5ec98e27c9e206ed5:5060608:319331fae14fec8a88063751475fce26bae328e0"));
Sent from my Nexus 7 using Tapatalk HD
Click to expand...
Click to collapse
So a question, could this failure above be causing my 32 GB nexus 7 to have system update issues? (Not necessarily XT9IME.apk (which I shouldn't have deleted), more the other one) Is there a fix?
modwilly said:
So a question, could this failure above be causing my 32 GB nexus 7 to have system update issues? (Not necessarily XT9IME.apk (which I shouldn't have deleted), more the other one) Is there a fix?
Click to expand...
Click to collapse
Looks like you've updated the boot (LNX) partition in addition to deleting (or renaming/moving) the XT9IMG.apk?
So yes, the OTA will not install until you've put both items back to their expected state.
The fix, of course, depends on exactly what you did to change them in the first place.
version 2.1 uploaded to Play Store
Major re-write of app done for version 2.0 and above.
Recent change log:
[version 2.1 - 6-May-2014]:
- fix issue w/identification of non-existent files
[version 2.0 - 5-May-2014]:
- major app update: edify parsing, RPN processing and execution engine completely re-written
- original core app behavior and functionality remain the same, but code cleanup and re-write should mean better and more robust handling of future OTA updater-script expressions
Click to expand...
Click to collapse
Thanks and let me know if you have any questions.
@scary alien could you please tell me how to get apply_patch_space bytes? i am making ota script and i got almost all, still need to generate:
apply_patch_space(bytes) || abort("Not enough free space on /cache to apply patches.");
Click to expand...
Click to collapse
i just dunno how
ZduneX25 said:
@scary alien could you please tell me how to get apply_patch_space bytes? i am making ota script and i got almost all, still need to generate:
i just dunno how
Click to expand...
Click to collapse
It's just the available space (in bytes) in the /cache partition that you want to make sure is available (i.e., free space) for any operations your updater-script file will do concerning /cache.
For example:
apply_patch_space(1000000) || abort("Not enough free space on /cache to apply patches.");
Click to expand...
Click to collapse
Would verify that there is at least 1MB (1,000,000) free bytes available in /cache.
Does that answer what you're asking?
Lemme know--happy to help if I can.
Cheers!
@scary alien not really, i mean i know how it works, just dunno how to generate proper size in updater, for example:
i create regular ota: multiple .p files and some images, zipped, signed OTA.zip size is 20mb, /patch size is 7 mb, images 10 mb and /system (new files) 3mb, how do i know how many bytes i should set to make this ota install in recovery?
should i summarize .p files size or target (patched apk, jar) files size (would be around 90mb) or what else?
I think the size would depend on when your patch files are cleaned-up...i.e., after each patching operation or at the end. If its at the end, you'll of course need to account to all of the space you might use in /cache.
I don't know of a good way to tell you what the high water mark would be other than testing and recording the output of a "df /cache" command at various points in your updater-script file.
I could do that however I don't see it universal or handy, each ota has different size so it would need more/less free space every time.
There is how Google gets this value : https://github.com/MiCode/patchrom_tools/blob/kitkat/releasetools/edify_generator.py#L131 maybe you will understand better.
ZduneX25 said:
I could do that however I don't see it universal or handy, each ota has different size so it would need more/less free space every time.
There is how Google gets this value : https://github.com/MiCode/patchrom_tools/blob/kitkat/releasetools/edify_generator.py#L131 maybe you will understand better.
Click to expand...
Click to collapse
I think I understood what you meant...there's no easy way to make this universal for each OTA except to evaluate each file that might need to use space resources from the /cache partition.
Even the edify-generator git that you referenced does this dynamically:
releasetools/ota_from_target_files:
Code:
for diff in diffs:
tf, sf, d = diff.GetPatch()
if d is None or len(d) > tf.size * OPTIONS.patch_threshold:
# patch is almost as big as the file; don't bother patching
tf.AddToZip(output_zip)
verbatim_targets.append((tf.name, tf.size))
else:
common.ZipWriteStr(output_zip, "patch/" + tf.name + ".p", d)
patch_list.append((tf.name, tf, sf, tf.size, common.sha1(d).hexdigest()))
[COLOR="Red"]largest_source_size[/COLOR] = max([COLOR="red"]largest_source_size[/COLOR], sf.size)
:
:
:
if patch_list or updating_recovery or updating_boot:
script.[COLOR="Blue"][B]CacheFreeSpaceCheck[/B][/COLOR]([COLOR="red"]largest_source_size[/COLOR])
I have seen it, but here comes largest_source_size:
Code:
largest_source_size = 0
https://github.com/MiCode/patchrom_tools/blob/kitkat/releasetools/ota_from_target_files#L532
ZduneX25 said:
I have seen it, but here comes largest_source_size:
Code:
largest_source_size = 0
https://github.com/MiCode/patchrom_tools/blob/kitkat/releasetools/ota_from_target_files#L532
Click to expand...
Click to collapse
Yeah, that's just the initialization of that variable...it gets updated in the for-loop that I included above.
(you know that's not my tool, software, right?)
[HUAWEI WATCH 2 (LTE/4G-Sawshark) & (Bluetooth/BT-Sawfish)-OWDE.180926.001.A1]INTERNATIONAL VERSION
Please read the instructions and notes before flashing anything. Don't ask me if you don't read the instructions.
Code:
###Disclaimer###
[COLOR="Red"][B]WARNING:
IMPROPER FLASHING MAY POTENTIALLY BRICK YOUR DEVICE. SO PLEASE PROCEED AT YOUR OWN RISK. ME OR ANY OTHER DEVELOPER MENTIONED IN THIS POST WILL ASSUME NO RESPONSIBILITY FOR THIS.[/B][/COLOR]
DONATE ME HERE
DONATE-ME
##############################
REQUIREMENT
##############################
- An Unlock bootloader
- Working adb/fastboot and driver - Download from Here
- A custom recovery (twrp) See my twrp thread for custom twrp recovery
TWRP-RECOVERY
##############################
HOW TO FLASH KERNEL/BOOT IMAGE
##############################
- Steps via adb/fastboot
- Unzip the folder and move the boot image into your adb/fastboot folder and apply the following commands
Code:
- adb devices
- adb reboot bootloader
- fastboot flash boot boot.img
- fastboot reboot
##############################
HOW TO FLASH THE ROM AND ROOT
##############################
1- Move the build/ROM and Busybox and Magisk to your watch
2- Make a backup - there's always 1% chance something goes wrong.
3- Full wipe is recommended....Wipe data/Factory reset
4- Flash the ROM, then flash Busybox and Magisk (Please flash in this order, ROM, then Busybox and Magisk)
5- Reboot and complete your initial setting
6- Open Magisk Manager and go to settings and set Automatic Response to Grant
7- Done. Don't forget to donate if you like my work, Thanks.
##############################
ROM AND KERNEL FEATURES [22-Jan-2020]
##############################
[Changelog]-Huawei Watch 2 LTE(Sawshark)+Huawei Watch 2 BT(Sawfish)-[22/Jan/2019]
- Based on latest kernel source (-Source 3.18.24) android-wear with latest security patch
- Linux version 3.18.24 (gcc version 4.9.3 20141215 (prerelease) (UBER-SaberMod-4.9.3_arm-graphite)) #1 SMP PREEMPT Wed Jan 22 9:45:39 CET 2020
- Forced-encryption disabled
- dm-verity removed/disabled
- Auto memory killer set to default
- Sepolicy is patched
- Fix the CPU idle latency unvote timeout. It should reduce the wasting power and CPU go to deep idle states immediately after a request
- Add and use a timer frequency of 100 Hz. It should improve power consumption.
- Add and update/Hide verifiedbootstate from /proc/cmdline in order to fix the failed SafetyNet CTS check(It can still fail through other means)-GOOGLE PAY SHOULD WORK. USE MAGISK TO HIDE ROOT. U may need Gpay enabler
- Remove verifiedbootstate flag from /proc/cmdline - Disable CRC check
- Scheduler optimize/support for heterogeneous multi-core
- Scheduler support for heterogeneous multi-processor systems
- Enable all core with scaling_available_frequencies (200000 400000 533333 800000 1094400 1267200 MHz)- scaling down the frequency of the CPUs to 200 MHz during idl mode and rise the freq. to 1.26Ghz during high pressure.
- Set swappiness to 60
- Change zswap max pool % to 20%. It will reduce CPU usage a lot
- Enable zram & zswap and add 256MB virtual memory default. It will speed up the device a lot
- Removed nolog usage, remove rtb logging from the kernel
- Remove selinux auditing from kernel for lower overhead
- Remove IPC logging from the kernel
- Disabled some kernel parameter to speed up the performance- at the cost of battery/ power consumption
- Remove some logging from several drivers
- Improve memory allocations -Should improve the device a lot
- Add some tweaks to improve the overall speed, apps startup are too faster
- Set zswap compressor to lz4 by default
- APM driver updated again to reduce battery usage during sleeping
- Several other patches to reduce battery usage
- Multi-core scheduler enable/optimized
- APM driver updated reduce battery usage during sleeping
- Fix the wake up time. The screen should wake up more quickly when pressing the button.
- Tweaked the scheduler to reduce/save power by scaling down the frequency of the CPUs or idling them,
- A lot subsystems converted to use power efficient workqueue
- The watch goes to sleep during no action in order to save battery
- Remove debug event logging-Kill the useless logging to reduce overhead
- Remove sync debug entirely to cut down CPU waste in the frame render hot path
- Remove 10 ms CPU idle latency unvote timeout- Doesn't force the CPU to stay out of deep idle states for far longer than necessary, which wastes power
- Disable audit support, usually comes with a measurably significant amount of overhead
- Remove audit dependency
NOTE: THERE IS NO NEED TO FLASH THE LATEST KERNEL IF YOU FLASH THE LATEST ROM.
##############################
DOWNLOAD
##############################
[Huawei Watch 2 4G/LTE]+[Huawei Watch BT][22-Jan]
[DECRYPTION KEY]
WO0FVexxQnrtcODYdmNvnQ
##############################
MAGISK/BUSYBOX/APP-KERNEL-CONTROL
##############################
DOWNLOAD LATEST MAGISK FROM HERE
DOWNLOAD LATEST BUSYBOX FROM HERE
KERNEL CONTROL APP WEAR OS
##############################
How to get the Gpay back...
##############################
1-https://pastebin.com/HKV7cj7H
2-https://forum.xda-developers.com/smartwatch/other-smartwatches/rom-kernel-t3821013/page172
3-https://www.youtube.com/watch?v=UKxGfNxRjo4&t=320s
4-https://forum.xda-developers.com/showpost.php?p=79637148&postcount=1720
##############################
HOW TO FLASH THE STOCK IMAGES-(BACK TO STOCK)
##############################
1- Download and unzip the system image below
2- Attach the watch charger to the watch and plug the USB cord (from the charger) into your computer
3- Use the following adb command to start the watch in fastboot mode: adb reboot bootloader
4- On your computer, navigate to the directory where you unzipped the system image in Step 1. At the top level of that directory, execute the flash-all script:
- On Linux or MacOS, type ./flash-all.sh
- On Windows, type flash-all.bat
5 -DONE. Don't forget to donate if you like my work, Thanks.
STOCK-IMAGES-HUAWEI-WATCH-2-LTE-LEO-DLXX-OWDE.180215.017-SAWSHARK-(13/Oct/2018)
STOCK-IMAGES-HUAWEI-WATCH-2-BT-LEO-BX9-OWDD.180215.018-SAWFISH-(22/7/2018)
##############################
Source/GitHub
##############################
-Source
IF YOU LIKE MY WORK AND WANT ME TO CONTINUE, THEN BUY ME A SHOT OF WHISKY
DONATE ME HERE
DONATE-HERE
Special thanks to:
If you can, donate and respect all the devs and enjoy
@Chainfire for great work in android
@Maxr1998 Big thanks for giving me knowledge and your great work for Asus Zenwatch_3 and your great github guide. Please thank and donate him for all his efforts
@topjohnwu for his great effort (Magisk)Thank you so much
@SuperR.R for the great kitchen
@Xmaster24 for system-less root-
@moneytoo for his great app. Please appreciate and donate him
Pay Enabler
@SuperThomasLab for great tools
Please always support devs and others (soon).
ROM download asking for decryption key?Can fix the link?
Hello All,
Is it possible to install this latest ROM on model without LTE?
Thank you for reply :good:
arthos7 said:
ROM download asking for decryption key?Can fix the link?
Click to expand...
Click to collapse
Hoffmanns said:
Hello All,
Is it possible to install this latest ROM on model without LTE?
Thank you for reply :good:
Click to expand...
Click to collapse
Link are fixed now. It will properly not gonna work on non-lte. I can build a new for non-lte version if some one send me the latest system image and boot image. (I can extract from your watch via teamviewer, in case you can't) But you need to flash the latest firmware without root.
IF YOU LIKE MY WORK AND WANT ME TO CONTINUE, THEN BUY ME A SHOT OF WHISKY
DONATE ME HERE
I will upload a complete latest stock images N7176C (lte) incase anyone wanna go back to latest stock again.
The only thing you have to do is boot into bootloader mod and then run the script by double click on it. After some reboots you will be back on latest stock.
I will combine both Linux and Windows together, use one you prefer.
IF YOU LIKE MY WORK AND WANT ME TO CONTINUE, THEN BUY ME A SHOT OF WHISKY
DONATE ME HERE
Just received my Huawei SW 4G this weekend and after installing Huawei wear I got the alert message that the watch was rooted.
How can I confirm is it's rooted or not.
Thanks
Sent from my ONEPLUS A3003 using Tapatalk
Can anyone who's used this verify that it's notably faster or has improved battery life compared to stock? Or is the difference negligible?
How to build boot.img
Hi Janjan,
I am trying to build a custom kernel for my Huawei Watch 2 (non LTE) and I was wondering if you could share a little of your development work.
How do you actually put the boot image together? I am able to compile the kernel from android-msm-sawshark-3.18-nougat-mr1-wear-release,
which gives me a zImage. I also have the original images. So I tried to unmkbootimg the original boot image and replace the kernel. However, this doesn't seem to work. when I compare the sizes of the supposedly original zImage and the one created from the repository above, their size differs by roughly a factor of 100. So there must be something seriously wrong
What steps do you use to create the kernel and the boot image?
I also checked your github code and tried to use it but it seems to depend on other stuff that is not in your repos. Where did you find the code you have in your repos?
Best regards,
Mogli
janjan said:
I can build a new for non-lte version if some one send me the latest system image and boot image. (I can extract from your watch via teamviewer, in case you can't) But you need to flash the latest firmware without root.
Click to expand...
Click to collapse
Does that offer still stand? If yes I am willing to let my watch be used as a test subject.
mogli19 said:
Hi Janjan,
I am trying to build a custom kernel for my Huawei Watch 2 (non LTE) and I was wondering if you could share a little of your development work.
How do you actually put the boot image together? I am able to compile the kernel from android-msm-sawshark-3.18-nougat-mr1-wear-release,
which gives me a zImage. I also have the original images. So I tried to unmkbootimg the original boot image and replace the kernel. However, this doesn't seem to work. when I compare the sizes of the supposedly original zImage and the one created from the repository above, their size differs by roughly a factor of 100. So there must be something seriously wrong
What steps do you use to create the kernel and the boot image?
I also checked your github code and tried to use it but it seems to depend on other stuff that is not in your repos. Where did you find the code you have in your repos?
Best regards,
Mogli
Click to expand...
Click to collapse
Sure, tell me what you did and your steps for building zImage + modul. I am away from my office for a while.
janjan, have you had success with making a non-lte version?
cdkg said:
janjan, have you had success with making a non-lte version?
Click to expand...
Click to collapse
If you send me the latest boot.img, system.img and vendor.img then I will definitely make.
janjan said:
If you send me the latest boot.img, system.img and vendor.img then I will definitely make.
Click to expand...
Click to collapse
I have the boot.img and system.img. Is there a tutorial or any instructions you could give on how to get the vendor.img?
janjan said:
Sure, tell me what you did and your steps for building zImage + modul. I am away from my office for a while.
Click to expand...
Click to collapse
Hi Janjan,
(Apparently I am not allowed to post links yet, so I am trying my best to explain without them)
1. I got the source code for the Sawshark watch from github (mr1-wear-release). I guess there is no dedicated Seafish kernel source. Short question: There is a choice of 3 different kernel codes. Which one shall I take?
2. I tried to compile this source code without changes (to rule out errors before I make modifications). This works and I get as zImage. What do you mean by modul though? I thought zImage was the only product.
3. Using unmkbootimg, I un-packed an stock boot.img. The unmkbootimg tool says that the boot.img has been compiled with a non-standard mkbootimg program. However the offsets and other values (I am supposed to tune when I use mkbootimg) are contradicting. Eventually, the "non-custom" values recommended by unmkbootimg caused errors in mkbootimg and I ended up using the default values. This worked.
4. When I flash the resulting boot.img my watch gets stuck during boot with the Huawei logo on all the time.
To verify my tools, I tried step 3. in two more ways:
3.1. re-pack the un-packed boot.img, flash it (no errors and boot works)
3.2 pack a boot.img using a zImage obtained from a sawshark boot.img (instead of the seafish). This also worked and boot was successful
I have also looked at the boot.img and zImage files in a hex editor. I can locate the beginning of the kernel but not the end. Also if I did, I wouldn't know how to replace the kernel in hex mode But from what I have understood about mkbootimg, this script does not much more than concatenate zImage and ramdisk and add a header. Is this somewhat correct?
Eventually, I need to turn on some currently disabled kernel features (which is why I am doing all of this ). So I am still trying to figure out the right tools and components. And therefore the question: How do you usually build the kernel and how do you pack it into the boot.img. Do you modify the ramdisk when you replace the kernel?
Best,
Mogli
Instructions to modify ramdisk
Hi Janjan,
How do you disassemble and re-assemble the ramdisk?
Wanted to make a few modifications to the ramdisk.cpio.gz. Again, I wanted to try the tools first. So I unpacked and re-packaged the ramdisk without modifications. After flashing the regenerated boot image, my watch goes into recovery mode...
I found these instructions in a tutorial (again, I can't post links yet... sorry):
For disassembly:
Code:
$ mkdir ramdisk_dir
$ cd ramdisk_dir
$ gunzip -c ../ramdisk.cpio.gz | cpio -i
for re-assembly
Code:
$ find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz
Update to my previous post:
I found my mistake in building the kernel:
Instead of using
Code:
make ARCH=arm CROSS_COMPILE=arm-linux-androidkernel-
I was using
Code:
make ARCH=arm CROSS_COMPILE=arm-linux-androideabi-
mogli19 said:
Hi Janjan,
How do you disassemble and re-assemble the ramdisk?
Wanted to make a few modifications to the ramdisk.cpio.gz. Again, I wanted to try the tools first. So I unpacked and re-packaged the ramdisk without modifications. After flashing the regenerated boot image, my watch goes into recovery mode...
I found these instructions in a tutorial (again, I can't post links yet... sorry):
For disassembly:
for re-assembly
Update to my previous post:
I found my mistake in building the kernel:
Instead of using
I was using
Click to expand...
Click to collapse
It seems much better now. Are you in Windows or Linux? I will post my script and tools once I reach my PC. I am away from my PC right now. It means you destroy something during generating or packaging the boot image. Does you kernel /boot.img work without or before editing the ramdisk?
Update:- seems you are in Linux.
janjan said:
It seems much better now. Are you in Windows or Linux? I will post my script and tools once I reach my PC. I am away from my PC right now. It means you destroy something during generating or packaging the boot image. Does you kernel /boot.img work without or before editing the ramdisk?
Update:- seems you are in Linux.
Click to expand...
Click to collapse
Yes, I am on linux. I found a different approach that works for me now:
Code:
Extract the ramdisk.
$ mkdir ramdisk
$ cd ramdisk
$ gzip -dc ../ramdisk.cpio.gz | cpio -i
# Make any changes necessary (e.g., set ro.secure=0 in default.prop).
# Recreate the cpio archive using the mkbootfs binary produced from building the Android source code
$ cd ..
$ mkbootfs ./ramdisk | gzip > ramdisk-new.gz
You said you were able to turn on all the cores. Can this be done by modifying the ramdisk or how do you do this?
mogli19 said:
Yes, I am on linux. I found a different approach that works for me now:
You said you were able to turn on all the cores. Can this be done by modifying the ramdisk or how do you do this?
Click to expand...
Click to collapse
Did I said? But It can't be done by editing the ramdisk only. You need to add and edit alot (add driver edit cores etc) in kernel sources.
Okay, before anyone flames, I did look everywhere in this thread and cannot find it. Does anyone have the link to the flashing instructions for this rom?
janjan said:
Did I said? But It can't be done by editing the ramdisk only. You need to add and edit alot (add driver edit cores etc) in kernel sources.
Click to expand...
Click to collapse
Oh sorry, I thought I had read this on your feature list I actually looked at this and asked myself if there was a way to make the cpu settings permanent:
https://stackoverflow.com/questions/20221680/android-how-to-force-cpu-core-offlineshut-down-cores
I currently have a phone (Lenovo P2) that is soft bricked and I found this post from XDA which I will try: https://forum.xda-developers.com/t/tool-unbrick-reset-fix-for-bad-signal-stock-firmware.3859402/
Would it delete everything including /storage/emulated/0? I don't care if data from my apps are gone but I don't want the personal files to be gone. If there is no other way though I guess I will have to do it.
Look inside the file flashall - stock reco.bat - that comes with the tool linked to - to see what gets wiped / deleted and what not.
It says it is flashing userdata i think, i don't understand much but I attached the file.
Edit: I can't get it to attach the file here so I uploaded to Google Drive: https://drive.google.com/file/d/1WCNhfHWVUURXQQYqZUtw3CwLlER3oHtM/view?usp=sharing
xberkayx said:
It says it is flashing userdata i think, i don't understand much but I attached the file.
Click to expand...
Click to collapse
You are wrong: whether userdata get erased / flashed or not can be set by you
Code:
::
:: command line options to override the defaults
:: useful for factory software preparation
::
SET flash_userdata=1
SET erase_userdata=0
SET erase_cache=0
SET para_flash=1
SET serial_number=
SET device_list=
SET device_count=0
SET opts=
SET flash_script=%0
SET is_device_in_productlist=0
SET no_reboot=0
SET flash_persist=0
SET flash_preload=1
SET flash_gpt=1
Have the .BAT file attached ( as .TXT-file )
jwoegerbauer said:
You are wrong: whether userdata get erased / flashed or not can be set by you
Code:
::
:: command line options to override the defaults
:: useful for factory software preparation
::
SET flash_userdata=1
SET erase_userdata=0
SET erase_cache=0
SET para_flash=1
SET serial_number=
SET device_list=
SET device_count=0
SET opts=
SET flash_script=%0
SET is_device_in_productlist=0
SET no_reboot=0
SET flash_persist=0
SET flash_preload=1
SET flash_gpt=1
Have the .BAT file attached ( as .TXT-file )
Click to expand...
Click to collapse
You mean I should set flash_userdata to 0? And I tried attaching it as txt, it still didn't work.