Opened 14 years ago

Closed 12 years ago

#6698 closed enhancement (invalid)

[WIP] Haiku should include support for wimax devices

Reported by: kallisti5 Owned by: nobody
Priority: low Milestone: Unscheduled
Component: Drivers/Network Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description (last modified by kallisti5)

Haiku should include at least one wimax hardware driver, thus making the building of a Wimax stack possible someday.

Attachments (4)

beceem.png​ (220.5 KB ) - added by kallisti5 14 years ago.
progress atm
beceem_10.08.2010.jpg​ (268.8 KB ) - added by kallisti5 14 years ago.
as of Oct 8th, 2010
beceem_10.19.2010.jpg​ (281.5 KB ) - added by kallisti5 14 years ago.
beceem_12.05.2010.JPG​ (292.1 KB ) - added by kallisti5 13 years ago.
great progress :)

Download all attachments as: .zip

Change History (11)

by kallisti5, 14 years ago

Attachment: beceem.png​ added

progress atm

comment:1 by kallisti5, 14 years ago

Progress so far:

  • based on other known stable usb driver framework
  • properly detects new usb device and begins to set it up
  • detects the firmware in /boot/system/data/firmware/macxvi200/macxvi200.bin
  • attempts to push the firmware to the usb device (not working atm but almost there)
  • as it is not complete yet, it safely stops before causing stability issues
  • unloads cleanly if USB device is unplugged

EDIT: description should be: "Haiku should include at least one wimax hardware driver, thus making the building of a Wimax *framework* possible someday."

Last edited 14 years ago by kallisti5 (previous) (diff)

comment:2 by kallisti5, 14 years ago

sources at ​http://github.com/kallisti5/usb_beceemwmx

Progress so far:

  • vendor configuration is pushed (with error checking) to device
  • firmware is pushed (with error checking) to device
  • stable!

TODO:

  • implement calls to read nvram (FLASH or EEPROM)
Last edited 14 years ago by kallisti5 (previous) (diff)

by kallisti5, 14 years ago

Attachment: beceem_10.08.2010.jpg​ added

as of Oct 8th, 2010

by kallisti5, 14 years ago

Attachment: beceem_10.19.2010.jpg​ added

comment:3 by kallisti5, 14 years ago

Progress so far:

  • Device baseband chip detected
  • Binary vendor configuration loaded into struct for access
  • Flash or EEPROM non-volatile memory detected (verified)
  • Non-volatile memory initialized (verified)
  • DDR memory initialized (verified)
  • vendor config pushed to device
  • firmware pushed to device
  • Device CPU booted
  • MAC address read from non-volatile memory (verified)
  • When device is allowed to complete initialization...
    • a new network interface shows up with the correct MAC address
    • any bytes sent to the interface result in a "WiMAX connection not up" warning
    • removal of usb device causes a crash (looking into it)

TODO:

  • Get device LED's working via GPIO
  • Implement generic WiMAX interface in driver / control application
  • lots

comment:4 by kallisti5, 13 years ago

Progress so far:

  • Device baseband chip detected (verified)
  • Generic support for a wide range of Beceem devices (due to generic vendor config)
    • Future support of non-USB Beceem devices possible
  • Binary vendor configuration loaded into struct for access (verified)
  • Flash or EEPROM non-volatile memory detected (verified)
  • Non-volatile memory initialized (verified)
  • DDR memory initialized (verified)
  • vendor config pushed to device (verified)
  • firmware pushed to device (verified)
  • Device CPU boots (verified)
  • MAC address read from non-volatile memory (verified)
  • GPIO registers probed and device LEDs set up based on vendor config (verified)
  • We know what GPIO LEDs do what based on the vendor config (verified)
  • GPIO LEDs can be illuminated easily. (verified)
  • A LED control kernel thread is spawned. (not operational atm)
  • When device is allowed to complete initialization...
    • a new network interface shows up with the correct MAC address
    • any bytes sent to the interface result in a "WiMAX connection not up" warning
  • When the device is removed
    • LED kernel thread is safely terminated
    • mallocs are safely freed

by kallisti5, 13 years ago

Attachment: beceem_12.05.2010.JPG​ added

great progress :)

comment:5 by phoudoin, 13 years ago

Since hrev39581, link speed should be reported in bits/s unit, not anymore kbits/s. And I dunno much about WiMax, but I guess WiMax usual speed is not 1000 bits/s ;-)

comment:6 by kallisti5, 13 years ago

Description: modified (diff)
Milestone: R1 → Unscheduled
Priority: normal → low
Version: R1/alpha2 → R1/Development

my initial work was checked in hrev40302

TODO

  • physical network interface needs work as well as io control calls.
  • contact Beceem / Broadcom and see if they will dual license code as MIT+GPL, or get their blessing for us to license my code as MIT. (there isn't a lot of original Beceem code left.. but there is possibly a little.. especially in the BeceemDDR code)

Done:

  • Beceem binary firmware file push
  • low level hardware setup and communication
  • GPIO mapping and a basic LED Thread that monitors device state
  • LED blinks and stuff according to device state
  • reads device mac address and sets up (buggy) network interface with it.
  • more stable then vendors driver!

comment:7 by kallisti5, 12 years ago

Resolution: → invalid
Status: new → closed

going to close this for now.. given the decline in WiMax presence in the US and abroad, as well as the tendency for new WiMax devices to show up as generic ndis devices it seems like more trouble then it's worth.

I'll leave the Beceem wimax driver in-tree for now. However it should definitely not be in the default build.

Note: See TracTickets for help on using tickets.