Roger Binns
2005-03-11 07:20:22 UTC
I just got a loaner LG VX8000 (Verizon) from RPI Wireless today. Here
are some initial observations and questions. Superficially the phone
is just like the VX7000 (and is almost indistinguishable in the user
interface). It also adds the ability for VZW to nickel and dime you,
err I mean play expensive low quality streaming video over EV-DO.
The phone appears to have two data storage areas. One is named Application
Memory and is 6.15MB in size. Another is named Content Memory and is
46.13MB. (The latter can contain up to 100 each of "Tunes", "Tune Shows"
and "Flix"). In answer to the memory config request it claims to actually
have 100MB (98,293,760 bytes).
Does anyone have an idea what OWS stands for? There is a top level OWS
directory that then has usr/content below it as well as some aptable, keytable
type files and MMC and PM directories. Within OWS/usr/content there are
subdirectories named bmp, gif, jpeg, midi, png, qcelp and temp. (If these
are actually used then it will be the fourth different scheme used on LG phones
in the last two years.) The OWS/usr/content subdirectories are all empty.
Like the VX7000 (which introduced the 3rd different scheme), there a top level
dload directory. Each media type is catalogued in two index files. One
is a conventional one. For example dload/image.dat starts like this:
0000 77 00 00 03 64 6c 6f 61 64 2f 69 6d 67 2f 30 33 w...dload/img/03
0010 31 30 30 35 31 39 30 30 61 2e 6a 70 67 00 00 00 10051900a.jpg...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0040 00 00 00 00 c9 5b 5b 2f 00 00 00 00 76 00 00 03 .....[[/....v...
0050 64 6c 6f 61 64 2f 69 6d 67 2f 30 33 31 30 30 35 dload/img/031005
0060 31 39 30 30 2e 6a 70 67 00 00 00 00 00 00 00 00 1900.jpg........
0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
There is a second 4 byte file named dload/imagesize.dat that is the
total size of all the image files added together. Note that the path
names in the index are absolute.
In addition to image.dat/imagesize.dat, there is sound.dat/soundsize.dat
and video.dat/videosize.dat. These are the same as on the VX7000.
Sound and images go in dload/snd and dload/img by default. Video follows
this pattern by going in brew/media! By this point we should be able
to deduce how many programmers worked on the firmware and that they didn't
talk to each other.
This phone also introduces two new types. There is an empty aod.dat/aodsize.dat
and premium.dat/prmsize.dat. (Note consistency of prmsize.dat. The same
directory is full of long filenames - why constrain to 8.3?)
The phone UI makes a distinction between ringtones, tunes and tune shows.
Presumably the last two are some half baked clone of iTunes.
It can read from the EFS at around 33kb/s, with the Windows driver.
We get 25kb/s with libusb on Linux and 20kb/s with libusb on Mac.
The standard LG device driver on Windows has yet another bug to
work around. With this phone after hammering away (eg during
backing up the whole filesystem), the win32api read method is
returning a negative number and not setting the windows equivalent
of errno. That is very wrong. There is no problem using our USB
code on Linux or Mac.
The brew directory contains two applications. One is named mediaasf
and the other is verizonmediaplayer.
There are a few GSM'isms scattered around, such as files with IMEI
in their name. My best guess is that now that Qualcomm also supports
GSM and even bringing Brew to GSM, they are making their reference
firmware have as much as common with both environments. (eg both
nvm/$SYS.ESN and nvm/$SYS.IMEI exist).
Roger
are some initial observations and questions. Superficially the phone
is just like the VX7000 (and is almost indistinguishable in the user
interface). It also adds the ability for VZW to nickel and dime you,
err I mean play expensive low quality streaming video over EV-DO.
The phone appears to have two data storage areas. One is named Application
Memory and is 6.15MB in size. Another is named Content Memory and is
46.13MB. (The latter can contain up to 100 each of "Tunes", "Tune Shows"
and "Flix"). In answer to the memory config request it claims to actually
have 100MB (98,293,760 bytes).
Does anyone have an idea what OWS stands for? There is a top level OWS
directory that then has usr/content below it as well as some aptable, keytable
type files and MMC and PM directories. Within OWS/usr/content there are
subdirectories named bmp, gif, jpeg, midi, png, qcelp and temp. (If these
are actually used then it will be the fourth different scheme used on LG phones
in the last two years.) The OWS/usr/content subdirectories are all empty.
Like the VX7000 (which introduced the 3rd different scheme), there a top level
dload directory. Each media type is catalogued in two index files. One
is a conventional one. For example dload/image.dat starts like this:
0000 77 00 00 03 64 6c 6f 61 64 2f 69 6d 67 2f 30 33 w...dload/img/03
0010 31 30 30 35 31 39 30 30 61 2e 6a 70 67 00 00 00 10051900a.jpg...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0040 00 00 00 00 c9 5b 5b 2f 00 00 00 00 76 00 00 03 .....[[/....v...
0050 64 6c 6f 61 64 2f 69 6d 67 2f 30 33 31 30 30 35 dload/img/031005
0060 31 39 30 30 2e 6a 70 67 00 00 00 00 00 00 00 00 1900.jpg........
0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
There is a second 4 byte file named dload/imagesize.dat that is the
total size of all the image files added together. Note that the path
names in the index are absolute.
In addition to image.dat/imagesize.dat, there is sound.dat/soundsize.dat
and video.dat/videosize.dat. These are the same as on the VX7000.
Sound and images go in dload/snd and dload/img by default. Video follows
this pattern by going in brew/media! By this point we should be able
to deduce how many programmers worked on the firmware and that they didn't
talk to each other.
This phone also introduces two new types. There is an empty aod.dat/aodsize.dat
and premium.dat/prmsize.dat. (Note consistency of prmsize.dat. The same
directory is full of long filenames - why constrain to 8.3?)
The phone UI makes a distinction between ringtones, tunes and tune shows.
Presumably the last two are some half baked clone of iTunes.
It can read from the EFS at around 33kb/s, with the Windows driver.
We get 25kb/s with libusb on Linux and 20kb/s with libusb on Mac.
The standard LG device driver on Windows has yet another bug to
work around. With this phone after hammering away (eg during
backing up the whole filesystem), the win32api read method is
returning a negative number and not setting the windows equivalent
of errno. That is very wrong. There is no problem using our USB
code on Linux or Mac.
The brew directory contains two applications. One is named mediaasf
and the other is verizonmediaplayer.
There are a few GSM'isms scattered around, such as files with IMEI
in their name. My best guess is that now that Qualcomm also supports
GSM and even bringing Brew to GSM, they are making their reference
firmware have as much as common with both environments. (eg both
nvm/$SYS.ESN and nvm/$SYS.IMEI exist).
Roger