Re: [coreboot] Phoenix Technologies and General Software

2009-09-02 Thread Andrew Goodbody

greg wrote:

Now Andrew if we could track down a collection of Tadpole VME bus based
boards wearing the M68K family of processors..
(Ignore that remark fellow Coreboot participants, that's a side-remark to
Andrew G.


Now if I could only find a spare VME chasis to put this here TP43M in,
I could have a fiddle with it... :)

greg



Sorry guys but that's the wrong Tadpole. AFAIK the VME stuff was by 
Tadpole Technology which is I believe no longer in existence. I work for 
what is left of Tadpole Computer.


Andrew

--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot


Re: [coreboot] SeaBIOS WinXP install

2009-09-02 Thread Myles Watson
 Here is the lspci for both legacy and coreboot :
 ---
 legacy :
 00:1f.2 IDE interface: Intel Corporation EP80579 S-ATA IDE (rev 01)
 (prog-if 8f [Master SecP SecO PriP PriO])
 Subsystem: Intel Corporation EP80579 S-ATA IDE
 Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 58
 I/O ports at f080 [size=8]
 I/O ports at f070 [size=4]
 I/O ports at f060 [size=8]
 I/O ports at f050 [size=4]
 I/O ports at f040 [size=16]
 Memory at d010 (32-bit, non-prefetchable) [size=1K]
 Capabilities: [70] Power Management version 2
 
 00:1f.2 IDE interface: Intel Corporation EP80579 S-ATA IDE (rev 01)
 (prog-if 8f [Master SecP SecO PriP PriO])
 Subsystem: Intel Corporation Unknown device 2680
 Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 145
 I/O ports at 2410 [size=8]
 I/O ports at 2420 [size=4]
 I/O ports at 2418 [size=8]
 I/O ports at 2424 [size=4]
 I/O ports at 2400 [size=16]
 Memory at d4a07400 (32-bit, non-prefetchable) [size=1K]
 Capabilities: [70] Power Management version 2
 
 Actually same except io ports are located another place and the
 subsystem IDs is set differently by the driver. I do
 not think the last one would cause any troubles.
I don't think the IO port location is a problem, unless it conflicts with
something in the DSDT.  The IRQ setting is also different. 145 seems pretty
high.

Thanks,
Myles



-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot


Re: [coreboot] SeaBIOS WinXP install

2009-09-02 Thread Arnaud Maye

Myles Watson wrote:

Here is the lspci for both legacy and coreboot :
---
legacy :
00:1f.2 IDE interface: Intel Corporation EP80579 S-ATA IDE (rev 01)
(prog-if 8f [Master SecP SecO PriP PriO])
Subsystem: Intel Corporation EP80579 S-ATA IDE
Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 58
I/O ports at f080 [size=8]
I/O ports at f070 [size=4]
I/O ports at f060 [size=8]
I/O ports at f050 [size=4]
I/O ports at f040 [size=16]
Memory at d010 (32-bit, non-prefetchable) [size=1K]
Capabilities: [70] Power Management version 2

00:1f.2 IDE interface: Intel Corporation EP80579 S-ATA IDE (rev 01)
(prog-if 8f [Master SecP SecO PriP PriO])
Subsystem: Intel Corporation Unknown device 2680
Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 145
I/O ports at 2410 [size=8]
I/O ports at 2420 [size=4]
I/O ports at 2418 [size=8]
I/O ports at 2424 [size=4]
I/O ports at 2400 [size=16]
Memory at d4a07400 (32-bit, non-prefetchable) [size=1K]
Capabilities: [70] Power Management version 2

Actually same except io ports are located another place and the
subsystem IDs is set differently by the driver. I do
not think the last one would cause any troubles.


I don't think the IO port location is a problem, unless it conflicts with
something in the DSDT.  The IRQ setting is also different. 145 seems pretty
high.
  
What this IRQ 145 (or 58) relates to. On the legacy BIOS this is an 
ACPI=force boot and on coreboot
this is an ACPI=off. Is this IRQ assigned by coreboot, by seabios or the 
operating system. I just want to

verify if this is normal or not.

Thank you,

