In micro kernel system structure,hardware is not interact with the micro kernel.
So I want to know why micro-kernel of Windows NT doesn't directly interact with the hardware layer?
here is diagram what I am talking about
Mico kernel System structure
In a word: Portability
The NT microkernel is written in terms of the HAL (Hardware Abstraction Layer) to make it easy to port to mulitple target harware architectures. Now for the most part the HAL is very low level, and where possible compiles away to nothing (so the actual microkernel code is running directly on the hardware), or minimal inline asembly code.
Related
In the case of x86 the same (real mode) bootloader works on virtually any x86 device.
Is that possible on ARM or do I need to create a specific bootloader for each 'cortex'?
x86 or lets say PC compatible systems are ... pc compatible. They support the ancient bios calls so that there is massive compatibility. by design, by the chip vendor (intel) the software vendors (bios, operating system) and the motherboard vendors.
ARM is in now way shape or form like that. There are instruction sets you can choose that work almost or all the way across, but remember ARM systems you buy an ARM core and add it to your special chip, you and your special/custom stuff, then that is put on one or more different boards. There is little to no compatibility. Instruction set and arm core is a small part of the whole picture most of the code is for the non-arm stuff.
u-boot and perhaps others are fairly massive bootloaders, pretty much an operating system themselves, and have to be ported just like an operating system to each chip/board combination. The chip vendor, if this is a linux compatible system, most likely has a reference design and a BSP including a u-boot port and/or some other solution (rasberry pi is a good example). it is fairly trivial to boot linux or used to be, there is no reason for the massively overcomplicated u-boot. without a DTB you setup a few memory locations a register or two and branch to the kernel, thats it (again look at the raspberry pi), I assume with DTB you build the dtb then put it somewhere, setup a few registers and branch to the linux kernel (raspberry pi? ntc chip?)
There is a Arm open source project that can cover Armv7/v8 Cortex-A processors bootloaders.
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/
Another open source project for Cortex-M processors:
https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/
Before publishing its Videocore IV specification, Broadcom released an operating system independent binary blob. Does ARM Mali GPU has an abstraction layer independent of Linux kernel with an public interface specification?
The Linux kernel driver is released as full source code; there is no kernel-side binary blob. Source code for the kernel modules can be found here:
https://developer.arm.com/products/software/mali-drivers
... although silicon providers may provide customized releases for their chipsets (e.g. adding power management support), so ARM recommend getting the source via the chipset manufacturer. There is no non-Linux kernel driver available publicly to the best of my knowledge.
User-space library releases are binary only, available from the chipset manufacturer.
On my ARM system (Tegra based), I'm running the mainline linux kernel. It uses the device tree system.
I have enabled a hardware driver for the General-Memory-Bus (part of the SoC) in the .dts file by setting its status="okay". Recompiled the dtb and booted the kernel. But no device (/dev/xx) appears.
The driver is compiled into the kernel and can be seen by
cat /lib/modules/$(uname -r)/modules.builtin
The command
cat /sys/firmware/devicetree/base/<path to device>/status
returns "okay".
Do I need to make some kind of "mknod"?
What else is nessesary?
The traditional UNIX "stream of bytes" device model is a pretty high-level abstraction of most modern hardware, and as such there are plenty of drivers which do not create /dev entries for the devices they control largely because they don't fit that model. Bus drivers in particular are very much a case of that - they exist, but only for the sake of discovering and allowing access to the devices behind them; there is no /dev/sata that lets you interact with the actual host controller, sending out raw commands on any old port regardless of what's connected or not; there is no /dev/usb that lets you attempt arbitrary transfers to arbitrary endpoints which may or may not exist.
Furthermore, your typical 'external interface' controller as in this case is orders of magnitude less complex than an interface like SATA or USB - the 'device' itself is often little more than a register block controlling some clocks and a chip-select multiplexer. Even if the driver did create something you could interact with directly, there's not exactly much you could do with it.
The correct way to proceed in this situation is to describe your FPGA device in the DT as a child of the GMI bus, accurately reflecting the hardware, no less, then develop your own driver for that. The bus driver itself just sits transparently in the middle. And if you do want a quick and dirty way to get started by just reading and writing bus addresses directly, well, it's behind a memory-mapped I/O region; that's exactly what /dev/mem exists for.
Cheers...
I understand that it stands for Hardware Abstraction Layer but what exactly does it do ? Is it designed for high level languages like VB to communicate with the hardware ? What about the IN/OUT instructions do these instructions call into a HAL routine or do they communicate directly with the hardware's device driver via the I/O manager ?
Thanks in advance
I understand that it stands for Hardware Abstraction Layer but what exactly does it do ?
It's essentially the "non-portable" part of the NT kernel, provided as a seperate module so that NT could be ported to multiple processor architectures. Example: interrupt routing.
Is it designed for high level languages like VB to communicate with the hardware ?
No. It is meant as support routines for the NT kernel. If you are coding in user mode (as you would be as in high level languages like VB) you have no need to know it exists.
What about the IN/OUT instructions do these instructions call into a HAL routine or do they communicate directly with the hardware's device driver via the I/O manager ?
When you use the the in and out instructions, this is talking directly to the CPU. This is entirely unrelated to the NT kernel topics you are discussing. There is no HAL there. There is no NT I/O manager. These instructions are what the x86 instruction set provides for talking to devices through an I/O address.
The HAL is designed to 'abstract' details of the hardware away from the operating system (It is a kernel component).
It provides routines to kernel for dealing with machine specific instructions (afaik includes handling of things like AVX state preservation through a context switch) as well as other details such as interrupts (Google 'Interrupts IDT' (no quotes))
Note that the HAL does not fully sit below the kernel, as the kernel still talks directly to hardware in some places, however the HAL also depends on the kernel for many of its functions (as such they often come in matched 'sets')
http://support.microsoft.com/kb/99588
The HAL is like an isolation layer, it means that things on either side of the layer can change, and (theoretically) it will have no effect on the other side.
This means various different kinds of hardware can be below the HAL, and the software that calls through the HAL doesn't care.
I am interested in learning how to do embedded system programming in c. However, I will need some hardware.
I am wondering is there any software that can simulate what the control board will do?
The control board is listed in the following tutorial
http://www.learn-c.com/hardware.htm
Many thanks for any advice
The board you linked to is not an embedded system board, it is an I/O interface for a PC. If you want to simulate that, you can simply write PC code stubs for the I/O functions that simulate connected devices' behaviour. However, you will not learn much about embedded systems from this. You may learn a little about PC based control, but since the board does not support interrupts or DMA, I suggest again that you will not learn much of that either.
Moreover the board is designed for an ISA bus slot. Modern PCs no longer have such slots. And modern operating systems prevent access to hardware I/O in user level code.
If you are serious about learning embedded systems development, you might for example download Keil's MDK-ARM evaluation; it includes an ARM simulator with on-chip peripheral simulation for a number of commonly available ARM based micro-controllers, and real hardware is available at reasonable cost.
If PC based control is of more interest, then you would be better off starting with a USB based I/O device, such as this example.