yashsingh1/xdaforums huggingface dataset:
[MDA III, XDA III, PDA2k, 9090 Software Upgrading] helmi_c:
Re: Way to go helmi

oops... fixed... thanks thingonaspring... hopes we can be more active on this thingonaspring... :wink:

its still early stage, we need more people involved, but maybe with thingonaspring here (I believe he ready to put some nice stuff here), midget, blackspz, logout, tautara, xplode , everyone who willing to work as a team, for me its doesnt matter who build/make the rom, I believe we just want a ROM that we can use right? so working together on the fix / update issues would produce a "Best" or "less bug" rom, plus with ability to customizing it for personal use. well, at least that my intention. hopes we all can work together.
[MDA III, XDA III, PDA2k, 9090 Software Upgrading] helmi_c:
this is exactly what I want.. people share their stuff.. and make our BA more rich with feature/option on spesific stuff... yes u might modify anything if u thing necessary (as long u didnt delete it ...lol) and inform about the update, so others know about it.

hmm... maybe that could happen, but I beleive if we make it together? maybe it'll slow a bit, but more bug will be fix/resolve, share experience, it doesnt matter about who makes the rom. well, we'll see about this proggress...
[MDA III, XDA III, PDA2k, 9090 Software Upgrading] Brazilian Joe:
About ROM Kitchen and 'the One ROM'

The ROM Kitchen is a wonderful idea.

IMO, things should walk towards stabilizing a base ROM with all features working (including WModem ;) ).

But we also shouldn't leave to the users the effort to create their own ROMs, that's too troublesome.

Maybe all devs could get closer together and agree on some tools to integrate to it, and call it the 'XDA ROM', instead of Bepe, Helmi, TuMa or whatever.

So, we could have a 'BASE ROM', meant to be used on the ROM Kitchen, and the XDA ROM supported by all devs, built from the BASE ROM with tools which were agreed to be useful, so the less geeky can have a nice working ROM to update their BAs with. With things like PHM regedit, ability to choose between BT stacks, GB Soft Tweak and other useful stuff.

That does not stop the devs from having their own name branded ROMs placed on the site...
[MDA III, XDA III, PDA2k, 9090 Software Upgrading] fraser:
Agreed, a base ROM system is the best of both worlds. Say I was to pickup a base ROM and build on it, is there anything I can do that can't be done using ExtROM installers? Sure, you get to put stuff in the ROM, but it's already stuffed full it would seem!

I remember reading about an anti-theft application that you could put in the ROM. If the phone number changed, it would start sending you text messages telling you about the current owner/thief. Is this an option for the BA once we get a kitchen?
[MDA III, XDA III, PDA2k, 9090 Software Upgrading] xplode:
I will test it tonight after work, , i will test my latest SAP package and maybe if it works OK i will post it in this thread

i still have to dump some devices roms to see what can i get from them, at this moment i have new versions of CommManager and WlanMgr and maybe fix for wifi integration, but first should test it...

Once again i want to thank everyone involved in WM5 development for BA

It will be a very long list .. so i will mention just a few names:

mamaich, bepe, helmi, logout, tuatara, Midget_1990 and many more
[MDA III, XDA III, PDA2k, 9090 Software Upgrading] Brazilian Joe:
Right way to roll in UPXed system apps?

OK, I have just decompressed all files, but I have no OEM packages rolled int yet.

I have tested many UPXed system dlls and exes, and I would like to roll them in to save space, in place of the original ones.

Where do I put them?
[MDA III, XDA III, PDA2k, 9090 Software Upgrading] tmoore:
Attempted to build a base rom from the files provided and i am getting an error after clicking on CreateOS. The error is "Error: OS\2849e391-1e39-4a98-87b9-53932dec51d3 is not listed in packages.sof". How do you add or remove packages listed in the sof file or is that possible? How can i remedy this error?

Thanks in advance
[MDA III, XDA III, PDA2k, 9090 Software Upgrading] xplode:
i have 3 errors for 3 folders in os folder, i just moved them into oem folder

more results soon
[MDA III, XDA III, PDA2k, 9090 Software Upgrading] Brazilian Joe:
I had the 3 errors too, and moved the files to OEM. The ROM image was built (apparently) was successfully built.

BUT, the million dollar question is:

How much free space do we have without adding any OEM stuff at all (a BARE ROM)?

We need to know our KB budget to know how much we can roll in...
[MDA III, XDA III, PDA2k, 9090 Software Upgrading] Marx2:
I have the same error. What did you move exactly?

