bcm440x doesn't initialize the NIC

[cssvb94]

bcm440x driver compiles without a problem and reckognizes the NIC by vendorID/productID, but does not initialize the network card.

I've put some debug messages and found that in b44um.c @ line 119:

if (b44_LM_GetAdapterInfo(&be_b44_dev_cards[sCardsFound].lm_dev) != LM_STATUS_SUCCESS) 

b44_LM_GetAdapterInfo() never returns LM_STATUS_SUCCESS.

in b44lm.c @ line 199:
    /* check sprom version */
    if ((eprom[126] != 1) && (eprom[126] != 0x10))
        return LM_STATUS_FAILURE;

Always return LM_STATUS_FAILURE, I don't know which are the correct values or b44_LM_EepromReadBlock(pDevice, 0, eprom_dw, sizeof(eprom_dw)); doesn't reads the values correctly.

I did the lamest thing and hacked some functions and recompiled to return LM_STATUS_SUCCESS. I can see that during ping request NIC card's LEDs are flashing, i.e. packets are sent, but DHCP server can not be found and even after setting IP address and default GW the other machines in the network can not be reached.

[cssvb94]

In b44lm.c @ line 199, eprom[] array all the values are 0xFF. Incorect reading device eprom. Function:

b44_LM_EepromReadBlock(pDevice, 0, eprom_dw, sizeof(eprom_dw));

b44lm.c @ line 139 in b44_LM_EepromReadBlock():

buf[i/4] = REG_RD_OFFSET(pDevice, 4096 + off + i);

REG_RD_OFFSET does not point at the right location which results worng values in eprom[]

[cssvb94]

I found that in the Linux b44 driver/module, reading eprom is a little bit different:

/* Read 128-bytes of EEPROM. */
static int '''b44_read_eeprom'''(struct b44 *bp, u8 *data)
{
        long i;
        u16 *ptr = (u16 *) data;

        for (i = 0; i < 128; i += 2)
                ptr[i / 2] = readw(bp->regs + 4096 + i);

        return 0;
}

Hope that information will help the knowledgeable people here.

[korli]

The driver version we use is a bit outdated and was based on Linux bcm440x. Linux now uses a refactored driver b44. We should probably rebase this port on the FreeBSD driver bfe (should be named broadcom_bcm440x since we have broadcom_bcm570x for bge). As I own the hardware I might be able to check this out.

[cssvb94]

Great korli, I'll help with the testing. Drop a line here =)

[axeld]

That would be great, Korli! Once we have both drivers up and running, I guess we can remove the old drivers from the tree.

BTW I think the "_bcm" part of the name could safely be removed - I thought the chip would be named that way back then, but that doesn't appear to be this way (so broadcom570x would be better). If no one beats me to it, I'll rename it tomorrow.

[cssvb94]

Any progress so far?

[cssvb94]

FreeBSD bfe drivers + Jamfiles

[cssvb94]

I've put FreeBSD bfe drivers and created/modified Jamfiles to compile it. Compilation went without errors and during Haiku boot driver loads up, but can not reset the device properly. Here is the syslog snip:

KERN: register_domain(1, internet)
KERN: get_device_interface: ask "network/devices/ethernet/v1" for loop
KERN: get_device_interface: ask "network/devices/loopback/v1" for loop
KERN: 3com: init_hardware(0x807b5bd8)
KERN: 3com: no hardware found.
KERN: loaded driver /boot/beos/system/add-ons/kernel/drivers/dev/net/bcm570x
KERN: broadcom440x: init_hardware(0x807b2800)
KERN: broadcom440x, found Broadcom BCM4401-B0 Fast Ethernet at 14
KERN: broadcom440x: init_driver(0x807b2800)
KERN: [broadcom440x] (bfe) bus_alloc_resource(3, [16], 0x0, 0xffffffff, 0x1, 0x2)
KERN: [broadcom440x] (bfe) bus_alloc_resource(1, [0], 0x0, 0xffffffff, 0x1, 0x6)
KERN: if_initname(0x81773540, bfe, 3)
KERN: [broadcom440x] broadcom440x: /dev/net/broadcom440x/0
KERN: [broadcom440x] (bfe) PHY Reset would not complete.
KERN: [broadcom440x] (bfe) MII without any PHY!
KERN: [broadcom440x] (bfe) PHY Reset would not complete.KERN: 
KERN: loaded driver /boot/beos/system/add-ons/kernel/drivers/dev/net/broadcom440x
KERN: etherpci: init_driver init_driver: etherpci not found

