Mouse wrote:
2f0002:
d0 8f 43 00 movl $0x00000043,r2
2f0006: 00 00 52
You could make this three bytes more compact by using movzbl. (If you
were using characters in the 0x00-0x3f range, you could use a short
literal and it'd be only three bytes either way.)
That was for testing purposes only, yes you can see that I know nothing
about VAX Assembler...
This was only the try to execute some code as early as possible to see
that damn thing doing something...
The Startup Code in that Binary is in common/srt0.S where I hacked in this
2 charackter outs, there was nothing before at all. The relocation code was
later and I wasn't interested what it would do since I placed 2 nops and
a halt after the two putchars.
After the mopcopy it worked as it should:
2..1..0..CD
...Halt (or something like this)
>>
Not that that's relevant to your problem.
that 20044f23 is your cons_A_TX w/o that leading
blbc 1001(r11),0x20044f32
(don't know what that bis should do, so I left it aside)
I think that is probably handling for "no console present" or some
such. Most of the console interaction checks it in some form.
Ok, I read something in the rtVAX User Manual about such a console Bit,
than this is it.
Examining the memory at 2f0000 is showing this:
[compacted vertically -Mouse]
P 002F0000 01 01 D0 8F 00 00 2F 00
P 002F0008 5E C3 8F 00 00 2F 00 8F
P 002F0010 5C EA 2F 00 50 9E AF E8
P 002F0018 51 D0 8F 00 00 2F 00 53
P 002F0020 28 50 61 63 C3 8F 5C EA
P 002F0028 2F 00 8F F4 10 30 00 52
P 002F0030 2C 00 63 00 52 63 16 AF
P 002F0038 00 D0 8F 41
I don't have any clue where this is coming
from.
I think I might. This disassembles as
2f0000: nop
2f0001: nop
2f0002: movl $002f0000,sp
2f0009: subl3 $002f0000,$002fea5c,r0
2f0015: movab 0x2f0000,r1
2f0019: movl $002f0000,r3
2f0020: movc3 r0,(r1),(r3)
2f0024: subl3 $002fea5c,$003010f4,r2
2f0030: movc5 $0,(r3),$0,r2,(r3)
2f0036: jsb 0x2f0039
(plus a few leftover bytes which make up only a partial instruction)
which looks to me like "relocate myself to where I expect to be" code
(plus a bit more; the instructions at 2f0024 and 2f0030 are "clear bss"
code). This is probably coming from something in the NetBSD bootblock
build procedure getting linked before your code. This code will
explode if the bootblock size and location are such that the relocation
code in the as-loaded location overlaps something in the as-expected
location; I hesitate to say that's what's behind the behaviour you're
seeing, though.
Yes, but it was still in the memory from tests with that old "mopboot"
file, this wasn't the code I'm tried to download on that rtVAX, the
MOP simply stalled before it got the code loaded b'cause the file format
wasn't the expected Mop Format ... no error message was displayed.
> I'd also take a detailed look (I'm
talking "hexdump -C" level of
> detailed here) at the file being MOP-booted to make sure its
> structure is what you think it is.
It is a netbsd ELF File
That is suspicious to me. It's been a while since I played with MOP,
but I think it doesn't want an executable such as a.out or ELF. Later
messages in the thread make me think that's right, but they also make
me think you've already discovered it, so I don't need to elaborate.
As I already wrote, suspicios to me also, but in NetBSD Distribution the
file format changed w/o any notice, so I tought it may be working.
It where possible to let mopd convert such things on the fly..
Ok, I hacked up that mopcopy from NetBSD (src/usr.sbin/mopd...)
so I could compile it with some hand work (normally integrated in NetBSDs
makefile structure) and I have at least no a working FreeBSD/I386 binary
that is able to build something that boots.. Now the hard work, that
booted NetBSD Loader doesn't do anything, at least I see nothing with
tcpdump, so I have further to investigate what is going on with that SGEC
and the VAX Busses/Adresses/Vectors and such things. At least the SGEC is
supported in the Bootcode as boot/if_ze.c (Standalone routine for the SGEC
Ethernet controller.) Some Timers may work too since I see the countdown
for the autoboot on the Terminal...
Regards,
Holm
--
Technik Service u. Handel Tiffe,
www.tsht.de, Holm Tiffe,
Freiberger Stra?e 42, 09600 Obersch?na, USt-Id: DE253710583
www.tsht.de, info at tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741