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
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
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/
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>
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
Eric,
Did you ever translate the E7501 into C?
Regards
YH
-----邮件原件-----
发件人: ebiederman(a)lnxi.com [mailto:ebiederman@lnxi.com]
发送时间: Wednesday, June 16, 2004 10:25 AM
收件人: ron minnich
抄送: Stefan Reinauer; LinuxBIOS
主题: Re: [PROPOSAL] extended payload handling
ron minnich <rminnich(a)lanl.gov> writes:
> On 14 Jun 2004, Eric W. Biederman wrote:
>
> I'm not so sure I get this 'bloated' discussion. LinuxBIOS is around 32K.
> What's bloat? linuxbios overall is about the size of 'cat'.
Ron can I have you version of romcc?. We have several ports
that are routinely smacking up against the 64K limit during
development. The last E7501 port I did in the freebios1 tree
LinuxBIOS was running about 40K. With romcc inlining everything
we are worse in the freebios2 tree.
As far as bloat baring Stefan's concerns about redundancy between
LinuxBIOS and OpenBIOS (the resource allocation code). Is not so
much about the features we have to day, but more a feeling much more
will be the pebble that starts the avalanche. Or maybe we feel
we have seen the pebble, and we are watching it bounce downhill with
dread.
The bottom line is that to keep size under control you constantly
have to be paying attention to size, just as you have to constantly
watch correctness and performance. The long term trends in the industry
are for very slow romsize growth.
Anyway even at 32K you are twice as big as my cat :)
ls -l /bin/cat
-rwxr-xr-x 1 root root 15000 2003-10-04 17:10 /bin/cat*
Eric
_______________________________________________
Linuxbios mailing list
Linuxbios(a)clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
For Linux based Server, LinuxBIOS would be better than any other commercial
BIOS.
OS has been in GPL, So BIOS should be there too.
Regards
YH
-----邮件原件-----
发件人: Tony Cheng [mailto:tony_cheng@pcmagic.net]
发送时间: Wednesday, June 16, 2004 1:29 PM
收件人: YhLu
抄送: LinuxBIOS
主题: Re: Building Tyan AMD64 s2882 Linux BIOS
Yh,
The source code I've got is coming from CVS, but it's about one or two month
ago. I get the code and did do anything with it until now. I will update the
code and try again.
I will try Redhat 9.0, last time I try it, I saw the version of GCC on
redhat 9.0 is lower than the required version mentioned by LinuxBIOS-AMD64,
Author by Stefan Reinauer
I'm not fully understand the paylod idea yet, but I will do some research on
my side.
I'm really appriciate the response you guys have given to me. I'm starting
to feel much more confident with LinuxBIOS now.
Some people in my company is a little hesitate about the LinuxBIOS as we use
Phoenix BIOS before and afraid of the free Software, I will make a strong
case for them because the good community I saw here.
Tony
----- Original Message -----
From: "YhLu" <YhLu(a)tyan.com>
To: <tony_cheng(a)pcmagic.net>
Cc: "LinuxBIOS" <linuxbios(a)clustermatic.org>
Sent: Wednesday, June 16, 2004 1:06 PM
Subject: 答复: Building Tyan AMD64 s2882 Linux BIOS
> Tony,
>
> Where did you get the source code?
>
> Via CVS or linuxbios snapshot?
>
> The update source code should be compiled no problem under RH 9 for i386.
>
> ROM_SECTION_SIZE should be 128K for fallback.
>
> If you want to boot local
> 1. Etherboot: you can build ide_disk.zelf
> 2. FILO: it can understand file system and kernel + rootfs instead of elf
> format
> 3. FILO_IN_Etherboot: I port the FILO into Etherboot and add boot from
sata
> and it can boot from usb disk too.
>
> Regards
>
> YH
> -----邮件原件-----
> 发件人: root [mailto:tony_cheng@pcmagic.net]
> 发送时间: Wednesday, June 16, 2004 12:58 PM
> 收件人: YhLu
> 抄送: LinuxBIOS
> 主题: Building Tyan AMD64 s2882 Linux BIOS
>
>
> Mr. Yh,
>
> I'm glag to see you here. I saw your name on the LinuxBIOS web site and
> know you are the owner of Tyan AMD64 motherboard.
>
> I'm building the Linux BIOS using your Tyan s2882. The AMD opteron 2
> CPUs system for my comany, we are evaluating Tyan s2882 board for a
> embeded Storage Server. I have some questions maybe you can enlighten
> me.
>
> 1. I get a lot of warning messages from compiler when I build, is that
> normal? I use Suse Linux 9.1, GCC 3.3.3
>
> 2. I only get Fallback BIOS build sucessfully, Normal BIOS will break
> during the build, is that the way it is?
>
> 3. I see your ROM_SECTION_SIZE was set to about 98K, you must have a
> very small payload and use a flash utilty to program the Flash. I set
> the ROM_SECTION_SIZE to 512K, but I'm still have trouble to get a Linux
> Kernel to fit into the Flash. Do you have any recommandation about the
> payload? if you can send your payload "tg3--ide_disk_com1_2.zelf" to me
> just for a testing purpose that will be great!
>
>
> Thanks
>
> Tony
> _______________________________________________
> Linuxbios mailing list
> Linuxbios(a)clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>
