[flashrom] [coreboot] Winflashrom plans

Darmawan Salihun darmawan.salihun at gmail.com
Wed Jun 16 10:30:47 CEST 2010


Hello,

On 6/16/10, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
> Hi Darmawan,
>
> nice to see you're back.
> flashrom has its own mailing list and I added it to CC.
>
> On 15.06.2010 21:56, Darmawan Salihun wrote:
>> Sorry, I haven't been able to update Winflashrom for more than 3 years
>> now.
>> I'm planning to add Windows 7 support next month.
>>
>
> Nice!
>
>
>> Therefore, I'm looking for suggestions.
>>
>> A bit of Winflashrom background of the currently available Winflashrom
>> (at flashrom.org):
>>
>> The programming model:
>> a. User mode application:
>>     - Mostly "pure" flashrom source code recompiled with MinGW.
>>
>
> Current flashrom can be compiled with MinGW and Cygwin, but it doesn't
> support any PCI accesses (USB and serial work).
>

I see. I need to think about the best programming model for the PCI.

>
>>     - libpci recompiled with MinGW (for PCI access logic). This is
>> required because
>>        the PCI access functions in the Windows API is not guaranteed
>> (marked as obsolete),
>>        in Windows XP SP2 and Windows 2003 server back then.
>>
>
> If the PCI access functions are still available in Windows 7, can we
> simply ignore the "deprecated" warnings? CF8/CFC accesses from userspace
> are not atomic and might cause mixed up PCI accesses.
>

Ok. I take that as a very serious consideration. It will be of utmost
importance.

>
>> b. Device driver:
>>     - Provides POSIX mmap() implementation in the kernel, i.e.
>>       provides an entrypoint for mmap() function to user mode application.
>>
>
> Please note that we need two types of memory mapping:
> sys_physmap_ro_cached() and sys_physmap_rw_uncached(). For example, the
> low memory mapping for coreboot tables uses the readonly cached variant,
> and any future DMI string access will also use the readonly cached
> variant. Any MMIO areas (including flash access) use the uncached rw
> variant. Some operating systems do not care at all about cached/uncached
> mapping (they simply use the default caching settings of that memory
> region), and for those you can use the uncached rw access for both
> access types.
>

I'm not really sure about the current state with Windows.
But, AFAIK the caching state of the MMIO regions must be set when
reading/writing to MMIO regions in a Windows device driver.

>
>>     - Provides direct I/O port access for libpci.
>>
>> Well, the reason for these programming model is to reduce the burden
>> when moving to newer flash chip support because this programming model
>> "preserves" the POSIX API in the user mode application (the device
>> driver is generic enough).
>> Therefore, "only" the user mode application need to be recompiled to
>> support new flash chip.
>>
>> Any suggestions on what to change from the current programming model?
>>
>
> Current flashrom already supports PCI device flashing and onboard
> flashing on DOS, Linux, FreeBSD, NetBSD, DragonFlyBSD, OpenSolaris, Mac
> OS X and a few others.
> Please take a look at hwaccess.c and hwaccess.h and physmap.c for things
> you might want to change for Windows PCI support.
>

Ok. Thanks for the pointer.

> I expect Windows support in flashrom to need ~60 lines of code, maybe
> less. The device driver (and libpci support) is a different question,
> though.

I see.

> If you have to modify any file except hwaccess.c, hwaccess.h, physmap.c
> or Makefile please tell us.

Ok.

Regards,

Darmawan
-- 
--------------------------------------------------------------------
-= Human knowledge belongs to the world =-




More information about the flashrom mailing list