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

[jakdillard]

actually calcu and i are not beefing at least i hope not if yyou pay attention to his post you will see that I thanked him for what he posted i was just joking with him in my post honestly seriously folks lets lighten up and keep this on topic i as well as calcu are in here to help we are not at war

[scrosler]

Originally Posted by jakdillard

actually calcu and i are not beefing at least i hope not if yyou pay attention to his post you will see that I thanked him for what he posted i was just joking with him in my post honestly seriously folks lets lighten up and keep this on topic i as well as calcu are in here to help we are not at war

Thanks for the clarification!!!

Last time I listen to bored! (J/K)


I'll kick back and go into learning mode. Thanks alot!

[gguruusa]

Originally Posted by scrosler

Would you like to help me undertand the PPC Kitchen better?

Anytime.

Lighten up, !!!bored!!!. I was merely poking fun at scrosler for using a double negative.

--------------------

Rearranging segments to remove gaps doesn't actually give you any memory back. You are rearranging the segments within an allocated pool, so it's shrinking the pool that actually reclaims the space.

yes, xip contents are aligned on boundaries. Can't recall what it is off the top of my head...you can probably deduce it from xipports map file, though. Pretty sizeable alignment boundaries, as I recall.

[gguruusa]

Originally Posted by lllboredlll

I know I just wasn't gonna involve your name. I would of loved to been able to use that thread as a resource but had to go to god ol' xda for my answers. Seems to be against the law around here to have those kind of discussions and tutorials.

Fayfay not only stated the process was his, but he got it wrong at the same time. So yeah, we pretty much try to discourage things like that.

There are plenty of tutorials and discussions here, not the least of which are correct xip porting tutorials.

[FormerPalmOS]

Originally Posted by gguruusa

Rearranging segments to remove gaps doesn't actually give you any memory back. You are rearranging the segments within an allocated pool, so it's shrinking the pool that actually reclaims the space.

yes, xip contents are aligned on boundaries. Can't recall what it is off the top of my head...you can probably deduce it from xipports map file, though. Pretty sizeable alignment boundaries, as I recall.

Have started to figure this out. Said boundary for TP is a full track of 64 sectors of 2048 bytes each (0x20000 bytes). I'm working on an XIP now that shrinks by a full track, and gives that back as free RAM (changes to ROM header, changes to partition table, changes to MSFLSH50, changes to os.nb.payload template, etc. Will post once I cook and get it to boot (hopefully) - but not tonight. Only scrosler can cook with no sleep...

Spreadsheet sandbox attached that has what I've been working on for the partition table and MSFLSH50 table, with my current sizes, etc. Also my map.txt and ROMHDR.TXT - JD - feel free to comment if you think I did this right (haven't tried to boot this yet).

[scrosler]

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

I realized that this was in boot.rgu! DOPE! Stupid me! Changed it there and received the results I desired.

[FormerPalmOS]

EDIT: Nevermind. I managed to unbrick it but I did shoot some whiskey in memory of... Well you get the idea. I'm back now. Turns out it IS ok to muck with the partition table but only if you make sure that when you make a last minute change to the partition table you also update the MSFLSH50 region in your donor os.nb.payload. Took a while to figure this out, including a flash back to stock.

[FormerPalmOS]

Some good progress to report. Hope to have a new os.nb.payload uploaded tomorrow.

Here's what I've learned and some files for example.

First, due to the way offsets work in the ARM instruction set, and due to the way the flash operates, for most addresses there are page size boundaries that must be enforced or bad things will happen. For RAM offsets, this number appears to be 14 bits (in other words, the lower 14 bits of a RAM offset must be zero) - example, start of RAM for nk.exe, start of free RAM (ulRAMFree). This RAM can start at 0x8034C000 but not at 0x8034B000. For For partitions (in os.nb.payload), the number is 17 bits. This corresponds to a virtual track (64 virtual heads). Thus the IMGFS address in the os.nb.payload can start at 0x300000 but not at 0x2F0000.

In the XIP RAM, DLL offsets (and virtual base offsets) can start at 12-bit addresses (for example 0x01FCA000 but not at 0x1FC9F00).

