December 2008 - coreboot - mail.coreboot.org

r1088 - in coreboot-v3: arch/x86 arch/x86/amd/k8 include/arch/x86 mainboard/amd/dbm690t mainboard/amd/serengeti mainboard/gigabyte/m57sli
by svn＠coreboot.org Dec. 30, 2008

Dec. 30, 2008

Author: cozzie Date: 2008-12-30 08:02:52 +0100 (Tue, 30 Dec 2008) New Revision: 1088 Modified: coreboot-v3/arch/x86/amd/k8/stage1.c coreboot-v3/arch/x86/stage1_mtrr.c coreboot-v3/include/arch/x86/mtrr.h coreboot-v3/mainboard/amd/dbm690t/Makefile coreboot-v3/mainboard/amd/serengeti/Makefile coreboot-v3/mainboard/gigabyte/m57sli/Makefile Log: Fix breakage of k8 targets caused by r1085. Thanks to Myles Watson for tracking down the offending commit. Signed-off-by: Corey Osgood <corey.osgood(a)gmail.com> Acked-by: Peter Stuge <peter(a)stuge.se> Modified: coreboot-v3/arch/x86/amd/k8/stage1.c =================================================================== --- coreboot-v3/arch/x86/amd/k8/stage1.c 2008-12-23 23:44:39 UTC (rev 1087) +++ coreboot-v3/arch/x86/amd/k8/stage1.c 2008-12-30 07:02:52 UTC (rev 1088) @@ -35,7 +35,7 @@ */ void set_init_ram_access(void) { - set_var_mtrr(0, 0x00000000, CONFIG_CBMEMK << 10, MTRR_TYPE_WRBACK); + stage1_set_var_mtrr(0, 0x00000000, CONFIG_CBMEMK << 10, MTRR_TYPE_WRBACK); } /** Modified: coreboot-v3/arch/x86/stage1_mtrr.c =================================================================== --- coreboot-v3/arch/x86/stage1_mtrr.c 2008-12-23 23:44:39 UTC (rev 1087) +++ coreboot-v3/arch/x86/stage1_mtrr.c 2008-12-30 07:02:52 UTC (rev 1088) @@ -25,7 +25,7 @@ wrmsr(MTRRphysMask_MSR(reg), zero); } -void set_var_mtrr( +void stage1_set_var_mtrr( unsigned long reg, unsigned long base, unsigned long size, unsigned long type) { @@ -63,7 +63,7 @@ { /* Enable caching for 0 - 1MB using variable mtrr */ disable_cache(); - set_var_mtrr(0, 0x00000000, CONFIG_CBMEMK << 10, type); + stage1_set_var_mtrr(0, 0x00000000, CONFIG_CBMEMK << 10, type); enable_cache(); } @@ -98,7 +98,7 @@ /* enable write through caching so we can do execute in place * on the flash rom. */ - set_var_mtrr(1, XIP_ROM_BASE, XIP_ROM_SIZE, MTRR_TYPE_WRBACK); + stage1_set_var_mtrr(1, XIP_ROM_BASE, XIP_ROM_SIZE, MTRR_TYPE_WRBACK); #endif #endif Modified: coreboot-v3/include/arch/x86/mtrr.h =================================================================== --- coreboot-v3/include/arch/x86/mtrr.h 2008-12-23 23:44:39 UTC (rev 1087) +++ coreboot-v3/include/arch/x86/mtrr.h 2008-12-30 07:02:52 UTC (rev 1088) @@ -35,6 +35,8 @@ void x86_setup_var_mtrrs(unsigned address_bits); void x86_setup_mtrrs(unsigned address_bits); int x86_mtrr_check(void); +void stage1_set_var_mtrr(unsigned long reg, unsigned long base, + unsigned long size, unsigned long type); #endif Modified: coreboot-v3/mainboard/amd/dbm690t/Makefile =================================================================== --- coreboot-v3/mainboard/amd/dbm690t/Makefile 2008-12-23 23:44:39 UTC (rev 1087) +++ coreboot-v3/mainboard/amd/dbm690t/Makefile 2008-12-30 07:02:52 UTC (rev 1088) @@ -26,6 +26,7 @@ $(src)/arch/x86/amd/model_fxx/stage1.c \ $(src)/northbridge/amd/k8/get_nodes.c \ $(src)/northbridge/amd/k8/libstage1.c \ + $(src)/arch/x86/stage1_mtrr.c INITRAM_SRC= $(src)/mainboard/$(MAINBOARDDIR)/initram.c \ $(src)/northbridge/amd/k8/raminit.c \ Modified: coreboot-v3/mainboard/amd/serengeti/Makefile =================================================================== --- coreboot-v3/mainboard/amd/serengeti/Makefile 2008-12-23 23:44:39 UTC (rev 1087) +++ coreboot-v3/mainboard/amd/serengeti/Makefile 2008-12-30 07:02:52 UTC (rev 1088) @@ -30,6 +30,7 @@ $(src)/southbridge/amd/amd8111/stage1_smbus.c \ $(src)/southbridge/amd/amd8111/stage1_ctrl.c \ $(src)/southbridge/amd/amd8111/stage1_enable_rom.c \ + $(src)/arch/x86/stage1_mtrr.c STAGE0_DYNAMIC_SRC := $(obj)/mainboard/$(MAINBOARDDIR)/option_table.c Modified: coreboot-v3/mainboard/gigabyte/m57sli/Makefile =================================================================== --- coreboot-v3/mainboard/gigabyte/m57sli/Makefile 2008-12-23 23:44:39 UTC (rev 1087) +++ coreboot-v3/mainboard/gigabyte/m57sli/Makefile 2008-12-30 07:02:52 UTC (rev 1088) @@ -29,6 +29,7 @@ $(src)/northbridge/amd/k8/libstage1.c \ $(src)/southbridge/nvidia/mcp55/stage1_smbus.c \ $(src)/southbridge/nvidia/mcp55/stage1_enable_rom.c \ + $(src)/arch/x86/stage1_mtrr.c STAGE0_DYNAMIC_SRC := $(obj)/mainboard/$(MAINBOARDDIR)/option_table.c

