I'm working on it.  The design is relatively simple.

What i've done so far.
Pull off the back of the Zipit, then peel off film from the back of
the Zipit screen.  Clean the back of the LCD with a solvent and press
a piece of semi transparent paper/plastic against the back of the
screen(it should stick).

What I plan to do.
Glue 8 bright LEDs to each corner and in between each corner pointing
towards the center of the zipit.  Wire them up in parrellel and wire a
resistor between the positive wire and positive battery solder point
on the Zipit to prevent overvoltage.  Solder the negative LED line to
a switch that can operate outside the zipit and the other terminal of
the switch to the negative battery solder point on the board.  I plan
to drill out the plate that covers the back of the LCD to make room
for the LEDs, put it all back together and enjoy.

The LEDs should draw 160mA total which should barely effect the 1100
mAH battery.

Answers within...

--- In zipitwireless@yahoogroups.com, "Dan M." <estefan@c...> wrote:
>
> Have a few questions?
>
> 1) Could the 2 ports on the back, by the headphone jack be capable
of
> connecting to a dongle for wired access ?

Doubtful since there's no NIC on the board.  But I can't offer any
other suggestion what it might be, other than controls for media
playback on headphones.

> 2) someone mentioned a mod for a back light for the display, did it
work,
> and do you have  directions for the mod?

I haven't heard, but that would be nice to have included.

> 3) on power off there is a brief display screen, but it shuts down
too
> fast, anyone know what it is?

I believe it's the same prompt you get when you log on from another
device.  The Zipit for some reason doesn't support multiple logins on
one account.  I don't know why it would be appearing while logging
off.  Anyone?

   --Darren

Have a few questions?

1) Could the 2 ports on the back, by the headphone jack be capable of
connecting to a dongle for wired access ?

2) someone mentioned a mod for a back light for the display, did it work,
and do you have  directions for the mod?

3) on power off there is a brief display screen, but it shuts down too
fast, anyone know what it is?

Thanks
Dan



--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.6.11 - Release Date: 1/12/2005

What's in ROM?
After a few false starts, I finally grabbed the ROM contents. Here's
my prelim analysis.

Embedded Linux / ARM Linux experts, please see "General Q:"
for questions or other areas where more in-depth knowledge would
help.

----------------------------------------------------------
The ZipIt device has 2MB or Flash ROM and 16MB of RAM

The Flash ROM contains a small boot loader, and Gziped images of the
Linux kernel and ramdisk. These get expanded to RAM when the device
boots.
At the end of the Flash ROM is a small area where settings are saved
(eg: passwords, SSIDs etc).

FlashROM Memory Map: (current version)
00000000 : boot loader
00010000 : more loader, gzip
00012BEC : start of gzipped Linux kernel image (over 1MB expanded)
000A0000 : start of gzipped Linux ramdisk image (over 4MB expanded)
001F0000 : Flash stored properties -- "AerMedia Properties"
001FFFFF: end of FlashROM (2MB)

------------------------------------------------------------------

What's in ROM - Linux

The linux kernel build string is:
"Linux version 2.4.21-rmk1 (root@sambaman) (gcc version 3.2) #15 Wed
Apr 21 16:01:33 UTC 2004"

Most components were built a long time ago (2002 or 2003). I assume
they are not customized for the ZipIt.

See the file uploads for how to mount and examine the 'ramdisk'
partition
Looks like many standard things and one big custom app.

in /lib/modules are a few dynamic loaded modules
audiodrv.o [audio],
wlags49_h2_cs.o, wlags49_h25_cs.o [WiFi]

General Q: Anything else out of the ordinary ?
General Q: Any good tool for dumping 'kernel.gz' ?

----------------------------------------------------------------
What's in ramdisk -- init script

The brief init script, /sbin/init

-----
[a bunch of echo statements]
/bin/mount /proc
/sbin/ifconfig lo 127.0.0.1
insmod /lib/modules/audiodrv.o

cd /usr/bin
/bin/ash &
./Zipit
/bin/ash
------

-----------------------------------------------------------------
What's in ramdisk - custom app "Zipit"

