Pushing for Final Concept [HW base selected], Draft V2 dropped

A project log for IAMCIty = )

Secure IoT idea for “Intelligent Autonomous system for Monitoring and Control of Intersections” brought to life with #2015HackadayPrize

Dimitar TomovDimitar Tomov 06/07/2015 at 18:300 Comments

As professional activities took over my time fully past 2 weeks, my most sincere set goal for DraftV2 release had to be dropped, yet I'm going for the *Final Version of the Concept as I've made the next step - Selected a HW Platform - iMX6-SoloX*
You will see attached 4 Image at end of post - All are from the official Freescale Site for i.MX6SoloX, which follows - .

Fey Key Points "Why iMX6-SoloX is my choice for Hearth of #IAMCIty = ) ?"

0. Secure Solution:

FYI: Page Number 441 of total 4687 - Document Number: IMX6SXRM, Rev 0, 2/2015

Chapter "System Security" - Abstract of Security Features from Official Freescale Documentation 

High Assurance Boot (HAB) feature in the System Boot up to RSA-4096 signature
• Secure Non Volatile Storage (SNVS)
• TrustZone (TZ) Architecture in the ARM Cortex A7 Platform, TrustZone aware
Interrupt Controller (GIC) and TrustZone Watchdog Timer (WDOG-2)
• TrustZone Address Space Controller (TZC-380) - providing security address region
control functions on DDR memory space.
• On-chip RAM (OCRAM) with TrustZone protection using OCRAM controller.
• 32 Kbyte of on-chip Secure RAM
• On chip OTP (OCOTP) with on-chip electrical fuses
• Central Security Unit (CSU
• Resource Domain Controller (RDC)
• Secure JTAG Controller (SJC)
• Locked mode in the Smart Direct Memory Access (SDMA) controller
• DryICE (real-time monitors for frequency, temperature and voltage)
• 10 tamper pins with 5 active tamper detection sources support
• Hardware Cryptographic Accelerators
• Symmetric: AES-128, AES-192, AES-256, DES, 3DES, and ARC4
• Hash Message Digest and HMAC: SHA-1, SHA-224, SHA-256, SHA-384,
SHA-512, and MD-5Public Key RSA (up to 4096 bit) and ECC (up to 1023 bit)
• DPA protection for 3DES engine
• True and Pseudo Random Number Generator

*1. iMX6 SoloX is based on a known Series of MPUs with Known ARM Architectures*

1a. Known ARMv7 Architecture - Cortex-A9 for main MPU

1b. Known ARMv7 Architecture - Cortex-M4 for secondary MCU

*2. Freescale iMX6 as ARM Series, yet New SoloX are already known in some degree to me*

2.1 A lot of info & community

2.2 Have experience with Freescale's ways - Doc & BSP

2.3 ARM TrustZone - Secure & Non-secure world (just in a nutshell)

2.4 There's an MCU which can coup hopefully well , with the need of Real-time Operations (Capability)

*3. Image Camera Interface - More than 1 option, but there's a catch "optional analog camera"*

3a 24-bit RGB
3b 1ch LVDS
3c 2x20-bit CSI
3d Analog NTSC

4. Image Processing for iMX6, through the A9 core; is in focus.

+ I intend to use the HW acceleration available
+ Including ARM's NEON instructions
+ Every other DSP capabilities (instructions) present that can be of service to #IAMCIty = )

+ DPS & acceleration used through GNU Octave or some sort of Native C "sane madness"

Side note1: I do not intend to brute-force the DSP process with 1GHz ARM A9 Core.
Side note2: Goal is for efficient use & which means Optimization & Actual HW use.
Side-note3: Not just SW rolling on-top of some Hi-techy HW ;)

+ There's OpenCV as described in the AppNote, but that doesn't overlay with my Goals.

Pleas find link below for the AppNote mentioned:

IMO: Although If You look at the Freescale's Engineer Face - Perhaps that's not so straightforward solution :D Not a very smile face for an Engineer (generally) :P

Will use the A9 MPU to run Linux & run the Main Image Processing + Data Communication + Security on some Level (TrustZone further explanation). Then the M4 MCU will handle the Sensitive as Speed, Latency & again Security Operations, including actuators related operations.

For A9 there's TrustZone in place 100% , which is A very good thing ! :-)
For M4 TrustZone must be verified & if at all applicable as ARM's M4 IP do has some set of it AFAIK, it's ARMv7 ;-)

Cause for sure it was not my 1st, I wanted more Bare-metal M4, even M7 solution, but realism needed to take side in this idea of mine. Also support for iMX6 in Linux was put over an year ago - .

From here on I'm pushing to catch-up the delay of V2 + the actual 0 technical update what-so-ever for 1 month++ .
*Set Goal* - Update everything to *A Final Concept*
When - ASAP - This month (June) or early in the next (July)
*Follow-up step / Next Goal* - That *Final Concept* I'm going to start developing to an actual HW & SW.
When - Early next month at best.

*I will do my best to follow if ANY feedback comes from You guys*. Yet I must inform you that I'm about to undertake my job relocation this coming week. Hopefully will write my next update from Grenoble,France with even bigger smile from an even better mood after I've completed my relocation tasks :-)

Thank You for Your time & I do hope You will bare with me a bit more until there's actual Technical update so the "Big Picture" start to become clearer.

Dimitar Tomov


PS: For those of you & Only you who seek more explanation to why I could not manage to push my Draft V2 the week I set for it & in a Long story-short kind of way: Prof. & Personal Technical activities must not interfere , but also 1 must take precedence over the other. At this stage Prof. are the one that take over. Still things are looking very good & I strongly believe that I'll have more than enough time for the 17th August Deadline - from which point I have to set more time & develop a lot, which is my intend from the start. I felt that I own that ... explanation of sort , simply because when one man (any human i.e ) states something he must come through - Either way it's just words.