From owner-freebsd-stable Tue Feb 13 08:31:38 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA20950 for stable-outgoing; Tue, 13 Feb 1996 08:31:38 -0800 (PST) Received: from Sysiphos (Sysiphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id IAA20941 for ; Tue, 13 Feb 1996 08:30:51 -0800 (PST) Received: by Sysiphos id AA09319 (5.67b/IDA-1.5 for freebsd-stable@freebsd.org); Tue, 13 Feb 1996 17:30:13 +0100 Message-Id: <199602131630.AA09319@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Tue, 13 Feb 1996 17:30:13 +0100 In-Reply-To: "Justin T. Gibbs" "Re: One problem && one question" (Feb 13, 8:10) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: "Justin T. Gibbs" Subject: Re: One problem && one question Cc: Richard J Kuhns , freebsd-stable@freebsd.org Sender: owner-stable@freebsd.org Precedence: bulk On Feb 13, 8:10, "Justin T. Gibbs" wrote: } Subject: Re: One problem && one question } >On Feb 13, 9:39, Richard J Kuhns wrote: } >} Subject: Re: One problem && one question } >} Justin T. Gibbs writes: } >} > Patch round two: } >} } >} Sorry, still no cigar. I rebooted this machine several times this morning, } >} trying to copy the boot messages. I guess I'd better set up a minimal } >} configuration to test this so the bt messages will remain on-screen. } >} } >} At any rate, I believe it looked like: } >} } >} int a irq 10 pci 0:13 } >} mapreg[10] type 1 addr 0x00006000 size ffff0004 } >} bt0: Invalid base address } > } >The region size calculation seems broken! } } The driver only cares about the I/O port, which isn't reported above. I've } seen boot -v output from bt946 cards before, and they at least report a } sane I/O port address like 0x330 (when listed as a device without a driver) The BIOS is free to assign any port address, and 0x330 seems to be reasonable to emulate the ISA version of the card ... } - never looked at the size, but it should be 4. I wouldn't bother hacking } up the memory size calculation just for this card since we won't even use } it. I just sent him an updated patch, that corrects some mistakes I made The PCI code uses it as a parameter to the pci_map_io() call, but since this is not about VM, it doesn't have much of an effect ... } in the last one, but I did notice something odd in the PCI code: } } if (bootverbose) { } for (reg=PCI_MAP_REG_START; regpb_read (tag, reg); } if ((data&~7)==0) continue; } switch (data&7) { } } case 1: } case 5: } printf (" map(%x): io(%lx)\n", } reg, data & ~3); } break; } } I guess that everything must be quad-word aligned so that is why you } & ~3? Is this in the spec even for I/O ports? In PCI there are a number of map types, and those are encoded in those (assumed to be '0') bits. I.e. the type 1 encoding has a '01' in the two low order bits, which have to be masked out ... The problem with the wrong size being reported is caused by the fact, that the bt946c has only a 16 bit port base register. And for this reason, it returns 0x0000fffd if a 0xffffffff had been written ... The 'd' is a 'c' (i.e. -4) plus the mapping type 1 code. Since the PCI spec defines type 1 as a 32bit I/O port mapping (IIRC) the 946 really should return 0xfffffffd. It has no right to ignore the upper 16bits. But since ISA only supports 16 bits of port address anyway, it doesn't appear to make much of a difference to make the code always ignore those upper half for port mappings ... Regards, STefan -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/~se