Neo 1973 Phase 0

From Openmoko

(Redirected from Neo1973 Phase 0 Errata)
Jump to: navigation, search
Outdated warning ! This article or section is significantly outdated, either by significant hardware or software changes. Procedures mentioned in this page may well not work for current hardware/software.


Phase0 Quick Start

See the following sections for quick start instructions for Phase0 developers:

Software Image

We were using u-boot, kernel and rootfs images from to pre-install the devices. This is a self-contained devirginator snapshot, and can be used at any given time to fully restore the phone (complete loss of data is implied).

Restoring original Software Image

NOTE: This is how you do a full restore, including U-Boot. This requires a Debug Board. In most cases, it is sufficient to use dfu-util to flash kernel and rootfs partitions

This is how to restore the phone:

  • Go to a convenient directory, then
tar xfz devirginate-20070301.tar.gz
  • Enter the directory:
cd devirginate-20070301
  • Disconnect everything:
    • the USB connector of the debug v2 board from the PC
    • the USB cable from the Neo
    • remove the battery
  • Connect the Neo to the debug v2 board.
  • Connect USB of the debug v2 board to the PC.
  • If you have a serial console, start it now. The device should be something like /dev/ttyUSB0.
  • Connect the USB cable of the Neo.
  • Insert the battery.
  • Power on the Neo. (If it has powered on by itself, that's okay.)
  • Start OpenOCD (if you have a local openocd.cfg, please use that one):
tmp/openocd -f tmp/openocd-debugv2.cfg
  • OpenOCD should print one line (below) and keep running:
Info:    openocd.c:84 main(): Open On-Chip Debugger (2007-01-31 12:00 CET)

If OpenOCD prints an error, please disconnect the USB cable of debug v2 from the PC, connect it again, then restart OpenOCD.

  • In another window, start the install script:
./devirginate -0 -1 -2
NOTE: The -0 option irrecoverably destroys bad block information provided by the chip manufacturer. This is only appropriate for devices from phase 0, or earlier. Instructions will be updated for later models.

Watch the screen of the Neo. The following things should happen:

  • it turns on, showing weird things for about 10-30 seconds
  • the screen goes dark for 1-2 minutes
  • the screen lights up and shows a smiling face for a few minutes
  • the screen goes dark and shows a partial (broken) Openmoko logo for about 5-10 seconds
  • the screen goes dark again, then shows the full Openmoko logo
  • the machine will boot Linux now and start touch screen calibration


power-off while DFU

u-boot can power-off the phone while in DFU mode :(


Either press the AUX button frequently to keep the phone from shutting off while the transfer is in progress, or access the u-boot console to increase boot_menu_timeout to some large value (in seconds) and restart.


Update to a more recent u-boot revision. All builds with svn revision 1284 or later address this issue.

Licenses not in rootfs image

/usr/share/common-licenses is not populated


printed GPL/LGPL included

rootfs update causes what seems like bad blocks

Since we do block-by-block erasing of the flash during DFU, the 'rootfs' partition is not erased completely before writing a new JFFS2 image to NAND, if the rootfs image is smaller than the flash size


Either use the 'pad' option to mkfs.jffs2' when creating the image or use

GTA01Bv3#  nand erase clean rootfs

on the U-Boot console before using DFU to flash a new rootfs image

Mechanical stress to microSD lid can cause short-circuit

If you operate the microSD slot without a card inserted, while the device is powered on, plus put some mechanical stress to it, it can short-circuit the contact pins, resulting in 3.3V supply voltage short-circuit.


Please do not power the phone without microSD card inserted. Especially, never try to switch cards without unpowering the phone completely.

Random system crashes

Due to a bug in the GPIO initialization routines of our u-boot patchset up to moko5, we had memory corruption as soon as more than 64MB of SDRAM were used.




The real solution is to update to a more recent u-boot revision, such as

Rootfs corrupted after flashing via DFU

The USB DFU code for handling the JFFS2 root filesystem partition did not properly erase the rest of the partition, in case you are flashing an image that is smaller than the physical size of the rootfs partition.


Manually issue

nand erase clean rootfs

on the u-boot commandline before flashing a new rootfs image.


Use a u-boot image svn rev. 1306 or higher.

Reboot cycle

When battery is empty, it looks like Neo1973 is booting, but then reboots. This cycle repeats every 7 seconds. See bug #212 for more info


Hit the power button once. This should turn the device off, and it should stay off. If that doesn't happen, then try again.

Wait for a few minutes, for the device to charge up a bit.

Be ready for the next few steps - you'll need to act quickly.

Power on the device.

Then get into the U-Boot console via ttyACM0. Then type "neo1973 charger fast".

Alternative: Change battery to BL-5C with enough juice.

Alternative: Once you've got out of the reboot cycle, leave it off until it has charged enough to get fully into Linux.


Do not let battery drain to too low level? u-boot update?

AC Charger only charges with 100mA

please don't use the AC charger, as it will only charge with 100mA, which will take at least 12 hours to fill the battery, if the device is switched off.

if you keep the device running, it will consume more than 100mA, and thus actually run empty - just a bit slower than it would without the charger.

With devices up to GTA01Bv3 and the current charger we basically have no way of using a non-usb-host for charging without violating the USB spec.

So now we have the choice between USB incompliant 500mA charging (which might in some really bad cases cause damage to the 'usb host' it is attached to.

Thus, we'd rather done it the safe way: Only use 500mA after the USB host has granted us permission to do so.

I know that it's almost industry practise to violate this part of the spec. However, Openmoko wants to set a good example and adhere to standards :)


GTA01Bv4 and the new charger hardware contain circuit changes to address this problem in a usb spec compliant way.

Q: A host that does not communicate with the peripheral while supplying power also violates standards. If the host does not attempt to communicate with the neo for 30s, then why not turn on fast charging, or at least pop up a dialog when you plug it in to charge, informing the user that the port may not be able to supply 100mA, and that clicking 'charge anyway' may stop stuff working.  ?

A device that will not easily charge on the many available USB chargers is broken.


you can manually override the charging mode via sysfs or in u-boot, if you really want to use the charger for 500mA charging. see the kernel and u-boot pages in the wiki.

Personal tools