OK i have it.

It's:

2849e391-1e39-4a98-87b9-53932dec51d3

e3055288-19cd-4317-9125-a63654628fb3

fb30fdba-23d9-4a92-af78-041b1ee1d46c
[MDA III, XDA III, PDA2k, 9090 Software Upgrading] tmoore:
Move them from the OS directory to the OEM directory
[MDA III, XDA III, PDA2k, 9090 Software Upgrading] Brazilian Joe:
When you get the error, move the folder with that name to OEM.

Another subject:

Hey all,

I have unpacked the ROM (nk.nba), replaced all folders ending with .exe and .dll with the actual file contained in each, and UPXed all exes and dlls.

Suspicious files are automatically skipped by UPX, and I compressed them with 'upx -i --compress-exports=0 --compress-resources=0 --strip-relocs=0', because when I was testing compressing (Office) with the default options, it didn't work. All compressible files worked, with these options.

The 'dump' contents went from 52,3 MB to 30,6 MB.

The catch: I don't know if the nk.nba generated from them will work ;)

I haven't tried repacking it into an nba and flashing a ROM. Does anyone want to experiment with this file?

EDIT:

After BuildImgfs.exe finished, it reported the following:

Total Sectors: d2a8

Used Sectors : b984

Free Sectors : 1924

In decimal: 53928,47492,6436.

How big is a IMGFS sector? 512bytes? 1KB? more?

/EDIT
[MDA III, XDA III, PDA2k, 9090 Software Upgrading] Marx2:
i did it with a few files

simply deleted them and created OEM package with UPXed versions

My Himalaya is flashing now AKU 3.2!

It flashed ok, hovewer entering BT settings hangs device :(

I will wait for Bepe

EDIT: BT stack is my fault cause by UPXing it
[MDA III, XDA III, PDA2k, 9090 Software Upgrading] a771la:
i create my rom ... very fast :D

but when i turn off my 9090 , it don't turn on ( display is balack) :evil:

any solution?
[MDA III, XDA III, PDA2k, 9090 Software Upgrading] cugarwang:
hi,

how to build a SD-Card Images?
[MDA III, XDA III, PDA2k, 9090 Software Upgrading] xplode:
I do not know what causes it but every rom i cook has the same problem with resuming from standby, the touchscreen and backlight are working after resume, but lcd does not...

does anyone have idea how to fix this
[MDA III, XDA III, PDA2k, 9090 Software Upgrading] Black6spdZ:
yes.. I know there was a problem originally with the aku3 release from bepe way back, I used the 2.3 drivers in its place and that solved the resume problem.

BTW, does anyone remember the online XDA ROM kitchen? That was a piece of work for sure.. just selected the main OS version you wanted and you got the option to select the options you wanted along with carrier settings, themes, etc.. it had a running bar at the top to show you how much rom space you have left.. it then built the rom and you downloaded it ready to flash
[MDA III, XDA III, PDA2k, 9090 Software Upgrading] egzthunder1:
Hell Yeah, I remember it! If it wasn't for LumpiStefan and that kitchen, my Wallaby would be a paperweight right now. I guess it would be nice if we could have something like that for the BA's. However, I do agree with some of you how said that we need a more stable version of the OS before releasing a Kitched into the open public. If the OS has major bugs, this forum will be flooded with questions from people in no time (even though we have a Wiki :wink: )

Helmi, I will keep on testing your betas until we reach a good and stable rom. Let me refrase that, until we find the rom that is closest to perfection (you are getting there 8) ). Once that goal is reached, I guess we can openly tell everyone... "here is the kitchen. Go crazy"

All in all, I love this place!!!!!
[MDA III, XDA III, PDA2k, 9090 Software Upgrading] Marx2:
You CAN delete registry from OEM package. Bepe has written about it somewhere on the buzzdev.net in ROM kitchen thread. It's something like setting "-" as value of registry key

What can't be done and it's serious is inability to move files via initflashes file - you can only copy them to different place.

Installing many OEM packages resulting in having all of them in /windows directory and there is risk that some files will have the same name (simply example: readme.txt or licence.txt file, but more serius would be dll with the same name)

