[openfirmware] Making Open Firmware look like CE

[Mitch Bradley]

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.
>