coreboot September 2010

coreboot@coreboot.org

58 participants
324 discussions

[commit] r5820 - trunk/src/northbridge/intel/i440bx
by repository service 20 Sep '10

20 Sep '10

Author: uwe Date: Tue Sep 21 01:41:37 2010 New Revision: 5820 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5820 Log: A number of cleanups for 440BX raminit code. Resolves a number of TODOs items within, and clarified a number of other TODOs. Change register_values[] from long to u8 (byte). For what we are doing this is sufficient and makes it only 1/4 the size. Remove a hard-coding of SDRAMC register that is redundant and now incorrect, now that SDRAMC is conditioned on SDRAMPWR_4DIMM Kconfig and set through register_values[]. This fixes all boards with 3 DIMM slots (e.g. ASUS P2B, A-Trend ATC-6220). RPS registers are now set in runtime code; remove it from register_values[] table. Bring DUMPNORTH() back. The code it refers to is still there. Move #define of NB up so the DUMPNORTH() macro can use it. Signed-off-by: Keith Hui <buurin(a)gmail.com> Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de> Modified: trunk/src/northbridge/intel/i440bx/raminit.c Modified: trunk/src/northbridge/intel/i440bx/raminit.c ============================================================================== --- trunk/src/northbridge/intel/i440bx/raminit.c Sun Sep 19 23:12:05 2010 (r5819) +++ trunk/src/northbridge/intel/i440bx/raminit.c Tue Sep 21 01:41:37 2010 (r5820) @@ -29,15 +29,15 @@ Macros and definitions. -----------------------------------------------------------------------------*/ +#define NB PCI_DEV(0, 0, 0) + /* Debugging macros. */ #if CONFIG_DEBUG_RAM_SETUP #define PRINT_DEBUG(x) print_debug(x) #define PRINT_DEBUG_HEX8(x) print_debug_hex8(x) #define PRINT_DEBUG_HEX16(x) print_debug_hex16(x) #define PRINT_DEBUG_HEX32(x) print_debug_hex32(x) -// no dump_pci_device in src/northbridge/intel/i440bx -// #define DUMPNORTH() dump_pci_device(PCI_DEV(0, 0, 0)) -#define DUMPNORTH() +#define DUMPNORTH() dump_pci_device(NB) #else #define PRINT_DEBUG(x) #define PRINT_DEBUG_HEX8(x) @@ -46,8 +46,6 @@ #define DUMPNORTH() #endif -#define NB PCI_DEV(0, 0, 0) - /* SDRAMC[7:5] - SDRAM Mode Select (SMS). */ #define RAM_COMMAND_NORMAL 0x0 #define RAM_COMMAND_NOP 0x1 @@ -70,7 +68,7 @@ }; /* Table format: register, bitmask, value. */ -static const long register_values[] = { +static const u8 register_values[] = { /* NBXCFG - NBX Configuration Register * 0x50 - 0x53 * @@ -131,9 +129,8 @@ * 0 = A7# is sampled asserted (i.e., 0) * [01:00] Reserved */ - // TODO NBXCFG + 0, 0x00, 0x0c, - // NBXCFG + 1, 0x00, 0xa0, + // TODO: Bit 15 should be 0 for multiprocessor boards NBXCFG + 1, 0x00, 0x80, NBXCFG + 2, 0x00, 0x00, NBXCFG + 3, 0x00, 0xff, @@ -143,7 +140,12 @@ * * [7:6] Reserved * [5:5] Module Mode Configuration (MMCONFIG) - * TODO + * The combination of SDRAMPWR and this bit (which is set by an + * external strapping option) determine how CKE works. + * SDRAMPWR MMCONFIG + * 0 0 = 3 DIMM, CKE0[5:0] driven + * X 1 = 3 DIMM, CKE0 only + * 1 0 = 4 DIMM, GCKE only * [4:3] DRAM Type (DT) * 00 = EDO * 01 = SDRAM @@ -252,12 +254,25 @@ * Sets the row page size for SDRAM. For EDO memory, the page * size is fixed at 2 KB. * - * [15:0] Page Size (PS) - * TODO - */ - // TODO - RPS + 0, 0x00, 0x00, - RPS + 1, 0x00, 0x00, + * Bits[1:0] Page Size + * 00 2 KB + * 01 4 KB + * 10 8 KB + * 11 Reserved + * + * RPS bits Corresponding DRB register + * [01:00] DRB[0], row 0 + * [03:02] DRB[1], row 1 + * [05:04] DRB[2], row 2 + * [07:06] DRB[3], row 3 + * [09:08] DRB[4], row 4 + * [11:10] DRB[5], row 5 + * [13:12] DRB[6], row 6 + * [15:14] DRB[7], row 7 + */ + /* Power on defaults to 2KB. Will be set later. */ + // RPS + 0, 0x00, 0x00, + // RPS + 1, 0x00, 0x00, /* SDRAMC - SDRAM Control Register * 0x76 - 0x77 @@ -266,8 +281,7 @@ * [09:08] Idle/Pipeline DRAM Leadoff Timing (IPDLT) * 00 = Illegal * 01 = Add a clock delay to the lead-off clock count - * 10 = Illegal - * 11 = Illegal + * 1x = Illegal * [07:05] SDRAM Mode Select (SMS) * 000 = Normal SDRAM Operation (default) * 001 = NOP Command Enable @@ -296,7 +310,7 @@ #if CONFIG_SDRAMPWR_4DIMM SDRAMC + 0, 0x00, 0x10, /* The board has 4 DIMM slots. */ #else - SDRAMC + 0, 0x00, 0x00, /* The board has 3 DIMM slots.*/ + SDRAMC + 0, 0x00, 0x00, /* The board has 3 DIMM slots. */ #endif SDRAMC + 1, 0x00, 0x00, @@ -304,7 +318,9 @@ * 0x78 - 0x79 * * [15:08] Banks per Row (BPR) - * TODO + * Each bit in this field corresponds to one row of the memory + * array. Bit 15 corresponds to row 7 while bit 8 corresponds + * to row 0. Bits for empty rows are "don't care". * 0 = 2 banks * 1 = 4 banks * [07:05] Reserved @@ -320,7 +336,6 @@ * 0111 = 32 clocks * 1xxx = Infinite (pages are not closed for idle condition) */ - // TODO PGPOL + 0, 0x00, 0x00, PGPOL + 1, 0x00, 0xff, @@ -354,7 +369,6 @@ /* Enable normal refresh and the gated clock. */ // TODO: Only do this later? // PMCR, 0x00, 0x14, - // PMCR, 0x00, 0x10, PMCR, 0x00, 0x00, /* Enable SCRR.SRRAEN and let BX choose the SRR. */ @@ -458,11 +472,11 @@ } } - /* Algorithm bitmap for programming MBSC[39:0] and MBFS[23:0] + /* Algorithm bitmap for programming MBSC[39:0] and MBFS[23:0]. * - * 440BX datasheet says buffer frequency is independent from bus frequency - * and mismatch both ways are possible. This is how it is programmed - * in ASUS P2B-LS. + * The 440BX datasheet says buffer frequency is independent from bus + * frequency and mismatch both ways are possible. This is how it is + * programmed in the ASUS P2B-LS mainboard. * * There are four main conditions to check when programming DRAM buffer * frequency and strength: @@ -523,7 +537,8 @@ * +--------------------------------------- MAA[13:0],WEA#,SRASA#,SCASA# * MBSC[47:40] and MBFS[23] are reserved. * - * This algorithm is checked against P2B-LS factory BIOS. It has 4 DIMM slots. + * This algorithm is checked against the ASUS P2B-LS (which has + * 4 DIMM slots) factory BIOS. * Therefore it assumes a board with 4 slots, and will need testing * on boards with 3 DIMM slots. */ @@ -946,17 +961,14 @@ /* Setup DRAM row boundary registers and other attributes. */ set_dram_row_attributes(); - /* TODO: Set SDRAMC. */ - pci_write_config16(NB, SDRAMC, 0x0010); /* SDRAMPWR=1: 4 DIMM config */ - - /* TODO */ + /* Setup DRAM buffer strength. */ set_dram_buffer_strength(); /* TODO: Set PMCR? */ // pci_write_config8(NB, PMCR, 0x14); pci_write_config8(NB, PMCR, 0x10); - /* TODO? */ + /* TODO: This is for EDO memory only. */ pci_write_config8(NB, DRAMT, 0x03); }

