I'm taking an advanced operating systems course. We're using full hardware emulation from qemu to develop our own basic operating system. What we're programming this week is the keyboard. Interacting with the keyboard controller over ports 0x60 and 0x64 in the appropriate way to decode scancodes works. Using our previously written CGA driver we can now type things and have them displayed on screen in qemu. One thing that doesn't work in qemu, but does work on hardware provided by the professor specifically for the course, is setting the speed and delay parameters of the keyboard. These determine how long you need to push a key until make-codes are sent repeatedly and with what frequency make-codes are sent once you pushed the key long enough. This changes how fast a character is printed repeatedly on screen when holding. We are all wondering what exactly is happening in qemu that prevents this from working in qemu. The easy answer: qemu doesn't emulate the set_speed (0xf3) command. The more interesting question: From where in the source code could one tell this is not going to work? Are there other commands not emulated by qemu? Why is set_speed not emulated by qemu?
Many thanks in advance
Related
I am trying to make some custom firmware for a MIDI controller (AKAI LPD8).
There is an STM32F102R8T6 chip in the unit.
I am trying to reach it with a programmer to wipe it, but it seems to not be responsive.
Some information and thing I have tried:
The firmware that came with the unit works, so the chip is not broken
Removed the components connected to the programming pins (PA9-PA10 and PA13-PA14)
I am able to pull BOOT0 high and have it not run the main program, but I am however not able to get a life sign using either an ST-Link2(clone) connected to PA13/14, nor a USB to serial adapter connected to PA9/PA10, so I am not sure what mode it is in
The connection has been checked, and RX-TX etc is the correct way around (but also for the sake of trying it all, I reversed the connections as well...).
Tried both the STM32CubeProgrammer and stm32flash, but none connects.
I am actually not sure if AKAI have locked the chip in such a way that you cannot even do a full chip erase and use the chip for something new? The NRST pin is strangely not doing anything to the running of the firmware either when I try to pull it low.
Is there a way to reprogram these chips when they come off of a commercial product, or are they permanently locked?
Any solution/tips?
Many of the STM32 parts have "proprietary code read-out protection" (google PCROP) which but you might be lucky and they haven't enabled it in the option bytes. Read the documentation for that and the bootloader documentation and get a good idea of what you expect it to do if it is enabled and if it isn't.
If you have a scope, try watching the SWD/JTAG pins to see if there is any response from the device. (If you aren't even sure if it is in reset then scope the crystal if there is one).
If you haven't got a scope, you might be able to to verify what it is doing by seeing if it sets the pins and pull-resistors to how they would be expected to be in the bootloader mode, eg: UART TX should be high if it is enabled, even it it isn't transmitting anything. Put a strong pull-down (~1k) on there and see if it still reads high.
After hours of trying different ways of making it work (also tried the alternate mapping of the UART port), and probed the TX pin as suggested by Tom V to no avail, I have given up working on that specific chip and ordered an upgrade from the STM32F4 family instead to replace it with. A lot more power and useful peripherals.
A bit of a non-answer to the specific question. Frustrating to not have found out what was wrong (chip or approach) but being mindful of the sunk cost fallacy, I think it was best to just replace the chip with a fresh one and start development from there.
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.
In the Sparc V8 architecture we have some N register windows. Generally an RTOS during context switching pushes and pops registers. Is it possible( or already has been done) to use each of these register windows as one of the thread. This will make switching onto next thread as good as shifting register window and pushing and popping PSR ! Thus saving context switching time and enabling faster context switching frequency.
Maybe, it depends on what you mean by threads and how many.
The register windows are built around the idea of function calls and returns, implementing this in hardware and software traps with well defined operation. If your threads are just functions that get called in a round robin fashion etc... then yes they will get switched in this manner as will any other functions called from your "thread". That said once your have more functions than the number of register windows they will start getting paged in and out of the register file.
From the perspective of OS and User code... you don't have control of what happens when you enter and leave a register window as that is implemented as a trap as I understand it probably in the firmware. If you go changing how that works you aren't running a Sparc anymore because what it does there is defined in the Spec.
The whole point of Register windows has always been fast context switching.. but other aspects of Sparc hardware such as the TLB can get in the way of that... in the context of a Sparc MCU with a flat address space... then yeah it would be really fast.
My question is quite simple.
I encountered this sys_vm86old syscall (when reverse engineering) and I am trying to understand what it does.
I found two sources that could give me something but I'm still not sure that I fully understand; these sources are
The Source Code and this page which gives me this paragraph (but it's more readable directly on the link):
config GRKERNSEC_VM86
bool "Restrict VM86 mode"
depends on X86_32
help:
If you say Y here, only processes with CAP_SYS_RAWIO will be able to
make use of a special execution mode on 32bit x86 processors called
Virtual 8086 (VM86) mode. XFree86 may need vm86 mode for certain
video cards and will still work with this option enabled. The purpose
of the option is to prevent exploitation of emulation errors in
virtualization of vm86 mode like the one discovered in VMWare in 2009.
Nearly all users should be able to enable this option.
From what I understood, it would ensure that the calling process has cap_sys_rawio enabled. But this doesn't help me a lot...
Can anybody tell me ?
Thank you
The syscall is used to execute code in VM86 mode. This mode allows you to run old "real mode" 32bit code (like present in some BIOS) inside a protected mode OS.
See for example the Wikipedia article on it: https://en.wikipedia.org/wiki/Virtual_8086_mode
The setting you found means you need CAP_SYS_RAWIO to invoke the syscall.
I think X11 especially is using it to call BIOS methods for switching the video mode. There are two syscalls, the one with old suffix offers less operations but is retained for binary (ABI) compatibility.
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).