Pegasos 2 support patch ...

Hello,

Please find here attached a patch which adds support for the Pegasos 2
motherboard, and partial support for the Pegasos 1. I would like to have
some review of it, and if it is ok, see how it would be possible to have
it included in the main kernel. The patch is against 2.6.7.

The remaining problem for the pegasos 2 is with the via82cxxx ide
driver, which needs to support a different irq for both channels, thus
breakign when a device is present on the second ide channel. The
pegasos-via82cxxx.diff patches is a hcky soltuion for this, but is
naturally not fit for mainstream inclusion. I would welcome any hint on
how to solve this issue.

The pegasos1 support is not complete, but i believe this is due to some
brokeness in the OF. The main problem being that the translate function
is broken, and altough phys has the right value (0x00010000) before
calling it, it is 0 afterwards. I suppose the initial value is taken
from &_stext, so it should be feasible to detect that this is the
correct value before calling the translate OF method, or fixing it if we
detect a Pegasos 1 with the model OF property. Comments on this would
also be welcome. There may be some interrupt level thing left on pegasos
1 also, but i would need to check that.

Thanks for your comments,

Friendly,

Sven Luther

On Tue, Jun 29, 2004 at 06:50:29PM +0200, Sven Luther wrote:

The pegasos1 support is not complete, but i believe this is due to some
brokeness in the OF. The main problem being that the translate function
is broken, and altough phys has the right value (0x00010000) before
calling it, it is 0 afterwards. I suppose the initial value is taken
from &_stext, so it should be feasible to detect that this is the
correct value before calling the translate OF method, or fixing it if we
detect a Pegasos 1 with the model OF property. Comments on this would
also be welcome. There may be some interrupt level thing left on pegasos
1 also, but i would need to check that.

Well, the pegasos 1 seems to start with mmu enabled, but with BATs
mapped 1:1. There is not much we can do unless we fix the translate
method, i think. The attached patch tests if the machine is a pegasos 1
(but not 2) and sets the phys to 0x00010000 if this is the case.

Another solution would be to test before doing the translate call, maybe
this would be more elegant ?

Friendly,

Sven Luther

Another solution would be to test before doing the translate call, maybe
this would be more elegant ?

Yup, if you know it will be broken, don't bother calling it,
and please, avoid the over-long line :)

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Tue, Jun 29, 2004 at 09:57:29PM -0500, Benjamin Herrenschmidt wrote:

quoted

Another solution would be to test before doing the translate call, maybe
this would be more elegant ?

Yup, if you know it will be broken, don't bother calling it,
and please, avoid the over-long line :)

Ok, this is then the final patch, i hope it is now correct.

The only part missing is the via82cxxx patch, where may i best find help
on how to best solve this ? I wrote the maintainer listed in the patch,
but never got a reply.

Friendly,

Sven Luther

On Wed, 30 Jun 2004, Sven Luther wrote:

On Tue, Jun 29, 2004 at 09:57:29PM -0500, Benjamin Herrenschmidt wrote:

quoted

quoted

Another solution would be to test before doing the translate call, maybe
this would be more elegant ?

Yup, if you know it will be broken, don't bother calling it,
and please, avoid the over-long line :)

Ok, this is then the final patch, i hope it is now correct.

                                               ^
Bogus asterisk

+		 * it directly.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Wed, Jun 30, 2004 at 10:10:07AM +0200, Geert Uytterhoeven wrote:

On Wed, 30 Jun 2004, Sven Luther wrote:

quoted

On Tue, Jun 29, 2004 at 09:57:29PM -0500, Benjamin Herrenschmidt wrote:

quoted

quoted

Another solution would be to test before doing the translate call, maybe
this would be more elegant ?

Yup, if you know it will be broken, don't bother calling it,
and please, avoid the over-long line :)

Ok, this is then the final patch, i hope it is now correct.

quoted

--- kernel-source-2.6.7.orig/arch/ppc/syslib/prom_init.c	2004-06-16 07:20:24.000000000 +0200
+++ kernel-source-2.6.7.peg2/arch/ppc/syslib/prom_init.c	2004-06-30 07:51:49.975232432 +0200

@@ -850,11 +853,20 @@

 	klimit = (char *) (mem - offset);

