Re: Netbsd & PC532 ... moving in small steps

To: Jon Buller <jon%bullers.net@localhost>
Subject: Re: Netbsd & PC532 ... moving in small steps
From: Matthias Pfaller <leo%marco.de@localhost>
Date: Tue, 16 Feb 2010 15:17:56 +0100
> udo.a.moeller%web.de@localhost wrote:
>> Hi Jon,
>>
>> a dumpster is definitly not the right place for a good old piece of
>> computer hardware ... I have some space available for it if you really
>> want to dump it.
>>
>> There was a bug in the SCSI emulation in my FPGA. Now it continues a
>> little bit further :
>>
>>
>> NS32000 ROM Debugger
>> Version: Wed Nov 13 21:45:02 1991
>> Auto-boot enabled.
>> RAM free above 0x130c
>>
>> Command (? for help): download 260000
>> CRC ok, length = 1474560
>> Command (? for help): run 3BE020
>>
>>>> NetBSD/pc532 Boot, Revision 1.1
>>>> (jon%bullbox.bullers.net@localhost, Wed Jun 19 21:11:10 PDT 2002)
>> Boot: [[[sd0a:]netbsd][-abds]] :- md0a:/netbsd.gz
>> 688128+2125824+134232 total=0x2d1c5c
>>
>> Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001
>>     The NetBSD Foundation, Inc.  All rights reserved.
>> Copyright (c) 1982, 1986, 1989, 1991, 1993
>>     The Regents of the University of California.  All rights reserved.
>>
>>
>> NetBSD 1.5.3_RC1 (INSTALL) #0: Wed Mar 13 23:28:17 PST 2002
>>     jon%bullbox.bullers.net@localhost:/usr/src/sys/arch/pc532/compile/INSTALL
>> total memory = 8192 KB
>> avail memory = 4568 KB
>> using 128 buffers containing 512 KB of memory
>> mainbus0 (root)
>> clock0 at mainbus0 addr 0xfffffe00, irq 2
>> ncr0 at mainbus0 addr 0xffd00000, irq 4
>> scsibus0 at ncr0: 8 targets, 8 luns per target
>> zero=fffcbfeb, bio=4010, net=34010, tty=34010, clock=34014, imp=34010,
>> softclock=fffdffeb, softnet=34000
>> scsibus0: waiting 2 seconds for devices to settle...
>> sd0 at scsibus0 target 0 lun 0: <UMoeller, V-SCSI Harddisk, V1.0>
>> SCSI2 0/direct fixed
>> sd0: 81920 KB, 5120 cyl, 2 head, 16 sec, 512 bytes/sect x 163840 sectors
>> sd1 at scsibus0 target 0 lun 1: <UMoeller, V-SCSI Harddisk, V1.0>
>> SCSI2 0/direct fixed
>> sd1: could not mode sense (4/5); using fictitious geometry
>> sd1(ncr0:0:1): could not get size
>> sd1: 0, 0 cyl, 64 head, 32 sec, 512 bytes/sect x 0 sectors
>> sd2 at scsibus0 target 0 lun 2: <UMoeller, V-SCSI Harddisk, V1.0>
>> SCSI2 0/direct fixed
>> sd2: could not mode sense (4/5); using fictitious geometry
>> sd2(ncr0:0:2): could not get size
>> sd2: 0, 0 cyl, 64 head, 32 sec, 512 bytes/sect x 0 sectors
>> sd3 at scsibus0 target 0 lun 3: <UMoeller, V-SCSI Harddisk, V1.0>
>> SCSI2 0/direct fixed
>> sd3: could not mode sense (4/5); using fictitious geometry
>> sd3(ncr0:0:3): could not get size
>> sd3: 0, 0 cyl, 64 head, 32 sec, 512 bytes/sect x 0 sectors
>> sd4 at scsibus0 target 0 lun 4: <UMoeller, V-SCSI Harddisk, V1.0>
>> SCSI2 0/direct fixed
>> sd4: could not mode sense (4/5); using fictitious geometry
>> sd4(ncr0:0:4): could not get size
>> sd4: 0, 0 cyl, 64 head, 32 sec, 512 bytes/sect x 0 sectors
>> sd5 at scsibus0 target 0 lun 5: <UMoeller, V-SCSI Harddisk, V1.0>
>> SCSI2 0/direct fixed
>> sd5: could not mode sense (4/5); using fictitious geometry
>> sd5(ncr0:0:5): could not get size
>> sd5: 0, 0 cyl, 64 head, 32 sec, 512 bytes/sect x 0 sectors
>> sd6 at scsibus0 target 0 lun 6: <UMoeller, V-SCSI Harddisk, V1.0>
>> SCSI2 0/direct fixed
>> sd6: could not mode sense (4/5); using fictitious geometry
>> sd6(ncr0:0:6): could not get size
>> sd6: 0, 0 cyl, 64 head, 32 sec, 512 bytes/sect x 0 sectors
>> sd7 at scsibus0 target 0 lun 7: <UMoeller, V-SCSI Harddisk, V1.0>
>> SCSI2 0/direct fixed
>> sd7: could not mode sense (4/5); using fictitious geometry
>> sd7(ncr0:0:7): could not get size
>> sd7: 0, 0 cyl, 64 head, 32 sec, 512 bytes/sect x 0 sectors
>> md0: internal 2048K image area
>> boot device: <unknown>
>> root on md0a dumps on md0b
>> WARNING: bad date in battery clock -- CHECK AND RESET THE DATE!
>> root file system type: ffs
>>
>> ++++++++++++++++++++++++++++++
>>
>> The only action after the last message is the timer interrupt every
>> second. Do you know what should come next ?
>> What is meant by the WARNING : bad date in battery clock ? As far as I
>> know there is no real-time clock chip in the PC532.
>> Do you have an explenation for the line with "zero=... bio=... net=...
>> etc." ?
>>
>> The SCSI device is emulated on the Host. Therefore I can define any
>> device. My current setting is that any LUN other than 0
>> is not accepted. I made a test with the Quantum LPS525S with LUN 0 but
>> it still reports the LUNs from 1 to 7 (see above).
>>
>> Maybe Richard and myself are too optimistic : just emulate the
>> hardware and the software will run without troubles. But
>> first results looked promising and therefore we will not give up.
>>
>> I attached a photo of my CPU card. Dumping is not an option !
>> Regards,
>> Udo

