-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
So I am able to some what force read the chip, although it's not correct, I can see clearly parts of what I know is the Linux BIOS binary, and stuff that I know is not. My research tells me it uses a "28F320C3B" flash rom chip. I am starting to think I am completely screwed here, any help at all would be greatly appreciated.
Joshua McDowell
I'm really confused here. What is this platform? And why does the IB flash come into it?
ron
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
ron minnich wrote:
I'm really confused here. What is this platform? And why does the IB flash come into it?
ron
Ron, Now I am confused, because when you say something like "IB" I think "Infiniband". I assume this is a typo and you meant lbflash. It comes into it, because I know they used it to put Linux BIOS onto these boards. lbflash is dead, and cannot be raised from the dead, so I turned to flashrom, which doesn't work with these boards.
Thanks,
Joshua McDowell
On Wed, May 20, 2009 at 10:54 AM, Joshua McDowell jmcdowell@issisolutions.com wrote:
Now I am confused, because when you say something like "IB" I think "Infiniband".
I just wanted to be sure that the InfniBand flash memory was not playing into this in any way.
I assume this is a typo and you meant lbflash. It comes into it, because I know they used it to put Linux BIOS onto these boards. lbflash is dead, and cannot be raised from the dead, so I turned to flashrom, which doesn't work with these boards.
What are these boards?
If you had lbflash source, we might find the flash write enable magic and put it into flashrom. But to start, would be good to know what the boards are.
ron
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Intel® Server Board SE7520JR2 http://www.intel.com/support/motherboards/server/se7520jr2/sb/cs-013736.htm I am currently waiting for someone to power up the storage device that may contain the lbflash source code. I can tell you that lbflash uses /dev/mtdX to read and write to devices. So it may not have what you are looking for, I don't know.
Thanks,
Joshua McDowell
ron minnich wrote:
On Wed, May 20, 2009 at 10:54 AM, Joshua McDowell jmcdowell@issisolutions.com wrote:
Now I am confused, because when you say something like "IB" I think "Infiniband".
I just wanted to be sure that the InfniBand flash memory was not playing into this in any way.
I assume this is a typo and you meant lbflash. It comes into it, because I know they used it to put Linux BIOS onto these boards. lbflash is dead, and cannot be raised from the dead, so I turned to flashrom, which doesn't work with these boards.
What are these boards?
If you had lbflash source, we might find the flash write enable magic and put it into flashrom. But to start, would be good to know what the boards are.
ron
On Wed, May 20, 2009 at 10:59 AM, Joshua McDowell jmcdowell@issisolutions.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Intel® Server Board SE7520JR2 http://www.intel.com/support/motherboards/server/se7520jr2/sb/cs-013736.htm I am currently waiting for someone to power up the storage device that may contain the lbflash source code. I can tell you that lbflash uses /dev/mtdX to read and write to devices. So it may not have what you are looking for, I don't know.
that tells us a lot. We actually planned to use mtd layer in 2000 for everything, but there were continuous issues, so the stopgap flash-and-burn (which became flashrom) never stopped being used. LBFLASH went the mtd route, arguably better, it just never worked out as well for many people as flashrom.
LNXI IIRC developed LBFLASH.
The board enable magic for your board might be found in the mtd drivers. Intel habitually dedicates a GPIO pin for flash protection. You have to set the GPIO low (usually) to enable flash writing. This old mainboard certainly dates to that era.
And, it is unlikely that intel will tell you what the pin is.
rno
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I don't know if any of this will help.. But I am posting it anyway.. I also have a call into Intel's Advanced HPC ( EPSD ) division for more answers. Maybe they can help, maybe not.
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/56213
http://lists.infradead.org/pipermail/linux-mtd/2005-February/011990.html
https://dev.openwrt.org/browser/trunk/target/linux/brcm-2.4/files/arch/mips/...
http://git.denx.de/u-boot/include/flash.h
I am being as pro active as I can, hardly understanding what it is exactly that you need. Outside an exact white paper from Intel. Anything I can do, I am willing to help move this along. In the mean time, I am going to try to read the man page that I found for lbflash since I have it. It's hardly a solution I would want to rely on though.
Thanks,
Joshua McDowell
ron minnich wrote:
On Wed, May 20, 2009 at 10:59 AM, Joshua McDowell jmcdowell@issisolutions.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Intel® Server Board SE7520JR2 http://www.intel.com/support/motherboards/server/se7520jr2/sb/cs-013736.htm I am currently waiting for someone to power up the storage device that may contain the lbflash source code. I can tell you that lbflash uses /dev/mtdX to read and write to devices. So it may not have what you are looking for, I don't know.
that tells us a lot. We actually planned to use mtd layer in 2000 for everything, but there were continuous issues, so the stopgap flash-and-burn (which became flashrom) never stopped being used. LBFLASH went the mtd route, arguably better, it just never worked out as well for many people as flashrom.
LNXI IIRC developed LBFLASH.
The board enable magic for your board might be found in the mtd drivers. Intel habitually dedicates a GPIO pin for flash protection. You have to set the GPIO low (usually) to enable flash writing. This old mainboard certainly dates to that era.
And, it is unlikely that intel will tell you what the pin is.
rno
On Wed, May 20, 2009 at 11:37 AM, Joshua McDowell jmcdowell@issisolutions.com wrote:
Maybe they can help, maybe not.
oh, the vendor *can* help. But will they help? In the past they have made it clear that it is not their policy to release this kind of info. You don't need info on the flash part; you need info on the mainboard itself.
The kind of info is found in the linux kernel in drivers/mtd/maps, in files like this: alchemy-flash.c ipaq-flash.c rbtx4939-flash.c amd76xrom.c ixp2000.c redwood.c autcpu12-nvram.c ixp4xx.c rpxlite.c bfin-async-flash.c Kconfig sa1100-flash.c cdb89712.c l440gx.c sbc8240.c ceiva.c Makefile sbc_gxx.c cfi_flagadm.c map_funcs.c sc520cdp.c ck804xrom.c mbx860.c scb2_flash.c dbox2-flash.c netsc520.c scx200_docflash.c dc21285.c nettel.c solutionengine.c dilnetpc.c octagon-5066.c sun_uflash.c dmv182.c omap_nor.c tqm8xxl.c edb7312.c pci.c ts5500_flash.c esb2rom.c pcmciamtd.c tsunami_flash.c fortunet.c physmap.c uclinux.c h720x-flash.c physmap_of.c vmax301.c ichxrom.c plat-ram.c vmu-flash.c impa7.c pmcmsp-flash.c wr_sbc82xx_flash.c integrator-flash.c pmcmsp-ramroot.c intel_vr_nor.c pxa2xx-flash.c
Let's look at one of interest, for example, the l440gx.c. In it you find code like this:
/* Set the iobase */ iobase = pm_iobase->start; pci_write_config_dword(pm_dev, 0x40, iobase | 1);
/* Set XBCS# */ pci_read_config_word(dev, 0x4e, &word); word |= 0x4; pci_write_config_word(dev, 0x4e, word);
/* Supply write voltage to the chip */ l440gx_set_vpp(&l440gx_map, 1);
/* Enable the gate on the WE line */ outb(inb(TRIBUF_PORT) & ~1, TRIBUF_PORT);
printk(KERN_NOTICE "Enabled WE line to L440GX BIOS flash chip.\n");
The key line follows the comment: /* Enable the gate on the WE line */
This is the kind of code that enables mainboard flash writes. A lot of the board support in mtd is old; vendors don't help much with this kind of information, as they are scared of the dreaded BIOS virus.
But this is what we need. I was hoping MTD had it; I don't know how LBFLASH fixed the WE problem, but if you can get us source we can try to see.
ron
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Interestingly enough, I was able to get linux bios from the chip, just not correctly. The starting address wasn't correct and I don't think I got the whole thing. I doubt intel will help, and I will alert you the second I have access to the storage that I think has the source code.
Joshua
ron minnich wrote:
On Wed, May 20, 2009 at 11:37 AM, Joshua McDowell jmcdowell@issisolutions.com wrote:
Maybe they can help, maybe not.
oh, the vendor *can* help. But will they help? In the past they have made it clear that it is not their policy to release this kind of info. You don't need info on the flash part; you need info on the mainboard itself.
The kind of info is found in the linux kernel in drivers/mtd/maps, in files like this: alchemy-flash.c ipaq-flash.c rbtx4939-flash.c amd76xrom.c ixp2000.c redwood.c autcpu12-nvram.c ixp4xx.c rpxlite.c bfin-async-flash.c Kconfig sa1100-flash.c cdb89712.c l440gx.c sbc8240.c ceiva.c Makefile sbc_gxx.c cfi_flagadm.c map_funcs.c sc520cdp.c ck804xrom.c mbx860.c scb2_flash.c dbox2-flash.c netsc520.c scx200_docflash.c dc21285.c nettel.c solutionengine.c dilnetpc.c octagon-5066.c sun_uflash.c dmv182.c omap_nor.c tqm8xxl.c edb7312.c pci.c ts5500_flash.c esb2rom.c pcmciamtd.c tsunami_flash.c fortunet.c physmap.c uclinux.c h720x-flash.c physmap_of.c vmax301.c ichxrom.c plat-ram.c vmu-flash.c impa7.c pmcmsp-flash.c wr_sbc82xx_flash.c integrator-flash.c pmcmsp-ramroot.c intel_vr_nor.c pxa2xx-flash.c
Let's look at one of interest, for example, the l440gx.c. In it you find code like this:
/* Set the iobase */ iobase = pm_iobase->start; pci_write_config_dword(pm_dev, 0x40, iobase | 1);
/* Set XBCS# */ pci_read_config_word(dev, 0x4e, &word); word |= 0x4; pci_write_config_word(dev, 0x4e, word);
/* Supply write voltage to the chip */ l440gx_set_vpp(&l440gx_map, 1);
/* Enable the gate on the WE line */ outb(inb(TRIBUF_PORT) & ~1, TRIBUF_PORT);
printk(KERN_NOTICE "Enabled WE line to L440GX BIOS flash chip.\n");The key line follows the comment: /* Enable the gate on the WE line */
This is the kind of code that enables mainboard flash writes. A lot of the board support in mtd is old; vendors don't help much with this kind of information, as they are scared of the dreaded BIOS virus.
But this is what we need. I was hoping MTD had it; I don't know how LBFLASH fixed the WE problem, but if you can get us source we can try to see.
ron
On 20.05.2009 21:47, Joshua McDowell wrote:
Interestingly enough, I was able to get linux bios from the chip, just not correctly. The starting address wasn't correct and I don't think I got the whole thing.
Even without the source, a lbflash run will tell us a lot. Can you run lsmod after lbflash has run? That should allow us to find out which kernel modules lbflash is using, thereby leading us to the right WE line.
Regards, Carl-Daniel
I can't seem to get lbflash to work on that node. In the past on other nodes it would load mtdcore and something like amd76x. Joshua Joshua McDowell - Lead integrator
Sent from my Blackberry
-----Original Message----- From: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Date: Wed, 20 May 2009 21:57:34 To: Joshua McDowelljmcdowell@issisolutions.com Cc: ron minnichrminnich@gmail.com; coreboot@coreboot.org Subject: Re: [coreboot] Uh oh, looks like trouble...
On 20.05.2009 21:47, Joshua McDowell wrote:
Interestingly enough, I was able to get linux bios from the chip, just not correctly. The starting address wasn't correct and I don't think I got the whole thing.
Even without the source, a lbflash run will tell us a lot. Can you run lsmod after lbflash has run? That should allow us to find out which kernel modules lbflash is using, thereby leading us to the right WE line.
Regards, Carl-Daniel
Ok, I have a ton of src rpms for lbflash. I will need an ftp or something. Any takers? I think this is a great thing anyway, as this would all be lost otherwise, even if it doesn't help my problem.
Joshua McDowell - Lead integrator
Sent from my Blackberry
-----Original Message----- From: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Date: Wed, 20 May 2009 21:57:34 To: Joshua McDowelljmcdowell@issisolutions.com Cc: ron minnichrminnich@gmail.com; coreboot@coreboot.org Subject: Re: [coreboot] Uh oh, looks like trouble...
On 20.05.2009 21:47, Joshua McDowell wrote:
Interestingly enough, I was able to get linux bios from the chip, just not correctly. The starting address wasn't correct and I don't think I got the whole thing.
Even without the source, a lbflash run will tell us a lot. Can you run lsmod after lbflash has run? That should allow us to find out which kernel modules lbflash is using, thereby leading us to the right WE line.
Regards, Carl-Daniel
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
One last post on this, I am sure I am annoying you all to death. I posted a link earlier, I think.. Anyway, I found this post where someone claims to have gotten it to work with mtd by patching some files and he includes his changes.
http://lists.infradead.org/pipermail/linux-mtd/2005-February/011990.html
<snip> On Thu, Feb 24, 2005 at 05:55:52PM +0000, Greg Johnson wrote:
Hi,
I would like to be able to update the BIOS of a bunch of Intel SE7520JR2 motherboards from Linux. According to the spec for this board, it has a Intel 28F320C3B flash chip.
What would be required to support this under Linux MTD? Grepping the source reveals references to Intel 28F320B3 chips. Are these supported? If so, how similar are they? I'm happy to read the spec and write code, but I need a little direction first.
Ok, I was able to get the 28F320C3B to work as an MTD device by adding the appropriate entry to jedec_table[] in jedec_probe.c:
diff -ur linux-2.6.10/drivers/mtd/chips/jedec_probe.c linux-2.6.10-fix/drivers/mtd/chips/jedec_probe.c - --- linux-2.6.10/drivers/mtd/chips/jedec_probe.c 2004-12-24 16:35:40.000000000 -0500 +++ linux-2.6.10-fix/drivers/mtd/chips/jedec_probe.c 2005-02-24 19:34:20.790309335 -0500 @@ -101,6 +101,7 @@ #define I28F160B3B 0x8891 #define I28F320B3T 0x8896 #define I28F320B3B 0x8897 +#define I28F320C3B 0x88c5 #define I28F640B3T 0x8898 #define I28F640B3B 0x8899 #define I82802AB 0x00ad @@ -1018,6 +1019,20 @@ } }, { .mfr_id = MANUFACTURER_INTEL, + .dev_id = I28F320C3B, + .name = "Intel 28F320C3B", + .uaddr = { + [1] = MTD_UADDR_UNNECESSARY, /* x16 */ + }, + .DevSize = SIZE_4MiB, + .CmdSet = P_ID_INTEL_STD, + .NumEraseRegions= 2, + .regions = { + ERASEINFO(0x02000, 8), + ERASEINFO(0x10000, 63), + } + }, { + .mfr_id = MANUFACTURER_INTEL, .dev_id = I28F320B3T, .name = "Intel 28F320B3T", .uaddr = {
The parameters seem to be correct from the specs including the regions and sizes.
With this patch, I am able to read the entire 4MB of the device (using mtdchar), and the resulting file appears to contain valid BIOSes. However, I can only write to half of the chip, i.e. 2MB. I believe that this is because the BIOS does "rolling updates". The flash chip contains two copies of the BIOS. The flash chip is 4MB, and the BIOS image is 2MB. When updating, the active BIOS is saved, and the new BIOS is written to the other "partition". Afterwards, a flag is set somewhere telling the hardware which is the active partition to boot from. If for some reason the new BIOS is bad, the system falls back to the old one.
In any case, I am able to update the inactive partition (with flashcp), but don't know how to set the flag to make it active. Any thoughts on how to do this? Alternatively, if I could write to both partitions that would work. Maybe something to do with locking?
Thanks for any help,
Greg
</snip>
Carl-Daniel Hailfinger wrote:
On 20.05.2009 21:47, Joshua McDowell wrote:
Interestingly enough, I was able to get linux bios from the chip, just not correctly. The starting address wasn't correct and I don't think I got the whole thing.
Even without the source, a lbflash run will tell us a lot. Can you run lsmod after lbflash has run? That should allow us to find out which kernel modules lbflash is using, thereby leading us to the right WE line.
Regards, Carl-Daniel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I pasted the source from the file in this e-mail, so you can all tell me I am crazy when I am wrong. This ALL came from a GPLed package. I am also attaching the tgz this came out of. Basically it's the src.rpm output. Also, I did an md5sum on the test.rom and the same rom image from the rpm, and they were an exact match. So using the switch I mentioned when I sent out my correction was able to grab the rom image perfectly. Now the trick is getting the rom writable, and low and behold I find a jarrell_rom_jumper.c file with the linux bios source package for this version of linux bios.
( This is the second time I have sent this e-mail, the first one held because it exceeded the 2mb limit. So I am not re-attaching it, we will have to find another method or the moderator will have to release it.)
Please let me know if this helps, and thanx in advance.
Joshua McDowell
#define _GNU_SOURCE #include <getopt.h> #include <sys/types.h> #include <sys/wait.h> #include <sys/stat.h> #include <sys/ioctl.h> #include <sys/mman.h> #include <sys/io.h> #include <unistd.h> #include <fcntl.h> #include <errno.h> #include <string.h> #include <stdio.h> #include <stdlib.h> #include <stdint.h> #include <stdarg.h> #include "./freebios2/src/include/boot/linuxbios_tables.h"
#define PACKED __attribute__((packed))
#define cli() __asm__ __volatile__ ("cli" : : : "memory") #define sti() __asm__ __volatile__ ("sti" : : : "memory")
typedef uint32_t device_t;
#define FLOPPY_DEVICE 0 #define COM1_DEVICE 2 #define COM2_DEVICE 3 #define CWC_DEVICE 4 #define KBC_DEVICE 5 #define CIR_DEVICE 6 #define GPIO_DEVICE 7 #define FMC_DEVICE 9 #define WATCHDOG_DEVICE 0xa #define XBUS_DEVICE 0xf #define RTC_DEVICE 0x10 #define HMC_DEVICE 0x14
#define DEVICE_MAP (\ (1<<0)|(1<<2)|(1<<3)|(1<<4)|(1<<5)|(1<<6)|(1<<7)|(1<<9)|\ (1<<0xa)|(1<<0xf)|(1<<0x10)|(1<<0x14))
#define PNP_BASE_PORT 0x2e
#define PNP_DEV(PORT, FUNC) (((PORT) << 8) | (FUNC))
#define PNP_IDX_IO0 0x60 #define PNP_IDX_IO1 0x62 #define PNP_IDX_IO2 0x64 #define PNP_IDX_IO3 0x66 #define PNP_IDX_IRQ0 0x70 #define PNP_IDX_IRQ1 0x72 #define PNP_IDX_DRQ0 0x74 #define PNP_IDX_DRQ1 0x75
static void enter_pnp(device_t dev) { unsigned port = dev >> 8; unsigned device = dev & 0xff; /* Enter pnp mode */ /* noop */ /* Set the logical device */ outb(0x07, port); outb(device, port +1); }
static void exit_pnp(device_t dev) { /* noop */ }
/* I enter and exit pnp config mode with every access * so when I read an invalid address and potentially * mess up the state machine, the state machine gets * reset. */ static void pnp_write_config(device_t dev, uint8_t reg, uint8_t value) { unsigned port = dev >> 8; cli(); enter_pnp(dev); outb(reg, port); outb(value, port + 1); exit_pnp(dev); sti(); }
static uint8_t pnp_read_config(device_t dev, uint8_t reg) { unsigned port = dev >> 8; uint8_t result; cli(); enter_pnp(dev); outb(reg, port); result = inb(port +1); exit_pnp(dev); sti(); return result; }
static void pnp_set_enable(device_t dev, int enable) { pnp_write_config(dev, 0x30, enable?0x1:0x0); }
static int pnp_read_enable(device_t dev) { return pnp_read_config(dev, 0x30); }
static uint16_t pnp_read_iobase(device_t dev, unsigned index) { uint16_t iobase; iobase = pnp_read_config(dev, index) << 8; iobase |= pnp_read_config(dev, index + 1); return iobase; }
static uint8_t pnp_read_irq(device_t dev, unsigned index) { return pnp_read_config(dev, index); }
static uint8_t pnp_read_drq(device_t dev, unsigned index) { return pnp_read_config(dev, index); }
static void pnp_print_config(device_t dev, FILE *fp) { unsigned device = dev & 0xff; int i; fprintf(fp, "Resource configuration for device: 0x%02x\n", device); fprintf(fp, "Enabled: 0x%02x\n", pnp_read_enable(dev)); fprintf(fp, "iobase0: 0x%04x iobase1: 0x%04x iobase2: 0x%04x iobase3: 0x%04x\n", pnp_read_iobase(dev, PNP_IDX_IO0), pnp_read_iobase(dev, PNP_IDX_IO1), pnp_read_iobase(dev, PNP_IDX_IO2), pnp_read_iobase(dev, PNP_IDX_IO3)); fprintf(fp, "irq0: %2d irq1: %2d drq: %d\n", pnp_read_irq(dev, PNP_IDX_IRQ0), pnp_read_irq(dev, PNP_IDX_IRQ1), pnp_read_drq(dev, PNP_IDX_DRQ0)); for(i = 0x00; i < 256; i++) { unsigned char byte; byte = pnp_read_config(dev, i); if ((i & 0xf) == 0) { fprintf(fp, "%02x: ", i); } fprintf(fp, "%02x ", byte); if ((i & 0xf) == 0xf) { fprintf(fp, "\n"); } } fprintf(fp, "\n"); }
/* * Functions for accessing PCI configuration space with type 1 accesses */
#define PCI_DEV(BUS, DEV, FN) ( \ (((BUS) & 0xFF) << 16) | \ (((DEV) & 0x1f) << 11) | \ (((FN) & 0x7) << 8))
#define PCI_ID(VENDOR_ID, DEVICE_ID) \ ((((DEVICE_ID) & 0xFFFF) << 16) | ((VENDOR_ID) & 0xFFFF))
#define CONFIG_CMD(dev, where) (0x80000000 | dev | (where & ~3))
static uint8_t pci_read_config8(device_t dev, int where) { outl(CONFIG_CMD(dev,where), 0xCF8); return inb(0xCFC + (where&3)); }
static uint16_t pci_read_config16(device_t dev, int where) { outl(CONFIG_CMD(dev,where), 0xCF8); return inw(0xCFC + (where&2)); }
static uint32_t pci_read_config32(device_t dev, int where) { outl(CONFIG_CMD(dev,where), 0xCF8); return inl(0xCFC); }
static void pci_write_config8(device_t dev, int where, uint8_t value) { outl(CONFIG_CMD(dev,where), 0xCF8); outb(value, 0xCFC + (where&3)); }
static void pci_write_config16(device_t dev, int where, uint16_t value) { outl(CONFIG_CMD(dev,where), 0xCF8); outw(value, 0xCFC + (where&2)); }
static void pci_write_config32(device_t dev, int where, uint32_t value) { outl(CONFIG_CMD(dev,where), 0xCF8); outl(value, 0xCFC); }
#undef CONFIG_CMD
#define PCI_DEV_INVALID (0xffffffffU) static device_t pci_locate_device(unsigned pci_id, device_t dev) { for(; dev <= PCI_DEV(255, 31, 7); dev += PCI_DEV(0,0,1)) { unsigned int id; id = pci_read_config32(dev, 0); if (id == pci_id) { return dev; } } return PCI_DEV_INVALID; }
void udelay(int useconds) { struct timeval tv; tv.tv_sec = 0; tv.tv_usec = useconds; select(0, 0, 0, 0, &tv); }
/* jumper pin 1 -> sio_bios_sel (pin 52) jumper pin 2 -> (xbus_r_a20 to ROM) (ich5r pin r2 LDRQ1_N/GPI41) jumper pin 3 -> pull down resistor */
static void die(char *format, ...) { va_list args; va_start(args, format); vfprintf(stderr, format, args); va_end(args); exit(1); }
#define J_DISCONNECTED 0 #define J_1TO2 1 #define J_2TO3 2
void print_jumper_state(int state, FILE *fp) { if (state == J_DISCONNECTED) { fprintf(fp, "High -- disconnected"); } else if (state == J_1TO2) { fprintf(fp, "Toggling -- 1 to 2"); } else if (state == J_2TO3) { fprintf(fp, "Low -- 2 to 3"); } else { die("Impossible Jumper state\n"); } }
int main(int argc, char*argv[]) { device_t ich5r; device_t nsc87427; uint32_t gpio_base; uint32_t gpio_use_sel2, gp_lvl2; uint32_t gp_lvl2_lo, gp_lvl2_hi; uint16_t xbus_base; uint8_t xbimm, xbbsl; FILE *fp; int expected_jumper_state, jumper_state; int i;
expected_jumper_state = J_2TO3;
if (iopl(3) != 0) { die("iopl failed!\n"); }
/* Find the ich5r */ ich5r = pci_locate_device(PCI_ID(0x8086,0x24d0), 0); if (ich5r == PCI_DEV_INVALID) { fprintf(stderr, "Could not find southbridge\n"); } /* Find the gpio bar/base D31:F0 0x58-0x5b */ gpio_base = pci_read_config32(ich5r, 0x58); gpio_base &= ~1; #if 0 fprintf(stdout, "gpio_base: %08x\n", gpio_base); #endif if (gpio_base == 0) { die("gpio_base is not set!\n"); } /* Ensure the gpio line is properly setup */ gpio_use_sel2 = inl(gpio_base + 0x30); #if 0 fprintf(stdout, "gpio_use_sel2: %08x\n", gpio_use_sel2); #endif if ((gpio_use_sel2 & (1 << (41 - 32 ))) == 0) { die("gpio not configured to read high rom address line\n"); } #if 0 /* Read the rom address line */ gp_lvl2 = inl(gpio_base + 0x38); fprintf(stdout, "gp_lvl2: %08x 41=%d\n", gp_lvl2, (gp_lvl2 & (1 << (41 - 32)))?1:0 ); #endif
/* Get the superio device */ nsc87427 = PNP_DEV(PNP_BASE_PORT, XBUS_DEVICE);
/* Get the xbus base address */ xbus_base = pnp_read_iobase(nsc87427, PNP_IDX_IO0); if (xbus_base == 0) { die("xbus_base is not set!\n"); }
/* Clear the protections bits... */ for(i = 0; i < 32; i++) { outb(((i & 0xf) << 4) | 0, xbus_base + 0x13 + (i >> 4)); }
/* Copy the current xbus high bit confiugration */ xbimm = pnp_read_config(nsc87427, 0xfe); xbbsl = pnp_read_config(nsc87427, 0xff);
/* Disable toggling */ pnp_write_config(nsc87427, 0xff, xbbsl & 0x7f);
/* Force the bit high */ pnp_write_config(nsc87427, 0xfe, xbimm & 0x7f);
/* Read the rom address line */ gp_lvl2_lo = !!(inl(gpio_base + 0x38) & (1 << (41 - 32))); #if 0 fprintf(stdout, "41=%d\n", gp_lvl2_lo); #endif
/* Force the bit low */ pnp_write_config(nsc87427, 0xfe, xbimm | 0x80);
/* Read the rom address line */ gp_lvl2_hi = !!(inl(gpio_base + 0x38) & (1 << (41 - 32))); #if 0 fprintf(stdout, "41=%d\n", gp_lvl2_hi); #endif
/* Restore the xbus high bit configuration */ pnp_write_config(nsc87427, 0xfe, xbimm); pnp_write_config(nsc87427, 0xff, xbbsl);
/* Record the jumper state */ jumper_state = -1; /* Report the jumper state */ if (gp_lvl2_hi != gp_lvl2_lo) { jumper_state = J_1TO2; /* Because it toggles */ } else if (gp_lvl2_lo == 0) { jumper_state = J_2TO3; /* Because it is stuck low */ } else { jumper_state = J_DISCONNECTED; /* Becuase it is stuck high */ }
#if 0 /* Print the device registers */ pnp_print_config(nsc87427, stdout);
/* Get the xbus base address */ xbus_base = pnp_read_iobase(nsc87427, PNP_IDX_IO0); if (xbus_base == 0) { die("xbus_base is not set!\n"); } /* Dump the xbus io mapped registers */ for(i = 0; i <= 0x16; i++) { unsigned value; value = inb(xbus_base + i); fprintf(stdout, "%02x ", value); } fprintf(stdout, "\n");
/* Dump the protection bits... */ for(i = 0; i < 32; i++) { unsigned value; outb(((i & 0xf) << 4) | (1 << 3), xbus_base + 0x13 + (i >> 4)); value = inb(xbus_base + 0x13 + (i >> 4)); fprintf(stdout, "%02x ", value); if (((i+1) & 0xf) == 0) { fprintf(stdout, "\n"); } }
#endif /* Report the jumper state */ fp = stdout; fprintf(fp, "Current jumper state: "); print_jumper_state(jumper_state, fp); fprintf(fp, "\n"); if (expected_jumper_state != jumper_state) { fprintf(fp, "Expected: "); print_jumper_state(expected_jumper_state, fp); fprintf(fp, "\n"); exit(1); } return 0; }
I think this file is the key to writing the flash. This is how we used to do write enables before mainboard support went into flashrom.
ron
On Thu, May 21, 2009 at 9:44 AM, ron minnich rminnich@gmail.com wrote:
I think this file is the key to writing the flash. This is how we used to do write enables before mainboard support went into flashrom.
So the next thing for Joshua to do is compile this file and run it before running flashrom again, right?
Thanks, Myles
On Thu, May 21, 2009 at 9:45 AM, Myles Watson mylesgw@gmail.com wrote:
On Thu, May 21, 2009 at 9:44 AM, ron minnich rminnich@gmail.com wrote:
I think this file is the key to writing the flash. This is how we used to do write enables before mainboard support went into flashrom.
So the next thing for Joshua to do is compile this file and run it before running flashrom again, right?
yes.
ron
Forcing the use of "SST49LF160C" as the prom dumps the bios perfectly every time, even before the use of the newly discovered source code.
Joshua McDowell - Lead integrator
Sent from my Blackberry
-----Original Message----- From: ron minnich rminnich@gmail.com
Date: Thu, 21 May 2009 10:01:28 To: Myles Watsonmylesgw@gmail.com Cc: Joshua McDowelljmcdowell@issisolutions.com; Carl-Daniel Hailfingerc-d.hailfinger.devel.2006@gmx.net; coreboot@coreboot.org Subject: Re: [coreboot] jarrell_rom_jumper.c ( I think I found it )
On Thu, May 21, 2009 at 9:45 AM, Myles Watson mylesgw@gmail.com wrote:
On Thu, May 21, 2009 at 9:44 AM, ron minnich rminnich@gmail.com wrote:
I think this file is the key to writing the flash. This is how we used to do write enables before mainboard support went into flashrom.
So the next thing for Joshua to do is compile this file and run it before running flashrom again, right?
yes.
ron
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
So I ran built and then ran the program on a running node. I got the following output. Current jumper state: Low. -- 2 to 3 I then ran flashrom with no change.
Joshua McDowell - Lead integrator
Sent from my Blackberry
-----Original Message----- From: Myles Watson mylesgw@gmail.com
Date: Thu, 21 May 2009 10:45:45 To: ron minnichrminnich@gmail.com Cc: Joshua McDowelljmcdowell@issisolutions.com; Carl-Daniel Hailfingerc-d.hailfinger.devel.2006@gmx.net; coreboot@coreboot.org Subject: Re: [coreboot] jarrell_rom_jumper.c ( I think I found it )
On Thu, May 21, 2009 at 9:44 AM, ron minnich rminnich@gmail.com wrote:
I think this file is the key to writing the flash. This is how we used to do write enables before mainboard support went into flashrom.
So the next thing for Joshua to do is compile this file and run it before running flashrom again, right?
Thanks, Myles
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Joshua McDowell wrote:
My research tells me it uses a "28F320C3B" flash rom chip.
The chip has a 16-bit wide data bus, which flashrom can't really deal with.
I think you have to get the original tool going. One idea is to experiment with a kernel as recent as possible, make sure to enable MTD, and try using lbflash and the rom_jumper program.
//Peter
-
Carl-Daniel Hailfinger -
Joshua McDowell -
Joshua McDowell
-
Myles Watson -
Peter Stuge -
ron minnich