I'm doing a project in C language that runs on a target with vxWorks operating system.
I would like to run my code on PC also for two reasons:
The HW of the target is not available yet, and i want to start testing my SW.
Even when the target will be ready it will be easier for me perform testing and simulations on a PC.
Is there some interesting way to do it?
Thanks.
You have three choices:
Use the VxWorks Simulator (vxsim) - it's part of the Workbench and can be accessed like a real target
Pros:
Easy to to use
Integrated into workbench
Debug functionality and good control of the system
Doesn't need any further hardware
Documentation (check Wind River VxWorks Simulator User's Guide)
Cons:
Not the real target system (but this is a con for all points here)
Use a x86 machine and boot eg. through ftp
Pros:
You can test booting via network and network
Cons:
The system may lack of drivers
Possible you have to change kernel
Debug is not as good as vxsim
The difference to your target may be realy big
Use a Virtual Maschine
Pros:
Runs on same pc - no further hardware required
Possible to test several bootloaders
Cons:
Not possible to simulate the target cpu etc.
A VM is not the best way for VxWorks testing
As Archie, I recommend you the VxWorks Simulator too.
A third way is to abstract the HW and OS in a separate layer in your application architecture, and provide both a PC and VxWorks versions of this layer.
This is rather costly, of course, but will have other advantages, i.e. insulation from vendor instability (like when pSos support was stopped years ago...) It might also nudge you in the direction of a nice, layered architecture.
Related
Since syscall emulation is much easier to setup, I'm wondering what are the advantages of using the full system emulation when running an userland program.
Or in other words, what interesting aspects are modeled in the full system but not syscall emulation mode, and when are they significant?
It is mentioned in the docs at: http://gem5.org/Splash_benchmarks that full system is
Realistic: you're getting the actual Linux thread scheduler to schedule your threads
Is this the only advantage, or are there any other advantage for users that are optimizing their applications or investigating micro-architecture?
I also suspect that the MMU simulation is another important feature that is only modeled properly in full system mode, and could affect program performance.
Full system mode should be preferred (when it is possible to use it). There are benefits to using it, primarily fidelity in the simulation which is not possible with system call emulation mode. (The kernel interactions with an application can be important depending on the study that a researcher is trying to conduct.) Also, the user does not need to worry about implementing (or debugging) the system call implementation.
With that said, system call emulation mode can be useful under the right conditions. It is faster to run application code because there is no kernel running in the background. There is also no system noise if you want to mitigate it entirely. Arguably, it is easier to bootstrap a new device model as well. You can work on the model without driver support and make magic happen though fake interfaces. (It saves you having to model the bare-metal interface perfectly or having to write your own device driver.)
Your comments about dynamic linking and multi-threading support are related. If dynamic linking is fixed, you should be able to use your system's pthreads library and can forget about linking with m5threads entirely. The pthread library support has existed in the simulator for a while now (the system calls necessary for it to work properly).
However, there's a caveat to the threading implementation. You need to preallocate enough thread contexts at the start of simulation (by invoking with the -n option on the se.py script).
To elaborate, there is no operating system running in the background to schedule threads on the processors. (I use the terms threads and processors very loosely here.) To obviate the scheduling problem, you have to preallocate enough processors so that the threads can be created on calls to clone/execve. There is a constraint that you can never have more threads than processors (unlike a real system where the operating system can schedule them as it pleases).
The configuration scripts probably do not behave how a researcher would want them to behave for a multi-threaded workload. The researcher would need to verify that the caches were configured correctly and that they are sharing certain cache levels like a real machine would do. If the application calls clone/execve many times, it may not be possible to cause the generated configuration to behave realistically.
Your last statement about modeling accelerators is incorrect. The AMD GFX8 model does use system call emulation mode. (Also, we developed a NIC model which was never publicly released.) It involves creating a fake driver and manipulating it through the same ioctl interfaces that a real driver would use. Linux treats everything like a file so the driver is opened through the open system call interface and you can capture it there. There are other things which you might need to do (like map mmio ranges in the configuration), but the driver interface is the main piece. The application interacts with the driver and the driver interacts with the accelerator model.
Advantages of SE:
sometimes easier to setup benchmarks, if all syscalls you need are implemented (see also, see also), and if you have just the right cross compiler, which of course no one has documented properly which one that is.
SE runs Dhrystone about 2x https://github.com/cirosantilli/linux-kernel-module-cheat/tree/00d282d912173b72c63c0a2cc893a97d45498da5#user-mode-vs-full-system-benchmark That benchmark makes no syscalls (except for information before / after the actual benchmark runs)
it is easier to get greater visibility and control of what the application is doing since the kernel is not running in parallel. E.g. stats will be just for the application, GDB will be just for the application: thread-aware gdb for the Linux kernel
Disadvantages of SE:
in practice, harder to setup benchmarks, because it is too fragile / has too many restrictions.
If your content does not work immediately out of the box, it is easier to just create or download a full system image and go for that instead, which is much more reliable.
Here is a sample minimal working Ubuntu setup if you are still interested: How to compile and run an executable in gem5 syscall emulation mode with se.py?
less representative, since no actual OS is running
no dynamic linking for ARM as of June 2018: How to run a dynamically linked executable syscall emulation mode se.py in gem5?
if you want to evaluate an accelerator like a GPU, you will have to create some slightly custom interface for it, since there is no kernel driver running on top the the kernel as usual.
Brandon has pointed out in his answer that this has in fact been done before: https://stackoverflow.com/a/56371006/9160762
So my recommendation is:
try SE first. If it works, great. If it doesn't, try to fix it quickly, since most problems are trivial. Having the SE setup will save you a lot of time over full system, and it is often representative enough.
otherwise, use FS mode. It is just simpler to setup, more representative, and the performance hit is acceptable for most.
You could also use SE first, and then go to FS to further validate only your most important SE results, since FS is slower and you can therefore validate less different setups.
I am developing a testing approach for embedded software, and would like to test it on a POSIX based, real world application that uses scheduler Linux functions (e.g. sched_setscheduler).
It is relatively easy to find open source software that is using POSIX threads and locks (e.g. http://ctrace.sourceforge.net). However, I cannot find any real world application to use Linux scheduling as well. Google drives me in a direction of WCET calculation.
Does anyone know any open source, embedded, POSIX based software, that uses scheduling and affinity Linux functions?
Thank you.
Have a look here: https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git/. and here: http://elinux.org/Realtime_Testing_Best_Practices These are artificial test sets for realtime testing Linux kernels. Basically they work on parallel and prioritized CPU load, scheduling and missing computation deadlines.
I am wondering if anyone have any information on development boards where you can utilize ARM TrustZone? I have the BeagleBoard XM which uses TI's OMAP3530 with Cortex-A8 processor that supports trust zone, however TI confirmed that they have disabled the function on the board as it is a general purpose device.
Further research got me to the panda board which uses OMAP4430 but there is no response from TI and very little information on the internet. How do you learn how to use trust zone?
Best Regards
Mr Gigu
As far as I know, all the OMAP processors you can get off-the-shelf are GP devices, i.e. with the TrustZone functions disabled (or else they're processors in production devices such as off-the-shelf mobile phones, for which you don't get the keys). The situation is similar with other SoC manufacturers. Apart from ARM's limited publications (which only cover the common ARM features anyway, and not the chip-specific features such as memory management details, booting and loading trusted code), all documentation about TrustZone features comes under NDA. This is a pity because it precludes independent analysis of these security features or leverage by open-source software.
I'm afraid that if you want to program for a TrustZone device, you'll have to contact a representative of TI or one of their competitors, convince them that your application is something they want to happen, and obtain HS devices, the keys to sign code for your development boards, and the documentation without which you'll have a very hard time.
As of today OP-TEE runs on quite a few devices (see OP-TEE platforms supported) and several of them are development boards readily available. To name a few HiKey, Raspberry Pi3, ARM Juno Board, Freescale i.MX6 variants etc. Either you could pick up one of those or you could simply try it all using QEMU which is very well supported in OP-TEE.
You can get 45 days trial version for ARM fastmodels. RaspberyPI is supposed to support TrustZone too. www.openvirtualization.org has full open source implementation of ARM TrustZone. ARM is moving away from its proprietary TrustZone APIs to globalplatform API. GlobalPlatform also defines the APIs for Inter process communication etc.
There are a few select boards at this time that do allow development with TrustZone. As far as general purpose board, the FriendlyARM board is a good start (http://www.friendlyarm.net). Also, any board with a Cortex A15 processor must have TrustZone available due to the fact that the virtualization extensions can only be utilized from the Normal world. There may still be a question of whether or not the manufacturer has their own code running in the Secure world, but you can always try. The Arndale is a good development board, but unfortunately Samsung already has code running in the Secure world, so by the time you get access, you're running in the Normal world. So if you need Secure world access, look for non-Samsung, Cortex A15 processors. That'd be your best bet.
It's also worth noting the TI did not technically disable TrustZone. Instead, the bootrom code transitions the processor into the Normal world prior to switching execution to U-boot. So it's actually using TrustZone to move to the Normal world, but then doesn't provide a mechanism for moving back to the Secure world. To prove this, just try to read the SCR and you'll get an undefined exception, which is what will typically happen from the Normal world. However, if you perform a SMC call, it will execute just as expected (i.e., it switches to the Secure world, but then just switches right back to the Normal world), so it looks like nothing happened.
regarding openvirtualization, it can be ported to arm development board like the samsung exynos 4XXX.
you will have access to all source code including the secure os if you use openvirtualization.
but if you just want to develop programs that use the trustzone, I wonder if it is necessary. maybe there are standard driver or api that allow you to do it without worrying about compiling your own secure os?
the best thing you can do is contact parties like Gemalto and the people that brought Mobicore. Note that they will indeed ask you to sign an NDA.
Secondly, you can buy the ARM DS5 development suite. This comes with a lot of documentation including some on trustzone.
You should really take a look at the USB armory from Inverse Path: http://www.inversepath.com/usbarmory.html
It's built on open hardware and open source with full access to Trustzone (you can blow in die fuse to enable secure boot): https://github.com/inversepath/usbarmory
They successfully ran Genode within TZ and Linux in the normal world.
I am involved with an embedded software development for telecom industry. I have zero experience before with such embedded hardware devices.
I got a network processor board, which is featured in switching pipeline engines.
Besides the board, there is also an accessory board called "piggy"(seems for ethernet connetion), and another serial line connection.
I am completely lost about these boards and serial line connections. what they are used for? I tried to use google to find some useful introduction or materials but failed. Can anyone point out what this piggy board is used for? Any good references or books that explain about this?
Thanks a lot!!
To develop for your embedded system you will need a development host (a PC or workstation that hosts the development tools including cross-compiler, platform libraries, debugger etc.), and a debug connection to the target (typically an in-circuit emulator or JTAG debugger, but in some cases debug over serial, USB or Ethernet may be supported via software running on the target - though that is less reliable since the code you are debugging may corrupt or break the debug stub running on the same target).
When you have got that together and can build, load and run code on the target, you may then be in a position to ask a more specific question. Writing code for this platform will depend on many things such as processor type, programming language, target operating system (if any), real-time performance requirements, regulatory standards, product type standards etc.
With respect to how to access your specific hardware, then no one can tell you that without access to the documentation and hardware schematics, and you cannot do anything with it yourself without that. Some knowledge of electronics will be a distinct advantage in most cases.
I'm just starting to design some embedded devices, and am looking for resources.
What I want to be able to do is to connect a GPS receiver to a lightweight SBC or mini-ITX, x86-based computer, and track a remote-controlled vehicle's location/progress.
Ideally, this could morph into building some hobby, semi-autonomous vehicles.
But what I need to start with is a development board for GPS programming.
What boards/packages have you used, and where can I find [preferably open source] development for them?
OpenEmbedded is a good place to go to get started. A lot of embedded products use ARM and other processors, so cross-compiling is a big deal. Buildroot is another resource for building custom linux kernels for small systems.
You can also find lots of manufacturers with Single Board Computers (SBCs) that have tools to do what you want - do a google search for "SBC Linux" and you should have a gold mine.
LinuxDevices keeps a pulse on the linux embedded community and you should find several good articles there that lead you to products or software to help you.
Debian has an embedded build, but I haven't explored that.
There are several books on embedded linux available if you want to go that route.
The GPS receiver simply connects to a serial or USB port, and present an NMEA stream of data, which you can parse with GPSD and several programs can access it through GPSD. It's a very simple text based format.
I've used regular PC motherboards, and Atmel AT91 processors for embedded systems (with GPS, cellular, etc). There's a lot of information out there right now, and it's not expensive to get into. If I were to start a new project, I'd look at the AVR32 processors from Atmel - they are very hobbyist friendly, and provide a lot of community support for linux on the AVR32 architecture. They provide free GCC compilers and significant framework and examples if you want to go the OS-less route and have a single program running on the processer as well.
Good luck!
-Adam
"NMEA" is the keyword to be searching for when looking for this stuff. While I haven't done anything with this in a long, long time, here is a good source for some boards and other hardware:
http://www.sparkfun.com/commerce/categories.php?c=4
We have had good luck with Holux GPS recievers (designed for samsung q1). A farily simple connect over serial port and you can read the NMEA string.
What OS are you targeting? If it's Linux there are a lot of GPS libraries available (here's a good list). GPSd and GpsDrive are two of the more popular ones I've seen.
I haven't see any GPS devices specifically for lightweight/embedded use, but many of the consumer GPS devices have USB hookups available that could probably work (watch out for low end ones, they usually don't have the computer interface).
I suggest starting with a plain old c project that reads and parses NMEA from a serial port. You can do this in Windows or Linux.
I usually break down any project like this into a set of smaller projects like:
read and parse NMEA from serial
port
establish a serial /
network link from the remote device
to the tracking system server
integrate the components
Wikipedia has a good article on the NMEA protocol. As Adam points out it's actually pretty simple.
Circuit Cellar magazine often has projects like this as well.
Depending on what you want to do, there are various sizes of target to consider. Use Atmel AVR for small low power (battery) stuff. Perhapse use Linux on an old laptop if I just wanted to rough out the concept and needed WiFi (or cellular) for internet.
The laptop Linux prototype then could be trimmed down and ported to an embedded Cinux system for even lower battery usage and portability later on. (not as low as Atmel though).
If you are comfortable with programming in Linux I would recommend the Gumstix range of small computers - http://www.gumstix.com/
You could pair the vedex motherboard with the GPSstix expansion board tp make a tiny GPS receiver with a well supported programming environment.
I suggest GPSBabel to communicate with your GPS receiver.
GPSBabel
Handles waypoints, tracks, and routes,
Knows lots of format (this explains the name Babel),
Runs on Windows, Linux, OSX,
Free.
Some people here have suggested devices like the gumstix - embedded devices which cost $149 without GPS. I don't understand that bit. A off-the-shelf TomTom comes with running Linux on ARM, built-in GPS, lots of flash, battery and screen. It's hard to beat the price advantage that comes with mass production. For your hobby project, the map included is not needed, but who cares?