The /usr/bin/Zipit app is a 1.6MB program that has all the goodies
in it.
It uses a number of support files for the user interface
Sounds are in standard WAV format (/usr/bin/Sounds)
Images are in standard BMP format (/usr/bin/GUI)
The user interface is stored in .SDF data files for the different
pages (/usr/bin/SDFs)
Looks like a proprietary format ??

A quick disassembly (objdump) show lots of potential, but the
program is big and without souce (audio processing routines, WMA
compatability, not to mention all the existing IM functionality)

General Q: anybody want to disassemble this sucker ?

Other ideas? or should we pitch this app and try to use the basic
Linux core features ?

Uploaded to the files section:

http://groups.yahoo.com/group/zipitwireless/files/Linux%20Raw%20data

NOTE: contains both GPL Linux software, as well as Zipit specific
application program and data.
Intended for fair use education for owners of Zipit devices only

---------
The 2MB ROM image contains a bootloader, updatable variables and
GZIP files for both the kernel image and the ramdisk fs image

kernel.gz - GZIPed kernel image (expands to over 1MB)
ramdisk.gz - GZIPed ramdisk image (expands to over 4MB)

To examine the files on the ramdisk you need a Linux box.
Un-gzip the ramdisk.gz file and mount it.
Something like:

  cp ??? /tmp/ramdisk.gz
  gzip -d /tmp/ramdisk.gz
  mkdir /mnt/ramdisk
  mount /tmp/ramdisk /mnt/ramdisk -o loop


  [ then look into the /mnt/ramdisk directory ]

I believe this is the latest version of the ROM update.

--- In zipitwireless@yahoogroups.com, "trb" <gentoo@n...> wrote:
> I've probably already have the kernel and rootfs source. I've got a
> few Cirrus Development boards (EP93xx based), the follow-on to the
> chip series used in the Zipit.

Please take a look and let me know if you find anything interesting
in the system components.

> So, did the serial bootloader work, or did you have to unsolder
the flash
> and read it out with another piece of hardware?

The FCC photos lead me to using the wrong pins.
I was getting ready to yank the chip....but I don't have proper BGA
hardware

----
However, I found enough pins to do the bootloader trick

I won't get into too much detail here [at least until I find a
reliable way of reflashing the sucker]

Congrats!

I've probably already have the kernel and rootfs source. I've got a
few Cirrus Development boards (EP93xx based), the follow-on to the
chip series used in the Zipit.

I'm doing development work on that processor. I'm looking forward to
finding out more, sorry I've been busy hacking another device, the
NSLU2.



--- In zipitwireless@yahoogroups.com, "ZipItPet" <aibopet@a...> wrote:
>
> --- In zipitwireless@yahoogroups.com, "Darren Madams" <dspyder@y...>
> wrote:
> > ... what makes you sure it's Linux?  And which
> > version?
>
> Because it says so in the kernel ;->
>
> "Linux version 2.4.21-rmk1 (root@sambaman) (gcc version 3.2) #15 Wed
> Apr 21 16:01:33 UTC 2004"
>
> Gziped kernel and ramdisk images in the ROM.
>
> ----
> > For reference, they're only required to release their
> modifications
> > to kernal and module, not their stand-alone app.
>
> That's why source release is less interesting in this case ;-<
>
> All of the interesting ZipIt functionality is in one 1.6MB
> (copyrighted) custom program and a few data files. The system
> modifications look trivial (most files dated 2002 or 2003, a few
> library module .o files)
>
> ----
>
> Will post a mini-summary of recent discoveries in a separate thread
> later today ("Whats in ROM").

At 11:10 AM 1/11/2005 , ZipItPet wrote:
>
>Will post a mini-summary of recent discoveries in a separate thread
>later today ("Whats in ROM").

Great!

So, did the serial bootloader work, or did you have to unsolder the flash
and read it out with another piece of hardware?

--
newell

--- In zipitwireless@yahoogroups.com, "Darren Madams" <dspyder@y...>
wrote:
> ... what makes you sure it's Linux?  And which
> version?

Because it says so in the kernel ;->

"Linux version 2.4.21-rmk1 (root@sambaman) (gcc version 3.2) #15 Wed
Apr 21 16:01:33 UTC 2004"

Gziped kernel and ramdisk images in the ROM.

----
> For reference, they're only required to release their
modifications
> to kernal and module, not their stand-alone app.

