TG01 ROM Building - Kitchen Released!

---

I haven't finished my kitchen (it doesn't work reliably at all) so I won't be posting it publicly (I'll be posting it when I get home today, if you know what you're doing, drop me a PM and I'll send you a beta version).

There are two batch scripts, "dump" and "build" (and "verify").

For "dump", you'll need to drop your TSW in \Base, and edit the set INPUT_FILE to reflect the name of your TSW.

From there, just run dump.bat.

You can then edit the OEM/SYS/XIP.

In theory, the MSXIPKernel and MSXIPKernelLTK from ROM\XIPDonor\xip.bin are combined with OEMXIPKernel, WinceNLS and LangDB are taken from ROM\XIPDevice\xip.bin. This does cause some odd errors because XIPPort isn't perfect. I'll try and write some code that dumps the XIP properly and merges the two. XIPPort is used because it builds a map.txt and ROMHDR.txt (these should be buildable with the tools I've got, but haven't finished them)

During the rebuild, both the XIP and SYS\OEM are relocated, based off ROMHDR and the .VM/.ROM, this and XIPPort aren't perfect. They cope with the stock ROM well, but less well with different XIPs/SYSs.

The Build.bat contains

set INPUT_FILE=
set OUTPUT_FILE=

INPUT_FILE is the name of the original TSW file (or whatever you want TGTool to build a new TSW from). It must be in \Base.
OUTPUT_FILE is the name of the output TSW. It will be placed in the root of the kithcen.

Verify.bat (along with the verify folder) are designed for distributing the ROM. Verify runs TGTool to check the tsw, and generates an MD5 for the TSW. Please distribute this with the ROM, so we don't end up with bad flashes.


You flash any ROMs built using this at your own risk.
TGTool is the (excellent) work of cedesmith. Without it, none of this is possible.
Don't use it if you don't know what you're doing.
Without Wen (from WMPU) I wouldn't have had a TG01 for testing, so this wouldn't have happened, and thanks to anyone who donated.

I'm going on holiday tomorrow, so I've uploaded the kitchen here. It may not work, things may go wrong, it's not my fault if they do etc. Download, and use only if you know what you're doing!

(Password is l3v5yTG01Kitchen)

Reserved...

Also reserved.

Thanks for this, it's nice to just see some progress.

i will have the uk rom with german lang? can i make this with the scripts and tools?? it´s only the langdb... to change... or???

ps. sorry for my englisch...


greetz

scoobydoo2k1

Thanks I3v5y!

Looking forward to this kitchen and a WM6.5.5 Rom. I don't need a clean WM6.5.0 Rom because that doesn't make my phone faster That's why I'm waiting for your Rom.


I also noticed, that you got a problem while flashing your TG01? The pictures shows NAND error.

Did you manage it to get the phone working again? Maybe with the short pin method?

Best regards,

DunkDream

It's look like the error which minhanh_tran got
http://forum.xda-developers.com/show...08&postcount=6

Originally Posted by DunkDream

Thanks I3v5y!

Looking forward to this kitchen and a WM6.5.5 Rom. I don't need a clean WM6.5.0 Rom because that doesn't make my phone faster That's why I'm waiting for your Rom.


I also noticed, that you got a problem while flashing your TG01? The pictures shows NAND error.

Did you manage it to get the phone working again? Maybe with the short pin method?

Best regards,

DunkDream

I had a NAND error too flashing a .enc with short pin method days ago, but I just restarted and the flashing worked again. I think it may happen when you don't have the bridge over the pins enought time after starting the device. But this can be another thing maybe.

Short pin vs SDDL+

---

I was wondering why everyone seems to use the short pin method and not SDDL+? I have used SDDL+ to flash different roms as long as tgtool came back with no errors. I have not had much success with an upgraded Windows Mobile 6.5.5 rom, probably because I have been using HTC kitchens. But I have always been able to recovere using the short pin method.
Should I stop using SDDL+ and switch to short pin?

SDDL+ is fine. Short pin method should only need to be used when you don't have access to SDDL or SDDL+.