Related
Hi
I have created the attachd word document with images on how to change page pool alongwith tools required
None of these tools are created by me and due respect and thanks to the creators of these tools.
Hope this is useful and request someone to upload to wiki site in html format
I am a newbie any modifications, suggestions let me know
Regards
rbalu72 said:
Hi
I have created the attachd word document with images on how to change page pool alongwith tools required
None of these tools are created by me and due respect and thanks to the creators of these tools.
Hope this is useful and request someone to upload to wiki site in html format
I am a newbie any modifications, suggestions let me know
Regards
Click to expand...
Click to collapse
NOPE!!!
The value must be reversed!
Example:
0x223500 - FF FF FF FF 00 00 00 00
Thanks Master Tomal for correction.
If I modify the document as below, would it convey the correct message?
In attached screen the values changed in blue rectangle should be changed as below
00 00 60 00 00 00 00 00 For 6MB Pagepool
00 00 56 00 00 00 00 00 For 5.6MB Pagepool
00 00 80 00 00 00 00 00 For 8MB Pagepool
FF FF FF FF 00 00 00 00 for 128MB devices
Attached is the revised document.
Let me know if there are any further modifications/suggestions..
Many thanks for your guidance.
why cannot download it??
PagePool changer
Thanks for the instructions!
I writed a little utility which are help to modify the NK.FAT file.
Place the PPSET.EXE with same directory with the NK.FAT file, and just run it. When the 64B0... signature found the can be selected the new settings.
Original NK.FAT saved as NK.BAK.
So guys in this post i'll show you how to remove ULDR partition from out ROMs to gain 3 MBs of space that was wasted in all of our earlier ROMs. But first, *SPECIAL* thanks to cmonex for helping me with this
Requirements:
1. A HEX editor
2. os.nb.payload (the one inside \ROM folder)
I've used the payload from our latest WM 6.1 ROM, so my base payload over here is 3.07.720.3 ROM. The removal of ULDR requires you to edit the MBR (master boot record) and MSFLSH50 regions in the payload. So be careful while editing otherwise there would problems in cooking or the deivce won't boot.
So, take HEX editor of your choice and open the payload. The MBR starts at offset 0x0 and ends at 0x1FF. You don't need to worry about whole of the MBR, just take a look at the following HEX strings:
Code:
[size="3"]
000001b0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [COLOR="DarkRed"][b]00 02 [/b][/COLOR]
000001c0h: [COLOR="darkred"][b]01 00 20 7F 01 30 02 00 00 00 7E 18 00 00 [/b][/COLOR][COLOR="Red"][b]00 00 [/b][/COLOR]
000001d0h: [COLOR="red"][b]01 31 23 7F 01 65 80 18 00 00 80 1A 00 00 [/b][/COLOR][COLOR="Blue"][b]00 00 [/b][/COLOR]
000001e0h: [COLOR="blue"][b]01 66 25 7F 81 DF 00 33 00 00 00 3D 03 00[/b] [/COLOR]00 00
000001f0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA[/size]
These 3 strings are actually 3 partitions, the first one is ULDR, 2nd one is XIP and 3rd one IMGFS. Now take a look at the following:
Code:
[SIZE="3"]00000200h: 4D 53 46 4C 53 48 35 30 00 00 00 00 38 00 00 00
00000210h: 00 00 00 00 00 00 00 00 00 00 00 00 [COLOR="DarkGreen"][b]66[/b][/COLOR] 00 00 00
00000220h: 80 00 00 00 00 00 01 00 00 00 00 00 01 00 00 00
00000230h: 00 00 00 00 00 00 00 00 7A 06 00 00 80 00 00 00
00000240h: 00 00 01 00 00 00 00 00 FF FF FF FF FF FF FF FF [/SIZE]
This is the MSFLSH50 region and the marked offset shows the logical block of IMGFS start. So, in order to remove the ULDR, we have to edit the MBR and MSLFSH50 regions in the marked areas.
The ULDR partition starts at 0x400 offset and ends at 0x30FFFF (XIP starts at 0x310000 in the shipped ROM for Elfins). Delete all the HEX bytes from 0x400 upto 0x30FFFF. Deletion of ULDR means start of logical blocks of XIP and IMGFS will go up. So the XIP will start at 0x400 instead of ULDR and IMGFS will start at 0x350000. Now you need to edit the MBR and MSFLSH50 regions to adjust for the new XIP and IMGFS start offsets. So using your HEX editor, change the MBR and FSFLSH50 regions as shown below:
Code:
[SIZE="3"]000001b0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [COLOR="Red"][B]00 02 [/B][/COLOR]
000001c0h: [COLOR="red"][B]01 31 23 7F 01 65 02 00 00 00 7E 1A 00 00 [/B][/COLOR][B][COLOR="Blue"]00 00 [/COLOR][/B]
000001d0h: [COLOR="blue"][B]01 66 25 7F 81 DF 80 1A 00 00 00 3D 03 00 [/B][/COLOR][COLOR="DarkRed"][B]00 00 [/B][/COLOR]
000001e0h: [COLOR="darkred"][B]00 00 00 00 00 00 00 00 00 00 00 00 00 00 [/B][/COLOR]00 00
000001f0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA [/size]
Code:
[SIZE="3"]
00000200h: 4D 53 46 4C 53 48 35 30 00 00 00 00 38 00 00 00
00000210h: 00 00 00 00 00 00 00 00 00 00 00 00 [B][COLOR="DarkGreen"]35[/COLOR][/B] 00 00 00
00000220h: 80 00 00 00 00 00 01 00 00 00 00 00 01 00 00 00
00000230h: 00 00 00 00 00 00 00 00 7A 06 00 00 80 00 00 00
00000240h: 00 00 01 00 00 00 00 00 FF FF FF FF FF FF FF FF [/SIZE]
Save the new os.nb.payload and copy into the \ROM folder of your kitchen replacing the original os.nb.payload. From now on use this payload as your template for cooking ROMs. Since, the XIP and IMGFS start offsets have changed, we need to make a few adjustments to the kitchen (Hybrid, Ervius' or bepe's kitchen) also. Note the following command in CreateROM.bat file inside the \Tools folder:
Code:
..\TOOLS\insert -i ..\ROM\out.bin -o OS.nb.payload -d 0x00310000 -s 0x00350000
This command inserts the new XIP (named out.bin) into the payload. Add REM before this command because insert.exe can't insert the xip at 0x400 for some reason. So there are 2 workarounds for this problem:
1. Use XIPPort.exe to insert the out.bin (created inside ROM folder) at 0x400
OR2. Use msflshtool.exe to insert the out.bin. For using this method, copy the msflshtool.exe to your \Tools folder and add the following command in your CreateROM.bat file in place of "insert.exe ..." command.
Code:
..\TOOLS\msflshtool OS.nb.payload -r ..\ROM\out.bin -p 0
After this step, you are ready to cook your new ROM with extra space of 3 MBs . Happy cooking
Hex Screenshots
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
This is like a scratch note - an easy accessed "guide".
Its purpose is to help everyone understand what are the numbers - bytes - that we are editing according to AMAN's guide for ULDR Removal.
As the title says it is a "hex view" at the latest Official Elfin 3.10.710.00 ROM
to figure out how all those hex-strings are related
and
to be able to change them, knowing what is going on!
Regards!
ababrekar said:
Awesome job brother . Hoping to see this kind of documentation for Diamonds too very soon
Click to expand...
Click to collapse
i would love to, but then u need to send me your Diamond for testing purposes
htctouchp said:
i would love to, but then u need to send me your Diamond for testing purposes
Click to expand...
Click to collapse
Promise me you will also tell me about those imgfs values for the xip playing guide and i'll send it right now
ababrekar said:
Promise me you will also tell me about those imgfs values for the xip playing guide and i'll send it right now
Click to expand...
Click to collapse
yeah i promise once i get the ULDR removed from ur diamond , i'll tell u about the imgfs values also
Yes! ULDR Removal for Elf/Elfins - Work!!!
htctouchp,
Thank you very much!!!
vadyarik said:
Yes! ULDR Removal for Elf/Elfins - Work!!!
htctouchp,
Thank you very much!!!
Click to expand...
Click to collapse
welcome
Good work!!
htctouchp said:
After this step, you are ready to cook your new ROM with extra space of 3 MBs . Happy cooking
Click to expand...
Click to collapse
Whaaaou!
GOOD WORK.
htctouchp said:
After this step, you are ready to cook your new ROM with extra space of 3 MBs . Happy cooking
Click to expand...
Click to collapse
Thanks for this, that's so great! I managed to get 74.9 Mb free storage on my Elf with a cleaned ROM.
A little addon to your great tutorial: If you have the last hybrid with the pagepool patch at the end, comment it or modify the offsets to match the new ones. My first flash was stuck on mobility screen because of this (or was it bad luck ?).
letama said:
A little addon to your great tutorial: If you have the last hybrid with the pagepool patch at the end, comment it or modify the offsets to match the new ones.
Click to expand...
Click to collapse
sorry, i didn't get it
Thanx for this new finding Aman!
It's great!
I noticed that after this ULDR removal, there is only one address that we find the pp pattern(03 15 A0 ...)!
Is it normal or did I mess it up?
htctouchp said:
sorry, i didn't get it
Click to expand...
Click to collapse
The offsets for the pp have been changed, so the script I wrote for the 2.2 Rom was aiming(&hexediting) the wrong offsets, resulting in a non-bootable rom..
Regards!
kokotas said:
Thanx for this new finding Aman!
It's great!
I noticed that after this ULDR removal, there is only one address that we find the pp pattern(03 15 A0 ...)!
Is it normal or did I mess it up?
Click to expand...
Click to collapse
yes, its perfectly normal. if u check the PP offsets of the original payload of any ROM, the first HEX string is in the region of ULDR and the 2nd in the region of the XIP. So obviously u can see only one HEX string now. And as i said in PP changer thread a few days ago that only 2nd HEX string is responsible for the PP change, so even if u don't remove the ULDR, u don't have to edit the 1st HEX string.
The offsets for the pp have been changed, so the script I wrote for the 2.2 Rom was aiming(&hexediting) the wrong offsets, resulting in a non-bootable rom..
Click to expand...
Click to collapse
ok, now i get it.
htctouchp said:
yes, its perfectly normal. if u check the PP offsets of the original payload of any ROM, the first HEX string is in the region of ULDR and the 2nd in the region of the XIP. So obviously u can see only one HEX string now. And as i said in PP changer thread a few days ago that only 2nd HEX string is responsible for the PP change, so even if u don't remove the ULDR, u don't have to edit the 1st HEX string.
ok, now i get it.
Click to expand...
Click to collapse
Can you guys give the PP offset for a 2.2 ULDR ROM, as wel as a 3.xx ULDR ROM? I'll need to add more checks for the Universal PP changer
htctouchp said:
yes, its perfectly normal. if u check the PP offsets of the original payload of any ROM, the first HEX string is in the region of ULDR and the 2nd in the region of the XIP. So obviously u can see only one HEX string now. And as i said in PP changer thread a few days ago that only 2nd HEX string is responsible for the PP change, so even if u don't remove the ULDR, u don't have to edit the 1st HEX string.
Click to expand...
Click to collapse
Found it:
htctouchp said:
will have to change again, coz the 1st HEX string is going to disappear forever
Click to expand...
Click to collapse
lol
It sounds like you did some magic...hehe
Question:
When I followed your instructions and reached to the point of deleting ULDR section, imgfs start offset was 0x350400
and I had to delete some "FF" above to make that 0x350000.
Have you any idea about what went wrong?
kokotas said:
Question:
When I followed your instructions and reached to the point of deleting ULDR section, imgfs start offset was 0x350400
and I had to delete some "FF" above to make that 0x350000.
Have you any idea about what went wrong?
Click to expand...
Click to collapse
0x350400 ? impossible....u must have missed something...try again.
dsixda said:
Can you guys give the PP offset for a 2.2 ULDR ROM, as wel as a 3.xx ULDR ROM? I'll need to add more checks for the Universal PP changer
Click to expand...
Click to collapse
for the 3.XX based nk.exe ULDR removed ROM, the offset is 0x45210. didn't check the 2.XX ROM though.
htctouchp said:
for the 3.XX based nk.exe ULDR removed ROM, the offset is 0x45210. didn't check the 2.XX ROM though.
Click to expand...
Click to collapse
Ok, the Universal PP Changer has been updated and tested with your ULDR hack. All 3.xx ROMs are now supported. I haven't been able to check on 2.xx ROMs without ULDR, however.
Thanks htctouchp!!!!
dsixda said:
Ok, the Universal PP Changer has been updated and tested with your ULDR hack. All 3.xx ROMs are now supported. I haven't been able to check on 2.xx ROMs without ULDR, however.
Thanks htctouchp!!!!
Click to expand...
Click to collapse
welcome!!
i think we don't need to work with 2.2X ROMs now. all the ROMs from now onwards are going to be based on 3.3X ROMs anyway.
All i'm hoping at the moment is that i removed the Bytes correctly .
"Delete all the HEX bytes from 0x400 upto 0x30FFFF"
I took that as a Starting from the beginning of 400 to the end of 30ffff.
Not directly my favourite stuff to do but what is there to loose
Well IF It Boots It Works. (Should have noted storage before, but looks better)
On page 67 of the Service Manual, it mentions "Turn the device power off and insert Diagnostic SD card. Press and hold Capture button, then press Power button to enter Diagnostic mode."
I'm thinking that the camera + power button will make the G1 boot off the SD Card.. this may be a way to run a hacked rev 30 on a locked rev 30 phone...
I will try some stuff tonight...
-Nikropht
that does seem interesting... im going to try to flash JF's img after in finishes downloading... i'll post results... along with my attempt to flash a signed rc29 update... cross your fingers i dont brick the damned phone
The Artemis device had this so-called "Diagnostic SD" mentioned. Im asuming therefore we could dossibly create one and flash our device with whatever firmware, akin to the "Pandora Battery" for PSP.
Worth exploring, but difficult to pull of without bricking... If it is possibly to flash a signed RC30 at any point using the current SD method, then at least we know we cannot brick the phone
the SPL bootloader (engineering and original) look for NBH files on the SD card.
DREADIAG.nbh
and
DREAIMG.nbh
As you can see, their purpose is clear. One is for booting diagnostics and the other is for flashing the firmware.
^^^so are you saying flashing DREAIMG.nbh is possible with this method?
damien667 said:
the SPL bootloader (engineering and original) look for NBH files on the SD card.
DREADIAG.nbh
and
DREAIMG.nbh
As you can see, their purpose is clear. One is for booting diagnostics and the other is for flashing the firmware.
Click to expand...
Click to collapse
So could we create a dreadiag.nbh from RC29?
Yes indeedy. However, we don't know the format of said nbh files. We're working on it still.
richbayliss said:
The Artemis device had this so-called "Diagnostic SD" mentioned. Im asuming therefore we could dossibly create one and flash our device with whatever firmware, akin to the "Pandora Battery" for PSP.
Worth exploring, but difficult to pull of without bricking... If it is possibly to flash a signed RC30 at any point using the current SD method, then at least we know we cannot brick the phone
Click to expand...
Click to collapse
its possible to flash update.zip so we won't brick the phone... the issue is that each update checks for something on the one previously installed... like mentioned in one of my other posts its a endless loop... we can change whatit looks for but then loose the signature...
Can we not use the info here
http://wiki.xda-developers.com/index.php?pagename=Hermes_NBH
To go the other way!?
richbayliss said:
Can we not use the info here
http://wiki.xda-developers.com/index.php?pagename=Hermes_NBH
To go the other way!?
Click to expand...
Click to collapse
ok... HAs anyone tried to extract DREAIMG.NBH just to see how its formated or structured??? If so we could compare it to the data listed for the hermes nbh format just to compare differences(if any) to see how closely they match... just a thought
If I could get a copy of the file I would give it a whirl... but cannot find it anywhere.
Guys,
NBH files are a proprietary format. They are like the update.zip, but different. We don't know how, as this is embedded into the SPL code that is all in binary format at the time (it's not been disassembled). No one except HTC and/or T-Mo will have these original files anyway. This means we're going to have to build one from scratch with reverse engineering of the spl (at least that's what it looks like as of now). That being said, there is no NBH file that is "found" on any file system of the G1. The NBH file contains files within itself that are flashed onto the NAND flash of the phone, like update.zip. The difference is that NBH files are not signed (that we know of yet), and the format in which they have to be assembled.
richbayliss said:
If I could get a copy of the file I would give it a whirl... but cannot find it anywhere.
Click to expand...
Click to collapse
I cant find it either.... its out there though... too many people have posted their experiments with it... if any has it or know where it is is located please post... thank...
DREAIMG.nbh is nowhere. People are just creating empty files with that filename to see what the bootloader will do.
damien667 said:
DREAIMG.nbh is nowhere. People are just creating empty files with that filename to see what the bootloader will do.
Click to expand...
Click to collapse
Yup. Well to be correct there are probably true DREAIMG.NBH files somewhere out there (at a htc repair center most likely), but they have not yet made their way into the hands of the hacking community.
True.
I would rick messing if there was an update.zip of the OTA RC30 as is now. So I could rescue myself.
Looking at the WinMo phones, they have NBH for a few devices, and it is common for all of them to put the OS partition at header 0x0400, even on the latest Diamond device. So I would risk trying a file with this IF I knew I wouldnt be bricking for life.
richbayliss said:
True.
I would rick messing if there was an update.zip of the OTA RC30 as is now. So I could rescue myself.
Looking at the WinMo phones, they have NBH for a few devices, and it is common for all of them to put the OS partition at header 0x0400, even on the latest Diamond device. So I would risk trying a file with this IF I knew I wouldnt be bricking for life.
Click to expand...
Click to collapse
there is an official rc30 update.zip out... however it does not seem to alter the os... i re-flahed my rc30 with it and i didnt have to re log into google and nothing was missing... all of my text messages were even intact
When you flash with update.zip, it does not affect the data partition (where all your settings and installed apps are located). It only changes radio, system, and boot partitions.
formar of DREAIMG.nbh:
0x200 bytes header,
then N images one by one(radio, hboot, recovery, boot, splash, sysfs, userfs)
header:
000: 48 00 00 00 54 00 00 00 43 00 00 00 49 00 00 00 │H...T...C...I...
010: 4D 00 00 00 41 00 00 00 47 00 00 00 45 00 00 00 │M...A...G...E...
020: 44 52 45 41 31 30 30 30 30 00 00 00 00 00 00 00 │DREA10000.......
030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │................
seems like simple "magic"
+0x40: 32 DD's - IMHO type descriptor's (type of each image, 00 if not used)
+0xC0: 32 DD's - offset of images
+0x140: 32 DD's - size of each image
+0x1C0: version?
1C0: 31 31 31 31 31 31 31 31 00 00 00 00 00 00 00 00 │11111111........
1D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │................
1E0: 30 2E 30 35 2E 30 2E 30 00 00 00 00 00 00 00 00 │0.05.0.0........
1F0: 47 65 6E 65 72 69 63 00 00 00 00 00 00 00 00 00 │Generic.........
Booting from the SD card is probably how you enter the manufacturers test mode RE: FACTORY_TEST Run as a manufacturer test application, running as the root user. "android.permission.FACTORY_TEST"
http://code.google.com/android/reference/android/Manifest.permission.html
[TUT] Simple way to add Flash Disk (a.k.a "Internal Storage") to your own ROM
It's so long time, no one answer this question "How to add Flash Disk to own-cook ROM?", so I tried to find it out myself and I had found 2 different ways to do that.
As promised, or just a way to say thanks to all this community, I will share the way which more simple than the other.
It worked with Universal devices and may work with others, too!
* What you need?
1. Your ROM file (OS.nb, a.k.a nk.nba, nk.fat), different kitchens use different file names.
2. Any HEX editor, I use XVI32 here.
3. My Flash Disk image template.
* How it work?
The maximum size for a Universal OS ROM is 63 MB (66.060.288 Bytes), normally, we use less than this size for our ROM, the remain size is useless at all, so we make it useful by partitioning it.
* Which things to modify?
- Nothing in your SYS and/or OEM.
- boot.rgu in your XIP (only if it is not XIP-ready )
- First 512 Bytes of your ROM file (called Master Boot Record) (only if it is not MBR-ready )
- First 512 Bytes of my Flash Disk template file (called Boot Sector or Boot Record), it is a must edit thing to do (determine the size of Flash Disk)
* Here we go!
1. Download my file below, extract it and your nk.nbf into the same folder.
2. Run HTC64, decode your nk.nbf into two files (nk.prj and nk.fat).
3. Run HEX editor (XVI32), open nk.fat and write down two values (or just remember if you can) RED value (from $1E6 to $1E8 [or from $1F6 to $1F8 if they are not all 00]) and BLUE value (from $1EA to $1EB [or from $1FA to $1FB if they are not all 00]).
- Note: I use luca16thebig 1.4.9 BETA1 ROM for example, values may different from your ROM or this ROM after rebuilt.
00000000 ...
...
000001E0 41 88 04 FF 41 F7 80 88 01 00 80 6F 00 00 00 00
000001F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA
Click to expand...
Click to collapse
4. Close the file nk.fat and don't save if there is anything changed. Open VNIntFlashDisk.template (also in HEX editor).
Match two RED and BLUE values which you have writen down into two place RED (from $1C to $1E) and BLUE (from $13 to $14). Double check if the values are corrected and fixed into its places and save the template.
- Note: I have already done it with luca16thebig 1.4.9 BETA1 ROM's values, so just goto next step
00000000 ...
00000010 02 00 02 80 6F F8 0C 00 3F 00 FF 00 80 88 01 00
Click to expand...
Click to collapse
5. Run combine.bat from my package, your original ROM file will be saved as nk.fat.original. The file nk.fat now is Flash Disk ready!
6. Run HTC64, re-encode two files (nk.prj and nk.fat) into nk.nbf and we are done!
* What is RED and BLUE values mean?
All two values are in HEX and reversed order, in this example we have:
- RED value is 80 88 01, so its true value is 1.88.80h, change it into decimal number, we have 100.480. It is the number of used sectors (1 sector = 512 Bytes). And... luca16thebig 1.4.9 BETA1 ROM's original size is 51.445.760 Bytes = 100.480 sectors x 512 Bytes.
- BLUE value is 80 6F, its true value is 6F.80h, in decimal is 28.544. It is the number of free sectors, so our Flash Disk size is 28.544 sectors x 512 Bytes = 14.614.528 Bytes ~ 14 MB.
- As you known, OS ROM maximum size is 66.060.288 Bytes = 51.445.760 Bytes + 14.614.528 Bytes.
If your ROM is MBR-ready, each time you rebuilt the ROM, all two values will automatically adjusted in MBR and you just match these values into my Flash Disk template. That all!
- Note: luca16thebig 1.4.9 BETA1 ROM is XIP-ready and MBR-ready. So, if your ROM doesn't work with this instruction, post your 512 Bytes MBR and your boot.rgu file here. I will analyse and make instructions how to make them ready.
When I release this instruction, I tried to make all things clearly from basic to advance but it seem so hard to... eat! So, I did it in reversed order, let you can do it first, then explain and/or clarify. More details will be add later (only when someone needed)!
Link: VNIntFlashDisk.rar
Questions and answers
* What is XIP-ready?
- boot.rgu in your XIP already have Flash Disk related key and values, they are:
[HKEY_LOCAL_MACHINE\System\StorageManager\Profiles\TRUEFFS_DOC\FATFS]
"FormatTfat"=dword:1
"EnableWriteBack"=dword:1
"MountAsROM"=dword:0
"MountHidden"=dword:0
"Folder"="Flash Disk"
Click to expand...
Click to collapse
- Note: no space in key [HKEY_LOCAL_MACHINE\System\StorageManager\Profiles\TRUEFFS_DOC\FATFS], I don't know why there is a space before TRUEFFS_DOC, please manually delete that space when copy!
* What is MBR-ready?
MBR of your ROM already have Flash Disk partition, there are 4 partition slots in MBR.
00000000 ...
...
000001B0 __ __ __ __ __ __ __ __ __ __ __ __ __ __ 11 11
000001C0 11 11 11 11 11 11 11 11 11 11 11 11 11 11 22 22
000001D0 22 22 22 22 22 22 22 22 22 22 22 22 22 22 33 33
000001E0 33 33 33 33 33 33 33 33 33 33 33 33 33 33 44 44
000001F0 44 44 44 44 44 44 44 44 44 44 44 44 44 44 55 AA
Click to expand...
Click to collapse
- The last 2 bytes (55 AA) is a signature, it means END OF MBR.
- 5th byte of each slot is value for partition type, some mostly used values are:
+ 20 - BOOT: just a name, it isn't actually a boot partition and your MBR can be without it.
+ 23 - RAWFS: your XIP partition.
+ 25 - IMGFS: your SYS + OEM partition.
+ 00 - none: free slot, all value in this slot should be 00, too.
+ 01, 04, 06 - FATFS: our Flash Disk here! In some other devices, it's called "Internal Storage".
There are some other values but that's another matter!
So, if your MBR have a FATFS partition type in last used slot, you have a MBR-ready ROM.
- Two non-MBR-ready cases: (with and without BOOT partition slot)
00000000 ...
...
000001B0 __ __ __ __ __ __ __ __ __ __ __ __ __ __ 11 11
000001C0 11 11 20 11 11 11 11 11 11 11 11 11 11 11 22 22
000001D0 22 22 23 22 22 22 22 22 22 22 22 22 22 22 33 33
000001E0 33 33 25 33 33 33 33 33 33 33 33 33 33 33 00 00
000001F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA
Click to expand...
Click to collapse
00000000 ...
...
000001B0 __ __ __ __ __ __ __ __ __ __ __ __ __ __ 11 11
000001C0 11 11 23 11 11 11 11 11 11 11 11 11 11 11 22 22
000001D0 22 22 25 22 22 22 22 22 22 22 22 22 22 22 00 00
000001E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000001F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA
Click to expand...
Click to collapse
BLUE free slot must be entered manually (by HEX caculating) to make them MBR-ready! But... how to HEX caculate values? Maybe later with a MBR sample!
VNInt said:
It's so long time, no one answer this question "How to add Flash Disk to own-cook ROM?", so I tried to find it out myself and I had found 2 different ways to do that.
As promised, or just a way to say thanks to all this community, I will share the way which more simple than the other.
It worked with Universal devices and may work with others, too!
* What you need?
1. Your ROM file (OS.nb, a.k.a nk.nba, nk.fat), different kitchens use different file names.
2. Any HEX editor, I use XVI32 here.
3. My Flash Disk image template.
* How it work?
The maximum size for a Universal OS ROM is 63 MB (66.060.288 Bytes), normally, we use less than this size for our ROM, the remain size is useless at all, so we make it useful by partitioning it.
* Which things to modify?
- Nothing in your SYS and/or OEM.
- boot.rgu in your XIP (only if it is not XIP-ready )
- First 512 Bytes of your ROM file (called Master Boot Record) (only if it is not MBR-ready )
- First 512 Bytes of my Flash Disk template file (called Boot Sector or Boot Record), it is a must edit thing to do (determine the size of Flash Disk)
* Here we go!
1. Download my file below, extract it and your nk.nbf into the same folder.
2. Run HTC64, decode your nk.nbf into two files (nk.prj and nk.fat).
3. Run HEX editor (XVI32), open nk.fat and write down two values (or just remember if you can) RED value (from $1E6 to $1E8) and BLUE value (from $1EA to $1EB).
- Note: I use luca16thebig 1.4.9 BETA1 ROM for example, values may different from your ROM or this ROM after rebuilt.
4. Close the file nk.fat and don't save if there is anything changed. Open VNIntFlashDisk.template (also in HEX editor).
Match two RED and BLUE values which you have writen down into two place RED (from $1C to $1E) and BLUE (from $13 to $14). Double check if the values are corrected and fixed into its places and save the template.
- Note: I have already done it with luca16thebig 1.4.9 BETA1 ROM's values, so just goto next step
5. Run combine.bat from my package, your original ROM file will be saved as nk.fat.original. The file nk.fat now is Flash Disk ready!
6. Run HTC64, re-encode two files (nk.prj and nk.fat) into nk.nbf and we are done!
- Note: luca16thebig 1.4.9 BETA1 ROM is XIP-ready and MBR-ready. So, if your ROM doesn't work with this instruction, post your 512 Bytes MBR and your boot.rgu file here. I will analyse and make instructions how to make them ready.
More details will be add later (only when someone needed)
Link: VNIntFlashDisk.rar
Click to expand...
Click to collapse
Very Useful!!THX You!!Post More details,PLZ
very very good news thank you
WOW
guys it's just to hard to handle for me
I'll give it a try....thx for the info....
ps: VNInt, could you just add Luca's ROM with flash disk? that would be great....
Got me 13.90MB Flash disk!!!!...
Thanks VNInt.....
I can't download the file from www.4shared.com
who can apply another download link
thanks
VNInt said:
* Which things to modify?
- Nothing in your SYS and/or OEM.
- boot.rgu in your XIP (only if it is not XIP-ready )
- First 512 Bytes of your ROM file (called Master Boot Record) (only if it is not MBR-ready )
- First 512 Bytes of my Flash Disk template file (called Boot Sector or Boot Record), it is a must edit thing to do (determine the size of Flash Disk)
Click to expand...
Click to collapse
1st let me thank you for your post. it will be quite useful in the future.
2 questions just to clarify:
- how to find if rom is XIP ready or not?
- how to find if rom is MBR ready?
Maybe these are dumb questions, sory for that.
Cheers.
ultravox said:
- how to find if rom is XIP ready or not?
- how to find if rom is MBR ready?
Click to expand...
Click to collapse
Yeah! You asked must-answer questions!
When I release this instruction, I tried to make all things clearly from basic to advance but it seem so hard to... eat! So, I did it in reversed order, let you can do it first, then explain and/or clarify.
* XIP-ready: boot.rgu in your XIP already have Flash Disk related key and values, they are:
[HKEY_LOCAL_MACHINE\System\StorageManager\Profiles\TRUEFFS_DOC\FATFS]
"FormatTfat"=dword:1
"EnableWriteBack"=dword:1
"MountAsROM"=dword:0
"MountHidden"=dword:0
"Folder"="Flash Disk"
Click to expand...
Click to collapse
* MBR-ready: MBR of your ROM already have Flash Disk partition, there are 4 partition slots in MBR.
00000000 ...
...
000001B0 __ __ __ __ __ __ __ __ __ __ __ __ __ __ 11 11
000001C0 11 11 11 11 11 11 11 11 11 11 11 11 11 11 22 22
000001D0 22 22 22 22 22 22 22 22 22 22 22 22 22 22 33 33
000001E0 33 33 33 33 33 33 33 33 33 33 33 33 33 33 44 44
000001F0 44 44 44 44 44 44 44 44 44 44 44 44 44 44 55 AA
Click to expand...
Click to collapse
- The last 2 bytes (55 AA) is a signature, it means END OF MBR.
- 5th byte of each slot is value for partition type, some mostly used values are:
+ 20 - BOOT: just a name, it isn't actually a boot partition and your MBR can be without it.
+ 23 - RAWFS: your XIP partition.
+ 25 - IMGFS: your SYS + OEM partition.
+ 00 - none: free slot, all value in this slot should be 00, too.
+ 01, 04, 06 - FATFS: our Flash Disk here! In some other devices, it's called "Internal Storage".
There are some other values but that's another matter!
So, if your MBR have a FATFS partition type in last used slot, you have a MBR-ready ROM.
- Two non-MBR-ready cases: (with and without BOOT partition slot)
00000000 ...
...
000001B0 __ __ __ __ __ __ __ __ __ __ __ __ __ __ 11 11
000001C0 11 11 20 11 11 11 11 11 11 11 11 11 11 11 22 22
000001D0 22 22 23 22 22 22 22 22 22 22 22 22 22 22 33 33
000001E0 33 33 25 33 33 33 33 33 33 33 33 33 33 33 00 00
000001F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA
Click to expand...
Click to collapse
00000000 ...
...
000001B0 __ __ __ __ __ __ __ __ __ __ __ __ __ __ 11 11
000001C0 11 11 23 11 11 11 11 11 11 11 11 11 11 11 22 22
000001D0 22 22 25 22 22 22 22 22 22 22 22 22 22 22 00 00
000001E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000001F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA
Click to expand...
Click to collapse
BLUE free slot must be entered manually (by HEX caculating) to make them MBR-ready!
* Updated to second #2 post!
VNInt said:
* What is XIP-ready?
- boot.rgu in your XIP already have Flash Disk related key and values, they are:
- Note: no space in key [HKEY_LOCAL_MACHINE\System\StorageManager\Profiles\TRUEFFS_DOC\FATFS], I don't know why there is a space before TRUEFFS_DOC, please manually delete that space when copy!
* What is MBR-ready?
MBR of your ROM already have Flash Disk partition, there are 4 partition slots in MBR.
- The last 2 bytes (55 AA) is a signature, it means END OF MBR.
- 5th byte of each slot is value for partition type, some mostly used values are:
+ 20 - BOOT: just a name, it isn't actually a boot partition and your MBR can be without it.
+ 23 - RAWFS: your XIP partition.
+ 25 - IMGFS: your SYS + OEM partition.
+ 00 - none: free slot, all value in this slot should be 00, too.
+ 01, 04, 06 - FATFS: our Flash Disk here! In some other devices, it's called "Internal Storage".
There are some other values but that's another matter!
So, if your MBR have a FATFS partition type in last used slot, you have a MBR-ready ROM.
- Two non-MBR-ready cases: (with and without BOOT partition slot)
BLUE free slot must be entered manually (by HEX caculating) to make them MBR-ready! But... how to HEX caculate values? Maybe later with a MBR sample!
Click to expand...
Click to collapse
how to HEX caculate values?
yanqichun9527 said:
how to HEX caculate values?
Click to expand...
Click to collapse
Do not only ask, just follow my instruction, if it do not work for you or your MBR are not ready, post your 512 bytes MBR and your boot.rgu here!
I will use them as samples to continue.
Excellent tutorial VNint..Thanks!
VNInt said:
Do not only ask, just follow my instruction, if it do not work for you or your MBR are not ready, post your 512 bytes MBR and your boot.rgu here!
I will use them as samples to continue.
Click to expand...
Click to collapse
It's Ready I think.Just Want To Know Answer
yanqichun9527 said:
It's Ready I think.Just Want To Know Answer
Click to expand...
Click to collapse
OK! As we know, values are saved in reversed order and maximum size is 1.F8.00h sectors, in decimal is 129.024 sectors = 66.060.288 Bytes (1 sector = 512 Bytes).
From now, we work with HEX only.
* Some definitions:
1. Value from $1x6 (4 Bytes) (x is C, D, E or F) is address offset of partition's first sector a.k.a number of used sectors by all previous partitions.
2. Value from $1xA (4 Bytes) (x is C, D, E or F) is number of sectors in partition a.k.a size of partition.
* Some formularies:
number of used sectors = size of last partition + address offset of last partition
size of your partition = maximum size - number of used sectors
In your sample:
number of used sectors = 1.BA.00h + 1A.80h = 1.D4.80h
size of your partition = 1.F8.00h - 1.D4.80h = 80.23h
lol how about to remove them from roms?
mr4r4n said:
lol how about to remove them from roms?
Click to expand...
Click to collapse
So easy! Just zero-fill FATFS slot in your MBR!
Nice tutorial VNInt.
Sorry
I have stupid Question....
Can we have Internal Device Storage Memory more than usually?
For example, ROM from VNInt has Internal Memory ~41MB, Storage ~9.9MB & Flashdisk ~21MB. Can we combine all of the memory (internal,storage & flashdisk) to One Place memory, so we can have Internal memory 41 + 9.9 + 21 = ~73MB? ..
Sorry 4 my bad English & my stupid Question
aladin said:
Sorry
I have stupid Question....
Can we have Internal Device Storage Memory more than usually?
For example, ROM from VNInt has Internal Memory ~41MB, Storage ~9.9MB & Flashdisk ~21MB. Can we combine all of the memory (internal,storage & flashdisk) to One Place memory, so we can have Internal memory 41 + 9.9 + 21 = ~73MB? ..
Sorry 4 my bad English & my stupid Question
Click to expand...
Click to collapse
The answer is NO, but this is an exciting idea!
I will try some hack to get it true if it can be!
aladin said:
Sorry
I have stupid Question....
Can we have Internal Device Storage Memory more than usually?
For example, ROM from VNInt has Internal Memory ~41MB, Storage ~9.9MB & Flashdisk ~21MB. Can we combine all of the memory (internal,storage & flashdisk) to One Place memory, so we can have Internal memory 41 + 9.9 + 21 = ~73MB? ..
Sorry 4 my bad English & my stupid Question
Click to expand...
Click to collapse
My Stupid Question has answered... look at this
Code:
http://forum.xda-developers.com/showthread.php?t=468776
My Question Again. How to make it?
aladin said:
My Stupid Question has answered... look at this
Code:
http://forum.xda-developers.com/showthread.php?t=468776
My Question Again. How to make it?
Click to expand...
Click to collapse
* Yeah! He got it hacked!
* How it work? This trick is made by repartitioning DiskOnChip.
- This is original DOC layout: (mtty/task 28)
Binary0 Size: 0x100000
FAT0 Size: 0x4000000 (67108864 bytes = 64 MB) (63 MB maximum ROM and Flash Disk size + 1 MB splash image)
FAT1 Size: 0xA00000 (10485760 bytes = 10 MB Extended ROM size)
FAT2 Size: 0x2C70000 (46596096 bytes = 44 MB Storage size)
All Size: 0x7770000
FAT0_ADDR=0x100000,FAT1_ADDR=0x4100000,FAT2_ADDR=0x4B00000
- And this is modified DOC layout after Cotulla's ROM:
Binary0 Size: 0x100000
FAT0 Size: 0x2A00000 (44040192 bytes = 42 MB maximum ROM size)
FAT1 Size: 0x40000 (262144 bytes = 256 KB Extended ROM resized but hidden away)
FAT2 Size: 0x4C20000 (79822848 bytes = 76 MB Storage gained size)
All Size: 0x7760000
FAT0_ADDR=0x100000,FAT1_ADDR=0x2B00000,FAT2_ADDR=0x2B40000
* How to make it?
There is a DOC repartitioning tool released by mamaich before with his source code. I'm trying to got it work unattendedly, so hard now.
I have an Android device with a QComm SDM680 SOC. The QCom part# of the SOC is SM6225.
How do I find the "hw_soc_version" and "soc_version" of the SDM680/SM6225 ?
I've found some general scripts that collate this type of info, like this one. But the SDM680 is not in any of those lists.
I've searched on the rooted device, grepped the kernel logs and the kernel opensource. fastboot getvar all doesn't expose this info either.
Does anybody know how to find these values?
Oh, that's easy. You just run an EDL client, they always ask the HWID.
You don't even need to have a loader for it.
On my EDL client just:
Code:
C:\>edl /l
Found EDL 9008
Serial: 12345678
HWID: 000cc0e100000000, QC: 000cc0e1, OEM: 0000, Model: 0000
Hash: 7be49b72f9e43372-23ccb84d6eccca4e-61ce16e3602ac200-8cb18b75babe6d09
You can also attach a UART while booting.
Code:
Format: Log Type - Time(microsec) - Message - Optional Info
Log Type: B - Since Boot(Power On Reset), D - Delta, S - Statistic
S - QC_IMAGE_VERSION_STRING=BOOT.XF.1.4-00246-S660LZB-1
S - IMAGE_VARIANT_STRING=Sdm660LA
S - OEM_IMAGE_VERSION_STRING=cibuild
S - Boot Interface: Unknown
S - Secure Boot: Off
S - Boot Config @ 0x00786070 = 0x000001c1
S - JTAG ID @ 0x00786130 = 0x000cc0e1
Note that even though this is a SDM636 the log speaks of 660, but the "JTAG ID" is the correct HWID.
Usually the certs in xbl/abl has the HW_ID in it.
Also:
Code:
Teletex string 11 3007 0000 0000 0000 0000 0000 0000 0000 0000 0000 SOC_VERS
(I've never run into this soc_version before.)
Also, AFAIK, your friendly Firehose loader repository doesn't have a loader for this.
Edit: Oh, you're not looking for the HWID?
Renate said:
Oh, that's easy. You just run an EDL client, they always ask the HWID.
You don't even need to have a loader for it.
On my EDL client just:
Code:
C:\>edl /l
Found EDL 9008
Serial: 12345678
HWID: 000cc0e100000000, QC: 000cc0e1, OEM: 0000, Model: 0000
Hash: 7be49b72f9e43372-23ccb84d6eccca4e-61ce16e3602ac200-8cb18b75babe6d09
...
Edit: Oh, you're not looking for the HWID?
Click to expand...
Click to collapse
Thanks for the tip. I checked the SAHARA output. It seems that this HWID consists of the MSM_ID+OEM+MODEL. For the SDM680 I got: HW_ID: 0x001b80e100000000 (MSM_ID=0x001b80e1 OEM_ID=0x0000 MODEL_ID=0x0000).
Looking at bkerler's qualcomm_config.py, it seems that the hw_soc_version and hwid are two different things. For example for the SDM660, the msmid entry is 0x08C0E1, with a comment that the soc_hw_version is different:
Code:
0x08C0E1: "SDM660", # 0x30060000 soc_hw_version
Renate said:
Usually the certs in xbl/abl has the HW_ID in it.
Click to expand...
Click to collapse
Even though it's about the hwid, I looked into this too. It seems that around 2016, the HWID was stored in OU fields in the certificiates in the XBL file (see pages 10-11). But after 2019, it is now stored in the metadata of the MBN image (see page 9) within the XBL file. I only mention it because I thought it might prove useful for you.
Curiously, the HWID wasn't in the certs or metadata in my stock ROM's xbl.elf. Strange.
Yahoo Mike said:
For the SDM680 I got: HW_ID: 0x001b80e100000000...
Click to expand...
Click to collapse
The good news for you is that it's not stamped OEM/model.
There's some chance that this is not SecureBoot.
Which means that any loader that's compatible with your SoC will work.
What does this say: fastboot getvar secure
What does this say: cat /proc/cpuinfo (Just the name line.)
You can also look in the DTB, either decoded or raw, it's at the beginning.
Then there's the other wrinkle that Qualcomm has SDM numbers, MSM numbers and code names for SoCs.
Maybe that cpuinfo will tell you a codename.
Renate said:
The good news for you is that it's not stamped OEM/model.
There's some chance that this is not SecureBoot.
Which means that any loader that's compatible with your SoC will work.
What does this say: fastboot getvar secure
Click to expand...
Click to collapse
I think SecureBoot is on. I've had to do a test-points recovery a few times - after I tried to run with a patched (and incorrectly signed) ABL.
In fastbootd & bootloader menus, it says SecureBoot is on. And (as you suggested) fastboot utility agrees:
Code:
C:\>fastboot getvar secure
secure: yes
Finished. Total time: 0.001s
Renate said:
What does this say: cat /proc/cpuinfo (Just the name line.)
You can also look in the DTB, either decoded or raw, it's at the beginning.
Then there's the other wrinkle that Qualcomm has SDM numbers, MSM numbers and code names for SoCs.
Maybe that cpuinfo will tell you a codename.
Click to expand...
Click to collapse
The codename is khaje.
Code:
TB128FU:/ # cat /proc/cpuinfo
Processor : AArch64 Processor rev 4 (aarch64)
...<info about 8 processors>...
Hardware : Qualcomm Technologies, Inc KHAJE
That agrees with the run-time /sys/devices/soc0/soc_id value of 518, which is "khaje" according to the stock ROM's /vendor/bin/init.qti.display_boot.sh and /vendor/bin/init.qcom.post_boot.sh.
Curiously, at the beginning of the DTB it says it's "Bengal":
Code:
00 00 00 03 00 00 00 33 00 00 00 00 51 75 61 6C .......3....Qual
63 6F 6D 6D 20 54 65 63 68 6E 6F 6C 6F 67 69 65 comm Technologie
73 2C 20 49 6E 63 2E 20 42 65 6E 67 61 6C 20 31 s, Inc. Bengal 1
47 62 20 44 44 52 20 48 44 2B 20 53 6F 43 00 00 Gb DDR HD+ SoC..
But at offset 0x2A62D0 it changes its name:
Code:
00 00 00 00 00 03 00 00 00 26 00 00 00 00 51 75 .........&....Qu
61 6C 63 6F 6D 6D 20 54 65 63 68 6E 6F 6C 6F 67 alcomm Technolog
69 65 73 2C 20 49 6E 63 2E 20 4B 68 61 6A 65 20 ies, Inc. Khaje
53 6F 43 00 00 00 00 00 00 03 00 00 00 0B 00 00 SoC.............
I can't believe how many different numbers/strings QCom has to describe a SoC: soc_id, codename, hwid, msm_id ... and the ever-elusive hw_soc_version.
Anyway, I'll load up this SoC's firehose program to bkerler's edl. I'll slip in a question about how to query the hw_soc_version. I'll post back any reply.
Yahoo Mike said:
The codename is khaje.
Click to expand...
Click to collapse
Khajeh is a city in Iran: https://en.wikipedia.org/wiki/Khajeh,_Iran
Yahoo Mike said:
Curiously, at the beginning of the DTB it says...
Click to expand...
Click to collapse
That's because you are probably looking at multiple DTBs.
You can simply grep/scan for "Qualcomm Technologies".
I don't know why they do that.
The abl scans through them and find the one that best matches.
S/N: 0x7BD1BDD5
HW ID: 0x001B80E10015006D -> HUAWEI
HASH: 0xB25DECD85D217F5D9B53DC3C42EF7846DCEF59DD3E0AF4D12606199F5099FF23D73C3AFFBE5EFBF421A81A197E41FDF5
PBL : 0x00000000
HASH TYPE: SHA384
DEV HASH: 0x0000003AC0D4
CPU : Undefined CPU: 001B80E10015006D