Database Info

Very very important please.

I have crashed my Olivetti Olipad flashing bad rom
Now i have original rom in this format:
META-INF (folder)
boot.img (3.154 KB)
bootloader.bin (920 KB)
recovery.img (3.754 KB)
system.img (142.519 KB)
The original recovery consolle not work.
It's possible with this file restore the ful original firmware with nvflash??
or only recovery consolle?
Please help me.
I'm disperate.
Thanks.

It should be possible to use nvflash and rewrite the various partitions.
I suppose you have a ZIP file... prepared for the consolle recovery.
I also had troubles with Recovery NOT starting, but you could try to revive it doing a double step launch: load a good partition 9 (the SOS or Recovery) and then start the recovery just nvflashed with the volume + key, then do the restore.
So....
assuming that you have in the same directory an NVFLASH kit and the files you extracted form the Zip you got, I would do this:
nvflash --bl bootloader.bin --download 9 recovery.img --download 10 boot.bin --download 11 system.img --go
To send the olipad in the proper mode for this procedure you have to press Power and Volume - (see a short screen flash and then all black, but PC will recognize it as APX)
Let me know if it works.
SimonePDA

The restore of boot.bin failed perhaps the partition tablem modified in Gtablet mode.
I'm waiting the download of malata firmware for try with it.
P.S. I'm the same man of hdblog forum.

By the way, I would be very grateful to you if you could make that file available to me as well, because I already made quite a mess of my olipad and going back to normal would be great!
Let me know and thanx in advance.
Simone PDA

tatoone said:
The restore of boot.bin failed perhaps the partition tablem modified in Gtablet mode.
P.S. I'm the same man of hdblog forum.
Click to expand...
Click to collapse
When you say "it failed", what message you get?
you tried the command I wrote and after loading bootloader, if exited with some error... which one?

Moved to general.

tatoone said:
I have crashed my Olivetti Olipad flashing bad rom
Now i have original rom in this format:
META-INF (folder)
boot.img (3.154 KB)
bootloader.bin (920 KB)
recovery.img (3.754 KB)
system.img (142.519 KB)
The original recovery consolle not work.
It's possible with this file restore the ful original firmware with nvflash??
or only recovery consolle?
Please help me.
I'm disperate.
Thanks.
Click to expand...
Click to collapse
Help me!!!!
Original recovery consolle not work.
OliPad write "booting recovery kernel image"
Please give me Original Flash !!!

WolfMan2012 said:
Help me!!!!
Original recovery consolle not work.
OliPad write "booting recovery kernel image"
Please give me Original Flash !!!
Click to expand...
Click to collapse
I don't have first hand experience with the OliPad, but nvflash should correct your issue. Just make sure to flash the correct version 1.1 or 1.2. That depends on the ROM you are flashing.

[SOLVED] Update Prime v1.7 to v1.8.x w/ Ubuntu

Fix: I was able to flash the CWM recovery.img with nvflash, update Prime with CWM, and re-flash lilstevie's recovery to gain back Ubuntu-booting support.
Do a full backup with nvflash (instructions here)
Flash CWM recovery.img (attached) to the recovery partition with nvflash.
Code:
sudo ./nvflash --bct transformer.bct --setbct --configfile flash.cfg --bl bootloader.bin --odmdata 0x300d8011 --sbk 0x1682CCD8 0x8A1A43EA 0xA532EEB6 0xECFE1D98 --sync
sudo ./nvflash --resume --download 5 recovery.img
Use CWM to flash any update ZIPs (I updated Prime v1.7 to v1.8.2-->v1.8.4)
Restore the Ubuntu-booting recovery partition (05_SOS_raw.img) from the backup in step #1
Code:
sudo ./nvflash --bct transformer.bct --setbct --configfile flash.cfg --bl bootloader.bin --odmdata 0x300d8011 --sbk 0x1682CCD8 0x8A1A43EA 0xA532EEB6 0xECFE1D98 --sync
sudo ./nvflash --resume --download 5 05_SOS_raw.img
Original Question [Solved]:I have my Transformer dual booting Prime v1.7 (primary) and lilstevie's eMMC-loaded Ubuntu (recovery). I'd like to update Prime to v1.8.x, but I don't believe I'm able to boot CWM Recovery, as Ubuntu's taking up that space.
I'm about to go down the path of figuring out how to back up all of my partitions (easy), remove Ubuntu in-place (hard), update and backup Prime (easy), and flash it all back with Ubuntu again (medium).
Is there a better way to do this (such as actually being able to boot CWM Recovery), or does anyone have any advice with the above plans?

Welp, I'm impatient, so I'm going to give this a shot. My plan is to flash CWM in recovery.img form via nvflash, use it to update to Prime v1.8.4 (and maybe a new kernel), back everything back up again, and flash back lilstevie's recovery image. I'll post results.

