[openfirmware] Making Open Firmware look like CE
Mitch Bradley
wmb at laptop.org
Mon May 30 05:14:09 CEST 2011
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-ce-6.0-start_3f00_.aspx
>>
>> 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 at openfirmware.info
> https://openfirmware.info/mailman/listinfo/openfirmware
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dumpcebin.fth
URL: <http://openfirmware.info/pipermail/openfirmware/attachments/20110529/30a9de0c/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: makecebin.fth
URL: <http://openfirmware.info/pipermail/openfirmware/attachments/20110529/30a9de0c/attachment-0001.ksh>
More information about the openfirmware
mailing list