[LinuxBIOS] VIA EPIA MII 10k stability questions

[Lars Randers]

> 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>