RE: Trouble Floppy Booting an MVME167
> When I enter BH (boot halt) at the bug prompt and then trace, I
> see some code that contains a "SYSCALL .DSKRD". Following this
> floppy disk access is a branch statement that probably leads to a
> successful boot. The trace fails to take this branch and loops
> back and repeats (including the "SYSCALL .DSKRD"). On a third
> loop, before the "SYSCALL .DSKRD", it branches to $10000 where
> memory is zero-filled.
This chunk of code is actually trying to load the second stage kernel
loader (the thing that display the LILO prompt), each time round the
loop it is loading a fragment of the file. In this case the file has 2
fragments the third iteration detects the end of the fragment list.
Using the "Woody" rescue.bin as an example, the first 256 bytes of the
image is the IPL code loaded by the Bug, and looks like this:
0000: 00 02 10 00 00 00 00 22 00 00 00 00 00 00 00 00
0010: 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 02
0020: 00 00 48 E7 FF FE 4B FA FF EA 28 4D 18 C1 18 C0
0030: 4D FA 00 64 20 7C 00 01 00 00 32 1E 67 32 24 1E
0040: 66 0C ED 49 60 02 20 C2 51 C9 FF FC 60 EC 49 ED
0050: 00 02 42 5C 28 C8 28 C2 38 C1 42 54 48 55 4E 4F
0060: 00 10 4A 6D 00 02 66 10 ED 49 41 F0 14 00 60 CA
0070: 2F 0F 4E B9 00 01 00 00 4E 4F 00 63 4C DF 7F FF
0080: 60 A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0090: 00 00 00 00 00 00 00 30 00 00 0B A0 00 3C 00 00
00A0: 0B D4 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00F0: 4C 69 6E 75 78 36 38 6B 4D 4F 54 4F 52 4F 4C 41
typedef struct {
unsigned long sp; // 00 initial stack pointer
unsigned long pc; // 04 initial program counter
char filler1[12]; // 08
unsigned long boot_start_block; // 14 boot file start block addr
unsigned short boot_block_count; // 18 number of blocks in file
char filler2[4]; // 1a
unsigned long boot_load_addr; // 1e
char boot_code[110]; // 22 IPL code
unsigned long cfg_block; // 90 config data start block
unsigned char cfg_count; // 94 config data block count
char filler3[1]; // 95 word align frag_list
char frag_list[90]; // 96 loader file fragment list
char boot_id[16]; // f0 id string "Linux68kMOTOROLA"
} BOOTBLOCK;
Offset 0000 is the stack pointer (00021000).
Offset 001e is the load address (00020000).
Offset 0004 is the execution offset (00000022)
Offset 0096 is the start of the fragment list a word specifying the
number of 256 byte blocks to load followed by a long word block number.
A zero block count marks the end of the list:
0096: 0030 0000BA0
009C: 003C 0000BD4
0102: 0000
The fragments are transferred into memory starting at address 10000, the
first fragment should look like this:
000B A000 60 FF 00 00 1D F8 00 00 48 E7 38 30 24 6F 00 18
000B A010 26 2F 00 1C 42 82 20 79 00 01 65 8A 21 42 16 DE
000B A020 47 F9 00 01 4B 64 60 00 01 2C 70 0A B0 81 67 30
000B A030 6D 12 78 08 B8 81 67 52 70 09 B0 81 67 00 00 98
000B A040 60 00 00 D2 78 1B B8 81 67 64 6D 0A 70 0D B0 81
000B A050 67 0E 60 00 00 C0 78 7F B8 81 67 2E 60 00 00 B6
000B A060 22 79 00 01 65 8A 41 E9 00 30 42 30 28 00 20 0A
...
> I have tried different floppy diskettes, and both the potato and
> woody rescue.bin images created using rawrite2.
> All results appear the same. Does anyone have any helpful suggestions?
It would appear that either:
1. The floppy disk contains only part of the rescue.bin image (the first
sector seems to have been loaded correctly by the Bug).
2. The 'Bug' is failing to read sectors and not telling the IPL code.
3. IPL code is broken for floppy disks (I've never actually tried a
floppy drive on an MVME machine).
> I have noted the D4 register is 49504C2C, but Motorola BO
> documentation indicates it should be 49504C0C.
> The documentaion states the 0C at the end indicates "TRAP #15
> support with stack parameter passing TRAP #15 disk support".
> I don't know whether this is significant, but thought I'd mention
> it. Perhaps the bit set by the 2 is not relevant.
I have no idea.
Nick
---------------------------------------------------------------
Contact : Nick Holgate <holgate@debian.org> ICQ #117649207
Home Page : http://people.debian.org/~holgate
GPG key : http://people.debian.org/~holgate/pubkey.txt
Fingerprint: 9DCA EDEA D5C5 57DA 23F3 1A2B 2273 5645 FD9C 18AF
Reply to: