Does the Zephyr OS(version 1.9) needs any BIOS or UBOOT for booting?
Since I am new to this please provide booting process of zephyr RTOS
Zephyr RTOS is designed first of all to be "baremetal" OS. It boots directly on the hardware and initialized it completely itself.
But: first of all, you need to get a Zephyr application onto your board/MCU. This can be done using an in-circuit programmer (JTAG, SWD, etc.), but for end user, it may be more convenient to use an MCU-specific bootloader and upload an app via a UART/USB connection. Note that these MCU specific bootloaders aren't "BIOS" or "UBOOT"
Going further, when new ports appear to architectures which normally use e.g. the U-Boot bootloader, I guess Zephyr port to that architecture will take advantage of that, to make application deployment easier.
Summing up: Zephyr RTOS doesn't need a special bootloader. But it can take advantage of it to make application deployment easier for a user.
Related
I'm interested in the details of how operating systems work and perhaps writing my own.
From what I've gathered, the BIOS/UEFI is supposed to handle setting up the hardware, and do things like memory-mapping (or IO ports for) the graphics card and other IO devices like audio and ethernet.
My question is, how does the kernel know how to access and (re)configure these devices when it's passed control from the bootloader? Are there just conventions like 'the graphics card is always memory mapped from X to Y address space'? Are you at the mercy of a hardware manufacturer writing a driver for an operating system which knows how the hardware will be initialized?
That seems wrong, so maybe the kernel code includes instructions which somehow iterate through all the bus-connected devices. But what instructions can accomplish that? Is the PCI(e) controller also a memory-mapped device? How do you begin querying and setting up the system?
My primary reference has been the Intel 64 Architectures Software Developer's Manual, which has excellent documentation on how the CPU works, but doesn't describe how the system is setup.
I never wrote a firmware so I don't really know how that works in general. You probably have some memory detection done like an actual memory iteration that is done and some interrogation of PCI devices that are memory mapped in RAM. You also probably have some information in the Developer's manuals as to how you should get some information about memory and stuff like that.
In the end, the kernel doesn't need to bother about that because the firmware takes care to do all that and to provide temporary drivers before the kernel is set up completely.
The firmware passes information to the kernel using the ACPI tables so that is the convention you are looking for. The UEFI firmware launches the /efi/boot/bootx64.efi EFI app from the hard-disk automatically. It calls the main function of that app often called the bootloader. When you write that application, often with frameworks such as EDK2 or GNU-EFI, you can thus use the temporary drivers to get some information like the location of the RSDP which points to all other ACPI tables.
The ACPI convention specifies a language that is AML which, when your kernel interprets, tells it all about hardware. You thus have all the required information there to load drivers and such.
PCI (which is everything nowadays) is another thing. It works with memory mapped IO but the ACPI tables (the MCFG) is helpful to find the beginning of the configuration space for PCI devices that take the form of memory mapped registers.
As to graphics cards, you probably don't want to start with those. They are complex and, at first, you should probably stick to the framebuffer returned by UEFI and at least write a driver for xHCI which is the PCI host controller responsible to interact with USB including keyboards and mouses.
I would like to have a computer running only one program, so whenever the computer boots, it executes that program.
For example:
Computer board from Tesla car, common supermarket systems
One example of how I use that:
Develop a system to make a house automatic, so there would be a screen showing lights which can be turned on or off, and if the house runs out of power, when the energy come back the computer would reboot and display lights options again.
Do I have to build a OS for that?
A program that boots + runs on bare metal is called a "freestanding" program. It doesn't run under an OS, and includes everything it needs to manage the hardware, and includes all libraries it needs (statically linked).
It needs to do some of the same things an OS does (talk to hardware, install interrupt handlers, etc.) so in some respects you could call it an OS, but it's also just one program and doesn't necessarily provide any mechanism for running other programs.
The more bare-bones and light-weight the microcontroller is (and/or the program), the more obvious it is that it's just a program, not an OS. (e.g. if you don't do any dynamic memory allocation. Or you don't load any code from anywhere into RAM, just execute it from ROM).
BTW, an OS kernel is a freestanding program. Not all freestanding programs are kernels, but a kernel has to be be freestanding by the normal definitions of what a kernel is.
Also BTW, it's totally normal for an embedded system to run an OS, and have that OS start some specific programs. In fact the examples you cited do use OSes. So instead of writing all your own drivers, scheduling code, etc., you use an existing OS and write a program that runs under that OS.
Sometimes that OS is Linux, sometimes it's a light-weight real-time OS.
For a kiosk, sometimes that OS is even Windows. (Or in older systems, DOS which is barely an OS.) See comments under the question.
You should take a look at IncludeOS Which is made exactly for your purpose, only include what is needed.
Is it possible to access external hardware without using a driver, i.e. not having the driver abstraction layer in between program and external device?
Can you use a device by implementing your own driver-like controlling/handling directly in your program code?
I'm trying to understand a program that implements a Modbus protocol and some very specific Modbus configurations. Now I don't know how exactly it communicates with the Modbus devices.
It looks to me that this is very similar to what a driver does.
But can it even communicate DIRECTLY with the device without having a driver installed?
Yes, there are several micro-kernel OS's that always configure this way -- drivers are entirely implemented outside of the kernel.
The first thing you likely need is to get access to the device's registers; typically performed with mmap(), you may need to dig around a bit to find the right settings for cacheability, etc...
Second problem is interrupts. Unless you are running something like QNX, you won't have a way to have interrupts signal your program directly. You will probably have to turn them off and poll the device periodically.
If you are using linux and need io ports (inb, outb, etc...) man ioperm for more information.
I have digital mixer that runs a proprietary DOS/UNIX like O/S. I would like to setup a VM environment for the O/S in hope that I can provide enhancement via some sort of wrapper or API. What are things I should consider in trying to setup such environment. The feedback below is from one of the developers:
The problem is that the OS is very particular about which hardware is
connected.For my experiments, the OS stopped booting when it tried to
activate write combining for the graphics card. And I didn´t find
any way to make the virtual machine emulate that. I tried to see if I
could make the VM emulate one of the ati cards that seems to work for
these machines - also without luck.
I have several years experience with microcontroller programming. Freertos provides the necessary code to port to a set of microcontrollers. I would like to port Freertos to an embedded system which is not supported.
Which main steps have to be undertaken in order to successfully port freertos to another embedded system? (for example: what initialization steps should absolutely be done in port.c etc...) I have read the freertos page about porting, but it is still pretty vague.
I presume this is the page you are referring to http://www.freertos.org/FreeRTOS-porting-guide.html it is vague because each architecture has its own requirements. For example, is a yield going to be performed synchronously using a trap style instruction, or asynchronously using a pended interrupt, how is interrupt nesting going to be implemented and what support does the hardware give to implement it, etc. Therefore it would have helped a lot if you said which architecture you wanted to port to, then I might have been able to suggest which port to look at as a reference.