coreboot

coreboot@coreboot.org

39717 discussions

[LinuxBIOS] Re: patch for cpu in epia-m
by Raymond Mantchala 03 Nov '05

03 Nov '05

The last digit of the value set in cpu_table ( for example 0x695) is the stepping value reported by cat /dev/cpuinfo. It refers to the release of the processor. It is adviseable to verify that the value corresponding to your cpu is set in cpu_table[]. I have several epia-m boxes some with stepping 1 and some with stepping 8. In this case, I set {X86_VENDOR_CENTAUR, 0x691 } in cpu_table[] to use the box with the cpu wich has stepping 1. Regards

2 1

[LinuxBIOS] patch for cpu in epia-m
by Anton Borisov 03 Nov '05

03 Nov '05

Those who will test EPIA-M systems - please add this string to cpu_table[] in file src/cpu/via/model_centaur/model_centaur_init.c { X86_VENDOR_CENTAUR, 0x0695 }, // VIA C3 Nehemiah This will resolve problem with "Unknown CPU" and apparently will let you boot. -- Sincerely, Anton Borisov

2 1

[LinuxBIOS] get_apicid_base unresolved?
by Greg Johnson 03 Nov '05

03 Nov '05

I'm trying to build LinuxBIOS for a tyan s2891 and am getting linuxbios_ram.o(.text+0x8e22): In function `smp_write_config_table': : undefined reference to `get_apicid_base' Has the issue with get_apicid_base not been resolved yet? Thanks, Greg

1 0

[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

[LinuxBIOS] Tyan S2865
by Justin Cormack 31 Oct '05

31 Oct '05

Ok, I now have several of these. They shouldnt be very different from the supported Tyan chipsets (unless the nForce 4 Ultra chipset is very different from the nForce 4 Pro - lspci below). WOuld I be best off using ECC memory as all the other Tyan ports do? Any other hints and tips? ANyone looked at this? 00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3) 00:01.0 ISA bridge: nVidia Corporation: Unknown device 0050 (rev a3) 00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2) 00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2) 00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3) 00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio Controller (rev a2) 00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2) 00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) 00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) 00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2) 00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3) 00:0b.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) 00:0c.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) 00:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) 00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 01:05.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27) 01:06.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80) 04:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5721 Gigabit Ethernet PCI Express (rev 11)

1 0

[LinuxBIOS] New config language
by Josiah England 30 Oct '05

30 Oct '05

It has come to the awareness of many (apparently *after* I did my talk at the summit) that the mini-config-language is quite useful and indeed necessary unless we want a bunch of really ugly, duplicated makefile code scattered through our codebase, and (most) people have come to the realization that they don't want to handwrite static C initialization structures unnecessarily. So, by request, I've modified the old pseudo-BNF for the config language and appended it to this message with the (initial) changes to include in the "new" language. This is by no means complete nor formal (yet hopefully it is relatively accurate ;). Most of the language description matches what we currently have, but I've also added many of the changes I deem necessary (mostly from common sense). There are a few notes and suggestions on which I'd like some feedback. Feel free to rant or rave on anything and furthermore share your ideas. Said changes are mostly small and include, but are not limited to: - Removing unnecessary "end" statements to commands that needn't be blocks (like 'arch') - Combined the function of 'define' (as found in src/config/Options.lb) as an optional part of the 'default' statement - Limited the widespread used of 'default' for setting options - Changed 'dir' to 'config' and 'config' to 'static' (maybe) - Removing necessity of double-quotes surrounding strings (which may happen to include double-quotes of their own) - etc... ------------------------------------------------------------------------------- New config language for LinuxBIOS This document defines the new configuration language for LinuxBIOS. The goals of the new language are these: - Move from the python based configuration tool to something more easily extensible and flexible - Simplify parser so people can see and alter what is done - Detail output so people can visualize the configuration tree during the parsing process - Implement capability for viewing and altering configuration with Kconfig Here is the new language. It is very similar to the old one, differing in only a few aspects. Furthermore, effort has been put forth to make the new configuration tool capable of parsing the syntax of the old language. This capability may be phased out in the near future, and replaced with warning/error statements for configuration files not conforming to the new language. Pseudo-BNF extensions key: Elements in angled brackets (<>) are nonterminal symbols; items within braces ({}) are for clarification and do not represent grammar, double-quotes ("") denote literal strings required in the text, elements in single-quotes ('') are keywords picked up by the parser, and a postfixed asterisk (*) denotes optionally repeatable blocks. # Expressions are composed of terms acted upon by operators # (unary or binary). # They may optionally be surrounded by parentheses. # (Preferably, surrounding parentheses may soon be required syntax - ?) expr ::= ["("] ( unary-op term ) | ( term (binary-op term)* ) [")"] # term is a number (dec or hex with '0x' notation), ID, or expression. # An ID remains as an unexpanded reference until it is used or exported. term ::= NUM | ID | expr unary-op ::= "+" | "-" | "!" binary-op ::= "+" | "-" | "*" | "/" | "^" | "&&" | "||" # Default command: Define and set an ID to its initial value. # Defaults may only be set in Options.lb files. # Attempts to assign defaults elsewhere are treated as like 'option'. # It is OK to set an ID's default value after it has already been set. # Default assignments may optionally be followed on subsequent lines # with 'export', 'type', and/or 'comment' commands in any order. # A comment will be displayed in generated Kconfig menus. # Values are re-evaluated from component statements when referenced # (ie, are delayed-evaluate, or recursively expanded variables). default ::= 'default' ID "=" value [ type ::= ("number" | "bool" | "string") # (Hex vs. Dec ???) export ::= ("always" | "used" | "never") comment ::= 'comment' [<newline> <comment>]* "end" ] # Option command: Re-sets ID to new value. # Options are used in Config files (in expressions and 'if' statements) # and are also passed to the C compiler when building rom images. # Options always over-ride defaults. # It is an error to have an option command define the value of an ID # after the ID has been referenced (i.e. 'set after used' is an error). option ::= 'option' ID "=" value # Values are treated differently depending on their declared type. # A string is taken literally and doesn't need surrounding quotes. # A numeric type is always evaluated mathematically, as an expression. # An expr containing at least 1 one hex term results in a hex answer. value ::= string | term # Before any option may be referenced in a Config, it must be "used". uses ::= 'uses' ID # The 'chip' command causes sourcing of Config files as in the old # config tool. As parts are sourced, a device tree is built. # The 'device' command also works just as it has in the past. # Note that the 'device' command is used exclusively for describing the # device tree and it does not source any configuration files. # The structure of the tree is determined by the structure of the # components. # Example of structure: ... chip southbridge/via/vt8231 register "enable_native_ide" = "0" device pci 11.0 on # Southbrdge chip superio/winbond/w83627hf device pnp 2e.0 on # Floppy io 0x60 = 0x3f0 end ... # Static initializers are auto-generated from this hierarchy (static.c). # Order does not matter for statements in the same block (for instance, # in the above example, the device block may go before 'register' as # long as it ends). chip ::= 'chip' PATH ['register' """<register_name>""" "=" """<register_value>"""]* [<embedded_chip_or_device_statement>]* "end" # NOTE: Quotes may (preferably) become unneccessary in 'register' # clause. device ::= 'device' device_path_type device_path ("on" | "off") [device_resource <resource_index> "=" <resource_base>]* device_path_type ::= ("pci_domain" | "pci" | "pnp" | "apic" | "apic_cluster" | "i2c") device_path ::= <port_on_path_type>"."<device_number_on_path_type> # NOTE: The two numbers composing the path are implied hex (without the "0x") device_resource ::= "io" | "irq" | "drq" | "mem" # Except as otherwise noted (in 'mainboard' and 'arch'), # PATH is to a file's location in relation to the LinuxBIOS src dir. PATH ::= {path_to_Config_file/}<filename> # Files to include in static.c (Can this command have a better name?) static ::= 'static' PATH # Add C code to the current component (motherboard, etc.) # to initialise the component-INDEPENDENT structure members. # (Only used for src/arch/<arch>/init/crt0.S, so may become implicit) init ::= 'init' PATH # Add C code to the current component (motherboard, etc.) # to initialise the component-DEPENDENT structure members. register ::= 'register' <CODE> # mainboard command specifies where (from src/mainboard directory) # to find the board's root-level Config file with device tree. mainboard ::= 'mainboard' {src/mainboard/}PATH # Specify where (from within src/arch directory) to find the # architecture-specific Config file. arch ::= 'arch' {src/arch/}PATH # Target build directory target ::= 'target' PATH # Payload to include in image; existence is checked before compilation payload ::= 'payload' PATH # Files for building linuxbios: # Include a file in crt0.S mainboardinit ::= 'mainboardinit' PATH # Include an object for initialization initobject ::= 'initobject' PATH # Object file object ::= 'object' PATH # Driver objects are built into the image in a different way driver ::= 'driver' PATH # Use the Config file in the PATH config ::= 'config' PATH # Add a file to the set of ldscript files. ldscript ::= 'ldscript' PATH # Set up a makerule makerule ::= 'makerule' "<rule_name>" ("""[depends]""")* ("""[action]""")* "end" # NOTE: Again, quotes may become unneccessary # Dependencies or actions for the makerule command depends ::= 'depends' <raw_make_syntax(prerequisites)> action ::= 'action' <raw_make_syntax(commands)> # Add an action to an existing make rule. addaction ::= 'addaction' "<rule_name>" <raw_make_syntax(commands)> # Addition definitions used in generated image makefiles. makedefine ::= 'makedefine' <raw_make_syntax> # statements statement ::= option | default | uses | arch | target | chip | device | driver | object | makerule | makedefine | addaction | init | mainboardinit | initobject | if | config | static | ldscript statements ::= (statement)*

1 1

[LinuxBIOS] Epia-M patch
by Nick Barker 29 Oct '05

29 Oct '05

I attach a patch file for the Via Epia-m target which makes this target now compile and work. I have tried to keep all changes local to the directories relevent to this target i.e. - mainboard/via/epia-m - northbridge/via/vt8623 - southbridge/via/vt8623 - southbridge/ricoh - superio/via/vt1211 - targets/via/epia-m However there are 4 files which are modified elsewhere in the sources: - devices/cardbus_device.c - which needed another io resource probing - comments suggest no-one else is using this anyway - include/device/cardbus.h - to include another function definition - cpu/via/model_centaur/model_centaur.c - to add more processor id codes and to get it to set up mtrr's - arch/i386/lib/cpu.c - to conditionally test for SMP & IOAPIC systems - this board/processor has no APIC's and would otherwise fail on the call to lapicid() In addition to making it work again, I have added the following functionality: - Dynamic memory sizing - which has been tested so far with: - - 256Mb 1 bank (i.e. single sided) - - 256Mb 2 bank (i.e. double sided) - - 512Mb 2 bank (i.e. double sided) - A minimalist ACPI dsdt table free of any intellectual property and can thus be distributed with sources. - Compact Flash boot working. - I have also written an EPIA-M howto which I have attached seperately. Maybe that can get onto the web site. Things still not resolved: I spent a great deal of time trying to get the vga to initialise through the emulator, but I have failed. I feel that I now know the workings of the emulator inside out, but it would take a good deal more effort to resolve the issues. As an interim solution, therefore, I have re-implemented the old real mode vga-bios.c which works a treat on this board. To keep the main source tree clean of this, it is implemented locally within the mainboard/via/epia-m directory, and in a way which does not require any changes to the main source tree (e.g. it implements its own temporary gdt's and idt's). Maybe one day I shall return to this problem. Whilst attempting to get the emulator to work, I had to start using a fallback only image for sizing reasons, and this is how the patch is configured. Without both real-mode vga and the emulator it may be possible to go back to a dual image. My original epia-m port set up 2 mtrr's over the vga framebuffer and agp bridge as per the Award bios, and this makes a noticeable difference in performance. Without changing the current mtrr stuff I see no way of making a request for these to be set up, and so this version doesn't attempt to. It would be nice to see this sort of functionality return into the core if anyone is interested - perhaps as another type of memory resource different to main memory and non contiguous from main memory. The type of these mtrr's is write combining rather than write back as used for main memory. Nick Barker

4 5

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot