On Tuesday, November 14, 2017 at 12:10 AM, Jeremy Begg wrote: > >On Monday, November 13, 2017 at 2:04 AM, Jeremy Begg wrote: > >> I am trying to get SIMH up and running on the ethernet interface of a > >> Raspberry Pi 3. I have followed the intructions in 0readme_ethernet.txt, > >> installing the libpcap-dev, bridge-utils and uml-utilities packages before > >> building SIMH itself. I just ran 'make vax' and let it go, and the build > >> to > >> completion. > >> > >> My problem is that I just can't get networking going. To cut to the > >> chase, if > >> I run the simulator without first setting up the br0 and tap0 interfaces, > >> and > >> don't attempt to attach the XQ device, it works fine -- albeit without any > >> networking (as expected). > >> > >> If I configure SIMH to attach XQ directly to the Pi's eth0 interface > >> (without > >> configuring br0/tap0) it works on the first run but fails selftest > >> 53 on the next run. If I reboot the Pi and start the br0/tap0 interfaces > >> and > >> then run the simulator the VAX console fails selftest 53 again. > > > > > >Hmm... I've been trying to track down the 53 test failure, which I can't > >reproduce here. > > > >In general this should not have anything to do with the networking details > >you've got setup, but there might be some influence. > > I think I have found the cause. Yesterday Wilm pointed out that his > configuration did NOT require the tap0 interface to be assigned an IP > address by the host system, and Steve Mansfield-Device's blog is the > only place I've found that suggested this requirement. > > It occurred to me after I reported it was working that I had in fact made > TWO changes: the successful boot did NOT connect the NVR. Trying again > just > now, with no IP address assigned to "tap0" and no NVR configured, the VAX > boots quite happily with a working network interface. > > Mark, thank you for the detailed explanation about the failed selftest, but > I fear it's in vain. I suspect it's just a corrupt NVR file instead. So I > won't try the alternative ka655x.bin (unless you still think it might be > helpful to do so).
The goal is to remove the possibility of having any self test errors. Not having an NVR attached merely starts things with a zeroed NVR. This is a completely normal case and is exactly how I tested on my systems successfully hundreds of times. PLEASE see if you can reproduce a failure and then see if the different ROM Image fixes it by following the steps I listed below. Thanks. - Mark > >A little background explanation is warranted here. Long ago, when the > >extended memory was added to the MicroVAX 3900 simulator (extending > from > >64MB to 512MB), I had observed that boot ROM self test interval timer test > >intermittently failed (1 out of 10 times). At the time, I attributed the > >failures to competing load on the host system while the timer test was > >running. To avoid potential problem reports from users the interval timer > >tests were disabled with a patch to the ROM image. The resulting > KA655x.bin > >image was unmodified until this past January. At that time, the timer > >related plumbing in simh was significantly reworked and it seemed like the > >ROM self tests should now pass without the need to side step them. I > >re-enabled the tests and, in my testing I've run many hundreds of tests > >without failure, meanwhile there have been some reports like yours... :-( > > >Since you've got a somewhat reproducible test 53 failure, will you please: > > >1) send me the configuration file you're loading > >2) send me the ka655x.bin or ka655.bin file you may be loading in your > configuration file > >3) explicitly load the attached ka655x.bin file prior to booting the > >simulator > in your configuration file with: > > sim> load -r ka655x_test.bin > > sim> BOOT (or BOOT CPU) > >4) let me know if you still can observe the self test problems you had > previously seen. > > >If the problem is completely solved, then I'll revise the packaged (and > >internal) ka655x.bin ROM image and these problems should be behind us. If > >the problem persists, then I'll have to look for other ways to address it. > > >Thanks. > > >- Mark _______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
