coreboot November 2007

coreboot@coreboot.org

75 participants
397 discussions

[LinuxBIOS] Slow and error prone bootstrap.
by Steve Isaacs 24 Nov '07

24 Nov '07

I'm working with a two dual core Opteron (2218HE) motherboard using a new and currently unsupported chipset from Broadcom. During the early startup I'm seeing the messages I've included below. I know I have problems in my Config.lb for the board which is causing the complaint about static devices at the end but my question is regarding the section containing the fidvid timeout messages. Can someone help me out by providing a clue for what I can do to correct the problem? Thanks, Steve LinuxBIOS-2.0.0._xxxx_Fallback OBJ-XXXX-XX Tue Nov 20 14:32:28 PST 2007 starting... (0,1) link=01 (1,0) link=01 02 nodes initialized. core0 started: 01 01 02 03SBLink=00 NC node|link=00 SMBus controller enabled INIT detected from ---- {APICID = 00 NODEID = 00 COREID = 00} --- Issuing SOFT_RESET... (0,1) link=01 (1,0) link=03 02 nodes initialized. core0 started: 01 *01*00000001 *02*00000001 *03*00000001 SBLink=00 NC node|link=00 SMBus controller enabled begin msr fid, vid 310a12120a120202 fidvid_bsp_stage1: time out while reading from ap 02 set fid failed for apicid =00 fidvid_bsp_stage2: time out while reading from ap 02 end msr fid, vid 310a120a0a120202 ht reset - Ram1.00 Ram1.01 Ram2.00 Registered 333Mhz Interleaved RAM: 0x00400000 KB Ram2.01 Registered 333Mhz Interleaved RAM: 0x00800000 KB Ram3 Initializing memory: done Initializing memory: done RAM: 0x00900000 KB Setting variable MTRR 02, base: 0000MB, range: 0800MB, type WB Setting variable MTRR 03, base: 0800MB, range: 0400MB, type WB DQS Training:RcvrEn:Pass1: 00 CTLRMaxDelay=78 done DQS Training:RcvrEn:Pass1: 01 CTLRMaxDelay=12 done DQS Training:DQSPos: 00 done DQS Training:DQSPos: 01 done DQS Training:RcvrEn:Pass2: 00 CTLRMaxDelay=7a done DQS Training:RcvrEn:Pass2: 01 CTLRMaxDelay=42 done DQS Training:tsc[00]=000000094c3914a3 DQS Training:tsc[01]=000000095401de5f DQS Training:tsc[02]=00000009540661c3 DQS Training:tsc[03]=0000000a4dae27f1 DQS Training:tsc[04]=0000000a57232364 mem_trained[00]=01 mem_trained[01]=01 Ram4 v_esp=000cefc8 testx = 5a5a5a5a Copying data from cache to ram -- switching to use ram as stack... Done testx = 5a5a5a5a Disabling cache as ram now Clearing initial memory region: Done Copying LinuxBIOS to ram. src=fffe8000 dst=00004000 linxbios_ram.nrv2b length = 000088d9 linxbios_ram.bin length = 000178cc Jumping to LinuxBIOS. LinuxBIOS-2.0.0._apollo_Fallback Tue Nov 20 14:32:28 PST 2007 booting... Enumerating buses... APIC_CLUSTER: 0 enabled PCI_DOMAIN: 0000 enabled PCI: 00:18.3 siblings=1 CPU: APIC: 00 enabled CPU: APIC: 01 enabled PCI: 00:19.0 [1022/1100] enabled PCI: 00:19.1 [1022/1101] enabled PCI: 00:19.2 [1022/1102] enabled PCI: 00:19.3 [1022/1103] enabled PCI: 00:19.3 siblings=1 CPU: APIC: 02 enabled CPU: APIC: 03 enabled PCI: pci_scan_bus for bus 00 PCI: 00:18.0 [1022/1100] enabled PCI: 00:18.1 [1022/1101] enabled PCI: 00:18.2 [1022/1102] enabled PCI: 00:18.3 [1022/1103] enabled PCI: 00:19.0 [1022/1100] enabled PCI: 00:19.1 [1022/1101] enabled PCI: 00:19.2 [1022/1102] enabled PCI: 00:19.3 [1022/1103] enabled PCI: 00:00.0 [1166/0140] enabled PCI: 00:10.0 [1166/0140] enabled next_unitid: 0015 PCI: 00:00.0 [1166/0031] enabled PCI: 00:15.0 [1166/0031] enabled next_unitid: 001d PCI: 00:02.0 PCI: 00:02.1 PCI: 00:02.2 PCI: 00:04.0 HT: Left over static devices. Check your Config.lb PCI: pci_scan_bus for bus 00 PCI: 00:01.0 [1166/0031] enabled PCI: 00:02.0 subbordinate bus PCI-X PCI: 00:02.0 [1166/0406] enabled PCI: 00:02.1 [1166/0429] enabled Disabling static device: PCI: 00:02.2 PCI: 00:03.0 subbordinate bus PCI-X PCI: 00:03.0 [1166/0406] enabled PCI: 00:03.1 [1166/0429] enabled PCI: 00:04.0 subbordinate bus PCI Express PCI: 00:04.0 [1166/0420] enabled PCI: 00:04.1 [1166/042a] enabled PCI: 00:05.0 subbordinate bus PCI Express PCI: 00:05.0 [1166/0422] enabled PCI: 00:05.1 [1166/042a] enabled PCI: 00:07.0 [1166/0408] enabled PCI: 00:07.1 [1166/0215] enabled PCI: 00:07.2 [1166/040a] enabled Disabling static device: PCI: 00:07.3 PCI: 00:07.4 [1166/040e] enabled PCI: 00:07.5 [1166/040e] enabled PCI: 00:07.6 [1166/040e] enabled PCI: 00:0f.0 [1002/515e] enabled PCI: 00:10.0 [1166/0140] enabled PCI: 00:11.0 subbordinate bus PCI Express PCI: 00:11.0 [1166/0142] disabled PCI: 00:12.0 subbordinate bus PCI Express PCI: 00:12.0 [1166/0144] enabled PCI: 00:13.0 subbordinate bus PCI Express PCI: 00:13.0 [1166/0142] disabled PCI: 00:14.0 subbordinate bus PCI Express PCI: 00:14.0 [1166/0144] disabled PCI: 00:01.1 PCI: 00:02.0 PCI: 00:02.1 PCI: 00:04.0 PCI: Left over static devices. Check your Config.lb

