Interrupt routing in prep_pci.c

Interrupt routing in prep_pci.c

[Jeremy Fitzhardinge]

Hi Cort/all,

I'm trying to work out what kernel/prep_pci.c is doing with interrupt routing. 
I'm looking at the stuff in the standard 2.2 kernel, so perhaps there's a better
place for me to look.

Firstly, in route_pci_interrupts it does an inb(0x800) to get something to
determine the interrupt architecture of the board.  What is this value, and
where does it come from?

Rather than having hard-coded tables, can't the interrupt routing be determined
from either firmware or the interrupt controller itself?  The comment at the
top of the file is that this will go away soon.  What are you planning to
replace it?

Background: I'm porting LinuxPPC to a Yellowknife-like board running Open
Firmware.  It works well except that the drivers can't find their interrupts.

Thanks,
        J

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Interrupt routing in prep_pci.c

[Gabriel Paubert]

On Wed, 10 Feb 1999, Jeremy Fitzhardinge wrote:

> 
> Hi Cort/all,
> 
> I'm trying to work out what kernel/prep_pci.c is doing with interrupt routing. 
> I'm looking at the stuff in the standard 2.2 kernel, so perhaps there's a better
> place for me to look.
> 
> Firstly, in route_pci_interrupts it does an inb(0x800) to get something to
> determine the interrupt architecture of the board.  What is this value, and
> where does it come from?

It's a value which give sthe board type on rather old IBM/Motorola boards.

> Rather than having hard-coded tables, can't the interrupt routing be determined
> from either firmware or the interrupt controller itself?  The comment at the
> top of the file is that this will go away soon.  What are you planning to
> replace it?

Indeed, that's what I do from residual data on PreP machines and it seems
to work on several kinds of boards. You'll find it embedded somewhere
in the patch file at:

	ftp://vcorr1.iram.es/pub/linux-2.2/mvm2600.generic-patch-2.2.1

> Background: I'm porting LinuxPPC to a Yellowknife-like board running Open
> Firmware.  It works well except that the drivers can't find their interrupts.

Note that this patch includes a new bootloader for PreP machines, I'd like
to extend it to support OF too but don't have te time right now.

	Gabriel.


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Interrupt routing in prep_pci.c

[Troy Benjegerdes]

You may also find my patches for MTX SMP support usefull. It contains most
of the stuff in Geert's patches, with the addition that most all of the
architecture-dependent functions have been redone to be dispatched by a
structure of function pointers. (Thanks to Corey Minyard) This gets rid of
a great number of case statements, and what could be the framework for a
good cleaning up of the arch/ppc/kernel directory. I suspect it might make
porting to a yellowknife like board easier. If the yellowknife board
supports SMP and has an OpenPIC, my SMP patches might work also ;)

They can be found at:

	ftp://linuxppc.cs.nmt.edu/pub/linuxppc/patches/mtx-smp/
	ftp://ftp.microux.com/pub/linux/

(The latest is agains 2.2.0-pre9.. I need to update it ;)

On Thu, 11 Feb 1999, Gabriel Paubert wrote:

> 
> 
> 
> On Wed, 10 Feb 1999, Jeremy Fitzhardinge wrote:
> 
> > 
> > Hi Cort/all,
> > 
> > I'm trying to work out what kernel/prep_pci.c is doing with interrupt routing. 
> > I'm looking at the stuff in the standard 2.2 kernel, so perhaps there's a better
> > place for me to look.
> > 
> > Firstly, in route_pci_interrupts it does an inb(0x800) to get something to
> > determine the interrupt architecture of the board.  What is this value, and
> > where does it come from?
> 
> It's a value which give sthe board type on rather old IBM/Motorola boards.
> 
> > Rather than having hard-coded tables, can't the interrupt routing be determined
> > from either firmware or the interrupt controller itself?  The comment at the
> > top of the file is that this will go away soon.  What are you planning to
> > replace it?
> 
> Indeed, that's what I do from residual data on PreP machines and it seems
> to work on several kinds of boards. You'll find it embedded somewhere
> in the patch file at:
> 
> 	ftp://vcorr1.iram.es/pub/linux-2.2/mvm2600.generic-patch-2.2.1
> 
> > Background: I'm porting LinuxPPC to a Yellowknife-like board running Open
> > Firmware.  It works well except that the drivers can't find their interrupts.
> 
> Note that this patch includes a new bootloader for PreP machines, I'd like
> to extend it to support OF too but don't have te time right now.
> 
> 	Gabriel.
> 
> 
> 

