At 04:32 PM 2/23/99 +0000, Russell King - ARM Linux Admin wrote:
>Paul Koning writes:
>> I think the issue is that EBSA285 doesn't HAVE a BIOS.
>
>I do have a BIOS like loader for the EBSA285, but is in dire need of a
>cleanup in certain areas (which I know I must get around to).
>
>> Personally, I wonder about depending on such a notion. There's
>> nothing wrong with having the OS initialization do the entire system
>> init from scratch. At worst that duplicates what a "BIOS" did; at
>> best it's what makes things work.
>
>The PCI initialisation is hardware specific - there is no way to know
>what an EBSA285 is plugged into, and therefore I'd prefer that on this
>machine the kernel did NOT initialise the PCI bus. In fact, my current
>thinking is to reduce some of the initialisation that the kernel does on
>EBSA285.
>
The EBSA-285 is even more complicated than normal as it can run either
as an intelligent device or as the host bridge. Host bridge is the standard
Intel PCI based system case.
There are two parts to the PCI initialisation. The (standard) kernel
uses BIOS callbacks to discover the PCI topology (what devices on
what buses using which addresses in what PCI spaces). In the Alpha/MIPs
cases, there is system specific code that carries out the init functions
normally carried out by Intel BIOS. It's a bit generalised but it
has to be system specific 'cos how PCI land is accessed and how interrupts
are routed is system specific. That's handled by arch/alpha/kernel/bios32.c.
The generic code is in drivers/pci/pci.c and is the same across architectures.
I seem to remember 2.2.1 giving you the ability to completely re-init the
PCI subsystem though.
As for whether or not this code should be in the kernel is an interesting
question. If it is not, then where does it go? How does the kernel
figure out the PCI topology? You could have a bootloader/console that
inits the PCI and hands off the PCI topology information to the kernel.
Given that the PCI system has been configured, the kernel could figure out
the topology itself (via configuration cycles) in a system independent
way.
Without a console, you have to assume that the kernel has to do all of
the work. Most ARM systems do not have consoles. In the Alpha case,
the Miniloader (MILO) uses the kernel PCI setup code and the kernel then
re-inits the PCI subsystem (a little sordid, but it works).
Dave
_____
> |_____| ------------------------------------------------- ---+---+-
> | | Russell King [EMAIL PROTECTED] --- ---
> | | | | http://www.arm.linux.org.uk/~rmk/armlinux.html / / |
> | +-+-+ --- -+-
> / | THE developer of ARM Linux |+| /|\
> / | | | --- |
> +-+-+ ------------------------------------------------- /\\\ |
>unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
>
>
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