Arnaud

--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot


Re: [coreboot] SeaBIOS WinXP install

2009-09-02 Thread Myles Watson
  I don't think the IO port location is a problem, unless it conflicts
 with
  something in the DSDT.  The IRQ setting is also different. 145 seems
 pretty
  high.
 
 What this IRQ 145 (or 58) relates to. On the legacy BIOS this is an
 ACPI=force boot and on coreboot
 this is an ACPI=off. Is this IRQ assigned by coreboot, by seabios or the
 operating system. I just want to
 verify if this is normal or not.

I wish I knew more about it.  Here's the part of Rudolf's page about that:
http://www.coreboot.org/ACPI_in_coreboot#Interrupt_routing_in_DSDT

My understanding is that the IRQs are specified as offsets from IOAPICs,
each of which supply some number of IRQs.  If your DSDT specifies this
differently than the chipset was configured by Coreboot, it breaks.

Myles




-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot


[coreboot] PATCH: do not rely on tempfile being available

2009-09-02 Thread Bernie Innocenti
Signed-off-by: Bernie Innocenti ber...@codewiz.org

Build fix: add a fallback for systems where tempfile is missing

Index: bin/show-instructions.sh
===
--- bin/show-instructions.sh(revision 261)
+++ bin/show-instructions.sh(working copy)
@@ -1,6 +1,6 @@
 #!/bin/sh
 
-tmp=`tempfile`
+tmp=`tempfile 2/dev/null || echo /tmp/show-instructions.$$`
 cat $1 | sed -e s:%DESTFILE%:$2:  $tmp
 
 if [ -x `dirname $0`/../scripts/kconfig/lxdialog/lxdialog ]; then

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs   - http://sugarlabs.org/


-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot


[coreboot] [BuildROM] r271 - buildrom-devel/bin

2009-09-02 Thread svn
Author: ward
Date: 2009-09-02 23:41:13 +0200 (Wed, 02 Sep 2009)
New Revision: 271

Modified:
   buildrom-devel/bin/show-instructions.sh
Log:

Build fix: add a fallback for systems where tempfile is missing

Signed-off-by: Bernie Innocenti ber...@codewiz.org
Acked-by: Ward Vandewege w...@gnu.org



Modified: buildrom-devel/bin/show-instructions.sh
===
--- buildrom-devel/bin/show-instructions.sh 2009-08-24 16:10:31 UTC (rev 
270)
+++ buildrom-devel/bin/show-instructions.sh 2009-09-02 21:41:13 UTC (rev 
271)
@@ -1,6 +1,6 @@
 #!/bin/sh
 
-tmp=`tempfile`
+tmp=`tempfile 2/dev/null || echo /tmp/show-instructions.$$`
 cat $1 | sed -e s:%DESTFILE%:$2:  $tmp
 
 if [ -x `dirname $0`/../scripts/kconfig/lxdialog/lxdialog ]; then


-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot


Re: [coreboot] PATCH: do not rely on tempfile being available

2009-09-02 Thread Ward Vandewege
On Wed, Sep 02, 2009 at 04:12:21PM -0400, Bernie Innocenti wrote:
 Signed-off-by: Bernie Innocenti ber...@codewiz.org
 
 Build fix: add a fallback for systems where tempfile is missing

Acked-by: Ward Vandewege w...@gnu.org

Committed in r271.

Thanks,
Ward.

-- 
Ward Vandewege w...@fsf.org
Free Software Foundation - Senior Systems Administrator

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot


Re: [coreboot] K8 machine with (a lot of) ram from 2 vendors keeps resetting

2009-09-02 Thread Marc Jones
Hi Ward,