--------------------------------------------------------------------------
| Troy Benjegerdes    |       troy@microux.com     |    hozer@drgw.net   |
|    Unix is user friendly... You just have to be friendly to it first.  |
| This message composed with 100% free software.    http://www.gnu.org   |
--------------------------------------------------------------------------


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Interrupt routing in prep_pci.c

[Jeremy Fitzhardinge]

On 14-Feb-99 Troy Benjegerdes wrote:
> You may also find my patches for MTX SMP support usefull. It contains most
> of the stuff in Geert's patches, with the addition that most all of the
> architecture-dependent functions have been redone to be dispatched by a
> structure of function pointers. (Thanks to Corey Minyard) This gets rid of
> a great number of case statements, and what could be the framework for a
> good cleaning up of the arch/ppc/kernel directory. I suspect it might make
> porting to a yellowknife like board easier. If the yellowknife board
> supports SMP and has an OpenPIC, my SMP patches might work also ;)

Thanks a lot - this should be very helpful.  BTW, how much work has been put
into using Open Firmware callbacks rather than blowing OFW away (I guess that's
more of a CHRP rather than PReP or MTX question)?

        J

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Interrupt routing in prep_pci.c

[Gabriel Paubert]

On Sun, 14 Feb 1999, Jeremy Fitzhardinge wrote:

> Thanks a lot - this should be very helpful.  BTW, how much work has been put
> into using Open Firmware callbacks rather than blowing OFW away (I guess that's
> more of a CHRP rather than PReP or MTX question)?

Not very much I think, and the boards I have with OF do not implement
RTAS, which makes blowing away OF the only viable solution.

	Gabriel.



[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Interrupt routing in prep_pci.c

[Gabriel Paubert]

On Sat, 13 Feb 1999, Troy Benjegerdes wrote:

> You may also find my patches for MTX SMP support usefull. It contains most
> of the stuff in Geert's patches, with the addition that most all of the
> architecture-dependent functions have been redone to be dispatched by a
> structure of function pointers. (Thanks to Corey Minyard) This gets rid of
> a great number of case statements, and what could be the framework for a
> good cleaning up of the arch/ppc/kernel directory. I suspect it might make
> porting to a yellowknife like board easier. If the yellowknife board
> supports SMP and has an OpenPIC, my SMP patches might work also ;)

I forgot to tell that my patch includes all of the preceding plus some
updates to the prepboot code.

	Gabriel. 


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Interrupt routing in prep_pci.c

[Johnnie Peters]

Hi Gabriel

I would like to try your stuff out but I have not been able to get to your site.  Do
you have it anywhere else I can retrieve it from?

I tried a version of it a while back and it did not seem to compile with the standard
R4 compiler.  At that time I tried to compile and use the latest egcs and binutils
stuff and it seemed to work for the kernel but when I tried compiling user level
stuff it gave me several problems.  I have asked several people on the net and have
not got a good answer as to what compiler I should be using with R4.  Can you tell me
the combination you are using?

Thanks for your time,

Johnnie


Gabriel Paubert wrote:

> On Wed, 10 Feb 1999, Jeremy Fitzhardinge wrote:
>
> >
> > Hi Cort/all,
> >
> > I'm trying to work out what kernel/prep_pci.c is doing with interrupt routing.
> > I'm looking at the stuff in the standard 2.2 kernel, so perhaps there's a better
> > place for me to look.
> >
> > Firstly, in route_pci_interrupts it does an inb(0x800) to get something to
> > determine the interrupt architecture of the board.  What is this value, and
> > where does it come from?
>
> It's a value which give sthe board type on rather old IBM/Motorola boards.
>
> > Rather than having hard-coded tables, can't the interrupt routing be determined
> > from either firmware or the interrupt controller itself?  The comment at the
> > top of the file is that this will go away soon.  What are you planning to
> > replace it?
>
> Indeed, that's what I do from residual data on PreP machines and it seems
> to work on several kinds of boards. You'll find it embedded somewhere
> in the patch file at:
>
>         ftp://vcorr1.iram.es/pub/linux-2.2/mvm2600.generic-patch-2.2.1
>
> > Background: I'm porting LinuxPPC to a Yellowknife-like board running Open
> > Firmware.  It works well except that the drivers can't find their interrupts.
>
> Note that this patch includes a new bootloader for PreP machines, I'd like
> to extend it to support OF too but don't have te time right now.
>
>         Gabriel.




