[Q] Is it safe to flash this? - General Questions and Answers

Hi there XDA! I have a really big question/problem. I want to theme Clockworkmod Recovery with custom pictures/icons/themes and such. So far I installed Ubuntu VM, decompiled the Recovery Image into Kernel and Ramdisk, replaced the pre-loaded icons with my custom icons to the ramdisk. Finally, I recompiled it into a new recovery image!
However, since this program is designed for device boot images, Im still curious, can this be used for recovery images? I haven't editing anything within the kernel, just opened the ramdisk, replaced the /res/images with my own and did abootimg --create newcwm.img.
EDIT : All I know is that in the boot.cfg the boot parameter size has to be exact fit or hardbrick.
so I have attached the 2 files that shows the recovery image data/config of both of them.
Don't worry its just 2 txt files. Inside the other archive has the flash ready images. BOTH OF THEM. Also includes the already decompiled ramdisk and kernel to take a look at. In addition the bootimg.cfg is also in. It has everything you need to know
So, heres the question. If I decide to flash it to mmcblk0p21 which is the verified recovery partition for the GT-i9505, (Info on the partition informations/mount points below
http://forum.xda-developers.com/showthread.php?t=2342841
Then, hopefuly the flash to the recovery partition shouldn't hardbrick my device. Am I right? Or missing something.
I will attach both my image and the cwm recovery Image I decompiled. Please if you can tell me if theres something that has to be fixed to prevent me getting a $700 paperweight.
Note: The layout might be confusing inside the Archive, just please bear with me and just take your time. I can wait
PRESS ME TO DOWNLOAD

Related

[Q] Boot Process

I've looked in quite a few threads, including the custom mix ROMs. What I want to know is who has knowledge of how this thing boots? I've noticed on the 2 droids I've messed with you upgrade them with an update.zip and basically an empty file on the SD card.
I'm guessing the update.zip contains a squashfs or something similar along with a kernel, but I don't know for sure. Who can explain exactly what happens on boot, what devices it looks for filesystems/loop filesystems on etc?
muqali said:
I've looked in quite a few threads, including the custom mix ROMs. What I want to know is who has knowledge of how this thing boots? I've noticed on the 2 droids I've messed with you upgrade them with an update.zip and basically an empty file on the SD card.
I'm guessing the update.zip contains a squashfs or something similar along with a kernel, but I don't know for sure. Who can explain exactly what happens on boot, what devices it looks for filesystems/loop filesystems on etc?
Click to expand...
Click to collapse
The best way to learn about this stuff is by tearing down existing .zip flashers and reading about how boot.img files are built and trying to build your own.
The boot process is controlled by the bootloader (the thing that displays the Viewsonic birds logo and decides whether you are trying to boot into recovery, APX mode, or a standard boot).
The ZIP files that you flash actually run a script that writes an .IMG file contents to one or more partitions.
Most ROM flashers have two images they flash - a boot.img and a system.img. The system.img is a filesystem image of the system partition. The boot.img consists of two parts - a kernel and a ramdisk image (well, and a boot header). The kernel is the Linux kernel that's been compiled to provide all the core system functionality for Android. The ramdisk image (which is a GZIPed CPIO file) contains the init.rc file that does all the initialization, mounting of the main filesystem images and so on.
Once everything is mounted and configured, the Android ROM itself boots up.
I recommend reading this page for more info:
http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images
Hope that helps!
That's more or less what I wanted, but for our device do you know the exact boot order? Mtd partitions then SD sd2 and maybe a USB disk? I'd really like to put a custom Roman on the sd2 and leave the rom factory.
muqali said:
That's more or less what I wanted, but for our device do you know the exact boot order? Mtd partitions then SD sd2 and maybe a USB disk? I'd really like to put a custom Roman on the sd2 and leave the rom factory.
Click to expand...
Click to collapse
I *think* (could be wrong) that both the externalSD (/sdcard2) and the USBDISK (/usbdisk) are mounted dynamically, via vold.
At least that's the way I understood it...
There's a thread here in this forum, about (dual) booting Ubuntu, that does something along the lines of what you're asking about...
Jim
rcgabriel said:
The best way to learn about this stuff is by tearing down existing .zip flashers and reading about how boot.img files are built and trying to build your own.
The boot process is controlled by the bootloader (the thing that displays the Viewsonic birds logo and decides whether you are trying to boot into recovery, APX mode, or a standard boot).
The ZIP files that you flash actually run a script that writes an .IMG file contents to one or more partitions.
Most ROM flashers have two images they flash - a boot.img and a system.img. The system.img is a filesystem image of the system partition. The boot.img consists of two parts - a kernel and a ramdisk image (well, and a boot header). The kernel is the Linux kernel that's been compiled to provide all the core system functionality for Android. The ramdisk image (which is a GZIPed CPIO file) contains the init.rc file that does all the initialization, mounting of the main filesystem images and so on.
Once everything is mounted and configured, the Android ROM itself boots up.
I recommend reading this page for more info:
http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images
Hope that helps!
Click to expand...
Click to collapse
rcgabriel,
When you do an nvflash (ala bekit's), does the contents of bootloader.bin end up getting stored permanently on the Gtab's internal SDcard? And, whenever the Gtab is booted, the code in that bootloader is the first code that runs, deciding, as you said, whether or not to do a recovery or execute the boot.img?
Thanks,
Jim
Isn't the bootloader on one of the MTD partitions and not the sdcard? What I'm having the hardest time wrapping my head around is how this system boots in comparison to an x86 Debian 5.0 system.
The basic picture I have is that there is the rom/flash portion of the boot process and then the kernel and real filesystem are loaded and mounted. But using these custom roms, is it changing the flash and bootloader or just the kernel and OS? Meaning where exactly is the first thing the CPU hits to boot? Flash MTD partitions for the bootloader. Then is the kernel on the mtd partitions or on some separate partition on sdcard.
Since you can basically stick 2 files on an external uSD and send it into upgrade mode, can't you customize the filesystem contained in a zip and then stick it in and have a custom system with whatever you wanted added or removed?

[Q] Why .img?

So in looking around I have not found any answer to my question. Why is everything to flash on the shield a .img instead of building zip files you can flash directly from recovery? I have been messing with android for quite a long time and know how to flash .img, fastboot, adb, ect. But dl'd and flashing a zip is far easier.
Any answers?
thanks.
*I think* that base factory images (.img files.) are meant to be flashed via fastboot, since they have a direct relationship with device specific partitions. Imagine a bit to bit flash, like a Ghost/Acronis image?!?
As for .zip files, they are installed via recoveries (CWM, TWRP, etc), because you just want to add/replace files in the / partition.
And with our Shield, until now, all OTAs are full system images, not updates.
I hope that I've explained this properly, if not please someone correct me
http://en.wikipedia.org/wiki/Fastboot#Fastboot
anthonws said:
*I think* that base factory images (.img files.) are meant to be flashed via fastboot, since they have a direct relationship with device specific partitions. Imagine a bit to bit flash, like a Ghost/Acronis image?!?
As for .zip files, they are installed via recoveries (CWM, TWRP, etc), because you just want to add/replace files in the / partition.
And with our Shield, until now, all OTAs are full system images, not updates.
I hope that I've explained this properly, if not please someone correct me
http://en.wikipedia.org/wiki/Fastboot#Fastboot
Click to expand...
Click to collapse
Not all ota are full system images, ota 65 and 67 are simple delta updates.
BTW, the main reason of .img files for images is because this can't depend on the recovery. How do you flash a recovery .zip file without a recovery?
You need to have a .img file that can be flashed via fastboot, it is VERY much "bricked" proff that a flashable zip
Thanks for the explanations. I realize some things need to be done via fastboot like unlocking or flashing a recovery for the first time.
I guess I have become spoiled by xda and the simplicity of modification that is available today. Far cry from hacking htcs back in the day.
thx -jason
Both answers are correct - it all depends on which software (on the device) is used to flash, and what format it accepts.
With Tegra devices you have at least 3 ways to flash stuff, from lowest to highest level:
- nvflash/tegrarcm mode. This is a very small firmware that is burnt in ROM and is thus always available no matter how hard you screw your device. It can run small programs (typically, a flasher) that are sent through USB. Problem is, for Tegra4 it will only accept signed binaries, which makes it useless for modders.
- bootloader/fastboot. The bootloader supports the fastboot protocol, which can flash .img files. The bootloader is written in flash memory so your bootloader partition must be in good shape.
- recovery/zip files. The recovery is a Linux image, so this means it is a full-blown system of its own right. Because of this it can support more format, including .zip archives with a script to describe how the archive should be installed.
So in the boot chain, you have 3 anchors from which you can flash images: boot rom (always available but unusable to us) -> bootloader -> recovery. The fact the boot rom cannot be used without a signed image (which is not available publicly) means that screwing your bootloader is sufficient to permanently brick your device.
Recovery images are more convenient since they are in .zip format and can for some be device-independent (e.g. superSU recovery images are flashed the same on every single device out there), contrary to the bootloader which can be different for every device. But they require a working recovery, which is not always granted - so for actual recovery, fastboot images are also useful.
That's why I love XDA
You're never alone!
Thanks for the additional info to all
Anthonws

Boot image modification for Pixel? The usual steps don't work

Usually, for modifying boot images, I unpack boot images (either extracted from rooted phone, or from full system image) using Android Image Kitchen, make my changes in the ramdisk directory, repack and flash (using fastboot flash boot <image_new.img>).
However, this doesn't work for Pixel or Pixel XL. I could simply create a new file in the ramdisk directory, but it doesn't reflect in the phone's root directory. I suspect this has something to do with the partitioning changes for this device, although I haven't been able to find a good complete write up about what are the exact changes. I have noticed a few new partitions (like hosd.img, bootlocker.img, hyp.img, keymaster.img, etc) but I am not entirely sure what they are for.
Any ideas how I can make some simple changes to the boot image? I want to make changes to the rc files and add a few shell scripts (for some init.rc services), and make some changes to default.prop.
Edit: I have read a bit more online, and I figured out that the boot image's ramdisk is only used in recovery, and initramfs of the system image is used as the init and the root during the normal phone boot up. So I will be able to do what I want by modifying the system image? I tried going through Chainfire's boot image too, and I am not exactly sure how he manages to modify the content of the system using the boot image.

[Q] Installing System raw image with flashable .zip

I'm trying to make a flashable zip for TWRP to install a Lenovo Z6 Pro stock ROM. I create the .zip file with Boot, System and Vendor (I'd add the rest of the firmware later). Boot and Vendor are installed but system.img is not installed. I know that I could use .dat files but I'm specially interested on using the image files.
I took as template another ROM which uses .IMG files too with the function 'package_extract_file'. I just replaced the .IMG files making sure that the names are exactly the same, and also I'm sure that my system.img is raw. When I try to install the flashable zip from recovery it prompts the uiprint "Patching system unconditionally" but nothing is installed and skips directly to patch the vendor partitions which is successfully patched.
Any help or clue will be much appreciated. Thanks in advance.

Any Recovery Editing program?

Is there any program that can edit / modify recoveries?
I have tried to make cwm and twrp for a Panasonic KX-PRX150 by unpacking replacing files and repacking but nothing the phone's screen remains black when booting to recovery mode.
I have also tried to flash the stock recovery and it is not in recovery.img format but in recovery-from-boot.p and a install-recovery.sh flashing it on recovery mode.
Try this guide. I've never tested it.
How to Create and Port TWRP Recovery to any Android Device
In this tutorial, we will show you detailed steps to create and port TWRP Recovery for any Android Device using Android Image Kitchen tool.
www.droidwin.com
Thank you. But I was thinking about Editing my stock recovery.
I'm fond of my own ImgUtil.exe (in the sig) which can modify boot images without taking them all apart and putting them back.
I usually start with stock recovery and replace adbd with a rooted adbd, add a service for it in init.rc (if there is none).
This should all work fine unless you have issues with AVB.

Categories

Resources