That's why source release is less interesting in this case ;-<

All of the interesting ZipIt functionality is in one 1.6MB
(copyrighted) custom program and a few data files. The system
modifications look trivial (most files dated 2002 or 2003, a few
library module .o files)

----

Will post a mini-summary of recent discoveries in a separate thread
later today ("Whats in ROM").

Replying to myself.... I meant to include this gem from Slashdot too:

http://developers.slashdot.org/article.pl?
sid=04/01/15/2350216&tid=185&tid=117&tid=123&tid=8

   --Darren

--- In zipitwireless@yahoogroups.com, "Darren Madams" <dspyder@y...>
wrote:
>
> This is a good thing... what makes you sure it's Linux?  And which
> version?
>
> GPL violations are tricky, but as soon as you confirm what it's
> running (especially any modules they may have borrowed), I'll write
a
> nice letter assuming we can find a good contact for them.
>
> For reference, they're only required to release their modifications
> to kernal and module, not their stand-alone app.  I'm not entirely
> convinced they even need to publically say they're using Linux, but
> that's always been a sore point.  It's definitely worth persuing.
>
> Links from the Free Software Foundation (make your donation while
> you're there):
> http://www.fsf.org/licenses/gpl-violation.html
> http://www.fsf.org/licenses/gpl-faq.html
>
> What happened when Linksys tried to violate:
> http://yro.slashdot.org/article.pl?
> sid=03/06/08/1749217&tid=193&tid=117&tid=17
> http://lkml.org/archive/2003/6/7/164/index.html
>
> A sample letter to Dell that we may want to borrow:
>
http://web.archive.org/web/20030620073929/http://www.redbrick.dcu.ie/~
> colmmacc/TrueMobile-1184/dell.letter
>
> Let's try to be civil at first rather than unleashing Linux zealot
> hell on them :)  See what they come back with.
>
> Good find!
>
>   --Darren
>
> --- In zipitwireless@yahoogroups.com, "ZipItPet" <aibopet@a...>
wrote:
> >
> > Cool, they tricked me into buying a Linux PDA !->
> >
> > Embedded Linux of course
> >
> > More technical info to come...
> >
> > ----
> > Someone needs to ask them for a source release of their
> > kernel/driver mods (ie. anything GPL derived)
> > Volunteers ?
> >
> > Since they scramble the binary files used for their firmware
> > updates, they are hiding the fact they are using Linux.
> >
> > IANAL
> > That's shabby IMHO, although not forbidden by the GPL
> > (ie. GPL says you must release source code for certain things if
> > people ask, but if they don't know to ask you can hide your Linux
> > source from the public...).

This is a good thing... what makes you sure it's Linux?  And which
version?

GPL violations are tricky, but as soon as you confirm what it's
running (especially any modules they may have borrowed), I'll write a
nice letter assuming we can find a good contact for them.

For reference, they're only required to release their modifications
to kernal and module, not their stand-alone app.  I'm not entirely
convinced they even need to publically say they're using Linux, but
that's always been a sore point.  It's definitely worth persuing.

Links from the Free Software Foundation (make your donation while
you're there):
http://www.fsf.org/licenses/gpl-violation.html
http://www.fsf.org/licenses/gpl-faq.html

What happened when Linksys tried to violate:
http://yro.slashdot.org/article.pl?
sid=03/06/08/1749217&tid=193&tid=117&tid=17
http://lkml.org/archive/2003/6/7/164/index.html

A sample letter to Dell that we may want to borrow:
http://web.archive.org/web/20030620073929/http://www.redbrick.dcu.ie/~
colmmacc/TrueMobile-1184/dell.letter

Let's try to be civil at first rather than unleashing Linux zealot
hell on them :)  See what they come back with.

Good find!

   --Darren

--- In zipitwireless@yahoogroups.com, "ZipItPet" <aibopet@a...> wrote:
>
> Cool, they tricked me into buying a Linux PDA !->
>
> Embedded Linux of course
>
> More technical info to come...
>
> ----
> Someone needs to ask them for a source release of their
> kernel/driver mods (ie. anything GPL derived)
> Volunteers ?
>
> Since they scramble the binary files used for their firmware
> updates, they are hiding the fact they are using Linux.
>
> IANAL
> That's shabby IMHO, although not forbidden by the GPL
> (ie. GPL says you must release source code for certain things if
> people ask, but if they don't know to ask you can hide your Linux
> source from the public...).

