Teensy 4.0 Boot loaders (USB-MSD, SREC, Kboot-HID, SD card) with AES256 encryption

uTasker

Well-known member
Hi All

The following is a boot loader that can be installed on the Teensy 4.0:
https://www.utasker.com/iMX/Teensy_4.html
to allows it to load new code via USB-MSD, serial SREC (on LPUART3), using NXP's Kboot USB-HID tool or from an SD card.

It is AES256 encrypted in QSPI flash and also the new code loaded via the loading methods can be AES256 encrypted so that no one can reverse engineer it by reading it from the QSP flash.

There is a reference application that can be tested (in plain text and AES256 encrypted forms, whereby the loader accepts both) that demonstrates USB-MSD and USB-CDC composite HW USB device and SD card operation (when there is an SD card socket mounted) allowing the Teensy 4 to operate as a pen drive to a USB host with access to the SD card. Furthermore it always appears as a second hard drive to the PC with emulated FAT content that shows snap shots of the complete QSPI flash content, the instruction RAM content and the data RAM content.
On the USB-CDC interface (and on LPUART3 at 115'200Baud) there is a command line menu which supports various commands, such as a DOS like command line interface to the SD card, commands to view, write and erase data in the QSPI flash, command ports and save parameters to an area of QSPI flash. It allows commanding a LPUART3 to USB-CDC bridge, etc. etc.

The loader is usable with Teensyduino projects by linking the project code to the address 0x00000300 (for execution in instruction RAM) - interrupt vectors are to be copied by the code to the instruction RAM area beginning at 0x00000000. The image can be optionally AES256 encrypted by using the uTaskerConvert utility at https://www.utasker.com/forum/index.php?topic=1445.0 to securely protect it when distributing new firmware versions.

The boot loader also dynamically partitions the FlexRAM in the i.MX RT 1062 to suit the application size (allocating just enough banks to fit the application in instruction memory and allocating all remaining ones to data memory). This achieves maximum performance since code and data are accessed at full speed without wait states. The QSPI flash is powered down when not used by parameters or file system and so optimal power consumption, with no radiation due to external QSPI code accesses once running.

Regards

Mark
 
Some questions:

- Where is the sourcecode?
- Does the PJRC Bootloader still work?
- Does the 15-Second restore still work?
- Does a Teensyduino program need to fit into the RAM now? Or can we still use the FLASH, too?
- Teensyduino partitions the RAM, too, in a similar way you described - how does that work together with your bootloader? If the memory map is different - can you show it?
- Can you give detailed examples how to work with your Bootloader AND Teensyduino? (Together with the needed linkerscript)
 
Put on three alternate T4's with working SDIO under Arduino {loglow/frdm/PJRC_BETA} - none could mount an SD card - err -3. HEX upload worked then dropping the BIN on the exposed explorer device had it uploaded and executed. LED blinking and Serial4 debug output works - but no commands work it seems when card fails to mount? I saw a typo in one of the first T_4 web lines where it has a .1 for model number?

15s Restore still works - I wiped all three I did afterwards. On one I uploaded a SD sketch and it read the card just fine.
And it seems PJRC TeensyLoader still works - it just wipes the uTasker bootloader that resides in FLASH for booting.

… Frank's other questions seem interesting …
 
Hi

I have updated the binaries after performing better testing, whereby all loading methods have been verified (originally the operation had been simulated but not fully tested on HW since the SD card test socket was not ready). Also the LPUART3 Rx line was mis-configured, which stopped command line communication (USB-CDC communication was used during initial testing and so this was missed).

Therefore:
- SD card operation should be good (physically verified) - I think that there is also a small error in the Teensy 4.0 circuit diagram SD_B0_04 (pin H2) is marked as DAT3 and SD_B0_05 as DAT2 but I believe these should be marked as DAT2 ad DAT3 respectively (according to NXP documentation)
- Command line operates on LPUART3 completely and on USB-CDC

Typo on web page corrected (the code is also available for Teensy 4.1 but the question is whether there will be two pages or ine shared by the both - does the Teensy 4.1 physically exist at the moment?)

Finally, the operation is just an application to the Teensys 4.0 and so it won't interfere with loading or recovery in any way.

Regards

Mark
 
I guess Paul has some T4.1.
Can you answer the remaining questions? Esp, the linkerfile, and possible interference with RAM partitions and usage of data in flash.

And a link to the sourcecode, please.
 
Some questions:

- Where is the sourcecode?
- Does the PJRC Bootloader still work?
- Does the 15-Second restore still work?
- Does a Teensyduino program need to fit into the RAM now? Or can we still use the FLASH, too?
- Teensyduino partitions the RAM, too, in a similar way you described - how does that work together with your bootloader? If the memory map is different - can you show it?
- Can you give detailed examples how to work with your Bootloader AND Teensyduino? (Together with the needed linkerscript)

- Source code is generally available at https://github.com/uTasker/uTasker-Kinetis but presently only for Teensy 3.1, 3.2. 3.5 and 3.6. Teensy 4.0 will probably be published for open-source use at a later point. Present Teensy 4.0 (and NXP evaluation boards and Embedded Artists OEM boards) source code is on a private GIT repository to which accounts are available for co-operating developers and partner companies and some educational institutes.
- The operation doesn't have any effect on the PJRC bootloader but I am in the process or clearing up the implications of activating even stronger protection based on BEE and there is a risk that that may not be possible (to see): https://forum.pjrc.com/threads/60247-Can-enabling-the-BEE-eFUSE-cause-problems-with-the-Teensy-4
- Restore is not affected.
- This specific configuration assumes that application code fits into internal RAM (max code size up to about 512k) but the loader concept can work from any memory type, including XiP- it is configured accordingly.
- RAM memory map for variables is starting at the beginning of DTC - I use the following applications, whereby code is located to ITC:

MEMORY
{
SPI_FLASH (rx) : ORIGIN = 0x60000000, LENGTH = 0x00200000 /* 2M FlexSPI Flash Flash */
SRAM_DTC (rwx) : ORIGIN = 0x20000000, LENGTH = 0x80000 /* 512K bytes (data RAM) - note that maximum physical use of DTC and ITC is limited to 512k */
SRAM_ITC (rwx) : ORIGIN = 0x300, LENGTH = 0x80000-0x300 /* 512K bytes (instruction RAM) - interrupt vectors located here */
SRAM_OC (rwx) : ORIGIN = 0x20200000, LENGTH = 0x80000 /* 512K bytes (general purpose RAM) */
}


When the reference application starts up the flexRAM configuration assigned to the application is shown on the debug output:

Hello, world... TEENSY 4.0
Static memory = 0x000011a0
OS Heap use = 0x03b1 from 0x7800
Initial stack margin 0x000674cc
FlexRAM:
2 Code banks [0x00000000..0x0000ffff
14 Data banks [0x20000000..0x2006ffff

uFileSystem integrity
OK
Disk E mounted
SD-card V2 - High Capacity

Disk D mounted
Enumerated (1)


- I can't yet give any details since I only received my Teensy 4.0 on Friday and so have only had time to port the loaders and application to the board during the the last couple of days; I haven't had any time to write detailed documentation or make video guides yet.
I did develop guides for Teensy 3.x users - see appendix B of https://www.utasker.com/docs/uTasker/uTaskerSerialLoader.pdf and https://www.utasker.com/forum/index.php?topic=1869.0 and most bear true for Teensy 4 usage, with possibly a few small details to be encountered on the way. It is not rocket science and I expect anyone with a little experience of coding to be able to do it anyway (the exact application that runs is not constrained by the loader - any code can be used as long as it is correctly located. Since I don't work with Arduino for my usual work I will probably do this together with someone who requires the functionality for a real project when they demand it - I usually do remote desktop sessions with such people to quickly identify what may need to be modified.

Regards

Mark
 
Back
Top