Nokia Booklet 3G - Sensors

February 3, 2022    Article    2007 words    10 mins read
Nokia Booklet 3G - Sensors

Note

This article started as a section in the large Nokia Booklet 3G page but I decided to make a separate copy just in case someone wants to play with I2C sensors.

You can access the Nokia Booklet sensors in Linux if you install the required packages.

Temperature

Main thermal sensor is a SMSC EMC1402-1 that is connected to the SMBus and is linked to an external diode on the CPU via the THRMDA and THRMDC pins (T5, U4) ↔ DP and DN (2, 3).

$ sudo apt install hddtemp lm-sensors
$ sudo sensors-detect
$ sudo modprobe drivetemp

And you can view the temperature using the sensors tool:

$ sensors
BAT1-acpi-0
Adapter: ACPI interface
in0:          16.51 V
curr1:         0.00 A

drivetemp-scsi-0-0
Adapter: SCSI adapter
temp1:        +39.0°C  (low  =  +5.0°C, high = +55.0°C)
                       (crit low =  +5.0°C, crit = +55.0°C)
                       (lowest =  +0.0°C, highest = +43.0°C)

coretemp-isa-0000
Adapter: ISA adapter
Core 0:       +26.0°C  (crit = +90.0°C)

Dump the names of the hwmon devices:

$ grep . /sys/class/hwmon/hwmon[0123456]/name
/sys/class/hwmon/hwmon0/name:BAT1
/sys/class/hwmon/hwmon1/name:coretemp
/sys/class/hwmon/hwmon2/name:ACAD
/sys/class/hwmon/hwmon3/name:drivetemp

If you don’t use modprobe to load the drivetemp kernel module (so that you have HDD temperature reading into the sensors utility) you will need to use the hddtemp tool to view the HDD temperature.

$ sudo hddtemp /dev/sda
/dev/sda: TOSHIBA MK1235GSL: 40°C

Light and accelerometer

The light (TAOS TSL2561FN) and accelerometer (NXP MMA7455LR1) sensors are connected to the SMBus so I need to do some additional probing in order to detect them. Start by installing the required packages.

$ sudo apt install i2c-tools
$ sudo modprobe i2c_dev

The i2c-tools package contains some very useful utilities:

  • i2cdetect - to detect I2C chips.
  • i2cget - to read from I2C/SMBus chip registers.
  • i2cset - to set I2C registers.
  • i2cdump - to dump I2C registers.

Now I can use i2cdetect to scan and return a list of all I2C devices.

$ sudo i2cdetect -l
i2c-15	i2c       	intel drm LVDSBLC_B             	I2C adapter
i2c-3	i2c       	gma500 gmbus vga                	I2C adapter
i2c-13	i2c       	gma500 GPIOF                    	I2C adapter
i2c-1	i2c       	gma500 gmbus ssc                	I2C adapter
i2c-11	i2c       	gma500 gmbus reserved           	I2C adapter
i2c-8	i2c       	gma500 GPIOD                    	I2C adapter
i2c-6	i2c       	gma500 GPIOC                    	I2C adapter
i2c-16	i2c       	intel drm LVDSDDC_C             	I2C adapter
i2c-4	i2c       	gma500 GPIOA                    	I2C adapter
i2c-14	smbus     	SMBus SCH adapter at 1100       	SMBus adapter
i2c-2	i2c       	gma500 GPIOB                    	I2C adapter
i2c-12	i2c       	gma500 gmbus dpd                	I2C adapter
i2c-0	i2c       	gma500 gmbus disabled           	I2C adapter
i2c-9	i2c       	gma500 gmbus dpb                	I2C adapter
i2c-10	i2c       	gma500 GPIOE                    	I2C adapter
i2c-7	i2c       	gma500 gmbus dpc                	I2C adapter
i2c-17	i2c       	SDVO DDC proxy                  	I2C adapter
i2c-5	i2c       	gma500 gmbus panel              	I2C adapter

Most of the buses belong to the Intel GMA 500 Poulsbo video “card” but let’s scan them anyway to see if we can find anything cute.

  • gma500 gmbus ssc / gma500 GPIOB -
  • gma500 gmbus vga / gma500 GPIOA -
  • gma500 gmbus panel / gma500 GPIOC -
  • gma500 gmbus dpc / gma500 GPIOD - HDMIC
  • gma500 gmbus dpb / gma500 GPIOE - SDVO, HDMIB
  • gma500 gmbus dpd / gma500 GPIOF - HDMID

Let’s scan one of the buses for all the possible devices on that bus:

$ sudo i2cdetect -y -r 10
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- 38 -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

In the example above I used i2cdetect to scan the bus number 10, the output of the command will be an array of all device address locations on that bus, with -- (address probed but no device responded), UU (address not probed because it is in use by a driver) or a device address, as its value. So there is something on the bus number 10, address 0x38.

Figuring out what type of device is sitting on that bus address is a bit more complex. I used the I2C Database to check a list of the devices that are known to be at that address and this is the result:

AHT10 - ASAIR Humidity and Temperature sensor
BMA150 - Digital triaxial acceleration sensor
FT6x06 - Capacitive Touch Driver
PCF8574AP - I²C-bus to parallel port expander
SAA1064 - 4-digit LED driver
SEN-15892 - Zio Qwiic Loudness Sensor
VEML6070 - UVA Light Sensor with I2C Interface

Now, I have to admit I have no idea what the device is, because there is no chip in that list that can be found on the Booklet boards.

The Booklet accelerometer is an NXP MMA7455LR1 and the only thing I could find in the I2C database is NXP MMA845x, which seems to sit on address 0x1c and 0x1d. source

The light sensor in the Nokia Booklet is a TAOS TSL2561FN and that specific sensor is in the I2C database but listed as sitting on 0x39 and 0x49. source I guess the sensor can be on the 0x38 address in the Booklet because it’s a custom device and not a separate chip, but the device at that address is not responding as expected for a TSL2561FN.

Checking the datasheet I noticed the ID register is 0x0a so I tried to get something from it.

$ sudo i2cget -y 10 0x38 0x0a w
0x0000

From the chip’s datasheet Part Number Identification: field value 0000 = TSL2560, field value 0001 = TSL2561 but the chip is definitely a TSL2561, so I’m stuck. Last attempt, let’s dump the I2C block for the device at this address:

$ sudo i2cdump -y 10 0x38 i
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 00 00 00 00 00 00 00 02 7a 01 00 00 00 00 00 00    .......?z?......
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
30: 00 00 00 00 0f 00 68 00 00 82 02 00 00 00 00 00    ....?.h..??.....
40: 01 20 00 00 00 00 43 02 00 00 00 00 00 00 00 00    ? ....C?........
50: 11 40 00 00 11 03 01 34 1b 18 05 01 aa 02 00 00    ?@..???4??????..
60: 11 15 01 00 00 11 03 02 00 e8 03 00 05 1e 96 00    ???..???.??.???.
70: 00 00 00 00 00 00 00 00 00 00 00 00 1e 00 00 00    ............?...
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

Let’s scan another bus.

$ sudo i2cdetect -y -r 5
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

Bus 5, address 0x50, devices known to sit on that address, nothing familiar. But the name of the bus is gma500 gmbus panel, so it must be something linked to the laptop screen, right? Let’s dump the I2C block for the device at this address:

$ sudo i2cdump -y 5 0x50 i
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 00 ff ff ff ff ff ff 00 06 af d5 11 00 00 00 00    ........????....
10: 01 13 01 03 80 16 0d 78 0a d1 15 94 56 55 93 29    ???????x????VU?)
20: 23 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01    #PT...??????????
30: 01 01 01 01 01 01 06 18 00 70 50 d0 10 20 30 20    ????????.pP?? 0
40: 36 00 de 7d 00 00 00 18 00 00 00 0f 00 00 00 00    6.?}...?...?....
50: 00 00 00 00 00 00 00 00 00 20 00 00 00 fe 00 41    ......... ...?.A
60: 55 4f 0a 20 20 20 20 20 20 20 20 20 00 00 00 fe    UO?         ...?
70: 00 42 31 30 31 45 57 30 31 20 56 31 20 0a 00 c3    .B101EW01 V1 ?.?
80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................

The B101EW01 string jumps into attention because it’s the name of the display.

Let’s scan one more bus:

$ sudo i2cdetect -y -r 14
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- 69 -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

Bus 14, address 0x69, possible devices. Some InvenSense gyroscopes, accelerometers and/or magnetometers but no NXP MMA7455LR1.

Freaking hell.