Hello, On 6/16/10, Carl-Daniel Hailfinger <[email protected]> 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 =- _______________________________________________ flashrom mailing list [email protected] http://www.flashrom.org/mailman/listinfo/flashrom
