[LinuxBIOS] winflashrom architecture (Windows port of flashrom) -- looking for suggestions
Hi all, I'm currently working on a windows port of the flashrom utility. I have been thinking about how it should be done. There are two paradigm that I'm thinking about as of now. I need your suggestions/critics, etc. ;-). Both of them based on the fact that this utility should be divided into user mode code and kernel mode code.
1. The kernel mode code a.k.a kernel mode device driver is as simple as possible and only provides "raw" functionality, i.e. capability to map the physical address space in which the BIOS chip is mapped into the requesting user mode code. This approach provides the user mode code similar to mmap() function in *NIX. The pros in this approach is there won't be much changes to the *NIX version of flashrom to adapt it to windows and it will be a little easier to develop because no need to load/unload the driver. The cons is if the user mode code went wrong, it can bring the whole system down. I've been experimenting with a minor tested version for this approach though.
2. The kernel mode driver implements the majority of the flashrom code and the usermode code is merely a "front-end" to the kernel mode device driver which provides all of the chip related logic. The pros in this approach is the code would probably much stable because the user mode code won't bring the system down as easily as the previous approach. The cons is it will very probably requires more work to port the *NIX version of flashrom to Windows with this approach and more over, I haven't been able to figure out how to do integrity-testing to the driver to ensure its stability :-(.
Anyway, I'm also thinking about a quite "universal" interface between the user mode code and the kernel mode code. Perhaps a well defined interface that will work both in *NIX and Windows in the future will be needed or maybe I will try to provide an "evolution path" to such an interface. I really need suggestion in this area.
--Darmawan
hi Darmawan,
a decent flashing software is badly in need. otherwise there is only UNIFLASH, a DOS turbo pascal 7 program, which is not covering some recent hardware and die PCI Expansion ROM support is patchy. It may also make sense to make a knoppix liveimage with full LinuxBIOS integration to allow legacy mainbios modification under Linux with flashrom. --Q
Darmawan Salihun schrieb:
Hi all, I'm currently working on a windows port of the flashrom utility. I have been thinking about how it should be done. There are two paradigm that I'm thinking about as of now. I need your suggestions/critics, etc. ;-). Both of them based on the fact that this utility should be divided into user mode code and kernel mode code.
On Mon, 2007-04-30 at 11:52 +0200, Quux wrote:
hi Darmawan,
a decent flashing software is badly in need. otherwise there is only UNIFLASH, a DOS turbo pascal 7 program, which is not covering some recent hardware and die PCI Expansion ROM support is patchy. It may also make sense to make a knoppix liveimage with full LinuxBIOS integration to allow legacy mainbios modification under Linux with flashrom. --Q
I second using UNIFLASH. A person can easily create a FreeDOS boot cdrom incorporating UNIFLASH or booting UNIFLASH on another cdrom media.
However, I agree about incorporating flashrom into knoppix or, my favorite, SystemRescueCD (it's Gentoo based ;-).
I don't know if Knoppix will integrate as it's more of a candy coated cdrom, but I can almost guarentee the maintainer of SystemRescueCD would integrate flashrom. To ease integration, I was thinking about creating an ebuild for LinuxBIOS or just Flashrom.
-- Roger http://www.eskimo.com/~roger/index.html Key fingerprint = 8977 A252 2623 F567 70CD 1261 640F C963 1005 1D61
Mon Apr 30 11:43:02 PDT 2007
On Mon, Apr 30, 2007 at 10:50:07AM +0700, Darmawan Salihun wrote:
- The kernel mode code a.k.a kernel mode device driver is as
simple as possible and only provides "raw" functionality, i.e. capability to map the physical address space in which the BIOS chip is mapped into the requesting user mode code.
This would be OK, but there's a constant race between making the window large enough and new flash chips.
- The kernel mode driver implements the majority of the flashrom
code and the usermode code is merely a "front-end" to the kernel mode device driver which provides all of the chip related logic.
I like this a bit better.
Anyway, I'm also thinking about a quite "universal" interface between the user mode code and the kernel mode code. Perhaps a well defined interface
This requires a lot of extra work but has the benefit of only one generic algorithm being implemented in the kernel, thus the kernel driver will not have to be updated to support new flash chips. It could however have to be updated when a new driver supporting all SPI flash is released. (But not every time a new flash chip is added.)
After having identified the chip the app would download the appropriate microcode to the kernel driver; a set of rather high-level instructions to be executed by the driver.
1. or 2. will be a lot less work though. Maybe start there.
I like 2.
//Peter
On 5/1/07, Peter Stuge stuge-linuxbios@cdy.org wrote:
On Mon, Apr 30, 2007 at 10:50:07AM +0700, Darmawan Salihun wrote:
- The kernel mode code a.k.a kernel mode device driver is as
simple as possible and only provides "raw" functionality, i.e. capability to map the physical address space in which the BIOS chip is mapped into the requesting user mode code.
This would be OK, but there's a constant race between making the window large enough and new flash chips.
In my current experimental code. The "window" in the kernel driver is programmable, i.e. the user mode application passes the starting address of the MMIO range along with the size of the range to be mapped.
- The kernel mode driver implements the majority of the flashrom
code and the usermode code is merely a "front-end" to the kernel mode device driver which provides all of the chip related logic.
I like this a bit better.
I see. My problem right now in this version is to define the interface between the kernel driver and the user mode code. Quite hard to define the interface because it will use a quite different approach than the "mmap" approach in point 1. It requires me to write wrapper functions and "decouples" the original routine in the linux version of flashrom. Nonetheless, I haven't built any experimental code with this approach yet. Unlike the approach in point 1, it seems to be working so far in my testbed.
Anyway, I'm also thinking about a quite "universal" interface between the user mode code and the kernel mode code. Perhaps a well defined interface
This requires a lot of extra work but has the benefit of only one generic algorithm being implemented in the kernel, thus the kernel driver will not have to be updated to support new flash chips. It could however have to be updated when a new driver supporting all SPI flash is released. (But not every time a new flash chip is added.)
After having identified the chip the app would download the
appropriate microcode to the kernel driver; a set of rather high-level instructions to be executed by the driver.
yes. That's why I'm currently thinking about the "evolutionary path" to this kind of functionality
- or 2. will be a lot less work though. Maybe start there.
I like 2.
I'll have a look at this approach more closely.
On Tue, May 01, 2007 at 11:20:20PM +0700, Darmawan Salihun wrote:
On Mon, Apr 30, 2007 at 10:50:07AM +0700, Darmawan Salihun wrote:
- The kernel mode code a.k.a kernel mode device driver is as
This would be OK, but there's a constant race between making the window large enough and new flash chips.
In my current experimental code. The "window" in the kernel driver is programmable, i.e. the user mode application passes the starting address of the MMIO range along with the size of the range to be mapped.
The problem with this is that the app could map ALL memory and destroy the system and/or data, even if by mistake. Not pretty.
- The kernel mode driver implements the majority of the flashrom
code and the usermode code is merely a "front-end" to the kernel mode device driver which provides all of the chip related logic.
I like this a bit better.
I see. My problem right now in this version is to define the interface between the kernel driver and the user mode code. Quite hard to define the interface because it will use a quite different approach than the "mmap" approach in point 1.
It depends on how high level the driver tasks should be.
I would model this after flashrom command parameters.
Anyway, I'm also thinking about a quite "universal" interface between the user mode code and the kernel mode code. Perhaps a well defined interface
This requires a lot of extra work but has the benefit of only one generic algorithm being implemented in the kernel, thus the kernel
yes. That's why I'm currently thinking about the "evolutionary path" to this kind of functionality
Sure. Better a hack that works than nothing. :)
- or 2. will be a lot less work though. Maybe start there.
I like 2.
I'll have a look at this approach more closely.
Maybe you can actually identify trivial things that change in flashrom and create a small protocol for the application to specify them to the kernel driver.
The app could enumerate the PCI devices in the system and compare that with a list of write enable functions that are implemented in the driver. (The driver tells the app which functions are available, the app decides which one to use.)
Most of the time a new flash chip can be added to flashrom just by adding it's parameters to the chip table. If this table was in the application a lot would already be gained.
//Peter
On 5/2/07, Peter Stuge stuge-linuxbios@cdy.org wrote:
On Tue, May 01, 2007 at 11:20:20PM +0700, Darmawan Salihun wrote:
On Mon, Apr 30, 2007 at 10:50:07AM +0700, Darmawan Salihun wrote:
- The kernel mode code a.k.a kernel mode device driver is as
This would be OK, but there's a constant race between making the window large enough and new flash chips.
In my current experimental code. The "window" in the kernel driver is programmable, i.e. the user mode application passes the starting address of the MMIO range along with the size of the range to be mapped.
The problem with this is that the app could map ALL memory and destroy the system and/or data, even if by mistake. Not pretty.
I see, I overlooked the issue previously. This should be in my top list of consideration ;-).
- The kernel mode driver implements the majority of the flashrom
code and the usermode code is merely a "front-end" to the kernel mode device driver which provides all of the chip related logic.
I like this a bit better.
I see. My problem right now in this version is to define the interface between the kernel driver and the user mode code. Quite hard to define the interface because it will use a quite different approach than the "mmap" approach in point 1.
It depends on how high level the driver tasks should be.
I would model this after flashrom command parameters.
ok. This hint is helpful ;-).
Anyway, I'm also thinking about a quite "universal" interface
between the user mode code and the kernel mode code. Perhaps a well defined interface
This requires a lot of extra work but has the benefit of only one generic algorithm being implemented in the kernel, thus the kernel
yes. That's why I'm currently thinking about the "evolutionary path" to this kind of functionality
Sure. Better a hack that works than nothing. :)
- or 2. will be a lot less work though. Maybe start there.
I like 2.
I'll have a look at this approach more closely.
Maybe you can actually identify trivial things that change in flashrom and create a small protocol for the application to specify them to the kernel driver.
The app could enumerate the PCI devices in the system and compare that with a list of write enable functions that are implemented in the driver. (The driver tells the app which functions are available, the app decides which one to use.)
The current PCI device enumeration uses a cut-down version of the pciutils source code which I port to Windows (Quite trivial given the availability of inb,outb, ..., in the current kernel driver).
Most of the time a new flash chip can be added to flashrom just by
adding it's parameters to the chip table. If this table was in the application a lot would already be gained.
yes, of course this should be in the priority list.
-- Darmawan -------------------------------------------------------------------- -= Human knowledge belongs to the world =-
On Wed, May 02, 2007 at 12:09:39AM +0700, Darmawan Salihun wrote:
Do you think that this approach is foolproof
Certainly not, this is a very dangerous path, the entire operating system is circumvented. Tread carefully.
and extensible enough for the time being?
It allows flashrom to run with little modification, but it is not a solution I like.
On Wed, May 02, 2007 at 12:15:39AM +0700, Darmawan Salihun wrote:
The app could enumerate the PCI devices in the system and compare
The current PCI device enumeration uses a cut-down version of the pciutils source code which I port to Windows (Quite trivial given the availability of inb,outb, ..., in the current kernel driver).
That's not a good idea
This is because Windows assumes it has full control over hardware. Windows could start making a PCI config access at any time, including in the middle of the PCI config access you're doing directly with in/out functions.
Again, direct hardware access is very dangerous since you're operating under the feet of the operating system. Always use the Windows API for everything you can. Direct access only for memory reads and writes at the top of 4GB.
//Peter
On 5/2/07, Peter Stuge stuge-linuxbios@cdy.org wrote:
On Wed, May 02, 2007 at 12:09:39AM +0700, Darmawan Salihun wrote:
Do you think that this approach is foolproof
Certainly not, this is a very dangerous path, the entire operating system is circumvented. Tread carefully.
hmmm..., ok, this won't be the development path. Anyway, the current version is just a very early experimental version to test the MMIO related routine in the kernel mode driver.
and extensible enough for the time being?
It allows flashrom to run with little modification, but it is not a solution I like.
On Wed, May 02, 2007 at 12:15:39AM +0700, Darmawan Salihun wrote:
The app could enumerate the PCI devices in the system and compare
The current PCI device enumeration uses a cut-down version of the pciutils source code which I port to Windows (Quite trivial given the availability of inb,outb, ..., in the current kernel driver).
That's not a good idea
This is because Windows assumes it has full control over hardware. Windows could start making a PCI config access at any time, including in the middle of the PCI config access you're doing directly with in/out functions.
Again, direct hardware access is very dangerous since you're operating under the feet of the operating system. Always use the Windows API for everything you can. Direct access only for memory reads and writes at the top of 4GB.
OK. I see the problem now. Anyway, IIRC the PCI enumeration is not provided by "user mode" Windows API but it's available as kernel mode driver API in the OS.
--Darmawan -------------------------------------------------------------------- -= Human knowledge belongs to the world =-
Now, into a completely different issues. 1. How am I suppose to commit the source code for winflashrom (windows version of flashrom), once I got a working version of the code (at least tested to work in two testbed motherboard that I have rightnow)? 2. How the versioning system works in the current flashrom utility? Does it follow LinuxBIOS versioning?
-- Darmawan Salihun a.k.a Pinczakko -------------------------------------------------------------------- -= Human knowledge belongs to the world =-
* Darmawan Salihun darmawan.salihun@gmail.com [070506 07:02]:
- How am I suppose to commit the source code for winflashrom (windows version of flashrom), once I got a working version of the code (at least tested to work in two testbed motherboard that I have right now)?
I guess sending a unified diff against flashrom from the LinuxBIOSv2 tree would be the best way.
- How the versioning system works in the current flashrom utility? Does it
follow LinuxBIOS versioning?
It is currently part of the LinuxBIOSv2 tree, living under util/
There's Windows support for subversion here: http://tortoisesvn.tigris.org/
At some point we want to create a seperate LinuxBIOS utilities repository, but thats not there yet. Wont be a difference anyways.
On Sun, May 06, 2007 at 12:30:08PM +0200, Stefan Reinauer wrote:
- Darmawan Salihun darmawan.salihun@gmail.com [070506 07:02]:
- How am I suppose to commit the source code for winflashrom
I guess sending a unified diff against flashrom from the LinuxBIOSv2 tree would be the best way.
I'm not sure about this.
Does the Windows program build from the same source?
I think it's a separate directory but with some common files.
//Peter
On 5/7/07, Peter Stuge stuge-linuxbios@cdy.org wrote:
On Sun, May 06, 2007 at 12:30:08PM +0200, Stefan Reinauer wrote:
- Darmawan Salihun darmawan.salihun@gmail.com [070506 07:02]:
- How am I suppose to commit the source code for winflashrom
I guess sending a unified diff against flashrom from the LinuxBIOSv2 tree would be the best way.
I'm not sure about this.
Does the Windows program build from the same source?
I think it's a separate directory but with some common files.
Yeah, I think this should be the case, because there will be quite a lot
of difference in the platform specific support. I will try to get as close as possible though (aming for minimal effort on porting new versions of flashrom chip support). I'm still trying to figure out how to replace libpci now. Anyway, if you guys can come into a specific directory structure that I should adhere to, it will be very helpful ;-).
Thanks, -- Darmawan Salihun a.k.a Pinczakko -------------------------------------------------------------------- -= Human knowledge belongs to the world =-
On 5/1/07, Darmawan Salihun darmawan.salihun@gmail.com wrote:
On 5/1/07, Peter Stuge < stuge-linuxbios@cdy.org> wrote:
On Mon, Apr 30, 2007 at 10:50:07AM +0700, Darmawan Salihun wrote:
- The kernel mode code a.k.a kernel mode device driver is as
simple as possible and only provides "raw" functionality, i.e. capability to map the physical address space in which the BIOS chip is mapped into the requesting user mode code.
This would be OK, but there's a constant race between making the window large enough and new flash chips.
In my current experimental code. The "window" in the kernel driver is programmable, i.e. the user mode application passes the starting address of the MMIO range along with the size of the range to be mapped.
I'll elaborate more on this. The current kernel mode driver provides the following set of interface functions: ------------------------------------------------------------------------------------------ int InitDriver(); // returns 0 on error, 1 on success void CleanupDriver(); // must be called after done using the driver
void* MapPhysicalAddressRange( unsigned long phyAddrStart, unsigned long size ); // returns NULL on error, valid pointer on success int UnmapPhysicalAddressRange( void* virtAddrStart, unsigned long size ); // must be called when finished with the mapped physical memory
void outb(unsigned char value, unsigned short port); void outw(unsigned short value, unsigned short port); void outl(unsigned long value, unsigned short port);
unsigned char inb(unsigned short port); unsigned short inw(unsigned short port); unsigned long inl(unsigned short port); ------------------------------------------------------------------------------ The inX and outX match exactly with the Linux version of flashrom, therefore practically no changes in code. The MapPhysicalAddressRange() replaces the mmap() function in the Linux version of flashrom.
Do you think that this approach is foolproof and extensible enough for the time being?
PS: I'm still grepping through the latest flashrom to see wheter this is enough or I need to rework it.
-- Darmawan -------------------------------------------------------------------- -= Human knowledge belongs to the world =-
-
Darmawan Salihun -
Peter Stuge -
Quux -
roger -
Stefan Reinauer