CDMA Touch Pro XIPs 20764 20771 20954 21015 21018 21028 21032 21109

[scrosler]

Originally Posted by jakdillard

Encrpytion is removed because on some device like the mogul it would corrupt your storage card ... this practiced is just still used today .... the catch filter if you choose to keep it you can move it to imgfs .... most times something is removed to save space or move modules around to take advantage of free RAM that is out there or to gain space in imgfs there are plenty of modules in the OEMXIPKernal and MSXIPkernal that can be moved to imgfs or deleted completely the key is to trim XIP

Thanks JD. Quick question. I am still learning to master the kitchen. I have little to no exp with modifying the XIP portion as you just noted. Could you direct me to a good resource. Im not asking for you to explain just a thread or a resource that might be able to assist me in understanding this portion of the ROM better.

As aways thanks for your wisdom and willingness to share!

[gguruusa]

Originally Posted by FormerPalmOS

I've also cooked a ROM using Scott's simple kitchen (ver 1.0), with some changes as noted below. The ROM is Verizon look and feel but with 21109 sys files (see below) and a few other goodies Scott found. This ROM is working great for me - Scott's kitchen is good for quick cooking (I used Calku's kitchen to get some additional tools for XIP porting). I also used Calcu's sys files instead of Scott's (when I downloaded, Scott said he had a problem with his SYS - I assume he has since fixed this problem). If anyone would like the ROM, I just need a place to upload it.

Changes to Calku 21109 SYS files from his kitchen

1. Removed BTHID, WindowsLive packages
2. Removed scard.dll, winscard.dll (smart card support - NA on TP)
3. Removed ircomm.dll (no IR on TP)
4. Removed Calku's tweaks cab
5. Removed Calku's Welcomhead192.png, replaced with the one Scott used in VZNAV3.0 (no offense Calcu, just my preference)
6. Following .RGU files were missing the FF FE unicode tag at the start:
   Enterprise\fd7ec796-412f-4352-9a71-04da841dc265.rgu
   Phone\2a6583ff-6047-46cc-b9be-b7deca1152c3.rgu
   PhoneRedist\d9d7d86d-3f83-4289-bd32-aa1972a1447e.rgu
   Shell\1f1aca24-d942-464a-9281-10567741499c.rgu
7. Added WindowsUpdate package from Verizon stock ROM (though it
8. doesn't seem to be working - says it can't establish a connection with the server - not planning to debug.)

I also made some changes to Scott's SSK1.0 OEM directory:

1. Removed HTC_cm_guardian.exe from _operatorpkg
2. Removed JetCET5 and Opera cabs - left to user to install
3. Added touchscreen pre-calibration data to ffffffff-ffff-ffff-ffff-fffffff1.rgu in _scrosler, removed toucnscreen pressure tweak, some color tweaks, weather server override
4. Moved Gyrator, QuickGPS and GPS Tool links to utilities folder (no separate GPS folder - just a personal preference)

Changes to kitchen:

1. Changed default checked/unchecked options in option.xml files for faster cooking with my defaults
2. Moved temp file cleanup to first instead of last - allows post-cook XIP insertion and "playing around"

This list is an excellent example of why you guys need to move away from old bepe kitchens. Not one item would have been necessary for him to do to achieve his goal (except add his own oems, which would have been done automatically).

[FormerPalmOS]

Originally Posted by scrosler

DAMN! Encryption just ruined my day.

EDIT: Can you take the time to post a cab to default it OFF please? Or tell me where in the reg to look so I can cook it in.

EDIT2: Is this it:

[HKEY_LOCAL_MACHINE\System\StorageManager\Filters\E NCFilt]
"EncryptByDefault"=dword:0

The above might work, but to be absolutely sure, un-hide the control panel aplet (HKLM\ControlPanel\Encryption\Hide=0) then un-check it there. It will default to encrypted in my XIP, but you can add the above to your .rgu in _scrosler and that should over-ride the XIP. The SDMemory profile isn't loaded during boot - only after OS load - so you should be able to change settings for SDMemory without changing the XIP.