Cool, they tricked me into buying a Linux PDA !->

Embedded Linux of course

More technical info to come...

----
Someone needs to ask them for a source release of their
kernel/driver mods (ie. anything GPL derived)
Volunteers ?

Since they scramble the binary files used for their firmware
updates, they are hiding the fact they are using Linux.

IANAL
That's shabby IMHO, although not forbidden by the GPL
(ie. GPL says you must release source code for certain things if
people ask, but if they don't know to ask you can hide your Linux
source from the public...).

> Has anyone touched their ZipIt since XMas ?
Yes I took it on a tour of Downtown today hooking every network I ran
across. Works great. Love it.

> Does this device have a future?
Dunno. Statistically speaking there were only about 2000 in stock, so
asssuming 1/2 were sold, theres ~1000 users. Judging from the
upgrades to firmware so far and the upgrade delivery methodry I would
say the devices have potential to become VERY popular.

> What kind of things could it be hacked to do ?
Well the chipset has memory, it has sound, it's natively wireless(and
promiscuous no less). WAP browsing comes to mind. Store mp3's on your
server and stream em to the device ANYWHERE..sounds great. cripes i
dunno ..guess we gotta break it a bit more first.

> Is hacking this thing worth the effort ?
mmm. was hacking the commodore64 worth it? maybe not. but the little
ghostbusters image i got to cross the screen after 2000 lines of
BASIC code sure made my friends think i was cool. \,,/ ^_^ \,,/

> Ideas? Suggestions? Enthusiasm ?
Yes. Yes. Yes!



--- In zipitwireless@yahoogroups.com, "ZipItPet" <aibopet@a...> wrote:
>
> Anybody home ?->
>
> ----
>
> Has anyone touched their ZipIt since XMas ?
>
> Does this device have a future?
>
> What kind of things could it be hacked to do ?
>
> Is hacking this thing worth the effort ?
>
> Ideas? Suggestions? Enthusiasm ?

---

Yahoo! Groups Links

• To visit your group on the web, go to:
• http://groups.yahoo.com/group/zipitwireless/
•  
• To unsubscribe from this group, send an email to:
• zipitwireless-unsubscribe@yahoogroups.com
•  
• Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.6.9 - Release Date: 1/6/2005

No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.6.9 - Release Date: 1/6/2005

> Has anyone touched their ZipIt since XMas ?
Yes I took it on a tour of Downtown today hooking every network I ran
across. Works great. Love it.

> Does this device have a future?
Dunno. Statistically speaking there were only about 2000 in stock, so
asssuming 1/2 were sold, theres ~1000 users. Judging from the
upgrades to firmware so far and the upgrade delivery methodry I would
say the devices have potential to become VERY popular.

> What kind of things could it be hacked to do ?
Well the chipset has memory, it has sound, it's natively wireless(and
promiscuous no less). WAP browsing comes to mind. Store mp3's on your
server and stream em to the device ANYWHERE..sounds great. cripes i
dunno ..guess we gotta break it a bit more first.

> Is hacking this thing worth the effort ?
mmm. was hacking the commodore64 worth it? maybe not. but the little
ghostbusters image i got to cross the screen after 2000 lines of
BASIC code sure made my friends think i was cool. \,,/ ^_^ \,,/

> Ideas? Suggestions? Enthusiasm ?
Yes. Yes. Yes!



--- In zipitwireless@yahoogroups.com, "ZipItPet" <aibopet@a...> wrote:
>
> Anybody home ?->
>
> ----
>
> Has anyone touched their ZipIt since XMas ?
>
> Does this device have a future?
>
> What kind of things could it be hacked to do ?
>
> Is hacking this thing worth the effort ?
>
> Ideas? Suggestions? Enthusiasm ?

Anybody home ?->

----

Has anyone touched their ZipIt since XMas ?

Does this device have a future?

What kind of things could it be hacked to do ?

Is hacking this thing worth the effort ?

Ideas? Suggestions? Enthusiasm ?

