coreboot November 2005

coreboot@coreboot.org

38 participants
84 discussions

[LinuxBIOS] Bugs in rom emulator
by Nick Barker 02 Nov '05

02 Nov '05

Whilst trying to get the emulator to spark up the vga on the epia-m I came across the following bugs in the emulator: opcodes a0 thru a3 need to respond to the address size prefix and should look as below in src/devices/emulator/x86emu/ops.c The address size prefix is used by the epia-m bios on these instructions, however the emulator still doesn't work for this bios. I am assuming that there are other infrequently used instructions which are less well tested and which are still preventing the bios from running Nick Barker /*************************************************************************** * REMARKS: Handles opcode 0xa0 **************************************************************************** / void x86emuOp_mov_AL_M_IMM(u8 X86EMU_UNUSED(op1)) { u32 offset; START_OF_INSTR(); DECODE_PRINTF("MOV\tAL,"); if( M.x86.mode & SYSMODE_PREFIX_ADDR ) offset = fetch_long_imm(); else offset = fetch_word_imm(); DECODE_PRINTF2("[%04x]\n", offset); TRACE_AND_STEP(); M.x86.R_AL = fetch_data_byte(offset); DECODE_CLEAR_SEGOVR(); END_OF_INSTR(); } /*************************************************************************** * REMARKS: Handles opcode 0xa1 **************************************************************************** / void x86emuOp_mov_AX_M_IMM(u8 X86EMU_UNUSED(op1)) { u32 offset; START_OF_INSTR(); if( M.x86.mode & SYSMODE_PREFIX_ADDR ) offset = fetch_long_imm(); else offset = fetch_word_imm(); if (M.x86.mode & SYSMODE_PREFIX_DATA) { DECODE_PRINTF2("MOV\tEAX,[%04x]\n", offset); } else { DECODE_PRINTF2("MOV\tAX,[%04x]\n", offset); } TRACE_AND_STEP(); if (M.x86.mode & SYSMODE_PREFIX_DATA) { M.x86.R_EAX = fetch_data_long(offset); } else { M.x86.R_AX = fetch_data_word(offset); } DECODE_CLEAR_SEGOVR(); END_OF_INSTR(); } /*************************************************************************** * REMARKS: Handles opcode 0xa2 **************************************************************************** / void x86emuOp_mov_M_AL_IMM(u8 X86EMU_UNUSED(op1)) { u32 offset; START_OF_INSTR(); DECODE_PRINTF("MOV\t"); if( M.x86.mode & SYSMODE_PREFIX_ADDR ) offset = fetch_long_imm(); else offset = fetch_word_imm(); DECODE_PRINTF2("[%04x],AL\n", offset); TRACE_AND_STEP(); store_data_byte(offset, M.x86.R_AL); DECODE_CLEAR_SEGOVR(); END_OF_INSTR(); } /*************************************************************************** * REMARKS: Handles opcode 0xa3 **************************************************************************** / void x86emuOp_mov_M_AX_IMM(u8 X86EMU_UNUSED(op1)) { u32 offset; START_OF_INSTR(); if( M.x86.mode & SYSMODE_PREFIX_ADDR ) offset = fetch_long_imm(); else offset = fetch_word_imm(); if (M.x86.mode & SYSMODE_PREFIX_DATA) { DECODE_PRINTF2("MOV\t[%04x],EAX\n", offset); } else { DECODE_PRINTF2("MOV\t[%04x],AX\n", offset); } TRACE_AND_STEP(); if (M.x86.mode & SYSMODE_PREFIX_DATA) { store_data_long(offset, M.x86.R_EAX); } else { store_data_word(offset, M.x86.R_AX); } DECODE_CLEAR_SEGOVR(); END_OF_INSTR(); }

2 1

RE: [LinuxBIOS] E7501 Raminit rewrite
by Lu, Yinghai 01 Nov '05

01 Nov '05

