Related
>>>> In a post further down, I have released a updated zip file which contains the 2ndihkvc program as well as its source as well as few support scripts to allow experimentation with this mechanism of multiple user spaces <<<<
Hi All
I have been following the below thread, as well as working on my own on some of the concepts. You can get the details till now from my posts in the below thread.
http://forum.xda-developers.com/showthread.php?t=1378886
I was not able to get the SETREGS to succeed in setting PC required for the current/existing 2nd-init logic, nor wait was waiting to lock the process, SO I tried a new and simpler alternate method for triggering/execve the init process a 2nd time using only POKE and it seems to have succeeded. I am guessing this based on my nooktablet having got messed up and it keeps rebooting again and again when it reaches my logic potentially. I have to restore back to factory settings and try afresh in the morning (Well it is almost morning ;-) now here) with few more debug messages to pin point it fully.
The code I am injecting directly into init process is in the attached txt file which is actually a .s (assembly file). (NOTE: Currently I am not handling environment variables, not sure if that is causing my boot to keep looping).
In turn the logic to hijack the init process and inject the code is as simple as
Step1) PTRACE_ATTACH
Step2) PTRACE_GETREGS
Step3) PTRACE_POKETEXT (Regs.ARM_pc, code to inject)
Step4) PTRACE_CONT
Step5) PTRACE_DETACH
I will upload the code in a day or two - however the jist of the logic is above, if anyone wants to experiment on their own.
NOTE: The code is very simple and experimental and expects the pc address to be known before hand to massage the .s file appropriately.
NOTE: The above algo with the corresponding .s file is still EXPERIMENTAL and also requires additional shell scripts to get access to the boot flow to trigger the hijack. And the current code will break the nooktab booting, so don't experiment this logic and the .s file unless you know what you are doing.
NOTE: I am not that much into Custom Roms etc, so don't expect anything much shortly wrt Custom Roms etc, this is just a experimentation for myself and to feel happy inspite of BN removing some useful features like sideloading as well as forcing a signed bootloader on everyone.
can you make a 2-init zip like on the milestone
http://forum.xda-developers.com/showthread.php?t=998425
because then the devs can go on and make a recovery
Bit more exploration with init hijacking - 2ndihkvc src package for EXPERIMENTATION
Hi,
NOTE: Source code package is attached with this message. However this is WIP and provided for anyone wanting to EXPERIMENT on their own parallel to me. Because I think the basic logic is done now. It is more of cleaning up the init rc files and or killing some additional tasks before restarting init or some such things HOPEFULLY (NO harm in hoping and being positive . HOWEVER NOTE that the current version will loop your boot and fail. I have put a timed triggering logic to try and reduce the risk, check out the documents in the package, but it can factory reset or worst case wipe your partitions and render the nooktab dead.
After yesterdays initial init hijacking, I have cleaned up the .s file so that it passes the Args properly as well as added the environment variables set by Android by default. Also the ptrace code I have updated to do relocation (using a simple custom table) of injected code. Also rather than a minimal ptrace code, I have put a bit more full fledged one with my logic as well as skrilax's logic as well as reg dumping and few other stuff to help experimenters.
In turn I have cross verified, that init is actually getting restarted and it is running thro the scripts and setting up the properties as specified by my modified default.prop as well as in the process rerunning all the commands/services/prgs.
However some where beyond rild/vold sequence it seems to be blocking and looping the boot. Also I had modified the init a bit, have to check that also once later.
Enjoy and experiment
NOTE: Not sure how to avoid having to put the same message in two threads. I created this thread only becasue the original thread was in the wrong category (i.e non development), when it should have been in development also.
This is interesting. I have minimal experience with assembly, none of it ARM. I would like to help, if possible. I appreciate the work you have put into this. I'm really hoping to be able to have CM7 on this tablet eventually.
Sent from my BNTV250 using xda premium
Potentially working Alternate Userspace in uSD using 2ndihkvc
Hi All,
I have updated my 2ndihkvc package a bit more and now you can boot into a ALTERNATE Android user space in uSD (NOTE: Userspace only and not kernel - locked bootloader doesn't allow alternate kernel).
For this you require to copy your required android /system and /data partitions into a MicroSD card in its 2nd and 3rd partitions which should be ext4 (specified in the init.omap4430.rc file in 2ndihkvc directory).
NOTE: Best way of getting a working /system and /data partitions is to ==> After rooting your Nook and removing all unwanted Apps/Junk, make a copy of the /system partition from eMMC to uSD. Same for /data/partition. Then you can copy what ever additional applications you want in this uSD based Android /system/app or /data/app partition. Thus you can have different sets of Android user space in different uSD cards.
Follow the instructions in INSTALL file for experimenting this on your rooted NookTab. BUT REMEMBER IT IS STILL EXPERIMENTAL. ALSO as a SAFETY FEATURE, as of now it will boot into this ALTERNATE MODE (in uSD) only when the current HOUR is specified in the start2ndihkvc.sh file appropriately. Otherwise it tries to boot into the your normal Andorid system in eMMC. This should hopefull CATCH any mistake, BUT THIS IS NOT GUARENTEED AND THIS IS A DANGEROUS THING TO EXPERIMENT, UNLESS YOU KNOW WHAT YOU ARE DOING.
NOTE: One time it did reboot from my alternate android system, I haven't debugged this yet, as it has not occured after it (Well I have tried only once more) so cann't say one way or the other yet. But definitely, there are some corner cases.
NOTE: If something gets messed up or if something is different or even if there is some corner case in my code, which I haven't handled yet, it may MESS UP your NOOK TAB so EXPERIMENT WITH THIS only if you know how to recover on your own, provided the NOOKTAB is recoverable (90% should be, but NO GAURENTEE).
Now the BRAVE HEARTS can experiment and Enjoy a alternate Andorid system in uSD card.
NOTE: With this one should be able to boot into any Custom ROM after suitable updation of the scripts in my zip file, as well as by copying their /system and /data/ partitions into uSD 2nd and 3rd partitions. AS long AS that Custome ROM doesn't have any specific kernel requirements.
BYPASS Kernel and Ramdisk check for People with UART ACCESS
Hi,
NOTE: THis is based on a initial look at the source code and then the objdump of u-boot.bin. I haven't cross checked this yet, because for now I haven't opened up the nooktab for uart access yet. Also this assumes by default booti command is used for booting in BN uboot. If some one wants to use bootm, then a different location requires to be patched wrt the image loading security check.
If you are a lucky ;-) person working with opened up NookTab with UART access, then basically replacing the memory contents of these two offsets with NOP will 90% BYPASS the security check successfully and allow you to boot a MODIFIED KERNEL or RAMDISK as required.
All offsets specified Assuming u-boot is loaded at 0 (adjust for the actual address where u-boot.bin is loaded, haven't looked into that yet).
Check for Security check of Kernel image is at
[ORIG] 0x48c0 => bne 0x48d8 (0x1a00.0004)
Make this a NOP by overwriting using uboot memory write command to
[MODI] 0x48c0 => mov r0, r0 (0xe1a0.0000)
Check for Security check of RAMDisk image is at
[ORIG] 0x4928 => bne 0x4958 (1a00.000a)
Make this a NOP by overwriting with
[MODI] 0x4928 => mov r0, r0 (0xe1a0.0000)
Someone (Hi Adamoutler, maybe you) with opened up NookTab can try this and tell me if it worked or not.
NOTE: you have to add up the actual u-boot load address to the offsets specified.
UPDATE1: It appears the load address is either
Possibility 1) 0x80e8.0000 OR
Possibility 2) 0x80e8.0000-0x120 (More likely).
Have to dig thro bit more, but one of these two will potentially work.
So that means to NOP RAMDisk security check the offset is
Possibility 1 ==> 0x80e8.0000+0x4928
Possibility 2 ==> 0x80e8.0000-0x120+0x4928 (More likely)
Best is to cross check if the resultant address contains the BNE instruction bytes specified above.
Same concept applies for the Kernel security check Nopping offset.
NOTE: It appears there is a 0x120 size header before the actual u-boot.bin code starts and in turn, when I did the objdump, it included the 0x120 bytes of header also assumed as code. And inturn the full (including the header) u-boot.bin or for that matter the u-boot from emmc seems to load into 0x80e8.0000-0x120.
UPDATE 2:
Code around the locations to be noped to help identify the same in memory, in case my offset calculations are wrong
48b4: eb0030f1 bl 0x10c80
48b8: e59d3010 ldr r3, [sp, #16]
48bc: e3530000 cmp r3, #0
48c0: 1a000004 bne 0x48d8
48c4: e59f0104 ldr r0, [pc, #260] ; 0x49d0
48c8: e594100c ldr r1, [r4, #12]
48cc: e5942008 ldr r2, [r4, #8]
48d0: eb0015db bl 0xa044
............
491c: eb0030d7 bl 0x10c80
4920: e59d3010 ldr r3, [sp, #16]
4924: e3530000 cmp r3, #0
4928: 1a00000a bne 0x4958
492c: e59f00a4 ldr r0, [pc, #164] ; 0x49d8
4930: e5941014 ldr r1, [r4, #20]
4934: e5942010 ldr r2, [r4, #16]
4938: eb0015c1 bl 0xa044
UPDATE 3: ... for a rainy day in future ;-)
UPDATE 4: For maximum success, first try a changed RAMDisk rather than Changed Kernel. If Changed Ramdisk works then try Changed Kernel (THere is one more thing in Code, which I am not sure if it will impact a modified kernel or not yet, only way is to experiment).
How can I run 2ndihkvc just to load a new default.prop using the existing userspace? What I did so far was to remount / in rw, updated default.prop, pushed 2ndihkvc to /data/local/, changed permissions to 755 and executed. Here is the output
Code:
# ./2ndihkvc -p 1 -w 0 -c 0 -m 2
INFO:2ndihkvc:v30Dec_2020:
INFO:2ndihkvc: Tracing process with pid = 1
INFO:2ndihkvc: NewPrg = /init
WARN: RESPECT_WAIT disabled
WARN: Mode = MODE_INJECT_HKVC2
INFO: ContType = CONTINUE
INFO:2ndihkvc:PTRACE: Attached to (1)
INFO:2ndihkvc: Giving 2 secs to the likely traced process
ERROR:2ndihkvc:WAIT:Failed (No child processes)
INFO:2ndihkvc:hkvc2: InjectAddr (Regs->ARM_pc) = 0xffff0520
INFO:2ndihkvc:hkvc2: /init found at offset 0x100
INFO:2ndihkvc:hkvc2:ProgramToExecute: /init replaced with /init
INFO:2ndihkvc:hkvc2: At offset 0x208 relocating from 0x100 to 0xffff0620
INFO:2ndihkvc:hkvc2: At offset 0x200 relocating from 0x208 to 0xffff0728
INFO:2ndihkvc:hkvc2: At offset 0x280 relocating from 0x288 to 0xffff07a8
INFO:2ndihkvc:hkvc2: At offset 0x288 relocating from 0x300 to 0xffff0820
INFO:2ndihkvc:hkvc2: At offset 0x28c relocating from 0x307 to 0xffff0827
INFO:2ndihkvc:hkvc2: At offset 0x290 relocating from 0x312 to 0xffff0832
ERROR:PTRACE:POKE failed at location ffff0520
INFO:2ndihkvc:PTRACE: Continue/SingleStep ...
INFO:2ndihkvc: Detaching...
ERROR:2ndihkvc:PTRACE: Failed DETACH (No such process)
#
Do I need to push your init to /system/2ndihkvc/init? I am just trying to play around with it and Adam's BHT just to see what I can do them. Thanks.
Hi Brianf21,
As specified in the INSTALL file with in my zip
Copy my 2ndihkvc.zip file to /data/local/tmp
Then mount /system in rw mode.
Next unzip 2ndihkvc.zip into /system. It should create 2ndihkvc folder.
Next run ./install.sh from with in 2ndihkvc folder.
This will setup the boot process to start into 2ndihkvc. And it inturn will restart init with new set of init.*.rc as well as default.prop files.
Have a look at the 2ndihkvc folder, it already contains a default.prop file. If you want to change anything in default.prop then do the changes in this default.prop in /system/2ndihkvc folder.
Also remember to change the time check in start2ndihkvc.sh file in /system/2ndihkvc folder to the current hour, when you will be experimenting. Otherwise, it will not run 2ndihkvc, but continue with the normal Android init flow.
Cross check my INSTALL file once again for the details/steps to setup 2ndihkvc.
Once you have done the above. When you restart your system, it will trigger 2ndihkvc as required and the default.prop will be the new one which you would have edited/updated in /system/2ndihkvc/ folder.
NOTE: Looking at the address, it seems like you had tried 2ndihkvc once before in the same session. Try following the install step specified above/In the 2ndihkvc zip file and see. There is a minimally modified version of init.omap4430.rc and default.prop already in the 2ndihkvc folder, modify those if you want to modify them. This is because start2ndihkvc.sh will copy these files from /system/2ndihkvc/ folder when it is run to restart init.
I will have to read more, to avoid setting up system and data up on an sdcard. Once the setup is done, will it always hijack init for every following boot until it is removed or only one reboot? i am just to get a clearer picture of what's going on, I wanted to just see the hijack of init work independently of the other processes.. I kind of like to break things down into parts so I can get a better understanding of the entire process. Thanks for the work you've out in so far.
hkvc said:
Hi Brian21,
As specified in the INSTALL file with in my zip
Copy my 2ndihkvc.zip file to /data/local/tmp
Then mount /system in rw mode.
Next unzip 2ndihkvc.zip into /system. It should create 2ndihkvc folder.
Next run ./install.sh from with in 2ndihkvc folder.
This will setup the boot process to start into 2ndihkvc. And it inturn will restart init with new set of init.*.rc as well as default.prop files.
Have a look at the 2ndihkvc folder, it already contains a default.prop file. If you want to change anything in default.prop then do the changes in this default.prop in /system/2ndihkvc folder.
Also remember to change the time check in start2ndihkvc.sh file in /system/2ndihkvc folder to the current hour, when you will be experimenting. Otherwise, it will not run 2ndihkvc, but continue with the normal Android init flow.
Cross check my INSTALL file once again for the details/steps to setup 2ndihkvc.
Once you have done the above. When you restart your system, it will trigger 2ndihkvc as required and the default.prop will be the new one which you would have edited/updated in /system/2ndihkvc/ folder.
NOTE: Looking at the address, it seems like you had tried 2ndihkvc once before in the same session. Try following the install step specified above/In the 2ndihkvc zip file and see. There is a minimally modified version of init.omap4430.rc and default.prop already in the 2ndihkvc folder, modify those if you want to modify them. This is because start2ndihkvc.sh will copy these files from /system/2ndihkvc/ folder when it is run to restart init.
Click to expand...
Click to collapse
brianf21 said:
I will have to read more, to avoid setting up system and data up on an sdcard. Once the setup is done, will it always hijack init for every following boot until it is removed or only one reboot? i am just to get a clearer picture of what's going on, I wanted to just see the hijack of init work independently of the other processes.. I kind of like to break things down into parts so I can get a better understanding of the entire process. Thanks for the work you've out in so far.
Click to expand...
Click to collapse
If all you are interested is run 2ndihkvc with a modified default.prop but no other modification (i.e no uSD /system and /data partitions), then
a) overwrite the init.omap4430.rc in /system/2ndihkvc with the one in / . However if you have already booted into a system with 2ndihkvc then in /data/local/tmp.
Or if required you can directly edit the init.omap4430.rc in /system/2ndihkvc and update the mount commands in there to mount from emmc instead of uSD.
b) Remove the 2 lines in restart-userspace.sh corresponding to mount -o move ....
This will allow you to boot into a system with a modified default.prop but no other change from a runtime perspective (unless I have forgotten something).
Also 2ndihkvc will be applied each time boot into NookTab provided the current hour matches the hour set in start2ndihkvc.sh. Once the current hour no longer matches the hour set in the sh file, it will boot into the normal BN Nooktab environment.
NOTE: I purposefully modified the init.omap4430.rc file to replace the /system and /data from emmc to uSD, so that if someone is experimenting something, he doesn't corrupt the emmc easily as long as he doesn't become root user. HOWEVER with root access emmc can still get corrupted if one is not careful, because eMMC is still available and mounted.
tried but rebooted few times until factory reset kicked in
Hi,
ok. maybe a bit too optimistic, but I compiled ICS for pandaboard and put the system to sd card (partition 1 ext4 empty, partion 2 ext4 system with panda stuff, partion 3 data, partition 4 empty).
I hit adb reboot and the device booted a few times until it restored factory. Uff.
Is there a way without serial console to see what happens?
There's also small glitch in install.sh. It doesn't find init.rc in /system/2ndihkvc.
Rgds,
Chris
chrmhoffmann said:
Hi,
The device booted a few times until it restored factory. Uff.
Click to expand...
Click to collapse
If it's counting boots like the Nook Color you can stop it by running this (if the rom partition is mounted at /rom-- it's p2 on nc and I guess p5 on nt).
chrmhoffmann said:
Hi,
ok. maybe a bit too optimistic, but I compiled ICS for pandaboard and put the system to sd card (partition 1 ext4 empty, partion 2 ext4 system with panda stuff, partion 3 data, partition 4 empty).
I hit adb reboot and the device booted a few times until it restored factory. Uff.
Is there a way without serial console to see what happens?
There's also small glitch in install.sh. It doesn't find init.rc in /system/2ndihkvc.
Rgds,
Chris
Click to expand...
Click to collapse
Hi,
The missing init.rc is not a glitch, I purposefully left it out while packaging, so that one doesn't modify it drastically and botch up the boot. init.4430.rc is the only thing required to change the mount partitions.
Also if you are using my default start2ndihkvc.sh script, then it has a time check, so while xperimenting if you have goofed up. Just let the time you have set in this script pass by (i.e don't power on), then it will automatically go back to the stock NT boot, thus avoiding the factory reset.
I merged the latest B&N 1.4.2 code into my 2nduboot git repository on github: https://github.com/bauwks/Nook-Tablet
It still compiles and works on my 16GB NT and others have have successfully booted the 8GB NT model.
The instructions for building are the same as before:
cd distro/u-boot
PATH=/usr/local/arm-2010q1/bin:$PATH
make nt2ndboot_sd_config
make
./tools/build_nt_2ndboot_img.py -o test.img u-boot.bin
cp test.img /media/boot/flashing_boot.img
For those of you that wish to try it without messy compilers, this zip file (http://dl.dropbox.com/u/40331061/bauwks-boot-1.4.2.zip) contains:
MLO from 1.4.2
u-boot.bin from 1.4.2
flashing_boot.img <- the 2nd uboot
Unzip it to the root directory on an SD card, drop in a boot.img you want to test and go. If you see the box then it's booting off the SD card and should then load your boot.img.
Great job bauwks!
Someone with an 8 gig model please test this. If it works, I can begin working on a resurrection solution for the NT 8gig.
FWIW "Cyanoboot" (w/menu and all that) has been tested and works w/512 model as well.. stay tuned.
Incidentally, my tester did seem to indicate that sd card boots need to be tethered. FWIW
so going off of what i have read heres what ive gotten so far.
format the sd card to fat32 and make sure the flags for boot and lba are on.
transfer the files to the root directory of the card (im assuming this doesnt mean try to write any of the image files to the card).
put the card in the nook.
press the power button and it should boot from the sd card.
this is everything that i have done and the device wont power on while the card is in the slot but i can take it out and it works fine.
am i doing something wrong?
anyone else have this issue?
EDIT: booted after i changed the partition size to 50 mb, but it didnt change or add anything.
just for clarification. Even if this allows boot and root from SD card, people should still not be using this new found access to flash roms designed for the 16gb on the 8gb? I say this because, last I read the acclaim update bricked the 8gb tablet.
that could be mine, but the tech at b&n says it's hardware problem so I'm not too sure. the flash was going well half way and when I stepped away for a couple minutes and came back to find it bricked.
albertwertz said:
just for clarification. Even if this allows boot and root from SD card, people should still not be using this new found access to flash roms designed for the 16gb on the 8gb? I say this because, last I read the acclaim update bricked the 8gb tablet.
Click to expand...
Click to collapse
Actually, I believe if the kernel is 1.4.2, there should be no problems and CM for the nook tab should have 1.4.2, we would need gonce to come in and verify though.
albertwertz said:
just for clarification. Even if this allows boot and root from SD card, people should still not be using this new found access to flash roms designed for the 16gb on the 8gb? I say this because, last I read the acclaim update bricked the 8gb tablet.
Click to expand...
Click to collapse
As long as the bootloader and kernel are based on the latest kernels and such there shouldn't be a reason that both devices can't run the same roms. The issue with the acclaim update is that it flashes the bootloader/kernel stuff from 1.4.0 which doesn't take into account the variances between both devices. Since the 1.4.0 bootloader doesn't know how to take into account the 512 memory you get a bricked device. If it were possible to create an acclaim update with the newest 1.4.2 bootloader/kernel and a 1.4.0 file system except for a couple of possible driver related changes the 1.4.0 file system would work fine on the device.
However, as long as we stick to the same guidelines that BN will, any rom we release should work just as effectively on both devices. This is because BN has designed the latest BNOS to run on both devices so that they only have to release one update file in the future as opposed to support for two devices with so few differences between them. As long as we take into consideration both devices by using the latest bootloader/kernel sources, it should work on both devices without a hitch.
I am sorry to sound so dumb but I came to the party late. (Just bought the 8gb NT yesterday.)
I did create the 50meg partition and loaded the files to it. It boots to the box but I am uncertain of where to go from here. I have tried to find related threads but I have not been successful.
Please be kind.. ;-)
So far this is the only thing that has been release for the 8gig. I haven't seen any CWM or 1.4.2 ROMs yet. I know that they are currently working on CM7 for 8gig and an Ubuntu recovery.
raywaldo said:
I am sorry to sound so dumb but I came to the party late. (Just bought the 8gb NT yesterday.)
I did create the 50meg partition and loaded the files to it. It boots to the box but I am uncertain of where to go from here. I have tried to find related threads but I have not been successful.
Please be kind.. ;-)
Click to expand...
Click to collapse
@bauwks: The boot.img you provide does not boot completely on the 8GB tablet; it reboots abruptly after /system is mounted. Upon further investigation the culprit appears to be the files /manifest00 and /manifest01 in the ramdisk in boot.img, which contain (what I would assume to be) checksums or signatures of a large number of files under /system. The /init binary seems to include a B&N-specific "feature": it crashes if any of the files listed in /manifest00 and /manifest01 has a different checksum on disk than the checksum specified in /manifest00 or /manifest01. There're a number of differences between the /manifest00 and /manifest01 included in the boot partition of the 8GB version and those in your boot.img (meaning that the system files themselves are different on the 8GB than on the 16GB), which is what causes /init to crash on the 8GB NT, resulting in a reboot.
The simple solution is to delete everything in /manifest00 and /manifest01, because /init only verifies the checksums of files listed in /manifest00 and /manifest01, and will happily ignore everything else. I zeroed out the two files in your ramdisk, rebuilt boot.img and can boot perfectly into the stock software.
This mechanism is really evil on the part of B&N. To modify an Android system file (I discovered this when trying to replace /system/framework/framework.jar), for instance to apply a skin or enable copy & paste, you would need to modify /manifest00 or /manifest01. To modify /manifest00 or /manifest01, you would then need to flash a new boot partition. But to flash a new boot partition, you would need to circumvent the locked bootloader (which you have done - hats off to that). This is the most locked-down Android device I've ever played with.
jichuan89 said:
@bauwks: The boot.img you provide does not boot completely on the 8GB tablet; it reboots abruptly after /system is mounted. Upon further investigation the culprit appears to be the files /manifest00 and /manifest01 in the ramdisk in boot.img, which contain (what I would assume to be) checksums or signatures of a large number of files under /system. The /init binary seems to include a B&N-specific "feature": it crashes if any of the files listed in /manifest00 and /manifest01 has a different checksum on disk than the checksum specified in /manifest00 or /manifest01. There're a number of differences between the /manifest00 and /manifest01 included in the boot partition of the 8GB version and those in your boot.img (meaning that the system files themselves are different on the 8GB than on the 16GB), which is what causes /init to crash on the 8GB NT, resulting in a reboot.
The simple solution is to delete everything in /manifest00 and /manifest01, because /init only verifies the checksums of files listed in /manifest00 and /manifest01, and will happily ignore everything else. I zeroed out the two files in your ramdisk, rebuilt boot.img and can boot perfectly into the stock software.
This mechanism is really evil on the part of B&N. To modify an Android system file (I discovered this when trying to replace /system/framework/framework.jar), for instance to apply a skin or enable copy & paste, you would need to modify /manifest00 or /manifest01. To modify /manifest00 or /manifest01, you would then need to flash a new boot partition. But to flash a new boot partition, you would need to circumvent the locked bootloader (which you have done - hats off to that). This is the most locked-down Android device I've ever played with.
Click to expand...
Click to collapse
Thanks a lot for your detailed analysis jichuan89. I'm kind of surprised the checksums don't match because I took the original boot.img straight out of B&N's 1.4.2 release zip file. Well, at least I know that the bootloader is working on the 8GB model.
odd... I just booted this on my NT 16G...
Code:
Texas Instruments X-Loader 1.41 (Nov 11 2011 - 17:05:18)
Start not on PWRON, skipping power button check.
mmc read: Invalid size
Starting OS Bootloader from MMC/SD1 ...
U-Boot 1.1.4-elation1.4.3_1.4.3.3001^{} (Feb 15 2012 - 18:31:19)
get_sdram_size: 1073741824
Load address: 0x80e80000
DRAM: 1024 MB
Using default environment
In: serial
Out: serial
Err: serial
hw_status 0x23 vbus_status 0x80
MAX17042+UBOOT: battery type=LG
MAX17042+UBOOT: gas gauge detected (0x0000)
MAX17042_STATUS (00h) is 0x0000
MAX17042+UBOOT: BATTERY Detected!
MAX17042+UBOOT:WARM BOOT
No valid max17042 init data found, assume no battery history
uboot verify: 1d CONFIG is 2210 ; should be 2210 & 0xFDFB
uboot verify: 2a RELAXCFG is 083b ; should be 083b
uboot verify: 29 FILTERCFG is 87a4 ; should be 87a4
uboot verify: 28 LEARNCFG is 2456 ; should be 2406 & 0xFF0F
uboot verify: 18 DesignCap is 205c ; should be 205c
uboot verify: 12 Vempty is 7d5a ; should be 7d5a
uboot verify: 25 TEMPLIM is 2305 ; should be 2305
uboot verify: 2b MiscCFG is 0810 ; should be 0810 & cc1f
uboot verify: 2c TGAIN is e3e1 ; should be e3e1
uboot verify: 2d TOFF is 290e ; should be 290e
uboot verify: 2e CGAIN is 4000 ; should be 4000
uboot verify: 2f COFF is 0000 ; should be 0000
uboot verify: 37 FCTC is 05e0 ; should be 05e0
MAX17042+UBOOT: warm config is okay
hw_status 0x23 vbus_status 0x80
Identified DVT or newer, using its charging GPIOs
Disable charging
Powering off!
hrm... nevermind... my device won't power up on even stock right now... it could be low on battery, but oddly it is showing green on the charger.
bauwks said:
I'm kind of surprised the checksums don't match because I took the original boot.img straight out of B&N's 1.4.2 release zip file.
Click to expand...
Click to collapse
I totally agree. A diff between your /manifest00 and the 8GB's /manifest00 shows that the userspace on the 16GB and the 8GB versions are completely different; core Android system libraries like /system/framework/framework.jar, /system/framework/core.jar, /system/framework/ext.jar, /system/framework/core.jar and so on are all different in the two ROMs:
Code:
$ diff nook_16gb_boot/ramdisk/manifest00 nook_8gb_boot/ramdisk/manifest00
160,187c160,187
< /system/framework/ime.jar:0208a82881c097c787c49c40fdb4679487b4b2e9
< /system/framework/framework.jar:540d575dd8b88dceaff9931f5169508f73f53ce8
< /system/framework/input.jar:a52eb0ba70b8f6a0a5e4035ccc49c2a98ed95dd6
< /system/framework/monkey.jar:08e7508dfaa10f8c0eb80fa6abff6e69fb283c80
< /system/framework/javax.obex.jar:5c5685865ac196e0b7e487b145a6e112e695a257
< /system/framework/android.test.runner.jar:6c795691eb3990362e3cd08bf0babe2403bdac73
< /system/framework/am.jar:4d015820c353ad5e92942cc5bce25e431942b94d
< /system/framework/com.bn.cloud.jar:35992cbd24e29ce5366d90128733cae01c2314ce
< /system/framework/com.bn.app.displayinfo.jar:56a0d6a43c55a930d6141444140a10f44dc775f0
< /system/framework/services.jar:4f50684204b449ab45566e86a5a7573d9bedc8d3
< /system/framework/pm.jar:ab289af9add3be4907c2c51fc19bc64021a00836
< /system/framework/com.bn.app.deviceinfo.jar:6eb25c7ec0afa72f123983be3767abd90aef8823
< /system/framework/sqlite-jdbc.jar:c2f75237682f87add7c0ff07c0b844666941c17d
< /system/framework/core.jar:0f8b49f7b38625dc9354235464edd49070f5883a
< /system/framework/svc.jar:b3db35986ceee4e035963648fb66ae8072708e25
< /system/framework/com.bn.authentication.jar:612168ccd4e724e7aa08d2b10d7522b52e1ab4e6
< /system/framework/bncloudapi.jar:46ee63bcd922d52dde46a61377633d76c1cd3ea9
< /system/framework/ext.jar:b9f34ae936d1d2cc1a2d37d8a645e59d393d71d3
< /system/framework/com.bn.app.crypto.jar:f30292d95d4834ddd74d2076ff4352f70893fd02
< /system/framework/com.bn.gpb.jar:6a6c0ba81cf0edb2eb23d5cadcd78dace38bc98e
< /system/framework/core-junit.jar:ef8c3aa523400df6ed0c74a03a1565765fe2acc1
< /system/framework/com.android.location.provider.jar:8d5c848effb81aeb001dfc18b061414b48fd46ef
< /system/framework/com.bn.provider.utils.jar:0cc256eff7b6e0f268a130ddf6bf744e468505e0
< /system/framework/bouncycastle.jar:eaf8716aecb7b5c5404cdd0dc945a0ac5546f76e
< /system/framework/bmgr.jar:cc90fb658bd9373841b23d4a68bb04602be278bd
< /system/framework/com.bn.service.devicemanager.jar:833fca513552ce073f6a28d22fc7f185538b80c4
< /system/framework/com.bn.policymanager.jar:95d54490b9e148385670e836651b0685058cb433
< /system/framework/android.policy.jar:98af166741dd0a8ab1964584e37cbc4c7e825fcb
---
> /system/framework/ime.jar:27146e528c683df58b76492eaab8cf02f5310f1b
> /system/framework/framework.jar:636c3015a7f6e5975e84cc523b578aaeffa45454
> /system/framework/input.jar:21833f73ecd9ccd868cbec6733607fda36bffe22
> /system/framework/monkey.jar:de98f6b9f43dfc30029e240765d56f8284498d39
> /system/framework/javax.obex.jar:616ed1d68673333a9b05b69dc13171d971006ed2
> /system/framework/android.test.runner.jar:edbc28be81077514e6cdedd5018a9cd741622da8
> /system/framework/am.jar:3aed3895f63fb27309dba486ae645f6b3eb447f6
> /system/framework/com.bn.cloud.jar:8182d5d308a46b277a03775c473bf86c3e33b73b
> /system/framework/com.bn.app.displayinfo.jar:858074aa9ec095d8ed4a6e7e880ab376a52ce271
> /system/framework/services.jar:fa3808bcbce9b64fa3cdc1adc322ff783729ef63
> /system/framework/pm.jar:47c08c0de507bd2a5ea71a43004d6ad5f220c986
> /system/framework/com.bn.app.deviceinfo.jar:c3b261f713cd1cd78095d21a53ea5df54cf874dc
> /system/framework/sqlite-jdbc.jar:90a05ffc8aa06c937e0107340af211b9166b204e
> /system/framework/core.jar:4d34e393d8ab0b8f544405ec833af355a5670192
> /system/framework/svc.jar:98aef5fabe53a0771010e83c7e8cb6e1d69aeeb8
> /system/framework/com.bn.authentication.jar:95be7d84b4fddbbcef417e5c1ab3410d9c1cba41
> /system/framework/bncloudapi.jar:9207bdd53e52ee1d721244c4d8eaad7aba828429
> /system/framework/ext.jar:2d582e4793457a35e19e429d5bbac746fc72b2ef
> /system/framework/com.bn.app.crypto.jar:26d118312120b661612ee7335673923064567d63
> /system/framework/com.bn.gpb.jar:739e7ce38c94615130ce3780085496553e6656c3
> /system/framework/core-junit.jar:80a4040d76cd04d85a8fe16e7910365f5994d378
> /system/framework/com.android.location.provider.jar:08628ff32fe0d9ea23e2ae362803cad3e26b6425
> /system/framework/com.bn.provider.utils.jar:5897fdec7612a796824475454414d39dd0e5a6f6
> /system/framework/bouncycastle.jar:8d2cee2830d46e557c52eeea7de21b6abfba1529
> /system/framework/bmgr.jar:89cc7d926e9bdb36e7fe1adeccf0d140fe5d4b90
> /system/framework/com.bn.service.devicemanager.jar:066da8a087d199239e2dc96fd2aa4ab3c364f5c1
> /system/framework/com.bn.policymanager.jar:a7e953e9e550a5ffce357007a97b82c753063b99
> /system/framework/android.policy.jar:48dd1337c5e45830e5d2dc009173cb7622226aad
211c211
< /system/bin/debuggerd:6dea49eb6a8cf831efb459fd73800d319f21050a
---
> /system/bin/debuggerd:9e90dd40168eef36fee2a9cf273146180e4c9135
You're right in saying this is very surprising; I would have thought that the only difference between the ROMs should be the kernel command line in the boot partition.
bauwks said:
Well, at least I know that the bootloader is working on the 8GB model.
Click to expand...
Click to collapse
Well since I based my root method for the 8GB NT on your images (just in case you didn't know), I want to use this opportunity to say a HUGE THANK YOU for everything you've done - esp 2nduboot (just ingenious...wow) and posting these files for the 8GB. You're a god.
I've looked deeper into the /manifest00 + /manifest01 stuff and came across something really strange. I grabbed the official 1.4.2 update archive from and observed that the /system/framework/framework.jar in the update archive, which I assume to be the same as on the 16GB tablet, is indeed different from the same file on the NT 8GB. However, when I extract both files with unzip, I discovered that they have the same content; in addition, the two files also have the exact same length. I would be very curious to know if this is intentional on the part of B&N, and why.
It is not clear to me if this has been verified to work on the NT 8GB model.
Has this been verified?
Thank you!
I have a brand new Nook Tablet 8GB with factory 1.4.2 firmware and the image did absolutely nothing on it. What are the stept again? I copied the three files to the SD card and nothing happens when I turn on the Nook with the SD inserted.
haloway13 said:
It is not clear to me if this has been verified to work on the NT 8GB model.
Has this been verified?
Thank you!
Click to expand...
Click to collapse
I believe it has, as has CyanoBoot.
i have some curious results here... I have a device which does not boot from SD Properly.
Code:
Texas Instruments X-Loader 1.41 (Oct 21 2011 - 14:00:05)
Checking power button state... PRESSED. OK
mmc read: InvaliD size
[ERROR] [SEC_ENTRY] Call to Secure HAL failed!
Could not read bootloader!
X-Loader hangs
The SDCard works in my device, but it does not work in this bricked device...
Any ideas. My mind seems to keep revolving around a modification to e-Fuses??
AdamOutler said:
i have some curious results here... I have a device which does not boot from SD Properly.
Code:
Texas Instruments X-Loader 1.41 (Oct 21 2011 - 14:00:05)
Checking power button state... PRESSED. OK
mmc read: InvaliD size
[ERROR] [SEC_ENTRY] Call to Secure HAL failed!
Could not read bootloader!
X-Loader hangs
The SDCard works in my device, but it does not work in this bricked device...
Any ideas. My mind seems to keep revolving around a modification to e-Fuses??
Click to expand...
Click to collapse
I'm not sure which x-loader (mlo) you're running, but looking at source from 1.41 source as well as 1.42, that line seems to be from cpu/omap4/mmc.c , though I don't see the capital "D" in "InvaliD" the way you've shown me in any source we've been given, which makes me think the mlo has changed (unless you retyped it).
It should be reported like this:
function omap_mmc_read_sect:
printf("mmc read: Invalid size\n");
I'm also not sure if you just copied the flashing_boot.img to that sd card, but you may want to copy mlo over from 1.42 as well, just to be sure.
Hi,
Here a release of kboot.
Kboot permit to boot multiple os with different kernel.
It's based on a buildroot environment.
The source to make your own kboot filesystem are available here
The kernel source are available here
You can download the install archive :
ARCHIVE VERSIONS
0.0. Unstable release. Freeze bug. Install release ARCHIVE (Obsolete)
0.1. Fix freeze. Python bytecode generation (pyc files) is naturally not friend with squashfs. Install release ARCHIVE (Obsolete)
0.2. STABLE Release. Display timeout, migration from squashfs to initramfs. Install release ARCHIVE
The archive looks like :
zImage and initramfs.cpio.gz to flash in SDE menu
a directory kboot which contain:
conf directory : configuration file
os directory : os to boot
images directory : background menu image
Installation
Kboot directory
Copy the kboot directory on your archos in /mnt/storage/, you should have this path /mnt/storage/kboot. The path should be exactly the same otherwise kboot will not be launched
Flash zImage and initramfs.cpio.gz
Follow this link to setup SDE on your archos http://forum.xda-developers.com/showthread.php?t=930197
After Reboot
You should have the following screen. Note: after installing Kboot the device permanently reboot in Kboot.
The main menu will display the os put in os directory (see in Configuration OS boot menu to see how to include your os), advanced menu and halt.
Boot menu
OS boot menu
I have tried to make things simple. To add an OS, all you need is to create a directory in /mnt/storage/kboot/os/ and put in this newly created directory the files zImage and initramfs.cpio.gz.
Important, the name should be exactly zImage and initramfs.cpio.gz, if one file is missing or misnamed the menu item don't appear
For example, the menu above have the following content in /mnt/storage/kboot/os :
Code:
/mnt/storage/kboot/os/Android Froyo:
drwxrwxrwx 2 2000 2000 4096 Feb 27 23:42 .
drwxrwxrwx 5 2000 2000 4096 Feb 28 15:02 ..
-rw-rw-rw- 1 2000 2000 726520 Feb 27 23:39 initramfs.cpio.gz
-rw-rw-rw- 1 2000 2000 2564460 Feb 27 23:39 zImage
/mnt/storage/kboot/os/Android Honeycomb:
drwxrwxrwx 2 2000 2000 4096 Feb 27 16:46 .
drwxrwxrwx 5 2000 2000 4096 Feb 28 15:02 ..
-rw-rw-rw- 1 2000 2000 0 Feb 27 13:42 initramfs.cpio.gz
-rw-rw-rw- 1 2000 2000 0 Feb 27 13:42 zImage
/mnt/storage/kboot/os/UrukDroid 1.6:
drwxrwxrwx 2 2000 2000 4096 Feb 28 15:03 .
drwxrwxrwx 5 2000 2000 4096 Feb 28 15:02 ..
-rw-rw-rw- 1 2000 2000 2874800 Jan 3 19:41 initramfs.cpio.gz
-rw-rw-rw- 1 2000 2000 2302252 Jan 3 19:26 zImage
Note : for specific kernel you can add a file named cmdline containing kernel parameters
Advanced boot menu
Boot init : boot into android, if android kernel was uninstalled, this item didn't appear
Boot recovery : boot into recovery
Soft boot : For details about omap soft reboot see the discussion here
Configuration
There is a configuration file in kboot/conf directory named config.ini. This file is divided into 3 section
init
telnet : 1 to enable telnet, 0 to disable
usbip : set the ip address of usb ethernet interface
Code:
[init]
telnet = 1
usbip = 192.168.10.1
kboot
last_selection : enable (1) or disable (0) the boot by default of the last selectioned entry after a configured timeout
last_selection_timeout : timeout in second
softboot : enable or disable softboot menu
title_font_size : set the title font size
menu_font_size : set the menu font size
title_color : title color in r,g,b format
menu_item_color : menu unselected color in r,g,b format
menu_item_selected_color : menu selected color in r,g,b format
Code:
[kboot]
# boot last selection if no key pressed after 30 seconds
last_selection = 1
last_selection_timeout = 30
# enable soft boot menu (bootloader dev only)
softboot = 1
# some tuning
title_font_size = 36
menu_font_size = 32
# change the color, R,G,B format
title_color = 255,255,255
menu_item_color = 92,97,98
menu_item_selected_color = 0,0,255
softboot
item<n> : the boot sequence wanted
Code:
[softboot]
# put a list of items to display in Soft boot menu
# item<n> = sequence
item1 = uart,usb,mmc1,mmc2
item2 = uart,usb
item3 = mmc1,mmc2
background image
To customize the background image, just replace the file kboot/images/bkg.png with your own and adapt if necessary the size and the font color.
BUGS
Feedbacks are welcome
Cool stuff bro!
Unfortunately it's not working on the A70S, as we only have 800x480 and therefor need a diff picture.
It seems to be good.I have tested it on my A101 and it can boot both openaos and urukdroid.
Thanks.
EDIT:Sorry, Urukdroid cannot boot.It stay at the boot animationan and always show that.
fzelle said:
Unfortunately it's not working on the A70S, as we only have 800x480 and therefor need a diff picture.
Click to expand...
Click to collapse
As an early release I didn't take the time to put the different resolution. The background image have a 1500x1200 resolution, so on 101 it didn't display right too. However kboot adapt resolution for corresponding board. kboot didn't boot on 70s or display wrong the background image ?
MarsCarmen said:
EDIT:Sorry, Urukdroid cannot boot.It stay at the boot animationan and always show that.
Click to expand...
Click to collapse
I have to test urukdroid on mine.
The menu is not readable because the resolution adaption is not doing what it should do.
fzelle said:
The menu is not readable because the resolution adaption is not doing what it should do.
Click to expand...
Click to collapse
I have uploaded a new archive here.
Replace rootfs.squashfs with the new one. Fixed : resolution was wrong for 70S and 70H*.
The zImage in new archive should be flashed, it seems to fix the random freeze.
MarsCarmen said:
EDIT:Sorry, Urukdroid cannot boot.It stay at the boot animationan and always show that.
Click to expand...
Click to collapse
I have to say sorry again that Kboot can boot Urukdroid properly.It was because I copied my backup file to my archos by using MY PC.That is why I cannot boot urukdroid.Maybe I didn't find the real cause. I'm now using Kboot to boot Urukdroid and Openaos.
Really very well!!
Sorry For My Bad English
@alephzain:
Copied the whole kboot dir and flashed the new initrams and zimage.
Looks still as before.
fzelle said:
@alephzain:
Copied the whole kboot dir and flashed the new initrams and zimage.
Looks still as before.
Click to expand...
Click to collapse
. Kernel natively support usb gadget ethernet, when kboot is launched a telnetd is started, an interface usb0 is configured with ip address 192.168.10.1.
if you are on linux it should automatically detect this and on your pc an ifconfig let appear usb0 interface. On your pc type :
Code:
ifconfig usb0 192.168.10.2 netmask 255.255.255.0 up
telnet -l root 192.168.10.1
.
If you can paste a ps output, to see if it detect you board correctly.
Found a Live Linux to use in a vm.
ps output starts with :
{init} /bin/sh /init A70S 07 /dev/mmcblk1p1 /dev/mmcblk0p1
fzelle said:
Found a Live Linux to use in a vm.
ps output starts with :
{init} /bin/sh /init A70S 07 /dev/mmcblk1p1 /dev/mmcblk0p1
Click to expand...
Click to collapse
Its fixed now . Replace rootfs by this one
alephzain said:
Its fixed now . Replace rootfs by this one
Click to expand...
Click to collapse
Please adapt the first post also so that future users have the correct files.
Maybe add a version number....
---------- Post added at 04:27 PM ---------- Previous post was at 04:12 PM ----------
This may be a stupid question but why do you need a squashed fs that contains (when unsquashed) about 30Mb on files including python?
it should be possible to trim that down and put all the scripts and support libs in the initramfs so that you only need to flash the kernel and initramfs and nothing else.
Working now.
If now someone could come with the possibility for booting older stock FW,
would be great.
fzelle said:
Working now.
If now someone could come with the possibility for booting older stock FW,
would be great.
Click to expand...
Click to collapse
Not really possible because the stock firmware (initramfs) always uses the same location for the root file system.
You could do it but it needs some changes to the initramfs that is placed in the dirs.
wdl1908 said:
This may be a stupid question but why do you need a squashed fs that contains (when unsquashed) about 30Mb on files including python?
it should be possible to trim that down and put all the scripts and support libs in the initramfs so that you only need to flash the kernel and initramfs and nothing else.
Click to expand...
Click to collapse
Files on first post have been updated, but you're right a better presentation to avoid confusion is necessary.
Simply because I use python (pygame which use sdl) to code Kboot. Python lib dir is about 13M ... . A minimal filesystem (compressed initramfs) for kboot work is about 8M + ~2M for the kernel give 10M, and it's too big to flash in SDE max 8M. But if i can optimize the size ... I will do
alephzain thanks for the sources on gitorious, I hope I have some time in the weekend to try it out
divx118
@divx118:
And could you then make a initramfs.cpio.gz that direktly boots into CM7?
Hi,
im just about testing...
But sadly I can't get it to work.
Each time the menu starts up i can navigate nicely though the menues.
But whenever I select an entry - noting happens
After that I can still navigate ONCE (up or down) to the next entry and then the device freezes.
It doesn't matter wich entry i select as it seems. I tested Boot init, and my custom entries (UrukDroid and BullRC) yet. But all behave the same.
Any ideas ?
Btw: I tested it with the acutal squashfs and the one packed in the zip (even they seemed to be the same in size)
EDIT:
SOLUTION: I had usb cable attached (since flash) and that made it freeze - juts removed the cable and all is fine
Thanks and gr8 work - was looking for this since ages
fzelle said:
@divx118:
And could you then make a initramfs.cpio.gz that direktly boots into CM7?
Click to expand...
Click to collapse
Yes, no problem.
I Have decided that this thread has served it's purpose and will now be closed to future posts. Please direct and 'non' SHV-E160L post's to
Brixfix V2
Please can all Ongoing jobs/works migrate to the above thread.
-----------Final Notes--------------
It has been mentioned many times that i should go back and correct the information below, i started to correct a few post's then realized i was removing the flavour in change of colour and size, parts of this thread documents my mistakes, assumptions and general lack of understanding of how we NOOBS post on XDA, It's with that in mind that i have decided to leave the mistakes in, so you can see in writing what i gained from the support of other Devs here.
Now, if you are NOOB in anyway or have a few questions please click HELP
If you are bricked and need help, read this thread first, there is NO one CLICK solution for anything, even this mentioned device.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
So you Brixed/bricced/BOD/QDL/EDLOAD/QHS-USB/05c6:9008/05c6:9025/ your device? Need a Oil and brush , Need help, follow this
One, Rules
Two, Understanding
--------------------------------------------------------------------------
Tip From the Author,
Some of you may have noticed that i did not start the original thread with a question, I did something my mentor taught me at around 9 years old but didn't put into good use until much later in life.
The tip is write things down as a question for yourself, in the writing process you get to pass the information past the part of your brain that interprets information, virtual sounding board, before posting as a question for others.
--------------------------------------------------------------------------
New Tools for debricking, goto
Brixfix V2
---------------------------Further Info Info -----------------------------
** I have Since Fixed the device and developed soultions for non shv-e160l devices. Prior posts are undergoing edit's for corrections.
** if you want the glory shot, sorry you will just have to read through.
** If you are selling this as a solution, dont. I know who you are.
---------------------------Original Post-----------------------------
Hi All
As i mentioned on this thread http://forum.xda-developers.com/showthread.php?p=32231827#post32231827 i will be attempting to come up with a home grown debrick solution for a SHV-E160L samsung note from korea.
I will use the forum to document what i am doing, i am very new to this so correct me please if i am wrong. I have never done Android dev work at any time but i have a very good understanding of the logic behind it all. `
Things i Have :-
Phone ( SHV-E160L)
bus pirate v3 with jtag firmware
openocd compiled on ubuntu and centos 6
smd jtag adapter and relay wire ( magnetic wire)
things i still need :-
openocd target config file for MSM8660 Snapdragon cpu (and a better understanding of eMMC access, how to load boot loaders either into ram or eMMC or trigger fail over boot to sc-card, USB via software or X0M/Boot pins)
assembled jtag (it's the smallest soldering i've ever seen)
.PIT file for 32GB model (if someone could pull the .PIT file from a working unit I would be happy, specify your radio/kernel versions when uploading)
micro fine solder iron tip and 20w iron (i've got 60w but too high for this type of work)
Does anyone have a idea of the SD-CARD partition layout, files for snapdragon devices, google has given me much for other devices but not a snapdragon .
Another question, I've used the USB jig to trigger 301K mode USB-Factory and seen no activity in dmesg for usb devices, i've yet to try windows, does windows/linux behave in a different way when it comes to usb , as in windows see's the qualcom usb mode but not linux ? does the usb client device always start the comms?
using the 615K usb jig i get nothing too, no pbl message from samsung (hence i am led to think is's the pbl/sbl thats damaged)
My understanding up boot is as follows
iROM code
This loads basic settings to boot the PBL (iROM is in rom) the PBL is loaded into radio(modem) cpu and then loads the SBL(s)
PBL/SBL stored in eMMC at address ????? (need to document the address for the masked access to eMMC and jtag/openocd access unmasked access)
Once the SBL is loaded you with have the ODIN mode (USB/UART)
from what i can see of commercial JTAG boxes is the access the radio cpu via jtag, write a new PBL/SBL to the eMMC then halt/reset cpu which now loads the new bootloaders, (resurrect dead body)
The openocd TAP id for the cpu should be 0x105310E1 but thats a number i got from a riff box log, not any actual testing ( still need to solder the fine pitch connector)
Here is a log from a riff box, not sure if the address's are usable accross to opencd
Taken from gsm-forums:-
Open serial port...OK
Connecting to the RIFF Box...OK
Firmware Version: 1.33, JTAG Manager Version: 1.44
Selected Resurrector: [Samsung E160K V1.0.4535.7001]
Connecting to the dead body...OK
Detected dead body ID: 0x105310E1 - IGNORED!
Set I/O Voltage reads as 1.79V, TCK Frequency is RTCK
Adaptive Clocking RTCK Sampling is: [Sample at MAX]
Resurrection sequence started.
Establish communication with the phone...OK
Initializing internal hardware configuration...OK
Uploading resurrector data into memory...OK
Starting communication with resurrector...OK
Detected an Initialized FLASH1 Chip, ID: 0x0015/0x0000 (KTS00M, 0x0003AB400000 Bytes = 14.68 GB)
Detected an Initialized FLASH2 Chip, ID: 0x0015/0x0000 (KTS00M, 0x000000200000 Bytes = 2.00 MB)
Flashing the dead body...OK
Resurrection complete!
Click to expand...
Click to collapse
I did notice one thing, the riff box opens the serial port, i wonder if they load PBL+SBL into memory, reset the cpu, then using the serial connection activate download mode ? (like on the captive)
I also dont know how the cpu (jtag TAP id? ) and flash variables translate accross to openocd as ive not found a target config file yet ( or my searching is wrong)
in the full stock Firmware I was able to extract the .tar file which contained,
Code:
amss.bin <-- application cpu boot files ?
boot.img <-- kernel/initrd ramdrive
mdm.bin <-- modem cpu boot files
recovery.img <--- recovery image
system.img.ext4 <---- rest of the system applications
so i think we have the two cpu firmware/boot loaders in the .bin files, these bin files are just fat32 images, to access in ubuntu use
Code:
mount -o loop mdm.bin /mnt/mdmmountlocation
My guess is my first approach is getting the right PBL/SBL into the system and getting some feed back via uart, i have the jtag pinouts and further reserach says there is a UART2 on the jtag header, so when soldering up my jtag adapter i will include all pins if i can and sniff for serial logic, i happen to have a Open source logic sniffer, great tool as i do a lot of hacking into serial devices like scales and till printers .
back to topic.
When i do get to the jtag part at a minimum i should have access to the modem radio, afaik jtag devices connect in chains and most of the IC's that have jtag on the phones board all should link to the master device (i am thinking it's the modem cpu, no application) and that the Two cpu's share the eMMC memory some how, or it could be one cpu loads it into the other (it is connected via jtag down the chain) .
hopefully someone could correct me there.
Most of this is theory and my guess work, correct me if you find a mistake. most of the research is only over a few days too so i am far from finished there, does not help that most of the users speak a language that google translate just does not have a flair for.
Most of the info seems to suggest the modem cpu is the first inline so i decided to look further into the files there, notice the mdm.bin file is 23Mb, thats large, when mounted i notice the is a folder called 'image' ( amms.bin has folder called IMAGE , note the case difference, dont yet know whay)
in image folder we have :-
Code:
1.3M Sep 30 13:07 AMSS.MBN
35K Sep 30 13:07 DBL.MBN
2.2M Sep 30 13:07 DSP1.MBN
19M Sep 30 13:07 DSP2.MBN
40 Sep 30 13:07 EFS1.MBN
40 Sep 30 13:07 EFS2.MBN
40 Sep 30 13:07 EFS3.MBN
295K Sep 30 13:07 OSBL.MBN
Ah, i see amss.mbm , that must be the boot loader for the application cpu, DBL.MBM seems to be the PBL , OSBL.MBM could be the SBL
then there is the DSP/EFS files, I did do the command strings on all the files,
DBL.MBM does not have any text in the file that points to being able to do UART on boot, all text seems internal like pointers and references to the original build files e.g
Code:
D:\Q1LGT_MDM\MDM9600\modem_proc\core\boot\secboot2\dbl\target\mdm9x00\src\dbl_ddr.c
9x00B-SCAQSVZM-31613102
D:\Q1LGT_MDM\MDM9600\modem_proc\core\boot\secboot2\dbl\target\mdm9x00\src\dbl_sahara.c
but it also does contain data like this
Code:
auth_image
@[email protected]
@configure_hw
@flash_init
l0:eek:SBL
load_osbl_img
@DBL, Start
hw_init
so it looks more likley that dbl is first in the chain, it refers to loading osbl and configure hardware, i wonder if it means USB/UART at this stage or setting up ram and other GPIO's
in OSBL.MBM we have more interesting text
Code:
MbP?
Unable to attached to ChipInfo DAL
SAMSUNG
TOSHIBA
Flash: Failed to do initialization for probe!
ONFIx
0:ALL
Flash: Multi 2X page read not supported!
Flash: Multi 2X page write not supported!
boot_qdsps
OSBL
hw_init
hw_init_secondary
OSBL, Start
create_vector_table
ram_init
retrieve_shared
clobber_add_protection
mmu_flush_cache
OSBL, End
OSBL, Delta
osbl_sahara_load_amss
osbl_sahara_load_dsp1
osbl_sahara_load_dsp2
osbl_sahara_load_ramfs1
osbl_sahara_load_ramfs2
osbl_sahara_load_ramfs3
smem_boot_init
so it is looking more and more like DBL then SBL which then loads all of the other parts , also if you notice EFS1/2/3 are all tiny 40byte files, now i see why, they are loaded as ram-drives, so i assume those file set out the basic EFS file system in the ram.
again from research the boot stages are often counted as 3, i am assuming the real first part is in rom of the cpu (is this what triggers the qualcom download mode ) that loads DBL from eMMC and chain loads SBL
Now looking around the riff forums i see the list the info in a different way
Code:
Partition 0
SBL1
SBL2
Partition 1
RPM
SBL3
eMMC APPSBoot
TZ
.PIT
Click to expand...
Click to collapse
TZ i think is Trusted Zone
RPM - Power manager ?
now how this translates to file name from full flash and to mmcblk0p1 partitions i have yet to find out, i still dont have a .PIT file from a 32gb model
More updates to come,
regards
DarkSpr1te
CPU Boot order updates
So my digging has taken me back round to some of me early searching which i forgot about , hardware level seems to support the qualcom usb mode, but it can be disabled by manufacturer, so even if you find a resistor to the BOOT_CONFIG GPIO and ground it , it still may not work, and you could toast your board. once the qfuse is gone for that track, the maker can now use the gpio for anything else, it no longer controls the iROM branch choice ( CPU:do i start usb first or last?), it my thinking that on the first board sent out by the designers for a final production run ( those first public devices) they keep the option open to print off DEV models by changing the resistors/value of while the hardware stays same, not to be confused with dev board, that is pin/track simlar but is used to design the software mainly, sometimes hardware debug but as you change the hardware between the dev platform and production this is less helpful, google new.intrinsyc.com and apq8060, they produce a dev board that is the same as the device we hold, but everything is broken out for testing so don't expect to see this left in a bar for you to e-bay.
EDIT:
Above I refer to a dev phone and dev board, these are SURF and FFA, FFA is form factor accurate and SURF is Subscriber Unit Reference.
Here is the link, http://forum.xda-developers.com/showthread.php?t=1856327
Now from what i see, it's the same(edit:simlar) X0M pin setup as other phones, ground the right pin, reverse boot order, but this maybe two pins in the snapdragon,
[copied from other link]
Simplified table:
Code:
------------------------------------------------------------------
BC[5:0] Mapping
------------------------------------------------------------------
0b00000 Emergency Boot from SDC3 (SD) followed by USB-HS
0b00001 SDC3 followed by SDC1 (eMMC)
0b00010 SDC3 followed by SDC2 (if used)
0b00011 SDC1 (eMMC)
Click to expand...
Click to collapse
So if 0b00000 is EM boot and the docs say the the two gpio's that control this (if qfuse not blown) are taken high then it's 0b00011, so grounding those two resistors should give us 0b00000 or EM boot, the cpu docs also say they are internally grounded, the schematic says the voltage goes throught a 10k resistor, so grounding that side of the resistor that 'goes' to the cpu should change the boot order, but before trying this out, remember if you get the live side of the resistor the is no resistor between your probe and ground, that full current, short, blown, no more johnny 5.
Have you managed to unbrick the E160L?
darkspr1te said:
So my digging has taken me back round to some of me early searching which i forgot about , hardware level seems to support the qualcom usb mode, but it can be disabled by manufacturer, so even if you find a resistor to the BOOT_CONFIG GPIO and ground it , it still may not work, and you could toast your board. once the qfuse is gone for that track, the maker can now use the gpio for anything else, it no longer controls the iROM branch choice ( CPU:do i start usb first or last?), it my thinking that on the first board sent out by the designers for a final production run ( those first public devices) they keep the option open to print off DEV models by changing the resistors/value of while the hardware stays same, not to be confused with dev board, that is pin/track simlar but is used to design the software mainly, sometimes hardware debug but as you change the hardware between the dev platform and production this is less helpful, google new.intrinsyc.com and apq8060, they produce a dev board that is the same as the device we hold, but everything is broken out for testing so don't expect to see this left in a bar for you to e-bay.
Here is the link, http://forum.xda-developers.com/showthread.php?t=1856327
Now from what i see, it's the same(edit:simlar) X0M pin setup as other phones, ground the right pin, reverse boot order, but this maybe two pins in the snapdragon,
[copied from other link]
Simplified table:
Code:
------------------------------------------------------------------
BC[5:0] Mapping
------------------------------------------------------------------
0b00000 Emergency Boot from SDC3 (SD) followed by USB-HS
0b00001 SDC3 followed by SDC1 (eMMC)
0b00010 SDC3 followed by SDC2 (if used)
0b00011 SDC1 (eMMC)
So if 0b00000 is EM boot and the docs say the the two gpio's that control this (if qfuse not blown) are taken high then it's 0b00011, so grounding those two resistors should give us 0b00000 or EM boot, the cpu docs also say they are internally grounded, the schematic says the voltage goes throught a 10k resistor, so grounding that side of the resistor that 'goes' to the cpu should change the boot order, but before trying this out, remember if you get the live side of the resistor the is no resistor between your probe and ground, that full current, short, blown, no more johnny 5.
Click to expand...
Click to collapse
I think my E160L got a real brick today after I tried to flash a modified Rom downloaded from a Chinese forum. It can not be powered on after rebooting (installed successfully). I desperately need advice now on how to deal with it.
Jeff_GTA said:
I think my E160L got a real brick today after I tried to flash a modified Rom downloaded from a Chinese forum. It can not be powered on after rebooting (installed successfully). I desperately need advice now on how to deal with it.
Click to expand...
Click to collapse
Do you have any backups like nandroid ? does the 3 button boot still work ?
Regards
Have you looked into using ort-jtag. It's only about $150 (USD).
I've been looking into this myself for low-level debugging/bootloader development on SGH-T959V and SGH-I717.
All three of these devices are supported by ort-jtag and have header connectors for the jtag pins.
So I'm also getting some of these from digi-key, and making a small receptacle, much like in AdamOutler's captivate bootloader development thread. (search for k-ww)
Again, ort-jtag does support the SHV-E160L. (search that link for SHV-E160L)
PBL Dump - I think
So ive been doing some tests.
I think i managed to dump the PBL
i dumped memory and a strings search return this
Code:
pbl_error_handler.c
pbl_flash_nand.c
pbl_flash.c
dload.c
pbl_flash_nand.c
pbl_flash_onenand.c
pbl_auth\secboot_rsa_math.c
pbl_error_handler.c
pbl_auth.c
pbl_auth.c
pbl_auth.c
pbl_auth.c
pbl_auth.c
pbl_mc.c
pbl_mc.c
pbl_error_handler.c
and
Code:
qhsusb\src\dci\qhsusb_dci.c
}^PBL_DloadVER1.0
!8}^
}]^}^
Q`omm
z8}]
DEBUG
SW_ID
OEM_ID
pbl_flash_onfi.c
pbl_flash_nand.c
pbl_flash_sflashc.c
pbl_loader.c
pbl_flash_sdcc.c
pbl_auth.c
pbl_auth\secboot.c
pbl_auth\secboot_x509.c
QUALCOMM COPYRIGHT 2009BOOT ROM VERSION: 1.4QHSUSB VERSION: 00.00.08
BOOT ROM AUTHOR: DHAVAL PATEL
07 0000 SHA1
does any one want the dump that can reverse it ?
Dumps & execute address
I also need the help of other SHV-E160? owners, i need dumps from working phones, i managed to create a 8660_msimage.mbn and flashed it, but i was using i717 bootloaders and i dont think they will work, i need working dumps from working phones, starting with partition table layout, sbl1.mbn and sbl2.mbn
Does anyone know if the is is correct
SBL1 exec address 0x2A000000
SBL2 exec address 0x2E000000
as i can upload the sbl to 0x2a000000 but not the sbl2 to 0x2e000000
i can also upload the tz.mbn to 0x2a020000
i am trying to use sec boot 3 based call stack but am unsure of the real exec values
Ive seen in another post these values
"
It looks like ours deviates slightly from this.
If the headers are to be believed,
TZ is loaded at 0x2A000000
SBL3 is loaded at 0x8FF00000
APPSBL/aboot is loaded at 0x88E00000
"
the post is
http://forum.xda-developers.com/showpost.php?p=30057296&postcount=243
it does explain why i cant load into 0x2e000000
Progress
So today i made real progress, I have been able to flash a basic program to allow me to access the EMMC, i have taken a full backup and now i need to start scanning the dump for need information,
I still need help from other users so please if you are will to provide me dumps of your working device that would help me a great deal
So Part One is a sucess, I have been able to flash my own code and power on the galaxy note. next step is rebuilding the emmc partition tables, testdisk can find the partitions but is not alowing me to write a non standard partition table (which emmc seems to be formatted with)
Thanks
darkspr1te
help QPST Software Download
Hi,
I'm stuck with the same problem can you tell me what image you use to the phone. I stuck here. I' m really don't know what to do?
Thank you for your help.
tyllerdurdent said:
Hi,
I'm stuck with the same problem can you tell me what image you use to the phone. I stuck here. I' m really don't know what to do?
Thank you for your help.
Click to expand...
Click to collapse
First thing i must say is dont flash your phone just yet!! walking blindly into this could render your phone useless due to certain data being lost for good.
if you still wish to continue i will upload a basic guide and files. My method is still in development, it has many bugs ( i flashed the phone with i717 roms, working, SHV-E120 roms, working, N7000 rom complete fail)
But first some questions,
Which model phone is it?
what happened to get you to the point of needing the flash ? ( i ask so i can trace why the bricks are happening and hopefully fix it)
thank you for your help, I will be waiting your method and your files.
Thank you so much for your help.
My phone is a samsung galaxy note SHV-E160L korean version.
what happen was:
I tried to upgrade the firmware with kies and suddenly the program crash. My phone enter in an error issue with the firmware and said use emergency recovery mode.
I tried the recovery several times (uninstalling kies and install it again but that never work).
So, I download odin and this files to restore the original firmware:
CSC - GT-N7000-MULTI-CSC-OZSLPF.tar.md5
Phone - MODEM_N7000XXLR1_REV_05_CL1144476.tar.md5
Bootloader- N7000_APBOOT_N7000ZSLPF_CL558430_REV02_user_low_sh ip.tar.md5
PDA - N7000_CODE_N7000ZSLPF_CL558430_REV02_user_low_ship .tar.md5
Pit for 16GB - Q1_20110914_16GB.pit
I connect my phone and try to install the firmware again, but odin fail and my samsung became a nice brick.
The phone currently does not turn on, the phone is in download mode and I install QPST and the program recognize the system in download mode.
I want to try your method because other information I collected said that I have to send it to guarantee.
Can I install i717 rom in the E160L?
I will be waiting for your post because sincerely I don't know how to repair it.
Thank you so much.
Hello darkspr1te
First of all, nice work there (though I didn't understood most of the things there, but seems there is some good work going on on our SHV-E160's
On your comment;
( i flashed the phone with i717 roms, working, SHV-E120 roms, working, N7000 rom complete fail)
Does that mean that i717 roms can work on the SHV-E160 devices? Please share if that is the case.
The geeky bits
tyllerdurdent said:
Thank you so much for your help.
My phone is a samsung galaxy note SHV-E160L korean version.
what happen was:
I tried to upgrade the firmware with kies and suddenly the program crash. My phone enter in an error issue with the firmware and said use emergency recovery mode.
I tried the recovery several times (uninstalling kies and install it again but that never work).
So, I download odin and this files to restore the original firmware:
CSC - GT-N7000-MULTI-CSC-OZSLPF.tar.md5
Phone - MODEM_N7000XXLR1_REV_05_CL1144476.tar.md5
Bootloader- N7000_APBOOT_N7000ZSLPF_CL558430_REV02_user_low_sh ip.tar.md5
PDA - N7000_CODE_N7000ZSLPF_CL558430_REV02_user_low_ship .tar.md5
Pit for 16GB - Q1_20110914_16GB.pit
I connect my phone and try to install the firmware again, but odin fail and my samsung became a nice brick.
The phone currently does not turn on, the phone is in download mode and I install QPST and the program recognize the system in download mode.
I want to try your method because other information I collected said that I have to send it to guarantee.
Can I install i717 rom in the E160L?
I will be waiting for your post because sincerely I don't know how to repair it.
Thank you so much.
Click to expand...
Click to collapse
Ok, as i said it's still a work in progress at the moment.
I used the i717 bootloaders (thats why we have a brick as it's not getting to the aboot loader or little kernel as some other refer to it) and E160 modem and application cpu as my first target is getting odin mode back.
I was able to also use the E120 bootloaders (screen was messed up though )
I've just got home from a very long shift so i will do a full and clear write up ( STILL a work in progress ) tomorrow (20th)
but i will explain the basic now as you do need to download large files before we continue.
First you need to download the same firmware as you were originally on before the brick, The reason is because between versions i suspect there is minor changes in partition tables (that why the n7000 roms brick )
If you dont have the latest QPST (2.7.3xx or higher ) please google for it now, there are many sites that offer it. (links will folllow tomorrow)
also down load :-
ABOOT_SGH-I717M_I717MUGLA2_user_CL875155_REV00.tar (or tar.md5 )
i717-GB-Modem.tar (or .md5)
now my initital work was based off a chinese link for the A820L
http://blog.csdn.net/su_ky/article/details/7773273
To save you the time of many hours of translation and cross reference here is the quick run down
When the phone is in QDLoad mode its because the PBL (Stored in ROM , read only memory) could not start SBL1 or SBL2 , it stores the error in IRAM location 0x3FF18 and then goes to QDLoad fail mode. At this point it has tried uart, sd-card before hand and those failed too.
IRAM is the small built in memory of the MSM8660 CPU, it has not initiated the main SYSTEM ram yet so our memory space ro running code is 87k and 256k (refer to document 8960_boot_architecture.pdf found the unlock bootloaders section.
Now because our partition table and or our bootloaders are damaged (or we have emmc brick bug) we have to rewrite that data again to revive our bricks.
This is where it gets hard, and where my warnings now come into play.
right now you must think of the EMMC chip (its the name for the internal SD-CARD we boot from and store our normal data, imei and all the other data of the system, it is just a sc-card with better security for our purpose)
This emmc chip holds all of you settings for phone function and we must not loose that,
But...
we have to write data to the chip to boot again, I am not fully aware of all the memory locations so this is assumptions on my part.
we are going to write a basic bootloader that turns the whole phone into a sd-card, then write new bootloaders
using QPST we upload 8660_msimage.mbn (its a out of the box emmc factory image) this file is ment for setting up of dev versions of the phone, it made up of the following parts
sector 0 partition table or (partition0.bin AFTER patching with info from patch0.xml) I do not have a real copy of the original of this, it can be pulled from a working SVH-E160x using the code at the end.
after the MBR (which is the first part of the partiton make up, EBR follows, we can have 3 primary partitions and the fourth is a extended which is just another partiton table pointing to the next EBR and so on, upto 29 parititons i think)
anyway, after the MBR is SBL1, which chainloads SBL2 then that side loads RPM, gets a go signal then loads SBL3, when SBL3 is done most of the device hardware has been mapped into the cpu's memory table, SDRAM is now ready for larger code,
aboot now loads
some of the above loading functions occur at the same time and some wait on go signals from other code in other CPU's and some fail due corruption and or security check fails( JTAG users can watch the memory as it changes and halt, change data and continue which is why JTAGers's have more power , we dont have loader outputting data yet so no feed back, hence the brick)
when aboot is loaded we now have access to odin, so thats the goal, get aboot loaded for now who cares about the rest of the funtions.
we do need to care about those function later so thats why we will backup the entire system, i dont know if this will really work when restored and bring back all of our settings, thats later,
So onto the writing and possibly overwriting of important information, WARNING, i dont know yet if we are overwriting imei or simalr data yet so proceed at your own risk.
We will get the required from factory (qualcomm test or dev board not samsung factory in the box for consumer) from the MUI phone firmware
http://bigota.d.miui.com/QDN43/Mioneplus_QDN43_fastboot_Android_4.0_d3d83nmdk2.zip
from this zip we want 8660_msimage.mbn, patch0.xml, partition0.bin MPRG8660.hex ( this file is uploaded first, its a serial bootloader that is loaded at 0x2a000000 (start of PBL IRAM space 256k in size) and that setups a emmc to command access (we use revskill to upload the same file and dump memory , sadly ive not found a way of pulling the entire emmc to a backup, if we can figure that out we can pull the entire boot chain, fix it and send it back with what ever versions we desire, for now revskill is used to read the PBL error so we can at least see why we cant boot, not quite jtag but best we got ))
so now we have a phone running a basic bit of code that allows us to use code sent to serial port to write (possibly read) the emmc
we then use QPST to write the 8660_msimage.mbn as a one to one copy to the very start of the emmc , reboot phone and then when the phone restarts, it sets up the ram, some hardware (charging system, you will now notice your phone gets warmer that before when plugged in) and gives us direct access to the emmc as if it was a sd-card
at this point you could move the phone to any pc and it's just a sd-card branded qualcomm
BUT at this point the pc or any other computer you connect it too only see's the partition table contained in the 8660_msimage.mbn file , you other data is there so i advise the next step you MUST do.
connect the phone to a linux computer (use a live cd or live usb if you are not a normal linux user)
you will then run the following command
Code:
dd if=/dev/sd? of=/mount/location/shv-e160-full-emmc.bin bs=512
? is the letter of the drive , use dmesg and look for sdb or sdc , if you dont understand this part then i would suggest waiting for a possible script/one click solution. right now i am still booting only 1 in 20 boots and do not yet know why the boots fail and why some work.
of=/mount... this is where you will place the entire 16GB (32GB for 32gb models ) which should be a one to one copy of the system
the bs=512 is very important, it's block size, again, if you dont understand then maybe wait.
Thats enough for now, i am going to spend a hour or two working on some theories i came up with today.
user with working phones, please google how to backup parts of your phone, this may happen to you so it's best to backup asap !!!
from the blog.csd site a script to grab the partition table data, if a working usr could please run this and post the file, it does not contain user data only the partiton table and a direct 1 to 1 restore for any phone, i think it possible to write that direct back to a QDLoad mode phone, re write the bootloaders from linux and bingo working phone. i dont have backups as it's not my phone, it belongs to a client who knows i like to tinker with electronics.
anyway, once i have the partition file i can overlay it on my test phone (which i can activate QSLoad at any time, hence it's unbrick-able dev mode)
once the partition file is written to my phone, i can build a script to backup your important data, write known working bootloaders, and reboot the phone into a usable device.
here is the script in python (user linux live cd with a copy of adb, just google adb linux pack, there is a windows and linux allin one pack)
or you can get the original from the link above, i've not tested this as i dont have a device in adb mode but i've read through it and it looks sound but never tested by me.
Well i hope that enlightens you, am sorry i dont have a all in one solution for you, it's still a dev project and most of the information i have has only been collected over the past week, i only discovered it's QSDload after getting a msm8660 schematic and i still dont know what i am trully shorting out to trigger the QSDload when ever i want, even when it's booted
If any one from the unbrickable project(s) want to get in touch to share info i would be happy, i am also sure this is a usable solution for HTC phones as well
oh and one last thing
i read only a hour ago (via cell phone while in a car so not 100%) that once the phone is in QSDload and stays in QSDload on every power cycle then we can write the partition table to a SD-CARD and it will boot that, i have not tested that yet, i will try and see if the 8660_msimage.mbn file written to a sd-card works
I also suspect that some of my good boots have been when i've mixed up the sdcard with system.img.ext4 etc on it with the one with just update.zip on it. it's one my list of things to check , any suggestions are welcome as to how i correctly format the card (heads,cylinders, block size etc)
ok folks, hope this helps
COPY TEXT BELOW ONLY INTO A FILE AND RUN WITH PYTHON (linux is easier, may be possible to use a vm box, i am but linux is my main os and windows is the vm)
Code:
import os
from struct import *
def mbr():
global offset, partitions
os.popen("adb shell su -c 'dd if=/dev/block/mmcblk0 of=/cache/partition0.bin bs=512 count=1'").close()
os.popen("adb shell su -c 'cp /cache/partition0.bin /sdcard/partition0.bin'").close()
os.popen("adb pull /sdcard/partition0.bin .").close()
f = open("partition0.bin", 'rb')
data = f.read()
f.close()
partitions = [ ]
n=0
while True:
buf = data[446+(16*n):446+(16*(n+1))]
partition = dict(zip(('boot', 'id', 'start', 'size'), unpack('4I', buf)))
partition['type'] = "MBR"
n += 1
partition['no'] = n
partitions.append(partition)
if partition['id'] == 5:
offset = partition['start']
break
def ebr():
global offset, partitions
n = 0
while True:
a = 0
os.popen("adb shell su -c 'dd if=/dev/block/mmcblk0 of=/cache/ebr bs=512 count=1 skip=" + str(offset+n) + "\'").close()
n += 1
os.popen("adb shell su -c 'dd if=/cache/ebr of=/cache/partition0.bin bs=512 count=1 seek=" + str(n) + "'").close()
os.popen("adb shell su -c 'cp /cache/ebr /sdcard/partition0.bin'").close()
os.popen("adb pull /sdcard/partition0.bin .").close()
f = open("partition0.bin", 'rb')
data = f.read()
f.close()
while True:
buf = data[446+16*a:446+16*(a+1)]
partition = dict(zip(('boot', 'id', 'start', 'size'), unpack('4I', buf)))
if partition['id'] == 5:
break
if partition['id'] == 0:
return
partition['type'] = "EBR"
partition['no'] = n
partition['start'] += n-1+offset
partitions.append(partition)
a += 1
if __name__ == "__main__":
mbr()
ebr()
os.popen("adb shell su -c 'cp /cache/partition0.bin /sdcard/partition0.bin'").close()
os.popen("adb pull /sdcard/partition0.bin .").close()
for part in partitions:
print "%s %2i, Boot: 0x%02X, Id: 0x%02X, Start: 0x%08X (%8i), Size: 0x%08X (%8i, %8i KB)" % (part['type'], part['no'], part['boot'],part['id'], part['start'], part['start'], part['size'], part['size'], part['size']/2)
Click to expand...
Click to collapse
beginning
thank you for your help,
I currently have the qpst version 2.7 build 373. You think is enough of download the same version of Chinese post QPST.2.7.374.rar
I will begin to download the other files required and I will be commenting my progress.
Thank you so much for your help, i really appreciate that you share you r knowledge.
Requests
While i try some theories if othe users could possibly provide me with :-
Original partition table via script above and also via adb
use
adb and run
Code:
cat /proc/partitions > /sdcard/partitions.txt
fdisk -l /dev/block/mmcblk0 > /sdcard/fdisklist.txt
mount > /sdcard/mountlist.txt
Then on the pc side using ADB again do the following
Code:
adb pull /sdcard/partitions.txt
adb pull /sdcard/fdisklist.txt
adb pull /sdcard/mountlist.txt
and post those files.
there are many posts on it so wont repeat but later will add a link.
along with some spell checks :laugh:
if you can dump the boot loaders from a original e160x too as my data started currupt.
i also need to talk to someone who can assist me in writing a program to take the pit file and turn it into this
Code:
<?xml version="1.0" ?>
<data>
<!--NOTE: Sector size is 512bytes-->
<program file_sector_offset="0" filename="" label="SMD_HDR" num_partition_sectors="65536" physical_partition_number="0" size_in_KB="32768.0" start_sector="1"/>
<program file_sector_offset="0" filename="sbl1.mbn" label="SBL1" num_partition_sectors="1000" physical_partition_number="0" size_in_KB="500.0" start_sector="65537"/>
<program file_sector_offset="0" filename="sbl2.mbn" label="SBL2" num_partition_sectors="3000" physical_partition_number="0" size_in_KB="1500.0" start_sector="66537"/>
<program file_sector_offset="0" filename="rpm.mbn" label="RPM" num_partition_sectors="1000" physical_partition_number="0" size_in_KB="500.0" start_sector="69559"/>
<program file_sector_offset="0" filename="sbl3.mbn" label="SBL3" num_partition_sectors="4096" physical_partition_number="0" size_in_KB="2048.0" start_sector="70559"/>
<program file_sector_offset="0" filename="aboot.mbn" label="ABOOT" num_partition_sectors="5000" physical_partition_number="0" size_in_KB="2500.0" start_sector="74655"/>
<program file_sector_offset="0" filename="" label="BOOT" num_partition_sectors="20480" physical_partition_number="0" size_in_KB="10240.0" start_sector="79655"/>
<program file_sector_offset="0" filename="tz.mbn" label="TZ" num_partition_sectors="1000" physical_partition_number="0" size_in_KB="500.0" start_sector="100135"/>
<program file_sector_offset="0" filename="partition0.bin" label="MBR" num_partition_sectors="1" physical_partition_number="0" size_in_KB="0.5" start_sector="0"/>
<program file_sector_offset="1" filename="partition0.bin" label="EXT" num_partition_sectors="22" physical_partition_number="0" size_in_KB="11.0" start_sector="69537"/>
</data>
Click to expand...
Click to collapse
*edit
the partiton0.bin provided below is 8.5kb (.5kb MBR, 8kb EBR) and in raw_program0.xml bove it say 0.5kb and 11kb, making that file 11.5kb, i dont know if the A810 has larger or smaller EBR than us, it could be they pulled extra, in my reading of the dumps i've seen lots of padded 0's after files (between sbl2/ebr/rpm) anyway if you just copy paste it will throw a error, ive got it set at 0.5 and 8.
EDIT:- Do not use this file, ive uploaded newer files later on.
some of the questions i need to answer are :-
1. what is the first partition, it's dos, around 105mb and labled smd_hdr and is filled with smd_hdr.bin (or mbn)
2. what are the real sector locations of the files, above you will see the rawpartiton0.xml file, this tells QPST where in the emmc to put the data num_partiton_sectors does match data from the pit files, but i dont know the real offsets yet, (samsung or htc could put the rest of the partiton table in cpu qfuse data areas and not write it to the emmc to confuse us and write the real files to another location and use the pit file as a base+offset calculation)
start_sector is the real location on the emmc, where it starts writing the file.
at the end is partiton locations(its a generic file containing the first few byes of default partition table, patch0.xml then updates this data), i dont have our device specific figures yet, i also dont fully understand patch0.xml and the difference in figures used.
if we have a backup of each of the different version of android partitons we could just write that in replacement of partiton0.bin and we dont need patch0.xml, this file sole job to alter the generic files, oem's have the choice of changing this data.
Code:
<?xml version="1.0" ?>
<patches>
<!--NOTE: This is an ** Autogenerated file **-->
<!--NOTE: Patching is in little endian format, i.e. 0xAABBCCDD will look like DD CC BB AA in the file or on disk-->
<!--NOTE: This file is used by Trace32 - So make sure to add decimals, i.e. 0x10-10=0, *but* 0x10-10.=6.-->
<patch byte_offset="506" filename="partition0.bin" physical_partition_number="0" size_in_bytes="4" start_sector="0" value="NUM_DISK_SECTORS-208801." what="Update MBR with the length of the EXT Partition."/>
<patch byte_offset="506" filename="DISK" physical_partition_number="0" size_in_bytes="4" start_sector="0" value="NUM_DISK_SECTORS-208801." what="Update MBR with the length of the EXT Partition."/>
<patch byte_offset="458" filename="partition0.bin" physical_partition_number="0" size_in_bytes="4" start_sector="16" value="NUM_DISK_SECTORS-1695744." what="Update final partition with actual size."/>
<patch byte_offset="458" filename="DISK" physical_partition_number="0" size_in_bytes="4" start_sector="208816" value="NUM_DISK_SECTORS-1695744." what="Update final partition with actual size."/>
</patches>
Click to expand...
Click to collapse
please note that it's two lines of the same code except one is partition0.bin and the other is DISK,
Do we need both? i know if i dont add the partiton0 section used in raw_program.xml then the drive is blank in linux,
now it's my understanding that the ebr comes as the forth partiton and it point to the next one , above in patch0.xml it start at NUM_DISK_SECTORS-1695744
i am still trying to better understand these figures,
Well time to grab coffee, i guess it's a dev night in.
the file MPRG8660.HEX can be renamed EMMCBLD.HEX and it triggers QPST to always look for a QDLoad mode phone and not debug, you can place all the files you need in one folder, i advise you to keep the originals in one location and only extract what your need to your worrking folder, copy emmcswdowload.exe from the QPST folder there too, we might need to do command line work, ive read that you can pre-create images in emmcswdownload (the same way 8660_msimage.mbn was created ) that you could just drop onto a phone once it's in emmc sd-card mode, almost a one click.
More info, plus help offered
Your welcome tyllerdurdent,
I am going to be putting a few hours into the dev from now actually for if you want assistance then no problems,
I also advise the following, download ubuntu live cd, it has a lot of tools your going to need to extract data you require, if we go step by step we might be good, i did a lot of test writing before i got my first boot, and that again only happens one in 20, i dont know why.
the rawpartiton0.xml above is incorrect for our devices as it states the first partion is 32mb, (i think it's ment to be amss.mbn, or NON-HLOS.mbn , our pit file which i did extract from my emmc dump says it's 105mb. i am confused and to why rawpartiton0.xml says the first bootloader is at start_sector="65537" but fdisk shows it as start 204801, i think someone needs to show me how to convert from blocks to sectors,
in patch0.xml it says
Code:
<patch byte_offset="506" filename="partition0.bin" physical_partition_number="0" size_in_bytes="4" start_sector="0" value="NUM_DISK_SECTORS-208801." what="Update MBR with the length of the EXT Partition."/>
Click to expand...
Click to collapse
208801 is where we have our ebr start,
i also think the IROM based pbl, sbl etc use the partition types in some way, why else have so many types? can any one explain that
this is a fdisk view of what i think our partition table looks like
Code:
Device Boot Start End Blocks Id System
/dev/sdb1 1 204800 102400 c W95 FAT32 (LBA)
/dev/sdb2 * 204801 205800 500 4d QNX4.x
/dev/sdb3 205801 208800 1500 51 OnTrack DM6 Aux1
/dev/sdb4 208801 208801 0 5 Extended
/dev/sdb5 212992 213991 500 47 Unknown
/dev/sdb6 221184 225279 2048 45 Unknown
/dev/sdb7 229376 234375 2500 4c Unknown
/dev/sdb8 237568 258047 10240 48 Unknown
/dev/sdb9 262144 263143 500 46 Unknown
/dev/sdb10 270336 271335 500 5d Unknown
/dev/sdb11 278528 279527 500 91 Unknown
/dev/sdb12 286720 307199 10240 93 Amoeba
/dev/sdb13 311296 511999 100352 c W95 FAT32 (LBA)
/dev/sdb14 516096 522239 3072 4a Unknown
/dev/sdb15 524288 530431 3072 4b Unknown
/dev/sdb16 532480 538623 3072 58 Unknown
/dev/sdb17 540672 741375 100352 8f Unknown
/dev/sdb18 745472 751615 3072 59 Unknown
/dev/sdb19 753664 759807 3072 5a Unknown
/dev/sdb20 761856 29843455 14540800 5b Unknown
/dev/sdb21 770048 790527 10240 ab Darwin boot
/dev/sdb22 794624 815103 10240 60 Unknown
/dev/sdb23 819200 839679 10240 94 Amoeba BBT
/dev/sdb24 843776 3911679 1533952 a5 FreeBSD
/dev/sdb25 3915776 8114175 2099200 a6 OpenBSD
/dev/sdb26 8118272 8736767 309248 a8 Darwin UFS
/dev/sdb27 8740864 9005055 132096 a9 NetBSD
/dev/sdb28 9011200 10035199 512000 95 Unknown
/dev/sdb29 10035200 30777343 10371072 90 Unknown
Oh, download wxdhex or wimlar program, you going to need a hex editor that can load BIG files , 16gb worth
i717-GB-Modem.zip IS THE SAME AS TAR?
i717-GB-Modem.zip 21.35 MB 7 0 2012-06-30 08:45:11
I could not find the i717-gb as tar file but I find it as a zip file. but I'm not sure about thif the contents are correct. Could you check
http://d-h.st/1aP
i717-GB-Modem.zip contents
META-INF
COM
GOOGLE
ANDROID
update-binary
updater-script
TMP
amss.bin
mdm.bin
Blocks and sectors
This may explain it , the different figure in the xml files
Because sectors are logical on the drive (Logical Block Addressing = LBA) you need to convert between LBA and physical (file system) sectors. This is pretty easy to do:
First - get a table of the start and end sectors of the partition table:
Code:
[[email protected] ~]# fdisk -lu /dev/hda
Disk /dev/hda: 120.0 GB, 120034123776 bytes
255 heads, 63 sectors/track, 14593 cylinders, total 234441648 sectors
Units = sectors of 1 * 512 = 512 bytes
Device Boot Start End Blocks Id System
/dev/hda1 * 63 208844 104391 83 Linux
/dev/hda2 208845 4401809 2096482+ 83 Linux
/dev/hda3 4401810 8482319 2040255 82 Linux swap
/dev/hda4 8482320 234436544 112977112+ 5 Extended
/dev/hda5 8482383 29447144 10482381 83 Linux
/dev/hda6 29447208 50411969 10482381 83 Linux
/dev/hda7 50412033 52516484 1052226 83 Linux
/dev/hda8 52516548 234436544 90959998+ 83 Linux
Use this to determine what partition the bad sector is in. In this case 232962120 is inside the start and end values for /dev/hda5
NOTE: This is in partition 5 - ignore partition 4 as it is the extended partition. Any block from partitions 5 through 8 will also be in partition 4, but you want the real partition, not the extended partition.
Next, calculate the file system block using the formula:
b = (int)((L-S)*512/B)
where:
b = File System block number B = File system block size in bytes (almost always is 4096) L = LBA of bad sector S = Starting sector of partition as shown by fdisk -lu and (int) denotes the integer part.
For example:
The reported sector from the smart log above is 232962120, thus:
((14858312 - 8482383) * 512) / 4096 = 796991.125
^Bad Sec. ^Start Sec. ^Cha Ching! This is the sector!
(Use the block number from the smart test section, not from the smart error log section. They are using different methods of reporting file system vs. physical blocks.)
((BadBLock - StartPartition) * 512) / 4096
You can just paste this into Google as a template
Any fraction left indicates the problem sector is in the mid or latter part of the block (which contains a number of sectors). Ignore the fraction and just use the integer.
Next, use debugfs to locate the inode and then file associated with that sector:
Click to expand...
Click to collapse
[[email protected]]# debugfs
debugfs 1.35 (28-Feb-2004)
debugfs: open /dev/hda5
debugfs: icheck 796991
Block Inode number
796991 <block not found>
debugfs: quit
Ah! It didn't give the inode! It if did, you could have found the file with:
[[email protected]]# debugfs
debugfs 1.35 (28-Feb-2004)
debugfs: open /dev/hda5
debugfs: icheck 796991
Block Inode number
796991 41032
debugfs: ncheck 41032
Inode Pathname
41032 /S1/R/H/714197568-714203359/H-R-714202192-16.gwf
So what the heck? Why no inode? Well, remember how it said the sector might be bad?
Click to expand...
Click to collapse
the above copied from
http://timelordz.com/wiki/SMART_Rewriting_Bad_Sectors
i have a feeling we may need to shift our files (the basic files need to start odin are listed in rawpatch0 above, i dont know if that 100% true but it was the only files i wrote on by first sucess)
also
http://forum.xda-developers.com/showthread.php?p=31843525&postcount=13
in the above link they talk about the header of the qualcomm file
+------------+
|Dbl-preamble|
+------------+
|Dbl-header |
+------------+
|Dbl.bin |
+------------+
Click to expand...
Click to collapse
and
data_ptr = autodetectpage;
*data_ptr = sbl_header.codeword;
data_ptr++;
*data_ptr = sbl_header.magic;
data_ptr++;
*data_ptr = AUTODETECT_PAGE_SIZE_MAGIC_NUM;
Click to expand...
Click to collapse
now i used this in a way to find my bootloaders (i717 by this time, not shve-160l )
and to find the partitons
you will see in a hex editor at the start of each boot loader
something else to think about, my lack of success that last two days to produce a boot could be because my partitons are not clean , thats is to say if i write my sbl1 to 1000, and the trailing 0000 of the partition definition of my 99 block ebr/mbr ends at 999 , if i have dirt data between 999 and 1000 the cpu/pbl my interpret that as code(some of my boots is brick, some are into QDLoad, i have no pattern yet) , something i must test or confirm, or just worry about.
tyllerdurdent said:
i717-GB-Modem.zip 21.35 MB 7 0 2012-06-30 08:45:11
I could not find the i717-gb as tar file but I find it as a zip file. but I'm not sure about thif the contents are correct. Could you check
http://d-h.st/1aP
i717-GB-Modem.zip contents
META-INF
COM
GOOGLE
ANDROID
update-binary
updater-script
TMP
amss.bin
mdm.bin
Click to expand...
Click to collapse
Yes thats correct
updater script btw contains text, binary is the flashing exe i think,
Code:
run_program("/sbin/dd", "if=/tmp/mdm.bin", "of=/dev/block/mmcblk0p17");
run_program("/sbin/dd", "if=/tmp/amss.bin", "of=/dev/block/mmcblk0p13");
Click to expand...
Click to collapse
and a google of a simlar sansung product the skyrocket gives me a simlar pit layout
Device Name Size Part Name ODIN tar file Mount Point
mmcblk0boot0 512KB (empty) n/a (empty partition)
mmcblk0boot1 512KB (empty) n/a (empty partition)
mmcblk0p1 100MB SMD_HDR (partition info)
mmcblk0p2 500KB SBL1 sbl1.mbn
mmcblk0p3 1500KB SBL2 sbl2.mbn
mmcblk0p4 1KB (unnamed partition with '55 AA' MBR signature)
mmcblk0p5 500KB RPM rpm.mbn
mmcblk0p6 2MB SBL3 sbl3.mbn
mmcblk0p7 2500KB ABOOT aboot.mbn
mmcblk0p8 10MB BOOT boot.img
mmcblk0p9 500KB TZ tz.mbn
mmcblk0p10 500KB SSD n/a (empty partition)
mmcblk0p11 500KB PIT celox.pit
mmcblk0p12 10MB PARAM param.lfs
mmcblk0p13 98MB MODEM amss.bin /system/etc/firmware/misc
mmcblk0p14 3MB MSM_ST1 efs.img
mmcblk0p15 3MB MSM_ST2 n/a
mmcblk0p16 3MB MSM_FSG n/a
mmcblk0p17 98MB MDM mdm.bin /system/etc/firmware/misc_mdm
mmcblk0p18 3MB M9K_EFS1 efsclear1.bin
mmcblk0p19 3MB M9K_EFS2 efsclear2.bin
mmcblk0p20 3MB M9K_FSG n/a
mmcblk0p21 10MB DEVENC enc.img.ext4 /efs
mmcblk0p22 10MB RECOVERY recovery.img
mmcblk0p23 3MB FOTA n/a
mmcblk0p24 598MB SYSTEM system.img.ext4 /system
mmcblk0p25 2GB USERDATA userdata.img.ext4 /data
mmcblk0p26 302MB CACHE cache.img.ext4 /cache
mmcblk0p27 129MB TOMBSTONES tomb.img.ext4 /tombstones
mmcblk0p28 11.2GB UMS ums.rfs /mnt/sdcard
Click to expand...
Click to collapse
Other files
contents of the i717 boot loaders i used
ABOOT_SGH-I717M_I717MUGLA2_user_CL875155_REV00
Code:
527K Jan 6 2012 aboot.mbn
115K Jan 6 2012 rpm.mbn
72K Jan 6 2012 sbl1.mbn
111K Jan 6 2012 sbl2.mbn
601K Jan 6 2012 sbl3.mbn
117K Jan 6 2012 tz.mbn
other files pulled from
ABOOT_SGH-I717M_I717MUGLA2_user_CL875155_REV00 (no bootloader but all the other system files )
After a long time search i think i can do a custom rom along with a CWM Recovery for TURBO X HIVE III tablet, but i need ORIGINAL boot.img, kernel.img, misc.img, recovery.img, system.img dump. I will do it myself, but in my Turbo X Hive III tablet i do not have original Andoid OS 4.1.1. I already put it on this nice tablet C.M.10.1 but with some other kernel from another tablet and i screw up the touchscreen drivers. From what i understand some of them are integrated in kernel, but i do not have the original kernel image! For those who wants to help to update this tablet (offcourse must have this device) i will upload a tool that can be easily dump .img for our needs! If more people want to develop something nice for this tablet i will provide more details on what we need to do or what i already did! But for now i will wait and see.....!!!
For the tool dump click HERE
Understanding!
Learning things first (optional).
All this is OPTIONAL for you to learn. If you don’t want to learn it then move on down to the instructions!
Understanding NAND layout:
Your NAND chips is broken into "partitions" or parts if you will call it that.
Each one of these servers a purpose. Here are all the partitions of a RockChip ROM.
Loader.bin - this is low in NAND and special. You can flash it but cannot dump it.
parameter - this file tells the loader how NAND memory is split up into partitions.
misc.img - this is a special area that tells the recovery system what to do on boot.
boot.img - this is the boot section and basically is the ram disk the kernel uses to boot.
kernel.img - this is of course the kernel.
cache.img - this is an area APPs store information like Google Play for instance.
kpanic.img - this is a special area for use by the kernel.
metadata.img - this is a NEW area for KitKat only. It does not exist in pre-kitkat ROMs. It's used for Encryption.
recovery.img - this is like boot.img but boots the recovery menu system.
system.img - this is the system OS.
backup.img - I am not sure what this is. It started showing up with Rockchip ROMs but does not appear to do anything.
But it might be work backing up anyway.
userdata.img - this is where APPs get installed, user accounts are stored, databases, etc. This area if erased losses all your user installed apps, settings, etc. A factory data reset erases this area.
user.img - This is the remaining NAND space and is set aside as the Internal SDcard.
Please note, many APPs like games, etc store stuff here! Erasing this you can lose data! This is also erased on a factory reset.
So based on the above what parts are a stock ROM?
Loader.bin
parameter
boot.img
kernel.img
misc.img
recovery.img
system.img
As you can see a stock ROM is just that! No user data!
Erasing NAND with the flash tool and flashing a stock ROM gives you a empty like new device as if you just bought it.
OK so some basics there. Now let’s look at the parameter file.
It's important because we will be using this to DUMP NAND memory.
I do not need to make you an expert on this but you need to know a few things.
If we look at this area of a parameter file, you will see the partitions I listed above!
Both the ones that hold a stock ROM images as well as ones that are created to be used by the system.
Here is an example of a parameter file for a kitkat ROM.
[email protected](misc),[email protected](kernel),[email protected](boot),[email protected](recovery),[email protected](backup),[email protected](cache),[email protected](userdata),[email protected](metadata),[email protected](kpanic),[email protected](system),[email protected](user)
So what do those number mean in from of each partition name like boot for instance?
First all these numbers are in hex. Second the numbers are blocks of 512 bytes!
let's look at boot..
[email protected](boot)
The first number 0x00006000 is the size of the partition.
The second number 0x0000a000 is the offset into the NAND chip from 0 location (start of the NAND chip).
But remember all these numbers are in 512 blocks.
If you wanted to know the size in bytes then do this math in your PC calculator.
REMEMBER to have the calculator set to HEX!!!
Enter 6000 and now multiply by 200 (fyi 200 hex is 512 decimal).
You will get C00000. Want to see that it decimal? In the calculator just click Dec and it will convert it!
So what we have is 12,582,912 bytes! Basically that is 12 megabytes.
Alright you can do that same math if you wanted to know the offset into NAND in decimal bytes.
Why is all this important? Well if gets you up to speed later when we calculate internal SDcard.
You don't need to know this but it might help you understand if you were to do things on your own.
___________________________________
Instructions for dumping....
Before we begin let’s get familiar with the tool.
In the download run the ROM_Dumper_Tool.exe.
When it opens you will notice 3 tabs at the top.
Download image - this is for flashing ROMs
Upgrade Firmware - this is for lashing single .img ROMs. I won’t be going into this area for as we don’t use it for dumping.
Advanced Function - This is for dumping and doing some NICE stuff! We will be in here all the time for this procedure.
Note: Anytime we dump a partition the tool always makes a file called ExportImage.img in a folder called Ouptut.
So every time we dump a different partition it will overwrite that file unless we rename them first!
Don't forget that please.
OK first lets dump the basic flashable ROM:
To do ANY dumping we need to dump the parameter file of the ROM from NAND.
Why? because we need the start (offset) and count (size) of the partition or we can’t dump anything.
1) Click the advance functions tab.
2) At the bottom is the "export image" button and to empty boxes, Start and Count.
3) To get the parameter file put a 0 in the start box and a 2 in the count.
4) Now press the export image button.
5) Now we need to make this a real parameter file! Rename the file to parameter.txt
6) We need to clean it up a bit. Open in Windows note pad ONLY!!! Do not open in MS word or anything else or it won’t work!
Also you may need to turn on word wrap to see everything (format menu, select word wrap checked).
7) The first line you will see something like this:
PARMi FIRMWARE_VER:4.1.1
Delete all the junk in front of the word FIRMWARE so it looks like this now:
FIRMWARE_VER:4.1.1
8) clean up ending junk. At the end you will see this word:
(user)
After it will be some junk. Delete everything after (user) including any blank space.
When done make sure to hit enter once so there is a new line after (user)
9) Save the cleaned up parameter file but leave it open as we need it to continue.
Now let’s start dumping!
We will do system.img to start with as an example.
1) Look at the parameter file and find (system) and the numbers before it. Example:
[email protected](system)
REMEMBER the number before @ is the COUNT and the number after the @ is the START!
2) Copy the number after the @ example: 0x00484000 into the start box of the advanced tab in the tool.
3) Copy the number before the @ example: 0x00180000 into the count box of the advanced tab in the tool.
4) Press the export image button and wait for it to complete.
5) Go into the Output folder and rename the file ExportImage.ing to system.img
Now we just repeat the steps 1-5 above for
misc.img
kernel.img
boot.img
recovery.img
backup.img (This can be optional but do it anyway especially if this is a first REAL stock ROM dump as we may need it).
Remember to always use the numbers in front of each name! Don't forget to change those or you won’t have a good dump.
Also remember after each dump, to rename ExportImage.img to the proper name of the image you dumped!
Each time you press Export Image, it will overwrite the existing ExportImage file unless you rename it!
When you’re done you should have the basic ROM dump.
misc.img, kernel.img, boot.img, recovery.img, system.img, and backup.img.
You can now use the flash tool 2.1 or the flash tool 1.37 to flash these.
_________________________________
Dumping userdata, cache, metadata, kpanic:
For a user backup the above 4 should be dumped.
We will start with userdata
This is basically the same as above except can take longer depending on how big your user data partition is.
This will be larger than any other partition so far as most devices have at least 1GB or more!
1) Again look at the parameter file and find (userdata) and the numbers before it. Example:
[email protected](userdata)
REMEMBER the number before @ is the COUNT and the number after the @ is the START!
2) Copy the number after the @ example: 0x00080000 into the start box of the advanced tab in the tool.
3) Copy the number before the @ example: 0x00400000 into the count box of the advanced tab in the tool.
4) Press the export image button and wait for it to complete.
5) Go into the Output folder and rename the file ExportImage.ing to userdata.img
Again repeat above for cache, kpanic, metadata.
if your parameter file does not have metadata then no need to dump this as it does not exist.
Remember only KitKat ROMs have this so do not worry if you don’t have it.
_________________________________
Finally to the hardest part but it is not really that hard. Dumping "user" which is internal SDcard.
Note: if you have a 32GB NAND or something large like that, this might not be worth your time!
Just back up internal SDcard another way (file copy) as it will probably be faster.
One way I like to do it is turn on MASS Storage in settings and enable USB to the PC.
Then I just copy the files to the PC.
For restore after flashing a ROM and userdata, I do the same thing and copy the files back to internal sd BEFORE running any apps that need that data on internal SDcard!
Dumping 32GB and flashing a large internal SDcard takes a LONG TIME! If most of your internal SDcard is empty,
dumping and flashing still writes ALL 32GB anyway so it's a waste of time to do this unless you have a LOT on internal SD.
So there is a trade-off... YOU decide which best works for you!
*********
So to back this area up we have to work some things out.
You will notice the parameter file for (user) has no SIZE number just the offset!
Example: [email protected](user)
the [email protected] simply says to use the remaining NAND as all of user (internal SDcard).
Thus to dump it we must calculate the size! To do this we must know how big our NAND chip is.
First put the number after the @ into the start box so we don't forget example: 0x00604000
This is just like the other parts we did above. We need the start point for user (internal SDcard).
Now let’s find out the size of the NAND chip.
In the advanced tab click the Read Flash Info button.
On the right it will display information but we are interested in this:
Flash Size: XXXXX MB
Where XXXXX is the size of your flash chip "page" size.
For instance my "other androidrk3066 device" says 8192 MB.
BUT WAIT! We also have to see how many pages of NAND we have.
Look at the line Flash CS:
If yours has a 0 then that is all you have 8GB
If CS says something like 0 1 2 3 (That’s 4 pages)
Then you have 4 pages of 8GB or 32GB NAND. If it says 0 1 then you have 2 pages or 16GB NAND and so on.
So whatever your size is multiple that by number of pages!
Example my "other rk3066 android device" stick says:
Flash Size 8528 MB
Flash CS: 0
Thus my full NAND size is 8528 as there is only 1 page
(yes the 0 is a page! The first page starts at 0 and a 1 is the 2nd page).
My "other rk3066 android device" says this:
Flash Size 8192 MB
Flash CS: 0 1 2 3
Thus I would take 8192 and multiply by 4 pages = 32768 MB NAND size.
So we now have our total NAND size!
Now a little more math but easy if you follow my instructions.
First we must make the size in MB a REAL GB number (not a MB number in 1000's).
I am going to use 8192 MB (8GB) NAND as an example. (It only had 1 page e.g. Flash CS: 0)
1) Open your PC calculator and again make sure it is set to programmer mode!
2) Make sure your set to Dec (decimal) not Hex mode!!!
2) Type in your NAND size you read or calculated with pages from the tool. My example 8192.
3) Multiply that by 1024. My example 8192 x 1024 = 8388608
4) Now do that one more time and multiply 8388608 by 1024. My example 8388608 x 1024 = 8589934592
5) Now divide this number by 512. My example 8589934592 / 512 = 16777216
So you know what all this math did was take the proper number of bytes and divide them into 512 blocks.
This is what is needed by the flash tool and parameter file!
6) Now press the Hex button on the left of the calculator to convert this to a hex number. My example came to 1000000 Hex.
7) OK now we know the total size of our NAND chip in 512 byte blocks in Hex format!
8) Now take this number and subtract the "start" that what was shown in the parameter file.
In my example parameter file I had [email protected](user) so my start is 604000 (we don’t use the beginning 0's).
So again my example 1000000 - 604000 = 9FC000
We now have our user (internal SDcard) size! It is 9FC000 in hex!!!
9) Enter this number into the count box of the tool. Again my example is 9FC000
BUT we need to enter it in the format the tool needs and that is hex!
Just add the 0x at beginning of the number so the tool knows it's hex. Again my example is now 0x9FC000
Just a note: 0's in front of any hex number are ignored. So 0x009fc000 is the same as 0x9fc000.
10) Make sure as I said above, you also entered the start number! Again in my example 0x00604000
11) Press the export image button and wait for it to finish. Depending on size this could be a long time!
12) Done forget to rename the ExpoertImage.img to user.img!
We are DONE! We now have a flashable FULL backup of the entire NAND chip!
What you should have in the output folder, if you did everything above dumping EVERYTHING is:
parameter.txt
backup.img
boot.img
cache.img
kernel.img
kpanic.img
metadata.img (optional if you had that and were on KitKat)
misc.img
recovery.img
system.img
user.img (internal SDcard)
userdata.img
__________________________________
Flashing your dump:
OK so now you have dumped the ROM and other items and you want to flash them back.
Well we can’t use the 2.1 RK tool! Why? Because it has 2 bugs in it.
1) Flashing userdata. It works but will error at 50% every time.
It actually does flash 100% but due to a math bug in the program it counts to 50% instead of 100%.
2) It won’t flash user (internal SD). If you try it says it did it but it doesn’t.
It returns success instantly so obviously it doesn’t flash anything.
If you did not backup user (Internal SD) then feel free to flash with the 2.1 tool and you will be OK even with the error at 50%.
However I setup the old 1.37 flash tool for you. All of the lines for each image is there.
I even have them checked by default for you.
In the download there is a flasher tool folder. Just run the flash tool from there.
Uncheck anything you didn’t backup or items you don’t want to flash.
Note: if you leave something checked you did not backup or the .img is not in the Output folder, you will get an error.
I left boot loader unchecked as there is no reason to flash that!
OK so that’s it!
Specs!
In case somebody not know what device is about: Turbo-X, 10.1", 1280 x 800 pixels resolution, IPS panel, Front Camera 0.3 Mp, Back Camera 2.0, Android 4.1 Jelly Bean, CPU - Dual Core ARM Cortex A9 at 1.5 GHz, Internal Storage 16 GB, RAM -1 GB, WiFi, Bluetooth, Mini HDMI, Micro usb 2.0 host, microSD card slot, Li-Ion 6600 mah with Android 4.1.1, 3.0.8+ Kernel !
Battery
Also for those who have some problem with battery i found this one that is even better then original HERE
Some other toolkit that i find!
Special thanks to Zeus and Faheem! With their tools you can Check Device, Wipe data, fastboot wipe, Reset user lock, Reset gmail, Reboot device, Fix camera, install usb driver and many other cool stuff!
HERE
My dear friend Seby, i can help you without any problem and maybe we can open a new development thread for this old tablet because i already did a custom rom with a great help from a greek friend Panagiotis! So we will talk in PM about that!
Hello,can i have more information about this rom?
I must fix my brother's tablet ,stuck on bootloader.
It's exactly the same model as the author's of the current thread.
does anybody know how to enter fastboot mode in a turbox hive iii tablet it stuck in boot logo screen and i cannot do anything. If there is something I can do please tell me.
thanks