Related
I'd like to toss this out for discussion. This might already exist, it might not.
Microsoft had system builders use a Disk Differencing technique to extract what exactly had changed after installing applications and customizations.
First, we'd install the OS and create a base image.
Second, we'd install the apps & customizations we wanted for our customers.
Third, we'd create another image. An app would then compare these two images and determine what files were added/changed and what registry additions, deletions, alterations were performed.
I'm hoping we can do the same for ROM upgrades.
1. OLD ROM - Base image.
2. Install apps and customizations - Image "Apps". This will give us our customizations.
3. Install new ROM - NEW base image created. Compare to OLD ROM base image to see what has changed (that we need to look out for that our APPs image might adversly change).
4. Apply Apps image to restore all customizations & applications.
Ideas anyone?
The theory sounds good.
Maybe buzz can comment?
The theory is very feasable, ive used similar building Win PE rescue disks, you have a app that gives you the base bootable image made from a Win XP install CD. then you add home made "modules" ie, your installed apps or networking capabilities etc. then it makes an image for you to use,
that cant really be that difficult to do the same for Win CE,
Ive also seen a M$ webcast thing where the guy took 45 mins to build an entire image for a win ce device,
so yer, it is very feasible that such dev apps exist, after all, they were made and then sold to the hardware vendors before ever being a rom image.
check in msdn for win ce 5 stuff, its a very intresting read, :shock:
it is a good idea, but only for linear ROMs, where each file has always it's own and same place in the rom and such rom is not compressed.
hmm...
but you can do partial rom upgrades with wm5 roms...
...and it would be possible to make registry diff + DOC Storage partition backup, where you actually install programs (so called \Device) and userdata.
buzz
buzz_lightyear said:
it is a good idea, but only for linear ROMs, where each file has always it's own and same place in the rom and such rom is not compressed.
hmm...
but you can do partial rom upgrades with wm5 roms...
...and it would be possible to make registry diff + DOC Storage partition backup, where you actually install programs (so called \Device) and userdata.
buzz
Click to expand...
Click to collapse
Ok...Since I'm not a programmer and somewhat of a noob with respect to WinCE, I am NOT constrained by what might be a logical limitation to a programmer or someone in the "know". So, below is my thinking ... outside of the box (er, PDA) style.
But first, I need to grasp further Buzz's post above about the locations of things in ROM. Does this mean that there isn't, for lack of a better example, a FAT for the ROM? That every individual thing is expected to be at some specific, static location that can't change? If so, I see your point. But that tells the system that this location is static? Also, doesn't that make bug fixes difficult as the fix might exceed the designated space in ROM? Or do bug fixes always get re-applied after each reset? Patching in memory is how I'm looking at this. (Remember, I'm a non-programmer...deal with me, please.) LOL
Ok..out of the box time.
1. Can a shim be used to capture calls to a certain location in the ROM and redirect to another location (within the ROM or even the storage card. Linux builds anyone?). Like what HD disk managers did to get around LBA limitations or even boot sector viruses did.
2. Can an emulator be used to simulate/backup/build/test the ROMs on a PC before wiping the PDA? Don't laugh, but if not, could something be done with Virtual PC? Oh..Ok, laugh.
(Should I go hide somewhere?)
ULDR
“ULDR” stands for “Update Loader”, and is part of the Image Update system. This system allows deployed devices to be updated with new software after they ship. The Update Loader reads a configuration stored in persistent memory and downloads and installs new versions of operating system or OEM files
IPL
Initial program load - usually paired with Secondary Program Load (SPL), is the boot loader of your phone, much like the BIOS is the boot loader for your PC. Note: IPL/SPL are highly hardware dependent, flashing the wrong IPL/SPL is much more serious than a flashing the wrong ROM. It may be noted that, sometimes a ROM package also contains the IPL/SPL which will be flashed into your phone. Hence be extra careful what you are flashing. Note: although a ROM may also contains the IPL/SPL, `ROM` usually refers just to the OS (eg. the Windows Mobile 5, not the IPL/SPL) and the ExtRom
SPL
Refer to IPL
XIP
(eXecute In Place) is a useful option available with uClinux systems. Its main value lies in providing a means of allowing several copies of a program to be running without duplicating the text segment. Indeed the text segment can reside in flash memory and need not be copied to the system Ram at all. This is useful for tasks that have large program bodies with many executable instances running in the system.
Only the Stack, BSS and data segments of an executable needs to be produced for each running program. The text segment can then reside in flash memory or, if execution speed is an issue, then copy the file system to ram first and mount it from there. If executables in the file system are compiled to support XIP and also flagged in their headers as XIP they will load and execute with just a single copy of the text segment
SYS
HardSPL
SoftSPL
sunny_ag said:
ULDR
XIP
SYS
HardSPL
SoftSPL
Thanks.
Click to expand...
Click to collapse
i double that or at least updating the wiki will be appreciated:
http://wiki.xda-developers.com/index.php?pagename=FAQ
can someone explain me the rest...
sunny_ag said:
can someone explain me the rest...
Click to expand...
Click to collapse
Ameet has updates Post #1 with most of them.
Have a look at the SPL Questions wiki page for the difference in Hard / Soft SPL.
SYS (IIRC) is the folders from a dumped ROM that contain all of the files / configurations for the Windows Mobile OS components. Have a look at the cooking sections of the wiki for more info.
Ta
Dave
DaveShaw said:
Armeet has updates Post #1 with most of them
Click to expand...
Click to collapse
Dave, not you too brother Its Ameet
Hey sunny, moved this thread to dev & hacking since it may attract more customers here than the device specific section
ababrekar said:
Dave, not you too brother Its Ameet
Hey sunny, moved this thread to dev & hacking since it may attract more customers here than the device specific section
Click to expand...
Click to collapse
Very sorry my friend, I have updated my post.
I see words and read what I want, rather than what it says.
Dave
Hi!
So what it's all about?
There are so many projects dedicated to porting linux to WM devices.
Mostly the only way to boot into linux and kick windows mobile out of RAM is the haret tool.
For thoose who never heard of it is a linux bootloader (it is even more), that is started from within windows mobile.
This is the result of the fact that the native bootcode of the device could not easily be replaced.
Apart from that, there are to many things to consider to rewrite own bootcode for a closed device.
So what if the native bootcode "thinks" it boots in windows mobile again, but it in fact jumps into linux kernel code?
Whaaat, you might think and i thought a lot of it in the last few weeks:
The idea is, to embed a linux kernel in a XIP container and boot it with the native bootloader
So that's crazy stuff and it's even more crazy, that some insane hackers already did some successful attempts.
The project aims to port Android to a device called Meizu M8.
Step into this thread and start reading:
http://www.meizume.com/modding-development/9014-project-port-android-meizu-m8-18.html
One of the developers already has started to push some GIT-repos of the toolset here:
http://gitorious.com/~banxian
Of course there's a lot to investigate and other things to consider:
1. The injected code must be in good shape (kernel needs excellent hardware support)
2. The device will need to be hard-SPLed (no security check)
3. The files must match the Flash layout of the bootcode
4. JTAG support for the device would be mandatory for testing
5. Lots of information about internal Flash structure is required
....
Please tell me what you think about it!
Cheers,
scholbert
That's an excellent idea!
Multiboot would seem to be a better (albeit more complicated) alternative to me though... In their current stage, Linux ports to WM devices tend to be unstable and rather limited in functionality. Replacing a fully functional WM with a semi-functional Android on one's primary device is not as tempting as having both at the same time.
I'd say the first step in this direction is bootstrapping custom XIP from RAM with a patched SPL. Flashing XIP nbX every time custom XIP is patched is slow and tedious. Once a working XIP with booting Linux kernel is available, it should be relatively easy to switch SPL back to normal booting from NAND. Also ULDR XIP can be used as a container for the custom XIP rather than the WM kernel XIP. This way one can boot WM by default and then reboot to ULDR/Linux if required (not quite multiboot, but something close).
The caveat here is that when HaRet is used to boot Linux kernel from under WM, some hardware init could have been carried out by WM kernel at boot time. When WM kernel/XIP was never ran, there's a good chance some of the hardware that works when booting Linux via HaRet won't work anymore Completely bypassing WM kernel initialization means more initialization may have to be done in Linux kernel/custom XIP.
The progress that Meizu people made is certainly impressive, but there's a long way from a 100-byte piece of code that fills the framebuffer to a fully working Linux kernel. I'm not being sceptical here, on contrary I'm pretty sure this is possible, but it will take a lot of time and dedication to make this happen. At any rate, good luck and I'm sure you'll find plenty of support here.
This project, is cool, i am waiting any progress, i want put the android in the MS20(Brazillian KS20 without wifi and 3G)
Hi again,
thanks for the feedback so far
@ stepw:
I really share your thoughts concerning long and dusty road of development.
So perhaps i was in kind of euphoria when i decided to post it yesterday.
Anyway, let's see what the future will bring us
Maybe we should start with some kind of ramloader and place it in XIP area.
BTW, could you be more specific about this ULDR XIP thing?
Sounds interesting and to be honest, never heard of it...
Please consider the thread as a starting point for an open discussion.
Anyway, i will need help, because i'm a horrible hacker.
So maybe i should have written IDEA not PRJ
Have a nice day!
scholbert
As per http://channel9.msdn.com/wiki/CEDeveloper/BSP/
ULDR and IPL
For BSPs that are for Windows Mobile products, the ULDR and IPL are required parts of the BSP.
“ULDR” stands for “Update Loader”, and is part of the Image Update system. This system allows deployed devices to be updated with new software after they ship. The Update Loader reads a configuration stored in persistent memory and downloads and installs new versions of operating system or OEM files.
“IPL” stands for “Initial Program Loader”. This piece of code is launched by the bootloader or executed directly at startup if a bootloader has been removed from a board. The sole job of this program is to choose whether to execute the ULDR software, or load and execute the operating system that is currently on the device. If a user has downloaded new versions of operating system or OEM files, the IPL will be configured to launch the ULDR. Otherwise, it will load and launch the OS.
===
Da_G's thread http://forum.xda-developers.com/showthread.php?t=520009 has plenty of information about ULDR, although it's more about keeping it rather than about using it for something else.
Replacing ULDR is a valid way to inject another item into NAND partition table. Unfortunately with WM all 4 primary partitions are used in the MBR by default, so taking ULDR out allows for reuse of one of the parition slots for other purposes. IPL already has a way to bootstrap either ULDR or OEM XIP (WM kernel), it should be possible to control boot partition selection from each of the OSes. Manipulating partition type and flags should make it possible to choose the default OS too.
ULDR partition is typically fairly small, but it can be expanded to store Linux ramfs image or even the filesystem. Alternatively, FATFS partition in NAND could be mounted at boot and filesystem image could be located there. Yet another location for it is IMGFS partition, but that calls for a file system driver (read-only at least) that I don't think exists for Linux. Anyway, if at least FATFS can be mounted, access to all user files accessible from WM should also be possible from Linux/Android once it's booted.
Sorry for deviating from the original topic
Hey stepw!
Sorry for deviating from the original topic
Click to expand...
Click to collapse
Hey we got an open discussion here...
Thanks for all this useful information so far!!
I knew about starting up WM platform and i also looked deeper into IPL and stuff. What i am missing a little is just these information about XIP and WM image in general.
So i think i'll first step through Da_G'S thread, it looks very promising. Great stuff!
Again leave your technical comments here, because i think it's the only way to get best solution
Best regards,
scholbert
Hi,
I've been working on this for a few days now and have a simple bootloader that loads and runs a kernel on my vogue. Unfortunately the kernel doesn't boot properly because it can't initialise all the hardware correctly but it definitely runs. Attached is my code and a script to insert it into an xip payload with a kernel.
Woooow.....
Hey dzo,
this is a real breakthrough or whatever you may call it.
Really great stuff!
Maybe this won't reach peoples interest right now,
but let me forecast, that someday this will give us the opportunity
to wipe out windows mobile completely if we like to
Anyway i think it would be nice to get some stuff pointed out more clearly.
So let me sum up:
1. Let's assume we got excellent kernel zImage to support the hardware of our device.
We will need to initialize even parts of hardware in this kernel,
that we did not even know about, while testing with haret.
2. We need some hard-SPL bootcode on our device, because we need to avoid security check of the image.
3. We got WM ROM for our device and we got some kitchen to extract it and work with it.
The starting point will be the file OS.nb.payload, because this is pure binary.
(the image like it is stored in NAND flash memory).
The image (OS.nb.payload) itself is organized in different parts and partitions.
At the moment we don't care much about it, because we leave it mainly untouched.
We need to find the entry point from the WM kernel, which is pure XIP code (XIP.bin).
4. We inject a tiny loader for elf binaries at this point, which is also compiled as XIP code (tinboot).
5. We step a bit further and place the kernel zImage (which is an elf file) at a certain offset.
At least this should be the address the tiny loader points at (e.g. offset + 0x8000).
6. We use some kitchen tools to reconstruct a flashable image.
7. We flash this image to our platform, using the same tools we use to flash a cooked ROM.
8. We boot into linux!
Please correct me if i forgot something or made a wrong assumption here.
Would be really nice to get some more hackers and ROM cookers over here to benefit the discussion.
Thanks again dzo!
Best regards,
scholbert
Hi again!
A little research at the forum gives some more details about OS.nb.payload:
http://forum.xda-developers.com/showthread.php?t=446506
This maybe all well known, but should help to point at it again for a better understanding.
So if we use mtty and type the info 8 command on HTC loaders this prints out these partitions (should be all the same on HTC devices):
Partition[0], type=0x20, start=..., total=... BOOT (ULDR)
Partition[1], type=0x23, start=..., total=... RAWFS (XIP)
Partition[2], type=0x25, start=..., total=... IMGFS (SYSTEM)
Partition[2], type=0x04, start=..., total=... FATFS
TBC
scholbert
dzo said:
Hi,
I've been working on this for a few days now and have a simple bootloader that loads and runs a kernel on my vogue. Unfortunately the kernel doesn't boot properly because it can't initialise all the hardware correctly but it definitely runs. Attached is my code and a script to insert it into an xip payload with a kernel.
Click to expand...
Click to collapse
That's some excellent progress! Did you build your kernel yourself too? Is it mission critical hardware that fails initalization or some minor stuff?
SuperJustKitchen v0.9 Released.
Go to my site: http://justkitchen.info to get the updates and the info. It takes to long to update every device's forum that is supported, and I plan to support all devices, eventually.
Word of warning:
Not all EXT's have been tested or modified for the every device. Please test test and test and then let me know which packages don't work and what YOU've done to fix them. (I don't have time to fix ALL of them by myself.) Some packages will only be compatible with some devices.
(I'm no longer updating each thread separately for each device but just updating my site and posting the release info here. I will only update each thread to say that a new version is out.)
**Warning**
Before using this kitchen, you MUST read the whole thread. Any questions that have been answered will be ignored. This is your only warning.
**Disclaimer**
I am not responsible for any damage that may be done to your phone with a ROM created in this kitchen.
I am not responsible for any damage done to your computer.
I am not responsible for anything... at all.
Introducing SuperJustKitchen!
SuperJustKitchen is based on [http://forum.xda-developers.com/member.php?u=843218"]airxtreme[/URL]'s osKitchen Zero. All credit on for the kitchen backend goes to him.
Features
A completely stripped ROM. (Work in progress for some devices.)
LZX and XPR compression (Also option for No compression.)
Auto clean files that are language specific or DPI specific that your ROM does not need
Auto port missing language MUI files
Automatic rec'loc'ing for devices without native 6.5 nk's
6.1 and 6.5 support
Auto XIP and SYS porting
Auto NBH packing
Tool to convert OEM packages to EXT packages
Auto file conflict fix (don't have to removing older file that conflict (not that there are any. )
Save custom ROM settings (for cooks for multiple ROMs)
Cook multiple languages at the same time with the same ROM settings (Have to add language support yourself. I removed the required MUI's a while back because they made updating the kitchen and adding devices a nightmare.)
MUCH better organization of EXT packages
Active development instead of a program that is no longer being developed
Cleaner and easier to use interface
A built-in and customizable Tutorial section
And more!
Builds included
21056 - WM6.1
23658 - WM6.5 with new redesigned GUI
At the moment, this is an ENGLISH (WWE) only kitchen. This might change...
NOTE: In order for me to keep track of whether my time was well spent or wasted, if you use this kitchen to make a ROM, please either include SJK in the name or just mention that it was SJK cooked in your ROM's thread.
NOTE: This kitchen assumes that you know how to flash through SD, recover from a bad flash and are able to backtrack your steps to figure out how you broke your own ROM. If you do not understand these, please learn them first. Do not PM me asking me. I have written numerous walkthroughs on all these except on how to backtrack your steps. For that, just remember what you're doing as you do it and keep backups.
If you find any issues, PLEASE report them to the bug tracker in my website. It will help me make this kitchen better!
ENJOY!!!
thanks i will try....
oh!!!!! it takes a long time as Compaed to earvius kitchen.....also i am not able to flash .nbh file it stops at 1% in ruu and then device restarts.......
Not working
indresh88 said:
oh!!!!! it takes a long time as Compaed to earvius kitchen.....also i am not able to flash .nbh file it stops at 1% in ruu and then device restarts.......
Click to expand...
Click to collapse
same here...the final ROM when flashed says image corrupt
Same here all the rom file made by sjkv0.8 gives unflashable rom.
Something might be broken then. I changed the executable last minute. What size is the NBH you are all producing?
ivan the output nbh size is ok it seems for a lite rom it produces about 56mb and remember the one nbh u provided for testing is also having prob it says its corrupt.
help me...SJK won't cook
i cannot make it work...
i get an error while cooking about some files (ringtones) not able to be copied and then hangs.
i tried it on Windows7 and it says that the some payload.nb file is not found in temp folder.
gui-wise/appearance wise...this is the best kitchen ever!!
can someone please tell me where i went wrong? i download four files from the SJK website: ext package, sys package, opal package and the SJK package and extracted to the same folder.
Update:
v0.8.1 - Fixed unflashable ROM bug
Thanks ivan now finally i can use sjk v0.8 (now 0.8.1) after using sjk 7 for so long time.
v0.8.2
Fixed LZX
still gives an error...
ivanmmj said:
v0.8.2
Fixed LZX
Click to expand...
Click to collapse
last night, i cooked 3-4 times using different settings, compression, rom version but it still gives a flash write error for me
cooking works fine except for some errors regarding some *.wma ringtone files inside SYS/PhoneRedist folder not being able to be copied (i overcame them by deleting)
flashing goes upto 100% (i used RUU via the usb cable) but the device reboots and goes to tri-color screen and says Rom Code Error.
btw...do i have to re-download every thing (SYS, EXT, *device_specific*) and the SJK_0.*.* or just the single SJK_0.*.* file?????
+1 Exactly same result since v8 and above
freelancer81 said:
last night, i cooked 3-4 times using different settings, compression, rom version but it still gives a flash write error for me
cooking works fine except for some errors regarding some *.wma ringtone files inside SYS/PhoneRedist folder not being able to be copied (i overcame them by deleting)
flashing goes upto 100% (i used RUU via the usb cable) but the device reboots and goes to tri-color screen and says Rom Code Error.
btw...do i have to re-download every thing (SYS, EXT, *device_specific*) and the SJK_0.*.* or just the single SJK_0.*.* file?????
Click to expand...
Click to collapse
No, if you already had the *_0.8 for all the files, just download the SJK_0.8.3. If you didn't have anything, download EVERY file that's not device specific and your device's file.
You're getting a flash write error?
Still error
what might be the problem????
flashing goes upto 100%, device reboots and goes to tri-color screen
and displays a "ROM CODE ERROR".
i tried all compression methods including UPX on EXT packages but same problem.
freelancer81 said:
what might be the problem????
flashing goes upto 100%, device reboots and goes to tri-color screen
and displays a "ROM CODE ERROR".
i tried all compression methods including UPX on EXT packages but same problem.
Click to expand...
Click to collapse
I think I know what happened. Please hold while I work with airxtreme to fix it.
gooooddddyyyy....i am looking forward to it!!!
Try this:
http://justkitchen.info/main/rokdownloads/SJK_0.8.5.7z
Please let me know ASAP if it works.
thank you for your promptness...i will surely try and let you know.
freelancer81 said:
thank you for your promptness...i will surely try and let you know.
Click to expand...
Click to collapse
Did you ever get a chance to try it out?
We have an imageinfo.bin, and S000, S001, S002, and S003. We need to combine them somehow.
So, I've found threads that will teach you how to create ROMs based on imageInfo.bin files, but does anyone know how to take the pieces of a DLL (or executable) and put them together as a standalone DLL? We are trying to do that in this thread: http://forum.xda-developers.com/showthread.php?t=844008&page=3
For an example of what we are trying to assemble, check here: http://forum.xda-developers.com/attachment.php?attachmentid=444604&d=1290160423
You need to get recmod.exe.
Awesome, thanks! You rock.
I'm running into an error message though, "Error! ProcessCase0: bit 5 is zero!" I think maybe the file format for windows phone 7 is different. Is there anywhere I can go to understand this problem, and maybe get the source code and fix it or something?
FWIW my suspicion is that recmode.exe doesn't properly handle signed binaries, since all the WP7 binaries are signed, but previous WM versions weren't all signed.
Ondraster probably knows the right way to re-file them.
OndraSter doesn't know the actual way .
Binaries in WP7 are a bit different, maybe those e32 and whatever (I haven't dug into this ever, don't understand it and I'm not sure it is worth learning, since WM is going off and WP7 won't be cookable or worth cooking) are different and recmod can't handle its new awesomeness .
Hey OndraSter,
Thanks for the reply. It seems it would be something useful in our efforts to run native code on Windows 7 to be able to recmod those things. Do you have the source code, or any tips on how to go about figuring it out? I can give you all the credit, all I want is to be able to assemble the files!
I have the same problem...