I really should do more reading before bothering you guys. It would seem that the answer to my questions is CMOS non-volatile RAM, accessed via IO ports. How very odd.
Thanks again,
Alan Alexander mailto:alan@icerasemi.com Software Toolchain Engineering Icera Inc, 2520 The Quadrant, Aztec west, Bristol BS32 4AQ, UK Tel. +44 (0)1454 284805 -----Original Message----- From: linuxbios-bounces@linuxbios.org [mailto:linuxbios-bounces@linuxbios.org] On Behalf Of Alan Alexander Sent: 27 November 2007 11:09 To: bari Cc: linuxbios@linuxbios.org Subject: Re: [LinuxBIOS] flashrom support for AMD CS5536
Many thanks to all of the help regarding flashing of the Pm49fl004 device through the AMD CS5536 chipset on my IEI Nano LX board. I am now able to erase and write the entire 512KByte region as desired.
Unfortunately, it would appear that I have overlooked something in my quest for an automatic way to modify the legacy bios settings in our embedded Linux devices. Although I can now alter the BIOS at my hearts content, it seems that the actual BIOS settings themselves are stored elsewhere. For example:
0) BIOS settings are set to configuration 'a' 1) I make a change to the Legacy BIOS settings (using the BIOS boot menu) - configuration now 'b' (not equal to 'a') 2) I save the BIOS image (with configuration 'b') from the Pm49fl004 device via flashrom -r. 3) I revert the BIOS settings back to configuration 'a' using the BIOS boot menu. 4) I re-apply the saved image ('b') using flashrom -w and verify it with flashrom -v 5) On reboot the settings change applied in configuration 'b' are missing.
So, my conclusion is that the actual BIOS settings must be stored elsewhere. I suspect that this is probably obvious to you guys.
Could someone please tell me if this is the usual setup (i.e. BIOS flash + some other storage device for settings). If so, could someone also point me at a likely interface/device/address range for this 'other' storage device. Is it likely to be a SPI flash or something?
Any help greatly appreciated.
Best regards,
Alan Alexander mailto:alan@icerasemi.com Software Toolchain Engineering Icera Inc, 2520 The Quadrant, Aztec west, Bristol BS32 4AQ, UK Tel. +44 (0)1454 284805 -----Original Message----- From: bari [mailto:bari@onelabs.com] Sent: 23 November 2007 18:35 To: Alan Alexander Cc: linuxbios@linuxbios.org Subject: Re: [LinuxBIOS] flashrom support for AMD CS5536
Alan Alexander wrote:
Many thanks for the information. Unfortunately I don't have access to the board schematics and getting technical support from the board supplier is proving rather difficult.
I have confirmed via an oscilloscope that both the WP# and TBL# pins
are
permanently pulled high - indicating that no hardware write protection is enabled (so it looks like I may have side stepped the GPIO locking issue).
The pins WP# and TBL# are active low and would be tied high even in the case of having write protection. Have you seen the WP# or TBL# go low on
the scope during any of your write attempts?
I have also observed activity on the LFRAME#/FWH4 pin when
flashrom is attempting to write to the flash. Since I don't have
access
to X-ray equipment I think my best shot is to take a look at waveforms produced during a byte program cycle. I just need to get hold of that Logic Analyzer.......
That will tell you how much you have working during an attempt at a byte
program cycle. Are you able now to write to the memory area below the top-boot-block of the Flash? If so, all you have left to do is find out how they control the TBL#.
-Bari
-- ************************************************************************ ****************** This e-mail (including any attachments) is intended only for the recipient(s) named above. It may contain confidential or privileged information and should not be read, copied or otherwise used by any other person. If you are not a named recipient, please contact the sender by telephone (+44-1454-284800) and destroy the original message. Any statement and/or opinion not related to this company's business and expressed in this message is that of the author and does not necessarily reflect those of Icera. This company does not take any responsibility for the views of the author in any matter not related to the company's objective. ************************************************************************ ******************