1 0

SeaBIOS and USB?
by Kevin O'Connor Dec. 30, 2008

Dec. 30, 2008

SeaBIOS is now booting multiple operating systems on real hardware (including WinXP, WinVista, Linux, Freedos, etc.). I think it is time to start looking at the next steps for SeaBIOS. USB support is a feature that SeaBIOS must have in order to be competitive with an "off the shelf" bios. I've spent some time investigating how this could be added. This email is to gather feedback from the coreboot developers and to see if there is an approach that makes sense. A legacy bios typically has two main USB features - usb mass storage handling and usb keyboard/mouse handling. The former is needed to support booting from flash drives, external hard drives, and usb cdroms. The latter is needed because some users only have a usb keyboard - indeed, many machines no longer have PS/2 ports. Both of the above require usb code that runs in 16bit mode. This certainly complicates the usb support - there are several open source projects that implement usb, but I'm not aware of any with this requirement. Since SeaBIOS is compiled with gcc a lot of the issues with 16bit mode wont be a problem; however, the memory restrictions of 16bit mode can't be ignored. Some info on the usb requirements: Mass storage requirements: The usb drive support looks to be straight forward. There is a document describing the minimum commands a bios can expect to have from a drive capable of booting the machine (search usb_msc_boot_1.0.pdf). It would seem that the 16bit code need only support sending BulkOut packets and receiving BulkIn packets. Interrupt support would not be needed, as the bios can poll for completion of requests. Keyboard/mouse requirements: Thankfully, full HID support is not needed as the USB spec includes a "boot" mode for keyboard and mice. The limited features of "boot" mode is sufficient for our purposes. The 16bit code would need to be able to send Control packets and receive InterruptIn packets. It looks like it will be necessary to have a USB interrupt handler - the 16bit code will need to catch an interrupt, extract the kbd/mouse data, and then ack the irq. I think it would be possible to add the above USB support to SeaBIOS. The initialization phase of SeaBIOS (aka "post") runs in 32bit mode today. The usb setup, bus scan, and hub detection can all be done during this post phase. All the dma setup, device initialization, and endpoint connections can also be done. It should then be possible to arrange for a handful of "transfer descriptors" to be setup in memory below 1MiB for all the requests that could be needed when in 16bit mode. The 16bit mode code would then only need to know how to fill out a "transfer descriptor" to communicate with the usb devices. This would require that SeaBIOS add support for uhci and ohci controllers. (Support for ehci would also be possible, but it would only speed up mass storage support - it is probably not worth the complexity.) It would also be necessary to setup irqs on the usb controller. In particular, this means coreboot will need to populate PCI_INTERRUPT_LINE and make sure that the pci devices are available in PIC mode. This type of support would limit the ability for the BIOS to support "plug and play" with devices. Only devices found during "post" would be available after post, and any device found during post but subsequently removed would no longer be available. However, the primary target for SeaBIOS is support for OS loaders (eg, lilo/grub/ntldr), and I don't think supporting plug-and-play during the small time window from bios post to OS load is critical. Finally, this style of support would not emulate a keyboard/mouse for software that uses direct PS/2 io port accesses (0x60/0x64). However, I have confirmed that none of lilo, grub, nor the windows boot loader directly access these ports. (Indeed, even freedos calls the bios to read the keyboard/mouse.) An alternative to the above plan would be to implement an SMI handler for USB support. I read somewhere that "off the shelf" bios frequently do this. Using an SMI handler would allow the usb code to all be 32bit, and it would allow full emulation of PS/2 keyboard/mouse accesses (ioport 0x60/0x64). However, there are some disadvantages to using an SMI handler: SMI appears to be board specific to setup, SMI has a "bad rap" among many developers, it may not be easy to share an SMI handler with vendor code and bios usb code, and it might be difficult to coordinate kbd/mouse and disk accesses if only part is done with SMI. One nice tool that already has USB support (uhci) is libpayload. Unfortunately, libpayload seems to be targeted for standalone "applications" and it doesn't seem to fit SeaBIOS' model. Because SeaBIOS needs to support 16bit callbacks it has more stringent requirements then a typical bootloader does. (An example of this in libpayload is the malloc call - malloc doesn't make sense in seabios because there are distinct areas that one can grab memory from (high memory, ebda, f segment, option rom area, etc.). The parameters to malloc aren't descriptive enough to convey these requirements.) One way forward would be to introduce these complications to libpayload and then use libpayload in seabios. Another option would be to introduce separate usb support in seabios. Well - that was a long email - thanks for reading. Any thoughts? -Kevin

