Re: integration of opensource firmware with b43 kernel driver
On Sunday 25 January 2009 13:19:45 Michael Buesch wrote: > On Sunday 25 January 2009 04:45:20 Larry Finger wrote: > > Francesco Gringoli wrote: > > > > > > could you please be so kind to try the opensource firmware on that > > > 4311/2 card by renaming it ucode13 and report what happens? I suggest to > > > try monitor mode without associating first. > > > > I had already tried it in managed mode. The logged data are > > > > Jan 23 13:37:09 larrylap kernel: b43-phy0: Loading OpenSource firmware > > version 351.11970 > > Jan 23 13:37:09 larrylap kernel: b43-phy0 warning: You are using an > > old firmware image. Support for old firmware will be removed soon > > (official deadline was July 2008). > > Jan 23 13:37:09 larrylap kernel: b43-phy0 warning: You must go to > > http://wireless.kernel.org/en/users/Drivers/b43#devicefirmware and > > download the correct firmware for this driver version. Please > > carefully read all instructions on this website. > > Jan 23 13:37:09 larrylap kernel: b43-phy0 debug: Chip initialized > > Jan 23 13:37:09 larrylap kernel: b43-phy0 debug: 64-bit DMA initialized > > Jan 23 13:37:09 larrylap kernel: Registered led device: b43-phy0::tx > > Jan 23 13:37:09 larrylap kernel: Registered led device: b43-phy0::rx > > Jan 23 13:37:09 larrylap kernel: Registered led device: b43-phy0::radio > > Jan 23 13:37:09 larrylap kernel: b43-phy0 debug: Wireless interface > > started > > Jan 23 13:37:09 larrylap kernel: b43-phy0: Controller restarted > > Jan 23 13:37:25 larrylap kernel: b43-phy0 ERROR: MAC suspend failed > > Jan 23 13:37:29 larrylap kernel: b43-phy0 ERROR: MAC suspend failed > > Jan 23 13:37:30 larrylap kernel: b43-phy0 ERROR: MAC suspend failed > > Jan 23 13:37:30 larrylap kernel: b43-phy0 ERROR: MAC suspend failed > > Jan 23 13:37:30 larrylap kernel: b43-phy0 ERROR: MAC suspend failed > > Jan 23 13:37:31 larrylap kernel: b43-phy0 ERROR: MAC suspend failed > > Jan 23 13:37:31 larrylap kernel: b43-phy0 ERROR: MAC suspend failed > > Jan 23 13:37:31 larrylap kernel: b43-phy0 ERROR: MAC suspend failed > > Jan 23 13:37:32 larrylap kernel: b43-phy0 ERROR: MAC suspend failed > > Jan 23 13:37:32 larrylap kernel: b43-phy0 ERROR: MAC suspend failed > > Jan 23 13:37:40 larrylap kernel: b43-phy0 ERROR: Firmware watchdog: > > The firmware died! > > Jan 23 13:37:40 larrylap kernel: b43-phy0: Controller RESET (Firmware > > watchdog) ... > > Jan 23 13:37:41 larrylap kernel: b43-phy0 ERROR: MAC suspend failed > > Jan 23 13:37:41 larrylap kernel: b43-phy0 debug: Wireless interface > > stopped > > Jan 23 13:37:41 larrylap kernel: b43-phy0 debug: DMA-64 rx_ring: Used > > slots 0/64, Failed frames 0/0 = 0.0%, Average tries 0.00 > > Jan 23 13:37:41 larrylap kernel: b43-phy0 debug: DMA-64 tx_ring_AC_BK: > > Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00 > > Jan 23 13:37:41 larrylap kernel: b43-phy0 debug: DMA-64 tx_ring_AC_BE: > > Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00 > > Jan 23 13:37:41 larrylap kernel: b43-phy0 debug: DMA-64 tx_ring_AC_VI: > > Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00 > > Jan 23 13:37:41 larrylap kernel: b43-phy0 debug: DMA-64 tx_ring_AC_VO: > > Used slots 22/128, Failed frames 0/0 = 0.0%, Average tries 0.00 > > Jan 23 13:37:41 larrylap kernel: b43-phy0 debug: DMA-64 tx_ring_mcast: > > Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00 > > > > I haven't gotten to monitor mode yet, but if the firmware cannot > > suspend the MAC, I'm not optimistic. > > Well, there's a reason broadcom does different firmwares for different cores. > ;) > It turns out even rev9 runs with its own firmware now. I think that used to > run rev5 > firmware in the past. Btw, I guess you know you guys know about the b43-fwdump utility found in b43-tools/debug. It provides a kernel-oops-like firmware register (and SHM) dump and a (pseudo-)backtrace for the current program counter of the firmware. It requires the b43 debugfs interface to be available. Very nice to debug this kind of "what the hell is happening" errors, as you can see what code the firmware does currently execute. For the pseudo-backtrace you must provide the .fw file to the b43-fwdump tool. (see b43-fwdump --help) -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: integration of opensource firmware with b43 kernel driver
On Sunday 25 January 2009 04:45:20 Larry Finger wrote: > Francesco Gringoli wrote: > > > > could you please be so kind to try the opensource firmware on that > > 4311/2 card by renaming it ucode13 and report what happens? I suggest to > > try monitor mode without associating first. > > I had already tried it in managed mode. The logged data are > > Jan 23 13:37:09 larrylap kernel: b43-phy0: Loading OpenSource firmware > version 351.11970 > Jan 23 13:37:09 larrylap kernel: b43-phy0 warning: You are using an > old firmware image. Support for old firmware will be removed soon > (official deadline was July 2008). > Jan 23 13:37:09 larrylap kernel: b43-phy0 warning: You must go to > http://wireless.kernel.org/en/users/Drivers/b43#devicefirmware and > download the correct firmware for this driver version. Please > carefully read all instructions on this website. > Jan 23 13:37:09 larrylap kernel: b43-phy0 debug: Chip initialized > Jan 23 13:37:09 larrylap kernel: b43-phy0 debug: 64-bit DMA initialized > Jan 23 13:37:09 larrylap kernel: Registered led device: b43-phy0::tx > Jan 23 13:37:09 larrylap kernel: Registered led device: b43-phy0::rx > Jan 23 13:37:09 larrylap kernel: Registered led device: b43-phy0::radio > Jan 23 13:37:09 larrylap kernel: b43-phy0 debug: Wireless interface > started > Jan 23 13:37:09 larrylap kernel: b43-phy0: Controller restarted > Jan 23 13:37:25 larrylap kernel: b43-phy0 ERROR: MAC suspend failed > Jan 23 13:37:29 larrylap kernel: b43-phy0 ERROR: MAC suspend failed > Jan 23 13:37:30 larrylap kernel: b43-phy0 ERROR: MAC suspend failed > Jan 23 13:37:30 larrylap kernel: b43-phy0 ERROR: MAC suspend failed > Jan 23 13:37:30 larrylap kernel: b43-phy0 ERROR: MAC suspend failed > Jan 23 13:37:31 larrylap kernel: b43-phy0 ERROR: MAC suspend failed > Jan 23 13:37:31 larrylap kernel: b43-phy0 ERROR: MAC suspend failed > Jan 23 13:37:31 larrylap kernel: b43-phy0 ERROR: MAC suspend failed > Jan 23 13:37:32 larrylap kernel: b43-phy0 ERROR: MAC suspend failed > Jan 23 13:37:32 larrylap kernel: b43-phy0 ERROR: MAC suspend failed > Jan 23 13:37:40 larrylap kernel: b43-phy0 ERROR: Firmware watchdog: > The firmware died! > Jan 23 13:37:40 larrylap kernel: b43-phy0: Controller RESET (Firmware > watchdog) ... > Jan 23 13:37:41 larrylap kernel: b43-phy0 ERROR: MAC suspend failed > Jan 23 13:37:41 larrylap kernel: b43-phy0 debug: Wireless interface > stopped > Jan 23 13:37:41 larrylap kernel: b43-phy0 debug: DMA-64 rx_ring: Used > slots 0/64, Failed frames 0/0 = 0.0%, Average tries 0.00 > Jan 23 13:37:41 larrylap kernel: b43-phy0 debug: DMA-64 tx_ring_AC_BK: > Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00 > Jan 23 13:37:41 larrylap kernel: b43-phy0 debug: DMA-64 tx_ring_AC_BE: > Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00 > Jan 23 13:37:41 larrylap kernel: b43-phy0 debug: DMA-64 tx_ring_AC_VI: > Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00 > Jan 23 13:37:41 larrylap kernel: b43-phy0 debug: DMA-64 tx_ring_AC_VO: > Used slots 22/128, Failed frames 0/0 = 0.0%, Average tries 0.00 > Jan 23 13:37:41 larrylap kernel: b43-phy0 debug: DMA-64 tx_ring_mcast: > Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00 > > I haven't gotten to monitor mode yet, but if the firmware cannot > suspend the MAC, I'm not optimistic. Well, there's a reason broadcom does different firmwares for different cores. ;) It turns out even rev9 runs with its own firmware now. I think that used to run rev5 firmware in the past. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: integration of opensource firmware with b43 kernel driver
Francesco Gringoli wrote: > > could you please be so kind to try the opensource firmware on that > 4311/2 card by renaming it ucode13 and report what happens? I suggest to > try monitor mode without associating first. I had already tried it in managed mode. The logged data are Jan 23 13:37:09 larrylap kernel: b43-phy0: Loading OpenSource firmware version 351.11970 Jan 23 13:37:09 larrylap kernel: b43-phy0 warning: You are using an old firmware image. Support for old firmware will be removed soon (official deadline was July 2008). Jan 23 13:37:09 larrylap kernel: b43-phy0 warning: You must go to http://wireless.kernel.org/en/users/Drivers/b43#devicefirmware and download the correct firmware for this driver version. Please carefully read all instructions on this website. Jan 23 13:37:09 larrylap kernel: b43-phy0 debug: Chip initialized Jan 23 13:37:09 larrylap kernel: b43-phy0 debug: 64-bit DMA initialized Jan 23 13:37:09 larrylap kernel: Registered led device: b43-phy0::tx Jan 23 13:37:09 larrylap kernel: Registered led device: b43-phy0::rx Jan 23 13:37:09 larrylap kernel: Registered led device: b43-phy0::radio Jan 23 13:37:09 larrylap kernel: b43-phy0 debug: Wireless interface started Jan 23 13:37:09 larrylap kernel: b43-phy0: Controller restarted Jan 23 13:37:25 larrylap kernel: b43-phy0 ERROR: MAC suspend failed Jan 23 13:37:29 larrylap kernel: b43-phy0 ERROR: MAC suspend failed Jan 23 13:37:30 larrylap kernel: b43-phy0 ERROR: MAC suspend failed Jan 23 13:37:30 larrylap kernel: b43-phy0 ERROR: MAC suspend failed Jan 23 13:37:30 larrylap kernel: b43-phy0 ERROR: MAC suspend failed Jan 23 13:37:31 larrylap kernel: b43-phy0 ERROR: MAC suspend failed Jan 23 13:37:31 larrylap kernel: b43-phy0 ERROR: MAC suspend failed Jan 23 13:37:31 larrylap kernel: b43-phy0 ERROR: MAC suspend failed Jan 23 13:37:32 larrylap kernel: b43-phy0 ERROR: MAC suspend failed Jan 23 13:37:32 larrylap kernel: b43-phy0 ERROR: MAC suspend failed Jan 23 13:37:40 larrylap kernel: b43-phy0 ERROR: Firmware watchdog: The firmware died! Jan 23 13:37:40 larrylap kernel: b43-phy0: Controller RESET (Firmware watchdog) ... Jan 23 13:37:41 larrylap kernel: b43-phy0 ERROR: MAC suspend failed Jan 23 13:37:41 larrylap kernel: b43-phy0 debug: Wireless interface stopped Jan 23 13:37:41 larrylap kernel: b43-phy0 debug: DMA-64 rx_ring: Used slots 0/64, Failed frames 0/0 = 0.0%, Average tries 0.00 Jan 23 13:37:41 larrylap kernel: b43-phy0 debug: DMA-64 tx_ring_AC_BK: Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00 Jan 23 13:37:41 larrylap kernel: b43-phy0 debug: DMA-64 tx_ring_AC_BE: Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00 Jan 23 13:37:41 larrylap kernel: b43-phy0 debug: DMA-64 tx_ring_AC_VI: Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00 Jan 23 13:37:41 larrylap kernel: b43-phy0 debug: DMA-64 tx_ring_AC_VO: Used slots 22/128, Failed frames 0/0 = 0.0%, Average tries 0.00 Jan 23 13:37:41 larrylap kernel: b43-phy0 debug: DMA-64 tx_ring_mcast: Used slots 0/128, Failed frames 0/0 = 0.0%, Average tries 0.00 I haven't gotten to monitor mode yet, but if the firmware cannot suspend the MAC, I'm not optimistic. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: integration of opensource firmware with b43 kernel driver
On Jan 23, 2009, at 8:45 PM, Larry Finger wrote: > Francesco Gringoli wrote: >> Damn... that would be a very hard writing We do not have any >> 4311/2 >> board: at first glance there are more condition registers whose >> meaning >> we do not know. Very different hardware, didn't know. Thank you for >> the >> feedback. >> >> By the way: is that device inside an AP? If yes what? if not which >> brand >> has the board on? I can look around. > > Mine is on a mini-PCIe card in a laptop. The part has an HP Part > #441090-001, but I expect there are Dell equivalents that are cheaper. > I don't know about an AP. > > Larry Larry, could you please be so kind to try the opensource firmware on that 4311/2 card by renaming it ucode13 and report what happens? I suggest to try monitor mode without associating first. Thanks a lot. -FG ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: integration of opensource firmware with b43 kernel driver
On Jan 23, 2009, at 6:44 PM, Brian J. Murrell wrote: > On Fri, 2009-01-23 at 18:36 +0100, Francesco Gringoli wrote: >> Hello, >> >> we have been testing the firmware for a week now and it seems stable. >> I personally tested it also on a Linksys WRT54GL and it works both in >> station and in AP modes. > > Did you try pushing it hard? i.e. doing a nice big bulk transfer > through it? Did it reach decent speeds without pegging the CPU with > softirqs? > > Can you give details on which kernel(s) and how you built/configured > the > router firmware(s)? Well, I just tested a 500Mbytes bulk transfer and I got a mean throughput of about 5.5Mbit/s, it was a simple infinite wget loop so we can have some slowness due to TCP. However no errors were logged to syslog and the AP is still there, it didn't complain about anything. I built kamikaze yesterday image (r14144), kernel 2.6.25.17, I used the AP as a station joined to another AP without encryption. By the way, we did thousands of tests with x86 and we came to the conclusion that there is no performance (throughput) difference if compared to the standard proprietary firmware. Cheers, -FG ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: integration of opensource firmware with b43 kernel driver
On Jan 23, 2009, at 8:37 PM, Michael Buesch wrote: > On Friday 23 January 2009 20:24:47 Francesco Gringoli wrote: >> On Jan 23, 2009, at 7:01 PM, Larry Finger wrote: >> >>> Francesco Gringoli wrote: Hello, we have been testing the firmware for a week now and it seems stable. I personally tested it also on a Linksys WRT54GL and it works both in station and in AP modes. I collected the feedbacks that some of you sent and it seems that the firmware now runs on these board: - 4306, 4311, 4318, 4320 >>> >>> As a point of clarification, I think this is restricted to the >>> 4311/1 >>> as the 4311/2 uses ucode13, not ucode5. If you need a tester for an >>> open-source version of the 13 firmware, I'm available. >> Damn... that would be a very hard writing We do not have any >> 4311/2 board: at first glance there are more condition registers >> whose >> meaning we do not know. Very different hardware, didn't know. Thank >> you for the feedback. > > Well, if you didn't notice it already, there are a zillion different > flavors > of the broadcom wireless chip out there. So if you buy a random > device, you're almost > guaranteed that you don't have that flavor already. ;) Ehm... I begin to notice now... we were so engaged in understanding the tx state machine that we lost this _huge_ detail(!). They (Broadcom) should have plenty of engineers to design so many different chipsets. Cheers, -FG ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: integration of opensource firmware with b43 kernel driver
On Friday 23 January 2009 20:46:45 Francesco Gringoli wrote: > -- Is using the Broadcom names for the firmware the best course of > -- action? What if the opensource firmware files were named something > -- like "os-ucode5.fw", etc. and b43 were coded to check for those files > -- first? It would then fall back to the standard firmware if the > -- opensource version is not found. I answered to this question with this patch: http://bu3sch.de/patches/wireless-testing/20081227-1821/patches/008-b43-probe-open-fw.patch I am currently testing an updated version of the patch and I'll push it upstream tomorrow. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: integration of opensource firmware with b43 kernel driver
On Jan 23, 2009, at 8:33 PM, Michael Buesch wrote: > On Friday 23 January 2009 20:18:52 Francesco Gringoli wrote: >>> Nothing. Why do we need to have different names? >> Well, I was only considering a question raised by John, we can surely >> maintain these names. > > I guess I missed that. What was the question? > Note that proprietary and open firmwares are in separate > directories, so > I don't see why we should rename them. > Renaming firmware is a huge pain. We did it several times in the > past and > I really want to avoid it. It creates a major confusion for users > for some months. Sorry sorry sorry and sorry again... it was a Larry question, not John's... pardon me -- Is using the Broadcom names for the firmware the best course of -- action? What if the opensource firmware files were named something -- like "os-ucode5.fw", etc. and b43 were coded to check for those files -- first? It would then fall back to the standard firmware if the -- opensource version is not found. However, it's not a problem maintaining these names. - detection of the opensource firmware capabilities: are you really sure we cannot use a shm location that the bcm proprietary firmware uses for some other purpose? >>> >>> Yes, well. You're not intermixing an earlier discussion into this, >>> where >>> you didn't indicate opensource capabilities to the kernel. >>> If you indicate OS capabilities, you can use whatever offset you >>> want, of course. >> Excellent. We will modify the firmware accordingly and encode the >> options. > > Thanks. Would be nice if you could also do the corresponding driver > patch. Ok, it should be simple. - tx header layout: the opensource firmware is now using the old memory layout in the tx header (<351). Do you think switching to 410 format is mandatory now or we can concentrate on the other tasks? >>> >>> Yes, the old format is deprecated and will be removed soon. >> Ok, first task in the todo list! > > Well, doesn't need to the the first one. Just note that support for > this is > scheduled to be removed in summer 2008. So if any problems show up > (broadcom > releases yet another API, for example), I will immediately remove it. Well, it's the first because it's the easiest :-) >> Ok, thanks for the hint. I will check, > > There are a few things we're not yet sure about. > For example the operand for the GPR number got an additional bit. > But we're not sure if the real number of GPRs also was doubled in > the hardware. > There are a few FIXMEs in the code for this... > I think this simply has to be tested by trial and error. Thanks, I will surely check this. Cheers, -FG > > > -- > Greetings, Michael. --- Francesco Gringoli, PhD - Assistant Professor Dept. of Electrical Engineering for Automation University of Brescia via Branze, 38 25123 Brescia ITALY Ph: ++39.030.3715843 FAX: ++39.030.380014 WWW: http://www.ing.unibs.it/~gringoli ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: integration of opensource firmware with b43 kernel driver
Francesco Gringoli wrote: > Damn... that would be a very hard writing We do not have any 4311/2 > board: at first glance there are more condition registers whose meaning > we do not know. Very different hardware, didn't know. Thank you for the > feedback. > > By the way: is that device inside an AP? If yes what? if not which brand > has the board on? I can look around. Mine is on a mini-PCIe card in a laptop. The part has an HP Part #441090-001, but I expect there are Dell equivalents that are cheaper. I don't know about an AP. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: integration of opensource firmware with b43 kernel driver
On Friday 23 January 2009 20:24:47 Francesco Gringoli wrote: > On Jan 23, 2009, at 7:01 PM, Larry Finger wrote: > > > Francesco Gringoli wrote: > >> Hello, > >> > >> we have been testing the firmware for a week now and it seems > >> stable. I > >> personally tested it also on a Linksys WRT54GL and it works both in > >> station and in AP modes. I collected the feedbacks that some of you > >> sent > >> and it seems that the firmware now runs on these board: > >> > >> - 4306, 4311, 4318, 4320 > > > > As a point of clarification, I think this is restricted to the 4311/1 > > as the 4311/2 uses ucode13, not ucode5. If you need a tester for an > > open-source version of the 13 firmware, I'm available. > Damn... that would be a very hard writing We do not have any > 4311/2 board: at first glance there are more condition registers whose > meaning we do not know. Very different hardware, didn't know. Thank > you for the feedback. Well, if you didn't notice it already, there are a zillion different flavors of the broadcom wireless chip out there. So if you buy a random device, you're almost guaranteed that you don't have that flavor already. ;) Another thing is: You simply can _not_ distinguish the devices by the 43xx number in practice. There are too many devices with the same 43xx number, but different internal designs. The safest solution for the firmware is to tell by the wireless core revision whether it works or not. (However, that still leaves a few traps for different PHY and radio revisions, as the firmware also accesses PHY and radio). -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: integration of opensource firmware with b43 kernel driver
On Friday 23 January 2009 20:18:52 Francesco Gringoli wrote: > > Nothing. Why do we need to have different names? > Well, I was only considering a question raised by John, we can surely > maintain these names. I guess I missed that. What was the question? Note that proprietary and open firmwares are in separate directories, so I don't see why we should rename them. Renaming firmware is a huge pain. We did it several times in the past and I really want to avoid it. It creates a major confusion for users for some months. > >> - detection of the opensource firmware capabilities: are you really > >> sure we cannot use a shm location that the bcm proprietary firmware > >> uses for some other purpose? > > > > Yes, well. You're not intermixing an earlier discussion into this, > > where > > you didn't indicate opensource capabilities to the kernel. > > If you indicate OS capabilities, you can use whatever offset you > > want, of course. > Excellent. We will modify the firmware accordingly and encode the > options. Thanks. Would be nice if you could also do the corresponding driver patch. > >> - what to do with rts procedure: we can implement this feature easily > >> but I'm not sure about the value it can add to people (the majority > >> of > >> users?) that use the bcm board in station mode. This is different for > >> those who run a bcm card in AP mode, but we can clearly discourage > >> them to run this firmware in AP mode if not sure about rts usage by > >> stations. However, we put this task in the todo list. > > > > RTS/CTS is not specific to AP mode. It's used on any station in the > > BSS. > > See IEEE 802.11 specs. > Yes, in fact we put this task in the todo list. Thanks. > >> - tx header layout: the opensource firmware is now using the old > >> memory layout in the tx header (<351). Do you think switching to 410 > >> format is mandatory now or we can concentrate on the other tasks? > > > > Yes, the old format is deprecated and will be removed soon. > Ok, first task in the todo list! Well, doesn't need to the the first one. Just note that support for this is scheduled to be removed in summer 2008. So if any problems show up (broadcom releases yet another API, for example), I will immediately remove it. > Ok, thanks for the hint. I will check, There are a few things we're not yet sure about. For example the operand for the GPR number got an additional bit. But we're not sure if the real number of GPRs also was doubled in the hardware. There are a few FIXMEs in the code for this... I think this simply has to be tested by trial and error. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: integration of opensource firmware with b43 kernel driver
On Jan 23, 2009, at 7:01 PM, Larry Finger wrote: > Francesco Gringoli wrote: >> Hello, >> >> we have been testing the firmware for a week now and it seems >> stable. I >> personally tested it also on a Linksys WRT54GL and it works both in >> station and in AP modes. I collected the feedbacks that some of you >> sent >> and it seems that the firmware now runs on these board: >> >> - 4306, 4311, 4318, 4320 > > As a point of clarification, I think this is restricted to the 4311/1 > as the 4311/2 uses ucode13, not ucode5. If you need a tester for an > open-source version of the 13 firmware, I'm available. Damn... that would be a very hard writing We do not have any 4311/2 board: at first glance there are more condition registers whose meaning we do not know. Very different hardware, didn't know. Thank you for the feedback. By the way: is that device inside an AP? If yes what? if not which brand has the board on? I can look around. Cheers, -FG ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: integration of opensource firmware with b43 kernel driver
On Jan 23, 2009, at 7:02 PM, Michael Buesch wrote: > On Friday 23 January 2009 18:36:37 Francesco Gringoli wrote: >> Hello, >> >> we have been testing the firmware for a week now and it seems stable. >> I personally tested it also on a Linksys WRT54GL and it works both in >> station and in AP modes. I collected the feedbacks that some of you >> sent and it seems that the firmware now runs on these board: >> >> - 4306, 4311, 4318, 4320 > > I don't think it has enough testing, yet. Sure, it seems to be stable on _our_ boards but I can't tell if it shows the same behavior on other hardware revisions. > > >> I was considering the suggestions you all gave me a few days ago and >> other questions related to the possible integration of this firmware >> into the kernel, and I came to these conclusions/questions (please >> forgive me for this long message :-) ) > > I don't think we want to have the firmware in the kernel. > Instead distributions should simply ship the firmware in a package. > That's not our business. I agree with you, distributions could easily package the firmware and distribute it to users when it will be stable, I was just wondering about. >> - change the name of the initvals for the opensource firmware: this > > Why? > >> [cut] >> initvals have already been uploaded. What can we do? > > Nothing. Why do we need to have different names? Well, I was only considering a question raised by John, we can surely maintain these names. >> - detection of the opensource firmware capabilities: are you really >> sure we cannot use a shm location that the bcm proprietary firmware >> uses for some other purpose? > > Yes, well. You're not intermixing an earlier discussion into this, > where > you didn't indicate opensource capabilities to the kernel. > If you indicate OS capabilities, you can use whatever offset you > want, of course. Excellent. We will modify the firmware accordingly and encode the options. >> - what to do with rts procedure: we can implement this feature easily >> but I'm not sure about the value it can add to people (the majority >> of >> users?) that use the bcm board in station mode. This is different for >> those who run a bcm card in AP mode, but we can clearly discourage >> them to run this firmware in AP mode if not sure about rts usage by >> stations. However, we put this task in the todo list. > > RTS/CTS is not specific to AP mode. It's used on any station in the > BSS. > See IEEE 802.11 specs. Yes, in fact we put this task in the todo list. >> - tx header layout: the opensource firmware is now using the old >> memory layout in the tx header (<351). Do you think switching to 410 >> format is mandatory now or we can concentrate on the other tasks? > > Yes, the old format is deprecated and will be removed soon. Ok, first task in the todo list! >> - I would like to start considering N-phy on the firmware side. I >> have >> a late 2008 MacBook Pro and I'm not sure if beginning this work on >> this platform is a waste of time or not as Apple could have asked >> Broadcom a customized chipset. Should I start or is it better if I >> buy >> a N-phy pci board for my x86 box? > > A little bit of b43-asm work is still needed for this core. > There are a few FIXMEs in the code. Not sure, maybe there's more to > do. > I didn't try that, yet. > Before you start, you'll have to verify whether the assembler works > correctly. > Same for the disassembler. Ok, thanks for the hint. I will check, Cheers, -FG > > > -- > Greetings, Michael. --- Francesco Gringoli, PhD - Assistant Professor Dept. of Electrical Engineering for Automation University of Brescia via Branze, 38 25123 Brescia ITALY Ph: ++39.030.3715843 FAX: ++39.030.380014 WWW: http://www.ing.unibs.it/~gringoli ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: integration of opensource firmware with b43 kernel driver
On Friday 23 January 2009 19:50:37 Dan Williams wrote: > On Fri, 2009-01-23 at 19:08 +0100, Michael Buesch wrote: > > On Friday 23 January 2009 19:01:00 Larry Finger wrote: > > > The driver can certainly be coded to look for the open-source firmware > > > names before trying to load vendor firmware. That way there will not > > > be any confusion. > > > > I already posted that, but in case you missed it: > > http://bu3sch.de/patches/wireless-testing/20081227-1821/patches/008-b43-probe-open-fw.patch > > Preferring the proprietary firmware over the open firmware (for now) > seems like the best approach at this time. Many people will be quite > happy with the open firmware that we can actually ship in distros, and > those that aren't can do the fwcutter stuff and get their own > proprietary firmware. If for some reason the open firmware isn't > working, use fwcutter and get the proprietary firmware, which you would > have had to do before anyway. And those people with chips that aren't > supported by the proprietary firmware yet still have to use the > fwcutter, which they would have had to do anyway. Win all around. Exactly. This is why I implemented it that way. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: integration of opensource firmware with b43 kernel driver
On Friday 23 January 2009 19:01:00 Larry Finger wrote: > The driver can certainly be coded to look for the open-source firmware > names before trying to load vendor firmware. That way there will not > be any confusion. I already posted that, but in case you missed it: http://bu3sch.de/patches/wireless-testing/20081227-1821/patches/008-b43-probe-open-fw.patch -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: integration of opensource firmware with b43 kernel driver
On Friday 23 January 2009 18:36:37 Francesco Gringoli wrote: > Hello, > > we have been testing the firmware for a week now and it seems stable. > I personally tested it also on a Linksys WRT54GL and it works both in > station and in AP modes. I collected the feedbacks that some of you > sent and it seems that the firmware now runs on these board: > > - 4306, 4311, 4318, 4320 I don't think it has enough testing, yet. > I was considering the suggestions you all gave me a few days ago and > other questions related to the possible integration of this firmware > into the kernel, and I came to these conclusions/questions (please > forgive me for this long message :-) ) I don't think we want to have the firmware in the kernel. Instead distributions should simply ship the firmware in a package. That's not our business. > - change the name of the initvals for the opensource firmware: this Why? > seems a little bit complicated as now the decision about the initval- > files' names and the detection of the firmware type are respectively > based on the phy type and on the firmware date. This means that > initval-files' names can be determine as soon as the hardware type has > been probed, while the firmware needs to be started before the kernel > can determine if it is opensource or not: at this time, however, the > initvals have already been uploaded. What can we do? Nothing. Why do we need to have different names? > - detection of the opensource firmware capabilities: are you really > sure we cannot use a shm location that the bcm proprietary firmware > uses for some other purpose? Yes, well. You're not intermixing an earlier discussion into this, where you didn't indicate opensource capabilities to the kernel. If you indicate OS capabilities, you can use whatever offset you want, of course. > - what to do with rts procedure: we can implement this feature easily > but I'm not sure about the value it can add to people (the majority of > users?) that use the bcm board in station mode. This is different for > those who run a bcm card in AP mode, but we can clearly discourage > them to run this firmware in AP mode if not sure about rts usage by > stations. However, we put this task in the todo list. RTS/CTS is not specific to AP mode. It's used on any station in the BSS. See IEEE 802.11 specs. > - tx header layout: the opensource firmware is now using the old > memory layout in the tx header (<351). Do you think switching to 410 > format is mandatory now or we can concentrate on the other tasks? Yes, the old format is deprecated and will be removed soon. > - I would like to start considering N-phy on the firmware side. I have > a late 2008 MacBook Pro and I'm not sure if beginning this work on > this platform is a waste of time or not as Apple could have asked > Broadcom a customized chipset. Should I start or is it better if I buy > a N-phy pci board for my x86 box? A little bit of b43-asm work is still needed for this core. There are a few FIXMEs in the code. Not sure, maybe there's more to do. I didn't try that, yet. Before you start, you'll have to verify whether the assembler works correctly. Same for the disassembler. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: integration of opensource firmware with b43 kernel driver
Francesco Gringoli wrote: > Hello, > > we have been testing the firmware for a week now and it seems stable. I > personally tested it also on a Linksys WRT54GL and it works both in > station and in AP modes. I collected the feedbacks that some of you sent > and it seems that the firmware now runs on these board: > > - 4306, 4311, 4318, 4320 As a point of clarification, I think this is restricted to the 4311/1 as the 4311/2 uses ucode13, not ucode5. If you need a tester for an open-source version of the 13 firmware, I'm available. > I was considering the suggestions you all gave me a few days ago and > other questions related to the possible integration of this firmware > into the kernel, and I came to these conclusions/questions (please > forgive me for this long message :-) ) > > - change the name of the initvals for the opensource firmware: this > seems a little bit complicated as now the decision about the > initval-files' names and the detection of the firmware type are > respectively based on the phy type and on the firmware date. This means > that initval-files' names can be determine as soon as the hardware type > has been probed, while the firmware needs to be started before the > kernel can determine if it is opensource or not: at this time, however, > the initvals have already been uploaded. What can we do? The driver can certainly be coded to look for the open-source firmware names before trying to load vendor firmware. That way there will not be any confusion. > - detection of the opensource firmware capabilities: are you really sure > we cannot use a shm location that the bcm proprietary firmware uses for > some other purpose? Once, in fact, the kernel has determined that the > firmware is opensource it can also use a given location in a different > manner than it would do for a proprietary firmware. However this is not > a problem at all :-) as we can use one location in the "high" shm-memory > area, let's say > 0xb00, just choose one. I think it best to choose an unused location. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: integration of opensource firmware with b43 kernel driver
On Fri, 2009-01-23 at 18:36 +0100, Francesco Gringoli wrote: > Hello, > > we have been testing the firmware for a week now and it seems stable. > I personally tested it also on a Linksys WRT54GL and it works both in > station and in AP modes. Did you try pushing it hard? i.e. doing a nice big bulk transfer through it? Did it reach decent speeds without pegging the CPU with softirqs? Can you give details on which kernel(s) and how you built/configured the router firmware(s)? b. signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
integration of opensource firmware with b43 kernel driver
Hello, we have been testing the firmware for a week now and it seems stable. I personally tested it also on a Linksys WRT54GL and it works both in station and in AP modes. I collected the feedbacks that some of you sent and it seems that the firmware now runs on these board: - 4306, 4311, 4318, 4320 I was considering the suggestions you all gave me a few days ago and other questions related to the possible integration of this firmware into the kernel, and I came to these conclusions/questions (please forgive me for this long message :-) ) - change the name of the initvals for the opensource firmware: this seems a little bit complicated as now the decision about the initval- files' names and the detection of the firmware type are respectively based on the phy type and on the firmware date. This means that initval-files' names can be determine as soon as the hardware type has been probed, while the firmware needs to be started before the kernel can determine if it is opensource or not: at this time, however, the initvals have already been uploaded. What can we do? - detection of the opensource firmware capabilities: are you really sure we cannot use a shm location that the bcm proprietary firmware uses for some other purpose? Once, in fact, the kernel has determined that the firmware is opensource it can also use a given location in a different manner than it would do for a proprietary firmware. However this is not a problem at all :-) as we can use one location in the "high" shm-memory area, let's say > 0xb00, just choose one. - what to do with rts procedure: we can implement this feature easily but I'm not sure about the value it can add to people (the majority of users?) that use the bcm board in station mode. This is different for those who run a bcm card in AP mode, but we can clearly discourage them to run this firmware in AP mode if not sure about rts usage by stations. However, we put this task in the todo list. - tx header layout: the opensource firmware is now using the old memory layout in the tx header (<351). Do you think switching to 410 format is mandatory now or we can concentrate on the other tasks? - I would like to start considering N-phy on the firmware side. I have a late 2008 MacBook Pro and I'm not sure if beginning this work on this platform is a waste of time or not as Apple could have asked Broadcom a customized chipset. Should I start or is it better if I buy a N-phy pci board for my x86 box? Thank you for your time. Cheers, -FG ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
