> 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
-- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
