Date: Wed, 09 Jan 2013 22:15:03 +0100 From: Andreas Longwitz <longwitz@incore.de> To: Hans Petter Selasky <hselasky@c2i.net> Cc: freebsd-isdn@freebsd.org Subject: Re: ISDN4BSD (HPS version) is going into ports Message-ID: <50EDDDD7.2000006@incore.de> In-Reply-To: <201301091015.39124.hselasky@c2i.net> References: <509E87EF.9070607@incore.de> <201212021043.53151.hselasky@c2i.net> <50ECAEBB.3030604@incore.de> <201301091015.39124.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hans Petter Selasky wrote:
>>
>> --- i4b_filter.h.orig 2009-01-09 20:07:38.000000000 +0100
>> +++ i4b_filter.h 2013-01-08 18:23:01.000000000 +0100
>> @@ -158,6 +158,12 @@
>> (f->buf_len) -= (io_len);
>> (f->Z_chip) -= (io_len);
>>
>> + /* Hack: <AVM Fritz!Card version 2 PCI> is ihfc1 */
>> + if((FIFO_NO(f) == d1r) && sc->sc_nametmp[4] == '1' ) {
>> + (f->buf_ptr) -= 1;
>> + (f->buf_len) += 1;
>> + }
>> +
>> return;
>> }
>
> Can you try the attached patch instead? And revert the one above?
Yes I did, but no success in eliminating the superfluous byte at the end
of every incoming D-channel frame, isdntrace gives one line
L3 04 AE 10101110 Protocol = Other Layer 3 or X.25 (0xae)
after every L2 frame and
L3 0C AE 1------- Single octet Information element
10101110 UNKNOWN single octet IE = 0xae
if an L3 frame occurs.
Your patch seems to fiddle something in the chip in contrast to my
i4b_filter.h hack.
>> I have analyzed the i4b_ifpi2_pci.c source from FreeBSD 6 (nearly
>> identical to the NetBSD source ifpci2.c) and found that your patch
>> brings us a step forward to the way the BSD-source ifpci2.c works.
>> But there are some more differences between isdn4bsd and BSD:
>>
>> 1. Access to the PCI bus via mem in isdn4bsd, via I/O port in BSD.
>> 2. DELAY times on startup is different: 4 ms in isdn4bsd, 10 ms in BSD
>> 3. Initializing the chip is more expansive in BSD, otherwise the
>> register cmdrd is only used in isdn4bsd.
>> 4. In avm_pci_fifo_reset() we write two single bytes, but BSD does one
>> (atomic) four byte read. Particularly we do not write the HSCX_LEN
>> byte between the both written bytes (must set to 0 ?)
>> 5. In avm_pci_b_status_read() - analog to 4. - we read two single bytes,
>> BSD (atomic) four bytes.
>> 6. After an interrupt BSD checks explicit HSCX_INT_MASK before working,
>> Afterwords the use of HSCX_INT_RPR and HSCX_INT_XPR seems a little
>> bit different to me.
>> 7. isdn4bsd and BSD both set HSCX_MODE_TRANS at startup, but BSD changes
>> this to HSCX_MODE_ITF_FLAG (ITF: interframe time fill) at the moment
>> a B-channel is coming up. Simultaneously the HSCX_CMD_RRS bit is
>> dropped (RRS = ?).
>
> There is no specific reason. Some of this programming was guessed based on
> other drivers and common thinking in this area.
>
> Please fix if something is wrong. However, note that my driver only uses
> transparent mode and HDLC emulation. This makes the driver much simpler.
I try to understand what you mean - for B-channels - exactly with terms
"transparent mode" and "HDLC emulation". I have b1protocol=hdlc in the
file isdnd.rc and isdnd sets up the B-channel with P_HDLC (=1). If I
activate the first MSG in ihfc_B_setup() I get
i4b-L1 ihfc1: ihfc_B_setup: fifo(#2/#3), protocol_1=1.
I introduced the following debug patch in i4b_avm_pci.h:
@@ -253,13 +291,16 @@
(f+receive)->i_ista &= ~(I_ISTA_RPF|I_ISTA_ERR);
temp = bus_space_read_1(t, h, offset + HSCX_LEN) & 0x3F;
- if(temp == 0) temp = 32;
+ if (bootverbose) {
+ IHFC_ERR("HSCX_LEN=%d, protocol_1=%d\n", temp,
f->prot_curr.protocol_1);
+ }
+ if(temp == 0) temp = 32;
/* read FIFO */
and get - the other side sends ppp frames -
i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=32, protocol_1=1
i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=32, protocol_1=17
i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=32, protocol_1=17
i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=32, protocol_1=17
i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=32, protocol_1=17
i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=32, protocol_1=17
i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=32, protocol_1=17
i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=32, protocol_1=17
i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=32, protocol_1=17
i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=32, protocol_1=17
i4b-L1 ihfc1: avm_pci_b_status_read: HSCX_LEN=0, protocol_1=17
and nothing more. After the first read P_HDLC changed to P_HDLC_EMU_D
(=17), is this correct and where this is done ?
No more data after HSCX_LEN=0. My vision of "transparent mode" of a
B-channel was that we have to handle a 64kbit data stream all the time,
seems to be wrong ?
--
Andreas Longwitz
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50EDDDD7.2000006>