From ts1 at tsn.or.jp Mon Dec 1 02:52:00 2003
From: ts1 at tsn.or.jp (Takeshi Sone)
Date: Mon Dec 1 02:52:00 2003
Subject: Level 2 cache activation code?
In-Reply-To: <1070234054.19232.32.camel@em2.my.own.domain>
References: <1069797381.15097.72.camel@em2.my.own.domain> <1070234054.19232.32.camel@em2.my.own.domain>
Message-ID: <20031201075151.GA32063@tsn.or.jp>
On Mon, Dec 01, 2003 at 12:14:14AM +0100, Svante Signell wrote:
> No speed-up seen. Extremely slow as before. Any hints? mtrr is OK, I
> believe. Is it the microcode??
You could try the microcode driver of Linux or code from LinuxBIOS.
> 3. How to create a kernel module consisting of more than one object
> file. Now I include the needed source files into the main one.
ld -o module.o -r obj1.o obj2.o
--
Takeshi
From niki.waibel at newlogic.com Mon Dec 1 05:45:00 2003
From: niki.waibel at newlogic.com (Niki Waibel)
Date: Mon Dec 1 05:45:00 2003
Subject: v1: epia-m: irq_tables.c, mainboard.c
Message-ID: <200312011044.hB1AiH84011967@enterprise2.newlogic.at>
i think we need a new thread for the ``intel dual netwokcard problem on epia-m'' topic.
facts (correct me if i am wrong!):
* intel dual eth nic is not working with linuxbios (2003-10-24).
* it can be plugged into the pci slot (00:14.0) of the epia-m.
* the dual nic has a pci-to-pci bridge on the card.
* that bridge assignes pci bus 2 (0=internal, 1=vga/agp?)
* the 2 nics on the card assign: 02:04.0 and 02:05.0
* linuxbios detects the bus/bridge and also sees the 2 nic.
!!* linuxbios does not assign irqs to the nics.
* default (2003-10-24) linuxbios src/mainboard/via/epia-m/irq_tables.c:
===
/* This file was generated by getpir.c, do not modify!
(but if you do, please run checkpir on it to verify)
Contains the IRQ Routing Table dumped directly from your memory , wich BIOS sets up
Documentation at : http://www.microsoft.com/hwdev/busbios/PCIIRQ.HTM
*/
#include
const struct irq_routing_table intel_irq_routing_table = {
PIRQ_SIGNATURE, /* u32 signature */
PIRQ_VERSION, /* u16 version */
32+16*5, /* there can be total 5 devices on the bus */
0, /* Where the interrupt router lies (bus) */
0, /* Where the interrupt router lies (dev) */
0x1c20, /* IRQs devoted exclusively to PCI usage */
0, /* Vendor */
0, /* Device */
0, /* Crap (miniport) */
{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, /* u8 rfu[11] */
#if 0
0x58, /* u8 checksum , this hase to set to some value that would give 0 after the sum of all bytes for this st
ructu
re (including checksum) */
{
{0,0xa0, {{0x2, 0xdeb8}, {0x3, 0xdeb8}, {0x4, 0xdeb8}, {0x1, 0xdeb8}}, 0x1, 0},
{0,0x98, {{0x1, 0xdeb8}, {0x2, 0xdeb8}, {0x3, 0xdeb8}, {0x4, 0xdeb8}}, 0x2, 0},
{0,0x50, {{0x4, 0xdeb8}, {0x1, 0xdeb8}, {0x2, 0xdeb8}, {0x3, 0xdeb8}}, 0x3, 0},
{0,0x68, {{0x2, 0xdeb8}, {0x3, 0xdeb8}, {0x4, 0xdeb8}, {0x1, 0xdeb8}}, 0x4, 0},
{0,0x8, {{0x1, 0xdeb8}, {0x2, 0xdeb8}, {0x3, 0xdeb8}, {0x4, 0xdeb8}}, 0, 0},
{0x50,0, {{0, 0}, {0, 0}, {0, 0}, {0, 0}}, 0, 0}
}
#else
0xac, /* u8 checksum , this hase to set to some value that would give 0 after the sum of all bytes for this st
ructu
re (including checksum) */
{
/* ethernet */
{0,0x90, {{0x3, 0xdeb8}, {0x4, 0xdeb8}, {0x2, 0xdeb8}, {0x1, 0xdeb8}}, 0x1, 0},
/* usb */
{0,0x80, {{0x2, 0xdeb8}, {0x3, 0xdeb8}, {0x4, 0xdeb8}, {0x1, 0xdeb8}}, 0x2, 0},
/* pci */
{0,0xa0, {{0x1, 0xdeb8}, {0x4, 0xdeb8}, {0x3, 0xdeb8}, {0x2, 0xdeb8}}, 0x3, 0},
/* audio */
{0,0x8d, {{0x4, 0xdeb8}, {0x3, 0xdeb8}, {0x2, 0xdeb8}, {0x1, 0xdeb8}}, 0x0, 0},
/* 1394 */
{0,0x68, {{0x4, 0xdeb8}, {0x3, 0xdeb8}, {0x2, 0xdeb8}, {0x1, 0xdeb8}}, 0x3, 0}
}
#endif
};
===
* if i run util/getpir/getpir (with the dual eth nic board) i get:
===
/* This file was generated by getpir.c, do not modify!
(but if you do, please run checkpir on it to verify)
Contains the IRQ Routing Table dumped directly from your memory , wich BIOS sets up
Documentation at : http://www.microsoft.com/hwdev/busbios/PCIIRQ.HTM
*/
#include
const struct irq_routing_table intel_irq_routing_table = {
PIRQ_SIGNATURE, /* u32 signature */
PIRQ_VERSION, /* u16 version */
32+16*5, /* there can be total 5 devices on the bus */
0, /* Where the interrupt router lies (bus) */
0, /* Where the interrupt router lies (dev) */
0x1c00, /* IRQs devoted exclusively to PCI usage */
0, /* Vendor */
0, /* Device */
0, /* Crap (miniport) */
{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, /* u8 rfu[11] */
0x78, /* u8 checksum , this hase to set to some value that would give 0 after the sum of all bytes for this st
ructu
re (including checksum) */
{
{0,0xa0, {{0x2, 0xdeb8}, {0x3, 0xdeb8}, {0x4, 0xdeb8}, {0x1, 0xdeb8}}, 0x1, 0},
{0,0x98, {{0x1, 0xdeb8}, {0x2, 0xdeb8}, {0x3, 0xdeb8}, {0x4, 0xdeb8}}, 0x2, 0},
{0,0x50, {{0x4, 0xdeb8}, {0x1, 0xdeb8}, {0x2, 0xdeb8}, {0x3, 0xdeb8}}, 0x3, 0},
{0,0x68, {{0x2, 0xdeb8}, {0x3, 0xdeb8}, {0x4, 0xdeb8}, {0x1, 0xdeb8}}, 0x4, 0},
{0,0x8, {{0x1, 0xdeb8}, {0x2, 0xdeb8}, {0x3, 0xdeb8}, {0x4, 0xdeb8}}, 0, 0},
}
};
===
* it does not help using the new irq_tables.c.
* i had to modify src/mainboard/via/epia-m/mainboard.c in addition to get it running.
--> basically add: ``pci_assign_irqs(2, 0x4, dualenetaIrq); pci_assign_irqs(2, 0x5, dualenetbIrq);''
in addition i had to play with the irq lists.
questions:
* what do the strange numbers in my new irq_table.c mean?
* if everything is hardcoded in mainboard.c -- what is irq_table.c for?
* is it possible that all this is hardcoded in mainboard.c for epia/epia-m only,
but not for other boards?
other boards use irq_table.c to assign interrupts?
* if you plug a card to the pci slot linuxbios seems to detect everything
(devices/bridges/devices behind bridges).
why cannot we say: ok there is irq 5, 10, 11 and 12. assign that 4 irqs
to all devices which were detected in the previous stage.
this must be the way the regular bios does it...
* when booting the epia-m with the std (award) bios and using the getpir
prg -> the resulting irq_table.c does not work either. is it just ignored
by the epia-m setup, or what is it actually for?
niki
From ijpriya at hotmail.com Mon Dec 1 07:52:00 2003
From: ijpriya at hotmail.com (Devi Priya)
Date: Mon Dec 1 07:52:00 2003
Subject: Linuxbios with Diskonchip?
Message-ID:
Hi,
I have Diskonchip millennium MD2800 (8 MB capacity) and Microns SDRAM
capacity (256 Mbits).
Then the flash is to be mapped into the physical address
0xFFFFFFFF-0xFF800000. SDRAM is to mapped into the physical address
0x00000000-0xFE000000. Is this mapping correct?
>From: ron minnich
>To: Devi Priya
>CC: gizara at cox.net,
>Subject: Re: Linuxbios with Diskonchip?
>Date: Sat, 29 Nov 2003 18:35:20 -0700 (MST)
>
>On Fri, 28 Nov 2003, Devi Priya wrote:
>
> > Hi,
> >
> > I am using Diskonchip millennium with boot capability. I just want
>to
> > know if diskonchip is mapped to the high order physical address (at
>reset)
> > and is any remapping is done later?
>
>usually mapped at flash address, right? 0xf0000 and 0xfff00000
>
>ron
>
>_______________________________________________
>Linuxbios mailing list
>Linuxbios at clustermatic.org
>http://www.clustermatic.org/mailman/listinfo/linuxbios
_________________________________________________________________
From rsmith at bitworks.com Mon Dec 1 11:58:01 2003
From: rsmith at bitworks.com (Richard Smith)
Date: Mon Dec 1 11:58:01 2003
Subject: v1: epia-m: irq_tables.c, mainboard.c
In-Reply-To: <200312011044.hB1AiH84011967@enterprise2.newlogic.at>
References: <200312011044.hB1AiH84011967@enterprise2.newlogic.at>
Message-ID: <3FCB72E7.6060109@bitworks.com>
Niki Waibel wrote:
> ===
> /* This file was generated by getpir.c, do not modify!
> (but if you do, please run checkpir on it to verify)
> Contains the IRQ Routing Table dumped directly from your memory , wich BIOS sets up
>
> Documentation at : http://www.microsoft.com/hwdev/busbios/PCIIRQ.HTM
Just FYI this link is going stale... MS currently redirects you to its
new location but who knows how long that will last. Perhaps someone
should save the whitepaper and put it at a location more under our
control. It is useful info.
Unless the ms copywrite forbids this, of course. :)
--
Richard A. Smith
rsmith at bitworks.com
From ebiederman at lnxi.com Mon Dec 1 14:54:01 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Dec 1 14:54:01 2003
Subject: automatic power on possible?
In-Reply-To: <200311272142.21841.thomas@wehrspann.de>
References: <200311272142.21841.thomas@wehrspann.de>
Message-ID: writes:
> Most modern motherboards supports the timer based automatic power on
> via BIOS settings. With linuxbios this is not(?) possible. There is a program
> for linux, called nvram-wakeup, to set the wakeup time in nvram or rtc. But
> especially for the K7SEM or EPIA boards a reboot is needed after it, so the
> wakeup settings can take effect.
> Does anyone know what the BIOS is doing what linuxbios does not?
> Perhaps it can be done in a program?
I believe it is just a matter of programming some real-time clock registers
so an alarm will go off at a specified time, and setting up the
appropriate southbridge or superio bits so that the board will wake up
when the alarm is triggered. I doubt it even requires BIOS support at
all. Though that can't hurt.
Eric
From rminnich at lanl.gov Mon Dec 1 18:29:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Mon Dec 1 18:29:00 2003
Subject: v1: epia-m: irq_tables.c, mainboard.c
In-Reply-To: <200312011044.hB1AiH84011967@enterprise2.newlogic.at>
Message-ID:
On Mon, 1 Dec 2003, Niki Waibel wrote:
> i think we need a new thread for the ``intel dual netwokcard problem on
> epia-m'' topic.
>
OK, I'm now looking at this for real :)
> facts (correct me if i am wrong!):
> * intel dual eth nic is not working with linuxbios (2003-10-24).
> * it can be plugged into the pci slot (00:14.0) of the epia-m.
> * the dual nic has a pci-to-pci bridge on the card.
> * that bridge assignes pci bus 2 (0=internal, 1=vga/agp?)
> * the 2 nics on the card assign: 02:04.0 and 02:05.0
> * linuxbios detects the bus/bridge and also sees the 2 nic.
> !!* linuxbios does not assign irqs to the nics.
> * default (2003-10-24) linuxbios src/mainboard/via/epia-m/irq_tables.c:
ok so far.
> {0,0xa0, {{0x2, 0xdeb8}, {0x3, 0xdeb8}, {0x4, 0xdeb8}, {0x1, 0xdeb8}}, 0x1, 0},
That's 0:14.0, or Bus 0, devfn 0xa0.
> {0,0xa0, {{0x2, 0xdeb8}, {0x3, 0xdeb8}, {0x4, 0xdeb8}, {0x1, 0xdeb8}}, 0x1, 0},
Note that linuxbios and the standard bios agree.
>
> * it does not help using the new irq_tables.c.
which makes sense as the one in there is already correct. My mistake. The
issue is that the card you're using has a bridge on it. I've never dealt
with this before.
> * i had to modify src/mainboard/via/epia-m/mainboard.c in addition to get it running.
> --> basically add: ``pci_assign_irqs(2, 0x4, dualenetaIrq);
> pci_assign_irqs(2, 0x5, dualenetbIrq);''
> in addition i had to play with the irq lists.
eek. You know that this is exactly the wrong way to do this and why, I
assume. But it works, so keep it for now. But this will never go into the
CVS.
>
> questions:
> * what do the strange numbers in my new irq_table.c mean?
doesn't matter, the old one was probably ok.
> * if everything is hardcoded in mainboard.c -- what is irq_table.c for?
irq_table.c is for linux, it tells linux how the irqs are wired up. In an
ideal world, linuxbios would hand the irq table to linux or plan9 or *bsd
and those OSes would do everything correctly. In our world, each of these
OSes get it wrong often enough that we have to now assign it directly. I
had hoped to avoid IRQ assignment in linuxbios but it seems that we have
no choice -- too many busted hardware/OS bits out there.
> * is it possible that all this is hardcoded in mainboard.c for
> epia/epia-m only,
> but not for other boards?
yes.
> other boards use irq_table.c to assign interrupts?
yes. And, *most of the time*, it works fine.
>
* if you plug a card to the pci slot linuxbios seems to detect everything
> (devices/bridges/devices behind bridges).
> why cannot we say: ok there is irq 5, 10, 11 and 12. assign that 4 irqs
> to all devices which were detected in the previous stage.
> this must be the way the regular bios does it...
Yes. We need more complex irq management in linuxbios. Obviously linux
doesn't know what to do here either.
> * when booting the epia-m with the std (award) bios and using the getpir
> prg -> the resulting irq_table.c does not work either. is it
> just ignored
> by the epia-m setup, or what is it actually for?
I don't know what the award bios is doing. It's clear that linux is not
able to handle the interrupt assignmnet in this case, so linuxbios will
have to do more. Oh well. Another thing to add.
ron
From linladn at yahoo.co.in Mon Dec 1 18:36:01 2003
From: linladn at yahoo.co.in (=?iso-8859-1?q?mount=20me?=)
Date: Mon Dec 1 18:36:01 2003
Subject: sst28SF040 sst28SF020 flash memories
In-Reply-To: <20030821123454.S72144-100000@www.missl.cs.umd.edu>
Message-ID: <20031201160747.33422.qmail@web8206.mail.in.yahoo.com>
advantech/pcm-5823 ---> does this use sst28sf040 for
having linux in it ? Or it is going to be
the Etherboot/DOC for booting of the linux ?
Could i get one advantech/pcm-5823 in india ?
Any indians with linuxbios in their board ?
firstboot,
karthik bala guru
________________________________________________________________________
Yahoo! India Mobile: Download the latest polyphonic ringtones.
Go to http://in.mobile.yahoo.com
From YhLu at tyan.com Mon Dec 1 19:59:01 2003
From: YhLu at tyan.com (YhLu)
Date: Mon Dec 1 19:59:01 2003
Subject: Tyan S4880
Message-ID: <3174569B9743D511922F00A0C9431423039907EB@TYANWEB>
Ron,
Please check in the Tyan s2850/2880/2881/2882/4880 updates into the CVS
Tree.
1. northbridge/amd/amdk8/raminit.h: change uint8_t to uint16_t
2. southbridge/amd/amd8111/amd8111_early_smbus.c: update smbus_write_byte
3. southbridge/amd/amd8131/amd8131_bridge.c: update ioapic_anable to enable
PCI-X MASTER Mode.
4. other in /src/mainboard/tyan/ and /targets/tyan
Stefan,
With update 1 and 2, you can get ride of FAKE_SPD_ROM. You need to change
some lines in auto.c for quartet. 1. I2C HUB address: 0x30 --> 0x18, 2.
RC0-> (1<<1)<<8, RC1-> (1<<2)<<8, RC2-> (1<<3)<<8, RC3-> (1<<4)<<8.
Regards
YH.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tyan_1201.change.diff.gz
Type: application/octet-stream
Size: 47193 bytes
Desc: not available
URL:
From rminnich at lanl.gov Mon Dec 1 20:44:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Mon Dec 1 20:44:01 2003
Subject: Tyan S4880
In-Reply-To: <3174569B9743D511922F00A0C9431423039907EB@TYANWEB>
Message-ID:
stefan and eric, we will look at these changes tomorrow. If you get a
chance can you scan them too to make sure no obvious problems exist?
thanks
ron
p.s. Ollie, Greg, and I will be combing linuxbios source this week,
looking at issues and working on integrating the newest LNXI code in as
well as this code.
From rminnich at lanl.gov Mon Dec 1 23:11:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Mon Dec 1 23:11:01 2003
Subject: Tyan S4880
In-Reply-To: <3174569B9743D511922F00A0C9431423039907EB@TYANWEB>
Message-ID:
I committed all this except for one thing:
diff -uNr ./freebios2/src/southbridge/amd/amd8111/amd8111_early_smbus.c ../freebios2/src/southbridge/amd/amd8111/amd8111_early_smbus.c
--- ./freebios2/src/southbridge/amd/amd8111/amd8111_early_smbus.c 2003-10-13 06:01:13.000000000 -0400
+++ ../freebios2/src/southbridge/amd/amd8111/amd8111_early_smbus.c 2003-12-01 16:14:18.000000000 -0500
@@ -120,24 +120,19 @@
return;
}
- /* setup transaction */
- /* disable interrupts */
- outw(inw(SMBUS_IO_BASE + SMBGCTL) & ~((1<<10)|(1<<9)|(1<<8)|(1<<4)),
- SMBUS_IO_BASE + SMBGCTL);
+//By LYH Begin
+ outb(0x37,SMBUS_IO_BASE + SMBGSTATUS);
/* set the device I'm talking too */
- outw(((device & 0x7f) << 1) | 1, SMBUS_IO_BASE + SMBHSTADDR);
- outb(address & 0xFF, SMBUS_IO_BASE + SMBHSTCMD);
- /* set up for a byte data write */ /* FIXME */
- outw((inw(SMBUS_IO_BASE + SMBGCTL) & ~7) | (0x1), SMBUS_IO_BASE + SMBGCTL);
- /* clear any lingering errors, so the transaction will run */
- /* Do I need to write the bits to a 1 to clear an error? */
- outw(inw(SMBUS_IO_BASE + SMBGSTATUS), SMBUS_IO_BASE + SMBGSTATUS);
+ outw(((device & 0x7f) << 1) | 0, SMBUS_IO_BASE + SMBHSTADDR);
+
+ /* data to send */
+ outb(val, SMBUS_IO_BASE + SMBHSTDAT);
- /* clear the data word...*/
- outw(val, SMBUS_IO_BASE + SMBHSTDAT);
+ outb(address & 0xFF, SMBUS_IO_BASE + SMBHSTCMD);
/* start the command */
- outw((inw(SMBUS_IO_BASE + SMBGCTL) | (1 << 3)), SMBUS_IO_BASE + SMBGCTL);
+ outb(0xa, SMBUS_IO_BASE + SMBGCTL);
+//By LYH END
/* poll for transaction completion */
smbus_wait_until_done();
I'm a little worried about removing some of those lines, such as:
/* disable interrupts */
outw(inw(SMBUS_IO_BASE + SMBGCTL) & ~((1<<10)|(1<<9)|(1<<8)|(1<<4)),
SMBUS_IO_BASE + SMBGCTL);
does it hurt to leave this in? OR:
- /* clear any lingering errors, so the transaction will run */
- /* Do I need to write the bits to a 1 to clear an error? */
- outw(inw(SMBUS_IO_BASE + SMBGSTATUS), SMBUS_IO_BASE + SMBGSTATUS);
why remove this?
comments?
ron
From ebiederman at lnxi.com Tue Dec 2 01:09:00 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Dec 2 01:09:00 2003
Subject: Tyan S4880
In-Reply-To:
References:
Message-ID:
ron minnich writes:
> I committed all this except for one thing:
This feels like something brought on by excess register pressure.
Ron one thing you did note was the changing of word accesses to byte
accesses. With romcc that does not help in the case of register pressure.
Usually doing the wrong size register accesses is a bad thing.
Eric
From ebiederman at lnxi.com Tue Dec 2 01:19:01 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Dec 2 01:19:01 2003
Subject: Tyan S4880
In-Reply-To: <3174569B9743D511922F00A0C9431423039907EB@TYANWEB>
References: <3174569B9743D511922F00A0C9431423039907EB@TYANWEB>
Message-ID:
YhLu writes:
> Ron,
>
> Please check in the Tyan s2850/2880/2881/2882/4880 updates into the CVS
> Tree.
>
> 1. northbridge/amd/amdk8/raminit.h: change uint8_t to uint16_t
This is quite reasonable.
> 2. southbridge/amd/amd8111/amd8111_early_smbus.c: update smbus_write_byte
> 3. southbridge/amd/amd8131/amd8131_bridge.c: update ioapic_anable to enable
> PCI-X MASTER Mode.
Why is this necessary? Previously it has been the policy to not set
the master enables any more than is necessary for proper operation
of the devices. Unless I am mistaken not setting the master enables is
very much in spec for pci devices.
> 4. other in /src/mainboard/tyan/ and /targets/tyan
>
> Stefan,
> With update 1 and 2, you can get ride of FAKE_SPD_ROM. You need to change
> some lines in auto.c for quartet. 1. I2C HUB address: 0x30 --> 0x18, 2.
> RC0-> (1<<1)<<8, RC1-> (1<<2)<<8, RC2-> (1<<3)<<8, RC3-> (1<<4)<<8.
Looking at the diffstat output you also touched the quartet/Config.lb and removed
the FAKE_SPD define. Has this been tested?
There is a context diff included in tyan/s2881/lyh.txt that does not look like
it needs to be there.
And of course there were all kinds of binary roms that the diff did not include.
Eric
From ebiederman at lnxi.com Tue Dec 2 01:49:01 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Dec 2 01:49:01 2003
Subject: Tyan S4880
In-Reply-To:
References:
Message-ID:
ron minnich writes:
> stefan and eric, we will look at these changes tomorrow. If you get a
> chance can you scan them too to make sure no obvious problems exist?
>
> thanks
>
> ron
> p.s. Ollie, Greg, and I will be combing linuxbios source this week,
> looking at issues and working on integrating the newest LNXI code in as
> well as this code.
I currently have a very odd issue. I am getting hang ups with B3
stepping cpus with the latest version of the LinuxBIOS tree that I have.
I'm not certain what the problem is, but this will have create a delay
in getting the last of my bug fixes out..
Eric
From stepan at suse.de Tue Dec 2 09:16:00 2003
From: stepan at suse.de (Stefan Reinauer)
Date: Tue Dec 2 09:16:00 2003
Subject: Tyan S4880
In-Reply-To: <3174569B9743D511922F00A0C9431423039907EB@TYANWEB>
References: <3174569B9743D511922F00A0C9431423039907EB@TYANWEB>
Message-ID: <20031202141555.GA19194@suse.de>
* YhLu [031202 02:05]:
> With update 1 and 2, you can get ride of FAKE_SPD_ROM.
> You need to change some lines in auto.c for quartet.
> 1. I2C HUB address: 0x30 --> 0x18,
> 2. RC0-> (1<<1)<<8, RC1-> (1<<2)<<8, RC2-> (1<<3)<<8, RC3-> (1<<4)<<8.
Tried this, doesn't work. I end up with 0KB memory detected on each
CPU. Is it only my Quartets that behave like this?
Stefan
--
Stefan Reinauer, SUSE LINUX AG
Teamleader Architecture Development
From miernik at ctnet.pl Tue Dec 2 09:38:00 2003
From: miernik at ctnet.pl (Miernik)
Date: Tue Dec 2 09:38:00 2003
Subject: LinuxBIOS on laptop - someone can create a custom mainboard!
Message-ID: <20031202143806.GA5688@tarnica.ctnet.pl>
I think you will be interested in this project:
http://www.technoir.nu/libretto/list/2003/msg01557.html
Here he writes "Price really depends on what ICs and bios used":
http://www.technoir.nu/libretto/list/2003/msg01564.html
This would be a really exiting to have a complete custome made
mainboard for a Toshiba Libretto laptop with LinuxBIOS.
--
Miernik ________________________ jabber:miernik at amessage.info
___________________/__ tel: +48608233394 __/ mailto:miernik at ctnet.pl
Sing a declaration against US invasion in Iraq:
http://www.moveon.org/declaration/
From rminnich at lanl.gov Tue Dec 2 11:14:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Tue Dec 2 11:14:01 2003
Subject: Tyan S4880
In-Reply-To:
Message-ID:
On 1 Dec 2003, Eric W. Biederman wrote:
> Ron one thing you did note was the changing of word accesses to byte
> accesses. With romcc that does not help in the case of register pressure.
I would think it would hurt since x86 lets you use those little
sub-registers (puddle arithmetic), so using bigger registers reduces the
number of registers available.
ron
From stepan at suse.de Tue Dec 2 11:21:00 2003
From: stepan at suse.de (Stefan Reinauer)
Date: Tue Dec 2 11:21:00 2003
Subject: Tyan S4880
In-Reply-To:
References:
Message-ID: <20031202162031.GA23768@suse.de>
* ron minnich [031202 17:13]:
> On 1 Dec 2003, Eric W. Biederman wrote:
>
> > Ron one thing you did note was the changing of word accesses to byte
> > accesses. With romcc that does not help in the case of register pressure.
>
> I would think it would hurt since x86 lets you use those little
> sub-registers (puddle arithmetic), so using bigger registers reduces the
> number of registers available.
Yes, being able to use this from romcc would severely lower register
pressure I assume. Neither romcc nor the code compiled with it takes
care of this at the moment though.
Stefan
--
Stefan Reinauer, SUSE LINUX AG
Teamleader Architecture Development
From YhLu at tyan.com Tue Dec 2 12:25:00 2003
From: YhLu at tyan.com (YhLu)
Date: Tue Dec 2 12:25:00 2003
Subject: =?GB2312?B?tPC4tDogVHlhbiBTNDg4MA==?=
Message-ID: <3174569B9743D511922F00A0C943142303990830@TYANWEB>
It should work for quertet.
I compare the schematic of S4880 and quartet, and the SPD_ROM access part is
the same.
You need to update raminit.h and amd8111_early_sumbus.c too.
YH.
-----????-----
???: Stefan Reinauer [mailto:stepan at suse.de]
????: 2003?12?2? 6:16
???: YhLu
??: ron minnich; ebiederman at lnxi.com; linuxbios at clustermatic.org
??: Re: Tyan S4880
* YhLu [031202 02:05]:
> With update 1 and 2, you can get ride of FAKE_SPD_ROM.
> You need to change some lines in auto.c for quartet.
> 1. I2C HUB address: 0x30 --> 0x18,
> 2. RC0-> (1<<1)<<8, RC1-> (1<<2)<<8, RC2-> (1<<3)<<8, RC3-> (1<<4)<<8.
Tried this, doesn't work. I end up with 0KB memory detected on each
CPU. Is it only my Quartets that behave like this?
Stefan
--
Stefan Reinauer, SUSE LINUX AG
Teamleader Architecture Development
From YhLu at tyan.com Tue Dec 2 12:29:01 2003
From: YhLu at tyan.com (YhLu)
Date: Tue Dec 2 12:29:01 2003
Subject: =?GB2312?B?tPC4tDogVHlhbiBTNDg4MA==?=
Message-ID: <3174569B9743D511922F00A0C943142303990833@TYANWEB>
>> 3. southbridge/amd/amd8131/amd8131_bridge.c: update ioapic_anable to
enable
>> PCI-X MASTER Mode.
>Why is this necessary? Previously it has been the policy to not set
>the master enables any more than is necessary for proper operation
>of the devices. Unless I am mistaken not setting the master enables is
>very much in spec for pci devices.
Eric,
Otherwise I can not use LAN and SCSI devices in PCI-X in Linux.
For Broadcom NIC, I can not ifconfig and ping.
For SCSI, I just can not get through the SCSI initialize in Linux kernel.
YH.
From stepan at suse.de Tue Dec 2 13:01:01 2003
From: stepan at suse.de (Stefan Reinauer)
Date: Tue Dec 2 13:01:01 2003
Subject: ????: Tyan S4880
In-Reply-To: <3174569B9743D511922F00A0C943142303990830@TYANWEB>
References: <3174569B9743D511922F00A0C943142303990830@TYANWEB>
Message-ID: <20031202180030.GA24716@suse.de>
* YhLu [031202 18:32]:
> It should work for quertet.
>
> I compare the schematic of S4880 and quartet, and the SPD_ROM access part is
> the same.
>
> You need to update raminit.h and amd8111_early_sumbus.c too.
Aaah. I found the culprit. All SMBus addresses have to be shifted right
by one compared to what the data sheet says. I forgot to do this for the
DIMM modules.
I checked your changes to amd8111_early_smbus.c into the freebios2 tree.
I still can't see the onboard network adapter, even with only 3G in the
machine. So I'll try the PCI-X master changes here as well.
Thanks a lot, Yinghai!
Stefan
--
Stefan Reinauer, SUSE LINUX AG
Teamleader Architecture Development
From ebiederman at lnxi.com Tue Dec 2 14:20:01 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Dec 2 14:20:01 2003
Subject: =?gb2312?b?tPC4tA==?=: Tyan S4880
In-Reply-To: <3174569B9743D511922F00A0C943142303990833@TYANWEB>
References: <3174569B9743D511922F00A0C943142303990833@TYANWEB>
Message-ID:
YhLu writes:
> >> 3. southbridge/amd/amd8131/amd8131_bridge.c: update ioapic_anable to
> enable
> >> PCI-X MASTER Mode.
>
> >Why is this necessary? Previously it has been the policy to not set
> >the master enables any more than is necessary for proper operation
> >of the devices. Unless I am mistaken not setting the master enables is
> >very much in spec for pci devices.
>
> Eric,
>
> Otherwise I can not use LAN and SCSI devices in PCI-X in Linux.
> For Broadcom NIC, I can not ifconfig and ping.
> For SCSI, I just can not get through the SCSI initialize in Linux kernel.
Hmm. Very odd. This has not been my experience so I want
to confirm we are communicating clearly.
We are talking about pci configuration space byte register 4, bit 2
which has a value of 0x4. bit 1 memory space enable of that
byte our generic code should already be setting if the device has
any memory resources.
Linux drivers are expected to call pci_set_master() which sets
this bit before performing DMA transactions. Any driver that does
not is buggy.
I believe we are talking about the general case of setting
these bits, not the specific instance of the 8131 ioapic.
And unless I am highly mistaken this all applies to pci
devices in general not just pci-X devices.'
So I can check out the possibility of buggy kernel drivers YH which
kernel and which drivers are you using. tg3 or bcm??? for the
broadcom nic.
In the general case if we are going to do this we should set
this bit in the pci layer so it always gets set and not set
it for the individual devices.
.......
Looking at the specific case of the amd8131, the documentation says
unless master enable is set it will not generate interrupts. I would
not see this problem on the HDAMA because it's interrupts are poorly
wired and do not actually use the ioapic on the 8131, instead they
all goto the 8111.
IOAPICs are a case of architectural hardware. Architectural hardware
is generally driven by generic drivers so it need to be configured to
act exactly as specified in the architecture. To do that in this
specific case we do need set the master enable, or we will not
generate interrupts.
Eric
From YhLu at tyan.com Tue Dec 2 14:31:01 2003
From: YhLu at tyan.com (YhLu)
Date: Tue Dec 2 14:31:01 2003
Subject: Tyan S4880
Message-ID: <3174569B9743D511922F00A0C943142303990875@TYANWEB>
Eric,
The Kernel is used 2.4.22 and I compiled it in ADM64 mode.
The LAN device is Broadcom 5704 and driver should be tg3.
The SCSI device (LSI SCSI 53c1030 -- onboard and Adaptec 29320 addon card)
all can not be initialized in Linux Kernal.
Regards
YH.
From ebiederman at lnxi.com Tue Dec 2 16:23:00 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Dec 2 16:23:00 2003
Subject: config -> default
In-Reply-To:
References:
Message-ID:
ron minnich writes:
> this fixup is at the top of next week's list now that sc '03 is over.
>
> sc '03 is a major event that pretty much eats up nov. for us, so sorry for
> the inconvenience.
Any head way on this. Especially the formulas which look
like they will need a second pass to get right?
And of course we still have some dependency problems with
the makefiles.
I'm not quite there but this is quickly becoming and itch I want
to scratch, unless someone is working on this.
Eric
From gwatson at lanl.gov Tue Dec 2 16:38:00 2003
From: gwatson at lanl.gov (Greg Watson)
Date: Tue Dec 2 16:38:00 2003
Subject: config -> default
In-Reply-To:
References:
Message-ID:
I'm looking at it.
Greg
At 2:27 PM -0700 12/2/03, Eric W. Biederman wrote:
>ron minnich writes:
>
>> this fixup is at the top of next week's list now that sc '03 is over.
>>
>> sc '03 is a major event that pretty much eats up nov. for us, so sorry for
>> the inconvenience.
>
>Any head way on this. Especially the formulas which look
>like they will need a second pass to get right?
>
>And of course we still have some dependency problems with
>the makefiles.
>
>I'm not quite there but this is quickly becoming and itch I want
>to scratch, unless someone is working on this.
>
>Eric
>_______________________________________________
>Linuxbios mailing list
>Linuxbios at clustermatic.org
>http://www.clustermatic.org/mailman/listinfo/linuxbios
From mirenna at mi.ingv.it Wed Dec 3 04:34:00 2003
From: mirenna at mi.ingv.it (Santi Mirenna)
Date: Wed Dec 3 04:34:00 2003
Subject: Help on epia-m 10000 linuxbios VGA
Message-ID: <5.1.1.6.2.20031203103153.021e2108@10.1.1.8>
Hi to all, today i make EPIA-M 10000 rom image. i compile to have VGA and
Filo,
after apply patch of Dave Ashley and info from Takeshi about RAM ammount
VGA now is found by the system but ....
In attach you have the output log ....
Can someone tell me where i wrong?
Dave Ashley reply:
You haven't applied all the patch, specifically the handler
for the unsupported bios interrupts.
This is the bug where it just gets into an endless loop
of bios interrupts, so the program needs to exit the
bios somehow. -Dave
Hi , can some one tell me where to look ....
i made the patch ....where to look Dave to know if the patch is ok ?
Thanks.
Santi Mirenna
-------------- next part --------------
LinuxBIOS-1.0.0 Thu Nov 27 12:28:35 CET 2003 starting...
RB?0
LinuxBIOS-1.0.0 Thu Nov 27 12:28:35 CET 2003 starting...
80 08 07 0d 0a 01 40 00 04 60 70 00 82 08 00 01
0e 04 0c 01 02 20 00 75 70 00 00 48 30 48 2a 40
75 75 45 45 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0a
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Copying LinuxBIOS to ram.
Jumping to LinuxBIOS.
LinuxBIOS-1.0.0 Thu Nov 27 12:28:35 CET 2003 booting...
Finding PCI configuration type.
PCI: Using configuration type 1
Scanning PCI bus...PCI: pci_scan_bus for bus 0
PCI: 00:00.0 [1106/3123]
PCI: 00:01.0 [1106/b091]
PCI: 00:0d.0 [1106/3044]
PCI: 00:10.0 [1106/3038]
PCI: 00:10.1 [1106/3038]
PCI: 00:10.2 [1106/3038]
PCI: 00:10.3 [1106/3104]
PCI: 00:11.0 [1106/3177]
PCI: 00:11.1 [1106/0571]
PCI: 00:11.5 [1106/3059]
PCI: 00:12.0 [1106/3065]
PCI: pci_scan_bus for bus 1
PCI: 01:00.0 [1106/3122]
PCI: pci_scan_bus returning with max=01
PCI: pci_scan_bus returning with max=01
done
Allocating PCI resources...
PCI: 00:00.0 register 10(00000008), read-only ignoring it
PCI: 00:00.0 register 10(00000008), read-only ignoring it
PCI: 00:00.0 register 10(00000008), read-only ignoring it
PCI: 00:00.0 register 10(00000008), read-only ignoring it
ASSIGN RESOURCES, bus 0
PCI: 00:01.0 1c
Hi,
I could not find any ipl code for sc1200 (nano mainboard). Which should I
mention in the config file for docipl? Please give me suggestion.
Thanks in advance.
_________________________________________________________________
Contact brides & grooms FREE! Only on www.shaadi.com.
http://www.shaadi.com/ptnr.php?ptnr=hmltag Register now!
From stepan at suse.de Wed Dec 3 05:37:00 2003
From: stepan at suse.de (Stefan Reinauer)
Date: Wed Dec 3 05:37:00 2003
Subject: Diskonchip ipl code for sc1200?
In-Reply-To:
References:
Message-ID: <20031203103637.GA28257@suse.de>
* Devi Priya [031203 10:53]:
> Hi,
>
> I could not find any ipl code for sc1200 (nano mainboard). Which should I
> mention in the config file for docipl? Please give me suggestion.
Have you looked at freebios/src/mainboard/nano/nano ?
It contains sample configuration files..
Stefan
--
Stefan Reinauer, SUSE LINUX AG
Teamleader Architecture Development
From ian at abelon.com Wed Dec 3 06:00:01 2003
From: ian at abelon.com (Ian Smith)
Date: Wed Dec 3 06:00:01 2003
Subject: Help on epia-m 10000 linuxbios VGA
In-Reply-To: <5.1.1.6.2.20031203103153.021e2108@10.1.1.8>
References: <5.1.1.6.2.20031203103153.021e2108@10.1.1.8>
Message-ID: <6.0.1.1.2.20031203104904.02b71900@mail.abelon.com>
An HTML attachment was scrubbed...
URL:
From mirenna at mi.ingv.it Wed Dec 3 09:15:01 2003
From: mirenna at mi.ingv.it (Santi Mirenna)
Date: Wed Dec 3 09:15:01 2003
Subject: Help on epia-m 10000 linuxbios VGA
Message-ID: <5.1.1.6.2.20031203151229.06182e18@10.1.1.8>
At 11.59 03/12/2003, you wrote:
>Hi Santi,
>
>At a minimum you need to check that your arch/i386/lib/idt.c file has the
>Int 21 and Unsupported Interrupt handler calling code installed:
>
>@@ -175,9 +175,18 @@
> eax = 64 * 1024;
> ret = 0;
> break;
>+#ifdef CONFIG_INT21HANDLER
>+ case 0x15:
>+ ret=handleint21( &edi, &esi, &ebp, &esp,
>+ &ebx, &edx, &ecx, &eax, &flags);
>+ break;
>+#endif
> default:
> printk_info(__FUNCTION__ ": Unsupport int #0x%x\n",
> intnumber);
>+#ifdef CONFIG_UNSUPPORTINT_RECOVER
>+ unsupportint_recover();
>+#endif
> break;
>
>
>and that arch/i386/lib/vgabios.c and mainboard/via/epia-m/mainboard.c
>respectively have the actual handler routines:
>
>@@ -145,6 +145,13 @@
> __asm__ (".text\n""real_mode_switch_end:\n");
> extern char real_mode_switch_end[];
>
>+#ifdef CONFIG_UNSUPPORTINT_RECOVER
>+void unsupportint_recover(void)
>+{
>+ __asm__ __volatile__ ( " jmp vgarestart \n" );
>+}
>+#endif
>+
>
>and
>
>@@ -92,3 +176,33 @@
> final_southbridge_fixup();
> }
>
>+int handleint21( unsigned long *edi, unsigned long *esi, unsigned long *ebp,
>+ unsigned long *esp, unsigned long *ebx, unsigned
>long *edx,
>+ unsigned long *ecx, unsigned long *eax, unsigned
>long *flags)
>+{
>+int res=-1;
>+ switch(*eax&0xffff)
>+ {
>+ case 0x5f19:
>+ break;
>+ case 0x5f18:
>+ *eax=0x5f;
>+ *ebx=0x15; // MCLK = 133, 32M frame buffer
>+ res=0;
>+ break;
>+ case 0x5f02:
>+ *eax=0x5f;
>+ *ebx=0 | (3<<8);
>+ *ecx=5 | (0<<8) | (0<<16);
>+ res=0;
>+ break;
>+ case 0x5f0f:
>+ *eax=0x5f;
>+ *ebx=0;
>+ *ecx=0;
>+ *edx=0;
>+ res=0;
>+ break;
>+ }
>+ return res;
>+}
>
>
>NOTE: It's possible that you may have patch these in by hand as the
>original diffs were from an older version of the codebase and things may
>have changed since then.
All the patch is ok and I get the CVS of 05 2003-July
>A quick check is to make sure there are no *.rej files present which might
>indicate a patch operation has failed.
all files are patched
>The diffs aren't large, so it's probably worthing checking them by hand to
>make sure the patches have been properly applied.
>
>Cheers
>
>Ian
>
>At 09:31 03/12/2003, Santi Mirenna wrote:
>>Hi to all, today i make EPIA-M 10000 rom image. i compile to have VGA and
>>Filo,
>>after apply patch of Dave Ashley and info from Takeshi about RAM ammount
>>VGA now is found by the system but ....
>>In attach you have the output log ....
>>Can someone tell me where i wrong?
>>
>>Dave Ashley reply:
>>
>>You haven't applied all the patch, specifically the handler
>>for the unsupported bios interrupts.
>>This is the bug where it just gets into an endless loop
>>of bios interrupts, so the program needs to exit the
>>bios somehow. -Dave
>>
>>Hi , can some one tell me where to look ....
>>i made the patch ....where to look Dave to know if the patch is ok ?
>>
>>Thanks.
>>
>>Santi Mirenna
From rminnich at lanl.gov Wed Dec 3 09:34:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Wed Dec 3 09:34:01 2003
Subject: Help on epia-m 10000 linuxbios VGA
In-Reply-To: <5.1.1.6.2.20031203103153.021e2108@10.1.1.8>
Message-ID:
can somebody write a HOWTO for this? people are really getting lost.
ron
From rminnich at lanl.gov Wed Dec 3 09:34:30 2003
From: rminnich at lanl.gov (ron minnich)
Date: Wed Dec 3 09:34:30 2003
Subject: Diskonchip ipl code for sc1200?
In-Reply-To:
Message-ID:
On Wed, 3 Dec 2003, Devi Priya wrote:
> I could not find any ipl code for sc1200 (nano mainboard). Which should I
> mention in the config file for docipl? Please give me suggestion.
you'll have to write it.
ron
From rminnich at lanl.gov Wed Dec 3 11:43:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Wed Dec 3 11:43:00 2003
Subject: arima hdama success
Message-ID:
as of this morning, with Yh Lu's changes, arima hdama builds work fine.
ron
From rminnich at lanl.gov Wed Dec 3 12:16:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Wed Dec 3 12:16:01 2003
Subject: config -> default
In-Reply-To:
Message-ID:
On 2 Dec 2003, Eric W. Biederman wrote:
> Any head way on this. Especially the formulas which look
> like they will need a second pass to get right?
it's moving.
> I'm not quite there but this is quickly becoming and itch I want
> to scratch, unless someone is working on this.
I would rather not see the old stuff re-appear that put perl eval commands
into the makefile. I had linuxbios builds down to 10 seconds at one point,
but it is creeping up again as people put stuff like this in:
export LINUXBIOS_BUILD:=$(shell date)
export LINUXBIOS_COMPILE_TIME:=$(shell date +%T)
export LINUXBIOS_COMPILE_BY:=$(shell whoami)
export LINUXBIOS_COMPILE_HOST:=$(shell hostname)
export LINUXBIOS_COMPILE_DOMAIN:=$(shell dnsdomainname)
export LINUXBIOS_COMPILER:=$(shell $(CC) $(CFLAGS) -v 2>&1 | tail -n 1)
export LINUXBIOS_LINKER:=$(shell $(CC) -Wl,-v 2>&1 | grep version | tail
-n 1)
export LINUXBIOS_ASSEMBLER:=$(shell touch dummy.s ; $(CC) -c -Wa,-v
dummy.s 2>&
1; rm -f dummy.s dummy.o )
I find the LINUXBIOS_ASSEMBLER one fairly distressing. Also, the
'dnsdomainname' has caused trouble in the past on machines which are not
using dns (these do exist).
ron
From stepan at suse.de Wed Dec 3 16:48:01 2003
From: stepan at suse.de (Stefan Reinauer)
Date: Wed Dec 3 16:48:01 2003
Subject: irq tables generation
Message-ID: <20031203214831.GB2254@suse.de>
Hi,
* ron minnich [031202 00:28]:
> > {0,0xa0, {{0x2, 0xdeb8}, {0x3, 0xdeb8}, {0x4, 0xdeb8}, {0x1, 0xdeb8}}, 0x1, 0},
>
> > pci_assign_irqs(2, 0x5, dualenetbIrq);''
> > in addition i had to play with the irq lists.
>
> eek. You know that this is exactly the wrong way to do this and why, I
> assume. But it works, so keep it for now. But this will never go into the
> CVS.
Do we agree that interrupts should be _unassigned_ during firmware
execution and set by the OS only? Another way of handling this might be
to set some default values and allow the OS to reconfigure those.
A PIRQ-Table has to contain
* one entry for each PCI device that needs an interrupt
* one entry for each peer bus to be visible.
It seems we know these parameters in-system already and can generate a
valid table assuming some fixed parameters (cycling interrupts a la
{{0x2, 0xdeb8}, {0x3, 0xdeb8}, {0x4, 0xdeb8}, {0x1, 0xdeb8}}
and a fixed mask of 0xdeb8.
> irq_table.c is for linux, it tells linux how the irqs are wired up. In an
> ideal world, linuxbios would hand the irq table to linux or plan9 or *bsd
> and those OSes would do everything correctly. In our world, each of these
> OSes get it wrong often enough that we have to now assign it directly. I
> had hoped to avoid IRQ assignment in linuxbios but it seems that we have
> no choice -- too many busted hardware/OS bits out there.
Not to forget the mptable - that contains additional information on
which busses are available - information that Linux obviously don't like
to read from there but from the irq table.
Stefan
--
Stefan Reinauer, SUSE LINUX AG
Teamleader Architecture Development
From rminnich at lanl.gov Wed Dec 3 17:05:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Wed Dec 3 17:05:01 2003
Subject: irq tables generation
In-Reply-To: <20031203214831.GB2254@suse.de>
Message-ID:
On Wed, 3 Dec 2003, Stefan Reinauer wrote:
> Do we agree that interrupts should be _unassigned_ during firmware
> execution and set by the OS only? Another way of handling this might be
> to set some default values and allow the OS to reconfigure those.
I am finding that OSes are really dumb, in general. Much to my regret, we
are going to have to assign these in linuxbios. It won't be 100% reliable
otherwise.
> Not to forget the mptable - that contains additional information on
> which busses are available - information that Linux obviously don't like
> to read from there but from the irq table.
in SMP mode, the mptable is used. In UP mode with IO-APIC support, the
mptable is used, But in Old Fashioned 1981 PC mode, the IRQ table is used
and the MPTABLE ignored.
what a mess.
ron
From stepan at suse.de Wed Dec 3 17:50:00 2003
From: stepan at suse.de (Stefan Reinauer)
Date: Wed Dec 3 17:50:00 2003
Subject: irq tables generation
In-Reply-To:
References: <20031203214831.GB2254@suse.de>
Message-ID: <20031203225021.GA2359@suse.de>
* ron minnich [031203 23:05]:
> I am finding that OSes are really dumb, in general. Much to my regret, we
> are going to have to assign these in linuxbios. It won't be 100% reliable
> otherwise.
It seems this does not add a lot of complexity, especially compared to
providing all these tables to different OSes, but I might be wrong.
> in SMP mode, the mptable is used. In UP mode with IO-APIC support, the
> mptable is used, But in Old Fashioned 1981 PC mode, the IRQ table is used
> and the MPTABLE ignored.
>
> what a mess.
It's even better. Linux kernels compiled for x86_64 always use the
IO-APIC. Still we need to add the peer bus 1 to the irq table so see
the bus in Linux which could use the mptable to detect busses as well.
Why I don't know.
Stefan
--
Stefan Reinauer, SUSE LINUX AG
Teamleader Architecture Development
From YhLu at tyan.com Wed Dec 3 21:26:01 2003
From: YhLu at tyan.com (YhLu)
Date: Wed Dec 3 21:26:01 2003
Subject: Tyan S2885
Message-ID: <3174569B9743D511922F00A0C9431423039909D4@TYANWEB>
Eric,
I found in amdk8_scan_root_bus in northbridge/amd/amdk8/northbridge.c
You put
/* Unmap all of the other pci busses */
for(reg = 0xe0; reg <= 0xec; reg += 4) {
f1_write_config32(reg, 0);
}
Why you need to clear that? After you clear that, I can not see the 8151 and
AGP in s2885.
PS:
I have reversed the scan sequence to make sure HT scan 8111 at first and
then 8151.
Regards
Yinghai Lu
From YhLu at tyan.com Wed Dec 3 21:29:01 2003
From: YhLu at tyan.com (YhLu)
Date: Wed Dec 3 21:29:01 2003
Subject: Tyan S2885
Message-ID: <3174569B9743D511922F00A0C9431423039909D5@TYANWEB>
Output
-----????-----
???: YhLu
????: 2003?12?3? 18:34
???: YhLu; ebiederman at lnxi.com
??: ron minnich; Stefan Reinauer; linuxbios at clustermatic.org
??: Tyan S2885
Eric,
I found in amdk8_scan_root_bus in northbridge/amd/amdk8/northbridge.c
You put
/* Unmap all of the other pci busses */
for(reg = 0xe0; reg <= 0xec; reg += 4) {
f1_write_config32(reg, 0);
}
Why you need to clear that? After you clear that, I can not see the 8151 and
AGP in s2885.
PS:
I have reversed the scan sequence to make sure HT scan 8111 at first and
then 8151.
Regards
Yinghai Lu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: s2885_out_put.zip
Type: application/octet-stream
Size: 22825 bytes
Desc: not available
URL:
From ijpriya at hotmail.com Wed Dec 3 21:43:00 2003
From: ijpriya at hotmail.com (Devi Priya)
Date: Wed Dec 3 21:43:00 2003
Subject: Filesystem for doc?
Message-ID:
Hi,
Which filesystem should I use for diskonchip? Should I use ths True FFS
or can I use the NFTL?
_________________________________________________________________
Love shopping online? Get this e credit card.
http://server1.msn.co.in/features/amex/ Save cost, add value!
From ijpriya at hotmail.com Wed Dec 3 22:39:01 2003
From: ijpriya at hotmail.com (Devi Priya)
Date: Wed Dec 3 22:39:01 2003
Subject: Diskonchip ipl code for sc1200?
Message-ID:
Hi,
Thanks for ur suggestion. Should I write both ipl code for the chipset
and the DOCM? Should I also write the SPL code for chipset and DOCM? Can I
use the ipl and spl code given with the xpressloader BootLoader Development
Kit?
>From: ron minnich
>To: Devi Priya
>CC: linuxbios at clustermatic.org
>Subject: Re: Diskonchip ipl code for sc1200?
>Date: Wed, 3 Dec 2003 07:34:03 -0700 (MST)
>
>On Wed, 3 Dec 2003, Devi Priya wrote:
>
> > I could not find any ipl code for sc1200 (nano mainboard). Which
>should I
> > mention in the config file for docipl? Please give me suggestion.
>
>you'll have to write it.
>
>ron
>
>_______________________________________________
>Linuxbios mailing list
>Linuxbios at clustermatic.org
>http://www.clustermatic.org/mailman/listinfo/linuxbios
_________________________________________________________________
It is Ms World time! Send in your wishes to Ami Vashi.
http://server1.msn.co.in/sp03/Missworld2003/ Help her bring home the crown!
From rminnich at lanl.gov Wed Dec 3 23:07:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Wed Dec 3 23:07:00 2003
Subject: Diskonchip ipl code for sc1200?
In-Reply-To:
Message-ID:
On Thu, 4 Dec 2003, Devi Priya wrote:
> Thanks for ur suggestion. Should I write both ipl code for the chipset
> and the DOCM? Should I also write the SPL code for chipset and DOCM? Can I
> use the ipl and spl code given with the xpressloader BootLoader Development
> Kit?
when I did this for VIA 8601 I adapted the code for ipl.S from sis 630. I
think you should try that.
ron
From ijpriya at hotmail.com Thu Dec 4 08:44:00 2003
From: ijpriya at hotmail.com (Devi Priya)
Date: Thu Dec 4 08:44:00 2003
Subject: Doubt with Diskonchip millennium?
Message-ID:
Hi,
In the application note (AP044) from Msystems diskonchip it is given
as:
"The DiskOnChip Millennium is mapped into an 8KB memory window in the host
platform?s
memory map. This 8KB window consists of four 2KB windows." Why is this
mapping done?
Is this done for all the DiskOnChip Millennium?
The steps for BIOS is summarised as
1. After DiskOnChip Millennium BUSY# signal is negated, the CPU fetches the
Reset Vector from
the Boot-Block area, fetches the Boot Code stored there, and starts to
execute the code.
2. Boot Code runs the first part of BIOS, initializing the basic hardware
functionality.
3. Boot Codes loads the rest of the BIOS from the flash memory to the DRAM,
and transfer control
(jumps) there.
4. Chip Select of DiskOnChip Millennium is remapped from Reset Vector to
BIOS expansion area.
5. CPU executes the rest of the BIOS code, including ROM expansion devices
(among them, the
DiskOnChip Millennium itself).
6. CPU calls OS bootstrap loader (INT19).
7. OS is loaded, and recognizes the DiskOnChip Millennium as the boot
device.
8. OS loads the application code from the DiskOnChip Millennium and executes
it.
9. Application software uses DiskOnChip Millennium exactly as if it were
using a regular hard disk.
In step 4 why is this remapping done
_________________________________________________________________
Shop online for kids? toys by age group, price range, and toy category at
MSN Shopping. No waiting for a clerk to help you! http://shopping.msn.com
From svante.signell at telia.com Thu Dec 4 10:37:00 2003
From: svante.signell at telia.com (Svante Signell)
Date: Thu Dec 4 10:37:00 2003
Subject: Level 2 cache activation code?
In-Reply-To: <00de01c3b79c$5afc6f20$0701000a@techmanager>
References:
<1069797381.15097.72.camel@em2.my.own.domain>
<1070234054.19232.32.camel@em2.my.own.domain>
<00de01c3b79c$5afc6f20$0701000a@techmanager>
Message-ID: <1070552214.1433.36.camel@em2.my.own.domain>
On Mon, 2003-12-01 at 00:47, Denis Dowling wrote:
> Hi Svante,
>
> ----- Original Message -----
> From: "Svante Signell"
> To: "ron minnich"
> Cc: "Takeshi Sone" ;
> Sent: Monday, December 01, 2003 10:14 AM
> Subject: Re: Level 2 cache activation code?
> >
> > The processor is an 1.3GHz Celeron Tualatin, with CPUID: 6b0. According
> > to the code in l2_cache.c newer CPUs than Coppermine (680) does not need
> > the L2 setup code. Is this the case?
>
> This was based on the assumption that all CPU from the coppermine forward
> had the cache integrated onto the CPU die. Is this the case with your CPU.
> Is it just a single large CPU on the slot1 pcb or does there look to be
> cache chips mounted on the board as well?
The CPU is placed on a socket 370 to slot 1 adapter (SLOT-T) from Upgradeware.
No, there are no external cache chips on the MOBO. BTW, the MOBO is a dual CPU 82443BX
board (MSI-6120). It runs perfectly well with dual Celerons (Mendocino). Also, the CPU
placed on the SLOT-T adapter works perfectly well with other (single CPU) boards.
> > if (signature < 0x630 || signature >= 0x680) {
> > printk_debug("CPU signature of %x so no L2 cache configuration\n",
> > signature);
> > goto done;
>
> You could always just drop this test and see what happens later. If the CPU
> does have external cache chips then this code might just work in
> initiallising the cache.
I have disabled the test and it seems the cache activation seem to work,
see below. The slowness remains however :-(
Dec 4 14:39:56 cl-dual kernel: Configuring L2 cache...Disable Cache
Dec 4 14:39:56 cl-dual kernel: rdmsr(0x17) = 0, 84320000
Dec 4 14:39:56 cl-dual kernel: L2 Cache latency is 1
Dec 4 14:39:56 cl-dual kernel: Sending 0 to set_l2_register4
Dec 4 14:39:56 cl-dual kernel: L2 ECC Checking is enabled
Dec 4 14:39:56 cl-dual kernel: L2 Physical Address Range is 512M
Dec 4 14:39:56 cl-dual kernel: Maximum cache mask is 2000
Dec 4 14:39:56 cl-dual kernel: L2 Cache Mask is 0
Dec 4 14:39:56 cl-dual kernel: read_l2(2) = 0
Dec 4 14:39:56 cl-dual kernel: write_l2(2) = 0
Dec 4 14:39:56 cl-dual kernel: Enable Cache
Dec 4 14:39:56 cl-dual kernel: L2 Cache size is 256K
Dec 4 14:39:56 cl-dual kernel: L2 Cache lines initialized
Dec 4 14:39:56 cl-dual kernel: Disable Cache
Dec 4 14:39:56 cl-dual kernel: Enable Cache
Dec 4 14:39:56 cl-dual kernel: done.
Dec 4 14:39:56 cl-dual kernel: cache_on installed
> Looks fine. Turn on as much debugging in the l2_cache code as possible and
> post to me and I will decode. Need to be able to see all of the printk_debug
> messages.
>
> Regards,
> Denis
What is wrong here:
Not caches
Not mtrr
microcode??
anything else??
HW fault, i.e. the VRM does not work as expected, even though lm-sensors
are reporting correct voltages.
The BIOS is not supporting Coppermine and later CPUs. AMI BIOS V2.0 from
(MSI)
Soon giving up...
From ebiederman at lnxi.com Fri Dec 5 00:31:01 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Dec 5 00:31:01 2003
Subject: Tyan S2885
In-Reply-To: <3174569B9743D511922F00A0C9431423039909D4@TYANWEB>
References: <3174569B9743D511922F00A0C9431423039909D4@TYANWEB>
Message-ID:
YhLu writes:
> Eric,
>
> I found in amdk8_scan_root_bus in northbridge/amd/amdk8/northbridge.c
> You put
> /* Unmap all of the other pci busses */
> for(reg = 0xe0; reg <= 0xec; reg += 4) {
> f1_write_config32(reg, 0);
> }
>
> Why you need to clear that? After you clear that, I can not see the 8151 and
> AGP in s2885.
Hmm. This looks like a thinko.
So right now the code says:
unsigned int amdk8_scan_root_bus(device_t root, unsigned int max)
{
unsigned reg;
max = pci_scan_bus(&root->link[0], PCI_DEVFN(0x18, 0), 0xff, max);
/* Unmap all of the other pci busses */
for(reg = 0xe0; reg <= 0xec; reg += 4) {
f1_write_config32(reg, 0);
}
return max;
}
And I think what I meant was:
unsigned int amdk8_scan_root_bus(device_t root, unsigned int max)
{
unsigned reg;
/* Unmap all of the other pci busses */
for(reg = 0xe0; reg <= 0xec; reg += 4) {
f1_write_config32(reg, 0);
}
max = pci_scan_bus(&root->link[0], PCI_DEVFN(0x18, 0), 0xff, max);
return max;
}
I don't have a clue why it works at all with clearing those registers after
the pci bus scan.
I wonder if that is the reason scan order matters because I don't
clear those registers out first and things are dual mapped.
Anyway my intention was to be very careful and to clear the HT chain
mapping registers before we scanned them so we didn't have any old
configurations getting in the way.
Eric
From ebiederman at lnxi.com Fri Dec 5 01:17:00 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Dec 5 01:17:00 2003
Subject: Romcc Ramblings...
In-Reply-To: <20031202162031.GA23768@suse.de>
References:
<20031202162031.GA23768@suse.de>
Message-ID:
Stefan Reinauer writes:
> * ron minnich [031202 17:13]:
> > On 1 Dec 2003, Eric W. Biederman wrote:
> >
> > > Ron one thing you did note was the changing of word accesses to byte
> > > accesses. With romcc that does not help in the case of register pressure.
> >
> > I would think it would hurt since x86 lets you use those little
> > sub-registers (puddle arithmetic), so using bigger registers reduces the
> > number of registers available.
>
> Yes, being able to use this from romcc would severely lower register
> pressure I assume. Neither romcc nor the code compiled with it takes
> care of this at the moment though.
I tried this at one point. And the problem is that there
is not a instruction sequence to move to/from the byte registers
from a normal 32bit register. Which negates most of the benefit of
the extra registers. 64bit mode on the Opteron gets byte register correct
but it no longer has more than one byte register per general purpose register.
Getting in support for mmx and sse registers was much more beneficial.
16 more instead of just 4.
A more general purpose technique is to use bit-fields. I am close to having
bit-fields implemented in my backburner version of romcc. I have some
really odd ball ideas about bitfields in 128 bit sse registers :) But
who knows when I will get that done.
Bit-fields still share with the x86 byte registers the property of
increasing the register pressure when you modify their values or
read/write them. (Because the field needs a register of it's own to be
modified). But when they are just passed around they can nicely
reduce the register pressure. And in addition they are under
programmer control so you know it is a trade off between register
pressure when using the value and register pressure when passing the
values.
You can roll bit-fields by hand at the moment if you want though.
What I find most disturbing is last I looked is that
size crt0.o list it at about 33K (After lowering spurious debugging
messages from debug to spew). And linuxbios_payload.nrvb at about
24K. crt0.o from the p4dpr is at about 10K. So romcc is giving
me a 3X code bloat... I am pretty certain it is code bloat caused
by inlining everything.
Ron you complained earlier about compile speed and I think romcc
is the big culprit there. It's register allocator is currently using
a O(N^2) data structure, so the more code it compiles the slower it
gets... I think I saw another version of basically the same
algorithm that uses a different data structure, which would make it
much faster.
Right now the speed is tolerable when I remember to set
#define DEBUG_CONSISTENCY 1
instead of 2 which I committed accidently the other day.
DEBUG_CONSISTENCY 2 is only really useful when debugging
the register allocator. With a perfect compiler DEBUG_CONSISTENCY
is not needed at all but romcc is still teething so if there
is not a performance hit it is useful.
Eric
From cforney at opus.com Fri Dec 5 05:54:01 2003
From: cforney at opus.com (Craig C Forney)
Date: Fri Dec 5 05:54:01 2003
Subject: arima hdama success
Message-ID: <000901c3bb1d$77dd8dc0$0100a8c0@opusone>
On Wed, 3 Dec 2003, Ron Minnich wrote
> as of this morning, with Yh Lu's changes, arima hdama builds work
fine.
>
>ron
I'm not having the same success.
I got the latest snapshot this evening, built for the arima hdama, and
it fails the same way it has failed (hangs after printing out stuff
below) for the last couple of months. Have Yh Lu's changes that fix the
arima hdama been committed? If not, could someone point me to the
changes that fix whatever this problem is?
Thanks,
Craig Forney
Opus Innovations LLC
LinuxBIOS-1.1.5.0Fallback Thu Dec 4 23:13:33 PST 2003 starting...
setting up resource map....
AMD8111 southbridge is connected to HT link 00000000
setting up resource map....
done.
Enabling routing table for node 00000000 done.
Enabling SMP settings
setup_remote_node
setup_remote_done
Renaming current temp node to 00000001 done.
Enabling routing table for node 00000001 done.
00000002 nodes initialized.
detect_mp_capabilities: 00000002
coherent_ht_finalize
done
SMBus controller enabled
Ram1.00
setting up CPU00 northbridge registers
done.
Ram1.01
setting up CPU01 northbridge registers
done.
Ram2.00
166Mhz
Interleaved
RAM: 0x00100000 KB
Ram2.01
Enabling dual channel memory
disabling dimm00
disabling dimm01
disabling dimm00
disabling dimm01
200Mhz
disabling dimm00
disabling dimm01
RAM: 0x00100000 KB
Ram3
ECC enabled
ECC enabled
Initializing memory: done
Clearing memory: addr 00000000-0000003f
----------------done
Initializing memory: done
Clearing memory: addr 00000040-0000003f
done
Ram4
PCI: 00:01.00
00: 22 10 50 74 00 00 30 02 12 00 04 06 00 00 81 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 f1 01 20 02
20: f0 ff 00 00 f1 ff 01 00 00 00 00 00 00 00 00 00
30: ff ff 00 00 a0 00 00 00 00 00 00 00 ff 00 00 00
40: 07 00 1f 00 00 00 00 00 02 0c 00 00 00 2c 00 00
50: 00 00 02 00 00 00 04 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 07 b8 03 00 08 00 03 00 0e 00 ff ff 02 00 ff ff
b0: 00 00 00 00 00 00 00 00 08 c0 00 80 00 00 00 00
c0: 08 00 41 00 20 00 11 00 20 00 00 00 22 00 35 00
d0: 02 00 35 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 08 08 0c 00 08 08 0d 00 0f 0f 13 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCI: 00:01.01
00: 22 10 51 74 00 00 00 02 01 10 00 08 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00
... PCI info deleted for brevity ...
80: 33 00 00 00 00 00 00 00 35 33 72 13 20 0a 10 00
90: 00 80 0a 08 08 0b 5b 0e 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: a3 88 1e 5a 02 00 00 00 8c 5b b7 d6 72 9f e7 ef
c0: 00 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 04 67 05 44 e4 ae 6b 16 9e 4f 10 40 c5 1b cc 44
e0: d9 c6 0a 24 48 04 5c 10 38 6c 03 48 86 74 2e 26
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCI: 00:18.03
00: 22 10 03 11 00 00 00 00 00 00 00 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 40 00 be fc 07 77 73 80 7b 46
50: 08 a5 f7 0b 88 00 00 00 16 16 16 00 00 04 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 11 01 02 51 11 80 00 50 00 38 00 08 1b 22 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 02 00 00 00 70 0f 00 00 00 83 06 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 01 00 00 e0 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 20 10 00 00 1b 01 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Copying LinuxBIOS to ram.
Jumping to LinuxBIOS.
LinuxBIOS-1.1.5.0Fallback Thu Dec 4 23:13:33 PST 2003 booting...
Finding PCI configuration type.
PCI: Using configuration type 1
Enumerating: AMD K8 Northbridge
Enumerating: AMD K8 Northbridge
Enumerating: AMD K8
Enumerating: AMD K8
Enumerating: AMD 8111
Enumerating: NSC 87360
Enumerating buses...PCI: pci_scan_bus for bus 0
PCI: 00:18.0 [1022/1100] enabled
PCI: 00:18.1 [1022/1101] enabled
PCI: 00:18.2 [1022/1102] enabled
PCI: 00:18.3 [1022/1103] ops
PCI: 00:18.3 [1022/1103] enabled
PCI: 00:19.0 [ffff/ffff] enabled
PCI: 00:19.1 [ffff/ffff/00ffff] has unknown header type ff, ignoring.
PCI: 00:19.1 No device operations
From rminnich at lanl.gov Fri Dec 5 10:48:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Fri Dec 5 10:48:01 2003
Subject: Romcc Ramblings...
In-Reply-To:
Message-ID:
On 4 Dec 2003, Eric W. Biederman wrote:
>
> Ron you complained earlier about compile speed and I think romcc is the
> big culprit there. It's register allocator is currently using a O(N^2)
> data structure, so the more code it compiles the slower it gets... I
> think I saw another version of basically the same algorithm that uses a
> different data structure, which would make it much faster.
I don't mind the romcc compile speed at all, I just don't want to see us
return to the days of tons of perl code in the Makefiles. We made
deliberate changes to the new config tool to eliminate the need for that
stuff. When I first cut over to the new config tool I was quite surprised
at the difference in build time for linuxbios -- all those Perl
invocations are expensive.
Romcc is fine by me, I don't care how fast it goes, it saves our necks.
ron
From YhLu at tyan.com Fri Dec 5 12:28:01 2003
From: YhLu at tyan.com (YhLu)
Date: Fri Dec 5 12:28:01 2003
Subject: Tyan S2885
Message-ID: <3174569B9743D511922F00A0C943142303990AA3@TYANWEB>
I will try the code and use normal scan.
YH.
-----????-----
???: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com]
????: 2003?12?4? 21:36
???: YhLu
??: ron minnich; Stefan Reinauer; linuxbios at clustermatic.org
??: Re: Tyan S2885
YhLu writes:
> Eric,
>
> I found in amdk8_scan_root_bus in northbridge/amd/amdk8/northbridge.c
> You put
> /* Unmap all of the other pci busses */
> for(reg = 0xe0; reg <= 0xec; reg += 4) {
> f1_write_config32(reg, 0);
> }
>
> Why you need to clear that? After you clear that, I can not see the 8151
and
> AGP in s2885.
Hmm. This looks like a thinko.
So right now the code says:
unsigned int amdk8_scan_root_bus(device_t root, unsigned int max)
{
unsigned reg;
max = pci_scan_bus(&root->link[0], PCI_DEVFN(0x18, 0), 0xff, max);
/* Unmap all of the other pci busses */
for(reg = 0xe0; reg <= 0xec; reg += 4) {
f1_write_config32(reg, 0);
}
return max;
}
And I think what I meant was:
unsigned int amdk8_scan_root_bus(device_t root, unsigned int max)
{
unsigned reg;
/* Unmap all of the other pci busses */
for(reg = 0xe0; reg <= 0xec; reg += 4) {
f1_write_config32(reg, 0);
}
max = pci_scan_bus(&root->link[0], PCI_DEVFN(0x18, 0), 0xff, max);
return max;
}
I don't have a clue why it works at all with clearing those registers after
the pci bus scan.
I wonder if that is the reason scan order matters because I don't
clear those registers out first and things are dual mapped.
Anyway my intention was to be very careful and to clear the HT chain
mapping registers before we scanned them so we didn't have any old
configurations getting in the way.
Eric
From steve at nexpath.com Fri Dec 5 13:11:01 2003
From: steve at nexpath.com (Steve Gehlbach)
Date: Fri Dec 5 13:11:01 2003
Subject: Romcc Ramblings...
In-Reply-To:
References:
Message-ID: <3FD0CC7E.4080707@nexpath.com>
ron minnich wrote:
> I just don't want to see us
> return to the days of tons of perl code in the Makefiles. We made
> deliberate changes to the new config tool to eliminate the need for that
> stuff. When I first cut over to the new config tool I was quite surprised
> at the difference in build time for linuxbios -- all those Perl
> invocations are expensive.
You realize you are talking about God's Language :-)). Anyway, I think
as many sins could just as easily be committed in bash, I wouldn't
necessarily hang it all on Perl. IMHO.
-Steve
From rminnich at lanl.gov Fri Dec 5 13:15:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Fri Dec 5 13:15:00 2003
Subject: Romcc Ramblings...
In-Reply-To: <3FD0CC7E.4080707@nexpath.com>
Message-ID:
On Fri, 5 Dec 2003, Steve Gehlbach wrote:
> ron minnich wrote:
> > I just don't want to see us
> > return to the days of tons of perl code in the Makefiles. We made
> > deliberate changes to the new config tool to eliminate the need for that
> > stuff. When I first cut over to the new config tool I was quite surprised
> > at the difference in build time for linuxbios -- all those Perl
> > invocations are expensive.
>
> You realize you are talking about God's Language :-)). Anyway, I think
> as many sins could just as easily be committed in bash, I wouldn't
> necessarily hang it all on Perl. IMHO.
yes, we want to keep the bash invocations to a minimum too.
ron
From stuge-linuxbios at cdy.org Fri Dec 5 13:48:01 2003
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Fri Dec 5 13:48:01 2003
Subject: Romcc Ramblings...
In-Reply-To:
References: <20031202162031.GA23768@suse.de>
Message-ID: <20031205184004.GE24918@foo.birdnet.se>
On Thu, Dec 04, 2003 at 11:22:08PM -0700, Eric W. Biederman wrote:
> > >
> > > I would think it would hurt since x86 lets you use those little
> > > sub-registers (puddle arithmetic), so using bigger registers reduces
> > > the number of registers available.
> >
> > Yes, being able to use this from romcc would severely lower register
> > pressure I assume. Neither romcc nor the code compiled with it takes
> > care of this at the moment though.
>
> I tried this at one point. And the problem is that there
> is not a instruction sequence to move to/from the byte registers
> from a normal 32bit register.
Hmm, there's movzx and movsx for moving to 32 bit, but from 32 to 8 is
worse for esi, edi and ebp. 32->16 works fine of course.
I could be missing something though. :)
//Peter
From jarcher at pobox.com Fri Dec 5 13:57:00 2003
From: jarcher at pobox.com (Jordan Archer)
Date: Fri Dec 5 13:57:00 2003
Subject: Update to pirq_routing
Message-ID: <5.2.1.1.2.20031205105558.00bb6b88@cybermorph.com>
The following is the diff for a change I made. I think the HAVE_PIRQ_TABLE
is always defined and this allowed me to turn off the existence of a
routing table.
Jordan
RCS file:
/cvsroot/freebios/freebios2/src/arch/i386/include/arch/pirq_routing.h,v
retrieving revision 1.1
diff -r1.1 pirq_routing.h
42c42,43
< #if defined(DEBUG) && defined(HAVE_PIRQ_TABLE)
---
> //#if defined(DEBUG) && defined(HAVE_PIRQ_TABLE)
> #if defined(DEBUG) && HAVE_PIRQ_TABLE // JORDAN: This needs to
be dependent on value, not existence.
48c49,50
< #if defined(HAVE_PIRQ_TABLE)
---
> //#if defined(HAVE_PIRQ_TABLE)
> #if HAVE_PIRQ_TABLE // JORDAN: This needs to be dependent on
value, not
Index: romcc_io.h
===================================================================
From YhLu at tyan.com Fri Dec 5 18:03:01 2003
From: YhLu at tyan.com (YhLu)
Date: Fri Dec 5 18:03:01 2003
Subject: Tyan S2885
Message-ID: <3174569B9743D511922F00A0C943142303990AFE@TYANWEB>
Eric,
I change amdk8_scan_root_bus to:
unsigned int amdk8_scan_root_bus(device_t root, unsigned int max)
{
unsigned reg;
uint32_t value;
/* Unmap all of the other pci busses */
printk_debug("\nbefore pci_scan_bus\n");
for(reg = 0xe0; reg <= 0xec; reg += 4) {
value = f1_read_config32(reg);
printk_debug("amdk8_scan_root_bus %0x = %0x max = %0x\n",
reg,value,max);
if((value>>24)>max)
f1_write_config32(reg, 0);
}
for(reg = 0xe0; reg <= 0xec; reg += 4) {
value = f1_read_config32(reg);
printk_debug("amdk8_scan_root_bus %0x = %0x max = %0x\n",
reg,value,max);
}
max = pci_scan_bus(&root->link[0], PCI_DEVFN(0x18, 0), 0xff, max);
printk_debug("after pci_scan_bus\n");
for(reg = 0xe0; reg <= 0xec; reg += 4) {
value = f1_read_config32(reg);
printk_debug("amdk8_scan_root_bus %0x = %0x max = %0x\n",
reg,value,max);
}
return max;
}
I think as least you only need to clear the regs that contain bigger bus
number than the next bus for scanning.
The result will be in the end.
The problems:
1. It can not access 8151 on CPU link0 and so can not scan it
2. The HT scan seems can not figure out and set the link and read/write
enable bit in e0. It set the e0 to 0x05050000
Regards
Yinghai Lu
Copying LinuxBIOS to ram.
Jumping to LinuxBIOS.
LinuxBIOS-1.1.52.0_Fallback Fri Dec 5 14:29:03 EST 2003 booting...
Finding PCI configuration type.
PCI: Using configuration type 1
Enumerating: AMD K8 Northbridge
Enumerating: AMD K8 Northbridge
Enumerating: AMD K8
Enumerating: AMD K8
Enumerating: AMD 8111
Enumerating buses...
before pci_scan_bus
amdk8_scan_root_bus e0 = 4000203 max = 0
amdk8_scan_root_bus e4 = 6050003 max = 0
amdk8_scan_root_bus e8 = 0 max = 0
amdk8_scan_root_bus ec = 0 max = 0
amdk8_scan_root_bus e0 = 0 max = 0
amdk8_scan_root_bus e4 = 0 max = 0
amdk8_scan_root_bus e8 = 0 max = 0
amdk8_scan_root_bus ec = 0 max = 0
PCI: pci_scan_bus for bus 0
PCI: 00:18.0 [1022/1100] enabled
PCI: 00:18.1 [1022/1101] enabled
PCI: 00:18.2 [1022/1102] enabled
PCI: 00:18.3 [1022/1103] ops
PCI: 00:18.3 [1022/1103] enabled
PCI: 00:19.0 [1022/1100] enabled
PCI: 00:19.1 [1022/1101] enabled
PCI: 00:19.2 [1022/1102] enabled
PCI: 00:19.3 [1022/1103] ops
PCI: 00:19.3 [1022/1103] enabled
amdk8_scan_chains max: 0 starting...
Hyper transport scan link: 2 max: 1
PCI: 01:01.0 [1022/7450] enabled next_unitid: 0003
PCI: 01:03.0 [1022/7460] enabled next_unitid: 0007
HyperT reset 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] 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] enabled
PCI: 01:04.3 [1022/746b] ops
PCI: 01:04.3 [1022/746b] enabled
PCI: 01:04.5 [1022/746d] enabled
amd8111_enable dev: PCI: 01:04.6 lpc_dev: PCI: 01:04.0 index: 6 reg: ffff ->
ffbf done
PCI: 01:04.6 [ffff/ffff] disabled
PCI: pci_scan_bus for bus 2
PCI: 02:09.0 [14e4/16a7] ops
PCI: 02:09.0 [14e4/16a7] enabled
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] ops
PCI: 04:00.0 [1022/7464] enabled
PCI: 04:00.1 [1022/7464] ops
PCI: 04:00.1 [1022/7464] enabled
PCI: 04:00.2 [1022/7463] ops
PCI: 04:00.2 [1022/7463] enabled
amd8111_enable dev: PCI: 04:01.0 lpc_dev: PCI: 01:04.0 index: 9 reg: ffbf ->
fdbf done
PCI: 04:01.0 [ffff/ffff] disabled
PCI: 04:0b.0 [1095/3114] ops
PCI: 04:0b.0 [1095/3114] enabled
PCI: 04:0c.0 [104c/8023] ops
PCI: 04:0c.0 [104c/8023] enabled
PCI: pci_scan_bus returning with max=04
PCI: pci_scan_bus returning with max=04
Hyper transport scan link: 2 new max: 4
Hypertransport scan link done
Hyper transport scan link: 0 max: 5
Missing static device: PCI: 05:00.0
HyperT reset not needed
PCI: pci_scan_bus for bus 5
PCI: 05:00.0 [ffff/ffff/00ffff] has unknown header type ff, ignoring.
PCI: 05:00.0 No device operations
PCI: 05:01.0 [ffff/ffff/00ffff] has unknown header type ff, ignoring.
PCI: 05:01.0 No device operations
PCI: pci_scan_bus returning with max=05
Hyper transport scan link: 0 new max: 5
Hypertransport scan link done
amdk8_scan_chains max: 5 done
amdk8_scan_chains max: 5 starting...
amdk8_scan_chains max: 5 done
PCI: pci_scan_bus returning with max=05
after pci_scan_bus
amdk8_scan_root_bus e0 = 5050000 max = 5
amdk8_scan_root_bus e4 = 0 max = 5
amdk8_scan_root_bus e8 = 0 max = 5
amdk8_scan_root_bus ec = 0 max = 5
done
Allocating resources...
PCI: 05:00.0 missing read_resources
PCI: 05:01.0 missing read_resources
PCI: 05:00.0 missing read_resources
PCI: 05:01.0 missing read_resources
PCI: 04:01.0 missing read_resources
PCI: 04:01.0 missing read_resources
PCI: 04:01.0 missing read_resources
PCI: 01:04.6 missing read_resources
PCI: 01:04.6 missing read_resources
ASSIGN RESOURCES, bus 0
PCI: 05:00.0 missing read_resources
PCI: 05:01.0 missing read_resources
PCI: 00:18.0 c8
Eric,
If don't clear the regs, the result will be:
Copying LinuxBIOS to ram.
Jumping to LinuxBIOS.
LinuxBIOS-1.1.52.0_Fallback Fri Dec 5 15:05:21 EST 2003 booting...
Finding PCI configuration type.
PCI: Using configuration type 1
Enumerating: AMD K8 Northbridge
Enumerating: AMD K8 Northbridge
Enumerating: AMD K8
Enumerating: AMD K8
Enumerating: AMD 8111
Enumerating buses...
before pci_scan_bus
amdk8_scan_root_bus e0 = 4000203 max = 0
amdk8_scan_root_bus e4 = 6050003 max = 0
amdk8_scan_root_bus e8 = 0 max = 0
amdk8_scan_root_bus ec = 0 max = 0
PCI: pci_scan_bus for bus 0
PCI: 00:18.0 [1022/1100] enabled
PCI: 00:18.1 [1022/1101] enabled
PCI: 00:18.2 [1022/1102] enabled
PCI: 00:18.3 [1022/1103] ops
PCI: 00:18.3 [1022/1103] enabled
PCI: 00:19.0 [1022/1100] enabled
PCI: 00:19.1 [1022/1101] enabled
PCI: 00:19.2 [1022/1102] enabled
PCI: 00:19.3 [1022/1103] ops
PCI: 00:19.3 [1022/1103] enabled
amdk8_scan_chains max: 0 starting...
Hyper transport scan link: 2 max: 1
PCI: 01:01.0 [1022/7450] enabled next_unitid: 0003
PCI: 01:03.0 [1022/7460] enabled next_unitid: 0007
HyperT reset 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] 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] enabled
PCI: 01:04.3 [1022/746b] ops
PCI: 01:04.3 [1022/746b] enabled
PCI: 01:04.5 [1022/746d] enabled
amd8111_enable dev: PCI: 01:04.6 lpc_dev: PCI: 01:04.0 index: 6 reg: ffff ->
ffbf done
PCI: 01:04.6 [ffff/ffff] disabled
PCI: pci_scan_bus for bus 2
PCI: 02:09.0 [14e4/16a7] ops
PCI: 02:09.0 [14e4/16a7] enabled
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] ops
PCI: 04:00.0 [1022/7464] enabled
PCI: 04:00.1 [1022/7464] ops
PCI: 04:00.1 [1022/7464] enabled
PCI: 04:00.2 [1022/7463] ops
PCI: 04:00.2 [1022/7463] enabled
amd8111_enable dev: PCI: 04:01.0 lpc_dev: PCI: 01:04.0 index: 9 reg: ffbf ->
fdbf done
PCI: 04:01.0 [ffff/ffff] disabled
PCI: 04:0b.0 [1095/3114] ops
PCI: 04:0b.0 [1095/3114] enabled
PCI: 04:0c.0 [104c/8023] ops
PCI: 04:0c.0 [104c/8023] enabled
PCI: pci_scan_bus returning with max=04
PCI: pci_scan_bus returning with max=04
Hyper transport scan link: 2 new max: 4
Hypertransport scan link done
Hyper transport scan link: 0 max: 5
PCI: 05:01.0 [1022/7454] enabled next_unitid: 0004
HyperT reset needed
PCI: pci_scan_bus for bus 5
PCI: 05:01.0 [1022/7454] ops
PCI: 05:01.0 [1022/7454] enabled
PCI: 05:02.0 [1022/7455] bus ops
PCI: 05:02.0 [1022/7455] enabled
PCI: pci_scan_bus for bus 6
PCI: 06:00.0 [10de/0322] enabled
PCI: pci_scan_bus returning with max=06
PCI: pci_scan_bus returning with max=06
Hyper transport scan link: 0 new max: 6
Hypertransport scan link done
amdk8_scan_chains max: 6 done
amdk8_scan_chains max: 6 starting...
amdk8_scan_chains max: 6 done
PCI: pci_scan_bus returning with max=06
after pci_scan_bus
amdk8_scan_root_bus e0 = 4010203 max = 6
amdk8_scan_root_bus e4 = 6050003 max = 6
amdk8_scan_root_bus e8 = 0 max = 6
amdk8_scan_root_bus ec = 0 max = 6
done
Allocating resources...
PCI: 04:01.0 missing read_resources
PCI: 04:01.0 missing read_resources
PCI: 04:01.0 missing read_resources
PCI: 01:04.6 missing read_resources
PCI: 01:04.6 missing read_resources
ASSIGN RESOURCES, bus 0
PCI: 00:18.0 c8
References: <3174569B9743D511922F00A0C943142303990AFE@TYANWEB>
Message-ID:
YhLu writes:
> Eric,
>
> I change amdk8_scan_root_bus to:
>
> unsigned int amdk8_scan_root_bus(device_t root, unsigned int max)
> {
> unsigned reg;
> uint32_t value;
> /* Unmap all of the other pci busses */
> printk_debug("\nbefore pci_scan_bus\n");
> for(reg = 0xe0; reg <= 0xec; reg += 4) {
> value = f1_read_config32(reg);
> printk_debug("amdk8_scan_root_bus %0x = %0x max = %0x\n",
> reg,value,max);
> if((value>>24)>max)
> f1_write_config32(reg, 0);
> }
> for(reg = 0xe0; reg <= 0xec; reg += 4) {
> value = f1_read_config32(reg);
> printk_debug("amdk8_scan_root_bus %0x = %0x max = %0x\n",
> reg,value,max);
> }
>
> max = pci_scan_bus(&root->link[0], PCI_DEVFN(0x18, 0), 0xff, max);
>
> printk_debug("after pci_scan_bus\n");
> for(reg = 0xe0; reg <= 0xec; reg += 4) {
> value = f1_read_config32(reg);
> printk_debug("amdk8_scan_root_bus %0x = %0x max = %0x\n",
> reg,value,max);
> }
>
> return max;
> }
>
> I think as least you only need to clear the regs that contain bigger bus
> number than the next bus for scanning.
>
> The result will be in the end.
>
> The problems:
> 1. It can not access 8151 on CPU link0 and so can not scan it
> 2. The HT scan seems can not figure out and set the link and read/write
> enable bit in e0. It set the e0 to 0x05050000
Doh. The Opteron is too forgiving when you only have one link. It
makes this kind of debugging a pain. What I am doing should not work
but it does in that case...
My apologies, for missing this.
In amdk8_scan_chains() there is the snippet:
config_busses &= 0x0000ffff;
config_busses |= ((dev->link[link].secondary) << 16) |
((dev->link[link].subordinate) << 24);
f1_write_config32(config_reg, config_busses);
Which is the offending piece of code. It neither sets the link that
we are supposed to go out, nor does it set the r/w enable bits. Ouch.
It only works if those registers are pre programmed.
So I think this should be:
config_busses &= 0x000fc88;
config_busses |=
(3 << 0) | /* rw enable, no device compare */
(( nodeid & 7) << 4) |
(( link & 3 ) << 8) |
((dev->link[link].secondary) << 16) |
((dev->link[link].subordinate) << 24);
f1_write_config32(config_reg, config_busses);
Eric
From YhLu at tyan.com Fri Dec 5 18:58:01 2003
From: YhLu at tyan.com (YhLu)
Date: Fri Dec 5 18:58:01 2003
Subject: Tyan S2885
Message-ID: <3174569B9743D511922F00A0C943142303990B1B@TYANWEB>
Eric,
Great, it works. Even normal scan it can find out 8151.
But the bus number is funny, I may need to update bus number mptable.c and
irq_table.c and reset.c
I wonder if 8151 on CPU 1 and 8131/8111 on CPU0. is the amdk8_scan_root_bus
called two times? If so, you may keep the
> for(reg = 0xe0; reg <= 0xec; reg += 4) {
> value = f1_read_config32(reg);
> printk_debug("amdk8_scan_root_bus %0x = %0x max =
%0x\n",
> reg,value,max);
> if((value>>24)>max)
> f1_write_config32(reg, 0);
> }
Regards
YH.
-----????-----
???: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com]
????: 2003?12?5? 15:26
???: YhLu
??: ron minnich; Stefan Reinauer; linuxbios at clustermatic.org
??: Re: Tyan S2885
YhLu writes:
> Eric,
>
> I change amdk8_scan_root_bus to:
>
> unsigned int amdk8_scan_root_bus(device_t root, unsigned int max)
> {
> unsigned reg;
> uint32_t value;
> /* Unmap all of the other pci busses */
> printk_debug("\nbefore pci_scan_bus\n");
> for(reg = 0xe0; reg <= 0xec; reg += 4) {
> value = f1_read_config32(reg);
> printk_debug("amdk8_scan_root_bus %0x = %0x max =
%0x\n",
> reg,value,max);
> if((value>>24)>max)
> f1_write_config32(reg, 0);
> }
> for(reg = 0xe0; reg <= 0xec; reg += 4) {
> value = f1_read_config32(reg);
> printk_debug("amdk8_scan_root_bus %0x = %0x max =
%0x\n",
> reg,value,max);
> }
>
> max = pci_scan_bus(&root->link[0], PCI_DEVFN(0x18, 0), 0xff, max);
>
> printk_debug("after pci_scan_bus\n");
> for(reg = 0xe0; reg <= 0xec; reg += 4) {
> value = f1_read_config32(reg);
> printk_debug("amdk8_scan_root_bus %0x = %0x max =
%0x\n",
> reg,value,max);
> }
>
> return max;
> }
>
> I think as least you only need to clear the regs that contain bigger bus
> number than the next bus for scanning.
>
> The result will be in the end.
>
> The problems:
> 1. It can not access 8151 on CPU link0 and so can not scan it
> 2. The HT scan seems can not figure out and set the link and read/write
> enable bit in e0. It set the e0 to 0x05050000
Doh. The Opteron is too forgiving when you only have one link. It
makes this kind of debugging a pain. What I am doing should not work
but it does in that case...
My apologies, for missing this.
In amdk8_scan_chains() there is the snippet:
config_busses &= 0x0000ffff;
config_busses |= ((dev->link[link].secondary) << 16) |
((dev->link[link].subordinate) << 24);
f1_write_config32(config_reg, config_busses);
Which is the offending piece of code. It neither sets the link that
we are supposed to go out, nor does it set the r/w enable bits. Ouch.
It only works if those registers are pre programmed.
So I think this should be:
config_busses &= 0x000fc88;
config_busses |=
(3 << 0) | /* rw enable, no device compare */
(( nodeid & 7) << 4) |
(( link & 3 ) << 8) |
((dev->link[link].secondary) << 16) |
((dev->link[link].subordinate) << 24);
f1_write_config32(config_reg, config_busses);
Eric
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: S2885_1.1.5_reverse_scan_reg_clear_e0_before_scan.txt
URL:
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: S2885_1.1.5_normal_scan_clear_e0_before_scan.txt
URL:
From ebiederman at lnxi.com Fri Dec 5 19:16:01 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Dec 5 19:16:01 2003
Subject: Tyan S2885
In-Reply-To: <3174569B9743D511922F00A0C943142303990B1B@TYANWEB>
References: <3174569B9743D511922F00A0C943142303990B1B@TYANWEB>
Message-ID:
YhLu writes:
> Eric,
>
> Great, it works. Even normal scan it can find out 8151.
>
> But the bus number is funny, I may need to update bus number mptable.c and
> irq_table.c and reset.c
>
> I wonder if 8151 on CPU 1 and 8131/8111 on CPU0. is the amdk8_scan_root_bus
> called two times? If so, you may keep the
amdk8_scan_root_bus is always only called once. It just finds the cpus.
It recurses into amdk8_scan_chains which actually finds all of the busses.
So it is ok to zap everything in amdk8_scan_root_bus. But it may
be a little more elegant to zap just what we need in amdk8_scan_root_bus.
Eric
From YhLu at tyan.com Fri Dec 5 19:51:01 2003
From: YhLu at tyan.com (YhLu)
Date: Fri Dec 5 19:51:01 2003
Subject: Tyan S2885
Message-ID: <3174569B9743D511922F00A0C943142303990B2F@TYANWEB>
S2885 updated to 1.1.5
Only reset once.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: S2885_1.1.5_normal_scan_clear_e0_before_scan_hard_reset_OK.txt
URL:
From Phreak_Show at gmx.de Sat Dec 6 10:57:01 2003
From: Phreak_Show at gmx.de (Stefan)
Date: Sat Dec 6 10:57:01 2003
Subject: Will this work ??
Message-ID: <3FD1FC88.3050404@gmx.de>
Hi there,
I've a Gigabyte GA-7NNXP with nForce II Chipset, and a BIOS with a size
of 512 KB.
Will I be able to get a open source "bios" work on that mainboard ?
thx for your helping!!
From Antony at Soft-Solutions.co.uk Sat Dec 6 11:20:00 2003
From: Antony at Soft-Solutions.co.uk (Antony Stone)
Date: Sat Dec 6 11:20:00 2003
Subject: Will this work ??
In-Reply-To: <3FD1FC88.3050404@gmx.de>
References: <3FD1FC88.3050404@gmx.de>
Message-ID: <200312061620.20115.Antony@Soft-Solutions.co.uk>
On Saturday 06 December 2003 3:58 pm, Stefan wrote:
> Hi there,
> I've a Gigabyte GA-7NNXP with nForce II Chipset, and a BIOS with a size
> of 512 KB.
> Will I be able to get a open source "bios" work on that mainboard ?
Boot Linux on that board by whatever means you can and post the results of
"lspci" and "lspci -v" so we can see what chipsets etc are really there.
Antony.
--
This is not a rehearsal.
This is Real Life.
Please reply to the list;
please don't CC me.
From rminnich at lanl.gov Sat Dec 6 11:46:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Sat Dec 6 11:46:01 2003
Subject: Will this work ??
In-Reply-To: <3FD1FC88.3050404@gmx.de>
Message-ID:
On Sat, 6 Dec 2003, Stefan wrote:
> I've a Gigabyte GA-7NNXP with nForce II Chipset, and a BIOS with a size
> of 512 KB.
nvidia chipset, right? no chance. nvidia has no wish to help.
ron
From a.nielsen at optushome.com.au Sat Dec 6 23:15:01 2003
From: a.nielsen at optushome.com.au (Adam Nielsen)
Date: Sat Dec 6 23:15:01 2003
Subject: Will this work ??
In-Reply-To:
References:
Message-ID: <200312071409.54893@korath>
> > I've a Gigabyte GA-7NNXP with nForce II Chipset, and a BIOS with a size
> > of 512 KB.
> nvidia chipset, right? no chance. nvidia has no wish to help.
That's a shame - I was thinking of getting a Gigabyte/nVidia board because
Gigabyte now appear to have true dual BIOS chips on their boards. If it
fails to boot from one chip it automatically switches to the other, you can
reflash one chip from the other or from a floppy in the default BIOS setup,
etc. it looks like it'd be a very handy board to use for testing - put
LinuxBIOS in the main chip and have the default BIOS as backup. Then you can
boot off the backup in case of a failed flash attempt and reflash LinuxBIOS
into the main chip.
Looks like Gigabyte are introducing it on all their boards though, which is a
good sign.
Cheers,
Adam.
From sc at flagen.com Sun Dec 7 06:59:00 2003
From: sc at flagen.com (David Hendricks)
Date: Sun Dec 7 06:59:00 2003
Subject: Will this work ??
In-Reply-To: <200312071409.54893@korath>
References:
<200312071409.54893@korath>
Message-ID: <20031207050022.5a6281ca.sc@flagen.com>
LinuxBIOS can boot off a fallback image on the ROM in case the primary
image fails.
On Sun, 7 Dec 2003 14:09:54 +1000
Adam Nielsen wrote:
> > > I've a Gigabyte GA-7NNXP with nForce II Chipset, and a BIOS with a
> > > size of 512 KB.
>
> > nvidia chipset, right? no chance. nvidia has no wish to help.
>
> That's a shame - I was thinking of getting a Gigabyte/nVidia board
> because Gigabyte now appear to have true dual BIOS chips on their
> boards. If it fails to boot from one chip it automatically switches
> to the other, you can reflash one chip from the other or from a floppy
> in the default BIOS setup, etc. it looks like it'd be a very handy
> board to use for testing - put LinuxBIOS in the main chip and have the
> default BIOS as backup. Then you can boot off the backup in case of a
> failed flash attempt and reflash LinuxBIOS into the main chip.
>
> Looks like Gigabyte are introducing it on all their boards though,
> which is a good sign.
>
> Cheers,
> Adam.
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
From ijpriya at hotmail.com Mon Dec 8 04:42:00 2003
From: ijpriya at hotmail.com (Devi Priya)
Date: Mon Dec 8 04:42:00 2003
Subject: Hardware Help with diskonchip?
Message-ID:
Hi,
In the application note (AP044) from Msystems it is given as:
"The DiskOnChip Millennium is mapped into an 8KB memory window in the host
platform?s
memory map. This 8KB window consists of four 2KB windows." Why is this
mapping done?
Is this mapping done in hardware? I use diskonchip millennium (8MByte
MD2800). Then shouldn't the entire 8MB shall be mapped in hardware to the
physical address space?
The steps for BIOS is summarised as
1. After DiskOnChip Millennium BUSY# signal is negated, the CPU fetches the
Reset Vector from
the Boot-Block area, fetches the Boot Code stored there, and starts to
execute the code.
2. Boot Code runs the first part of BIOS, initializing the basic hardware
functionality.
3. Boot Codes loads the rest of the BIOS from the flash memory to the DRAM,
and transfer control
(jumps) there.
4. Chip Select of DiskOnChip Millennium is remapped from Reset Vector to
BIOS expansion area.
5. CPU executes the rest of the BIOS code, including ROM expansion devices
(among them, the
DiskOnChip Millennium itself).
6. CPU calls OS bootstrap loader (INT19).
7. OS is loaded, and recognizes the DiskOnChip Millennium as the boot
device.
8. OS loads the application code from the DiskOnChip Millennium and executes
it.
9. Application software uses DiskOnChip Millennium exactly as if it were
using a regular hard
disk.
In step 4 why is this remapping done? Is this mapping done in hardware?
In my setup, the diskonchip is mapped in hardware to the higher order
address
(0xFFFFFFFF-0xFF800000). SDRAM mapped to lower address
(0x00000000-0x1FFFFFF). What else
modification do i require in HARDWARE to use diskonchip millennium?
_________________________________________________________________
Add zing to Hotmail. Get FREE newsletters.
http://server1.msn.co.in/features/general/Newsletters/index.asp Subscribe
now!
From nemesis-lists at icequake.net Mon Dec 8 07:48:01 2003
From: nemesis-lists at icequake.net (Ryan Underwood)
Date: Mon Dec 8 07:48:01 2003
Subject: legacy BIOS usage
Message-ID: <20031208124939.GC17909@dbz.icequake.net>
Hi,
I had the idea of using LinuxBIOS but also maintaining a legacy BIOS for
debugging and dual boot scenarios. It would be linked into the
LinuxBIOS image and jumped to alternatively depending on the user input.
However, thinking about this gave me 2 questions:
1. Are there any forms of user input possible into LinuxBIOS loader? Is
the system initialized enough to accept a keyboard input, or ACPI system
button, or even something sillier like checking if a PS/2 mouse is
plugged in (the user can unplug the mouse to signal LinuxBIOS to jump to
the legacy BIOS instead).
2. Is it possible to get the machine into a state where it can check
whatever form of user input is possible, but still be able to then put
the machine back into a state where the legacy BIOS won't be confused.
Or could something like this be done via the reboot vector instead?
Power on clean gets you LinuxBIOS, but reboot goes to legacy BIOS... I
guess the problem there again would be putting the hardware back into a
state that the legacy BIOS can use.
any ideas on that topic? It would be nice to use FreeDOS occasionally
for testing some external hardware control programs, but FreeDOS
requires a PC BIOS, of which there are no open source implementations
that I know of. :( Maybe that can be a project for the future, but
somehow I see a lack of interest in putting any new effort into a dead
platform, so using the legacy proprietary BIOS might be the only real
world choice.
p.s. there is a broken Microsoft link in the FAQ, it is here now:
http://www.microsoft.com/whdc/hwdev/archive/BUSBIOS/pciirq.mspx
--
Ryan Underwood,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
From adam at cfar.umd.edu Mon Dec 8 09:05:00 2003
From: adam at cfar.umd.edu (Adam Sulmicki)
Date: Mon Dec 8 09:05:00 2003
Subject: legacy BIOS usage
In-Reply-To: <20031208124939.GC17909@dbz.icequake.net>
Message-ID: <20031208090518.Q392-100000@www.missl.cs.umd.edu>
On Mon, 8 Dec 2003, Ryan Underwood wrote:
> any ideas on that topic? It would be nice to use FreeDOS occasionally
> for testing some external hardware control programs, but FreeDOS
> requires a PC BIOS, of which there are no open source implementations
> that I know of. :( Maybe that can be a project for the future, but
> somehow I see a lack of interest in putting any new effort into a dead
> platform, so using the legacy proprietary BIOS might be the only real
> world choice.
oh sure there is. see "SEBOS" project in linuxbios v1 cvs tree. It boots
windows, and windows 98 wasn't that far off.
--
Adam Sulmicki
http://www.eax.com The Supreme Headquarters of the 32 bit registers
From nemesis-lists at icequake.net Mon Dec 8 09:35:00 2003
From: nemesis-lists at icequake.net (Ryan Underwood)
Date: Mon Dec 8 09:35:00 2003
Subject: legacy BIOS usage
In-Reply-To: <20031208090518.Q392-100000@www.missl.cs.umd.edu>
References: <20031208124939.GC17909@dbz.icequake.net> <20031208090518.Q392-100000@www.missl.cs.umd.edu>
Message-ID: <20031208143618.GA27814@dbz.icequake.net>
hi,
On Mon, Dec 08, 2003 at 09:06:33AM -0500, Adam Sulmicki wrote:
> On Mon, 8 Dec 2003, Ryan Underwood wrote:
>
> > any ideas on that topic? It would be nice to use FreeDOS occasionally
> > for testing some external hardware control programs, but FreeDOS
> > requires a PC BIOS, of which there are no open source implementations
> > that I know of. :( Maybe that can be a project for the future, but
> > somehow I see a lack of interest in putting any new effort into a dead
> > platform, so using the legacy proprietary BIOS might be the only real
> > world choice.
>
> oh sure there is. see "SEBOS" project in linuxbios v1 cvs tree. It boots
> windows, and windows 98 wasn't that far off.
Very nice! That slipped in under my radar. I guess I'll be heading in
that direction then instead of bothering with the old proprietary junk.
thanks
--
Ryan Underwood,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
From rminnich at lanl.gov Mon Dec 8 12:29:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Mon Dec 8 12:29:00 2003
Subject: for all k8 builders
Message-ID:
your builds are broken today due to the missing amdk8.h file in
src/northbridge/amd/amdk8.
Do an update; I just added it.
ron
From ebiederman at lnxi.com Mon Dec 8 14:56:01 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Dec 8 14:56:01 2003
Subject: for all k8 builders
In-Reply-To:
References:
Message-ID:
ron minnich writes:
> your builds are broken today due to the missing amdk8.h file in
> src/northbridge/amd/amdk8.
>
> Do an update; I just added it.
Grumble. You are pushing out my changes before we have finished
testing them. I don't mind to much but I do know some of that code
was not fully generalized, so there could be problems if you have
not looked through it carefully.
Eric
From rminnich at lanl.gov Mon Dec 8 15:11:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Mon Dec 8 15:11:01 2003
Subject: for all k8 builders
In-Reply-To:
Message-ID:
On 8 Dec 2003, Eric W. Biederman wrote:
> Grumble. You are pushing out my changes before we have finished
> testing them. I don't mind to much but I do know some of that code
> was not fully generalized, so there could be problems if you have
> not looked through it carefully.
The problem was that builds that worked friday stopped working this
morning, due apparently to this:
Revision 1.9 - (download), view (text) (markup) (annotate) - [select for
diffs]
Sat Dec 6 00:11:56 2003 UTC (2 days, 19 hours ago) by ebiederm
CVS Tags: HEAD
Changes since 1.8: +21 -8 lines
Diff to previous 1.8
- Fix amdk8_scan_root_bus and amdk8_scan_chains so multiple HT chains
can be scanned in any order
===
it was your push, not mine. It broke all the K8 builds. I would normally
not have pushed your stuff out but this was kind of an emergency.
Trust me, I'm not going to push your changes out before we test 'em, but I
can't stop you from doing it :-)
thanks
ron
From ebiederman at lnxi.com Mon Dec 8 15:30:01 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Dec 8 15:30:01 2003
Subject: for all k8 builders
In-Reply-To:
References:
Message-ID:
ron minnich writes:
> On 8 Dec 2003, Eric W. Biederman wrote:
>
> > Grumble. You are pushing out my changes before we have finished
> > testing them. I don't mind to much but I do know some of that code
> > was not fully generalized, so there could be problems if you have
> > not looked through it carefully.
>
> The problem was that builds that worked friday stopped working this
> morning, due apparently to this:
>
> Revision 1.9 - (download), view (text) (markup) (annotate) - [select for
> diffs]
> Sat Dec 6 00:11:56 2003 UTC (2 days, 19 hours ago) by ebiederm
> CVS Tags: HEAD
> Changes since 1.8: +21 -8 lines
> Diff to previous 1.8
>
> - Fix amdk8_scan_root_bus and amdk8_scan_chains so multiple HT chains
> can be scanned in any order
>
> ===
>
> it was your push, not mine. It broke all the K8 builds. I would normally
> not have pushed your stuff out but this was kind of an emergency.
>
> Trust me, I'm not going to push your changes out before we test 'em, but I
> can't stop you from doing it :-)
Ok. My apologies I jumped the gun on that one. I guess one of my clean ups
slipped out unintentionally.
I checked in the changes I had talked about with Yhlu to get the bus scanning
right and it appears some of my cleanups slipped out unintentionally. I'm going
to many directions at once it appears.
Eric
From YhLu at tyan.com Mon Dec 8 15:35:01 2003
From: YhLu at tyan.com (YhLu)
Date: Mon Dec 8 15:35:01 2003
Subject: for all k8 builders
Message-ID: <3174569B9743D511922F00A0C943142303990BA6@TYANWEB>
If only
- Fix amdk8_scan_root_bus and amdk8_scan_chains so multiple HT chains
can be scanned in any order
it will not break the code.
There must some other file changes cause that.
YH.
-----????-----
???: ron minnich [mailto:rminnich at lanl.gov]
????: 2003?12?8? 12:12
???: Eric W. Biederman
??: linuxbios at clustermatic.org
??: Re: for all k8 builders
On 8 Dec 2003, Eric W. Biederman wrote:
> Grumble. You are pushing out my changes before we have finished
> testing them. I don't mind to much but I do know some of that code
> was not fully generalized, so there could be problems if you have
> not looked through it carefully.
The problem was that builds that worked friday stopped working this
morning, due apparently to this:
Revision 1.9 - (download), view (text) (markup) (annotate) - [select for
diffs]
Sat Dec 6 00:11:56 2003 UTC (2 days, 19 hours ago) by ebiederm
CVS Tags: HEAD
Changes since 1.8: +21 -8 lines
Diff to previous 1.8
- Fix amdk8_scan_root_bus and amdk8_scan_chains so multiple HT chains
can be scanned in any order
===
it was your push, not mine. It broke all the K8 builds. I would normally
not have pushed your stuff out but this was kind of an emergency.
Trust me, I'm not going to push your changes out before we test 'em, but I
can't stop you from doing it :-)
thanks
ron
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
From rminnich at lanl.gov Mon Dec 8 15:38:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Mon Dec 8 15:38:01 2003
Subject: for all k8 builders
In-Reply-To: <3174569B9743D511922F00A0C943142303990BA6@TYANWEB>
Message-ID:
On Mon, 8 Dec 2003, YhLu wrote:
> If only
> - Fix amdk8_scan_root_bus and amdk8_scan_chains so multiple HT chains
> can be scanned in any order
> it will not break the code.
>
> There must some other file changes cause that.
I'm sorry, I don't understand.
ron
From YhLu at tyan.com Mon Dec 8 15:44:00 2003
From: YhLu at tyan.com (YhLu)
Date: Mon Dec 8 15:44:00 2003
Subject: for all k8 builders
Message-ID: <3174569B9743D511922F00A0C943142303990BAA@TYANWEB>
I will check the code.
From ebiederman at lnxi.com Mon Dec 8 15:48:01 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Dec 8 15:48:01 2003
Subject: for all k8 builders
In-Reply-To:
References:
Message-ID:
ron minnich writes:
> On Mon, 8 Dec 2003, YhLu wrote:
>
> > If only
> > - Fix amdk8_scan_root_bus and amdk8_scan_chains so multiple HT chains
> > can be scanned in any order
> > it will not break the code.
> >
> > There must some other file changes cause that.
>
> I'm sorry, I don't understand.
>
> ron
So to be clear the complete change was below.
The include of amdk8.h, the extra memory hole bit, and the deletion of
the link defines, and the deletion of other_reg slipped out by
accident. But I don't see those extra changes causing problems...
Eric
Index: northbridge.c
===================================================================
RCS file: /cvsroot/freebios/freebios2/src/northbridge/amd/amdk8/northbridge.c,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- northbridge.c 14 Oct 2003 02:36:51 -0000 1.8
+++ northbridge.c 6 Dec 2003 00:11:56 -0000 1.9
@@ -12,6 +12,7 @@
#include
#include "chip.h"
#include "northbridge.h"
+#include "amdk8.h"
struct mem_range *sizeram(void)
{
@@ -60,6 +61,16 @@
mem[idx].sizek = sizek;
idx++;
}
+
+ /* see if we need a hole from 0xa0000 to 0xbffff */
+ if((mem[idx-1].basek < ((8*64)+(8*16))) &&
+ (mem[idx-1].sizek > ((8*64)+(16*16)))) {
+ mem[idx].basek = (8*64)+(16*16);
+ mem[idx].sizek = mem[idx-1].sizek - ((8*64)+(16*16));
+ mem[idx-1].sizek = ((8*64)+(8*16)) - mem[idx-1].basek;
+ idx++;
+ }
+
/* See if I need to split the region to accomodate pci memory space */
if ((mem[idx - 1].basek <= mmio_basek) &&
((mem[idx - 1].basek + mem[idx - 1].sizek) > mmio_basek)) {
@@ -151,10 +162,6 @@
}
-#define LinkConnected (1 << 0)
-#define InitComplete (1 << 1)
-#define NonCoherent (1 << 2)
-#define ConnectionPending (1 << 4)
static unsigned int amdk8_scan_chains(device_t dev, unsigned int max)
{
unsigned nodeid;
@@ -166,7 +173,7 @@
for(link = 0; link < dev->links; link++) {
uint32_t link_type;
uint32_t busses, config_busses;
- unsigned free_reg, config_reg, other_reg;
+ unsigned free_reg, config_reg;
dev->link[link].cap = 0x80 + (link *0x20);
do {
link_type = pci_read_config32(dev, dev->link[link].cap + 0x18);
@@ -249,7 +256,13 @@
((unsigned int) (dev->link[link].subordinate) << 16);
pci_write_config32(dev, dev->link[link].cap + 0x14, busses);
- config_busses = (config_busses & 0x00ffffff) | (dev->link[link].subordinate << 24);
+ config_busses &= 0x000fc88;
+ config_busses |=
+ (3 << 0) | /* rw enable, no device compare */
+ (( nodeid & 7) << 4) |
+ (( link & 3 ) << 8) |
+ ((dev->link[link].secondary) << 16) |
+ ((dev->link[link].subordinate) << 24);
f1_write_config32(config_reg, config_busses);
#if 1
printk_debug("Hypertransport scan link done\n");
@@ -456,11 +469,11 @@
unsigned int amdk8_scan_root_bus(device_t root, unsigned int max)
{
unsigned reg;
- max = pci_scan_bus(&root->link[0], PCI_DEVFN(0x18, 0), 0xff, max);
- /* Unmap all of the other pci busses */
+ /* Unmap all of HT chains */
for(reg = 0xe0; reg <= 0xec; reg += 4) {
f1_write_config32(reg, 0);
}
+ max = pci_scan_bus(&root->link[0], PCI_DEVFN(0x18, 0), 0xff, max);
return max;
}
From rminnich at lanl.gov Mon Dec 8 15:50:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Mon Dec 8 15:50:01 2003
Subject: for all k8 builders
In-Reply-To:
Message-ID:
On 8 Dec 2003, Eric W. Biederman wrote:
> The include of amdk8.h, the extra memory hole bit, and the deletion of
> the link defines, and the deletion of other_reg slipped out by
> accident. But I don't see those extra changes causing problems...
agree.
ron
From YhLu at tyan.com Mon Dec 8 16:05:00 2003
From: YhLu at tyan.com (YhLu)
Date: Mon Dec 8 16:05:00 2003
Subject: for all k8 builders
Message-ID: <3174569B9743D511922F00A0C943142303990BAE@TYANWEB>
Eric,
Please check the northbridge.c attached.
It seems you should modify the e0 before you do the
hypertransport_scan_chain. Otherwise you can not access the buses.
YH.
config_busses &= 0x000fc88;
config_busses |=
(3 << 0) | /* rw enable, no device compare */
(( nodeid & 7) << 4) |
(( link & 3 ) << 8) |
((dev->link[link].secondary) << 16) |
((dev->link[link].subordinate) << 24);
f1_write_config32(config_reg, config_busses);
#if 1
printk_debug("Hyper transport scan link: %d max: %d\n",
link, max);
#endif
/* Now we can scan all of the subordinate busses i.e. the
chain on the hypertranport link */
max = hypertransport_scan_chain(&dev->link[link], max);
-------------- next part --------------
A non-text attachment was scrubbed...
Name: northbridge.c
Type: application/octet-stream
Size: 13690 bytes
Desc: not available
URL:
From ebiederman at lnxi.com Mon Dec 8 16:34:00 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Dec 8 16:34:00 2003
Subject: for all k8 builders
In-Reply-To: <3174569B9743D511922F00A0C943142303990BAE@TYANWEB>
References: <3174569B9743D511922F00A0C943142303990BAE@TYANWEB>
Message-ID:
YhLu writes:
> Eric,
>
> Please check the northbridge.c attached.
>
> It seems you should modify the e0 before you do the
> hypertransport_scan_chain. Otherwise you can not access the buses.
Unless I am mistaken that is what f1_write_config32 is doing...
config_reg is one of 0xe0, 0xe4, 0xe8, or 0xec
I think the only differences I am seeing are in, amdk8_scan_root_bus
and I just unconditionally zero 0xe0 - 0xec where you handle it conditionally
Eric
>
> YH.
>
> config_busses &= 0x000fc88;
> config_busses |=
> (3 << 0) | /* rw enable, no device compare */
> (( nodeid & 7) << 4) |
> (( link & 3 ) << 8) |
> ((dev->link[link].secondary) << 16) |
> ((dev->link[link].subordinate) << 24);
> f1_write_config32(config_reg, config_busses);
>
> #if 1
> printk_debug("Hyper transport scan link: %d max: %d\n",
> link, max);
> #endif
> /* Now we can scan all of the subordinate busses i.e. the
> chain on the hypertranport link */
> max = hypertransport_scan_chain(&dev->link[link], max);
From YhLu at tyan.com Mon Dec 8 16:39:01 2003
From: YhLu at tyan.com (YhLu)
Date: Mon Dec 8 16:39:01 2003
Subject: =?GB2312?B?tPC4tDogZm9yIGFsbCBrOCBidWlsZGVycw==?=
Message-ID: <3174569B9743D511922F00A0C943142303990BB4@TYANWEB>
Eric,
I mean in the amdk8_scan_chains, you need to put
> config_busses &= 0x000fc88;
> config_busses |=
> (3 << 0) | /* rw enable, no device compare */
> (( nodeid & 7) << 4) |
> (( link & 3 ) << 8) |
> ((dev->link[link].secondary) << 16) |
> ((dev->link[link].subordinate) << 24);
> f1_write_config32(config_reg, config_busses);
before
/* Now we can scan all of the subordinate busses i.e. the
> chain on the hypertranport link */
> max = hypertransport_scan_chain(&dev->link[link], max);
YH.
From ebiederman at lnxi.com Mon Dec 8 16:51:01 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Dec 8 16:51:01 2003
Subject: =?gb2312?b?tPC4tA==?=: for all k8 builders
In-Reply-To: <3174569B9743D511922F00A0C943142303990BB4@TYANWEB>
References: <3174569B9743D511922F00A0C943142303990BB4@TYANWEB>
Message-ID:
YhLu writes:
> Eric,
>
> I mean in the amdk8_scan_chains, you need to put
>
>
> > config_busses &= 0x000fc88;
> > config_busses |=
> > (3 << 0) | /* rw enable, no device compare */
> > (( nodeid & 7) << 4) |
> > (( link & 3 ) << 8) |
> > ((dev->link[link].secondary) << 16) |
> > ((dev->link[link].subordinate) << 24);
> > f1_write_config32(config_reg, config_busses);
>
> before
>
> /* Now we can scan all of the subordinate busses i.e. the
> > chain on the hypertranport link */
> > max = hypertransport_scan_chain(&dev->link[link], max);
>
Right. Sorry. That is what I thought I had done (and actually did in my
internal tree). Somehow I modified the wrong line...
I have fixed that and committed it.
This is the diff. Let's see what idiot mistake I will make this time...
Index: northbridge.c
===================================================================
RCS file: /cvsroot/freebios/freebios2/src/northbridge/amd/amdk8/northbridge.c,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- northbridge.c 6 Dec 2003 00:11:56 -0000 1.9
+++ northbridge.c 8 Dec 2003 21:48:01 -0000 1.10
@@ -5,6 +5,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -233,8 +234,12 @@
((unsigned int)(dev->link[link].subordinate) << 16));
pci_write_config32(dev, dev->link[link].cap + 0x14, busses);
- config_busses &= 0x0000ffff;
- config_busses |= ((dev->link[link].secondary) << 16) |
+ config_busses &= 0x000fc88;
+ config_busses |=
+ (3 << 0) | /* rw enable, no device compare */
+ (( nodeid & 7) << 4) |
+ (( link & 3 ) << 8) |
+ ((dev->link[link].secondary) << 16) |
((dev->link[link].subordinate) << 24);
f1_write_config32(config_reg, config_busses);
@@ -256,13 +261,7 @@
((unsigned int) (dev->link[link].subordinate) << 16);
pci_write_config32(dev, dev->link[link].cap + 0x14, busses);
- config_busses &= 0x000fc88;
- config_busses |=
- (3 << 0) | /* rw enable, no device compare */
- (( nodeid & 7) << 4) |
- (( link & 3 ) << 8) |
- ((dev->link[link].secondary) << 16) |
- ((dev->link[link].subordinate) << 24);
+ config_busses = (config_busses & 0x00ffffff) | (dev->link[link].subordinate << 24);
f1_write_config32(config_reg, config_busses);
#if 1
printk_debug("Hypertransport scan link done\n");
@@ -469,7 +468,7 @@
unsigned int amdk8_scan_root_bus(device_t root, unsigned int max)
{
unsigned reg;
- /* Unmap all of HT chains */
+ /* Unmap all of the HT chains */
for(reg = 0xe0; reg <= 0xec; reg += 4) {
f1_write_config32(reg, 0);
}
From prl at peterlister.co.uk Mon Dec 8 18:29:01 2003
From: prl at peterlister.co.uk (Peter Lister)
Date: Mon Dec 8 18:29:01 2003
Subject: legacy BIOS usage
In-Reply-To: <20031208143618.GA27814@dbz.icequake.net>
References: <20031208124939.GC17909@dbz.icequake.net>
<20031208090518.Q392-100000@www.missl.cs.umd.edu>
<20031208143618.GA27814@dbz.icequake.net>
Message-ID: <1070926244.4868.4585.camel@eddie>
On Mon, 2003-12-08 at 14:36, Ryan Underwood wrote:
> Very nice! That slipped in under my radar. I guess I'll be heading in
> that direction then instead of bothering with the old proprietary junk.
You should also note Peter Anvin's MEMDISK which emulates a virtual HDD
from a memory image. The code lives with syslinux, but not tied to any
specific bootloader.
http://syslinux.zytor.com/memdisk.php
It's possible that there may soon also be PXE for Etherboot as well;
there is a reasonable amount of code in existance and I'm trying to
resurrect it and get enough working that a couple of NBPs will run.
I personally think that a completely open legacy BIOS implementation
based on these + ADLO + bochs BIOS with hardware handled by LinuxBIOS
will have a very significant impact on a certain family of proprietary
operating systems.
From JJia at Fortinet.com Tue Dec 9 13:06:01 2003
From: JJia at Fortinet.com (Jia Jianwei)
Date: Tue Dec 9 13:06:01 2003
Subject: Promise PDC20275 IDE controller
Message-ID: <003a01c3be7e$5fcccd40$3a4610ac@JiaJianwei>
I'm working on a BIOS with Promise PDC20275 IDE controller, But the Ultra DMA mode can't work anyway. I can't get the datasheet of the controller.Anybody knows how to initialize the controller? or give me some advices, Thanks very much!
Regards,
Jia Jianwei
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From linuxbios at xdr.com Tue Dec 9 13:09:00 2003
From: linuxbios at xdr.com (Dave Ashley)
Date: Tue Dec 9 13:09:00 2003
Subject: EPIA-M + second serial port enabler
Message-ID: <200312091808.hB9I8phP028465@xdr.com>
In a previous email message
http://www.clustermatic.org/pipermail/linuxbios/2003-November/005891.html
I wrote
In V1 the file to modify is src/superio/via/vt1211/setup_serial.inc
That code sets up ttyS0 which is the VT1211's logical device 2. You
want to add some similiar code for logical device 3 to get ttyS1 working.
Assuming you want it to be at 2f8 you'd merge in these lines:
OUTPNPADDR($7)
OUTPNPDATA($3)
/* set the enable in reg. 0x30 */
OUTPNPADDR($0x30)
OUTPNPDATA($0x1)
/* Serial Port 2 Base Address (BEh) */
OUTPNPADDR($0x60)
OUTPNPDATA($0xbe)
/* Serial Port 2 IRQ (03h) */
OUTPNPADDR($0x70)
OUTPNPDATA($0x3)
/* Serial Port 2 Control */
OUTPNPADDR($0xf0)
OUTPNPDATA($0x2)
...then do the turn off pnp
/* turn off PnP */
OUTPNPADDR($0xaa)
...then duplicate the serial setup except the address goes from 3f8 -> 2f8
There is a piece missing. I had to enable the second serial port on the VT1211
and although linux recognized it, there was no serial activity on the lines.
These lines need to be added during the vt1211 configuration:
/* Allow serial port 2 (ldn 3) pins to come out */
OUTPNPADDR($0x27)
OUTPNPDATA($00)
This has to be before the $0xaa write to turn off configuration mode.
The default value on powerup for this register on the vt1211 is 0xff.
There are multi purpose pins on the chip and this connects them to the second
serial port.
-Dave
From ijpriya at hotmail.com Wed Dec 10 00:21:01 2003
From: ijpriya at hotmail.com (Devi Priya)
Date: Wed Dec 10 00:21:01 2003
Subject: DOCM mapping address?
Message-ID:
Hi,
I like to have my linuxbios, linux OS, filesystem in the same
diskonchip millennium. If I have to use diskonchip millennium with
linuxbios, to which physical address should the DOCM should be mapped in
hardware ? Is any driver should be loaded before the OS gets loaded? I have
mapped in hardware 0xFFFFFFFF-0xFF800000. Is this correct? Does any
remapping is to be done in hardware afer this?
Which file system should I use?
Regards,
Priya.
_________________________________________________________________
Discover India. Celebrate her diversity.
http://server1.msn.co.in/features/tourism/ Come, fall in love!
From ravivsn at roc.co.in Wed Dec 10 08:10:01 2003
From: ravivsn at roc.co.in (Ravi)
Date: Wed Dec 10 08:10:01 2003
Subject: Is net4501 of soekris engineering supported?
Message-ID: <3FD7205F.1070901@roc.co.in>
Hi,
This is my first posting to this list. Before posting this mail I
searched for any support of net 4501 soekris box.
Is net 4501 soekris box is supported by linuxbios?
Thanks in advance,
Best Regards,
Ravi
From rminnich at lanl.gov Wed Dec 10 10:33:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Wed Dec 10 10:33:00 2003
Subject: Is net4501 of soekris engineering supported?
In-Reply-To: <3FD7205F.1070901@roc.co.in>
Message-ID:
On Wed, 10 Dec 2003, Ravi wrote:
> Is net 4501 soekris box is supported by linuxbios?
without an lspci we can't tell you.
ron
From YhLu at tyan.com Wed Dec 10 15:53:01 2003
From: YhLu at tyan.com (YhLu)
Date: Wed Dec 10 15:53:01 2003
Subject: IDE on s2885 and LinuxBIOS -- FILO
Message-ID: <3174569B9743D511922F00A0C943142303990D22@TYANWEB>
Ron,
I have checked pci.c in fifo. It need to be changes as follow.
It seems otherwise it can not scan the peer root bus.
Maybe someone need to make it can handle peer root bus refer to the code in
Linux kernel or Etherboot.
Regards
YH.
void pci_init(void)
{
/* Count devices */
dev_list = 0;
debug("Scanning PCI: ");
pci_scan_bus(0);
pci_scan_bus(1); // For Tyan s2880,s2881,s2882,s2885,s4880
// pci_scan_bus(3); //For Tyan s2885
debug("found %d devices\n", n_devs);
/* Make the list */
dev_list = malloc(n_devs * sizeof(struct pci_dev));
n_devs = 0;
pci_scan_bus(0);
pci_scan_bus(1); // For Tyan s2880,s2881,s2882,s2885,s4880
// pci_scan_bus(3); //For Tyan s2885
#if DEBUG
{
int i;
for (i = 0; i < n_devs; i++) {
debug("%02x:%02x.%x %04x:%04x %04x %02x\n",
PCI_BUS(dev_list[i].addr),
PCI_DEV(dev_list[i].addr),
PCI_FN(dev_list[i].addr),
dev_list[i].vendor,
dev_list[i].device,
dev_list[i].devclass,
dev_list[i].prog_if);
}
}
#endif
}
-----????-----
???: YhLu
????: 2003?12?10? 9:27
???: 'ron minnich'
??: Hendricks David W.
??: Re: IDE on s2885 and LinuxBIOS
Is it working with On current tree or using old source tree to make sure all
8111/8131 on bus 0?
Yinghai Lu
-----????-----
???: ron minnich [mailto:rminnich at lanl.gov]
????: 2003?12?10? 7:25
???: YhLu
??: Hendricks David W.
??: Re: IDE on s2885 and LinuxBIOS
I wonder what differes from HDAMA to s2885? filo works fine on HDAMA
ron
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: S4880_REG_with_MB_HT_FIFO.txt
URL:
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: S4880_REG_with_MB_HT_FIFO_patch.txt
URL:
From stepan at suse.de Wed Dec 10 16:34:00 2003
From: stepan at suse.de (Stefan Reinauer)
Date: Wed Dec 10 16:34:00 2003
Subject: IDE on s2885 and LinuxBIOS -- FILO
In-Reply-To: <3174569B9743D511922F00A0C943142303990D22@TYANWEB>
References: <3174569B9743D511922F00A0C943142303990D22@TYANWEB>
Message-ID: <20031210213555.GB9144@suse.de>
* YhLu [031210 22:02]:
> I have checked pci.c in fifo. It need to be changes as follow.
>
> It seems otherwise it can not scan the peer root bus.
How is this done on the HDAMA and other boards?
> Maybe someone need to make it can handle peer root bus refer to the code in
> Linux kernel or Etherboot.
Can we have an array of peer busses in the config file?
ie. register SCAN_BUSSES={ 0, 1, 3 }
Or is there any real way to _detect_ peer busses? Or at least conclude
their existance by the available southbridges - There is obviously no
peer bus without a (transparent) bridge
Stefan
--
Stefan Reinauer, SUSE LINUX AG
Teamleader Architecture Development
From YhLu at tyan.com Wed Dec 10 16:37:01 2003
From: YhLu at tyan.com (YhLu)
Date: Wed Dec 10 16:37:01 2003
Subject: IDE on s2885 and LinuxBIOS -- FILO
Message-ID: <3174569B9743D511922F00A0C943142303990D30@TYANWEB>
> How is this done on the HDAMA and other boards?
The 8111/8131 in bus 0 or bus1 if it works with filo?
From ebiederman at lnxi.com Wed Dec 10 16:43:01 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Dec 10 16:43:01 2003
Subject: IDE on s2885 and LinuxBIOS -- FILO
In-Reply-To: <20031210213555.GB9144@suse.de>
References: <3174569B9743D511922F00A0C943142303990D22@TYANWEB>
<20031210213555.GB9144@suse.de>
Message-ID:
Stefan Reinauer writes:
> * YhLu [031210 22:02]:
> > I have checked pci.c in fifo. It need to be changes as follow.
> >
> > It seems otherwise it can not scan the peer root bus.
>
> How is this done on the HDAMA and other boards?
Currently I have not been testing the Filo on the HDAMA. Last
time this was brought up I someone was going to modify FILO to scan
through all possible busses like etherboot does.
> > Maybe someone need to make it can handle peer root bus refer to the code in
> > Linux kernel or Etherboot.
>
> Can we have an array of peer busses in the config file?
> ie. register SCAN_BUSSES={ 0, 1, 3 }
In LinuxBIOS we are fine. It is just in FILO where there is an issue.
> Or is there any real way to _detect_ peer busses? Or at least conclude
> their existance by the available southbridges - There is obviously no
> peer bus without a (transparent) bridge
Linux uses the pirq table to infer their presence. We really
should export the device tree in the LinuxBIOS table. Then FILO can
read that to find busses and other devices.
Eric
From ijpriya at hotmail.com Wed Dec 10 22:09:01 2003
From: ijpriya at hotmail.com (Devi Priya)
Date: Wed Dec 10 22:09:01 2003
Subject: Please help
Message-ID:
Hi,
I like to have my linuxbios, linux OS, filesystem in the same
diskonchip millennium. If I have to use diskonchip millennium with
linuxbios, to which physical address should the DOCM should be mapped in
hardware ? Is any driver should be loaded before the OS gets loaded? I have
mapped in hardware 0xFFFFFFFF-0xFF800000. Is this correct? Does any
remapping is to be done in hardware afer this?
Which file system should I use?
_________________________________________________________________
Download cool KHNH ringtones. Add style to your mobile.
http://server1.msn.co.in/sp03/gprs/howcani_ring.asp Simply click here.
From rminnich at lanl.gov Wed Dec 10 22:39:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Wed Dec 10 22:39:00 2003
Subject: Please help
In-Reply-To:
Message-ID:
On Thu, 11 Dec 2003, Devi Priya wrote:
> diskonchip millennium. If I have to use diskonchip millennium with
> linuxbios, to which physical address should the DOCM should be mapped in
> hardware ? Is any driver should be loaded before the OS gets loaded? I have
> mapped in hardware 0xFFFFFFFF-0xFF800000. Is this correct? Does any
> remapping is to be done in hardware afer this?
> Which file system should I use?
I would like to help but your questions indicate you are somewhat
unfamiliar with many things. Are you using some standard motherboard or
designing one?
If you are not designing one, consider buying an existing DOC-based mobo
from cwlinux.com and learning from that.
ron
From ijpriya at hotmail.com Wed Dec 10 23:56:01 2003
From: ijpriya at hotmail.com (Devi Priya)
Date: Wed Dec 10 23:56:01 2003
Subject: Please help
Message-ID:
I am using SC1200.
>From: ron minnich
>To: Devi Priya
>CC: linuxbios at clustermatic.org
>Subject: Re: Please help
>Date: Wed, 10 Dec 2003 20:40:51 -0700 (MST)
>
>On Thu, 11 Dec 2003, Devi Priya wrote:
>
> > diskonchip millennium. If I have to use diskonchip millennium with
> > linuxbios, to which physical address should the DOCM should be mapped in
> > hardware ? Is any driver should be loaded before the OS gets loaded? I
>have
> > mapped in hardware 0xFFFFFFFF-0xFF800000. Is this correct? Does any
> > remapping is to be done in hardware afer this?
> > Which file system should I use?
>
>I would like to help but your questions indicate you are somewhat
>unfamiliar with many things. Are you using some standard motherboard or
>designing one?
>
>If you are not designing one, consider buying an existing DOC-based mobo
>from cwlinux.com and learning from that.
>
>ron
>
_________________________________________________________________
Contact brides & grooms FREE! Only on www.shaadi.com.
http://www.shaadi.com/ptnr.php?ptnr=hmltag Register now!
From ts1 at tsn.or.jp Thu Dec 11 03:30:01 2003
From: ts1 at tsn.or.jp (Takeshi Sone)
Date: Thu Dec 11 03:30:01 2003
Subject: IDE on s2885 and LinuxBIOS -- FILO
In-Reply-To:
References: <3174569B9743D511922F00A0C943142303990D22@TYANWEB> <20031210213555.GB9144@suse.de>
Message-ID: <20031211083112.GA3485@tsn.or.jp>
On Wed, Dec 10, 2003 at 02:49:29PM -0700, Eric W. Biederman wrote:
> Stefan Reinauer writes:
>
> > * YhLu [031210 22:02]:
> > > I have checked pci.c in fifo. It need to be changes as follow.
> > >
> > > It seems otherwise it can not scan the peer root bus.
> >
> > How is this done on the HDAMA and other boards?
>
> Currently I have not been testing the Filo on the HDAMA. Last
> time this was brought up I someone was going to modify FILO to scan
> through all possible busses like etherboot does.
That patch is here:
http://www.clustermatic.org/pipermail/linuxbios/2003-October/005753.html
> > > Maybe someone need to make it can handle peer root bus refer to the code in
> > > Linux kernel or Etherboot.
> >
> > Can we have an array of peer busses in the config file?
> > ie. register SCAN_BUSSES={ 0, 1, 3 }
I like this idea implemented in FILO, rather than having 2 options
(recurse from bus 0, and scan 0-255).
What do you think?
> > Or is there any real way to _detect_ peer busses? Or at least conclude
> > their existance by the available southbridges - There is obviously no
> > peer bus without a (transparent) bridge
>
> Linux uses the pirq table to infer their presence. We really
> should export the device tree in the LinuxBIOS table. Then FILO can
> read that to find busses and other devices.
That would be the right solution eventually.
--
Takeshi
From parit_top at yahoo.com Sat Dec 13 23:37:00 2003
From: parit_top at yahoo.com (Parit Wattanasin)
Date: Sat Dec 13 23:37:00 2003
Subject: serial programming
Message-ID: <20031214043944.21965.qmail@web10801.mail.yahoo.com>
hi, I'm new for LinuxBIOS. I have problem about my
mainboard(VIA-EPIA) Now I'm use LinuxBIOS but I want
to customized it to chang payload from etherboot with
my program about serial port(now this mainboard use
serial console) how can I'change it(my program use
assembly). Thank you for answer
__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
From stuge-linuxbios at cdy.org Sun Dec 14 00:22:01 2003
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Sun Dec 14 00:22:01 2003
Subject: serial programming
In-Reply-To: <20031214043944.21965.qmail@web10801.mail.yahoo.com>
References: <20031214043944.21965.qmail@web10801.mail.yahoo.com>
Message-ID: <20031214051445.GA17520@foo.birdnet.se>
On Sat, Dec 13, 2003 at 08:39:44PM -0800, Parit Wattanasin wrote:
> hi, I'm new for LinuxBIOS. I have problem about my
> mainboard(VIA-EPIA) Now I'm use LinuxBIOS but I want
> to customized it to chang payload from etherboot with
> my program about serial port(now this mainboard use
> serial console) how can I'change it(my program use
> assembly). Thank you for answer
The payload can be exchanged from Etherboot to another self-contained ELF
file simply by recompiling LinuxBIOS.
I'm not quite sure about the status of the EPIA port in the version 2 CVS
tree, but it's there and there's been work put into it so it should probably
compile and work just fine.
The best bet is to check the mailing list archives for information, and then
grab the CVS code, or a snapshot, and make your own build.
While making your own build you can also take out all serial port activity
not needed for your application, of course.
//Peter
From rminnich at lanl.gov Sun Dec 14 00:50:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Sun Dec 14 00:50:01 2003
Subject: serial programming
In-Reply-To: <20031214051445.GA17520@foo.birdnet.se>
Message-ID:
On Sun, 14 Dec 2003, Peter Stuge wrote:
> I'm not quite sure about the status of the EPIA port in the version 2 CVS
> tree, but it's there and there's been work put into it so it should probably
> compile and work just fine.
EPIA is fine in V2, not perfect but FAR better than EPIA in v1.
We want to clean up EPIA completely, then fix up EPIA-M, but there have
been some distractions (SC '03).
ron
From stuge-linuxbios at cdy.org Sun Dec 14 02:45:01 2003
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Sun Dec 14 02:45:01 2003
Subject: serial programming
In-Reply-To:
References: <20031214051445.GA17520@foo.birdnet.se>
Message-ID: <20031214073708.GC17520@foo.birdnet.se>
On Sat, Dec 13, 2003 at 10:52:20PM -0700, ron minnich wrote:
> On Sun, 14 Dec 2003, Peter Stuge wrote:
>
> > I'm not quite sure about the status of the EPIA port in the version 2 CVS
> > tree, but it's there and there's been work put into it so it should probably
> > compile and work just fine.
>
> EPIA is fine in V2, not perfect but FAR better than EPIA in v1.
>
> We want to clean up EPIA completely, then fix up EPIA-M, but there have
> been some distractions (SC '03).
Ah, yes, that's right.
I can't wait until I actually have the time to sit down and do something
with LinuxBIOS, last time was over two years ago, there's been an amazing
evolution of the code. I can easily imagine running LinuxBIOS 3 or 4 on
_MANY_ systems in another year or two. It seems vendors (like Tyan) are
picking up too, which is great. Just don't take over all of their competent
people over at LANL, at least not until there's support for all of their
boards in the tree.. >:)
Just a short note to celebrate your success. :)
//Peter
From parit_top at yahoo.com Sun Dec 14 13:38:01 2003
From: parit_top at yahoo.com (Parit Wattanasin)
Date: Sun Dec 14 13:38:01 2003
Subject: serial programming
In-Reply-To: <20031214170000.26080.21738.Mailman@nwn.definitive.org>
Message-ID: <20031214184048.54508.qmail@web10805.mail.yahoo.com>
--- linuxbios-request at clustermatic.org wrote:
> Send Linuxbios mailing list submissions to
> linuxbios at clustermatic.org
>
> To subscribe or unsubscribe via the World Wide Web,
> visit
>
>
http://www.clustermatic.org/mailman/listinfo/linuxbios
> or, via email, send a message with subject or body
> 'help' to
> linuxbios-request at clustermatic.org
>
> You can reach the person managing the list at
> linuxbios-admin at clustermatic.org
>
> When replying, please edit your Subject line so it
> is more specific
> than "Re: Contents of Linuxbios digest..."
>
>
> Today's Topics:
>
> 1. serial programming (Parit Wattanasin)
> 2. Re: serial programming (Peter Stuge)
> 3. Re: serial programming (ron minnich)
> 4. Re: serial programming (Peter Stuge)
>
> --__--__--
>
> Message: 1
> Date: Sat, 13 Dec 2003 20:39:44 -0800 (PST)
> From: Parit Wattanasin
> Subject: serial programming
> To: linuxbios at clustermatic.org
>
> hi, I'm new for LinuxBIOS. I have problem about my
> mainboard(VIA-EPIA) Now I'm use LinuxBIOS but I
> want
> to customized it to chang payload from etherboot
> with
> my program about serial port(now this mainboard use
> serial console) how can I'change it(my program use
> assembly). Thank you for answer
>
> __________________________________
> Do you Yahoo!?
> New Yahoo! Photos - easier uploading and sharing.
> http://photos.yahoo.com/
>
> --__--__--
>
> Message: 2
> Date: Sun, 14 Dec 2003 06:14:45 +0100
> From: Peter Stuge
> To: linuxbios at clustermatic.org
> Subject: Re: serial programming
>
> On Sat, Dec 13, 2003 at 08:39:44PM -0800, Parit
> Wattanasin wrote:
> > hi, I'm new for LinuxBIOS. I have problem about my
> > mainboard(VIA-EPIA) Now I'm use LinuxBIOS but I
> want
> > to customized it to chang payload from etherboot
> with
> > my program about serial port(now this mainboard
> use
> > serial console) how can I'change it(my program use
> > assembly). Thank you for answer
>
> The payload can be exchanged from Etherboot to
> another self-contained ELF
> file simply by recompiling LinuxBIOS.
>
> I'm not quite sure about the status of the EPIA port
> in the version 2 CVS
> tree, but it's there and there's been work put into
> it so it should probably
> compile and work just fine.
>
> The best bet is to check the mailing list archives
> for information, and then
> grab the CVS code, or a snapshot, and make your own
> build.
>
> While making your own build you can also take out
> all serial port activity
> not needed for your application, of course.
>
>
> //Peter
>
> --__--__--
>
> Message: 3
> Date: Sat, 13 Dec 2003 22:52:20 -0700 (MST)
> From: ron minnich
> To: Peter Stuge
> cc: linuxbios at clustermatic.org
> Subject: Re: serial programming
>
> On Sun, 14 Dec 2003, Peter Stuge wrote:
>
> > I'm not quite sure about the status of the EPIA
> port in the version 2 CVS
> > tree, but it's there and there's been work put
> into it so it should probably
> > compile and work just fine.
>
> EPIA is fine in V2, not perfect but FAR better than
> EPIA in v1.
>
> We want to clean up EPIA completely, then fix up
> EPIA-M, but there have
> been some distractions (SC '03).
>
> ron
>
>
> --__--__--
>
> Message: 4
> Date: Sun, 14 Dec 2003 08:37:08 +0100
> From: Peter Stuge
> To: linuxbios at clustermatic.org
> Subject: Re: serial programming
>
> On Sat, Dec 13, 2003 at 10:52:20PM -0700, ron
> minnich wrote:
> > On Sun, 14 Dec 2003, Peter Stuge wrote:
> >
> > > I'm not quite sure about the status of the EPIA
> port in the version 2 CVS
> > > tree, but it's there and there's been work put
> into it so it should probably
> > > compile and work just fine.
> >
> > EPIA is fine in V2, not perfect but FAR better
> than EPIA in v1.
> >
> > We want to clean up EPIA completely, then fix up
> EPIA-M, but there have
> > been some distractions (SC '03).
>
> Ah, yes, that's right.
>
> I can't wait until I actually have the time to sit
> down and do something
> with LinuxBIOS, last time was over two years ago,
> there's been an amazing
> evolution of the code. I can easily imagine running
> LinuxBIOS 3 or 4 on
> _MANY_ systems in another year or two. It seems
> vendors (like Tyan) are
> picking up too, which is great. Just don't take over
> all of their competent
> people over at LANL, at least not until there's
> support for all of their
> boards in the tree.. >:)
>
> Just a short note to celebrate your success. :)
>
>
> //Peter
>
>
> --__--__--
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
>
http://www.clustermatic.org/mailman/listinfo/linuxbios
>
>
> End of Linuxbios Digest
I'm assemble my serial program to elf-format and
exchange for etherboot.It has error
=LinuxBIOS-1.0.0 Wed Dec 3 11:26:55 ICT 2003
starting..
=Enabled first bank of RAM: 0x08000000 bytes
=Copying LinuxBIOS to ram.
=Jumping to LinuxBIOS.
=POST: 0x39
=LinuxBIOS-1.0.0 Wed Dec 3 11:26:55 ICT 2003
booting...
=POST: 0x40
=...
=...
=...
=Copying IRQ routing tables to 0xf0000...done.
=Verifing priq routing tables copy at
0xf0000...succeed
=POST: 0x96
=Wrote linuxbios table at: 00000500 - 000006b0
=checksum 8255
=
=Welcome to elfboot, the open sourced starter.
=January 2002, Eric Biederman.
=Version 1.2
=
=POST: 0xf8
37:init_bytes() - zkernel_start:0xfff00000
=zkernel_mask:0x0000ffff
=Found ELF candiate at offset 0
=New segment addr 0x8048000 size 0xa6 offset 0x0
=filesize 0xa6
=(cleaned up) New segment addr 0x8048000 size 0xa6
=offset 0x0 filesize 0xa6
=Cannot Load ELF Image
=POST: 0xff=
__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
From dwh at lanl.gov Mon Dec 15 00:12:00 2003
From: dwh at lanl.gov (Hendricks David W.)
Date: Mon Dec 15 00:12:00 2003
Subject: VIA EPIA mini-ITX mainboards
In-Reply-To: <000001c3bfd1$881ce150$9512cecb@etechtxp1>
Message-ID:
Yeah, Slasdot obviously is not intended to be used as a message forum for
lingering discussion.
Ron has a working image that was used for what I gather is a similar
mainboard. Output from lspci would also be helpful so that we can make
sure the hardware on your board is the same as the hardware on ours
(Whatever came in the ITuner Minibox M-100's).
P.S. I cc'd this e-mail to the mailing list (
http://www.clustermatic.org/pipermail/linuxbios/2003-December/ ) since
the EPIA is a rather popular platform and others might be able to offer
help in this matter.
Etherboot can boot a kernel over a LAN, and IDE disk, floppy, and probably
some others too. Are you using an ethernet bridge like a Linksys WET11
or an add-in PCI or USB wireless device?
On Thu, 11 Dec 2003, Sonam Chauhan wrote:
> [ Re: http://bsd.slashdot.org/comments.pl?sid=87041&cid=7567224 ]
>
> Hi - Thanks for offering to help with your experience flashing VIA EPIA
> mini-ITX mainboards. Sorry, I didn't see your reply until recently. :)
>
> You wrote:
> > If you're using the 500MHz/800MHz normal SDRAM version, I'll send
> > you a ROM I used with the old freebios tree and an Etherboot
> > payload.
> That'd be great! Yes, I have the 533 MHz fanless EPIA ESP 5000 board
> with PC 133 SDRAM.
>
> By etherboot, do you mean that the board can boot remotely from LAN,
> using the onboard ethernet port? If so, that's excellent! Out of
> curiosity, do you see any problem with the Mini-ITX board etherbooting
> via a 802.11 wireless access point it is connected to with it's ethernet
> interface?
>
> With best regards,
> Sonam Chauhan
>
From niki.waibel at newlogic.com Mon Dec 15 04:53:01 2003
From: niki.waibel at newlogic.com (Niki Waibel)
Date: Mon Dec 15 04:53:01 2003
Subject: EPIA-M + second serial port enabler
In-Reply-To: <200312091808.hB9I8phP028465@xdr.com>
Message-ID: <200312150955.hBF9tf84006867@enterprise2.newlogic.at>
i'd just like to confirm that the 2nd serial port on the epia-m
works if you do the modifications dave describes.
niki
On 09-Dec-2003 Dave Ashley wrote:
> In a previous email message
> http://www.clustermatic.org/pipermail/linuxbios/2003-November/005891.html
>
> I wrote
> In V1 the file to modify is src/superio/via/vt1211/setup_serial.inc
> That code sets up ttyS0 which is the VT1211's logical device 2. You
> want to add some similiar code for logical device 3 to get ttyS1 working.
>
> Assuming you want it to be at 2f8 you'd merge in these lines:
> OUTPNPADDR($7)
> OUTPNPDATA($3)
> /* set the enable in reg. 0x30 */
> OUTPNPADDR($0x30)
> OUTPNPDATA($0x1)
>
> /* Serial Port 2 Base Address (BEh) */
> OUTPNPADDR($0x60)
> OUTPNPDATA($0xbe)
> /* Serial Port 2 IRQ (03h) */
> OUTPNPADDR($0x70)
> OUTPNPDATA($0x3)
> /* Serial Port 2 Control */
> OUTPNPADDR($0xf0)
> OUTPNPDATA($0x2)
>
> ...then do the turn off pnp
> /* turn off PnP */
> OUTPNPADDR($0xaa)
>
> ...then duplicate the serial setup except the address goes from 3f8 -> 2f8
>
>
> There is a piece missing. I had to enable the second serial port on the VT1211
> and although linux recognized it, there was no serial activity on the lines.
>
> These lines need to be added during the vt1211 configuration:
>
> /* Allow serial port 2 (ldn 3) pins to come out */
> OUTPNPADDR($0x27)
> OUTPNPDATA($00)
>
> This has to be before the $0xaa write to turn off configuration mode.
>
> The default value on powerup for this register on the vt1211 is 0xff.
> There are multi purpose pins on the chip and this connects them to the second
> serial port.
>
> -Dave
From linuxbios at xdr.com Wed Dec 17 14:10:01 2003
From: linuxbios at xdr.com (Dave Ashley)
Date: Wed Dec 17 14:10:01 2003
Subject: EPIA-M serial port 1/2 baud rate insanity
Message-ID: <200312171913.hBHJD25G000391@xdr.com>
I am at my wits end regarding how to get the serial ports on the epia-m to
run at full 115,200 baud rate. Here is a summary of what is known:
1) The serial ports are driven by the VT1211 superio chip.
2) Under AWARD bios the serial ports are capable of 115,200 operation.
3) Under linuxbios they can only run at 57,600 max.
4) Booting up with AWARD then soft reset (or hit reset button on motherboard)
into linuxbios still maintains 115,200 baud
5) Hard reset (power off then on) into linuxbios reduces maximum baud rate to
57,600.
6) All registers of the VT1211 are identical after linuxbios bootup, whether
from award -> softreset -> linuxbios bootup or hardreset -> linuxbios bootup.
I am speaking of all registers of all logical devices of the VT1211, including
all the global registers. I wrote a program to dump everything then diff'd the
two outputs, they're identical.
I have repeatedly tried asking VIA for help, in various different ways. The
VT1211 datasheet and the VT1211 bios porting guide have not resolved the
issue. VIA has proven incapable of addressing the problem.
I have one last idea. There is an emulator to test VGA bios's, I was messing
with it a few months back. Is there an emulator for the full BIOS? I'd like
to be able to watch all io port accesses of the award bios, maybe I can
trap when it goes to write to the 0x2e + 0x2f io ports to configure the
vt1211 serial ports, then look for something near there that might be related.
The idea would be to figure out what magical thing the AWARD bios is doing
to initialize the serial port.
Failing that is there any way to disassemble a BIOS image?
Any ideas welcome.
BTW if anyone has figured out how to fix the problem, please just f*cking
out with it, I think I've been very generous in the past with enhancements
and turnabout is fair play.
Thanks--
Dave
From rminnich at lanl.gov Wed Dec 17 16:25:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Wed Dec 17 16:25:01 2003
Subject: EPIA-M serial port 1/2 baud rate insanity [PMX:#]
In-Reply-To: <200312171913.hBHJD25G000391@xdr.com>
Message-ID:
I don't know what the problem is, I don't have an EPIA-M yet.
One thing you could do with a PCI analyzer is watch the ins and outs and
look for a magic setting.
Are your sure the clock source for the superio or uart is the same for
linuxbios and award?
disassembly is a bad idea.
The "emulator for VGA bios" will actually run anything that looks like a
bios. I've run T23 bios on a T23 (and crashed the T23 that way). So that
works.
ron
From linuxbios at xdr.com Wed Dec 17 17:47:00 2003
From: linuxbios at xdr.com (Dave Ashley)
Date: Wed Dec 17 17:47:00 2003
Subject: EPIA-M serial port 1/2 baud rate insanity
Message-ID: <200312172250.hBHMoLUL001502@xdr.com>
>I don't know what the problem is, I don't have an EPIA-M yet.
>...
>Are your sure the clock source for the superio or uart is the same for
>linuxbios and award?
>The "emulator for VGA bios" will actually run anything...
If sending you an epia-m would mean you'd begin looking at it I'll
get you one. Let me know.
I'm not sure of the clock source, VIA hasn't provided a schematic for the
board. The datasheet indicates 2 clock sources, one is for the LPC
interface and the other is for the main clock. LPC is the 33 mhz pci clock.
The other clock is 48 mhz. I had a scope on the chip and as near as I can
tell the 48 mhz clock was in fact 48 mhz. I didn't look at the 33 mhz clock
at all.
-Dave
From ijpriya at hotmail.com Wed Dec 17 21:45:01 2003
From: ijpriya at hotmail.com (Devi Priya)
Date: Wed Dec 17 21:45:01 2003
Subject: sc1200?
Message-ID:
Hi,
After power-on, the x86 processor is placed in real mode. That means the CPU
looks for the instruction at the address 0xffff0. Is it correct? In SC1200
datasheet, it is given that,
"Approximately 150 to 250 external clock cycles after RESET is deasserted,
the processor begins executing instructions at the top of physical memory
(address location
FFFFFFF0h). The actual number of clock cycles depends on the clock scaling
in use. Also, before execution begins, an additional 220 clock cycles are
needed when self-test is
requested. Typically, an intersegment jump is placed at FFFFFFF0h. This
instruction will force the processor to begin execution in the lowest 1 MB
of address space."
In real mode, the CPU can address only 1 MB. Then how this address could be
addressed by the CPU?
To which address does my Flash memory gets mapped to at power-on?
_________________________________________________________________
Don?t miss out on jobs that are not advertised.
http://go.msnserver.com/IN/38902.asp Post your CV on naukri.com today.
From aip at cwlinux.com Wed Dec 17 22:24:01 2003
From: aip at cwlinux.com (Andrew Ip)
Date: Wed Dec 17 22:24:01 2003
Subject: EPIA-M serial port 1/2 baud rate insanity
In-Reply-To: <200312171913.hBHJD25G000391@xdr.com>; from Dave Ashley on Wed, Dec 17, 2003 at 11:13:02AM -0800
References: <200312171913.hBHJD25G000391@xdr.com>
Message-ID: <20031218112744.A21757@mail.cwlinux.com>
Hi Dave,
Have you checked out the clock connected to LPC? On W311, FS2 can be
set to 24 or 48 MHz. It could be the problem, since I have similar problem
with USB on a custom cle266 board. FYI, it can be programmed thru smb.
Here is from we have done to program the USB clock.
#define SMB_BASE_ADDRESS 0x5000
#define SMB_STATUS (SMB_BASE_ADDRESS + 0)
#define SMB_CONTROL (SMB_BASE_ADDRESS + 2)
#define SMB_COMMAND (SMB_BASE_ADDRESS + 3)
#define SMB_ADDRESS (SMB_BASE_ADDRESS + 4)
#define SMB_DATA (SMB_BASE_ADDRESS + 5)
#define I2C_TRANS_CMD 0x40
#define CLOCK_SLAVE_ADDRESS 0x69
static void ext_clock_fixup(void)
{
int dt;
struct pci_dev *dev;
dev = pci_find_device(PCI_VENDOR_ID_VIA, 0x3177, 0);
if (dev != NULL)
{
printk_info("ext clock setting\n");
// SMB IO address 5000h
pci_write_config_byte(dev, 0xD1, (SMB_BASE_ADDRESS>>8)&0xff );
pci_write_config_byte(dev, 0xD0, SMB_BASE_ADDRESS&0xff );
// enable SMB
pci_write_config_byte(dev, 0xD2, 0x01);
// clear status
outb( 0xff, SMB_STATUS );
// USB out 48MHz
outb( 0x7f, SMB_DATA );
outb( 0x83, SMB_COMMAND );
outb( (CLOCK_SLAVE_ADDRESS<<1), SMB_ADDRESS );
outb( 0x8|I2C_TRANS_CMD, SMB_CONTROL );
while( inb(SMB_STATUS) & 0x01 );
}
}
You may want to put similar code in serial init. Hope this help.
-Andrew
On Wed, Dec 17, 2003 at 11:13:02AM -0800, Dave Ashley wrote:
> I am at my wits end regarding how to get the serial ports on the epia-m to
> run at full 115,200 baud rate. Here is a summary of what is known:
>
> 1) The serial ports are driven by the VT1211 superio chip.
> 2) Under AWARD bios the serial ports are capable of 115,200 operation.
> 3) Under linuxbios they can only run at 57,600 max.
> 4) Booting up with AWARD then soft reset (or hit reset button on motherboard)
> into linuxbios still maintains 115,200 baud
> 5) Hard reset (power off then on) into linuxbios reduces maximum baud rate to
> 57,600.
> 6) All registers of the VT1211 are identical after linuxbios bootup, whether
> from award -> softreset -> linuxbios bootup or hardreset -> linuxbios bootup.
> I am speaking of all registers of all logical devices of the VT1211, including
> all the global registers. I wrote a program to dump everything then diff'd the
> two outputs, they're identical.
>
> I have repeatedly tried asking VIA for help, in various different ways. The
> VT1211 datasheet and the VT1211 bios porting guide have not resolved the
> issue. VIA has proven incapable of addressing the problem.
>
> I have one last idea. There is an emulator to test VGA bios's, I was messing
> with it a few months back. Is there an emulator for the full BIOS? I'd like
> to be able to watch all io port accesses of the award bios, maybe I can
> trap when it goes to write to the 0x2e + 0x2f io ports to configure the
> vt1211 serial ports, then look for something near there that might be related.
> The idea would be to figure out what magical thing the AWARD bios is doing
> to initialize the serial port.
>
> Failing that is there any way to disassemble a BIOS image?
>
> Any ideas welcome.
>
> BTW if anyone has figured out how to fix the problem, please just f*cking
> out with it, I think I've been very generous in the past with enhancements
> and turnabout is fair play.
>
> Thanks--
> Dave
>
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
--
Andrew Ip
Email: aip at cwlinux.com
Tel: (852) 2542 2046
Fax: (852) 2542 2036
Mobile: (852) 9201 9866
Cwlinux Limited
Unit 202B 2/F Lai Cheong Factory Building,
479-479A Castle Peak Road,
Lai Chi Kok, Kowloon,
Hong Kong.
For public pgp key, please obtain it from http://www.keyserver.net/en.
From rminnich at lanl.gov Thu Dec 18 00:04:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Thu Dec 18 00:04:01 2003
Subject: sc1200?
In-Reply-To:
Message-ID:
at power-on, on all chipsets for PCs I have used, FLASH is mapped at BOTH
0xffffff0 and 0xffff0.
ron
From ijpriya at hotmail.com Thu Dec 18 01:18:01 2003
From: ijpriya at hotmail.com (Devi Priya)
Date: Thu Dec 18 01:18:01 2003
Subject: sc1200?
Message-ID:
Thanks for ur suggestion.
My flash is 4 MB. My processor can address up to 4 GB physical address
space. That means after power-on, in shematic should I map the flash memory
like 0xFFC00000-0xFFFFFFFF and
0x00000000-0x003FFFFF? 0r in upper address, is it enough to map the 256KB
region to the Flash ie 0xFFFC0000-0xFFFFFFFF? and the lower address to
0x00000000-0x003FFFFF
>From: ron minnich
>To: Devi Priya
>CC: linuxbios at clustermatic.org
>Subject: Re: sc1200?
>Date: Wed, 17 Dec 2003 22:07:00 -0700 (MST)
>
>at power-on, on all chipsets for PCs I have used, FLASH is mapped at BOTH
>0xffffff0 and 0xffff0.
>
>ron
>
>_______________________________________________
>Linuxbios mailing list
>Linuxbios at clustermatic.org
>http://www.clustermatic.org/mailman/listinfo/linuxbios
_________________________________________________________________
Don?t miss out on jobs that are not advertised.
http://go.msnserver.com/IN/38902.asp Post your CV on naukri.com today.
From ollie at lanl.gov Thu Dec 18 11:12:00 2003
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Dec 18 11:12:00 2003
Subject: sc1200?
In-Reply-To:
References:
Message-ID: <1071764089.4956.136.camel@exponential.lanl.gov>
On Wed, 2003-12-17 at 23:21, Devi Priya wrote:
> Thanks for ur suggestion.
> My flash is 4 MB. My processor can address up to 4 GB physical address
> space. That means after power-on, in shematic should I map the flash memory
> like 0xFFC00000-0xFFFFFFFF and
> 0x00000000-0x003FFFFF? 0r in upper address, is it enough to map the 256KB
> region to the Flash ie 0xFFFC0000-0xFFFFFFFF? and the lower address to
> 0x00000000-0x003FFFFF
>
Are you building your own mainboard ? Usually this mapping stuff
is done by the southbridge or superio chip, you don't and can't
do anything about.
BTW, are you sure your flash is 4MByte instead of 4Mbits ?
Ollie
From rminnich at lanl.gov Thu Dec 18 12:39:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Thu Dec 18 12:39:00 2003
Subject: sc1200?
In-Reply-To:
Message-ID:
You're building hardware?
ron
From rminnich at lanl.gov Thu Dec 18 12:40:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Thu Dec 18 12:40:01 2003
Subject: sc1200?
In-Reply-To:
Message-ID:
On Thu, 18 Dec 2003, Devi Priya wrote:
>
> Thanks for ur suggestion.
> My flash is 4 MB. My processor can address up to 4 GB physical address
> space. That means after power-on, in shematic should I map the flash memory
> like 0xFFC00000-0xFFFFFFFF and
ffe00000-ffffffff and e0000-fffff
From bari at onelabs.com Thu Dec 18 12:40:04 2003
From: bari at onelabs.com (Bari Ari)
Date: Thu Dec 18 12:40:04 2003
Subject: sc1200?
In-Reply-To:
References:
Message-ID: <3FE1E769.6040007@onelabs.com>
Devi Priya wrote:
>
> Thanks for ur suggestion.
> My flash is 4 MB. My processor can address up to 4 GB physical address
> space. That means after power-on, in shematic should I map the flash
> memory like 0xFFC00000-0xFFFFFFFF and
> 0x00000000-0x003FFFFF? 0r in upper address, is it enough to map the
> 256KB region to the Flash ie 0xFFFC0000-0xFFFFFFFF? and the lower
> address to 0x00000000-0x003FFFFF
>
>> From: ron minnich
>> To: Devi Priya
>> CC: linuxbios at clustermatic.org
>> Subject: Re: sc1200?
>> Date: Wed, 17 Dec 2003 22:07:00 -0700 (MST)
>>
>> at power-on, on all chipsets for PCs I have used, FLASH is mapped at BOTH
>> 0xffffff0 and 0xffff0.
>>
From the AMD data sheet:
The Core Logic module positively decodes memory
addresses 000F0000h-000FFFFFh (64 KB) and
FFFC0000h-FFFFFFFFh (256 KB) at reset. These memory
cycles cause the Core Logic module to claim the cycle, and
generate an ISA bus memory cycle with ROMCS#
asserted. The Core Logic module can also be configured to
respond to memory addresses FF000000h-FFFFFFFFh
(16 MB) and 000E0000h-000FFFFFh (128 KB).
8- or 16-bit wide ROM is supported. BOOT16 strap determines
the width after reset. MCR[14,3] (Offset 34h) in the
General Configuration Block allows program control of the width.
Flash ROM is supported in the Core Logic module by
enabling the ROMCS# signal on write accesses to the
ROM region. Normally only read cycles are passed to the
ISA bus, and the ROMCS# signal is suppressed for write
cycles. When the ROM Write Enable bit (F0 Index 52h[1])
is set, a write access to the ROM address region causes a
write cycle to occur with MEMW#,WR# and ROMCS#
asserted.
The Boot Flash supported by the SC1200/SC1201 can be
up to 16 MB. It is supported with the ROMCS# signal.
DOCCS#
? Asserted on memory read/write transactions from/to
a programmable window.
? ROMCS#
? Asserted on memory read/write to upper 16 MB of
address space. Configurable via the ROM Mask
register (F0 Index 6Eh).
? DOCR#
? DOCR# is asserted on memory read transactions
from DOCCS# window (i.e., when both DOCCS# and
MEMR# are active, DOCR# is active; otherwise, it is
inactive).
? DOCW
? DOCW# is asserted on memory write transactions to
DOCCS# window (i.e., when both DOCCS# and
MEMW# are active, DOCW# is active; otherwise, it is
inactive).
? RD#, WR#
? The signals IOR#, IOW#, MEMR#, and MEMW# are
combined into two signals: RD# is asserted on I/O
read or memory read; WR# is asserted on I/O write
or memory write.
Memory devices that use ROMCS# or DOCCS# as their
chip select signal can be configured to support an 8-bit or
16-bit data bus via bits 3 and 6 of the MCR register. Such
devices can also be configured as zero wait states devices
(regardless of the data bus width) via bits 9 and 10 of the
MCR register.
The DiskOnChip chip select signal (DOCCS#) is asserted
on any memory read or memory write transaction from/to a
programmable address range. The address range is pro-grammable
via the DOCCS#Base Address and Control
registers (F0 Index 78h and 7Ch). The base address must
be on an address boundary, the size of the range.
Signal DOCCS# can also be used to interface to NAND
Flash devices together with signals DOCW# and DOCR#.
See application note AMD Geode? SC1200/SC2200/
SC3200 Processors: External NAND Flash Memory Circuit
for details.
This you'll have to get from AMD. It goes into using the DOC for boot
ROM and also as a general storage device. It also contains IPL and SPL
code along with the boot procedure, memory map, etc.
-Bari
From linuxbios at xdr.com Thu Dec 18 12:42:01 2003
From: linuxbios at xdr.com (Dave Ashley)
Date: Thu Dec 18 12:42:01 2003
Subject: EPIA-M serial port 1/2 baud rate insanity
Message-ID: <200312181745.hBIHjEnL006550@xdr.com>
Andrew Ip wrote:
>Have you checked out the clock connected to LPC? On W311, FS2 can be
>set to 24 or 48 MHz. It could be the problem, since I have similar problem
>with USB on a custom cle266 board. FYI, it can be programmed thru smb.
>Here is from we have done to program the USB clock.
>...
>You may want to put similar code in serial init. Hope this help.
I tried this and...it worked! My simple test program is below. Linuxbios
puts the smb stuff at 0xf00 and it is already enabled (at least in my patch).
So all I had to do was do the outb's to get it to work. Thanks *very* much.
Note to Ron: Let me know if you want the epia-m, I'll still send one off if
you want it. I've got a spare 10000 (1 gig) that you can have. Note I
don't read email sent to the address I'm posting from...best send to
dash at xdr.com to get to me.
#include
#include
#include
#include
#include
#define SMB_STATUS (base + 0)
#define SMB_CONTROL (base + 2)
#define SMB_COMMAND (base + 3)
#define SMB_ADDRESS (base + 4)
#define SMB_DATA (base + 5)
#define I2C_TRANS_CMD 0x40
#define CLOCK_SLAVE_ADDRESS 0x69
int main(int argc, char **argv)
{
int res;
int base=0xf00;
res=iopl(3);
if(res)
{
perror("iopl");
exit(-1);
}
outb( 0xff, SMB_STATUS );
// USB out 48MHz
outb( 0x7f, SMB_DATA );
outb( 0x83, SMB_COMMAND );
outb( (CLOCK_SLAVE_ADDRESS<<1), SMB_ADDRESS );
outb( 0x8|I2C_TRANS_CMD, SMB_CONTROL );
while( inb(SMB_STATUS) & 0x01 );
}
-Dave
From linuxbios at xdr.com Thu Dec 18 13:31:01 2003
From: linuxbios at xdr.com (Dave Ashley)
Date: Thu Dec 18 13:31:01 2003
Subject: EPIA-M serial port 1/2 baud rate insanity
Message-ID: <200312181834.hBIIY5LP006669@xdr.com>
Here is what I did to integrate this into linuxbios. I
created the following file
src/mainboard/via/epia-m/smbusenable.inc
/* Useful macros PCIBUS, and SMBUS functions for getting DRAM going. */
/* courtesy Eric Biederman of linuxnetworx.com */
#define CS_WRITE_BYTE(addr, byte) \
movl $addr, %eax ; \
movl $byte, %edx ; \
PCI_WRITE_CONFIG_BYTE
#define CS_WRITE_WORD(addr, word) \
movl $addr, %eax ; \
movl $word, %ecx ; \
PCI_WRITE_CONFIG_WORD
#define CS_WRITE_LONG(addr, dword) \
movl $addr, %eax ; \
movl $dword, %ecx ; \
PCI_WRITE_CONFIG_DWORD
#define DEVFN(device, function) (((device) << 3) + (function))
#ifndef CONFIG_ADDR
#define CONFIG_ADDR(bus,devfn,where) (((bus) << 16) | ((devfn) << 8) | (where))
#endif
/* generic SMB routines that work for many systems. The only one that might
* not work is the enable_smbus.
* you have to define PM_FUNCTION for this to work.
*/#define SMBUS_IO_BASE 0xf00
#define SMBHSTSTAT 0
#define SMBHSTCTL 2
#define SMBHSTCMD 3
#define SMBHSTADD 4
#define SMBHSTDAT0 5
#define SMBHSTDAT1 6
#define SMBBLKDAT 7
/* (DA) Lines added to get this to compile */
#define PM_DEVFN CONFIG_ADDR(0,0x11*8,0)
#define DRAM_CONFIG_PORT 0x5a
#define SMBUS_MEM_DEVICE_0 0x50
#define LAST_SMBUS_MEM_DEVICE SMBUS_MEM_DEVICE_0
#define REGISTERED_DRAM_REGISTER $0x69
#define REGISTERED_DRAM $0x2d
#define NONREGISTERED_DRAM $0
/* put the SMBUS at port 0xf00 + enable*/
CS_WRITE_WORD(PM_DEVFN+ 0xd0, SMBUS_IO_BASE|1) /* iobase addr */
CS_WRITE_BYTE(PM_DEVFN + 0xd2, (0x4 << 1) | 1) /* smbus enable */
CS_WRITE_WORD(PM_DEVFN + 0x4, 1) /* iospace enable */
/* The VT1211 serial port needs 48 mhz clock, on power up it is getting
only 24 mhz, there is some mysterious device on the smbus that can
fix this...this code below does it. */
#define MYOUTB(val, port) movb val, %al; movw port, %dx ; outb %al, %dx
#define I2C_TRANS_CMD 0x40
#define CLOCK_SLAVE_ADDRESS 0x69
MYOUTB( $0xff, $(SMBUS_IO_BASE+SMBHSTSTAT))
MYOUTB( $0x7f, $(SMBUS_IO_BASE+SMBHSTDAT0))
MYOUTB( $0x83, $(SMBUS_IO_BASE+SMBHSTCMD))
MYOUTB( $(CLOCK_SLAVE_ADDRESS<<1), $(SMBUS_IO_BASE+SMBHSTADD))
MYOUTB( $(8 | I2C_TRANS_CMD), $(SMBUS_IO_BASE+SMBHSTCTL))
movw $(SMBUS_IO_BASE+SMBHSTSTAT), %dx
smbwait1:
inb %dx, %al
and $1, %al
jnz smbwait1
----- Now in src/mainboard/via/epia-m/Config we need to include the above
file, so it ends up looking like this:
mainboardinit mainboard/via/epia-m/smbusenable.inc
mainboardinit superio/via/vt1211/setup_serial.inc
mainboardinit pc80/serial.inc
-Dave
From brian.thomason at lindows.com Thu Dec 18 16:21:01 2003
From: brian.thomason at lindows.com (Brian Thomason)
Date: Thu Dec 18 16:21:01 2003
Subject: Intel 82845G/GL
Message-ID: <3FE21B1F.6070706@lindows.com>
I scanned the entire mailing and website for LinuxBIOS and didn't see a
single reference to the Intel 82845G/GL. Is this configuration
supported? If not, would it be "easy" to add support for it?
I'm very new to LinuxBIOS (just discovered the website a month or so ago
and still don't fully grok it) but have two machines with this chipset
I'd like to get setup as sample boxes to show my boss the increase in
boot time. (From what I hear, it speeds up boot time CONSIDERABLY)
Thanks in advance for your time,
Brian Thomason
Lindows.com Developer Relations
From rminnich at lanl.gov Thu Dec 18 16:29:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Thu Dec 18 16:29:00 2003
Subject: Intel 82845G/GL
In-Reply-To: <3FE21B1F.6070706@lindows.com>
Message-ID:
On Thu, 18 Dec 2003, Brian Thomason wrote:
> I scanned the entire mailing and website for LinuxBIOS and didn't see a
> single reference to the Intel 82845G/GL. Is this configuration
> supported? If not, would it be "easy" to add support for it?
not done yet. started, but not done.
>
> I'm very new to LinuxBIOS (just discovered the website a month or so ago
> and still don't fully grok it) but have two machines with this chipset
> I'd like to get setup as sample boxes to show my boss the increase in
> boot time. (From what I hear, it speeds up boot time CONSIDERABLY)
have you done this type of hacking before? if so, you can probably get
there.
ron
From brian.thomason at lindows.com Thu Dec 18 16:33:01 2003
From: brian.thomason at lindows.com (Brian Thomason)
Date: Thu Dec 18 16:33:01 2003
Subject: Intel 82845G/GL
In-Reply-To:
References:
Message-ID: <3FE21DD6.5040409@lindows.com>
Unfortunately, no. I'm a lowly web programmer at this point.
(Python/PHP/Perl)
I learn quite quickly though - Who's currently working on this chipset?
-Brian
ron minnich wrote:
>On Thu, 18 Dec 2003, Brian Thomason wrote:
>
>
>
>>I scanned the entire mailing and website for LinuxBIOS and didn't see a
>>single reference to the Intel 82845G/GL. Is this configuration
>>supported? If not, would it be "easy" to add support for it?
>>
>>
>
>not done yet. started, but not done.
>
>
>>I'm very new to LinuxBIOS (just discovered the website a month or so ago
>>and still don't fully grok it) but have two machines with this chipset
>>I'd like to get setup as sample boxes to show my boss the increase in
>>boot time. (From what I hear, it speeds up boot time CONSIDERABLY)
>>
>>
>
>have you done this type of hacking before? if so, you can probably get
>there.
>
>ron
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From dwh at lanl.gov Thu Dec 18 17:32:00 2003
From: dwh at lanl.gov (Hendricks David W.)
Date: Thu Dec 18 17:32:00 2003
Subject: Intel 82845G/GL
In-Reply-To: <3FE21B1F.6070706@lindows.com>
Message-ID:
That's a graphics chip, correct? Unfortunately, we're still working on
initializing VGA BIOSes (Particularly on GeForce cards).
However, there are some boards which have VGA working in LinuxBIOS, like
the VIA EPIA mini-itx board with an integrated graphics controller. I
haven't tried booting KDE with it yet, but I imagine the BIOS and kernel
could load at least as fast as KDE itself.
As for your Intel 82845G/GL, could you please post lspci output? As I
recall, the 82845 is on the i845 chipset, uses the 82801DB PCI
controller and the e7501 (ICH4) memory controller hub. Eric Beiderman got
that chipset, or at least a very similar one, working with the Supermicro
X5DPR in the freebios1 tree (I don't think it's in freebios2 yet). I can't
say you'll get VGA output without some serious hacking around, but you
should at least be able to boot it, get some serial output, and SSH in if
all goes well and your kernel boots.
By the way, and I hate to get off-topic, how is Micheal doing in
Europe? I've read about the lawsuits on The Register, but they don't seem
to have a very positive outlook :(
On Thu, 18 Dec 2003, Brian Thomason wrote:
> I scanned the entire mailing and website for LinuxBIOS and didn't see a
> single reference to the Intel 82845G/GL. Is this configuration
> supported? If not, would it be "easy" to add support for it?
>
> I'm very new to LinuxBIOS (just discovered the website a month or so ago
> and still don't fully grok it) but have two machines with this chipset
> I'd like to get setup as sample boxes to show my boss the increase in
> boot time. (From what I hear, it speeds up boot time CONSIDERABLY)
>
> Thanks in advance for your time,
>
> Brian Thomason
> Lindows.com Developer Relations
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>
From brian.thomason at lindows.com Thu Dec 18 17:50:01 2003
From: brian.thomason at lindows.com (Brian Thomason)
Date: Thu Dec 18 17:50:01 2003
Subject: Intel 82845G/GL
In-Reply-To:
References:
Message-ID: <3FE22FFB.20002@lindows.com>
Hendricks David W. wrote:
>That's a graphics chip, correct? Unfortunately, we're still working on
>initializing VGA BIOSes (Particularly on GeForce cards).
>
Come to find out, it is a graphics chip (I don't know hardware very
well, so please bear with me :-) )
I also know very little in the way of LinuxBIOS and how it works. It is
disheartening to hear GeForce cards aren't supported as of yet.
>However, there are some boards which have VGA working in LinuxBIOS, like
>the VIA EPIA mini-itx board with an integrated graphics controller.
>
I believe our resellers sell some PC's with this installed, so that is
good to hear.
>I haven't tried booting KDE with it yet, but I imagine the BIOS and kernel
>could load at least as fast as KDE itself.
>
>As for your Intel 82845G/GL, could you please post lspci output?
>
00:00.0 Host bridge: Intel Corp. 82845G/GL [Brookdale-G] Chipset Host
Bridge (rev 03)
00:01.0 PCI bridge: Intel Corp. 82845G/GL [Brookdale-G] Chipset AGP
Bridge (rev 03)
00:1d.0 USB Controller: Intel Corp. 82801DB USB (Hub #1) (rev 02)
00:1d.1 USB Controller: Intel Corp. 82801DB USB (Hub #2) (rev 02)
00:1d.2 USB Controller: Intel Corp. 82801DB USB (Hub #3) (rev 02)
00:1d.7 USB Controller: Intel Corp. 82801DB USB EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB PCI Bridge (rev 82)
00:1f.0 ISA bridge: Intel Corp. 82801DB ISA Bridge (LPC) (rev 02)
00:1f.1 IDE interface: Intel Corp. 82801DB ICH4 IDE (rev 02)
00:1f.3 SMBus: Intel Corp. 82801DB SMBus (rev 02)
00:1f.5 Multimedia audio controller: Intel Corp. 82801DB AC'97 Audio
(rev 02)
01:00.0 VGA compatible controller: nVidia Corporation NV11 [GeForce2
MX/MX 400] (rev b2)
02:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
> As I recall, the 82845 is on the i845 chipset,
>
How would I verify this?
>uses the 82801DB PCI controller and the e7501 (ICH4) memory controller hub.
>
You know your hardware don't you? :-)
>Eric Beiderman got that chipset, or at least a very similar one, working with the Supermicro
>X5DPR in the freebios1 tree (I don't think it's in freebios2 yet). I can't
>say you'll get VGA output without some serious hacking around, but you
>should at least be able to boot it, get some serial output, and SSH in if
>all goes well and your kernel boots.
>
:-( Looks like I'll just have to track down a box with the VIA EPIA
mini-itx board you referred to.
>By the way, and I hate to get off-topic, how is Micheal doing in
>Europe? I've read about the lawsuits on The Register, but they don't seem
>to have a very positive outlook :(
>
Unfortunately, I'm not permitted to discuss that, but you can read about
them as they happen on ChoicePC.com.
Many thanks for the prompt and helpful reply.
-Brian
From ebiederman at lnxi.com Thu Dec 18 19:27:01 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Dec 18 19:27:01 2003
Subject: IDEA: Linux kernel and pcbios compatibility...
Message-ID:
Brainstorming earlier today I think I have found a way to use
an linux kernel for the boot loader and to implement pcbios
compatibility without too much cost. The idea is to use
a uclinux kernel. And implement a ``user space'' aplication
that is a user space shim that makes kernel calls.
There are a few nasty details to work out like how to handle
services that are expected to work in vm86 mode. But I'm
not certain I care.
Other thoughts?
After I come back from my christmas vacation I am going to have to try
it and see how will it will actually work.
Eric
From aip at cwlinux.com Thu Dec 18 19:30:01 2003
From: aip at cwlinux.com (Andrew Ip)
Date: Thu Dec 18 19:30:01 2003
Subject: EPIA-M serial port 1/2 baud rate insanity
In-Reply-To: <200312181745.hBIHjEnL006550@xdr.com>; from Dave Ashley on Thu, Dec 18, 2003 at 09:45:14AM -0800
References: <200312181745.hBIHjEnL006550@xdr.com>
Message-ID: <20031219083330.A5137@mail.cwlinux.com>
Hi Dave,
> I tried this and...it worked! My simple test program is below. Linuxbios
> puts the smb stuff at 0xf00 and it is already enabled (at least in my patch).
> So all I had to do was do the outb's to get it to work. Thanks *very* much.
Execellent. I will integrate it to the v1 tree. Thank you very much for
the patch. :)
-Andrew
--
Andrew Ip
Email: aip at cwlinux.com
Tel: (852) 2542 2046
Fax: (852) 2542 2036
Mobile: (852) 9201 9866
Cwlinux Limited
Unit 202B 2/F Lai Cheong Factory Building,
479-479A Castle Peak Road,
Lai Chi Kok, Kowloon,
Hong Kong.
For public pgp key, please obtain it from http://www.keyserver.net/en.
From joshua at joshuawise.com Thu Dec 18 20:27:00 2003
From: joshua at joshuawise.com (Joshua Wise)
Date: Thu Dec 18 20:27:00 2003
Subject: IDEA: Linux kernel and pcbios compatibility...
In-Reply-To:
References:
Message-ID: <200312182031.04720.joshua@joshuawise.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thursday 18 December 2003 7:36 pm, Eric W. Biederman wrote:
> Brainstorming earlier today I think I have found a way to use
> an linux kernel for the boot loader and to implement pcbios
> compatibility without too much cost. The idea is to use
> a uclinux kernel. And implement a ``user space'' aplication
> that is a user space shim that makes kernel calls.
The way I implement my bootloader on ARM is like this:
1) First stage assembly loader sets up serial and DRAM.
2) First stage loader probes RAM, and sets up tagged list.
3) First stage jumps into zImage of special LAB (Linux As Bootldr) kernel.
(currently just a 2.6.0 kernel from handhelds.org that has CONFIG_LAB
defined.)
4) LAB kernel boots up until it gets ready to jump into init.
5) #ifdef'ed code takes over and calls a LAB main function which does all
sorts of cool stuff including giving the user a CLI if requested (usually by
holding the iPAQ's joypad down), or autobooting (running a predefined
mkdir/mount/armboot sequence.)
Conceivably you could write a subapp for the CLI that does what you want, and
put it in the autoboot script.
LAB for ARM's zImage is currently ~509kbytes for those who care. (We must keep
it below 512KB.)
> There are a few nasty details to work out like how to handle
> services that are expected to work in vm86 mode. But I'm
> not certain I care.
I've tinkered with writing an OS, but I still don't know too much about the
x86 architecture, so I couldn't help there. Sorry.
> Other thoughts?
Check out my LAB code, see what you think. It's in handhelds.org anoncvs,
module linux/kernel26. Relevant crap is in bootldr/, drivers/bootldr/, and
arch/arm/boot/.
> After I come back from my christmas vacation I am going to have to try
> it and see how will it will actually work.
Take care, have a nice vacation.
> Eric
/joshua
- --
Joshua Wise | www.joshuawise.com
GPG Key | 0xEA80E0B3
Quote | I akilled *@* by mistake
In memoriam | Whiskers the hamster, 2001 - Dec 15, 2003
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE/4lTWPn9tWOqA4LMRAnd3AKCRojCaS1dGk7BHmp9RTxkCNjo/7QCfVAel
7kuNSdKY2Y5lg9QAdwGP5BQ=
=qD9C
-----END PGP SIGNATURE-----
From ebiederman at lnxi.com Fri Dec 19 00:17:00 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Dec 19 00:17:00 2003
Subject: IDEA: Linux kernel and pcbios compatibility...
In-Reply-To: <200312182031.04720.joshua@joshuawise.com>
References:
<200312182031.04720.joshua@joshuawise.com>
Message-ID:
Joshua Wise writes:
> On Thursday 18 December 2003 7:36 pm, Eric W. Biederman wrote:
> > Brainstorming earlier today I think I have found a way to use
> > an linux kernel for the boot loader and to implement pcbios
> > compatibility without too much cost. The idea is to use
> > a uclinux kernel. And implement a ``user space'' aplication
> > that is a user space shim that makes kernel calls.
>
> The way I implement my bootloader on ARM is like this:
>
> 1) First stage assembly loader sets up serial and DRAM.
> 2) First stage loader probes RAM, and sets up tagged list.
Roughly what LinuxBIOS does.
> 3) First stage jumps into zImage of special LAB (Linux As Bootldr) kernel.
> (currently just a 2.6.0 kernel from handhelds.org that has CONFIG_LAB
> defined.)
> 4) LAB kernel boots up until it gets ready to jump into init.
> 5) #ifdef'ed code takes over and calls a LAB main function which does all
> sorts of cool stuff including giving the user a CLI if requested (usually by
> holding the iPAQ's joypad down), or autobooting (running a predefined
> mkdir/mount/armboot sequence.)
>
> Conceivably you could write a subapp for the CLI that does what you want, and
> put it in the autoboot script.
Somehow I could write a subapp that would make linux look like a normal
pcbios, but I can be surprised.
> LAB for ARM's zImage is currently ~509kbytes for those who care. (We must keep
> it below 512KB.)
Ouch! My x86 images are below that, at least before decompression.
> > There are a few nasty details to work out like how to handle
> > services that are expected to work in vm86 mode. But I'm
> > not certain I care.
> I've tinkered with writing an OS, but I still don't know too much about the
> x86 architecture, so I couldn't help there. Sorry.
>
> > Other thoughts?
> Check out my LAB code, see what you think. It's in handhelds.org anoncvs,
> module linux/kernel26. Relevant crap is in bootldr/, drivers/bootldr/, and
> arch/arm/boot/.
I probably will. Doing that stuff inside the kernel does not really feel
proper to me. I already have an x86 kernel that can load another kernel
from user space. I'm just trying to find a good long term architecture
for using the kernel as a bootloader.
> > After I come back from my christmas vacation I am going to have to try
> > it and see how will it will actually work.
> Take care, have a nice vacation.
Thanks.
Eric
From rminnich at lanl.gov Fri Dec 19 00:29:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Fri Dec 19 00:29:01 2003
Subject: Intel 82845G/GL
In-Reply-To: <3FE22FFB.20002@lindows.com>
Message-ID:
On Thu, 18 Dec 2003, Brian Thomason wrote:
> Hendricks David W. wrote:
>
> >That's a graphics chip, correct? Unfortunately, we're still working on
> >initializing VGA BIOSes (Particularly on GeForce cards).
> >
> Come to find out, it is a graphics chip (I don't know hardware very
> well, so please bear with me :-) )
the 82845 is a north bridge.
> You know your hardware don't you? :-)
david really knows hardware quite well.
ron
From rminnich at lanl.gov Fri Dec 19 00:34:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Fri Dec 19 00:34:01 2003
Subject: IDEA: Linux kernel and pcbios compatibility...
In-Reply-To:
Message-ID:
well I sure like the idea of using linux for the bios, as always ...
ron
From rminnich at lanl.gov Fri Dec 19 00:34:05 2003
From: rminnich at lanl.gov (ron minnich)
Date: Fri Dec 19 00:34:05 2003
Subject: EPIA-M serial port 1/2 baud rate insanity
In-Reply-To: <20031219083330.A5137@mail.cwlinux.com>
Message-ID:
let's talk about that patch one more time before we commit.
ron
From ebiederman at lnxi.com Fri Dec 19 00:47:00 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Dec 19 00:47:00 2003
Subject: IDEA: Linux kernel and pcbios compatibility...
In-Reply-To:
References:
Message-ID:
ron minnich writes:
> well I sure like the idea of using linux for the bios, as always ...
Regardless of the actual details what I like is the added requirement
that we attempt to support the legacy pcbios interface. It's ugly it's
nasty but if we can do that with a Linux kernel driving the hardware
we have a single solution which can work for everyone. Some people
can strip it down and not include all of the features but...
Eric
From adam at cfar.umd.edu Fri Dec 19 00:51:01 2003
From: adam at cfar.umd.edu (Adam Sulmicki)
Date: Fri Dec 19 00:51:01 2003
Subject: IDEA: Linux kernel and pcbios compatibility...
In-Reply-To:
Message-ID: <20031219005706.H66505-100000@www.missl.cs.umd.edu>
you mean just like dosemu runs under linux ???
On 18 Dec 2003, Eric W. Biederman wrote:
>
> Brainstorming earlier today I think I have found a way to use
> an linux kernel for the boot loader and to implement pcbios
> compatibility without too much cost. The idea is to use
> a uclinux kernel. And implement a ``user space'' aplication
> that is a user space shim that makes kernel calls.
>
> There are a few nasty details to work out like how to handle
> services that are expected to work in vm86 mode. But I'm
> not certain I care.
>
> Other thoughts?
>
> After I come back from my christmas vacation I am going to have to try
> it and see how will it will actually work.
>
> Eric
>
>
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>
--
Adam Sulmicki
http://www.eax.com The Supreme Headquarters of the 32 bit registers
From ebiederman at lnxi.com Fri Dec 19 02:40:01 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Dec 19 02:40:01 2003
Subject: IDEA: Linux kernel and pcbios compatibility...
In-Reply-To: <20031219005706.H66505-100000@www.missl.cs.umd.edu>
References: <20031219005706.H66505-100000@www.missl.cs.umd.edu>
Message-ID:
Adam Sulmicki writes:
> you mean just like dosemu runs under linux ???
Right but for BSD and early versions of windows the dependencies
were worse. I don't know which services matter though.
Eric
From ts1 at tsn.or.jp Fri Dec 19 04:18:00 2003
From: ts1 at tsn.or.jp (Takeshi Sone)
Date: Fri Dec 19 04:18:00 2003
Subject: IDEA: Linux kernel and pcbios compatibility...
In-Reply-To:
References: <20031219005706.H66505-100000@www.missl.cs.umd.edu>
Message-ID: <20031219092135.GA27866@tsn.or.jp>
On Fri, Dec 19, 2003 at 12:49:42AM -0700, Eric W. Biederman wrote:
> Adam Sulmicki writes:
>
> > you mean just like dosemu runs under linux ???
>
> Right but for BSD and early versions of windows the dependencies
> were worse. I don't know which services matter though.
Last time I saw the source code of FreeBSD, its _bootloader_ has its
own vm86 monitor (in assembly), works in protected mode,
and calls all the BIOS calls (video, keyboard, disk,...) in
vm86 mode. Also the kernel calls E820, APM, VESA, etc in vm86.
Also I saw a recent version of Windows calls BIOS services in vm86.
Maybe we can modify FreeBSD, and have work-around for Windows,
but at least I don't think it's the way to go.
My conclusion then was that PCBIOS had to work in real mode.
Maybe we can code it with GCC and .code16gcc hack.
If 64KB is not enough, maybe 0xE000 segment can be used
so that we have 64KB code and 64KB data segments.
And all the "POST" code can be outside the real mode space.
So it's not impossible or hard at all.
--
Takeshi
From ebiederman at lnxi.com Fri Dec 19 06:49:01 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Dec 19 06:49:01 2003
Subject: IDEA: Linux kernel and pcbios compatibility...
In-Reply-To: <20031219092135.GA27866@tsn.or.jp>
References: <20031219005706.H66505-100000@www.missl.cs.umd.edu>
<20031219092135.GA27866@tsn.or.jp>
Message-ID:
Takeshi Sone writes:
> On Fri, Dec 19, 2003 at 12:49:42AM -0700, Eric W. Biederman wrote:
> > Adam Sulmicki writes:
> >
> > > you mean just like dosemu runs under linux ???
> >
> > Right but for BSD and early versions of windows the dependencies
> > were worse. I don't know which services matter though.
>
> Last time I saw the source code of FreeBSD, its _bootloader_ has its
> own vm86 monitor (in assembly), works in protected mode,
> and calls all the BIOS calls (video, keyboard, disk,...) in
> vm86 mode. Also the kernel calls E820, APM, VESA, etc in vm86.
> Also I saw a recent version of Windows calls BIOS services in vm86.
>
> Maybe we can modify FreeBSD, and have work-around for Windows,
> but at least I don't think it's the way to go.
Thanks. I knew this was the biggest danger, and from the description
it looks like no half measures will do.
> My conclusion then was that PCBIOS had to work in real mode.
If that is the case the PCBIOS has hit an evolutionary dead,
as the code size cannot increase, there is very little
room for change remaining. This explains ACPI. And
it makes EFI look much more attractive.
I think I see one way out of this pickle, implement the firmware
in System Management mode. System calls will be slow and we will
need an interrupt reflector but this does allow us to escape the
bounds of vm86 mode, and the legacy limitations. And our
OS will even have some protection from ``user mode''.
System Management mode is essentially big real mode. So
code would need to be compiled with .code16gcc, but there is
a full 4G available. I know with amd's processors I can switch to
32bit or 64bit protected mode inside of smm mode, Intel's
documentation is not clear on that point, so I don't know what
we can do there. Depending on what works it may make sense
simply to build an smm mode trampoline to get out of vm86 mode.
> Maybe we can code it with GCC and .code16gcc hack.
> If 64KB is not enough, maybe 0xE000 segment can be used
> so that we have 64KB code and 64KB data segments.
> And all the "POST" code can be outside the real mode space.
> So it's not impossible or hard at all.
For just PCBIOS compatibility I agree. Primarily I want
that layer to exist as an add-on and an after thought. Something
that gives backwards compatibility but allows us to do something
better.
With only 256KB of room, there simply is not enough room to
implement drivers of interesting hardware. Nor is there enough
room to implement interesting protocol stacks. And it limits
what we can do in the future.
Eric
From stepan at suse.de Fri Dec 19 08:53:01 2003
From: stepan at suse.de (Stefan Reinauer)
Date: Fri Dec 19 08:53:01 2003
Subject: IDEA: Linux kernel and pcbios compatibility...
In-Reply-To:
References:
Message-ID: <20031219135615.GA14339@suse.de>
* Eric W. Biederman [031219 01:36]:
>
> Brainstorming earlier today I think I have found a way to use
> an linux kernel for the boot loader and to implement pcbios
> compatibility without too much cost. The idea is to use
> a uclinux kernel. And implement a ``user space'' aplication
> that is a user space shim that makes kernel calls.
What functionality is it exactly that we need the uclinux
kernel for? We won't do any scheduling, and we won't need source code
drivers if we implement a pcbios "emulation"
What I liked most about the LinuxBIOS2 approach is that
code was only introduced in the tree when it was specifically needed.
Since I had my hands at the Alpha bootloader Milo, everything that uses
a Linux kernel for it's operations kind of scares me...
Stefan
--
Stefan Reinauer, SUSE LINUX AG
Teamleader Architecture Development
From rminnich at lanl.gov Fri Dec 19 11:48:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Fri Dec 19 11:48:01 2003
Subject: IDEA: Linux kernel and pcbios compatibility...
In-Reply-To: <20031219135615.GA14339@suse.de>
Message-ID:
On Fri, 19 Dec 2003, Stefan Reinauer wrote:
> * Eric W. Biederman [031219 01:36]:
> >
> > Brainstorming earlier today I think I have found a way to use
> > an linux kernel for the boot loader and to implement pcbios
> > compatibility without too much cost. The idea is to use
> > a uclinux kernel. And implement a ``user space'' aplication
> > that is a user space shim that makes kernel calls.
>
> What functionality is it exactly that we need the uclinux
> kernel for? We won't do any scheduling, and we won't need source code
> drivers if we implement a pcbios "emulation"
> What I liked most about the LinuxBIOS2 approach is that
> code was only introduced in the tree when it was specifically needed.
I've been assuming that the uclinux approach is for a payload for those
who want it. I did not expect to see this in the tree.
ron
From ebiederman at lnxi.com Fri Dec 19 13:11:00 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Dec 19 13:11:00 2003
Subject: IDEA: Linux kernel and pcbios compatibility...
In-Reply-To: <20031219135615.GA14339@suse.de>
References: <20031219135615.GA14339@suse.de>
Message-ID:
Stefan Reinauer writes:
> * Eric W. Biederman [031219 01:36]:
> >
> > Brainstorming earlier today I think I have found a way to use
> > an linux kernel for the boot loader and to implement pcbios
> > compatibility without too much cost. The idea is to use
> > a uclinux kernel. And implement a ``user space'' aplication
> > that is a user space shim that makes kernel calls.
>
> What functionality is it exactly that we need the uclinux
> kernel for? We won't do any scheduling, and we won't need source code
> drivers if we implement a pcbios "emulation"
> What I liked most about the LinuxBIOS2 approach is that
> code was only introduced in the tree when it was specifically needed.
>
> Since I had my hands at the Alpha bootloader Milo, everything that uses
> a Linux kernel for it's operations kind of scares me...
So this is for the bootloader, the payload and it will be optional.
This will not go into the linuxBIOS tree, this is an alternative to
etherboot.
I might do a kernel port to a weird hardware configuration but I will
not hack up the kernel in the way Milo does. I have worked on it
and I have the scars as well. Anything that borrows the kernel
drivers is asking for trouble. But look at etherboot. It also
has a dependency on linux drivers. But because etherboot actually
ports the drivers, and then ports the bug fixes it works there
is not a nightmare of a maintenance issue there. So I think using
the kernel whole will be ok.
The observation has been that any sufficiently general firmware
bootloader tends to become an OS, so why not use a real OS.
So the things I actually care about are: booting over myrinet,
booting over inifinband, booting over quadrics, booting over a pair of
bonded nics. Having a good tg3 driver. Getting Lustre as my root
filesystem. Unless size issues kill it again I am going to use the
linux kernel as my bootloader to do this.
So except for the case where someone plugs in a card with an option
rom all the pcbios emulation would do would be to make system
calls to the linux kernel. The biggest modification I would have
to make would be to change the load address of the kernel, and
not the let the kernel use all of RAM, but instead live in a small
fixed area.
I guess the other problem I see with doing a pcbios emulation layer
is I don't know if there it is there is an API to get the kernel
drivers to stop.
If I can't have my cake and eat it too, I won't have pcbios
compatibility. Oh, well.
Eric
From rminnich at lanl.gov Fri Dec 19 14:33:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Fri Dec 19 14:33:00 2003
Subject: IDEA: Linux kernel and pcbios compatibility...
In-Reply-To:
Message-ID:
On 19 Dec 2003, Eric W. Biederman wrote:
> The observation has been that any sufficiently general firmware
> bootloader tends to become an OS, so why not use a real OS.
ah ha! we've come full circle :-)
good to hear.
>
> So the things I actually care about are: booting over myrinet,
> booting over inifinband, booting over quadrics, booting over a pair of
> bonded nics. Having a good tg3 driver. Getting Lustre as my root
> filesystem. Unless size issues kill it again I am going to use the
> linux kernel as my bootloader to do this.
yah, this is why we still put linux in flash here at LANL.
ron
From gwatson at lanl.gov Fri Dec 19 14:39:01 2003
From: gwatson at lanl.gov (Greg Watson)
Date: Fri Dec 19 14:39:01 2003
Subject: IDEA: Linux kernel and pcbios compatibility...
In-Reply-To:
References:
<20031219135615.GA14339@suse.de>
Message-ID:
At 11:20 AM -0700 12/19/03, Eric W. Biederman wrote:
>Stefan Reinauer writes:
>
>> * Eric W. Biederman [031219 01:36]:
>> >
>> > Brainstorming earlier today I think I have found a way to use
>> > an linux kernel for the boot loader and to implement pcbios
>> > compatibility without too much cost. The idea is to use
>> > a uclinux kernel. And implement a ``user space'' aplication
>> > that is a user space shim that makes kernel calls.
>>
>> What functionality is it exactly that we need the uclinux
>> kernel for? We won't do any scheduling, and we won't need source code
>> drivers if we implement a pcbios "emulation"
>> What I liked most about the LinuxBIOS2 approach is that
>> code was only introduced in the tree when it was specifically needed.
>>
>> Since I had my hands at the Alpha bootloader Milo, everything that uses
>> a Linux kernel for it's operations kind of scares me...
>
>So this is for the bootloader, the payload and it will be optional.
>This will not go into the linuxBIOS tree, this is an alternative to
>etherboot.
>
I would like to see this from the PPC perspective. Since neither filo
nor etherboot work on PPC, this might be a good way of booting from,
say, a disk. Which would be nice.
Greg
From ebiederman at lnxi.com Fri Dec 19 15:53:00 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Dec 19 15:53:00 2003
Subject: IDEA: Linux kernel and pcbios compatibility...
In-Reply-To:
References: <20031219135615.GA14339@suse.de>
Message-ID:
Greg Watson writes:
> I would like to see this from the PPC perspective. Since neither filo nor
> etherboot work on PPC, this might be a good way of booting from, say, a
> disk. Which would be nice.
I won't argue with that but this will take some time to come to fruition.
etherboot should be fairly straight forward to port to the PPC. Currently
etherboot supports 3 architectures 4 if you count x86_64. The PPC would
not even be the first big endian port. So for a low end solution that
works I still recommend etherboot.
But if we can avoid the bloat issues the Linux kernel is a good thing
to have.
Any interest in porting kexec to the ppc? It is not strictly required
if you can get your kernel to avoid the memory problem but it is quite
useful.
Eric
From ebiederman at lnxi.com Fri Dec 19 15:55:01 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Dec 19 15:55:01 2003
Subject: IDEA: Linux kernel and pcbios compatibility...
In-Reply-To:
References:
Message-ID:
ron minnich writes:
> On 19 Dec 2003, Eric W. Biederman wrote:
>
> > The observation has been that any sufficiently general firmware
> > bootloader tends to become an OS, so why not use a real OS.
>
> ah ha! we've come full circle :-)
>
> good to hear.
I have never disagreed. Now that we have something that works for
the low end limited ROM solutions I can revisit some of the more
interesting ideas.
> > So the things I actually care about are: booting over myrinet,
> > booting over inifinband, booting over quadrics, booting over a pair of
> > bonded nics. Having a good tg3 driver. Getting Lustre as my root
> > filesystem. Unless size issues kill it again I am going to use the
> > linux kernel as my bootloader to do this.
>
> yah, this is why we still put linux in flash here at LANL.
Now if you had more than a proof of concept implementation of most
of the pieces I would not be happier, but anyway...
Eric
From rminnich at lanl.gov Fri Dec 19 16:20:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Fri Dec 19 16:20:00 2003
Subject: IDEA: Linux kernel and pcbios compatibility...
In-Reply-To:
Message-ID:
On Fri, 19 Dec 2003, Greg Watson wrote:
> I would like to see this from the PPC perspective. Since neither filo
> nor etherboot work on PPC, this might be a good way of booting from,
> say, a disk. Which would be nice.
a linux kernel, with a small initrd with modules and kexec, is just about
the ideal boot loader setup. cwlinux.com has been selling this
configuration for some time. Setting up the same thing on PPC should be
easy.
We have all the bits we need for a very capable bootloader, and have for 3
years. The only thing missing has been a big enough FLASH part. If the
FLASH gets big enough soon enough, our problems will be solved for us.
ron
From rminnich at lanl.gov Fri Dec 19 16:23:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Fri Dec 19 16:23:01 2003
Subject: IDEA: Linux kernel and pcbios compatibility...
In-Reply-To:
Message-ID:
On 19 Dec 2003, Eric W. Biederman wrote:
> Now if you had more than a proof of concept implementation of most
> of the pieces I would not be happier, but anyway...
I kind of miss the point. Pink's been booting with linux in ide-flash for
a year, and if the flash on pink were large enough, we would have been
using that instead.
ron
From ebiederman at lnxi.com Fri Dec 19 16:38:00 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Dec 19 16:38:00 2003
Subject: IDEA: Linux kernel and pcbios compatibility...
In-Reply-To:
References:
Message-ID:
ron minnich writes:
> On 19 Dec 2003, Eric W. Biederman wrote:
>
> > Now if you had more than a proof of concept implementation of most
> > of the pieces I would not be happier, but anyway...
>
> I kind of miss the point. Pink's been booting with linux in ide-flash for
> a year, and if the flash on pink were large enough, we would have been
> using that instead.
Possibly proof of concept is the wrong term.
What Pink does works. I can't throw J. Random kernel at beoboot and have
that work. I can't throw memtest86 at it and have that work. I can't use an
SMP aware kernel with beoboot. And last I looked beoboot had a bulky user
space that makes it hard to squeeze into flash as well. So beoboot
with 2 kernel monte works for a certain interesting subset of cases
but it does not handle the general case.
Except possibly for the exotic driver case 512KB is a large enough
FLASH chip to put in both LinuxBIOS and a kernel. You have to work at
it with a 512KB flash chip but it is doable today.
Eric
From rminnich at lanl.gov Fri Dec 19 16:49:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Fri Dec 19 16:49:00 2003
Subject: IDEA: Linux kernel and pcbios compatibility...
In-Reply-To: