Date: Tue, 10 Dec 1996 12:03:59 +1030 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: pst@shockwave.com (Paul Traina) Cc: msmith@atrad.adelaide.edu.au, Andrew.Gordon@net-tel.co.uk, nate@freebsd.org, mobile@freebsd.org, hackers@freebsd.org, pst@jnx.com Subject: Re: need help with a PC CARD NE2000 clone... Message-ID: <199612100134.MAA11963@genesis.atrad.adelaide.edu.au> In-Reply-To: <199612091804.KAA01333@precipice.shockwave.com> from Paul Traina at "Dec 9, 96 10:04:26 am"
next in thread | previous in thread | raw e-mail | index | archive | help
(It made it OK Paul, I just had to go to sleep at some point 8)
> > Note that if this really is an NE2000 clone, it doesn't need any
> > memory address space (the on-card RAM is driven by i/o) - unlike some
> > of the other cards supported by the ed driver.
>
> Yeah, I agree. Why does it have two blocks of memory?
Not entirely sure. It looks like the card might have a boot ROM on it;
I can't find any other justification for this, which is a write-protected
32K region :
> Tuple #1, code = 0x1 (Common memory descriptor), length = 3
> 000: dc 03 ff
> Common memory device information:
> Device number 1, type Function specific, WPS = ON
> Speed = 100nS, Memory block size = 32Kb, 1 units
I can only assume that pccardd is trying to DTRT and map this in somewhere.
> # cat /etc/pccard.conf
...
> # Generally available IO ports
> io 0x240-0x360
> # Generally available IRQs (Built-in sound-card owners remove 5)
> irq 3 5 10 11 13 15
Does your notebook really have all these resources available? (Lots have
onboard peripherals scattered around. I'd have expected the PCIC to be
given IRQ 3...)
> # Available memory slots
> memory 0xd0000 96k (I've tried this at d4000)
Should be plenty of space anyway.
> PC-Card Intel 82365 (5 mem & 2 I/O windows)
> pcic: controller irq 3
As I thought, the PCIC is getting IRQ 3. You will want to remove this
from the list of available IRQs (no, I know this isn't your problem).
> Code 240 not found
> Code 240 not found
> code Unknown ignored
There's a tuple in the card with an unknown (0xf0) code; no idea what it's
supposed to be.
> Breakpoint 1, assign_io (sp=0x19100) at cardd.c:464
> 464 cis = sp->cis;
> (gdb) n
> 465 defconf = cis->def_config;
> (gdb) print *cis
> $1 = {tlist = 0x18160, manuf = "PMX ", '\000' <repeats 13 times>,
> vers = "PE-200", '\000' <repeats 13 times>,
> add_info1 = "ETHERNET", '\000' <repeats 11 times>,
> add_info2 = "R01", '\000' <repeats 16 times>, maj_v = 4 '\004',
> min_v = 1 '\001', last_config = 1 '\001', ccrs = 1 '\001', reg_addr = 256,
> attr_mem = {valid = 1 '\001', type = 5 '\005', speed = 3 '\003',
> wps = 0 '\000', addr = 0 '\000', units = 1 '\001'}, common_mem = {
> valid = 1 '\001', type = 13 '\r', speed = 4 '\004', wps = 1 '\001',
> addr = 0 '\000', units = 3 '\003'}, def_config = 0x1d080, conf = 0x1d080}
> (gdb) n
> 466 for (cisconf = cis->conf; cisconf; cisconf = cisconf->next)
> (gdb) n
> 467 if (cisconf->id == sp->config->index)
> (gdb) print *cisconf
> $2 = {next = 0x0, pwr = 0, timing = 0, iospace = 1, irq = 1, memspace = 1,
> misc_valid = 0, id = 1 '\001', io_blks = 2 '\002', io_addr = 10 '\n',
> io_bus = 2 '\002', io = 0x1a1c0, irqlevel = 0 '\000', irq_flags = 48 '0',
> irq_mask = 48892, memwins = 2 '\002', mem = 0x1a1e0, misc = 0 '\000'}
> (gdb) print *sp
> $3 = {next = 0x19080, fd = 8, mask = 0, slot = 1, name = 0x1a0d0 "/dev/card1",
> state = filled, cis = 0x19180, card = 0x180a0, config = 0x180c0,
> card_config = 0x0, devname = '\000' <repeats 15 times>,
> eaddr = "\000\000\000\000\000", io = {next = 0x0, addr = 0, size = 0,
> flags = 0, cardaddr = 0}, mem = {next = 0x0, addr = 0, size = 0,
> flags = 0, cardaddr = 0}, irq = 0}
> (gdb) print *sp->config
> $4 = {next = 0x0, index = 1 '\001', driver = 0x180e0, irq = 11, flags = 0,
> inuse = 1 '\001'}
> (gdb) n
> 469 if (cisconf == 0)
> (gdb) n
> 471 sp->card_config = cisconf;
> (gdb) n
> 477 if (cisconf->memspace || (defconf && defconf->memspace)) {
> (gdb) n
> 480 mp = cisconf->mem;
> (gdb) print cisconf->memspace
> $5 = 1
> (gdb) print defconf
> $6 = (struct cis_config *) 0x1d080
> (gdb) print defconf->memspace
> $7 = 1
> (gdb) print cisconf
> $8 = (struct cis_config *) 0x1d080
>
> NOTE: cisconf and defconf are the same???
Some cards have more than one Configuration Entry tuple; one can be
nominated as the 'default' in the card, but this can be overridden with
an explicit index entry in the /etc/pccard.conf file.
> (gdb) n
> 481 if (!cisconf->memspace)
> (gdb) n
> 483 sp->mem.size = mp->length;
> (gdb) n
> 484 sp->mem.cardaddr = mp->address;
> (gdb) n
> 487 sp->mem.addr = sp->config->driver->mem;
> (gdb) n
> 492 if (sp->mem.size && sp->mem.addr == 0) {
> (gdb) print *sp
> $9 = {next = 0x19080, fd = 8, mask = 0, slot = 1, name = 0x1a0d0 "/dev/card1",
> state = filled, cis = 0x19180, card = 0x180a0, config = 0x180c0,
> card_config = 0x1d080, devname = '\000' <repeats 15 times>,
> eaddr = "\000\000\000\000\000", io = {next = 0x0, addr = 0, size = 0,
> flags = 0, cardaddr = 0}, mem = {next = 0x0, addr = 0, size = 1024,
> flags = 0, cardaddr = 0}, irq = 0}
>
> NOTE: why is sp->mem.size == 1024? <----------------------------
It's trying to allocate a mapping for the EEPROM (tuple #2, aka
memory region 1).
> (gdb) n
> 493 sp->mem.addr = alloc_memory(mp->length);
> (gdb) s
> alloc_memory (size=-272639028) at util.c:125
> 125 i = bit_fns(mem_avail, MEMBLKS, size / MEMUNIT);
>
> (gdb) print *mem_avail @200 (oops, should have just printed 12 bytes)
>
> $10 = {"\000\000\000\000\000\000\000\000\000
Ok. Looks like you have some memory there.
> (gdb) s
> bit_fns (nm=0x1a030 "", nbits=96, count=0) at util.c:106
And there's your problem; alloc_memory should be rounding 'size' up
to MEMUNIT, as bit_fns can't handle a request for an allocation of 0.
unsigned long
alloc_memory(int size)
{
int i;
/* Add Me */
if (size < MEMUNIT)
size = MEMUNIT;
i = bit_fns(mem_avail, MEMBLKS, size / MEMUNIT);
if (i < 0)
return (0);
bit_nclear(mem_avail, i, size / MEMUNIT);
return (BIT2MEM(i));
}
(commentary on your CIS follows)
> Configuration data for card in slot 1
> Tuple #1, code = 0x1 (Common memory descriptor), length = 3
> 000: dc 03 ff
> Common memory device information:
> Device number 1, type Function specific, WPS = ON
> Speed = 100nS, Memory block size = 32Kb, 1 units
> Tuple #2, code = 0x17 (Attribute memory descriptor), length = 3
> 000: 53 01 ff
> Attribute memory device information:
> Device number 1, type FLASH EEPROM, WPS = OFF
> Speed = 150nS, Memory block size = 2Kb, 1 units
> Tuple #3, code = 0x21 (Functional ID), length = 2
> 000: 06 03
> Network/LAN adapter - POST initialize - Card has ROM
> Tuple #4, code = 0x15 (Version 1 info), length = 30
> 000: 04 01 50 4d 58 20 20 20 00 50 45 2d 32 30 30 00
> 010: 45 54 48 45 52 4e 45 54 00 52 30 31 00 ff
> Version = 4.1, Manuf = [PMX ],card vers = [PE-200]
> Addit. info = [ETHERNET],[R01]
> Tuple #5, code = 0x1a (Configuration map), length = 5
> 000: 01 01 00 01 01
> Reg len = 2, config register addr = 0x100, last config = 0x1
> Registers: X-------
> Tuple #6, code = 0x1b (Configuration entry), length = 25
> 000: c1 81 78 ca 61 00 03 0f 10 03 0f 30 fc be c9 04
> 010: 00 00 40 0d 40 40 00 40 0d
> Config index = 0x1(default)
> Interface byte = 0x81 (I/O) wait signal supported
> Card decodes 10 address lines, limited 8/16 Bit I/O
> I/O address # 1: block start = 0x300 block length = 0x10
> I/O address # 2: block start = 0x310 block length = 0x10
> IRQ modes: Level
> IRQs: 4 5 10 11 12 13 14 15
> -> why? what could this be for? It's 1k long?
> -> Memory descriptor 1
> -> blk length = 0x400 card addr = 0x000 host addr = 0xd4000
Not entirely sure. This may match tuple #2, the flash EEPROM.
> Memory descriptor 2
> blk length = 0x4000 card addr = 0x4000 host addr = 0xd4000
This almost certainly matches tuple #1. It's interesting to note that
the sizes of both of these mismatch; it appears that the spec doesn't
provide for 1K or 16K as legitimate values for memory regions.
--
]] Mike Smith, Software Engineer msmith@gsoft.com.au [[
]] Genesis Software genesis@gsoft.com.au [[
]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[
]] realtime instrument control. (ph) +61-8-8267-3493 [[
]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612100134.MAA11963>