Kitchen Questions

[beluczywo]

Enjoying playing with Helmi's 1.0.4 and building some OEM files (will post once debugged). Some questions on the whole thing:

1. How do you keep track at time of "BuildOS" so your ROM is not too big for "CreateROM"?
2. Most packages let their files dump into Windows -- why not map them with "initflashfiles.txt" to go into "Program Files"
3. Are the files compressed in the Windows directory -- if they were, would you be able to fit more into the Kitchen?
4. I have bootloader 1.02 -- is there a way to update it? Should I care?
5. Is the Extended_ROM good for anything? I understand how to unlock it, but can you use it to load programs as extra space or does it just hold the Verizon (vendor) customizations?
6. On the first run after the flash, should I let the customizations run or not? I've seen mixed opinions -- that the files are already built into the ROM and you should skip it, but I'm not sure.
7. When I install programs after the ROM flash and tell them to go to the SD card, why does my storage memory get used up anyway? I verified the files really are in the storage memory -- are there dlls going into the windows directory?
8. Since WM5 sees a Windows directory on the device and a Windows directory on an SD card as one big directory, does this confuse it's concept of memory usage?
9. Some CAB files show ARM720,SA1100, some just show ARM. I know this is XScale -- which ones work and which don't. Is there really a difference in the guts of an ARM vs ARM720 of the same program? They are the same size.
10. Anyone else's Apache ever get warm to the touch and go from 90% battery to 50% battery in minutes? Definitely a random short but very intermittent for me?
11. Can someone REALLY explain memory -- I've read all the fine manuals and they are about as clear as mud. My understanding is there is 128M onboard divided into 64M of true EEPROM (flash ROM) that limits the size of a Kitchen. The other 64M is "working memory" as is an additional 32 for a total of 96M out of which the 64 needs to clone itself at boot time. Thus on a full ROM, you're left with about 32M of usable space split between Program Memory and Storage Memory, right?
12. Any way to run a ROM Kitchen agains the CE5 emulator from Microsoft to test things before a flash? Where would you get the Hardware Description for the emulator?
13. Any quick "pull yourself by the bootstraps" tips for aspiring developers -- I'm a 20 year software engineer, but it's still tough trying to figure out which of the 20 different tools to use when -- I have all of the Visual C from Microsoft, the SDK's etc. How about a quickie broad-brush-stroke view of "start here", "package it there", "do this to emulate and debug", "make it hardware independent by doing this", "make it language independent by doing that".
14. Anyone know if SQLCE3 and SQLCE2 can peacefully coexist? I have a program that requires SQLCE2.

[gguruusa]

Originally Posted by beluczywo

Enjoying playing with Helmi's 1.0.4 and building some OEM files (will post once debugged). Some questions on the whole thing:

1. How do you keep track at time of "BuildOS" so your ROM is not too big for "CreateROM"?

You can't. You can approximate the size of the ROM by looking at the size of temp/dump. 91MB is about as full as you can get, and you likely won't get a working ROM with that much.

Originally Posted by beluczywo

2. Most packages let their files dump into Windows -- why not map them with "initflashfiles.txt" to go into "Program Files"

ROM files HAVE to be in /Windows to start. When you move them with initflashfiles, you start consuming Program memory (which, by moving things into ROM, is what we were trying to save)

Originally Posted by beluczywo

3. Are the files compressed in the Windows directory -- if they were, would you be able to fit more into the Kitchen?

yes, they're compressed - that's how you can fit 90MB of crap in a 64 MB container. Compressing files before putting them in the kitchen won't help and will likely consume additional resources unnecesarily.

Originally Posted by beluczywo

4. I have bootloader 1.02 -- is there a way to update it? Should I care?

You can install the BellMobility ?.04 bootloader, but no, there is no reason to do so. You won't gain anything.

Originally Posted by beluczywo

5. Is the Extended_ROM good for anything? I understand how to unlock it, but can you use it to load programs as extra space or does it just hold the Verizon (vendor) customizations?

With 1.0.4 kitchen ROMS, you should remove the vendor customizations from the extended rom. You can then use it for pretty much whatever you want, keeping in mind the locked/unlocked state. Because it survives MemClear, it has it's uses. Many people use it for additional customization.

Originally Posted by beluczywo

6. On the first run after the flash, should I let the customizations run or not? I've seen mixed opinions -- that the files are already built into the ROM and you should skip it, but I'm not sure.

You should erase your extended rom so there are no customizations to run. The customizations that you need have already been cooked into the CE ROM.

Originally Posted by beluczywo

7. When I install programs after the ROM flash and tell them to go to the SD card, why does my storage memory get used up anyway? I verified the files really are in the storage memory -- are there dlls going into the windows directory?

Not everything got stored to the SD card. Drivers, shortcuts, DLLs, some program items, etc might not be installed to the SD card. If you're really curious, the .cab determines where most files go.

Originally Posted by beluczywo

8. Since WM5 sees a Windows directory on the device and a Windows directory on an SD card as one big directory, does this confuse it's concept of memory usage?

No, because it's not really one big directory...it's just presented that way.

Originally Posted by beluczywo

9. Some CAB files show ARM720,SA1100, some just show ARM. I know this is XScale -- which ones work and which don't. Is there really a difference in the guts of an ARM vs ARM720 of the same program? They are the same size.

The processor type determines instruction set. Sometimes the features of a later processor aren't significantly different or aren't used by the application. Generally, the processor type specifies the minimum instruction set required for the application - your processor may contain a superset and therefore be acceptable.

Originally Posted by beluczywo

10. Anyone else's Apache ever get warm to the touch and go from 90% battery to 50% battery in minutes? Definitely a random short but very intermittent for me?

Warm to the touch is normal while charging, but shouldn't occur significantly while discharging. The perceived drop from 90% to 50% is not necessarily an issue - battery charge remaining is a gross estimate and can change wildly based on temperature, recent charge activity, and power drain (load). In a nutshell, battery life is really a measument of actual output voltage vs expected voltage. Since batteries are chemical cells, all those things which affect chemical reactions will affect your battery performance.

Originally Posted by beluczywo

11. Can someone REALLY explain memory -- I've read all the fine manuals and they are about as clear as mud. My understanding is there is 128M onboard divided into 64M of true EEPROM (flash ROM) that limits the size of a Kitchen. The other 64M is "working memory" as is an additional 32 for a total of 96M out of which the 64 needs to clone itself at boot time. Thus on a full ROM, you're left with about 32M of usable space split between Program Memory and Storage Memory, right?

There's 128 MB of flash - 64MB of ROM, 10 MB of extended ROM, 44MB of Storage memory. The rest goes to bootloaders and such.
There's 64MB of SDRAM - yields about 49 MB of Program memory beyond WM5 requirements.

[Kolano]

Originally Posted by beluczywo

10. Anyone else's Apache ever get warm to the touch and go from 90% battery to 50% battery in minutes? Definitely a random short but very intermittent for me?

Yes, used to happens all the time for me. Usually this is due to a program on the device or part of the device OS getting mucked up and using 100% CPU. I was never able to work out the specific circumstances in which it would occur for me, but it seemed to be due to using the phone in a low signal area (or more specifically between a low signal to no signal area).

The latest 1.0.x kitchens have generally been better regarding this for me.