A little bit of tweaking should resolve the issue. =) Cheers

[korli]

Sorry I had work in progress which needed a bit of tweaking. Please check broadcom440X found in hrev28597.

[cssvb94]

Doesn't work for me =(. Same message in the syslog "(bfe) PHY Reset would not complete. ". Used hrev28608.

[korli]

Out of curiosity, does it work on FreeBSD for you ? This failing code seems to be low level.

[cssvb94]

Haven't tried FreeBSD. I have Ubuntu/MacOS X/WinXP installed on Acer Travelmate 2490. I'll download it and I'll post back info here.

[cssvb94]

Downloaded and rebooted in FreeBSD 7.0 livefs, bfe driver recognized and started NIC without any problems. I configured the IP and Default gateway and I was able to ping to and from other workstations in the network. So the short answer is - Yes, it works =)

I hoped so bad Haiku/broadcom440x to work me.

[korli]

Thanks for checking. Could you provide a syslog ? What's the chip version ?

[cssvb94]

Ubuntu 8.04 lspci

[cssvb94]

Haiku syslog

[cssvb94]

I hope this will help you korli. Post back if you need more information.

[PieterPanman]

Maybe you can try with the attached patch. It will print out a little more information during phy detection. Please attach the resulting syslog.

[cssvb94]

Thank you Pieter.
I have updated to the latest svn version and applied the patch: patch -p0 < debug_bmtphy_probe.diff in broadcom440x/mii folder. No problems at all, even checked the file - all patched.
Then a ran: jam -q clean, jam -q @disk build
The compile process passed and I rebooted into Haiku.
This is the produced syslog by the system.
I can't see the debug messages you applied, but probably the information will be useful for you. Attached.

[PieterPanman]

Interesting. No output still tells me something: it doesn't even get there. Here's another diff with more debugging output. Can you try again? Patch is made from the src directory.

[cssvb94]

Yes, definitely!
I'm so glad that someone is working over that problem.
I doesn't matter how many tries will take.
Currently I'm at the office so after work I'll try and post the syslog again.

[PieterPanman]

No problem. I'll try to see what happens with your new output. Korli, if you happen to see something, or you have some ideas please let us know, we'll try to work them out.

[cssvb94]

OK, Here is the syslog hrev28734.

[PieterPanman]

Hm. Very strange, I have no clue really why it doesn't work. It seems the hardware is just not responding in the way it should. Maybe we need another phy? Could it use another? I'm not too familiar with how it chooses this in FreeBSD.

Can you try the freebsd livecd and see if any interesting debug output is produced? Can you post their syslog?

[cssvb94]

Yes, I'll post the result ASAP.
Only the syslog or you need some more hw info?

[PieterPanman]

I'm not sure what else may help, so that will do for now.

[cssvb94]

This is FreeBSD 7.0 syslog:

[korli]

It seems that the device is behing a pci-pci brige. Could you find a way to enable tracing in src/add-ons/kernel/bus_managers/pci/pci.cpp ? I don't understand as of now why pci traces don't appear in the syslog. _EnumerateBus should be the most interessant traces.

[Adek336]

KERN: i<TRUNC>i<DROP>ps2_hid: init_hardware

The <DROP> means some messages have not been written to disk.

To fix the problem, you have to edit ~/config/settings/kernel/drivers/kernel so that you have

syslog_buffer_size 131768

or something like that.

[cssvb94]

Done. Here is the result:

[cssvb94]

kernel settings log enabled

[cssvb94]

I've downloaded haiku.image.hrev28735 from Haiku Factory, installed it on the same partition and made it bootable.
The result according the syslog is absolutely the same as my builds.
The only difference was faster boot and ... thats it pretty much.