About UPX, i have noted that BT stack shouldn't be UPX, also many CPL doesn't like to be UPXed (I have written above about BT problems - it's fault of UPXing BT stack, not AKU3.2 itself)

Brazilian Joe: to recount numbers reported by createrom.bat simply convert from hex to decimal and divide by 2

Is seems that after UPX you have only 3MB free. I have in Himalaya much more, because I can for example put there NetCF2 which is more then 4MB,a nd many other apps

One more thing - how can I copy files from ROM? in ROM kitchen each files is made off few files, so I can't UPX them - I need completed files
[MDA III, XDA III, PDA2k, 9090 Software Upgrading] thingonaspring:
Welcome back tuatara

Glad to see you back, and best wishes for your family's speedy recovery.

UPX - Your comments on this make a ton of sense. I think we should all note that unless a DLL/EXE is really big (like ppt.exe 2mb or minimo.exe 7mb) then it should not be UPXed, but trusted to IMGFS compression instead.

Registry pruning - This definitely needs doing. The boot registry in particular includes a ton of power management entries that are not suited to that part of the registry and work perfectly well from an OS level package. Also, the relfsd entries seem to be a legacy from WM2003. Removing them has no ill effect.

Likewise there are plenty of instances of strange and scattered entries in the OS and LOC packages that need to be moved/removed. In particular I'm thinking that filesystem-related sections should only appear in the boot registry. At present there are some instances of FATFS cache sizes being set in OS packages for instance.
[MDA III, XDA III, PDA2k, 9090 Software Upgrading] fraser:
Can you mark the UPX files as uncompressible in some way, so that the IMGFS doesn't compress it? Or is IMGFS a filesystem level system?

The reason I ask is that compressing something twice is generally counter-productive. You never gain anything from the second pass other than increased decompression time.
[MDA III, XDA III, PDA2k, 9090 Software Upgrading] Marx2:
You are right with UPX

Brazilian Joe UPXed all system gaining about 22 MB, but after cooking he had only 3MB free
[MDA III, XDA III, PDA2k, 9090 Software Upgrading] Brazilian Joe:
Yeah, that might have been a ton of wasted work... but I am learning, and I believe others are learning with it too.

I will not even flash this ROM, at least yet. I will do another compression test, picking only big files.

There are some files which, despite being core system components, make sense to be compressed. like GWES.exe for example.

You always have a single instance of it, and if it crashes, so goes your system. It's always running. UPX cut its size by 50% (not counting IMGFS difference).

If there is a way to mark files as not compressed by IMGFS, that would help indeed, having UPXed files not be (de)compressed twice would make accessing them faster.
[MDA III, XDA III, PDA2k, 9090 Software Upgrading] fraser:
Would that impact system ram? If the original ROM application was execute-in-place (or whatever it's called), then the compressed one needs to be loaded into RAM and executed from there. Normally it would just run straight from the ROM i.e. the app is never actually loaded, it just runs.

I may be wrong on this as I think I read somewhere that the /storage filesystem is not compatible with the execute in place stuff/
[MDA III, XDA III, PDA2k, 9090 Software Upgrading] thingonaspring:
The 3 OS packages that require moving to OEM dir

Hi Guys,

Has anyone looked at what's inside the 3 offending OS Packages that need to be moved into the OEM folder prior to creating OS?

It turns out that the following :-

e3055288-19cd-4317-9125-a63654628fb3

fb30fdba-23d9-4a92-af78-041b1ee1d46c

In fact contain nothing but a DSM file. As the DSM files are generated by createOS from the contents of the folder, in this case nothing, it's fairly obvious these 2 should be deleted.

The remaining one

2849e391-1e39-4a98-87b9-53932dec51d3

Is a bunch of reg entries adding filetype support for jpg, gif, png, midi etc and should be retained.
[MDA III, XDA III, PDA2k, 9090 Software Upgrading] Marx2:
it's called XIP (execute in place) and it depends on flash memory type (not all flash memory types allows for XIP).

We should check how much memory usage will grow after UPXing system.
[MDA III, XDA III, PDA2k, 9090 Software Upgrading] Brazilian Joe:
I may be wrong, but I believe devices designed for WM5 use nand, which is not XIP capable, whereas BAs use NOR, which is XIP capable.

AFAIK, the hardware should be capable of XIP, but the FS driver would have to support it. would the binaries have to be compiled in a special way to support XIP? If that's the case, there will probably be no XIP for us...
[MDA III, XDA III, PDA2k, 9090 Software Upgrading] fraser:
Probably not, it'll be the OS that's loading them into RAM and running them. Might be a setting somewhere on the phone, but xip doesn't appear to be mentioned in the registry. Maybe someone with a debugger could determine where the program code is being exectuted from? But yeah, it's likely that the BA isn't using XIP anywhere, at least under WM5. Shame, XIP is a really useful idea; solid-state storage is going to be huge in desktops in 3-8 years IMHO.
[MDA III, XDA III, PDA2k, 9090 Software Upgrading] thingonaspring:
XIP is mentioned in the registry (ROM\boot.rgu) :-

[HKEY_LOCAL_MACHINE\System\StorageManager\Profiles\MSFlash\IMGFS]

"XIP"=dword:1

and later in the same file :-

[HKEY_LOCAL_MACHINE\System\StorageManager\Profiles\MSFlash\IMGFS]

"XIP"=dword:0

See what I mean about cleaning up clag in the registry files?

Also, if you view IMGFS.dll (in the boot XIP section) in a hex editor, it includes the string "XIP" (unicode) alongside its other registry settings "ShadowROM", and "Folder". I'd really like to know how shadowrom can be made to work. That would be really something.

At present I think the rom builds with IMGFS XIP set to 0 as that's the last instance of that value in the file.
[MDA III, XDA III, PDA2k, 9090 Software Upgrading] Brazilian Joe:
What is ShadowROM supposed to do?
[MDA III, XDA III, PDA2k, 9090 Software Upgrading] thingonaspring:
Shadowing ROM copies the contents of ROM to RAM and relocates all references to that location. So instead of every image, exe and dll coming from NOR flash over an 8-bit bus, it comes from 100mhz ram over a 32-bit bus. If you're the overclocking type, it would be even faster with RAM set to 133mhz.

Sadly I can find no way of making it work. In particular I can find no setting that would dictate the address to shadow to.
[MDA III, XDA III, PDA2k, 9090 Software Upgrading] helmi_c:
hey, nice to see u here tautara... btw me personally dont use bepe's way, I more prefer the old way...but this kitchen is just for let everyone to talk to each other, since we all the developer dont talk to each other, i dont know why..lol... but i hope we cant share usefull thing here.

I cant agree with u more... yes we are learning all the time... and thats why we talk to each other, maybe other hv a better experience on this, so it'll safe a lot of time.
[MDA III, XDA III, PDA2k, 9090 Software Upgrading] helmi_c:
Re: The 3 OS packages that require moving to OEM dir

maybe u should edit or even add new file to the kitchen? and maybe version numberin is necessary/ready now?

Btw once again, everyone can modify anything if they thing necessary, there's no dictatorship here, feel free, we all hv the same right in here...everyone hv right to modify everything if needed, but please inform to others so we know about the difference/change/updates and I'll update the first page, plus the name who made/update it.
[MDA III, XDA III, PDA2k, 9090 Software Upgrading] helmi_c:
my rom only hv this problem/limitation (other is just some file missing when i build them...lol):

1. Wifi not fully integrated with CommManager (turn on first with Wlan manager an ur ready to on/off with CommManager) when first AKU come out, i've manage to work this, with wizard driver combine to turn on wifi on boot time, and turn it off with small app (4kb). but is there other way to do this?

2. WModem did work on BA in any WM5.

3. If i use ace_ddi as display driver Landscape mode is perfect, but no gif display in PIE, but if I use ddi_d3d driver? the landscape is crap.

other then that? I dont thing there's any issues on my rom, or let say its easy to fix it, any help on this is very usefull...
[MDA III, XDA III, PDA2k, 9090 Software Upgrading] Brazilian Joe:
I have been browsing around msdn, and looks like the arcane 'windows ce platform builder', which is a package used by the OEMs to customize CE has a key role in defining XIP regions in the ROM. I don't know if our ROMs still preserve a 'skeleton' of the original 2003 ROMs, but if that is the case, it may be that our WM5 are XIP capable. On the other hand, it may also happen that having used a WM5 ROM made for a NAND-based device left us out of OS XIPability... Of course, I may have misunderstood and be wrong in my conclusions...

Turns out the CE Platform builder, at some point, build a .bin rom image. Only, I don't know whether it directly relates to our .bin files, which are result of splitting nk.nba, or they are something else which are further processed until they become a flashable ROM image.

From this link, you can navigate the labyrinth of MSDN looking for more CE-XIP stuff:

http://msdn.microsoft.com/library/d...howHowToCreateImageWithMultipleXIPRegions.asp

EDIT:

Also, according to MSDN, XIP execution is slower than RAM execution, which impacts performance.

EDIT
[MDA III, XDA III, PDA2k, 9090 Software Upgrading] helmi_c:
hmm... maybe ur bt driver is to old? what bt file on the Hima dev? btw try to add this bt driver to dump folder and rebuilt them. maybe it'll work, maybe it wont, just try it.

EDIT: The attachment is not needed, Marx2 u should edit ur post if the problem is in ur upx BT drivers files, not in the AKU3.2 itself. Its missleading to the reader... :wink:
[MDA III, XDA III, PDA2k, 9090 Software Upgrading] xplode:
I have built about 10 aku 3.2 roms , and in everyone i still get the resume bug ...

i have changed drivers but it gets worst ...

can anyone help me out ?
[MDA III, XDA III, PDA2k, 9090 Software Upgrading] a771la:
i use 2.3's drivers.... and it work :)

but it's slow :( and backligth regulation don't work

which is the driver that cause this bug?
[MDA III, XDA III, PDA2k, 9090 Software Upgrading] thingonaspring:
@helmi

Yep, I hear ya. Talking about it gets us so far, but posting updates is what its all about.

I'm keeping a full changelog of everything I do to the base packages so we can retrace our steps if stuff goes wrong.

Will hopefully post something useful tonight or tomorrow.
[MDA III, XDA III, PDA2k, 9090 Software Upgrading] Marx2:
Hello

Removing Office is quite simple and gives me about 5MB of space. Does anybody knows how to remove MSN messenger?

I'm testing Himalaya with AKU 3.2 and have noticed that:

-Modem link doesn't work

-Camera can't be assigned to a button

-Camera works quite fast even in full screen mode

-BT works ok

I will try to upload my OEM packages because they all work ok

EDIT

I've just uploaded them here

ftp://xdaupload@ftp.xda-developers.com/Himalaya/OEM_packages_by_Marx
[MDA III, XDA III, PDA2k, 9090 Software Upgrading] a771la:
ahioem.dll :evil: :twisted:

this is the problem

i solved import aku 2 version of it :)
[MDA III, XDA III, PDA2k, 9090 Software Upgrading] helmi_c:
I've upload Broadcom BA BT Stack v1.7.1.3400 OEM Pack, if u plan to us it for Himalaya or other device some modification is needed. check the :

[HKEY_LOCAL_MACHINE\SOFTWARE\WIDCOMM\BTConfig\SerialTransport]
"StopBits"=dword:00000000
"Port"=dword:00000004
"Parity"=dword:00000000
"FlowControl"=dword:00000001
"ByteSize"=dword:00000008

btw for rom with plenty off space u might build a rom with both BT stack available on ROM with CAB/APP to switch between them.

ftp://xda:xda@xda-developers.com/Up.../BA_BroadcomBT_v1.7.1.3400_OEM_Helmi_Test.rar

btw for info about the test progress/usability/limitation go here:

http://xdaforums.com/viewtopic.php?t=59639
[MDA III, XDA III, PDA2k, 9090 Software Upgrading] Tuatara:
Yes, that's correct. The problem is identifying the registry elements to delete ... if you don't know what was in the base ROM and/or a package is made and then used in subsequent versions, it can get quite difficult to manage removal of elements. If there is some 'legacy' BT registry entries in the base ROM, then any BT update would need to know which ones to delete and/or if it should, and ... well ... you get the picture. :-)

This could be solved by expanding the toolkit to do some more "sanity checking" on the final results. Right now we're depending a lot on the ROM builders to manage ALL interdependancies and ensure no conflicts. That'll then make it 'easy' for anyone to build their own ROM ... right now, a fair amount of care is still needed.
[MDA III, XDA III, PDA2k, 9090 Software Upgrading] Tuatara:
The simple answer is - it makes no difference even if it was marked. The marking itself requires the same space as marking the sector uncompressed. The same 'one bit' overhead is required.

When a block is uncompressible, the encoding for that block in IMGFS is similarly marked that way - after it was attempted to be compressed (during ROM creation). There is NO cost when actively running - other than the RAM buffers required for 'expansion/copy'.

UPX'd data sectors which are uncompressible are functionally LARGER than 512 bytes, (by the one bit to signal uncompressed sector) because the IMGFS filesystem must add the 'this is uncompressed data' flag. The advantage is that the uncompressible data is compressed 'better' than IMGFS could have done it - thus the space saving anyways.

I'd be VERY surprised if IMGFS would even be able to compress a UPX'd file to any degree. It's like trying to ZIP a RAR file ... good luck getting even 1% out of that ... the entropy of the data is just far too high for any useful compression to be possible.

Tuatara's Razor: "Any given file can be made one bit smaller. Apply recursion."