2 1

[LinuxBIOS] A good small mini-ITX case
by ron minnich 23 Nov '07

23 Nov '07

Any recommendations? I am trying to house the new SiS mainboard ... need a case that is open and makes it easy to get to parts like the SPI ... ron

3 2

Re: [LinuxBIOS] flashrom support for AMD CS5536
by bari 23 Nov '07

23 Nov '07

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

1 0

Re: [LinuxBIOS] flashrom support for AMD CS5536
by Alan Alexander 23 Nov '07

23 Nov '07

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). 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....... Best regards, Alan 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 17:15 To: Alan Alexander Cc: linuxbios(a)linuxbios.org Subject: Re: [LinuxBIOS] flashrom support for AMD CS5536 Alan Alexander wrote: > My mistake - that patch hasn't made a difference to the behaviour. > > It looks to me as if I'm unable to write to the top-block of the > Pm49FL004 device. Looking at the data sheet it appears that this device > has 2 write-protect pins - WP# (which looks as if it's wired up to the > AMD C5536 appropriately - such that writes to MSR 0x1808 have an effect) > and TBL# (Top-Block-Lock) which enables hardware write protection of the > top boot block (64Kbytes). Unfortunately I don't know how the TBL# pin > is connected to the CS5536. I'm guessing a GPIO. > > Does anyone have any experience of using this BIOS flash with the > CS5536? There is no "standard" or "required" way to connect the Top-Block-Lock pin to the CS5536. The board designers may have followed the AMD reference schematics or have done any number of other things with the signal. It appears that you don't have the schematics for the board. Try contacting tech support for your board and ask them if they know. Is there a jumper on the board to control writes to Flash? You may be able to trace the connections using a multimeter if they used thru and not blind vias under the CS5536. X-raying the board may also help, if you have access to the equipment. To make things more interesting many of the GPIO's on the CS5536 have Lock Bit registers to protect against accidental changes. Since TBL# is probably pulled up to high via a 4K-10K resistor, you could temporarily solder a connection from the TBL# to ground to enable it. Then you can test if you can write to the flash. -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. ******************************************************************************************