Good, I suggest use spd_ddr.h spd_ddr2.h spd_ddr3.h spd_fbdimm.h .... YH -----Original Message----- From: Steven J. Magnani [mailto:steve@digidescorp.com] Sent: Tuesday, November 01, 2005 10:09 AM To: Lu, Yinghai; linuxbios(a)openbios.org Subject: RE: [LinuxBIOS] E7501 Raminit rewrite Sorry it's taken so long to respond to this. I propose keeping SPD_xxx for byte addresses that are common to DDR and DDR2, and using SPD_DDR_xxx and SPD_DDR2_xxx for addresses that are defined differently or are unique to DDR and DDR2. Since in many cases, JEDEC kept the same byte address description for DDR2 but changed the interpretation of the bits, I also propose qualifying all of the field/bit-definitions with DDR_ or DDR2_, even if the interpretation happens to be the same. The only exception would be the memory type values, which have to be common to all memory types. The reason for keeping SPD_xxx for byte addresses common to DDR and DDR2 is that code that supports both (i.e. E7520) might get confusing to read if we didn't do this. For example, that code reads parameters like the number of columns only once, so calling the byte address SPD_DDR_NUM_COLUMNS or SPD_DDR2_NUM_COLUMNS Does this sound like a reasonable compromise? The spd.h file would become something like this: #ifndef __SPD_H_DEFINED #define __SPD_H_DEFINED // Byte numbers // (Essentially) common to DDR & DDR2 #define SPD_MEMORY_TYPE 2 #define SPD_NUM_ROWS 3 #define SPD_NUM_COLUMNS 4 #define SPD_MODULE_VOLTAGE 8 #define SPD_MIN_CYCLE_TIME_AT_CAS_MAX 9 #define SPD_DIMM_CONFIG_TYPE 11 #define SPD_REFRESH 12 #define SPD_PRIMARY_DRAM_WIDTH 13 #define SPD_SUPPORTED_BURST_LENGTHS 16 #define SPD_NUM_BANKS_PER_DRAM 17 #define SPD_ACCEPTABLE_CAS_LATENCIES 18 #define SPD_MODULE_ATTRIBUTES 21 #define SPD_MIN_ROW_PRECHARGE_TIME 27 #define SPD_MIN_ROW_ACTIVE_DELAY 28 #define SPD_MIN_RAS_TO_CAS_DELAY 29 #define SPD_MIN_ACTIVE_TO_PRECHARGE_DELAY 30 #define SPD_ADDRESS_CMD_HOLD 33 #define SPD_MIN_ACTIVE_TO_ACTIVE_TIME 41 #define SPD_MIN_AUTO_REFRESH_CMD_PERIOD 42 // DDR-specific #define SPD_DDR_NUM_DIMM_BANKS 5 #define SPD_DDR_MODULE_DATA_WIDTH_LSB 6 #define SPD_DDR_MODULE_DATA_WIDTH_MSB 7 #define SPD_DDR_MIN_CYCLE_TIME_AT_CAS_REDUCED_05 23 #define SPD_DDR_MIN_CYCLE_TIME_AT_CAS_REDUCED_10 25 // DDR2-specific #define SPD_DDR2_NUM_DIMM_RANKS 5 #define SPD_DDR2_MODULE_DATA_WIDTH 6 #define SPD_DDR2_MIN_CYCLE_TIME_AT_CAS_REDUCED_1 23 #define SPD_DDR2_MIN_CYCLE_TIME_AT_CAS_REDUCED_2 25 /****************************************************/ // SPD_MEMORY_TYPE values #define MEMORY_TYPE_SDRAM_DDR 7 #define MEMORY_TYPE_DDR2_SDRAM 8 // SPD_MODULE_VOLTAGE values #define DDR_VOLTAGE_SSTL2_5 4 #define DDR2_VOLTAGE_SSTL2_5 4 // SPD_DIMM_CONFIG_TYPE values #define DDR_ERROR_SCHEME_NONE 0 #define DDR_ERROR_SCHEME_PARITY 1 #define DDR_ERROR_SCHEME_ECC 2 #define DDR2_DATA_PARITY (1<<0) #define DDR2_DATA_ECC (1<<1) #define DDR2_ADDRESS_PARITY (1<<2) // SPD_ACCEPTABLE_CAS_LATENCIES values #define DDR_CAS_LATENCY_1_0 0x01 #define DDR_CAS_LATENCY_1_5 0x02 #define DDR_CAS_LATENCY_2_0 0x04 #define DDR_CAS_LATENCY_2_5 0x08 #define DDR_CAS_LATENCY_3_0 0x10 #define DDR_CAS_LATENCY_3_5 0x20 #define DDR_CAS_LATENCY_4_0 0x40 #define DDR2_CAS_LATENCY_2 (1<<2) #define DDR2_CAS_LATENCY_3 (1<<3) #define DDR2_CAS_LATENCY_4 (1<<4) #define DDR2_CAS_LATENCY_5 (1<<5) #define DDR2_CAS_LATENCY_6 (1<<6) // SPD_SUPPORTED_BURST_LENGTHS values #define DDR_BURST_LENGTH_1 1 #define DDR_BURST_LENGTH_2 2 #define DDR_BURST_LENGTH_4 4 #define DDR_BURST_LENGTH_8 8 #define DDR_BURST_LENGTH_PAGE (1<<7) #define DDR2_BURST_LENGTH_4 4 #define DDR2_BURST_LENGTH_8 8 // SPD_MODULE_ATTRIBUTES values #define DDR_MODULE_BUFFERED 1 #define DDR_MODULE_REGISTERED 2 #endif // __SPD_H_DEFINED It's a sticky problem, since undoubtedly there will be more changes when the next DRAM technology is standardized, and (theoretically, at least) there can be differences in definitions even between revisions of the standard for a particular memory type. Hopefully a scheme like this will work for awhile, even if it isn't perfect. ------------------------------------------------------------------------ Steven J. Magnani "I claim this network for MARS! www.digidescorp.com Earthling, return my space modulator!" #include <standard.disclaimer> -----Original Message----- From: Lu, Yinghai [mailto:yinghai.lu@amd.com] Sent: Wednesday, September 14, 2005 1:11 PM To: Steven J. Magnani; linuxbios(a)openbios.org Subject: RE: [LinuxBIOS] E7501 Raminit rewrite Every define have SPD_DDR_ prefix, or with ddr_spd.h and SPD_ prefix.... YH -----Original Message----- From: Steven J. Magnani [mailto:steve@digidescorp.com] Sent: Wednesday, September 14, 2005 11:06 AM To: Lu, Yinghai; linuxbios(a)openbios.org Subject: RE: [LinuxBIOS] E7501 Raminit rewrite Can you be more specific about the changes you'd like to see? Steve -----Original Message----- From: Lu, Yinghai [mailto:yinghai.lu@amd.com] Sent: Tuesday, September 13, 2005 10:27 AM To: Steven J. Magnani; linuxbios(a)openbios.org Subject: RE: [LinuxBIOS] E7501 Raminit rewrite It's good to have spd.h there. But the name should be changed for support DDR2...etc. YH -----Original Message----- From: linuxbios-bounces(a)openbios.org [mailto:linuxbios-bounces@openbios.org] On Behalf Of Steven J. Magnani Sent: Tuesday, September 13, 2005 8:08 AM To: linuxbios(a)openbios.org Subject: [LinuxBIOS] E7501 Raminit rewrite This one ends up being a little more than a "patch". I ended up reorganizing the E7501 raminit code so I could follow it, and fixed some bugs along the way. Significant logical changes: * Added support for "fast" (64-clock) refresh * Added code to support remap window for 3 - 4 GB systems * Fixed premature configuration of true row boundaries that resulted in some sections of DRAM not receiving JEDEC commands (see http://openbios.org/pipermail/linuxbios/2005-June/011752.html). * Redefined RCOMP_MMIO so that RCOMP registers can be configured on systems where A20M# is asserted. * Disabled subsystem (vendor) ID configuration * #ifdef'd out suspicious looking code (see http://openbios.org/pipermail/linuxbios/2005-June/011759.html) * Added optional run-time checking of dual-channel compatibility of installed DIMMs * Move JEDEC SPD and SDRAM definitions into reusable #include files Probably, the rewritten code should be reviewed as if it were new. My hope is that it is now easy enough to follow that this shouldn't be too bad. The original code is, of course, in Subversion. Since I reordered the functions as part of the rewrite, a 'diff' of of the new code against the original won't tell you much. I've attached a reordered copy of the Subversion code that won't compile, but should be a little easier to diff against the new code so you can see what's changed. I will hold off on committing this for awhile to give people time to look at it. I know that radical changes are a pain to review, but IMHO the improvement in maintainability is significant. New files that are part of this 'patch', but not included here (I committed these to Subversion): src/include/spd.h src/include/sdram_mode.h src/include/northbridge/intel/e7501/e7501.h Thanks, Steve ------------------------------------------------------------------------ Steven J. Magnani "I claim this network for MARS! www.digidescorp.com Earthling, return my space modulator!" #include <standard.disclaimer>

