Going from 2.2.12 to 2.2.17pre10

Going from 2.2.12 to 2.2.17pre10

[Michael Lundkvist]

Hi!

I'm trying to go from 2.2.12 to 2.2.17pre10 on an MVME 2400.

A few problems:

The Motorola SROM bug-patch lacks one row in de4x5.c:

--- de4x5.c~    Thu Jul  6 16:01:32 2000
+++ de4x5.c     Thu Jul  6 16:14:18 2000
@@ -4829,6 +4829,7 @@
     } else if ((lp->media == INIT) && (lp->timeout < 0)) {
         lp->ibn = 3;
        lp->active = *p;
+       if (MOTO_SROM_BUG) lp->active = 0;
        lp->infoblock_csr6 = OMR_MII_100;
        lp->useMII = TRUE;
        lp->infoblock_media = ANS;

This one was easy. Now for the hard one. :)

I'm using a PMC-harddisk based on the CMD-646 chipset (Ramix 233).

I installed my system under 2.2.12 with Debian.

When I come to the partition check in 2.2.17pre10 it fails with
"hda: unknown partition table"

I added a printout in drivers/block/genhd.c in msdos_partition()

--- genhd.c~    Thu Jul  6 16:01:31 2000
+++ genhd.c     Thu Jul  6 16:48:02 2000
@@ -522,7 +522,8 @@
 #endif
        if (*(unsigned short *)  (0x1fe + data) != cpu_to_le16(MSDOS_LABEL_MAGIC)) {
                brelse(bh);
-               return 0;
+               printk("Data: %x LABEL:%x\n",(*(unsigned short *)  (0x1fe + data)), cpu_to_le16(MSDOS_LABEL_MAGIC) );
+               return 0;
        }
        p = (struct partition *) (0x1be + data);


With this I get the following printout:
hda:Data: aa55 LABEL:55aa

So it seems like the byte order is wrong. Does anyone know why this
happens?

Please don't tell me my 2.2.12 partitioned disk is wrong. :)

Where do I go for the best LinuxPPC 2.4 kernel for MVME-boards? Is it
fsmlabs Bitkeeper repository?

/Micke

--
ml@epact.se

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

Re: Going from 2.2.12 to 2.2.17pre10

[Hollis Blanchard]

Michael Lundkvist wrote:

[snip]

> So it seems like the byte order is wrong. Does anyone know why this
> happens?
>
> Please don't tell me my 2.2.12 partitioned disk is wrong. :)

Something like that. This came up a while back (around 2.2.13 I think)
on the -workstation list. I didn't pay enough attention at the time, but
I think it switched from being always little-endian to being
native-endian. At least, I don't recall any x86 folks screaming about
it... ;)

I think without reformatting your only option is to use 'hda=swapdata'.

> Where do I go for the best LinuxPPC 2.4 kernel for MVME-boards? Is it
> fsmlabs Bitkeeper repository?

Probably. If that doesn't work shop around. ;)

-Hollis

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

Re: Going from 2.2.12 to 2.2.17pre10

[Gabriel Paubert]

On 6 Jul 2000, Michael Lundkvist wrote:

>
> Hi!
>
> I'm trying to go from 2.2.12 to 2.2.17pre10 on an MVME 2400.
>
> A few problems:
>
> The Motorola SROM bug-patch lacks one row in de4x5.c:
>
> --- de4x5.c~    Thu Jul  6 16:01:32 2000
> +++ de4x5.c     Thu Jul  6 16:14:18 2000
> @@ -4829,6 +4829,7 @@
>      } else if ((lp->media == INIT) && (lp->timeout < 0)) {
>          lp->ibn = 3;
>         lp->active = *p;
> +       if (MOTO_SROM_BUG) lp->active = 0;
>         lp->infoblock_csr6 = OMR_MII_100;
>         lp->useMII = TRUE;
>         lp->infoblock_media = ANS;
>
> This one was easy. Now for the hard one. :)
>
> I'm using a PMC-harddisk based on the CMD-646 chipset (Ramix 233).
>
> I installed my system under 2.2.12 with Debian.
>
> When I come to the partition check in 2.2.17pre10 it fails with
> "hda: unknown partition table"
>
> I added a printout in drivers/block/genhd.c in msdos_partition()
>
> --- genhd.c~    Thu Jul  6 16:01:31 2000
> +++ genhd.c     Thu Jul  6 16:48:02 2000
> @@ -522,7 +522,8 @@
>  #endif
>         if (*(unsigned short *)  (0x1fe + data) != cpu_to_le16(MSDOS_LABEL_MAGIC)) {
>                 brelse(bh);
> -               return 0;
> +               printk("Data: %x LABEL:%x\n",(*(unsigned short *)  (0x1fe + data)), cpu_to_le16(MSDOS_LABEL_MAGIC) );
> +               return 0;
>         }
>         p = (struct partition *) (0x1be + data);
>
>
> With this I get the following printout:
> hda:Data: aa55 LABEL:55aa
>
> So it seems like the byte order is wrong. Does anyone know why this
> happens?
>
> Please don't tell me my 2.2.12 partitioned disk is wrong. :)

What's your version of fdisk ?

Under 2.2.12 dd if=/dev/hda of=xxx bs=512 count=1 and see what comes out.
Can PPCBUG actually boot from these disks ?

>
> Where do I go for the best LinuxPPC 2.4 kernel for MVME-boards? Is it
> fsmlabs Bitkeeper repository?

I have 2.4.0-test2 running on an MVME2600, look at:

	ftp://vlab1.iram.es/pub/linux-2.4

did not try the MVME2400 yet (they are all in use for real tasks, I'm
waiting for more and have to develop on the 16Mb MVME2600 :-(). But I
only have SCSI disks or NFSRoot.

I have a 2.2.16 kernel compiled but never booted, I could give you R/O
access to my BK trees if you want (but the machine on which they are is
not up 100% of the time).

	Gabriel.

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

Re: Going from 2.2.12 to 2.2.17pre10

[Michael Lundkvist]

Gabriel Paubert <paubert@iram.es> writes:

> On 6 Jul 2000, Michael Lundkvist wrote:
>
> >
> > Please don't tell me my 2.2.12 partitioned disk is wrong. :)
>
> What's your version of fdisk ?

It seems like Hollis Blanchard was right so I'm doing a reinstall with
2.2.16 instead.

>
> Under 2.2.12 dd if=/dev/hda of=xxx bs=512 count=1 and see what comes out.
> Can PPCBUG actually boot from these disks ?
>

Nope. I think I'll go for Bugboot. Ramix also talked about the
possibility of modifying PPCBug to add support for the Ramix 233.

> >
> > Where do I go for the best LinuxPPC 2.4 kernel for MVME-boards? Is it
> > fsmlabs Bitkeeper repository?
>
> I have 2.4.0-test2 running on an MVME2600, look at:
>
> 	ftp://vlab1.iram.es/pub/linux-2.4
>
> did not try the MVME2400 yet (they are all in use for real tasks, I'm
> waiting for more and have to develop on the 16Mb MVME2600 :-(). But I
> only have SCSI disks or NFSRoot.
>

OK. I'll try that on a MVME2400.

We have ~25 MVME2400 just lying around here since they haven't been
able to get VxWorks working properly on them yet. :)

> I have a 2.2.16 kernel compiled but never booted, I could give you R/O
> access to my BK trees if you want (but the machine on which they are is
> not up 100% of the time).
>
> 	Gabriel.

How much difference is there between that and the main kernel?

The main reason I'm moving from the 2.2.12 is that it wasn't stable
under load on the MVME2400. I figured it was pointless to try to debug
it on an old kernel.

/Micke

--
ml@epact.se

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

Re: Going from 2.2.12 to 2.2.17pre10

[Gabriel Paubert]

	Hi,

> > What's your version of fdisk ?
>
> It seems like Hollis Blanchard was right so I'm doing a reinstall with
> 2.2.16 instead.

Ok, never had any problems with SCSI since DMA always gets the byte order
right ;-)

> > Under 2.2.12 dd if=/dev/hda of=xxx bs=512 count=1 and see what comes out.
> > Can PPCBUG actually boot from these disks ?
> >
>
> Nope. I think I'll go for Bugboot. Ramix also talked about the
> possibility of modifying PPCBug to add support for the Ramix 233.

Where is and what is Bugboot ?

> > > fsmlabs Bitkeeper repository?
> >
> > I have 2.4.0-test2 running on an MVME2600, look at:
> >
> > 	ftp://vlab1.iram.es/pub/linux-2.4
> >
> > did not try the MVME2400 yet (they are all in use for real tasks, I'm
> > waiting for more and have to develop on the 16Mb MVME2600 :-(). But I
> > only have SCSI disks or NFSRoot.
> >
>
> OK. I'll try that on a MVME2400.
>
> We have ~25 MVME2400 just lying around here since they haven't been
> able to get VxWorks working properly on them yet. :)
>
> > I have a 2.2.16 kernel compiled but never booted, I could give you R/O
> > access to my BK trees if you want (but the machine on which they are is
> > not up 100% of the time).
> >
> > 	Gabriel.
>
> How much difference is there between that and the main kernel?