3 2

hardware usb analyzers
by ron minnich Dec. 30, 2008

Dec. 30, 2008

any recommendations? This is not for coreboot, it is for debugging plan 9 usb drivers. We would prefer one that does not need a windows host to work. Ideally we could attach it to ethernet and talk to it that way. thanks ron

2 1

[PATCH][flashrom] Fix build on ubuntu 8.10 x86_64
by Corey Osgood Dec. 30, 2008

Dec. 30, 2008

Patch attached. -Corey

1 1

Re: [coreboot] #2: Complete tables of supported motherboards
by coreboot Dec. 29, 2008

Dec. 29, 2008

#2: Complete tables of supported motherboards ----------------------------------+----------------------------------------- Reporter: uwe | Owner: somebody Type: task | Status: new Priority: major | Milestone: Component: wiki/website/tracker | Version: Keywords: | Dependencies: ----------------------------------+----------------------------------------- Comment(by Radaguask): Today launched the new super program . It at one's desire be one of the wealthiest programs of 2009-2010 ! Program use permit lay out and Anti-DDoS keeping!!! From their plat: We, the TheWinterProfit.com , are pleased as Punch to invite You to participate in our Investment Programs. prefer released to to our webpage, to connection us for any humanitarian of questions, and of assuredly to border on to our Programs. We are a prominent assemble of hermit-like individuals, most of our teammates are masterful bankers and customrs, who compel ought to made cold hard cash fully cautious investments in the invest in hustle on a worldwide footing for through 8 years. Our gang is made up of American and European people, as follows we are masterly to take note of and deal on the abundant markets on the verge of 14 - 18 hours a day. We drink been participating in multifarious online and offline ventures, resulting in significant margins of profit for the owners and for the investors. Plans: 108 % after 1 day 118% after 2 days 128% after 3 days 10% referral commission! http://thewinterprofit.com/?ref=jon -- Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/2#comment:6> coreboot <http://www.coreboot.org/>