> 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.

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
be appreciated.
[if not I may get back to this sometime later in 2005 - or wait to
see if ZipIt takes off or fizzles out]

ZipItPet,

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.

Hmmmmmm

256K Redboot,
1.75 MB for root fs including linux loaded to ramdisk
maybe a small partition for saving the buddy list ?

It is possible.

[g2]
Tommy B



--- In zipitwireless@yahoogroups.com, "ZipItPet" <aibopet@a...> wrote:
>
> --- In zipitwireless@yahoogroups.com, 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
> device)
>
> ------
> > 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)
>
> COM1:
> 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.

Am I the only one that hasn't gotten the 1.08 upgrade yet?

Also, I've heard from two different people that have had problems
with their buddy list disappearing or being erased entirely on that
version.  Anybody else have similar problems?

One person spoke to K-Byte Tech Support and they were told that
another new version is coming "very soon".

   --Darren

--- In zipitwireless@yahoogroups.com, 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
device)

------
> 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)

COM1:
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.

I'm one step closer to adding a backlight.  I posted some Photos, take
a look.

At 07:53 PM 12/27/2004 +0000, ZipItPet wrote:
>
>image will do. It only needs to be done once (ie. no need to write a
>long-term boot loader)

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?


>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]

The flash could have been programmed before assembly.  I really doubt the
microcontroller is connected to the address and data bus.


>Soldering directly to the traces may be the only option [oww my eyes
>are burning... ]

Has anyone been able to verify that the UART lines are in fact brought out
to a trace, via, or connector?


--
newell

> If you can get to com1, then you can boot using Shoehorn and use
that
> 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 ?

>  > 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 ?)
>

If you can get to com1, then you can boot using Shoehorn and use that
to grab the ROM.

Scott

Hello Everyone,

Zipit updated to version 3.1.08.
I added ROM files to my http server: http://coderx.cjb.net/~zippy/ .
You can download the files from http://www.zipitwireless.net/~zippy/
as well, I'm storing them for backup.  I hope this helps the
decryption/decompression efforts.

~Jesse (coderxtreme)
------------------------------------------------
HTTP Stream between Zipit and AP listed below
------------------------------------------------
Date: Sat, 25 Dec 2004 00:51:20 GMT
Server: Apache/2.0.52 (Unix)
Content-Length: 96
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/plain; charset=ISO-8859-1

GET /~zippy/90300688.txt HTTP/1.1
Accept: */*
Connection: Keep-Alive
Host: www.zipitwireless.net:80
Range: bytes=0-95

HTTP/1.1 206 Partial Content
Date: Sat, 25 Dec 2004 00:51:20 GMT
Server: Apache/2.0.52 (Unix)
Content-Length: 96
Content-Range: bytes 0-95/96
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: text/plain; charset=ISO-8859-1

1.08
http://www.zipitwireless.net/~zippy/bootrom.t3.1.08.bin
AB2178653406C18908E20FA40E15B391

HEAD /~zippy/90300688.txt HTTP/1.1
Accept: */*
Connection: Close
Host: www.zipitwireless.net:80

HTTP/1.1 200 OK
Date: Sat, 25 Dec 2004 00:51:21 GMT
Server: Apache/2.0.52 (Unix)
Content-Length: 96
Connection: close
Content-Type: text/plain; charset=ISO-8859-1

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
specifically MD5

> 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. The
> 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.

I am assuming that's what the DBG pin does (short to ground).
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-
far-as-I-can-tell.

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't
you?), 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 nothing
more
> than a unique 32 bit serial number and a (possibly unique?) 128
bit 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. Assuming
they're
> booting from flash, then decompressing the executable into
sdram....

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
+ reboot

> there needs to be a vector table and some
bootloader/startup/decompression code
>in the boot sector, right?

My educated guess is that the all of this is in the same 2MB Flash
ROM.
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
another thing)

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.

I didn't see anything that looked like a JTAG port in the FCC filings.  I
did see two serial ports.  Someone with production hardware might be able
to look closely and determine if the serial port connections can be easily
restored.  (Too bad they didn't pick a TQFP packaged '7312 instead.)

The '7312 has a serial port bootloader.  After a quick glance through the
docs, I think it should be fairly simple to download a small chunk of code
to dump the flash.  Of course, that all presupposes a serial port
connection...

I tried compressing the downloaded update files.  They didn't, which makes
me think that they're either already compressed or encrypted, or both.  I
think they are almost certainly compressed (why wouldn't you?), but I'm not
so sure that they'd be encrypted.  Signed with some sort of hash or CRC,
perhaps.  (To ensure that the download wasn't corrupted.)

DRM: as I understand it, the DRM features of the '7312 are nothing more
than a unique 32 bit serial number and a (possibly unique?) 128 bit random
number.  I don't think they're using this to decrypt the update
files--after all, each unit is receiving the same update file.  I do wonder
if there's any correlation between the unique ID and the ZIP...

Errata: The B rev chips didn't even have a working MaverickKey.  The C rev
parts claim that you can't DMA from anything but 32 bit memory to the LCD.
Considering the single x16 sdram, I guess they're using the internal sram
as the frame buffer.

2MB + 16 byte update filesize: this troubles me slightly.  Assuming they're
booting from flash, then decompressing the executable into sdram, there
needs to be a vector table and some bootloader/startup/decompression code
in the boot sector, right?  I wouldn't expect this bootsector to change
very often, if at all.  But the update file appears to be large enough to
contain the entire flash device.  Hmm.


--
newell

Sorry if I accidentally denied peoples messages.  I set it to require
approval for first post to help reduce spam but I think I hit the
wrong button.  If the two of you who posted this morning don't see
your message appear soon, just send it through again.

Thanks,
   --Fat Fingers

For info on the cirrus chip see

http://www.gweep.net/~prefect/eng/audiotron/

the audiotron also uses the 7312.


In addition, see

http://www.heeltoe.com/software/ceiva/Ceiva-mini-HOWTO.html

The Ceiva uses the 7212 which is similar to the 7312.

What you want to look for not jtag but the serial ports. The
7212/7312 has an internal boot loader, jumper one pin and the chip
looks for a boot on it's first serial port. The Ceiva link has info
on what to do once you find the serial port. You will want to build a
Shoehorn and Hermit boot loader. I suspect the pins are there, it
beats having the eprom loaded before pcb insertion.

Scott

I've posted all of the useful FCC filings in the Files section of
this group.  Enjoy.

I would love to get ahold of the "demo firmware" they reference in
the users guide.

   --Darren

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):
o Search
https://gullfoss2.fcc.gov/prod/oet/cf/eas/reports/ApplicationStatusSe
arch.cfm for FCC filing ID PPQ-WL100BA51
o I will post these docs to this group hopefully tomorrow (to save
me bandwidth)

Login procedure (thanks me, and coderextreme):
1. Zipit connects to tracking URL, e.g.
http://www.zipitwireless.net/~zippy/90300684.txt
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
that....
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
text.
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)

Hardware:
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

Software:
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.
     http://www.zipitwireless.net/~zippy/90300004.txt
     http://www.zipitwireless.net/~zippy/90300015.txt
     http://www.zipitwireless.net/~zippy/90300020.txt
     http://www.zipitwireless.net/~zippy/90300028.txt
     http://www.zipitwireless.net/~zippy/90300032.txt
     http://www.zipitwireless.net/~zippy/90300036.txt
     http://www.zipitwireless.net/~zippy/90300038.txt
     http://www.zipitwireless.net/~zippy/90300041.txt
     http://www.zipitwireless.net/~zippy/90300048.txt
     http://www.zipitwireless.net/~zippy/90300051.txt
     http://www.zipitwireless.net/~zippy/90300060.txt
     http://www.zipitwireless.net/~zippy/90300061.txt
     http://www.zipitwireless.net/~zippy/90300074.txt
     http://www.zipitwireless.net/~zippy/90300076.txt
     http://www.zipitwireless.net/~zippy/90300089.txt
     http://www.zipitwireless.net/~zippy/90300189.txt
     http://www.zipitwireless.net/~zippy/90300289.txt
     http://www.zipitwireless.net/~zippy/90300386.txt
     http://www.zipitwireless.net/~zippy/90300391.txt
     http://www.zipitwireless.net/~zippy/90300410.txt
     http://www.zipitwireless.net/~zippy/90300422.txt


That's about all I have for now... get cracking and sharing!

   --Darren