Quite a lot. A complete bootloader, drivers for VME and many small patches
in the arch/ppc/kernel subtree. A diffstat of both patches gives:

 73 files changed, 19880 insertions, 478 deletions

> The main reason I'm moving from the 2.2.12 is that it wasn't stable
> under load on the MVME2400. I figured it was pointless to try to debug
> it on an old kernel.

I had to shut down an MVME2600 after 6 months of uptime with this kernel
for hardware upgrade. It is used as a server for all the nfsroot machines
and to compile all the software for these (and sometimes heavily swapping:
3 compiles in parallel in 32 Mb or RAM are noticeable). The MVME2400 have
never been under serious load, so I don't know if they have specific
problems but the kernel is essentially the same (less drivers and
filesystems).

I have not heavily stress-tested 2.4.0-test2 (well recompiling kernels and
performing bitkeeper patch imports is kind of stress testing I/O,
especially with 16Mb), I had some filesystem problems in 2.3.50 but they
have vanished it seems.

	Gabriel.

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

Re: Going from 2.2.12 to 2.2.17pre10

[Michael Lundkvist]

Gabriel Paubert <paubert@iram.es> writes:

> Ok, never had any problems with SCSI since DMA always gets the byte order
> right ;-)
>

It wasn't my decision to go with IDE...

>
> Where is and what is Bugboot ?
>

It's a bootloader for flashed kernels. Written by Matt Porter from Motorola.
http://members.home.net/mmporter/linux/

Could I do the same thing with your bootloader?

I would like to have a bootloader that can read from disk so that it
is easy to replace the kernel.

>
> Quite a lot. A complete bootloader, drivers for VME and many small patches
> in the arch/ppc/kernel subtree. A diffstat of both patches gives:
>
>  73 files changed, 19880 insertions, 478 deletions
>

OK. Then I'd like to try it. My initial tests with 2.2.17pre10 didn't
turn out well.

>
> I had to shut down an MVME2600 after 6 months of uptime with this kernel
> for hardware upgrade. It is used as a server for all the nfsroot machines
> and to compile all the software for these (and sometimes heavily swapping:
> 3 compiles in parallel in 32 Mb or RAM are noticeable). The MVME2400 have
> never been under serious load, so I don't know if they have specific
> problems but the kernel is essentially the same (less drivers and
> filesystems).
>

I ran the Debian 2.2.12 (with Motorola SROM bug patch) on a 2300 with
a fair bit of compiling and it was stable. The same kernel on an 2400
was unstable during compiles.

> I have not heavily stress-tested 2.4.0-test2 (well recompiling kernels and
> performing bitkeeper patch imports is kind of stress testing I/O,
> especially with 16Mb), I had some filesystem problems in 2.3.50 but they
> have vanished it seems.
>
> 	Gabriel.

I'll give your 2.4 a try. I need to get atleast one more PMC disk so I
can have one stable and one unstable evironment.

On an unrelated subject. I would like to have a Linux-board as SYSCON
on the VME bus that is able to generate a reset on the bus but doesn't
listen to it. Have you got any idea if it would be possible to modify
a MVME-card that way? To me it looks like it would be possible to
disconnect the signal from the Universe-bridge.

/Micke


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

Re: Going from 2.2.12 to 2.2.17pre10

[Gabriel Paubert]

On 7 Jul 2000, Michael Lundkvist wrote:

>
> Gabriel Paubert <paubert@iram.es> writes:
>
> > Ok, never had any problems with SCSI since DMA always gets the byte order
> > right ;-)
> >
>
> It wasn't my decision to go with IDE...

Well, it may be better since right now I'm stuck with 8 bit old SCSI
drives and running extremely short on disk space.

>
> >
> > Where is and what is Bugboot ?
> >
>
> It's a bootloader for flashed kernels. Written by Matt Porter from Motorola.
> http://members.home.net/mmporter/linux/

Ok...

> Could I do the same thing with your bootloader?
>
> I would like to have a bootloader that can read from disk so that it
> is easy to replace the kernel.

Mine cannot read from disk (for now). With OF it would be easy to call
methods to read from a disk, but with PPCBUG you woule have either:

- to use firmware specific calls (provided the interface is supported) and
you don't switch the MMU on (even mapped 1:1) since it does not work
whatever the documentation claims (actually I think I know where the bug
is in PPCBUG).

- to write your own drivers for the bootloader (might be quite simple
actually, since performance is not a concern, and you only need to read).
But then you have to know where to stop (include readonly filesystems ?).

So for now the (compressed) kernel is always in the initially loaded
image (very handy for network boots which is what I mostly use).

> > Quite a lot. A complete bootloader, drivers for VME and many small patches
> > in the arch/ppc/kernel subtree. A diffstat of both patches gives:
> >
> >  73 files changed, 19880 insertions, 478 deletions
> >
>
> OK. Then I'd like to try it. My initial tests with 2.2.17pre10 didn't
> turn out well.

