Would this be a possible solution to our kernel flashing problems, I know it works for the evo
Sent from my HTC Amaze 4G using XDA App
DEFINITIONOFREAL said:
Would this be a possible solution to our kernel flashing problems, I know it works for the evo
Sent from my HTC Amaze 4G using XDA App
Click to expand...
Click to collapse
It's possible. In fact I mentioned this about a month ago to a developer.
I would like to see one that has a couple of options such as flashing recovery and flashing boot.img files.
You can easy push the flash_image binary to /system/bin and set the permission to 755. In fact my CWMFaux kernel does just that. Faux stopped using it because it doesn't always work.
In fact I made it so easy that all you need to do is push the boot.img to /system and reboot. Yet... no one uses it. In fact I suggested to a couple of rom developers to simply add the binary file to /system/bin so that you can at least run the command from terminal but they don't even want to do that. I like being able to update my recovery at anytime by entering "flash_image recovery /sdcard/recovery.img" and then just rebooting to recovery. You can easily do that for kernels too. But I suppose it's so much easier to carry a computer around.
Binary100100 said:
It's possible. In fact I mentioned this about a month ago to a developer.
I would like to see one that has a couple of options such as flashing recovery and flashing boot.img files.
You can easy push the flash_image binary to /system/bin and set the permission to 755. In fact my CWMFaux kernel does just that. Faux stopped using it because it doesn't always work.
In fact I made it so easy that all you need to do is push the boot.img to /system and reboot. Yet... no one uses it. In fact I suggested to a couple of rom developers to simply add the binary file to /system/bin so that you can at least run the command from terminal but they don't even want to do that. I like being able to update my recovery at anytime by entering "flash_image recovery /sdcard/recovery.img" and then just rebooting to recovery. You can easily do that for kernels too. But I suppose it's so much easier to carry a computer around.
Click to expand...
Click to collapse
Im going to contact joeykrim and see if I can get him to add support in his app, and Ive been using your method since I got the phone (2 days ago) and started reading, but still a little hassle, and a big htc fail
Sent from my HTC Amaze 4G using XDA App
DEFINITIONOFREAL said:
Im going to contact joeykrim and see if I can get him to add support in his app, and Ive been using your method since I got the phone (2 days ago) and started reading, but still a little hassle, and a big htc fail
Sent from my HTC Amaze 4G using XDA App
Click to expand...
Click to collapse
Keep me posted will ya?
I believe that Faux and other developers would have to use the zImage kernel flashing technique to get it to work with his existing app but I'm sure he can simplify it to accept .img files and the .ko files in the /system/lib directory of a zip file. It actually should be very easy. It took me about ten mintues with testing included to create the script for my method. I just can't code for apps else it would be done by now.
DEFINITIONOFREAL said:
Im going to contact joeykrim and see if I can get him to add support in his app, and Ive been using your method since I got the phone (2 days ago) and started reading, but still a little hassle, and a big htc fail
Sent from my HTC Amaze 4G using XDA App
Click to expand...
Click to collapse
I contacted pershoot, no answer lol!!!
Joeykrim is willing to support the Amaze, he just needs testers, this would be a great backup incase the new script failed to push the kernel. I'll keep everyone posted with updates
Sent from my HTC Amaze 4G using XDA App
I've been working with joeykrim getting his app setup for our device, it looks like it should work, hopefully, within the next couple of days we can get this working and released
Sent from my HTC Amaze 4G using XDA App
DEFINITIONOFREAL said:
I've been working with joeykrim getting his app setup for our device, it looks like it should work, hopefully, within the next couple of days we can get this working and released
Sent from my HTC Amaze 4G using XDA App
Click to expand...
Click to collapse
That would be wonderful!
I'm tired of having to repeat myself.
flash_image boot /sdcard/boot.img
flash_image recovery /sdcard/recovery.img
Binary100100 said:
That would be wonderful!
I'm tired of having to repeat myself.
flash_image boot /sdcard/boot.img
flash_image recovery /sdcard/recovery.img
Click to expand...
Click to collapse
I just wish the devs would use your script, it would make things so much easier
Sent from my HTC Amaze 4G using XDA App
DEFINITIONOFREAL said:
I just wish the devs would use your script, it would make things so much easier
Sent from my HTC Amaze 4G using XDA App
Click to expand...
Click to collapse
Once I see that they do I can work out something else like:
kernelupdate
recoveryupdate
kernelupdate would be
flash_image boot /sdcard/kernel/*boot*.img
recoveryupdate would be
flash_image recovery /sdcard/recovery/*recovery*.img
So that if you place ANY of the appropriate img file in the perspective folders on the sdcard partition it would flash the .img by just entering either of the two commands from adb shell or terminal.
But I'm not going to waste my time if the devs don't want to use it.
Binary100100 said:
Once I see that they do I can work out something else like:
kernelupdate
recoveryupdate
kernelupdate would be
flash_image boot /sdcard/kernel/*boot*.img
recoveryupdate would be
flash_image recovery /sdcard/recovery/*recovery*.img
So that if you place ANY of the appropriate img file in the perspective folders on the sdcard partition it would flash the .img by just entering either of the two commands from adb shell or terminal.
But I'm not going to waste my time if the devs don't want to use it.
Click to expand...
Click to collapse
could a script be written to automatically flash these while installing/flashing the custom rom? This would cut down atleast the step for flashing kernels for a lot of noobs!!
seansk said:
could a script be written to automatically flash these while installing/flashing the custom rom? This would cut down atleast the step for flashing kernels for a lot of noobs!!
Click to expand...
Click to collapse
Actually, yes! I did add it to the init.d script but since xboarder had removed the init.d scripts from his rom it doesn't work anymore. But you sure could. It was basically how I was setting up my CWMFaux kernels. However it didn't seem to work 100% of the time. Couldn't figure out why.
It basically worked like this...
Flashing the CWM custom kernel .zip via recovery.
copies boot.img to /system
copies init.d 06tweaks script to init.d folder.
copies and set permissions for flash_image binary and kernelupdate script to /system/bin directory.
You then boot your phone up which triggers the init.d script which commands the kernelupdate script to initiate. The kernel update script is simply using the flash_image binary command "flash_image boot /system/boot.img" and it automatically updates the kernel. Then the init.d script removes the boot.img file from the /system directory to keep it from flashing upon every boot.
I would like to change it to /sdcard directory but there's the problem that the sdcard doesn't get mounted until the very end. WAY after the system. Which is why I stored it there. The system gets mounted even before the data partition so I couldn't even store the file in data because the script would run even before the data partition could mount. Basically the script is initiated while your still looking at the boot animation. Pretty much when your softkey backlights and led light comes on it flashes the new kernel. It's a pretty neat workaround if I must say but unfortunately nowhere near perfect and not even close to having an s-off workaround.
Now if you don't mind the fact that it won't be initiated upon boot I could make it so that it will flash any file in a perspective folder on the sdcard.
example:
kernelupdate would update the kernel with any *boot*.img file located in a certain directory... say /sdcard/kernel
recoveryupdate would update the recovery with any *recovery*.img file located in a certain directory... say /sdcard/recovery
The problem:
Some people would want to collect their kernels and recoveries and store them in those directories. That would NOT be possible since using the command "flash_image recovery /sdcard/*recovery*.img would flash any img file with the word "recovery" in it. So if there's more than one it would error out and not flash anything because of the conflict. Same principal with the kernel only MOST kernels are simply named "boot.img" where-as almost all recovery files have a unique name since they are all already custom.
Binary100100 said:
Actually, yes! I did add it to the init.d script but since xboarder had removed the init.d scripts from his rom it doesn't work anymore. But you sure could. It was basically how I was setting up my CWMFaux kernels. However it didn't seem to work 100% of the time. Couldn't figure out why.
It basically worked like this...
Flashing the CWM custom kernel .zip via recovery.
copies boot.img to /system
copies init.d 06tweaks script to init.d folder.
copies and set permissions for flash_image binary and kernelupdate script to /system/bin directory.
You then boot your phone up which triggers the init.d script which commands the kernelupdate script to initiate. The kernel update script is simply using the flash_image binary command "flash_image boot /system/boot.img" and it automatically updates the kernel. Then the init.d script removes the boot.img file from the /system directory to keep it from flashing upon every boot.
I would like to change it to /sdcard directory but there's the problem that the sdcard doesn't get mounted until the very end. WAY after the system. Which is why I stored it there. The system gets mounted even before the data partition so I couldn't even store the file in data because the script would run even before the data partition could mount. Basically the script is initiated while your still looking at the boot animation. Pretty much when your softkey backlights and led light comes on it flashes the new kernel. It's a pretty neat workaround if I must say but unfortunately nowhere near perfect and not even close to having an s-off workaround.
Now if you don't mind the fact that it won't be initiated upon boot I could make it so that it will flash any file in a perspective folder on the sdcard.
example:
kernelupdate would update the kernel with any *boot*.img file located in a certain directory... say /sdcard/kernel
recoveryupdate would update the recovery with any *recovery*.img file located in a certain directory... say /sdcard/recovery
The problem:
Some people would want to collect their kernels and recoveries and store them in those directories. That would NOT be possible since using the command "flash_image recovery /sdcard/*recovery*.img would flash any img file with the word "recovery" in it. So if there's more than one it would error out and not flash anything because of the conflict. Same principal with the kernel only MOST kernels are simply named "boot.img" where-as almost all recovery files have a unique name since they are all already custom.
Click to expand...
Click to collapse
quite a dilemma, I wonder if we could add pause to the script until everything is loaded on the first boot then after the pause the script flahes the recovery and more importantly the kernel!!! if this was possible we could keep the files in a separate place on the SD card.
Still nothing like S-off!!! Thanks HTC for being so dev friendly
seansk said:
quite a dilemma, I wonder if we could add pause to the script until everything is loaded on the first boot then after the pause the script flahes the recovery and more importantly the kernel!!! if this was possible we could keep the files in a separate place on the SD card.
Still nothing like S-off!!! Thanks HTC for being so dev friendly
Click to expand...
Click to collapse
I'm sure there's a way to add a delay timer of some sort. I'm just not that savvy. Easiest way would be through an app like Tasker.
DEFINITIONOFREAL said:
Would this be a possible solution to our kernel flashing problems, I know it works for the evo
Sent from my HTC Amaze 4G using XDA App
Click to expand...
Click to collapse
The short answer is yes!
I've setup the application to support the HTC Amaze 4G, but before I release it publically and officially, I want to have a few testers confirm everything is working properly for them.
Posted all the information in a new thread as this one seems to be covering a few different topics so I didn't want to "hijack".
http://forum.xda-developers.com/showthread.php?p=21574722
Thanks for the request and for reaching out to me DEFINITIONOFREAL.
Binary100100 said:
Once I see that they do I can work out something else like:
kernelupdate
recoveryupdate
kernelupdate would be
flash_image boot /sdcard/kernel/*boot*.img
recoveryupdate would be
flash_image recovery /sdcard/recovery/*recovery*.img
So that if you place ANY of the appropriate img file in the perspective folders on the sdcard partition it would flash the .img by just entering either of the two commands from adb shell or terminal.
But I'm not going to waste my time if the devs don't want to use it.
Click to expand...
Click to collapse
I think my application, Flash Image GUI, will be the best alternative, but of course I have a biased opinion!
Regarding alternatives, I think a simple sh script which takes an argument would make a nice wrapper. The argument would be location to the image file to flash. The script could either bundle the flash_image binary or take the location of it as another argument.
All depends on how the developers want to create some type of standard. Which is another great reason Flash Image GUI will work well as it contains everything required and doesn't rely on developers providing support in their ROM, only relys on developers following the standards for ROMs and kernel .zip files.
Also, in looking through some of the custom ROMs and kernel .zip files for this device, I notice one of the custom kernels does something similar to the suggestions above, it executes a file located in /system/etc/init.d on every boot which automatically flashes /system/boot.img file.
At first glance I was horrified to see this as this is a *major* security issue. If anybody were to place any type of file in /system/boot.img, either a rogue kernel or just a blank file, the script automatically flashed it on boot w/o any type of file verification or user notification!
Wanted to get that off my chest and discourage the use of *automatic* loading of any type of major file, such as kernel or recovery image, especially without at least file verification or user approval/notification.
I'll try and keep up with the thread and help contribute ideas to alternatives for anybody who wants to develop/implement! Great ideas in the thread and always enjoy reading community collaboration efforts, especially in resolution to manufacturer "adjustments" of standards.
ugh, sorry about the double post (too excited for being too early in the morning). if a moderator wants to combine my last two posts, please do. i dont have access to delete a post.
joeykrim said:
I think my application, Flash Image GUI, will be the best alternative, but of course I have a biased opinion!
Regarding alternatives, I think a simple sh script which takes an argument would make a nice wrapper. The argument would be location to the image file to flash. The script could either bundle the flash_image binary or take the location of it as another argument.
All depends on how the developers want to create some type of standard. Which is another great reason Flash Image GUI will work well as it contains everything required and doesn't rely on developers providing support in their ROM, only relys on developers following the standards for ROMs and kernel .zip files.
Also, in looking through some of the custom ROMs and kernel .zip files for this device, I notice one of the custom kernels does something similar to the suggestions above, it executes a file located in /system/etc/init.d on every boot which automatically flashes /system/boot.img file.
At first glance I was horrified to see this as this is a *major* security issue. If anybody were to place any type of file in /system/boot.img, either a rogue kernel or just a blank file, the script automatically flashed it on boot w/o any type of file verification or user notification!
Wanted to get that off my chest and discourage the use of *automatic* loading of any type of major file, such as kernel or recovery image, especially without at least file verification or user approval/notification.
I'll try and keep up with the thread and help contribute ideas to alternatives for anybody who wants to develop/implement! Great ideas in the thread and always enjoy reading community collaboration efforts, especially in resolution to manufacturer "adjustments" of standards.
ugh, sorry about the double post (too excited for being too early in the morning). if a moderator wants to combine my last two posts, please do. i dont have access to delete a post.
Click to expand...
Click to collapse
I look forward to tryin out your app.
It was basically what this thread was all about in the first place.
The clockwork method that you mentioned is the only workaround that I was able to come up with for custom kernels (like Faux123) because a kernel cannot be flashed through recovery without s-off. Really stupid. So I started thinking "How can we flash a boot.img file from recovery without the typical means?" Then came up with the solution to flash_image the boot.img file automatically IF the file is detected. But how to start a script automatically upon boot? init.d is the only way I could think of. Okay... so where to put the boot? I tried the sdcard but it failed to mount until it was way too late. So... data. Nope... still didn't mount in time. Cache? Well... how many developers will include a cache file into their roms? So the only other option was /system and it seemed convenient since /system mounts BEFORE the script can run (obviously) so that's why it is as it is. I also figured "If someone wants to flash a new kernel all they need to do is push the boot.img to /system and reboot." Must easier than using the EKF method (requiring PC access) and I don't know about you but I'm not around a computer 24/7.
Phone is a Star X19i
Now I'm looking at getting a system to allow me to back up the rom and re-flash if needed.
Post 4 has attachments of my boot, recovery and scatter files.
Old issue: (Solved)
Stupid thing I did I renamed the mtklockscreen.odex to mtklockscreen.odex1 just as a test in a half asleep phase to see if I would get the stock lockscreen loading.
Suffice to say the phone no longer boots.
Really don't think I can get into ADB and rename the file to get the phone booting again unless anyone knows a way.
Android was 2.3.6 and I asked the seller if it was possible to get the rom incase anything like happened which they didn't.
So anyone have any ideas?
I have attached the stock recovery and boot images made with cat and a scatter file I made to post 4.
As I have no idea about modifying these for hard root can anyone take a look?
I don't know the specifics of the phone, but if you can go into recovery mode maybe you can get adb working, or use a flashable zip to rename the file by installing it from recovery (just need to edit the zips' updater script)
dxppxd said:
I don't know the specifics of the phone, but if you can go into recovery mode maybe you can get adb working, or use a flashable zip to rename the file by installing it from recovery (just need to edit the zips' updater script)
Click to expand...
Click to collapse
I got into built in Factory mode and can see the file I renamed through ADB and android commander but cannot rename it back due to not having hard root access.
I also have a copy of the boot and recovery partitions 5 and 6 respectively I made in the adb shell yesterday as I was half looking at getting hard root access.
ren mtklockscreen.odex1 mtklockscreen.odex
ren: permission denied
I read you can do a custom recovery with root using SP Tools still so can anyone help me do this?
I know about system root etc and stuff and have flashed roms before on other tablets and have been a PC I.T tech (wouldn't think it due to the stupid mistake) but this recovery and scatter files etc is kinda new to me.
I have a scatter file now I just made if anyone is interested in helping me.
Yes I have a MTK6573 but the scatter file came from the MT6516 Rom Studio which I read works the same for the 6573.
Attached is also my stock boot and recovery partitions I made with cat yesterday if there usable to anyone to help.
Well I got it working and fixed.
I had to go into adb shell and su and mount the file system as writable, as I have used linux before I didn't know about android and what needed to be done and permission locks etc.
The stock boot, recovery and scatter files will remain on this thread if anyone wants to help create or find a recovery which can allow me to create backups and flash custom roms.
I may be able to provide a dump of android 2.3.6 for those that want it once I'm provided with a backup solution as I have read a few people wanting this updated android rom.
This got too close to what I would like liked with bricking this phone.
And I'm not comfortable unless I have a rom backup of this.
Rooting Advice: For anyone with a MTK6573 on Android 2.3.6 trying to root but having issues with super one click make sure you only turn on USB debugging after Android has loaded and just before you plug the usb cable in to run super one click.
I have seen a few thread and posters here about not being able to root the phone and this is the cause that debug needs to be switched on right before you connect and try to root.
Original seller has agreed to send the firmware and flashing stuff on cd for me so I can upload it for you all.
This is a win for MTK6573 Star X19i owners as I'll have the updated 2.3.6 Gingerbread firmware to release for you all root modify etc in a week or so.
Be careful with ROM studio. I believe it is not compatible with MT6573.
You want to read this: http://bm-smartphone-reviews.blogspot.com/2012_04_01_archive.html
cybermaus said:
Be careful with ROM studio. I believe it is not compatible with MT6573.
You want to read this: http://bm-smartphone-reviews.blogspot.com/2012_04_01_archive.html
Click to expand...
Click to collapse
That's what I read and did to get my scatter as I used cat then used the program linked in that thread to generate the scatter.
Dear Admins,
Could we get a forum setup for the Cube U27GT WiFi version? I dug around on the site a bit beforehand but didn't see one, I apologize if I missed it and please direct me there if I did.
I have this tablet and I am doing some initial basic firmware development for it and want a proper place to start putting threads.
Dear Dev Community,
I can't root this bloody thing... At least, not the rom itself. Let me explain...
I can flash the stock rom from Cube and that can be rooted using Kango Root. --Fine...
However, I can't figure out how to replicate this when I make my own rom.
Thus far, here is what I have attempted...
1. Setup dsixda's excellent kitchen on my Ubuntu workstation.
2. Unpack the rom, clean things up, manually put the boot image into the dsixda unpacked working rom folder, run dsixda's root functionality (which add SU binary to xbin and SuperSu apk file to app folder as well as do some things with the boot image file).
3. Rather than using repack with Dsixda (which makes an update.zip image which I can't use because the stock recovery environment on this device can't flash zip update files and I can't for the life of me figure out how to get and or make a working CWM or TWRP recovery image for this unit)...
4. What I do is I run commands in linux to unpack the stock rom to another directory and mount that directory, then clear out a bunch of folders and then manually copy in my files from dsixda's working folder, then repackage up my unpacked stock rom into a new system.img file.
5. Then copy my now modified boot image, system image, and also userdata image (I modify that as well as that is where most all of the chinese bloatware is loaded from) to my SP_Flash_Tool, generate new checksum.ini file and flash normally...
What I get as a result...
1. As long as I am really careful with how I copy files into my new image, the new system flashes okay (if I am not careful, after flash USB storage for some reason has a format error and the system will boot but can't mount USB storage and other odd issues ensue as a result).
2. Assuming everything flashes okay, and no issue with USB storage partition, I have SuperSU installed and when I go to use an app (ES File Explorer or Root Checker) that require's root, I do get the prompt. However none of the root functions actually work and Root Checker tells me I am not rooted.
That is as far as I have got. So as a result, I have a really nice, westernized, cleaned up rom but with no root.
Anyone have any ideas?
This is my first adventure into mod'ing MTK roms so I am sure I am doing all kinds of things wrong . I had a good bit of experience on Rockchip SoC's before this though.
Kind regards and thanks in advance!
Roman
Figured it out!
So I finally did the following rather hackish work-around...
1. Flash stock firmware...
2. Root with Kingo Root
3. Enabled ADB
4. Attach to PC and fire up MTK Droid Tools
5. Take a full backup
6. Modify the system image from the backup and make changes
7. Put that in new firmware flash package
8. Flash new firmware
YAY - Cleaned up rom, modified, with root!
Once I get it all packaged up and uploaded to mtkfirmware.com I will post a link for anyone that wants a cleaned up rom with root!
The only downfall of the above method is that it absolutely requires that the developer have a device on hand because you can't just root the stock image file (at least, I couldn't figure out how... - bleh...
Kind Regards,
Roman
Dear roman,
Thanks for your hard work.
I have a simple question (I think) and if you have the time to reply or -any other android guru- I would be thankful.
My later issue was with a U27GT cube tablet, but I have others, one for each kid, and this is more of general question.
I am reading this and other forums about how to flash tablets from PC. My question is:
Can the flashing process be done from a SD card?
Thanks a lot and regards,
Fernando
SKorea
I pulled the CM13 source from github and successfully completed a build. Set up all the tools, got the right java version set up, then did the actual build (envsetup, breakfast surnia, then used make) which took a few hours to complete.
However, I cannot seem to find the ZIP file which contains the flashable ROM. My build works well when I fastboot flash things (recovery, boot, cache and system). But I really would like to get a ZIP version of the ROM which can be ADB sideloaded.
I searched around and most of the posts I see related to this kind of stuff are old posts, and all of them indicate that the ZIP file will be created with the build. Is this not the case anymore? If not, can anyone help point me in the direction of how to make proper flashable zip created from a set of properly built .img files?
Asked too soon. Found how to get the zip file - ran "brunch surnia" instead of breakfast and a manual make, and now the ZIP file is generated.
You should try
make otapackage
Command instead of make surnia
Hi guys
just wanted to know if its possible to run scripts within TWRP
i.e i have a script on my /scard, can i make TWRP run it within recovery?
if not are there any ways i can do this? as its important that its done in recovery and not OS.
ive tried looking for flashable zips that i can edit the updater-script but always fails.
i just want to run a script within TWRP using a for statement as it takes too long doing it line by line.
thank you.
Hi,
I was trying to do a similar thing. Did you find a way to do this? I want to automate the running pre-boot.
You can run a script in TWRP. I have used it to remove certain apps from a gapps package. Search the forums for it.