Writing device drivers: How to access a specific memory area?
Hello all, I am writing a driver which needs to access memory at a specific location. The location depends on what the BIOS has configured into the host bridge. For example, my current machine uses an Intel 975X chipset and the memory location I am interested in has been set to 0xFED14000 and is 16KB in size (this is MCHBAR of the 975X memory hub). I have no idea how to access this space from my driver. I have played around with bus_alloc_resource() but this only gives me back NULL. However, a devinfo -r gives me: nexus0 npx0 acpi0 Interrupt request lines: 9 I/O ports: 0x10-0x1f ... 0x800-0x87f I/O memory addresses: 0x0-0x9 0xc-0xd 0xe-0xf 0x10-0x7fff 0xf000-0xf3ff 0xfec0-0xfec00fff 0xfed13000-0xfed19fff <--- 0xfed1c000-0xfed1 0xfed2-0xfed3 0xfed5-0xfed8 0xfee0-0xfee00fff 0xffb0-0xffbf 0xfff0-0x cpu0 ... The line marked with <--- shows the range which includes the location I am interested in. It is probably assigned to the acpi0 device. How do I proceed from this? Do I have to hack around in the ACPI-Code? I don't hope so ;-) I only need access to this memory location during the probe of my driver to read some configuration data. I do not need to access it later anymore... Thanks a lot for any hints, -Andre ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Writing device drivers: How to access a specific memory area?
On 25 Dec 2008, at 09:53, Andre Albsmeier wrote:
Hello all,
I am writing a driver which needs to access memory at a
specific location. The location depends on what the BIOS
has configured into the host bridge. For example, my
current machine uses an Intel 975X chipset and the memory
location I am interested in has been set to 0xFED14000 and
is 16KB in size (this is MCHBAR of the 975X memory hub).
You probably just need to do something like:
rid = PCI_BAR(number);
res = bus_alloc_resource_any(dev, SYS_RES_MEMORY, &rid, RF_ACTIVE);
And then,
bus_read_4(res, offset from specified PCI BAR);
I have no idea how to access this space from my driver.
I have played around with bus_alloc_resource() but this
only gives me back NULL.
However, a devinfo -r gives me:
nexus0
npx0
acpi0
Interrupt request lines:
9
I/O ports:
0x10-0x1f
...
0x800-0x87f
I/O memory addresses:
0x0-0x9
0xc-0xd
0xe-0xf
0x10-0x7fff
0xf000-0xf3ff
0xfec0-0xfec00fff
0xfed13000-0xfed19fff <---
0xfed1c000-0xfed1
0xfed2-0xfed3
0xfed5-0xfed8
0xfee0-0xfee00fff
0xffb0-0xffbf
0xfff0-0x
cpu0
...
The line marked with <--- shows the range which includes
the location I am interested in. It is probably assigned
to the acpi0 device.
How do I proceed from this? Do I have to hack around in
the ACPI-Code? I don't hope so ;-)
You'll probably need to create a fake ACPI child driver to access it.
Create your identify routine with something like:
static void mydriver_identify(driver_t *driver, device_t parent)
{
if (device_find_child(parent, "mydriver", -1) == NULL &&
mydriver_match(parent))
device_add_child(parent, "mydriver", -1);
}
mydriver_match() should check if you were given the acpi0 device.
I only need access to this memory location during the
probe of my driver to read some configuration data.
Is this pci configuration space ? If so, pci_read_config (man 9 pci)
should be just what you need.
Regards,
--
Rui Paulo
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
netapp dump/freebsd restore problem
Hi, Some years ago I solved the problem (some swab issue) by a one line fix to restore/tape.c, so 'rsh netapp dump ...| restore ...' worked. Now, while experimenting with zfs, we are tying to see if we can dump the netapp onto a zfs for backup, but alas, the dumprestore.h has changed. So, has anyone 1- the dumprestore.h/u_spcl from NetAPP 2- a restore that works. if not, then i'll have to do some reverse engineering ... danny PS: Season's greetings and a happy New Year! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
How to quickly determine if UFS2 FS is "clean" from command line?
At work, we have some machines we're setting up that have a fair amount of UFS2 "scratch space." While we would prefer to leave the file systems in question intact iff they are "clean," we do not want to run fsck(8) against them if they are not (because we expect that it would take too long); rather, we want to merely recreate them (with newfs(8)). While I might be able to hack something together by cribbing appropriate bits of fsck_ffs(8), I'm a great deal more comfortable cobbling up glue scripts and the like -- I don't fancy myself all that much of a C coder. Anyone know of a reasonable way to quickly determine whether or not a UFS2 file system is clean from the command line? Thanks! Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgp83q6YVvpux.pgp Description: PGP signature
Re: How to quickly determine if UFS2 FS is "clean" from command line?
On Thu, 25 Dec 2008 17:14:02 -0800 David Wolfskill wrote: > At work, we have some machines we're setting up that have a fair > amount of UFS2 "scratch space." > > While we would prefer to leave the file systems in question intact > iff they are "clean," we do not want to run fsck(8) against them > if they are not (because we expect that it would take too long); > rather, we want to merely recreate them (with newfs(8)). > > While I might be able to hack something together by cribbing > appropriate bits of fsck_ffs(8), I'm a great deal more comfortable > cobbling up glue scripts and the like -- I don't fancy myself all > that much of a C coder. > > Anyone know of a reasonable way to quickly determine whether or not > a UFS2 file system is clean from the command line? dumpfs will tell you the status of the 'clean' flag: dumpfs /dev/ad0s1d | grep clean That will output a line like: cgrotor 0 fmod 0 ronly 0 clean 1 Just like with fsck you can also tell dumpfs the previous mountpoint too and it'll use the right device. -- Bruce Cran ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: How to quickly determine if UFS2 FS is "clean" from command line?
On Fri, Dec 26, 2008 at 01:22:24AM +, Bruce Cran wrote: > ... > > Anyone know of a reasonable way to quickly determine whether or not > > a UFS2 file system is clean from the command line? > > dumpfs will tell you the status of the 'clean' flag: > > dumpfs /dev/ad0s1d | grep clean > > That will output a line like: > > cgrotor 0 fmod 0 ronly 0 clean 1 > > Just like with fsck you can also tell dumpfs the previous mountpoint > too and it'll use the right device. So this is quite useful. A reality check later, I find that for the file systems in question, dumpfs(8) produces the wanted information (and quite a bit more) nearly instantly, then spends about 33 seconds dumping cylinder group information that I have no interest in. While I admitted not being much of a C coder, I have been known to hack a bit :-} I also see that the dumpfs(8) code has been fairly static in the last couple of years. Would anyone else be interested in a hack to dumpfs(8) in the form of a command line flag (e.g., "-s" -- as in "short" or "super block only") to tell it to just spit out the FS super block information and skip the cylinder group stuff? (The command presently has but one command line flag; it is "-m" and is optional; if present, it causes the program to spit out a newfs(8) invocation to re-create the file system in question.) I'd be willing to cobble it up, test it, and submit a PR Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpP0tQA3pwyX.pgp Description: PGP signature
Re: How to quickly determine if UFS2 FS is "clean" from command line?
On Thu, 25 Dec 2008 17:49:56 -0800 David Wolfskill wrote: > A reality check later, I find that for the file systems in question, > dumpfs(8) produces the wanted information (and quite a bit more) > nearly instantly, then spends about 33 seconds dumping cylinder group > information that I have no interest in. I only ran it on a 2GB filesystem so I didn't see how slow it is! It looks like ffsinfo(8) can also display the superblock: by specifying only level 0x001 it should be fast, though the flags are combined into a single value in the output. -- Bruce Cran ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: How to quickly determine if UFS2 FS is "clean" from command line?
On Fri, Dec 26, 2008 at 09:35:42AM +0300, Sergey Zaharchenko wrote: > ... > Some of the stuff you want can be found here: > > r...@shark:~# file -s /dev/ufs/home > /dev/ufs/home: Unix Fast File system [v2] (little-endian) last mounted on > /home, volume name home, last written at Fri Dec 26 06:33:07 2008, clean flag > 0, readonly flag 0, number of blocks 13631488, number of data blocks > 13202246, number of cylinder groups 145, block size 16384, fragment size > 2048, average file size 16384, average number of files in dir 64, pending > blocks to free 4, pending inodes to free 0, system-wide uuid 0, minimum > percentage of free blocks 8, TIME optimization > > You probably want the clean flag (which is 0 for me because that device > node is mounted). Very nice; thanks! Seems that both ffsinfo(8) & file(1) can do the job quickly; dumpfs(8) can do it, but takes around 33 seconds for a 400 GB file system (because it also dumps the cylinder groups). Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgp8eA2go6WCC.pgp Description: PGP signature
Re: How to quickly determine if UFS2 FS is "clean" from command line?
Hello David! Thu, Dec 25, 2008 at 05:49:56PM -0800 you wrote: > Would anyone else be interested in a hack to dumpfs(8) in the form > of a command line flag (e.g., "-s" -- as in "short" or "super block > only") to tell it to just spit out the FS super block information > and skip the cylinder group stuff? Some of the stuff you want can be found here: r...@shark:~# file -s /dev/ufs/home /dev/ufs/home: Unix Fast File system [v2] (little-endian) last mounted on /home, volume name home, last written at Fri Dec 26 06:33:07 2008, clean flag 0, readonly flag 0, number of blocks 13631488, number of data blocks 13202246, number of cylinder groups 145, block size 16384, fragment size 2048, average file size 16384, average number of files in dir 64, pending blocks to free 4, pending inodes to free 0, system-wide uuid 0, minimum percentage of free blocks 8, TIME optimization You probably want the clean flag (which is 0 for me because that device node is mounted). HTH, -- DoubleF No virus detected in this message. Ehrm, wait a minute... /kernel: pid 56921 (antivirus), uid 32000: exited on signal 9 Oh yes, no virus:) pgpFrAELzWrIl.pgp Description: PGP signature
