Neo 1973 Phase 0
Phase0 Quick Start
See the following sections for quick start instructions for Phase0 developers:
We were using u-boot, kernel and rootfs images from http://people.openmoko.org/werner/devirginate-20070301.tar.gz 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 bootloader. 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:
- Download [devirginate-20070301.tar.gz] to the Linux PC that will do the installation.
- Go to a convenient directory, then
tar xfz devirginate-20070301.tar.gz
- Enter the directory:
- 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 bootloader 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 http://buildhost.openmoko.org/tmp/deploy/images/u-boot-gta01bv3-r3_0_0_1321.bin
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.
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.
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 bootloader 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.