[Windows Phone 7 Development and Hacking] ntonhd2:
sure....... :). anything ReactOS -freeldr, any arm code, whatever, is just to get basic idea up- to see the actual jump whilst watching (be it by jtag, kitl, usb, or telepathy interface to QD) and go from there; although im sure you could use ReactOS arm code lowlevel bootloader to jump into EITHER "freeldr" or proper "ntldr" or "osloader.exe" (modified of course to have no pci bus scan and the rest.....) that is the dilemma: either jump COMPLETELY like winmo6-android with all structures setup DIRECTLY INTO KERNEL and avoid the whole LDR side of things in that sense anyway; or, well, totally from scratch rebuild loader and subsequently deal with 'firmware' issues... i really do not care in the end if its a jump from one kernel to another (one os to another) because project here is to RUN NT ON ARM/HD2 and not to necessarily have it homogenous down to LDR.

as long as thread, memory, native api, other calls, all that, is truly ntoskrnl = you are running nt on your arm hd2! :D.

LDR does not matter.... total new rebuild or jump.... whatever comes first ;).

Thanks Cotulla, yes, we understand where your coming from re do not need linux, ce, and complexities there and i agree: just want to use these for initial testing and deployment of early code with some kitl, debug.... on other notes, trying to put all into organized groups, slowly :D but surely yes, with bit of faith we will get there in the end :).

if totally up to me i would probably take intel/tianocore EFI specification as the base if this could somehow be easily made to run on ARM in this particular context. ie EFI on a HD2!

look at this raw control power!>>> http://www.ami.com/support/doc/AMI_Debug_UEFI_Dsheet_PUB_2008-06-10.pdf

also along these lines, just briefly (is helpful in concept design):

http://x86asm.net/articles/uefi-hypervisors-winning-the-race-to-bare-metal/index.html

http://sourceforge.net/projects/gnu...orig.tar.gz/gnu-efi_3.0h.orig.tar.gz/download

http://x86asm.net/articles/introduction-to-uefi/

http://sourceforge.net/projects/efidevkit/

http://www.logic.nl/Products/Technology/BIOS-and-EFI.aspx

ok, summing up thoughts here>>>

0) object manager and objects; going over arm & ce7, as well as winmo6 and other ce, and comparing with nt and win32/64; just looking at how on final arm release, the \ObjectTypes will be different in the end. very interesting stuff.

1) LACK-OF. no pci bus which is highly expected by ldr/detect so make kernel prob see system in 'PALcode' or EFI mode. pass ldr data structs to kernel in that type of form. otherwise gets very messy and we are not going to hack around because you will end up with an emulator :D!. this will work but key is determing what 'firmware' passes this data to nt kernel - not from our perspective- but as NT.

2) BIOS. INT services are not used by kernel in that way after it becomes supervisor so will redo drivers unless preload remap somehow. INT only there during ntldr (or can load in ntbootdd.sys to supply these) and this is all pre-phase0 and is very early on.

3) HAL and clk

4) INT services are not used by kernel in that way after it becomes supervisor so will redo drivers unless preload remap somehow. INT only there during ntldr (or can load in ntbootdd.sys to supply these) and this is all pre-phase0 and is very early on.

5) kitl and kdcom

6) registry to pass on (setupreg).

8) filesystem, screen, other drivers

9) final native cli (ntdll.dll) or maybe initially just spcmdcon.sys.

above not in order :p..... sorting it all out though ;).....

ok, looks daunting but like i said before you could get up an nt kernel in setup mode with setup ldr and drivers and old blue screen "dos" mode native subsystem which uses the SMSS.EXE and NTDLL.DLL that are seperately contained in \i386\system32\ or \cmdcons\system32\ - very limited subsystem but is full nt os at kernel :). so........ if not ce and not linux preloading, WOW :D. it is quite an amazing project but doable; so basically just need to see how this armldr (low level strap - be it Reactos or my own clean job- will do both) code runs on the device itself and step by step add the rest in as required! but i still believe actual dev be better jumping from preexisting environment having kitl or some sort of serial or usb debug already there and then working way down to lowest possible level; so, basically, working backwards down to processor.

Doing it all from scratch and CLEAN :). (in the end!). ;).