I have been looking for literature covering the mechanics behind a hypervisor/microkernel that explains how it works, the design behind etc but can´t find anything except published cs papers and wikipedia.
I'm very interested in this field and would like to know more, so im wondering if anyone could recommend any literature in this area? The closest that I can think of is books covering operating systems.
I´m mostly interested in the added security benefits a hypervisor can provide for a OS instead of the running several OS´s on top of a hypervisor.
Thanks!
The hypervisor topic is closely knit with the hardware used along with it.
So it is difficult to find out the hypervisor explanation without knowing hardware details.
So if the hypervisor is implemented on ARMv7, you need to look the hypervisor implementation along with the hardware support e.g. virtualization extension or security extension provided by hardware.
A good writeup is available on
genode web page
You will find article on security extension also there.
This documentation is targeted for ARMv7 hardware.
ARMv7 Cortex A : architecture reference manual will provide more details of hardware support required for hypervisor.
Related
For the TLE985x Infineon uses bitfields to map the registers in their library.
Since I'm am kind of new to embedded programming, I read about bitfields. Many of the articles mentiond bad effects of bitfield. Now the question is, when bitfields are somehow bad, why is Infineon using it in their library?
Thank you for your help
Whether to use the default register maps from the vendor or roll out your own is pretty much project-specific. If you have high requirements of portability and general source code quality, you have to make your own register map.
Some discussion on that topic can be found here: How to access a hardware register from firmware? As discussed in that post, the vendor has several reasons for rolling out their own custom, crappy register maps:
Makes debugging register maps easier, particularly when using a crappy debugger with no specific part support (such as the various Eclipse-flavoured ones). High quality debuggers like Lauterbach, iSystem, Crossworks etc do have part support and you can watch registers just fine in them, no matter how those registers were declared in C source.
Silicon vendors have absolutely no reason to make it easier for you to port away from their silicon to some other. Quite the contrary. Register maps are of course quite non-portable to begin with. But similarly, tool vendors don't want you to port to another compiler for the same silicon.
Silicon vendors are notoriously incompetent when it comes to writing firmware. This has been the case for as long as everyone can remember. I wouldn't point at any particular vendor here, they are all hopelessly bad at this.
What you could do however, in case of Infineon specifically, is to ask: "Hey guys, you seem to like automotive electronics a lot. The automotive industry has been using MISRA-C since 1998. How come you still don't provide MISRA-C compliant libraries in the year 2020? You don't want automotive customers to use your products?" Lots of amusing mumbling responses to be had.
I am trying to select a particular companies line of ARM Cortex M microprocessors to work with for a project I want to do. Since all the companies license the architecture from ARM Holdings I am wondering how much difference there can be in the hardware between brands? I am thinking the documentation and software productivity and overall experience may be the deciding factor?
I have tried one company and their documentation was lacking! Thousands of pages of fluff about what wonderful stuff they make but very little info on how to use the things.
Mostly I am looking for good documentation. I don't need endless obsolete sample programs that don't compile and use mystery macros and functions! A line that includes a microprocessor with 2 ADC not just multiplexing channels to 1 ADC would be good but I may end up using external ADC.
Would anybody care to say what they recommend and why.
BTW: My history is programming C++, C# in MS Visual Studio for machine tool HMI as well as motion controllers.
Thanks In Advance
Chris
Most of your application has nothing to do with ARM and the cortex-m. Each chip vendor adds its own peripherals (or sometimes purchased) around the arm core. Most of your code is talking to peripherals. The processor core doesnt make the chip, the things other than the processor core make the chip.
You need to go do your research, stackoverflow is not about doing it for you. You should be able to find a list of parts with the number of peripherals you want, independent of processor core used. While a particular chip vendor may have different uarts across their product line or different gpios, adcs, etc, you can still get a feel for a vendor without having to look at every part on that list as you narrow in.
No vendor has great docs, some do have bad docs, that is part of the exercise. All of them provide libraries, same deal nobody has great libraries, some have bad ones, but the point of the libraries is to hide the details. You need to do your homework and look at the docs, look at that code, can you live with it can you replace it or repair it, or is it better to move on to another vendor or same vendor and an alternate library.
1% of the job is writing the application the other 99% is reading docs and doing experiments to make the peripherals do what you want them to do.
Same brand or different brands with the same name of processor core doesnt mean anything with respect to portability. If you read the arm docs as you should read any of the processor core docs for whatever parts you are evaluating or choosing, you will see that even if 7 vendors have products with the cortex-m0, that core has compile time and runtime options that each vendor could choose from making either the code or the performance incompatible with other chips using a cortex-m0. But the amount of code that would port anyway is a very very small percentage of your project. Most of your project is the not-processor-core stuff.
Note ARM makes a number of cortex-m cores that are not 100% compatible with each other. If you feel the need to go with an ARM core, then narrow in on the one you want, that will narrow your choices as far as available chips goes.
Built in ADCs are there to save on chips, depending on the specs you want, accuracy or performance, you may very well end up with an external ADC which makes the specific microcontroller less important if the ADC and its specs are your primary requirement.
Software productivity, also has little to nothing to do with the processor core. The vendors are going to cobble together an IDE with a compiler and libraries because folks expect that, doesnt make any of them any good nor productive. The text editor alone goes the way of religion and politics with developers, there is no single editor or environment that is perfect for every developer, developers have their ways of doing things and some are compatible and some are not. Some developers can bend some cant. Very rarely do you have to use the tools they provide.
It is not possible for us to choose your part for you nor is it possible for us to choose your development environment. That is not the purpose of stackoverflow.
The time it took to write your question and wait for an answer thus far you could have looked at all the major vendors docs several times over. I hope you didnt stop after the first one.
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
I would like to model the behavior of caches in Intel architectures (LRU, inclusive, K-Way Associative, etc)., I've read wikipedia, Ulrich Drepper's great paper on memory, and the Intel Manual Volume 3A: System Programming Guide (chapter 11, but it's not very helpful, because they only explain what can be manipulated at the software level). I've also read a bunch of academic papers, but as usual, they do not make their code available for replication... even after asking for it. My question is, is there already a publicly available framework to model cache behavior? If not, is there a document detailing the behavior of caches from Intel at the deepest levels? I could not find one.
There are plenty of cache simulators out there, Dinero for e.g. (pun obviously intended) should be fairly simple and is often used for educational purposes.
Note that this simulator is trace-driven, it means it feeds on a list of memory access addresses, it doesn't know how to run a binary. You can produce such traces by emulating them with binary instrumentation tools, for e.g.
pin
qemu
bochs
etc.. Note that some of these offer internal cache simulators already, and may be possible to play with.
Other simulators can simulate full CPU/system behavior, not just caches, and can therefore support running a binary. Most of them include within them a simulated cache system. For e.g.:
gem5
simplescalar
multi2sim
marss86
and many others
On the other hand, writing your own cache simulator is fairly simple - if you can work on a memory trace (writing an actual fronend is way more complicated). You won't be able to get a too detailed spec on actual caches in Intel/AMD products, but the basic functionality is detailed in any computer architecture textbook or even wikipedia, the parameters (size, associativity, coherency policies) are mostly documented in the published guides, and may often change between product generations. You can always ask here if you encounter any specific question :)
Edit:
Regarding the second part of the question - there's no publicly available documentation of the exact cache implementation of Intel CPUs, but the dry "specs" (size, associativity, policies) are in the optimization guide:
Now, modeling these caches should be straightforward, but there may be some hidden caveats, like powerdown features or specialized LRU behaviors. One such reported example can be found here - http://blog.stuffedcow.net/2013/01/ivb-cache-replacement/ (if this is true, it might be worth implementing for accuracy), but aside from that I believe the overall behavior shouldn't be affected by these details too much, for any practical use.
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.