[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Interrupt routing in prep_pci.c

[Cort Dougan]

It doesn't work many of the boards I have.  The residual data isn't
always there and isn't always right when it is there.  The comment about
it going away soon was referring to the code to use residual data - but it
turns out that we can't always depend on it.  I still don't like the way
we do it, though.

}> > Rather than having hard-coded tables, can't the interrupt routing be determined
}> > from either firmware or the interrupt controller itself?  The comment at the
}> > top of the file is that this will go away soon.  What are you planning to
}> > replace it?
}>
}> Indeed, that's what I do from residual data on PreP machines and it seems
}> to work on several kinds of boards. You'll find it embedded somewhere
}> in the patch file at:


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Interrupt routing in prep_pci.c

[VALETTE Eric]

>>>>> "Cort" == Cort Dougan <cort@persephone.cs.nmt.edu> writes:

Cort> It doesn't work many of the boards I have.  The residual data isn't
Cort> always there and isn't always right when it is there.  The comment about
Cort> it going away soon was referring to the code to use residual data - but it
Cort> turns out that we can't always depend on it.  I still don't like the way
Cort> we do it, though.

> Rather than having hard-coded tables, can't the interrupt routing be determined
> from either firmware or the interrupt controller itself?  The comment at the
> top of the file is that this will go away soon.  What are you planning to
> }> > replace it?
> }>
> }> Indeed, that's what I do from residual data on PreP machines and it seems
> to work on several kinds of boards. You'll find it embedded somewhere
> in the patch file at:


OK but with the current code :

   1) you scew up the value that may have been correctly set for PCI devices,
   BY ANY KIND OF FIRMWARE (PPCBUG, ...),
   2) You force epople to write a config for each board,
   3) you assume old 105, 106 PCI interrupt routing scheme that makes nothing
   on newer chips like raven,

Of course, residual does not provide anything but firmware may program
correctly the harware and interrupt routing. So I really believes
that
	1) we should know wether the board firmware correctly
	set up the PCI devices. If this is the case, the old
	interrupt scheme must be removed. Note that this
	implies to have a better scheme for identifying board than the
	inb (0x800) currently used.
	2) If we have residual, we may override some value by the
	value provided by the residual,
	3) If an openpic compliant interrupt controller is
	there we should use it.

My 2 cents,


-- 
   __                 
  /  `                   	Eric Valette
 /--   __  o _.          	Canon CRF
(___, / (_(_(__         	Rue de la touche lambert
				35517 Cesson-Sevigne  Cedex
				FRANCE
Tel: +33 (0)2 99 87 68 91	Fax: +33 (0)2 99 84 11 30
E-mail: valette@crf.canon.fr

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Interrupt routing in prep_pci.c

[Cort Dougan]

Before you get too grumpy please realize I don't have any of the newer
boards.  I only have the "old interrupt" routing scheme boards to work
with first hand.  If someone wants to get to me 1) the newer boards or 2)
some code that handles both well I'd be more than happy to redo the
routing.  prep_pci.c has been a nasty piece of code for some time.

}OK but with the current code :
}
}   1) you scew up the value that may have been correctly set for PCI devices,
}   BY ANY KIND OF FIRMWARE (PPCBUG, ...),
}   2) You force epople to write a config for each board,
}   3) you assume old 105, 106 PCI interrupt routing scheme that makes nothing
}   on newer chips like raven,

That's right, we should keep the setup if it's correct.  Find me a better
scheme for identifying the board, then.

}	1) we should know wether the board firmware correctly
}	set up the PCI devices. If this is the case, the old
}	interrupt scheme must be removed. Note that this
}	implies to have a better scheme for identifying board than the
}	inb (0x800) currently used.


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Interrupt routing in prep_pci.c

[VALETTE Eric]

>>>>> "Cort" == Cort Dougan <cort@persephone.cs.nmt.edu> writes:


eric>OK but with the current code :
eric>
eric>   1) you scew up the value that may have been correctly set for PCI devices,
eric>   BY ANY KIND OF FIRMWARE (PPCBUG, ...),
eric>   2) You force epople to write a config for each board,
eric>   3) you assume old 105, 106 PCI interrupt routing scheme that makes nothing
eric>   on newer chips like raven,

Cort> Before you get too grumpy please realize I don't have any of the newer
Cort> boards.  I only have the "old interrupt" routing scheme boards to work
Cort> with first hand.  If someone wants to get to me 1) the newer boards or 2)
Cort> some code that handles both well I'd be more than happy to redo the
Cort> routing.  prep_pci.c has been a nasty piece of code for some time.

You can detect the raven. Gabriel has code for this for weeks...
You can detect you are on a motorola board also. Those two leads to 
have ppcbug and a valid PCI configuration. If furthermore, you
decide to use the openpic feature provided by the raven, then
you can translate the value. I have code working (mostly Gabriel code
+ some patches).

Besides I would like you to point out boards were PCI configuration
registers are wrong as they are initialized on reset... I think
those board are not PCI 2.x compliant and probably you can't even buy
them anymore...

In any case, if code for old boards is a mess but still needed for
many good reasons, then put it under a config variable and at least 
let clean code exist for newer boards that may work for any 
recent/upcoming board...

CONFIG_RESIDUAL Comes in mind
CONFIG_PCI_CONFIG_ON_RESET_OK also
CONFIG_OPEN_PIC also...

If you mange to have table for indirect calls this is evn better :)

eric>	1) we should know wether the board firmware correctly
eric>	set up the PCI devices. If this is the case, the old
eric>	interrupt scheme must be removed. Note that this
eric>	implies to have a better scheme for identifying board than the
eric>	inb (0x800) currently used.

Cort> That's right, we should keep the setup if it's correct.  Find me a better
Cort> scheme for identifying the board, then.

For motorola, use the sytem configuration register at physaddr 0xfef80400 for
example. I do not know all the boards but probably someone at motorola could 
make suggestions as I bet PPCBUG has code to make it :)

I think  correct board dentification is a key point for code
portability/autoconfiguration. Not working on this item will
prevent any good restructuration as adding code for one board will
break another...



-- 
   __                 
  /  `                   	Eric Valette
 /--   __  o _.          	Canon CRF
(___, / (_(_(__         	Rue de la touche lambert
				35517 Cesson-Sevigne  Cedex
				FRANCE
Tel: +33 (0)2 99 87 68 91	Fax: +33 (0)2 99 84 11 30
E-mail: valette@crf.canon.fr

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Interrupt routing in prep_pci.c

[Cort Dougan]

It's not as simple as you suggest.  Code it up so that it works on all
the boards around and I'll be quite happy to take it :)  The problem
I'm having now is code that works on one set doesn't work on others.

I don't want to break the kernel for older boards just because you can't
buy them anymore.  That's not a reason to ignore them.


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Interrupt routing in prep_pci.c

[VALETTE Eric]

>>>>> "Cort" == Cort Dougan <cort@persephone.cs.nmt.edu> writes:

Cort> It's not as simple as you suggest.  

You haven't even tried. Did you try Gabriel patches?

Cort Code it up so that it works on all
Cort> the boards around and I'll be quite happy to take it :)  The problem
Cort> I'm having now is code that works on one set doesn't work on others.

That's your choice. Provided you do not ask me to agree and do not
ask for support of your way of handling patches...

-- eric

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Interrupt routing in prep_pci.c

[Johnnie Peters]

I've been trying to stay out of this discussion because I was pretty sure it
would
take on the tone of religous conviction but here is my two cents worth.

I have tried Gabriels patches.  I used his boot loader stuff with my own
Raven changes
and for some of our boards it worked great (namely the VME boards).  However
it did
not work for everything.  Since I work exclusively with Motorola machines and
have
several different ones here, I would very much prefer a kernel that boots
correctly
on all of them if possible.

Gabriels stuff breaks on several.  It does not take into account some of the
newer stuff
such as the Mesquite cPCI board.  As Cort stated in one message in this
thread of
discussion, LinuxPPC is already trying to account for dozens of sometimes
very different
board types and is currently doing it with only 3 or 4 different boot loader
setups.  It
has been identified as necessary to add at least a couple of more to account
for all the
MBX stuff and others.  If the number of boot loaders increases into the
dozens, the
corresponding kernel changes will follow suit and chaos will rule in the
LinuxPPC
world.

I too have sent patches to Cort that are not yet in the sources.  I too would
very
much like to see them in and solve the issues I have keeping my sources
updated
everytime there is changes to the vger tree. I have 13 years of doing UNIX
kernel experience and have seen too many engineers concerned with getting
their little bit of the picture working reguardless of what it does to
everybody
else.

When you send a patch to Cort and wish it too be included, he will test it on
the
machines he currently has.  They are not all inclusive and if It breaks one
of them
then that patch should be rejected.  If he does not reject it then he looses
credibility in his submissions to Linus and at some time no more PPC code
will make it into the main base because Linus will not trust Cort.  I cannot
and
will not beleive that this is what you want.

I am not sure but I think that I recently saw a post where Gabriel showed an
ftp
link where you could retrieve his stuff.  He also stated that it did not work
with
Open Firmware.  Some of the boxes I use to test various things I am trying to
do
with LinuxPPC are Motorola Utahs.  There are some bootleg versions of PPCBug
floating around for them but they are incomplete and the engineer that did
most of
the work to get it going (in his free time) told me that it is still unstable
on the
Utah.  I also tried for 2 days to get Gabriels patches and try them again
to see if some of the problems I was having had been fixed.  I never got in.
Here
again if you want credibility with Cort, me and the others subscribing to
this list
then dont make posts that are unrealistic like this one.

I have been using Linux since the 0.96 release.  For many years I did not
have
the chance to participate directly in the Linux community.  I did, however,
follow what was going on.  I have over the years read flames against every
coordinator there was includeing Linus.  Somebody has to control what gets
into the source base.  For LinuxPPC right now this is Cort.  He has taken
the responsibility for it.  I have rarely seen professionals that had a clue
about how to do this and Cort as a graduate student is doing a pretty damn
good job.

There was at one point something called the System V Interface
Definition for UNIX.  I spent years telling customers that what they wanted
would break the standards for UNIX and I rarely got more than "but thats what

I want back".  Cort is in the position where he has to tell people the same
kind of thing.  Good engineers do not break exsisting things to get new
things
working.  It is Corts job to enforce this with LinuxPPC.

I have stated to Cort that I can test pretty much anything he needs on
Motorola
boxes (Blackhawk, Utah, MTX, MVMEXXXX, Mequite, Sitka, etc.)  I will tell
him where it does and does not work.  You can do the same it you have
resources.
We will get pretty much everything working with time.  Give Cort a break
and work with him.

Johnnie


VALETTE Eric wrote:

> >>>>> "Cort" == Cort Dougan <cort@persephone.cs.nmt.edu> writes:
>
> Cort> It's not as simple as you suggest.
>
> You haven't even tried. Did you try Gabriel patches?
>
> Cort Code it up so that it works on all
> Cort> the boards around and I'll be quite happy to take it :)  The problem
> Cort> I'm having now is code that works on one set doesn't work on others.
>
> That's your choice. Provided you do not ask me to agree and do not
> ask for support of your way of handling patches...
>
> -- eric




[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Interrupt routing in prep_pci.c

[VALETTE Eric]

>>>>> "Johnnie" == Johnnie Peters <jpeters@phx.mcd.mot.com> writes:

Johnnie> I have tried Gabriels patches.  I used his boot loader stuff with my own
Johnnie> Raven changes
Johnnie> and for some of our boards it worked great (namely the VME boards). 

I use Cpci board (mcp750) and it works well.

Johnnie> When you send a patch to Cort and wish it too be included, he will test it on
Johnnie> the
Johnnie> machines he currently has.  They are not all inclusive and if It breaks one
Johnnie> of them
Johnnie> then that patch should be rejected.  If he does not reject it then he looses
Johnnie> credibility in his submissions to Linus and at some time no more PPC code
Johnnie> will make it into the main base because Linus will not trust Cort.  I cannot
Johnnie> and
Johnnie> will not beleive that this is what you want.

I say this way of doing is bad because :

  1) Cort admit that he has no recent board,
  2) Value of a patch should be mesured in number of additionnal cards that works with
  a patch versus the number of boards it breaks AND a cleaner design.
  3) Sometimes you must admit to breaks things because otherwyse
  you will not manage to get further. I understand the discussion
  on source tree layout reorganisation is vital in this regard.
  
Allthough the current way of doing slows down the development, update to regular
linux source tree are not frequent... Many people have complained about CVS
access being broken that just makes things worse... And there is linux-pmac 
that still complicates the picture...

Johnnie> link where you could retrieve his stuff.  He also stated that it did not work
Johnnie> with Open Firmware.

Its work is called "prepboot" so if you think it is for OF sure you will not get too
far...

Johnnie> I have been using Linux since the 0.96 release.  

And I (with others) have designed what could have been the next version of 
Unixware 2.x if novell did not sell USL to SCO...

Johnnie> I have stated to Cort that I can test pretty much anything he needs on
Johnnie> Motorola
Johnnie> boxes (Blackhawk, Utah, MTX, MVMEXXXX, Mequite, Sitka, etc.)  I will tell

How many motorola board having OF can you buy today? How many having PPCBUG?

Johnnie> him where it does and does not work.  You can do the same it you have
Johnnie> resources.
Johnnie> We will get pretty much everything working with time.  Give Cort a break
Johnnie> and work with him.

What I can say for sure is that :

     1) not a single kernel released by Cort does work without modification 
     on MCP750 because the old code for interrupt routing screw up anythings 
     relies on PCI interrupt value. Besides there is no code for identifying
     the machines that would enables to gracefully include codes...
     2) I have seen patches to support the raven that have never been
     integrated although they work on MVMW2700 and MCP750 (are there
     other PREP machines that use raven???),
     3) Multi-device PCI function will never be handled correctly with actual
     prep code...
     4) PREP Ide byte swapping is still broken. You cannot read IDE disk
     partitionned on a PC, nor use PPCBUG pboot to load linux on a prep machine
     (allthough someone has already provided a patch...),

So, given that : I keep my patches as the code is ugly enough so that
I do not find way to correctly integrate it and as I need to apply
patch anyway, I prefer to apply them on "official" tree.

But that is probably not arguments that could convince someone with your
perfect understanding and your immense experience...

BTW, as you work for motorolla, may be you could you tell us how 
PPCBUG identifies boards dynamically. As least THIS would be helpfull.


--
   __                 
  /  `                   	Eric Valette
 /--   __  o _.          	Canon CRF
(___, / (_(_(__         	Rue de la touche lambert
				35517 Cesson-Sevigne  Cedex
				FRANCE
Tel: +33 (0)2 99 87 68 91	Fax: +33 (0)2 99 84 11 30
E-mail: valette@crf.canon.fr

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Interrupt routing in prep_pci.c

[Cort Dougan]

I disagree with that quite a bit.  I don't believe that we can allow the
"support in this version, not in the next, now in the next..." type of
flip-flop.  

We can move ahead and we need to do it quickly, yes.  So lets do that.  My
previous message details my plan.  If there aren't any serious objections
lets get working rather than trying to use our own bootloaders.  Lets
merge them or failing that provide a few different ones.

If we can't do things that way I'll need to stick with the current
bootloader and just start taking patches against that to get things
working.  I don't think that's a good solution since the current loader is
broken.

}  2) Value of a patch should be mesured in number of additionnal cards that works with
}  a patch versus the number of boards it breaks AND a cleaner design.


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Interrupt routing in prep_pci.c

[VALETTE Eric]

>>>>> "Cort" == Cort Dougan <cort@persephone.cs.nmt.edu> writes:

Cort> I disagree with that quite a bit.  I don't believe that we can allow the
Cort> "support in this version, not in the next, now in the next..." type of
Cort> flip-flop.  

This is not really a flip flop if it is clearly announced! Once you have something
that work on your hardware, you can wait until it works again. Or decide
to make the patch yourself. I for example have done the work on 2.1.131 and
then waited for 2.2.1

Anyway, thanks for your mail about merging bootloaders. I personnaly
agree on most part.

Note that, we may also need to fix the early kernel setup...

-- eric

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Interrupt routing in prep_pci.c

[Cort Dougan]

Can you send me the latest diffs needed for your board?  Mostly pci
interrupt routing, right?  That can go in right away.

}Note that, we may also need to fix the early kernel setup...


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

bootloader problems and linux/ppc developers tree

[Cort Dougan]

I need everyone with their favorite bootloaders to talk to one another.  I
can't be the communication point between you all.  There are several
groups out there who have interest in certain boards to work - and
don't care about the others.  Unfortunately, this has given us a set of
bootloaders that work on subsets of the machines.

What I'd really appreciate is if you guys could give one another your
versions of the bootloaders and iron out the differences.  I _cannot_ test
all the systems out - I don't have the hardware.  I'd very much like to
handle this quickly by having the hardware by merging them myself and
trying them out but I don't have the resources.  I need you to help me
here.

We need to resolve this now.  Someone, it doesn't matter who, stick a
bootloader for arch/ppc/prepboot on the ftp server here.  My preference the
one from Garbriel since most people have based their work off of it.
That'll be our new reference bootloader.  Then, everyone with a board they
need to work grab it and test it out.  If it doesn't work, or doesn't work
the way you like send all of us that are interested email with your
problems and your code merged in to fix your problems (if you have any
code, otherwise we can try to fix the problems).

Then we can get this prepboot situation over with.  I want all boards
booting and I will not put in a new bootloader that breaks the older
boards.  Arguments about 'having to break things sometimes' have their
strengths, but I don't think this is the place or time.  2.2.x needs
to be stable and not just drop support for certain boards to begin
supporting newer ones.  I do not want to get into the habit of screwing
users with older boards (one of whom is me - I only have the older prep
boards).

Within the next few weeks if we can't get this settled I think it would
worth creating separate bootloaders for prep machines.  If the designs are
so different this may be the only way - but I'd like to give a real try to
find a general solution first.

Once that is finally retired I'd like to merge in the other changes that
have backed up (smp mtx and so on) so I can create a linux/ppc developer
tree.  I'll talk to Larry about bitkeeper this week to find out useful it
would be in this case.  If things don't look ready with bitkeeper I'll
create a cvs tree here.

Does this sound good to everyone?  I think this will address the more
immediate problems.  2.2.x is a good time to resolve these issues and I'd
like to do it right.  I'd hate to loose the good work you've all done
by things getting too divergent.  Lets share code and try to hammer out a
common bootloader for prep now.

I'll be at linuxworld so I may not be able to respond to email about the
bootloader as quickly as I'd like.  I'll probably be doing work there, too
but I need a lot of feedback from you to get this done.

}That's your choice. Provided you do not ask me to agree and do not
}ask for support of your way of handling patches...


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: bootloader problems and linux/ppc developers tree

[VALETTE Eric]

>>>>> "Cort" == Cort Dougan <cort@persephone.cs.nmt.edu> writes:


Cort> Does this sound good to everyone?  I think this will address the more
Cort> immediate problems.  2.2.x is a good time to resolve these issues and I'd
Cort> like to do it right.  I'd hate to loose the good work you've all done
Cort> by things getting too divergent.  Lets share code and try to hammer out a
Cort> common bootloader for prep now.

I could not agree more. Sorry to have pushed for this to happen a little
firmly and at least non diplomaticly.

Note that the kernel early setup (prep_*) should be handled in a similar 
way as I think many incompatibilities lies there also.

--  eric

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: bootloader problems and linux/ppc developers tree

[Gabriel Paubert]

On Fri, 26 Feb 1999, Cort Dougan wrote:

> I need everyone with their favorite bootloaders to talk to one another.  I
> can't be the communication point between you all.  There are several
> groups out there who have interest in certain boards to work - and
> don't care about the others.  Unfortunately, this has given us a set of
> bootloaders that work on subsets of the machines.

Indeed.

> What I'd really appreciate is if you guys could give one another your
> versions of the bootloaders and iron out the differences.  I _cannot_ test
> all the systems out - I don't have the hardware.  I'd very much like to
> handle this quickly by having the hardware by merging them myself and
> trying them out but I don't have the resources.  I need you to help me
> here.

Fine. 

> We need to resolve this now.  Someone, it doesn't matter who, stick a
> bootloader for arch/ppc/prepboot on the ftp server here.  My preference the
> one from Garbriel since most people have based their work off of it.
> That'll be our new reference bootloader.  Then, everyone with a board they
> need to work grab it and test it out.  If it doesn't work, or doesn't work
> the way you like send all of us that are interested email with your
> problems and your code merged in to fix your problems (if you have any
> code, otherwise we can try to fix the problems).

Ok, my bootloader still relies too much on residual data. I'm sorry for
this but I thought they would be reliable on recent boards, they are not 
and are often completely wrong, and old boards never provide them on
netboots. However, for interested people, I have put a program on my 
site (which I'll upload as soon as I can) in:

	ftp://vcorr1.iram.es/pub/other/residual.c.gz

which can be used to dump the contents of the residual data once you've
been able to upload them to a tftp server with a NIOP command under
PPCBug (note that the program will only run under a Linux/PPC machine,
I was to lazy to make it endian-independant and, horror, it includes
kernel headers for things like ld_le{16,32}).

> Then we can get this prepboot situation over with.  I want all boards
> booting and I will not put in a new bootloader that breaks the older
> boards.  Arguments about 'having to break things sometimes' have their
> strengths, but I don't think this is the place or time.  2.2.x needs
> to be stable and not just drop support for certain boards to begin
> supporting newer ones.  I do not want to get into the habit of screwing
> users with older boards (one of whom is me - I only have the older prep
> boards).

I only have MVME2600. 

> Within the next few weeks if we can't get this settled I think it would
> worth creating separate bootloaders for prep machines.  If the designs are
> so different this may be the only way - but I'd like to give a real try to
> find a general solution first.

I agree.

> Once that is finally retired I'd like to merge in the other changes that
> have backed up (smp mtx and so on) so I can create a linux/ppc developer
> tree.  I'll talk to Larry about bitkeeper this week to find out useful it
> would be in this case.  If things don't look ready with bitkeeper I'll
> create a cvs tree here.

Ok, note that it seems that anon cvs vger access has been removed forever
because the loadd as too high. I've been bitten very hard by this, and
will never go back to any cvs server which is not maintained by the
Linux/PPC people.

> Does this sound good to everyone?  I think this will address the more
> immediate problems.  2.2.x is a good time to resolve these issues and I'd
> like to do it right.  I'd hate to loose the good work you've all done
> by things getting too divergent.  Lets share code and try to hammer out a
> common bootloader for prep now.

Ok, of course if someone has a better base to start than my prepboot code,
he's welcome. 

	Gabriel.


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Interrupt routing in prep_pci.c

[Matt Porter]

On Mon, 22 Feb 1999, VALETTE Eric wrote:

> eric>	1) we should know wether the board firmware correctly
> eric>	set up the PCI devices. If this is the case, the old
> eric>	interrupt scheme must be removed. Note that this
> eric>	implies to have a better scheme for identifying board than the
> eric>	inb (0x800) currently used.
> 
> Cort> That's right, we should keep the setup if it's correct.  Find me a better
> Cort> scheme for identifying the board, then.
> 
> For motorola, use the sytem configuration register at physaddr 0xfef80400 for
> example. I do not know all the boards but probably someone at motorola could 
> make suggestions as I bet PPCBUG has code to make it :)
> 
> I think  correct board dentification is a key point for code
> portability/autoconfiguration. Not working on this item will
> prevent any good restructuration as adding code for one board will
> break another...

Ok, maybe this will help stop the endless whining.

First determine Raven or Hawk existence, if it is Raven the following
works:

The key is to use the base module status register (BMSR) at I/O 0x802

0xe0  MCP750
0xe1  MCPN750
0xf7  MTX no parport
0xf8  MTX w/ parport
0xf9  MVME2300
0xfa  MVME2300SC or MVME2600 w/100BaseT (use SYSCR 0xfef80400 to determine
      which: bits 31-24 of SYSCR are 0xfd for 2300's or 0xfe for others)
0xfb  MVME2600/2700 w/712 I/O
0xfc  MVME2600/2700 w/761 I/O
0xfd  MVME3600 w/712 I/O
0xfe  MVME3600 w/761 I/O
0xff  MVME1600

Now, if it is a Hawk, you have a new architecture which has no board
registers.  VPD is stored in EEPROM across the Hawk I2C bus.  Write the
I2C lib for Hawk and parse the data.  It is _much_ more detailed than what
is available from the old register sets.  The first board with this scheme
is the MVME2400.

--
Matt Porter
mmporter@home.com
This is Linux Country. On a quiet night, you can hear Windows reboot.


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Interrupt routing in prep_pci.c

[Cort Dougan]

No hand-waving.  Send me code.  I need to check this against other boards
with different IO areas, different register layouts and such.

Please remember, your world of the newer moto boards isn't the entire
scope of what I'm trying to support.  So when you get frustrated with me
not taking things that are "obvious and easy" fixes please understand that
it may not work on other machines.

I'm not adamantly refusing anyones work, I'm trying to get these things to
evolve into a single working bootloader.

}First determine Raven or Hawk existence, if it is Raven the following
}works:


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Interrupt routing in prep_pci.c

[Matt Porter]

On Fri, 26 Feb 1999, Cort Dougan wrote:

Hey, I don't _like_ just putting the info up there, but it was better than
letting the people who might have had time then to do the code guess how
to identify every single board.  Gathering that information would have
been a pain for anybody on the outside.

Now that I solved my top priority problems (de4x5 failed on 21143-based
Moto boards and booting from flash works finally), I suppose I'll code
this out of necessity.  If anybody's got a working board ID framework or
has any sort of board ID code started for Moto. boards let me know because
I hate to duplicate effort...

> No hand-waving.  Send me code.  I need to check this against other boards
> with different IO areas, different register layouts and such.
> 
> Please remember, your world of the newer moto boards isn't the entire
> scope of what I'm trying to support.  So when you get frustrated with me
> not taking things that are "obvious and easy" fixes please understand that
> it may not work on other machines.
> 
> I'm not adamantly refusing anyones work, I'm trying to get these things to
> evolve into a single working bootloader.
> 
> }First determine Raven or Hawk existence, if it is Raven the following
> }works:
> 

--
Matt Porter
mmporter@home.com
This is Linux Country. On a quiet night, you can hear Windows reboot.


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]