N900 Hardware USB

(Host mode prospects.: links and minor notes added)
(USB Phy: FUSB2600)
 
(42 intermediate revisions not shown)
Line 1: Line 1:
-
The USB connector on the n900 is a micro-b connector, as required in european and chinese markets, under the new scheme to make all phone charger sockets identical.
+
The USB connector on the [[Nokia N900|N900]] is a micro-b connector, as now required in European and Chinese markets, under the [http://en.wikipedia.org/wiki/Universal_Charger_Solution#Universal_Charging_Solution|new scheme to make all phone charger sockets identical].
-
=USB socket=
+
==USB implementation==
-
=USB implementation=
+
The N900 seems initially to have been designed to be capable of acting as a USB host, or implementing OSG mode. This would have allowed keyboards, mice, and other peripherals to be plugged in.
-
The n900 seems initially to have been designed to be capable of acting as a USB host, or implementing OSG mode. This would have allowed keyboards, mice, and other peripherals to be plugged in.
+
-
This was changed relatively short time before release, the micro-AB USB receptacle was changed to be micro-B, and the host functionality was officially removed - in order to comply with the USB standard - it could not get certification as a standard USB port with embedded host mode, while not all the necessary OTG drivers were ready for showtime.  
+
The USB port with embedded host mode could not be certified, as the OTG drivers were not ready. (see [http://talk.maemo.org/showthread.php?p=643577#post643577] last block).
 +
 
 +
This lead to the the micro-AB USB connector being replaced by a micro-B, and the host functionality being officially removed short time before launch.
Lacking certification would have a large number of issues, from some operating systems requiring certification before allowing drivers to be distributed, to legal compliance with the USB charger specs - it would technically not be a USB port.
Lacking certification would have a large number of issues, from some operating systems requiring certification before allowing drivers to be distributed, to legal compliance with the USB charger specs - it would technically not be a USB port.
-
==The Chips==
+
===The Chips===
 +
 
There are four chips involved in the USB subsystem.
There are four chips involved in the USB subsystem.
-
===SoC===
+
 
 +
====SoC====
 +
 
The System-on-a-chip is the main processor on the n900.
The System-on-a-chip is the main processor on the n900.
This is the [http://focus.ti.com/docs/prod/folders/print/omap3530.html  TI omap3430]
This is the [http://focus.ti.com/docs/prod/folders/print/omap3530.html  TI omap3430]
-
===Gaia===
 
-
The TWL4030[http://wiki.maemo.org/N900_Hardware_Power_management/I2C] is a TI companion chip to the SoC
 
-
===USB battery charger===
 
-
The [http://focus.ti.com/docs/prod/folders/print/bq24150.html bq24150] charger from TI is quite a flexible charger.
 
-
It, along with the PHY chip - support charging without the intervention of the SoC when the system is charging from a completely dead battery.
 
-
The PHY chip detects a charger (shorted D+ and D- pins) and the charger uses this information to charge more rapidly.
 
-
It also features reverse boost mode - which enables power to be supplied to a USB device connected to the n900.
+
====Gaia====
-
===USB Phy===
+
The [[N900_Hardware_Power_management/I2C|TWL4030]] is a TI companion chip to the SoC
-
The [http://www.nxp.com/ NXP] isp1707a is used as the USB PHY chip. [http://www.spinics.net/lists/linux-usb/msg25167.html].
+
-
This rights to this part have been bought by ST-Ericson and some information is [http://www.stericsson.com/sales_marketing_resources/USB_transceiverBR_1.pdf available in a brief marketing sheet].
+
-
There is no published datasheet for this chip.
+
====USB battery charger====
-
It may be available under another name.
+
-
==The Circuit==
+
The [http://focus.ti.com/docs/prod/folders/print/bq24150a.html bq24150a] charger from TI is a flexible charger. It, along with the PHY chip - support charging without the intervention of the SoC when the system is charging from a completely dead battery. The PHY chip detects a charger (shorted D+ and D- pins) and the charger uses this information to charge more rapidly.
-
* The SoC has the USB protocol controller - this is the 'high level' controller - it implements most of the USB protocol.
+
It also features reverse boost mode - which enables power to be supplied to a USB device connected to the N900. (up to a limit of 200mA)
-
* The PHY (physical layer) chip connects to the world through the USB socket. This is not the normal companion chip - but the NXP part, and is connected to the SoC via a standard ULPI interface. It does the very lowest level USB hardware protocol. Also it detects chargers (by sensing D+/D- short). It also has a connection to VBUS, via a 1k resistor, to do certain probing.
+
For more information see [[N900 Hardware Battery Charger]]
-
* The bq24150 Battery charger. This is connected to the battery, and the PHY chip, as well as to the SoC though I2C. It handles (with the PHY chip) charging from dead. It also implements boost mode, to enable powering things through the USB socket. Of course it detects when external VBUS is applied.
+
====USB Phy====
-
* Gaia. The TWL4030 [http://wiki.maemo.org/N900_Hardware_Power_management/I2C]is used to sense the value of the ID pin. It also has a connection to VBUS, to power up the device on charger insertion and probably also to inform a running system about changes in VBUS state.
+
The [http://www.nxp.com/ NXP] isp1707a is used as the USB PHY chip. [http://www.spinics.net/lists/linux-usb/msg25167.html]. This rights to this part have been bought by ST-Ericson and some information is [http://www.stericsson.com/sales_marketing_resources/USB_transceiverBR_1.pdf available in a brief marketing sheet].  
-
==The Software==
+
There is no published datasheet for this chip. It may be available under another name.
-
* BME - the battery managment entity. This has its hands in everything, especially the bq24150, and is split into
+
A reasonably similar chip (compare chips: [http://www.ebv.com/fileadmin/products/Products/ST-Ericsson/Flyer_USB_Transceivers_1.pdf]) is the 1704 which has a datasheet [http://www.stericsson.com/technical_documents/CD00222700.pdf] 
-
** BME - kernel
+
-
** BME - userspace
+
-
* Kernel driver.
+
Another equivalent chip seems to be the https://www.startpage.com/do/search?query=FUSB2500 - see http://talk.maemo.org/showthread.php?p=643577#post643577
-
** This seems to be a partially implemented OTG driver for the initial design of the n900, with OTG mode partially implemented, assuming that the twl4030 would be used as the USB PHY. It seems to have been modified only to the extent required to make the NXP PHY work as a replacement.
+
-
=Host mode prospects.=
+
For more information see [[N900 Hardware USB PHY]]
-
A USB OTG controller would normally switch between host and device mode (initially) using the ID pin, to detect if it's at the A or B-side of a OTG cable.
+
===The Circuit===
-
Initially it was claimed that ID is not connected externally, and that this made USB host mode impossible.
+
* The SoC has the USB protocol controller - this is the 'high level' controller - it implements most of the USB protocol. This is a [http://www.mentor.com/products/ip/usb/usb20otg/ Mentorgrafix MUSBMHDRC-core] IntelectualProperty function block licenced for the OMAP.
 +
* The PHY (physical layer) chip connects to the world through the USB socket. This is not the normal companion chip - but the NXP part, and is connected to the SoC via a standard ULPI interface. It does the very lowest level USB hardware protocol. Also it detects chargers (by sensing D+/D- short). It also has a connection to VBUS, via a 1k resistor, to do certain probing.
 +
* The [[N900 Hardware Battery Charger|bq24150a Battery charger]]. This is connected to the battery, and the PHY chip, as well as to the SoC though I2C. It handles (with the PHY chip) charging from dead. It also implements boost mode, to enable powering things through the USB socket. Of course it detects when external VBUS is applied.
 +
* Gaia. The [[N900_Hardware_Power_management/I2C|TWL4030]] is used to sense the value of the ID pin. It also has a connection to VBUS, to power up the device on charger insertion and inform a running system about changes in VBUS state. Though TWL4030 has a function similar to PHY chip as well, the original design using this function had to change as early chip revisions had problems with charger detection (so the rumour). Driver sourecode is full of cruft from that original design.
-
However, similar device datasheets indicate that the ID pin is used on hardware that supports it to switch between host and device mode.
+
===The Software===
-
But, importantly, the ID pin does nothing directly to the state of the PHY. It simply informs the CPU of the state of the ID pin, and leaves the driver to properly configure the chip (nota bene, only for OTG, and only for determining the inital state).
+
* [[N900 Software BME|BME]] - the battery managment entity. This has its hands in everything, especially the bq24150a, and is split into
 +
** charger detection (via PHY) in kernel MUSB_HDRC driver, exposing /sys/devices/platform/musb_hdrc/charger
 +
** BME - userspace driver for the charger chip, as well as monitoring battery voltage through Gaia.
 +
** Hald-addon-bme - a small helper program to interface between HAL and BME.
-
So, if the kernel can be altered to ignore this pin - which should be trivial if there is host mode support for the chip in the kernel - then host mode works.(the related sourcecode is to be found here:[http://mxr.maemo.org/fremantle/source/kernel/drivers/usb/musb/musb_core.c#2010], a 'echo host >mode' should work if the kernel driver wasn't crippled in some strange way)
+
* Kernel driver.
 +
** This seems to be a partially implemented OTG driver for the initial design of the N900, with OTG mode partially implemented, assuming that the twl4030 would be used as the USB PHY. It seems to have been modified only to the extent required to make the NXP PHY work as a replacement.
-
The current understanding by several people who are working on USB host mode is:
+
==Host mode details.==
-
The USB port can supply power - at least 200mA (as demonstrated here:[http://talk.maemo.org/showthread.php?p=588950#post588950]). This is plenty for many devices - mice and keyboards.
+
Host mode works, see [http://talk.maemo.org/showthread.php?p=901888#post901888 this thread] Mohammad started on talk.maemo.org, when releasing first beta of a package comprising of a hostmode patched kernel build by Paul Fertser with support of h-e-n team, and a lean GUI built by Mohammad. The basic functionality seems to work fine.
 +
 +
A [[N900_Hardware_USB_Host|user friendly implementation]] that makes it easy to use host mode needs a lot more than this, e.g. proper automounting, clean unmounting and sync, drivers for all kinds of peripherals etc.
-
It seems likely that a relatively simple kernel change should enable USB hostmode - http://focus.ti.com/lit/ug/spruf98d/spruf98d.pdf - search for FORCE_HOST - there may well be other cleaner solutions.
+
A USB OTG controller would normally switch between host and device mode (initially) using the ID pin, to detect if it's at the A or B-side of a OTG cable.  
-
A possibly related errata is detailed at 3.1.3 in [http://focus.ti.com/lit/er/sprz278d/sprz278d.pdf this document] - this, and other erratas may or may not cause issues with implementing host mode.
+
Initially it was claimed that ID is not connected externally, and that this made USB host mode impossible.
-
=USB socket=
+
While this is mostly correct, it needs some exemplification:
-
It seems that there is a USB socket hardware issue on some [[N900]] ...
+
* the ID pin is not connected to PHY, but it is connected to GAIA
 +
* MUSB-core has a hw statemachine that reacts on a telegram from PHY, telling MUSB-core about ID pin grounded and to enter OTG_A hostmode now.
 +
* Other PHY chips (e.g. in N810) have a command to make them send this telegram, so you can switch MUSB-core to hostmode under software control (go figure!). 1707 is missing this function.
 +
* There is apparently no way to tell MUSB-core directly to switch to hostmode in a natural way.
 +
* However there is a bit in MUSB-core registers called FORCE_HOST, which is switching MUSB-core into a semi-lobotomized test mode and allowed us to implement h-e-n.
-
May this depends on the build date, can you help and report details on your broken device :
+
===the following text needs update, it doesn't represent current state of investigation results anymore (corrections in ''(italic)'')===
-
* http://talk.maemo.org/poll.php?do=showresults&pollid=339
+
However, similar device datasheets indicate that the ID pin is used on hardware that supports it to switch between host and device mode.
 +
But, importantly, the ID pin does nothing directly to the state of the PHY. It simply informs the CPU ''(the MUSB-core)'' of the state of the ID pin, and leaves the driver to properly configure the chip (nota bene, only for OTG, and only for determining the inital state).
-
No reason to panic most users are not affected and it could be trivial to prevent or repair once investigated by some diy hackers...
+
So, if the kernel can be altered to ignore this pin - which should be trivial if there is host mode support for the chip in the kernel ''(the hw statemachine in MUSB-core won't play nice with whatever kernel does to enable hostmode in a "normal" way)''- then host mode works.(the related sourcecode is to be found here:[http://mxr.maemo.org/fremantle/source/kernel/drivers/usb/musb/musb_core.c#2010], a 'echo host >mode' should work if the kernel driver wasn't crippled in some strange way)''(h-e-n kernel hostmode now is working like this, but still needs another 'echo Fx >/proc/drivers/musb-hdrc' where 'x' is depending on speed. The kernel is "crippled" in a way it can not send a command to PHY to switch to hostmode, as the 1707 '''seems''' doesn't support this - further investigation needed, maybe it has this command but it isn't documented. Or we can spoof this command rsp the resulting telegram)''
-
=== what to do ? ===
+
The current understanding by several people who are working on USB host mode is:
-
Please fill ( template : nickname : build date ; SN  ; contact url or email ; notes ) , also tell hw version (" sysinfo-tool -g /device/hw-version" )
+
The USB port can supply power - at least 200mA (as demonstrated here:[http://talk.maemo.org/showthread.php?p=588950#post588950]). This is plenty for many devices - mice and keyboards.
-
* Ha... (TBC)
+
It seems likely that a relatively simple kernel change should enable USB hostmode - http://focus.ti.com/lit/ug/spruf98d/spruf98d.pdf - search for FORCE_HOST - there may well be other cleaner solutions. ''(h-e-n is exploiting this. About the "relatively simple" part that's up to your discretion)
-
* H...P... (TBC) http://talk.maemo.org/showthread.php?p=549339#1
+
''
-
* Sh.... (TBC)
+
-
* Z...n (TBC) : http://talk.maemo.org/showthread.php?p=548915#post548915
+
-
* T... : http://tabulacrypticum.wordpress.com/2009/12/13/connecting-on-the-surface-an-n900-risk/
+
-
* n... : http://talk.maemo.org/showthread.php?p=550378#post550378
+
-
* ... : http://talk.maemo.org/showthread.php?p=550704#post550704
+
-
* ...
+
-
Also answers polls :
+
A possibly related errata is detailed at 3.1.3 in [http://focus.ti.com/lit/er/sprz278d/sprz278d.pdf this document] - this, and other erratas may or may not cause issues with implementing host mode.
-
 
+
-
* http://talk.maemo.org/showthread.php?p=548177
+
-
* http://talk.maemo.org/showthread.php?t=37107
+
-
 
+
-
 
+
-
=== Solution ===
+
-
* Waranty :http://discussions.europe.nokia.com/t5/Maemo-Devices/Nokia-responds-to-reports-about-the-N900-micro-usb-port-getting/td-p/629019
+
==USB socket==
-
* DIY : may void Warranty ? http://talk.maemo.org/showthread.php?p=540344#post540344
+
-
* Repair :  http://www.nokia.com/repair
+
-
* Replace by a fixed one : http://www.astel.be/Les-Nokia-N900-suivants-tardent-defaut-de-fabrication-au-micro-USB_3568
+
-
* External charger : http://talk.maemo.org/showthread.php?t=45887
+
-
=== Misc ===
+
{{main|N900 Hardware USB Socket}}
-
* Please Avoid FUD, not sure it will help : http://slashdot.org/submission/1180314/Nokia-N900-Hardware-failure---USB-port-falling-off
+
===Compatible devices===
-
* http://img2.pixhost.org/images/668/1649730_img_0366_edit.jpg
+
{| class="wikitable sortable"
-
* data sheet : http://www.hirose.co.jp/cataloge_hp/e24200011.pdf
+
|+ Compatible USB devices
-
* hardware version : http://talk.maemo.org/showthread.php?t=46314&page=3
+
|-
 +
! USB device name
 +
! Status
 +
! class="unsortable" | Additional information
 +
! Additional driver needed
 +
! class="unsortable" | Discussion link
 +
|-
 +
| Edimax EU-4207 || Working || no problems found || <code>no</code> || http://talk.maemo.org/showthread.php?t=66667
 +
|-
 +
| ZTE-AC2766 || Working || no problems || <code>no, uses usbserial.ko</code> || http://talk.maemo.org/showpost.php?p=1198785&postcount=13
 +
|-
 +
|}
-
[[Category:N900_Hardware]]
+
[[Category:N900 Hardware]]

Latest revision as of 04:01, 21 August 2018

The USB connector on the N900 is a micro-b connector, as now required in European and Chinese markets, under the scheme to make all phone charger sockets identical.

Contents

[edit] USB implementation

The N900 seems initially to have been designed to be capable of acting as a USB host, or implementing OSG mode. This would have allowed keyboards, mice, and other peripherals to be plugged in.

The USB port with embedded host mode could not be certified, as the OTG drivers were not ready. (see [1] last block).

This lead to the the micro-AB USB connector being replaced by a micro-B, and the host functionality being officially removed short time before launch.

Lacking certification would have a large number of issues, from some operating systems requiring certification before allowing drivers to be distributed, to legal compliance with the USB charger specs - it would technically not be a USB port.

[edit] The Chips

There are four chips involved in the USB subsystem.

[edit] SoC

The System-on-a-chip is the main processor on the n900. This is the TI omap3430

[edit] Gaia

The TWL4030 is a TI companion chip to the SoC

[edit] USB battery charger

The bq24150a charger from TI is a flexible charger. It, along with the PHY chip - support charging without the intervention of the SoC when the system is charging from a completely dead battery. The PHY chip detects a charger (shorted D+ and D- pins) and the charger uses this information to charge more rapidly.

It also features reverse boost mode - which enables power to be supplied to a USB device connected to the N900. (up to a limit of 200mA)

For more information see N900 Hardware Battery Charger

[edit] USB Phy

The NXP isp1707a is used as the USB PHY chip. [2]. This rights to this part have been bought by ST-Ericson and some information is available in a brief marketing sheet.

There is no published datasheet for this chip. It may be available under another name.

A reasonably similar chip (compare chips: [3]) is the 1704 which has a datasheet [4]

Another equivalent chip seems to be the https://www.startpage.com/do/search?query=FUSB2500 - see http://talk.maemo.org/showthread.php?p=643577#post643577

For more information see N900 Hardware USB PHY

[edit] The Circuit

  • The SoC has the USB protocol controller - this is the 'high level' controller - it implements most of the USB protocol. This is a Mentorgrafix MUSBMHDRC-core IntelectualProperty function block licenced for the OMAP.
  • The PHY (physical layer) chip connects to the world through the USB socket. This is not the normal companion chip - but the NXP part, and is connected to the SoC via a standard ULPI interface. It does the very lowest level USB hardware protocol. Also it detects chargers (by sensing D+/D- short). It also has a connection to VBUS, via a 1k resistor, to do certain probing.
  • The bq24150a Battery charger. This is connected to the battery, and the PHY chip, as well as to the SoC though I2C. It handles (with the PHY chip) charging from dead. It also implements boost mode, to enable powering things through the USB socket. Of course it detects when external VBUS is applied.
  • Gaia. The TWL4030 is used to sense the value of the ID pin. It also has a connection to VBUS, to power up the device on charger insertion and inform a running system about changes in VBUS state. Though TWL4030 has a function similar to PHY chip as well, the original design using this function had to change as early chip revisions had problems with charger detection (so the rumour). Driver sourecode is full of cruft from that original design.

[edit] The Software

  • BME - the battery managment entity. This has its hands in everything, especially the bq24150a, and is split into
    • charger detection (via PHY) in kernel MUSB_HDRC driver, exposing /sys/devices/platform/musb_hdrc/charger
    • BME - userspace driver for the charger chip, as well as monitoring battery voltage through Gaia.
    • Hald-addon-bme - a small helper program to interface between HAL and BME.
  • Kernel driver.
    • This seems to be a partially implemented OTG driver for the initial design of the N900, with OTG mode partially implemented, assuming that the twl4030 would be used as the USB PHY. It seems to have been modified only to the extent required to make the NXP PHY work as a replacement.

[edit] Host mode details.

Host mode works, see this thread Mohammad started on talk.maemo.org, when releasing first beta of a package comprising of a hostmode patched kernel build by Paul Fertser with support of h-e-n team, and a lean GUI built by Mohammad. The basic functionality seems to work fine.

A user friendly implementation that makes it easy to use host mode needs a lot more than this, e.g. proper automounting, clean unmounting and sync, drivers for all kinds of peripherals etc.

A USB OTG controller would normally switch between host and device mode (initially) using the ID pin, to detect if it's at the A or B-side of a OTG cable.

Initially it was claimed that ID is not connected externally, and that this made USB host mode impossible.

While this is mostly correct, it needs some exemplification:

  • the ID pin is not connected to PHY, but it is connected to GAIA
  • MUSB-core has a hw statemachine that reacts on a telegram from PHY, telling MUSB-core about ID pin grounded and to enter OTG_A hostmode now.
  • Other PHY chips (e.g. in N810) have a command to make them send this telegram, so you can switch MUSB-core to hostmode under software control (go figure!). 1707 is missing this function.
  • There is apparently no way to tell MUSB-core directly to switch to hostmode in a natural way.
  • However there is a bit in MUSB-core registers called FORCE_HOST, which is switching MUSB-core into a semi-lobotomized test mode and allowed us to implement h-e-n.

[edit] the following text needs update, it doesn't represent current state of investigation results anymore (corrections in (italic))

However, similar device datasheets indicate that the ID pin is used on hardware that supports it to switch between host and device mode.

But, importantly, the ID pin does nothing directly to the state of the PHY. It simply informs the CPU (the MUSB-core) of the state of the ID pin, and leaves the driver to properly configure the chip (nota bene, only for OTG, and only for determining the inital state).

So, if the kernel can be altered to ignore this pin - which should be trivial if there is host mode support for the chip in the kernel (the hw statemachine in MUSB-core won't play nice with whatever kernel does to enable hostmode in a "normal" way)- then host mode works.(the related sourcecode is to be found here:[5], a 'echo host >mode' should work if the kernel driver wasn't crippled in some strange way)(h-e-n kernel hostmode now is working like this, but still needs another 'echo Fx >/proc/drivers/musb-hdrc' where 'x' is depending on speed. The kernel is "crippled" in a way it can not send a command to PHY to switch to hostmode, as the 1707 seems doesn't support this - further investigation needed, maybe it has this command but it isn't documented. Or we can spoof this command rsp the resulting telegram)

The current understanding by several people who are working on USB host mode is:

The USB port can supply power - at least 200mA (as demonstrated here:[6]). This is plenty for many devices - mice and keyboards.

It seems likely that a relatively simple kernel change should enable USB hostmode - http://focus.ti.com/lit/ug/spruf98d/spruf98d.pdf - search for FORCE_HOST - there may well be other cleaner solutions. (h-e-n is exploiting this. About the "relatively simple" part that's up to your discretion)

A possibly related errata is detailed at 3.1.3 in this document - this, and other erratas may or may not cause issues with implementing host mode.

[edit] USB socket

Main article: N900 Hardware USB Socket


[edit] Compatible devices

Compatible USB devices
USB device name Status Additional information Additional driver needed Discussion link
Edimax EU-4207 Working no problems found no http://talk.maemo.org/showthread.php?t=66667
ZTE-AC2766 Working no problems no, uses usbserial.ko http://talk.maemo.org/showpost.php?p=1198785&postcount=13