[EMAIL PROTECTED] writes:
> 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.
Indeed. There are two different 'architectures' in the kernel (one is sitting
in my incoming patches and is available from Mark van Doesburg) which is the
'intelligent device' mode, and the EBSA285 case which is the stuff thats presently
in my kernels.
> 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.
Indeed, and we make use if that exactly how the other architectures do.
However, when the EBSA285 is being used as a host bridge, it is responsible
for initialising the system and such like.
I'm not over thrilled by the idea of programming the kernel into flash -
this to me is too limited. A better solution would be to have a BIOS-like
loader (MILO or whatever) that pulls the kernel off of whatever medium it
is stored on. This is exactly the point behind my BIOS - to be generic.
> 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.
Indeed.
> 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).
Not necessarily - you still need to get the kernel from somewhere. If you
have a small BIOS programmed into the flash, then that can give you so
many more options than a kernel could ever give you. The BIOS could even
load the kernel from flash if you wanted it to.
I'm not talking here about replacing the EBSA angel loader btw, I'm talking
about supplementing it with a Linux Loader.
Now that 2.2's in the making, things were quietening down (until Linus
released 2.2.2 today), and I was going to clean up the last few bits in
my BIOS to get it out there... There are loads of improvements that could
be made to it as it stands though.
_____
|_____| ------------------------------------------------- ---+---+-
| | 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]
