I'd like to start playing with ARM TrustZone, so I'd like to setup a development environment, unfortunatelly I have the feeling I'm still missing something, I don't know how to put everything together.
This is my current picture:
A SoC with a Cortex-A processor is required
is it possible to develop without a board? i.e. emulators?
TrustZone is a Hardware & Software technology
If I get a SoC board, is the hardware part already covered?
The software (OS/Kernel) part may be solved with GlobalPlatform, OpenTEE, etc.
TrustedApplications development
Which IDE's are there?
How are they deployed to the board?
I know this is a quite extensive question, I'll be happy to get links to online material.
Edit:
Some parts of my question were partially answered, but the most important thing hasn't been answered yet: is the picture I detailed correct and complete? Yes/no, why?
And no, this is not a duplicate of Which ARM based development boards should I use?
For emulator, you can use ARM Fast Model (https://developer.arm.com/products/system-design/fast-models) if you have the budget.
QEmu might have some Trustzone support but I am not sure how reliable is the Trustzone implementation (What works on QEmu might not work on real hardware). joakim-bech (one of the lead engineer working on an Open-Source implementation of Trusted OS) said in his stackoverflow response it should work; And he has still confirmed it in the blog post TEE Development With No Hardware - Is That Possible?...
I would recommand you to have a look at the list of platforms supported by Optee - Open Portable Trusted Execution Environment: https://github.com/OP-TEE/optee_os#3-platforms-supported
The answers to your other questions would really depend of the platform you use, your budget, your development environment, etc
For less than $150:
If you want to stick to Windows you might have to build qEmu yourself (qEmu seems to support Windows but I am not sure if the Windows already-built binaries support Trustzone). In term of HW board, I use the Hikey board (currently at $119) for my Trustzone development.
Using Linux for the development will probably save you some time as for this budget you will probably have to use Open-Source solutions that generally primarily support Linux.
To start developing a Trusted App for OP-TEE:
I used this presentation: https://www.slideshare.net/linaroorg/lcu14103-how-to-create-and-run-trusted-applications-on-optee
I updated/improved the original example code, my changes could be found here: https://github.com/oliviermartin/lcu14_optee_hello_world
Related
I am a beginner in OpenCL programming. My PC has windows 8.1 with both intel graphics and AMD Radeon 7670. When I searched to download an OpenCL SDK and sample helloworld programs, I found that there are separate SDKs and programs in entirely different formats available. I have to use C not C++. Can anyone suggest which SDK I should install? Please help.
At the lowest level, the various OpenCL SDKs are the same; they all include cl.h from the Khronos website. Once you've included that header you can write to the OpenCL API, and then you need to link to OpenCL.lib, which is also supplied in the SDK. At runtime, your application will load the OpenCL.dll that your GPU vendor has installed in /Windows/System32.
Alternatively, you can include cl.hpp and use the C++ wrapper, but since you said you're a C programmer, and because most of the books use the C API, stick with cl.h. I think this might account for the "programs in entirely different formats" observation you made which is why I bring it up here.
The benefit of one SDK over another typically is for profiling and debugging. The AMD SDK, for example, includes APP Profiler (or now CodeXL) which will help you figure out how to make your kernels faster. NVIDIA supplies Parallel Nsight for the same purpose, and Intel also has performance tools.
So you might choose your SDK based on the hardware in your machine, but understand that once you've coded to the OpenCL API, your application can run on other GPUs from other vendors -- that is the benefit of OpenCL. You should even be able to get samples from one vendor to execute on hardware from another.
One thing to be careful of is versions: If you code to an OpenCL 1.2 SDK you might not run on OpenCL 1.1 hardware.
For me the best thing with OpenCL is that you do not need an SDK at all because it abstracts different Vendor implementations behind a common Interface (see Answer in this Thread: Do I really need an OpenCL SDK?).
I'd like to develop a network based application for the Arduino platform. The examples shipped with a Wi-Fi Shield library are all multifile sketches with a network part implemented in C. I'd like to figure out how to implement the network portion in a way regular C/C++ development is conducted (with a decent IDE and step-by-step debugger).
I noticed WiShield is build on top of the uIP library ((an open source full TCP/IP stack implementation for resource-constrained embedded devices)) and greatly influenced by it. Smart folks implemented DHCP and zero configuration implementations on top of it. How do people execute projects of such complexity and what tools are being used?
Are you looking for some Arduino emulator? I think these two should get you started.
Emulino
Simavr
Use the simple programming software that can easily work with arduino chips but don't make your project in complex situation putting some complex programs.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I have to choose a thesis topic soon and I was considering implementing an operating system for an architecture that is not x86 (I'm leaning towards ARM or AVR). The reason I am avoiding x86 is because I would like to gain some experience with embedded platforms and I (possibly incorrectly) believe that the task may be easier when carried out on a smaller scale. Does anyone have any pointers to websites or resources where there are some examples of this. I have read through most if not all of the OSDev questions on stack overflow, and I am also aware of AvrFreaks and OSDev. Additionally if anyone has had experience in this area and wanted to offer some advice in regards to approach or platform it would be much appreciated.
Thanks
Developing an (RT)OS is not a trivial task. It is very educational though. My advice to you is to start hardware independent. PC is a good starting point as it comes with plenty of I/O possibilities and good debugging. If you create a kind-of-virtual machine application, you can create something with simple platform capabilities (console output, some buttons/indicators are a good start). Also, you can use files for instance, to output timing (schedules) If you start on 'bare metal' you'll have to start from scratch. Debugging on a LED (on/off/blinking) is very hard and time consuming. My second advice is to define your scope early: is it the scheduler, the communication mechanisms or the file systems you're interested at... ? Doing all can easily end up in a life long project.
Samek, Miro, Practical UML Statecharts in C/C++ contains some interesting sections on a microkernel. It's one of my favorite books.
Advanced PIC Microcontroller Projects in C: From USB to RTOS with the PIC 18F Series
seems to cover some of your interests; I haven't read it yet though. Operating Systems: Internals and Design Principles may also bring good insights. It covers all aspects from scheduler to network stack. Good luck!
Seems like you should get a copy of Jean Labrosse's book MicroC/OS.
It looks like he may have just updated it too.
http://micrium.com/page/press_room/news/id:40
http://micrium.com/page/home
This is a well documented book describing the inner workings of an RTOS written in C and ported to many embedded processors. You could also run it on a x86, and then cross compile to another processor.
Contiki might be a good thing to research. It's very small, runs on microcontrollers, and is open source. It has a heavy bias towards networking and communications, but perhaps you can skip those parts and focus on the kernel.
If you choose ARM, pick up a copy of the ARM System Developer's Guide (Sloss, Symes, Wright). Link to Amazon
Chapter 11 discusses the implementation of a simple embedded operating system, with great explanations and sample code.
ARM and AVR are chalk and cheese - you've scoped this very wide!
You could produce a very different and more sophisticated OS for ARM than AVR (unless you are talking about AVR32 perhaps - which is a completely different architecture?).
AVR would be far more constraining to the point that the task may be just to trivial for the scope of your thesis. Even specifying ARM does not narrow it down much; low-end ARM parts have small on-chip memories, no MMU and simple peripherals; higher end parts have an MMU, data/instruction caches, often a GPU, sometimes an FPU, hardware Java bytecode execution, and many other complex peripherals. The term 'ARM' covers ARM7, ARM9, ARM11, Cortex M3, Cortex M8, plus a number of architectures intended for use on ASICs and FPGAs - so you need to narrow it down a bit perhaps?
If you choose ARM, take a look at these resources. Especially the Insider's Guides from Hitex, and the "Building bare-metal ARM with GNU", they will help you get your board 'up' and form starting point for your OS.
Silly as it may sound, I was recently interested in the Arduino platform to learn some hacking tricks with the help of more experienced friends. There was also this thread for a guy interested in writing an OS for it (although not his primary intention).
I think the Arduino is very basic and straightforward as an educational tool for such endeavors. It may worth the try checking it out if it fits the bill.
The first thing I recommend is to narrow your thesis topic considerably. OSs are ubiquitous, well researched and developed. What novel idea do you hope to pursue?
That said, the AvrX is a very small microkernel that I've used professionally on AVR microcontrollers. It is written in assembly. One person started to port it to C, but hasn't finished the port. Either finalizing the port to C and/or making a C port to the AVR32 architecture would be valuable.
An OS shall not be tightly coupled to any processor so ARM or x86 doesn't matter.
It will be a bigger topic, if we start discussing if ARM is embedded and x86 is not. Anyway, there are many many places in which x86 processors are used for embedded software development.
I guess most of the kernel code will be just plain C lanugage. There are many free OS that are already available, like for example, embedded linux, Free version of Itron, minix, etc ... It will be a daunting task.
But on the other hand, what you can try is, port embedded linux to platforms in which it is not yet working. This will be really useful to the world.
An RTOS is almost never architecture specific. Refer to any RTOS architecture available on the net and you will notice that a CPU/Hardware abstraction layer abstracts out the CPU. The board specific portions (that deal with peripherals such as com ports, timers etc.) are abstracted by a board support package.
To begin with, get an understanding of how multi-threading works in a RTOS try implementing a simple context switch code for the CPU of your choice; this will involve code for creating a thread context, saving a context and restoring a saved context. This code will form the basis of your hardware abstraction layer. The initial development can easily be accomplished using a software simulator for the selected CPU.
I agree with the poster who suggested reading the book, uCOS-II by Jean Labrosse. Samples of context switch code, especially for x86, should be just a google search away!
http://www.amazon.com/Operating-Systems-Design-Implementation-3rd/dp/0131429388
Pretty solid stuff.
Next term, I'll need to write a basic operating system for Motorola 68K processor as part of a course lab material.
Is there a Linux emulator of a basic hardware setup with that processor? So my partners and I can debug quicker on our computers instead of physically restarting the board and stuff.
Is it possible to apply test-driven development technique to OS development? Code will be mostly assembly and C. What will be the main difficulties with trying to test-drive this? Any advice on how to do it?
I would recommend developing an operating system for the classic Amiga computers, which had different versions of the 68000 processor. Since the Amiga computer is a complete computer and is extremely well documented, I thought this would be a good exercise.
There is an emulator for it called UAE (and Win-UAE) which is very exact and
can be configured with different kinds of processors (68000 - 68060) and other capabilities. Normally, you would also need to acquire ROMs for it, but since you are developing an operating system yourself, this is not necessary.
Tools you will need is either Cygwin (for developing under Windows) or a Linux computer. Then you will need cross compilers. This includes both a C compiler and an assembler. Here is a template for creating a simple ROM which changes screen color and flicks the power LED. It will create a file 'kick.rom' which UAE then searches for in the current directory.
Reference on the 68000 instruction set can be found at the links below. Be aware that different assembler programs may use slightly different syntax and instruction set.
If you need to demo the operating system on real hardware, there are modern Amiga clones sold on Ebay and other places. Search for "Minimig".
Update:
Nowadays AROS also runs on UAE as well as physical Amigas.
Refs:
[UAE]
[WinUAE]
[Cygwin]
[Cross Compilers]
[68000 reference]
I would suggest QEMU for m68k emulation.
(The system emulator you want in QEMU is "Coldfire" - that's what Freescale calls the successor to the m68k architecture).
You certainly can tdd this project. First off decouple all accesses to the hardware with simple routine calls, e.g. getch() and printf, then you can provide simple mocks that provide test input and check output. You can then write well over 90% of the project on a PC using gcc, msdev or xcode. Once you have got some confidence in the decoupling routines you will need very little access to the hardware, and only then to occasionally check that your mocks are acting as you expect.
Keep to C until you find a particular bottle neck, and only then resort to assembler.
There are a few new projects that use hardware simulated 68000 cpus, the C-One project, the Minimig (Mini Amiga) project and the Natami (Native Amiga) project - they are new 68k compatible Amiga systems.
C One, reconfigurable computer, Minimig, in development, prototypes done: FPGA Arcade and Natami.
The Easy68k http://www.easy68k.com simulator might help you.
The uClinux project started on a m68k board. They may have the tools you need...
I would like to ask a few questions regarding mobile game porting...
Let say if I have a simple 2D C++ game engine and have a PC game based on that engine and I want to port it to different mobile platforms BREW, J2ME, iPhone, Android, Symbian, etc..
Do I need to re-code the engine and the game for each platform? or is there an easier and more efficient way? I am sure the process is complicated since different phones have different graphic/processor/memory/etc. I am just curious about the overview of mobile game porting process. :)
Thanks!
There are several ways of attacking mobile game porting. First of all, until very recently it was mostly BREW and J2ME. The iPhone, Android and BlackBerry are changing this landscape and making the impossible task of mobile game porting even more impossible. I worked in 3rd party mobile game development for many years until recently. I watched BREW vanish and saw publishers completely focus on J2ME as the cost of porting is strangling the industry. There are estimates to its cost, both time and money, and it seems to bell curve around 50-60% of the total development cost for each game is just porting.
At our company, we handled porting by having two engines that paralleled each other, one in BREW, one in J2ME. We never supported Symbian as Symbian development does not make any money. It is mainly for high-end tech demos that might be on one or two devices, nothing that could reach the mass market. Plus, most Symbian phones supported J2ME.
We would be required by publishers to provide any where from 7-23 reference builds of the game, targeting many different devices, in both BREW and J2ME. Just before moving on, publishers were also starting to require a J2ME touch screen reference version, and an iPhone SKU was being left as "to be determined" based on the final product and how cost effective an iPhone version would be at that time. The reference versions would then be passed on to a porting house to translate the different references to the thousands of other required SKUs.
Companies like Gameloft still brute force their way through porting. That's why Gameloft's games are constantly at a higher quality than the rest of the industry. However, it is just not possible for smaller companies to attack the problem this way due to costs. Not everyone can afford an office in Beijing with 5000 developers.
There are many companies out there developing engines to cut porting costs. Mobile-Distillery is one I was in contact with quite a lot, but we ended up never using it. So, I can't vouch for them. The problem here is that you will be at the mercy of another companies engine. Performance could be problematic due to the fact that it is being built to target thousands of SKUs. Plus, you really have little control over the low level implementation of your game in this instance. The end result seems to be a game that targets the lowest common denominator of phones.
Finally, a lot of developers are just abandoning the idea of supporting all mobile platforms. There is a huge flood on games on the iPhone because 1) it requires only targeting one platform and 2) there is a 70 percent profit share through the AppStore for developers. Through carrier releases, the percentage is not even comparable.
This of course depends on in which language your "simple engine" is written. Java is supposed to be easier to move between platforms, since it in effect is a platform of its own. If your engine is written in something more low-level, like C++, it will likely depend on platform-specific libraries for graphics and input, since C++ doesn't provide you with that.
I can personally recommend edgelib as a cross platform layer for mobile games and application development.
It is widely used, offers excellent performance and supports most of the important smartphone platforms in existence today: Symbian, Win Mobile, IPhone and others.
Most important: It's cheap and offers a free complete evaluation until you decide to produce commercial content with it.
You can find it at: http://www.edgelib.com
You can see a showcase of games and other projects based on this platform at the site.
Unfortunately, BREW is not supported though. And since it isn't a real open platform, it poses quite a challenge compared to other mobile OS platforms as it's development community is mostly professional and not very "talkative" in online terms...
This will perhaps change as the competition is getting more open by the minute.
I am not affiliated with Edgelib... this is just my personal opinion. :)
There is no free lunch. The platforms you are considering are not compatible, most of then allow you to run C/C++ code so in theory you could port the engine to some Standard, such as ANSI, or C99 and it would compile in most of the platforms PC, BREW however this does not take in account the libraries your engine might need. For example if your engine uses OpenGL then it would work in the PC, and some consoles but on Symbiam devices you need OpenGL-ES which is not exactly the same, so you need an abstraction for all libraries you use.
About J2ME and Android they are Java platforms, so no C/C++ can be run there without any special VM lib at least. In this case you need to port the C/C++ code to Java which can be overkiling.
So my answer to this is while you can make an abstraction to your libs and code using standards you might be able to use the same engine in several platforms as long you can use the same compiler for them.
Take a look for example to this engine CubicVR it allows you to compile the same engine for PC/Linux/MAC/iPhone (maybe)/Sony PlayStation Portable
What I have used for multiplatform development is to implement a hardware abstraction layer. The engine is coded in C++ but using a plain C interface to implement the system calls. This allows you to use full-fledged C++ for your game and engine and link with the system abstraction written in whatever language your platform needs. Symbian doesn't support 100% of the features of C++, and still has a few bugs, and IPhone API uses Objective C. C is compatible which most of the platforms you mention (well, not Java) and linking C is easier than C++, as there are less problems (ABIs and all that stuff).
Implementing a additional interface in C is a little slower, but will help you a lot when porting it to other platforms. Also, it allows you to have a Win32/Linux/Mac build besides the Symbian, BREW, etc. one. I have worked, mainly, with Symbian and N-Gage, and the debugging capabilities of those platforms are signifficantly behind Visual Studio or GDB. Iphone, on the other side, has a lot of cool tools to debug and profile your app.
If the engine you have is not written in JAVA or FLASH I don't see a way that you can use your engine out of the box without recoding it in a language which might run on a mobile phone.
If it is coded in JAVA or FLASH, I think you're main problem (beside the performance difference between a phone and a pc) is the main memory. As I've heared, the main memory is the biggest problem in mobile phone game development.
As others have pointed out, if your engine is built on top of some 'platform independent' framework such as Java, then it's supposedly easier than if it's written in a lower level language. However, neither Java nor Flash is, for example, supported on the iPhone/iPod touch, and it'll probably take a while until they are. On the other hand, if I recall correctly, the only SDK available for those platforms is Objective-C, which, guessing wildly, you didn't use to implement your engine.
In general, it depends on the application/game engine you've written. Most likely you'll have to change something, as very rarely are all features available on all platforms. J2ME graphics is a classic scenario of 'platform independent'-dependence, or so I've heard. How much you'll have to change solely depends on how portable your code is, i.e. how well did you separate out the parts that potentially need changing.
Unfortunately, this is the best answer I can give you.