In the FreeBSD syslog noticed at line #91: bfe0: using obsoleted if_watchdog interface
I don't know is the watchdog access to the interface matter. Just a guess.

[Adek336]

Which MII does FreeBSD use for your card?

[Adek336]

This should be in "devinfo -r" output.

[cssvb94]

Here is the devinfo output:

[cssvb94]

Here is the devinfo output

[Adek336]

It uses bmtphy which is included in Haiku as well. Also we see that phyno=1 there. Could you try mii.diff, it blindly accepts phyno=1 as correct.

[cssvb94]

It worked to certain point.

1. Applied the diff and compiled Haiku rev 28781.
   
2. Rebooted to Haiku, but after the boot sequence the system froze at the blue screen with no icons, but mouse hand cursor only. I wasn't able to move the mouse cursor.
   
3. Rebooted Haiku with disabled add-ons this time with everything operational.
   
4. The NIC is detected by the system, but according the syslog PHY reset couldn't complete.
   

I'm able to set IP address, but not to change media to 100TX neither to ping any workstation in my network. DHCP IP assigning not working. The MAC address of the NIC is FF:FF:FF:FF:FF:FF, i.e. wrong.
Hope that information will help you.

[Adek336]

Replying to cssvb94:

4. The NIC is detected by the system, but according the syslog PHY reset couldn't complete.

That's too bad because it means that the patch didn't help at all.

Could you please try with reverting mii.diff and applying bfe440x.1.diff ?

[cssvb94]

1. Compiled and started up Haiku without a problem.
   
2. The network card is not registered in /dev/net.
   
3. All debug values are 0xff.
   

mii.dif is reverted.

[Adek336]

It looks like the driver fails to setup memory mapped io, bfe440x.2.diff will show the pci control registers' values.

[cssvb94]

I'll do it right a way when I come back home.
Do you want me to revert bfe440x.1.diff, before applying bfe440x.2.diff?

[Adek336]

Yea, revert.

[Adek336]

Oh and also change PCIR_BAR(0) to PCIR_BAR(1) in bfe_attach().

[cssvb94]

1. Compiled and started up Haiku without a problem.
   
2. The network card is not registered in /dev/net.
   

bfe440x.1.diff reverted and changed PCIR_BAR(0) to PCIR_BAR(1) in bfe_attach().

[Adek336]

That PCIR_BAR(0) is correct after all. So either the card needs more configuring before being accessed through mmio (unlikely), or the mmio range isn't mapped into the proper virtual address.

bus_alloc_mem_resource() allocates indifferently 128 kb. Looking at the listdev output we see that such an amount overlaps with the card reader's memory. It's a thin chance, but forcing the driver to allocate only the amount it needs may help.

[Adek336]

If that doesn't help; could you try disabling stuff in BIOS or removing them from the computer - particularly the memory stick reader?

[cssvb94]

I reverted all previous patches and applied bfe440x.3.diff.
Then I compiled Haiku and rebooted.
After the last icon (the rocket) at boot process I was dropped right into KDL.
The pictures are attached below.
I was able to continue to working Desktop, but no network, syslog attached above.

[Adek336]

Um, it would be interesting to see what is the mapping for 0xd0001000 but I don't know how to use the "page" kdl command? I'll try to investigate.

[korli]

Could you attach the output of "lspci -vvvv" on linux please ?

[cssvb94]

lspci ouput Ubuntu 8.10

[cssvb94]

I've updated the system BIOS, but the result is still the same.

[Adek336]

Could you post the output of

db -p 0xd0010000 600

from the kernel debugger?

[cssvb94]

Sorry for the delay, but yesterday (18.Dec) the dev site wasn't accessible for some reason. I'll post the result later today.

[cssvb94]

Hm, now Haiku boots normally - without dropping in KDL any more.
NIC still not operational - same debug messages in the syslog as the last attached here.

[Adek336]

