Install Pantech Jellybean JYUS06032013 (Android 4.1.2) on Pantech Flex (over any current build)



Join the #p8010 IRC channel

Procedure if you ARE NOT running baseband JYUS06032013 (ICS Basebands) :

  • boot ICS CWM
  • flash FLEX-JB-JYUS06032013-FIRMWARE.zip from CWM
  • format system in CWM (will NOT wipe data, but makes sure old rom does not flash back stock recovery)
  • restart start recovery/adb reboot recovery (JB CWM is installed – do not try to fastboot boot ICS CWM)
  • flash FLEX-JB-JYUS06032013-ROM.zip from CWM.
    reboot

Procedure if you ARE running baseband JYUS06032013 (JB Baseband) :

  • get root (Instructions HERE – use GANDALF)
  • install CWM (Instructions HERE)
  • flash FLEX-JB-JYUS06032013-FIRMWARE.zip from CWM
  • format system in CWM (will NOT wipe data, but makes sure old rom does not flash back stock recovery)
  • reboot to installed CWM
  • flash FLEX-JB-JYUS06032013-ROM.zip from CWM.
    reboot

This ROM is Pantech stock stock stock with no mods other than CWM installation protection and all stock permissions and symlinks carefully maintained and consistent with the product of a successful OTA.

The firmware is also stock, with the exception of the open aboot allowing fastboot boot, and installation of JB CWM with nothing else added or changed. It runs well with nothing broken. You MUST be on JB firmware (below) to run it properly.

Root: You can let the new CWM root it if you like when you exit – it will prompt you.

Downloads:
md5: 1a0ca5f177bce2f4c428931616e0ecd1 FLEX-JB-JYUS06032013-FIRMWARE.zip
md5: 17c0e611ab6dfbca230571c1e40f3d14 FLEX-JB-JYUS06032013-ROM.zip

Restore “fastboot boot boot.img” capability on Pantech Flex after Android 4.1 Jellybean update



Join the #burstroot IRC channel

Restore fastboot boot boot.img on Pantech Flex
(after Android 4.1 Jellybean update)

Process:

As usual, this is high level for advanced users.  No support implied or available.

Notes:
I pulled and zipped the aboot from my ICS Pantech Flex phone.

md5sum /dev/block/platform/msm_sdcc.1/by-name/aboot
3af799fcb04331d5d0a00f0af2ebd229 /dev/block/platform/msm_sdcc.1/by-name/aboot
tells me the md5sum of the aboot partition

md5sum /dev/block/mmcblk0p5
3af799fcb04331d5d0a00f0af2ebd229 /dev/block/mmcblk0p5
tells me that is the aboot partition because the md5′s match

md5sum aboot.img
3af799fcb04331d5d0a00f0af2ebd229  aboot.img
tells me the aboot I off pulled matches the partition aboot.  It’s a good image.

I was able to apply the 4.1 update and test this.  It works.  Fastboot is back.  I was then able to extract and boot the stock JB boot and recovery images.

ICS boot images are not compatible. New recovery and custom boot images are needed, but they can be installed the same ways as before after flashing back the older aboot as described above.

For anyone not able to get the JB update.zip from the AT&T OTA, here it is, signed and ready to flash from stock recovery.  Note: this [B][I]will[/I][/B] fail if there are missing pieces.  You must be on stock ICS.

http://tau.shadowchild.nl/files/flex-jb-update.zip

Here are extracted stock JB aboot, boot and recovery images if they are needed:

http://tau.shadowchild.nl/files/flex-4.1-stock-aboot-boot-recovery.zip  << rename to update.zip and flash from stock ICS recovery.

loki-doki, the simple way to patch any custom boot image on AT&T and Verizon Galaxy S 4


Feedback please – let me know your result by commenting below.

What it is:

A simple script in a zip I put together that is run from recovery (like GAPPS) that will extract and patch the installed boot image with drjbliss’s utilities and re-flash it. The only prerequisite is any properly working custom recovery.

Why?

from djrbliss’s notes, it seems that the patch is aboot specific. This means that boot images will only work with the version aboot they were patched for. This remedies that by patching for the phone-specifc aboot.

To use:

  1. flash a non-patched boot image or custom rom. 
  2. flash loki-doki.zip from custom recovery the same way you would flash gapps for CyanogenMod or a custom rom.
  3. Done.  It’s quick and painless.

This utility checks the bootloader version before executing anything.  It will do no harm if someone should run it on a device out of scope.

Anyone is free to use/modify/distribute this in any way.
No Warranty is implied, expressed etc.  As always, use at your own risk.

Download:  http://tau.shadowchild.nl/files/loki-doki.zip