Note that thiss was for 2.2.12, as I said I've not booted 2.2.16 so I did
not put the patches on my ftp site (that's the only QA I do :-)).

> I ran the Debian 2.2.12 (with Motorola SROM bug patch) on a 2300 with
> a fair bit of compiling and it was stable. The same kernel on an 2400
> was unstable during compiles.

Ok, since the main difference is the host bridge. I would rather suspect a
bad bit setting which results in coherency problems, or bad
memory/whatever (did you try several MVME2400 to see whether it was
reproducible ?)

> I'll give your 2.4 a try. I need to get atleast one more PMC disk so I
> can have one stable and one unstable evironment.

I usually netboot 2 different versions of the kernel (and I select the
kernel to boot with a symlink on the server to avoid editing
/etc/dhcpd.conf and restarting dhcpd). The rest of the system is
identical.

> On an unrelated subject. I would like to have a Linux-board as SYSCON
> on the VME bus that is able to generate a reset on the bus but doesn't
> listen to it. Have you got any idea if it would be possible to modify
> a MVME-card that way? To me it looks like it would be possible to
> disconnect the signal from the Universe-bridge.

It should be but I don't know how. I implemented the capability to reset
the VME bus in my Universe driver and tested it on an Pentium VME board
but right now it is disabled since the driver is compiled by default with
#define SUICIDAL_VME_RESET.

Trying to modify such a multilayer board with connections to a BGA is a
daunting prospect. The VME bus buffers might be te right place to do it
since they should be more or less accessible (with extreme care).

	Gabriel.


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

Re: Going from 2.2.12 to 2.2.17pre10

[Michael Lundkvist]

Gabriel Paubert <paubert@iram.es> writes:


> Mine cannot read from disk (for now). With OF it would be easy to call
> methods to read from a disk, but with PPCBUG you woule have either:
>
> - to use firmware specific calls (provided the interface is supported) and
> you don't switch the MMU on (even mapped 1:1) since it does not work
> whatever the documentation claims (actually I think I know where the bug
> is in PPCBUG).
>
> - to write your own drivers for the bootloader (might be quite simple
> actually, since performance is not a concern, and you only need to read).
> But then you have to know where to stop (include readonly filesystems ?).
>
> So for now the (compressed) kernel is always in the initially loaded
> image (very handy for network boots which is what I mostly use).
>

I have to be able to create a standalone system so network boot is not
an option.

Maybe I'll look in to creating a driver for the bootloader. When I get
some spare time....

How portable is something like Grub? Maybe that could be a way to go.

>
> Note that thiss was for 2.2.12, as I said I've not booted 2.2.16 so I did
> not put the patches on my ftp site (that's the only QA I do :-)).
>

OK. 2.2.12 is not interesting. I don't want do reinstall again... :)

>
> Ok, since the main difference is the host bridge. I would rather suspect a
> bad bit setting which results in coherency problems, or bad
> memory/whatever (did you try several MVME2400 to see whether it was
> reproducible ?)
>

I have tried two MVME-2400 boards but I haven't had time to do any
systematic testing. It always crashes in find_buffer in fs/buffer.c
during moderate to heavy disk activity. I'm starting to suspect that
the CMD646 isn't being setup correctly since it feels like the system
was more stable after a cold reboot. I'll have to test it a bit more.

>
> It should be but I don't know how. I implemented the capability to reset
> the VME bus in my Universe driver and tested it on an Pentium VME board
> but right now it is disabled since the driver is compiled by default with
> #define SUICIDAL_VME_RESET.
>
> Trying to modify such a multilayer board with connections to a BGA is a
> daunting prospect. The VME bus buffers might be te right place to do it
> since they should be more or less accessible (with extreme care).
>
> 	Gabriel.

You're probably right that it's easier modify the backplane.

I'll just tell our HW-guys what I want and let them figure it out.

/Micke

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

Re: Going from 2.2.12 to 2.2.17pre10

[Gabriel Paubert]

On 7 Jul 2000, Michael Lundkvist wrote:

> I have to be able to create a standalone system so network boot is not
> an option.

Sigh, and falshing the kernel neither I suppose...

> Maybe I'll look in to creating a driver for the bootloader. When I get
> some spare time....

> How portable is something like Grub? Maybe that could be a way to go.

I was under the impression that it was very x86 focussed (but maybe I'm
mixing things up with OpenBIOS).

> > Note that thiss was for 2.2.12, as I said I've not booted 2.2.16 so I did
> > not put the patches on my ftp site (that's the only QA I do :-)).
> >
>
> OK. 2.2.12 is not interesting. I don't want do reinstall again... :)

Fine, but 2.2.16 is claimed to have other problems (look at Alan's release
notes for each 2.2.17-pre).

> I have tried two MVME-2400 boards but I haven't had time to do any
> systematic testing. It always crashes in find_buffer in fs/buffer.c
> during moderate to heavy disk activity. I'm starting to suspect that
> the CMD646 isn't being setup correctly since it feels like the system
> was more stable after a cold reboot. I'll have to test it a bit more.

Ok, that's likely the cause. SCSI (NCR) disk access is rock solid here on
MVME2600.

> You're probably right that it's easier modify the backplane.

No, it's not the backplane, it's the implementation in the MVME boards:


PCI bus <-> Universe <-> Layer of buffers <-> VME connectors

The PCI bus is probably largely buried inside the PCB layers.
The Universe is a BGA.
The VME bus has only one (bidirectional) reset signal.

However there are 2 VME reset signal buffer, one inwards and one outwards
for 2 pins of the Universe (VME reset in and VME reset out).

	Universe       Buffers       VME connector

	VXSYSRST-------|>o--+
                            |--------SYSRST*
	VRSYSRST#------<|---+

The only accessible place (with adequate lab equipment) are the buffers:
cut the input or the output of the receive buffer and connect it to the
power supply (safer on the input since it can directly be connected to
the buffer power supply while I'm not sure that some versions of the
Universe are not 3.3V only)   .

	Gabriel.


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

Re: Going from 2.2.12 to 2.2.17pre10

[Michael Lundkvist]

Gabriel Paubert <paubert@iram.es> writes:

> On 7 Jul 2000, Michael Lundkvist wrote:
>
> > I have to be able to create a standalone system so network boot is not
> > an option.
>
> Sigh, and falshing the kernel neither I suppose...
>

If I can find a stable version it is an option. And I actually have
plenty of time to look. I need a rock-stable system by the end of this
year.

>
> Fine, but 2.2.16 is claimed to have other problems (look at Alan's release
> notes for each 2.2.17-pre).
>

I'll try 2.2.17pre10 tonight and see if I have more luck with that.

> > I have tried two MVME-2400 boards but I haven't had time to do any
> > systematic testing. It always crashes in find_buffer in fs/buffer.c
> > during moderate to heavy disk activity. I'm starting to suspect that
> > the CMD646 isn't being setup correctly since it feels like the system
> > was more stable after a cold reboot. I'll have to test it a bit more.
>
> Ok, that's likely the cause. SCSI (NCR) disk access is rock solid here on
> MVME2600.
>

I guess I should talk to Ramix. They have been helpful before.
I'll also try to go back to an older version of the
CMD646-driver. There are a few timing related setup changes in the
newer versions.

>
> No, it's not the backplane, it's the implementation in the MVME boards:
>
>
> PCI bus <-> Universe <-> Layer of buffers <-> VME connectors
>
> The PCI bus is probably largely buried inside the PCB layers.
> The Universe is a BGA.
> The VME bus has only one (bidirectional) reset signal.
>
> However there are 2 VME reset signal buffer, one inwards and one outwards
> for 2 pins of the Universe (VME reset in and VME reset out).
>
> 	Universe       Buffers       VME connector
>
> 	VXSYSRST-------|>o--+
>                             |--------SYSRST*
> 	VRSYSRST#------<|---+
>
> The only accessible place (with adequate lab equipment) are the buffers:
> cut the input or the output of the receive buffer and connect it to the
> power supply (safer on the input since it can directly be connected to
> the buffer power supply while I'm not sure that some versions of the
> Universe are not 3.3V only)   .
>

OK. Then it looks quite possible. Thanks for the info.

/Micke

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

Re: Going from 2.2.12 to 2.2.17pre10

[Gabriel Paubert]

On 7 Jul 2000, Michael Lundkvist wrote:

> If I can find a stable version it is an option. And I actually have
> plenty of time to look. I need a rock-stable system by the end of this
> year.

Ok, I hoppe 2.4 will be out then...

> I'll try 2.2.17pre10 tonight and see if I have more luck with that.

Well, I'm going to put my patches for 2.2.16 in an untested directory
then...

> I guess I should talk to Ramix. They have been helpful before.
> I'll also try to go back to an older version of the
> CMD646-driver. There are a few timing related setup changes in the
> newer versions.

This might indeed be the problem. My 2400 are not heavily stressed but
nevertheless they are stable: one has 52 days and the other 39 days
uptime. The second one had a strange behaviour when a lightning struck the
telescope however and had to be powered down before rebooting, hard reset
through front panel push button would not work (not even reaching PPCBUG
boot messages).

> > The only accessible place (with adequate lab equipment) are the buffers:
> > cut the input or the output of the receive buffer and connect it to the
> > power supply (safer on the input since it can directly be connected to
> > the buffer power supply while I'm not sure that some versions of the
> > Universe are not 3.3V only)   .
> >
>
> OK. Then it looks quite possible. Thanks for the info.

Thee only problem is to locate this damned buffer (just find which one is
connected to the VME bus SYSRST but there are so many).

	Gabriel.


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

Problem with de4x5 on an MVME-2400

[Michael Lundkvist]

Gabriel Paubert <paubert@iram.es> writes:

>
> > I'll try 2.2.17pre10 tonight and see if I have more luck with that.
>
> Well, I'm going to put my patches for 2.2.16 in an untested directory
> then...
>

Now I've tried every recent 2.2.x kernel I could get my hands on and
none of them are stable during disk load except for the pre-built
Debian 2.2.16pre5 that I can't find the source for.

I also tried your 2.4.0test2 patch and after adding a call to
ppc_generic_ide_fix_driveid as shown below I got it to boot. This is
the best 2.4-kernel I've tried so far.

In arch/ppc/kernel/prep_setup.c:
void __prep
prep_ide_fix_driveid(struct hd_driveid *id)
{
        ppc_generic_ide_fix_driveid(id);
}


But I have one quite big problem with it. The onboard network interface
doesn't work.

It initializes without problem and detects the 100Mbit/s carrier but
it fails after a few seconds.

I get the following errors:
eth0: Setup frame timed out, status f0600004
Unhandled interrupt 1, disabled
Unhandled interrupt 1, disabled
Unhandled interrupt 1, disabled
eth0: media is 100Mb/s.
Unhandled interrupt 1, disabled
Unhandled interrupt 1, disabled


Do you have any idea what this could be?


Complete boot log at the end of the mail. Any more info you need?

/Micke

Residual-Data Located at: $0FF88000

Model:                            (e2)
Serial: MOT03AE1BA
Processor/Bus frequencies (Hz): 450030400/100001944
Time Base Divisor: 4000
MS(0): START=4000, END=fcff, OFF=0, ATT=d2
PS(0): START=0, END=3fff, OFF=0, ATT=8af3
MS(1): START=fd00, END=fdff, OFF=300, ATT=d2
PS(1): START=0, END=0, OFF=0, ATT=8a00
MS(2): START=0, END=0, OFF=4000, ATT=2
PS(2): START=0, END=0, OFF=0, ATT=8a00
MS(3): START=fe00, END=febf, OFF=200, ATT=c0
PS(3): START=0, END=0, OFF=0, ATT=8a00

PCI: Probing PCI hardware
PCI device 00:00.0 register 0 disabled
Configurable PCI resources:
IO Port resources:
   00000000 007fffff 00000100 (@0ff7f244)
     00000000 00000000 40000100 (@0fecc198)
       0ff7df50 0ff7df5f 60000101 (@0feccdec)
       0ff7df64 0ff7df67 60000101 (@0feccdd0)
       0ff7df68 0ff7df6f 60000101 (@0feccdb4)
       0ff7df74 0ff7df77 60000101 (@0feccd98)
       0ff7df78 0ff7df7f 60000101 (@0feccd7c)
       0ff7df80 0ff7dfff 60000101 (@0feccaf4)
       0ff7e000 0ff7efff 60000101 (@0fecc888)
       0ff7ffc0 0ff7ffcf 60000101 (@0fecc670)
       0ff7ffd0 0ff7ffdf 60000101 (@0fecc654)
       0ff7ffe4 0ff7ffe7 60000101 (@0fecc638)
       0ff7ffe8 0ff7ffef 60000101 (@0fecc61c)
       0ff7fff4 0ff7fff7 60000101 (@0fecc600)
       0ff7fff8 0ff7ffff 60000101 (@0fecc5e4)
       00000000 0003ffff 20000101 (@0fecc0d4)
IO Memory resources:
   40000000 fcffffff 00000200 (@0ff7f260)
     00000000 00000000 40000200 (@0fecc1b4)
       2ff7ec00 2ff7efff 60000200 (@0feccb10)
       2ff7f000 2ff7ffff 60000200 (@0fecc86c)
       3c000000 3c03ffff 60000200 (@0fecc0f0)
     00000000 00000000 40001200 (@0fecc1d0)
       fffc0000 ffffffff 60007200 (@0feccb9c)
Allocation requirements: io=00002000, mem=00200000
Before actual allocations:
IO Port resources:
   00000000 007fffff 00000100 (@0ff7f244)
     00010000 00011fff 40000100 (@0fecc198)
       00000000 0003ffff 20000101 (@0fecc0d4)
       00000000 00000fff 60000101 (@0fecc888)
       00000000 0000007f 60000101 (@0feccaf4)
       00000000 0000000f 60000101 (@0feccdec)
       00000000 0000000f 60000101 (@0fecc670)
       00000000 0000000f 60000101 (@0fecc654)
       00000000 00000007 60000101 (@0feccdb4)
       00000000 00000007 60000101 (@0feccd7c)
       00000000 00000007 60000101 (@0fecc61c)
       00000000 00000007 60000101 (@0fecc5e4)
       00000000 00000003 60000101 (@0feccdd0)
       00000000 00000003 60000101 (@0feccd98)
       00000000 00000003 60000101 (@0fecc638)
       00000000 00000003 60000101 (@0fecc600)
IO Memory resources:
   40000000 fcffffff 00000200 (@0ff7f260)
     00000000 000fffff 40000200 (@0fecc1b4)
       00000000 0003ffff 60000200 (@0fecc0f0)
       00000000 00000fff 60000200 (@0fecc86c)
       00000000 000003ff 60000200 (@0feccb10)
     00000000 000fffff 40001200 (@0fecc1d0)
       00000000 0003ffff 60007200 (@0feccb9c)
Allocated PCI resources:
IO Port resources:
   00000000 007fffff 00000100 (@0ff7f244)
     00010000 00011fff 40000100 (@0fecc198)
       00000000 0003ffff 20000101 (@0fecc0d4)
       00010000 00010fff 40000101 (@0fecc888)
       00011000 0001107f 40000101 (@0feccaf4)
       00011080 0001108f 40000101 (@0feccdec)
       00011090 0001109f 40000101 (@0fecc670)
       000110a0 000110af 40000101 (@0fecc654)
       000110b0 000110b7 40000101 (@0feccdb4)
       000110b8 000110bf 40000101 (@0feccd7c)
       000110c0 000110c7 40000101 (@0fecc61c)
       000110c8 000110cf 40000101 (@0fecc5e4)
       000110d0 000110d3 40000101 (@0feccdd0)
       000110d4 000110d7 40000101 (@0feccd98)
       000110d8 000110db 40000101 (@0fecc638)
       000110dc 000110df 40000101 (@0fecc600)
IO Memory resources:
   40000000 fcffffff 00000200 (@0ff7f260)
     fcf00000 fcffffff 40000200 (@0fecc1b4)
       fcfbec00 fcfbefff 40000200 (@0feccb10)
       fcfbf000 fcfbffff 40000200 (@0fecc86c)
       fcfc0000 fcffffff 40000200 (@0fecc0f0)
     fce00000 fcefffff 40001200 (@0fecc1d0)
       fcec0000 fcefffff 40007200 (@0feccb9c)

Linux/PPC load: console=ttyS0 root=/dev/hda2

Uncompressing the kernel...done
Now building bootinfo...
done
Now booting...
Kernel at 0x00000000, size=0x1cbf34
Initrd at 0x0ff7eb5c, size=0x0
Boot info 0x001cc000, size=0x5c
Residual data at 0x001cd000
PReP architecture
Total memory = 256MB; using 1024kB for hash table (at c0200000)
Linux version 2.4.0-test2 (root@etss140) (gcc version 2.95.2 20000220 (Debian GNU/Linux)) #5 Sat Jul 8 02:56:56 CEST 2000
Boot arguments: console=ttyS0 root=/dev/hda2
On node 0 totalpages: 65536
zone(0): 65536 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: console=ttyS0 root=/dev/hda2
OpenPIC Version 1.3 (2 CPUs and 17 IRQ sources) at fcfc0000
OpenPIC timer frequency is 11 MHz
time_init: decrementer frequency = 1499976540/60 (23MHz)
Calibrating delay loop... 897.84 BogoMIPS
Memory: 254388k available (1052k kernel code, 584k data, 204k init)
0000000,d0000000]
Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes)
Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
kmem_create: Poisoning requested, but con given - bdev_cache
Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
kmem_create: Poisoning requested, but con given - inode_cache
POSIX conformance testing by UNIFIX
PCI: Probing PCI hardware
Setting PCI interrupts for a "MVME 2400"
Linux NET4.0 for Linux 2.3
Based upon Swansea University Computer Society NET3.039
kmem_create: Poisoning requested, but con given - skbuff_head_cache
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 16384)
Starting kswapd v1.6
pty: 256 Unix98 ptys configured
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: registered device at major 7
loop: enabling 8 loop devices
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
W82C105: ignored by ide_scan_pci_device() (uses own driver)
CMD646: IDE controller on PCI bus 00 dev 80
CMD646: chipset revision 7
CMD646: chipset revision 0x07, UltraDMA Capable
CMD646: 100% native mode on irq 25
hda: IBM-DARA-206000, ATA DISK drive
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ide0 at 0x110b8-0x110bf,0x110d6 on irq 25
hda: 11733120 sectors (6007 MB) w/418KiB Cache, CHS=12416/15/63
Partition check:
 hda: hda1 hda2
eth0: DC21143 at 0x11000 (PCI bus 0, device 14), h/w address 08:00:3e:2d:ce:9f,
      and requires IRQ18 (provided by PCI BIOS).
de4x5.c:V0.545 1999/11/28 davies@maniac.ultranet.com
Serial driver version 5.01 (2000-05-29) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
rtc: I/O port 112 is not free.
Macintosh non-volatile memory driver v1.0
kmem_create: Forcing size word alignment - nfs_fh
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 204k init 8k chrp 4k pmac 4k open firmware
modprobe: modprobe: Can't open dependencies file /lib/modules/2.4.0-test2/modules.dep (No such file or directory)
modprobe: modprobe: Can't open dependencies file /lib/modules/2.4.0-test2/modules.dep (No such file or directory)

modprobe: modprobe: Can't open dependencies file /lib/modules/2.4.0-test2/modules.dep (No such file or directory)

INIT: version 2.78 booting
Activating swap...
Adding Swap: 512148k swap-space (priority -1)
Checking root file system...
Parallelizing fsck version 1.18 (11-Nov-1999)
/dev/hda2 was not cleanly unmounted, check forced.
/dev/hda2: Deleted inode 622561 has zero dtime.  FIXED.
/dev/hda2: 89226/670432 files (1.5% non-contiguous), 344310/1338592 blocks
Calculating module dependencies... depmod: Can't open /lib/modules/2.4.0-test2/modules.dep for writing
done.
Loading modules:
modprobe: Can't open dependencies file /lib/modules/2.4.0-test2/modules.dep (No such file or directory)
Checking all file systems...
Parallelizing fsck version 1.18 (11-Nov-1999)
Setting kernel variables.
Loading the saved-state of the serial devices...
/dev/ttyS0 at 0x03f8 (irq = 4) is a 16550A
Mounting local filesystems...
not mounted anything
Running dns-clean.
Setting up IP spoofing protection: rp_filter.
Configuring network interfaces: eth0: Setup frame timed out, status f0600004

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

Re: Problem with de4x5 on an MVME-2400

[Gabriel Paubert]

On 8 Jul 2000, Michael Lundkvist wrote:

>
> Gabriel Paubert <paubert@iram.es> writes:
>
> >
> > > I'll try 2.2.17pre10 tonight and see if I have more luck with that.
> >
> > Well, I'm going to put my patches for 2.2.16 in an untested directory
> > then...
> >
>
> Now I've tried every recent 2.2.x kernel I could get my hands on and
> none of them are stable during disk load except for the pre-built
> Debian 2.2.16pre5 that I can't find the source for.
>
> I also tried your 2.4.0test2 patch and after adding a call to
> ppc_generic_ide_fix_driveid as shown below I got it to boot. This is
> the best 2.4-kernel I've tried so far.

Good...

>
> In arch/ppc/kernel/prep_setup.c:
> void __prep
> prep_ide_fix_driveid(struct hd_driveid *id)
> {
>         ppc_generic_ide_fix_driveid(id);
> }
>
>
> But I have one quite big problem with it. The onboard network interface
> doesn't work.
>
> It initializes without problem and detects the 100Mbit/s carrier but
> it fails after a few seconds.
>
> I get the following errors:
> eth0: Setup frame timed out, status f0600004
> Unhandled interrupt 1, disabled
> Unhandled interrupt 1, disabled
> Unhandled interrupt 1, disabled
> eth0: media is 100Mb/s.
> Unhandled interrupt 1, disabled
> Unhandled interrupt 1, disabled
>
>
> Do you have any idea what this could be?

