As you've probably ascertained, Zymkey is more of a generic HSM than a TPM. As such, it isn't (and cannot) be used at the core of the boot process. To date, the Raspberry Pi does not implement an HAB strategy. Typically, an HAB strategy employs digital signature verification for each of the low level components along the way in the boot process. On the i.MX6, for example, this feature is implemented with ROM code that knows how to do verify signatures based on fusible material which describes booting options and public keys. Essentially this looks like:
2) ROM boot strap checks HAB fuse and verifies signature of 2nd stage bootloader using fused public key
3) 2nd stage bootloader verifies kernel signature using same fused public key and loads kernel if signature is verified
As you may already know, in the Raspberry Pi, the GPU starts the boot process, not the ARM CPU and there is no OTP space available for programming public keys. The Broadcom GPU is proprietary and really can't be programmed (discounting the open source compiler based on reverse engineering). This means that the soonest that an evaluation could be performed is in the kernel or later.
Zymbit, however, is working on a strategy that could be used to provide a reliable boot process which requires an encrypted root file system plus an initramfs. Measurements for the boot components are stored on the crypto rootfs and are evaluated by the second stage init on the crypto rootfs prior to continuing the boot process:
1) GPU boots Pi via ROM bootstrap, start.elf, etc.
2) GPU loads kernel and initramfs and hands off to ARM CPU.
3) initramfs init uses Zymkey to decrypt a black blob which contains the LUKS key for a dm-crypt rootfs. initramfs hands over to the crypto filesystem with the LUKS key.
4) The init script on the crypto rootfs evaluates signatures for all of the early components prior to entering the crypto rootfs (e.g. start.elf, initramfs, kernel, bootcfg.txt). If any of these components fails, the system shuts down.
Of course, the above only works if the final crypto rootfs can be sufficiently locked down with good password hygiene and/or ssh keys. Also, there are logistics associated with upgrade of the various boot components.
I hope this answers your questions. Please feel free to follow up.