1 0

Re: [LinuxBIOS] flashrom support for AMD CS5536
by Alan Alexander 23 Nov '07

23 Nov '07

Reading through the data-sheet a bit more, it seems that the Block Locking Registers (BL_REG) are only available in FWH (Intel FirmWare Hub) mode. Perhaps the Savior RD-1's are using an LPC type interface? I suspect my CS5536 hook-up is LPC also. Cheers, Alan 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(a)linuxbios.org [mailto:linuxbios-bounces@linuxbios.org] On Behalf Of Corey Osgood Sent: 23 November 2007 07:57 To: Nikolay Petukhov Cc: linuxbios(a)linuxbios.org Subject: Re: [LinuxBIOS] flashrom support for AMD CS5536 Nikolay Petukhov wrote: > Info from pm49fl002/4's manual: Pm49fl002/4 write protected at power up. > This patch fix it. > I'm a bit confused, because I use the Pm49fl002/4 regularly, mostly in BIOS Savior RD-1's. I've never had any problems writing to those chips. This patch also needs a "Signed-off-by:" line, and a couple other things below. > diff -Nru LinuxBIOSv2-2978/util/flashrom/flashchips.c LinuxBIOSv2-2978-pm49fl00x/util/flashrom/flashchips.c > 'svn diff' does pretty much the same thing, but easier to apply. > diff -Nru LinuxBIOSv2-2978/util/flashrom/pm49fl004.c LinuxBIOSv2-2978-pm49fl00x/util/flashrom/pm49fl004.c > --- LinuxBIOSv2-2978/util/flashrom/pm49fl004.c 2007-10-18 05:55:15.000000000 +0600 > +++ LinuxBIOSv2-2978-pm49fl00x/util/flashrom/pm49fl004.c 1970-01-01 05:00:00.000000000 +0500 > @@ -1,51 +0,0 @@ > -/* > - * This file is part of the flashrom project. > - * > - * Copyright (C) 2004 Tyan Corporation > - * > - * This program is free software; you can redistribute it and/or modify > - * it under the terms of the GNU General Public License as published by > - * the Free Software Foundation; either version 2 of the License, or > - * (at your option) any later version. > - * > - * This program is distributed in the hope that it will be useful, > - * but WITHOUT ANY WARRANTY; without even the implied warranty of > - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > - * GNU General Public License for more details. > - * > - * You should have received a copy of the GNU General Public License > - * along with this program; if not, write to the Free Software > - * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA > - */ > - > -#include <stdio.h> > -#include "flash.h" > - > -extern int exclude_start_page, exclude_end_page; > - > -int write_49fl004(struct flashchip *flash, uint8_t *buf) > -{ > - int i; > - int total_size = flash->total_size * 1024; > - int page_size = flash->page_size; > - volatile uint8_t *bios = flash->virtual_memory; > - > - printf("Programming page: "); > - for (i = 0; i < total_size / page_size; i++) { > - if ((i >= exclude_start_page) && (i < exclude_end_page)) > - continue; > - > - /* erase the page before programming */ > - erase_block_jedec(bios, i * page_size); > - > - /* write to the sector */ > - printf("%04d at address: 0x%08x", i, i * page_size); > - write_sector_jedec(bios, buf + i * page_size, > - bios + i * page_size, page_size); > - printf("\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b"); > - fflush(stdout); > - } > - printf("\n"); > - > - return 0; > -} > We should probably do 'svn mv' to this file, instead of removing it, then patch against it. > diff -Nru LinuxBIOSv2-2978/util/flashrom/pm49fl00x.c LinuxBIOSv2-2978-pm49fl00x/util/flashrom/pm49fl00x.c > --- LinuxBIOSv2-2978/util/flashrom/pm49fl00x.c 1970-01-01 05:00:00.000000000 +0500 > +++ LinuxBIOSv2-2978-pm49fl00x/util/flashrom/pm49fl00x.c 2007-11-23 11:43:47.000000000 +0500 > @@ -0,0 +1,95 @@ > +/* > + * This file is part of the flashrom project. > + * > + * Copyright (C) 2004 Tyan Corporation > Please add yourself here. I can't tell who the original author was, so just leave the Tyan email blank. > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License, or > + * (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA > + */ > + > +#include <stdio.h> > +#include "flash.h" > + > +extern int exclude_start_page, exclude_end_page; > + > +static __inline__ int write_lockbits_49fl00x(volatile uint8_t *bios, int size, > + unsigned char bits, int block_size) > Why inlined? > +{ > + int i, left = size; > + > + //printf("bios=0x%08lx\n", (unsigned long)bios); > just drop this. we don't like committing commented code ;) > + for (i = 0; left >= block_size; i++, left -= block_size) { > + > + /* pm49fl002 */ > + if (block_size == 16384 && i%2) > + continue; > + > + //printf("lockbits at address=0x%08lx is 0x%01x\n", (unsigned long)0xFFC00000 - size + (i * block_size) + 2, *(bios + (i * block_size) + 2) ); > same here > + *(bios + (i * block_size) + 2) = bits; > + //printf("lockbits at address=0x%08lx is 0x%01x\n", (unsigned long)0xFFC00000 - size + (i * block_size) + 2, *(bios + (i * block_size) + 2) ); > and here > + } > + > + return 0; > I don't see any other return paths, any reason not to make this function void? > +} > + > +int probe_49fl00x(struct flashchip *flash) > +{ > + int ret = probe_jedec(flash); > + > + if (ret == 1) > + map_flash_registers(flash); > + > + return ret; > +} > + > +int erase_49fl00x(struct flashchip *flash) > +{ > + int total_size = flash->total_size * 1024; > + int page_size = flash->page_size; > + write_lockbits_49fl00x(flash->virtual_registers, total_size, 0, page_size); > + return erase_chip_jedec(flash); > +} > + > +int write_49fl00x(struct flashchip *flash, uint8_t *buf) > +{ > + int i; > + int total_size = flash->total_size * 1024; > + int page_size = flash->page_size; > + volatile uint8_t *bios = flash->virtual_memory; > + > + /* unprotected */ > + write_lockbits_49fl00x(flash->virtual_registers, total_size, 0, page_size); > IIRC, flashrom erases before writing. If that is the case, wouldn't this be unnecessary? > + > + printf("Programming page: "); > + for (i = 0; i < total_size / page_size; i++) { > + if ((i >= exclude_start_page) && (i < exclude_end_page)) > + continue; > + > + /* erase the page before programming */ > + erase_block_jedec(bios, i * page_size); > + > + /* write to the sector */ > + printf("%04d at address: 0x%08x", i, i * page_size); > + write_sector_jedec(bios, buf + i * page_size, > + bios + i * page_size, page_size); > + printf("\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b"); > + fflush(stdout); > + } > + printf("\n"); > + > + /* protected */ > + write_lockbits_49fl00x(flash->virtual_registers, total_size, 1, page_size); > + > + return 0; > +} -- linuxbios mailing list linuxbios(a)linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios -- ****************************************************************************************** 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. ******************************************************************************************

1 0

Re: [LinuxBIOS] flashrom support for AMD CS5536
by bari 23 Nov '07

23 Nov '07

Alan Alexander wrote: > My mistake - that patch hasn't made a difference to the behaviour. > > It looks to me as if I'm unable to write to the top-block of the > Pm49FL004 device. Looking at the data sheet it appears that this device > has 2 write-protect pins - WP# (which looks as if it's wired up to the > AMD C5536 appropriately - such that writes to MSR 0x1808 have an effect) > and TBL# (Top-Block-Lock) which enables hardware write protection of the > top boot block (64Kbytes). Unfortunately I don't know how the TBL# pin > is connected to the CS5536. I'm guessing a GPIO. > > Does anyone have any experience of using this BIOS flash with the > CS5536? There is no "standard" or "required" way to connect the Top-Block-Lock pin to the CS5536. The board designers may have followed the AMD reference schematics or have done any number of other things with the signal. It appears that you don't have the schematics for the board. Try contacting tech support for your board and ask them if they know. Is there a jumper on the board to control writes to Flash? You may be able to trace the connections using a multimeter if they used thru and not blind vias under the CS5536. X-raying the board may also help, if you have access to the equipment. To make things more interesting many of the GPIO's on the CS5536 have Lock Bit registers to protect against accidental changes. Since TBL# is probably pulled up to high via a 4K-10K resistor, you could temporarily solder a connection from the TBL# to ground to enable it. Then you can test if you can write to the flash. -Bari

1 0

Re: [LinuxBIOS] flashrom support for AMD CS5536
by Alan Alexander 23 Nov '07

23 Nov '07

My mistake - that patch hasn't made a difference to the behaviour. It looks to me as if I'm unable to write to the top-block of the Pm49FL004 device. Looking at the data sheet it appears that this device has 2 write-protect pins - WP# (which looks as if it's wired up to the AMD C5536 appropriately - such that writes to MSR 0x1808 have an effect) and TBL# (Top-Block-Lock) which enables hardware write protection of the top boot block (64Kbytes). Unfortunately I don't know how the TBL# pin is connected to the CS5536. I'm guessing a GPIO. Does anyone have any experience of using this BIOS flash with the CS5536? Many thanks, Alan 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+alan=icerasemi.com(a)linuxbios.org [mailto:linuxbios-bounces+alan=icerasemi.com@linuxbios.org] On Behalf Of Alan Alexander Sent: 23 November 2007 11:24 To: Nikolay Petukhov; linuxbios(a)linuxbios.org Subject: Re: [LinuxBIOS] flashrom support for AMD CS5536 Thanks for the information. The patch certainly seems to have cured that problem. Unfortunately, although I can now write to the Flash (and verify the contents) it seems that the image is over-written when the board reboots (i.e. the BIOS change doesn't take effect and a subsequent verification of the previously verified image fails). Presumably there's a shadow copy left unmodified somewhere? Any ideas? 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: linuxbios-bounces+alan=icerasemi.com(a)linuxbios.org [mailto:linuxbios-bounces+alan=icerasemi.com@linuxbios.org] On Behalf Of Nikolay Petukhov Sent: 23 November 2007 07:06 To: linuxbios(a)linuxbios.org Subject: Re: [LinuxBIOS] flashrom support for AMD CS5536 2007/11/22, "Alan Alexander" <alan(a)IceraSemi.com>: > > Hi all, > > I've recently checked out and built revision 2977 of flashrom in order > to apply a simple BIOS configuration change to approx 200 embedded Linux > devices. > Unfortunately although flashrom is able to read the contents of the BIOS > flash, writes fail to take (verification fails). > > The system basics are as follows: > IEI NanoLX Board (AMD LX800 + CS5536 + Winbond W83627EHG) > http://www.ieiworld.com/en/product_IPC.asp?model=NANO-LX > Linux Kernel Version 2.6.20 > Flash part identified by flashrom as Pm49FL004 at physical > address 0xfff80000 (512 KB) > > I see from the source code that the CS5536 chipset is directly supported > and that the code attempts to remove the write protection via MSR > 0x1808. This all looks good and yet the writes fail to take. I assume > therefore that this board is using some GPIOs to disable writes to the > BIOS flash? > > Does it sound likely that GPIOs are causing the write problem that I am > seeing? Does anyone know how I might go about figuring out which GPIOs > to look at? > > Any help would be very appreciated. > > Best regards, > > > Alan Alexander mailto:alan@icerasemi.com > Icera Inc, 2520 The Quadrant, Aztec west, Bristol BS32 4AQ, UK > Tel. +44 (0)1454 284805 I have the same problems with flashrom on iei/pcisa-lx. http://www.ieiworld.com/en/product_IPC.asp?model=PCISA-LX (Flash Pm49FL004) Info from pm49fl002/4's manual: Pm49fl002/4 write protected at power up. This patch fix it. -- Nikolay -- ************************************************************************ ****************** 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. ************************************************************************ ****************** -- linuxbios mailing list linuxbios(a)linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios -- ****************************************************************************************** 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. ******************************************************************************************

1 0

Re: [LinuxBIOS] flashrom support for AMD CS5536
by Alan Alexander 23 Nov '07

23 Nov '07

Thanks for the information. The patch certainly seems to have cured that problem. Unfortunately, although I can now write to the Flash (and verify the contents) it seems that the image is over-written when the board reboots (i.e. the BIOS change doesn't take effect and a subsequent verification of the previously verified image fails). Presumably there's a shadow copy left unmodified somewhere? Any ideas? 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: linuxbios-bounces+alan=icerasemi.com(a)linuxbios.org [mailto:linuxbios-bounces+alan=icerasemi.com@linuxbios.org] On Behalf Of Nikolay Petukhov Sent: 23 November 2007 07:06 To: linuxbios(a)linuxbios.org Subject: Re: [LinuxBIOS] flashrom support for AMD CS5536 2007/11/22, "Alan Alexander" <alan(a)IceraSemi.com>: > > Hi all, > > I've recently checked out and built revision 2977 of flashrom in order > to apply a simple BIOS configuration change to approx 200 embedded Linux > devices. > Unfortunately although flashrom is able to read the contents of the BIOS > flash, writes fail to take (verification fails). > > The system basics are as follows: > IEI NanoLX Board (AMD LX800 + CS5536 + Winbond W83627EHG) > http://www.ieiworld.com/en/product_IPC.asp?model=NANO-LX > Linux Kernel Version 2.6.20 > Flash part identified by flashrom as Pm49FL004 at physical > address 0xfff80000 (512 KB) > > I see from the source code that the CS5536 chipset is directly supported > and that the code attempts to remove the write protection via MSR > 0x1808. This all looks good and yet the writes fail to take. I assume > therefore that this board is using some GPIOs to disable writes to the > BIOS flash? > > Does it sound likely that GPIOs are causing the write problem that I am > seeing? Does anyone know how I might go about figuring out which GPIOs > to look at? > > Any help would be very appreciated. > > Best regards, > > > Alan Alexander mailto:alan@icerasemi.com > Icera Inc, 2520 The Quadrant, Aztec west, Bristol BS32 4AQ, UK > Tel. +44 (0)1454 284805 I have the same problems with flashrom on iei/pcisa-lx. http://www.ieiworld.com/en/product_IPC.asp?model=PCISA-LX (Flash Pm49FL004) Info from pm49fl002/4's manual: Pm49fl002/4 write protected at power up. This patch fix it. -- Nikolay -- ****************************************************************************************** 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. ******************************************************************************************

1 0

Re: [LinuxBIOS] flashrom support for AMD CS5536
by Nikolay Petukhov 23 Nov '07

23 Nov '07

2007/11/22, "Alan Alexander" <alan(a)IceraSemi.com>: > > Hi all, > > I've recently checked out and built revision 2977 of flashrom in order > to apply a simple BIOS configuration change to approx 200 embedded Linux > devices. > Unfortunately although flashrom is able to read the contents of the BIOS > flash, writes fail to take (verification fails). > > The system basics are as follows: > IEI NanoLX Board (AMD LX800 + CS5536 + Winbond W83627EHG) > http://www.ieiworld.com/en/product_IPC.asp?model=NANO-LX > Linux Kernel Version 2.6.20 > Flash part identified by flashrom as Pm49FL004 at physical > address 0xfff80000 (512 KB) > > I see from the source code that the CS5536 chipset is directly supported > and that the code attempts to remove the write protection via MSR > 0x1808. This all looks good and yet the writes fail to take. I assume > therefore that this board is using some GPIOs to disable writes to the > BIOS flash? > > Does it sound likely that GPIOs are causing the write problem that I am > seeing? Does anyone know how I might go about figuring out which GPIOs > to look at? > > Any help would be very appreciated. > > Best regards, > > > Alan Alexander mailto:alan@icerasemi.com > Icera Inc, 2520 The Quadrant, Aztec west, Bristol BS32 4AQ, UK > Tel. +44 (0)1454 284805 I have the same problems with flashrom on iei/pcisa-lx. http://www.ieiworld.com/en/product_IPC.asp?model=PCISA-LX (Flash Pm49FL004) Info from pm49fl002/4's manual: Pm49fl002/4 write protected at power up. This patch fix it. -- Nikolay

2 1

[LinuxBIOS] MSI K8N Neo3 MS-7135 progress?
by jakllsch＠kollasch.net 23 Nov '07

23 Nov '07

Hi, Subject says most if not all of it. David? Anyway, I've got one, I just put a socket on it, but I'll still need to find a second memory device that is compatible. Jonathan Kollasch

1 0

← Newer
1
...
14
15
16
17
18
19
20
...
40
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot November 2007