From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 18 11:51:38 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D81F916A41F for ; Fri, 18 Nov 2005 11:51:38 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from postman.atlantis.dp.ua (postman.atlantis.dp.ua [193.108.47.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2BE943D46 for ; Fri, 18 Nov 2005 11:51:37 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from smtp.atlantis.dp.ua (smtp.atlantis.dp.ua [193.108.46.231]) by postman.atlantis.dp.ua (8.13.1/8.13.1) with ESMTP id jAIBpPDP031903 for ; Fri, 18 Nov 2005 13:51:25 +0200 (EET) (envelope-from dmitry@atlantis.dp.ua) Date: Fri, 18 Nov 2005 13:51:25 +0200 (EET) From: Dmitry Pryanishnikov To: freebsd-hackers@freebsd.org Message-ID: <20051118124856.F199@atlantis.atlantis.dp.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Fri, 18 Nov 2005 12:44:56 +0000 Subject: Physical memory access from kld X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2005 11:51:39 -0000 Hello! I'm trying to add Intel 875P chipset support for ecc.ko module. Basically this module outputs whether chipset supports and utilizes ECC, how much memory does it have, and whether there were memory errors. Well, this chipset has a very confusing architecture. Instead of having all relevant bits in PCI device configuration space, Intel has moved part of important DRAM controller registers into memory-mapped region, which is in turn controlled by the Overflow device 6, which isn't (in turn) even available by default. Many thanks to the author of http://www.x86-secret.com/articles/tweak/pat/patsecrets-2.htm for making it possible to access it at all - Intel's pdf doesn't even mention special register 0xF4 of Device 0! Very confusing desing, much worse than previous Intel chips ;( So, what tricks should I do in order to access memory-mapped registers of this "hidden" device 6? I wrote the code (currently under FreeBSD-4, but I want to port it then to RELENG_6) that enables device 6. Luckily BAR6 (starting address of memory-mapped registers) has been set up correctly by the mobo's (D875PBZ) BIOS. I can even "dd if=/dev/mem skip=xxx" and read those registers. But obviously I can't just dereference the pointer read from BAR6 since this physical address isn't mapped in kernel's virtual address space. What API should I use in order to map it in RELENG_4? In RELENG_6? And how to construct 'pcicfgregs' object for this "shadow" Overflow device under RELENG_6? During boot this device is invisible, so OS doesn't create 'pcicfgregs' for it. Under RELENG_4 all is simple: static pcicfgregs pci_cfg,pci_cfg2; ... bzero(cfgp, sizeof pci_cfg); pci_cfg.slot = 0; pci_cfg.func = 0; ... pci_cfg2 = pci_cfg; pci_cfg2.slot = 6 ; pci_cfg2.func = 0; and voila - pci_cfgread() / pci_cfgwrite() are happy. But under RELENG_6 there is no such API, and pci_read_config() / pci_write_config() do require valid (pcicfgregs *)->dev. So for Device 0 I'm just using OS-created objects: STAILQ_FOREACH(dinfo,&pci_devq,pci_links) { cfgp = &dinfo->cfg; if (cfgp->baseclass != PCIC_BRIDGE) continue; if (cfgp->subclass != PCIS_BRIDGE_HOST) continue; /* Here I have valid "pcicfgregs *cfgp" */ How to create valid *cfgp for Device 6? Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE