coreboot

coreboot@coreboot.org

10 participants
39711 discussions

Re: Question about AGP
by Dave Ashley 22 Jun '04

22 Jun '04

Regarding the EPIA-M, I've determined more about the situation. The CLE266 comes up with the AGP memory area mapped at 0, but AGP is disabled. The actual memory area is defined by pci device 00.0 memory resource #0 at offset $10 in pci config space. When linuxbios goes to try to assign space for this, it gives up after it decides the resource is read-only. What's happening is the bit to enable AGP (00.0 byte $88 bit 1) if set to 0 causes the upper 4 bits of the longword at $10 to always read back 0. So in order to actually configure that region you need to set the bit to 1. But if you set the bit to 1 and the region is still set to the default value of 0 the system locks up because you're now stepping on RAM. So to initialize agp on epia-m you need to 1) Write some safe value to the memory region at 00.0 offset $10, say $e0000000. It won't read back as $e0000000, it'll still read back as $00000000. 2) Enable 00.0 byte $88 bit 1 (bits go from 0 to 7) 3) Set graphics aperture size to 128 mbytes by writing $80 to 00.0 byte $84. 4) Fall through to normal pci resource allocation I haven't implemented this yet within linuxbios V1 but I will try it out and post again. -Dave

1 0

E7501 support in V2
by YhLu 21 Jun '04

21 Jun '04

Eric, I finish the translate raminit.inc to E7501. But in compiling stage, it used up the regs. In the K8, there is enable_mmx_sse.inc to enable cpu access more regs for romcc. So the problem is 1. Can I use the enable_mmx_sse.inc for Xeon without change? It has MMX and sse too. 2. how about the romcc cpu flag. Or just use -mcpu=k8? Regards YH

1 0

[PROPOSAL] extended payload handling
by Stefan Reinauer 21 Jun '04

21 Jun '04

There has been a similar proposal on this list a while ago, but nothing happened so far, so I want to put this pack to discussion. Objectives ---------- 1.) LinuxBIOS is kind of hard to set up for project newbies, since it does not only require manually tweaking the configuration files for basically every situation, but also necessarily needs an external payload to do anything useful. LinuxBIOS currently sets a high barrier due to the modular concepts it uses. - LinuxBIOS itself is sometimes very sensitive to the build environment. See requirement for setting LANG for example. - For a project outsider it is hard to determine the best payload solution for a specific purpose. There is basically no information except the mailing list archives. - Config files have to be tweaked to explicitly suit the user's directory structure. There is no proposal, nothing that works out of the box. One just _has to_ edit the config files. - LinuxBIOS requires the user to specify a size for the payload instead of determining the required size and doing the needed calculations itself. This is very hand-crufted and can be pretty mind wasting. 2.) LinuxBIOS can currently execute one payload. For greater flexibility and isolated development cycles of the firmware related code parts/projects LinuxBIOS should allow payload chains, ie. executing multiple payloads one after the other. LinuxBIOS wants to keep up it's modularity, letting each module do it's job. This possibility of not doing more than one task should be passed on to the payloads. Solution -------- Feature plugins like "testbios" should not be merged into LinuxBIOS' core code. Instead they should be implemented as a payload. Since we want to load an operating system later on, we also need to be able to load more than one payload. Implementing ELFLOAD in each such plugin is inadequate. Instead LinuxBIOS should execute multiple payloads the same way it executes multiple "drivers" now. * LinuxBIOS therefore needs a way to automatically determine payload sizes when building the image and later when executing payloads. Hardcoding the size values in the config files is inadequate and will lead to unnecessary overhead * LinuxBIOS at runtime needs to go through the list of available payloads, either by having a linked list of payload start points or by scanning the flash rom. * LinuxBIOS should, to be consequent, remove all streaming code except CONFIG_ROM_STREAM * Payloads should have the possibility to add their own enhancements to the LinuxBIOS table. * A least one payload should be "default payload" with the possibility to build this automatically and link it into the image. This is why I checked the "util/extensions" directory into v2 during the last discussion. It should hold possible choices to payloads that can automatically be built and included. Potentially one could add more payloads by symlinking their source tree to this directory to make it available to LinuxBIOS without major reconfiguration. People feel a lot safer with creating a symlink than with changing config files they do not fully understand. Since these can later be executed in row by elfboot, the minimum overhead design of LinuxBIOS itself will not be hurt. At this point I want to put an idea to discussion: If we are going more and more modular and some of us think the current tree is too bloated: Why do we not modularize code like pci resource allocation into a payload as well. My favorite bootloader may already do this and I can't stand this bloat everywhere, you know ;) Even though this may sound funny, I am serious about this issue. I do not see why allocating PCI resources should really be part of the lowlevel code, except for the fact that the NEXT payload in row, potentially Linux itself is too stupid to do that. Bummer. * LinuxBIOS configuration should have an easier mechanism for choosing payloads from the "default" directory, allowing them to be built automatically. Right now I am doing: cd filo-0.4.2 linux32 make CC="gcc -m32" LD="ld -melf_i386" cd .. freebios2/targets/buildtarget amd/solo $PWD/freebios2 cd build-solo make cd .. cp build-solo/solo.rom . My target Config.lb comes with these constructs: target ../../../../build-solo payload ../../filo-0.4.2/filo.elf So I build everything completely out of the freebios2 tree, because building in-tree sucks. The only thing left is to get filo and the other payloads to build out-of-tree as well. Comments? Discussion? Assassination attempts? Stefan