1 0

[patch]: AMD DDR3 fix the register name
by Bao, Zheng 20 Sep '10

20 Sep '10

Fix the typo. Field DisAutoRefresh is in DramTimngHi. Signed-off-by: Zheng Bao <zheng.bao(a)amd.com> Index: src/northbridge/amd/amdmct/mct_ddr3/mct_d.c =================================================================== --- src/northbridge/amd/amdmct/mct_ddr3/mct_d.c (revision 5818) +++ src/northbridge/amd/amdmct/mct_ddr3/mct_d.c (working copy) @@ -1220,7 +1220,7 @@ Set_NB32(dev, 0x88 + reg_off, DramTimingLo); /*DCT Timing Low*/ if (pDCTstat->Speed > 4) { - DramTimingLo |= 1 << DisAutoRefresh; + DramTimingHi |= 1 << DisAutoRefresh; } DramTimingHi |= 0x000018FF; Set_NB32(dev, 0x8c + reg_off, DramTimingHi); /*DCT Timing Hi*/

2 1

ohava laptop coreboot
by Sahil Sinha 20 Sep '10

20 Sep '10

I spoke with someone in the IRC to send this here, I offered free hardware for a port of coreboot to this machine. Sahil Sinha Ohava Computers (703) 887-1032 www.ohava.com

