I think the answer is here: http://msdn.microsoft.com/en-us/library/ms924510.aspx
I downloaded an NK.bin that I found on the web, apparently for some random Nokia device, and was able to make sense of it according to that recipe:
0000000: 42 30 30 30 46 46 0a signature - "B000FF\n" 0000007: 00 00 30 8c 0x8c300000 start address for loading 000000b: 94 bc 07 01 0x107bc94 total size
000000f: 00 00 30 8c 0x8c300000 of this chunk start address 0000013: 04 00 00 00 0x00000004 chunk length 0000017: eb 01 00 00 0x000001eb checksum - 0xfe + 0x03 + 0x00 + 0xea 000001b: fe 03 00 ea 0xea0003fe data: ARM instruction "b .+1000"
000001f: 40 00 30 8c 0x8c300040 chunk start address chunk 0000023: 08 00 00 00 0x00000008 chunk length 0000027: a1 02 00 00 0x000002a1 checksum - 45+43+45+43+30+9d+37+8d 000002b: 45 43 45 43 data: "ECEC" 000002f: 30 9d 37 8d 0x8d379d30 pointer to ECEC data - TOC?
0000033: 48 00 30 8c 0x8c300048 start address of this chunk 0000037: 04 00 00 00 0x00000004 chunk length 000003b: d5 00 00 00 0x000000d5 checksum - 30+9d+01+01 000003f: 30 9d 07 01 0x01079d30 Maybe this is the virtual address for the TOC or something? Note that the low 25 bits are the same as the address in the ECEC block
0000043: 00 10 30 8c 0x8c301000 chunk start address 0000047 ac f2 03 00 0x0003f2ac chunk length - almost 256K 000004b: 84 91 8f 01 0x108f9184 checksum - 32 bit sum of the following 0x0003f2ac bytes
data - probably text segment 000004f: 57 00 00 ea 0xea000057 ARM instruction "b .+0x164" - This is clearly the ARM vector table 0000053: fd ff ff ea 0xeafffffd ARM instruction "b .-4" (i.e. to the instruction at 000004f:) 0000057: fc ff ff ea 0xeafffffd ARM instruction "b .-8" (i.e. to the instruction at 000004f:) 000005b: fb ff ff ea 0xeafffffd ARM instruction "b .-0xc" (i.e. to the instruction at 000004f:) 000005f: fa ff ff ea 0xeafffffd ARM instruction "b .-0x10" (i.e. to the instruction at 000004f:) 0000063: f9 ff ff ea 0xeafffffd ARM instruction "b .-0x14" (i.e. to the instruction at 000004f:) 0000067: f8 ff ff ea 0xeafffffd ARM instruction "b .-0x18" (i.e. to the instruction at 000004f:) 000006b: f7 ff ff ea 0xeafffffd ARM instruction "b .-0x1c" (i.e. to the instruction at 000004f:) 000006f: 00 00 00 80 0x80000000 some data of unknown interpretation - not ARM instructions 0000073: 00 00 00 00 0x00000000 0000077: 01 00 00 00 0x00000001 000007b: 00 00 00 84 0x00000084 ...
Attached are two Forth scripts. dumpcebin.fth will decode a .bin file, displaying the section headers and the first few bytes of each section.
$ forth dumpcebin.fth -s "dump-bin NK.bin"
makecebin.fth will wrap a binary file as a .bin file.
$ forth makecebin.fth -s "make-bin-file ofw.img ofw.bin"
On 5/29/2011 6:44 AM, Mitch Bradley wrote:
How about sending me a hex dump of the first thousand bytes of the nk image.
OFW does have code at the beginning. The first location in the AIF header it currently uses contains a branch instruction.
Other headers could be prepended to that as necessary.
On 5/29/2011 3:47 AM, Mark Morgan Lloyd wrote:
Mitch Bradley wrote:
On 5/28/2011 2:19 AM, Mark Morgan Lloyd wrote:
A few weeks ago (mid March) I mentioned that I had some ARM boards that I'd like use as Linux development systems. Unfortunately, they come with CE, and while the manufacturer does supply Linux it's prohibitively expensive.
CE is booted from a partitioned CompactFlash card, and I initially thought that the code in the partition and filesystem boot sectors was relevant, i.e. that there was something equivalent to a PC's BIOS in Flash. However on inspection I think that the code is x86, which implies that the loader in Flash is reading and transferring control to the OS image directly.
Is it possible to build Open Firmware to look like a CE image, which would possibly allow this board (and potentially many other devices) to run Linux without modification to the content of internal Flash?
It should be relatively easy. The ARM version of OFW is dynamically relocatable, so all you have to do is put it somewhere in memory and jump to it.
I believe that WinCE use the PECOFF image format, documented at http://msdn.microsoft.com/en-us/windows/hardware/gg463125
There is also /usr/include/linux/coff.h which may clarify some things.
PECOFF has a lot of features but I think all you need is file header followed by a single section header. My best guess is that the section name should be ".text". The physical address and virtual address should be the desired load address (which is pretty flexible as I mentioned), and the file pointer would be the offset to the OFW image data.
This is the sort of thing - slapping on random headers as required by some pre-existing bootloader - that I do routinely when porting to a new platform.
The thing to do is to hex dump the first thousand bytes of the CE image and see if you can make sense of it as a PECOFF header. Then put a similar header on the front of the OFW image.
cpu/arm/savefort.fth contains an example of making a header (in this case in AIF - ARM Image Format) then writing the header and the OFW dictionary image out to a file.
Interesting, so in the current case I should be able to wrap it in a header using a binary editor, at least initially.
I think that I'm going to have to update viewers before I can make sense of that reference :-(
For reference (and Google), this is what I see while booting:
Microsoft Windows CE Ethernet Bootloader Common Library Version 1.1 Built May 5 2006 17:09:07 LP3970 Init Fail!! ICPEMS WinCE Bootloader 1.7 for the HMI270 Built May 5 2006 CF_Reset: Reset CF card ... Success! CF_Reset: Reset CF card ... Success! CF_Reset: Reset CF card ... Success! CF_CopyImageToRAM: Starting to copy OS image to memory -Image address = 0x80100000 -Image length = 0x01b64c00 -Launch address = 0x80101000 CF_CopyImageToRAM: Succeeded to copy image from CF card to memory CF_Reset: Reset CF card ... Success! Download successful! Jumping to image at 0x80101000 (physical 0xA0101000)...
At that point I suspect it's trying to talk to an LCD, which in my case I have not got. I presume that the physical address in the last line is a red herring as far as headers are concerned. I think the ICPEMS is a loader peculiar to this manufacturer (IEI) or board model (Kamio-2701), but I don't know whether "PE" and "MS" in that name are related to the format or indicate an author.
On the FAT-16 contained in the partitioned CF module, there's a boot.ini which specifies BinFile=nk.bin. I think the boot.ini is read by a file called BLDR (boot loader?) which I presume is the one we want to emulate. However, here are the file sizes:
drwxr-xr-x 2 root root 2048 2006-07-28 10:18 System -rwxr-xr-x 1 root root 28199699 2006-06-13 14:05 NK.bin -rwxr-xr-x 1 root root 481080 2006-05-17 09:24 logo.bmp -rwxr-xr-x 1 root root 1181 2005-01-01 18:51 BOOT.INI -r-xr-xr-x 1 root root 20480 2004-09-30 21:24 BLDR -rwxr-xr-x 1 root root 3544 2004-07-01 12:00 SPLASH.BMX
The image length from the load messages looks more like that of NK.bin plus a 512K offset. Those messages don't appear to be in the BLDR file so it might actually be that it calls back to code in Flash, I suspect that I'm going to have to bite the bullet and hook up JTAG (something I've not done before- I'm a logic analyser man) before I can get any further.
This http://blogs.msdn.com/b/ce_base/archive/2007/11/26/how-does-windows-embedded...
is a very good description of loading the kernel for CE 6.0, but in the current case I think I'm looking at 5.0 and while it's similarly got an ECEC marker I think what comes after differs... it's definitely not a PE variant, although it's always possible that some of the internal structures are similar to COFF.
[Slightly later] Google suggests that the embedded ECEC marker is critical, but http://itsme.home.xs4all.nl/ cryptically refers to this format as being "xip" (execute in place?). I need to look at BLDR with a disassembler but I suspect that it might actually be a binary with no significant header. Can I build OFW with code or at least a relative jump at the start?
I'll be back... after I've tried to make sense of somebody's MIPS compiler port.
openfirmware mailing list openfirmware@openfirmware.info https://openfirmware.info/mailman/listinfo/openfirmware