• G3
• G4
• H3

• binary - with large blocksizes, in the order of 32kbyte or larger.
  these are used for bootloader
• normal - with small blocksize, 512 bytes, like a normal disk
  these are used for the operatingsystem, and user data
• OTP - one time programmable, this is a small section, max about 8kbyte
  htc does not use this
• IPL - the initial-program-loader, small, about 8kbyte, this is automatically loaded in ram after reset.

layout used by htc

• usually the htc disk-on-chip devices are formatted with 1 or 2 binary partitions, and 2 or 3 normal partitions.
• normal partitions usually start with a partition table, containng the partition layout at offset 0x1BE

• one binary partition for the bootloader / SPL
• one binary partition containing these sections:
• one normal partition for the user filesystem, this is partition contains a partitiontable, and a fat32 partition
• one normal partition for the operatingsystem code, this partition contains a partition table, one or 2 XIP sections and a IMGFS section
• one normal partition for the extended rom, also with a partition table, and fat32 partition

the IPL

• the reading the IPL is not supported by the windows ce device driver, you can only read/write it from the bootloader.
• you can however get the IPL code, since it is usually still in RAM, at address 0x80000000

reading G3 devices

• one disk signature : 'BIPO'
• binpart#0 has sectorsize 0x8000
• binpart#1 has sectorsize 0x10000 or 0x4000 depending on the sector

reading G4 devices

• one disk signature : 'BIPO'
• binpart#0 has sectorsize 0x20000
• binpart#1 has sectorsize 0x10000 or 0x4000 or 0x40000, or 0x30000 depending on the sector

reading H3 devices

• each binary partition block has a different disk signature
• binpart#0 has sectorsize 0x40000
• binpart#1 has sectorsize 0x40000

pdocread

• -b to specify the sectorsize, this is used to calculate the starting sector number from the starting offset. and also to calculate the sector to start reading the second transfer block from.
• -G to specify the transfer blocksize, this is the amount of information transferred in one request from the wince device to the pc. max about 16M, but i don't know if such large blocks transfer properly without errors.
• -B to specify the Trueffs reading blocksize, this is the amount of data requested at once by itsutils.dll from the trueffs device driver. older drivers did not support reading very large blocks, but usualy this is not relevant to reading a specific layout, more useful when you encounter crashes during reading.

reading G3

pdocread -n 0 0 0x100000 -b 0x8000 bdk0-spl.bin 
pdocread -n 1 0 0x10000 bdk1-0-cid.bin 
pdocread -n 1 0x10000 0x10000 bdk1-1-cidbk.bin 
pdocread -n 1 0x20000 0x10000 bdk1-2-serial.bin 
pdocread -n 1 0x30000 0x10000 bdk1-3-subsplash.bmp 
pdocread -n 1 0x10000 0x4000 -b 0x4000 bdk1-4-gsmdata.bin
pdocread -n 1 0x50000 0x280000 bdk1-5-gsmcode.bin
pdocread -n 1 0x2d0000 0x30000 bdk1-45-splash.bin 

reading G4

pdocread -n 0 -b 0x20000 0 0x100000 bdk0-spl.nb
pdocread -n 1 -b 0x10000 0 0x40000 bdk1-0-cid.nb
pdocread -n 1 -b 0x10000 0x10000 0x40000 bdk1-1.nb
pdocread -n 1 -b 0x10000 0x20000 0x40000 bdk1-2-serials.nb
pdocread -n 1 -b 0x10000 0x30000 0x40000 bdk1-3.nb
pdocread -n 1 -b 0x4000 0x10000 0x4000 bdk1-4-gsmdata.nb
pdocread -n 1 -b 0x40000 0x140000 0x280000 bdk1-5-gsmcode.nb
pdocread -n 1 -b 0x40000 0x380000 0x40000 bdk1-e.nb
pdocread -n 1 -G 0x30000 -b 0x10000 0xF0000 0x30000 bdk1-f-splash.nb

reading H3

pdocread -n 0 -b 0x40000 0 0x100000 bdk0-spl.nb
pdocread -S BK1A -n 1 -b 0x40000 -G 0x40000 0x00000 0x40000 A-cid.nb
pdocread -S BK1B -n 1 -b 0x40000 -G 0x40000 0x00000 0x40000 B-empty.nb
pdocread -S BK1C -n 1 -b 0x40000 -G 0x40000 0x00000 0x40000 C-serials.nb
pdocread -S BK1D -n 1 -b 0x40000 -G 0x40000 0x00000 0x40000 D-empty.nb
pdocread -S BK1E -n 1 -b 0x40000 -G 0x40000 0x00000 0x40000 E-gsmdata.nb
pdocread -S BK1F -n 1 -b 0x40000 -G 0x40000 0x00000 0x280000 F-gsmcode.nb
pdocread -S BK1G -n 1 -b 0x40000 -G 0x40000 0x00000 0x40000 G-splash.nb