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.