It looks like a problem with network interrupt routing. I don't know why
since it works on my 2600 which use the same interrupt for the de4x5.
Can't test on a 2400 for now, sorry...

What does 'cat /proc/interrupt' tell, as well as /proc/ioports and
/proc/iomem ?

In which PMC slot did you put the Ramix (upper or lower ?). IDE interfaces
have strange interrupt routing topologies (and give me a _sane_ interrupt
system, a la VME or even Z80, any day :-().

> Complete boot log at the end of the mail. Any more info you need?

Not for now...

>
> /Micke
>
> Residual-Data Located at: $0FF88000
>
> Model:                            (e2)
> Serial: MOT03AE1BA
> Processor/Bus frequencies (Hz): 450030400/100001944
> Time Base Divisor: 4000
> MS(0): START=4000, END=fcff, OFF=0, ATT=d2
> PS(0): START=0, END=3fff, OFF=0, ATT=8af3
> MS(1): START=fd00, END=fdff, OFF=300, ATT=d2
> PS(1): START=0, END=0, OFF=0, ATT=8a00
> MS(2): START=0, END=0, OFF=4000, ATT=2
> PS(2): START=0, END=0, OFF=0, ATT=8a00
> MS(3): START=fe00, END=febf, OFF=200, ATT=c0
> PS(3): START=0, END=0, OFF=0, ATT=8a00

Ok, reconfiguration of Hawk in CHRP mode.

> Allocation requirements: io=00002000, mem=00200000
> Allocated PCI resources:
> IO Port resources:
>    00000000 007fffff 00000100 (@0ff7f244)
>      00010000 00011fff 40000100 (@0fecc198)
>        00000000 0003ffff 20000101 (@0fecc0d4)
>        00010000 00010fff 40000101 (@0fecc888)
>        00011000 0001107f 40000101 (@0feccaf4)
>        00011080 0001108f 40000101 (@0feccdec)
>        00011090 0001109f 40000101 (@0fecc670)
>        000110a0 000110af 40000101 (@0fecc654)
>        000110b0 000110b7 40000101 (@0feccdb4)
>        000110b8 000110bf 40000101 (@0feccd7c)
>        000110c0 000110c7 40000101 (@0fecc61c)
>        000110c8 000110cf 40000101 (@0fecc5e4)
>        000110d0 000110d3 40000101 (@0feccdd0)
>        000110d4 000110d7 40000101 (@0feccd98)
>        000110d8 000110db 40000101 (@0fecc638)
>        000110dc 000110df 40000101 (@0fecc600)

Fine (although IDE is a mess with registers spread all over the place,
especially the WinBond)
> IO Memory resources:
>    40000000 fcffffff 00000200 (@0ff7f260)
>      fcf00000 fcffffff 40000200 (@0fecc1b4)
>        fcfbec00 fcfbefff 40000200 (@0feccb10)  <--- ? is is the 21143 ?
>        fcfbf000 fcfbffff 40000200 (@0fecc86c)
>        fcfc0000 fcffffff 40000200 (@0fecc0f0)
>      fce00000 fcefffff 40001200 (@0fecc1d0)
>        fcec0000 fcefffff 40007200 (@0feccb9c)
>
> Linux/PPC load: console=ttyS0 root=/dev/hda2
>
> Uncompressing the kernel...done
> Now building bootinfo...
> done
> Now booting...
> Kernel at 0x00000000, size=0x1cbf34
> Initrd at 0x0ff7eb5c, size=0x0
> Boot info 0x001cc000, size=0x5c
> Residual data at 0x001cd000
> PReP architecture
> Total memory = 256MB; using 1024kB for hash table (at c0200000)
> Linux version 2.4.0-test2 (root@etss140) (gcc version 2.95.2 20000220 (Debian GNU/Linux)) #5 Sat Jul 8 02:56:56 CEST 2000
> Boot arguments: console=ttyS0 root=/dev/hda2
> On node 0 totalpages: 65536
> zone(0): 65536 pages.
> zone(1): 0 pages.
> zone(2): 0 pages.
> Kernel command line: console=ttyS0 root=/dev/hda2
> OpenPIC Version 1.3 (2 CPUs and 17 IRQ sources) at fcfc0000
> OpenPIC timer frequency is 11 MHz
> time_init: decrementer frequency = 1499976540/60 (23MHz)
> Calibrating delay loop... 897.84 BogoMIPS
> Memory: 254388k available (1052k kernel code, 584k data, 204k init)
> 0000000,d0000000]

Wow, my biggest machine has 32 Mb :-(

> Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes)
> Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes)
> Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
> kmem_create: Poisoning requested, but con given - bdev_cache
> Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
> kmem_create: Poisoning requested, but con given - inode_cache
> POSIX conformance testing by UNIFIX
> PCI: Probing PCI hardware
> Setting PCI interrupts for a "MVME 2400"
> Linux NET4.0 for Linux 2.3
> Based upon Swansea University Computer Society NET3.039
> kmem_create: Poisoning requested, but con given - skbuff_head_cache
> NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
> NET4: Linux TCP/IP 1.0 for NET4.0
> IP Protocols: ICMP, UDP, TCP, IGMP
> IP: routing cache hash table of 2048 buckets, 16Kbytes
> TCP: Hash tables configured (established 16384 bind 16384)
> Starting kswapd v1.6
> pty: 256 Unix98 ptys configured
> RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
> loop: registered device at major 7
> loop: enabling 8 loop devices
> Uniform Multi-Platform E-IDE driver Revision: 6.31
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> W82C105: ignored by ide_scan_pci_device() (uses own driver)
> CMD646: IDE controller on PCI bus 00 dev 80
> CMD646: chipset revision 7
> CMD646: chipset revision 0x07, UltraDMA Capable
> CMD646: 100% native mode on irq 25
> hda: IBM-DARA-206000, ATA DISK drive
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> ide0 at 0x110b8-0x110bf,0x110d6 on irq 25
> hda: 11733120 sectors (6007 MB) w/418KiB Cache, CHS=12416/15/63
> Partition check:
>  hda: hda1 hda2
> eth0: DC21143 at 0x11000 (PCI bus 0, device 14), h/w address 08:00:3e:2d:ce:9f,
>       and requires IRQ18 (provided by PCI BIOS).
> de4x5.c:V0.545 1999/11/28 davies@maniac.ultranet.com
> Serial driver version 5.01 (2000-05-29) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
> ttyS00 at 0x03f8 (irq = 4) is a 16550A
> rtc: I/O port 112 is not free.

Set CONFIG_RTC and/or CONFIG_NVRAM off. They don't work properly in any
case on this machine...

> Macintosh non-volatile memory driver v1.0
> kmem_create: Forcing size word alignment - nfs_fh
> VFS: Mounted root (ext2 filesystem) readonly.
> Freeing unused kernel memory: 204k init 8k chrp 4k pmac 4k open firmware
> modprobe: modprobe: Can't open dependencies file /lib/modules/2.4.0-test2/modules.dep (No such file or directory)
> modprobe: modprobe: Can't open dependencies file /lib/modules/2.4.0-test2/modules.dep (No such file or directory)
>
> modprobe: modprobe: Can't open dependencies file /lib/modules/2.4.0-test2/modules.dep (No such file or directory)
>
> INIT: version 2.78 booting
> Activating swap...
> Adding Swap: 512148k swap-space (priority -1)
> Checking root file system...
> Parallelizing fsck version 1.18 (11-Nov-1999)
> /dev/hda2 was not cleanly unmounted, check forced.
> /dev/hda2: Deleted inode 622561 has zero dtime.  FIXED.
> /dev/hda2: 89226/670432 files (1.5% non-contiguous), 344310/1338592 blocks
> Calculating module dependencies... depmod: Can't open /lib/modules/2.4.0-test2/modules.dep for writing
> done.
> Loading modules:
> modprobe: Can't open dependencies file /lib/modules/2.4.0-test2/modules.dep (No such file or directory)
> Checking all file systems...
> Parallelizing fsck version 1.18 (11-Nov-1999)
> Setting kernel variables.
> Loading the saved-state of the serial devices...
> /dev/ttyS0 at 0x03f8 (irq = 4) is a 16550A
> Mounting local filesystems...
> not mounted anything
> Running dns-clean.
> Setting up IP spoofing protection: rp_filter.
> Configuring network interfaces: eth0: Setup frame timed out, status f0600004

Looks again like interrupts are not coming through, or are set edge
instead of level or whatever.

	Gabriel.


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

Re: Problem with de4x5 on an MVME-2400

[Michael Lundkvist]

Gabriel Paubert <paubert@iram.es> writes:

> It looks like a problem with network interrupt routing. I don't know why
> since it works on my 2600 which use the same interrupt for the de4x5.
> Can't test on a 2400 for now, sorry...
>
> What does 'cat /proc/interrupt' tell, as well as /proc/ioports and
> /proc/iomem ?
>

I'm on vacation now so I can't check. I'll start messing with it in a
couple of weeks again.

Looking in de4x5.c for the error message it claims that the interrupts
are turned of.

