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

[Larik]

Thanks Former!!!
I was wondering why did you change those flags by just removing leading 000. I can try to restore those flags myself and see if this solves my icon flickering problem.(though since i started using custom ROMs my A2DP problem still bugs me) I was using 16MB Pagepool. I will let you know.
Larik

[lllboredlll]

I'll have to look around tonight to pin point where I got it from.

Also need to test 21028 with your xip a little more. I ended up moving right onto the topaz dump with your 21028 xip. Pretty nice so far but ...... I dont know how much I'd prefer it over 21028. I'll get back to ya on my source though. I can assure you it was xda but what thread hahaha no tellin

[FormerPalmOS]

Originally Posted by Larik

Thanks Former!!!
I was wondering why did you change those flags by just removing leading 000. I can try to restore those flags myself and see if this solves my icon flickering problem.(though since i started using custom ROMs my A2DP problem still bugs me) I was using 16MB Pagepool. I will let you know.
Larik

Removing the leading zeros doesn't change the value. If you look at a stock boot.rgu you will see that the flags value appears three times under a [HKEY_LOCAL_MACHINE\Init\Bootvars] key. RGUComp processes the file top to bottom so only the last value sticks. But in the stock that last value is 5 - somehow I changed it to 3.

Also, you have to re-cook the XIP for this change to take effect. Just changing boot.rgu won't make it stick - with the exception being for programs that look at this during phase 2 boot or later. Anything in phase 1 boot that relies on this value has to get it from the compiled boot.hv in the XIP.

On your A2DP problem - I traded messages with another user in some thread to check and see if you find a file called atcmdint.dll in \Windows. After boot, a provxml copies a cooked in file named atcmdint_.dll to atcmdint.dll. This newly-copied file replaces the stock atcmdint.dll that is part of SYS. This file is the AT command interpreter specific to our BT hardware. If the wrong interpreter is used, there may be issues with the BT hardware. Not sure if this is your problem, but something else to check.

Provxmls won't run if their attributes aren't correct (must be hidden, system and read-only) or if they aren't listed in a manifest (.dsm file) somewhere. Some of the sources for the SYS are mucking with the attributes.

[jucytec]

Originally Posted by FormerPalmOS

Sorry - trade secret. J/K...

1) Removed encrypting filter settings (meaning 723fb954-d931-4348-b672-82a188e587b5.rgu and boot_ms.rgu are no longer required and have been removed)

2) Removed IRDA protocol stack since there is no IR device in the CDMA Touch Pro

3) Set the File System Replication Filter (fsreplxfilt) as follows:
...Set the DoImmaculate flag - causes the OID mapping cache to be flushed at boot - prevents leftover stale entries.
...Set the OID cache size to 4096 entries

4) Removed all references to the relfsd (Release File System) - this file system is for development and is not (as far as I know) used by the OS

5) Instantiated CacheFilt.dll in the filters section on the SDMemory and FLASHDRV profiles. The way it was instantiated in boot.rgu it was being over-ridden by profile-level filter entries. IMHO, the default boot.rgu is NOT using the file cache filter. I also added the LockIOBuffers key - per MS, this key is required if using the file cache filter with the file system replication filter.

6) Removed MSFlash and CD profiles from file system since these do not exist in CDMA Touch Pro

7) Removed spy file system. This appears to be a leftover simple sample file system that MS provides developers.

FLASHDRV profile FATFS
... Disabled Autoscan in flags key (flags key shoud be deprecated but I kept it for backwards compatibility)
... Disabled Autoscan via new WM6 key
... Changed DataCacheSize from 2048 sectors to system-managed. This is the directory meta-data. Since most of the files on your system are in IMGFS, this will basically result in Windows deciding how much directory meta-data to cache, which will usually be all of it unless you have a ton of stuff installed (vs. cooked in).
... Changed FatCacheSize from 512 sectors to system-managed. Same comments as above apply.
... Set transaction bitmap cache size to system-managed (which should be the default if this key isn't specified) - so this may not represent a change.
... Enabled pre-loading of the FAT and transaction bitmap caches at boot time (slows boot but speeds up initial performance, no long-lasting performance impact). Not sure if this change is worth keeping.

9) Removed HTC Filter (no idea what it does and all builds I've done have worked fine without it)

10) Moved lsfilter from XIP to IMGFS (lsfilter is part of the LockStream Digital Rights Management solution HTC is using).

Note - I discovered that the Flags key under HKLM\Init\Bootvars is different. Not sure why - I didn't intentionally change this. I don't know what this value does. I can upload a new version with this changed back and you can try it.

What Pagepool size are you using?

10.64

[FormerPalmOS]

Just posted a new version of 8 with the HKLM\Init\Bootvars flags fixed. Also removed the FatCacheWarm and BitmapCacheWarm keys. See if this makes any difference at all. Let me know what you find.

Also, check your OEM pack / kitchen - be sure the attributes are correct on all *.rgu, *.dsm and mxip*.* files (safest is to add a line to the kitchen batch command file to set these after BuildOS before imgfsfromdump.exe).

FPOS

[Larik]

Thanks Former!
Tried it with Scott's kitchen and still have those flickering icons. Everything is OK when I use his ROM.
Larik

[FormerPalmOS]

Wierd. Can you zip and upload the os.nb.payload that you cook with in his kitchen that doesn't have any issues? I'll check it out.

[Larik]

Sure! Thanks!!!
Larik

[FormerPalmOS]

OK - what you posted is "the usual" result from XIPPorterEx with the remove CacheFilt.dll and remove Mencfilt.dll checkbox enabled, plus the other usual modules removed. No other changes. In other words, it's a slightly size-reduced XIP but no tweaks. If the ONLY difference between a working ROM for you and non-working is this, then there is obviously some dependency.

I haven't cooked with 21028 yet. lllboredlll has and unless he hasn't bothered to report it, I don't think he's had the problem you are having. Which implies that the dependency could also involve the SYS build plus the XIP.

So anyone that's used this XIP - please report a) what SYS you cooked with (version AND source) and b) if it's working fine or if you are seeing strange issues.

I made exactly the same changes to 20771 and have been running for a week now with zero strangeness, nothing wierd.

One more question - are you using the default .VM and .SYS, or are you using the modified ones I included in the XIP .ZIP file? Where in the build process do you do G'Reloc.exe and what exactly is the command line? Have you dumped your ROM and looked at the virtual memory map (imgfstodump.exe creates memorymap.txt - can be useful to see if there is an overlap in any of your modules with the XIP module VM space. Just another thought. This feels like a filesystem bug though...

[lllboredlll]

all is good in the hood with your 21028 xip on my 21028 sys