-	/* If we are already running at 0xc0000000, we assume we were
-	 * loaded by an OF bootloader which did set a BAT for us.
-	 * This breaks OF translate so we force phys to be 0.
-	 */
-	if (offset == 0) {
+	node = call_prom("finddevice", 1, 1, "/");
+	rc = call_prom("getprop", 4, 1, node, "model", model, sizeof(model));
+	if (rc > 0 && !strncmp (model, "Pegasos", 7)
+		&& strncmp (model, "Pegasos2", 8)) {
+		/* Pegasos 1 has a broken translate method in the OF,
+		 * and furthermore the BATs are mapped 1:1 so the phys
+		 * address calculated above is * correct, so let's use

                                               ^
Bogus asterisk

Ok, i will remove it thanks.

Friendly,

Sven Luther

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Tue, 2004-06-29 at 17:50, Sven Luther wrote:

The remaining problem for the pegasos 2 is with the via82cxxx ide
driver, which needs to support a different irq for both channels, thus
breakign when a device is present on the second ide channel. The
pegasos-via82cxxx.diff patches is a hcky soltuion for this, but is
naturally not fit for mainstream inclusion. I would welcome any hint on
how to solve this issue.

I have a board which has the same problem.

My current idea is to add an extra flag to the ide_pci_device_t to
indicate that the device defaults to ports 14 and 15, then modify
ide_hwif_configure() to use this flag.

- Adrian Cox
Humboldt Solutions Ltd.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Wed, Jun 30, 2004 at 10:18:10AM +0100, Adrian Cox wrote:

On Tue, 2004-06-29 at 17:50, Sven Luther wrote:

quoted

The remaining problem for the pegasos 2 is with the via82cxxx ide
driver, which needs to support a different irq for both channels, thus
breakign when a device is present on the second ide channel. The
pegasos-via82cxxx.diff patches is a hcky soltuion for this, but is
naturally not fit for mainstream inclusion. I would welcome any hint on
how to solve this issue.

I have a board which has the same problem.

My current idea is to add an extra flag to the ide_pci_device_t to
indicate that the device defaults to ports 14 and 15, then modify
ide_hwif_configure() to use this flag.

Ok, sounds nice, do you plan to write this patch anytime soon, or should
i go forward and implement this idea ?

Thanks for the reply.

Friendly,

Sven Luther

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Wed, 2004-06-30 at 10:30, Sven Luther wrote:

On Wed, Jun 30, 2004 at 10:18:10AM +0100, Adrian Cox wrote:

quoted

On Tue, 2004-06-29 at 17:50, Sven Luther wrote:

quoted

The remaining problem for the pegasos 2 is with the via82cxxx ide
driver, which needs to support a different irq for both channels, thus
breakign when a device is present on the second ide channel. [snip]

quoted

My current idea is to add an extra flag to the ide_pci_device_t to
indicate that the device defaults to ports 14 and 15, then modify
ide_hwif_configure() to use this flag.

Ok, sounds nice, do you plan to write this patch anytime soon, or should
i go forward and implement this idea ?

I've got a few other things to get into the kernel before this, so
please don't wait for me. If you make a patch I'll test it.

In my case, the initial setup is that the device has been assigned I/O
space address in the 0xfe00 range, and no PCI IRQ.  This confuses the
PCI IDE code, because it assumes that the device must be an add-in card
if it is not on the legacy ports.

- Adrian Cox
Humboldt Solutions Ltd.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Wed, Jun 30, 2004 at 10:40:47AM +0100, Adrian Cox wrote:

On Wed, 2004-06-30 at 10:30, Sven Luther wrote:

quoted

On Wed, Jun 30, 2004 at 10:18:10AM +0100, Adrian Cox wrote:

quoted

On Tue, 2004-06-29 at 17:50, Sven Luther wrote:

quoted

The remaining problem for the pegasos 2 is with the via82cxxx ide
driver, which needs to support a different irq for both channels, thus
breakign when a device is present on the second ide channel. [snip]

quoted

quoted

My current idea is to add an extra flag to the ide_pci_device_t to
indicate that the device defaults to ports 14 and 15, then modify
ide_hwif_configure() to use this flag.

Ok, sounds nice, do you plan to write this patch anytime soon, or should
i go forward and implement this idea ?

I've got a few other things to get into the kernel before this, so
please don't wait for me. If you make a patch I'll test it.

Ok, altough i have not much experience with ide stuff.

In my case, the initial setup is that the device has been assigned I/O
space address in the 0xfe00 range, and no PCI IRQ.  This confuses the
PCI IDE code, because it assumes that the device must be an add-in card
if it is not on the legacy ports.

Ok.

Friendly,

Sven Luther

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Wed, Jun 30, 2004 at 10:18:10AM +0100, Adrian Cox wrote:

On Tue, 2004-06-29 at 17:50, Sven Luther wrote:

quoted

The remaining problem for the pegasos 2 is with the via82cxxx ide
driver, which needs to support a different irq for both channels, thus
breakign when a device is present on the second ide channel. The
pegasos-via82cxxx.diff patches is a hcky soltuion for this, but is
naturally not fit for mainstream inclusion. I would welcome any hint on
how to solve this issue.

I have a board which has the same problem.

My current idea is to add an extra flag to the ide_pci_device_t to
indicate that the device defaults to ports 14 and 15, then modify
ide_hwif_configure() to use this flag.

Mmm, ...

static ide_hwif_t *ide_hwif_configure(struct pci_dev *dev,
	ide_pci_device_t *d, ide_hwif_t *mate, int port, int irq)

Would it not be better in my case to call ide_hwif_configure with the
right irq ? Or do i misunderstand what you had in mind ?

Friendly,

Sven Luther


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Wed, 2004-06-30 at 16:50, Sven Luther wrote:

static ide_hwif_t *ide_hwif_configure(struct pci_dev *dev,
	ide_pci_device_t *d, ide_hwif_t *mate, int port, int irq)

Would it not be better in my case to call ide_hwif_configure with the
right irq ? Or do i misunderstand what you had in mind ?

It shouldn't make much difference - I only suggested ide_hwif_configure
because it already contains flag checking code.

- Adrian Cox
Humboldt Solutions Ltd.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Wed, Jun 30, 2004 at 05:12:46PM +0100, Adrian Cox wrote:

On Wed, 2004-06-30 at 16:50, Sven Luther wrote:

quoted

static ide_hwif_t *ide_hwif_configure(struct pci_dev *dev,
	ide_pci_device_t *d, ide_hwif_t *mate, int port, int irq)

Would it not be better in my case to call ide_hwif_configure with the
right irq ? Or do i misunderstand what you had in mind ?

It shouldn't make much difference - I only suggested ide_hwif_configure
because it already contains flag checking code.

I am not sure if it works for me, but in your case, would the right
solution not be to have d->init_chipset return the irq ?

Friendly,

Sven Luther

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Wed, 2004-06-30 at 17:23, Sven Luther wrote:

I am not sure if it works for me, but in your case, would the right
solution not be to have d->init_chipset return the irq ?

No, because d->init_chipset is only called once per pci device, and that
one pci device provides two channels with different irqs.

The problem is that the via686 ide is hardwired to irqs 14 and 15 of the
i8259 interrupt controller internally, but the kernel believes that only
IDE controllers at the legacy address can have separate irqs for each
channel.

- Adrian Cox
Humboldt Solutions Ltd.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Wed, Jun 30, 2004 at 05:39:35PM +0100, Adrian Cox wrote:

On Wed, 2004-06-30 at 17:23, Sven Luther wrote:

quoted

I am not sure if it works for me, but in your case, would the right
solution not be to have d->init_chipset return the irq ?

No, because d->init_chipset is only called once per pci device, and that
one pci device provides two channels with different irqs.

Ah, too bad. that said, this could be perhaps changed ? After all the
calling code in the idesetup stuff is per channel, so there is no reason
we could not call this one (or a similar function) for each channel.

The problem is that the via686 ide is hardwired to irqs 14 and 15 of the
i8259 interrupt controller internally, but the kernel believes that only
IDE controllers at the legacy address can have separate irqs for each
channel.

Is this the case for each via ide controller ? If so why does it work on
x86 ?

Friendly,

Sven Luther

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Wed, 2004-06-30 at 19:52, Sven Luther wrote:

On Wed, Jun 30, 2004 at 05:39:35PM +0100, Adrian Cox wrote:

quoted

The problem is that the via686 ide is hardwired to irqs 14 and 15 of the
i8259 interrupt controller internally, but the kernel believes that only
IDE controllers at the legacy address can have separate irqs for each
channel.

Is this the case for each via ide controller ? If so why does it work on
x86 ?

Because on x86 the BIOS places the IDE controller at the legacy
addresses (0x1f0, 0x170), and then setup-pci.c spots that the via ide
controller is also the legacy IDE controller, and thus uses the legacy
irq numbers 14 and 15.

What I'm looking for is a tidy way of achieving the same result on a
platform where the boot firmware did not put the via ide controller at
the legacy addresses.

- Adrian Cox
Humboldt Solutions Ltd.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Wed, Jun 30, 2004 at 08:05:01PM +0100, Adrian Cox wrote:

On Wed, 2004-06-30 at 19:52, Sven Luther wrote:

quoted

On Wed, Jun 30, 2004 at 05:39:35PM +0100, Adrian Cox wrote:

quoted

The problem is that the via686 ide is hardwired to irqs 14 and 15 of the
i8259 interrupt controller internally, but the kernel believes that only
IDE controllers at the legacy address can have separate irqs for each
channel.

Is this the case for each via ide controller ? If so why does it work on
x86 ?

Because on x86 the BIOS places the IDE controller at the legacy
addresses (0x1f0, 0x170), and then setup-pci.c spots that the via ide
controller is also the legacy IDE controller, and thus uses the legacy
irq numbers 14 and 15.

Ah, ok, so this is just another x86-bug, and there should really be no
major problem in rectifying it, and all the code should already be in
setup-pci.c. We just need to find some way to detect that we are also in
this case. Could this not be probed somehow ? In which case are the irq
numbers the same ? Only when the via driver is on a stansalone pci card ?

What I'm looking for is a tidy way of achieving the same result on a
platform where the boot firmware did not put the via ide controller at
the legacy addresses.

Ok, the main point would be to fins the tidy way for doing this.

Friendly,

Sven Luther

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Wed, 30 Jun 2004, Sven Luther wrote:

On Wed, Jun 30, 2004 at 08:05:01PM +0100, Adrian Cox wrote:

quoted

On Wed, 2004-06-30 at 19:52, Sven Luther wrote:

quoted

On Wed, Jun 30, 2004 at 05:39:35PM +0100, Adrian Cox wrote:

quoted

The problem is that the via686 ide is hardwired to irqs 14 and 15 of the
i8259 interrupt controller internally, but the kernel believes that only
IDE controllers at the legacy address can have separate irqs for each
channel.

Is this the case for each via ide controller ? If so why does it work on
x86 ?

Because on x86 the BIOS places the IDE controller at the legacy
addresses (0x1f0, 0x170), and then setup-pci.c spots that the via ide
controller is also the legacy IDE controller, and thus uses the legacy
irq numbers 14 and 15.

Ah, ok, so this is just another x86-bug, and there should really be no
major problem in rectifying it, and all the code should already be in
setup-pci.c. We just need to find some way to detect that we are also in
this case. Could this not be probed somehow ? In which case are the irq
numbers the same ? Only when the via driver is on a stansalone pci card ?

quoted

What I'm looking for is a tidy way of achieving the same result on a
platform where the boot firmware did not put the via ide controller at
the legacy addresses.

Ok, the main point would be to fins the tidy way for doing this.

Cfr. the code in longtrail_pcibios_fixup() and briq_pcibios_fixup() for the
SL82C105 IDE interface, which is left in legacy mode by Open Firmware?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Thu, 2004-07-01 at 08:59, Geert Uytterhoeven wrote:

On Wed, 30 Jun 2004, Sven Luther wrote:

quoted

On Wed, Jun 30, 2004 at 08:05:01PM +0100, Adrian Cox wrote:

quoted

Ah, ok, so this is just another x86-bug, and there should really be no
major problem in rectifying it, and all the code should already be in
setup-pci.c. We just need to find some way to detect that we are also in
this case. Could this not be probed somehow ? In which case are the irq
numbers the same ? Only when the via driver is on a stansalone pci card ?

The via 686 can't go on a standalone pci card, as it's a complete
southbridge.

quoted

quoted

What I'm looking for is a tidy way of achieving the same result on a
platform where the boot firmware did not put the via ide controller at
the legacy addresses.

Ok, the main point would be to fins the tidy way for doing this.

Cfr. the code in longtrail_pcibios_fixup() and briq_pcibios_fixup() for the
SL82C105 IDE interface, which is left in legacy mode by Open Firmware?

Which tree are those boards in?

There's a similar fixup in pplus.c in 2.6.7, but I don't like the way
IDE works on PowerPC currently. The ppc_ide_md structure and the fixups
are being used to fool the core ide code into behaving in a specific
way. The core ide code makes no guarantees that these tricks will
continue to work, and in my case the necessary tricks changed between
2.4 and 2.6. The only platform specific knowledge required for the Via
686 is the mapping between the internal i8259 interrupt number and the
linux interrupt number.

- Adrian Cox
Humboldt Solutions Ltd.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Thu, 1 Jul 2004, Adrian Cox wrote:

On Thu, 2004-07-01 at 08:59, Geert Uytterhoeven wrote:

quoted

On Wed, 30 Jun 2004, Sven Luther wrote:

quoted

On Wed, Jun 30, 2004 at 08:05:01PM +0100, Adrian Cox wrote:

quoted

What I'm looking for is a tidy way of achieving the same result on a
platform where the boot firmware did not put the via ide controller at
the legacy addresses.

Ok, the main point would be to fins the tidy way for doing this.

Cfr. the code in longtrail_pcibios_fixup() and briq_pcibios_fixup() for the
SL82C105 IDE interface, which is left in legacy mode by Open Firmware?

Which tree are those boards in?

LongTrail support has been in the main tree since several years. But
longtrail_pcibios_fixup() may still be missing even in the PPC tree (it doesn't
seem to be in plain 2.6.7 yet). Patches floated on the list.

There's a similar fixup in pplus.c in 2.6.7, but I don't like the way
IDE works on PowerPC currently. The ppc_ide_md structure and the fixups
are being used to fool the core ide code into behaving in a specific
way. The core ide code makes no guarantees that these tricks will
continue to work, and in my case the necessary tricks changed between
2.4 and 2.6. The only platform specific knowledge required for the Via
686 is the mapping between the internal i8259 interrupt number and the
linux interrupt number.

And the internal i8259 interrupt number is always the same as the Linux
interrupt number to support legacy code, right?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Thu, Jul 01, 2004 at 09:42:52AM +0100, Adrian Cox wrote:

On Thu, 2004-07-01 at 08:59, Geert Uytterhoeven wrote:

quoted

On Wed, 30 Jun 2004, Sven Luther wrote:

quoted

On Wed, Jun 30, 2004 at 08:05:01PM +0100, Adrian Cox wrote:

quoted

quoted

Ah, ok, so this is just another x86-bug, and there should really be no
major problem in rectifying it, and all the code should already be in
setup-pci.c. We just need to find some way to detect that we are also in
this case. Could this not be probed somehow ? In which case are the irq
numbers the same ? Only when the via driver is on a stansalone pci card ?

The via 686 can't go on a standalone pci card, as it's a complete
southbridge.

So, do i understand this correctly, and all instances of the via82cxxx
driver have the 14/15 interrupt arrangement ? Or are there other
standalone pci cards basd on the via ide chipset ?

quoted

quoted

quoted

What I'm looking for is a tidy way of achieving the same result on a
platform where the boot firmware did not put the via ide controller at
the legacy addresses.

Ok, the main point would be to fins the tidy way for doing this.

Cfr. the code in longtrail_pcibios_fixup() and briq_pcibios_fixup() for the
SL82C105 IDE interface, which is left in legacy mode by Open Firmware?

Which tree are those boards in?

There's a similar fixup in pplus.c in 2.6.7, but I don't like the way
IDE works on PowerPC currently. The ppc_ide_md structure and the fixups
are being used to fool the core ide code into behaving in a specific
way. The core ide code makes no guarantees that these tricks will
continue to work, and in my case the necessary tricks changed between
2.4 and 2.6. The only platform specific knowledge required for the Via
686 is the mapping between the internal i8259 interrupt number and the
linux interrupt number.

Mmm.

Friendly,

Sven Luther

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/