Loading ...
Sorry, an error occurred while loading the content.
 

Status so far

Expand Messages
  • Darren Madams
    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
    Message 1 of 8 , Dec 22 7:32 PM
      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
    • icybiepet
      ... Could also be used for interfacing the external port (there is no digitizer in the device) ... Or some other hash / checksum. Don t see anything that says
      Message 2 of 8 , Dec 24 9:08 AM
        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.
      • Scott D. Davilla
        ... If you can get to com1, then you can boot using Shoehorn and use that to grab the ROM. Scott
        Message 3 of 8 , Dec 25 6:30 AM
          > > 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
        • ZipItPet
          ... that ... 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
          Message 4 of 8 , Dec 27 11:53 AM
            > 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 ?
          • Scott Newell
            ... 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? ...
            Message 5 of 8 , Dec 27 12:19 PM
              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
            • ZipItPet
              ... bootloader or ... something here? My assumption is there is no separate bootloader , but instead bootloader-like features built into each and every new
              Message 6 of 8 , Dec 28 11:01 AM
                --- 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.
              • trb
                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
                Message 7 of 8 , Dec 28 12:33 PM
                  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.
                • ZipItPet
                  ... output during boot or the application. Nothing seen during normal running. ... With the magical boot sequence enabled there is a lonely
                  Message 8 of 8 , Dec 29 10:17 AM
                    > 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]
                  Your message has been successfully submitted and would be delivered to recipients shortly.