Google Unveils Nexus 7 Tablet, Nexus Q 'Social Streaming Device'

Through some stroke of fortune, your friendly editor Timothy Lord is at Google I/O watching the keynote. We'll be updating the story live (below the fold) with his updates as they stream in. Starting things off, he reported a few features of Android Jelly Bean. First, graphics will be triple-buffered for extra smoothness; the graphics demo was reportedly impressive enough that the audience swooned. Text input has been improved with new dictionaries and a predictive keyboard that will learn better over time. Additionally, voice typing will now work offline. English will be initially supported, with Farsi, Thai, and Hindi support to follow. Hit the link below to see further updates, including details on the Nexus 7 tablet and the Nexus Q streaming device.

 

HP Releases More WebOS Components for the TouchPad

About two months ago, HP made the first source releases of webOS components. Conspicuously absent, however, were the sources to the Luna system manager, and it was not possible to build an image for the TouchPad with what was available. On Tuesday, the webOS team released the Luna sources and build tools as "webOS Community Edition." This is acontinuation of their previous source releases, and is intended only for the TouchPad; Open webOS is still slated for release in September and will be designed for porting to new hardware platforms. Quoting the developers: "With the release of the webOS Community Edition you can now learn how the TouchPad works, modify your TouchPad experience and then apply that learning to Open webOS 1.0 in the future. We are excited to empower the community to create custom user experiences on the TouchPad. For example, developers can now modify the card view, launcher, notifications, Just Type and more." You can grab the latest over at Github. The developers claim you can build and install it onto actual hardware: anyone want to give it a shot?

serial-protocols.

http://itsme.home.xs4all.nl/projects/xda/serial-protocols.html

 

This is a description of protocols used on the various serial ports that exist in the xda-1. These ports are:

devicename	driver	uart address	irq	connects to
COM1:	serial.dll	a8030000	0010	external serial cable
COM3:	ircomm.dll			infrared port
COM2:	serial3.dll	a8050000	000f	gsm multiplexed protocols
COM8:	usb.dll	a8000000	000d	serial over USB
COM9:	serial2.dll	a8010000	0011	gsm bootloader

To be able to talk the multichannel protocol over COM2, you have to send this ioctl: DeviceIoControl (hCom,0xAAAA5679L, {0x84,0}, 2,0,0,0,0)

---

multi channel protocol

This protocol is what is sent over the internal port ( the strongarm serial port 1 at virtual address 0xa8050000, or physical 0x80050000 ). and it is what atdbg ( or rilcomtemp.exe ) dumps.

command	protocol channels supported
normal	11 14 16 17
dualtrace	11 14 17
dual	11 14 17

protocol	description
11	trace messages
12	other gsm trace
13	PCO trace
14	unknown
16	gsm at commands
17	peripheral control ( led, vibrator, battery)

the number you can specify after 'normal' and 'atcmd' seems to indicate something related to baud rate, looking at the type of crap that you see with different values.

Wait for turn on GSM...  GSM already on -> RESET !!  GSM turn on successed!!    -----------------------ULYSSE MODE---------------------------  Normal mode(UART2 --- UART3)      ******************************************************  InitDebugSerial using SERIAL PORT 2  ******************************************************  GSM RESET...  

after which things get interesting: in hex:

02 11 00 00 00 20 03 "Trace module started by the environment" 02  02 11 00 00 00 00 01 "RVT: Lost Message" 02  02 17 "4D01FF00004D" 02  02 16 "AT-Command Interpreter ready\r\n" 02  

now there are several things I can do:

request	reply
11 02	Exception: Unexpected Software Interrupt this seems to crash the gsm
14 02	02 14 00 10 10 10 10 02
17 02	02 17 "0000" 02
16 "at%ureg?0,4\r" 02	02 16 "a" 02 02 16 "t%ureg?0,4\r\r\n\r\n" "+EXT_UREG EA000446\r\n\r\n\r\n" "OK\r\n" 02

---

channel 17 - peripheral control

in this protocol everything is sent encoded as hexadecimal characters. the first digit indicates the length of the command sequence, the second digit is probably a device address. followed by the number of bytes ( in hex, so 2 digits per byte ) indicated by the first digit.

these devices are available I think:

address	description
1	led/vibrator
2	unknown
5	battery via cal
7	unknown
8	unknown
9	phone audio control
b	unknown
d	battery via ssp

in replies, the length+device nyble are followed by a hex-status byte, followed by <length> result bytes

sequence	action
51 00 00 00 00 00	led off
51 00 01 01 05 05	red led on
51 00 00 01 05 05	red led off
51 01 01 01 05 05	green led on
51 01 00 01 05 05	green led off
51 02 01 01 05 05	orange led on
51 02 00 01 05 05	orange led off
51 03 01 00 01 00	vibrator on
51 03 00 00 01 00	vibrator off
19 xx	phone mode ? something audio related
0d	request battery status via scc answer: 4D0180021FEF
05	request battery status via cal answer: 45FFFF0274B9

