I want to write to BIOS, I know that it is required to disable write protection and more things that can be founded on the PCH datasheet (intel's case).
If I want to write to BIOS, first I have to know the address space of it. I have looked for information on the internet, but I have found nothing.
Is there any place to look at for that information?
Related
I've an issue with my current micropython project on my ESP8266. I've a 10x10 LED matrix which i would like to control via 4 shift registers.
In general 3 pins are required for the controlling DATA, LATCH and CLOCK. After some hours of internet searching the most promising solution was the usage of SPI, where also found some useful instructions for the pyboard (thank you for the code btw):
https://forum.micropython.org/viewtopic.php?t=1219
I tried to replace the pyboard specific librarys with the general machine module for the ESP8266 to get access to the SPI class. It worked fine till a specific point but the main issue at the moment is that it was not capable provide a binary signal at the DATA pin.
To be honest I'm a little bit confused about the write methods in the machine.SPI class. The docu says the return value is None. So in general what is the purpose of a write method with a return value of None (sry for the maybe silly question)
Is there maybe another solution to get a binary signal out of the data pin? I'm not sure anymore if the usage of SPI is the best way to manage the controlling. Do you have some other examples or tutorials to get deeper into the topic?
Thank you for your kind response in advance,
BR charlzo
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.
I have question how to generate unique serial number of machine in Delphi? I tried to do this using the ID the motherboard or processor, but unfortunately it's unfortunately supported. Partition serial numbers, etc. fall off, because it is changing after the formatted. I'm looking for something that doesn't change after the formatted. Has anyone any idea?
Inside JCL library, there are several functions very usefull for this topic:
function CPUID: TCpuInfo;
function GetMacAddresses(const Machine: string; const Addresses: TStrings): Integer;
function GetVolumeSerialNumber(const Drive: string): string;
function GetBIOSName: string;
What you're after is actually some sort of "hardware fingerprint", not an "serial number". The problem with this approach is that it's not 100% reliable. Proof: Microsoft didn't manage to find a way to properly limit OEM software to any single computer, you can actually re-install a OEM license on a new computer after a while! Once you agree there can't be a perfect solution you may look at your options and try getting something that's good enough.
For my applications I'm creating a fingerprint based on info returned by GetSystemInfo, GetVolumeInformation and (for the 'C:' partition) and a selection of registry keys from HKLM\HARDWARE (lots of registry keys actually, everything but usb, keyboard and mouse stuff). I'm reading hardware information from the registry because a Windows application can't really access hardware directly (DOS-style approaches can't work), and because I don't have time to figure out ways to determine hardware-related information for many different devices.
My approach has the following disadvantages:
Uses the partition serial number, as set up by Format. An format would clearly change the fingerprint.
Uses information about the installed drivers. Updating an driver might actually change the fingerprint! Moving a card from one PCI port to an other might change the fingerprint.
None the less, even with all of this changing information taken into account, I get collisions: Something like 1/1000 computers! There are several factors at work here:
Big OEM build many computers using the same hardware. They also clone HDD's in order to speed up software installation so different PC's might get the same partition serial number.
I'm building a very short hash from all that information, short enough so people can read it to me on the phone without too many mistakes.
This system works for me, but it will not work for you if you expect to re-identify computers once they're reinstalled.
You can test GLibWMI that extract information of several components on Windows.
It's free and source included. You can find it on my Web or in Sourceforge.
alt text http://img175.imageshack.us/img175/1250/imagen344.png
Include components for BIOSInfo, DiskInfo, ProcessorInfo,...
With this three components you can obtain information like this:
alt text http://img690.imageshack.us/img690/6006/imagen349.png
You can find the BIN/EXE of GenericDemo (all components) here; You can test all information that you can retrive with this components.
I had a similar problem back in the good old DOS days. I found out that the ROM of the installed hardware ie. video card, disk controllers seriel ports etc. was accessible directly, since they are memory-mapped. This means that I was able to create a list of installed hardware, and use it to generate a "serial number", that uniquely identified each computer (until the hardware setup was changed). I'm sure something similar is possible today as well.
Check out http://duartes.org/gustavo/blog/post/motherboard-chipsets-memory-map, if you want to use this approach.
Regards
Frank
Often the MAC address of the (a) network card is used, there are several ways to query the mac address (in Delphi) but the easiest/cleanest way is probably to use the GetAdaptersInfo API.
Here is a simple solution
Generate a GUID
Save the Guid value in the registry
Use the value of the guid as the serial number
If you a worried about security use a
hash over the ( Guid + some secret data)
I tend to agree with the "it can't be done" camp. At least not 100%, but it can probably be done "good enough" to keep the average user in line.
And if it can be done then it probably has been done. Did you check Torry's Delpi300, etc (maybe even sourceforge, although you might have to translate into Delphi).
http://www.google.com.sg/search?hl=en&source=hp&q=How+to+generate+unique+serial+number+of+machine+in+Delphi actually looks promising
Is it possible to get location data out of Google Gears, Google Gelocation API or any other web location API (such as Fire Eagle) in such a format that it appears to other software as a GPS device?
It occured to me reading these answers to my question regarding WiFi location finding, on Super User, that if I could emulate a GPS unit, many of these web services could act as a 'poor-mans' GPS to otherwise less useful software that requires it.
Is GPSD an option?
Preferably OSX & Python, but I would be interested in any implementation.
There is a very similar thread on a Python mailinglist that mentions Windows virtual COM ports and discusses Unix's pseudo-tty capabilities. If the app(s) you want to use let you type in a specific tty device file, this may be the easiest route. (Short of asking the authors to provide a plugin API for what you're trying to do, or buying yourself a $20 bluetooth GPS mouse.)
Are you using OS X?
There is a project macosxvirtualserialport on Google code that provides a graphical wrapper around some of the features of a utility called socat. I'd recommend taking a look at socat if you see potential in the pseudo-tty route. I believe you could use socat to link a pipe from a Python program to a pseudo-tty.
Most native Mac apps will be querying IOServiceMatching for a device with kIOSerialBSDRS232Type, and I doubt that a pseudo-tty will show up as an IOKit service.
In this case, unless you can find a project that has already implemented such a thing, you will need to implement a driver as described in this How to create virtual COM port thread. If you're going to the trouble of create a device driver, you would want to base it on IOKit because of that likely IOServiceMatching query. You can find the Apple16X50Serial project mentioned in that post at the top of Apple's open source code list (go to the main page and pick an older OS release if you want to target something pre-10.6).
If your app is most useful with realtime data (e.g. the RouteBuddy app mentioned in the Python mailinglist thread can log current positions) then you will want to fetch updates from your web sources (hopefully they support long-polling) and convert them to basic NMEA RMC sentences. You do not want to do this from inside your driver code. Instead, divide your work up into kernel-land and user-land pieces that can communicate, and put as little of the code as possible into the kernel part.
If you want to let apps both read and write to these web services, your best bet would probably be to simulate a Garmin device. Garmin has more-or-less documented their protocol in the IntfSpec.pdf file included with their Device Interface SDK. Again, you'd want to split as much as you could into user-space code.
I was unable to find a project or utility that implements the kernel side of an IOKit-based virtual serial interface, but I'd be surprised if there wasn't one hiding somewhere out there. Unfortunately, most of the answers I found to that question were like this, with the developer being told to get busy writing a kext.
I'm not exactly sure how to accomplish what you're asking, but I may be able to lend some insight as to how you might begin to get it done. So here goes:
A GPS device shows up to most systems as nothing more than a serial device -- a.k.a. a COM port if you're dealing with Windows, /dev/ttySx if you're in *nix. By definition, a serial port's specific duty is to stream data across a bus, one block at a time. So, it would then follow logically that if you want to emulate the presence of a GPS device, you should gather the data you're consuming and put it into a stream that somehow acts like an active serial port.
There are, however, some complications you might want to consider:
Most GPS devices don't just send out location data; there's also information on satellite locations, fix quality, bearing, and so on. Then again, nobody's made any rules saying you have to make all that data available. There's probably more to this, but I'll admit that I need to do more research in this area myself.
I'm not sure how fast you can receive data when dealing with Google Latitude, etc., but any delays in receiving would definitely result in visible pauses in your "serial port"'s data stream. Again, this may not be as big a complication as it seems, because GPS devices are known to "burst" data across the bus anyway, but I'd definitely keep an eye on that. You want to make sure there's always a surplus of data coming across, not a shortage.
Along the way you'll also have to transform the coordinates you receive into valid GPS sentences, as well. You can find specifications for those, but I would definitely make friends with the NMEA standard -- even though it is a flawed standard, it's the one everyone seems to agree on anyway.
Hope this helped you, at least a little bit. Are there anymore details specific to your problem that you think could be useful in answering this question?
Take a look to Franson GPS Gate which allows you to connect to Google Earth among other things (like simulating GPS and so on). Is windows only though but I think you could get some useful ideas from it.
I haven't looked into it very much, but have you considered using Skyhook's SDK? It might provide you with some of what you are looking for. It's available for every major desktop and mobile OS.
I know that the write protect tab in SD cards is not a real hardware protection, but a simple signal to the reader that the card is write protected. For example, the CHDK project for Canon cameras specifically ignores it, and once had a cheap flash reader ($2 by mail from Hong Kong) which didn't recognize it.
Is there any way (registry hack, custom driver, anything) on Windows to prevent this flag from being set? I'd like my SDHC reader to also ignore the write protect tab; has anyone ever heard / seen such a thing before?
I'm not sure about any registry but the controller MUST support such feature (or lack of feature ^_^)
from a driver point of view, I doubt this is standardized.
Good luck