I've wondered how you would do that myself, you could ask in the Ubuntu thread because a lot of those people probably had the same question

Mission accomplished. I've updated to Prime v1.8.4 without blowing away my Ubuntu partition. I'll update the main post. I'll probably start a thread in the Dev forums to compile information about messing around with nvflash.

thank you!
I used this method to upgrade from prime 2.5 to 2.7

The new flashpack updated 6 hours ago includes a mode that dumps the recovery partition, uploads CWM to recovery, so you can do the update with it. Then flash the kernel that was in recovery back once you are done

So you still have to have ubuntu in the recovery partition?
Is there no way to have the Prime Recovery partition AND have ubuntu AND have android?
Right now Im having a problem where I can't boot into Android at all, only Linux, even though I had the same configuration as you (Android Default, Ubuntu in recovery). This problem started after I installed the ROM Manager off the Android Market.

technological said:
So you still have to have ubuntu in the recovery partition?
Is there no way to have the Prime Recovery partition AND have ubuntu AND have android?
Right now Im having a problem where I can't boot into Android at all, only Linux, even though I had the same configuration as you (Android Default, Ubuntu in recovery). This problem started after I installed the ROM Manager off the Android Market.
Click to expand...
Click to collapse
The way I understand it is this: you can currently only have one "kernel" in the recovery partition at one time. Examples are:
Stock Recovery
CWM Recovery
Ubuntu Kernel
Option 1
If you want to switch between Android and Ubuntu, but don't care about CWM, you should put the Ubuntu kernel in the Recovery partition. I used to do this, but since I've been updating my Android OS (Revolution HD) frequently, I'm about to switch to the next option.
Option 2
If you'd like to keep CWM Recovery, but also be able to move between Android and Ubuntu frequently, keep CWM Recovery in the Recovery partition, and store two ZIP files on your MicroSD card:
Android Kernel ZIP
Ubuntu Kernel ZIP
Running either of these ZIPs from CWM Recovery will install that kernel blob to the default OS partition. Thus, upon reboot, it will boot that particular OS. If you want to boot the other OS, load CWM Recovery, flash that ZIP, and the new default OS will be changed.

rickatnight11 said:
The way I understand it is this: you can currently only have one "kernel" in the recovery partition at one time. Examples are:
Stock Recovery
CWM Recovery
Ubuntu Kernel
Option 1
If you want to switch between Android and Ubuntu, but don't care about CWM, you should put the Ubuntu kernel in the Recovery partition. I used to do this, but since I've been updating my Android OS (Revolution HD) frequently, I'm about to switch to the next option.
Option 2
If you'd like to keep CWM Recovery, but also be able to move between Android and Ubuntu frequently, keep CWM Recovery in the Recovery partition, and store two ZIP files on your MicroSD card:
Android Kernel ZIP
Ubuntu Kernel ZIP
Running either of these ZIPs from CWM Recovery will install that kernel blob to the default OS partition. Thus, upon reboot, it will boot that particular OS. If you want to boot the other OS, load CWM Recovery, flash that ZIP, and the new default OS will be changed.
Click to expand...
Click to collapse
Oh. K. So there is no sacrificed functionality in doing this? Do you get slower boot times?

