I am taking a course in Operating Systems. I am booting jos os on to qemu x86 PC emulator. I read that BIOS finds bootable devices and loads the bootloader from the first sector of the bootable device to 0x7c00 in the memory.
The first instruction in the bootloader is to disable the interrupts i.e cli.
I read about cli i.e it clears the enable interrupts flag in the eflags register. I read from Wikipedia that it is done to avoid a race condition between kernel code and interrupt handlers. please explain what a race condition is and what sort of race condition is present here.
I still don't understand why it's done? Can someone elaborate on this?
I am considering using JOS for my operating systems class, perhaps as early as Winter term 2016. The cli question, while interesting because of what it prevents, is a little less interesting, IMO, than this one:
When are interrupts enabled again?
One can use the directions on loading the git for the lab described at http://pdos.csail.mit.edu/6.828/2014/labs/lab1/ and then look through the boot and kern directories for the sequence.
Related
I learned that a Privileged Instruction is only executed when current privileged level(CPL) is kernel mode and if not a interrupt is occurred.
And the way to check the current CPL is looking up some mode bit in registers.
I think there should be some process that check a instruction with a mode bit using some special table. And I read this process is on decode state in an unverified blog.
It is true? If not where this process is done?
I wonder where mode bits be checked.
Privileged Instructions are defined by CPU but operating-system.It uses a different branch to run,and hardware will do it.To be honest,you should check Intel Software Developer's Manual,but internel process is not public.
we have system which runs on NXP KE06 chip (MKE06Z64VLH4). It's stationary system, which was developed from primary company, which is not interested in quick bug fixing (there is a lot of bugs) and further development.
Now we have a job to solve a problem, without primary company. We have right now 200 products all over the country. If we want to update mentioned NXP chip, we need to travel to destination, take machine apart,
make and update for NXP chip over SWD (.HEX file) manualy and assemble each machine together again.
We have our controlling system on Raspberry, which is running Raspbian and we have RS-485 half-duplex connection between Raspberry and NXP chip. (which connection continues to CAN --> NXP chip)
We want to solve this problem with software and with current hardware. (With changing all current hardware, with new hardware solution, solves the problem)
Question:
Is possible to make an "remote" updater/flasher with .HEX file, and with current hardware?
FACTS: - we can't ask company for source code
- we have current .HEX file
- we don't want to replace all hardware (200+ pieces)
- we don't know the source code
Is possible to make an "remote" updater/flasher with .HEX file, and with current hardware?
No, because for that to be an option, the MCU must already have a bootloader alternative inside itself.
NXP hates their customers, so they block anyone from reading the manual without logging in... I managed to eventually get it. There is no mentioning of on-chip bootloader support save for SWD. The part can only be programmed by SWD or by a custom bootloader that you'd have to develop.
UART-based bootloaders are not uncommon - you could write one yourself using either UART/RS-485 or CAN, but then you'd have to update the firmware to download the bootloader, so it isn't helpful in this case.
Summary: you need something with SWD on-site or it can't be done.
Also please note that these MCUs typically have anti-copycat protection enabled, preventing you from reading anything out of it. Depending on how they were programmed, this could be present and then the only thing you can do is to erase and flash the whole program.
I was just wondering whether the switch between the kernel mode and the user mode in an operating system is done by the hardware or the os itself.
I understand that when a user process wants to get into kernel mode it can make a system call and execute some kernel code. When the system call is made, the process goes into the kernel mode and now all memory becomes accessible, etc. In order for this to happen, I would assume that the interrupt handler needs to switch or alter the page table. Is this true? If not, how does the CPU know, that it is running in the kernel mode and does not need to page fault when accessing restricted (unaccessible to the user process) memory?
Thanks!
The last answer is actually not true....
Changing to kernel mode doesn't go through 'Real mode'. Actually after finishing the boot process, the computer never goes back to real mode.
In normal x86 systems, changing to kernel mode involves calling 'sysenter' (after setting parameters in some registers), which causes jumping a predefined address (saved in the MISR register of the CPU), that was set when the computer booted, because it can be done only from kernel mode (it is a 'privileged' command).
So it basically involves executing a software command, that the hardware responds to, by the way it was set, when it was in kernel mode
This is kind of a broad question - each hardware platform is going to do things slightly differently, but I think the basic answer is that it's done w/ software that leverages hardware facilities for memory protection, etc.
When a user process wants to do a system call, it executes a special CPU instruction, and the CPU switches from virtual mode (for user processes, has page tables specific to processes) to real mode (for the kernel) and jumps to the OS syscall handler. The kernel can then do what it likes.
CPU support for this is required. The CPU keeps track of which mode it is in, where the page tables are located, jumping the instruction pointer, etc. It is triggered by the user software doing the syscall, and is dependent on the kernel providing support for whatever it is trying to do. As with all computation, it's always both hardware and software. I cannot be done solely with software however, because then there would be no way to prevent a process making a syscall from abusing the privelages it gains, e.g. it could start reading /etc/shadow.
Modern x86 computers have a special instruction just for doing system calls. Earlier x86 processors, and some current RISC ones, have an instruction to trigger an interrupt. Older architecures had other ways of switching control.
Can anyone tell me how do I understand what happens when you boot up a Unix system? Like "BIOS" is loaded, it does a peripheral test etc until you get a shell?
For each unix it's different but for linux, from bios you go the bootloader (u-boot, lilo, grub..) then the kernel decompress itself, start himself and call init once booted.
This article explain well the process :
http://www.ibm.com/developerworks/linux/library/l-linuxboot/
It depends on the system, but in general, you want to start with a look at the init process: http://en.wikipedia.org/wiki/Init
I also recommend "Advanced Programming In the UNIX Environment" (I think in 3rd edition right now) which goes into much detail on this and many questions like it.
To make it easier, BIOS checks for bootable devices in order defined,
The first one that is found, First sector is copied to the memory.
The code at the memory position 0800 hex is then set to the Program Counter register and execution is delivered to the bootable media.
RESOLVED
After much confusion and frustration, I finally got my hard disk to interrupt. :D It basically came down to the fact that I kept reading the status register instead of the alternate status register. A few other things were messed up to boot, but the point is my hard disk driver is finally starting to take shape. Now, for others I will leave the original post.
P.S. For further clarification, I didn't need to issue any sort of reset command. All I did was the following:
Select the device (didn't want to kill the Solaris OS on the other disk)
clear the nIEN bit in the DEVICE CONTROL register
issue an IDENTIFY DEVICE command***
Actually, I am not sure if the IDENTIFY DEVICE command is need because I left the lab happy before I could test the code without issuing the command. However, the main point is that I needed to be sure to read the alternate status register and have the nIEN bit cleared without the need for a reset. The BIOS apparently takes care of most stuff.
I am currently trying to write a disk driver for a hobby OS being developed at my school. I currently have routines to read/write data in the PCI configuration space and assembly routines to do port IO with the various registers defined by ATA/ATAPI-7. Now, my question is, specifically how will I get an IDE hard drive to start generating interrupts? I have been looking through all this documentation and is hasn't become clear to me what I am doing wrong.
Can someone explain exactly what causes an IDE hard drive to start generating interrupts? I already have an interrupts service routine ready to test, but am having difficulty getting the interrupts in the first place. Can this be accomplished through the ATA SOFT RESET?
Thanks!
UPDATE: Ok, I was able to get the secondary channel, an ATAPI CDROM to generate interrupts by setting the SRST bit in the DEVICE CONTROL register for a soft reset. This does not work for the hard disk on the primary channel. What I have noticed so far is that when I set the SRST bit for the HDD, it sets the BSY bit and leaves it set. From there I don't know what to do.
This reference should help you a fair bit: Kenos description of programming ATA/ATAPI.
The basic mechanism to enable interrupts is to clear nIEN in the DCR (Device Control Register):
nIEN: Drive Interrupt Enable bit. The enable bit for the drive interrupt to the host. When nIEN is 0 or the drive is selected the host interrupt signal INTRQ is enabled through a tri state buffer to the host. When nIEN is 1 or the drive is not selected the host interrupt signal INTRQ is in a high impedance state regardless of the presence or absence of a pending interrupt.
This www.ata-atapi.com is a good jumping-off point to find way more info about ATA/PATA/SATA/ATAPI than you want to know... Note that the official ATA-6/7/etc specs cost $$ from T13, though you can download current drafts of ATA-8 from them.
This link describes a few of the many ways ATA devices vary from the specs. (I used to write SCSI and ATA/ATAPI drivers for Commodore/Amiga, way back when, as well as help with qualifying drives - or more accurately, figuring out what idiocies drive makers had done.)
if this is just a hobby OS, why not use the BIOS interrupt (int 13h)? admittedly not as fast as direct disk access but safer for your hard drive (I've put a read head through a plate before messing with disk I/O).