[LinuxBIOS] RFC Winflashrom Architecture -- Current device driver (testbed)

[Corey Osgood]

Okay, I hate to sound naive, but what Windows versions can/will this
support? I'm assuming 2000 and XP, what about Vista and 98? Also, where
this is going to be a driver, will there be any problem with Vista
complaining about it not being signed? Vista can be a real pain with
drivers that aren't signed, the beta I was running had a workaround to
allow you to boot, but I think that was removed from the retail release,
which I have (free of charge, the only way I'd have it) but haven't
installed yet.

And last (but not least), flashing the BIOS while running Windows always
seems to have been a tricky beast, I bricked a couple boards using
windows-based flash tools back in the day. Will there be any ill side
effects and/or potential issues with this?

BTW, good work!

-Corey

Darmawan Salihun wrote:
> Stefan Reinauer wrote:
>   
>> Oh I love playing advocatus diaboli ;-)
>>
>> * Jeremy Jackson <jerj at coplanar.net> [070611 16:58]:
>>   
>>     
>>> One thing that should really drive this home, is that using this
>>> architecture on Linux *and* Windows, the same userspace tool could be
>>> used on both, so the fancy code for incremental updates, writing
>>> parameter blocks, etc.,  wouldn't have to be duplicated.
>>>     
>>>       
>> It should not be duplicated anyways. The Windows driver currently only
>> takes care of mapping memory into user space if I remember correctly.
>>   
>>     
> The current experimental windows driver is capable of _mapping_ the
> entire 4GB physical address space to user mode
> application and doing a direct IO transcation (which is bad :-( ). I'm
> currently working to limit the mapping to the top 16MB below the 4GB
> limit. It should be trivial.
> And other thing is to remove the direct IO routine because it's too
> dangerous and replace it with "Windows driver setup API" instead because
> what flashrom need
> is only the PCI id's and some other stuff that I think can be found in
> windows device configuration information through the setup API. (i.e.
> CM_xxx function in PnP
> "manager" or the SetupDi family of API).
> FYI, I haven't managed to complete a version that can be tested because
> of my exam last week. Hopefully there will be significant progress this
> week.
>
> --Darmawan
>
>