Bug#45694: Bug#47225: MVME162FX Rescue Disc Boot fails
Bill,
> Thanks for the reply, I've been afraid this would drop off in a dark hole
as
> my prior bug has (#45694).
Sorry about #45694, but the notification e-mail from the bug tracking system
seems to have gone astray :-(.
> I'm somewhat confused about your statements regarding Bug usage of DRAM.
> Bug always uses 0-10000 for its own purposes and the addresses you list
> (FFE0 0000 to FFE1 0000) are for SRAM ...
I have looked at the kernel sources to confirm what I was saying, the Bug
MUST be configured to use the SRAM as its workspace on the MVME162 and
MVME172. This appears not to be your problem with Bug#47225 but is almost
definitely your problem with tftplilo (Bug#45694). The reason being that the
Linux kernel must be loaded at the bottom of memory address 0x1000 upwards.
During the 162 and 172 kernel's initialisation phase it makes several calls
to the Bug to identify the board type and to output the familiar ABCDFJLMN
initialisation progress indication. If as in your case the Bug workspace is
at address 0 it will have been overwritten by the kernel and the Bug will
crash when it is called.
> In any case tried the tracing route and the results are attached. Appears
> to me that there's a wild branch at 20056; the contents of DRAM from 10000
> to 15fff are zeros.
As for Bug#47225, it looks like you have a bad floppy disk image the IPL
code which you have traced through is doing the correct thing, except it
appears to loading empty sectors instead of the kernel boot loader. You
could prove this by filling the memory at address 0x10000 with a pattern
before tracing the IPL code. I would suggest that you try to rewrite your
floppy disk, perhaps obtaining the image from a different source e.g.
ftp://ftp.debian.org/debian/dists/slink/main/disks-m68k/current/mvme162/resc
1440.bin
Please let me know how you get on.
Nick
---------------------------------------------
Nick Holgate <holgate@debian.org>
PGP key from public servers : Key ID DF3E8223
Reply to: