David A Rusling said:
> Russell King - ARM Linux Admin wrote:
> > 1. the kernel cannot possibly know the way the bus needs to be set up
> > in every case.
>
> Well, err, yes it can. The Alpha/MIPs cases work on a huge variety of
> systems. The kernel can know as well as a BIOS how to set up a PCI
> subsystem.
There are currently two implementations of the PCI interrupt fixup in the
kernel as it stands - one for EBSA285 in an EBSA285 backplane, and the other
for the CATS boards. The CATS boards do not use the PCI pin designation
as far as I know, so the two are not mixed.
However, if you have an EBSA285 card plugged into joe bloggs backplane,
how do you discover how it's got the interrupt pins mapped? You shouldn't
autoprobe the IRQs (since PCI isn't supposed to be autoprobed), and there's
nothing you can read to find out about the backplane.
> > 2. a freebios could set up the PCI bus how we wanted it in the first
> > place, while releaving the kernel of the task of knowing system X,
> > Y and Z's peculiarities.
>
> In this case, so long as you implement the PCI BIOS bits - these include
> query callbacks to discover the PCI topology - then this is a perfectly
> valid approach. Its advantage would be that the kernels could remain
> (or become) generic. Of course, you'd still have to port the BIOS but that
> couldn't be harder than porting a kernel.
The PCI BIOS bits are already and have been implemented from the very
start. There is no 'so long as' here - it's an always has been.
> I'm not saying that this is the right approach, but for MILO I embedded
> real Linux device drivers into an environment that was a cut-down Linux
> kernel. The advantage was the enormous set of device drivers, the
> disadvantage was the need to have the code in the kernel in the first
> place. If your BIOS can be simpler then all to the good.
The bios can be simpler, and does not actually require the complexities of
interrupts, process management etc operation at all. In fact, it's probably
better because you could start with a core that is known stable, and get on
with the real job of porting the kernel rather than having to find ways of
loading kernels onto the EBSA285 board.
> Have you seen uHAL?
Yes.
PS, Am I right in saying that the Angel initialisation code does not probe
for the size of the SDRAMs? I didn't notice any change in the setup of the
SDRAMs when I change the SDRAMs fitted.
--
Russell King ([EMAIL PROTECTED])
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