1 0

Good v3 port candidate for Socket F
by Myles Watson Dec. 29, 2008

Dec. 29, 2008

All, I'm looking for a system to port to v3. It needs to be Dual socket F. Here's the "simplified" block diagram of the system that I have: Opteron - Opteron | Chipset | PCIe And the system that I need: Opteron - Opteron | | PCIe Chipset Notice that the second socket has an independent link to a PCIe controller. The Tyan s2895 would work, but I need socket F. My question is if you know of any Socket F systems that would fit the bill. I'm especially interested in what chipsets they use. I'd like to port it to Coreboot-v3. Thanks, Myles

4 11

Want to participate in ASUS M2V(K8T890/VT8237A) testing
by torkwemada＠gmail.com Dec. 29, 2008

Dec. 29, 2008

Hello, I have ASUS M2V VIA K8T890 VIA VT8237A motherboard and BIOS saver device. I see that the closest supported configurations are: ASUS A8V-E SE<http://www.asus.com.tw/products.aspx?l1=3&l2=15&l3=143&l4=0&model=576&model…> AMD K8 VIA K8T890 / VT8237R ASUS M2V-MX SE<http://www.asus.com/products.aspx?l1=3&l2=101&l3=324&l4=0&model=1807&modelm…> AMD K8 VIA K8M890 / VT8237S I believe I can use K8T890 from the ASUS A8V-E-SE but VT8237A has WIP status yet. I even have VT2837A specification( I've got from VIA under NDA) that helped me to patch my flasher to work with BIOS flash on it. Whom can I contact for details about testing this model? Thank you. With respect, John.

2 1

Re: [coreboot] [PATCH] Fix SB600 SATA and add support for port 2-4
by Carl-Daniel Hailfinger Dec. 29, 2008

Dec. 29, 2008

Hi Zheng, On 23.12.2008 03:26, Bao, Zheng wrote: > Reviewed-by: zheng bao <zheng.bao(a)amd.com> > > It is tested well on dbm690t and pistachio. > Thank you for the fast review! Our commit process is a bit difficult because it needs an Acked-by: statement. (The subversion repository will reject a commit without Acked-by.) Everybody who understands the code is allowed to ack a patch. You understand that piece of code very well, so could you please also add an Acked-by statement? Thanks! Regards, Carl-Daniel > -----Original Message----- > From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2006@gmx.net] > Sent: Tuesday, December 23, 2008 10:01 AM > To: Coreboot > Cc: Bao, Zheng > Subject: [PATCH] Fix SB600 SATA and add support for port 2-4 > > The SB600 RPR documentation does not mention what to do if SATA_BAR0+6 > is no longer 0xA0 or 0xB0. It simply assumes that will never happen. > My 500 GB Seagate Barracuda ST3500820AS triggers that corner case on the > first init after poweron. > The current code hangs forever with my drive. Fix this by rerunning the > init sequence after SATA_BAR0+6 is no longer 0xA0 or 0xB0. > > Add support for SATA port 2-4 (Primary Slave, Secondary Master, > Secondary Slave). > > Activate and improve debug messages for SPEW log level. > > Fix some comments. > > New log messages look like this: > PCI: 00:12.0 init > sata_bar0=3020 > sata_bar1=3060 > sata_bar2=3030 > sata_bar3=3070 > sata_bar4=3000 > sata_bar5=fc309000 > SATA port 0 status = 23 > 0x6=a0, 0x7=80 > drive detection not yet completed, waiting... > 0x6=a0, 0x7=80 > drive detection not yet completed, waiting... > [... 281 repetitions ...] > 0x6=0, 0x7=50 > drive no longer selected after 2830 ms, retrying init > drive detection done after 10 ms > Primary Master device is ready > SATA port 1 status = 23 > drive detection done after 10 ms > Primary Slave device is ready > SATA port 2 status = 0 > No Secondary Master SATA drive on Slot2 > SATA port 3 status = 0 > No Secondary Slave SATA drive on Slot3 > > Full log is attached. > > With this patch (and my other non-SATA fixups), my Asus M2A-VM boots > into Linux without problems. > > Signed-off-by: Carl-Daniel Hailfinger > <c-d.hailfinger.devel.2006(a)gmx.net> > > -- http://www.hailfinger.org/