On Wed, Sep 2, 2009 at 3:14 PM, Ward Vandewegew...@gnu.org wrote:
 Hi all,

 I'm having some problems with a supermicro h8dme board with 2 K8 processors
 and 64 GB of ram.

 Sadly, the ram is of two types (that was not my decision :/). We have 8x 4GB
 Samsung M393T5160QZA-CE6 and 8x 4GB Kingston KVR667D2D4P5/4G. Both of these
 types of ram are dual rank DDR2, 667 MHz, CL5, 1.8 V, registered, ECC.

 The memory is installed like this:

 BANK     CPU1        CPU2
 1B       KING        KING
 1A       KING        KING
 2B       KING        KING
 2A       KING        KING
 3B       SAMS        SAMS
 3A       SAMS        SAMS
 4B       SAMS        SAMS
 4A       SAMS        SAMS

 With the proprietary BIOS, this setup works perfectly. That said, the manual
 for the board does say it's not recommended to mix memory types. Our system
 integrator mentions that when 16 banks are used, the memory runs at maximum
 533MHz.

As we talked about, it looks like the memory is sized correctly and
the next thing to try forcing the memory speed slower. 8 dual rank
dimms (16 banks) s[eed limitation might be spec'd or errata. A check
might need to go into the main k8 mem init code.

Marc

-- 
http://marcjonesconsulting.com

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot


[coreboot] LNXI eVelocity 2 BIOS reburn

2009-09-02 Thread Sebastian Lara
Hi,

I'm trying to revive a Linux Netwox eVelocity 2 Cluster with
LinuxBIOS-1.1.7.8 and Etherboot 5.2 on compute nodes. After some
trouble, I have access to a shell after node system installation over
network. My problem now is that I can't get localboot to work.

I need to know if I can re-burn the BIOS with a newer version of
coreboot or something else, so I can use PXE and use GRUB for booting
from local.

Here is my lspci output. Thanks in advance for any help

lspci -tv
-+-[:01]-+-01.0-[:02]--+-03.0  Broadcom Corporation NetXtreme
BCM5702X Gigabit Ethernet
 |   | \-04.0  Broadcom Corporation NetXtreme
BCM5702X Gigabit Ethernet
 |   +-01.1  Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC
 |   +-02.0-[:03-04]01.0-[:04]00.0  Mellanox
Technologies MT23108 InfiniHost
 |   +-02.1  Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC
 |   +-03.0-[:05]--+-00.0  Advanced Micro Devices [AMD] AMD-8111 USB
 |   | +-00.1  Advanced Micro Devices [AMD] AMD-8111 USB
 |   | \-06.0  ATI Technologies Inc Rage XL
 |   +-04.0  Advanced Micro Devices [AMD] AMD-8111 LPC
 |   +-04.1  Advanced Micro Devices [AMD] AMD-8111 IDE
 |   +-04.2  Advanced Micro Devices [AMD] AMD-8111 SMBus 2.0
 |   +-04.3  Advanced Micro Devices [AMD] AMD-8111 ACPI
 |   \-04.6  Advanced Micro Devices [AMD] AMD-8111 MC97 Modem
 \-[:00]-+-18.0  Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] HyperTransport Technology Configuration
 +-18.1  Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] Address Map
 +-18.2  Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] DRAM Controller
 +-18.3  Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] Miscellaneous Control
 +-19.0  Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] HyperTransport Technology Configuration
 +-19.1  Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] Address Map
 +-19.2  Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] DRAM Controller
 \-19.3  Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] Miscellaneous Control


sh-3.2#  lspci -tvnn
-+-[:01]-+-01.0-[:02]--+-03.0  14e4:16a6
 |   | \-04.0  14e4:16a6
 |   +-01.1  1022:7451
 |   +-02.0-[:03-04]01.0-[:04]00.0  15b3:5a44
 |   +-02.1  1022:7451
 |   +-03.0-[:05]--+-00.0  1022:7464
 |   | +-00.1  1022:7464
 |   | \-06.0  1002:4752
 |   +-04.0  1022:7468
 |   +-04.1  1022:7469
 |   +-04.2  1022:746a
 |   +-04.3  1022:746b
 |   \-04.6  1022:746e
 \-[:00]-+-18.0  1022:1100
 +-18.1  1022:1101
 +-18.2  1022:1102
 +-18.3  1022:1103
 +-19.0  1022:1100
 +-19.1  1022:1101
 +-19.2  1022:1102
 \-19.3  1022:1103





-- 
Sebastián Lara Menares
Ingeniería Civil Electrónica
Universidad de Concepción

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] K8 machine with (a lot of) ram from 2 vendors keeps resetting