Reference:
drjbliss’s github repo: https://github.com/djrbliss/loki

 

Go play outside you whiney, entitled feeling little punk.


It’s too bad some users (largely those coming from XDA developers, the largest commercial idiot farm on the planet) seem to feel like they are entitled to free support that simply isn’t on the table.  In the end, it makes existing support impossible in certain cases.

Quote from unlimited.io

Update regarding Windows versions of our tools:

Team Unlimited has decided to drop all support for the Windows OS. This is due to massive amounts of trolling on forums and in our support channel as well as flaming us for our decision to not support Windows 8 or any version of Windows 64bit.

We attempted to explain to anyone who had questions why this was not supported – drivers are unreliable, percentage of risk for bricking was too high, and just general complications – but we were greeted with people who demanded support and others that came into our support # to tell us that ‘clearly we didn’t test 64bit because it works’ and ‘wanted to let us know that we could support 64bit.’

We want to make it clear that we make and support these tools with our free time, for free, for you – our users. We made a decision to provide clear and concise directions and a live support channel. We can revoke all or part of this at any time and will should people become abusive to our team members.”

Android usb debugging and fastboot support on Windows is dicey at best.  My biggest mistake with AAHK was including windows support because it *could* work.  It was a mistake because too often the user’s windows environment failed.   Some of the hacks for newer smartphones are more complex than they used to be, and those who develop them hate to put them out there without some support because sometimes even with due diligence on the part of the user things can go awry.  Not all Linux distros are equal and most of these tools are distributed with android tools that are for 32 bit Linux.  So if developers support only what works most reliably and produces the least number of support issues, then support that decision because:

  • Showing gratitude without criticism of free support is the classy thing to do.
  • Carping about free support automatically makes you a colossal asshole.
  • You might as well; your opinion means shit anyway.

If you don’t like this approach to free support, then go play outside (or anywhere else).

A high-level DHD/Inspire manual S-OFF hack concept for advanced users


Okay, stop the hating. Here’s a high level DHD/Inspire manual (as in not automated) S-OFF hack concept for advanced users. I am NOT going to detail it further or support it.

#include <std_disclaimer.h>
/*
Your warranty is now void. I am not responsible for bricked devices, dead SD cards, thermonuclear war, or you getting fired because you can’t tether. Please do some research if you have any concerns about this process before attempting it! YOU are choosing to make these modifications, and if you point the finger at me for messing up your device, I will laugh at you.
*/
(Disclaimer borrowed heavily from cyanogenmod)

Just because the hack kit is going away doesn’t mean the Inspire/DHD can’t be set s-off. Here’s a high level how-to that advanced users should have no issue with. This is NOT a step-by-step, but a description of the activity.  This is deliberate.  If you don’t know what you are doing and don’t understand what’s going on – DON’T EVEN TRY THIS. I am NOT going to detail it further or support it

High Level Steps (some detail deliberately NOT included)

  • htc dev unlock, install cwm recovery and root ONLY
  • dd the stock boot image to /data/local/tmp and pull it to your pc HD (/dev/block/mmcblk0p22 is boot)
    • adb shell dd if=/dev/block/mmcblk0p22 of=/data/local/tmp/boot.img
    • adb pull /data/local/tmp/boot.img
  • make a goldcard (for all CIDS not in android-info.txt in the firmware.zip to be flashed)
    • adb push goldcard /data/local/tmp
    • adb shell chmod 775 /data/local/tmp/goldcard
    • adb shell cat /sys/class/mmc_host/mmc2/mmc2:*/cid  (returns sdcard cid)
    • adb shell /data/local/tmp/goldcard -c <sd card cid above>  -o /data/local /tmp/goldcard.img
    • adb shell dd if=/data/local/tmp/goldcard.img of=/dev/block/mmcblk1 (this writes the goldcard.img to the sdcard.  Mileage on used sdcards may vary)
  • push misc_version to the phone and use to lower the mainversion (need to lower the  mainversion in order to flash the firmware downgrade)
    • adb push misc_version /data/local/tmp
    • adb shell chmod 775 /data/local/tmp/misc_version
    • adb shell /data/local/tmp/misc_version -s 1.11.111.1 
  • relock the bootloader
  • flash firmware.zip with from the zip below (this firmware contains the original radio exploit used by gfree)
    • fastboot oem rebootRUU
    • fastboot flash zip firmware.zip
    • fastboot reboot-bootloader
  • unlock the bootloader again (use the same unlocktoken bin)
  • flash your stock boot.img to boot (this will get the current rom working again)
    • fastboot flash boot boot.img
  • flash recovery.img to recovery (from the zip below – this recovery has a kernel that works with the radio exploit)
    • fastboot flash recovery recovery.img
  • boot to recovery (yes, the screen may well be blank, but adb should work fine)
    • adb push gfree /tmp/
    • adb shell chmod 775 /tmp/gfree
    • adb shell /tmp/gfree -f   >> yeilds – s-off, supercid, sim-unlock
  • reboot to bootloader and check success.

Notes:

  • The firmware.zip in the package below does not contain an hboot, so it should be safe for all Inspire/DHD devices, even those shipped with Gingerbread.
  • Flashing a froyo hboot to a device shipped with Gingerbread is a terrible idea. If you do this after all that has been posted about it, you’re an idiot.  EARLY S-OFF METHODS DID THIS.
  • If you read this carefully, you will realize that this is S-OFF ONLY.  The radio will need to be updated again, it is not rooted, nor does not have working recovery on most devices.  There are 1000s of threads on how to do all that with S-OFF, so no, we are not going into any of that here.
  • Included are the two HBOOTs Hyuh hacked up for us with some ENG functionality. There is one for Sense 3 devices and one for pre-sense 3 devices. Use the correct one – partition layouts are different.

Tools here: ace-tools.zip
md5: 91a551d72f16883a35b8e8f9a7e5bcb1 ace-tools.zip

This should be a useful process outline, and I hope it helps people who have a clue to start with. I am NOT going to detail it further or support it.

Once again, I AM NOT GOING INTO FURTHER DETAIL OR SUPPORTING THIS PROCESS. IF YOU DON’T GET IT, TOO BAD.

Thanks to:

  • Revskills for their fantastic gold card algorithym
  • GenePoole for the kickass android goldcard binary based on above and a new version of gfree built w/o need for certain dependencies.
  • scotty2 for finding the vold exploit and the author of psneuter
  • Guhl for misc_version and gfree
  • hyuh for misc_version revisions and Hboots with ENG features

 

HEYZUESS, what the hell are smartphone makers thinking?


Quote from CNET on rumored SGS4 specs:
“Among them is a rumored eight-core Exynos processor, a separate eight-core graphics processing unit, a 4.99-inch SuperAmoled display, 2GB of RAM, a 13-megapixel rear camera with 1080p video capability, a 2-megapixel front-facing camera, and the latest version of Android

WTF is all of this for?  A phone? Unless it’s going to have 16 GB ram, a TB drive and a complete docking station with dual monitor support and multi OS boot capability, IDGAF.  It’s just silly.

I don’t want more cores, more megapixels and a larger screen.  REALLY, I don’t.  I want the things I have FIXED, like buggy touchscreens (let’s be honest) and light sensors that don’t work worth a damn to keep the display at reasonable automatic settings from low light to bright outdoors.  From GPS chips that loose their minds and sync forever to craptastic WIFI connections and poor audio input and output circuits.

FIXITFIXITFIXITFIXIT, DAMMIT FIXIT!

While you’re at it Samsung, I want a phone that can easily fit in ANY of my pants pockets (SGS3 isn’t it with a decent protective case on it), a phone with a battery that will last the best part of a week with light to moderate use with a single charge and a phone that can optionally automatically switch the number my carrier provides to VOIP over WIFI.

None of what I want in a new phone involves more memory a larger screen or more CPU/GPU cores.  I DO NOT GIVE A CRAP ABOUT RAISING THE BAR IN THOSE AREAS.  Those things are just not important.  What’s important is improvements in useability and functionality and better integration into my day to day life.  That’s what a smartphone is supposed to be about – not making big stupid ones.

Samsung, your eye is clearly not on the ball, even if no one else is doing any better.

Wall of shame….


17:44 jisaacs has joined #aahkSupport
17:45 < jisaacs> Hello, hello
17:45 < jisaacs> greatly in need of some help
17:47 jisaacs has quit [Client Quit]

No more mail validation required for new users…


Once you register, you can begin posting on TAU right away. Posts are validated. This is not a forum/message board.

Timestamping Android recovery backup sets on devices with no hardware clock

Problem:

  • ClockworkMod recovery (and others) use timestamps to identify and list backup sets in sequence.  Unfortunately, many modern devices using SOC (system on chip) lack a battery backed system clock.  The result is that the Linux  time is set to sometime 1969ish on boot, and devices use network time to reset it once connected.   However, recovery is not network connected.  This results in backup sets timestamped out of sequence and makes them more difficult to track which is which.

Solutions:

Use ROM Manager to initiate backup sets.

    • Is available today as a work around for Rom Manager supported devices
    • Requires Rom Manager, which many prefer not to use
    • Does not address the core problem with standalone recovery