3 3

Re: [coreboot] RE : [PATCH] Re: RE : RE : First coreboot build for Tyan s2895 K8WE mobo with seabios payload, computer starts, but graphical ubuntu 64bits is crashing
by Peter Stuge 20 Sep '10

20 Sep '10

STEMMELIN, FREDERIC (FREDERIC)** CTR ** wrote: > Thank you very much for your help, in the mean time i have very > goods news, yes my Tyan s2895 is BOOTING now :) Nice, but.. > kerneloops on screen after kernel was trying to set a IRQ for the > intel network card, with error -39 (or -38 i dont remember > exactly). > > Now after remowing my Intel PRO1000MT server network card from > PCI-X slot 6, i can boot without any problems :) ..the PCI-X should also work. I think it may be good to investigate why it gets such a high bus number. > Now here are my results with the patched Memtest86+ version 4.1. > Check the attached files. > > As you can see it is far way better, even if it is not working, at > least i can see that the memory is recognized correctly, wich is > pretty good. > Memtest86+ is still crashing on test starting (after 3%), but > really not important so far, as long as my computer does not crash > in normal operation mode. I think it is important. memtest should not crash, if it does, then I don't think everything is right with the memory setup, and that will lead to your computer crashing, it will just take some time; until you have started filling the RAM with stuff that you don't want to lose. > Another question, what may the consequences be not supporting e820 > in bios, *Please* remember that coreboot is not a BIOS. e820 memory maps are a BIOS-specific interface, and coreboot does not provide this. coreboot still provides a memory map, within the coreboot tables. SeaBIOS provides BIOS interfaces, among other things it implements "e820" memory maps, based on the coreboot tables memory map. > for other OS like windows for example ? Does another OS use this > feature e820 ? Nearly every OS on the PC so far assumes that the 30-year old BIOS interface will be present. Because systems do not understand the coreboot memory map format they require legacy BIOS compatibility and can only start using SeaBIOS. In a way this is also true for Linux, but mkelfImage helps bridge the gap so that no BIOS is needed. Obviously everything that uses libpayload is also free of BIOS requirements. memtest86 understands both e820 and coreboot tables, but the coreboot support in memtest86 was not updated to interpret the latest version of coreboot tables, or rather the specific high tables feature. So an unpatched memtest86 will notice that coreboot is available even if you have SeaBIOS, it just does not know how to correctly interpret the coreboot tables. //Peter

2 1

Trac reminder: list of new ticket(s)
by coreboot tracker 20 Sep '10

20 Sep '10

1 0

Re: [coreboot] [PATCH] Make ASUS P3B-F RAM init actually work by enabling SPD access
by Keith Hui 20 Sep '10

20 Sep '10

> > Message: 1 > Date: Sat, 18 Sep 2010 21:06:38 +0200 > From: Uwe Hermann <uwe(a)hermann-uwe.de> > To: coreboot(a)coreboot.org > Subject: [coreboot] [PATCH] Make ASUS P3B-F RAM init actually work by > enabling SPD access > Message-ID: <20100918190638.GE3256@greenwood> > Content-Type: text/plain; charset="us-ascii" > > See patch. > > This fix is brought to you by SerialICE(tm), thanks! > > > Uwe. > -- > http://hermann-uwe.de | http://sigrok.org > http://randomprojects.org | http://unmaintained-free-software.org >