Sorry about the KDL, it's a result of not properly allocating memory in the debug code. It's weird that it sometimes doesn't crash for you, though.
Could you post a photo of what that db command outputs?

[cssvb94]

Two photos attached after complete boot into working Haiku environment.
I entered KDL using CTRL-ALT-F12.
The first one is :

db -p 0xd0010000 600

The second one is :

db -p 0xd00100000 600

because I've noticed that address in the previous shots I took.

[Adek336]

Wow, that is unexpected.
Could you take a look at

db -p 0xd0010000 4096

and

db -p 0xd0011000 4096

and see if you get anything else than lots of "ff" ?

[cssvb94]

I did the same, i.e. entered in KDL after full boot into Haiku.
In the both scenarios only 0xFF is read =(.

[korli]

It could be interesting to check the memory for the next device on the bus at 0xd0000000 ? It might indicate a bad configuration of the pci-pci bus. Just an idea.

[Adek336]

That'd be 0xd0012000 for the "CardBus bridge".

[Adek336]

Unless you meant the Atheros NIC, of course, should be interesting to see !

[cssvb94]

db -p 0xd0012000 4096

[cssvb94]

db -p 0xd00012000 4096

[cssvb94]

db -p 0xd0001000 4096

[cssvb94]

db -p 0xd00010000 4096

[cssvb94]

Here are some KDL screen shots:

1. db -p 0xd0012000 4096  ;Only 0xFF
2. db -p 0xd00012000 4096 ;Various =)
3. db -p 0xd0001000 4096  ;Only 0xFF
4. db -p 0xd00010000 4096 ;Various =)

[Adek336]

Regarding 0xd00010000 and other 9-digit hex numbers: memory addresses are 8-digit hex, so 0xd00010000 is cut to 0x10000 which is no MMIO range but some program data, so unfortunately, non-ff data there is of no help to us.

[Adek336]

Replying to korli:

It could be interesting to check the memory for the next device on the bus at 0xd0000000 ? It might indicate a bad configuration of the pci-pci bus. Just an idea.

Haiku

431	KERN: PCI: [dom 0, bus  0] bus   0, device 30, function  0: vendor 8086, device 2448, revision e2
432	KERN: PCI:   class_base 06, class_function 04, class_api 01
433	KERN: PCI:   vendor 8086: Intel Corporation
434	KERN: PCI:   device 2448: 82801 Mobile PCI Bridge
435	KERN: PCI:   info: Bridge (PCI bridge, Subtractive decode)
436	KERN: PCI:   line_size 00, latency 00, header_type 01, BIST 00
437	KERN: PCI:   subsystem_id 0000, subsystem_vendor_id 0050
438	KERN: PCI:   primary_bus 00, secondary_bus 06, subordinate_bus 07, secondary_latency 20
439	KERN: PCI:   io_base_upper_16  0000, io_base  f0
440	KERN: PCI:   io_limit_upper_16 0000, io_limit 00
441	KERN: PCI:   memory_base d000, memory_limit d000
442	KERN: PCI:   prefetchable_memory_base_upper32  00000000, prefetchable_memory_base  fff1
443	KERN: PCI:   prefetchable_memory_limit_upper32 00000000, prefetchable_memory_limit 0001
444	KERN: PCI:   bridge_control 0823, secondary_status 0280
445	KERN: PCI:   interrupt_line ff, interrupt_pin 00
446	KERN: PCI:   ROM base host 00000000, pci 00000000, size ??
447	KERN: PCI:   base reg 0: host 00000000, pci 00000000, size 00000000, flags 00
448	KERN: PCI:   base reg 1: hostKERN:  00000000, pci 00000000, size 00000000, flags 00
449	KERN: PCI:   Capabilities: 0x0d

Ubuntu

282	00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2) (prog-if 01)
283	        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
284	        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
285	        Latency: 0
286	        Bus: primary=00, secondary=06, subordinate=0a, sec-latency=32
287	        I/O behind bridge: 0000f000-00000fff
288	        Memory behind bridge: d0000000-d00fffff
289	        Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
290	        Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
291	        BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
292	                PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
293	        Capabilities: [50] Subsystem: Acer Incorporated [ALI] Device 0090