Connect to the network and sync time

    • No one is doing this that I know of
    • Increases the complexity of making custom recovery considerably

Pass a token to recovery from Android and use it to set time on Linux boot

    • On reboot to recovery, will be accurate within a minute or so
    • On boot to recovery after extended shutdown will not be accurate, but will still allow timestamped backup set name to be in sequence.  The long the time the phone is down before starting recovery, the older the time token is.
    • This could be implemented via a root some Android app and a start up script in recovery (I don’t know of any yet).
    • This can be implemented on any device with this issue with init.d jobs and a start up script in recovery (how to is here).

Passing a time token from Android to Recovery using initd:

Prerequisites:

    • Working init.d on ROM
    • Knowing how to build custom recovery or unpack, modify and repack a recovery image

 

Example of an init.d script on ROM:

#!/bin/sh
# 99timemachine attn1 01/2013
top() {
date -u +%Y.%m.%d-%T > /cache/timemachine
sleep 15
top
}

Addition of the following to /sbin/postrecoveryboot.sh

#!/bin/sh
# postrecoveryboot.sh script attn1 01/2013

if [ -f /cache/timemachine ]; then
ln -s /sbin/toolbox /tmp/busybox
read ntime < /cache/timemachine
/tmp/busybox date -s $ntime -u
rm -f /tmp/busybox
fi

Then rename a current version of busy box for your platform to toolbox and THEN place it in /sbin in recovery.  Why?  Busybox is built into ClockworkMod and does not support date -s function like good standalone binaries do.

One other note:

To get this working reliably, I had to mount /cache early in recovery boot, so I added a mount statement in init.rc:

from the top, init.rc might look like this:

import /init.recovery.${ro.hardware}.rc

on early-init
start ueventd

on emmc-fs
mount ext4 /dev/block/mmcblk0p16 /cache nosuid nodev barrier=1

Your mount statements will need to be correct for your device, of course.

If permissions are set correctly, this should work fine.  This system is installed with the Burst Hack Kit for the Pantech Burst.

You dumbass, you flashed a froyo hboot on your HTC Inspire/DHD after we’ve warned NOT to for over a year. Here’s the fix:


You dumbass, you flashed a froyo hboot on your HTC Inspire/DHD shipped with gingerbread after we’ve been warning NOT to for over a year. And YES, the HTC ENG HBOOTS are Froyo ones.  Your phone takes forever to turn on, then it buzzes like cheap vibrator got hit by lightning for two or three minutes – then it finally begins to boot.  And IDGAF, you did this – not me.  You did not research very much, or you would have seen the shitstorm this has caused.  If you’re getting the idea that this topic pisses me off, then take comfort in the fact that maybe you are not a terminal dumbass, because you’d be right.

GREAT BIG HUGE DUMBASS @#$(*@%%! NOTE:

We didn’t get you into this mess, and the only reason I am posting this is so you LEAVE US THE HELL ALONE about it. Go whine to the person who is posting whatever screwed up thing got you to this point, not to us. You can talk about it amongst yourselves, you can take this and post it elsewhere, I don’t care – this is my last word on it. This is not supported by me or our IRC channels, so do NOT come asking about it. Here’s how to fix it:

  • Make a directory called IAMADUMBASS
  • Open a root or admin cmd prompt or terminal (depending on your OS) and navigate to directory IAMADUMBASS . Do NOT ask me how to do these things; this is NOT PC101 and I am NOT here to teach you how to use your PC.
  • Get this iamadumbass.zip , unzip it into the iamadumbass directory and install the windows drivers from the tools/windrivers folder in the archive.  Make sure the phone is NOT plugged in while installing the drivers.
  • Setup adb and fastboot if you haven’t already:
    • Windows:  open and cmd prompt as admin and run windows-setup.cmd (found in tools) from the cmd line.
    • Linux:  open a terminal and run ./linux-setup.sh from tools
    • OSX: open a terminal and run ./osx-setup.sh from tools
  • Boot your phone fully to the Android desktop
  • Plug in the usb cable to your computer and make sure usb debuggery is enabled.

