[LinuxBIOS] VIA EPIA MII 10k stability questions
Lars Randers
lranders at post2.tele.dk
Fri Dec 21 09:22:55 CET 2007
> On Thu, Dec 20, 2007 at 02:52:31PM +0100, Lars Randers wrote:
> > I've been dabbling with this board and the writeups for
> about a week
> > to little avail, so I'd like to hear from anyone who have
> this board
> > running stable with LB, and preferably with VGA enabled.
>
> I have a 6k which was fairly stable with VGA until the
> capacitors blew, but I did not use all features on the board.
>
>
> > I can't seem to build the bios successfully with the
> > Config.vga.filo.lb configs.
>
> Hm, I also seem to recall that the sample config didn't work.
> But I think it was fairly easy to sort out. What errors do
> you encounter?
>
/root/LinuxBIOSv2/src/mainboard/via/epia-m/auto.c -o auto.inc
earlymtrr.c:23.0:
"XIP_ROM_BASE is not a multiple of XIP_ROM_SIZE"
make[1]: *** [auto.inc] Error 1
make[1]: Leaving directory
`/root/LinuxBIOSv2/targets/via/epia-m/epia-m/normal'
make: *** [normal/linuxbios.rom] Error 1
>
> > I have also been investigating spurrious interrupts with
> the CF slot
> > when running Linux (Centos 4.5 - 2.6.9 kernel)
>
> This is a hardware problem with the Ricoh chip.
>
Can the interrupt be disabled BIOS wise or simply safely ignored?
>
> > and the strange LAN lockup, which seems to be related to a
> DMA issue
> > in the southbridge chip.
>
> AFAIK this is also a hardware problem.
>
So it's not possible to make a BIOS fix, workaround, disable DMA
completely?
>
> > Should I just trash the board and look for a more stable platform?
>
> If you have options, that may not be a bad idea.
>
>
> > It's a nice platform, low power and all, but if it's
> hopelessly flawed
> > in design it's out. Any input on the issue welcome!
>
> What other boards are your candidates?
>
Well it's a board I had lying around from an earlier attempt at making
a PVR. I think I had happily forgotten all about my woes with it :)
The current project is for a Trixbox PBX that I want to move out of my
Vmware environment because of sound tearing, how ever I want a diskless
solution as the Vmware server is more than capable of supplying storage
over NFS.
>
> > Furthermore I'm struggeling to get the Linux kernel to boot through
> > the initrd without ending up in a panic. I know it's not a
> LB issue,
> > but as I said, I'd like to get in contact with anyone who has any
> > knowledge into the problem.
>
> I don't like initrds much. As it stands you will need one
> solely for the purpose of resetting the Ricoh chip, but I
> would prefer to hack those few lines of code into FILO
> instead, so that the initrd can be skipped.
>
If we could get some code into FILO or the BIOS to somehow trick
the Linux kernel into thinking it's looking at a genuine IDE port
i.e. find a /dev/hda instead of the Ricoh chip, I'd be thrilled.
That would solve my initrd woes at the same time.
>
> > The wiki is incomplete in this respect and I certainly
> wouldn't mind
> > donating some of my time in return updating it if I could get it
> > working.
>
> Well, you should be able to find other pages about how to
> make an initrd. It will also very greatly with distributions,
> which makes generic advice somewhat difficult to produce.
>
> Why do you want the initrd in the first place? :) Is it some
> other reason than resetcf?
>
Well since the stock kernel is modular built, I need the initrd for
loading
the hardware modules for the pcmcia / yenta as well as the ext3 fs stuff.
The hardest part seems to be getting cardmgr to run from inside the nash
script runner. I'm getting a strange select(): bad file descriptor error
from it.
The funny thing is that if I force nash out into a shell the command
works
from there, it's just a bit selfdefeating to do it that way...
It's frustrating to feel one is so close to making it work but still no
luck.
I have attempted to recompile the stock kernel from source, but after
patching
it up using the CentOS buildenvironment it just fails compilation
miserably.
I have succeeded in compiling the bleeding edge 2.6.23.9 kernel with
root_on_nfs,
but it corrupts the target fs badly, so I'd like to stay with 2.6.9.
>
> //Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071221/a77bc23b/attachment.html>
More information about the coreboot
mailing list