[coreboot] [commit] r5486 - trunk/src/northbridge/amd/amdmct
Author: zbao Date: Sat Apr 24 09:56:32 2010 New Revision: 5486 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5486 Log: Trivial. Fix a space to tab. Signed-off-by: Zheng Bao zheng@amd.com Acked-by: Zheng Bao zheng@amd.com Modified: trunk/src/northbridge/amd/amdmct/amddefs.h Modified: trunk/src/northbridge/amd/amdmct/amddefs.h == --- trunk/src/northbridge/amd/amdmct/amddefs.h Fri Apr 23 22:58:13 2010 (r5485) +++ trunk/src/northbridge/amd/amdmct/amddefs.h Sat Apr 24 09:56:32 2010 (r5486) @@ -64,8 +64,8 @@ #defineAMD_DR_ALL (AMD_DR_Bx) #defineAMD_FAM10_ALL (AMD_DR_ALL | AMD_RB_C2 | AMD_HY_D0 | AMD_DA_C3 | AMD_DA_C2) #defineAMD_FAM10_GT_B0 (AMD_FAM10_ALL ~(AMD_DR_B0)) -#define AMD_DR_Cx (AMD_RB_C2 | AMD_DA_C2 | AMD_RB_C3 | AMD_DA_C3) -#define AMD_DR_Dx (AMD_HY_D0) +#defineAMD_DR_Cx (AMD_RB_C2 | AMD_DA_C2 | AMD_RB_C3 | AMD_DA_C3) +#defineAMD_DR_Dx (AMD_HY_D0) /* -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] EP80579 reference platform
On 4/24/10 4:52 AM, Dustin Harrison wrote: Thanks for the idea Stefan. I have yet to get SerialICE up, but I did manage to get the Truxton BIOS into QEMU. Interesting that QEMU exceptions at the same (at least relative to C code) spot as my board hangs. As a comparison (since so much of the i3100 code is shared) I was able to get the MtTarvon board up in QEMU with no crash. Here is the output of QEMU with Truxton: coreboot-4.0-r5422:5430M Fri Apr 23 19:46:42 PDT 2010 starting... SMBus controller enabled dimm qemu: fatal: triple fault Unfortunately that does not mean much.. Qemu emulates an i440BX chipset (more or rather less) and trying to execute the BIOS of any other machine on it may or may not crash, but will not give any useful results either way. Stefan -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: i...@coresystems.de • http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg • HRB 7656 Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Enable maximum decoded range for VT8237*
On Fri, Apr 23, 2010 at 10:59:51PM +0200, Rudolf Marek wrote: Thanks, it is in as Committed revision 5485. While we are at the tinybootblock. Kevin do you plan to convert the epia-cn too? What about to implement there the PSON gating so SMB hack is not needed anymore? I didn't need to do anything for tinybootblock beyond adding select TINY_BOOTBLOCK to epia-cn/Kconfig. The PSON gating was: --- src/southbridge/via/vt8237r/vt8237r_early_smbus.c (revision 5486) +++ src/southbridge/via/vt8237r/vt8237r_early_smbus.c (working copy) @@ -148,6 +148,9 @@ die(Power management controller not found\n); } +while (!(pci_read_config8(dev, 0x82) (16))) +; + /* * 7 = SMBus Clock from RTC 32.768KHz * 5 = Internal PLL reset from susp But it should probably have a timeout added. I've been meaning to clean these things up, but I haven't had the chance. -Kevin -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] drop all copies of vgabios.c
On Fri, Apr 23, 2010 at 11:01:34PM +0200, Stefan Reinauer wrote: This patch cleans up the option rom code in coreboot significantly by dropping all extra copies of vgabios.c and instead changing the code to use oprom/x86.c with custom per-board int15 handlers. Corey, I can't test this on cn400/cn700 ... Can you? The code should go in as is, but it might require some extra fixing, as (like with vgabios.c before) the int15 handlers are all copies of the age-old epia-m code. (except vx800) Nice! If I don't enable CONFIG_VGA_ROM_RUN I get: build/coreboot_ram.o: In function `vga_init': vga.c:(.text+0x178d): undefined reference to `mainboard_interrupt_handlers' If I do enable that option it will compile. I tested it on a flash image that did not contain a valid vga rom in cbfs - it did boot, but took much longer: 00.497: Stage: loading fallback/coreboot_ram @ 0x10 (180224 bytes), entry @ 0x10 01.619: coreboot-4.0-r5486M Sat Apr 24 11:13:13 EDT 2010 booting... vs: 00.501: Stage: loading fallback/coreboot_ram @ 0x4000 (163840 bytes), entry @ 0x4000 00.547: coreboot-4.0-r5486M Sat Apr 24 10:45:34 EDT 2010 rebooting... I'm not sure if the delay is because RAMBASE moved or because of something related to the vga code. It's been a while since I've used coreboot's vga init code - what's the best way to test that - filo? -Kevin -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] drop all copies of vgabios.c
On 4/24/10 5:28 PM, Kevin O'Connor wrote: On Fri, Apr 23, 2010 at 11:01:34PM +0200, Stefan Reinauer wrote: This patch cleans up the option rom code in coreboot significantly by dropping all extra copies of vgabios.c and instead changing the code to use oprom/x86.c with custom per-board int15 handlers. Corey, I can't test this on cn400/cn700 ... Can you? The code should go in as is, but it might require some extra fixing, as (like with vgabios.c before) the int15 handlers are all copies of the age-old epia-m code. (except vx800) Nice! If I don't enable CONFIG_VGA_ROM_RUN I get: build/coreboot_ram.o: In function `vga_init': vga.c:(.text+0x178d): undefined reference to `mainboard_interrupt_handlers' If I do enable that option it will compile. I tested it on a flash image that did not contain a valid vga rom in cbfs - it did boot, but took much longer: 00.497: Stage: loading fallback/coreboot_ram @ 0x10 (180224 bytes), entry @ 0x10 01.619: coreboot-4.0-r5486M Sat Apr 24 11:13:13 EDT 2010 booting... vs: 00.501: Stage: loading fallback/coreboot_ram @ 0x4000 (163840 bytes), entry @ 0x4000 00.547: coreboot-4.0-r5486M Sat Apr 24 10:45:34 EDT 2010 rebooting... I'm not sure if the delay is because RAMBASE moved or because of something related to the vga code. Oh, can you just add the rambase at 0x4000 again and try that? This sounds like a caching issue and it should be investigated (we have such issues on AMD platforms, too) And tripling boot time is definitely a regression we need to fight as it comes :-) It's been a while since I've used coreboot's vga init code - what's the best way to test that - filo? I think so, yes. -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: i...@coresystems.de • http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg • HRB 7656 Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Dualbios on GA-MA770-UD3
Thank you for your work on Dual BIOS. What I don't understand is how is this supposed to work. From what you say and what I asked sales cotact staff at gigabyte (no very useful insights) , there are two bios roms. One has the ability to check the other and run it only if it detects it's ok. If it doesn't it flashes itself to it. So if you use one of the BIOS for coreboot it will either be rewriten by the original BIOS or it will boot, depending on which ROM boots first and which ROM you put coreboot in. If you flash the ROM that boots first you can try coreboot, but in case it doesn't work how are you going to jump to the original BIOS ? If you flash the other ROM then apparently the original BIOS will boot and do what it pleases, possibly overwrite coreboot, or assuming you can trick it to believe coreboot is a correct BIOS then maybe jump to it after some initialisation, but will coreboot then have a chance to work from the same state it would in case it had booted first ? Tricking the original BIOS to believe coreboot is a correct image may be hard. In the worst case you may have to break a digital signature without the private key. This is not directly related, but gives an idea of how hard it could be http://invisiblethingslab.com/resources/bh09usa/Attacking Intel BIOS.pdf But assuming you can, will using coreboot after other firmware has set up things far enough to be able to test the ROM where coreboot is in, will that be a sufficient test ? I'm not saying it won't, I have no clue. Anyway, being able to flash both chips is good at the very least in order to have more space for payloads or so. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Dualbios on GA-MA770-UD3
Am 24.04.2010 19:43, schrieb xdrudis: What I don't understand is how is this supposed to work. From what you say and what I asked sales cotact staff at gigabyte (no very useful insights) , there are two bios roms. One has the ability to check the other and run it only if it detects it's ok. If it doesn't it flashes itself to it. So if you use one of the BIOS for coreboot it will either be rewriten by the original BIOS or it will boot, depending on which ROM boots first and which ROM you put coreboot in. If you flash the ROM that boots first you can try coreboot, but in case it doesn't work how are you going to jump to the original BIOS ? They might just use a watchdog: - BIOS 1 sets a flag - BIOS 1 configures the watchdog to trigger when it's not touched within 2 seconds (or whatever). watchdog would reboot the system then - BIOS 1 jumps in BIOS 2 - BIOS 2 does whatever it needs to do to consider itself safe - Meanwhile, BIOS 2 touches the watchdog every so often - BIOS 2 deactivates the watchdog In this scenario, coreboot would have to know how to tell the watchdog to reset its countdown, and how to disable the watchdog, to safely use the Dual BIOS feature. If you flash the other ROM then apparently the original BIOS will boot and do what it pleases, possibly overwrite coreboot, or assuming you can trick it to believe coreboot is a correct BIOS then maybe jump to it after some initialisation, but will coreboot then have a chance to work from the same state it would in case it had booted first ? Tricking the original BIOS to believe coreboot is a correct image may be hard. In the worst case you may have to break a digital signature without the private key. This is not directly related, but gives an idea of how hard it could be The feature supposedly shouldn't just guard against non-Gigabyte images, but against issues with their own images, too - and those would have the right signature, and thus would pass any such test. I'd be really amazed if they'd add another chip (that actually costs money) and then only implement an incomplete protection scheme with it. Regards, Patrick Georgi -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Dualbios on GA-MA770-UD3
Patrick Georgi wrote: I'd be really amazed if they'd add another chip (that actually costs money) and then only implement an incomplete protection scheme with it. Yes it's surprising, but Gigabyte does add another flash device. They also appear to rely on security by obscurity. I'm trying to find out if some of the SuperIO and EC registers are under some super secret NDA. Since some of the registers used are not even in the NDA versions of the docs. -Bari -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Dualbios on GA-MA770-UD3
On 4/24/10 8:26 PM, Patrick Georgi wrote: They might just use a watchdog: - BIOS 1 sets a flag - BIOS 1 configures the watchdog to trigger when it's not touched within 2 seconds (or whatever). watchdog would reboot the system then - BIOS 1 jumps in BIOS 2 - BIOS 2 does whatever it needs to do to consider itself safe - Meanwhile, BIOS 2 touches the watchdog every so often - BIOS 2 deactivates the watchdog In this scenario, coreboot would have to know how to tell the watchdog to reset its countdown, and how to disable the watchdog, to safely use the Dual BIOS feature. And the way to find out would be SerialICE: http://www.serialice.com/ Best regards, Stefan -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: i...@coresystems.de • http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg • HRB 7656 Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] drop all copies of vgabios.c
On Sat, Apr 24, 2010 at 07:13:11PM +0200, Stefan Reinauer wrote: On 4/24/10 5:28 PM, Kevin O'Connor wrote: If I don't enable CONFIG_VGA_ROM_RUN I get: build/coreboot_ram.o: In function `vga_init': vga.c:(.text+0x178d): undefined reference to `mainboard_interrupt_handlers' [...] I'm not sure if the delay is because RAMBASE moved or because of something related to the vga code. Oh, can you just add the rambase at 0x4000 again and try that? This sounds like a caching issue and it should be investigated (we have such issues on AMD platforms, too) Reverting the RAMBASE part of the patch fixes the timing. It's been a while since I've used coreboot's vga init code - what's the best way to test that - filo? I think so, yes. I ran a test with filo and a coreboot executed vga optionrom - it works fine on my epia-cn. (As an aside, filo takes several seconds longer than seabios to init.) So, the patch works for me with the exception of RAMBASE and CONFIG_VGA_ROM_RUN. -Kevin -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r5487 - trunk/util/cbfstool
Author: stepan
Date: Sat Apr 24 23:24:06 2010
New Revision: 5487
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5487
Log:
print the known cbfs types in cbfstool usage
Signed-off-by: Stefan Reinauer ste...@coresystems.de
Acked-by: Stefan Reinauer ste...@coresystems.de
Modified:
trunk/util/cbfstool/cbfstool.c
trunk/util/cbfstool/common.c
trunk/util/cbfstool/common.h
Modified: trunk/util/cbfstool/cbfstool.c
==
--- trunk/util/cbfstool/cbfstool.c Sat Apr 24 09:56:32 2010(r5486)
+++ trunk/util/cbfstool/cbfstool.c Sat Apr 24 23:24:06 2010(r5487)
@@ -254,17 +254,20 @@
void usage(void)
{
printf
- (cbfstool: Management utility for CBFS formatted ROM images\n
-USAGE:\n cbfstool [-h]\n
-cbfstool FILE COMMAND [PARAMETERS]...\n\n OPTIONs:\n
- -h Display this help message\n\n
+ (cbfstool: Management utility for CBFS formatted ROM images\n\n
+USAGE:\n cbfstool [-h]\n
+ cbfstool FILE COMMAND [PARAMETERS]...\n\n OPTIONs:\n
+ -h Display this help message\n\n
COMMANDs:\n
-add FILE NAME TYPE [base address]Add a component\n
-add-payload FILE NAME [COMP] [base] Add a payload to the ROM\n
-add-stage FILE NAME [COMP] [base]Add a stage to the ROM\n
-create SIZE BOOTBLOCK [ALIGN]Create a ROM file\n
-locate FILE NAME ALIGN Find a place for a file of
that size\n
-printShow the contents of the
ROM\n);
+ add FILE NAME TYPE [base address]Add a component\n
+ add-payload FILE NAME [COMP] [base] Add a payload to the ROM\n
+ add-stage FILE NAME [COMP] [base]Add a stage to the ROM\n
+ create SIZE BOOTBLOCK [ALIGN]Create a ROM file\n
+ locate FILE NAME ALIGN Find a place for a file of
that size\n
+ printShow the contents of the
ROM\n\n
+TYPEs:\n
+);
+ print_supported_filetypes();
}
int main(int argc, char **argv)
Modified: trunk/util/cbfstool/common.c
==
--- trunk/util/cbfstool/common.cSat Apr 24 09:56:32 2010(r5486)
+++ trunk/util/cbfstool/common.cSat Apr 24 23:24:06 2010(r5487)
@@ -137,6 +137,17 @@
{CBFS_COMPONENT_NULL, null}
};
+void print_supported_filetypes(void)
+{
+ int i, number = ARRAY_SIZE(filetypes);
+
+ for (i=0; inumber; i++) {
+ printf( %s%c, filetypes[i].name, (i==(number-1))?'\n':',');
+ if ((i%8) == 7)
+ printf(\n);
+ }
+}
+
const char *strfiletype(uint32_t number)
{
int i;
Modified: trunk/util/cbfstool/common.h
==
--- trunk/util/cbfstool/common.hSat Apr 24 09:56:32 2010(r5486)
+++ trunk/util/cbfstool/common.hSat Apr 24 23:24:06 2010(r5487)
@@ -72,4 +72,6 @@
uint32_t cbfs_find_location(const char *romfile, uint32_t filesize,
const char *filename, uint32_t align);
+void print_supported_filetypes(void);
+
#define ARRAY_SIZE(a) (sizeof(a) / sizeof((a)[0]))
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r5488 - in trunk/src: devices/oprom mainboard/artecgroup/dbe61/realmode northbridge/via/cn400 northbridge/via/cn700 northbridge/via/cx700 northbridge/via/vx800
Author: stepan
Date: Sun Apr 25 01:15:23 2010
New Revision: 5488
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5488
Log:
drop all duplicate copies of vgabios.c in favor
of devices/oprom/x86.c.
We have some tests on hardware. Moving RAMBASE to
1MB needs to wait a bit until C7 cache_as_ram.inc
has been adapted to cache that area or things will
become incredibly slow (1.5s boot time instead of 0.5)
Signed-off-by: Stefan Reinauer ste...@coresystems.de
Acked-by: Stefan Reinauer ste...@coresystems.de
Deleted:
trunk/src/mainboard/artecgroup/dbe61/realmode/
trunk/src/northbridge/via/cn400/vgabios.c
trunk/src/northbridge/via/cn400/vgachip.h
trunk/src/northbridge/via/cn700/vgabios.c
trunk/src/northbridge/via/cn700/vgachip.h
trunk/src/northbridge/via/cx700/vgabios.c
trunk/src/northbridge/via/vx800/vgabios.c
trunk/src/northbridge/via/vx800/vgachip.h
Modified:
trunk/src/devices/oprom/x86.c
trunk/src/northbridge/via/cn400/Kconfig
trunk/src/northbridge/via/cn400/Makefile.inc
trunk/src/northbridge/via/cn400/vga.c
trunk/src/northbridge/via/cn700/Kconfig
trunk/src/northbridge/via/cn700/Makefile.inc
trunk/src/northbridge/via/cn700/vga.c
trunk/src/northbridge/via/cx700/Kconfig
trunk/src/northbridge/via/cx700/Makefile.inc
trunk/src/northbridge/via/cx700/cx700_vga.c
trunk/src/northbridge/via/vx800/Kconfig
trunk/src/northbridge/via/vx800/Makefile.inc
trunk/src/northbridge/via/vx800/vga.c
Modified: trunk/src/devices/oprom/x86.c
==
--- trunk/src/devices/oprom/x86.c Sat Apr 24 23:24:06 2010(r5487)
+++ trunk/src/devices/oprom/x86.c Sun Apr 25 01:15:23 2010(r5488)
@@ -134,11 +134,13 @@
/* Many option ROMs use the hard coded interrupt entry points in the
* system bios. So install them at the known locations.
-* Only need int10 so far.
*/
/* int42 is the relocated int10 */
- write_idt_stub((void *)0xff065, 0x42);
+ write_idt_stub((void *)0xff065, 0x42);
+
+ /* VIA's VBIOS calls f000:f859 instead of int15 */
+ write_idt_stub((void *)0xff859, 0x15);
}
void run_bios(struct device *dev, unsigned long addr)
Modified: trunk/src/northbridge/via/cn400/Kconfig
==
--- trunk/src/northbridge/via/cn400/Kconfig Sat Apr 24 23:24:06 2010
(r5487)
+++ trunk/src/northbridge/via/cn400/Kconfig Sun Apr 25 01:15:23 2010
(r5488)
@@ -6,17 +6,6 @@
default 0
depends on NORTHBRIDGE_VIA_CN400
-# this is done by the northbridge's vgabios.c already
-config VGA_ROM_RUN
- bool
- default n
- depends on NORTHBRIDGE_VIA_CN400
-
-config PCI_ROM_RUN
- bool
- default n
- depends on NORTHBRIDGE_VIA_CN400
-
# TODO: Values are from the CX700 datasheet, not sure if this matches CN400.
# TODO: What should be the per-chipset default value here?
choice
Modified: trunk/src/northbridge/via/cn400/Makefile.inc
==
--- trunk/src/northbridge/via/cn400/Makefile.incSat Apr 24 23:24:06
2010(r5487)
+++ trunk/src/northbridge/via/cn400/Makefile.incSun Apr 25 01:15:23
2010(r5488)
@@ -18,8 +18,6 @@
## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
##
-obj-y += vgabios.o
-
driver-y += northbridge.o
driver-y += agp.o
driver-y += vga.o
Modified: trunk/src/northbridge/via/cn400/vga.c
==
--- trunk/src/northbridge/via/cn400/vga.c Sat Apr 24 23:24:06 2010
(r5487)
+++ trunk/src/northbridge/via/cn400/vga.c Sun Apr 25 01:15:23 2010
(r5488)
@@ -33,24 +33,63 @@
#include string.h
#include bitops.h
#include cpu/cpu.h
+#include arch/interrupt.h
#include chip.h
#include northbridge.h
#include cn400.h
-#include vgachip.h
-void write_protect_vgabios(void)
+static int via_cn400_int15_handler(struct eregs *regs)
{
- /* Don't bother for now. */
+ int res=-1;
+ printk(BIOS_DEBUG, via_cn400_int15_handler\n);
+ switch(regs-eax 0x) {
+ case 0x5f19:
+ break;
+ case 0x5f18:
+ regs-eax=0x5f;
+ regs-ebx=0x545; // MCLK = 133, 32M frame buffer, 256 M main
memory
+ regs-ecx=0x060;
+ res=0;
+ break;
+ case 0x5f00:
+ regs-eax = 0x8600;
+ break;
+ case 0x5f01:
+ regs-eax = 0x5f;
+ regs-ecx = (regs-ecx 0xff00 ) | 2; // panel type = 2 =
1024 * 768
+ res = 0;
+ break;
+ case 0x5f02:
+ regs-eax=0x5f;
+ regs-ebx= (regs-ebx 0x) | 2;
+ regs-ecx= (regs-ecx 0x) | 0x401; //
[coreboot] [commit] r5489 - trunk/src/cpu/intel/model_6xx
Author: stepan
Date: Sun Apr 25 01:16:23 2010
New Revision: 5489
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5489
Log:
these cpus are explicitly supported by model_6bx
Signed-off-by: Stefan Reinauer ste...@coresystems.de
Acked-by: Stefan Reinauer ste...@coresystems.de
Modified:
trunk/src/cpu/intel/model_6xx/model_6xx_init.c
Modified: trunk/src/cpu/intel/model_6xx/model_6xx_init.c
==
--- trunk/src/cpu/intel/model_6xx/model_6xx_init.c Sun Apr 25 01:15:23
2010(r5488)
+++ trunk/src/cpu/intel/model_6xx/model_6xx_init.c Sun Apr 25 01:16:23
2010(r5489)
@@ -57,9 +57,6 @@
{ X86_VENDOR_INTEL, 0x06A0 },
{ X86_VENDOR_INTEL, 0x06A1 },
{ X86_VENDOR_INTEL, 0x06A4 },
- { X86_VENDOR_INTEL, 0x06B0 }, /* Mobile Celeron FCBGA */
- { X86_VENDOR_INTEL, 0x06B1 }, /* Celeron (Tualatin) */
- { X86_VENDOR_INTEL, 0x06B4 },
{ 0, 0 },
};
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Dualbios on GA-MA770-UD3
Vadim Girlin wrote: Please, post any info you have that can help me. This has been discussed a few times before. Gigabyte holds a patent for this technology. See http://www.mail-archive.com/linuxb...@linuxbios.org/msg05929.html for the link. The patent describes how the DualBIOS scheme works. There is a timing circuit and a special handshake. The board starts up with one chip selected, and if the handshake is performed by the BIOS before timeout then the system starts normally. In case of a timeout, the timing circuit resets the board, activates the second flash chip, and then releases reset to attempt startup with the new flash chip. Details of the handshake are not included in the patent, and I expect them to vary by board. GA-M57SLI-S4 has pads for the timing circuit, but parts are not populated. Me and Reinder investigated how the M57SLI board works, details can be inferred from http://stuge.se/m57sli/ On the M57SLI the timing circuit was drawn quite far away from the flash chips - with components totally unrelated to the superio - it was located underneath the battery holder. I think it will be difficult to learn the handshake details from looking at the board, and I do believe SerialICE can be helpful here. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
