I have a requirement to use a specific version of the Eclipse IDE, and I want to know how to tell what version of DS-5 I need to download to get the Eclipse version I need. I need to have Eclipse IDE for Java Developers – Juno SR1 Package. Please let me know if I should provide additional details.
I also need to somehow run the download even though I am currently enjoying the latest version of ds-5; it is in the 30day evaluation period. What is the best way to proceed please? What are my options?
Regards-
Sean
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
Good Evening Matt,
Thanks this is exactly what I needed. I'll try the community edition, and will keep in touch. I'll keep your other suggestion above in mind also. Re: the restriction comment - it is due to what Qualcomm's debugger supports.
Thanks
Hi seanans,
I checked out the Qualcomm debugger package and it seems to require a MUCH older version of Eclipse than we currently support. CDT 4.1.2 was a very long time ago! I was wrong in that we're actually using Luna (not Juno) in DS-5 5.21 and DS-5 5.22. I am not sure which version the last DS-5 to use Juno SR1/SR2 was but it might be back in the DS-5 5.17 range.
You might have more luck asking Qualcomm to update their debugger, to be honest.
Thanks,
Thanks. You do not know how much it means to receive the follow up email from you. In addition to the Eclipse version mismatch, there exists the challenge of not being able to a compiled executable from the user space. I am still learning about what are the differences between ARM specifications of its Trust Zone technology, and what Qualcomm and Samsung implemented for my target platform. There seems to be differences at every level, and not limited to TEE alone, which require the documentation. If you know of any documents, or content which explains the differences between the two I would greatly appreciate it. For instance, ARM implements Cortex cores or instruction set while I believe Qualcomm Snapdragon uses Krait? I love to get more detailed information on what are the similarities and differences between the two hardware architecture. Can I rely on the instruction set to be the same? What about the starting address of different system and subsystems? Again, I like to thank you for the email. I am posting messages on the Qualcomm forums also.
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.
Matt,
Thank you so much. You, and the rest of the ARM support team, continously surpass my expectations in terms of support. I am so appreciative. This is exactly what I needed; what I can count on in terms of fuctionality and what I need to potentially validate. Thank you; thank you so much for this amazing reply.