Status of development kernel that is tracking mainline
Running a mainline kernel on your GTA04
Unfortunately you cannot (yet) run a mainline kernel (from Linus) on your GTA04. There are 3 main reasons for this.
Bugs. Untested code is buggy code and as few people have had a GTA04 for long, few people have tested mainline on that hardware so there are doubtlessly bugs. As bugs are identified and fixed the fixes should get upstream relatively easily.
Missing drivers. While much of the hardware in the GTA04 has drivers in mainline, there are a few exceptions. As drivers are written it should not be too hard to get them upstream, though we should expect at least one release cycle before they are included.
Explicit board support. This topic is slightly more complicated.
Previously each distinct "board" (printed circuit board with components) would have a dedicated "board" file which describes the various components and how they are connected. This approach means that each different board needs a different kernel specially compiled for it. This is not good for distributors who want to provide a single kernel that can boot anywhere.
The new approach is to describe the hardware using a "device tree" file. The kernel then reads this file and initialises all the requires devices appropriately. With Linux 3.19 support for the device tree has been added.
Consequently it is not likely that our GTA04 board file will ever get into mainline Linux so we won't be able to run a pure mainline kernel until device-tree support is sufficiently complete, and we have a device-tree file for GTA04. This is not a serious problem and is really just a good goal to help work towards. The current device tree file is omap3-gta04.dts.
More information about the device tree can be found at http://www.devicetree.org. On 2014-11-30 Dr. Nikolaus Schaller held a talk about the device tree from the view of GTA04 at the 6th OSHW. The talk has been recorded and the slides are available.
The remainder of this page describes the state of support for each component and feature on the GTA04, identifying what is implemented, how much is upstream, and what still needs to be done.
It is sorted in either of the categories Needs Work, Untested, Non-Existent Driver and Working.
The code described here can be found in the "gta04/3.3.y" branch of git://github.com/neilbrown/linux.git and the "3.3-gta04" branch of git://neil.brown.name/gta04
Status of support
Being cautious, I (NeilBrown) will only report that something does work if I have personally tested it. Otherwise I may just say that it is reported to work. Others are welcome to add specific test results.
Disclaimer:
The content was written in reference to the status of the 3.3 mainline kernel. Information might be out of date.
Needs Work
GSM/UMTS
Connected via USB and appears as:
- 6 tty ports ttyHS0 - ttyHS1. In /sys/class/tty/ttyHS?/hsotype these report as: "Diagnostic", "GPS", "GPS Control", "Application", "Control", "Modem".
- A network interface "hso0"
- an rfkill interface "hso-5"
- An audio interface "gta04voice" which has no mixer controls.
This seems to work appropriately though there are some odd issues.
All async notification arrive on the 'Application' interface except the "NO CARRIER" notification when a caller hangs up - this arrives on the "MODEM" interface.
Sometimes the module seems to 'crash' and all the tty ports are reset and need to be re-opened.
Wake-from-suspend on incoming call and SMS works. It can be detected via 'poll' on /sys/class/gpio/gpio176/value - setting '.../edge' to 'rising' first.
Driver is upstream, however a small patch to driver is needed to improve power usage. Patch has not been sent upstream.
Runtime Power Management
runtime power management involves powering down individual components when they are not in active use. Ideally this should bring current usage close to suspend current levels when most things are idle.
Currently:
- wifi, USB-port, audio seem to auto-power-down correctly.
- Internal USB (connecting the GSM chip) powers down.
- Bluetooth, GSM need to be explicitly controlled.
- LEDs are naturally low-power when not used.
- GSM does it's own power management.
I have measures about 65mA as lowest idle current drain though this is not stable. We should be able to get a lot less.
Future work
- Find out where the power is going.
Battery Charging
This works but there is room for improvement.
When power is available on the USB port the GTA04 will try to draw 600mA of current to run the device and charge the battery. This is fine for a charger and probably OK for a USB port on a powered hub or PC (which are only really meant to deliver 500mA) but would be bad on an unpowered hub or USB-1.1 port.
The charge current can be changed by writing a number of microamps to /sys/class/power_supply/twl4030_usb/device/max_current.
Charging is disabled when machine is turned off.
The backup battery is charged when needed.
If battery is flat, device will charge battery slowly and will not turn on until voltage level reaches a threshold. There should then be enough charge in the battery to keep the device alive until the charging circuitry is enabled. This has been tested a couple of times and takes a couple of minutes before boot starts.
Most of the driver is upstream but various fixes to make it work well - e.g. to work with the Openmoko charger or to charge the backup battery - are not upstream. I probably won't submit them until I have a clearer idea how it all should work.
Future work
- reliably detect charger and only draw high current when charger is present
- only draw any current from non-charger if host as said it is OK.
- possibly keep charger active when off.
Power-Off
Works, but also powers-off battery charger.
Once powered-off only the power-button or an RTC alarm will wake the device.
Future work
- possibly leave battery charger on at power-off
Suspend power saving
Current suspend works but does not save as much power as expected. We expect to draw around 10mA during suspend but actually draw about 25mA providing all volume controls are set as described above.
Future work
- Identify cause of power drain and rectify it.
Audio
Audio in through main mic and headset mic, and out through earpiece, speaker, and headset work using "gta04" sound device.
There are many more mixer controls than are meaningful of the way the hardware is configured.
The core driver is upstream but the board configuration for the GTA04 (which is separate from other board configuration) is not.
Future work
The visible mixer controls should be limited to those which are meaningful.
Power saving does not seem to be properly enabled and the sound card wastes a lot of power. Turning all mixer controls to a minimum and muting everything possible is advised and can save 10s of milliamps. This needs to be fixed.
USB gadget
Tested with g_ether (ethernet device) and g_mass_storage. Should work with all gadget drivers.
Currently reports that 2mA of current is needed, but will try to draw 600mA to charge the battery.
Driver is upstream.
Future work
- Report sensible current draw and stick to it. Maybe report several version of each function with different current draws, and only charge battery if high-current function was selected by host.
USB OTG
When a USB-OTG connector cable is used, can drive a device that claim to need at most 100mA and will provide 100mA current.
My USB flash drives claim to need 200mA so I hacked the code to accept that and then I successfully mounted a filesystem of such a device.
My wireless pocket-size keyboard claims to only need 100mA but does not work when plugged in. Maybe it needs more than 100mA.
Driver is upstream.
GPS
Providing the hardware mod has been made (for GTA04A3) GPS works well. Data appears through /dev/ttyO1.
Power to the Antenna is controlled using the 'GPS' rfkill device.
The GPS device is turned on or off by writing "0" then "1" to /sys/class/gpio/gpio145/value. Writing these two values toggles off->on or on->off.
The external antenna can be detected by inspecting /sys/class/gpio/gpio144/value which will be '1' if the 'rfkill' device is enabled and the external antenna is installed.
Future work
- Integrate the on/off toggle into the 'rfkill' device.
- export the 'external antenna' connected via a 'switch' or 'extcon' class device once one of the other arrives in mainline.
Accelerometer
There is a simplistic driver for the BMA150 which is an earlier version of the accelerometer. This has been hacked to work with the BMA180 for testing. A proper driver will eventually be written to replace this, so don't depend on current functionality.
When this is configured in it normally appears as /dev/input/event1 pushing the buttons up to '2' and '3'.
Compass
A driver for the HMC5843 is upstream. This driver should work with the HMC5883L with minor modifications since both chips are quite similar.
Future work:
- Add interrupt handling (new data available)
Barometer / Thermometer
Driver for BMP085 is upstream (in misc/) and works well.
Future work:
- Add interrupt handling (new data available)
Gyroscope
Driver for ITG3200 is available from https://gitorious.org/freerunner-navigation-board/itg3200. It exports a quick and dirty sysfs interface. Needs to be cleaned up and a proper interface (input/IIO/whatever) should be added.
Future work:
- Add meaningful interface.
- Add interrupt handling.
LCD display
Works well, though sometimes it flickers a bit, particularly when tapping on screen. Maybe some sort of timing issue?
Driver for the video controller in the OMAP SOC is upstream. Driver for the LCD controller needs cleaning up before it can be submitted.
Untested
- IrDA
- Headset Detect
- Video-out
- Camera
Non-Existent Driver
- FM radio transceiver
Working
Wake from suspend
- AUX button and serial receive reliably wake from suspend.
- power button, RTC alarm, and USB plug/unplug wake from suspend.
- GSM incoming should wake from suspend.
- touch-screen tap could be configured to wake from suspend but isn't.
LCD backlight
Works and brightness can be adjusted. Visible in /sys/class/backlight/pwm-backlight/
Requires omap "pwm" driver which is not yet upstream.
Touch Screen
Works well. Appears (typically) as /dev/input/event0.
Driver is upstream.
uSD card
Works reliably. Powers down when not in use. Is not auto-ejected on suspend.
Driver is upstream.
Serial ports
There are 3 serial ports: Which appear as ttyO0, ttyO1, ttyO2.
ttyO0 is connected to bluetooth and is reported to work. Special care is needed to run at speeds above 115200 bps, but this is reportedly possible.
ttyO1 is connected to GPS. This works reliably.
ttyO2 is the 'console' port which is available through the 8 pin connector on the back of the board. This works reliably.
Early printk works, so when configure you can see messages as soon as boot starts.
Wake from suspend on data-received works (for console at least).
Driver is upstream.
When aggressive power-saving is enabled, the UART is likely to lose or corrupt the first character it receives. This applied to baud rates from 115200 up. Lower baud rates are not affects.
Bluetooth
Reported to work. HCI-UART access is via ttyO0. Audio access is via the "gta04headset" ALSA device. There are no mixer controls.
Power supply is managed by rfkill device "Bluetooth". Blocking this device does not actually remove power unless the wifi device is also inactive.
Driver is upstream.
Wifi
Works well, and powers-off when not in use (unless bluetooth is keeping the power supply on).
Driver is upstream but requires a closed firmware blob which is free-to-distribute.
LEDs
Works and provides hardware support for blinking at a range of rates. Will remain on in suspend and will continue blinking in suspend if a blink rate was selected which is supported by the hardware (on and off times between 300 and 27000ms are supported as are a few others).
Driver is upstream from 3.3-rc1.
AUX and Power buttons
Work and are reported (normally) through /dev/input/event1 and /dev/input/event2. Either will wake-from-suspend.
The AUX button generates "KEY_PHONE", the power button generates "KEY_POWER".
Driver is upstream.
Vibrator
Reported to work.
Controlled via the Audio device.
Driver is upstream.
An alternate drive controls the vibrator via an 'input' device using the 'force feedback' framework.
Reboot
Device reboots cleanly when requested to.