Re: Going from 2.2.12 to 2.2.17pre10

Gabriel Paubert [off-list ref] 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/

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).

quoted

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/