All other addresses must be on a long-word boundary (e.g. last digit in an address is 0, 4, 8 or C - can't be anything else).

So, taking a look at map.txt and what I've changed. These changes are relative to the "floating around out there" 20954-based XIP that Scott (scrosler) uses in his ROMs. This XIP has mencfilt and cachefilt removed, plus a bunch of other useless stuff removed. However it wastes a lot of RAM. I've managed to add back in these modules and still recover 1.5M.

1) First DLL address changed from 0x1F801FC to 0x1FC01FC. This number MUST end with 01FC and the upper 16 bits of the address must end with 0, 4, 8 or C (thus 0x1FC01FC is OK, but 0x1FC71FC is not). The 01FC part is used for something - not sure what, but it don't work if you change this. Moving this from 0x1F801FC to 0x1FC01FC buys a bit more "breathing" room for allocating SYS modules into virtual memory, but only if you also change the ROM imageingo.txt and run G'Reloc.exe on the SYS directory. More on that later. Might result in a marginal (few tens of K bytes) increase in program RAM. Note - last DLL address must be for busenum.dll and must end at 0x02000000 (dlllast in ROMHDR.TXT - don't change).

2) First XIP DLL virtual base increased to 0x03DC000 to align with start of wce_rex.dll entry point. This number can overlap exactly with the e32_entryrva address in your SYS .VM imageinfo.txt. Last DLL must again be busenum.dll and it must end at 0x04000000. Again, this frees up some virtual memory space for SYS modules. No increase in free RAM.

3) Looking at the physical map (starting with 0x80000000) you can see there are very few empty spaces (those that exist do so because the next module must start at a page address. With the removed modules (I moved wince_nls to SYS - it is not required at early boot), the physical memory required for the XIP code and data ends at 0x802d6CFA. I set the Phylast address in the ROMHDR.TXT equal to the next page offset -1 (0x802D7FFF). There is some growing room in this XIP, but not much. This allows me to relocate the NK.EXE data segment (and the start of XIP RAM) to 0x802D8000. The end of XIP ram is 0x8034B000 but again it must end at a 14-bit offset (0x8034C000 in this case). By changing the ROMHDR.TXT ulRAMStart and ulRAMFree values, a significant chunk of program memory is recovered.

Now - you need to make similar changes to the ROM .VM file and the numbers plugged into G'Reloc.exe in order to actually use this space. So in summary, here are the changes using the numbers before and after:

What Before After
ROMHDR.TXT dllfirst 0x01F801FC 0x01FC01FC (below + 0x000001FC)
G'Reloc.exe VM Slot 0 0x01F80000 0x01FC0000
SYS .ROM imageinfo.txt e32_stackmax 0x01F80000 0x01FC0000 (same as above)
SYS .VM imageinfo.txt e32_entryrva 0x03D70000 0x03DC0000 (same as below)
G'Reloc.exe VM Slot 1 0x03D70000 0x03DC0000
ROMHDR.TXT physlast 0x803CF9BC 0x802D7FFF (below -1)
M'Reloc_nk.exe RAM o32_realaddr 0x803D0000 0x802D8000
ROMHDR.TXT ulRAMStart 0x803D0000 0x802D8000 (same as above)
NK.EXE imageinfo.txt o32[1].o32_realaddr 0x803D0000 0x802D80000 (same as above)
NK.EXE imageinfo.txt o32[2].o32_realaddr 0x803D6000 0x802DE0000 (above plus 0x00006000 )
ROMHDR.TXT ulRAMFree 0x80448000 0x8034C000

If anyone can squeeze any more space out of this, feel free, but I think this is it without removing additional modules. If I get motivated, I may do one without mencfilt and recover that memory as well.

[FormerPalmOS]

New version uploaded - see first post.

[FormerPalmOS]

Post a response if you are interested in a version of this XIP with mencfilt.dll removed. This will break storage card encryption for every ROM built using said XIP, and it may or may not be faster (won't be slower). And I may or may not be able to recover some additional RAM (wouldn't be more than a few hundred K). The alternative is to keep it as-is, with encryption defaulted to off - that way you can use it if you later decide you want to. I'm not noticing any performance impacts even with encryption enabled, but I haven't spent much time baselining it either.

EDIT - looked into this a bit further and there isn't much to be gained by removing it. ~64K of virtual memory space (only if you change .VM and .ROM in SYS and re-G'Reloc) and from none to a few tens of K of real RAM, depending on how modules fall. From a performance perspective, the encrypting filter isn't even applied to the IMGFS or NAND FAT file system - only to the SD Card. So you might get a small performance boost reading from SD, and a slightly larger boost writing to SD. Might...

So I'm not going to spend time on a encryption-removed XIP.