[LinuxBIOS] flashrom support for AMD Geode CS5536
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 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
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?
More information about the coreboot