The kicker with encryption is how well it works. If you save stuff to your storage card via ActiveSync or via the WM6 device in any way, and encryption is enabled, it is encrypted using a unique key stored on your device and re-generated with every hard reset (or re-flash). If you use an external reader/writer to write to the card (I have a Micro-SD to SD adapter and use that to read-write stuff I don't want encrypted like cab files) then those remain unencrypted.

As for removing it, the way I am doing this requires moving each and every DLL module loaded in the XIP - you have to move each one to a new address. It's a somewhat manual process that takes time. Granted, just removing it (and the associated registry keys and re-compiling boot.v and re-building XIP and re-inserting it into os.payload.nb) doesn't involve re-allocating addresses - OK to just leave a gap. But removing it wouldn't make the XIP space any smaller - so you really wouldn't buy anything by removing it. This is my understanding - those with more XIP experience may disagree.

By all means feel free to use this in future kitchens - but make the above changes in the .rgu file in _scrosler (unhide the control panel aplet and default it to not encrypt) so folks can see the control panel aplet and check / uncheck it as they please. I've made the change to default to not encrypt by default in my local copy - if I do this again, I'll do it to default to no encryption.

[FormerPalmOS]

Originally Posted by gguruusa

This list is an excellent example of why you guys need to move away from old bepe kitchens. Not one item would have been necessary for him to do to achieve his goal (except add his own oems, which would have been done automatically).

Since your signature has PPCKitchen in it, is that what you would recommend? Anyone successfully cooked a ROM for a VERIZON Touch Pro with the PPC kitchen? I have to say that the bepe based kitchen and this whole process was not exactly easy, nor could I do exactly what I want, so something better would be welcome!!

[FormerPalmOS]

Originally Posted by Juggalo_X

it is a good idea to remove this from the xip. u know what would have been 789643298576329486523984% easier?

use those dlls in a OEMXIP Package rather then reinventing the wheel in putting them back into the xip. they are taken out to save space. that way if u need it u add it to the OEM XIP package... if you dont then you dont.

oh yah. patch the PP string in the payload, and no cert patch it. if your going to do the xip might as well patch it correctly so users can take full advantage of it.

You've built many more ROMs than me - so some additional explanation here would help. Here's my understanding - correct me where I'm wrong. My two goals for this XIP were to a) re-enable file filter cache and b) re-enable storage card encryption. For some reason (don't know - just going by MS suggestion), mencfilt.dll must load on every FAT file system or it won't work. I confirmed this by trial and (many) errors. That means it has to load in the XIP - can't load after boot. Same with cachefilt - it should be applied to the root filesystem and should therefore also be loaded in the XIP. The XIP modules must be individually located within the XIP address space, with a specific order for one particular module. The addresses for the module code, constants and data must all be allocated so there are no overlaps. Once complete, the whole thing is turned into one image and stored in the XIP section of the NAND. At boot this is copied into RAM and executed. It proceeds to load the actual OS.

So I don't know what an OEMXIP is - unless you are referring to the OEM modules which are device-specific (I extracted these from the verizon Stock ROM XIP dump) and are combined with the new 21109 MS modules which are not device-specific - the sum of the two is the device-specific XIP. But regardless of where the mencfilt.dll and cachefilt.dll are placed (OEM or MS) the module memory allocation process and XIP image building, etc. must still be done.

Now if there is an easier way to do this (can't imagine a much harder way), then I'm all ears!

On the no cert patch and pagepool patch - the pagepool patch as-is would enable the pagepool changer to work (probably) - I didn't try it that way, preferred my way (though at 4am maybe not for any good reason). No idea what the no cert patch is for - I didn't do it and haven't run into anything I can't do as a result. What is the patch, what does it do? (Yes I know I could search the threads but as it stands I don't have a need for this and will therefore not take the time to do so until said need arises).

Thank you.

[FormerPalmOS]

Originally Posted by scrosler

I had no issues changint he PP from 12 to 9. What are you two talking about? I dont get it? Or did you fix the XIP and re-up?

With my XIP, unless you a) ran the pagepool patcher first then b) ran the pagepool changer, the change didn't actually do anything. The pagepoolchanger will actually report that it did change things, but the code in NK.EXE AS-IS will over-write that with 12MB. Here's why. The pagepool changer changes the default value saved in the parameter block of NK.EXE. The pagepool patcher changes the code in NK.EXE (I assume) so it can't overwrite that default value. So in theory, the sequence of patch --> pagepool changer should work. I just changed it in the code as I described above since at 4am that seemed a more logical way to do it. It's still easy to change, just not quite as automated as the pagepool changer ap.

[FormerPalmOS]

Originally Posted by jakdillard

Encrpytion is removed because on some device like the mogul it would corrupt your storage card ... this practiced is just still used today .... the catch filter if you choose to keep it you can move it to imgfs .... most times something is removed to save space or move modules around to take advantage of free RAM that is out there or to gain space in imgfs there are plenty of modules in the OEMXIPKernal and MSXIPkernal that can be moved to imgfs or deleted completely the key is to trim XIP

OK - you've got me intrigued. I assume that reducing the size of XIP would save RAM, and us Verizon folks need all we can get. But the whole XIP image is ~3MB - how much could we really save?

What modules in particular are not needed at early boot and can be moved out of XIP?

I did try loading mencfilt only on the SD card FATFS and it didn't work. According to MS it has to load on every FATFS volume. SInce the first FATFS volume loaded is the root on FLASHDRV, I assumed it had to load at that time. What I didn't try was loading it in the same manner in the registry, but not in boot.hv - loading it instead in the normal registry. If that worked it would remove it from XIP. Anyone out there with a ROM without working encryption and without this new XIP want to try an experiment and report back? If it can indeed be made to work and not be part of XIP, I'll re-cook a new one without it.

[kyppcgeek]

OK! So.... I'm not going to start a p#@$s'n war here, but YES... I have successfully cooked a PPCGEEKS Kitchen (Herman). It works just fine.

[kyppcgeek]

You and Scott need to work with GGURU to port the New XIP and sorts over to the PPCKitchen BuildOS if it has not been done so already.

The new kitchen is much much easier to manipulate files and upgrade your phone.

[FormerPalmOS]

Originally Posted by kyppcgeek

OK! So.... I'm not going to start a p#@$s'n war here, but YES... I have successfully cooked a PPCGEEKS Kitchen (Herman). It works just fine.

No doubts on the kitchen - just on if the OEMs and carrier files and the way they were split out from their original sources all work on a Verizon Touch Pro. First few kitchen attempts that worked on the Sprint Touch Pros didn't work so well on the Verizon ones for some reason.

Easier way to manipulate files? All I need to hear - sign me up to give PPCGeeks kitchen a spin - just not as the 1st guinea pig. Need the phone for my day job so "playtime" can't last more than a few hours at a time. Long plane flights excluded...