2 12

r3845 - trunk/coreboot-v2/src/southbridge/amd/sb600
by svn＠coreboot.org Dec. 29, 2008

Dec. 29, 2008

Author: hailfinger Date: 2008-12-29 10:35:00 +0100 (Mon, 29 Dec 2008) New Revision: 3845 Modified: trunk/coreboot-v2/src/southbridge/amd/sb600/sb600_sata.c Log: The SB600 RPR documentation does not mention what to do if SATA_BAR0+6 is no longer 0xA0 or 0xB0. It simply assumes that will never happen. My 500 GB Seagate Barracuda ST3500820AS triggers that corner case on the first init after poweron. The current code hangs forever with my drive. Fix this by rerunning the init sequence after SATA_BAR0+6 is no longer 0xA0 or 0xB0. Add support for SATA port 2-4 (Primary Slave, Secondary Master, Secondary Slave). If only the 2nd SATA port is connected and the hardware acts strangely (contrary to documentation), it will print the error message below and continue anyway. The official AMD asm code behaves the same way. SATA port 0 status = 0 No Primary Master SATA drive on Slot0 SATA port 1 status = 23 0x6=7f, 0x7=7f drive no longer selected after 0 ms, retrying init [8 repetitions] 0x6=7f, 0x7=7f drive no longer selected after 0 ms, retrying init Primary Slave device is not ready after 10 tries Activate and improve debug messages for SPEW log level. Fix some comments. New log messages look like this: PCI: 00:12.0 init sata_bar0=3020 sata_bar1=3060 sata_bar2=3030 sata_bar3=3070 sata_bar4=3000 sata_bar5=fc309000 SATA port 0 status = 23 0x6=a0, 0x7=80 drive detection not yet completed, waiting... 0x6=a0, 0x7=80 drive detection not yet completed, waiting... [... 281 repetitions ...] 0x6=0, 0x7=50 drive no longer selected after 2820 ms, retrying init drive detection done after 0 ms Primary Master device is ready after 2 tries SATA port 1 status = 23 drive detection done after 0 ms Primary Slave device is ready after 1 tries SATA port 2 status = 0 No Secondary Master SATA drive on Slot2 SATA port 3 status = 0 No Secondary Slave SATA drive on Slot3 With this patch, my Asus M2A-VM boots into Linux without problems. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Acked-by: Zheng Bao <zheng.bao(a)amd.com> Modified: trunk/coreboot-v2/src/southbridge/amd/sb600/sb600_sata.c =================================================================== --- trunk/coreboot-v2/src/southbridge/amd/sb600/sb600_sata.c 2008-12-24 18:23:00 UTC (rev 3844) +++ trunk/coreboot-v2/src/southbridge/amd/sb600/sb600_sata.c 2008-12-29 09:35:00 UTC (rev 3845) @@ -2,6 +2,7 @@ * This file is part of the coreboot project. * * Copyright (C) 2008 Advanced Micro Devices, Inc. + * Copyright (C) 2008 Carl-Daniel Hailfinger * * 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 @@ -26,6 +27,33 @@ #include <arch/io.h> #include "sb600.h" +int sata_drive_detect(int portnum, u16 iobar) +{ + u8 byte, byte2; + int i = 0; + outb(0xA0 + 0x10 * (portnum % 2), iobar + 0x6); + while (byte = inb(iobar + 0x6), byte2 = inb(iobar + 0x7), + (byte != (0xA0 + 0x10 * (portnum % 2))) || + ((byte2 & 0x88) != 0)) { + printk_spew("0x6=%x, 0x7=%x\n", byte, byte2); + if (byte != (0xA0 + 0x10 * (portnum % 2))) { + /* This will happen at the first iteration of this loop + * if the first SATA port is unpopulated and the + * second SATA port is poulated. + */ + printk_debug("drive no longer selected after %i ms, " + "retrying init\n", i * 10); + return 1; + } else + printk_spew("drive detection not yet completed, " + "waiting...\n"); + mdelay(10); + i++; + } + printk_spew("drive detection done after %i ms\n", i * 10); + return 0; +} + static void sata_init(struct device *dev) { u8 byte; @@ -33,6 +61,7 @@ u32 dword; u8 *sata_bar5; u16 sata_bar0, sata_bar1, sata_bar2, sata_bar3, sata_bar4; + int i, j; struct southbridge_ati_sb600_config *conf; conf = dev->chip_info; @@ -62,12 +91,12 @@ sata_bar3 = pci_read_config16(dev, 0x1C) & ~0x7; sata_bar4 = pci_read_config16(dev, 0x20) & ~0x7; - /* printk_debug("sata_bar0=%x\n", sata_bar0); */ /* 3030 */ - /* printk_debug("sata_bar1=%x\n", sata_bar1); */ /* 3070 */ - /* printk_debug("sata_bar2=%x\n", sata_bar2); */ /* 3040 */ - /* printk_debug("sata_bar3=%x\n", sata_bar3); */ /* 3080 */ - /* printk_debug("sata_bar4=%x\n", sata_bar4); */ /* 3000 */ - /* printk_debug("sata_bar5=%x\n", sata_bar5); */ /* e0309000 */ + printk_spew("sata_bar0=%x\n", sata_bar0); /* 3030 */ + printk_spew("sata_bar1=%x\n", sata_bar1); /* 3070 */ + printk_spew("sata_bar2=%x\n", sata_bar2); /* 3040 */ + printk_spew("sata_bar3=%x\n", sata_bar3); /* 3080 */ + printk_spew("sata_bar4=%x\n", sata_bar4); /* 3000 */ + printk_spew("sata_bar5=%x\n", sata_bar5); /* e0309000 */ /* Program the 2C to 0x43801002 */ dword = 0x43801002; @@ -131,31 +160,36 @@ dword |= 1 << 25; pci_write_config32(dev, 0x40, dword); - /* Enable the I/O ,MM ,BusMaster access for SATA */ + /* Enable the I/O, MM, BusMaster access for SATA */ byte = pci_read_config8(dev, 0x4); byte |= 7 << 0; pci_write_config8(dev, 0x4, byte); - /* RPR6.6 SATA drive detection. Currently we detect Primary Master Device only */ - /* Use BAR5+0x1A8,BAR0+0x6 for Primary Slave */ - /* Use BAR5+0x228,BAR0+0x6 for Secondary Master */ - /* Use BAR5+0x2A8,BAR0+0x6 for Secondary Slave */ + /* RPR6.6 SATA drive detection. */ + /* Use BAR5+0x128,BAR0 for Primary Slave */ + /* Use BAR5+0x1A8,BAR0 for Primary Slave */ + /* Use BAR5+0x228,BAR2 for Secondary Master */ + /* Use BAR5+0x2A8,BAR2 for Secondary Slave */ - byte = readb(sata_bar5 + 0x128); - /* printk_debug("byte=%x\n", byte); */ - byte &= 0xF; - if (byte == 0x3) { - outb(0xA0, sata_bar0 + 0x6); - while ((inb(sata_bar0 + 0x6) != 0xA0) - || ((inb(sata_bar0 + 0x7) & 0x88) != 0)) { - mdelay(10); - /* printk_debug("0x6=%x,0x7=%x\n", inb(sata_bar0 + 0x6), - inb(sata_bar0 + 0x7)); */ - printk_debug("drive detection fail,trying...\n"); + for (i = 0; i < 4; i++) { + byte = readb(sata_bar5 + 0x128 + 0x80 * i); + printk_spew("SATA port %i status = %x\n", i, byte); + byte &= 0xF; + if (byte == 0x3) { + for (j = 0; j < 10; j++) { + if (!sata_drive_detect(i, ((i / 2) == 0) ? sata_bar0 : sata_bar2)) + break; + } + printk_debug("%s %s device is %sready after %i tries\n", + (i / 2) ? "Secondary" : "Primary", + (i % 2 ) ? "Slave" : "Master", + (j == 10) ? "not " : "", + (j == 10) ? j : j + 1); + } else { + printk_debug("No %s %s SATA drive on Slot%i\n", + (i / 2) ? "Secondary" : "Primary", + (i % 2 ) ? "Slave" : "Master", i); } - printk_debug("Primary master device is ready\n"); - } else { - printk_debug("No Primary master SATA drive on Slot0\n"); } /* Below is CIM InitSataLateFar */

