Status so far
- I've posted some info to the site, but I'm trying to keep some of it
out of the public eye for now so that the Zipit folks don't go
changing things before we get to do any updates.
What we know so far:
Chips (thanks ZipitPet):
+ Cirrus EP7312-CR-90 (CPU)
+ Agere WL600114LY (and shielded radio)
+ Hynix HY5V26D (16MB SDRAM, 16 bits wide)
+ MX 29LV160ATxBC-70 (2MB Flash ROM)
+ LPC915 (8 bit uP, with 2 A->D, for digitizer ?)
+ WM8751 (stereo DAC)
+ several smaller ones
FCC Paperwork (thanks coderextreme):
arch.cfm for FCC filing ID PPQ-WL100BA51
o I will post these docs to this group hopefully tomorrow (to save
Login procedure (thanks me, and coderextreme):
1. Zipit connects to tracking URL, e.g.
1.5 That number appears to be called the Zippy/Zipit ID (ZID) and is
not obviously related to the serial number or MAC address on the
device. Can be alphanumeric, and not all exist [process to register
new Zipit?]. 12345678.txt or any other 8 chars returns ZID not
found for example.
2. Text file contains what we assume to be a version number, and a
location to fetch a ROM version. We have seen version numbers 1.0
and 1.99 (00000000.txt) and ROM files bootrom.t2.1.0.bin and
bootrom.t3.1.0.bin. The .txt with 1.99 points to the same ROM and
hash, so we don't know what will happen if we faked our own ZIDs to
2.5. Also has what appears to be an MD5 hash at the bottom, though
they all appear to be the same and do not match with a hash of
either of the .bin files
3. Connects directly to Instant Messaging servers after initial
check with home server.
ROM .bin (general)
o Most likely encrypted as strings, etc. do not return any obvious
o 2MB + 16 bytes exactly is likely the full contents of the flash
ROM plus a 16 byte key?
o Two versions do differ (significantly)
o Video is flakey after disassembly and reassembly
o JTAG ports seem to have been removed from final production version
o Radio is not as strong as first hoped (34.6-38.9 mW) but battery
life has been better than expected
o FCC users guide implies that they've had streaming audio working
(by pressing ctrl-a). It looks like it will use Musicmatch Jukebox
as a local server much like the Linksys wireless media player.
o Several bugs and lacking features as documented on my page
ZIDs (thanks coderextreme):
-also working, I think these addresses represent Zipit ID numbers
for activated clients since the URL listing seems somewhat random
which makes sense because a bunch are probably not sold yet and
those that were sold were not sold in order.
That's about all I have for now... get cracking and sharing!
- Additional info / comments from this and other threads:
> + LPC915 (8 bit uP, with 2 A->D, for digitizer ?)Could also be used for interfacing the external port (there is no
digitizer in the device)
> Also has what appears to be an MD5 hash at the bottom...Or some other hash / checksum. Don't see anything that says it is
> FCC Paperwork (thanks coderextreme) ...Thanks. The serial port wiring is most helpful. Haven't found any
direct connection to the outside world from the serial port
[the funky connector has at least two input pins]
> What you want to look for not jtag but the serial ports. TheI am assuming that's what the DBG pin does (short to ground).
> 7212/7312 has an internal boot loader, jumper one pin and the chip
> looks for a boot on it's first serial port.
> I suspect the pins are there, it
> beats having the eprom loaded before pcb insertion.
Access to the serial port is a trickier
Haven't found anything that gives direct access. In theory the 4 pin
connector could be used, but it is not a direct serial connection As-
More probing is needed (or fine wire soldering)
> You will want to build a Shoehorn and Hermit boot loader.That won't be necessary. The first challenge is to grab the existing
ROM (using the alternate boot method). That only needs to be done
once (what's the prize for whoever gets it first ?)
The device has a built-in firmware update (the 2MB+16B files). Since
all devices have WiFi, it can be used for all flash updates.
re: pending messages
The Yahoo download limit was exceeded very easily.
Let me know if you need more webspace.
re: ROM files
> ... Ithink they are almost certainly compressed (why wouldn'tyou?), but I'm not so sure that they'd be encrypted.
I think you have that backwards.
They are most certainly encrypted (/scrambled). The two versions
have nothing in common and the exact same size.
The size indicates they are not compressed (the ROM is 2MB is size,
and the upload file is exactly 2MB+16B)
> DRM: as I understand it, the DRM features of the '7312 are nothingmore
> than a unique 32 bit serial number and a (possibly unique?) 128bit random number.
True, and even if they use if for future device specific keying DRM,
I don't see the need. You will always need a PC connection (where
you can use existing DRM)
It may come into play for the ????????.txt file for initial
download. Not very important since you can easily spoof the server
and the downloads are not device specific.
> 2MB + 16 byte update filesize: this troubles me slightly. Assumingthey're
> booting from flash, then decompressing the executable intosdram....
There is 2MB of Flash ROM that contains the firmware, which includes
the ability to upgrade the flash (using WiFi of course).
I assume that the upgrade goes something like this:
+ download the 2MB+16B file from the WiFi internet connection to RAM
(enough RAM for that)
+ check to make sure it is complete
+ [critical step] burn 2MB image to Flash ROM
> there needs to be a vector table and somebootloader/startup/decompression code
>in the boot sector, right?My educated guess is that the all of this is in the same 2MB Flash
I see no room for a separate loader from the main 2MB of ROM
(there is a very small 128B boot sector in the CPU, but that's
If the image were screwed up, then you would have a dead device.
Therefore all firmware updates must include the firmware updating
software built in, and to do a good sanity check on the new firmware
image before reprogramming the flash ROM.
> > You will want to build a Shoehorn and Hermit boot loader.If you can get to com1, then you can boot using Shoehorn and use that
>That won't be necessary. The first challenge is to grab the existing
>ROM (using the alternate boot method). That only needs to be done
>once (what's the prize for whoever gets it first ?)
to grab the ROM.
> If you can get to com1, then you can boot using Shoehorn and usethat
> to grab the ROM.Exactly (or something like Shoehorn). Any approach that gets the ROM
image will do. It only needs to be done once (ie. no need to write a
long-term boot loader)
Getting to the COM1 port is a pain. I have probed the traces (easy
to figure out thanks to the Internal FCC photos). I can't find a
direct connection to the easy-access connections (eg: the DBG pin,
the 4 extra i/o pins). The DBG pin does not do what I wanted it to ;-
I may have missed something in the probing (tough on they eyes), or
they may be doing something trickier to burn the Flash ROM at the
factory [? perhaps the 2nd CPU]
Soldering directly to the traces may be the only option [oww my eyes
are burning... ]
Anyone else trying this ?
- At 07:53 PM 12/27/2004 +0000, ZipItPet wrote:
>If you replace all the code, you'll either need to include a bootloader or
>image will do. It only needs to be done once (ie. no need to write a
>long-term boot loader)
use the serial port to do any future updates. Am I missing something here?
>I may have missed something in the probing (tough on they eyes), orThe flash could have been programmed before assembly. I really doubt the
>they may be doing something trickier to burn the Flash ROM at the
>factory [? perhaps the 2nd CPU]
microcontroller is connected to the address and data bus.
>Soldering directly to the traces may be the only option [oww my eyesHas anyone been able to verify that the UART lines are in fact brought out
>are burning... ]
to a trace, via, or connector?
- --- In firstname.lastname@example.org, Scott Newell <newell@c...>
> If you replace all the code, you'll either need to include abootloader or
> use the serial port to do any future updates. Am I missingsomething here?
My assumption is there is no separate 'bootloader', but instead
bootloader-like features built into each and every new version of
ie. the entire 2MB of flash ROM appears to be in the update, you
reflash the entire thing, including the code that does future
reflashing (ie. screw up and the device is dead)
Serial port uploading doesn't appear to be available (in a stock
> The flash could have been programmed before assembly....Most likely the case.
BTW: The flash chip on my ZipIt has a little white paint dot on it
> Has anyone been able to verify that the UART lines are in factbrought out
> to a trace, via, or connector?I haven't found any that go directly to an external connector.
COM 1/2 lines are available near the chip. Difficult to solder to,
but not impossible.
Check the FCC internal photos and they are pretty easy to figure out
(the evaluation unit has COM1 and COM2 headers, the final units have
the traces shortened)
The RX has a pullup resistor to VCC (R121 - easy to solder to)
The TX out is available in a via near the chip -- appears to be
turned off (low signal) if I have the right one.
The tricky part is the "nMEDCHG" pin which must be driven low before
power-on for the magic boot sequence to happen.
Thx for the info. Have you by chance soldered the level-shifters for
the serial onto the COM1 traces ? I'm wondering if there's any output
during boot or the application.
Also, has anyone run NMAP on their device to fingerprint the OS ? I"m
wondering if it's running linux or a just a custom app.
1.75 MB for root fs including linux loaded to ramdisk
maybe a small partition for saving the buddy list ?
It is possible.
--- In email@example.com, "ZipItPet" <aibopet@a...> wrote:
> --- In firstname.lastname@example.org, Scott Newell <newell@c...>
> > If you replace all the code, you'll either need to include a
> bootloader or
> > use the serial port to do any future updates. Am I missing
> something here?
> My assumption is there is no separate 'bootloader', but instead
> bootloader-like features built into each and every new version of
> the firmware
> ie. the entire 2MB of flash ROM appears to be in the update, you
> reflash the entire thing, including the code that does future
> reflashing (ie. screw up and the device is dead)
> Serial port uploading doesn't appear to be available (in a stock
> > The flash could have been programmed before assembly....
> Most likely the case.
> BTW: The flash chip on my ZipIt has a little white paint dot on it
> > Has anyone been able to verify that the UART lines are in fact
> brought out
> > to a trace, via, or connector?
> I haven't found any that go directly to an external connector.
> COM 1/2 lines are available near the chip. Difficult to solder to,
> but not impossible.
> Check the FCC internal photos and they are pretty easy to figure out
> (the evaluation unit has COM1 and COM2 headers, the final units have
> the traces shortened)
> The RX has a pullup resistor to VCC (R121 - easy to solder to)
> The TX out is available in a via near the chip -- appears to be
> turned off (low signal) if I have the right one.
> The tricky part is the "nMEDCHG" pin which must be driven low before
> power-on for the magic boot sequence to happen.
> Have you by chance soldered the level-shifters foroutput during boot or the application.
> the serial onto the COM1 traces ? I'm wondering if there's any
Nothing seen during normal running.
With the magical boot sequence enabled there is a lonely '<' sent to
the COM1 port at 9800 baud
[See the boot sequence source code in the appendix of the CPU manual]
I've only seen this once (or maybe I was dreaming...)
Currently my impromptu wiring is flakey. If someone has better
tools/skills for small PCB probing and wants to help out, that would
[if not I may get back to this sometime later in 2005 - or wait to
see if ZipIt takes off or fizzles out]