1 0

[commit] r5819 - in trunk/src: mainboard/asus/p3b-f southbridge/intel/i82371eb
by repository service 19 Sep '10

19 Sep '10

Author: uwe Date: Sun Sep 19 23:12:05 2010 New Revision: 5819 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5819 Log: Make ASUS P3B-F RAM init actually work by enabling SPD access. On this board all reads from SPD return 0xff by default, there's a custom GPIO fiddling needed to enable access to the SPD SMBus offsets at 0x50-0x53. While coreboot actually sort of booted sometimes before r5193, that was just sheer luck as the RAM init was hardcoded in certain ways. Since the proper, more heavily SPD-based RAM init the brokenness of the ASUS P3B-F RAM init was becoming visible. This patch uses GPIOs to enable access to the SPD SMBus offsets, and resets the GPIOs again after RAM init (this is needed to allow for lm-sensors to work, for example). Tested successfully on hardware. Signed-off-by: Uwe Hermann <uwe(a)hermann-uwe.de> Acked-by: Idwer Vollering <vidwer(a)gmail.com> Added: trunk/src/southbridge/intel/i82371eb/i82371eb_early_pm.c Modified: trunk/src/mainboard/asus/p3b-f/romstage.c trunk/src/southbridge/intel/i82371eb/i82371eb.h trunk/src/southbridge/intel/i82371eb/i82371eb_early_smbus.c Modified: trunk/src/mainboard/asus/p3b-f/romstage.c ============================================================================== --- trunk/src/mainboard/asus/p3b-f/romstage.c Fri Sep 17 23:38:40 2010 (r5818) +++ trunk/src/mainboard/asus/p3b-f/romstage.c Sun Sep 19 23:12:05 2010 (r5819) @@ -29,6 +29,7 @@ #include "lib/ramtest.c" #include "southbridge/intel/i82371eb/i82371eb_enable_rom.c" #include "southbridge/intel/i82371eb/i82371eb_early_smbus.c" +#include "southbridge/intel/i82371eb/i82371eb_early_pm.c" #include "northbridge/intel/i440bx/raminit.h" #include "lib/debug.c" #include "pc80/udelay_io.c" @@ -49,6 +50,37 @@ #include "northbridge/intel/i440bx/raminit.c" #include "northbridge/intel/i440bx/debug.c" +/* + * ASUS P3B-F specific SPD enable magic. + * + * Setting the byte at offset 0x37 in the PM I/O space to 0x6f will make the + * board DIMMs accessible at SMBus/SPD offsets 0x50-0x53. Per default the SPD + * offsets 0x50-0x53 are _not_ readable (all SPD reads will return 0xff) which + * will make RAM init fail. + * + * Tested values for PM I/O offset 0x37: + * 0x67: 11 00 111: Only SMBus/I2C offsets 0x48/0x49/0x2d accessible + * 0x6f: 11 01 111: Only SMBus/I2C offsets 0x50-0x53 (SPD) accessible + * 0x77: 11 10 111: Only SMBus/I2C offset 0x69 accessible + * + * PM I/O space offset 0x37 is GPOREG[31:24], i.e. it controls the GPIOs + * 24-30 of the PIIX4E (bit 31 is reserved). Thus, GPIOs 27 and 28 + * control which SMBus/I2C offsets can be accessed. + */ +static void enable_spd(void) +{ + outb(0x6f, PM_IO_BASE + 0x37); +} + +/* + * Disable SPD access after RAM init to allow access to SMBus/I2C offsets + * 0x48/0x49/0x2d, which is required e.g. by lm-sensors. + */ +static void disable_spd(void) +{ + outb(0x67, PM_IO_BASE + 0x37); +} + static void main(unsigned long bist) { if (bist == 0) @@ -64,10 +96,16 @@ i82371eb_enable_rom(PCI_DEV(0, 4, 0)); /* ISA bridge is 00:04.0. */ enable_smbus(); + enable_pm(); + + enable_spd(); + /* dump_spd_registers(); */ sdram_set_registers(); sdram_set_spd_registers(); sdram_enable(); /* ram_check(0, 640 * 1024); */ + + disable_spd(); } Modified: trunk/src/southbridge/intel/i82371eb/i82371eb.h ============================================================================== --- trunk/src/southbridge/intel/i82371eb/i82371eb.h Fri Sep 17 23:38:40 2010 (r5818) +++ trunk/src/southbridge/intel/i82371eb/i82371eb.h Sun Sep 19 23:12:05 2010 (r5819) @@ -72,5 +72,6 @@ #define SSDE1 (1 << 3) /* Secondary Drive 1 UDMA/33 */ #define ISA (1 << 0) /* Select ISA */ #define EIO (0 << 0) /* Select EIO */ +#define PMIOSE (1 << 0) /* PM I/O Space Enable */ #endif /* SOUTHBRIDGE_INTEL_I82371EB_I82371EB_H */ Added: trunk/src/southbridge/intel/i82371eb/i82371eb_early_pm.c ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ trunk/src/southbridge/intel/i82371eb/i82371eb_early_pm.c Sun Sep 19 23:12:05 2010 (r5819) @@ -0,0 +1,53 @@ +/* + * This file is part of the coreboot project. + * + * Copyright (C) 2010 Uwe Hermann <uwe(a)hermann-uwe.de> + * + * 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 <stdint.h> +#include <device/pci_ids.h> +#include "i82371eb.h" + +#define PM_IO_BASE 0xe400 + +static void enable_pm(void) +{ + device_t dev; + u8 reg8; + u16 reg16; + + /* Check for SMBus/PM device PCI ID on the 82371AB/EB/MB. */ + dev = pci_locate_device(PCI_ID(PCI_VENDOR_ID_INTEL, + PCI_DEVICE_ID_INTEL_82371AB_SMB_ACPI), 0); + + if (dev == PCI_DEV_INVALID) + die("SMBus/PM controller not found\n"); + + /* Set the PM I/O base. */ + pci_write_config32(dev, PMBA, PM_IO_BASE | 1); + + /* Enable access to the PM I/O space. */ + reg16 = pci_read_config16(dev, PCI_COMMAND); + reg16 |= PCI_COMMAND_IO; + pci_write_config16(dev, PCI_COMMAND, reg16); + + /* PM I/O Space Enable (PMIOSE). */ + reg8 = pci_read_config8(dev, PMREGMISC); + reg8 |= PMIOSE; + pci_write_config8(dev, PMREGMISC, reg8); +} + Modified: trunk/src/southbridge/intel/i82371eb/i82371eb_early_smbus.c ============================================================================== --- trunk/src/southbridge/intel/i82371eb/i82371eb_early_smbus.c Fri Sep 17 23:38:40 2010 (r5818) +++ trunk/src/southbridge/intel/i82371eb/i82371eb_early_smbus.c Sun Sep 19 23:12:05 2010 (r5819) @@ -33,14 +33,12 @@ u8 reg8; u16 reg16; - /* Check for SMBus device PCI ID on the 82371AB/EB/MB. */ + /* Check for SMBus/PM device PCI ID on the 82371AB/EB/MB. */ dev = pci_locate_device(PCI_ID(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82371AB_SMB_ACPI), 0); if (dev == PCI_DEV_INVALID) - die("SMBus controller not found\n"); - - print_spew("SMBus controller enabled\n"); + die("SMBus/PM controller not found\n"); /* Set the SMBus I/O base. */ pci_write_config32(dev, SMBBA, SMBUS_IO_BASE | 1);

1 0

[PATCH] Make ASUS P3B-F RAM init actually work by enabling SPD access
by Uwe Hermann 19 Sep '10

19 Sep '10

See patch. This fix is brought to you by SerialICE(tm), thanks! Uwe. -- http://hermann-uwe.de | http://sigrok.org http://randomprojects.org | http://unmaintained-free-software.org

2 2

mkelfimage and coreboot.rom!!
by ali hagigat 19 Sep '10

19 Sep '10

can i build an elf file from the final coreboot image means coreboot.rom by using mkelfimage tool? Or it is used for Linux kernel only? Thank you to read my message

2 1

RE : RE : [PATCH] Re: RE : RE : First coreboot build for Tyan s2895 K8WE mobo with seabios payload, computer starts, but graphical ubuntu 64bits is crashing
by STEMMELIN, FREDERIC (FREDERIC)** CTR ** 19 Sep '10

19 Sep '10

Now here are my results with the patched Memtest86+ version 4.1. Check the attached files. As you can see it is far way better, even if it is not working, at least i can see that the memory is recognized correctly, wich is pretty good. Memtest86+ is still crashing on test starting (after 3%), but really not important so far, as long as my computer does not crash in normal operation mode. Another question, what may the consequences be not supporting e820 in bios, for other OS like windows for example ? Does another OS use this feature e820 ? Cheers Frédéric ________________________________________ De : coreboot-bounces(a)coreboot.org [coreboot-bounces(a)coreboot.org] de la part de STEMMELIN, FREDERIC (FREDERIC)** CTR ** [frederic.stemmelin(a)alcatel-lucent.com] Date d'envoi : dimanche 19 septembre 2010 15:35 À : Juhana Helovuo Cc : coreboot(a)coreboot.org Objet : [coreboot] RE : [PATCH] Re: RE : RE : First coreboot build for Tyan s2895 K8WE mobo with seabios payload, computer starts, but graphical ubuntu 64bits is crashing Thank you very much for your help, in the mean time i have very goods news, yes my Tyan s2895 is BOOTING now :) I found what was the origin of teh crashes after i was trying to boot a debian livecd with "noapic noapm" and such other things as kernel parameters (i didnt change the defaut settings). I saw a kerneloops on screen after kernel was trying to set a IRQ for the intel network card, with error -39 (or -38 i dont remember exactly). Now after remowing my Intel PRO1000MT server network card from PCI-X slot 6, i can boot without any problems :) Memtest86+ v 4.0 is still not working, but less important now that i am sure my problem was not RAM related :) I will anyway try your instructions with patchs and report back. By the way, i was not able to compile following with coreboot v4: - corinfo => compile errors - tint => same - memtest as payload => same I tried several things like changing Makefile, but it didnt work as i dont understand what it doest exactly. Thank's for your support. PS: If needed i can provide all informations what mayy necessary to find the PCI-X bug with teh network card, if you wish. ________________________________________ De : Juhana Helovuo [juhe(a)iki.fi] Date d'envoi : samedi 18 septembre 2010 18:23 À : STEMMELIN, FREDERIC (FREDERIC)** CTR ** Cc : coreboot(a)coreboot.org Objet : [PATCH] Re: [coreboot] RE : RE : First coreboot build for Tyan s2895 K8WE mobo with seabios payload, computer starts, but graphical ubuntu 64bits is crashing On Sat, 2010-09-18 at 00:14 +0200, STEMMELIN, FREDERIC (FREDERIC)** CTR ** wrote: > In the mean time i checked RAM with memtest86+ v4.0 provided with > Ubuntu 10.04, and it is not working at all, 0kb RAM detected with > coreboot+seabios. > On tyan bios all the RAM is detected properly (no errors on tests > too). > > I have 4*2GB ECC RAM from crucial, dont remember ref, can probably find it somewhere. Hello, My guess from your memtest86+ printouts is the following: With Tyan BIOS, memtest86+ uses BIOS call "e820" to find out the available RAM. With Coreboot + SeaBIOS, memtes86+ detects that there are Coreboot tables in memory ("LxBIOS"), but for some reason thinks that the table reports 0k memory. This may be because your memtest86+ version does not support Coreboot "high tables", and therefore detects the presence of Coreboot, but cannot read the contents of the table. Coreboot does not implement the e820 interface, but SeaBIOS should have it available. However, when memtest86+ detects that Coreboot is present, it ignores the e820 interface and tries to read the Coreboot tables. I have made a patch for memtest86+ v4.10, which adds better support for Coreboot and also multiboot tables. The patch is not my original work, but a combination of two patches, so the credit belongs to the original authors. Application instructions: * Download memtest86+ v 4.10 sources .tar.gz and untar * Apply patch, e.g. patch -p1 < ../coreboot-v4-and-multiboot-support-for-memtest86+-4.10.patch * Manually rename two files: % mv linuxbios.c coreboot.c % mv linuxbios_tables.h coreboot_tables.h * Build memtest86+ using "make" The build process creates two versions of the memtest86+ binary. "memtest" is multiboot-compatible ELF executable and "memtest.bin" is bootable image like a Linux kernel image. Choosing between these two depends on your boot method: BIOS, Coreboot only, Coreboot+SeaBIOS, or a bootloader. My success with memtest86+ has been rather limited, but maybe this works for you. Best regards, Juhana Helovuo -- coreboot mailing list: coreboot(a)coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot

1 0

← Newer
1
...
14
15
16
17
18
19
20
...
33
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 September 2010