What is a platform when we talk about embedded systems? - embedded

I am trying to learn linux porting, booting and other things and one thing that specially comes is platform. What is it
a cpu
a board
an overall term as board + cpu
like when we say platform specific code do we mean architecture(of cpu) specific code ?

The answer depends on context. If you are porting Linux, the platform from that point-of-view is the hardware you are porting it to. If you are writing applications to run on Linux on that hardware, then the platform is *both) the OS and the hardware.
Furthermore if you were targeting a GUI framework such as KDE or Gnome, that that would be "part of the "platform" too; or if you were running Java code, the platform would include the JVM.
Essentially it is the stuff that is already there that the code needs to pre-exist in order to run the code. Generally a platform might consist of layers; the "platform" as such comprises of whatever layers exist below that which you might be developing at that time.

Related

How can I use QEMU to simulate mixed platforms?

Backgournd
There is a lot of documentation about using QEMU for simulating a system of particular architecture (a "platform").
For example, x86, ARM or RISCV system.
The first step is to configure QEMU target-list, for example ./configure --target-list=riscv32-softmmu.
It's also possible to provide multiple targets in the target-list, but apparently that builds an independent simulation for each specified platform.
My goal, however, is to simulate a system with mixed targets: an x86 machine which also hosts a RISCV embedded processor over PCI.
Obviously I need to implement a QEMU PCI device which would host the RISCV device on the x86 platform, and
I have a good idea how to implement a generic PCI device.
However, I'm not sure about the best approach to simulate both x86 and RISCV together on the same QEMU simulation.
One approach is to run two instances of QEMU (as two separate processes) and use some sort of IPC for communicating between the x86 and the RISCV simulation.
Another possible (?) approach could be to build RISCV QEMU as a loadable library and load it from x86 QEMU.
Perhaps it's even possible to have a single QEMU application that simulates both x86 and RISCV?
Yet another approach is not to use QEMU for simulating the RISCV device. I could implement a QEMU PCI device that completely encapsulates a RISCV simulation such as tiny-emu, but I would rather use QEMU for both x86 and RISCV.
My questions are:
Are there some guidelines or examples for a mixed-target QEMU project?
I've searched for examples but only found references to using QEMU as a single platform simulation, where first you choose which platform you would like to run.
What would be the best approach for simulating a mixed platform in QEMU? Separate QEMU processes with IPC? Or is there a way to configure QEMU in such a way that it could simulates a mixed platform?
Related
https://lists.gnu.org/archive/html/qemu-devel/2021-12/msg01969.html
QEMU does not support running multiple target architectures in the same QEMU process. (This is something we would in theory like to be able to do, but it would require a lot of reworking of core parts of QEMU which assume that the target architecture is known at compile time. So far nobody has felt it important enough to put in the significant development effort needed.)
So if you want to do this you'll need to somehow stitch together a QEMU process for the primary architecture with some other process to do the secondary architecture (QEMU or otherwise). This has been done (for instance Xilinx have an out-of-tree QEMU-based system that does this kind of thing with multiple QEMU processes) but I'm not aware of any easy off-the-shelf frameworks or setups to do it. I suspect that figuring out how time/clocks interact between the two simulations is one of the tricky aspects.
There is another option
you can start 2 QEMU processes and connect them through socket
Then you can create run script that start both of them in your order
its less "clock" accurate but good enough for virtual your HW
The other option is https://wiki.qemu.org/Features/MultiProcessQEMU
but you will need some hacking this experimental code
Use renode. It not only provides easy multi cpu simulation, but also hdl and multimachine simulation synchronozed in a single process.

FreeRTOS x86 in virtual environment

I've been reading about FreeRTOS and seems like its widely used on microcontrollers and microprocessors like RasPi/BBB etc. I also read that it can be run on x86 platform and I want to test it.
Can I run FreeRTOS as a VM on virtual box or VMware?
Whats the best way to use FreeRTOS on x86 platform?
Thanks in advance.
One solution to use FreeRTOS on x86 is to run an available FreeRTOS simulator.
e.g. FreeRTOS Windows port:
This allows FreeRTOS to be run in a Windows environment - although
true real time behaviour cannot be achieved. Demo projects are
provided for both Eclipse with MingW (GCC) and Visual Studio 2010
Express Edition.
See the Richard's answer on this topic:
Building FreeRTOS for x86
but [...] the timing is all over the place and simulated time is much lower than
real time (because the timing resolution and accuracy in Windows is so
low compared to a real time system).

