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?
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.
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.
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.
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
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.
OK. This is the start of BLDR which I think is what the code in Flash is loading.
0000000: 9090 9066 e987 1600 0090 9090 9090 9090 ...f............ 0000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000040: 4543 4543 d448 0000 d438 0000 0000 0000 ECEC.H...8...... 0000050: 0000 0000 0000 0000 0000 0000 0000 0000 ................ [Zero lines repeated] 0000ff0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0001000: 0000 0000 10ea 5c41 0000 0000 0200 0000 ......\A........ 0001010: 5100 0000 cc15 0000 cc09 0000 0000 0000 Q............... 0001020: 0000 0000 3340 0000 0141 4400 5010 4009 ....3@...AD.P.@. 0001030: 0540 0000 014c 5300 5010 4009 7820 0000 .@...LS.P.@.x .. 0001040: 014c 5300 ec10 2980 f0c0 0000 014b 5300 .LS...)......KS. 0001050: ec10 2981 0000 0000 0452 5400 ec10 3981 ..)......RT...9. 0001060: 0b90 0000 0452 5400 ec10 3981 c9d0 0000 .....RT...9..... 0001070: 0452 5400 ec10 3981 4ce0 0000 0452 5400 .RT...9.L....RT. 0001080: 8611 0013 ba50 0000 0444 4c00 0b10 2000 .....P...DL... . 0001090: cca0 0000 054e 4700 b710 5090 0860 0000 .....NG...P..`.. 00010a0: 0633 4300 b710 0092 7604 0000 0633 4300 .3C.....v....3C. 00010b0: d448 0000 4a75 6d70 696e 6720 746f 2069 .H..Jumping to i 00010c0: 6d61 6765 2028 6164 6472 6573 733d 3078 mage (address=0x 00010d0: 2578 290a 0a00 0000 290d 0a00 2028 4275 %x).....)... (Bu 00010e0: 696c 7420 0000 0000 2e00 0000 5665 7273 ilt ........Vers 00010f0: 696f 6e20 0000 0000 2573 2025 732e 2573 ion ....%s %s.%s 0001100: 2028 4275 696c 7420 2573 290d 0a00 0000 (Built %s)..... 0001110: 0a0d 4d69 6372 6f73 6f66 7420 5769 6e64 ..Microsoft Wind 0001120: 6f77 7320 4345 2042 494f 5320 426f 6f74 ows CE BIOS Boot 0001130: 6c6f 6164 6572 2056 6572 7369 6f6e 0000 loader Version.. 0001140: 3200 0000 4f63 7420 2031 2032 3030 3400 2...Oct 1 2004. 0001150: 0000 0000 3340 0000 0141 4400 5010 4009 ....3@...AD.P.@. 0001160: 0540 0000 014c 5300 5010 4009 7820 0000 .@...LS.P.@.x .. 0001170: 014c 5300 ec10 2980 f0c0 0000 014b 5300 .LS...)......KS. 0001180: ec10 2981 0000 0000 0452 5400 ec10 3981 ..)......RT...9. 0001190: 0b90 0000 0452 5400 ec10 3981 c9d0 0000 .....RT...9..... 00011a0: 0452 5400 ec10 3981 4ce0 0000 0452 5400 .RT...9.L....RT. 00011b0: 8611 0013 ba50 0000 0444 4c00 0b10 2000 .....P...DL... . 00011c0: cca0 0000 054e 4700 b710 5090 0860 0000 .....NG...P..`.. 00011d0: 0633 4300 b710 0092 7604 0000 0633 4300 .3C.....v....3C. 00011e0: 4641 5433 3200 0000 4641 5431 3600 0000 FAT32...FAT16... 00011f0: 4641 5431 3200 0000 0000 0000 3340 0000 FAT12.......3@.. 0001200: 0141 4400 5010 4009 0540 0000 014c 5300 .AD.P.@..@...LS. 0001210: 5010 4009 7820 0000 014c 5300 ec10 2980 P.@.x ...LS...). 0001220: f0c0 0000 014b 5300 ec10 2981 0000 0000 .....KS...)..... 0001230: 0452 5400 ec10 3981 0b90 0000 0452 5400 .RT...9......RT. 0001240: ec10 3981 c9d0 0000 0452 5400 ec10 3981 ..9......RT...9. 0001250: 4ce0 0000 0452 5400 8611 0013 ba50 0000 L....RT......P.. 0001260: 0444 4c00 0b10 2000 cca0 0000 054e 4700 .DL... ......NG. 0001270: b710 5090 0860 0000 0633 4300 b710 0092 ..P..`...3C.....
This is the start of NK.bin which I think is loaded by BLDR which gets its name from BOOT.INI, the header format might be useful.
0000000: 4230 3030 4646 0a00 0010 8000 4cb6 0100 B000FF......L... 0000010: 0010 8004 0000 00eb 0100 00fe 0300 ea40 ...............@ 0000020: 0010 8008 0000 00cb 0200 0045 4345 4360 ...........ECEC` 0000030: 14c6 8148 0010 8004 0000 002b 0100 0060 ...H.......+...` 0000040: 14b6 0100 1010 802c 2904 008c 279f 0142 .......,)...'..B 0000050: 0000 eb0f 001a e331 1700 0a5a 0000 eb08 .......1...Z.... 0000060: 001a e30f 0000 1a9d 0c01 eb01 42a0 e3fd ............B... 0000070: 10a0 e300 1084 e5dc 009f e508 0090 e50a ................ 0000080: 10a0 e129 ef00 eb00 0050 e303 0000 1ac4 ...).....P...... 0000090: 009f e508 0090 e50a 10a0 e138 ef00 ea04 ...........8.... 00000a0: 10a0 e301 a0ca e198 0e01 eb01 42a0 e3df ............B... 00000b0: 10a0 e300 1084 e559 0000 eb01 42a0 e3de .......Y....B... 00000c0: 10a0 e300 1084 e508 0d01 eb01 42a0 e3dd ............B... 00000d0: 10a0 e300 1084 e5e6 0c01 eb01 42a0 e3dc ............B... 00000e0: 10a0 e300 1084 e545 ef00 eb01 42a0 e3fb .......E....B... 00000f0: 10a0 e300 1084 e514 0d01 eb01 32a0 e3fa ............2... 0000100: 10a0 e300 1083 e5da 0c01 eb01 32a0 e3f9 ............2... 0000110: 10a0 e300 1083 e5ac 0e01 eb01 32a0 e3f8 ............2... 0000120: 10a0 e300 1083 e581 0e01 eb01 32a0 e3f7 ............2... 0000130: 10a0 e300 1083 e5d9 0e01 eb01 32a0 e3f6 ............2... 0000140: 10a0 e300 1083 e54d 0f01 eb01 32a0 e3f5 .......M....2... 0000150: 10a0 e300 1083 e5f1 1600 ea00 00f0 40d3 ..............@. 0000160: 00a0 e300 f021 e1a0 009f e511 0f0f ee10 .....!.......... 0000170: 0f12 ee00 00a0 e104 f04f e278 00a0 e310 .........O.x.... 0000180: 0f01 ee10 0f12 ee00 00a0 e104 f04f e200 .............O.. 0000190: 00e0 e310 0f03 ee74 009f e530 a090 e51f .......t...0.... 00001a0: 20a0 e302 a00a e030 2080 e504 c090 e53f ......0 ......? 00001b0: 20a0 e302 c00c e00c c8a0 e10c a08a e105 ............... 00001c0: 10a0 e300 1080 e51e ff2f e144 009f e502 ........./.D.... 00001d0: 11a0 e354 1080 e508 10a0 e35c 1080 e502 ...T........... 00001e0: 12a0 e364 1080 e52c 109f e568 1080 e505 ...d...,...h.... 00001f0: 19a0 e314 1080 e520 109f e50c 1080 e501 ....... ........ 0000200: 02a0 e3ff 10a0 e300 1080 e51e ff2f e143 ............./.C 0000210: 2000 0000 00f0 4000 00e0 403a a409 c11a .....@...@:.... 0000220: c4f8 c301 22a0 e311 10a0 e300 1082 e514 ...."........... 0000230: 109f e514 209f e504 2081 e501 22a0 e322 .... ... ...".." 0000240: 10a0 e300 1082 e51e ff2f e100 0030 4140 ........./...0A@ 0000250: 0240 0000 0000 0000 0000 0000 0000 0000 .@.............. 0000260: 0000 006a 558e 4400 0000 0002 0000 0056 ...jU.D........V 0000270: 0000 0048 6b00 0048 5f00 0041 5049 5302 ...Hk..H_..APIS. 0000280: 0605 0040 1210 8000 0000 0000 0000 0028 ...@...........( 0000290: 9210 80f4 da10 80c8 9210 8084 9410 80ec ................ 00002a0: 9410 8000 0000 0008 0000 0041 0052 004d ...........A.R.M 00002b0: 0000 009c 1310 8090 1310 8078 1310 8074 ...........x...t 00002c0: 1310 8064 1310 8058 1310 8054 1310 8048 ...d...X...T...H 00002d0: 1310 8048 1310 8038 1310 802c 1310 8057 ...H...8...,...W 00002e0: 0069 006e 0064 006f 0077 0073 0020 0043 .i.n.d.o.w.s. .C 00002f0: 0045 0020 004b 0065 0072 006e 0065 006c .E. .K.e.r.n.e.l 0000300: 0020 0066 006f 0072 0020 0041 0052 004d . .f.o.r. .A.R.M 0000310: 0020 0028 0054 0068 0075 006d 0062 0020 . .(.T.h.u.m.b. 0000320: 0045 006e 0061 0062 006c 0065 0064 0029 .E.n.a.b.l.e.d.) 0000330: 0020 0042 0075 0069 006c 0074 0020 006f . .B.u.i.l.t. .o 0000340: 006e 0020 004a 0075 006e 0020 0032 0034 .n. .J.u.n. .2.4 0000350: 0020 0032 0030 0030 0034 0020 0061 0074 . .2.0.0.4. .a.t 0000360: 0020 0031 0038 003a 0032 0035 003a 0030 . .1.8.:.2.5.:.0 0000370: 0030 000d 000a 0000 0000 005b 4857 2042 .0.........[HW B 0000380: 7265 616b 5d00 005b 5374 6163 6b20 6661 reak]..[Stack fa 0000390: 756c 745d 0000 003c 496e 7661 6c69 643e ult]...<Invalid> 00003a0: 0000 0049 5251 0044 6174 6120 4162 6f72 ...IRQ.Data Abor 00003b0: 7400 0050 7265 6665 7463 6820 4162 6f72 t..Prefetch Abor 00003c0: 7400 0053 5749 0055 6e64 6566 696e 6564 t..SWI.Undefined 00003d0: 2049 6e73 7472 7563 7469 6f6e 0000 0052 Instruction...R 00003e0: 6573 6368 6564 756c 6500 0052 6169 7365 eschedule..Raise 00003f0: 4578 6365 7074 696f 6e00 0000 0000 004d Exception......M 0000400: 0044 0056 0061 006c 0069 0064 0061 0074 .D.V.a.l.i.d.a.t 0000410: 0065 0052 006f 006d 0043 0068 0061 0069 .e.R.o.m.C.h.a.i 0000420: 006e 003a 0020 0058 0049 0050 0020 0028 .n.:. .X.I.P. .( 0000430: 0025 0038 002e 0038 006c 0078 0020 002d .%.8...8.l.x. .- 0000440: 003e 0020 0025 0038 002e 0038 006c 0078 .>. .%.8...8.l.x 0000450: 0029 0020 0064 006f 0065 0073 006e 0027 .). .d.o.e.s.n.' 0000460: 0074 0020 0065 0078 0069 0073 0074 0020 .t. .e.x.i.s.t. 0000470: 0069 006e 0020 004f 0045 004d 0041 0064 .i.n. .O.E.M.A.d 0000480: 0064 0072 0065 0073 0073 0054 0061 0062 .d.r.e.s.s.T.a.b 0000490: 006c 0065 0020 000d 000a 0000 0000 004d .l.e. .........M 00004a0: 0044 0056 0061 006c 0069 0064 0061 0074 .D.V.a.l.i.d.a.t 00004b0: 0065 0052 006f 006d 0043 0068 0061 0069 .e.R.o.m.C.h.a.i 00004c0: 006e 003a 0020 0058 0049 0050 0020 0028 .n.:. .X.I.P. .( 00004d0: 0025 0038 002e 0038 006c 0078 0020 002d .%.8...8.l.x. .- 00004e0: 003e 0020 0025 0038 002e 0038 006c 0078 .>. .%.8...8.l.x 00004f0: 0029 0020 0073 0070 0061 006e 0020 0061 .). .s.p.a.n. .a
I've tacked on a few extra lines of messages because the mix of ASCII and Unicode is interesting, and because they specifically refer to XIP.
Hope this makes some sense. At one time I could decode popular opcode sets from memory...
openfirmware@openfirmware.info
-
Mark Morgan Lloyd -
Mitch Bradley