From stepan at suse.de Sun Dec 1 06:52:01 2002
From: stepan at suse.de (Stefan Reinauer)
Date: Sun Dec 1 06:52:01 2002
Subject: National Semiconductor Geode GX1 ?
In-Reply-To: <87k7ivi9b8.fsf@zoo.weinigel.se>; from christer@weinigel.se on Sat, Nov 30, 2002 at 12:30:35PM +0100
References: <20021129030231.A12003@verdi.et.tudelft.nl> <87of88jzi5.fsf@zoo.weinigel.se> <3DE7A79A.2030603@onelabs.com> <20021129212821.A22668@suse.de> <87k7ivi9b8.fsf@zoo.weinigel.se>
Message-ID: <20021201125510.B28369@suse.de>
* Christer Weinigel [021130 12:30]:
> How about the licensing? I think the VSA BIOS freely available from
> NatSemi if one gets the XPressROM kit from them, but what does the GPL
> say about calling a binary object? In my mind there is no linking
> done if a GPL:ed application contains a binary blob which it
> uncompresses into memory and then jumps to an address within the blob,
> but people were quite anal retentive about GPL:ed applications using
> the Qt toolkit a few years ago, so there could be trouble.
Still, it's not a legal problem to use Grub oder Lilo for loading and
jumping into this binary blob called windows. If putting VSA2 code to
ROM would be a problem for whatever reason, it could be loaded from a
different media, as vsa is not needed to get IDE working.
Stefan
--
The x86 isn't all that complex - it just doesn't make a lot of
sense. -- Mike Johnson, Leader of 80x86 Design at AMD
Microprocessor Report (1994)
From rminnich at lanl.gov Sun Dec 1 12:02:00 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Sun Dec 1 12:02:00 2002
Subject: National Semiconductor Geode GX1 ?
In-Reply-To: <20021201125510.B28369@suse.de>
Message-ID:
I see no problem with putting vsa2 to rom. I just don't know how to use it
:-)
ron
From stuge-linuxbios at cdy.org Sun Dec 1 13:11:01 2002
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Sun Dec 1 13:11:01 2002
Subject: National Semiconductor Geode GX1 ?
In-Reply-To:
References: <20021201125510.B28369@suse.de>
Message-ID: <20021201180950.GA27380@foo.birdnet.se>
On Sun, Dec 01, 2002 at 10:05:21AM -0700, Ronald G. Minnich wrote:
> I see no problem with putting vsa2 to rom. I just don't know how to use
> it :-)
E.g. via int 10h, or outb(0x220,..).. VSA (and 2) is used to provide the
old software interface to the new hardware that works in quite different
(better, hopefully) ways.
When int 10h is called, or port 0x220 or 0x92 is accessed, an smint (system
management interrupt, found on mobile CPUs for suspending and so on) is
generated and the "low level" OS driver ends up talking to software instead
of hardware. Practical and economic, when you grasp the concept.
Some VSA things are complete functions (xpressaudio, no sound will be heard
without the xpressaudio VSA ROM) while others are only one way to access
that particular feature (video BIOS, the framebuffer driver works as well
which means that the video BIOS isn't strictly needed although nice for boot
debugging) and yet others may be simple, optional, addons.
//Peter
From malas at pinetron.com Sun Dec 1 19:51:00 2002
From: malas at pinetron.com (Munjun Kang)
Date: Sun Dec 1 19:51:00 2002
Subject: file system error (fwd)
References:
Message-ID: <002f01c2999d$62669380$2800a8c0@MALXP>
> "Ronald G. Minnich" writes:
>
> > any ideas?
> >
> > ron
> >
> > ---------- Forwarded message ----------
> > Date: Fri, 29 Nov 2002 15:35:52 +0900
> > From: Munjun Kang
> > To: Ronald G. Minnich
> > Subject: Re: file system error
> >
> > Thanks for your reply.
> >
> > I tried as your suggest.
> >
> > dd if=/dev/zero of=/dev/hda bs=1024 count=10000 ~ 100000
> > Segmentation fault's are occured in random by count.
> >
> > and then, turn off the UDMA feature by hdparm option.
> > But, I can see same symptom.
>
> All DMA is turned off hdparm -d0 /dev/hda ??
Yes, I did it.
>
> > In this time, I tried to attach SCSI & IEEE1394 SBP-2 devices.
> > case1. Adaptec 2930 SCSI adapter + 8GB Seagate SCSI HDD
> > case2. IEEE1394 Interface card + external IEEE1394 HDD
> > both cases show the same problem.
>
> The northbridge having DMA problems is still a canidate.
> SCSI disks do DMA as well.
>
> > Now, I think it's not a DMA problem.
> > I'm in the maze. hmmmm......
> >
> > Is there any clear hint?
>
> Past history with the Athlon problems on VIA chipsets
> says that some VIA northbridges have problems with burst traffic.
>
> And either DMA or a fast memory copy could trigger it. memtest86
> currently does not have an optimized memcpy so it could miss that problem.
>
> Currently I consider your northbridge to be the best canidate.
> The same kernel is run under both BIOSes?
I tried in several cases.
1. Build-in BIOS + 2.4.18-13 (redhat 8.0) => work
2. Linuxbios + 2.4.18-13 (redhat 8.0) => don't work
3. Linuxbios + 2.4.19 => don't work
>
> Compared to your previous BIOS are there any unknown settings
> in the northbridge?
>
> In particular what are the differences between, on both boards,
> and can you account for the differences.
> lspci -s 0:0.0 -xxx
> And can you account for all differences.
In work,
00:00.0 Host bridge: VIA Technologies, Inc. VT8605 [ProSavage PM133]
00: 06 11 05 06 06 00 10 a2 00 00 00 06 00 08 00 00
10: 08 00 00[e8]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[06 11 05 06]
30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: fd db c8 be 05 00 08 08 c0 00 08 08 08 08 08 08
60: 03[aa]00[20]e6 d5 d5 00 43 38 86 0d 08 21 00 00
70: c4 88[cc]0c 0e 81 52 00 01 b4 09 00 00 00 00 00
80: 0f 40 00 00 c0 00 00 00 02 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 02 c0 20 00 07 02 00 1f 00 00 00 00 2f 02 04 00
b0: 40 ff 10 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 06 00 32 42 00 b0 00 00 00 00
In problem,
00:00.0 Class 0600: 1106:0605
00: 06 11 05 06 06 00 10 a2 00 00 00 06 00 08 00 00
10: 08 00 00[f8]00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00[00 00 00 00]
30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: fd db c8 be 05 00 08 08 c0 00 08 08 08 08 08 08
60: 03[00]00[00]e6 d5 d5 00 43 38 86 0d 08 21 00 00
70: c4 88[4c]0c 0e 81 52 00 01 b4 09 00 00 00 00 00
80: 0f 40 00 00 c0 00 00 00 02 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 02 c0 20 00 07 02 00 1f 00 00 00 00 2f 02 04 00
b0: 40 ff 10 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 06 00 32 42 00 b0 00 00 00 00
0x13 : Graphics Aperature Base
0x2c : I don't know. maybe same with vendor & device ID
0x61, 0x62 : shadow ram setting
0x72 : CPU to PCI Flow control. difference bit 7 is described as follow.
7bit Retry Status
0 No retry occurred -------- default
1 Retry occurred ----------- write 1 to clear
In my opinion, there are not special differences.
>
> Eric
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>
From lawrence at tyanchina.com Sun Dec 1 21:03:01 2002
From: lawrence at tyanchina.com (Lawrence LL. Dai)
Date: Sun Dec 1 21:03:01 2002
Subject: Is a Doc is necessary?
Message-ID: <441383BA85E81D48964152E537886C9D1D2C54@mail.sh.corp.tyan.com>
Hi, All:
Who can tell me whether a Doc is necessary for linuxbios? Can I burn on a ROM only?
Thank,
Lawrence
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From rminnich at lanl.gov Sun Dec 1 21:13:00 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Sun Dec 1 21:13:00 2002
Subject: Is a Doc is necessary?
In-Reply-To: <441383BA85E81D48964152E537886C9D1D2C54@mail.sh.corp.tyan.com>
Message-ID:
On Mon, 2 Dec 2002, Lawrence LL. Dai wrote:
> Who can tell me whether a Doc is necessary for linuxbios? Can I burn on
> a ROM only?
DoC is nice but not necessary. On many chipsets you can not use DoC
because the socket is not compatible or the chipset is so complex. On all
the e7500 machines doc is not useable.
ron
From rminnich at lanl.gov Sun Dec 1 21:19:01 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Sun Dec 1 21:19:01 2002
Subject: motherboard owners: you know who you are:
Message-ID:
It would help a lot if those of you who are The Experts on a given
motherboard would update your STATUS and send me the patches. Otherwise
I'm going to have to guess on some of these (nano, etc.) and I might not
get it right.
thanks
ron
From aip at cwlinux.com Sun Dec 1 21:57:01 2002
From: aip at cwlinux.com (Andrew Ip)
Date: Sun Dec 1 21:57:01 2002
Subject: [COMMIT] cs5530 and pcm-5823
Message-ID: <20021202110004.A10572@mail.cwlinux.com>
src/southbridge/nsc/cs5530/southbridge.c
src/mainboard/advantech/pcm-5823/Config
- Disabled hard coded irq assignment where priq is existed
- With this commit, even older version of pcm-5823, eg.PCM-5823-E0A1, can boot
and access from hdc
-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.
Tel: (852)2542 2046
Fax: (852)2542 2036
For public pgp key, please obtain it from http://www.keyserver.net/en.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL:
From akohlsmith-linuxbios at benshaw.com Sun Dec 1 21:58:01 2002
From: akohlsmith-linuxbios at benshaw.com (Andrew Kohlsmith)
Date: Sun Dec 1 21:58:01 2002
Subject: common flash hw write enable methods
Message-ID: <200212012159.54423@-mixdown.ca>
So I've got linuxbios booting inside Bochs and I feel I'm confident enough to
roll the dice and burn it to a real board (TSSOP package, no sockets) using
/dev/bios.
After some head-scratching, I realize that the hardware RP# and VPP are tied
together, and at a logic low, preventing any flash attempts. These are pins
10 and 11 on the TSSOP part. :-(
Now I imagine that these are tied to a MOSFET to +12V which is run off of a
GPIO pin. The question is, without tracing an 8-layer board out to try and
identify how exactly reflash is enabled, how to reflash this?
I can always cut the traces and hard-wire to +12V but I'd like to see if I
can't do this programmatically. I have a number of boards I want to use and
hardware hacking is something I'd like to avoid doing if possible.
Now I know that every motherboard is different and that there may be other
things locking me out, but generally speaking is there an "industry standard"
way of enabling/disabling BIOS reflash? It's currently a PhoenixBIOS, so I
imagine if I located a reflash tool and ran it in a Bochs session with a lot
of I/O debugging I could figure out what it's doing but before I embark on
that I'd like to see if anyone has any hints that may save me a lot of time.
Regards,
Andrew
From rminnich at lanl.gov Sun Dec 1 22:39:00 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Sun Dec 1 22:39:00 2002
Subject: common flash hw write enable methods
In-Reply-To: <200212012159.54423@-mixdown.ca>
Message-ID:
On Sun, 1 Dec 2002, Andrew Kohlsmith wrote:
> Now I imagine that these are tied to a MOSFET to +12V which is run off of a
> GPIO pin.
probably a good guess.
Another way I found it on one board was to try every combination of GPIOs
until the FLASH started working. Not fun, but pretty fast if you write a
program.
> I can always cut the traces and hard-wire to +12V but I'd like to see if I
> can't do this programmatically. I have a number of boards I want to use and
> hardware hacking is something I'd like to avoid doing if possible.
get the flash burner for this board, run under a simulator of some sort,
and watch the IOs. Or put a PCI bus analyzer on the machine, run the flash
program, and watch the IOs. It's not going to be fun.
I still don't see how running under Bochs helps with the chipset but maybe
I missed something.
> Now I know that every motherboard is different and that there may be other
> things locking me out, but generally speaking is there an "industry standard"
> way of enabling/disabling BIOS reflash?
No, the goal is to make it hard for you to reflash. So the vendors keep
coming up with new ways to hide this. Very annoying!
ron
From bari at onelabs.com Sun Dec 1 23:16:01 2002
From: bari at onelabs.com (Bari Ari)
Date: Sun Dec 1 23:16:01 2002
Subject: common flash hw write enable methods
References:
Message-ID: <3DEADF9F.8070606@onelabs.com>
Ronald G. Minnich wrote:
>On Sun, 1 Dec 2002, Andrew Kohlsmith wrote:
>
>
>>Now I know that every motherboard is different and that there may be other
>>things locking me out, but generally speaking is there an "industry standard"
>>way of enabling/disabling BIOS reflash?
>>
>>
>
>No, the goal is to make it hard for you to reflash. So the vendors keep
>coming up with new ways to hide this. Very annoying!
>
>
>
The two methods we use for the several motherboards we design a year to
enable/disable flash writes are:
Method A - Use a jumper.
Method B - Use whatever GPIO is leftover on chipset or Super I/O.
Bari
From pyro at linuxlabs.com Mon Dec 2 07:35:01 2002
From: pyro at linuxlabs.com (steven james)
Date: Mon Dec 2 07:35:01 2002
Subject: file system error (fwd)
In-Reply-To: <002f01c2999d$62669380$2800a8c0@MALXP>
Message-ID:
Greetings,
Any poassability that the amount of memory passed to the kernel is too
high and the crashes are due to using non-existant memory for a buffer or
struct?
1st test is check reported memory on boot, 2nd is memtest86, 3rd is to
pass mem=(some small value) to the kernel and see what happens.
G'day,
sjames
On Mon, 2 Dec 2002, Munjun Kang wrote:
> > "Ronald G. Minnich" writes:
> >
> > > any ideas?
> > >
> > > ron
> > >
> > > ---------- Forwarded message ----------
> > > Date: Fri, 29 Nov 2002 15:35:52 +0900
> > > From: Munjun Kang
> > > To: Ronald G. Minnich
> > > Subject: Re: file system error
> > >
> > > Thanks for your reply.
> > >
> > > I tried as your suggest.
> > >
> > > dd if=/dev/zero of=/dev/hda bs=1024 count=10000 ~ 100000
> > > Segmentation fault's are occured in random by count.
> > >
> > > and then, turn off the UDMA feature by hdparm option.
> > > But, I can see same symptom.
> >
> > All DMA is turned off hdparm -d0 /dev/hda ??
> Yes, I did it.
>
> >
> > > In this time, I tried to attach SCSI & IEEE1394 SBP-2 devices.
> > > case1. Adaptec 2930 SCSI adapter + 8GB Seagate SCSI HDD
> > > case2. IEEE1394 Interface card + external IEEE1394 HDD
> > > both cases show the same problem.
> >
> > The northbridge having DMA problems is still a canidate.
> > SCSI disks do DMA as well.
> >
> > > Now, I think it's not a DMA problem.
> > > I'm in the maze. hmmmm......
> > >
> > > Is there any clear hint?
> >
> > Past history with the Athlon problems on VIA chipsets
> > says that some VIA northbridges have problems with burst traffic.
> >
> > And either DMA or a fast memory copy could trigger it. memtest86
> > currently does not have an optimized memcpy so it could miss that problem.
> >
> > Currently I consider your northbridge to be the best canidate.
> > The same kernel is run under both BIOSes?
> I tried in several cases.
> 1. Build-in BIOS + 2.4.18-13 (redhat 8.0) => work
> 2. Linuxbios + 2.4.18-13 (redhat 8.0) => don't work
> 3. Linuxbios + 2.4.19 => don't work
>
> >
> > Compared to your previous BIOS are there any unknown settings
> > in the northbridge?
> >
> > In particular what are the differences between, on both boards,
> > and can you account for the differences.
> > lspci -s 0:0.0 -xxx
> > And can you account for all differences.
> In work,
> 00:00.0 Host bridge: VIA Technologies, Inc. VT8605 [ProSavage PM133]
> 00: 06 11 05 06 06 00 10 a2 00 00 00 06 00 08 00 00
> 10: 08 00 00[e8]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[06 11 05 06]
> 30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00
> 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 50: fd db c8 be 05 00 08 08 c0 00 08 08 08 08 08 08
> 60: 03[aa]00[20]e6 d5 d5 00 43 38 86 0d 08 21 00 00
> 70: c4 88[cc]0c 0e 81 52 00 01 b4 09 00 00 00 00 00
> 80: 0f 40 00 00 c0 00 00 00 02 00 00 00 00 00 00 00
> 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> a0: 02 c0 20 00 07 02 00 1f 00 00 00 00 2f 02 04 00
> b0: 40 ff 10 00 00 00 00 00 00 00 00 00 00 00 00 00
> c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
> d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> f0: 00 00 00 00 00 00 06 00 32 42 00 b0 00 00 00 00
>
> In problem,
> 00:00.0 Class 0600: 1106:0605
> 00: 06 11 05 06 06 00 10 a2 00 00 00 06 00 08 00 00
> 10: 08 00 00[f8]00 00 00 00 00 00 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00[00 00 00 00]
> 30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00
> 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 50: fd db c8 be 05 00 08 08 c0 00 08 08 08 08 08 08
> 60: 03[00]00[00]e6 d5 d5 00 43 38 86 0d 08 21 00 00
> 70: c4 88[4c]0c 0e 81 52 00 01 b4 09 00 00 00 00 00
> 80: 0f 40 00 00 c0 00 00 00 02 00 00 00 00 00 00 00
> 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> a0: 02 c0 20 00 07 02 00 1f 00 00 00 00 2f 02 04 00
> b0: 40 ff 10 00 00 00 00 00 00 00 00 00 00 00 00 00
> c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
> d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> f0: 00 00 00 00 00 00 06 00 32 42 00 b0 00 00 00 00
>
> 0x13 : Graphics Aperature Base
> 0x2c : I don't know. maybe same with vendor & device ID
> 0x61, 0x62 : shadow ram setting
> 0x72 : CPU to PCI Flow control. difference bit 7 is described as follow.
> 7bit Retry Status
> 0 No retry occurred -------- default
> 1 Retry occurred ----------- write 1 to clear
>
> In my opinion, there are not special differences.
>
> >
> > Eric
> >
> > _______________________________________________
> > Linuxbios mailing list
> > Linuxbios at clustermatic.org
> > http://www.clustermatic.org/mailman/listinfo/linuxbios
> >
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>
--
-------------------------steven james, director of research, linux labs
... ........ ..... .... 230 peachtree st nw ste 701
the original linux labs atlanta.ga.us 30303
-since 1995 http://www.linuxlabs.com
office 404.577.7747 fax 404.577.7743
-----------------------------------------------------------------------
From rminnich at lanl.gov Mon Dec 2 09:24:01 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Dec 2 09:24:01 2002
Subject: file system error (fwd)
In-Reply-To:
Message-ID:
On Mon, 2 Dec 2002, steven james wrote:
> Any poassability that the amount of memory passed to the kernel is too
> high and the crashes are due to using non-existant memory for a buffer or
> struct?
that has worked for me on some ugly platforms, so it is a good thing to
try.
ron
From jerj at coplanar.net Mon Dec 2 14:34:00 2002
From: jerj at coplanar.net (Jeremy Jackson)
Date: Mon Dec 2 14:34:00 2002
Subject: common flash hw write enable methods
References: <200212012159.54423@-mixdown.ca>
Message-ID: <008901c29a3a$0eed5250$7e07a8c0@bridge>
One i430TX board I have (Tyan S1571) had the DIP32's (Atmel AT29C010A) OE#
in the normal place (ISA MEMR#), but the WE# at ISA SMEMW#. So you had to
read from the high window, and write to the low. annoying to alter
/dev/bios driver, so I removed the jumper and soldered WE# to ISA MEMW#.
Regards,
Jeremy
----- Original Message -----
From: "Andrew Kohlsmith"
To:
Sent: Sunday, December 01, 2002 9:59 PM
Subject: common flash hw write enable methods
> After some head-scratching, I realize that the hardware RP# and VPP are
tied
> together, and at a logic low, preventing any flash attempts. These are
pins
> 10 and 11 on the TSSOP part. :-(
>
> Now I imagine that these are tied to a MOSFET to +12V which is run off of
a
> GPIO pin. The question is, without tracing an 8-layer board out to try
and
> identify how exactly reflash is enabled, how to reflash this?
>
> I can always cut the traces and hard-wire to +12V but I'd like to see if I
> can't do this programmatically. I have a number of boards I want to use
and
> hardware hacking is something I'd like to avoid doing if possible.
>
> Now I know that every motherboard is different and that there may be other
> things locking me out, but generally speaking is there an "industry
standard"
> way of enabling/disabling BIOS reflash? It's currently a PhoenixBIOS, so
I
> imagine if I located a reflash tool and ran it in a Bochs session with a
lot
> of I/O debugging I could figure out what it's doing but before I embark on
> that I'd like to see if anyone has any hints that may save me a lot of
time.
From rminnich at lanl.gov Mon Dec 2 14:39:00 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Dec 2 14:39:00 2002
Subject: linuxbios and gcc 3.2
Message-ID:
I'm trying to track down the problems with linuxbios, mptables, and gcc
3.2
The symptom is that the myrinet card which is in the slot for 02:1.0
ends up with IRQ 0 when linux is done parsing the mp table.
So far I am dumping the intsrc entries in the mp table and they look fine
from the linuxbios side.
If anyone has any hints I'll take them. This is weird.
ron
From pyro at linuxlabs.com Mon Dec 2 16:13:01 2002
From: pyro at linuxlabs.com (steven james)
Date: Mon Dec 2 16:13:01 2002
Subject: linuxbios and gcc 3.2
In-Reply-To:
Message-ID:
Greetings,
Possably a packing problem? Are you dumping the raw byte values to check
for bad padding?
G'day,
sjames
On Mon, 2 Dec 2002, Ronald G. Minnich wrote:
>
> I'm trying to track down the problems with linuxbios, mptables, and gcc
> 3.2
>
> The symptom is that the myrinet card which is in the slot for 02:1.0
> ends up with IRQ 0 when linux is done parsing the mp table.
>
> So far I am dumping the intsrc entries in the mp table and they look fine
> from the linuxbios side.
>
> If anyone has any hints I'll take them. This is weird.
>
> ron
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>
--
-------------------------steven james, director of research, linux labs
... ........ ..... .... 230 peachtree st nw ste 701
the original linux labs atlanta.ga.us 30303
-since 1995 http://www.linuxlabs.com
office 404.577.7747 fax 404.577.7743
-----------------------------------------------------------------------
From rminnich at lanl.gov Mon Dec 2 16:15:00 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Dec 2 16:15:00 2002
Subject: linuxbios and gcc 3.2
In-Reply-To:
Message-ID:
On Mon, 2 Dec 2002, steven james wrote:
> Possably a packing problem? Are you dumping the raw byte values to check
> for bad padding?
yes, I am now doing to dump the whole table to try to see what's up. This
is pretty weird.
ron
From rminnich at lanl.gov Mon Dec 2 17:59:01 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Dec 2 17:59:01 2002
Subject: MP table and gcc 3.2
Message-ID:
OK, I've verified that most of the bits are right. The only thing that
seems broken is the floating table structure (_MP_), the data in memory
for that look quite wrong. The other structs (i.e. PCMP) seem to be ok.
I think I've almost got it.
ron
From rminnich at lanl.gov Mon Dec 2 18:17:00 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Dec 2 18:17:00 2002
Subject: mp table and gcc 3.2 and ....
Message-ID:
the mp table (_MP_) is also ok.
Now this is getting weird. All the data in all the tables looks fine,
almost byte-for-byte the same (I'm still working out what's different).
But Linux never finds this MP table when loaded from a gcc 3.2-compiled
linuxbios. The same linux, booted with linuxbios compiled on gcc 2.96,
finds the table no trouble.
Any hints anyone :-)
how many people are building linux with RH 8.0, and these gcc tools:
root at pinkish tmp]# gcc -v -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --host=i386-redhat-linux --with-system-zlib
--enable-__cxa_atexit
Thread model: posix
gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)
[root at pinkish tmp]# as -v -v
GNU assembler version 2.13.90.0.2 (i386-redhat-linux) using BFD version
2.13.90.0.2 20020802
[root at pinkish tmp]# ld -v -v
GNU ld version 2.13.90.0.2 20020802
GNU ld version 2.13.90.0.2 20020802
ron
From rminnich at lanl.gov Mon Dec 2 19:07:00 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Dec 2 19:07:00 2002
Subject: mptable and redhat 8 and wotta mess.
Message-ID:
If I build linuxbios with gcc 2.96, things get marginally better. But
weirder.
Linux version 2.4.19-lanl.18beoboot (root at butthead) (gcc version 2.96
20000731 (Red Hat Linux 7.3 2.96-112)) #1 Fri Aug 16 15:03:04 MDT 2002
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 0000000000000bd0 (reserved)
BIOS-e820: 0000000000000bd0 - 00000000000a0000 (usable)
BIOS-e820: 00000000000f0000 - 00000000000f0400 (reserved)
BIOS-e820: 0000000000100000 - 0000000020000000 (usable)
BIOS-e820: 0000000100000000 - 0000000120000000 (usable)
Warning only 896MB will be used.
Use a PAE enabled kernel.
896MB LOWMEM available.
hm, page 00000000 reserved twice.
On node 0 totalpages: 229376
note that it is still not seeing the MP table.
But later on:
PCI: Discovered primary peer bus 10 [IRQ]
PCI: Discovered primary peer bus 11 [IRQ]
PCI: Discovered primary peer bus 12 [IRQ]
PCI: Using IRQ router PIIX [8086/2480] at 00:1f.0
PCI: Found IRQ 11 for device 00:1d.0
PCI: Sharing IRQ 11 with 07:01.0
PCI: Found IRQ 5 for device 00:1f.1
PCI: Found IRQ 3 for device 00:1f.3
PCI: Found IRQ 7 for device 02:01.0
So how is it getting this info? I am now getting confused.
nevertheless it does get the new kernel fine over the myrinet. The ram map
still looks like this:
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 0000000000000bd0 (reserved)
BIOS-e820: 0000000000000bd0 - 00000000000a0000 (usable)
BIOS-e820: 00000000000f0000 - 00000000000f0400 (reserved)
BIOS-e820: 0000000000100000 - 0000000020000000 (usable)
BIOS-e820: 0000000100000000 - 0000000120000000 (usable)
Note also that the RAM map shows (for this newer linuxbios) a big hole in
the ram map. 2.4.19 doesn't seem to be able to handle this, more below:
Warning only 4GB will be used.
Use a PAE enabled kernel.
3200MB HIGHMEM available.
OOPS! There's only 1024 MB but the kernel is doing something odd.
Now the older linuxbios (a version from LNXI that says 1.0.0.6) show this
for the ram map:
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 0000000000000b54 (reserved)
BIOS-e820: 0000000000000b54 - 00000000000a0000 (usable)
BIOS-e820: 00000000000f0000 - 00000000000f0400 (reserved)
BIOS-e820: 0000000000100000 - 0000000040000000 (usable)
128MB HIGHMEM available.
896MB LOWMEM available.
And this works.
So, that's the state of play: linuxbios is now producing e820 maps that
2.4.19 doesn't seem to be able to handle; something is somehow trashing
the MP table (etherboot); and, in general, things on e7500 are not
currently working.
More later.
ron
From rminnich at lanl.gov Tue Dec 3 00:08:01 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Tue Dec 3 00:08:01 2002
Subject: E7500
Message-ID:
Status:
- working fallback linuxbios that was built on redhat 7.3 w/ gcc 2.96
(bogus redhat version :-)
- trying to get a supermicro p4dpe to work on redhat 8.0
- kernel+initrd is loaded from IDE-flash via etherboot.
This is a bproc "phase 1" kernel, and will download and boot a
"phase 2" kernel.
The phase 1 kernel is non-smp, and should use PIRQ tables or similar to
set up IRQs, it turns out. It appears not to be MP-table aware. The
phase 2 kernel is SMP- and MP-table aware.
If I build linuxbios with gcc 3.2, it loads the phase 1 kernel but ...
that kernel can't find any interrupts for the myrinet card. If I build
linuxbios with gcc 2.96, that kernel can find interrupts and download the
phase 2 kernel. The phase 2 kernel finds the MP table and gets everything
ready to go, but panics when trying to set up the initrd for reasons that
are not clear. It seems to think it has 4 GB memory, when it fact it has 1
GB memory with a big memory hole. Can Linux 2.4.19 handle this kind of
sparse memory map? right now, experience is saying "no", although I
thought this was working.
Now I think I need to look at the PIRQ table as compiled by gcc 3.2. The
MP table seems to be created just fine. Interesting.
ron
From ebiederman at lnxi.com Tue Dec 3 01:57:00 2002
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Dec 3 01:57:00 2002
Subject: mptable and redhat 8 and wotta mess.
In-Reply-To:
References:
Message-ID:
"Ronald G. Minnich" writes:
> If I build linuxbios with gcc 2.96, things get marginally better. But
> weirder.
>
> Linux version 2.4.19-lanl.18beoboot (root at butthead) (gcc version 2.96
> 20000731 (Red Hat Linux 7.3 2.96-112)) #1 Fri Aug 16 15:03:04 MDT 2002
> BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 0000000000000bd0 (reserved)
> BIOS-e820: 0000000000000bd0 - 00000000000a0000 (usable)
> BIOS-e820: 00000000000f0000 - 00000000000f0400 (reserved)
> BIOS-e820: 0000000000100000 - 0000000020000000 (usable)
> BIOS-e820: 0000000100000000 - 0000000120000000 (usable)
> Warning only 896MB will be used.
> Use a PAE enabled kernel.
> 896MB LOWMEM available.
> hm, page 00000000 reserved twice.
> On node 0 totalpages: 229376
>
> note that it is still not seeing the MP table.
It looks like either the of pirq or mptable is working.
>
> But later on:
>
> PCI: Discovered primary peer bus 10 [IRQ]
> PCI: Discovered primary peer bus 11 [IRQ]
> PCI: Discovered primary peer bus 12 [IRQ]
> PCI: Using IRQ router PIIX [8086/2480] at 00:1f.0
> PCI: Found IRQ 11 for device 00:1d.0
> PCI: Sharing IRQ 11 with 07:01.0
> PCI: Found IRQ 5 for device 00:1f.1
> PCI: Found IRQ 3 for device 00:1f.3
> PCI: Found IRQ 7 for device 02:01.0
>
> So how is it getting this info? I am now getting confused.
Yep that looks very much like a pirq table. All of the assigned irqs are below 16.
> nevertheless it does get the new kernel fine over the myrinet. The ram map
> still looks like this:
>
> BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 0000000000000bd0 (reserved)
> BIOS-e820: 0000000000000bd0 - 00000000000a0000 (usable)
> BIOS-e820: 00000000000f0000 - 00000000000f0400 (reserved)
> BIOS-e820: 0000000000100000 - 0000000020000000 (usable)
> BIOS-e820: 0000000100000000 - 0000000120000000 (usable)
>
> Note also that the RAM map shows (for this newer linuxbios) a big hole in
> the ram map. 2.4.19 doesn't seem to be able to handle this, more below:
Cool, you have enabled the debugging option.
It leaves 512MB low, and it puts the rest of the memory about 4GB so it is possible
to test PAE setups.
> Warning only 4GB will be used.
> Use a PAE enabled kernel.
> 3200MB HIGHMEM available.
>
> OOPS! There's only 1024 MB but the kernel is doing something odd.
LinuxBIOS actually, it is a feature...
That 3200MB HIGHMEM available definitely sounds off.
> Now the older linuxbios (a version from LNXI that says 1.0.0.6) show this
> for the ram map:
>
> BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 0000000000000b54 (reserved)
> BIOS-e820: 0000000000000b54 - 00000000000a0000 (usable)
> BIOS-e820: 00000000000f0000 - 00000000000f0400 (reserved)
> BIOS-e820: 0000000000100000 - 0000000040000000 (usable)
> 128MB HIGHMEM available.
> 896MB LOWMEM available.
>
> And this works.
>
> So, that's the state of play: linuxbios is now producing e820 maps that
> 2.4.19 doesn't seem to be able to handle;
Hmm. If you get more than 512MB of RAM it is a 2.4.19 bug, earlier
kernels handle that case just fine.
> something is somehow trashing
> the MP table (etherboot); and, in general, things on e7500 are not
> currently working.
It looks like it is still an mptable problem. There are a few oddities
but nothing very big.
Next time I swing by and do a build I will see how well it all works
with binutils-2.13 and gcc-3.2 I have recently upgraded I just have
not swung by that direction yet.
You might try installing egcs-2.91.66 aka kgcc on redhat. That was
what the port was developed with. Until I had the compressor going
I was having a hard time fitting etherboot and LinuxBIOS in the last
64KB.
Eric
From k4sus2000 at yahoo.de Tue Dec 3 07:05:01 2002
From: k4sus2000 at yahoo.de (=?iso-8859-1?q?Fredy=20Setiadji?=)
Date: Tue Dec 3 07:05:01 2002
Subject: sis730s manual
Message-ID: <20021203120859.21139.qmail@web9901.mail.yahoo.com>
where can i find the sis730s manual and register sets?
thanks,
fredy
__________________________________________________________________
Gesendet von Yahoo! Mail - http://mail.yahoo.de
Weihnachts-Eink?ufe ohne Stress! http://shopping.yahoo.de
From pyro at linuxlabs.com Tue Dec 3 09:35:01 2002
From: pyro at linuxlabs.com (steven james)
Date: Tue Dec 3 09:35:01 2002
Subject: mptable and redhat 8 and wotta mess.
In-Reply-To:
Message-ID:
Greetings,
I'm not on RH8.0 yet. I do use gcc 2.96 20000731 to build LinuxBIOS. I'm
currently tracking an apparent memory issue that may be caused by the same
thing. The symptom is that when the baremetal based bootloader allocates
the bounce buffer at the top of RAM, it seems to be allocating nonexistant
RAM. It gets the LinuxBIOS table using Eric's code from etherboot.
I will let you know if I find anything interesting.
G'day,
sjames
On Mon, 2 Dec 2002, Ronald G. Minnich wrote:
>
>
> If I build linuxbios with gcc 2.96, things get marginally better. But
> weirder.
>
> Linux version 2.4.19-lanl.18beoboot (root at butthead) (gcc version 2.96
> 20000731 (Red Hat Linux 7.3 2.96-112)) #1 Fri Aug 16 15:03:04 MDT 2002
> BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 0000000000000bd0 (reserved)
> BIOS-e820: 0000000000000bd0 - 00000000000a0000 (usable)
> BIOS-e820: 00000000000f0000 - 00000000000f0400 (reserved)
> BIOS-e820: 0000000000100000 - 0000000020000000 (usable)
> BIOS-e820: 0000000100000000 - 0000000120000000 (usable)
> Warning only 896MB will be used.
> Use a PAE enabled kernel.
> 896MB LOWMEM available.
> hm, page 00000000 reserved twice.
> On node 0 totalpages: 229376
>
> note that it is still not seeing the MP table.
>
> But later on:
>
> PCI: Discovered primary peer bus 10 [IRQ]
> PCI: Discovered primary peer bus 11 [IRQ]
> PCI: Discovered primary peer bus 12 [IRQ]
> PCI: Using IRQ router PIIX [8086/2480] at 00:1f.0
> PCI: Found IRQ 11 for device 00:1d.0
> PCI: Sharing IRQ 11 with 07:01.0
> PCI: Found IRQ 5 for device 00:1f.1
> PCI: Found IRQ 3 for device 00:1f.3
> PCI: Found IRQ 7 for device 02:01.0
>
> So how is it getting this info? I am now getting confused.
>
> nevertheless it does get the new kernel fine over the myrinet. The ram map
> still looks like this:
>
> BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 0000000000000bd0 (reserved)
> BIOS-e820: 0000000000000bd0 - 00000000000a0000 (usable)
> BIOS-e820: 00000000000f0000 - 00000000000f0400 (reserved)
> BIOS-e820: 0000000000100000 - 0000000020000000 (usable)
> BIOS-e820: 0000000100000000 - 0000000120000000 (usable)
>
> Note also that the RAM map shows (for this newer linuxbios) a big hole in
> the ram map. 2.4.19 doesn't seem to be able to handle this, more below:
>
> Warning only 4GB will be used.
> Use a PAE enabled kernel.
> 3200MB HIGHMEM available.
>
> OOPS! There's only 1024 MB but the kernel is doing something odd.
>
> Now the older linuxbios (a version from LNXI that says 1.0.0.6) show this
> for the ram map:
>
> BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 0000000000000b54 (reserved)
> BIOS-e820: 0000000000000b54 - 00000000000a0000 (usable)
> BIOS-e820: 00000000000f0000 - 00000000000f0400 (reserved)
> BIOS-e820: 0000000000100000 - 0000000040000000 (usable)
> 128MB HIGHMEM available.
> 896MB LOWMEM available.
>
> And this works.
>
> So, that's the state of play: linuxbios is now producing e820 maps that
> 2.4.19 doesn't seem to be able to handle; something is somehow trashing
> the MP table (etherboot); and, in general, things on e7500 are not
> currently working.
>
> More later.
>
> ron
>
>
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>
--
-------------------------steven james, director of research, linux labs
... ........ ..... .... 230 peachtree st nw ste 701
the original linux labs atlanta.ga.us 30303
-since 1995 http://www.linuxlabs.com
office 404.577.7747 fax 404.577.7743
-----------------------------------------------------------------------
From rminnich at lanl.gov Tue Dec 3 09:49:00 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Tue Dec 3 09:49:00 2002
Subject: It's the IRQ table
Message-ID:
gcc 3.2 when it compiles the PIRQ table gives me utterly different results
from 2.96. I now have something to look at.
ron
From rminnich at lanl.gov Tue Dec 3 09:51:00 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Tue Dec 3 09:51:00 2002
Subject: linuxbios (fwd)
Message-ID:
any hints?
zengqi, please send these messages to this list. I don't have time right
now to help you. Sorry!
ron
---------- Forwarded message ----------
Date: Tue, 3 Dec 2002 01:29:32 +0800
From:
To: Ronald G. Minnich
Subject: linuxbios
Dear Mr Ronald G
Now I have two issues about Linux-BIOS booting IDE ,I hope you can help me!
1)I hope my computer boot from Linux-BIOS and load kernel from IDE harddisk,
not from DOC.SO I add "BOOT_IDE=1" into m758lmr+.config ,but when I use the command as follow:
linuxbios.init m758lmr+.config
,linux.bin.gz, linuxbios.strip and docipl can not be created.(Before I add BOOT_IDE , the command was
worked well),why?
2)In linux ,After I insert two modules the DOC2000 and Docprobe (doc_config_location=0xfffc8000 )and use
command "flash_on",I can recognize DOC . The problem is that I can not recognize DOC in DOS.(I would like
to use tooling such as DINFO or DFORMAT to serch DOC,but failed),why?
the hardware : a. pcchips m758lmr+
b. two bios :linuxbios and normal bios
the kernel of linux is 2.4.19
regards
Zengqi
From rminnich at lanl.gov Tue Dec 3 09:56:01 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Tue Dec 3 09:56:01 2002
Subject: help! (fwd)
Message-ID:
can someone help xu?
ron
---------- Forwarded message ----------
Date: Tue, 03 Dec 2002 18:39:42 +0800
From: xu xuning
To: rminnich at lanl.gov
Subject: help!
Mr.Ronald G. Minnich
how are you !
I have used pre-made image from http://www.cwlinux.com/download/ and
success start from my doc,my mainboard is Winfast6300 MA Pro.
and now i have two questions to ask you :
one :
how to mount /dev/hda1 (my harddisk),because i found in my system on doc
have "/dev/hda*",but when i run " # mount /dev/hda1 /home/disk/" the result
is a error,so can you tell me HOWTO?
two:
how to mount usb-memory (e.g.onlydisk),i know in Red Hat Linux7.2 is "#
mount /dev/sda /home/usb/",but in my system on doc there is no /dev/sda*,So
how to do ?
Thanks a lot!
XuNing
_________________________________________________________________
???????????????????????????? MSN Messenger: http://messenger.msn.com/cn
From rminnich at lanl.gov Tue Dec 3 09:57:01 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Tue Dec 3 09:57:01 2002
Subject: sis730s manual
In-Reply-To: <20021203120859.21139.qmail@web9901.mail.yahoo.com>
Message-ID:
On Tue, 3 Dec 2002, Fredy Setiadji wrote:
> where can i find the sis730s manual and register sets?
you have to go to SiS.
ron
From pyro at linuxlabs.com Tue Dec 3 10:09:01 2002
From: pyro at linuxlabs.com (steven james)
Date: Tue Dec 3 10:09:01 2002
Subject: linuxbios (fwd)
In-Reply-To:
Message-ID:
Greetings,
Not sure about first question, but I suspect that DOS can't see the DOC
because of overwriting the M-SYS boot block.
The Doc normally loads a BIOS extender from block 0 on power up which the
BIOS runs. The extender hooks int 13 so that DOS will see it as a drive.
If block 0 is overwritten, that will fail.
G'day,
sjames
On Tue, 3 Dec 2002, Ronald G. Minnich wrote:
>
> any hints?
>
> zengqi, please send these messages to this list. I don't have time right
> now to help you. Sorry!
>
> ron
>
> ---------- Forwarded message ----------
> Date: Tue, 3 Dec 2002 01:29:32 +0800
> From:
> To: Ronald G. Minnich
> Subject: linuxbios
>
>
> Dear Mr Ronald G
>
> Now I have two issues about Linux-BIOS booting IDE ,I hope you can help me!
>
> 1)I hope my computer boot from Linux-BIOS and load kernel from IDE harddisk,
> not from DOC.SO I add "BOOT_IDE=1" into m758lmr+.config ,but when I use the command as follow:
> linuxbios.init m758lmr+.config
> ,linux.bin.gz, linuxbios.strip and docipl can not be created.(Before I add BOOT_IDE , the command was
> worked well),why?
>
> 2)In linux ,After I insert two modules the DOC2000 and Docprobe (doc_config_location=0xfffc8000 )and use
> command "flash_on",I can recognize DOC . The problem is that I can not recognize DOC in DOS.(I would like
> to use tooling such as DINFO or DFORMAT to serch DOC,but failed),why?
>
> the hardware : a. pcchips m758lmr+
> b. two bios :linuxbios and normal bios
> the kernel of linux is 2.4.19
>
> regards
>
> Zengqi
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>
--
-------------------------steven james, director of research, linux labs
... ........ ..... .... 230 peachtree st nw ste 701
the original linux labs atlanta.ga.us 30303
-since 1995 http://www.linuxlabs.com
office 404.577.7747 fax 404.577.7743
-----------------------------------------------------------------------
From akohlsmith-linuxbios at benshaw.com Tue Dec 3 10:12:00 2002
From: akohlsmith-linuxbios at benshaw.com (Andrew Kohlsmith)
Date: Tue Dec 3 10:12:00 2002
Subject: It's the IRQ table
In-Reply-To:
References:
Message-ID: <200212031014.35432@-mixdown.ca>
> gcc 3.2 when it compiles the PIRQ table gives me utterly different results
> from 2.96. I now have something to look at.
That might be why I'm getting CRC errors with my priq tables! I'm using gcc
3.1!
Regards,
Andrew
From rminnich at lanl.gov Tue Dec 3 10:32:00 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Tue Dec 3 10:32:00 2002
Subject: linuxbios and gcc 3.2: got it.
Message-ID:
it's a fundamental disagreement between 3.2 and 2.96. I think 3.2 is
right, 2.96 is wrong. But it bit us, because we conformed to 2.96 usage.
Consider the following:
struct thing { int z; };
struct thingy { int a; struct thing t[1]; };
This is like our irq_table struct now. We wish to have the array t be
variable-sized, and the way you get that in gcc 2 is to just initialize it
as needed:
struct thingy x = {1, {{2}, {3}}};
t will be forced to grow as needed.
What a kludge! We declare it as t[1], but then grow it by making the
initializer too big!
What does gcc 3.2 do with this? Well, that's a good question. I've seen a
few different results from gcc:
- complain, and product a truncated output file with no entries
- not even produce an output file.
- in no case does what it does match what gcc 2 did
gcc 3.2 does the sane thing in my view. If you make the array [1], that's
all you should get. Growing it with too big an initializer is ugly!
So how to declare this? Like this:
struct thing { int z; };
struct thingy { int a; struct thing t[]; };
^^^
struct thingy x = {1, {{2}, {3}}};
This works fine. I am going to modify the irq_table struct, since gcc296
complains about the [] but still produces the right code.
My mistake was zeroing in on the mptable, not the irq_table, because I
forgot that our phase 1 image in IDE-flash is a non-SMP kernel. But it was
a good thing in the end as I found this nasty non-compliant (for 3.2) bit
of code in linuxbios.
ron
From akohlsmith at benshaw.com Tue Dec 3 10:35:01 2002
From: akohlsmith at benshaw.com (Andrew Kohlsmith)
Date: Tue Dec 3 10:35:01 2002
Subject: It's the IRQ table
In-Reply-To:
References:
Message-ID: <200212031013.18076@-mixdown.ca>
> gcc 3.2 when it compiles the PIRQ table gives me utterly different results
> from 2.96. I now have something to look at.
That might be why I'm getting CRC errors with my priq tables! I'm using gcc
3.1!
Regards,
Andrew
From rminnich at lanl.gov Tue Dec 3 11:12:00 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Tue Dec 3 11:12:00 2002
Subject: committed fix for irq_tables
Message-ID:
All gcc 2.x users are now going to get a warning on the irq_tables.c
compile. Sorry, but it will produce the right table, and 3.x will also
produce the right table. I've confirmed this by comparing the .o files
that both gcc's produce.
This may fix some of the problems 3.x users have been reporting.
I will confirm a good linuxbios-based boot as soon as I get in to work --
it's snowing here so we have 2-hour delays today.
ron
From k4sus2000 at yahoo.de Tue Dec 3 12:10:00 2002
From: k4sus2000 at yahoo.de (=?iso-8859-1?q?Fredy=20Setiadji?=)
Date: Tue Dec 3 12:10:00 2002
Subject: sis730s manual
In-Reply-To:
Message-ID: <20021203171413.33181.qmail@web9903.mail.yahoo.com>
is ist available on the web site???
fred
--- "Ronald G. Minnich" schrieb: >
On Tue, 3 Dec 2002, Fredy Setiadji wrote:
>
> > where can i find the sis730s manual and register
> sets?
>
> you have to go to SiS.
>
> ron
>
__________________________________________________________________
Gesendet von Yahoo! Mail - http://mail.yahoo.de
Weihnachts-Eink?ufe ohne Stress! http://shopping.yahoo.de
From rminnich at lanl.gov Tue Dec 3 12:29:00 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Tue Dec 3 12:29:00 2002
Subject: sis730s manual
In-Reply-To: <20021203171413.33181.qmail@web9903.mail.yahoo.com>
Message-ID:
On Tue, 3 Dec 2002, Fredy Setiadji wrote:
> is ist available on the web site???
not any more.
on
From rminnich at lanl.gov Tue Dec 3 15:44:00 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Tue Dec 3 15:44:00 2002
Subject: GCC 3.2 can now build linuxbios
Message-ID:
The simple change I made to irq_table did the trick. Myrinet drivers are
now finding their IRQ.
Now to find the next problem ...
RAMDISK: Couldn't find valid RAM disk image starting at 0.
Freeing initrd memory: 741k freed
Kernel panic: VFS: Unable to mount root fs on 01:00
:-)
ron
From rminnich at lanl.gov Tue Dec 3 15:55:00 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Tue Dec 3 15:55:00 2002
Subject: question on e7500 sizeram
Message-ID:
freebios/src/northbridge/intel/E7500/northbridge.c
In this file there is a variable called remap_high. I assume the function
of this is to remap the high memory (512MB) so it is contiguous with the
low 512MB.
Even when remap_high is true, on -current, I end up with two 512MB
segemnts, one at 0 and one at 4 GB.
Anybody have any idea as to why this would happen? It's confusing 2.4.19
from what I can see.
ron
From gnuorder at tampabay.rr.com Tue Dec 3 17:32:00 2002
From: gnuorder at tampabay.rr.com (GNUOrder)
Date: Tue Dec 3 17:32:00 2002
Subject: E7500
In-Reply-To:
References:
Message-ID: <200212032235.gB3MZnfC013891@smtp-server2.tampabay.rr.com>
I had similar trouble with 2.4.19 on a Tyan E7500 motherboard and RH80. The
stock RH 2.4.18 wouldn't work either and none of the pre 2.4.20's I tried
would work. I could only get 2.4.18 to run stable. I used the gcc that came
with RH80 kernel builds I think, though I've since downgraded to the previous
clean release of gcc. I also had to get the latest unrelease BIOS from Tyan
so the BIOS was at least part of the problem. Its not a machine I can play
with to see if 2.4.20 works or if building 2.4.19 with different version of
gcc would have worked.
GO
On Tuesday 03 December 2002 00:12, Ronald G. Minnich wrote:
> Status:
> - working fallback linuxbios that was built on redhat 7.3 w/ gcc 2.96
> (bogus redhat version :-)
> - trying to get a supermicro p4dpe to work on redhat 8.0
> - kernel+initrd is loaded from IDE-flash via etherboot.
> This is a bproc "phase 1" kernel, and will download and boot a
> "phase 2" kernel.
> The phase 1 kernel is non-smp, and should use PIRQ tables or similar to
> set up IRQs, it turns out. It appears not to be MP-table aware. The
> phase 2 kernel is SMP- and MP-table aware.
>
> If I build linuxbios with gcc 3.2, it loads the phase 1 kernel but ...
> that kernel can't find any interrupts for the myrinet card. If I build
> linuxbios with gcc 2.96, that kernel can find interrupts and download the
> phase 2 kernel. The phase 2 kernel finds the MP table and gets everything
> ready to go, but panics when trying to set up the initrd for reasons that
> are not clear. It seems to think it has 4 GB memory, when it fact it has 1
> GB memory with a big memory hole. Can Linux 2.4.19 handle this kind of
> sparse memory map? right now, experience is saying "no", although I
> thought this was working.
>
> Now I think I need to look at the PIRQ table as compiled by gcc 3.2. The
> MP table seems to be created just fine. Interesting.
>
> ron
>
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
From nathanael at gnat.ca Tue Dec 3 19:19:01 2002
From: nathanael at gnat.ca (Nathanael Noblet)
Date: Tue Dec 3 19:19:01 2002
Subject: Question regarding instructions...
Message-ID: <97149AA8-071E-11D7-B449-0003931B4D6A@gnat.ca>
Hello again,
So I ordered 6 of the flash chips and got a PLCC removal tool. I'm
ready to start getting this working on my machine. I am still unclear
as to the steps to proceed in order to do that. I have looked at the
tiara source, there seems to be quite a bit there so that is promising.
Where I become confused is where to put my code and such, how to break
it up. Looking at making a Config file, it says to set the target (for
example winfast) does that mean I need to make my own for arbor (maker
of this SBC)? and then all the mainboard/model stuff as well. How do I
know where everything is to go? Are there any docs relating to how to
proceed to get all the devices setup and placement of files. There
seems to be quite a few directories with nothing in them and that is
confusing as well. I have the output of lspci -vvvv and the datasheet
for the sis530 that is the chipset on this board. I don't see anything
similar to the superio chips that seem to be related to the other sis
boards etc...
So basically I'm wondering:
1) What are the basic things I need to implement / create to get
linuxbios up and compiled etc..
2) Is there anything that better explains the directory/file structure
of the source tree?
a) if there isn't, then how can I determine what to put where?
I think that is it for now. Thanks for the help so far, this is
exciting, I hope to be able to help the project out by getting
LinuxBIOS on one more box, albeit a somewhat older one (but good for
embedded development). :)
--
Nathanael Noblet
Gnat Solutions
4604 Monterey Ave NW
Calgary, AB
T3B 5K4
T/F 403.288.5360
C 403.809.5368
http://www.gnat.ca/
From rminnich at lanl.gov Tue Dec 3 19:36:01 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Tue Dec 3 19:36:01 2002
Subject: Question regarding instructions...
In-Reply-To: <97149AA8-071E-11D7-B449-0003931B4D6A@gnat.ca>
Message-ID:
the empty directories are an artifact of CVS. Sorry, I can't fix it just
now.
ron
From rminnich at lanl.gov Tue Dec 3 19:37:00 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Tue Dec 3 19:37:00 2002
Subject: remap_high in the e7500 northbridge
Message-ID:
Does this mean remap memory to 4GB + or remap high memory to low memory
space. I think I have been misunderstanding it.
ron
From ebiederman at lnxi.com Tue Dec 3 20:16:01 2002
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Dec 3 20:16:01 2002
Subject: remap_high in the e7500 northbridge
In-Reply-To:
References:
Message-ID:
"Ronald G. Minnich" writes:
> Does this mean remap memory to 4GB + or remap high memory to low memory
> space. I think I have been misunderstanding it.
It remaps low memory above 4GB. The hardware feature is designed to
recover memory covered by pci devices.
The option in linuxbios is a debugging option to make certain kernels,
and kernel modules can handle > 4GB of ram.
I have not seen a problem with it set either way.
And yes you were looking at it backwards my apologies for not replying
sooner, it's been a busy day.
Eric
From ebiederman at lnxi.com Tue Dec 3 20:19:00 2002
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Dec 3 20:19:00 2002
Subject: question on e7500 sizeram
In-Reply-To:
References:
Message-ID:
"Ronald G. Minnich" writes:
> freebios/src/northbridge/intel/E7500/northbridge.c
>
> In this file there is a variable called remap_high. I assume the function
> of this is to remap the high memory (512MB) so it is contiguous with the
> low 512MB.
>
> Even when remap_high is true, on -current, I end up with two 512MB
> segemnts, one at 0 and one at 4 GB.
>
> Anybody have any idea as to why this would happen? It's confusing 2.4.19
> from what I can see.
And while I am replying the confusion of 2.4.19 if it is real, is a kernel
problem. If you can confirm that the problems go away when all of
memory is in 1 1GB segment that would be a very interesting data
point. I suspect the kernel simply has some very confusing messages,
and no problems will be solved by flipping this option.
Eric
From rminnich at lanl.gov Tue Dec 3 21:15:01 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Tue Dec 3 21:15:01 2002
Subject: remap_high in the e7500 northbridge
In-Reply-To:
Message-ID:
On 3 Dec 2002, Eric W. Biederman wrote:
> I have not seen a problem with it set either way.
even on 2.4.19? because the 2.4.19 output I've seen indicates it is
extremely confused.
ron
From lawrence at tyanchina.com Tue Dec 3 21:18:00 2002
From: lawrence at tyanchina.com (lawrence)
Date: Tue Dec 3 21:18:00 2002
Subject: How to make a supermicro linuxbios?
Message-ID: <1038968542.1262.30.camel@dai>
Hi all:
I am trying to make a ROM of supermicro p4dpe. I got a romimage of 448K
which is cat from payload.block(400K) and linuxbios.rom(48K). But at the
end of the romimage i can not see the first far jump instruction EAh, so
I suppose it is why the rom does not work on my board. What's wrong?
Thanks,
Lawrence
From rminnich at lanl.gov Tue Dec 3 21:50:01 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Tue Dec 3 21:50:01 2002
Subject: How to make a supermicro linuxbios?
In-Reply-To: <1038968542.1262.30.camel@dai>
Message-ID:
On 4 Dec 2002, lawrence wrote:
> I am trying to make a ROM of supermicro p4dpe. I got a romimage of 448K
> which is cat from payload.block(400K) and linuxbios.rom(48K). But at the
> end of the romimage i can not see the first far jump instruction EAh, so
> I suppose it is why the rom does not work on my board. What's wrong?
>
you need to build a 64KB fallback image. I will send you my now-working
config files, both normal and fallback, for that board.
lawrence, what is your gcc version again?
ron
From rminnich at lanl.gov Tue Dec 3 21:55:00 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Tue Dec 3 21:55:00 2002
Subject: Question regarding instructions...
In-Reply-To: <97149AA8-071E-11D7-B449-0003931B4D6A@gnat.ca>
Message-ID:
the best way to do a new motherboard is find one that is almost the same
in the mainboard tree, and make a copy of that directory, and tailor it as
needed.
So, for example, if you have a motherboard that is a lot like
src/mainboard/digitallogic/smartcore-p5,
and it is called the Noblet Fineboard, then you would do this:
mkdir src/mainboard/Noblet/Fineboard
cp src/mainboard/digitallogic/smartcore-p5/* \
src/mainboard/Noblet/Fineboard
Then you modify the Config file in that directory to match that mainboard.
ron
From ivan at sixfold.com Wed Dec 4 00:04:00 2002
From: ivan at sixfold.com (Ivan Pulleyn)
Date: Wed Dec 4 00:04:00 2002
Subject: Question regarding instructions...
In-Reply-To:
Message-ID:
FYI:
If you do 'cvs update -dP'. After checking out the code, they will go
away.
-d gets any new directories that have been added to the tree since you last updated
-P prunes empty directories after the checkout completes.
This hides the problem with CVS that directories can never be
removed. Also, this reduces the urge people have to delete directories
from the CVS server (which makes it impossible to check out older code
that relied on those directories).
Ivan...
PS - is anyone out there running LinuxBIOS on Tyan S2460? If so,
please email me your config. Thanks!
On Tue, 3 Dec 2002, Ronald G. Minnich wrote:
> the empty directories are an artifact of CVS. Sorry, I can't fix it just
> now.
>
> ron
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>
--
----------------------------------------------------------------------
Ivan Pulleyn
Sixfold Technologies, LLC
Chicago Technology Park
2201 West Campbell Drive
Chicago, IL 60612
email: ivan at sixfold.com
voice: (866) 324-5460 x601
fax: (312) 421-0388
----------------------------------------------------------------------
From aip at cwlinux.com Wed Dec 4 01:18:01 2002
From: aip at cwlinux.com (Andrew Ip)
Date: Wed Dec 4 01:18:01 2002
Subject: common flash hw write enable methods
In-Reply-To: ; from rminnich@lanl.gov on Sun, Dec 01, 2002 at 08:43:06PM -0700
References: <200212012159.54423@-mixdown.ca>
Message-ID: <20021204142212.A9685@mail.cwlinux.com>
Ron,
> Another way I found it on one board was to try every combination of GPIOs
> until the FLASH started working. Not fun, but pretty fast if you write a
> program.
Do you have such a program??
-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.
Tel: (852)2542 2046
Fax: (852)2542 2036
For public pgp key, please obtain it from http://www.keyserver.net/en.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL:
From stepan at suse.de Wed Dec 4 08:57:00 2002
From: stepan at suse.de (Stefan Reinauer)
Date: Wed Dec 4 08:57:00 2002
Subject: common flash hw write enable methods
In-Reply-To:
References: <200212012159.54423@-mixdown.ca>
Message-ID: <20021204140042.GA9132@suse.de>
* Ronald G. Minnich [021202 04:43]:
> Another way I found it on one board was to try every combination of GPIOs
> until the FLASH started working. Not fun, but pretty fast if you write a
> program.
Some machines, like my Thinkpad A21p, reboot immediately on probing, if
the right GPIO is not set. Pretty ugly.
> get the flash burner for this board, run under a simulator of some sort,
> and watch the IOs. Or put a PCI bus analyzer on the machine, run the flash
> program, and watch the IOs. It's not going to be fun.
ouch! sounds like this gets nasty quickly.
> I still don't see how running under Bochs helps with the chipset but maybe
> I missed something.
It doesn't. Basically most flasher programs use some kind of data
structure the look for in the bios memory, that contains pointers to
functions like "map flash to memory", "disable write protection", etc.
This is at least the case with AMI and Award, probably Phoenix as well.
These are 16bit calls, which makes it kind of hard/impossible to really
use directly. It's possible to search for this structure and look at
the code. However, this is likely to be illegal in many countries.
> No, the goal is to make it hard for you to reflash. So the vendors keep
> coming up with new ways to hide this. Very annoying!
Especially after the first non-vendor-written flashers appeared, many
people were scared of viruses destroying the flash data and such.
Security by obscurity...
Stefan
--
The x86 isn't all that complex - it just doesn't make a lot of
sense. -- Mike Johnson, Leader of 80x86 Design at AMD
Microprocessor Report (1994)
From akohlsmith-linuxbios at benshaw.com Wed Dec 4 09:30:01 2002
From: akohlsmith-linuxbios at benshaw.com (Andrew Kohlsmith)
Date: Wed Dec 4 09:30:01 2002
Subject: common flash hw write enable methods
In-Reply-To:
References:
Message-ID: <200212040933.08468@-mixdown.ca>
> I still don't see how running under Bochs helps with the chipset but maybe
> I missed something.
Turn on excessive debugging on Bochs and watch for debug messages saying
"accessing register x on PCI device abc:def" to help narrow it down.
Regards,
Andrew
From akohlsmith-linuxbios at benshaw.com Wed Dec 4 09:37:59 2002
From: akohlsmith-linuxbios at benshaw.com (Andrew Kohlsmith)
Date: Wed Dec 4 09:37:59 2002
Subject: common flash hw write enable methods
In-Reply-To: <20021204140042.GA9132@suse.de>
References: <200212012159.54423@-mixdown.ca> <20021204140042.GA9132@suse.de>
Message-ID: <200212040935.40197@-mixdown.ca>
> It doesn't. Basically most flasher programs use some kind of data
> structure the look for in the bios memory, that contains pointers to
> functions like "map flash to memory", "disable write protection", etc.
> This is at least the case with AMI and Award, probably Phoenix as well.
> These are 16bit calls, which makes it kind of hard/impossible to really
> use directly. It's possible to search for this structure and look at
> the code. However, this is likely to be illegal in many countries.
Not in Canada. :-)
Yeah this does sound kind of ugly. Especially since the Orasis BIOS won't
boot up in Bochs, as it seems to end up hanging due to some PIT simulator
inconsistencies.
> Especially after the first non-vendor-written flashers appeared, many
> people were scared of viruses destroying the flash data and such.
> Security by obscurity...
Well, if worse comes to worst I can just cut the trace and wire those pins to
+12. The datasheet for the chip says that it operates normally under those
circumstances, except that all "soft" boot block protection is disabled.
Regards,
Andrew
From rminnich at lanl.gov Wed Dec 4 09:43:00 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed Dec 4 09:43:00 2002
Subject: common flash hw write enable methods
In-Reply-To: <20021204142212.A9685@mail.cwlinux.com>
Message-ID:
On Wed, 4 Dec 2002, Andrew Ip wrote:
> Ron,
>
> > Another way I found it on one board was to try every combination of GPIOs
> > until the FLASH started working. Not fun, but pretty fast if you write a
> > program.
> Do you have such a program??
it varies for each and every motherboard.
I'll try to find my old one for the T23 (which failed, by the way, thanks
to IBM).
ron
From rminnich at lanl.gov Wed Dec 4 09:47:00 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed Dec 4 09:47:00 2002
Subject: common flash hw write enable methods
In-Reply-To: <20021204140042.GA9132@suse.de>
Message-ID:
On Wed, 4 Dec 2002, Stefan Reinauer wrote:
> Some machines, like my Thinkpad A21p, reboot immediately on probing, if
> the right GPIO is not set. Pretty ugly.
yes, this is an iterative process with many landmines.
>
> > get the flash burner for this board, run under a simulator of some sort,
> > and watch the IOs. Or put a PCI bus analyzer on the machine, run the flash
> > program, and watch the IOs. It's not going to be fun.
>
> ouch! sounds like this gets nasty quickly.
actually the PCI analyzer is the easiest, it allowed us to figure out
L440GX flash and ASUS SMBUS issues in about 15 minutes.
ron
From pyro at linuxlabs.com Wed Dec 4 09:50:00 2002
From: pyro at linuxlabs.com (steven james)
Date: Wed Dec 4 09:50:00 2002
Subject: question on e7500 sizeram
In-Reply-To:
Message-ID:
Greetings,
My understanding is that it is used to accomodate PCI memory mappings. The
layout is regular memory, then PCI devices, APICs and flash, then any
physical ram above remap_high goes over the 4Gig mark (for PAE).
G'day,
sjames
On Tue, 3 Dec 2002, Ronald G. Minnich wrote:
> freebios/src/northbridge/intel/E7500/northbridge.c
>
> In this file there is a variable called remap_high. I assume the function
> of this is to remap the high memory (512MB) so it is contiguous with the
> low 512MB.
>
> Even when remap_high is true, on -current, I end up with two 512MB
> segemnts, one at 0 and one at 4 GB.
>
> Anybody have any idea as to why this would happen? It's confusing 2.4.19
> from what I can see.
>
> ron
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>
--
-------------------------steven james, director of research, linux labs
... ........ ..... .... 230 peachtree st nw ste 701
the original linux labs atlanta.ga.us 30303
-since 1995 http://www.linuxlabs.com
office 404.577.7747 fax 404.577.7743
-----------------------------------------------------------------------
From rminnich at lanl.gov Wed Dec 4 09:55:01 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed Dec 4 09:55:01 2002
Subject: question on e7500 sizeram
In-Reply-To:
Message-ID:
On Wed, 4 Dec 2002, steven james wrote:
> My understanding is that it is used to accomodate PCI memory mappings. The
> layout is regular memory, then PCI devices, APICs and flash, then any
> physical ram above remap_high goes over the 4Gig mark (for PAE).
yea, I read the sense of that remap_high variable backwards: I thought it
meant "remap high memory to low" but it mean "remap low memory to high".
Very cool.
Anybody remember when 32 bits seemed like a lot of memory?
ron
From rminnich at lanl.gov Wed Dec 4 11:27:00 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed Dec 4 11:27:00 2002
Subject: linux 2.4.19 and E820 problems CONFIRMED
Message-ID:
I have just confirmed that 2.4.19 won't work at all with the memory split.
I set remap_high to disable in cmos and the node is now workig correctly.
I think I'm going to have a CONFIG option to disable this completely,
since if it gets turned on accidently I have an unbootable node. Comments?
ron
From pyro at linuxlabs.com Wed Dec 4 11:49:01 2002
From: pyro at linuxlabs.com (steven james)
Date: Wed Dec 4 11:49:01 2002
Subject: common flash hw write enable methods
In-Reply-To: <20021204140042.GA9132@suse.de>
Message-ID:
Greetings,
Security by obscurity is likely part of it, but either it's not the whole
story or not well thought out. A simple jumper is much more secure and not
at all obscure.
G'day,
sjames
On Wed, 4 Dec 2002, Stefan Reinauer wrote:
> * Ronald G. Minnich [021202 04:43]:
> > Another way I found it on one board was to try every combination of GPIOs
> > until the FLASH started working. Not fun, but pretty fast if you write a
> > program.
>
> Some machines, like my Thinkpad A21p, reboot immediately on probing, if
> the right GPIO is not set. Pretty ugly.
>
> > get the flash burner for this board, run under a simulator of some sort,
> > and watch the IOs. Or put a PCI bus analyzer on the machine, run the flash
> > program, and watch the IOs. It's not going to be fun.
>
> ouch! sounds like this gets nasty quickly.
>
> > I still don't see how running under Bochs helps with the chipset but maybe
> > I missed something.
>
> It doesn't. Basically most flasher programs use some kind of data
> structure the look for in the bios memory, that contains pointers to
> functions like "map flash to memory", "disable write protection", etc.
> This is at least the case with AMI and Award, probably Phoenix as well.
> These are 16bit calls, which makes it kind of hard/impossible to really
> use directly. It's possible to search for this structure and look at
> the code. However, this is likely to be illegal in many countries.
>
> > No, the goal is to make it hard for you to reflash. So the vendors keep
> > coming up with new ways to hide this. Very annoying!
>
> Especially after the first non-vendor-written flashers appeared, many
> people were scared of viruses destroying the flash data and such.
> Security by obscurity...
>
> Stefan
>
>
--
-------------------------steven james, director of research, linux labs
... ........ ..... .... 230 peachtree st nw ste 701
the original linux labs atlanta.ga.us 30303
-since 1995 http://www.linuxlabs.com
office 404.577.7747 fax 404.577.7743
-----------------------------------------------------------------------
From pyro at linuxlabs.com Wed Dec 4 12:24:00 2002
From: pyro at linuxlabs.com (steven james)
Date: Wed Dec 4 12:24:00 2002
Subject: question on e7500 sizeram
In-Reply-To:
Message-ID:
Greetings,
Sorta Like when my machine w/ 4 MEG of ram and 120 MEG HD seemed imposible
to ever fill up :-) These days, 32 bits is too cramped for some single
processes.
G'day,
sjames
On Wed, 4 Dec 2002, Ronald G. Minnich wrote:
> On Wed, 4 Dec 2002, steven james wrote:
>
> > My understanding is that it is used to accomodate PCI memory mappings. The
> > layout is regular memory, then PCI devices, APICs and flash, then any
> > physical ram above remap_high goes over the 4Gig mark (for PAE).
>
> yea, I read the sense of that remap_high variable backwards: I thought it
> meant "remap high memory to low" but it mean "remap low memory to high".
>
> Very cool.
>
> Anybody remember when 32 bits seemed like a lot of memory?
>
> ron
>
--
-------------------------steven james, director of research, linux labs
... ........ ..... .... 230 peachtree st nw ste 701
the original linux labs atlanta.ga.us 30303
-since 1995 http://www.linuxlabs.com
office 404.577.7747 fax 404.577.7743
-----------------------------------------------------------------------
From pyro at linuxlabs.com Wed Dec 4 12:28:01 2002
From: pyro at linuxlabs.com (steven james)
Date: Wed Dec 4 12:28:01 2002
Subject: linux 2.4.19 and E820 problems CONFIRMED
In-Reply-To:
Message-ID:
Greetings,
Unless/until the kernel can handle it, I agree.
G'day,
sjames
On Wed, 4 Dec 2002, Ronald G. Minnich wrote:
> I have just confirmed that 2.4.19 won't work at all with the memory split.
>
> I set remap_high to disable in cmos and the node is now workig correctly.
>
> I think I'm going to have a CONFIG option to disable this completely,
> since if it gets turned on accidently I have an unbootable node. Comments?
>
> ron
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>
--
-------------------------steven james, director of research, linux labs
... ........ ..... .... 230 peachtree st nw ste 701
the original linux labs atlanta.ga.us 30303
-since 1995 http://www.linuxlabs.com
office 404.577.7747 fax 404.577.7743
-----------------------------------------------------------------------
From ebiederman at lnxi.com Wed Dec 4 12:44:01 2002
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Dec 4 12:44:01 2002
Subject: linux 2.4.19 and E820 problems CONFIRMED
In-Reply-To:
References:
Message-ID:
steven james writes:
> Greetings,
>
> Unless/until the kernel can handle it, I agree.
It works on 2.4.18 just fine. So if it fails on 2.4.19 it is a kernel
regression. I will take a look at 2.4.19 shortly, and see what the
confusion is. But if this is a kernel regression, the kernel needs
fixing not LinuxBIOS. The configuration is 100% valid.
Ron could you provide a little more detailed report of the practical
problem you are seeing? Where does it blow up? A console log of a
good and a bad bootup would be ideal. I want to make certain when I
attempt to reproduce this that I actually am seeing the problem you
are seeing. Unless I borrow one of the nodes on Pink I cannot
exactly replicate what you are seeing...
Eric
From ebiederman at lnxi.com Wed Dec 4 14:13:00 2002
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Dec 4 14:13:00 2002
Subject: linux 2.4.19 and E820 problems CONFIRMED
In-Reply-To:
References:
Message-ID:
"Ronald G. Minnich" writes:
> I have just confirmed that 2.4.19 won't work at all with the memory split.
>
> I set remap_high to disable in cmos and the node is now workig correctly.
>
> I think I'm going to have a CONFIG option to disable this completely,
> since if it gets turned on accidently I have an unbootable node. Comments?
A small one. For the short term this is not necessary as the remap_high option
is not available in fallback mode. So you should still be able to boot problematical
machines.
Eric
From hansolofalcon at worldnet.att.net Wed Dec 4 16:08:00 2002
From: hansolofalcon at worldnet.att.net (Gregg C Levine)
Date: Wed Dec 4 16:08:00 2002
Subject: common flash hw write enable methods
In-Reply-To: <200212040933.08468@-mixdown.ca>
Message-ID: <001601c29bd9$d8df0c20$ea69580c@who>
Hello from Gregg C Levine
Good idea. But under which version of Bochs? The group over there, is
having excessive problems in making 2.0 reachable by the end of the
year. And how do you do that?
-------------------
Gregg C Levine hansolofalcon at worldnet.att.net
------------------------------------------------------------
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke."? Obi-Wan Kenobi
(This company dedicates this E-Mail to General Obi-Wan Kenobi )
(This company dedicates this E-Mail to Master Yoda )
> -----Original Message-----
> From: linuxbios-admin at clustermatic.org [mailto:linuxbios-
> admin at clustermatic.org] On Behalf Of Andrew Kohlsmith
> Sent: Wednesday, December 04, 2002 9:33 AM
> To: linuxbios at clustermatic.org
> Subject: Re: common flash hw write enable methods
>
> > I still don't see how running under Bochs helps with the chipset but
maybe
> > I missed something.
>
> Turn on excessive debugging on Bochs and watch for debug messages
saying
> "accessing register x on PCI device abc:def" to help narrow it down.
>
> Regards,
> Andrew
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
From hansolofalcon at worldnet.att.net Wed Dec 4 16:15:01 2002
From: hansolofalcon at worldnet.att.net (Gregg C Levine)
Date: Wed Dec 4 16:15:01 2002
Subject: common flash hw write enable methods
In-Reply-To: <200212040935.40197@-mixdown.ca>
Message-ID: <001701c29bd9$dc78ada0$ea69580c@who>
Hello from Gregg C Levine
Pardon me Andrew? It happens that I got the thing to work. This was in
1.4.1 and under Linux, Slackware Linux 8.0 if you're curious. I simply
plugged the file that you made into the space provided, and adjusted the
rest of the settings to match. If you mean that the elf boot program
that everyone is proud of, and rightfully so, does not work under Bochs,
I'll agree. I tabled it, because I could not figure out a way to make it
work. I figured correctly that I'd need to make a port to a particular
motherboard to make it work for me. Oh, and what did you mean? Anyway.
-------------------
Gregg C Levine hansolofalcon at worldnet.att.net
------------------------------------------------------------
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke."? Obi-Wan Kenobi
(This company dedicates this E-Mail to General Obi-Wan Kenobi )
(This company dedicates this E-Mail to Master Yoda )
> -----Original Message-----
> From: linuxbios-admin at clustermatic.org [mailto:linuxbios-
> admin at clustermatic.org] On Behalf Of Andrew Kohlsmith
> Sent: Wednesday, December 04, 2002 9:36 AM
> To: linuxbios at clustermatic.org
> Subject: Re: common flash hw write enable methods
>
> > It doesn't. Basically most flasher programs use some kind of data
> > structure the look for in the bios memory, that contains pointers to
> > functions like "map flash to memory", "disable write protection",
etc.
> > This is at least the case with AMI and Award, probably Phoenix as
well.
> > These are 16bit calls, which makes it kind of hard/impossible to
really
> > use directly. It's possible to search for this structure and look at
> > the code. However, this is likely to be illegal in many countries.
>
> Not in Canada. :-)
>
> Yeah this does sound kind of ugly. Especially since the Orasis BIOS
won't
> boot up in Bochs, as it seems to end up hanging due to some PIT
simulator
> inconsistencies.
>
> > Especially after the first non-vendor-written flashers appeared,
many
> > people were scared of viruses destroying the flash data and such.
> > Security by obscurity...
>
> Well, if worse comes to worst I can just cut the trace and wire those
pins to
> +12. The datasheet for the chip says that it operates normally under
those
> circumstances, except that all "soft" boot block protection is
disabled.
>
> Regards,
> Andrew
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
From akohlsmith-linuxbios at benshaw.com Wed Dec 4 16:35:01 2002
From: akohlsmith-linuxbios at benshaw.com (Andrew Kohlsmith)
Date: Wed Dec 4 16:35:01 2002
Subject: common flash hw write enable methods
In-Reply-To: <001601c29bd9$d8df0c20$ea69580c@who>
References: <001601c29bd9$d8df0c20$ea69580c@who>
Message-ID: <200212041637.16928@-mixdown.ca>
> Hello from Gregg C Levine
> Good idea. But under which version of Bochs? The group over there, is
> having excessive problems in making 2.0 reachable by the end of the
> year. And how do you do that?
You might want to try spacing out your emails a bit, the hello and long
signature lines all mashed up against the actual body text make it difficult
to read.
Having said that, it is easily done by editing the source to Bochs; in
particular, iodev/pci.cc and just reporting PCI reads and writes and then
going through them afterward.
Regards,
Andrew
From akohlsmith-linuxbios at benshaw.com Wed Dec 4 16:38:00 2002
From: akohlsmith-linuxbios at benshaw.com (Andrew Kohlsmith)
Date: Wed Dec 4 16:38:00 2002
Subject: common flash hw write enable methods
In-Reply-To: <001701c29bd9$dc78ada0$ea69580c@who>
References: <001701c29bd9$dc78ada0$ea69580c@who>
Message-ID: <200212041640.32885@-mixdown.ca>
> Pardon me Andrew? It happens that I got the thing to work. This was in
> 1.4.1 and under Linux, Slackware Linux 8.0 if you're curious. I simply
> plugged the file that you made into the space provided, and adjusted the
> rest of the settings to match. If you mean that the elf boot program
> that everyone is proud of, and rightfully so, does not work under Bochs,
> I'll agree. I tabled it, because I could not figure out a way to make it
> work. I figured correctly that I'd need to make a port to a particular
> motherboard to make it work for me. Oh, and what did you mean? Anyway.
The original 256k Dauphin Orasis v1 BIOS will not come up in Bochs; it seems
to get stuck in a timing loop with the PIT. That is what I was referring to.
With the 430tx LinuxBIOS and the ELF IDE payload booter, I was able to get a
lovely kernel panic in Bochs, which is good. Now I'm just trying to get
these damned boards to enable the reflash of the BIOS so I can use /dev/bios
and put LinuxBIOS there.
Regards,
Andrew
From rminnich at lanl.gov Wed Dec 4 20:02:01 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed Dec 4 20:02:01 2002
Subject: linux 2.4.19 and E820 problems CONFIRMED
In-Reply-To:
Message-ID:
On 4 Dec 2002, Eric W. Biederman wrote:
> > I think I'm going to have a CONFIG option to disable this completely,
> > since if it gets turned on accidently I have an unbootable node. Comments?
>
> A small one. For the short term this is not necessary as the remap_high option
> is not available in fallback mode. So you should still be able to boot problematical
> machines.
OK I won't do that option after all, I think this can all be resolved in
the short term.
ron
From malas at pinetron.com Wed Dec 4 20:05:01 2002
From: malas at pinetron.com (Munjun Kang)
Date: Wed Dec 4 20:05:01 2002
Subject: file system error (fwd)
References:
Message-ID: <002f01c29bfa$8a800450$2800a8c0@MALXP>
Thanks for your concerning.
> Greetings,
>
> Any poassability that the amount of memory passed to the kernel is too
> high and the crashes are due to using non-existant memory for a buffer or
> struct?
I've installed the 128MB(in one bank) Memory.
But, my Northbridge uses SMA(shared memory architecture) for interal graphics core(savage 4).
For SMA, NB reserves the 8~32MB physical memory.
I did test in various SMA size, 0, 8, 32 etc.
In my think, this causes the problem.
>
> 1st test is check reported memory on boot, 2nd is memtest86, 3rd is to
> pass mem=(some small value) to the kernel and see what happens.
1st. memory reporting through e820 memmap is good.
2nd. memtest86 has no error, but often shows 1 error/day.
3rd. command line mem=xxm option show the many symptom.
below mem=80m, it works good.
but, over mem=80m to 120m , it show kernel panic after found compressed or segmentation fault in harddisk access.
>
> G'day,
> sjames
>
>
>
> On Mon, 2 Dec 2002, Munjun Kang wrote:
Thanks for reading.
Malas. (Munjun Kang)
>
> > > "Ronald G. Minnich" writes:
> > >
> > > > any ideas?
> > > >
> > > > ron
> > > >
> > > > ---------- Forwarded message ----------
> > > > Date: Fri, 29 Nov 2002 15:35:52 +0900
> > > > From: Munjun Kang
> > > > To: Ronald G. Minnich
> > > > Subject: Re: file system error
> > > >
> > > > Thanks for your reply.
> > > >
> > > > I tried as your suggest.
> > > >
> > > > dd if=/dev/zero of=/dev/hda bs=1024 count=10000 ~ 100000
> > > > Segmentation fault's are occured in random by count.
> > > >
> > > > and then, turn off the UDMA feature by hdparm option.
> > > > But, I can see same symptom.
> > >
> > > All DMA is turned off hdparm -d0 /dev/hda ??
> > Yes, I did it.
> >
> > >
> > > > In this time, I tried to attach SCSI & IEEE1394 SBP-2 devices.
> > > > case1. Adaptec 2930 SCSI adapter + 8GB Seagate SCSI HDD
> > > > case2. IEEE1394 Interface card + external IEEE1394 HDD
> > > > both cases show the same problem.
> > >
> > > The northbridge having DMA problems is still a canidate.
> > > SCSI disks do DMA as well.
> > >
> > > > Now, I think it's not a DMA problem.
> > > > I'm in the maze. hmmmm......
> > > >
> > > > Is there any clear hint?
> > >
> > > Past history with the Athlon problems on VIA chipsets
> > > says that some VIA northbridges have problems with burst traffic.
> > >
> > > And either DMA or a fast memory copy could trigger it. memtest86
> > > currently does not have an optimized memcpy so it could miss that problem.
> > >
> > > Currently I consider your northbridge to be the best canidate.
> > > The same kernel is run under both BIOSes?
> > I tried in several cases.
> > 1. Build-in BIOS + 2.4.18-13 (redhat 8.0) => work
> > 2. Linuxbios + 2.4.18-13 (redhat 8.0) => don't work
> > 3. Linuxbios + 2.4.19 => don't work
> >
> > >
> > > Compared to your previous BIOS are there any unknown settings
> > > in the northbridge?
> > >
> > > In particular what are the differences between, on both boards,
> > > and can you account for the differences.
> > > lspci -s 0:0.0 -xxx
> > > And can you account for all differences.
> > In work,
> > 00:00.0 Host bridge: VIA Technologies, Inc. VT8605 [ProSavage PM133]
> > 00: 06 11 05 06 06 00 10 a2 00 00 00 06 00 08 00 00
> > 10: 08 00 00[e8]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[06 11 05 06]
> > 30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00
> > 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 50: fd db c8 be 05 00 08 08 c0 00 08 08 08 08 08 08
> > 60: 03[aa]00[20]e6 d5 d5 00 43 38 86 0d 08 21 00 00
> > 70: c4 88[cc]0c 0e 81 52 00 01 b4 09 00 00 00 00 00
> > 80: 0f 40 00 00 c0 00 00 00 02 00 00 00 00 00 00 00
> > 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > a0: 02 c0 20 00 07 02 00 1f 00 00 00 00 2f 02 04 00
> > b0: 40 ff 10 00 00 00 00 00 00 00 00 00 00 00 00 00
> > c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
> > d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > f0: 00 00 00 00 00 00 06 00 32 42 00 b0 00 00 00 00
> >
> > In problem,
> > 00:00.0 Class 0600: 1106:0605
> > 00: 06 11 05 06 06 00 10 a2 00 00 00 06 00 08 00 00
> > 10: 08 00 00[f8]00 00 00 00 00 00 00 00 00 00 00 00
> > 20: 00 00 00 00 00 00 00 00 00 00 00 00[00 00 00 00]
> > 30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00
> > 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 50: fd db c8 be 05 00 08 08 c0 00 08 08 08 08 08 08
> > 60: 03[00]00[00]e6 d5 d5 00 43 38 86 0d 08 21 00 00
> > 70: c4 88[4c]0c 0e 81 52 00 01 b4 09 00 00 00 00 00
> > 80: 0f 40 00 00 c0 00 00 00 02 00 00 00 00 00 00 00
> > 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > a0: 02 c0 20 00 07 02 00 1f 00 00 00 00 2f 02 04 00
> > b0: 40 ff 10 00 00 00 00 00 00 00 00 00 00 00 00 00
> > c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
> > d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > f0: 00 00 00 00 00 00 06 00 32 42 00 b0 00 00 00 00
> >
> > 0x13 : Graphics Aperature Base
> > 0x2c : I don't know. maybe same with vendor & device ID
> > 0x61, 0x62 : shadow ram setting
> > 0x72 : CPU to PCI Flow control. difference bit 7 is described as follow.
> > 7bit Retry Status
> > 0 No retry occurred -------- default
> > 1 Retry occurred ----------- write 1 to clear
> >
> > In my opinion, there are not special differences.
> >
> > >
> > > Eric
> > >
> > > _______________________________________________
> > > Linuxbios mailing list
> > > Linuxbios at clustermatic.org
> > > http://www.clustermatic.org/mailman/listinfo/linuxbios
> > >
> > _______________________________________________
> > Linuxbios mailing list
> > Linuxbios at clustermatic.org
> > http://www.clustermatic.org/mailman/listinfo/linuxbios
> >
>
> --
> -------------------------steven james, director of research, linux labs
> ... ........ ..... .... 230 peachtree st nw ste 701
> the original linux labs atlanta.ga.us 30303
> -since 1995 http://www.linuxlabs.com
> office 404.577.7747 fax 404.577.7743
> -----------------------------------------------------------------------
>
>
From rminnich at lanl.gov Wed Dec 4 23:41:01 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed Dec 4 23:41:01 2002
Subject: 2.4.19 and sparse e820 map
Message-ID:
The first problem is this:
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 0000000000000bcc (reserved)
BIOS-e820: 0000000000000bcc - 00000000000a0000 (usable)
BIOS-e820: 00000000000f0000 - 00000000000f0400 (reserved)
BIOS-e820: 0000000000100000 - 0000000020000000 (usable)
BIOS-e820: 0000000100000000 - 0000000120000000 (usable)
3712MB HIGHMEM available.
896MB LOWMEM available.
those MEM numbers are quite bogus. The second problem is that it can't
find the initrd in the image. On a good load the initrd is at 2000a000
i.e. 512MB+some, and that puts it on this mem right at memory that doesn't
exist.
I think it is getting confused early in the game and ending up with an
initrd somewhere bogus.
ron
From rminnich at lanl.gov Wed Dec 4 23:45:01 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed Dec 4 23:45:01 2002
Subject: linux 2.4.19 and E820 problems CONFIRMED
In-Reply-To:
Message-ID:
until I can get a console log of good/bad bootup, can you send me dmesg
output from 2.4.18 booting with the remap_high on?
thanks
ron
From ebiederman at lnxi.com Thu Dec 5 00:19:00 2002
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Dec 5 00:19:00 2002
Subject: 2.4.19 and sparse e820 map
In-Reply-To:
References:
Message-ID:
"Ronald G. Minnich" writes:
> The first problem is this:
> BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 0000000000000bcc (reserved)
> BIOS-e820: 0000000000000bcc - 00000000000a0000 (usable)
> BIOS-e820: 00000000000f0000 - 00000000000f0400 (reserved)
> BIOS-e820: 0000000000100000 - 0000000020000000 (usable)
> BIOS-e820: 0000000100000000 - 0000000120000000 (usable)
> 3712MB HIGHMEM available.
> 896MB LOWMEM available.
>
Looking at the kernel source these seem to be the sizes of the
lowmem and the highmem ranges, and not a count of available ram.
All I had handy was 2.4.17 and it reports in the bogus case:
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 0000000000000be0 (reserved)
BIOS-e820: 0000000000000be0 - 00000000000a0000 (usable)
BIOS-e820: 00000000000f0000 - 00000000000f0400 (reserved)
BIOS-e820: 0000000000100000 - 0000000020000000 (usable)
BIOS-e820: 0000000100000000 - 00000001e0000000 (usable)
Warning only 4GB will be used.
Use a PAE enabled kernel.
3328MB HIGHMEM available.
And then it works just fine. So I do not think there except for
a bad print statement.
> those MEM numbers are quite bogus. The second problem is that it can't
> find the initrd in the image.
> On a good load the initrd is at 2000a000
> i.e. 512MB+some, and that puts it on this mem right at memory that doesn't
> exist.
Ouch how does beoboot decide where to place a ramdisk? I just hard code them
at 8MB in mkelfImage, so it looks to me like it is beoboot that cannot handle
the situation.
> I think it is getting confused early in the game and ending up with an
> initrd somewhere bogus.
Sounds reasonable. With the one caveat that the kernel does not position the
initrd. Which makes beoboot look like the culprit.
Eric
From rminnich at lanl.gov Thu Dec 5 09:07:01 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Thu Dec 5 09:07:01 2002
Subject: 2.4.19 and sparse e820 map
In-Reply-To:
Message-ID:
On 4 Dec 2002, Eric W. Biederman wrote:
> Sounds reasonable. With the one caveat that the kernel does not
> position the initrd. Which makes beoboot look like the culprit.
yeah, I was beginning to think this myself. OK, I'll go look there.
ron
From OliverArnold at via.com.tw Thu Dec 5 19:56:00 2002
From: OliverArnold at via.com.tw (OliverArnold at via.com.tw)
Date: Thu Dec 5 19:56:00 2002
Subject: VIA EPIA - Status
Message-ID: <7BD8956C4C0394468AABA9BD2D52BF7EAF8744@exchtp05.taipei.via.com.tw>
hello ng,
i just want to check, what is the status of the epia port?
oliver
From aip at cwlinux.com Fri Dec 6 02:51:00 2002
From: aip at cwlinux.com (Andrew Ip)
Date: Fri Dec 6 02:51:00 2002
Subject: VIA EPIA - Status
In-Reply-To: <7BD8956C4C0394468AABA9BD2D52BF7EAF8744@exchtp05.taipei.via.com.tw>; from OliverArnold@via.com.tw on Fri, Dec 06, 2002 at 08:58:17AM +0800
References: <7BD8956C4C0394468AABA9BD2D52BF7EAF8744@exchtp05.taipei.via.com.tw>
Message-ID: <20021206155546.A7628@mail.cwlinux.com>
Oliver,
> i just want to check, what is the status of the epia port?
AFAIK, Kelvin has fixed the irq problem by changing IDE mode, and he will send
a patch to us once he has cleaned up the code. I'll also look into it again
some time next week.
-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.
Tel: (852)2542 2046
Fax: (852)2542 2036
For public pgp key, please obtain it from http://www.keyserver.net/en.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL:
From bigpilot at linuxmail.org Fri Dec 6 04:45:00 2002
From: bigpilot at linuxmail.org (Big Pilot)
Date: Fri Dec 6 04:45:00 2002
Subject: Booting from floppy
Message-ID: <20021206094902.13955.qmail@linuxmail.org>
I'm wondering whether it is still possible to boot DOS (or a free equivalent) from a floppy if LinuxBIOS is installed on the mobo. Also, if Linux fails, how is one supposed to repair it? Or is the only option booting Linux off a floppy and repairing using that?
--
______________________________________________
http://www.linuxmail.org/
Now with POP3/IMAP access for only US$19.95/yr
Powered by Outblaze
From adam at cfar.umd.edu Fri Dec 6 08:52:00 2002
From: adam at cfar.umd.edu (Adam Sulmicki)
Date: Fri Dec 6 08:52:00 2002
Subject: Booting from floppy
In-Reply-To: <20021206094902.13955.qmail@linuxmail.org>
Message-ID: <20021206090112.A28351-100000@www.missl.cs.umd.edu>
> I'm wondering whether it is still possible to boot DOS (or a free
> equivalent) from a floppy if LinuxBIOS is installed on the mobo. Also,
> if Linux fails, how is one supposed to repair it? Or is the only option
> booting Linux off a floppy and repairing using that?
Perhpas this FAQ will answer your questions?
http://www.eax.com/ADLO-FAQ.html
--
Adam Sulmicki
http://www.eax.com The Supreme Headquarters of the 32 bit registers
From rminnich at lanl.gov Fri Dec 6 10:08:01 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Dec 6 10:08:01 2002
Subject: Booting from floppy
In-Reply-To: <20021206094902.13955.qmail@linuxmail.org>
Message-ID:
On Fri, 6 Dec 2002, Big Pilot wrote:
>
> I'm wondering whether it is still possible to boot DOS (or a free
> equivalent) from a floppy if LinuxBIOS is installed on the mobo. Also,
> if Linux fails, how is one supposed to repair it? Or is the only option
> booting Linux off a floppy and repairing using that?
the u. md. guys will chime in here with an explanation :-)
ron
From adam at cfar.umd.edu Fri Dec 6 12:39:01 2002
From: adam at cfar.umd.edu (Adam Sulmicki)
Date: Fri Dec 6 12:39:01 2002
Subject: Booting from floppy
In-Reply-To:
Message-ID: <20021206123939.G28351-100000@www.missl.cs.umd.edu>
> the u. md. guys will chime in here with an explanation :-)
I'm trying to use it as the opportunity to improve the FAQ :-)
From bigpilot at linuxmail.org Fri Dec 6 17:02:00 2002
From: bigpilot at linuxmail.org (Big Pilot)
Date: Fri Dec 6 17:02:00 2002
Subject: Booting from floppy
Message-ID: <20021206215824.19556.qmail@linuxmail.org>
So there are two issues: a) DOS isn't supported and b) the floppy as a boot device isn't supported. That will make it a very difficult sell for mobo manufacturers. Can you imagine me buying a Linux PC with LinuxBIOS and it crashing. How am I going to repair it then?
----- Original Message -----
From: Adam Sulmicki
Date: Fri, 6 Dec 2002 12:50:07 -0500 (EST)
To: "Ronald G. Minnich"
Subject: Re: Booting from floppy
>
> > the u. md. guys will chime in here with an explanation :-)
>
> I'm trying to use it as the opportunity to improve the FAQ :-)
>
> From what I saw during the coverage of announcement there were quite a bit
> of folks unfamilar with the BIOS projects, an and this FAQ hopes to clear
> up the confusion.
>
> http://www.eax.com/ADLO-FAQ.html
>
> Big Pilot, if I may call you that, does this FAQ answers tose questions?
> The way I see, the part below is answered by Q5. Since I assume you are
> asking about LinuxBIOS. If you are really asking about linux kernel, then
> it is definitely wrong mailing list.
>
> > > if Linux fails, how is one supposed to repair it? Or is the only
> > > option booting Linux off a floppy and repairing using that?
>
>
> > > I'm wondering whether it is still possible to boot DOS (or a free
> > > equivalent) from a floppy if LinuxBIOS is installed on the mobo.
>
> As for above. We had limited success with Win98 which is DOS based (we can
> get as far as desktop screen, but there are issues), but as the Q6 says it
> is still long way to go.
>
> As for the particular susbsystem -- floppy, it has not been tested at all,
> and is presumed not working at the moment.
>
> --
> Adam Sulmicki
> http://www.eax.com The Supreme Headquarters of the 32 bit registers
>
>
>
--
______________________________________________
http://www.linuxmail.org/
Now with POP3/IMAP access for only US$19.95/yr
Powered by Outblaze
From adam at cfar.umd.edu Fri Dec 6 17:04:01 2002
From: adam at cfar.umd.edu (Adam Sulmicki)
Date: Fri Dec 6 17:04:01 2002
Subject: Booting from floppy
In-Reply-To: <20021206215824.19556.qmail@linuxmail.org>
Message-ID: <20021206171404.R28351-100000@www.missl.cs.umd.edu>
> So there are two issues: a) DOS isn't supported and b) the floppy as a
> boot device isn't supported. That will make it a very difficult sell for
> mobo manufacturers. Can you imagine me buying a Linux PC with LinuxBIOS
> and it crashing. How am I going to repair it then?
Well nobody pretends it is a finished work. As the FAQ says a milestone
has been made but there's tons of work left.
--
Adam Sulmicki
http://www.eax.com The Supreme Headquarters of the 32 bit registers
From rminnich at lanl.gov Fri Dec 6 17:16:01 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Dec 6 17:16:01 2002
Subject: Booting from floppy
In-Reply-To: <20021206215824.19556.qmail@linuxmail.org>
Message-ID:
On Fri, 6 Dec 2002, Big Pilot wrote:
>
> So there are two issues: a) DOS isn't supported and b) the floppy as a
> boot device isn't supported. That will make it a very difficult sell for
> mobo manufacturers. Can you imagine me buying a Linux PC with LinuxBIOS
> and it crashing. How am I going to repair it then?
floppies are dead. What's wrong with a cdrom boot?
ron
From ebiederman at lnxi.com Fri Dec 6 17:43:00 2002
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Dec 6 17:43:00 2002
Subject: Booting from floppy
In-Reply-To: <20021206215824.19556.qmail@linuxmail.org>
References: <20021206215824.19556.qmail@linuxmail.org>
Message-ID:
"Big Pilot" writes:
> So there are two issues: a) DOS isn't supported and b) the floppy as a boot
> device isn't supported. That will make it a very difficult sell for mobo
> manufacturers. Can you imagine me buying a Linux PC with LinuxBIOS and it
> crashing. How am I going to repair it then?
Which hardware you can boot from depends on the bootloader you pair
LinuxBIOS with. ADLO is one, that is just recently maturing into usability.
Etherboot is another.
The linux kernel is another.
9Load for Plan9 is another.
Both etherboot,Linux, and I believe 9Load have floppy support so
there are cases where you can boot from a floppy.
For several of the developers the primary boot devices is the network,
which makes recovering if something goes wrong quite simple, but it does
assume you have a second machine.
The basic boot sequence with LinuxBIOS runs:
A) LinuxBIOS sets up some hardware, and allocates the rest unique addresses.
B) LinuxBIOS loads an ELF formatted bootloader from somewhere normally the same rom chip.
C) The bootloader 9loader/ADLO/Etherboot/(A Linux kernel + initrd) loads and decides what to do.
D) The final kernel (usually Linux) is loaded and you go about your usual computing.
The primary users so far are embedded users, and cluster users.
For use in a cluster, a primary bit of usefulness is how easy you can see what
is wrong (the serial port is available before ram is initialized) and how easy
it is to recover from a machine crash.
The company I work for can currently sell LinuxBIOS, and it has helped
us to get some of our biggest deals. So as it is salable to some, and
it is open source so fell free to pay us back, by developing the
features you want.
Basically LinuxBIOS has one core design. Don't do unnecessary work.
It takes some thought to see how, to make use of that, but it is not
too hard to work with.
Eric
From rminnich at lanl.gov Fri Dec 6 17:53:01 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Dec 6 17:53:01 2002
Subject: linuxbios targets ...
In-Reply-To:
Message-ID:
I heard an amazing data point from a company a few days ago, discussing
the linuxbios issue.
They estimate they have lost $30M just this year due to their inability to
support linuxbios on their boxes (no, it wasn't IBM, but it could have
been). Now for the company in question, this is peanuts -- not even 1/1000
of their gross revenue. But for the salesman for the company in question,
this is lost opportunity to make targets. Their salesmen are more than a
little unhappy. But the companies persist in saying "there is no market"
for LinuxBIOS, the same way they said "there is no market" for Linux, and
the same way they said "there is no market" for Unix.
It's always amazing to me that small companies in the US, with so much
more to lose, are so much more willing to take on risk than the big
companies, who can waste tens of millions in the wink of an eye -- far
more than it would cost them to field LinuxBIOS.
ron
From PhilB at olymed.com Fri Dec 6 19:59:01 2002
From: PhilB at olymed.com (Phil Brooks)
Date: Fri Dec 6 19:59:01 2002
Subject: Booting from floppy
Message-ID: <682FBAAE0A65E1448C5048B7CCEA920F06A3E7@exchange55.olymed_nt.com>
We are interested in using LinuxBIOS on our medical system, running the Digital Logic P5 PC-104 SBC. After reading these posts, and scanning the FAQ, I am confused about boot methods:
Will LinuxBIOS work on a stand-alone system with a EIDE disk?
If floppy boot won't be supported, can it boot from cdrom?
Thanks very much,
Phil Brooks
Phil Brooks - Software Engineer
Olympic Medical
206-268-5119
philb at olymed.com
-----Original Message-----
From: Ronald G. Minnich [mailto:rminnich at lanl.gov]
Sent: Friday, December 06, 2002 2:21 PM
To: Big Pilot
Cc: adam at cfar.umd.edu; linuxbios at clustermatic.org
Subject: Re: Booting from floppy
On Fri, 6 Dec 2002, Big Pilot wrote:
>
> So there are two issues: a) DOS isn't supported and b) the floppy as a
> boot device isn't supported. That will make it a very difficult sell for
> mobo manufacturers. Can you imagine me buying a Linux PC with LinuxBIOS
> and it crashing. How am I going to repair it then?
floppies are dead. What's wrong with a cdrom boot?
ron
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
From adam at cfar.umd.edu Fri Dec 6 20:04:00 2002
From: adam at cfar.umd.edu (Adam Sulmicki)
Date: Fri Dec 6 20:04:00 2002
Subject: Booting from floppy
In-Reply-To: <682FBAAE0A65E1448C5048B7CCEA920F06A3E7@exchange55.olymed_nt.com>
Message-ID: <20021206201220.I28351-100000@www.missl.cs.umd.edu>
> We are interested in using LinuxBIOS on our medical system, running the
> Digital Logic P5 PC-104 SBC. After reading these posts, and scanning the
> FAQ, I am confused about boot methods:
> Will LinuxBIOS work on a stand-alone system with a EIDE disk?
yes, definitely.
> If floppy boot won't be supported, can it boot from cdrom?
It is not that it "won't be supported" as much as there wasn't much of
interested. That's all. I bet it is just at most one day of work to get
booting from floppy to work.. so it is not a big deal.
It would be much easier if you could put what's the target OS you are
going to run, as it would make answering question easier. For example if
you don't need PC BIOS services (it is what ADLO/BOCHS-BIOS is about) then
there are tons of other ways to configure LinuxBIOS.
--
Adam Sulmicki
http://www.eax.com The Supreme Headquarters of the 32 bit registers
From rminnich at lanl.gov Fri Dec 6 20:21:01 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Fri Dec 6 20:21:01 2002
Subject: Booting from floppy
In-Reply-To: <682FBAAE0A65E1448C5048B7CCEA920F06A3E7@exchange55.olymed_nt.com>
Message-ID:
On Fri, 6 Dec 2002, Phil Brooks wrote:
> Will LinuxBIOS work on a stand-alone system with a EIDE disk?
yes.
> If floppy boot won't be supported, can it boot from cdrom?
yes.
Phil, you are welcome to visit LANL if that will help with other
questions. We have lots of p5 systems here with linuxbios.
ron
From ebiederman at lnxi.com Fri Dec 6 21:31:01 2002
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Dec 6 21:31:01 2002
Subject: Booting from floppy
In-Reply-To: <682FBAAE0A65E1448C5048B7CCEA920F06A3E7@exchange55.olymed_nt.com>
References: <682FBAAE0A65E1448C5048B7CCEA920F06A3E7@exchange55.olymed_nt.com>
Message-ID:
"Phil Brooks" writes:
> We are interested in using LinuxBIOS on our medical system, running the Digital
> Logic P5 PC-104 SBC. After reading these posts, and scanning the FAQ, I am
> confused about boot methods:
The initial poster asked a bad question. Booting DOS from a floppy
does not work. Nor is it even a primary target. But there is some
recent work in that direction. And given that everyone assumed he
was asking about the recent work.
> Will LinuxBIOS work on a stand-alone system with a EIDE disk?
Yes.
> If floppy boot won't be supported, can it boot from cdrom?
There is a floppy driver.
To put it clearly the LinuxBIOS core does not really support booting
from anything except a ROM chip. And it really only supports booting
a bootloader of some sort. That said there are a number of interesting
bootloaders for LinuxBIOS that let you boot off of all kinds of things,
IDE drivers/network cards/floppies etc. And as long as the support
is put into a bootloader and not the LinuxBIOS core it is even
encouraged for people to fill in the missing gaps.
The various bootloaders are maturing and people are starting to find
LinuxBIOS useful so we shall see where it goes.
Eric
From jerj at coplanar.net Sat Dec 7 00:19:00 2002
From: jerj at coplanar.net (Jeremy Jackson)
Date: Sat Dec 7 00:19:00 2002
Subject: linuxbios targets ...
References:
Message-ID: <003401c29db0$a3410ef0$7e07a8c0@bridge>
What market sector? Embedded, Beowulf/cluster, ? This is really
interesting stuff.
Is this figure lost hardware sales?
----- Original Message -----
From: "Ronald G. Minnich"
To:
Sent: Friday, December 06, 2002 5:57 PM
Subject: linuxbios targets ...
>
> I heard an amazing data point from a company a few days ago, discussing
> the linuxbios issue.
>
> They estimate they have lost $30M just this year due to their inability to
> support linuxbios on their boxes (no, it wasn't IBM, but it could have
> been). Now for the company in question, this is peanuts -- not even 1/1000
> of their gross revenue. But for the salesman for the company in question,
> this is lost opportunity to make targets. Their salesmen are more than a
> little unhappy. But the companies persist in saying "there is no market"
> for LinuxBIOS, the same way they said "there is no market" for Linux, and
> the same way they said "there is no market" for Unix.
>
> It's always amazing to me that small companies in the US, with so much
> more to lose, are so much more willing to take on risk than the big
> companies, who can waste tens of millions in the wink of an eye -- far
> more than it would cost them to field LinuxBIOS.
>
> ron
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>
From rminnich at lanl.gov Sat Dec 7 10:37:00 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Sat Dec 7 10:37:00 2002
Subject: linuxbios targets ...
In-Reply-To: <003401c29db0$a3410ef0$7e07a8c0@bridge>
Message-ID:
On Sat, 7 Dec 2002, Jeremy Jackson wrote:
> What market sector? Embedded, Beowulf/cluster, ? This is really
> interesting stuff.
cluster only. There's lots more outside cluster.
> Is this figure lost hardware sales?
Lost system sales, yes.
ron
From russell.gower at btinternet.com Sun Dec 8 21:30:01 2002
From: russell.gower at btinternet.com (Russell Gower)
Date: Sun Dec 8 21:30:01 2002
Subject: Build failure!
Message-ID: <003a01c29c85$58c0f7e0$0a01a8c0@winxp>
After cvs updating this afternoon, i'm now unable to build the
winfast-flash.config it fails with the attached error.
I suspect this could be todo with the modification made for gcc 3. or i
might be completely wrong. I would appreciate some help with this one.
Also is there an example of what i need to do to boot from IDE.
Thanks
Russell
ICQ 4186920
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ~output.log
Type: application/octet-stream
Size: 559 bytes
Desc: not available
URL:
From P.Lister at sychron.com Sun Dec 8 21:33:11 2002
From: P.Lister at sychron.com (Peter Lister)
Date: Sun Dec 8 21:33:11 2002
Subject: Booting from floppy
In-Reply-To: Your message of "Fri, 06 Dec 2002 22:58:24 +0100."
<20021206215824.19556.qmail@linuxmail.org>
Message-ID:
> So there are two issues: a) DOS isn't supported and b) the floppy as
> a boot device isn't supported. That will make it a very difficult
> sell for mobo manufacturers. Can you imagine me buying a Linux PC
> with LinuxBIOS and it crashing. How am I going to repair it then?
It's Ron's privilege to name the project as he sees fit, but when
people first see "LinuxBIOS", misinterpretation does seem to be
common. "LinuxBIOS" does *not* mean "a BIOS for Linux" - for one
thing, Linux does needs no BIOS. The project's original intention was
to put Linux in a mobo rom *instead* of a legacy PC BIOS.
The code base has turned out to be useful for much more than that, and
it now supports other boot loader code, such as Etherboot. The UMD
guys have just created ADLO to glue the Bochs PC BIOS together with
LinuxBIOS for the hardware setup, so that various OSes (MS included)
are supported. This is very new, so give it time - but I don't think
we'll need to wait long, this stuff is moving fast.
From rminnich at lanl.gov Sun Dec 8 21:40:00 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Sun Dec 8 21:40:00 2002
Subject: gcc 2.96 != gcc 2.96
Message-ID:
gcc 2.96 on redhat 8.0 compiles linuxbios just fine. gcc 2.96 on redhat
7.3 gets an error on that pirq change I made recently.
I have now put in, tested, and committed the following patch, let me know
if this helps:
#if GCC_VERSION < 3000
struct irq_info slots[1];
#else
struct irq_info slots[];
#endif
Compiles now on my redhat 7.3
ron
From aip at cwlinux.com Sun Dec 8 21:42:01 2002
From: aip at cwlinux.com (Andrew Ip)
Date: Sun Dec 8 21:42:01 2002
Subject: Build failure!
In-Reply-To: <003a01c29c85$58c0f7e0$0a01a8c0@winxp>; from Russell Gower on Thu, Dec 05, 2002 at 05:40:05PM -0000
References: <003a01c29c85$58c0f7e0$0a01a8c0@winxp>
Message-ID: <20021209104732.A5976@mail.cwlinux.com>
Russell,
> After cvs updating this afternoon, i'm now unable to build the
> winfast-flash.config it fails with the attached error.
> I suspect this could be todo with the modification made for gcc 3. or i
> might be completely wrong. I would appreciate some help with this one.
You need to change
< struct irq_info slots[];
to
> struct irq_info *slots;
-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.
Tel: (852)2542 2046
Fax: (852)2542 2036
For public pgp key, please obtain it from http://www.keyserver.net/en.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL:
From rminnich at lanl.gov Sun Dec 8 23:02:00 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Sun Dec 8 23:02:00 2002
Subject: Build failure!
In-Reply-To: <003a01c29c85$58c0f7e0$0a01a8c0@winxp>
Message-ID:
On Thu, 5 Dec 2002, Russell Gower wrote:
> After cvs updating this afternoon, i'm now unable to build the
> winfast-flash.config it fails with the attached error.
> I suspect this could be todo with the modification made for gcc 3. or i
> might be completely wrong. I would appreciate some help with this one.
I think my fix should work now.
here is what is in one of my files to boot ide.
option BOOT_IDE=1
# I really don't like having to include this line.
dir /src/pc80/ide
option USE_ELF_BOOT=1
option RAMTEST=1
option CONFIG_LINUXBIOS_ENABLE_IDE=1
option CONFIG_LINUXBIOS_LEGACY_IDE=1
From rminnich at lanl.gov Sun Dec 8 23:03:00 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Sun Dec 8 23:03:00 2002
Subject: Booting from floppy
In-Reply-To:
Message-ID:
On Sun, 8 Dec 2002, Peter Lister wrote:
> people first see "LinuxBIOS", misinterpretation does seem to be
> common. "LinuxBIOS" does *not* mean "a BIOS for Linux" - for one
> thing, Linux does needs no BIOS. The project's original intention was
> to put Linux in a mobo rom *instead* of a legacy PC BIOS.
it's this way for historical reasons and it almost seems too late to
change. But Garzik really called this freebios so there's no reason not to
pick that up at some point.
ron
From rminnich at lanl.gov Sun Dec 8 23:05:01 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Sun Dec 8 23:05:01 2002
Subject: Build failure!
In-Reply-To: <20021209104732.A5976@mail.cwlinux.com>
Message-ID:
On Mon, 9 Dec 2002, Andrew Ip wrote:
> < struct irq_info slots[];
> to
> > struct irq_info *slots;
>
andrew, are you sure that will work. The first usage means 'array of
undefined length which will be set by an initializer', the second means
'pointer to a slot'. The second seems wrong to me.
ron
From sivakumar.subramani at wipro.com Sun Dec 8 23:54:00 2002
From: sivakumar.subramani at wipro.com (sivakumar)
Date: Sun Dec 8 23:54:00 2002
Subject: LinuxBIOS on my system.
Message-ID: <1039410037.12774.11.camel@Jasmine>
Hi,
PLEASE IGNORE THE ATTACHMENT !!
I trying to bring up my System with LinuxBIOS.My machine configuration
is as follow:
MainBoard: vc15.
NorthBridge: Intel 845 MCH
Southbridge: INtel 82801BA
SuperIO: SMSC LPC47M192.
I have modified the linuxBIOS to support these component as per their
specification. I build the Image also.
When started the system with the new image, I am getting following lines
only through serial output:
Welcome to minicom 2.00.0
OPTIONS: History Buffer, F-key Macros, Search History Buffer, I18n
Compiled on Feb 26 2002, 09:38:06.
Press CTRL-A Z for help on special keys
LinuxBIOS-1.0.0 Sat Oct 26 14:32:26 IST 2002 starting...
LinuxBIOS-1.0.0 Sat Oct 26 14:32:26 IST 2002 starting...
After that nothing is happening. Can any one help me in proceeding
further.
Thanks,
Siva.s
--
sivakumar
wipro
From adam at cfar.umd.edu Mon Dec 9 00:00:00 2002
From: adam at cfar.umd.edu (Adam Sulmicki)
Date: Mon Dec 9 00:00:00 2002
Subject: Booting from floppy
In-Reply-To:
Message-ID: <20021209001124.W42093-100000@www.missl.cs.umd.edu>
> > people first see "LinuxBIOS", misinterpretation does seem to be
> > common. "LinuxBIOS" does *not* mean "a BIOS for Linux" - for one
> > thing, Linux does needs no BIOS. The project's original intention was
> > to put Linux in a mobo rom *instead* of a legacy PC BIOS.
>
> it's this way for historical reasons and it almost seems too late to
> change. But Garzik really called this freebios so there's no reason not to
> pick that up at some point.
Not to mention "EtherBOOT" that boots from IDE.
--
Adam Sulmicki
http://www.eax.com The Supreme Headquarters of the 32 bit registers
From terryc at tyanchina.com Mon Dec 9 00:36:01 2002
From: terryc at tyanchina.com (Terry B. Chen)
Date: Mon Dec 9 00:36:01 2002
Subject: problem in gunzip kernel!
Message-ID: <441383BA85E81D48964152E537886C9D1D2FF8@mail.sh.corp.tyan.com>
I met problem in gunzip my linux kernel:
The message in serial console is :
January 2000, James Hendricks, Dale Webster, and Ron Minnich.
Version 0.1
203:init_bytes() - zkernel_start:0xfff80000 zkernel_mask:0x0000ffff
Searching for 16 byte tags
64:rom_read_bytes() - overflowed source buffer. max_block = 7
init_bytes found 0 tags
Gunzip setup
gunzip_setup
output data is 0x00100000
Gunzipping boot code
bad gzip magic numbers
I think we may have error in zkernel_start address or there is a Tag in linux kernel we must do something?
Best Regards
Terry Chen
From ebiederman at lnxi.com Mon Dec 9 02:12:00 2002
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Dec 9 02:12:00 2002
Subject: Booting from floppy
In-Reply-To:
References:
Message-ID:
Peter Lister writes:
> > So there are two issues: a) DOS isn't supported and b) the floppy as
> > a boot device isn't supported. That will make it a very difficult
> > sell for mobo manufacturers. Can you imagine me buying a Linux PC
> > with LinuxBIOS and it crashing. How am I going to repair it then?
>
> It's Ron's privilege to name the project as he sees fit, but when
> people first see "LinuxBIOS", misinterpretation does seem to be
> common. "LinuxBIOS" does *not* mean "a BIOS for Linux" - for one
> thing, Linux does needs no BIOS.
Bogus.
Linux needs a BIOS, to initialize the platform. Which we have shown
the hard way. Linux simply needs not any help after it gets
except on poorly designed ports.
And LinuxBIOS is a BIOS for Linux.
> The project's original intention was
> to put Linux in a mobo rom *instead* of a legacy PC BIOS.
Which is also suggested by the name LinuxBIOS. Unfortunately
that does not work have as well as initially envisioned.
> The code base has turned out to be useful for much more than that, and
> it now supports other boot loader code, such as Etherboot. The UMD
> guys have just created ADLO to glue the Bochs PC BIOS together with
> LinuxBIOS for the hardware setup, so that various OSes (MS included)
> are supported. This is very new, so give it time - but I don't think
> we'll need to wait long, this stuff is moving fast.
One small step at a time.
Eric
From ebiederman at lnxi.com Mon Dec 9 02:18:00 2002
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Dec 9 02:18:00 2002
Subject: Booting from floppy
In-Reply-To: <20021209001124.W42093-100000@www.missl.cs.umd.edu>
References: <20021209001124.W42093-100000@www.missl.cs.umd.edu>
Message-ID:
Adam Sulmicki writes:
> > > people first see "LinuxBIOS", misinterpretation does seem to be
> > > common. "LinuxBIOS" does *not* mean "a BIOS for Linux" - for one
> > > thing, Linux does needs no BIOS. The project's original intention was
> > > to put Linux in a mobo rom *instead* of a legacy PC BIOS.
> >
> > it's this way for historical reasons and it almost seems too late to
> > change. But Garzik really called this freebios so there's no reason not to
> > pick that up at some point.
>
> Not to mention "EtherBOOT" that boots from IDE.
That one is much less silly. The primary focus is still on booting
over an ethernet network in with etherboot...
Things do tend to expand their functionality when we touch them don't
they.
Another fun one is the Bochs-BIOS running on someplace besides under
Bochs....
Eric
From aip at cwlinux.com Mon Dec 9 03:31:01 2002
From: aip at cwlinux.com (Andrew Ip)
Date: Mon Dec 9 03:31:01 2002
Subject: Build failure!
In-Reply-To: ; from Ronald G. Minnich on Sun, Dec 08, 2002 at 09:09:39PM -0700
References: <20021209104732.A5976@mail.cwlinux.com>
Message-ID: <20021209163611.A10512@mail.cwlinux.com>
Sorry. My mistake...
-Andrew
On Sun, Dec 08, 2002 at 09:09:39PM -0700, Ronald G. Minnich wrote:
> On Mon, 9 Dec 2002, Andrew Ip wrote:
>
> > < struct irq_info slots[];
> > to
> > > struct irq_info *slots;
> >
>
>
> andrew, are you sure that will work. The first usage means 'array of
> undefined length which will be set by an initializer', the second means
> 'pointer to a slot'. The second seems wrong to me.
>
> ron
>
--
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.
Tel: (852)2542 2046
Fax: (852)2542 2036
For public pgp key, please obtain it from http://www.keyserver.net/en.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL:
From malas at pinetron.com Mon Dec 9 04:36:01 2002
From: malas at pinetron.com (Munjun Kang)
Date: Mon Dec 9 04:36:01 2002
Subject: file system error
References:
Message-ID: <002501c29f63$716183b0$2800a8c0@MALXP>
Thanks for your concerning.
> Greetings,
>
> Any poassability that the amount of memory passed to the kernel is too
> high and the crashes are due to using non-existant memory for a buffer or
> struct?
I've installed the 128MB(in one bank) Memory.
But, my Northbridge uses SMA(shared memory architecture) for interal graphics core(savage 4).
For SMA, NB reserves the 8~32MB physical memory.
I did test in various SMA size, 0, 8, 32 etc.
In my think, this causes the problem.
>
> 1st test is check reported memory on boot, 2nd is memtest86, 3rd is to
> pass mem=(some small value) to the kernel and see what happens.
1st. memory reporting through e820 memmap is good.
2nd. memtest86 has no error, but often shows 1 error/day.
3rd. command line mem=xxm option show the many symptom.
below mem=80m, it works good.
but, over mem=80m to 120m , it show kernel panic after found compressed or segmentation fault in harddisk access.
>
> G'day,
> sjames
>
>
>
> On Mon, 2 Dec 2002, Munjun Kang wrote:
Thanks for reading.
Malas. (Munjun Kang)
>
> > > "Ronald G. Minnich" writes:
> > >
> > > > any ideas?
> > > >
> > > > ron
> > > >
> > > > ---------- Forwarded message ----------
> > > > Date: Fri, 29 Nov 2002 15:35:52 +0900
> > > > From: Munjun Kang
> > > > To: Ronald G. Minnich
> > > > Subject: Re: file system error
> > > >
> > > > Thanks for your reply.
> > > >
> > > > I tried as your suggest.
> > > >
> > > > dd if=/dev/zero of=/dev/hda bs=1024 count=10000 ~ 100000
> > > > Segmentation fault's are occured in random by count.
> > > >
> > > > and then, turn off the UDMA feature by hdparm option.
> > > > But, I can see same symptom.
> > >
> > > All DMA is turned off hdparm -d0 /dev/hda ??
> > Yes, I did it.
> >
> > >
> > > > In this time, I tried to attach SCSI & IEEE1394 SBP-2 devices.
> > > > case1. Adaptec 2930 SCSI adapter + 8GB Seagate SCSI HDD
> > > > case2. IEEE1394 Interface card + external IEEE1394 HDD
> > > > both cases show the same problem.
> > >
> > > The northbridge having DMA problems is still a canidate.
> > > SCSI disks do DMA as well.
> > >
> > > > Now, I think it's not a DMA problem.
> > > > I'm in the maze. hmmmm......
> > > >
> > > > Is there any clear hint?
> > >
> > > Past history with the Athlon problems on VIA chipsets
> > > says that some VIA northbridges have problems with burst traffic.
> > >
> > > And either DMA or a fast memory copy could trigger it. memtest86
> > > currently does not have an optimized memcpy so it could miss that problem.
> > >
> > > Currently I consider your northbridge to be the best canidate.
> > > The same kernel is run under both BIOSes?
> > I tried in several cases.
> > 1. Build-in BIOS + 2.4.18-13 (redhat 8.0) => work
> > 2. Linuxbios + 2.4.18-13 (redhat 8.0) => don't work
> > 3. Linuxbios + 2.4.19 => don't work
> >
> > >
> > > Compared to your previous BIOS are there any unknown settings
> > > in the northbridge?
> > >
> > > In particular what are the differences between, on both boards,
> > > and can you account for the differences.
> > > lspci -s 0:0.0 -xxx
> > > And can you account for all differences.
> > In work,
> > 00:00.0 Host bridge: VIA Technologies, Inc. VT8605 [ProSavage PM133]
> > 00: 06 11 05 06 06 00 10 a2 00 00 00 06 00 08 00 00
> > 10: 08 00 00[e8]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[06 11 05 06]
> > 30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00
> > 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 50: fd db c8 be 05 00 08 08 c0 00 08 08 08 08 08 08
> > 60: 03[aa]00[20]e6 d5 d5 00 43 38 86 0d 08 21 00 00
> > 70: c4 88[cc]0c 0e 81 52 00 01 b4 09 00 00 00 00 00
> > 80: 0f 40 00 00 c0 00 00 00 02 00 00 00 00 00 00 00
> > 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > a0: 02 c0 20 00 07 02 00 1f 00 00 00 00 2f 02 04 00
> > b0: 40 ff 10 00 00 00 00 00 00 00 00 00 00 00 00 00
> > c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
> > d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > f0: 00 00 00 00 00 00 06 00 32 42 00 b0 00 00 00 00
> >
> > In problem,
> > 00:00.0 Class 0600: 1106:0605
> > 00: 06 11 05 06 06 00 10 a2 00 00 00 06 00 08 00 00
> > 10: 08 00 00[f8]00 00 00 00 00 00 00 00 00 00 00 00
> > 20: 00 00 00 00 00 00 00 00 00 00 00 00[00 00 00 00]
> > 30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00
> > 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 50: fd db c8 be 05 00 08 08 c0 00 08 08 08 08 08 08
> > 60: 03[00]00[00]e6 d5 d5 00 43 38 86 0d 08 21 00 00
> > 70: c4 88[4c]0c 0e 81 52 00 01 b4 09 00 00 00 00 00
> > 80: 0f 40 00 00 c0 00 00 00 02 00 00 00 00 00 00 00
> > 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > a0: 02 c0 20 00 07 02 00 1f 00 00 00 00 2f 02 04 00
> > b0: 40 ff 10 00 00 00 00 00 00 00 00 00 00 00 00 00
> > c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
> > d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > f0: 00 00 00 00 00 00 06 00 32 42 00 b0 00 00 00 00
> >
> > 0x13 : Graphics Aperature Base
> > 0x2c : I don't know. maybe same with vendor & device ID
> > 0x61, 0x62 : shadow ram setting
> > 0x72 : CPU to PCI Flow control. difference bit 7 is described as follow.
> > 7bit Retry Status
> > 0 No retry occurred -------- default
> > 1 Retry occurred ----------- write 1 to clear
> >
> > In my opinion, there are not special differences.
> >
> > >
> > > Eric
> > >
> > > _______________________________________________
> > > Linuxbios mailing list
> > > Linuxbios at clustermatic.org
> > > http://www.clustermatic.org/mailman/listinfo/linuxbios
> > >
> > _______________________________________________
> > Linuxbios mailing list
> > Linuxbios at clustermatic.org
> > http://www.clustermatic.org/mailman/listinfo/linuxbios
> >
>
> --
> -------------------------steven james, director of research, linux labs
> ... ........ ..... .... 230 peachtree st nw ste 701
> the original linux labs atlanta.ga.us 30303
> -since 1995 http://www.linuxlabs.com
> office 404.577.7747 fax 404.577.7743
> -----------------------------------------------------------------------
>
>
From sivakumar.subramani at wipro.com Mon Dec 9 06:27:01 2002
From: sivakumar.subramani at wipro.com (sivakumar)
Date: Mon Dec 9 06:27:01 2002
Subject: LinuxBIOS on my system.
In-Reply-To: <1039410037.12774.11.camel@Jasmine>
References: <1039410037.12774.11.camel@Jasmine>
Message-ID: <1039433668.1465.15.camel@Jasmine>
PLEASE IGNORE THE ATTACHMENT...
I am getting only the Linux BIOS banner message with LinuxBIOS image.
I found that the banner message is coming from the crt0.s file, which
takes the time stamp of the LinuxBIOS image and prints the LinuxBIOS
startup message.
I am not getting any printk_info from linuxbiosmain function.
I did following steps to build the LinuxBIOS Image:
$python2.1 /vobs/elinux/LinuxBIOS/freebios/util/config/NLBConfig.py ./fi
c.config /vobs/elinux/LinuxBIOS/freebios
$cd fic
$make
After make, I got following image file, which I burn on the flash ROM
chip. While rebooting the system, I got following messages through
serial output:
LinuxBIOS-1.0.0 Sat Oct 26 14:32:26 IST 2002 starting...
LinuxBIOS-1.0.0 Sat Oct 26 14:32:26 IST 2002 starting...
sh-2.04$ ls -l linuxbios.strip
-rwxrwxr-x 1 siva users 65536 Oct 26 13:56
linuxbios.strip*
Can any one help me in resolving the issue?
Thanks,
Siva.s
On Mon, 2002-12-09 at 10:30, sivakumar wrote:
> Hi,
>
>
> PLEASE IGNORE THE ATTACHMENT !!
>
>
> I trying to bring up my System with LinuxBIOS.My machine configuration
> is as follow:
> MainBoard: vc15.
> NorthBridge: Intel 845 MCH
> Southbridge: INtel 82801BA
> SuperIO: SMSC LPC47M192.
>
> I have modified the linuxBIOS to support these component as per their
> specification. I build the Image also.
>
> When started the system with the new image, I am getting following lines
> only through serial output:
>
>
>
>
>
> Welcome to minicom 2.00.0
>
> OPTIONS: History Buffer, F-key Macros, Search History Buffer, I18n
> Compiled on Feb 26 2002, 09:38:06.
>
> Press CTRL-A Z for help on special keys
>
>
>
> LinuxBIOS-1.0.0 Sat Oct 26 14:32:26 IST 2002 starting...
>
> LinuxBIOS-1.0.0 Sat Oct 26 14:32:26 IST 2002 starting...
>
>
>
>
>
>
>
> After that nothing is happening. Can any one help me in proceeding
> further.
>
> Thanks,
> Siva.s
--
sivakumar
wipro
From akohlsmith-linuxbios at benshaw.com Mon Dec 9 08:31:01 2002
From: akohlsmith-linuxbios at benshaw.com (Andrew Kohlsmith)
Date: Mon Dec 9 08:31:01 2002
Subject: Booting from floppy
In-Reply-To:
References:
Message-ID: <200212090834.12883@-mixdown.ca>
> It's Ron's privilege to name the project as he sees fit, but when
> people first see "LinuxBIOS", misinterpretation does seem to be
> common. "LinuxBIOS" does *not* mean "a BIOS for Linux" - for one
> thing, Linux does needs no BIOS. The project's original intention was
> to put Linux in a mobo rom *instead* of a legacy PC BIOS.
Personally when I first heard of LinuxBIOS I wondered what the usefulness of
such a thing was. Yeah fast boots, but how is that any cheaper to buy
motherboards with DoC media than to put an 8M CF card in a CF-IDE adaptor and
boot from that?
Now in quantity (i.e. clusters) I think that LinuxBIOS is probably cheaper in
the long run (I'm sure that Ron's done all of these analyses and so forth
since it appears it's for government use) and I really am glad that Ron and
the toher contributors have done what they did. It's always embarassing to
write off something as being fringe and then a year or so later find yourself
asking questions about it because you need to use it yourself. :-)
Regards,
Andrew
From pyro at linuxlabs.com Mon Dec 9 09:30:01 2002
From: pyro at linuxlabs.com (steven james)
Date: Mon Dec 9 09:30:01 2002
Subject: problem in gunzip kernel!
In-Reply-To: <441383BA85E81D48964152E537886C9D1D2FF8@mail.sh.corp.tyan.com>
Message-ID:
Greetings,
The tags are optional and help when multiple targets are selected. If no
tags are found, the default is to load starting at ZKERNEL_START.
However, if ZKERNEL_START == 0xfff80000, there's not enough room for a
kernel unless you've done something interesting there.
G'day,
sjames
On Mon, 9 Dec 2002, Terry B. Chen wrote:
>
>
> I met problem in gunzip my linux kernel:
> The message in serial console is :
> January 2000, James Hendricks, Dale Webster, and Ron Minnich.
> Version 0.1
>
> 203:init_bytes() - zkernel_start:0xfff80000 zkernel_mask:0x0000ffff
> Searching for 16 byte tags
> 64:rom_read_bytes() - overflowed source buffer. max_block = 7
> init_bytes found 0 tags
> Gunzip setup
> gunzip_setup
> output data is 0x00100000
> Gunzipping boot code
> bad gzip magic numbers
>
> I think we may have error in zkernel_start address or there is a Tag in linux kernel we must do something?
>
>
> Best Regards
> Terry Chen
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>
--
-------------------------steven james, director of research, linux labs
... ........ ..... .... 230 peachtree st nw ste 701
the original linux labs atlanta.ga.us 30303
-since 1995 http://www.linuxlabs.com
office 404.577.7747 fax 404.577.7743
-----------------------------------------------------------------------
From pyro at linuxlabs.com Mon Dec 9 09:42:01 2002
From: pyro at linuxlabs.com (steven james)
Date: Mon Dec 9 09:42:01 2002
Subject: file system error
In-Reply-To: <002501c29f63$716183b0$2800a8c0@MALXP>
Message-ID:
Greetings,
That's looking likely, but it seems that 48M are being eaten somewhere
(quite possably SMA). Unless you actually want an SMA that big, it might
be good to look at the registers for SMA using lspci after a LinuxBIOS
boot. You'll probably have to add some code to initialize that/those
registers. It could be that SMA is taking 48M due to an undocumented or
reserved value in the register.
If this is the cause, the corruption could be infrequent with video not
initialized.
The test to confirm will be examining the registers with LinuxBIOS vs. OEM
BIOS and setting SMA register explicitly to a smaller value and see if the
mem= parameter can be larger in that case.
G'day,
sjames
On Mon, 9 Dec 2002, Munjun Kang wrote:
> Thanks for your concerning.
>
> > Greetings,
> >
> > Any poassability that the amount of memory passed to the kernel is too
> > high and the crashes are due to using non-existant memory for a buffer or
> > struct?
>
> I've installed the 128MB(in one bank) Memory.
> But, my Northbridge uses SMA(shared memory architecture) for interal graphics core(savage 4).
> For SMA, NB reserves the 8~32MB physical memory.
> I did test in various SMA size, 0, 8, 32 etc.
> In my think, this causes the problem.
>
> >
> > 1st test is check reported memory on boot, 2nd is memtest86, 3rd is to
> > pass mem=(some small value) to the kernel and see what happens.
> 1st. memory reporting through e820 memmap is good.
> 2nd. memtest86 has no error, but often shows 1 error/day.
> 3rd. command line mem=xxm option show the many symptom.
> below mem=80m, it works good.
> but, over mem=80m to 120m , it show kernel panic after found compressed or segmentation fault in harddisk access.
>
> >
> > G'day,
> > sjames
> >
> >
> >
> > On Mon, 2 Dec 2002, Munjun Kang wrote:
>
> Thanks for reading.
>
> Malas. (Munjun Kang)
>
> >
> > > > "Ronald G. Minnich" writes:
> > > >
> > > > > any ideas?
> > > > >
> > > > > ron
> > > > >
> > > > > ---------- Forwarded message ----------
> > > > > Date: Fri, 29 Nov 2002 15:35:52 +0900
> > > > > From: Munjun Kang
> > > > > To: Ronald G. Minnich
> > > > > Subject: Re: file system error
> > > > >
> > > > > Thanks for your reply.
> > > > >
> > > > > I tried as your suggest.
> > > > >
> > > > > dd if=/dev/zero of=/dev/hda bs=1024 count=10000 ~ 100000
> > > > > Segmentation fault's are occured in random by count.
> > > > >
> > > > > and then, turn off the UDMA feature by hdparm option.
> > > > > But, I can see same symptom.
> > > >
> > > > All DMA is turned off hdparm -d0 /dev/hda ??
> > > Yes, I did it.
> > >
> > > >
> > > > > In this time, I tried to attach SCSI & IEEE1394 SBP-2 devices.
> > > > > case1. Adaptec 2930 SCSI adapter + 8GB Seagate SCSI HDD
> > > > > case2. IEEE1394 Interface card + external IEEE1394 HDD
> > > > > both cases show the same problem.
> > > >
> > > > The northbridge having DMA problems is still a canidate.
> > > > SCSI disks do DMA as well.
> > > >
> > > > > Now, I think it's not a DMA problem.
> > > > > I'm in the maze. hmmmm......
> > > > >
> > > > > Is there any clear hint?
> > > >
> > > > Past history with the Athlon problems on VIA chipsets
> > > > says that some VIA northbridges have problems with burst traffic.
> > > >
> > > > And either DMA or a fast memory copy could trigger it. memtest86
> > > > currently does not have an optimized memcpy so it could miss that problem.
> > > >
> > > > Currently I consider your northbridge to be the best canidate.
> > > > The same kernel is run under both BIOSes?
> > > I tried in several cases.
> > > 1. Build-in BIOS + 2.4.18-13 (redhat 8.0) => work
> > > 2. Linuxbios + 2.4.18-13 (redhat 8.0) => don't work
> > > 3. Linuxbios + 2.4.19 => don't work
> > >
> > > >
> > > > Compared to your previous BIOS are there any unknown settings
> > > > in the northbridge?
> > > >
> > > > In particular what are the differences between, on both boards,
> > > > and can you account for the differences.
> > > > lspci -s 0:0.0 -xxx
> > > > And can you account for all differences.
> > > In work,
> > > 00:00.0 Host bridge: VIA Technologies, Inc. VT8605 [ProSavage PM133]
> > > 00: 06 11 05 06 06 00 10 a2 00 00 00 06 00 08 00 00
> > > 10: 08 00 00[e8]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[06 11 05 06]
> > > 30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00
> > > 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > 50: fd db c8 be 05 00 08 08 c0 00 08 08 08 08 08 08
> > > 60: 03[aa]00[20]e6 d5 d5 00 43 38 86 0d 08 21 00 00
> > > 70: c4 88[cc]0c 0e 81 52 00 01 b4 09 00 00 00 00 00
> > > 80: 0f 40 00 00 c0 00 00 00 02 00 00 00 00 00 00 00
> > > 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > a0: 02 c0 20 00 07 02 00 1f 00 00 00 00 2f 02 04 00
> > > b0: 40 ff 10 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > f0: 00 00 00 00 00 00 06 00 32 42 00 b0 00 00 00 00
> > >
> > > In problem,
> > > 00:00.0 Class 0600: 1106:0605
> > > 00: 06 11 05 06 06 00 10 a2 00 00 00 06 00 08 00 00
> > > 10: 08 00 00[f8]00 00 00 00 00 00 00 00 00 00 00 00
> > > 20: 00 00 00 00 00 00 00 00 00 00 00 00[00 00 00 00]
> > > 30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00
> > > 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > 50: fd db c8 be 05 00 08 08 c0 00 08 08 08 08 08 08
> > > 60: 03[00]00[00]e6 d5 d5 00 43 38 86 0d 08 21 00 00
> > > 70: c4 88[4c]0c 0e 81 52 00 01 b4 09 00 00 00 00 00
> > > 80: 0f 40 00 00 c0 00 00 00 02 00 00 00 00 00 00 00
> > > 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > a0: 02 c0 20 00 07 02 00 1f 00 00 00 00 2f 02 04 00
> > > b0: 40 ff 10 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > f0: 00 00 00 00 00 00 06 00 32 42 00 b0 00 00 00 00
> > >
> > > 0x13 : Graphics Aperature Base
> > > 0x2c : I don't know. maybe same with vendor & device ID
> > > 0x61, 0x62 : shadow ram setting
> > > 0x72 : CPU to PCI Flow control. difference bit 7 is described as follow.
> > > 7bit Retry Status
> > > 0 No retry occurred -------- default
> > > 1 Retry occurred ----------- write 1 to clear
> > >
> > > In my opinion, there are not special differences.
> > >
> > > >
> > > > Eric
> > > >
> > > > _______________________________________________
> > > > Linuxbios mailing list
> > > > Linuxbios at clustermatic.org
> > > > http://www.clustermatic.org/mailman/listinfo/linuxbios
> > > >
> > > _______________________________________________
> > > Linuxbios mailing list
> > > Linuxbios at clustermatic.org
> > > http://www.clustermatic.org/mailman/listinfo/linuxbios
> > >
> >
> > --
> > -------------------------steven james, director of research, linux labs
> > ... ........ ..... .... 230 peachtree st nw ste 701
> > the original linux labs atlanta.ga.us 30303
> > -since 1995 http://www.linuxlabs.com
> > office 404.577.7747 fax 404.577.7743
> > -----------------------------------------------------------------------
> >
> >
>
>
--
-------------------------steven james, director of research, linux labs
... ........ ..... .... 230 peachtree st nw ste 701
the original linux labs atlanta.ga.us 30303
-since 1995 http://www.linuxlabs.com
office 404.577.7747 fax 404.577.7743
-----------------------------------------------------------------------
From pyro at linuxlabs.com Mon Dec 9 09:49:00 2002
From: pyro at linuxlabs.com (steven james)
Date: Mon Dec 9 09:49:00 2002
Subject: Booting from floppy
In-Reply-To: <200212090834.12883@-mixdown.ca>
Message-ID:
Greetings,
My finding (as a commercial LinuxBIOS supplier in clusters) is that the
cost difference is quite small vs booting from cf or PXE boot, etc. The
big benefit in clusters is that the boot becomes MUCH more reliable.
LinuxBIOS never 'forgets' that serial console is needed, and never stops
for the user to press 'any key' (and no keyboard in sight).
In other cases, I find boards that have good hardware and a good value but
bugs in the BIOS make it unusable w/o LinuxBIOS.
Of course, having the source opens a number of AFAIK unexplored options
for secure netbooting.
G'day,
sjames
On Mon, 9 Dec 2002, Andrew Kohlsmith wrote:
> > It's Ron's privilege to name the project as he sees fit, but when
> > people first see "LinuxBIOS", misinterpretation does seem to be
> > common. "LinuxBIOS" does *not* mean "a BIOS for Linux" - for one
> > thing, Linux does needs no BIOS. The project's original intention was
> > to put Linux in a mobo rom *instead* of a legacy PC BIOS.
>
> Personally when I first heard of LinuxBIOS I wondered what the usefulness of
> such a thing was. Yeah fast boots, but how is that any cheaper to buy
> motherboards with DoC media than to put an 8M CF card in a CF-IDE adaptor and
> boot from that?
>
> Now in quantity (i.e. clusters) I think that LinuxBIOS is probably cheaper in
> the long run (I'm sure that Ron's done all of these analyses and so forth
> since it appears it's for government use) and I really am glad that Ron and
> the toher contributors have done what they did. It's always embarassing to
> write off something as being fringe and then a year or so later find yourself
> asking questions about it because you need to use it yourself. :-)
>
> Regards,
> Andrew
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>
--
-------------------------steven james, director of research, linux labs
... ........ ..... .... 230 peachtree st nw ste 701
the original linux labs atlanta.ga.us 30303
-since 1995 http://www.linuxlabs.com
office 404.577.7747 fax 404.577.7743
-----------------------------------------------------------------------
From rminnich at lanl.gov Mon Dec 9 10:05:00 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Dec 9 10:05:00 2002
Subject: LinuxBIOS on my system.
In-Reply-To: <1039410037.12774.11.camel@Jasmine>
Message-ID:
On 9 Dec 2002, sivakumar wrote:
> is as follow:
> MainBoard: vc15.
> NorthBridge: Intel 845 MCH
> Southbridge: INtel 82801BA
> SuperIO: SMSC LPC47M192.
I have no reason to believe that 845 support works. SO that is probably a
problem.
You are going to have to debug this.
ron
From rminnich at lanl.gov Mon Dec 9 10:07:00 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Dec 9 10:07:00 2002
Subject: problem in gunzip kernel!
In-Reply-To: <441383BA85E81D48964152E537886C9D1D2FF8@mail.sh.corp.tyan.com>
Message-ID:
On Mon, 9 Dec 2002, Terry B. Chen wrote:
>
>
> I met problem in gunzip my linux kernel:
> The message in serial console is :
> January 2000, James Hendricks, Dale Webster, and Ron Minnich.
> Version 0.1
>
> 203:init_bytes() - zkernel_start:0xfff80000 zkernel_mask:0x0000ffff
> Searching for 16 byte tags
> 64:rom_read_bytes() - overflowed source buffer. max_block = 7
> init_bytes found 0 tags
> Gunzip setup
> gunzip_setup
> output data is 0x00100000
> Gunzipping boot code
> bad gzip magic numbers
>
> I think we may have error in zkernel_start address or there is a Tag in
> linux kernel we must do something?
no, the problem is that ELF_BOOT is not set to 1. This is the wrong set of
messages to get. You've got something configured wrong.
ron
From rminnich at lanl.gov Mon Dec 9 10:17:00 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Dec 9 10:17:00 2002
Subject: Booting from floppy
In-Reply-To: <200212090834.12883@-mixdown.ca>
Message-ID:
On Mon, 9 Dec 2002, Andrew Kohlsmith wrote:
> Now in quantity (i.e. clusters) I think that LinuxBIOS is probably cheaper in
> the long run (I'm sure that Ron's done all of these analyses and so forth
> since it appears it's for government use) and I really am glad that Ron and
> the toher contributors have done what they did. It's always embarassing to
> write off something as being fringe and then a year or so later find yourself
> asking questions about it because you need to use it yourself. :-)
Actually lots of people have found uses we would not have thought of, far
outside our domain of use in clusters. I have been quite surprised.
The biggest complaints I hear about the proprietary BIOSes (these are not
my opinions, as a person at a USG-funded lab I am not allowed to have such
opinions)
- very poor code -- tons and tons of assembly that is hard to figure out
- limited control -- the bios does what it is going to do, and if your
hardware doesn't quite fit a PC model, you have to work around it.
Example: you have something in a DIMM slot that looks like memory
but is not. You're going to have to design that hardware in a special
way to make sure the BIOS doesn't configure it as memory. With
LinuxBIOS, that is not an issue -- you can fix this kind of thing
trivially.
- very high overhead costs -- initial flat fee + ongoing per-year
- high unit cost -- on a $50 motherboard, you can spend a huge chunk of
that on bios license. So if you get rid of the BIOS cost, you either
clear more money as profit or get to be more competitive by reducing
unit costs
Again, I don't endorse these claims, as I am not allowed to endorse
things; but I have heard them many times from various vendors and I find
them interesting.
ron
From rminnich at lanl.gov Mon Dec 9 10:19:00 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Dec 9 10:19:00 2002
Subject: file system error
In-Reply-To:
Message-ID:
On Mon, 9 Dec 2002, steven james wrote:
> That's looking likely, but it seems that 48M are being eaten somewhere
> (quite possably SMA). Unless you actually want an SMA that big, it might
> be good to look at the registers for SMA using lspci after a LinuxBIOS
> boot. You'll probably have to add some code to initialize that/those
> registers. It could be that SMA is taking 48M due to an undocumented or
> reserved value in the register.
what's odd here is that the memory sizer functions should reduce the
memory by the amount of SMA size.
From rminnich at lanl.gov Mon Dec 9 10:21:00 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Dec 9 10:21:00 2002
Subject: file system error
In-Reply-To:
Message-ID:
ah, ok, looking at this lspci.
I don't believe there is support in linuxbios for calculcating the SMA
size on this chipset. There is on e.g. sis 630, so on sis 630 sizeram() we
figure out the SMA window size and reduce the ram size by that amount.
Munjun, how do we compute SMA size on this chipset? can you send me C code
to do this? This is a needed upgrade to the chipset support.
ron
From rminnich at lanl.gov Mon Dec 9 10:23:00 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Dec 9 10:23:00 2002
Subject: file system error
In-Reply-To:
Message-ID:
more questions, sorry.
This is an 8605. We need to get that code into the source tree. I assume
you just assumed 8601 code would work?
I'd like to get this worked out.
ron
From rminnich at lanl.gov Mon Dec 9 11:14:01 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Dec 9 11:14:01 2002
Subject: pci_ids.h
Message-ID:
I have merged in the latest 2.4.19 pci_ids.h with the linuxbios version.
In the process I found they have changed and deleted some names.
I have put the linuxbios-specific names at the end of the file bracketed
by a comment pair to show they are linuxbios-specific. Your builds should
be fine.
If they break due to a problem with pci_ids.h please let me know.
I needed to update for some newer chips that were not in the linuxbios
pci_ids.h.
thanks
ron
From nathanael at gnat.ca Mon Dec 9 12:29:00 2002
From: nathanael at gnat.ca (Nathanael Noblet)
Date: Mon Dec 9 12:29:00 2002
Subject: Fast starts...
Message-ID: <660E5317-0B9C-11D7-87C9-0003931B4D6A@gnat.ca>
Hello,
I've been following the discussion on the "Booting from floppy"
thread. Someone said that there are better ways to get fast starts,
like the DoC and CF IDE and what not. I'm still thinking that you're
going to be waiting for the typical BIOS to run its course. So what
were they referring to? something like XIP type CF or what?
--
Nathanael Noblet
Gnat Solutions
4604 Monterey Ave NW
Calgary, AB
T3B 5K4
T/F 403.288.5360
C 403.809.5368
http://www.gnat.ca/
From rminnich at lanl.gov Mon Dec 9 12:39:01 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Dec 9 12:39:01 2002
Subject: Fast starts...
In-Reply-To: <660E5317-0B9C-11D7-87C9-0003931B4D6A@gnat.ca>
Message-ID:
On Mon, 9 Dec 2002, Nathanael Noblet wrote:
> I've been following the discussion on the "Booting from floppy"
> thread. Someone said that there are better ways to get fast starts,
> like the DoC and CF IDE and what not. I'm still thinking that you're
> going to be waiting for the typical BIOS to run its course. So what
> were they referring to? something like XIP type CF or what?
yes, you can put IDE-FLASH in a conventional BIOS and still wait for 5
minutes in some cases.
ron
From akohlsmith-linuxbios at benshaw.com Mon Dec 9 13:27:00 2002
From: akohlsmith-linuxbios at benshaw.com (Andrew Kohlsmith)
Date: Mon Dec 9 13:27:00 2002
Subject: Fast starts...
In-Reply-To:
References:
Message-ID: <200212091331.03099@-mixdown.ca>
> yes, you can put IDE-FLASH in a conventional BIOS and still wait for 5
> minutes in some cases.
Or in my particular application, forever.
Regards,
Andrew
From rminnich at lanl.gov Mon Dec 9 18:12:00 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Dec 9 18:12:00 2002
Subject: more fun with gcc 3.2
Message-ID:
I just fixed ANOTHER PIRQ problem with gcc 3.2
Erik Hendriks has been pointing out to me that this usage of [] looks
shaky, and my reaction was "Yeah, but I don't want to fix it" and also
"Yeah, but it's in C99!". So I hoped not to have to fix it -- it's
supposed to work.
Well, now I've had to.
Gcc was generating bad code for the PIRQ table for this one case. The
symptom was that it failed to put in the first intializer for the slots.
Then everything else went to pieces.
So I have made the following changes to
the pirq_routing.h file:
If IRQ_SLOT_COUNT is defined, then slots are declared as follows:
struct irq_info slots[IRQ_SLOT_COUNT];
otherwise it reverts to the original declaration for GCC 2.0:
struct irq_info slots[0];
And for 3.0 you get the C99 version:
struct irq_info slots[];
To use this, you set the IRQ_SLOT_COUNT. SO, for example, in
the mainboard irq_tables.c for the supermicro p4dpr:
#define IRQ_SLOT_COUNT 24
#include
Then, down below, have exactly that many struct initializations.
Less magic, less bugs, more happy users :-)
ron
p.s. Erik and Greg, I don't want to hear it :-) Yeah, yeah, yeah, you're
right :-)
From kevinh at ispiri.com Mon Dec 9 19:06:00 2002
From: kevinh at ispiri.com (Kevin Hester)
Date: Mon Dec 9 19:06:00 2002
Subject: Starting the real time clock on virgin systems
In-Reply-To:
References:
Message-ID:
Hi all,
First I'd like to describe a problem I've encountered:
I have a virgin motherboard that has never been powered up before. i.e. this
board was not manufactured elsewhere and a 'standard' BIOS has never been
used on it.
When booting this board I discovered an interesting problem: the boot would
hang when the "hwclock" tool was invoked by /etc/rcS.d/.
The underlying problem is that this common linux utility is reading the RTC
via the standard IO ports 70-71. Within this RTC window all of the dallas
semiconductor RTC clones use a few bits in register 0x0a to enable the clock
when power is down. The default values of these bits do not enable the clock
- presumably to avoid draining the battery until the boards are first placed
into production.
I've modified my version of linuxbios to ensure that these bits are set to
enable the RTC updates. My question is, where is the best place to make this
change?
1) In some non linuxbios component (i.e. some little app run at boot time)
2) In linuxbios, but restricted to my mainboard.
3) In linuxbios, but in 'common' code that applies to all intel boards.
I'm in favor of option 3, but I thought I'd ask first. I think this problem
would apply to any board. The reason we haven't seen it before is that most
folks are running linux bios on boards that once had a standard bios. The
standard bios has already 'activated' the RTC updates.
What do you think?
Kevin
From rminnich at lanl.gov Mon Dec 9 19:15:01 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Mon Dec 9 19:15:01 2002
Subject: Starting the real time clock on virgin systems
In-Reply-To:
Message-ID:
On Mon, 9 Dec 2002, Kevin Hester wrote:
> I'm in favor of option 3, but I thought I'd ask first. I think this problem
> would apply to any board. The reason we haven't seen it before is that most
> folks are running linux bios on boards that once had a standard bios. The
> standard bios has already 'activated' the RTC updates.
how about in a new file pc80/rtc.c. That is where legacy pc files are. In
the rtc.c file you can set up the code to do this. We'll make its
inclusion conditional on a config variable.
I actually did have this same problem on the l440gx, but never knew what
it was ...
thanks
ron
From ebiederman at lnxi.com Mon Dec 9 20:37:01 2002
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Dec 9 20:37:01 2002
Subject: Fast starts...
In-Reply-To: <200212091331.03099@-mixdown.ca>
References:
<200212091331.03099@-mixdown.ca>
Message-ID:
Andrew Kohlsmith writes:
> > yes, you can put IDE-FLASH in a conventional BIOS and still wait for 5
> > minutes in some cases.
>
> Or in my particular application, forever. won't let you force drive parameters and don't wait long enough for the CF to
> respond>
It probably means the BIOS is depending on the RDRY signal which many
CF drives don't actually set.
Eric
From adam at cfar.umd.edu Mon Dec 9 21:07:01 2002
From: adam at cfar.umd.edu (Adam Sulmicki)
Date: Mon Dec 9 21:07:01 2002
Subject: [FAQ] The Open Source Stackable PC BIOS
Message-ID: <20021209211130.X43851-100000@www.missl.cs.umd.edu>
Hello,
I have updated the FAQ with various comments from
"Booting from floppy" thread. Comments on FAQ welcome.
http://www.eax.com/ADLO-FAQ.html
This FAQ does not intend to duplicate LinuxBIOS FAQ but rather
give a bird view of the various BIOS projects and give someone new
to the BIOS projects better idea what's it about and why someone
would want to do this.
In this release:
new question * Q10: What is what?
heavily updated * Q3: So is this accomplishment just art for art's sake?
updated question * Q6: So when can I expect to see it in commerical motherboards?
--
Adam Sulmicki
http://www.eax.com The Supreme Headquarters of the 32 bit registers
From sivakumar.subramani at wipro.com Mon Dec 9 22:03:00 2002
From: sivakumar.subramani at wipro.com (sivakumar)
Date: Mon Dec 9 22:03:00 2002
Subject: LinuxBIOS on my system.
In-Reply-To:
References:
Message-ID: <1039489833.2714.9.camel@Jasmine>
Actually I have ported the code of the northbridge to support 845 as per
it's specification.
Can you send me the sample intial output that I need to expect through
serial output, while booting the system with LinuxBIOS.
That might help me in debugging further.
Thanks,
Siva
On Mon, 2002-12-09 at 20:40, Ronald G. Minnich wrote:
> On 9 Dec 2002, sivakumar wrote:
>
> > is as follow:
> > MainBoard: vc15.
> > NorthBridge: Intel 845 MCH
> > Southbridge: INtel 82801BA
> > SuperIO: SMSC LPC47M192.
>
> I have no reason to believe that 845 support works. SO that is probably a
> problem.
>
> You are going to have to debug this.
>
> ron
--
sivakumar
wipro
From pyro at linuxlabs.com Tue Dec 10 09:19:00 2002
From: pyro at linuxlabs.com (steven james)
Date: Tue Dec 10 09:19:00 2002
Subject: Starting the real time clock on virgin systems
In-Reply-To:
Message-ID:
Greetings,
It is probably a good idea to have this code in place in general (if it
can avoid doing the wrong thing if the RTC is already initialized). I've
seen boards where the clock reverts to the uninitialized state. This is
most likely whenever the battery is replaced, or in some cases where the
CMOS is cleared by jumper. In other cases, it seems to happen for no
discernable reason (could be physical vibration causing intermittant
contact w/ battery when being moved).
I do agree that it should be an option.
G'day,
sjames
On Mon, 9 Dec 2002, Ronald G. Minnich wrote:
> On Mon, 9 Dec 2002, Kevin Hester wrote:
>
> > I'm in favor of option 3, but I thought I'd ask first. I think this problem
> > would apply to any board. The reason we haven't seen it before is that most
> > folks are running linux bios on boards that once had a standard bios. The
> > standard bios has already 'activated' the RTC updates.
>
> how about in a new file pc80/rtc.c. That is where legacy pc files are. In
> the rtc.c file you can set up the code to do this. We'll make its
> inclusion conditional on a config variable.
>
> I actually did have this same problem on the l440gx, but never knew what
> it was ...
>
> thanks
>
> ron
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>
--
-------------------------steven james, director of research, linux labs
... ........ ..... .... 230 peachtree st nw ste 701
the original linux labs atlanta.ga.us 30303
-since 1995 http://www.linuxlabs.com
office 404.577.7747 fax 404.577.7743
-----------------------------------------------------------------------
From felix at allot.com Tue Dec 10 11:51:01 2002
From: felix at allot.com (Felix Radensky)
Date: Tue Dec 10 11:51:01 2002
Subject: LinuxBIOS and Vxworks
Message-ID: <3DF61D70.4030602@allot.com>
Hi, folks
We have a custom board based on 440LX chipset and
successfully use LinuxBIOS to boot linux kernel.
In the near future we'll have VxWorks on the same
hardware platform. It would be very nice to have LinuxBIOS
booting this OS as well. Do you think this is possible ? Any hints or
pointers would be very much appreciated.
TIA.
Felix.
From kevinh at ispiri.com Tue Dec 10 19:49:01 2002
From: kevinh at ispiri.com (Kevin Hester)
Date: Tue Dec 10 19:49:01 2002
Subject: LinuxBIOS and Vxworks
In-Reply-To: <3DF61D70.4030602@allot.com>
References: <3DF61D70.4030602@allot.com>
Message-ID:
Hi,
It has been a couple of years since I was futzing with the ugly beast that is
vxWorks ;-). However, I don't think the Intel BSPs are 'plug-and-play'.
I.e. vxWorks counts on the BIOS setting up the IRQ bindings for all PCI
devices.
It seems to me that most of the current linuxbios ROMs don't setup the PCI
IRQs - they rely on the fact that linux is able to use the pirq table and do
it's own PCI IRQ assignment. If you are using vxWorks you may need to make
sure your mainboard.c is assigning IRQs to all PCI devices.
I just sent Andrew a patch which does this for the Via Epia motherboard.
After this is checked in you should search the source for pci_assign_irqs for
example usage.
Kevin
On Tuesday 10 December 2002 08:59, Felix Radensky wrote:
> Hi, folks
>
> We have a custom board based on 440LX chipset and
> successfully use LinuxBIOS to boot linux kernel.
>
> In the near future we'll have VxWorks on the same
> hardware platform. It would be very nice to have LinuxBIOS
> booting this OS as well. Do you think this is possible ? Any hints or
> pointers would be very much appreciated.
>
> TIA.
>
> Felix.
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
From ebiederman at lnxi.com Tue Dec 10 20:27:01 2002
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Dec 10 20:27:01 2002
Subject: LinuxBIOS and Vxworks
In-Reply-To:
References: <3DF61D70.4030602@allot.com>
Message-ID:
Kevin Hester writes:
> Hi,
>
> It has been a couple of years since I was futzing with the ugly beast that is
> vxWorks ;-). However, I don't think the Intel BSPs are 'plug-and-play'.
> I.e. vxWorks counts on the BIOS setting up the IRQ bindings for all PCI
> devices.
>
> It seems to me that most of the current linuxbios ROMs don't setup the PCI
> IRQs - they rely on the fact that linux is able to use the pirq table and do
> it's own PCI IRQ assignment. If you are using vxWorks you may need to make
> sure your mainboard.c is assigning IRQs to all PCI devices.
>
> I just sent Andrew a patch which does this for the Via Epia motherboard.
> After this is checked in you should search the source for pci_assign_irqs for
> example usage.
Does this use the pirq tables or does it do something else?
As much as possible I would like to have a single source table so we
don't run into strange maintenance issues.
Assigning initial irqs, and reporting them in pci space is something
very much in the scope of LinuxBIOS. It just hasn't come up much before
now so the code is not there yet...
Eric
From ebiederman at lnxi.com Tue Dec 10 20:31:01 2002
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Dec 10 20:31:01 2002
Subject: LinuxBIOS on my system.
In-Reply-To: <1039489833.2714.9.camel@Jasmine>
References:
<1039489833.2714.9.camel@Jasmine>
Message-ID:
sivakumar writes:
> Actually I have ported the code of the northbridge to support 845 as per
> it's specification.
>
> Can you send me the sample intial output that I need to expect through
> serial output, while booting the system with LinuxBIOS.
> That might help me in debugging further.
It depends some on how verbose your debug messages are:
>From the p4dpr-igm:
>
>LinuxBIOS-1.0.0.9rc1Normal Fri Oct 25 21:54:54 MDT 2002 starting...
>Power failed
>Restarting pci clocks
>
>
>LinuxBIOS-1.0.0.9rc1Normal Fri Oct 25 21:54:54 MDT 2002 starting...
>Ram1
>Ram2
>Reading SPD data...
>setting based on SPD data...
>done
>Ram3
>Ram Enable 1
>Ram Enable 2
>Ram Enable 3
>Ram Enable 4
>Ram Enable 5
>Ram Enable 6
>Ram Enable 7
>Ram Enable 8
>Ram Enable 9
>Ram Enable 10
>Ram Enable 11
>Ram4
>Bank 01 Side 00 Spot checking: 00000000-0007ffff
>Bank 02 Side 00 Spot checking: 08000000-0807ffff
>Bank 03 Side 00 Spot checking: 10000000-1007ffff
>Bank 03 Side 01 Spot checking: 14000000-1407ffff
>Ram5
>Initializing ECC state...
>ECC state initialized.
>Ram6
>Copying LinuxBIOS to ram.
>Jumping to LinuxBIOS.
>LinuxBIOS-1.0.0.9rc1Normal Fri Oct 25 21:54:54 MDT 2002 booting...
>Finding PCI configuration type.
>handle_superio port 0x0, defaultport 0x2e
>handle_superio Using port 0x2e
>Scanning PCI bus...done
>Allocating PCI resources...done.
>Enabling PCI resourcess...done.
>Initializing PCI devices...
>PCI devices initialized
>totalram: 4096M
>Initializing CPU #0
>microcode_info: sig = 0x00000f24 pf=0x00000002 rev = 0x00000000
>microcode updated from revision 0 to 16
>Enabling cache...done.
>Setting up local apic...done.
>CPU #0 Initialized
>clocks_per_usec: 2397
>Initializing CPU #6
>microcode_info: sig = 0x00000f24 pf=0x00000002 rev = 0x00000000
>microcode updated from revision 0 to 16
>Initializing CPU #1
>Enabling cache...microcode_info: sig = 0x00000f24 pf=0x00000002 rev = 0x00000010Initializing CPU #7
>done.
>microcode updated from revision 16 to 16
>set power on after power fail
>microcode_info: sig = 0x00000f24 pf=0x00000002 rev = 0x00000010
>handle_superio port 0x2e, defaultport 0x2e
>Enabling cache...microcode updated from revision 16 to 16
>Setting up local apic...handle_superio Using port 0x2e
>done.
>done.
>Setting up local apic...Enabling cache...CPU #6 Initialized
>done.
>done.
>Setting up local apic...CPU #1 Initialized
>done.
>CPU #7 Initialized
>handle_superio port 0x2e, defaultport 0x2e
>handle_superio Using port 0x2e
>Copying IRQ routing tables to 0xf0000...done.
>
>Welcome to elfboot, the open sourced starter.
>January 2002, Eric Biederman.
>Version 1.2
>
>Loading Etherboot version: 5.1.2rc7.eb10
>ROM segment 0x0000 length 0xfbf8 reloc 0x00020000
>Etherboot 5.1.2rc7.eb10 (GPL) ELF64 ELF (Multiboot) for [EEPRO100][E1000][IDE]
>CPU 2470 Mhz
>Boot from (N)etwork (D)isk (F)loppy or from (L)ocal?
>Probing pci nic...
>[E1000]The PCI BIOS has not enabled this device!
>Updating PCI command 0003->0007. pci_bus 03 pci_device_fn 20
>Ethernet addr: 00:30:48:12:3D:1D
>e1000: Valid Link not detected
>[EEPRO100]The PCI BIOS has not enabled this device!
>Updating PCI command 0003->0007. pci_bus 04 pci_device_fn 10
>Ethernet addr: 00:30:48:12:37:0F
>
>Searching for server (DHCP)...
>..Me: 192.168.0.27, Server: 192.168.0.252, Gateway 192.168.0.252
>Loading 192.168.0.252:dual-amd-boot2.ebi ...(ELF)... Loading Linux version:
>................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
>
You shouldn't have the double start of LinuxBIOS, that exists
to work around bugs in the board.
>Copying LinuxBIOS to ram.
>Jumping to LinuxBIOS.
>LinuxBIOS-1.0.0.9rc1Normal Fri Oct 25 21:54:54 MDT 2002 booting...
The above is definitely generic code and should be present.
And I would expect the check points in the generic ram setup to be useful.
Eric
From bios at sandtecmedia.com Tue Dec 10 20:32:01 2002
From: bios at sandtecmedia.com (BIOS Support)
Date: Tue Dec 10 20:32:01 2002
Subject: LinuxBIOS and Vxworks
References: <3DF61D70.4030602@allot.com>
Message-ID: <007701c2a0b5$cec13b10$437ffea9@hewlett2n8fn74>
Kevin,
I'm looking forward to duplicating the success you had with the VIA Epia
motherboard code.
Are all the patches for VIA Epia in Andrew's hands now?
Anybody: What's the recommended approach/reference/magic to getting video
going for LinuxBIOS. I'd like to get the on-chip video going on the VIA Epia
board - Hints appreciated.
Thanks.
Andy
----- Original Message -----
From: "Kevin Hester"
To: "Felix Radensky" ;
Sent: Tuesday, December 10, 2002 7:52 PM
Subject: Re: LinuxBIOS and Vxworks
> I just sent Andrew a patch which does this for the Via Epia motherboard.
> After this is checked in you should search the source for pci_assign_irqs
for
> example usage.
>
> Kevin
From ebiederman at lnxi.com Tue Dec 10 21:02:00 2002
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Dec 10 21:02:00 2002
Subject: Starting the real time clock on virgin systems
In-Reply-To:
References:
Message-ID:
Kevin Hester writes:
> Hi all,
>
> First I'd like to describe a problem I've encountered:
>
> I have a virgin motherboard that has never been powered up before. i.e. this
> board was not manufactured elsewhere and a 'standard' BIOS has never been
> used on it.
>
> When booting this board I discovered an interesting problem: the boot would
> hang when the "hwclock" tool was invoked by /etc/rcS.d/ reads the rtc>.
>
> The underlying problem is that this common linux utility is reading the RTC
> via the standard IO ports 70-71. Within this RTC window all of the dallas
> semiconductor RTC clones use a few bits in register 0x0a to enable the clock
> when power is down. The default values of these bits do not enable the clock
> - presumably to avoid draining the battery until the boards are first placed
> into production.
>
> I've modified my version of linuxbios to ensure that these bits are set to
> enable the RTC updates. My question is, where is the best place to make this
> change?
Assuming your RTC hardware is in your southbridge:
src/southbridge///rtc.c or something like that.
It is my experience that only for reading the real time clock is
a real time clock a real time clock. The control functions which are
handled rarely tend to be specific to an individual implementation. Though
there are generally similarities within a family of implementations.
> 1) In some non linuxbios component (i.e. some little app run at boot time)
>
> 2) In linuxbios, but restricted to my mainboard.
>
> 3) In linuxbios, but in 'common' code that applies to all intel boards.
In linuxbios common code that applies to your southbridge.
For now it will probably work best to have that code called from your mainboard,
and others who need it can call that code as well.\
> I'm in favor of option 3, but I thought I'd ask first. I think this problem
> would apply to any board. The reason we haven't seen it before is that most
> folks are running linux bios on boards that once had a standard bios. The
> standard bios has already 'activated' the RTC updates.
I suspect being the second BIOS on the boards has certainly had something to
do with it. But given how much chips vary this may simply be an oddity of
your particular variation of the board.
> What do you think?
Until I see proof that this feature was in the original motorola mc146818
real time clock, and has been in all implementations there after, I
don't want the code to apply all boards indescrimanently.
Eric
From kevinh at ispiri.com Tue Dec 10 21:25:01 2002
From: kevinh at ispiri.com (Kevin Hester)
Date: Tue Dec 10 21:25:01 2002
Subject: LinuxBIOS and Vxworks
In-Reply-To:
References: <3DF61D70.4030602@allot.com>
Message-ID:
Alas, it doesn't read the pirq table. That would be damn smart and such a
feature could be built with a function that uses pci_assign_irqs and the pirq
table.
The reason I decided to not use the PIRQ table was it seemed like some
important information may be missing. For instance, this is the pirq table I
created for the Epia:
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) */
0x88, /* Where the interrupt router lies (dev) */
0x1c20, /* IRQs devoted exclusively to PCI usage */
0x1106, /* Vendor Via */
0x8231, /* Device 8231 southbridge */
0, /* Crap (miniport) */
{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, /* u8 rfu[11] */
0x5e, /* u8 checksum , this hase to set to some value that would
give 0 after the sum of all bytes for this structure (including checksum) */
{
/* PCI slot */
{0,0xa0, {{0x2, 0xdeb8}, {0x3, 0xdeb8}, {0x4, 0xdeb8}, {0x1, 0xdeb8}}, 0x1,
0},
/* Unused */
{0,0x98, {{0x1, 0xdeb8}, {0x2, 0xdeb8}, {0x3, 0xdeb8}, {0x4, 0xdeb8}}, 0x2,
0},
/* Unknown */
{0,0x50, {{0x3, 0xdeb8}, {0x4, 0xdeb8}, {0x1, 0xdeb8}, {0x2, 0xdeb8}}, 0x3,
0},
/* Southbridge internal */
{0,0x88, {{0x1, 0xdeb8}, {0x2, 0xdeb8}, {0x3, 0xdeb8}, {0x4, 0xdeb8}}, 0x4,
0},
/* 8231 Ethernet */
{0,0x90, {{0x1, 0xdeb8}, {0x2, 0xdeb8}, {0x3, 0xdeb8}, {0x4, 0xdeb8}}, 0,
0},
}
};
Most of these values were captured from the standard Award bios that came
with the board - the remaining fields were fixed/added by me. The troubling
thing is the IRQ bitmaps that were passed in for each of the slots, notice
that all of the IRQ bitmaps are 0xdeb8. The standard BIOS is apparently
using this to indicate that a large number of options are available for
assigning IRQs to each of these slots.
The thing that seems to be missing in the PIRQ table is information about how
these various IRQs are connected on the backplane and within the southbridge.
i.e. within the via vt8601 southbridge there is only four PINTA-D mappings
to IRQs . Each one of these PINTx signals can be mapped to any IRQ, but by
definition all of the signals on PINTx are sharing the same IRQ. The OS that
is using the pirq table is not free to manipulate these independently.
It seems like this sharing of IRQs can be described by the link value fields
in the pirq table. For instance, the 8231 Ethernet in the table above shows
a 0x1 for its PINTA link value. The fact that the southbridge internal entry
also shows 0x1 for PINTA link value means that both of those PINTAs must be
bound to the same IRQ.
So, where does this leave us?
We could make a function that uses the pirq table and pci_assign_irqs, but it
would require us assigning a particular meaning to the link value fields in
the pirq table. If we can use the link value fields as
we wish, then we can use the PIRQ pci_exclusive_irq bitmask followed by the
remaining slot specific irq bitmaps.
Unfortunately, reading my "pci system architecture" book says that these link
value fields must be interpreted as specified by the manufacturer of the
interrupt router (the southbridge?).
How do you think we should handle this? I looked at a few PCs/chipsets
around the office, and they all seem to use similar mappings of this link
value field.
I was reluctant to get into the realm of mapping arbitrary pirq tables to
IRQs and I was lazy, so I only added pci_assign_irqs. For a particular
mainboard it is pretty painless to use, for instance the Epia uses:
// Our default IRQ bindings for each of the four devices
static const unsigned char southbridgeIrqs[4] = { 11, 5, 10, 12 };
static const unsigned char enetIrqs[4] = { 11, 5, 10, 12 };
static const unsigned char slotIrqs[4] = { 5, 10, 12, 11 };
/*
Our IDSEL mappings are as follows
PCI slot is AD31 (device 15) (00:14.0)
Southbridge is AD28 (device 12) (00:11.0)
*/
static void pci_routing_fixup(void)
{
struct pci_dev *dev;
dev = pci_find_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8231, 0);
if (dev != NULL)
{
/* initialize PCI interupts - these assignments depend
on the PCB routing of PINTA-D
PINTA = IRQ11
PINTB = IRQ5
PINTC = IRQ10
PINTD = IRQ12
*/
pci_write_config_byte(dev, 0x55, 0xb0);
pci_write_config_byte(dev, 0x56, 0xa5);
pci_write_config_byte(dev, 0x57, 0xc0);
}
// Standard southbridge components
pci_assign_irqs(0, 0x11, southbridgeIrqs);
// Ethernet built into southbridge
pci_assign_irqs(0, 0x12, enetIrqs);
pci_assign_irqs(0, 0x14, slotIrqs);
}
If folks think we can trust the link value fields to show interrupt sharing,
then all is well. I'm happy to make a new function that given an arbitrary
pirq table will make default IRQ assignments.
Kevin
On Tuesday 10 December 2002 17:36, Eric W. Biederman wrote:
> Kevin Hester writes:
> > Hi,
> >
> > It has been a couple of years since I was futzing with the ugly beast
> > that is vxWorks ;-). However, I don't think the Intel BSPs are
> > 'plug-and-play'. I.e. vxWorks counts on the BIOS setting up the IRQ
> > bindings for all PCI devices.
> >
> > It seems to me that most of the current linuxbios ROMs don't setup the
> > PCI IRQs - they rely on the fact that linux is able to use the pirq table
> > and do it's own PCI IRQ assignment. If you are using vxWorks you may
> > need to make sure your mainboard.c is assigning IRQs to all PCI devices.
> >
> > I just sent Andrew a patch which does this for the Via Epia motherboard.
> > After this is checked in you should search the source for pci_assign_irqs
> > for example usage.
>
> Does this use the pirq tables or does it do something else?
> As much as possible I would like to have a single source table so we
> don't run into strange maintenance issues.
>
> Assigning initial irqs, and reporting them in pci space is something
> very much in the scope of LinuxBIOS. It just hasn't come up much before
> now so the code is not there yet...
>
> Eric
From steve at nexpath.com Tue Dec 10 21:26:00 2002
From: steve at nexpath.com (Steve M. Gehlbach)
Date: Tue Dec 10 21:26:00 2002
Subject: LinuxBIOS and Vxworks
In-Reply-To: <007701c2a0b5$cec13b10$437ffea9@hewlett2n8fn74>
Message-ID:
> Anybody: What's the recommended approach/reference/magic to getting video
> going for LinuxBIOS. I'd like to get the on-chip video going on
> the VIA Epia
> board - Hints appreciated.
>
> Thanks.
> Andy
Do you mean a linuxbios vga text console?
I have the code to set the legacy registers to start VGA for a vga console,
integrated into linuxbios, working on two different integrated chips, the
stpc cpu/chipset, and the sis 630 chipset. It sets the registers for
640x400 std text vga, and also 640x480x4 graphics. I was working on the
display of a .pcx graphics file when I had to get onto something else, but
it was all working the last time I tried it.
You are welcome to the code if it would help. AFAIR the EPIA is the
PLE133/vt8601a, which has legacy VGA registers. All you need usually is
legacy plus a "few other settings" to get text and/or simple legacy graphics
going. The "few other settings" can be bitch, though.
-Steve
From kevinh at ispiri.com Tue Dec 10 21:55:01 2002
From: kevinh at ispiri.com (Kevin Hester)
Date: Tue Dec 10 21:55:01 2002
Subject: Starting the real time clock on virgin systems
In-Reply-To:
References:
Message-ID:
Hi,
Re: proof that this feature is in the mc146818
Sure, I agree - proof good. Saddly, the only datasheets I can find on the
net are for newer clones on this chip. The common dallas semi part datasheet
doesn't show the register usage (arrgh!). However, this via clone does show
register usage (attached).
For REGISTERA it says that DV0-DV2 must have the value of 010 to turn on the
oscillator. The default value of these bits are zero and the award BIOS on
my board will init these bits correctly if found to be zero.
The problem occurs in the linux hwclock tool. In rtc.c it spins waiting for
the second count to change. If the RTC has not had the oscillator enabled,
the second count does not change.
For the patches I've submitted, I've simply called rtc_init(0) from the
vt8601 southbridge init. I didn't want to change other systems right now.
Ron mentioned he had seen this exact behavior on some 440bx(?) board he was
working on. If someone is out there with some different chip set, you can do
an experiment:
* Shut the system down
* Remove the battery
* Wait a good long time
* Insert the battery
* Boot linuxbios & linux. If hwclock hangs, then you have this problem.
Kevin
On Tuesday 10 December 2002 18:11, Eric W. Biederman wrote:
> Kevin Hester writes:
> > Hi all,
> >
> > First I'd like to describe a problem I've encountered:
> >
> > I have a virgin motherboard that has never been powered up before. i.e.
> > this board was not manufactured elsewhere and a 'standard' BIOS has never
> > been used on it.
> >
> > When booting this board I discovered an interesting problem: the boot
> > would hang when the "hwclock" tool was invoked by /etc/rcS.d/ > that reads the rtc>.
> >
> > The underlying problem is that this common linux utility is reading the
> > RTC via the standard IO ports 70-71. Within this RTC window all of the
> > dallas semiconductor RTC clones use a few bits in register 0x0a to enable
> > the clock when power is down. The default values of these bits do not
> > enable the clock - presumably to avoid draining the battery until the
> > boards are first placed into production.
> >
> > I've modified my version of linuxbios to ensure that these bits are set
> > to enable the RTC updates. My question is, where is the best place to
> > make this change?
>
> Assuming your RTC hardware is in your southbridge:
> src/southbridge///rtc.c or something like that.
>
> It is my experience that only for reading the real time clock is
> a real time clock a real time clock. The control functions which are
> handled rarely tend to be specific to an individual implementation. Though
> there are generally similarities within a family of implementations.
>
> > 1) In some non linuxbios component (i.e. some little app run at boot
> > time)
> >
> > 2) In linuxbios, but restricted to my mainboard.
> >
> > 3) In linuxbios, but in 'common' code that applies to all intel boards.
>
> In linuxbios common code that applies to your southbridge.
> For now it will probably work best to have that code called from your
> mainboard, and others who need it can call that code as well.\
>
> > I'm in favor of option 3, but I thought I'd ask first. I think this
> > problem would apply to any board. The reason we haven't seen it before
> > is that most folks are running linux bios on boards that once had a
> > standard bios. The standard bios has already 'activated' the RTC
> > updates.
>
> I suspect being the second BIOS on the boards has certainly had something
> to do with it. But given how much chips vary this may simply be an oddity
> of your particular variation of the board.
>
> > What do you think?
>
> Until I see proof that this feature was in the original motorola mc146818
> real time clock, and has been in all implementations there after, I
> don't want the code to apply all boards indescrimanently.
>
> Eric
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vt82c885.pdf
Type: application/pdf
Size: 74090 bytes
Desc: not available
URL:
From bios at sandtecmedia.com Tue Dec 10 22:05:01 2002
From: bios at sandtecmedia.com (BIOS Support)
Date: Tue Dec 10 22:05:01 2002
Subject: LinuxBIOS and Vxworks
References:
Message-ID: <00cb01c2a0c2$d0bcaa00$437ffea9@hewlett2n8fn74>
> Do you mean a linuxbios vga text console?
Yes, that's a start. I'd be looking for how quick I can put something on the
screen to pacify users - it could even be character graphics for a simple
logo.
> I have the code to set the legacy registers to start VGA for a vga
console,
> integrated into linuxbios, working on two different integrated chips, the
> stpc cpu/chipset, and the sis 630 chipset. It sets the registers for
> 640x400 std text vga, and also 640x480x4 graphics. I was working on the
> display of a .pcx graphics file when I had to get onto something else, but
> it was all working the last time I tried it.
Graphics through the frame buffer would be nice but I'm willing to look into
that. I've heard of some code that already works with the vt8601 that I'm
looking to use.
> You are welcome to the code if it would help. AFAIR the EPIA is the
> PLE133/vt8601a, which has legacy VGA registers. All you need usually is
> legacy plus a "few other settings" to get text and/or simple legacy
graphics
> going. The "few other settings" can be bitch, though.
Yep, the "few other settings" is like the saying in engineering that goes
something along the lines of "the final 10% of the work takes 90% of the
time." That's in the category of "magic" that I was referring too earlier
(it goes by other names such as "company confidential", "proprietary", "NDA
required", etc.).
Andy
From pyro at linuxlabs.com Tue Dec 10 22:47:00 2002
From: pyro at linuxlabs.com (steven james)
Date: Tue Dec 10 22:47:00 2002
Subject: Starting the real time clock on virgin systems
In-Reply-To:
Message-ID:
Greetings,
if the init is what I think it is ( setting bit 5 in RTC index 0x0a, the
divider), it should be the same for all RTC. The part that tends to differ
is the PnP stuff. The index accesses from port 0x70-71 tend to stick to
standards.
G'day,
sjames
On 10 Dec 2002, Eric W. Biederman wrote:
> Kevin Hester writes:
>
> > Hi all,
> >
> > First I'd like to describe a problem I've encountered:
> >
> > I have a virgin motherboard that has never been powered up before. i.e. this
> > board was not manufactured elsewhere and a 'standard' BIOS has never been
> > used on it.
> >
> > When booting this board I discovered an interesting problem: the boot would
> > hang when the "hwclock" tool was invoked by /etc/rcS.d/ > reads the rtc>.
> >
> > The underlying problem is that this common linux utility is reading the RTC
> > via the standard IO ports 70-71. Within this RTC window all of the dallas
> > semiconductor RTC clones use a few bits in register 0x0a to enable the clock
> > when power is down. The default values of these bits do not enable the clock
> > - presumably to avoid draining the battery until the boards are first placed
> > into production.
> >
> > I've modified my version of linuxbios to ensure that these bits are set to
> > enable the RTC updates. My question is, where is the best place to make this
> > change?
>
> Assuming your RTC hardware is in your southbridge:
> src/southbridge///rtc.c or something like that.
>
> It is my experience that only for reading the real time clock is
> a real time clock a real time clock. The control functions which are
> handled rarely tend to be specific to an individual implementation. Though
> there are generally similarities within a family of implementations.
>
> > 1) In some non linuxbios component (i.e. some little app run at boot time)
> >
> > 2) In linuxbios, but restricted to my mainboard.
> >
> > 3) In linuxbios, but in 'common' code that applies to all intel boards.
>
> In linuxbios common code that applies to your southbridge.
> For now it will probably work best to have that code called from your mainboard,
> and others who need it can call that code as well.\
>
> > I'm in favor of option 3, but I thought I'd ask first. I think this problem
> > would apply to any board. The reason we haven't seen it before is that most
> > folks are running linux bios on boards that once had a standard bios. The
> > standard bios has already 'activated' the RTC updates.
>
> I suspect being the second BIOS on the boards has certainly had something to
> do with it. But given how much chips vary this may simply be an oddity of
> your particular variation of the board.
>
> > What do you think?
>
> Until I see proof that this feature was in the original motorola mc146818
> real time clock, and has been in all implementations there after, I
> don't want the code to apply all boards indescrimanently.
>
> Eric
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>
--
-------------------------steven james, director of research, linux labs
... ........ ..... .... 230 peachtree st nw ste 701
the original linux labs atlanta.ga.us 30303
-since 1995 http://www.linuxlabs.com
office 404.577.7747 fax 404.577.7743
-----------------------------------------------------------------------
From pyro at linuxlabs.com Tue Dec 10 22:50:01 2002
From: pyro at linuxlabs.com (steven james)
Date: Tue Dec 10 22:50:01 2002
Subject: Starting the real time clock on virgin systems
In-Reply-To:
Message-ID:
Greetings,
Confirmed on Intel Clearwater (e7500 chipset w/ RTC built in to NatSemi
superio).
G'day,
sjames
On Tue, 10 Dec 2002, Kevin Hester wrote:
> Hi,
>
> Re: proof that this feature is in the mc146818
>
> Sure, I agree - proof good. Saddly, the only datasheets I can find on the
> net are for newer clones on this chip. The common dallas semi part datasheet
> doesn't show the register usage (arrgh!). However, this via clone does show
> register usage (attached).
>
> For REGISTERA it says that DV0-DV2 must have the value of 010 to turn on the
> oscillator. The default value of these bits are zero and the award BIOS on
> my board will init these bits correctly if found to be zero.
>
> The problem occurs in the linux hwclock tool. In rtc.c it spins waiting for
> the second count to change. If the RTC has not had the oscillator enabled,
> the second count does not change.
>
> For the patches I've submitted, I've simply called rtc_init(0) from the
> vt8601 southbridge init. I didn't want to change other systems right now.
>
> Ron mentioned he had seen this exact behavior on some 440bx(?) board he was
> working on. If someone is out there with some different chip set, you can do
> an experiment:
>
> * Shut the system down
> * Remove the battery
> * Wait a good long time
> * Insert the battery
> * Boot linuxbios & linux. If hwclock hangs, then you have this problem.
>
> Kevin
>
>
> On Tuesday 10 December 2002 18:11, Eric W. Biederman wrote:
> > Kevin Hester writes:
> > > Hi all,
> > >
> > > First I'd like to describe a problem I've encountered:
> > >
> > > I have a virgin motherboard that has never been powered up before. i.e.
> > > this board was not manufactured elsewhere and a 'standard' BIOS has never
> > > been used on it.
> > >
> > > When booting this board I discovered an interesting problem: the boot
> > > would hang when the "hwclock" tool was invoked by /etc/rcS.d/ > > that reads the rtc>.
> > >
> > > The underlying problem is that this common linux utility is reading the
> > > RTC via the standard IO ports 70-71. Within this RTC window all of the
> > > dallas semiconductor RTC clones use a few bits in register 0x0a to enable
> > > the clock when power is down. The default values of these bits do not
> > > enable the clock - presumably to avoid draining the battery until the
> > > boards are first placed into production.
> > >
> > > I've modified my version of linuxbios to ensure that these bits are set
> > > to enable the RTC updates. My question is, where is the best place to
> > > make this change?
> >
> > Assuming your RTC hardware is in your southbridge:
> > src/southbridge///rtc.c or something like that.
> >
> > It is my experience that only for reading the real time clock is
> > a real time clock a real time clock. The control functions which are
> > handled rarely tend to be specific to an individual implementation. Though
> > there are generally similarities within a family of implementations.
> >
> > > 1) In some non linuxbios component (i.e. some little app run at boot
> > > time)
> > >
> > > 2) In linuxbios, but restricted to my mainboard.
> > >
> > > 3) In linuxbios, but in 'common' code that applies to all intel boards.
> >
> > In linuxbios common code that applies to your southbridge.
> > For now it will probably work best to have that code called from your
> > mainboard, and others who need it can call that code as well.\
> >
> > > I'm in favor of option 3, but I thought I'd ask first. I think this
> > > problem would apply to any board. The reason we haven't seen it before
> > > is that most folks are running linux bios on boards that once had a
> > > standard bios. The standard bios has already 'activated' the RTC
> > > updates.
> >
> > I suspect being the second BIOS on the boards has certainly had something
> > to do with it. But given how much chips vary this may simply be an oddity
> > of your particular variation of the board.
> >
> > > What do you think?
> >
> > Until I see proof that this feature was in the original motorola mc146818
> > real time clock, and has been in all implementations there after, I
> > don't want the code to apply all boards indescrimanently.
> >
> > Eric
>
--
-------------------------steven james, director of research, linux labs
... ........ ..... .... 230 peachtree st nw ste 701
the original linux labs atlanta.ga.us 30303
-since 1995 http://www.linuxlabs.com
office 404.577.7747 fax 404.577.7743
-----------------------------------------------------------------------
From steve at nexpath.com Tue Dec 10 23:10:01 2002
From: steve at nexpath.com (Steve M. Gehlbach)
Date: Tue Dec 10 23:10:01 2002
Subject: VGA and LinuxBios
In-Reply-To: <00cb01c2a0c2$d0bcaa00$437ffea9@hewlett2n8fn74>
Message-ID:
> I've heard of some code that already works with the vt8601 that I'm
> looking to use.
>
> Andy
There should be a way to put the 8601a specific stuff in
northbridge/via/8601a, and try and keep vga generic (legacy) register code
in a central place (eg, pc80/). This worked well for stpc and sis630; most
of the code is common even though the chips are radically different, they
both match well to legacy VGA. There are also changes to lib/video_subr.c
since it currently doesn't move the cursor or use the correct memory address
for text.
The only reason this hasn't been integrated into linuxbios codebase at this
point is partly lack of interest (I think) in this group, since most use the
serial console, and partly that I have been off on other things lately.
All of my projects use the vga console, so as I use various integrated
chipsets, I will be adding vga for each. Until this gets into the linuxbios
base, anyone that wants the code just send me an email. It's all gpl of
course.
-Steve
From rminnich at lanl.gov Tue Dec 10 23:51:01 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Tue Dec 10 23:51:01 2002
Subject: LinuxBIOS and Vxworks
In-Reply-To:
Message-ID:
On Tue, 10 Dec 2002, Kevin Hester wrote:
> It seems to me that most of the current linuxbios ROMs don't setup the PCI
> IRQs - they rely on the fact that linux is able to use the pirq table and do
> it's own PCI IRQ assignment. If you are using vxWorks you may need to make
> sure your mainboard.c is assigning IRQs to all PCI devices.
we're going to have to fix that. I hoped not to do this but too many OSes
either can't do it or get it wrong.
I want to see if we can use that patch of yours.
thanks
ron
From rminnich at lanl.gov Tue Dec 10 23:54:01 2002
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Tue Dec 10 23:54:01 2002
Subject: LinuxBIOS and Vxworks
In-Reply-To: <007701c2a0b5$cec13b10$437ffea9@hewlett2n8fn74>
Message-ID: