Related
Where is the BIOS in this thing? I get that it has /boot /system and /recovery but where is the firmware that the device very first utilizes?
Does the streak even have any type of NVRAM memory?
webdawg said:
Where is the BIOS in this thing? I get that it has /boot /system and /recovery but where is the firmware that the device very first utilizes?
Does the streak even have any type of NVRAM memory?
Click to expand...
Click to collapse
What are you attempting to do?
Understanding and Hacking
I am trying to understand the device and search for potential exploit vectors. If I take out the inner SD card what type of data does the device still have on it?
It has to have something that starts the boot from the inner SD card. Does this something insert anything into the running code on the device? Can it?
Can, if the device has the type of storage I am talking about, the device record and store even a small amount of data?
I have heard of reference to NAND backups and even seen a quote about how the NAND backup util included in the recovery utils does not backup something. The something I am referring to is not the external SD card.
Web...
Strephon Alkhalikoi said:
What are you attempting to do?
Click to expand...
Click to collapse
Why would you need exploit vectors when the system is completely open/unprotected?
the innerSD holds the /data and /cache partitions
It is like I am not making myself clear enough. A computer has a BIOS which passes boot to the OS/bootloader. Would not the phone have the same thing. If you do not know this answer do not ask anymore questions.
Stop asking why I am asking.
TheManii said:
Why would you need exploit vectors when the system is completely open/unprotected?
the innerSD holds the /data and /cache partitions
Click to expand...
Click to collapse
webdawg said:
It is like I am not making myself clear enough. A computer has a BIOS which passes boot to the OS/bootloader. Would not the phone have the same thing. If you do not know this answer do not ask anymore questions.
Stop asking why I am asking.
Click to expand...
Click to collapse
Unfortunately for you it seems you don't know what you're doing or why you're even asking about it
Sent from my GT-I9100 using Tapatalk 2
Okay Then
cdzo72 said:
Unfortunately for you it seems you don't know what you're doing or why you're even asking about it
Sent from my GT-I9100 using Tapatalk 2
Click to expand...
Click to collapse
Please. Unless you have an answer please do not reply. I know exactly what I am talking about. If the device does not have any NVRAM in it that one could flash to and only internal memory via SD card then just say this.
webdawg said:
It is like I am not making myself clear enough. A computer has a BIOS which passes boot to the OS/bootloader. Would not the phone have the same thing. If you do not know this answer do not ask anymore questions.
Stop asking why I am asking.
Click to expand...
Click to collapse
Manii knows far more about the Streak than you do, so if you want your questions answered, I suggest you check that attitude of yours at the door.
Strephon Alkhalikoi said:
Manii knows far more about the Streak than you do, so if you want your questions answered, I suggest you check that attitude of yours at the door.
Click to expand...
Click to collapse
Your right. Did not realize it was him, work has an affect on my attention. Sorry Manni.
I am at home now. Let me try and expain myself.
I just do not get it. All the pages I have read and the research I have done everything tells me that everything is stored on the internal SD card.
But I still have this nagging thought from this page: http://www.rdtk.net/2011/06/25/using-streakmod-recovery/ that says this: the firmwares reside on the nand but in an entirely separate area. only stock recoverys can write to them under normal circumstances, you can probably read/write them manually but it’s dangerous as you can super-brick if you don’t know what you’re doing
What the hell is that guy talking about? The way I read it is that an entire subset of firmware exists on the device that only that one webpage has ever talked about. (That I have read)
I have read alot about BIOS hacks and how they function inserting code into Windows. Even legitimate code for paid services. Computrace.
I know about the Carrier IQ software. What I do not know about is the software outside the rom, recovery, boot partitions and such that exists on the Dell streak or any Android device.
I suppose my attitude comes from the ton of forum posts that I read with unanswered questions because people wanted to know why the OP is asking such a question.
I took Manii's post the wrong way because of your question Steven. Not to offend you and I understand why you ask. For example I just hate going into support channels and asking questions about an iptable rule and being told that I should relearn Linux networking because...well just because I did not understand one concept. I took it the same way here.
I apologize to all.
Web...
MTD based nands are more complicated then eMMC nands in this aspect, as MTD nands you simply cannot read from the 'hidden' portions of the nand. eMMC ones you can.
eMMC devices you can always read from any eMMC partition, so you can likely make complete backups including your modem (though no custom recovery does this by default, it's still a bad idea)
Fortunately for us, MTD seems to be 'obsolete', every device that launched with GB installed or newer uses eMMC.
Dell Streak 5/Partition layout - XDA wiki
Dell Streak Pro/Partition layout - XDA wiki
The S5 is a MTD device, the SPro is eMMC, note how the SPro has many more partitions.
The majority of them also exist on the S5, but the only way to access them (safely) is though a stock recovery.
You can write to them with fastboot, but some of them must be unpacked by an updater in the stock recovery. Simply flash them (specific ones) and you'll super-brick that would require JTAGging at a minimum to fix.
You simply cant read the other MTD partitions without JTAGing (it might be possible with a specificly modified kernal, but you dont gain anything doing this, if at all), assuming that the hidden parts are MTD partitions even. For all we know the controller could be directly writing onto NAND pages with their locs hardcoded (which would kinda be like partitioning, but without the formal partition tables(?) )
There's also is a small amount of memory that can only be written (afaik) via JTAG.
It contains your device's ID, such as Service tag and IMEI.
On tegra devices (at least the S7 and S10) it's the WP1 and WP2 partition.
It could be possible that it's on the NAND as a MTD partition, but if it is we dont know about it. It would be insane (and illegal, as changing your IMEI is illegal in most countries) to write to it, but so there's never been an example of it. I dont know where they are on the SPro, i'd need a live device to check.
The modem OS itself is stored on the nand, the modem processor knows (or the bootloader knows) how to feed it it's OS image.
Location breakdown:
NAND: <everything on the partition layout above, including the below>
/system
/firstboot
boot.img
recovery.img
amss.mbn
appsboot.mbn
dbl.mbn
dsp1.mbn
fsbl.mbn
osbl.mbn
DT.img
The innerSD
/data
/cache
Modem storage (lock state)
Device unique data (IMEI and Service tag)
RTC (the clock)
I dont know the exact terminology or the exact order of booting on qualcomm snapdragons (it's likely to be the same with all at least in the same generation)
But it's something like:
Press power button
CPU powers up
IPL loads <hardwired onto cpu>
Check if innerSD is valid (this is streak specific, device also locks up if it fails as the loader isnt robust enough to work around it)
Init modem and it's firmware <amss.mbn on older devices, non_hlos.bin on newer devices> (FYI modems are themselves complete 'system's in that they have their own ram and OS, basebands are complete OS images in most devices)
Check what button combos are pressed
Start booting:
If you pressed the recovery mode combo:
Load recovery SPL <dbl.mbn? + DT.img>
Display SPL menu:
Reboot
Load Recovery ("update from update.pkg")
Read from recovery.img and load it
Caliberate screen
If you pressed fastboot mode combo:
Load the fastboot loader <fsbl.mbn?>
If you pressed the download mode combo:
Go into download mode (for QDLtool)
If you did not press any combo: begin booting normally
Load dsp1.mbn
Load boot.bin
Linux kernal mounts and starts reading:
/system
/cache
/firstboot
/data
Android boots normally
Boot completes, you're at the lockscreen/home screen
I'm just making educated guesses at which *.mbn does what, as noone's really studied them to the point that they are willing to modify them.
Regardless they're signed so you cant modify them (we dont know per-se that the CPU checks the signatures on *.mbns, but I dont think any is willing to risk their device to try anyway)
The kernal images arnt signed, you can simply toss any kernal that is valid (otherwise it wouldnt boot)
When your device boots, the logo flashes 4 times:
1st logo: IPL and it's logo (possibly hardwired onto chip)
2nd logo: SPL and it's logo (stored in one of the *.mbns)
3rd logo: UBOOT and the kernal logo (stored with the kernal, sounds like a band name)
4th logo: bootimage.zip (whatever boot splash is with the installed rom
TheManii,
Thanks for the information. This is everything I wanted to know. If I have anymore questions I will ask later.
Web...
Hi all,
Has anyone followed Rayman's excellent article the-inner-workings-of-secure-boot-key-and-nvflash and fully recovered a N7 from APX only mode?
I have this situation which I think resulted from the battery dying during the 4.4.2 update - Doh I know, but thought I had enough juice to complete the update.
Rayman says the required files will be made available but I cannot find them anywhere
Since every motherboard has a unique key, there is no generic blob. To be able to recover your N7, you will need a backup of it, but it's impossible to make if your device is dead.
Try to send it to Asus/Google.
Erovia said:
Since every motherboard has a unique key, there is no generic blob. To be able to recover your N7, you will need a backup of it, but it's impossible to make if your device is dead.
Try to send it to Asus/Google.
Click to expand...
Click to collapse
Did you read the article? Sounds like you can use the sbk which is a hash of the cpuid...
Nope, but why don't you ask around in the flatline topic?
Erovia said:
Nope, but why don't you ask around in the flatline topic?
Click to expand...
Click to collapse
too much of a noob to post on the forum, but thanks for the pointer.
FYI Raymans article. It does sound possible to bring it back, but there was no follow up with the required files;
What is Secure Boot Key and how does it work?
I've been getting lots of questions about this, so here is some simple background:
The secure boot key is an AES128 encryption key that can used to encrypt various data on the flash memory. It's a generic nvidia tegra2 thing, that the manufacturer can optionally use to make their device more "secure".
When the SBK is set, it's stored in a one-time-programmable "fuse". This also means that now that the key is out, they can't change it on already released devices, only new devices.
When the tegra2 starts up, the AES key is available to the hardware AES engine only. E.g. not even the bootloader can read it back! However, the bootloader can *use* the key to encrypt whatever data it wants through the hardware AES engine. And here is the explanation why the blob flashing method actually works! The bootloader checks for the blob in the staging partition and encrypts and flashes it as needed.
Once the bootloader is done, it clear the key from the AES engine which makes it impossible to encrypt or decrypt things from within the OS.
So what happens when it boots into APX/Nvflash mode?
The basic APX mode is stored in the BootROM and hence can never be changed. It appears to accept only a very limited range of commands, and each command needs to be encrypted using the SBK to be accepted. If it receives a command that's not properly encrypted, it disconnects the USB and appears to be off. This is the dreaded "0x4" error that people have been getting when attempting to get nvflash working.
It should be noted, that even with the SBK inputted into nvflash, most regular nvflash commands won't be available. I'm still not entirely sure why (and I can't rule out it will change).
What *is* available, is the nvflash --create command. What this command does is repartition and format all partitions, set bct and odmdata and send over all needed partitions to the device (and encrypt them as needed). This means a full recovery is possible, but regular ability to flash e.g. just boot.img or read partitions off of the device is not possible at this point.
So what do we need for nvflash?
In order to get a working (e.g. --create) nvflash, we need a few bits of information as well as some files:
◦Secure Boot Key
◦BCT file (boot device setup, ram configuration and a bit more)
◦ODM data (board-specific bit-field specifying various board settings. *Needs* to be correct
◦flash.cfg (e.g. list of settings and names/identifiers of partitions.
On top of these files, we also need all the partitions, e.g. bootloader.bin, boot.img, recovery.img and system.img. Luckily, these partition files are available in official ASUS updates and can be extracted from the blob file using my blob tools
The first four peices aren't readily available, but through lots of effort and a good deal of luck, we have managed to recreate the needed files. Secure Boot Key has already been released (note that this was by far the hardest!) and the rest will most likely follow over the weekend. Keep in mind that we want to keep this legal, so don't expect us to release any ready-made packs for unbricking! We will however make the recreated files available. Since these are recreated and not actual ASUS files, there should be no problems with them.
I hope this helps give a better understanding of how and what secure boot key is and what it gives us.
Hello everyone,
Please, just a question about repartitioning a PIT file via Odin. I´m a bit confused about information I have read about the result of the repartitioning operation.
In some forums appear to say the repartitioning operation via Odin is, first, a values rewriting of GPT entries, and after that any kind of formatting/wipe of all partitions.
In other words, if i repartition a PIT file exactly with the same values I have in my GPT table, does nothing occurs and the content of partitions keeps, or partitions data are lost?
Sorry about my english, and thank you for any answer you can give me.
D,
hi,
if i understand correctly, you would still be performing a repartition operation , which will destroy data during the process.
Although, if you have some experience with data/forensic recovery and can get the tools ported to your tab, it's likely
you may be able to recover a fair amount of what you lose without the data being corrupted.
That being said your repartitioning would need to succeed first.
The better approach for rescuing your data would be to pull the mmcblocks/partitions off of the device and onto
your pc [Linux] as img files through ADB [android debug bridge], BEFORE YOU PERFORM THE OPERATION.
That way if you fail in repartitioning [ which is highly likely]
your data will still be preserved on your pc. To be able to pull the information/data from the device, the device must be rooted
or have a custom recovery available with properly functioning access to/through adb for root functions and adb shell as root.
questions belong in q&a by the way.
m
hi,
if i understand correctly, you would still be performing a repartition operation , which will destroy data during the process.
Click to expand...
Click to collapse
Thank you for you answer. Well, what i´m trying to do is just an "experiment" resizing partitions. Of course there are other ways to do it, but what i´m thinking about is this:
Imagine the recovery partition was located in the first memory addresses, so, in one of the first GPT entries, and what i want to do is just modifiy size of last three partitions, so, three last entries in GPT table. If i create a new PIT file exactly with the same values that i have in the GPT table of the device but only modified values for the three last GPT entries, after perform a repartitioning via Odin and restart the device the recovery will be still there?
So, that is the sense of my question: Repartitioning does only write the values in the GPT table, or besides performs any kind of data lose in partitions (wipe,formatting...) ?
questions belong in q&a by the way.
m
Click to expand...
Click to collapse
Sorry and thank you, next time i´ll pay attention to it.
On older devices I had some success resizing partitions using parted in recovery mode via adb.
parted doesn't support ext4 as far as it's useful functions goes, you would have to create/resize any partition
as ext2 and reformat from there, cute approach but more hassle/trouble than it's worth.
for your experiment, be sure you can afford a new tab ! :silly:
i'm pretty sure your block layout is hardcoded in the bootloader. So you will probably end up creating
a very fashionable serving tray.
Meaning your device won't be able to find recovery partition, also there is likely a set amount of partitions allowed
by way of kernel if i remember correctly.
If your trying to get rid of that annoying no-execute permission in data thing, getting rid of FUSE would maybe get that done.
m
Thanks again for your answer. Experiment cancelled, currently no budget for a new tab.
Just a last -and sure a stupid- question, please: In your opinion, what would happen if i extract the PIT file from my device, and use itself to repartitioning via Odin? I mean, just specifying the PIT file and marking Re-Partition, other options (PDA,Phone,etc) unmarked? After restart, could work the tablet or I´ll get a brick?
Thanks again.
Regards.
D,
hi,
That's not a stupid question at all. I would suggest you read this thread all the way through
http://forum.xda-developers.com/tab-4/help/t530nu-pit-file-t2968498
also search via your preferred engine and XDA for terms/variations
samsung pit file signed odin heimdall
so far, the chances of repairing/modifying partition table on these newer devices [samsung] is slim/grim.
However maybe utilizing external/usb-otg storages to suit your needs would be a way to go. :good:
m
I am beyond ecstatic, after 3 months of research, trial and error, I fixed my tablet!!
I am pleased to announce a fix to the dreaded QDLOAD 9008 brick! I've written this tutorial on the one tablet experimented on (LG-V410 aka Gpad 7.0 LTE US ATT), but I'm pretty certain others may find this helpful to other qualcomm msm based devices.
Background: I maintain that I can fix anything I break so I did the worst thing and corrupted the data on my LG GPAD LTE 7.0 (V410). As a result the tablet wouldn't go into any mode, no lights, even when charging, no screen image or light, nothing. When I plugged it into my computer, it wasn't even recognized, windows told me the device was having a problem. After a little experimentation I got it recognized (held power while connected to power cycle) by the computer as "QD BULK". Further research I found some drivers for Qualcomm devices and got the computer to recognize it as "QDLOADER 9008". I thought this was great news but from there got no where. I tried qpst, qfuse, hyperterminal, LG B2C, LG SUPPORT TOOL, EFS Professional, miflash, blankflash, etc... everything I tried got me nowhere. After 3 months, It is now fully operational and apparently CARRIER UNLOCKED, talk about a pot of gold at the end of a rainbow!!
WORD OF WARNING: This is not a simple matter, 9008 most likely means your Grand Partition Table is corrupted, and the poor thing doesn't have a clue how to function. My method is NOT GUARANTEED in any way, I will not be responsible if you turn your paper weight of a device into permanent paper weight or half functioning paper weight etc...PROCEED WITH CAUTION, this is not for the feint of heart nor a simple fix!! You've been warned!
PreRequisites:
-Windows (for expanding the KDZ) (there may be a linux alternative to LGFirmwareExtract)
-Linux and some basic experience with dd and navigating the terminal (I used ubuntu) --(again, nearly everything I'm about to explain can probaly be translated to another os.)
-KDZ for your device. http://forum.xda-developers.com/g-pad-10/general/kdz-lg-g-pad-7-0-v410-t3224867
-Replacement aboot and boot (see attached)
-KDZ Extractor ---http://forum.xda-developers.com/showthread.php?t=2600575
-TWRP http://forum.xda-developers.com/g-pad-10/development/recovery-twrp2-8-5-0lgv400-410-t3049568
-Fasboot and ADB http://forum.xda-developers.com/showthread.php?t=2588979
-A modified rom like Cyanogen mod etc... http://download.cyanogenmod.org/?device=v410
-16GB microsd card + a way of directly writing to it (i.e. usb card reader etc..) a second one is helpful but not required.
-Most important, Patience, beer, more patience, and more beer...
To teach a man to fish, some pertinent understanding: First thing to understand is how your main board works. Personally I disassembled my device and cross referenced every chip to do this, Good news is you don't have to. When power goes to the device, the SoC (system on a chip) looks to built in storage media for booting instructions (think low level here) and that in turn fires up everything else and then loads your kernel etc... You may be aware, there are two different types of computer systems out there, the old method used a BIOS, and the current uses UEFI. Older machines, when power was given to the system, the BIOS was responsible for firing up peripherals and finding the bootloader etc... UEFI (Unified Extended Firmware Instruction) however, relies on firmware on storage media to do all that.
For example, an x86 PC with a bios, when power is given to the board, the bios runs the show, testing equipment and waking up devices, then when it's ready, it looks to external media for a little magic byte at the end of the first sector of that media to indicate that it is bootable and in turn will boot (let those instructions take over). This style of booting media is called MBR or Master Boot Record.
Modern machines and most mobile devices use GPT or global partition table. There are quite a few advantages to GPT one primary being the possibility of many many more primary partitions, (MBR was very limited). The GPAD 7 LTE has 34 partitions to put things in perspective. When your device is stuck in 9008 mode, it is because it doesn't have a clue how to boot, most likely your GPT is corrupted. Fortunately, at least with the Gpad 7.0 this information does not have to be on the onboard internal memory chip. For this fix we will be constructing an sdcard to have all this info to get into a mode capable of writing to the emmc.
Without Further Ado, Here are the steps:
]PLUG THE TABLET INTO A CHARGER while you do the following (you may think it's been off and fully charged, but in reality it's probably been trying to boot over and over again while looking lifeless)
1.) Get the KDZ for your device (stock firmware)
2.) Extract the DZ using LGFirmwareExtractor
3.) Extract all the .bin files from the DZ using LGFirmwareExtractor
3b.) V410 US LTE ONLY - Replace aboot and boot with the files I attatched --I was fortunate enough to back them up before I hosed my tablet and they proved invaluable as the ones in the KDZ I linked to were causing strange graphic issues.
4.) open a terminal in linux and dd the sdcard with the file you extracted called "PrimaryGPT...."
I.E. "sudo dd if=/PATHTODZFILES/PrimaryGPT_0.bin of=/dev/sdx" (BE CERTAIN of the of= path, you can find yourself with more problems if you get that wrong) (run "sudo fdisk -l | less" first to verify what your sdcard's path is.)
This is where it gets tedious...:
5.) Do some hand stretches and start charting all 34 partitions on paper. Your sdcard is now partitioned with GPT and you need to know the name of each partition and its path. I.e. ("Partition name: LAF Located at /dev/sdXx")
6.) now for the fun part: dd every .bin to the corresponding partition EXCEPT: laf.bin and any of the system_xxxxx.bin files. (laf disables fastboot and the next step will bring you to a useless LG firmware download mode)( I.e. sudo dd if=/PATHTODZFILES/laf_xxx.bin of=/dev/sdXx) If some fail out, don't fret too much, I'm currently uncertain which ones are required and don't feel like corrupting my tablet again to figure that out. If the next step doesn't work you may need to revisit this step and ensure everything was accurate. It's easy to write down the wrong location for a partition and throw everything off
7.)Unmount your sdcard and put it in the tablet
8.) Press and hold power and volume up...If all went well, there is suddenly life to your paperweight!! Congratulate yourself and prepare for more fun... If nothing happened, revisit the above steps, more than likely something got flashed to the wrong partition.
9.)Now that you have fastboot, plug your tablet into the computer and use the following command: "fastboot boot TWRP.img" (or whatever the name or path is for your downloaded TWRP image.
10.) You should now be in TWRP and now your device is ADB ready, we are close to the home stretch...
11.) Now we need to load up an sdcard with all those dz files (except for laf and system images) and the custom rom like cyanogen mod. (if you only have the one sdcard you can unmount it and remove it while the table is in TWRP...crazy right?, if you opt for this, reformat the sdcard to ext or fat or whatever you please so the tablet can see all the bin files) Then put the sdcard into the tablet. You may need to remount the card in twrp before proceeding...
12.) Now from your computer type the following command "adb shell".
13.) now just like you did with the sd card dd PrimaryGPT_0.bin to the internal memory card, with the following command: dd if=/sdcard/PrimaryGPT_0.bin of=/dev/block/mmcblk0
14.) Grab the paper you wrote all the partitions down on and start doing the same thing you did to the sdcard to your tablet. You'll adjust the following command accordingly: "dd if=/sdcard/PARTITIONNAME.bin of=/dev/block/mmcblkpX (X being the partition number)
(again skip all system bin's and laf_xxxx.bin. Flashing laf disables fastboot on LG devices.)
15.) now time to install your custom rom, go through the prompts, clear your cache, and delvik cache and choose power off.
If all went well, you now have a tablet again, that's unlocked too!!!!! If not, don't lose faith, revisit the steps and ensure you didn't mistype or overlook something, this is so tedious it's easy to do. For instance, if you mistype your of=xxx it will create the file instead and give no error.
Post with your success stories, questions or difficulties and I'll try to help.
Yours Truly,
TheKiln
UPDATE/WARNING: Do not at any time under any circumstances dd directly from your host computer to the internal memory on your tablet, only do this via the asb shell. This may render a mode that I have not yet found a fix to, I will be working on it soon but from initial observation may be more complicated then the above instructions. With any invasive hacks like this tutorial there is always the possibility of making matters worse, so exercise caution and patience.
Quick Update/Revision : I am actively experimenting with this device and wanted to share that if your sbl1 and sbl1b partition is corrupt I have confirmed it will also cause 9008 mode. Therefore, it may be best to determine if the table is corrupt (try "parted /dev/block/mmcblk print"), and if not instead of wiping rewriting mmcblk0 try restoring sbl1 and sbl1b first. The V410 boots in the following order from what I can tell slb1->aboot->boot->system. So far I haven't found a downside to my prior instructions but to be less invasive just in case it might be wise to try this amendment.
I know my grand partition is corrupt, because after doing fastboot erase, basically everything, it came up as /dev/sdb. In a panic, I had deleted all the partitions, so now obviously my emmc storage is one big formated 16gb HD that cannot be seen in windows or linux no longer.
I just tried your method, found this post by doing a google search for:
sudo dd if=PrimaryGPT_0.bin
Had been doing just this, including the laf and many other ways. Am still getting the same thing though when putting the sdcard in the tablet, shows a 0% battery.
with the sdcard in the tablet I do get:
Bus 003 Device 063: ID 05c6:f006 Qualcomm, Inc.
Then after a few minutes, leaving it plugged into the USB I get:
Bus 003 Device 058: ID 1004:61a1 LG Electronics, Inc.
Also, with the sdcard in I do get KDZ_FW_UPD_EN to start updating but then get a perimeter error.
bethnesbitt said:
I know my grand partition is corrupt, because after doing fastboot erase, basically everything, it came up as /dev/sdb. In a panic, I had deleted all the partitions, so now obviously my emmc storage is one big formated 16gb HD that cannot be seen in windows or linux no longer.
I just tried your method, found this post by doing a google search for:
sudo dd if=PrimaryGPT_0.bin
Had been doing just this, including the laf and many other ways. Am still getting the same thing though when putting the sdcard in the tablet, shows a 0% battery.
with the sdcard in the tablet I do get:
Bus 003 Device 063: ID 05c6:f006 Qualcomm, Inc.
Then after a few minutes, leaving it plugged into the USB I get:
Bus 003 Device 058: ID 1004:61a1 LG Electronics, Inc.
Also, with the sdcard in I do get KDZ_FW_UPD_EN to start updating but then get a perimeter error.
Click to expand...
Click to collapse
Ive seen the exact mode you are referring to. Three possibilities:
1.) unplugged, hold down the power button for 30 seconds (or less if fastboot comes up)
2.) your sd card does not have all the necessary partitions to boot (which i just confirmed are specifically rpm, rpmb, tz, tzb, sbl1, sbl1b, PrimaryGpt(has to be done first), aboot and abootb)
3) They didn't dd quite right. from my active testing Ive found if you script the dd'ing it doesn't quite flash right, unless you add a delay after each step.
Its actually a very good sign you are seeing the 0% battery logo, sounds like you are almost there. Let me know what happens. Ill be happy to help guide you. Ive dedicated my v410 as a dev board so Im constantly running tests and reverse engineering it.
The 0% only shows up with the sdcard in, after I remove it, nothing. Tried wall charging it all night, that did nothing.
My theory is that if there was some way to mount the raw emmc and dd the primarygpt.bin to the raw emmc hd then the rest would be not problem.
I deleted the original EMMC partitions in gparted under linux after doing an erase fastboot -w laf, system, etc... something like that. After that the tablet did not show up again in gparted as soon as I unplugged it.
Right now I'm zero dd'ing my 16gb sd card, dang dd'ing seems to glue the partitions to the sdcard, If I try to fdisk the sdcard or delete the partitions using gparted, as soon as I dd the primarygpt.bin the old files reappear. Need to start fresh with 0s to the card.
In windows I can actually install specific lg drivers while in qualcomm hs_usb 9008 mode. The interesting thing with the sdcard in I can install the LG Android Net USB serial driver, which will not work while in 9008 mode.
bethnesbitt said:
The 0% only shows up with the sdcard in, after I remove it, nothing. Tried wall charging it all night, that did nothing.
My theory is that if there was some way to mount the raw emmc and dd the primarygpt.bin to the raw emmc hd then the rest would be not problem.
I deleted the original EMMC partitions in gparted under linux after doing an erase fastboot -w laf, system, etc... something like that. After that the tablet did not show up again in gparted as soon as I unplugged it.
Right now I'm zero dd'ing my 16gb sd card, dang dd'ing seems to glue the partitions to the sdcard, If I try to fdisk the sdcard or delete the partitions using gparted, as soon as I dd the primarygpt.bin the old files reappear. Need to start fresh with 0s to the card.
In windows I can actually install specific lg drivers while in qualcomm hs_usb 9008 mode. The interesting thing with the sdcard in I can install the LG Android Net USB serial driver, which will not work while in 9008 mode.
Click to expand...
Click to collapse
The 0% comes up when your sdcard is inserted because you are close to getting it done. You're going to have your computer running all night on the zero'ing but I can assure you that will be in vein. The whole point of this tutorial is so you can get into a mode in which you can flash the emmc. I can tell you are a little lost in the steps so pm me and I'll help you out. Also a word to the wise, you can try all you want with windows and the 9008 drivers, but seriously there is nothing out there specific to the v410 thats going to help you "engage" the 9008 mode. Not being stubborn I've just literally tried it all. If it's any credit I am clinically OCD. I can't sleep till I figure things out.
Finally, I see a hope is shining here!
I bricked my LG VK810, when I was trying to flash twrp, I refered to v500 pad instead and I flashed wrong img files (aboot, boot, sb1, sb2, sb3, tz & twrp.img) "only those 6 files" so I only need to replace those with the correct files, which I downloaded now.
I do not have Ubuntu, however I have CentOS, which i have not used for couple of years, so I forgot how to use it. also do I still need to use the LG Firmware Extractor?
please help
thekiln said:
This is where it gets tedious...:
5.) Do some hand stretches and start charting all 34 partitions on paper. Your sdcard is now partitioned with GPT and you need to know the name of each partition and its path. I.e. ("Partition name: LAF Located at /dev/sdXx")
6.) now for the fun part: dd every .bin to the corresponding partition EXCEPT: laf.bin and any of the system_xxxxx.bin files. (laf disables fastboot and the next step will bring you to a useless LG firmware download mode)( I.e. sudo dd if=/PATHTODZFILES/laf_xxx.bin of=/dev/sdXx) If some fail out, don't fret too much, I'm currently uncertain which ones are required and don't feel like corrupting my tablet again to figure that out. If the next step doesn't work you may need to revisit this step and ensure everything was accurate. It's easy to write down the wrong location for a partition and throw everything off
Click to expand...
Click to collapse
Please please please help, how to do those steps!
nmnm4alll said:
Please please please help, how to do those steps!
Click to expand...
Click to collapse
I am not certain exactly which partitions have to be flashed, the attached note I made was from what I can tell so far. I was simply noting that it may be best to try one partition at a time vs doing them all at once, it is at your own descretion. So as far as listing the partitions, I'm not familuar with the centos distro but in Ubuntu it is something to the effect of fdisk /dev/sdb -l or gdisk /dev/sda then p. I hope that answers your question, If not please be more specific to your exact question.
thekiln said:
I am not certain exactly which partitions have to be flashed, the attached note I made was from what I can tell so far. I was simply noting that it may be best to try one partition at a time vs doing them all at once, it is at your own descretion. So as far as listing the partitions, I'm not familuar with the centos distro but in Ubuntu it is something to the effect of fdisk /dev/sdb -l or gdisk /dev/sda then p. I hope that answers your question, If not please be more specific to your exact question.
Click to expand...
Click to collapse
Thank you very much for your response, I am sorry I have never flashed partitions before, sbut I noticed gparted is not on CentOS, so I downloaded Puppy precise Linux as I was able to find gparted and I tried using it as shown in this video, https://www.youtube.com/watch?v=6z1Tu9l8WNc
But I am confused now about how big and what are the formats for the 34 partitions which need to be created?
nmnm4alll said:
Thank you very much for your response, I am sorry I have never flashed partitions before, sbut I noticed gparted is not on CentOS, so I downloaded Puppy precise Linux as I was able to find gparted and I tried using it as shown in this video, https://www.youtube.com/watch?v=6z1Tu9l8WNc
But I am confused now about how big and what are the formats for the 34 partitions which need to be created?
Click to expand...
Click to collapse
Flashing PrimaryGPT_0.bin will automatically create the partitions. Flashing the individual partitions will give each partition the data needed. There should be no need to manually create partitions, if no partitions show up in gparted, the problem goes back to primarygpt, as that is the partition table.
I am not quite sure what you mean by:
thekiln said:
5.) Do some hand stretches and start charting all 34 partitions on paper. Your sdcard is now partitioned with GPT and you need to know the name of each partition and its path. I.e. ("Partition name: LAF Located at /dev/sdXx")
Click to expand...
Click to collapse
how to can I get the Partition names?
Edit: I finally was able to get Ubuntu installed on my computer, so please instruct accordingly, sorry I have been googling everything you have mentioned in your OP with no luck!
Thanks in advance.
nmnm4alll said:
I am not quite sure what you mean by:
how to can I get the Partition names?
Edit: I finally was able to get Ubuntu installed on my computer, so please instruct accordingly, sorry I have been googling everything you have mentioned in your OP with no luck!
Thanks in advance.
Click to expand...
Click to collapse
For the names I like to use "parted /dev/sdb" then "print" (sdb being the location of the sd card, might be sdc, sdd, etc..)
thekiln said:
For the names I like to use "parted /dev/sdb" then "print" (sdb being the location of the sd card, might be sdc, sdd, etc..)
Click to expand...
Click to collapse
Thanks for the command line, I came up with this 36 partitions
https://www.dropbox.com/s/bw8nj317y3v7pw6/VirtualBox_Ubunto_05_01_2016_08_59_03.png?dl=0
now how do I know each partition's path?
you have mentioned "I.e. ("Partition name: LAF Located at /dev/sdXx")"
so do I type for example: "modem: LAF located at /dev/sdb1" (sdb1 is my sdcard's path)?
thekiln said:
6.) now for the fun part: dd every .bin to the corresponding partition EXCEPT: laf.bin and any of the system_xxxxx.bin files. (laf disables fastboot and the next step will bring you to a useless LG firmware download mode)( I.e. sudo dd if=/PATHTODZFILES/laf_xxx.bin of=/dev/sdXx) If some fail out, don't fret too much, I'm currently uncertain which ones are required and don't feel like corrupting my tablet again to figure that out. If the next step doesn't work you may need to revisit this step and ensure everything was accurate. It's easy to write down the wrong location for a partition and throw everything off
Click to expand...
Click to collapse
Those are the files got extracted from the DZ file
https://www.dropbox.com/s/z3ebiy4vvnsy9oo/Untitled.png?dl=0
and this is a screenshot in Ubuntu after copying the file on a 64 memory stick and mounting it
https://www.dropbox.com/s/gqn35n1npklq8ld/VirtualBox_Ubunto_05_01_2016_09_30_15.png?dl=0
Do I just type: "sudo dd if=/media/mike/MEMORY/aboot_153600.bin of=/dev/sdb1" and so on for all .bin files?
Please try to write command lines as I do not have experience with Linux
I'll be honest and blunt, if you do not have experience with linux, a simple keystroke mistake could wipe your entire computer. I can't in good conscience recommend touching dd if you're not familiar with it. Not trying to be condescending or anything just really dangerous tools we are working with here.
it have problem
wow !!! i can see the LG logo in my tablet !!!
but i can't run next step !!!
pushed power + volume up button but i never changed screen !!
This is written on the screen.
"boot certification verify"
please help me i copy 34 partition on SDcard after that what can i do? please answer , this does not work (( 8.) Press and hold power and volume up...If all went well, there is suddenly life to your paperweight!! Congratulate yourself and prepare for more fun... If nothing happened, revisit the above steps, more than likely something got flashed to the wrong partition.
Issue
Hello, I've successfully followed the tutorial until step 9. When i flash TWRP it reboots and comes back to the fastboot screen.
If I hold the vol+ button when it is booting, the download mode screen flashes for a second and then it comes back to the fastboot.
I haven't been able to to anything else and would be very grateful if someone could help me with this.
Apparently there is no bootloader so it is stuck
I attached a picture of my screen
LG G Pad 7.0 V400
Is there a way to unlock Qualcomm 9008 from LG V400?
Finally my dead tablet went into fastboot mode.
Except windows cannot find a fastboot driver and fastboot command can't locate the device either. Any suggestions?
So you followed a bad tutorial, or lost power during a flash, or formatted your unit for some reason and now you have a unit that seems mostly unresponsive. All hope may not be lost. You do have a backup, right??
If you don't have your own backup, you may be able to find one online somewhere that will work, but be aware that not all 8227L units are the same, and not every ROM dump you find online is going to work. At any rate, the issue is beyond the scope of this tutorial, so we'll proceed assuming you either have your own backup or have located a compatible one. I'm also going to assume that you have SP-Flashtool and have been able to use it, as it's fairly hard to end up with a bricked unit without using SP-Flashtool to begin with.
There are two different types of backup that can be relied on in this situation. The first, and probably more reliable backup format is a ROM dump from SP-Flashtool, consisting of 3 files, BOOT_1, BOOT_2, and EMMC_USER. They may be named something different. If SP-Flashtool's automatically suggested names were used, they could be named ROM_0, ROM_1 and ROM_2, in which case you'll need to pay attention to the file sizes. The other type is a group of many files, containing backups of the individual partitions, usually named boot.img, recovery.img, system.img, userdata.img, etc. In either case, you will also require a suitable scatter file, which you should have with your backup.
You're going to need to access the "test point" on your unit in order to flash your backup if you have flashed the wrong pre-loader or formatted the pre-loader partition. There is a chunk of read-only memory on the board containing the factory preloader, and that's what we'll be accessing to pull this off.
For information on disassembling your unit and accessing the test point, see my tutorial here on unlocking the bootloader.
Determine the process for reloading your backup based on the type of backup that you have and the state your system is in by reading the Getting Prepared section. The Flashing section will explain how to actually start the flashing process. It's important that you don't skip ahead! Ensure you've prepared everything correctly!
Getting prepared:
Remove all external power from the unit, and prepare SP-Flashtool with your scatter file and backup files. Do not connect the USB cable yet. If you are using system.img, userdata.img, recovery.img etc, make sure all the paths to the files are correct on the Download tab. As long as you have not attempted to modify the partition file, you can flash in Download Only mode, and you're good to go. If you have attempted to modify the partition table, the most reliable way to ensure that your backup loads correctly is to flash only your preloader first on the first pass, and then do another pass in Format All + Download mode with all of your files selected. After your preloader is restored, you should not need to use the test point for the second pass.
If your backup is a ROM dump, and you have a BOOT_1, BOOT_2, and EMMC_USER backup file, then you will need to use the "advanced mode" in SP-Flashtool to restore. While in SP-Flashtool, press Ctrl + Alt + v to enable advanced mode. Then from the Window menu at the top, check the box for Write Memory, and switch to the newly opened Write Memory tab. For the file path entry, browse or type the path to your BOOT_1 backup. Set the Begin Address to 0x0. After flashing BOOT_1, you will need to repeat the flashing process for BOOT_2 and EMMC_USER, but once BOOT_1 is flashed, your preloader is restored and you should not need to use the test point to restore the other files.
Flashing:
At this point, you should have SP-Flashtool prepared with your backup files and the unit should be disconnected from power and USB. In the next step you'll need to have the test point shorted as you plug the USB in, and remove the short when the tool connects to the factory preloader so get prepared to do that. If you're in the Download tab at this point, click the Download button, if you're in Write Memory mode, click the Write Memory button. SP-Flashtool will start looking for a device. Plug in your USB cable with the test point shorted on your board. Once SP-Flashtool recognizes the device, you usually need to give it a couple of seconds to initialize the connection before you remove the short. You may have to try a few times to get the timing right. If you remove the short too quickly or hold it in place for too long, the connection will fail and you'll need to try again. Once you get it right, it should begin flashing as normal. If you're only flashing your preloader on the first pass, you should not need to use the testpoint to get SP-Flashtool to recognize your device on subsequent passes. Finish reloading all of your backup files and you're done! You should have a functional device!
Very good information here. I've been reading a lot on these forums and it is safe to say that majority of people accidentally bricked their devices without having a backup but also Windows not installing MediaTek drivers properly.
iceblue1980 said:
Very good information here. I've been reading a lot on these forums and it is safe to say that majority of people accidentally bricked their devices without having a backup but also Windows not installing MediaTek drivers properly.
Click to expand...
Click to collapse
I'm a Linux user, so I'm not really a good person to ask about the Windows drivers... the best solution I can offer is, "Throw it out, install Linux," lol. Unfortunately a lot of useful and arguably required utilities for working with these units are Windows-only, so I'm working on developing a suite of cross-platform applications to replace them.
So I dismantled my bricked 8227L unit (accidentally formatted the Flash ROM with SP FLash Tools, but reckon the factory preloader is still there?) and before soldering the test points I wanted to ask couple of n00b questions:
1. When my unit is completely shut down (power disconnected), I insert the 4-pin USB cable and then connect it with my Win10 laptop through USB 2.0 but nothing happens. Nothing pops up, no new hardware detected. I have the latest MediaTek drivers installed. I also tried to insert a USB stick to the head unit just to see if there is any power or reading going on when the unit is on, and there is absolutely nothing. Can this mean my USB on the head unit is faulty?
2. Tried to look at pictures and look online how you actually "short" the test points. Some suggest just to put some solder on the golden plates, you say to connect one wire - but what do you do with the wire when connecting laptop to head unit through USB? Is that wire supposed to touch any other "golden plates"?
Thanks
I am so delighted to see someone hitting on the hot iron. Looking forward to the detailed tutorial to take backup, unlock bootloader, customize my radio.
I do have the scatter file to flash twrp but as I mentioned on other post that my radio is not detected in Sp flash tools when its off.
When I reboot it, it then gets detected for 2 seconds. I remember I did not remove the power cable may be this is why it's not fully powered off?
I'll try to remove the cable and check if it's get detected.
And then I will firstly start with the backup to stock rom just to be on safe side.
Just a noob question. Is stock backup possible before unlocking the bootloader?
I tried the test point and write memory, but I am getting an error. Attached is the screenshot.
threadreaper said:
So you followed a bad tutorial, or lost power during a flash, or formatted your unit for some reason and now you have a unit that seems mostly unresponsive. All hope may not be lost. You do have a backup, right??
If you don't have your own backup, you may be able to find one online somewhere that will work, but be aware that not all 8227L units are the same, and not every ROM dump you find online is going to work. At any rate, the issue is beyond the scope of this tutorial, so we'll proceed assuming you either have your own backup or have located a compatible one. I'm also going to assume that you have SP-Flashtool and have been able to use it, as it's fairly hard to end up with a bricked unit without using SP-Flashtool to begin with.
There are two different types of backup that can be relied on in this situation. The first, and probably more reliable backup format is a ROM dump from SP-Flashtool, consisting of 3 files, BOOT_1, BOOT_2, and EMMC_USER. They may be named something different. If SP-Flashtool's automatically suggested names were used, they could be named ROM_0, ROM_1 and ROM_2, in which case you'll need to pay attention to the file sizes. The other type is a group of many files, containing backups of the individual partitions, usually named boot.img, recovery.img, system.img, userdata.img, etc. In either case, you will also require a suitable scatter file, which you should have with your backup.
You're going to need to access the "test point" on your unit in order to flash your backup if you have flashed the wrong pre-loader or formatted the pre-loader partition. There is a chunk of read-only memory on the board containing the factory preloader, and that's what we'll be accessing to pull this off.
For information on disassembling your unit and accessing the test point, see my tutorial here on unlocking the bootloader.
Determine the process for reloading your backup based on the type of backup that you have and the state your system is in by reading the Getting Prepared section. The Flashing section will explain how to actually start the flashing process. It's important that you don't skip ahead! Ensure you've prepared everything correctly!
Getting prepared:
Remove all external power from the unit, and prepare SP-Flashtool with your scatter file and backup files. Do not connect the USB cable yet. If you are using system.img, userdata.img, recovery.img etc, make sure all the paths to the files are correct on the Download tab. As long as you have not attempted to modify the partition file, you can flash in Download Only mode, and you're good to go. If you have attempted to modify the partition table, the most reliable way to ensure that your backup loads correctly is to flash only your preloader first on the first pass, and then do another pass in Format All + Download mode with all of your files selected. After your preloader is restored, you should not need to use the test point for the second pass.
If your backup is a ROM dump, and you have a BOOT_1, BOOT_2, and EMMC_USER backup file, then you will need to use the "advanced mode" in SP-Flashtool to restore. While in SP-Flashtool, press Ctrl + Alt + v to enable advanced mode. Then from the Window menu at the top, check the box for Write Memory, and switch to the newly opened Write Memory tab. For the file path entry, browse or type the path to your BOOT_1 backup. Set the Begin Address to 0x0. After flashing BOOT_1, you will need to repeat the flashing process for BOOT_2 and EMMC_USER, but once BOOT_1 is flashed, your preloader is restored and you should not need to use the test point to restore the other files.
Flashing:
At this point, you should have SP-Flashtool prepared with your backup files and the unit should be disconnected from power and USB. In the next step you'll need to have the test point shorted as you plug the USB in, and remove the short when the tool connects to the factory preloader so get prepared to do that. If you're in the Download tab at this point, click the Download button, if you're in Write Memory mode, click the Write Memory button. SP-Flashtool will start looking for a device. Plug in your USB cable with the test point shorted on your board. Once SP-Flashtool recognizes the device, you usually need to give it a couple of seconds to initialize the connection before you remove the short. You may have to try a few times to get the timing right. If you remove the short too quickly or hold it in place for too long, the connection will fail and you'll need to try again. Once you get it right, it should begin flashing as normal. If you're only flashing your preloader on the first pass, you should not need to use the testpoint to get SP-Flashtool to recognize your device on subsequent passes. Finish reloading all of your backup files and you're done! You should have a functional device!
Click to expand...
Click to collapse
amit_coolcampus said:
I tried the test point and write memory, but I am getting an error. Attached is the screenshot.
Click to expand...
Click to collapse
Can you please look into it.
To be more precise:
1. I was able to restore my preloader from the EMMC_BOOT_1 backup.
2. Now I can see my device in device manager as well as in SP flash tools.
3. I tried to use "Formal all + Download" and "Firmware upgrade". With EMMC_user partition write memory. Both times I get the attached error.
4. I was able to restore EMMC_User . Itvgets completed successfully but radio doesn't boot up. Only black screen.
5. I also tried to download a few Firmwares and flash them but I get the same error. Even in download mode.
Error: S_FT_ENABLE_DRAM_FAIL (4032)
[EMI] Enable DRAM Failed!
[Hint]:
Please check your load matches to your target which is to be downloaded.
So precisely, I am able to flash only stock backed up ROM and that too in download mode.
threadreaper said:
So you followed a bad tutorial, or lost power during a flash, or formatted your unit for some reason and now you have a unit that seems mostly unresponsive. All hope may not be lost. You do have a backup, right??
If you don't have your own backup, you may be able to find one online somewhere that will work, but be aware that not all 8227L units are the same, and not every ROM dump you find online is going to work. At any rate, the issue is beyond the scope of this tutorial, so we'll proceed assuming you either have your own backup or have located a compatible one. I'm also going to assume that you have SP-Flashtool and have been able to use it, as it's fairly hard to end up with a bricked unit without using SP-Flashtool to begin with.
There are two different types of backup that can be relied on in this situation. The first, and probably more reliable backup format is a ROM dump from SP-Flashtool, consisting of 3 files, BOOT_1, BOOT_2, and EMMC_USER. They may be named something different. If SP-Flashtool's automatically suggested names were used, they could be named ROM_0, ROM_1 and ROM_2, in which case you'll need to pay attention to the file sizes. The other type is a group of many files, containing backups of the individual partitions, usually named boot.img, recovery.img, system.img, userdata.img, etc. In either case, you will also require a suitable scatter file, which you should have with your backup.
You're going to need to access the "test point" on your unit in order to flash your backup if you have flashed the wrong pre-loader or formatted the pre-loader partition. There is a chunk of read-only memory on the board containing the factory preloader, and that's what we'll be accessing to pull this off.
For information on disassembling your unit and accessing the test point, see my tutorial here on unlocking the bootloader.
Determine the process for reloading your backup based on the type of backup that you have and the state your system is in by reading the Getting Prepared section. The Flashing section will explain how to actually start the flashing process. It's important that you don't skip ahead! Ensure you've prepared everything correctly!
Getting prepared:
Remove all external power from the unit, and prepare SP-Flashtool with your scatter file and backup files. Do not connect the USB cable yet. If you are using system.img, userdata.img, recovery.img etc, make sure all the paths to the files are correct on the Download tab. As long as you have not attempted to modify the partition file, you can flash in Download Only mode, and you're good to go. If you have attempted to modify the partition table, the most reliable way to ensure that your backup loads correctly is to flash only your preloader first on the first pass, and then do another pass in Format All + Download mode with all of your files selected. After your preloader is restored, you should not need to use the test point for the second pass.
If your backup is a ROM dump, and you have a BOOT_1, BOOT_2, and EMMC_USER backup file, then you will need to use the "advanced mode" in SP-Flashtool to restore. While in SP-Flashtool, press Ctrl + Alt + v to enable advanced mode. Then from the Window menu at the top, check the box for Write Memory, and switch to the newly opened Write Memory tab. For the file path entry, browse or type the path to your BOOT_1 backup. Set the Begin Address to 0x0. After flashing BOOT_1, you will need to repeat the flashing process for BOOT_2 and EMMC_USER, but once BOOT_1 is flashed, your preloader is restored and you should not need to use the test point to restore the other files.
Flashing:
At this point, you should have SP-Flashtool prepared with your backup files and the unit should be disconnected from power and USB. In the next step you'll need to have the test point shorted as you plug the USB in, and remove the short when the tool connects to the factory preloader so get prepared to do that. If you're in the Download tab at this point, click the Download button, if you're in Write Memory mode, click the Write Memory button. SP-Flashtool will start looking for a device. Plug in your USB cable with the test point shorted on your board. Once SP-Flashtool recognizes the device, you usually need to give it a couple of seconds to initialize the connection before you remove the short. You may have to try a few times to get the timing right. If you remove the short too quickly or hold it in place for too long, the connection will fail and you'll need to try again. Once you get it right, it should begin flashing as normal. If you're only flashing your preloader on the first pass, you should not need to use the testpoint to get SP-Flashtool to recognize your device on subsequent passes. Finish reloading all of your backup files and you're done! You should have a functional device!
Click to expand...
Click to collapse
does the sgpt/pgpt partitions (the partition tables) need to be flashed?
I searched many forums but still feel lost. Can someone tell me how to create backup of my existing stock ROM without rooting it and unlocking bootloader.
I read there can be two types of backup. Is there any way to backup my stock ROM from adb or fastboot mode also?
threadreaper said:
So you followed a bad tutorial, or lost power during a flash, or formatted your unit for some reason and now you have a unit that seems mostly unresponsive. All hope may not be lost. You do have a backup, right??
If you don't have your own backup, you may be able to find one online somewhere that will work, but be aware that not all 8227L units are the same, and not every ROM dump you find online is going to work. At any rate, the issue is beyond the scope of this tutorial, so we'll proceed assuming you either have your own backup or have located a compatible one. I'm also going to assume that you have SP-Flashtool and have been able to use it, as it's fairly hard to end up with a bricked unit without using SP-Flashtool to begin with.
There are two different types of backup that can be relied on in this situation. The first, and probably more reliable backup format is a ROM dump from SP-Flashtool, consisting of 3 files, BOOT_1, BOOT_2, and EMMC_USER. They may be named something different. If SP-Flashtool's automatically suggested names were used, they could be named ROM_0, ROM_1 and ROM_2, in which case you'll need to pay attention to the file sizes. The other type is a group of many files, containing backups of the individual partitions, usually named boot.img, recovery.img, system.img, userdata.img, etc. In either case, you will also require a suitable scatter file, which you should have with your backup.
You're going to need to access the "test point" on your unit in order to flash your backup if you have flashed the wrong pre-loader or formatted the pre-loader partition. There is a chunk of read-only memory on the board containing the factory preloader, and that's what we'll be accessing to pull this off.
For information on disassembling your unit and accessing the test point, see my tutorial here on unlocking the bootloader.
Determine the process for reloading your backup based on the type of backup that you have and the state your system is in by reading the Getting Prepared section. The Flashing section will explain how to actually start the flashing process. It's important that you don't skip ahead! Ensure you've prepared everything correctly!
Getting prepared:
Remove all external power from the unit, and prepare SP-Flashtool with your scatter file and backup files. Do not connect the USB cable yet. If you are using system.img, userdata.img, recovery.img etc, make sure all the paths to the files are correct on the Download tab. As long as you have not attempted to modify the partition file, you can flash in Download Only mode, and you're good to go. If you have attempted to modify the partition table, the most reliable way to ensure that your backup loads correctly is to flash only your preloader first on the first pass, and then do another pass in Format All + Download mode with all of your files selected. After your preloader is restored, you should not need to use the test point for the second pass.
If your backup is a ROM dump, and you have a BOOT_1, BOOT_2, and EMMC_USER backup file, then you will need to use the "advanced mode" in SP-Flashtool to restore. While in SP-Flashtool, press Ctrl + Alt + v to enable advanced mode. Then from the Window menu at the top, check the box for Write Memory, and switch to the newly opened Write Memory tab. For the file path entry, browse or type the path to your BOOT_1 backup. Set the Begin Address to 0x0. After flashing BOOT_1, you will need to repeat the flashing process for BOOT_2 and EMMC_USER, but once BOOT_1 is flashed, your preloader is restored and you should not need to use the test point to restore the other files.
Flashing:
At this point, you should have SP-Flashtool prepared with your backup files and the unit should be disconnected from power and USB. In the next step you'll need to have the test point shorted as you plug the USB in, and remove the short when the tool connects to the factory preloader so get prepared to do that. If you're in the Download tab at this point, click the Download button, if you're in Write Memory mode, click the Write Memory button. SP-Flashtool will start looking for a device. Plug in your USB cable with the test point shorted on your board. Once SP-Flashtool recognizes the device, you usually need to give it a couple of seconds to initialize the connection before you remove the short. You may have to try a few times to get the timing right. If you remove the short too quickly or hold it in place for too long, the connection will fail and you'll need to try again. Once you get it right, it should begin flashing as normal. If you're only flashing your preloader on the first pass, you should not need to use the testpoint to get SP-Flashtool to recognize your device on subsequent passes. Finish reloading all of your backup files and you're done! You should have a functional device!
Click to expand...
Click to collapse
Hi I have made a video tutorial on how to make stock ROM backup using information from this forum. Hope it's helpful for everyone.
Hi friends,
Have you are observed overheating of touch panel of your car stereo or hangs in your Android car stereo or system not responding or application keep crashing etc.
Then this video is for you. I have done this small modification in my car.
I made a small hole on sides of AC vents such that cool air blows over the heat sink of Android car stereo and two cpu fans of 12V take power supply from same connector.
Whenever the car stereo is turned ON the fans also turn ON and blow cool air over the heat sink to keep it cool.
Hi I have made a updated video tutorial with added info on how to make stock ROM backup.
[UPDATE][ROM Dump] Stock ROM backup of Android Car Stereo | Memory Dump Procedure via flashtool
amit_coolcampus said:
Can you please look into it.
To be more precise:
1. I was able to restore my preloader from the EMMC_BOOT_1 backup.
2. Now I can see my device in device manager as well as in SP flash tools.
3. I tried to use "Formal all + Download" and "Firmware upgrade". With EMMC_user partition write memory. Both times I get the attached error.
4. I was able to restore EMMC_User . Itvgets completed successfully but radio doesn't boot up. Only black screen.
5. I also tried to download a few Firmwares and flash them but I get the same error. Even in download mode.
Error: S_FT_ENABLE_DRAM_FAIL (4032)
[EMI] Enable DRAM Failed!
[Hint]:
Please check your load matches to your target which is to be downloaded.
So precisely, I am able to flash only stock backed up ROM and that too in download mode.
Click to expand...
Click to collapse
How did your computer see it again? I can't do it.
The sp flash tools cant read my device, ive press the down button, the up button but still it doesnt detected.
Is it because ive load a different scattered file or not suitable file?
Can you give me a hint?
Ive just brick my device because flash wrong file and i dont have any backup.
Please help me, thanks in advance.
threadreaper said:
So you followed a bad tutorial, or lost power during a flash, or formatted your unit for some reason and now you have a unit that seems mostly unresponsive. All hope may not be lost. You do have a backup, right??
If you don't have your own backup, you may be able to find one online somewhere that will work, but be aware that not all 8227L units are the same, and not every ROM dump you find online is going to work. At any rate, the issue is beyond the scope of this tutorial, so we'll proceed assuming you either have your own backup or have located a compatible one. I'm also going to assume that you have SP-Flashtool and have been able to use it, as it's fairly hard to end up with a bricked unit without using SP-Flashtool to begin with.
There are two different types of backup that can be relied on in this situation. The first, and probably more reliable backup format is a ROM dump from SP-Flashtool, consisting of 3 files, BOOT_1, BOOT_2, and EMMC_USER. They may be named something different. If SP-Flashtool's automatically suggested names were used, they could be named ROM_0, ROM_1 and ROM_2, in which case you'll need to pay attention to the file sizes. The other type is a group of many files, containing backups of the individual partitions, usually named boot.img, recovery.img, system.img, userdata.img, etc. In either case, you will also require a suitable scatter file, which you should have with your backup.
You're going to need to access the "test point" on your unit in order to flash your backup if you have flashed the wrong pre-loader or formatted the pre-loader partition. There is a chunk of read-only memory on the board containing the factory preloader, and that's what we'll be accessing to pull this off.
For information on disassembling your unit and accessing the test point, see my tutorial here on unlocking the bootloader.
Determine the process for reloading your backup based on the type of backup that you have and the state your system is in by reading the Getting Prepared section. The Flashing section will explain how to actually start the flashing process. It's important that you don't skip ahead! Ensure you've prepared everything correctly!
Getting prepared:
Remove all external power from the unit, and prepare SP-Flashtool with your scatter file and backup files. Do not connect the USB cable yet. If you are using system.img, userdata.img, recovery.img etc, make sure all the paths to the files are correct on the Download tab. As long as you have not attempted to modify the partition file, you can flash in Download Only mode, and you're good to go. If you have attempted to modify the partition table, the most reliable way to ensure that your backup loads correctly is to flash only your preloader first on the first pass, and then do another pass in Format All + Download mode with all of your files selected. After your preloader is restored, you should not need to use the test point for the second pass.
If your backup is a ROM dump, and you have a BOOT_1, BOOT_2, and EMMC_USER backup file, then you will need to use the "advanced mode" in SP-Flashtool to restore. While in SP-Flashtool, press Ctrl + Alt + v to enable advanced mode. Then from the Window menu at the top, check the box for Write Memory, and switch to the newly opened Write Memory tab. For the file path entry, browse or type the path to your BOOT_1 backup. Set the Begin Address to 0x0. After flashing BOOT_1, you will need to repeat the flashing process for BOOT_2 and EMMC_USER, but once BOOT_1 is flashed, your preloader is restored and you should not need to use the test point to restore the other files.
Flashing:
At this point, you should have SP-Flashtool prepared with your backup files and the unit should be disconnected from power and USB. In the next step you'll need to have the test point shorted as you plug the USB in, and remove the short when the tool connects to the factory preloader so get prepared to do that. If you're in the Download tab at this point, click the Download button, if you're in Write Memory mode, click the Write Memory button. SP-Flashtool will start looking for a device. Plug in your USB cable with the test point shorted on your board. Once SP-Flashtool recognizes the device, you usually need to give it a couple of seconds to initialize the connection before you remove the short. You may have to try a few times to get the timing right. If you remove the short too quickly or hold it in place for too long, the connection will fail and you'll need to try again. Once you get it right, it should begin flashing as normal. If you're only flashing your preloader on the first pass, you should not need to use the testpoint to get SP-Flashtool to recognize your device on subsequent passes. Finish reloading all of your backup files and you're done! You should have a functional device!
Click to expand...
Click to collapse
Watch this new video guide that shows how to successfully restore your head unit using Test Point recovery.
somebody can help me how I find test point??
denin84 said:
somebody can help me how I find test point??
Click to expand...
Click to collapse
What kind of head unit do you have?
iceblue1980 said:
What kind of head unit do you have?
Click to expand...
Click to collapse
AC8227L ZXDZ 01 sir
denin84 said:
AC8227L ZXDZ 01 sir
Click to expand...
Click to collapse
I will reply in your other post.
Hi,
I think I have bricked my alps FF-5000 8227L device
I did the following steps before this happened:
1. I flashed the HU with this firmware: 8227L_8_UI04-国外11_v1_20210421 UPDATE.zip link
2. The process was successful, everything worked fine, but the screen resolution was much bigger than the device native resolution.
3. I found a possible solution in another forum, according to that I uploaded the attaced files in the zip to the system.
4. This process was also successful but after that the system didn't boot anymore. I can see only black screen with backlit.
I'm not sure what and why happened but I would like to know if there is any solution to fix this or the only one possible way is the test point method recovery.
And yeah, I don't have any dump from the rom. No backups.
Also attached a screen from the stock fw version.