headers
rmantchala | 1 Nov 2005 08:33
Picon

Re: Epia-M patch

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

 

 

 

--

-- 
LinuxBIOS mailing list
LinuxBIOS <at> openbios.org
http://www.openbios.org/mailman/listinfo/linuxbios
Permalink | Reply | 2 comments |
headers
Ronald G Minnich | 1 Nov 2005 16:46

Re: Epia-M patch

if the various parties can get a common patch together, that would be 
good. I think we have 2-3 candidates right now ...

ron

--

-- 
LinuxBIOS mailing list
LinuxBIOS <at> openbios.org
http://www.openbios.org/mailman/listinfo/linuxbios
Permalink | Reply | 1 comment |
headers
Stefan Reinauer | 1 Nov 2005 16:37
Gravatar

Re: Epia-M patch

* Ronald G Minnich <rminnich <at> lanl.gov> [051101 16:46]:
> if the various parties can get a common patch together, that would be 
> good. I think we have 2-3 candidates right now ...

I have created a task in the issue tracker that gathers all the
different patches for the Epia-M:

     https://openbios.org/roundup/linuxbios/task4

If you have additions for the Epia-M, please create yourself an account
in the issue tracker at:

     https://openbios.org/roundup/linuxbios/user? <at> template=register

and add the patches to the tracker, in addition to sending them to the
mailing list. This helps other contributors from doing work twice and 
makes it easy for the gatekeepers to keep track of missing merges.

Stefan

--

-- 
LinuxBIOS mailing list
LinuxBIOS <at> openbios.org
http://www.openbios.org/mailman/listinfo/linuxbios
Permalink | Reply | 0 comments |
headers
Steven J. Magnani | 1 Nov 2005 19:08

RE: 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 <at> amd.com] 
Sent: Wednesday, September 14, 2005 1:11 PM
To: Steven J. Magnani; linuxbios <at> 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 <at> digidescorp.com] 
Sent: Wednesday, September 14, 2005 11:06 AM
To: Lu, Yinghai; linuxbios <at> 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 <at> amd.com] 
Sent: Tuesday, September 13, 2005 10:27 AM
To: Steven J. Magnani; linuxbios <at> 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 <at> openbios.org
[mailto:linuxbios-bounces <at> openbios.org] On Behalf Of Steven J. Magnani
Sent: Tuesday, September 13, 2005 8:08 AM
To: linuxbios <at> 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>

--

-- 
LinuxBIOS mailing list
LinuxBIOS <at> openbios.org
http://www.openbios.org/mailman/listinfo/linuxbios
Permalink | Reply | 0 comments |
headers
Lu, Yinghai | 1 Nov 2005 20:06
Picon
Favicon

RE: E7501 Raminit rewrite

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 <at> digidescorp.com] 
Sent: Tuesday, November 01, 2005 10:09 AM
To: Lu, Yinghai; linuxbios <at> 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 <at> amd.com] 
Sent: Wednesday, September 14, 2005 1:11 PM
To: Steven J. Magnani; linuxbios <at> 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 <at> digidescorp.com] 
Sent: Wednesday, September 14, 2005 11:06 AM
To: Lu, Yinghai; linuxbios <at> 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 <at> amd.com] 
Sent: Tuesday, September 13, 2005 10:27 AM
To: Steven J. Magnani; linuxbios <at> 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 <at> openbios.org
[mailto:linuxbios-bounces <at> openbios.org] On Behalf Of Steven J. Magnani
Sent: Tuesday, September 13, 2005 8:08 AM
To: linuxbios <at> 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>

--

-- 
LinuxBIOS mailing list
LinuxBIOS <at> openbios.org
http://www.openbios.org/mailman/listinfo/linuxbios
Permalink | Reply | 0 comments |
headers
Nick Barker | 2 Nov 2005 11:37

Bugs in rom emulator

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();
}

--

-- 
LinuxBIOS mailing list
LinuxBIOS <at> openbios.org
http://www.openbios.org/mailman/listinfo/linuxbios
Permalink | Reply | 1 comment |
headers
Ronald G Minnich | 2 Nov 2005 16:48

Re: Bugs in rom emulator

nick, were you ever able to try the old user-mode emulator. I am still 
seeing the occasional problem with the built-in emulator that came up 
when we made it have less of a ram footprint.

thanks

ron

--

-- 
LinuxBIOS mailing list
LinuxBIOS <at> openbios.org
http://www.openbios.org/mailman/listinfo/linuxbios
Permalink | Reply | 0 comments |
headers
Anton Borisov | 3 Nov 2005 06:16
Picon

patch for cpu in epia-m

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

--

-- 
LinuxBIOS mailing list
LinuxBIOS <at> openbios.org
http://www.openbios.org/mailman/listinfo/linuxbios
Permalink | Reply | 1 comment |
headers
Martin Ley | 3 Nov 2005 07:55

Re: patch for cpu in epia-m

I had the same problem yesterday, but LinuxBios said:

 > Initializing CPU #0
 > CPU: vendor Centaur device 693
 > Unknown cpu

so I added a line with

       { X86_VENDOR_CENTAUR, 0x0693 }, // VIA C3 Nehemiah

to that file.

Anton Borisov schrieb:

>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.
>
>  
>

--

-- 
LinuxBIOS mailing list
LinuxBIOS <at> openbios.org
http://www.openbios.org/mailman/listinfo/linuxbios
Permalink | Reply | 0 comments |
headers
Greg Johnson | 3 Nov 2005 01:41

get_apicid_base unresolved?

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

--

-- 
LinuxBIOS mailing list
LinuxBIOS <at> openbios.org
http://www.openbios.org/mailman/listinfo/linuxbios
Permalink | Reply | 0 comments |

Gmane