"Eric W. Biederman" wrote:
> There are 4 things that happen with devices:
> 1. Enumeration (So you can find it).
> 2. Resource Allocation (So you can program it)
> 3. Device Initialization (So you can use it)
> 4. Device Untilization (Actually using a device)
>
> What happens and where reponsiblities lie is an interesting question.
> What is clear is that in conjunction with the bootloader and the operation
> system all of these things needs to happen.
>
> Some of them must happen in linuxBIOS or things simply won't work,
> some of them must happen during ram initialization or you can't turn
> on ram. For the rest at a minimum linuxBIOS must provide for them all
> to happen. Think ACPI here as that is the best general interface I
> have seen for this to happen. I would like to avoid the interpreter
> and make a ``light'' ACPI that is totally table driven but the idea
> remains.
>
> Since I currently don't know of a good open source implementation,
> of the general hardware setup problem, achieving 1&2 on all devices.
> As part of the linuxBIOS effort we need to implement something. And
> eventually the linux kernel needs to be updated.
>
> As I see it what we need are a set of tables that act as a blue print
> for the motherboard. Giving how devices are connected. This gives
> the necessary information to setup irq lines and do many other
> interesting things.
>
> Since we must implement general device resource allocation, I would
> like to keep the initial implementation within linuxBIOS proper. Once
> we understand what is needed we can move the code out to other places
> where it belongs. And simply not do it withing linuxBIOS. But
> we shouldn't do this until we understand the problem.
The concept I call stage1 (for the purposes of this e-mail) should do
the absolute minimum required to set the machine up to execute a 32-bit
ELF image. Typically this is CPU and DRAM init, but it might also
involve twiddling the PCI host bridge (which in turn requires some
amount of PCI init). Because enumeration of a set of devices might
depend on initialization of other hardware, you can easily wind up
putting more and more device init code in linuxBIOS, which I think is
wrong. A slippery slope.
For the Alpha firmware console I would like to have, it would need to
have small stub drivers for PCI initalization, an x86 emulator to exec
x86 bios rom code, and similar hardware init duties, in addition to
providing console prompt/boot services. linuxBIOS would act as it
currently does on alpha, simply loading an ELF image -- in this case, my
firmware console instead of the Linux kernel.
So we should ask ourselves, what stuff do we want to allow in stage1?
As I see it, we can take a monolithic approach, which sounds to me like
what you are describing above, or a modular approach.
If we take the monolithic approach, a single linuxbios binary would
contain additional code for further device initialization and
enumeration, building ACPI tables, ...
Or, my preference is the modular approach. I would rather have
linuxBIOS consist of a bootstrap piece (stage1), as described above --
initializing a 32-bit C environment, and loading an ELF image from
flash. This ELF image would perform the rest of the initialization, and
I call this image stage2.
Don't you see how, in the modular approach, stage1 would be coded and
then left relatively untouched during its lifetime? stage2 will be
constantly changing due to new features, coder features, etc. For
example, if we add ACPI table support as you propose, stage1 would
likely not have to be updated much, if at all. Just stage2, the piece
that took over after CPU and DRAM init.
For the modular approach, that would even imply that some of the
existing linuxBIOS code would be split into the stage2 part I describe.
Comments? :)
--
Jeff Garzik | Disbelief, that's why you fail.
Building 1024 |
MandrakeSoft |
