From stepan at openbios.org  Mon Nov  1 03:42:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Mon Nov  1 03:42:00 2004
Subject: PXE support
In-Reply-To: <000201c4bfb0$cec0d5f0$8e04010a@nexcom.com.tw>
References: <1098980769.12894.6.camel@exponential.lanl.gov> <000201c4bfb0$cec0d5f0$8e04010a@nexcom.com.tw>
Message-ID: <20041101100508.GA12769@openbios.org>

* Gin <ginlin at nexcom.com.tw> [041101 02:19]:
> Hello,
> It seems like linuxbios supports PXE. Can anyone tell me how it works if
> you have experience with it? Thanks
 
etherboot supports PXE. If you use etherboot as LB payload it should
work. Never tried this though since I can't really recognize an
advantage over the usual dhcp/tftpboot scenario. It's unlikely that you
are able to use any driver like code on the network adapters without
16bit bios.

Stefan



From tyson at irobot.com  Mon Nov  1 07:15:01 2004
From: tyson at irobot.com (tyson at irobot.com)
Date: Mon Nov  1 07:15:01 2004
Subject: status information
In-Reply-To: <1099067604.12894.70.camel@exponential.lanl.gov>
References: <20041028115139.GA19778@openbios.org>	 <m3654v9gbn.fsf@maxwell.lnxi.com>	 <Pine.LNX.4.58.0410280813530.7845@linux.site>	 <1098990045.12894.20.camel@exponential.lanl.gov>	 <m3sm7yqwk5.fsf@maxwell.lnxi.com> <1099067604.12894.70.camel@exponential.lanl.gov>
Message-ID: <41863C5B.7020802@irobot.com>

Li-Ta Lo wrote:
> On Thu, 2004-10-28 at 16:58, Eric W. Biederman wrote:
> 
>>As for CF.  I guess I have only seen LANL doing that, and it
>>seems a little unsatisfactory.  There is no reason why beoboot
>>needs that much space for example.
>>
> 
> 
> I bet there are a lot of people using CF in the embedded world, they 
> can't use Etherboot to fetch the kernel from the net as you do. We 
> should not only think about HPC applications. People in embedded
> market are in different enviroment and have different cost structure
> than you.

I haven't been following many linuxbios threads but this one caught my eye.

Though we are still using a very old version of Linuxbios and thus not 
currently doing any development here :-( we do boot from a CF and the 
ability to do so is very important.

Ollie is right, embedded usage patterns are VERY different from HPC.

Cheers!
Ty


-- 
Tyson D Sawyer                     iRobot Corporation
Lead Systems Engineer              Government & Industrial Robotics
tsawyer at irobot.com                 Robots for the Real World
781-345-0200 ext 3329              http://www.irobot.com



From daubin at actuality-systems.com  Mon Nov  1 07:24:00 2004
From: daubin at actuality-systems.com (Dave Aubin)
Date: Mon Nov  1 07:24:00 2004
Subject: Kernel for linuxbios
Message-ID: <E8F8DBCB0468204E856114A2CD20741F2C1D25@mail.local.ActualitySystems.com>

Two things strike me as odd.

1.  Your ," PCI: IRQ 0 for device 0000:02:00.1 doesn't match PIRQ mask -
try
pci=usepirqmaskPCI: 02:01.0 [1022/7462] disabled"
   Type of errors.  Looks like you pcirqp map is bad?  Are you making
your
Own mother board?  If so it is important that you get this and the mp
Table correct based on your wiring.  

2.  You did get to initramfs, good job, but it did fail to mount you
File system.  This could be anything.  Please send your init script
And Describe what are you trying to mount.  A USB stick, ide, what?


-----Original Message-----
From: Sagiv Yefet [mailto:sagivy at 3vium.com] 
Sent: Sunday, October 31, 2004 5:45 AM
To: Dave Aubin
Cc: linuxbios at clustermatic.org
Subject: RE: Kernel for linuxbios


I took your advise and try the 2.6.
I am using the initramfs_data.cpio.gz from the link you send me.

The mkelf command is:

./objdir/sbin/mkelfImage -t bzImage-i386
--kernel=/home/sagivy/bzImage-2.6. 	--command-line="rw
console=ttyS0,115200 root=/dev/ram0"
	--initrd=/home/sagivy/initramfs_data.cpio.gz 
	--output=/home/sagivy/bzImage2.6.8.elf

And here is the output:

Jumping to Linux                
Linux version 2.6.8 (root at hermes) (gcc version 3.3.3) #6 Mon Nov 17
21:49:23 IST

 2003     
BIOS-provided physical RAM map:                               
 BIOS-e820: 0000000000000000 - 0000000000000d54 (rese

 BIOS-e820: 0000000000000d54 - 00000000000a0000 (usable)

 BIOS-e820: 00000000000f0000 - 00000000000f0400 (reserved)

 BIOS-e820: 0000000000100000 - 0000000020000000 (usable)

0MB HIGHMEM available.                      
512MB LOWMEM available.                       
DMI not present.                
ACPI: Unable to locate RSDP                           
Built 1 zonelists                 
Kernel command line: rw console=ttyS0,115200 root=/dev/ram0

Initializing CPU#0                  
PID hash table entries: 4096 (order 12: 32768 bytes)

Detected 1603.740 MHz processor.                                
Using tsc for high-res timesource                                 
Console: colour VGA+ 80x25                          
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)..

Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)    
PCI: Using configuration type 1                          
Memory: 515700k/524288k available (1525k kernel code, 7824k reserved,
702k data, K8 Northbridge                               
Enumerating: AMD K8 CPU          
 228k init, 0k highmem)g: AMD 8111 Southbridge Checking if this
processor honours the WP bit even in supervisor mode...
Ok.               
Enumerating buses...                    
amdk8_scan_root_bus
Calibrating delay loop... 3162.11 BogoMIPSart scaning pci bus

Mount-cache hash table entries: 512 (order: 0, 4096 bytes)

PCI: 00:18.0 [1022/1100] enabled          
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)

PCI: 00:18.2 [1022/1102] enabled           
CPU: L2 Cache: 1024K (64 bytes/line)022/1103] ops                       
Enabling fast FPU save and restore... done.

HyperT rese
Enabling unmasked SIMD FPU exception support... done.for bus 1

PCI: 01:01.0 [10
Checking 'hlt' instruction... OK.              
PCI: 01:01.0 [1022
checking if image is initramfs... it is      
PCI: 01:02.0 [1022/7468] bus ops
Freeing initrd memory: 151k freedCI: 01:02.0 [1022/7468] enabled  
NET: Registered protocol family 16 01:02.1 [1022/7469] ops          
EISA bus registeredCI: 01:02.1 [1022/7
PCI: Using configuration type 1            
PCI: 01:02.2 [1022
mtrr: v2.0 (20020519)                     
Linux Plug and Play Support v0.97 (c) Adam Belay           
PCI: 01:02.3 [1022/746b] enabled    
PCI: Probing PCI hardware
PCI: 01:02.5 [1022/746
PCI: IRQ 0 for device 0000:02:00.0 doesn't match PIRQ mask - try
pci=usepirqmask7463] ops                            
PCI: 02:00.2 [1022/7463] disabled         

PCI: IRQ 0 for device 0000:02:00.1 doesn't match PIRQ mask - try
pci=usepirqmaskPCI: 02:01.0 [1022/7462] disabled

PCI: 02:0a.0 

PCI: IRQ 0 for device 0000:02:0a.0 doesn't match PIRQ mask - try
pci=usepirqmask                          
PCI: 02:0b.0 [1002/4752] enabled                     

PCI: IRQ 0 for device 0000:02:0b.0 doesn't match PIRQ m

PCI: 02:0e.0 [14e                
PNP: 002e.7 disabled           
apm: BIOS not found. disabled           
VFS: Disk quotas dquot_6.5.1d                    
PNP: 0
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)              
scan_static_bus done                    
PC
isapnp: Scanning for PnP cards...=02                              
isapnp: No Plug & Play device found 0 new max: 2                      
Real Time Clock Driver v1.12ort scan link done          
Serial: 8250/16550 driver $Revision: 1.90 $ 48 ports, IRQ sharing
enabled    
PCI: pci_scan_bus returning with max=02                             
ttyS0 at I/O 0x3f8 (irq = bus:                    
AMD8111: not 100% native mode: will probe irqs later
AMD8111: 0000:01:02.1 (rev 03) UDMA133 controller
    ide0: BM-DMA at 0x2420-0x2427, BIOS settings: hda:pio, hdb:pio
    ide1: BM-DMA at 0x2428-0x242f, BIOS settings: hdc:pio, hdd:pio
ide-floppy driver 0.99.newide
mice: PS/2 mouse device common for all mice
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
EISA: Probing bus 0 at eisa0
NET: Registered protocol family 2
IP: routing cache hash table of 4096 buckets, 32Kbytes
TCP: Hash tables configured (established 131072 bind 65536)
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 8
NET: Registered protocol family 20
Freeing unused kernel memory: 228k freed Kernel panic: Attempted to kill
init!
================ ==================
    This kernel uses initramfs
==================================
Unknown root filesystem type!

Sagiv.

-----Original Message-----
From: Dave Aubin [mailto:daubin at actuality-systems.com]
Sent: Wednesday, October 13, 2004 2:47 PM
To: Sagiv Yefet; Stefan Reinauer
Cc: linuxbios at clustermatic.org
Subject: RE: Kernel for linuxbios

Sorry for the late response.  Are you using Linux 2.6.*.  If so give
initramfs a try.
Here is a link to aid you in how:

http://linuxfromscratch.org/pipermail/lfs-hackers/2004-June/001424.html

Dave
 

-----Original Message-----
From: linuxbios-admin at clustermatic.org
[mailto:linuxbios-admin at clustermatic.org] On Behalf Of Sagiv Yefet
Sent: Wednesday, October 13, 2004 8:10 AM
To: Stefan Reinauer
Cc: linuxbios at clustermatic.org
Subject: RE: Kernel for linuxbios

I tried to use initrd - same problem.

Sagiv 

-----Original Message-----
From: Stefan Reinauer [mailto:stepan at openbios.org]
Sent: Monday, October 11, 2004 11:21 AM
To: Sagiv Yefet
Cc: linuxbios at clustermatic.org
Subject: Re: Kernel for linuxbios

* Sagiv Yefet <sagivy at 3vium.com> [041011 11:06]:
> 
> I add the console support and there is output. Thanks.
> 
> My machine has no disks and I need initrd. So I took initrd from 
> Thinstation and build the elf file by the command :
> 
> RAMDISK: Couldn't find valid RAM disk image starting at 0.
> Freeing initrd memory: 11922k freed
> Kernel panic: VFS: Unable to mount root fs on 01:00
 
use initrd, not ramdisk!

Stefan


_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios




From rminnich at lanl.gov  Mon Nov  1 10:36:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Nov  1 10:36:01 2004
Subject: FILO fixups
In-Reply-To: <3174569B9743D511922F00A0C94314230665B8B6@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B8B6@TYANWEB>
Message-ID: <Pine.LNX.4.58.0411010958320.24927@linux.site>


On Fri, 29 Oct 2004, YhLu wrote:

> You can get filo only under Etherboot.
> 
> make bin/filo.zelf

but you won't get my speed improvements, although we can see about putting 
those in too. 

we'll probably continue with filo-only here for now. 

thanks

ron


From rminnich at lanl.gov  Mon Nov  1 10:45:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Nov  1 10:45:01 2004
Subject: status information
In-Reply-To: <m3oeilhz7o.fsf@maxwell.lnxi.com>
References: <20041028115139.GA19778@openbios.org> <m3654v9gbn.fsf@maxwell.lnxi.com>
 <Pine.LNX.4.58.0410280813530.7845@linux.site> <1098990045.12894.20.camel@exponential.lanl.gov>
 <m3sm7yqwk5.fsf@maxwell.lnxi.com> <Pine.LNX.4.58.0410281734270.11174@linux.site>
 <20041028234908.GD2018@tinyvaio.nome.ca> <Pine.LNX.4.58.0410281751130.11174@linux.site>
 <m3oeilhz7o.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.58.0411011004340.24927@linux.site>


On Fri, 29 Oct 2004, Eric W. Biederman wrote:

> As for size, the beoboot userland is one of the reasons why you are
> still using CF.  But that can be tuned.

No, beoboot really is not the reason at all! 

We had a cluster at SC '03 with linuxbios/linux/beoboot in the flash part,
NOT the cf. That booted over ethernet (faster than etherboot, which was
interesting). As soon as you put IB drivers or myrinet drivers or quadrics
drivers into the picture, you need the CF. That's just the way it is.
Those drivers and their support code push the kernel size over the edge.

Plus, on Pink, the 1024 node cluster, we have a fallback/normal linuxbios,
fallback/normal FILO in flash; the fallback/normal kernel and initrd are
in CF. There's no room at all to do this in a 1 MB flash part. 

Use of CF is not a beoboot/kexec issue at all.

ron



From rminnich at lanl.gov  Mon Nov  1 10:53:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Nov  1 10:53:01 2004
Subject: status information
In-Reply-To: <20041030160434.GA5786@openbios.org>
References: <20041028115139.GA19778@openbios.org> <m3654v9gbn.fsf@maxwell.lnxi.com>
 <Pine.LNX.4.58.0410280813530.7845@linux.site> <m3wtxaqx83.fsf@maxwell.lnxi.com>
 <20041030160434.GA5786@openbios.org>
Message-ID: <Pine.LNX.4.58.0411011015490.24927@linux.site>


On Sat, 30 Oct 2004, Stefan Reinauer wrote:

> What was the original intention of the structure? It might be nice to
> know how many sockets there are and what CPUs are in those sockets.. 
> (ie some dmi kind of information)

it would have allowed for more debug information, but it appear that 
requests from a number of people to leave it in there were ignored.

ron


From adam at cfar.umd.edu  Mon Nov  1 11:48:01 2004
From: adam at cfar.umd.edu (Adam Sulmicki)
Date: Mon Nov  1 11:48:01 2004
Subject: LinuxBIOS debugging with an emulator
In-Reply-To: <1099002233.12894.42.camel@exponential.lanl.gov>
Message-ID: <20041101131812.Y90066-100000@www.missl.cs.umd.edu>

On Thu, 28 Oct 2004, Li-Ta Lo wrote:

> BTW, if you specify the -g option for gcc, you can use the -S option
> in objdump to see the source code with the disassebmly (-d).

BTW, this is a very usefull tip. I had been using it lately all the time
to trace ooops in kernel.

	objdump -S -C ./vmadump.ko  |less



From ollie at lanl.gov  Mon Nov  1 12:10:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Mon Nov  1 12:10:01 2004
Subject: status information
In-Reply-To: <m3oeilhz7o.fsf@maxwell.lnxi.com>
References: <20041028115139.GA19778@openbios.org>
	 <m3654v9gbn.fsf@maxwell.lnxi.com>
	 <Pine.LNX.4.58.0410280813530.7845@linux.site>
	 <1098990045.12894.20.camel@exponential.lanl.gov>
	 <m3sm7yqwk5.fsf@maxwell.lnxi.com>
	 <Pine.LNX.4.58.0410281734270.11174@linux.site>
	 <20041028234908.GD2018@tinyvaio.nome.ca>
	 <Pine.LNX.4.58.0410281751130.11174@linux.site>
	 <m3oeilhz7o.fsf@maxwell.lnxi.com>
Message-ID: <1099333978.5500.12.camel@exponential.lanl.gov>

On Fri, 2004-10-29 at 17:38, Eric W. Biederman wrote:
> 
> As for size, the beoboot userland is one of the reasons why you are
> still using CF.  But that can be tuned.
> 

I see no relation between CF an beoboot. As I said, not everyone is 
happy with booting kernel over network. They don't use beoboot
an they want CF !!!

Ollie




From ollie at lanl.gov  Mon Nov  1 12:26:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Mon Nov  1 12:26:01 2004
Subject: FILO fixups
In-Reply-To: <3174569B9743D511922F00A0C94314230665B8B6@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B8B6@TYANWEB>
Message-ID: <1099334957.5500.18.camel@exponential.lanl.gov>

On Fri, 2004-10-29 at 16:47, YhLu wrote:
> You can get filo only under Etherboot.
> 
> make bin/filo.zelf
> 
> or 
> 
> make bin/tg3--filo.zelf
> 
> Also I added something into the filo in Etherboot.
> 


Does it contain anything about Etherboot ? I just want FILO !!!

Ollie




From rminnich at lanl.gov  Mon Nov  1 12:41:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Nov  1 12:41:01 2004
Subject: FILO fixups
In-Reply-To: <m3sm7xi1a1.fsf@maxwell.lnxi.com>
References: <Pine.LNX.4.58.0410291552300.13175@linux.site>
 <1099087480.12894.86.camel@exponential.lanl.gov> <Pine.LNX.4.58.0410291636470.13175@linux.site>
 <m3sm7xi1a1.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.58.0411011000280.24927@linux.site>


On Fri, 29 Oct 2004, Eric W. Biederman wrote:

> Please let's give it's own namespace, just like freebios2 has.
> Or at least could we start a util tree for these kinds of things.

that's my plan9. I'm considering this:

freebios2/payloads

for payloads like filo that are part of the tree.

ron


From YhLu at tyan.com  Mon Nov  1 13:30:01 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Nov  1 13:30:01 2004
Subject: FILO fixups
Message-ID: <3174569B9743D511922F00A0C94314230665B90E@TYANWEB>

The reason for put filo in etherboot.
1. It can let boot from HD or net according to CMOS setting.
2. Etherboot can produce zelf. We may got more space to put other stuff such
as USB support...
3. Etherboot structure and support...

I may check if filo.zlef only include FILO ..., even it is not, we still can
make it clean.

Regards

YH

-----Original Message-----
From: Li-Ta Lo [mailto:ollie at lanl.gov] 
Sent: Monday, November 01, 2004 10:49 AM
To: YhLu
Cc: Ronald G. Minnich; LinuxBIOS
Subject: RE: FILO fixups

On Fri, 2004-10-29 at 16:47, YhLu wrote:
> You can get filo only under Etherboot.
> 
> make bin/filo.zelf
> 
> or 
> 
> make bin/tg3--filo.zelf
> 
> Also I added something into the filo in Etherboot.
> 


Does it contain anything about Etherboot ? I just want FILO !!!

Ollie



From rminnich at lanl.gov  Mon Nov  1 13:33:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Nov  1 13:33:01 2004
Subject: FILO fixups
In-Reply-To: <3174569B9743D511922F00A0C94314230665B90E@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B90E@TYANWEB>
Message-ID: <Pine.LNX.4.58.0411011254490.24927@linux.site>


On Mon, 1 Nov 2004, YhLu wrote:

> 1. It can let boot from HD or net according to CMOS setting.

only useful if your ethernet is hooked up. 15/16 of our nodes here have no 
ethernet. 

> 2. Etherboot can produce zelf. We may got more space to put other stuff such
> as USB support...

not that important to us. 

> 3. Etherboot structure and support...

not clear at the moment if this is a plus or minus. Seeing that it has 
trouble building under certain tool chains, there still seem to be 
problems with it.

> I may check if filo.zlef only include FILO ..., even it is not, we still can
> make it clean.

We still need to add my performance improvements. 

ron


From ollie at lanl.gov  Mon Nov  1 13:41:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Mon Nov  1 13:41:01 2004
Subject: FILO fixups
In-Reply-To: <3174569B9743D511922F00A0C94314230665B90E@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B90E@TYANWEB>
Message-ID: <1099339469.5500.26.camel@exponential.lanl.gov>

On Mon, 2004-11-01 at 12:00, YhLu wrote:
> The reason for put filo in etherboot.
> 1. It can let boot from HD or net according to CMOS setting.
> 2. Etherboot can produce zelf. We may got more space to put other stuff such
> as USB support...
> 3. Etherboot structure and support...
> 
> I may check if filo.zlef only include FILO ..., even it is not, we still can
> make it clean.
> 

You have the same blind spot as Eric. For many people, boot over net is
irrelevant. Why do they need to live with the overhead of network 
protocol stack and driver if all they want to to boot form some
mass storage device ?

Ollie




From daubin at actuality-systems.com  Mon Nov  1 13:59:00 2004
From: daubin at actuality-systems.com (Dave Aubin)
Date: Mon Nov  1 13:59:00 2004
Subject: FILO fixups
Message-ID: <E8F8DBCB0468204E856114A2CD20741F2C1D75@mail.local.ActualitySystems.com>

Hi,

  I'll voice my desire to have etherboot with filo.
I love the fact that I can first try to boot remotely
And then if not use filo.  For this reason alone I am
A fan of the mechanism.  Try remote first then if fail
Use local storage.  If we can, can we please put the
Etherboot flavor in utils that has both network & filo support?

Kind thanks,
Dave:) 

-----Original Message-----
From: linuxbios-admin at clustermatic.org
[mailto:linuxbios-admin at clustermatic.org] On Behalf Of Ronald G. Minnich
Sent: Monday, November 01, 2004 2:56 PM
To: YhLu
Cc: Li-Ta Lo; LinuxBIOS
Subject: RE: FILO fixups



On Mon, 1 Nov 2004, YhLu wrote:

> 1. It can let boot from HD or net according to CMOS setting.

only useful if your ethernet is hooked up. 15/16 of our nodes here have
no ethernet. 

> 2. Etherboot can produce zelf. We may got more space to put other 
> stuff such as USB support...

not that important to us. 

> 3. Etherboot structure and support...

not clear at the moment if this is a plus or minus. Seeing that it has
trouble building under certain tool chains, there still seem to be
problems with it.

> I may check if filo.zlef only include FILO ..., even it is not, we 
> still can make it clean.

We still need to add my performance improvements. 

ron
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From yhlu at tyan.com  Mon Nov  1 14:01:01 2004
From: yhlu at tyan.com (Yinghai Lu)
Date: Mon Nov  1 14:01:01 2004
Subject: Merge/Cleanup status
In-Reply-To: <m34qka225u.fsf@maxwell.lnxi.com>
Message-ID: <200411011900.iA1J0aL21848@nwn.definitive.org>

After increase the ROM_IMAGE_SIZE beyond 64K, Do you need to change
DXIP_ROM_SIZE?

Regards

YH

-----Original Message-----
From: Eric W. Biederman [mailto:eric at lnxi.com] On Behalf Of Eric W.
Biederman
Sent: Sunday, October 31, 2004 10:06 AM
To: Yinghai Lu
Cc: 'LinuxBIOS'; 'Ronald G. Minnich'; 'Richard Smith'; ollie at lanl.gov;
'Stefan Reinauer'
Subject: Re: Merge/Cleanup status

"Yinghai Lu" <yhlu at tyan.com> writes:

> 1. Using ROMCC to do propresser will help the size reduction?

Not directly.  But it does cleanup the header files and increase
the exposure to romcc.  There are a small handful of things
this make more maintainable.

> 2. what is usage for MOVNTI? It is for GDB....

Look at ramtest.c.  movnti is a non-teporal move (bypasses the cache).
In some cases it can noticeably increase store performance.  Last
I measured in the cases it mattered it increased store performance
by 3X.

> 3. How to use GDB to debug LinuxBIOS? Is it only for linuxbios_ram?
Correct.  Either an exception must be taken or a call to
gdb_stub_breakpoint()
needs to be made.  At that point LinuxBIOS will stop and wait for
the debugger.  Assuming CONFIG_GDB_STUB is compiled in.  For details
on the gdb side, read up on the gdb remote serial protocol.

I'm not really a fan, I am still more productive with printf
debugging.  But implement ion exception handling support is a general
win.  And the support was easy to add.

> 4. You will use llshell for crt0.s or auto.c debug?

That is the idea.  Again I added it because it is available.  It would
not be hard to call out to it with an appropriate asm directive. 
If people find llshell useful.  

> 5. Current romcc only take constant parameters for non inline function? It
> that right?

There is something weird going on that affects the generated code, so
things don't work as smoothly as they should.

That said in theory function can be non-inline.

> 6. Anyone has tried to compile LinuxBIOS under Suse 9.1?  what's the
> recommended platform for LinuxBIOS compliation? It seems Suse 9.1 can not
> compile Etherboot properly. I am always using RH9 to do the work. And just
> found I can not compile LB for S2885, (size>65536), but I can do it in
Suse
> 9.1 pro.

The goal is to have LinuxBIOS compiling as many places as possible.
As for recommendations we can call out specific revisions of the
tool chain that are known good but I won't call out distros.  

Size wise I know gcc-3.4 is about 2% better than gcc-3.3.

Interesting.  On the purely size issue you can bump ROM_IMAGE_SIZE a
little and see if it the build works.

As for etherboot I don't know what your compile failure is.  So I
don't know how to diagnose that.

Eric



From rminnich at lanl.gov  Mon Nov  1 14:02:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Nov  1 14:02:01 2004
Subject: FILO fixups
In-Reply-To: <E8F8DBCB0468204E856114A2CD20741F2C1D75@mail.local.ActualitySystems.com>
References: <E8F8DBCB0468204E856114A2CD20741F2C1D75@mail.local.ActualitySystems.com>
Message-ID: <Pine.LNX.4.58.0411011324570.24927@linux.site>


On Mon, 1 Nov 2004, Dave Aubin wrote:

>   I'll voice my desire to have etherboot with filo.

that's fine. choice is good. I have no complaints about that at all. 

That's why I am saying we chose filo. At some later time we might choose 
etherboot. 

ron


From YhLu at tyan.com  Mon Nov  1 14:07:01 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Nov  1 14:07:01 2004
Subject: FILO fixups
Message-ID: <3174569B9743D511922F00A0C94314230665B927@TYANWEB>


From rminnich at lanl.gov  Mon Nov  1 14:14:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Nov  1 14:14:01 2004
Subject: FILO fixups
In-Reply-To: <3174569B9743D511922F00A0C94314230665B927@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B927@TYANWEB>
Message-ID: <Pine.LNX.4.58.0411011334211.24927@linux.site>


On Mon, 1 Nov 2004, YhLu wrote:

> >From the very beginning, how to initialize the CF flash, do it manually?

This is the bootstrap question. 

LNXI booted etherboot to load our flashes up. Once it was up, I reflashed 
flash and CF with a FILO-only image. 

> Or if the CF FS crashed, how do you roll it back?

We've never had it happen here, in several thousand nodes * several years.  
I'm sure it would not be fun.

But recall that many installations do not have ethernet connection of any
kind, so there is no real recovery via ethernet in those cases.  
Ethernet-free machines constitute several thousand machines here at LANL.

We are in fact disconnecting gigE from about 1200 nodes as I speak.

ron


From daubin at actuality-systems.com  Mon Nov  1 14:15:00 2004
From: daubin at actuality-systems.com (Dave Aubin)
Date: Mon Nov  1 14:15:00 2004
Subject: FILO fixups
Message-ID: <E8F8DBCB0468204E856114A2CD20741F2C1D79@mail.local.ActualitySystems.com>

Consider the redundancy aspect of it.  First try remote.
If that fails go local or vs versa.  Kinda like if mom is
Around listen to her, if she's not around well then think
For yourself;)

Consider embedded size aspect of it as well.  A kernel and
Initrd in my situation is about 4Meg.  On my local drive it 
Is about half that.  Size costs more on my embedded local side.

I do like the versatility of etherboot having both local and
Net in one, but I totally understand why you'd want just filo 
As the kernel can do the remote side.  

There is also the error in filo where it can not handle an elf
With both a kernel and initrd.  It can only handle a kernel.
To use filo I had to pack it up with initramfs, i.e. one big kernel.
Etherboot remote boot doesn't have this problem.


-----Original Message-----
From: linuxbios-admin at clustermatic.org
[mailto:linuxbios-admin at clustermatic.org] On Behalf Of Li-Ta Lo
Sent: Monday, November 01, 2004 3:05 PM
To: YhLu
Cc: Ronald G. Minnich; LinuxBIOS
Subject: RE: FILO fixups

On Mon, 2004-11-01 at 12:00, YhLu wrote:
> The reason for put filo in etherboot.
> 1. It can let boot from HD or net according to CMOS setting.
> 2. Etherboot can produce zelf. We may got more space to put other 
> stuff such as USB support...
> 3. Etherboot structure and support...
> 
> I may check if filo.zlef only include FILO ..., even it is not, we 
> still can make it clean.
> 

You have the same blind spot as Eric. For many people, boot over net is
irrelevant. Why do they need to live with the overhead of network
protocol stack and driver if all they want to to boot form some mass
storage device ?

Ollie


_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From ollie at lanl.gov  Mon Nov  1 14:16:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Mon Nov  1 14:16:00 2004
Subject: FILO fixups
In-Reply-To: <3174569B9743D511922F00A0C94314230665B927@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B927@TYANWEB>
Message-ID: <1099341529.5500.89.camel@exponential.lanl.gov>

On Mon, 2004-11-01 at 13:30, YhLu wrote:
> >From the very beginning, how to initialize the CF flash, do it manually?
> 
> Or if the CF FS crashed, how do you roll it back?
> 

How does the CF in your PDA get inited ?
How do you recover your PDA when it crashed? Connect to
the internet ?

How about your vacuum ? your refigurator, your microwave ?

Ollie




From rminnich at lanl.gov  Mon Nov  1 14:19:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Nov  1 14:19:01 2004
Subject: FILO fixups
In-Reply-To: <E8F8DBCB0468204E856114A2CD20741F2C1D79@mail.local.ActualitySystems.com>
References: <E8F8DBCB0468204E856114A2CD20741F2C1D79@mail.local.ActualitySystems.com>
Message-ID: <Pine.LNX.4.58.0411011341050.24927@linux.site>


On Mon, 1 Nov 2004, Dave Aubin wrote:

> Consider the redundancy aspect of it.  First try remote.

again, if you have remote to try, that's fine, go for it. 

If you don't have that ethernet connection, then counting on etherboot is 
kind of pointless :-)

> There is also the error in filo where it can not handle an elf
> With both a kernel and initrd.  It can only handle a kernel.
> To use filo I had to pack it up with initramfs, i.e. one big kernel.
> Etherboot remote boot doesn't have this problem.

??

in an ext2 on filo, i've got a kernel and initrd and it loads it up just 
fine, so I don't see what you mean.

ron


From ollie at lanl.gov  Mon Nov  1 14:22:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Mon Nov  1 14:22:00 2004
Subject: FILO fixups
In-Reply-To: <E8F8DBCB0468204E856114A2CD20741F2C1D75@mail.local.ActualitySystems.com>
References: 	 <E8F8DBCB0468204E856114A2CD20741F2C1D75@mail.local.ActualitySystems.com>
Message-ID: <1099341942.5500.104.camel@exponential.lanl.gov>

On Mon, 2004-11-01 at 13:21, Dave Aubin wrote:
> Hi,
> 
>   I'll voice my desire to have etherboot with filo.
> I love the fact that I can first try to boot remotely
> And then if not use filo.  For this reason alone I am
> A fan of the mechanism.  Try remote first then if fail
> Use local storage.  If we can, can we please put the
> Etherboot flavor in utils that has both network & filo support?
> 

First of all, we didn't say we don't want choice. Actually we
want more, including the choice of not having some choices.
The problems of FILO/Etherboot are:
	1. Some people have hard time building Etherboot.
	2. Some people don't want the feature provided by
	   Etherboot, they are satisfied by FILO itself.
	3. FILO (as FILO itself) does not have an official
	   host. If we want to continue maintain FILO to serve
	   people in 1. and 2., we have to put it somewhere. 

If you want FILO as FILO+Etherboot, why don't you get it from
etherboot project?

Ollie




From daubin at actuality-systems.com  Mon Nov  1 14:24:00 2004
From: daubin at actuality-systems.com (Dave Aubin)
Date: Mon Nov  1 14:24:00 2004
Subject: FILO fixups
Message-ID: <E8F8DBCB0468204E856114A2CD20741F2C1D7B@mail.local.ActualitySystems.com>

Ah, that could be the culprit.  I'm using reiserfs, not ext2
With filo.  Although it says it supports it.  Perhaps it is
The file system that caused my hair loss!!!!  ;)

Yes, having the net connection does make things nice...if ya have it:) 

-----Original Message-----
From: Ronald G. Minnich [mailto:rminnich at lanl.gov] 
Sent: Monday, November 01, 2004 3:42 PM
To: Dave Aubin
Cc: Li-Ta Lo; YhLu; LinuxBIOS
Subject: RE: FILO fixups



On Mon, 1 Nov 2004, Dave Aubin wrote:

> Consider the redundancy aspect of it.  First try remote.

again, if you have remote to try, that's fine, go for it. 

If you don't have that ethernet connection, then counting on etherboot
is kind of pointless :-)

> There is also the error in filo where it can not handle an elf With 
> both a kernel and initrd.  It can only handle a kernel.
> To use filo I had to pack it up with initramfs, i.e. one big kernel.
> Etherboot remote boot doesn't have this problem.

??

in an ext2 on filo, i've got a kernel and initrd and it loads it up just
fine, so I don't see what you mean.

ron


From daubin at actuality-systems.com  Mon Nov  1 14:30:01 2004
From: daubin at actuality-systems.com (Dave Aubin)
Date: Mon Nov  1 14:30:01 2004
Subject: FILO fixups
Message-ID: <E8F8DBCB0468204E856114A2CD20741F2C1D7C@mail.local.ActualitySystems.com>

Filo does need a home and it can run outside of etherboot
So I would concede that is ok to have a home for it.
Although...sniff I do like it in etherboot;) 

-----Original Message-----
From: Li-Ta Lo [mailto:ollie at lanl.gov] 
Sent: Monday, November 01, 2004 3:46 PM
To: Dave Aubin
Cc: Ronald G. Minnich; YhLu; LinuxBIOS
Subject: RE: FILO fixups

On Mon, 2004-11-01 at 13:21, Dave Aubin wrote:
> Hi,
> 
>   I'll voice my desire to have etherboot with filo.
> I love the fact that I can first try to boot remotely And then if not 
> use filo.  For this reason alone I am A fan of the mechanism.  Try 
> remote first then if fail Use local storage.  If we can, can we please

> put the Etherboot flavor in utils that has both network & filo 
> support?
> 

First of all, we didn't say we don't want choice. Actually we want more,
including the choice of not having some choices.
The problems of FILO/Etherboot are:
	1. Some people have hard time building Etherboot.
	2. Some people don't want the feature provided by
	   Etherboot, they are satisfied by FILO itself.
	3. FILO (as FILO itself) does not have an official
	   host. If we want to continue maintain FILO to serve
	   people in 1. and 2., we have to put it somewhere. 

If you want FILO as FILO+Etherboot, why don't you get it from etherboot
project?

Ollie




From rminnich at lanl.gov  Mon Nov  1 14:35:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Nov  1 14:35:00 2004
Subject: FILO fixups
In-Reply-To: <E8F8DBCB0468204E856114A2CD20741F2C1D7C@mail.local.ActualitySystems.com>
References: <E8F8DBCB0468204E856114A2CD20741F2C1D7C@mail.local.ActualitySystems.com>
Message-ID: <Pine.LNX.4.58.0411011358050.24927@linux.site>


On Mon, 1 Nov 2004, Dave Aubin wrote:

> Although...sniff I do like it in etherboot;) 

it will stay in etherboot, no question about that!

ron


From daubin at actuality-systems.com  Mon Nov  1 14:37:01 2004
From: daubin at actuality-systems.com (Dave Aubin)
Date: Mon Nov  1 14:37:01 2004
Subject: FILO fixups
Message-ID: <E8F8DBCB0468204E856114A2CD20741F2C1D7E@mail.local.ActualitySystems.com>

Then I am happy:-) 

-----Original Message-----
From: Ronald G. Minnich [mailto:rminnich at lanl.gov] 
Sent: Monday, November 01, 2004 3:58 PM
To: Dave Aubin
Cc: Li-Ta Lo; YhLu; LinuxBIOS
Subject: RE: FILO fixups



On Mon, 1 Nov 2004, Dave Aubin wrote:

> Although...sniff I do like it in etherboot;)

it will stay in etherboot, no question about that!

ron


From tyson at irobot.com  Mon Nov  1 14:48:01 2004
From: tyson at irobot.com (tyson at irobot.com)
Date: Mon Nov  1 14:48:01 2004
Subject: FILO fixups
In-Reply-To: <1099341529.5500.89.camel@exponential.lanl.gov>
References: <3174569B9743D511922F00A0C94314230665B927@TYANWEB> <1099341529.5500.89.camel@exponential.lanl.gov>
Message-ID: <4186A653.9050703@irobot.com>

> On Mon, 2004-11-01 at 13:30, YhLu wrote:
> 
>>>From the very beginning, how to initialize the CF flash, do it manually?

Mount the CF in an other computer and put what you need on it.

There are a number of other ways.

>>Or if the CF FS crashed, how do you roll it back?

We build appliances.  They mount their FS read-only so that every time 
they boot the same way.


...embedded appliances are not the same as workstations or HPC's.

Ty


-- 
Tyson D Sawyer                     iRobot Corporation
Lead Systems Engineer              Government & Industrial Robotics
tsawyer at irobot.com                 Robots for the Real World
781-345-0200 ext 3329              http://www.irobot.com



From stepan at openbios.org  Mon Nov  1 14:51:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Mon Nov  1 14:51:00 2004
Subject: FILO fixups
In-Reply-To: <Pine.LNX.4.58.0411011254490.24927@linux.site>
References: <3174569B9743D511922F00A0C94314230665B90E@TYANWEB> <Pine.LNX.4.58.0411011254490.24927@linux.site>
Message-ID: <20041101211358.GA22567@openbios.org>

* Ronald G. Minnich <rminnich at lanl.gov> [041101 20:56]:
> > 2. Etherboot can produce zelf. We may got more space to put other stuff such
> > as USB support...
> 
> not that important to us. 

That's something that would be very interesting for OpenBIOS.
It seems this is not that easy without etherboot's pregenerated elf
headers though. Is there any documentation available about what zelf
should have?

As an alternative, the LinuxBIOS (elf) loader could offer to load
nrv2b compressed files... opinions?

Stefan


From YhLu at tyan.com  Mon Nov  1 15:14:00 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Nov  1 15:14:00 2004
Subject: FILO fixups
Message-ID: <3174569B9743D511922F00A0C94314230665B92B@TYANWEB>

I mean cluster nodes.

You will go there unplug the CF. (You may need to spend sometime to figure
out which one).

Regards

YH

-----Original Message-----
From: Li-Ta Lo [mailto:ollie at lanl.gov] 
Sent: Monday, November 01, 2004 12:39 PM
To: YhLu
Cc: Ronald G. Minnich; LinuxBIOS
Subject: RE: FILO fixups

On Mon, 2004-11-01 at 13:30, YhLu wrote:
> >From the very beginning, how to initialize the CF flash, do it manually?
> 
> Or if the CF FS crashed, how do you roll it back?
> 

How does the CF in your PDA get inited ?
How do you recover your PDA when it crashed? Connect to
the internet ?

How about your vacuum ? your refigurator, your microwave ?

Ollie



From YhLu at tyan.com  Mon Nov  1 15:14:12 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Nov  1 15:14:12 2004
Subject: FILO fixups
Message-ID: <3174569B9743D511922F00A0C94314230665B92D@TYANWEB>

I guess FILO will be in Etherboot from 5.2.6.

I think we may add several lines in README to make users to enable linuxbios
support.

It should be

1. Changes in arch/i386/Config.
	Comment out PCIBOS
	Enable LinuxBIOS line.
	Enable X86-64 line
2. make bin/tg3.zelf or make bin/tg3--filo.zelf


Regards

YH
-----Original Message-----
From: Dave Aubin [mailto:daubin at actuality-systems.com] 
Sent: Monday, November 01, 2004 12:53 PM
To: Li-Ta Lo
Cc: Ronald G. Minnich; YhLu; LinuxBIOS
Subject: RE: FILO fixups

Filo does need a home and it can run outside of etherboot
So I would concede that is ok to have a home for it.
Although...sniff I do like it in etherboot;) 

-----Original Message-----
From: Li-Ta Lo [mailto:ollie at lanl.gov] 
Sent: Monday, November 01, 2004 3:46 PM
To: Dave Aubin
Cc: Ronald G. Minnich; YhLu; LinuxBIOS
Subject: RE: FILO fixups

On Mon, 2004-11-01 at 13:21, Dave Aubin wrote:
> Hi,
> 
>   I'll voice my desire to have etherboot with filo.
> I love the fact that I can first try to boot remotely And then if not 
> use filo.  For this reason alone I am A fan of the mechanism.  Try 
> remote first then if fail Use local storage.  If we can, can we please

> put the Etherboot flavor in utils that has both network & filo 
> support?
> 

First of all, we didn't say we don't want choice. Actually we want more,
including the choice of not having some choices.
The problems of FILO/Etherboot are:
	1. Some people have hard time building Etherboot.
	2. Some people don't want the feature provided by
	   Etherboot, they are satisfied by FILO itself.
	3. FILO (as FILO itself) does not have an official
	   host. If we want to continue maintain FILO to serve
	   people in 1. and 2., we have to put it somewhere. 

If you want FILO as FILO+Etherboot, why don't you get it from etherboot
project?

Ollie



From rminnich at lanl.gov  Mon Nov  1 15:27:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Nov  1 15:27:00 2004
Subject: FILO fixups
In-Reply-To: <3174569B9743D511922F00A0C94314230665B92B@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B92B@TYANWEB>
Message-ID: <Pine.LNX.4.58.0411011449480.24927@linux.site>


On Mon, 1 Nov 2004, YhLu wrote:

> I mean cluster nodes.
> 
> You will go there unplug the CF. (You may need to spend sometime to figure
> out which one).

has not been a big deal in several years of work here with multiple 
thousands of nodes. It's not something we worry about.

ron


From ollie at lanl.gov  Mon Nov  1 15:35:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Mon Nov  1 15:35:00 2004
Subject: FILO fixups
In-Reply-To: <3174569B9743D511922F00A0C94314230665B92B@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B92B@TYANWEB>
Message-ID: <1099346318.5500.190.camel@exponential.lanl.gov>

On Mon, 2004-11-01 at 13:48, YhLu wrote:
> I mean cluster nodes.
> 
> You will go there unplug the CF. (You may need to spend sometime to figure
> out which one).
> 

Yea, but I was speaking for EMBEDDED people why they want FILO as FILO
instead of FILO as FILO+Etherboot.

Ollie




From adam at cfar.umd.edu  Mon Nov  1 16:09:00 2004
From: adam at cfar.umd.edu (Adam Sulmicki)
Date: Mon Nov  1 16:09:00 2004
Subject: xen,bproc and grub 
Message-ID: <20041101173949.B90066-100000@www.missl.cs.umd.edu>

Hello,
	I have recently ported bproc [1] which part of clustermatic [2]
suite to xen-2.0 [3] to run on domain0. It was pretty straightforward,
that it required few trival hacks to the kernel, few sym-links and
remembering to use "ARCH=xen" whenever appropriate.

However, clustermatic does use linuxbios on its nodes for booting and does
not use traditional bios at all. This means that the grub (with its
multiboot support) with its heavy dependencies on PC-BIOS Is out of
window.

Thus I'm trying to figure out how I could boot xen/linux-2.6.8.1-xen0 duo
on nodes. Are there any other options to boot it besides using grub[4][5]?
and preferably does not rquire multiboot [6].

I figure out I that maybe could load xen.gz [7] using FILO, Kexec, or
maybe etherboot but it still would not load linux kernel in turn (because
of the dependency on multiboot).

Anyone knows what are my options here? Ideas?

[1] http://bproc.sourceforge.net/
[2] http://www.clustermatic.org/
[3] http://www.cl.cam.ac.uk/Research/SRG/netos/xen/
[4] grub configuration file entry for xen

	title Xen 2.0 / XenLinux 2.6.8.1
	    kernel (hd0,0)/boot/xen.gz dom0_mem=65536
	    module (hd0,0)/boot/vmlinuz-2.6.8.1-xen0 root=/dev/hda1

[5] grub-multiboot, from info page

 - Command: module file ...
     Load a boot module FILE for a Multiboot format boot image (no
     interpretation of the file contents are made, so the user of this
     command must know what the kernel in question expects). The rest
     of the line is passed as the "module command-line", like the
     `kernel' command. You must load a Multiboot kernel image before
     loading any module. See also *Note modulenounzip::.

[6] http://www.gnu.org/software/grub/manual/multiboot/multiboot.html
    does anyone knows better references to multiboot specs?

[7] /boot/xen.gz

redbull:/etc/clustermatic # file /boot/xen.gz
/boot/xen.gz: gzip compressed data, from Unix, max compression

redbull:/etc/clustermatic # file /tmp/xen
/tmp/xen: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped

redbull:/etc/clustermatic # readelf -a /tmp/xen
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Intel 80386
  Version:                           0x1
  Entry point address:               0x100000
  Start of program headers:          52 (bytes into file)
  Start of section headers:          266608 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         1
  Size of section headers:           40 (bytes)
  Number of section headers:         3
  Section header string table index: 2

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0 0  0
  [ 1] .text             PROGBITS        00100000 000080 0410f0 00 WAX  0 0 64
  [ 2] .shstrtab         STRTAB          00000000 0411e8 000011 00      0 0  1
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           0x000080 0x00100000 0x00100000 0x410f0 0x764c0 RWE 0x40

 Section to Segment mapping:
  Segment Sections...
   00     .text

There is no dynamic segment in this file.

There are no relocations in this file.

There are no unwind sections in this file.

No version information found in this file.
redbull:/etc/clustermatic #





From yhlu at tyan.com  Mon Nov  1 17:38:00 2004
From: yhlu at tyan.com (Yinghai Lu)
Date: Mon Nov  1 17:38:00 2004
Subject: Merge/Cleanup status
In-Reply-To: <m34qka225u.fsf@maxwell.lnxi.com>
Message-ID: <200411012237.iA1Mb4L23761@nwn.definitive.org>

Eric,

What the reasons that you set MTRRs for one CPU two times.?
amd_setup_mtrrs of amd_mtrr.c call x86_setup_mtrrs...

regards

Yinghai Lu

APIC_CLUSTER: 0 init
Initializing CPU #0
CPU: vendor AMD device f5a
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 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: 2048MB, type WB
Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB
Setting variable MTRR 2, base: 3072MB, range:  512MB, type WB
Setting variable MTRR 3, base: 3584MB, range:  256MB, type WB
Setting variable MTRR 4, base: 3840MB, range:  128MB, type WB
Setting variable MTRR 5, base: 4096MB, range: 4096MB, type WB
Setting variable MTRR 6, base: 8192MB, range: 8192MB, type WB
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled



From jpraher at yahoo.de  Tue Nov  2 05:15:01 2004
From: jpraher at yahoo.de (Jakob Praher)
Date: Tue Nov  2 05:15:01 2004
Subject: testing and researching
Message-ID: <1099395510.7277.55.camel@jaques2>

hi all,

I'd like to do some embedded systems and cluster research and would like
to use linuxbios as the building block.

Has anybody tried to use linuxbios as the bios in a vm like bochs or
vmware, so that one can "play" with linuxbios in software only?

Additionally I'd like to know, whether you prefere the LinuxBiosKernel
(I mean that there is no "real" linux kernel in the bios) over the
LinuxKernel in Bios approach. If you are using LinuxBiosKernel are you
using a standard ATA flash disk, or are there better ways to boot the
LinuxKernel.....

I'd also apprechiate a good and cheap hardware configuration, that works
with linuxbios, especially: 

* in todays boards: is the flash bios big enough for the LinuxBiosKernel
* if not, which flash chips would you prefer?
* what board would you choose for clustering testing purposes (it should
have state of the art peripheral stuff and modern chipsets, etc).

thanks in advance
-- Jakob



From ebiederman at lnxi.com  Tue Nov  2 05:26:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Nov  2 05:26:00 2004
Subject: Merge/Cleanup status
In-Reply-To: <20041102000054.4C58AD000EC5@spam.llix.net>
References: <20041102000054.4C58AD000EC5@spam.llix.net>
Message-ID: <m3lldka2t7.fsf@maxwell.lnxi.com>

"Yinghai Lu" <yhlu at tyan.com> writes:

> Eric,
> 
> What the reasons that you set MTRRs for one CPU two times.?
> amd_setup_mtrrs of amd_mtrr.c call x86_setup_mtrrs...

This is just the fixed mtrrs.  The code should be refined further,
but this code properly sets the RD_MEM and WR_MEM bits in the fixed
mtrrs.

Given how the code is currently factored this was the easiest way to
code it cleanly.  I expect to revisit this when looking at overlapping mtrr
support. 

Eric


From stepan at openbios.org  Tue Nov  2 05:39:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue Nov  2 05:39:00 2004
Subject: testing and researching
In-Reply-To: <1099395510.7277.55.camel@jaques2>
References: <1099395510.7277.55.camel@jaques2>
Message-ID: <20041102120248.GB30064@openbios.org>

* Jakob Praher <jpraher at yahoo.de> [041102 12:38]:
> I'd like to do some embedded systems and cluster research and would like
> to use linuxbios as the building block.
> 
> Has anybody tried to use linuxbios as the bios in a vm like bochs or
> vmware, so that one can "play" with linuxbios in software only?
 
I started a build for qemu, a free x86 (plus a lot of other
cpus/architectures) emulator, see http://fabrice.bellard.free.fr/qemu/

there's a target emulation/qemu-i386 but it needs some fixing since the
last major restructure...

> Additionally I'd like to know, whether you prefere the LinuxBiosKernel
> (I mean that there is no "real" linux kernel in the bios) over the
> LinuxKernel in Bios approach. If you are using LinuxBiosKernel are you
> using a standard ATA flash disk, or are there better ways to boot the
> LinuxKernel.....
 
There is no such thing as a LinuxBIOS-Kernel. Basically LinuxBIOS
initializes the machine just far enough so a Linux (or any other) kernel
can be started from flash or IDE(disk/cf/...)
This kernel or application is reffered to as "payload" in LinuxBIOS
contect.
Since most flash devices are too small to fit in a standard linux
kernel, other payloads are used that allow loading a Linux kernel or
other operating system from a file system or over network. Examples for
payloads are: OpenBIOS, etherboot, filo (See mailinglist archive for
more information).

> * in todays boards: is the flash bios big enough for the LinuxBiosKernel

If you load a Linux kernel from an IDE device, it fits easily in every
common flash device out there. Otherwise you will at least need 512k or
more of flash.. I don't think that Linux in flash is a good solution,
but others on this list have a different opinion and proofed that it
works fine.

> * if not, which flash chips would you prefer?

You always need something that is compatible to the already available
flash device (LPC/parallel/3V,5V,12V...) 

> * what board would you choose for clustering testing purposes (it should
> have state of the art peripheral stuff and modern chipsets, etc).

Clearly AMD64 boards with AMD8111/8151/8131 chipset. They are best
supported so far. Many boards from Tyan come with this chipset, but
there are machines/boards available from other vendors as well..


Stefan



From stepan at openbios.org  Tue Nov  2 05:50:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue Nov  2 05:50:01 2004
Subject: Status Report 2004-11-02
Message-ID: <20041102121347.GA5148@openbios.org>

Hi,

after some more changes like the removed 64k limit for linuxbios rom
images here a new status report about the current image builds.

NOTE: Many boards are broken at the moment. If anyone here can supply
fixes, please do so. The situation is almost fatal given that the
changes to do are mostly time consuming but not really complex.

As a generic goal we should work on reducing the impact of such changes
by adapting the structure. Example: Having a per board fallback mechanism 
seems overkill.. The only difference among all boards seem to be the
included files from the north bridge and southbridge directories. These
could easily be autogenerated from the config tool.

The less files one port has, the easier it is to adapt to new changes.
Long term this raises code quality and the number of new ports.

Stefan

-------------- next part --------------
Processing mainboard amd quartet (i386: ok)
  Creating config file... ok
  Creating builddir...ok
  Compiling image ..FAILED! Log excerpt:
In file included from /home/stepan/cvsroots/freebios2/src/mainboard/amd/quartet/auto.c:148:
/home/stepan/cvsroots/freebios2/src/northbridge/amd/amdk8/raminit.c:568:2: warning: #warning "FIXME implement a better test for opterons"
make[1]: *** [auto.E] Error 1
make[1]: Leaving directory `/home/stepan/cvsroots/freebios2/util/abuild/linuxbios-builds/amd_quartet/fallback'
make: *** [fallback-rom] Error 1

Processing mainboard amd serenade (i386: ok)
  Creating config file... ok
  Creating builddir...ok
  Compiling image ..FAILED! Log excerpt:
In file included from /home/stepan/cvsroots/freebios2/src/mainboard/amd/serenade/auto.c:121:
/home/stepan/cvsroots/freebios2/src/northbridge/amd/amdk8/raminit.c:568:2: warning: #warning "FIXME implement a better test for opterons"
make[1]: *** [auto.E] Error 1
make[1]: Leaving directory `/home/stepan/cvsroots/freebios2/util/abuild/linuxbios-builds/amd_serenade/fallback'
make: *** [fallback-rom] Error 1

Processing mainboard amd solo (i386: ok)
  Creating config file... ok
  Creating builddir...ok
  Compiling image ..ok.

Processing mainboard arima hdama (i386: ok)
  Creating config file... ok
  Creating builddir...ok
  Compiling image ..ok.

Processing mainboard densitron dpx114 (i386: ok)
  Creating config file... ok
  Creating builddir...FAILED! Log excerpt:
Configuring TARGET densitron_dpx114
Will place Makefile, crt0.S, etc. in densitron_dpx114
===> ERROR: Could not open file "/home/stepan/cvsroots/freebios2/src/mainboard/densitron/dpx114/Options.lb"
Config-densitron_dpx114.lb:0

Processing mainboard digitallogic adl855pc (i386: ok)
  Creating config file... ok
  Creating builddir...FAILED! Log excerpt:
Configuring TARGET digitallogic_adl855pc
Will place Makefile, crt0.S, etc. in digitallogic_adl855pc
===> ERROR: Could not open file "/home/stepan/cvsroots/freebios2/src/mainboard/digitallogic/adl855pc/Options.lb"
Config-digitallogic_adl855pc.lb:0

Processing mainboard embeddedplanet ep405pc (ppc: skipped, we're i386)

Processing mainboard emulation qemu-i386 (i386: ok)
  Creating config file... ok
  Creating builddir...FAILED! Log excerpt:
List of nearby tokens: 
  (@0)  EOF  =  ''
===> ERROR: Could not parse file
Config-emulation_qemu-i386.lb:0
src/mainboard/emulation/qemu-i386/Options.lb:0

Processing mainboard ibm e325 (i386: ok)
  Creating config file... ok
  Creating builddir...ok
  Compiling image ..FAILED! Log excerpt:
make[1]: Entering directory `/home/stepan/cvsroots/freebios2/util/abuild/linuxbios-builds/ibm_e325/fallback'
cp /home/stepan/cvsroots/freebios2/src/arch/i386/init/crt0.S.lb crt0.S
make[1]: *** No rule to make target `/home/stepan/cvsroots/freebios2/src/cpu/i386/entry16.inc', needed by `crt0.s'.  Stop.
make[1]: Leaving directory `/home/stepan/cvsroots/freebios2/util/abuild/linuxbios-builds/ibm_e325/fallback'
make: *** [fallback-rom] Error 1

Processing mainboard Iwill DK8S2 (i386: ok)
  Creating config file... ok
  Creating builddir...FAILED! Log excerpt:
Configuring TARGET Iwill_DK8S2
Will place Makefile, crt0.S, etc. in Iwill_DK8S2
===> ERROR: Could not open file "/home/stepan/cvsroots/freebios2/src/mainboard/Iwill/DK8S2/Options.lb"
Config-Iwill_DK8S2.lb:0

Processing mainboard Iwill DK8X (i386: ok)
  Creating config file... ok
  Creating builddir...FAILED! Log excerpt:
Configuring TARGET Iwill_DK8X
Will place Makefile, crt0.S, etc. in Iwill_DK8X
===> ERROR: Could not open file "/home/stepan/cvsroots/freebios2/src/mainboard/Iwill/DK8X/Options.lb"
Config-Iwill_DK8X.lb:0

Processing mainboard motorola sandpoint (ppc: skipped, we're i386)

Processing mainboard newisys khepri (i386: ok)
  Creating config file... ok
  Creating builddir...ok
  Compiling image ..FAILED! Log excerpt:
make[1]: Entering directory `/home/stepan/cvsroots/freebios2/util/abuild/linuxbios-builds/newisys_khepri/fallback'
cp /home/stepan/cvsroots/freebios2/src/arch/i386/init/crt0.S.lb crt0.S
make[1]: *** No rule to make target `/home/stepan/cvsroots/freebios2/src/cpu/i386/entry16.inc', needed by `crt0.s'.  Stop.
make[1]: Leaving directory `/home/stepan/cvsroots/freebios2/util/abuild/linuxbios-builds/newisys_khepri/fallback'
make: *** [fallback-rom] Error 1

Processing mainboard technologic ts5300 (i386: ok)
  Creating config file... ok
  Creating builddir...FAILED! Log excerpt:
Configuring TARGET technologic_ts5300
Will place Makefile, crt0.S, etc. in technologic_ts5300
===> ERROR: Could not open file "/home/stepan/cvsroots/freebios2/src/mainboard/technologic/ts5300/Options.lb"
Config-technologic_ts5300.lb:0

Processing mainboard totalimpact briq (ppc: skipped, we're i386)

Processing mainboard tyan s2735 (i386: ok)
  Creating config file... ok
  Creating builddir...ok
  Compiling image ..FAILED! Log excerpt:
raminit.c:1449.36: raminit.c:1778.40: generic_sdram.c:26.40: auto.c:96.33: 
Load address out of bounds
make[1]: *** [auto.inc] Error 1
make[1]: Leaving directory `/home/stepan/cvsroots/freebios2/util/abuild/linuxbios-builds/tyan_s2735/fallback'
make: *** [fallback-rom] Error 1

Processing mainboard tyan s2850 (i386: ok)
  Creating config file... ok
  Creating builddir...ok
  Compiling image ..FAILED! Log excerpt:
Cannot find `northbridge/amd/amdk8/setup_resource_map.c'

make[1]: *** [auto.inc] Error 1
make[1]: Leaving directory `/home/stepan/cvsroots/freebios2/util/abuild/linuxbios-builds/tyan_s2850/fallback'
make: *** [fallback-rom] Error 1

Processing mainboard tyan s2875 (i386: ok)
  Creating config file... ok
  Creating builddir...ok
  Compiling image ..FAILED! Log excerpt:
Cannot find `northbridge/amd/amdk8/setup_resource_map.c'

make[1]: *** [auto.inc] Error 1
make[1]: Leaving directory `/home/stepan/cvsroots/freebios2/util/abuild/linuxbios-builds/tyan_s2875/fallback'
make: *** [fallback-rom] Error 1

Processing mainboard tyan s2880 (i386: ok)
  Creating config file... ok
  Creating builddir...ok
  Compiling image ..FAILED! Log excerpt:
Cannot find `northbridge/amd/amdk8/setup_resource_map.c'

make[1]: *** [auto.inc] Error 1
make[1]: Leaving directory `/home/stepan/cvsroots/freebios2/util/abuild/linuxbios-builds/tyan_s2880/fallback'
make: *** [fallback-rom] Error 1

Processing mainboard tyan s2881 (i386: ok)
  Creating config file... ok
  Creating builddir...ok
  Compiling image ..FAILED! Log excerpt:
Cannot find `northbridge/amd/amdk8/setup_resource_map.c'

make[1]: *** [auto.inc] Error 1
make[1]: Leaving directory `/home/stepan/cvsroots/freebios2/util/abuild/linuxbios-builds/tyan_s2881/fallback'
make: *** [fallback-rom] Error 1

Processing mainboard tyan s2882 (i386: ok)
  Creating config file... ok
  Creating builddir...ok
  Compiling image ..FAILED! Log excerpt:
Cannot find `northbridge/amd/amdk8/setup_resource_map.c'

make[1]: *** [auto.inc] Error 1
make[1]: Leaving directory `/home/stepan/cvsroots/freebios2/util/abuild/linuxbios-builds/tyan_s2882/fallback'
make: *** [fallback-rom] Error 1

Processing mainboard tyan s2885 (i386: ok)
  Creating config file... ok
  Creating builddir...ok
  Compiling image ..FAILED! Log excerpt:
/home/stepan/cvsroots/freebios2/src/superio/winbond/w83627hf/superio.c:218: error: unknown field `name' specified in initializer
/home/stepan/cvsroots/freebios2/src/superio/winbond/w83627hf/superio.c:218: warning: initialization from incompatible pointer type
make[1]: *** [superio.o] Error 1
make[1]: Leaving directory `/home/stepan/cvsroots/freebios2/util/abuild/linuxbios-builds/tyan_s2885/fallback'
make: *** [fallback-rom] Error 1

Processing mainboard tyan s4880 (i386: ok)
  Creating config file... ok
  Creating builddir...ok
  Compiling image ..FAILED! Log excerpt:
Cannot find `northbridge/amd/amdk8/setup_resource_map.c'

make[1]: *** [auto.inc] Error 1
make[1]: Leaving directory `/home/stepan/cvsroots/freebios2/util/abuild/linuxbios-builds/tyan_s4880/fallback'
make: *** [fallback-rom] Error 1

Processing mainboard tyan s4882 (i386: ok)
  Creating config file... ok
  Creating builddir...ok
  Compiling image ..FAILED! Log excerpt:
Cannot find `northbridge/amd/amdk8/setup_resource_map.c'

make[1]: *** [auto.inc] Error 1
make[1]: Leaving directory `/home/stepan/cvsroots/freebios2/util/abuild/linuxbios-builds/tyan_s4882/fallback'
make: *** [fallback-rom] Error 1

Processing mainboard via epia (i386: ok)
  Creating config file... ok
  Creating builddir...FAILED! Log excerpt:
===> NOTE: Changing default value of MAINBOARD
===> NOTE: Changing default value of MAINBOARD_VENDOR
===> NOTE: Changing default value of MAINBOARD_PART_NUMBER
===> ERROR: Attempt to set nonexistent option CC (missing USES?)
Config-via_epia.lb:0

Processing mainboard via epia-m (i386: ok)
  Creating config file... ok
  Creating builddir...FAILED! Log excerpt:
Configuring TARGET via_epia-m
Will place Makefile, crt0.S, etc. in via_epia-m
===> ERROR: Could not open file "/home/stepan/cvsroots/freebios2/src/mainboard/via/epia-m/Options.lb"
Config-via_epia-m.lb:0


From ginlin at nexcom.com.tw  Tue Nov  2 08:12:00 2004
From: ginlin at nexcom.com.tw (Gin)
Date: Tue Nov  2 08:12:00 2004
Subject: ram not usable 
In-Reply-To: <1099395510.7277.55.camel@jaques2>
Message-ID: <000001c4c0e9$2d89b910$8e04010a@nexcom.com.tw>

Hello,
I am using the Config file for mainboard tyan/s2735 to build the image
because it has the same chipset (E7501) with my target sytem. The
Southbridge(ICH3-s) and superio(SMSC) is different but I think it should
be fine. I got the console working but it failed with the initializing
Ram. When I run the ram test, the value I read out is different from
what I wrote in.   

1. Should the RAM-init code work in my board since it has the same
Northbridge? Or there could be a mainboard specific problem? 

2.
There is a Config.lb file under /src/mainboard directory. Should I
modify it to fit our board structure? In the end, there is PCI Device
Tree like structure, is it the exact PCI devices on that mainbaord?

Thanks, we are very anxious to get this going. We have customers waiting
to use it. 

Gin  



From YhLu at tyan.com  Tue Nov  2 11:52:01 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Nov  2 11:52:01 2004
Subject: Status Report 2004-11-02
Message-ID: <3174569B9743D511922F00A0C94314230665B983@TYANWEB>

I have fixed my parts.

Regards

YH

-----Original Message-----
From: Stefan Reinauer [mailto:stepan at openbios.org] 
Sent: Tuesday, November 02, 2004 4:14 AM
To: linuxbios at clustermatic.org
Subject: Status Report 2004-11-02

Hi,

after some more changes like the removed 64k limit for linuxbios rom
images here a new status report about the current image builds.

NOTE: Many boards are broken at the moment. If anyone here can supply
fixes, please do so. The situation is almost fatal given that the
changes to do are mostly time consuming but not really complex.

As a generic goal we should work on reducing the impact of such changes
by adapting the structure. Example: Having a per board fallback mechanism 
seems overkill.. The only difference among all boards seem to be the
included files from the north bridge and southbridge directories. These
could easily be autogenerated from the config tool.

The less files one port has, the easier it is to adapt to new changes.
Long term this raises code quality and the number of new ports.

Stefan



From stepan at openbios.org  Tue Nov  2 12:49:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue Nov  2 12:49:00 2004
Subject: option tables
Message-ID: <20041102191253.GA18067@openbios.org>

Hi,

what's the right method of disabling build with an option table?
Setting HAVE_OPTION_TABLE to 0 fails in src/include/pc80/mc146818rtc.h

It's possible to change both HAVE_OPTIONS_TABLE and USE_OPTION_TABLE,
but the logic is a bit weird.

Stefan



From stepan at openbios.org  Tue Nov  2 13:42:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue Nov  2 13:42:01 2004
Subject: Weird K8 output
Message-ID: <20041102200548.GA19658@openbios.org>

Hi,

on a 4cpu K8 system I get the following output before the system hangs..

Is the machine drunk or are CPU1-3 just running away?

LinuxBIOS-1.1.7.0-fallback Tue Nov  2 20:34:14 CET 2004 starting...
setting up resource map....done.
Enabling routing table for node 00 done.
Enabling SMP settings
setup_remote_node: done
Renaming current temporary node to 01 done.
anabling routing table for node 01 dConlee.
 tRiennamgin g mcutrrrenrt
  emporary node to 02 done.
Enabling routing table for node 02 dConle.e
mRernaiminngg c urmretntr tre
 porary node to 03 done.
Enabling routing table for node 03 dColnee.a
iz04n ngod esm itnirtiral
  ed.
coherent_ht_finalize
done
PCI_DEV=(0,0x18,0) 0xb4=00030000
bus=00 id =74501022
bus=00 id =74601022
PCI_DEV=(0,0x19,0) 0xd4=000a0400


Stefan


From YhLu at tyan.com  Tue Nov  2 14:09:00 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Nov  2 14:09:00 2004
Subject: Weird K8 output
Message-ID: <3174569B9743D511922F00A0C94314230665B9AB@TYANWEB>

MB Model?
HT routing table?

YH

-----Original Message-----
From: Stefan Reinauer [mailto:stepan at openbios.org] 
Sent: Tuesday, November 02, 2004 12:06 PM
To: linuxbios at clustermatic.org
Subject: Weird K8 output

Hi,

on a 4cpu K8 system I get the following output before the system hangs..

Is the machine drunk or are CPU1-3 just running away?

LinuxBIOS-1.1.7.0-fallback Tue Nov  2 20:34:14 CET 2004 starting...
setting up resource map....done.
Enabling routing table for node 00 done.
Enabling SMP settings
setup_remote_node: done
Renaming current temporary node to 01 done.
anabling routing table for node 01 dConlee.
 tRiennamgin g mcutrrrenrt
  emporary node to 02 done.
Enabling routing table for node 02 dConle.e
mRernaiminngg c urmretntr tre
 porary node to 03 done.
Enabling routing table for node 03 dColnee.a
iz04n ngod esm itnirtiral
  ed.
coherent_ht_finalize
done
PCI_DEV=(0,0x18,0) 0xb4=00030000
bus=00 id =74501022
bus=00 id =74601022
PCI_DEV=(0,0x19,0) 0xd4=000a0400


Stefan
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From ebiederman at lnxi.com  Tue Nov  2 14:43:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Nov  2 14:43:01 2004
Subject: Weird K8 output
In-Reply-To: <20041102200548.GA19658@openbios.org>
References: <20041102200548.GA19658@openbios.org>
Message-ID: <m3654o55cc.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at openbios.org> writes:

> Hi,
> 
> on a 4cpu K8 system I get the following output before the system hangs..

Hmm.  It looks like you have non-bootstrap cpus running through the code.

Usually it is this hunk of code that traps errors.
	if (!boot_cpu()) {
		stop_this_cpu();

Although I can see something very weird happening if you have
BIST failure, on your secondary cpus. But that is quite 
unlikely.

> Is the machine drunk or are CPU1-3 just running away?

It looks like the cpus are just running away :(  Usually I would
expect to interlaced characters form a message I recognize.  But I
don't recognize see anything I recognize here.

Eric
 
> LinuxBIOS-1.1.7.0-fallback Tue Nov  2 20:34:14 CET 2004 starting...
> setting up resource map....done.
> Enabling routing table for node 00 done.
> Enabling SMP settings
> setup_remote_node: done
> Renaming current temporary node to 01 done.
> anabling routing table for node 01 dConlee.
>  tRiennamgin g mcutrrrenrt
>   emporary node to 02 done.
> Enabling routing table for node 02 dConle.e
> mRernaiminngg c urmretntr tre
>  porary node to 03 done.
> Enabling routing table for node 03 dColnee.a
> iz04n ngod esm itnirtiral
>   ed.
> coherent_ht_finalize
> done
> PCI_DEV=(0,0x18,0) 0xb4=00030000
> bus=00 id =74501022
> bus=00 id =74601022
> PCI_DEV=(0,0x19,0) 0xd4=000a0400


From ebiederman at lnxi.com  Tue Nov  2 14:46:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Nov  2 14:46:01 2004
Subject: option tables
In-Reply-To: <20041102191253.GA18067@openbios.org>
References: <20041102191253.GA18067@openbios.org>
Message-ID: <m31xfc556z.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at openbios.org> writes:

> Hi,
> 
> what's the right method of disabling build with an option table?
> Setting HAVE_OPTION_TABLE to 0 fails in src/include/pc80/mc146818rtc.h
> 
> It's possible to change both HAVE_OPTIONS_TABLE and USE_OPTION_TABLE,
> but the logic is a bit weird.

Not certain.  It would be necessary to disable both of them.
What happens is by default I compile my fallback images with HAVE_OPTION_TABLE.
so the export it.  The code just does not look at the options, because USE_OPTION_TABLE
is disabled.

For my normal images I set both HAVE_OPTION_TABLE and USE_OPTION_TABLE.

Eric


From ebiederman at lnxi.com  Tue Nov  2 15:14:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Nov  2 15:14:00 2004
Subject: Status Report 2004-11-02
In-Reply-To: <20041102121347.GA5148@openbios.org>
References: <20041102121347.GA5148@openbios.org>
Message-ID: <m3wtx43pbe.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at openbios.org> writes:

> Hi,
> 
> after some more changes like the removed 64k limit for linuxbios rom
> images here a new status report about the current image builds.
> 
> NOTE: Many boards are broken at the moment. If anyone here can supply
> fixes, please do so. 
I intend to look at this.  I'm fighting a nasty cold right now so I'm doing so
moving very fast.

> The situation is almost fatal given that the
> changes to do are mostly time consuming but not really complex.
> 
> As a generic goal we should work on reducing the impact of such changes
> by adapting the structure. Example: Having a per board fallback mechanism 
> seems overkill.. The only difference among all boards seem to be the
> included files from the north bridge and southbridge directories. These
> could easily be autogenerated from the config tool.

I agree to some extent.  Having a default chipset implementation of
a fallack mechanism could be useful.  In the general case you need to
be per board.  But there is no reason not to provide helper functions.

At least with the code in C.  Someone can modify the code and
have a reasonable chance of it working on ports they cannot test.

> The less files one port has, the easier it is to adapt to new changes.
> Long term this raises code quality and the number of new ports.

The vision is to get enough pieces into a general framework so we can
freeze the APIs or at least put them in serious slush mode.  Getting
nearly everything into the device tree as we have looks like a significant
step in that direction.

The big remaining piece is to figure out how to get irq routing into a generic
framework.  Right now we have some functional hacks but code reuse is hard.


Eric


From marc at geekythings.com  Tue Nov  2 15:19:01 2004
From: marc at geekythings.com (Marc Nicholas)
Date: Tue Nov  2 15:19:01 2004
Subject: EPIA MS board
In-Reply-To: <41369CC7.1010203@coplanar.net>
References: <41369CC7.1010203@coplanar.net>
Message-ID: <Pine.GSO.4.60.0411021635140.12891@nerd>

We're going to switch from using the EPIA MII series to EPIA MS as it 
meets the needs of a digital entertainment device much better. Anyone else 
working on getting the MS booting with LinuxBIOS, or will I be in virgin 
territory? :-)

-marc


From stepan at openbios.org  Tue Nov  2 15:40:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue Nov  2 15:40:01 2004
Subject: Weird K8 output
In-Reply-To: <m3654o55cc.fsf@maxwell.lnxi.com>
References: <20041102200548.GA19658@openbios.org> <m3654o55cc.fsf@maxwell.lnxi.com>
Message-ID: <20041102220333.GA28577@openbios.org>

* Eric W. Biederman <ebiederman at lnxi.com> [041102 22:05]:
> Hmm.  It looks like you have non-bootstrap cpus running through the code.
> 
> Usually it is this hunk of code that traps errors.
> 	if (!boot_cpu()) {
> 		stop_this_cpu();
 
> Although I can see something very weird happening if you have
> BIST failure, on your secondary cpus. But that is quite 
> unlikely.
 
But that is something that would be reported, somehow, before setting
the resource map, no?

> > Is the machine drunk or are CPU1-3 just running away?
> 
> It looks like the cpus are just running away :(  Usually I would
> expect to interlaced characters form a message I recognize.  But I
> don't recognize see anything I recognize here.
 

Looking closer, it almost looks like Clearing mtrr

> > Renaming current temporary node to 01 done.
> > anabling routing table for node 01 dConlee.
                                        C  l e
> >  tRiennamgin g mcutrrrenrt
     t i n   g   g m  tr    r

as in print_spew("Clearing mtrr\r\n"); of do_early_mtrr_init.c

Ha, it looks like noone had a chance to compile with spew messages in
quite a while ;-) mtrr setup is long called before stop_cpu. So the
messages seem to be unrelated to the hang..

> >   emporary node to 02 done.
> > Enabling routing table for node 02 dConle.e
> > mRernaiminngg c urmretntr tre
> >  porary node to 03 done.
> > Enabling routing table for node 03 dColnee.a
> > iz04n ngod esm itnirtiral
> >   ed.
> > coherent_ht_finalize
> > done
> > PCI_DEV=(0,0x18,0) 0xb4=00030000
> > bus=00 id =74501022
> > bus=00 id =74601022
> > PCI_DEV=(0,0x19,0) 0xd4=000a0400
 


From ollie at lanl.gov  Tue Nov  2 15:42:13 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Tue Nov  2 15:42:13 2004
Subject: Invalidating TLB, cache
Message-ID: <1099433022.3373.36.camel@exponential.lanl.gov>

Eric,

What was the conclusion of invalidating the cache and TLB ?
If found that

        xorl    %eax, %eax
        movl    %eax, %cr3    /* Invalidate TLB*/

still exists in the current CVS.

Ollie




From bari at onelabs.com  Tue Nov  2 16:34:01 2004
From: bari at onelabs.com (Bari Ari)
Date: Tue Nov  2 16:34:01 2004
Subject: EPIA MS board
In-Reply-To: <Pine.GSO.4.60.0411021635140.12891@nerd>
References: <41369CC7.1010203@coplanar.net> <Pine.GSO.4.60.0411021635140.12891@nerd>
Message-ID: <41881178.7050009@onelabs.com>

Marc Nicholas wrote:

> We're going to switch from using the EPIA MII series to EPIA MS as it 
> meets the needs of a digital entertainment device much better. Anyone 
> else working on getting the MS booting with LinuxBIOS, or will I be in 
> virgin territory? :-)

We're starting with the CN400 (found in the Epia N) and newer chipsets. 
For our apps. the CLE266 is too slow.

-Bari



From ebiederman at lnxi.com  Tue Nov  2 17:00:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Nov  2 17:00:01 2004
Subject: Segments in pre-C and C part
In-Reply-To: <1099435346.3373.40.camel@exponential.lanl.gov>
References: <1099435346.3373.40.camel@exponential.lanl.gov>
Message-ID: <m3wtx3kf8d.fsf@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:

> Eric,
> 
> Why we use two differenct segment lay out for pre-C and
> C part ?

For the code that runs from ram and the code that runs
directly from the rom chip.
 
> In entry32.inc it is 0x08 for code and 0x10 for data but
> in c_start we use 0x10 for code and 0x18 for data.

Good question but it is probably a decent thing that will
keep up from making too many assumptions that they have the
same gdt.

I don't believe this is something that has changed recently.

Eric


From ebiederman at lnxi.com  Tue Nov  2 17:03:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Nov  2 17:03:00 2004
Subject: Interrupt Handling
In-Reply-To: <1099435746.3373.44.camel@exponential.lanl.gov>
References: <1099435746.3373.44.camel@exponential.lanl.gov>
Message-ID: <m3sm7rkf2o.fsf@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:

> Eric,
> 
> Why there are two ways for interrupt handling in c_start.S

There are two ways for hardware exception handling.  Interrupts
are not handled.  And that is because on x86 exception handlers
don't always give you an error code.
 
> vec9:
>         pushl   $0 /* error code */
>         pushl   $9 /* vector */
>         jmp int_hand
>                                                                                                                                                
> 
> vec10:
>         /* error code */
>         pushl   $10 /* vector */
>         jmp     int_hand
>         .word   0x9090
> 
> Vector 9 push the error code and vector but vector 10 only push the 
> vector number.
> 
> BTW, are those handler actually used ? The idt is uninited.

This hunk below initializes it.  It seems to work out better to initialize the idt
with code instead of data.

       /* Initialize the Interrupt Descriptor table */
        leal    _idt, %edi
        leal    vec0, %ebx
        movl    $(0x10 << 16), %eax     /* cs selector */

1:      movw    %bx, %ax
        movl    %ebx, %edx
        movw    $0x8E00, %dx            /* Interrupt gate - dpl=0, present */
        movl    %eax, 0(%edi)
        movl    %edx, 4(%edi)
        addl    $6, %ebx
        addl    $8, %edi
        cmpl    $_idt_end, %edi
        jne     1b

        /* Load the Interrupt descriptor table */
        lidt    idtarg

Eric



From ebiederman at lnxi.com  Tue Nov  2 17:06:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Nov  2 17:06:00 2004
Subject: Removing .name field
In-Reply-To: <1099436457.3373.52.camel@exponential.lanl.gov>
References: <1099436457.3373.52.camel@exponential.lanl.gov>
Message-ID: <m3oeifkez4.fsf@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:

> Eric,
> 
> Since you relaxed the 64kB limit. Why you still removed the .name field?
> We really want the field back in for debugging purpose.

No one has shown me a use or an example of a use.  I have simply heard
that the name field is a good thing.  

Show me how it would be used and I don't have a problem with not 
removing it.  As it simply looks totally like dead code to me.

In addition while I have relaxed the 64KiB limit I still want to watch
the code size.

Eric


From ebiederman at lnxi.com  Tue Nov  2 17:09:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Nov  2 17:09:00 2004
Subject: Weird K8 output
In-Reply-To: <20041102220333.GA28577@openbios.org>
References: <20041102200548.GA19658@openbios.org>
	<m3654o55cc.fsf@maxwell.lnxi.com>
	<20041102220333.GA28577@openbios.org>
Message-ID: <m3k6t3kex1.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at openbios.org> writes:

> * Eric W. Biederman <ebiederman at lnxi.com> [041102 22:05]:
> > Hmm.  It looks like you have non-bootstrap cpus running through the code.
> > 
> > Usually it is this hunk of code that traps errors.
> > 	if (!boot_cpu()) {
> > 		stop_this_cpu();
>  
> > Although I can see something very weird happening if you have
> > BIST failure, on your secondary cpus. But that is quite 
> > unlikely.
>  
> But that is something that would be reported, somehow, before setting
> the resource map, no?

Not on the second cpu...
 
> > > Is the machine drunk or are CPU1-3 just running away?
> > 
> > It looks like the cpus are just running away :(  Usually I would
> > expect to interlaced characters form a message I recognize.  But I
> > don't recognize see anything I recognize here.
>  
> 
> Looking closer, it almost looks like Clearing mtrr
> 
> > > Renaming current temporary node to 01 done.
> > > anabling routing table for node 01 dConlee.
>                                         C  l e
> > >  tRiennamgin g mcutrrrenrt
>      t i n   g   g m  tr    r
> 
> as in print_spew("Clearing mtrr\r\n"); of do_early_mtrr_init.c
> 
> Ha, it looks like noone had a chance to compile with spew messages in
> quite a while ;-) mtrr setup is long called before stop_cpu. So the
> messages seem to be unrelated to the hang..

Cool.  I wonder if we want to kill those messages.  In the
normal course of affairs I can't see how they would help...

Eric


From ollie at lanl.gov  Tue Nov  2 17:11:06 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Tue Nov  2 17:11:06 2004
Subject: Segments in pre-C and C part
In-Reply-To: <m3wtx3kf8d.fsf@maxwell.lnxi.com>
References: <1099435346.3373.40.camel@exponential.lanl.gov>
	 <m3wtx3kf8d.fsf@maxwell.lnxi.com>
Message-ID: <1099438257.3373.54.camel@exponential.lanl.gov>

On Tue, 2004-11-02 at 16:23, Eric W. Biederman wrote:
> Li-Ta Lo <ollie at lanl.gov> writes:
> 
> > Eric,
> > 
> > Why we use two differenct segment lay out for pre-C and
> > C part ?
> 
> For the code that runs from ram and the code that runs
> directly from the rom chip.
>  
> > In entry32.inc it is 0x08 for code and 0x10 for data but
> > in c_start we use 0x10 for code and 0x18 for data.
> 
> Good question but it is probably a decent thing that will
> keep up from making too many assumptions that they have the
> same gdt.
> 
> I don't believe this is something that has changed recently.
> 

It is there for a long time. I just want to know why.

Ollie

> Eric
> 



From stepan at openbios.org  Tue Nov  2 17:19:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue Nov  2 17:19:01 2004
Subject: Interrupt Handling
In-Reply-To: <m3sm7rkf2o.fsf@maxwell.lnxi.com>
References: <1099435746.3373.44.camel@exponential.lanl.gov> <m3sm7rkf2o.fsf@maxwell.lnxi.com>
Message-ID: <20041102234257.GA31121@openbios.org>

* Eric W. Biederman <ebiederman at lnxi.com> [041103 00:26]:
> This hunk below initializes it.  It seems to work out better to initialize the idt
> with code instead of data.
> 
>        /* Initialize the Interrupt Descriptor table */
>         leal    _idt, %edi
>         leal    vec0, %ebx
>         movl    $(0x10 << 16), %eax     /* cs selector */
> 
> 1:      movw    %bx, %ax
>         movl    %ebx, %edx
>         movw    $0x8E00, %dx            /* Interrupt gate - dpl=0, present */
>         movl    %eax, 0(%edi)
>         movl    %edx, 4(%edi)
>         addl    $6, %ebx
>         addl    $8, %edi
>         cmpl    $_idt_end, %edi
>         jne     1b
> 
>         /* Load the Interrupt descriptor table */
>         lidt    idtarg

What would btw be the correct way of resuming operation after, say, a
division by zero exception? I tried to set a new info->eip in
x86_exception() to a helper function, but I get the honour of a GPF
right after returning from that function... finding it jumps into the
stack at some point.

Stefan




From stepan at openbios.org  Tue Nov  2 17:26:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue Nov  2 17:26:00 2004
Subject: Weird K8 output
In-Reply-To: <3174569B9743D511922F00A0C94314230665B9AB@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665B9AB@TYANWEB>
Message-ID: <20041102234946.GA31240@openbios.org>

* YhLu <YhLu at tyan.com> [041102 21:27]:
> done
> PCI_DEV=(0,0x18,0) 0xb4=00030000
> bus=00 id =74501022
> bus=00 id =74601022
> PCI_DEV=(0,0x19,0) 0xd4=000a0400

Hm.. it dies here while collapsing the previous enumeration.

adding more debug now...

Stefan




From ebiederman at lnxi.com  Tue Nov  2 17:29:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Nov  2 17:29:01 2004
Subject: Segments in pre-C and C part
In-Reply-To: <1099438257.3373.54.camel@exponential.lanl.gov>
References: <1099435346.3373.40.camel@exponential.lanl.gov>
	<m3wtx3kf8d.fsf@maxwell.lnxi.com>
	<1099438257.3373.54.camel@exponential.lanl.gov>
Message-ID: <m3zn1zn72x.fsf@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:

> On Tue, 2004-11-02 at 16:23, Eric W. Biederman wrote:
> > Li-Ta Lo <ollie at lanl.gov> writes:
> > 
> > > Eric,
> > > 
> > > Why we use two differenct segment lay out for pre-C and
> > > C part ?
> > 
> > For the code that runs from ram and the code that runs
> > directly from the rom chip.
> >  
> > > In entry32.inc it is 0x08 for code and 0x10 for data but
> > > in c_start we use 0x10 for code and 0x18 for data.
> > 
> > Good question but it is probably a decent thing that will
> > keep up from making too many assumptions that they have the
> > same gdt.
> > 
> > I don't believe this is something that has changed recently.
> > 
> 
> It is there for a long time. I just want to know why.

To be clear I think it was because we were confusing which gdt was which
at some point.  With different segment values we cannot have that confusion.
And if you are actually mucking with segments I think not confusing
the two is important.

Eric


From stepan at openbios.org  Tue Nov  2 17:44:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue Nov  2 17:44:00 2004
Subject: Weird K8 output
In-Reply-To: <20041102234946.GA31240@openbios.org>
References: <3174569B9743D511922F00A0C94314230665B9AB@TYANWEB> <20041102234946.GA31240@openbios.org>
Message-ID: <20041103000706.GA31774@openbios.org>

* Stefan Reinauer <stepan at openbios.org> [041103 00:49]:
> * YhLu <YhLu at tyan.com> [041102 21:27]:
> > done
> > PCI_DEV=(0,0x18,0) 0xb4=00030000
> > bus=00 id =74501022
> > bus=00 id =74601022
> > PCI_DEV=(0,0x19,0) 0xd4=000a0400
> 
> Hm.. it dies here while collapsing the previous enumeration.
 
While collapsing 74501022 again...

Can anyone shed some light on why the repeated collapse is needed?

   Stefan



From YhLu at tyan.com  Tue Nov  2 17:58:01 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Nov  2 17:58:01 2004
Subject: Weird K8 output
Message-ID: <3174569B9743D511922F00A0C94314230665BA00@TYANWEB>

Yes, 

You are right, 

You can change to 
//                upos = ht_c[i].upos;
                upos = ((reg & 0xf00)>>8) * 0x20 + 0x80;

last time, I remember because it will use up regs. But this time seems OK.

regards

Yinghai Lu
-----Original Message-----
From: Stefan Reinauer [mailto:stepan at openbios.org] 
Sent: Tuesday, November 02, 2004 3:31 PM
To: YhLu
Subject: Re: Weird K8 output

* YhLu <YhLu at tyan.com> [041102 21:27]:
> MB Model?
> HT routing table?
 
It was too loud (LOGLEVEL 9) 

BUT:

> coherent_ht_finalize
> done
> PCI_DEV=(0,0x18,0) 0xb4=00030000
> bus=00 id =74501022
> bus=00 id =74601022
> PCI_DEV=(0,0x19,0) 0xd4=000a0400
  <HANGS HERE>

static int ht_setup_chains(const struct ht_chain *ht_c, int ht_c_num)
takes:
                [...]
                { /* Link 1 of CPU0 */
                        .udev = PCI_DEV(0, 0x18, 0),
                        .upos = 0xa0,
                        .devreg = 0xe0,
                },
                { /* Link 2 of CPU1 */
                        .udev = PCI_DEV(0, 0x19, 0),
                        .upos = 0xc0,
                        .devreg = 0xe4, 
                },
                [...]

and resourcemap.c:
        PCI_ADDR(0, 0x18, 1, 0xE0), 0x0000FC88, 0x03000103,
        PCI_ADDR(0, 0x18, 1, 0xE4), 0x0000FC88, 0x0a040213,
        PCI_ADDR(0, 0x18, 1, 0xE8), 0x0000FC88, 0x0f0b0223,
        PCI_ADDR(0, 0x18, 1, 0xEC), 0x0000FC88, 0x14100133,

Question1:
I took the bus numbers above from the running machine. is this wrong? 
How would I calculate them correctly?

Question2:
isn't .upos duplicate?
ht_setup_chains reads the link to choose from .devreg. It could
determine .upos from there as well, no?

    Stefan


From YhLu at tyan.com  Tue Nov  2 18:00:11 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Nov  2 18:00:11 2004
Subject: Weird K8 output
Message-ID: <3174569B9743D511922F00A0C94314230665BA06@TYANWEB>

Only two times
Once in crt0 
One in LinuxBIOS_ram.   Device.
Besides updating unitid, device scan need to update bus number too.

Regards

Yinghai Lu

-----Original Message-----
From: Stefan Reinauer [mailto:stepan at openbios.org] 
Sent: Tuesday, November 02, 2004 4:07 PM
To: YhLu
Cc: linuxbios at clustermatic.org
Subject: Re: Weird K8 output

* Stefan Reinauer <stepan at openbios.org> [041103 00:49]:
> * YhLu <YhLu at tyan.com> [041102 21:27]:
> > done
> > PCI_DEV=(0,0x18,0) 0xb4=00030000
> > bus=00 id =74501022
> > bus=00 id =74601022
> > PCI_DEV=(0,0x19,0) 0xd4=000a0400
> 
> Hm.. it dies here while collapsing the previous enumeration.
 
While collapsing 74501022 again...

Can anyone shed some light on why the repeated collapse is needed?

   Stefan


From stepan at openbios.org  Tue Nov  2 18:07:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue Nov  2 18:07:01 2004
Subject: Weird K8 output
In-Reply-To: <3174569B9743D511922F00A0C94314230665BA06@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665BA06@TYANWEB>
Message-ID: <20041103003018.GA32097@openbios.org>

* YhLu <YhLu at tyan.com> [041103 01:17]:
> Only two times
> Once in crt0 
> One in LinuxBIOS_ram.   Device.
> Besides updating unitid, device scan need to update bus number too.

You are right. I confused the 8131 at cpu0 with the one at cpu1.

PCI_DEV=(0,0x18,0) 0xb4=00030000
Collapsing device: 74501022
Collapsing device: 74601022
collapsed enumeration
bus=00 id =74501022
bus=00 id =74601022
PCI_DEV=(0,0x19,0) 0xd4=000a0400
Collapsing device: 74501022

Stefan




From YhLu at tyan.com  Tue Nov  2 18:40:01 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Nov  2 18:40:01 2004
Subject: Weird K8 output
Message-ID: <3174569B9743D511922F00A0C94314230665BA0B@TYANWEB>

Can you let us know the incoherent device in CPU 0....CPU3..?

Some device unit id can not be changed? For examples, you set it from 0 to
1, it will still be 0. So it hang there....

Regards

YH

-----Original Message-----
From: YhLu 
Sent: Tuesday, November 02, 2004 4:07 PM
To: 'Stefan Reinauer'
Cc: linuxbios at clustermatic.org
Subject: RE: Weird K8 output

Yes, 

You are right, 

You can change to 
//                upos = ht_c[i].upos;
                upos = ((reg & 0xf00)>>8) * 0x20 + 0x80;

last time, I remember because it will use up regs. But this time seems OK.

regards

Yinghai Lu
-----Original Message-----
From: Stefan Reinauer [mailto:stepan at openbios.org] 
Sent: Tuesday, November 02, 2004 3:31 PM
To: YhLu
Subject: Re: Weird K8 output

* YhLu <YhLu at tyan.com> [041102 21:27]:
> MB Model?
> HT routing table?
 
It was too loud (LOGLEVEL 9) 

BUT:

> coherent_ht_finalize
> done
> PCI_DEV=(0,0x18,0) 0xb4=00030000
> bus=00 id =74501022
> bus=00 id =74601022
> PCI_DEV=(0,0x19,0) 0xd4=000a0400
  <HANGS HERE>

static int ht_setup_chains(const struct ht_chain *ht_c, int ht_c_num)
takes:
                [...]
                { /* Link 1 of CPU0 */
                        .udev = PCI_DEV(0, 0x18, 0),
                        .upos = 0xa0,
                        .devreg = 0xe0,
                },
                { /* Link 2 of CPU1 */
                        .udev = PCI_DEV(0, 0x19, 0),
                        .upos = 0xc0,
                        .devreg = 0xe4, 
                },
                [...]

and resourcemap.c:
        PCI_ADDR(0, 0x18, 1, 0xE0), 0x0000FC88, 0x03000103,
        PCI_ADDR(0, 0x18, 1, 0xE4), 0x0000FC88, 0x0a040213,
        PCI_ADDR(0, 0x18, 1, 0xE8), 0x0000FC88, 0x0f0b0223,
        PCI_ADDR(0, 0x18, 1, 0xEC), 0x0000FC88, 0x14100133,

Question1:
I took the bus numbers above from the running machine. is this wrong? 
How would I calculate them correctly?

Question2:
isn't .upos duplicate?
ht_setup_chains reads the link to choose from .devreg. It could
determine .upos from there as well, no?

    Stefan


From YhLu at tyan.com  Tue Nov  2 18:42:18 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Nov  2 18:42:18 2004
Subject: Weird K8 output
Message-ID: <3174569B9743D511922F00A0C94314230665BA0F@TYANWEB>

I removed the udev and upos in ht_chains.

Commited.


CVS: ----------------------------------------------------------------------
CVS: Enter Log.  Lines beginning with `CVS:' are removed automatically
CVS:
CVS: Committing in .
CVS:
CVS: Modified Files:
CVS:    src/mainboard/amd/quartet/auto.c
CVS:    src/mainboard/tyan/s2885/auto.c
CVS:    src/northbridge/amd/amdk8/incoherent_ht.c
CVS: ----------------------------------------------------------------------


From ebiederman at lnxi.com  Tue Nov  2 18:45:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Nov  2 18:45:01 2004
Subject: tagging freebios2 tree
In-Reply-To: <1099430679.3373.21.camel@exponential.lanl.gov>
References: <Pine.LNX.4.44.0408231050200.26484-100000@maxroach.lanl.gov>
	<m3llg5bwc8.fsf@maxwell.lnxi.com>
	<1093361287.23596.99.camel@exponential.lanl.gov>
	<m3y8k4xbxf.fsf@maxwell.lnxi.com>
	<1099430679.3373.21.camel@exponential.lanl.gov>
Message-ID: <m3ekjbd9me.fsf@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:

> On Tue, 2004-08-24 at 19:07, Eric W. Biederman wrote:
> > No quite I put the cpu_info structure at the bottom of the stack,
> > and this function looks it up.
> > 
> > The same idea has been used in the kernel for quite a while.  
> > 
> > Basically this allows me to preallocate some per cpu information
> > and to pass that into cpu_initialize from another cpu.
> > 
> > The linux kernel has been doing something similar for quite a while.
> > 
> 
> Does cpu_info() return different value depends on which CPU it is 
> running ?

Yes.  The stack is per cpu and it returns a fixed address from
the stack structure.

 > Are the data structures per CPU or shared between CPUs ?

per-cpu.  Which is the point.

Eric


From ebiederman at lnxi.com  Tue Nov  2 18:48:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Nov  2 18:48:00 2004
Subject: status information
In-Reply-To: <Pine.LNX.4.58.0411011015490.24927@linux.site>
References: <20041028115139.GA19778@openbios.org>
	<m3654v9gbn.fsf@maxwell.lnxi.com>
	<Pine.LNX.4.58.0410280813530.7845@linux.site>
	<m3wtxaqx83.fsf@maxwell.lnxi.com> <20041030160434.GA5786@openbios.org>
	<Pine.LNX.4.58.0411011015490.24927@linux.site>
Message-ID: <m3actzd9f7.fsf@maxwell.lnxi.com>

"Ronald G. Minnich" <rminnich at lanl.gov> writes:

> On Sat, 30 Oct 2004, Stefan Reinauer wrote:
> 
> > What was the original intention of the structure? It might be nice to
> > know how many sockets there are and what CPUs are in those sockets.. 
> > (ie some dmi kind of information)
> 
> it would have allowed for more debug information, but it appear that 
> requests from a number of people to leave it in there were ignored.

Nothing was ignored but no case was presented for retention of
the .name member.

No one has even given me the details of how they expect the structure
element to be used much less a working code example.

Eric



From YhLu at tyan.com  Tue Nov  2 21:34:00 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Nov  2 21:34:00 2004
Subject: tagging freebios2 tree
Message-ID: <3174569B9743D511922F00A0C94314230665BA3D@TYANWEB>

For DP Xeon MB, CONFIG_MAX_CPUS should be 4 or 2?

It is used only by you said stack....

config/linuxbios_ram.ld:                . = (CONFIG_MAX_CPUS * STACK_SIZE) ;
cpu/x86/pae/pgtbl.c:    static struct pg_table pgtbl[CONFIG_MAX_CPUS]
__attribute__ ((aligned(4096)));
cpu/x86/pae/pgtbl.c:    static unsigned long mapped_window[CONFIG_MAX_CPUS];
cpu/x86/pae/pgtbl.c:    if ((index < 0) || (index >= CONFIG_MAX_CPUS)) {

YH

-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Tuesday, November 02, 2004 5:06 PM
To: Li-Ta Lo
Cc: LinuxBIOS
Subject: Re: tagging freebios2 tree

Li-Ta Lo <ollie at lanl.gov> writes:

> On Tue, 2004-08-24 at 19:07, Eric W. Biederman wrote:
> > No quite I put the cpu_info structure at the bottom of the stack,
> > and this function looks it up.
> > 
> > The same idea has been used in the kernel for quite a while.  
> > 
> > Basically this allows me to preallocate some per cpu information
> > and to pass that into cpu_initialize from another cpu.
> > 
> > The linux kernel has been doing something similar for quite a while.
> > 
> 
> Does cpu_info() return different value depends on which CPU it is 
> running ?

Yes.  The stack is per cpu and it returns a fixed address from
the stack structure.

 > Are the data structures per CPU or shared between CPUs ?

per-cpu.  Which is the point.

Eric
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From stepan at openbios.org  Wed Nov  3 01:49:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Wed Nov  3 01:49:00 2004
Subject: Weird K8 output
In-Reply-To: <3174569B9743D511922F00A0C94314230665BA0F@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665BA0F@TYANWEB>
Message-ID: <20041103081225.GA4711@openbios.org>

* YhLu <YhLu at tyan.com> [041103 01:54]:
> I removed the udev and upos in ht_chains.
> 
> Commited.
 
wonderful, thanks!

Stefan



From ebiederman at lnxi.com  Wed Nov  3 01:53:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Nov  3 01:53:01 2004
Subject: tagging freebios2 tree
In-Reply-To: <3174569B9743D511922F00A0C94314230665BA3D@TYANWEB>
References: <3174569B9743D511922F00A0C94314230665BA3D@TYANWEB>
Message-ID: <m3actz73kq.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> For DP Xeon MB, CONFIG_MAX_CPUS should be 4 or 2?
> 
> It is used only by you said stack....

It should be 4.  It is used to allocate per cpu sized arrays.
The one per cpu data structure you have found are the page tables for
accessing more than 4GiB of memory.  They are actually quite small as
I always use 2MiB pages.  

 
> config/linuxbios_ram.ld:                . = (CONFIG_MAX_CPUS * STACK_SIZE) ;
> cpu/x86/pae/pgtbl.c:    static struct pg_table pgtbl[CONFIG_MAX_CPUS]
> __attribute__ ((aligned(4096)));
> cpu/x86/pae/pgtbl.c:    static unsigned long mapped_window[CONFIG_MAX_CPUS];
> cpu/x86/pae/pgtbl.c:    if ((index < 0) || (index >= CONFIG_MAX_CPUS)) {
 
Eric


From stepan at openbios.org  Wed Nov  3 02:05:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Wed Nov  3 02:05:00 2004
Subject: Makefile changes for symbols
In-Reply-To: <m3654xvjmv.fsf@maxwell.lnxi.com>
References: <1098480250.16598.22.camel@exponential.lanl.gov> <1098481504.2738.7.camel@localhost.localdomain> <Pine.LNX.4.58.0410221617230.16599@linux.site> <1098710105.2721.3.camel@localhost.localdomain> <Pine.LNX.4.58.0410250850150.25731@linux.site> <1098719346.2721.140.camel@localhost.localdomain> <Pine.LNX.4.58.0410250958540.25731@linux.site> <1098732363.16598.69.camel@exponential.lanl.gov> <20041026073904.GA9126@openbios.org> <m3654xvjmv.fsf@maxwell.lnxi.com>
Message-ID: <20041103082832.GD4711@openbios.org>

* Eric W. Biederman <ebiederman at lnxi.com> [041026 12:50]:
> Stefan Reinauer <stepan at openbios.org> writes:
> > Now that A stepping CPUs start dying out, could we not switch the reset
> > mechanism to use LDTSTOP instead of a complete reset? 
> > It's more solid and a lot faster.
> 
> Solid?  There are several errata with using LDTSTOP and you can not use it after
> memory is initialized. 

We don't do this anyways, do we?

In situations with marginal timing for RESET#, there is less chance of
something going wrong. Hardware is rarely perfect, and LDTSTOP# affects
less of it, so it is a little more robust. 

  Stefan




From koryherzinger at yahoo.com  Wed Nov  3 02:29:01 2004
From: koryherzinger at yahoo.com (Kory Herzinger)
Date: Wed Nov  3 02:29:01 2004
Subject: some questions about nForce and LinuxBIOS
Message-ID: <20041103085255.62180.qmail@web41012.mail.yahoo.com>


I am working on my senior project in college, and have run into a slight issue with how long it takes for my BIOS to POST. I would like LinuxBIOS to boot my system into a minimal Linux kernel in as little amount of time as necessary, and then have that kernel boot into a Linux system I've already built and configured on the hard drive. From doing some research on your project I've found that this goes by the catchy name of LOBOS :-) From the kernel that the LinuxBIOS will boot, I don't need network, sound, or video support. I'd like to leave it up to the existing Linux installation on my hard drive to bring up these devices for me. Here's the specs on the board I am using:

Northbridge: NForce2 Crush 18G IGP chipset
Southbridge: MCP chipset / High-speed interface to the MCP
OnBoard GFX: NVidia GeForce4 MX

The board has support for TV composite signal-out which I will be using once the system is up and running, but since nVidia doesn't release specs or source for their hardware, I obviously can't use it during the BIOS phase. So I guess the real questions are:

1) Is it possible to build a LinuxBIOS that will run on my system?
2) If so, since the support for network, sound, and audio devices will not be present in the BIOS, can I still bring them up in my Linux kernel using the proprietary drivers distributed by nVidia?
3) If the above two scenarios are possible, could I throw my linux system currently on the hard drive into a NVRAM device and boot it from there to further reduce boot time?

I appreciate your help with this. If you are interested in my senior project, there is information on my project website: www.novagameconsole.com

Anything you can offer is greatly appreciated! Thanks!

			
---------------------------------
Do you Yahoo!?
 Check out the new Yahoo! Front Page.  www.yahoo.com/a
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20041103/317293fa/attachment.html>

From cro_marmot at comcast.net  Wed Nov  3 03:29:00 2004
From: cro_marmot at comcast.net (David Hendricks)
Date: Wed Nov  3 03:29:00 2004
Subject: some questions about nForce and LinuxBIOS
In-Reply-To: <20041103085255.62180.qmail@web41012.mail.yahoo.com>
References: <20041103085255.62180.qmail@web41012.mail.yahoo.com>
Message-ID: <20041103025406.08c375d3@sunder>

I don't think anyone's done an nForce2 port for LinuxBIOS. The nForce4
on the other hand might be different, you would have to ask Dr. Lu @
Tyan about that.

And Ron might have just made bootup time <= 8 seconds for K8s. I'm dying
to try this stuff out on my nForce3 :)

On Wed, 3 Nov 2004 00:52:55 -0800 (PST)
Kory Herzinger <koryherzinger at yahoo.com> wrote:

> 
> I am working on my senior project in college, and have run into a
> slight issue with how long it takes for my BIOS to POST. I would like
> LinuxBIOS to boot my system into a minimal Linux kernel in as little
> amount of time as necessary, and then have that kernel boot into a
> Linux system I've already built and configured on the hard drive. From
> doing some research on your project I've found that this goes by the
> catchy name of LOBOS :-) From the kernel that the LinuxBIOS will boot,
> I don't need network, sound, or video support. I'd like to leave it up
> to the existing Linux installation on my hard drive to bring up these
> devices for me. Here's the specs on the board I am using:
> 
> Northbridge: NForce2 Crush 18G IGP chipset
> Southbridge: MCP chipset / High-speed interface to the MCP
> OnBoard GFX: NVidia GeForce4 MX
> 
> The board has support for TV composite signal-out which I will be
> using once the system is up and running, but since nVidia doesn't
> release specs or source for their hardware, I obviously can't use it
> during the BIOS phase. So I guess the real questions are:
> 
> 1) Is it possible to build a LinuxBIOS that will run on my system?
> 2) If so, since the support for network, sound, and audio devices will
> not be present in the BIOS, can I still bring them up in my Linux
> kernel using the proprietary drivers distributed by nVidia? 3) If the
> above two scenarios are possible, could I throw my linux system
> currently on the hard drive into a NVRAM device and boot it from there
> to further reduce boot time?
> 
> I appreciate your help with this. If you are interested in my senior
> project, there is information on my project website:
> www.novagameconsole.com
> 
> Anything you can offer is greatly appreciated! Thanks!
> 
> 			
> ---------------------------------
> Do you Yahoo!?
>  Check out the new Yahoo! Front Page.  www.yahoo.com/a


From zhushisongzhu at yahoo.com  Wed Nov  3 04:39:01 2004
From: zhushisongzhu at yahoo.com (zhu shi song)
Date: Wed Nov  3 04:39:01 2004
Subject: i845GV ddr sdram init passed
Message-ID: <20041103110302.37516.qmail@web13205.mail.yahoo.com>

After working hard for three day, I have made i845gv
ddr sdram work well.  I can boot linux 2.4.27 with
root filesystem on my hard disk.  But linux 2.4.27
support new hardware weakly. So I hope I can boot
linux 2.6.  I have before used initrd dyn invented by
l inux router project to boot linux 2.4.  I like the
way booting linux.
 (1) Who knows can initrd dyn support linux 2.6.  I
know the latest version of initrd dyn is for
linux2.5.54.
 (2) If unfortunately I can't use initrd dyn again,
how can I make my root fs?  how can I boot linux 2.6
using tar.gz file as root filesystem?

  tks
  zhu





		
__________________________________ 
Do you Yahoo!? 
Check out the new Yahoo! Front Page. 
www.yahoo.com 
 



From donald.zoch at amd.com  Wed Nov  3 08:06:01 2004
From: donald.zoch at amd.com (Donald Zoch)
Date: Wed Nov  3 08:06:01 2004
Subject: flash_rom on SST49LF004B tips?
Message-ID: <20041101200807.A8449@orkney.amd.com>

I'm trying to get the flash_rom program working on the SST49LF004B.
This is the part that is coming in our newer Arima HDAMA boards that
replaces the SST49LF040.   It has the same id as the SST49LF004A,
but is different in that when we first started trying to flash it, the
flash looked like it worked but would never verify.   I took a look
at the data sheet and from the looks of it there are these block locking
registers that the zero bit must be cleared in in order to write to
certain parts of the flash.  At least that's why I think it's not
flashing.   

I'm trying to zero out the registers, but it appears as if the first
4 cannot be cleared out.   The last 4 look like they're being set to 
zero.   I have tried to calculate the register locations by looking
at the probe jedec code and seeing that the jedec ID registers are
at bios and bios + 0x01.  I then looked in the data sheet at where those
registers appear in the memory map and then calculated the register
memory locations as offsets to bios, some negative offsets and some
positive.  

I've also tried anding that value with 0xFE just to zero out the bit
that I need, but that doesn't seem to work.   I can never seem
to change the values in the first four registers.

Do either of you have any pointers on how to get this to work?                       
I will attach the data sheet for the flash part.  It's
the 49lf004b that I'm interested in. 

void unprotect_49lf004b(volatile unsigned char *bios)
    {
      *(volatile unsigned char *) (bios + 0x30002) = 0x00; 
      printf("REGISTER HAS VALUE 0x%x AFTER\n",*(volatile unsigned char *)(bios + 0x30002));
      *(volatile unsigned char *) (bios + 0x20002) = 0x00; 
      printf("REGISTER HAS VALUE 0x%x AFTER\n",*(volatile unsigned char *)(bios + 0x20002));
      *(volatile unsigned char *) (bios + 0x10002) = 0x00; 
      printf("REGISTER HAS VALUE 0x%x AFTER\n",*(volatile unsigned char *)(bios + 0x10002));
      *(volatile unsigned char *) (bios + 0x00002) = 0x00; 
      printf("REGISTER HAS VALUE 0x%x AFTER\n",*(volatile unsigned char *)(bios + 0x00002));
      *(volatile unsigned char *) (bios - 0xFFFE) = 0x00; 
      printf("REGISTER HAS VALUE 0x%x AFTER\n",*(volatile unsigned char *)(bios - 0xFFFE));
      *(volatile unsigned char *) (bios - 0x1FFFE) = 0x00; 
      printf("REGISTER HAS VALUE 0x%x AFTER\n",*(volatile unsigned char *)(bios - 0x1FFFE));
      *(volatile unsigned char *) (bios - 0x2FFFE) = 0x00; 
      printf("REGISTER HAS VALUE 0x%x AFTER\n",*(volatile unsigned char *)(bios - 0x2FFFE));
      *(volatile unsigned char *) (bios - 0x3FFFE) = 0x00; 
      printf("REGISTER HAS VALUE 0x%x AFTER\n",*(volatile unsigned char *)(bios - 0x3FFFE));
}
    

Donald
----
Donald Zoch                    
Phone: (512) 602-7945
Pager: (512) 604-5401
donald.zoch at amd.com                 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: S71232.pdf
Type: application/pdf
Size: 509866 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20041103/143b6b4a/attachment.pdf>

From rminnich at lanl.gov  Wed Nov  3 10:24:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed Nov  3 10:24:00 2004
Subject: some questions about nForce and LinuxBIOS
In-Reply-To: <20041103085255.62180.qmail@web41012.mail.yahoo.com>
References: <20041103085255.62180.qmail@web41012.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0411030947040.30684@linux.site>


On Wed, 3 Nov 2004, Kory Herzinger wrote:

> 1) Is it possible to build a LinuxBIOS that will run on my system?

Given Nvidia's current level of helpfulness, no. Sorry.

ron


From rminnich at lanl.gov  Wed Nov  3 10:30:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed Nov  3 10:30:00 2004
Subject: flash_rom on SST49LF004B tips?
In-Reply-To: <20041101200807.A8449@orkney.amd.com>
References: <20041101200807.A8449@orkney.amd.com>
Message-ID: <Pine.LNX.4.58.0411030950040.30684@linux.site>


On Mon, 1 Nov 2004, Donald Zoch wrote:

> I'm trying to get the flash_rom program working on the SST49LF004B.
> This is the part that is coming in our newer Arima HDAMA boards that
> replaces the SST49LF040.   It has the same id as the SST49LF004A,
> but is different in that when we first started trying to flash it, the
> flash looked like it worked but would never verify.   I took a look
> at the data sheet and from the looks of it there are these block locking
> registers that the zero bit must be cleared in in order to write to
> certain parts of the flash.  At least that's why I think it's not
> flashing.   

I did a part like that already, the sst 49lf008a. 

Look in flash_rom. It works fine.

ron


From ollie at lanl.gov  Wed Nov  3 10:47:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Wed Nov  3 10:47:00 2004
Subject: flash_rom on SST49LF004B tips?
In-Reply-To: <Pine.LNX.4.58.0411030950040.30684@linux.site>
References: <20041101200807.A8449@orkney.amd.com>
	 <Pine.LNX.4.58.0411030950040.30684@linux.site>
Message-ID: <1099501820.3373.66.camel@exponential.lanl.gov>

On Wed, 2004-11-03 at 09:53, Ronald G. Minnich wrote:
> On Mon, 1 Nov 2004, Donald Zoch wrote:
> 
> > I'm trying to get the flash_rom program working on the SST49LF004B.
> > This is the part that is coming in our newer Arima HDAMA boards that
> > replaces the SST49LF040.   It has the same id as the SST49LF004A,
> > but is different in that when we first started trying to flash it, the
> > flash looked like it worked but would never verify.   I took a look
> > at the data sheet and from the looks of it there are these block locking
> > registers that the zero bit must be cleared in in order to write to
> > certain parts of the flash.  At least that's why I think it's not
> > flashing.   
> 
> I did a part like that already, the sst 49lf008a. 
> 
> Look in flash_rom. It works fine.
> 

BTW, there is some unknown proble to flash some SST flash in 64-bit
mode. I have no idea why. It works perfectly in 32-bit mode.

Ollie

> ron
> 



From ollie at lanl.gov  Wed Nov  3 12:27:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Wed Nov  3 12:27:00 2004
Subject: tagging freebios2 tree
In-Reply-To: <m3ekjbd9me.fsf@maxwell.lnxi.com>
References: <Pine.LNX.4.44.0408231050200.26484-100000@maxroach.lanl.gov>
	 <m3llg5bwc8.fsf@maxwell.lnxi.com>
	 <1093361287.23596.99.camel@exponential.lanl.gov>
	 <m3y8k4xbxf.fsf@maxwell.lnxi.com>
	 <1099430679.3373.21.camel@exponential.lanl.gov>
	 <m3ekjbd9me.fsf@maxwell.lnxi.com>
Message-ID: <1099507835.3373.92.camel@exponential.lanl.gov>

On Tue, 2004-11-02 at 18:06, Eric W. Biederman wrote:
> Li-Ta Lo <ollie at lanl.gov> writes:
> 
> > On Tue, 2004-08-24 at 19:07, Eric W. Biederman wrote:
> > > No quite I put the cpu_info structure at the bottom of the stack,
> > > and this function looks it up.
> > > 
> > > The same idea has been used in the kernel for quite a while.  
> > > 
> > > Basically this allows me to preallocate some per cpu information
> > > and to pass that into cpu_initialize from another cpu.
> > > 
> > > The linux kernel has been doing something similar for quite a while.
> > > 
> > 
> > Does cpu_info() return different value depends on which CPU it is 
> > running ?
> 
> Yes.  The stack is per cpu and it returns a fixed address from
> the stack structure.
> 

Why you push the cpu index and struct cpu in c_start.S ? Is it parameter
to the hardwaremain() ?

And why you save the %esp before init IDT and restore it ? I don't see
it is modified when init IDT.

BTW, I think c_start.S is only executed on BSP, right ?

Ollie

	/* Push the cpu index and struct cpu */
	pushl	$0
	pushl	$0

	/* push the boot_complete flag */
	pushl	%ebp

	/* Save the stack location */
	movl	%esp, %ebp

	/* Initialize the Interrupt Descriptor table */
	xxx
	xxx	

	/* Load the Interrupt descriptor table */
	lidt	idtarg

	intel_chip_post_macro(0xfe)	/* post fe */

	/* Restore the stack location */
	movl	%ebp, %esp
	
	/* The boot_complete flag has already been pushed */
	call	hardwaremain
	/*NOTREACHED*/



From YhLu at tyan.com  Wed Nov  3 12:54:01 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Nov  3 12:54:01 2004
Subject: flash_rom on SST49LF004B tips?
Message-ID: <3174569B9743D511922F00A0C94314230665BA4F@TYANWEB>

That should be kernel 2.6 bug under 64bit: the last 4k near 4G can not be
accessed when 4G RAM installed.

Regards

YH

-----Original Message-----
From: Li-Ta Lo [mailto:ollie at lanl.gov] 
Sent: Wednesday, November 03, 2004 9:10 AM
To: Ronald G. Minnich
Cc: Donald Zoch; Hendricks David W.; LinuxBIOS
Subject: Re: flash_rom on SST49LF004B tips?

On Wed, 2004-11-03 at 09:53, Ronald G. Minnich wrote:
> On Mon, 1 Nov 2004, Donald Zoch wrote:
> 
> > I'm trying to get the flash_rom program working on the SST49LF004B.
> > This is the part that is coming in our newer Arima HDAMA boards that
> > replaces the SST49LF040.   It has the same id as the SST49LF004A,
> > but is different in that when we first started trying to flash it, the
> > flash looked like it worked but would never verify.   I took a look
> > at the data sheet and from the looks of it there are these block locking
> > registers that the zero bit must be cleared in in order to write to
> > certain parts of the flash.  At least that's why I think it's not
> > flashing.   
> 
> I did a part like that already, the sst 49lf008a. 
> 
> Look in flash_rom. It works fine.
> 

BTW, there is some unknown proble to flash some SST flash in 64-bit
mode. I have no idea why. It works perfectly in 32-bit mode.

Ollie

> ron
> 

_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From YhLu at tyan.com  Wed Nov  3 12:54:16 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Nov  3 12:54:16 2004
Subject: some questions about nForce and LinuxBIOS
Message-ID: <3174569B9743D511922F00A0C94314230665BA50@TYANWEB>

Tom warren from Nvidia seems work on LinuxBIOS support on (k8s....)

Regards

YH
-----Original Message-----
From: David Hendricks [mailto:cro_marmot at comcast.net] 
Sent: Wednesday, November 03, 2004 1:54 AM
To: linuxbios at clustermatic.org
Subject: Re: some questions about nForce and LinuxBIOS

I don't think anyone's done an nForce2 port for LinuxBIOS. The nForce4
on the other hand might be different, you would have to ask Dr. Lu @
Tyan about that.

And Ron might have just made bootup time <= 8 seconds for K8s. I'm dying
to try this stuff out on my nForce3 :)

On Wed, 3 Nov 2004 00:52:55 -0800 (PST)
Kory Herzinger <koryherzinger at yahoo.com> wrote:

> 
> I am working on my senior project in college, and have run into a
> slight issue with how long it takes for my BIOS to POST. I would like
> LinuxBIOS to boot my system into a minimal Linux kernel in as little
> amount of time as necessary, and then have that kernel boot into a
> Linux system I've already built and configured on the hard drive. From
> doing some research on your project I've found that this goes by the
> catchy name of LOBOS :-) From the kernel that the LinuxBIOS will boot,
> I don't need network, sound, or video support. I'd like to leave it up
> to the existing Linux installation on my hard drive to bring up these
> devices for me. Here's the specs on the board I am using:
> 
> Northbridge: NForce2 Crush 18G IGP chipset
> Southbridge: MCP chipset / High-speed interface to the MCP
> OnBoard GFX: NVidia GeForce4 MX
> 
> The board has support for TV composite signal-out which I will be
> using once the system is up and running, but since nVidia doesn't
> release specs or source for their hardware, I obviously can't use it
> during the BIOS phase. So I guess the real questions are:
> 
> 1) Is it possible to build a LinuxBIOS that will run on my system?
> 2) If so, since the support for network, sound, and audio devices will
> not be present in the BIOS, can I still bring them up in my Linux
> kernel using the proprietary drivers distributed by nVidia? 3) If the
> above two scenarios are possible, could I throw my linux system
> currently on the hard drive into a NVRAM device and boot it from there
> to further reduce boot time?
> 
> I appreciate your help with this. If you are interested in my senior
> project, there is information on my project website:
> www.novagameconsole.com
> 
> Anything you can offer is greatly appreciated! Thanks!
> 
> 			
> ---------------------------------
> Do you Yahoo!?
>  Check out the new Yahoo! Front Page.  www.yahoo.com/a
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From YhLu at tyan.com  Wed Nov  3 12:54:20 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Nov  3 12:54:20 2004
Subject: i845GV ddr sdram init passed
Message-ID: <3174569B9743D511922F00A0C94314230665BA51@TYANWEB>

send out raminit.inc, I could convert that into freebios2 for you.

I guess raminit.inc is similar to e7501's.

Regards

YH

-----Original Message-----
From: zhu shi song [mailto:zhushisongzhu at yahoo.com] 
Sent: Wednesday, November 03, 2004 3:03 AM
To: linuxbios at clustermatic.org
Subject: i845GV ddr sdram init passed

After working hard for three day, I have made i845gv
ddr sdram work well.  I can boot linux 2.4.27 with
root filesystem on my hard disk.  But linux 2.4.27
support new hardware weakly. So I hope I can boot
linux 2.6.  I have before used initrd dyn invented by
l inux router project to boot linux 2.4.  I like the
way booting linux.
 (1) Who knows can initrd dyn support linux 2.6.  I
know the latest version of initrd dyn is for
linux2.5.54.
 (2) If unfortunately I can't use initrd dyn again,
how can I make my root fs?  how can I boot linux 2.6
using tar.gz file as root filesystem?

  tks
  zhu





		
__________________________________ 
Do you Yahoo!? 
Check out the new Yahoo! Front Page. 
www.yahoo.com 
 

_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From YhLu at tyan.com  Wed Nov  3 12:54:23 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Nov  3 12:54:23 2004
Subject: Etherboot 5.2.5 with gcc 3.4
Message-ID: <3174569B9743D511922F00A0C94314230665BA6E@TYANWEB>

Eric,

When using gcc 3.4 to compile Etherboot 5.2.5, I got

ld  -N -Ttext 0x20000 -T arch/i386/core/etherboot.lds -o bin/tg3.tmp
bin/start32.o bin/pcbios.o bin/memsizes.o bin/basemem.o bin/linuxbios.o
bin/config.o bin/tg3.o bin/bootlib.a 
bin/linuxbios.o(.text+0x337): In function `get_memsizes':
: undefined reference to `memcpy'

Regards

YH


From ebiederman at lnxi.com  Wed Nov  3 13:40:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Nov  3 13:40:01 2004
Subject: Makefile changes for symbols
In-Reply-To: <20041103082832.GD4711@openbios.org>
References: <1098480250.16598.22.camel@exponential.lanl.gov>
	<1098481504.2738.7.camel@localhost.localdomain>
	<Pine.LNX.4.58.0410221617230.16599@linux.site>
	<1098710105.2721.3.camel@localhost.localdomain>
	<Pine.LNX.4.58.0410250850150.25731@linux.site>
	<1098719346.2721.140.camel@localhost.localdomain>
	<Pine.LNX.4.58.0410250958540.25731@linux.site>
	<1098732363.16598.69.camel@exponential.lanl.gov>
	<20041026073904.GA9126@openbios.org> <m3654xvjmv.fsf@maxwell.lnxi.com>
	<20041103082832.GD4711@openbios.org>
Message-ID: <m37jp2itso.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at openbios.org> writes:

> * Eric W. Biederman <ebiederman at lnxi.com> [041026 12:50]:
> > Stefan Reinauer <stepan at openbios.org> writes:
> > > Now that A stepping CPUs start dying out, could we not switch the reset
> > > mechanism to use LDTSTOP instead of a complete reset? 
> > > It's more solid and a lot faster.
> > 
> > Solid?  There are several errata with using LDTSTOP and you can not use it
> after
> 
> > memory is initialized. 
> 
> We don't do this anyways, do we?

Yes.  We avoid it but the generic code is run after memory is initialized.
 
> In situations with marginal timing for RESET#, there is less chance of
> something going wrong. Hardware is rarely perfect, and LDTSTOP# affects
> less of it, so it is a little more robust. 

Possibly.  At the same time reset# must be implemented and work correctly, as reset# is used
to during board power on.  Whereas it is not fatal if LDTSTOP# is implemented incorrectly.

I think you can tweak the calls to reset in the romcc compiled code to use LDTSTOP# on a per
motherboard basis so it may be worth trying to use LDTSTOP#.

Eric


From pyro at linuxlabs.com  Wed Nov  3 14:07:00 2004
From: pyro at linuxlabs.com (Steven James)
Date: Wed Nov  3 14:07:00 2004
Subject: flash_rom on SST49LF004B tips?
In-Reply-To: <20041101200807.A8449@orkney.amd.com>
References: <20041101200807.A8449@orkney.amd.com>
Message-ID: <Pine.LNX.4.58.0411032028470.17125@ucontrol.mobiledns.com>

Greetings,

I'm not familiar with that part, but I know that some flash parts that
support block locking can also 'lock down' a block so that it can only be
unlocked by power cycling. Any chance that's happening?

G'day,
sjames


On Mon, 1 Nov 2004, Donald Zoch wrote:

> I'm trying to get the flash_rom program working on the SST49LF004B.
> This is the part that is coming in our newer Arima HDAMA boards that
> replaces the SST49LF040.   It has the same id as the SST49LF004A,
> but is different in that when we first started trying to flash it, the
> flash looked like it worked but would never verify.   I took a look
> at the data sheet and from the looks of it there are these block locking
> registers that the zero bit must be cleared in in order to write to
> certain parts of the flash.  At least that's why I think it's not
> flashing.
>
> I'm trying to zero out the registers, but it appears as if the first
> 4 cannot be cleared out.   The last 4 look like they're being set to
> zero.   I have tried to calculate the register locations by looking
> at the probe jedec code and seeing that the jedec ID registers are
> at bios and bios + 0x01.  I then looked in the data sheet at where those
> registers appear in the memory map and then calculated the register
> memory locations as offsets to bios, some negative offsets and some
> positive.
>
> I've also tried anding that value with 0xFE just to zero out the bit
> that I need, but that doesn't seem to work.   I can never seem
> to change the values in the first four registers.
>
> Do either of you have any pointers on how to get this to work?
> I will attach the data sheet for the flash part.  It's
> the 49lf004b that I'm interested in.
>
> void unprotect_49lf004b(volatile unsigned char *bios)
>     {
>       *(volatile unsigned char *) (bios + 0x30002) = 0x00;
>       printf("REGISTER HAS VALUE 0x%x AFTER\n",*(volatile unsigned char *)(bios + 0x30002));
>       *(volatile unsigned char *) (bios + 0x20002) = 0x00;
>       printf("REGISTER HAS VALUE 0x%x AFTER\n",*(volatile unsigned char *)(bios + 0x20002));
>       *(volatile unsigned char *) (bios + 0x10002) = 0x00;
>       printf("REGISTER HAS VALUE 0x%x AFTER\n",*(volatile unsigned char *)(bios + 0x10002));
>       *(volatile unsigned char *) (bios + 0x00002) = 0x00;
>       printf("REGISTER HAS VALUE 0x%x AFTER\n",*(volatile unsigned char *)(bios + 0x00002));
>       *(volatile unsigned char *) (bios - 0xFFFE) = 0x00;
>       printf("REGISTER HAS VALUE 0x%x AFTER\n",*(volatile unsigned char *)(bios - 0xFFFE));
>       *(volatile unsigned char *) (bios - 0x1FFFE) = 0x00;
>       printf("REGISTER HAS VALUE 0x%x AFTER\n",*(volatile unsigned char *)(bios - 0x1FFFE));
>       *(volatile unsigned char *) (bios - 0x2FFFE) = 0x00;
>       printf("REGISTER HAS VALUE 0x%x AFTER\n",*(volatile unsigned char *)(bios - 0x2FFFE));
>       *(volatile unsigned char *) (bios - 0x3FFFE) = 0x00;
>       printf("REGISTER HAS VALUE 0x%x AFTER\n",*(volatile unsigned char *)(bios - 0x3FFFE));
> }
>
>
> Donald
> ----
> Donald Zoch
> Phone: (512) 602-7945
> Pager: (512) 604-5401
> donald.zoch at amd.com
>

||||| |||| |||||||||||||  |||
by Linux Labs International, Inc.
   Steven James, CTO

55 Marietta Street
Suite 1830
Atlanta, Ga 30303
866 824 9737 support



From YhLu at tyan.com  Wed Nov  3 14:46:01 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Nov  3 14:46:01 2004
Subject: Merge/Cleanup status
Message-ID: <3174569B9743D511922F00A0C94314230665BA80@TYANWEB>

FYI

With gcc 3.4 linuxbios_rom.rom spare 1400 bytes.

With gcc 3.2.2 in RH9
./nrv2b e linuxbios_ram.bin linuxbios_ram.nrv2b
input/output = 76396/29877 = 2.557
cp linuxbios_ram.nrv2b linuxbios_ram.rom
echo "INCLUDE ldoptions" > ldscript.ld ; for file in
/home/yhlu/xx/xx/freebios2/src/arch/i386/init/ldscript.lb
/home/yhlu/xx/xx/freebios2/src//cpu/x86/16bit/entry16.lds
/home/yhlu/xx/xx/freebios2/src//cpu/x86/32bit/entry32.lds
/home/yhlu/xx/xx/freebios2/src//cpu/x86/16bit/reset16.lds
/home/yhlu/xx/xx/freebios2/src//arch/i386/lib/id.lds
/home/yhlu/xx/xx/freebios2/src//arch/i386/lib/failover.lds ; do echo
"INCLUDE $file" >> ldscript.ld ; done
/usr/bin/gcc -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld
crt0.o 
nm -n linuxbios | sort > linuxbios.map
objcopy -O binary linuxbios linuxbios.strip
/usr/bin/gcc -o buildrom /home/yhlu/xx/xx/freebios2/util/buildrom/buildrom.c
./buildrom linuxbios.strip linuxbios.rom
../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf 0x10000 0x20000
linuxbios image is 66272 bytes; only 65536 allowed
Linuxbios input file larger than allowed size!

With gcc 3.4
./nrv2b e linuxbios_ram.bin linuxbios_ram.nrv2b
input/output = 74572/28488 = 2.618
cp linuxbios_ram.nrv2b linuxbios_ram.rom
gcc -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld crt0.o 
nm -n linuxbios | sort > linuxbios.map
objcopy -O binary linuxbios linuxbios.strip
./buildrom linuxbios.strip linuxbios.rom
../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf 0x10000 0x20000


From ollie at lanl.gov  Wed Nov  3 15:27:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Wed Nov  3 15:27:00 2004
Subject: PCI_DOMAIN ??
Message-ID: <1099518645.3373.99.camel@exponential.lanl.gov>

Eric,

>From my memory of the LXNI visit, the pci_domain represents different 
ways to access PCI CS (0xcf8, 0xcfc). So the very low level of PCI
access method will be different depends on the domain. Now the question
is why not the pci_set_method() a device method of the PCI_DOMAIN
device ? It is in the hardwarmain() now.

Ollie 



From ebiederman at lnxi.com  Wed Nov  3 16:28:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Nov  3 16:28:00 2004
Subject: PCI_DOMAIN ??
In-Reply-To: <1099518645.3373.99.camel@exponential.lanl.gov>
References: <1099518645.3373.99.camel@exponential.lanl.gov>
Message-ID: <m3fz3qk0ln.fsf@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:

> Eric,
> 
> >From my memory of the LXNI visit, the pci_domain represents different 
> ways to access PCI CS (0xcf8, 0xcfc). So the very low level of PCI
> access method will be different depends on the domain. Now the question
> is why not the pci_set_method() a device method of the PCI_DOMAIN
> device ? It is in the hardwarmain() now.

Because no one has done the work :)

The immediate reason for introducing the concept was so that we would not need
to override the root device methods, as chipsets have different requirements
when scanning their busses.

pci_set_method is not something that we really want as a method.  Because
if we know what the hardware is we don't need to auto-detect the method.
Although having scanbus call pci_set_method may not be the worst way
to go.

I suspect what we want is a pci_read/write_config... set of methods
that the code will keep looking to parent busses to provide if
the current bus not provide the operations.

An alternative is to provide pci_read/write_config.... methods that
also take a domain parameter.  And just have the northbridge provide those.

The practical case where something like this comes soon is accessing the
extra configuration bytes from pci-express devices.

So my immediate suggestion would be to call pci_set_method from the pci_domain's
scan_bus method before it does anything.  We can worry about the rest later.

Eric


From ollie at lanl.gov  Wed Nov  3 16:36:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Wed Nov  3 16:36:01 2004
Subject: PCI_DOMAIN ??
In-Reply-To: <m3fz3qk0ln.fsf@maxwell.lnxi.com>
References: <1099518645.3373.99.camel@exponential.lanl.gov>
	 <m3fz3qk0ln.fsf@maxwell.lnxi.com>
Message-ID: <1099522768.3373.106.camel@exponential.lanl.gov>

On Wed, 2004-11-03 at 15:51, Eric W. Biederman wrote:
> So my immediate suggestion would be to call pci_set_method from the pci_domain's
> scan_bus method before it does anything.  We can worry about the rest later.
> 

Isn't the root_dev::scan_bus() called before pci_domain::scan_bus() ? 
What if root_dev::scan_bus() wants to access PCI CS ?

Ollie




From ebiederman at lnxi.com  Wed Nov  3 16:56:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Nov  3 16:56:00 2004
Subject: PCI_DOMAIN ??
In-Reply-To: <1099522768.3373.106.camel@exponential.lanl.gov>
References: <1099518645.3373.99.camel@exponential.lanl.gov>
	<m3fz3qk0ln.fsf@maxwell.lnxi.com>
	<1099522768.3373.106.camel@exponential.lanl.gov>
Message-ID: <m3d5yua5c4.fsf@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:

> On Wed, 2004-11-03 at 15:51, Eric W. Biederman wrote:
> > So my immediate suggestion would be to call pci_set_method from the
> pci_domain's
> 
> > scan_bus method before it does anything.  We can worry about the rest later.
> > 
> 
> Isn't the root_dev::scan_bus() called before pci_domain::scan_bus() ? 
Yes but it uses scan_static_bus()

> What if root_dev::scan_bus() wants to access PCI CS ?

Currently that sounds like a bug.  I am starting to go through the code
now.  If I don't see any problems I will make this change.

Hopefully I can get most of the tree compiling...

Eric


From ollie at lanl.gov  Wed Nov  3 17:12:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Wed Nov  3 17:12:00 2004
Subject: PCI_DOMAIN ??
In-Reply-To: <m3d5yua5c4.fsf@maxwell.lnxi.com>
References: <1099518645.3373.99.camel@exponential.lanl.gov>
	 <m3fz3qk0ln.fsf@maxwell.lnxi.com>
	 <1099522768.3373.106.camel@exponential.lanl.gov>
	 <m3d5yua5c4.fsf@maxwell.lnxi.com>
Message-ID: <1099524915.3373.110.camel@exponential.lanl.gov>

On Wed, 2004-11-03 at 16:19, Eric W. Biederman wrote:
> Li-Ta Lo <ollie at lanl.gov> writes:
> 
> > On Wed, 2004-11-03 at 15:51, Eric W. Biederman wrote:
> > > So my immediate suggestion would be to call pci_set_method from the
> > pci_domain's
> > 
> > > scan_bus method before it does anything.  We can worry about the rest later.
> > > 
> > 
> > Isn't the root_dev::scan_bus() called before pci_domain::scan_bus() ? 
> Yes but it uses scan_static_bus()
> 

But the mainboard::enable_dev() updatea the root_dev::scan_bus(), if I 
am right. So the mainboard::scan_bus() will be called before 
pci_domain::scan_bus().

Ollie




From ebiederman at lnxi.com  Wed Nov  3 18:08:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Nov  3 18:08:01 2004
Subject: PCI_DOMAIN ??
In-Reply-To: <1099524915.3373.110.camel@exponential.lanl.gov>
References: <1099518645.3373.99.camel@exponential.lanl.gov>
	<m3fz3qk0ln.fsf@maxwell.lnxi.com>
	<1099522768.3373.106.camel@exponential.lanl.gov>
	<m3d5yua5c4.fsf@maxwell.lnxi.com>
	<1099524915.3373.110.camel@exponential.lanl.gov>
Message-ID: <m3d5yuzc8c.fsf@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:

> On Wed, 2004-11-03 at 16:19, Eric W. Biederman wrote:
> > Li-Ta Lo <ollie at lanl.gov> writes:
> > 
> > > On Wed, 2004-11-03 at 15:51, Eric W. Biederman wrote:
> > > > So my immediate suggestion would be to call pci_set_method from the
> > > pci_domain's
> > > 
> > > > scan_bus method before it does anything.  We can worry about the rest
> later.
> 
> > > > 
> > > 
> > > Isn't the root_dev::scan_bus() called before pci_domain::scan_bus() ? 
> > Yes but it uses scan_static_bus()
> > 
> 
> But the mainboard::enable_dev() updatea the root_dev::scan_bus(), if I 
> am right. So the mainboard::scan_bus() will be called before 
> pci_domain::scan_bus().

I am not arguing that you cannot arrange a scenario where it cannot
happen.  And an enable_dev method may be a slightly more appropriate place
to set the pci_ops than early in scan_bus.  What I am arguing is that
I believe we have no remaining code that sanely does that.  And that
for the future it can be as simple as saying don't do that then.

The only case I remember leaving code that looked like was in emulation/qemu-i386
and that was because I thought it did not define a northbridge.  Since even that
code defines a northbridge I don't for see any problems.  I am going to examine 
all of the mainboard code though and actually look to see what is going on.

An advantage of doing this is that with just a little work I can not even
compile in support for the unused configuration type which should keep
the code a little smaller.

Eric


From ebiederman at lnxi.com  Wed Nov  3 21:34:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Nov  3 21:34:01 2004
Subject: Technologic ts5300???
Message-ID: <m31xfaqn9t.fsf@maxwell.lnxi.com>

There is the beginnins of a port but there is no sc520 code.
What is the status of this?

With nothing checked into the tree I cannot fix it along with everything else.

Eric





From stepan at openbios.org  Thu Nov  4 02:46:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Thu Nov  4 02:46:01 2004
Subject: Technologic ts5300???
In-Reply-To: <m31xfaqn9t.fsf@maxwell.lnxi.com>
References: <m31xfaqn9t.fsf@maxwell.lnxi.com>
Message-ID: <20041104091012.GA26662@openbios.org>

* Eric W. Biederman <ebiederman at lnxi.com> [041104 04:57]:
> 
> There is the beginnins of a port but there is no sc520 code.
> What is the status of this?
> 
> With nothing checked into the tree I cannot fix it along with everything else.
 
I started the port but was unable to finish it up to now.. :-(

Stefan




From liutao at safe-mail.net  Thu Nov  4 04:06:01 2004
From: liutao at safe-mail.net (Liu Tao)
Date: Thu Nov  4 04:06:01 2004
Subject: Board hangs after soft_reset() in auto.c
Message-ID: <418A050A.4020307@safe-mail.net>

Hello,

My K8 board hangs after "ht reset -" is printed, the post card
at 0x80 is reseted to 0xff, so I think 8111 has performed the
RESET_L and LDTRST_L signal. On my board the LDTRST_L signal
drives to the RESET_L pin of K8 and RESET# pin of 8131, is this
routing OK? Does the RESET_L signal of K8 updates the ht freq/width
during reseting the CPU? Is this a cold/hard reset to CPU?

Regards,
Liu Tao


From ebiederman at lnxi.com  Thu Nov  4 04:19:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Nov  4 04:19:01 2004
Subject: Board hangs after soft_reset() in auto.c
In-Reply-To: <418A050A.4020307@safe-mail.net>
References: <418A050A.4020307@safe-mail.net>
Message-ID: <m33bzpopxr.fsf@maxwell.lnxi.com>

Liu Tao <liutao at safe-mail.net> writes:

> Hello,
> 
> My K8 board hangs after "ht reset -" is printed, the post card
> at 0x80 is reseted to 0xff, so I think 8111 has performed the
> RESET_L and LDTRST_L signal. On my board the LDTRST_L signal
> drives to the RESET_L pin of K8 and RESET# pin of 8131, is this
> routing OK? 

Hmm I don't think LDTRESET#  should drive the cpu's reset# signal.
But I am not certain.

> Does the RESET_L signal of K8 updates the ht freq/width
> during reseting the CPU? 

The ht freq/width are updated earlier and the reset causes the changes
to take effect.

> Is this a cold/hard reset to CPU?
As opposed to a soft reset yes.    The power is expected to remain
on for the duration so ht freq/width can be retained in the chips.

The short answer is that optimizing the hypertransport speed and frequency
is an optimization.  So you can disable the reset and see how far you board
gets otherwise.  That should give you a little more time to debug the reset path.

Eric


From ebiederman at lnxi.com  Thu Nov  4 04:41:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Nov  4 04:41:01 2004
Subject: Technologic ts5300???
In-Reply-To: <20041104091012.GA26662@openbios.org>
References: <m31xfaqn9t.fsf@maxwell.lnxi.com>
	<20041104091012.GA26662@openbios.org>
Message-ID: <m3y8hhnad9.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at openbios.org> writes:

> * Eric W. Biederman <ebiederman at lnxi.com> [041104 04:57]:
> > 
> > There is the beginnins of a port but there is no sc520 code.
> > What is the status of this?
> > 
> > With nothing checked into the tree I cannot fix it along with everything else.
> 
>  
> I started the port but was unable to finish it up to now.. :-(

Ok that explains it.   Do you have enough northbridge/southbridge code that it even builds for you?

Eric


From ebiederman at lnxi.com  Thu Nov  4 04:53:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Nov  4 04:53:01 2004
Subject: Build fixes....
Message-ID: <m3u0s5n9ta.fsf@maxwell.lnxi.com>

I have been working on getting all of the working ports in
the tree to build.  Of particular interest is that the mainboard/via/epia builds.

The exceptions are currently:
- i855pm as it's raminit.c is still 1/2 in assembly.
- The via epia-m as it's southbridge code needs to converted so it will run.
- The ppc ports as I am still building a cross compiler and have not had a chance
  to test it yet.
- Whatever I fat fingered at the last minute before I decided to call it quits.

Cross compiler currently works in LinuxBIOS (we routinely use it on amd64)
so I don't expect problems compile testing the ppc code, as soon as I have
built a cross compiler.

Our dependency information is currently atrocious.  Ideally abuild would allow
the dependencies to prevent us from rebuilding any port that has built successfully
when none of it's dependencies have changed.  Unfortunately we don't generate
those properly, and abuild.sh is not quite smart enough yet to take advantage of
dependencies even if we properly generated them.  This is something to put
on the wishlist.

Anyway my checking comments are below.
Hopefully I have not gotten too spacey and missed something important.

Eric

- Update abuild.sh so it will rebuild successfull builds
- Move pci_set_method out of hardwaremain.c
- Re-add debugging name field but only include the CONFIG_CHIP_NAME is
  enabled.  All instances are now wrapped in CHIP_NAME
- Many minor cleanups so most ports build.
- Implemented failover.c on many ports where it was previously a stub.
CVS: ----------------------------------------------------------------------
CVS: Enter Log.  Lines beginning with `CVS:' are removed automatically
CVS: 
CVS: Committing in .
CVS: 
CVS: Modified Files:
CVS: 	documentation/LinuxBIOS-AMD64.tex src/arch/i386/lib/Config.lb 
CVS: 	src/arch/i386/lib/pci_ops.c src/boot/hardwaremain.c 
CVS: 	src/config/Config.lb src/config/Options.lb 
CVS: 	src/cpu/amd/socket_754/socket_754.c 
CVS: 	src/cpu/amd/socket_940/socket_940.c 
CVS: 	src/cpu/intel/slot_2/slot_2.c 
CVS: 	src/cpu/intel/socket_mPGA479M/socket_mPGA479M.c 
CVS: 	src/cpu/intel/socket_mPGA603/socket_mPGA603_400Mhz.c 
CVS: 	src/cpu/intel/socket_mPGA604_533Mhz/socket_mPGA604_533Mhz.c 
CVS: 	src/cpu/intel/socket_mPGA604_800Mhz/socket_mPGA604_800Mhz.c 
CVS: 	src/include/device/device.h src/include/device/pci_ops.h 
CVS: 	src/mainboard/Iwill/DK8S2/Config.lb 
CVS: 	src/mainboard/Iwill/DK8S2/auto.c 
CVS: 	src/mainboard/Iwill/DK8S2/chip.h 
CVS: 	src/mainboard/Iwill/DK8S2/cmos.layout 
CVS: 	src/mainboard/Iwill/DK8S2/mainboard.c 
CVS: 	src/mainboard/Iwill/DK8S2/mptable.c 
CVS: 	src/mainboard/Iwill/DK8X/Config.lb 
CVS: 	src/mainboard/Iwill/DK8X/auto.c 
CVS: 	src/mainboard/Iwill/DK8X/chip.h 
CVS: 	src/mainboard/Iwill/DK8X/cmos.layout 
CVS: 	src/mainboard/Iwill/DK8X/mainboard.c 
CVS: 	src/mainboard/Iwill/DK8X/mptable.c 
CVS: 	src/mainboard/amd/quartet/Config.lb 
CVS: 	src/mainboard/amd/quartet/auto.c 
CVS: 	src/mainboard/amd/quartet/chip.h 
CVS: 	src/mainboard/amd/quartet/mainboard.c 
CVS: 	src/mainboard/amd/quartet/mptable.c 
CVS: 	src/mainboard/amd/serenade/Config.lb 
CVS: 	src/mainboard/amd/serenade/auto.c 
CVS: 	src/mainboard/amd/serenade/chip.h 
CVS: 	src/mainboard/amd/serenade/mainboard.c 
CVS: 	src/mainboard/amd/serenade/mptable.c 
CVS: 	src/mainboard/amd/solo/Config.lb 
CVS: 	src/mainboard/amd/solo/mainboard.c 
CVS: 	src/mainboard/arima/hdama/Config.lb 
CVS: 	src/mainboard/arima/hdama/auto.c 
CVS: 	src/mainboard/arima/hdama/cmos.layout 
CVS: 	src/mainboard/arima/hdama/mainboard.c 
CVS: 	src/mainboard/densitron/dpx114/Config.lb 
CVS: 	src/mainboard/densitron/dpx114/auto.c 
CVS: 	src/mainboard/densitron/dpx114/chip.h 
CVS: 	src/mainboard/densitron/dpx114/failover.c 
CVS: 	src/mainboard/densitron/dpx114/mainboard.c 
CVS: 	src/mainboard/digitallogic/adl855pc/Config.lb 
CVS: 	src/mainboard/digitallogic/adl855pc/auto.c 
CVS: 	src/mainboard/digitallogic/adl855pc/chip.h 
CVS: 	src/mainboard/digitallogic/adl855pc/failover.c 
CVS: 	src/mainboard/digitallogic/adl855pc/mainboard.c 
CVS: 	src/mainboard/emulation/qemu-i386/auto.c 
CVS: 	src/mainboard/emulation/qemu-i386/mainboard.c 
CVS: 	src/mainboard/ibm/e325/Config.lb 
CVS: 	src/mainboard/ibm/e325/Options.lb 
CVS: 	src/mainboard/ibm/e325/auto.c src/mainboard/ibm/e325/chip.h 
CVS: 	src/mainboard/ibm/e325/mainboard.c 
CVS: 	src/mainboard/ibm/e325/mptable.c 
CVS: 	src/mainboard/newisys/khepri/Config.lb 
CVS: 	src/mainboard/newisys/khepri/auto.c 
CVS: 	src/mainboard/newisys/khepri/chip.h 
CVS: 	src/mainboard/newisys/khepri/mainboard.c 
CVS: 	src/mainboard/newisys/khepri/mptable.c 
CVS: 	src/mainboard/technologic/ts5300/Config.lb 
CVS: 	src/mainboard/technologic/ts5300/mainboard.c 
CVS: 	src/mainboard/tyan/s2735/mainboard.c 
CVS: 	src/mainboard/tyan/s2850/mainboard.c 
CVS: 	src/mainboard/tyan/s2880/mainboard.c 
CVS: 	src/mainboard/tyan/s2881/mainboard.c 
CVS: 	src/mainboard/tyan/s2882/auto.c 
CVS: 	src/mainboard/tyan/s2882/mainboard.c 
CVS: 	src/mainboard/tyan/s2885/mainboard.c 
CVS: 	src/mainboard/tyan/s4880/auto.c 
CVS: 	src/mainboard/tyan/s4880/mainboard.c 
CVS: 	src/mainboard/tyan/s4882/mainboard.c 
CVS: 	src/mainboard/via/epia/Config.lb src/mainboard/via/epia/auto.c 
CVS: 	src/mainboard/via/epia/failover.c 
CVS: 	src/mainboard/via/epia/mainboard.c 
CVS: 	src/mainboard/via/epia-m/Config.lb 
CVS: 	src/mainboard/via/epia-m/auto.c 
CVS: 	src/mainboard/via/epia-m/chip.h 
CVS: 	src/mainboard/via/epia-m/failover.c 
CVS: 	src/mainboard/via/epia-m/mainboard.c 
CVS: 	src/northbridge/amd/amdk8/northbridge.c 
CVS: 	src/northbridge/emulation/qemu-i386/northbridge.c 
CVS: 	src/northbridge/intel/e7501/northbridge.c 
CVS: 	src/northbridge/intel/i855pm/northbridge.c 
CVS: 	src/northbridge/intel/i855pm/raminit.c 
CVS: 	src/northbridge/transmeta/tm5800/northbridge.c 
CVS: 	src/northbridge/via/vt8601/northbridge.c 
CVS: 	src/northbridge/via/vt8623/northbridge.c 
CVS: 	src/northbridge/via/vt8623/raminit.c 
CVS: 	src/southbridge/amd/amd8111/amd8111.c 
CVS: 	src/southbridge/intel/i82801dbm/i82801dbm.c 
CVS: 	src/southbridge/intel/i82801er/i82801er.c 
CVS: 	src/southbridge/ricoh/rl5c476/rl5c476.c 
CVS: 	src/southbridge/via/vt8231/vt8231.c 
CVS: 	src/southbridge/via/vt8235/vt8235.c 
CVS: 	src/superio/NSC/pc87360/superio.c 
CVS: 	src/superio/NSC/pc87366/chip.h 
CVS: 	src/superio/NSC/pc87366/superio.c 
CVS: 	src/superio/NSC/pc97307/superio.c 
CVS: 	src/superio/via/vt1211/vt1211.c 
CVS: 	src/superio/winbond/w83627hf/superio.c 
CVS: 	src/superio/winbond/w83627hf/w83627hf.h 
CVS: 	src/superio/winbond/w83627hf/w83627hf_early_serial.c 
CVS: 	src/superio/winbond/w83627thf/chip.h 
CVS: 	src/superio/winbond/w83627thf/superio.c util/abuild/abuild.sh 
CVS: Added Files:
CVS: 	src/arch/i386/include/arch/pci_ops.h 
CVS: 	src/arch/i386/lib/pci_ops_auto.c 
CVS: 	src/arch/i386/lib/pci_ops_conf1.c 
CVS: 	src/arch/i386/lib/pci_ops_conf2.c 
CVS: 	src/arch/ppc/include/arch/pci_ops.h 
CVS:    src/mainboard/Iwill/DK8S2/Options.lb
CVS:    src/mainboard/Iwill/DK8X/Options.lb
CVS:    src/mainboard/densitron/dpx114/Options.lb
CVS:    src/mainboard/digitallogic/adl855pc/Options.lb
CVS:    src/mainboard/via/epia-m/Options.lb
CVS: ----------------------------------------------------------------------


From rminnich at lanl.gov  Thu Nov  4 09:23:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Thu Nov  4 09:23:00 2004
Subject: Technologic ts5300???
In-Reply-To: <m31xfaqn9t.fsf@maxwell.lnxi.com>
References: <m31xfaqn9t.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.58.0411040846280.1002@linux.site>


On Wed, 3 Nov 2004, Eric W. Biederman wrote:

> 
> There is the beginnins of a port but there is no sc520 code.
> What is the status of this?

It got stuck, don't worry about this. The flash was soldered-on and I've 
decided to do the port with a digital logic card instead (this one does 
have removable flash).

ron


From rminnich at lanl.gov  Thu Nov  4 09:29:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Thu Nov  4 09:29:01 2004
Subject: Technologic ts5300???
In-Reply-To: <20041104091012.GA26662@openbios.org>
References: <m31xfaqn9t.fsf@maxwell.lnxi.com> <20041104091012.GA26662@openbios.org>
Message-ID: <Pine.LNX.4.58.0411040853080.1002@linux.site>


On Thu, 4 Nov 2004, Stefan Reinauer wrote:

> I started the port but was unable to finish it up to now.. :-(

guess stefan and I were both trying.

ron


From rminnich at lanl.gov  Thu Nov  4 09:31:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Thu Nov  4 09:31:01 2004
Subject: Technologic ts5300???
In-Reply-To: <m3y8hhnad9.fsf@maxwell.lnxi.com>
References: <m31xfaqn9t.fsf@maxwell.lnxi.com> <20041104091012.GA26662@openbios.org>
 <m3y8hhnad9.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.58.0411040853470.1002@linux.site>


On Thu, 4 Nov 2004, Eric W. Biederman wrote:

> Ok that explains it.  Do you have enough northbridge/southbridge code
> that it even builds for you?

stefan and I had talked on this one and were probably not going to do a 
seperate north/south as they are all so tightly integrated on this chip. 
It was a bit of an experiment. 

That's my memory anyway.

ron


From ollie at lanl.gov  Thu Nov  4 10:17:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Nov  4 10:17:01 2004
Subject: PCI_DOMAIN ??
In-Reply-To: <m3d5yuzc8c.fsf@maxwell.lnxi.com>
References: <1099518645.3373.99.camel@exponential.lanl.gov>
	 <m3fz3qk0ln.fsf@maxwell.lnxi.com>
	 <1099522768.3373.106.camel@exponential.lanl.gov>
	 <m3d5yua5c4.fsf@maxwell.lnxi.com>
	 <1099524915.3373.110.camel@exponential.lanl.gov>
	 <m3d5yuzc8c.fsf@maxwell.lnxi.com>
Message-ID: <1099586422.3373.124.camel@exponential.lanl.gov>

On Wed, 2004-11-03 at 17:31, Eric W. Biederman wrote:
> Li-Ta Lo <ollie at lanl.gov> writes:
> 
> > On Wed, 2004-11-03 at 16:19, Eric W. Biederman wrote:
> > > Li-Ta Lo <ollie at lanl.gov> writes:
> > > 
> > > > On Wed, 2004-11-03 at 15:51, Eric W. Biederman wrote:
> > > > > So my immediate suggestion would be to call pci_set_method from the
> > > > pci_domain's
> > > > 
> > > > > scan_bus method before it does anything.  We can worry about the rest
> > later.
> > 
> > > > > 
> > > > 
> > > > Isn't the root_dev::scan_bus() called before pci_domain::scan_bus() ? 
> > > Yes but it uses scan_static_bus()
> > > 
> > 
> > But the mainboard::enable_dev() updatea the root_dev::scan_bus(), if I 
> > am right. So the mainboard::scan_bus() will be called before 
> > pci_domain::scan_bus().
> 
> I am not arguing that you cannot arrange a scenario where it cannot
> happen.  And an enable_dev method may be a slightly more appropriate place
> to set the pci_ops than early in scan_bus.  What I am arguing is that
> I believe we have no remaining code that sanely does that.  And that
> for the future it can be as simple as saying don't do that then.
> 

Hmm. you removed all mainboard:enable_dev(). Now there are much few 
code.

Ollie




From ollie at lanl.gov  Thu Nov  4 10:44:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Nov  4 10:44:00 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
Message-ID: <1099588036.3373.127.camel@exponential.lanl.gov>

YhLu,

Now we have a totally new device driver architecture, could we remove 
those #if 0 #endf code in the mainboard.c for Tyan board?

Ollie




From rminnich at lanl.gov  Thu Nov  4 10:48:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Thu Nov  4 10:48:00 2004
Subject: PCI_DOMAIN ??
In-Reply-To: <1099586422.3373.124.camel@exponential.lanl.gov>
References: <1099518645.3373.99.camel@exponential.lanl.gov> 
 <m3fz3qk0ln.fsf@maxwell.lnxi.com>  <1099522768.3373.106.camel@exponential.lanl.gov>
  <m3d5yua5c4.fsf@maxwell.lnxi.com>  <1099524915.3373.110.camel@exponential.lanl.gov>
  <m3d5yuzc8c.fsf@maxwell.lnxi.com> <1099586422.3373.124.camel@exponential.lanl.gov>
Message-ID: <Pine.LNX.4.58.0411041010400.1147@linux.site>


On Thu, 4 Nov 2004, Li-Ta Lo wrote:

> Hmm. you removed all mainboard:enable_dev(). Now there are much few 
> code.

Ollie, I'm hoping you are saying this is good.  :-)

I'm pretty happy about all the code-ectomy that the changes have allowed 
...

ron


From ginlin at mail.nexcom.com.tw  Thu Nov  4 11:15:00 2004
From: ginlin at mail.nexcom.com.tw (Gin Lin)
Date: Thu Nov  4 11:15:00 2004
Subject: ram init
Message-ID: <20041104173157.M6580@mail.nexcom.com.tw>

Does anyone know if the raminit.c under intel/E7501 is stable enough? I am 
having a problem with the system reseting when it jumps to the first address 
in the ram. Could the procedures of writing NorthBrige registers have 
problems?

thanks,
Gin  


From YhLu at tyan.com  Thu Nov  4 12:40:01 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Nov  4 12:40:01 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
Message-ID: <3174569B9743D511922F00A0C943142306BA2C63@TYANWEB>

OK for me.

Some line I want to use print mem or pci at the end of LinuxBIOS can not be
used now. Eric removed the CHIP_PASS....

Regards

YH

-----Original Message-----
From: Li-Ta Lo [mailto:ollie at lanl.gov] 
Sent: Thursday, November 04, 2004 9:07 AM
To: YhLu; LinuxBIOS
Subject: Removing device driver code in mainboard.c for Tyan boards?

YhLu,

Now we have a totally new device driver architecture, could we remove 
those #if 0 #endf code in the mainboard.c for Tyan board?

Ollie



From ebiederman at lnxi.com  Thu Nov  4 12:55:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Nov  4 12:55:01 2004
Subject: PCI_DOMAIN ??
In-Reply-To: <Pine.LNX.4.58.0411041010400.1147@linux.site>
References: <1099518645.3373.99.camel@exponential.lanl.gov>
	<m3fz3qk0ln.fsf@maxwell.lnxi.com>
	<1099522768.3373.106.camel@exponential.lanl.gov>
	<m3d5yua5c4.fsf@maxwell.lnxi.com>
	<1099524915.3373.110.camel@exponential.lanl.gov>
	<m3d5yuzc8c.fsf@maxwell.lnxi.com>
	<1099586422.3373.124.camel@exponential.lanl.gov>
	<Pine.LNX.4.58.0411041010400.1147@linux.site>
Message-ID: <m3y8hh5sok.fsf@maxwell.lnxi.com>

"Ronald G. Minnich" <rminnich at lanl.gov> writes:

> On Thu, 4 Nov 2004, Li-Ta Lo wrote:
> 
> > Hmm. you removed all mainboard:enable_dev(). Now there are much few 
> > code.
> 
> Ollie, I'm hoping you are saying this is good.  :-)
> 
> I'm pretty happy about all the code-ectomy that the changes have allowed 
> ...

I wasn't going to do it on the HDAMA but when I noticed how many ports
had copied my debugging code I figured I needed a good example.

The northbridge code was almost equally simplified.  For the pci_domains
I have been able to describe all of their resources subtractively  Which
means all of the heavy lifting and resource assignment is done elsewhere.
And more importantly for the K8. It allows all of the bridge resources to
be assigned independently.

Eric


From ebiederman at lnxi.com  Thu Nov  4 12:58:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Nov  4 12:58:00 2004
Subject: Technologic ts5300???
In-Reply-To: <Pine.LNX.4.58.0411040853470.1002@linux.site>
References: <m31xfaqn9t.fsf@maxwell.lnxi.com>
	<20041104091012.GA26662@openbios.org>
	<m3y8hhnad9.fsf@maxwell.lnxi.com>
	<Pine.LNX.4.58.0411040853470.1002@linux.site>
Message-ID: <m3u0s55sjp.fsf@maxwell.lnxi.com>

"Ronald G. Minnich" <rminnich at lanl.gov> writes:

> On Thu, 4 Nov 2004, Eric W. Biederman wrote:
> 
> > Ok that explains it.  Do you have enough northbridge/southbridge code
> > that it even builds for you?
> 
> stefan and I had talked on this one and were probably not going to do a 
> seperate north/south as they are all so tightly integrated on this chip. 
> It was a bit of an experiment. 
> 
> That's my memory anyway.

Sounds sane.  

In any case we need to start running abuild regularly.
We need to have a way of dealing with ports that we are totally broken
in the tree.

Eric


From ollie at lanl.gov  Thu Nov  4 13:46:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Nov  4 13:46:01 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
In-Reply-To: <3174569B9743D511922F00A0C943142306BA2C63@TYANWEB>
References: <3174569B9743D511922F00A0C943142306BA2C63@TYANWEB>
Message-ID: <1099598702.3373.129.camel@exponential.lanl.gov>

On Thu, 2004-11-04 at 10:45, YhLu wrote:
> OK for me.
> 
> Some line I want to use print mem or pci at the end of LinuxBIOS can not be
> used now. Eric removed the CHIP_PASS....
> 

I guess we don't need the driver/intel|si||adaptec|boradcom anymore ?

Ollie

> Regards
> 
> YH
> 
> -----Original Message-----
> From: Li-Ta Lo [mailto:ollie at lanl.gov] 
> Sent: Thursday, November 04, 2004 9:07 AM
> To: YhLu; LinuxBIOS
> Subject: Removing device driver code in mainboard.c for Tyan boards?
> 
> YhLu,
> 
> Now we have a totally new device driver architecture, could we remove 
> those #if 0 #endf code in the mainboard.c for Tyan board?
> 
> Ollie
> 



From ollie at lanl.gov  Thu Nov  4 13:52:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Nov  4 13:52:00 2004
Subject: PCI_DOMAIN ??
In-Reply-To: <m3y8hh5sok.fsf@maxwell.lnxi.com>
References: <1099518645.3373.99.camel@exponential.lanl.gov>
	 <m3fz3qk0ln.fsf@maxwell.lnxi.com>
	 <1099522768.3373.106.camel@exponential.lanl.gov>
	 <m3d5yua5c4.fsf@maxwell.lnxi.com>
	 <1099524915.3373.110.camel@exponential.lanl.gov>
	 <m3d5yuzc8c.fsf@maxwell.lnxi.com>
	 <1099586422.3373.124.camel@exponential.lanl.gov>
	 <Pine.LNX.4.58.0411041010400.1147@linux.site>
	 <m3y8hh5sok.fsf@maxwell.lnxi.com>
Message-ID: <1099599337.3373.131.camel@exponential.lanl.gov>

On Thu, 2004-11-04 at 12:18, Eric W. Biederman wrote:
> "Ronald G. Minnich" <rminnich at lanl.gov> writes:
> 
> > On Thu, 4 Nov 2004, Li-Ta Lo wrote:
> > 
> > > Hmm. you removed all mainboard:enable_dev(). Now there are much few 
> > > code.
> > 
> > Ollie, I'm hoping you are saying this is good.  :-)
> > 
> > I'm pretty happy about all the code-ectomy that the changes have allowed 
> > ...
> 
> I wasn't going to do it on the HDAMA but when I noticed how many ports
> had copied my debugging code I figured I needed a good example.
> 
> The northbridge code was almost equally simplified.  For the pci_domains
> I have been able to describe all of their resources subtractively  Which
> means all of the heavy lifting and resource assignment is done elsewhere.
> And more importantly for the K8. It allows all of the bridge resources to
> be assigned independently.
> 

For some reason you didn't convert the tyan/s2875/mainboard.c. Did you
just miss it? 

Ollie

> Eric
> 



From rminnich at lanl.gov  Thu Nov  4 14:03:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Thu Nov  4 14:03:01 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
In-Reply-To: <3174569B9743D511922F00A0C943142306BA2C63@TYANWEB>
References: <3174569B9743D511922F00A0C943142306BA2C63@TYANWEB>
Message-ID: <Pine.LNX.4.58.0411041326350.1147@linux.site>


On Thu, 4 Nov 2004, YhLu wrote:

> Some line I want to use print mem or pci at the end of LinuxBIOS can not be
> used now. Eric removed the CHIP_PASS....

it was no longer needed I think.

ron


From YhLu at tyan.com  Thu Nov  4 14:08:01 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Nov  4 14:08:01 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
Message-ID: <3174569B9743D511922F00A0C943142306BA2C96@TYANWEB>

Yes, We still need some, I will give a example about SI image chip.

Regards

YH

-----Original Message-----
From: Li-Ta Lo [mailto:ollie at lanl.gov] 
Sent: Thursday, November 04, 2004 12:05 PM
To: YhLu
Cc: LinuxBIOS
Subject: RE: Removing device driver code in mainboard.c for Tyan boards?

On Thu, 2004-11-04 at 10:45, YhLu wrote:
> OK for me.
> 
> Some line I want to use print mem or pci at the end of LinuxBIOS can not
be
> used now. Eric removed the CHIP_PASS....
> 

I guess we don't need the driver/intel|si||adaptec|boradcom anymore ?

Ollie

> Regards
> 
> YH
> 
> -----Original Message-----
> From: Li-Ta Lo [mailto:ollie at lanl.gov] 
> Sent: Thursday, November 04, 2004 9:07 AM
> To: YhLu; LinuxBIOS
> Subject: Removing device driver code in mainboard.c for Tyan boards?
> 
> YhLu,
> 
> Now we have a totally new device driver architecture, could we remove 
> those #if 0 #endf code in the mainboard.c for Tyan board?
> 
> Ollie
> 


From YhLu at tyan.com  Thu Nov  4 14:09:00 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Nov  4 14:09:00 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
Message-ID: <3174569B9743D511922F00A0C943142306BA2C98@TYANWEB>

Actually, Eric another link to dev_root and it's init will be called after
all under dev_root link0.

Regards

YH

-----Original Message-----
From: Ronald G. Minnich [mailto:rminnich at lanl.gov] 
Sent: Thursday, November 04, 2004 12:27 PM
To: YhLu
Cc: Li-Ta Lo; LinuxBIOS
Subject: RE: Removing device driver code in mainboard.c for Tyan boards?



On Thu, 4 Nov 2004, YhLu wrote:

> Some line I want to use print mem or pci at the end of LinuxBIOS can not
be
> used now. Eric removed the CHIP_PASS....

it was no longer needed I think.

ron


From YhLu at tyan.com  Thu Nov  4 14:39:00 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Nov  4 14:39:00 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
Message-ID: <3174569B9743D511922F00A0C943142306BA2C9D@TYANWEB>

Please check the si/3114

I guess you need to keep
Ati
Si
Trident

Regards

YH

-----Original Message-----
From: YhLu 
Sent: Thursday, November 04, 2004 12:37 PM
To: Li-Ta Lo
Cc: LinuxBIOS
Subject: RE: Removing device driver code in mainboard.c for Tyan boards?

Yes, We still need some, I will give a example about SI image chip.

Regards

YH

-----Original Message-----
From: Li-Ta Lo [mailto:ollie at lanl.gov] 
Sent: Thursday, November 04, 2004 12:05 PM
To: YhLu
Cc: LinuxBIOS
Subject: RE: Removing device driver code in mainboard.c for Tyan boards?

On Thu, 2004-11-04 at 10:45, YhLu wrote:
> OK for me.
> 
> Some line I want to use print mem or pci at the end of LinuxBIOS can not
be
> used now. Eric removed the CHIP_PASS....
> 

I guess we don't need the driver/intel|si||adaptec|boradcom anymore ?

Ollie

> Regards
> 
> YH
> 
> -----Original Message-----
> From: Li-Ta Lo [mailto:ollie at lanl.gov] 
> Sent: Thursday, November 04, 2004 9:07 AM
> To: YhLu; LinuxBIOS
> Subject: Removing device driver code in mainboard.c for Tyan boards?
> 
> YhLu,
> 
> Now we have a totally new device driver architecture, could we remove 
> those #if 0 #endf code in the mainboard.c for Tyan board?
> 
> Ollie
> 
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From ollie at lanl.gov  Thu Nov  4 14:47:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Nov  4 14:47:01 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
In-Reply-To: <3174569B9743D511922F00A0C943142306BA2C9D@TYANWEB>
References: <3174569B9743D511922F00A0C943142306BA2C9D@TYANWEB>
Message-ID: <1099602647.3373.135.camel@exponential.lanl.gov>

On Thu, 2004-11-04 at 14:08, YhLu wrote:
> Please check the si/3114
> 
> I guess you need to keep
> Ati
> Si
> Trident
> 


Why you put the debug_device back ?

Ollie




From YhLu at tyan.com  Thu Nov  4 14:48:00 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Nov  4 14:48:00 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
Message-ID: <3174569B9743D511922F00A0C943142306BA2C9E@TYANWEB>

It is disabled via DEBUG.

YH

-----Original Message-----
From: Li-Ta Lo [mailto:ollie at lanl.gov] 
Sent: Thursday, November 04, 2004 1:11 PM
To: YhLu
Cc: LinuxBIOS
Subject: RE: Removing device driver code in mainboard.c for Tyan boards?

On Thu, 2004-11-04 at 14:08, YhLu wrote:
> Please check the si/3114
> 
> I guess you need to keep
> Ati
> Si
> Trident
> 


Why you put the debug_device back ?

Ollie



From ollie at lanl.gov  Thu Nov  4 14:49:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Nov  4 14:49:00 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
In-Reply-To: <3174569B9743D511922F00A0C943142306BA2C9E@TYANWEB>
References: <3174569B9743D511922F00A0C943142306BA2C9E@TYANWEB>
Message-ID: <1099602792.3373.137.camel@exponential.lanl.gov>

On Thu, 2004-11-04 at 14:17, YhLu wrote:
> It is disabled via DEBUG.
> 

I know. But why you need a virtual debug_device? Just to dump the
PCI CS registers ?

Ollie

> YH
> 
> -----Original Message-----
> From: Li-Ta Lo [mailto:ollie at lanl.gov] 
> Sent: Thursday, November 04, 2004 1:11 PM
> To: YhLu
> Cc: LinuxBIOS
> Subject: RE: Removing device driver code in mainboard.c for Tyan boards?
> 
> On Thu, 2004-11-04 at 14:08, YhLu wrote:
> > Please check the si/3114
> > 
> > I guess you need to keep
> > Ati
> > Si
> > Trident
> > 
> 
> 
> Why you put the debug_device back ?
> 
> Ollie
> 



From YhLu at tyan.com  Thu Nov  4 14:53:00 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Nov  4 14:53:00 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
Message-ID: <3174569B9743D511922F00A0C943142306BA2CA1@TYANWEB>

I want to print PCI regs after PCI device initialization.

Where need to put the calling print_pci_regs_all? In hardwaremain ???

YH

-----Original Message-----
From: Li-Ta Lo [mailto:ollie at lanl.gov] 
Sent: Thursday, November 04, 2004 1:13 PM
To: YhLu
Cc: LinuxBIOS
Subject: RE: Removing device driver code in mainboard.c for Tyan boards?

On Thu, 2004-11-04 at 14:17, YhLu wrote:
> It is disabled via DEBUG.
> 

I know. But why you need a virtual debug_device? Just to dump the
PCI CS registers ?

Ollie

> YH
> 
> -----Original Message-----
> From: Li-Ta Lo [mailto:ollie at lanl.gov] 
> Sent: Thursday, November 04, 2004 1:11 PM
> To: YhLu
> Cc: LinuxBIOS
> Subject: RE: Removing device driver code in mainboard.c for Tyan boards?
> 
> On Thu, 2004-11-04 at 14:08, YhLu wrote:
> > Please check the si/3114
> > 
> > I guess you need to keep
> > Ati
> > Si
> > Trident
> > 
> 
> 
> Why you put the debug_device back ?
> 
> Ollie
> 


From ollie at lanl.gov  Thu Nov  4 15:11:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Nov  4 15:11:01 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
In-Reply-To: <3174569B9743D511922F00A0C943142306BA2CA1@TYANWEB>
References: <3174569B9743D511922F00A0C943142306BA2CA1@TYANWEB>
Message-ID: <1099604107.3373.144.camel@exponential.lanl.gov>

On Thu, 2004-11-04 at 14:22, YhLu wrote:
> I want to print PCI regs after PCI device initialization.
> 
> Where need to put the calling print_pci_regs_all? In hardwaremain ???
> 

Why don't you put the debug device into device/generic/debug ?
And in the mainboard Config.lb you added

	chip device/generic/debug

as the last chip. The device emuleration will call the methods
of the debug device last. And you probably can dump PCI CS registers
in different stages of the enumeration.

Ollie




From ollie at lanl.gov  Thu Nov  4 15:18:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Nov  4 15:18:00 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
In-Reply-To: <3174569B9743D511922F00A0C943142306BA2C9D@TYANWEB>
References: <3174569B9743D511922F00A0C943142306BA2C9D@TYANWEB>
Message-ID: <1099602319.3373.133.camel@exponential.lanl.gov>

On Thu, 2004-11-04 at 14:08, YhLu wrote:
> Please check the si/3114
> 
> I guess you need to keep
> Ati
> Si
> Trident
> 

The si_sata.c only enable the BM DMA. Are you going to do something
more ?

Ollie




From YhLu at tyan.com  Thu Nov  4 15:23:00 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Nov  4 15:23:00 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
Message-ID: <3174569B9743D511922F00A0C943142306BA2CA8@TYANWEB>

Please get new one from CVS tree.

It checks the device class code.

YH

-----Original Message-----
From: Li-Ta Lo [mailto:ollie at lanl.gov] 
Sent: Thursday, November 04, 2004 1:05 PM
To: YhLu
Cc: LinuxBIOS
Subject: RE: Removing device driver code in mainboard.c for Tyan boards?

On Thu, 2004-11-04 at 14:08, YhLu wrote:
> Please check the si/3114
> 
> I guess you need to keep
> Ati
> Si
> Trident
> 

The si_sata.c only enable the BM DMA. Are you going to do something
more ?

Ollie



From ollie at lanl.gov  Thu Nov  4 15:26:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Nov  4 15:26:01 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
In-Reply-To: <3174569B9743D511922F00A0C943142306BA2CA8@TYANWEB>
References: <3174569B9743D511922F00A0C943142306BA2CA8@TYANWEB>
Message-ID: <1099605009.3373.146.camel@exponential.lanl.gov>

On Thu, 2004-11-04 at 14:52, YhLu wrote:
> Please get new one from CVS tree.
> 
> It checks the device class code.
> 
> YH

I saw that.

Ollie

> 
> -----Original Message-----
> From: Li-Ta Lo [mailto:ollie at lanl.gov] 
> Sent: Thursday, November 04, 2004 1:05 PM
> To: YhLu
> Cc: LinuxBIOS
> Subject: RE: Removing device driver code in mainboard.c for Tyan boards?
> 
> On Thu, 2004-11-04 at 14:08, YhLu wrote:
> > Please check the si/3114
> > 
> > I guess you need to keep
> > Ati
> > Si
> > Trident
> > 
> 
> The si_sata.c only enable the BM DMA. Are you going to do something
> more ?
> 
> Ollie
> 



From YhLu at tyan.com  Thu Nov  4 16:15:01 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Nov  4 16:15:01 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
Message-ID: <3174569B9743D511922F00A0C943142306BA2CB4@TYANWEB>

debug device added

        chip drivers/generic/debug
                device  pnp 0.0 on end
        end

debug device will be sibling to PCI_DOMAIN and APIC_CLUSTER...

YH

CVS: ----------------------------------------------------------------------
CVS: Enter Log.  Lines beginning with `CVS:' are removed automatically
CVS:
CVS: Committing in .
CVS:
CVS: Modified Files:
CVS:    src/mainboard/tyan/s2735/mainboard.c
CVS:    src/mainboard/tyan/s2850/mainboard.c
CVS:    src/mainboard/tyan/s2875/mainboard.c
CVS:    src/mainboard/tyan/s2880/mainboard.c
CVS:    src/mainboard/tyan/s2881/mainboard.c
CVS:    src/mainboard/tyan/s2882/mainboard.c
CVS:    src/mainboard/tyan/s2885/Config.lb
CVS:    src/mainboard/tyan/s2885/mainboard.c
CVS:    src/mainboard/tyan/s4880/mainboard.c
CVS:    src/mainboard/tyan/s4882/mainboard.c
CVS: Added Files:
CVS:    src/drivers/generic/debug/Config.lb
CVS:    src/drivers/generic/debug/chip.h
CVS:    src/drivers/generic/debug/debug_dev.c
CVS: ----------------------------------------------------------------------

-----Original Message-----
From: Li-Ta Lo [mailto:ollie at lanl.gov] 
Sent: Thursday, November 04, 2004 1:35 PM
To: YhLu
Cc: LinuxBIOS
Subject: RE: Removing device driver code in mainboard.c for Tyan boards?

On Thu, 2004-11-04 at 14:22, YhLu wrote:
> I want to print PCI regs after PCI device initialization.
> 
> Where need to put the calling print_pci_regs_all? In hardwaremain ???
> 

Why don't you put the debug device into device/generic/debug ?
And in the mainboard Config.lb you added

	chip device/generic/debug

as the last chip. The device emuleration will call the methods
of the debug device last. And you probably can dump PCI CS registers
in different stages of the enumeration.

Ollie



From davidnicol at gmail.com  Thu Nov  4 16:23:01 2004
From: davidnicol at gmail.com (David Nicol)
Date: Thu Nov  4 16:23:01 2004
Subject: Just for Fun: 01/12/01 submission
Message-ID: <934f64a2041104144722e4207c@mail.gmail.com>

Just for Fun: 01/12/01:
    Submit your ideas for the best use of all the useless factory
    flash parts we've got laying around


Thesis:
Glue on appropriate fishhooks and sell for use as lures. 

Antithesis:
Donate to elementary schools as a craft supply.

Synthesis:
Outsource gluing on the fishhooks to child labor.




-- 
David L Nicol


From davidnicol at gmail.com  Thu Nov  4 16:26:01 2004
From: davidnicol at gmail.com (David Nicol)
Date: Thu Nov  4 16:26:01 2004
Subject: Just for Fun: 01/12/01 submission
Message-ID: <934f64a20411041449587454a8@mail.gmail.com>

Just for Fun: 01/12/01:
    Submit your ideas for the best use of all the useless factory
flash parts we've got laying around.


Thesis:  Glue on fishhooks and sell as lures

Antithesis:  Donate to elementary schools as a craft supply

Synthesis:  Outsource assembly of the fishing lures to child laborers


-- 
David L Nicol
"How cool is that?" -- Elgie


From ollie at lanl.gov  Thu Nov  4 17:02:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Nov  4 17:02:00 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
In-Reply-To: <3174569B9743D511922F00A0C943142306BA2CB4@TYANWEB>
References: <3174569B9743D511922F00A0C943142306BA2CB4@TYANWEB>
Message-ID: <1099610745.3373.165.camel@exponential.lanl.gov>

On Thu, 2004-11-04 at 15:44, YhLu wrote:
> debug device added
> 
>         chip drivers/generic/debug
>                 device  pnp 0.0 on end
>         end
> 
> debug device will be sibling to PCI_DOMAIN and APIC_CLUSTER...
> 

Cool, that is exactly what I want. Actually by defining different debug 
devices, we can construct different 'probes' into the device space.
We can either probe software data structures or the real hardware and
we can do it at different phases of the device enumeration as we want.
For example, the current debug device (pnp 0.0) dumps the PCI CS 
registers at the end of device enumeration. We can define another
debug device to show the topology of the device tree or just print
the famous .name field ;-).

The best thing about the debug device is it totally extensible and
plug/unplugable. We don't have to add any code to the existing device
driver nor the hardwaremain(). It is decoupled from the rest of 
LinuxBIOS. The operations we need to act on the (normal) devices are 
encapsulated in the debug device.

Ollie



From YhLu at tyan.com  Thu Nov  4 17:44:00 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Nov  4 17:44:00 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
Message-ID: <3174569B9743D511922F00A0C943142306BA2CD1@TYANWEB>

Then every device will need do scan_static_bus.

Also the debug device need to find his parent....

YH

-----Original Message-----
From: Li-Ta Lo [mailto:ollie at lanl.gov] 
Sent: Thursday, November 04, 2004 3:26 PM
To: YhLu
Cc: LinuxBIOS
Subject: RE: Removing device driver code in mainboard.c for Tyan boards?

On Thu, 2004-11-04 at 15:44, YhLu wrote:
> debug device added
> 
>         chip drivers/generic/debug
>                 device  pnp 0.0 on end
>         end
> 
> debug device will be sibling to PCI_DOMAIN and APIC_CLUSTER...
> 

Cool, that is exactly what I want. Actually by defining different debug 
devices, we can construct different 'probes' into the device space.
We can either probe software data structures or the real hardware and
we can do it at different phases of the device enumeration as we want.
For example, the current debug device (pnp 0.0) dumps the PCI CS 
registers at the end of device enumeration. We can define another
debug device to show the topology of the device tree or just print
the famous .name field ;-).

The best thing about the debug device is it totally extensible and
plug/unplugable. We don't have to add any code to the existing device
driver nor the hardwaremain(). It is decoupled from the rest of 
LinuxBIOS. The operations we need to act on the (normal) devices are 
encapsulated in the debug device.

Ollie


From ollie at lanl.gov  Thu Nov  4 17:48:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Nov  4 17:48:00 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
In-Reply-To: <3174569B9743D511922F00A0C943142306BA2CD1@TYANWEB>
References: <3174569B9743D511922F00A0C943142306BA2CD1@TYANWEB>
Message-ID: <1099613364.3373.167.camel@exponential.lanl.gov>

On Thu, 2004-11-04 at 17:13, YhLu wrote:
> Then every device will need do scan_static_bus.
> 
> Also the debug device need to find his parent....
> 

Why ??

Ollie




From stepan at openbios.org  Thu Nov  4 17:55:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Thu Nov  4 17:55:01 2004
Subject: linuxbios autobuild / regression testing
In-Reply-To: <m3u0s55sjp.fsf@maxwell.lnxi.com>
References: <m31xfaqn9t.fsf@maxwell.lnxi.com> <20041104091012.GA26662@openbios.org> <m3y8hhnad9.fsf@maxwell.lnxi.com> <Pine.LNX.4.58.0411040853470.1002@linux.site> <m3u0s55sjp.fsf@maxwell.lnxi.com>
Message-ID: <20041105001910.GB16244@openbios.org>

* Eric W. Biederman <ebiederman at lnxi.com> [041104 20:21]:
> In any case we need to start running abuild regularly.
> We need to have a way of dealing with ports that we are totally broken
> in the tree.

I implemented simple cross compiling support in LinuxBIOS abuild. So far 
it supports compiling x86 images on AMD64 and possibly PPC images on
PPC64 (untested).

If I'd find a set of cross-ppc-gcc rpms for SUSE 9.0-AMD64 I could set
up cross building ppc binaries on openbios.org and have the results
put to a web page or mailed regularly to the LinuxBIOS mailinglist.

It seems no mainboard says "use LD" at all yet. Some still don't 
"use CC" but this is minor..

What's the usual naming convention for the cross compiler and cross
linker of a given platform? We also need to cope with multiple payloads
if we want to be able to use the resulting binaries... (in an ideal
world the next step would be to automatically flash them)

Your check for a previous successful compile is really useful when
flying over the tree and fixing a larger number of boards. To detect
any regressions easily I added the option -a so all motherboard builds
can be forced.

also with -t vendor/board it is possible to only build a given board

./abuild.sh -at arima/hdama
will always rebuild the single target arima hdama

Stefan


From YhLu at tyan.com  Thu Nov  4 17:57:00 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Nov  4 17:57:00 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
Message-ID: <3174569B9743D511922F00A0C943142306BA2CD8@TYANWEB>

Do you mean 

             chip southbridge/amd/amd8111    
		         chip drivers/generic/debug
         		       device  pnp 0.0 on end # print parent .name
amd8111 SB
				  device  pnp 0.1 on end #  print parent PCI
CS...
				  device  pnp 0.2 on end # othe debug...
        			end
                   device pci 0.0 on
                         device pci 0.0 on end
                         device pci 0.1 on end
                         device pci 0.2 off end
                         device pci 1.0 off end
                    end
                    device pci 1.0 on
......

-----Original Message-----
From: Li-Ta Lo [mailto:ollie at lanl.gov] 
Sent: Thursday, November 04, 2004 4:09 PM
To: YhLu
Cc: LinuxBIOS
Subject: RE: Removing device driver code in mainboard.c for Tyan boards?

On Thu, 2004-11-04 at 17:13, YhLu wrote:
> Then every device will need do scan_static_bus.
> 
> Also the debug device need to find his parent....
> 

Why ??

Ollie



From ollie at lanl.gov  Thu Nov  4 18:02:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Nov  4 18:02:01 2004
Subject: 8131 and 8151 in static.c
Message-ID: <1099614350.3373.174.camel@exponential.lanl.gov>

Eric,

Why there is no 
	struct southbridge_amd_amd8131_config
or
	struct southbridge_amd_amd8151_config

in ter static.c although we have
	chip southbridge/amd/amd8131
and
	chip southbridge/amd/amd8151

in the Config.lb?

There is no
	struct chip_operations southbridge_amd_amd8131_ops
nor
	struct chip_operations southbridge_amd_amd8151_ops
nether.

Ollie



From ollie at lanl.gov  Thu Nov  4 18:04:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Nov  4 18:04:00 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
In-Reply-To: <3174569B9743D511922F00A0C943142306BA2CD8@TYANWEB>
References: <3174569B9743D511922F00A0C943142306BA2CD8@TYANWEB>
Message-ID: <1099614454.3373.176.camel@exponential.lanl.gov>

On Thu, 2004-11-04 at 17:26, YhLu wrote:
> Do you mean 
> 
>              chip southbridge/amd/amd8111    
> 		         chip drivers/generic/debug
>          		       device  pnp 0.0 on end # print parent .name
> amd8111 SB
> 				  device  pnp 0.1 on end #  print parent PCI
> CS...
> 				  device  pnp 0.2 on end # othe debug...
>         			end
>                    device pci 0.0 on
>                          device pci 0.0 on end
>                          device pci 0.1 on end
>                          device pci 0.2 off end
>                          device pci 1.0 off end
>                     end
>                     device pci 1.0 on
> ......
> 

Sort of, but the chip is at the 'top' level like it is in the 
s2885/Config.lb now.

Ollie




From stepan at openbios.org  Thu Nov  4 18:27:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Thu Nov  4 18:27:01 2004
Subject: make -j4 ?
Message-ID: <20041105005030.GA5511@openbios.org>

Hi,

just noticed on my way to bed..

it seems make -j does work fine for the single linuxbios images
(fallback / normal) but not for the concatenated final one because of
a wrong dependency:


------------------------------ 8< -----------------------------

all: fallback-rom normal-rom buildroms

fallback-rom:
        if (cd fallback; \
                make linuxbios.rom)\
        then true; else exit 1; fi;

normal-rom:
        if (cd normal; \
                make linuxbios.rom)\
        then true; else exit 1; fi;

buildroms:
        cat normal/linuxbios.rom fallback/linuxbios.rom > ./amd_quartet.rom


------------------------------ 8< -----------------------------

should look like:

all: buildroms
[..]
buildroms: fallback-rom normal-rom

Otherwise make assumes it can build all three of 
fallback-rom, normal-rom and buildroms in parallel

Stefan




From liutao at safe-mail.net  Thu Nov  4 19:45:00 2004
From: liutao at safe-mail.net (Liu Tao)
Date: Thu Nov  4 19:45:00 2004
Subject: Board hangs after soft_reset() in auto.c
In-Reply-To: <m33bzpopxr.fsf@maxwell.lnxi.com>
References: <418A050A.4020307@safe-mail.net> <m33bzpopxr.fsf@maxwell.lnxi.com>
Message-ID: <418AE11E.6010704@safe-mail.net>

Thanks, after remove the ht_optimize_link() in ht_setup_chainx()
the board soft resets OK.

Eric W. Biederman wrote:
 >
 >The short answer is that optimizing the hypertransport speed and frequency
 >is an optimization.  So you can disable the reset and see how far you 
board
 >gets otherwise.  That should give you a little more time to debug the 
reset path.
 >

Regards,
Liu Tao


From YhLu at tyan.com  Thu Nov  4 20:15:01 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Nov  4 20:15:01 2004
Subject: Board hangs after soft_reset() in auto.c
Message-ID: <3174569B9743D511922F00A0C943142306BA2CED@TYANWEB>

It seems that you only have one CPU. Then without ht_optimize_link in
in_conherent.c  you even don't need to do soft_reset.

What's the value in you resource_map.c?

You need update that to

    PCI_ADDR(0, 0x18, 1, 0xE0), 0x0000FC88, 0x06000203, // AMD 8131/8111 on
link0 of CPU 0
    PCI_ADDR(0, 0x18, 1, 0xE4), 0x0000FC88, 0x09070003, // AMD 8131 on link1
of CPU 0
    PCI_ADDR(0, 0x18, 1, 0xE8), 0x0000FC88, 0x0c0a0003, // AMD 8131 on link2
of CPU 0
    PCI_ADDR(0, 0x18, 1, 0xEC), 0x0000FC88, 0x00000000,

In the auto.c

        static const struct ht_chain ht_c[] = {
                { /* Link 0 of CPU0 */
                        .devreg = 0xe0,  /* Preset bus num in resource map
*/
                },      
                { /* Link 1 of CPU0 */
                        .devreg = 0xe4,  /* Preset bus num in resource map
*/
                },      
                { /* Link 2 of CPU0 */
                        .devreg = 0xe8,  /* Preset bus num in resource map
*/
                },      
        };


Regards

YH

-----Original Message-----
From: Liu Tao [mailto:liutao at safe-mail.net] 
Sent: Thursday, November 04, 2004 6:11 PM
To: Eric W. Biederman
Cc: LinuxBIOS
Subject: Re: Board hangs after soft_reset() in auto.c

Thanks, after remove the ht_optimize_link() in ht_setup_chainx()
the board soft resets OK.

Eric W. Biederman wrote:
 >
 >The short answer is that optimizing the hypertransport speed and frequency
 >is an optimization.  So you can disable the reset and see how far you 
board
 >gets otherwise.  That should give you a little more time to debug the 
reset path.
 >

Regards,
Liu Tao
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From liutao at safe-mail.net  Thu Nov  4 21:08:00 2004
From: liutao at safe-mail.net (Liu Tao)
Date: Thu Nov  4 21:08:00 2004
Subject: Board hangs after soft_reset() in auto.c
In-Reply-To: <3174569B9743D511922F00A0C943142306BA2CED@TYANWEB>
References: <3174569B9743D511922F00A0C943142306BA2CED@TYANWEB>
Message-ID: <418AF498.1090002@safe-mail.net>

I was using the old .upos version ht_c[] and misconfigured the upos value,
after fixed the value soft resets OK with ht_optimize_link(). Another
needs_reset request comes from apply_cpu_errata_fixes().

Regards,
Liu Tao


YhLu wrote:

 >It seems that you only have one CPU. Then without ht_optimize_link in
 >in_conherent.c  you even don't need to do soft_reset.
 >
 >What's the value in you resource_map.c?
 >
 >You need update that to
 >
 >    PCI_ADDR(0, 0x18, 1, 0xE0), 0x0000FC88, 0x06000203, // AMD 
8131/8111 on
 >link0 of CPU 0
 >    PCI_ADDR(0, 0x18, 1, 0xE4), 0x0000FC88, 0x09070003, // AMD 8131 on 
link1
 >of CPU 0
 >    PCI_ADDR(0, 0x18, 1, 0xE8), 0x0000FC88, 0x0c0a0003, // AMD 8131 on 
link2
 >of CPU 0
 >    PCI_ADDR(0, 0x18, 1, 0xEC), 0x0000FC88, 0x00000000,
 >
 >In the auto.c
 >
 >        static const struct ht_chain ht_c[] = {
 >                { /* Link 0 of CPU0 */
 >                        .devreg = 0xe0,  /* Preset bus num in resource map
 >*/
 >                },   
 >                { /* Link 1 of CPU0 */
 >                        .devreg = 0xe4,  /* Preset bus num in resource map
 >*/
 >                },   
 >                { /* Link 2 of CPU0 */
 >                        .devreg = 0xe8,  /* Preset bus num in resource map
 >*/
 >                },   
 >        };
 >
 >


From ebiederman at lnxi.com  Thu Nov  4 21:20:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Nov  4 21:20:01 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
In-Reply-To: <3174569B9743D511922F00A0C943142306BA2C98@TYANWEB>
References: <3174569B9743D511922F00A0C943142306BA2C98@TYANWEB>
Message-ID: <m3u0s57yex.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Actually, Eric another link to dev_root and it's init will be called after
> all under dev_root link0.

Exactly.  I simply removed the debugging code that was doing this because
the mainboard is much easier to read and maintain without it.

But for debugging it is a sane technique and it may be worth having an example
around somewhere that does this.  Just always doing it in every mainboard file
seems like overkill.

Eric


From ebiederman at lnxi.com  Thu Nov  4 21:24:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Nov  4 21:24:00 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
In-Reply-To: <1099598702.3373.129.camel@exponential.lanl.gov>
References: <3174569B9743D511922F00A0C943142306BA2C63@TYANWEB>
	<1099598702.3373.129.camel@exponential.lanl.gov>
Message-ID: <m3pt2t7y8y.fsf@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:

> On Thu, 2004-11-04 at 10:45, YhLu wrote:
> > OK for me.
> > 
> > Some line I want to use print mem or pci at the end of LinuxBIOS can not be
> > used now. Eric removed the CHIP_PASS....
> > 
> 
> I guess we don't need the driver/intel|si||adaptec|boradcom anymore ?

That is what replaced the #if 0 #endif code from the Tyan motherboards.

This is needed especially for little things like setting the motherboard's
subsystem vendor and subsystem id.

Eric


From YhLu at tyan.com  Thu Nov  4 21:24:13 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Nov  4 21:24:13 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
Message-ID: <3174569B9743D511922F00A0C943142306BA2CF3@TYANWEB>

I modified some debug func.
        chip drivers/generic/debug
                device pnp 0.0 on end # print parent name
                device pnp 0.1 off end # print PCI regs
                device pnp 0.2 off end # print mem
                device pnp 0.3 on end # print msr ?
        end

but it only can be put under device with scan_static_bus calling.
Such as dev_root and lpc.

Regards

YH

-----Original Message-----
From: Li-Ta Lo [mailto:ollie at lanl.gov] 
Sent: Thursday, November 04, 2004 4:09 PM
To: YhLu
Cc: LinuxBIOS
Subject: RE: Removing device driver code in mainboard.c for Tyan boards?

On Thu, 2004-11-04 at 17:13, YhLu wrote:
> Then every device will need do scan_static_bus.
> 
> Also the debug device need to find his parent....
> 

Why ??

Ollie



From ebiederman at lnxi.com  Thu Nov  4 21:26:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Nov  4 21:26:01 2004
Subject: PCI_DOMAIN ??
In-Reply-To: <1099599337.3373.131.camel@exponential.lanl.gov>
References: <1099518645.3373.99.camel@exponential.lanl.gov>
	<m3fz3qk0ln.fsf@maxwell.lnxi.com>
	<1099522768.3373.106.camel@exponential.lanl.gov>
	<m3d5yua5c4.fsf@maxwell.lnxi.com>
	<1099524915.3373.110.camel@exponential.lanl.gov>
	<m3d5yuzc8c.fsf@maxwell.lnxi.com>
	<1099586422.3373.124.camel@exponential.lanl.gov>
	<Pine.LNX.4.58.0411041010400.1147@linux.site>
	<m3y8hh5sok.fsf@maxwell.lnxi.com>
	<1099599337.3373.131.camel@exponential.lanl.gov>
Message-ID: <m3lldh7y5k.fsf@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:

> For some reason you didn't convert the tyan/s2875/mainboard.c. Did you
> just miss it? 

That sounds like what happened.  s2875 does not sound at all familiar.

Eric


From YhLu at tyan.com  Thu Nov  4 21:31:01 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Nov  4 21:31:01 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
Message-ID: <3174569B9743D511922F00A0C943142306BA2CF4@TYANWEB>

chip northbridge/amd/amdk8                              
        device pci_domain 0 on                          
                device pci 18.0 on # LDT0       
.				....
			  End
			  ....
			  chip northbridge/amd/amdk8

				device pci 19.0 end
				...
			   End 
		End # PCI domain
.....acpic...
End # NB K8

It looks strang, 
Why not thang that to followings?

device pci_domain 0 on                          
	chip northbridge/amd/amdk8                              
                device pci 18.0 on # LDT0       
.				....
			  End
			  ....
	 End #NB K8
			  chip northbridge/amd/amdk8

				device pci 19.0 end
				...
			   End 
		End # PCI domain
.....apic....


From ebiederman at lnxi.com  Thu Nov  4 21:35:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Nov  4 21:35:01 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
In-Reply-To: <1099613364.3373.167.camel@exponential.lanl.gov>
References: <3174569B9743D511922F00A0C943142306BA2CD1@TYANWEB>
	<1099613364.3373.167.camel@exponential.lanl.gov>
Message-ID: <m3hdo57xqu.fsf@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:

> On Thu, 2004-11-04 at 17:13, YhLu wrote:
> > Then every device will need do scan_static_bus.
> > 
> > Also the debug device need to find his parent....
> > 

> Why ??
> 
> Ollie

YhLu I think Ollie was just thinking about different kinds
of debug devices for different kinds of debugging information.

One to print the out pci space.
Another one dump the cpu msrs.

Etc.

Basically just configurable hooks that we can collect and
everyone can share.

It should not be necessary to place the debug devices in
different places in the tree.

Eric


From ebiederman at lnxi.com  Thu Nov  4 21:39:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Nov  4 21:39:00 2004
Subject: 8131 and 8151 in static.c
In-Reply-To: <1099614350.3373.174.camel@exponential.lanl.gov>
References: <1099614350.3373.174.camel@exponential.lanl.gov>
Message-ID: <m3d5yt7xk4.fsf@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:

> Eric,
> 
> Why there is no 
> 	struct southbridge_amd_amd8131_config
> or
> 	struct southbridge_amd_amd8151_config

Because they don't need an enable_dev method.

> in ter static.c although we have
> 	chip southbridge/amd/amd8131
> and
> 	chip southbridge/amd/amd8151
> 
> in the Config.lb?

The chips are found by their pci_ids.

> There is no
> 	struct chip_operations southbridge_amd_amd8131_ops
> nor
> 	struct chip_operations southbridge_amd_amd8151_ops
> nether.

Currently struct xxxxx_config and struct chip_operations xxx_ops
are tied together.  If you have you have both.

We don't currently require a struct chip_operations.

I have not thought enough about this to know if it is a good or
a bad thing.  It is simply the way it was done and I have not changed it.
If we always required this we could remove the config directive
from the configuration language.

Eric


From liutao at safe-mail.net  Thu Nov  4 21:40:00 2004
From: liutao at safe-mail.net (Liu Tao)
Date: Thu Nov  4 21:40:00 2004
Subject: Board hangs after soft_reset() in auto.c
In-Reply-To: <3174569B9743D511922F00A0C943142306BA2CED@TYANWEB>
References: <3174569B9743D511922F00A0C943142306BA2CED@TYANWEB>
Message-ID: <418AFC08.9090409@safe-mail.net>

Can this cause configuration regions overlap with each other during
device enumeration? In amdk8_scan_chains() the subordinate/limit field of
current register is set to 0xff before hypertransport_scan_chain(),
while other following registers are not touched yet, so they overlay with
current register?

Regards,
Liu Tao

 >
 >    PCI_ADDR(0, 0x18, 1, 0xE0), 0x0000FC88, 0x06000203, // AMD 
8131/8111 on
 >link0 of CPU 0
 >    PCI_ADDR(0, 0x18, 1, 0xE4), 0x0000FC88, 0x09070003, // AMD 8131 on 
link1
 >of CPU 0
 >    PCI_ADDR(0, 0x18, 1, 0xE8), 0x0000FC88, 0x0c0a0003, // AMD 8131 on 
link2
 >of CPU 0
 >    PCI_ADDR(0, 0x18, 1, 0xEC), 0x0000FC88, 0x00000000,
 >


From YhLu at tyan.com  Thu Nov  4 21:45:00 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Nov  4 21:45:00 2004
Subject: Board hangs after soft_reset() in auto.c
Message-ID: <3174569B9743D511922F00A0C943142306BA2CF5@TYANWEB>

That only used by auto.c (in_conherent.c)

And it is ok to be overlapped in c parts. ( hardwaremain)?

To do that, only let cpu can see different BUS in auto.c stage.

Regards

YH


-----Original Message-----
From: Liu Tao [mailto:liutao at safe-mail.net] 
Sent: Thursday, November 04, 2004 8:05 PM
To: YhLu
Cc: Eric W. Biederman; LinuxBIOS
Subject: Re: Board hangs after soft_reset() in auto.c

Can this cause configuration regions overlap with each other during
device enumeration? In amdk8_scan_chains() the subordinate/limit field of
current register is set to 0xff before hypertransport_scan_chain(),
while other following registers are not touched yet, so they overlay with
current register?

Regards,
Liu Tao

 >
 >    PCI_ADDR(0, 0x18, 1, 0xE0), 0x0000FC88, 0x06000203, // AMD 
8131/8111 on
 >link0 of CPU 0
 >    PCI_ADDR(0, 0x18, 1, 0xE4), 0x0000FC88, 0x09070003, // AMD 8131 on 
link1
 >of CPU 0
 >    PCI_ADDR(0, 0x18, 1, 0xE8), 0x0000FC88, 0x0c0a0003, // AMD 8131 on 
link2
 >of CPU 0
 >    PCI_ADDR(0, 0x18, 1, 0xEC), 0x0000FC88, 0x00000000,
 >


From YhLu at tyan.com  Thu Nov  4 21:48:00 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Nov  4 21:48:00 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
Message-ID: <3174569B9743D511922F00A0C943142306BA2CF6@TYANWEB>

and

Mainboard on
.....
End

Mainboard on
...
End

To put them into dev_root links

YH

-----Original Message-----
From: YhLu 
Sent: Thursday, November 04, 2004 8:01 PM
To: ebiederman at lnxi.com
Cc: Ronald G. Minnich; Li-Ta Lo; LinuxBIOS
Subject: RE: Removing device driver code in mainboard.c for Tyan boards?

chip northbridge/amd/amdk8                              
        device pci_domain 0 on                          
                device pci 18.0 on # LDT0       
.				....
			  End
			  ....
			  chip northbridge/amd/amdk8

				device pci 19.0 end
				...
			   End 
		End # PCI domain
.....acpic...
End # NB K8

It looks strang, 
Why not thang that to followings?

device pci_domain 0 on                          
	chip northbridge/amd/amdk8                              
                device pci 18.0 on # LDT0       
.				....
			  End
			  ....
	 End #NB K8
			  chip northbridge/amd/amdk8

				device pci 19.0 end
				...
			   End 
		End # PCI domain
.....apic....
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From ebiederman at lnxi.com  Thu Nov  4 21:48:11 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Nov  4 21:48:11 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
In-Reply-To: <3174569B9743D511922F00A0C943142306BA2CF4@TYANWEB>
References: <3174569B9743D511922F00A0C943142306BA2CF4@TYANWEB>
Message-ID: <m3ekj953zs.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> chip northbridge/amd/amdk8                              
>         device pci_domain 0 on                          
>                 device pci 18.0 on # LDT0       
> .				....
> 			  End
> 			  ....
> 			  chip northbridge/amd/amdk8
> 
> 				device pci 19.0 end
> 				...
> 			   End 
> 		End # PCI domain
> .....acpic...
> End # NB K8
> 
> It looks strang, 
> Why not thang that to followings?

Primarily because that device pci_domain needs some chip to sit in.

And because the methods for the pci_domain are closely related
to the code that looks at the rest of the chipset.

So in short what we are currently doing his the least strange
method I have found to model the reality.

It might help to think that the device tree is from the perspective of cpu 0.

Eric


From ebiederman at lnxi.com  Thu Nov  4 21:57:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Nov  4 21:57:00 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
In-Reply-To: <3174569B9743D511922F00A0C943142306BA2CF6@TYANWEB>
References: <3174569B9743D511922F00A0C943142306BA2CF6@TYANWEB>
Message-ID: <m3wtx1x6xc.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> and
> 
> Mainboard on
> .....
> End
> 
> Mainboard on
> ...
> End
> 
> To put them into dev_root links

At which point the code would need to be implemented in the mainboard
which is something I want to avoid except for mainboard specific code.

I can see doing something like:

chip northbridge/amd/amk8/root_complex
        device pci_domain 0 on 
		chip northbridge/amd/amdk8
			device pci 18.0 on end # LDT 0
			device pci 18.0 on end # LDT1
			device pci 18.0 on end # LDT2
			device pci 18.1 on end
			device pci 18.2 on end
			device pci 18.3 on end
                end
		chip northbridge/amd/amdk8
			device pci 19.0 on end
			device pci 19.0 on end
			device pci 19.0 on end
			device pci 19.1 on end
			device pci 19.2 on end
			device pci 19.3 on end
		end
	end
	device apic_cluster 0 on
		chip cpu/amd/socket_940
			device apic 0 on end
		end
		chip cpu/amd/socket_940
			device apic 1 on end
		end
	end
end

And leaving all of the code for the root_complex in
northbridge/amd/amdk8/northbridge.c

Eric


From YhLu at tyan.com  Thu Nov  4 22:00:01 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Nov  4 22:00:01 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
Message-ID: <3174569B9743D511922F00A0C943142306BA2CF8@TYANWEB>

Great. That will be very clear.

Then
chip northbridge/amd/amk8/root_complex

..

End # ----> dev_root link0
chip northbridge/amd/amk8/root_complex

..

End # ----> dev_root link1

chip northbridge/amd/amk8/root_complex

..

End # ----> dev_root link2


From liutao at safe-mail.net  Thu Nov  4 22:05:01 2004
From: liutao at safe-mail.net (Liu Tao)
Date: Thu Nov  4 22:05:01 2004
Subject: Board hangs after soft_reset() in auto.c
In-Reply-To: <3174569B9743D511922F00A0C943142306BA2CF5@TYANWEB>
References: <3174569B9743D511922F00A0C943142306BA2CF5@TYANWEB>
Message-ID: <418B01EC.4060703@safe-mail.net>

I mean when enumerating HT0 e0 is set to 0xff010003, while e4 matains 
0x09070103,
so e4 overlaps with e0?

Regards,
Liu Tao

YhLu wrote:

 >That only used by auto.c (in_conherent.c)
 >
 >And it is ok to be overlapped in c parts. ( hardwaremain)?
 >
 >To do that, only let cpu can see different BUS in auto.c stage.
 >



From ebiederman at lnxi.com  Thu Nov  4 22:05:14 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Nov  4 22:05:14 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
In-Reply-To: <3174569B9743D511922F00A0C943142306BA2CF8@TYANWEB>
References: <3174569B9743D511922F00A0C943142306BA2CF8@TYANWEB>
Message-ID: <m3mzxwrka6.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Great. That will be very clear.
> 
> Then
> chip northbridge/amd/amk8/root_complex
> 
> ..
> 
> End # ----> dev_root link0
> chip northbridge/amd/amk8/root_complex
> 
> ..
> 
> End # ----> dev_root link1
> 
> chip northbridge/amd/amk8/root_complex
> 
> ..
> 
> End # ----> dev_root link2

And what do you want on link1 and link2 for the root_device?

Among other things I'm not certain config.g currently supports
that. 

Is this just for placing the debug devices far away?

Eric


From YhLu at tyan.com  Thu Nov  4 22:08:00 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Nov  4 22:08:00 2004
Subject: Board hangs after soft_reset() in auto.c
Message-ID: <3174569B9743D511922F00A0C943142306BA2CF9@TYANWEB>

Which stage auto.c
E0: 0xff010003 -->  0x06000003
E4: 0x09070103 -->  0x09070103
E8: 		     -->   0x0c0a0203

YH
-----Original Message-----
From: Liu Tao [mailto:liutao at safe-mail.net] 
Sent: Thursday, November 04, 2004 8:31 PM
To: YhLu
Cc: Eric W. Biederman; LinuxBIOS
Subject: Re: Board hangs after soft_reset() in auto.c

I mean when enumerating HT0 e0 is set to 0xff010003, while e4 matains 
0x09070103,
so e4 overlaps with e0?

Regards,
Liu Tao

YhLu wrote:

 >That only used by auto.c (in_conherent.c)
 >
 >And it is ok to be overlapped in c parts. ( hardwaremain)?
 >
 >To do that, only let cpu can see different BUS in auto.c stage.
 >


From YhLu at tyan.com  Thu Nov  4 22:12:01 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Nov  4 22:12:01 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
Message-ID: <3174569B9743D511922F00A0C943142306BA2CFA@TYANWEB>

No, debug_dev can be PCI_DOMAIN and APIC's sibling and one child dev_root in
link0.

YH

-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Thursday, November 04, 2004 8:29 PM
To: YhLu
Cc: Ronald G. Minnich; Li-Ta Lo; LinuxBIOS
Subject: Re: Removing device driver code in mainboard.c for Tyan boards?

YhLu <YhLu at tyan.com> writes:

> Great. That will be very clear.
> 
> Then
> chip northbridge/amd/amk8/root_complex
> 
> ..
> 
> End # ----> dev_root link0
> chip northbridge/amd/amk8/root_complex
> 
> ..
> 
> End # ----> dev_root link1
> 
> chip northbridge/amd/amk8/root_complex
> 
> ..
> 
> End # ----> dev_root link2

And what do you want on link1 and link2 for the root_device?

Among other things I'm not certain config.g currently supports
that. 

Is this just for placing the debug devices far away?

Eric


From ebiederman at lnxi.com  Thu Nov  4 22:29:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Nov  4 22:29:01 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
In-Reply-To: <3174569B9743D511922F00A0C943142306BA2CFA@TYANWEB>
References: <3174569B9743D511922F00A0C943142306BA2CFA@TYANWEB>
Message-ID: <m3y8hgyk06.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> No, debug_dev can be PCI_DOMAIN and APIC's sibling and one child dev_root in
> link0.

So why the question about dev_root link 1 and 2?

Eric


From ebiederman at lnxi.com  Fri Nov  5 01:56:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Nov  5 01:56:01 2004
Subject: make -j4 ?
In-Reply-To: <20041105005030.GA5511@openbios.org>
References: <20041105005030.GA5511@openbios.org>
Message-ID: <m3mzxw1zdi.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at openbios.org> writes:

> Hi,
> 
> just noticed on my way to bed..
> 
> it seems make -j does work fine for the single linuxbios images
> (fallback / normal) but not for the concatenated final one because of
> a wrong dependency:

> Otherwise make assumes it can build all three of 
> fallback-rom, normal-rom and buildroms in parallel

I have just taken a first stab at this and my current Makefile is below.
There is still some missing dependency information but otherwise things should be
correct.  What I have not massaged is left as an exercise to the reader :)

Now to see if I can get abuild building ppc targets.

# File: tdir/hdama/Makefile is autogenerated
Makefile: /home/eric/projects/linuxbios/linuxbios/hdama/tdir/hdama/config.py /home/eric/projects/linuxbios/linuxbios/hdama/Config.lb
	(cd /home/eric/projects/linuxbios/linuxbios/hdama ; /home/eric/projects/linuxbios/linuxbios/hdama/tdir/hdama/config.py ./Config.lb ./freebios2)

include Makefile.settings

all: ./linuxbios.rom

fallback/linuxbios.rom:
	if (cd fallback; \
		make linuxbios.rom)\
	then true; else exit 1; fi;

normal/linuxbios.rom:
	if (cd normal; \
		make linuxbios.rom)\
	then true; else exit 1; fi;

clean:  fallback-clean normal-clean

fallback-clean:
	(cd fallback; make clean)

normal-clean:
	(cd normal; make clean)

./linuxbios.rom: normal/linuxbios.rom  fallback/linuxbios.rom 
	cat  normal/linuxbios.rom  fallback/linuxbios.rom > ./linuxbios.rom

.PHONY: all clean fallback-clean normal-clean




From liutao at safe-mail.net  Fri Nov  5 02:01:01 2004
From: liutao at safe-mail.net (Liu Tao)
Date: Fri Nov  5 02:01:01 2004
Subject: Board hangs after soft_reset() in auto.c
In-Reply-To: <3174569B9743D511922F00A0C943142306BA2CF9@TYANWEB>
References: <3174569B9743D511922F00A0C943142306BA2CF9@TYANWEB>
Message-ID: <418B3921.9070700@safe-mail.net>

YhLu wrote:

 >Which stage auto.c
 >E0: 0xff010003 -->  0x06000003
 >E4: 0x09070103 -->  0x09070103
 >E8:              -->   0x0c0a0203
 >
 >YH

In auto.c setup_myboard_resource_map():
E0: <- 0x06000003
E4: <- 0x09070103
E8: <- 0x0c0a0203

then in C part amdk8_scan_chains():
E0: <- 0xff010003 (max=0)    /* E0 overlaps E4/E8 ? */
max = hypertransport_scan_chain(link0, max);
E0: <- 0x06010003 (imagin max=0x6)
E4: <- 0xff070003        /* E4 overlaps E8 ? */
max = hypertransport_scan_chain(link1, max);
E4: <- 0x09070003 (imagin max=0x9)
E8: <- 0xff0a0003
max = hypertransport_scan_chain(link2, max);
E8: <- 0x0c0a0003 (imagin max=0xc)

Regards,
Liu Tao





From ebiederman at lnxi.com  Fri Nov  5 03:22:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Nov  5 03:22:01 2004
Subject: linuxbios autobuild / regression testing
In-Reply-To: <20041105001910.GB16244@openbios.org>
References: <m31xfaqn9t.fsf@maxwell.lnxi.com>
	<20041104091012.GA26662@openbios.org>
	<m3y8hhnad9.fsf@maxwell.lnxi.com>
	<Pine.LNX.4.58.0411040853470.1002@linux.site>
	<m3u0s55sjp.fsf@maxwell.lnxi.com>
	<20041105001910.GB16244@openbios.org>
Message-ID: <m37jp0iq7r.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at openbios.org> writes:

> * Eric W. Biederman <ebiederman at lnxi.com> [041104 20:21]:
> > In any case we need to start running abuild regularly.
> > We need to have a way of dealing with ports that we are totally broken
> > in the tree.
> 
> I implemented simple cross compiling support in LinuxBIOS abuild. So far 
> it supports compiling x86 images on AMD64 and possibly PPC images on
> PPC64 (untested).
> 
> If I'd find a set of cross-ppc-gcc rpms for SUSE 9.0-AMD64 I could set
> up cross building ppc binaries on openbios.org and have the results
> put to a web page or mailed regularly to the LinuxBIOS mailinglist.
> 
> It seems no mainboard says "use LD" at all yet. Some still don't 
> "use CC" but this is minor..

Actually what you should be looking for is "uses CROSS_COMPILE"
Currently we don't seem to call LD directly so as long as gcc can
find the proper one we are ok.
 
> What's the usual naming convention for the cross compiler and cross
> linker of a given platform? We also need to cope with multiple payloads
> if we want to be able to use the resulting binaries... (in an ideal
> world the next step would be to automatically flash them)

I suspect that we will want to have a simple Config.lb in targets that
we can start with and add cross compiling and other options to.
 
> Your check for a previous successful compile is really useful when
> flying over the tree and fixing a larger number of boards. To detect
> any regressions easily I added the option -a so all motherboard builds
> can be forced.
>
> also with -t vendor/board it is possible to only build a given board
> 
> ./abuild.sh -at arima/hdama
> will always rebuild the single target arima hdama

-a and -t sound like useful additions.

Just don't forget that ultimately if we can fix the dependencies in the
tree we both -a and my caching of what actually built successfully
should be trivial.

Note: I had to tweak the parser so it would work when I specified where the
linuxbios tree was.  It was putting single quotes around the pathname
nad ls was not really fond of './freebios2/'/src/mainboard ....

Eric


From stepan at openbios.org  Fri Nov  5 04:58:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Fri Nov  5 04:58:00 2004
Subject: [Freebios-cvs] freebios2/util/abuild abuild.sh,1.5,1.6
In-Reply-To: <E1CPzo8-0007Cu-Lp@sc8-pr-cvs1.sourceforge.net>
References: <E1CPzo8-0007Cu-Lp@sc8-pr-cvs1.sourceforge.net>
Message-ID: <20041105112230.GA13168@openbios.org>

Eric,

I tried this before as well, but it does not work, at least with my
util-linux 2.11z:

./abuild.sh -h
LBROOT=-h
ls: invalid option -- /
Try `ls --help' for more information.

Which is why I ended up doing the workaround I used.

Do you know a fix that actually helps fixing your fix, or shall I revert
your changes?

Stefan


* Eric Biederman <ebiederm at users.sourceforge.net> [041105 09:50]:
> Index: abuild.sh
> ===================================================================
> RCS file: /cvsroot/freebios/freebios2/util/abuild/abuild.sh,v
> retrieving revision 1.5
> retrieving revision 1.6
> diff -C2 -d -r1.5 -r1.6
> *** abuild.sh	5 Nov 2004 00:26:31 -0000	1.5
> --- abuild.sh	5 Nov 2004 08:50:53 -0000	1.6
> ***************
> *** 254,258 ****
>   
>   # parse parameters
> ! args=`getopt -l version,verbose,help,all,target: Vvhat: $*`
>   
>   if [ $? != 0 ]; then
> --- 255,259 ----
>   
>   # parse parameters
> ! args=`getopt -l version,verbose,help,all,target: Vvhat: -- "$@"`
>   
>   if [ $? != 0 ]; then
> ***************
> *** 261,278 ****
>   fi
>   
> ! set -- $args
> ! for arg
> ! do
> !   case $arg in
> !         -t|--target)	shift;target=$1;shift;;
> !         -a|--all)	shift;buildall=true;;
> ! 	-v|--verbose)	shift;verbose=true;;
> ! 	-V|--version)	shift;myversion;;
> ! 	-h|--help)	shift;myhelp;;
> !   esac
>   done
>   
> ! # -- is $1
> ! LBROOT=$2
>   
>   # /path/to/freebios2/
> --- 262,279 ----
>   fi
>   
> ! eval set -- "$args"
> ! while true ; do
> ! 	case $1 in
> ! 		-t|--target)	shift; target=$1; shift;;
> ! 		-a|--all)	shift; buildall=true;;
> ! 		-v|--verbose)	shift; verbose=true;;
> ! 		-V|--version)	shift; myversion;;
> ! 		-h|--help)	shift; myhelp;;
> ! 		--)		shift; break;;
> ! 		*)		echo "Unrecognized argument" ; exit 1 ;;
> ! 	esac
>   done
>   
> ! LBROOT=$1
>   
>   # /path/to/freebios2/
> ***************
> *** 280,283 ****
> --- 281,285 ----
>   	LBROOT=$( cd ../..; pwd )
>   fi
> + echo "LBROOT=$LBROOT"
>   
>   if [ "$target" != "" ]; then



From ebiederman at lnxi.com  Fri Nov  5 05:29:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Nov  5 05:29:01 2004
Subject: [Freebios-cvs] freebios2/util/abuild abuild.sh,1.5,1.6
In-Reply-To: <20041105112230.GA13168@openbios.org>
References: <E1CPzo8-0007Cu-Lp@sc8-pr-cvs1.sourceforge.net>
	<20041105112230.GA13168@openbios.org>
Message-ID: <m3mzxwpl69.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at openbios.org> writes:

> Eric,
> 
> I tried this before as well, but it does not work, at least with my
> util-linux 2.11z:
> 
> ./abuild.sh -h
> LBROOT=-h
> ls: invalid option -- /
> Try `ls --help' for more information.
> 
> Which is why I ended up doing the workaround I used.
> 
> Do you know a fix that actually helps fixing your fix, or shall I revert
> your changes?

It turns out that getopt was adding the -- prefix.
In addition -- is not specified to terminate the list of options so
breaking out when an option is not recognized is necessary.

There are days I really think getopt is way more trouble than it is worth.

Anyway it should be fixed now, and there is basic support for cross compiling on powerpc.

On powerpc we currently have 3 ports.  I have been concentrating on the
embeddedplanet ep405pc.  I have been able to coax it all the way
through the configuration process but I'm not certain how many of the things
I have done are just hacks at the moment.

In any event one thing I have clearly found is that abuild.sh is specifying 2 options
that the ep405pc atleast does not implement.  USE_FALLBACK_IMAGE and ROM_IMAGE_SIZE.

It is looking increasingly like we probably want to start working with the
target directory.  Not having a USE_FALLBACK_IMAGE also appears to describe the qemu-i386
target as well which wants to build everything into just 64KiB.  Which is sane.

I will report back on what I learn about powerpc compilers when I get one that will
actually build the powerpc assembly code.  It appears mine currently do not support
all of the needed powerpc instructions :(

Eric


From stepan at openbios.org  Fri Nov  5 07:06:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Fri Nov  5 07:06:01 2004
Subject: linuxbios autobuild / regression testing
Message-ID: <20041105133001.GA17450@openbios.org>

* Eric W. Biederman <ebiederman at lnxi.com> [041105 10:45]:
> > It seems no mainboard says "use LD" at all yet. Some still don't 
> > "use CC" but this is minor..
> 
> Actually what you should be looking for is "uses CROSS_COMPILE"
> Currently we don't seem to call LD directly so as long as gcc can
> find the proper one we are ok.
 
Oops. Misassumption on my side. I just saw the defines on the compile
command line:

-DLINUXBIOS_LINKER='"GNU ld version 2.14.90.0.5 20030722 (SuSE Linux)"' -DLINUXBIOS_ASSEMBLER='"GNU assembler version 2.14.90.0.5 (x86_64-suse-linux) using BFD version 2.14.90.0.5 20030722 (SuSE Linux)"'

Are these compiled in per default?

> > What's the usual naming convention for the cross compiler and cross
> > linker of a given platform? We also need to cope with multiple payloads
> > if we want to be able to use the resulting binaries... (in an ideal
> > world the next step would be to automatically flash them)
> 
> I suspect that we will want to have a simple Config.lb in targets that
> we can start with and add cross compiling and other options to.
 
Hm. We're setting a lot of default options in Options.lb and some in
Config.lb for the mainboards.. Is there room to place defaults for these
specifics in there?
 
> > ./abuild.sh -at arima/hdama
> -a and -t sound like useful additions.
 
-at doesn't seem to work btw. -a -t does though.. whatever.

> Just don't forget that ultimately if we can fix the dependencies in the
> tree we both -a and my caching of what actually built successfully
> should be trivial.
 
so far I deleted the linuxbios-builds directory most of the time before each
build to make sure nothing old is keeping things from building
correctly because I saw a place or two where things did not get rebuild
though something changed in the source tree. With the rebuild of all
motherboards currently being around 10 minutes on this machine speed did
not really care for generating the reports along. This is different if
the tool is used actively in each cycle during development..

> Note: I had to tweak the parser so it would work when I specified where the
> linuxbios tree was.  It was putting single quotes around the pathname
> nad ls was not really fond of './freebios2/'/src/mainboard ....

Oh,.. I had that problem too with the -t option.. Thanks for fixing
this. I will remove the stupid tr -d workaround I used.

Stefan






From stepan at openbios.org  Fri Nov  5 07:32:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Fri Nov  5 07:32:00 2004
Subject: [RFC] linuxbios autobuild
Message-ID: <20041105135541.GA2791@openbios.org>

Hi,

What's missing in the linuxbios autobuild tool?

Regression Testing
------------------
 We might want to regularly (or even on checkin?) use abuild.sh to check
 the LinuxBIOS repository for consistency and open building lots..

 Shall we have a mail sent to the mailinglist/cvs list regularly/on
 checkin?
 We definitely also want a web page with this information, maybe the
 tool should optionally generate HTML/XML reports?

 ... ?

Resulting ROM images
--------------------
 There needs to be a way to specify a per build or at least per platform
 payload. Otherwise no bootable images will result.
 
 Once the images have been proven stable we could offer prebuilt images
 (or have a webfrontend that creates an image from 2 payloads and 2
 linuxbios romimages..

 too lion-hearted?

Development
-----------

 I would love to see the rest of the target config files go away for
 default builds, or have the abuild tool create them easily on the fly.
 This could be nice for testing different scenarios during development as
 well as for end users that don't want to go edit the default
 configuration but still want a different payload etc..

 Ideas?


What's missing?

Stefan




From stepan at openbios.org  Fri Nov  5 08:08:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Fri Nov  5 08:08:00 2004
Subject: [Freebios-cvs] freebios2/util/abuild abuild.sh,1.5,1.6
In-Reply-To: <m3mzxwpl69.fsf@maxwell.lnxi.com>
References: <E1CPzo8-0007Cu-Lp@sc8-pr-cvs1.sourceforge.net> <20041105112230.GA13168@openbios.org> <m3mzxwpl69.fsf@maxwell.lnxi.com>
Message-ID: <20041105143224.GA14938@openbios.org>

* Eric W. Biederman <ebiederman at lnxi.com> [041105 12:52]:
> On powerpc we currently have 3 ports.  I have been concentrating on the
> embeddedplanet ep405pc.  I have been able to coax it all the way
> through the configuration process but I'm not certain how many of the things
> I have done are just hacks at the moment.
 
I've been looking at http://kegel.com/crosstool/ now and I'm waiting for
a gcc 3.4.x for PPC 750 to finish. I'm not sure what target to build
for, but it'll be ok for a try.

> I will report back on what I learn about powerpc compilers when I get one that will
> actually build the powerpc assembly code.  It appears mine currently do not support
> all of the needed powerpc instructions :(

Above script can build for all PPC CPUs from 405 to 970 with preset
scripts

Stefan



From pyro at linuxlabs.com  Fri Nov  5 08:16:01 2004
From: pyro at linuxlabs.com (Steven James)
Date: Fri Nov  5 08:16:01 2004
Subject: ram init
In-Reply-To: <20041104173157.M6580@mail.nexcom.com.tw>
References: <20041104173157.M6580@mail.nexcom.com.tw>
Message-ID: <Pine.LNX.4.58.0411051426120.17125@ucontrol.mobiledns.com>

Greetings,

It's been a while since I've looked at it, but when I last looked, it did
sometimes need power cycled to restart. I worked around that by making the
kernel reboot by writing 0x0e to port 0xcf9. That causes the southbridge
to do a 3 second power off.

G'day,
sjames



On Fri, 5 Nov 2004, Gin Lin wrote:

> Does anyone know if the raminit.c under intel/E7501 is stable enough? I am
> having a problem with the system reseting when it jumps to the first address
> in the ram. Could the procedures of writing NorthBrige registers have
> problems?
>
> thanks,
> Gin
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>

||||| |||| |||||||||||||  |||
by Linux Labs International, Inc.
   Steven James, CTO

55 Marietta Street
Suite 1830
Atlanta, Ga 30303
866 824 9737 support



From rminnich at lanl.gov  Fri Nov  5 09:09:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Nov  5 09:09:00 2004
Subject: [RFC] linuxbios autobuild
In-Reply-To: <20041105135541.GA2791@openbios.org>
References: <20041105135541.GA2791@openbios.org>
Message-ID: <Pine.LNX.4.58.0411050832360.3800@linux.site>


On Fri, 5 Nov 2004, Stefan Reinauer wrote:

> What's missing?

create a page for a web server so that anyone can view the overnight 
results and the last 7 days or so results.

ron


From stepan at openbios.org  Fri Nov  5 09:53:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Fri Nov  5 09:53:00 2004
Subject: [Freebios-cvs] freebios2/util/abuild abuild.sh,1.5,1.6
In-Reply-To: <m3mzxwpl69.fsf@maxwell.lnxi.com>
References: <E1CPzo8-0007Cu-Lp@sc8-pr-cvs1.sourceforge.net> <20041105112230.GA13168@openbios.org> <m3mzxwpl69.fsf@maxwell.lnxi.com>
Message-ID: <20041105161716.GA3329@openbios.org>

* Eric W. Biederman <ebiederman at lnxi.com> [041105 12:52]:
> On powerpc we currently have 3 ports.  I have been concentrating on the
> embeddedplanet ep405pc.  I have been able to coax it all the way
> through the configuration process but I'm not certain how many of the things
> I have done are just hacks at the moment.
> 
> In any event one thing I have clearly found is that abuild.sh is specifying 2 options
> that the ep405pc atleast does not implement.  USE_FALLBACK_IMAGE and ROM_IMAGE_SIZE.

Do you have an Options.lb for those ports? my cross compiler seems to
work quite nicely until now so I can join the boat of cross linuxbios
builders..


Stefan




From ollie at lanl.gov  Fri Nov  5 10:12:00 2004
From: ollie at lanl.gov (ollie at lanl.gov)
Date: Fri Nov  5 10:12:00 2004
Subject: 8131 and 8151 in static.c
In-Reply-To: <m3d5yt7xk4.fsf@maxwell.lnxi.com>
References: <1099614350.3373.174.camel@exponential.lanl.gov>
    <m3d5yt7xk4.fsf@maxwell.lnxi.com>
Message-ID: <56257.128.165.0.81.1099670185.squirrel@128.165.0.81>

> Li-Ta Lo <ollie at lanl.gov> writes:
>
>> Eric,
>>
>> Why there is no
>> 	struct southbridge_amd_amd8131_config
>> or
>> 	struct southbridge_amd_amd8151_config
>
> Because they don't need an enable_dev method.
>
>> in ter static.c although we have
>> 	chip southbridge/amd/amd8131
>> and
>> 	chip southbridge/amd/amd8151
>>
>> in the Config.lb?
>
> The chips are found by their pci_ids.
>
>> There is no
>> 	struct chip_operations southbridge_amd_amd8131_ops
>> nor
>> 	struct chip_operations southbridge_amd_amd8151_ops
>> nether.
>
> Currently struct xxxxx_config and struct chip_operations xxx_ops
> are tied together.  If you have you have both.
>
> We don't currently require a struct chip_operations.
>
> I have not thought enough about this to know if it is a good or
> a bad thing.  It is simply the way it was done and I have not changed it.
> If we always required this we could remove the config directive
> from the configuration language.
>
> Eric
>

How does the config tool tell if there is chip_operation or not ?
How does it know to generate struct xxx_config for northbridge
but not the southbridge?

Ollie



From rsmith at bitworks.com  Fri Nov  5 10:21:01 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Fri Nov  5 10:21:01 2004
Subject: [Freebios-cvs] freebios2/util/abuild abuild.sh,1.5,1.6
In-Reply-To: <20041105143224.GA14938@openbios.org>
References: <E1CPzo8-0007Cu-Lp@sc8-pr-cvs1.sourceforge.net> <20041105112230.GA13168@openbios.org> <m3mzxwpl69.fsf@maxwell.lnxi.com> <20041105143224.GA14938@openbios.org>
Message-ID: <418BADFB.6070007@bitworks.com>

Stefan Reinauer wrote:

>>On powerpc we currently have 3 ports.  I have been concentrating on the
>>embeddedplanet ep405pc.  I have been able to coax it all the way
>>through the configuration process but I'm not certain how many of the things
>>I have done are just hacks at the moment.
> 
>  
> I've been looking at http://kegel.com/crosstool/ now and I'm waiting for
> a gcc 3.4.x for PPC 750 to finish. I'm not sure what target to build
> for, but it'll be ok for a try.

crosstool is the way to go.  It's really important in the ppc stuff to 
get all the right patches to for a working setup.

There are many on the embedded lists I'm on who claim "real developers 
build thier own toolchain" but also in those circles cross tool is 
considered to be the defacto reference for building a working cross 
toolchain.

-- 
Richard A. Smith




From YhLu at tyan.com  Fri Nov  5 11:04:01 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Nov  5 11:04:01 2004
Subject: Board hangs after soft_reset() in auto.c
Message-ID: <3174569B9743D511922F00A0C943142306BA2D08@TYANWEB>

Amdk8_scan_chains will clear E0... E8 at first.

YH

-----Original Message-----
From: Liu Tao [mailto:liutao at safe-mail.net] 
Sent: Friday, November 05, 2004 12:26 AM
To: YhLu
Cc: Eric W. Biederman; LinuxBIOS
Subject: Re: Board hangs after soft_reset() in auto.c

YhLu wrote:

 >Which stage auto.c
 >E0: 0xff010003 -->  0x06000003
 >E4: 0x09070103 -->  0x09070103
 >E8:              -->   0x0c0a0203
 >
 >YH

In auto.c setup_myboard_resource_map():
E0: <- 0x06000003
E4: <- 0x09070103
E8: <- 0x0c0a0203

then in C part amdk8_scan_chains():
E0: <- 0xff010003 (max=0)    /* E0 overlaps E4/E8 ? */
max = hypertransport_scan_chain(link0, max);
E0: <- 0x06010003 (imagin max=0x6)
E4: <- 0xff070003        /* E4 overlaps E8 ? */
max = hypertransport_scan_chain(link1, max);
E4: <- 0x09070003 (imagin max=0x9)
E8: <- 0xff0a0003
max = hypertransport_scan_chain(link2, max);
E8: <- 0x0c0a0003 (imagin max=0xc)

Regards,
Liu Tao




From YhLu at tyan.com  Fri Nov  5 11:47:01 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Nov  5 11:47:01 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
Message-ID: <3174569B9743D511922F00A0C943142306BA2D16@TYANWEB>

Forget about that.

Why separate root_complex from amdk8/northbridge.c to
root_complex/root_complex.c

YH

-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Thursday, November 04, 2004 8:53 PM
To: YhLu
Cc: Ronald G. Minnich; Li-Ta Lo; LinuxBIOS
Subject: Re: Removing device driver code in mainboard.c for Tyan boards?

YhLu <YhLu at tyan.com> writes:

> No, debug_dev can be PCI_DOMAIN and APIC's sibling and one child dev_root
in
> link0.

So why the question about dev_root link 1 and 2?

Eric


From YhLu at tyan.com  Fri Nov  5 11:54:01 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Nov  5 11:54:01 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
Message-ID: <3174569B9743D511922F00A0C943142306BA2D17@TYANWEB>

Share get_fx_devs and f1_read_config32?

YH

-----Original Message-----
From: YhLu 
Sent: Friday, November 05, 2004 10:17 AM
To: ebiederman at lnxi.com
Cc: Ronald G. Minnich; Li-Ta Lo; LinuxBIOS
Subject: RE: Removing device driver code in mainboard.c for Tyan boards?

Forget about that.

Why separate root_complex from amdk8/northbridge.c to
root_complex/root_complex.c

YH

-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Thursday, November 04, 2004 8:53 PM
To: YhLu
Cc: Ronald G. Minnich; Li-Ta Lo; LinuxBIOS
Subject: Re: Removing device driver code in mainboard.c for Tyan boards?

YhLu <YhLu at tyan.com> writes:

> No, debug_dev can be PCI_DOMAIN and APIC's sibling and one child dev_root
in
> link0.

So why the question about dev_root link 1 and 2?

Eric
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From ebiederman at lnxi.com  Fri Nov  5 12:07:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Nov  5 12:07:01 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
In-Reply-To: <3174569B9743D511922F00A0C943142306BA2D16@TYANWEB>
References: <3174569B9743D511922F00A0C943142306BA2D16@TYANWEB>
Message-ID: <m31xf8b127.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Forget about that.

Ok.
 
> Why separate root_complex from amdk8/northbridge.c to
> root_complex/root_complex.c

I haven't because the code is to intertwined in northbridge.c and
it would be likely be a maintenance problem to do so.

Eric


From YhLu at tyan.com  Fri Nov  5 12:20:00 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Nov  5 12:20:00 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
Message-ID: <3174569B9743D511922F00A0C943142306BA2D22@TYANWEB>

What does "config chip.h" in Config.lb use for?

It seems it is not necessary?

Regards

YH

-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Friday, November 05, 2004 10:31 AM
To: YhLu
Cc: Ronald G. Minnich; Li-Ta Lo; LinuxBIOS
Subject: Re: Removing device driver code in mainboard.c for Tyan boards?

YhLu <YhLu at tyan.com> writes:

> Forget about that.

Ok.
 
> Why separate root_complex from amdk8/northbridge.c to
> root_complex/root_complex.c

I haven't because the code is to intertwined in northbridge.c and
it would be likely be a maintenance problem to do so.

Eric


From YhLu at tyan.com  Fri Nov  5 12:26:01 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Nov  5 12:26:01 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
Message-ID: <3174569B9743D511922F00A0C943142306BA2D26@TYANWEB>

Static.c include comes from it.

YH

-----Original Message-----
From: YhLu 
Sent: Friday, November 05, 2004 10:44 AM
To: 'ebiederman at lnxi.com'
Cc: Ronald G. Minnich; Li-Ta Lo; LinuxBIOS
Subject: RE: Removing device driver code in mainboard.c for Tyan boards?

What does "config chip.h" in Config.lb use for?

It seems it is not necessary?

Regards

YH

-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Friday, November 05, 2004 10:31 AM
To: YhLu
Cc: Ronald G. Minnich; Li-Ta Lo; LinuxBIOS
Subject: Re: Removing device driver code in mainboard.c for Tyan boards?

YhLu <YhLu at tyan.com> writes:

> Forget about that.

Ok.
 
> Why separate root_complex from amdk8/northbridge.c to
> root_complex/root_complex.c

I haven't because the code is to intertwined in northbridge.c and
it would be likely be a maintenance problem to do so.

Eric


From YhLu at tyan.com  Fri Nov  5 13:04:00 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Nov  5 13:04:00 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
Message-ID: <3174569B9743D511922F00A0C943142306BA2D34@TYANWEB>

Eric,

If the chip_ops has no .name, then should use
if CONFIG_CHIP_NAME 
	config chip.h 
end

also .c include that chip_ops
#if CONFIG_CHIP_NAME
...chip_ops defininition
#endif

Regards

Such as norththbridge, socket, mainboard(root).

YH

-----Original Message-----
From: YhLu 
Sent: Friday, November 05, 2004 10:50 AM
To: ebiederman at lnxi.com
Cc: Ronald G. Minnich; Li-Ta Lo; LinuxBIOS
Subject: RE: Removing device driver code in mainboard.c for Tyan boards?

What does "config chip.h" in Config.lb use for?

It seems it is not necessary?

Regards

YH

-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Friday, November 05, 2004 10:31 AM
To: YhLu
Cc: Ronald G. Minnich; Li-Ta Lo; LinuxBIOS
Subject: Re: Removing device driver code in mainboard.c for Tyan boards?

YhLu <YhLu at tyan.com> writes:

> Forget about that.

Ok.
 
> Why separate root_complex from amdk8/northbridge.c to
> root_complex/root_complex.c

I haven't because the code is to intertwined in northbridge.c and
it would be likely be a maintenance problem to do so.

Eric
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From stepan at openbios.org  Fri Nov  5 14:28:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Fri Nov  5 14:28:01 2004
Subject: [Freebios-cvs] freebios2/util/abuild abuild.sh,1.5,1.6
In-Reply-To: <418BADFB.6070007@bitworks.com>
References: <E1CPzo8-0007Cu-Lp@sc8-pr-cvs1.sourceforge.net> <20041105112230.GA13168@openbios.org> <m3mzxwpl69.fsf@maxwell.lnxi.com> <20041105143224.GA14938@openbios.org> <418BADFB.6070007@bitworks.com>
Message-ID: <20041105205201.GA7057@openbios.org>

* Richard Smith <rsmith at bitworks.com> [041105 17:44]:
> >I've been looking at http://kegel.com/crosstool/ now and I'm waiting for
> >a gcc 3.4.x for PPC 750 to finish. I'm not sure what target to build
> >for, but it'll be ok for a try.
> 
> crosstool is the way to go.  It's really important in the ppc stuff to 
> get all the right patches to for a working setup.
 
good, thanks for this confirmation. There's also devkitPPC, but it is
mainly used for console development. Worse than x86, you'd never want
to use gcc on non-x86 platforms without patches. I remember the big fuzz
gcc 2.96 "release" was pretty usable after applying about 250 patches ;)
(better than any compiler on axp before)

> There are many on the embedded lists I'm on who claim "real developers 
> build thier own toolchain" but also in those circles cross tool is 
> considered to be the defacto reference for building a working cross 
> toolchain.

That is true, to some extent, for toolchain developers. Real developers
also develop their own OS before writing a letter.. But the best ones
develop firmware anyways ;)

Stefan




From YhLu at tyan.com  Fri Nov  5 14:50:00 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Nov  5 14:50:00 2004
Subject: PCI_DOMAIN ??
Message-ID: <3174569B9743D511922F00A0C943142306BA2D3B@TYANWEB>

Create dummy device, and assign devfn to it, then....

YH

-----Original Message-----
From: Li-Ta Lo [mailto:ollie at lanl.gov] 
Sent: Wednesday, November 03, 2004 2:59 PM
To: Eric W. Biederman
Cc: LinuxBIOS
Subject: Re: PCI_DOMAIN ??

On Wed, 2004-11-03 at 15:51, Eric W. Biederman wrote:
> So my immediate suggestion would be to call pci_set_method from the
pci_domain's
> scan_bus method before it does anything.  We can worry about the rest
later.
> 

Isn't the root_dev::scan_bus() called before pci_domain::scan_bus() ? 
What if root_dev::scan_bus() wants to access PCI CS ?

Ollie


_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From YhLu at tyan.com  Fri Nov  5 15:41:01 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Nov  5 15:41:01 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
Message-ID: <3174569B9743D511922F00A0C943142306BA2D42@TYANWEB>

I changed e7501 to use root_complex too.

Regards

YH

-----Original Message-----
From: YhLu 
Sent: Friday, November 05, 2004 11:34 AM
To: YhLu; ebiederman at lnxi.com
Cc: Ronald G. Minnich; Li-Ta Lo; LinuxBIOS
Subject: RE: Removing device driver code in mainboard.c for Tyan boards?

Eric,

If the chip_ops has no .name, then should use
if CONFIG_CHIP_NAME 
	config chip.h 
end

also .c include that chip_ops
#if CONFIG_CHIP_NAME
...chip_ops defininition
#endif

Regards

Such as norththbridge, socket, mainboard(root).

YH


From stepan at openbios.org  Fri Nov  5 17:36:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Fri Nov  5 17:36:00 2004
Subject: [Freebios-cvs] freebios2/util/abuild abuild.sh,1.5,1.6
In-Reply-To: <20041105143224.GA14938@openbios.org>
References: <E1CPzo8-0007Cu-Lp@sc8-pr-cvs1.sourceforge.net> <20041105112230.GA13168@openbios.org> <m3mzxwpl69.fsf@maxwell.lnxi.com> <20041105143224.GA14938@openbios.org>
Message-ID: <20041105235946.GA5626@openbios.org>

* Stefan Reinauer <stepan at openbios.org> [041105 15:32]:
> * Eric W. Biederman <ebiederman at lnxi.com> [041105 12:52]:
> > On powerpc we currently have 3 ports.  I have been concentrating on the
> > embeddedplanet ep405pc.  I have been able to coax it all the way
> > through the configuration process but I'm not certain how many of the things
> > I have done are just hacks at the moment.
>  
> I've been looking at http://kegel.com/crosstool/ now and I'm waiting for
> a gcc 3.4.x for PPC 750 to finish. I'm not sure what target to build
> for, but it'll be ok for a try.

/opt/crosstool/powerpc-7450-linux-gnu/gcc-3.4.1-glibc-2.3.3/lib/gcc/powerpc-7450-linux-gnu/3.4.1/include/limits.h:122:61: no include path in which to search for limits.h

Weird.. has anyone seen this one before? I get it from ppc div64.h
because of nostdinc it seems...

Stefan




From ebiederman at lnxi.com  Fri Nov  5 18:35:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Nov  5 18:35:01 2004
Subject: [Freebios-cvs] freebios2/util/abuild abuild.sh,1.5,1.6
In-Reply-To: <20041105235946.GA5626@openbios.org>
References: <E1CPzo8-0007Cu-Lp@sc8-pr-cvs1.sourceforge.net>
	<20041105112230.GA13168@openbios.org>
	<m3mzxwpl69.fsf@maxwell.lnxi.com>
	<20041105143224.GA14938@openbios.org>
	<20041105235946.GA5626@openbios.org>
Message-ID: <m3zn1vn66q.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at openbios.org> writes:

> * Stefan Reinauer <stepan at openbios.org> [041105 15:32]:
> > * Eric W. Biederman <ebiederman at lnxi.com> [041105 12:52]:
> > > On powerpc we currently have 3 ports.  I have been concentrating on the
> > > embeddedplanet ep405pc.  I have been able to coax it all the way
> > > through the configuration process but I'm not certain how many of the things
> 
> > > I have done are just hacks at the moment.
> >  
> > I've been looking at http://kegel.com/crosstool/ now and I'm waiting for
> > a gcc 3.4.x for PPC 750 to finish. I'm not sure what target to build
> > for, but it'll be ok for a try.
> 
> /opt/crosstool/powerpc-7450-linux-gnu/gcc-3.4.1-glibc-2.3.3/lib/gcc/powerpc-7450-linux-gnu/3.4.1/include/limits.h:122:61:
> no include path in which to search for limits.h
> 
> 
> Weird.. has anyone seen this one before? I get it from ppc div64.h
> because of nostdinc it seems...

That is odd.  Although it seems reasonable.

I can successfully build that part with gcc-3.4.1 so I don't know what is going on.
If you want to add a ppc limits.h feel free.  I'm not certain if that header file
should be should come with the compiler or not...

Actually that feels like a gcc bug.  Because it is your limits.h that cannot find
limits.h?

Eric




From ebiederman at lnxi.com  Fri Nov  5 18:49:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Nov  5 18:49:01 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
In-Reply-To: <3174569B9743D511922F00A0C943142306BA2D42@TYANWEB>
References: <3174569B9743D511922F00A0C943142306BA2D42@TYANWEB>
Message-ID: <m3pt2rn5k8.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> I changed e7501 to use root_complex too.

Could we please reserve this construct for chipsets
with multiple northbridges?

I think it is just going to be extra noise on a
simple chipset like the e7501.

And since the e7501 is an example to a certain extent having it
doing extra work be confusing and a pain.

> If the chip_ops has no .name, then should use
> if CONFIG_CHIP_NAME 
> 	config chip.h 
> end
> 
> also .c include that chip_ops
> #if CONFIG_CHIP_NAME
> ...chip_ops defininition
> #endif
> 
> Regards
> 
> Such as norththbridge, socket, mainboard(root).

They can.  But I am about to suggest simply removing the config
directive, and assuming the ``config chip.h'' is always given.  The
overhead is almost zero for a zero filled structure.  And always
requiring a chip.h would tend to simply the process of writing code
for a new chip.

Eric


From YhLu at tyan.com  Fri Nov  5 19:06:01 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Nov  5 19:06:01 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
Message-ID: <3174569B9743D511922F00A0C943142306BA2D6E@TYANWEB>

1.
root_complex
	pci_domain
		NB
			SB
		End
	End
	Apic
End 

Is more understanding even for one MC MB.

2. 
Without " config chip.h"
The corresponding device chip_ops field will be 0, and not to some ......ops
(all zero).

3. another is 
	if not define " uses CONFIG_CHIP_NAME" in MB Option.lb
	and use "if CONFIG_CHIP_NAME  config chip.h end
	the config.g will be report CONFIG_CHIP_NAME is not defined, just
some other strang reporting.

Regards

YH

-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Friday, November 05, 2004 5:13 PM
To: YhLu
Cc: 'Ronald G. Minnich'; 'Li-Ta Lo'; 'LinuxBIOS'
Subject: Re: Removing device driver code in mainboard.c for Tyan boards?

YhLu <YhLu at tyan.com> writes:

> I changed e7501 to use root_complex too.

Could we please reserve this construct for chipsets
with multiple northbridges?

I think it is just going to be extra noise on a
simple chipset like the e7501.

And since the e7501 is an example to a certain extent having it
doing extra work be confusing and a pain.

> If the chip_ops has no .name, then should use
> if CONFIG_CHIP_NAME 
> 	config chip.h 
> end
> 
> also .c include that chip_ops
> #if CONFIG_CHIP_NAME
> ...chip_ops defininition
> #endif
> 
> Regards
> 
> Such as norththbridge, socket, mainboard(root).

They can.  But I am about to suggest simply removing the config
directive, and assuming the ``config chip.h'' is always given.  The
overhead is almost zero for a zero filled structure.  And always
requiring a chip.h would tend to simply the process of writing code
for a new chip.

Eric


From stepan at openbios.org  Sat Nov  6 09:03:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Sat Nov  6 09:03:00 2004
Subject: PPC types
In-Reply-To: <m3pt2rn5k8.fsf@maxwell.lnxi.com>
References: <3174569B9743D511922F00A0C943142306BA2D42@TYANWEB> <m3pt2rn5k8.fsf@maxwell.lnxi.com>
Message-ID: <20041106152713.GA29300@openbios.org>

For PPC there are two types of lb_memory_range defined. 

which one should be used? (uint64_t is save probably)

void lb_memory_range(struct lb_memory *mem,
        uint32_t type, unsigned long startk, unsigned long sizek);

void lb_memory_range(struct lb_memory *mem,
                        uint32_t type, uint64_t start, uint64_t size)

Eric,

limits.h is pretty much overkill in div64.h, we just need ULONG_MAX
which we could place somewhere within our arch dependent files...

Stefan




From sagivy at 3vium.com  Sun Nov  7 10:22:01 2004
From: sagivy at 3vium.com (Sagiv Yefet)
Date: Sun Nov  7 10:22:01 2004
Subject: tyan S2850 - optimal performance
Message-ID: <4A3D5F6DC9406A4DBE93D9BA8F07E4BB22D6C8@cronos.trivium>

Hello, 
  I have the TYAN s2850 board and I am running with Linux bios.
  I want to use it in optimal performance.
  Are there any parameters that I could change?
  Does someone know about the optimal parameters in TYAN S2850 board?
 
Thanks,
Sagiv
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20041107/ab911804/attachment.html>

From stepan at openbios.org  Sun Nov  7 10:29:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Sun Nov  7 10:29:01 2004
Subject: tyan S2850 - optimal performance
In-Reply-To: <4A3D5F6DC9406A4DBE93D9BA8F07E4BB22D6C8@cronos.trivium>
References: <4A3D5F6DC9406A4DBE93D9BA8F07E4BB22D6C8@cronos.trivium>
Message-ID: <20041107165303.GA14507@openbios.org>

* Sagiv Yefet <sagivy at 3vium.com> [041107 17:52]:
> Hello, 
>   I have the TYAN s2850 board and I am running with Linux bios.
>   I want to use it in optimal performance.
>   Are there any parameters that I could change?
>   Does someone know about the optimal parameters in TYAN S2850 board?

LinuxBIOS ought to configure the board with optimal performance
parameters already. Is there anything you are missing?

Stefan



From cro_marmot at comcast.net  Sun Nov  7 11:57:01 2004
From: cro_marmot at comcast.net (David Hendricks)
Date: Sun Nov  7 11:57:01 2004
Subject: tyan S2850 - optimal performance
In-Reply-To: <4A3D5F6DC9406A4DBE93D9BA8F07E4BB22D6C8@cronos.trivium>
References: <4A3D5F6DC9406A4DBE93D9BA8F07E4BB22D6C8@cronos.trivium>
Message-ID: <20041107112315.102c0962@sunder>

What exactly do you mean by 'optimal' performance? You mean like
tweaking your memory timings or something?

On Sun, 7 Nov 2004 18:52:15 +0200
"Sagiv Yefet" <sagivy at 3vium.com> wrote:

> Hello, 
>   I have the TYAN s2850 board and I am running with Linux bios.
>   I want to use it in optimal performance.
>   Are there any parameters that I could change?
>   Does someone know about the optimal parameters in TYAN S2850 board?
>  
> Thanks,
> Sagiv
> 


From adam at cfar.umd.edu  Sun Nov  7 13:05:00 2004
From: adam at cfar.umd.edu (Adam Sulmicki)
Date: Sun Nov  7 13:05:00 2004
Subject: xen,bproc and grub 
In-Reply-To: <20041101173949.B90066-100000@www.missl.cs.umd.edu>
Message-ID: <20041107052720.H45090-100000@www.missl.cs.umd.edu>

> Thus I'm trying to figure out how I could boot xen/linux-2.6.8.1-xen0 duo
> on nodes. Are there any other options to boot it besides using grub[4][5]?
> and preferably does not rquire multiboot [6].
>
> I figure out I that maybe could load xen.gz [7] using FILO, Kexec, or
> maybe etherboot but it still would not load linux kernel in turn (because
> of the dependency on multiboot).

ok, so I I grabbed kexec-tools-1.98, then I patched it with this patch

	http://www.tjd.phlegethon.org/software/kexec-multiboot.patch

and I got an kexec kernel that supports multiboot. Now the fun thing is
that on laptop it just works fine, as it should, but on an another machine
the same setup results in reboot instead of starting a new kernel. weird
stuff.

ideas ?

monte: entry point (protected mode): 0x100000
Linux version 2.6.8.1-kexec-ituner (root at redbull) (gcc version 3.3.3 (SuSE Linux)) #6 Sat Nov 6 14:58:34 MST 2004
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 0000000000000b40 (reserved)
 BIOS-e820: 0000000000000b40 - 00000000000a0000 (usable)
 BIOS-e820: 0000000000100000 - 0000000010000000 (usable)
256MB LOWMEM available.
DMI not present.
ACPI: Unable to locate RSDP
Built 1 zonelists
Kernel command line: console=ttyS0,19200 root=/dev/nfs nfsroot=10.0.10.5:/ ip=10.0.10.103:10.0.10.5:10.0.10.5:255.255.255.0:node2:eth0:off init=/bin/sh
Initializing CPU#0
PID hash table entries: 2048 (order 11: 16384 bytes)
Detected 533.502 MHz processor.
Using tsc for high-res timesource
Console: colour dummy device 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 255300k/262144k available (1108k kernel code, 6100k reserved, 371k data, 100k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay loop... 1048.57 BogoMIPS
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 bytes/line)
CPU: L2 Cache: 64K (32 bytes/line)
CPU: Centaur VIA Samuel 2 stepping 03
Checking 'hlt' instruction... OK.
Checking for popad bug... OK.
checking if image is initramfs... it is
Freeing initrd memory: 1588k freed
NET: Registered protocol family 16
PCI: Using configuration type 1
Linux Plug and Play Support v0.97 (c) Adam Belay
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
PCI: Using IRQ router VIA [1106/8231] at 0000:00:11.0
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
via-rhine.c:v1.10-LK1.1.20-2.6 May-23-2004 Written by Donald Becker
PCI: Found IRQ 11 for device 0000:00:12.0
IRQ routing conflict for 0000:00:11.2, have irq 12, want irq 11
IRQ routing conflict for 0000:00:11.3, have irq 12, want irq 11
eth0: VIA Rhine II at 0x1800, 00:40:63:cc:0e:d9, IRQ 11.
eth0: MII PHY found at address 1, status 0x786d advertising 05e1 Link 45e1.
mice: PS/2 mouse device common for all mice
i8042.c: Can't read CTR while initializing i8042.
NET: Registered protocol family 2
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 32768)
NET: Registered protocol family 17
eth0: Setting full-duplex based on MII #1 link partner capability of 45e1.
IP-Config: Complete:
      device=eth0, addr=10.0.10.103, mask=255.255.255.0, gw=10.0.10.5,
     host=node2, domain=, nis-domain=(none),
     bootserver=10.0.10.5, rootserver=10.0.10.5, rootpath=
Looking up port of RPC 100003/2 on 10.0.10.5
Looking up port of RPC 100005/1 on 10.0.10.5
VFS: Mounted root (nfs filesystem) readonly.
Freeing unused kernel memory: 100k freed

sh-2.05b#

sh-2.05b# /sbin/kexec

No kernel specified
kexec 1.98 released 15 September 2004
Usage: kexec [OPTION]... [kernel]
Directly reboot into a new kernel

 -h, --help        Print this help.
 -v, --version     Print the version of kexec.
 -f, --force       Force an immediate kexec, don't call shutdown.
 -x, --no-ifdown   Don't bring down network interfaces.
                   (if used, must be last option specified)
 -l, --load        Load the new kernel into the current kernel.
 -u, --unload      Unload the current kexec target kernel.
 -e, --exec        Execute a currently loaded kernel.
 -t, --type=TYPE   Specify the new kernel is of this type.

Supported kernel file types and options:
multiboot-x86
    --command-line=STRING        Set the kernel command line to STRING.
    --module="MOD arg1 arg2..."  Load module MOD with command-line "arg1..."
                                 (can be used multiple times).
    --reset-vga                  Include code to set VGA text mode 3.
                                 (use this flag at load time).
elf32-x86
    --command-line=STRING Set the kernel command line to STRING
    --append=STRING       Set the kernel command line to STRING
    --initrd=FILE         Use FILE as the kernel's initial ramdisk.
    --ramdisk=FILE        Use FILE as the kernel's initial ramdisk.
    --args-linux          Pass linux kernel style options
    --args-elf            Pass elf boot notes
bzImage
-d, --debug               Enable debugging to help spot a failure.
    --real-mode           Use the kernels real mode entry point.
    --command-line=STRING Set the kernel command line to STRING.
    --append=STRING       Set the kernel command line to STRING.
    --initrd=FILE         Use FILE as the kernel's initial ramdisk.
    --ramdisk=FILE        Use FILE as the kernel's initial ramdisk.

sh-2.05b#
sh-2.05b# /sbin/kexec --load /boot/xen-full --type=multiboot-x86 \
>                 --command-line="dom0_mem=65536" \
>                 --module="/boot/vmlinuz-2.6.8.1-xen0-full
root=/dev/hda1"
Cannot open /proc/iomem: No such file or directory
Could not get memory layout

sh-2.05b#

sh-2.05b# mount /proc

sh-2.05b#

sh-2.05b# cat /proc/iomem

00000000-00000b3f : reserved
00000b40-0009ffff : System RAM
000a0000-000bffff : Video RAM area
000f0000-000fffff : System ROM
00100000-0fffffff : System RAM
  00100000-00215068 : Kernel code
  00215069-00271e9f : Kernel data
feb00000-feb000ff : 0000:00:12.0
  feb00000-feb000ff : via-rhine

sh-2.05b#

sh-2.05b# cat /proc/mounts

rootfs / rootfs rw 0 0
/dev/root / nfs ro,v2,rsize=4096,wsize=4096,hard,udp,nolock,addr=10.0.10.5 0 0 proc /proc proc rw,nodiratime 0 0

sh-2.05b# touch /x

touch: cannot touch `/x': Read-only file system

sh-2.05b# /sbin/kexec --load /boot/xen-full --type=multiboot-x86 \
>                 --command-line="dom0_mem=65536" \
>                 --module="/boot/vmlinuz-2.6.8.1-xen0-full root=/dev/hda1"
kexec_load succeeded (multiboot-x86)

sh-2.05b# /sbin/kexec -e

Starting new kernel


LinuxBIOS-1.1.6.0Fallback Wed Mar 24 14:39:17 MST 2004 starting...
vt8601 init starting
Slot 00 is SDRAM 10000000 bytes
Slot 01smbus_error: 04
Device Error
 is empty
Slot 02smbus_error: 04
Device Error
 is empty
Slot 03smbus_error: 04
Device Error
 is empty
vt8601 done
LinuxBIOS-1.1.6.0Fallback Wed Mar 24 14:39:17 MST 2004 booting...





From ebiederman at lnxi.com  Sun Nov  7 14:59:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Sun Nov  7 14:59:00 2004
Subject: tyan S2850 - optimal performance
In-Reply-To: <4A3D5F6DC9406A4DBE93D9BA8F07E4BB22D6C8@cronos.trivium>
References: <4A3D5F6DC9406A4DBE93D9BA8F07E4BB22D6C8@cronos.trivium>
Message-ID: <m3is8h8iat.fsf@maxwell.lnxi.com>

"Sagiv Yefet" <sagivy at 3vium.com> writes:

> Hello, 
>   I have the TYAN s2850 board and I am running with Linux bios.
>   I want to use it in optimal performance.
>   Are there any parameters that I could change?
>   Does someone know about the optimal parameters in TYAN S2850 board?


Most of the options are options to lower the performance to help
track down bad hardware.

If you have 4GiB or more of RAM in the machine and are running a 64bit kernel
there are a few cases where the resource layout can be improved
depending on what hardware you have plugged in.

And if you have PCI-X cards it was recently brought to my attention
that we are not optimizing that bus to the fullest extent possible.

All of those things are currently on my TODO list and should be fixed
shortly.  And they are all Opteron board independent.

Beyond that using things like PC3200 memory and a recent cpu should
are more likely to increase performance.

Given that one of the largest LinuxBIOS markets is in high performance
computing it would be silly to deliberately leave something suboptimal.

Eric


From liutao at safe-mail.net  Mon Nov  8 07:25:01 2004
From: liutao at safe-mail.net (Liu Tao)
Date: Mon Nov  8 07:25:01 2004
Subject: Board hangs after soft_reset() in auto.c
In-Reply-To: <3174569B9743D511922F00A0C943142306BA2D08@TYANWEB>
References: <3174569B9743D511922F00A0C943142306BA2D08@TYANWEB>
Message-ID: <418F79E6.3060202@safe-mail.net>

Found in pci_domain_scan_bus().
Thanks.

YhLu wrote:

>Amdk8_scan_chains will clear E0... E8 at first.
>
>YH
>
>-----Original Message-----
>From: Liu Tao [mailto:liutao at safe-mail.net] 
>Sent: Friday, November 05, 2004 12:26 AM
>To: YhLu
>Cc: Eric W. Biederman; LinuxBIOS
>Subject: Re: Board hangs after soft_reset() in auto.c
>
>YhLu wrote:
>
> >Which stage auto.c
> >E0: 0xff010003 -->  0x06000003
> >E4: 0x09070103 -->  0x09070103
> >E8:              -->   0x0c0a0203
> >
> >YH
>
>In auto.c setup_myboard_resource_map():
>E0: <- 0x06000003
>E4: <- 0x09070103
>E8: <- 0x0c0a0203
>
>then in C part amdk8_scan_chains():
>E0: <- 0xff010003 (max=0)    /* E0 overlaps E4/E8 ? */
>max = hypertransport_scan_chain(link0, max);
>E0: <- 0x06010003 (imagin max=0x6)
>E4: <- 0xff070003        /* E4 overlaps E8 ? */
>max = hypertransport_scan_chain(link1, max);
>E4: <- 0x09070003 (imagin max=0x9)
>E8: <- 0xff0a0003
>max = hypertransport_scan_chain(link2, max);
>E8: <- 0x0c0a0003 (imagin max=0xc)
>
>Regards,
>Liu Tao
>
>
>_______________________________________________
>Linuxbios mailing list
>Linuxbios at clustermatic.org
>http://www.clustermatic.org/mailman/listinfo/linuxbios
>
>.
>
>  
>



From liutao at safe-mail.net  Mon Nov  8 07:30:01 2004
From: liutao at safe-mail.net (Liu Tao)
Date: Mon Nov  8 07:30:01 2004
Subject: LinuxBIOS boots
Message-ID: <418F7B11.1070503@safe-mail.net>

It's really exciting :)
Does etherboot support AMD8111 ethernet controller?

Regards,
Liu Tao

==========================



LinuxBIOS-1.1.7.0-Fallback ? 11? 8 15:59:58 CST 2004 starting...
setting up resource map....done.
coherent_ht_finalize
done
ht reset -


LinuxBIOS-1.1.7.0-Fallback ? 11? 8 15:59:58 CST 2004 starting...
setting up resource map....done.
coherent_ht_finalize
done
Ram1.00
Ram2.00
Ram3
Initializing memory: done
Clearing initial memory region: done
Ram4
Copying LinuxBIOS to ram.
Jumping to LinuxBIOS.
LinuxBIOS-1.1.7.0-Fallback ? 11? 8 15:59:58 CST 2004 booting...
Enumerating buses...
PCI_DOMAIN: 0000 enabled
APIC_CLUSTER: 0 enabled
PNP: 0000.0 enabled
PNP: 0000.1 disabled
PNP: 0000.2 disabled
PNP: 0000.3 enabled
PCI: pci_scan_bus for bus 0
PCI: 00:18.0 [1022/1100] bus ops
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] ops
PCI: 00:18.3 [1022/1103] enabled
PCI: 01:01.0 [1022/7450] enabled next_unitid: 0003
HyperT reset not needed
PCI: pci_scan_bus for bus 1
PCI: 01:01.0 [1022/7450] bus ops
PCI: 01:01.0 [1022/7450] enabled
PCI: 01:01.1 [1022/7451] ops
PCI: 01:01.1 [1022/7451] enabled
PCI: 01:02.0 [1022/7450] bus ops
PCI: 01:02.0 [1022/7450] enabled
PCI: 01:02.1 [1022/7451] ops
PCI: 01:02.1 [1022/7451] enabled
PCI: pci_scan_bus for bus 2
PCI: pci_scan_bus returning with max=02
PCI: pci_scan_bus for bus 3
PCI: pci_scan_bus returning with max=03
PCI: pci_scan_bus returning with max=03
PCI: 04:01.0 [1022/7450] enabled next_unitid: 0003
PCI: 04:03.0 [1022/7460] enabled next_unitid: 0007
HyperT reset not needed
PCI: pci_scan_bus for bus 4
PCI: 04:01.0 [1022/7450] bus ops
PCI: 04:01.0 [1022/7450] enabled
PCI: 04:01.1 [1022/7451] ops
PCI: 04:01.1 [1022/7451] enabled
PCI: 04:02.0 [1022/7450] bus ops
PCI: 04:02.0 [1022/7450] enabled
PCI: 04:02.1 [1022/7451] ops
PCI: 04:02.1 [1022/7451] enabled
PCI: 04:03.0 [1022/7460] bus ops
PCI: 04:03.0 [1022/7460] enabled
PCI: 04:04.0 [1022/7468] bus ops
PCI: 04:04.0 [1022/7468] enabled
PCI: 04:04.1 [1022/7469] ops
PCI: 04:04.1 [1022/7469] enabled
PCI: 04:04.2 [1022/746a] enabled
PCI: 04:04.3 [1022/746b] bus ops
PCI: 04:04.3 [1022/746b] enabled
PCI: 04:04.5 [1022/746d] enabled
PCI: 04:04.6 No device operations
PCI: pci_scan_bus for bus 5
PCI: pci_scan_bus returning with max=05
PCI: pci_scan_bus for bus 6
PCI: pci_scan_bus returning with max=06
PCI: pci_scan_bus for bus 7
PCI: 07:00.0 [1022/7464] enabled
PCI: 07:00.1 [1022/7464] enabled
PCI: 07:00.2 No device operations
PCI: 07:01.0 No device operations
PCI: pci_scan_bus returning with max=07
PNP: 0002.0 enabled
PNP: 0002.1 disabled
PNP: 0002.2 disabled
PNP: 0002.3 enabled
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=07
PCI: 08:01.0 [1022/7450] enabled next_unitid: 0003
HyperT reset not needed
PCI: pci_scan_bus for bus 8
PCI: 08:01.0 [1022/7450] bus ops
PCI: 08:01.0 [1022/7450] enabled
PCI: 08:01.1 [1022/7451] ops
PCI: 08:01.1 [1022/7451] enabled
PCI: 08:02.0 [1022/7450] bus ops
PCI: 08:02.0 [1022/7450] enabled
PCI: 08:02.1 [1022/7451] ops
PCI: 08:02.1 [1022/7451] enabled
PCI: pci_scan_bus for bus 9
PCI: pci_scan_bus returning with max=09
PCI: pci_scan_bus for bus 10
PCI: pci_scan_bus returning with max=0a
PCI: pci_scan_bus returning with max=0a
PCI: pci_scan_bus returning with max=0a
CPU: APIC: 00 enabled
CPU: APIC: 01 disabled
done
Allocating resources...
PCI: 01:01.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 2 io
PCI: 01:01.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 2 prefmem
PCI: 01:01.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 2 mem
PCI: 01:02.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 3 io
PCI: 01:02.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 3 prefmem
PCI: 01:02.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 3 mem
PCI: 04:01.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 5 io
PCI: 04:01.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 5 prefmem
PCI: 04:01.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 5 mem
PCI: 04:02.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 6 io
PCI: 04:02.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 6 prefmem
PCI: 04:02.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 6 mem
PCI: 04:03.0 1c <- [0x000000f000 - 0x000000efff] bus 7 io
PCI: 04:03.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 7 prefmem
PCI: 08:01.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 9 io
PCI: 08:01.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 9 prefmem
PCI: 08:01.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 9 mem
PCI: 08:02.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 10 io
PCI: 08:02.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 10 prefmem
PCI: 08:02.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 10 mem
PCI: 00:18.0 1b9 <- [0x00fc400000 - 0x00fc3fffff] prefmem <node 0 link 1>
PCI: 00:18.0 1c1 <- [0x0000001000 - 0x0000001fff] io <node 0 link 1>
PCI: 00:18.0 1d8 <- [0x0000002000 - 0x0000001fff] io <node 0 link 0>
PCI: 00:18.0 1b0 <- [0x00fc400000 - 0x00fc3fffff] prefmem <node 0 link 0>
PCI: 00:18.0 1a8 <- [0x00fc200000 - 0x00fc2fffff] mem <node 0 link 0>
PCI: 00:18.0 1a1 <- [0x00fc000000 - 0x00fc1fffff] mem <node 0 link 1>
PCI: 00:18.0 1d2 <- [0x0000002000 - 0x0000001fff] io <node 0 link 2>
PCI: 00:18.0 19a <- [0x00fc400000 - 0x00fc3fffff] prefmem <node 0 link 2>
PCI: 00:18.0 192 <- [0x00fc300000 - 0x00fc3fffff] mem <node 0 link 2>
PCI: 01:01.1 10 <- [0x00fc200000 - 0x00fc200fff] mem
PCI: 01:02.1 10 <- [0x00fc201000 - 0x00fc201fff] mem
PCI: 04:01.1 10 <- [0x00fc100000 - 0x00fc100fff] mem
PCI: 04:02.1 10 <- [0x00fc101000 - 0x00fc101fff] mem
PCI: 04:03.0 20 <- [0x00fc000000 - 0x00fc0fffff] bus 7 mem
PCI: 07:00.0 10 <- [0x00fc000000 - 0x00fc000fff] mem
PCI: 07:00.1 10 <- [0x00fc001000 - 0x00fc001fff] mem
PNP: 002e.0 60 <- [0x00000003f0 - 0x00000003f7] io
PNP: 002e.0 70 <- [0x0000000006 - 0x0000000006] irq
PNP: 002e.0 74 <- [0x0000000002 - 0x0000000002] drq
PNP: 002e.2 60 <- [0x00000003f8 - 0x00000003ff] io
PNP: 002e.2 70 <- [0x0000000004 - 0x0000000004] irq
PNP: 002e.5 60 <- [0x0000000060 - 0x0000000060] io
PNP: 002e.5 62 <- [0x0000000064 - 0x0000000064] io
PNP: 002e.5 70 <- [0x0000000001 - 0x0000000001] irq
PNP: 002e.5 72 <- [0x000000000c - 0x000000000c] irq
PNP: 002e.b 60 <- [0x0000000290 - 0x0000000297] io
PNP: 002e.b 70 <- [0x0000000005 - 0x0000000005] irq
PCI: 04:04.1 20 <- [0x0000001860 - 0x000000186f] io
PCI: 04:04.2 10 <- [0x0000001840 - 0x000000185f] io
PCI: 04:04.3 58 <- [0x0000001000 - 0x00000010ff] io
PCI: 04:04.5 10 <- [0x0000001400 - 0x00000014ff] io
PCI: 04:04.5 14 <- [0x0000001800 - 0x000000183f] io
PCI: 08:01.1 10 <- [0x00fc300000 - 0x00fc300fff] mem
PCI: 08:02.1 10 <- [0x00fc301000 - 0x00fc301fff] mem
PCI: 00:18.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart>
done.
Enabling resourcess...
PCI: 00:18.0 cmd <- 140
PCI: 01:01.0 bridge ctrl <- 0003
PCI: 01:01.0 cmd <- 140
PCI: 01:01.1 subsystem <- 10f1/2885
PCI: 01:01.1 cmd <- 146
PCI: 01:02.0 bridge ctrl <- 0003
PCI: 01:02.0 cmd <- 140
PCI: 01:02.1 subsystem <- 10f1/2885
PCI: 01:02.1 cmd <- 146
PCI: 04:01.0 bridge ctrl <- 0003
PCI: 04:01.0 cmd <- 140
PCI: 04:01.1 subsystem <- 10f1/2885
PCI: 04:01.1 cmd <- 146
PCI: 04:02.0 bridge ctrl <- 0003
PCI: 04:02.0 cmd <- 140
PCI: 04:02.1 subsystem <- 10f1/2885
PCI: 04:02.1 cmd <- 146
PCI: 04:03.0 bridge ctrl <- 0003
PCI: 04:03.0 cmd <- 146
PCI: 07:00.0 subsystem <- 10f1/2885
PCI: 07:00.0 cmd <- 142
PCI: 07:00.1 subsystem <- 10f1/2885
PCI: 07:00.1 cmd <- 142
PCI: 04:04.0 subsystem <- 10f1/2885
PCI: 04:04.0 cmd <- 14f
w83627hf hwm smbus enabledPCI: 04:04.1 subsystem <- 10f1/2885
PCI: 04:04.1 cmd <- 141
PCI: 04:04.2 subsystem <- 10f1/2885
PCI: 04:04.2 cmd <- 141
PCI: 04:04.3 subsystem <- 10f1/2885
PCI: 04:04.3 cmd <- 141
PCI: 04:04.5 subsystem <- 10f1/2885
PCI: 04:04.5 cmd <- 141
PCI: 08:01.0 bridge ctrl <- 0003
PCI: 08:01.0 cmd <- 140
PCI: 08:01.1 subsystem <- 10f1/2885
PCI: 08:01.1 cmd <- 146
PCI: 08:02.0 bridge ctrl <- 0003
PCI: 08:02.0 cmd <- 140
PCI: 08:02.1 subsystem <- 10f1/2885
PCI: 08:02.1 cmd <- 146
PCI: 00:18.1 subsystem <- 10f1/2885
PCI: 00:18.1 cmd <- 140
PCI: 00:18.2 subsystem <- 10f1/2885
PCI: 00:18.2 cmd <- 140
PCI: 00:18.3 cmd <- 140
done.
Initializing devices...
Root Device init
PCI: 00:18.0 init
PCI: 01:01.0 init
PCI: 01:02.0 init
PCI: 04:01.0 init
PCI: 04:02.0 init
PCI: 04:03.0 init
PCI: 04:04.0 init
RTC Init
Invalid CMOS LB checksum
enabling HPET @0xfed00000
PNP: 0002.0 init
PNP: 0002.3 init
calling cpuid 0x80000007
cpuid[80000007]: 00000000 00000000 00000000 00000009
PNP: 002e.0 init
PNP: 002e.2 init
PNP: 002e.5 init
PNP: 002e.b init
PCI: 04:04.1 init
IDE1 IDE0 PCI: 04:04.3 init
set power on after power fail
PCI: 08:01.0 init
PCI: 08:02.0 init
PCI: 00:18.3 init
NB: Function 3 Misc Control.. resetting cpu
done.
APIC_CLUSTER: 0 init
Initializing CPU #0
CPU: vendor AMD device f58
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 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: 2048MB, type WB
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs : Enabled
Variable MTRRs: Enabled

Clearing memory 0K - 2097152K: ------------------------------- done
Setting up local apic... apic_id: 0 done.
CPU #0 Initialized
CPU 1 did not initialize!
All AP CPUs stopped
PNP: 0000.0 init
PNP: 0000.3 init
calling cpuid 0x80000007
cpuid[80000007]: 00000000 00000000 00000000 00000009
Devices initialized
Copying IRQ routing tables to 0xf0000...done.
Verifing copy of IRQ routing tables at 0xf0000...done
Checking IRQ routing table consistency...
/home/lt/vvvv/freebios2-20041106-0100/src/arch/i386/boot/pirq_routing.c: 
28:check_pirq_routing_table() - irq_routing_table located at: 0x000f0000
/home/lt/vvvv/freebios2-20041106-0100/src/arch/i386/boot/pirq_routing.c: 
36:check_pirq_routing_table() - checksum is: 0xd8 but should be: 0x42
done.
Wrote the mp table end at: 00000020 - 00000210
Wrote linuxbios table at: 00000500 - 00000d68 checksum 13a9

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

23:stream_init() - rom_stream: 0xfffe0000 - 0xfffefbff
Found ELF candiate at offset 0
New segment addr 0x100000 size 0x260c0 offset 0xc0 filesize 0xc028
(cleaned up) New segment addr 0x100000 size 0x260c0 offset 0xc0 filesize 
0xc028
New segment addr 0x1260c0 size 0x48 offset 0xc100 filesize 0x48
(cleaned up) New segment addr 0x1260c0 size 0x48 offset 0xc100 filesize 0x48
Dropping non PT_LOAD segment
Dropping non PT_LOAD segment
Loading Segment: addr: 0x0000000000100000 memsz: 0x00000000000260c0 
filesz: 0x000000000000c028
Clearing Segment: addr: 0x000000000010c028 memsz: 0x000000000001a098
Loading Segment: addr: 0x00000000001260c0 memsz: 0x0000000000000048 
filesz: 0x0000000000000048
Jumping to boot code at 0x1089c8
FILO version 0.4.2 (lt at ncic.ac.cn) Fri Jun 25 18:17:36 CST 2004
collect_sys_info: boot eax = 0xe1fb007
collect_sys_info: boot ebx = 0x7ffef860
collect_sys_info: boot arg = 0x7ffef860
malloc_diag: alloc: 0 bytes (0 blocks), free: 16376 bytes (1 blocks)
malloc_diag: alloc: 24 bytes (1 blocks), free: 16352 bytes (1 blocks)
collect_elfboot_info: Bootloader: elfboot
collect_elfboot_info: Version: 1.3
malloc_diag: alloc: 40 bytes (2 blocks), free: 16336 bytes (1 blocks)
collect_linuxbios_info: Searching for LinuxBIOS tables...
find_lb_table: Found canidate at: 00000500
find_lb_table: header checksum o.k.
find_lb_table: table checksum o.k.
find_lb_table: record count o.k.
collect_linuxbios_info: Found LinuxBIOS table at: 00000500
malloc_diag: alloc: 128 bytes (3 blocks), free: 16248 bytes (1 blocks)
convert_memmap: 0x00000000000000 0x00000000000dd8 16
convert_memmap: 0x00000000000dd8 0x0000000009f228 1
convert_memmap: 0x000000000c0000 0x00000000030000 1
convert_memmap: 0x000000000f0000 0x00000000000400 16
convert_memmap: 0x000000000f0400 0x0000007ff0fc00 1
collect_sys_info: 0000000000000dd8-00000000000a0000
collect_sys_info: 00000000000c0000-00000000000f0000
collect_sys_info: 00000000000f0400-0000000080000000
collect_sys_info: RAM 2048 MB
relocate: Current location: 0x100000-0x126107
relocate: Relocating to 0x7ffd9ef0-0x7ffffff7... ok
setup_timers: CPU 1396 MHz
pci_init: Scanning PCI: found 24 devices
malloc_diag: alloc: 424 bytes (4 blocks), free: 15952 bytes (1 blocks)
pci_init: 00:18.0 1022:1100 0600 00
pci_init: 00:18.1 1022:1101 0600 00
pci_init: 00:18.2 1022:1102 0600 00
pci_init: 00:18.3 1022:1103 0600 00
pci_init: 01:01.0 1022:7450 0604 00
pci_init: 01:01.1 1022:7451 0800 10
pci_init: 01:02.0 1022:7450 0604 00
pci_init: 01:02.1 1022:7451 0800 10
pci_init: 04:01.0 1022:7450 0604 00
pci_init: 04:01.1 1022:7451 0800 10
pci_init: 04:02.0 1022:7450 0604 00
pci_init: 04:02.1 1022:7451 0800 10
pci_init: 04:03.0 1022:7460 0604 00
pci_init: 04:04.0 1022:7468 0601 00
pci_init: 04:04.1 1022:7469 0101 8a
pci_init: 04:04.2 1022:746a 0c05 00
pci_init: 04:04.3 1022:746b 0680 00
pci_init: 04:04.5 1022:746d 0401 00
pci_init: 07:00.0 1022:7464 0c03 10
pci_init: 07:00.1 1022:7464 0c03 10
pci_init: 08:01.0 1022:7450 0604 00
pci_init: 08:01.1 1022:7451 0800 10
pci_init: 08:02.0 1022:7450 0604 00
pci_init: 08:02.1 1022:7451 0800 10
boot:


From rminnich at lanl.gov  Mon Nov  8 08:13:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Nov  8 08:13:00 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
In-Reply-To: <m3pt2rn5k8.fsf@maxwell.lnxi.com>
References: <3174569B9743D511922F00A0C943142306BA2D42@TYANWEB>
 <m3pt2rn5k8.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.58.0411080737060.11714@linux.site>


On Fri, 5 Nov 2004, Eric W. Biederman wrote:

> Could we please reserve this construct for chipsets
> with multiple northbridges?

Whew, I'm glad you said that Eric, it concerned me too!

thanks

ron


From rminnich at lanl.gov  Mon Nov  8 08:13:13 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Nov  8 08:13:13 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
In-Reply-To: <m3pt2rn5k8.fsf@maxwell.lnxi.com>
References: <3174569B9743D511922F00A0C943142306BA2D42@TYANWEB>
 <m3pt2rn5k8.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.58.0411080737450.11714@linux.site>


On Fri, 5 Nov 2004, Eric W. Biederman wrote:

> They can.  But I am about to suggest simply removing the config
> directive, and assuming the ``config chip.h'' is always given.  The
> overhead is almost zero for a zero filled structure.  And always
> requiring a chip.h would tend to simply the process of writing code
> for a new chip.

yes, I think Eric is right on this one too :-)

ron


From YhLu at tyan.com  Mon Nov  8 11:29:00 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Nov  8 11:29:00 2004
Subject: LinuxBIOS boots
Message-ID: <3174569B9743D511922F00A0C943142306BA2D99@TYANWEB>

It seems there is no support on that.

Option for you:
1. add that support you self and contribute that to Etherboot.
2. push AMD to support that. Can they?
3. push AMD to pay Etherboot ( Ken, Tim, Eric) to add that for you. I don't
think Eric could have time for it.
4. You company pay Etherboot.
5. Change you design to add another support LAN chip.
6. Use one supported add-on card.

Final solution for LinuxBIOS maybe some day the kernel can be tailored to be
small enough to be put in flash (with initramfs), that will call kexec to
init another kernel in net or any kernel support media.


Regards

Yinghai Lu

-----Original Message-----
From: Liu Tao [mailto:liutao at safe-mail.net] 
Sent: Monday, November 08, 2004 5:57 AM
To: LinuxBIOS
Subject: LinuxBIOS boots

It's really exciting :)
Does etherboot support AMD8111 ethernet controller?

Regards,
Liu Tao

==========================



LinuxBIOS-1.1.7.0-Fallback ? 11? 8 15:59:58 CST 2004 starting...
setting up resource map....done.
coherent_ht_finalize
done
ht reset -


LinuxBIOS-1.1.7.0-Fallback ? 11? 8 15:59:58 CST 2004 starting...
setting up resource map....done.
coherent_ht_finalize
done
Ram1.00
Ram2.00
Ram3
Initializing memory: done
Clearing initial memory region: done
Ram4
Copying LinuxBIOS to ram.
Jumping to LinuxBIOS.
LinuxBIOS-1.1.7.0-Fallback ? 11? 8 15:59:58 CST 2004 booting...
Enumerating buses...
PCI_DOMAIN: 0000 enabled
APIC_CLUSTER: 0 enabled
PNP: 0000.0 enabled
PNP: 0000.1 disabled
PNP: 0000.2 disabled
PNP: 0000.3 enabled
PCI: pci_scan_bus for bus 0
PCI: 00:18.0 [1022/1100] bus ops
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] ops
PCI: 00:18.3 [1022/1103] enabled
PCI: 01:01.0 [1022/7450] enabled next_unitid: 0003
HyperT reset not needed
PCI: pci_scan_bus for bus 1
PCI: 01:01.0 [1022/7450] bus ops
PCI: 01:01.0 [1022/7450] enabled
PCI: 01:01.1 [1022/7451] ops
PCI: 01:01.1 [1022/7451] enabled
PCI: 01:02.0 [1022/7450] bus ops
PCI: 01:02.0 [1022/7450] enabled
PCI: 01:02.1 [1022/7451] ops
PCI: 01:02.1 [1022/7451] enabled
PCI: pci_scan_bus for bus 2
PCI: pci_scan_bus returning with max=02
PCI: pci_scan_bus for bus 3
PCI: pci_scan_bus returning with max=03
PCI: pci_scan_bus returning with max=03
PCI: 04:01.0 [1022/7450] enabled next_unitid: 0003
PCI: 04:03.0 [1022/7460] enabled next_unitid: 0007
HyperT reset not needed
PCI: pci_scan_bus for bus 4
PCI: 04:01.0 [1022/7450] bus ops
PCI: 04:01.0 [1022/7450] enabled
PCI: 04:01.1 [1022/7451] ops
PCI: 04:01.1 [1022/7451] enabled
PCI: 04:02.0 [1022/7450] bus ops
PCI: 04:02.0 [1022/7450] enabled
PCI: 04:02.1 [1022/7451] ops
PCI: 04:02.1 [1022/7451] enabled
PCI: 04:03.0 [1022/7460] bus ops
PCI: 04:03.0 [1022/7460] enabled
PCI: 04:04.0 [1022/7468] bus ops
PCI: 04:04.0 [1022/7468] enabled
PCI: 04:04.1 [1022/7469] ops
PCI: 04:04.1 [1022/7469] enabled
PCI: 04:04.2 [1022/746a] enabled
PCI: 04:04.3 [1022/746b] bus ops
PCI: 04:04.3 [1022/746b] enabled
PCI: 04:04.5 [1022/746d] enabled
PCI: 04:04.6 No device operations
PCI: pci_scan_bus for bus 5
PCI: pci_scan_bus returning with max=05
PCI: pci_scan_bus for bus 6
PCI: pci_scan_bus returning with max=06
PCI: pci_scan_bus for bus 7
PCI: 07:00.0 [1022/7464] enabled
PCI: 07:00.1 [1022/7464] enabled
PCI: 07:00.2 No device operations
PCI: 07:01.0 No device operations
PCI: pci_scan_bus returning with max=07
PNP: 0002.0 enabled
PNP: 0002.1 disabled
PNP: 0002.2 disabled
PNP: 0002.3 enabled
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=07
PCI: 08:01.0 [1022/7450] enabled next_unitid: 0003
HyperT reset not needed
PCI: pci_scan_bus for bus 8
PCI: 08:01.0 [1022/7450] bus ops
PCI: 08:01.0 [1022/7450] enabled
PCI: 08:01.1 [1022/7451] ops
PCI: 08:01.1 [1022/7451] enabled
PCI: 08:02.0 [1022/7450] bus ops
PCI: 08:02.0 [1022/7450] enabled
PCI: 08:02.1 [1022/7451] ops
PCI: 08:02.1 [1022/7451] enabled
PCI: pci_scan_bus for bus 9
PCI: pci_scan_bus returning with max=09
PCI: pci_scan_bus for bus 10
PCI: pci_scan_bus returning with max=0a
PCI: pci_scan_bus returning with max=0a
PCI: pci_scan_bus returning with max=0a
CPU: APIC: 00 enabled
CPU: APIC: 01 disabled
done
Allocating resources...
PCI: 01:01.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 2 io
PCI: 01:01.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 2 prefmem
PCI: 01:01.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 2 mem
PCI: 01:02.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 3 io
PCI: 01:02.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 3 prefmem
PCI: 01:02.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 3 mem
PCI: 04:01.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 5 io
PCI: 04:01.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 5 prefmem
PCI: 04:01.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 5 mem
PCI: 04:02.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 6 io
PCI: 04:02.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 6 prefmem
PCI: 04:02.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 6 mem
PCI: 04:03.0 1c <- [0x000000f000 - 0x000000efff] bus 7 io
PCI: 04:03.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 7 prefmem
PCI: 08:01.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 9 io
PCI: 08:01.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 9 prefmem
PCI: 08:01.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 9 mem
PCI: 08:02.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 10 io
PCI: 08:02.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 10 prefmem
PCI: 08:02.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 10 mem
PCI: 00:18.0 1b9 <- [0x00fc400000 - 0x00fc3fffff] prefmem <node 0 link 1>
PCI: 00:18.0 1c1 <- [0x0000001000 - 0x0000001fff] io <node 0 link 1>
PCI: 00:18.0 1d8 <- [0x0000002000 - 0x0000001fff] io <node 0 link 0>
PCI: 00:18.0 1b0 <- [0x00fc400000 - 0x00fc3fffff] prefmem <node 0 link 0>
PCI: 00:18.0 1a8 <- [0x00fc200000 - 0x00fc2fffff] mem <node 0 link 0>
PCI: 00:18.0 1a1 <- [0x00fc000000 - 0x00fc1fffff] mem <node 0 link 1>
PCI: 00:18.0 1d2 <- [0x0000002000 - 0x0000001fff] io <node 0 link 2>
PCI: 00:18.0 19a <- [0x00fc400000 - 0x00fc3fffff] prefmem <node 0 link 2>
PCI: 00:18.0 192 <- [0x00fc300000 - 0x00fc3fffff] mem <node 0 link 2>
PCI: 01:01.1 10 <- [0x00fc200000 - 0x00fc200fff] mem
PCI: 01:02.1 10 <- [0x00fc201000 - 0x00fc201fff] mem
PCI: 04:01.1 10 <- [0x00fc100000 - 0x00fc100fff] mem
PCI: 04:02.1 10 <- [0x00fc101000 - 0x00fc101fff] mem
PCI: 04:03.0 20 <- [0x00fc000000 - 0x00fc0fffff] bus 7 mem
PCI: 07:00.0 10 <- [0x00fc000000 - 0x00fc000fff] mem
PCI: 07:00.1 10 <- [0x00fc001000 - 0x00fc001fff] mem
PNP: 002e.0 60 <- [0x00000003f0 - 0x00000003f7] io
PNP: 002e.0 70 <- [0x0000000006 - 0x0000000006] irq
PNP: 002e.0 74 <- [0x0000000002 - 0x0000000002] drq
PNP: 002e.2 60 <- [0x00000003f8 - 0x00000003ff] io
PNP: 002e.2 70 <- [0x0000000004 - 0x0000000004] irq
PNP: 002e.5 60 <- [0x0000000060 - 0x0000000060] io
PNP: 002e.5 62 <- [0x0000000064 - 0x0000000064] io
PNP: 002e.5 70 <- [0x0000000001 - 0x0000000001] irq
PNP: 002e.5 72 <- [0x000000000c - 0x000000000c] irq
PNP: 002e.b 60 <- [0x0000000290 - 0x0000000297] io
PNP: 002e.b 70 <- [0x0000000005 - 0x0000000005] irq
PCI: 04:04.1 20 <- [0x0000001860 - 0x000000186f] io
PCI: 04:04.2 10 <- [0x0000001840 - 0x000000185f] io
PCI: 04:04.3 58 <- [0x0000001000 - 0x00000010ff] io
PCI: 04:04.5 10 <- [0x0000001400 - 0x00000014ff] io
PCI: 04:04.5 14 <- [0x0000001800 - 0x000000183f] io
PCI: 08:01.1 10 <- [0x00fc300000 - 0x00fc300fff] mem
PCI: 08:02.1 10 <- [0x00fc301000 - 0x00fc301fff] mem
PCI: 00:18.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart>
done.
Enabling resourcess...
PCI: 00:18.0 cmd <- 140
PCI: 01:01.0 bridge ctrl <- 0003
PCI: 01:01.0 cmd <- 140
PCI: 01:01.1 subsystem <- 10f1/2885
PCI: 01:01.1 cmd <- 146
PCI: 01:02.0 bridge ctrl <- 0003
PCI: 01:02.0 cmd <- 140
PCI: 01:02.1 subsystem <- 10f1/2885
PCI: 01:02.1 cmd <- 146
PCI: 04:01.0 bridge ctrl <- 0003
PCI: 04:01.0 cmd <- 140
PCI: 04:01.1 subsystem <- 10f1/2885
PCI: 04:01.1 cmd <- 146
PCI: 04:02.0 bridge ctrl <- 0003
PCI: 04:02.0 cmd <- 140
PCI: 04:02.1 subsystem <- 10f1/2885
PCI: 04:02.1 cmd <- 146
PCI: 04:03.0 bridge ctrl <- 0003
PCI: 04:03.0 cmd <- 146
PCI: 07:00.0 subsystem <- 10f1/2885
PCI: 07:00.0 cmd <- 142
PCI: 07:00.1 subsystem <- 10f1/2885
PCI: 07:00.1 cmd <- 142
PCI: 04:04.0 subsystem <- 10f1/2885
PCI: 04:04.0 cmd <- 14f
w83627hf hwm smbus enabledPCI: 04:04.1 subsystem <- 10f1/2885
PCI: 04:04.1 cmd <- 141
PCI: 04:04.2 subsystem <- 10f1/2885
PCI: 04:04.2 cmd <- 141
PCI: 04:04.3 subsystem <- 10f1/2885
PCI: 04:04.3 cmd <- 141
PCI: 04:04.5 subsystem <- 10f1/2885
PCI: 04:04.5 cmd <- 141
PCI: 08:01.0 bridge ctrl <- 0003
PCI: 08:01.0 cmd <- 140
PCI: 08:01.1 subsystem <- 10f1/2885
PCI: 08:01.1 cmd <- 146
PCI: 08:02.0 bridge ctrl <- 0003
PCI: 08:02.0 cmd <- 140
PCI: 08:02.1 subsystem <- 10f1/2885
PCI: 08:02.1 cmd <- 146
PCI: 00:18.1 subsystem <- 10f1/2885
PCI: 00:18.1 cmd <- 140
PCI: 00:18.2 subsystem <- 10f1/2885
PCI: 00:18.2 cmd <- 140
PCI: 00:18.3 cmd <- 140
done.
Initializing devices...
Root Device init
PCI: 00:18.0 init
PCI: 01:01.0 init
PCI: 01:02.0 init
PCI: 04:01.0 init
PCI: 04:02.0 init
PCI: 04:03.0 init
PCI: 04:04.0 init
RTC Init
Invalid CMOS LB checksum
enabling HPET @0xfed00000
PNP: 0002.0 init
PNP: 0002.3 init
calling cpuid 0x80000007
cpuid[80000007]: 00000000 00000000 00000000 00000009
PNP: 002e.0 init
PNP: 002e.2 init
PNP: 002e.5 init
PNP: 002e.b init
PCI: 04:04.1 init
IDE1 IDE0 PCI: 04:04.3 init
set power on after power fail
PCI: 08:01.0 init
PCI: 08:02.0 init
PCI: 00:18.3 init
NB: Function 3 Misc Control.. resetting cpu
done.
APIC_CLUSTER: 0 init
Initializing CPU #0
CPU: vendor AMD device f58
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 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: 2048MB, type WB
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs : Enabled
Variable MTRRs: Enabled

Clearing memory 0K - 2097152K: ------------------------------- done
Setting up local apic... apic_id: 0 done.
CPU #0 Initialized
CPU 1 did not initialize!
All AP CPUs stopped
PNP: 0000.0 init
PNP: 0000.3 init
calling cpuid 0x80000007
cpuid[80000007]: 00000000 00000000 00000000 00000009
Devices initialized
Copying IRQ routing tables to 0xf0000...done.
Verifing copy of IRQ routing tables at 0xf0000...done
Checking IRQ routing table consistency...
/home/lt/vvvv/freebios2-20041106-0100/src/arch/i386/boot/pirq_routing.c: 
28:check_pirq_routing_table() - irq_routing_table located at: 0x000f0000
/home/lt/vvvv/freebios2-20041106-0100/src/arch/i386/boot/pirq_routing.c: 
36:check_pirq_routing_table() - checksum is: 0xd8 but should be: 0x42
done.
Wrote the mp table end at: 00000020 - 00000210
Wrote linuxbios table at: 00000500 - 00000d68 checksum 13a9

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

23:stream_init() - rom_stream: 0xfffe0000 - 0xfffefbff
Found ELF candiate at offset 0
New segment addr 0x100000 size 0x260c0 offset 0xc0 filesize 0xc028
(cleaned up) New segment addr 0x100000 size 0x260c0 offset 0xc0 filesize 
0xc028
New segment addr 0x1260c0 size 0x48 offset 0xc100 filesize 0x48
(cleaned up) New segment addr 0x1260c0 size 0x48 offset 0xc100 filesize 0x48
Dropping non PT_LOAD segment
Dropping non PT_LOAD segment
Loading Segment: addr: 0x0000000000100000 memsz: 0x00000000000260c0 
filesz: 0x000000000000c028
Clearing Segment: addr: 0x000000000010c028 memsz: 0x000000000001a098
Loading Segment: addr: 0x00000000001260c0 memsz: 0x0000000000000048 
filesz: 0x0000000000000048
Jumping to boot code at 0x1089c8
FILO version 0.4.2 (lt at ncic.ac.cn) Fri Jun 25 18:17:36 CST 2004
collect_sys_info: boot eax = 0xe1fb007
collect_sys_info: boot ebx = 0x7ffef860
collect_sys_info: boot arg = 0x7ffef860
malloc_diag: alloc: 0 bytes (0 blocks), free: 16376 bytes (1 blocks)
malloc_diag: alloc: 24 bytes (1 blocks), free: 16352 bytes (1 blocks)
collect_elfboot_info: Bootloader: elfboot
collect_elfboot_info: Version: 1.3
malloc_diag: alloc: 40 bytes (2 blocks), free: 16336 bytes (1 blocks)
collect_linuxbios_info: Searching for LinuxBIOS tables...
find_lb_table: Found canidate at: 00000500
find_lb_table: header checksum o.k.
find_lb_table: table checksum o.k.
find_lb_table: record count o.k.
collect_linuxbios_info: Found LinuxBIOS table at: 00000500
malloc_diag: alloc: 128 bytes (3 blocks), free: 16248 bytes (1 blocks)
convert_memmap: 0x00000000000000 0x00000000000dd8 16
convert_memmap: 0x00000000000dd8 0x0000000009f228 1
convert_memmap: 0x000000000c0000 0x00000000030000 1
convert_memmap: 0x000000000f0000 0x00000000000400 16
convert_memmap: 0x000000000f0400 0x0000007ff0fc00 1
collect_sys_info: 0000000000000dd8-00000000000a0000
collect_sys_info: 00000000000c0000-00000000000f0000
collect_sys_info: 00000000000f0400-0000000080000000
collect_sys_info: RAM 2048 MB
relocate: Current location: 0x100000-0x126107
relocate: Relocating to 0x7ffd9ef0-0x7ffffff7... ok
setup_timers: CPU 1396 MHz
pci_init: Scanning PCI: found 24 devices
malloc_diag: alloc: 424 bytes (4 blocks), free: 15952 bytes (1 blocks)
pci_init: 00:18.0 1022:1100 0600 00
pci_init: 00:18.1 1022:1101 0600 00
pci_init: 00:18.2 1022:1102 0600 00
pci_init: 00:18.3 1022:1103 0600 00
pci_init: 01:01.0 1022:7450 0604 00
pci_init: 01:01.1 1022:7451 0800 10
pci_init: 01:02.0 1022:7450 0604 00
pci_init: 01:02.1 1022:7451 0800 10
pci_init: 04:01.0 1022:7450 0604 00
pci_init: 04:01.1 1022:7451 0800 10
pci_init: 04:02.0 1022:7450 0604 00
pci_init: 04:02.1 1022:7451 0800 10
pci_init: 04:03.0 1022:7460 0604 00
pci_init: 04:04.0 1022:7468 0601 00
pci_init: 04:04.1 1022:7469 0101 8a
pci_init: 04:04.2 1022:746a 0c05 00
pci_init: 04:04.3 1022:746b 0680 00
pci_init: 04:04.5 1022:746d 0401 00
pci_init: 07:00.0 1022:7464 0c03 10
pci_init: 07:00.1 1022:7464 0c03 10
pci_init: 08:01.0 1022:7450 0604 00
pci_init: 08:01.1 1022:7451 0800 10
pci_init: 08:02.0 1022:7450 0604 00
pci_init: 08:02.1 1022:7451 0800 10
boot:
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From ebiederman at lnxi.com  Mon Nov  8 13:05:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Nov  8 13:05:00 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
In-Reply-To: <Pine.LNX.4.58.0411080737450.11714@linux.site>
References: <3174569B9743D511922F00A0C943142306BA2D42@TYANWEB>
	<m3pt2rn5k8.fsf@maxwell.lnxi.com>
	<Pine.LNX.4.58.0411080737450.11714@linux.site>
Message-ID: <m3actsb0mt.fsf@maxwell.lnxi.com>

"Ronald G. Minnich" <rminnich at lanl.gov> writes:

> On Fri, 5 Nov 2004, Eric W. Biederman wrote:
> 
> > They can.  But I am about to suggest simply removing the config
> > directive, and assuming the ``config chip.h'' is always given.  The
> > overhead is almost zero for a zero filled structure.  And always
> > requiring a chip.h would tend to simply the process of writing code
> > for a new chip.
> 
> yes, I think Eric is right on this one too :-)

I think we probably want to wait a little on this one.
YhLu is extremely tight on space right now and I think
that needs to be addressed before we require any more
slight size increases.

Eric


From ebiederman at lnxi.com  Mon Nov  8 13:09:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Nov  8 13:09:01 2004
Subject: LinuxBIOS boots
In-Reply-To: <3174569B9743D511922F00A0C943142306BA2D99@TYANWEB>
References: <3174569B9743D511922F00A0C943142306BA2D99@TYANWEB>
Message-ID: <m3654gb0fy.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> It seems there is no support on that.
> 
> Option for you:
> 1. add that support you self and contribute that to Etherboot.
> 2. push AMD to support that. Can they?
> 3. push AMD to pay Etherboot ( Ken, Tim, Eric) to add that for you. I don't
> think Eric could have time for it.
> 4. You company pay Etherboot.
> 5. Change you design to add another support LAN chip.
> 6. Use one supported add-on card.
> 
> Final solution for LinuxBIOS maybe some day the kernel can be tailored to be
> small enough to be put in flash (with initramfs), that will call kexec to
> init another kernel in net or any kernel support media.
> 
> 
> Regards
> 
> Yinghai Lu
> 
> -----Original Message-----
> From: Liu Tao [mailto:liutao at safe-mail.net] 
> Sent: Monday, November 08, 2004 5:57 AM
> To: LinuxBIOS
> Subject: LinuxBIOS boots
> 
> It's really exciting :)
> Does etherboot support AMD8111 ethernet controller?

No but it does support some similar controllers. And it is simple one
so starting with the docs and the Linux driver it should not take
very long to do the port.

Yours is the first board since the AMD reference board that I have
seen that actually uses the AMD8111.

Eric


From ebiederman at lnxi.com  Mon Nov  8 13:19:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Nov  8 13:19:00 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
In-Reply-To: <Pine.LNX.4.58.0411080737060.11714@linux.site>
References: <3174569B9743D511922F00A0C943142306BA2D42@TYANWEB>
	<m3pt2rn5k8.fsf@maxwell.lnxi.com>
	<Pine.LNX.4.58.0411080737060.11714@linux.site>
Message-ID: <m3wtww9ldt.fsf@maxwell.lnxi.com>

"Ronald G. Minnich" <rminnich at lanl.gov> writes:

> On Fri, 5 Nov 2004, Eric W. Biederman wrote:
> 
> > Could we please reserve this construct for chipsets
> > with multiple northbridges?
> 
> Whew, I'm glad you said that Eric, it concerned me too!

This is not something I think it is worth much of an argument about.

I think doing this with the E7501 makes is less good as an example,
for other boards.

Except for chipsets with multiple northbridges I don't intend to
use the root_complex structure.

When you have multiple northbridges it nicely makes the information
we specify per northbridge symmetric.  Which helps in a lot
of little ways.  But for a single chipset it really is unnecessary.
It is the device's that really cary structure information and we have
all of those, one way or another.

Eric


From YhLu at tyan.com  Mon Nov  8 13:20:00 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Nov  8 13:20:00 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
Message-ID: <3174569B9743D511922F00A0C943142306BA2DC4@TYANWEB>

The difference is with "config config.h", the device in static will point to
one all zero struct about 4 bytes ( without .name and only has
.enable_dev=0).
Or .chip_ops = some _ops.

Eric has comment out config.h for socket. Only unsued chip_ops is for NB and
MB.
Others root_complex and SB bridge and superio.

YH

-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Monday, November 08, 2004 11:29 AM
To: Ronald G. Minnich
Cc: YhLu; 'Li-Ta Lo'; 'LinuxBIOS'
Subject: Re: Removing device driver code in mainboard.c for Tyan boards?

"Ronald G. Minnich" <rminnich at lanl.gov> writes:

> On Fri, 5 Nov 2004, Eric W. Biederman wrote:
> 
> > They can.  But I am about to suggest simply removing the config
> > directive, and assuming the ``config chip.h'' is always given.  The
> > overhead is almost zero for a zero filled structure.  And always
> > requiring a chip.h would tend to simply the process of writing code
> > for a new chip.
> 
> yes, I think Eric is right on this one too :-)

I think we probably want to wait a little on this one.
YhLu is extremely tight on space right now and I think
that needs to be addressed before we require any more
slight size increases.

Eric


From YhLu at tyan.com  Mon Nov  8 13:23:01 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Nov  8 13:23:01 2004
Subject: Removing device driver code in mainboard.c for Tyan boards?
Message-ID: <3174569B9743D511922F00A0C943142306BA2DC6@TYANWEB>

OK, someone can roll it back. Actually the E7501 support in v2 is side
product when I tried to add support for E7520...

Regards

YH

-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Monday, November 08, 2004 11:44 AM
To: Ronald G. Minnich
Cc: YhLu; 'Li-Ta Lo'; 'LinuxBIOS'
Subject: Re: Removing device driver code in mainboard.c for Tyan boards?

"Ronald G. Minnich" <rminnich at lanl.gov> writes:

> On Fri, 5 Nov 2004, Eric W. Biederman wrote:
> 
> > Could we please reserve this construct for chipsets
> > with multiple northbridges?
> 
> Whew, I'm glad you said that Eric, it concerned me too!

This is not something I think it is worth much of an argument about.

I think doing this with the E7501 makes is less good as an example,
for other boards.

Except for chipsets with multiple northbridges I don't intend to
use the root_complex structure.

When you have multiple northbridges it nicely makes the information
we specify per northbridge symmetric.  Which helps in a lot
of little ways.  But for a single chipset it really is unnecessary.
It is the device's that really cary structure information and we have
all of those, one way or another.

Eric


From YhLu at tyan.com  Mon Nov  8 15:10:00 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Nov  8 15:10:00 2004
Subject: ROMCC update
Message-ID: <3174569B9743D511922F00A0C943142306BA2DDD@TYANWEB>

Eric,

You update the ROMCC today, what's new feature of it?

Regards

YH


From YhLu at tyan.com  Mon Nov  8 15:18:00 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Nov  8 15:18:00 2004
Subject: Using Suse 9.1 pro for AMD64 as dev server.
Message-ID: <3174569B9743D511922F00A0C943142306BA2DE2@TYANWEB>

I'm planning to use Suse 9.1 pro for AMD64 as my dev server.

I have encountered some problems:
1. vi color, the Old RH 9 vi can high lighten the C grammar. But the Suse
don't how to enable it?
2. can not compiled gcc 3.4.2 under Suse 9.1 pro for AMD 64.
3. Etherboot doesn't like gcc 3.3.3, the tg3.zelf produced is corrupted,
only 17k.

Regards

YH


From stepan at openbios.org  Mon Nov  8 15:57:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Mon Nov  8 15:57:01 2004
Subject: Using Suse 9.1 pro for AMD64 as dev server.
In-Reply-To: <3174569B9743D511922F00A0C943142306BA2DE2@TYANWEB>
References: <3174569B9743D511922F00A0C943142306BA2DE2@TYANWEB>
Message-ID: <20041108222134.GC15948@openbios.org>

* YhLu <YhLu at tyan.com> [041108 22:48]:
> I'm planning to use Suse 9.1 pro for AMD64 as my dev server.
> 
> I have encountered some problems:
> 1. vi color, the Old RH 9 vi can high lighten the C grammar. But the Suse
> don't how to enable it?

It's just disabled per default.
: syn on. Or add "syn on" to your .vimrc

> 2. can not compiled gcc 3.4.2 under Suse 9.1 pro for AMD 64.

Any error messages? You might get
ftp://ftp.suse.com/pub/suse/i386/9.2/suse/src/gcc-3.3.4-11.src.rpm and
ftp://ftp.suse.com/pub/suse/i386/9.2/suse/src/binutils-2.15.91.0.2-7.src.rpm
and do rpmbuild --rebuild on them to get native rpms for amd64. It's
likely that you have more success with those (Or you use 9.2, it has
just been released. They also have a Live DVD which might be nice for
testing without having to install, at:
ftp://ftp.suse.com/pub/suse/i386/live-cd-9.2/SUSE-Linux-9.2-LiveDVD.iso
but I have no idea whether there's a gcc on it, I only tried the live cd
so far..

> 3. Etherboot doesn't like gcc 3.3.3, the tg3.zelf produced is corrupted,
> only 17k.

Do you know any details on this one?

Stefan



From YhLu at tyan.com  Mon Nov  8 16:09:01 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Nov  8 16:09:01 2004
Subject: Using Suse 9.1 pro for AMD64 as dev server.
Message-ID: <3174569B9743D511922F00A0C943142306BA2DF6@TYANWEB>

1. in /etc/vimrc
	Add "syntax on" at last
2. 
/home/yhlu/xx1/gcc-3.4.2/gcc/xgcc -B/home/yhlu/xx1/gcc-3.4.2/gcc/
-B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/x86_64-unknown-linux-gnu/include -isystem
/usr/local/x86_64-unknown-linux-gnu/sys-include -O2  -DIN_GCC    -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include  -fPIC -g -DHAVE_GTHR_DEFAULT
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -shared -nodefaultlibs
-Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc/32/libgcc.map -o
32/libgcc_s.so.1  -m32  libgcc/32/_muldi3.o libgcc/32/_negdi2.o
libgcc/32/_lshrdi3.o libgcc/32/_ashldi3.o libgcc/32/_ashrdi3.o
libgcc/32/_cmpdi2.o libgcc/32/_ucmpdi2.o libgcc/32/_floatdidf.o
libgcc/32/_floatdisf.o libgcc/32/_fixunsdfsi.o libgcc/32/_fixunssfsi.o
libgcc/32/_fixunsdfdi.o libgcc/32/_fixdfdi.o libgcc/32/_fixunssfdi.o
libgcc/32/_fixsfdi.o libgcc/32/_fixxfdi.o libgcc/32/_fixunsxfdi.o
libgcc/32/_floatdixf.o libgcc/32/_fixunsxfsi.o libgcc/32/_fixtfdi.o
libgcc/32/_fixunstfdi.o libgcc/32/_floatditf.o libgcc/32/_clear_cache.o
libgcc/32/_enable_execute_stack.o libgcc/32/_trampoline.o libgcc/32/__main.o
libgcc/32/_absvsi2.o libgcc/32/_absvdi2.o libgcc/32/_addvsi3.o
libgcc/32/_addvdi3.o libgcc/32/_subvsi3.o libgcc/32/_subvdi3.o
libgcc/32/_mulvsi3.o libgcc/32/_mulvdi3.o libgcc/32/_negvsi2.o
libgcc/32/_negvdi2.o libgcc/32/_ctors.o libgcc/32/_ffssi2.o
libgcc/32/_ffsdi2.o libgcc/32/_clz.o libgcc/32/_clzsi2.o libgcc/32/_clzdi2.o
libgcc/32/_ctzsi2.o libgcc/32/_ctzdi2.o libgcc/32/_popcount_tab.o
libgcc/32/_popcountsi2.o libgcc/32/_popcountdi2.o libgcc/32/_paritysi2.o
libgcc/32/_paritydi2.o libgcc/32/_divdi3.o libgcc/32/_moddi3.o
libgcc/32/_udivdi3.o libgcc/32/_umoddi3.o libgcc/32/_udiv_w_sdiv.o
libgcc/32/_udivmoddi4.o  libgcc/32/unwind-dw2.o
libgcc/32/unwind-dw2-fde-glibc.o libgcc/32/unwind-sjlj.o
libgcc/32/gthr-gnat.o libgcc/32/unwind-c.o -lc && rm -f libgcc_s_32.so && ln
-s 32/libgcc_s.so.1 libgcc_s_32.so
/usr/bin/ld: crti.o: No such file: No such file or directory
collect2: ld returned 1 exit status
make[2]: *** [32/libgcc_s_32.so] Error 1
make[2]: Leaving directory `/home/yhlu/xx1/gcc-3.4.2/gcc'
make[1]: *** [stmp-multilib] Error 2
make[1]: Leaving directory `/home/yhlu/xx1/gcc-3.4.2/gcc'
make: *** [all-gcc] Error 2


From ebiederman at lnxi.com  Mon Nov  8 16:13:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Nov  8 16:13:01 2004
Subject: ROMCC update
In-Reply-To: <3174569B9743D511922F00A0C943142306BA2DDD@TYANWEB>
References: <3174569B9743D511922F00A0C943142306BA2DDD@TYANWEB>
Message-ID: <m3bre8nf1b.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Eric,
> 
> You update the ROMCC today, what's new feature of it?

Minor CPP bug fixes.  When you first start using something problems
you never thought to test for show up.

The primary bug fix is that large constant values are actually
unsigned long instead of signed long.  That was causing problems
with the sanity checks in earlymtrr.c

Other bug fixes include not complaining about comments after
an #include directive, and recognizing undefined macros
and replacing them with 0.

It turned out that I most of the bug fixes were actually code
cleanups so I managed to remove 350 lines and make the code
a little more understandable while I was at it.

There is actually something really annoying about the C
preprocessor.  Things like sizeof(unsigned long) are valid
constant expressions that do not work simply because no
identifiers and keywords may be recognized  at the time the C
preprocessor is run.

My checkin comments may have more details.

I hope to find time soon to investigate the problems that show up when
not inlining.  But I don't have a clue what my schedule is going to
look like.

Eric


From YhLu at tyan.com  Mon Nov  8 16:37:01 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Nov  8 16:37:01 2004
Subject: ROMCC update
Message-ID: <3174569B9743D511922F00A0C943142306BA2E03@TYANWEB>

ROMCC is broken.

./romcc    -mcpu=k8 -O2 -I/home/yhlu/xx/xx/freebios2/src -I.
-I/home/yhlu/xx/xx/freebios2/src/include
-I/home/yhlu/xx/xx/freebios2/src/arch/i386/include
-I/usr/local/lib/gcc/i686-pc-linux-gnu/3.4.2/include -DARCH='i386'
-DHAVE_MOVNTI='1' -DCROSS_COMPILE -DCC='gcc -m32' -DHOSTCC='gcc'
-DOBJCOPY='objcopy' -DLINUXBIOS_VERSION='"1.1.7"' -DLINUXBIOS_BUILD='"Mon
Nov  8 14:14:42 PST 2004"' -DLINUXBIOS_COMPILE_TIME='"14:14:42"'
-DLINUXBIOS_COMPILE_BY='"root"' -DLINUXBIOS_COMPILE_HOST='"tst2723-rh9"'
-DLINUXBIOS_COMPILE_DOMAIN='""' -DLINUXBIOS_COMPILER='"gcc version 3.4.2"'
-DLINUXBIOS_LINKER='"GNU ld version 2.15"' -DLINUXBIOS_ASSEMBLER='"GNU
assembler version 2.15 (i686-pc-linux-gnu) using BFD version 2.15"'
-DHAVE_FALLBACK_BOOT='1' -DROM_IMAGE_SIZE='0x10000' -DPAYLOAD_SIZE='0x50000'
-D_ROMBASE='0xfffd0000' -D_RESET='0xfffd0000'
-D_EXCEPTION_VECTORS='0xfffd0100' -DSTACK_SIZE='0x2000' -DHEAP_SIZE='0x4000'
-D_RAMBASE='0x4000' -DCONFIG_COMPRESS='1' -DCONFIG_UNCOMPRESSED='0'
-DCONFIG_LB_MEM_TOPK='1024' -DHAVE_OPTION_TABLE='1' -DUSE_OPTION_TABLE='1'
-DLB_CKS_RANGE_START='49' -DLB_CKS_RANGE_END='122' -DLB_CKS_LOC='123'
-DCRT0='/home/yhlu/xx/xx/freebios2/src/arch/i386/init/crt0.S.lb' -DDEBUG='1'
-DCONFIG_CONSOLE_VGA='0' -DCONFIG_CONSOLE_BTEXT='0'
-DCONFIG_CONSOLE_LOGBUF='0' -DCONFIG_CONSOLE_SROM='0'
-DCONFIG_CONSOLE_SERIAL8250='1' -DDEFAULT_CONSOLE_LOGLEVEL='8'
-DMAXIMUM_CONSOLE_LOGLEVEL='8' -DCONFIG_SERIAL_POST='0' -DTTYS0_BASE='0x3f8'
-DTTYS0_BAUD='115200' -DTTYS0_LCS='0x3'
-DMAINBOARD='/home/yhlu/xx/xx/freebios2/src/mainboard/tyan/s2885'
-DMAINBOARD_PART_NUMBER='"Tyan"' -DMAINBOARD_VENDOR='"s2885"'
-DMAINBOARD_PCI_SUBSYSTEM_VENDOR_ID='4337'
-DMAINBOARD_PCI_SUBSYSTEM_DEVICE_ID='0x2885' -DCONFIG_SMP='1'
-DCONFIG_MAX_CPUS='2' -DCONFIG_LOGICAL_CPUS='0' -DCONFIG_IDE_STREAM='0'
-DCONFIG_ROM_STREAM='1' -DCONFIG_ROM_STREAM_START='0xfff80000'
-DCONFIG_FS_STREAM='0' -DCONFIG_FS_EXT2='0' -DCONFIG_FS_ISO9660='0'
-DCONFIG_FS_FAT='0' -DAUTOBOOT_DELAY='2' -DAUTOBOOT_CMDLINE='"hdc1:/vmlinuz
root=/dev/hdc3 console=tty0 console=ttyS0,115200"' -DCONFIG_IDE='0'
-DIDE_BOOT_DRIVE='0' -DIDE_OFFSET='0' -DCONFIG_CHIP_NAME='1'
-DHAVE_INIT_TIMER='1' -DHARD_RESET_BUS='3' -DHARD_RESET_DEVICE='4'
-DHARD_RESET_FUNCTION='0' -DMAX_REBOOT_CNT='3' -DFAKE_SPDROM='0'
-DHAVE_ACPI_TABLES='0' -DCK804_DEVN_BASE='1' -DHAVE_MP_TABLE='1'
-DHAVE_PIRQ_TABLE='1' -DUSE_FALLBACK_IMAGE='0' -DHAVE_HARD_RESET='1'
-DIRQ_SLOT_COUNT='11' -DCONFIG_IOAPIC='1' -DFALLBACK_SIZE='0x20000'
-DROM_SIZE='0x80000' -DROM_SECTION_SIZE='0x60000' -DROM_SECTION_OFFSET='0x0'
-DXIP_ROM_SIZE='0x10000' -DXIP_ROM_BASE='0xfffd0000'
-DLINUXBIOS_EXTRA_VERSION='"2.0_Normal"'
-DMAINBOARD_POWER_ON_AFTER_POWER_FAIL='MAINBOARD_POWER_ON'
-DCONFIG_GDB_STUB='0' -DCONFIG_USE_INIT='0' -DCONFIG_LEGACY_VGABIOS='0'
-DAGP_APERTURE_SIZE='0x4000000' -DCONFIG_UDELAY_TSC='0'
-DCONFIG_TSC_X86RDTSC_CALIBRATE_WITH_TIMER2='0'
/home/yhlu/xx/xx/freebios2/src/mainboard/tyan/s2885/auto.c -o auto.inc
:0.0: 
No functions to compile



From ebiederman at lnxi.com  Mon Nov  8 18:14:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Nov  8 18:14:00 2004
Subject: ROMCC update
In-Reply-To: <3174569B9743D511922F00A0C943142306BA2E03@TYANWEB>
References: <3174569B9743D511922F00A0C943142306BA2E03@TYANWEB>
Message-ID: <m3y8hbj1pc.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> ROMCC is broken.

Sorry stupid bug.  It was failing when there was a preprocessing
directive on the last line of an include file...

There were also one or two other silly bugs, caused by my code
reorganization. 

Fixed, and committed.

Eric


From cro_marmot at comcast.net  Mon Nov  8 23:17:00 2004
From: cro_marmot at comcast.net (David Hendricks)
Date: Mon Nov  8 23:17:00 2004
Subject: Using Suse 9.1 pro for AMD64 as dev server.
In-Reply-To: <3174569B9743D511922F00A0C943142306BA2DE2@TYANWEB>
References: <3174569B9743D511922F00A0C943142306BA2DE2@TYANWEB>
Message-ID: <20041108224417.685af724@sunder>

> 1. vi color, the Old RH 9 vi can high lighten the C grammar.

Looks like you found the solution to this one, but I also suggest adding
these these to your ~/.exrc:
colorscheme koehler
set si
set showmatch
set showmode
set ai
set ic

> 3. Etherboot doesn't like gcc 3.3.3, the tg3.zelf produced is
> corrupted, only 17k.

Which version of Etherboot? I think I ran into a version with 5.2.4
where ELF/ZELF images were corrupt no matter which GCC I tried.


From rminnich at lanl.gov  Tue Nov  9 08:19:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Tue Nov  9 08:19:00 2004
Subject: romcc quesiton
Message-ID: <Pine.LNX.4.58.0411090742440.14435@linux.site>


I'm seeing that with  the new built-in preprocessor the following types of 
things work incorrectly:

#if 0
blha blha
#endif

The #if 0 is ignored, the romcc tries to compile the code. 

Is this the expected behavior?

ron
p.s. cvs update as of this morning.


From sagivy at 3vium.com  Tue Nov  9 09:09:01 2004
From: sagivy at 3vium.com (Sagiv Yefet)
Date: Tue Nov  9 09:09:01 2004
Subject: tyan S2850 - optimal performance
Message-ID: <4A3D5F6DC9406A4DBE93D9BA8F07E4BB228AA3@cronos.trivium>

Where can I get a list of those parameters and there values ?

Sagiv

-----Original Message-----
From: Stefan Reinauer [mailto:stepan at openbios.org] 
Sent: Sunday, November 07, 2004 6:53 PM
To: Sagiv Yefet
Cc: linuxbios at clustermatic.org
Subject: Re: tyan S2850 - optimal performance

* Sagiv Yefet <sagivy at 3vium.com> [041107 17:52]:
> Hello, 
>   I have the TYAN s2850 board and I am running with Linux bios.
>   I want to use it in optimal performance.
>   Are there any parameters that I could change?
>   Does someone know about the optimal parameters in TYAN S2850 board?

LinuxBIOS ought to configure the board with optimal performance
parameters already. Is there anything you are missing?

Stefan




From stepan at openbios.org  Tue Nov  9 09:38:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue Nov  9 09:38:01 2004
Subject: tyan S2850 - optimal performance
In-Reply-To: <4A3D5F6DC9406A4DBE93D9BA8F07E4BB228AA3@cronos.trivium>
References: <4A3D5F6DC9406A4DBE93D9BA8F07E4BB228AA3@cronos.trivium>
Message-ID: <20041109160248.GA26282@openbios.org>

* Sagiv Yefet <sagivy at 3vium.com> [041109 16:39]:
> Where can I get a list of those parameters and there values ?

In the code, man, in the code...

   Stefan



From YhLu at tyan.com  Tue Nov  9 11:38:00 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Nov  9 11:38:00 2004
Subject: Using Suse 9.1 pro for AMD64 as dev server.
Message-ID: <3174569B9743D511922F00A0C943142306BA2E56@TYANWEB>

>Which version of Etherboot? I think I ran into a version with 5.2.4
>where ELF/ZELF images were corrupt no matter which GCC I tried.

In the Old RH 9, gcc-3.2.2 works well.

[root at tst2723-rh9 xx]# /usr/bin/gcc --version    
gcc (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


From YhLu at tyan.com  Tue Nov  9 11:47:00 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Nov  9 11:47:00 2004
Subject: romcc quesiton
Message-ID: <3174569B9743D511922F00A0C943142306BA2E5A@TYANWEB>

I met that too, and I have remove some un converted code in E7501 raminit.c

YH

-----Original Message-----
From: Ronald G. Minnich [mailto:rminnich at lanl.gov] 
Sent: Tuesday, November 09, 2004 6:44 AM
To: linuxbios at clustermatic.org
Subject: romcc quesiton



I'm seeing that with  the new built-in preprocessor the following types of 
things work incorrectly:

#if 0
blha blha
#endif

The #if 0 is ignored, the romcc tries to compile the code. 

Is this the expected behavior?

ron
p.s. cvs update as of this morning.
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From kfuchs at winternet.com  Tue Nov  9 14:10:01 2004
From: kfuchs at winternet.com (Ken Fuchs)
Date: Tue Nov  9 14:10:01 2004
Subject: Problem with AMD HDT setup for Tyan S2885 - LinuxBIOS debugging
Message-ID: <200411092035.iA9KZ6GN016683@tundra.winternet.com>

Purpose:

    To use AMD's HDT hardware/software to debug LinuxBIOS on various
    mainboards and chipsets.

    Two HDT headers were added to a commercial Tyan S2885 board.

Here's my hardware setup:

    S2885 with HDT CPU0 header <-> HDT ribbon cable
           and HDT CPU1 header <-> HDT ribbon cable

    HDT ribbon cable <-> HDT Multiprocessor Adapter
    HDT ribbon cable <-> |

    HDT Multiprocessor Adapter <-> Macraigor Systems' OCDemon (Raven)

    OCDemon (Raven) <-> parallel cable <-> host EPP mode port

Power up sequence:

    1) Host
    2) Target
    3) OCDemon (Raven)
    4) HDT MP Adapter

Symptoms of the problem:

    1) OCDemon host and target lights never go on.

    2) When using the host HDT software to open a new workspace, only 1
       processor is shown as available.

    3) While completing the opening of this single processor workspace, a
       warning window with the text below pops open:

       +--------------------------------------------+
       |Communication between HDT and               |
       |Processor No. 0 has problem!                |
       |                                            |
       |Please check your HDT host                  |
       |and target TAP connections.                 |
       |                                            |
       |Do you want to continue with incorrect info?|
       +--------------------------------------------+
    
Possible clue to the solution:

    Missing TDI/TDO jumpers or jumper headers?  There is a 2x3 header
    pad (no header) directly between the P1 socket and the P0 DIMM
    sockets that could be the correct place for these jumper headers.
    Maybe all I need to do is add a 2x3 header there and trace the
    routes of the six pins, hopefully back to the P0's HDT connector?
    (I don't have access to the S2885's schematics.)

    It seems that MP HDT must be enabled in this way.  I know that
    reference boards have toggle switches for this purpose.

Please respond with your suggestions.

Thank you very much!

Sincerely,

Ken Fuchs <kfuchs at winternet.com>


From rminnich at lanl.gov  Tue Nov  9 14:24:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Tue Nov  9 14:24:01 2004
Subject: romcc quesiton
In-Reply-To: <3174569B9743D511922F00A0C943142306BA2E5A@TYANWEB>
References: <3174569B9743D511922F00A0C943142306BA2E5A@TYANWEB>
Message-ID: <Pine.LNX.4.58.0411091348170.15069@linux.site>


On Tue, 9 Nov 2004, YhLu wrote:

> I met that too, and I have remove some un converted code in E7501
> raminit.c

it's hard to reproduce with simple cases -- I'm trying to create the 
simple case but romcc always gets those right. 


I'll try to find more if I get time today.

ron


From ebiederman at lnxi.com  Tue Nov  9 15:54:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Nov  9 15:54:01 2004
Subject: romcc quesiton
In-Reply-To: <Pine.LNX.4.58.0411091348170.15069@linux.site>
References: <3174569B9743D511922F00A0C943142306BA2E5A@TYANWEB>
	<Pine.LNX.4.58.0411091348170.15069@linux.site>
Message-ID: <m3llda1x9l.fsf@maxwell.lnxi.com>

"Ronald G. Minnich" <rminnich at lanl.gov> writes:

> On Tue, 9 Nov 2004, YhLu wrote:
> 
> > I met that too, and I have remove some un converted code in E7501
> > raminit.c
> 
> it's hard to reproduce with simple cases -- I'm trying to create the 
> simple case but romcc always gets those right. 
> 
> 
> I'll try to find more if I get time today.

A complex case would be fine.  With abuild.sh I'm not seeing any compile
failures.

Eric


From YhLu at tyan.com  Tue Nov  9 16:10:01 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Nov  9 16:10:01 2004
Subject: Problem with AMD HDT setup for Tyan S2885 - LinuxBIOS debuggi
	ng
Message-ID: <3174569B9743D511922F00A0C943142306BA2E8E@TYANWEB>

HW engineer said 
"on S2885, put jumper caps on J94 pin2 and pin3; J95 pin1 and pin2 to make
HDT and MP HDT work.
 J94 and J95 are in middle of the area between bootable CPU memory modules
and secondary CPU socket. the pin1 is the pin more close to the board edge
and power connectors."

Regards

YH

-----Original Message-----
From: Ken Fuchs [mailto:kfuchs at winternet.com] 
Sent: Tuesday, November 09, 2004 12:35 PM
To: LinuxBIOS at clustermatic.org
Subject: Problem with AMD HDT setup for Tyan S2885 - LinuxBIOS debugging

Purpose:

    To use AMD's HDT hardware/software to debug LinuxBIOS on various
    mainboards and chipsets.

    Two HDT headers were added to a commercial Tyan S2885 board.

Here's my hardware setup:

    S2885 with HDT CPU0 header <-> HDT ribbon cable
           and HDT CPU1 header <-> HDT ribbon cable

    HDT ribbon cable <-> HDT Multiprocessor Adapter
    HDT ribbon cable <-> |

    HDT Multiprocessor Adapter <-> Macraigor Systems' OCDemon (Raven)

    OCDemon (Raven) <-> parallel cable <-> host EPP mode port

Power up sequence:

    1) Host
    2) Target
    3) OCDemon (Raven)
    4) HDT MP Adapter

Symptoms of the problem:

    1) OCDemon host and target lights never go on.

    2) When using the host HDT software to open a new workspace, only 1
       processor is shown as available.

    3) While completing the opening of this single processor workspace, a
       warning window with the text below pops open:

       +--------------------------------------------+
       |Communication between HDT and               |
       |Processor No. 0 has problem!                |
       |                                            |
       |Please check your HDT host                  |
       |and target TAP connections.                 |
       |                                            |
       |Do you want to continue with incorrect info?|
       +--------------------------------------------+
    
Possible clue to the solution:

    Missing TDI/TDO jumpers or jumper headers?  There is a 2x3 header
    pad (no header) directly between the P1 socket and the P0 DIMM
    sockets that could be the correct place for these jumper headers.
    Maybe all I need to do is add a 2x3 header there and trace the
    routes of the six pins, hopefully back to the P0's HDT connector?
    (I don't have access to the S2885's schematics.)

    It seems that MP HDT must be enabled in this way.  I know that
    reference boards have toggle switches for this purpose.

Please respond with your suggestions.

Thank you very much!

Sincerely,

Ken Fuchs <kfuchs at winternet.com>
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From stepan at openbios.org  Tue Nov  9 16:27:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue Nov  9 16:27:00 2004
Subject: romcc quesiton
In-Reply-To: <m3llda1x9l.fsf@maxwell.lnxi.com>
References: <3174569B9743D511922F00A0C943142306BA2E5A@TYANWEB> <Pine.LNX.4.58.0411091348170.15069@linux.site> <m3llda1x9l.fsf@maxwell.lnxi.com>
Message-ID: <20041109225127.GA7807@openbios.org>

* Eric W. Biederman <ebiederman at lnxi.com> [041109 23:19]:
> > I'll try to find more if I get time today.
> 
> A complex case would be fine.  With abuild.sh I'm not seeing any compile
> failures.
 
Something's wrong with the line numbers. I get
incoherent_ht.c:191.8: warning:  "FIXME handle multiple chains!"
which is 10 lines later..
Does it ignore the lines with include statements?




From ebiederman at lnxi.com  Tue Nov  9 16:57:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Nov  9 16:57:00 2004
Subject: romcc quesiton
In-Reply-To: <20041109225127.GA7807@openbios.org>
References: <3174569B9743D511922F00A0C943142306BA2E5A@TYANWEB>
	<Pine.LNX.4.58.0411091348170.15069@linux.site>
	<m3llda1x9l.fsf@maxwell.lnxi.com> <20041109225127.GA7807@openbios.org>
Message-ID: <m3mzxqy5fn.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at openbios.org> writes:

> * Eric W. Biederman <ebiederman at lnxi.com> [041109 23:19]:
> > > I'll try to find more if I get time today.
> > 
> > A complex case would be fine.  With abuild.sh I'm not seeing any compile
> > failures.
>  
> Something's wrong with the line numbers. I get
> incoherent_ht.c:191.8: warning:  "FIXME handle multiple chains!"
> which is 10 lines later..
> Does it ignore the lines with include statements?

It should not but I have touched that bit of code recently so there
may be a regression there.

I will take a look.

Eric


From kfuchs at winternet.com  Tue Nov  9 20:32:00 2004
From: kfuchs at winternet.com (Ken Fuchs)
Date: Tue Nov  9 20:32:00 2004
Subject: Problem with AMD HDT setup for Tyan S2885 - LinuxBIOS debuggi
	ng
In-Reply-To: <3174569B9743D511922F00A0C943142306BA2E8E@TYANWEB> (message from
	YhLu on Tue, 9 Nov 2004 14:40:54 -0800)
References: <3174569B9743D511922F00A0C943142306BA2E8E@TYANWEB>
Message-ID: <200411100257.iAA2v4b28143@ecstasy1.winternet.com>

YhLu wrote:

>HW engineer said 
>"on S2885, put jumper caps on J94 pin2 and pin3; J95 pin1 and pin2 to make
>HDT and MP HDT work.
> J94 and J95 are in middle of the area between bootable CPU memory modules
>and secondary CPU socket. the pin1 is the pin more close to the board edge
>and power connectors."

Thank you very much, YhLu!  This is exactly the information I need to
get the MP HDT working on my S2885.

Sincerely,

Ken Fuchs <kfuchs at winternet.com>

>-----Original Message-----
>From: Ken Fuchs [mailto:kfuchs at winternet.com] 
>Sent: Tuesday, November 09, 2004 12:35 PM
>To: LinuxBIOS at clustermatic.org
>Subject: Problem with AMD HDT setup for Tyan S2885 - LinuxBIOS debugging
>
>Purpose:
>
>    To use AMD's HDT hardware/software to debug LinuxBIOS on various
>    mainboards and chipsets.
>
>    Two HDT headers were added to a commercial Tyan S2885 board.
>
>Here's my hardware setup:
>
>    S2885 with HDT CPU0 header <-> HDT ribbon cable
>           and HDT CPU1 header <-> HDT ribbon cable
>
>    HDT ribbon cable <-> HDT Multiprocessor Adapter
>    HDT ribbon cable <-> |
>
>    HDT Multiprocessor Adapter <-> Macraigor Systems' OCDemon (Raven)
>
>    OCDemon (Raven) <-> parallel cable <-> host EPP mode port
>
>Power up sequence:
>
>    1) Host
>    2) Target
>    3) OCDemon (Raven)
>    4) HDT MP Adapter
>
>Symptoms of the problem:
>
>    1) OCDemon host and target lights never go on.
>
>    2) When using the host HDT software to open a new workspace, only 1
>       processor is shown as available.
>
>    3) While completing the opening of this single processor workspace, a
>       warning window with the text below pops open:
>
>       +--------------------------------------------+
>       |Communication between HDT and               |
>       |Processor No. 0 has problem!                |
>       |                                            |
>       |Please check your HDT host                  |
>       |and target TAP connections.                 |
>       |                                            |
>       |Do you want to continue with incorrect info?|
>       +--------------------------------------------+
>    
>Possible clue to the solution:
>
>    Missing TDI/TDO jumpers or jumper headers?  There is a 2x3 header
>    pad (no header) directly between the P1 socket and the P0 DIMM
>    sockets that could be the correct place for these jumper headers.
>    Maybe all I need to do is add a 2x3 header there and trace the
>    routes of the six pins, hopefully back to the P0's HDT connector?
>    (I don't have access to the S2885's schematics.)
>
>    It seems that MP HDT must be enabled in this way.  I know that
>    reference boards have toggle switches for this purpose.
>
>Please respond with your suggestions.
>
>Thank you very much!
>
>Sincerely,
>
>Ken Fuchs <kfuchs at winternet.com>
>_______________________________________________
>Linuxbios mailing list
>Linuxbios at clustermatic.org
>http://www.clustermatic.org/mailman/listinfo/linuxbios
>


From ebiederman at lnxi.com  Wed Nov 10 09:49:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Nov 10 09:49:00 2004
Subject: romcc quesiton
In-Reply-To: <20041109225127.GA7807@openbios.org>
References: <3174569B9743D511922F00A0C943142306BA2E5A@TYANWEB>
	<Pine.LNX.4.58.0411091348170.15069@linux.site>
	<m3llda1x9l.fsf@maxwell.lnxi.com> <20041109225127.GA7807@openbios.org>
Message-ID: <m3is8dy94j.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at openbios.org> writes:

> * Eric W. Biederman <ebiederman at lnxi.com> [041109 23:19]:
> > > I'll try to find more if I get time today.
> > 
> > A complex case would be fine.  With abuild.sh I'm not seeing any compile
> > failures.
>  
> Something's wrong with the line numbers. I get
> incoherent_ht.c:191.8: warning:  "FIXME handle multiple chains!"
> which is 10 lines later..
> Does it ignore the lines with include statements?

It looks like it is multiline macros that are confusing things.
As the same construct in raminit.c gets the line numbers correct.

Now to see if I can track down why this is.

Eric


From ebiederman at lnxi.com  Wed Nov 10 10:32:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Nov 10 10:32:01 2004
Subject: romcc quesiton
In-Reply-To: <m3is8dy94j.fsf@maxwell.lnxi.com>
References: <3174569B9743D511922F00A0C943142306BA2E5A@TYANWEB>
	<Pine.LNX.4.58.0411091348170.15069@linux.site>
	<m3llda1x9l.fsf@maxwell.lnxi.com> <20041109225127.GA7807@openbios.org>
	<m3is8dy94j.fsf@maxwell.lnxi.com>
Message-ID: <m3hdnxwskv.fsf@maxwell.lnxi.com>

ebiederman at lnxi.com (Eric W. Biederman) writes:

> Stefan Reinauer <stepan at openbios.org> writes:
> 
> > * Eric W. Biederman <ebiederman at lnxi.com> [041109 23:19]:
> > > > I'll try to find more if I get time today.
> > > 
> > > A complex case would be fine.  With abuild.sh I'm not seeing any compile
> > > failures.
> >  
> > Something's wrong with the line numbers. I get
> > incoherent_ht.c:191.8: warning:  "FIXME handle multiple chains!"
> > which is 10 lines later..
> > Does it ignore the lines with include statements?
> 
> It looks like it is multiline macros that are confusing things.
> As the same construct in raminit.c gets the line numbers correct.
> 
> Now to see if I can track down why this is.

Ok.  This is clearly an issue with \ at the end of lines to
splice them together.  So to a certain the reporting is correct.
But I agree in practice that is wrong.

Fixing this is a little tricky. Either splice_lines needs to
insert a #line directive or I need to cleanup macro parsing a little
more.

Since the only thing incorrect is the line number I would like to
reproduce and fix the mysterious #if 0 does not work bug, before I 
touch that bit of code.

Eric


From ebiederman at lnxi.com  Wed Nov 10 12:10:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Nov 10 12:10:01 2004
Subject: [Davide <louigi600@yahoo.it>] Freebios and unsupported hardware ?
Message-ID: <m3lld9v9gs.fsf@maxwell.lnxi.com>


Perhaps the list can help.  At the moment I don't have time....

Eric



-------------- next part --------------
An embedded message was scrubbed...
From: Davide <louigi600 at yahoo.it>
Subject: Freebios and unsupported hardware ?
Date: Wed, 10 Nov 2004 09:17:44 +0100 (CET)
Size: 3490
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20041110/ca32f32d/attachment.mht>

From rminnich at lanl.gov  Wed Nov 10 12:16:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed Nov 10 12:16:01 2004
Subject: romcc quesiton
In-Reply-To: <m3llda1x9l.fsf@maxwell.lnxi.com>
References: <3174569B9743D511922F00A0C943142306BA2E5A@TYANWEB>
 <Pine.LNX.4.58.0411091348170.15069@linux.site> <m3llda1x9l.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.58.0411101139470.17517@linux.site>


On Tue, 9 Nov 2004, Eric W. Biederman wrote:

> A complex case would be fine.  With abuild.sh I'm not seeing any compile
> failures.

weird! The digitallogic adl855pc won't build for me at all ...


well, it will today. 

I deleted much lines of code and at some point it started to at least not 
get errors, although I don't even get a POST code when it starts up :-(

ron


From rminnich at lanl.gov  Wed Nov 10 12:19:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed Nov 10 12:19:00 2004
Subject: romcc quesiton
In-Reply-To: <20041109225127.GA7807@openbios.org>
References: <3174569B9743D511922F00A0C943142306BA2E5A@TYANWEB>
 <Pine.LNX.4.58.0411091348170.15069@linux.site> <m3llda1x9l.fsf@maxwell.lnxi.com>
 <20041109225127.GA7807@openbios.org>
Message-ID: <Pine.LNX.4.58.0411101142020.17517@linux.site>

I think I fixed part of my problem by removing // comments. 

interesting.


ron



From ebiederman at lnxi.com  Wed Nov 10 12:29:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Nov 10 12:29:00 2004
Subject: romcc quesiton
In-Reply-To: <3174569B9743D511922F00A0C943142306BA2E5A@TYANWEB>
References: <3174569B9743D511922F00A0C943142306BA2E5A@TYANWEB>
Message-ID: <m3is8dsfg0.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> I met that too, and I have remove some un converted code in E7501 raminit.c

Ok.  Checking out the old version I can reproduce this problem.

I would like to see Ron's case but YhLu I know what is causing the problem
for the old northbridge/e7501/raminit.c case.

The code is ignored but I am still attempting to convert the text
into C tokens.  Since C does nothing with a '$' character whenever
I hit one of those the tokenizer chokes.

While I am within my rights per the C standard it would be nice
to be more permissive when I am skipping code.

For unconverted assembly code I suggest enclosing it in multiple coments
or placing it in strings for the moment.

Eric


From ebiederman at lnxi.com  Wed Nov 10 12:46:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Nov 10 12:46:01 2004
Subject: romcc quesiton
In-Reply-To: <Pine.LNX.4.58.0411101139470.17517@linux.site>
References: <3174569B9743D511922F00A0C943142306BA2E5A@TYANWEB>
	<Pine.LNX.4.58.0411091348170.15069@linux.site>
	<m3llda1x9l.fsf@maxwell.lnxi.com>
	<Pine.LNX.4.58.0411101139470.17517@linux.site>
Message-ID: <m3is8dpli4.fsf@maxwell.lnxi.com>

"Ronald G. Minnich" <rminnich at lanl.gov> writes:

> On Tue, 9 Nov 2004, Eric W. Biederman wrote:
> 
> > A complex case would be fine.  With abuild.sh I'm not seeing any compile
> > failures.
> 
> weird! The digitallogic adl855pc won't build for me at all ...

I meant I was not seeing any new build failures.

My memory has it that the i855pm was one of the few ports that were never
completed, and had never built so I had filtered that one out.
 
> well, it will today. 
> 
> I deleted much lines of code and at some point it started to at least not 
> get errors, although I don't even get a POST code when it starts up :-(

raminit.c for that port has the same issues as the e7501 did.  In particular
it has unconverted assembly #if 0'd out.

Placing the unconverted assembly in strings, or simply commenting it out
will avoid the issue for now.

Next time can you an least give the me error message?
Having the string "unknown token" would at least have put me much closer
to knowing where to look.

Parsing but not compiling code inside an #if 0 is a totally different from simply
ignoring an #if 0.  Although I can see how it might not look differently.
If I had the error message at least I would have known where to look.

So currently we have found 3 quality of implementation issues
with romcc.
1) romcc tokenizes code inside an #if 0 and chokes on dollar signs '$'
2) romcc gets the line numbers wrong if you splice lines together with '\'
3) noninline functions don't always compile.

I will take a good hard look at the front end issues and see what I can
do.  It should be possible to fix those without making radical changes
to the rest of the code.

Eric


From rminnich at lanl.gov  Wed Nov 10 12:54:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed Nov 10 12:54:00 2004
Subject: romcc quesiton
In-Reply-To: <m3is8dpli4.fsf@maxwell.lnxi.com>
References: <3174569B9743D511922F00A0C943142306BA2E5A@TYANWEB>
 <Pine.LNX.4.58.0411091348170.15069@linux.site> <m3llda1x9l.fsf@maxwell.lnxi.com>
 <Pine.LNX.4.58.0411101139470.17517@linux.site> <m3is8dpli4.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.58.0411101214290.17593@linux.site>


On Wed, 10 Nov 2004, Eric W. Biederman wrote:

> My memory has it that the i855pm was one of the few ports that were never
> completed, and had never built so I had filtered that one out.

yes you are right. This port has new life and I want to get it back to 
"about as broken as it was" :)


> 
> raminit.c for that port has the same issues as the e7501 did.  In particular
> it has unconverted assembly #if 0'd out.

gone.

I only left things there until I was sure I did not want them. that code 
is gone. 

> Placing the unconverted assembly in strings, or simply commenting it out
> will avoid the issue for now.

Or removing it. 

> Next time can you an least give the me error message?
> Having the string "unknown token" would at least have put me much closer
> to knowing where to look.

There wasn't an error message at all. What happened is everything in #if 0 
went through and romcc doesn't much like trying to compile assembly code 
...

thanks 

ron


From ebiederman at lnxi.com  Wed Nov 10 13:04:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Nov 10 13:04:01 2004
Subject: romcc quesiton
In-Reply-To: <Pine.LNX.4.58.0411101214290.17593@linux.site>
References: <3174569B9743D511922F00A0C943142306BA2E5A@TYANWEB>
	<Pine.LNX.4.58.0411091348170.15069@linux.site>
	<m3llda1x9l.fsf@maxwell.lnxi.com>
	<Pine.LNX.4.58.0411101139470.17517@linux.site>
	<m3is8dpli4.fsf@maxwell.lnxi.com>
	<Pine.LNX.4.58.0411101214290.17593@linux.site>
Message-ID: <m37jot33l4.fsf@maxwell.lnxi.com>

"Ronald G. Minnich" <rminnich at lanl.gov> writes:

> On Wed, 10 Nov 2004, Eric W. Biederman wrote:
> > Placing the unconverted assembly in strings, or simply commenting it out
> > will avoid the issue for now.
> 
> Or removing it. 

True.
 
> > Next time can you an least give the me error message?
> > Having the string "unknown token" would at least have put me much closer
> > to knowing where to look.
> 
> There wasn't an error message at all. What happened is everything in #if 0 
> went through and romcc doesn't much like trying to compile assembly code 
> ...
> 

I see the error now.  That is how I know it exists.

I just did a build of the old digitalligic code.  From the end of the make:
./romcc ......
raminit.c:133.8: warning:  RAM_MRS -- using BROKEN hard-wired CAS 2.0. FIX ME SOON
raminit.c:792.17: 
unknown token
make[1]: *** [auto.inc] Error 1
make[1]: Leaving directory `/home/eric/projects/linuxbios/checkin/abuild/linuxbios-builds/digitallogic_adl855pc/normal'
make: *** [normal/linuxbios.rom] Error 1

It does say "unknown token" in there.  But just a cut and paste of the failure
would have been nice.

Eric


From rsmith at bitworks.com  Wed Nov 10 15:53:00 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Wed Nov 10 15:53:00 2004
Subject: Bitworks e-mail DOS
In-Reply-To: <m3is8dsfg0.fsf@maxwell.lnxi.com>
References: <3174569B9743D511922F00A0C943142306BA2E5A@TYANWEB> <m3is8dsfg0.fsf@maxwell.lnxi.com>
Message-ID: <41929388.20906@bitworks.com>

Bitworks.com is under a email DOS attack from bounced spam due to our 
forged address problem.

Our ISP had to disable e-mail for bitworks.com. As a result mail to 
Bitworks.com will fail.

I can send out but not receive.

You can reach me at smithbone at gmail.com

Spammers are the scum of the earth.

-- 
Richard A. Smith




From ginlin at nexcom.com.tw  Thu Nov 11 00:38:00 2004
From: ginlin at nexcom.com.tw (Gin)
Date: Thu Nov 11 00:38:00 2004
Subject: Tyan/s2735
In-Reply-To: <Pine.LNX.4.58.0411051426120.17125@ucontrol.mobiledns.com>
Message-ID: <000001c4c7bc$8a7a0c90$3501070a@nexcom.com.tw>

Steven,
Thanks for the info. I've got the ram up by filling the some values in
North Bridge(I reference a regular bios).

I have an essential question about the code base for Tyan/s2735. Has it
ever successfully built and run on that board? I have to make sure the
code I am currently building our board on is good.

Thanks   

-----Original Message-----
From: linuxbios-admin at clustermatic.org
[mailto:linuxbios-admin at clustermatic.org] On Behalf Of Steven James
Sent: Friday, November 05, 2004 10:40 PM
To: Gin Lin
Cc: linuxbios at clustermatic.org
Subject: Re: ram init

Greetings,

It's been a while since I've looked at it, but when I last looked, it
did
sometimes need power cycled to restart. I worked around that by making
the
kernel reboot by writing 0x0e to port 0xcf9. That causes the southbridge
to do a 3 second power off.

G'day,
sjames



On Fri, 5 Nov 2004, Gin Lin wrote:

> Does anyone know if the raminit.c under intel/E7501 is stable enough?
I am
> having a problem with the system reseting when it jumps to the first
address
> in the ram. Could the procedures of writing NorthBrige registers have
> problems?
>
> thanks,
> Gin
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>

||||| |||| |||||||||||||  |||
by Linux Labs International, Inc.
   Steven James, CTO

55 Marietta Street
Suite 1830
Atlanta, Ga 30303
866 824 9737 support

_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios



From rminnich at lanl.gov  Thu Nov 11 07:39:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Thu Nov 11 07:39:01 2004
Subject: minor changes
Message-ID: <Pine.LNX.4.58.0411110703050.19872@linux.site>

in loglevel.h, if ASM_CONSOLE_LOGLEVEL is defined, don't try to set it.
Set adl855pc ROM_SIZE to 1M
Other minor debug prints until we get this fixed.

We're almost as far along as we were before the Change :-)
CVS: 
----------------------------------------------------------------------
CVS: Enter Log.  Lines beginning with `CVS:' are removed automatically
CVS:
CVS: Committing in .
CVS:
CVS: Modified Files:
CVS:    include/console/loglevel.h
CVS:    mainboard/digitallogic/adl855pc/Options.lb
CVS:    mainboard/digitallogic/adl855pc/auto.c
CVS:    northbridge/intel/i855pm/raminit.c
CVS:    southbridge/intel/i82801dbm/i82801dbm_early_smbus.c
CVS: 
----------------------------------------------------------------------



From stepan at openbios.org  Thu Nov 11 09:17:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Thu Nov 11 09:17:00 2004
Subject: ppc targets
Message-ID: <20041111154204.GA27761@openbios.org>

The ppc targets fail because of src/cpu/ppc/ppc4xx/mem.c
struct mem_range is never ever defined. Is it struct lb_memory?!

I have a bunch of other patches lying around that I will commit if
nobody complains

Stefan

-------------- next part --------------
Index: src/arch/ppc/boot/linuxbios_table.c
===================================================================
RCS file: /cvsroot/freebios/freebios2/src/arch/ppc/boot/linuxbios_table.c,v
retrieving revision 1.7
diff -u -r1.7 linuxbios_table.c
--- src/arch/ppc/boot/linuxbios_table.c	27 Oct 2004 08:53:35 -0000	1.7
+++ src/arch/ppc/boot/linuxbios_table.c	11 Nov 2004 15:39:34 -0000
@@ -129,7 +129,7 @@
 }
 
 void lb_memory_range(struct lb_memory *mem,
-	uint32_t type, uint64_t start, uint64_t size)
+	uint32_t type, unsigned long start, unsigned long size)
 {
 	int entries;
 	entries = (mem->size - sizeof(*mem))/sizeof(mem->map[0]);
Index: src/arch/ppc/boot/linuxbios_table.h
===================================================================
RCS file: /cvsroot/freebios/freebios2/src/arch/ppc/boot/linuxbios_table.h,v
retrieving revision 1.1
diff -u -r1.1 linuxbios_table.h
--- src/arch/ppc/boot/linuxbios_table.h	13 Jun 2003 22:07:51 -0000	1.1
+++ src/arch/ppc/boot/linuxbios_table.h	11 Nov 2004 15:39:34 -0000
@@ -7,8 +7,6 @@
 
 /* This file holds function prototypes for building the linuxbios table. */
 unsigned long write_linuxbios_table(
-	unsigned long *processor_map, 
-	struct mem_range *ram,
 	unsigned long low_table_start, unsigned long low_table_end,
 	unsigned long rom_table_start, unsigned long rom_table_end);
 
Index: src/arch/ppc/lib/cpuid.c
===================================================================
RCS file: /cvsroot/freebios/freebios2/src/arch/ppc/lib/cpuid.c,v
retrieving revision 1.5
diff -u -r1.5 cpuid.c
--- src/arch/ppc/lib/cpuid.c	27 Oct 2004 08:53:35 -0000	1.5
+++ src/arch/ppc/lib/cpuid.c	11 Nov 2004 15:39:34 -0000
@@ -3,6 +3,7 @@
 
 #include "ppc.h"
 #include "ppcreg.h"
+#include <device/device.h>
 #include <console/console.h>
 
 void display_cpuid(struct device *cpu)
Index: src/include/cpu/cpu.h
===================================================================
RCS file: /cvsroot/freebios/freebios2/src/include/cpu/cpu.h,v
retrieving revision 1.4
diff -u -r1.4 cpu.h
--- src/include/cpu/cpu.h	16 Oct 2004 06:20:04 -0000	1.4
+++ src/include/cpu/cpu.h	11 Nov 2004 15:39:34 -0000
@@ -2,7 +2,7 @@
 #define CPU_CPU_H
 
 struct device;
-#include <arch/cpu.h>
+// #include <arch/cpu.h>
 
 void cpu_initialize(void);
 void initialize_cpus(struct bus *cpu_bus);

From YhLu at tyan.com  Thu Nov 11 11:15:00 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Nov 11 11:15:00 2004
Subject: Tyan/s2735
Message-ID: <3174569B9743D511922F00A0C943142306BA2F42@TYANWEB>

YES

-----Original Message-----
From: Gin [mailto:ginlin at nexcom.com.tw] 
Sent: Wednesday, November 10, 2004 11:03 PM
To: 'Steven James'
Cc: linuxbios at clustermatic.org
Subject: Tyan/s2735

Steven,
Thanks for the info. I've got the ram up by filling the some values in
North Bridge(I reference a regular bios).

I have an essential question about the code base for Tyan/s2735. Has it
ever successfully built and run on that board? I have to make sure the
code I am currently building our board on is good.

Thanks   

-----Original Message-----
From: linuxbios-admin at clustermatic.org
[mailto:linuxbios-admin at clustermatic.org] On Behalf Of Steven James
Sent: Friday, November 05, 2004 10:40 PM
To: Gin Lin
Cc: linuxbios at clustermatic.org
Subject: Re: ram init

Greetings,

It's been a while since I've looked at it, but when I last looked, it
did
sometimes need power cycled to restart. I worked around that by making
the
kernel reboot by writing 0x0e to port 0xcf9. That causes the southbridge
to do a 3 second power off.

G'day,
sjames



On Fri, 5 Nov 2004, Gin Lin wrote:

> Does anyone know if the raminit.c under intel/E7501 is stable enough?
I am
> having a problem with the system reseting when it jumps to the first
address
> in the ram. Could the procedures of writing NorthBrige registers have
> problems?
>
> thanks,
> Gin
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>

||||| |||| |||||||||||||  |||
by Linux Labs International, Inc.
   Steven James, CTO

55 Marietta Street
Suite 1830
Atlanta, Ga 30303
866 824 9737 support

_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios

_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From stepan at openbios.org  Thu Nov 11 14:45:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Thu Nov 11 14:45:01 2004
Subject: autobuild statistics
Message-ID: <20041111211035.GA10363@openbios.org>

Hi,

The abuild script checks for new checkins now every 4h and logs are
placed at: http://snapshots.linuxbios.org/stats/

BTW, the latest changes made things a little more dramatic again.
In size, compile time and compile success.

Stefan





From stepan at openbios.org  Thu Nov 11 15:02:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Thu Nov 11 15:02:00 2004
Subject: autobuild statistics
In-Reply-To: <20041111211035.GA10363@openbios.org>
References: <20041111211035.GA10363@openbios.org>
Message-ID: <20041111212731.GA10646@openbios.org>

* Stefan Reinauer <stepan at openbios.org> [041111 22:10]:
> BTW, the latest changes made things a little more dramatic again.
> In size, compile time and compile success.

With my current board I get these:
romcc_io.h:106.27: coherent_ht.c:585.48: coherent_ht.c:643.52:
auto.c:221.47: warning: edge reg %unset
romcc_io.h:106.27: coherent_ht.c:585.48: coherent_ht.c:643.52:
auto.c:221.47: warning:  copy 0x85b5f48
romcc_io.h:106.27: coherent_ht.c:585.48: coherent_ht.c:643.52:
auto.c:221.47: warning:  or 0x84ba7c8
romcc_io.h:107.37: coherent_ht.c:585.48: coherent_ht.c:643.52:
auto.c:221.47: warning:  and 0x84ba8f8
romcc_io.h:107.38: coherent_ht.c:585.48: coherent_ht.c:643.52:
auto.c:221.47: warning: edge reg %eax
romcc_io.h:107.38: coherent_ht.c:585.48: coherent_ht.c:643.52:
auto.c:221.47: warning:  copy 0x8774fd0
romcc_io.h:107.38: coherent_ht.c:585.48: coherent_ht.c:643.52:
auto.c:221.47: warning:  or 0x84ba9b8
[..]
coherent_ht.c:451.1: coherent_ht.c:637.46: auto.c:221.47:
too few registers

Stefan



From YhLu at tyan.com  Thu Nov 11 15:06:01 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Nov 11 15:06:01 2004
Subject: autobuild statistics
Message-ID: <3174569B9743D511922F00A0C943142306BA2F62@TYANWEB>

Someone (who recent format the coherent_ht.c) 
need to 

static void fill_row(u8 node, u8 row, u32 value)
{
        pci_write_config32(NODE_HT(node), 0x40+(row<<2), value);
}
Before

#if CONFIG_MAX_CPUS > 1

to support ONE AMD K8

YH
-----Original Message-----
From: Stefan Reinauer [mailto:stepan at openbios.org] 
Sent: Thursday, November 11, 2004 1:11 PM
To: linuxbios at clustermatic.org
Subject: autobuild statistics

Hi,

The abuild script checks for new checkins now every 4h and logs are
placed at: http://snapshots.linuxbios.org/stats/

BTW, the latest changes made things a little more dramatic again.
In size, compile time and compile success.

Stefan



_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From YhLu at tyan.com  Thu Nov 11 18:52:00 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Nov 11 18:52:00 2004
Subject: mtrr
Message-ID: <3174569B9743D511922F00A0C943142306BA2F72@TYANWEB>

I just found the mtrr after booting is not right.

~ # cat /proc/mtrr
reg00: base=0x00000000 (   0MB), size=985088MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=984064MB: write-back, count=1
reg02: base=0xc0000000 (3072MB), size=983296MB: write-back, count=1

and it should be

reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg02: base=0xc0000000 (3072MB), size=256MB: write-back, count=1

and it is has 98340MB more = 0xf0 0000 0000.

Regards

YH


From YhLu at tyan.com  Thu Nov 11 19:28:00 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Nov 11 19:28:00 2004
Subject: mtrr
Message-ID: <3174569B9743D511922F00A0C943142306BA2F73@TYANWEB>

On 2.4.22 it becomes to 
~ # cat /proc/mtrr
reg00: base=0x00000000 (   0MB), size=32768MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=16384MB: write-back, count=1
reg02: base=0xc0000000 (3072MB), size=4096MB: write-back, count=1

x 16

-----Original Message-----
From: YhLu 
Sent: Thursday, November 11, 2004 5:24 PM
To: ebiederman at lnxi.com; Ronald G. Minnich
Cc: linuxbios at clustermatic.org
Subject: mtrr

I just found the mtrr after booting is not right.

~ # cat /proc/mtrr
reg00: base=0x00000000 (   0MB), size=985088MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=984064MB: write-back, count=1
reg02: base=0xc0000000 (3072MB), size=983296MB: write-back, count=1

and it should be

reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg02: base=0xc0000000 (3072MB), size=256MB: write-back, count=1

and it is has 98340MB more = 0xf0 0000 0000.

Regards

YH
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From YhLu at tyan.com  Thu Nov 11 19:36:00 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Nov 11 19:36:00 2004
Subject: mtrr
Message-ID: <3174569B9743D511922F00A0C943142306BA2F74@TYANWEB>

In the cpu/x86/mtrr/mtrr.c

#warning "FIXME I do not properly handle address more than 36 physical
address bits"
#ifdef k8
# define ADDRESS_BITS 40
#else
# define ADDRESS_BITS 36
#endif
#define ADDRESS_BITS_HIGH (ADDRESS_BITS - 32)
#define ADDRESS_MASK_HIGH ((1u << ADDRESS_BITS_HIGH) - 1)

It seems someone already remove k8 from Option.lb

Then ....

Regards

YH

-----Original Message-----
From: YhLu 
Sent: Thursday, November 11, 2004 6:00 PM
To: YhLu; ebiederman at lnxi.com; Ronald G. Minnich
Cc: linuxbios at clustermatic.org
Subject: RE: mtrr

On 2.4.22 it becomes to 
~ # cat /proc/mtrr
reg00: base=0x00000000 (   0MB), size=32768MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=16384MB: write-back, count=1
reg02: base=0xc0000000 (3072MB), size=4096MB: write-back, count=1

x 16

-----Original Message-----
From: YhLu 
Sent: Thursday, November 11, 2004 5:24 PM
To: ebiederman at lnxi.com; Ronald G. Minnich
Cc: linuxbios at clustermatic.org
Subject: mtrr

I just found the mtrr after booting is not right.

~ # cat /proc/mtrr
reg00: base=0x00000000 (   0MB), size=985088MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=984064MB: write-back, count=1
reg02: base=0xc0000000 (3072MB), size=983296MB: write-back, count=1

and it should be

reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg02: base=0xc0000000 (3072MB), size=256MB: write-back, count=1

and it is has 98340MB more = 0xf0 0000 0000.

Regards

YH
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From ebiederman at lnxi.com  Thu Nov 11 19:54:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Nov 11 19:54:00 2004
Subject: mtrr
In-Reply-To: <3174569B9743D511922F00A0C943142306BA2F74@TYANWEB>
References: <3174569B9743D511922F00A0C943142306BA2F74@TYANWEB>
Message-ID: <m3k6srbyh9.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> In the cpu/x86/mtrr/mtrr.c
> 
> #warning "FIXME I do not properly handle address more than 36 physical
> address bits"
> #ifdef k8
> # define ADDRESS_BITS 40
> #else
> # define ADDRESS_BITS 36
> #endif
> #define ADDRESS_BITS_HIGH (ADDRESS_BITS - 32)
> #define ADDRESS_MASK_HIGH ((1u << ADDRESS_BITS_HIGH) - 1)
> 
> It seems someone already remove k8 from Option.lb
> 
> Then ....
> 
> Regards

Interesting.  The mtrr's actually work and the kernel is confused.

However what we need to do is call the appropriate cpuid function
to compute it or pass in the number of address bits.  It should not be
a compile time option, at least not in the generic code.  What
happens when we get can plug in cpus with different address bit
limits.

Eric


From ebiederman at lnxi.com  Thu Nov 11 19:58:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Nov 11 19:58:01 2004
Subject: autobuild statistics
In-Reply-To: <20041111212731.GA10646@openbios.org>
References: <20041111211035.GA10363@openbios.org>
	<20041111212731.GA10646@openbios.org>
Message-ID: <m3lld7956k.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at openbios.org> writes:

> * Stefan Reinauer <stepan at openbios.org> [041111 22:10]:
> > BTW, the latest changes made things a little more dramatic again.
> > In size, compile time and compile success.
> 
> With my current board I get these:
> romcc_io.h:106.27: coherent_ht.c:585.48: coherent_ht.c:643.52:
> auto.c:221.47: warning: edge reg %unset
> romcc_io.h:106.27: coherent_ht.c:585.48: coherent_ht.c:643.52:
> auto.c:221.47: warning:  copy 0x85b5f48
> romcc_io.h:106.27: coherent_ht.c:585.48: coherent_ht.c:643.52:
> auto.c:221.47: warning:  or 0x84ba7c8
> romcc_io.h:107.37: coherent_ht.c:585.48: coherent_ht.c:643.52:
> auto.c:221.47: warning:  and 0x84ba8f8
> romcc_io.h:107.38: coherent_ht.c:585.48: coherent_ht.c:643.52:
> auto.c:221.47: warning: edge reg %eax
> romcc_io.h:107.38: coherent_ht.c:585.48: coherent_ht.c:643.52:
> auto.c:221.47: warning:  copy 0x8774fd0
> romcc_io.h:107.38: coherent_ht.c:585.48: coherent_ht.c:643.52:
> auto.c:221.47: warning:  or 0x84ba9b8
> [..]
> coherent_ht.c:451.1: coherent_ht.c:637.46: auto.c:221.47:
> too few registers

What happens if you don't compile in the spew messages?

Eric


From ebiederman at lnxi.com  Thu Nov 11 20:02:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Nov 11 20:02:01 2004
Subject: ppc targets
In-Reply-To: <20041111154204.GA27761@openbios.org>
References: <20041111154204.GA27761@openbios.org>
Message-ID: <m3hdnv94zo.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at openbios.org> writes:

> The ppc targets fail because of src/cpu/ppc/ppc4xx/mem.c
> struct mem_range is never ever defined. Is it struct lb_memory?!

That is because of the big change where sizeram was removed.
I think the definition originally sat in src/include/mem.h 
Which has been removed, because it is no longer used.

Getting the ppc port to use the device tree, looks like an interesting
task.
 
> I have a bunch of other patches lying around that I will commit if
> nobody complains
> 
> Stefan
> 
> 
> Index: src/arch/ppc/boot/linuxbios_table.c
> ===================================================================
> RCS file: /cvsroot/freebios/freebios2/src/arch/ppc/boot/linuxbios_table.c,v
> retrieving revision 1.7
> diff -u -r1.7 linuxbios_table.c
> --- src/arch/ppc/boot/linuxbios_table.c	27 Oct 2004 08:53:35 -0000	1.7
> +++ src/arch/ppc/boot/linuxbios_table.c	11 Nov 2004 15:39:34 -0000
> @@ -129,7 +129,7 @@
>  }
>  
>  void lb_memory_range(struct lb_memory *mem,
> -	uint32_t type, uint64_t start, uint64_t size)
> +	uint32_t type, unsigned long start, unsigned long size)
>  {
>  	int entries;
>  	entries = (mem->size - sizeof(*mem))/sizeof(mem->map[0]);
> Index: src/arch/ppc/boot/linuxbios_table.h
> ===================================================================
> RCS file: /cvsroot/freebios/freebios2/src/arch/ppc/boot/linuxbios_table.h,v
> retrieving revision 1.1
> diff -u -r1.1 linuxbios_table.h
> --- src/arch/ppc/boot/linuxbios_table.h	13 Jun 2003 22:07:51 -0000	1.1
> +++ src/arch/ppc/boot/linuxbios_table.h	11 Nov 2004 15:39:34 -0000
> @@ -7,8 +7,6 @@
>  
>  /* This file holds function prototypes for building the linuxbios table. */
>  unsigned long write_linuxbios_table(
> -	unsigned long *processor_map, 
> -	struct mem_range *ram,
>  	unsigned long low_table_start, unsigned long low_table_end,
>  	unsigned long rom_table_start, unsigned long rom_table_end);
>  
> Index: src/arch/ppc/lib/cpuid.c
> ===================================================================
> RCS file: /cvsroot/freebios/freebios2/src/arch/ppc/lib/cpuid.c,v
> retrieving revision 1.5
> diff -u -r1.5 cpuid.c
> --- src/arch/ppc/lib/cpuid.c	27 Oct 2004 08:53:35 -0000	1.5
> +++ src/arch/ppc/lib/cpuid.c	11 Nov 2004 15:39:34 -0000
> @@ -3,6 +3,7 @@
>  
>  #include "ppc.h"
>  #include "ppcreg.h"
> +#include <device/device.h>
>  #include <console/console.h>
>  
>  void display_cpuid(struct device *cpu)
> Index: src/include/cpu/cpu.h
> ===================================================================
> RCS file: /cvsroot/freebios/freebios2/src/include/cpu/cpu.h,v
> retrieving revision 1.4
> diff -u -r1.4 cpu.h
> --- src/include/cpu/cpu.h	16 Oct 2004 06:20:04 -0000	1.4
> +++ src/include/cpu/cpu.h	11 Nov 2004 15:39:34 -0000
> @@ -2,7 +2,7 @@
>  #define CPU_CPU_H
>  
>  struct device;
> -#include <arch/cpu.h>
> +// #include <arch/cpu.h>
>  
>  void cpu_initialize(void);
>  void initialize_cpus(struct bus *cpu_bus);

The fix here is to add an arch/ppc/include/arch/cpu.h.
It can be empty...

The rest look fine.

Eric


From ebiederman at lnxi.com  Thu Nov 11 20:04:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Nov 11 20:04:01 2004
Subject: autobuild statistics
In-Reply-To: <20041111211035.GA10363@openbios.org>
References: <20041111211035.GA10363@openbios.org>
Message-ID: <m3d5yj94vm.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at openbios.org> writes:

> Hi,
> 
> The abuild script checks for new checkins now every 4h and logs are
> placed at: http://snapshots.linuxbios.org/stats/
> 
> BTW, the latest changes made things a little more dramatic again.
> In size, compile time and compile success.

Thanks.  Sorry about that.

Actually being able to boot with a subset of cpus is rather important
to me.  And the changes to coherent_ht.c were needed to get that
to work.  I thought I had merged that earlier but it turned out 
I hadn't.

At this point I probably need to retest that bit of code, and make
certain it is still working.

Eric


From YhLu at tyan.com  Thu Nov 11 20:23:00 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Nov 11 20:23:00 2004
Subject: mtrr
Message-ID: <3174569B9743D511922F00A0C943142306BA2F78@TYANWEB>

x86_setup_mtrrs should be split to

x86_setup_fixed_mtrrs
x86_setup_var_mtrrs
x86_setup_enable_mtrrs

and for Opteron it can reuse 
x86_setup_var_mtrrs
x86_setup_enable_mtrrs

and 
x86_setup_var_mtrrs can take the cupid or sth as parameter to find out 40bit
or 32 bit.

YH

-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Thursday, November 11, 2004 6:20 PM
To: YhLu
Cc: 'Ronald G. Minnich'; 'linuxbios at clustermatic.org'
Subject: Re: mtrr

YhLu <YhLu at tyan.com> writes:

> In the cpu/x86/mtrr/mtrr.c
> 
> #warning "FIXME I do not properly handle address more than 36 physical
> address bits"
> #ifdef k8
> # define ADDRESS_BITS 40
> #else
> # define ADDRESS_BITS 36
> #endif
> #define ADDRESS_BITS_HIGH (ADDRESS_BITS - 32)
> #define ADDRESS_MASK_HIGH ((1u << ADDRESS_BITS_HIGH) - 1)
> 
> It seems someone already remove k8 from Option.lb
> 
> Then ....
> 
> Regards

Interesting.  The mtrr's actually work and the kernel is confused.

However what we need to do is call the appropriate cpuid function
to compute it or pass in the number of address bits.  It should not be
a compile time option, at least not in the generic code.  What
happens when we get can plug in cpus with different address bit
limits.

Eric


From gwatson at lanl.gov  Thu Nov 11 20:31:00 2004
From: gwatson at lanl.gov (Greg Watson)
Date: Thu Nov 11 20:31:00 2004
Subject: ppc targets
In-Reply-To: <20041111154204.GA27761@openbios.org>
References: <20041111154204.GA27761@openbios.org>
Message-ID: <668A5D58-3456-11D9-8723-000D932F4B4A@lanl.gov>

Let me have a look. I'm back from travel tomorrow....

Greg

On Nov 11, 2004, at 8:42 AM, Stefan Reinauer wrote:

> The ppc targets fail because of src/cpu/ppc/ppc4xx/mem.c
> struct mem_range is never ever defined. Is it struct lb_memory?!
>
> I have a bunch of other patches lying around that I will commit if
> nobody complains
>
> Stefan
>
> <ppc.diff>



From ollie at lanl.gov  Fri Nov 12 11:42:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri Nov 12 11:42:00 2004
Subject: Problem with AMD HDT setup for Tyan S2885 - LinuxBIOS debugging
In-Reply-To: <200411092035.iA9KZ6GN016683@tundra.winternet.com>
References: <200411092035.iA9KZ6GN016683@tundra.winternet.com>
Message-ID: <1100282854.1119.6.camel@exponential.lanl.gov>

On Tue, 2004-11-09 at 13:35, Ken Fuchs wrote:
> 
>        +--------------------------------------------+
>        |Communication between HDT and               |
>        |Processor No. 0 has problem!                |
>        |                                            |
>        |Please check your HDT host                  |
>        |and target TAP connections.                 |
>        |                                            |
>        |Do you want to continue with incorrect info?|
>        +--------------------------------------------+
>     

You must be using some parallel port without EPP mode. Go to the
BIOS setup and configure it correctly.

Ollie




From ollie at lanl.gov  Fri Nov 12 13:54:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri Nov 12 13:54:01 2004
Subject: ppc targets
In-Reply-To: <20041111154204.GA27761@openbios.org>
References: <20041111154204.GA27761@openbios.org>
Message-ID: <1100290761.1119.8.camel@exponential.lanl.gov>

On Thu, 2004-11-11 at 08:42, Stefan Reinauer wrote:
> The ppc targets fail because of src/cpu/ppc/ppc4xx/mem.c
> struct mem_range is never ever defined. Is it struct lb_memory?!
> 
> I have a bunch of other patches lying around that I will commit if
> nobody complains
> 
> Stefan
> 

You marked the #include<arch/cpu.h> in inlcude/cpu/cpu.h. It breaks all 
x86 port !!!

Ollie




From stepan at openbios.org  Fri Nov 12 14:37:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Fri Nov 12 14:37:01 2004
Subject: ppc targets
In-Reply-To: <1100290761.1119.8.camel@exponential.lanl.gov>
References: <20041111154204.GA27761@openbios.org> <1100290761.1119.8.camel@exponential.lanl.gov>
Message-ID: <20041112210211.GA8019@openbios.org>

* Li-Ta Lo <ollie at lanl.gov> [041112 21:19]:
> 
> You marked the #include<arch/cpu.h> in inlcude/cpu/cpu.h. It breaks all 
> x86 port !!!
 
Ouch. Fixed.

<brown-paperbag>Stefan</brown-paperbag>




From rminnich at lanl.gov  Fri Nov 12 15:49:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Nov 12 15:49:01 2004
Subject: ppc targets
In-Reply-To: <20041111154204.GA27761@openbios.org>
References: <20041111154204.GA27761@openbios.org>
Message-ID: <Pine.LNX.4.58.0411121514140.23297@linux.site>


On Thu, 11 Nov 2004, Stefan Reinauer wrote:

> The ppc targets fail because of src/cpu/ppc/ppc4xx/mem.c
> struct mem_range is never ever defined. Is it struct lb_memory?!

this changed recently. 

> I have a bunch of other patches lying around that I will commit if
> nobody complains

what are these patches doing ?

ron


From stepan at openbios.org  Fri Nov 12 16:13:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Fri Nov 12 16:13:00 2004
Subject: ppc targets
In-Reply-To: <Pine.LNX.4.58.0411121514140.23297@linux.site>
References: <20041111154204.GA27761@openbios.org>
Message-ID: <20041112223833.GA11057@openbios.org>

Ron,

I'll give a quick comment. Some patches are fixing smaller issues
where prototypes and their functions drifted because a prototype was
changed due to x86 merger but the ppc function was not adopted or
similar. Others add missing includes. With these patches I get all PPC
ports built up to the point of the missing mem_range structure which i
did not attempt to fix.

> --- src/arch/ppc/boot/linuxbios_table.c	27 Oct 2004 08:53:35 -0000	1.7
> +++ src/arch/ppc/boot/linuxbios_table.c	11 Nov 2004 15:39:34 -0000
> @@ -129,7 +129,7 @@
>  void lb_memory_range(struct lb_memory *mem,
> -	uint32_t type, uint64_t start, uint64_t size)
> +	uint32_t type, unsigned long start, unsigned long size)
>  {

The prototype in linuxbios_table.h uses ulongs too. This would be the
same on ppc64 platforms, but on ppc ulong is just 32bit (pointer size)

> diff -u -r1.1 linuxbios_table.h
> --- src/arch/ppc/boot/linuxbios_table.h	13 Jun 2003 22:07:51 -0000	1.1
> +++ src/arch/ppc/boot/linuxbios_table.h	11 Nov 2004 15:39:34 -0000
> @@ -7,8 +7,6 @@
>  unsigned long write_linuxbios_table(
> -	unsigned long *processor_map, 
> -	struct mem_range *ram,
>  	unsigned long low_table_start, unsigned long low_table_end,
>  	unsigned long rom_table_start, unsigned long rom_table_end);
 
These are unused and unimplemented in the actual function.
 
> --- src/arch/ppc/lib/cpuid.c	27 Oct 2004 08:53:35 -0000	1.5
> +++ src/arch/ppc/lib/cpuid.c	11 Nov 2004 15:39:34 -0000
> @@ -3,6 +3,7 @@
>  #include "ppcreg.h"
> +#include <device/device.h>
>  #include <console/console.h>

missing include

> --- src/include/cpu/cpu.h	16 Oct 2004 06:20:04 -0000	1.4
> +++ src/include/cpu/cpu.h	11 Nov 2004 15:39:34 -0000
> @@ -2,7 +2,7 @@
>  #define CPU_CPU_H
>  
>  struct device;
> -#include <arch/cpu.h>
> +// #include <arch/cpu.h>
>  
>  void cpu_initialize(void);
>  void initialize_cpus(struct bus *cpu_bus);

The file was not there on PPC. I created it now and reversed above
patch.

Stefan




From ebiederman at lnxi.com  Fri Nov 12 18:44:02 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Nov 12 18:44:02 2004
Subject: ppc targets
In-Reply-To: <549D62F4-34FE-11D9-8723-000D932F4B4A@computer.org>
References: <20041111154204.GA27761@openbios.org>
	<m3hdnv94zo.fsf@maxwell.lnxi.com>
	<549D62F4-34FE-11D9-8723-000D932F4B4A@computer.org>
Message-ID: <m3wtwqr1uk.fsf@maxwell.lnxi.com>

Greg Watson <g.watson at computer.org> writes:

> On Nov 11, 2004, at 7:27 PM, Eric W. Biederman wrote:
> 
> > Stefan Reinauer <stepan at openbios.org> writes:
> >
> >> The ppc targets fail because of src/cpu/ppc/ppc4xx/mem.c
> >> struct mem_range is never ever defined. Is it struct lb_memory?!
> >
> > That is because of the big change where sizeram was removed.
> > I think the definition originally sat in src/include/mem.h
> > Which has been removed, because it is no longer used.
> >
> 
> So where/how is this done now? 

read_resources of an appropriate device now returns the information.


> What else has been changed? 

Everything (short of interrupts) is now done through the device tree.
The static device tree now uses the same nodes as the dynamic device tree.

> It would be nice if a change like this was accompanied by a
> description of what has been done, particularly if targets are left
> for someone else to update.

It was not the intention to leave this for someone else to update.
The ppc ports were simply at the end of the list.  And beyond
that their structure does not much resemble the structure of
the other ports on x86.

Just glancing at the ppc code I have not seen an appropriate device
to attach the code to.

I was planning on looking into the powerpc code in the next couple of
days.  To see if I could sort this out.

Eric


From kfuchs at winternet.com  Fri Nov 12 20:35:00 2004
From: kfuchs at winternet.com (Ken Fuchs)
Date: Fri Nov 12 20:35:00 2004
Subject: Problem with AMD HDT setup for Tyan S2885 - LinuxBIOS debugging
In-Reply-To: <1100282854.1119.6.camel@exponential.lanl.gov> (message from
	Li-Ta Lo on Fri, 12 Nov 2004 11:07:34 -0700)
References: <200411092035.iA9KZ6GN016683@tundra.winternet.com> <1100282854.1119.6.camel@exponential.lanl.gov>
Message-ID: <200411130300.iAD30co14081@ecstasy1.winternet.com>

>On Tue, 2004-11-09 at 13:35, Ken Fuchs wrote:

>>        +--------------------------------------------+
>>        |Communication between HDT and               |
>>        |Processor No. 0 has problem!                |
>>        |                                            |
>>        |Please check your HDT host                  |
>>        |and target TAP connections.                 |
>>        |                                            |
>>        |Do you want to continue with incorrect info?|
>>        +--------------------------------------------+

Ollie wrote:

>You must be using some parallel port without EPP mode. Go to the
>BIOS setup and configure it correctly.

Thanks for the suggestion.  However, I already had my parallel port set
to EPP in the BIOS of the host machine.

The solution for the S2885 was adding two three pin jumpers at J94 & J95
as suggested earlier by one of Tyan's engineer via YhLu.  Plus
connecting pins 2 & 3 of jumper J94 and connecting pins 1 & 2 of jumper
J95.  Pin 1 is the closest one to the board's nearest edge.

YhLu wrote:

>HW engineer said 
>"on S2885, put jumper caps on J94 pin2 and pin3; J95 pin1 and pin2 to make
>HDT and MP HDT work.
> J94 and J95 are in middle of the area between bootable CPU memory modules
>and secondary CPU socket. the pin1 is the pin more close to the board edge
>and power connectors."

Thank you everyone for responding to my question.

Sincerely,

Ken Fuchs <kfuchs at winternet.com>


From zhushisongzhu at yahoo.com  Sat Nov 13 06:18:00 2004
From: zhushisongzhu at yahoo.com (zhu shi song)
Date: Sat Nov 13 06:18:00 2004
Subject: i845 MB progress
Message-ID: <20041113124334.99170.qmail@web13207.mail.yahoo.com>

Now I can boot my i845 MB successfully with kernel
2.4.27.  please see content of /proc/pci:
PCI devices found:
  Bus  0, device   0, function  0:
    Host bridge: Intel Corp. 82845G/GL [Brookdale-G]
Chipset Host Bridge (rev 3)
.
      Prefetchable 32 bit memory at 0xe0000000
[0xe3ffffff].
  Bus  0, device   2, function  0:
    VGA compatible controller: Intel Corp. 82845G/GL
[Brookdale-G] Chipset Integ
rated Graphics Device (rev 3).
      IRQ 11.
      Prefetchable 32 bit memory at 0xd0000000
[0xd7ffffff].
      Non-prefetchable 32 bit memory at 0xdff80000
[0xdfffffff].
  Bus  3, device  10, function  0:
    Ethernet controller: Realtek Semiconductor Co.,
Ltd. RTL-8139/8139C/8139C+ (
rev 16).
      IRQ 3.
      Master Capable.  Latency=32.  Min Gnt=32.Max
Lat=64.
      I/O at 0xcc00 [0xccff].
      Non-prefetchable 32 bit memory at 0xdfdfff00
[0xdfdfffff].

It seemed that linux assigned correct irq to rtl8139.
But there was some trouble with ethernet.
(1)insmod 8139too  ---> ok
(2)ifconfig eth0 192.12.10.167 ---> error
linux box hangup and the driver output "rtl8139:
exiting interrupt, intr_status=0000" continuously.

my settings:
(1)don't set FEC0__xxxx regs
(2) 0x4d0=28
    0x4d1=1c
    0x21=e8
    0xA1=3f

 who has met the same problem and can give some glues
to solve it?
  tks
  zhu








		
__________________________________ 
Do you Yahoo!? 
Check out the new Yahoo! Front Page. 
www.yahoo.com 
 



From pyro at linuxlabs.com  Sun Nov 14 14:05:00 2004
From: pyro at linuxlabs.com (Steven James)
Date: Sun Nov 14 14:05:00 2004
Subject: Tyan/s2735
In-Reply-To: <000001c4c7bc$8a7a0c90$3501070a@nexcom.com.tw>
References: <000001c4c7bc$8a7a0c90$3501070a@nexcom.com.tw>
Message-ID: <Pine.LNX.4.58.0411142029120.21597@ucontrol.mobiledns.com>

Greetings,

I have successfully used the v1 code on that board. Things have been in
flux since then, and I haven't had time to test a recent CVS checkout or
the v2 tree.

G'day,
sjames


On Thu, 11 Nov 2004, Gin wrote:

> Steven,
> Thanks for the info. I've got the ram up by filling the some values in
> North Bridge(I reference a regular bios).
>
> I have an essential question about the code base for Tyan/s2735. Has it
> ever successfully built and run on that board? I have to make sure the
> code I am currently building our board on is good.
>
> Thanks
>
> -----Original Message-----
> From: linuxbios-admin at clustermatic.org
> [mailto:linuxbios-admin at clustermatic.org] On Behalf Of Steven James
> Sent: Friday, November 05, 2004 10:40 PM
> To: Gin Lin
> Cc: linuxbios at clustermatic.org
> Subject: Re: ram init
>
> Greetings,
>
> It's been a while since I've looked at it, but when I last looked, it
> did
> sometimes need power cycled to restart. I worked around that by making
> the
> kernel reboot by writing 0x0e to port 0xcf9. That causes the southbridge
> to do a 3 second power off.
>
> G'day,
> sjames
>
>
>
> On Fri, 5 Nov 2004, Gin Lin wrote:
>
> > Does anyone know if the raminit.c under intel/E7501 is stable enough?
> I am
> > having a problem with the system reseting when it jumps to the first
> address
> > in the ram. Could the procedures of writing NorthBrige registers have
> > problems?
> >
> > thanks,
> > Gin
> > _______________________________________________
> > Linuxbios mailing list
> > Linuxbios at clustermatic.org
> > http://www.clustermatic.org/mailman/listinfo/linuxbios
> >
>
> ||||| |||| |||||||||||||  |||
> by Linux Labs International, Inc.
>    Steven James, CTO
>
> 55 Marietta Street
> Suite 1830
> Atlanta, Ga 30303
> 866 824 9737 support
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>

||||| |||| |||||||||||||  |||
by Linux Labs International, Inc.
   Steven James, CTO

55 Marietta Street
Suite 1830
Atlanta, Ga 30303
866 824 9737 support



From rminnich at lanl.gov  Sun Nov 14 14:55:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Sun Nov 14 14:55:01 2004
Subject: ppc targets
In-Reply-To: <20041112223833.GA11057@openbios.org>
References: <20041111154204.GA27761@openbios.org> <20041112223833.GA11057@openbios.org>
Message-ID: <Pine.LNX.4.58.0411141420580.28529@linux.site>

those changes look fine.

ron



From rminnich at lanl.gov  Sun Nov 14 15:01:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Sun Nov 14 15:01:01 2004
Subject: i845 MB progress
In-Reply-To: <20041113124334.99170.qmail@web13207.mail.yahoo.com>
References: <20041113124334.99170.qmail@web13207.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0411141426320.28529@linux.site>

do you want to send me patches?

ron



From rminnich at lanl.gov  Sun Nov 14 15:08:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Sun Nov 14 15:08:01 2004
Subject: vgabios/testbios
Message-ID: <Pine.LNX.4.58.0411141433240.28529@linux.site>

I've just added a few new fixes to vgabios, and expect to add more as I 
get it to the point that it can run this BIOS for the 855gm board. Just 
FYI.

ron


From ginlin at nexcom.com.tw  Sun Nov 14 19:16:00 2004
From: ginlin at nexcom.com.tw (Gin)
Date: Sun Nov 14 19:16:00 2004
Subject: Tyan/s2735
In-Reply-To: <Pine.LNX.4.58.0411142029120.21597@ucontrol.mobiledns.com>
Message-ID: <000401c4cab4$11ebda10$4f01060a@nexcom.com.tw>

Thanks Steven,
Do you think you will have time testing this on V2 tree? I've been
working on that code base and keep having problems with it. 

Gin

-----Original Message-----
From: linuxbios-admin at clustermatic.org
[mailto:linuxbios-admin at clustermatic.org] On Behalf Of Steven James
Sent: Monday, November 15, 2004 4:31 AM
To: Gin
Cc: linuxbios at clustermatic.org
Subject: Re: Tyan/s2735

Greetings,

I have successfully used the v1 code on that board. Things have been in
flux since then, and I haven't had time to test a recent CVS checkout or
the v2 tree.

G'day,
sjames


On Thu, 11 Nov 2004, Gin wrote:

> Steven,
> Thanks for the info. I've got the ram up by filling the some values in
> North Bridge(I reference a regular bios).
>
> I have an essential question about the code base for Tyan/s2735. Has
it
> ever successfully built and run on that board? I have to make sure the
> code I am currently building our board on is good.
>
> Thanks
>
> -----Original Message-----
> From: linuxbios-admin at clustermatic.org
> [mailto:linuxbios-admin at clustermatic.org] On Behalf Of Steven James
> Sent: Friday, November 05, 2004 10:40 PM
> To: Gin Lin
> Cc: linuxbios at clustermatic.org
> Subject: Re: ram init
>
> Greetings,
>
> It's been a while since I've looked at it, but when I last looked, it
> did
> sometimes need power cycled to restart. I worked around that by making
> the
> kernel reboot by writing 0x0e to port 0xcf9. That causes the
southbridge
> to do a 3 second power off.
>
> G'day,
> sjames
>
>
>
> On Fri, 5 Nov 2004, Gin Lin wrote:
>
> > Does anyone know if the raminit.c under intel/E7501 is stable
enough?
> I am
> > having a problem with the system reseting when it jumps to the first
> address
> > in the ram. Could the procedures of writing NorthBrige registers
have
> > problems?
> >
> > thanks,
> > Gin
> > _______________________________________________
> > Linuxbios mailing list
> > Linuxbios at clustermatic.org
> > http://www.clustermatic.org/mailman/listinfo/linuxbios
> >
>
> ||||| |||| |||||||||||||  |||
> by Linux Labs International, Inc.
>    Steven James, CTO
>
> 55 Marietta Street
> Suite 1830
> Atlanta, Ga 30303
> 866 824 9737 support
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>

||||| |||| |||||||||||||  |||
by Linux Labs International, Inc.
   Steven James, CTO

55 Marietta Street
Suite 1830
Atlanta, Ga 30303
866 824 9737 support

_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios



From ginlin at nexcom.com.tw  Sun Nov 14 19:22:01 2004
From: ginlin at nexcom.com.tw (Gin)
Date: Sun Nov 14 19:22:01 2004
Subject: ram_check
Message-ID: <000501c4cab4$e46ae030$4f01060a@nexcom.com.tw>

I have a question with the ram. Don't know if anyone has heard the same
problem before. I ran the ram_check procedure and it reports that there
are always 4 bytes out of every 64 bytes that reads zero. I think that's
why I can run the code in the ram but it gets reset in the in different
places.
 
 
Gin    
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20041114/87bd4c4d/attachment.html>

From pyro at linuxlabs.com  Sun Nov 14 20:31:01 2004
From: pyro at linuxlabs.com (Steven James)
Date: Sun Nov 14 20:31:01 2004
Subject: Tyan/s2735
In-Reply-To: <000401c4cab4$11ebda10$4f01060a@nexcom.com.tw>
References: <000401c4cab4$11ebda10$4f01060a@nexcom.com.tw>
Message-ID: <Pine.LNX.4.58.0411150254250.21597@ucontrol.mobiledns.com>

Greetings,

I'm pretty snowed in for the next couple of weeks, but after that I hope
to get myself up to speed on v2.

G'day,
sjames



On Mon, 15 Nov 2004, Gin wrote:

> Thanks Steven,
> Do you think you will have time testing this on V2 tree? I've been
> working on that code base and keep having problems with it.
>
> Gin
>
> -----Original Message-----
> From: linuxbios-admin at clustermatic.org
> [mailto:linuxbios-admin at clustermatic.org] On Behalf Of Steven James
> Sent: Monday, November 15, 2004 4:31 AM
> To: Gin
> Cc: linuxbios at clustermatic.org
> Subject: Re: Tyan/s2735
>
> Greetings,
>
> I have successfully used the v1 code on that board. Things have been in
> flux since then, and I haven't had time to test a recent CVS checkout or
> the v2 tree.
>
> G'day,
> sjames
>
>
> On Thu, 11 Nov 2004, Gin wrote:
>
> > Steven,
> > Thanks for the info. I've got the ram up by filling the some values in
> > North Bridge(I reference a regular bios).
> >
> > I have an essential question about the code base for Tyan/s2735. Has
> it
> > ever successfully built and run on that board? I have to make sure the
> > code I am currently building our board on is good.
> >
> > Thanks
> >
> > -----Original Message-----
> > From: linuxbios-admin at clustermatic.org
> > [mailto:linuxbios-admin at clustermatic.org] On Behalf Of Steven James
> > Sent: Friday, November 05, 2004 10:40 PM
> > To: Gin Lin
> > Cc: linuxbios at clustermatic.org
> > Subject: Re: ram init
> >
> > Greetings,
> >
> > It's been a while since I've looked at it, but when I last looked, it
> > did
> > sometimes need power cycled to restart. I worked around that by making
> > the
> > kernel reboot by writing 0x0e to port 0xcf9. That causes the
> southbridge
> > to do a 3 second power off.
> >
> > G'day,
> > sjames
> >
> >
> >
> > On Fri, 5 Nov 2004, Gin Lin wrote:
> >
> > > Does anyone know if the raminit.c under intel/E7501 is stable
> enough?
> > I am
> > > having a problem with the system reseting when it jumps to the first
> > address
> > > in the ram. Could the procedures of writing NorthBrige registers
> have
> > > problems?
> > >
> > > thanks,
> > > Gin
> > > _______________________________________________
> > > Linuxbios mailing list
> > > Linuxbios at clustermatic.org
> > > http://www.clustermatic.org/mailman/listinfo/linuxbios
> > >
> >
> > ||||| |||| |||||||||||||  |||
> > by Linux Labs International, Inc.
> >    Steven James, CTO
> >
> > 55 Marietta Street
> > Suite 1830
> > Atlanta, Ga 30303
> > 866 824 9737 support
> >
> > _______________________________________________
> > Linuxbios mailing list
> > Linuxbios at clustermatic.org
> > http://www.clustermatic.org/mailman/listinfo/linuxbios
> >
>
> ||||| |||| |||||||||||||  |||
> by Linux Labs International, Inc.
>    Steven James, CTO
>
> 55 Marietta Street
> Suite 1830
> Atlanta, Ga 30303
> 866 824 9737 support
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>

||||| |||| |||||||||||||  |||
by Linux Labs International, Inc.
   Steven James, CTO

55 Marietta Street
Suite 1830
Atlanta, Ga 30303
866 824 9737 support



From ebiederman at lnxi.com  Mon Nov 15 04:35:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Nov 15 04:35:01 2004
Subject: romcc quesiton
In-Reply-To: <20041109225127.GA7807@openbios.org>
References: <3174569B9743D511922F00A0C943142306BA2E5A@TYANWEB>
	<Pine.LNX.4.58.0411091348170.15069@linux.site>
	<m3llda1x9l.fsf@maxwell.lnxi.com> <20041109225127.GA7807@openbios.org>
Message-ID: <m3ekivqsve.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at openbios.org> writes:

> * Eric W. Biederman <ebiederman at lnxi.com> [041109 23:19]:
> > > I'll try to find more if I get time today.
> > 
> > A complex case would be fine.  With abuild.sh I'm not seeing any compile
> > failures.
>  
> Something's wrong with the line numbers. I get
> incoherent_ht.c:191.8: warning:  "FIXME handle multiple chains!"
> which is 10 lines later..
> Does it ignore the lines with include statements?

Ok.  I have this fixed as well as a few other glitches in the preprocessor.
Error messages could be a little more precise.  But reporting everything
immediately after the error causing construct is not bad.

I believe I even have fixed the:
#if 0
        random assembly code....
#endif
issues as well.  This was accomplished by putting the sanity check at
a slightly higher location in the stack.

It looks like I have most things building again as well.  So far so good..

Eric


From stepan at openbios.org  Mon Nov 15 04:55:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Mon Nov 15 04:55:00 2004
Subject: coherent_ht.c,1.29,1.30
Message-ID: <20041115112114.GA15572@openbios.org>

* Eric Biederman <ebiederm at users.sourceforge.net> [041115 11:46]:
> Modified Files:
> 	coherent_ht.c 
> Log Message:
> - optimize_link_read_pointers compiles now on the solo so don't disable it.
 

The problem was actually not htat it did not compile, but that it made
linuxbios hang on the hardware. Did you verify that it does not do this
anymore with optimize_link_read_pointers()?

I cannot verify this since I don't have access to test hardware anymore.

> --- coherent_ht.c	15 Nov 2004 10:46:43 -0000	1.30
> *** 643,651 ****
>   	coherent_ht_finalize(result.nodes);
>   	result.needs_reset = apply_cpu_errata_fixes(result.nodes, result.needs_reset);
> - 
> - #if CONFIG_MAX_CPUS > 1 /* Why doesn't this work on the solo? */
>   	result.needs_reset = optimize_link_read_pointers(result.nodes, result.needs_reset);
> - #endif
> - 
>   	return result.needs_reset;


From rminnich at lanl.gov  Mon Nov 15 08:14:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Nov 15 08:14:01 2004
Subject: ram_check
In-Reply-To: <000501c4cab4$e46ae030$4f01060a@nexcom.com.tw>
References: <000501c4cab4$e46ae030$4f01060a@nexcom.com.tw>
Message-ID: <Pine.LNX.4.58.0411150739300.30542@linux.site>


On Mon, 15 Nov 2004, Gin wrote:

> I have a question with the ram. Don't know if anyone has heard the same
> problem before. I ran the ram_check procedure and it reports that there
> are always 4 bytes out of every 64 bytes that reads zero. I think that's
> why I can run the code in the ram but it gets reset in the in different
> places.

it just means your ram is still programmed incorrectly.

ron


From ebiederman at lnxi.com  Mon Nov 15 10:16:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Nov 15 10:16:01 2004
Subject: coherent_ht.c,1.29,1.30
In-Reply-To: <20041115112114.GA15572@openbios.org>
References: <20041115112114.GA15572@openbios.org>
Message-ID: <m33bzb83og.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at openbios.org> writes:

> * Eric Biederman <ebiederm at users.sourceforge.net> [041115 11:46]:
> > Modified Files:
> > 	coherent_ht.c 
> > Log Message:
> > - optimize_link_read_pointers compiles now on the solo so don't disable it.
>  
> 
> The problem was actually not htat it did not compile, but that it made
> linuxbios hang on the hardware. Did you verify that it does not do this
> anymore with optimize_link_read_pointers()?
> 
> I cannot verify this since I don't have access to test hardware anymore.

The comment about why it was disabled was significantly ambiguous that
it could be either a compile problem or a hang problem.  And potentially
it could have been both.

According to cvs I committed that code initially and it shows up in my
tree several weeks before it shows up in the public freebios2 tree so
I am inclined to trust my memory.

However there are 2 significant checks we can perform.
- Did the original version compile?
- Does this work on the tyan/s2850

I just checked out the original version and it does not compile it
runs out of registers.

So unless YhLu has problems on the s2850 or we can dig something up in
the mailing list archives I am fairly certain that this change is ok.

Eric


From stepan at openbios.org  Mon Nov 15 10:24:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Mon Nov 15 10:24:01 2004
Subject: coherent_ht.c,1.29,1.30
In-Reply-To: <m33bzb83og.fsf@maxwell.lnxi.com>
References: <20041115112114.GA15572@openbios.org> <m33bzb83og.fsf@maxwell.lnxi.com>
Message-ID: <20041115165003.GA21839@openbios.org>

* Eric W. Biederman <ebiederman at lnxi.com> [041115 17:42]:
> However there are 2 significant checks we can perform.
> - Did the original version compile?
> - Does this work on the tyan/s2850

does the s2850 use an athlon64? Iirc the problem was that the athlon64
has less ht links..

> So unless YhLu has problems on the s2850 or we can dig something up in
> the mailing list archives I am fairly certain that this change is ok.
 
The best way to test this is testing on a solo system.. If somebody has
one... Which I dont. Otherwise I suggest we mark the solo build broken
until someone can verify this..

Stefan





From ebiederman at lnxi.com  Mon Nov 15 10:37:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Nov 15 10:37:01 2004
Subject: coherent_ht.c,1.29,1.30
In-Reply-To: <20041115165003.GA21839@openbios.org>
References: <20041115112114.GA15572@openbios.org>
	<m33bzb83og.fsf@maxwell.lnxi.com>
	<20041115165003.GA21839@openbios.org>
Message-ID: <m3d5yfjb87.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at openbios.org> writes:

> * Eric W. Biederman <ebiederman at lnxi.com> [041115 17:42]:
> > However there are 2 significant checks we can perform.
> > - Did the original version compile?
> > - Does this work on the tyan/s2850
> 
> does the s2850 use an athlon64? Iirc the problem was that the athlon64
> has less ht links..

I am pretty certain that case was limited to the code that was
living in misc_control.c.  For which this problem has been resolved.

> > So unless YhLu has problems on the s2850 or we can dig something up in
> > the mailing list archives I am fairly certain that this change is ok.
>  
> The best way to test this is testing on a solo system.. If somebody has
> one... Which I dont. Otherwise I suggest we mark the solo build broken
> until someone can verify this..

Actually looking at this the code is exactly what we have in misc_control.c
Which has been tested on an Athlon64 so I'm not concerned.

Eric


From ebiederman at lnxi.com  Mon Nov 15 10:42:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Nov 15 10:42:00 2004
Subject: ram_check
In-Reply-To: <Pine.LNX.4.58.0411150739300.30542@linux.site>
References: <000501c4cab4$e46ae030$4f01060a@nexcom.com.tw>
	<Pine.LNX.4.58.0411150739300.30542@linux.site>
Message-ID: <m37jondor5.fsf@maxwell.lnxi.com>

"Ronald G. Minnich" <rminnich at lanl.gov> writes:

> On Mon, 15 Nov 2004, Gin wrote:
> 
> > I have a question with the ram. Don't know if anyone has heard the same
> > problem before. I ran the ram_check procedure and it reports that there
> > are always 4 bytes out of every 64 bytes that reads zero. I think that's
> > why I can run the code in the ram but it gets reset in the in different
> > places.
> 
> it just means your ram is still programmed incorrectly.

It sounds like there was a conversion bug when converting
the memory initialization from assembly to C.

The v1 memory initialization for the e7501 should be solid.

The v2 port was done primarily as a proof of concept so it would not
surprise me if a couple of small bugs were introduced.

Eric


From ebiederman at lnxi.com  Mon Nov 15 10:59:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Nov 15 10:59:00 2004
Subject: coherent_ht.c,1.29,1.30
In-Reply-To: <20041115165003.GA21839@openbios.org>
References: <20041115112114.GA15572@openbios.org>
	<m33bzb83og.fsf@maxwell.lnxi.com>
	<20041115165003.GA21839@openbios.org>
Message-ID: <m37jonxbwt.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at openbios.org> writes:

> * Eric W. Biederman <ebiederman at lnxi.com> [041115 17:42]:
> > However there are 2 significant checks we can perform.
> > - Did the original version compile?
> > - Does this work on the tyan/s2850
> 
> does the s2850 use an athlon64? Iirc the problem was that the athlon64
> has less ht links..
> 
> > So unless YhLu has problems on the s2850 or we can dig something up in
> > the mailing list archives I am fairly certain that this change is ok.
>  
> The best way to test this is testing on a solo system.. If somebody has
> one... Which I dont. Otherwise I suggest we mark the solo build broken
> until someone can verify this..

On that same note we are getting close to the point where making a stable 2.0
and freezing the API (or at least making no changes that are not backwards compatible)
is getting close.  We still have irqs and the ppc to sort out before then.

With that in mind we probably want to introduce a category of TESTED motherboards.

The solo is certainly is not worth dropping out of regression tests because it still
cleanly.   But since no one has tested it in a long time marking not marking it TESTED
is likely a good thing.

Anyway something to think about.

Eric


From YhLu at tyan.com  Mon Nov 15 12:36:01 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Nov 15 12:36:01 2004
Subject: pnp_enable_devices
Message-ID: <3174569B9743D511922F00A0C943142306BA3019@TYANWEB>

pnp_enable_devices(dev, &pnp_ops,....)

I think the second parameter is not necessary and can be removed.

Regards

YH


From yhlu at tyan.com  Mon Nov 15 12:38:01 2004
From: yhlu at tyan.com (Yinghai Lu)
Date: Mon Nov 15 12:38:01 2004
Subject: Flash_rom
In-Reply-To: <Pine.LNX.4.58.0411141433240.28529@linux.site>
Message-ID: <200411151737.iAFHbpL14273@nwn.definitive.org>

enable_flash_ich4 and enable_flash_e7500 is the same. You may remove
enable_flash_e7500.

It should use SB name and model...

Regards

YH



From gwatson at lanl.gov  Mon Nov 15 13:00:01 2004
From: gwatson at lanl.gov (Greg Watson)
Date: Mon Nov 15 13:00:01 2004
Subject: recent changes
Message-ID: <908F53E8-373B-11D9-8334-000D932F4B4A@lanl.gov>

We now seem to have a chip keyword, in addition to config, device, 
driver and object keywords. We have a device_operations structure, a 
cpu_device_id structure and a cpu_driver structure as well as a 
pci_driver structure. The cpu tree has been reorganized to include 
vendor directories as well as architecture directories. We now seem to 
have a drivers directory tree.

Can someone please provide the following information:

1. What does each keyword actually do now?

2. How do the keywords relate to the data structures?

3. What files are now auto generated, and how is everything linked 
together?

4. What keywords/data structures are actually needed, and by which 
devices?

5. How/where are the data structures used?

6. What is the rationale behind the reorganization of the cpu tree, and 
how is it supposed to work?

7. What is the purpose of the drivers tree, how do drivers differ from 
devices, and why is the console not included?

The configuration process now seems so complicated that  I can't see 
how we could expect someone to port to a new board without some basic 
description of how everything is supposed to work. I have a major 
vendor interested in doing this, but at the moment I can't offer them 
any help.

Greg



From gwatson at lanl.gov  Mon Nov 15 13:00:12 2004
From: gwatson at lanl.gov (Greg Watson)
Date: Mon Nov 15 13:00:12 2004
Subject: recent changes
Message-ID: <30DE5374-373C-11D9-8334-000D932F4B4A@lanl.gov>

We now seem to have a chip keyword, in addition to config, device, 
driver and object keywords. We have a device_operations structure, a 
cpu_device_id structure and a cpu_driver structure as well as a 
pci_driver structure. The cpu tree has been reorganized to include 
vendor directories as well as architecture directories. We now seem to 
have a drivers directory tree.

Can someone please provide the following information:

1. What does each keyword actually do now?

2. How do the keywords relate to the data structures?

3. What files are now auto generated, and how is everything linked 
together?

4. What keywords/data structures are actually needed, and by which 
devices?

5. How/where are the data structures used?

6. What is the rationale behind the reorganization of the cpu tree, and 
how is it supposed to work?

7. What is the purpose of the drivers tree, how do drivers differ from 
devices, and why is the console not included?

The configuration process now seems so complicated that  I can't see 
how we could expect someone to port to a new board without some basic 
description of how everything is supposed to work. I have a major 
vendor interested in doing this, but at the moment I can't offer them 
any help.

Greg



From YhLu at tyan.com  Mon Nov 15 13:12:01 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Nov 15 13:12:01 2004
Subject: recent changes
Message-ID: <3174569B9743D511922F00A0C943142306BA301E@TYANWEB>

According to my experience.

With 
Chip ...
		Device.... end
		Device ... end
End

And "Config chip.h"

The static.c will be produced according to the Config.lb in MB dir.

All device under that chip will share one chip_operation, and the
chip_operation will contain one enable_dev member. It will link and enable
static that can not be done via pci function....

Regards

YH

-----Original Message-----
From: Greg Watson [mailto:gwatson at lanl.gov] 
Sent: Monday, November 15, 2004 11:26 AM
To: LinuxBIOS
Subject: recent changes

We now seem to have a chip keyword, in addition to config, device, 
driver and object keywords. We have a device_operations structure, a 
cpu_device_id structure and a cpu_driver structure as well as a 
pci_driver structure. The cpu tree has been reorganized to include 
vendor directories as well as architecture directories. We now seem to 
have a drivers directory tree.

Can someone please provide the following information:

1. What does each keyword actually do now?

2. How do the keywords relate to the data structures?

3. What files are now auto generated, and how is everything linked 
together?

4. What keywords/data structures are actually needed, and by which 
devices?

5. How/where are the data structures used?

6. What is the rationale behind the reorganization of the cpu tree, and 
how is it supposed to work?

7. What is the purpose of the drivers tree, how do drivers differ from 
devices, and why is the console not included?

The configuration process now seems so complicated that  I can't see 
how we could expect someone to port to a new board without some basic 
description of how everything is supposed to work. I have a major 
vendor interested in doing this, but at the moment I can't offer them 
any help.

Greg

_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From ebiederman at lnxi.com  Mon Nov 15 13:52:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Nov 15 13:52:00 2004
Subject: recent changes
In-Reply-To: <30DE5374-373C-11D9-8334-000D932F4B4A@lanl.gov>
References: <30DE5374-373C-11D9-8334-000D932F4B4A@lanl.gov>
Message-ID: <m3fz3alvcf.fsf@maxwell.lnxi.com>

Greg Watson <gwatson at lanl.gov> writes:

> We now seem to have a chip keyword, in addition to config, device, driver and
> object keywords. We have a device_operations structure, a cpu_device_id
> structure and a cpu_driver structure as well as a pci_driver structure. The cpu
> tree has been reorganized to include vendor directories as well as architecture
> directories. We now seem to have a drivers directory tree.

All of the northbridge/southbridge/superio keywords were condensed
into a single keyword chip.
A simplification.

device specifies a logical subdevice of a chip.

chip specifies where the code lives, generally this is a subdirectory
with code for a specific ASIC.  device describes a logical device within
chip, and an entry in the device tree.

And of course the device tree shows up in static.c like it has done
for a long while.

As for the cpus on x86 they were reorganized so that as much as possible
they work like any other device.  Since in a lot of cases it is possible
to plug in multiple cpus into the same motherboard.

The design is for per architecture code to figure out which cpu
it is running on and then setup the methods appropriately.

driver and object are essentially the same keyword.  The difference
is that if you are marked object you are only linked in if there
is an external reference to you from elsewhere, this is good for
library functions.  Something marked driver is always linked in.

> Can someone please provide the following information:
> 
> 1. What does each keyword actually do now?
>
> 2. How do the keywords relate to the data structures?
> 
> 3. What files are now auto generated, and how is everything linked together?
> 
> 4. What keywords/data structures are actually needed, and by which devices?
> 
> 5. How/where are the data structures used?
> 
> 6. What is the rationale behind the reorganization of the cpu tree, and how is
> it supposed to work?
> 
> 7. What is the purpose of the drivers tree, how do drivers differ from devices,
> and why is the console not included?

There is no drivers tree, just the device tree.  The code does like
it has done for a long time in v2.  Some motherboard specific code
runs, and then we enter hardwaremain.  In hardwaremain we look at
the specified set of devices, and we look at the code for those devices
and we see if we can find some more.  And then we setup the devices.

There has been an effort to remove special cases.  We are currently
left with the timer subsystem, the console, and hard_reset.  All of
which are optional.  I don't see a way for those things to be both
useful and not be a special case.

> The configuration process now seems so complicated that  I can't see how we
> could expect someone to port to a new board without some basic description of
> how everything is supposed to work. 

Which is reasonable.  Working examples may help as well.

> I have a major vendor interested in doing
> this, but at the moment I can't offer them any help.

The big change from v1 to v2 is that in v1 everything was handled top down,
while the code is structured in v2 to encourage building the code bottom
up which tends to be more reusable.

So in v2 the basic model is:
We detect that a piece of hardware exists.
We find an ID for that hardware.
With that ID we find a driver for that hardware.
With that driver we configure the resources for that device.
After the resources are configured we enabled them.
With everything setup we make a last pass and do device specific initialization.

If a device cannot be discovered by the generic code it needs to be
present in the static device tree.  And if a device is always present on the
motherboard it is recommend that it be present in the static tree.  

The last big round of changes was largely simplifications to expose the primary
model on how things work.  We generate a device tree directly from Config.lb
without an intermediate chip tree.  cpus were pushed into the device tree.
All of this was done with an eye towards the fact that things were getting
too complex.  Once the dust clears the infrastructure should be fairly
stable from here on out.

Eric


From ebiederman at lnxi.com  Mon Nov 15 14:02:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Nov 15 14:02:00 2004
Subject: pnp_enable_devices
In-Reply-To: <3174569B9743D511922F00A0C943142306BA3019@TYANWEB>
References: <3174569B9743D511922F00A0C943142306BA3019@TYANWEB>
Message-ID: <m3brdyluwb.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> pnp_enable_devices(dev, &pnp_ops,....)
> 
> I think the second parameter is not necessary and can be removed.

Sounds right.

Eric


From ollie at lanl.gov  Mon Nov 15 14:33:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Mon Nov 15 14:33:00 2004
Subject: Multiple Debug Devices
Message-ID: <1100552371.1119.13.camel@exponential.lanl.gov>

Yhu,

You still have two debug devices in the s2885 mainboard Config.lb, one
under amd8111 the other under root_complex. Why do you do this ? You
said the debug device depends on scan_static_bus(), how do you make
this conclusion ?

Ollie




From YhLu at tyan.com  Mon Nov 15 14:38:01 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Nov 15 14:38:01 2004
Subject: Multiple Debug Devices
Message-ID: <3174569B9743D511922F00A0C943142306BA302E@TYANWEB>

1. I just want to use that to make sure it need scan_static_bus.
2. It is a static device under some device, so without scan_static_bus for
that device, the static device will not be enumerated.

Regards

YH

-----Original Message-----
From: Li-Ta Lo [mailto:ollie at lanl.gov] 
Sent: Monday, November 15, 2004 1:00 PM
To: LinuxBIOS; YhLu
Subject: Multiple Debug Devices

Yhu,

You still have two debug devices in the s2885 mainboard Config.lb, one
under amd8111 the other under root_complex. Why do you do this ? You
said the debug device depends on scan_static_bus(), how do you make
this conclusion ?

Ollie



From ollie at lanl.gov  Mon Nov 15 14:46:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Mon Nov 15 14:46:00 2004
Subject: Multiple Debug Devices
In-Reply-To: <3174569B9743D511922F00A0C943142306BA302E@TYANWEB>
References: <3174569B9743D511922F00A0C943142306BA302E@TYANWEB>
Message-ID: <1100553111.1119.20.camel@exponential.lanl.gov>

On Mon, 2004-11-15 at 14:10, YhLu wrote:
> 1. I just want to use that to make sure it need scan_static_bus.
> 2. It is a static device under some device, so without scan_static_bus for
> that device, the static device will not be enumerated.
> 

So the one under 8111 is actually redudant and can be safely removed?

> Regards
> 
> YH
> 
> -----Original Message-----
> From: Li-Ta Lo [mailto:ollie at lanl.gov] 
> Sent: Monday, November 15, 2004 1:00 PM
> To: LinuxBIOS; YhLu
> Subject: Multiple Debug Devices
> 
> Yhu,
> 
> You still have two debug devices in the s2885 mainboard Config.lb, one
> under amd8111 the other under root_complex. Why do you do this ? You
> said the debug device depends on scan_static_bus(), how do you make
> this conclusion ?
> 
> Ollie
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 



From linuxbios at xdr.com  Mon Nov 15 17:32:01 2004
From: linuxbios at xdr.com (Dave Ashley)
Date: Mon Nov 15 17:32:01 2004
Subject: [PATCH] SPD autoconfigure logic for EPIA-M
Message-ID: <200411152358.iAFNw1hh024727@xdr.com>

Here is NXTV's ramini.c to be placed in version 1 of linuxbios
src/northbridge/via/vt8623/raminit.inc

It was written by Felipe Rodriguez for NXTV and is now being contributed
back to the linuxbios project. His email address is included in the
comments in the file.

It assumes the SPD contents on the module are valid, and it sets up
the CLE266 DDR controller appropriately.

Features:
o Detects number of ram banks
o Properly tunes tunables
o Detects column and row address sizes
o Works for every 128M DDR module we've tried as well as one 256M
  module, correctly setting the available memory in linux.
o Lots of comments for reference

Now if someone else wants to convert this X86 code to C code for romcc
in version 2, that would be great.

Enjoy!

-Dave


begin 644 raminit.inc.gz
M'XL(",-`F4$``W)A;6EN:70N:6YC`.T[^W/;QM$_$W_%-HG'9#Z*Q).BE#I3
M6I(=345)):7&GL2#P>,HP@$!%@#U\%_?W3N\"4)B7'\SG:G:>,B[O=V]O7W<
M[AZ'/TKP(T36R at N\9.`%SC'`21 at LO+M-Q.`^&8\T#2)VY\4)BV*$%?_OW"R]
M&-91>(=+`3\N(L8@#A?)@Q6QG^`IW(!C!;C2Q9619V\2!EX"5N`.PPA6H>LM
MG@@/CFT"ET60+!D at B54,X8)_>7]Y"^]9P"++A^N-[7L.7'@."V(&%I*FD7C)
M7+`Y'EKQCGB8ISS`NQ`16XD7!C\!\W`^@GO<`GX'-:.1(NQ#&!&2KI40YQ&$
M:UK70W:?P+>28NE at Q_:+7;K@!1SW,ESCCI:($O?XX/D^V`PV,5ML_#ZA0&#X
M]?SFEZO;&YA<?H1?)[/9Y/+FXT\(G"Q#G&7W3*#R5FO?0\RXK\@*DB=DGS!,
MSV8GO^"2R=OSB_.;C[@)>'=^<WDVG\.[JQE,X'HRNSD_N;V8S.#Z=G9]-3\;
M`,P9L<4(08N(%_R44(PN2RS/C[.-?\2#C9$[WX6E=<_P@!WFW2-O%CCA^NGY
MPR,DEA\&=WR;"%P(\B?P%A"$21\>(@_U)0EAZUAI>7&R?3@/G$$?1H<&3*TX
MALD]'N:)M;(CS[W#C],)R*JB'?7A=CX9%.I[BK+UP_6*!0FQ/+\^!6N3A`<.
M5WV(UV$0X^Y)N^#RP\T_.9UT[62#QQ,==]XQW\,CG at Q@%KH1&@S[`G]=1-GG
MOP6/R?W`"5<_<X*H1<?0N0SO095EO:Q&3NB22L>;%4/E#QB<GL[@]'PZ)3/9
M^$P(ZM[R/9<SBENW$)[6QYOU.HP2P2?)ZI^>!6?7YY.#*=BA%;G$\U"2OG?9
MPD/,?ABND3S\(#\:LBQ7QA4QKN*$)'4^K]:=U"M(G4','!(W?#>(PM6`&/A.
MDB+/=*Q8.<9IU'T\T.].)G-02&,0G+F#WZ/?@^]2,+4&INX`,^IP`Z,94JL!
M:@U at FX`@2X"W@=BP"[0$1;IA`Q"KQ0%DB]U_Q:;+?.NIM/CT'W-`LURC9?(I
M$&`LBD@;2C0LV^?*2PQ%*Y)O?2F:X6U,T,B.M?&3$E4_?##M,'!KA'$8:#@E
MNO3NEDU at -)[!X;FM(W;OA9L8#TN<Y;'4\8*$^::S]-;F.HP3<V4Y4=B5'S6C
MATM.YN:OL_.;LRZJPJ'1)XV0QS0Q_!%BEFS6X*PWI%,52$/FD`Y"5L<5/NZR
M^K at JX!?U<8V/C[?PI)SHG,6KR_G5Q9EY?OGNRKSY8*(/G'5_>'WPNK=S3FZ9
M<UOFVG#^'K5-!C at I#='(\>]T-IF2)YI::[AY0I<!Z'[0&X(,<+58H%C!&$L"
M-%>9%4/W^P26ZT8LYKIB6S$J;BA"@G`-K^,,#E5_&81^>/=$,9;CXL'BCI&/
M2]W^#==,_>"(?-XYZ0$B&*NZKKW_P-T*!E1DAGQ_[O8YJK=6\`<H0YEVL<)=
M)'P7R/5OAP?&IRH(>KP5LH!W"G3A!**7`+2ANHU#.U!J(%LXY$^2X&3&+.$%
M[2><4@[[<+E9V1B@<4<V+B</"G,N<9<+>2"1LJ[">[^#&J0HJ*JOF/V()S>Y
MN)A?=^.5O8G-"-&:A)(4[#&,[,XKQ^_C?U+'6:UM6BJK_5<6?O_\I8,G9DXG
M:#EKDW;1Z0R'H(RF=G[B52ZU,I,1&G)ZJ"RN,B=K+V`N9\=-V?$[>*DP1[JI
MJ&-NUIR=D3[$[U,;ND at PAK^^`47M[>!/00:O(V]EH1YQR3UX;K*L\>;NPYN>
MBZJ=MT=NT$B#+QO+)'$.HAIE<>8+"$63'NAE"3NAOUD%-2'7^#B62EO3]]G:
M4;ZU`,W4M+W$1((F42M!63E4PH)=0/9+@,8Y$$/?GE3!I/I"].^HO.0K1ZDP
MN6[*0T4!A"/9@""``1YJ>BQ)6ULJ\.DE?$<OP;7-;H%,+2$;5Y%)4 at W3<2T4
MC/N`:WO2<+CE?'\Y^S#N\LFJ[R7'`+'WA:5^4!]H`P76=Z`90IL,Z^!GPP7:
M!`5NAJXG51_N#)GE+#D27"_D^.8-&?S;=#&\$21D\=W.O\/_@:V(0:<Z2/^H
M8L9MF*%_M*KG6J1:2C*K^1<%IN*FR-&X>,WVDJ<V;>86AWK5?V6C;J&GS3T<
M?4]8G%0&R at 9*WS\'P@<2.=DDP7*;??]V-VJECEJIHM9;42LMJ#.F<M390(9:
M;45M*.IT-W*]CERO(5?:16*,6I"K=>1J#3D9?XM0T"7N1J[4D2MUY'H;\I'>
M at COCJSC-<0VWVH9;:Y-XQE:!6Z_A5EJ%@@*'(>B%PN1+:/J,+NM]2L.SJ[?P
M-P62X]V.Q?;KUU(+?1$?%7NQ_3R`Q9@<EV*,43+>W&X- at .\I8*V73['G8*;,
M+S"[[3:EXG")<2KHH1),4TO26BR0I=(UA5`J?&-2QV5.9\><]/_K:/8Y8W3$
MSY[QUVGH-H56#=W+LK9QMUK67BZA03*M+F$O9[:-O-V9[>6&MY&WN^&]PD>#
M6-HT99^@UR"4/1R-5%V.%QL<L.DVP]U(X8F4_3V1+3Q1IS;L9`ZJ,NJFHSRK
MK^4"8UX/N<#$*W">H'(#45]P3][3X$FH5/;9WY"SE<;^=IHNU1IJ"?.;V?GE
M^^X/>?&H)TIA`IR7NUH7$42OI`^RR"$)!1VN&UDK,_$PP;^3>%&LX014+2L/
M(!@X?NC\`<Z30R4E;\7`2N#DX@,<@#PPJL=S^,(T!M+2#@I,9`>:-OWE"UUI
MQ;@BR]-E^MV2*</$'#P3=?O>U5[5F;3MW7A6DJK1J[J/%G3:L]BT$C*M!9DP
MP]+(<369N.&##36<D9ZFIICAKR-VX"RMZ(Y1]OK;H:AOS-"RKC=^S$2&33,C
M,5.V.9'Q_F;T]4\"(?^;G\Z`*L/IB(QTE1O\<)`-*``J#:@WZ8B"(!H?&1CY
M&$(=T`?M1LI8&A)Q4='DA-52,8:*1)'/J-*/,TH_K\,4A:JHNEVNI-UD=MT3
M@*1=J$VH2YJ#9.4@%L-"R8!JA\AA-CP:\5'2Q#$"&3C<D.ZKAWUN'`VD:^4>
M>X_47G,*F^`GO8C8OS;\2-ZDV^#&T,GKNF9DQ682DG:):C%/<(M21BD-S<5%
M.H`I9B%SE-7)Z;<4UE&[L';OIEPD4?:I__Q)2:[)-$QN&KD@*5#L%N2Z9$PH
MQ\E\2X[J".4X#D17<79=$Z>F8OZ]+4[=!CC<(4YT'6EED4O5<A+OGE?[GY=M
M:7\5T;(]1*N.]A8MW2A,+S?D7+3Z3AWEM_O2BJ^HO.YDHR*!EU1E&XJ+-92F
M_D`FV%"PK0.J'##S_M$CN>XFF.-"#Y5JQ.!KFNB7EJBI?#/XXUI_9:2_J)25
MME[$<?.J.6H;]0BI-&7Y:=JXU9,9B9Z,;*4H^/))9'M)Q'NG%,CP]+:6B5:+
M5JH6GUS?4A,V5;,B\&6]BS3NU<"R/P/#7W_T"<`.PR1&XNN8+C'RHR-#5VAL
MKU2JVT1Q`CX+[M"DW\"8KS<^25L=)YVSR>0>S[:1C?GV>I33N!J\3_AU:FL+
MHR,IAQG2/N(U8Z[@?W24\M\5<=!*LAL]!6&\)2&\V,!)&"11Z/LH510"_`PJ
M7YTV2&JS?WD#.LVFW1'.W?@/6%OH/^CV+RAKI5E]:S:-U%/DQ5OC+8U/KZB=
M3+/RMM1&1WW1X\UT at D>@G]^02T0?:2WHJ0,G5ARDY7[>Q$D_+9PJ^#^-2J>*
MN'V>GEU,/G;3_G&*]4QT0$_^?K:M739G0,E`3[V8PW*:$4-G%B^W%UE"D[-%
M<SPQ-R*W2Q:@"'=%!@'=M,,UT`=JG[C4Y=XV.K?<3"Q/'`K5)XOY3Y=N,"E)
MRS.OF/.88G_%K$?\[GJBZ40#L=>G?\1&%W@)9?9FL<!36>$AT`L2-%S?PH\5
MREDB4,J"<B\HB^22W.#:MQQFEK":86`2-NZ<TP+1RV`E$L=YX.`>*<7EI^$(
M#8>'I7BW$C%Z&L-?D21+*\"3JC`MK5*]-;-ACCJN%?Q'CN@)Z]S23\N4CF$Z
MZ5-SO0_3TR'J6^-!&X98>7(,9U;D/Z4Y5<Q\YB2T?-J'D_GWA$.2VK==]^!,
MRS+IW,N@&E*C'7U$[$2>+=X#T;.,M^=7>/L/HX2RA_<;SZ5NQ/4=J&/HHKI2
M2Z)'!BNY;F12]D%H\#[&>U6H#)=7U^A#1%\TM;`=UB53"HHK2/_``C?<$/!#
M&+FH4>&*OVK*VAOI>QW76ZWR;!*H""C+<I<TL8<[1#4M6[J:6^(DC3YP';'T
M[O-"%M-,4=!2:K0X[NE\]AP2K;1/RA!E>5G>A+JUAP)X7(,=-[$PR8/KU^U/
M;4)^\G8&)SRO?P:57B[4C/GE,JZ>E;;[K+A7+B#U%T,:+X8<O1CR\,60]>/8
M#7GT8DCK&<@]M*[21]^R+R2&>9JWJ&3U*CW/HU<V<G5X8&11>G8V.177PMZN
MDI8FUYQ[5B?_TN'!1K!B$BNF**LU#E/I)14+\E,52G;!#<)HA1Z9UT'H2M&,
MJ4"DU!"):V\=2^;+^'!Z99O2A66'L`UZ>R2)*XA)#Y_$*ZHB/R4KY;/\C567
MOXW#2V9(D;+TX*HW2.\OY&=5NAFH1]LT1YRFKH@;^?;[(R4SQ86''L`/'S`N
M\\=66YC&^8VE^IJDE`_E#[VDIOM_^9%1RW30.OW]Z[0DZXL./K\+T%6&XB%%
M`+QATR at 40(JJZ<;H<"Q.D0-RF5(Q,)O+</+K"W0)8X]#+CS?K\P)QX[3E5&U
M<51K'-7ST99]#E[S"'_/(GI5+):+59E6H\'XL+T_J at 7C93FRO+@XD&<HI?CS
MK7T[$NJW)Z%]>Q)ZC<2^-':6=<NO)1M>XA49]%>\X.-^&-(6C;,43UV*AYW%
M.TR)GEB6&2?GY`4.-_V\19&U;DE;\0Z+"LO?F]Q%F(71,V"I$R^I>)"Z]<)U
M4'>HM1NT[7]$WR>+%+POS`L8 at 54N#N5RYHY_PR,?%0$+"!1SOKGBV>E_Q^Z*
MXWEF>SMFMBHVPJ\K2H/>E-62OPGN9=J"`R*"T5-,TPE1_9&(5`X&9<%^JVCP
M0R4:C!NCP?A_T8"?UX)^8E"V[F\0$OXTG3WCPI^FLV=P^--TZA%B)YU",1?X
M)Z<:G"HFBZR8-2GCM]/!SN<\7I4#08, at JF9]>O;V]GWJX32U2WC;#!=>-SU[
M+_N;G,XWBX/<D_'&*/>7Z:?CK(R8=0[4H48EA6[^.X0N$H:#_.<+76?9Z^75
M*@JI:74JWMC95QY1J!R6"ESH1#K@\@'W,4?@I^^=^%=1=8=7+ at ZX'LV[E7E*
MJ'@<_QH"5C,!\9;C/T%@\3("XKLMOF=.G*I-F;"EDI2S=VG-<3GG1)S%DE[I
MEJ(TI"_;FN*P:%&T*:=(P'8JYG*W[D&+7G:;YI[7]=[7_:)#VA',MRX*HZ(2
MU_1#ED->8L;S\D4G[D>JB7.'1CFT:&DXE%FNZ5=MW@*R6FE6:.:E6JH<D^_M
MU$N&M??/66%=_)QBJ_EAB>;'+2[F!4%E)):5WI[$`X"NR*#U].GT4=IKG3V.
MCJ";]R)[-&*,H4O/[/G/4OA(1B3KS!9_^>/^_`\O)Z,=P*HQ&M)3,;L$K&N5
MKFX[YI&Q`[@)LZ;6:S-4C\@?T8SE[*TE1JM4QB;B,6G7C2V,\2B[%&;@>`!4
MI*FNK5?`Q6*="D^E=<>2\+YKQ]LJ0!R*YM]8K>G?H=:LEX="7PUYZS=@2O[+
M+DX,G<9ZZ3DQ6&MT(_0;8?I9TA9]1=!QY5[QA*5B!Z.\#]0X?5AJ$^W\P1H*
+4_HWRK@*]<`\````
`
end


From rminnich at lanl.gov  Mon Nov 15 18:38:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Nov 15 18:38:00 2004
Subject: Via/EPIA Status
In-Reply-To: <20041115164544.z3log8o8kw88gs48@2pmtechnologies.com>
References: <20041115164544.z3log8o8kw88gs48@2pmtechnologies.com>
Message-ID: <Pine.LNX.4.58.0411151803500.31480@linux.site>


On Mon, 15 Nov 2004 mark.wilkinson at 2pmtech.com wrote:

> Hi Ron, All
>       Just a quick update on the status of the Via/Epia.
> 
> I have it booting now, from cold start/reset to payload.
> 
> 
> Problems :-
>    - Possible timing problem in smbus
>       - causes memory modules not to be found,
>         worked around this by adding a slight delay into raminit.c

actually, look at my code for the i82801dbm early smbus. You need to wait 
for smbus to start before you wait for it to stop. MUCH better than a 
delay.

>    - Filo not seeing ide disks
>       - this is probably due to fixups on southbridge being run to enable
>         ide and/or nic. Could be

I have a new FILO that is better; want it?

ron


From rminnich at lanl.gov  Mon Nov 15 18:43:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Nov 15 18:43:01 2004
Subject: Flash_rom
In-Reply-To: <200411151904.iAFJ4aG1026850@proofpoint2.lanl.gov>
References: <200411151904.iAFJ4aG1026850@proofpoint2.lanl.gov>
Message-ID: <Pine.LNX.4.58.0411151808470.31480@linux.site>


On Mon, 15 Nov 2004, Yinghai Lu wrote:

> It should use SB name and model...

SB?

ron


From rminnich at lanl.gov  Mon Nov 15 18:52:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Nov 15 18:52:01 2004
Subject: [PATCH] SPD autoconfigure logic for EPIA-M
In-Reply-To: <200411152358.iAFNw1hh024727@xdr.com>
References: <200411152358.iAFNw1hh024727@xdr.com>
Message-ID: <Pine.LNX.4.58.0411151818280.31480@linux.site>

dave, this is great, it is what this project is all about. 

Many thanks!

ron



From rminnich at lanl.gov  Mon Nov 15 18:59:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Nov 15 18:59:01 2004
Subject: Can't remember if I mentioned this for abuild.
Message-ID: <Pine.LNX.4.58.0411151824550.31480@linux.site>

You should see the adl855pc building just fine again.

If not, well, tell me :-)

ron


From stepan at openbios.org  Tue Nov 16 01:28:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue Nov 16 01:28:00 2004
Subject: Flash_rom
In-Reply-To: <Pine.LNX.4.58.0411151808470.31480@linux.site>
References: <200411151904.iAFJ4aG1026850@proofpoint2.lanl.gov> <Pine.LNX.4.58.0411151808470.31480@linux.site>
Message-ID: <20041116075416.GA28672@openbios.org>

* Ronald G. Minnich <rminnich at lanl.gov> [041116 02:08]:
> 
> 
> On Mon, 15 Nov 2004, Yinghai Lu wrote:
> 
> > It should use SB name and model...
> 
> SB?

Southbridge, since the flash is attached to it's LPC bus I assume



From ollie at lanl.gov  Tue Nov 16 11:02:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Tue Nov 16 11:02:01 2004
Subject: pci_operations for amd8111_ac97.c
Message-ID: <1100626105.1119.1237.camel@exponential.lanl.gov>

Eric,

The lpci_set_subsystem() in amd8111_ac97.c is exactly the same as the
default pci_dev_set_subsystem(), why do you define it instead of using
the default one?

BTW, why can't the set_subsystem() method be set at runtime ?

Ollie





From ebiederman at lnxi.com  Tue Nov 16 13:29:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Nov 16 13:29:01 2004
Subject: pci_operations for amd8111_ac97.c
In-Reply-To: <1100626105.1119.1237.camel@exponential.lanl.gov>
References: <1100626105.1119.1237.camel@exponential.lanl.gov>
Message-ID: <m3oehxh8lo.fsf@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:

> Eric,
> 
> The lpci_set_subsystem() in amd8111_ac97.c is exactly the same as the
> default pci_dev_set_subsystem(), why do you define it instead of using
> the default one?

Probably because I didn't realize it.  It seems like every device
has a different function.  It may also have been I was wondering
if it was worth exporting the default method.

The default is simply a good guess, that can't hurt if it's wrong.
 
> BTW, why can't the set_subsystem() method be set at runtime ?

All of the methods are set at runtime.  I just have the pci specific
methods is a sub-table.

Eric


From zhushisongzhu at yahoo.com  Wed Nov 17 03:10:01 2004
From: zhushisongzhu at yahoo.com (zhu shi song)
Date: Wed Nov 17 03:10:01 2004
Subject: i845GB MB progress
Message-ID: <20041117093634.62898.qmail@web13206.mail.yahoo.com>

rtl8139 on my i845GV MB still can't work.  Who know
the meaning of post code of linux?  I saw linux last 
post code was 99, using vendor's bios linux last post
code was 97.  I want to know the difference.
  tks
  zhu


		
__________________________________ 
Do you Yahoo!? 
The all-new My Yahoo! - Get yours free! 
http://my.yahoo.com 
 



From stepan at openbios.org  Wed Nov 17 04:17:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Wed Nov 17 04:17:01 2004
Subject: i845GB MB progress
In-Reply-To: <20041117093634.62898.qmail@web13206.mail.yahoo.com>
References: <20041117093634.62898.qmail@web13206.mail.yahoo.com>
Message-ID: <20041117104335.GA18797@openbios.org>

* zhu shi song <zhushisongzhu at yahoo.com> [041117 10:36]:
> rtl8139 on my i845GV MB still can't work.  Who know
> the meaning of post code of linux?  I saw linux last 
> post code was 99, using vendor's bios linux last post
> code was 97.  I want to know the difference.

forget post codes under linux. port 80 is used for io delays there.
Looks like your interrupt mapping doesnt work?

Stefan





From rminnich at lanl.gov  Wed Nov 17 08:37:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed Nov 17 08:37:01 2004
Subject: i845GB MB progress
In-Reply-To: <20041117104335.GA18797@openbios.org>
References: <20041117093634.62898.qmail@web13206.mail.yahoo.com>
 <20041117104335.GA18797@openbios.org>
Message-ID: <Pine.LNX.4.58.0411170803220.3899@linux.site>


On Wed, 17 Nov 2004, Stefan Reinauer wrote:

> forget post codes under linux. port 80 is used for io delays there.

they do have limited use. 98 is usually the idle loop. 

Not sure what 99 and 97 are.

ron


From adam at cfar.umd.edu  Wed Nov 17 10:45:01 2004
From: adam at cfar.umd.edu (Adam Sulmicki)
Date: Wed Nov 17 10:45:01 2004
Subject: i845GB MB progress
In-Reply-To: <20041117104335.GA18797@openbios.org>
Message-ID: <20041117122310.I84271-100000@www.missl.cs.umd.edu>

On Wed, 17 Nov 2004, Stefan Reinauer wrote:

> forget post codes under linux. port 80 is used for io delays there.

no kidding.

and I was looking for some ready-to-use delay loop to hold stuff after
using port 80.

either way ended up using serial port



From ebiederman at lnxi.com  Wed Nov 17 13:32:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Nov 17 13:32:00 2004
Subject: ppc targets
In-Reply-To: <549D62F4-34FE-11D9-8723-000D932F4B4A@computer.org>
References: <20041111154204.GA27761@openbios.org>
	<m3hdnv94zo.fsf@maxwell.lnxi.com>
	<549D62F4-34FE-11D9-8723-000D932F4B4A@computer.org>
Message-ID: <m3fz38i6xb.fsf@maxwell.lnxi.com>

Ok I am starting to dig into these and figure out what needs to happen
to get the ppc targets working again.

The hardest case currently appears to be the sandpointx3 with pmc
processor modules, so I will get to it last.  The whole northboard/southboard
thing is interesting.  But something we need to handle.  I think
I have heard of the same thing with a few hypertransport based systems
as well.    Which board is the bootrom that the systems starts
executing with on.  The few schematics I have looked up so far
have a bootrom on the sandpoint and the MPCxxx pmc module.
The other datapoint I need to track down is are there other boards
the processor pmc modules can plug into.  Or there tighter coupling than
that.

I have not been able to track down documentation on  cpu the embeddedplanet epc405
is using.  In fact I'm not even certain which cpu it is using which is part of
the problem.  Does that board use a northbridge at all or is the memory controller
and pci bus built into the cpu?

But it looks like I have tracked down enough information on the totalipact/briq,
to understand what is going on.  Or at least well enough that I can get something
that will build and will be close to working built.  So I am starting
there despite the fact it does not look like that port was ever quite
finished, or at least it was never built to handle the general case
as it has a hardcoded memory size.

One of the cases the northboard/southboard thing brings up is that we
don't have good infrastructure for handling plugin boards with lots
of chips that need special handling.  If we can identify them we can
do something, the code is just not very general yet.  It is likely we
want to be able to build a static device tree that describes a pluging
board that we can just graft to the main tree when we detect that
board.  It is something to think about anyway.

Eric


From ollie at lanl.gov  Wed Nov 17 14:08:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Wed Nov 17 14:08:00 2004
Subject: Link and Links again
Message-ID: <1100723692.15287.1434.camel@exponential.lanl.gov>

Eric,

>From my understanding, the device.link for bridge device does not 
include the up stream bus. The up stream bus is the device.bus field.
So for 'normal' PCI bridges, with one up stream and one down stream
buses, its device.links = 1. Am I correct ?

Ollie




From ollie at lanl.gov  Wed Nov 17 16:43:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Wed Nov 17 16:43:01 2004
Subject: Root_complex in northbridge.c
Message-ID: <1100732986.15287.1601.camel@exponential.lanl.gov>

Eric,

Is there any reason that you put the root_complex driver in
amdk8/northbridge.c instead of amdk8/root_complex/root_complex.c?

Ollie




From ebiederman at lnxi.com  Wed Nov 17 16:58:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Nov 17 16:58:00 2004
Subject: Root_complex in northbridge.c
In-Reply-To: <1100732986.15287.1601.camel@exponential.lanl.gov>
References: <1100732986.15287.1601.camel@exponential.lanl.gov>
Message-ID: <m3hdnoys86.fsf@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:

> Eric,
> 
> Is there any reason that you put the root_complex driver in
> amdk8/northbridge.c instead of amdk8/root_complex/root_complex.c?

Because the is very strongly intertwined.

Eric


From ebiederman at lnxi.com  Wed Nov 17 16:59:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Nov 17 16:59:00 2004
Subject: Root_complex in northbridge.c
In-Reply-To: <1100732986.15287.1601.camel@exponential.lanl.gov>
References: <1100732986.15287.1601.camel@exponential.lanl.gov>
Message-ID: <m3ekisys67.fsf@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:

> Eric,
> 
> Is there any reason that you put the root_complex driver in
> amdk8/northbridge.c instead of amdk8/root_complex/root_complex.c?

Because the code is very strongly intertwined.

Logical things the pieces are separate but in practice they are not.

Eric


From ginlin at nexcom.com.tw  Wed Nov 17 19:39:01 2004
From: ginlin at nexcom.com.tw (Gin)
Date: Wed Nov 17 19:39:01 2004
Subject: boot from ide
In-Reply-To: <1100723692.15287.1434.camel@exponential.lanl.gov>
Message-ID: <000001c4cd13$1f043a60$4f01060a@nexcom.com.tw>

Hello, 
I've got my linuxbios run to the point it tries to load the image from
an IDE drive. I use FILO as the payload. 

1. What do I have to add in the Config.lb file to make it use filo? I
know CONFIG_FS_STREAM should be set to true. What else?

2. I remembered linuxbios supports ROM image size larger than 64K now.
But when got compiler errors when specifies it as 128K. Do I miss
anything?


Gin  



From gwatson at lanl.gov  Wed Nov 17 19:55:01 2004
From: gwatson at lanl.gov (Greg Watson)
Date: Wed Nov 17 19:55:01 2004
Subject: boot from ide
In-Reply-To: <000001c4cd13$1f043a60$4f01060a@nexcom.com.tw>
References: <000001c4cd13$1f043a60$4f01060a@nexcom.com.tw>
Message-ID: <797B163D-3908-11D9-A5AE-000D932F4B4A@lanl.gov>

Actually, don't set CONFIG_FS_STREAM if you're using Filo as a payload. 
Use the CONFIG_IDE_STREAM instead.

Greg

On Nov 17, 2004, at 7:05 PM, Gin wrote:

> Hello,
> I've got my linuxbios run to the point it tries to load the image from
> an IDE drive. I use FILO as the payload.
>
> 1. What do I have to add in the Config.lb file to make it use filo? I
> know CONFIG_FS_STREAM should be set to true. What else?
>
> 2. I remembered linuxbios supports ROM image size larger than 64K now.
> But when got compiler errors when specifies it as 128K. Do I miss
> anything?
>
>
> Gin
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>



From ginlin at nexcom.com.tw  Wed Nov 17 23:11:01 2004
From: ginlin at nexcom.com.tw (Gin)
Date: Wed Nov 17 23:11:01 2004
Subject: boot from ide
Message-ID: <000001c4cd30$b95c1340$4f01060a@nexcom.com.tw>

Thanks, 
I got an error while specifying the fall back rom image size of larger
than 64K. See below: 

1. When ROM_IMAGE_SIZE = 0x2000
./buildrom linuxbios.strip linuxbios.rom /opt/filo/fallback/filo.elf
0x20000 0x40000
linuxbios image is 131087 bytes; only 131072 allowed
Linuxbios input file larger than allowed size!
: Success
make: *** [linuxbios.rom] Error 2

2.When ROM_IMAGE_SIZE = 0x3000
./buildrom linuxbios.strip linuxbios.rom /opt/filo/fallback/filo.elf
0x30000 0x40000
linuxbios image is 196623 bytes; only 196608 allowed
Linuxbios input file larger than allowed size!
: Success
make: *** [linuxbios.rom] Error 2 

-----Original Message-----
From: linuxbios-admin at clustermatic.org
[mailto:linuxbios-admin at clustermatic.org] On Behalf Of Greg Watson
Sent: Thursday, November 18, 2004 10:21 AM
To: Gin
Cc: 'LinuxBIOS'
Subject: Re: boot from ide

Actually, don't set CONFIG_FS_STREAM if you're using Filo as a payload. 
Use the CONFIG_IDE_STREAM instead.

Greg

On Nov 17, 2004, at 7:05 PM, Gin wrote:

> Hello,
> I've got my linuxbios run to the point it tries to load the image from
> an IDE drive. I use FILO as the payload.
>
> 1. What do I have to add in the Config.lb file to make it use filo? I
> know CONFIG_FS_STREAM should be set to true. What else?
>
> 2. I remembered linuxbios supports ROM image size larger than 64K now.
> But when got compiler errors when specifies it as 128K. Do I miss
> anything?
>
>
> Gin
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>

_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios



From zhushisongzhu at yahoo.com  Thu Nov 18 05:46:00 2004
From: zhushisongzhu at yahoo.com (zhu shi song)
Date: Thu Nov 18 05:46:00 2004
Subject: i845 progress
Message-ID: <20041118121311.39122.qmail@web13203.mail.yahoo.com>

At last , rtl8139 work correctly.
Now I'm working on VGA(internal graphic device).  I
set 0x52(graphic control register) to 0x40 to let IGD
enable and SMA size to 8M, but filo reset MB. I need
to set some other things?
  tks
  zhu





		
__________________________________ 
Do you Yahoo!? 
The all-new My Yahoo! - Get yours free! 
http://my.yahoo.com 
 



From ebiederman at lnxi.com  Thu Nov 18 06:46:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Nov 18 06:46:01 2004
Subject: ppc targets
In-Reply-To: <m3fz38i6xb.fsf@maxwell.lnxi.com>
References: <20041111154204.GA27761@openbios.org>
	<m3hdnv94zo.fsf@maxwell.lnxi.com>
	<549D62F4-34FE-11D9-8723-000D932F4B4A@computer.org>
	<m3fz38i6xb.fsf@maxwell.lnxi.com>
Message-ID: <m3y8gzi9ln.fsf@maxwell.lnxi.com>

Just a progress update before I go to bed.

I have the totalimpact/briq building now.  There are a couple of things
that are not quite right but nothing architectural. 

Looking at where the code is I should be able to get the
sandpointx3+pmc/altimus/mpc7410 building.  Since there is only one pmc
supported things look much simpler :)

Beyond that a lot of my confusion has been looking at code and
expecting it to work, or to handle the general case when in fact
it doesn't.  

As I settle for merely fixing the code so it continues to do what
it did before, I can successfully make a lot of progress.

Eric



From gwatson at lanl.gov  Thu Nov 18 07:36:00 2004
From: gwatson at lanl.gov (Greg Watson)
Date: Thu Nov 18 07:36:00 2004
Subject: ppc targets
In-Reply-To: <m3y8gzi9ln.fsf@maxwell.lnxi.com>
References: <20041111154204.GA27761@openbios.org> <m3hdnv94zo.fsf@maxwell.lnxi.com> <549D62F4-34FE-11D9-8723-000D932F4B4A@computer.org> <m3fz38i6xb.fsf@maxwell.lnxi.com> <m3y8gzi9ln.fsf@maxwell.lnxi.com>
Message-ID: <893E9B0B-396A-11D9-A5AE-000D932F4B4A@lanl.gov>

On Nov 18, 2004, at 6:13 AM, Eric W. Biederman wrote:

>
> Just a progress update before I go to bed.
>
> I have the totalimpact/briq building now.  There are a couple of things
> that are not quite right but nothing architectural.
>
> Looking at where the code is I should be able to get the
> sandpointx3+pmc/altimus/mpc7410 building.  Since there is only one pmc
> supported things look much simpler :)
>
> Beyond that a lot of my confusion has been looking at code and
> expecting it to work, or to handle the general case when in fact
> it doesn't.
>
> As I settle for merely fixing the code so it continues to do what
> it did before, I can successfully make a lot of progress.
>
> Eric
>

The problem with both the briq and the ep405pc is the lack of 
board-level documentation. This makes adding support painstakingly slow 
at best.

I will be satisfied having the code back to the point where at least 
development can continue.

Greg



From rminnich at lanl.gov  Thu Nov 18 08:45:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Thu Nov 18 08:45:01 2004
Subject: boot from ide
In-Reply-To: <000001c4cd13$1f043a60$4f01060a@nexcom.com.tw>
References: <000001c4cd13$1f043a60$4f01060a@nexcom.com.tw>
Message-ID: <Pine.LNX.4.58.0411180810050.7881@linux.site>

Here is my filo-using config

# Sample config file for the Arima HDAMA

target hdama.filo
mainboard arima/hdama
option DEFAULT_CONSOLE_LOGLEVEL=5
option MAXIMUM_CONSOLE_LOGLEVEL=5


romimage "normal"
	option USE_FALLBACK_IMAGE=0
	option ROM_IMAGE_SIZE=0x10000
	option LINUXBIOS_EXTRA_VERSION=".0Normal"
	payload /opt/filo/normal/filo.elf
end

romimage "fallback" 
	option USE_FALLBACK_IMAGE=1
	option ROM_IMAGE_SIZE=0x10000
	option LINUXBIOS_EXTRA_VERSION=".0Fallback"
	payload /opt/filo/fallback/filo.elf
end

buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback"



From ollie at lanl.gov  Thu Nov 18 14:34:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Nov 18 14:34:00 2004
Subject: Resource base 0x1xy for AMD K8 northbridge.
Message-ID: <1100811624.15287.2920.camel@exponential.lanl.gov>

Eric,

Why you add 0x100 to the resource base register for AMDK8 Function 1, in
find_mem|io_pair()?


	if (reg > 0) {
		resource = new_resource(dev, 0x100 + (reg | link));
	}

Ollie




From jmiller at actuality-systems.com  Thu Nov 18 16:47:01 2004
From: jmiller at actuality-systems.com (Jay Miller)
Date: Thu Nov 18 16:47:01 2004
Subject: reset loop??
Message-ID: <E8F8DBCB0468204E856114A2CD20741F390898@mail.local.ActualitySystems.com>

Has anyone seen a situation where the BIOS appears stuck in a reset loop
on cold boot?

On cold boot our board continually loops through the reset path.  We had
apparently "worked around" this problem by pointing HARD_RESET_DEVICE to
the 8131, which meant that nothing actually got reset.  But now we're
running into interrupt problems caused by the "work around" that
doesn't.  

HDT loses it's mind in the protected_start section, just prior to the
reset, but I have stopped it to see that there is only the 8151 on the
PCI bus scan.  This is more that likely a red herring...

I thought it might be an ht issue because needs_reset gets set by the
ht_setup_chain, and our board is unique in that it has 8151->8131->8111
all on link 0.  But I adjusted the position passed into that function
and saw no improvement.  Perhaps the position I chose was wrong (0xa0 vs
the default 0x80)?

Any other thoughts?

Thanks,

Jay Miller
781-229-7812x117
Actuality Systems, Inc.
jmiller at actuality-systems.com




From ginlin at nexcom.com.tw  Thu Nov 18 19:06:01 2004
From: ginlin at nexcom.com.tw (Gin)
Date: Thu Nov 18 19:06:01 2004
Subject: boot from ide
In-Reply-To: <Pine.LNX.4.58.0411180810050.7881@linux.site>
Message-ID: <000801c4cdd7$b021e2d0$4f01060a@nexcom.com.tw>

Thanks for the file. But would it work if I specify the ROM_IMAGE_SIZE
larger than 0x10000?


-----Original Message-----
From: linuxbios-admin at clustermatic.org
[mailto:linuxbios-admin at clustermatic.org] On Behalf Of Ronald G. Minnich
Sent: Thursday, November 18, 2004 11:11 PM
To: Gin
Cc: 'LinuxBIOS'
Subject: Re: boot from ide

Here is my filo-using config

# Sample config file for the Arima HDAMA

target hdama.filo
mainboard arima/hdama
option DEFAULT_CONSOLE_LOGLEVEL=5
option MAXIMUM_CONSOLE_LOGLEVEL=5


romimage "normal"
	option USE_FALLBACK_IMAGE=0
	option ROM_IMAGE_SIZE=0x10000
	option LINUXBIOS_EXTRA_VERSION=".0Normal"
	payload /opt/filo/normal/filo.elf
end

romimage "fallback" 
	option USE_FALLBACK_IMAGE=1
	option ROM_IMAGE_SIZE=0x10000
	option LINUXBIOS_EXTRA_VERSION=".0Fallback"
	payload /opt/filo/fallback/filo.elf
end

buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback"

_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios



From ginlin at nexcom.com.tw  Thu Nov 18 21:42:00 2004
From: ginlin at nexcom.com.tw (Gin)
Date: Thu Nov 18 21:42:00 2004
Subject: ROM_IMAGE_SIZE
In-Reply-To: <000801c4cdd7$b021e2d0$4f01060a@nexcom.com.tw>
Message-ID: <000001c4cded$8552dd00$4f01060a@nexcom.com.tw>

Not sure why this is happening. When I specify the ROM_IMAGE_SIZE to be
larger than 64k. The file linuxbios.strip is larger than linuxbios,
which is the file before the objcopy. This doesn't happen to the
rom_image_size that is 64k.
Here is the file size info. 

[root at localhost fallback]# ls -l linuxbios*
-rwxr-xr-x    1 root     root       126425 Nov 19 11:28 linuxbios
-rw-r--r--    1 root     root       155892 Nov 19 11:28 linuxbios.a
-rw-r--r--    1 root     root        39445 Nov 19 11:28 linuxbios.map
-rwxr-xr-x    1 root     root       149179 Nov 19 11:28 linuxbios_ram
-rwxr-xr-x    1 root     root        77008 Nov 19 11:28
linuxbios_ram.bin
-rw-r--r--    1 root     root        13331 Nov 19 11:28
linuxbios_ram.map
-rw-r--r--    1 root     root        36353 Nov 19 11:28
linuxbios_ram.nrv2b
-rw-r--r--    1 root     root       114373 Nov 19 11:28 linuxbios_ram.o
-rw-r--r--    1 root     root        36353 Nov 19 11:28
linuxbios_ram.rom
-rw-r--r--    1 root     root       262144 Nov 19 09:58 linuxbios.rom
-rwxr-xr-x    1 root     root       131087 Nov 19 11:28 linuxbios.strip
-rw-r--r--    1 root     root         4872 Nov 17 19:19
linuxbios_table.o


Gin
 



From zhushisongzhu at yahoo.com  Fri Nov 19 01:20:00 2004
From: zhushisongzhu at yahoo.com (zhu shi song)
Date: Fri Nov 19 01:20:00 2004
Subject: i845gv MB progress
Message-ID: <20041119074650.6132.qmail@web13201.mail.yahoo.com>

Now I can set sma correctly.  But still can't execute
vgabios successfully. After executing testbios, the
following message prompted:
****************************
[root at localhost /app]# ./testbios -s 65536 ./i845.vga
running file ./i845.vga
No base specified. defaulting to 0xc0000
No initial code segment specified. defaulting to
0xc000
No initial instruction pointer specified. defaulting
to 0x0003
c000:015a: 62 ILLEGAL X86 OPCODE!
halt_sys: file ops.c, line 94
halted
*************************************
what can I do to solve the problem?

  tks
  zhu


		
__________________________________ 
Do you Yahoo!? 
The all-new My Yahoo! - Get yours free! 
http://my.yahoo.com 
 



From stepan at openbios.org  Fri Nov 19 01:45:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Fri Nov 19 01:45:01 2004
Subject: reset loop??
In-Reply-To: <E8F8DBCB0468204E856114A2CD20741F390898@mail.local.ActualitySystems.com>
References: <E8F8DBCB0468204E856114A2CD20741F390898@mail.local.ActualitySystems.com>
Message-ID: <20041119081151.GA11075@openbios.org>

* Jay Miller <jmiller at actuality-systems.com> [041119 00:13]:
> I thought it might be an ht issue because needs_reset gets set by the
> ht_setup_chain, and our board is unique in that it has 8151->8131->8111
> all on link 0.  But I adjusted the position passed into that function
> and saw no improvement.  Perhaps the position I chose was wrong (0xa0 vs
> the default 0x80)?

80 is ldt0, a0 is ldt1, c0 is ldt2

Stefan



From zhushisongzhu at yahoo.com  Fri Nov 19 03:32:00 2004
From: zhushisongzhu at yahoo.com (zhu shi song)
Date: Fri Nov 19 03:32:00 2004
Subject: i845GV VGA progress
Message-ID: <20041119095906.18730.qmail@web13202.mail.yahoo.com>

I use intelfb in linux-2.4.27.  VGA of i845 can work
correctly except that there is no cursor.  So if there
is no cursor, it's almost nothing for practical usage.
 Now I hope I can find some way to fix it up in
intelfb.

tks
zhu


		
__________________________________ 
Do you Yahoo!? 
Meet the all-new My Yahoo! - Try it today! 
http://my.yahoo.com 
 



From zhushisongzhu at yahoo.com  Fri Nov 19 05:48:00 2004
From: zhushisongzhu at yahoo.com (zhu shi song)
Date: Fri Nov 19 05:48:00 2004
Subject: i845GV VGA progress(cont.)
Message-ID: <20041119121502.11286.qmail@web13206.mail.yahoo.com>

The following are messages from linuxbios V1 vgabios
call:
******************
INSTALL REAL-MODE IDT
DO THE VGA BIOS
found VGA: vid=8086, did=2562
rom base predefined, size: fffc0000
0x55 0xaa 0x5a 0xe9 0xf7 0xab 0x30 0x30 0x30 0x30 0x30
0x30 0x30 0x30 0x30 0x30 bus/devfn = 0x10
biosint: # 0x2, eax 0x3 ebx 0xc000 ecx 0x3 edx 0x3b4
biosint: ebp 0x10fe4 esp 0xfd6 edi 0x10080 esi 0x10a5b
biosint: ip 0x145b cs 0xc000 flags 0x246
biosint: Oops, exception 2
Stack contents: 0x145b 0xc000 0x0246 0xade6 0xc000
0x0046 0xac61 0xac2b 0x0000 0x0000 0x46cc 0x8798
0x8680 0x0ffa 0x0010 0xe524 0x0010 0x0010 0x0046
0x8e1d 0x0000 
biosint: Bailing out
***************************
is there any progress on it?
tks
zhu


		
__________________________________ 
Do you Yahoo!? 
Meet the all-new My Yahoo! - Try it today! 
http://my.yahoo.com 
 



From rminnich at lanl.gov  Fri Nov 19 10:35:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Nov 19 10:35:00 2004
Subject: boot from ide
In-Reply-To: <000801c4cdd7$b021e2d0$4f01060a@nexcom.com.tw>
References: <000801c4cdd7$b021e2d0$4f01060a@nexcom.com.tw>
Message-ID: <Pine.LNX.4.58.0411191000290.11606@linux.site>


On Fri, 19 Nov 2004, Gin wrote:

> Thanks for the file. But would it work if I specify the ROM_IMAGE_SIZE
> larger than 0x10000?

good question. 

I just found this out: there is a bug in the new build that has crept in. 

If I build linuxbios from this file, and flash a 512KB flash, it won't 
boot. 

If I do this:
cat linuxbios.rom linuxbios.rom > 1M
flash_rom 1M

to a 1M part, to boots fine. 

I'm tracking it down.

ron


From rminnich at lanl.gov  Fri Nov 19 10:44:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Nov 19 10:44:01 2004
Subject: i845gv MB progress
In-Reply-To: <20041119074650.6132.qmail@web13201.mail.yahoo.com>
References: <20041119074650.6132.qmail@web13201.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0411191004150.11606@linux.site>


On Thu, 18 Nov 2004, zhu shi song wrote:

> Now I can set sma correctly.  But still can't execute
> vgabios successfully. After executing testbios, the
> following message prompted:
> ****************************
> [root at localhost /app]# ./testbios -s 65536 ./i845.vga
> running file ./i845.vga
> No base specified. defaulting to 0xc0000
> No initial code segment specified. defaulting to
> 0xc000
> No initial instruction pointer specified. defaulting
> to 0x0003
> c000:015a: 62 ILLEGAL X86 OPCODE!
> halt_sys: file ops.c, line 94
> halted
> *************************************
> what can I do to solve the problem?
> 

turn tracing on. I'm finding more limitations in the emulator. I would be 
interested to see what instruction is not implemented.

ron


From rminnich at lanl.gov  Fri Nov 19 10:44:09 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Nov 19 10:44:09 2004
Subject: i845GV VGA progress(cont.)
In-Reply-To: <20041119121502.11286.qmail@web13206.mail.yahoo.com>
References: <20041119121502.11286.qmail@web13206.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0411191005480.11606@linux.site>


On Fri, 19 Nov 2004, zhu shi song wrote:

> The following are messages from linuxbios V1 vgabios
> call:
> ******************
> INSTALL REAL-MODE IDT
> DO THE VGA BIOS
> found VGA: vid=8086, did=2562
> rom base predefined, size: fffc0000
> 0x55 0xaa 0x5a 0xe9 0xf7 0xab 0x30 0x30 0x30 0x30 0x30
> 0x30 0x30 0x30 0x30 0x30 bus/devfn = 0x10
> biosint: # 0x2, eax 0x3 ebx 0xc000 ecx 0x3 edx 0x3b4
> biosint: ebp 0x10fe4 esp 0xfd6 edi 0x10080 esi 0x10a5b
> biosint: ip 0x145b cs 0xc000 flags 0x246
> biosint: Oops, exception 2
> Stack contents: 0x145b 0xc000 0x0246 0xade6 0xc000
> 0x0046 0xac61 0xac2b 0x0000 0x0000 0x46cc 0x8798
> 0x8680 0x0ffa 0x0010 0xe524 0x0010 0x0010 0x0046
> 0x8e1d 0x0000 
> biosint: Bailing out
> ***************************
> is there any progress on it?
> tks
> zhu


we're going toward full emulation as the vgabios'es do things that are 
very unclean.

ron


From zhushisongzhu at yahoo.com  Sat Nov 20 00:07:00 2004
From: zhushisongzhu at yahoo.com (zhu shi song)
Date: Sat Nov 20 00:07:00 2004
Subject: Good News of i845GV
Message-ID: <20041120063352.98780.qmail@web13202.mail.yahoo.com>

  Now I can make intelfb work correctly.  I upgrade
intelfb driver of kernel 2.4.28 to 0.7.7 I have
downloaded from author's website.  It can work and
cursor there is no problem.
  Linuxbios is very great work.  I just grab some code
from factory's bios and set northbridge and
southbridge after the values of vendor's bios.  I can
make it boot linux 2.4.28.  Out of my surprise it can
support vga very well.
thanks all guys who have contributed to linuxbios.

zhu






		
__________________________________ 
Do you Yahoo!? 
The all-new My Yahoo! - Get yours free! 
http://my.yahoo.com 
 



From talbotx at comcast.net  Mon Nov 22 00:14:01 2004
From: talbotx at comcast.net (Adam Talbot)
Date: Mon Nov 22 00:14:01 2004
Subject: Any ides on how to build a confing for the 82855GME northbridge?
Message-ID: <003e01c4d05e$633e5870$9901a8c0@newflame>

Any ides on how to build a confing for the 82855GME northbridge?
I am having no end of problems setting up linux bios on my LV-671
motherboard.
Been working on this board for a few weeks now.  I have two other system
running Linux BIOS with out any problems, but they are both 440bx systems.
This system is running a north bridge that is not supported (82855GME), yet.
First and for most, to get the system booting. As of yet I have been unable
to get the system to boot, console or vga output. So far I have built up a
custom config basted on the tyan tiger board already in the motherboard
folder, but had very little luck compiling and none booting.  The flash ROM
chip is 512KB in size; I am hoping to fit the whole Linux bios on that; just
enough to boot the main kernel off the disk.. I have a nice flash burner,
and have no issues with bad flash's, I can always reflash with the stock
bios.   I would like to stay away from having to buy a DOC for this system.
The motherboard has built on CF (compact flash) if I can't fit the whole
Linux bios on the flash ROM, then I am going to try to boot from the ROM and
switch to the CF, but this may be the same idea as booting from HDD. The
whole point of this is to get my system to boot faster.  I would like to
build this into my car as an embedded MP3 player. I have almost every thing
running correctly in Linux, MP3's, GPS, Hibernate(suspend to disk) but need
a faster boot time. Any ideas or help on getting a config running for this
board would be of great help.
-Adam Talbot

System specs:
Gentoo Linux
1.5GHz PM CPU
512MB ddr
60GB HDD
32MB CF card
Supre IO: w83627hf
Northbridge: 82855GME
Southbridge: 82801db

 (The link to my board)
http://www.commell.com.tw/Product/SBC/LV-671.HTM

carcomp # lspci
0000:00:00.0 Host bridge: Intel Corp. 82852/82855 GM/GME/PM/GMV Processor to
I/O Controller (rev 02)
0000:00:00.1 System peripheral: Intel Corp. 82852/82855 GM/GME/PM/GMV
Processor to I/O Controller (rev 02)
0000:00:00.3 System peripheral: Intel Corp. 82852/82855 GM/GME/PM/GMV
Processor to I/O Controller (rev 02)
0000:00:02.0 VGA compatible controller: Intel Corp. 82852/855GM Integrated
Graphics Device (rev 02)
0000:00:02.1 Display controller: Intel Corp. 82852/855GM Integrated Graphics
Device (rev 02)
0000:00:1d.0 USB Controller: Intel Corp. 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 02)
0000:00:1d.1 USB Controller: Intel Corp. 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 02)
0000:00:1d.2 USB Controller: Intel Corp. 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 02)
0000:00:1d.7 USB Controller: Intel Corp. 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI
Controller (rev 02)
0000:00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 82)
0000:00:1f.0 ISA bridge: Intel Corp. 82801DB/DBL (ICH4/ICH4-L) LPC Interface
Bridge (rev 02)
0000:00:1f.1 IDE interface: Intel Corp. 82801DB (ICH4) IDE Controller (rev
02)
0000:00:1f.3 SMBus: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus
Controller (rev 02)
0000:00:1f.5 Multimedia audio controller: Intel Corp. 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 02)
0000:01:0b.0 CardBus bridge: Ricoh Co Ltd RL5c475 (rev 80)
0000:01:0d.0 Ethernet controller: Intel Corp. 82540EM Gigabit Ethernet
Controller (rev 02)




From rminnich at lanl.gov  Mon Nov 22 11:02:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Nov 22 11:02:00 2004
Subject: Good News of i845GV
In-Reply-To: <20041120063352.98780.qmail@web13202.mail.yahoo.com>
References: <20041120063352.98780.qmail@web13202.mail.yahoo.com>
Message-ID: <Pine.LNX.4.58.0411220902360.24552@linux.site>

what kind of board are you using?

ron



From rminnich at lanl.gov  Mon Nov 22 11:16:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Nov 22 11:16:01 2004
Subject: Any ides on how to build a confing for the 82855GME northbridge?
In-Reply-To: <003e01c4d05e$633e5870$9901a8c0@newflame>
References: <003e01c4d05e$633e5870$9901a8c0@newflame>
Message-ID: <Pine.LNX.4.58.0411221042120.24724@linux.site>

I'm trying to get this gm working too. 

It's a battle, the docs are not really usable. 

one question you should ask yourself -- does it have to be this part from 
this vendor? Is there a compelling reason to work on this instead of an 
amd64 board, given that AMD is very helpful w.r.t. LinuxBIOS? 

Anyway, if you find you need this chip, let me know, and we can try to 
work it out.

ron



From rminnich at lanl.gov  Mon Nov 22 14:33:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Nov 22 14:33:00 2004
Subject: interesting ...
Message-ID: <Pine.LNX.4.58.0411221400120.24724@linux.site>

this is on arima hdama. 

I build a linuxbios and it boots fallback. All is fine. 

I use cmos_util to set boot options to normal and reboot. This is fine. 

Then I reboot one more time. NO serial output, no nothing. NO output at 
all. 

Anyone seen this?

ron


From rminnich at lanl.gov  Mon Nov 22 14:47:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Nov 22 14:47:01 2004
Subject: ah yes, my config for the arima
Message-ID: <Pine.LNX.4.58.0411221414030.24724@linux.site>


# Sample config file for the Arima HDAMA

target hdama.filo
mainboard arima/hdama
option DEFAULT_CONSOLE_LOGLEVEL=3
option MAXIMUM_CONSOLE_LOGLEVEL=9


romimage "normal"
	option USE_FALLBACK_IMAGE=0
	option ROM_IMAGE_SIZE=0x10000
	option LINUXBIOS_EXTRA_VERSION=".0Normal"
	payload /opt/filo/normal/filo.elf
end

romimage "fallback" 
	option USE_FALLBACK_IMAGE=1
	option ROM_IMAGE_SIZE=0x10000
	option LINUXBIOS_EXTRA_VERSION=".0Fallback"
	payload /opt/filo/fallback/filo.elf
end

buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback"



that's it. nothing exciting ...

ron


From talbotx at comcast.net  Mon Nov 22 15:33:00 2004
From: talbotx at comcast.net (Adam Talbot)
Date: Mon Nov 22 15:33:00 2004
Subject: How do i join
Message-ID: <00cc01c4d0de$b7739920$9901a8c0@newflame>

How do i join this mailing list?
-Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20041122/6b53fbcb/attachment.html>

From talbotx at comcast.net  Mon Nov 22 16:18:00 2004
From: talbotx at comcast.net (Adam Talbot)
Date: Mon Nov 22 16:18:00 2004
Subject: Need a hand with freebios2
Message-ID: <00e101c4d0e5$06518330$9901a8c0@newflame>

I was good with the tools in freebios, but I do not no my way around freebios2.  Are there any "How To" guides for setting up a bios in freebios2?? 
-Adam Talbot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20041122/dfca6d2c/attachment.html>

From jbors at mail.ru  Mon Nov 22 16:28:00 2004
From: jbors at mail.ru (Dmitry Borisov)
Date: Mon Nov 22 16:28:00 2004
Subject: [PATCH] SPD autoconfigure logic for EPIA-M
References: <200411152358.iAFNw1hh024727@xdr.com>
Message-ID: <037a01c4d0e6$64a8b510$0200a8c0@amr.corp.intel.com>

From: "Dave Ashley" <linuxbios at xdr.com>
To: <linuxbios at clustermatic.org>
Sent: Monday, November 15, 2004 3:58 PM
Subject: [PATCH] SPD autoconfigure logic for EPIA-M


> Here is NXTV's ramini.c to be placed in version 1 of linuxbios
> src/northbridge/via/vt8623/raminit.inc
>
> It was written by Felipe Rodriguez for NXTV and is now being contributed
> back to the linuxbios project. His email address is included in the
> comments in the file.
>
> It assumes the SPD contents on the module are valid, and it sets up
> the CLE266 DDR controller appropriately.
>
> Features:
> o Detects number of ram banks
> o Properly tunes tunables
> o Detects column and row address sizes
> o Works for every 128M DDR module we've tried as well as one 256M
>   module, correctly setting the available memory in linux.
> o Lots of comments for reference
>
> Now if someone else wants to convert this X86 code to C code for romcc
> in version 2, that would be great.
>
> Enjoy!

Dave,
Thank you so much for contributing it back. Any news in VGA stuff for CLE266
?
Dmitry/



From YhLu at tyan.com  Mon Nov 22 16:31:00 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Nov 22 16:31:00 2004
Subject: Direct message to com2
Message-ID: <3174569B9743D511922F00A0C943142306BA32CE@TYANWEB>

Who has met such problem?

I changed the linuxbios to direct message to com2 via changing 
1. SP1 to SP2 in auto.c
2. enable com2 in Config.lb
3. change 0x3f8 to 0x2f8 in Options.lb

Etherboot change 0x3f8 to 0x2f8.

Then After Ethertboot get the elf image from tftp server, it will hang a
while (30s) at "Firmware type: LinuxBIOS", and that message is not shown.

I remember several months ago, when I make message comes to both ports (COM1
and COM2), it worked well....

Weird.

Regards

YH


[tg3-5703X]Ethernet addr: 00:E0:81:27:2D:30
Tigon3 [partno(BCM95703A30) rev 1002 PHY(5703)] (PCIX:100MHz:64-bit)
Link is up at 1000 Mbps, full duplex. TX RX flow control
Searching for server (DHCP)...
..Me: 192.168.1.191, Server: 192.168.1.1, Gateway 192.168.1.1
Loading 192.168.1.1:ram0_2.5_2.6.9_k8.2_mydisk8_com2.elf ...(ELF)...
...............................................................
.......................................................
............................................................................
...............................................done
(Firmware type: LinuxBIOS)
old bootloader convention, maybe loadlin?
Bootdata ok (command line is root=/dev/ram0 rw console=ttyS0,115200n8 )
Linux version 2.6.9 (root at tst288xsuse9) (gcc version 3.3.3 (SuSE Linux)) #15
SMP Mon Nov 22 14:53:36 PST 2004


From YhLu at tyan.com  Mon Nov 22 19:31:00 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Nov 22 19:31:00 2004
Subject: [Etherboot-users] Direct message to com2
Message-ID: <3174569B9743D511922F00A0C943142306BA32ED@TYANWEB>

Eric,
 I add second serial_x.c to support com2. then it works well.

The "Firmware type: LinuxBIOS" only comes out in COM1.

Which segement print " Firmware type: LinuxBIOS" ?, it seems hardcoded to
use 0x3f8.

Regards

YH


-----Original Message-----
From: YhLu 
Sent: Monday, November 22, 2004 3:04 PM
To: linuxbios at clustermatic.org; ebiederman at lnxi.com;
etherboot-users at lists.sourceforge.net
Subject: [Etherboot-users] Direct message to com2

Who has met such problem?

I changed the linuxbios to direct message to com2 via changing 
1. SP1 to SP2 in auto.c
2. enable com2 in Config.lb
3. change 0x3f8 to 0x2f8 in Options.lb

Etherboot change 0x3f8 to 0x2f8.

Then After Ethertboot get the elf image from tftp server, it will hang a
while (30s) at "Firmware type: LinuxBIOS", and that message is not shown.

I remember several months ago, when I make message comes to both ports (COM1
and COM2), it worked well....

Weird.

Regards

YH


[tg3-5703X]Ethernet addr: 00:E0:81:27:2D:30
Tigon3 [partno(BCM95703A30) rev 1002 PHY(5703)] (PCIX:100MHz:64-bit)
Link is up at 1000 Mbps, full duplex. TX RX flow control
Searching for server (DHCP)...
..Me: 192.168.1.191, Server: 192.168.1.1, Gateway 192.168.1.1
Loading 192.168.1.1:ram0_2.5_2.6.9_k8.2_mydisk8_com2.elf ...(ELF)...
...............................................................
.......................................................
............................................................................
...............................................done
(Firmware type: LinuxBIOS)
old bootloader convention, maybe loadlin?
Bootdata ok (command line is root=/dev/ram0 rw console=ttyS0,115200n8 )
Linux version 2.6.9 (root at tst288xsuse9) (gcc version 3.3.3 (SuSE Linux)) #15
SMP Mon Nov 22 14:53:36 PST 2004


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Etherboot-users mailing list
Etherboot-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/etherboot-users


From YhLu at tyan.com  Mon Nov 22 19:46:00 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Nov 22 19:46:00 2004
Subject: [Etherboot-users] Direct message to com2
Message-ID: <3174569B9743D511922F00A0C943142306BA32F1@TYANWEB>

It's in mkelfImage 2.5
linux-i386/ convert_params.c

it is hardcode to 0x3f8.

YH



-----Original Message-----
From: YhLu 
Sent: Monday, November 22, 2004 6:05 PM
To: ebiederman at lnxi.com
Cc: linuxbios at clustermatic.org; etherboot-users at lists.sourceforge.net
Subject: RE: [Etherboot-users] Direct message to com2

Eric,
 I add second serial_x.c to support com2. then it works well.

The "Firmware type: LinuxBIOS" only comes out in COM1.

Which segement print " Firmware type: LinuxBIOS" ?, it seems hardcoded to
use 0x3f8.

Regards

YH


-----Original Message-----
From: YhLu 
Sent: Monday, November 22, 2004 3:04 PM
To: linuxbios at clustermatic.org; ebiederman at lnxi.com;
etherboot-users at lists.sourceforge.net
Subject: [Etherboot-users] Direct message to com2

Who has met such problem?

I changed the linuxbios to direct message to com2 via changing 
1. SP1 to SP2 in auto.c
2. enable com2 in Config.lb
3. change 0x3f8 to 0x2f8 in Options.lb

Etherboot change 0x3f8 to 0x2f8.

Then After Ethertboot get the elf image from tftp server, it will hang a
while (30s) at "Firmware type: LinuxBIOS", and that message is not shown.

I remember several months ago, when I make message comes to both ports (COM1
and COM2), it worked well....

Weird.

Regards

YH


[tg3-5703X]Ethernet addr: 00:E0:81:27:2D:30
Tigon3 [partno(BCM95703A30) rev 1002 PHY(5703)] (PCIX:100MHz:64-bit)
Link is up at 1000 Mbps, full duplex. TX RX flow control
Searching for server (DHCP)...
..Me: 192.168.1.191, Server: 192.168.1.1, Gateway 192.168.1.1
Loading 192.168.1.1:ram0_2.5_2.6.9_k8.2_mydisk8_com2.elf ...(ELF)...
...............................................................
.......................................................
............................................................................
...............................................done
(Firmware type: LinuxBIOS)
old bootloader convention, maybe loadlin?
Bootdata ok (command line is root=/dev/ram0 rw console=ttyS0,115200n8 )
Linux version 2.6.9 (root at tst288xsuse9) (gcc version 3.3.3 (SuSE Linux)) #15
SMP Mon Nov 22 14:53:36 PST 2004


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Etherboot-users mailing list
Etherboot-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/etherboot-users


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Etherboot-users mailing list
Etherboot-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/etherboot-users


From YhLu at tyan.com  Mon Nov 22 19:53:00 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Nov 22 19:53:00 2004
Subject: [Etherboot-users] Direct message to com2
Message-ID: <3174569B9743D511922F00A0C943142306BA32F5@TYANWEB>

It seems that mkelfImage should get the com address from commandline.

For example:
mkelfImage --command-line="ramdisk_size=65536 root=/dev/ram0 rw console=tty0
console=ttyS1,115200n8" --kernel=linuxkernel/bzImage_2.
6.9_k8.2 --ramdisk=rootfs/mydisk8_com2.gz
--output=elf/ram0_2.5_2.6.9_k8.2_mydisk8_com2.elf

Then makeelfImage should use 0x2f8 instead of 0x3f8 in convert_params.c
according to ttyS1.

Regards

YH

-----Original Message-----
From: YhLu 
Sent: Monday, November 22, 2004 6:20 PM
To: YhLu; ebiederman at lnxi.com
Cc: linuxbios at clustermatic.org; etherboot-users at lists.sourceforge.net
Subject: RE: [Etherboot-users] Direct message to com2

It's in mkelfImage 2.5
linux-i386/ convert_params.c

it is hardcode to 0x3f8.

YH



-----Original Message-----
From: YhLu 
Sent: Monday, November 22, 2004 6:05 PM
To: ebiederman at lnxi.com
Cc: linuxbios at clustermatic.org; etherboot-users at lists.sourceforge.net
Subject: RE: [Etherboot-users] Direct message to com2

Eric,
 I add second serial_x.c to support com2. then it works well.

The "Firmware type: LinuxBIOS" only comes out in COM1.

Which segement print " Firmware type: LinuxBIOS" ?, it seems hardcoded to
use 0x3f8.

Regards

YH


-----Original Message-----
From: YhLu 
Sent: Monday, November 22, 2004 3:04 PM
To: linuxbios at clustermatic.org; ebiederman at lnxi.com;
etherboot-users at lists.sourceforge.net
Subject: [Etherboot-users] Direct message to com2

Who has met such problem?

I changed the linuxbios to direct message to com2 via changing 
1. SP1 to SP2 in auto.c
2. enable com2 in Config.lb
3. change 0x3f8 to 0x2f8 in Options.lb

Etherboot change 0x3f8 to 0x2f8.

Then After Ethertboot get the elf image from tftp server, it will hang a
while (30s) at "Firmware type: LinuxBIOS", and that message is not shown.

I remember several months ago, when I make message comes to both ports (COM1
and COM2), it worked well....

Weird.

Regards

YH


[tg3-5703X]Ethernet addr: 00:E0:81:27:2D:30
Tigon3 [partno(BCM95703A30) rev 1002 PHY(5703)] (PCIX:100MHz:64-bit)
Link is up at 1000 Mbps, full duplex. TX RX flow control
Searching for server (DHCP)...
..Me: 192.168.1.191, Server: 192.168.1.1, Gateway 192.168.1.1
Loading 192.168.1.1:ram0_2.5_2.6.9_k8.2_mydisk8_com2.elf ...(ELF)...
...............................................................
.......................................................
............................................................................
...............................................done
(Firmware type: LinuxBIOS)
old bootloader convention, maybe loadlin?
Bootdata ok (command line is root=/dev/ram0 rw console=ttyS0,115200n8 )
Linux version 2.6.9 (root at tst288xsuse9) (gcc version 3.3.3 (SuSE Linux)) #15
SMP Mon Nov 22 14:53:36 PST 2004


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Etherboot-users mailing list
Etherboot-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/etherboot-users


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Etherboot-users mailing list
Etherboot-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/etherboot-users


From talbotx at comcast.net  Mon Nov 22 20:12:01 2004
From: talbotx at comcast.net (Adam Talbot)
Date: Mon Nov 22 20:12:01 2004
Subject: Compile error
Message-ID: <011601c4d105$a3ba3e30$9901a8c0@newflame>

Any ideas on this error? What is causing theis?

 /root/freebios2/src/mainboard/commell/lv-671/auto.c -o auto.inc
raminit.c:1369.39:
member channel1 not present
make[1]: *** [auto.inc] Error 1
make[1]: Leaving directory `/root/linuxbios/lv-671.512kflash/normal'
make: *** [normal/linuxbios.rom] Error 1



-Adam Talbot

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

From rminnich at lanl.gov  Mon Nov 22 21:56:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Nov 22 21:56:01 2004
Subject: Compile error
In-Reply-To: <011601c4d105$a3ba3e30$9901a8c0@newflame>
References: <011601c4d105$a3ba3e30$9901a8c0@newflame>
Message-ID: <Pine.LNX.4.58.0411222123350.28393@linux.site>

I need to know a *lot* more about your setup.

We can commit your initial tree if you wish so others can see.

ron



From zhushisongzhu at yahoo.com  Tue Nov 23 06:17:00 2004
From: zhushisongzhu at yahoo.com (zhu shi song)
Date: Tue Nov 23 06:17:00 2004
Subject: how to read thermal sensor in 82801db
Message-ID: <20041123124434.54189.qmail@web13205.mail.yahoo.com>

I hope I can read cpu temperature under linux.  I know
I can read thermal sensor through smbus just like
reading spd.  Who know the slave address of the sensor
and know the meaning of every byte of the sensor?  Is
there any existing utility to read thermal sensor of
81801db?
  tks
  zhu


		
__________________________________ 
Do you Yahoo!? 
Meet the all-new My Yahoo! - Try it today! 
http://my.yahoo.com 
 



From talbotx at comcast.net  Tue Nov 23 09:21:00 2004
From: talbotx at comcast.net (Adam Talbot)
Date: Tue Nov 23 09:21:00 2004
Subject: how to read thermal sensor in 82801db
Message-ID: <013c01c4d173$ef65b1c0$9901a8c0@newflame>

Wow, I think I can help on this one.
Try the link.  Its for the 82801DBM south bridge and may have what you are hunting for.
ftp://download.intel.com/design/mobile/datashts/25233701.pdf
Take a look at section 5.12.8.1.  That may be able to give you the information you are looking for.
section 9.8.3.5 has all the info about throttling but not sure if its what you are looking for.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20041123/2b9e6b25/attachment.html>

From jmiller at actuality-systems.com  Tue Nov 23 11:37:01 2004
From: jmiller at actuality-systems.com (Jay Miller)
Date: Tue Nov 23 11:37:01 2004
Subject: Compile error
Message-ID: <E8F8DBCB0468204E856114A2CD20741F390944@mail.local.ActualitySystems.com>

Hi Adam,

I'm guessing that channel1 is referring to one of your SDRAM channels.
 
Look in freebios2/src/mainboard/<company>/<board>/auto.c and potentially
mainboard.c.  Oh, and if you changed any Config.lb files you'll need to
re-generate the build directory using buildtarget <company>/<board>.

Cheers,

Jay Miller
781-229-7812x117
Actuality Systems, Inc.
jmiller at actuality-systems.com




From rminnich at lanl.gov  Tue Nov 23 12:29:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Tue Nov 23 12:29:01 2004
Subject: Compile error
In-Reply-To: <E8F8DBCB0468204E856114A2CD20741F390944@mail.local.ActualitySystems.com>
References: <E8F8DBCB0468204E856114A2CD20741F390944@mail.local.ActualitySystems.com>
Message-ID: <Pine.LNX.4.58.0411231154530.30122@linux.site>


On Tue, 23 Nov 2004, Jay Miller wrote:

> I'm guessing that channel1 is referring to one of your SDRAM channels.

Also, if you're going the 855gme, you should be looking at the 
digitallogic/adl855pc as a model, since it is for that part (misnamed in 
the tree :-)


ron


From yhlu at tyan.com  Tue Nov 23 12:56:01 2004
From: yhlu at tyan.com (Yinghai Lu)
Date: Tue Nov 23 12:56:01 2004
Subject: 4G 4 Rank memory module
In-Reply-To: <m3ekisys67.fsf@maxwell.lnxi.com>
Message-ID: <200411231755.iANHt9L30053@nwn.definitive.org>

Eric,

How to make Opteron support 4G Pc2700 4 Rank REG ECC memory modules?

Current code report "Bad SPD value".

Regards

YH



From YhLu at tyan.com  Tue Nov 23 13:16:01 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Nov 23 13:16:01 2004
Subject: 4G 4 Rank memory module
Message-ID: <3174569B9743D511922F00A0C943142306BA333A@TYANWEB>

LinuxBIOS-1.1.72.0_Fallback Tue Nov 23 10:46:38 PST 2004 starting...
02 nodes initialized.
Ram1.00
Ram1.01
Ram2.00
rows: 0x0000000d 
columns: 0x0000000c 
banks: 0x00000004 
module data width : 0x00000048 
side2 banks: 0x00000002 
Ram2.01
rows: 0x0000000d 
columns: 0x0000000c 
banks: 0x00000004 
module data width : 0x00000048 
side2 banks: 0x00000004 
Bad SPD value

CPU0 got 2G modules
CPU1 got 4G modules
Side2 banks is different.

YH

-----Original Message-----
From: YhLu 
Sent: Tuesday, November 23, 2004 11:23 AM
To: 'Eric W. Biederman'
Cc: 'LinuxBIOS'
Subject: 4G 4 Rank memory module

Eric,

How to make Opteron support 4G Pc2700 4 Rank REG ECC memory modules?

Current code report "Bad SPD value".

Regards

YH

_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From stepan at openbios.org  Tue Nov 23 14:29:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue Nov 23 14:29:00 2004
Subject: 4G 4 Rank memory module
In-Reply-To: <3174569B9743D511922F00A0C943142306BA333A@TYANWEB>
References: <3174569B9743D511922F00A0C943142306BA333A@TYANWEB>
Message-ID: <20041123205626.GA14938@openbios.org>

* YhLu <YhLu at tyan.com> [041123 20:51]:
> Ram2.00
> rows: 0x0000000d 
> columns: 0x0000000c 
> banks: 0x00000004 
> module data width : 0x00000048 
> side2 banks: 0x00000002 

> Ram2.01
> rows: 0x0000000d 
> columns: 0x0000000c 
> banks: 0x00000004 
> module data width : 0x00000048 
> side2 banks: 0x00000004 
> Bad SPD value
> 
> CPU0 got 2G modules
> CPU1 got 4G modules
> Side2 banks is different.
 
Is this with two different modules? Ram2.00 Shows a difference.
Maybe noise on the I2C bus? Ram2.01 seems to be ok..?!?

Stefan


From YhLu at tyan.com  Tue Nov 23 14:30:01 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Nov 23 14:30:01 2004
Subject: 4G 4 Rank memory module
Message-ID: <3174569B9743D511922F00A0C943142306BA3341@TYANWEB>

2G modules for CPU0
4G modules for CPU1.

-----Original Message-----
From: Stefan Reinauer [mailto:stepan at openbios.org] 
Sent: Tuesday, November 23, 2004 12:56 PM
To: YhLu
Cc: 'Eric W. Biederman'; 'LinuxBIOS'
Subject: Re: 4G 4 Rank memory module

* YhLu <YhLu at tyan.com> [041123 20:51]:
> Ram2.00
> rows: 0x0000000d 
> columns: 0x0000000c 
> banks: 0x00000004 
> module data width : 0x00000048 
> side2 banks: 0x00000002 

> Ram2.01
> rows: 0x0000000d 
> columns: 0x0000000c 
> banks: 0x00000004 
> module data width : 0x00000048 
> side2 banks: 0x00000004 
> Bad SPD value
> 
> CPU0 got 2G modules
> CPU1 got 4G modules
> Side2 banks is different.
 
Is this with two different modules? Ram2.00 Shows a difference.
Maybe noise on the I2C bus? Ram2.01 seems to be ok..?!?

Stefan


From stepan at openbios.org  Tue Nov 23 14:35:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue Nov 23 14:35:01 2004
Subject: 4G 4 Rank memory module
In-Reply-To: <3174569B9743D511922F00A0C943142306BA3341@TYANWEB>
References: <3174569B9743D511922F00A0C943142306BA3341@TYANWEB>
Message-ID: <20041123210254.GA15815@openbios.org>

* YhLu <YhLu at tyan.com> [041123 22:04]:
> 2G modules for CPU0

It seems to dislike the 2G Modules it seems..? Can you try with only the
4G modules?


> 4G modules for CPU1.
> 
> -----Original Message-----
> From: Stefan Reinauer [mailto:stepan at openbios.org] 
> Sent: Tuesday, November 23, 2004 12:56 PM
> To: YhLu
> Cc: 'Eric W. Biederman'; 'LinuxBIOS'
> Subject: Re: 4G 4 Rank memory module
> 
> * YhLu <YhLu at tyan.com> [041123 20:51]:
> > Ram2.00
> > rows: 0x0000000d 
> > columns: 0x0000000c 
> > banks: 0x00000004 
> > module data width : 0x00000048 
> > side2 banks: 0x00000002 
> 
> > Ram2.01
> > rows: 0x0000000d 
> > columns: 0x0000000c 
> > banks: 0x00000004 
> > module data width : 0x00000048 
> > side2 banks: 0x00000004 
> > Bad SPD value
> > 
> > CPU0 got 2G modules
> > CPU1 got 4G modules
> > Side2 banks is different.
>  
> Is this with two different modules? Ram2.00 Shows a difference.
> Maybe noise on the I2C bus? Ram2.01 seems to be ok..?!?
> 
> Stefan
> 


From YhLu at tyan.com  Tue Nov 23 14:38:00 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Nov 23 14:38:00 2004
Subject: 4G 4 Rank memory module
Message-ID: <3174569B9743D511922F00A0C943142306BA3342@TYANWEB>

It can treat 4G as 2G modules, if I comment out physical bank check. (!=2
get out).

YH

-----Original Message-----
From: Stefan Reinauer [mailto:stepan at openbios.org] 
Sent: Tuesday, November 23, 2004 1:03 PM
To: YhLu
Cc: 'Eric W. Biederman'; 'LinuxBIOS'
Subject: Re: 4G 4 Rank memory module

* YhLu <YhLu at tyan.com> [041123 22:04]:
> 2G modules for CPU0

It seems to dislike the 2G Modules it seems..? Can you try with only the
4G modules?


> 4G modules for CPU1.
> 
> -----Original Message-----
> From: Stefan Reinauer [mailto:stepan at openbios.org] 
> Sent: Tuesday, November 23, 2004 12:56 PM
> To: YhLu
> Cc: 'Eric W. Biederman'; 'LinuxBIOS'
> Subject: Re: 4G 4 Rank memory module
> 
> * YhLu <YhLu at tyan.com> [041123 20:51]:
> > Ram2.00
> > rows: 0x0000000d 
> > columns: 0x0000000c 
> > banks: 0x00000004 
> > module data width : 0x00000048 
> > side2 banks: 0x00000002 
> 
> > Ram2.01
> > rows: 0x0000000d 
> > columns: 0x0000000c 
> > banks: 0x00000004 
> > module data width : 0x00000048 
> > side2 banks: 0x00000004 
> > Bad SPD value
> > 
> > CPU0 got 2G modules
> > CPU1 got 4G modules
> > Side2 banks is different.
>  
> Is this with two different modules? Ram2.00 Shows a difference.
> Maybe noise on the I2C bus? Ram2.01 seems to be ok..?!?
> 
> Stefan
> 


From talbotx at comcast.net  Tue Nov 23 18:27:01 2004
From: talbotx at comcast.net (Adam Talbot)
Date: Tue Nov 23 18:27:01 2004
Subject: Compile error
Message-ID: <004801c4d1c0$1bd47150$9901a8c0@newflame>

Cool, go that error fixed, syntax error on my part. My configs is based off the digitallogic/adl855pc.  I made a new set of folders in the tree commell/lv-671, in mainboards and targets.  I put into place a new irq table for my board.  After fixing some more "simple" error's I get these two new errors.
The first one I can fix, but am not sure why it comes up. My current config file is nearly unchanged from the digitallogic/adl855pc, i have added one line "option ROM_SIZE=524288"

static.c:40: error: `mainboard_commell_lv_671_ops' undeclared here (not in a function)
static.c:40: error: initializer element is not constant
static.c:40: error: (near initialization for `dev_root.chip_ops')
static.c:24: error: storage size of `mainboard_commell_lv_671_info_0' isn't known
make[1]: *** [static.o] Error 1
make[1]: Leaving directory `/root/freebios2/targets/commell/lv-671/lv-671/normal'
make: *** [normal/linuxbios.rom] Error 1

This has an easy fix of just going through my static.c and changing it from lv-671 to lv671, easily done under vi, but im not sure it there are any golbal effects from such a mod.
After that mod the compile goes right past that point and runs into the memory error. This part is beond my sikll with C. You guy's have any ideas?

gcc -m32 -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld crt0.o
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../../i686-pc-linux-gnu/bin/ld: section .reset [00000000fffdfff0 -> 00000000fffdffff] overlaps section .rom [00000000fffd5478 -> 00000000fffe67ef]
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../../i686-pc-linux-gnu/bin/ld: section .id [00000000fffdffd5 -> 00000000fffdffef] overlaps section .rom [00000000fffd5478 -> 00000000fffe67ef]
collect2: ld returned 1 exit status
make[1]: *** [linuxbios] Error 1
make[1]: Leaving directory `/root/freebios2/targets/commell/lv-671/lv-671/normal'
make: *** [normal/linuxbios.rom] Error 1

-Adam Talbot

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20041123/9e1472e5/attachment.html>

From ebiederman at lnxi.com  Wed Nov 24 02:27:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Nov 24 02:27:00 2004
Subject: 4G 4 Rank memory module
In-Reply-To: <3174569B9743D511922F00A0C943142306BA3342@TYANWEB>
References: <3174569B9743D511922F00A0C943142306BA3342@TYANWEB>
Message-ID: <m38y8rk4ok.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> It can treat 4G as 2G modules, if I comment out physical bank check. (!=2
> get out).

Ah so it is the explicit check for <= 2 Ranks that is the immediate problem :)

This case is peculiar enough I did not add support because I could not test it.

Does your board have 4 chip selects running to the dimm socket?
If not you cannot support 4 rank dimms.

What does your struct mem_controller look like?

One partial solution would be to simply repeat the spd address
twice in the channel structure, and comment out the maximum bank check.
Of course that would fail for non quad rank dimms.

So I am not quite certain what the complete solution is.  YhLu once you describe
how your dimm sockets are wired we can figure something out.

       static const struct mem_controller cpu[] = {
                {
                        .node_id = 0,
                        .f0 = PCI_DEV(0, 0x18, 0),
                        .f1 = PCI_DEV(0, 0x18, 1),
                        .f2 = PCI_DEV(0, 0x18, 2),
                        .f3 = PCI_DEV(0, 0x18, 3),
                        .channel0 = { (0xa<<3)|0, (0xa<<3)|2, 0, 0 },
                        .channel1 = { (0xa<<3)|1, (0xa<<3)|3, 0, 0 },
                },


Eric


From ebiederman at lnxi.com  Wed Nov 24 02:33:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Nov 24 02:33:00 2004
Subject: Resource base 0x1xy for AMD K8 northbridge.
In-Reply-To: <1100811624.15287.2920.camel@exponential.lanl.gov>
References: <1100811624.15287.2920.camel@exponential.lanl.gov>
Message-ID: <m34qjfk4de.fsf@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:

> Eric,
> 
> Why you add 0x100 to the resource base register for AMDK8 Function 1, in
> find_mem|io_pair()?

As a general convention I name the resources as the address in the configuration
space.  The k8 distributes functionality across it's pci configuration space,
which makes it atypical in a number of respects.  

In this case the bridges are all in function 0, but the bars for those
bridges are actually in function 1.  Since I am reporting those resources
on function 0 I add 0x100 to indicate that those resources are really
in function 1.    Which is simple and keeps me safe from most conflicts.

It looks like I am also playing with the low address bits to distinguish
which link I am actually dealing with.

Does that make sense?

The resource->index is arbitrary but I try to keep to a convention where
looking at it you can tell which configuration register you are dealing
with.

Eric


From ebiederman at lnxi.com  Wed Nov 24 02:36:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Nov 24 02:36:01 2004
Subject: Compile error
In-Reply-To: <011601c4d105$a3ba3e30$9901a8c0@newflame>
References: <011601c4d105$a3ba3e30$9901a8c0@newflame>
Message-ID: <m3zn17ipok.fsf@maxwell.lnxi.com>

"Adam Talbot" <talbotx at comcast.net> writes:

> Any ideas on this error? What is causing theis?
> 
>  /root/freebios2/src/mainboard/commell/lv-671/auto.c -o auto.inc
> raminit.c:1369.39:
> member channel1 not present

It looks like you are trying to compile code that references a structure
member you don't have.  

Typically I boards are setup with a struct memory controller that
has channel0 and channel1 members.  But that configuration is board specific.

Eric


From ebiederman at lnxi.com  Wed Nov 24 02:39:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Nov 24 02:39:00 2004
Subject: [Etherboot-users] Direct message to com2
In-Reply-To: <3174569B9743D511922F00A0C943142306BA32F5@TYANWEB>
References: <3174569B9743D511922F00A0C943142306BA32F5@TYANWEB>
Message-ID: <m3vfbvipiz.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> It seems that mkelfImage should get the com address from commandline.
> 
> For example:
> mkelfImage --command-line="ramdisk_size=65536 root=/dev/ram0 rw console=tty0
> console=ttyS1,115200n8" --kernel=linuxkernel/bzImage_2.
> 6.9_k8.2 --ramdisk=rootfs/mydisk8_com2.gz
> --output=elf/ram0_2.5_2.6.9_k8.2_mydisk8_com2.elf
> 
> Then makeelfImage should use 0x2f8 instead of 0x3f8 in convert_params.c
> according to ttyS1.

Patches are welcome.

What probably makes the most sense long term is to export the console device
in the LinuxBIOS table so software running under LinuxBIOS can just lookup
what the console device is supposed to be.

Eric


From shahidi at engr.mun.ca  Wed Nov 24 07:41:00 2004
From: shahidi at engr.mun.ca (Reza Shahidi)
Date: Wed Nov 24 07:41:00 2004
Subject: Heterogeneous clusters with Clustermatic
Message-ID: <41A4960A.6000207@engr.mun.ca>

Hello all:

    I just wanted to see if Clustermatic supports heterogeneous 
clusters.  We have 4 identical slave nodes for the time being, but we 
may want to add some more machines later on.  This has probably been 
answered in the documentation somewhere, but I haven't been able to find 
it.  I hope I am E-mailing the correct list.

Thanks,
Reza


From rminnich at lanl.gov  Wed Nov 24 09:16:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed Nov 24 09:16:00 2004
Subject: Heterogeneous clusters with Clustermatic
In-Reply-To: <41A4960A.6000207@engr.mun.ca>
References: <41A4960A.6000207@engr.mun.ca>
Message-ID: <Pine.LNX.4.58.0411240843140.1285@linux.site>


On Wed, 24 Nov 2004, Reza Shahidi wrote:

>    I just wanted to see if Clustermatic supports heterogeneous clusters.  

no. There's no way currently to support (e.g.) mixed i386/ppc because 
of migration that bproc does. 

ron


From rminnich at lanl.gov  Wed Nov 24 10:01:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed Nov 24 10:01:01 2004
Subject: Compile error
In-Reply-To: <004801c4d1c0$1bd47150$9901a8c0@newflame>
References: <004801c4d1c0$1bd47150$9901a8c0@newflame>
Message-ID: <Pine.LNX.4.58.0411240831400.1285@linux.site>


On Tue, 23 Nov 2004, Adam Talbot wrote:

> The first one I can fix, but am not sure why it comes up. My current
> config file is nearly unchanged from the digitallogic/adl855pc, i have
> added one line "option ROM_SIZE=524288"

because the C compiler takes your name lv-761 and thinks you're trying to 
subtract 671 from lv. 
> static.c:24: error: storage size of `mainboard_commell_lv_671_info_0' isn't known


That's just another renaming exercise ...

> gcc -m32 -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld crt0.o
> /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../../i686-pc-linux-gnu/bin/ld: section .reset [00000000fffdfff0 -> 00000000fffdffff] overlaps section .rom [00000000fffd5478 -> 00000000fffe67ef]
> /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../../i686-pc-linux-gnu/bin/ld: section .id [00000000fffdffd5 -> 00000000fffdffef] overlaps section .rom [00000000fffd5478 -> 00000000fffe67ef]
> collect2: ld returned 1 exit status
> make[1]: *** [linuxbios] Error 1
> make[1]: Leaving directory `/root/freebios2/targets/commell/lv-671/lv-671/normal'
> make: *** [normal/linuxbios.rom] Error 1

turn down your MAX_LOGLEVEL to 6 or so ...

ron


From talbotx at comcast.net  Wed Nov 24 10:43:01 2004
From: talbotx at comcast.net (Adam Talbot)
Date: Wed Nov 24 10:43:01 2004
Subject: Compile error
References: <004801c4d1c0$1bd47150$9901a8c0@newflame> <Pine.LNX.4.58.0411240831400.1285@linux.site>
Message-ID: <008801c4d248$8918d200$9901a8c0@newflame>

OK, turned down my log...
I am still stuch on this memory error.  Where should i look? what files?
-Adam Talbot

----- Original Message ----- 
From: "Ronald G. Minnich" <rminnich at lanl.gov>
To: "Adam Talbot" <talbotx at comcast.net>
Cc: <linuxbios at clustermatic.org>
Sent: Wednesday, November 24, 2004 7:33 AM
Subject: Re: Compile error


>
>
> On Tue, 23 Nov 2004, Adam Talbot wrote:
>
> > The first one I can fix, but am not sure why it comes up. My current
> > config file is nearly unchanged from the digitallogic/adl855pc, i have
> > added one line "option ROM_SIZE=524288"
>
> because the C compiler takes your name lv-761 and thinks you're trying to
> subtract 671 from lv.
> > static.c:24: error: storage size of `mainboard_commell_lv_671_info_0'
isn't known
>
>
> That's just another renaming exercise ...
>
> > gcc -m32 -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld
crt0.o
> >
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../../i686-pc-linux-gnu/bin/l
d: section .reset [00000000fffdfff0 -> 00000000fffdffff] overlaps section
.rom [00000000fffd5478 -> 00000000fffe67ef]
> >
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../../i686-pc-linux-gnu/bin/l
d: section .id [00000000fffdffd5 -> 00000000fffdffef] overlaps section .rom
[00000000fffd5478 -> 00000000fffe67ef]
> > collect2: ld returned 1 exit status
> > make[1]: *** [linuxbios] Error 1
> > make[1]: Leaving directory
`/root/freebios2/targets/commell/lv-671/lv-671/normal'
> > make: *** [normal/linuxbios.rom] Error 1
>
> turn down your MAX_LOGLEVEL to 6 or so ...
>
> ron
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>




From rminnich at lanl.gov  Wed Nov 24 10:55:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed Nov 24 10:55:01 2004
Subject: Compile error
In-Reply-To: <008801c4d248$8918d200$9901a8c0@newflame>
References: <004801c4d1c0$1bd47150$9901a8c0@newflame>
 <Pine.LNX.4.58.0411240831400.1285@linux.site> <008801c4d248$8918d200$9901a8c0@newflame>
Message-ID: <Pine.LNX.4.58.0411241022400.1522@linux.site>


On Wed, 24 Nov 2004, Adam Talbot wrote:

> OK, turned down my log...
> I am still stuch on this memory error.  Where should i look? what files?

Try building digitallogic/adl855pc just to see if that goes.

ron


From linuxbios at xdr.com  Wed Nov 24 11:24:01 2004
From: linuxbios at xdr.com (Dave Ashley)
Date: Wed Nov 24 11:24:01 2004
Subject: linuxbios vs award bios on EPIA-M
Message-ID: <200411241752.iAOHq0NN020808@xdr.com>

The VIA XFree86 module for CLE266 used on the epia-m makes some
assumptions about certain of the VGA registers containing information
that would have been set by the bios. Specifically here is a code
snippet from XFree86 4.3.0:

    /* Next go on to detect amount of installed ram */
    if (pScrn->videoRam < 16384 || pScrn->videoRam > 65536) {
        bMemSize = BIOS_GetVideoMemSize(pScrn);
        if (bMemSize) {
            pScrn->videoRam = bMemSize << 6;
        }
        else {
            VGAOUT8(0x3C4, 0x39);
            bMemSize = VGAIN8(0x3c5);
            if (bMemSize > 16 && bMemSize <= 128) {
                pScrn->videoRam = (bMemSize + 1) << 9;
            }
            else if (bMemSize > 0 && bMemSize < 31){
                pScrn->videoRam = bMemSize << 12;
            }
            else {
                DEBUG(xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
                "bMemSize = %d\nGet Video Memory Size by default.\n", bMemSize));
                pScrn->videoRam = VIAGetMemSize();
            }
        }
    }


And here is from XFree86 4.4.0:

    /* detect amount of installed ram */
    if (pScrn->videoRam < 16384 || pScrn->videoRam > 65536) {
	if(pVia->Chipset == VIA_CLE266)
	    bMemSize = hwp->readSeq(hwp, 0x34);
	else
	    bMemSize = hwp->readSeq(hwp, 0x39);

	if (bMemSize > 16 && bMemSize <= 128)
	    pScrn->videoRam = (bMemSize + 1) << 9;
	else if (bMemSize > 0 && bMemSize < 31)
	    pScrn->videoRam = bMemSize << 12;
	else {
	    xf86DrvMsg(pScrn->scrnIndex, X_WARNING, "Memory size detection failed: using 16MB\n");
	    pScrn->videoRam = 16 << 10;	/* Assume the base 16Mb */
	}
    }



So the older version tries to query the BIOS first. The newer version
doesn't even bother with the bios and assumes the VGA Seq registers
0x39 or 0x34 contain the memory size.

3c5.34 is Scratch Pad Register 3
3c5.39 is BIOS reserved register 0

XF4.4.0 seems to abstract how the VGA sequence registers are accessed.
Even the logic seems strange, XF4.3.0 assumes seq 0x39 has the info,
but XF4.4.0 assumes seq 0x39 has the info.

linuxbios isn't initializing either as far as I know. To handle this
safely it would seem it must set the ram size in both seq registers.

This seems really weird, using vga seq scratch registers to convey information
from the BIOS to XFree86. Is this common or something specific to VIA?

-Dave


From talbotx at comcast.net  Wed Nov 24 11:24:12 2004
From: talbotx at comcast.net (Adam Talbot)
Date: Wed Nov 24 11:24:12 2004
Subject: Compile error
References: <004801c4d1c0$1bd47150$9901a8c0@newflame> <Pine.LNX.4.58.0411240831400.1285@linux.site> <008801c4d248$8918d200$9901a8c0@newflame> <Pine.LNX.4.58.0411241022400.1522@linux.site>
Message-ID: <009a01c4d24e$54af4070$9901a8c0@newflame>

Same error when I compile the digitallogic/adl855pc... Well the good news is
its not me :-)
Now, what is causing this, I am more then willing to try and help fix this
problem.
----- Original Message ----- 
From: "Ronald G. Minnich" <rminnich at lanl.gov>
To: "Adam Talbot" <talbotx at comcast.net>
Cc: <linuxbios at clustermatic.org>
Sent: Wednesday, November 24, 2004 9:23 AM
Subject: Re: Compile error


>
>
> On Wed, 24 Nov 2004, Adam Talbot wrote:
>
> > OK, turned down my log...
> > I am still stuch on this memory error.  Where should i look? what files?
>
> Try building digitallogic/adl855pc just to see if that goes.
>
> ron
>




From ollie at lanl.gov  Wed Nov 24 11:39:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Wed Nov 24 11:39:00 2004
Subject: Resource base 0x1xy for AMD K8 northbridge.
In-Reply-To: <m34qjfk4de.fsf@maxwell.lnxi.com>
References: <1100811624.15287.2920.camel@exponential.lanl.gov>
	 <m34qjfk4de.fsf@maxwell.lnxi.com>
Message-ID: <1101317364.3086.8.camel@exponential.lanl.gov>

On Wed, 2004-11-24 at 02:01, Eric W. Biederman wrote:
> Li-Ta Lo <ollie at lanl.gov> writes:
> 
> > Eric,
> > 
> > Why you add 0x100 to the resource base register for AMDK8 Function 1, in
> > find_mem|io_pair()?
> 
> As a general convention I name the resources as the address in the configuration
> space.  The k8 distributes functionality across it's pci configuration space,
> which makes it atypical in a number of respects.  
> 
> In this case the bridges are all in function 0, but the bars for those
> bridges are actually in function 1.  Since I am reporting those resources
> on function 0 I add 0x100 to indicate that those resources are really
> in function 1.    Which is simple and keeps me safe from most conflicts.
> 
> It looks like I am also playing with the low address bits to distinguish
> which link I am actually dealing with.
> 
> Does that make sense?
> 

It's fine but please add a comment in the .c or .h file. It is confusing
since the 0x100 and low order bit value in pretty artifitial. Nobody is
going to understant the code by just reading the AMD data sheet.

Ollie

> The resource->index is arbitrary but I try to keep to a convention where
> looking at it you can tell which configuration register you are dealing
> with.
> 
> Eric
> 



From YhLu at tyan.com  Wed Nov 24 12:10:01 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Nov 24 12:10:01 2004
Subject: 4G 4 Rank memory module
Message-ID: <3174569B9743D511922F00A0C943142306BA338F@TYANWEB>

Eric,

Our MB all CS are connected. 

DIMM0 and DIMM1 are using 0, 1, 4, 5.
DIMM2 and DIMM3 are using 2, 3, 6, 7.

Then need to change to

static const struct mem_controller cpu[] = {
  {
                        .node_id = 0,
                        .f0 = PCI_DEV(0, 0x18, 0),
                        .f1 = PCI_DEV(0, 0x18, 1),
                        .f2 = PCI_DEV(0, 0x18, 2),
                        .f3 = PCI_DEV(0, 0x18, 3),
         .channel0 = { (0xa<<3)|0, (0xa<<3)|2, (0xa<<3)|0, (0xa<<3)|2, },
         .channel1 = { (0xa<<3)|1, (0xa<<3)|3, (0xa<<3)|1, (0xa<<3)|3, },
                },

Regards

YH

-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Wednesday, November 24, 2004 12:55 AM
To: YhLu
Cc: Stefan Reinauer; 'LinuxBIOS'
Subject: Re: 4G 4 Rank memory module

YhLu <YhLu at tyan.com> writes:

> It can treat 4G as 2G modules, if I comment out physical bank check. (!=2
> get out).

Ah so it is the explicit check for <= 2 Ranks that is the immediate problem
:)

This case is peculiar enough I did not add support because I could not test
it.

Does your board have 4 chip selects running to the dimm socket?
If not you cannot support 4 rank dimms.

What does your struct mem_controller look like?

One partial solution would be to simply repeat the spd address
twice in the channel structure, and comment out the maximum bank check.
Of course that would fail for non quad rank dimms.

So I am not quite certain what the complete solution is.  YhLu once you
describe
how your dimm sockets are wired we can figure something out.

       static const struct mem_controller cpu[] = {
                {
                        .node_id = 0,
                        .f0 = PCI_DEV(0, 0x18, 0),
                        .f1 = PCI_DEV(0, 0x18, 1),
                        .f2 = PCI_DEV(0, 0x18, 2),
                        .f3 = PCI_DEV(0, 0x18, 3),
                        .channel0 = { (0xa<<3)|0, (0xa<<3)|2, 0, 0 },
                        .channel1 = { (0xa<<3)|1, (0xa<<3)|3, 0, 0 },
                },


Eric


From rminnich at lanl.gov  Wed Nov 24 13:44:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed Nov 24 13:44:00 2004
Subject: Compile error
In-Reply-To: <009a01c4d24e$54af4070$9901a8c0@newflame>
References: <004801c4d1c0$1bd47150$9901a8c0@newflame>
 <Pine.LNX.4.58.0411240831400.1285@linux.site> <008801c4d248$8918d200$9901a8c0@newflame>
 <Pine.LNX.4.58.0411241022400.1522@linux.site> <009a01c4d24e$54af4070$9901a8c0@newflame>
Message-ID: <Pine.LNX.4.58.0411241311560.1831@linux.site>


On Wed, 24 Nov 2004, Adam Talbot wrote:

> Same error when I compile the digitallogic/adl855pc... Well the good news is
> its not me :-)

well, it means I need to commit my latest stuff. OOPS.

ron


From rminnich at lanl.gov  Wed Nov 24 13:59:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed Nov 24 13:59:00 2004
Subject: linuxbios vs award bios on EPIA-M [PMX:#]
In-Reply-To: <200411241752.iAOHq0NN020808@xdr.com>
References: <200411241752.iAOHq0NN020808@xdr.com>
Message-ID: <Pine.LNX.4.58.0411241323410.1831@linux.site>


On Wed, 24 Nov 2004, Dave Ashley wrote:

> 3c5.34 is Scratch Pad Register 3
> 3c5.39 is BIOS reserved register 0
> 

> linuxbios isn't initializing either as far as I know. To handle this
> safely it would seem it must set the ram size in both seq registers.
> 
> This seems really weird, using vga seq scratch registers to convey information
> from the BIOS to XFree86. Is this common or something specific to VIA?

it's common. I think it would be easy to have the northbridge code set it 
up, we did something like this years ago on the sis 630.

look at the v1 northsouth code for the 630 and you'll see it.
ron


From YhLu at tyan.com  Wed Nov 24 14:31:02 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Nov 24 14:31:02 2004
Subject: 4G 4 Rank memory module
Message-ID: <3174569B9743D511922F00A0C943142306BA33AA@TYANWEB>

Repeat the i2c address two times make the memory modules fail. At that case
some thing being done twice...cause that...

YH

-----Original Message-----
From: YhLu 
Sent: Wednesday, November 24, 2004 10:44 AM
To: ebiederman at lnxi.com
Cc: Stefan Reinauer; 'LinuxBIOS'
Subject: RE: 4G 4 Rank memory module

Eric,

Our MB all CS are connected. 

DIMM0 and DIMM1 are using 0, 1, 4, 5.
DIMM2 and DIMM3 are using 2, 3, 6, 7.

Then need to change to

static const struct mem_controller cpu[] = {
  {
                        .node_id = 0,
                        .f0 = PCI_DEV(0, 0x18, 0),
                        .f1 = PCI_DEV(0, 0x18, 1),
                        .f2 = PCI_DEV(0, 0x18, 2),
                        .f3 = PCI_DEV(0, 0x18, 3),
         .channel0 = { (0xa<<3)|0, (0xa<<3)|2, (0xa<<3)|0, (0xa<<3)|2, },
         .channel1 = { (0xa<<3)|1, (0xa<<3)|3, (0xa<<3)|1, (0xa<<3)|3, },
                },

Regards

YH

-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Wednesday, November 24, 2004 12:55 AM
To: YhLu
Cc: Stefan Reinauer; 'LinuxBIOS'
Subject: Re: 4G 4 Rank memory module

YhLu <YhLu at tyan.com> writes:

> It can treat 4G as 2G modules, if I comment out physical bank check. (!=2
> get out).

Ah so it is the explicit check for <= 2 Ranks that is the immediate problem
:)

This case is peculiar enough I did not add support because I could not test
it.

Does your board have 4 chip selects running to the dimm socket?
If not you cannot support 4 rank dimms.

What does your struct mem_controller look like?

One partial solution would be to simply repeat the spd address
twice in the channel structure, and comment out the maximum bank check.
Of course that would fail for non quad rank dimms.

So I am not quite certain what the complete solution is.  YhLu once you
describe
how your dimm sockets are wired we can figure something out.

       static const struct mem_controller cpu[] = {
                {
                        .node_id = 0,
                        .f0 = PCI_DEV(0, 0x18, 0),
                        .f1 = PCI_DEV(0, 0x18, 1),
                        .f2 = PCI_DEV(0, 0x18, 2),
                        .f3 = PCI_DEV(0, 0x18, 3),
                        .channel0 = { (0xa<<3)|0, (0xa<<3)|2, 0, 0 },
                        .channel1 = { (0xa<<3)|1, (0xa<<3)|3, 0, 0 },
                },


Eric
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From gwatson at lanl.gov  Wed Nov 24 15:01:01 2004
From: gwatson at lanl.gov (Greg Watson)
Date: Wed Nov 24 15:01:01 2004
Subject: pnp_enable_resource not being called
Message-ID: <D7BB98BA-3E5F-11D9-956D-000D932F4B4A@lanl.gov>

The sandpoint has the following structure:

Northbridge MPC107 --> Southbridge W83C553 --> Superio PC97307

The config file looks like:

chip northbridge/motorola/mpc107
         device pci_domain 0 on
                 device pci 0.0 on end
                 device pci b.0 on
                         chip southbridge/winbond/w83c553
                                 chip superio/NSC/pc97307
                                         device pnp 15c.0 on end # 
Kyeboard
                                         device pnp 15c.1 on end # Mouse
                                         device pnp 15c.2 on end # 
Real-time Cloc
k
                                         device pnp 15c.3 on end # Floppy
                                         device pnp 15c.4 on end # 
Parallel port
                                         device pnp 15c.5 on end # com2
                                         device pnp 15c.6 on end # com1
                                         device pnp 15c.7 on end # gpio
                                         device pnp 15c.8 on end # Power 
manageme
nt
                                 end
                         end
                 end # pci to isa bridge
                 device pci b.1 on end # pci ide controller
         end
         device cpu_bus 0 on
                 chip cpu/ppc/mpc74xx
                         device cpu 0 on end
                 end
         end
end

The dev_enumerate() code is calling the PNP enable routines and the 
dev_initialize() code is calling the PNP init routine. However the 
dev_enable() code never calls the PNP enable_resource routine, which 
means the the PNP devices are never actually enabled.

The enable_dev routine for the superio device calls:

         pnp_enable_devices(dev, &ops,
                 sizeof(pnp_dev_info)/sizeof(pnp_dev_info[0]), 
pnp_dev_info);

where ops is defined as:

static struct device_operations ops = {
         .read_resources   = pnp_read_resources,
         .set_resources    = pnp_set_resources,
         .enable_resources = pnp_enable_resources,
         .enable           = pnp_enable,
         .init             = init,
};

Any ideas why this is not working? Is there something else that needs 
to happen?

Greg



From talbotx at comcast.net  Wed Nov 24 16:07:01 2004
From: talbotx at comcast.net (Adam Talbot)
Date: Wed Nov 24 16:07:01 2004
Subject: Compile error
References: <004801c4d1c0$1bd47150$9901a8c0@newflame> <Pine.LNX.4.58.0411240831400.1285@linux.site> <008801c4d248$8918d200$9901a8c0@newflame> <Pine.LNX.4.58.0411241022400.1522@linux.site> <009a01c4d24e$54af4070$9901a8c0@newflame> <Pine.LNX.4.58.0411241311560.1831@linux.site>
Message-ID: <00c201c4d275$d7da6fc0$9901a8c0@newflame>

Please let me no when the update is commited...

----- Original Message ----- 
From: "Ronald G. Minnich" <rminnich at lanl.gov>
To: "Adam Talbot" <talbotx at comcast.net>
Cc: <linuxbios at clustermatic.org>
Sent: Wednesday, November 24, 2004 12:12 PM
Subject: Re: Compile error


>
>
> On Wed, 24 Nov 2004, Adam Talbot wrote:
>
> > Same error when I compile the digitallogic/adl855pc... Well the good
news is
> > its not me :-)
>
> well, it means I need to commit my latest stuff. OOPS.
>
> ron
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>




From YhLu at tyan.com  Wed Nov 24 16:12:01 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Nov 24 16:12:01 2004
Subject: pnp_enable_resource not being called
Message-ID: <3174569B9743D511922F00A0C943142306BA33BC@TYANWEB>

In the AMD8111_lpc.c

static void amd8111_lpc_enable_resources(device_t dev)
{
        pci_dev_enable_resources(dev);

        enable_childrens_resources(dev);
}

static struct device_operations lpc_ops  = {
        .read_resources   = amd8111_lpc_read_resources,
        .set_resources    = pci_dev_set_resources,
        .enable_resources = amd8111_lpc_enable_resources,
        .init             = lpc_init,
        .scan_bus         = scan_static_bus,
//      .enable           = amd8111_enable,
        .ops_pci          = &lops_pci,
};

So I guess you need to add the device driver for the lpc in SB.

Then the scan_static_bus and enable_childrens_resources(dev) will be called.

Regards

YH

-----Original Message-----
From: Greg Watson [mailto:gwatson at lanl.gov] 
Sent: Wednesday, November 24, 2004 1:29 PM
To: 'LinuxBIOS'
Subject: pnp_enable_resource not being called

The sandpoint has the following structure:

Northbridge MPC107 --> Southbridge W83C553 --> Superio PC97307

The config file looks like:

chip northbridge/motorola/mpc107
         device pci_domain 0 on
                 device pci 0.0 on end
                 device pci b.0 on
                         chip southbridge/winbond/w83c553
                                 chip superio/NSC/pc97307
                                         device pnp 15c.0 on end # 
Kyeboard
                                         device pnp 15c.1 on end # Mouse
                                         device pnp 15c.2 on end # 
Real-time Cloc
k
                                         device pnp 15c.3 on end # Floppy
                                         device pnp 15c.4 on end # 
Parallel port
                                         device pnp 15c.5 on end # com2
                                         device pnp 15c.6 on end # com1
                                         device pnp 15c.7 on end # gpio
                                         device pnp 15c.8 on end # Power 
manageme
nt
                                 end
                         end
                 end # pci to isa bridge
                 device pci b.1 on end # pci ide controller
         end
         device cpu_bus 0 on
                 chip cpu/ppc/mpc74xx
                         device cpu 0 on end
                 end
         end
end

The dev_enumerate() code is calling the PNP enable routines and the 
dev_initialize() code is calling the PNP init routine. However the 
dev_enable() code never calls the PNP enable_resource routine, which 
means the the PNP devices are never actually enabled.

The enable_dev routine for the superio device calls:

         pnp_enable_devices(dev, &ops,
                 sizeof(pnp_dev_info)/sizeof(pnp_dev_info[0]), 
pnp_dev_info);

where ops is defined as:

static struct device_operations ops = {
         .read_resources   = pnp_read_resources,
         .set_resources    = pnp_set_resources,
         .enable_resources = pnp_enable_resources,
         .enable           = pnp_enable,
         .init             = init,
};

Any ideas why this is not working? Is there something else that needs 
to happen?

Greg

_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From ebiederman at lnxi.com  Thu Nov 25 02:00:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Nov 25 02:00:00 2004
Subject: Apologies for ignored email...
Message-ID: <m3653u8h9g.fsf@maxwell.lnxi.com>

I just discovered that the my local system administrators had applied a spam filter
to my incoming mail that seems to have has a 2:1 false positive rate when identifying
spam.  Especially picking on email that was short to the point, and important or interesting.

I think I have things under control, but I will have to wait until next week when everyone
gets back work to tell for certain.

So my apologies for not catching this sooner.  It resulted in me ignore several messages 
I should have because I never received them.

Eric





From ebiederman at lnxi.com  Thu Nov 25 02:13:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Nov 25 02:13:00 2004
Subject: Invalidating TLB, cache
In-Reply-To: <1099433022.3373.36.camel@exponential.lanl.gov>
References: <1099433022.3373.36.camel@exponential.lanl.gov>
Message-ID: <m3653u5ni1.fsf@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:

> Eric,
> 
> What was the conclusion of invalidating the cache and TLB ?
> If found that
> 
>         xorl    %eax, %eax
>         movl    %eax, %cr3    /* Invalidate TLB*/
> 
> still exists in the current CVS.

Cache invalidates are actively harmful, as they can loose data that has
not been written from the cache and they take seconds on an Opteron
to execute.

Currently TLB invalidates don't have any negative side effects and
seem harmless.  Since TLB do not cache writes I can't think of a case
where they would cause incorrect behavior.    If they start running
slow on some we can revisit the issue.

Eric


From ebiederman at lnxi.com  Thu Nov 25 02:22:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Nov 25 02:22:01 2004
Subject: Link and Links again
In-Reply-To: <1100723692.15287.1434.camel@exponential.lanl.gov>
References: <1100723692.15287.1434.camel@exponential.lanl.gov>
Message-ID: <m3is7u1fdp.fsf@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:

> Eric,
> 
> >From my understanding, the device.link for bridge device does not 
> include the up stream bus.
Correct it only includes the device itself.
device.link.dev == device

> The up stream bus is the device.bus field.

Correct.

> So for 'normal' PCI bridges, with one up stream and one down stream
> buses, its device.links = 1. Am I correct ?

Yes.

Eric


From ginlin at nexcom.com.tw  Thu Nov 25 06:11:00 2004
From: ginlin at nexcom.com.tw (Gin)
Date: Thu Nov 25 06:11:00 2004
Subject: boot linux from an ide
In-Reply-To: <Pine.LNX.4.58.0410272051480.5895@linux.site>
Message-ID: <000001c4d2eb$e4af0780$4f01060a@nexcom.com.tw>

I use FILO as the payload to boot from a Hard Disk, which has a
installed linux on it. I noticed if I enabled the ide stream. It tries
to read the ELF header from my IDE drive. But I thought the FILO payload
should be the one to load the image from the IDE drive. When does it
come in and play the role?
Anyone can explain the flow of booting if I try to load the INSTALLED
linux from a IDE drive. 


Gin



From ginlin at mail.nexcom.com.tw  Thu Nov 25 06:41:01 2004
From: ginlin at mail.nexcom.com.tw (Gin Lin)
Date: Thu Nov 25 06:41:01 2004
Subject: boot from an ide
Message-ID: <20041125130607.M32179@mail.nexcom.com.tw>

I use FILO as the payload to boot from a Hard Disk, which has a installed 
linux on it. I noticed if I enabled the ide stream. It tries to read the ELF 
header from my IDE drive. But I thought the FILO payload should be the one 
to load the image from the IDE drive. When does it come in and play the 
role? Anyone can explain the flow of booting if I try to load the INSTALLED 
linux from a IDE drive. 


Gin



From gwatson at lanl.gov  Thu Nov 25 09:15:00 2004
From: gwatson at lanl.gov (Greg Watson)
Date: Thu Nov 25 09:15:00 2004
Subject: boot linux from an ide
In-Reply-To: <000001c4d2eb$e4af0780$4f01060a@nexcom.com.tw>
References: <000001c4d2eb$e4af0780$4f01060a@nexcom.com.tw>
Message-ID: <9E6F7E98-3EF8-11D9-B5FA-000D932F4B4A@lanl.gov>

If FILO is a payload in flash, then you need to set CONFIG_ROM_STREAM=1 
and CONFIG_ROM_STREAM_START to the address you want to start looking 
for the payload ELF header (usually just after the LinuxBIOS image). 
CONFIG_IDE_STREAM is used to load a payload (such as FILO) from an 
attached IDE device. This is useful if the flash is not large enough to 
hold LinuxBIOS+payload, but is probably not what you are looking for. 
Sorry for the confusion.

Greg

On Nov 25, 2004, at 5:40 AM, Gin wrote:

> I use FILO as the payload to boot from a Hard Disk, which has a
> installed linux on it. I noticed if I enabled the ide stream. It tries
> to read the ELF header from my IDE drive. But I thought the FILO 
> payload
> should be the one to load the image from the IDE drive. When does it
> come in and play the role?
> Anyone can explain the flow of booting if I try to load the INSTALLED
> linux from a IDE drive.
>
>
> Gin
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>



From stepan at openbios.org  Thu Nov 25 16:39:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Thu Nov 25 16:39:00 2004
Subject: What's next?
Message-ID: <20041125230708.GA5619@openbios.org>

Hi,

I am still having problems scanning the noncoherent chains connected to
CPU1-3 of the motherboard I am working to support. I could temporarily
work around this issue by setting the Config Base and Limit registers of
those links to 0. Otherwise collapsing the chain when setting up that
CPU fails. I set the Config Base and Limit registers like this:
        PCI_ADDR(0, 0x18, 1, 0xE0), 0x0000FC88, 0x04000103,
        PCI_ADDR(0, 0x18, 1, 0xE4), 0x0000FC88, 0xff050213,
since there's bus 0-4 on cpu0 when i don't scan cpu1

Looking at incoherent_ht.c there are two functions that are very
similar:

static int ht_setup_chain(device_t udev, unsigned upos)
static int ht_setup_chains(const struct ht_chain *ht_c, int ht_c_num)

the first one warns:
#warning "FIXME handle multiple chains!"

Should we not drop ht_setup_chain in favour of ht_setup_chains?

Also later on it dies apparently in amdk8_scan_chains in
northbridge/amd/amdk8/northbridge.c.

Something is severely wrong with my link setup, but I double checked
where the coherent and non coherent links hang off of..

Pointers?

Stefan.

LinuxBIOS-1.1.7.0-fallback Thu Nov 25 21:58:33 CET 2004 starting...
setting up resource map....done.
04 nodes initialized.
udev=(0,0x18,0) 0xb4=00ff0000bus=00 id =74501022
bus=00 id =74601022
udev=(0,0x18,0) 0x94=00000000bus=00 id =74501022
bus=00 id =74601022
udev=(0,0x18,0) 0x94=00000000bus=00 id =74501022
bus=00 id =74601022
udev=(0,0x18,0) 0x94=00000000bus=00 id =74501022
bus=00 id =74601022
PCI: 00:01.00
PCI: 00:01.01
PCI: 00:02.00
PCI: 00:02.01
PCI: 00:03.00
PCI: 00:04.00
PCI: 00:04.01
PCI: 00:04.02
PCI: 00:04.03
PCI: 00:04.05
PCI: 00:04.06
PCI: 00:18.00
PCI: 00:18.01
PCI: 00:18.02
PCI: 00:18.03
PCI: 00:19.00
PCI: 00:19.01
PCI: 00:19.02
PCI: 00:19.03
PCI: 00:1a.00
PCI: 00:1a.01
PCI: 00:1a.02
PCI: 00:1a.03
PCI: 00:1b.00
PCI: 00:1b.01
PCI: 00:1b.02
PCI: 00:1b.03
ht reset -
Ram1.00
Ram1.01
Ram1.02
Ram1.03
Ram2.00
Ram2.01
Ram2.02
Ram2.03
Ram3
Initializing memory:  done
Initializing memory:  done
Initializing memory:  done
Initializing memory:  done
Clearing initial memory region:  done
Ram4
Copying LinuxBIOS to ram.
Jumping to LinuxBIOS.
LinuxBIOS-1.1.7.0-fallback Thu Nov 25 21:58:33 CET 2004 booting...
Enumerating buses...
PCI_DOMAIN: 0000 enabled
APIC_CLUSTER: 0 enabled
PCI: pci_scan_bus for bus 0
PCI: 00:18.0 [1022/1100] bus ops
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] ops
PCI: 00:18.3 [1022/1103] enabled
PCI: 00:19.0 [1022/1100] bus ops
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] ops
PCI: 00:19.3 [1022/1103] enabled
PCI: 00:1a.0 [1022/1100] bus ops
PCI: 00:1a.0 [1022/1100] enabled
PCI: 00:1a.1 [1022/1101] enabled
PCI: 00:1a.2 [1022/1102] enabled
PCI: 00:1a.3 [1022/1103] ops
PCI: 00:1a.3 [1022/1103] enabled
PCI: 00:1b.0 [1022/1100] bus ops
PCI: 00:1b.0 [1022/1100] enabled
PCI: 00:1b.1 [1022/1101] enabled
PCI: 00:1b.2 [1022/1102] enabled
PCI: 00:1b.3 [1022/1103] ops
PCI: 00:1b.3 [1022/1103] enabled
PCI: 01:01.0 [1022/7450] enabled next_unitid: 0003
PCI: 01:03.0 [1022/7460] enabled next_unitid: 0007
HyperT reset not needed
PCI: pci_scan_bus for bus 1
PCI: 01:01.0 [1022/7450] bus ops
PCI: 01:01.0 [1022/7450] enabled
PCI: 01:01.1 [1022/7451] ops
PCI: 01:01.1 [1022/7451] enabled
PCI: 01:02.0 [1022/7450] bus ops
PCI: 01:02.0 [1022/7450] enabled
PCI: 01:02.1 [1022/7451] ops
PCI: 01:02.1 [1022/7451] enabled
PCI: 01:03.0 [1022/7460] bus ops
PCI: 01:03.0 [1022/7460] enabled
PCI: 01:04.0 [1022/7468] bus ops
PCI: 01:04.0 [1022/7468] enabled
PCI: 01:04.1 [1022/7469] ops
PCI: 01:04.1 [1022/7469] enabled
PCI: 01:04.2 [1022/746a] bus ops
PCI: 01:04.2 [1022/746a] enabled
PCI: 01:04.3 [1022/746b] bus ops
PCI: 01:04.3 [1022/746b] enabled
PCI: 01:04.5 No device operations
PCI: 01:04.6 [1022/746e] enabled
PCI: pci_scan_bus for bus 2
PCI: pci_scan_bus returning with max=02
PCI: pci_scan_bus for bus 3
PCI: pci_scan_bus returning with max=03
PCI: pci_scan_bus for bus 4
PCI: 04:00.0 [1022/7464] enabled
PCI: 04:00.1 [1022/7464] enabled
PCI: 04:00.2 No device operations
PCI: 04:01.0 No device operations
PCI: 04:04.0 [1002/4752] enabled
PCI: 04:05.0 [8086/1209] enabled
PCI: pci_scan_bus returning with max=04
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
I2C: 70 enabled
I2C: 50 enabled
I2C: 51 enabled
I2C: 52 enabled
I2C: 53 enabled
I2C: 54 enabled
I2C: 55 enabled
I2C: 56 enabled
I2C: 57 enabled
PCI: pci_scan_bus returning with max=04





From yhlu at tyan.com  Thu Nov 25 22:45:01 2004
From: yhlu at tyan.com (Yinghai Lu)
Date: Thu Nov 25 22:45:01 2004
Subject: What's next?
In-Reply-To: <20041125230708.GA5619@openbios.org>
Message-ID: <200411260344.iAQ3iBL11308@nwn.definitive.org>

What is your HT topology?

Is there any cross link between (CPU0 and CPU2) or (CPU1 and CPU2)....

You may try to disable i2c stuff in the amd8111 dir.

The code works well with S4882 and S4880.

YH

-----Original Message-----
From: linuxbios-admin at clustermatic.org
[mailto:linuxbios-admin at clustermatic.org] On Behalf Of Stefan Reinauer
Sent: Thursday, November 25, 2004 3:07 PM
To: linuxbios at clustermatic.org
Subject: What's next?

Hi,

I am still having problems scanning the noncoherent chains connected to
CPU1-3 of the motherboard I am working to support. I could temporarily
work around this issue by setting the Config Base and Limit registers of
those links to 0. Otherwise collapsing the chain when setting up that
CPU fails. I set the Config Base and Limit registers like this:
        PCI_ADDR(0, 0x18, 1, 0xE0), 0x0000FC88, 0x04000103,
        PCI_ADDR(0, 0x18, 1, 0xE4), 0x0000FC88, 0xff050213,
since there's bus 0-4 on cpu0 when i don't scan cpu1

Looking at incoherent_ht.c there are two functions that are very
similar:

static int ht_setup_chain(device_t udev, unsigned upos)
static int ht_setup_chains(const struct ht_chain *ht_c, int ht_c_num)

the first one warns:
#warning "FIXME handle multiple chains!"

Should we not drop ht_setup_chain in favour of ht_setup_chains?

Also later on it dies apparently in amdk8_scan_chains in
northbridge/amd/amdk8/northbridge.c.

Something is severely wrong with my link setup, but I double checked
where the coherent and non coherent links hang off of..

Pointers?

Stefan.

LinuxBIOS-1.1.7.0-fallback Thu Nov 25 21:58:33 CET 2004 starting...
setting up resource map....done.
04 nodes initialized.
udev=(0,0x18,0) 0xb4=00ff0000bus=00 id =74501022
bus=00 id =74601022
udev=(0,0x18,0) 0x94=00000000bus=00 id =74501022
bus=00 id =74601022
udev=(0,0x18,0) 0x94=00000000bus=00 id =74501022
bus=00 id =74601022
udev=(0,0x18,0) 0x94=00000000bus=00 id =74501022
bus=00 id =74601022
PCI: 00:01.00
PCI: 00:01.01
PCI: 00:02.00
PCI: 00:02.01
PCI: 00:03.00
PCI: 00:04.00
PCI: 00:04.01
PCI: 00:04.02
PCI: 00:04.03
PCI: 00:04.05
PCI: 00:04.06
PCI: 00:18.00
PCI: 00:18.01
PCI: 00:18.02
PCI: 00:18.03
PCI: 00:19.00
PCI: 00:19.01
PCI: 00:19.02
PCI: 00:19.03
PCI: 00:1a.00
PCI: 00:1a.01
PCI: 00:1a.02
PCI: 00:1a.03
PCI: 00:1b.00
PCI: 00:1b.01
PCI: 00:1b.02
PCI: 00:1b.03
ht reset -
Ram1.00
Ram1.01
Ram1.02
Ram1.03
Ram2.00
Ram2.01
Ram2.02
Ram2.03
Ram3
Initializing memory:  done
Initializing memory:  done
Initializing memory:  done
Initializing memory:  done
Clearing initial memory region:  done
Ram4
Copying LinuxBIOS to ram.
Jumping to LinuxBIOS.
LinuxBIOS-1.1.7.0-fallback Thu Nov 25 21:58:33 CET 2004 booting...
Enumerating buses...
PCI_DOMAIN: 0000 enabled
APIC_CLUSTER: 0 enabled
PCI: pci_scan_bus for bus 0
PCI: 00:18.0 [1022/1100] bus ops
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] ops
PCI: 00:18.3 [1022/1103] enabled
PCI: 00:19.0 [1022/1100] bus ops
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] ops
PCI: 00:19.3 [1022/1103] enabled
PCI: 00:1a.0 [1022/1100] bus ops
PCI: 00:1a.0 [1022/1100] enabled
PCI: 00:1a.1 [1022/1101] enabled
PCI: 00:1a.2 [1022/1102] enabled
PCI: 00:1a.3 [1022/1103] ops
PCI: 00:1a.3 [1022/1103] enabled
PCI: 00:1b.0 [1022/1100] bus ops
PCI: 00:1b.0 [1022/1100] enabled
PCI: 00:1b.1 [1022/1101] enabled
PCI: 00:1b.2 [1022/1102] enabled
PCI: 00:1b.3 [1022/1103] ops
PCI: 00:1b.3 [1022/1103] enabled
PCI: 01:01.0 [1022/7450] enabled next_unitid: 0003
PCI: 01:03.0 [1022/7460] enabled next_unitid: 0007
HyperT reset not needed
PCI: pci_scan_bus for bus 1
PCI: 01:01.0 [1022/7450] bus ops
PCI: 01:01.0 [1022/7450] enabled
PCI: 01:01.1 [1022/7451] ops
PCI: 01:01.1 [1022/7451] enabled
PCI: 01:02.0 [1022/7450] bus ops
PCI: 01:02.0 [1022/7450] enabled
PCI: 01:02.1 [1022/7451] ops
PCI: 01:02.1 [1022/7451] enabled
PCI: 01:03.0 [1022/7460] bus ops
PCI: 01:03.0 [1022/7460] enabled
PCI: 01:04.0 [1022/7468] bus ops
PCI: 01:04.0 [1022/7468] enabled
PCI: 01:04.1 [1022/7469] ops
PCI: 01:04.1 [1022/7469] enabled
PCI: 01:04.2 [1022/746a] bus ops
PCI: 01:04.2 [1022/746a] enabled
PCI: 01:04.3 [1022/746b] bus ops
PCI: 01:04.3 [1022/746b] enabled
PCI: 01:04.5 No device operations
PCI: 01:04.6 [1022/746e] enabled
PCI: pci_scan_bus for bus 2
PCI: pci_scan_bus returning with max=02
PCI: pci_scan_bus for bus 3
PCI: pci_scan_bus returning with max=03
PCI: pci_scan_bus for bus 4
PCI: 04:00.0 [1022/7464] enabled
PCI: 04:00.1 [1022/7464] enabled
PCI: 04:00.2 No device operations
PCI: 04:01.0 No device operations
PCI: 04:04.0 [1002/4752] enabled
PCI: 04:05.0 [8086/1209] enabled
PCI: pci_scan_bus returning with max=04
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
I2C: 70 enabled
I2C: 50 enabled
I2C: 51 enabled
I2C: 52 enabled
I2C: 53 enabled
I2C: 54 enabled
I2C: 55 enabled
I2C: 56 enabled
I2C: 57 enabled
PCI: pci_scan_bus returning with max=04



_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios



From ginlin at nexcom.com.tw  Fri Nov 26 01:09:01 2004
From: ginlin at nexcom.com.tw (Gin)
Date: Fri Nov 26 01:09:01 2004
Subject: could not find a bounce buffer
In-Reply-To: <9E6F7E98-3EF8-11D9-B5FA-000D932F4B4A@lanl.gov>
Message-ID: <000001c4d38a$dbc33ed0$4f01060a@nexcom.com.tw>

Yes, I think I need to set CONFIG_ROM_STREAM=1 in order to have it boot
from my FILO payload which then will go load the image in a IDE drive.
Thanks.

I got an error when it ties to get_bounce_buffer in elfboot, Don't know
if you have the same problem. I dumped out the mem entries info. Looks
like the 2 mem entries are all LB_MEM_TABLE(ram config tables to be kept
in). So there is no LB_MEM_RAM, (where everyone could use) to allocate
the bounce buffer from. 

Any idea?


=======================================================
Wrote the mp table end at: 00000020 - 000001f4
Wrote linuxbios table at: 00000500 - 00000be4  checksum 18e1

lb_size=0x20000

mem_entries=2
mem entry1: type=0x10, start=0, size=0xc4c
mem entry2: type=0x10, start=0xf0000, size=0x400

Could not find a bounce buffer...
Cannot Load ELF Image
-===========================================================
-----Original Message-----
From: Greg Watson [mailto:gwatson at lanl.gov] 
Sent: Thursday, November 25, 2004 11:43 PM
To: Gin
Cc: linuxbios at clustermatic.org
Subject: Re: boot linux from an ide

If FILO is a payload in flash, then you need to set CONFIG_ROM_STREAM=1 
and CONFIG_ROM_STREAM_START to the address you want to start looking 
for the payload ELF header (usually just after the LinuxBIOS image). 
CONFIG_IDE_STREAM is used to load a payload (such as FILO) from an 
attached IDE device. This is useful if the flash is not large enough to 
hold LinuxBIOS+payload, but is probably not what you are looking for. 
Sorry for the confusion.

Greg

On Nov 25, 2004, at 5:40 AM, Gin wrote:

> I use FILO as the payload to boot from a Hard Disk, which has a
> installed linux on it. I noticed if I enabled the ide stream. It tries
> to read the ELF header from my IDE drive. But I thought the FILO 
> payload
> should be the one to load the image from the IDE drive. When does it
> come in and play the role?
> Anyone can explain the flow of booting if I try to load the INSTALLED
> linux from a IDE drive.
>
>
> Gin
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>



From stepan at openbios.org  Fri Nov 26 04:55:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Fri Nov 26 04:55:00 2004
Subject: Alignment of LinuxBIOS table structures
Message-ID: <20041126112305.GA6135@openbios.org>

Hi,

I got an interesting report today from a customer having problems 
with building LinuxBIOS and the payload with different compilers

The problem is that different compilers handle structure alignment
differently, ie 2.95.x and 3.x have fundamental differences here:

Adding __attribute__ ((packed)) to the structures helps:

struct lb_memory_range {
	uint64_t start;
	uint64_t size;
	uint32_t type;
#define LB_MEM_RAM       1	/* Memory anyone can use */
#define LB_MEM_RESERVED  2	/* Don't use this memory region */
#define LB_MEM_TABLE     16	/* Ram configuration tables are kept in */
	
} __attribute__ ((packed)); 

struct lb_memory {
	uint32_t tag;
	uint32_t size;
	struct lb_memory_range map[0];
} __attribute__ ((packed));

Since this is a table that is passed in memory, we do want it to be
exactly as it is defined, with no extra padding of any kind to make it
reliable information. So I consider adding __attribute__ ((packed))
a good solution for the problem.

If I get no good reasons against adding this, I will check it in later

Stefan



From gwatson at lanl.gov  Fri Nov 26 08:46:01 2004
From: gwatson at lanl.gov (Greg Watson)
Date: Fri Nov 26 08:46:01 2004
Subject: pnp_enable_resource not being called
In-Reply-To: <3174569B9743D511922F00A0C943142306BA33BC@TYANWEB>
References: <3174569B9743D511922F00A0C943142306BA33BC@TYANWEB>
Message-ID: <4788D6F6-3F44-11D9-B5FA-000D932F4B4A@lanl.gov>

YH,

Thanks, that seems to have fixed the problem.

Greg

On Nov 24, 2004, at 3:48 PM, YhLu wrote:

> In the AMD8111_lpc.c
>
> static void amd8111_lpc_enable_resources(device_t dev)
> {
>         pci_dev_enable_resources(dev);
>
>         enable_childrens_resources(dev);
> }
>
> static struct device_operations lpc_ops  = {
>         .read_resources   = amd8111_lpc_read_resources,
>         .set_resources    = pci_dev_set_resources,
>         .enable_resources = amd8111_lpc_enable_resources,
>         .init             = lpc_init,
>         .scan_bus         = scan_static_bus,
> //      .enable           = amd8111_enable,
>         .ops_pci          = &lops_pci,
> };
>
> So I guess you need to add the device driver for the lpc in SB.
>
> Then the scan_static_bus and enable_childrens_resources(dev) will be 
> called.
>
> Regards
>
> YH
>
> -----Original Message-----
> From: Greg Watson [mailto:gwatson at lanl.gov]
> Sent: Wednesday, November 24, 2004 1:29 PM
> To: 'LinuxBIOS'
> Subject: pnp_enable_resource not being called
>
> The sandpoint has the following structure:
>
> Northbridge MPC107 --> Southbridge W83C553 --> Superio PC97307
>
> The config file looks like:
>
> chip northbridge/motorola/mpc107
>          device pci_domain 0 on
>                  device pci 0.0 on end
>                  device pci b.0 on
>                          chip southbridge/winbond/w83c553
>                                  chip superio/NSC/pc97307
>                                          device pnp 15c.0 on end #
> Kyeboard
>                                          device pnp 15c.1 on end # 
> Mouse
>                                          device pnp 15c.2 on end #
> Real-time Cloc
> k
>                                          device pnp 15c.3 on end # 
> Floppy
>                                          device pnp 15c.4 on end #
> Parallel port
>                                          device pnp 15c.5 on end # com2
>                                          device pnp 15c.6 on end # com1
>                                          device pnp 15c.7 on end # gpio
>                                          device pnp 15c.8 on end # 
> Power
> manageme
> nt
>                                  end
>                          end
>                  end # pci to isa bridge
>                  device pci b.1 on end # pci ide controller
>          end
>          device cpu_bus 0 on
>                  chip cpu/ppc/mpc74xx
>                          device cpu 0 on end
>                  end
>          end
> end
>
> The dev_enumerate() code is calling the PNP enable routines and the
> dev_initialize() code is calling the PNP init routine. However the
> dev_enable() code never calls the PNP enable_resource routine, which
> means the the PNP devices are never actually enabled.
>
> The enable_dev routine for the superio device calls:
>
>          pnp_enable_devices(dev, &ops,
>                  sizeof(pnp_dev_info)/sizeof(pnp_dev_info[0]),
> pnp_dev_info);
>
> where ops is defined as:
>
> static struct device_operations ops = {
>          .read_resources   = pnp_read_resources,
>          .set_resources    = pnp_set_resources,
>          .enable_resources = pnp_enable_resources,
>          .enable           = pnp_enable,
>          .init             = init,
> };
>
> Any ideas why this is not working? Is there something else that needs
> to happen?
>
> Greg
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>



From talbotx at comcast.net  Fri Nov 26 10:46:01 2004
From: talbotx at comcast.net (Adam Talbot)
Date: Fri Nov 26 10:46:01 2004
Subject: Stuck.  Compile error with a clean tree.
Message-ID: <001501c4d3db$56ca65e0$9901a8c0@newflame>

Any one have an idea on this error?
I grab a new copy of the freebios2 tree.

cvs -d:pserver:anonymous at cvs.sourceforge.net:/cvsroot/freebios login
cvs -z3 -d:pserver:anonymous at cvs.sourceforge.net:/cvsroot/freebios co
freebios2

cd ~/freebios2/targets/
./buildtarget digitallogic/adl855pc
cd digitallogic/adl855pc/adl855pc
make

gcc -m32 -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld crt0.o
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../../i686-pc-linux-gnu/bin/l
d: section .reset [00000000fffdfff0 -> 00000000fffdffff] overlaps section
.rom [00000000fffd54f8 -> 00000000fffe686f]
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../../i686-pc-linux-gnu/bin/l
d: section .id [00000000fffdffce -> 00000000fffdffef] overlaps section .rom
[00000000fffd54f8 -> 00000000fffe686f]
collect2: ld returned 1 exit status
make[1]: *** [linuxbios] Error 1
make[1]: Leaving directory
`/root/freebios2/targets/digitallogic/adl855pc/adl855pc/normal'
make: *** [normal/linuxbios.rom] Error 1

Here I stand stuck. fixing memory problems is beyond my C skill's
-Adam Talbot








From rminnich at lanl.gov  Sat Nov 27 18:27:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Sat Nov 27 18:27:00 2004
Subject: Stuck.  Compile error with a clean tree.
In-Reply-To: <001501c4d3db$56ca65e0$9901a8c0@newflame>
References: <001501c4d3db$56ca65e0$9901a8c0@newflame>
Message-ID: <Pine.LNX.4.58.0411272140090.12056@linux.site>

Adam, I just committed my changes and the adl855pc builds with same error. 

The problem is simple: the debug levels are so high that our code is
getting too big.

I will try to fix this monday. Looks like recent changes made linuxbios 
grow a bit.

ron



From ginlin at nexcom.com.tw  Sun Nov 28 03:13:00 2004
From: ginlin at nexcom.com.tw (Gin)
Date: Sun Nov 28 03:13:00 2004
Subject: jmp_to_elf_entry
In-Reply-To: <4788D6F6-3F44-11D9-B5FA-000D932F4B4A@lanl.gov>
Message-ID: <000001c4d54e$31039420$4f01060a@nexcom.com.tw>

I've got it to run to the point that it jumps to the ELF entry. My
payload is a FILO. 

What should I see after it jumps to the ELF entry? I guess the FILO
program will start to run, correct?

I have not got my VGA up, so I can't see if it really boots the ELF
entry successfully. Maybe that's what I should do.

Gin



From ginlin at nexcom.com.tw  Sun Nov 28 17:13:00 2004
From: ginlin at nexcom.com.tw (Gin)
Date: Sun Nov 28 17:13:00 2004
Subject: compile vga rom
Message-ID: <000001c4d5c3$7f80c120$4f01060a@nexcom.com.tw>

I have an onboard VGA chip that I want to use. Is there a way to compile
the onboard VGA rom with the linuxbios? Or would it be easier to use a
VGA card?
 
 
Gin 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20041128/0dc1ee00/attachment.html>

From rminnich at lanl.gov  Sun Nov 28 17:58:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Sun Nov 28 17:58:00 2004
Subject: jmp_to_elf_entry
In-Reply-To: <000001c4d54e$31039420$4f01060a@nexcom.com.tw>
References: <000001c4d54e$31039420$4f01060a@nexcom.com.tw>
Message-ID: <Pine.LNX.4.58.0411282113311.15023@linux.site>


On Sun, 28 Nov 2004, Gin wrote:

> I have not got my VGA up, so I can't see if it really boots the ELF
> entry successfully. Maybe that's what I should do.

forget vga, use serial port for now.

ron


From rminnich at lanl.gov  Sun Nov 28 18:19:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Sun Nov 28 18:19:00 2004
Subject: Alignment of LinuxBIOS table structures
In-Reply-To: <20041126112305.GA6135@openbios.org>
References: <20041126112305.GA6135@openbios.org>
Message-ID: <Pine.LNX.4.58.0411282122480.15023@linux.site>


On Fri, 26 Nov 2004, Stefan Reinauer wrote:
> The problem is that different compilers handle structure alignment
> differently, ie 2.95.x and 3.x have fundamental differences here:

stepan, from the point of view of Plan 9, these are the same compiler. 

> Adding __attribute__ ((packed)) to the structures helps:

Sadly, Plan 9 compilers do not support this attribute for very good 
technical reasons. The problem then is that these tables will be hard for 
Plan 9 to deal with. 

> struct lb_memory_range {
> 	uint64_t start;
> 	uint64_t size;
> 	uint32_t type;
> #define LB_MEM_RAM       1	/* Memory anyone can use */
> #define LB_MEM_RESERVED  2	/* Don't use this memory region */
> #define LB_MEM_TABLE     16	/* Ram configuration tables are kept in */
> 	
> } __attribute__ ((packed)); 

There are two problems here. 

The first problem is the use of binary structures, followed by the use of
gcc attributes to make the structures have a certain "shape". I've just
had a big tussle with this in Xen and Plan 9. Xen kind of assumes a gcc
world and things fall apart badly when your compiler is not gcc. This is 
going to happen with these binary structures when our payloads are not 
built with gcc compatible compilers -- which is already the case with Plan 
9 payloads. 

Second problem is, what happens if this or other LinuxBIOS tables need to
change at some future point? We're going to have different versions.  
Intel and Microsoft solve this versioning problem by putting a version
number in binary tables. Hence in the _MP_ table there is a version flag.
This versioning of binary tables is a headache; what if you have to boot a
very old OS that realizes it can't parse table version 2, only table
version 1? Oops. Trouble, that's what.

I think the big problem is the use of binary data structures. It shows how 
smart the Open Boot guys were to use strings, and they figured this out 16 
years ago!

I think we should look at having linuxbios create strings of data for 
tables, not binary tables. Long term, the binary tables are going to cause 
us trouble, as they have already: having to use non-portable compiler 
options/attributes is a recipe for disaster. You only parse them once to 
turn them into internal binary data structures in the OS; performance is 
not an issue here. 

In Plan 9, the parameters are passed in as keyword-value pairs, viz:
totalmem=0x100000

This is easy to generate, and both Linux and Plan 9 and other OSes have 
more than enough functions in the kernel already to parse these. This 
removes special needs for alignment, packing, and so on. 

If you want you can generate Forth tables, which are also simple, but in 
the end, I think we need to avoid the problems of binary tables.

My real preference is for S-expressions, as they are totally 
character-oriented tables that can still provide structure such as trees 
and tables, but I am not sure people will like S-expressions. 

ron


From ben.sommer at berlin.de  Sun Nov 28 19:27:01 2004
From: ben.sommer at berlin.de (Ben Sommer)
Date: Sun Nov 28 19:27:01 2004
Subject: Bios Epia-M Nemiah 10k / 256MB
In-Reply-To: <Pine.LNX.4.58.0411282122480.15023@linux.site>
References: <20041126112305.GA6135@openbios.org> <Pine.LNX.4.58.0411282122480.15023@linux.site>
Message-ID: <200411290642.27501.ben.sommer@berlin.de>

Hi
I'm new in this group and i have a vdr with an epia-m board. is there someone 
with a working bios for my board? I like to boot my debian from harddisk. If 
someone has a good working bios please send it to me :-) My email ist 
ben.sommer at berlin.de

Greetings from Berlin (Germany)

Ben Sommer


From ginlin at nexcom.com.tw  Mon Nov 29 00:16:01 2004
From: ginlin at nexcom.com.tw (Gin)
Date: Mon Nov 29 00:16:01 2004
Subject: elfboot
Message-ID: <000001c4d5fe$93a21920$4f01060a@nexcom.com.tw>

I know it's probably been a while since you look into the elfboot code. 
 
In the elfboot.c
When it tries to build the ELF segment list, it checks if the segment
address is valid by walking through the table of valid memory ranges.
What is the reason to do this?  Below is the code, the "if " statement
seems only guarantee that the new addresses INTERSECT with the valid
memory range, not fully contained.  
 
 
 
for(i = 0; i < mem_entries; i++) {
                uint64_t mstart, mend;
                uint32_t mtype;
                mtype = mem->map[i].type;
                mstart = mem->map[i].start;
                mend = mstart + mem->map[i].size;
                if ((mtype == LB_MEM_RAM) && (start < mend) && (end >
mstart)) {
                        break;
                }
        }
        
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20041129/40b3a20b/attachment.html>

From gwatson at lanl.gov  Mon Nov 29 04:52:00 2004
From: gwatson at lanl.gov (Greg Watson)
Date: Mon Nov 29 04:52:00 2004
Subject: Alignment of LinuxBIOS table structures
In-Reply-To: <Pine.LNX.4.58.0411282122480.15023@linux.site>
References: <20041126112305.GA6135@openbios.org> <Pine.LNX.4.58.0411282122480.15023@linux.site>
Message-ID: <694EBC7A-4218-11D9-B5FA-000D932F4B4A@lanl.gov>

On Nov 28, 2004, at 9:34 PM, Ronald G. Minnich wrote:

>
>
> On Fri, 26 Nov 2004, Stefan Reinauer wrote:
>> The problem is that different compilers handle structure alignment
>> differently, ie 2.95.x and 3.x have fundamental differences here:
>
> stepan, from the point of view of Plan 9, these are the same compiler.
>
>> Adding __attribute__ ((packed)) to the structures helps:
>
> Sadly, Plan 9 compilers do not support this attribute for very good
> technical reasons. The problem then is that these tables will be hard 
> for
> Plan 9 to deal with.
>
>> struct lb_memory_range {
>> 	uint64_t start;
>> 	uint64_t size;
>> 	uint32_t type;
>> #define LB_MEM_RAM       1	/* Memory anyone can use */
>> #define LB_MEM_RESERVED  2	/* Don't use this memory region */
>> #define LB_MEM_TABLE     16	/* Ram configuration tables are kept in */
>> 	
>> } __attribute__ ((packed));
>
> There are two problems here.
>
> The first problem is the use of binary structures, followed by the use 
> of
> gcc attributes to make the structures have a certain "shape". I've just
> had a big tussle with this in Xen and Plan 9. Xen kind of assumes a gcc
> world and things fall apart badly when your compiler is not gcc. This 
> is
> going to happen with these binary structures when our payloads are not
> built with gcc compatible compilers -- which is already the case with 
> Plan
> 9 payloads.
>
> Second problem is, what happens if this or other LinuxBIOS tables need 
> to
> change at some future point? We're going to have different versions.
> Intel and Microsoft solve this versioning problem by putting a version
> number in binary tables. Hence in the _MP_ table there is a version 
> flag.
> This versioning of binary tables is a headache; what if you have to 
> boot a
> very old OS that realizes it can't parse table version 2, only table
> version 1? Oops. Trouble, that's what.
>
> I think the big problem is the use of binary data structures. It shows 
> how
> smart the Open Boot guys were to use strings, and they figured this 
> out 16
> years ago!
>
> I think we should look at having linuxbios create strings of data for
> tables, not binary tables. Long term, the binary tables are going to 
> cause
> us trouble, as they have already: having to use non-portable compiler
> options/attributes is a recipe for disaster. You only parse them once 
> to
> turn them into internal binary data structures in the OS; performance 
> is
> not an issue here.
>
> In Plan 9, the parameters are passed in as keyword-value pairs, viz:
> totalmem=0x100000
>
> This is easy to generate, and both Linux and Plan 9 and other OSes have
> more than enough functions in the kernel already to parse these. This
> removes special needs for alignment, packing, and so on.
>
> If you want you can generate Forth tables, which are also simple, but 
> in
> the end, I think we need to avoid the problems of binary tables.
>
> My real preference is for S-expressions, as they are totally
> character-oriented tables that can still provide structure such as 
> trees
> and tables, but I am not sure people will like S-expressions.

I agree, we need to get away from binary structures. Much as I like 
S-expressions, strings containing key/value pairs is probably the most 
common and easily understandable way to do it.

Greg



From rminnich at lanl.gov  Mon Nov 29 04:59:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Nov 29 04:59:00 2004
Subject: elfboot
In-Reply-To: <000001c4d5fe$93a21920$4f01060a@nexcom.com.tw>
References: <000001c4d5fe$93a21920$4f01060a@nexcom.com.tw>
Message-ID: <Pine.LNX.4.58.0411290807360.16481@linux.site>


On Mon, 29 Nov 2004, Gin wrote:

> When it tries to build the ELF segment list, it checks if the segment
> address is valid by walking through the table of valid memory ranges.
> What is the reason to do this?  

Because we don't relocate elf addresses. The addresses in the elf have to 
be backed by memory.

> for(i = 0; i < mem_entries; i++) {
>                 uint64_t mstart, mend;
>                 uint32_t mtype;
>                 mtype = mem->map[i].type;
>                 mstart = mem->map[i].start;
>                 mend = mstart + mem->map[i].size;
>                 if ((mtype == LB_MEM_RAM) && (start < mend) && (end >
> mstart)) {

Possibly I'm reading this wrong but ... this test looks somewhat broken. 

take a simple case. 
memory start 0x1000 memory end 0x2000 
elf    start 0x1001 elf end 0x3000

Seems like this test will indicate, incorrectly, that the elf segment will 
fit in physical memory and that is not the case.

ron



From ebiederman at lnxi.com  Mon Nov 29 08:06:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Nov 29 08:06:01 2004
Subject: Alignment of LinuxBIOS table structures
In-Reply-To: <20041126112305.GA6135@openbios.org>
References: <20041126112305.GA6135@openbios.org>
Message-ID: <m3hdn8plde.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at openbios.org> writes:

> Hi,
> 
> I got an interesting report today from a customer having problems 
> with building LinuxBIOS and the payload with different compilers
> 
> The problem is that different compilers handle structure alignment
> differently, ie 2.95.x and 3.x have fundamental differences here:

I agree that there is a problem with the definition of this structure.  
Everything in the table remains 32bit aligned so we are clear there.
For 64bit data types the alignment is much less clear, and struct
lb_memory_range is a bit of a problem in that it does not have a 32bit
type as padding.

To see what the problem actually amounts to I walked through my
compiler collection with a simple test to see what sizeof reported
for lb_memory_range, (without adding the packed attribute).

> #include <stdio.h>
> #include "linuxbios_tables.h"
> 
> 
> int main(int argc, char **argv)
> {
> 	printf("sizeof(lb_memory_range): %d\n", sizeof(struct lb_memory_range));
> 	return 0;
> }

On 32bit x86 I tested with:
gcc-2.7.2
gcc-2.95
gcc-3.0
gcc-3.2
gcc-3.3
gcc-3.4

And in each instance the result was 20. 

On 64bit x86 I with I tested with
gcc-3.2
gcc-3.3
gcc-3.4

And the result was 24.

I also managed to test with gcc-3.3 with -m32 and the size was still
20.

So from what I can see with 32bit x86 code we are consistent, and we
do not have compiler version dependencies.   So the bad definition
is consistent.

Moving forward we need to remove this table entry and 
replace it with a table entry that is properly defined.
Utilities like mkelfImage can continue to support the old definition,
but it should be deprecated there.

> Since this is a table that is passed in memory, we do want it to be
> exactly as it is defined, with no extra padding of any kind to make it
> reliable information. So I consider adding __attribute__ ((packed))
> a good solution for the problem.

It is a good pragmatic solution, but actually needing __attribute__ ((packed))
is an issue.  As Ron has pointed out, not all compilers support it.
And having a definition that varies between 32bit and 64bit is a
problem anyway.

> If I get no good reasons against adding this, I will check it in
> later


What I want to do is add a replacement for struct lb_memory_range that
looks like:

struct lb_memory_range2 {
	uint64_t start;
	uint64_t size;
	uint32_t type;
#define LB_MEM_RAM       1	/* Memory anyone can use */
#define LB_MEM_RESERVED  2	/* Don't use this memory region */
#define LB_MEM_TABLE     16	/* Ram configuration tables are kept in */
	uint32_t reserved;	
};

At the same time I need to define an LB_TAB_ALIGN that I can insert
when data is only 32bit aligned and I need 64bit or better alignment
in the table.  64bit alignment is unlikely to cost much at this
point but better safe than sorry :)  And it preserves the property
that the data in the table can just be used.

Eric



From ebiederman at lnxi.com  Mon Nov 29 09:09:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Nov 29 09:09:00 2004
Subject: Alignment of LinuxBIOS table structures
In-Reply-To: <Pine.LNX.4.58.0411282122480.15023@linux.site>
References: <20041126112305.GA6135@openbios.org>
	<Pine.LNX.4.58.0411282122480.15023@linux.site>
Message-ID: <m3wtw4o3vb.fsf@maxwell.lnxi.com>

"Ronald G. Minnich" <rminnich at lanl.gov> writes:

> On Fri, 26 Nov 2004, Stefan Reinauer wrote:

> I think the big problem is the use of binary data structures. It shows how 
> smart the Open Boot guys were to use strings, and they figured this out 16 
> years ago!

open boot provides a single function you can call.  And as I recall
everything is done in terms of forth words.  32 bit or 64bit.   
My memory may be faulty but that does not sound like a string based 
interface.

> I think we should look at having linuxbios create strings of data for 
> tables, not binary tables. Long term, the binary tables are going to cause 
> us trouble, as they have already: having to use non-portable compiler 
> options/attributes is a recipe for disaster. You only parse them once to 
> turn them into internal binary data structures in the OS; performance is 
> not an issue here. 

Performance is not an issue code size can be.  Check out ACPI for the
nasty version of needing too much parsing to get the data you need.

> In Plan 9, the parameters are passed in as keyword-value pairs, viz:
> totalmem=0x100000

Which is not bad.  But the implementation is totally naive.

> This is easy to generate, and both Linux and Plan 9 and other OSes have 
> more than enough functions in the kernel already to parse these. This 
> removes special needs for alignment, packing, and so on. 

What of etherboot, what of mkelfImage, and other simple utilities.

> If you want you can generate Forth tables, which are also simple, but in 
> the end, I think we need to avoid the problems of binary tables.


> My real preference is for S-expressions, as they are totally 
> character-oriented tables that can still provide structure such as trees 
> and tables, but I am not sure people will like S-expressions. 

If we really want to avoid problems what we need is a table definition
checker that looks at the definitions of table entries and checks to
see if they are portable and safe.  I don't care if they are binary
or string based, you can get into problems either way.

If someone wants to do a proof of concept of a string based implementation
I am willing to consider ideas.  

Be warned though that strings scare me because everyone thinks they
are safe, and easy.  When in fact they have the same essential
complexity as binary data structures with simply a different set of
limitations, and fewer tools provided in the compiler to make certain
you don't mess up.

In addition there are cases that string based tables handle very
poorly such as passing fonts.

With the current structure is there is information that is best
passed in a string form we can define one or more table entries
that allows us to implement that.

The next big step is to export the device tree via the linuxbios
table to the outside world.  In most cases the this decomposes nicely
into a hierarchical set of devices.  But with interrupts and a few
of their kin it starts getting hard to describe hardware as a tree,
making a graph necessary to handle the general case.  

Fundamentally changing things is just something to think about for
now. 

The current problem while very bad is still mild enough the current
table definitions can be patched.  It is unfortunate that this
happened with the most widely used table entry.

Eric






From ebiederman at lnxi.com  Mon Nov 29 09:11:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Nov 29 09:11:01 2004
Subject: Stuck.  Compile error with a clean tree.
In-Reply-To: <Pine.LNX.4.58.0411272140090.12056@linux.site>
References: <001501c4d3db$56ca65e0$9901a8c0@newflame>
	<Pine.LNX.4.58.0411272140090.12056@linux.site>
Message-ID: <m3sm6so3s8.fsf@maxwell.lnxi.com>

"Ronald G. Minnich" <rminnich at lanl.gov> writes:

> Adam, I just committed my changes and the adl855pc builds with same error. 
> 
> The problem is simple: the debug levels are so high that our code is
> getting too big.
> 
> I will try to fix this monday. Looks like recent changes made linuxbios 
> grow a bit.

Can you bump up ROM_IMAGE_SIZE by a small amount to avoid this?

I wish I knew a way to implement a grow down segment in LD.

Eric


From rminnich at lanl.gov  Mon Nov 29 09:59:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Nov 29 09:59:00 2004
Subject: Stuck.  Compile error with a clean tree.
In-Reply-To: <m3sm6so3s8.fsf@maxwell.lnxi.com>
References: <001501c4d3db$56ca65e0$9901a8c0@newflame>
 <Pine.LNX.4.58.0411272140090.12056@linux.site> <m3sm6so3s8.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.58.0411291314070.16947@linux.site>


On Mon, 29 Nov 2004, Eric W. Biederman wrote:
> I wish I knew a way to implement a grow down segment in LD.

I worry that we're asking LD to do more than it should be asked to do.

ron


From talbotx at comcast.net  Mon Nov 29 10:03:00 2004
From: talbotx at comcast.net (Adam Talbot)
Date: Mon Nov 29 10:03:00 2004
Subject: Stuck.  Compile error with a clean tree.
References: <001501c4d3db$56ca65e0$9901a8c0@newflame> <Pine.LNX.4.58.0411272140090.12056@linux.site> <m3sm6so3s8.fsf@maxwell.lnxi.com> <Pine.LNX.4.58.0411291314070.16947@linux.site>
Message-ID: <002501c4d650$9e8e2520$9901a8c0@newflame>

Well if I up my ROM_IMAGE_SIZE, it does go through and compile the
digitallogic/adl855pc with out any errors... Rebuilding my configs for my
board, I will get back to you in a few hours.
-Adam Talbot

----- Original Message ----- 
From: "Ronald G. Minnich" <rminnich at lanl.gov>
To: "Eric W. Biederman" <ebiederman at lnxi.com>
Cc: "Adam Talbot" <talbotx at comcast.net>; <linuxbios at clustermatic.org>
Sent: Monday, November 29, 2004 12:14 PM
Subject: Re: Stuck. Compile error with a clean tree.


>
>
> On Mon, 29 Nov 2004, Eric W. Biederman wrote:
> > I wish I knew a way to implement a grow down segment in LD.
>
> I worry that we're asking LD to do more than it should be asked to do.
>
> ron
>




From rminnich at lanl.gov  Mon Nov 29 10:06:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Nov 29 10:06:00 2004
Subject: Alignment of LinuxBIOS table structures
In-Reply-To: <m3wtw4o3vb.fsf@maxwell.lnxi.com>
References: <20041126112305.GA6135@openbios.org> <Pine.LNX.4.58.0411282122480.15023@linux.site>
 <m3wtw4o3vb.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.58.0411291316150.16947@linux.site>


On Mon, 29 Nov 2004, Eric W. Biederman wrote:

> Performance is not an issue code size can be.  Check out ACPI for the
> nasty version of needing too much parsing to get the data you need.

no argument, we don't want to recreate ACPI
> > totalmem=0x100000
> 
> Which is not bad.  But the implementation is totally naive.

??

> What of etherboot, what of mkelfImage, and other simple utilities.

again, the x=y stuff is dead simple to parse. Keep in mind, there is the 
possibility as time goes on of matching old linuxbios to new payloads, or 
even in the worse case for testing old payloads to new linuxbios. 

You're either going to need to:
1- fix the table for all time (not practical)
2- version number the table (which can detect version mismatch but can't 
   fix it)
3- go to a string-based organization

now the fact is that etherboot parses all kinds of strings in packets, so 
I don't see parsing linuxbios strings a big deal; same with the others. 
They all deal with strings of one sort or another. 

> In addition there are cases that string based tables handle very
> poorly such as passing fonts.

You lost me on this one. Are we planning to pass fonts in the tables in 
whatever form they take?

> With the current structure is there is information that is best
> passed in a string form we can define one or more table entries
> that allows us to implement that.

That won't fix the fundamental problem with binary tables. 

I think what Stepan's problem has shown, as my problems with Xen have 
shown, that planning to pass structs through and assume it will always 
work is going to get us in trouble.

We don't have to do keyword-value pairs, but the binary table approach is 
not the clear win it first appeared to be.

ron


From talbotx at comcast.net  Mon Nov 29 11:27:00 2004
From: talbotx at comcast.net (Adam Talbot)
Date: Mon Nov 29 11:27:00 2004
Subject: Stuck.  Compile error with a clean tree.
References: <001501c4d3db$56ca65e0$9901a8c0@newflame> <Pine.LNX.4.58.0411272140090.12056@linux.site> <m3sm6so3s8.fsf@maxwell.lnxi.com> <Pine.LNX.4.58.0411291314070.16947@linux.site> <002501c4d650$9e8e2520$9901a8c0@newflame>
Message-ID: <009a01c4d65c$5bc18140$9901a8c0@newflame>

Woot!!!
It compiles and boot, kinda.  The compile finishes with out any errors, but
when I go to boot the system all I get is garbage on the minicom screen.
Same with hyperterm. I have seen this out put in minicom before, simple fix,
set minicom to the right speed ( 115200 8N1, no hard/software flow control).
I when through all speed, it still does not like me. Any ideas?


my current config:

target lv671
mainboard commell/lv671

option ROM_SIZE=524288

romimage "normal"
        option USE_FALLBACK_IMAGE=0
        option ROM_IMAGE_SIZE=0x15000
        option LINUXBIOS_EXTRA_VERSION=".0Normal"
        payload /etc/hosts
end

romimage "fallback"
        option USE_FALLBACK_IMAGE=1
        option ROM_IMAGE_SIZE=0x15000
        option LINUXBIOS_EXTRA_VERSION=".0Fallback"
        payload /etc/hosts
end

buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback"




From rminnich at lanl.gov  Mon Nov 29 11:32:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Nov 29 11:32:00 2004
Subject: Stuck.  Compile error with a clean tree.
In-Reply-To: <009a01c4d65c$5bc18140$9901a8c0@newflame>
References: <001501c4d3db$56ca65e0$9901a8c0@newflame>
 <Pine.LNX.4.58.0411272140090.12056@linux.site> <m3sm6so3s8.fsf@maxwell.lnxi.com>
 <Pine.LNX.4.58.0411291314070.16947@linux.site> <002501c4d650$9e8e2520$9901a8c0@newflame>
 <009a01c4d65c$5bc18140$9901a8c0@newflame>
Message-ID: <Pine.LNX.4.58.0411291447090.16947@linux.site>

that's odd, in the adl855pc I got output just fine. 

For the heck of it, build an adl855pc target and see if you get the same 
problem.

ron



From talbotx at comcast.net  Mon Nov 29 12:04:00 2004
From: talbotx at comcast.net (Adam Talbot)
Date: Mon Nov 29 12:04:00 2004
Subject: Stuck.  Compile error with a clean tree.
References: <001501c4d3db$56ca65e0$9901a8c0@newflame> <Pine.LNX.4.58.0411272140090.12056@linux.site> <m3sm6so3s8.fsf@maxwell.lnxi.com> <Pine.LNX.4.58.0411291314070.16947@linux.site> <002501c4d650$9e8e2520$9901a8c0@newflame> <009a01c4d65c$5bc18140$9901a8c0@newflame> <Pine.LNX.4.58.0411291447090.16947@linux.site>
Message-ID: <00af01c4d661$7c7942b0$9901a8c0@newflame>

Clean compile of the adl855pc.  I changed 2 lines in the config and added
one.

added:        option ROM_SIZE=524288
normal,
changed:     option ROM_IMAGE_SIZE=0x10000    to    option
ROM_IMAGE_SIZE=0x15000
fallback,
changed:     option ROM_IMAGE_SIZE=0x10000    to    option
ROM_IMAGE_SIZE=0x15000

Still get garbage to the screen... Bad cable?  Switched cables, same.  Idea,
added console redirect to my grub.conf set the speed to 115200 8n1, works
fine.  Hummm
What does it take to get the onboard VGA running? Can you give me a quick
"how to"?
-Adam Talbot


----- Original Message ----- 
From: "Ronald G. Minnich" <rminnich at lanl.gov>
To: "Adam Talbot" <talbotx at comcast.net>
Cc: <linuxbios at clustermatic.org>
Sent: Monday, November 29, 2004 1:47 PM
Subject: Re: Stuck. Compile error with a clean tree.


> that's odd, in the adl855pc I got output just fine.
>
> For the heck of it, build an adl855pc target and see if you get the same
> problem.
>
> ron
>
>




From rminnich at lanl.gov  Mon Nov 29 12:06:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Nov 29 12:06:01 2004
Subject: Stuck.  Compile error with a clean tree.
In-Reply-To: <00af01c4d661$7c7942b0$9901a8c0@newflame>
References: <001501c4d3db$56ca65e0$9901a8c0@newflame>
 <Pine.LNX.4.58.0411272140090.12056@linux.site> <m3sm6so3s8.fsf@maxwell.lnxi.com>
 <Pine.LNX.4.58.0411291314070.16947@linux.site> <002501c4d650$9e8e2520$9901a8c0@newflame>
 <009a01c4d65c$5bc18140$9901a8c0@newflame> <Pine.LNX.4.58.0411291447090.16947@linux.site>
 <00af01c4d661$7c7942b0$9901a8c0@newflame>
Message-ID: <Pine.LNX.4.58.0411291520460.16947@linux.site>


On Mon, 29 Nov 2004, Adam Talbot wrote:

> What does it take to get the onboard VGA running? Can you give me a quick
> "how to"?

there's nothing quick about vga. stick to serial. YOur problems are in the 
dram, so stay with that for now.

ron


From daubin at actuality-systems.com  Mon Nov 29 12:33:01 2004
From: daubin at actuality-systems.com (Dave Aubin)
Date: Mon Nov 29 12:33:01 2004
Subject: Stuck.  Compile error with a clean tree.
Message-ID: <E8F8DBCB0468204E856114A2CD20741F390A51@mail.local.ActualitySystems.com>

Do you have access to the network?
If you don't have a com cable (like I did in the beginning) then
You could try netconsole.  Here are some links to what it is.

http://lwn.net/Articles/43852/
http://technocrat.net/article.pl?sid=04/08/14/0236245&mode=nested

Although this will only help you if you are getting to a 2.6 kernel
And have a network connection.

Dave 

-----Original Message-----
From: linuxbios-admin at clustermatic.org
[mailto:linuxbios-admin at clustermatic.org] On Behalf Of Adam Talbot
Sent: Monday, November 29, 2004 5:19 PM
To: Ronald G. Minnich
Cc: linuxbios at clustermatic.org
Subject: Re: Stuck. Compile error with a clean tree.

Clean compile of the adl855pc.  I changed 2 lines in the config and
added one.

added:        option ROM_SIZE=524288
normal,
changed:     option ROM_IMAGE_SIZE=0x10000    to    option
ROM_IMAGE_SIZE=0x15000
fallback,
changed:     option ROM_IMAGE_SIZE=0x10000    to    option
ROM_IMAGE_SIZE=0x15000

Still get garbage to the screen... Bad cable?  Switched cables, same.
Idea, added console redirect to my grub.conf set the speed to 115200
8n1, works fine.  Hummm What does it take to get the onboard VGA
running? Can you give me a quick "how to"?
-Adam Talbot


----- Original Message -----
From: "Ronald G. Minnich" <rminnich at lanl.gov>
To: "Adam Talbot" <talbotx at comcast.net>
Cc: <linuxbios at clustermatic.org>
Sent: Monday, November 29, 2004 1:47 PM
Subject: Re: Stuck. Compile error with a clean tree.


> that's odd, in the adl855pc I got output just fine.
>
> For the heck of it, build an adl855pc target and see if you get the
same
> problem.
>
> ron
>
>


_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From rminnich at lanl.gov  Mon Nov 29 12:35:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Nov 29 12:35:01 2004
Subject: Stuck.  Compile error with a clean tree.
In-Reply-To: <E8F8DBCB0468204E856114A2CD20741F390A51@mail.local.ActualitySystems.com>
References: <E8F8DBCB0468204E856114A2CD20741F390A51@mail.local.ActualitySystems.com>
Message-ID: <Pine.LNX.4.58.0411291550180.16947@linux.site>


On Mon, 29 Nov 2004, Dave Aubin wrote:

> Although this will only help you if you are getting to a 2.6 kernel
> And have a network connection.

he's nowhere near that far. He's got to get the northbridge working so 
memory works. It doesn't. 

serial port is the only way.

ron


From talbotx at comcast.net  Mon Nov 29 13:59:00 2004
From: talbotx at comcast.net (Adam Talbot)
Date: Mon Nov 29 13:59:00 2004
Subject: Stuck.  Compile error with a clean tree.
References: <001501c4d3db$56ca65e0$9901a8c0@newflame> <Pine.LNX.4.58.0411272140090.12056@linux.site> <m3sm6so3s8.fsf@maxwell.lnxi.com> <Pine.LNX.4.58.0411291314070.16947@linux.site> <002501c4d650$9e8e2520$9901a8c0@newflame> <009a01c4d65c$5bc18140$9901a8c0@newflame> <Pine.LNX.4.58.0411291447090.16947@linux.site> <00af01c4d661$7c7942b0$9901a8c0@newflame> <Pine.LNX.4.58.0411291520460.16947@linux.site>
Message-ID: <00d201c4d671$970c49f0$9901a8c0@newflame>

dram issue's, where should I start hunting?
-Adam Talbot
----- Original Message ----- 
From: "Ronald G. Minnich" <rminnich at lanl.gov>
To: "Adam Talbot" <talbotx at comcast.net>
Cc: <linuxbios at clustermatic.org>
Sent: Monday, November 29, 2004 2:21 PM
Subject: Re: Stuck. Compile error with a clean tree.


>
>
> On Mon, 29 Nov 2004, Adam Talbot wrote:
>
> > What does it take to get the onboard VGA running? Can you give me a
quick
> > "how to"?
>
> there's nothing quick about vga. stick to serial. YOur problems are in the
> dram, so stay with that for now.
>
> ron
>




From YhLu at tyan.com  Mon Nov 29 14:57:00 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Nov 29 14:57:00 2004
Subject: get_pbus
Message-ID: <3174569B9743D511922F00A0C943142306BA345B@TYANWEB>

Every pci_read_config and pci_write_config need to findout top parenent bus
to get bus ops. (get_pbus).

It looks weird....

YH



From ebiederman at lnxi.com  Mon Nov 29 15:32:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Nov 29 15:32:00 2004
Subject: get_pbus
In-Reply-To: <3174569B9743D511922F00A0C943142306BA345B@TYANWEB>
References: <3174569B9743D511922F00A0C943142306BA345B@TYANWEB>
Message-ID: <m3d5xwumyj.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Every pci_read_config and pci_write_config need to findout top parenent bus
> to get bus ops. (get_pbus).
> 
> It looks weird....

Yes, it does look weird.  But it comes very close to modeling reality.
You have to find the top of the pci bus to perform reads and writes.
The apparent inefficiency does not thrill me but the tree is not
usually very deep so in practice get_pbus only needs to execute one
or two look iterations.

It allows any bus that has specific methods for pci read/write
to implement them, and any bus that does not need not care.

If I read the documentation correctly one of the powerpc northbridges
the cpc710 I think actually has 2 separate pci domains with a 
different base register to access each of the different pci domains.

So having pci access methods that vary by pci domain is a case that
needs to be handled, and this code allows it.  

In addition we need something similar to handle the extended pci
accesses which PCI express allows.  I still need to find out how
the hypertransport to PCI-Express bridges handle that case.  Do the
decode the reserved HT memory region that is just below 1TB or do
they do something else?

Eric


From YhLu at tyan.com  Mon Nov 29 15:44:00 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Nov 29 15:44:00 2004
Subject: get_pbus
Message-ID: <3174569B9743D511922F00A0C943142306BA3460@TYANWEB>

You mean to access extra reg space (4096 bytes) for PCI-E device?

We don't need to touch that extra space ....in LinuxBIOS.
Under LinuxBIOS + kernel + IB driver, the IB adapter works well with S289x.
need to create one entry in mptable for the device. Otherwise it can not get
INT.

Currently I can not make MSI work....Kernel 2.6.

YH


From talbotx at comcast.net  Mon Nov 29 16:02:00 2004
From: talbotx at comcast.net (Adam Talbot)
Date: Mon Nov 29 16:02:00 2004
Subject: Any one have a "How to" on vga?
Message-ID: <00fb01c4d682$ce85bc20$9901a8c0@newflame>

OK, can any one give me a quick how to on setting up VGA?
I have the system booting, kinda, and I would like to see if can get the VGA
bios loaded.




From YhLu at tyan.com  Mon Nov 29 16:20:01 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Nov 29 16:20:01 2004
Subject: Any one have a "How to" on vga?
Message-ID: <3174569B9743D511922F00A0C943142306BA3466@TYANWEB>

What's your VGA chip?
Currently ati rage xl initialized in LinuxBIOS stage (dev init). --- via
framebuffer and btext.
Some XGI blade has some code in drivers dir too.

Otherwise You need to get the system boot into Linux and use vgabios to call
vga rom to init VGA.

If you have problem before that, you need to stick to serial port to get
debug message.

YH

-----Original Message-----
From: Adam Talbot [mailto:talbotx at comcast.net] 
Sent: Monday, November 29, 2004 6:18 PM
To: linuxbios at clustermatic.org
Subject: Any one have a "How to" on vga?

OK, can any one give me a quick how to on setting up VGA?
I have the system booting, kinda, and I would like to see if can get the VGA
bios loaded.


_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From talbotx at comcast.net  Mon Nov 29 20:02:01 2004
From: talbotx at comcast.net (Adam Talbot)
Date: Mon Nov 29 20:02:01 2004
Subject: Any one have a "How to" on vga?
References: <3174569B9743D511922F00A0C943142306BA3466@TYANWEB>
Message-ID: <010701c4d6a4$491c7980$9901a8c0@newflame>

855GME intel extream, onboard.
What code do I need to find from intel inorder to make my system boot with
VGA support?
-Adam Talbot
----- Original Message ----- 
From: "YhLu" <YhLu at tyan.com>
To: "Adam Talbot" <talbotx at comcast.net>; <linuxbios at clustermatic.org>
Sent: Monday, November 29, 2004 6:42 PM
Subject: RE: Any one have a "How to" on vga?


> What's your VGA chip?
> Currently ati rage xl initialized in LinuxBIOS stage (dev init). --- via
> framebuffer and btext.
> Some XGI blade has some code in drivers dir too.
>
> Otherwise You need to get the system boot into Linux and use vgabios to
call
> vga rom to init VGA.
>
> If you have problem before that, you need to stick to serial port to get
> debug message.
>
> YH
>
> -----Original Message-----
> From: Adam Talbot [mailto:talbotx at comcast.net]
> Sent: Monday, November 29, 2004 6:18 PM
> To: linuxbios at clustermatic.org
> Subject: Any one have a "How to" on vga?
>
> OK, can any one give me a quick how to on setting up VGA?
> I have the system booting, kinda, and I would like to see if can get the
VGA
> bios loaded.
>
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>




From stepan at openbios.org  Tue Nov 30 03:24:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue Nov 30 03:24:00 2004
Subject: Alignment of LinuxBIOS table structures
In-Reply-To: <m3hdn8plde.fsf@maxwell.lnxi.com>
References: <20041126112305.GA6135@openbios.org> <m3hdn8plde.fsf@maxwell.lnxi.com>
Message-ID: <20041130133954.GB6348@openbios.org>

* Eric W. Biederman <ebiederman at lnxi.com> [041129 19:21]:
> To see what the problem actually amounts to I walked through my
> compiler collection with a simple test to see what sizeof reported
> for lb_memory_range, (without adding the packed attribute).
 
> On 32bit x86 I tested with:
> gcc-2.7.2
> gcc-2.95
> gcc-3.0
> gcc-3.2
> gcc-3.3
> gcc-3.4
> 
> And in each instance the result was 20. 
 
> So from what I can see with 32bit x86 code we are consistent, and we
> do not have compiler version dependencies.   So the bad definition
> is consistent.

x86 QNX/Neutrino 6.2.1 (with gcc 2.95.3):
# gcc -v
Reading specs from /usr/lib/gcc-lib/ntox86/2.95.3qnx-nto/specs
gcc version 2.95.3qnx-nto 20010315 (release)

sizeof(lb_memory_range): 24
sizeof(struct lb_memory): 8

It seems gcc does not always behave the same. 

> It is a good pragmatic solution, but actually needing __attribute__ ((packed))
> is an issue.  As Ron has pointed out, not all compilers support it.
> And having a definition that varies between 32bit and 64bit is a
> problem anyway.
 
So you are saying people out there are building LinuxBIOS with non-gnu 
compilers? I actually doubt that, assuming a lot of objcopy/objdump/ld
magic is pretty much gnu specific as well.. 

one could go like:

#ifdef __GNUC__
#define STRICTSIZE __attribute__ ((packed))
#else
#define STRICTSIZE 
#endif

Fixing the issue among all gcc versions while not breaking anything on
others. It really sucks that gcc does magic here that makes writing
portable code really ugly.

Stefan



From rminnich at lanl.gov  Tue Nov 30 05:24:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Tue Nov 30 05:24:00 2004
Subject: Stuck.  Compile error with a clean tree.
In-Reply-To: <00d201c4d671$970c49f0$9901a8c0@newflame>
References: <001501c4d3db$56ca65e0$9901a8c0@newflame>
 <Pine.LNX.4.58.0411272140090.12056@linux.site> <m3sm6so3s8.fsf@maxwell.lnxi.com>
 <Pine.LNX.4.58.0411291314070.16947@linux.site> <002501c4d650$9e8e2520$9901a8c0@newflame>
 <009a01c4d65c$5bc18140$9901a8c0@newflame> <Pine.LNX.4.58.0411291447090.16947@linux.site>
 <00af01c4d661$7c7942b0$9901a8c0@newflame> <Pine.LNX.4.58.0411291520460.16947@linux.site>
 <00d201c4d671$970c49f0$9901a8c0@newflame>
Message-ID: <Pine.LNX.4.58.0411300839120.19250@linux.site>


On Mon, 29 Nov 2004, Adam Talbot wrote:

> dram issue's, where should I start hunting?

start with the l440gx data book from developer.intel.com, it has a nice 
overview of how to turn on SDRAM. Then read about DDR which is on that 
board. Then read the e7501 code which turns on that part. Then read teh 
855GME manual. 

ron


From rminnich at lanl.gov  Tue Nov 30 05:28:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Tue Nov 30 05:28:00 2004
Subject: Any one have a "How to" on vga?
In-Reply-To: <00fb01c4d682$ce85bc20$9901a8c0@newflame>
References: <00fb01c4d682$ce85bc20$9901a8c0@newflame>
Message-ID: <Pine.LNX.4.58.0411300842550.19250@linux.site>


On Mon, 29 Nov 2004, Adam Talbot wrote:

> OK, can any one give me a quick how to on setting up VGA?
> I have the system booting, kinda, and I would like to see if can get the VGA
> bios loaded.

Adam, I can't tell you enough times that this is an exercise in
frustration. If this board you have uses system memory for the frame
buffer, as does the ADL855PC, then VGA will need working memory, which I
doubt you have. You need to make sure memory works before fooling with
VGA.

thanks

ron


From rminnich at lanl.gov  Tue Nov 30 05:41:00 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Tue Nov 30 05:41:00 2004
Subject: Alignment of LinuxBIOS table structures
In-Reply-To: <20041130133954.GB6348@openbios.org>
References: <20041126112305.GA6135@openbios.org> <m3hdn8plde.fsf@maxwell.lnxi.com>
 <20041130133954.GB6348@openbios.org>
Message-ID: <Pine.LNX.4.58.0411300850300.19250@linux.site>


On Tue, 30 Nov 2004, Stefan Reinauer wrote:

> So you are saying people out there are building LinuxBIOS with non-gnu 
> compilers? I actually doubt that, assuming a lot of objcopy/objdump/ld
> magic is pretty much gnu specific as well.. 

no, what i'm saying is that there are people (me, at least) building
payloads with non-gnu compilers. If you use gcc magic to fix that struct,
and said magic is not available in the other compilers, then the payload
will not be able to read the table easily. I've had this very same problem 
passing structs between Xen and Plan 9; Xen relies on every gcc trick in 
the book, which is very hard to deal with when you have a non-gcc 
compiler. 

Plus, even if you get all the gcc flags done correctly, we still have the
table version problem, as has been shown with the various versions of the
SMP tables.

It's been shown in practice that you can avoid these problems by not using
a binary table; plan 9 has used strings for 16 years now with no ill
effects. I would NOT recommend that V2 use a binary table but there seems
to be some resistance to a strings-based table. In any event, V3 will use
a string-based interface.

> Fixing the issue among all gcc versions while not breaking anything on
> others. It really sucks that gcc does magic here that makes writing
> portable code really ugly.
> 

it's only an issue because we're trying to using binary tables in a way 
that is simply not appropriate for portability. The problem is easily 
fixed, but there seems to be some resistance to doing this in V2. 

ron


From shahidi at engr.mun.ca  Tue Nov 30 06:10:01 2004
From: shahidi at engr.mun.ca (Reza Shahidi)
Date: Tue Nov 30 06:10:01 2004
Subject: MATLAB with Clustermatic
Message-ID: <41AC9F28.3050807@engr.mun.ca>

Hello:

    We have set up Clustermatic 5 on a small five-node cluster, and want 
to install a parallel implementation of MATLAB.  Which would you 
recommend?  MATLAB*P and STAR-P looked good, but I haven't been able to 
find anywhere to download them.  Both ease of coding and running speed 
are important.  If you have any experience or suggestions, could you 
respond?

Thanks,
Reza


From rminnich at lanl.gov  Tue Nov 30 06:30:01 2004
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Tue Nov 30 06:30:01 2004
Subject: MATLAB with Clustermatic
In-Reply-To: <41AC9F28.3050807@engr.mun.ca>
References: <41AC9F28.3050807@engr.mun.ca>
Message-ID: <Pine.LNX.4.58.0411300945290.19250@linux.site>


On Tue, 30 Nov 2004, Reza Shahidi wrote:

>    We have set up Clustermatic 5 on a small five-node cluster, and want to
> install a parallel implementation of MATLAB.  Which would you recommend?
> MATLAB*P and STAR-P looked good, but I haven't been able to find anywhere to
> download them.  Both ease of coding and running speed are important.  If you
> have any experience or suggestions, could you respond?


well, this is the wrong list, but anyway ... it's been years since I did 
parallel matlab, and the licensing costs were the big issue. You should 
try all the ones you can.

ron


From bari at onelabs.com  Tue Nov 30 07:24:01 2004
From: bari at onelabs.com (Bari Ari)
Date: Tue Nov 30 07:24:01 2004
Subject: MATLAB with Clustermatic
In-Reply-To: <Pine.LNX.4.58.0411300945290.19250@linux.site>
References: <41AC9F28.3050807@engr.mun.ca> <Pine.LNX.4.58.0411300945290.19250@linux.site>
Message-ID: <41ACB0B9.3090801@onelabs.com>

Try posting your question here:

beowulf at beowulf.org

Ronald G. Minnich wrote:
> 
> On Tue, 30 Nov 2004, Reza Shahidi wrote:
> 
> 
>>   We have set up Clustermatic 5 on a small five-node cluster, and want to
>>install a parallel implementation of MATLAB.  Which would you recommend?
>>MATLAB*P and STAR-P looked good, but I haven't been able to find anywhere to
>>download them.  Both ease of coding and running speed are important.  If you
>>have any experience or suggestions, could you respond?
> 
> 
> 
> well, this is the wrong list, but anyway ... it's been years since I did 
> parallel matlab, and the licensing costs were the big issue. You should 
> try all the ones you can.
> 
> ron
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 
> 
> 
> 



From stepan at openbios.org  Tue Nov 30 12:04:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue Nov 30 12:04:00 2004
Subject: What's next?
In-Reply-To: <200411260344.iAQ3iBL11308@nwn.definitive.org>
References: <20041125230708.GA5619@openbios.org> <200411260344.iAQ3iBL11308@nwn.definitive.org>
Message-ID: <20041130221716.GA15322@openbios.org>

* Yinghai Lu <yhlu at tyan.com> [041126 06:13]:
> What is your HT topology?
> 
> Is there any cross link between (CPU0 and CPU2) or (CPU1 and CPU2)....

0-2 is there, did you mean 0-3/1-2?

Actually the specs I got had a different CPU numbering, but the existing
non-linux bios works with below topology...

static const unsigned int rows_4p[4][4] = {
    { 0x000b0101, 0x00010202, 0x00030808, 0x00010208 },
    { 0x00010202, 0x00070101, 0x00010204, 0x00030404 },
    { 0x00030404, 0x00010204, 0x00070101, 0x00010202 },
    { 0x00010208, 0x00030808, 0x00010202, 0x000b0101 }
};


NCHT-chain              NCHT-chain
    |                       |
    |                       |
   LDT2                    LDT1
    |                       |
   CPU2 - LDT0 ---- LDT0 - CPU3
    |                       |
   LDT1                    LDT2
    |                       |
    |                       |
    |                       |
   LDT2                    LDT1
    |                       |
   CPU0 - LDT0 ---- LDT0 - CPU1
    |                       |
   LDT1                    LDT2
    |                       |
    |                       |
NCHT-chain              NCHT-chain

> You may try to disable i2c stuff in the amd8111 dir.

Tried this already. Doesn't help. I also tried disabling the link
optimization code, but as one would assume, it does not play in until
softreset, which it never reaches.

> The code works well with S4882 and S4880.

  ... Stefan



From cro_marmot at comcast.net  Tue Nov 30 12:39:00 2004
From: cro_marmot at comcast.net (David Hendricks)
Date: Tue Nov 30 12:39:00 2004
Subject: MATLAB with Clustermatic
In-Reply-To: <Pine.LNX.4.58.0411300945290.19250@linux.site>
References: <41AC9F28.3050807@engr.mun.ca>
	<Pine.LNX.4.58.0411300945290.19250@linux.site>
Message-ID: <20041130155516.724ed0cd@sunder>

Perhaps Matt Sottile can help with this?

On Tue, 30 Nov 2004 09:46:10 -0700 (MST)
"Ronald G. Minnich" <rminnich at lanl.gov> wrote:

> 
> 
> On Tue, 30 Nov 2004, Reza Shahidi wrote:
> 
> >    We have set up Clustermatic 5 on a small five-node cluster, and
> >    want to
> > install a parallel implementation of MATLAB.  Which would you
> > recommend? MATLAB*P and STAR-P looked good, but I haven't been able
> > to find anywhere to download them.  Both ease of coding and running
> > speed are important.  If you have any experience or suggestions,
> > could you respond?
> 
> 
> well, this is the wrong list, but anyway ... it's been years since I
> did parallel matlab, and the licensing costs were the big issue. You
> should try all the ones you can.
> 
> ron
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios


From ebiederman at lnxi.com  Tue Nov 30 18:07:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Nov 30 18:07:01 2004
Subject: get_pbus
In-Reply-To: <3174569B9743D511922F00A0C943142306BA3460@TYANWEB>
References: <3174569B9743D511922F00A0C943142306BA3460@TYANWEB>
Message-ID: <m3k6s2r6jw.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> You mean to access extra reg space (4096 bytes) for PCI-E device?
> 
> We don't need to touch that extra space ....in LinuxBIOS.

So far.  The question is how long will that last.
What firmware has to do especially with onboard hardware
never follows the rules for ordinary hardware.  Especially
when bug workarounds are involved.

> Under LinuxBIOS + kernel + IB driver, the IB adapter works well with S289x.
> need to create one entry in mptable for the device. Otherwise it can not get
> INT.
> 
> Currently I can not make MSI work....Kernel 2.6.

I have not had a chance to play with that.  I saw something on the
openib list a while ago about MSI with a mellanox IB card not having a
complete firmware implementation or something like that.

Eric


From YhLu at tyan.com  Tue Nov 30 18:17:01 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Nov 30 18:17:01 2004
Subject: strange prink_debug output with dev_path
Message-ID: <3174569B9743D511922F00A0C943142306BA3523@TYANWEB>

What is the difference between 
        printk_debug("smbus:  %s[%d]->",  dev_path(dev->bus->dev),
dev->bus->link );
        printk_debug("%s",  dev_path(dev));

and 

        printk_debug("smbus:  %s[%d]->%s",  dev_path(dev->bus->dev),
dev->bus->link ,  dev_path(dev));

the first print 
smbus:  PCI: 01:01.1[0]->I2C: 50

the second one print
smbus:  PCI: 01:01.1[0]-> PCI: 01:01.1

YH