Rom backup with d2s - MDA II, XDA II, 2060 ROM Development

I'm attempting to backup my Himalaya as per
http://en.pdamobiz.com/en/forum/forum_posts.asp?TID=62
According to everything I can find on the web, here and on other PDA sites I should be able to enter:
d2s 80000000 02000000
d2s 60000000 00300000 sd a
d2s 70000000 01080000 sd a
And end up with a complete backup.
d2s works on it's own, however d2s with any argument seems to do nothing but return me to the prompt.
I assume I'm missing something.
Entering the password doesn't make any difference ... with or without the password I still have the same problem.
Any thoughts?

Bump

Related

unlock mdaII radio 1.17

Hi
I have problem with unlock my pocket qtek 2020.
Radio 1.17
d 1.72.00WE
How can I do it ?
Greetings from Warsaw )
Where did you find that upgrade with 1.17 radio version? Where i can download?
Thank You
I buy new phone with new software and I can`t unlocking my mda
Greetings from Warsaw
can you post a copy to the forum?
to make a copy of your radio rom, do the following:
( you will lose all data on your device, and your sd-card, so make a backup first )
- make sure there is no sd-card in your device.
- boot your device into bootloader mode
( by holding down the big action button together with the power button,
and hard-resetting with the pen at the same time )
now the display should say 'serial' and the bootloader version.
- insert a blank sd-card
- put your device in it's cradle
- start 'mtty' ( see this page )
- select 'usb' in the mtty program.
- type the followint command into the mtty window
Code:
d2s 60000000 00300000
( this will write your radio rom to the sd-card )
- when it says it is done, remove the sd-card.
- hard-reset, and reinitialize your device.
- put it in the cradle again.
- insert the sd-card, answer 'no' to the do-you want to format question.
- use 'psdread' to copy the sdcard image to a file ( you type this command on a windows or dos command prompt )
Code:
psdread -3 0 0x300200 sdradio.img
see here for information on psdread.
correction: I meant 'psdread'.
now put this howto up on the wiki

Backup Original ROM before trash my Himalaya

First of all .. my thanks goes to all the people to this forum!
You're really GREAT !!
In any case sorry for my poor english :wink:
I've few questions ...
I've read many many pages but I can't understand the right procedure to follow for dumping my Himalaya original ROMs because in some pages the "d2s" command is followed by some numbers and in other, by other numbers ... confusion bring me !
After that, otherwise, I've tried to follow the XDA II procedure and the storing procedure to SD seems to be ok .. but when I try to save the rom dump from my SD to PC using ntwr (otherwise was unreadable in Win), I've got a read error but, in any case, I obtain only one file on my PC of about 400 MB and I suppose that something is wrong because all of you speaks of about 50 MB ... so ... What's the right procedure with the right command? How can I be sure that my dump is correct? The dump it's only one file or one for separate ROM Radio and Extended?
When I solve this issue I can try to upgrade my Himalaya to WM2005.
Thank you for your help.
Please help me, I'd like don't lose my guarantee.
This post was submitted also to buzz forum
Now this is the situation ...
Qtek 2020 - 1.66.04ITA
-= Preparing the device =-
01 ) I,m gone to Bootloader (Power + Directions + Reset)
02 ) I see on the device "Serial v1.06"
03 ) I stop MSSync service Ctrl+Alt+Canc and stop wcescomm.exe
04 ) Put device on cradle
05 ) Now I see on the device "USB v1.06" instead of "Serial v1.06"
06 ) Put the 512 MB SD into the device
07 ) Start Mtty 1.42
08 ) Leave as is all the parameters
09 ) I've "USB" port (and not ".WCEUSBSH001") and I press USB
10 ) Ok seems to be connected to the device
-= Dumping the ROM on SD =-
11 ) Into mtty command line I write (and not copy and paste and without "sd a" at the end)
d2s 80000000 02000000
12 ) Device tell me % of work while in mtty I found
SD:Waiting for card insert.........
CMD3 for SD, it's OK, ready to get RCA from response.
SD : Detected one card
SD : ready for transfer OK
pc->drive.total_lba=EEC00
pc->drive.num_heads=0
pc->drive.sec_p_track=0
pc->drive.num_cylinders=0
pc->drive.block_size=200
pc->drive.features=0
pc->drive.RCA=B368
pc->drive.drv_type=40000000
pc->drive.securedAreaSize=0
pc->drive.securityDrv=0
pc->drive.busWidth=1
pc->drive.erasedSize=0
Total card size=1DD80000
SDCARDD2S+,cStoragePlatformTyp e=FF
****************************** ****************************** ****************************** ****************************** ********
Store image to SD/MMC card successful.
USB>
13 ) Then I write
d2s 60000000 00300000 sd a
14 ) Device tell me % of work while in mtty I found
SD:Waiting for card insert.........
CMD3 for SD, it's OK, ready to get RCA from response.
SD : Detected one card
SD : ready for transfer OK
pc->drive.total_lba=EEC00
pc->drive.num_heads=0
pc->drive.sec_p_track=0
pc->drive.num_cylinders=0
pc->drive.block_size=200
pc->drive.features=0
pc->drive.RCA=B368
pc->drive.drv_type=40000000
pc->drive.securedAreaSize=0
pc->drive.securityDrv=0
pc->drive.busWidth=1
pc->drive.erasedSize=0
Total card size=1DD80000
************
Store image to SD/MMC card successful.
USB>
15 ) Then I write
d2s 70000000 01080000 sd a
16 ) Device tell me % of work while in mtty I found
SD:Waiting for card insert.........
CMD3 for SD, it's OK, ready to get RCA from response.
SD : Detected one card
SD : ready for transfer OK
pc->drive.total_lba=EEC00
pc->drive.num_heads=0
pc->drive.sec_p_track=0
pc->drive.num_cylinders=0
pc->drive.block_size=200
pc->drive.features=0
pc->drive.RCA=B368
pc->drive.drv_type=40000000
pc->drive.securedAreaSize=0
pc->drive.securityDrv=0
pc->drive.busWidth=1
pc->drive.erasedSize=0
Total card size=1DD80000
DOCInfoTableinitHW+
Binary0:dwSize=80000
BINFS0:dwSize=0
FAT0:dwSize=1000000
FAT1:dwSize=EA0000
All:dwSize=1F20000
****************************** ****************************** ******
Store image to SD/MMC card successful.
USB>
-= Saving ROM from SD Card to PC =-
17 ) Put the SD Card into a Card Reader
18 ) Go to Dos command line into ntrw path
19 ) Type "ntrw read ROM.nb1 H:" where H: is the Card reader drive
Now start the problem ... :shock:
I want to know if it's all ok with this process ...
The output of ntrw is:
NTRW 2.0
Removable media
Cylinders: 0:60
TracksperCylinder: 255
SectorsPerTrack: 63
BytePerSectors: 512
bufsize is 65536
500629504 bytes written bytes: 0
ReadFile(): ROM.nb1 -- Parametro non corretto
First signal of some error but someone tell that's ok!
And then I see prompt.
Now I find the file ROM.nb1 that is 477 MB (like the SD size after a FAT format).
It's ok? ... I don't think so .. but let's going on!
I open the file with an HEX Editor and the file seems ok but after a string like HTCE the file contains all 00h.
Can I cut off that part?
How can I ensure myself that's all ok?
Come on guru don't leave me with the bootloader splash screen instead of the MAGNETO one :lol: :lol: :lol:
Thanks to rhmartin's help (on buzzdev.net) I've reach this situation ..
I've got my dumped rom in SD and in a file.
But ...
I acquire more information about my Qtek 2020 (XDA2):
ROM: 1.66.04ITA
Radio: 1.10
ExtROM: 1.66.148
I think that's a WM2003 (not SE), isn't it?
In any case ... I put back my dumped roms in SD and followed the procedure for rom restore:
1 - Bootloader
2 - Put SD into device
3 - Wait for "Press Power Button"
4 - ecc. ecc.
But I never reached number 3, what's wrong?
I've put back the dump as a single file (as ntrw output give to me), it's correct or I must put it back (and so backup first in that way) as 3 separate files?
I've seen that in download area there's no WM2003 dumped rom, so I search by myself and I found RUU172128ITA (1.72 ITA) but I prefer if my backup can be useful for disaster recovery and can be used for my original version backup.
I think that you understand my situation .. I prefer ask before a not funny situation instead fill the forum with hundreds emergency posts.
I hope you think I've reason.
Thank you for the patience and sorry for possible misunderstandings or english syntax errors!
NO ONE CAN HELP ME ... INCREDIBLE!
I'm ready to ask sorry but ...
There's no one in this great forum that can help me ...
IT'S INCREDIBLE !!! :shock: :shock: :shock:
I don't think that no one haven't my problem ...
PLEASE SOMEONE HELP ME
:evil:

Boot problem

during flashing with niki-project rom the power went down of entire city
When it came back i couldn't start my niki.
i read some things and tried mtty,
i get this!
Code:
Cmd>boot
No card inserted
OEMGetUpdateMode
OEMTranslateBaseAddress 23 80000000 80000000
IPLMSG:0x8:INFO: Loading image ...
IPLMSG:0x9:INFO: Jumping to image...
OEMLaunchImage 80000000
Jump to Physical Address 10300000
more at http://forum.xda-developers.com/showthread.php?p=2092039#post2092039

[TOOL] MTD-Utils

Here, i've quickly compiled three MTD utils ( git://git.infradead.org/mtd-utils.git ):
nanddump, nandwrite, flash_erase
So far tested nanddump - works , i was wandering what's inside
--
mtd3: 00040000 00020000 "LogFilter"
mtd4: 00300000 00020000 "oem_log"
--
Nothing interesting, actually.
--
nandwrite should enable you to write boot, recovery, system and firstboot right from android system (i don't think that it's good idea, but anyway).
--
Readme:
MTD-Utils 1.5
Please use with extreme caution!
--
Streak 5, dump example for recovery:
./nanddump /dev/mtd/mtd1 -f /sdcard/mtd1
--
Our layout:
cat /proc/mtd
dev: size erasesize name
mtd0: 00500000 00020000 "boot"
mtd1: 00600000 00020000 "recovery"
mtd2: 00600000 00020000 "recovery_bak"
mtd3: 00040000 00020000 "LogFilter"
mtd4: 00300000 00020000 "oem_log"
mtd5: 00100000 00020000 "splash"
mtd6: 10400000 00020000 "system"
mtd7: 08c00000 00020000 "userdata"
--
Have fun,
Sergei (_n0p_)
(tools attached)
--
I was able to switch recovery on the fly, having /sdcard/CWM.img (CWM port by TheManii) and /sdcard/SM.img (Old and trusty StreakMod):
/system/xbin/flash_erase /dev/mtd/mtd1 0 0
/system/xbin/nandwrite /dev/mtd/mtd1 /sdcard/CWM.img
Reboot, checked if works - it does
Back to StreakMod:
/system/xbin/flash_erase /dev/mtd/mtd1 0 0
/system/xbin/nandwrite /dev/mtd/mtd1 /sdcard/SM.img
Changelog:
Added flash_erase
can you please guide how to flash this
should i flash this in streakmod recovery and will it wipe my current streakmod with cwm recovery ?
This zip pack should not be flashed.
This tools can operate on (at least) Streak NAND flash partitions, i.e. read, erase, write.
It contains three android binaries - you should extract them and place, preferably, into /system/xbin
Change permissions on al this files to 755 - like:
chmod 755 nanddump
Now, you should be able to flash boot(kernel) and recovery right from working Android system.
I've given an example in first post.
hunderteins, if you reading this - would you give mtd5 from your device?
I have it empty and wander what image format it should have.
Where is AMSS, DSP and stuff?
What do we have on NAND (my comments are in italic):
I/PrintK ( 1): <5>Creating 8 MTD partitions on "msm_nand":
54MB hole
I/PrintK ( 1): <5>0x000003600000-0x000003b00000 : "boot"
I/PrintK ( 1): <5>0x000003b00000-0x000004100000 : "recovery"
I/PrintK ( 1): <5>0x000004100000-0x000004700000 : "recovery_bak"
I/PrintK ( 1): <5>0x000004700000-0x000004740000 : "LogFilter"
I/PrintK ( 1): <5>0x000004740000-0x000004a40000 : "oem_log"
1MB hole
I/PrintK ( 1): <5>0x000004b40000-0x000004c40000 : "splash"
35MB hole
I/PrintK ( 1): <5>0x000007000000-0x000017400000 : "system"
I/PrintK ( 1): <5>0x000017400000-0x000030000000 : "userdata" (should be 0x000020000000)
W/PrintK ( 1): <4>mtd: partition "userdata" extends beyond the end of device "msm_nand" -- size truncated to 0x8c00000
According to this article:
http://forum.xda-developers.com/showthread.php?t=542688
this areas can be regained and hmmm, altered?
AMSS, DSP, service tag, provider lock and some other interesting stuff could be there!
_n0p_ said:
hunderteins, if you reading this - would you give mtd5 from your device?
I have it empty and wander what image format it should have.
Click to expand...
Click to collapse
nice one. Thanks. But my mtd5 is 1048576 times 0xff.
What is the difference between
$ cat /dev/mtd/mtd5 > /sdcard/mtd5
and
$ nanddump /dev/mtd/mtd5 -f /sdcard/mtd5
?
hunderteins said:
nice one. Thanks. But my mtd5 is 1048576 times 0xff.
What is the difference between
$ cat /dev/mtd/mtd5 > /sdcard/mtd5
and
$ nanddump /dev/mtd/mtd5 -f /sdcard/mtd5
?
Click to expand...
Click to collapse
Well, it seems that nothing, but this makes me feel dumber than usual
I didn't try cat :laugh:
flash_image should be the built in way of writing to mtd and raw emmc partitions, though we rarely ever discuss flash_image
try reading the raw nand at the beginning of it, thats where its stored on emmc devices, and there is unmapped space in the beginning
54mb should be approx enough shouldnt it? (not at pc to verify file sizes of the firmwares)
you could compare to the spro's map i guess, its an emmc device, but not a qisda one.
if i had the mapping for the "streak2 5" that would be the best to compare to, but i dont
is there any way to verify the mem locations are correct? i have the exact emmc layout for the s7/s10 because nvflash provides it if asked.
but there is no standardized tool for qualcomm chips, ill assume they're correct
also: at least on filesystems you should use dd and not cat for the fact that cat drops the final byte or something to that degree.
i dont recall if it applies to yaffs2 but it should for ext, it shouldnt matter for raw mtd partitions
hmmm iam still confused need to wait more to know this all
TheManii said:
flash_image should be the built in way of writing to mtd and raw emmc partitions, though we rarely ever discuss flash_image
try reading the raw nand at the beginning of it, thats where its stored on emmc devices, and there is unmapped space in the beginning
54mb should be approx enough shouldnt it? (not at pc to verify file sizes of the firmwares)
Click to expand...
Click to collapse
You see, tools operate on logical partition level (i think flash_image is a userspace tool that uses mtd partitions, same as mtd-utils).
And kernel doesn't provide a raw device for NAND (i'd love to be wrong though).
I'll try tomorrow to supply kernel an MTD table via mtdparts parameter and check ow it goes.
TheManii said:
flash_image should be the built in way of writing to mtd and raw emmc partitions, though we rarely ever discuss flash_image
also: at least on filesystems you should use dd and not cat for the fact that cat drops the final byte or something to that degree.
i dont recall if it applies to yaffs2 but it should for ext, it shouldnt matter for raw mtd partitions
Click to expand...
Click to collapse
mtd devices are character devices, dd works only on block devices.
I thought apply_patch is the first choice for writing into mtd from the commandline.
there should be a kernel option near mtd in menuconfig where you can setup the mtd-layout manually on the kernel commandline. Thats where I would tinker, when I wouldn't trust atag.
Yes, " Command line partition table parsing" enabled in kernel.
Also, MTD seems to have enabled char read/write access, that makes MTD-Utils a bit obsolete
OK, i'll report if i'll find something interesting.
$ dumpatags /proc/atags
read 412 bytes from /proc/atags in buffer of size 10000
0000 - 0002:54410001 ATAG CORE flags=00000004 pagesize=54420005 rootdev=21000000
0008 - 0004:54420005 ATAG INITRD2 start=21000000 size=0002b4d3
0024 - 0004:54410002 ATAG MEM size=0e800000 start=20000000
0040 - 0004:54410002 ATAG MEM size=0fe00000 start=30000000
0056 - 0058:4d534d70unknown tag
0288 - 0022:54410009 ATAG CMDLINE androidboot.hardware=streak console=ttyMSM2,115200n8 androidboot.baseband=msm
0376 - 0004:afd137cbunknown tag
0392 - 0003:54410007 ATAG REVISION revision=00000016
AMSS MTD partition:
Offset: 0x6C0000, Size: 0x1360000
DSP MTD partition:
Offset: 0x1A80000, Size: 0x1060000
--
Service Tag resides in area starting on 0x360000
--
AppsBoot:
Offset: 0x1A20000, Size: 0x60000
dbl:
Offset: 0x200, Size: 0x1E000
DT:
Offset: 0x620000, Size: 0xA0000
--
Unsure of fsbl and osbl - seems like it's data intermixed with bad blocks on my device.
--
Block from 0x4c40000 contains somewhat altered amss and dsp (maybe something else).
StreakMod recovery.
Kind of side-effect from my test:
StreakMod with replaced kernel (Phoenix, +rotated matrix).
http://n0p.8bit.fm/streak/smd.img
Works in portrait mode (interesting, looks like out matrix was rotated in kernel for 270 in kernel)., no it's different static surface flinger.
Could you make a dump of dt? (and which version of DT you have)
DT obviously isnt straight flashed during a stock update, wonder how it's transformed on install.
I believe it's 407.
http://n0p.8bit.fm/streak/DT.zip (zipped just for integrity)
Which kernel was it that you modded for this? (I mean the exact revision), did you upload it?
I'm keen on dumping everything and attempting to do a write up on it.
I've done a device fixing guide for the S7:
[Guide][Technical]Restoring your device specific data (including Service Tag)
Context: someone uploaded an nvflash dump that also included their device specific data (imei, service tag, etc)
and dozens of people ended up with cloned devices because they blindly flashed it without understanding nvflash.
I would like to do a feasability study to see if it would be possible to restore jtagged S5's (ie ones with blanked IMEI, service tags)
I'd need multiple dumps to compare the unique data, very least we'd be able to learn a thing or three.
I'm guessing that JTAG was always able to access these sections of the nand, and that they were writing bad data to it during restore
(as the jtaggers didnt have a good copy from a working s5?)
Your DT dump is definitely different from the raw DT.img, 366 and 407's DT only differ in their dates, they're more or less byte identical.
It's likely due to DT being "installed" and not mere "extracted" (ie DT_update on stock update)
It's simply a kernel parameters, altering mtd partitions - and you can take them from smd.img I published earlier. There's three unkX partitions mapped to holes in nand layout.
Or I can build a cm7 kernel with this options.
--
Seems like contents or mtd partitions are crc checksummed. Anyway, having full amss and dsp dump should enable us to write'em right on rom flashing and that's good.
For the actual firmware files, it's not important as I'm mainly interested in analyzing the device unique data.
I dont believe the unique data has any checksums, as devices can still boot with blank IMEIs and service tags,
unless it also just so happens that they took that one instance into account.
The S7's data definitely isnt checksummed, but it's a rather different platform.

[Q] Rockchip 3066 TV Box - making an image of the device for replicating

Hi there, long time reader, first time contributor.
[Edit: Sorry I just read this should go in Q&A and I do apologise. Can a moderator please move if appropriate?]
I'm hoping some of you on this forum can help me with a Rockchip 3066 TV Box I am working with. The situation is thus:
I have a number of these boxes, 12 in my possession currently with more on the way
I have successfully rooted the boxes through ADB, none of the one click or other methods worked, but rooting through ADB did.
I have tried using rkdump but unfortunately it cannot find the update.img which I assume to mean it doesn't have one.
What I would like to do is setup a box exactly how I want and then image this off and copy the image to the others
As I mentioned, even though it's a Rockhip based chipset, there's no way I can identify to extract any kind of update.img from it. I have seen through other postings that some of the 3066 based boards no longer use the same cramfs file header/structure the previous 2xxx chipset used so this is probably why.
The big thing is, I just want to mirror the setup to other hardware of exactly the same pedigree.
Here is the MTD/partition map:
Code:
1|[email protected]:/dev # cat /proc/mtd
dev: size erasesize name
mtd0: 00400000 00004000 "misc"
mtd1: 00800000 00004000 "kernel"
mtd2: 01000000 00004000 "boot"
mtd3: 01000000 00004000 "recovery"
mtd4: 18000000 00004000 "backup"
mtd5: 08000000 00004000 "cache"
mtd6: 40000000 00004000 "userdata"
mtd7: 00400000 00004000 "kpanic"
mtd8: 20000000 00004000 "system"
mtd9: 6ac00000 00004000 "user"
My thoughts are I could just dd off the partition to the sd card, and dd this back onto the other devices. I could write a shell script easy enough that could do all this, but obviously trial and error could be an expensive process if I start bricking boxes.
So a couple of questions:
Would the DD thing work?
If so which MTD partition(s) should I dd off
any ideas on what the precise format of the copy to and from commands should be assuming this is the way to go about it?
Is this the wrong way to go about it? Are there better suggestions / ways of achieving this i.e. mirroring devices?
There's a number of applications that ship on the box by default too I need to remove as root, and I'd like to automate everything, hence the idea of imaging as opposed to stepping through all the tasks manually.
Use rkdump to dump kernel, boot and recovery (use /dev/block/mtdblock# as an argument), dd'ing system partition should work, but i wouldn't suggest it because it can be modified during creating dump, and this may corrupts image , so its better to copy all files from system using adb and then create ext4 image using make_ext4fs.
After you done use RKAndroidTool to flash dumped images to your device
lolet said:
Use rkdump to dump kernel, boot and recovery (use /dev/block/mtdblock# as an argument), dd'ing system partition should work, but i wouldn't suggest it because it can be modified during creating dump, and this may corrupts image , so its better to copy all files from system using adb and then create ext4 image using make_ext4fs.
After you done use RKAndroidTool to flash dumped images to your device
Click to expand...
Click to collapse
Thanks very much for your reply, unfortunately rkdump cannot find the boot and recovery.img in any of the mtdblocks, only kernel.img. I had read this is because of the FS Rk3066 uses for some images.
Hence the DD route.... but as you said, there is a possibility of corruption.
DoctorDbx said:
Thanks very much for your reply, unfortunately rkdump cannot find the boot and recovery.img in any of the mtdblocks, only kernel.img. I had read this is because of the FS Rk3066 uses for some images.
Hence the DD route.... but as you said, there is a possibility of corruption.
Click to expand...
Click to collapse
You can dd boot & recovery image safely, then strip 0xFF in hex editor from end if you need lower size of images. Try my tool I attached.Type:
"dump.bat info", to get partition structure you will need later to flash the images, then
"dump.bat recovery o",
"dump.bat kernel",
"dump.bat boot o",
"dump.bat system"
Good luck.

Categories

Resources