eclipse version

If I understand your question correctly, you are looking to import DS-5 in to an existing Eclipse? Is that correct? Or Are you looking at a DS-5 version that ships with Eclipse -Juno version?

You may be able to simply follow the instructions here:

http://ds.arm.com/ds-5-community-edition/

http://ds.arm.com/ds-5-community-edition/getting-started-update-site/

The "Community Edition" is almost the full DS-5, but without a license and missing a few components. If you have a DS-5 Professional or Ultimate Edition (or an Evaluation of either) license you can enter it into the ARM License Manager (Help menu) and unlock the full-featured tools. The latest version of DS-5 runs on Juno SR2, and should work fine on Juno SR1.

If you find that you're missing something important, then it may be that the Community Edition package simply won't work for you - in this case, is there any reason you couldn't use Eclipse and DS-5 side by side? You can build in your required SR1 environment and debug by simply opening the same workspace (once you've quit the previous) in Juno SR2. Also, why would you be so restricted in the version of Eclipse?

Ta,

Matt

ARM's specification of TrustZone is in the ARMv7-A/R Architecture Reference Manual, covered by any section which talks about "Security Extensions." The essential components have to be there for architecture licensees like Qualcomm to have ARM sign off on whether this is an Architecturally Compliant core or not (otherwise ARM bears the risk of there being this weird almost-ARM core in the world). In that sense, you can rely on the instruction set to be absolutely identical, although some co-processor accesses might be slightly different, if they say they support it.

The starting address of different system and subsystems would be different for every SoC - ARM don't define a memory map, really, beyond the standard vector base addresses (0x00000000 and 0xFFFF0000); although some architecturally defined components should have a similar - if not identical - register mapping starting from those SoC-dependent base addresses.

Essentially, the Security Extensions cover a few registers, the banking of those registers based on current value of the SCR.NS bit, the MON(itor) mode, and the behaviours associated with those registers and modes (including the SMC instruction). Outside the core, more needs to be implemented -- the "Secure" part of the Security Extensions is that the Non-Secure and Secure worlds can't interact through memory locations marked Secure. The Secure world -- with translation table descriptors marking memory locations as Secure -- has it's own entirely separate Virtual address space and also a theoretically separate Physical address space. The Architecture defines how those are managed, too, in terms of caches and so on, so you can get an assurance that it is secure per the architecture no matter who implements it.

Outside the core it is less clear cut from a design perspective -- if it's an ARM core with an AMBA bus (AXI for example) then whether a memory access is Secure or not is a protection bit on the bus (AxPROT[1], for example), and on a 32-bit addressed bus it could be thought of as a 33rd address bit to split up those two theoretically separate Physical address spaces. SoC-specific peripherals receiving those transactions should be able to arbitrate whether they can service an address with one or the other protection bit setting. On a non-AMBA bus -- Qualcomm, for example, are free to implement whatever bus architecture and protocol they like as long as it meets the demands of the ARM Architecture -- it could be a different methodology and protocol to determine security of transactions, a raft of bits or some other signalling or a whole other port from the core on a completely different bus, but it still has to be respected for it to work properly.

That protection bus mechanism may be further controlled outside the core by some kind of security controller IP which is configurable, but this is also outside the space ARM defines. Every SoC vendor has their own, and this is probably the bit you really need an NDA from the SoC vendor to get hold of the programming mechanism for that component. ARM has a couple, though, the TrustZone Address Space Controller, which are publicly documented, and several System MMU components which can modify security attributes, and if you're lucky the SoC vendor will have used one of them. Note that ARM also defines the Generic Interrupt Controller (GIC) Architecture, which is relevant -- most vendors use it, or have implemented something which complies with the architecture, and there are some security implications required to be tended to when using it.

Ta,

Matt