[flashrom] Porting flashrom to OpenBSD

[Carl-Daniel Hailfinger]

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