2009-09-02 Thread Ward Vandewege
Hi Marc,

On Wed, Sep 02, 2009 at 04:03:45PM -0600, Marc Jones wrote:
  With the proprietary BIOS, this setup works perfectly. That said, the manual
  for the board does say it's not recommended to mix memory types. Our system
  integrator mentions that when 16 banks are used, the memory runs at maximum
  533MHz.
 
 As we talked about, it looks like the memory is sized correctly and
 the next thing to try forcing the memory speed slower. 8 dual rank
 dimms (16 banks) s[eed limitation might be spec'd or errata. A check
 might need to go into the main k8 mem init code.

I've forced the speed down to 533MHz with this patch:

--- src/northbridge/amd/amdk8/raminit_f.code(revision 4625)
+++ src/northbridge/amd/amdk8/raminit_f.code(working copy)
@@ -1811,6 +1811,10 @@
}
min_latency = 3;
 
+   // Force minimum cycle time to 3.75ns (i.e. 266MHz)
+   min_cycle_time = 0x375;
+
+   printk_raminit(1 bios_cycle_time: %08x\n, bios_cycle_time);
printk_raminit(1 min_cycle_time: %08x\n, min_cycle_time);
 
/* Compute the least latency with the fastest clock supported

Which appears to do the right thing, but the behavior is unchanged. Here's a
boot log prior to the patch:

  
http://ward.vandewege.net/coreboot/h8dme/minicom-20090902-with-64G-samsung-on-cpu1-kingston-on-cpu2-before-533MHz-limit.cap

and here's after the patch:

  
http://ward.vandewege.net/coreboot/h8dme/minicom-20090902-with-64G-samsung-on-cpu1-kingston-on-cpu2-after-533MHz-limit.cap

This is with all samsung ram on CPU1 and all kingston ram on CPU2, as you
suggested on irc.

Anything else I should try?

Thanks,
Ward.

-- 
Ward Vandewege w...@fsf.org
Free Software Foundation - Senior Systems Administrator

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot


Re: [coreboot] SeaBIOS WinXP install

2009-09-02 Thread Kevin O'Connor
On Wed, Sep 02, 2009 at 04:31:19PM +0200, Arnaud Maye wrote:
 Just before the system to hang, seabios displays :
 -
 fail handle_legacy_disk:845(1):
   a=0201  b=0d00  c=0001  d=47530081 ds=9000 es=9000 ss=9000
  si=fff0fff0 di=0009fff0 bp=1ff0 sp=8ff8 cs=9020 ip=1015  f=0283
 fail handle_legacy_disk:845(1):
   a=415a  b=55aa  c=fe03  d=47530081 ds=9000 es=9000 ss=9000
  si=fff00d5a di=0009 bp=1ff0 sp=8ffe cs=9020 ip=1043  f=0293

If you see these messages after Linux starts, then something very
strange is occurring.

If you're seeing these messages prior to the Linux start, then they
like normal -- the messages are just warnings resulting from a call
with invalid parameters (looks like grub is probing for a second hard
drive).

-Kevin

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot


Re: [coreboot] K8 machine with (a lot of) ram from 2 vendors keeps resetting

2009-09-02 Thread Carl-Daniel Hailfinger
On 02.09.2009 23:14, Ward Vandewege wrote:
 I'm having some problems with a supermicro h8dme board with 2 K8 processors
 and 64 GB of ram.

 Sadly, the ram is of two types (that was not my decision :/). We have 8x 4GB
 Samsung M393T5160QZA-CE6 and 8x 4GB Kingston KVR667D2D4P5/4G. Both of these
 types of ram are dual rank DDR2, 667 MHz, CL5, 1.8 V, registered, ECC.
   

The K8 memory code has some oddities which cause it to break down even
if the SPD parameters you use are identical. Not only must all SPD
timing parameters be identical, they also have to be stored at the same
byte addresses in each SPD. I sent a patch for this to the list sometime
last year, but it was never completely finished. I can try to dig it up
if you want to take a look.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/


-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot