[EMAIL PROTECTED] wrote:
>
> Wrong end of the stick. If you have the EBSA285 in add-in mode, then
> it needs to know the values of the BARs. The EBSA285 does not necessarily
> know if the BARs have been set by the host - only the host knows this, and
> yes, if the host has a driver for it loaded, then it shouldn't change them.
>
> However, at what point does the EBSA285 know in fact that it's been
> correctly configured so it can read the BARs? There is no "initialisation
> complete" bit as there is for the EBSA285 to tell the host it's ready.
There is no explicit bit but one can be implemented easily enough using
the mailbox registers (or doorbell's or some equivalent).
For example:
Host + EBSA both get power.
Host pauses on PCI retries of EBSA
EBSA sets the first mailbox register (offset 0x50?) to 0, no/minimal OS
initialization yet.
EBSA sets PCI ready bit and busy-waits on the mailbox register.
Host continues booting, BIOS and OS scramble the BARs.
Host OS loads driver for the EBSA.
Host EBSA driver writes 0xED (or some other magic byte) into the first
mailbox register.
EBSA sees the mailbox register has the correct magic byte and continues
loading. It can even set the mailbox register back to zero when it is
done to let the host know it has finished loading.
Host and EBSA are both booted and happy with a consistant PCI memory
view from both sides.
Mark's co285 patch uses a variant of this method (in the other
direction) to supply information about the EBSA-285 memory size to the
host. We used a similar trick at CMU to coordinate readiness between
two drivers, one on the host, one on the EBSA.
Oh - and everywhere above that I said EBSA I really meant EBSA-285.
And to butt back into the previous/related topic on HOST/ADD-IN mode, I
tend to agree with Phil here. The add-in mode should be given more
access to the PCI bus. We were able to do it with only a few patches
made to the add-in mode configuration (basically copying a few
memory-mappings and defines from the host mode). As long as the
programmer is smart enough to only have a driver installed on either the
host or the EBSA there shouldn't be a problem.
-Jon
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