the last 2 bytes for the led/vibrator are the 'on', and 'off' time, so 510101000105 will give brief flashes and long spaces. or 510301000101 will alternate the vibrator

---

rsupgrade/monitor protocol

This protocol is what rsupgrade.exe uses to upload and execute the monitor to the gsm, used to flash a new radio stack.
(this talks to the strongarm serial port 3 at virtual address 0xa8010000, or physical 0x80010000 ) you can also use this protocol on the external serial port, when entering the utilities menu, selecting the option 'gsmrom to sd', with an sd card inserted. the xda then prompts the user to start 'pc-monitor'. (after close inspection of the bootloader code, it turns out that you are talking to an emulation of the gsm, in the bootloader.)

the code in the gsm rom handling this protocol is in the first 4K of the gsm rom. this code is never updated(well, not that I have seen) by radio stack upgrades, thus always leaving an option to rescue your radio stack if something went wrong upgrading.

I have not yet figured out what rsupgrade does to be able to talk to com9:
I think I did everything the same as I see rsupgrade doing, it just doesn't work for me.

the general request format is:

position	value	description
0	0xaa	header byte
1		length byte
2	0x00 .. 0x0b	command byte
>=3		data, if 0xaa occurs, it is escaped by doubling it

the general answer format is:

position	value	description
0	0xaa	header byte
1		length byte
2	0x00 .. 0x0b	command byte
3		status byte, 0x00= OK
>4		data, if 0xaa occurs, it is escaped by doubling it

below the packet formats, ( leaving out the '0xaa' )
with the number of 'x' specifying how many digits in each parameter.

command	request format	answer format
cmd00	get_monitor_id	01 00	05 00 00 ii mi ma info byte, minor, major version nr
cmd01	get_flash_memory_id	01 01	03 01 00 xx
cmd02	get_chip_id	01 02	03 02 00 xx
cmd03	get_board_id	01 03	03 03 00 xx
cmd04	erase_flash_memory	01 04	01 04
cmd05	write_flash_memory	01 05	10 05 00 xxxx xxxx xxxxxxxx first 16bit word is a checksum, last 32bit word is a crc
cmd06		01 06	03 06 00 xx
cmd07	read_parameters	04 07 xxxx xx	?? 07 00 xx [xxxx ...]
cmd08	write_parameters	?? 08 xxxx xx [xxxx ...]	01 08
cmd09	write srecords	01 09	06 09 00 xxxx xxxx first word is file checksum, second is ram checksum
cmd0a	execute monitor	05 0a xxxxxxxx	01 0a
cmd0b	write_flash_memory	01 0b	0a 05 00 xxxx xxxx xxxxxxxx

test program

I created this pocket pc tool to be able to test various bits and ioctls in the xda. the source is browsable here

on the top line, there are checkboxes, to control this: otherwise it is sent as ascii, followed by a CR (carriage return)

DTR, RTS	controls these rs232 lines
BREAK	sends a break
Infrared-mode	sets the uart in Infrared mode.
hex	the input edit box is interpreted as hexadecimal data.

the next line contains status indicators for this:

DSR,CTS,DCD,RING	the status of these rs232 lines
BRK	break was detected. - MS Comm api does not tell when the break ends
RLSD	? - [see ms docs]
rcv,xmit	these toggle on and off, with each packet received/sent

below each of these indicators is a counter, counting how often they have changed

then follows the userinput box, with a 'transmit' button

then a big output window

followed by 2 lines of bit indicators, the first line are the gpio bits, the second line the port at 0xa4000068 ( with the now I think wrong assumption, that 0xa4000064 controls the direction of these bits ). red means it is an input bit, black means it is an output bit. you can switch from input to output by tap+holding the bit. you can toggle its output value by tapping ig. a filled square is a '1' bit, an empty squere is a '0'. 
playing with these bits may damage your device, so first research by reverseengineering code that touches them, before just randomly fidling with them.

the bottom is a bit chaotic, and contains experimental checkboxes enable.disable it. for COM2: this enables shared use of the GSM at command channel. this seems to control the power of the gsm part. this seems to enable control of the power of the gsm part.

ril	send ioctl 0x03000318/0x03000314 to the RIL1: device,
com	send ioctl 0xaaaa5679 to the current device
dbg	enable/disable debugging info in the output window
gsm	controls bit 6 of 0xa4000068
mode	controls bit 6 of 0xa4000064
mem	toggles the value of 0xac0203c8 between 0 and 1
open	opens or closes the selected device

trace tools

on the xda-ii you can see raw output from the multichannel protocol in \Storage\XPanelLog*.pco files.
the at commands are logged in \Storage\Atdbg*.log
problem is however that these log files are not -always- written. or maybe only closed after they reach their maximum size ( about 2M )

to enable logging, set these registry keys:

[HKLM\SOFTWARE\HTC\ATDbgLog]  Enable=1    [HKLM\SOFTWARE\HTC\XPanel]  Enable=1