ARM-based commodity hardware without TrustZone? - mobile

Do you know embedded or mobile commodity hardware that integrate ARM-based processors and which does not support ARM's TrustZone? Do I have to assume that any commodity device (e.g. OMAP platform) which integrates a TrustZone-ready processor (Cortex-A9 and higher) automatically supports these seucrity extensions?
The hardware could integrate simple microcontrollers (Cortex-M) or more complex system-on-a-chip hardware (e.g. general purpose OMAP processors).
A few devices for which I am not sure whether they support TrustZone or TI's M-Shield are: LG Optimus 3D P920, LG Prada, Samsung Galaxy SI / SII, Motorola Droid Bionic, Motorola Atrix 2.

Related

Backwards compatibility of ARM ISA Versions (particularly when using QEMU w/ KVM acceleration)

I'm working on using QEMU w/ KVM acceleration to test various arm64 binaries. My host CPU is ARMv8.5 the guest CPU I'm trying to emulate is an ARM Cortex-A53 (ARMv8). Few questions:
Will these binaries be backward compatible and allow KVM acceleration? (this might be a yes and no)
Broadly speaking does ARM have any guarantees of backward compatibility? Doesn't seem like this is the case which makes trying to design a KVM-accelerated emulation system rather difficult.

ARM Architecture Initialization

In the case of x86 the same (real mode) bootloader works on virtually any x86 device.
Is that possible on ARM or do I need to create a specific bootloader for each 'cortex'?
x86 or lets say PC compatible systems are ... pc compatible. They support the ancient bios calls so that there is massive compatibility. by design, by the chip vendor (intel) the software vendors (bios, operating system) and the motherboard vendors.
ARM is in now way shape or form like that. There are instruction sets you can choose that work almost or all the way across, but remember ARM systems you buy an ARM core and add it to your special chip, you and your special/custom stuff, then that is put on one or more different boards. There is little to no compatibility. Instruction set and arm core is a small part of the whole picture most of the code is for the non-arm stuff.
u-boot and perhaps others are fairly massive bootloaders, pretty much an operating system themselves, and have to be ported just like an operating system to each chip/board combination. The chip vendor, if this is a linux compatible system, most likely has a reference design and a BSP including a u-boot port and/or some other solution (rasberry pi is a good example). it is fairly trivial to boot linux or used to be, there is no reason for the massively overcomplicated u-boot. without a DTB you setup a few memory locations a register or two and branch to the kernel, thats it (again look at the raspberry pi), I assume with DTB you build the dtb then put it somewhere, setup a few registers and branch to the linux kernel (raspberry pi? ntc chip?)
There is a Arm open source project that can cover Armv7/v8 Cortex-A processors bootloaders.
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/
Another open source project for Cortex-M processors:
https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/

DS-5 : What is FVP, RTSM, Foundation Model, AEM model, Fast Model, CADI?

DS-5 simulator uses a lot of terms like FVP, RTSM, Fast Models, Foundation Model, AEM Model, CADI. The explanation provided in Arm's documentation is not very clear. What do these terms mean and which ones should I care about as an end user of DS-5?
Model
An industry term for software simulation
In Arm's case, it is used interchangeably to either mean a component model (like a processor model) or an entire system/platform (like a VE FVP)
Fast Model
Software simulation of an individual component of a SOC like a processor or a peripheral
Usually provided as a shared library
Usually not seen by an end-user of DS-5.
Example: Cortex-A53 model.
Detailed docs - https://developer.arm.com/products/system-design/fast-models/docs
Cycle Models
Software simulation of an SoC including processor and peripherals
Cycle models are compiled directly from Arm RTL and retain complete functional accuracy
Instrumented to enable debug and analysis
Example: Multi-Cluster Arm Cortex-A53 with Coherent Interconnect, Interrupt Controller, Timer and UART
Virtual Platform (VP)
A virtual version of a real development board.
Usually provided as an executable.
Generic industry term.
Example: Android emulator
Fixed Virtual Platform (FVP)
Arm's term for its virtual platform.
Provided as an executable.
Not free, can be licensed from Arm.
Example: Quad-Core Cortex-A9 FVP, provided as part of DS-5, is not just a Cortex-A9 processor model, but a complete development platform containing Cortex-A9 4-core SoC simulation along with many peripherals.
Detailed docs - https://developer.arm.com/products/system-design/fixed-virtual-platforms/docs
RTSM
Stands for "Real Time System Model"
An old name for FVP.
The term RTSM is no longer actively used by Arm. They use FVP instead.
Foundation Model or Foundation Platform
A free virtual platform provided by Arm to kick-start Armv8 software development.
Minimal features - Only available on Linux, models a 'generic' Armv8 processor.
CADI
Stands for "Component Architecture Debug Interface" [Edited].
Arm specific term.
Simulator equivalent of the JTAG interface provided by real hardware.
DS-5 and other debuggers use CADI to talk to the Arm's virtual platforms.

Intel atom or ARM for heavy Signal processing workload

I would like to know which is a better (in performance) option :
To get a Intel Dual core atom based board
To get a Arm cortex A9 based board (pandaboard etc)
I would like to run some light version of linux and do some very cpu intensive
computations like Image/Video processing (maybe 3D later) and also process audio
on them. Of-course all floating point mathematics.
Definitely #2, Pandaboard is an OMAP4 platform.
OMAP4 contains not only the ARM Cortex A9 (which is not likely to compete on it's own with dual core Atom), but, and this is crucial, a full C674x DSP core, both floating and fixed point mathematics.
The embedded DSP core in OMAP4 is fully capable of handling 1080p H.264 decode, with some resources to spare. I'm yet to see an Atom platform capable of that.
(shameless plug - my company is using OMAP3 and evaluating OMAP4 for some of our niche markets, and we might be interested in assisting in yours as well)

.NET Micro Framework on a ARM Cortex-M3 Core

I have a RDK-IDM from Luminary Micro. This board has a 32-bit ARM® Cortex™-M3 core. Has anybody tried to run a .NET Micro Framework application on such a device?
I don't have any hands on experience but based on http://www.microsoft.com/netmf/about/gettingstarted.mspx The smallest footprint supported is 64kb RAM, 256kb Flash and MMU is not required. Therefore your applications needs would be the determining factor.
FYI: the .NET Micro Framework was released as Open Source under the Apache 2.0 License November 16, 2009
It seems that the LM3S6918 (The chip on the RDK-IDM) has only 256KB Flash and 64Kb SRAM but .NET Micro Framework requires 256KB RAM and 512K Flash/ROM!
Read more here
We have ported .NET Micro Framework to TI Stellaris MCU, ARM Cortex-M3 core,
currently we have a port for EK-LM3S8962 board, and it is working.
.NET Micro Framework Minimal memory footprint:
Flash: 155KB
RAM: 32KB
The cortex M3 is a very cut-down core, it lacks an MMU, for example, and is intended to run very simple operating systems. Specifically, not Symbian/Windows Mobile/Linux/etc. Rather OSEck, OSEK, iTRON, or similar. I think this is actually totally infeasible due to that.

Resources