Why can an executable run on both Intel and AMD processors?

How is it that an executable can work on both AMD and Intel systems. Aren't AMD's and Intel's instruction sets different? How does the executable work on both? How exactly do they compile the files to work like that. And what exactly is the role of the OS in all this?
The only real difference between AMD and Intel at a given processor iteration is their implementation of the instruction sets they support. x86 (32 bit) and x64 (64 bit) are the two most common instruction sets for Intel and AMD processors.
The differences come in when Intel and AMD implement the instruction sets in their chips - but these implementations should have no effect on the instruction sets themselves. So if a program was compiled for an x64 processor, it can run on any processor that implements the x64 instruction set, which almost all modern Intel and AMD processors implement.
A great example of an implementation difference is the way that Intel likes to hyperthread cores whereas AMD likes to just add more cores. They do this for a multitude of reasons, such as power consumption and better concurrent processing, but it doesn't really impact if programs run because it doesn't change the instruction set. Another difference between Intel and AMD is the number of pipeline stages, which can affect speed.
Huge complexities come into play when operating systems are considered. Windows has huge libraries that programs have to use if they want to run on windows. The same goes for Linux and Mac OS X. Since these libraries aren't shared between operating systems, programs written on one operating system probably won't run on another.
Essentially these days, compilation is done for the OS not for hardware, as most hardware have universal protocols and/or tech, as mentioned above, x86 or x64 machine code/opcodes/instruction sets, some programmers do make software designed to run better on certain hardware i.e optimized for AMD or Intel etc...
but still have other versions for other hardware
mainly due to the OS you need to worry about bit length and or running OS
most compilers or software makers tend to compile out to shared machine code instead of manufacturer specific, it should be remember different people use the same things in a different way, the guys in MIT, may decide to code their own OS for their needs and may want to use advance specific features of Intel ins tsrcution set some people fully re do their own androids etc...

What pascal compilers can target embedded ARM with no OS?

Looks like available Pascal compilers can only produce binaries for ARM on Linux. Is there established version of compiler/bundle for just bare ARM cpu with zero extra software preinstalled ?
To clarify, I am looking for high quality, compact tool (alternative to commercial C, open source C) for kernel-less, plain embedded CPU with all software in one plain ROM ? IDE with debugging capabilities is nice to have, but not necessary. Dubugger could actually be some different 3rd party generic IDE. I hope that compilers can dump the debug/symbols info in some standard form.
Thank you
Free Pascal Compiler supports ARM without any OS. They call it TARGET EMBEDDED.
For ARM Linux take a look at this and this.
There is also Lazarus CT edition cross compiler which seams to target sysless ARM too.
UPDATE 1: mikroElektronika has also recently made Pascal compiler for ARM.
UPDATE 2: Ultibo framework for bare metal Raspberry Pi programming looks outstanding.

If I wanted to develop algorithms for a purely RISC machine, what should my development environment be?

Short of buying a SPARC processor, what emulators are there? Thanks.
Pickup a second hand Power Mac G5 and you can run a fairly recent version of a mainstream OS (ie. OS X 10.5.8) and a modern development environment (Xcode 3.1.4).
You get a pretty fast, modern RISC machine running an OS that is still highly used (for the time being, I admit.)
You could also install Linux onto it if that would be better for your needs.
Probably a lot easier to find and cheaper than a SPARC machine.
You could also install the SPIM emulator for MIPS
On revisiting this, it's worth noting that nearly all modern smartphones run on ARM processors, which is short for 'Acorn RISC Machine'. So, an easy answer is 'Android Studio' or anything else targeting phone applications.
Similarly, there's a plethora of simple development boards available inexpensively, such as the BeagleBone Black and the Raspberry Pi, that also carry ARM processors.