howto convert .bin to .nb0 and back
Foreword:
.BIN files are not all the same by their nature (of course not by content). There are
- .bin that are used to identify the bare binary content of the various partitions (you mostly see those)
- .bin that are used to flash a ROM to the device. This looks somehow historic though, the format is already described by itsme at: http://www.xs4all.nl/~itsme/projects/xda/wince-flashfile-formats.html. It seems to me that some non HTC devices are still using this format.
The osnbtool.exe (from Weisun at PDACLAN.COM) does not work for any purpose regarding .bin files
at least not for Hurricane.
- The -sp option cuts only the B000F\0a header but does not reconstruct the blocks of the .bin file.
Mind that small .bin files (smaller than 0x1c00000) are treated correctly as there is only one block.
- The -2bin option creates an incorrect .bin header (sets a weird total length) and sets totally confused
block-load addresses for the created blocks of 64k (0x10000) size. Check it with viewbin.exe if you like.
Reference for the filestructure by itsme:
http://www.xs4all.nl/~itsme/projects/xda/wince-flashfile-formats.html
The splitrom.pl (itsme romtools) seems not be able to read the content of any .bin file I have fed to it.
Neither for .BIN files created for Hurricane nor those for Typhoon, I always get:
cmd> splitrom.pl <binfile>
B000FF image: 82040000-84c40000, entrypoint: 00000000
!!! your rom is not known to me: md5: a520f0d1093b36f0a3cfd9323ea99155
this bootloader seems to be No bootloader present
no xipchain found
no bootloader found
no operator rom found
no bitmap found
I am rather sure it should handle everything correctly but I am too stupid to debug .pl :(
So the only thing that works and will re-create a flash-able .BIN file from a .nb0 is listed below:
- convert .bin to .nb0:
- enter: viewbin -r <binfile>, you get something like:
Image Start = 0x82040000, length = 0x02C00000
Record [ 0] : Start = 0x82040000, Length = 0x01C00000, Chksum = 0x00000000
Record [ 1] : Start = 0x83C40000, Length = 0x01000000, Chksum = 0x00000000
Record [ 2] : Start = 0x00000000, Length = 0x00000000, Chksum = 0x00000000
Start address = 0x00000000
The above has two blocks of data and a termination block.
The checksum = 0 effectively disables upload checking (so potentially dangerous).
The size just fits the Hurricane's SPL "l" (load) command buffer, as you get when loading a ROM:
"clean up the image temp buffer at 0x8C080000 Length 0x01C40000 "
The blocks can be smaller than 0x1c40000 but not bigger obviously.
- then convert to nb0, enter: cvrtbin.exe -r -a <imgstart> -l <length> -w 32 <binfile>
for above viewbin output: cvrtbin.exe -r -a 82040000 -l 2c00000 -w 32 <binfile>
mind to omit the 0x for the start and address, replace <binfile> with your filename, then you get a resulting file from <original-name.bin> to <original-name.nb0> which can further be decomposed and edited with standard ROM tools
- convert .nb0 to .bin:
enter: xipbin.exe <input.nb0> <start-in-nb0> <output.bin> <loadaddress>
to get back something flashable like above: xipbin.exe <input.nb0> 0 <output.bin> 82040000
mind to omit the 0x for the loadaddress, replace <"file"> with your filenames
- to recheck if the created BIN file is usable, startup the viewbin again
- enter: viewbin -r <binfile> you now get something like:
Image Start = 0x82040000, length = 0x02C00000
Record [ 0] : Start = 0x82040000, Length = 0x00040000, Chksum = 0x0208CC79
...many entries deleted...
Record [175] : Start = 0x84C00000, Length = 0x00040000, Chksum = 0x0177FB3C
Record [176] : Start = 0x00000000, Length = 0x00000000, Chksum = 0x00000000
Start address = 0x00000000
Done.
- Looks quite different - but this is ok! The loading process in MTTY indocates the loading of each above block with a sequence of |*, so with these many blocks the upload to the device is giving feedback and thus is not tempting people to interrupt it.
I have done my tests with the 566.zip linked in the first post of this thread, but this should work with any .BIN file from the other ROMs as well. So I will continue to see if I can recycle any of the WM6 Roms for inserting my imgfs created for Tornado. As before the imgfs still the XIP is loaded and I know too little about this yet (especially in connection to the imgfs and how close these two are linked) - I am prepared to see non booting device states quite a lot. Luckily there is nothing done to the early boot chain (IPL and SPL) so I can always get back to the bootloader and start over again.
I hope to get a first indication that imgfs is mounted correctly in the "old" XIP before I have to replace the OEMdriver parts in my Tornado ROM.
I just checked if I can still use this flash-method for the Tornado - and it works as well. So the created "os-new.nb" in the OUT directory can be converted to .BIN and then flashed inside MTTY with the "l" command. Not that I like this method - but it works as well.