1 0

[patch]:SB600 flashrom using virtual memory
by Bao, Zheng Dec. 29, 2008

Dec. 29, 2008

The accessing is changed to reading and writing byte to virtual memory. Reading chip can be improved. Writing doesn't seem to get noticeable improvement. The patch contains my previous patch which fixes hang and is not acked-by yet. Zheng diff -Nuar -x .svn -x flashrom -x '*.o' -x .dependencies flashrom-org/chipset_enable.c coreboot-v2-svn/util/flashrom/chipset_enable.c --- flashrom-org/chipset_enable.c 2008-12-22 14:12:08.000000000 +0800 +++ coreboot-v2-svn/util/flashrom/chipset_enable.c 2008-12-23 09:46:53.000000000 +0800 @@ -681,8 +681,16 @@ flashbus = BUS_TYPE_SB600_SPI; /* Enable SPI ROM in SB600 PM register. */ + /* If we enable SPI ROM here, we have to disable it after we leave. + * But how can we know which ROM we are going to handle? So we have + * to trade off. We only access LPC ROM if we boot via LPC ROM. And + * only SPI ROM if we boot via SPI ROM. If you want to do it crossly, + * you have to use the code below. + */ + /* OUTB(0x8f, 0xcd6); OUTB(0x0e, 0xcd7); + */ return 0; } diff -Nuar -x .svn -x flashrom -x '*.o' -x .dependencies flashrom-org/sb600spi.c coreboot-v2-svn/util/flashrom/sb600spi.c --- flashrom-org/sb600spi.c 2008-11-29 15:07:14.000000000 +0800 +++ coreboot-v2-svn/util/flashrom/sb600spi.c 2008-12-29 16:17:09.000000000 +0800 @@ -44,13 +44,11 @@ int sb600_spi_read(struct flashchip *flash, uint8_t *buf) { - int rc = 0, i; + int rc = 0; int total_size = flash->total_size * 1024; - int page_size = 8; - for (i = 0; i < total_size / page_size; i++) - spi_nbyte_read(i * page_size, (void *)(buf + i * page_size), - page_size); + memcpy(buf, (const char *)flash->virtual_memory, total_size); + return rc; } @@ -68,17 +66,20 @@ { int rc = 0, i; int total_size = flash->total_size * 1024; + uint8_t *bios; /* Erase first */ printf("Erasing flash before programming... "); flash->erase(flash); printf("done.\n"); + spi_disable_blockprotect(); printf("Programming flash"); - for (i = 0; i < total_size; i++, buf++) { - spi_disable_blockprotect(); + for (i = 0, bios = (uint8_t *)flash->virtual_memory; + i < total_size; + i++, buf++, bios++) { spi_write_enable(); - spi_byte_program(i, *buf); + *bios = *buf; /* wait program complete. */ if (i % 0x8000 == 0) printf("."); @@ -97,12 +98,18 @@ printf("reset\n"); } -void execute_command(void) +int execute_command(void) { + int timeout = 1000; + sb600_spibar[2] |= 1; - while (sb600_spibar[2] & 1) - ; + while ((sb600_spibar[2] & 1) && timeout) + { + myusec_delay(1); + timeout --; + } + return timeout ? 1 : 0; } int sb600_spi_command(unsigned int writecnt, unsigned int readcnt, @@ -150,7 +157,8 @@ */ reset_internal_fifo_pointer(); - execute_command(); + if (!execute_command()) + return 1; /* * After the command executed, we should find out the index of the

1 1