[openfirmware] Making Open Firmware look like CE

[Mark Morgan Lloyd]

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.

-- 
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]