I made some printouts of the registers of the 21143 and it looked to
me like it couldn't access the tx and rx buffers. I'll look again when
I get back.

/Micke

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

Re: Going from 2.2.12 to 2.2.17pre10

[Matt Porter]

On Thu, Jul 06, 2000 at 07:32:49PM +0200, Michael Lundkvist wrote:
>
> Gabriel Paubert <paubert@iram.es> writes:
> > Under 2.2.12 dd if=/dev/hda of=xxx bs=512 count=1 and see what comes out.
> > Can PPCBUG actually boot from these disks ?

PPCBUG expects a little endian partition table, so no.

> Nope. I think I'll go for Bugboot. Ramix also talked about the
> possibility of modifying PPCBug to add support for the Ramix 233.

I really have to recommend against that.  Once Ramix sees the icky PPCBUG
code they will hate as much as I do.  I gave well documented changes to
the PPCBUG guys so that BUGBOOT wasn't needed to boot a kernel from
FLASH on a PowerPlus board but they haven't incorporated those changes
after a full year now. :)

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

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

Re: Going from 2.2.12 to 2.2.17pre10

[Michael Lundkvist]

Matt Porter <mmporter@home.com> writes:

>
> > Nope. I think I'll go for Bugboot. Ramix also talked about the
> > possibility of modifying PPCBug to add support for the Ramix 233.
>
> I really have to recommend against that.  Once Ramix sees the icky PPCBUG
> code they will hate as much as I do.  I gave well documented changes to
> the PPCBUG guys so that BUGBOOT wasn't needed to boot a kernel from
> FLASH on a PowerPlus board but they haven't incorporated those changes
> after a full year now. :)
>

Getting those changes into PPCBUG would be great.

How board specific is the residual data that Bugboot needs?

Would it be possible to make one image for 2300 cards and one for 2400
cards or does memory size affect the residual data?

/Micke

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

Re: Going from 2.2.12 to 2.2.17pre10

[Matt Porter]

On Sun, Jul 09, 2000 at 08:12:26AM +0200, Michael Lundkvist wrote:
>
> Matt Porter <mmporter@home.com> writes:
>
> >
> > > Nope. I think I'll go for Bugboot. Ramix also talked about the
> > > possibility of modifying PPCBug to add support for the Ramix 233.
> >
> > I really have to recommend against that.  Once Ramix sees the icky PPCBUG
> > code they will hate as much as I do.  I gave well documented changes to
> > the PPCBUG guys so that BUGBOOT wasn't needed to boot a kernel from
> > FLASH on a PowerPlus board but they haven't incorporated those changes
> > after a full year now. :)
> >
>
> Getting those changes into PPCBUG would be great.

All you need is a big customer of MCG's to push them to do it.  Money
is a powerful motivator.

> How board specific is the residual data that Bugboot needs?

For the single processor boards, the only thing used for the prep port
is the memory sizing information.  You can always hack that or fix
the kernel to get memory size from the board registers or VPD (in the
case of the MVME2400 and later boards).

> Would it be possible to make one image for 2300 cards and one for 2400
> cards or does memory size affect the residual data?

See above, you could make a lowest common denominator version of the
data and lose some memory.  Honestly, I'd just hack the kernel...PPCBUG
and residual data are a horrible burden.  Look through prep_* and
mm/init.c for every place residual data is used and hardcode for your
MCG boards.  In init.c, prep_find_end_of_memory() can detect a Raven
bridge then use the documented board registers to identify memory size
(see online user manual).  A 2400 puts memory size across the I2C bus
in a EEPROM containing all sorts of useful information.  Bug MCG to get
specs on the layout of these VPD records.

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

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

Re: Going from 2.2.12 to 2.2.17pre10

[Gabriel Paubert]

On Sun, 9 Jul 2000, Matt Porter wrote:

> > Getting those changes into PPCBUG would be great.
>
> All you need is a big customer of MCG's to push them to do it.  Money
> is a powerful motivator.

Hopeless for me...

> > Would it be possible to make one image for 2300 cards and one for 2400
> > cards or does memory size affect the residual data?
>
> See above, you could make a lowest common denominator version of the
> data and lose some memory.  Honestly, I'd just hack the kernel...PPCBUG
> and residual data are a horrible burden.  Look through prep_* and
> mm/init.c for every place residual data is used and hardcode for your
> MCG boards.  In init.c, prep_find_end_of_memory() can detect a Raven
> bridge then use the documented board registers to identify memory size
> (see online user manual).  A 2400 puts memory size across the I2C bus
> in a EEPROM containing all sorts of useful information.  Bug MCG to get
> specs on the layout of these VPD records.

I disagree, the residual data of the device/property tree of OF are great
things. I want to boot _exactly_ the same kernel on machines with
different amounts of memory... A lot of the initizalization should be
moved to early boot or to a first stage bootloader (before uncompressing
the kernel) and then the kernel should receive important information in a
predigested form.

For the VPD records, the information in the MVME2400 programmer's guide
(mvme2400apg.pdf) looks sufficient (page 1-27 and appendix B).

	Regards,
	Gabriel.


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

Re: Going from 2.2.12 to 2.2.17pre10

[Matt Porter]

On Mon, Jul 10, 2000 at 02:25:19PM +0200, Gabriel Paubert wrote:
>
> On Sun, 9 Jul 2000, Matt Porter wrote:
>
> > > Getting those changes into PPCBUG would be great.
> >
> > All you need is a big customer of MCG's to push them to do it.  Money
> > is a powerful motivator.
>
> Hopeless for me...

Yeah, it's a tough spot since their aren't really any serious competitors
for the PPC VMEbus business.  CPCI is another story though.

> > > Would it be possible to make one image for 2300 cards and one for 2400
> > > cards or does memory size affect the residual data?
> >
> > See above, you could make a lowest common denominator version of the
> > data and lose some memory.  Honestly, I'd just hack the kernel...PPCBUG
> > and residual data are a horrible burden.  Look through prep_* and
> > mm/init.c for every place residual data is used and hardcode for your
> > MCG boards.  In init.c, prep_find_end_of_memory() can detect a Raven
> > bridge then use the documented board registers to identify memory size
> > (see online user manual).  A 2400 puts memory size across the I2C bus
> > in a EEPROM containing all sorts of useful information.  Bug MCG to get
> > specs on the layout of these VPD records.
>
> I disagree, the residual data of the device/property tree of OF are great
> things. I want to boot _exactly_ the same kernel on machines with
> different amounts of memory... A lot of the initizalization should be
> moved to early boot or to a first stage bootloader (before uncompressing
> the kernel) and then the kernel should receive important information in a
> predigested form.

That would be fine in a perfect world, but the reality is that MCG
continually puts out buggy firmware with holes in the residual data.
Since residual data is a dead standard, they are patching in new packet
types as new board features are added to make so Frankensteinian
PReP residual data standard.  Again, the only useful thing being
garnered from residual data for the PReP port is memory size.  This
is almost as easily gathered from the board registers on boards
< MVME2400 and from the VPD on those boards >= MVME2400.

Back to original point, I'm not against using a residual data or
device tree if it doesn't have to have dozens of fixups applied.
I just don't see that coming out of the proprietary hardware/software
houses to use their broken data...

> For the VPD records, the information in the MVME2400 programmer's guide
> (mvme2400apg.pdf) looks sufficient (page 1-27 and appendix B).

The PrPMC750 and latter boards have define VPD packets a bit different
IIRC.  2400 was the first board to define VPD and it _almost_ was
standardized but not quite. :)

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

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

Re: Going from 2.2.12 to 2.2.17pre10

[Adrian Cox]

Matt Porter wrote:
> Back to original point, I'm not against using a residual data or
> device tree if it doesn't have to have dozens of fixups applied.
> I just don't see that coming out of the proprietary hardware/software
> houses to use their broken data...

Residual data is useful for things like finding the memory size, and for
chips designed inside Apple. For almost everything else Linux already
contains a device tree, built by PCI probing when the kernel boots^*. I
don't see much need for a parallel, architecture specific, device tree.

- Adrian Cox, AG Electronics
*) Apologies to MCA and Nubus users.

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

Re: Going from 2.2.12 to 2.2.17pre10

[Benjamin Herrenschmidt]

>
>Residual data is useful for things like finding the memory size, and for
>chips designed inside Apple. For almost everything else Linux already
>contains a device tree, built by PCI probing when the kernel boots^*. I
>don't see much need for a parallel, architecture specific, device tree.

In the case of Apple HW, the OF device tree is the only way to know about:

 - Interrupt routing & sense type (level/edge)
 - Machine model (for the machine device-specific stuffs we have)
 - Bits inside Apple ASICs (we could hard code everything, but that doesn't
   sound like a good idea, and the device tree also provide things like the
   MAC address of the eth chip)
 - Firmware boot path (to setup the OF boot and configure the bootloader)
 - PCI hierarchy with the Uni-N chip
 - Memory size (of course)
 - What else did I forget ?


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

Re: Going from 2.2.12 to 2.2.17pre10

[Adrian Cox]

