Re: [flashrom] [coreboot] Winflashrom plans

[Carl-Daniel Hailfinger]

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).
> - 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.
> 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.
> - 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.

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.
If you have to modify any file except hwaccess.c, hwaccess.h, physmap.c
or Makefile please tell us.

If you have any questions, feel free to ask at [e-mail] or
in #flashrom on irc.freenode.net.

Regards,
Carl-Daniel

[coreboot] Winflashrom plans

[Darmawan Salihun]

Hello,

On 6/16/10, Carl-Daniel Hailfinger  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

[coreboot] Winflashrom plans

[Carl-Daniel Hailfinger]

Hi Darmawan,

any updates on the Windows port of flashrom? We'll release 0.9.3 soon,
and it would be cool to have Windows support. If you need any help,
please tell us. Even if a patch supports just one Windows version, it is
better than what we have now.

Regards,
Carl-Daniel

On 16.06.2010 10:30, Darmawan Salihun wrote:
> Hello,
>
> On 6/16/10, Carl-Daniel Hailfinger  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

[coreboot] Winflashrom plans

[Darmawan Salihun]

Hello Carl-Daniel,

I'm sorry, Ive been busy with life until now.
I'm still trying to find enough time to work on it.

Regards,

Darmawan

On 8/3/10, Carl-Daniel Hailfinger  wrote:
> Hi Darmawan,
>
> any updates on the Windows port of flashrom? We'll release 0.9.3 soon,
> and it would be cool to have Windows support. If you need any help,
> please tell us. Even if a patch supports just one Windows version, it is
> better than what we have now.
>
> Regards,
> Carl-Daniel
>
> On 16.06.2010 10:30, Darmawan Salihun wrote:
> > Hello,
> >
> > On 6/16/10, Carl-Daniel Hailfinger 
> > 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