Add initial support for i855gme. This is a work in progress and I
don't expect it to work on all boards, or even any besides mine. This
is based heavily on i855pm.
Signed off by Jon Dufresne <jon.dufresne(a)gmail.com>
Ok, so I've been working on porting the SPD code, and this patch is
what I've got so far. Here are some of the outstanding issues/changes:
* SPD register code (tested using PCI/SMBus Dumps)
I ported the v1 assembly and made some modifications when the numbers
didn't really add up on my machine (particularly the DRB registers)
and added some minor functionality (CAS2/3 detection) that may or may
not work, although based on the results from the dataset I used, it
should work (at least for my current setup).
* PMCR - When should it be updated?
Looking at the assembly, it seems as though it's ok to just set the
final value before the RAM refresh code instead of waiting until
afterwards, but I don't know for sure, so I left the original code
alone. Judging from some of the recent 440bx discussions, it may not
make much of a difference anyway.
* sdram_enable delays
I changed all the RAM timing delays (tRP, tRC, tMRD) to 1usec, since
the timings are on the order of hundreds of nanoseconds (according to
SPD values) and the smallest resolution timer available seems to be
udelay() anyway. It should work for any SDRAM, and shaves a few
milliseconds off previous code.
Incidentally, I noticed that the v1 assembly sets the clock idle value
to 32 in the PGPOL register until SDRAM refresh is enabled, but it
seems like it should eventually be set back to zero (which is what the
patch does). Does it matter?
Anyway, enough verbosity... take a look and see what you think.
Unfortunately, besides testing the SPD code on memory dumps, I haven't
tested the image.
Alfred
> On Wed, Aug 03, 2005 at 11:59:20AM +0900, Jun OKAJIMA wrote:
> > Probably, most guys here use BIOS Saver.
> > And it works well?
> > In mine, RD1 for PLCC gets not being writable suddenly.
> > I mean, it seems writable but # flash_rom -v fails.
> > I solved this problem by a quick hack.
> >
> > How about yours? You can write RD1 or W49F002U well?
> > Any problem happen?
Johnathan McDowell wrote:
> Even after that it's sometimes a bit flakey and I have to erase, then
> write it. I've put the board's original BIOS in the RD1 and am writing
> to the SST 39SF020A instead, which works without problems.
I've read posts about the RD1 that suggest its integrated flash device
is low quality and it may take 10 or more flash attempts to get a good
flash update to the RD1 flash device.
As a result, many RD1 BIOS Savior users will flash the commercial
BIOS image (or other known good BIOS image) into the RD1 integrated
flash device as many times as needed to get an image that boots.
Then use the original BIOS device to flash test BIOS image (usually
LinuxBIOS images among this group), since the original BIOS device
usually flashes OK on the first attempt.
I've used the RD1 in the above fashion with great success on the
Tyan S2885 mainboard.
The same RD1 would not work on the nVidia CK8-04 CRB mainboard.
I think the CK8-04 CRB requires a flash device that the RD1 does
not support. However, the RD1 worked well as an "do nothing" adapter
which allowed swapping the BIOS flash device between my flash burner
and the mainboard without any wear to the mainboard's BIOS socket.
BTW, my flash burner is an older Enhanced Willem Universal Programmer.
I got mine for only $60 US over a year ago. I've seen it for less
than $40 on eBay a few weeks ago. The newest model is going for about
$50 US. It does a LinuxBIOS flash in about 5 minutes; not bad for a
$60 burner. However, it does require changing DIP switches to match
an image for each device it can program. Great for the amateur or
professional with a small budget.
> > BTW, a cable of your RD1 is not broken?
> > I needed soldering to fix it.
> Mine was fine out of the box.
Mine cable and switch worked fine out of the box as well.
Sincerely,
Ken Fuchs <kfuchs(a)winternet.com> ami-mac-sun
Hi,
Attached are dmidecode and lspci -t/n/v output for my system, which has the
same MB as Adrian's.
Since he has the tools, can anyone provide tips on how to get started?
Regards,
David M. Barr
On 19/03/2007 12:06:43 am, Adrian-Ken Rueegsegger wrote:
Hi David,
Thanks for the info! I did find out that all chipsets are supported. I
bought myself a Bios saviour and I have all the other hardware one
needs. I just had little time playing around with it the last two weeks
but I want to start looking into it again, that's why I wanted to ask if
you had made some progress.
I am not quite sure where to start but I found a motherboard [1] that is
quite "similar" to ours: Sun Ultra40. It has the same North- and
Southbridge; SuperIO is different though. Would you know where to go
from here?
Cheers,
Adrian
#40: Decide on common header #ifndef names or standards for usage
-----------------------------+----------------------------------------------
Reporter: uwe | Owner: uwe
Type: enhancement | Status: new
Priority: minor | Milestone: Cosmetic fixes
Component: code | Version: v2
Keywords: | Due_close: MM/DD/YYYY
Include_gantt: 0 | Dependencies:
Due_assign: MM/DD/YYYY | Patchstatus: there is no patch
-----------------------------+----------------------------------------------
We have lots of variations for "include guards" in the code:
{{{
_FOO
_FOO_H
__FOO_H
__FOO_H__
_FOO_H_
__FOO_DEFINED
...
}}}
Is there a special convention or agreement on when to use which? If yes,
it should be documented. If no, we should standardize on one format and
use it consistently.
--
Ticket URL: <http://tracker.linuxbios.org/trac/LinuxBIOS/ticket/40>
LinuxBIOS <http://www.linuxbios.org/>
Jmayes, author of...
"Tivo piggy-back PROM"
"How to build the Tivo PROM piggy socket", and
"Tivo PROM piggy-back socket installation"
...has given explicit permission for these documents to be posted to this list;
for them to be published under the "Creative Commons Attribution-Share Alike
3.0 License" found at http://creativecommons.org/licenses/by-sa/3.0/ ;
and for their contents to be inserted into the LinuxBIOS wiki.
I have temprorarily hosted these documents at...
http://gozelle.com/jmayes/tivo_piggyback_prom.pdfhttp://gozelle.com/jmayes/how_to_build_the_tivo_prom_piggy_socket.pdfhttp://gozelle.com/jmayes/tivo_prom_piggy_back_socket_installation.pdf
...until such time as their useful data is wikified.
Again, none of this is my original work; all I did was ask for permission.
-dhbarr.
---------- Forwarded message ----------
From: Jmayes - Direct
Date: Apr 29, 2007 8:48 PM
Subject: RE: [LinuxBIOS] ECS top hat flash - dual-bios-circuit useable els
ewhere ?
To: "David H. Barr" <dhbarr(a)gozelle.com>
Ok, that sounds fine to me :)
Go ahead and post.
Hope it helps out.
Thankx again,
Jeff
-----Original Message-----
From: David H. Barr [mailto:dhbarr@gozelle.com]
Sent: Sunday, April 29, 2007 9:21 PM
To: Jmayes - Direct
Subject: Re: [LinuxBIOS] ECS top hat flash - dual-bios-circuit useable els
ewhere ?
Jeff,
My gut says to go with the "Creative Commons Attribution-Share Alike 3.0
License", found at
http://creativecommons.org/licenses/by-sa/3.0/
When you break it down this says:
- I want people to be able to use this
- I don't care if they make some money off of it
- I want to be recognized as the original author
- I want people to be able to modify and redistribute this, but only if they
keep this same set of provisions.
A quick note posted directly back to me indicating that it is okay for me to
release your work under this or another specific license of your choice would
be great; that way there's a written understanding.
Basically I intend to simply CC: your 'pdfs to the LinuxBIOS list with the
CreativeCommons license attached and your name mentioned as the original author
and copyright holder, and then put the content in the LinuxBIOS wiki.
Thanks again for your affirmitive response; I just want to make doubly certain
before I use someone else's good work.
Thanks again,
-dhbarr.
On 4/29/07, Jmayes - Direct wrote:
>
>
> HI,
>
> No problem, you can just pick whatever licence you think will do- my
> first guess is the 'Sharealike'. I am not interested in any fame or
> fortune, just glad the info is going to good use.
>
> I finally found a good low-profile socket at digikey- I will try to
> find the info, Almost all of the USA made sockets are too tall (made
> with to much plastic), but most of the china ones are fine.
>
> I have used this trick (piggyback rom) in many widgets, saves huge
> time vs taking the old one off the board, most cases you have to cut
> the enable pin to the original prom but sometimes you can do it
> without any cuts at all.
>
> Just get me some info on your target devices and I can help.
>
> Thankx and goodluck!
> Jeff
>
>
> -----Original Message-----
> From: David H. Barr [mailto:dhbarr@gozelle.com]
> Sent: Sunday, April 29, 2007 5:19 PM
> To: Jmayes - Direct
> Subject: Fwd: [LinuxBIOS] ECS top hat flash - dual-bios-circuit
> useable elsewhere ?
>
>
> Greetings.
>
> I'm with the LinuxBIOS project, and I was wondering if we could get
> permission to license your three documents...
>
> * "How to build the Tivo PROM piggy socket"
> * "Tivo PROM piggy-back socket installation"
> * "Tivo piggy-back PROM"
>
> ...under some sort of open license such as...
> * Free Documentation License
> * Creative Commons License
> * Attribution License
> * Sharealike License
>
> Basically I want to be able to share this data with our other
> developers, but I want to make sure you get credit for sparking me on
> this idea. We're basically doing the same work you did with TiVo's,
> except we do server, desktop, and embedded motherboard BIOS chips.
>
> Let me know what I'd need to do to make this happen. I think the
> easiest method for -our- purposes would be permission to copy the data
> and pictures out of your PDFs and into the LinuxBIOS wiki. I can
> guarantee your name and URL would be included, and like I mentioned
> any open license that allows people to update, correct, etc. the
> original would be awesome.
>
> Anyhoo, I've wasted enough of your time. Thanks for taking the time
> to read this.
>
> -dhbarr.
>
> PS: Attached is the conversation on-list that sparked all this.
>
>
> On 4/29/07, Peter Stuge <stuge-linuxbios(a)cdy.org> wrote:
> > On Sun, Apr 29, 2007 at 01:38:44PM -0500, David H. Barr wrote:
> > > > I'd love to find out more about exactly how this is done.
> > >
> > > Probably a lot like the TiVo PROM back-to-back socket. Basically
> > > two plcc32 sockets soldered back to back with a few pin tweaks.
> >
> > Yes, with "a lot like" and "a few tweaks" being the gaps I'd like to
> > fill. :p
> >
> >
> > > Yet another variation on dead-roaching or piggy-backing a chip.
> > >
> > > "tivo prom piggy" should get you there as a search query.
> >
> > Not really with a lot of detail unless I registered at the DDB
> > forum. Oh how I hate forums.
> >
> > Anyway, at least one of the posts indicated that a trace needs to be
> > cut, and one wire needs to be soldered. This solves the problem I'm
> > interested in, but I'm only interested in ways to accomplish the
> > same thing completely without soldering.
> >
> >
> > > I've occasionally wondered how hard it would be to have something
> > > like this manufactured, thereby bypassing the whole TopHat /
> > > BIOSSavior vendor specific issue.
> >
> > The BIOS savior is very generic. Some issues may come from the
> > choice of flash chip inside it, but there would probably be issues
> > on other boards with another chip if that's the actual cause of the
> > reported problems.
> >
> > TopHat I don't know about. I'm interested in Quux' findings! :)
> >
> >
> > On Sun, Apr 29, 2007 at 09:44:43PM +0200, Quux wrote:
> > > the tivo socket has no circuitry at all.
> >
> > Really? Is there a schematic somewhere?
Dear all,
I am wondering if it would be possible to run LinuxBios on a braille
device. Regarded from a Linux point of view, such a device is very
similar to a PC or a laptop, as you will certainly notice according to
the datas provided below.
If the device is supported, the idea would be to install a screen-reader
(like brltty) in the BIOS, which would help when there is a problem
while booting the operating system's kernel.
So below are the outputs of lspci -n, lspci -v and lspci -t run on
the terminal. Could someone please tell me whether there is a possibility
or not to install LinuxBios on such a machine ?
Thanks a lot in advance for your help,
Sébastien.
# lspci -n
00:00.0 0600: 1078:0001
00:02.0 0200: 1282:9102 (rev 40)
00:12.0 0601: 1078:0100 (rev 30)
00:12.1 0680: 1078:0101
00:12.2 0101: 1078:0102
00:12.3 0401: 1078:0103
00:12.4 0300: 1078:0104
00:13.0 0c03: 0e11:a0f8 (rev 06)
# lspci -v
00:00.0 Host bridge: Cyrix Corporation PCI Master
Flags: bus master, medium devsel, latency 0
00:02.0 Ethernet controller: Davicom Semiconductor, Inc. 21x4x DEC-Tulip compatible 10/100 Ethernet (rev 40)
Subsystem: Davicom Semiconductor, Inc. Unknown device 8212
Flags: bus master, medium devsel, latency 165, IRQ 11
I/O ports at 1000 [size=256]
Memory at fedfe000 (32-bit, non-prefetchable) [size=256]
[virtual] Expansion ROM at 10000000 [disabled] [size=256K]
Capabilities: [50] Power Management version 2
00:12.0 ISA bridge: Cyrix Corporation 5530 Legacy [Kahlua] (rev 30)
Flags: bus master, medium devsel, latency 64
00:12.1 Bridge: Cyrix Corporation 5530 SMI [Kahlua]
Flags: medium devsel
Memory at 40012000 (32-bit, non-prefetchable) [size=256]
00:12.2 IDE interface: Cyrix Corporation 5530 IDE [Kahlua] (prog-if 80 [Master])
Flags: bus master, medium devsel, latency 0
I/O ports at 1400 [size=16]
00:12.3 Multimedia audio controller: Cyrix Corporation 5530 Audio [Kahlua]
Flags: bus master, medium devsel, latency 0
Memory at 40011000 (32-bit, non-prefetchable) [size=128]
00:12.4 VGA compatible controller: Cyrix Corporation 5530 Video [Kahlua] (prog-if 00 [VGA])
Subsystem: Cyrix Corporation Unknown device 0001
Flags: medium devsel
Memory at 40800000 (32-bit, non-prefetchable) [size=8M]
00:13.0 USB Controller: Compaq Computer Corporation ZFMicro Chipset USB (rev 06) (prog-if 10 [OHCI])
Subsystem: Compaq Computer Corporation ZFMicro Chipset USB
Flags: bus master, medium devsel, latency 64, IRQ 9
Memory at 000e0000 (32-bit, non-prefetchable) [size=4K]
# lspci -t
-[0000:00]-+-00.0
+-02.0
+-12.0
+-12.1
+-12.2
+-12.3
+-12.4
\-13.0
Hi all
There has been a bug in the EPIA build which at some point stopped FILO
being able to boot
from an IDE drive. After much digging I have found the problem and have
changed the following
two files.
LinuxBIOSv2/src/mainboard/via/epia/auto.c
LinuxBIOSv2/src/southbridge/via/vt8231/vt8231_ide.c
I have also changed the default COM speed from 19200 to 115200. This is
a personal thing but
every time I update LB I forget to change it back. Leave it out if you wish.
LinuxBIOSv2/src/mainboard/via/epia/Options.lb
I have attached a patch file. Can someone please see about checking &
adding the fixes to the repository.
There is still an issue with the board sometimes hanging on boot. So I
would not class this as fully working just yet.
Regards
Ben Hewson
Index: /home/ben/sw/LinuxBIOSv2/src/mainboard/via/epia/auto.c
===================================================================
--- /home/ben/sw/LinuxBIOSv2/src/mainboard/via/epia/auto.c (revision 2621)
+++ /home/ben/sw/LinuxBIOSv2/src/mainboard/via/epia/auto.c (working copy)
@@ -66,8 +66,16 @@
/* we do this here as in V2, we can not yet do raw operations
* to pci!
*/
- dev += 0x100; /* ICKY */
-
+
+ /* changed this to work correctly on later revisions of LB.
+ * The original dev += 0x100; stopped working. It also appears
+ * that if this is not set here, but in ide_init() only, the IDE
+ * does not work at all. I assume it needs to be set before something else,
+ * possibly before enabling the IDE peripheral, or it is a timing issue.
+ * Ben Hewson 29 Apr 2007.
+ */
+
+ dev = pci_locate_device(PCI_ID(0x1106,0x0571), 0);
pci_write_config8(dev, 0x42, 0);
}
Index: /home/ben/sw/LinuxBIOSv2/src/southbridge/via/vt8231/vt8231_ide.c
===================================================================
--- /home/ben/sw/LinuxBIOSv2/src/southbridge/via/vt8231/vt8231_ide.c (revision 2621)
+++ /home/ben/sw/LinuxBIOSv2/src/southbridge/via/vt8231/vt8231_ide.c (working copy)
@@ -15,6 +15,12 @@
// Run the IDE controller in 'compatiblity mode - i.e. don't use PCI
// interrupts. Using PCI ints confuses linux for some reason.
+ /* Setting reg 0x42 here does not work. It is set in mainboard/auto.c
+ * It probably can only be changed while the IDE is disabled
+ * or it is possibly a timing issue. Ben Hewson29 Apr 2007.
+ */
+
+ /*
printk_info("%s: enabling compatibility IDE addresses\n", __FUNCTION__);
enables = pci_read_config8(dev, 0x42);
printk_debug("enables in reg 0x42 0x%x\n", enables);
@@ -22,6 +28,8 @@
pci_write_config8(dev, 0x42, enables);
enables = pci_read_config8(dev, 0x42);
printk_debug("enables in reg 0x42 read back as 0x%x\n", enables);
+ */
+
}
enables = pci_read_config8(dev, 0x40);
Index: /home/ben/sw/LinuxBIOSv2/src/mainboard/via/epia/Options.lb
===================================================================
--- /home/ben/sw/LinuxBIOSv2/src/mainboard/via/epia/Options.lb (revision 2621)
+++ /home/ben/sw/LinuxBIOSv2/src/mainboard/via/epia/Options.lb (working copy)
@@ -51,7 +51,7 @@
default CONFIG_CONSOLE_SERIAL8250=1
## Select the serial console baud rate
-default TTYS0_BAUD=19200
+default TTYS0_BAUD=115200
# Select the serial console base port
default TTYS0_BASE=0x3f8