Benjamin Herrenschmidt wrote:

> In the case of Apple HW, the OF device tree is the only way to know about:
> [big list of things Apple OF tells you]

Actually, I'm whining about nothing. I just did a search of the drivers
tree, and the only generic PCI device that uses the OF tree is
chipsfb.c. Of course, that's the one I've been porting to a more generic
PCI device driver aimed at the later C&T devices.

As Geert has declared intent to move the FB drivers to PCI probing, this
is a non-issue.

- Adrian

btw: Off topic: which Powerbook uses chipsfb? If they're cheap
secondhand I'll consider becoming my own guinea-pig for the merged
driver.

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

Re: Going from 2.2.12 to 2.2.17pre10

[Claus]

 >:
 >: btw: Off topic: which Powerbook uses chipsfb? If they're cheap
 >: secondhand I'll consider becoming my own guinea-pig for the merged
 >: driver.

2400/3400/3500

--
Yours, ce

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

Re: Going from 2.2.12 to 2.2.17pre10

[Geert Uytterhoeven]

On Tue, 11 Jul 2000, Adrian Cox wrote:
> Benjamin Herrenschmidt wrote:
> > In the case of Apple HW, the OF device tree is the only way to know about:
> > [big list of things Apple OF tells you]
>
> Actually, I'm whining about nothing. I just did a search of the drivers
> tree, and the only generic PCI device that uses the OF tree is
> chipsfb.c. Of course, that's the one I've been porting to a more generic
> PCI device driver aimed at the later C&T devices.
>
> As Geert has declared intent to move the FB drivers to PCI probing, this
> is a non-issue.

Well, some (control/platinum/valkyrie) will keep on using OF probing since
they're used on PowerMac only. But their initialization routine will no longer
be called by offb.

Prepare to see an (untested, as usual :-) patch for this RSN...

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/

Re: Going from 2.2.12 to 2.2.17pre10

[Benjamin Herrenschmidt]

>Well, some (control/platinum/valkyrie) will keep on using OF probing since
>they're used on PowerMac only. But their initialization routine will no
longer
>be called by offb.
>
>Prepare to see an (untested, as usual :-) patch for this RSN...

BTW. I didn't look in details yet what's wrong, but I noticed that with
the current bk 2.4test3:

 - video=ofonly doesn't work. We need to find some kludge to get this one
back, as it's useful on some setup with broken video (and can be the only
way to get the machine up)

 - aty128fb doesn't intialize console_fb_info (the Xpmac compat stuff).
This is easily fixed by copy&pasting code from another driver, I'll have
a fix for this in bk tonight

 - More annoying: I couldn't get XF4 to work on the Pismo with this
kernel. I tried with or without aty128fb in the kernel, I tried XF4 with
the plain fbdevhw driver, with the r128 driver without fbdev, and with
the r128 driver on top of fbdev, and all I could get is a hung XFree on a
black screen (I found no way to get the screen back with a console, but
the machine still answer to telnet).
The exact same XF4 binary works nicely on 2.2

Ben.


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

Re: Going from 2.2.12 to 2.2.17pre10

[Geert Uytterhoeven]

On Wed, 12 Jul 2000, Benjamin Herrenschmidt wrote:
> >Well, some (control/platinum/valkyrie) will keep on using OF probing since
> >they're used on PowerMac only. But their initialization routine will no
> longer
> >be called by offb.
> >
> >Prepare to see an (untested, as usual :-) patch for this RSN...
>
> BTW. I didn't look in details yet what's wrong, but I noticed that with
> the current bk 2.4test3:
>
>  - video=ofonly doesn't work. We need to find some kludge to get this one
> back, as it's useful on some setup with broken video (and can be the only
> way to get the machine up)

I don't have the bk tree here at hand. Where is the check for `video=ofonly'?
In Linus' tree it's in offb. So the kernel argument should be
`video=offb:ofonly'.

It also depends on the frame buffer device you are using. Atyfb, aty128fb and
matroxfb are initialized before offb (controlfb etc. will be soon), so ofonly
can't work for these. There's one exception: if you have any `video=offb[:*]'
before any other video options, offb will be initialized first (through
pref_init_funcs[] in fbmem.c). Thanks to the resource management system, all
cards used by offb will be marked busy and e.g. atyfb will no longer try to use
the card.