technological said:
Oh. K. So there is no sacrificed functionality in doing this? Also, I've found the explanations of ClockWork Recovery to be even less noob friendly than everything else on this site. I dont understand what it is, nor how to get it, and I've been reading through this site for weeks.
Click to expand...
Click to collapse
CWM Recovery is a piece of software (I believe it's a very light build of Linux), written by Koush, intended to provide OS recovery features such as:
Backups
Restores
USB Access
Since the hardware is different for every device, installation and booting of CWM is different for every device. In the Transformer's case, CWM is written to the Recovery partition, overwriting the stock Recovery tool. (This tool only restores your Android partition to stock and applies OTA updates. If you're using CWM, chances are you're flashing your own ROMs, so this functionality is replaced by CWM features.) You boot into the CWM Recovery just like you would the stock Recovery, by holding Pwr+VolDown and then releasing and pressing VolUp, when prompted.
When you boot into any OS, that OS can essentially do whatever it wants to the hardware on the device, provided adequate tools and drivers are included in the OS. Since it's not smart to mess with the OS that's currently loaded, it makes sense to boot to another system before messing with Android. Thus, applying updates, wiping, backing up, or flashing new ROMS is done from CWM.
The last tip, which may help you understand everything, is an overview of how ALL operating systems work. The kernel IS the operating system. When your computer/phone/tablet boot, it always loads a kernel into memory. This kernel includes all of the drivers and applications needed to load the entire OS into memory. It also includes a reference to which partitions the rest of the data should be loaded from.
As an example, when Android boots, it boots the kernel, which loads all of the low-level linux drivers and modules. This includes the driver to access the internal flash. At that point it can access the partitions it's been programmed to "know" about, and load the rest of the OS from them.
CWM itself is doing the same thing. When you use the key combination to load the Recovery, your Transformer is loading the CWM Kernel, rather than the Android Kernel. The CWM Kernel contains (I suspect) a very watered down version of the Linux kernel, which it uses to boot the tiny Recovery application you are presented with. It has the drivers and modules needed to access the screen, the internal flash, the keyboard, etc, which allows you to perform all of those tasks.
Lastly, Ubuntu works the same way. Regardless of how you have it set up, you eventually trigger the Transformer to boot the Ubuntu Linux Kernel. This loads all of the drivers and modules, and then pulls the remaining portions of the OS from the correct partition.

So dont you lose all your data whenever you change OSes?
As far as I can tell, you keep CWM in recovery, then reflash the main every time you want to change to and from Ubuntu/Android. So don't you lose data every time you do this?

technological said:
So dont you lose all your data whenever you change OSes?
As far as I can tell, you keep CWM in recovery, then reflash the main every time you want to change to and from Ubuntu/Android. So don't you lose data every time you do this?
Click to expand...
Click to collapse
Correct. All you're doing is flashing the kernel partition, which is separate from the system and data partitions on both OSes.

[Q] Blob pack/unpack

Hi,
I have asus transformer infinity tf700t and a stock blob of JB. I used blobtools to unpack and repack the blob.
STOCK blob - blob
Repacked stock blob after unpacking - blob_new
I did this just to test the integrity of blobtools. However to my surprise I found that blob and blob_new differ in binary mode. They have exact same size
(du <filename>) but when I open them in binary mode, the files differ a lot.
Is this expected behavior?
I did not change anything in the extracted files after unpacking the original blob.
Please suggest.
regards
shivanand

[Q] Create Flashable zip from Stock ASUS .zip ?

Can anyone link me to a guide or explain here how to convert an ASUS Stock .zip ROM to a Flashable zip that can be flashed in recovery ?
I managed to get my hands on the final Stock Honeycomb 8.6.5.21 ROM ASUS released before moving over to ICS and want to create a flashable .zip so I can flash it in recovery like any other custom ROM
Thanks

*Detection* said:
Can anyone link me to a guide or explain here how to convert an ASUS Stock .zip ROM to a Flashable zip that can be flashed in recovery ?
I managed to get my hands on the final Stock Honeycomb 8.6.5.21 ROM ASUS released before moving over to ICS and want to create a flashable .zip so I can flash it in recovery like any other custom ROM
Thanks
Click to expand...
Click to collapse
No, you cant. But you can take your /system (ROM) files and compress it as .tar file from the Terminal Emulator. You need know how to make an updater-script to make the zip file flashable from custom recovery. Try to use the Android Kitchen

TheMrcool212 said:
No, you cant. But you can take your /system (ROM) files and compress it as .tar file from the Terminal Emulator. You need know how to make an updater-script to make the zip file flashable from custom recovery. Try to use the Android Kitchen
Click to expand...
Click to collapse
It's packed as a blob so not as easy as extracting it I suppose, I've read a little about extracting blob files but never tried it
Thanks for the info, I`ll leave the link to it here if anyone fancies giving it a shot
http://www.portableandroid.co.uk/androidDL/WW_epad-user-8.6.5.21.zip

One way is to extract the blob from the zip ( which is actually a zip within a zip ) and write it to disk from a terminal I'm assuming you are rooted as you mention having CWM . The command off the top of my head is: dd if=/pathtoyourblobfile of=/dev/block/mmcblk0p4. It will take a few minutes to complete, bear in mind you will be back to stock, I.e. no CWM and you will lose root. HTH.

pkfox said:
One way is to extract the blob from the zip ( which is actually a zip within a zip ) and write it to disk from a terminal I'm assuming you are rooted as you mention having CWM . The command off the top of my head is: dd if=/pathtoyourblobfile of=/dev/block/mmcblk0p4. It will take a few minutes to complete, bear in mind you will be back to stock, I.e. no CWM and you will lose root. HTH.
Click to expand...
Click to collapse
That's why I wanted a flashble zip, so I don't return to stock and can easily flash back to 4.2.2 when I'm done playing
Cheers though

What I did was backup 4.2.2, then flash stock (recovery and ROM).
Then I rooted and installed TWRP using Wolf's method 3.
Made a stock backup in TWRP.
Then I can restore to stock, and when I'm done I can restore back to 4.2.2

You can take your ROM files by doing these commands in the Terminal Emulator.
Code:
su
tar -c system/* >> sdcard/system.tar
And wait for few minutes and a file named system.tar will appear in /sdcard. You can take the file from your computer and use the android kitchen to make the /system file flashable in custom recovery. You can find the tutorial (Here)

frederuco said:
What I did was backup 4.2.2, then flash stock (recovery and ROM).
Then I rooted and installed TWRP using Wolf's method 3.
Made a stock backup in TWRP.
Then I can restore to stock, and when I'm done I can restore back to 4.2.2
Click to expand...
Click to collapse
Good idea, so does the TF see the HC update zip and just allow you to flash as if it was an OTA, even from JB or did you need to flash it a different way ?
TheMrcool212 said:
You can take your ROM files by doing these commands in the Terminal Emulator.
Code:
su
tar -c system/* >> sdcard/system.tar
And wait for few minutes and a file named system.tar will appear in /sdcard. You can take the file from your computer and use the android kitchen to make the /system file flashable in custom recovery. You can find the tutorial (Here)
Click to expand...
Click to collapse
Great thanks, I`ll take a look at that method too cheers

*Detection* said:
Good idea, so does the TF see the HC update zip and just allow you to flash as if it was an OTA, even from JB or did you need to flash it a different way ?
Click to expand...
Click to collapse
I flashed the last ICS firmware (unzip once) from TWRP. Should work the same from HC.
Then install TWRP using ADB or APX. Root if you want (flash SuperUser.zip) and make a nandroid.

frederuco said:
I flashed the last ICS firmware (unzip once) from TWRP. Should work the same from HC.
Then install TWRP using ADB or APX. Root if you want (flash SuperUser.zip) and make a nandroid.
Click to expand...
Click to collapse
Ah so the stock zips are already flashable from TWRP, shame theres not a simple way to add TWRP to the stock zip

[Q] Boot custom image without flashing it

This may seem an already (10 times) solved question, but I'm unable to boot my Mogo G with a custom boot.img instead of the one flashed on the device.
The phone is an XT1032, currently running KitKat 4.4.4, and I use the latest SDK tools.
I download the stock firmware from sbf.droid-developers.org/phone.php, where I choose RETAIL-FR_FALCON_KLB20.9-1.10-1.24-1.1_cid7_CFC_1FF_SVC.xml.zip
I extract the boot.img file using standard unzip tools, and the zImage and initrd.img files using abootimg
Code:
adb reboot-bootloader
The phone reboots and gets to the fastboot menu
Code:
fastboot boot zImage initrd.img
The console output seems right:
Code:
creating boot image...
creating boot image - 6975488 bytes
downloading 'boot.img'...
OKAY [ 0.336s]
booting...
OKAY [ 0.244s]
finished. total time: 0.580s
The device tries to reboot, but stops at the first "M Powered by Android" splash screen
I wait one minute
I hard reboot the device by holding the power button
The device reboots, but has to pass an unusual step, "Updating Android/Optimization application ..."
I'm quite sure the same method was successful a few months ago, so what has since changed:
The device's firmware was upgraded from 4.4.3 to 4.4.4
The SDK tools were upgraded from ? to 23.0.2
I don't remember whether the firmware was available as a tar.gz or a xml.zip file, but I think it was a tar.gz, and I'm near certain I then used the SDK provided fastboot tool. Today, the firmware is available as an xml.zip file, and I think I have to use the Motorola specific fastboot tool (anyway I've tried both, for identical results)
Could anyone point me toward what I'm missing or doing wrong ?
Thanks.

Why did u extract the boot.img?
Maybe wrong kernel?
And whats about the kernel modules of your custom kernel?

sub77 said:
Why did u extract the boot.img?
Click to expand...
Click to collapse
I simply want a basic way to boot a custom initial ramdisk, without flashing it to the device. So I download the stock firmware archive, unzip it, extract the initial ramdisk (initrd.img) from the boot image, modify it, and repack it using abootimg.
And then:
Code:
fastboot boot zImage initrd.img
For me, this command conform to both the SDK provided fastboot and the Motorola specific one shows in it's help message:
Code:
boot <kernel> [ <ramdisk> ]
I'm not sure anymore of the above command's correctness:
Some information may be missing, as when you expand the boot image (boot.img) you get three files : a kernel (zImage), an initial ramdisk (initrd.img), but also some metadata (in bootimg.cfg); and this metadata is lost when I use "fastboot boot zImage initrd.img". I may try to give this information using additional fastboot options
I even suspect that a few months ago, I used fastboot with a full boot.img image as parameter, though this does not seem to fit the help message above
sub77 said:
Maybe wrong kernel?
And whats about the kernel modules of your custom kernel?
Click to expand...
Click to collapse
As I told you, I'm not currently working on the kernel, and I'm testing with _unmodified_ kernel image (zImage) and initial ramdisk (initird.img), as extracted by "abootimg -x".
Again, any idea is welcome.