Hi,

the zero=..., bio=..., net=... lines show the interrupt masks for
splzero, splbio, splnet, ...
Do I understand this correctly, you are building a ns32532 cpu core in a
fpga? My pc532 is still in working condition (about 10m away)... At
least it was the last time I tried to boot it. I just tried again and it
does no longer talk to me :-( But it does reset the scsi-bus a couple of
times. Maybe its just the serial driver that's dead.

As jon already wrote, the kernel now should load init and you should get
a prompt asking you for the single user shell.

But I'm missing the probe messages for your serial devices?

NetBSD 1.5.3 (GENERIC) #6: Tue Jul  2 19:53:03 PDT 2002
    jon%bullbox.bullers.net@localhost:/usr/src/sys/arch/pc532/compile/GENERIC
total memory = 8192 KB
avail memory = 6204 KB
using 128 buffers containing 512 KB of memory
mainbus0 (root)
rtc0 at mainbus0 addr 0xfff00000
clock0 at mainbus0 addr 0xfffffe00, irq 2
scn0 at mainbus0 addr 0xffc80000, irq 13, 12: scn2692, flags 1
scn1 at mainbus0 addr 0xffc80008
scn2 at mainbus0 addr 0xffc80010, irq 11, 10: scn2692
scn3 at mainbus0 addr 0xffc80018
scn4 at mainbus0 addr 0xffc80020, irq 9, 8: scn2692
scn5 at mainbus0 addr 0xffc80028
scn6 at mainbus0 addr 0xffc80030, irq 7, 6: scn2692
scn7 at mainbus0 addr 0xffc80038
ncr0 at mainbus0 addr 0xffd00000, irq 4
scsibus0 at ncr0: 8 targets, 8 luns per target
zero=fff8802b, bio=4010, net=34010, tty=76a90, clock=76a94, imp=76a90,
softclock=fff9c02b, softnet=34000
scsibus0: waiting 2 seconds for devices to settle...
sd0 at scsibus0 target 0 lun 0: <SEAGATE, ST3550N, 9416> SCSI2 0/direct
fixed
sd0: 435 MB, 2128 cyl, 5 head, 83 sec, 512 bytes/sect x 891574 sectors
sd1 at scsibus0 target 1 lun 0: <SEAGATE, ST31200N, 8648> SCSI2 0/direct
fixed
sd1: 1006 MB, 2700 cyl, 9 head, 84 sec, 512 bytes/sect x 2061108 sectors
ncr0: unexpected MESSAGE OUT; sending NOOP
ncr0: reset SCSI bus for TID=4 LUN=0
sd2 at scsibus0 target 4 lun 0: <QUANTUM, PD210S   SUN0207, 492W> SCSI2
0/direct fixed
sd2: 199 MB, 1156 cyl, 7 head, 50 sec, 512 bytes/sect x 408574 sectors
st0 at scsibus0 target 5 lun 0: <ARCHIVE, VIPER 150  21247, -005> SCSI1
1/sequential removable
st0: rogue, drive empty
cd0 at scsibus0 target 6 lun 0: <TOSHIBA, CD-ROM XM-3501TA, 3384> SCSI2
5/cdrom removable
boot device: sd0
root on sd0a dumps on sd0b
root file system type: ffs

iirc the kernel does a real probe for the scnX devices (my fault, its
because of the lpt module). I'd bet that scn probe fails with your
emulation:

int
scnprobe(struct device *parent, struct cfdata *cf, void *aux)
{
        struct confargs *ca = aux;
        volatile u_char *ch_base;
        int mr1;

        /* Now some black magic that should detect a scc26x2 channel. */
        ca->ca_addr = SCN_MAP_ADDR(cf->cf_loc[MAINBUSCF_ADDR]);
        ch_base = (volatile u_char *)ca->ca_addr;
        ch_base[CH_CR] = CR_CMD_RESET_ERR;
        RECOVER();
        ch_base[CH_CR] = CR_CMD_RESET_BRK;
        RECOVER();
        ch_base[CH_CR] = CR_CMD_MR1;
        RECOVER();
        mr1 = ch_base[CH_MR] ^ 0x80;
        ch_base[CH_CR] = CR_CMD_MR1;
        RECOVER();
        ch_base[CH_MR] = mr1;
        ch_base[CH_CR] = CR_CMD_MR1;
        RECOVER();
        if (ch_base[CH_MR] != mr1)
                return(0);
        if (ch_base[CH_MR] == mr1)
                return(0);

        ca->ca_irq = cf->cf_loc[MAINBUSCF_IRQ];

        return(1);
}



Regard, Matthias
-- 
Matthias Pfaller                          Software Entwicklung
marco Systemanalyse und Entwicklung GmbH  Tel   +49 8131 5161 41
Hans-Böckler-Str. 2, D 85221 Dachau       Fax   +49 8131 5161 66
http://www.marco.de/                      Email leo%marco.de@localhost
Geschäftsführer Martin Reuter             HRB 171775 Amtsgericht München
References:
- Re: Netbsd & PC532 ... moving in small steps
  - From: Jon Buller
Prev by Date: Re: Netbsd & PC532 ... moving in small steps
Next by Date: Re: Netbsd & PC532 ... moving in small steps
Previous by Thread: Re: Netbsd & PC532 ... moving in small steps
Next by Thread: Re: Netbsd & PC532 ... moving in small steps
Indexes:
Home | Main Index | Thread Index | Old Index