I was wondering how this was done?
There's a very simple solution. ROM was invented first.
From wikipedia: "The simplest type of solid state ROM is as old as semiconductor technology itself."
Computers as early as the ENIAC used ROM to store functionality. The concept of BIOS - more simply, a bootloader - wasn't necessary until computers became publicly available, by which point ROM had been around for decades.
Eproms existed before magnetic media as far as I know, and eproms were what BIOS was stored in. And still are in more sophisticated form.
In the earliest computers, there was a front panel with toggle switches to enter machine code to get it up and running so it could talk to the magnetic tape or punch cards.
http://en.wikipedia.org/wiki/Front_panel
Related
Is it possible to associate single wireless network interface controller (WNIC) with multiple Wireless Access Points (WAP) at a time? If not: why?
I've never heard about such a feature, so I assume it's technically impossible or fairly difficult and rarely implemented. Is it really that difficult/impossible to implement driver providing such a feature? Is it software or hardware difficulty?
I assume that TCP/IP protocols' specifications doesn't limit us at all because if I attach multiple WNICs to my computer, I can easily connect to multiple APs.
If it's software difficulty, than what's the actual problem? Does Linux/Windows kernel or WNIC's drivers limits it? Or maybe system libraries (like libc on GNU/Linux systems)?
If it's hardware difficulty, what actually limits us? Antennas? Using single radio frequency at a time? If yes, than why can't we implement frequency hopping (like Kismet does)? Because of lost packets during time spent on other channels? If yes, than can we associate WNIC with multiple routers working on the same channel (I know that channel overlapping is bad)?
Note: I'm not talking about dual band routers. I assume that we consider most common WNIC and AP which both work on 2.4GHz channels. If I have to put my question into OS context, than I choose GNU/Linux context.
Yes. The basic technique is that the client tells AP 'A' that it is going to sleep and then talks to AP 'B' while A is buffering frames for it.
Microsoft research worked this out a while ago:
http://research.microsoft.com/en-us/um/redmond/projects/virtualwifi/
Many low-level drivers support Wi-Fi interface virtualization (e.g. the BRCM wl command has options which support this).
Apple's AirDrop and MultiPeer features for OS X and iOS use a similar technique, but instead of talking to a 2nd AP they talk to a peer device.
I can't seem to find a good comprehensive list of available ioctls for netbsd.
I am looking to do some operations on harddisk (getting size, physical sector size, model). I have the code working in linux. It looks something like this, I removed errors etc to make it more compact:
ioctl(fileno(driveptr[i]),HDIO_GET_IDENTITY,&hd);
ioctl(fileno(driveptr[i]),BLKGETSIZE64,&drivesize[i]);
ioctl(fileno(driveptr[i]),BLKPBSZGET,&psztemp);
Is there an equivalent to these ioctls in netbsd?
regards
The driver source for a given type of disk interface (or any other kind of device driver) is probably the best canonical place to find device specific ioctls.
NetBSD at a systems level, like many unix-based systems, tries hard to avoid being hardware specific, even in terms of providing detailed hardware specific information to user level. The goal of unix, after all, is to provide a system that is uniform across a wide variety of hardware platorms, not to provide detailed low-level access to specific hardware. The very best you can get in terms of hardware specific details is the information printed by the drivers at boot time about the hardware as it is probed and attached.
At a more generic level you can basically only get disk and partition labels -- i.e. information pertinent to the way the system presents disk devices to userland. Unfortunately the only driver manual page that documents these is sd(4) (cd(4) has some more detail about more ioctls specific to cd-rom devices). scsi(4) documents bus-level ioctls for SCSI and ATAPI interfaces.
On x86 platforms there's "sysctl machdep.diskinfo" (and the equivalent C level interface via sysctl(3)) to get details about what the BIOS reported about the disks it knew about at boot time, but that may be incomplete.
My laptop has two video cards, a high powered NVIDIA one and an onboard Intel one. When I call IDirect3D9::GetAdapterCount however, it only finds the onboard Intel one, probably because the high powered one is being hidden.
I'm able to go into my laptop settings and tell it 'force choose' the NVIDIA card, and then it works, but this is not an acceptable solution for my end-users. I've also noticed that when I run Battlefield3, it's able to properly find the NVIDIA card even without 'force choose' enabled. Maybe there's a special white-list that has Battlefield listed? Or some other secret method?
Any ideas how to acquire that elusive card?
Are you sure the intel chip is enumeratable? Quite often its not. By sticking in a discrete GPU the sandybridge (and older) chipset is generally disabled. You probably want to check the Nvidia optimus test tool.
GetAdapterCount will actually returns count of the monitors in system, not videocards. And as far as I know there is no way to force choose it programmatically.
If you talking about nVidia optimus technology, it choose videochip using driver settings.
My and my fellow students are deciding on a choosing a simple microcontroller to do very basic image processing. We are basically trying to implement template matching to find a set of objects in specific portions of the image. We'd like to use a connect a webcam to the microcontroller to do the job take the pictures and look for the objects. We also require basic wireless communication (e.g. bluetooth or wifi).
I don't think we will have the luxury of using state-of-the-art microcontroller, but something thats been around for a while (due to budget and stuff). Could anyone please advise on which specs of the microcontrolelr would be the most relevant for the above task (e.g. CPU, MIPS, etc).
Thanks a lot!
For this kind of a task, I would say the amount of RAM is the most relevant spec.
A microcontroller with an external memory interface allows you to extend the data space with additional SRAM to hold your image data.
Also note, that memory is needed for any protocol stacks you need to implement (Bluetooth, TCP/IP even more so).
You probably want to have total RAM in tens of kilobytes, preferably 100+ kB.
It is also nice to have plenty of program memory available when learning and experimenting. Later on you can try to optimize and squeeze your code into a more confined device.
As for the architecture, choose something you can easily find development tools and examples for.ARM, AVR and PIC are all good candidates among others.
Also find out what interfaces you need to use to
control the camera (e.g. I2C or SPI)
read pixel data (e.g. parallel or analog)
Connecting directly to a webcam's USB interface would not be a straightforward task, as the microcontroller would need to act as a USB host.
Good luck with your project!
You may need a microcontroller with following features:
USB 2.0 Host controller
1.2MB of memory for buffer 640*480*2(bytes per pixel)*2(double buffer)
(you may use lower resolution if there are not enough memory)
Wifi controller
CPU power strong enough for your task
Ready open source code
It seems that broadcom controllers may be useful here.
Also, you can by off-the-shell Wifi router with usb port and use it for your project
(i.e. Linksys E3000 )
This is a homework problem that I have. I have been doing some research and couldn't find much. I did find a powerpoint but could not make much sense of it due to lack of text.
http://xen.org/files/xensummit_tokyo/19_KoichiOnoue_en.pdf
(Specifically, what is gPa and hPa?)
I was wondering if anyone could point me in the correct direction of where to look next.
Here is the question:
Explain how one could virtualize system calls issued by Pguest so that they are serviced by kernel code of the guest OS (mapped into the address space of Pguest). How do you differentiate and control the switching between application and kernel stacks in Pguest? In your answer, include a diagram that shows how control is redirected between various parts of memory, to handle virtualized system calls.
Any help would be appreciated!
These are "guest physical address" and "host physical address".
I hesitate to go into too much detail when it is coursework. You need to do the legwork yourself or you will not learn the material and you risk failing the exams/tests.
Hopefully you know how memory-mapping works at the OS kernel and CPU levels. You will find lots more material if you just search Google for the three keywords gpa hpa and VM.