Given that neither the Atheros NIC, Broadcom NIC or cardbus bridge on pci6 seem to talk and that Haiku does not mention the 0xd0000000 - 0xd00fffff range for the bridge, you might be right that the bridge needs more configuring.

[Adek336]

Note #3.

[Adek336]

Would you care to check this patch.

[cssvb94]

Now I'm applying the patch.
At first it failed to build, because:

@434 int bus_alloc_mem_resource_adipe(device_t dev, struct resource *res, int regid);

I added the following code at the beginning of your patch:

Index: src/libs/compat/freebsd_network/bus.c
===================================================================
--- src/libs/compat/freebsd_network/bus.c	(wersja 28800)
+++ src/libs/compat/freebsd_network/bus.c	(kopia robocza)
@@ -108,7 +108,26 @@
 	return 0;
 }
 
+int
+bus_alloc_mem_resource_adipe(device_t dev, struct resource *res, int regid)
+{
+	uint32 addr = pci_read_config(dev, regid, 4) & PCI_address_memory_32_mask;
+	uint32 size = 4 * 1024; /* XXX */
+	void *virtualAddr;
 
+	dprintf("bfe: bus_alloc_mem_resource_adipe\n");
+
+	res->r_mapped_area = map_mem(&virtualAddr, (void *)addr, size, 0,
+		"bus_alloc_resource(MEMORY)");
+	if (res->r_mapped_area < B_OK)
+		return -1;
+
+	res->r_bustag = I386_BUS_SPACE_MEM;
+	res->r_bushandle = (bus_space_handle_t)virtualAddr;
+	return 0;
+}
+
+
 static int
 bus_alloc_ioport_resource(device_t dev, struct resource *res, int regid)
 {

Sorry for the delay.
I'll post the result as soon as possible.

[cssvb94]

Boot log

[cssvb94]

Boot process stopped here

[cssvb94]

bfe pci output details

[cssvb94]

Haiku compiled and when I rebooted it stopped at the last boot icon (rocket). KDL wasn't possible to be called. PC freezed. Then I rebooted in debug output mode to take some pictures (attached above). If I choose safe mode it boots to bash prompt.

[Adek336]

If you enter KDL after the "bfe: rman_bus_handle: ...", does "db -p 0xd0010000 600" yield something interesting ?

[cssvb94]

Happy new year to all of you guys and all the best and bright future of Haiku.

Replying to Adek336:

If you enter KDL after the "bfe: rman_bus_handle: ...", does "db -p 0xd0010000 600" yield something interesting ?

You mean in safe mode I presume?
Do I need to set breakpoint to enter KDL and how to do that?

[Adek336]

If the driver is picked up with safe mode, that is if the modified bfe driver binaries reside in /boot/beos/system/add-ons/... than check in safe mode please. Although you should be able to select non-safe mode + on screen debug and enter KDL with F12 when the "Press Q or S.." text is displayed, after the "bfe: rman_bus_handle" message appears.

Also, to open KDL from the source code, you can replace the "dprintf" in dprintf("bfe: rman_bus_handle...", ...) with "panic".

[cssvb94]

KDL frozen

[cssvb94]

I've added panic("ble") after dprintf("bfe: rman_bus_....") function.
As can be seen in the attached image above boot process spawned KDL during boot, but when I've tried to execute "db -p 0xd0010000 600" it frozed the PC.

[Adek336]

Could you do

out32 0xcf8 0x8000f004
in32 0xcfc

to see the pci command register of the bridge (bus 0, device 30, function 0) ?

[cssvb94]

The result is:

[0xcfc]     d0010000

[Adek336]

That looks like the address, but it shouldn't. Anyway, please try

out32 0xcf8 0x8000f004
out32 0xcfc 0xd0010002

before the 3com driver gets loaded. Then, try "db -p 0xd0010000 600" when the "ble" panic appears.

[cssvb94]

How can I set breakpoint before the 3com driver?

[Adek336]

You can press F12 some time before the red rocket icon appears.

[cssvb94]

I only had a chance to do it before network manager starts to load up.

out32 0xcf8 0x8000f004
out32 0xcfc 0xd0010002
db -p 0xd0010000 600

returns only 0x00 value.

[Adek336]

Thanks! Did you try continuing the bootup by entering "continue" at the kdls you get? If you succeeded, could you grep the syslog for "bfe"? And try db -p 0xd0010000 600 after the bootup? Of course with the two out32 commands applied before the red icon.

[cssvb94]

I admit I didn't =) continue. I'll try now.

[cssvb94]

I did it just before my panic("ble") in bfe.

out32 0xcf8 0x8000f004
out32 0xcfc 0xd0010002

but after KDL continue it freezes again.

[richienyhus]

Has this been fixed in the mean time?

[cssvb94]

No, when i remove the soft link and recreate it again, still shows message that can not be initialized.

KERN: set MTRRs to:
2095	KERN:   mtrr:  0: base: 0xd0000000, size: 0x10000000, type: 0
2096	KERN:   mtrr:  1: base: 0xe0000000, size: 0x20000000, type: 0
2097	KERN:   mtrr:  2: base: 0x80000000, size: 0x80000000, type: 1
2098	KERN: driver "broadcom440x" removed
2099	KERN: devfs: reload driver "broadcom440x" (3, 590228)
2100	KERN: driver "broadcom440x" added
2101	KERN: devfs: reload driver "broadcom440x" (3, 590228)
2102	KERN: broadcom440x: init_driver(0x81df458c)
2103	KERN: [broadcom440x] (bfe) bus_alloc_resource(3, [16], 0x0, 0xffffffff, 0x1,0x2)
2104	KERN: add_memory_type_range(5944, 0xd0010000, 0x20000, 0)
2105	KERN: set MTRRs to:
2106	KERN:   mtrr:  0: base: 0xd0000000, size: 0x10000000, type: 0
2107	KERN:   mtrr:  1: base: 0xe0000000, size: 0x20000000, type: 0
2108	KERN:   mtrr:  2: base: 0x80000000, size: 0x80000000, type: 1
2109	KERN: [broadcom440x] (bfe) bus_alloc_resource(1, [0], 0x0, 0xffffffff, 0x1,0x6)
2110	KERN: if_initname(0x83016160, bfe, 3)
2111	KERN: [broadcom440x] broadcom440x: /dev/net/broadcom440x/0
2112	KERN: [broadcom440x] (bfe) PHY Reset would not complete.
2113	KERN: [broadcom440x] (bfe) MII without any PHY!
2114	KERN: [broadcom440x] (bfe) PHY Reset would not complete.
2115	KERN: remove_memory_type_range(5944, 0xd0010000, 0x20000, 0)
2116	KERN: set MTRRs to:
2117	KERN:   mtrr:  0: base: 0xd0000000, size: 0x10000000, type: 0
2118	KERN:   mtrr:  1: base: 0xe0000000, size: 0x20000000, type: 0
2119	KERN:   mtrr:  2: base: 0x80000000, size: 0x80000000, type: 1

Same with atheroswifi ticket: #5546 Doesn't matter GCC2/4 build.

[diver]

Probably a kernel issue.

[diver]

(In #5546) Most likely the same cause as in #2998.

[brunobratwurst]

R1Alpha3 Broadcom 4401 B0 and Iprowifi3945

[cssvb94]

Tested with haiku-nightly-hrev44091-x86gcc2hybrid-anyboot : issue remains.

[cssvb94]

atheroswifi driver is unable to attach the hardware. I'm reporting it here because #5446 was closed pointing to this one.

[Caylon]

bcm440x works on a Acer 662 with hrev44270, but only if the cable is plugged in before I boot Haiku!

[diver]

@Caylon: Please file a new ticket about this problem, as it's likely unrelated to this ticket. Also attach a syslog to it.

[Caylon]

ok https://dev.haiku-os.org/ticket/8704

[waddlesplash]

bcm440x has been removed from the tree in favor of broadcom440x from FreeBSD. Close?

[nielx]

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone