* Re: [parisc-linux] enumerating devices from user space
@ 2003-03-13 10:22 Lyonel Vincent
2003-03-13 11:30 ` bruno_vidal
0 siblings, 1 reply; 17+ messages in thread
From: Lyonel Vincent @ 2003-03-13 10:22 UTC (permalink / raw)
To: parisc-linux
If you can find this, I will be VERY interested in having a look at it...
Thinking of it, this HP guy may well be me ;o)
You can contact me privately, it may happen that I know your instructor.
cheers,
lv.
> Being as I just got done with a class from HP Education on Linux, this very
> issue was brought up by all of us HP-UX guys. We love our IOSCAN. The
> instructor told us that someone within HP actually wrote an "ioscan" for
> Red Hat. I'm thinking that getting a copy of that source code would be a
> good place to start. I'm going to do a search for the guy tomorrow or get
> his name from our instructor to see if I can get a hold of his code.
>
> derek
--
The software said it requires Windows 2000 or better, so I installed Linux.
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [parisc-linux] enumerating devices from user space 2003-03-13 10:22 [parisc-linux] enumerating devices from user space Lyonel Vincent @ 2003-03-13 11:30 ` bruno_vidal 2003-03-13 12:45 ` Lyonel Vincent 0 siblings, 1 reply; 17+ messages in thread From: bruno_vidal @ 2003-03-13 11:30 UTC (permalink / raw) To: parisc-linux [-- Attachment #1: Type: text/plain, Size: 718 bytes --] Hi guys. While developping the dump modules, I had to find a way to retrieve the hardware path of disk/hba. So I had to developpe a small hack in the kernel/firmware.c in order to retrive the right hba. But it is parisc dependant. Do you want I try to add an ioctl in my dump modules in order to print in user space this informations ? Example: size:1500160 nr_sects:3000320 start_sect:374784 hwpath: 0/0/1/1.15.0.0. dump device opened: 0x813 with index: 0 at hpa: 0x900 So my functions are able to print the hw path of each io modules. Is it what you are looking for ? -- Vidal Bruno, (770-4271) SSD-HA Team, HP-UX & LINUX Support bruno_vidal@admin.france.hp.com [-- Attachment #2: Card for --] [-- Type: text/x-vcard, Size: 386 bytes --] begin:vcard n:Bruno;VIDAL tel;fax:01-69-82-60-14 tel;work:01-69-29-42-71 x-mozilla-html:TRUE url:www.france.hp.com org:Solution Center version:2.1 email;internet:bruno_vidal@hp.com title:Expert Logiciel Environnement Haute Disponibilité adr;quoted-printable:;;HP France=0D=0A;Z.A de Courtaboeuf;1 Av. du Canada;91947 Les Ulis cedex;France x-mozilla-cpt:;26208 fn:VIDAL Bruno end:vcard ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [parisc-linux] enumerating devices from user space 2003-03-13 11:30 ` bruno_vidal @ 2003-03-13 12:45 ` Lyonel Vincent 2003-03-14 8:45 ` bruno_vidal 0 siblings, 1 reply; 17+ messages in thread From: Lyonel Vincent @ 2003-03-13 12:45 UTC (permalink / raw) To: bruno_vidal; +Cc: parisc-linux Hi Bruno, That sounds like what I was looking for (HW path + version information)! What do you think is the best approach? cheers, lv. On Thu, 13 Mar 2003 12:30:44 +0100 bruno_vidal@hp.com wrote: > Hi guys. > While developping the dump modules, I had to find a way to retrieve > the hardware path of disk/hba. So I had to developpe a small hack > in the kernel/firmware.c in order to retrive the right hba. > But it is parisc dependant. Do you want I try to add an ioctl in my > dump modules in order to print in user space this informations ? > Example: > > size:1500160 nr_sects:3000320 start_sect:374784 > hwpath: 0/0/1/1.15.0.0. > dump device opened: 0x813 with index: 0 at hpa: 0x900 > > So my functions are able to print the hw path of each io modules. > Is it what you are looking for ? > > -- > Vidal Bruno, (770-4271) > SSD-HA Team, HP-UX & LINUX Support > bruno_vidal@admin.france.hp.com > > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [parisc-linux] enumerating devices from user space 2003-03-13 12:45 ` Lyonel Vincent @ 2003-03-14 8:45 ` bruno_vidal 2003-03-14 12:33 ` Lyonel Vincent 0 siblings, 1 reply; 17+ messages in thread From: bruno_vidal @ 2003-03-14 8:45 UTC (permalink / raw) To: Lyonel Vincent; +Cc: parisc-linux [-- Attachment #1: Type: text/plain, Size: 1683 bytes --] Hi I'll try to add an ioctls in my dump driver to print this list. It will give a good starting point, isn't it ? The other choice is to create a new modules that use my functions in firmware.c. But keep in mind that it will usefull only for pa-risc. I don't know if it is the best practice. cheers. Lyonel Vincent wrote: > Hi Bruno, > > That sounds like what I was looking for (HW path + version information)! > What do you think is the best approach? > > cheers, > lv. > > On Thu, 13 Mar 2003 12:30:44 +0100 > bruno_vidal@hp.com wrote: > > > Hi guys. > > While developping the dump modules, I had to find a way to retrieve > > the hardware path of disk/hba. So I had to developpe a small hack > > in the kernel/firmware.c in order to retrive the right hba. > > But it is parisc dependant. Do you want I try to add an ioctl in my > > dump modules in order to print in user space this informations ? > > Example: > > > > size:1500160 nr_sects:3000320 start_sect:374784 > > hwpath: 0/0/1/1.15.0.0. > > dump device opened: 0x813 with index: 0 at hpa: 0x900 > > > > So my functions are able to print the hw path of each io modules. > > Is it what you are looking for ? > > > > -- > > Vidal Bruno, (770-4271) > > SSD-HA Team, HP-UX & LINUX Support > > bruno_vidal@admin.france.hp.com > > > > > > _______________________________________________ > parisc-linux mailing list > parisc-linux@lists.parisc-linux.org > http://lists.parisc-linux.org/mailman/listinfo/parisc-linux -- Vidal Bruno, (770-4271) SSD-HA Team, HP-UX & LINUX Support bruno_vidal@admin.france.hp.com [-- Attachment #2: Card for --] [-- Type: text/x-vcard, Size: 386 bytes --] begin:vcard n:Bruno;VIDAL tel;fax:01-69-82-60-14 tel;work:01-69-29-42-71 x-mozilla-html:TRUE url:www.france.hp.com org:Solution Center version:2.1 email;internet:bruno_vidal@hp.com title:Expert Logiciel Environnement Haute Disponibilité adr;quoted-printable:;;HP France=0D=0A;Z.A de Courtaboeuf;1 Av. du Canada;91947 Les Ulis cedex;France x-mozilla-cpt:;26208 fn:VIDAL Bruno end:vcard ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [parisc-linux] enumerating devices from user space 2003-03-14 8:45 ` bruno_vidal @ 2003-03-14 12:33 ` Lyonel Vincent 2003-03-14 13:19 ` Matthew Wilcox 0 siblings, 1 reply; 17+ messages in thread From: Lyonel Vincent @ 2003-03-14 12:33 UTC (permalink / raw) To: bruno_vidal; +Cc: parisc-linux Hi Bruno, The ioctl sounds great to me. On which device would you "attach" it (as some of the devices I'd like to report don't even have an entry in /dev), create a new one? Correct me if I'm wrong (I don't know much about IOCTLs) If you want me to help testing/developing, I have a 9000/C180 w/ Debian (unstable) ready to use. cheers, lv. PS: being PA-RISC dependent is not a problem, I already have ifdefs for x86, PowerPC and Alpha On Fri, 14 Mar 2003 09:45:59 +0100 bruno_vidal@hp.com wrote: > Hi > I'll try to add an ioctls in my dump driver to print this list. It > will give a good starting point, isn't it ? > The other choice is to create a new modules that use my functions > in firmware.c. But keep in mind that it will usefull only for pa-risc. > I don't know if it is the best practice. > > cheers. > > Lyonel Vincent wrote: > > > Hi Bruno, > > > > That sounds like what I was looking for (HW path + version > > information)! What do you think is the best approach? > > > > cheers, > > lv. > > > > On Thu, 13 Mar 2003 12:30:44 +0100 > > bruno_vidal@hp.com wrote: > > > > > Hi guys. > > > While developping the dump modules, I had to find a way to > > > retrieve the hardware path of disk/hba. So I had to developpe a > > > small hack in the kernel/firmware.c in order to retrive the right > > > hba. But it is parisc dependant. Do you want I try to add an ioctl > > > in my dump modules in order to print in user space this > > > informations ? Example: > > > > > > size:1500160 nr_sects:3000320 start_sect:374784 > > > hwpath: 0/0/1/1.15.0.0. > > > dump device opened: 0x813 with index: 0 at hpa: 0x900 > > > > > > So my functions are able to print the hw path of each io modules. > > > Is it what you are looking for ? > > > > > > -- > > > Vidal Bruno, (770-4271) > > > SSD-HA Team, HP-UX & LINUX Support > > > bruno_vidal@admin.france.hp.com > > > > > > > > > > _______________________________________________ > > parisc-linux mailing list > > parisc-linux@lists.parisc-linux.org > > http://lists.parisc-linux.org/mailman/listinfo/parisc-linux > > -- > Vidal Bruno, (770-4271) > SSD-HA Team, HP-UX & LINUX Support > bruno_vidal@admin.france.hp.com > > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [parisc-linux] enumerating devices from user space 2003-03-14 12:33 ` Lyonel Vincent @ 2003-03-14 13:19 ` Matthew Wilcox 2003-03-14 14:05 ` Lyonel Vincent 0 siblings, 1 reply; 17+ messages in thread From: Matthew Wilcox @ 2003-03-14 13:19 UTC (permalink / raw) To: Lyonel Vincent; +Cc: bruno_vidal, parisc-linux On Fri, Mar 14, 2003 at 01:33:05PM +0100, Lyonel Vincent wrote: > The ioctl sounds great to me. It sounds like an awful idea to me. I'll never take that kind of patch into my tree. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [parisc-linux] enumerating devices from user space 2003-03-14 13:19 ` Matthew Wilcox @ 2003-03-14 14:05 ` Lyonel Vincent 2003-03-14 14:08 ` Matthew Wilcox 0 siblings, 1 reply; 17+ messages in thread From: Lyonel Vincent @ 2003-03-14 14:05 UTC (permalink / raw) To: Matthew Wilcox; +Cc: bruno_vidal, parisc-linux okokok I won't argue then. I would have liked to have ioscan-like support, but anyway... On Fri, 14 Mar 2003 13:19:21 +0000 Matthew Wilcox <willy@debian.org> wrote: > On Fri, Mar 14, 2003 at 01:33:05PM +0100, Lyonel Vincent wrote: > > The ioctl sounds great to me. > > It sounds like an awful idea to me. I'll never take that kind of > patch into my tree. > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [parisc-linux] enumerating devices from user space 2003-03-14 14:05 ` Lyonel Vincent @ 2003-03-14 14:08 ` Matthew Wilcox 2003-03-14 17:29 ` Grant Grundler 0 siblings, 1 reply; 17+ messages in thread From: Matthew Wilcox @ 2003-03-14 14:08 UTC (permalink / raw) To: Lyonel Vincent; +Cc: Matthew Wilcox, bruno_vidal, parisc-linux On Fri, Mar 14, 2003 at 03:05:49PM +0100, Lyonel Vincent wrote: > okokok I won't argue then. > I would have liked to have ioscan-like support, but anyway... Well, you can have it in 2.5; start looking at sysfs. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [parisc-linux] enumerating devices from user space 2003-03-14 14:08 ` Matthew Wilcox @ 2003-03-14 17:29 ` Grant Grundler 2003-03-17 13:53 ` Lyonel Vincent 0 siblings, 1 reply; 17+ messages in thread From: Grant Grundler @ 2003-03-14 17:29 UTC (permalink / raw) To: Matthew Wilcox; +Cc: Lyonel Vincent, bruno_vidal, parisc-linux On Fri, Mar 14, 2003 at 02:08:48PM +0000, Matthew Wilcox wrote: > On Fri, Mar 14, 2003 at 03:05:49PM +0100, Lyonel Vincent wrote: > > okokok I won't argue then. > > I would have liked to have ioscan-like support, but anyway... > > Well, you can have it in 2.5; start looking at sysfs. willy and I talked offline and it seems like the right answer is to backport _the user interface_ - ie something that *looks* like sysfs but could be based on /proc. I'd basically like to see all resources in struct parisc_device exported using the same name as the field - matching sysfs field names use for PCI where appropriate. Willy suggested id be broken out into it's struct parisc_device_id parts and provided directly has hex strings (eg hw_type entry could contain "0x5"). Details of how sysfs currently looks are still changing - don't get hung up in the current details. grant ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [parisc-linux] enumerating devices from user space 2003-03-14 17:29 ` Grant Grundler @ 2003-03-17 13:53 ` Lyonel Vincent 0 siblings, 0 replies; 17+ messages in thread From: Lyonel Vincent @ 2003-03-17 13:53 UTC (permalink / raw) To: Grant Grundler; +Cc: Matthew Wilcox, bruno_vidal, parisc-linux Hi Grant, sounds very good to me (and way cleaner)... I'll be happy to try to help. cheers, lv. On Fri, Mar 14, 2003 at 10:29:24AM -0700, Grant Grundler wrote: > On Fri, Mar 14, 2003 at 02:08:48PM +0000, Matthew Wilcox wrote: > > On Fri, Mar 14, 2003 at 03:05:49PM +0100, Lyonel Vincent wrote: > > > okokok I won't argue then. > > > I would have liked to have ioscan-like support, but anyway... > > > > Well, you can have it in 2.5; start looking at sysfs. > > willy and I talked offline and it seems like the right > answer is to backport _the user interface_ - ie something > that *looks* like sysfs but could be based on /proc. > > I'd basically like to see all resources in struct parisc_device > exported using the same name as the field - matching sysfs field > names use for PCI where appropriate. Willy suggested id be broken > out into it's struct parisc_device_id parts and provided > directly has hex strings (eg hw_type entry could contain "0x5"). > Details of how sysfs currently looks are still changing - don't get > hung up in the current details. > > grant -- The software said it requires Windows 2000 or better, so I installed Linux. ^ permalink raw reply [flat|nested] 17+ messages in thread
* [parisc-linux] enumerating devices from user space @ 2003-03-12 16:32 Lyonel Vincent 2003-03-12 16:48 ` Matthew Wilcox 0 siblings, 1 reply; 17+ messages in thread From: Lyonel Vincent @ 2003-03-12 16:32 UTC (permalink / raw) To: parisc-linux Hi there, I'm currently implementing a small tool called lshw (you can find it on Freshmeat) that enumerates installed devices on a machine and reports them as a device tree (text, HTML and XML). For now it knows about DMI, PCI busses, SCSI, IDE and PCMCIA and I would like to port it to PA-RISC Linux. I already get some very basic info from /proc/cpuinfo. Does anyone know how I can access the device tree as seen by the kernel? (much like HP-UX's ioscan does and what is shown in dmesg) I've tried digging in /proc without much success... is there a way to get this information from user space? PPC Linux exposes the device tree in /proc for example. A mechanism similar to /proc/bus/pci/devices (machine- parseable text) would be great, too. thanks for your help, Lyonel. PS: I noticed that /proc/iomem lists 00000000-000009ff as "PDC data (Page Zero)", is there a chance I can find what I need there? (I dd-ed it from /dev/mem but I can't say if it contains useful data...) -- The software said it requires Windows 2000 or better, so I installed Linux. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [parisc-linux] enumerating devices from user space 2003-03-12 16:32 Lyonel Vincent @ 2003-03-12 16:48 ` Matthew Wilcox 2003-03-12 17:30 ` Lyonel Vincent 0 siblings, 1 reply; 17+ messages in thread From: Matthew Wilcox @ 2003-03-12 16:48 UTC (permalink / raw) To: Lyonel Vincent; +Cc: parisc-linux On Wed, Mar 12, 2003 at 05:32:36PM +0100, Lyonel Vincent wrote: > I'm currently implementing a small tool called lshw (you can find it on > Freshmeat) that enumerates installed devices on a machine and reports them > as a device tree (text, HTML and XML). That's cool. > For now it knows about DMI, PCI busses, SCSI, IDE and PCMCIA and I would > like to port it to PA-RISC Linux. I already get some very basic info from > /proc/cpuinfo. > Does anyone know how I can access the device tree as seen by the kernel? > (much like HP-UX's ioscan does and what is shown in dmesg) You can look in /var/log/dmesg. For example... Found devices: 1. U2-IOA BC Runway Port (12) at 0xfff88000 [8], versions 0x580, 0xf, 0xb 2. Dino PCI Bridge (13) at 0xf2000000 [8/0], versions 0x680, 0x0, 0xa, additional addresses: 0xf2800000 3. Raven U/L2 Dino PS/2 Port (10) at 0xf2001000 [8/1], versions 0x6, 0x0, 0x96 4. Raven U/L2 Dino RS-232 (10) at 0xf2003000 [8/3], versions 0x6, 0x0, 0x8c 5. Raven U/L2 Core FW-SCSI (4) at 0xf200c000 [8/12], versions 0x3b, 0x0, 0x89 6. Raven U/L2 Core BA (11) at 0xffd00000 [8/16], versions 0x3b, 0x0, 0x81, additional addresses: 0xffd0c000 0xffc00000 7. Raven U/L2 Core Centronics (10) at 0xffd02000 [8/16/0], versions 0x3b, 0x0, 0x74, additional addresses: 0xffd01000 0xffd03000 8. Raven U/L2 Core Audio (10) at 0xffd04000 [8/16/1], versions 0x3b, 0x4, 0x7b 9. Raven U/L2 Core RS-232 (10) at 0xffd05000 [8/16/4], versions 0x3b, 0x0, 0x8c 10. Raven U/L2 Core SCSI (10) at 0xffd06000 [8/16/5], versions 0x3b, 0x0, 0x82 11. Raven U/L2 Core LAN (802.3) (10) at 0xffd07000 [8/16/6], versions 0x3b, 0x0, 0x8a 12. Raven U/L2 Core PS/2 Port (10) at 0xffd08000 [8/16/7], versions 0x3b, 0x0, 0x84 13. Raven U/L2 Core PS/2 Port (10) at 0xffd08100 [8/16/8], versions 0x3b, 0x0, 0x84 14. Raven Backplane Wax BA (11) at 0xffe00000 [8/20], versions 0x17, 0x0, 0x8e 15. Raven Backplane Wax HIL (10) at 0xffe01000 [8/20/1], versions 0x17, 0x0, 0x73 16. Raven Backplane RS-232 (10) at 0xffe02000 [8/20/2], versions 0x17, 0x0, 0x8c 17. Raven Backplane Wax EISA BA (11) at 0xfc000000 [8/20/5], versions 0x17, 0x0, 0x90, additional addresses: 0xffc88000 0xfc00000b 18. Gecko GSC Core Graphics (10) at 0xfa000000 [8/24], versions 0x16, 0x0, 0x85, additional addresses: 0xf0026000 19. U2-IOA BC GSC+ Port (7) at 0xf203f000 [8/63], versions 0x501, 0x1, 0xc 20. U2-IOA BC Runway Port (12) at 0xfff8a000 [10], versions 0x580, 0xf, 0xb 21. U2-IOA BC GSC+ Port (7) at 0xf103f000 [10/63], versions 0x501, 0x1, 0xc 22. Raven U 240 (9000/780/C240) (0) at 0xfffa0000 [32], versions 0x599, 0x0, 0x4 23. Memory (1) at 0xfffb1000 [49], versions 0x6f, 0x0, 0x9 The numbers in [] tell you what the tree looks like. In this example, we have 4 top-level devices: #1, #20, #22 & #23. > I've tried digging in /proc without much success... is there a way to get > this information from user space? PPC Linux exposes the device tree in > /proc for example. A mechanism similar to /proc/bus/pci/devices (machine- > parseable text) would be great, too. In 2.5, this information's available via sysfs. I don't think we'll expose it in /proc. > PS: I noticed that /proc/iomem lists 00000000-000009ff as "PDC data (Page > Zero)", is there a chance I can find what I need there? (I dd-ed it from > /dev/mem but I can't say if it contains useful data...) No, you need to actually make firmware calls and you can't do that from user mode. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [parisc-linux] enumerating devices from user space 2003-03-12 16:48 ` Matthew Wilcox @ 2003-03-12 17:30 ` Lyonel Vincent 2003-03-12 20:50 ` Helge Deller 0 siblings, 1 reply; 17+ messages in thread From: Lyonel Vincent @ 2003-03-12 17:30 UTC (permalink / raw) To: Matthew Wilcox; +Cc: parisc-linux many thanks for the prompt answer well... that's exactly the answer I didn't want to ear ;o) lshw can't reasonably assume that /var/log/dmesg exists and is correct (or even dmesg) and dig into the trash. My kernel programming skills are extremely limited (not to say inexistent) but how difficult would it be to expose this information to user space through /proc? (AFAICT, we already have PA-RISC specific files like /proc/bus/runway) A simplistic format like <hwpath>\t<type> <instance> <hversion> <sversion> etc. would do. Do you think it'd be useful to make that kind of information available to user- space? (besides lshw of course ;op) If it's the case I'll try to do my best... cheers, lv. On Wed, Mar 12, 2003 at 04:48:52PM +0000, Matthew Wilcox wrote: > On Wed, Mar 12, 2003 at 05:32:36PM +0100, Lyonel Vincent wrote: > > I'm currently implementing a small tool called lshw (you can find it on > > Freshmeat) that enumerates installed devices on a machine and reports them > > as a device tree (text, HTML and XML). > > That's cool. > > > For now it knows about DMI, PCI busses, SCSI, IDE and PCMCIA and I would > > like to port it to PA-RISC Linux. I already get some very basic info from > > /proc/cpuinfo. > > Does anyone know how I can access the device tree as seen by the kernel? > > (much like HP-UX's ioscan does and what is shown in dmesg) > > You can look in /var/log/dmesg. For example... > > Found devices: > 1. U2-IOA BC Runway Port (12) at 0xfff88000 [8], versions 0x580, 0xf, 0xb > 2. Dino PCI Bridge (13) at 0xf2000000 [8/0], versions 0x680, 0x0, 0xa, additional addresses: 0xf2800000 > 3. Raven U/L2 Dino PS/2 Port (10) at 0xf2001000 [8/1], versions 0x6, 0x0, 0x96 > 4. Raven U/L2 Dino RS-232 (10) at 0xf2003000 [8/3], versions 0x6, 0x0, 0x8c > 5. Raven U/L2 Core FW-SCSI (4) at 0xf200c000 [8/12], versions 0x3b, 0x0, 0x89 > 6. Raven U/L2 Core BA (11) at 0xffd00000 [8/16], versions 0x3b, 0x0, 0x81, additional addresses: 0xffd0c000 0xffc00000 > 7. Raven U/L2 Core Centronics (10) at 0xffd02000 [8/16/0], versions 0x3b, 0x0, 0x74, additional addresses: 0xffd01000 0xffd03000 > 8. Raven U/L2 Core Audio (10) at 0xffd04000 [8/16/1], versions 0x3b, 0x4, 0x7b > 9. Raven U/L2 Core RS-232 (10) at 0xffd05000 [8/16/4], versions 0x3b, 0x0, 0x8c > 10. Raven U/L2 Core SCSI (10) at 0xffd06000 [8/16/5], versions 0x3b, 0x0, 0x82 > 11. Raven U/L2 Core LAN (802.3) (10) at 0xffd07000 [8/16/6], versions 0x3b, 0x0, 0x8a > 12. Raven U/L2 Core PS/2 Port (10) at 0xffd08000 [8/16/7], versions 0x3b, 0x0, 0x84 > 13. Raven U/L2 Core PS/2 Port (10) at 0xffd08100 [8/16/8], versions 0x3b, 0x0, 0x84 > 14. Raven Backplane Wax BA (11) at 0xffe00000 [8/20], versions 0x17, 0x0, 0x8e > 15. Raven Backplane Wax HIL (10) at 0xffe01000 [8/20/1], versions 0x17, 0x0, 0x73 > 16. Raven Backplane RS-232 (10) at 0xffe02000 [8/20/2], versions 0x17, 0x0, 0x8c > 17. Raven Backplane Wax EISA BA (11) at 0xfc000000 [8/20/5], versions 0x17, 0x0, 0x90, additional addresses: 0xffc88000 0xfc00000b > 18. Gecko GSC Core Graphics (10) at 0xfa000000 [8/24], versions 0x16, 0x0, 0x85, additional addresses: 0xf0026000 > 19. U2-IOA BC GSC+ Port (7) at 0xf203f000 [8/63], versions 0x501, 0x1, 0xc > 20. U2-IOA BC Runway Port (12) at 0xfff8a000 [10], versions 0x580, 0xf, 0xb > 21. U2-IOA BC GSC+ Port (7) at 0xf103f000 [10/63], versions 0x501, 0x1, 0xc > 22. Raven U 240 (9000/780/C240) (0) at 0xfffa0000 [32], versions 0x599, 0x0, 0x4 > 23. Memory (1) at 0xfffb1000 [49], versions 0x6f, 0x0, 0x9 > > The numbers in [] tell you what the tree looks like. In this example, we > have 4 top-level devices: #1, #20, #22 & #23. > > > I've tried digging in /proc without much success... is there a way to get > > this information from user space? PPC Linux exposes the device tree in > > /proc for example. A mechanism similar to /proc/bus/pci/devices (machine- > > parseable text) would be great, too. > > In 2.5, this information's available via sysfs. I don't think we'll > expose it in /proc. > > > PS: I noticed that /proc/iomem lists 00000000-000009ff as "PDC data (Page > > Zero)", is there a chance I can find what I need there? (I dd-ed it from > > /dev/mem but I can't say if it contains useful data...) > > No, you need to actually make firmware calls and you can't do that from > user mode. > > -- > "It's not Hollywood. War is real, war is primarily not about defeat or > victory, it is about death. I've seen thousands and thousands of dead bodies. > Do you think I want to have an academic debate on this subject?" -- Robert Fisk -- The software said it requires Windows 2000 or better, so I installed Linux. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [parisc-linux] enumerating devices from user space 2003-03-12 17:30 ` Lyonel Vincent @ 2003-03-12 20:50 ` Helge Deller 2003-03-12 22:36 ` Lyonel Vincent 0 siblings, 1 reply; 17+ messages in thread From: Helge Deller @ 2003-03-12 20:50 UTC (permalink / raw) To: vincentl, Matthew Wilcox; +Cc: parisc-linux Hi, I think the most intesting thing is the name of the system, which is (untested!) in /proc/cpuinfo (should give you "Raven U 240 (9000/780/C240)"). The rest is mostly and often standard serial, parallel, SCSI, pci (pci-utils!), and some strange GSC cards (which often give you some of the above devices). Regards, Helge On Wednesday 12 March 2003 18:30, Lyonel Vincent wrote: > many thanks for the prompt answer > > well... that's exactly the answer I didn't want to ear ;o) > lshw can't reasonably assume that /var/log/dmesg exists and is correct (or > even dmesg) and dig into the trash. > > My kernel programming skills are extremely limited (not to say inexistent) > but how difficult would it be to expose this information to user space > through /proc? (AFAICT, we already have PA-RISC specific files like > /proc/bus/runway) A simplistic format like <hwpath>\t<type> <instance> > <hversion> <sversion> etc. would do. > Do you think it'd be useful to make that kind of information available to > user- space? (besides lshw of course ;op) If it's the case I'll try to do > my best... > > cheers, > lv. > > On Wed, Mar 12, 2003 at 04:48:52PM +0000, Matthew Wilcox wrote: > > On Wed, Mar 12, 2003 at 05:32:36PM +0100, Lyonel Vincent wrote: > > > I'm currently implementing a small tool called lshw (you can find it on > > > Freshmeat) that enumerates installed devices on a machine and reports > > > them as a device tree (text, HTML and XML). > > > > That's cool. > > > > > For now it knows about DMI, PCI busses, SCSI, IDE and PCMCIA and I > > > would like to port it to PA-RISC Linux. I already get some very basic > > > info from /proc/cpuinfo. > > > Does anyone know how I can access the device tree as seen by the > > > kernel? (much like HP-UX's ioscan does and what is shown in dmesg) > > > > You can look in /var/log/dmesg. For example... > > > > Found devices: > > 1. U2-IOA BC Runway Port (12) at 0xfff88000 [8], versions 0x580, 0xf, 0xb > > 2. Dino PCI Bridge (13) at 0xf2000000 [8/0], versions 0x680, 0x0, 0xa, > > additional addresses: 0xf2800000 3. Raven U/L2 Dino PS/2 Port (10) at > > 0xf2001000 [8/1], versions 0x6, 0x0, 0x96 4. Raven U/L2 Dino RS-232 (10) > > at 0xf2003000 [8/3], versions 0x6, 0x0, 0x8c 5. Raven U/L2 Core FW-SCSI > > (4) at 0xf200c000 [8/12], versions 0x3b, 0x0, 0x89 6. Raven U/L2 Core BA > > (11) at 0xffd00000 [8/16], versions 0x3b, 0x0, 0x81, additional > > addresses: 0xffd0c000 0xffc00000 7. Raven U/L2 Core Centronics (10) at > > 0xffd02000 [8/16/0], versions 0x3b, 0x0, 0x74, additional addresses: > > 0xffd01000 0xffd03000 8. Raven U/L2 Core Audio (10) at 0xffd04000 > > [8/16/1], versions 0x3b, 0x4, 0x7b 9. Raven U/L2 Core RS-232 (10) at > > 0xffd05000 [8/16/4], versions 0x3b, 0x0, 0x8c 10. Raven U/L2 Core SCSI > > (10) at 0xffd06000 [8/16/5], versions 0x3b, 0x0, 0x82 11. Raven U/L2 Core > > LAN (802.3) (10) at 0xffd07000 [8/16/6], versions 0x3b, 0x0, 0x8a 12. > > Raven U/L2 Core PS/2 Port (10) at 0xffd08000 [8/16/7], versions 0x3b, > > 0x0, 0x84 13. Raven U/L2 Core PS/2 Port (10) at 0xffd08100 [8/16/8], > > versions 0x3b, 0x0, 0x84 14. Raven Backplane Wax BA (11) at 0xffe00000 > > [8/20], versions 0x17, 0x0, 0x8e 15. Raven Backplane Wax HIL (10) at > > 0xffe01000 [8/20/1], versions 0x17, 0x0, 0x73 16. Raven Backplane RS-232 > > (10) at 0xffe02000 [8/20/2], versions 0x17, 0x0, 0x8c 17. Raven Backplane > > Wax EISA BA (11) at 0xfc000000 [8/20/5], versions 0x17, 0x0, 0x90, > > additional addresses: 0xffc88000 0xfc00000b 18. Gecko GSC Core Graphics > > (10) at 0xfa000000 [8/24], versions 0x16, 0x0, 0x85, additional > > addresses: 0xf0026000 19. U2-IOA BC GSC+ Port (7) at 0xf203f000 [8/63], > > versions 0x501, 0x1, 0xc 20. U2-IOA BC Runway Port (12) at 0xfff8a000 > > [10], versions 0x580, 0xf, 0xb 21. U2-IOA BC GSC+ Port (7) at 0xf103f000 > > [10/63], versions 0x501, 0x1, 0xc 22. Raven U 240 (9000/780/C240) (0) at > > 0xfffa0000 [32], versions 0x599, 0x0, 0x4 23. Memory (1) at 0xfffb1000 > > [49], versions 0x6f, 0x0, 0x9 > > > > The numbers in [] tell you what the tree looks like. In this example, we > > have 4 top-level devices: #1, #20, #22 & #23. > > > > > I've tried digging in /proc without much success... is there a way to > > > get this information from user space? PPC Linux exposes the device tree > > > in /proc for example. A mechanism similar to /proc/bus/pci/devices > > > (machine- parseable text) would be great, too. > > > > In 2.5, this information's available via sysfs. I don't think we'll > > expose it in /proc. > > > > > PS: I noticed that /proc/iomem lists 00000000-000009ff as "PDC data > > > (Page Zero)", is there a chance I can find what I need there? (I dd-ed > > > it from /dev/mem but I can't say if it contains useful data...) > > > > No, you need to actually make firmware calls and you can't do that from > > user mode. > > > > -- > > "It's not Hollywood. War is real, war is primarily not about defeat or > > victory, it is about death. I've seen thousands and thousands of dead > > bodies. Do you think I want to have an academic debate on this subject?" > > -- Robert Fisk ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [parisc-linux] enumerating devices from user space 2003-03-12 20:50 ` Helge Deller @ 2003-03-12 22:36 ` Lyonel Vincent 2003-03-13 0:58 ` Matthew Wilcox 2003-03-13 8:23 ` Derek Engelhaupt 0 siblings, 2 replies; 17+ messages in thread From: Lyonel Vincent @ 2003-03-12 22:36 UTC (permalink / raw) To: Helge Deller; +Cc: parisc-linux Hello Helge, The goal is precisely that: *accurately* report installed hardware (including the "standard" stuff) and how it's connected in a *unified* way, without having to use dozens of inconsistent tools (pci-utils, lsusb, sg-utils, cat, grep, black magic, etc.). A good example of this being HP-UX's ioscan. DMI-aware PCs also have a similar feature. SCSI, PCI etc. are already enumerated platform-independently (without needing pci-utils nor sg-utils, only pci.ids) but they currently seem to come "out of the void" as the underlying hardware (LASI, various GSC bridges, etc) is not enumerated. Concerning the obvious /proc/cpuinfo, its info is reported too (on PA-RISC, x86, IA-64, PowerPC and Alpha). In short, that's why I'd like to access ioscan-like data under PA-RISC Linux from user space. cheers, lv. On Wed, 12 Mar 2003 21:50:50 +0100 Helge Deller <deller@gmx.de> wrote: > Hi, > > I think the most intesting thing is the name of the system, which is > (untested!) in /proc/cpuinfo (should give you "Raven U 240 > (9000/780/C240)"). > > The rest is mostly and often standard serial, parallel, SCSI, pci > (pci-utils!), and some strange GSC cards (which often give you some of > the above devices). > > Regards, > Helge > > On Wednesday 12 March 2003 18:30, Lyonel Vincent wrote: > > many thanks for the prompt answer > > > > well... that's exactly the answer I didn't want to ear ;o) > > lshw can't reasonably assume that /var/log/dmesg exists and is > > correct (or even dmesg) and dig into the trash. > > > > My kernel programming skills are extremely limited (not to say > > inexistent) but how difficult would it be to expose this information > > to user space through /proc? (AFAICT, we already have PA-RISC > > specific files like/proc/bus/runway) A simplistic format like > > <hwpath>\t<type> <instance><hversion> <sversion> etc. would do. > > Do you think it'd be useful to make that kind of information > > available to user- space? (besides lshw of course ;op) If it's the > > case I'll try to do my best... > > > > cheers, > > lv. > > > > On Wed, Mar 12, 2003 at 04:48:52PM +0000, Matthew Wilcox wrote: > > > On Wed, Mar 12, 2003 at 05:32:36PM +0100, Lyonel Vincent wrote: > > > > I'm currently implementing a small tool called lshw (you can > > > > find it on Freshmeat) that enumerates installed devices on a > > > > machine and reports them as a device tree (text, HTML and XML). > > > > > > That's cool. > > > > > > > For now it knows about DMI, PCI busses, SCSI, IDE and PCMCIA and > > > > I would like to port it to PA-RISC Linux. I already get some > > > > very basic info from /proc/cpuinfo. > > > > Does anyone know how I can access the device tree as seen by the > > > > kernel? (much like HP-UX's ioscan does and what is shown in > > > > dmesg) > > > > > > You can look in /var/log/dmesg. For example... > > > > > > Found devices: > > > 1. U2-IOA BC Runway Port (12) at 0xfff88000 [8], versions 0x580, > > > 0xf, 0xb 2. Dino PCI Bridge (13) at 0xf2000000 [8/0], versions > > > 0x680, 0x0, 0xa, additional addresses: 0xf2800000 3. Raven U/L2 > > > Dino PS/2 Port (10) at 0xf2001000 [8/1], versions 0x6, 0x0, 0x96 > > > 4. Raven U/L2 Dino RS-232 (10) at 0xf2003000 [8/3], versions 0x6, > > > 0x0, 0x8c 5. Raven U/L2 Core FW-SCSI(4) at 0xf200c000 [8/12], > > > versions 0x3b, 0x0, 0x89 6. Raven U/L2 Core BA(11) at 0xffd00000 > > > [8/16], versions 0x3b, 0x0, 0x81, additional addresses: > > > 0xffd0c000 0xffc00000 7. Raven U/L2 Core Centronics (10) at > > > 0xffd02000 [8/16/0], versions 0x3b, 0x0, 0x74, additional > > > addresses: 0xffd01000 0xffd03000 8. Raven U/L2 Core Audio (10) at > > > 0xffd04000[8/16/1], versions 0x3b, 0x4, 0x7b 9. Raven U/L2 Core > > > RS-232 (10) at 0xffd05000 [8/16/4], versions 0x3b, 0x0, 0x8c 10. > > > Raven U/L2 Core SCSI(10) at 0xffd06000 [8/16/5], versions 0x3b, > > > 0x0, 0x82 11. Raven U/L2 Core LAN (802.3) (10) at 0xffd07000 > > > [8/16/6], versions 0x3b, 0x0, 0x8a 12. Raven U/L2 Core PS/2 Port > > > (10) at 0xffd08000 [8/16/7], versions 0x3b, 0x0, 0x84 13. Raven > > > U/L2 Core PS/2 Port (10) at 0xffd08100 [8/16/8], versions 0x3b, > > > 0x0, 0x84 14. Raven Backplane Wax BA (11) at 0xffe00000[8/20], > > > versions 0x17, 0x0, 0x8e 15. Raven Backplane Wax HIL (10) at > > > 0xffe01000 [8/20/1], versions 0x17, 0x0, 0x73 16. Raven Backplane > > > RS-232(10) at 0xffe02000 [8/20/2], versions 0x17, 0x0, 0x8c 17. > > > Raven Backplane Wax EISA BA (11) at 0xfc000000 [8/20/5], versions > > > 0x17, 0x0, 0x90, additional addresses: 0xffc88000 0xfc00000b 18. > > > Gecko GSC Core Graphics(10) at 0xfa000000 [8/24], versions 0x16, > > > 0x0, 0x85, additional addresses: 0xf0026000 19. U2-IOA BC GSC+ > > > Port (7) at 0xf203f000 [8/63], versions 0x501, 0x1, 0xc 20. U2-IOA > > > BC Runway Port (12) at 0xfff8a000[10], versions 0x580, 0xf, 0xb > > > 21. U2-IOA BC GSC+ Port (7) at 0xf103f000[10/63], versions 0x501, > > > 0x1, 0xc 22. Raven U 240 (9000/780/C240) (0) at 0xfffa0000 [32], > > > versions 0x599, 0x0, 0x4 23. Memory (1) at 0xfffb1000[49], > > > versions 0x6f, 0x0, 0x9 > > > > > > The numbers in [] tell you what the tree looks like. In this > > > example, we have 4 top-level devices: #1, #20, #22 & #23. > > > > > > > I've tried digging in /proc without much success... is there a > > > > way to get this information from user space? PPC Linux exposes > > > > the device tree in /proc for example. A mechanism similar to > > > > /proc/bus/pci/devices(machine- parseable text) would be great, > > > > too. > > > > > > In 2.5, this information's available via sysfs. I don't think > > > we'll expose it in /proc. > > > > > > > PS: I noticed that /proc/iomem lists 00000000-000009ff as "PDC > > > > data(Page Zero)", is there a chance I can find what I need > > > > there? (I dd-ed it from /dev/mem but I can't say if it contains > > > > useful data...) > > > > > > No, you need to actually make firmware calls and you can't do that > > > from user mode. > > > > > > -- > > > "It's not Hollywood. War is real, war is primarily not about > > > defeat or victory, it is about death. I've seen thousands and > > > thousands of dead bodies. Do you think I want to have an academic > > > debate on this subject?"-- Robert Fisk > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [parisc-linux] enumerating devices from user space 2003-03-12 22:36 ` Lyonel Vincent @ 2003-03-13 0:58 ` Matthew Wilcox 2003-03-13 8:23 ` Derek Engelhaupt 1 sibling, 0 replies; 17+ messages in thread From: Matthew Wilcox @ 2003-03-13 0:58 UTC (permalink / raw) To: Lyonel Vincent; +Cc: Helge Deller, parisc-linux On Wed, Mar 12, 2003 at 11:36:51PM +0100, Lyonel Vincent wrote: > SCSI, PCI etc. are already enumerated platform-independently (without > needing pci-utils nor sg-utils, only pci.ids) but they currently seem to > come "out of the void" as the underlying hardware (LASI, various GSC > bridges, etc) is not enumerated. Right -- and you'll get this in 2.5 from sysfs. Given this, I'm reluctant to introduce a new file in /proc. -- "It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject?" -- Robert Fisk ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [parisc-linux] enumerating devices from user space 2003-03-12 22:36 ` Lyonel Vincent 2003-03-13 0:58 ` Matthew Wilcox @ 2003-03-13 8:23 ` Derek Engelhaupt 1 sibling, 0 replies; 17+ messages in thread From: Derek Engelhaupt @ 2003-03-13 8:23 UTC (permalink / raw) To: parisc-linux [-- Attachment #1: Type: text/plain, Size: 6918 bytes --] Being as I just got done with a class from HP Education on Linux, this very issue was brought up by all of us HP-UX guys. We love our IOSCAN. The instructor told us that someone within HP actually wrote an "ioscan" for Red Hat. I'm thinking that getting a copy of that source code would be a good place to start. I'm going to do a search for the guy tomorrow or get his name from our instructor to see if I can get a hold of his code. derek Lyonel Vincent <vincentl@ec-lyon.fr> wrote:Hello Helge, The goal is precisely that: *accurately* report installed hardware (including the "standard" stuff) and how it's connected in a *unified* way, without having to use dozens of inconsistent tools (pci-utils, lsusb, sg-utils, cat, grep, black magic, etc.). A good example of this being HP-UX's ioscan. DMI-aware PCs also have a similar feature. SCSI, PCI etc. are already enumerated platform-independently (without needing pci-utils nor sg-utils, only pci.ids) but they currently seem to come "out of the void" as the underlying hardware (LASI, various GSC bridges, etc) is not enumerated. Concerning the obvious /proc/cpuinfo, its info is reported too (on PA-RISC, x86, IA-64, PowerPC and Alpha). In short, that's why I'd like to access ioscan-like data under PA-RISC Linux from user space. cheers, lv. On Wed, 12 Mar 2003 21:50:50 +0100 Helge Deller wrote: > Hi, > > I think the most intesting thing is the name of the system, which is > (untested!) in /proc/cpuinfo (should give you "Raven U 240 > (9000/780/C240)"). > > The rest is mostly and often standard serial, parallel, SCSI, pci > (pci-utils!), and some strange GSC cards (which often give you some of > the above devices). > > Regards, > Helge > > On Wednesday 12 March 2003 18:30, Lyonel Vincent wrote: > > many thanks for the prompt answer > > > > well... that's exactly the answer I didn't want to ear ;o) > > lshw can't reasonably assume that /var/log/dmesg exists and is > > correct (or even dmesg) and dig into the trash. > > > > My kernel programming skills are extremely limited (not to say > > inexistent) but how difficult would it be to expose this information > > to user space through /proc? (AFAICT, we already have PA-RISC > > specific files like/proc/bus/runway) A simplistic format like > > \t etc. would do. > > Do you think it'd be useful to make that kind of information > > available to user- space? (besides lshw of course ;op) If it's the > > case I'll try to do my best... > > > > cheers, > > lv. > > > > On Wed, Mar 12, 2003 at 04:48:52PM +0000, Matthew Wilcox wrote: > > > On Wed, Mar 12, 2003 at 05:32:36PM +0100, Lyonel Vincent wrote: > > > > I'm currently implementing a small tool called lshw (you can > > > > find it on Freshmeat) that enumerates installed devices on a > > > > machine and reports them as a device tree (text, HTML and XML). > > > > > > That's cool. > > > > > > > For now it knows about DMI, PCI busses, SCSI, IDE and PCMCIA and > > > > I would like to port it to PA-RISC Linux. I already get some > > > > very basic info from /proc/cpuinfo. > > > > Does anyone know how I can access the device tree as seen by the > > > > kernel? (much like HP-UX's ioscan does and what is shown in > > > > dmesg) > > > > > > You can look in /var/log/dmesg. For example... > > > > > > Found devices: > > > 1. U2-IOA BC Runway Port (12) at 0xfff88000 [8], versions 0x580, > > > 0xf, 0xb 2. Dino PCI Bridge (13) at 0xf2000000 [8/0], versions > > > 0x680, 0x0, 0xa, additional addresses: 0xf2800000 3. Raven U/L2 > > > Dino PS/2 Port (10) at 0xf2001000 [8/1], versions 0x6, 0x0, 0x96 > > > 4. Raven U/L2 Dino RS-232 (10) at 0xf2003000 [8/3], versions 0x6, > > > 0x0, 0x8c 5. Raven U/L2 Core FW-SCSI(4) at 0xf200c000 [8/12], > > > versions 0x3b, 0x0, 0x89 6. Raven U/L2 Core BA(11) at 0xffd00000 > > > [8/16], versions 0x3b, 0x0, 0x81, additional addresses: > > > 0xffd0c000 0xffc00000 7. Raven U/L2 Core Centronics (10) at > > > 0xffd02000 [8/16/0], versions 0x3b, 0x0, 0x74, additional > > > addresses: 0xffd01000 0xffd03000 8. Raven U/L2 Core Audio (10) at > > > 0xffd04000[8/16/1], versions 0x3b, 0x4, 0x7b 9. Raven U/L2 Core > > > RS-232 (10) at 0xffd05000 [8/16/4], versions 0x3b, 0x0, 0x8c 10. > > > Raven U/L2 Core SCSI(10) at 0xffd06000 [8/16/5], versions 0x3b, > > > 0x0, 0x82 11. Raven U/L2 Core LAN (802.3) (10) at 0xffd07000 > > > [8/16/6], versions 0x3b, 0x0, 0x8a 12. Raven U/L2 Core PS/2 Port > > > (10) at 0xffd08000 [8/16/7], versions 0x3b, 0x0, 0x84 13. Raven > > > U/L2 Core PS/2 Port (10) at 0xffd08100 [8/16/8], versions 0x3b, > > > 0x0, 0x84 14. Raven Backplane Wax BA (11) at 0xffe00000[8/20], > > > versions 0x17, 0x0, 0x8e 15. Raven Backplane Wax HIL (10) at > > > 0xffe01000 [8/20/1], versions 0x17, 0x0, 0x73 16. Raven Backplane > > > RS-232(10) at 0xffe02000 [8/20/2], versions 0x17, 0x0, 0x8c 17. > > > Raven Backplane Wax EISA BA (11) at 0xfc000000 [8/20/5], versions > > > 0x17, 0x0, 0x90, additional addresses: 0xffc88000 0xfc00000b 18. > > > Gecko GSC Core Graphics(10) at 0xfa000000 [8/24], versions 0x16, > > > 0x0, 0x85, additional addresses: 0xf0026000 19. U2-IOA BC GSC+ > > > Port (7) at 0xf203f000 [8/63], versions 0x501, 0x1, 0xc 20. U2-IOA > > > BC Runway Port (12) at 0xfff8a000[10], versions 0x580, 0xf, 0xb > > > 21. U2-IOA BC GSC+ Port (7) at 0xf103f000[10/63], versions 0x501, > > > 0x1, 0xc 22. Raven U 240 (9000/780/C240) (0) at 0xfffa0000 [32], > > > versions 0x599, 0x0, 0x4 23. Memory (1) at 0xfffb1000[49], > > > versions 0x6f, 0x0, 0x9 > > > > > > The numbers in [] tell you what the tree looks like. In this > > > example, we have 4 top-level devices: #1, #20, #22 & #23. > > > > > > > I've tried digging in /proc without much success... is there a > > > > way to get this information from user space? PPC Linux exposes > > > > the device tree in /proc for example. A mechanism similar to > > > > /proc/bus/pci/devices(machine- parseable text) would be great, > > > > too. > > > > > > In 2.5, this information's available via sysfs. I don't think > > > we'll expose it in /proc. > > > > > > > PS: I noticed that /proc/iomem lists 00000000-000009ff as "PDC > > > > data(Page Zero)", is there a chance I can find what I need > > > > there? (I dd-ed it from /dev/mem but I can't say if it contains > > > > useful data...) > > > > > > No, you need to actually make firmware calls and you can't do that > > > from user mode. > > > > > > -- > > > "It's not Hollywood. War is real, war is primarily not about > > > defeat or victory, it is about death. I've seen thousands and > > > thousands of dead bodies. Do you think I want to have an academic > > > debate on this subject?"-- Robert Fisk > _______________________________________________ parisc-linux mailing list parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux --------------------------------- Do you Yahoo!? Yahoo! Web Hosting - establish your business online [-- Attachment #2: Type: text/html, Size: 8475 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2003-03-17 13:53 UTC | newest] Thread overview: 17+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2003-03-13 10:22 [parisc-linux] enumerating devices from user space Lyonel Vincent 2003-03-13 11:30 ` bruno_vidal 2003-03-13 12:45 ` Lyonel Vincent 2003-03-14 8:45 ` bruno_vidal 2003-03-14 12:33 ` Lyonel Vincent 2003-03-14 13:19 ` Matthew Wilcox 2003-03-14 14:05 ` Lyonel Vincent 2003-03-14 14:08 ` Matthew Wilcox 2003-03-14 17:29 ` Grant Grundler 2003-03-17 13:53 ` Lyonel Vincent -- strict thread matches above, loose matches on Subject: below -- 2003-03-12 16:32 Lyonel Vincent 2003-03-12 16:48 ` Matthew Wilcox 2003-03-12 17:30 ` Lyonel Vincent 2003-03-12 20:50 ` Helge Deller 2003-03-12 22:36 ` Lyonel Vincent 2003-03-13 0:58 ` Matthew Wilcox 2003-03-13 8:23 ` Derek Engelhaupt
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.