I've booted Simics to EFI shell on Intel EagleStream, but I can't get any drives to be mapped. I've tried setting $disk_image to an empty 10Mb .craff file, but still no luck. In QEMU, this is fairly straight-forward and one can even map physical USB slots on the host machine to a target drive. How would I accomplish this with Simics?
Setting the default disk image to an empty image, or any image, should work. Provided it is the right variable (which varies with the target system in general). Directly mapping a physical USB device into the virtual system is currently not a feature supported by Simics.
Related
From Wikipedia
Disk formatting
Disk formatting is the process of preparing a data storage device such as a hard disk drive, solid-state drive, floppy disk or USB flash drive for initial use.
Mount (computing)
Mounting is a process by which the operating system makes files and directories on a storage device (such as hard drive, CD-ROM, or network share) available for user to access via the computer's file system.
I don't understand how these two sentences are different
You format a device. You mount a filesystem.
Mounting a Filesystem
Typically, to make a device ready to be written to by the system, you'd have to do the following:
Physically connect the device to the system
(optional but recommended) Create a partition on your device
Create a filesystem on the device/partition
Mount the filesystem on the device/partition to a directory on your system's filesystem, so that you can access the filesystem of the device/partition from your system.
Formatting a Device
Therefore, every filesystem is backed by some block storage device. The storage medium of a block storage device (e.g. a hard disk) is divided into many sections, called sectors. Each sector has a unique address. Whenever you write to, or read from, the device, it is done by writing/reading whole sectors. Therefore, the sector is a smallest addressable physical unit for a block storage device.
When you format a device, you are adding 'marks' onto the storage medium to mark the location of these sectors.
Source of Confusion
Formatting has nothing to do with the filesystem, or mounting. The confusion often arise from Windows users, because on Windows, the term 'formatting' also includes the creation of the filesystem. On Windows, when you format a disk, you are also creating a filesystem on it (and Windows also automatically mount devices you connect).
To distinguish between Window's version of 'formatting', and actual formatting, people have used the term low-level formatting for actual formatting, and high-level formatting for creating the filesystem.
Formatting a disk or partition usually means that you're actually creating or have already created a volume, and it is the volume that you are formatting. Formatting a volume is to write an empty filesystem with the initialised filesystem structures like the MFT to the volume.
Mount has the notion of putting something on top of the other. But what is considered to be on top and what is considered to be at the bottom varies.
For mount points, the mount directory and the existing directory tree is considered to be on the bottom, and you mount the volume on top of / to the directory. This is despite the mount points actually being logically higher than the volume in the driver stack and the process of interacting with files. You sometimes see people say mounting the filesystem to the mount point, like the Linux df command. This makes sense because the file system is indeed logically between the volume and the mount point.
For mounting filesystems to volumes, the filesystem is on top and the volume is below. You mount the filesystem onto the volume. It is actually logically on top of the volume because on Windows it is consulted by the I/O Manager before the volume and it is up to the file system to interact with the volume stack.
On Windows, the volume is mounted to its mount points (C:\ if the symbolic link is \DosDevices\C:) and then you mount the file system to the volume by formatting the volume. Formatting the volume with a file system causes the file system driver to mount the volume. The file system will then mount itself to the volume every time the volume is detected 'arrives' on the system so long as it has been formatted with that file system because the file system driver detects its filesystem on the volume.
Formatting is usually done ONCE during the lifetime of the hard drive.
The hard drive is written to, wiping away anything that was on it previously, so that it can be accepted as a filesystem.
Mounting usually happens every time the system has been restarted. It allows the operating system to access the hard drive as a filesystem. Mounting a drive does NOT alter the hard drive, although once a filesystem has been mounted it can be modified (unless it was mounted read-only) by typical filesystem operations like creating a directory/folder, creating files, modifying files, etc ....
Mounting tells the operating system which filesystem type (ext3, ext4, HFS+, NTFS, ZFS ...) the hard drive is allowing the OS kernel to map the virtual filesystem functions to the real filesystem functions.
I'm developping a "MP3 player"-like USB device. It is seen as a Mass Storage device by the USB host (Windows). I'd like to be able to keep the current song playing while the device is connected.
In an ideal world, the user should be able to delete every mp3 files using his file explorer but the one currently playing, which would be seen as "in use" by Windows.
The filesystem is FAT, I use FatFS for reading files on the device.
Does FAT allow such thing (mark a file as "in use") ? Any smarter idea ?
Like every filesystem that isn't specifically designed for this purpose, FAT isn't a cluster filesystem. As such, there are no provisions for mounting it from more than one host at a time. So it can't be mounted from the USB host's operating system and from the USB device's embedded operating system at the same time. The concept of a file being "in use" at the filesystem level is moot for a non-cluster filesystem.
For examples of cluster filesystems, look at OCFS2 or GFS2. But those require things like network lock managers and it is very unlikely that you can easily use them for an application like a USB device.
Let's say I would like to change a setting in the BIOS of my computer in Linux (let's say Ubuntu 11 if it matters.) What types of APIs exist to allow you query and manipulate BIOS setting?
Further, what are good resources for doing this type of development?
The CMOS memory exists outside of the normal address space and cannot
contain directly executable code. It is reachable through IN and OUT
commands at port number 70h (112d) and 71h (113d). To read a CMOS byte,
an OUT to port 70h is executed with the address of the byte to be read and
an IN from port 71h will then retrieve the requested information.
You can use the inb and outb macros to read and write from these ports to get the entire BIOS settings stored in the CMOS. For the settings memory format stored have a look at: http://bochs.sourceforge.net/techspec/CMOS-reference.txt
These mappings are actually vendor dependent, but most of them should be common.
Although this is not an API, but with this you can make direct access to the CMOS memory and make your own API. For a quick program i would recommend getting an API. Check out #Nemo's answer in this case.
flashrom is a utility for flashing a new BIOS image from within Linux.
To modify the BIOS settings themselves, you can use the /dev/nvram device.
This page provides good information on both of these.
Note that the meaning of the NVRAM contents depends entirely on the BIOS itself; it will vary from BIOS to BIOS and even between revisions of the same BIOS. So the only thing you can reliably do is save the BIOS settings on one system and restore them onto an identical system.
This all depends from what one means by "BIOS setting".
In traditional, PC/AT, PC machine firmware, the "BIOS settings" are saved in the non-volatile RAM associated with the real-time clock chip. There is pretty much no standardization as to what the individual bytes of NVRAM represent (although there are a couple of common conventions) and their meanings vary from firmware vendor to firmware vendor, and from firmware release to firmware release. Tools for manipulating the RTC NVRAM include the Linux and FreeBSD /dev/nvram device.
But this isn't the only non-volatile RAM on a modern PC. The "BIOS ROM" is also, in reality, non-volatile RAM. (One cannot just write to it in normal operation. One has to perform magic incantations to enable write cycles. But it is not Read-Only Memory.) Later PC firmwares use this much larger (potentially up to 16MiB as opposed to 256 bytes) non-volatile RAM for settings storage. System management data such as Extended System Configuration Data and the infamous DMI Pool are stored there. Tools for manipulating these data include the Linux dmidecode utility which uses /dev/mem.
On a modern PC with EFI firmware, the "BIOS" NVRAM is usually where the EFI firmware environment variables are stored. These can be manipulated by tools such as uefivars, which in their turn rely upon the /sys/firmware/efi filesystem (which effectively, albeit somewhat indirectly, exports the kernel-mode EFI API for variables to application mode). EFI variables are the "settings" of modern EFI firmwares, controlling a range of things from what's on the EFI Boot Manager menu (c.f. the efibootmgr utility) to what devices constitute the system console.
I'm trying to curate a list of tools to do this on my wiki:
https://wiki.xkyle.com/Configuing_BIOS_From_Linux
While not technically API's, they are methods to do what you are asking.
They are vendor specific, and for servers.
Intel Severs: Syscfg utility
Dell PowerEdge C Servers: setupbios or their syscfg
HP Servers: the CONREP utility
I have a CE 6.0 project on a PXA310 where I need to be able to download OS updates (nk.bin) via Wi-Fi and safely flash the new OS to my device. I'm open to other suggestions about how to do this, but I'm considering saving the nk.bin to my file system in NAND flash, then restarting and have the bootloader locate the file in the file system and flash it to the BINFS partition. Is this possible, and if so, can you give me an outline of what I'd need to do?
One caveat is that this needs to be very robust since the devices are deployed in the field and are not field serviceable. I need to be sure that if the OS flash fails (due to power failure, etc.) that upon reboot the bootloader can try again. That is why I'd like to store the downloaded image in persistent flash and avoid having to re-download the image.
Technically just about anything is possible. For this strategy what you would need is code for your bootloader to mount the NAND flash as a drive and have a FAT driver so that it can traverse that file system and find the image. That is a lot of work if you don't already have it.
THe other option is to just store it in flash outside of the file system in a known address location. That's a lot easier from the bootloader perspective as all you have to do is map to the address and copy. Of course it makes the writes more challenging because then you're doing it from the OS and you have to disable any other flash accesses completely while you do your write to prevent corruption by two threads sending flash commands to the chip at the same time.
In either case, if you have the space it's a good idea to store a "known-good" image elsewhere too, so that if the new image has a problem (fails a checksum or x number of load attempts fails) then you have a working OS that the bootloader can fall back to.
Clearly a lot depends on your hardware setup, but we've done this without making the Bootloader support the Flash Filesystem.
In our product, the OS image is loaded from Flash to execute from RAM -- I think most WinCE devices work this way nowadays. So to update the OS we use a special Flash driver which lets an application, running under WinCE, update the OS blocks in the Flash -- then all you need is a hard reboot and the Bootloader loads the new flash image into RAM in order to execute it. We've found this pretty reliable in the field (with some not-very-technical end-users!).
A special Flash driver was needed because the MS Flash Filesystem drivers have no access to the OS image sectors of the Flash, in order to prevent trashing the OS by accident.
You do need to load the NK.BIN into some memory which the OS programming application can read, normally the NAND Flash, but if you had enough RAM it could just go into the root of the filestore. However either way you can delete it when you've finished programming the OS sectors before the reboot so it's only a temporary requirement.
I will write some thing in a file/memory just before system shutdown or a service shutdown. In the next restart of system, Is it possible to access same file or same memory on the disk, before filesystem loads? Actual requirement is like this, we have a driver that sits between volume level drivers and filesystem driver...in that part of the driver code, I want to access some memory or file.
Thanks & Regards,
calvin
The logical thing here is to read/write this into the registry if it is not too big. Is there a reason you do not want to use the registry?
If you need to access large data and you are writing a volume or device filter and cannot rely on ZwOpen/Read/Write/Close functions in the kernel an approach would be to create the file in user mode, get its device name and cluster chain and store them in the registry. On the next boot, you can get the device and clusters from registry, and do direct I/O on them.
Since you want to access this before the filesystem loads, my first thought is to allocate and use a block of storage space on the hard drive outside of the filesystem. You can create a hidden mini-partition on the drive and use low-level I/O commands to read and write your data.
This is a common task in the world of embedded systems, and we often implement it by adding some sort of non-volatile memory device into the system (flash, battery-backed DRAM, etc) and reading and writing to that device. Since you likely don't have the same level of control over the available hardware as embedded developers do, the closest analogue I can think of would be to reserve a chunk of space on a physical disk that you can read from without having to mount as a filesystem. A dedicated mini-partition might work the best because if you know the size of it, you can treat it as one big raw-access buffer and can avoid having to hassle with filenames, filesystems, etc.