<br><br><div><span class="gmail_quote">On 5/1/07, <b class="gmail_sendername">Darmawan Salihun</b> <<a href="mailto:darmawan.salihun@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">darmawan.salihun@gmail.com
</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><br><div><span><span class="gmail_quote">On 5/1/07, <b class="gmail_sendername">Peter Stuge</b> <<a href="mailto:stuge-linuxbios@cdy.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
stuge-linuxbios@cdy.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Mon, Apr 30, 2007 at 10:50:07AM +0700, Darmawan Salihun wrote:<br>> 1. The kernel mode code a.k.a kernel mode device driver is as<br>> simple as possible and only provides "raw" functionality, i.e.<br>
> capability to map the physical address space in which the BIOS
<br>> chip is mapped into the requesting user mode code.<br><br>This would be OK, but there's a constant race between making the<br>window large enough and new flash chips.<br></blockquote></span>In my current experimental code. The "window" in the kernel driver is programmable,
i.e. the user mode application <br>passes the starting address of the MMIO range along with the size of the range to be mapped. <span><br></span></div></blockquote></div><br>I'll elaborate more on this. The current kernel mode driver provides the following set of interface functions:
<br>------------------------------------------------------------------------------------------<br>int InitDriver(); // returns 0 on error, 1 on success<br>void CleanupDriver(); // must be called after done using the driver
<br><br>void* MapPhysicalAddressRange( unsigned long phyAddrStart, <br> unsigned long size ); // returns NULL on error, valid pointer on success<br>int UnmapPhysicalAddressRange( void* virtAddrStart,
<br> unsigned long size ); // must be called when finished with the mapped physical memory<br><br>void outb(unsigned char value, unsigned short port);<br>void outw(unsigned short value, unsigned short port);
<br>void outl(unsigned long value, unsigned short port);<br><br>unsigned char inb(unsigned short port);<br>unsigned short inw(unsigned short port);<br>unsigned long inl(unsigned short port);<br>------------------------------------------------------------------------------
<br>The inX and outX match exactly with the Linux version of flashrom, therefore practically no changes in code. <br>The MapPhysicalAddressRange() replaces the mmap() function in the Linux version of flashrom. <br><br>Do you think that this approach is foolproof and extensible enough for the time being?
<br><br>PS: I'm still grepping through the latest flashrom to see wheter this is enough or I need to rework it.<br><br>-- Darmawan<br>--------------------------------------------------------------------<br>-= Human knowledge belongs to the world =-