coreboot

coreboot@coreboot.org

12 participants
39779 discussions

K7SEM support broken in freebios?
by Thomas Wehrspann 09 Aug '03

09 Aug '03

Hello, is seems that the support for the ecs k7sem got broken. When i use the current CVS copiling is no problem, but when i boot linuxbios stops before the mtrr stuff with "Enabling cache...". I followed the procedure in the howto and used the serial console (no debug). The CVS version from 2003-04-01 works, the one from 2003-05-01 works not. Thomas

4 7

Re: Supporting extension ROMs and beyond...
by YhLu 09 Aug '03

09 Aug '03

Ron, Where is the VGA BIOS support? Still in freebios? YH -----邮件原件----- 发件人: ron minnich [mailto:rminnich@lanl.gov] 发送时间: 2003年8月8日 12:42 收件人: SONE Takeshi 抄送: linuxbios(a)clustermatic.org 主题: Re: Supporting extension ROMs and beyond... On Sat, 9 Aug 2003, SONE Takeshi wrote: > Then it's convenient to have a few more INTs and generic PCI ROM > enabling routine to enable the SCSI adapter. That code would be > simple and small anyway. It doesn't bother me. I am fine with it. I believe that the VGA BIOS support can be used for this as well, with very little extra work. > Then, at this point, why not adding a simple code to load IPL and > jumping it in real mode? It's smaller than a printk. Sure. Eric is concerned that it not be in the "core". I am willing to call it a compiled-in extension if everyone is ok with that. We could have a src/extensions directory, and put items such as the VGA BIOS support etc. in there. Such extensions have to be explicitly enabled. The static device mechanism gives us an easy way to hook into them. But for reasons of space at least, I would really like to keep the ability to compile VGA BIOS support directly into linuxbios. The ELF chaining that Adam mentioned, while interesting, is complex enough to worry me. Takeshi did I apply your last patch to VGA BIOS support? Can you check? thanks ron _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

4 3

DoC on EPIA-M with DIP2PLCC adapter -- instead of 256kbyte bios chip
by Niki Waibel 09 Aug '03

09 Aug '03

hi, my plan is still to use a DoC 2000 on an EPIA-M mobo with a DIP2PLCC adapter -- instead of the original 256kbyte (PLCC) bios chip. can anyone tell me if this is theoretically possible? niki

3 5

Re: Datasheets for EPIA-M10000
by Dave Ashley 08 Aug '03

08 Aug '03

>Can anyone help with info on VIA CLE266, VT8235, VT6103, VT1616, VT1662, VT6307S, anything would be appreciated .... or have people just used the linux kernel source for their information??? >James. VIA doesn't give out datasheets easily, for the most part they are available only under NDA, probably so they don't have to be fighting the US patent insanity all the time. Look at viarena.com, more information is there, and try to convince VIA reps you're a serious developer. Contrast that with this page: http://www.national.com/pf/SC/SC1200.html Anyone can anonymously download the geode SC1200 datasheet without any hassle at all, and the doc is accurate and complete. Sometimes VIA's datasheets raise more questions than they answer... -Dave

1 0

A lesson from Plan 9
by ron minnich 08 Aug '03

08 Aug '03

Eric's comments on the keeping the core clean bring Plan 9 to mind, especially as Plan 9 was the inspiration for both the original and new config tools. Plan 9 is broken into two trees, as follows. /sys/src/9/port /sys/src/9/<architecture> The 'port' code is that code which is non-platform-specific. The <architecture> code is of course platform-specific. You can actually think of 'port' as the "core", and the other tree as the specialization to a given platform. To a large degree, platform-specific code gets linked in statically as devices, defined in arrays of structures. These are accessed via indirection through structures. The platform code can of course make calls to the OS for services. I think this is what many people I talk to would like for linuxbios: the ability to specialize the bios for specific platforms, e.g. x86 mainboards with VGA or other ROMs, to allow card initialization (e.g. rom bios). Obviously this brings a degree of x86-specificity to that build of the bios, but I think we can keep it isolated from the core. I feel this specialization could be done in a clean way: /src/freebios/src/extensions/.... and with a new keyword in the config tool that makes the nature of the extension clear. We need somehow to address the demand for very early VGA support in linuxbios. It's probably the highest-demand item right now. ron

1 0

TigerMPX no dice - please help
by Jeff Noxon 08 Aug '03

08 Aug '03

Howdy, I've been playing around with the CVS tree trying to get the TigerMPX stuff to compile. At first I got assembler warnings because AMD768_DEV was not defined. I found that AMD766_DEV was defined, so I changed it. That got a little further. It was set to 0x3800 yet my lspci -vvv shows my PCI bridge at 0x2000. Is that because the Tyan BIOS moved it? Then I got a compile failure on the ide code. It tries to include <ide.h> which doesn't exist. I #if 0'd around this because I use a different controller anyway. That got further along. Then, after all the 768 stuff compiled, I got link failures as it was trying to link amd766 functions instead of the 768 functions. This all leads me to believe that the code in CVS is not really functional to begin with. Either that, or I am doing something really stupid, which is entirely possible. ;) Is there newer code that someone can send me, and/or commit to CVS? Last but not least, Sourceforge seems to be having a lot of CVS problems. It is slow when it works, but it doesn't work much of the time I try to use it. I haven't been able to update in a few days, it just drops my connections. Thanks & Regards, Jeff

2 1

Slowly merging the static and dynamic device trees.
by ebiederman＠lnxi.com 08 Aug '03

08 Aug '03

So at first glance the static device tree seems to be pretty usable so now I am investigating what needs to happen to merge the device trees. There is one large area of mismatch though that I don't know if I want to do something about or not. Currently the static device tree is by chip. And the dynamic tree is by logical device. Where this becomes challenging is on chips like the 8131 or the 8111 which have multiple busses hanging off of them. Or even for the simple amdk8 processor which has 3 HT links hanging off of it. And I don't want to mix the children of various busses. For the arima/hdama my static device tree currently like: cpu k8 "cpu0" register "up" = "{.chip = &amd8131, .ht_width=16, .ht_speed=600}" southbridge amd/amd8131 "amd8131" end southbridge amd/amd8111 "amd8111" superio NSC/pc87360 register "com1" = "{1}" register "lpt" = "{1}" end end end cpu k8 "cpu1" end Now that I have something to start with I am busily brainstorming how to glue all this together and make it work. The new configuration tool seems to be doing a good job so far. Eric

2 1

Flash chip identified in BIOS Savior PMC4
by Jeff Noxon 08 Aug '03

08 Aug '03

To answer one of my own questions - The flash chip in the Bios Savior RD1-PMC4 is the PMC Pm49FL004. (Manufacturer ID: 0=0x9D, 2=0x7F; Device ID 1=0x6E) http://www.pmcflash.com/resource_center/docs/Pm49FL002%2D004%2D008%20V1%2E1… Regards, Jeff

1 0

Using USB Flash drives instead of CF
by Luis Pacheco 08 Aug '03

08 Aug '03

Hello, I think this link can help you: http://www.8ung.at/spblinux/concept.htm#usb There is an part about usb storage media and linux kernel... -- Luis André Pacheco http://www.neuralbit.com

1 0

List Problem
by James Weir 08 Aug '03

08 Aug '03

Can someone help, I keep getting two of every message? Is anyone else having this problem, Thanks, James.

5 7

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot