I could use a small number of the 12x12mm chips for prototyping with. How do I go about arranging to get some?
Email me & Robin directly. Write the message *only* about buying a small number of those chips. Mixing business and any tech questions in the same email is a perfect way for it to "slip through the cracks" when we're really busy (which is almost always).
I believe we have more chips arriving next week, so we should be good for low to moderate (under 100) quantity.
And that if I shell out the extra dough to get them, I'll be able to burn off the NXP software with the Teensy bootloader and run it just like a Teensy 4.x.
I haven't tested any of those chips. As far as I know, nobody has.
I also don't have any technical documentation about how they really work. I only know how the normal 1062 part works, and a little info I've read (but not hands-on experience) about the 1064 part. So all the following comments are based only on my 1062-based knowledge.
Hard to imagine you could "burn off the NXP software". With Teensy, the software storage in a separate flash chip made by Winbond. The 1062 chips have no flash memory. NXP can't know whether you will connect a Winbond or Spansion or ISSI or other flash chip, and they certainly have no control over the contents of flash memory you buy from other companies and connect to the 1062. NXP only has ROM and fuse memory inside 1062.
Code isn't possible in the fuse memory. The fuse memory is only 256 bytes and most of it is reserved for specific uses, like stuff NXP stores during testing of the chips, boot configuration, and areas meant for encryption keys. The fuse memory is mapped to the peripheral address space, where we configure the MPU to disallow code execution. Even if the MPU was configured differently and fuse memory large enough for a program, you probably couldn't execute any code from the fuses because the registers are sparsely populated with each 4 byte word mapped every 16 bytes of address space.
While NXP could theoretically put anything inside those chips, the 3 plausible explanations (at least that I can imagine) for embedding software would be repurposing part of the normal ROM, or increasing the ROM size, or adding a flash chip on FlexSPI2, as they do for the 1064 part.
The 1062 chip has many powerful security features which we normally don't use on Teensy 4.x. I'm currently working on support for encrypted firmware, but even that will use only a subset of the security features. NXP has many more capabilities in the hardware, and it's entirely possible the chip has even more (undocumented outside NXP) security features.
But we do know the hardware supports
ARM TrustZone. On top of the normal ARM MPU, NXP has a Bus Encryption Engine which is capable of remapping addresses and enforcing access controls. You can see some info about its configuration on pages 367-374 and 377-380. Sadly, most details are in the security manual which NXP only provides under NDA, though a lot of that info is also in their SDK header files which are public.
You can also find mention of memory patch hardware, for example on page 186. Earlier versions of the reference manual showed more mentions. I've not seen any real documentation on it, even in the confidential security manual. It's entirely possible these chips don't have that hardware (but maybe some iMX6 or iMX8 do, and lingering mentions are just leftover copypasta from NXP's earlier documentation on those other chips). Or maybe 1062 has a silicon bug in it memory patch hardware which is "fixed" by deleting all documentation. But it's also entirely possible that sort of hardware is present and could be dynamically patching anywhere in the 32 bit address space.
It's also quite possible the special software isn't burned into the hardware at all. In fact, if I were to wager, I'd bet they probably don't put the special code into the chips at all. It very well could just be a collection of header files and either source code or compiled .o or .a files (likely provided under NDA) which you link with your application.
The software could also be an encrypted "binary blob" rather than normal .o object code or .a library archive. Theoretically, NXP could pre-burn the decryption key in the fuse memory and leverage some combination of the security features I've just mentioned, for you to embed a binary blob into your program and have its functions be callable (but not readable) from your code.
Truth is, I have absolutely no idea how they're providing that additional software. But I do know the hardware has many very impressive security capabilities which can dynamically remap, encrypt and enforce access controls to regions of memory. It's entirely possible NXP might use some technical feature I don't know exists & can't even imagine. If you're thinking of these chips as simple microcontrollers like old 8 bit chips, the range of abilities can be quite surprising.
I still have no idea whether those parts can work. Probably the only way to find out is to build a board and try them. But even that could be risky, as we'll soon be updating the bootloader to support encrypted flash, so if NXP is using special security features together with that special software, there's a risk of future compatibility issues as we support using some of that special hardware.
I'd really recommend going with the 1062 chip. Email us directly next week and we'll probably be able to help you with a small quantity to get your project going.