Now my question: exactly what does BootX pass to the kernel if you specify `no
video driver', and where (before or after the other kernel arguments)?

If it passes `video=offb:ofonly' (or plain `video=offb') before any other
options, it should still work fine.
If it passes `video=ofonly', you need to add a test to video_setup() in
fbmem.c to move the initfunc for offb to the top of pref_init_funcs[] if that
option is specified.

Gr{oetje,eeting}s,

						Geert

P.S. Sorry, my patch is delayed until this evening.

--
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/

Re: Going from 2.2.12 to 2.2.17pre10

[Timothy A. Seufert]

At 1:57 PM +0100 7/11/00, Adrian Cox wrote:

>btw: Off topic: which Powerbook uses chipsfb? If they're cheap
>secondhand I'll consider becoming my own guinea-pig for the merged
>driver.

The 2400, 3400, and original G3 (the one that looks just like a
3400).  The 2400 and 3400 have a 65550 with 1MB VRAM, the G3 has a
65554 with 2MB VRAM.

The cheapest of these would be the 3400, but it won't come that
cheap.  The 2400 is the coolest one IMO because it was the last
subnotebook Apple made, and can be upgraded to G3 (if you can still
locate an upgrade card for a reasonable price that is).  However the
2400 is more expensive than it should be precisely because it was the
last subnotebook Apple made.

   Tim Seufert

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

Re: Going from 2.2.12 to 2.2.17pre10

[Matt Porter]

On Tue, Jul 11, 2000 at 10:37:11AM +0100, Adrian Cox wrote:
>
> Matt Porter wrote:
> > Back to original point, I'm not against using a residual data or
> > device tree if it doesn't have to have dozens of fixups applied.
> > I just don't see that coming out of the proprietary hardware/software
> > houses to use their broken data...
>
> Residual data is useful for things like finding the memory size, and for
> chips designed inside Apple. For almost everything else Linux already
> contains a device tree, built by PCI probing when the kernel boots^*. I
> don't see much need for a parallel, architecture specific, device tree.

Whoa...you mentioned the key phrase here...it's really only useful or
required for chips design inside Apple where you can't get documentation.
"Residual data" and defined in the PReP spec is only found on PReP systems
where all the hardware is fully documented so it's easy to size the
memory by other means.  It's not that hard to read board registers or
the memory controller setup.

I can see why the Mac folks have to deal with the broken OF device tree.

A architecture specific (PPC) device tree (or residual data, if you will)
would be part of a "standard" OpenSource firmware project.  It's only
use would be to provide information for board bringup, etc.  It has it's
advantages and disadvantages...

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

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

Re: Going from 2.2.12 to 2.2.17pre10

[Gabriel Paubert]

On Wed, 12 Jul 2000, Matt Porter wrote:

> > Residual data is useful for things like finding the memory size, and for
> > chips designed inside Apple. For almost everything else Linux already
> > contains a device tree, built by PCI probing when the kernel boots^*. I
> > don't see much need for a parallel, architecture specific, device tree.
>
> Whoa...you mentioned the key phrase here...it's really only useful or
> required for chips design inside Apple where you can't get documentation.
> "Residual data" and defined in the PReP spec is only found on PReP systems
> where all the hardware is fully documented so it's easy to size the
> memory by other means.  It's not that hard to read board registers or
> the memory controller setup.

Indeed, but there is one thing which is very hard to guess: interrupt
routing (due to the utterly stupid original Intel/IBM design which was
obsolete already before Neanderthal).

Actually very similar boards may have quite different interrupt routing
and break an unsuspecting kernel. I also hate all these tables with magic
values in the kernel (beside the fact that they don't work with
multifunction boards).

> I can see why the Mac folks have to deal with the broken OF device tree.
>
> A architecture specific (PPC) device tree (or residual data, if you will)
> would be part of a "standard" OpenSource firmware project.  It's only
> use would be to provide information for board bringup, etc.  It has it's
> advantages and disadvantages...

For ISA devices and interrupt routing, I consider it a big plus... For PCI
devices just ignore it if present.

	Gabriel.


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

Re: Going from 2.2.12 to 2.2.17pre10

[Matt Porter]

On Thu, Jul 13, 2000 at 01:43:49PM +0200, Gabriel Paubert wrote:
>
>
> On Wed, 12 Jul 2000, Matt Porter wrote:
>
> > > Residual data is useful for things like finding the memory size, and for
> > > chips designed inside Apple. For almost everything else Linux already
> > > contains a device tree, built by PCI probing when the kernel boots^*. I
> > > don't see much need for a parallel, architecture specific, device tree.
> >
> > Whoa...you mentioned the key phrase here...it's really only useful or
> > required for chips design inside Apple where you can't get documentation.
> > "Residual data" and defined in the PReP spec is only found on PReP systems
> > where all the hardware is fully documented so it's easy to size the
> > memory by other means.  It's not that hard to read board registers or
> > the memory controller setup.
>
> Indeed, but there is one thing which is very hard to guess: interrupt
> routing (due to the utterly stupid original Intel/IBM design which was
> obsolete already before Neanderthal).

Not just hard to guess...impossible.  That's one piece of board specific
information that you must provide somewhere.  The PReP port provides it
in a table as you know...all firmware has tables for each board's local
bus that is supported.  Although many of those tables are incorrect,
the information is public and it can be fixed (I just found some errors
in the Utah map since I have one of those at home).

> Actually very similar boards may have quite different interrupt routing
> and break an unsuspecting kernel. I also hate all these tables with magic
> values in the kernel (beside the fact that they don't work with
> multifunction boards).
>
> > I can see why the Mac folks have to deal with the broken OF device tree.
> >
> > A architecture specific (PPC) device tree (or residual data, if you will)
> > would be part of a "standard" OpenSource firmware project.  It's only
> > use would be to provide information for board bringup, etc.  It has it's
> > advantages and disadvantages...
>
> For ISA devices and interrupt routing, I consider it a big plus... For PCI
> devices just ignore it if present.

If only we could kill off ISA...I about passed out when I got a newly
designed PPC750 CPCI board with an Acer Labs PCI-ISA bridge. :-/

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

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

Re: Going from 2.2.12 to 2.2.17pre10

[Michael Lundkvist]

Matt Porter <mmporter@home.com> writes:

> >
> > Getting those changes into PPCBUG would be great.
>
> All you need is a big customer of MCG's to push them to do it.  Money
> is a powerful motivator.
>
OK. Then I'll try the official channels. Is there a name for these
changes so that people know what I'm asking for?

> > How board specific is the residual data that Bugboot needs?
>
> For the single processor boards, the only thing used for the prep port
> is the memory sizing information.  You can always hack that or fix
> the kernel to get memory size from the board registers or VPD (in the
> case of the MVME2400 and later boards).
>

OK. I'll look into that after my vacation.

> > Would it be possible to make one image for 2300 cards and one for 2400
> > cards or does memory size affect the residual data?
>
> See above, you could make a lowest common denominator version of the
> data and lose some memory.  Honestly, I'd just hack the kernel...PPCBUG
> and residual data are a horrible burden.  Look through prep_* and
> mm/init.c for every place residual data is used and hardcode for your
> MCG boards.  In init.c, prep_find_end_of_memory() can detect a Raven
> bridge then use the documented board registers to identify memory size
> (see online user manual).  A 2400 puts memory size across the I2C bus
> in a EEPROM containing all sorts of useful information.  Bug MCG to get
> specs on the layout of these VPD records.
>

Good. That doesnt sound *too* difficult. Thanks for the info.

/Micke

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

Re: Going from 2.2.12 to 2.2.17pre10

[Matt Porter]

On Wed, Jul 12, 2000 at 02:52:23PM +0200, Michael Lundkvist wrote:
> Matt Porter <mmporter@home.com> writes:
> > >
> > > Getting those changes into PPCBUG would be great.
> >
> > All you need is a big customer of MCG's to push them to do it.  Money
> > is a powerful motivator.
> >
> OK. Then I'll try the official channels. Is there a name for these
> changes so that people know what I'm asking for?

The "PReP residual data ROMBOOT" changes...or something like that.

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

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

Re: Going from 2.2.12 to 2.2.17pre10

[Gabriel Paubert]

On Sat, 8 Jul 2000, Matt Porter wrote:

>
> On Thu, Jul 06, 2000 at 07:32:49PM +0200, Michael Lundkvist wrote:
> >
> > Gabriel Paubert <paubert@iram.es> writes:
> > > Under 2.2.12 dd if=/dev/hda of=xxx bs=512 count=1 and see what comes out.
> > > Can PPCBUG actually boot from these disks ?
>
> PPCBUG expects a little endian partition table, so no.

Ok, my queston was rather: does PPCBUG have support for generic IDE
interfaces or not ?

> I really have to recommend against that.  Once Ramix sees the icky PPCBUG
> code they will hate as much as I do.  I gave well documented changes to
> the PPCBUG guys so that BUGBOOT wasn't needed to boot a kernel from
> FLASH on a PowerPlus board but they haven't incorporated those changes
> after a full year now. :)

The other change I would like to see in PPCBUG is that it complies with
the documentatioon that claims that its services will work when the MMU is
enabled. At least on 603e it does not work since it sets the MSR IP bit
and then silently crashes in the TLB handlers. I doubt that this would
work on a 604 or a 750 either (I did not test it), but if you get an ISI
or DSI exception, you are probably screwed too.

If people volunteer to write a new MVME bootrom from scratch (or a working
OF), I shall be the first in line to get it and flash it in my boards.
ppc*BUG* deserves its name, at least the second part :-(

	Regards,
	Gabriel.

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

Re: Going from 2.2.12 to 2.2.17pre10

[Matt Porter]

On Mon, Jul 10, 2000 at 02:12:08PM +0200, Gabriel Paubert wrote:
>
>
> On Sat, 8 Jul 2000, Matt Porter wrote:
>
> >
> > On Thu, Jul 06, 2000 at 07:32:49PM +0200, Michael Lundkvist wrote:
> > >
> > > Gabriel Paubert <paubert@iram.es> writes:
> > > > Under 2.2.12 dd if=/dev/hda of=xxx bs=512 count=1 and see what comes out.
> > > > Can PPCBUG actually boot from these disks ?
> >
> > PPCBUG expects a little endian partition table, so no.
>
> Ok, my queston was rather: does PPCBUG have support for generic IDE
> interfaces or not ?

Do you mean standard PCI IDE interfaces as in the PCI spec addon?  I'm
pretty sure that the init code doesn't put the onboard controllers in
native mode so the Ramix controller on the bus will need massaged to
get into native mode so it can relocated safely in I/O space.  So,
the answer is no.

> > I really have to recommend against that.  Once Ramix sees the icky PPCBUG
> > code they will hate as much as I do.  I gave well documented changes to
> > the PPCBUG guys so that BUGBOOT wasn't needed to boot a kernel from
> > FLASH on a PowerPlus board but they haven't incorporated those changes
> > after a full year now. :)
>
> The other change I would like to see in PPCBUG is that it complies with
> the documentatioon that claims that its services will work when the MMU is
> enabled. At least on 603e it does not work since it sets the MSR IP bit
> and then silently crashes in the TLB handlers. I doubt that this would
> work on a 604 or a 750 either (I did not test it), but if you get an ISI
> or DSI exception, you are probably screwed too.

:)
> If people volunteer to write a new MVME bootrom from scratch (or a working
> OF), I shall be the first in line to get it and flash it in my boards.
> ppc*BUG* deserves its name, at least the second part :-(

There's a few different bootrom projects in fairly early stages and
lots of interest from various embedded Linux parties since many
board manufacturers don't have anything more than VxWorks BSPs for
their hardware and now want Linux support.  I'm predicting that you'll
see some usable GPL bootrom frameworks/code come out of this need in
the near future.  I swear I saw a free OF project forming somewhere
too.

I agree on that last part, it is buggy and impossible to maintain due
to it's poor design.  It's a true testament to the failure of rushed
proprietary software.

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

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

Re: Going from 2.2.12 to 2.2.17pre10

[Gabriel Paubert]

On Mon, 10 Jul 2000, Matt Porter wrote:

> > Ok, my queston was rather: does PPCBUG have support for generic IDE
> > interfaces or not ?
>
> Do you mean standard PCI IDE interfaces as in the PCI spec addon?  I'm
> pretty sure that the init code doesn't put the onboard controllers in
> native mode so the Ramix controller on the bus will need massaged to
> get into native mode so it can relocated safely in I/O space.  So,
> the answer is no.

Thanks, this anwers my question.

> > The other change I would like to see in PPCBUG is that it complies with
> > the documentatioon that claims that its services will work when the MMU is
> > enabled. At least on 603e it does not work since it sets the MSR IP bit
> > and then silently crashes in the TLB handlers. I doubt that this would
> > work on a 604 or a 750 either (I did not test it), but if you get an ISI
> > or DSI exception, you are probably screwed too.
>
> :)

Actually I think that the only way it will work is if everything that
PPCBUG accesses is mapped with BATs. But I chose not to use BATs for
simplicity in PrePboot.

> > If people volunteer to write a new MVME bootrom from scratch (or a working
> > OF), I shall be the first in line to get it and flash it in my boards.
> > ppc*BUG* deserves its name, at least the second part :-(
>
> There's a few different bootrom projects in fairly early stages and
> lots of interest from various embedded Linux parties since many
> board manufacturers don't have anything more than VxWorks BSPs for
> their hardware and now want Linux support.  I'm predicting that you'll
> see some usable GPL bootrom frameworks/code come out of this need in
> the near future.  I swear I saw a free OF project forming somewhere
> too.

I would swear it too, but I've lost the pointers.  Actually I thought of
adding more early init code to prepboot (towards which I'm understandably
biased) to get something of this kind running, but I don't have the time.

	Regards,
	Gabriel.


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