Option One: This takes the best part of 65 minutes to complete, but works in almost every case where a. Good usb cables and connections exist and b. the PC configuration is not screwed up.  This method is the least likely to make a worse mess.

  • Remove your sdcard if it is not out already and leave it out until after the repair
  • From the  admin cmd prompt or root, execute the following commands in the IAMADUMBASS directory:
    • wget http://tau.shadowchild.nl/files/PD98IMG-HBFX.zip
    • md5sum PD98IMG-HBFX.zip   (Note: the md5sum MUST be d867e667061361f8a0b6b596d459a5dd – if it’s not, your download is corrupt. Fix your PC and try again)
    • adb reboot oem-78 ( Note: SKIP THIS IF YOU ARE COMING FROM Option Two.  This reboot will take some time. When it is complete, the screen will be black with large gray HTC letters on it. In the meantime, chant “I am a dumbass” over and over. This helps the mojo and and to pass the time. Allow a full 20 mintues before proceeding.)
    • fastboot flash zip PD98IMG-HBFX.zip  (Note: this will take a LONG time to complete – the best part of 45 mins.  Keep chanting to speed things up.)
    • When the above command completes it will say Okay near the end in your cmd prompt or terminal.  This means it was successful.
    • fastboot reboot (It does not matter that the green bar on the phone screen did not go all the way to the right.  The green bar is like boobs on a snake – interesting, but pretty much useless.)
    • Your phone is fixed.  Sorry, you’re still a dumbass

Option Two: This method is the ONLY method you should use if your phone will not boot to the desktop, and takes a long time (adds 25-35  mins) and continues with Option One.

  • Remove the SDCARD.
  • Unplug USB
  • Remove and replace the battery.
  • Put the phone into hboot (yes you can, if a Froyo hboot is the only issue)
    • Pull the battery
    • Press and hold vol-down FOREVER, then press power for about 45 seconds.
    • Keep holding that vol down key, it’s not forever yet.  yes, your thumb feels like it should fall off.
    • In 10 or 15 minutes, the phone should start and eventually get to hboot.  NOW it’s forever, and you can finally let go of the vol-down key. Chant I AM A DUMB ASS to increase mojo and pass time.
  • A few minutes after hboot starts, you should be able to navigate the hboot menu with the vol up/down keys.  Select fastboot and press the power button to excute the reboot to fastboot.  Keep chanting, this will take time – it’s rebooting again.  Plug in USB while this is all going on.
  • Once you have fastboot and can navigate THAT menu, enter the following command in a root term or admin cmd prompt:
    • fastboot oem reboot RUU    (Note: the command is case sensitive, it starts another reboot and another long wait – keep chanting.)
  • Now you can proceed back to Option One (^^^ THAT WAY, DUMBASS ^^^) and pick up from there.

Option Three: this method is much faster but works ONLY if you have radio S-OFF, S-OFF via the eng hboot, or have flashed RUU 1.31.405.6, it WILL NOT WORK OTHERWISE.

  • Put psneuter and gfree from iamadumbass/tools/bin and put them in directory IAMADUMBASS
  • UNZIP PD98IMG-HBFX.zip to directory IAMADUMBASS
  • Rename hboot_7230_Ace_0.85.0024_UnlockBL.nb0 to hboot.nb0
  • From an admin cmd prompt or root terminal, execute the following commands in the IAMADUMBASS directory (PC Consulting not provided)
    • wget http://tau.shadowchild.nl/files/PD98IMG-HBFX.zip
    •  md5sum hboot.nb0  (Note: this md5sum MUST be 709ee752782df6f8cd460783977a3b83 – if not, do not proceed.)
    • adb push hboot.nb0 /data/local/tmp/
    • adb push gfree /data/local/tmp/ (Note: not needed if you are s-off)
    • adb push psneuter /data/local/tmp/
    • adb shell chmod 0755 /data/local/tmp/gfree (not needed if you are s-off)
    • adb shell chmod 0755 /data/local/tmp/psneuter
    • adb shell /data/local/tmp/psneuter
    • adb shell /data/local/tmp/gfree -f  (Note: not needed if you are s-off)
    • adb shell
      • dd if=/data/local/tmp/hboot.nb0 of=/dev/block/mmcblk0p18
      • sync
      • dd if=/dev/block/mmcblk0p18 of=/data/local/tmp/hboot.test
      • exit
    • adb pull /data/local/tmp/hboot.test
    • md5sum hboot.test
  • md5sum for hboot.test should be 709ee752782df6f8cd460783977a3b83 .  If not, there may be a larger issue with your emmc.  You can retry adb pushing the hboot and then the dd and md5 commands without rebooting, but don’t ask us about it.  If the md5sum matches, you’re still a dumbass, but your phone is fixed.
  • adb reboot

So why not just flash a RUU?
A   Because mercifully, your miserable dumbass life will end before you see that RUU finish flashing.  Your hboot is in super slo-mo, and all the sand that’s passed through all the hourglasses since the dawn of time itself will not amount to how long it will take a full RUU to complete flashing. Well okay, maybe I am exaggerating just a little.