From rmantchala at wanadoo.fr  Tue Nov  1 08:33:29 2005
From: rmantchala at wanadoo.fr (rmantchala)
Date: Tue, 1 Nov 2005 08:33:29 +0100
Subject: [LinuxBIOS] Epia-M patch
Message-ID: <000001c5deb6$8e385dc0$0101a8c0@kriss>

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
 
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20051101/652b81ca/attachment.html>

From rminnich at lanl.gov  Tue Nov  1 16:46:30 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 01 Nov 2005 08:46:30 -0700
Subject: [LinuxBIOS] Epia-M patch
In-Reply-To: <000001c5deb6$8e385dc0$0101a8c0@kriss>
References: <000001c5deb6$8e385dc0$0101a8c0@kriss>
Message-ID: <43678DD6.803@lanl.gov>

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

ron



From stepan at openbios.org  Tue Nov  1 16:37:28 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue, 1 Nov 2005 16:37:28 +0100
Subject: [LinuxBIOS] Epia-M patch
In-Reply-To: <43678DD6.803@lanl.gov>
References: <000001c5deb6$8e385dc0$0101a8c0@kriss> <43678DD6.803@lanl.gov>
Message-ID: <20051101153728.GA19989@openbios.org>

* 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?@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





From steve at digidescorp.com  Tue Nov  1 19:08:57 2005
From: steve at digidescorp.com (Steven J. Magnani)
Date: Tue, 1 Nov 2005 12:08:57 -0600
Subject: [LinuxBIOS] E7501 Raminit rewrite
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4201E0614C@ssvlexmb2.amd.com>
Message-ID: <000201c5df0f$5799fc20$15070a0a@banana>

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>












From yinghai.lu at AMD.COM  Tue Nov  1 20:06:51 2005
From: yinghai.lu at AMD.COM (Lu, Yinghai)
Date: Tue, 1 Nov 2005 11:06:51 -0800
Subject: [LinuxBIOS] E7501 Raminit rewrite
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E061F8@ssvlexmb2.amd.com>

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>














From nick.barker9 at btinternet.com  Wed Nov  2 11:37:27 2005
From: nick.barker9 at btinternet.com (Nick Barker)
Date: Wed, 2 Nov 2005 10:37:27 -0000
Subject: [LinuxBIOS] Bugs in rom emulator
Message-ID: <CHEGKGFOOBMOIAKJLGNEGEFCCDAA.nick.barker9@btinternet.com>

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




From rminnich at lanl.gov  Wed Nov  2 16:48:55 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 02 Nov 2005 08:48:55 -0700
Subject: [LinuxBIOS] Bugs in rom emulator
In-Reply-To: <CHEGKGFOOBMOIAKJLGNEGEFCCDAA.nick.barker9@btinternet.com>
References: <CHEGKGFOOBMOIAKJLGNEGEFCCDAA.nick.barker9@btinternet.com>
Message-ID: <4368DFE7.4010008@lanl.gov>

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



From a.borisov at tesv.tmb.ru  Thu Nov  3 06:16:39 2005
From: a.borisov at tesv.tmb.ru (Anton Borisov)
Date: Thu, 3 Nov 2005 08:16:39 +0300
Subject: [LinuxBIOS] patch for cpu in epia-m
Message-ID: <20051103081639.64a12238.a.borisov@tesv.tmb.ru>

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



From m303 at luusa.org  Thu Nov  3 07:55:04 2005
From: m303 at luusa.org (Martin Ley)
Date: Thu, 03 Nov 2005 07:55:04 +0100
Subject: [LinuxBIOS] patch for cpu in epia-m
In-Reply-To: <20051103081639.64a12238.a.borisov@tesv.tmb.ru>
References: <20051103081639.64a12238.a.borisov@tesv.tmb.ru>
Message-ID: <4369B448.40302@luusa.org>

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




From gjohnson at lanl.gov  Thu Nov  3 01:41:29 2005
From: gjohnson at lanl.gov (Greg Johnson)
Date: Wed, 2 Nov 2005 17:41:29 -0700
Subject: [LinuxBIOS] get_apicid_base unresolved?
Message-ID: <20051103004129.GZ10181@durango.c3.lanl.gov>

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



From rmantchala at wanadoo.fr  Thu Nov  3 14:53:58 2005
From: rmantchala at wanadoo.fr (Raymond Mantchala)
Date: Thu, 03 Nov 2005 14:53:58 +0100
Subject: [LinuxBIOS] Re: patch for cpu in epia-m
Message-ID: <436A1676.3060209@wanadoo.fr>

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



From stepan at openbios.org  Thu Nov  3 16:35:36 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Thu, 3 Nov 2005 16:35:36 +0100
Subject: [LinuxBIOS] Re: patch for cpu in epia-m
In-Reply-To: <436A1676.3060209@wanadoo.fr>
References: <436A1676.3060209@wanadoo.fr>
Message-ID: <20051103153536.GA785@openbios.org>

* Raymond Mantchala <rmantchala at wanadoo.fr> [051103 14:53]:
> 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.

Maybe it would make sense to mask the last digit out for matching
against the table then? Otherwise we end up having very vulnerable rom
images. Plugging a new CPU in suddenly keeps the system from working and
such.
Or we need to store an id and a mask. ie. {X86_VENDOR_CENTAUR, 0x690, 0xfff0 }
to match 0x69[0-f] with one entry.

Stefan





From yinghai.lu at amd.com  Thu Nov  3 18:41:29 2005
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Thu, 3 Nov 2005 09:41:29 -0800
Subject: [LinuxBIOS] get_apicid_base unresolved?
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E061FD@ssvlexmb2.amd.com>

Please check my patch 1025_enable_CAR_init_cpus_get_apicid_base.diff
that I sent out 10/26. I will check that in and populate that to
s2891....

YH

-----Original Message-----
From: linuxbios-bounces at openbios.org
[mailto:linuxbios-bounces at openbios.org] On Behalf Of Greg Johnson
Sent: Wednesday, November 02, 2005 4:41 PM
To: linuxbios at openbios.org
Subject: [LinuxBIOS] 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





From matt at glw.com  Fri Nov  4 23:10:30 2005
From: matt at glw.com (Matthew Simmons)
Date: Fri, 4 Nov 2005 16:10:30 -0600
Subject: [LinuxBIOS] S2882 Memory Hang
Message-ID: <20051104220829.664C04BF01@mail.glw.com>

I am currently trying get LinuxBios up and running on my Tyan S2882. After
hard coding the apicid_base = 1 in the mptable.c I was finally able to
successfully build a bios image for my system. I am using filo as the
payload and the configuration of that went well. 
 
Both LinuxBios and filo are working as expected. The problem occurs when I
attempt to boot the kernel. The kernel stops after the memory manager loads.
There are no errors or panics. The system just locks up. 
 
I was wondering if any of you have seen this problem, or know of a work
around. I am including the kernel output from the serial console. As well as
a brief description of the configuration of the system.
 
Thanks for your help,
Matthew Simmons


 
Configuration:
----------------------------------------------
Tyan S2882 2x Opteron 248 Processors
1024mb Ram (512x per processor)
LinuxBIOSv2 (Revision 2084)
Kernel: 2.6.12.1 with the Realtime Preempt Patch
Base OS: SuSE 9.2
GCC version: 3.3.2
 
 
Serial Console Output: (Sorry for the length)
------------------------------------------------
LinuxBIOS-1.1.8_s2882_Fallback Fri Nov  4 12:47:40 CST 2005 starting...

(0,1) link=01             
(1,0) link=01             
02 nodes initialized.                     
SBLink=00         
NC node|link=00               
Ram1.00       
Ram1.01       
Ram2.00       
Ram2.01       
Ram3    
Initializing memory:  done                          
Initializing memory:  done                          
Clearing initial memory region:  done                                     
Ram4    
Copying LinuxBIOS to ram.                         
Jumping to LinuxBIOS.                     
LinuxBIOS-1.1.8_s2882_Fallback Fri Nov  4 12:47:40 CST 2005 booting...

Enumerating buses...                    
APIC_CLUSTER: 0 enabled                       
PCI_DOMAIN: 0000 enabled                        
CPU: APIC: 10 enabled                     
PCI: 00:19.0 [1022/1100] enabled                                
PCI: 00:19.1 [1022/1101] enabled                                
PCI: 00:19.2 [1022/1102] enabled                                
PCI: 00:19.3 [1022/1103] enabled                                
CPU: APIC: 11 enabled                     
PCI: pci_scan_bus for bus 0                           
PCI: 00:18.0 [1022/1100] enabled                                
PCI: 00:18.1 [1022/1101] enabled                                
PCI: 00:18.2 [1022/1102] enabled                                
PCI: 00:18.3 [1022/1103] enabled                                
PCI: 00:19.0 [1022/1100] enabled                                
PCI: 00:19.1 [1022/1101] enabled                                
PCI: 00:19.2 [1022/1102] enabled                                
PCI: 00:19.3 [1022/1103] enabled                                
PCI: 01:00.0 [1022/7450] en                          
PCI: 01:01.0 [1022/7450] enabled next_unitid: 0003

PCI: 01:00.0 [1022/7460] enabled                                
PCI: 01:03.0 [1022/7460] enabled next_unitid: 0007

PCI: pci_scan_bus for bus 1                           
PCI: 01:01.0 [1022/7450] enabled                                
PCI: 01:01.1 [1022/7451] enabled                                
PCI: 01:02.0 [1022/7450] enabled                                
PCI: 01:02.1 [1022/7451] enabled                                
PCI: 01:03.0 [1022/7460] enabled                                
PCI: 01:04.0 [1022/7468] enabled                                
PCI: 01:04.1 [1022/7469] enabled                                
PCI: 01:04.2 [1022/746a] enabled                                
PCI: 01:04.3 [1022/746b] enabled                                
PCI: pci_scan_bus for bus 2                           
Disabling static device: PCI: 0                              
Disabling static device: PCI: 02:06.1                                     
PCI: 02:09.0 [14e4/1648] enabled                                
PCI: 02:09.1 [14e4/1648] enabled                                
PCI: pci_scan_bus returning with max=02

PCI: 02: 100MHz PCI-X                     
PCI: pci_scan_bus for bus 3                           
PCI: 03:04.0 [10ee/3fc6] enabled                                
PCI: pci_scan_bus returning with max=03

PCI: 03: Conventional PCI                         
PCI: pci_scan_bus for bus 4                           
PCI: 04:00.0 [1022/7464] enabled                                
PCI: 04:00.1 [1022/7464] enabled                                
PCI: 04:05.0 [1095/3114] enabled                                
PCI: 04:06.0 [1002/4752] enabled                                
PCI: 04:08.0 [8086/1229] enabled                                
PCI: pci_scan_bus returning with m                                
PNP: 002e.0 enabled                   
PNP: 002e.1 disabled                    
PNP: 002e.2 enabled                   
PNP: 002e.3 disabled                    
PNP: 002e.5 enabled                   
PNP: 002e.6 disabled                    
PNP: 002e.7 disabled                    
PNP: 002e.8 disabled                    
PNP: 002e.9 disabled                    
PNP: 002e.a disabled                    
PNP: 002e.b enabled                   
PCI: pci_scan_bus returning with max=04

PCI: pci_scan_bus returning with max=04

done    
Allocating resources...                       
Reading resources...                    
PCI: 01:01.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 2 io

PCI: 01:01.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 2 prefmem

PCI: 01:02.0 1c <- [0x00fffff00                              
PCI: 01:02.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 3 prefmem
map page: 16ee: 118                          
Cannot map page: 16f       
PCI: 01:03.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 4 prefmem

Cannot map pag              
Cannot map p
Done reading resources.        
Cannot map pag
Allocating VGA resource PCI: 04:06.0                             
Cannot
Setting PCI_BRIDGE_CTL_VGA for bridge PCI: 01:03.0 map page: 174xtra MTRR'sd
<                      
Setting PCI_BRIDGE_CTL_VGA for bridge PCI: 00:18.0  
Cannot map          
Cannot map page: 176      
Setting PCI_BRIDGE_CTL_VGA for bridge PCI_DOMAIN: 0000            

Cannot map page: 178 page: 14b          
Setting PCI_BRIDGE_CTL_VGA for bridge Root Devicep page: 14c

Setting resources...7a                  
PCI: 00:18.0 1b8 <- [0x00fd400000 - 0x00fd3fffff] prefmem <node 0 link 0>

Cannot map page:                
Cannot map page: 17d   
PCI: 01:02.1 10 <- [0x00fd301000 - 0x00fd301fff] mem64map page: 17

Cannot map page: 1a8  
PCI: 01:03.0 1c <- [0x0000001000 - 0x0000001fff] bus 4 io page: 18

Cannot map page: 1
PCI: 01:03.0 20 <- [0x00fc000000 - 0x00fd0fffff] bus 4 memge: 191

Cannot map page: 1acnot
PCI: 04:00.0 10 <- [0x00fd020000 - 0x00fd020fff] meme: 1ading f

Cannot map page
PCI: 04:00.1 10 <- [0x00fd021000 - 0x00fd021fff] mem  
Cannot map page: 1aft map                        
PCI: 04:05.0 10 <- [0x0000001450 - 0x0000001457] ioCann    
Cannot map page: 1b1age: 19566e: 124M, W  
PCI: 04:05.0 14 <- [0x0000001470 - 0x0000001473] ioge: 1b                   
Cannot map page: 1bcot ma
PCI: 04:05.0 18 <- [0x0000001460 - 0x0000001467] ioot map page: 1bdot map

Ca
PCI: 04:05.0 1c <- [0x00000014                        
   
PNP: 002e.0 70 <- [0x0000000006 - 0x0000000006] irq     
Cannot map page: 1de                    
Cann
PNP: 002e.0 74 <- [0x0000000002 - 0x0000000002] drq           
P 
C 
Can   

-Cannot map page: 1e0t ma
PNP: 002e.2 60 <- [0x00000003f8 - 0x00000003ff] ionot map page: 1e1

Cannot ma   
PNP: 002e.2 70 <- [0x0000000004 - 0x0000000004] irqo     
Cannot map page: 1e3ot map page: 1ca        
PNP: 002e.5 60 <- [0x0000000060 - 0x0000000060] io                  


Cannot map page: 1f4         
PNP: 002e.5 62 <- [0x0000000064 - 0x0000000064] io              
Cannot      
Cannot map page: 1f6  
PNP: 002e.5 70 <- [0x0000000001 - 0x0000000001] irq: 1f7                    
Cannot m        
Cannot m
PNP: 002e.5 72 <- [0x000000000c - 0x000000000c] irq                    
Cannot map page: 1f9Cannot map
PNP: 002e.b 60 <- [0x0000000290 - 0x0000000297] ioage: 1faage: 1ee

Canno
PNP: 002e.b 70 <- [0x0000000005 - 0x0000000005] irq                       
Cannot map page            
PNP: 002e.5 init        
PCI: 01:01.1 cmd <- 146b i             
NB: Fu
PCI: 01:02.0 bridge ctrl <- 0003                               

PCI: 01:02.0 cmd <- 1460ot ma                 
PCI: 03:04.0 cmd <- 142.0 init                
PCI: 01:02.1 subsystem <- 10f1/2882    
PNP: 002e.0 initd             
PCI: 01:02.1 cmd <- 146 tables to 0xf0000...do
PCI: 01:03.0 bridge ctrl <- 000b                                
PCI: 01:03.0 cmd <- 147ng copy of IRQ routing 
PCI: 04:00.0 subsystem <- 10f1/2882                                   
PCI: 04:00.0 cmd <- 142PCI: 00:19.1 init:06.0 
PCI: 04:00.1 subsystem <- 10f1/2882RQ routing table consistency...PCI:
PCI: 04:00.1 cmd <- 142                       
PCI: 04:05.0 subsystem <- 10f1/2882 
check_pirq_routing_table() - irq_
PCI: 04:05.0 cmd <- 143: 0x000f00sc Control.. 
PCI: 04:06.0 subsystem <- 10f1/2882                                   
PCI: 04:06.0 cmd <- 1c3         
           

    33:stre
PCI: 01:04.1 cmd <- 1410xfffe0000 - 0xfffe6fff
PCI: 01:04.2 subsystem <- 10f1/2882                            
Found 
PCI: 01:04.2 cmd <- 141                       
PCI: 01:04.3 subsystem <- 10f1/2882                      
Loading Ethe
PCI: 01:04.3 cmd <- 141                       
PCI: 00:18.1 subsystem <- 10f1/2882ing non PT_LOAD segment            
PCI: 00:18.1 cmd <- 140ot 5.2.6 (GPL) http://e
PCI: 00:18.2 subsystem <- 10f1/2882 hda4:/boot/vmlinuz initrd=/boot/in
PCI: 00:18.2 cmd <- 140ons                    
PCI: 00:18.3 cmd <- 140                       
PCI: 00:19.0 cmd <- 140                       
PCI: 00:19.1 cmd <- 140                       
hda: LBA48: HDS7280
Initializing CPU #0                 


CPU: vendor AMD device f5aack Fri Nov  4 13:59:37 CS
Enabling cache...           

Setting fixed MTRRs(0-88) type: UC                        
Found Lin
Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM                           
(0,1) link=01host) #
Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM       
02 nodes initialized.                    
DONE fixed MTRRsSBLink=00and lin
Setting variable MTRR 0, base:    0MB, range: 1024MB, type WB

ht reset -canning NU                    



DONE variable MTRRs2_Fallback Fri Nov 
Clear out the extra MTRR'sng...                     

MTRR check          
Fixed MTRRs   : Enabled    
Linux version     
Variable MTRRs: Enabledeko at buildho            

Setting up local apic..=01on 3               
Copying Lin
Enabling cachepe 16         

Setting fixed MTRRs(0-88) type: UCnuxBIOS.                     
 BIO
Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM4 13:59:37 CST 2005
booting...                  
Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM  
 BIOS-e820: 00000000000f0000 - 000            
DONE fixed MTRRs     
Enumeratin
Setting variable MTRR 0, base:    0MB, range: 1024MB, type WB               
Scanning NU           
PCI_DOMAIN: 0000 enabl
DONE variable MTRRs              
CPU:
Clear out the extra MTRR's 0000000000               

MTRR check          
Fixed MTRRs   : Enabled/11                    
PCI: 00:19.1 [10
All AP CPUs stopped                   
PCI: 00:18.0 initr #17 INVAL      
PCI: 01:01.0 init 00:19.2 [1022/11
PCI: 02:09.0 init                 
PCI: 02:09.1 init#1           
PCI
PCI: 01:02.0 init03] enabled      
PCI: 01:03.0 init        
I 
PCI: 
PCI: 04:05.0 init] enabled00.     
PCI: 04:06.0 init            
PCI:
rom address for PCI: 04:06.0 = fff80000: 0003

Incorrect Expansion ROM Header Signature 457fCI: 01:00.0 [1022/7460] enabled

PCI: 04:08.0 init
CPU 0: apertur  
PCI: 01:04.0 init01:03.0 [1022/746
RTC Initd next_u
Invalid CMOS LB checksum                        
enabling HPET @0xf                 
PCI: 00:18.2 init                 
PCI: 00:18.3 initstatic device: PC
NB: Function 3 Misc Control.. done.           
Inode-cache hash table 
PCI: 00:19.0 init               
D
PCI: 00:19.1 initvice: PCI: 02:06.
PCI: 00:19.2 init                 
PCI: 00:19.3 init14e4/1648] enable
NB: Function 3 Misc Control.. done.                                   
PCI: 03:04.0 init        
PCI: 02:
Devices initializedbledk data, 220k in
Copying IRQ routing tables to 0xf0000...done.       
PCI: pci_scan_bus returning with max=
Wrote the mp table end at: 00000020 - 00000214
Moving GDT to 0x500...ok
Wrote linuxbios table at: 00000530 - 00000de4  checksum 9515

Welcome to elfboot, the open sourced starter.
January 2002, Eric Biederman.
Version 1.3

    33:stream_init() - rom_stream: 0xfffe0000 - 0xfffe6fff
Found ELF candiate at offset 0
Loading Etherboot version: 5.2.6
Dropping non PT_LOAD segment
New segment addr 0x20000 size 0x312bd offset 0xb0 filesize 0x6c5b
(cleaned up) New segment addr 0x20000 size 0x312bd offset 0xb0 filesize
0x6c5b
Loading Segment: addr: 0x000000003ff90000 memsz: 0x000000000002a000 filesz:
0x0000000000006c5b
Clearing Segment: addr: 0x000000003ff96c5b memsz: 0x00000000000233a5
Loading Segment: addr: 0x000000000004a000 memsz: 0x00000000000072bd filesz:
0x0000000000000000
Clearing Segment: addr: 0x000000000004a000 memsz: 0x00000000000072bd
Jumping to boot code at 0x20000
ROM segment 0x0000 length 0x0000 reloc 0x00020000
CPU 2056 Mhz
Etherboot 5.2.6 (GPL) http://etherboot.org Tagged ELF for [FILO]
Relocating _text from: [00026c60,00052870) to [3fed43f0,3ff00000)
Boot from (N)etwork (D)isk or (Q)uit?

Probing pci disk...it() - ro
Int BIOS-e820: 00000000000f0000 - 00000000000f0400 type 16i Nov  4 13:57:25
C
Virtual Wire compatibility mode
BIOS-e820: 0000000000100000 - 0000000040000000 (usable)>Product ID: S2882
<6>APIC at: 0xFEE00000hda4 con
Scanning NUMA topology in Northbridge 24toppe
New segment
Virtual Wire compatibility mode.
OEM ID: TYAN     <6>Product ID: S2882        <6>APIC at: 0xFEE00000
Processor #16 15:5 APIC version 16
Processor #17 15:5 APIC version 16
Processor #17 INVALID. (Max ID: 16).
I/O APIC #1 Version 17 at 0xFEC00000.
I/O APIC #2 Version 17 at 0xFD300000.
I/O APIC #3 Version 17 at 0xFD301000.
Processors: 2
Checking aperture...
CPU 0: aperture @ f8000000 size 64 MB
CPU 1: aperture @ f8000000 size 64 MB
Built 2 zonelists
Kernel command line: ro root=/dev/hda4 console=ttyS0,115200
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 131072 bytes)
time.c: Using 1.193182 MHz PIT timer.
time.c: Detected 1990.814 MHz processor.
Console: colour dummy device 80x25
Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Memory: 1023436k/1048576k available (2452k kernel code, 0k reserved, 942k
data,
220k init)




From yinghai.lu at amd.com  Sat Nov  5 00:51:23 2005
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Fri, 4 Nov 2005 15:51:23 -0800
Subject: [LinuxBIOS] S2882 Memory Hang
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E061FF@ssvlexmb2.amd.com>

1. You don't need to lift your cpu apic id above 0x10.

2. for amd8111 sb, when you do that, kernel will hang, because jiffies
will not change.

So remove 0x10 in your k8_secondart_stop.....
And hard code apicid_base to 4

It should work....

YH


-----Original Message-----
From: linuxbios-bounces at openbios.org
[mailto:linuxbios-bounces at openbios.org] On Behalf Of Matthew Simmons
Sent: Friday, November 04, 2005 2:11 PM
To: linuxbios at openbios.org
Subject: [LinuxBIOS] S2882 Memory Hang

I am currently trying get LinuxBios up and running on my Tyan S2882.
After
hard coding the apicid_base = 1 in the mptable.c I was finally able to
successfully build a bios image for my system. I am using filo as the
payload and the configuration of that went well. 
 
Both LinuxBios and filo are working as expected. The problem occurs when
I
attempt to boot the kernel. The kernel stops after the memory manager
loads.
There are no errors or panics. The system just locks up. 
 
I was wondering if any of you have seen this problem, or know of a work
around. I am including the kernel output from the serial console. As
well as
a brief description of the configuration of the system.
 
Thanks for your help,
Matthew Simmons


 
Configuration:
----------------------------------------------
Tyan S2882 2x Opteron 248 Processors
1024mb Ram (512x per processor)
LinuxBIOSv2 (Revision 2084)
Kernel: 2.6.12.1 with the Realtime Preempt Patch
Base OS: SuSE 9.2
GCC version: 3.3.2
 
 
Serial Console Output: (Sorry for the length)
------------------------------------------------
LinuxBIOS-1.1.8_s2882_Fallback Fri Nov  4 12:47:40 CST 2005 starting...

(0,1) link=01             
(1,0) link=01             
02 nodes initialized.                     
SBLink=00         
NC node|link=00               
Ram1.00       
Ram1.01       
Ram2.00       
Ram2.01       
Ram3    
Initializing memory:  done                          
Initializing memory:  done                          
Clearing initial memory region:  done

Ram4    
Copying LinuxBIOS to ram.                         
Jumping to LinuxBIOS.                     
LinuxBIOS-1.1.8_s2882_Fallback Fri Nov  4 12:47:40 CST 2005 booting...

Enumerating buses...                    
APIC_CLUSTER: 0 enabled                       
PCI_DOMAIN: 0000 enabled                        
CPU: APIC: 10 enabled                     
PCI: 00:19.0 [1022/1100] enabled                                
PCI: 00:19.1 [1022/1101] enabled                                
PCI: 00:19.2 [1022/1102] enabled                                
PCI: 00:19.3 [1022/1103] enabled                                
CPU: APIC: 11 enabled                     
PCI: pci_scan_bus for bus 0                           
PCI: 00:18.0 [1022/1100] enabled                                
PCI: 00:18.1 [1022/1101] enabled                                
PCI: 00:18.2 [1022/1102] enabled                                
PCI: 00:18.3 [1022/1103] enabled                                
PCI: 00:19.0 [1022/1100] enabled                                
PCI: 00:19.1 [1022/1101] enabled                                
PCI: 00:19.2 [1022/1102] enabled                                
PCI: 00:19.3 [1022/1103] enabled                                
PCI: 01:00.0 [1022/7450] en                          
PCI: 01:01.0 [1022/7450] enabled next_unitid: 0003

PCI: 01:00.0 [1022/7460] enabled                                
PCI: 01:03.0 [1022/7460] enabled next_unitid: 0007

PCI: pci_scan_bus for bus 1                           
PCI: 01:01.0 [1022/7450] enabled                                
PCI: 01:01.1 [1022/7451] enabled                                
PCI: 01:02.0 [1022/7450] enabled                                
PCI: 01:02.1 [1022/7451] enabled                                
PCI: 01:03.0 [1022/7460] enabled                                
PCI: 01:04.0 [1022/7468] enabled                                
PCI: 01:04.1 [1022/7469] enabled                                
PCI: 01:04.2 [1022/746a] enabled                                
PCI: 01:04.3 [1022/746b] enabled                                
PCI: pci_scan_bus for bus 2                           
Disabling static device: PCI: 0                              
Disabling static device: PCI: 02:06.1

PCI: 02:09.0 [14e4/1648] enabled                                
PCI: 02:09.1 [14e4/1648] enabled                                
PCI: pci_scan_bus returning with max=02

PCI: 02: 100MHz PCI-X                     
PCI: pci_scan_bus for bus 3                           
PCI: 03:04.0 [10ee/3fc6] enabled                                
PCI: pci_scan_bus returning with max=03

PCI: 03: Conventional PCI                         
PCI: pci_scan_bus for bus 4                           
PCI: 04:00.0 [1022/7464] enabled                                
PCI: 04:00.1 [1022/7464] enabled                                
PCI: 04:05.0 [1095/3114] enabled                                
PCI: 04:06.0 [1002/4752] enabled                                
PCI: 04:08.0 [8086/1229] enabled                                
PCI: pci_scan_bus returning with m                                
PNP: 002e.0 enabled                   
PNP: 002e.1 disabled                    
PNP: 002e.2 enabled                   
PNP: 002e.3 disabled                    
PNP: 002e.5 enabled                   
PNP: 002e.6 disabled                    
PNP: 002e.7 disabled                    
PNP: 002e.8 disabled                    
PNP: 002e.9 disabled                    
PNP: 002e.a disabled                    
PNP: 002e.b enabled                   
PCI: pci_scan_bus returning with max=04

PCI: pci_scan_bus returning with max=04

done    
Allocating resources...                       
Reading resources...                    
PCI: 01:01.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 2 io

PCI: 01:01.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 2
prefmem

PCI: 01:02.0 1c <- [0x00fffff00                              
PCI: 01:02.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 3
prefmem
map page: 16ee: 118                          
Cannot map page: 16f       
PCI: 01:03.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 4 prefmem

Cannot map pag              
Cannot map p
Done reading resources.        
Cannot map pag
Allocating VGA resource PCI: 04:06.0                             
Cannot
Setting PCI_BRIDGE_CTL_VGA for bridge PCI: 01:03.0 map page: 174xtra
MTRR'sd
<                      
Setting PCI_BRIDGE_CTL_VGA for bridge PCI: 00:18.0  
Cannot map          
Cannot map page: 176      
Setting PCI_BRIDGE_CTL_VGA for bridge PCI_DOMAIN: 0000            

Cannot map page: 178 page: 14b          
Setting PCI_BRIDGE_CTL_VGA for bridge Root Devicep page: 14c

Setting resources...7a                  
PCI: 00:18.0 1b8 <- [0x00fd400000 - 0x00fd3fffff] prefmem <node 0 link
0>

Cannot map page:                
Cannot map page: 17d   
PCI: 01:02.1 10 <- [0x00fd301000 - 0x00fd301fff] mem64map page: 17

Cannot map page: 1a8  
PCI: 01:03.0 1c <- [0x0000001000 - 0x0000001fff] bus 4 io page: 18

Cannot map page: 1
PCI: 01:03.0 20 <- [0x00fc000000 - 0x00fd0fffff] bus 4 memge: 191

Cannot map page: 1acnot
PCI: 04:00.0 10 <- [0x00fd020000 - 0x00fd020fff] meme: 1ading f

Cannot map page
PCI: 04:00.1 10 <- [0x00fd021000 - 0x00fd021fff] mem  
Cannot map page: 1aft map                        
PCI: 04:05.0 10 <- [0x0000001450 - 0x0000001457] ioCann    
Cannot map page: 1b1age: 19566e: 124M, W  
PCI: 04:05.0 14 <- [0x0000001470 - 0x0000001473] ioge: 1b

Cannot map page: 1bcot ma
PCI: 04:05.0 18 <- [0x0000001460 - 0x0000001467] ioot map page: 1bdot
map

Ca
PCI: 04:05.0 1c <- [0x00000014                        
   
PNP: 002e.0 70 <- [0x0000000006 - 0x0000000006] irq     
Cannot map page: 1de                    
Cann
PNP: 002e.0 74 <- [0x0000000002 - 0x0000000002] drq           
P 
C 
Can   

-Cannot map page: 1e0t ma
PNP: 002e.2 60 <- [0x00000003f8 - 0x00000003ff] ionot map page: 1e1

Cannot ma   
PNP: 002e.2 70 <- [0x0000000004 - 0x0000000004] irqo     
Cannot map page: 1e3ot map page: 1ca        
PNP: 002e.5 60 <- [0x0000000060 - 0x0000000060] io                  


Cannot map page: 1f4         
PNP: 002e.5 62 <- [0x0000000064 - 0x0000000064] io              
Cannot      
Cannot map page: 1f6  
PNP: 002e.5 70 <- [0x0000000001 - 0x0000000001] irq: 1f7

Cannot m        
Cannot m
PNP: 002e.5 72 <- [0x000000000c - 0x000000000c] irq                    
Cannot map page: 1f9Cannot map
PNP: 002e.b 60 <- [0x0000000290 - 0x0000000297] ioage: 1faage: 1ee

Canno
PNP: 002e.b 70 <- [0x0000000005 - 0x0000000005] irq

Cannot map page            
PNP: 002e.5 init        
PCI: 01:01.1 cmd <- 146b i             
NB: Fu
PCI: 01:02.0 bridge ctrl <- 0003                               

PCI: 01:02.0 cmd <- 1460ot ma                 
PCI: 03:04.0 cmd <- 142.0 init                
PCI: 01:02.1 subsystem <- 10f1/2882    
PNP: 002e.0 initd             
PCI: 01:02.1 cmd <- 146 tables to 0xf0000...do
PCI: 01:03.0 bridge ctrl <- 000b                                
PCI: 01:03.0 cmd <- 147ng copy of IRQ routing 
PCI: 04:00.0 subsystem <- 10f1/2882                                   
PCI: 04:00.0 cmd <- 142PCI: 00:19.1 init:06.0 
PCI: 04:00.1 subsystem <- 10f1/2882RQ routing table consistency...PCI:
PCI: 04:00.1 cmd <- 142                       
PCI: 04:05.0 subsystem <- 10f1/2882 
check_pirq_routing_table() - irq_
PCI: 04:05.0 cmd <- 143: 0x000f00sc Control.. 
PCI: 04:06.0 subsystem <- 10f1/2882                                   
PCI: 04:06.0 cmd <- 1c3         
           

    33:stre
PCI: 01:04.1 cmd <- 1410xfffe0000 - 0xfffe6fff
PCI: 01:04.2 subsystem <- 10f1/2882                            
Found 
PCI: 01:04.2 cmd <- 141                       
PCI: 01:04.3 subsystem <- 10f1/2882                      
Loading Ethe
PCI: 01:04.3 cmd <- 141                       
PCI: 00:18.1 subsystem <- 10f1/2882ing non PT_LOAD segment            
PCI: 00:18.1 cmd <- 140ot 5.2.6 (GPL) http://e
PCI: 00:18.2 subsystem <- 10f1/2882 hda4:/boot/vmlinuz initrd=/boot/in
PCI: 00:18.2 cmd <- 140ons                    
PCI: 00:18.3 cmd <- 140                       
PCI: 00:19.0 cmd <- 140                       
PCI: 00:19.1 cmd <- 140                       
hda: LBA48: HDS7280
Initializing CPU #0                 


CPU: vendor AMD device f5aack Fri Nov  4 13:59:37 CS
Enabling cache...           

Setting fixed MTRRs(0-88) type: UC                        
Found Lin
Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM

(0,1) link=01host) #
Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM       
02 nodes initialized.                    
DONE fixed MTRRsSBLink=00and lin
Setting variable MTRR 0, base:    0MB, range: 1024MB, type WB

ht reset -canning NU                    



DONE variable MTRRs2_Fallback Fri Nov 
Clear out the extra MTRR'sng...                     

MTRR check          
Fixed MTRRs   : Enabled    
Linux version     
Variable MTRRs: Enabledeko at buildho            

Setting up local apic..=01on 3               
Copying Lin
Enabling cachepe 16         

Setting fixed MTRRs(0-88) type: UCnuxBIOS.                     
 BIO
Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM4 13:59:37 CST 2005
booting...                  
Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM  
 BIOS-e820: 00000000000f0000 - 000            
DONE fixed MTRRs     
Enumeratin
Setting variable MTRR 0, base:    0MB, range: 1024MB, type WB

Scanning NU           
PCI_DOMAIN: 0000 enabl
DONE variable MTRRs              
CPU:
Clear out the extra MTRR's 0000000000               

MTRR check          
Fixed MTRRs   : Enabled/11                    
PCI: 00:19.1 [10
All AP CPUs stopped                   
PCI: 00:18.0 initr #17 INVAL      
PCI: 01:01.0 init 00:19.2 [1022/11
PCI: 02:09.0 init                 
PCI: 02:09.1 init#1           
PCI
PCI: 01:02.0 init03] enabled      
PCI: 01:03.0 init        
I 
PCI: 
PCI: 04:05.0 init] enabled00.     
PCI: 04:06.0 init            
PCI:
rom address for PCI: 04:06.0 = fff80000: 0003

Incorrect Expansion ROM Header Signature 457fCI: 01:00.0 [1022/7460]
enabled

PCI: 04:08.0 init
CPU 0: apertur  
PCI: 01:04.0 init01:03.0 [1022/746
RTC Initd next_u
Invalid CMOS LB checksum                        
enabling HPET @0xf                 
PCI: 00:18.2 init                 
PCI: 00:18.3 initstatic device: PC
NB: Function 3 Misc Control.. done.           
Inode-cache hash table 
PCI: 00:19.0 init               
D
PCI: 00:19.1 initvice: PCI: 02:06.
PCI: 00:19.2 init                 
PCI: 00:19.3 init14e4/1648] enable
NB: Function 3 Misc Control.. done.                                   
PCI: 03:04.0 init        
PCI: 02:
Devices initializedbledk data, 220k in
Copying IRQ routing tables to 0xf0000...done.       
PCI: pci_scan_bus returning with max=
Wrote the mp table end at: 00000020 - 00000214
Moving GDT to 0x500...ok
Wrote linuxbios table at: 00000530 - 00000de4  checksum 9515

Welcome to elfboot, the open sourced starter.
January 2002, Eric Biederman.
Version 1.3

    33:stream_init() - rom_stream: 0xfffe0000 - 0xfffe6fff
Found ELF candiate at offset 0
Loading Etherboot version: 5.2.6
Dropping non PT_LOAD segment
New segment addr 0x20000 size 0x312bd offset 0xb0 filesize 0x6c5b
(cleaned up) New segment addr 0x20000 size 0x312bd offset 0xb0 filesize
0x6c5b
Loading Segment: addr: 0x000000003ff90000 memsz: 0x000000000002a000
filesz:
0x0000000000006c5b
Clearing Segment: addr: 0x000000003ff96c5b memsz: 0x00000000000233a5
Loading Segment: addr: 0x000000000004a000 memsz: 0x00000000000072bd
filesz:
0x0000000000000000
Clearing Segment: addr: 0x000000000004a000 memsz: 0x00000000000072bd
Jumping to boot code at 0x20000
ROM segment 0x0000 length 0x0000 reloc 0x00020000
CPU 2056 Mhz
Etherboot 5.2.6 (GPL) http://etherboot.org Tagged ELF for [FILO]
Relocating _text from: [00026c60,00052870) to [3fed43f0,3ff00000)
Boot from (N)etwork (D)isk or (Q)uit?

Probing pci disk...it() - ro
Int BIOS-e820: 00000000000f0000 - 00000000000f0400 type 16i Nov  4
13:57:25
C
Virtual Wire compatibility mode
BIOS-e820: 0000000000100000 - 0000000040000000 (usable)>Product ID:
S2882
<6>APIC at: 0xFEE00000hda4 con
Scanning NUMA topology in Northbridge 24toppe
New segment
Virtual Wire compatibility mode.
OEM ID: TYAN     <6>Product ID: S2882        <6>APIC at: 0xFEE00000
Processor #16 15:5 APIC version 16
Processor #17 15:5 APIC version 16
Processor #17 INVALID. (Max ID: 16).
I/O APIC #1 Version 17 at 0xFEC00000.
I/O APIC #2 Version 17 at 0xFD300000.
I/O APIC #3 Version 17 at 0xFD301000.
Processors: 2
Checking aperture...
CPU 0: aperture @ f8000000 size 64 MB
CPU 1: aperture @ f8000000 size 64 MB
Built 2 zonelists
Kernel command line: ro root=/dev/hda4 console=ttyS0,115200
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 131072 bytes)
time.c: Using 1.193182 MHz PIT timer.
time.c: Detected 1990.814 MHz processor.
Console: colour dummy device 80x25
Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Memory: 1023436k/1048576k available (2452k kernel code, 0k reserved,
942k
data,
220k init)


-- 
LinuxBIOS mailing list
LinuxBIOS at openbios.org
http://www.openbios.org/mailman/listinfo/linuxbios





From okajima at digitalinfra.co.jp  Sat Nov  5 05:39:21 2005
From: okajima at digitalinfra.co.jp (Jun OKAJIMA)
Date: Sat, 05 Nov 2005 13:39:21 +0900
Subject: [LinuxBIOS] EPIA-M fails for me.
Message-ID: <200511050439.AA00422@bbb-jz5c7z9hn9y.digitalinfra.co.jp>


Hello.

I just patched 2084 src tree with Nick Barker's EPIA-M patch, but failed.
Give me advise!.

The patch I used is this.
http://openbios.org/pipermail/linuxbios/2005-October/012723.html
http://openbios.org/pipermail/linuxbios/attachments/20051028/2d3ed7d9/epia-m.patch-0001.gz
The src is this.
http://snapshots.linuxbios.org/LinuxBIOSv2-2084.tar.bz2

What I did is like this.
$ tar -xvzf Linuxbios...
$ patch -p1
$ ./buildtarget epia-m
$ make
  ( failed!)

              --- Okajima, Jun. Tokyo, Japan.

--------------
_BASE='0xffff0000' -DCONFIG_UDELAY_TSC='1' -DCONFIG_TSC_X86RDTSC_CALIBRATE_WITH_TIMER2='0' -Os -
nostdinc -nostdlib -fno-builtin  -Wall -o model_centaur_init.o /home/okajima/lx2/LinuxBIOSv2-
2084/src/cpu/via/model_centaur/model_centaur_init.c
/home/okajima/lx2/LinuxBIOSv2-2084/src/cpu/via/model_centaur/model_centaur_init.c:29: warning: 
#warning "FIXME - need correct cpu id here for VIA C3"
cc1: Invalid option `32'
/home/okajima/lx2/LinuxBIOSv2-2084/src/cpu/via/model_centaur/model_centaur_init.c:45: warning: 
`used' attribute directive ignored
/home/okajima/lx2/LinuxBIOSv2-2084/src/cpu/via/model_centaur/model_centaur_init.c:45: warning: 
`driver' defined but not used
make[1]: *** [model_centaur_init.o] Error 1
make[1]: Leaving directory `/home/okajima/lx2/LinuxBIOSv2-2084/targets/via/epia-m/epia-m/fallback'
make: *** [fallback/linuxbios.rom] Error 1
okajima at Debian:~/lx2/LinuxBIOSv2-2084/targets/via/epia-m/epia-m$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
gcc version 2.95.4 20011002 (Debian prerelease)
okajima at Debian:~/lx2/LinuxBIOSv2-2084/targets/via/epia-m/epia-m$ as --version
GNU assembler 2.12.90.0.1 20020307 Debian/GNU Linux
Copyright 2002 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License.  This program has absolutely no warranty.
This assembler was configured for a target of `i386-linux'.
okajima at Debian:~/lx2/LinuxBIOSv2-2084/targets/via/epia-m/epia-m$





From d0wnl0ad at freemail.hu  Sat Nov  5 06:41:51 2005
From: d0wnl0ad at freemail.hu (d0wnl0ad3r d0wnl0ad3r)
Date: Sat, 5 Nov 2005 06:41:51 +0100 (CET)
Subject: [LinuxBIOS] ASUS P4R8L motherboard
Message-ID: <freemail.20051005064151.92774@fm03.freemail.hu>

Hi all!
I would like to ask you is it possible to use linuxbios on
ASUS P4R8L motherboard (in ASUS Pundit-R)?
Thank you for your help in advance,
Gabor

PS: the output of lspci -v:

0000:00:00.0 Host bridge: ATI Technologies Inc: Unknown
device 5833 (rev 02)
        Subsystem: Asustek Computer, Inc.: Unknown device 8107
        Flags: bus master, 66MHz, medium devsel, latency 64
        Memory at f0000000 (32-bit, prefetchable) [size=128M]
        Memory at eff00000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [a0] AGP version 3.0

0000:00:01.0 PCI bridge: ATI Technologies Inc: Unknown
device 5838 (prog-if 00 [Normal decode])
        Flags: bus master, 66MHz, medium devsel, latency 64
        Bus: primary=00, secondary=01, subordinate=01,
sec-latency=64
        I/O behind bridge: 0000d000-0000dfff
        Memory behind bridge: fd900000-fdcfffff
        Prefetchable memory behind bridge: cfe00000-efdfffff

0000:00:13.0 USB Controller: ATI Technologies Inc: Unknown
device 4347 (rev 01) (prog-if 10 [OHCI])
        Subsystem: Asustek Computer, Inc.: Unknown device 8108
        Flags: bus master, 66MHz, medium devsel, latency 64,
IRQ 177
        Memory at fe900000 (32-bit, non-prefetchable) [size=4K]

0000:00:13.1 USB Controller: ATI Technologies Inc: Unknown
device 4348 (rev 01) (prog-if 10 [OHCI])
        Subsystem: Asustek Computer, Inc.: Unknown device 8108
        Flags: bus master, 66MHz, medium devsel, latency 64,
IRQ 177
        Memory at fea00000 (32-bit, non-prefetchable) [size=4K]

0000:00:13.2 USB Controller: ATI Technologies Inc: Unknown
device 4345 (rev 01) (prog-if 20 [EHCI])
        Subsystem: Asustek Computer, Inc.: Unknown device 8108
        Flags: bus master, 66MHz, medium devsel, latency 64,
IRQ 177
        Memory at feb00000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [dc] Power Management version 2

0000:00:14.0 SMBus: ATI Technologies Inc ATI SMBus (rev 18)
        Subsystem: Asustek Computer, Inc.: Unknown device 8108
        Flags: 66MHz, medium devsel
        I/O ports at 0a00 [size=16]
        Memory at 18000000 (32-bit, non-prefetchable) [size=1K]

0000:00:14.1 IDE interface: ATI Technologies Inc: Unknown
device 4349 (prog-if 8a [Master SecP PriP])
        Subsystem: Asustek Computer, Inc.: Unknown device 8108
        Flags: bus master, medium devsel, latency 0, IRQ 185
        I/O ports at <ignored>
        I/O ports at <ignored>
        I/O ports at <ignored>
        I/O ports at <ignored>
        I/O ports at ff00 [size=16]

0000:00:14.3 ISA bridge: ATI Technologies Inc: Unknown
device 434c
        Subsystem: Asustek Computer, Inc.: Unknown device 8108
        Flags: bus master, 66MHz, medium devsel, latency 0

0000:00:14.4 PCI bridge: ATI Technologies Inc: Unknown
device 4342 (prog-if 01 [Subtractive decode])
        Flags: bus master, 66MHz, medium devsel, latency 64
        Bus: primary=00, secondary=02, subordinate=03,
sec-latency=64
        I/O behind bridge: 00001000-0000efff
        Memory behind bridge: fdd00000-fe2fffff

0000:00:14.5 Multimedia audio controller: ATI Technologies
Inc IXP150 AC'97 Audio Controller
        Subsystem: Asustek Computer, Inc.: Unknown device 810d
        Flags: bus master, 66MHz, slow devsel, latency 64,
IRQ 193
        Memory at fe800000 (32-bit, non-prefetchable) [size=256]

0000:01:05.0 VGA compatible controller: ATI Technologies
Inc: Unknown device 5834 (prog-if 00 [VGA])
        Subsystem: Asustek Computer, Inc.: Unknown device 8107
        Flags: bus master, 66MHz, medium devsel, latency 64,
IRQ 185
        Memory at d0000000 (32-bit, prefetchable) [size=256M]
        I/O ports at d000 [size=256]
        Memory at fdc00000 (32-bit, non-prefetchable) [size=64K]
        Expansion ROM at fdb00000 [disabled] [size=128K]
        Capabilities: [58] AGP version 3.0
        Capabilities: [50] Power Management version 2

0000:02:08.0 Ethernet controller: 3Com Corporation 3Com
3C920B-EMB-WNM Integrated Fast Ethernet Controller (rev 40)
        Subsystem: Asustek Computer, Inc.: Unknown device 8108
        Flags: bus master, medium devsel, latency 64, IRQ 201
        I/O ports at ec00 [size=128]
        Memory at fe200000 (32-bit, non-prefetchable) [size=128]
        Expansion ROM at fe100000 [disabled] [size=128K]
        Capabilities: [dc] Power Management version 2

0000:02:0a.0 FireWire (IEEE 1394): VIA Technologies, Inc.
IEEE 1394 Host Controller (rev 80) (prog-if 10 [OHCI])
        Subsystem: Asustek Computer, Inc.: Unknown device 808a
        Flags: bus master, medium devsel, latency 64, IRQ 201
        Memory at fdf00000 (32-bit, non-prefetchable) [size=2K]
        I/O ports at e880 [size=128]
        Capabilities: [50] Power Management version 2

0000:02:0c.0 CardBus bridge: ENE Technology Inc CB710
Cardbus Controller (rev 02)
        Subsystem: ENE Technology Inc CB710 Cardbus Controller
        Flags: bus master, medium devsel, latency 168, IRQ 185
        Memory at 18001000 (32-bit, non-prefetchable) [size=4K]
        Bus: primary=02, secondary=03, subordinate=06,
sec-latency=176
        Memory window 0: 18400000-187ff000 (prefetchable)
        Memory window 1: 18800000-18bff000
        I/O window 0: 00004000-000040ff
        I/O window 1: 00004400-000044ff
        16-bit legacy interface ports at 0001

0000:02:0c.1 FLASH memory: ENE Technology Inc CB710 Memory
Card Reader Controller
        Subsystem: ENE Technology Inc CB710 Memory Card
Reader Controller
        Flags: medium devsel, IRQ 177
        I/O ports at e800 [size=128]
        Capabilities: [a0] Power Management version 2




_____________________________________________________________________
Angolul tanulna, de nincs ideje r??  Pr?b?lja ki a levelez? m?dszert.
Hanganyag CD-n vagy kazett?n. www.elo.hu/free





From stepan at openbios.org  Sat Nov  5 12:06:10 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Sat, 5 Nov 2005 12:06:10 +0100
Subject: [LinuxBIOS] EPIA-M fails for me.
In-Reply-To: <200511050439.AA00422@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
References: <200511050439.AA00422@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
Message-ID: <20051105110610.GA32715@openbios.org>

* Jun OKAJIMA <okajima at digitalinfra.co.jp> [051105 05:39]:
> 
> Hello.
> 
> I just patched 2084 src tree with Nick Barker's EPIA-M patch, but failed.
> Give me advise!.
 
Your C compiler does not support the -m32 option. You might try to
remove that from the config file. Or, even better, update to a newer GCC
version (ie 3.3.x)

> The patch I used is this.
> http://openbios.org/pipermail/linuxbios/2005-October/012723.html
> http://openbios.org/pipermail/linuxbios/attachments/20051028/2d3ed7d9/epia-m.patch-0001.gz
> The src is this.
> http://snapshots.linuxbios.org/LinuxBIOSv2-2084.tar.bz2
> 
> What I did is like this.
> $ tar -xvzf Linuxbios...
> $ patch -p1
> $ ./buildtarget epia-m
> $ make
>   ( failed!)
> 
>               --- Okajima, Jun. Tokyo, Japan.
> 
> --------------
> _BASE='0xffff0000' -DCONFIG_UDELAY_TSC='1' -DCONFIG_TSC_X86RDTSC_CALIBRATE_WITH_TIMER2='0' -Os -
> nostdinc -nostdlib -fno-builtin  -Wall -o model_centaur_init.o /home/okajima/lx2/LinuxBIOSv2-
> 2084/src/cpu/via/model_centaur/model_centaur_init.c
> /home/okajima/lx2/LinuxBIOSv2-2084/src/cpu/via/model_centaur/model_centaur_init.c:29: warning: 
> #warning "FIXME - need correct cpu id here for VIA C3"
> cc1: Invalid option `32'
> /home/okajima/lx2/LinuxBIOSv2-2084/src/cpu/via/model_centaur/model_centaur_init.c:45: warning: 
> `used' attribute directive ignored
> /home/okajima/lx2/LinuxBIOSv2-2084/src/cpu/via/model_centaur/model_centaur_init.c:45: warning: 
> `driver' defined but not used
> make[1]: *** [model_centaur_init.o] Error 1
> make[1]: Leaving directory `/home/okajima/lx2/LinuxBIOSv2-2084/targets/via/epia-m/epia-m/fallback'
> make: *** [fallback/linuxbios.rom] Error 1
> okajima at Debian:~/lx2/LinuxBIOSv2-2084/targets/via/epia-m/epia-m$ gcc -v
> Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
> gcc version 2.95.4 20011002 (Debian prerelease)
> okajima at Debian:~/lx2/LinuxBIOSv2-2084/targets/via/epia-m/epia-m$ as --version
> GNU assembler 2.12.90.0.1 20020307 Debian/GNU Linux
> Copyright 2002 Free Software Foundation, Inc.
> This program is free software; you may redistribute it under the terms of
> the GNU General Public License.  This program has absolutely no warranty.
> This assembler was configured for a target of `i386-linux'.
> okajima at Debian:~/lx2/LinuxBIOSv2-2084/targets/via/epia-m/epia-m$
> 
> 
> 
> -- 
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
> 



From rminnich at lanl.gov  Sat Nov  5 17:07:13 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Sat, 05 Nov 2005 09:07:13 -0700
Subject: [LinuxBIOS] ASUS P4R8L motherboard
In-Reply-To: <freemail.20051005064151.92774@fm03.freemail.hu>
References: <freemail.20051005064151.92774@fm03.freemail.hu>
Message-ID: <436CD8B1.2080301@lanl.gov>

those ATI bridges are news to me. Can you get docs?

ron



From stepan at openbios.org  Sun Nov  6 22:07:10 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Sun, 6 Nov 2005 22:07:10 +0100
Subject: [LinuxBIOS] get_apicid_base unresolved?
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4201E061FD@ssvlexmb2.amd.com>
Message-ID: <20051106210710.GA4179@openbios.org>

* Lu, Yinghai <yinghai.lu at amd.com> [051103 18:41]:
> Please check my patch 1025_enable_CAR_init_cpus_get_apicid_base.diff
> that I sent out 10/26. I will check that in and populate that to
> s2891....

Shall we enable this for all Opteron platforms?

Stefan




From yinghailu at gmail.com  Sun Nov  6 22:31:59 2005
From: yinghailu at gmail.com (yhlu)
Date: Sun, 6 Nov 2005 13:31:59 -0800
Subject: [LinuxBIOS] get_apicid_base unresolved?
In-Reply-To: <20051106210710.GA4179@openbios.org>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4201E061FD@ssvlexmb2.amd.com>
	<20051106210710.GA4179@openbios.org>
Message-ID: <2ea3fae10511061331g1b55b0e7j9aef1b06b78d18a2@mail.gmail.com>

I'm OK. I need make sure Tyan MB user happy. then I will change other MBs
such as aruma and hadma..
 YH

 On 11/6/05, Stefan Reinauer <stepan at openbios.org> wrote:
>
> * Lu, Yinghai <yinghai.lu at amd.com> [051103 18:41]:
> > Please check my patch 1025_enable_CAR_init_cpus_get_apicid_base.diff
> > that I sent out 10/26. I will check that in and populate that to
> > s2891....
>
> Shall we enable this for all Opteron platforms?
>
> Stefan
>
>
> --
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20051106/e55142e6/attachment.html>

From okajima at digitalinfra.co.jp  Sun Nov  6 22:45:55 2005
From: okajima at digitalinfra.co.jp (Jun OKAJIMA)
Date: Mon, 07 Nov 2005 06:45:55 +0900
Subject: [LinuxBIOS] EPIA-M VGA
Message-ID: <200511062145.AA00448@bbb-jz5c7z9hn9y.digitalinfra.co.jp>



I also have another problem: VGA does not work *USUALLY*.
I mean, I have seen several times that VGA works, but in most cases, does not.
And, I can not understand what is the difference.
I did some experiment, like turning off power, not pushing reset button,
or once you boot it with normal bios, and then switch to LX, or....
But, I have not found any rule so far. Why it sometimes works? Umm..

                      --- Okajima, Jun. Tokyo, Japan.




From okajima at digitalinfra.co.jp  Sun Nov  6 22:45:50 2005
From: okajima at digitalinfra.co.jp (Jun OKAJIMA)
Date: Mon, 07 Nov 2005 06:45:50 +0900
Subject: [LinuxBIOS] EPIA-M slow
Message-ID: <200511062145.AA00447@bbb-jz5c7z9hn9y.digitalinfra.co.jp>



Hello.

First, it booted finally. Thanks a lot.
But, one problem. it takes long time to boot.
it is very fast once booting is start, even with debugging enabled.
But, before it, there is long wait.
I mean, wait until a message below comes.

(push reset button)
(wait, wait, wait,,,,   WAIT..... zzzz....   Maybe more than 10 sec!)
LinuxBIOS-1.1.8.0Fallback Sun Nov  6 07:39:08 UTC 2005 starting...
 Enabling mainboard devices
 Enabling shadow ram
(after this, very fast.)

Any help?
I used this patch also. Maybe this is a cause? But, without this, it does 
not work.
http://www.openbios.org/pipermail/linuxbios/2005-November/012736.html

                   --- Okajima, Jun. Tokyo, Japan.

------------
My env:
H/W : EPIA-MII 1.2GHz
      Mem: Single side DDR. 512MB PC3200 CL3 SAMSUNG.
S/W : Debian Sid.
root at Debian:/# gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --enable-
languages=c,c++,java,f95,objc,ada,treelang --
prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --
without-included-gettext --
enable-threads=posix --enable-nls --program-suffix=-4.0 --enable-
__cxa_atexit --enable-libstdcxx-
allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-
gc=boehm --enable-java-
awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-
4.0-1.4.2.0/jre --enable-
mpfr --disable-werror --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.0.3 20051023 (prerelease) (Debian 4.0.2-3)
root at Debian:/# as --version
GNU assembler 2.16.91 20050902 Debian GNU/Linux
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License.  This program has absolutely no warranty.
This assembler was configured for a target of `i486-linux-gnu'.




From okajima at digitalinfra.co.jp  Mon Nov  7 01:29:53 2005
From: okajima at digitalinfra.co.jp (Jun OKAJIMA)
Date: Mon, 07 Nov 2005 09:29:53 +0900
Subject: [LinuxBIOS] EPIA-M VGA
In-Reply-To: <200511062145.AA00448@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
References: <200511062145.AA00448@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
Message-ID: <200511070029.AA00451@bbb-jz5c7z9hn9y.digitalinfra.co.jp>

And the log of failure session is this.
I dont have success one, sorry.

These lines are same as yours?

 > VGA random fixup ...
 > INSTALL REAL-MODE IDT
 > DO THE VGA BIOS
 > found VGA: vid=1106, did=3122
 > rom base, size: fffc0000
 > BAD SIGNATURE 0x8 0x1e
 > biosint: # 0x10, eax 0x4f14 ebx 0x18003 ecx 0x1 edx 0x0
 > biosint: ebp 0x17fa0 esp 0xffa edi 0x0 esi 0x187c8
 > biosint: ip 0xb565 cs 0x0 flags 0x46
 > BIOSINT: Unsupport int #0x10

                         --- Okajima, Jun. Tokyo, Japan.

------------
LinuxBIOS-1.1.8.0Fallback Sun Nov  6 07:39:08 UTC 2005 starting...
 Enabling mainboard devices
 Enabling shadow ram
vt8623 init starting
Detecting Memory
Number of Banks 04
Number of Rows 0d
Priamry DRAM width08
No Columns 0b
MA type e0
Bank 0 (*16 Mb) 20
No Physical Banks 01
Total Memory (*16 Mb) 20
CAS Supported 2.5 3
Cycle time at CL X     (nS)50
Cycle time at CL X-0.5 (nS)60
Cycle time at CL X-1   (nS)00
Starting at CAS 3
We can do CAS 2.5
tRP 3c
tRCD 3c
tRAS 28
Low Bond 00  High Bondcc  Setting DQS delay88vt8623 done
00:06 11 23 31 06 00 30 22 00 00 00 06 00 00 00 00
10:08 00 00 d0 00 00 00 00 00 00 00 00 00 00 00 00
20:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30:00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00
40:00 18 88 80 82 44 00 00 18 99 88 80 82 44 00 00
50:c8 de cf 88 e0 07 00 00 e0 00 20 20 20 20 00 00
60:02 ff 00 30 62 32 01 20 42 2d 43 58 00 44 00 00
70:82 48 00 01 01 08 50 00 01 00 00 00 00 00 00 02
80:0f 6c 00 00 80 00 00 00 02 00 00 00 00 00 00 00
90:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0:02 c0 20 00 07 02 00 1f 04 00 00 00 2f 02 04 00
b0:00 00 00 00 80 00 00 00 88 00 00 00 00 00 00 00
c0:01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
d0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0:00 dd 00 00 00 00 01 00 40 00 00 00 00 00 00 00
f0:00 00 00 00 00 00 12 13 00 00 00 00 00 00 00 00
AGP
 Doing MTRR init.
Copying LinuxBIOram.
Jumping to LinuxBIOS.
LinuxBIOS-1.1.8.0Fallback Sun Nov  6 07:39:08 UTC 2005 booting...
clocks_per_usec: 2572
Enumerating buses...
Finiguration type.
PCI: Using conf_CLUSTER: 0 enabled
PCI: pci_scan_bus for bus 0
PCI: 00:00.0 [1106/3123]d
PCI: 00:01.0 [1106/b091] enabled0a.0
Disabling static device: PCI: 00:0a.1
PCI: 00:0d.0 [1106/3044] enabled
In vt8235_enable 1106 PCI: 00:10.0 [1106/3038] enabled0.1 [1106/3038] enabled
In vt8235_enable 1106 3038.
PCI: 00:10.2 [1106/3038] enabled
In vt8235_enable 1106 3104.
PCI: 00:10.3 [1106/3104] enabledIn vt8235_enable 1106 3177.
InitialisinPCI: 00:11.0 [1106/3177] enabled
In vt8235_enable 1106 0571.
PCI: 00:11.1 [1106/0571] enabledCI: 00:11.5 [1106/3059] enabled
In vt8235_enable ffff ffff.
In vt8235_enable 1106 3065.
PCI: 00:12.0 [1106/3065] enabled
PCI: pci_scan_bus for bus 1
PCI: 01:00.0 [1106/3122] enabled
PCI: pci_scan_bus returning with max=01
vt1211 enabld
vt1211 enabling PNP devices.
PNP: 002e.1 enabled
vt1211 enabling PNP devices.
PNP: 002e.2 enabled
vt1211 enabling PNP devices.
PNP: 002e.3 enabled
vt1211 enabling PNPled
PCI: pci_scan_bus returning with max=01
done
Allocating resources...
Reading resources...
Done reading resources.
Setting resources...
I would set ram size to 0x80000 Kbytes
0x00febfe000 - 0x00febfe7ff] mem
PCI: 00:0d.0 14 <- [0x0000001800 - 0x000000187f] io
PCI: 00:10.0 20 <- [0x0000001880 - 0x000000189f] io
PCI: 00:10.1 20 <- [0x00000018a0 - 0x00000018bf] io
PCI: 00:10.2 20 <- [0x00000018c0 - 0x00000018df] io
PCI: 00:10.3 10 <- [0x00febff000 - 0x00febff0ff] mem
PN[0x00000003f0 - 0x00000003f7] io
PNP: 002e.0 70 <- [0x0000000006 - 0x0000000006] irq
PNP: 002e.0 74 <- [0x0000000002 - 0x0000000002] drq
PNP: 002e.1 60 <- [0x0000000378 - 0x000000037f] io
PNP: 002e.1 70 <- [0x0000000007 - 0x0000000007] irq
PNP: 002e.1 74 <- [0x0000000003 - 0x0000000003] drq
PNP: 002e.2 60 <- [0x00000003f8 - 0x00000003ff] io
PNP: 002e.2 70 <- [0x000000000P: 002e.3 60 <- [0x00000002f8 - 0x00000002ff] io
PNP: 002e.3 70 <- [0x0000000003 - 0x0000000003] irq
PNP: 002e.b 60 <- [0x000000ec00 - 0x000000ecff] io
PCI: 00:11.1 20 <- [0x00000018e0 - 0x00000018ef] io
PCI: 00:11.5 10 <- [0x0000001000 - 0x00000010ff] io
PCI: 00:12.0 10 <- [0x0000001400 - 0x00000014ff] io
PCI: 00:12.000 - 0x00fec000ff] mem
Done setting resources.
Done allocating resources.
Enabling resourcess...
PCI: 00:00.0 cmd <- 146
PCI: 00:01.0 bridge ctrl <- 000f
PCI: 00:01.0 cmd <- 147
PCI: 01:00.0 cmd <- 140
PCI: 00:0d.0 cmd <- 1c3
PCI: 00:10.0 subsystem <- 00/00
PCI: 00:10.0 cmd <- 141
PCI: 00:10.1 subsystem <- 00/00
PCI: 00:10.1 cmd <- 141
P
PCI: 00:10.2 cmd <- 141
PCI: 00:10.3 subsystem <- 00/00
PCI: 00:10.3 cmd <- 142
PCI: 00:11.0 cmd <- 147
PNP: 002e.0 - enabling
PNP: 002e.1 - enabling
PNP: 002e.2 - enabling
PNP: 002e.3 - enabling
PNP: 002e.b - enabling
PCI: 00:11.1 cmd <- 147
PCI: 00:11.5 subsystem <- 00/00
PCI: 00:11.5 cmd141
PCI: 00:12.0 cmd <-
                   Initializing devices...
Root Dee init
PCI: 00:10.0 init
PCI: 00:10.1 init
PCI: 00:10.2 init
PCI: 00:10.3 init
PCI: 00:11.0 init
vt8235 init
RTC Init
RTC: Checksum invalid zeroing cmos
Invalid CMOS LB checksum
pci_routing_fixup: dev is 00010ac0
setting firewire
Assigning IRQ 9 to 0:d.0
  Readback = 9
setting usb
Assigning IRQ 5 to 0:10.0
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
Assigning IRQ 9 to 0:10.1
  Readback = 9
ning IRQ 9 to 0:10.2 order bits are wrong: want 0x0, got 0x20
  Readback 9
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
Assigning IRQ 5 to 0:10.3
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
setting vt8235
Assigning IRQ 5 to 0:11.1
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
Assigning IRQ 9 to 0:11.5
  Readback = 9
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
setting ethernet
Assigning IRQ 5 to 0:12.0
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
setting vga
Assigning IRQ 5 to 1:0.0
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
setting pci slot
g cardbus slot
setting riser slot
PNP: 002e.0 init
PNP: 002e.1 init
PNP: 002e.2PNP: 002e.3 init
PNP: 002e.b init
PCI: 00:11.1 init
Enabling VIA IDE.
ide_init: enabling compatibility IDE addresses
enables in reg 0x42 0x0
enables in reg 0x42 read back as 0x0
enables in reg 0x40 0x13
enables in reg 0x40 read back as 0x13
enables in reg 0x9 0x8a
enables in reg 0x9 read back as 0x8a
command in reg 0x4 0x7
command in reg 0x4 reads back as 0x7
PCI: 00:11.5 init
PCI: 00:12.0 init
Configuring VIA Rhine LAN
APIC_CLUSTER: 0 init
Initializing CPU #0
CPU: vendor Centaur device 698
Enabling cache

Setting fixed MTRRs(0-88) type: UC
Setting fixed MTRRs(0-16) Type: WB
Setting fixed MTRRs(24-88) Type: WB
DONE fixed MTRRs
Setting variable MTRR 0, base:    0MB, range:  256MB, type WB
Setting variable MTRR 1, base:  256MB, range:  128MB, type WB
Setting variable MTRR 2, base:   range:   64MB, type WB
Setting variable MTRR 3, base:  448MB, range:   32MB, type WB
DONE varie extra MTRR's

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

Disabling local apic...done.
CPU #0 Initialized
PCI: 00:00.0 init
VT8623 random fixup ...
Frame buffer at d0000000
PCI: 00:01.0 init
VT8623 AGP random fixup ...
PCI: 00:0d.0 init
PCI: 01:00.0 init
VGA random fixup ...
INSTALL REAL-MODE IDT
DO THE VGA BIOS
found VGA: vid=1106, did=3122
rom base, size: fffc0000
BAD SIGNATURE 0x8 0x1e
biosint: # 0x10, eax 0x4f14 ebx 0x18003 ecx 0x1 edx 0x0
biosint: ebp 0x17fa0 esp 0xffa edi 0x0 esi 0x187c8
biosint: ip 0xb565 cs 0x0 flags 0x46
BIOSINT: Unsupport int #0x10
Devices initialized
Copying IRQ routing tables to 0xf0000...done.
Verifing copy of IRQ routing tables at 0xf0000...done
Checking IRQ routing table consistency...
check_pirq_routing_table() - irq_routing_table located at: 0x000f0000
done.
ACPI: Writing ACPI tables at f0400...
ACPI:     * FACS
ACPI:     * DSDT @ 000f04aa Length 3f0
ACPI:     * FADT
ACPI: added table 1/8 Length now 40
ACPI: done.
Moving GDT to 0x500...ok
Wrote linuxbile at: 00000530 - 00000b60  checksum 828

Welcome to elfboot, the open sourced starter.
January 2002, Eric Biederman.
Version 1.3

    33:stream_ini - 0xfffeffff
Found ELF candiate at offset 0
New segment addr 0x100000 size 0x25390 offset 0xa0 filesize 0xb2e0
(cleaned up) New segment addr 0x100000 size 0x25390 offset 0xa0 filesize 0xb2e0
New segment addr 0x1253a0 size 0x60 offset 0xb380 filesize 0x60
(cleaned up) New segment addr 0x1253a0 size 0x60 offset 0xb380 filesize 0x60
Dropping non PT_LOAD segment
Loading Segment: addr: 0x0000000000100000 memsz: 0x0000000000025390 filesz: 0x000000000000b2e0
Clearing Segment: addr: 0x000000000010b2e0 memsz: 0x000000000001oading Segment: addr: 
0x00000000001253a0 memsz: 0x0000000000000060 filesz: 0x0000000000000060
Jumping to boot code at 0x108b4c
FILO version 0.4.2 (okajima at Debian) Sun Nov  6 04:49:41 UTC 2005Press <Enter> for default boot, or 
<Esc> for boot prompt... timed out
boot: hda1:/vmlinuz root=/dev/he=ttyS0,115200
IDE time out
Netected on IDE channel 0
boot: hda1:/vmlinuz root=/dev/hda1 console=tty0 console=ttyS0,115200



From okajima at digitalinfra.co.jp  Mon Nov  7 01:31:35 2005
From: okajima at digitalinfra.co.jp (Jun OKAJIMA)
Date: Mon, 07 Nov 2005 09:31:35 +0900
Subject: [LinuxBIOS] EPIA-M slow
In-Reply-To: <200511062145.AA00447@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
References: <200511062145.AA00447@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
Message-ID: <200511070031.AA00452@bbb-jz5c7z9hn9y.digitalinfra.co.jp>


This morning, booting is fast!
nothing has been changed, but booted fast!
Why???

>
>Hello.
>
>First, it booted finally. Thanks a lot.
>But, one problem. it takes long time to boot.
>it is very fast once booting is start, even with debugging enabled.
>But, before it, there is long wait.
>I mean, wait until a message below comes.
>
>(push reset button)
>(wait, wait, wait,,,,   WAIT..... zzzz....   Maybe more than 10 sec!)
>LinuxBIOS-1.1.8.0Fallback Sun Nov  6 07:39:08 UTC 2005 starting...
> Enabling mainboard devices
> Enabling shadow ram
>(after this, very fast.)
>
>Any help?
>I used this patch also. Maybe this is a cause? But, without this, it does 
>not work.
>http://www.openbios.org/pipermail/linuxbios/2005-November/012736.html
>
>                   --- Okajima, Jun. Tokyo, Japan.
>
>------------
>My env:
>H/W : EPIA-MII 1.2GHz
>      Mem: Single side DDR. 512MB PC3200 CL3 SAMSUNG.
>S/W : Debian Sid.
>root at Debian:/# gcc -v
>Using built-in specs.
>Target: i486-linux-gnu
>Configured with: ../src/configure -v --enable-
>languages=c,c++,java,f95,objc,ada,treelang --
>prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --
>without-included-gettext --
>enable-threads=posix --enable-nls --program-suffix=-4.0 --enable-
>__cxa_atexit --enable-libstdcxx-
>allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-
>gc=boehm --enable-java-
>awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-
>4.0-1.4.2.0/jre --enable-
>mpfr --disable-werror --enable-checking=release i486-linux-gnu
>Thread model: posix
>gcc version 4.0.3 20051023 (prerelease) (Debian 4.0.2-3)
>root at Debian:/# as --version
>GNU assembler 2.16.91 20050902 Debian GNU/Linux
>Copyright 2005 Free Software Foundation, Inc.
>This program is free software; you may redistribute it under the terms of
>the GNU General Public License.  This program has absolutely no warranty.
>This assembler was configured for a target of `i486-linux-gnu'.
>
>
>-- 
>LinuxBIOS mailing list
>LinuxBIOS at openbios.org
>http://www.openbios.org/mailman/listinfo/linuxbios
>



From smithbone at gmail.com  Mon Nov  7 06:11:15 2005
From: smithbone at gmail.com (Richard Smith)
Date: Sun, 6 Nov 2005 23:11:15 -0600
Subject: [LinuxBIOS] EPIA-M slow
In-Reply-To: <200511070031.AA00452@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
References: <200511062145.AA00447@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
	<200511070031.AA00452@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
Message-ID: <8a0c36780511062111x4ddcdf6fn7af801b254c6edef@mail.gmail.com>

> This morning, booting is fast!
> nothing has been changed, but booted fast!
> Why???

The power cycle perhaps?

Its been my experience that sometimes you can get northbridge(s) in a
very confused state and they do flaky things until you power cycle
them.

--
Richard A. Smith



From a.borisov at tesv.tmb.ru  Mon Nov  7 06:23:39 2005
From: a.borisov at tesv.tmb.ru (Anton Borisov)
Date: Mon, 7 Nov 2005 08:23:39 +0300
Subject: [LinuxBIOS] EPIA-M VGA
In-Reply-To: <200511062145.AA00448@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
References: <200511062145.AA00448@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
Message-ID: <20051107082339.2d1969ee.a.borisov@tesv.tmb.ru>

On Mon, 07 Nov 2005 06:45:55 +0900
Jun OKAJIMA <okajima at digitalinfra.co.jp> wrote:

> 
> 
> I also have another problem: VGA does not work *USUALLY*.
> I mean, I have seen several times that VGA works, but in most cases, does not.
> And, I can not understand what is the difference.
> I did some experiment, like turning off power, not pushing reset button,
> or once you boot it with normal bios, and then switch to LX, or....
> But, I have not found any rule so far. Why it sometimes works? Umm..

	Did you warm reboot your LX box? If so, then I faced with this bug either. Unfortunately all these scrapy logs were at the screen only (infinite printfs of registers and that's all) - the last thing I saw in minicom window was the ACPI message. 
	Cold reboot works just fine.


-- 
Sincerely, Anton Borisov



From talbotx at comcast.net  Mon Nov  7 07:08:35 2005
From: talbotx at comcast.net (Adam Talbot)
Date: Sun, 06 Nov 2005 22:08:35 -0800
Subject: [LinuxBIOS] status of Geode?
Message-ID: <436EEF63.4050202@comcast.net>

-linuxbios
I have an old 300MHz geode board I would like to get linuxbios on. There 
is nothing out on the web site about geode systems.  I remember that 
there was work being put into the geode...  Did that work ever finish? 
Does linuxbios now support the geode? 
-Adam



From rminnich at lanl.gov  Mon Nov  7 08:09:10 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 07 Nov 2005 00:09:10 -0700
Subject: [LinuxBIOS] EPIA-M VGA
In-Reply-To: <200511070029.AA00451@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
References: <200511062145.AA00448@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
	<200511070029.AA00451@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
Message-ID: <436EFD96.5000204@lanl.gov>

Jun OKAJIMA wrote:
> And the log of failure session is this.
> I dont have success one, sorry.
> 
> These lines are same as yours?
> 
>  > VGA random fixup ...
>  > INSTALL REAL-MODE IDT
>  > DO THE VGA BIOS
>  > found VGA: vid=1106, did=3122
>  > rom base, size: fffc0000
>  > BAD SIGNATURE 0x8 0x1e
>  > biosint: # 0x10, eax 0x4f14 ebx 0x18003 ecx 0x1 edx 0x0
>  > biosint: ebp 0x17fa0 esp 0xffa edi 0x0 esi 0x187c8
>  > biosint: ip 0xb565 cs 0x0 flags 0x46
>  > BIOSINT: Unsupport int #0x10


This confuses me. The BAD SIGNATURE IIRC means that there is no valid 
signature in the ROM image. So the VGA bios should not be run.

So where is that biosint call coming from if not vga? This makes no 
sense to me at all.

ron



From rminnich at lanl.gov  Mon Nov  7 08:10:38 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 07 Nov 2005 00:10:38 -0700
Subject: [LinuxBIOS] EPIA-M slow
In-Reply-To: <8a0c36780511062111x4ddcdf6fn7af801b254c6edef@mail.gmail.com>
References: <200511062145.AA00447@bbb-jz5c7z9hn9y.digitalinfra.co.jp>	<200511070031.AA00452@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
	<8a0c36780511062111x4ddcdf6fn7af801b254c6edef@mail.gmail.com>
Message-ID: <436EFDEE.1030507@lanl.gov>

Richard Smith wrote:

> Its been my experience that sometimes you can get northbridge(s) in a
> very confused state and they do flaky things until you power cycle
> them.

well, I would count via northbridges as sometimes flaky ...

ron



From rminnich at lanl.gov  Mon Nov  7 08:22:22 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 07 Nov 2005 00:22:22 -0700
Subject: [LinuxBIOS] status of Geode?
In-Reply-To: <436EEF63.4050202@comcast.net>
References: <436EEF63.4050202@comcast.net>
Message-ID: <436F00AE.6050407@lanl.gov>

Adam Talbot wrote:
> -linuxbios
> I have an old 300MHz geode board I would like to get linuxbios on. There 
> is nothing out on the web site about geode systems.  I remember that 
> there was work being put into the geode...  Did that work ever finish? 
> Does linuxbios now support the geode? 
> -Adam
> 

V1 still does. V2, I stopped working on as I ran out of time. It should 
be easy, however.

ron



From matt at glw.com  Mon Nov  7 18:13:49 2005
From: matt at glw.com (Matthew Simmons)
Date: Mon, 7 Nov 2005 11:13:49 -0600
Subject: [LinuxBIOS] S2882 Memory Hang
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4201E061FF@ssvlexmb2.amd.com>
Message-ID: <20051107171150.3245B434C9@mail.glw.com>

 I am having a little trouble locating the k8_secondart_stop function. Could
you point me in the right direction? I looked in
src/southbridge/amd/amd8111/ and in src/mainboard/tyan/s2882/ as well as
src/northbridge/amd/amdk8.

I have hard coded the apicid_base to 4.

Thanks for your help,
Matt

-----Original Message-----
From: Lu, Yinghai [mailto:yinghai.lu at amd.com] 
Sent: Friday, November 04, 2005 5:51 PM
To: Matthew Simmons; linuxbios at openbios.org
Subject: RE: [LinuxBIOS] S2882 Memory Hang

1. You don't need to lift your cpu apic id above 0x10.

2. for amd8111 sb, when you do that, kernel will hang, because jiffies will
not change.

So remove 0x10 in your k8_secondart_stop.....
And hard code apicid_base to 4

It should work....

YH


-----Original Message-----
From: linuxbios-bounces at openbios.org
[mailto:linuxbios-bounces at openbios.org] On Behalf Of Matthew Simmons
Sent: Friday, November 04, 2005 2:11 PM
To: linuxbios at openbios.org
Subject: [LinuxBIOS] S2882 Memory Hang

I am currently trying get LinuxBios up and running on my Tyan S2882.
After
hard coding the apicid_base = 1 in the mptable.c I was finally able to
successfully build a bios image for my system. I am using filo as the
payload and the configuration of that went well. 
 
Both LinuxBios and filo are working as expected. The problem occurs when I
attempt to boot the kernel. The kernel stops after the memory manager loads.
There are no errors or panics. The system just locks up. 
 
I was wondering if any of you have seen this problem, or know of a work
around. I am including the kernel output from the serial console. As well as
a brief description of the configuration of the system.
 
Thanks for your help,
Matthew Simmons


 
Configuration:
----------------------------------------------
Tyan S2882 2x Opteron 248 Processors
1024mb Ram (512x per processor)
LinuxBIOSv2 (Revision 2084)
Kernel: 2.6.12.1 with the Realtime Preempt Patch Base OS: SuSE 9.2 GCC
version: 3.3.2
 
 
Serial Console Output: (Sorry for the length)
------------------------------------------------
LinuxBIOS-1.1.8_s2882_Fallback Fri Nov  4 12:47:40 CST 2005 starting...

(0,1) link=01             
(1,0) link=01             
02 nodes initialized.                     
SBLink=00         
NC node|link=00               
Ram1.00       
Ram1.01       
Ram2.00       
Ram2.01       
Ram3    
Initializing memory:  done                          
Initializing memory:  done                          
Clearing initial memory region:  done

Ram4    
Copying LinuxBIOS to ram.                         
Jumping to LinuxBIOS.                     
LinuxBIOS-1.1.8_s2882_Fallback Fri Nov  4 12:47:40 CST 2005 booting...

Enumerating buses...                    
APIC_CLUSTER: 0 enabled                       
PCI_DOMAIN: 0000 enabled                        
CPU: APIC: 10 enabled                     
PCI: 00:19.0 [1022/1100] enabled                                
PCI: 00:19.1 [1022/1101] enabled                                
PCI: 00:19.2 [1022/1102] enabled                                
PCI: 00:19.3 [1022/1103] enabled                                
CPU: APIC: 11 enabled                     
PCI: pci_scan_bus for bus 0                           
PCI: 00:18.0 [1022/1100] enabled                                
PCI: 00:18.1 [1022/1101] enabled                                
PCI: 00:18.2 [1022/1102] enabled                                
PCI: 00:18.3 [1022/1103] enabled                                
PCI: 00:19.0 [1022/1100] enabled                                
PCI: 00:19.1 [1022/1101] enabled                                
PCI: 00:19.2 [1022/1102] enabled                                
PCI: 00:19.3 [1022/1103] enabled                                
PCI: 01:00.0 [1022/7450] en                          
PCI: 01:01.0 [1022/7450] enabled next_unitid: 0003

PCI: 01:00.0 [1022/7460] enabled                                
PCI: 01:03.0 [1022/7460] enabled next_unitid: 0007

PCI: pci_scan_bus for bus 1                           
PCI: 01:01.0 [1022/7450] enabled                                
PCI: 01:01.1 [1022/7451] enabled                                
PCI: 01:02.0 [1022/7450] enabled                                
PCI: 01:02.1 [1022/7451] enabled                                
PCI: 01:03.0 [1022/7460] enabled                                
PCI: 01:04.0 [1022/7468] enabled                                
PCI: 01:04.1 [1022/7469] enabled                                
PCI: 01:04.2 [1022/746a] enabled                                
PCI: 01:04.3 [1022/746b] enabled                                
PCI: pci_scan_bus for bus 2                           
Disabling static device: PCI: 0                              
Disabling static device: PCI: 02:06.1

PCI: 02:09.0 [14e4/1648] enabled                                
PCI: 02:09.1 [14e4/1648] enabled                                
PCI: pci_scan_bus returning with max=02

PCI: 02: 100MHz PCI-X                     
PCI: pci_scan_bus for bus 3                           
PCI: 03:04.0 [10ee/3fc6] enabled                                
PCI: pci_scan_bus returning with max=03

PCI: 03: Conventional PCI                         
PCI: pci_scan_bus for bus 4                           
PCI: 04:00.0 [1022/7464] enabled                                
PCI: 04:00.1 [1022/7464] enabled                                
PCI: 04:05.0 [1095/3114] enabled                                
PCI: 04:06.0 [1002/4752] enabled                                
PCI: 04:08.0 [8086/1229] enabled                                
PCI: pci_scan_bus returning with m                                
PNP: 002e.0 enabled                   
PNP: 002e.1 disabled                    
PNP: 002e.2 enabled                   
PNP: 002e.3 disabled                    
PNP: 002e.5 enabled                   
PNP: 002e.6 disabled                    
PNP: 002e.7 disabled                    
PNP: 002e.8 disabled                    
PNP: 002e.9 disabled                    
PNP: 002e.a disabled                    
PNP: 002e.b enabled                   
PCI: pci_scan_bus returning with max=04

PCI: pci_scan_bus returning with max=04

done    
Allocating resources...                       
Reading resources...                    
PCI: 01:01.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 2 io

PCI: 01:01.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 2 prefmem

PCI: 01:02.0 1c <- [0x00fffff00                              
PCI: 01:02.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 3 prefmem
map page: 16ee: 118                          
Cannot map page: 16f       
PCI: 01:03.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 4 prefmem

Cannot map pag              
Cannot map p
Done reading resources.        
Cannot map pag
Allocating VGA resource PCI: 04:06.0                             
Cannot
Setting PCI_BRIDGE_CTL_VGA for bridge PCI: 01:03.0 map page: 174xtra MTRR'sd
<                      
Setting PCI_BRIDGE_CTL_VGA for bridge PCI: 00:18.0  
Cannot map          
Cannot map page: 176      
Setting PCI_BRIDGE_CTL_VGA for bridge PCI_DOMAIN: 0000            

Cannot map page: 178 page: 14b          
Setting PCI_BRIDGE_CTL_VGA for bridge Root Devicep page: 14c

Setting resources...7a                  
PCI: 00:18.0 1b8 <- [0x00fd400000 - 0x00fd3fffff] prefmem <node 0 link
0>

Cannot map page:                
Cannot map page: 17d   
PCI: 01:02.1 10 <- [0x00fd301000 - 0x00fd301fff] mem64map page: 17

Cannot map page: 1a8
PCI: 01:03.0 1c <- [0x0000001000 - 0x0000001fff] bus 4 io page: 18

Cannot map page: 1
PCI: 01:03.0 20 <- [0x00fc000000 - 0x00fd0fffff] bus 4 memge: 191

Cannot map page: 1acnot
PCI: 04:00.0 10 <- [0x00fd020000 - 0x00fd020fff] meme: 1ading f

Cannot map page
PCI: 04:00.1 10 <- [0x00fd021000 - 0x00fd021fff] mem  
Cannot map page: 1aft map                        
PCI: 04:05.0 10 <- [0x0000001450 - 0x0000001457] ioCann    
Cannot map page: 1b1age: 19566e: 124M, W
PCI: 04:05.0 14 <- [0x0000001470 - 0x0000001473] ioge: 1b

Cannot map page: 1bcot ma
PCI: 04:05.0 18 <- [0x0000001460 - 0x0000001467] ioot map page: 1bdot map

Ca
PCI: 04:05.0 1c <- [0x00000014                        
   
PNP: 002e.0 70 <- [0x0000000006 - 0x0000000006] irq     
Cannot map page: 1de                    
Cann
PNP: 002e.0 74 <- [0x0000000002 - 0x0000000002] drq           
P
C 
Can   

-Cannot map page: 1e0t ma
PNP: 002e.2 60 <- [0x00000003f8 - 0x00000003ff] ionot map page: 1e1

Cannot ma   
PNP: 002e.2 70 <- [0x0000000004 - 0x0000000004] irqo     
Cannot map page: 1e3ot map page: 1ca        
PNP: 002e.5 60 <- [0x0000000060 - 0x0000000060] io                  


Cannot map page: 1f4         
PNP: 002e.5 62 <- [0x0000000064 - 0x0000000064] io              
Cannot      
Cannot map page: 1f6
PNP: 002e.5 70 <- [0x0000000001 - 0x0000000001] irq: 1f7

Cannot m        
Cannot m
PNP: 002e.5 72 <- [0x000000000c - 0x000000000c] irq                    
Cannot map page: 1f9Cannot map
PNP: 002e.b 60 <- [0x0000000290 - 0x0000000297] ioage: 1faage: 1ee

Canno
PNP: 002e.b 70 <- [0x0000000005 - 0x0000000005] irq

Cannot map page            
PNP: 002e.5 init        
PCI: 01:01.1 cmd <- 146b i             
NB: Fu
PCI: 01:02.0 bridge ctrl <- 0003                               

PCI: 01:02.0 cmd <- 1460ot ma                 
PCI: 03:04.0 cmd <- 142.0 init                
PCI: 01:02.1 subsystem <- 10f1/2882    
PNP: 002e.0 initd             
PCI: 01:02.1 cmd <- 146 tables to 0xf0000...do
PCI: 01:03.0 bridge ctrl <- 000b                                
PCI: 01:03.0 cmd <- 147ng copy of IRQ routing 
PCI: 04:00.0 subsystem <- 10f1/2882                                   
PCI: 04:00.0 cmd <- 142PCI: 00:19.1 init:06.0
PCI: 04:00.1 subsystem <- 10f1/2882RQ routing table consistency...PCI:
PCI: 04:00.1 cmd <- 142                       
PCI: 04:05.0 subsystem <- 10f1/2882
check_pirq_routing_table() - irq_
PCI: 04:05.0 cmd <- 143: 0x000f00sc Control.. 
PCI: 04:06.0 subsystem <- 10f1/2882                                   
PCI: 04:06.0 cmd <- 1c3         
           

    33:stre
PCI: 01:04.1 cmd <- 1410xfffe0000 - 0xfffe6fff
PCI: 01:04.2 subsystem <- 10f1/2882                            
Found 
PCI: 01:04.2 cmd <- 141                       
PCI: 01:04.3 subsystem <- 10f1/2882                      
Loading Ethe
PCI: 01:04.3 cmd <- 141                       
PCI: 00:18.1 subsystem <- 10f1/2882ing non PT_LOAD segment            
PCI: 00:18.1 cmd <- 140ot 5.2.6 (GPL) http://e
PCI: 00:18.2 subsystem <- 10f1/2882 hda4:/boot/vmlinuz initrd=/boot/in
PCI: 00:18.2 cmd <- 140ons                    
PCI: 00:18.3 cmd <- 140                       
PCI: 00:19.0 cmd <- 140                       
PCI: 00:19.1 cmd <- 140                       
hda: LBA48: HDS7280
Initializing CPU #0                 


CPU: vendor AMD device f5aack Fri Nov  4 13:59:37 CS
Enabling cache...           

Setting fixed MTRRs(0-88) type: UC                        
Found Lin
Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM

(0,1) link=01host) #
Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM       
02 nodes initialized.                    
DONE fixed MTRRsSBLink=00and lin
Setting variable MTRR 0, base:    0MB, range: 1024MB, type WB

ht reset -canning NU                    



DONE variable MTRRs2_Fallback Fri Nov 
Clear out the extra MTRR'sng...                     

MTRR check          
Fixed MTRRs   : Enabled    
Linux version     
Variable MTRRs: Enabledeko at buildho            

Setting up local apic..=01on 3               
Copying Lin
Enabling cachepe 16         

Setting fixed MTRRs(0-88) type: UCnuxBIOS.                     
 BIO
Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM4 13:59:37 CST 2005
booting...                  
Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM  
 BIOS-e820: 00000000000f0000 - 000            
DONE fixed MTRRs     
Enumeratin
Setting variable MTRR 0, base:    0MB, range: 1024MB, type WB

Scanning NU           
PCI_DOMAIN: 0000 enabl
DONE variable MTRRs              
CPU:
Clear out the extra MTRR's 0000000000               

MTRR check          
Fixed MTRRs   : Enabled/11                    
PCI: 00:19.1 [10
All AP CPUs stopped                   
PCI: 00:18.0 initr #17 INVAL      
PCI: 01:01.0 init 00:19.2 [1022/11
PCI: 02:09.0 init                 
PCI: 02:09.1 init#1           
PCI
PCI: 01:02.0 init03] enabled      
PCI: 01:03.0 init        
I
PCI: 
PCI: 04:05.0 init] enabled00.     
PCI: 04:06.0 init            
PCI:
rom address for PCI: 04:06.0 = fff80000: 0003

Incorrect Expansion ROM Header Signature 457fCI: 01:00.0 [1022/7460] enabled

PCI: 04:08.0 init
CPU 0: apertur
PCI: 01:04.0 init01:03.0 [1022/746
RTC Initd next_u
Invalid CMOS LB checksum                        
enabling HPET @0xf                 
PCI: 00:18.2 init                 
PCI: 00:18.3 initstatic device: PC
NB: Function 3 Misc Control.. done.           
Inode-cache hash table 
PCI: 00:19.0 init               
D
PCI: 00:19.1 initvice: PCI: 02:06.
PCI: 00:19.2 init                 
PCI: 00:19.3 init14e4/1648] enable
NB: Function 3 Misc Control.. done.                                   
PCI: 03:04.0 init        
PCI: 02:
Devices initializedbledk data, 220k in
Copying IRQ routing tables to 0xf0000...done.       
PCI: pci_scan_bus returning with max=
Wrote the mp table end at: 00000020 - 00000214 Moving GDT to 0x500...ok
Wrote linuxbios table at: 00000530 - 00000de4  checksum 9515

Welcome to elfboot, the open sourced starter.
January 2002, Eric Biederman.
Version 1.3

    33:stream_init() - rom_stream: 0xfffe0000 - 0xfffe6fff Found ELF
candiate at offset 0 Loading Etherboot version: 5.2.6 Dropping non PT_LOAD
segment New segment addr 0x20000 size 0x312bd offset 0xb0 filesize 0x6c5b
(cleaned up) New segment addr 0x20000 size 0x312bd offset 0xb0 filesize
0x6c5b Loading Segment: addr: 0x000000003ff90000 memsz: 0x000000000002a000
filesz:
0x0000000000006c5b
Clearing Segment: addr: 0x000000003ff96c5b memsz: 0x00000000000233a5 Loading
Segment: addr: 0x000000000004a000 memsz: 0x00000000000072bd
filesz:
0x0000000000000000
Clearing Segment: addr: 0x000000000004a000 memsz: 0x00000000000072bd Jumping
to boot code at 0x20000 ROM segment 0x0000 length 0x0000 reloc 0x00020000
CPU 2056 Mhz Etherboot 5.2.6 (GPL) http://etherboot.org Tagged ELF for
[FILO] Relocating _text from: [00026c60,00052870) to [3fed43f0,3ff00000)
Boot from (N)etwork (D)isk or (Q)uit?

Probing pci disk...it() - ro
Int BIOS-e820: 00000000000f0000 - 00000000000f0400 type 16i Nov  4
13:57:25
C
Virtual Wire compatibility mode
BIOS-e820: 0000000000100000 - 0000000040000000 (usable)>Product ID:
S2882
<6>APIC at: 0xFEE00000hda4 con
Scanning NUMA topology in Northbridge 24toppe New segment Virtual Wire
compatibility mode.
OEM ID: TYAN     <6>Product ID: S2882        <6>APIC at: 0xFEE00000
Processor #16 15:5 APIC version 16
Processor #17 15:5 APIC version 16
Processor #17 INVALID. (Max ID: 16).
I/O APIC #1 Version 17 at 0xFEC00000.
I/O APIC #2 Version 17 at 0xFD300000.
I/O APIC #3 Version 17 at 0xFD301000.
Processors: 2
Checking aperture...
CPU 0: aperture @ f8000000 size 64 MB
CPU 1: aperture @ f8000000 size 64 MB
Built 2 zonelists
Kernel command line: ro root=/dev/hda4 console=ttyS0,115200 Initializing
CPU#0 PID hash table entries: 4096 (order: 12, 131072 bytes)
time.c: Using 1.193182 MHz PIT timer.
time.c: Detected 1990.814 MHz processor.
Console: colour dummy device 80x25
Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Memory: 1023436k/1048576k available (2452k kernel code, 0k reserved, 942k
data, 220k init)


--
LinuxBIOS mailing list
LinuxBIOS at openbios.org
http://www.openbios.org/mailman/listinfo/linuxbios






From yinghai.lu at AMD.com  Mon Nov  7 18:16:03 2005
From: yinghai.lu at AMD.com (Lu, Yinghai)
Date: Mon, 7 Nov 2005 09:16:03 -0800
Subject: [LinuxBIOS] S2882 Memory Hang
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E06204@ssvlexmb2.amd.com>

src/cpu/amd/dualcore...

anyway that is some confusing..., it should be at
src/cpu/amd/model_fxx...

YH

-----Original Message-----
From: Matthew Simmons [mailto:matt at glw.com] 
Sent: Monday, November 07, 2005 8:09 AM
To: Lu, Yinghai; linuxbios at openbios.org
Subject: RE: [LinuxBIOS] S2882 Memory Hang

I am having a little trouble locating the k8_secondart_stop function.
Could
you point me in the right direction? I looked in
src/southbridge/amd/amd8111/ and in src/mainboard/tyan/s2882/ as well as
src/northbridge/amd/amdk8.

I have hard coded the apicid_base to 4.

Thanks for your help,
Matt


-----Original Message-----
From: Lu, Yinghai [mailto:yinghai.lu at amd.com] 
Sent: Friday, November 04, 2005 5:51 PM
To: Matthew Simmons; linuxbios at openbios.org
Subject: RE: [LinuxBIOS] S2882 Memory Hang

1. You don't need to lift your cpu apic id above 0x10.

2. for amd8111 sb, when you do that, kernel will hang, because jiffies
will
not change.

So remove 0x10 in your k8_secondart_stop.....
And hard code apicid_base to 4

It should work....

YH


-----Original Message-----
From: linuxbios-bounces at openbios.org
[mailto:linuxbios-bounces at openbios.org] On Behalf Of Matthew Simmons
Sent: Friday, November 04, 2005 2:11 PM
To: linuxbios at openbios.org
Subject: [LinuxBIOS] S2882 Memory Hang

I am currently trying get LinuxBios up and running on my Tyan S2882.
After
hard coding the apicid_base = 1 in the mptable.c I was finally able to
successfully build a bios image for my system. I am using filo as the
payload and the configuration of that went well. 
 
Both LinuxBios and filo are working as expected. The problem occurs when
I
attempt to boot the kernel. The kernel stops after the memory manager
loads.
There are no errors or panics. The system just locks up. 
 
I was wondering if any of you have seen this problem, or know of a work
around. I am including the kernel output from the serial console. As
well as
a brief description of the configuration of the system.
 
Thanks for your help,
Matthew Simmons


 
Configuration:
----------------------------------------------
Tyan S2882 2x Opteron 248 Processors
1024mb Ram (512x per processor)
LinuxBIOSv2 (Revision 2084)
Kernel: 2.6.12.1 with the Realtime Preempt Patch Base OS: SuSE 9.2 GCC
version: 3.3.2
 
 
Serial Console Output: (Sorry for the length)
------------------------------------------------
LinuxBIOS-1.1.8_s2882_Fallback Fri Nov  4 12:47:40 CST 2005 starting...

(0,1) link=01             
(1,0) link=01             
02 nodes initialized.                     
SBLink=00         
NC node|link=00               
Ram1.00       
Ram1.01       
Ram2.00       
Ram2.01       
Ram3    
Initializing memory:  done                          
Initializing memory:  done                          
Clearing initial memory region:  done

Ram4    
Copying LinuxBIOS to ram.                         
Jumping to LinuxBIOS.                     
LinuxBIOS-1.1.8_s2882_Fallback Fri Nov  4 12:47:40 CST 2005 booting...

Enumerating buses...                    
APIC_CLUSTER: 0 enabled                       
PCI_DOMAIN: 0000 enabled                        
CPU: APIC: 10 enabled                     
PCI: 00:19.0 [1022/1100] enabled                                
PCI: 00:19.1 [1022/1101] enabled                                
PCI: 00:19.2 [1022/1102] enabled                                
PCI: 00:19.3 [1022/1103] enabled                                
CPU: APIC: 11 enabled                     
PCI: pci_scan_bus for bus 0                           
PCI: 00:18.0 [1022/1100] enabled                                
PCI: 00:18.1 [1022/1101] enabled                                
PCI: 00:18.2 [1022/1102] enabled                                
PCI: 00:18.3 [1022/1103] enabled                                
PCI: 00:19.0 [1022/1100] enabled                                
PCI: 00:19.1 [1022/1101] enabled                                
PCI: 00:19.2 [1022/1102] enabled                                
PCI: 00:19.3 [1022/1103] enabled                                
PCI: 01:00.0 [1022/7450] en                          
PCI: 01:01.0 [1022/7450] enabled next_unitid: 0003

PCI: 01:00.0 [1022/7460] enabled                                
PCI: 01:03.0 [1022/7460] enabled next_unitid: 0007

PCI: pci_scan_bus for bus 1                           
PCI: 01:01.0 [1022/7450] enabled                                
PCI: 01:01.1 [1022/7451] enabled                                
PCI: 01:02.0 [1022/7450] enabled                                
PCI: 01:02.1 [1022/7451] enabled                                
PCI: 01:03.0 [1022/7460] enabled                                
PCI: 01:04.0 [1022/7468] enabled                                
PCI: 01:04.1 [1022/7469] enabled                                
PCI: 01:04.2 [1022/746a] enabled                                
PCI: 01:04.3 [1022/746b] enabled                                
PCI: pci_scan_bus for bus 2                           
Disabling static device: PCI: 0                              
Disabling static device: PCI: 02:06.1

PCI: 02:09.0 [14e4/1648] enabled                                
PCI: 02:09.1 [14e4/1648] enabled                                
PCI: pci_scan_bus returning with max=02

PCI: 02: 100MHz PCI-X                     
PCI: pci_scan_bus for bus 3                           
PCI: 03:04.0 [10ee/3fc6] enabled                                
PCI: pci_scan_bus returning with max=03

PCI: 03: Conventional PCI                         
PCI: pci_scan_bus for bus 4                           
PCI: 04:00.0 [1022/7464] enabled                                
PCI: 04:00.1 [1022/7464] enabled                                
PCI: 04:05.0 [1095/3114] enabled                                
PCI: 04:06.0 [1002/4752] enabled                                
PCI: 04:08.0 [8086/1229] enabled                                
PCI: pci_scan_bus returning with m                                
PNP: 002e.0 enabled                   
PNP: 002e.1 disabled                    
PNP: 002e.2 enabled                   
PNP: 002e.3 disabled                    
PNP: 002e.5 enabled                   
PNP: 002e.6 disabled                    
PNP: 002e.7 disabled                    
PNP: 002e.8 disabled                    
PNP: 002e.9 disabled                    
PNP: 002e.a disabled                    
PNP: 002e.b enabled                   
PCI: pci_scan_bus returning with max=04

PCI: pci_scan_bus returning with max=04

done    
Allocating resources...                       
Reading resources...                    
PCI: 01:01.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 2 io

PCI: 01:01.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 2
prefmem

PCI: 01:02.0 1c <- [0x00fffff00                              
PCI: 01:02.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 3
prefmem
map page: 16ee: 118                          
Cannot map page: 16f       
PCI: 01:03.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 4 prefmem

Cannot map pag              
Cannot map p
Done reading resources.        
Cannot map pag
Allocating VGA resource PCI: 04:06.0                             
Cannot
Setting PCI_BRIDGE_CTL_VGA for bridge PCI: 01:03.0 map page: 174xtra
MTRR'sd
<                      
Setting PCI_BRIDGE_CTL_VGA for bridge PCI: 00:18.0  
Cannot map          
Cannot map page: 176      
Setting PCI_BRIDGE_CTL_VGA for bridge PCI_DOMAIN: 0000            

Cannot map page: 178 page: 14b          
Setting PCI_BRIDGE_CTL_VGA for bridge Root Devicep page: 14c

Setting resources...7a                  
PCI: 00:18.0 1b8 <- [0x00fd400000 - 0x00fd3fffff] prefmem <node 0 link
0>

Cannot map page:                
Cannot map page: 17d   
PCI: 01:02.1 10 <- [0x00fd301000 - 0x00fd301fff] mem64map page: 17

Cannot map page: 1a8
PCI: 01:03.0 1c <- [0x0000001000 - 0x0000001fff] bus 4 io page: 18

Cannot map page: 1
PCI: 01:03.0 20 <- [0x00fc000000 - 0x00fd0fffff] bus 4 memge: 191

Cannot map page: 1acnot
PCI: 04:00.0 10 <- [0x00fd020000 - 0x00fd020fff] meme: 1ading f

Cannot map page
PCI: 04:00.1 10 <- [0x00fd021000 - 0x00fd021fff] mem  
Cannot map page: 1aft map                        
PCI: 04:05.0 10 <- [0x0000001450 - 0x0000001457] ioCann    
Cannot map page: 1b1age: 19566e: 124M, W
PCI: 04:05.0 14 <- [0x0000001470 - 0x0000001473] ioge: 1b

Cannot map page: 1bcot ma
PCI: 04:05.0 18 <- [0x0000001460 - 0x0000001467] ioot map page: 1bdot
map

Ca
PCI: 04:05.0 1c <- [0x00000014                        
   
PNP: 002e.0 70 <- [0x0000000006 - 0x0000000006] irq     
Cannot map page: 1de                    
Cann
PNP: 002e.0 74 <- [0x0000000002 - 0x0000000002] drq           
P
C 
Can   

-Cannot map page: 1e0t ma
PNP: 002e.2 60 <- [0x00000003f8 - 0x00000003ff] ionot map page: 1e1

Cannot ma   
PNP: 002e.2 70 <- [0x0000000004 - 0x0000000004] irqo     
Cannot map page: 1e3ot map page: 1ca        
PNP: 002e.5 60 <- [0x0000000060 - 0x0000000060] io                  


Cannot map page: 1f4         
PNP: 002e.5 62 <- [0x0000000064 - 0x0000000064] io              
Cannot      
Cannot map page: 1f6
PNP: 002e.5 70 <- [0x0000000001 - 0x0000000001] irq: 1f7

Cannot m        
Cannot m
PNP: 002e.5 72 <- [0x000000000c - 0x000000000c] irq                    
Cannot map page: 1f9Cannot map
PNP: 002e.b 60 <- [0x0000000290 - 0x0000000297] ioage: 1faage: 1ee

Canno
PNP: 002e.b 70 <- [0x0000000005 - 0x0000000005] irq

Cannot map page            
PNP: 002e.5 init        
PCI: 01:01.1 cmd <- 146b i             
NB: Fu
PCI: 01:02.0 bridge ctrl <- 0003                               

PCI: 01:02.0 cmd <- 1460ot ma                 
PCI: 03:04.0 cmd <- 142.0 init                
PCI: 01:02.1 subsystem <- 10f1/2882    
PNP: 002e.0 initd             
PCI: 01:02.1 cmd <- 146 tables to 0xf0000...do
PCI: 01:03.0 bridge ctrl <- 000b                                
PCI: 01:03.0 cmd <- 147ng copy of IRQ routing 
PCI: 04:00.0 subsystem <- 10f1/2882                                   
PCI: 04:00.0 cmd <- 142PCI: 00:19.1 init:06.0
PCI: 04:00.1 subsystem <- 10f1/2882RQ routing table consistency...PCI:
PCI: 04:00.1 cmd <- 142                       
PCI: 04:05.0 subsystem <- 10f1/2882
check_pirq_routing_table() - irq_
PCI: 04:05.0 cmd <- 143: 0x000f00sc Control.. 
PCI: 04:06.0 subsystem <- 10f1/2882                                   
PCI: 04:06.0 cmd <- 1c3         
           

    33:stre
PCI: 01:04.1 cmd <- 1410xfffe0000 - 0xfffe6fff
PCI: 01:04.2 subsystem <- 10f1/2882                            
Found 
PCI: 01:04.2 cmd <- 141                       
PCI: 01:04.3 subsystem <- 10f1/2882                      
Loading Ethe
PCI: 01:04.3 cmd <- 141                       
PCI: 00:18.1 subsystem <- 10f1/2882ing non PT_LOAD segment            
PCI: 00:18.1 cmd <- 140ot 5.2.6 (GPL) http://e
PCI: 00:18.2 subsystem <- 10f1/2882 hda4:/boot/vmlinuz initrd=/boot/in
PCI: 00:18.2 cmd <- 140ons                    
PCI: 00:18.3 cmd <- 140                       
PCI: 00:19.0 cmd <- 140                       
PCI: 00:19.1 cmd <- 140                       
hda: LBA48: HDS7280
Initializing CPU #0                 


CPU: vendor AMD device f5aack Fri Nov  4 13:59:37 CS
Enabling cache...           

Setting fixed MTRRs(0-88) type: UC                        
Found Lin
Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM

(0,1) link=01host) #
Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM       
02 nodes initialized.                    
DONE fixed MTRRsSBLink=00and lin
Setting variable MTRR 0, base:    0MB, range: 1024MB, type WB

ht reset -canning NU                    



DONE variable MTRRs2_Fallback Fri Nov 
Clear out the extra MTRR'sng...                     

MTRR check          
Fixed MTRRs   : Enabled    
Linux version     
Variable MTRRs: Enabledeko at buildho            

Setting up local apic..=01on 3               
Copying Lin
Enabling cachepe 16         

Setting fixed MTRRs(0-88) type: UCnuxBIOS.                     
 BIO
Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM4 13:59:37 CST 2005
booting...                  
Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM  
 BIOS-e820: 00000000000f0000 - 000            
DONE fixed MTRRs     
Enumeratin
Setting variable MTRR 0, base:    0MB, range: 1024MB, type WB

Scanning NU           
PCI_DOMAIN: 0000 enabl
DONE variable MTRRs              
CPU:
Clear out the extra MTRR's 0000000000               

MTRR check          
Fixed MTRRs   : Enabled/11                    
PCI: 00:19.1 [10
All AP CPUs stopped                   
PCI: 00:18.0 initr #17 INVAL      
PCI: 01:01.0 init 00:19.2 [1022/11
PCI: 02:09.0 init                 
PCI: 02:09.1 init#1           
PCI
PCI: 01:02.0 init03] enabled      
PCI: 01:03.0 init        
I
PCI: 
PCI: 04:05.0 init] enabled00.     
PCI: 04:06.0 init            
PCI:
rom address for PCI: 04:06.0 = fff80000: 0003

Incorrect Expansion ROM Header Signature 457fCI: 01:00.0 [1022/7460]
enabled

PCI: 04:08.0 init
CPU 0: apertur
PCI: 01:04.0 init01:03.0 [1022/746
RTC Initd next_u
Invalid CMOS LB checksum                        
enabling HPET @0xf                 
PCI: 00:18.2 init                 
PCI: 00:18.3 initstatic device: PC
NB: Function 3 Misc Control.. done.           
Inode-cache hash table 
PCI: 00:19.0 init               
D
PCI: 00:19.1 initvice: PCI: 02:06.
PCI: 00:19.2 init                 
PCI: 00:19.3 init14e4/1648] enable
NB: Function 3 Misc Control.. done.                                   
PCI: 03:04.0 init        
PCI: 02:
Devices initializedbledk data, 220k in
Copying IRQ routing tables to 0xf0000...done.       
PCI: pci_scan_bus returning with max=
Wrote the mp table end at: 00000020 - 00000214 Moving GDT to 0x500...ok
Wrote linuxbios table at: 00000530 - 00000de4  checksum 9515

Welcome to elfboot, the open sourced starter.
January 2002, Eric Biederman.
Version 1.3

    33:stream_init() - rom_stream: 0xfffe0000 - 0xfffe6fff Found ELF
candiate at offset 0 Loading Etherboot version: 5.2.6 Dropping non
PT_LOAD
segment New segment addr 0x20000 size 0x312bd offset 0xb0 filesize
0x6c5b
(cleaned up) New segment addr 0x20000 size 0x312bd offset 0xb0 filesize
0x6c5b Loading Segment: addr: 0x000000003ff90000 memsz:
0x000000000002a000
filesz:
0x0000000000006c5b
Clearing Segment: addr: 0x000000003ff96c5b memsz: 0x00000000000233a5
Loading
Segment: addr: 0x000000000004a000 memsz: 0x00000000000072bd
filesz:
0x0000000000000000
Clearing Segment: addr: 0x000000000004a000 memsz: 0x00000000000072bd
Jumping
to boot code at 0x20000 ROM segment 0x0000 length 0x0000 reloc
0x00020000
CPU 2056 Mhz Etherboot 5.2.6 (GPL) http://etherboot.org Tagged ELF for
[FILO] Relocating _text from: [00026c60,00052870) to [3fed43f0,3ff00000)
Boot from (N)etwork (D)isk or (Q)uit?

Probing pci disk...it() - ro
Int BIOS-e820: 00000000000f0000 - 00000000000f0400 type 16i Nov  4
13:57:25
C
Virtual Wire compatibility mode
BIOS-e820: 0000000000100000 - 0000000040000000 (usable)>Product ID:
S2882
<6>APIC at: 0xFEE00000hda4 con
Scanning NUMA topology in Northbridge 24toppe New segment Virtual Wire
compatibility mode.
OEM ID: TYAN     <6>Product ID: S2882        <6>APIC at: 0xFEE00000
Processor #16 15:5 APIC version 16
Processor #17 15:5 APIC version 16
Processor #17 INVALID. (Max ID: 16).
I/O APIC #1 Version 17 at 0xFEC00000.
I/O APIC #2 Version 17 at 0xFD300000.
I/O APIC #3 Version 17 at 0xFD301000.
Processors: 2
Checking aperture...
CPU 0: aperture @ f8000000 size 64 MB
CPU 1: aperture @ f8000000 size 64 MB
Built 2 zonelists
Kernel command line: ro root=/dev/hda4 console=ttyS0,115200 Initializing
CPU#0 PID hash table entries: 4096 (order: 12, 131072 bytes)
time.c: Using 1.193182 MHz PIT timer.
time.c: Detected 1990.814 MHz processor.
Console: colour dummy device 80x25
Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Memory: 1023436k/1048576k available (2452k kernel code, 0k reserved,
942k
data, 220k init)


--
LinuxBIOS mailing list
LinuxBIOS at openbios.org
http://www.openbios.org/mailman/listinfo/linuxbios








From linuxbios at glw.com  Mon Nov  7 19:54:36 2005
From: linuxbios at glw.com (Matthew Simmons)
Date: Mon, 7 Nov 2005 12:54:36 -0600
Subject: [LinuxBIOS] S2882 Memory Hang
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4201E06204@ssvlexmb2.amd.com>
Message-ID: <20051107185237.F1B794C085@mail.glw.com>

Here is what I did to make it work. In the src/cpu/amd/dualcore/dualcore.c I
removed the 0x10 from the line:

lapic_write(LAPIC_ID,(0x10 + id.coreid*0x10 + id.nodeid) << 24);

The new line is:

lapic_write(LAPIC_ID,(id.coreid*0x10 + id.nodeid) << 24);

This worked correctly. And the system booted!

Thanks for your help,
Matt

-----Original Message-----
From: linuxbios-bounces at openbios.org [mailto:linuxbios-bounces at openbios.org]
On Behalf Of Lu, Yinghai
Sent: Monday, November 07, 2005 11:16 AM
To: Matthew Simmons; linuxbios at openbios.org
Subject: Re: [LinuxBIOS] S2882 Memory Hang

src/cpu/amd/dualcore...

anyway that is some confusing..., it should be at src/cpu/amd/model_fxx...

YH

-----Original Message-----
From: Matthew Simmons [mailto:matt at glw.com]
Sent: Monday, November 07, 2005 8:09 AM
To: Lu, Yinghai; linuxbios at openbios.org
Subject: RE: [LinuxBIOS] S2882 Memory Hang

I am having a little trouble locating the k8_secondart_stop function.
Could
you point me in the right direction? I looked in
src/southbridge/amd/amd8111/ and in src/mainboard/tyan/s2882/ as well as
src/northbridge/amd/amdk8.

I have hard coded the apicid_base to 4.

Thanks for your help,
Matt


-----Original Message-----
From: Lu, Yinghai [mailto:yinghai.lu at amd.com]
Sent: Friday, November 04, 2005 5:51 PM
To: Matthew Simmons; linuxbios at openbios.org
Subject: RE: [LinuxBIOS] S2882 Memory Hang

1. You don't need to lift your cpu apic id above 0x10.

2. for amd8111 sb, when you do that, kernel will hang, because jiffies will
not change.

So remove 0x10 in your k8_secondart_stop.....
And hard code apicid_base to 4

It should work....

YH


-----Original Message-----
From: linuxbios-bounces at openbios.org
[mailto:linuxbios-bounces at openbios.org] On Behalf Of Matthew Simmons
Sent: Friday, November 04, 2005 2:11 PM
To: linuxbios at openbios.org
Subject: [LinuxBIOS] S2882 Memory Hang

I am currently trying get LinuxBios up and running on my Tyan S2882.
After
hard coding the apicid_base = 1 in the mptable.c I was finally able to
successfully build a bios image for my system. I am using filo as the
payload and the configuration of that went well. 
 
Both LinuxBios and filo are working as expected. The problem occurs when I
attempt to boot the kernel. The kernel stops after the memory manager loads.
There are no errors or panics. The system just locks up. 
 
I was wondering if any of you have seen this problem, or know of a work
around. I am including the kernel output from the serial console. As well as
a brief description of the configuration of the system.
 
Thanks for your help,
Matthew Simmons


 
Configuration:
----------------------------------------------
Tyan S2882 2x Opteron 248 Processors
1024mb Ram (512x per processor)
LinuxBIOSv2 (Revision 2084)
Kernel: 2.6.12.1 with the Realtime Preempt Patch Base OS: SuSE 9.2 GCC
version: 3.3.2
 
 
Serial Console Output: (Sorry for the length)
------------------------------------------------
LinuxBIOS-1.1.8_s2882_Fallback Fri Nov  4 12:47:40 CST 2005 starting...

(0,1) link=01             
(1,0) link=01             
02 nodes initialized.                     
SBLink=00         
NC node|link=00               
Ram1.00       
Ram1.01       
Ram2.00       
Ram2.01       
Ram3    
Initializing memory:  done                          
Initializing memory:  done                          
Clearing initial memory region:  done

Ram4    
Copying LinuxBIOS to ram.                         
Jumping to LinuxBIOS.                     
LinuxBIOS-1.1.8_s2882_Fallback Fri Nov  4 12:47:40 CST 2005 booting...

Enumerating buses...                    
APIC_CLUSTER: 0 enabled                       
PCI_DOMAIN: 0000 enabled                        
CPU: APIC: 10 enabled                     
PCI: 00:19.0 [1022/1100] enabled                                
PCI: 00:19.1 [1022/1101] enabled                                
PCI: 00:19.2 [1022/1102] enabled                                
PCI: 00:19.3 [1022/1103] enabled                                
CPU: APIC: 11 enabled                     
PCI: pci_scan_bus for bus 0                           
PCI: 00:18.0 [1022/1100] enabled                                
PCI: 00:18.1 [1022/1101] enabled                                
PCI: 00:18.2 [1022/1102] enabled                                
PCI: 00:18.3 [1022/1103] enabled                                
PCI: 00:19.0 [1022/1100] enabled                                
PCI: 00:19.1 [1022/1101] enabled                                
PCI: 00:19.2 [1022/1102] enabled                                
PCI: 00:19.3 [1022/1103] enabled                                
PCI: 01:00.0 [1022/7450] en                          
PCI: 01:01.0 [1022/7450] enabled next_unitid: 0003

PCI: 01:00.0 [1022/7460] enabled                                
PCI: 01:03.0 [1022/7460] enabled next_unitid: 0007

PCI: pci_scan_bus for bus 1                           
PCI: 01:01.0 [1022/7450] enabled                                
PCI: 01:01.1 [1022/7451] enabled                                
PCI: 01:02.0 [1022/7450] enabled                                
PCI: 01:02.1 [1022/7451] enabled                                
PCI: 01:03.0 [1022/7460] enabled                                
PCI: 01:04.0 [1022/7468] enabled                                
PCI: 01:04.1 [1022/7469] enabled                                
PCI: 01:04.2 [1022/746a] enabled                                
PCI: 01:04.3 [1022/746b] enabled                                
PCI: pci_scan_bus for bus 2                           
Disabling static device: PCI: 0                              
Disabling static device: PCI: 02:06.1

PCI: 02:09.0 [14e4/1648] enabled                                
PCI: 02:09.1 [14e4/1648] enabled                                
PCI: pci_scan_bus returning with max=02

PCI: 02: 100MHz PCI-X                     
PCI: pci_scan_bus for bus 3                           
PCI: 03:04.0 [10ee/3fc6] enabled                                
PCI: pci_scan_bus returning with max=03

PCI: 03: Conventional PCI                         
PCI: pci_scan_bus for bus 4                           
PCI: 04:00.0 [1022/7464] enabled                                
PCI: 04:00.1 [1022/7464] enabled                                
PCI: 04:05.0 [1095/3114] enabled                                
PCI: 04:06.0 [1002/4752] enabled                                
PCI: 04:08.0 [8086/1229] enabled                                
PCI: pci_scan_bus returning with m                                
PNP: 002e.0 enabled                   
PNP: 002e.1 disabled                    
PNP: 002e.2 enabled                   
PNP: 002e.3 disabled                    
PNP: 002e.5 enabled                   
PNP: 002e.6 disabled                    
PNP: 002e.7 disabled                    
PNP: 002e.8 disabled                    
PNP: 002e.9 disabled                    
PNP: 002e.a disabled                    
PNP: 002e.b enabled                   
PCI: pci_scan_bus returning with max=04

PCI: pci_scan_bus returning with max=04

done    
Allocating resources...                       
Reading resources...                    
PCI: 01:01.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 2 io

PCI: 01:01.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 2 prefmem

PCI: 01:02.0 1c <- [0x00fffff00                              
PCI: 01:02.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 3 prefmem
map page: 16ee: 118                          
Cannot map page: 16f       
PCI: 01:03.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 4 prefmem

Cannot map pag              
Cannot map p
Done reading resources.        
Cannot map pag
Allocating VGA resource PCI: 04:06.0                             
Cannot
Setting PCI_BRIDGE_CTL_VGA for bridge PCI: 01:03.0 map page: 174xtra MTRR'sd
<                      
Setting PCI_BRIDGE_CTL_VGA for bridge PCI: 00:18.0  
Cannot map          
Cannot map page: 176      
Setting PCI_BRIDGE_CTL_VGA for bridge PCI_DOMAIN: 0000            

Cannot map page: 178 page: 14b          
Setting PCI_BRIDGE_CTL_VGA for bridge Root Devicep page: 14c

Setting resources...7a                  
PCI: 00:18.0 1b8 <- [0x00fd400000 - 0x00fd3fffff] prefmem <node 0 link
0>

Cannot map page:                
Cannot map page: 17d   
PCI: 01:02.1 10 <- [0x00fd301000 - 0x00fd301fff] mem64map page: 17

Cannot map page: 1a8
PCI: 01:03.0 1c <- [0x0000001000 - 0x0000001fff] bus 4 io page: 18

Cannot map page: 1
PCI: 01:03.0 20 <- [0x00fc000000 - 0x00fd0fffff] bus 4 memge: 191

Cannot map page: 1acnot
PCI: 04:00.0 10 <- [0x00fd020000 - 0x00fd020fff] meme: 1ading f

Cannot map page
PCI: 04:00.1 10 <- [0x00fd021000 - 0x00fd021fff] mem  
Cannot map page: 1aft map                        
PCI: 04:05.0 10 <- [0x0000001450 - 0x0000001457] ioCann    
Cannot map page: 1b1age: 19566e: 124M, W
PCI: 04:05.0 14 <- [0x0000001470 - 0x0000001473] ioge: 1b

Cannot map page: 1bcot ma
PCI: 04:05.0 18 <- [0x0000001460 - 0x0000001467] ioot map page: 1bdot map

Ca
PCI: 04:05.0 1c <- [0x00000014                        
   
PNP: 002e.0 70 <- [0x0000000006 - 0x0000000006] irq     
Cannot map page: 1de                    
Cann
PNP: 002e.0 74 <- [0x0000000002 - 0x0000000002] drq           
P
C 
Can   

-Cannot map page: 1e0t ma
PNP: 002e.2 60 <- [0x00000003f8 - 0x00000003ff] ionot map page: 1e1

Cannot ma   
PNP: 002e.2 70 <- [0x0000000004 - 0x0000000004] irqo     
Cannot map page: 1e3ot map page: 1ca        
PNP: 002e.5 60 <- [0x0000000060 - 0x0000000060] io                  


Cannot map page: 1f4         
PNP: 002e.5 62 <- [0x0000000064 - 0x0000000064] io              
Cannot      
Cannot map page: 1f6
PNP: 002e.5 70 <- [0x0000000001 - 0x0000000001] irq: 1f7

Cannot m        
Cannot m
PNP: 002e.5 72 <- [0x000000000c - 0x000000000c] irq                    
Cannot map page: 1f9Cannot map
PNP: 002e.b 60 <- [0x0000000290 - 0x0000000297] ioage: 1faage: 1ee

Canno
PNP: 002e.b 70 <- [0x0000000005 - 0x0000000005] irq

Cannot map page            
PNP: 002e.5 init        
PCI: 01:01.1 cmd <- 146b i             
NB: Fu
PCI: 01:02.0 bridge ctrl <- 0003                               

PCI: 01:02.0 cmd <- 1460ot ma                 
PCI: 03:04.0 cmd <- 142.0 init                
PCI: 01:02.1 subsystem <- 10f1/2882    
PNP: 002e.0 initd             
PCI: 01:02.1 cmd <- 146 tables to 0xf0000...do
PCI: 01:03.0 bridge ctrl <- 000b                                
PCI: 01:03.0 cmd <- 147ng copy of IRQ routing 
PCI: 04:00.0 subsystem <- 10f1/2882                                   
PCI: 04:00.0 cmd <- 142PCI: 00:19.1 init:06.0
PCI: 04:00.1 subsystem <- 10f1/2882RQ routing table consistency...PCI:
PCI: 04:00.1 cmd <- 142                       
PCI: 04:05.0 subsystem <- 10f1/2882
check_pirq_routing_table() - irq_
PCI: 04:05.0 cmd <- 143: 0x000f00sc Control.. 
PCI: 04:06.0 subsystem <- 10f1/2882                                   
PCI: 04:06.0 cmd <- 1c3         
           

    33:stre
PCI: 01:04.1 cmd <- 1410xfffe0000 - 0xfffe6fff
PCI: 01:04.2 subsystem <- 10f1/2882                            
Found 
PCI: 01:04.2 cmd <- 141                       
PCI: 01:04.3 subsystem <- 10f1/2882                      
Loading Ethe
PCI: 01:04.3 cmd <- 141                       
PCI: 00:18.1 subsystem <- 10f1/2882ing non PT_LOAD segment            
PCI: 00:18.1 cmd <- 140ot 5.2.6 (GPL) http://e
PCI: 00:18.2 subsystem <- 10f1/2882 hda4:/boot/vmlinuz initrd=/boot/in
PCI: 00:18.2 cmd <- 140ons                    
PCI: 00:18.3 cmd <- 140                       
PCI: 00:19.0 cmd <- 140                       
PCI: 00:19.1 cmd <- 140                       
hda: LBA48: HDS7280
Initializing CPU #0                 


CPU: vendor AMD device f5aack Fri Nov  4 13:59:37 CS
Enabling cache...           

Setting fixed MTRRs(0-88) type: UC                        
Found Lin
Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM

(0,1) link=01host) #
Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM       
02 nodes initialized.                    
DONE fixed MTRRsSBLink=00and lin
Setting variable MTRR 0, base:    0MB, range: 1024MB, type WB

ht reset -canning NU                    



DONE variable MTRRs2_Fallback Fri Nov 
Clear out the extra MTRR'sng...                     

MTRR check          
Fixed MTRRs   : Enabled    
Linux version     
Variable MTRRs: Enabledeko at buildho            

Setting up local apic..=01on 3               
Copying Lin
Enabling cachepe 16         

Setting fixed MTRRs(0-88) type: UCnuxBIOS.                     
 BIO
Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM4 13:59:37 CST 2005
booting...                  
Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM  
 BIOS-e820: 00000000000f0000 - 000            
DONE fixed MTRRs     
Enumeratin
Setting variable MTRR 0, base:    0MB, range: 1024MB, type WB

Scanning NU           
PCI_DOMAIN: 0000 enabl
DONE variable MTRRs              
CPU:
Clear out the extra MTRR's 0000000000               

MTRR check          
Fixed MTRRs   : Enabled/11                    
PCI: 00:19.1 [10
All AP CPUs stopped                   
PCI: 00:18.0 initr #17 INVAL      
PCI: 01:01.0 init 00:19.2 [1022/11
PCI: 02:09.0 init                 
PCI: 02:09.1 init#1           
PCI
PCI: 01:02.0 init03] enabled      
PCI: 01:03.0 init        
I
PCI: 
PCI: 04:05.0 init] enabled00.     
PCI: 04:06.0 init            
PCI:
rom address for PCI: 04:06.0 = fff80000: 0003

Incorrect Expansion ROM Header Signature 457fCI: 01:00.0 [1022/7460] enabled

PCI: 04:08.0 init
CPU 0: apertur
PCI: 01:04.0 init01:03.0 [1022/746
RTC Initd next_u
Invalid CMOS LB checksum                        
enabling HPET @0xf                 
PCI: 00:18.2 init                 
PCI: 00:18.3 initstatic device: PC
NB: Function 3 Misc Control.. done.           
Inode-cache hash table 
PCI: 00:19.0 init               
D
PCI: 00:19.1 initvice: PCI: 02:06.
PCI: 00:19.2 init                 
PCI: 00:19.3 init14e4/1648] enable
NB: Function 3 Misc Control.. done.                                   
PCI: 03:04.0 init        
PCI: 02:
Devices initializedbledk data, 220k in
Copying IRQ routing tables to 0xf0000...done.       
PCI: pci_scan_bus returning with max=
Wrote the mp table end at: 00000020 - 00000214 Moving GDT to 0x500...ok
Wrote linuxbios table at: 00000530 - 00000de4  checksum 9515

Welcome to elfboot, the open sourced starter.
January 2002, Eric Biederman.
Version 1.3

    33:stream_init() - rom_stream: 0xfffe0000 - 0xfffe6fff Found ELF
candiate at offset 0 Loading Etherboot version: 5.2.6 Dropping non PT_LOAD
segment New segment addr 0x20000 size 0x312bd offset 0xb0 filesize 0x6c5b
(cleaned up) New segment addr 0x20000 size 0x312bd offset 0xb0 filesize
0x6c5b Loading Segment: addr: 0x000000003ff90000 memsz:
0x000000000002a000
filesz:
0x0000000000006c5b
Clearing Segment: addr: 0x000000003ff96c5b memsz: 0x00000000000233a5 Loading
Segment: addr: 0x000000000004a000 memsz: 0x00000000000072bd
filesz:
0x0000000000000000
Clearing Segment: addr: 0x000000000004a000 memsz: 0x00000000000072bd Jumping
to boot code at 0x20000 ROM segment 0x0000 length 0x0000 reloc 0x00020000
CPU 2056 Mhz Etherboot 5.2.6 (GPL) http://etherboot.org Tagged ELF for
[FILO] Relocating _text from: [00026c60,00052870) to [3fed43f0,3ff00000)
Boot from (N)etwork (D)isk or (Q)uit?

Probing pci disk...it() - ro
Int BIOS-e820: 00000000000f0000 - 00000000000f0400 type 16i Nov  4
13:57:25
C
Virtual Wire compatibility mode
BIOS-e820: 0000000000100000 - 0000000040000000 (usable)>Product ID:
S2882
<6>APIC at: 0xFEE00000hda4 con
Scanning NUMA topology in Northbridge 24toppe New segment Virtual Wire
compatibility mode.
OEM ID: TYAN     <6>Product ID: S2882        <6>APIC at: 0xFEE00000
Processor #16 15:5 APIC version 16
Processor #17 15:5 APIC version 16
Processor #17 INVALID. (Max ID: 16).
I/O APIC #1 Version 17 at 0xFEC00000.
I/O APIC #2 Version 17 at 0xFD300000.
I/O APIC #3 Version 17 at 0xFD301000.
Processors: 2
Checking aperture...
CPU 0: aperture @ f8000000 size 64 MB
CPU 1: aperture @ f8000000 size 64 MB
Built 2 zonelists
Kernel command line: ro root=/dev/hda4 console=ttyS0,115200 Initializing
CPU#0 PID hash table entries: 4096 (order: 12, 131072 bytes)
time.c: Using 1.193182 MHz PIT timer.
time.c: Detected 1990.814 MHz processor.
Console: colour dummy device 80x25
Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Memory: 1023436k/1048576k available (2452k kernel code, 0k reserved, 942k
data, 220k init)


--
LinuxBIOS mailing list
LinuxBIOS at openbios.org
http://www.openbios.org/mailman/listinfo/linuxbios






--
LinuxBIOS mailing list
LinuxBIOS at openbios.org
http://www.openbios.org/mailman/listinfo/linuxbios





From yinghai.lu at amd.com  Mon Nov  7 20:21:19 2005
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Mon, 7 Nov 2005 11:21:19 -0800
Subject: [LinuxBIOS] S2882 Memory Hang
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E06206@ssvlexmb2.amd.com>

Actually you could remove that line....

lapic_write(LAPIC_ID,(0x10 + id.coreid*0x10 + id.nodeid) << 24);

====>

Node0, core0 (0): apicid = 0x10;  
Node0, core1 (1): apicid = 0x20;
Node1, core0 (2): apicid = 0x11;
Node1, core1 (3): apicid = 0x21;


lapic_write(LAPIC_ID,(id.coreid*0x10 + id.nodeid) << 24);

====>

Node0, core0 (0): apicid = 0;  
Node0, core1 (1): apicid = 0x10;
Node1, core0 (2): apicid = 1;
Node1, core1 (3): apicid = 0x11;

All are weird...


YH

-----Original Message-----
From: linuxbios-bounces at openbios.org
[mailto:linuxbios-bounces at openbios.org] On Behalf Of Matthew Simmons
Sent: Monday, November 07, 2005 10:55 AM
To: Lu, Yinghai; linuxbios at openbios.org
Subject: Re: [LinuxBIOS] S2882 Memory Hang

Here is what I did to make it work. In the
src/cpu/amd/dualcore/dualcore.c I
removed the 0x10 from the line:

lapic_write(LAPIC_ID,(0x10 + id.coreid*0x10 + id.nodeid) << 24);

The new line is:

lapic_write(LAPIC_ID,(id.coreid*0x10 + id.nodeid) << 24);

This worked correctly. And the system booted!

Thanks for your help,
Matt

-----Original Message-----
From: linuxbios-bounces at openbios.org
[mailto:linuxbios-bounces at openbios.org]
On Behalf Of Lu, Yinghai
Sent: Monday, November 07, 2005 11:16 AM
To: Matthew Simmons; linuxbios at openbios.org
Subject: Re: [LinuxBIOS] S2882 Memory Hang

src/cpu/amd/dualcore...

anyway that is some confusing..., it should be at
src/cpu/amd/model_fxx...

YH

-----Original Message-----
From: Matthew Simmons [mailto:matt at glw.com]
Sent: Monday, November 07, 2005 8:09 AM
To: Lu, Yinghai; linuxbios at openbios.org
Subject: RE: [LinuxBIOS] S2882 Memory Hang

I am having a little trouble locating the k8_secondart_stop function.
Could
you point me in the right direction? I looked in
src/southbridge/amd/amd8111/ and in src/mainboard/tyan/s2882/ as well as
src/northbridge/amd/amdk8.

I have hard coded the apicid_base to 4.

Thanks for your help,
Matt


-----Original Message-----
From: Lu, Yinghai [mailto:yinghai.lu at amd.com]
Sent: Friday, November 04, 2005 5:51 PM
To: Matthew Simmons; linuxbios at openbios.org
Subject: RE: [LinuxBIOS] S2882 Memory Hang

1. You don't need to lift your cpu apic id above 0x10.

2. for amd8111 sb, when you do that, kernel will hang, because jiffies
will
not change.

So remove 0x10 in your k8_secondart_stop.....
And hard code apicid_base to 4

It should work....

YH


-----Original Message-----
From: linuxbios-bounces at openbios.org
[mailto:linuxbios-bounces at openbios.org] On Behalf Of Matthew Simmons
Sent: Friday, November 04, 2005 2:11 PM
To: linuxbios at openbios.org
Subject: [LinuxBIOS] S2882 Memory Hang

I am currently trying get LinuxBios up and running on my Tyan S2882.
After
hard coding the apicid_base = 1 in the mptable.c I was finally able to
successfully build a bios image for my system. I am using filo as the
payload and the configuration of that went well. 
 
Both LinuxBios and filo are working as expected. The problem occurs when
I
attempt to boot the kernel. The kernel stops after the memory manager
loads.
There are no errors or panics. The system just locks up. 
 
I was wondering if any of you have seen this problem, or know of a work
around. I am including the kernel output from the serial console. As
well as
a brief description of the configuration of the system.
 
Thanks for your help,
Matthew Simmons


 
Configuration:
----------------------------------------------
Tyan S2882 2x Opteron 248 Processors
1024mb Ram (512x per processor)
LinuxBIOSv2 (Revision 2084)
Kernel: 2.6.12.1 with the Realtime Preempt Patch Base OS: SuSE 9.2 GCC
version: 3.3.2
 
 
Serial Console Output: (Sorry for the length)
------------------------------------------------
LinuxBIOS-1.1.8_s2882_Fallback Fri Nov  4 12:47:40 CST 2005 starting...

(0,1) link=01             
(1,0) link=01             
02 nodes initialized.                     
SBLink=00         
NC node|link=00               
Ram1.00       
Ram1.01       
Ram2.00       
Ram2.01       
Ram3    
Initializing memory:  done                          
Initializing memory:  done                          
Clearing initial memory region:  done

Ram4    
Copying LinuxBIOS to ram.                         
Jumping to LinuxBIOS.                     
LinuxBIOS-1.1.8_s2882_Fallback Fri Nov  4 12:47:40 CST 2005 booting...

Enumerating buses...                    
APIC_CLUSTER: 0 enabled                       
PCI_DOMAIN: 0000 enabled                        
CPU: APIC: 10 enabled                     
PCI: 00:19.0 [1022/1100] enabled                                
PCI: 00:19.1 [1022/1101] enabled                                
PCI: 00:19.2 [1022/1102] enabled                                
PCI: 00:19.3 [1022/1103] enabled                                
CPU: APIC: 11 enabled                     
PCI: pci_scan_bus for bus 0                           
PCI: 00:18.0 [1022/1100] enabled                                
PCI: 00:18.1 [1022/1101] enabled                                
PCI: 00:18.2 [1022/1102] enabled                                
PCI: 00:18.3 [1022/1103] enabled                                
PCI: 00:19.0 [1022/1100] enabled                                
PCI: 00:19.1 [1022/1101] enabled                                
PCI: 00:19.2 [1022/1102] enabled                                
PCI: 00:19.3 [1022/1103] enabled                                
PCI: 01:00.0 [1022/7450] en                          
PCI: 01:01.0 [1022/7450] enabled next_unitid: 0003

PCI: 01:00.0 [1022/7460] enabled                                
PCI: 01:03.0 [1022/7460] enabled next_unitid: 0007

PCI: pci_scan_bus for bus 1                           
PCI: 01:01.0 [1022/7450] enabled                                
PCI: 01:01.1 [1022/7451] enabled                                
PCI: 01:02.0 [1022/7450] enabled                                
PCI: 01:02.1 [1022/7451] enabled                                
PCI: 01:03.0 [1022/7460] enabled                                
PCI: 01:04.0 [1022/7468] enabled                                
PCI: 01:04.1 [1022/7469] enabled                                
PCI: 01:04.2 [1022/746a] enabled                                
PCI: 01:04.3 [1022/746b] enabled                                
PCI: pci_scan_bus for bus 2                           
Disabling static device: PCI: 0                              
Disabling static device: PCI: 02:06.1

PCI: 02:09.0 [14e4/1648] enabled                                
PCI: 02:09.1 [14e4/1648] enabled                                
PCI: pci_scan_bus returning with max=02

PCI: 02: 100MHz PCI-X                     
PCI: pci_scan_bus for bus 3                           
PCI: 03:04.0 [10ee/3fc6] enabled                                
PCI: pci_scan_bus returning with max=03

PCI: 03: Conventional PCI                         
PCI: pci_scan_bus for bus 4                           
PCI: 04:00.0 [1022/7464] enabled                                
PCI: 04:00.1 [1022/7464] enabled                                
PCI: 04:05.0 [1095/3114] enabled                                
PCI: 04:06.0 [1002/4752] enabled                                
PCI: 04:08.0 [8086/1229] enabled                                
PCI: pci_scan_bus returning with m                                
PNP: 002e.0 enabled                   
PNP: 002e.1 disabled                    
PNP: 002e.2 enabled                   
PNP: 002e.3 disabled                    
PNP: 002e.5 enabled                   
PNP: 002e.6 disabled                    
PNP: 002e.7 disabled                    
PNP: 002e.8 disabled                    
PNP: 002e.9 disabled                    
PNP: 002e.a disabled                    
PNP: 002e.b enabled                   
PCI: pci_scan_bus returning with max=04

PCI: pci_scan_bus returning with max=04

done    
Allocating resources...                       
Reading resources...                    
PCI: 01:01.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 2 io

PCI: 01:01.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 2
prefmem

PCI: 01:02.0 1c <- [0x00fffff00                              
PCI: 01:02.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 3
prefmem
map page: 16ee: 118                          
Cannot map page: 16f       
PCI: 01:03.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 4 prefmem

Cannot map pag              
Cannot map p
Done reading resources.        
Cannot map pag
Allocating VGA resource PCI: 04:06.0                             
Cannot
Setting PCI_BRIDGE_CTL_VGA for bridge PCI: 01:03.0 map page: 174xtra
MTRR'sd
<                      
Setting PCI_BRIDGE_CTL_VGA for bridge PCI: 00:18.0  
Cannot map          
Cannot map page: 176      
Setting PCI_BRIDGE_CTL_VGA for bridge PCI_DOMAIN: 0000            

Cannot map page: 178 page: 14b          
Setting PCI_BRIDGE_CTL_VGA for bridge Root Devicep page: 14c

Setting resources...7a                  
PCI: 00:18.0 1b8 <- [0x00fd400000 - 0x00fd3fffff] prefmem <node 0 link
0>

Cannot map page:                
Cannot map page: 17d   
PCI: 01:02.1 10 <- [0x00fd301000 - 0x00fd301fff] mem64map page: 17

Cannot map page: 1a8
PCI: 01:03.0 1c <- [0x0000001000 - 0x0000001fff] bus 4 io page: 18

Cannot map page: 1
PCI: 01:03.0 20 <- [0x00fc000000 - 0x00fd0fffff] bus 4 memge: 191

Cannot map page: 1acnot
PCI: 04:00.0 10 <- [0x00fd020000 - 0x00fd020fff] meme: 1ading f

Cannot map page
PCI: 04:00.1 10 <- [0x00fd021000 - 0x00fd021fff] mem  
Cannot map page: 1aft map                        
PCI: 04:05.0 10 <- [0x0000001450 - 0x0000001457] ioCann    
Cannot map page: 1b1age: 19566e: 124M, W
PCI: 04:05.0 14 <- [0x0000001470 - 0x0000001473] ioge: 1b

Cannot map page: 1bcot ma
PCI: 04:05.0 18 <- [0x0000001460 - 0x0000001467] ioot map page: 1bdot
map

Ca
PCI: 04:05.0 1c <- [0x00000014                        
   
PNP: 002e.0 70 <- [0x0000000006 - 0x0000000006] irq     
Cannot map page: 1de                    
Cann
PNP: 002e.0 74 <- [0x0000000002 - 0x0000000002] drq           
P
C 
Can   

-Cannot map page: 1e0t ma
PNP: 002e.2 60 <- [0x00000003f8 - 0x00000003ff] ionot map page: 1e1

Cannot ma   
PNP: 002e.2 70 <- [0x0000000004 - 0x0000000004] irqo     
Cannot map page: 1e3ot map page: 1ca        
PNP: 002e.5 60 <- [0x0000000060 - 0x0000000060] io                  


Cannot map page: 1f4         
PNP: 002e.5 62 <- [0x0000000064 - 0x0000000064] io              
Cannot      
Cannot map page: 1f6
PNP: 002e.5 70 <- [0x0000000001 - 0x0000000001] irq: 1f7

Cannot m        
Cannot m
PNP: 002e.5 72 <- [0x000000000c - 0x000000000c] irq                    
Cannot map page: 1f9Cannot map
PNP: 002e.b 60 <- [0x0000000290 - 0x0000000297] ioage: 1faage: 1ee

Canno
PNP: 002e.b 70 <- [0x0000000005 - 0x0000000005] irq

Cannot map page            
PNP: 002e.5 init        
PCI: 01:01.1 cmd <- 146b i             
NB: Fu
PCI: 01:02.0 bridge ctrl <- 0003                               

PCI: 01:02.0 cmd <- 1460ot ma                 
PCI: 03:04.0 cmd <- 142.0 init                
PCI: 01:02.1 subsystem <- 10f1/2882    
PNP: 002e.0 initd             
PCI: 01:02.1 cmd <- 146 tables to 0xf0000...do
PCI: 01:03.0 bridge ctrl <- 000b                                
PCI: 01:03.0 cmd <- 147ng copy of IRQ routing 
PCI: 04:00.0 subsystem <- 10f1/2882                                   
PCI: 04:00.0 cmd <- 142PCI: 00:19.1 init:06.0
PCI: 04:00.1 subsystem <- 10f1/2882RQ routing table consistency...PCI:
PCI: 04:00.1 cmd <- 142                       
PCI: 04:05.0 subsystem <- 10f1/2882
check_pirq_routing_table() - irq_
PCI: 04:05.0 cmd <- 143: 0x000f00sc Control.. 
PCI: 04:06.0 subsystem <- 10f1/2882                                   
PCI: 04:06.0 cmd <- 1c3         
           

    33:stre
PCI: 01:04.1 cmd <- 1410xfffe0000 - 0xfffe6fff
PCI: 01:04.2 subsystem <- 10f1/2882                            
Found 
PCI: 01:04.2 cmd <- 141                       
PCI: 01:04.3 subsystem <- 10f1/2882                      
Loading Ethe
PCI: 01:04.3 cmd <- 141                       
PCI: 00:18.1 subsystem <- 10f1/2882ing non PT_LOAD segment            
PCI: 00:18.1 cmd <- 140ot 5.2.6 (GPL) http://e
PCI: 00:18.2 subsystem <- 10f1/2882 hda4:/boot/vmlinuz initrd=/boot/in
PCI: 00:18.2 cmd <- 140ons                    
PCI: 00:18.3 cmd <- 140                       
PCI: 00:19.0 cmd <- 140                       
PCI: 00:19.1 cmd <- 140                       
hda: LBA48: HDS7280
Initializing CPU #0                 


CPU: vendor AMD device f5aack Fri Nov  4 13:59:37 CS
Enabling cache...           

Setting fixed MTRRs(0-88) type: UC                        
Found Lin
Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM

(0,1) link=01host) #
Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM       
02 nodes initialized.                    
DONE fixed MTRRsSBLink=00and lin
Setting variable MTRR 0, base:    0MB, range: 1024MB, type WB

ht reset -canning NU                    



DONE variable MTRRs2_Fallback Fri Nov 
Clear out the extra MTRR'sng...                     

MTRR check          
Fixed MTRRs   : Enabled    
Linux version     
Variable MTRRs: Enabledeko at buildho            

Setting up local apic..=01on 3               
Copying Lin
Enabling cachepe 16         

Setting fixed MTRRs(0-88) type: UCnuxBIOS.                     
 BIO
Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM4 13:59:37 CST 2005
booting...                  
Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM  
 BIOS-e820: 00000000000f0000 - 000            
DONE fixed MTRRs     
Enumeratin
Setting variable MTRR 0, base:    0MB, range: 1024MB, type WB

Scanning NU           
PCI_DOMAIN: 0000 enabl
DONE variable MTRRs              
CPU:
Clear out the extra MTRR's 0000000000               

MTRR check          
Fixed MTRRs   : Enabled/11                    
PCI: 00:19.1 [10
All AP CPUs stopped                   
PCI: 00:18.0 initr #17 INVAL      
PCI: 01:01.0 init 00:19.2 [1022/11
PCI: 02:09.0 init                 
PCI: 02:09.1 init#1           
PCI
PCI: 01:02.0 init03] enabled      
PCI: 01:03.0 init        
I
PCI: 
PCI: 04:05.0 init] enabled00.     
PCI: 04:06.0 init            
PCI:
rom address for PCI: 04:06.0 = fff80000: 0003

Incorrect Expansion ROM Header Signature 457fCI: 01:00.0 [1022/7460]
enabled

PCI: 04:08.0 init
CPU 0: apertur
PCI: 01:04.0 init01:03.0 [1022/746
RTC Initd next_u
Invalid CMOS LB checksum                        
enabling HPET @0xf                 
PCI: 00:18.2 init                 
PCI: 00:18.3 initstatic device: PC
NB: Function 3 Misc Control.. done.           
Inode-cache hash table 
PCI: 00:19.0 init               
D
PCI: 00:19.1 initvice: PCI: 02:06.
PCI: 00:19.2 init                 
PCI: 00:19.3 init14e4/1648] enable
NB: Function 3 Misc Control.. done.                                   
PCI: 03:04.0 init        
PCI: 02:
Devices initializedbledk data, 220k in
Copying IRQ routing tables to 0xf0000...done.       
PCI: pci_scan_bus returning with max=
Wrote the mp table end at: 00000020 - 00000214 Moving GDT to 0x500...ok
Wrote linuxbios table at: 00000530 - 00000de4  checksum 9515

Welcome to elfboot, the open sourced starter.
January 2002, Eric Biederman.
Version 1.3

    33:stream_init() - rom_stream: 0xfffe0000 - 0xfffe6fff Found ELF
candiate at offset 0 Loading Etherboot version: 5.2.6 Dropping non
PT_LOAD
segment New segment addr 0x20000 size 0x312bd offset 0xb0 filesize
0x6c5b
(cleaned up) New segment addr 0x20000 size 0x312bd offset 0xb0 filesize
0x6c5b Loading Segment: addr: 0x000000003ff90000 memsz:
0x000000000002a000
filesz:
0x0000000000006c5b
Clearing Segment: addr: 0x000000003ff96c5b memsz: 0x00000000000233a5
Loading
Segment: addr: 0x000000000004a000 memsz: 0x00000000000072bd
filesz:
0x0000000000000000
Clearing Segment: addr: 0x000000000004a000 memsz: 0x00000000000072bd
Jumping
to boot code at 0x20000 ROM segment 0x0000 length 0x0000 reloc
0x00020000
CPU 2056 Mhz Etherboot 5.2.6 (GPL) http://etherboot.org Tagged ELF for
[FILO] Relocating _text from: [00026c60,00052870) to [3fed43f0,3ff00000)
Boot from (N)etwork (D)isk or (Q)uit?

Probing pci disk...it() - ro
Int BIOS-e820: 00000000000f0000 - 00000000000f0400 type 16i Nov  4
13:57:25
C
Virtual Wire compatibility mode
BIOS-e820: 0000000000100000 - 0000000040000000 (usable)>Product ID:
S2882
<6>APIC at: 0xFEE00000hda4 con
Scanning NUMA topology in Northbridge 24toppe New segment Virtual Wire
compatibility mode.
OEM ID: TYAN     <6>Product ID: S2882        <6>APIC at: 0xFEE00000
Processor #16 15:5 APIC version 16
Processor #17 15:5 APIC version 16
Processor #17 INVALID. (Max ID: 16).
I/O APIC #1 Version 17 at 0xFEC00000.
I/O APIC #2 Version 17 at 0xFD300000.
I/O APIC #3 Version 17 at 0xFD301000.
Processors: 2
Checking aperture...
CPU 0: aperture @ f8000000 size 64 MB
CPU 1: aperture @ f8000000 size 64 MB
Built 2 zonelists
Kernel command line: ro root=/dev/hda4 console=ttyS0,115200 Initializing
CPU#0 PID hash table entries: 4096 (order: 12, 131072 bytes)
time.c: Using 1.193182 MHz PIT timer.
time.c: Detected 1990.814 MHz processor.
Console: colour dummy device 80x25
Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Memory: 1023436k/1048576k available (2452k kernel code, 0k reserved,
942k
data, 220k init)


--
LinuxBIOS mailing list
LinuxBIOS at openbios.org
http://www.openbios.org/mailman/listinfo/linuxbios






--
LinuxBIOS mailing list
LinuxBIOS at openbios.org
http://www.openbios.org/mailman/listinfo/linuxbios



-- 
LinuxBIOS mailing list
LinuxBIOS at openbios.org
http://www.openbios.org/mailman/listinfo/linuxbios





From gjohnson at lanl.gov  Mon Nov  7 21:21:32 2005
From: gjohnson at lanl.gov (Greg Johnson)
Date: Mon, 7 Nov 2005 13:21:32 -0700
Subject: [LinuxBIOS] dual core disable?
Message-ID: <20051107202132.GB2363@durango.c3.lanl.gov>

Disabling dual core on our s2891 boards with Opteron 270's doesn't seem
to work properly.  When I boot with dual core disabled, I am getting two
cores on one socket enabled and none on the other socket.  Here's 
/proc/cpuinfo with dual core disabled:

p5:~# cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 33
model name      : unknown
stepping        : 2
cpu MHz         : 2010.318
cache size      : 1024 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 2
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni lahf_lm cmp_legacy
bogomips        : 4029.78
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp

processor       : 1
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 33
model name      : unknown
stepping        : 2
cpu MHz         : 2010.318
cache size      : 1024 KB
physical id     : 0
siblings        : 2
core id         : 1
cpu cores       : 2
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni lahf_lm cmp_legacy
bogomips        : 4020.90
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp


It also performs like it's using both cores on one socket.  Any
thoughts?

Thanks,

Greg




From matt at glw.com  Mon Nov  7 21:52:45 2005
From: matt at glw.com (Matthew Simmons)
Date: Mon, 7 Nov 2005 14:52:45 -0600
Subject: [LinuxBIOS] S2882 - Fallback Only?
Message-ID: <20051107205045.A84A04C48F@mail.glw.com>

First off thanks for your help with the APIC problems on my system.
 
Now I am trying to straighten out the boot sequence. I have noticed that I
am booting off the fallback image. Both images are build using the payload
and the same configuration. However, I would like to use Filo with USB disk
support, and that increased Filo's size by 50% from 24K to 34K. This makes
filo large to fit inside of the 131K room for the fallback rom image.
 
Is there any help you guys could give me as to why I am not booting off the
primary image?
 
Thanks,
Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20051107/df3a3232/attachment.html>

From yinghai.lu at amd.com  Mon Nov  7 21:51:29 2005
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Mon, 7 Nov 2005 12:51:29 -0800
Subject: [LinuxBIOS] dual core disable?
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E06209@ssvlexmb2.amd.com>

That's OK, the kernel problem....

It assumes all nbcfg 54 bit is set.....with out check it.

So it could treat Node1/core0 as Node0/Core1....

YH

-----Original Message-----
From: linuxbios-bounces at openbios.org
[mailto:linuxbios-bounces at openbios.org] On Behalf Of Greg Johnson
Sent: Monday, November 07, 2005 12:22 PM
To: linuxbios at openbios.org
Subject: [LinuxBIOS] dual core disable?

Disabling dual core on our s2891 boards with Opteron 270's doesn't seem
to work properly.  When I boot with dual core disabled, I am getting two
cores on one socket enabled and none on the other socket.  Here's 
/proc/cpuinfo with dual core disabled:

p5:~# cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 33
model name      : unknown
stepping        : 2
cpu MHz         : 2010.318
cache size      : 1024 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 2
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext
fxsr_opt lm 3dnowext 3dnow pni lahf_lm cmp_legacy
bogomips        : 4029.78
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp

processor       : 1
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 33
model name      : unknown
stepping        : 2
cpu MHz         : 2010.318
cache size      : 1024 KB
physical id     : 0
siblings        : 2
core id         : 1
cpu cores       : 2
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext
fxsr_opt lm 3dnowext 3dnow pni lahf_lm cmp_legacy
bogomips        : 4020.90
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp


It also performs like it's using both cores on one socket.  Any
thoughts?

Thanks,

Greg


-- 
LinuxBIOS mailing list
LinuxBIOS at openbios.org
http://www.openbios.org/mailman/listinfo/linuxbios





From yinghai.lu at amd.com  Mon Nov  7 22:03:26 2005
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Mon, 7 Nov 2005 13:03:26 -0800
Subject: [LinuxBIOS] S2882 - Fallback Only?
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E0620A@ssvlexmb2.amd.com>

Don't need.

 

You can put the payload as follow

 

FULL_FILO_WITH_USB+NORMAL_IMAGE+FALLBACK_IMAGE

 

Then you make filo to be very simple one with command line to boot the
FULL_FILO_WITH_USB in FLASH.

 

Or you can use tiny kernel as payload for normal back, then fallback can
jump that kernel.

 

Please check README.filo_in_etherboot for more command lines about 

mem at 0xfffe0000

 

you may need to subtract the size for VGA Option rom on flash if you are
using it.

 

YH

 

________________________________

From: linuxbios-bounces at openbios.org
[mailto:linuxbios-bounces at openbios.org] On Behalf Of Matthew Simmons
Sent: Monday, November 07, 2005 12:53 PM
To: linuxbios at openbios.org
Subject: [LinuxBIOS] S2882 - Fallback Only?

 

First off thanks for your help with the APIC problems on my system.

 

Now I am trying to straighten out the boot sequence. I have noticed that
I am booting off the fallback image. Both images are build using the
payload and the same configuration. However, I would like to use Filo
with USB disk support, and that increased Filo's size by 50% from 24K to
34K. This makes filo large to fit inside of the 131K room for the
fallback rom image.

 

Is there any help you guys could give me as to why I am not booting off
the primary image?

 

Thanks,

Matt

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20051107/16558e35/attachment.html>

From rminnich at lanl.gov  Tue Nov  8 00:29:30 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 07 Nov 2005 16:29:30 -0700
Subject: [LinuxBIOS] S2882 - Fallback Only?
In-Reply-To: <20051107205045.A84A04C48F@mail.glw.com>
References: <20051107205045.A84A04C48F@mail.glw.com>
Message-ID: <436FE35A.5060008@lanl.gov>

Matthew Simmons wrote:

> Is there any help you guys could give me as to why I am not booting off 
> the primary image?

you need a clean checksum -- you need cmos_utils (use google to find 
them) so you have a good cmos checksum

ron



From rminnich at lanl.gov  Tue Nov  8 00:40:12 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 07 Nov 2005 16:40:12 -0700
Subject: [LinuxBIOS] dual core disable?
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4201E06209@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4201E06209@ssvlexmb2.amd.com>
Message-ID: <436FE5DC.8080909@lanl.gov>

Lu, Yinghai wrote:
> That's OK, the kernel problem....

how is that ok?
> 
> It assumes all nbcfg 54 bit is set.....with out check it.

so how do we fix it?

ron



From yinghai.lu at amd.com  Tue Nov  8 00:00:09 2005
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Mon, 7 Nov 2005 15:00:09 -0800
Subject: [LinuxBIOS] dual core disable?
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E0620D@ssvlexmb2.amd.com>

?

In Normal BIOS, is there option to disable dual core?

YH

-----Original Message-----
From: Ronald G Minnich [mailto:rminnich at lanl.gov] 
Sent: Monday, November 07, 2005 3:40 PM
To: Lu, Yinghai
Cc: Greg Johnson; linuxbios at openbios.org
Subject: Re: [LinuxBIOS] dual core disable?

Lu, Yinghai wrote:
> That's OK, the kernel problem....

how is that ok?
> 
> It assumes all nbcfg 54 bit is set.....with out check it.

so how do we fix it?

ron





From okajima at digitalinfra.co.jp  Mon Nov  7 23:59:54 2005
From: okajima at digitalinfra.co.jp (Jun OKAJIMA)
Date: Tue, 08 Nov 2005 07:59:54 +0900
Subject: [LinuxBIOS] EPIA-M VGA
In-Reply-To: <436EFD96.5000204@lanl.gov>
References: <436EFD96.5000204@lanl.gov>
Message-ID: <200511072259.AA00453@bbb-jz5c7z9hn9y.digitalinfra.co.jp>





Your video BIOS is same as mine?
If not, maybe it is a cause?

BTW, I found that video BIOS does not stay on same location of usual one,
when I am using LX2 BIOS.
Is this correct? If so, where it stays?


             --- Okajima, Jun. Tokyo, Japan.

-----------------
okajima at Debian:~/lx2$ ls -la video.bios.bin
-rw-r--r--    1 root     root        65536 Nov  6 05:14 video.bios.bin
okajima at Debian:~/lx2$ md5sum video.bios.bin
d7980d838d24a12aec497d6fe19c1bf5  video.bios.bin
okajima at Debian:~$ ls -la *.bin
-rw-r--r--    1 root     root       262144 Nov  8 07:51 lx2.bin
-rw-r--r--    1 root     root       262144 Nov  8 07:51 via.bin
okajima at Debian:~$ md5sum *.bin
fee442a3333f48904fcb9c8a4c2e22c5  lx2.bin
4219b481dbc64ce5f26a94fb9a70d017  via.bin
root at Debian:~# bin/flash_rom -v linuxbios.rom
SST39SF020A found at physical address: 0xfffc0000
Part is SST39SF020A
Verifying address:
result: VERIFIED
---------------------------

>Jun OKAJIMA wrote:
>> And the log of failure session is this.
>> I dont have success one, sorry.
>> 
>> These lines are same as yours?
>> 
>>  > VGA random fixup ...
>>  > INSTALL REAL-MODE IDT
>>  > DO THE VGA BIOS
>>  > found VGA: vid=1106, did=3122
>>  > rom base, size: fffc0000
>>  > BAD SIGNATURE 0x8 0x1e
>>  > biosint: # 0x10, eax 0x4f14 ebx 0x18003 ecx 0x1 edx 0x0
>>  > biosint: ebp 0x17fa0 esp 0xffa edi 0x0 esi 0x187c8
>>  > biosint: ip 0xb565 cs 0x0 flags 0x46
>>  > BIOSINT: Unsupport int #0x10
>
>
>This confuses me. The BAD SIGNATURE IIRC means that there is no valid 
>signature in the ROM image. So the VGA bios should not be run.
>
>So where is that biosint call coming from if not vga? This makes no 
>sense to me at all.
>
>ron
>



From gjohnson at lanl.gov  Tue Nov  8 00:37:01 2005
From: gjohnson at lanl.gov (Greg Johnson)
Date: Mon, 7 Nov 2005 16:37:01 -0700
Subject: [LinuxBIOS] dual core disable?
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4201E0620D@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4201E0620D@ssvlexmb2.amd.com>
Message-ID: <20051107233701.GC2363@durango.c3.lanl.gov>

On Mon, Nov 07, 2005 at 03:00:09PM -0800, Lu, Yinghai wrote:
> ?
> 
> In Normal BIOS, is there option to disable dual core?
> 

No.  I'm pretty sure that I'm really getting two cores on one socket.
Memory bandwidth is affected when running on both cores.  In any case,
Linux K8 NUMA is confused:

p5:~# numactl --show
policy: default
preferred node: current
cpubind: 0
membind: 0 1

Greg



From yinghai.lu at amd.com  Tue Nov  8 00:55:01 2005
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Mon, 7 Nov 2005 15:55:01 -0800
Subject: [LinuxBIOS] dual core disable?
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E0620E@ssvlexmb2.amd.com>

OK, 

We may need to set the nbcfg 54 bit even disable the dual core.

Please several lines
1. src/cpu/dualcore/dualcore.c 
//If(read_option(CMOS_VSTART_dual_core.....
2. in you cache_as_ram_auto.c
//#if CONFIG_LOGICAL_CPUS == 1
	Set_apicid_cpuid_lo();
//#endif

YH


-----Original Message-----
From: Greg Johnson [mailto:gjohnson at lanl.gov] 
Sent: Monday, November 07, 2005 3:37 PM
To: Lu, Yinghai
Cc: Ronald G Minnich; Greg Johnson; linuxbios at openbios.org
Subject: Re: [LinuxBIOS] dual core disable?

On Mon, Nov 07, 2005 at 03:00:09PM -0800, Lu, Yinghai wrote:
> ?
> 
> In Normal BIOS, is there option to disable dual core?
> 

No.  I'm pretty sure that I'm really getting two cores on one socket.
Memory bandwidth is affected when running on both cores.  In any case,
Linux K8 NUMA is confused:

p5:~# numactl --show
policy: default
preferred node: current
cpubind: 0
membind: 0 1

Greg





From gjohnson at lanl.gov  Tue Nov  8 01:02:57 2005
From: gjohnson at lanl.gov (Greg Johnson)
Date: Mon, 7 Nov 2005 17:02:57 -0700
Subject: [LinuxBIOS] dual core disable?
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4201E0620E@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4201E0620E@ssvlexmb2.amd.com>
Message-ID: <20051108000257.GD2363@durango.c3.lanl.gov>

BTW, How come you don't use the CPU1 Enable (Cpu1En) bit to disable the
second core?

Greg


On Mon, Nov 07, 2005 at 03:55:01PM -0800, Lu, Yinghai wrote:
> OK, 
> 
> We may need to set the nbcfg 54 bit even disable the dual core.
> 
> Please several lines
> 1. src/cpu/dualcore/dualcore.c 
> //If(read_option(CMOS_VSTART_dual_core.....
> 2. in you cache_as_ram_auto.c
> //#if CONFIG_LOGICAL_CPUS == 1
> 	Set_apicid_cpuid_lo();
> //#endif
> 
> YH
> 
> 
> -----Original Message-----
> From: Greg Johnson [mailto:gjohnson at lanl.gov] 
> Sent: Monday, November 07, 2005 3:37 PM
> To: Lu, Yinghai
> Cc: Ronald G Minnich; Greg Johnson; linuxbios at openbios.org
> Subject: Re: [LinuxBIOS] dual core disable?
> 
> On Mon, Nov 07, 2005 at 03:00:09PM -0800, Lu, Yinghai wrote:
> > ?
> > 
> > In Normal BIOS, is there option to disable dual core?
> > 
> 
> No.  I'm pretty sure that I'm really getting two cores on one socket.
> Memory bandwidth is affected when running on both cores.  In any case,
> Linux K8 NUMA is confused:
> 
> p5:~# numactl --show
> policy: default
> preferred node: current
> cpubind: 0
> membind: 0 1
> 
> Greg
> 



From yinghai.lu at amd.com  Tue Nov  8 01:19:09 2005
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Mon, 7 Nov 2005 16:19:09 -0800
Subject: [LinuxBIOS] dual core disable?
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E0620F@ssvlexmb2.amd.com>

That bit is cleared default, and if you don't want to dual core, you
don't need to set it....

YH

-----Original Message-----
From: linuxbios-bounces at openbios.org
[mailto:linuxbios-bounces at openbios.org] On Behalf Of Greg Johnson
Sent: Monday, November 07, 2005 4:03 PM
To: Lu, Yinghai
Cc: Greg Johnson; linuxbios at openbios.org
Subject: Re: [LinuxBIOS] dual core disable?

BTW, How come you don't use the CPU1 Enable (Cpu1En) bit to disable the
second core?

Greg


On Mon, Nov 07, 2005 at 03:55:01PM -0800, Lu, Yinghai wrote:
> OK, 
> 
> We may need to set the nbcfg 54 bit even disable the dual core.
> 
> Please several lines
> 1. src/cpu/dualcore/dualcore.c 
> //If(read_option(CMOS_VSTART_dual_core.....
> 2. in you cache_as_ram_auto.c
> //#if CONFIG_LOGICAL_CPUS == 1
> 	Set_apicid_cpuid_lo();
> //#endif
> 
> YH
> 
> 
> -----Original Message-----
> From: Greg Johnson [mailto:gjohnson at lanl.gov] 
> Sent: Monday, November 07, 2005 3:37 PM
> To: Lu, Yinghai
> Cc: Ronald G Minnich; Greg Johnson; linuxbios at openbios.org
> Subject: Re: [LinuxBIOS] dual core disable?
> 
> On Mon, Nov 07, 2005 at 03:00:09PM -0800, Lu, Yinghai wrote:
> > ?
> > 
> > In Normal BIOS, is there option to disable dual core?
> > 
> 
> No.  I'm pretty sure that I'm really getting two cores on one socket.
> Memory bandwidth is affected when running on both cores.  In any case,
> Linux K8 NUMA is confused:
> 
> p5:~# numactl --show
> policy: default
> preferred node: current
> cpubind: 0
> membind: 0 1
> 
> Greg
> 

-- 
LinuxBIOS mailing list
LinuxBIOS at openbios.org
http://www.openbios.org/mailman/listinfo/linuxbios





From yinghai.lu at amd.com  Tue Nov  8 01:33:08 2005
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Mon, 7 Nov 2005 16:33:08 -0800
Subject: [LinuxBIOS] dual core disable?
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E06210@ssvlexmb2.amd.com>

Northbridge.c cpu_bus_scan need to be modified too, you need to assume
the CONFIG_LOGICAL_CPU==1 there..

YH

-----Original Message-----
From: linuxbios-bounces at openbios.org
[mailto:linuxbios-bounces at openbios.org] On Behalf Of Lu, Yinghai
Sent: Monday, November 07, 2005 3:55 PM
To: Greg Johnson
Cc: linuxbios at openbios.org
Subject: Re: [LinuxBIOS] dual core disable?

OK, 

We may need to set the nbcfg 54 bit even disable the dual core.

Please several lines
1. src/cpu/dualcore/dualcore.c 
//If(read_option(CMOS_VSTART_dual_core.....
2. in you cache_as_ram_auto.c
//#if CONFIG_LOGICAL_CPUS == 1
	Set_apicid_cpuid_lo();
//#endif

YH


-----Original Message-----
From: Greg Johnson [mailto:gjohnson at lanl.gov] 
Sent: Monday, November 07, 2005 3:37 PM
To: Lu, Yinghai
Cc: Ronald G Minnich; Greg Johnson; linuxbios at openbios.org
Subject: Re: [LinuxBIOS] dual core disable?

On Mon, Nov 07, 2005 at 03:00:09PM -0800, Lu, Yinghai wrote:
> ?
> 
> In Normal BIOS, is there option to disable dual core?
> 

No.  I'm pretty sure that I'm really getting two cores on one socket.
Memory bandwidth is affected when running on both cores.  In any case,
Linux K8 NUMA is confused:

p5:~# numactl --show
policy: default
preferred node: current
cpubind: 0
membind: 0 1

Greg



-- 
LinuxBIOS mailing list
LinuxBIOS at openbios.org
http://www.openbios.org/mailman/listinfo/linuxbios





From okajima at digitalinfra.co.jp  Tue Nov  8 04:03:06 2005
From: okajima at digitalinfra.co.jp (Jun OKAJIMA)
Date: Tue, 08 Nov 2005 12:03:06 +0900
Subject: [LinuxBIOS] EPIA-M VGA
In-Reply-To: <200511072259.AA00453@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
References: <200511072259.AA00453@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
Message-ID: <200511080303.AA00454@bbb-jz5c7z9hn9y.digitalinfra.co.jp>



progressed ---

the doc which Nick gave has a mistake.
use this to get VGA BIOS.
# dd if=/dev/mem of=video.bios.bin.4 bs=1 count=65536 skip=786432
786432 is 0xc0000, and 790528 which Nich told is 0xc1000.
My hash codes are:
okajima at Debian:~/lx2/LinuxBIOSv2-2084$ md5sum video.bios.bin.c*
26dcdde20308778d4a86628b82b215ba  video.bios.bin.c0000
d7980d838d24a12aec497d6fe19c1bf5  video.bios.bin.c1000


Then, VGA BIOS was recognized. But still no screen comes.
Probably, 
> biosint: Oops, exception 60x6a1f 0xc000 0x0046 0x7fa0 0x89b5 0xb6e1 0x0000
> biosint: Bailing out
here is the problem. Any idea?



                         --- Okajima, Jun. Tokyo, Japan.


VGA random fixup ...
INSTALL REAL-MODE IDT
DO THE VGA BIOS
found VGA: vid=1106, did=3122
rom bawrite_protect_vgabios
bus/devfn = 0x100
biosint: # 0x6, eax 0x5f00 ebx 0x187c8 ecx 0x17fa0 edx 0xa
biosint: ebp 0x17f70 esp 0xfec edi 0xe850 esi 0x187c8
biosint: ip 0xf859 cs 0xf000 flags 0x46
biosint: Oops, exception 60x6a1f 0xc000 0x0046 0x7fa0 0x89b5 0xb6e1 0x0000
biosint: Bailing out
sp 0xffa edi 0x0 esi 0x187c8ebx 0x18003 ecx 0x1 edx 0x0
biosint: ip 0xb565 cs 0x0 flags 0x46
BIOSINT: Unsupport int #0x10








------------

LinuxBIOS-1.1.llback Tue Nov  8 10:20:46 UTC 2tarting...
 Enabling mainboard device
                           Enabling shadow ram
vt8623 init starg
Detecting Memory
Numr of Banks 04
Number of Rows0d
Priamry DRAM width08
No Columns 0b
MA type e0
Bank 0 (*16 Mb) 20
No Physical Banks 01
Total Memory (*16 Mb) 20
CAS Supported 2.5 3
Cycle time at CL X     (nS)50
Cycle time at CL X-0.5 (nS)60
Cycle time at CL X-1   (nS)00
Starting at CAS
We can do CAS 2.5
tRP 3c
tRCD 3c
tRAS 28
Low Bond 00  High Bondc9  Setting DQS delay86vt8623 done
00:06 11 23 31 06 00 30 22 00 00 00 06 00 00 00 00
10:08 00 00 d0 00 00 00 00 00 00 00 00 00 00 00 00
20:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30:00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00
40:00 18 88 80 82 44 00 00 18 99 88 80 82 44 00 00
50:c8 de cf 88 e0 07 00 00 e0 00 20 20 20 20 00 00
60:02 ff 00 30 62 32 01 20 42 2d 43 58 00 44 00 00
70:82 48 00 01 01 08 50 00 01 00 00 00 00 00 00 02
80:0f 6c 00 00 80 00 00 00 02 00 00 00 00 00 00 00
90:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0:02 c0 20 00 07 02 00 1f 04 00 00 00 2f 02 04 00
b0:00 00 00 00 80 00 00 00 88 00 00 00 00 00 00 00
c0:01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
d0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0:00 dd 00 00 00 00 01 00 40 00 00 00 00 00 00 00
f0:00 00 00 00 00 00 12 13 00 00 00 00 00 00 00 00
AGP
 Doing MTRR init.
Copying LinuxBIOJumping to LinuxBIOS.
LinuxBIOS-1.1.8.0Fallback Tue Nov  8 10:20:46 UTclocks_per_usec: 2572
Enumerating buses...
Finding PCIN: 0000 enabled
APIC_CLUSTER: 0 enabled
PCI: pci_scan_bus for bus 0
PCI: 00:00.0 [1106/3123]abling static device: PCI: 00:0a.0
Disabling static device: PCI: 00:0a.1
PCI: 00:0d.0 [1106/3044] enabled
In vt8235_enable 1106 1106 3038.
PCI: 00:10.1 [1106/3038] enabled
In vt8235_enable 1106 3038.
PCI: 00:10.2 [1106/3038] enabled
In vt8235_enable 1106 5_enable 1106 3177.
Initialising Devices
PCI: 00:11.0 [1106/3177] enabled
In vt8235_enable 1106  1106 3059.
PCI: 00:11.5 [1106/3059] enabled
In vt8235_enable ffff ffff.
In vt8235_enable 1106 3065.
PCI: 00:12.0 [1106/3065] enabled
PCI: pci_scan_bus for bus 1
PCI_bus returning with max=01
vt1211 enabling PNP devices.
PNP: 002e.0 enabled
vt1211 enabling PNP devices.
PNP: 002e.1 enabled
vt1211 enabling PNP devices.
PNP: 002e.2 enabled
vt1211 enabling PNP devices.
PNP: 002e.3 enabled
PCI: pci_scan_bus returning with max=01
done
Allocating resources...
Reading resources...
Done reading resources.
Setting resourc to 0x80000 Kbytes
PCI: 00:0d.0 10 <- [0x00febfe000 - 0x00febfe7ff] mem
PCI: 00:0d.0 14 <- [0x0000001800 - 0x000000187f] io
PCI: 00:10.0 20 <- [0x0000001880 - 0x000000189f] io
PCI: 00:10.1 20 <- [0x00000018a0 - 0x00000018bf] io
PCI: 00:10.2 20 <- [0x00000018c0 - 0x00000018df] io
PCI: 00:10.3 10 <- [0x00febff000 - 0x00febff0ff] mem
PNP: 002e.0 60 <- [0x00000003f0 00006 - 0x0000000006] irq
PNP: 002e.0 74 <- [0x0000000002 - 0x0000000002] drq
PNP: 002e.1 60 <- [0x0000000378 - 0x000000037f] io
PNP: 002e.1 70 <- [0x0000000007 - 0x0000000007] irq
PNP: 002e.1 74 <- [0x0000000003 - 0x0000000003] drq
PNP: 002e.2 60 <- [0x00000003f8 - 0x0000x0000000004] irq
PNP: 002e.3 60 <- [0x00000002f8 - 0x00000002ff] io
PNP: 002e.3 70 <- [0x0000000003 - 0x0000000003] irq
PNP: 002e.b 60 <- [0x000000ec00 - 0x000000ecff] io
PCI: 00:11.1 20 <- [0x00000018e0 - 0x00000018ef] io
PCI: 00:11.5 10 <- [0x0000001000 - 0x00000010ff] io
PCI: 00:12.0 10 <- [0x0000001400 - 0x00000014ff]000ff] mem
Done setting resources.
Done allocating resources.
Enabling resourcess...
PCI: 00:00.0 cmd <- 146
PCI: 00:01.0 bridge ctrl <- 000f
PCI: 00:01.0 cmd <- 147
PCI: 01:00.0 cmd <- 140
PCI: 00:0d.0 cmd <- 1c3
PCI: 00:10.0 subsystem <- 00/00
PCI: 00:10.0 cmd <-00:10.1 cmd <- 141
PCI: 00:10.2 subsystem <- 00/00
PCI: 00:10.2 cmd <- 141
PCI: 00:10.3 subsystem <- 00/00
PCI: 00:10.3 cmd <- 142
PCI: 00:11.0 cmd <- 147
PNP: 002e.0 - enabling
PNP: 002e.1 - enabling
PNP: 002e.2 - enabling
PNP: 002e.3 - enabling
PNP: 002e.b - enabling
PCI: 00:11.system <- 00/00
PCI: 00:11.md <- 141
PCI: 00:12.0 cmd <- 1c3
done.
Initializing devices...
Root Device init
PCI: 00:10.0 init
PCI: 00:10.1 init
PCI: 00:10.2 init
PCI: 00:10.3 init
PCI: 00:11.0 init
vt8235 init
RTC Init
Invalid CMOS LB checksum
pci_routing_fixup: dev is 00010ac0
setting firewire
Assigning IRQ 9 to 0:d.0
  Readback = 9
setting usb
Assigning IRQ 5 to 0:10.0
  Readback = 5
 wrong: want 0x0, got 0x20
Assigning IRQ 9 to 0:10.1
  Readback = 9
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
Assigning IRQ 9 to 0:10.2
  Readback = 9
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
Assigning IRQ 5 to 0:10.3
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
setting vt8235
Assigning IRQ 5 to 0:11.1
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, go 0:11.5
  Readback = 9
pci_level_irq: lower order bits are wrong: want 0x0, ting ethernet
Assigning IRQ 5 to 0:12.0
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
setting vga
Assigning IRQ 5 to 1:0.0
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
setting pci slot
setting cardbus slot
setting riser slot
PNP: 002e.0 init
PNP: 002e.1 init
PNP: 002e.2 init
PNP: 002e.3 init
PNP: 002e.b init
PCI: 00:11.1 init
Enabling VIA IDE.
ide_init: enabling compatibility IDE addresses
enables in reg 0x42 0x0
enables in reg 0x42 read back as 0x0
enables in reg 0x40 0x13
enables in reg 0x40 read back as 0x13
enables in reg 0x9 0x8a
enables in reg 0x9 read back as 0x8a
command in reg 0x4 0x7
command in reg 0x4 reads back as 0x7
PCI: 00:11.5 inionfiguring VIA Rhine LAN
APIC_CLUSTER: 0 init
IniCPU: vendor Centaur devi
Enabling cache

Setting fixed MTRRs(0-88) type: UC
Setting fixed MTRRs(0-16) Type: WB
Setting fixed MTRRs(24-88) Type: WB
DONE fixed MTRRs
Setting variable MTRR 0, base:    0MB, range:  256MB, type WB
Setting variable MTRR 1, base:  256MB, range:  128MB, type WB
Setting variable MTRR 2, base:  384MB, range:   64MB, type WB
Setting variable MTRR 3, base:  448MB, range:   32MB, type WB
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

Disabling local apic...done.
CPU #0 Initialized
PCI: 00:00.0 init
VT8623 random fixup ...
Frame buffer at d0000000dom fixup ...
PCI: 00:0d.0 init
PCI: 01:00.0 init
VGA random fixup ...
INSTALL REAL-MODE IDT
DO THE VGA BIOS
found VGA: vid=1106, did=3122
rom bawrite_protect_vgabios
bus/devfn = 0x100
biosint: # 0x6, eax 0x5f00 ebx 0x187c8 ecx 0x17fa0 edx 0xa
biosint: ebp 0x17f70 esp 0xfec edi 0xe850 esi 0x187c8
biosint: ip 0xf859 cs 0xf000 flags 0x46
biosint: Oops, exception 60x6a1f 0xc000 0x0046 0x7fa0 0x89b5 0xb6e1 0x0000
biosint: Bailing out
sp 0xffa edi 0x0 esi 0x187c8ebx 0x18003 ecx 0x1 edx 0x0
biosint: ip 0xb565 cs 0x0 flags 0x46
BIOSINT: Unsupport int #0x10
Devices initialized
Copying IRQ routing tables to 0xf0000...done.
Verifing copy of IRQ routing tables at 0xf0000...done
Checking IRQ routing table consistency...
check_pirq_routing_table() - irq_routing_table located at: 0x000f0000
done.
ACPI: Writing ACPI tables at f0400...
ACPI:     * FACS
ACPI:     * DSDT @ 000f04aa Length 3f0
ACPI:     * FADT
ACPI: added table 1/8 Length now 40
ACPI: done.
Moving GDT to 0x500...ok
Wrote linuxbios table at: 00000530 - 00000b60  checksum 1e60

Welcome to elfboot, the open sourced starter.
January 2002, Eric Biederman.
Version 1.3

    33:stream_init() - rom_stream: 0xfffd0000 - 0xfffeffff
Found ELF candiate at offset 0
New segment addr 0x100000 size 0x25390 offset 0xa0 filesize 0xb2e0
(cleaned up) New segment addr 0x100000 size 0x25390 offset 0xa0 filesize 0xb2e0
New segment addr 0x1253a0 size 0x60egment addr 0x1253a0 size 0x60 offset 0xb380 filesize 0x60
Dropping non PT_LOAD segment
Loading Segment: addr: 0x0000000000100000 memsz: 0x0000000000025390 filesz: 0x000000000000b2e0
Clearing Segment00000010b2e0 memsz: 0x000000000001a0b0
Loading Segment: addr: 0x00000000001253a0 memsz: 0x0000000000000060 filesz: 0x0000000000000060
Jumping to boot code at 0x108b4c
FILO version 0.4.2 (okajima at Debian) Sun Nov  6 04:49:41 UTC 2005
Press <Enter> for default boot, or <Esc> for boot prompt... timed out
boot: hda1:/vmlinuz root=/dev/hIDE time out
No drive detected on IDE channel 0
boot: hda1:/vmlinuz root=/dev/hda1 console=tty0 console=ttyS0,115200



From stepan at openbios.org  Tue Nov  8 12:24:43 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue, 8 Nov 2005 12:24:43 +0100
Subject: [LinuxBIOS] EPIA-M VGA
In-Reply-To: <200511080303.AA00454@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
References: <200511072259.AA00453@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
	<200511080303.AA00454@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
Message-ID: <20051108112443.GC14693@openbios.org>

* Jun OKAJIMA <okajima at digitalinfra.co.jp> [051108 04:03]:
> biosint: # 0x6, eax 0x5f00 ebx 0x187c8 ecx 0x17fa0 edx 0xa
> biosint: ebp 0x17f70 esp 0xfec edi 0xe850 esi 0x187c8
> biosint: ip 0xf859 cs 0xf000 flags 0x46

http://www.ctyme.com/intr/int-06.htm 

It's probably the "graphics character table" version.

> biosint: Oops, exception 60x6a1f 0xc000 0x0046 0x7fa0 0x89b5 0xb6e1 0x0000
> biosint: Bailing out

This definitely is an error..

   Stefan



From gjohnson at lanl.gov  Tue Nov  8 20:54:29 2005
From: gjohnson at lanl.gov (Greg Johnson)
Date: Tue, 8 Nov 2005 12:54:29 -0700
Subject: [LinuxBIOS] dual core disable?
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4201E06210@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4201E06210@ssvlexmb2.amd.com>
Message-ID: <20051108195429.GE2363@durango.c3.lanl.gov>

YH,

I'm not sure I'm quite following.  I tried making the changes you
suggested, but it still looks the same.  Linux still identifies it as a
single socket with two cores.  I've rechecked the performance and it
still looks like a single socket with two cores (measuring memory
latencies and bandwidth).  Any other ideas?

Thanks,

Greg

On Mon, Nov 07, 2005 at 04:33:08PM -0800, Lu, Yinghai wrote:
> Northbridge.c cpu_bus_scan need to be modified too, you need to assume
> the CONFIG_LOGICAL_CPU==1 there..
> 
> YH
> 
> -----Original Message-----
> From: linuxbios-bounces at openbios.org
> [mailto:linuxbios-bounces at openbios.org] On Behalf Of Lu, Yinghai
> Sent: Monday, November 07, 2005 3:55 PM
> To: Greg Johnson
> Cc: linuxbios at openbios.org
> Subject: Re: [LinuxBIOS] dual core disable?
> 
> OK, 
> 
> We may need to set the nbcfg 54 bit even disable the dual core.
> 
> Please several lines
> 1. src/cpu/dualcore/dualcore.c 
> //If(read_option(CMOS_VSTART_dual_core.....
> 2. in you cache_as_ram_auto.c
> //#if CONFIG_LOGICAL_CPUS == 1
> 	Set_apicid_cpuid_lo();
> //#endif
> 
> YH



From beneo at comcast.net  Wed Nov  9 02:01:37 2005
From: beneo at comcast.net (beneo)
Date: Tue, 8 Nov 2005 17:01:37 -0800
Subject: [LinuxBIOS] Build broken?
Message-ID: <003401c5e4c9$246c8ba0$131814ac@trans.corp>

Hi, 
I download a lateset snapshot from linuxBIOS.org yesterday. I don't know if it is bad luck or something, I can not successfully build any BIOS from the tree I downloaded. I tried following three platform.

tyan/s2891
tyan/s2895
amd/serenade

Does anybody has similar issue or know what happened?

Below are the details on the things I got for these three different target platform

1. Both tyan/s2891 and tyan/s2895 have similar behavior 

I changed a few lines in Options.lb:

default USE_DCACHE_RAM=1
default CONFIG_USE_INIT=1
default DEFAULT_CONSOLE_LOGLEVEL=7
default  MAXIMUM_CONSOLE_LOGLEVEL=7

I get a error output like below: (Note: Changing options in the Options.lb above were not the cuase of the problem. Without changing USE_DCACHE_RAM and CONFIG_USE_INIT, I still get same results)

------------
gcc -m32 -nostdlib -nostartfiles -static -o linuxbios_ram -T /export/1/new/src/config/linuxbios_ram.ld linuxbios_ram.o
linuxbios_ram.o(.text+0x13db9): In function `smp_write_config_table':
: undefined reference to `get_apicid_base'
collect2: ld returned 1 exit status
make[1]: *** [linuxbios_ram] Error 1
make[1]: Leaving directory `/export/1/new/targets/tyan/s2895/s2895/normal'
make: *** [normal/linuxbios.rom] Error 1

2. amd/serenade gets the build error like below. It probably is the side product of the tree enabled dual core and cache as RAM?
-----
gcc -m32 -nostdlib -nostartfiles -static -o linuxbios_ram -T /export/1/new/src/config/linuxbios_ram.ld linuxbios_ram.o
linuxbios_ram.o(.text+0x14d2): In function `model_fxx_init':
: undefined reference to `get_node_core_id'
linuxbios_ram.o(.text+0x14e6): In function `model_fxx_init':
: undefined reference to `amd_sibling_init'
collect2: ld returned 1 exit status
make[1]: *** [linuxbios_ram] Error 1
make[1]: Leaving directory `/export/1/new/targets/amd/serenade/serenade/normal'
make: *** [normal/linuxbios.rom] Error 1


Any help would be appriciated.

Thanks 

Beneo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20051108/6c2b3dc0/attachment.html>

From a.borisov at tesv.tmb.ru  Wed Nov  9 06:14:13 2005
From: a.borisov at tesv.tmb.ru (Anton Borisov)
Date: Wed, 9 Nov 2005 08:14:13 +0300
Subject: [LinuxBIOS] ADLO with EPIA-M LX2
Message-ID: <20051109081413.4bc0afc0.a.borisov@tesv.tmb.ru>

Hi.
	I have compiled ADLO from LX1 (freebios--devel--1.0--base-0.tar.bz2). Pure BOCHS BIOS ~58k. Payload with VGABIOS - 124k.
My Config.lb is below:

=
target epia-m

mainboard via/epia-m

option  MAXIMUM_CONSOLE_LOGLEVEL=8
option  DEFAULT_CONSOLE_LOGLEVEL=8
option  CONFIG_CONSOLE_SERIAL8250=1

option ROM_SIZE=256*1024
option HAVE_OPTION_TABLE=1
option CONFIG_ROM_STREAM=1
option HAVE_FALLBACK_BOOT=1

option FALLBACK_SIZE=0x30000
option _RAMBASE=0x00004000

romimage "fallback"
        option USE_FALLBACK_IMAGE=1
        option ROM_IMAGE_SIZE=0x10000
        option ROM_SECTION_OFFSET=0x10000
        option ROM_SECTION_SIZE=0x30000
        option LINUXBIOS_EXTRA_VERSION=".0Fallback"
        payload /home/anthony/src/payloads/adlo.elf
end

buildrom ./linuxbios.rom ROM_SIZE  "fallback"
=

	Some comments regarding FALLBACK_SIZE. This is done intentionally to include VIA's VGABIOS into fallback portion. 
	linuxbios.rom being composed this way is written into flash chip. 
	Unfortunately I wasn't able to load ADLO payload (see messages below).

=
Moving GDT to 0x500...ok                                                                            
Wrote linuxbios table at: 00000530 - 00000b28  checksum 97d3                                        
                                                                                                    
Welcome to elfboot, the open sourced starter.                                                       
January 2002, Eric Biederman.                                                                       
Version 1.3                                                                                         
                                                                                                    
    33:stream_init() - rom_stream: 0xfffd0000 - 0xfffeffff                                          
Found ELF candiate at offset 0                                                                      
Cannot Load ELF Image        
=
	I assume this is a problem with improper configuring ROM_IMAGE_SIZE, ROM_SECTION_OFFSET in my example. I did increase it to 0x20000 value. And I've got this error while compiling with ROMCC:

=
./romcc    -mcpu=c3 -O -I/home/lx/src/LinuxBIOSv2-2080/src -I. -I/home/lx/src/LinuxBIOSv2-earlymtrr.c:21.45:                                                                     Integer constant to large 
=

	Where I've done wrong? Does anybody experienced with ADLO applying to LX2 recently?

Thanks.

-- 
Sincerely, Anton Borisov



From cro_marmot at comcast.net  Wed Nov  9 06:26:34 2005
From: cro_marmot at comcast.net (David Hendricks)
Date: Tue, 8 Nov 2005 22:26:34 -0700
Subject: [LinuxBIOS] Build broken?
In-Reply-To: <003401c5e4c9$246c8ba0$131814ac@trans.corp>
References: <003401c5e4c9$246c8ba0$131814ac@trans.corp>
Message-ID: <20051108222634.068fa951@sunder>

Probably bad luck. This has been known to happen, and IIRC one of the
points at the recent LinuxBIOS summit was to post 'stable' tarballs
where everything should build without hassle, even if it means rolling
back some features. Stay tuned...

On Tue, 8 Nov 2005 17:01:37 -0800
"beneo" <beneo at comcast.net> wrote:

> Hi, 
> I download a lateset snapshot from linuxBIOS.org yesterday. I don't
> know if it is bad luck or something, I can not successfully build any
> BIOS from the tree I downloaded. I tried following three platform.
> 
> tyan/s2891
> tyan/s2895
> amd/serenade
> 
> Does anybody has similar issue or know what happened?
> 
> Below are the details on the things I got for these three different
> target platform
> 
> 1. Both tyan/s2891 and tyan/s2895 have similar behavior 
> 
> I changed a few lines in Options.lb:
> 
> default USE_DCACHE_RAM=1
> default CONFIG_USE_INIT=1
> default DEFAULT_CONSOLE_LOGLEVEL=7
> default  MAXIMUM_CONSOLE_LOGLEVEL=7
> 
> I get a error output like below: (Note: Changing options in the
> Options.lb above were not the cuase of the problem. Without changing
> USE_DCACHE_RAM and CONFIG_USE_INIT, I still get same results)
> 
> ------------
> gcc -m32 -nostdlib -nostartfiles -static -o linuxbios_ram
> -T /export/1/new/src/config/linuxbios_ram.ld linuxbios_ram.o
> linuxbios_ram.o(.text+0x13db9): In function
> `smp_write_config_table': : undefined reference to `get_apicid_base'
> collect2: ld returned 1 exit status make[1]: *** [linuxbios_ram]
> Error 1 make[1]: Leaving directory
> `/export/1/new/targets/tyan/s2895/s2895/normal' make: ***
> [normal/linuxbios.rom] Error 1
> 
> 2. amd/serenade gets the build error like below. It probably is the
> side product of the tree enabled dual core and cache as RAM? -----
> gcc -m32 -nostdlib -nostartfiles -static -o linuxbios_ram
> -T /export/1/new/src/config/linuxbios_ram.ld linuxbios_ram.o
> linuxbios_ram.o(.text+0x14d2): In function `model_fxx_init': :
> undefined reference to `get_node_core_id'
> linuxbios_ram.o(.text+0x14e6): In function `model_fxx_init': :
> undefined reference to `amd_sibling_init' collect2: ld returned 1
> exit status make[1]: *** [linuxbios_ram] Error 1
> make[1]: Leaving directory
> `/export/1/new/targets/amd/serenade/serenade/normal' make: ***
> [normal/linuxbios.rom] Error 1
> 
> 
> Any help would be appriciated.
> 
> Thanks 
> 
> Beneo


-- 



From smithbone at gmail.com  Wed Nov  9 06:40:14 2005
From: smithbone at gmail.com (Richard Smith)
Date: Tue, 8 Nov 2005 23:40:14 -0600
Subject: [LinuxBIOS] ADLO with EPIA-M LX2
In-Reply-To: <20051109081413.4bc0afc0.a.borisov@tesv.tmb.ru>
References: <20051109081413.4bc0afc0.a.borisov@tesv.tmb.ru>
Message-ID: <8a0c36780511082140h1777ec2cr3e20a77ea9fbfbb1@mail.gmail.com>

>     33:stream_init() - rom_stream: 0xfffd0000 - 0xfffeffff
> Found ELF candiate at offset 0
> Cannot Load ELF Image
> =
> =
>
>         Where I've done wrong? Does anybody experienced with ADLO applying to LX2 recently?

See if you can load any payload at all or if its just the ADLO payload
thats causing you trouble.  Try memtest without the video bios so you
don't have to change any settings.

--
Richard A. Smith



From smithbone at gmail.com  Wed Nov  9 07:19:07 2005
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 9 Nov 2005 00:19:07 -0600
Subject: [LinuxBIOS] ADLO with EPIA-M LX2
In-Reply-To: <20051109090713.7472a241.a.borisov@tesv.tmb.ru>
References: <20051109081413.4bc0afc0.a.borisov@tesv.tmb.ru>
	<8a0c36780511082140h1777ec2cr3e20a77ea9fbfbb1@mail.gmail.com>
	<20051109085232.06d048bb.a.borisov@tesv.tmb.ru>
	<8a0c36780511082156i75130afbj587bf03ac054e501@mail.gmail.com>
	<20051109090713.7472a241.a.borisov@tesv.tmb.ru>
Message-ID: <8a0c36780511082219s76216c95r6f7f5fe3b2628ecd@mail.gmail.com>

I'm sticking this back on the list so others can suggest things as well.

On 11/9/05, Anton Borisov <a.borisov at tesv.tmb.ru> wrote:
> On Tue, 8 Nov 2005 23:56:53 -0600
> Richard Smith <smithbone at gmail.com> wrote:
>
> > > > See if you can load any payload at all or if its just the ADLO payload
> > > > thats causing you trouble.  Try memtest without the video bios so you
> > > > don't have to change any settings.
> > >
> > >         You're quite right - ADLO payload causing this problem. FILO just works perfectly. I'm ready to blame the size of my ADLO payload ;-) - more then 120 kb. But I wasn't able to start ADLO without VIDEO as well.
> > >
> >
> > So ADLO with no video bios won't load either?  Do you still get an elf
> > load error?
>
>         I probed 2 versions of ADLO: with integrated VIDEO ROM and without it. Sizes accordingly are 58Kb and 124Kb. Tracing with minicom revealed the same effect -
> ==
>  Found ELF candiate at offset 0
>  Cannot Load ELF Image
> ==
>         Maybe I've run into improper understanding of XIP_ROM_SIZE and ROM_SIZE params inside Config.lb, but I doubt this ;-)

I don't think your problem is related to size.  The elf image is found
but failed to load properly.  I believe the size is embedded in the
elf segment.  If your sizes were all wrong I would expect that it
either wouldn't boot or it would not find the payload.

Are you using XIP?  If so you might try turning it off.

You will probally have to go look in the elf load code and see what
causes that message I've not looked at the elf load code so I don't
have many suggestions.

Is you adlo.elf really a valid elf image?  What do you get for a
'readelf -a adlo.elf'

--
Richard A. Smith



From tristan at open3net.com  Wed Nov  9 08:46:01 2005
From: tristan at open3net.com (tristan)
Date: Wed, 09 Nov 2005 08:46:01 +0100
Subject: [LinuxBIOS] VIA EPIA M10000 (Nehemiah) CentaurHauls Stepping 5
	support status
Message-ID: <1131522362.3446.17.camel@localhost.localdomain>

Hi list,
I'd like to know the exact support status of LinuxBIOS on VIA EPIA
M10000 (Nehemiah) CentaurHauls Stepping 5. I've seen messages (August
2005) that say VGA is supported, and more recent threads that say it
isn't. So, what is supported by the mainstream LinuxBios v2 ? And what
is not yet?
Are these any patches around that could achieve better support?
All different messages I see are rather confusing ...

Another question: VIA has published a "FastBoot" BIOS that seems to be a
fork of LinuxBIOS, since it's a fork and LinuxBIOS is covered by GPL, is
FastBoot a GPL violation? Someone has ever had the sources of FastBoot?
If ever, could it lead to a better support of EPIA motherboards?

Thanks for you answers,

Tristan





From a.borisov at tesv.tmb.ru  Wed Nov  9 09:06:04 2005
From: a.borisov at tesv.tmb.ru (Anton Borisov)
Date: Wed, 9 Nov 2005 11:06:04 +0300
Subject: [LinuxBIOS] VIA EPIA M10000 (Nehemiah) CentaurHauls Stepping 5
 support status
In-Reply-To: <1131522362.3446.17.camel@localhost.localdomain>
References: <1131522362.3446.17.camel@localhost.localdomain>
Message-ID: <20051109110604.70e1289b.a.borisov@tesv.tmb.ru>

On Wed, 09 Nov 2005 08:46:01 +0100
tristan <tristan at open3net.com> wrote:

> I'd like to know the exact support status of LinuxBIOS on VIA EPIA
> M10000 (Nehemiah) CentaurHauls Stepping 5. I've seen messages (August
> 2005) that say VGA is supported, and more recent threads that say it
> isn't. So, what is supported by the mainstream LinuxBios v2 ? And what
> is not yet?
> Are these any patches around that could achieve better support?
> All different messages I see are rather confusing ...

	Textmode at exactly your version of EPIA is supported. ACPI subsystem is ok. Videomode is limited to 320x240x8 or 640x480x4 (from my experience with EPIA-M 10K).

-- 
Sincerely, Anton Borisov



From jrg at toasterfish.com  Wed Nov  9 09:15:23 2005
From: jrg at toasterfish.com (John Galloway)
Date: Wed, 9 Nov 2005 00:15:23 -0800
Subject: [LinuxBIOS] VIA EPIA M10000 (Nehemiah) CentaurHauls Stepping 5
	support status
In-Reply-To: <1131522362.3446.17.camel@localhost.localdomain>
References: <1131522362.3446.17.camel@localhost.localdomain>
Message-ID: <42FC91CF-1BFB-4F63-83AE-92D35227AA8E@toasterfish.com>


On Nov 8, 2005, at 11:46 PM, tristan wrote:
>
> Another question: VIA has published a "FastBoot" BIOS that seems to  
> be a
> fork of LinuxBIOS, since it's a fork and LinuxBIOS is covered by  
> GPL, is
> FastBoot a GPL violation? Someone has ever had the sources of  
> FastBoot?
There was some discussion of this on the VIA-Arena forum but I don't
know that any certain evidence was produced.  It seems very unlikely  
that VIA
wrote FastBoot from scratch so the general consensus was that they
are likely violating the GPL from LinuxBios.  But getting any sort of  
interaction
from VIA on such is also likely going to be difficult as they pretty  
much do
not offer support for anyone other than large customers.  I seem to  
recall
that FastBoot is also setup to boot Windows only, though I'm not sure  
what
this means, if true, from a technical point of view (support only  
booting from a FAT
file system or some such?).
   -jrg



From rminnich at lanl.gov  Wed Nov  9 16:58:07 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 09 Nov 2005 08:58:07 -0700
Subject: [LinuxBIOS] VIA EPIA M10000 (Nehemiah) CentaurHauls Stepping
 5	support status
In-Reply-To: <1131522362.3446.17.camel@localhost.localdomain>
References: <1131522362.3446.17.camel@localhost.localdomain>
Message-ID: <43721C8F.5010604@lanl.gov>

tristan wrote:
> Hi list,
> I'd like to know the exact support status of LinuxBIOS on VIA EPIA
> M10000 (Nehemiah) CentaurHauls Stepping 5. I've seen messages (August
> 2005) that say VGA is supported, and more recent threads that say it
> isn't. So, what is supported by the mainstream LinuxBios v2 ? And what
> is not yet?
> Are these any patches around that could achieve better support?
> All different messages I see are rather confusing ...

all the patches are in the issue trackers, and after SC 2005 I intend to 
try to get this stuff into the tree. It seems like 3 different groups 
have got 3 different patches.



> 
> Another question: VIA has published a "FastBoot" BIOS that seems to be a
> fork of LinuxBIOS, since it's a fork and LinuxBIOS is covered by GPL, is
> FastBoot a GPL violation? Someone has ever had the sources of FastBoot?
> If ever, could it lead to a better support of EPIA motherboards?

is fastboot a GPL violation ?If it is based on linuxbios, then yet it 
is. Does anyone have time to track this down?  No. The FSF has been 
informed, as of a few years ago.

ron



From yinghai.lu at amd.com  Wed Nov  9 18:37:50 2005
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Wed, 9 Nov 2005 09:37:50 -0800
Subject: [LinuxBIOS] [Etherboot-developers] Infiniband driver
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E06227@ssvlexmb2.amd.com>

Who want it? LinuxBIOS, current System BIOS or EFI?

 

For LinuxBIOS, We will use LinuxBIOS+tiny kernel for booting. The Tiny
kernel could include IB and IP over IB, So we don't need to port driver
from kernel to everywhere....

 

YH

 

________________________________

From: etherboot-developers-admin at lists.sourceforge.net
[mailto:etherboot-developers-admin at lists.sourceforge.net] On Behalf Of
Eli Cohen
Sent: Wednesday, November 09, 2005 3:53 AM
To: etherboot-developers at lists.sourceforge.net
Subject: [Etherboot-developers] Infiniband driver

 

Hi, 
We have developed a driver for Mellanox's HCA device MT23108. In our
plans is a to add support for a second line of devices. This will allow
a host having an HCA to use it for doing remote boot. It is based on
Etherboot and we would like to open the source to the public and we
would like it to be part of Etherboot. I would like to know how to move
in this direction.

Thanks 
Eli 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
When the going gets tough the tough get going 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20051109/936520c7/attachment.html>

From beneo at comcast.net  Wed Nov  9 19:16:19 2005
From: beneo at comcast.net (Beneo)
Date: Wed, 9 Nov 2005 10:16:19 -0800
Subject: [LinuxBIOS] Build broken?
References: <003401c5e4c9$246c8ba0$131814ac@trans.corp>
	<20051108222634.068fa951@sunder>
Message-ID: <032201c5e559$b383da60$812614ac@trans.corp>

David,

Do you know a tar ball with recent date that is relatively good that I can
download?

Thanks

Beneo


----- Original Message ----- 
From: "David Hendricks" <cro_marmot at comcast.net>
To: <linuxbios at openbios.org>
Sent: Tuesday, November 08, 2005 9:26 PM
Subject: Re: [LinuxBIOS] Build broken?


> Probably bad luck. This has been known to happen, and IIRC one of the
> points at the recent LinuxBIOS summit was to post 'stable' tarballs
> where everything should build without hassle, even if it means rolling
> back some features. Stay tuned...
>
> On Tue, 8 Nov 2005 17:01:37 -0800
> "beneo" <beneo at comcast.net> wrote:
>
> > Hi,
> > I download a lateset snapshot from linuxBIOS.org yesterday. I don't
> > know if it is bad luck or something, I can not successfully build any
> > BIOS from the tree I downloaded. I tried following three platform.
> >
> > tyan/s2891
> > tyan/s2895
> > amd/serenade
> >
> > Does anybody has similar issue or know what happened?
> >
> > Below are the details on the things I got for these three different
> > target platform
> >
> > 1. Both tyan/s2891 and tyan/s2895 have similar behavior
> >
> > I changed a few lines in Options.lb:
> >
> > default USE_DCACHE_RAM=1
> > default CONFIG_USE_INIT=1
> > default DEFAULT_CONSOLE_LOGLEVEL=7
> > default  MAXIMUM_CONSOLE_LOGLEVEL=7
> >
> > I get a error output like below: (Note: Changing options in the
> > Options.lb above were not the cuase of the problem. Without changing
> > USE_DCACHE_RAM and CONFIG_USE_INIT, I still get same results)
> >
> > ------------
> > gcc -m32 -nostdlib -nostartfiles -static -o linuxbios_ram
> > -T /export/1/new/src/config/linuxbios_ram.ld linuxbios_ram.o
> > linuxbios_ram.o(.text+0x13db9): In function
> > `smp_write_config_table': : undefined reference to `get_apicid_base'
> > collect2: ld returned 1 exit status make[1]: *** [linuxbios_ram]
> > Error 1 make[1]: Leaving directory
> > `/export/1/new/targets/tyan/s2895/s2895/normal' make: ***
> > [normal/linuxbios.rom] Error 1
> >
> > 2. amd/serenade gets the build error like below. It probably is the
> > side product of the tree enabled dual core and cache as RAM? -----
> > gcc -m32 -nostdlib -nostartfiles -static -o linuxbios_ram
> > -T /export/1/new/src/config/linuxbios_ram.ld linuxbios_ram.o
> > linuxbios_ram.o(.text+0x14d2): In function `model_fxx_init': :
> > undefined reference to `get_node_core_id'
> > linuxbios_ram.o(.text+0x14e6): In function `model_fxx_init': :
> > undefined reference to `amd_sibling_init' collect2: ld returned 1
> > exit status make[1]: *** [linuxbios_ram] Error 1
> > make[1]: Leaving directory
> > `/export/1/new/targets/amd/serenade/serenade/normal' make: ***
> > [normal/linuxbios.rom] Error 1
> >
> >
> > Any help would be appriciated.
> >
> > Thanks
> >
> > Beneo
>
>
> -- 
>
> -- 
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios




From stepan at openbios.org  Wed Nov  9 19:24:22 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Wed, 9 Nov 2005 19:24:22 +0100
Subject: [LinuxBIOS] Build broken?
In-Reply-To: <032201c5e559$b383da60$812614ac@trans.corp>
References: <003401c5e4c9$246c8ba0$131814ac@trans.corp>
	<20051108222634.068fa951@sunder>
	<032201c5e559$b383da60$812614ac@trans.corp>
Message-ID: <20051109182422.GA21173@openbios.org>

* Beneo <beneo at comcast.net> [051109 19:16]:
> David,
> 
> Do you know a tar ball with recent date that is relatively good that I can
> download?


http://snapshots.linuxbios.org/

rev 2064 should be relatively good.

Stefan 




From matt at glw.com  Wed Nov  9 20:03:54 2005
From: matt at glw.com (Matthew Simmons)
Date: Wed, 9 Nov 2005 13:03:54 -0600
Subject: [LinuxBIOS] Tiny Kernel
Message-ID: <20051109190156.63F3135570@mail.glw.com>

Where do I find information on booting "tiny kernel"? Or could you guys
explain it to me?
 
Thanks,
Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20051109/9ae9fc09/attachment.html>

From smithbone at gmail.com  Wed Nov  9 20:29:29 2005
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 9 Nov 2005 13:29:29 -0600
Subject: [LinuxBIOS] Tiny Kernel
In-Reply-To: <20051109190156.63F3135570@mail.glw.com>
References: <20051109190156.63F3135570@mail.glw.com>
Message-ID: <8a0c36780511091129u1151ae1bhbc9c165a5c7f33ab@mail.gmail.com>

On 11/9/05, Matthew Simmons <matt at glw.com> wrote:
>
> Where do I find information on booting "tiny kernel"? Or could you guys
> explain it to me?

http://www.selenic.com/linux-tiny/


--
Richard A. Smith



From beneo at comcast.net  Wed Nov  9 20:57:16 2005
From: beneo at comcast.net (beneo)
Date: Wed, 9 Nov 2005 11:57:16 -0800
Subject: [LinuxBIOS] Build broken?
References: <003401c5e4c9$246c8ba0$131814ac@trans.corp>
	<20051108222634.068fa951@sunder>
	<032201c5e559$b383da60$812614ac@trans.corp>
	<20051109182422.GA21173@openbios.org>
Message-ID: <004501c5e567$c91ed380$131814ac@trans.corp>

I tried rev 2064, on two targets: tyan/s2891 and amd/serenade, both gave me
an error like this:

---
gcc -m32 -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld crt0.o
/usr/bin/ld: section .reset [fffdfff0 -> fffdffff] overlaps section .rom
[fffd7da8 -> fffe08df]
/usr/bin/ld: section .id [fffdffd7 -> fffdffef] overlaps section .rom
[fffd7da8 -> fffe08df]
collect2: ld returned 1 exit status
make[1]: *** [linuxbios] Error 1
---

Do I need to do some ajustment? or do I need to try other revision?

Thanks

Beneo

----- Original Message ----- 
From: "Stefan Reinauer" <stepan at openbios.org>
To: "Beneo" <beneo at comcast.net>
Cc: "David Hendricks" <cro_marmot at comcast.net>; <linuxbios at openbios.org>
Sent: Wednesday, November 09, 2005 10:24 AM
Subject: Re: [LinuxBIOS] Build broken?


> * Beneo <beneo at comcast.net> [051109 19:16]:
> > David,
> >
> > Do you know a tar ball with recent date that is relatively good that I
can
> > download?
>
>
> http://snapshots.linuxbios.org/
>
> rev 2064 should be relatively good.
>
> Stefan
>




From rminnich at lanl.gov  Wed Nov  9 21:00:37 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 09 Nov 2005 13:00:37 -0700
Subject: [LinuxBIOS] Build broken?
In-Reply-To: <004501c5e567$c91ed380$131814ac@trans.corp>
References: <003401c5e4c9$246c8ba0$131814ac@trans.corp>	<20051108222634.068fa951@sunder>	<032201c5e559$b383da60$812614ac@trans.corp>	<20051109182422.GA21173@openbios.org>
	<004501c5e567$c91ed380$131814ac@trans.corp>
Message-ID: <43725565.2000600@lanl.gov>

beneo wrote:
> I tried rev 2064, on two targets: tyan/s2891 and amd/serenade, both gave me
> an error like this:
> 
> ---
> gcc -m32 -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld crt0.o
> /usr/bin/ld: section .reset [fffdfff0 -> fffdffff] overlaps section .rom
> [fffd7da8 -> fffe08df]
> /usr/bin/ld: section .id [fffdffd7 -> fffdffef] overlaps section .rom
> [fffd7da8 -> fffe08df]
> collect2: ld returned 1 exit status
> make[1]: *** [linuxbios] Error 1
> ---


This is the 'your flash part is too small or your payload is too big' 
error. I apologize for the lousy error diagnostic, this is on our 
Post-sc2005 list of things to fix.

ron



From beneo at comcast.net  Thu Nov 10 04:02:23 2005
From: beneo at comcast.net (beneo)
Date: Wed, 9 Nov 2005 19:02:23 -0800
Subject: [LinuxBIOS] Build broken?
References: <003401c5e4c9$246c8ba0$131814ac@trans.corp>	<20051108222634.068fa951@sunder>	<032201c5e559$b383da60$812614ac@trans.corp>	<20051109182422.GA21173@openbios.org><004501c5e567$c91ed380$131814ac@trans.corp>
	<43725565.2000600@lanl.gov>
Message-ID: <005001c5e5a3$2d4f9f70$131814ac@trans.corp>

Thanks for the pointer. I tried it, but still has some issues, hope a guru
can point me a little more.

I changed the ROM_IMAGE_SIZE to 128k from 64K for both normal and fall back,
the PAYLOAD_SIZE changed to 128K too.

But I still get a error message like this:
-----
objcopy --gap-fill 0xff -O binary linuxbios linuxbios.strip
gcc -o buildrom
/root/dl/lb/v2-2064/LinuxBIOSv2-2064/util/buildrom/buildrom.c
./buildrom linuxbios.strip linuxbios.rom /export/1/payloads/filo.zelf
0x20000 0x40000
linuxbios image is 131080 bytes; only 131072 allowed
Linuxbios input file larger than allowed size!
-----

This only happens to my fallback image. I traced the code, indeed, My
linuxbios.strip file has a size = 131080, which is too large. But the size
of my linuxbios file was only 124570. the objcopy seems created a too large
linuxbios.strip for me.

More interesting thing is that I have a older tree, (8 month older tree) In
that tree, my linuxbios file size was 122982, the objcopy successfully
created a linuxbios.strip file with a size 65536. It must used some
compression. Since I don't know much about objcopy, I can not tell what it
used. The only difference I can tell is that objcopy was look like this:
objcopy -O binary linuxbios linuxbios.strip. (Note: without "--gap-fill 0xff
" option, but don't know if it would make any difference)

Does anybody know what I did wrong or missed?

By the way, my linuxbios_ram.rom size is 31614, crt0.o size is 87388.
Payload size is 42784.

Thanks

beneo

----- Original Message ----- 
From: "Ronald G Minnich" <rminnich at lanl.gov>
To: "beneo" <beneo at comcast.net>
Cc: <linuxbios at openbios.org>
Sent: Wednesday, November 09, 2005 12:00 PM
Subject: Re: [LinuxBIOS] Build broken?


> beneo wrote:
> > I tried rev 2064, on two targets: tyan/s2891 and amd/serenade, both gave
me
> > an error like this:
> >
> > ---
> > gcc -m32 -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld
crt0.o
> > /usr/bin/ld: section .reset [fffdfff0 -> fffdffff] overlaps section .rom
> > [fffd7da8 -> fffe08df]
> > /usr/bin/ld: section .id [fffdffd7 -> fffdffef] overlaps section .rom
> > [fffd7da8 -> fffe08df]
> > collect2: ld returned 1 exit status
> > make[1]: *** [linuxbios] Error 1
> > ---
>
>
> This is the 'your flash part is too small or your payload is too big'
> error. I apologize for the lousy error diagnostic, this is on our
> Post-sc2005 list of things to fix.
>
> ron
>
> -- 
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios




From yinghai.lu at AMD.COM  Thu Nov 10 04:39:17 2005
From: yinghai.lu at AMD.COM (Lu, Yinghai)
Date: Wed, 9 Nov 2005 19:39:17 -0800
Subject: [LinuxBIOS] Build broken?
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E0622C@ssvlexmb2.amd.com>

Please change ROM_IMAGE_SIZE in romimage "fallback" section to 0x16380

YH





From beneo at comcast.net  Thu Nov 10 20:53:57 2005
From: beneo at comcast.net (beneo)
Date: Thu, 10 Nov 2005 11:53:57 -0800
Subject: [LinuxBIOS] Build broken?
References: <6F7DA19D05F3CF40B890C7CA2DB13A4201E0622C@ssvlexmb2.amd.com>
Message-ID: <006301c5e630$7d1cdf30$131814ac@trans.corp>

Thanks. It works on one of issues I have encountered.

My immidiate question is why my ROM_IMAGE_SIZE with larger value 0x20000
won't work, but with 0x16380 would work? If you don't tell me this, I
probably would never be able to figure out.

My have another issue, It looks like a bug in target tyan/s2891. I'm trying
to build tyan/s2891. No matter what I change, I always get a build error
like:
---
gcc -m32 -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld crt0.o
init.o
/usr/bin/ld: section .rodata.str1.32 [fffbff80 -> fffc0091] overlaps section
.reset [fffbfff0 -> fffbffff]
collect2: ld returned 1 exit status
make[1]: *** [linuxbios] Error 1
---

Then I looked at ldscript file, it included southbridge/nvidia/ck804/id.lds
file, which looks like this:
---
SECTIONS {
        . = (_ROMBASE + ROM_IMAGE_SIZE - 0x80) - (__id_end - __id_start);
        .id (.): {
                *(.id)
        }
}
---

There is no linker script would arrange section .rodata.str1.32. I guess
that just makes linker to patch section .rodata.str1.32 at end of .id
section, which caused the overlap with .reset section.

This looks to me is a bug in tyan/s2891. How do I fix this? is that OK to
remove nvidia/ck804/id.lds?

thanks

beneo





----- Original Message ----- 
From: "Lu, Yinghai" <yinghai.lu at AMD.COM>
To: "beneo" <beneo at comcast.net>; "Ronald G Minnich" <rminnich at lanl.gov>
Cc: <linuxbios at openbios.org>
Sent: Wednesday, November 09, 2005 7:39 PM
Subject: Re: [LinuxBIOS] Build broken?


> Please change ROM_IMAGE_SIZE in romimage "fallback" section to 0x16380
>
> YH
>
>
>
> -- 
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios




From okajima at digitalinfra.co.jp  Thu Nov 10 21:49:23 2005
From: okajima at digitalinfra.co.jp (Jun OKAJIMA)
Date: Fri, 11 Nov 2005 05:49:23 +0900
Subject: [LinuxBIOS] VIA EPIA M10000 (Nehemiah) CentaurHauls Stepping 5
 support status
In-Reply-To: <20051109110604.70e1289b.a.borisov@tesv.tmb.ru>
References: <20051109110604.70e1289b.a.borisov@tesv.tmb.ru>
Message-ID: <200511102049.AA00457@bbb-jz5c7z9hn9y.digitalinfra.co.jp>



>
>> I'd like to know the exact support status of LinuxBIOS on VIA EPIA
>> M10000 (Nehemiah) CentaurHauls Stepping 5. I've seen messages (August
>> 2005) that say VGA is supported, and more recent threads that say it
>> isn't. So, what is supported by the mainstream LinuxBios v2 ? And what
>> is not yet?
>> Are these any patches around that could achieve better support?
>> All different messages I see are rather confusing ...
>
>	Textmode at exactly your version of EPIA is supported. ACPI subsystem is ok. Videomode 
is limited to 320x240x8 or 640x480x4 (from my experience with EPIA-M 10K).
>

I feel I am facing same problem. Any solution? I have been using EPIA-MII 1.2GHz.
BTW, you tried both cold boot ( power off, wait a minite, then power on to boot)
and hot? boot( just push reset button).

As my experiment, cold boot does not work, but this way works.
1. you boot with normal bios.
2. switch a bios to lx2, with RD1 bios savior.
3. push reset button.

                          --- Okajima, Jun. Tokyo, Japan.




From okajima at digitalinfra.co.jp  Thu Nov 10 22:23:26 2005
From: okajima at digitalinfra.co.jp (Jun OKAJIMA)
Date: Fri, 11 Nov 2005 06:23:26 +0900
Subject: [LinuxBIOS] Tyan S2850 VGA
Message-ID: <200511102123.AA00459@bbb-jz5c7z9hn9y.digitalinfra.co.jp>


Hello.

I am looking for M/B with these specs.

1. Boots fast (2 or 3 secs) with linuxbios ( or other utils).
2. Supports VGA, including X.
3. High performance. Like over 2GHz or such.

How about S2850? it suppors VGA with X?
Or, you know any other M/B?

                   --- Okajima




From okajima at digitalinfra.co.jp  Thu Nov 10 22:23:25 2005
From: okajima at digitalinfra.co.jp (Jun OKAJIMA)
Date: Fri, 11 Nov 2005 06:23:25 +0900
Subject: [LinuxBIOS] Fast booting
Message-ID: <200511102123.AA00458@bbb-jz5c7z9hn9y.digitalinfra.co.jp>





Do you know any other fast boot solution than linuxbios?
I tested Via fast boot util, but it is not so fast...

For example, how about this.
General Software Embedded BIOS
http://www.gensw.com/pages/prod/firmbase/firmbase.htm

                      --- Okajima, Jun. Tokyo, Japan.



From rminnich at lanl.gov  Thu Nov 10 22:35:59 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 10 Nov 2005 14:35:59 -0700
Subject: [LinuxBIOS] Tyan S2850 VGA
In-Reply-To: <200511102123.AA00459@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
References: <200511102123.AA00459@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
Message-ID: <4373BD3F.5020903@lanl.gov>

Jun OKAJIMA wrote:
> Hello.
> 
> I am looking for M/B with these specs.
> 
> 1. Boots fast (2 or 3 secs) with linuxbios ( or other utils).
> 2. Supports VGA, including X.
> 3. High performance. Like over 2GHz or such.
> 
> How about S2850? it suppors VGA with X?
> Or, you know any other M/B?
> 
>                    --- Okajima
> 
> 

2881 is a good general purpose mobo, and 2885 has 8x agp. These are from 
tyan.

ron



From smithbone at gmail.com  Thu Nov 10 22:44:51 2005
From: smithbone at gmail.com (Richard Smith)
Date: Thu, 10 Nov 2005 15:44:51 -0600
Subject: [LinuxBIOS] Fast booting
In-Reply-To: <200511102123.AA00458@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
References: <200511102123.AA00458@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
Message-ID: <8a0c36780511101344i952521dj82b55639ec80d536@mail.gmail.com>

> Do you know any other fast boot solution than linuxbios?
> I tested Via fast boot util, but it is not so fast...
>
> For example, how about this.
> General Software Embedded BIOS
> http://www.gensw.com/pages/prod/firmbase/firmbase.htm
>

I've not used firmbase.  But I have used GenSw on a previous project.

You will need some cash.  3 years ago the royalites were about $7/copy
minimum lot of 100. Source is available but it costs about $20k.  Its
one massive pile of assembly code.  Resonablly well coded though.  And
when I got it all setup it worked nicely.  The support although
expensive was good.  In some cases I was talking to the guy who wrote
a lot of the code.

I don't know any of the current prices.

We get a lot of eval boards now that have GenSW's stuff on them now
though and I really don't care for thier license scheme.  They have a
large delay built into the boot sequence and you have to e-mail in or
call to get a license that will by-pass that.  I did call (and e-mail)
several times for one board but never got a response.

--
Richard A. Smith



From yinghai.lu at amd.com  Thu Nov 10 23:10:01 2005
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Thu, 10 Nov 2005 14:10:01 -0800
Subject: [LinuxBIOS] Build broken?
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E0622F@ssvlexmb2.amd.com>

OK, Let me explain that again:

Final LinuxBIOS image = VGABIOS ROM + Normal Image + FallBack Image

FallBack Image = PayLoad + linuxbios_ram.n2v + linuxbios_rom

Linuxbios_rom  = crt0.S + init.o + id + reset_vector

Reset_vector is sit on 0xfffffff0, and at the very beginning, reset
happen, the ROM only can be accessed in 64K range. So need to make sure
_start in crt0.S need to stay in last 64 address range.

The init.o will include cache_as_ram_auto.c in the fallback amd64_main,
it will enabled the access 4M flash access. 

When We were using ROMCC, the crt0.S will be very bigger (it include
auto.inc), So for 8 way or 4 way system, It will push out the _start out
of last 64K.

When We are using CAR, the init.o is all the same size for 8way and 2
way system. ( because CAR use gcc, and have real stack for functional
call, ROMCC can not have stack because of limited regs)

Another problem is if put set ROM_IMAGE_SIZE too big, the current lds
can not curbe crt0.S to stay in last 64K too...

So you need to set your ROM_IMAGE_SIZE carefully for FALLBACK image.
If it is too small, it could not fit Payload
+linuxbios_ram.n2v+linuxbios.rom

It it is too big, _start in crt0.S will out of last 64K....

Later we could modify .lds to force crt0.S and init.o stay in last
64K....

Or change Linuxbios_rom = init.o + crt0.S + id + reset_vector.... ( need
make sure enable_rom in 64K too...)

But is not high priority, because crt0.S+init.o for CAR are always
small....

Other problem is you must use Linux otherthan Redhat and Suse????
And you need to upgrade your gcc

YH

-----Original Message-----
From: beneo [mailto:beneo at comcast.net] 
Sent: Thursday, November 10, 2005 11:54 AM
To: Lu, Yinghai; Ronald G Minnich
Cc: linuxbios at openbios.org
Subject: Re: [LinuxBIOS] Build broken?

Thanks. It works on one of issues I have encountered.

My immidiate question is why my ROM_IMAGE_SIZE with larger value 0x20000
won't work, but with 0x16380 would work? If you don't tell me this, I
probably would never be able to figure out.

My have another issue, It looks like a bug in target tyan/s2891. I'm
trying
to build tyan/s2891. No matter what I change, I always get a build error
like:
---
gcc -m32 -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld
crt0.o
init.o
/usr/bin/ld: section .rodata.str1.32 [fffbff80 -> fffc0091] overlaps
section
.reset [fffbfff0 -> fffbffff]
collect2: ld returned 1 exit status
make[1]: *** [linuxbios] Error 1
---

Then I looked at ldscript file, it included
southbridge/nvidia/ck804/id.lds
file, which looks like this:
---
SECTIONS {
        . = (_ROMBASE + ROM_IMAGE_SIZE - 0x80) - (__id_end -
__id_start);
        .id (.): {
                *(.id)
        }
}
---

There is no linker script would arrange section .rodata.str1.32. I guess
that just makes linker to patch section .rodata.str1.32 at end of .id
section, which caused the overlap with .reset section.

This looks to me is a bug in tyan/s2891. How do I fix this? is that OK
to
remove nvidia/ck804/id.lds?

thanks

beneo





----- Original Message ----- 
From: "Lu, Yinghai" <yinghai.lu at AMD.COM>
To: "beneo" <beneo at comcast.net>; "Ronald G Minnich" <rminnich at lanl.gov>
Cc: <linuxbios at openbios.org>
Sent: Wednesday, November 09, 2005 7:39 PM
Subject: Re: [LinuxBIOS] Build broken?


> Please change ROM_IMAGE_SIZE in romimage "fallback" section to 0x16380
>
> YH
>
>
>
> -- 
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios






From ollie at lanl.gov  Thu Nov 10 23:13:59 2005
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu, 10 Nov 2005 15:13:59 -0700
Subject: [LinuxBIOS] Tyan S2850 VGA
In-Reply-To: <200511102123.AA00459@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
References: <200511102123.AA00459@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
Message-ID: <1131660839.6839.5.camel@logarithm.lanl.gov>

On Fri, 2005-11-11 at 06:23 +0900, Jun OKAJIMA wrote:
> Hello.
> 
> I am looking for M/B with these specs.
> 
> 1. Boots fast (2 or 3 secs) with linuxbios ( or other utils).
> 2. Supports VGA, including X.
> 3. High performance. Like over 2GHz or such.
> 
> How about S2850? it suppors VGA with X?
> Or, you know any other M/B?
> 
>                    --- Okajima
> 
> 

Basically all those Tyan MBs supported by LB are good. VGA should
be working for all of them. If you need the fancy AGP VGA card, you
have to buy 2885. AFIAK, VGA on MB with PCI Express also works.
-- 
Li-Ta Lo <ollie at lanl.gov>
Los Alamos National Lab




From yinghai.lu at amd.com  Thu Nov 10 23:58:19 2005
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Thu, 10 Nov 2005 14:58:19 -0800
Subject: [LinuxBIOS] Build broken?
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E06230@ssvlexmb2.amd.com>

With attach lds, the linuxbios_rom will be fixed on 0x0xffff0000 for
fallback image.

Anyway address is fixed, leave last 64k for crt0.s and init.o now....

YH
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ldscript.lb
Type: application/octet-stream
Size: 1090 bytes
Desc: ldscript.lb
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20051110/8aae0261/attachment.obj>

From yinghai.lu at amd.com  Fri Nov 11 00:08:30 2005
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Thu, 10 Nov 2005 15:08:30 -0800
Subject: [LinuxBIOS] Build broken?
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E06231@ssvlexmb2.amd.com>

At the same time, you could set FALLBACK_SIZE to 256K, in case you have
a big FILO in etherboot with USB support.

YH





From beneo at comcast.net  Fri Nov 11 00:14:26 2005
From: beneo at comcast.net (beneo)
Date: Thu, 10 Nov 2005 15:14:26 -0800
Subject: [LinuxBIOS] Build broken?
References: <6F7DA19D05F3CF40B890C7CA2DB13A4201E0622F@ssvlexmb2.amd.com>
Message-ID: <007201c5e64c$7ee691f0$131814ac@trans.corp>

I understand what you say. It matches what I see in the code. However, my
questions are not addressed, or I didn't understand your explaination.

First, I'm using redhat Linux 9.0, my gcc -v output like this: "gcc version
3.2.2 20030222 (Red Hat Linux 3.2.2-5)", I hopt it is good enough to build
LinuxBIOS.

Second, tyan/s2891 build generate a section called .rodata.str1.32.  The
linker script doesn't have anything explict to handle this section. I think
the Linker just patch this section at end of the last  section that are
explicitly specified in the Linker script. In tyan/s2891 build, it is .id
section. The .id section is 0x70 bytes below .reset section. The
.rodata.str1.32 is larger than 0x70 bytes. Therefor, .rodata.str1.32 will
overlap with .reset section and cause the build to break. Are you saying my
compiler caused this issue?

Third, I understand _start must be in the last 64K, are you saying objcopy
would enforce this? To be more specific on my quesiton, when I'm useing
ROMCC, my crt0.o is larger than 64K, objcopy would compress certain portion
of crt0.o and make sure _start is in the last 64k?

Thanks

beneo

----- Original Message ----- 
From: "Lu, Yinghai" <yinghai.lu at amd.com>
To: "beneo" <beneo at comcast.net>; "Ronald G Minnich" <rminnich at lanl.gov>
Cc: <linuxbios at openbios.org>
Sent: Thursday, November 10, 2005 2:10 PM
Subject: Re: [LinuxBIOS] Build broken?


> OK, Let me explain that again:
>
> Final LinuxBIOS image = VGABIOS ROM + Normal Image + FallBack Image
>
> FallBack Image = PayLoad + linuxbios_ram.n2v + linuxbios_rom
>
> Linuxbios_rom  = crt0.S + init.o + id + reset_vector
>
> Reset_vector is sit on 0xfffffff0, and at the very beginning, reset
> happen, the ROM only can be accessed in 64K range. So need to make sure
> _start in crt0.S need to stay in last 64 address range.
>
> The init.o will include cache_as_ram_auto.c in the fallback amd64_main,
> it will enabled the access 4M flash access.
>
> When We were using ROMCC, the crt0.S will be very bigger (it include
> auto.inc), So for 8 way or 4 way system, It will push out the _start out
> of last 64K.
>
> When We are using CAR, the init.o is all the same size for 8way and 2
> way system. ( because CAR use gcc, and have real stack for functional
> call, ROMCC can not have stack because of limited regs)
>
> Another problem is if put set ROM_IMAGE_SIZE too big, the current lds
> can not curbe crt0.S to stay in last 64K too...
>
> So you need to set your ROM_IMAGE_SIZE carefully for FALLBACK image.
> If it is too small, it could not fit Payload
> +linuxbios_ram.n2v+linuxbios.rom
>
> It it is too big, _start in crt0.S will out of last 64K....
>
> Later we could modify .lds to force crt0.S and init.o stay in last
> 64K....
>
> Or change Linuxbios_rom = init.o + crt0.S + id + reset_vector.... ( need
> make sure enable_rom in 64K too...)
>
> But is not high priority, because crt0.S+init.o for CAR are always
> small....
>
> Other problem is you must use Linux otherthan Redhat and Suse????
> And you need to upgrade your gcc
>
> YH
>
> -----Original Message-----
> From: beneo [mailto:beneo at comcast.net]
> Sent: Thursday, November 10, 2005 11:54 AM
> To: Lu, Yinghai; Ronald G Minnich
> Cc: linuxbios at openbios.org
> Subject: Re: [LinuxBIOS] Build broken?
>
> Thanks. It works on one of issues I have encountered.
>
> My immidiate question is why my ROM_IMAGE_SIZE with larger value 0x20000
> won't work, but with 0x16380 would work? If you don't tell me this, I
> probably would never be able to figure out.
>
> My have another issue, It looks like a bug in target tyan/s2891. I'm
> trying
> to build tyan/s2891. No matter what I change, I always get a build error
> like:
> ---
> gcc -m32 -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld
> crt0.o
> init.o
> /usr/bin/ld: section .rodata.str1.32 [fffbff80 -> fffc0091] overlaps
> section
> .reset [fffbfff0 -> fffbffff]
> collect2: ld returned 1 exit status
> make[1]: *** [linuxbios] Error 1
> ---
>
> Then I looked at ldscript file, it included
> southbridge/nvidia/ck804/id.lds
> file, which looks like this:
> ---
> SECTIONS {
>         . = (_ROMBASE + ROM_IMAGE_SIZE - 0x80) - (__id_end -
> __id_start);
>         .id (.): {
>                 *(.id)
>         }
> }
> ---
>
> There is no linker script would arrange section .rodata.str1.32. I guess
> that just makes linker to patch section .rodata.str1.32 at end of .id
> section, which caused the overlap with .reset section.
>
> This looks to me is a bug in tyan/s2891. How do I fix this? is that OK
> to
> remove nvidia/ck804/id.lds?
>
> thanks
>
> beneo
>
>
>
>
>
> ----- Original Message ----- 
> From: "Lu, Yinghai" <yinghai.lu at AMD.COM>
> To: "beneo" <beneo at comcast.net>; "Ronald G Minnich" <rminnich at lanl.gov>
> Cc: <linuxbios at openbios.org>
> Sent: Wednesday, November 09, 2005 7:39 PM
> Subject: Re: [LinuxBIOS] Build broken?
>
>
> > Please change ROM_IMAGE_SIZE in romimage "fallback" section to 0x16380
> >
> > YH
> >
> >
> >
> > -- 
> > LinuxBIOS mailing list
> > LinuxBIOS at openbios.org
> > http://www.openbios.org/mailman/listinfo/linuxbios
>
>
>
>
> -- 
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios




From yinghai.lu at amd.com  Fri Nov 11 00:15:37 2005
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Thu, 10 Nov 2005 15:15:37 -0800
Subject: [LinuxBIOS] Build broken?
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E06232@ssvlexmb2.amd.com>

With this change, We can fix all K8 MB 
ROM_IMAGE_SIZE=0x20000    #128K
FALLBACK_SIZE=0x40000     #256K

[ffff0000, ffffffff) : rom  (64K)
[fffe0000, fffeffff) : ram  (64K)
[fffc0000, fffdffff) : payload (128K) too big...

XIP_ROM_SIZE will be equal to ROM_IMAGE_SIZE...

All fixed address....

YH

-----Original Message-----
From: linuxbios-bounces at openbios.org
[mailto:linuxbios-bounces at openbios.org] On Behalf Of Lu, Yinghai
Sent: Thursday, November 10, 2005 2:58 PM
To: beneo; Ronald G Minnich
Cc: linuxbios at openbios.org
Subject: Re: [LinuxBIOS] Build broken?

With attach lds, the linuxbios_rom will be fixed on 0x0xffff0000 for
fallback image.

Anyway address is fixed, leave last 64k for crt0.s and init.o now....

YH




From yinghai.lu at AMD.COM  Fri Nov 11 00:17:03 2005
From: yinghai.lu at AMD.COM (Lu, Yinghai)
Date: Thu, 10 Nov 2005 15:17:03 -0800
Subject: [LinuxBIOS] Build broken?
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E06233@ssvlexmb2.amd.com>

Why not use gcc 3.4....?

YH

-----Original Message-----
From: beneo [mailto:beneo at comcast.net] 
Sent: Thursday, November 10, 2005 3:14 PM
To: Lu, Yinghai; Ronald G Minnich
Cc: linuxbios at openbios.org
Subject: Re: [LinuxBIOS] Build broken?

I understand what you say. It matches what I see in the code. However,
my
questions are not addressed, or I didn't understand your explaination.

First, I'm using redhat Linux 9.0, my gcc -v output like this: "gcc
version
3.2.2 20030222 (Red Hat Linux 3.2.2-5)", I hopt it is good enough to
build
LinuxBIOS.

Second, tyan/s2891 build generate a section called .rodata.str1.32.  The
linker script doesn't have anything explict to handle this section. I
think
the Linker just patch this section at end of the last  section that are
explicitly specified in the Linker script. In tyan/s2891 build, it is
.id
section. The .id section is 0x70 bytes below .reset section. The
.rodata.str1.32 is larger than 0x70 bytes. Therefor, .rodata.str1.32
will
overlap with .reset section and cause the build to break. Are you saying
my
compiler caused this issue?

Third, I understand _start must be in the last 64K, are you saying
objcopy
would enforce this? To be more specific on my quesiton, when I'm useing
ROMCC, my crt0.o is larger than 64K, objcopy would compress certain
portion
of crt0.o and make sure _start is in the last 64k?

Thanks

beneo

----- Original Message ----- 
From: "Lu, Yinghai" <yinghai.lu at amd.com>
To: "beneo" <beneo at comcast.net>; "Ronald G Minnich" <rminnich at lanl.gov>
Cc: <linuxbios at openbios.org>
Sent: Thursday, November 10, 2005 2:10 PM
Subject: Re: [LinuxBIOS] Build broken?


> OK, Let me explain that again:
>
> Final LinuxBIOS image = VGABIOS ROM + Normal Image + FallBack Image
>
> FallBack Image = PayLoad + linuxbios_ram.n2v + linuxbios_rom
>
> Linuxbios_rom  = crt0.S + init.o + id + reset_vector
>
> Reset_vector is sit on 0xfffffff0, and at the very beginning, reset
> happen, the ROM only can be accessed in 64K range. So need to make
sure
> _start in crt0.S need to stay in last 64 address range.
>
> The init.o will include cache_as_ram_auto.c in the fallback
amd64_main,
> it will enabled the access 4M flash access.
>
> When We were using ROMCC, the crt0.S will be very bigger (it include
> auto.inc), So for 8 way or 4 way system, It will push out the _start
out
> of last 64K.
>
> When We are using CAR, the init.o is all the same size for 8way and 2
> way system. ( because CAR use gcc, and have real stack for functional
> call, ROMCC can not have stack because of limited regs)
>
> Another problem is if put set ROM_IMAGE_SIZE too big, the current lds
> can not curbe crt0.S to stay in last 64K too...
>
> So you need to set your ROM_IMAGE_SIZE carefully for FALLBACK image.
> If it is too small, it could not fit Payload
> +linuxbios_ram.n2v+linuxbios.rom
>
> It it is too big, _start in crt0.S will out of last 64K....
>
> Later we could modify .lds to force crt0.S and init.o stay in last
> 64K....
>
> Or change Linuxbios_rom = init.o + crt0.S + id + reset_vector.... (
need
> make sure enable_rom in 64K too...)
>
> But is not high priority, because crt0.S+init.o for CAR are always
> small....
>
> Other problem is you must use Linux otherthan Redhat and Suse????
> And you need to upgrade your gcc
>
> YH
>
> -----Original Message-----
> From: beneo [mailto:beneo at comcast.net]
> Sent: Thursday, November 10, 2005 11:54 AM
> To: Lu, Yinghai; Ronald G Minnich
> Cc: linuxbios at openbios.org
> Subject: Re: [LinuxBIOS] Build broken?
>
> Thanks. It works on one of issues I have encountered.
>
> My immidiate question is why my ROM_IMAGE_SIZE with larger value
0x20000
> won't work, but with 0x16380 would work? If you don't tell me this, I
> probably would never be able to figure out.
>
> My have another issue, It looks like a bug in target tyan/s2891. I'm
> trying
> to build tyan/s2891. No matter what I change, I always get a build
error
> like:
> ---
> gcc -m32 -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld
> crt0.o
> init.o
> /usr/bin/ld: section .rodata.str1.32 [fffbff80 -> fffc0091] overlaps
> section
> .reset [fffbfff0 -> fffbffff]
> collect2: ld returned 1 exit status
> make[1]: *** [linuxbios] Error 1
> ---
>
> Then I looked at ldscript file, it included
> southbridge/nvidia/ck804/id.lds
> file, which looks like this:
> ---
> SECTIONS {
>         . = (_ROMBASE + ROM_IMAGE_SIZE - 0x80) - (__id_end -
> __id_start);
>         .id (.): {
>                 *(.id)
>         }
> }
> ---
>
> There is no linker script would arrange section .rodata.str1.32. I
guess
> that just makes linker to patch section .rodata.str1.32 at end of .id
> section, which caused the overlap with .reset section.
>
> This looks to me is a bug in tyan/s2891. How do I fix this? is that OK
> to
> remove nvidia/ck804/id.lds?
>
> thanks
>
> beneo
>
>
>
>
>
> ----- Original Message ----- 
> From: "Lu, Yinghai" <yinghai.lu at AMD.COM>
> To: "beneo" <beneo at comcast.net>; "Ronald G Minnich"
<rminnich at lanl.gov>
> Cc: <linuxbios at openbios.org>
> Sent: Wednesday, November 09, 2005 7:39 PM
> Subject: Re: [LinuxBIOS] Build broken?
>
>
> > Please change ROM_IMAGE_SIZE in romimage "fallback" section to
0x16380
> >
> > YH
> >
> >
> >
> > -- 
> > LinuxBIOS mailing list
> > LinuxBIOS at openbios.org
> > http://www.openbios.org/mailman/listinfo/linuxbios
>
>
>
>
> -- 
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios






From beneo at comcast.net  Fri Nov 11 00:22:10 2005
From: beneo at comcast.net (beneo)
Date: Thu, 10 Nov 2005 15:22:10 -0800
Subject: [LinuxBIOS] Build broken?
References: <6F7DA19D05F3CF40B890C7CA2DB13A4201E06233@ssvlexmb2.amd.com>
Message-ID: <008c01c5e64d$9467ad60$131814ac@trans.corp>

Is gcc 3.4 a requirement?

If not, I would save the trouble and stay with 3.2.2. I didn't encounter any
trouble building LinuxBIOS using this version until now. In another word,
are you absulutely sure the issue I have stated is caused by gcc 3.2.2

Thanks

beneo

----- Original Message ----- 
From: "Lu, Yinghai" <yinghai.lu at AMD.COM>
To: "beneo" <beneo at comcast.net>; "Ronald G Minnich" <rminnich at lanl.gov>
Cc: <linuxbios at openbios.org>
Sent: Thursday, November 10, 2005 3:17 PM
Subject: RE: [LinuxBIOS] Build broken?


Why not use gcc 3.4....?

YH

-----Original Message-----
From: beneo [mailto:beneo at comcast.net]
Sent: Thursday, November 10, 2005 3:14 PM
To: Lu, Yinghai; Ronald G Minnich
Cc: linuxbios at openbios.org
Subject: Re: [LinuxBIOS] Build broken?

I understand what you say. It matches what I see in the code. However,
my
questions are not addressed, or I didn't understand your explaination.

First, I'm using redhat Linux 9.0, my gcc -v output like this: "gcc
version
3.2.2 20030222 (Red Hat Linux 3.2.2-5)", I hopt it is good enough to
build
LinuxBIOS.

Second, tyan/s2891 build generate a section called .rodata.str1.32.  The
linker script doesn't have anything explict to handle this section. I
think
the Linker just patch this section at end of the last  section that are
explicitly specified in the Linker script. In tyan/s2891 build, it is
.id
section. The .id section is 0x70 bytes below .reset section. The
.rodata.str1.32 is larger than 0x70 bytes. Therefor, .rodata.str1.32
will
overlap with .reset section and cause the build to break. Are you saying
my
compiler caused this issue?

Third, I understand _start must be in the last 64K, are you saying
objcopy
would enforce this? To be more specific on my quesiton, when I'm useing
ROMCC, my crt0.o is larger than 64K, objcopy would compress certain
portion
of crt0.o and make sure _start is in the last 64k?

Thanks

beneo

----- Original Message ----- 
From: "Lu, Yinghai" <yinghai.lu at amd.com>
To: "beneo" <beneo at comcast.net>; "Ronald G Minnich" <rminnich at lanl.gov>
Cc: <linuxbios at openbios.org>
Sent: Thursday, November 10, 2005 2:10 PM
Subject: Re: [LinuxBIOS] Build broken?


> OK, Let me explain that again:
>
> Final LinuxBIOS image = VGABIOS ROM + Normal Image + FallBack Image
>
> FallBack Image = PayLoad + linuxbios_ram.n2v + linuxbios_rom
>
> Linuxbios_rom  = crt0.S + init.o + id + reset_vector
>
> Reset_vector is sit on 0xfffffff0, and at the very beginning, reset
> happen, the ROM only can be accessed in 64K range. So need to make
sure
> _start in crt0.S need to stay in last 64 address range.
>
> The init.o will include cache_as_ram_auto.c in the fallback
amd64_main,
> it will enabled the access 4M flash access.
>
> When We were using ROMCC, the crt0.S will be very bigger (it include
> auto.inc), So for 8 way or 4 way system, It will push out the _start
out
> of last 64K.
>
> When We are using CAR, the init.o is all the same size for 8way and 2
> way system. ( because CAR use gcc, and have real stack for functional
> call, ROMCC can not have stack because of limited regs)
>
> Another problem is if put set ROM_IMAGE_SIZE too big, the current lds
> can not curbe crt0.S to stay in last 64K too...
>
> So you need to set your ROM_IMAGE_SIZE carefully for FALLBACK image.
> If it is too small, it could not fit Payload
> +linuxbios_ram.n2v+linuxbios.rom
>
> It it is too big, _start in crt0.S will out of last 64K....
>
> Later we could modify .lds to force crt0.S and init.o stay in last
> 64K....
>
> Or change Linuxbios_rom = init.o + crt0.S + id + reset_vector.... (
need
> make sure enable_rom in 64K too...)
>
> But is not high priority, because crt0.S+init.o for CAR are always
> small....
>
> Other problem is you must use Linux otherthan Redhat and Suse????
> And you need to upgrade your gcc
>
> YH
>
> -----Original Message-----
> From: beneo [mailto:beneo at comcast.net]
> Sent: Thursday, November 10, 2005 11:54 AM
> To: Lu, Yinghai; Ronald G Minnich
> Cc: linuxbios at openbios.org
> Subject: Re: [LinuxBIOS] Build broken?
>
> Thanks. It works on one of issues I have encountered.
>
> My immidiate question is why my ROM_IMAGE_SIZE with larger value
0x20000
> won't work, but with 0x16380 would work? If you don't tell me this, I
> probably would never be able to figure out.
>
> My have another issue, It looks like a bug in target tyan/s2891. I'm
> trying
> to build tyan/s2891. No matter what I change, I always get a build
error
> like:
> ---
> gcc -m32 -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld
> crt0.o
> init.o
> /usr/bin/ld: section .rodata.str1.32 [fffbff80 -> fffc0091] overlaps
> section
> .reset [fffbfff0 -> fffbffff]
> collect2: ld returned 1 exit status
> make[1]: *** [linuxbios] Error 1
> ---
>
> Then I looked at ldscript file, it included
> southbridge/nvidia/ck804/id.lds
> file, which looks like this:
> ---
> SECTIONS {
>         . = (_ROMBASE + ROM_IMAGE_SIZE - 0x80) - (__id_end -
> __id_start);
>         .id (.): {
>                 *(.id)
>         }
> }
> ---
>
> There is no linker script would arrange section .rodata.str1.32. I
guess
> that just makes linker to patch section .rodata.str1.32 at end of .id
> section, which caused the overlap with .reset section.
>
> This looks to me is a bug in tyan/s2891. How do I fix this? is that OK
> to
> remove nvidia/ck804/id.lds?
>
> thanks
>
> beneo
>
>
>
>
>
> ----- Original Message ----- 
> From: "Lu, Yinghai" <yinghai.lu at AMD.COM>
> To: "beneo" <beneo at comcast.net>; "Ronald G Minnich"
<rminnich at lanl.gov>
> Cc: <linuxbios at openbios.org>
> Sent: Wednesday, November 09, 2005 7:39 PM
> Subject: Re: [LinuxBIOS] Build broken?
>
>
> > Please change ROM_IMAGE_SIZE in romimage "fallback" section to
0x16380
> >
> > YH
> >
> >
> >
> > -- 
> > LinuxBIOS mailing list
> > LinuxBIOS at openbios.org
> > http://www.openbios.org/mailman/listinfo/linuxbios
>
>
>
>
> -- 
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios






From yinghai.lu at AMD.COM  Fri Nov 11 00:29:45 2005
From: yinghai.lu at AMD.COM (Lu, Yinghai)
Date: Thu, 10 Nov 2005 15:29:45 -0800
Subject: [LinuxBIOS] Build broken?
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A420309490A@ssvlexmb2.amd.com>

You can change section name in arch/i386/Config.lb if you have strange
compiler that produce werid section name.

YH

-----Original Message-----
From: beneo [mailto:beneo at comcast.net] 
Sent: Thursday, November 10, 2005 3:22 PM
To: Lu, Yinghai; Ronald G Minnich
Cc: linuxbios at openbios.org
Subject: Re: [LinuxBIOS] Build broken?

Is gcc 3.4 a requirement?

If not, I would save the trouble and stay with 3.2.2. I didn't encounter
any
trouble building LinuxBIOS using this version until now. In another
word,
are you absulutely sure the issue I have stated is caused by gcc 3.2.2

Thanks

beneo

----- Original Message ----- 
From: "Lu, Yinghai" <yinghai.lu at AMD.COM>
To: "beneo" <beneo at comcast.net>; "Ronald G Minnich" <rminnich at lanl.gov>
Cc: <linuxbios at openbios.org>
Sent: Thursday, November 10, 2005 3:17 PM
Subject: RE: [LinuxBIOS] Build broken?


Why not use gcc 3.4....?

YH

-----Original Message-----
From: beneo [mailto:beneo at comcast.net]
Sent: Thursday, November 10, 2005 3:14 PM
To: Lu, Yinghai; Ronald G Minnich
Cc: linuxbios at openbios.org
Subject: Re: [LinuxBIOS] Build broken?

I understand what you say. It matches what I see in the code. However,
my
questions are not addressed, or I didn't understand your explaination.

First, I'm using redhat Linux 9.0, my gcc -v output like this: "gcc
version
3.2.2 20030222 (Red Hat Linux 3.2.2-5)", I hopt it is good enough to
build
LinuxBIOS.

Second, tyan/s2891 build generate a section called .rodata.str1.32.  The
linker script doesn't have anything explict to handle this section. I
think
the Linker just patch this section at end of the last  section that are
explicitly specified in the Linker script. In tyan/s2891 build, it is
.id
section. The .id section is 0x70 bytes below .reset section. The
.rodata.str1.32 is larger than 0x70 bytes. Therefor, .rodata.str1.32
will
overlap with .reset section and cause the build to break. Are you saying
my
compiler caused this issue?

Third, I understand _start must be in the last 64K, are you saying
objcopy
would enforce this? To be more specific on my quesiton, when I'm useing
ROMCC, my crt0.o is larger than 64K, objcopy would compress certain
portion
of crt0.o and make sure _start is in the last 64k?

Thanks

beneo

----- Original Message ----- 
From: "Lu, Yinghai" <yinghai.lu at amd.com>
To: "beneo" <beneo at comcast.net>; "Ronald G Minnich" <rminnich at lanl.gov>
Cc: <linuxbios at openbios.org>
Sent: Thursday, November 10, 2005 2:10 PM
Subject: Re: [LinuxBIOS] Build broken?


> OK, Let me explain that again:
>
> Final LinuxBIOS image = VGABIOS ROM + Normal Image + FallBack Image
>
> FallBack Image = PayLoad + linuxbios_ram.n2v + linuxbios_rom
>
> Linuxbios_rom  = crt0.S + init.o + id + reset_vector
>
> Reset_vector is sit on 0xfffffff0, and at the very beginning, reset
> happen, the ROM only can be accessed in 64K range. So need to make
sure
> _start in crt0.S need to stay in last 64 address range.
>
> The init.o will include cache_as_ram_auto.c in the fallback
amd64_main,
> it will enabled the access 4M flash access.
>
> When We were using ROMCC, the crt0.S will be very bigger (it include
> auto.inc), So for 8 way or 4 way system, It will push out the _start
out
> of last 64K.
>
> When We are using CAR, the init.o is all the same size for 8way and 2
> way system. ( because CAR use gcc, and have real stack for functional
> call, ROMCC can not have stack because of limited regs)
>
> Another problem is if put set ROM_IMAGE_SIZE too big, the current lds
> can not curbe crt0.S to stay in last 64K too...
>
> So you need to set your ROM_IMAGE_SIZE carefully for FALLBACK image.
> If it is too small, it could not fit Payload
> +linuxbios_ram.n2v+linuxbios.rom
>
> It it is too big, _start in crt0.S will out of last 64K....
>
> Later we could modify .lds to force crt0.S and init.o stay in last
> 64K....
>
> Or change Linuxbios_rom = init.o + crt0.S + id + reset_vector.... (
need
> make sure enable_rom in 64K too...)
>
> But is not high priority, because crt0.S+init.o for CAR are always
> small....
>
> Other problem is you must use Linux otherthan Redhat and Suse????
> And you need to upgrade your gcc
>
> YH
>
> -----Original Message-----
> From: beneo [mailto:beneo at comcast.net]
> Sent: Thursday, November 10, 2005 11:54 AM
> To: Lu, Yinghai; Ronald G Minnich
> Cc: linuxbios at openbios.org
> Subject: Re: [LinuxBIOS] Build broken?
>
> Thanks. It works on one of issues I have encountered.
>
> My immidiate question is why my ROM_IMAGE_SIZE with larger value
0x20000
> won't work, but with 0x16380 would work? If you don't tell me this, I
> probably would never be able to figure out.
>
> My have another issue, It looks like a bug in target tyan/s2891. I'm
> trying
> to build tyan/s2891. No matter what I change, I always get a build
error
> like:
> ---
> gcc -m32 -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld
> crt0.o
> init.o
> /usr/bin/ld: section .rodata.str1.32 [fffbff80 -> fffc0091] overlaps
> section
> .reset [fffbfff0 -> fffbffff]
> collect2: ld returned 1 exit status
> make[1]: *** [linuxbios] Error 1
> ---
>
> Then I looked at ldscript file, it included
> southbridge/nvidia/ck804/id.lds
> file, which looks like this:
> ---
> SECTIONS {
>         . = (_ROMBASE + ROM_IMAGE_SIZE - 0x80) - (__id_end -
> __id_start);
>         .id (.): {
>                 *(.id)
>         }
> }
> ---
>
> There is no linker script would arrange section .rodata.str1.32. I
guess
> that just makes linker to patch section .rodata.str1.32 at end of .id
> section, which caused the overlap with .reset section.
>
> This looks to me is a bug in tyan/s2891. How do I fix this? is that OK
> to
> remove nvidia/ck804/id.lds?
>
> thanks
>
> beneo
>
>
>
>
>
> ----- Original Message ----- 
> From: "Lu, Yinghai" <yinghai.lu at AMD.COM>
> To: "beneo" <beneo at comcast.net>; "Ronald G Minnich"
<rminnich at lanl.gov>
> Cc: <linuxbios at openbios.org>
> Sent: Wednesday, November 09, 2005 7:39 PM
> Subject: Re: [LinuxBIOS] Build broken?
>
>
> > Please change ROM_IMAGE_SIZE in romimage "fallback" section to
0x16380
> >
> > YH
> >
> >
> >
> > -- 
> > LinuxBIOS mailing list
> > LinuxBIOS at openbios.org
> > http://www.openbios.org/mailman/listinfo/linuxbios
>
>
>
>
> -- 
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios








From beneo at comcast.net  Fri Nov 11 02:26:24 2005
From: beneo at comcast.net (beneo)
Date: Thu, 10 Nov 2005 17:26:24 -0800
Subject: [LinuxBIOS] Build broken?
References: <6F7DA19D05F3CF40B890C7CA2DB13A420309490A@ssvlexmb2.amd.com>
Message-ID: <009501c5e65e$eea08a20$131814ac@trans.corp>

thanks for the help, otherwise, I probably would spend days to figure out. I
create a cace_as_ram.lds in my directory which handles the section not in
standard lds, I can build now.

Only mystery still remain is why when I have ROM_IMAGE_SIZE set to 0x20000
in fallback, it won't build, but set to smaller 0x16380, it builds. It seems
caused objcopy to generate a different size of linuxbios.strip file. I think
objcopy should have nothing to do with it. but something went wrong before
that. It should be a bug in the code, I just don't know what it is.

Thanks

beneo



----- Original Message ----- 
From: "Lu, Yinghai" <yinghai.lu at AMD.COM>
To: "beneo" <beneo at comcast.net>; "Ronald G Minnich" <rminnich at lanl.gov>
Cc: <linuxbios at openbios.org>
Sent: Thursday, November 10, 2005 3:29 PM
Subject: Re: [LinuxBIOS] Build broken?


> You can change section name in arch/i386/Config.lb if you have strange
> compiler that produce werid section name.
>
> YH
>
> -----Original Message-----
> From: beneo [mailto:beneo at comcast.net]
> Sent: Thursday, November 10, 2005 3:22 PM
> To: Lu, Yinghai; Ronald G Minnich
> Cc: linuxbios at openbios.org
> Subject: Re: [LinuxBIOS] Build broken?
>
> Is gcc 3.4 a requirement?
>
> If not, I would save the trouble and stay with 3.2.2. I didn't encounter
> any
> trouble building LinuxBIOS using this version until now. In another
> word,
> are you absulutely sure the issue I have stated is caused by gcc 3.2.2
>
> Thanks
>
> beneo
>
> ----- Original Message ----- 
> From: "Lu, Yinghai" <yinghai.lu at AMD.COM>
> To: "beneo" <beneo at comcast.net>; "Ronald G Minnich" <rminnich at lanl.gov>
> Cc: <linuxbios at openbios.org>
> Sent: Thursday, November 10, 2005 3:17 PM
> Subject: RE: [LinuxBIOS] Build broken?
>
>
> Why not use gcc 3.4....?
>
> YH
>
> -----Original Message-----
> From: beneo [mailto:beneo at comcast.net]
> Sent: Thursday, November 10, 2005 3:14 PM
> To: Lu, Yinghai; Ronald G Minnich
> Cc: linuxbios at openbios.org
> Subject: Re: [LinuxBIOS] Build broken?
>
> I understand what you say. It matches what I see in the code. However,
> my
> questions are not addressed, or I didn't understand your explaination.
>
> First, I'm using redhat Linux 9.0, my gcc -v output like this: "gcc
> version
> 3.2.2 20030222 (Red Hat Linux 3.2.2-5)", I hopt it is good enough to
> build
> LinuxBIOS.
>
> Second, tyan/s2891 build generate a section called .rodata.str1.32.  The
> linker script doesn't have anything explict to handle this section. I
> think
> the Linker just patch this section at end of the last  section that are
> explicitly specified in the Linker script. In tyan/s2891 build, it is
> .id
> section. The .id section is 0x70 bytes below .reset section. The
> .rodata.str1.32 is larger than 0x70 bytes. Therefor, .rodata.str1.32
> will
> overlap with .reset section and cause the build to break. Are you saying
> my
> compiler caused this issue?
>
> Third, I understand _start must be in the last 64K, are you saying
> objcopy
> would enforce this? To be more specific on my quesiton, when I'm useing
> ROMCC, my crt0.o is larger than 64K, objcopy would compress certain
> portion
> of crt0.o and make sure _start is in the last 64k?
>
> Thanks
>
> beneo
>
> ----- Original Message ----- 
> From: "Lu, Yinghai" <yinghai.lu at amd.com>
> To: "beneo" <beneo at comcast.net>; "Ronald G Minnich" <rminnich at lanl.gov>
> Cc: <linuxbios at openbios.org>
> Sent: Thursday, November 10, 2005 2:10 PM
> Subject: Re: [LinuxBIOS] Build broken?
>
>
> > OK, Let me explain that again:
> >
> > Final LinuxBIOS image = VGABIOS ROM + Normal Image + FallBack Image
> >
> > FallBack Image = PayLoad + linuxbios_ram.n2v + linuxbios_rom
> >
> > Linuxbios_rom  = crt0.S + init.o + id + reset_vector
> >
> > Reset_vector is sit on 0xfffffff0, and at the very beginning, reset
> > happen, the ROM only can be accessed in 64K range. So need to make
> sure
> > _start in crt0.S need to stay in last 64 address range.
> >
> > The init.o will include cache_as_ram_auto.c in the fallback
> amd64_main,
> > it will enabled the access 4M flash access.
> >
> > When We were using ROMCC, the crt0.S will be very bigger (it include
> > auto.inc), So for 8 way or 4 way system, It will push out the _start
> out
> > of last 64K.
> >
> > When We are using CAR, the init.o is all the same size for 8way and 2
> > way system. ( because CAR use gcc, and have real stack for functional
> > call, ROMCC can not have stack because of limited regs)
> >
> > Another problem is if put set ROM_IMAGE_SIZE too big, the current lds
> > can not curbe crt0.S to stay in last 64K too...
> >
> > So you need to set your ROM_IMAGE_SIZE carefully for FALLBACK image.
> > If it is too small, it could not fit Payload
> > +linuxbios_ram.n2v+linuxbios.rom
> >
> > It it is too big, _start in crt0.S will out of last 64K....
> >
> > Later we could modify .lds to force crt0.S and init.o stay in last
> > 64K....
> >
> > Or change Linuxbios_rom = init.o + crt0.S + id + reset_vector.... (
> need
> > make sure enable_rom in 64K too...)
> >
> > But is not high priority, because crt0.S+init.o for CAR are always
> > small....
> >
> > Other problem is you must use Linux otherthan Redhat and Suse????
> > And you need to upgrade your gcc
> >
> > YH
> >
> > -----Original Message-----
> > From: beneo [mailto:beneo at comcast.net]
> > Sent: Thursday, November 10, 2005 11:54 AM
> > To: Lu, Yinghai; Ronald G Minnich
> > Cc: linuxbios at openbios.org
> > Subject: Re: [LinuxBIOS] Build broken?
> >
> > Thanks. It works on one of issues I have encountered.
> >
> > My immidiate question is why my ROM_IMAGE_SIZE with larger value
> 0x20000
> > won't work, but with 0x16380 would work? If you don't tell me this, I
> > probably would never be able to figure out.
> >
> > My have another issue, It looks like a bug in target tyan/s2891. I'm
> > trying
> > to build tyan/s2891. No matter what I change, I always get a build
> error
> > like:
> > ---
> > gcc -m32 -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld
> > crt0.o
> > init.o
> > /usr/bin/ld: section .rodata.str1.32 [fffbff80 -> fffc0091] overlaps
> > section
> > .reset [fffbfff0 -> fffbffff]
> > collect2: ld returned 1 exit status
> > make[1]: *** [linuxbios] Error 1
> > ---
> >
> > Then I looked at ldscript file, it included
> > southbridge/nvidia/ck804/id.lds
> > file, which looks like this:
> > ---
> > SECTIONS {
> >         . = (_ROMBASE + ROM_IMAGE_SIZE - 0x80) - (__id_end -
> > __id_start);
> >         .id (.): {
> >                 *(.id)
> >         }
> > }
> > ---
> >
> > There is no linker script would arrange section .rodata.str1.32. I
> guess
> > that just makes linker to patch section .rodata.str1.32 at end of .id
> > section, which caused the overlap with .reset section.
> >
> > This looks to me is a bug in tyan/s2891. How do I fix this? is that OK
> > to
> > remove nvidia/ck804/id.lds?
> >
> > thanks
> >
> > beneo
> >
> >
> >
> >
> >
> > ----- Original Message ----- 
> > From: "Lu, Yinghai" <yinghai.lu at AMD.COM>
> > To: "beneo" <beneo at comcast.net>; "Ronald G Minnich"
> <rminnich at lanl.gov>
> > Cc: <linuxbios at openbios.org>
> > Sent: Wednesday, November 09, 2005 7:39 PM
> > Subject: Re: [LinuxBIOS] Build broken?
> >
> >
> > > Please change ROM_IMAGE_SIZE in romimage "fallback" section to
> 0x16380
> > >
> > > YH
> > >
> > >
> > >
> > > -- 
> > > LinuxBIOS mailing list
> > > LinuxBIOS at openbios.org
> > > http://www.openbios.org/mailman/listinfo/linuxbios
> >
> >
> >
> >
> > -- 
> > LinuxBIOS mailing list
> > LinuxBIOS at openbios.org
> > http://www.openbios.org/mailman/listinfo/linuxbios
>
>
>
>
>
>
> -- 
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios




From beneo at comcast.net  Fri Nov 11 02:42:29 2005
From: beneo at comcast.net (beneo)
Date: Thu, 10 Nov 2005 17:42:29 -0800
Subject: [LinuxBIOS] Build broken?
References: <6F7DA19D05F3CF40B890C7CA2DB13A420309490B@ssvlexmb2.amd.com>
Message-ID: <00a701c5e661$2f405a90$131814ac@trans.corp>

right, I should try this script when I have fallback ROM_IMAGE_SIZE larger
than 64k. Otherwise I would not be able to build. I will try it.

beneo.

----- Original Message ----- 
From: "Lu, Yinghai" <yinghai.lu at amd.com>
To: "beneo" <beneo at comcast.net>; "Ronald G Minnich" <rminnich at lanl.gov>
Cc: <linuxbios at openbios.org>
Sent: Thursday, November 10, 2005 5:32 PM
Subject: RE: [LinuxBIOS] Build broken?


Did you use my new ldscripts.lds?

Also you need to change you FALLBACK_SIZE in MB Option.lb to 0x40000

YH

-----Original Message-----
From: beneo [mailto:beneo at comcast.net]
Sent: Thursday, November 10, 2005 5:26 PM
To: Lu, Yinghai; Ronald G Minnich
Cc: linuxbios at openbios.org
Subject: Re: [LinuxBIOS] Build broken?

thanks for the help, otherwise, I probably would spend days to figure
out. I
create a cace_as_ram.lds in my directory which handles the section not
in
standard lds, I can build now.

Only mystery still remain is why when I have ROM_IMAGE_SIZE set to
0x20000
in fallback, it won't build, but set to smaller 0x16380, it builds. It
seems
caused objcopy to generate a different size of linuxbios.strip file. I
think
objcopy should have nothing to do with it. but something went wrong
before
that. It should be a bug in the code, I just don't know what it is.

Thanks

beneo



----- Original Message ----- 
From: "Lu, Yinghai" <yinghai.lu at AMD.COM>
To: "beneo" <beneo at comcast.net>; "Ronald G Minnich" <rminnich at lanl.gov>
Cc: <linuxbios at openbios.org>
Sent: Thursday, November 10, 2005 3:29 PM
Subject: Re: [LinuxBIOS] Build broken?


> You can change section name in arch/i386/Config.lb if you have strange
> compiler that produce werid section name.
>
> YH
>
> -----Original Message-----
> From: beneo [mailto:beneo at comcast.net]
> Sent: Thursday, November 10, 2005 3:22 PM
> To: Lu, Yinghai; Ronald G Minnich
> Cc: linuxbios at openbios.org
> Subject: Re: [LinuxBIOS] Build broken?
>
> Is gcc 3.4 a requirement?
>
> If not, I would save the trouble and stay with 3.2.2. I didn't
encounter
> any
> trouble building LinuxBIOS using this version until now. In another
> word,
> are you absulutely sure the issue I have stated is caused by gcc 3.2.2
>
> Thanks
>
> beneo
>
> ----- Original Message ----- 
> From: "Lu, Yinghai" <yinghai.lu at AMD.COM>
> To: "beneo" <beneo at comcast.net>; "Ronald G Minnich"
<rminnich at lanl.gov>
> Cc: <linuxbios at openbios.org>
> Sent: Thursday, November 10, 2005 3:17 PM
> Subject: RE: [LinuxBIOS] Build broken?
>
>
> Why not use gcc 3.4....?
>
> YH
>
> -----Original Message-----
> From: beneo [mailto:beneo at comcast.net]
> Sent: Thursday, November 10, 2005 3:14 PM
> To: Lu, Yinghai; Ronald G Minnich
> Cc: linuxbios at openbios.org
> Subject: Re: [LinuxBIOS] Build broken?
>
> I understand what you say. It matches what I see in the code. However,
> my
> questions are not addressed, or I didn't understand your explaination.
>
> First, I'm using redhat Linux 9.0, my gcc -v output like this: "gcc
> version
> 3.2.2 20030222 (Red Hat Linux 3.2.2-5)", I hopt it is good enough to
> build
> LinuxBIOS.
>
> Second, tyan/s2891 build generate a section called .rodata.str1.32.
The
> linker script doesn't have anything explict to handle this section. I
> think
> the Linker just patch this section at end of the last  section that
are
> explicitly specified in the Linker script. In tyan/s2891 build, it is
> .id
> section. The .id section is 0x70 bytes below .reset section. The
> .rodata.str1.32 is larger than 0x70 bytes. Therefor, .rodata.str1.32
> will
> overlap with .reset section and cause the build to break. Are you
saying
> my
> compiler caused this issue?
>
> Third, I understand _start must be in the last 64K, are you saying
> objcopy
> would enforce this? To be more specific on my quesiton, when I'm
useing
> ROMCC, my crt0.o is larger than 64K, objcopy would compress certain
> portion
> of crt0.o and make sure _start is in the last 64k?
>
> Thanks
>
> beneo
>
> ----- Original Message ----- 
> From: "Lu, Yinghai" <yinghai.lu at amd.com>
> To: "beneo" <beneo at comcast.net>; "Ronald G Minnich"
<rminnich at lanl.gov>
> Cc: <linuxbios at openbios.org>
> Sent: Thursday, November 10, 2005 2:10 PM
> Subject: Re: [LinuxBIOS] Build broken?
>
>
> > OK, Let me explain that again:
> >
> > Final LinuxBIOS image = VGABIOS ROM + Normal Image + FallBack Image
> >
> > FallBack Image = PayLoad + linuxbios_ram.n2v + linuxbios_rom
> >
> > Linuxbios_rom  = crt0.S + init.o + id + reset_vector
> >
> > Reset_vector is sit on 0xfffffff0, and at the very beginning, reset
> > happen, the ROM only can be accessed in 64K range. So need to make
> sure
> > _start in crt0.S need to stay in last 64 address range.
> >
> > The init.o will include cache_as_ram_auto.c in the fallback
> amd64_main,
> > it will enabled the access 4M flash access.
> >
> > When We were using ROMCC, the crt0.S will be very bigger (it include
> > auto.inc), So for 8 way or 4 way system, It will push out the _start
> out
> > of last 64K.
> >
> > When We are using CAR, the init.o is all the same size for 8way and
2
> > way system. ( because CAR use gcc, and have real stack for
functional
> > call, ROMCC can not have stack because of limited regs)
> >
> > Another problem is if put set ROM_IMAGE_SIZE too big, the current
lds
> > can not curbe crt0.S to stay in last 64K too...
> >
> > So you need to set your ROM_IMAGE_SIZE carefully for FALLBACK image.
> > If it is too small, it could not fit Payload
> > +linuxbios_ram.n2v+linuxbios.rom
> >
> > It it is too big, _start in crt0.S will out of last 64K....
> >
> > Later we could modify .lds to force crt0.S and init.o stay in last
> > 64K....
> >
> > Or change Linuxbios_rom = init.o + crt0.S + id + reset_vector.... (
> need
> > make sure enable_rom in 64K too...)
> >
> > But is not high priority, because crt0.S+init.o for CAR are always
> > small....
> >
> > Other problem is you must use Linux otherthan Redhat and Suse????
> > And you need to upgrade your gcc
> >
> > YH
> >
> > -----Original Message-----
> > From: beneo [mailto:beneo at comcast.net]
> > Sent: Thursday, November 10, 2005 11:54 AM
> > To: Lu, Yinghai; Ronald G Minnich
> > Cc: linuxbios at openbios.org
> > Subject: Re: [LinuxBIOS] Build broken?
> >
> > Thanks. It works on one of issues I have encountered.
> >
> > My immidiate question is why my ROM_IMAGE_SIZE with larger value
> 0x20000
> > won't work, but with 0x16380 would work? If you don't tell me this,
I
> > probably would never be able to figure out.
> >
> > My have another issue, It looks like a bug in target tyan/s2891. I'm
> > trying
> > to build tyan/s2891. No matter what I change, I always get a build
> error
> > like:
> > ---
> > gcc -m32 -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld
> > crt0.o
> > init.o
> > /usr/bin/ld: section .rodata.str1.32 [fffbff80 -> fffc0091] overlaps
> > section
> > .reset [fffbfff0 -> fffbffff]
> > collect2: ld returned 1 exit status
> > make[1]: *** [linuxbios] Error 1
> > ---
> >
> > Then I looked at ldscript file, it included
> > southbridge/nvidia/ck804/id.lds
> > file, which looks like this:
> > ---
> > SECTIONS {
> >         . = (_ROMBASE + ROM_IMAGE_SIZE - 0x80) - (__id_end -
> > __id_start);
> >         .id (.): {
> >                 *(.id)
> >         }
> > }
> > ---
> >
> > There is no linker script would arrange section .rodata.str1.32. I
> guess
> > that just makes linker to patch section .rodata.str1.32 at end of
.id
> > section, which caused the overlap with .reset section.
> >
> > This looks to me is a bug in tyan/s2891. How do I fix this? is that
OK
> > to
> > remove nvidia/ck804/id.lds?
> >
> > thanks
> >
> > beneo
> >
> >
> >
> >
> >
> > ----- Original Message ----- 
> > From: "Lu, Yinghai" <yinghai.lu at AMD.COM>
> > To: "beneo" <beneo at comcast.net>; "Ronald G Minnich"
> <rminnich at lanl.gov>
> > Cc: <linuxbios at openbios.org>
> > Sent: Wednesday, November 09, 2005 7:39 PM
> > Subject: Re: [LinuxBIOS] Build broken?
> >
> >
> > > Please change ROM_IMAGE_SIZE in romimage "fallback" section to
> 0x16380
> > >
> > > YH
> > >
> > >
> > >
> > > -- 
> > > LinuxBIOS mailing list
> > > LinuxBIOS at openbios.org
> > > http://www.openbios.org/mailman/listinfo/linuxbios
> >
> >
> >
> >
> > -- 
> > LinuxBIOS mailing list
> > LinuxBIOS at openbios.org
> > http://www.openbios.org/mailman/listinfo/linuxbios
>
>
>
>
>
>
> -- 
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios






From yinghai.lu at amd.com  Fri Nov 11 02:32:38 2005
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Thu, 10 Nov 2005 17:32:38 -0800
Subject: [LinuxBIOS] Build broken?
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A420309490B@ssvlexmb2.amd.com>

Did you use my new ldscripts.lds?

Also you need to change you FALLBACK_SIZE in MB Option.lb to 0x40000

YH

-----Original Message-----
From: beneo [mailto:beneo at comcast.net] 
Sent: Thursday, November 10, 2005 5:26 PM
To: Lu, Yinghai; Ronald G Minnich
Cc: linuxbios at openbios.org
Subject: Re: [LinuxBIOS] Build broken?

thanks for the help, otherwise, I probably would spend days to figure
out. I
create a cace_as_ram.lds in my directory which handles the section not
in
standard lds, I can build now.

Only mystery still remain is why when I have ROM_IMAGE_SIZE set to
0x20000
in fallback, it won't build, but set to smaller 0x16380, it builds. It
seems
caused objcopy to generate a different size of linuxbios.strip file. I
think
objcopy should have nothing to do with it. but something went wrong
before
that. It should be a bug in the code, I just don't know what it is.

Thanks

beneo



----- Original Message ----- 
From: "Lu, Yinghai" <yinghai.lu at AMD.COM>
To: "beneo" <beneo at comcast.net>; "Ronald G Minnich" <rminnich at lanl.gov>
Cc: <linuxbios at openbios.org>
Sent: Thursday, November 10, 2005 3:29 PM
Subject: Re: [LinuxBIOS] Build broken?


> You can change section name in arch/i386/Config.lb if you have strange
> compiler that produce werid section name.
>
> YH
>
> -----Original Message-----
> From: beneo [mailto:beneo at comcast.net]
> Sent: Thursday, November 10, 2005 3:22 PM
> To: Lu, Yinghai; Ronald G Minnich
> Cc: linuxbios at openbios.org
> Subject: Re: [LinuxBIOS] Build broken?
>
> Is gcc 3.4 a requirement?
>
> If not, I would save the trouble and stay with 3.2.2. I didn't
encounter
> any
> trouble building LinuxBIOS using this version until now. In another
> word,
> are you absulutely sure the issue I have stated is caused by gcc 3.2.2
>
> Thanks
>
> beneo
>
> ----- Original Message ----- 
> From: "Lu, Yinghai" <yinghai.lu at AMD.COM>
> To: "beneo" <beneo at comcast.net>; "Ronald G Minnich"
<rminnich at lanl.gov>
> Cc: <linuxbios at openbios.org>
> Sent: Thursday, November 10, 2005 3:17 PM
> Subject: RE: [LinuxBIOS] Build broken?
>
>
> Why not use gcc 3.4....?
>
> YH
>
> -----Original Message-----
> From: beneo [mailto:beneo at comcast.net]
> Sent: Thursday, November 10, 2005 3:14 PM
> To: Lu, Yinghai; Ronald G Minnich
> Cc: linuxbios at openbios.org
> Subject: Re: [LinuxBIOS] Build broken?
>
> I understand what you say. It matches what I see in the code. However,
> my
> questions are not addressed, or I didn't understand your explaination.
>
> First, I'm using redhat Linux 9.0, my gcc -v output like this: "gcc
> version
> 3.2.2 20030222 (Red Hat Linux 3.2.2-5)", I hopt it is good enough to
> build
> LinuxBIOS.
>
> Second, tyan/s2891 build generate a section called .rodata.str1.32.
The
> linker script doesn't have anything explict to handle this section. I
> think
> the Linker just patch this section at end of the last  section that
are
> explicitly specified in the Linker script. In tyan/s2891 build, it is
> .id
> section. The .id section is 0x70 bytes below .reset section. The
> .rodata.str1.32 is larger than 0x70 bytes. Therefor, .rodata.str1.32
> will
> overlap with .reset section and cause the build to break. Are you
saying
> my
> compiler caused this issue?
>
> Third, I understand _start must be in the last 64K, are you saying
> objcopy
> would enforce this? To be more specific on my quesiton, when I'm
useing
> ROMCC, my crt0.o is larger than 64K, objcopy would compress certain
> portion
> of crt0.o and make sure _start is in the last 64k?
>
> Thanks
>
> beneo
>
> ----- Original Message ----- 
> From: "Lu, Yinghai" <yinghai.lu at amd.com>
> To: "beneo" <beneo at comcast.net>; "Ronald G Minnich"
<rminnich at lanl.gov>
> Cc: <linuxbios at openbios.org>
> Sent: Thursday, November 10, 2005 2:10 PM
> Subject: Re: [LinuxBIOS] Build broken?
>
>
> > OK, Let me explain that again:
> >
> > Final LinuxBIOS image = VGABIOS ROM + Normal Image + FallBack Image
> >
> > FallBack Image = PayLoad + linuxbios_ram.n2v + linuxbios_rom
> >
> > Linuxbios_rom  = crt0.S + init.o + id + reset_vector
> >
> > Reset_vector is sit on 0xfffffff0, and at the very beginning, reset
> > happen, the ROM only can be accessed in 64K range. So need to make
> sure
> > _start in crt0.S need to stay in last 64 address range.
> >
> > The init.o will include cache_as_ram_auto.c in the fallback
> amd64_main,
> > it will enabled the access 4M flash access.
> >
> > When We were using ROMCC, the crt0.S will be very bigger (it include
> > auto.inc), So for 8 way or 4 way system, It will push out the _start
> out
> > of last 64K.
> >
> > When We are using CAR, the init.o is all the same size for 8way and
2
> > way system. ( because CAR use gcc, and have real stack for
functional
> > call, ROMCC can not have stack because of limited regs)
> >
> > Another problem is if put set ROM_IMAGE_SIZE too big, the current
lds
> > can not curbe crt0.S to stay in last 64K too...
> >
> > So you need to set your ROM_IMAGE_SIZE carefully for FALLBACK image.
> > If it is too small, it could not fit Payload
> > +linuxbios_ram.n2v+linuxbios.rom
> >
> > It it is too big, _start in crt0.S will out of last 64K....
> >
> > Later we could modify .lds to force crt0.S and init.o stay in last
> > 64K....
> >
> > Or change Linuxbios_rom = init.o + crt0.S + id + reset_vector.... (
> need
> > make sure enable_rom in 64K too...)
> >
> > But is not high priority, because crt0.S+init.o for CAR are always
> > small....
> >
> > Other problem is you must use Linux otherthan Redhat and Suse????
> > And you need to upgrade your gcc
> >
> > YH
> >
> > -----Original Message-----
> > From: beneo [mailto:beneo at comcast.net]
> > Sent: Thursday, November 10, 2005 11:54 AM
> > To: Lu, Yinghai; Ronald G Minnich
> > Cc: linuxbios at openbios.org
> > Subject: Re: [LinuxBIOS] Build broken?
> >
> > Thanks. It works on one of issues I have encountered.
> >
> > My immidiate question is why my ROM_IMAGE_SIZE with larger value
> 0x20000
> > won't work, but with 0x16380 would work? If you don't tell me this,
I
> > probably would never be able to figure out.
> >
> > My have another issue, It looks like a bug in target tyan/s2891. I'm
> > trying
> > to build tyan/s2891. No matter what I change, I always get a build
> error
> > like:
> > ---
> > gcc -m32 -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld
> > crt0.o
> > init.o
> > /usr/bin/ld: section .rodata.str1.32 [fffbff80 -> fffc0091] overlaps
> > section
> > .reset [fffbfff0 -> fffbffff]
> > collect2: ld returned 1 exit status
> > make[1]: *** [linuxbios] Error 1
> > ---
> >
> > Then I looked at ldscript file, it included
> > southbridge/nvidia/ck804/id.lds
> > file, which looks like this:
> > ---
> > SECTIONS {
> >         . = (_ROMBASE + ROM_IMAGE_SIZE - 0x80) - (__id_end -
> > __id_start);
> >         .id (.): {
> >                 *(.id)
> >         }
> > }
> > ---
> >
> > There is no linker script would arrange section .rodata.str1.32. I
> guess
> > that just makes linker to patch section .rodata.str1.32 at end of
.id
> > section, which caused the overlap with .reset section.
> >
> > This looks to me is a bug in tyan/s2891. How do I fix this? is that
OK
> > to
> > remove nvidia/ck804/id.lds?
> >
> > thanks
> >
> > beneo
> >
> >
> >
> >
> >
> > ----- Original Message ----- 
> > From: "Lu, Yinghai" <yinghai.lu at AMD.COM>
> > To: "beneo" <beneo at comcast.net>; "Ronald G Minnich"
> <rminnich at lanl.gov>
> > Cc: <linuxbios at openbios.org>
> > Sent: Wednesday, November 09, 2005 7:39 PM
> > Subject: Re: [LinuxBIOS] Build broken?
> >
> >
> > > Please change ROM_IMAGE_SIZE in romimage "fallback" section to
> 0x16380
> > >
> > > YH
> > >
> > >
> > >
> > > -- 
> > > LinuxBIOS mailing list
> > > LinuxBIOS at openbios.org
> > > http://www.openbios.org/mailman/listinfo/linuxbios
> >
> >
> >
> >
> > -- 
> > LinuxBIOS mailing list
> > LinuxBIOS at openbios.org
> > http://www.openbios.org/mailman/listinfo/linuxbios
>
>
>
>
>
>
> -- 
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios






From rminnich at lanl.gov  Fri Nov 11 03:51:44 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 10 Nov 2005 19:51:44 -0700
Subject: [LinuxBIOS] Build broken?
In-Reply-To: <008c01c5e64d$9467ad60$131814ac@trans.corp>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4201E06233@ssvlexmb2.amd.com>
	<008c01c5e64d$9467ad60$131814ac@trans.corp>
Message-ID: <43740740.2000005@lanl.gov>

beneo wrote:
> Is gcc 3.4 a requirement?
> 
> If not, I would save the trouble and stay with 3.2.2. I didn't encounter any
> trouble building LinuxBIOS using this version until now. In another word,
> are you absulutely sure the issue I have stated is caused by gcc 3.2.2

gcc keeps changing the names of types of segments we use. I don't recall 
the rodata.str1.32 segment before, but my memory is hazy.

So, no, I don't *think* 3.4 is a requirement -- we built for a long time 
with 2.95, after all -- but at the same time, 3.4 is known to work ...

ro




From talbotx at comcast.net  Fri Nov 11 08:25:59 2005
From: talbotx at comcast.net (Adam Talbot)
Date: Thu, 10 Nov 2005 23:25:59 -0800
Subject: [LinuxBIOS] DOC vs CF
Message-ID: <43744787.3030608@comcast.net>

Can any one give me a quick run down and the Up/Downs of using a DOC or 
CF as the primary boot device in a Linux BIOS system. I know there are 
both based on nand technology, and I know that the CF is on the ATA 
bus... I know that both have a limited number of writes, but that is 
where i run out of info.  What else is there, why would some one use a 
CF or DOC over the other?
-Adam



From okajima at digitalinfra.co.jp  Fri Nov 11 09:26:16 2005
From: okajima at digitalinfra.co.jp (Jun OKAJIMA)
Date: Fri, 11 Nov 2005 17:26:16 +0900
Subject: [LinuxBIOS] DOC vs CF
In-Reply-To: <43744787.3030608@comcast.net>
References: <43744787.3030608@comcast.net>
Message-ID: <200511110826.AA00460@bbb-jz5c7z9hn9y.digitalinfra.co.jp>


DOC is slow! and needs special H/W.
The only merit of DOC is easyness of implementation for hardware designer,
and probably cost when you buy it with very large quantity.
In short, DOC is out of scope unless you are a h/w designer of embedded systems.

                           --- Okajima, Jun. Tokyo, Japan.


>Can any one give me a quick run down and the Up/Downs of using a DOC or 
>CF as the primary boot device in a Linux BIOS system. I know there are 
>both based on nand technology, and I know that the CF is on the ATA 
>bus... I know that both have a limited number of writes, but that is 
>where i run out of info.  What else is there, why would some one use a 
>CF or DOC over the other?
>-Adam
>
>-- 
>LinuxBIOS mailing list
>LinuxBIOS at openbios.org
>http://www.openbios.org/mailman/listinfo/linuxbios
>



From a.borisov at tesv.tmb.ru  Fri Nov 11 09:55:03 2005
From: a.borisov at tesv.tmb.ru (Anton Borisov)
Date: Fri, 11 Nov 2005 11:55:03 +0300
Subject: [LinuxBIOS] Problems with ADLO
Message-ID: <20051111115503.476fdd6d.a.borisov@tesv.tmb.ru>

Hello.
	I have ADLO shipped with LinuxBIOS v1. My working box has
bcc: version 0.16.14
gcc version 3.3.4
as86 version: 0.16.15

	I tried to compile bochs rom like this:

# cd ~/ADLO/bochs/bios
# make distclean
# make 

gcc -E rombios.c > _rombios_.c
rombios.c:2662:50: pasting "(" and ""ata_cmd_data_in : read error\n"" does not give a valid preprocessing token
rombios.c:2665:84: pasting "(" and ""ata_cmd_data_in : DRQ not set (status %02x)\n"" does not give a valid preprocessing token

	rombios.c dated 01 May, 2005, size 276323 (freebios--devel--1.0--base-0.tar.bz2).

Anyone succeded to compile ADLO recently?

-- 
Sincerely, Anton Borisov



From smithbone at gmail.com  Fri Nov 11 15:38:29 2005
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 11 Nov 2005 08:38:29 -0600
Subject: [LinuxBIOS] Problems with ADLO
In-Reply-To: <20051111115503.476fdd6d.a.borisov@tesv.tmb.ru>
References: <20051111115503.476fdd6d.a.borisov@tesv.tmb.ru>
Message-ID: <8a0c36780511110638h360e6578sfe31f958178d6bf6@mail.gmail.com>

> gcc -E rombios.c > _rombios_.c
> rombios.c:2662:50: pasting "(" and ""ata_cmd_data_in : read error\n"" does not give a valid preprocessing token
> rombios.c:2665:84: pasting "(" and ""ata_cmd_data_in : DRQ not set (status %02x)\n"" does not give a valid preprocessing token
>
>         rombios.c dated 01 May, 2005, size 276323 (freebios--devel--1.0--base-0.tar.bz2).
>
> Anyone succeded to compile ADLO recently?

This has been a problem for a while.  I just forgot to submit a patch.

The variable arguments in a macro handleing changed in gcc 3.x.

Either use gcc-2.95 or change all occurances of

BX_DEBUG(##a)
to
BX_DEBUG(a)

--
Richard A. Smith



From beneo at comcast.net  Fri Nov 11 18:56:36 2005
From: beneo at comcast.net (Beneo)
Date: Fri, 11 Nov 2005 09:56:36 -0800
Subject: [LinuxBIOS] Build broken?
References: <6F7DA19D05F3CF40B890C7CA2DB13A4201E06233@ssvlexmb2.amd.com>
	<008c01c5e64d$9467ad60$131814ac@trans.corp>
	<43740740.2000005@lanl.gov>
Message-ID: <000401c5e6e9$450d11a0$812614ac@trans.corp>

maybe should just use wildcard to include all sections except the ones
needed to be discarded? as far as I can tell, all the sections in .o files
are go into same section in output rom file. Then just let GCC to change
section name as it wants to.

beneo

----- Original Message ----- 
From: "Ronald G Minnich" <rminnich at lanl.gov>
To: "beneo" <beneo at comcast.net>
Cc: "Lu, Yinghai" <yinghai.lu at AMD.COM>; <linuxbios at openbios.org>
Sent: Thursday, November 10, 2005 6:51 PM
Subject: Re: [LinuxBIOS] Build broken?


> beneo wrote:
> > Is gcc 3.4 a requirement?
> >
> > If not, I would save the trouble and stay with 3.2.2. I didn't encounter
any
> > trouble building LinuxBIOS using this version until now. In another
word,
> > are you absulutely sure the issue I have stated is caused by gcc 3.2.2
>
> gcc keeps changing the names of types of segments we use. I don't recall
> the rodata.str1.32 segment before, but my memory is hazy.
>
> So, no, I don't *think* 3.4 is a requirement -- we built for a long time
> with 2.95, after all -- but at the same time, 3.4 is known to work ...
>
> ro
>




From rminnich at lanl.gov  Fri Nov 11 20:03:43 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Fri, 11 Nov 2005 12:03:43 -0700
Subject: [LinuxBIOS] Build broken?
In-Reply-To: <000401c5e6e9$450d11a0$812614ac@trans.corp>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4201E06233@ssvlexmb2.amd.com>
	<008c01c5e64d$9467ad60$131814ac@trans.corp>
	<43740740.2000005@lanl.gov>
	<000401c5e6e9$450d11a0$812614ac@trans.corp>
Message-ID: <4374EB0F.5050101@lanl.gov>

Beneo wrote:
> maybe should just use wildcard to include all sections except the ones
> needed to be discarded? as far as I can tell, all the sections in .o files
> are go into same section in output rom file. Then just let GCC to change
> section name as it wants to.

there is some wildcarding, but the gnu guys create new, unmatched 
segments on occasion. This has bit me a time or two.

ron



From yinghai.lu at amd.com  Fri Nov 11 21:46:08 2005
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Fri, 11 Nov 2005 12:46:08 -0800
Subject: [LinuxBIOS] results in romcc
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094915@ssvlexmb2.amd.com>

Stephan, 

Can you remove util/romcc/results/*? 

YH




From ebiederman at lnxi.com  Fri Nov 11 22:31:26 2005
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri, 11 Nov 2005 14:31:26 -0700
Subject: [LinuxBIOS] results in romcc
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094915@ssvlexmb2.amd.com>
	(Yinghai Lu's message of "Fri, 11 Nov 2005 12:46:08 -0800")
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094915@ssvlexmb2.amd.com>
Message-ID: <m3d5l650sx.fsf@maxwell.lnxi.com>

"Lu, Yinghai" <yinghai.lu at amd.com> writes:

> Stephan, 
>
> Can you remove util/romcc/results/*? 

You want to remove the expected output of the romcc regression tests?

Eric



From yinghai.lu at amd.com  Fri Nov 11 22:38:15 2005
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Fri, 11 Nov 2005 13:38:15 -0800
Subject: [LinuxBIOS] results in romcc
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094916@ssvlexmb2.amd.com>

Any use? For comparison?

YH

-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Friday, November 11, 2005 1:31 PM
To: Lu, Yinghai
Cc: Ronald G Minnich; Stefan Reinauer; linuxbios at openbios.org
Subject: Re: [LinuxBIOS] results in romcc

"Lu, Yinghai" <yinghai.lu at amd.com> writes:

> Stephan, 
>
> Can you remove util/romcc/results/*? 

You want to remove the expected output of the romcc regression tests?

Eric





From yinghai.lu at amd.com  Fri Nov 11 23:03:50 2005
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Fri, 11 Nov 2005 14:03:50 -0800
Subject: [LinuxBIOS] def addcpupath
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094917@ssvlexmb2.amd.com>

Why is there two "def addcpupath( " in util/newconfig/config.g?

YH





From stepan at openbios.org  Sat Nov 12 02:09:21 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Sat, 12 Nov 2005 02:09:21 +0100
Subject: [LinuxBIOS] results in romcc
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094916@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094916@ssvlexmb2.amd.com>
Message-ID: <20051112010921.GC10381@openbios.org>

* Lu, Yinghai <yinghai.lu at amd.com> [051111 22:38]:
> Any use? For comparison?
> 
> YH

Is it used for any regression testing? I can remove it if it is unused,
but I'd prefer to have such cleanups done after the tree is in shape
again.

Stefan





From ebiederman at lnxi.com  Sat Nov 12 04:45:32 2005
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri, 11 Nov 2005 20:45:32 -0700
Subject: [LinuxBIOS] results in romcc
In-Reply-To: <20051112010921.GC10381@openbios.org> (Stefan Reinauer's
	message of "Sat, 12 Nov 2005 02:09:21 +0100")
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094916@ssvlexmb2.amd.com>
	<20051112010921.GC10381@openbios.org>
Message-ID: <m34q6ifs0z.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at openbios.org> writes:

> * Lu, Yinghai <yinghai.lu at amd.com> [051111 22:38]:
>> Any use? For comparison?
>> 
>> YH
>
> Is it used for any regression testing? I can remove it if it is unused,
> but I'd prefer to have such cleanups done after the tree is in shape
> again.

Yes.  That is exactly the purpose.  There should be a shell script
test.sh that performs the tests.

Eric



From stepan at openbios.org  Sat Nov 12 16:43:50 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Sat, 12 Nov 2005 16:43:50 +0100
Subject: [LinuxBIOS] flash_and_burn fixes.
Message-ID: <20051112154350.GA26503@openbios.org>

Hi,

flash_and_burn does not compile in gcc 4 anymore since it comes
with -Werror. This makes sense since it is touching a very sensitive
part of a system :-)

Since gcc 4 warns a lot more about signed/unsigned pointer confusion
I changed major parts of flash_and_burn to use unsigned pointers only.
We are coping with data, so signedness is not interesting in the code.
In fact it might rather hurt.

I'll apply the patch to the repository shortly, when someone signs it
off. 

Other questions: 
 - Can we drop flash_on? The code seems included in flash_rom and it
   only works on old sis stuff anyways. We will not drop functionality 
   by dropping this extra binary.

 - Should we rename the utility to flash_and_burn or should we rename
   the directory to flash_rom? There's a lot of confusion since the
   utility and it's location in the source tree have different names.

Stefan


-------------- next part --------------
Index: LinuxBIOSv2/util/flash_and_burn/pm49fl004.c
===================================================================
--- LinuxBIOSv2/util/flash_and_burn/pm49fl004.c	(revision 2084)
+++ LinuxBIOSv2/util/flash_and_burn/pm49fl004.c	(working copy)
@@ -34,7 +34,7 @@
 	int i;
 	int total_size = flash->total_size * 1024, page_size =
 		flash->page_size;
-	volatile char *bios = flash->virt_addr;
+	volatile unsigned char *bios = flash->virt_addr;
 	
 	printf("Programming Page: ");
 	for (i = 0; i < total_size / page_size; i++) {
Index: LinuxBIOSv2/util/flash_and_burn/sst39sf020.c
===================================================================
--- LinuxBIOSv2/util/flash_and_burn/sst39sf020.c	(revision 2084)
+++ LinuxBIOSv2/util/flash_and_burn/sst39sf020.c	(working copy)
@@ -35,7 +35,7 @@
 #define AUTO_PG_ERASE1		0x20
 #define AUTO_PG_ERASE2		0xD0
 
-static __inline__ int erase_sector_39sf020(volatile char *bios,
+static __inline__ int erase_sector_39sf020(volatile unsigned char *bios,
 					   unsigned long address)
 {
 	*bios = AUTO_PG_ERASE1;
@@ -52,7 +52,7 @@
 	int i;
 	int total_size = flash->total_size * 1024, page_size =
 		flash->page_size;
-	volatile char *bios = flash->virt_addr;
+	volatile unsigned char *bios = flash->virt_addr;
 
 	erase_chip_jedec(flash);
 
Index: LinuxBIOSv2/util/flash_and_burn/flash.h
===================================================================
--- LinuxBIOSv2/util/flash_and_burn/flash.h	(revision 2084)
+++ LinuxBIOSv2/util/flash_and_burn/flash.h	(working copy)
@@ -9,7 +9,7 @@
 	int manufacture_id;
 	int model_id;
 
-	volatile char *virt_addr;
+	volatile unsigned char *virt_addr;
 	int total_size;
 	int page_size;
 
@@ -19,7 +19,7 @@
 	int (*read) (struct flashchip * flash, unsigned char *buf);
 
 	int fd_mem;
-	volatile char *virt_addr_2;
+	volatile unsigned char *virt_addr_2;
 };
 
 #define AMD_ID            0x01
Index: LinuxBIOSv2/util/flash_and_burn/jedec.h
===================================================================
--- LinuxBIOSv2/util/flash_and_burn/jedec.h	(revision 2084)
+++ LinuxBIOSv2/util/flash_and_burn/jedec.h	(working copy)
@@ -12,7 +12,7 @@
 			      volatile unsigned char *dst,
 			      unsigned int page_size);
 
-extern __inline__ void toggle_ready_jedec(volatile char *dst)
+extern __inline__ void toggle_ready_jedec(volatile unsigned char *dst)
 {
 	unsigned int i = 0;
 	char tmp1, tmp2;
@@ -28,10 +28,10 @@
 	}
 }
 
-extern __inline__ void data_polling_jedec(volatile char *dst, char data)
+extern __inline__ void data_polling_jedec(volatile unsigned char *dst, unsigned char data)
 {
 	unsigned int i = 0;
-	char tmp;
+	unsigned char tmp;
 
 	data &= 0x80;
 
@@ -43,23 +43,23 @@
 	}
 }
 
-extern __inline__ void unprotect_jedec(volatile char *bios)
+extern __inline__ void unprotect_jedec(volatile unsigned char *bios)
 {
-	*(volatile char *) (bios + 0x5555) = 0xAA;
-	*(volatile char *) (bios + 0x2AAA) = 0x55;
-	*(volatile char *) (bios + 0x5555) = 0x80;
-	*(volatile char *) (bios + 0x5555) = 0xAA;
-	*(volatile char *) (bios + 0x2AAA) = 0x55;
-	*(volatile char *) (bios + 0x5555) = 0x20;
+	*(volatile unsigned char *) (bios + 0x5555) = 0xAA;
+	*(volatile unsigned char *) (bios + 0x2AAA) = 0x55;
+	*(volatile unsigned char *) (bios + 0x5555) = 0x80;
+	*(volatile unsigned char *) (bios + 0x5555) = 0xAA;
+	*(volatile unsigned char *) (bios + 0x2AAA) = 0x55;
+	*(volatile unsigned char *) (bios + 0x5555) = 0x20;
 
 	usleep(200);
 }
 
-extern __inline__ void protect_jedec(volatile char *bios)
+extern __inline__ void protect_jedec(volatile unsigned char *bios)
 {
-	*(volatile char *) (bios + 0x5555) = 0xAA;
-	*(volatile char *) (bios + 0x2AAA) = 0x55;
-	*(volatile char *) (bios + 0x5555) = 0xA0;
+	*(volatile unsigned char *) (bios + 0x5555) = 0xAA;
+	*(volatile unsigned char *) (bios + 0x2AAA) = 0x55;
+	*(volatile unsigned char *) (bios + 0x5555) = 0xA0;
 
 	usleep(200);
 }
Index: LinuxBIOSv2/util/flash_and_burn/sst28sf040.c
===================================================================
--- LinuxBIOSv2/util/flash_and_burn/sst28sf040.c	(revision 2084)
+++ LinuxBIOSv2/util/flash_and_burn/sst28sf040.c	(working copy)
@@ -36,7 +36,7 @@
 #define RESET			0xFF
 #define READ_ID			0x90
 
-static __inline__ void protect_28sf040(volatile char *bios)
+static __inline__ void protect_28sf040(volatile unsigned char *bios)
 {
 	/* ask compiler not to optimize this */
 	volatile unsigned char tmp;
@@ -50,7 +50,7 @@
 	tmp = *(volatile unsigned char *) (bios + 0x040A);
 }
 
-static __inline__ void unprotect_28sf040(volatile char *bios)
+static __inline__ void unprotect_28sf040(volatile unsigned char *bios)
 {
 	/* ask compiler not to optimize this */
 	volatile unsigned char tmp;
@@ -64,7 +64,7 @@
 	tmp = *(volatile unsigned char *) (bios + 0x041A);
 }
 
-static __inline__ int erase_sector_28sf040(volatile char *bios,
+static __inline__ int erase_sector_28sf040(volatile unsigned char *bios,
 					   unsigned long address)
 {
 	*bios = AUTO_PG_ERASE1;
@@ -76,7 +76,7 @@
 	return (0);
 }
 
-static __inline__ int write_sector_28sf040(volatile char *bios,
+static __inline__ int write_sector_28sf040(volatile unsigned char *bios,
 					   unsigned char *src,
 					   volatile unsigned char *dst,
 					   unsigned int page_size)
@@ -103,7 +103,7 @@
 
 int probe_28sf040(struct flashchip *flash)
 {
-	volatile char *bios = flash->virt_addr;
+	volatile unsigned char *bios = flash->virt_addr;
 	unsigned char id1, id2, tmp;
 
 	/* save the value at the beginning of the Flash */
@@ -132,7 +132,7 @@
 
 int erase_28sf040(struct flashchip *flash)
 {
-	volatile char *bios = flash->virt_addr;
+	volatile unsigned char *bios = flash->virt_addr;
 
 	unprotect_28sf040(bios);
 	*bios = CHIP_ERASE;
@@ -150,7 +150,7 @@
 	int i;
 	int total_size = flash->total_size * 1024, page_size =
 	    flash->page_size;
-	volatile char *bios = flash->virt_addr;
+	volatile unsigned char *bios = flash->virt_addr;
 
 	unprotect_28sf040(bios);
 
Index: LinuxBIOSv2/util/flash_and_burn/w49f002u.c
===================================================================
--- LinuxBIOSv2/util/flash_and_burn/w49f002u.c	(revision 2084)
+++ LinuxBIOSv2/util/flash_and_burn/w49f002u.c	(working copy)
@@ -37,7 +37,7 @@
 	int i;
 	int total_size = flash->total_size * 1024, page_size =
 		flash->page_size;
-	volatile char *bios = flash->virt_addr;
+	volatile unsigned char *bios = flash->virt_addr;
 
 	erase_chip_jedec(flash);
 
Index: LinuxBIOSv2/util/flash_and_burn/am29f040b.c
===================================================================
--- LinuxBIOSv2/util/flash_and_burn/am29f040b.c	(revision 2084)
+++ LinuxBIOSv2/util/flash_and_burn/am29f040b.c	(working copy)
@@ -28,7 +28,7 @@
 #include "flash.h"
 #include "jedec.h"
 
-static __inline__ int erase_sector_29f040b(volatile char *bios,
+static __inline__ int erase_sector_29f040b(volatile unsigned char *bios,
 					   unsigned long address)
 {
 	*(bios + 0x555) = 0xAA;
@@ -46,7 +46,7 @@
 	return (0);
 }
 
-static __inline__ int write_sector_29f040b(volatile char *bios,
+static __inline__ int write_sector_29f040b(volatile unsigned char *bios,
 					   unsigned char *src,
 					   volatile unsigned char *dst,
 					   unsigned int page_size)
@@ -116,7 +116,7 @@
 	int i;
 	int total_size = flash->total_size * 1024, page_size =
 	    flash->page_size;
-	volatile char *bios = flash->virt_addr;
+	volatile unsigned char *bios = flash->virt_addr;
 
 	printf("Programming Page: ");
 	for (i = 0; i < total_size / page_size; i++) {
Index: LinuxBIOSv2/util/flash_and_burn/flash_rom.c
===================================================================
--- LinuxBIOSv2/util/flash_and_burn/flash_rom.c	(revision 2084)
+++ LinuxBIOSv2/util/flash_and_burn/flash_rom.c	(working copy)
@@ -103,7 +103,7 @@
 struct flashchip *probe_flash(struct flashchip *flash)
 {
 	int fd_mem;
-	volatile char *bios;
+	volatile unsigned char *bios;
 	unsigned long size;
 
 	if ((fd_mem = open("/dev/mem", O_RDWR)) < 0) {
@@ -146,11 +146,11 @@
 	return NULL;
 }
 
-int verify_flash(struct flashchip *flash, char *buf, int verbose)
+int verify_flash(struct flashchip *flash, unsigned char *buf, int verbose)
 {
 	int i;
 	int total_size = flash->total_size * 1024;
-	volatile char *bios = flash->virt_addr;
+	volatile unsigned char *bios = flash->virt_addr;
 
 	printf("Verifying address: ");
 	for (i = 0; i < total_size; i++) {
@@ -189,7 +189,7 @@
 
 int main(int argc, char *argv[])
 {
-	char *buf;
+	unsigned char *buf;
 	unsigned long size;
 	FILE *image;
 	struct flashchip *flash;
@@ -275,7 +275,7 @@
 		return 0;
 	}
 	size = flash->total_size * 1024;
-	buf = (char *) calloc(size, sizeof(char));
+	buf = (unsigned char *) calloc(size, sizeof(char));
 
 	if (erase_it) {
 		printf("Erasing flash chip\n");
Index: LinuxBIOSv2/util/flash_and_burn/msys_doc.c
===================================================================
--- LinuxBIOSv2/util/flash_and_burn/msys_doc.c	(revision 2084)
+++ LinuxBIOSv2/util/flash_and_burn/msys_doc.c	(working copy)
@@ -30,11 +30,11 @@
 
 
 
-static int doc_wait(volatile char *bios, int timeout);
-static unsigned char doc_read_chipid(volatile char *bios);
-static unsigned char doc_read_docstatus(volatile char *bios);
-static unsigned char doc_read_cdsncontrol(volatile char *bios);
-static void doc_write_cdsncontrol(volatile char *bios, unsigned char data);
+static int doc_wait(volatile unsigned char *bios, int timeout);
+static unsigned char doc_read_chipid(volatile unsigned char *bios);
+static unsigned char doc_read_docstatus(volatile unsigned char *bios);
+static unsigned char doc_read_cdsncontrol(volatile unsigned char *bios);
+static void doc_write_cdsncontrol(volatile unsigned char *bios, unsigned char data);
 
 
 
@@ -42,7 +42,7 @@
 
 int probe_md2802(struct flashchip *flash)
 {
-	volatile char *bios = flash->virt_addr;
+	volatile unsigned char *bios = flash->virt_addr;
 	unsigned char chipid;
 #ifndef MSYSTEMS_DOC_NO_55AA_CHECKING
 	unsigned char id_0x55, id_0xAA;
@@ -165,16 +165,16 @@
 
 int erase_md2802(struct flashchip *flash)
 {
-	volatile char *bios = flash->virt_addr;
+	volatile unsigned char *bios = flash->virt_addr;
 
 	return (1);
-	*(volatile char *) (bios + 0x5555) = 0xAA;
-	*(volatile char *) (bios + 0x2AAA) = 0x55;
-	*(volatile char *) (bios + 0x5555) = 0x80;
+	*(volatile unsigned char *) (bios + 0x5555) = 0xAA;
+	*(volatile unsigned char *) (bios + 0x2AAA) = 0x55;
+	*(volatile unsigned char *) (bios + 0x5555) = 0x80;
 
-	*(volatile char *) (bios + 0x5555) = 0xAA;
-	*(volatile char *) (bios + 0x2AAA) = 0x55;
-	*(volatile char *) (bios + 0x5555) = 0x10;
+	*(volatile unsigned char *) (bios + 0x5555) = 0xAA;
+	*(volatile unsigned char *) (bios + 0x2AAA) = 0x55;
+	*(volatile unsigned char *) (bios + 0x5555) = 0x10;
 }				/* int erase_md2802(struct flashchip *flash) */
 
 
@@ -216,7 +216,7 @@
 		0: ready
 		-1: timeout expired
 */
-static int doc_wait(volatile char *bios, int timeout)
+static int doc_wait(volatile unsigned char *bios, int timeout)
 {
 	int i = 20;
 
@@ -239,7 +239,7 @@
 
 
 
-static unsigned char doc_read_docstatus(volatile char *bios)
+static unsigned char doc_read_docstatus(volatile unsigned char *bios)
 {
 	doc_read(bios, CDSNSlowIO);
 	doc_read_2nop(bios);
@@ -249,7 +249,7 @@
 
 
 
-static unsigned char doc_read_chipid(volatile char *bios)
+static unsigned char doc_read_chipid(volatile unsigned char *bios)
 {
 	doc_read(bios, CDSNSlowIO);
 	doc_read_2nop(bios);
@@ -259,7 +259,7 @@
 
 
 
-static unsigned char doc_read_cdsncontrol(volatile char *bios)
+static unsigned char doc_read_cdsncontrol(volatile unsigned char *bios)
 {
 	unsigned char value;
 
@@ -275,7 +275,7 @@
 
 
 
-static void doc_write_cdsncontrol(volatile char *bios, unsigned char data)
+static void doc_write_cdsncontrol(volatile unsigned char *bios, unsigned char data)
 {
 	doc_write(data, bios, _CDSNControl);
 	doc_read_4nop(bios);
Index: LinuxBIOSv2/util/flash_and_burn/82802ab.c
===================================================================
--- LinuxBIOSv2/util/flash_and_burn/82802ab.c	(revision 2084)
+++ LinuxBIOSv2/util/flash_and_burn/82802ab.c	(working copy)
@@ -161,7 +161,7 @@
 	return (0);
 }
 
-void write_page_82802ab(volatile char *bios, char *src, volatile char *dst,
+void write_page_82802ab(volatile unsigned char *bios, unsigned char *src, volatile unsigned char *dst,
 			int page_size)
 {
 	int i;
Index: LinuxBIOSv2/util/flash_and_burn/m29f400bt.c
===================================================================
--- LinuxBIOSv2/util/flash_and_burn/m29f400bt.c	(revision 2084)
+++ LinuxBIOSv2/util/flash_and_burn/m29f400bt.c	(working copy)
@@ -29,21 +29,21 @@
 
 int probe_m29f400bt(struct flashchip *flash)
 {
-	volatile char *bios = flash->virt_addr;
+	volatile unsigned char *bios = flash->virt_addr;
 	unsigned char id1, id2;
 
-	*(volatile char *) (bios + 0xAAA) = 0xAA;
-	*(volatile char *) (bios + 0x555) = 0x55;
-	*(volatile char *) (bios + 0xAAA) = 0x90;
+	*(volatile unsigned char *) (bios + 0xAAA) = 0xAA;
+	*(volatile unsigned char *) (bios + 0x555) = 0x55;
+	*(volatile unsigned char *) (bios + 0xAAA) = 0x90;
 
 	myusec_delay(10);
 
 	id1 = *(volatile unsigned char *) bios;
 	id2 = *(volatile unsigned char *) (bios + 0x02);
 
-	*(volatile char *) (bios + 0xAAA) = 0xAA;
-	*(volatile char *) (bios + 0x555) = 0x55;
-	*(volatile char *) (bios + 0xAAA) = 0xF0;
+	*(volatile unsigned char *) (bios + 0xAAA) = 0xAA;
+	*(volatile unsigned char *) (bios + 0x555) = 0x55;
+	*(volatile unsigned char *) (bios + 0xAAA) = 0xF0;
 
 	myusec_delay(10);
 
@@ -58,15 +58,15 @@
 
 int erase_m29f400bt(struct flashchip *flash)
 {
-	volatile char *bios = flash->virt_addr;
+	volatile unsigned char *bios = flash->virt_addr;
 
-	*(volatile char *) (bios + 0xAAA) = 0xAA;
-	*(volatile char *) (bios + 0x555) = 0x55;
-	*(volatile char *) (bios + 0xAAA) = 0x80;
+	*(volatile unsigned char *) (bios + 0xAAA) = 0xAA;
+	*(volatile unsigned char *) (bios + 0x555) = 0x55;
+	*(volatile unsigned char *) (bios + 0xAAA) = 0x80;
 
-	*(volatile char *) (bios + 0xAAA) = 0xAA;
-	*(volatile char *) (bios + 0x555) = 0x55;
-	*(volatile char *) (bios + 0xAAA) = 0x10;
+	*(volatile unsigned char *) (bios + 0xAAA) = 0xAA;
+	*(volatile unsigned char *) (bios + 0x555) = 0x55;
+	*(volatile unsigned char *) (bios + 0xAAA) = 0x10;
 
 	myusec_delay(10);
 	toggle_ready_m29f400bt(bios);
@@ -74,16 +74,16 @@
 	return (0);
 }
 
-int block_erase_m29f400bt(volatile char *bios, volatile char *dst)
+int block_erase_m29f400bt(volatile unsigned char *bios, volatile unsigned char *dst)
 {
 
-	*(volatile char *) (bios + 0xAAA) = 0xAA;
-	*(volatile char *) (bios + 0x555) = 0x55;
-	*(volatile char *) (bios + 0xAAA) = 0x80;
+	*(volatile unsigned char *) (bios + 0xAAA) = 0xAA;
+	*(volatile unsigned char *) (bios + 0x555) = 0x55;
+	*(volatile unsigned char *) (bios + 0xAAA) = 0x80;
 
-	*(volatile char *) (bios + 0xAAA) = 0xAA;
-	*(volatile char *) (bios + 0x555) = 0x55;
-	//*(volatile char *) (bios + 0xAAA) = 0x10;
+	*(volatile unsigned char *) (bios + 0xAAA) = 0xAA;
+	*(volatile unsigned char *) (bios + 0x555) = 0x55;
+	//*(volatile unsigned char *) (bios + 0xAAA) = 0x10;
 	*dst = 0x30;
 
 	myusec_delay(10);
@@ -97,7 +97,7 @@
 	int i;
 	int total_size = flash->total_size * 1024, page_size =
 	    flash->page_size;
-	volatile char *bios = flash->virt_addr;
+	volatile unsigned char *bios = flash->virt_addr;
 
 	//erase_m29f400bt (flash);
 	printf("Programming Page:\n ");
@@ -154,7 +154,7 @@
 
 int write_linuxbios_m29f400bt(struct flashchip *flash, unsigned char *buf)
 {
-	volatile char *bios = flash->virt_addr;
+	volatile unsigned char *bios = flash->virt_addr;
 
 	printf("Programming Page:\n ");
 	/*********************************
Index: LinuxBIOSv2/util/flash_and_burn/mx29f002.c
===================================================================
--- LinuxBIOSv2/util/flash_and_burn/mx29f002.c	(revision 2084)
+++ LinuxBIOSv2/util/flash_and_burn/mx29f002.c	(working copy)
@@ -32,7 +32,7 @@
 
 int probe_29f002(struct flashchip *flash)
 {
-	volatile char *bios = flash->virt_addr;
+	volatile unsigned char *bios = flash->virt_addr;
 	unsigned char id1, id2;
 
 	*(bios + 0x5555) = 0xAA;
@@ -55,7 +55,7 @@
 
 int erase_29f002(struct flashchip *flash)
 {
-	volatile char *bios = flash->virt_addr;
+	volatile unsigned char *bios = flash->virt_addr;
 
 	*(bios + 0x555) = 0xF0;
 	*(bios + 0x555) = 0xAA;
@@ -88,8 +88,8 @@
 {
 	int i;
 	int total_size = flash->total_size * 1024;
-	volatile char *bios = flash->virt_addr;
-	volatile char *dst = bios;
+	volatile unsigned char *bios = flash->virt_addr;
+	volatile unsigned char *dst = bios;
 
 	*bios = 0xF0;
 	myusec_delay(10);
Index: LinuxBIOSv2/util/flash_and_burn/82802ab.h
===================================================================
--- LinuxBIOSv2/util/flash_and_burn/82802ab.h	(revision 2084)
+++ LinuxBIOSv2/util/flash_and_burn/82802ab.h	(working copy)
@@ -5,10 +5,10 @@
 extern int erase_82802ab(struct flashchip *flash);
 extern int write_82802ab(struct flashchip *flash, unsigned char *buf);
 
-extern __inline__ void toggle_ready_82802ab(volatile char *dst)
+extern __inline__ void toggle_ready_82802ab(volatile unsigned char *dst)
 {
 	unsigned int i = 0;
-	char tmp1, tmp2;
+	unsigned char tmp1, tmp2;
 
 	tmp1 = *dst & 0x40;
 
@@ -21,10 +21,10 @@
 	}
 }
 
-extern __inline__ void data_polling_82802ab(volatile char *dst, char data)
+extern __inline__ void data_polling_82802ab(volatile unsigned char *dst, unsigned char data)
 {
 	unsigned int i = 0;
-	char tmp;
+	unsigned char tmp;
 
 	data &= 0x80;
 
@@ -36,11 +36,11 @@
 	}
 }
 
-extern __inline__ void protect_82802ab(volatile char *bios)
+extern __inline__ void protect_82802ab(volatile unsigned char *bios)
 {
-	*(volatile char *) (bios + 0x5555) = 0xAA;
-	*(volatile char *) (bios + 0x2AAA) = 0x55;
-	*(volatile char *) (bios + 0x5555) = 0xA0;
+	*(volatile unsigned char *) (bios + 0x5555) = 0xAA;
+	*(volatile unsigned char *) (bios + 0x2AAA) = 0x55;
+	*(volatile unsigned char *) (bios + 0x5555) = 0xA0;
 
 	usleep(200);
 }
Index: LinuxBIOSv2/util/flash_and_burn/m29f400bt.h
===================================================================
--- LinuxBIOSv2/util/flash_and_burn/m29f400bt.h	(revision 2084)
+++ LinuxBIOSv2/util/flash_and_burn/m29f400bt.h	(working copy)
@@ -5,15 +5,15 @@
 
 extern int probe_m29f400bt(struct flashchip *flash);
 extern int erase_m29f400bt(struct flashchip *flash);
-extern int block_erase_m29f400bt(volatile char *bios, volatile char *dst);
+extern int block_erase_m29f400bt(volatile unsigned char *bios, volatile unsigned char *dst);
 extern int write_m29f400bt(struct flashchip *flash, unsigned char *buf);
 extern int write_linuxbios_m29f400bt(struct flashchip *flash,
 				     unsigned char *buf);
 
-extern __inline__ void toggle_ready_m29f400bt(volatile char *dst)
+extern __inline__ void toggle_ready_m29f400bt(volatile unsigned char *dst)
 {
 	unsigned int i = 0;
-	char tmp1, tmp2;
+	unsigned char tmp1, tmp2;
 
 	tmp1 = *dst & 0x40;
 
@@ -26,11 +26,11 @@
 	}
 }
 
-extern __inline__ void data_polling_m29f400bt(volatile char *dst,
+extern __inline__ void data_polling_m29f400bt(volatile unsigned char *dst,
 					      unsigned char data)
 {
 	unsigned int i = 0;
-	char tmp;
+	unsigned char tmp;
 
 	data &= 0x80;
 
@@ -51,16 +51,16 @@
 	usleep(200);
 }
 
-extern __inline__ void write_page_m29f400bt(volatile char *bios, char *src,
-					    volatile char *dst,
+extern __inline__ void write_page_m29f400bt(volatile unsigned char *bios, unsigned char *src,
+					    volatile unsigned char *dst,
 					    int page_size)
 {
 	int i;
 
 	for (i = 0; i < page_size; i++) {
-		*(volatile char *) (bios + 0xAAA) = 0xAA;
-		*(volatile char *) (bios + 0x555) = 0x55;
-		*(volatile char *) (bios + 0xAAA) = 0xA0;
+		*(volatile unsigned char *) (bios + 0xAAA) = 0xAA;
+		*(volatile unsigned char *) (bios + 0x555) = 0x55;
+		*(volatile unsigned char *) (bios + 0xAAA) = 0xA0;
 
 		/* transfer data from source to destination */
 		*dst = *src;
@@ -69,7 +69,7 @@
 		toggle_ready_m29f400bt(dst);
 		printf
 		    ("Value in the flash at address %p = %#x, want %#x\n",
-		     (char *) (dst - bios), *dst, *src);
+		     (unsigned char *) (dst - bios), *dst, *src);
 		dst++;
 		src++;
 	}
Index: LinuxBIOSv2/util/flash_and_burn/sst49lf040.c
===================================================================
--- LinuxBIOSv2/util/flash_and_burn/sst49lf040.c	(revision 2084)
+++ LinuxBIOSv2/util/flash_and_burn/sst49lf040.c	(working copy)
@@ -35,7 +35,7 @@
         int i;
         int total_size = flash->total_size * 1024;
         int page_size = flash->page_size;
-        volatile char *bios = flash->virt_addr;
+        volatile unsigned char *bios = flash->virt_addr;
 
         for (i = 0; i < total_size / page_size; i++) {
 		/* Chip erase only works in parallel programming mode
@@ -50,7 +50,7 @@
 	int i;
 	int total_size = flash->total_size * 1024;
 	int page_size = flash->page_size;
-	volatile char *bios = flash->virt_addr;
+	volatile unsigned char *bios = flash->virt_addr;
 
 	printf("Programming Page: ");
 	for (i = 0; i < total_size / page_size; i++) {

From stepan at openbios.org  Sat Nov 12 21:18:27 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Sat, 12 Nov 2005 21:18:27 +0100
Subject: [LinuxBIOS] ROM image integrity
Message-ID: <20051112201827.GA6635@openbios.org>

Hi,

Some suggestions:

1) We could put a checksum in the LinuxBIOS rom image so it can be 
   checked for integrity during boot time. Usually safety relevant 
   embedded devices require such a checksum and use CRC16 or CRC32 
   for that.

2) Is there any distinct way of finding out whether a flash image 
   is a LinuxBIOS image? One thing that can be read from an image 
   is the mainboard vendor and id, but the code looks somewhat ugly:
      
      void show_id(unsigned char *bios, int size)
      {
              unsigned char *manuf, *id;
      
              id=bios+size-0x1d;
              while (*id==0) id--; 
              while (*id)    id--;
      
              manuf=id-1; id++;
              while (*manuf && *manuf!=0xff) manuf--;
              manuf++;
      
              printf("MANUFACTURER: %s\n", manuf);
              printf("MAINBOARD ID: %s\n", id);
      }
      
3) There should be a flash description map in the rom file that allows 
   a program accessing the flash to automatically exclude certain 
   flashing areas such as the onboard option rom space or the fallback 
   image.

Stefan



From stepan at openbios.org  Sat Nov 12 21:47:22 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Sat, 12 Nov 2005 21:47:22 +0100
Subject: [LinuxBIOS] drop struct lb_uint64?
Message-ID: <20051112204722.GA14901@openbios.org>

Hi,

what exactly is this structure good for?

declared in src/include/boot/linuxbios_tables.h:

struct lb_uint64 {
        uint32_t lo;
        uint32_t hi;
};

It is used in the following files:

  src/arch/i386/boot/linuxbios_table.c
  src/arch/ppc/boot/linuxbios_table.c
  src/boot/elfboot.c

since each machine that can compile LinuxBIOS, ie that has a
(cross-)gcc, does have a uint64_t we should use that one.

Stefan





From ebiederman at lnxi.com  Sat Nov 12 22:13:50 2005
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Sat, 12 Nov 2005 14:13:50 -0700
Subject: [LinuxBIOS] drop struct lb_uint64?
In-Reply-To: <20051112204722.GA14901@openbios.org> (Stefan Reinauer's
	message of "Sat, 12 Nov 2005 21:47:22 +0100")
References: <20051112204722.GA14901@openbios.org>
Message-ID: <m31x1lmuwh.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at openbios.org> writes:

> Hi,
>
> what exactly is this structure good for?
>
> declared in src/include/boot/linuxbios_tables.h:
>
> struct lb_uint64 {
>         uint32_t lo;
>         uint32_t hi;
> };
>
> It is used in the following files:
>
>   src/arch/i386/boot/linuxbios_table.c
>   src/arch/ppc/boot/linuxbios_table.c
>   src/boot/elfboot.c
>
> since each machine that can compile LinuxBIOS, ie that has a
> (cross-)gcc, does have a uint64_t we should use that one.

No, it used to be a uint64_t and that caused problems.  For reasons of
backwards compatibility we want 32bit alignment not 64bit alignment.
x86 only requires 32bit alignment for a unit64_t but x86_64 requires
64bit alignment.  

For all new instances I agree. 

Eric



From ebiederman at lnxi.com  Sat Nov 12 22:27:04 2005
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Sat, 12 Nov 2005 14:27:04 -0700
Subject: [LinuxBIOS] ROM image integrity
In-Reply-To: <20051112201827.GA6635@openbios.org> (Stefan Reinauer's message
	of "Sat, 12 Nov 2005 21:18:27 +0100")
References: <20051112201827.GA6635@openbios.org>
Message-ID: <m3wtjdlfpz.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at openbios.org> writes:

> Hi,
>
> Some suggestions:
>
> 1) We could put a checksum in the LinuxBIOS rom image so it can be 
>    checked for integrity during boot time. Usually safety relevant 
>    embedded devices require such a checksum and use CRC16 or CRC32 
>    for that.

That sounds sane, at least in principle.

> 2) Is there any distinct way of finding out whether a flash image 
>    is a LinuxBIOS image? One thing that can be read from an image 
>    is the mainboard vendor and id, but the code looks somewhat ugly:
>       
>       void show_id(unsigned char *bios, int size)
>       {
>               unsigned char *manuf, *id;
>       
>               id=bios+size-0x1d;
>               while (*id==0) id--; 
>               while (*id)    id--;
>       
>               manuf=id-1; id++;
>               while (*manuf && *manuf!=0xff) manuf--;
>               manuf++;
>       
>               printf("MANUFACTURER: %s\n", manuf);
>               printf("MAINBOARD ID: %s\n", id);
>       }

We have on most boards id.lds  That places that information at a magic location.
Unfortunately that conflicts with nvidia chipset requirements.   And I think
in the general case and fixed location will be a problem.
       
> 3) There should be a flash description map in the rom file that allows 
>    a program accessing the flash to automatically exclude certain 
>    flashing areas such as the onboard option rom space or the fallback 
>    image.

Again in principle I agree.  

My basic concern is that I don't think we can do this inline across
variations in architecture.  Although I don't have a problem exporting
such information from the linuxbios table which should work universally
but it won't work for the first we flash something.

Please checkout our latest version of lbflash
ftp://ftp.lnxi.com/pub/linuxbios/utilities/lbflash/

We have a working map.  The code works well enough that we can deal
with multiple flash chips and other weird cases automatically.

Things like not flashing the fallback image by default we have been doing
for a long time.  Being able to just flash the bootloader/payload we are
just starting to do but the structure is there.

The ideal case is if we could start converging flash_and_burn and lbflash.
At least with respect to user interface.

The case that isn't currently covered is a checksum and that is only because
it keeps slipping my mind.  We do perform a full byte for byte
comparison against the source file though.  Which is good to ensure
you have flashed successfully but it doesn't detect if your romimage
got damaged in transport.

Eric



From stepan at openbios.org  Sat Nov 12 23:12:23 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Sat, 12 Nov 2005 23:12:23 +0100
Subject: [LinuxBIOS] ROM image integrity
In-Reply-To: <m3wtjdlfpz.fsf@maxwell.lnxi.com>
References: <20051112201827.GA6635@openbios.org>
	<m3wtjdlfpz.fsf@maxwell.lnxi.com>
Message-ID: <20051112221223.GA27801@openbios.org>

* Eric W. Biederman <ebiederman at lnxi.com> [051112 22:27]:
> >       void show_id(unsigned char *bios, int size)
> >       {
> >               unsigned char *manuf, *id;
> >       
> >               id=bios+size-0x1d;
> >               while (*id==0) id--; 
> >               while (*id)    id--;
> >       
> >               manuf=id-1; id++;
> >               while (*manuf && *manuf!=0xff) manuf--;
> >               manuf++;
> >       
> >               printf("MANUFACTURER: %s\n", manuf);
> >               printf("MAINBOARD ID: %s\n", id);
> >       }
> 
> We have on most boards id.lds  That places that information at a magic location.
> Unfortunately that conflicts with nvidia chipset requirements.   And I think
> in the general case and fixed location will be a problem.
 
The above will fail on nvidia. Agreed. 

The next problem is that the id is relative to the end of the image.
So the start position changes 
a) dependent on the chipset
b) dependent on the length of the motherboard manufacturer and id.

NVIDIA:

SECTIONS {
        . = (_ROMBASE + ROM_IMAGE_SIZE - 0x80) - (__id_end - __id_start);
        .id (.): {
                *(.id)
        }
}

Others (src/arch/i386/lib/id.lds)
SECTIONS {
        . = (_ROMBASE + ROM_IMAGE_SIZE - 0x10) - (__id_end - __id_start);
        .id (.): {
                *(.id)
        }
}

the arima hdama image looks like this:
00000000fffdffd8 R __id_start
00000000fffdffd8 r vendor
00000000fffdffde r part
00000000fffdfff0 R __id_end

only the last 16 bytes don't belong to the ID.

funny enough, linuxbios.rom contains this:

007ffd0: ffff ffff ffff ffff 4152 494d 4100 4844  ........ARIMA.HD
007ffe0: 414d 4100 2800 0000 2200 0000 0000 0200  AMA.(...".......
007fff0: e9b5 49ff ff00 0000 e903 4aff ff00 0000  ..I.......J.....

So where does the 2800 0000 2200 0000 0000 0200 come from?

Does the linker put some crap in there after the ID?
 
This makes it really hard to do a decent identification, even if we know
where the ID should/could be.

I would also suggest that on a given cpu architecture (ie. x86 or ppc)
the ID string should either be at a fixed address, one that suits all
chipsets. Or It should be identifyable in flash using a signature,
similar to the LinuxBIOS table in memory.
 
> My basic concern is that I don't think we can do this inline across
> variations in architecture. 

If such a in-rom table differs in position or details between x86 and
ppc, this won't be too nasty.

> Although I don't have a problem exporting
> such information from the linuxbios table which should work universally
> but it won't work for the first we flash something.

I agree. Putting this in the LinuxBIOS table would be fine to probe the
running system. 
I rather plan for the case where there has never been a time with a
non-linuxbios image in flash.

> Please checkout our latest version of lbflash
> ftp://ftp.lnxi.com/pub/linuxbios/utilities/lbflash/
> 
> We have a working map.  The code works well enough that we can deal
> with multiple flash chips and other weird cases automatically.

I've looked at this. Do you deliver this map as an extra file with an
image? Having this in the image would help comparing the map of an file
image to that of the rom image for example. I.e. you have two versions
of a board out there, one with 8MBit flash and one with 4 MBit flash.
Someone has a 512kByte flash file. Is this the normal image of case 1
or a complete image of case 2 etc pp.

I'd rather give them a 
  cat rommap linuxbios.rom > linuxbios.flashimage 
than 2 different files to cope with because I bet someone will mix this
up some time. It's just not solid.

> The ideal case is if we could start converging flash_and_burn and lbflash.
> At least with respect to user interface.
 
I've looked at lbflash earlier today. It seems to be using mtd for all
it's actions while flash_and_burn uses /dev/mem and some extra magic.
Then there's my old and obsolete /dev/bios. I want to drop that one at
least and rather have an improved solution in userspace. 

MTD is overly complex for what we are doing. and flash_and_burn has been
working really reliably for me. 

I also saw you have a newer lbflash version available as a binary than
as source. Unfortunately there's no changelog in the binary rpm. Is it
worth waiting for that source release?

> The case that isn't currently covered is a checksum and that is only because
> it keeps slipping my mind.  We do perform a full byte for byte
> comparison against the source file though.  Which is good to ensure
> you have flashed successfully but it doesn't detect if your romimage
> got damaged in transport.

In safety critical environments a system is required to deny service if
it can't proof it's own integrity during runtime. Lots of systems even 
probe flash and memory continuedly during runtime to find bit tilts
within a really short manifestation time.

Stefan.




From stepan at openbios.org  Sat Nov 12 23:23:37 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Sat, 12 Nov 2005 23:23:37 +0100
Subject: [LinuxBIOS] drop struct lb_uint64?
In-Reply-To: <m31x1lmuwh.fsf@maxwell.lnxi.com>
References: <20051112204722.GA14901@openbios.org>
	<m31x1lmuwh.fsf@maxwell.lnxi.com>
Message-ID: <20051112222337.GA546@openbios.org>

* Eric W. Biederman <ebiederman at lnxi.com> [051112 22:13]:
> > struct lb_uint64 {
> >         uint32_t lo;
> >         uint32_t hi;
> > };
> 
> No, it used to be a uint64_t and that caused problems.  For reasons of
> backwards compatibility we want 32bit alignment not 64bit alignment.
> x86 only requires 32bit alignment for a unit64_t but x86_64 requires
> 64bit alignment.  
 
Ok alignment might be an issue. Though that is a tough assumption made
that a compiler won't happen to align the above struct to 64bit under
some circumstances.

Do you remember the problems that this caused? If so, we should probably
add a comment to the source, drop one version of the [un]pack_lb64
functions and put the other one in a common place.

The reason for my bitching is that there are so many of these things
that some of us know to be necessary whereas from an outsiders view it
might look like the left over of a long-fixed compiler bug or something.

Stefan





From yinghailu at gmail.com  Sat Nov 12 23:49:07 2005
From: yinghailu at gmail.com (yhlu)
Date: Sat, 12 Nov 2005 14:49:07 -0800
Subject: [LinuxBIOS] flash_and_burn fixes.
In-Reply-To: <20051112154350.GA26503@openbios.org>
References: <20051112154350.GA26503@openbios.org>
Message-ID: <2ea3fae10511121449l7f528b30g92efd539263fb743@mail.gmail.com>

can you use uint8_t there?

YH

On 11/12/05, Stefan Reinauer <stepan at openbios.org> wrote:
>
> Hi,
>
> flash_and_burn does not compile in gcc 4 anymore since it comes
> with -Werror. This makes sense since it is touching a very sensitive
> part of a system :-)
>
> Since gcc 4 warns a lot more about signed/unsigned pointer confusion
> I changed major parts of flash_and_burn to use unsigned pointers only.
> We are coping with data, so signedness is not interesting in the code.
> In fact it might rather hurt.
>
> I'll apply the patch to the repository shortly, when someone signs it
> off.
>
> Other questions:
> - Can we drop flash_on? The code seems included in flash_rom and it
> only works on old sis stuff anyways. We will not drop functionality
> by dropping this extra binary.
>
> - Should we rename the utility to flash_and_burn or should we rename
> the directory to flash_rom? There's a lot of confusion since the
> utility and it's location in the source tree have different names.
>
> Stefan
>
>
>
>
> --
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20051112/38147d3b/attachment.html>

From yinghailu at gmail.com  Sun Nov 13 00:06:06 2005
From: yinghailu at gmail.com (yhlu)
Date: Sat, 12 Nov 2005 15:06:06 -0800
Subject: [LinuxBIOS] drop struct lb_uint64?
In-Reply-To: <m31x1lmuwh.fsf@maxwell.lnxi.com>
References: <20051112204722.GA14901@openbios.org>
	<m31x1lmuwh.fsf@maxwell.lnxi.com>
Message-ID: <2ea3fae10511121506h1b253cb8heaaf3bfa58b53bbc@mail.gmail.com>

interesting, So even new gcc on x86 still default uint64_t to 32bit
alignment?

YH

On 11/12/05, Eric W. Biederman <ebiederman at lnxi.com> wrote:
>
> Stefan Reinauer <stepan at openbios.org> writes:
>
> > Hi,
> >
> > what exactly is this structure good for?
> >
> > declared in src/include/boot/linuxbios_tables.h:
> >
> > struct lb_uint64 {
> > uint32_t lo;
> > uint32_t hi;
> > };
> >
> > It is used in the following files:
> >
> > src/arch/i386/boot/linuxbios_table.c
> > src/arch/ppc/boot/linuxbios_table.c
> > src/boot/elfboot.c
> >
> > since each machine that can compile LinuxBIOS, ie that has a
> > (cross-)gcc, does have a uint64_t we should use that one.
>
> No, it used to be a uint64_t and that caused problems. For reasons of
> backwards compatibility we want 32bit alignment not 64bit alignment.
> x86 only requires 32bit alignment for a unit64_t but x86_64 requires
> 64bit alignment.
>
> For all new instances I agree.
>
> Eric
>
> --
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20051112/4729fa83/attachment.html>

From yinghailu at gmail.com  Sun Nov 13 02:23:43 2005
From: yinghailu at gmail.com (yhlu)
Date: Sat, 12 Nov 2005 17:23:43 -0800
Subject: [LinuxBIOS] ENTRY(_start)
Message-ID: <2ea3fae10511121723y57ef12cdid20d076d2fb88a2a@mail.gmail.com>

is the ENTRY (_start) in

arch/i386/init/ldscript.lb

and

c_start.S

needed?

the Normal image don't need to include entry16.inc, So ...

YH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20051112/71d56a07/attachment.html>

From rminnich at lanl.gov  Sun Nov 13 07:19:14 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Sat, 12 Nov 2005 23:19:14 -0700
Subject: [LinuxBIOS] flash_and_burn fixes.
In-Reply-To: <20051112154350.GA26503@openbios.org>
References: <20051112154350.GA26503@openbios.org>
Message-ID: <4376DAE2.6090708@lanl.gov>

Stefan Reinauer wrote:

> 
> Other questions: 
>  - Can we drop flash_on? The code seems included in flash_rom and it
>    only works on old sis stuff anyways. We will not drop functionality 
>    by dropping this extra binary.

drop it.

> 
>  - Should we rename the utility to flash_and_burn or should we rename
>    the directory to flash_rom? There's a lot of confusion since the
>    utility and it's location in the source tree have different names.
  	for (i = 0; i < total_size / page_size; i++) {
> 


yeah, that sounds good. I will miss the name flash_and_burn though.

ron



From ebiederman at lnxi.com  Sun Nov 13 09:33:28 2005
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Sun, 13 Nov 2005 01:33:28 -0700
Subject: [LinuxBIOS] ROM image integrity
In-Reply-To: <20051112221223.GA27801@openbios.org> (Stefan Reinauer's
	message of "Sat, 12 Nov 2005 23:12:23 +0100")
References: <20051112201827.GA6635@openbios.org>
	<m3wtjdlfpz.fsf@maxwell.lnxi.com>
	<20051112221223.GA27801@openbios.org>
Message-ID: <m3zmo9hrqf.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at openbios.org> writes:

> The above will fail on nvidia. Agreed. 
>
> The next problem is that the id is relative to the end of the image.
> So the start position changes 
> a) dependent on the chipset
> b) dependent on the length of the motherboard manufacturer and id.
>
> NVIDIA:
>
> SECTIONS {
>         . = (_ROMBASE + ROM_IMAGE_SIZE - 0x80) - (__id_end - __id_start);
>         .id (.): {
>                 *(.id)
>         }
> }
>
> Others (src/arch/i386/lib/id.lds)
> SECTIONS {
>         . = (_ROMBASE + ROM_IMAGE_SIZE - 0x10) - (__id_end - __id_start);
>         .id (.): {
>                 *(.id)
>         }
> }
>
> the arima hdama image looks like this:
> 00000000fffdffd8 R __id_start
> 00000000fffdffd8 r vendor
> 00000000fffdffde r part
> 00000000fffdfff0 R __id_end
>
> only the last 16 bytes don't belong to the ID.
>
> funny enough, linuxbios.rom contains this:
>
> 007ffd0: ffff ffff ffff ffff 4152 494d 4100 4844  ........ARIMA.HD
> 007ffe0: 414d 4100 2800 0000 2200 0000 0000 0200  AMA.(...".......
> 007fff0: e9b5 49ff ff00 0000 e903 4aff ff00 0000  ..I.......J.....
>
> So where does the 2800 0000 2200 0000 0000 0200 come from?
>
> Does the linker put some crap in there after the ID?
>  
> This makes it really hard to do a decent identification, even if we know
> where the ID should/could be.

I don't recall exactly but look at the code in lbflash does.  I
believe there is a pointer to where the vendor and part are.

> I would also suggest that on a given cpu architecture (ie. x86 or ppc)
> the ID string should either be at a fixed address, one that suits all
> chipsets. Or It should be identifyable in flash using a signature,
> similar to the LinuxBIOS table in memory.

The problem is that over time hardware people get inventive.  So
I'm not certain that is possible.
  
>> My basic concern is that I don't think we can do this inline across
>> variations in architecture. 
>
> If such a in-rom table differs in position or details between x86 and
> ppc, this won't be too nasty.

Agreed.  But having code that works everywhere is useful.

>> Although I don't have a problem exporting
>> such information from the linuxbios table which should work universally
>> but it won't work for the first we flash something.
>
> I agree. Putting this in the LinuxBIOS table would be fine to probe the
> running system. 
> I rather plan for the case where there has never been a time with a
> non-linuxbios image in flash.

Agreed.

>> Please checkout our latest version of lbflash
>> ftp://ftp.lnxi.com/pub/linuxbios/utilities/lbflash/
>> 
>> We have a working map.  The code works well enough that we can deal
>> with multiple flash chips and other weird cases automatically.
>
> I've looked at this. Do you deliver this map as an extra file with an
> image? 

Yes.  There is a directory with all of that.

> Having this in the image would help comparing the map of an file
> image to that of the rom image for example. I.e. you have two versions
> of a board out there, one with 8MBit flash and one with 4 MBit flash.
> Someone has a 512kByte flash file. Is this the normal image of case 1
> or a complete image of case 2 etc pp.

Right now as long as the image is small enough it fits in 4Mbit it will
happily flash in either a 4Mbit or an 8Mbit part.

> I'd rather give them a 
>   cat rommap linuxbios.rom > linuxbios.flashimage 
> than 2 different files to cope with because I bet someone will mix this
> up some time. It's just not solid.

Yes and no.  Having a directory with all of the pieces is useful, and is a lot
more maintainable from a forward/backwards compatibility point of view.  If
we combine them I would rather do it as a cpio or a tar or an rpm.
Something where the structure is apparent but you have to try to work
at it to get multiple files.

>> The ideal case is if we could start converging flash_and_burn and lbflash.
>> At least with respect to user interface.
>  
> I've looked at lbflash earlier today. It seems to be using mtd for all
> it's actions while flash_and_burn uses /dev/mem and some extra magic.
> Then there's my old and obsolete /dev/bios. I want to drop that one at
> least and rather have an improved solution in userspace. 
>
> MTD is overly complex for what we are doing. and flash_and_burn has been
> working really reliably for me. 

I am conflicted on that one.  If you are talking users and not developers
it is usually easier to ensure that people have the right mtd drivers
loaded.  Last I looked the mtd code had a much better structure than
flash_and_burn, allowing for much more code reuse and a lot more
eyes looking at the problems.  flash_and_burn on the other hand seems
a great tool for developers, who know what should be happening but it
doesn't seem to have as many checks to make certain that you aren't
doing something stupid.

> I also saw you have a newer lbflash version available as a binary than
> as source. Unfortunately there's no changelog in the binary rpm. Is it
> worth waiting for that source release?

Groan.  It looks like someone forget to place the source rpm on the
public ftp site.  2.1 is pretty much a maintenance release with the
exception of a couple of very minor bug fixes nothing really has
changed.  So for getting a feel of the structure and the files we
are currently using 2.0 should be reasonable starting point.


>> The case that isn't currently covered is a checksum and that is only because
>> it keeps slipping my mind.  We do perform a full byte for byte
>> comparison against the source file though.  Which is good to ensure
>> you have flashed successfully but it doesn't detect if your romimage
>> got damaged in transport.
>
> In safety critical environments a system is required to deny service if
> it can't proof it's own integrity during runtime. Lots of systems even 
> probe flash and memory continuedly during runtime to find bit tilts
> within a really short manifestation time.

Sure I don't have a problem with putting a checksum, crc or a hash in
a data segment somewhere.  It will likely take an extra linker pass
to do that but that shouldn't be a problem.  Ideally that would be one
of the triggers for deciding if we go to fallback or normal mode.

Hmm.  In looking at things I just noticed that the decompressor
doesn't have anything like that, which really is a bug.  That I
unfortunately didn't catch when I found that code.

Eric



From ebiederman at lnxi.com  Sun Nov 13 09:43:27 2005
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Sun, 13 Nov 2005 01:43:27 -0700
Subject: [LinuxBIOS] drop struct lb_uint64?
In-Reply-To: <20051112222337.GA546@openbios.org> (Stefan Reinauer's message
	of "Sat, 12 Nov 2005 23:23:37 +0100")
References: <20051112204722.GA14901@openbios.org>
	<m31x1lmuwh.fsf@maxwell.lnxi.com> <20051112222337.GA546@openbios.org>
Message-ID: <m3veyxhr9s.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at openbios.org> writes:

> * Eric W. Biederman <ebiederman at lnxi.com> [051112 22:13]:
>> > struct lb_uint64 {
>> >         uint32_t lo;
>> >         uint32_t hi;
>> > };
>> 
>> No, it used to be a uint64_t and that caused problems.  For reasons of
>> backwards compatibility we want 32bit alignment not 64bit alignment.
>> x86 only requires 32bit alignment for a unit64_t but x86_64 requires
>> 64bit alignment.  
>  
> Ok alignment might be an issue. Though that is a tough assumption made
> that a compiler won't happen to align the above struct to 64bit under
> some circumstances.

Compilers can do a lot but it would have to be a non-ABI conformant
C compiler to request 64bit alignment for that structure.

> Do you remember the problems that this caused? 
> If so, we should probably add a comment to the source, drop one
> version of the [un]pack_lb64 functions and put the other one in a
> common place.
>
> The reason for my bitching is that there are so many of these things
> that some of us know to be necessary whereas from an outsiders view it
> might look like the left over of a long-fixed compiler bug or
> something.

I actually a little surprised you don't remember as I think you were
the one who brought it to the list.  Someone was using the old
definition which was uint64_t in a 64bit environment and they couldn't
read the table.

I don't have a problem with adding a comment and cleaning up the
implementation.  At the bug fix out was the important piece.  Looking
at this started all kinds of discussion on how we needed to structure
the linuxbios table.  With this fix we did not have to redo everything
so life continued forward.

Eric



From ebiederman at lnxi.com  Sun Nov 13 11:07:26 2005
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Sun, 13 Nov 2005 03:07:26 -0700
Subject: [LinuxBIOS] drop struct lb_uint64?
In-Reply-To: <2ea3fae10511121506h1b253cb8heaaf3bfa58b53bbc@mail.gmail.com>
	(yinghailu@gmail.com's
	message of "Sat, 12 Nov 2005 15:06:06 -0800")
References: <20051112204722.GA14901@openbios.org>
	<m31x1lmuwh.fsf@maxwell.lnxi.com>
	<2ea3fae10511121506h1b253cb8heaaf3bfa58b53bbc@mail.gmail.com>
Message-ID: <m3r79kj1y9.fsf@maxwell.lnxi.com>

yhlu <yinghailu at gmail.com> writes:

> interesting, So even new gcc on x86 still default uint64_t to 32bit alignment?

It's a murky area of the C ABI but I don't think the implementation has
changed.  I know gcc and Intel's C compiler were at disagreement over
that one at one point.  But I would have to read through the release
notes to see.

If gcc has changed on x86 it is even more important that the field is 
not implemented as a uint64_t.  Because unfortunately it is preceded
by a 32bit number which means that field should only be 32bit aligned.

Eric



From stepan at openbios.org  Sun Nov 13 13:30:11 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Sun, 13 Nov 2005 13:30:11 +0100
Subject: [LinuxBIOS] drop struct lb_uint64?
In-Reply-To: <m3veyxhr9s.fsf@maxwell.lnxi.com>
References: <20051112204722.GA14901@openbios.org>
	<m31x1lmuwh.fsf@maxwell.lnxi.com>
	<20051112222337.GA546@openbios.org>
	<m3veyxhr9s.fsf@maxwell.lnxi.com>
Message-ID: <20051113123011.GA20806@openbios.org>

* Eric W. Biederman <ebiederman at lnxi.com> [051113 09:43]:
> I actually a little surprised you don't remember as I think you were
> the one who brought it to the list.  Someone was using the old
> definition which was uint64_t in a 64bit environment and they couldn't
> read the table.
 
Seems I was oblivious yesterday. You are right. Therefore I have
attached a patch to clean up lb_uint64 handling and comment it.

Looks Ok?

Stefan


-------------- next part --------------
Index: src/include/boot/linuxbios_tables.h
===================================================================
--- src/include/boot/linuxbios_tables.h	(revision 2085)
+++ src/include/boot/linuxbios_tables.h	(working copy)
@@ -31,7 +31,41 @@
  * table entries and be backwards compatible, but it is not required.
  */
 
+/* Since LinuxBIOS is usually compiled 32bit, gcc will align 64bit 
+ * types to 32bit boundaries. If the LinuxBIOS table is dumped on a 
+ * 64bit system, a uint64_t would be aligned to 64bit boundaries, 
+ * breaking the table format.
+ *
+ * lb_uint64 will keep 64bit LinuxBIOS table values aligned to 32bit
+ * to ensure compatibility. They can be accessed with the two functions
+ * below: unpack_lb64() and pack_lb64()
+ *
+ * See also: util/lbtdump/lbtdump.c
+ */
 
+struct lb_uint64 {
+	uint32_t lo;
+	uint32_t hi;
+};
+
+static inline uint64_t unpack_lb64(struct lb_uint64 value)
+{
+        uint64_t result;
+        result = value.hi;
+        result = (result << 32) + value.lo;
+        return result;
+}
+
+static inline struct lb_uint64 pack_lb64(uint64_t value)
+{
+        struct lb_uint64 result;
+        result.lo = (value >> 0) & 0xffffffff;
+        result.hi = (value >> 32) & 0xffffffff;
+        return result;
+}
+
+
+
 struct lb_header
 {
 	uint8_t  signature[4]; /* LBIO */
@@ -57,10 +91,6 @@
 
 #define LB_TAG_MEMORY	0x0001
 
-struct lb_uint64 {
-	uint32_t lo;
-	uint32_t hi;
-};
 struct lb_memory_range {
 	struct lb_uint64 start;
 	struct lb_uint64 size;
Index: src/arch/ppc/boot/linuxbios_table.c
===================================================================
--- src/arch/ppc/boot/linuxbios_table.c	(revision 2085)
+++ src/arch/ppc/boot/linuxbios_table.c	(working copy)
@@ -7,22 +7,6 @@
 #include <device/device.h>
 #include <stdlib.h>
 
-static inline uint64_t unpack_lb64(struct lb_uint64 value) 
-{
-	uint64_t result;
-	result = value.hi;
-	result = (result << 32) + value.lo;
-	return result;
-}
-
-static inline struct lb_uint64 pack_lb64(uint64_t value)
-{
-	struct lb_uint64 result;
-	result.lo = (value >> 0) & 0xffffffff;
-	result.hi = (value >> 32) & 0xffffffff;
-	return result;
-}
-
 struct lb_header *lb_table_init(unsigned long addr)
 {
 	struct lb_header *header;
Index: src/arch/i386/boot/linuxbios_table.c
===================================================================
--- src/arch/i386/boot/linuxbios_table.c	(revision 2085)
+++ src/arch/i386/boot/linuxbios_table.c	(working copy)
@@ -7,22 +7,6 @@
 #include <device/device.h>
 #include <stdlib.h>
 
-static inline uint64_t unpack_lb64(struct lb_uint64 value) 
-{
-	uint64_t result;
-	result = value.hi;
-	result = (result << 32) + value.lo;
-	return result;
-}
-
-static inline struct lb_uint64 pack_lb64(uint64_t value)
-{
-	struct lb_uint64 result;
-	result.lo = (value >> 0) & 0xffffffff;
-	result.hi = (value >> 32) & 0xffffffff;
-	return result;
-}
-
 struct lb_header *lb_table_init(unsigned long addr)
 {
 	struct lb_header *header;
Index: util/lbtdump/lbtdump.c
===================================================================
--- util/lbtdump/lbtdump.c	(revision 2085)
+++ util/lbtdump/lbtdump.c	(working copy)
@@ -9,14 +9,6 @@
 #include <sys/mman.h>
 #include "../../src/include/boot/linuxbios_tables.h"
 
-static inline uint64_t unpack_lb64(struct lb_uint64 value)
-{
-	uint64_t result;
-	result = value.hi;
-	result = (result << 32) + value.lo;
-	return result;
-}
-
 void print_lb_records(struct lb_record *rec, struct lb_record *last, unsigned long addr);
 
 unsigned long compute_checksum(void *addr, unsigned long length)

From stepan at openbios.org  Sun Nov 13 14:28:48 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Sun, 13 Nov 2005 14:28:48 +0100
Subject: [LinuxBIOS] ROM image integrity
In-Reply-To: <m3zmo9hrqf.fsf@maxwell.lnxi.com>
References: <20051112201827.GA6635@openbios.org>
	<m3wtjdlfpz.fsf@maxwell.lnxi.com>
	<20051112221223.GA27801@openbios.org>
	<m3zmo9hrqf.fsf@maxwell.lnxi.com>
Message-ID: <20051113132847.GB20806@openbios.org>

* Eric W. Biederman <ebiederman at lnxi.com> [051113 09:33]:
> > Others (src/arch/i386/lib/id.lds)
> > SECTIONS {
> >         . = (_ROMBASE + ROM_IMAGE_SIZE - 0x10) - (__id_end - __id_start);
> >         .id (.): {
> >                 *(.id)
> >         }
> > }
> >
> > the arima hdama image looks like this:
> > 00000000fffdffd8 R __id_start
> > 00000000fffdffd8 r vendor
> > 00000000fffdffde r part
> > 00000000fffdfff0 R __id_end
> >
> > only the last 16 bytes don't belong to the ID.
> >
> > funny enough, linuxbios.rom contains this:
> >
> > 007ffd0: ffff ffff ffff ffff 4152 494d 4100 4844  ........ARIMA.HD
> > 007ffe0: 414d 4100 2800 0000 2200 0000 0000 0200  AMA.(...".......
> > 007fff0: e9b5 49ff ff00 0000 e903 4aff ff00 0000  ..I.......J.....
> >
> > So where does the 2800 0000 2200 0000 0000 0200 come from?
> >
> > Does the linker put some crap in there after the ID?
 
Looking at crt0.s it is not crap but really useful: The linker places
pointers to the string so we actually don't have to walk backward. I
could not find this in the code, but I consider it can be used:

   int show_id(unsigned char *bios, int size)
   {
           unsigned char *manuf, *id;
           unsigned int *walk;
   
           walk=(unsigned int *)(bios+size-0x10);
           walk--; printf("image size=%d\n", *walk);
           walk--; id=bios+size-*walk;
           walk--; manuf=bios+size-*walk;
           printf("MANUFACTURER: %s\n", manuf);
           printf("MAINBOARD ID: %s\n", id);
           return 0;
   }

> > I would also suggest that on a given cpu architecture (ie. x86 or ppc)
> > the ID string should either be at a fixed address, one that suits all
> > chipsets. Or It should be identifyable in flash using a signature,
> > similar to the LinuxBIOS table in memory.
> 
> The problem is that over time hardware people get inventive.  So
> I'm not certain that is possible.
 
Though, matching a file image with what is in a certain system is
absolutely necessary if we want to establish LinuxBIOS as a usable 
product for end customers.

> > If such a in-rom table differs in position or details between x86 and
> > ppc, this won't be too nasty.
> 
> Agreed.  But having code that works everywhere is useful.

There will always be small differences, such where the image is located
and where the entry point is loaded. As long as there's a good mechanism
making it easy to get this information in one way we're fine. The
LinuxBIOS table is slightly different on ppc and x86 already today.

> > Having this in the image would help comparing the map of an file
> > image to that of the rom image for example. I.e. you have two versions
> > of a board out there, one with 8MBit flash and one with 4 MBit flash.
> > Someone has a 512kByte flash file. Is this the normal image of case 1
> > or a complete image of case 2 etc pp.
> 
> Right now as long as the image is small enough it fits in 4Mbit it will
> happily flash in either a 4Mbit or an 8Mbit part.
 
So you could flash a fallback only image over a fallback+normal image
without lbflash ever complaining.

> Yes and no.  Having a directory with all of the pieces is useful, and is a lot
> more maintainable from a forward/backwards compatibility point of view.  If
> we combine them I would rather do it as a cpio or a tar or an rpm.
> Something where the structure is apparent but you have to try to work
> at it to get multiple files.
 
Probably true.

> I am conflicted on that one.  If you are talking users and not developers
> it is usually easier to ensure that people have the right mtd drivers
> loaded.  Last I looked the mtd code had a much better structure than
> flash_and_burn, allowing for much more code reuse and a lot more
> eyes looking at the problems.  flash_and_burn on the other hand seems
> a great tool for developers, who know what should be happening but it
> doesn't seem to have as many checks to make certain that you aren't
> doing something stupid.
 
I would agree if mtd did the autoprobing and flash_and_burn didnt. But
finding the right pair of mtd drivers can be annoying. The modular
concept is nice, no doubt. But for an end user I don't really see an
advantage. 

> Groan.  It looks like someone forget to place the source rpm on the
> public ftp site.  2.1 is pretty much a maintenance release with the
> exception of a couple of very minor bug fixes nothing really has
> changed.  So for getting a feel of the structure and the files we
> are currently using 2.0 should be reasonable starting point.

Ah, I assumed that you would only provide the source for older releases,
same for the cmos tool. Which would be perfectly understandable. So I
will have a closer look at lbflash. How do you produce the rom tables?

> Hmm.  In looking at things I just noticed that the decompressor
> doesn't have anything like that, which really is a bug.  That I
> unfortunately didn't catch when I found that code.

Hey, it's really small. In a safety critical application we might not
even want to go to fallback mode but rather print an error message over
serial and go to nirvana in case of a wrong checksum. 
Just wondering where the best place for such a checksum check would be
anyways. I would not want to cope with this in ramless code I guess.

Stefan 





From yinghailu at gmail.com  Sun Nov 13 21:27:07 2005
From: yinghailu at gmail.com (yhlu)
Date: Sun, 13 Nov 2005 12:27:07 -0800
Subject: [LinuxBIOS] drop struct lb_uint64?
In-Reply-To: <20051113123011.GA20806@openbios.org>
References: <20051112204722.GA14901@openbios.org>
	<m31x1lmuwh.fsf@maxwell.lnxi.com> <20051112222337.GA546@openbios.org>
	<m3veyxhr9s.fsf@maxwell.lnxi.com>
	<20051113123011.GA20806@openbios.org>
Message-ID: <2ea3fae10511131227q274fb3a3n116e6ed7b308f26d@mail.gmail.com>

for alignment, We can use more generic function such as

static void int_to_stream(uint32_t val, uint8_t *dest)
{
int i;
for(i=0;i<4;i++) {
*(dest+i) = (val >> (8*i)) & 0xff;
}
}

static void int64_to_stream(uint64_t val, uint8_t *dest)
{
int i;
for(i=0;i<8;i++) {
*(dest+i) = (val >> (8*i)) & 0xff;
}
}

YH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20051113/6a7e0fe1/attachment.html>

From a.borisov at tesv.tmb.ru  Mon Nov 14 07:42:31 2005
From: a.borisov at tesv.tmb.ru (Anton Borisov)
Date: Mon, 14 Nov 2005 09:42:31 +0300
Subject: [LinuxBIOS] How to trace back execution of NBI image?
Message-ID: <20051114094231.3913c64b.a.borisov@tesv.tmb.ru>

Hi.
	I boot LX2 with etherboot payload. I see how ip-address is assigned and process of loading NBI image from TFTP server. Unfortunately NBI image can't be run - the reasons are obscured. How to trace back it's execution?

P.S.	etherboot payload is "via-rhine.elf". NBI's structure is below. Any ideas?

$ readelf -a thinstation.nbi
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 ff 00 00 00 00 00 00 00 00 
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            Standalone App
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Intel 80386
  Version:                           0x1
  Entry point address:               0x82800
  Start of program headers:          52 (bytes into file)
  Start of section headers:          276 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         7
  Size of section headers:           40 (bytes)
  Number of section headers:         1
  Section header string table index: 0

Section Header:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0] <corrupt>         NULL            00000000 000000 000000 00      0   0  0
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000200 0x00082800 0x00082800 0x01400 0x01400 RWE 0x200
  LOAD           0x001600 0x00082400 0x00082400 0x00200 0x00200 RWE 0x200
  LOAD           0x001800 0x00080000 0x00080000 0x00200 0x00200 RWE 0x200
  LOAD           0x001a00 0x00080200 0x00080200 0x01400 0x01400 RWE 0x200
  LOAD           0x002e00 0x00100000 0x00100000 0xa2800 0xa2800 RWE 0x200
  LOAD           0x0a5600 0x001a3000 0x001a3000 0xa2d000 0xa2d000 RWE 0x200
  NOTE           0x0001e8 0x00000000 0x00000000 0x00018 0x00000     0


-- 
Sincerely, Anton Borisov



From yinghailu at gmail.com  Mon Nov 14 15:12:26 2005
From: yinghailu at gmail.com (yhlu)
Date: Mon, 14 Nov 2005 06:12:26 -0800
Subject: [LinuxBIOS] How to trace back execution of NBI image?
In-Reply-To: <20051114094231.3913c64b.a.borisov@tesv.tmb.ru>
References: <20051114094231.3913c64b.a.borisov@tesv.tmb.ru>
Message-ID: <2ea3fae10511140612l5bca316fg8d8f8a30a2c84de6@mail.gmail.com>

why do yo use NBI instead of ELF image from mkelfimage?

YH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20051114/389d1b12/attachment.html>

From beneo at comcast.net  Wed Nov 16 20:16:37 2005
From: beneo at comcast.net (beneo)
Date: Wed, 16 Nov 2005 11:16:37 -0800
Subject: [LinuxBIOS] cache-as-ram question
Message-ID: <00d801c5eae2$445e33e0$131814ac@trans.corp>

Is the cache as ram a AMD specific feature? The code looks like it would work for intel CPU, but I seems remember intel CPU would just return FF when reading from a cacheable location before memory becomes avialbe. 

beneo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20051116/d47f832e/attachment.html>

From ollie at lanl.gov  Wed Nov 16 21:10:25 2005
From: ollie at lanl.gov (Li-Ta Lo)
Date: Wed, 16 Nov 2005 13:10:25 -0700
Subject: [LinuxBIOS] cache-as-ram question
In-Reply-To: <00d801c5eae2$445e33e0$131814ac@trans.corp>
References: <00d801c5eae2$445e33e0$131814ac@trans.corp>
Message-ID: <1132171825.17581.0.camel@logarithm.lanl.gov>

On Wed, 2005-11-16 at 11:16 -0800, beneo wrote:
> Is the cache as ram a AMD specific feature? The code looks like it
> would work for intel CPU, but I seems remember intel CPU would just
> return FF when reading from a cacheable location before memory becomes
> avialbe. 
>  

CAR is available for Intel processors as well as AMD.

> beneo
> -- 
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
-- 
Li-Ta Lo <ollie at lanl.gov>
Los Alamos National Lab




From talbotx at comcast.net  Wed Nov 16 21:15:52 2005
From: talbotx at comcast.net (Adam Talbot)
Date: Wed, 16 Nov 2005 12:15:52 -0800
Subject: [LinuxBIOS] Ram limit at 128mb Bios, or hardware?
Message-ID: <437B9378.1050306@comcast.net>

I have a small geode board that has a ram limit of 128MB.  This is 
stated in the doc's, I have not yet been able to test this, yet. If it 
does cap out at 128mb would this be a factor of the bios or the 
hardware, or both?
-Adam Talbot



From smithbone at gmail.com  Wed Nov 16 22:14:09 2005
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 16 Nov 2005 15:14:09 -0600
Subject: [LinuxBIOS] Ram limit at 128mb Bios, or hardware?
In-Reply-To: <437B9378.1050306@comcast.net>
References: <437B9378.1050306@comcast.net>
Message-ID: <8a0c36780511161314y31b51f44x8aa6b31e28295469@mail.gmail.com>

> I have a small geode board that has a ram limit of 128MB.  This is
> stated in the doc's, I have not yet been able to test this, yet. If it
> does cap out at 128mb would this be a factor of the bios or the
> hardware, or both?

In general is a hardware limit.  The ram interface is going to be
designed with a specific range of sdram chip density and bus loading
in mind.  At a given density you have to add more chips to the bus to
get more ram. This will increase the bus loading.  The limit should be
set for the maximim loading of the highest density at the maximum
speed.

If you purchase high quality ram modules that don't load the bus as
much and have very good matching on pcb you *might* get away with
adding more than the said maximum.  Also If you slow the bus down you
might be able to push the specs.  Over clockers do the inverse of this
all the time.  Getting good quality ram (keeping it good and cold) and
upping the clock rate beyond rated specs.

Density wise you can't normally do a whole lot.  Usually that needs a
new sdram controller.

As with all things in semi-conductors you can probally push the specs
beyond whats on the datasheet but it may not work across all boards.

--
Richard A. Smith



From bari at onelabs.com  Wed Nov 16 22:17:25 2005
From: bari at onelabs.com (Bari Ari)
Date: Wed, 16 Nov 2005 15:17:25 -0600
Subject: [LinuxBIOS] Ram limit at 128mb Bios, or hardware?
In-Reply-To: <437B9378.1050306@comcast.net>
References: <437B9378.1050306@comcast.net>
Message-ID: <437BA1E5.40102@onelabs.com>

Yes  :)

If it only has one DRAM slot it's probably a limitation of the pcb 
layout and or DRAM controller.

Which geode board or which chipset is being used? I can check the 
hardware specs for you.

-Bari

Adam Talbot wrote:
> I have a small geode board that has a ram limit of 128MB.  This is 
> stated in the doc's, I have not yet been able to test this, yet. If it 
> does cap out at 128mb would this be a factor of the bios or the 
> hardware, or both?
> -Adam Talbot
> 





From talbotx at comcast.net  Thu Nov 17 01:48:15 2005
From: talbotx at comcast.net (Adam Talbot)
Date: Wed, 16 Nov 2005 16:48:15 -0800
Subject: [LinuxBIOS] Ram limit at 128mb Bios, or hardware?
In-Reply-To: <437BA1E5.40102@onelabs.com>
References: <437B9378.1050306@comcast.net> <437BA1E5.40102@onelabs.com>
Message-ID: <437BD34F.80206@comcast.net>

Thank you for the great info Richard.  Bari here is all the current info 
I have on the board.
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&ssPageName=ADME:B:EOIBSAA:US:11&Item=6822282977
I hope to get to play with it soon.
-Adam

Bari Ari wrote:

> Yes  :)
>
> If it only has one DRAM slot it's probably a limitation of the pcb 
> layout and or DRAM controller.
>
> Which geode board or which chipset is being used? I can check the 
> hardware specs for you.
>
> -Bari
>
> Adam Talbot wrote:
>
>> I have a small geode board that has a ram limit of 128MB.  This is 
>> stated in the doc's, I have not yet been able to test this, yet. If 
>> it does cap out at 128mb would this be a factor of the bios or the 
>> hardware, or both?
>> -Adam Talbot
>>
>
>
>




From smithbone at gmail.com  Thu Nov 17 02:29:16 2005
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 16 Nov 2005 19:29:16 -0600
Subject: [LinuxBIOS] Ram limit at 128mb Bios, or hardware?
In-Reply-To: <437BD34F.80206@comcast.net>
References: <437B9378.1050306@comcast.net> <437BA1E5.40102@onelabs.com>
	<437BD34F.80206@comcast.net>
Message-ID: <8a0c36780511161729g14a74ebblc1426d2a533f7de3@mail.gmail.com>

On 11/16/05, Adam Talbot <talbotx at comcast.net> wrote:
> Thank you for the great info Richard.  Bari here is all the current info
> I have on the board.
> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&ssPageName=ADME:B:EOIBSAA:US:11&Item=6822282977
> I hope to get to play with it soon.

In this case you limit is neither hardware or software.  It appears to
be cost.  They just didn't want  to spend the extra $$ to put a
additional SODIMM on there.  That or they just didn't have the board
space.  Board real estate is closely coupled to cost.

XpressRAM Subsystem

    * SDRAM interface tightly coupled to CPU core and graphics
subsystem for maximum efficiency
    * 64-Bit wide memory bus
    * Support for:
          o Two 168-pin unbuffered DIMMs
          o Up to 16 simultaneously open banks
          o 16-byte reads (burst length of two)
          o Up to 256 MB total memory supported


--
Richard A. Smith



From smithbone at gmail.com  Thu Nov 17 02:35:30 2005
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 16 Nov 2005 19:35:30 -0600
Subject: [LinuxBIOS] Ram limit at 128mb Bios, or hardware?
In-Reply-To: <8a0c36780511161729g14a74ebblc1426d2a533f7de3@mail.gmail.com>
References: <437B9378.1050306@comcast.net> <437BA1E5.40102@onelabs.com>
	<437BD34F.80206@comcast.net>
	<8a0c36780511161729g14a74ebblc1426d2a533f7de3@mail.gmail.com>
Message-ID: <8a0c36780511161735g1c525dd2l629c7cc7fdec8d67@mail.gmail.com>

>           o 16-byte reads (burst length of two)
>           o Up to 256 MB total memory supported

Someone would have to study the datasheet to answer this but if it
somehow supports 256Mbit chips it might be possible to get a 256 Meg
stick in there.  Highly unlikely though.

--
Richard A. Smith



From bari at onelabs.com  Thu Nov 17 03:58:19 2005
From: bari at onelabs.com (Bari Ari)
Date: Wed, 16 Nov 2005 20:58:19 -0600
Subject: [LinuxBIOS] Ram limit at 128mb Bios, or hardware?
In-Reply-To: <437BD34F.80206@comcast.net>
References: <437B9378.1050306@comcast.net> <437BA1E5.40102@onelabs.com>
	<437BD34F.80206@comcast.net>
Message-ID: <437BF1CB.4020208@onelabs.com>

The GXLV processor on that board only supported up to 256MB of SDRAM. 
128MB per SDRAM slot.

-Bari

Adam Talbot wrote:
> Thank you for the great info Richard.  Bari here is all the current info 
> I have on the board.
> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&ssPageName=ADME:B:EOIBSAA:US:11&Item=6822282977 




From talbotx at comcast.net  Thu Nov 17 04:50:51 2005
From: talbotx at comcast.net (Adam Talbot)
Date: Wed, 16 Nov 2005 19:50:51 -0800
Subject: [LinuxBIOS] Ram limit at 128mb Bios, or hardware?
In-Reply-To: <8a0c36780511161735g1c525dd2l629c7cc7fdec8d67@mail.gmail.com>
References: <437B9378.1050306@comcast.net> <437BA1E5.40102@onelabs.com>	
	<437BD34F.80206@comcast.net>	
	<8a0c36780511161729g14a74ebblc1426d2a533f7de3@mail.gmail.com>
	<8a0c36780511161735g1c525dd2l629c7cc7fdec8d67@mail.gmail.com>
Message-ID: <437BFE1B.3060807@comcast.net>

Well... I have a 256mb (sdram sodimm pc100) sitting around, but it is of 
VERY low quality.  I will stick it on and hope for the best. If I 
remember from the last few times I have run across this issue, the board 
will still boot and run just fine, but it will only be able to access 
128mb of the 256mb stick. I think. I will let you guy's know how it 
turns out.
End the end I am looking only for one thing, boot time.  How fast can I 
get from power on to playing music in my embedded automotive application 
(Car computer). The less memory I have, the less I need to suspend to 
disk. I will give it a nice big swap space to play with.
-Adam

Richard Smith wrote:

>>          o 16-byte reads (burst length of two)
>>          o Up to 256 MB total memory supported
>>    
>>
>
>Someone would have to study the datasheet to answer this but if it
>somehow supports 256Mbit chips it might be possible to get a 256 Meg
>stick in there.  Highly unlikely though.
>
>--
>Richard A. Smith
>
>  
>




From miernik at ffii.org  Thu Nov 17 07:45:47 2005
From: miernik at ffii.org (Miernik)
Date: Thu, 17 Nov 2005 07:45:47 +0100
Subject: [LinuxBIOS] RAM limit of TM5800 with VT8231 southbridge
Message-ID: <20051117064547.5B6A.3.NOFFLE@localhost.localdomain.local>

As i noticed a discussion on RAM limit above, I would like to start one
too, but about my board:

I have a HP Compaq t5500 Thin Client

http://h18002.www1.hp.com/products/quickspecs/11746_div/11746_div.HTML
http://www.transmeta.com/success/thin/hp/hp_t5500.html
http://www.transmeta.com/success/thin/hp/hp_t5500_spec.html

It has a TRANSMETA CRUSOE 5800A073310 CPU (TM5800) with integrated
northbridge, and a VIA VT8231 southbridge.

29LV160ATTC-90  2 MB flash chip (soldered).

I would like to put LinuxBIOS on it, and I would like to put as much RAM
as possible in it.

It has 1 SO-DIMM 200-pin DDR slot, and some place for soldering RAM
chips on the board.

In the slot there is a 128 MB module now. HP specs say you can put max
512 MB module there.


What are the real RAM limits? The TM5800 CPU supports 4 GB of RAM, so
thats the upper limit, but is there anything that limits it lower, and
if so what?

I am now planning to buy a 1 GB DDR SO-DIMM module, and I hope it'll
work in the slot. Will it? Will only some modules work? If so what
should I look for? Will this module work:
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=6821167601

I found somewhere that:
TM5800 memory subsystems can be populated with
64-Mbit (4M x 16 or 8M x 8),
128-Mbit (8M x 16 or 16M x 8),
256-Mbit (16M x 16 or 32M x 8), or
512-Mbit (32M x 16 or 64M x 8) devices.
Note that only x8 and x16 memory devices are supported.

Does it mean that if only my module is made of 32Mx16 or 64Mx8 chips,
it'll work? Or is there anything more required? Does the VIA VT8231 or
the thing's BIOS creates any more limits? With LinuxBIOS will I be able
to put more RAM in than with stock BIOS?

And finally is there anyone here who uses LinuxBIOS on such CPU and
southbridge, and can share some expirience?

-- 
Miernik             _________________________  xmpp:miernik at amessage.info
___________________/_______________________/      mailto:miernik at ffii.org
Protect Europe from a legal disaster. Petition against software patents
http://www.noepatents.org/index_html?LANG=en




From bari at onelabs.com  Thu Nov 17 16:27:42 2005
From: bari at onelabs.com (Bari Ari)
Date: Thu, 17 Nov 2005 09:27:42 -0600
Subject: [LinuxBIOS] Ram limit at 128mb Bios, or hardware?
In-Reply-To: <437BFE1B.3060807@comcast.net>
References: <437B9378.1050306@comcast.net>
	<437BA1E5.40102@onelabs.com>		<437BD34F.80206@comcast.net>		<8a0c36780511161729g14a74ebblc1426d2a533f7de3@mail.gmail.com>	<8a0c36780511161735g1c525dd2l629c7cc7fdec8d67@mail.gmail.com>
	<437BFE1B.3060807@comcast.net>
Message-ID: <437CA16E.3070107@onelabs.com>

The old GX1 and GXLV's were sensitive to SDRAM SDCLK speeds vs the 
number of loads (devices). Validated memory timings were pretty 
conservative. Depending on how your 256MB SDRAM SODIMM is configured, it 
may need to have the SDCLK slowed to make the half that may be 
accessible by the memory controller to work reliably.

-Bari


Adam Talbot wrote:
> Well... I have a 256mb (sdram sodimm pc100) sitting around, but it is of 
> VERY low quality.  I will stick it on and hope for the best. If I 
> remember from the last few times I have run across this issue, the board 
> will still boot and run just fine, but it will only be able to access 
> 128mb of the 256mb stick. I think. I will let you guy's know how it 
> turns out.
> End the end I am looking only for one thing, boot time.  How fast can I 
> get from power on to playing music in my embedded automotive application 
> (Car computer). The less memory I have, the less I need to suspend to 
> disk. I will give it a nice big swap space to play with.
> -Adam
> 
> Richard Smith wrote:
> 
> 
>>>         o 16-byte reads (burst length of two)
>>>         o Up to 256 MB total memory supported
>>>   
>>>
>>
>>Someone would have to study the datasheet to answer this but if it
>>somehow supports 256Mbit chips it might be possible to get a 256 Meg
>>stick in there.  Highly unlikely though.
>>
>>--
>>Richard A. Smith
>>
>> 
>>
> 
> 
> 





From bari at onelabs.com  Thu Nov 17 17:02:45 2005
From: bari at onelabs.com (Bari Ari)
Date: Thu, 17 Nov 2005 10:02:45 -0600
Subject: [LinuxBIOS] RAM limit of TM5800 with VT8231 southbridge
In-Reply-To: <20051117064547.5B6A.3.NOFFLE@localhost.localdomain.local>
References: <20051117064547.5B6A.3.NOFFLE@localhost.localdomain.local>
Message-ID: <437CA9A5.3080101@onelabs.com>

Miernik wrote:

> What are the real RAM limits? 

The "real" RAM size limit is a function of several aspects of the design.

	Design of the memory controller silicon
	PCB layout
	Number of DIMM memory slots
	Design and layout of the actual DIMM's
	BIOS


> The TM5800 CPU supports 4 GB of RAM, so

The TM5800 can directly address 4GB of memory space since it is a 32 bit 
cpu. However the maximum memory size in the DIMM sockets the TM5800 can 
address is 1025MB arranged as two banks of 512MB or four banks of 256MB.

What the maximum DRAM size is for the thin client design by HP depends 
on how they designed the PCB and BIOS.

> thats the upper limit, but is there anything that limits it lower, and
> if so what?

Design of the memory controller silicon and available DIMM 
configurations plus BIOS sets the lower limit.

The memory controller can handle devices as small as 4M x 16 and with 
one bank. Its lower limit then is 32MB.


> 
> I am now planning to buy a 1 GB DDR SO-DIMM module, and I hope it'll
> work in the slot. Will it? Will only some modules work? If so what
> should I look for? Will this module work:
> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=6821167601
> 
> I found somewhere that:
> TM5800 memory subsystems can be populated with
> 64-Mbit (4M x 16 or 8M x 8),
> 128-Mbit (8M x 16 or 16M x 8),
> 256-Mbit (16M x 16 or 32M x 8), or
> 512-Mbit (32M x 16 or 64M x 8) devices.
> Note that only x8 and x16 memory devices are supported.
> 
> Does it mean that if only my module is made of 32Mx16 or 64Mx8 chips,
> it'll work? Or is there anything more required? Does the VIA VT8231 or
> the thing's BIOS creates any more limits? With LinuxBIOS will I be able
> to put more RAM in than with stock BIOS?
> 
> And finally is there anyone here who uses LinuxBIOS on such CPU and
> southbridge, and can share some expirience?
> 

Look for modules that that minimize the number of loads. Use
the largest capacity devices possible for a given memory size. The SDRAM 
interface cannot drive more than sixteen unbuffered devices. SDR SDRAM 
configurations requiring more than sixteen loads must use buffered SDR 
memory.

-Bari




From miernik at ffii.org  Fri Nov 18 08:58:38 2005
From: miernik at ffii.org (Miernik)
Date: Fri, 18 Nov 2005 08:58:38 +0100
Subject: [LinuxBIOS] RAM limit of TM5800 with VT8231 southbridge
References: <20051117064547.5B6A.3.NOFFLE@localhost.localdomain.local>
	<437CA9A5.3080101@onelabs.com>
Message-ID: <20051118075838.10B0.0.NOFFLE@localhost.localdomain.local>

Bari Ari <bari at onelabs.com> wrote:
> The TM5800 can directly address 4GB of memory space since it is a 32 bit 
> cpu. However the maximum memory size in the DIMM sockets the TM5800 can 
> address is 1025MB 

1024 MB you mean?

If only 1 GB can go in DIMM sockets, where can the remaining 3 GB go?

> arranged as two banks of 512MB or four banks of 256MB.

Is "bank" = "1 DIMM module" or?

> Design of the memory controller silicon 

Is the memory controller silicon inside the TM5800, or is it some
separate chip?

> Look for modules that that minimize the number of loads. 

What are "loads"?

> The SDRAM interface cannot drive more than sixteen unbuffered devices.
> SDR SDRAM configurations requiring more than sixteen loads must use
> buffered SDR memory.

But I am talking about DDR here, not SDR.

TM5800 does not support buffered memory:
http://transmeta.com/crusoe_docs/TM5800v2.1_databook_030922.pdf
Page 2, section 1.2.1

-- 
Miernik             _________________________  xmpp:miernik at amessage.info
___________________/_______________________/      mailto:miernik at ffii.org
Protect Europe from a legal disaster. Petition against software patents
http://www.noepatents.org/index_html?LANG=en




From bari at onelabs.com  Fri Nov 18 17:20:58 2005
From: bari at onelabs.com (Bari Ari)
Date: Fri, 18 Nov 2005 10:20:58 -0600
Subject: [LinuxBIOS] RAM limit of TM5800 with VT8231 southbridge
In-Reply-To: <20051118075838.10B0.0.NOFFLE@localhost.localdomain.local>
References: <20051117064547.5B6A.3.NOFFLE@localhost.localdomain.local>	<437CA9A5.3080101@onelabs.com>
	<20051118075838.10B0.0.NOFFLE@localhost.localdomain.local>
Message-ID: <437DFF6A.6040409@onelabs.com>

Miernik wrote:
> Bari Ari <bari at onelabs.com> wrote:
> 
>>The TM5800 can directly address 4GB of memory space since it is a 32 bit 
>>cpu. However the maximum memory size in the DIMM sockets the TM5800 can 
>>address is 1025MB 
> 
> 
> 1024 MB you mean?
Yes 1024MB, pardon the typo.
> 
> If only 1 GB can go in DIMM sockets, where can the remaining 3 GB go?
Nowhere. All the DDR memory controller in the TM5800 can address is 1GB 
of DDR.

Look at Table #4, page 23, and section 1.2 on page 20, and through 1.2.4 
on page 24, TM5800v2.1_databook for an explanation of all this.
> 
> Is the memory controller silicon inside the TM5800, or is it some
> separate chip?
Inside the TM5800. Figure #1, page 10, TM5800v2.1_databook.
> 
> 
>>Look for modules that that minimize the number of loads. 
> 
> 
> What are "loads"?
  Loads = devices.

Again, the datasheet may list capabilities that may not be available on 
the mainboard. There may be traces and pads on the board without 
components soldered in to save costs. The bean counters may drop 
features off a board after the design has been completed. Leaving out 
components such as DIMMs or other connectors is an easy way to save on 
production costs without having to respin the pcb.

The PCB designers may have had problems with traces and parts placement 
so memory speeds are compromised. Also the datasheet may not list all 
the problems and workarounds with the device. Issues with cpu's and 
chipsets are usually in the NDA doc's vs public doc's.

-Bari




From stepan at openbios.org  Sat Nov 19 15:05:50 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Sat, 19 Nov 2005 15:05:50 +0100
Subject: [LinuxBIOS] CMOS checksums on intel/xe7501devkit
Message-ID: <20051119140550.GA7032@openbios.org>

Hi,

is there a reason that the LB checksum used on the intel/xe7501devkit
is completely different (and covers a really small space only)

default LB_CKS_RANGE_START=128
default LB_CKS_RANGE_END=130
default LB_CKS_LOC=131


compared to all the other supported boards:

default LB_CKS_RANGE_START=49
default LB_CKS_RANGE_END=122
default LB_CKS_LOC=123


Regards
Stefan





From smithbone at gmail.com  Sat Nov 19 17:23:36 2005
From: smithbone at gmail.com (Richard Smith)
Date: Sat, 19 Nov 2005 10:23:36 -0600
Subject: [LinuxBIOS] RAM limit of TM5800 with VT8231 southbridge
In-Reply-To: <437DFF6A.6040409@onelabs.com>
References: <20051117064547.5B6A.3.NOFFLE@localhost.localdomain.local>
	<437CA9A5.3080101@onelabs.com>
	<20051118075838.10B0.0.NOFFLE@localhost.localdomain.local>
	<437DFF6A.6040409@onelabs.com>
Message-ID: <8a0c36780511190823n10c503f0s9aad8fa69a20a818@mail.gmail.com>

> >
> > If only 1 GB can go in DIMM sockets, where can the remaining 3 GB go?
> Nowhere. All the DDR memory controller in the TM5800 can address is 1GB
> of DDR.

Processor address space != system memory.

Some of that 32-bit address space is reserved for =memory mapped PCI
devices, Some of it is allocated to your Graphics card RAM, Some of it
accesses the BIOS chip.

In the datasheets there should be a section called something like the
processory memory map or system memory map.

This section should outline what ranges of addresses are reserved for
what.  The board designers may also have special areas that are
reserved.

> > What are "loads"?
>   Loads = devices.

Thats EE speak for how many devices you can control on a bus.  Heres a
really gross oversimplification way to think about it.  Consider the
water coming into your home or apartment.  Only so much water can make
it into your home via the incomming pipe.  Each time you turn on a tap
the flow rate of the water reduces.  So when the washing machine is
on, the dishwasher is on, and somebody flushes the poor soul in the
shower gets almost no water pressure.

Each one of those items is a "load."  Each system can only support so
many loads before one part of the system suffers or just dosen't work
at all.


> Again, the datasheet may list capabilities that may not be available on
> the mainboard. There may be traces and pads on the board without

Like Bari says,  A high speed memory system is a _really_ tricky thing
to get right.  In fact I'm somewhat amazed we get them to work at all.
 At 200 Mhz a clock dosen't look like a clock anymore.  And you
violate timing specs if things are just a few nano-seconds (10E-9)
off.
If the manual lists things a certain way then in general thats the way
they need to be or your in for trouble.

Memory aside, I thought there were issues with the transmeta parts and
not enough documentation from transmeta?

--
Richard A. Smith



From miernik at ffii.org  Sat Nov 19 18:04:27 2005
From: miernik at ffii.org (Miernik)
Date: Sat, 19 Nov 2005 18:04:27 +0100
Subject: [LinuxBIOS] RAM limit of TM5800 with VT8231 southbridge
References: <20051117064547.5B6A.3.NOFFLE@localhost.localdomain.local>
	<437CA9A5.3080101@onelabs.com>
	<20051118075838.10B0.0.NOFFLE@localhost.localdomain.local>
	<437DFF6A.6040409@onelabs.com>
	<8a0c36780511190823n10c503f0s9aad8fa69a20a818@mail.gmail.com>
Message-ID: <20051119170427.6A23.2.NOFFLE@localhost.localdomain.local>

Richard Smith <smithbone at gmail.com> wrote:
> Memory aside, I thought there were issues with the transmeta parts and
> not enough documentation from transmeta?

And aside memory, can I currently flash this board with LinuxBIOS, and
how to safely do it, provided the flash part is soldered? I don't wan't
to make it useless.

It has to be a standard desktop computer, with video (may be
framebuffer), USB keyboard, IDE not essenstial, I can have only network
boot and USB flash disk.

0000:00:00.0 Host bridge: Transmeta Corporation LongRun Northbridge (rev 03)
0000:00:00.1 RAM memory: Transmeta Corporation SDRAM controller
0000:00:00.2 RAM memory: Transmeta Corporation BIOS scratchpad
0000:00:0d.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27)
0000:00:11.0 ISA bridge: VIA Technologies, Inc. VT8231 [PCI-to-ISA Bridge] (rev 10)
0000:00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
0000:00:11.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 1e)
0000:00:11.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 1e)
0000:00:11.4 Bridge: VIA Technologies, Inc. VT8235 ACPI (rev 10)
0000:00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686 AC97 Audio Controller (rev 40)
0000:00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 51)


Below are the main components on the motherboard:


P558 M/B        (motherboard)
02157-1.
48.3B201 .011
MADE  IN CHINA

CATAC 84V-0
E217196 CTML-1
041503


U8              (PHY)
VIA
VT6103
0408CD TAIWAN
2HF0443886


U4              (AUDIO)
VIA
VT1612A
0406CD TAIWAN
2HA4426311


U15             (Southbridge)
VIA
VT8231
0409CD TAIWAN
13H017100


U21             (VIDEO)
ATI
RAGE XL
215R3LASB41
DE5541.00
0340AA
TAIWAN


U16             (BIOS 2 MB)
----------------
MX B041172
29LV160ATTC-90
2J031300
TAIWAN

on sticker:
P558
U16
V1.09-733
----------------


U18             (CPU)
----------------
TRANSMETA CRUSOE
5800A073310

301320
101070
  0402

A1D23

B610K -2
DD2643.00
TAIWAN
----------------


U20             (2Mx32 = 8MB RAM)
0412        3-2
MT   48LC2M32B2
TG         -6 F



Did anyone do it? Do you recommend just to try it, and what rescue
options will I have if it goes wrong?

-- 
Miernik             _________________________  xmpp:miernik at amessage.info
___________________/_______________________/      mailto:miernik at ffii.org
                       Save Europe from Software Patents
                http://www.gnu.org/philosophy/savingeurope.html




From ak at suse.de  Mon Nov 21 23:06:05 2005
From: ak at suse.de (Andi Kleen)
Date: Mon, 21 Nov 2005 23:06:05 +0100
Subject: [LinuxBIOS] x86_64: apic id lift patch
In-Reply-To: <86802c440511211349t6a0a9d30i60e15fa23b86c49d@mail.gmail.com>
References: <86802c440511211349t6a0a9d30i60e15fa23b86c49d@mail.gmail.com>
Message-ID: <20051121220605.GD20775@brahms.suse.de>

On Mon, Nov 21, 2005 at 01:49:09PM -0800, yhlu wrote:
> Andi,
> 
> Please check the patch regarding apicid lifting.
> 
> For some reason, we need to lift AP apicid but keep the BSP apicid to 0....
> 
> Also it solve the E0 later single but have apic id reorder problem...

Can you please explain clearly:

- What are you changing.
- What was the problem with the old behaviour
- Why that particular change
- Why can't that APIC number setup not be done by the BIOS itself

Thanks.

Please note there is a high barrier of entry for any kind of BIOS workarounds -
in particular for LinuxBIOS i'm not very motivated because you guys can
just fix the BIOS.

-Andi




From ak at suse.de  Mon Nov 21 23:24:29 2005
From: ak at suse.de (Andi Kleen)
Date: Mon, 21 Nov 2005 23:24:29 +0100
Subject: [LinuxBIOS] x86_64: apic id lift patch
In-Reply-To: <86802c440511211417h737474fbt57946f4f2396b701@mail.gmail.com>
References: <86802c440511211349t6a0a9d30i60e15fa23b86c49d@mail.gmail.com>
	<20051121220605.GD20775@brahms.suse.de>
	<86802c440511211417h737474fbt57946f4f2396b701@mail.gmail.com>
Message-ID: <20051121222429.GE20775@brahms.suse.de>

On Mon, Nov 21, 2005 at 02:17:35PM -0800, yhlu wrote:
> > Can you please explain clearly:
> >
> > - What are you changing.
> 1.  use core_vir instead of x86_max_cores, for E0 later single core,
> core_vir could be 2, and x86_max_cores still is 1. So it makes node
> calculation right.

max_cores should be 2 here.

> > - What was the problem with the old behaviour
> 1. for E0 single core, node 2, initial apicid is 4, and old cold will
> get node=4 instead of 2.
> 2. if the lifted apicid is not continous, it will assign strange node
> id to the cpu.

Is there a good reason in the BIOS to not make it contiguous?

> > - Why that particular change
> 1. We can get exact node id and core id from initial apicid for E0 later.
> > - Why can't that APIC number setup not be done by the BIOS itself
> 1. That patch the code more generic. and don't assume the lifted
> apicid is continous.

It's only the last resort fallback anyways. I would prefer to not
make it more complicated. The recommend way is you supplying
a SRAT table, then you're independent of any such fallback heuristics
and just tell the kernel the right mapping.

-Andi



From yhlu.kernel at gmail.com  Mon Nov 21 22:49:09 2005
From: yhlu.kernel at gmail.com (yhlu)
Date: Mon, 21 Nov 2005 13:49:09 -0800
Subject: [LinuxBIOS] x86_64: apic id lift patch
Message-ID: <86802c440511211349t6a0a9d30i60e15fa23b86c49d@mail.gmail.com>

Andi,

Please check the patch regarding apicid lifting.

For some reason, we need to lift AP apicid but keep the BSP apicid to 0....

Also it solve the E0 later single but have apic id reorder problem...

YH


diff --git a/arch/x86_64/kernel/setup.c b/arch/x86_64/kernel/setup.c
--- a/arch/x86_64/kernel/setup.c
+++ b/arch/x86_64/kernel/setup.c
@@ -786,13 +786,24 @@ static void __init amd_detect_cmp(struct
 #ifdef CONFIG_SMP
 	int cpu = smp_processor_id();
 	unsigned bits;
+	int cores_vir;
 #ifdef CONFIG_NUMA
 	int node = 0;
-	unsigned apicid = phys_proc_id[cpu];
+	unsigned initial_apicid = phys_proc_id[cpu];
+	unsigned apicid = hard_smp_processor_id();
 #endif
+	
+	cores_vir = c->x86_max_cores;
+	if(cores_vir == 1) {
+		unsigned level = cpuid_eax(1);
+		/* double check if it is E0 later, only E0 later can reorder apicid
for single core */
+        	if ((level & 0xf0f00) >= 0x20f00) {
+			cores_vir = 2;
+		}
+	}

 	bits = 0;
-	while ((1 << bits) < c->x86_max_cores)
+	while ((1 << bits) < cores_vir)
 		bits++;

 	/* Low order bits define the core id (index of core in socket) */
@@ -802,32 +813,23 @@ static void __init amd_detect_cmp(struct

 #ifdef CONFIG_NUMA
   	node = phys_proc_id[cpu];
- 	if (apicid_to_node[apicid] != NUMA_NO_NODE)
- 		node = apicid_to_node[apicid];
+
+ 	if (apicid_to_node[apicid] == NUMA_NO_NODE)
+ 		apicid_to_node[apicid] = node;
+	
  	if (!node_online(node)) {
- 		/* Two possibilities here:
+ 		/* One possibilities here:
  		   - The CPU is missing memory and no node was created.
- 		   In that case try picking one from a nearby CPU
- 		   - The APIC IDs differ from the HyperTransport node IDs
- 		   which the K8 northbridge parsing fills in.
- 		   Assume they are all increased by a constant offset,
- 		   but in the same order as the HT nodeids.
- 		   If that doesn't result in a usable node fall back to the
- 		   path for the previous case.  */
- 		int ht_nodeid = apicid - (phys_proc_id[0] << bits);
- 		if (ht_nodeid >= 0 &&
- 		    apicid_to_node[ht_nodeid] != NUMA_NO_NODE)
- 			node = apicid_to_node[ht_nodeid];
- 		/* Pick a nearby node */
- 		if (!node_online(node))
- 			node = nearby_node(apicid);
+ 		   In that case try picking one from a nearby CPU */
+ 		node = nearby_node(apicid);
  	}
+
 	numa_set_node(cpu, node);
+#endif

   	printk(KERN_INFO "CPU %d(%d) -> Node %d -> Core %d\n",
   			cpu, c->x86_max_cores, node, cpu_core_id[cpu]);
 #endif
-#endif
 }

 static int __init init_amd(struct cpuinfo_x86 *c)



From yhlu.kernel at gmail.com  Mon Nov 21 23:17:35 2005
From: yhlu.kernel at gmail.com (yhlu)
Date: Mon, 21 Nov 2005 14:17:35 -0800
Subject: [LinuxBIOS] x86_64: apic id lift patch
In-Reply-To: <20051121220605.GD20775@brahms.suse.de>
References: <86802c440511211349t6a0a9d30i60e15fa23b86c49d@mail.gmail.com>
	<20051121220605.GD20775@brahms.suse.de>
Message-ID: <86802c440511211417h737474fbt57946f4f2396b701@mail.gmail.com>

> Can you please explain clearly:
>
> - What are you changing.
1.  use core_vir instead of x86_max_cores, for E0 later single core,
core_vir could be 2, and x86_max_cores still is 1. So it makes node
calculation right.
2. not assuming that lifted apic id is continous. We can get exact
node id and core id from initial apicid.
> - What was the problem with the old behaviour
1. for E0 single core, node 2, initial apicid is 4, and old cold will
get node=4 instead of 2.
2. if the lifted apicid is not continous, it will assign strange node
id to the cpu.
> - Why that particular change
1. We can get exact node id and core id from initial apicid for E0 later.
> - Why can't that APIC number setup not be done by the BIOS itself
1. That patch the code more generic. and don't assume the lifted
apicid is continous.

Thanks

YH



From yhlu.kernel at gmail.com  Mon Nov 21 23:31:44 2005
From: yhlu.kernel at gmail.com (yhlu)
Date: Mon, 21 Nov 2005 14:31:44 -0800
Subject: [LinuxBIOS] x86_64: apic id lift patch
In-Reply-To: <20051121222429.GE20775@brahms.suse.de>
References: <86802c440511211349t6a0a9d30i60e15fa23b86c49d@mail.gmail.com>
	<20051121220605.GD20775@brahms.suse.de>
	<86802c440511211417h737474fbt57946f4f2396b701@mail.gmail.com>
	<20051121222429.GE20775@brahms.suse.de>
Message-ID: <86802c440511211431p57628e01o5c8030c4e09deaba@mail.gmail.com>

>
> max_cores should be 2 here.
No, For E0 single core, x86_max_cores will be 1, the initial apicid
can not be shifted to node id....
>
>
> Is there a good reason in the BIOS to not make it contiguous?
>
amd8111, if i lift the bsp apic id, the jiffies will not be moving....,

YH



From steve at digidescorp.com  Mon Nov 21 23:58:25 2005
From: steve at digidescorp.com (Steven J. Magnani)
Date: Mon, 21 Nov 2005 16:58:25 -0600
Subject: [LinuxBIOS] CMOS checksums on intel/xe7501devkit
In-Reply-To: <20051119140550.GA7032@openbios.org>
Message-ID: <000a01c5eeef$149264e0$47070a0a@banana>

Yes - on the XE7501DEVKIT, the factory BIOS appears to use all of the
low 128 bytes of CMOS. So in order to have peaceful coexistence of LB
and the factory BIOS, the default XE7501DEVKIT build doesn't use CMOS at
all (i.e. single-image build).

Steve
------------------------------------------------------------------------
 Steven J. Magnani               "I claim this network for MARS!
 www.digidescorp.com              Earthling, return my space modulator!"
 
 #include <standard.disclaimer>

-----Original Message-----
From: Stefan Reinauer [mailto:stepan at openbios.org] 
Sent: Saturday, November 19, 2005 8:06 AM
To: linuxbios at linuxbios.org
Subject: [LinuxBIOS] CMOS checksums on intel/xe7501devkit


Hi,

is there a reason that the LB checksum used on the intel/xe7501devkit is
completely different (and covers a really small space only)

default LB_CKS_RANGE_START=128
default LB_CKS_RANGE_END=130
default LB_CKS_LOC=131


compared to all the other supported boards:

default LB_CKS_RANGE_START=49
default LB_CKS_RANGE_END=122
default LB_CKS_LOC=123


Regards
Stefan










From rminnich at lanl.gov  Tue Nov 22 00:33:05 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 21 Nov 2005 16:33:05 -0700
Subject: [LinuxBIOS] cleanup
Message-ID: <43825931.7050609@lanl.gov>

I've started cleaning up issue tracker stuff. I just finished my latest, 
and am working epia-m now. I will sign them off. The test will be if 
they at least build.

I will let you know as I do each one.

ron



From rminnich at lanl.gov  Tue Nov 22 00:57:08 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 21 Nov 2005 16:57:08 -0700
Subject: [LinuxBIOS] I just closed issue 28
Message-ID: <43825ED4.6020606@lanl.gov>


patch 04 was superseded by patch 6, but in any event, none of the 
patches took (they were assumed to be -r). Also, the other epia-m item 
(29) is in the tree, so I closed that.


please, folks, if you are resolving these issues, set the status to 
resolved and sign it off in comments.

Here is the rough path for using this tracker (we're still waiting on 
the doc)

login to the issue tracker.
create the issue
describe the problem
upload the file (x.diff)
assign to somebody.

somebody else should close the issue, so:
- get somebody to review.
- annoy us if we don't.


to close
- if it is global impact, scan carefully. take your time
- if it is only one mobo, one person, the person who sent the diff,
    scan carefully but try to get it done soon.
- apply the diff, if it succeeds
	commit and mark the issue resolved, with 'signed-off-by' in the remarks

- if it fails
	mark it deferred and notify the submitter


I am going to try nick barker's patch. It seems somebody is applying 
these and not following up?

ron



From stepan at openbios.org  Tue Nov 22 01:04:23 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue, 22 Nov 2005 01:04:23 +0100
Subject: [LinuxBIOS] I just closed issue 28
In-Reply-To: <43825ED4.6020606@lanl.gov>
References: <43825ED4.6020606@lanl.gov>
Message-ID: <20051122000423.GA24489@openbios.org>

* Ronald G Minnich <rminnich at lanl.gov> [051122 00:57]:
 
> I am going to try nick barker's patch. It seems somebody is applying 
> these and not following up?
 
I grabbed that patch from the mailing list without checking. It might
have been applied already before the issue tracker existed. not sure.

Stefan




From rminnich at lanl.gov  Tue Nov 22 01:13:28 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 21 Nov 2005 17:13:28 -0700
Subject: [LinuxBIOS] barker patch
Message-ID: <438262A8.8060305@lanl.gov>

applied. I don't like one or two things, but they appear harmless. Oh boy.

But this has waited way too long.

First, arch/i386/lib/cpu.c has an #ifdef CONFIG_SMP || CONFIG_IOPIC. 
Somebody want to clean this up? IIRC this was needed due to silliness in 
the VIA?

This has not broken targets AFAIK.

abuild.sh won't run for me -- HOWTO?

I put a HOWTO directory at the top level, I am hoping its appearance 
there will inspire people.

ron



From rminnich at lanl.gov  Tue Nov 22 01:15:48 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 21 Nov 2005 17:15:48 -0700
Subject: [LinuxBIOS] I just closed issue 28
In-Reply-To: <20051122000423.GA24489@openbios.org>
References: <43825ED4.6020606@lanl.gov> <20051122000423.GA24489@openbios.org>
Message-ID: <43826334.3040903@lanl.gov>

Stefan Reinauer wrote:
> * Ronald G Minnich <rminnich at lanl.gov> [051122 00:57]:
>  
> 
>>I am going to try nick barker's patch. It seems somebody is applying 
>>these and not following up?
> 
>  
> I grabbed that patch from the mailing list without checking. It might
> have been applied already before the issue tracker existed. not sure.
> 
> Stefan
> 

it had not been applied. It is now applied.

Will epia-m folks please try this out?

thanks

ron



From rminnich at lanl.gov  Tue Nov 22 01:17:07 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 21 Nov 2005 17:17:07 -0700
Subject: [LinuxBIOS] support for 3G memhole?
Message-ID: <43826383.9090605@lanl.gov>


status, anyone? Where is this?

ron



From rminnich at lanl.gov  Tue Nov 22 01:28:24 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 21 Nov 2005 17:28:24 -0700
Subject: [LinuxBIOS] issue 24
Message-ID: <43826628.9010104@lanl.gov>


Yh Lu, could you please look at issue 24, and respond to stefan's issues?

Yh Lu, I notice in issue 24, you set the idx to 0x10 in the amd k8 
northbridge code, as opposed to the previous 10. Did you change this 
back? What is the current favorite setting? Did we ever decide if this 
was really ok? I've not been tracking all the 'lifting' discussions as I 
should have been -- sorry.

At the least, please, can you review this patch and let's try to get it 
in as a set of patches, not as one giant patch; and, please seperate out 
the board-specific stuff (serengeti) from the global stuff that affects 
everything (northbridge/amdk8).

What's the state of the ********** 16 *************** lnxi patches? did 
someone apply them and not mark them, or do we really have to test them 
all.

I'm going to look at issue 31 next ... maybe this one will be easy.

I was that close to applying Yh Lu's issue 24 patch, but it scared me.

ron



From rminnich at lanl.gov  Tue Nov 22 01:30:59 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 21 Nov 2005 17:30:59 -0700
Subject: [LinuxBIOS] issue 31 is resolved.
Message-ID: <438266C3.6020700@lanl.gov>


I added both 695 and 693 types.

ron



From yinghai.lu at AMD.COM  Tue Nov 22 01:42:14 2005
From: yinghai.lu at AMD.COM (Lu, Yinghai)
Date: Mon, 21 Nov 2005 16:42:14 -0800
Subject: [LinuxBIOS] issue 24
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094943@ssvlexmb2.amd.com>

I sent you my latest tall last week.....for aruma, s2881/s2885.  Only
miss the HW mem hole setting regarding hole_startk == basek....

Regarding apic id lifting
1. final solution will be 
	a. ENABLE_APIC_EXT_ID will decide if lifted apicid
	b. APIC_ID_OFFSET will decide offset
	c. LIFT_BSP_APIC_ID will decide if lift BSP's....

2. Need to put back sth back to cpu_scan_bus...

Giant patch? It is already into two patch....
1. it is in two patch.... one for microcode
2. One for acpi, Serengeti is just for referenc.e

I have lost the sync to the public tree....., later I will send my tar
ball to Stephan and you instead if needed...
	
YH

-----Original Message-----
From: linuxbios-bounces at openbios.org
[mailto:linuxbios-bounces at openbios.org] On Behalf Of Ronald G Minnich
Sent: Monday, November 21, 2005 4:28 PM
To: LinuxBIOS
Subject: [LinuxBIOS] issue 24


Yh Lu, could you please look at issue 24, and respond to stefan's
issues?

Yh Lu, I notice in issue 24, you set the idx to 0x10 in the amd k8 
northbridge code, as opposed to the previous 10. Did you change this 
back? What is the current favorite setting? Did we ever decide if this 
was really ok? I've not been tracking all the 'lifting' discussions as I

should have been -- sorry.

At the least, please, can you review this patch and let's try to get it 
in as a set of patches, not as one giant patch; and, please seperate out

the board-specific stuff (serengeti) from the global stuff that affects 
everything (northbridge/amdk8).

What's the state of the ********** 16 *************** lnxi patches? did 
someone apply them and not mark them, or do we really have to test them 
all.

I'm going to look at issue 31 next ... maybe this one will be easy.

I was that close to applying Yh Lu's issue 24 patch, but it scared me.

ron

-- 
LinuxBIOS mailing list
LinuxBIOS at openbios.org
http://www.openbios.org/mailman/listinfo/linuxbios





From yinghailu at gmail.com  Tue Nov 22 03:05:44 2005
From: yinghailu at gmail.com (yhlu)
Date: Mon, 21 Nov 2005 18:05:44 -0800
Subject: [LinuxBIOS] patch for hole_startk == basek....
Message-ID: <2ea3fae10511211805m3b33af82w1b1005c5407772e0@mail.gmail.com>

stephan, oille,

Please check the memhole patch.

when the hole_startk == one node basek,
1. it will modify base reg instead of hole reg
2. or if K8_HW_MEM_HOLE_SIZE_AUTO =1, then hole_startk will be moved to pri
node mem middle....

this could solve the problem such as
1. two nodes, and first cpu have 2G installed, and memhole size is set to
2G, or mmio_basek is 2G, ( 2 IB installed).
2. four nodes. and every node has 1 G installed, and mmio will be 1G, and
memhole is 1G.....

New Mem hole behavoir will be
1. if K8_HW_MEM_HOLE_SIZEK == 0, then don't set mem_hole
2. if it is set, and it make hole_startk <= mmio_basek, will not reset mem
hole in northbridge.c
3. if it is set, and it make hole_startk > mmio_basek, memhole will be reset
in northbeidge.c
4. if hole_startk met with basek, it will use base reg instead of increase
the hole_sizek to make hole_startk to the middle of pri node.

YH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20051121/2210c504/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1121_memhole.diff
Type: text/x-patch
Size: 20284 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20051121/2210c504/attachment.diff>

From rminnich at lanl.gov  Tue Nov 22 03:40:38 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 21 Nov 2005 19:40:38 -0700
Subject: [LinuxBIOS] patch for hole_startk == basek....
In-Reply-To: <2ea3fae10511211805m3b33af82w1b1005c5407772e0@mail.gmail.com>
References: <2ea3fae10511211805m3b33af82w1b1005c5407772e0@mail.gmail.com>
Message-ID: <43828526.5020900@lanl.gov>

has this been added via the issue tracker? Please, no one, no commits 
unless from the issue tracker. This is really important to get right.

Ying Hai, I apologize for not being on top of your patches. Things got 
crazy the last month with SC 2005 and I am now digging out.

If you could, summarize for me in a seperate post what I should do to 
sync our trees up. I can use the tarball you sent, but I need a little 
direction.

I am trying to wrap up as many of the issues as I can, as fast as I can, 
though I expect the LNXI patches will be tough.

thanks

ron



From rminnich at lanl.gov  Tue Nov 22 03:46:18 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 21 Nov 2005 19:46:18 -0700
Subject: [LinuxBIOS] patch for hole_startk == basek....
In-Reply-To: <2ea3fae10511211805m3b33af82w1b1005c5407772e0@mail.gmail.com>
References: <2ea3fae10511211805m3b33af82w1b1005c5407772e0@mail.gmail.com>
Message-ID: <4382867A.40209@lanl.gov>

I have added this to the issue tracker.

ron



From stepan at openbios.org  Tue Nov 22 09:58:06 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue, 22 Nov 2005 09:58:06 +0100
Subject: [LinuxBIOS] support for 3G memhole?
In-Reply-To: <43826383.9090605@lanl.gov>
References: <43826383.9090605@lanl.gov>
Message-ID: <20051122085805.GD19184@openbios.org>

* Ronald G Minnich <rminnich at lanl.gov> [051122 01:17]:
> 
> status, anyone? Where is this?

Island/Aruma. They have plenty of devices. I think there is a better
solution to this, but I wanted to put it up so it won't get lost.

Stefan




From noodles at earth.li  Tue Nov 22 10:06:21 2005
From: noodles at earth.li (Jonathan McDowell)
Date: Tue, 22 Nov 2005 09:06:21 +0000
Subject: [LinuxBIOS] I just closed issue 28
In-Reply-To: <43825ED4.6020606@lanl.gov>
References: <43825ED4.6020606@lanl.gov>
Message-ID: <20051122090620.GF27589@earth.li>

On Mon, Nov 21, 2005 at 04:57:08PM -0700, Ronald G Minnich wrote:
> patch 04 was superseded by patch 6, but in any event, none of the 
> patches took (they were assumed to be -r). Also, the other epia-m item 
> (29) is in the tree, so I closed that.
> 
> please, folks, if you are resolving these issues, set the status to 
> resolved and sign it off in comments.
... 
> I am going to try nick barker's patch. It seems somebody is applying 
> these and not following up?

The patches in issue 28 were applied before the issue tracker was in use
I believe (I applied them, after posting them to the list for comments).
I added a comment to issue 28 saying as much and that Nick's work built
on them on 2005-11-13.12:57:49

I haven't tried svn today, but I've been running LB SVN 2083 + Nick's
patch and it appears to work fine (though I'm not using the VGA support
as I don't need it).

J.

-- 
If a program is useless, it must be documented.



From ak at suse.de  Tue Nov 22 10:44:18 2005
From: ak at suse.de (Andi Kleen)
Date: Tue, 22 Nov 2005 10:44:18 +0100
Subject: [LinuxBIOS] x86_64: apic id lift patch
In-Reply-To: <86802c440511211431p57628e01o5c8030c4e09deaba@mail.gmail.com>
References: <86802c440511211349t6a0a9d30i60e15fa23b86c49d@mail.gmail.com>
	<20051121220605.GD20775@brahms.suse.de>
	<86802c440511211417h737474fbt57946f4f2396b701@mail.gmail.com>
	<20051121222429.GE20775@brahms.suse.de>
	<86802c440511211431p57628e01o5c8030c4e09deaba@mail.gmail.com>
Message-ID: <20051122094417.GI20775@brahms.suse.de>

On Mon, Nov 21, 2005 at 02:31:44PM -0800, yhlu wrote:
> >
> > max_cores should be 2 here.
> No, For E0 single core, x86_max_cores will be 1, the initial apicid
> can not be shifted to node id....
> >
> >
> > Is there a good reason in the BIOS to not make it contiguous?
> >
> amd8111, if i lift the bsp apic id, the jiffies will not be moving....,

It works for other BIOS, so something must be wrong in your setup.
Better root cause that.

-Andi



From rminnich at lanl.gov  Tue Nov 22 17:40:31 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 22 Nov 2005 09:40:31 -0700
Subject: [LinuxBIOS] support for 3G memhole?
In-Reply-To: <20051122085805.GD19184@openbios.org>
References: <43826383.9090605@lanl.gov> <20051122085805.GD19184@openbios.org>
Message-ID: <438349FF.6080202@lanl.gov>

Stefan Reinauer wrote:
> * Ronald G Minnich <rminnich at lanl.gov> [051122 01:17]:
> 
>>status, anyone? Where is this?
> 
> 
> Island/Aruma. They have plenty of devices. I think there is a better
> solution to this, but I wanted to put it up so it won't get lost.
> 


the code looks ok. So do I commit this one, absent a better solution?

ron



From stepan at openbios.org  Tue Nov 22 17:49:11 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue, 22 Nov 2005 17:49:11 +0100
Subject: [LinuxBIOS] support for 3G memhole?
In-Reply-To: <438349FF.6080202@lanl.gov>
References: <43826383.9090605@lanl.gov> <20051122085805.GD19184@openbios.org>
	<438349FF.6080202@lanl.gov>
Message-ID: <20051122164911.GA7397@openbios.org>

* Ronald G Minnich <rminnich at lanl.gov> [051122 17:40]:
> Stefan Reinauer wrote:
> >* Ronald G Minnich <rminnich at lanl.gov> [051122 01:17]:
> >
> >>status, anyone? Where is this?
> >
> >
> >Island/Aruma. They have plenty of devices. I think there is a better
> >solution to this, but I wanted to put it up so it won't get lost.
> >
> 
> 
> the code looks ok. So do I commit this one, absent a better solution?
 
The code hard codes the three gig memory hole for all systems. Which
is maybe not what we want. 

I think https://www.openbios.org/roundup/linuxbios/issue33 might be
another approach for the problem. Yinghai?


-- Stefan





From yinghailu at gmail.com  Tue Nov 22 17:55:58 2005
From: yinghailu at gmail.com (yhlu)
Date: Tue, 22 Nov 2005 08:55:58 -0800
Subject: [LinuxBIOS] x86_64: apic id lift patch
In-Reply-To: <20051122094417.GI20775@brahms.suse.de>
References: <86802c440511211349t6a0a9d30i60e15fa23b86c49d@mail.gmail.com>
	<20051121220605.GD20775@brahms.suse.de>
	<86802c440511211417h737474fbt57946f4f2396b701@mail.gmail.com>
	<20051121222429.GE20775@brahms.suse.de>
	<86802c440511211431p57628e01o5c8030c4e09deaba@mail.gmail.com>
	<20051122094417.GI20775@brahms.suse.de>
Message-ID: <2ea3fae10511220855n4ea29b1fpf32b0d919c1df39b@mail.gmail.com>

OK, but the patch make your code more generic and also it support E0 single
core...
 YH

 On 11/22/05, Andi Kleen <ak at suse.de> wrote:
>
> On Mon, Nov 21, 2005 at 02:31:44PM -0800, yhlu wrote:
> > >
> > > max_cores should be 2 here.
> > No, For E0 single core, x86_max_cores will be 1, the initial apicid
> > can not be shifted to node id....
> > >
> > >
> > > Is there a good reason in the BIOS to not make it contiguous?
> > >
> > amd8111, if i lift the bsp apic id, the jiffies will not be moving....,
>
> It works for other BIOS, so something must be wrong in your setup.
> Better root cause that.
>
> -Andi
>
> --
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20051122/ebc764cb/attachment.html>

From yinghailu at gmail.com  Tue Nov 22 18:01:13 2005
From: yinghailu at gmail.com (yhlu)
Date: Tue, 22 Nov 2005 09:01:13 -0800
Subject: [LinuxBIOS] support for 3G memhole?
In-Reply-To: <20051122164911.GA7397@openbios.org>
References: <43826383.9090605@lanl.gov> <20051122085805.GD19184@openbios.org>
	<438349FF.6080202@lanl.gov> <20051122164911.GA7397@openbios.org>
Message-ID: <2ea3fae10511220901r3a8fa64br2c7626144203a59a@mail.gmail.com>

there are three ways for your problem
1. pref64 really 64 bit, and above 4G...
2. use base reg instead of hole reg
3. auto increase hole sizek...
 1, depend if it kernel driver support 64 pref.
2, and 3 is in the patch..., if your kernel is too old, you may use 3
only....
 YH


 On 11/22/05, Stefan Reinauer <stepan at openbios.org> wrote:
>
> * Ronald G Minnich <rminnich at lanl.gov> [051122 17:40]:
> > Stefan Reinauer wrote:
> > >* Ronald G Minnich <rminnich at lanl.gov> [051122 01:17]:
> > >
> > >>status, anyone? Where is this?
> > >
> > >
> > >Island/Aruma. They have plenty of devices. I think there is a better
> > >solution to this, but I wanted to put it up so it won't get lost.
> > >
> >
> >
> > the code looks ok. So do I commit this one, absent a better solution?
>
> The code hard codes the three gig memory hole for all systems. Which
> is maybe not what we want.
>
> I think https://www.openbios.org/roundup/linuxbios/issue33 might be
> another approach for the problem. Yinghai?
>
>
> -- Stefan
>
>
>
> --
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20051122/1e536001/attachment.html>

From rminnich at lanl.gov  Tue Nov 22 17:41:17 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 22 Nov 2005 09:41:17 -0700
Subject: [LinuxBIOS] I just closed issue 28
In-Reply-To: <20051122090620.GF27589@earth.li>
References: <43825ED4.6020606@lanl.gov> <20051122090620.GF27589@earth.li>
Message-ID: <43834A2D.7000702@lanl.gov>

Jonathan McDowell wrote:

> I haven't tried svn today, but I've been running LB SVN 2083 + Nick's
> patch and it appears to work fine (though I'm not using the VGA support
> as I don't need it).
> 


thanks for the feedback, if you can, please do an svn update and let me 
know.

I'll try to do same today for sc 520

ron




From rminnich at lanl.gov  Wed Nov 23 00:45:48 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 22 Nov 2005 16:45:48 -0700
Subject: [LinuxBIOS] issue 25: amd k8 microcode support
Message-ID: <4383ADAC.1060506@lanl.gov>

I have committed this. It was waiting too long. It caused no problems 
for building arima/hdama once I corrected a few typos.
Signed-off-by: Ronald G. Minnich


let me know if there are troubles. Will the first person to test this on 
real hardware please change status to resolved, instead of testing.

Stefan, can we have status items of 'builds ok'? It would help.

thanks

ron




From rminnich at lanl.gov  Wed Nov 23 05:32:26 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 22 Nov 2005 21:32:26 -0700
Subject: [LinuxBIOS] issue 20, island aruma update
Message-ID: <4383F0DA.3030909@lanl.gov>

stepan, this one looks harmless to me, any changes since you submitted a 
month ago?

ron



From ollie at lanl.gov  Wed Nov 23 05:45:33 2005
From: ollie at lanl.gov (Li-Ta Lo)
Date: Tue, 22 Nov 2005 21:45:33 -0700
Subject: [LinuxBIOS] issue 25: amd k8 microcode support
In-Reply-To: <4383ADAC.1060506@lanl.gov>
References: <4383ADAC.1060506@lanl.gov>
Message-ID: <1132721133.7747.2.camel@logarithm.lanl.gov>

On Tue, 2005-11-22 at 16:45 -0700, Ronald G Minnich wrote:
> I have committed this. It was waiting too long. It caused no problems 
> for building arima/hdama once I corrected a few typos.
> Signed-off-by: Ronald G. Minnich
> 
> 

Did you actually committed it? From the web page, the latest patch level
is 2091 which is the FSF address. SVN update shows the same thing.

> let me know if there are troubles. Will the first person to test this on 
> real hardware please change status to resolved, instead of testing.
> 

Does this include the apid id stuff as well? AFIAK we need at least
a function in that patch to compile Tyan boards.

> Stefan, can we have status items of 'builds ok'? It would help.
> 
> thanks
> 
> ron
> 
> 
-- 
Li-Ta Lo <ollie at lanl.gov>
Los Alamos National Lab




From rminnich at gmail.com  Wed Nov 23 05:55:39 2005
From: rminnich at gmail.com (ron minnich)
Date: Tue, 22 Nov 2005 21:55:39 -0700
Subject: [LinuxBIOS] abuild result
Message-ID: <13426df10511222055r38fc8b33ta48082e4b1fb8804@mail.gmail.com>

oh, wow, what a mess. There's a lot to fix still. We'll be looking at each
of these in turn, to try to get them to build. The last batch of patches
from people left the tree in a very unhealthy state.

We're going to have to watch this a lot more closely. If we can't improve
the situation somehow, the only thing I can think of to do is limit people
to sending in patches via the issue tracker, and shrinking the set of people
who can commit down to a very small circle. Based on what I'm seeing here,
the current setup is not working. I have not wanted to do this as we here at
LANL don't have tons of free time to monitor patches, but the current
situation can not continue.

I think the earlier suggestion, of requiring positive evidence that abuild
works after a patch, might be right. only problem -- abulid is making
mistakes. The digital logic msm586 bulid fails in abuild, and works fine
otherwise. oops.

thanks

ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20051122/0026830c/attachment.html>

From rminnich at gmail.com  Wed Nov 23 05:58:26 2005
From: rminnich at gmail.com (ron minnich)
Date: Tue, 22 Nov 2005 21:58:26 -0700
Subject: [LinuxBIOS] issue 25: amd k8 microcode support
In-Reply-To: <1132721133.7747.2.camel@logarithm.lanl.gov>
References: <4383ADAC.1060506@lanl.gov>
	<1132721133.7747.2.camel@logarithm.lanl.gov>
Message-ID: <13426df10511222058r5c4fd6alf955a55a1876ae5f@mail.gmail.com>

On 11/22/05, Li-Ta Lo <ollie at lanl.gov> wrote:
>
>
> Did you actually committed it? From the web page, the latest patch level
> is 2091 which is the FSF address. SVN update shows the same thing.



my mistake, and thanks, ollie. It is now commited.


> Does this include the apid id stuff as well? AFIAK we need at least
> a function in that patch to compile Tyan boards.



this is purely the microcode patch.

 thanks

ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20051122/a058a416/attachment.html>

From yinghailu at gmail.com  Wed Nov 23 06:02:38 2005
From: yinghailu at gmail.com (yhlu)
Date: Tue, 22 Nov 2005 21:02:38 -0800
Subject: [LinuxBIOS] issue 25: amd k8 microcode support
In-Reply-To: <13426df10511222058r5c4fd6alf955a55a1876ae5f@mail.gmail.com>
References: <4383ADAC.1060506@lanl.gov>
	<1132721133.7747.2.camel@logarithm.lanl.gov>
	<13426df10511222058r5c4fd6alf955a55a1876ae5f@mail.gmail.com>
Message-ID: <2ea3fae10511222102y783655d1k36ff39347988af62@mail.gmail.com>

ron,

1. you missed microcode_rev_c.h, microcode_rev_d.h, microcode_rev_e.h

2. you didn't use my latest that seperate model_fxx_update_microcode.c from
model_fxx_init.c

do you need me  do that for you?

YH

On 11/22/05, ron minnich <rminnich at gmail.com> wrote:
>
>
>
> On 11/22/05, Li-Ta Lo <ollie at lanl.gov> wrote:
> >
> >
> > Did you actually committed it? From the web page, the latest patch level
> > is 2091 which is the FSF address. SVN update shows the same thing.
>
>
>
> my mistake, and thanks, ollie. It is now commited.
>
>
> > Does this include the apid id stuff as well? AFIAK we need at least
> > a function in that patch to compile Tyan boards.
>
>
>
> this is purely the microcode patch.
>
>  thanks
>
> ron
>
>
> --
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20051122/041f1356/attachment.html>

From ollie at lanl.gov  Wed Nov 23 06:02:35 2005
From: ollie at lanl.gov (Li-Ta Lo)
Date: Tue, 22 Nov 2005 22:02:35 -0700 (MST)
Subject: [LinuxBIOS] issue 25: amd k8 microcode support
In-Reply-To: <13426df10511222058r5c4fd6alf955a55a1876ae5f@mail.gmail.com>
References: <4383ADAC.1060506@lanl.gov> 
	<1132721133.7747.2.camel@logarithm.lanl.gov>
	<13426df10511222058r5c4fd6alf955a55a1876ae5f@mail.gmail.com>
Message-ID: <38401.128.165.0.81.1132722155.squirrel@webmail.lanl.gov>


>
>> Does this include the apid id stuff as well? AFIAK we need at least
>> a function in that patch to compile Tyan boards.
>
>
>
> this is purely the microcode patch.
>

I will try to find out the get_apic_id() patch and commit it.
Without it, none of the Tyan targets can be built.

BTW, I have a minor change to the mptable.c for s2881, should I
put it into the issue tracker and get sign off by someone else?

Ollie




From ollie at lanl.gov  Wed Nov 23 06:04:46 2005
From: ollie at lanl.gov (Li-Ta Lo)
Date: Tue, 22 Nov 2005 22:04:46 -0700 (MST)
Subject: [LinuxBIOS] issue 25: amd k8 microcode support
In-Reply-To: <2ea3fae10511222102y783655d1k36ff39347988af62@mail.gmail.com>
References: <4383ADAC.1060506@lanl.gov> 
	<1132721133.7747.2.camel@logarithm.lanl.gov> 
	<13426df10511222058r5c4fd6alf955a55a1876ae5f@mail.gmail.com>
	<2ea3fae10511222102y783655d1k36ff39347988af62@mail.gmail.com>
Message-ID: <38581.128.165.0.81.1132722286.squirrel@webmail.lanl.gov>

> ron,
>
> 1. you missed microcode_rev_c.h, microcode_rev_d.h, microcode_rev_e.h
>
> 2. you didn't use my latest that seperate model_fxx_update_microcode.c
> from
> model_fxx_init.c
>
> do you need me  do that for you?
>

Could you send the CAR enabling and get_apic_id patch again?

Ollie




From ollie at lanl.gov  Wed Nov 23 06:07:50 2005
From: ollie at lanl.gov (Li-Ta Lo)
Date: Tue, 22 Nov 2005 22:07:50 -0700 (MST)
Subject: [LinuxBIOS] abuild result
In-Reply-To: <13426df10511222055r38fc8b33ta48082e4b1fb8804@mail.gmail.com>
References: <13426df10511222055r38fc8b33ta48082e4b1fb8804@mail.gmail.com>
Message-ID: <38732.128.165.0.81.1132722470.squirrel@webmail.lanl.gov>


>
> I think the earlier suggestion, of requiring positive evidence that abuild
> works after a patch, might be right. only problem -- abulid is making
> mistakes. The digital logic msm586 bulid fails in abuild, and works fine
> otherwise. oops.
>

I think abuild should use the target config file as possible instead of
generating its own unrealistic target.

Ollie




From rminnich at gmail.com  Wed Nov 23 06:10:55 2005
From: rminnich at gmail.com (ron minnich)
Date: Tue, 22 Nov 2005 22:10:55 -0700
Subject: [LinuxBIOS] issue 25: amd k8 microcode support
In-Reply-To: <2ea3fae10511222102y783655d1k36ff39347988af62@mail.gmail.com>
References: <4383ADAC.1060506@lanl.gov>
	<1132721133.7747.2.camel@logarithm.lanl.gov>
	<13426df10511222058r5c4fd6alf955a55a1876ae5f@mail.gmail.com>
	<2ea3fae10511222102y783655d1k36ff39347988af62@mail.gmail.com>
Message-ID: <13426df10511222110v43ea2816n548d56b27a5e6cfd@mail.gmail.com>

On 11/22/05, yhlu <yinghailu at gmail.com> wrote:
>
> ron,
>
> 1. you missed microcode_rev_c.h, microcode_rev_d.h, microcode_rev_e.h



fixed.

2. you didn't use my latest that seperate model_fxx_update_microcode.c from
> model_fxx_init.c



put a patch for this in the issue tracker. Let's start trying to do this
correctly.

I'm digging through this mess and it's not easy. If you have a new patch
that outdates one in the issue tracker, it's a good idea to change the
status of the issue.

thanks

ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20051122/b9041f41/attachment.html>

From rminnich at gmail.com  Wed Nov 23 06:12:13 2005
From: rminnich at gmail.com (ron minnich)
Date: Tue, 22 Nov 2005 22:12:13 -0700
Subject: [LinuxBIOS] issue 25: amd k8 microcode support
In-Reply-To: <38401.128.165.0.81.1132722155.squirrel@webmail.lanl.gov>
References: <4383ADAC.1060506@lanl.gov>
	<1132721133.7747.2.camel@logarithm.lanl.gov>
	<13426df10511222058r5c4fd6alf955a55a1876ae5f@mail.gmail.com>
	<38401.128.165.0.81.1132722155.squirrel@webmail.lanl.gov>
Message-ID: <13426df10511222112j454d3950h39ba42d6c27a9af8@mail.gmail.com>

On 11/22/05, Li-Ta Lo <ollie at lanl.gov> wrote:
>
>
>
> BTW, I have a minor change to the mptable.c for s2881, should I
> put it into the issue tracker and get sign off by someone else?



Your call. If it's really one file, and it's that simple, and you are sure
it only affects that single target, I think it is ok.

ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20051122/0089a05a/attachment.html>

From yinghailu at gmail.com  Wed Nov 23 06:12:57 2005
From: yinghailu at gmail.com (yhlu)
Date: Tue, 22 Nov 2005 21:12:57 -0800
Subject: [LinuxBIOS] issue 25: amd k8 microcode support
In-Reply-To: <13426df10511222110v43ea2816n548d56b27a5e6cfd@mail.gmail.com>
References: <4383ADAC.1060506@lanl.gov>
	<1132721133.7747.2.camel@logarithm.lanl.gov>
	<13426df10511222058r5c4fd6alf955a55a1876ae5f@mail.gmail.com>
	<2ea3fae10511222102y783655d1k36ff39347988af62@mail.gmail.com>
	<13426df10511222110v43ea2816n548d56b27a5e6cfd@mail.gmail.com>
Message-ID: <2ea3fae10511222112g368bd5aag9f975a0f4831608f@mail.gmail.com>

I will send out another patch that seperate it....

YH

On 11/22/05, ron minnich <rminnich at gmail.com> wrote:
>
>
>
> On 11/22/05, yhlu <yinghailu at gmail.com> wrote:
> >
> > ron,
> >
> > 1. you missed microcode_rev_c.h, microcode_rev_d.h, microcode_rev_e.h
>
>
>
> fixed.
>
> 2. you didn't use my latest that seperate model_fxx_update_microcode.c
> > from model_fxx_init.c
>
>
>
> put a patch for this in the issue tracker. Let's start trying to do this
> correctly.
>
> I'm digging through this mess and it's not easy. If you have a new patch
> that outdates one in the issue tracker, it's a good idea to change the
> status of the issue.
>
> thanks
>
> ron
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20051122/926ff754/attachment.html>

From rminnich at gmail.com  Wed Nov 23 06:13:06 2005
From: rminnich at gmail.com (ron minnich)
Date: Tue, 22 Nov 2005 22:13:06 -0700
Subject: [LinuxBIOS] abuild result
In-Reply-To: <38732.128.165.0.81.1132722470.squirrel@webmail.lanl.gov>
References: <13426df10511222055r38fc8b33ta48082e4b1fb8804@mail.gmail.com>
	<38732.128.165.0.81.1132722470.squirrel@webmail.lanl.gov>
Message-ID: <13426df10511222113k4678b7bdif0b15f16be84879d@mail.gmail.com>

On 11/22/05, Li-Ta Lo <ollie at lanl.gov> wrote:
>
>
> I think abuild should use the target config file as possible instead of
> generating its own unrealistic target.



yes, stepan, is that doable?

ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20051122/2b67bbe7/attachment.html>

From yinghailu at gmail.com  Wed Nov 23 06:46:29 2005
From: yinghailu at gmail.com (yhlu)
Date: Tue, 22 Nov 2005 21:46:29 -0800
Subject: [LinuxBIOS] issue 25: amd k8 microcode support
In-Reply-To: <2ea3fae10511222112g368bd5aag9f975a0f4831608f@mail.gmail.com>
References: <4383ADAC.1060506@lanl.gov>
	<1132721133.7747.2.camel@logarithm.lanl.gov>
	<13426df10511222058r5c4fd6alf955a55a1876ae5f@mail.gmail.com>
	<2ea3fae10511222102y783655d1k36ff39347988af62@mail.gmail.com>
	<13426df10511222110v43ea2816n548d56b27a5e6cfd@mail.gmail.com>
	<2ea3fae10511222112g368bd5aag9f975a0f4831608f@mail.gmail.com>
Message-ID: <2ea3fae10511222146r3368f4a6qe463a619701fb1e5@mail.gmail.com>

add issue 34 about that.

YH

On 11/22/05, yhlu <yinghailu at gmail.com> wrote:
>
> I will send out another patch that seperate it....
>
> YH
>
> On 11/22/05, ron minnich <rminnich at gmail.com> wrote:
> >
> >
> >
> > On 11/22/05, yhlu <yinghailu at gmail.com > wrote:
> > >
> > > ron,
> > >
> > > 1. you missed microcode_rev_c.h, microcode_rev_d.h, microcode_rev_e.h
> >
> >
> >
> > fixed.
> >
> > 2. you didn't use my latest that seperate model_fxx_update_microcode.c
> > > from model_fxx_init.c
> >
> >
> >
> > put a patch for this in the issue tracker. Let's start trying to do this
> > correctly.
> >
> > I'm digging through this mess and it's not easy. If you have a new patch
> > that outdates one in the issue tracker, it's a good idea to change the
> > status of the issue.
> >
> > thanks
> >
> > ron
> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20051122/7dbcd153/attachment.html>

From rminnich at gmail.com  Wed Nov 23 07:12:02 2005
From: rminnich at gmail.com (ron minnich)
Date: Tue, 22 Nov 2005 23:12:02 -0700
Subject: [LinuxBIOS] abuild.sh issue
Message-ID: <13426df10511222212h280821d6l60995572c4067fec@mail.gmail.com>

stefan, I have a patch to abuild.sh on the issue tracker. This patch works
as follows:
If there is a targets/vendor/mainboard/Config-abuild.lb
that will be used instead of the auto-generated one. See what you think.
See example
targets/digitallogic/msm586seg/Config-abuild.lb

This is how it looks.
 ~/src/LinuxBIOSv2/util/abuild/abuild.sh  -t digitallogic/msm586seg
~/src/LinuxBIOSv2/
Processing mainboard/digitallogic/msm586seg (i386: ok)
Used existing test target
/home/rminnich/src/LinuxBIOSv2//targets/digitallogic/msm586seg/Config-
abuild.lb
  Creating builddir...ok
  Compiling image ..ok.

The msm586seg now builds correctly in abuild. if this patch is ok, I will
apply it or you can.

Also, note that abuild won't create linuxbios-builds if you specify -t ...
this is a bug.

ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20051122/6064a1d8/attachment.html>

From stepan at openbios.org  Wed Nov 23 10:56:04 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Wed, 23 Nov 2005 10:56:04 +0100
Subject: [LinuxBIOS] abuild.sh issue
In-Reply-To: <13426df10511222212h280821d6l60995572c4067fec@mail.gmail.com>
References: <13426df10511222212h280821d6l60995572c4067fec@mail.gmail.com>
Message-ID: <20051123095604.GA21094@openbios.org>

* ron minnich <rminnich at gmail.com> [051123 07:12]:
> stefan, I have a patch to abuild.sh on the issue tracker. This patch works as
> follows:
> If there is a targets/vendor/mainboard/Config-abuild.lb
> that will be used instead of the auto-generated one. See what you think.
[..]
> The msm586seg now builds correctly in abuild. if this patch is ok, I
> will apply it or you can.
> Also, note that abuild won't create linuxbios-builds if you specify -t
> ... this is a bug.
> 
> ron

The patch is fine. We definitely need something like this to get around
the build specifics of certain boards and the files in targets are not
suitable for this. 

What's the issue with -t ?

./abuild.sh -t island/aruma
Processing mainboard/island/aruma (i386: ok, we're amd64)
  Creating config file... ok
  Creating builddir...ok
  Compiling image ..FAILED! Log excerpt:
:0.0:
too few registers
..

So it basically seems to work, except the current svn is broken.





From stepan at openbios.org  Wed Nov 23 11:08:54 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Wed, 23 Nov 2005 11:08:54 +0100
Subject: [LinuxBIOS] abuild result
In-Reply-To: <13426df10511222055r38fc8b33ta48082e4b1fb8804@mail.gmail.com>
References: <13426df10511222055r38fc8b33ta48082e4b1fb8804@mail.gmail.com>
Message-ID: <20051123100854.GA28982@openbios.org>

* ron minnich <rminnich at gmail.com> [051123 05:55]:
> oh, wow, what a mess. There's a lot to fix still. We'll be looking at each of
> these in turn, to try to get them to build. The last batch of patches from
> people left the tree in a very unhealthy state.
> 
> We're going to have to watch this a lot more closely. If we can't improve the
> situation somehow, the only thing I can think of to do is limit people to
> sending in patches via the issue tracker, and shrinking the set of people who
> can commit down to a very small circle. Based on what I'm seeing here, the
> current setup is not working. I have not wanted to do this as we here at LANL
> don't have tons of free time to monitor patches, but the current situation can
> not continue.
> 
> I think the earlier suggestion, of requiring positive evidence that abuild
> works after a patch, might be right. only problem -- abulid is making mistakes.
> The digital logic msm586 bulid fails in abuild, and works fine otherwise. oops.

This is mostly because abuild assumes a certain image size while some of
the builds break if you choose a too small or too big image. IIRC the DL
MSM586 breaks because it doesn't build with 512k rom images.

Stefan




From stepan at openbios.org  Wed Nov 23 11:11:07 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Wed, 23 Nov 2005 11:11:07 +0100
Subject: [LinuxBIOS] abuild result
In-Reply-To: <13426df10511222113k4678b7bdif0b15f16be84879d@mail.gmail.com>
References: <13426df10511222055r38fc8b33ta48082e4b1fb8804@mail.gmail.com>
	<38732.128.165.0.81.1132722470.squirrel@webmail.lanl.gov>
	<13426df10511222113k4678b7bdif0b15f16be84879d@mail.gmail.com>
Message-ID: <20051123101107.GB28982@openbios.org>

* ron minnich <rminnich at gmail.com> [051123 06:13]:
> 
> 
> On 11/22/05, Li-Ta Lo <ollie at lanl.gov> wrote:
> 
> 
>     I think abuild should use the target config file as possible instead of
>     generating its own unrealistic target.
> 
> 
> 
> yes, stepan, is that doable?
> 
> ron

Your approach of having a seperate abuild configuration file is a lot
better since the target configuration files tend to be very specific and
require certain payloads in certain very developer specific locations.

We could check a couple of binary payloads in the tree or into a
different tree that is supposed to sit next to LinuxBIOSv2 or something
and have that referenced by default so we don't have to use /dev/null or
/etc/hosts as payload.

Stefan





From stepan at openbios.org  Wed Nov 23 14:03:45 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Wed, 23 Nov 2005 14:03:45 +0100
Subject: [LinuxBIOS] issue 20, island aruma update
In-Reply-To: <4383F0DA.3030909@lanl.gov>
References: <4383F0DA.3030909@lanl.gov>
Message-ID: <20051123130345.GA28320@openbios.org>

* Ronald G Minnich <rminnich at lanl.gov> [051123 05:32]:
> stepan, this one looks harmless to me, any changes since you submitted a 
> month ago?

It is. But I am trying to move them to the newest tree, including cache
as ram. So I suggest we have this wait until I get the current tree up
to date and merge that stuff in then.

Stefan





From rminnich at lanl.gov  Wed Nov 23 16:32:07 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 23 Nov 2005 08:32:07 -0700
Subject: [LinuxBIOS] issue 20, island aruma update
In-Reply-To: <20051123130345.GA28320@openbios.org>
References: <4383F0DA.3030909@lanl.gov> <20051123130345.GA28320@openbios.org>
Message-ID: <43848B77.6090707@lanl.gov>

Stefan Reinauer wrote:
> * Ronald G Minnich <rminnich at lanl.gov> [051123 05:32]:
> 
>>stepan, this one looks harmless to me, any changes since you submitted a 
>>month ago?
> 
> 
> It is. But I am trying to move them to the newest tree, including cache
> as ram. So I suggest we have this wait until I get the current tree up
> to date and merge that stuff in then.

what do you see as the most important issues to work on while we get CAR 
  going everywhere?

ron



From rminnich at lanl.gov  Wed Nov 23 16:35:11 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 23 Nov 2005 08:35:11 -0700
Subject: [LinuxBIOS] abuild result
In-Reply-To: <20051123100854.GA28982@openbios.org>
References: <13426df10511222055r38fc8b33ta48082e4b1fb8804@mail.gmail.com>
	<20051123100854.GA28982@openbios.org>
Message-ID: <43848C2F.9090508@lanl.gov>

Stefan Reinauer wrote:

> This is mostly because abuild assumes a certain image size while some of
> the builds break if you choose a too small or too big image. IIRC the DL
> MSM586 breaks because it doesn't build with 512k rom images.

yes,  but that still leads to false negatives. MSM586 builds on on 256K 
ROMs, and that's all that you can use anyway. See my later patch to 
abuild and see what you think.

ron




From rminnich at lanl.gov  Wed Nov 23 16:37:41 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 23 Nov 2005 08:37:41 -0700
Subject: [LinuxBIOS] abuild.sh issue
In-Reply-To: <20051123095604.GA21094@openbios.org>
References: <13426df10511222212h280821d6l60995572c4067fec@mail.gmail.com>
	<20051123095604.GA21094@openbios.org>
Message-ID: <43848CC5.1030900@lanl.gov>

Stefan Reinauer wrote:

> What's the issue with -t ?
> 
> ./abuild.sh -t island/aruma
> Processing mainboard/island/aruma (i386: ok, we're amd64)
>   Creating config file... ok
>   Creating builddir...ok
>   Compiling image ..FAILED! Log excerpt:
> :0.0:
> too few registers
> ..
> 
> So it basically seems to work, except the current svn is broken.

was the linuxbios-builds directory there already? If it is not, I get an 
  error.

I will commit that patch, then.

ron





From stepan at openbios.org  Wed Nov 23 17:17:29 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Wed, 23 Nov 2005 17:17:29 +0100
Subject: [LinuxBIOS] abuild.sh issue
In-Reply-To: <43848CC5.1030900@lanl.gov>
References: <13426df10511222212h280821d6l60995572c4067fec@mail.gmail.com>
	<20051123095604.GA21094@openbios.org> <43848CC5.1030900@lanl.gov>
Message-ID: <20051123161729.GA32685@openbios.org>

* Ronald G Minnich <rminnich at lanl.gov> [051123 16:37]:
> Stefan Reinauer wrote:
> 
> >What's the issue with -t ?
> >
> >./abuild.sh -t island/aruma
> >Processing mainboard/island/aruma (i386: ok, we're amd64)
> >  Creating config file... ok
> >  Creating builddir...ok
> >  Compiling image ..FAILED! Log excerpt:
> >:0.0:
> >too few registers
> >..
> >
> >So it basically seems to work, except the current svn is broken.
> 
> was the linuxbios-builds directory there already? If it is not, I get an 
>  error.

weird. which motherboard? I just deleted the directory to be sure and it
seems to work.
 
> I will commit that patch, then.
 
Fine, thanks!

Stefan





From rminnich at lanl.gov  Wed Nov 23 17:17:47 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 23 Nov 2005 09:17:47 -0700
Subject: [LinuxBIOS] abuild.sh issue
In-Reply-To: <20051123161729.GA32685@openbios.org>
References: <13426df10511222212h280821d6l60995572c4067fec@mail.gmail.com>
	<20051123095604.GA21094@openbios.org> <43848CC5.1030900@lanl.gov>
	<20051123161729.GA32685@openbios.org>
Message-ID: <4384962B.1010202@lanl.gov>

Stefan Reinauer wrote:

> 
> weird. which motherboard? I just deleted the directory to be sure and it
> seems to work.

I'll try it again. Abuild patch comitted.

on to trying to get us back to life ...

ron



From rminnich at lanl.gov  Wed Nov 23 17:25:41 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 23 Nov 2005 09:25:41 -0700
Subject: [LinuxBIOS] what's up with linxi-patch-13?
Message-ID: <43849805.1050302@lanl.gov>


has this been applied? What's the story here.

thanks

ron



From smithbone at gmail.com  Wed Nov 23 17:40:04 2005
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 23 Nov 2005 10:40:04 -0600
Subject: [LinuxBIOS] issue 20, island aruma update
In-Reply-To: <43848B77.6090707@lanl.gov>
References: <4383F0DA.3030909@lanl.gov> <20051123130345.GA28320@openbios.org>
	<43848B77.6090707@lanl.gov>
Message-ID: <8a0c36780511230840t42f57c22ubeb0664375db3a28@mail.gmail.com>

>
> what do you see as the most important issues to work on while we get CAR
>   going everywhere?
>

What do you plan to do for platforms like VIA, geode or other embedded
setups which may never support CAR?  Or at least it will be awhile
until they do.

--
Richard A. Smith



From rminnich at lanl.gov  Wed Nov 23 17:58:13 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 23 Nov 2005 09:58:13 -0700
Subject: [LinuxBIOS] x86_64: apic id lift patch
In-Reply-To: <20051121220605.GD20775@brahms.suse.de>
References: <86802c440511211349t6a0a9d30i60e15fa23b86c49d@mail.gmail.com>
	<20051121220605.GD20775@brahms.suse.de>
Message-ID: <43849FA5.4020201@lanl.gov>

Andi Kleen wrote:

> Please note there is a high barrier of entry for any kind of BIOS workarounds -
> in particular for LinuxBIOS i'm not very motivated because you guys can
> just fix the BIOS.

Hi Andi, just wanted to let you know, that I do agree that this is a 
good policy in general. In terms of LinuxBIOS, now that we're starting 
to approach 2M nodes out in the field, fixing it is geting a wee bit 
harder. Again, I'm not disagreeing with the point above, just mentioning 
that "just fix the BIOS" is not as easy as it was when we had all the 
LinuxBIOS nodes in the world -- all 13 of them -- in my lab :-)

This APIC lifting thing has been a real mess, and IIRC what really 
pushed it originally was the island aruma, with its 32 PCI busses. It's 
amazing how PC architectures always seem to involve over-running 
bit-fields -- 4 bits, 6 bits, 8 bits, 10 bits, whatever.

Getting it all to work has involved lots of backtracking, as we found 
that fixing this problem HERE broke that legacy system THERE -- where 
legacy seems to mean "more than 3 weeks old". The mail traffic on the 
linuxbios list on this issue has been interesting, and in some cases, 
more than I can keep up with. Part of the issue is that we all have 
mutually exclusive hardware, and we keep running into hardware 
limitations that don't seem to be known to even the guys who make the 
chips. So we think we have the permanent fix, and somebody pops up to 
report we just broke their mainboard -- and they're the only ones with 
that mainboard, so testing is hard.

At the same time, we seem to be treading in territory where the fuctory 
BIOSes have not yet been. We're in the weird position, at times, of 
finding things out before the proprietary BIOSes get there.

Sometimes the ease of updating the BIOS can cause troubles you don't 
expect. Fuctory BIOSes seem to count on infrequent updates, forked code 
bases, and so on, so that you have to update each mainboard source base 
individually -- they have the disadvantage of a forked code base, but 
the one advantage is that a mod to fix one platform won't ever break 
another.

At some point I had understood that linux was going to be able to 
function without resorting to SRAT tables -- has that changed? Is this 
patch really intrusive enough that it is not acceptable? The issue is 
that we get LinuxBIOS right on a platform, and then some new rev of the 
CPU comes along, and LinuxBIOS gets updated in a way that is not 
obviously going to cause trouble for the older stuff -- but then it 
does, for some other reason. I am hoping this apic lifting will settle 
down in the next while, but it's been hard.

thanks

ron



From rminnich at lanl.gov  Wed Nov 23 18:01:21 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 23 Nov 2005 10:01:21 -0700
Subject: [LinuxBIOS] issue 20, island aruma update
In-Reply-To: <8a0c36780511230840t42f57c22ubeb0664375db3a28@mail.gmail.com>
References: <4383F0DA.3030909@lanl.gov> <20051123130345.GA28320@openbios.org>	
	<43848B77.6090707@lanl.gov>
	<8a0c36780511230840t42f57c22ubeb0664375db3a28@mail.gmail.com>
Message-ID: <4384A061.1020402@lanl.gov>

Richard Smith wrote:

> What do you plan to do for platforms like VIA, geode or other embedded
> setups which may never support CAR?  Or at least it will be awhile
> until they do.

I want to deprecate ROMCC as much as we possibly can. Over time, we're 
going to find all systems supporting CAR, so in the long run, ROMCC will 
be gone. Of course, as long as we need ROMCC, it will be there; but if a 
system can use CAR, it should never use ROMCC!

I really think ROMCC is one of the neatest things I've ever seen, but I 
would still like to get it out of linuxbios, now that we know how CAR 
works. I don't like having a C compiler as part of LinuxBIOS -- we have 
enough code to maintain.

Also, it's not clear that CAR won't work on these other platforms, now 
that we know the "CAR trick". It has not been tested. I suspect it will 
work on VIA.

ron



From stepan at openbios.org  Wed Nov 23 18:13:29 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Wed, 23 Nov 2005 18:13:29 +0100
Subject: [LinuxBIOS] issue 20, island aruma update
In-Reply-To: <43848B77.6090707@lanl.gov>
References: <4383F0DA.3030909@lanl.gov> <20051123130345.GA28320@openbios.org>
	<43848B77.6090707@lanl.gov>
Message-ID: <20051123171329.GA13080@openbios.org>

* Ronald G Minnich <rminnich at lanl.gov> [051123 16:32]:
> >It is. But I am trying to move them to the newest tree, including cache
> >as ram. So I suggest we have this wait until I get the current tree up
> >to date and merge that stuff in then.
> 
> what do you see as the most important issues to work on while we get CAR 
>  going everywhere?
 
I think we need to decide which of the LNXI patches are going to stay in
as is and give them a resolved. Leaving them open maybe helps the guilty
conscience of some people here but it does not get us a step ahead. 

We rather need to close them and open issues describing the problems
that we have _now_, like "This function is missing for all motherboard
builds in this list: xxx,yyy,zzz" and then we can decide if for example
CAR is an appropriate solution for the problem or if we have to
add/readd a function or if we check the aruma changes in the code and
try to move them to all the other mainboards as well..


when we have the tree in it's old well-known marvelous state again we
should require that every patch that goes into the tree from the tracker
is proven to break nothing by attaching an abuild of the whole tree
before and after the patch. This is 10min work for that one developer
per patch, but safes weeks for all of us.


Stefan





From yinghailu at gmail.com  Wed Nov 23 18:19:59 2005
From: yinghailu at gmail.com (yhlu)
Date: Wed, 23 Nov 2005 09:19:59 -0800
Subject: [LinuxBIOS] x86_64: apic id lift patch
In-Reply-To: <43849FA5.4020201@lanl.gov>
References: <86802c440511211349t6a0a9d30i60e15fa23b86c49d@mail.gmail.com>
	<20051121220605.GD20775@brahms.suse.de> <43849FA5.4020201@lanl.gov>
Message-ID: <2ea3fae10511230919l4d9829d8j3ce5d820b74074d1@mail.gmail.com>

sth about SRAT in LinuxBIOS,  I have put SRAT dynamically support in
LinuxBIOS, but the whole acpi support still need dsdt, current we only have
dsdt for AMD chipset in LB. And we can not have the access the dsdt asl from
Nvidia chipset yet...

YH


On 11/23/05, Ronald G Minnich <rminnich at lanl.gov> wrote:
>
> Andi Kleen wrote:
>
> > Please note there is a high barrier of entry for any kind of BIOS
> workarounds -
> > in particular for LinuxBIOS i'm not very motivated because you guys can
> > just fix the BIOS.
>
> Hi Andi, just wanted to let you know, that I do agree that this is a
> good policy in general. In terms of LinuxBIOS, now that we're starting
> to approach 2M nodes out in the field, fixing it is geting a wee bit
> harder. Again, I'm not disagreeing with the point above, just mentioning
> that "just fix the BIOS" is not as easy as it was when we had all the
> LinuxBIOS nodes in the world -- all 13 of them -- in my lab :-)
>
> This APIC lifting thing has been a real mess, and IIRC what really
> pushed it originally was the island aruma, with its 32 PCI busses. It's
> amazing how PC architectures always seem to involve over-running
> bit-fields -- 4 bits, 6 bits, 8 bits, 10 bits, whatever.
>
> Getting it all to work has involved lots of backtracking, as we found
> that fixing this problem HERE broke that legacy system THERE -- where
> legacy seems to mean "more than 3 weeks old". The mail traffic on the
> linuxbios list on this issue has been interesting, and in some cases,
> more than I can keep up with. Part of the issue is that we all have
> mutually exclusive hardware, and we keep running into hardware
> limitations that don't seem to be known to even the guys who make the
> chips. So we think we have the permanent fix, and somebody pops up to
> report we just broke their mainboard -- and they're the only ones with
> that mainboard, so testing is hard.
>
> At the same time, we seem to be treading in territory where the fuctory
> BIOSes have not yet been. We're in the weird position, at times, of
> finding things out before the proprietary BIOSes get there.
>
> Sometimes the ease of updating the BIOS can cause troubles you don't
> expect. Fuctory BIOSes seem to count on infrequent updates, forked code
> bases, and so on, so that you have to update each mainboard source base
> individually -- they have the disadvantage of a forked code base, but
> the one advantage is that a mod to fix one platform won't ever break
> another.
>
> At some point I had understood that linux was going to be able to
> function without resorting to SRAT tables -- has that changed? Is this
> patch really intrusive enough that it is not acceptable? The issue is
> that we get LinuxBIOS right on a platform, and then some new rev of the
> CPU comes along, and LinuxBIOS gets updated in a way that is not
> obviously going to cause trouble for the older stuff -- but then it
> does, for some other reason. I am hoping this apic lifting will settle
> down in the next while, but it's been hard.
>
> thanks
>
> ron
>
> --
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20051123/1e3716ed/attachment.html>

From stepan at openbios.org  Wed Nov 23 18:25:50 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Wed, 23 Nov 2005 18:25:50 +0100
Subject: [LinuxBIOS] what's up with linxi-patch-13?
In-Reply-To: <43849805.1050302@lanl.gov>
References: <43849805.1050302@lanl.gov>
Message-ID: <20051123172550.GB16002@openbios.org>

* Ronald G Minnich <rminnich at lanl.gov> [051123 17:25]:
> 
> has this been applied? What's the story here.
 
IIRC all lnxi patches have been applied, but they STILL lack the
according entries in the issue tracker.

Stefan
 



From ak at suse.de  Wed Nov 23 18:35:05 2005
From: ak at suse.de (Andi Kleen)
Date: Wed, 23 Nov 2005 18:35:05 +0100
Subject: [LinuxBIOS] x86_64: apic id lift patch
In-Reply-To: <43849FA5.4020201@lanl.gov>
References: <86802c440511211349t6a0a9d30i60e15fa23b86c49d@mail.gmail.com>
	<20051121220605.GD20775@brahms.suse.de> <43849FA5.4020201@lanl.gov>
Message-ID: <20051123173504.GK20775@brahms.suse.de>

> At the same time, we seem to be treading in territory where the fuctory 
> BIOSes have not yet been. We're in the weird position, at times, of 
> finding things out before the proprietary BIOSes get there.

You're saying that Arima machine only runs with LinuxBIOS so far?

> 
> Sometimes the ease of updating the BIOS can cause troubles you don't 
> expect. Fuctory BIOSes seem to count on infrequent updates, forked code 
> bases, and so on, so that you have to update each mainboard source base 
> individually -- they have the disadvantage of a forked code base, but 
> the one advantage is that a mod to fix one platform won't ever break 
> another.
> 
> At some point I had understood that linux was going to be able to 
> function without resorting to SRAT tables -- has that changed? Is this 

SRAT is definitely the wave of the future.  I'm going to keep
the old code working as long as it's relatively cleanly possible.
But this needs to make some assumptions, and in particular your
discontiguous APIC IDs broke that. I don't plan to try to handle
every weird case in this case - if your setup is really
weird use SRAT.

Regarding the BSP 0 - you probably just have a stupid bug
somewhere that breaks the timer interrupt. I don't know
of any hardware issue that would prevent the timer interrupt
going to a APIC ID != 0. There are some troubles with timer
interrupts, but they are different issues. IMHO the discontig
APIC IDs was just a workaround because you didn't want to fix
the interrupt routing properly, with the burden on the kernel.

You have two options now:

- Trace down why interrupt 0 doesn't work with BSP LAPIC != 0
and fix that. 
- Provide SRAT.

First is probably better, although the second also wouldn't hurt.


> patch really intrusive enough that it is not acceptable? The issue is 

Yes it complicates the logic enough and makes it more fragile,
which would be a long term maintenance issue. The only way 
to keep the fallback code alive at all is to keep it simple
and clean.


-Andi



From ak at suse.de  Wed Nov 23 18:36:36 2005
From: ak at suse.de (Andi Kleen)
Date: Wed, 23 Nov 2005 18:36:36 +0100
Subject: [LinuxBIOS] x86_64: apic id lift patch
In-Reply-To: <2ea3fae10511230919l4d9829d8j3ce5d820b74074d1@mail.gmail.com>
References: <86802c440511211349t6a0a9d30i60e15fa23b86c49d@mail.gmail.com>
	<20051121220605.GD20775@brahms.suse.de> <43849FA5.4020201@lanl.gov>
	<2ea3fae10511230919l4d9829d8j3ce5d820b74074d1@mail.gmail.com>
Message-ID: <20051123173636.GL20775@brahms.suse.de>

On Wed, Nov 23, 2005 at 09:19:59AM -0800, yhlu wrote:
> sth about SRAT in LinuxBIOS,  I have put SRAT dynamically support in
> LinuxBIOS, but the whole acpi support still need dsdt, current we only have
> dsdt for AMD chipset in LB. And we can not have the access the dsdt asl from
> Nvidia chipset yet...

You probably don't need most of it. Just a basic SRAT table (no AML methods)
and enough to keep the ACPI interpreter from aborting early.

Or alternatively just fix the bug that caused you to go with discontig
APICs in the first place.

-Andi



From yinghailu at gmail.com  Wed Nov 23 18:40:28 2005
From: yinghailu at gmail.com (yhlu)
Date: Wed, 23 Nov 2005 09:40:28 -0800
Subject: [LinuxBIOS] x86_64: apic id lift patch
In-Reply-To: <20051123173636.GL20775@brahms.suse.de>
References: <86802c440511211349t6a0a9d30i60e15fa23b86c49d@mail.gmail.com>
	<20051121220605.GD20775@brahms.suse.de> <43849FA5.4020201@lanl.gov>
	<2ea3fae10511230919l4d9829d8j3ce5d820b74074d1@mail.gmail.com>
	<20051123173636.GL20775@brahms.suse.de>
Message-ID: <2ea3fae10511230940t1f6a1757lf885a2559be6f0dc@mail.gmail.com>

is there any way to make the kernel use apci but still use pci irq
routing from mptable?

YH

On 11/23/05, Andi Kleen <ak at suse.de> wrote:
> On Wed, Nov 23, 2005 at 09:19:59AM -0800, yhlu wrote:
> > sth about SRAT in LinuxBIOS,  I have put SRAT dynamically support in
> > LinuxBIOS, but the whole acpi support still need dsdt, current we only have
> > dsdt for AMD chipset in LB. And we can not have the access the dsdt asl from
> > Nvidia chipset yet...
>
> You probably don't need most of it. Just a basic SRAT table (no AML methods)
> and enough to keep the ACPI interpreter from aborting early.
>
> Or alternatively just fix the bug that caused you to go with discontig
> APICs in the first place.
>
> -Andi
>



From yinghailu at gmail.com  Wed Nov 23 18:43:12 2005
From: yinghailu at gmail.com (yhlu)
Date: Wed, 23 Nov 2005 09:43:12 -0800
Subject: [LinuxBIOS] x86_64: apic id lift patch
In-Reply-To: <20051123173504.GK20775@brahms.suse.de>
References: <86802c440511211349t6a0a9d30i60e15fa23b86c49d@mail.gmail.com>
	<20051121220605.GD20775@brahms.suse.de> <43849FA5.4020201@lanl.gov>
	<20051123173504.GK20775@brahms.suse.de>
Message-ID: <2ea3fae10511230943y5f697eb8sdbf891497fa8b88f@mail.gmail.com>

fallback code it not needed, because for AMD optern, at that point you can
figure out the node id and core id from initial apic id exactly....

YH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20051123/40b07f4e/attachment.html>

From ak at suse.de  Wed Nov 23 18:50:42 2005
From: ak at suse.de (Andi Kleen)
Date: Wed, 23 Nov 2005 18:50:42 +0100
Subject: [LinuxBIOS] x86_64: apic id lift patch
In-Reply-To: <2ea3fae10511230943y5f697eb8sdbf891497fa8b88f@mail.gmail.com>
References: <86802c440511211349t6a0a9d30i60e15fa23b86c49d@mail.gmail.com>
	<20051121220605.GD20775@brahms.suse.de> <43849FA5.4020201@lanl.gov>
	<20051123173504.GK20775@brahms.suse.de>
	<2ea3fae10511230943y5f697eb8sdbf891497fa8b88f@mail.gmail.com>
Message-ID: <20051123175042.GM20775@brahms.suse.de>

On Wed, Nov 23, 2005 at 09:43:12AM -0800, yhlu wrote:
> fallback code it not needed, because for AMD optern, at that point you can
> figure out the node id and core id from initial apic id exactly....

AFAIK there is no foolproof way to figure out the HT node id from the
initial APIC ID. One is in the Northbridge, the other is in CPUID,
but there is no directly visible connection. 

If you know one please share it

-Andi



From yinghailu at gmail.com  Wed Nov 23 19:01:51 2005
From: yinghailu at gmail.com (yhlu)
Date: Wed, 23 Nov 2005 10:01:51 -0800
Subject: [LinuxBIOS] x86_64: apic id lift patch
In-Reply-To: <20051123175042.GM20775@brahms.suse.de>
References: <86802c440511211349t6a0a9d30i60e15fa23b86c49d@mail.gmail.com>
	<20051121220605.GD20775@brahms.suse.de> <43849FA5.4020201@lanl.gov>
	<20051123173504.GK20775@brahms.suse.de>
	<2ea3fae10511230943y5f697eb8sdbf891497fa8b88f@mail.gmail.com>
	<20051123175042.GM20775@brahms.suse.de>
Message-ID: <2ea3fae10511231001r47fcfa64r8afa8bd5552479d0@mail.gmail.com>

NB_CFG bit 54 for E0 stepping later can be set.

When it is set
the initial apic id will be
node0/core0 : 0
node0/core1 : 1
node1/core0 : 2
node1/core1 : 3

So you can shift the initial apic id to the node id, but the problem
is you need to have right cores_vir,  because for single you need to
use 2 to shift instead of 1 the core num that you read from msr.

For LinuxBIOS, we go further, that we use NB_CFG bit 54 directly,
instead of check cpu version, because only E0 later can be set.

please check the code in LinuxBIOS that we are using to get node id...

YH

static inline unsigned int read_nb_cfg_54(void)
{
        msr_t msr;
        msr = rdmsr(NB_CFG_MSR);
        return ( ( msr.hi >> (54-32)) & 1);
}

struct node_core_id {
        unsigned nodeid;
        unsigned coreid;
};

static inline unsigned get_initial_apicid(void)
{
        return ((cpuid_ebx(1) >> 24) & 0xf);
}

static inline struct node_core_id get_node_core_id(unsigned nb_cfg_54)
{
        struct node_core_id id;
        //    get the apicid via cpuid(1) ebx[27:24]
        if( nb_cfg_54) {
                //   when NB_CFG[54] is set, nodid = ebx[27:25],
coreid = ebx[24]
                id.coreid = (cpuid_ebx(1) >> 24) & 0xf;
                id.nodeid = (id.coreid>>1);
                id.coreid &= 1;
        }
        else
        {
                // when NB_CFG[54] is clear, nodeid = ebx[26:24],
coreid = ebx[27]
                id.nodeid = (cpuid_ebx(1) >> 24) & 0xf;
                id.coreid = (id.nodeid>>3);
                id.nodeid &= 7;
        }
        return id;
}

static inline unsigned get_core_num(void)
{
        return (cpuid_ecx(0x80000008) & 0xff);
}

static inline struct node_core_id get_node_core_id_x(void) {

        return get_node_core_id( read_nb_cfg_54() ); // for pre_e0()
nb_cfg_54 always be 0
}



From stepan at openbios.org  Wed Nov 23 19:17:08 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Wed, 23 Nov 2005 19:17:08 +0100
Subject: [LinuxBIOS] x86_64: apic id lift patch
In-Reply-To: <20051123173636.GL20775@brahms.suse.de>
References: <86802c440511211349t6a0a9d30i60e15fa23b86c49d@mail.gmail.com>
	<20051121220605.GD20775@brahms.suse.de> <43849FA5.4020201@lanl.gov>
	<2ea3fae10511230919l4d9829d8j3ce5d820b74074d1@mail.gmail.com>
	<20051123173636.GL20775@brahms.suse.de>
Message-ID: <20051123181708.GB27398@openbios.org>

* Andi Kleen <ak at suse.de> [051123 18:36]:
> You probably don't need most of it. Just a basic SRAT table (no AML methods)
> and enough to keep the ACPI interpreter from aborting early.
> 
> Or alternatively just fix the bug that caused you to go with discontig
> APICs in the first place.
 
Andi,

I really like your insisting way, but what we tried to express is that
there is hardware that just forces you to have discontiguous APIC ids,
so either you disable parts of the hardware or you are forced to do
nasty things.

Wrt the ACPI tables a good rule of thumb is that if you start to have
some of them you have to have them all. For example if you have a logical
subset of them and try to cover the rest with PIRQ or MPTABLE you will
fail because Linux moans about incorrect tables without even looking at
them. And no, there is no reason for not reading a HPET table when
there's no MADT available. And no, I'm not going to send a fix since I'm
really not motivated to dig into that code any minute more than
absolutely necessary.

I agree that there's a reason that the Linux ACPI code is as it is, but 
in fact as it is a reaction to zillions of buggy bioses it is not always
the best solution to have clean firmware not working with it "fixed" to
behave like the others out there. 

Stefan





From stepan at openbios.org  Wed Nov 23 19:18:04 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Wed, 23 Nov 2005 19:18:04 +0100
Subject: [LinuxBIOS] x86_64: apic id lift patch
In-Reply-To: <2ea3fae10511230940t1f6a1757lf885a2559be6f0dc@mail.gmail.com>
References: <86802c440511211349t6a0a9d30i60e15fa23b86c49d@mail.gmail.com>
	<20051121220605.GD20775@brahms.suse.de> <43849FA5.4020201@lanl.gov>
	<2ea3fae10511230919l4d9829d8j3ce5d820b74074d1@mail.gmail.com>
	<20051123173636.GL20775@brahms.suse.de>
	<2ea3fae10511230940t1f6a1757lf885a2559be6f0dc@mail.gmail.com>
Message-ID: <20051123181804.GC27398@openbios.org>

* yhlu <yinghailu at gmail.com> [051123 18:40]:
> is there any way to make the kernel use apci but still use pci irq
> routing from mptable?

Yes, don't provide any of MADT, DSDT, FADT.

   Stefan




From yinghailu at gmail.com  Wed Nov 23 19:22:18 2005
From: yinghailu at gmail.com (yhlu)
Date: Wed, 23 Nov 2005 10:22:18 -0800
Subject: [LinuxBIOS] x86_64: apic id lift patch
In-Reply-To: <20051123181804.GC27398@openbios.org>
References: <86802c440511211349t6a0a9d30i60e15fa23b86c49d@mail.gmail.com>
	<20051121220605.GD20775@brahms.suse.de> <43849FA5.4020201@lanl.gov>
	<2ea3fae10511230919l4d9829d8j3ce5d820b74074d1@mail.gmail.com>
	<20051123173636.GL20775@brahms.suse.de>
	<2ea3fae10511230940t1f6a1757lf885a2559be6f0dc@mail.gmail.com>
	<20051123181804.GC27398@openbios.org>
Message-ID: <2ea3fae10511231022g3a690870qf4564b085c24cb20@mail.gmail.com>

only RSDT+SRAT?, I will try it....

YH

On 11/23/05, Stefan Reinauer <stepan at openbios.org> wrote:
> * yhlu <yinghailu at gmail.com> [051123 18:40]:
> > is there any way to make the kernel use apci but still use pci irq
> > routing from mptable?
>
> Yes, don't provide any of MADT, DSDT, FADT.
>
>    Stefan
>
>



From stepan at openbios.org  Wed Nov 23 19:28:31 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Wed, 23 Nov 2005 19:28:31 +0100
Subject: [LinuxBIOS] x86_64: apic id lift patch
In-Reply-To: <20051123173504.GK20775@brahms.suse.de>
References: <86802c440511211349t6a0a9d30i60e15fa23b86c49d@mail.gmail.com>
	<20051121220605.GD20775@brahms.suse.de> <43849FA5.4020201@lanl.gov>
	<20051123173504.GK20775@brahms.suse.de>
Message-ID: <20051123182831.GA31870@openbios.org>

* Andi Kleen <ak at suse.de> [051123 18:35]:
> > At the same time, we seem to be treading in territory where the fuctory 
> > BIOSes have not yet been. We're in the weird position, at times, of 
> > finding things out before the proprietary BIOSes get there.
> 
> You're saying that Arima machine only runs with LinuxBIOS so far?

Island/Aruma. The only production level firmware is LinuxBIOS, indeed.

Others have failed.

Stefan






From yinghailu at gmail.com  Wed Nov 23 19:35:19 2005
From: yinghailu at gmail.com (yhlu)
Date: Wed, 23 Nov 2005 10:35:19 -0800
Subject: [LinuxBIOS] x86_64: apic id lift patch
In-Reply-To: <2ea3fae10511231022g3a690870qf4564b085c24cb20@mail.gmail.com>
References: <86802c440511211349t6a0a9d30i60e15fa23b86c49d@mail.gmail.com>
	<20051121220605.GD20775@brahms.suse.de> <43849FA5.4020201@lanl.gov>
	<2ea3fae10511230919l4d9829d8j3ce5d820b74074d1@mail.gmail.com>
	<20051123173636.GL20775@brahms.suse.de>
	<2ea3fae10511230940t1f6a1757lf885a2559be6f0dc@mail.gmail.com>
	<20051123181804.GC27398@openbios.org>
	<2ea3fae10511231022g3a690870qf4564b085c24cb20@mail.gmail.com>
Message-ID: <2ea3fae10511231035y5466a793y829688f5532ad32e@mail.gmail.com>

it doesn't work. At that case must disable the apci in kernel...(acpi=off)

YH

On 11/23/05, yhlu <yinghailu at gmail.com> wrote:
> only RSDT+SRAT?, I will try it....
>
> YH
>
> On 11/23/05, Stefan Reinauer <stepan at openbios.org> wrote:
> > * yhlu <yinghailu at gmail.com> [051123 18:40]:
> > > is there any way to make the kernel use apci but still use pci irq
> > > routing from mptable?
> >
> > Yes, don't provide any of MADT, DSDT, FADT.
> >
> >    Stefan
> >
> >
>



From rminnich at lanl.gov  Wed Nov 23 21:14:14 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 23 Nov 2005 13:14:14 -0700
Subject: [LinuxBIOS] isue 26
In-Reply-To: <20051123170631.GB3119@openbios.org>
References: <438492B0.5020408@lanl.gov> <20051123170631.GB3119@openbios.org>
Message-ID: <4384CD96.2020306@lanl.gov>

Stefan Reinauer wrote:
> * Ronald G Minnich <rminnich at lanl.gov> [051123 17:02]:
> 
>>reenable car
>>
>>it looks like it will apply, but what do you all think? is this thing ok?
> 
>  
> I definitely want it in, but it still fails on island/aruma. 
> 
> I don't consider this a blocker though, since I won't switch the
> customer to the new tree unless CAR works anyways so I would appreciate
> having it in the tree to settle down and mature.
> 
> Stefan
> 
> 

I'm leaning to applying the CAR patch (issue 26). This only affects k8. 
If anyone has a problem with this, let me know ASAP, else I will apply 
it later today.

I think I've resolved about 6 issues, I hope to get more done in the 
weeks to come. My goals is to have no unresolved issues by dec. 15.

ron



From rminnich at lanl.gov  Wed Nov 23 21:23:41 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 23 Nov 2005 13:23:41 -0700
Subject: [LinuxBIOS] x86_64: apic id lift patch
In-Reply-To: <2ea3fae10511230919l4d9829d8j3ce5d820b74074d1@mail.gmail.com>
References: <86802c440511211349t6a0a9d30i60e15fa23b86c49d@mail.gmail.com>	
	<20051121220605.GD20775@brahms.suse.de> <43849FA5.4020201@lanl.gov>
	<2ea3fae10511230919l4d9829d8j3ce5d820b74074d1@mail.gmail.com>
Message-ID: <4384CFCD.9010304@lanl.gov>

yhlu wrote:
> sth about SRAT in LinuxBIOS,  I have put SRAT dynamically support in 
> LinuxBIOS, but the whole acpi support still need dsdt, current we only 
> have dsdt for AMD chipset in LB. And we can not have the access the dsdt 
> asl from Nvidia chipset yet...

yeah, this is the great thing about ACPI, it has put us into a whole new 
  era of copyrighted stuff. ACPI tables describe hardware, and are 
copyright bios vendors. The question of which ACPI bits we can use in 
linuxbios is unresolved. AMD has committed to open-source ACPI tables, 
but ... what about companies like nvidia? unknown. And, to add to the 
fun, the mainboard vendors don't own their own ACPI tables -- the BIOS 
vendors do. So the mainboard vendor has their hardware design encoded 
into ACPI tables, which are copyright the bios vendor, not the mainboard 
vendor.

ACPI is a looming problem for all the open-source bios efforts out there.

I don't much like ACPI. It's just another mechanism for hiding 
information and limiting its distribution.

ron



From smithbone at gmail.com  Wed Nov 23 21:26:42 2005
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 23 Nov 2005 14:26:42 -0600
Subject: [LinuxBIOS] issue 20, island aruma update
In-Reply-To: <20051123171329.GA13080@openbios.org>
References: <4383F0DA.3030909@lanl.gov> <20051123130345.GA28320@openbios.org>
	<43848B77.6090707@lanl.gov> <20051123171329.GA13080@openbios.org>
Message-ID: <8a0c36780511231226n75189e23p1a78afd50afaf232@mail.gmail.com>

> when we have the tree in it's old well-known marvelous state again we
> should require that every patch that goes into the tree from the tracker
> is proven to break nothing by attaching an abuild of the whole tree
> before and after the patch. This is 10min work for that one developer
> per patch, but safes weeks for all of us.

What do you plan to do for archs that need a cross compiler?

--
Richard A. Smith



From rminnich at lanl.gov  Wed Nov 23 21:26:34 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 23 Nov 2005 13:26:34 -0700
Subject: [LinuxBIOS] x86_64: apic id lift patch
In-Reply-To: <20051123173504.GK20775@brahms.suse.de>
References: <86802c440511211349t6a0a9d30i60e15fa23b86c49d@mail.gmail.com>
	<20051121220605.GD20775@brahms.suse.de> <43849FA5.4020201@lanl.gov>
	<20051123173504.GK20775@brahms.suse.de>
Message-ID: <4384D07A.7030406@lanl.gov>

Andi Kleen wrote:
>>At the same time, we seem to be treading in territory where the fuctory 
>>BIOSes have not yet been. We're in the weird position, at times, of 
>>finding things out before the proprietary BIOSes get there.
> 
> 
> You're saying that Arima machine only runs with LinuxBIOS so far?

The Cray XD-1, opteron-based machine, is linuxbios only. Another 
machine, DRC, can only use linuxbios. Island/Aruma was mentioned. These 
are the three I know of, there may well be others.

DRC used linuxbios because fuctory bios could not configure HT correctly 
in their application.

(well, I know of one other, but can't tell you about it).

ron



From ak at suse.de  Wed Nov 23 21:28:19 2005
From: ak at suse.de (Andi Kleen)
Date: Wed, 23 Nov 2005 21:28:19 +0100
Subject: [LinuxBIOS] [discuss] Re:  x86_64: apic id lift patch
In-Reply-To: <2ea3fae10511231035y5466a793y829688f5532ad32e@mail.gmail.com>
References: <86802c440511211349t6a0a9d30i60e15fa23b86c49d@mail.gmail.com>
	<20051121220605.GD20775@brahms.suse.de> <43849FA5.4020201@lanl.gov>
	<2ea3fae10511230919l4d9829d8j3ce5d820b74074d1@mail.gmail.com>
	<20051123173636.GL20775@brahms.suse.de>
	<2ea3fae10511230940t1f6a1757lf885a2559be6f0dc@mail.gmail.com>
	<20051123181804.GC27398@openbios.org>
	<2ea3fae10511231022g3a690870qf4564b085c24cb20@mail.gmail.com>
	<2ea3fae10511231035y5466a793y829688f5532ad32e@mail.gmail.com>
Message-ID: <20051123202819.GO20775@brahms.suse.de>

On Wed, Nov 23, 2005 at 10:35:19AM -0800, yhlu wrote:
> it doesn't work. At that case must disable the apci in kernel...(acpi=off)

Shouldn't be very hard to fix in the kernel though 
(to use only SRAT and nothing else of ACPI). I can look 
into it if nobody beats me to it

-Andi



From ak at suse.de  Wed Nov 23 21:29:32 2005
From: ak at suse.de (Andi Kleen)
Date: Wed, 23 Nov 2005 21:29:32 +0100
Subject: [LinuxBIOS] [discuss] Re:  x86_64: apic id lift patch
In-Reply-To: <2ea3fae10511231001r47fcfa64r8afa8bd5552479d0@mail.gmail.com>
References: <86802c440511211349t6a0a9d30i60e15fa23b86c49d@mail.gmail.com>
	<20051121220605.GD20775@brahms.suse.de> <43849FA5.4020201@lanl.gov>
	<20051123173504.GK20775@brahms.suse.de>
	<2ea3fae10511230943y5f697eb8sdbf891497fa8b88f@mail.gmail.com>
	<20051123175042.GM20775@brahms.suse.de>
	<2ea3fae10511231001r47fcfa64r8afa8bd5552479d0@mail.gmail.com>
Message-ID: <20051123202932.GP20775@brahms.suse.de>

On Wed, Nov 23, 2005 at 10:01:51AM -0800, yhlu wrote:
> NB_CFG bit 54 for E0 stepping later can be set.

That MSR is not even in my docs. Sounds very stepping specific.
Probably nothing that a kernel should access. The k8topology
code is already far too machine specific and making it more
so would be a mistake.

-Andi



From rminnich at lanl.gov  Wed Nov 23 21:28:33 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 23 Nov 2005 13:28:33 -0700
Subject: [LinuxBIOS] issue 20, island aruma update
In-Reply-To: <8a0c36780511231226n75189e23p1a78afd50afaf232@mail.gmail.com>
References: <4383F0DA.3030909@lanl.gov> <20051123130345.GA28320@openbios.org>	
	<43848B77.6090707@lanl.gov> <20051123171329.GA13080@openbios.org>
	<8a0c36780511231226n75189e23p1a78afd50afaf232@mail.gmail.com>
Message-ID: <4384D0F1.5000803@lanl.gov>

Richard Smith wrote:
>>when we have the tree in it's old well-known marvelous state again we
>>should require that every patch that goes into the tree from the tracker
>>is proven to break nothing by attaching an abuild of the whole tree
>>before and after the patch. This is 10min work for that one developer
>>per patch, but safes weeks for all of us.
> 
> 
> What do you plan to do for archs that need a cross compiler?

cross-compiler is a solved problem. If you are sure that your work only 
impacts, e.g., K8, then we can subset the build requirement.

ron



From rminnich at lanl.gov  Wed Nov 23 21:29:11 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 23 Nov 2005 13:29:11 -0700
Subject: [LinuxBIOS] what's up with linxi-patch-13?
In-Reply-To: <20051123172550.GB16002@openbios.org>
References: <43849805.1050302@lanl.gov> <20051123172550.GB16002@openbios.org>
Message-ID: <4384D117.3040007@lanl.gov>

Stefan Reinauer wrote:
> * Ronald G Minnich <rminnich at lanl.gov> [051123 17:25]:
> 
>>has this been applied? What's the story here.
> 
>  
> IIRC all lnxi patches have been applied, but they STILL lack the
> according entries in the issue tracker.

well, I know that 14 was not needed, and so I resolved it as rejected.

ron



From rminnich at lanl.gov  Wed Nov 23 21:29:50 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 23 Nov 2005 13:29:50 -0700
Subject: [LinuxBIOS] [discuss] Re:  x86_64: apic id lift patch
In-Reply-To: <20051123202932.GP20775@brahms.suse.de>
References: <86802c440511211349t6a0a9d30i60e15fa23b86c49d@mail.gmail.com>
	<20051121220605.GD20775@brahms.suse.de> <43849FA5.4020201@lanl.gov>
	<20051123173504.GK20775@brahms.suse.de>
	<2ea3fae10511230943y5f697eb8sdbf891497fa8b88f@mail.gmail.com>
	<20051123175042.GM20775@brahms.suse.de>
	<2ea3fae10511231001r47fcfa64r8afa8bd5552479d0@mail.gmail.com>
	<20051123202932.GP20775@brahms.suse.de>
Message-ID: <4384D13E.6070804@lanl.gov>

Andi Kleen wrote:

> 
> That MSR is not even in my docs. Sounds very stepping specific.

or your docs predate that MSR?

ron




From ak at suse.de  Wed Nov 23 21:34:56 2005
From: ak at suse.de (Andi Kleen)
Date: Wed, 23 Nov 2005 21:34:56 +0100
Subject: [LinuxBIOS] [discuss] Re:  x86_64: apic id lift patch
In-Reply-To: <4384CFCD.9010304@lanl.gov>
References: <86802c440511211349t6a0a9d30i60e15fa23b86c49d@mail.gmail.com>
	<20051121220605.GD20775@brahms.suse.de> <43849FA5.4020201@lanl.gov>
	<2ea3fae10511230919l4d9829d8j3ce5d820b74074d1@mail.gmail.com>
	<4384CFCD.9010304@lanl.gov>
Message-ID: <20051123203456.GQ20775@brahms.suse.de>

On Wed, Nov 23, 2005 at 01:23:41PM -0700, Ronald G Minnich wrote:
> yeah, this is the great thing about ACPI, it has put us into a whole new 
>  era of copyrighted stuff. ACPI tables describe hardware, and are 
> copyright bios vendors. The question of which ACPI bits we can use in 
> linuxbios is unresolved. AMD has committed to open-source ACPI tables, 
> but ... what about companies like nvidia? unknown. And, to add to the 
> fun, the mainboard vendors don't own their own ACPI tables -- the BIOS 
> vendors do. So the mainboard vendor has their hardware design encoded 
> into ACPI tables, which are copyright the bios vendor, not the mainboard 
> vendor.

I don't think it's as bad as you describe. Once you have a free reference
DSL it shouldn't be very difficult to vary it for specific
platforms. I guess that is what the proprietary BIOS writers are doing too. 

Some systems have very complex ACPI tables, but for others they 
can be quite simple and a lot of the complexity can be just ignored.

I suppose you could even write a generic translator from mptables to ACPI 
tables (although I suspect more and more setups cannot be described
in the old tables) 

BTW there are other reasons now to support ACPI, like the MCFG tables
that are needed for extended config space accesses (necessary
e.g. for PCI Express error handling) or the HPET table for the HPET timer.

-Andi



From stepan at openbios.org  Wed Nov 23 21:39:38 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Wed, 23 Nov 2005 21:39:38 +0100
Subject: [LinuxBIOS] issue 20, island aruma update
In-Reply-To: <8a0c36780511231226n75189e23p1a78afd50afaf232@mail.gmail.com>
References: <4383F0DA.3030909@lanl.gov> <20051123130345.GA28320@openbios.org>
	<43848B77.6090707@lanl.gov> <20051123171329.GA13080@openbios.org>
	<8a0c36780511231226n75189e23p1a78afd50afaf232@mail.gmail.com>
Message-ID: <20051123203938.GA27171@openbios.org>

* Richard Smith <smithbone at gmail.com> [051123 21:26]:
> > when we have the tree in it's old well-known marvelous state again we
> > should require that every patch that goes into the tree from the tracker
> > is proven to break nothing by attaching an abuild of the whole tree
> > before and after the patch. This is 10min work for that one developer
> > per patch, but safes weeks for all of us.
> 
> What do you plan to do for archs that need a cross compiler?

Hm. We could put out a close description of how to build cross compilers
for the suite or allow developers to submit their patches and get the
results to it from the linuxbios.org machine.

Stefan





From stepan at openbios.org  Wed Nov 23 21:41:22 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Wed, 23 Nov 2005 21:41:22 +0100
Subject: [LinuxBIOS] issue 20, island aruma update
In-Reply-To: <4384D0F1.5000803@lanl.gov>
References: <4383F0DA.3030909@lanl.gov> <20051123130345.GA28320@openbios.org>
	<43848B77.6090707@lanl.gov> <20051123171329.GA13080@openbios.org>
	<8a0c36780511231226n75189e23p1a78afd50afaf232@mail.gmail.com>
	<4384D0F1.5000803@lanl.gov>
Message-ID: <20051123204122.GB27171@openbios.org>

* Ronald G Minnich <rminnich at lanl.gov> [051123 21:28]:
> Richard Smith wrote:
> >What do you plan to do for archs that need a cross compiler?
> 
> cross-compiler is a solved problem. If you are sure that your work only 
> impacts, e.g., K8, then we can subset the build requirement.

I think the implicit question was: "Do we guys have to build cross
compilers now for every new platform LinuxBIOS supports before we can
contribute?" 

And probably the question should be no, without having to check code in
;-)

Stefan






From rminnich at lanl.gov  Wed Nov 23 21:43:08 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 23 Nov 2005 13:43:08 -0700
Subject: [LinuxBIOS] issue 20, island aruma update
In-Reply-To: <20051123203938.GA27171@openbios.org>
References: <4383F0DA.3030909@lanl.gov> <20051123130345.GA28320@openbios.org>
	<43848B77.6090707@lanl.gov> <20051123171329.GA13080@openbios.org>
	<8a0c36780511231226n75189e23p1a78afd50afaf232@mail.gmail.com>
	<20051123203938.GA27171@openbios.org>
Message-ID: <4384D45C.6070809@lanl.gov>

Stefan Reinauer wrote:
> * Richard Smith <smithbone at gmail.com> [051123 21:26]:
> 
>>>when we have the tree in it's old well-known marvelous state again we
>>>should require that every patch that goes into the tree from the tracker
>>>is proven to break nothing by attaching an abuild of the whole tree
>>>before and after the patch. This is 10min work for that one developer
>>>per patch, but safes weeks for all of us.
>>
>>What do you plan to do for archs that need a cross compiler?
> 
> 
> Hm. We could put out a close description of how to build cross compilers
> for the suite or allow developers to submit their patches and get the
> results to it from the linuxbios.org machine.
> 
> Stefan
> 
> 

The thing is, it's just not possible to be casual about patches any 
more, as we were in the past. We've had the megapatch mess on our hands 
for almost 2 months, the tree is still a mess, and it's very hard to dig 
out. A BIOS is a much more sensitive piece of software than an operating 
system. You screw up the BIOS, you've got a lot of dead hardware on your 
hands and there is no way out. I think placing some sort of burden of 
proof on committers is a good idea. We've got to get this under control.

ron



From smithbone at gmail.com  Wed Nov 23 21:49:41 2005
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 23 Nov 2005 14:49:41 -0600
Subject: [LinuxBIOS] issue 20, island aruma update
In-Reply-To: <20051123204122.GB27171@openbios.org>
References: <4383F0DA.3030909@lanl.gov> <20051123130345.GA28320@openbios.org>
	<43848B77.6090707@lanl.gov> <20051123171329.GA13080@openbios.org>
	<8a0c36780511231226n75189e23p1a78afd50afaf232@mail.gmail.com>
	<4384D0F1.5000803@lanl.gov> <20051123204122.GB27171@openbios.org>
Message-ID: <8a0c36780511231249n6f159229l9fc4c84baca014f9@mail.gmail.com>

> I think the implicit question was: "Do we guys have to build cross
> compilers now for every new platform LinuxBIOS supports before we can
> contribute?"
>
> And probably the question should be no, without having to check code in
> ;-)

So I guess you will have to have a "patch master" for each arch who
will sign off that the patch did not break thier compile(s)?  That or
the developer would have to install the cross compiler for all the
archs.

Or possibly a system like Debian has for source packages where auto
builders go and try to build everything and only after it passes all
archs does it get accepted.  You would e-mail your patch to the
autobuilder and it would spit you back a log file.

--
Richard A. Smith



From rminnich at lanl.gov  Wed Nov 23 21:54:31 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 23 Nov 2005 13:54:31 -0700
Subject: [LinuxBIOS] issue 20, island aruma update
In-Reply-To: <8a0c36780511231249n6f159229l9fc4c84baca014f9@mail.gmail.com>
References: <4383F0DA.3030909@lanl.gov> <20051123130345.GA28320@openbios.org>	
	<43848B77.6090707@lanl.gov> <20051123171329.GA13080@openbios.org>	
	<8a0c36780511231226n75189e23p1a78afd50afaf232@mail.gmail.com>	
	<4384D0F1.5000803@lanl.gov> <20051123204122.GB27171@openbios.org>
	<8a0c36780511231249n6f159229l9fc4c84baca014f9@mail.gmail.com>
Message-ID: <4384D707.2080502@lanl.gov>

Richard Smith wrote:

> Or possibly a system like Debian has for source packages where auto
> builders go and try to build everything and only after it passes all
> archs does it get accepted.  You would e-mail your patch to the
> autobuilder and it would spit you back a log file.

excellent idea.

ron



From rminnich at lanl.gov  Wed Nov 23 22:00:58 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 23 Nov 2005 14:00:58 -0700
Subject: [LinuxBIOS] isue 26
In-Reply-To: <2ea3fae10511230934t77cd2517pa1e758f3004d274e@mail.gmail.com>
References: <438492B0.5020408@lanl.gov> <20051123170631.GB3119@openbios.org>	
	<2ea3fae10511230926n13f98844vba4a1f3023bbee06@mail.gmail.com>	
	<20051123172934.GC16002@openbios.org>
	<2ea3fae10511230934t77cd2517pa1e758f3004d274e@mail.gmail.com>
Message-ID: <4384D88A.50501@lanl.gov>

I've applied issue 26, restoring CAR. Builds of arima/hdama and 
tyan/2895 are fine. Will test next week.

I hope this doesn't break anyone too much, but this was needed. Man, 
builds without romcc are a lot faster ...

ron



From smithbone at gmail.com  Wed Nov 23 22:04:26 2005
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 23 Nov 2005 15:04:26 -0600
Subject: [LinuxBIOS] issue 20, island aruma update
In-Reply-To: <4384D707.2080502@lanl.gov>
References: <4383F0DA.3030909@lanl.gov> <20051123130345.GA28320@openbios.org>
	<43848B77.6090707@lanl.gov> <20051123171329.GA13080@openbios.org>
	<8a0c36780511231226n75189e23p1a78afd50afaf232@mail.gmail.com>
	<4384D0F1.5000803@lanl.gov> <20051123204122.GB27171@openbios.org>
	<8a0c36780511231249n6f159229l9fc4c84baca014f9@mail.gmail.com>
	<4384D707.2080502@lanl.gov>
Message-ID: <8a0c36780511231304n7bc364e8n3729b9208ee58cd8@mail.gmail.com>

> > Or possibly a system like Debian has for source packages where auto
> > builders go and try to build everything and only after it passes all
> > archs does it get accepted.  You would e-mail your patch to the
> > autobuilder and it would spit you back a log file.
>
> excellent idea.

This all gets you around compile problems but theres still the "Does
it actually work?" issue.  Somehow you have to go verify those changes
actually work on the boards.  Especially if your end goal is to
prevent bricking the hardware.

For that you probally will need some sort of maintainer for each board
or group of boards.

--
Richard A. Smith



From yinghailu at gmail.com  Wed Nov 23 22:06:29 2005
From: yinghailu at gmail.com (yhlu)
Date: Wed, 23 Nov 2005 13:06:29 -0800
Subject: [LinuxBIOS] isue 26
In-Reply-To: <4384D88A.50501@lanl.gov>
References: <438492B0.5020408@lanl.gov> <20051123170631.GB3119@openbios.org>
	<2ea3fae10511230926n13f98844vba4a1f3023bbee06@mail.gmail.com>
	<20051123172934.GC16002@openbios.org>
	<2ea3fae10511230934t77cd2517pa1e758f3004d274e@mail.gmail.com>
	<4384D88A.50501@lanl.gov>
Message-ID: <2ea3fae10511231306haaf964fxe474b0334c4a6f57@mail.gmail.com>

Good, I will polulate to other Tyan MB.

with two way dual core system and with make -j
every MB with CAR only need 6s to build.

Can you look at the acpi, I have seperate that to core, and MB..., in
the isssue tracker...

YH

On 11/23/05, Ronald G Minnich <rminnich at lanl.gov> wrote:
> I've applied issue 26, restoring CAR. Builds of arima/hdama and
> tyan/2895 are fine. Will test next week.
>
> I hope this doesn't break anyone too much, but this was needed. Man,
> builds without romcc are a lot faster ...
>
> ron
>



From rminnich at lanl.gov  Wed Nov 23 22:06:34 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 23 Nov 2005 14:06:34 -0700
Subject: [LinuxBIOS] issue 20, island aruma update
In-Reply-To: <8a0c36780511231304n7bc364e8n3729b9208ee58cd8@mail.gmail.com>
References: <4383F0DA.3030909@lanl.gov> <20051123130345.GA28320@openbios.org>	
	<43848B77.6090707@lanl.gov> <20051123171329.GA13080@openbios.org>	
	<8a0c36780511231226n75189e23p1a78afd50afaf232@mail.gmail.com>	
	<4384D0F1.5000803@lanl.gov> <20051123204122.GB27171@openbios.org>	
	<8a0c36780511231249n6f159229l9fc4c84baca014f9@mail.gmail.com>	
	<4384D707.2080502@lanl.gov>
	<8a0c36780511231304n7bc364e8n3729b9208ee58cd8@mail.gmail.com>
Message-ID: <4384D9DA.7090600@lanl.gov>

Richard Smith wrote:

> For that you probally will need some sort of maintainer for each board
> or group of boards.

I tried that 'board owner' thing on V1 and could NOT get it to work. We 
need some really convenient way for a board owner to say 'my board works 
with release #XXXX" so people can know what svn revs to use.

ron



From stepan at openbios.org  Wed Nov 23 22:09:01 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Wed, 23 Nov 2005 22:09:01 +0100
Subject: [LinuxBIOS] issue 20, island aruma update
In-Reply-To: <8a0c36780511231304n7bc364e8n3729b9208ee58cd8@mail.gmail.com>
References: <4383F0DA.3030909@lanl.gov> <20051123130345.GA28320@openbios.org>
	<43848B77.6090707@lanl.gov> <20051123171329.GA13080@openbios.org>
	<8a0c36780511231226n75189e23p1a78afd50afaf232@mail.gmail.com>
	<4384D0F1.5000803@lanl.gov> <20051123204122.GB27171@openbios.org>
	<8a0c36780511231249n6f159229l9fc4c84baca014f9@mail.gmail.com>
	<4384D707.2080502@lanl.gov>
	<8a0c36780511231304n7bc364e8n3729b9208ee58cd8@mail.gmail.com>
Message-ID: <20051123210901.GA8511@openbios.org>

* Richard Smith <smithbone at gmail.com> [051123 22:04]:
> > > Or possibly a system like Debian has for source packages where auto
> > > builders go and try to build everything and only after it passes all
> > > archs does it get accepted.  You would e-mail your patch to the
> > > autobuilder and it would spit you back a log file.
> >
> > excellent idea.
> 
> This all gets you around compile problems but theres still the "Does
> it actually work?" issue.  Somehow you have to go verify those changes
> actually work on the boards.  Especially if your end goal is to
> prevent bricking the hardware.

Until we have a large distributed cluster of machines connected to
promices we should stick to code reviews and assiduous maintainers.

Stefan




From ollie at lanl.gov  Wed Nov 23 22:09:24 2005
From: ollie at lanl.gov (Li-Ta Lo)
Date: Wed, 23 Nov 2005 14:09:24 -0700
Subject: [LinuxBIOS] isue 26
In-Reply-To: <4384CD96.2020306@lanl.gov>
References: <438492B0.5020408@lanl.gov> <20051123170631.GB3119@openbios.org>
	<4384CD96.2020306@lanl.gov>
Message-ID: <1132780164.5055.4.camel@logarithm.lanl.gov>

On Wed, 2005-11-23 at 13:14 -0700, Ronald G Minnich wrote:
> Stefan Reinauer wrote:
> > * Ronald G Minnich <rminnich at lanl.gov> [051123 17:02]:
> > 
> >>reenable car
> >>
> >>it looks like it will apply, but what do you all think? is this thing ok?
> > 
> >  
> > I definitely want it in, but it still fails on island/aruma. 
> > 
> > I don't consider this a blocker though, since I won't switch the
> > customer to the new tree unless CAR works anyways so I would appreciate
> > having it in the tree to settle down and mature.
> > 
> > Stefan
> > 
> > 
> 
> I'm leaning to applying the CAR patch (issue 26). This only affects k8. 
> If anyone has a problem with this, let me know ASAP, else I will apply 
> it later today.
> 
> I think I've resolved about 6 issues, I hope to get more done in the 
> weeks to come. My goals is to have no unresolved issues by dec. 15.
> 

I am O.K. with the CAR patch. The problem is the patch only works
for one Tyan motherboard. We need another patch to fix every other
boards.

> ron
-- 
Li-Ta Lo <ollie at lanl.gov>
Los Alamos National Lab




From rminnich at lanl.gov  Wed Nov 23 22:09:20 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 23 Nov 2005 14:09:20 -0700
Subject: [LinuxBIOS] isue 26
In-Reply-To: <2ea3fae10511231306haaf964fxe474b0334c4a6f57@mail.gmail.com>
References: <438492B0.5020408@lanl.gov> <20051123170631.GB3119@openbios.org>	
	<2ea3fae10511230926n13f98844vba4a1f3023bbee06@mail.gmail.com>	
	<20051123172934.GC16002@openbios.org>	
	<2ea3fae10511230934t77cd2517pa1e758f3004d274e@mail.gmail.com>	
	<4384D88A.50501@lanl.gov>
	<2ea3fae10511231306haaf964fxe474b0334c4a6f57@mail.gmail.com>
Message-ID: <4384DA80.9050105@lanl.gov>

yhlu wrote:

> Can you look at the acpi, I have seperate that to core, and MB..., in
> the isssue tracker...

which isssues are these, and ... are these related to the tarball you 
sent me 11/19?

I am going offline in a bit ... it's vacation time. Will look at these 
monday. Let me know which issues you want us to look at next, and if any 
issues on the tracker should be ignored/retired.

thanks

ron



From yinghailu at gmail.com  Wed Nov 23 22:11:29 2005
From: yinghailu at gmail.com (yhlu)
Date: Wed, 23 Nov 2005 13:11:29 -0800
Subject: [LinuxBIOS] isue 26
In-Reply-To: <1132780164.5055.4.camel@logarithm.lanl.gov>
References: <438492B0.5020408@lanl.gov> <20051123170631.GB3119@openbios.org>
	<4384CD96.2020306@lanl.gov>
	<1132780164.5055.4.camel@logarithm.lanl.gov>
Message-ID: <2ea3fae10511231311o4d1bd4b0h3ce3160384f7a1d6@mail.gmail.com>

the code for other MB, is sitting on my Laptop, I will produce one
patch after you applied my acpi patch...

YH

On 11/23/05, Li-Ta Lo <ollie at lanl.gov> wrote:
> On Wed, 2005-11-23 at 13:14 -0700, Ronald G Minnich wrote:
> > Stefan Reinauer wrote:
> > > * Ronald G Minnich <rminnich at lanl.gov> [051123 17:02]:
> > >
> > >>reenable car
> > >>
> > >>it looks like it will apply, but what do you all think? is this thing ok?
> > >
> > >
> > > I definitely want it in, but it still fails on island/aruma.
> > >
> > > I don't consider this a blocker though, since I won't switch the
> > > customer to the new tree unless CAR works anyways so I would appreciate
> > > having it in the tree to settle down and mature.
> > >
> > > Stefan
> > >
> > >
> >
> > I'm leaning to applying the CAR patch (issue 26). This only affects k8.
> > If anyone has a problem with this, let me know ASAP, else I will apply
> > it later today.
> >
> > I think I've resolved about 6 issues, I hope to get more done in the
> > weeks to come. My goals is to have no unresolved issues by dec. 15.
> >
>
> I am O.K. with the CAR patch. The problem is the patch only works
> for one Tyan motherboard. We need another patch to fix every other
> boards.
>
> > ron
> --
> Li-Ta Lo <ollie at lanl.gov>
> Los Alamos National Lab
>
>



From yinghailu at gmail.com  Wed Nov 23 22:12:44 2005
From: yinghailu at gmail.com (yhlu)
Date: Wed, 23 Nov 2005 13:12:44 -0800
Subject: [LinuxBIOS] isue 26
In-Reply-To: <4384DA80.9050105@lanl.gov>
References: <438492B0.5020408@lanl.gov> <20051123170631.GB3119@openbios.org>
	<2ea3fae10511230926n13f98844vba4a1f3023bbee06@mail.gmail.com>
	<20051123172934.GC16002@openbios.org>
	<2ea3fae10511230934t77cd2517pa1e758f3004d274e@mail.gmail.com>
	<4384D88A.50501@lanl.gov>
	<2ea3fae10511231306haaf964fxe474b0334c4a6f57@mail.gmail.com>
	<4384DA80.9050105@lanl.gov>
Message-ID: <2ea3fae10511231312w73bfc280t60ad9096d6ac96ea@mail.gmail.com>

wait... before you go, apply acpi patch....

YH

On 11/23/05, Ronald G Minnich <rminnich at lanl.gov> wrote:
> yhlu wrote:
>
> > Can you look at the acpi, I have seperate that to core, and MB..., in
> > the isssue tracker...
>
> which isssues are these, and ... are these related to the tarball you
> sent me 11/19?
>
> I am going offline in a bit ... it's vacation time. Will look at these
> monday. Let me know which issues you want us to look at next, and if any
> issues on the tracker should be ignored/retired.
>
> thanks
>
> ron
>



From stepan at openbios.org  Wed Nov 23 22:12:48 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Wed, 23 Nov 2005 22:12:48 +0100
Subject: [LinuxBIOS] isue 26
In-Reply-To: <4384DA80.9050105@lanl.gov>
References: <438492B0.5020408@lanl.gov> <20051123170631.GB3119@openbios.org>
	<2ea3fae10511230926n13f98844vba4a1f3023bbee06@mail.gmail.com>
	<20051123172934.GC16002@openbios.org>
	<2ea3fae10511230934t77cd2517pa1e758f3004d274e@mail.gmail.com>
	<4384D88A.50501@lanl.gov>
	<2ea3fae10511231306haaf964fxe474b0334c4a6f57@mail.gmail.com>
	<4384DA80.9050105@lanl.gov>
Message-ID: <20051123211248.GA10145@openbios.org>

* Ronald G Minnich <rminnich at lanl.gov> [051123 22:09]:
> yhlu wrote:
> 
> >Can you look at the acpi, I have seperate that to core, and MB..., in
> >the isssue tracker...
> 
> which isssues are these, and ... are these related to the tarball you 
> sent me 11/19?
> 
> I am going offline in a bit ... it's vacation time. Will look at these 
> monday. Let me know which issues you want us to look at next, and if any 
> issues on the tracker should be ignored/retired.
 
There's a superseeder field in the tracker to mark bugs which replace
others.

Stefan





From stepan at openbios.org  Wed Nov 23 22:14:46 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Wed, 23 Nov 2005 22:14:46 +0100
Subject: [LinuxBIOS] issue 20, island aruma update
In-Reply-To: <4384D9DA.7090600@lanl.gov>
References: <20051123130345.GA28320@openbios.org> <43848B77.6090707@lanl.gov>
	<20051123171329.GA13080@openbios.org>
	<8a0c36780511231226n75189e23p1a78afd50afaf232@mail.gmail.com>
	<4384D0F1.5000803@lanl.gov> <20051123204122.GB27171@openbios.org>
	<8a0c36780511231249n6f159229l9fc4c84baca014f9@mail.gmail.com>
	<4384D707.2080502@lanl.gov>
	<8a0c36780511231304n7bc364e8n3729b9208ee58cd8@mail.gmail.com>
	<4384D9DA.7090600@lanl.gov>
Message-ID: <20051123211446.GA11556@openbios.org>

* Ronald G Minnich <rminnich at lanl.gov> [051123 22:06]:
> Richard Smith wrote:
> 
> >For that you probally will need some sort of maintainer for each board
> >or group of boards.
> 
> I tried that 'board owner' thing on V1 and could NOT get it to work. We 
> need some really convenient way for a board owner to say 'my board works 
> with release #XXXX" so people can know what svn revs to use.
 
This is getting easier with tree wide revisions in SVN


Stefan




From rminnich at lanl.gov  Wed Nov 23 22:14:06 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 23 Nov 2005 14:14:06 -0700
Subject: [LinuxBIOS] isue 26
In-Reply-To: <2ea3fae10511231312w73bfc280t60ad9096d6ac96ea@mail.gmail.com>
References: <438492B0.5020408@lanl.gov> <20051123170631.GB3119@openbios.org>	
	<2ea3fae10511230926n13f98844vba4a1f3023bbee06@mail.gmail.com>	
	<20051123172934.GC16002@openbios.org>	
	<2ea3fae10511230934t77cd2517pa1e758f3004d274e@mail.gmail.com>	
	<4384D88A.50501@lanl.gov>	
	<2ea3fae10511231306haaf964fxe474b0334c4a6f57@mail.gmail.com>	
	<4384DA80.9050105@lanl.gov>
	<2ea3fae10511231312w73bfc280t60ad9096d6ac96ea@mail.gmail.com>
Message-ID: <4384DB9E.5080306@lanl.gov>

yhlu wrote:
> wait... before you go, apply acpi patch....

is this issue 24? And, of the 3 patches, which one is critical?

Or is this the tarball you sent? What do you want applied?

thanks

ron




From yinghailu at gmail.com  Wed Nov 23 22:16:15 2005
From: yinghailu at gmail.com (yhlu)
Date: Wed, 23 Nov 2005 13:16:15 -0800
Subject: [LinuxBIOS] isue 26
In-Reply-To: <4384DB9E.5080306@lanl.gov>
References: <438492B0.5020408@lanl.gov> <20051123170631.GB3119@openbios.org>
	<2ea3fae10511230926n13f98844vba4a1f3023bbee06@mail.gmail.com>
	<20051123172934.GC16002@openbios.org>
	<2ea3fae10511230934t77cd2517pa1e758f3004d274e@mail.gmail.com>
	<4384D88A.50501@lanl.gov>
	<2ea3fae10511231306haaf964fxe474b0334c4a6f57@mail.gmail.com>
	<4384DA80.9050105@lanl.gov>
	<2ea3fae10511231312w73bfc280t60ad9096d6ac96ea@mail.gmail.com>
	<4384DB9E.5080306@lanl.gov>
Message-ID: <2ea3fae10511231316o3403236ejf69bf171378a7614@mail.gmail.com>

a_s1_core.diff
and a_s1_mb.diff

So I can produce next patch shorter...

YH

On 11/23/05, Ronald G Minnich <rminnich at lanl.gov> wrote:
> yhlu wrote:
> > wait... before you go, apply acpi patch....
>
> is this issue 24? And, of the 3 patches, which one is critical?
>
> Or is this the tarball you sent? What do you want applied?
>
> thanks
>
> ron
>
>



From rminnich at lanl.gov  Thu Nov 24 02:28:11 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 23 Nov 2005 18:28:11 -0700
Subject: [LinuxBIOS] isue 26
In-Reply-To: <2ea3fae10511231316o3403236ejf69bf171378a7614@mail.gmail.com>
References: <438492B0.5020408@lanl.gov> <20051123170631.GB3119@openbios.org>	
	<2ea3fae10511230926n13f98844vba4a1f3023bbee06@mail.gmail.com>	
	<20051123172934.GC16002@openbios.org>	
	<2ea3fae10511230934t77cd2517pa1e758f3004d274e@mail.gmail.com>	
	<4384D88A.50501@lanl.gov>	
	<2ea3fae10511231306haaf964fxe474b0334c4a6f57@mail.gmail.com>	
	<4384DA80.9050105@lanl.gov>	
	<2ea3fae10511231312w73bfc280t60ad9096d6ac96ea@mail.gmail.com>	
	<4384DB9E.5080306@lanl.gov>
	<2ea3fae10511231316o3403236ejf69bf171378a7614@mail.gmail.com>
Message-ID: <4385172B.1040400@lanl.gov>

yhlu wrote:
> a_s1_core.diff
> and a_s1_mb.diff

That went very badly:

[rminnich at q LinuxBIOSv2]$ patch -p1 < /tmp/a_s1_core.diff
patching file src/arch/i386/boot/acpi.c
patching file src/arch/i386/include/arch/acpi.h
Hunk #3 succeeded at 114 with fuzz 1.
Hunk #4 succeeded at 134 (offset 1 line).
Hunk #6 succeeded at 285 (offset 1 line).
patching file src/config/Options.lb
Hunk #1 succeeded at 778 (offset -4 lines).
patching file src/include/device/path.h
patching file src/northbridge/amd/amdk8/amdk8_acpi.c
patching file src/northbridge/amd/amdk8/Config.lb
patching file src/northbridge/amd/amdk8/get_sblk_pci1234.c
patching file src/northbridge/amd/amdk8/northbridge.c
Hunk #1 succeeded at 692 with fuzz 2 (offset -102 lines).
Hunk #2 succeeded at 810 (offset 1 line).
Hunk #3 succeeded at 720 with fuzz 2 (offset -104 lines).
Hunk #4 succeeded at 841 (offset 4 lines).
Hunk #5 FAILED at 1033.
1 out of 5 hunks FAILED -- saving rejects to file 
src/northbridge/amd/amdk8/northbridge.c.rej
patching file src/southbridge/amd/amd8111/amd8111_acpi.c
Hunk #2 succeeded at 123 (offset 1 line).
patching file src/southbridge/amd/amd8132/amd8132_bridge.c
patching file src/southbridge/amd/amd8132/Config.lb

I looked atthe HUNKS that failed on northbridge.c and see no obvious way 
to fix it.

If anyone else wants to take a look, be my guest; I'm done for the 
night. good luck.

ron



From yinghailu at gmail.com  Thu Nov 24 02:51:20 2005
From: yinghailu at gmail.com (yhlu)
Date: Wed, 23 Nov 2005 17:51:20 -0800
Subject: [LinuxBIOS] isue 26
In-Reply-To: <4385172B.1040400@lanl.gov>
References: <438492B0.5020408@lanl.gov> <20051123172934.GC16002@openbios.org>
	<2ea3fae10511230934t77cd2517pa1e758f3004d274e@mail.gmail.com>
	<4384D88A.50501@lanl.gov>
	<2ea3fae10511231306haaf964fxe474b0334c4a6f57@mail.gmail.com>
	<4384DA80.9050105@lanl.gov>
	<2ea3fae10511231312w73bfc280t60ad9096d6ac96ea@mail.gmail.com>
	<4384DB9E.5080306@lanl.gov>
	<2ea3fae10511231316o3403236ejf69bf171378a7614@mail.gmail.com>
	<4385172B.1040400@lanl.gov>
Message-ID: <2ea3fae10511231751y6d82b687l52577ca3f435b882@mail.gmail.com>

that is used to store node id and coreid to the apic path. for core0
and core1, if core1 apic id path is created there bus_cpu_scan...

Because LNXI create the core1 apic id path in core0 of
amd_sibling_init, in that case need to store nodeid and coreid too...

I hope you can look the my northbridge.c to create core1 apic id patch
in bus_cpu_scan ...

So You can disable CPU_INIT_SERIALIZE for big SMP system...

YH

On 11/23/05, Ronald G Minnich <rminnich at lanl.gov> wrote:
> yhlu wrote:
> > a_s1_core.diff
> > and a_s1_mb.diff
>
> That went very badly:
>
> [rminnich at q LinuxBIOSv2]$ patch -p1 < /tmp/a_s1_core.diff
> patching file src/arch/i386/boot/acpi.c
> patching file src/arch/i386/include/arch/acpi.h
> Hunk #3 succeeded at 114 with fuzz 1.
> Hunk #4 succeeded at 134 (offset 1 line).
> Hunk #6 succeeded at 285 (offset 1 line).
> patching file src/config/Options.lb
> Hunk #1 succeeded at 778 (offset -4 lines).
> patching file src/include/device/path.h
> patching file src/northbridge/amd/amdk8/amdk8_acpi.c
> patching file src/northbridge/amd/amdk8/Config.lb
> patching file src/northbridge/amd/amdk8/get_sblk_pci1234.c
> patching file src/northbridge/amd/amdk8/northbridge.c
> Hunk #1 succeeded at 692 with fuzz 2 (offset -102 lines).
> Hunk #2 succeeded at 810 (offset 1 line).
> Hunk #3 succeeded at 720 with fuzz 2 (offset -104 lines).
> Hunk #4 succeeded at 841 (offset 4 lines).
> Hunk #5 FAILED at 1033.
> 1 out of 5 hunks FAILED -- saving rejects to file
> src/northbridge/amd/amdk8/northbridge.c.rej
> patching file src/southbridge/amd/amd8111/amd8111_acpi.c
> Hunk #2 succeeded at 123 (offset 1 line).
> patching file src/southbridge/amd/amd8132/amd8132_bridge.c
> patching file src/southbridge/amd/amd8132/Config.lb
>
> I looked atthe HUNKS that failed on northbridge.c and see no obvious way
> to fix it.
>
> If anyone else wants to take a look, be my guest; I'm done for the
> night. good luck.
>
> ron
>



From stuge-linuxbios at cdy.org  Thu Nov 24 02:59:18 2005
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Thu, 24 Nov 2005 02:59:18 +0100
Subject: [LinuxBIOS] issue 20, island aruma update
In-Reply-To: <4384D9DA.7090600@lanl.gov>
References: <20051123130345.GA28320@openbios.org> <43848B77.6090707@lanl.gov>
	<20051123171329.GA13080@openbios.org>
	<8a0c36780511231226n75189e23p1a78afd50afaf232@mail.gmail.com>
	<4384D0F1.5000803@lanl.gov> <20051123204122.GB27171@openbios.org>
	<8a0c36780511231249n6f159229l9fc4c84baca014f9@mail.gmail.com>
	<4384D707.2080502@lanl.gov>
	<8a0c36780511231304n7bc364e8n3729b9208ee58cd8@mail.gmail.com>
	<4384D9DA.7090600@lanl.gov>
Message-ID: <20051124015918.18705.qmail@cdy.org>

On Wed, Nov 23, 2005 at 02:06:34PM -0700, Ronald G Minnich wrote:
> I tried that 'board owner' thing on V1 and could NOT get it to
> work. We need some really convenient way for a board owner to say
> 'my board works with release #XXXX" so people can know what svn
> revs to use.

How about the wiki? Although it requires a username.

This mailing list? Someone (me?) could update the wiki page.


//Peter



From JJia at Fortinet.com  Thu Nov 24 03:08:56 2005
From: JJia at Fortinet.com (Jia Jianwei)
Date: Wed, 23 Nov 2005 18:08:56 -0800
Subject: [LinuxBIOS] AMD GX2 VSA init
References: <438492B0.5020408@lanl.gov>
	<20051123172934.GC16002@openbios.org><2ea3fae10511230934t77cd2517pa1e758f3004d274e@mail.gmail.com><4384D88A.50501@lanl.gov><2ea3fae10511231306haaf964fxe474b0334c4a6f57@mail.gmail.com><4384DA80.9050105@lanl.gov><2ea3fae10511231312w73bfc280t60ad9096d6ac96ea@mail.gmail.com><4384DB9E.5080306@lanl.gov><2ea3fae10511231316o3403236ejf69bf171378a7614@mail.gmail.com><4385172B.1040400@lanl.gov>
	<2ea3fae10511231751y6d82b687l52577ca3f435b882@mail.gmail.com>
Message-ID: <001901c5f09c$07ac3d60$3a4610ac@fortinet.com>

The attach file is VSM initialization code in protect mode, verified working
with SYSMGR VSM on a GX2/5535 system, hope helpful for those guys porting
GX2 system.   It suppose VSM has been loaded to D0000.

Jianwei
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vsa.S
Type: application/octet-stream
Size: 12842 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20051123/fd6f275a/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: reg.equ
Type: application/octet-stream
Size: 7445 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20051123/fd6f275a/attachment-0001.obj>

From rminnich at gmail.com  Thu Nov 24 03:47:26 2005
From: rminnich at gmail.com (ron minnich)
Date: Wed, 23 Nov 2005 19:47:26 -0700
Subject: [LinuxBIOS] serengeti support added
Message-ID: <13426df10511231847t73dfac31kfdf2f4b7d6399786@mail.gmail.com>

Ying Hai, serengeti support is in. This is one part of issue 24.


ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20051123/75d82a87/attachment.html>

From yinghai.lu at amd.com  Thu Nov 24 03:54:48 2005
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Wed, 23 Nov 2005 18:54:48 -0800
Subject: [LinuxBIOS] serengeti support added
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094953@ssvlexmb2.amd.com>

Great, 

 

Next you need to work on 36 and 37...

 

YH

 

________________________________

From: linuxbios-bounces at openbios.org
[mailto:linuxbios-bounces at openbios.org] On Behalf Of ron minnich
Sent: Wednesday, November 23, 2005 6:47 PM
To: LinuxBIOS; yhlu; Stefan Reinauer; Li-Ta Lo
Subject: [LinuxBIOS] serengeti support added

 

Ying Hai, serengeti support is in. This is one part of issue 24.


ron

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20051123/b1b134de/attachment.html>

From rminnich at gmail.com  Thu Nov 24 05:31:51 2005
From: rminnich at gmail.com (ron minnich)
Date: Wed, 23 Nov 2005 21:31:51 -0700
Subject: [LinuxBIOS] serengeti support added
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4203094953@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094953@ssvlexmb2.amd.com>
Message-ID: <13426df10511232031u56b5a287h6c9fe002afe7b7b3@mail.gmail.com>

On 11/23/05, Lu, Yinghai <yinghai.lu at amd.com> wrote:
>
>  Great,
>
>
>
> Next you need to work on 36 and 37?
>

we can not do that until we get the a_s1_core.diff to patch correctly,
right? I'm not totally done 24.

We're going to stop here and make sure the 2881 will work correctly with
current svn. We'll do these other patches next week.

ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20051123/6f2f9154/attachment.html>

From yinghailu at gmail.com  Thu Nov 24 06:20:35 2005
From: yinghailu at gmail.com (yhlu)
Date: Wed, 23 Nov 2005 21:20:35 -0800
Subject: [LinuxBIOS] serengeti support added
In-Reply-To: <13426df10511232031u56b5a287h6c9fe002afe7b7b3@mail.gmail.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094953@ssvlexmb2.amd.com>
	<13426df10511232031u56b5a287h6c9fe002afe7b7b3@mail.gmail.com>
Message-ID: <2ea3fae10511232120y1f756bb2w9885565e489e6556@mail.gmail.com>

without 37 you may have problem for s2881 to work with kernel.....

Kernel need lifted apic are continous.

But LNXI apicid solution will default lift all apic as
A:
Node0/Core0: 0x10
Node0/Core1: 0x20
Node1/Core0: 0x11
Node1/Core1: 0x21

You need to make northbridge.c/amd_siblings.c to be consistent with init_cpus.c

current init_cpus.c is using
B:
ENABLE_APIC_EXT_ID =0
Node0/Core0: 0x00
Node0/Core1: 0x01
Node1/Core0: 0x02
Node1/Core1: 0x03
or
ENABLE_APIC_EXT_ID=1, APIC_ID_OFFSET=0x10, LIFT_BSP_APIC_ID=0
C:
Node0/Core0: 0x00
Node0/Core1: 0x11
Node1/Core0: 0x12
Node1/Core1: 0x13
or
D:
ENABLE_APIC_EXT_ID=1, APIC_ID_OFFSET=0x10, LIFT_BSP_APIC_ID=1
Node0/Core0: 0x10
Node0/Core1: 0x11
Node1/Core0: 0x12
Node1/Core1: 0x13

Kernel will work with B and D.

With AMD8111 We need C, and Kernel patch....

YH



On 11/23/05, ron minnich <rminnich at gmail.com> wrote:
>
> On 11/23/05, Lu, Yinghai <yinghai.lu at amd.com> wrote:
> >
> >
> >
> > Great,
> >
> >
> >
> > Next you need to work on 36 and 37?
>
> we can not do that until we get the a_s1_core.diff to patch correctly,
> right? I'm not totally done 24.
>
> We're going to stop here and make sure the 2881 will work correctly with
> current svn. We'll do these other patches next week.
>
> ron
>
>
>
>

From ollie at lanl.gov  Thu Nov 24 06:28:33 2005
From: ollie at lanl.gov (Li-Ta Lo)
Date: Wed, 23 Nov 2005 22:28:33 -0700
Subject: [LinuxBIOS] serengeti support added
In-Reply-To: <13426df10511232031u56b5a287h6c9fe002afe7b7b3@mail.gmail.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094953@ssvlexmb2.amd.com>
	<13426df10511232031u56b5a287h6c9fe002afe7b7b3@mail.gmail.com>
Message-ID: <1132810114.10097.3.camel@logarithm.lanl.gov>

On Wed, 2005-11-23 at 21:31 -0700, ron minnich wrote:
> 
> On 11/23/05, Lu, Yinghai <yinghai.lu at amd.com> wrote:
>         Great, 
>         
>          
>         
>         Next you need to work on 36 and 37?
>         
>         
> 
> we can not do that until we get the a_s1_core.diff to patch correctly,
> right? I'm not totally done 24. 
> 

Do you mean the CAR enable patch depends on the ACPI patch? Why?
 
> We're going to stop here and make sure the 2881 will work correctly
> with current svn. We'll do these other patches next week.
> 

If CAR enable patch does not depend on the ACPI patch, we should be
able to proceed. Revision 2098 has been tested on the real s2881 and
I don't think revision 2099 and 2100 will do anything the other part
of the tree.

-- 
Li-Ta Lo <ollie at lanl.gov>
Los Alamos National Lab




From yinghailu at gmail.com  Thu Nov 24 07:00:34 2005
From: yinghailu at gmail.com (yhlu)
Date: Wed, 23 Nov 2005 22:00:34 -0800
Subject: [LinuxBIOS] serengeti support added
In-Reply-To: <1132810114.10097.3.camel@logarithm.lanl.gov>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4203094953@ssvlexmb2.amd.com>
	<13426df10511232031u56b5a287h6c9fe002afe7b7b3@mail.gmail.com>
	<1132810114.10097.3.camel@logarithm.lanl.gov>
Message-ID: <2ea3fae10511232200q3ef47ecak5a01fa214688ec78@mail.gmail.com>

Don't need acpi, but all related to northridge.c.

ACPI need to store node id and core id in apic id for SRAT and MADT in
bus_scan_bus....

with apic lifting, s2881 can work?

Can you check the apic id in LinuxBIOS and kernel?

YH

On 11/23/05, Li-Ta Lo <ollie at lanl.gov> wrote:
> On Wed, 2005-11-23 at 21:31 -0700, ron minnich wrote:
> >
> > On 11/23/05, Lu, Yinghai <yinghai.lu at amd.com> wrote:
> >         Great,
> >
> >
> >
> >         Next you need to work on 36 and 37?
> >
> >
> >
> > we can not do that until we get the a_s1_core.diff to patch correctly,
> > right? I'm not totally done 24.
> >
>
> Do you mean the CAR enable patch depends on the ACPI patch? Why?
>
> > We're going to stop here and make sure the 2881 will work correctly
> > with current svn. We'll do these other patches next week.
> >
>
> If CAR enable patch does not depend on the ACPI patch, we should be
> able to proceed. Revision 2098 has been tested on the real s2881 and
> I don't think revision 2099 and 2100 will do anything the other part
> of the tree.
>
> --
> Li-Ta Lo <ollie at lanl.gov>
> Los Alamos National Lab
>
>

From m303 at luusa.org  Thu Nov 24 09:51:45 2005
From: m303 at luusa.org (Martin Ley)
Date: Thu, 24 Nov 2005 09:51:45 +0100
Subject: [LinuxBIOS] Epia-M Status
In-Reply-To: <438266C3.6020700@lanl.gov>
References: <438266C3.6020700@lanl.gov>
Message-ID: <43857F21.9060802@luusa.org>

Hi list,


I just checked out a fresh new version (2100) of LinuxBiosV2. Epia-M 
builds (default-config) and boots with VGA.

The VGA Bios has to be extracted like Jun said:

 > # dd if=/dev/mem of=video.bios.bin.4 bs=1 count=65536 skip=786432
 > 786432 is 0xc0000, and 790528 which Nich told is 0xc1000.

I haven't tried X yet.

Nice work and thank you all for your help.


Martin



From stepan at openbios.org  Thu Nov 24 10:10:44 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Thu, 24 Nov 2005 10:10:44 +0100
Subject: [LinuxBIOS] issue 20, island aruma update
In-Reply-To: <20051124015918.18705.qmail@cdy.org>
References: <43848B77.6090707@lanl.gov> <20051123171329.GA13080@openbios.org>
	<8a0c36780511231226n75189e23p1a78afd50afaf232@mail.gmail.com>
	<4384D0F1.5000803@lanl.gov> <20051123204122.GB27171@openbios.org>
	<8a0c36780511231249n6f159229l9fc4c84baca014f9@mail.gmail.com>
	<4384D707.2080502@lanl.gov>
	<8a0c36780511231304n7bc364e8n3729b9208ee58cd8@mail.gmail.com>
	<4384D9DA.7090600@lanl.gov> <20051124015918.18705.qmail@cdy.org>
Message-ID: <20051124091044.GD18470@openbios.org>

* Peter Stuge <stuge-linuxbios at cdy.org> [051124 02:59]:
> On Wed, Nov 23, 2005 at 02:06:34PM -0700, Ronald G Minnich wrote:
> > I tried that 'board owner' thing on V1 and could NOT get it to
> > work. We need some really convenient way for a board owner to say
> > 'my board works with release #XXXX" so people can know what svn
> > revs to use.
> 
> How about the wiki? Although it requires a username.
> 
> This mailing list? Someone (me?) could update the wiki page.

I think this is a great idea! We do have a page with supported
motherboards already, but it tends to get outdated very easily.
Having reliable information there would definitely push the project.

Stefan





From stuge-linuxbios at cdy.org  Thu Nov 24 10:54:05 2005
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Thu, 24 Nov 2005 10:54:05 +0100
Subject: [LinuxBIOS] issue 20, island aruma update
In-Reply-To: <20051124091044.GD18470@openbios.org>
References: <20051123171329.GA13080@openbios.org>
	<8a0c36780511231226n75189e23p1a78afd50afaf232@mail.gmail.com>
	<4384D0F1.5000803@lanl.gov> <20051123204122.GB27171@openbios.org>
	<8a0c36780511231249n6f159229l9fc4c84baca014f9@mail.gmail.com>
	<4384D707.2080502@lanl.gov>
	<8a0c36780511231304n7bc364e8n3729b9208ee58cd8@mail.gmail.com>
	<4384D9DA.7090600@lanl.gov> <20051124015918.18705.qmail@cdy.org>
	<20051124091044.GD18470@openbios.org>
Message-ID: <20051124095406.9137.qmail@cdy.org>

On Thu, Nov 24, 2005 at 10:10:44AM +0100, Stefan Reinauer wrote:
> > How about the wiki? Although it requires a username.
> > This mailing list? Someone (me?) could update the wiki page.
> 
> I think this is a great idea! We do have a page with supported
> motherboards already, but it tends to get outdated very easily.
> Having reliable information there would definitely push the
> project.

That page is quite long, with a lot of information missing.

I'm thinking perhaps a table with a couple of fields;

motherboard_human_name motherboard_linuxbios_name
confirmed_working_svn comments

Example:

Epia-M epia-m 2100 "To enable VGA, extract VGA BIOS with dd if=.."

Should I add it to the top of that page or just make a new page?


//Peter



From stepan at openbios.org  Thu Nov 24 11:09:38 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Thu, 24 Nov 2005 11:09:38 +0100
Subject: [LinuxBIOS] issue 20, island aruma update
In-Reply-To: <20051124095406.9137.qmail@cdy.org>
References: <8a0c36780511231226n75189e23p1a78afd50afaf232@mail.gmail.com>
	<4384D0F1.5000803@lanl.gov> <20051123204122.GB27171@openbios.org>
	<8a0c36780511231249n6f159229l9fc4c84baca014f9@mail.gmail.com>
	<4384D707.2080502@lanl.gov>
	<8a0c36780511231304n7bc364e8n3729b9208ee58cd8@mail.gmail.com>
	<4384D9DA.7090600@lanl.gov> <20051124015918.18705.qmail@cdy.org>
	<20051124091044.GD18470@openbios.org>
	<20051124095406.9137.qmail@cdy.org>
Message-ID: <20051124100938.GA5163@openbios.org>

* Peter Stuge <stuge-linuxbios at cdy.org> [051124 10:54]:
> That page is quite long, with a lot of information missing.
> 
> I'm thinking perhaps a table with a couple of fields;
> 
> motherboard_human_name motherboard_linuxbios_name
> confirmed_working_svn comments
> 
> Example:
> 
> Epia-M epia-m 2100 "To enable VGA, extract VGA BIOS with dd if=.."
> 
> Should I add it to the top of that page or just make a new page?

I'd prefer a new page which is linked from the old one. 
But, since you are doing the work, do what you consider best.

Stefan




From martin.ley at smail.inf.fh-brs.de  Thu Nov 24 11:18:49 2005
From: martin.ley at smail.inf.fh-brs.de (Martin Ley)
Date: Thu, 24 Nov 2005 11:18:49 +0100
Subject: [LinuxBIOS] Typos in console.c/h
Message-ID: <43859389.1050603@smail.inf.fh-brs.de>

Hi list,

after reducing the log-levels to 0 the build did not compile anymore. 
Looks like there are some typos in the source:


Index: src/include/console/console.h
===================================================================
--- src/include/console/console.h   (Revision 2100)
+++ src/include/console/console.h   (Arbeitskopie)
@@ -45,7 +45,7 @@
 #endif
 #if MAXIMUM_CONSOLE_LOGLEVEL <= BIOS_ALERT
 #undef  printk_alert
-#define printk_alart(fmt, arg...)   do {} while(0)
+#define printk_alert(fmt, arg...)   do {} while(0)
 #endif
 #if MAXIMUM_CONSOLE_LOGLEVEL <= BIOS_CRIT
 #undef  printk_crit
Index: src/arch/i386/lib/console.c
===================================================================
--- src/arch/i386/lib/console.c     (Revision 2100)
+++ src/arch/i386/lib/console.c     (Arbeitskopie)
@@ -191,7 +191,7 @@
 #endif
 #if MAXIMUM_CONSOLE_LOGLEVEL <= BIOS_ALERT
 #undef  printk_alert
-#define printk_alart(fmt, arg...)   do {} while(0)
+#define printk_alert(fmt, arg...)   do {} while(0)
 #endif
 #if MAXIMUM_CONSOLE_LOGLEVEL <= BIOS_CRIT
 #undef  printk_crit

Someone might change this in the tree.

Martin



From stepan at openbios.org  Thu Nov 24 11:27:47 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Thu, 24 Nov 2005 11:27:47 +0100
Subject: [LinuxBIOS] Typos in console.c/h
In-Reply-To: <43859389.1050603@smail.inf.fh-brs.de>
References: <43859389.1050603@smail.inf.fh-brs.de>
Message-ID: <20051124102747.GA8159@openbios.org>

Dear Martin,

* Martin Ley <martin.ley at smail.inf.fh-brs.de> [051124 11:18]:
> after reducing the log-levels to 0 the build did not compile anymore. 
> Looks like there are some typos in the source:

thanks for spotting this. It's fixed in revision 2101.

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

Regards,
Stefan







From tristan at open3net.com  Thu Nov 24 12:01:40 2005
From: tristan at open3net.com (tristan)
Date: Thu, 24 Nov 2005 12:01:40 +0100
Subject: [LinuxBIOS] Epia-M Status
In-Reply-To: <43857F21.9060802@luusa.org>
References: <438266C3.6020700@lanl.gov>  <43857F21.9060802@luusa.org>
Message-ID: <1132830100.3430.19.camel@localhost.localdomain>

Le jeudi 24 novembre 2005 ? 09:51 +0100, Martin Ley a ?crit :
> Hi list,
> 
Hi list too
> 
> I just checked out a fresh new version (2100) of LinuxBiosV2. Epia-M 
> builds (default-config) and boots with VGA.
> 
which motherboard/processor do you have exactly? mine is M10000 /
Nehemiah 1GHz VIA stepping 5.

> The VGA Bios has to be extracted like Jun said:
> 
>  > # dd if=/dev/mem of=video.bios.bin.4 bs=1 count=65536 skip=786432
>  > 786432 is 0xc0000, and 790528 which Nich told is 0xc1000.
So, wich one using? 786432 or 790528?
> I haven't tried X yet.
Oh yes please tell us, thx!
Please also complete wiki for this motherboard ;-)

Tristan
> 
> Nice work and thank you all for your help.
> 
> Martin
> 




From a.borisov at tesv.tmb.ru  Thu Nov 24 12:18:15 2005
From: a.borisov at tesv.tmb.ru (Anton Borisov)
Date: Thu, 24 Nov 2005 14:18:15 +0300
Subject: [LinuxBIOS] Epia-M Status
In-Reply-To: <1132830100.3430.19.camel@localhost.localdomain>
References: <438266C3.6020700@lanl.gov> <43857F21.9060802@luusa.org>
	<1132830100.3430.19.camel@localhost.localdomain>
Message-ID: <20051124141815.6cff4c81.a.borisov@tesv.tmb.ru>

On Thu, 24 Nov 2005 12:01:40 +0100
tristan <tristan at open3net.com> wrote:

> > The VGA Bios has to be extracted like Jun said:
> > 
> >  > # dd if=/dev/mem of=video.bios.bin.4 bs=1 count=65536 skip=786432
> >  > 786432 is 0xc0000, and 790528 which Nich told is 0xc1000.
> So, wich one using? 786432 or 790528?
> > I haven't tried X yet.
> Oh yes please tell us, thx!
	
	My experience ended up with 640x480x4 (this is maximum!). X-driver is "vga". Unfortunately VBE Video BIOS couldn't be detected by Xorg.


-- 
Sincerely, Anton Borisov



From stuge-linuxbios at cdy.org  Thu Nov 24 12:29:03 2005
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Thu, 24 Nov 2005 12:29:03 +0100
Subject: [LinuxBIOS] issue 20, island aruma update
In-Reply-To: <20051124100938.GA5163@openbios.org>
References: <4384D0F1.5000803@lanl.gov> <20051123204122.GB27171@openbios.org>
	<8a0c36780511231249n6f159229l9fc4c84baca014f9@mail.gmail.com>
	<4384D707.2080502@lanl.gov>
	<8a0c36780511231304n7bc364e8n3729b9208ee58cd8@mail.gmail.com>
	<4384D9DA.7090600@lanl.gov> <20051124015918.18705.qmail@cdy.org>
	<20051124091044.GD18470@openbios.org>
	<20051124095406.9137.qmail@cdy.org>
	<20051124100938.GA5163@openbios.org>
Message-ID: <20051124112904.20531.qmail@cdy.org>

On Thu, Nov 24, 2005 at 11:09:38AM +0100, Stefan Reinauer wrote:
> > Should I add it to the top of that page or just make a new page?
> 
> I'd prefer a new page which is linked from the old one. 

I agree.

http://wiki.linuxbios.org/index.php/Confirmed_working_svn_revisions

I'll try to update it whenever I see confirmations on the list, but
by all means feel free to beat me to it. :)

I took the liberty of optimizing the dd command for epia-m a bit,
making it slightly less error-prone. While I cannot see why it would
make any difference I would appreciate if someone could test that it
does indeed work as it should. If not, I'll quickly change that back.


//Peter



From okajima at digitalinfra.co.jp  Thu Nov 24 12:33:57 2005
From: okajima at digitalinfra.co.jp (Jun OKAJIMA)
Date: Thu, 24 Nov 2005 20:33:57 +0900
Subject: [LinuxBIOS] Epia-M Status
In-Reply-To: <1132830100.3430.19.camel@localhost.localdomain>
References: <1132830100.3430.19.camel@localhost.localdomain>
Message-ID: <200511241133.AA00498@bbb-jz5c7z9hn9y.digitalinfra.co.jp>

>
>> The VGA Bios has to be extracted like Jun said:
>> 
>>  > # dd if=/dev/mem of=video.bios.bin.4 bs=1 count=65536 skip=786432
>>  > 786432 is 0xc0000, and 790528 which Nich told is 0xc1000.
>

I still can not run X yet.
You do same stuff after booted with Linux BIOS and 
check if you can get same BIOS image as you burned to your flash chip.
Anton Borisov noticed same thing, but in my test, the BIOS image is different!.
I am guessing this could be the cause.
Try it.

                               --- Okajima, Jun. Tokyo, Japan.




From m303 at luusa.org  Thu Nov 24 12:59:09 2005
From: m303 at luusa.org (Martin Ley)
Date: Thu, 24 Nov 2005 12:59:09 +0100
Subject: [LinuxBIOS] Epia-M Status
In-Reply-To: <1132830100.3430.19.camel@localhost.localdomain>
References: <438266C3.6020700@lanl.gov> <43857F21.9060802@luusa.org>
	<1132830100.3430.19.camel@localhost.localdomain>
Message-ID: <4385AB0D.7020205@luusa.org>

tristan schrieb:

>which motherboard/processor do you have exactly? mine is M10000 /
>Nehemiah 1GHz VIA stepping 5.
>
>  
>
Epia M10000

vendor_id       : CentaurHauls
cpu family      : 6
model           : 9
model name      : VIA Nehemiah
stepping        : 3
cpu MHz         : 999.609

>>The VGA Bios has to be extracted like Jun said:
>>
>> > # dd if=/dev/mem of=video.bios.bin.4 bs=1 count=65536 skip=786432
>> > 786432 is 0xc0000, and 790528 which Nich told is 0xc1000.
>>    
>>
>So, wich one using? 786432 or 790528?
>  
>
the extraction of the video BIOS with

#dd if=/dev/mem of=video.bios.bin.4 bs=1 count=65536 skip=786432

is the correct one.

>>I haven't tried X yet.
>>    
>>
>Oh yes please tell us, thx!
>Please also complete wiki for this motherboard ;-)
>
>  
>
Just ran X.org (Debian 6.8.2.dfsg.1-10) with the via drivers at 800x600 
and it looks good but I haven't done any performance testing or higher 
resolutions. The vga and the vesa driver did not work at all.


Martin



From paul at astro.gla.ac.uk  Thu Nov 24 13:18:32 2005
From: paul at astro.gla.ac.uk (Paul Millar)
Date: Thu, 24 Nov 2005 12:18:32 +0000
Subject: [LinuxBIOS] issue 20, island aruma update
In-Reply-To: <20051124091044.GD18470@openbios.org>
References: <43848B77.6090707@lanl.gov> <20051124015918.18705.qmail@cdy.org>
	<20051124091044.GD18470@openbios.org>
Message-ID: <200511241218.33482.paul@astro.gla.ac.uk>

On Thursday 24 November 2005 09:10, Stefan Reinauer wrote:
> I think this is a great idea! We do have a page with supported
> motherboards already, but it tends to get outdated very easily.

<delurk>
Something I've been mulling over is having some simple app that uses lshw (for 
example) to punt the information to some central What-Hardware-Works central 
brain.  lshw can generate XML, so we can do some funky modern XML-based 
data-processing.

Perhaps this app should also allow people to put in some hand-chosen words in 
there.
</delurk>

Cheers,

Paul.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20051124/50b21f5c/attachment.sig>

From stepan at openbios.org  Thu Nov 24 13:42:21 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Thu, 24 Nov 2005 13:42:21 +0100
Subject: [LinuxBIOS] issue 20, island aruma update
In-Reply-To: <200511241218.33482.paul@astro.gla.ac.uk>
References: <43848B77.6090707@lanl.gov> <20051124015918.18705.qmail@cdy.org>
	<20051124091044.GD18470@openbios.org>
	<200511241218.33482.paul@astro.gla.ac.uk>
Message-ID: <20051124124221.GA9517@openbios.org>

* Paul Millar <paul at astro.gla.ac.uk> [051124 13:18]:
> On Thursday 24 November 2005 09:10, Stefan Reinauer wrote:
> > I think this is a great idea! We do have a page with supported
> > motherboards already, but it tends to get outdated very easily.
> 
> <delurk>
> Something I've been mulling over is having some simple app that uses lshw (for 
> example) to punt the information to some central What-Hardware-Works central 
> brain.  lshw can generate XML, so we can do some funky modern XML-based 
> data-processing.
> 
> Perhaps this app should also allow people to put in some hand-chosen words in 
> there.
> </delurk>

Go ahead. We could set up some service on linuxbios.org to receive such
information, collect it and present it.

Can you write such a thing?

Stefan





From okajima at digitalinfra.co.jp  Thu Nov 24 13:58:39 2005
From: okajima at digitalinfra.co.jp (Jun OKAJIMA)
Date: Thu, 24 Nov 2005 21:58:39 +0900
Subject: [LinuxBIOS] Epia-M Status
In-Reply-To: <4385AB0D.7020205@luusa.org>
References: <4385AB0D.7020205@luusa.org>
Message-ID: <200511241258.AA00499@bbb-jz5c7z9hn9y.digitalinfra.co.jp>

>>
>Just ran X.org (Debian 6.8.2.dfsg.1-10) with the via drivers at 800x600 
>and it looks good but I haven't done any performance testing or higher 
>resolutions. The vga and the vesa driver did not work at all.
>
>
>Martin
>

You mean you ran X? then you are the second guy to run X on EPIA-M.

                      --- Okajima.



From paul at astro.gla.ac.uk  Thu Nov 24 16:57:51 2005
From: paul at astro.gla.ac.uk (Paul Millar)
Date: Thu, 24 Nov 2005 15:57:51 +0000
Subject: [LinuxBIOS] issue 20, island aruma update
In-Reply-To: <20051124124221.GA9517@openbios.org>
References: <43848B77.6090707@lanl.gov>
	<200511241218.33482.paul@astro.gla.ac.uk>
	<20051124124221.GA9517@openbios.org>
Message-ID: <200511241558.03023.paul@astro.gla.ac.uk>

On Thursday 24 November 2005 12:42, Stefan Reinauer wrote:
> > Something I've been mulling over is having some simple app that uses lshw
> > (for example) to punt the information to some central What-Hardware-Works
> > central brain.
>
> Go ahead. We could set up some service on linuxbios.org to receive such
> information, collect it and present it.
>
> Can you write such a thing?

Technically, yes, I believe I can.  The problem is the usual: not having 
enough free time.

That said, I can have a look into it.  What sort of information should be 
stored, d'ya think?  There looks to be a lot of potentially useful info in 
there.  Is any of it stuff that people are likely to consider private or 
sensitive?

Cheers,

Paul.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20051124/9c847776/attachment.sig>

From smithbone at gmail.com  Thu Nov 24 18:47:37 2005
From: smithbone at gmail.com (Richard Smith)
Date: Thu, 24 Nov 2005 11:47:37 -0600
Subject: [LinuxBIOS] issue 20, island aruma update
In-Reply-To: <20051124112904.20531.qmail@cdy.org>
References: <4384D0F1.5000803@lanl.gov>
	<8a0c36780511231249n6f159229l9fc4c84baca014f9@mail.gmail.com>
	<4384D707.2080502@lanl.gov>
	<8a0c36780511231304n7bc364e8n3729b9208ee58cd8@mail.gmail.com>
	<4384D9DA.7090600@lanl.gov> <20051124015918.18705.qmail@cdy.org>
	<20051124091044.GD18470@openbios.org>
	<20051124095406.9137.qmail@cdy.org>
	<20051124100938.GA5163@openbios.org>
	<20051124112904.20531.qmail@cdy.org>
Message-ID: <8a0c36780511240947n2fa7cc49nbbe81bb46b4263d5@mail.gmail.com>

On 11/24/05, Peter Stuge <stuge-linuxbios at cdy.org> wrote:
> On Thu, Nov 24, 2005 at 11:09:38AM +0100, Stefan Reinauer wrote:
> > > Should I add it to the top of that page or just make a new page?
> >
> > I'd prefer a new page which is linked from the old one.
>
> I agree.
>
> http://wiki.linuxbios.org/index.php/Confirmed_working_svn_revisions
>
> I'll try to update it whenever I see confirmations on the list, but
> by all means feel free to beat me to it. :)

I suggest some sort of date updated.  Perhpas the wiki does this automatically?

You may also want to add that the page is new and needs people to
submit success stories.  For all the viewers that hit the page that
are not on the lb list.

--
Richard A. Smith



From smithbone at gmail.com  Thu Nov 24 18:58:42 2005
From: smithbone at gmail.com (Richard Smith)
Date: Thu, 24 Nov 2005 11:58:42 -0600
Subject: [LinuxBIOS] issue 20, island aruma update
In-Reply-To: <200511241218.33482.paul@astro.gla.ac.uk>
References: <43848B77.6090707@lanl.gov> <20051124015918.18705.qmail@cdy.org>
	<20051124091044.GD18470@openbios.org>
	<200511241218.33482.paul@astro.gla.ac.uk>
Message-ID: <8a0c36780511240958m4c59b70cp8ff1ca72d1f3e911@mail.gmail.com>

> Something I've been mulling over is having some simple app that uses lshw (for
> example) to punt the information to some central What-Hardware-Works central

I see lshw understands OpenFirmware.  What would be really cool is if
it could be made to understand linuxbios tables as well.

Even more cool would be using all this data to automate the "Does LB
work on my main board?" question that hits the list all the time.

The user would do an lshw and then send it to the "brain" which would
report back success reports based on matching hardware.  I think a
fairly simple matching scheme would work.

ie:
 for each device in lshw tree:
     if exists success board rpt with matching device:
        append sucess report.
 send report

That way you would get back a listing of all boards that had at least
one of your devices on them.  So in the case where the board is not
supported directly the user would be able to cherry pick the parts and
perhaps produce the framework of a working setup.

--
Richard A. Smith



From smithbone at gmail.com  Thu Nov 24 19:00:48 2005
From: smithbone at gmail.com (Richard Smith)
Date: Thu, 24 Nov 2005 12:00:48 -0600
Subject: [LinuxBIOS] issue 20, island aruma update
In-Reply-To: <4384A061.1020402@lanl.gov>
References: <4383F0DA.3030909@lanl.gov> <20051123130345.GA28320@openbios.org>
	<43848B77.6090707@lanl.gov>
	<8a0c36780511230840t42f57c22ubeb0664375db3a28@mail.gmail.com>
	<4384A061.1020402@lanl.gov>
Message-ID: <8a0c36780511241000u7bbd9982od3fba24640aeaf63@mail.gmail.com>

> Also, it's not clear that CAR won't work on these other platforms, now
> that we know the "CAR trick". It has not been tested. I suspect it will
> work on VIA.

So what is this magical "trick."  First I've heard of talk for a universal CAR.

--
Richard A. Smith



From yinghailu at gmail.com  Thu Nov 24 19:55:45 2005
From: yinghailu at gmail.com (yhlu)
Date: Thu, 24 Nov 2005 10:55:45 -0800
Subject: [LinuxBIOS] issue 20, island aruma update
In-Reply-To: <8a0c36780511241000u7bbd9982od3fba24640aeaf63@mail.gmail.com>
References: <4383F0DA.3030909@lanl.gov> <20051123130345.GA28320@openbios.org>
	<43848B77.6090707@lanl.gov>
	<8a0c36780511230840t42f57c22ubeb0664375db3a28@mail.gmail.com>
	<4384A061.1020402@lanl.gov>
	<8a0c36780511241000u7bbd9982od3fba24640aeaf63@mail.gmail.com>
Message-ID: <2ea3fae10511241055o30b47028l8f24194a3f5d057e@mail.gmail.com>

Please look at the src/cpu/amd/car..., and cache_as_ram_auto.c

only difference is for Intel need to disable Hyperthreading at first....

So if you got time, try on other platform

Because of CAR, is much fast than ROMCC, you may have some problem
with timing....

YH

On 11/24/05, Richard Smith <smithbone at gmail.com> wrote:
> > Also, it's not clear that CAR won't work on these other platforms, now
> > that we know the "CAR trick". It has not been tested. I suspect it will
> > work on VIA.
>
> So what is this magical "trick."  First I've heard of talk for a universal CAR.
>
> --
> Richard A. Smith
>
> --
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



From rminnich at lanl.gov  Thu Nov 24 20:44:28 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 24 Nov 2005 12:44:28 -0700
Subject: [LinuxBIOS] issue 20, island aruma update
In-Reply-To: <8a0c36780511240947n2fa7cc49nbbe81bb46b4263d5@mail.gmail.com>
References: <4384D0F1.5000803@lanl.gov>	<8a0c36780511231249n6f159229l9fc4c84baca014f9@mail.gmail.com>	<4384D707.2080502@lanl.gov>	<8a0c36780511231304n7bc364e8n3729b9208ee58cd8@mail.gmail.com>	<4384D9DA.7090600@lanl.gov>
	<20051124015918.18705.qmail@cdy.org>	<20051124091044.GD18470@openbios.org>	<20051124095406.9137.qmail@cdy.org>	<20051124100938.GA5163@openbios.org>	<20051124112904.20531.qmail@cdy.org>
	<8a0c36780511240947n2fa7cc49nbbe81bb46b4263d5@mail.gmail.com>
Message-ID: <4386181C.30507@lanl.gov>

Richard Smith wrote:
> On 11/24/05, Peter Stuge <stuge-linuxbios at cdy.org> wrote:
> 
>>On Thu, Nov 24, 2005 at 11:09:38AM +0100, Stefan Reinauer wrote:
>>
>>>>Should I add it to the top of that page or just make a new page?
>>>
>>>I'd prefer a new page which is linked from the old one.
>>
>>I agree.
>>
>>http://wiki.linuxbios.org/index.php/Confirmed_working_svn_revisions
>>
>>I'll try to update it whenever I see confirmations on the list, but
>>by all means feel free to beat me to it. :)
> 
> 
> I suggest some sort of date updated.  Perhpas the wiki does this automatically?
> 
> You may also want to add that the page is new and needs people to
> submit success stories.  For all the viewers that hit the page that
> are not on the lb list.

this page is really wonderful, though. It's just what we needed.

ron



From rminnich at lanl.gov  Thu Nov 24 20:45:00 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 24 Nov 2005 12:45:00 -0700
Subject: [LinuxBIOS] issue 20, island aruma update
In-Reply-To: <200511241218.33482.paul@astro.gla.ac.uk>
References: <43848B77.6090707@lanl.gov>
	<20051124015918.18705.qmail@cdy.org>	<20051124091044.GD18470@openbios.org>
	<200511241218.33482.paul@astro.gla.ac.uk>
Message-ID: <4386183C.8070201@lanl.gov>

Paul Millar wrote:
> On Thursday 24 November 2005 09:10, Stefan Reinauer wrote:
> 
>>I think this is a great idea! We do have a page with supported
>>motherboards already, but it tends to get outdated very easily.
> 
> 
> <delurk>
> Something I've been mulling over is having some simple app that uses lshw (for 
> example) to punt the information to some central What-Hardware-Works central 
> brain.  lshw can generate XML, so we can do some funky modern XML-based 
> data-processing.
> 
> Perhaps this app should also allow people to put in some hand-chosen words in 
> there.
> </delurk>

sure, if you want to prototype it let's take a look.

Thanks for lurking :-)

ron



From rminnich at lanl.gov  Thu Nov 24 20:50:05 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 24 Nov 2005 12:50:05 -0700
Subject: [LinuxBIOS] Epia-M Status
In-Reply-To: <43857F21.9060802@luusa.org>
References: <438266C3.6020700@lanl.gov> <43857F21.9060802@luusa.org>
Message-ID: <4386196D.9040004@lanl.gov>

Martin Ley wrote:
> Hi list,
> 
> 
> I just checked out a fresh new version (2100) of LinuxBiosV2. Epia-M 
> builds (default-config) and boots with VGA.
> 
> The VGA Bios has to be extracted like Jun said:
> 
>  > # dd if=/dev/mem of=video.bios.bin.4 bs=1 count=65536 skip=786432
>  > 786432 is 0xc0000, and 790528 which Nich told is 0xc1000.
> 
> I haven't tried X yet.

wow, this is WONDERFUL news. We maybe have a solid epia-m in the tree!

thanks!

ron



From rminnich at lanl.gov  Thu Nov 24 20:54:34 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 24 Nov 2005 12:54:34 -0700
Subject: [LinuxBIOS] issue 20, island aruma update
In-Reply-To: <8a0c36780511241000u7bbd9982od3fba24640aeaf63@mail.gmail.com>
References: <4383F0DA.3030909@lanl.gov> <20051123130345.GA28320@openbios.org>	
	<43848B77.6090707@lanl.gov>	
	<8a0c36780511230840t42f57c22ubeb0664375db3a28@mail.gmail.com>	
	<4384A061.1020402@lanl.gov>
	<8a0c36780511241000u7bbd9982od3fba24640aeaf63@mail.gmail.com>
Message-ID: <43861A7A.6030601@lanl.gov>

Richard Smith wrote:
>>Also, it's not clear that CAR won't work on these other platforms, now
>>that we know the "CAR trick". It has not been tested. I suspect it will
>>work on VIA.
> 
> 
> So what is this magical "trick."  First I've heard of talk for a universal CAR.
> 
> --
> Richard A. Smith

eswar, let's get your slides up on the wiki. I would like to get all the 
presentations made at linuxbios summit up there. I uploaded mine, but 
then couldn't figure out how to set up the links to them.

ron



From a.borisov at tesv.tmb.ru  Sat Nov 26 11:43:44 2005
From: a.borisov at tesv.tmb.ru (Anton Borisov)
Date: Sat, 26 Nov 2005 13:43:44 +0300
Subject: [LinuxBIOS] God bless Debian
Message-ID: <20051126134344.1a7910ff.a.borisov@tesv.tmb.ru>

Hi.
	After some unsuccessful attempts to run X with EPIA-M (4-bit with 'vga' driver is out of score) I could finally experience full color and quite stable video playback at 1280x1024x16 resolution. So it seems to me I'm the third person after Martin Ley and Jun Okajima to see the how EPIA-M is performing with video enabled ;-)

	What I've done:

1) xorg.conf - should be enabled one option (it is essential): Option "NoAccel" "yes". 
2) 'via' driver. I used the one from unichrome project (via_drv.o-unichrome_X_r20-debian_sarge_xfree86-4.3.0.dfsg.1-1) and Martin's Ley driver (from his debian box).
3) ran x11perf

	Video playback with MPlayer ('xv' video output driver) is quite smooth. "Hitchhiker's Guide to The Galaxy" encoded as DX50 with 520x300 pixels is played at 30% of CPU workload. I'm not sure that x11perf will present all necessary charts so I'm asking you - which X11 benchmark should be used to measure all parrots?

	Thanks.

-- 
Sincerely, Anton Borisov



From grzegorz at el-kom.pl  Sat Nov 26 12:50:43 2005
From: grzegorz at el-kom.pl (Grzegorz...)
Date: Sat, 26 Nov 2005 12:50:43 +0100
Subject: [LinuxBIOS] Epia-m: Unknown CPU
Message-ID: <200511261250.43298.grzegorz@el-kom.pl>

Hello.

Mainboard: Via Epia-m 10000

LinuxBIOSv2 reports:

CPU: vendor Centaur device 691
Unknown CPU

If anyone have this problem just add one line

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

 in 

LinuxBIOSv2/src/cpu/via/model_centaur/model_centaur_init.c



-- 
Grzegorz...
.:| www.El-Kom.pl |:.
Internet, sieci, sprzet, oprogramowanie i wiele, wiele wiecej



From rminnich at gmail.com  Sat Nov 26 22:22:10 2005
From: rminnich at gmail.com (ron minnich)
Date: Sat, 26 Nov 2005 14:22:10 -0700
Subject: [LinuxBIOS] God bless Debian
In-Reply-To: <20051126134344.1a7910ff.a.borisov@tesv.tmb.ru>
References: <20051126134344.1a7910ff.a.borisov@tesv.tmb.ru>
Message-ID: <13426df10511261322x72e6f724y438e031eab3f8bb0@mail.gmail.com>

If someone would like to write a comprehensive epia-m HOWTO I will put it in
the linuxbios HOWTO directory.

thanks

ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20051126/006f4a3a/attachment.html>

From rminnich at gmail.com  Sat Nov 26 22:29:31 2005
From: rminnich at gmail.com (ron minnich)
Date: Sat, 26 Nov 2005 14:29:31 -0700
Subject: [LinuxBIOS] Epia-m: Unknown CPU
In-Reply-To: <200511261250.43298.grzegorz@el-kom.pl>
References: <200511261250.43298.grzegorz@el-kom.pl>
Message-ID: <13426df10511261329y64a4b075yb6f4e3509528405b@mail.gmail.com>

On 11/26/05, Grzegorz... <grzegorz at el-kom.pl> wrote:
>
> Hello.
>
> Mainboard: Via Epia-m 10000
>
> LinuxBIOSv2 reports:
>
> CPU: vendor Centaur device 691
> Unknown CPU
>
> If anyone have this problem just add one line
>
> { X86_VENDOR_CENTAUR, 0x0691 },         // VIA C3 Nehemiah
>
> I just checked and that is in there -- I did it a few days ago. Can you
svn update and see if
it is there?

ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20051126/676d219e/attachment.html>

From stepan at openbios.org  Sat Nov 26 22:37:05 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Sat, 26 Nov 2005 22:37:05 +0100
Subject: [LinuxBIOS] Epia-m: Unknown CPU
In-Reply-To: <13426df10511261329y64a4b075yb6f4e3509528405b@mail.gmail.com>
References: <200511261250.43298.grzegorz@el-kom.pl>
	<13426df10511261329y64a4b075yb6f4e3509528405b@mail.gmail.com>
Message-ID: <20051126213705.GA1194@openbios.org>

* ron minnich <rminnich at gmail.com> [051126 22:29]:
> 
>     Mainboard: Via Epia-m 10000
> 
>     LinuxBIOSv2 reports:
> 
>     CPU: vendor Centaur device 691
>     Unknown CPU
> 
>     If anyone have this problem just add one line
> 
>     { X86_VENDOR_CENTAUR, 0x0691 },         // VIA C3 Nehemiah
> 
> 
> I just checked and that is in there -- I did it a few days ago. Can you svn
> update and see if
> it is there?

It was added in r2108. Be sure, to use at least this revision.

Stefan




From stepan at openbios.org  Sat Nov 26 22:43:27 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Sat, 26 Nov 2005 22:43:27 +0100
Subject: [LinuxBIOS] God bless Debian
In-Reply-To: <13426df10511261322x72e6f724y438e031eab3f8bb0@mail.gmail.com>
References: <20051126134344.1a7910ff.a.borisov@tesv.tmb.ru>
	<13426df10511261322x72e6f724y438e031eab3f8bb0@mail.gmail.com>
Message-ID: <20051126214327.GA1271@openbios.org>

* ron minnich <rminnich at gmail.com> [051126 22:22]:
> If someone would like to write a comprehensive epia-m HOWTO I will put it in
> the linuxbios HOWTO directory.

Maybe someone wants to update this one?

http://www.linuxbios.org/index.php/The_EPIA-M/MII





From okajima at digitalinfra.co.jp  Tue Nov 29 02:33:45 2005
From: okajima at digitalinfra.co.jp (Jun OKAJIMA)
Date: Tue, 29 Nov 2005 10:33:45 +0900
Subject: [LinuxBIOS] I want Windows booting
Message-ID: <200511290133.AA00505@bbb-jz5c7z9hn9y.digitalinfra.co.jp>




Hello.

Current ADLO can not boot XP. Then, how about using freeldr as payload?
You must know freeldr already, but if I would explain shortly,
it is a clone of NTLDR, a boot loader of WindowsNT/2k/XP.
And it is one of products of ReactOS project.
Currently it can just boot ReactOS, which will be a clone of Windows itself,
and can not boot genuine Windows. But plan to be able to boot guenuie one someday.

Then, if once it becomes to be able to boot guenie Windows, how about using it
as payload? if doing so, it is yet another way of booting Windows than ADLO.


BTW, somebody help to work X on EPIA-M!.
Why 0xc0000 data changes after boot?

                   --- Okajima, Jun, Tokyo, Japan.



From stuge-linuxbios at cdy.org  Tue Nov 29 12:12:45 2005
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Tue, 29 Nov 2005 12:12:45 +0100
Subject: [LinuxBIOS] I want Windows booting
In-Reply-To: <200511290133.AA00505@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
References: <200511290133.AA00505@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
Message-ID: <20051129111245.12294.qmail@cdy.org>

On Tue, Nov 29, 2005 at 10:33:45AM +0900, Jun OKAJIMA wrote:

[..freeldr..]

> Then, if once it becomes to be able to boot guenie Windows, how
> about using it as payload?

Sure, as long as freeldr does not require any traditional interrupt
services, it will work just fine as a payload.


> if doing so, it is yet another way of booting Windows than ADLO.

In the event that freeldr provides all required interrupt services
for Windows XP early start, it should work well.

I would probably look at extending the ADLO/Bochs combination to
implement whatever is missing for XP though. It may not be at all
much. But then again, it may be months.


//Peter



From smithbone at gmail.com  Tue Nov 29 14:25:00 2005
From: smithbone at gmail.com (Richard Smith)
Date: Tue, 29 Nov 2005 07:25:00 -0600
Subject: [LinuxBIOS] I want Windows booting
In-Reply-To: <20051129111245.12294.qmail@cdy.org>
References: <200511290133.AA00505@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
	<20051129111245.12294.qmail@cdy.org>
Message-ID: <8a0c36780511290525u7b2b315fs9575a06c1c47785@mail.gmail.com>

>
> I would probably look at extending the ADLO/Bochs combination to
> implement whatever is missing for XP though. It may not be at all
> much. But then again, it may be months.

According to the bochs website XP is reported to work under bochs.  If
so then all that would be needed is an upgrade of the copy of bochs
bios.  That should get you all the necessary bios services.

I tried this probally a year or so ago but it breaks the IDE
interface.   Since at the time the new bios didn't really offer that
much in the way of new features I didn't continue.

Fixing the IDE should be pretty simple.  Diffing the ide routines to
the current shows what Adam did to make them work.

--
Richard A. Smith



From joep at frog.nl  Wed Nov 30 14:29:28 2005
From: joep at frog.nl (Joep Jansen)
Date: Wed, 30 Nov 2005 14:29:28 +0100
Subject: [LinuxBIOS] LinuxBios on ETX-mgx Geode GX1 platform
Message-ID: <438DA938.1060000@frog.nl>

Hello,

I would like to use LinuxBIOS on an embedded Geode GX1 platform.
The board is an Kontron ETX-mgx, and is has the following parts on board:

* CPU: Geode GX1 266 MHz

* Southbridge: CS5530A

* Superio: Winbond W83977F:
   IDE, floppy, 2x serial, parallel port

* Phoenix BIOS 4.0 in a Am29F040B 512kx8 flash chip (TSOP package)

* 64 MB PCI 133 DIMM

* Compact flash slot

* USB controller (Compaq ZFMicor Chipset)

* Ethernet: Davicom DM9102AE

I want to use LinuxBIOS with FILO to boot a linux kernel from the IDE 
Compact Flash.
My idea is to piggyback an empty flash chip on top of the BIOS flash 
chip, and then use a switch to select the original
BIOS or a newly flashed one.

I am new on this list, and would appreciate some help to get this 
project on the road!

My question is:

What would be the best way to get this started?

Can I use LinuxBIOSv1 or LinuxBIOSv2?
LinuxBIOSv2 seems newer, but it seems to lack support for the W83977F.

Thanks for any help!

Joep









From bari at onelabs.com  Wed Nov 30 15:19:18 2005
From: bari at onelabs.com (Bari Ari)
Date: Wed, 30 Nov 2005 08:19:18 -0600
Subject: [LinuxBIOS] LinuxBios on ETX-mgx Geode GX1 platform
In-Reply-To: <438DA938.1060000@frog.nl>
References: <438DA938.1060000@frog.nl>
Message-ID: <438DB4E6.6030009@onelabs.com>

Joep Jansen wrote:

> I want to use LinuxBIOS with FILO to boot a linux kernel from the IDE 
> Compact Flash.
> My idea is to piggyback an empty flash chip on top of the BIOS flash 
> chip, and then use a switch to select the original
> BIOS or a newly flashed one.

It's already been done. See if you can find a BIOS Savior:
http://www.linuxbios.org/index.php/FAQ#What_kind_of_hardware_tools_do_I_need.3F
  http://www.ioss.com.tw/web/English/RD1BIOSSavior.html
  http://www.cwlinux.com/eng/products/products_lbmb.php

> I am new on this list, and would appreciate some help to get this 
> project on the road!
> 
> My question is:
> 
> What would be the best way to get this started?
> 
> Can I use LinuxBIOSv1 or LinuxBIOSv2?
> LinuxBIOSv2 seems newer, but it seems to lack support for the W83977F.

The source from V1 for the 83977 can be updated for V2. V2 is the 
version that is currently being developed. Hamish was working on the V2 
port for geodes.

-Bari




From Kalyankumar.Sanagavarapu at honeywell.com  Wed Nov 30 15:21:05 2005
From: Kalyankumar.Sanagavarapu at honeywell.com (Kalyankumar,
	Sanagavarapu (IE10))
Date: Wed, 30 Nov 2005 19:51:05 +0530
Subject: [LinuxBIOS] Bochs is too slow while loading the Linux
Message-ID: <9F4FA7B367FAAD4E9D78594B289244FA04D0FC59@IE10EV801.global.ds.honeywell.com>

Sir,
    I am using freebios to load Linux on SC2200 (GEODE platform).
    I am using Bochs for the interrupt callback support.
    LinuxBIOS loads Bochs into the RAM and gives control to it 
   Bochs in turn loads Linux.
    Linux kernel size is around 512 MB.
    Bochs is taking around 12 sec to load Linux which is unacceptable as
per as system requirements.
    
    Bochs itself is too slow in executing the things.
    I observed that it is around 20 times slow than LinuxBIOS which is
executing before Bochs.
 
    Please help me in fixing this problem.
Thanks in advance
 
Regards,
Kalyan.
 
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20051130/b4f88741/attachment.html>

From joep at frog.nl  Wed Nov 30 15:41:55 2005
From: joep at frog.nl (Joep Jansen)
Date: Wed, 30 Nov 2005 15:41:55 +0100
Subject: [LinuxBIOS] LinuxBios on ETX-mgx Geode GX1 platform
In-Reply-To: <438DB4E6.6030009@onelabs.com>
References: <438DA938.1060000@frog.nl> <438DB4E6.6030009@onelabs.com>
Message-ID: <438DBA33.5040200@frog.nl>

I looked at the BIOS Savior, but it will do not good since the flash 
chip is a TSOP, directly soldered to the board.
The "piggyback" trick seems the most viable solution, but it will 
requilre some skill and good equipment ;-).

I will try the LinuxBIOSv2 path, and see where it brings me.

Thanks,

Joep

Bari Ari wrote:

> Joep Jansen wrote:
>
>> I want to use LinuxBIOS with FILO to boot a linux kernel from the IDE 
>> Compact Flash.
>> My idea is to piggyback an empty flash chip on top of the BIOS flash 
>> chip, and then use a switch to select the original
>> BIOS or a newly flashed one.
>
>
> It's already been done. See if you can find a BIOS Savior:
> http://www.linuxbios.org/index.php/FAQ#What_kind_of_hardware_tools_do_I_need.3F 
>
>  http://www.ioss.com.tw/web/English/RD1BIOSSavior.html
>  http://www.cwlinux.com/eng/products/products_lbmb.php
>
>> I am new on this list, and would appreciate some help to get this 
>> project on the road!
>>
>> My question is:
>>
>> What would be the best way to get this started?
>>
>> Can I use LinuxBIOSv1 or LinuxBIOSv2?
>> LinuxBIOSv2 seems newer, but it seems to lack support for the W83977F.
>
>
> The source from V1 for the 83977 can be updated for V2. V2 is the 
> version that is currently being developed. Hamish was working on the 
> V2 port for geodes.
>
> -Bari
>




From rminnich at lanl.gov  Wed Nov 30 15:59:06 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 30 Nov 2005 07:59:06 -0700
Subject: [LinuxBIOS] Bochs is too slow while loading the Linux
In-Reply-To: <9F4FA7B367FAAD4E9D78594B289244FA04D0FC59@IE10EV801.global.ds.honeywell.com>
References: <9F4FA7B367FAAD4E9D78594B289244FA04D0FC59@IE10EV801.global.ds.honeywell.com>
Message-ID: <438DBE3A.9090009@lanl.gov>

Kalyankumar, Sanagavarapu (IE10) wrote:
> Sir,
>     I am using freebios to load Linux on SC2200 (GEODE platform).
>     I am using Bochs for the interrupt callback support.
>     LinuxBIOS loads Bochs into the RAM and gives control to it
>    Bochs in turn loads Linux.
>     Linux kernel size is around 512 MB.
>     Bochs is taking around 12 sec to load Linux which is unacceptable as 
> per as system requirements.
>    
>     Bochs itself is too slow in executing the things.
>     I observed that it is around 20 times slow than LinuxBIOS which is 
> executing before Bochs.
>  
>     Please help me in fixing this problem.
> Thanks in advance
>  
> Regards,
> Kalyan.
>  
>  
>  
> 

why on earth are you using bochs to load linux? that is totally unnecessary.

ron



From smithbone at gmail.com  Wed Nov 30 18:01:19 2005
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 30 Nov 2005 11:01:19 -0600
Subject: [LinuxBIOS] Bochs is too slow while loading the Linux
In-Reply-To: <438DBE3A.9090009@lanl.gov>
References: <9F4FA7B367FAAD4E9D78594B289244FA04D0FC59@IE10EV801.global.ds.honeywell.com>
	<438DBE3A.9090009@lanl.gov>
Message-ID: <8a0c36780511300901w4b32559byfadaa8b5c3748ffc@mail.gmail.com>

>
> why on earth are you using bochs to load linux? that is totally unnecessary.

As ron says you dont need bochs to load linux.  However, using your
numbers you provided
512Megs in 12 seconds would be 43 MB/s.   To achieve that rate you
must be using either a RAID setup or a >= 10k rpm drive.  That might
explain why you need Bochs.

40 to 50 MB/s jives with what I see as the average stream speed for a
10k drive.  So from the info you have provided it looks like to me
that your limit is not Bochs but rather the IO stream speed of the
media you are loading from.  Unless you are using some sort of raid
array.

Rather than attempting to speed up the load time perhaps you should
attempt to reduce the size of your image that you need to load. 
Perhaps break it into 2 parts with a smaller initrd that loads a
bigger ramdisk and then piviot root.  IO access routines in Linux will
be more close to optimal than Bochs routines.

> >     Bochs itself is too slow in executing the things.
> >     I observed that it is around 20 times slow than LinuxBIOS which is
> > executing before Bochs.

How did you measure this?

Bochs runs in real mode rather than protected but other than the fact
that it uses i386 instructions so yeah it might be a bit slower but 20
times seems excessive.  Perhaps your ADLO shadow area init is doing
something to mess up the cache settings?

--
Richard A. Smith



From yinghai.lu at amd.com  Wed Nov 30 18:27:45 2005
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Wed, 30 Nov 2005 09:27:45 -0800
Subject: [LinuxBIOS] about the put sb chain on bus 0 and let sb ht end
 device use unitid 1
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4203094968@ssvlexmb2.amd.com>

I added some code to make 
1. sb ht chain sit on bus 0
2. let HT chain end device use small unit id..

So We can make the bus num and device num to be same to system BIOS. It
maybe useful to let use compare mptable/irqtable/acpi tables....

I will produce one patch after you apply issue36 and issue 37 to the
public tree.

YH




From stepan at openbios.org  Wed Nov 30 19:05:51 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Wed, 30 Nov 2005 19:05:51 +0100
Subject: [LinuxBIOS] Bochs is too slow while loading the Linux
In-Reply-To: <9F4FA7B367FAAD4E9D78594B289244FA04D0FC59@IE10EV801.global.ds.honeywell.com>
References: <9F4FA7B367FAAD4E9D78594B289244FA04D0FC59@IE10EV801.global.ds.honeywell.com>
Message-ID: <20051130180551.GA26784@openbios.org>

Sir,

>     Linux kernel size is around 512 MB.
>     Bochs is taking around 12 sec to load Linux which is unacceptable
>     as per as system requirements.

You will probably have to get a faster hard drive. With the numbers you
provided this gets down to about 43 Megabytes per second, which is not
too bad.

The question is: 

- Why do you need such a big kernel?

>     Bochs itself is too slow in executing the things.
>     I observed that it is around 20 times slow than LinuxBIOS which is
> executing before Bochs.
>  
>     Please help me in fixing this problem.
> Thanks in advance

Use LinuxBIOS directly, or use filo.

http://www.linuxbios.org/index.php/FILO

Best regards,

Stefan







From justin at street-vision.com  Wed Nov 30 19:08:31 2005
From: justin at street-vision.com (Justin Cormack)
Date: Wed, 30 Nov 2005 18:08:31 +0000
Subject: [LinuxBIOS] Bochs is too slow while loading the Linux
In-Reply-To: <8a0c36780511300901w4b32559byfadaa8b5c3748ffc@mail.gmail.com>
References: <9F4FA7B367FAAD4E9D78594B289244FA04D0FC59@IE10EV801.global.ds.honeywell.com>
	<438DBE3A.9090009@lanl.gov>
	<8a0c36780511300901w4b32559byfadaa8b5c3748ffc@mail.gmail.com>
Message-ID: <1133374111.1602.8.camel@scrod.vision>

On Wed, 2005-11-30 at 11:01 -0600, Richard Smith wrote:
> >
> > why on earth are you using bochs to load linux? that is totally unnecessary.
> 
> As ron says you dont need bochs to load linux.  However, using your
> numbers you provided
> 512Megs in 12 seconds would be 43 MB/s.   To achieve that rate you
> must be using either a RAID setup or a >= 10k rpm drive.  That might
> explain why you need Bochs.

New 7200 rpm IDE disks give 60MB/s off the front end.

So not clear why Bochs is necessary.