1 0

RE: [LinuxBIOS] E7501 Raminit rewrite
by Lu, Yinghai 01 Nov '05

01 Nov '05

Every define have SPD_DDR_ prefix, or with ddr_spd.h and SPD_ prefix.... YH -----Original Message----- From: Steven J. Magnani [mailto:steve@digidescorp.com] Sent: Wednesday, September 14, 2005 11:06 AM To: Lu, Yinghai; linuxbios(a)openbios.org Subject: RE: [LinuxBIOS] E7501 Raminit rewrite Can you be more specific about the changes you'd like to see? Steve -----Original Message----- From: Lu, Yinghai [mailto:yinghai.lu@amd.com] Sent: Tuesday, September 13, 2005 10:27 AM To: Steven J. Magnani; linuxbios(a)openbios.org Subject: RE: [LinuxBIOS] E7501 Raminit rewrite It's good to have spd.h there. But the name should be changed for support DDR2...etc. YH -----Original Message----- From: linuxbios-bounces(a)openbios.org [mailto:linuxbios-bounces@openbios.org] On Behalf Of Steven J. Magnani Sent: Tuesday, September 13, 2005 8:08 AM To: linuxbios(a)openbios.org Subject: [LinuxBIOS] E7501 Raminit rewrite This one ends up being a little more than a "patch". I ended up reorganizing the E7501 raminit code so I could follow it, and fixed some bugs along the way. Significant logical changes: * Added support for "fast" (64-clock) refresh * Added code to support remap window for 3 - 4 GB systems * Fixed premature configuration of true row boundaries that resulted in some sections of DRAM not receiving JEDEC commands (see http://openbios.org/pipermail/linuxbios/2005-June/011752.html). * Redefined RCOMP_MMIO so that RCOMP registers can be configured on systems where A20M# is asserted. * Disabled subsystem (vendor) ID configuration * #ifdef'd out suspicious looking code (see http://openbios.org/pipermail/linuxbios/2005-June/011759.html) * Added optional run-time checking of dual-channel compatibility of installed DIMMs * Move JEDEC SPD and SDRAM definitions into reusable #include files Probably, the rewritten code should be reviewed as if it were new. My hope is that it is now easy enough to follow that this shouldn't be too bad. The original code is, of course, in Subversion. Since I reordered the functions as part of the rewrite, a 'diff' of of the new code against the original won't tell you much. I've attached a reordered copy of the Subversion code that won't compile, but should be a little easier to diff against the new code so you can see what's changed. I will hold off on committing this for awhile to give people time to look at it. I know that radical changes are a pain to review, but IMHO the improvement in maintainability is significant. New files that are part of this 'patch', but not included here (I committed these to Subversion): src/include/spd.h src/include/sdram_mode.h src/include/northbridge/intel/e7501/e7501.h Thanks, Steve ------------------------------------------------------------------------ Steven J. Magnani "I claim this network for MARS! www.digidescorp.com Earthling, return my space modulator!" #include <standard.disclaimer>

2 1

Re: [LinuxBIOS] Epia-M patch
by rmantchala 01 Nov '05

01 Nov '05

With the last patch from Nick Barker, after booting I only see on the serial console: LinuxBIOS-1.1.8.0Fallback Sat Oct 29 13:55:37 CEST 2005 starting... Enabling mainboard devices I have solved this issue by changing enable_mainboard_devices function in src/mainboard/via/epia-m/auto.c . I have modified the 2th pci_write_config line from : pci_write_config8(dev, 0x51, 0x10); to pci_write_config8(dev, 0x51, 0x1f); With this modification, the epia-m system is booting and I can use it. Regards

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot November 2005