Dear LinuxBIOS readers!
This is the automated build check service of LinuxBIOS.
The developer "rsmith" checked in revision 2347 to
the LinuxBIOS source repository and caused the following
add framework for i440bx chipsetadd support for NSC pc87351 SuperIOadd Bitworks/IMS manboard configThis is a very basic framework for the i440bx chipset and theBitworks IMS board that uses it. Most things arestructure only.Known issues:- SMbus reads to the RAM SPD come backall zero.- dump_spd_registers() is commented out since it breaks withthe default setting of generic_dump_spd.c where it wants2 memory controllers.
Configuration of bitworks:ims has been fixed. Compilation of bitworks:ims has been fixed.
If something broke during this checkin please be a pain
in rsmith's neck until the issue is fixed.
If this issue is not fixed within 24h the revision will
be backed out.
LinuxBIOS automatic build system
I fixed up and committed my i440bx mods and the beginnings of support
for the Bitworks IMS board that used this chipset.
Hopefull, someone else can take the time to fix my stupid SPD problem
and we can get this chipset up.
I've not been back to work to test so its compile tested only. They
worked long ago (up to SPD) when I first created them so I'm guessing
they still boot. The nrv2b compression is new since then but since
that works on other boards hopefully it dosen't break things.
The commit also adds support for NSC pc87351 superIO.
If you look at auto.c in mainboard/bitworks/IMS you will see that
dump_spd_registers() and sdram/generic_dump_spd.c are commented out.
That's because generic_dump_spd.c expects to find 2 memory controllers
and 440bx only has one so unless you mod generic_dump_spd.c to only
try one controller the compile will fail. Rather than try to come up
with a fix I just left it as is and you just need to fixup your
install when you use dump_spd_registers() so that generic_dump_spd.c
only does 1 controller. Again someone else feel free to fix this if
it bothers you.
I should be able to fire up my old hardware sometime later on this
week and verify that the image still boots.
Richard A. Smith
I have recently downloaded from the repository, the latest LinuxBios
code. I have compiled this for the via/epia target to use filo as the
I have flashed the bios and everything verifies. However when I try to
boot the system it appears to be dead.
I am monitoring the serial output, but can't see any output. I have also
checked the serial output with a scope with no luck either.
Are there any know problems with the epia 5000 motherboard ?
Is there a known working version in the repository ?
I guess my next step will be to get hold of a POST card, but this will
probably take a few days at best.
Many thanks for any help.
Right now, we use mkelfimage to set up parameter blocks for linux. There
is a lot of code to do this, and I am running out of room on OLPC. I
need to build tiny elf images with on executable code in them (other
than your kernel, of course).
I have modified mkelfimage so that it produces an elfimage with only 3
segments: command line, kernel, initrd. With this option, you can build
a very simple elfimage with just those three things.
There is the issue of setting up %esi for 386 linux. I am considering
the following convention:
architecture-independent part (src/boot/)
For the first PT_LOAD elf segment, assume it is the command line. Set a
variable, command_line, to the load address of this segment.
architecture-dependent, e.g. 386 (src/cpu/boot.c)
set %esi to command_line.
If you are using normal mkelfimage, this is a no-op: esi setting is
ignored. If you are using mkelfimage with my option (e.g. OLPC), this
address will be used as the command line pointer.
I can't see a problem, any comments?
Dear LinuxBIOS community,
after the LinuxBIOS summit in Santa Fe last October was a very good
success, we are looking forward to have a LinuxBIOS summit again this
To make it easier for those who could not attend last year we are
planning to have the summit in Germany.
Topics will roughly cover the development news since last year, the
goals for LinuxBIOS in the future and of course having a good time
We currently have two possible dates. The earlier would be October 1st
to October 3rd. The Later would be somewhen in early December.
Please mail me (private mail) whether you are interested to join the
summit and which date you would prefer (October or December). So we can
do further planning.
Thanks and have a nice weekend,
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info(a)coresystems.de • http://www.coresystems.de/
I have a Fry's fm 7770 http://www.fryssupport.net/fs7770.cfm
That I was going to put linux on anyway. I had been trying to put fedora on for a few installs and it would not boot so I was messing with the bios and now I can not get the monitor to stay on at all and it reboots when I turn it off and it is having alot of problems. All I want is to get that Virus (Windows completely off) fix the bios and get on with a nice long life with linux. Will the linuxbios project work on my pc?
we are working on linux bios for a board of ours and are having
trouble seeing 2 SATA drives when they are identical.
we have tried 2 different sata drives and that works fine, and it also
works fine with the 2 identical drives and factory BIOS.
I ignored this lspci info, because on the chip solded in MB is impress:
What is correct? The name impressed on chip or the info returned by lspci ?
On 7/21/06, Ronald G Minnich <rminnich(a)lanl.gov> wrote:
> it's an 8237, not an 8235 ... doyou have a data book?
| Alan Carvalho de Assis |
Não importa o que os outros irão pensar,
A cura para a infelicidade é a felicidade