[LinuxBIOS] flashrom support for AMD Geode CS5536

Lane Brooks lbrooks at MIT.EDU
Tue Oct 2 19:32:52 CEST 2007


Jordan Crouse wrote:
> On 02/10/07 18:27 +0200, Stefan Reinauer wrote:
>> Dear Lane!
>>
>> Thank you very much for your patch.
>>
>> * Lane Brooks <lbrooks at MIT.EDU> [071002 18:20]:
>>> - It seems like there should be a way to revert the msr back after flashing 
>>> is completed to put the bios back in write protect mode.  Is there a 
>>> cleanup mechanism available?  Something like disable_flash...
>> Unfortunately no. Any patches that generically implement such a
>> mechanism are welcome though!
>>
>>
>>> +#define _LARGEFILE64_SOURCE
>>> +#include <sys/types.h>
>>> +#include <sys/stat.h>
>>> +#include <fcntl.h>
>>> +#include <unistd.h>
>>> +	unsigned long addr = 0x1808;
>>> +	lseek64(fd_msr, (off64_t) addr, SEEK_SET);
>> Why do you use/need large file support for seeking to an offset of
>> 0x1808 ?
> 
> Thats original generic MSR behavior from rdmsr/wrmsr - we need the
> large file support to access the high MSRs (0x80000000) and
> above.  Its not needed in this case - but is it hurting?
> 
> Jordan


Jordan brings up a point that I forgot to mention previously.  This is 
my first time contributing to an open source project, and I am not 
extremely familiar with protocols in terms of acknowledging code.  I 
based this patch on rdmsr/wrmsr code I found on the OLPC webpage, and it 
seems attributable to Ron Minnich.  Should I acknowledge this fact in 
the code?

Furthermore, I debated whether I should include the generic rdmsr/wrmsr 
functions rather than incorporating them into the flash_enable_cs5526() 
function.  I chose not to include the generic functions because it 
seemed a cleaner approach in the grand scheme of the flashrom code base 
given that non of the other chipset enable functions seem to require 
helper functions.  Any feedback on this point?  Will other chipsets ever 
need to use the MSR to unlock the bios?

Lane




More information about the coreboot mailing list