12 40

Question about AGP
by Dave Ashley 19 Jun '04

19 Jun '04

Is the bios supposed to initialize the AGP registers? I'm trying to get AGP working for EPIA-M. I'm wondering if linux itself takes care of everything or whether the bios has to initialize some stuff. -Dave

3 2

RE: Question about AGP
by M. Renee Hopkins 18 Jun '04

18 Jun '04

AGP worked with linuxbios V1 a couple months ago, but didn't seem to go into 4X, but stayed in 1X I believe. Also, I tried IVTV, but linuxbios didn't set the PCI card to 'bus master'. Any tips would be appreciated. I've not tried V2. >From: Dave Ashley <linuxbios(a)xdr.com> >To: linuxbios(a)clustermatic.org >Subject: Question about AGP >Date: Fri, 18 Jun 2004 07:26:40 -0700 > >Is the bios supposed to initialize the AGP registers? > >I'm trying to get AGP working for EPIA-M. I'm wondering if linux itself >takes care of everything or whether the bios has to initialize some stuff. > >-Dave >_______________________________________________ >Linuxbios mailing list >Linuxbios(a)clustermatic.org >http://www.clustermatic.org/mailman/listinfo/linuxbios _________________________________________________________________ Stop worrying about overloading your inbox - get MSN Hotmail Extra Storage! http://join.msn.click-url.com/go/onm00200362ave/direct/01/

1 0

Future support for Nvidia "Crush" CK8-04 (AMD-8111 replacement plus)?
by Ken Fuchs 18 Jun '04

18 Jun '04

Hi, The "Crush" CK8-04 is an interesting AMD-8111 "replacement" that adds PCI Express x20, USB 2.0, SATA-150, GbE, 24-bit 96KHz 7.1 audio to what the AMD-8111 provides (broken USB 2.0): http://www.xbitlabs.com/news/chipsets/display/20040405142953.html Is anyone out there interested in LinuxBIOS support for this chip? What are the prospects of LinuxBIOS supporting this chip? Iwill which has been working with Nvdia on this chip will release its dual Opteron mainboard DK8E based on the CK08-04 in August/Sept: http://www.xbitlabs.com/news/chipsets/display/20040526125019.html Sincerely, Ken Fuchs <kfuchs(a)winternet.com>

3 2

答复: Future support for Nvidia "Crush" CK8-04 (AMD-8111 replacement plus)?
by YhLu 18 Jun '04

18 Jun '04

Don't worry. Maybe before you get the MB, the LinuxBIOS for the chipset is ready, but it's in Tyan MB (S2895). Nvdia has promised to us that it will help us to get it done. Regards YH -----邮件原件----- 发件人: Ken Fuchs [mailto:kfuchs@winternet.com] 发送时间: Thursday, June 17, 2004 4:10 PM 收件人: linuxbios(a)clustermatic.org 主题: Future support for Nvidia "Crush" CK8-04 (AMD-8111 replacement plus)? Hi, The "Crush" CK8-04 is an interesting AMD-8111 "replacement" that adds PCI Express x20, USB 2.0, SATA-150, GbE, 24-bit 96KHz 7.1 audio to what the AMD-8111 provides (broken USB 2.0): http://www.xbitlabs.com/news/chipsets/display/20040405142953.html Is anyone out there interested in LinuxBIOS support for this chip? What are the prospects of LinuxBIOS supporting this chip? Iwill which has been working with Nvdia on this chip will release its dual Opteron mainboard DK8E based on the CK08-04 in August/Sept: http://www.xbitlabs.com/news/chipsets/display/20040526125019.html Sincerely, Ken Fuchs <kfuchs(a)winternet.com> _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

1 0

current available doc
by Wayne Isaacs 17 Jun '04

17 Jun '04

Is there still a DOC in production which plugs directly into the ROM socket? W. Isaacs

3 2

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