On 25.06.2010 18:58, Matthieu Herrb wrote: > On Fri, Jun 25, 2010 at 06:24:56PM +0200, Carl-Daniel Hailfinger wrote: > >> On 25.06.2010 17:07, Matthieu Herrb wrote: >> >>> On Fri, Jun 25, 2010 at 03:25:10PM +0100, Stuart Henderson wrote: >>> >>> >>>> On 2010/06/25 11:57, Carl-Daniel Hailfinger wrote: >>>> >>>> >>>>> Hi Jonathan, >>>>> >>>>> you're in CC of this mail because you sent the "unbreak pciutils" mail >>>>> to this list, and the failure mode is related. >>>>> http://marc.info/?l=openbsd-ports&m=126918139214769 >>>>> >>>>> >>>> Hmmm... So why is PCIOCWRITE failing, even when securelevel is 0 and >>>> allowaperture=2... >>>> >>>> >>> Probably because you do un-aligned PCI config space access. >>> Our /dev/pci only supports 32 bit wide read/write, aligned on 4 bytes >>> boundaries. >>> >>> If you need to write to PCI config space, you'll need a separate >>> kernel interface, with a high-level interface, so that you don't allow >>> random changes in the PCI config space from userland. >>> >>> >> Wouldn't allowing 16 bit and 8 bit reads/writes at native alignments in >> /dev/pci work for that? I could modify flashrom to use read/modify/write >> cycles to emulate 8/16 bit reads/writes with 32 bit reads/writes, but >> that may have undesirable side effects on some chipsets. >> > > As far as I know this is an urban legend. Ask kettenis@ for details. > So far we resisted to do that. libpciaccess handles it for > OpenBSD (/usr/xenocara/lib/libpciaccess/src/openbsd_pci.c). >
Thanks. Do you know if anyone plans to implement the same trickery in libpci? If it works fine for libpciaccess, it should be doable for libpci. >>> The rest of the discussion about not abusing the aperture driver for >>> this also stays. >>> >>> >> I never fully understood how /dev/mem and the aperture driver are >> related. flashrom uses /dev/mem for memory access. The allowaperture >> stuff is something I guessed from reading various OpenBSD docs and >> mailing list posts. >> > > The aperture driver was initially created to allow the X server to > access the physical memory addresses of the graphics cards, even when > running at securelevel > 0, where /dev/mem access is > forbidden. /dev/xf86 is used for that purpose and is attached to a > character device which has the same major device number as /dev/mem. > > The sysctl is there to enable or disable the aperture, in order to > avoid rebuilding a kernel to disable it. > > Then, when PCI/AGP video cards appeared, many PCI BIOS started so > buggy that something had to fix their configuration space in order to > be able to use them. Since XFree86 was a multi-platform system, > instead of asking and waiting until every possible supported system > implements the required kernel bits, they decided to write to the PCI > config space directly from userland to fix those problems. > > On OpenBSD we decided that those /dev/pci write access are similar to > /dev/mem access, and thus decided to control it using the same sysctl, > in order not to create more knobs. > So if I understand you correctly, full /dev/pci and /dev/mem access should be possible with securelevel=0, and we shouldn't screw with allowaperture at all? No problem, I am happy to change the flashrom docs. flashrom is something you won't run on every boot, so I think requiring securelevel=0 for the few times you need to access flash is perfectly fine. Regards, Carl-Daniel _______________________________________________ flashrom mailing list [email protected] http://www.flashrom.org/mailman/listinfo/flashrom
