summaryrefslogtreecommitdiffstats
path: root/doc
diff options
context:
space:
mode:
authorpancake <pancake@dazo>2007-04-20 18:20:22 +0200
committerpancake <pancake@dazo>2007-04-20 18:20:22 +0200
commitb1d0ce2848a79664374f802954b1e4390b11da6d (patch)
tree4f465ca029401b9afef0372ff1e0c60a43d87b40 /doc
download0xFFFF-b1d0ce2848a79664374f802954b1e4390b11da6d.tar.bz2
* Initial commit of 0xFFFF.0.1
This tree contains the same as the 0.1 tarball
Diffstat (limited to 'doc')
-rw-r--r--doc/dumping45
-rw-r--r--doc/faq70
-rw-r--r--doc/nokia-tips105
-rw-r--r--doc/oops2
-rw-r--r--doc/pieces6
-rw-r--r--doc/usage54
6 files changed, 282 insertions, 0 deletions
diff --git a/doc/dumping b/doc/dumping
new file mode 100644
index 0000000..0017a33
--- /dev/null
+++ b/doc/dumping
@@ -0,0 +1,45 @@
+<b>Dumping the firmware</b>
+
+This technique consists on reconstructing a firmware image dumping
+pieces at certains offsets of the device internal memory.
+
+
+<b>End user details:</b>
+
+ * Extract the firmware pieces from a running device
+ *
+ * This functionality is useful to extract backups of your system
+ * firmware. This is really useful when you're on a desert island
+ * without an internet connection.
+ *
+ * This tool needs more testing, so take care and don't blame me if
+ * it breaks your system. It *is* to your responsability, use at
+ * your own risk
+ *
+ * NOTE: It's theorically possible to flash the device on the fly from
+ * the running OS, but this has not yet been tested. Keep tuned for
+ * updates and newz.
+ *
+ * Have fun!
+
+
+<b>Technical details:</b>
+
+ * The internal flash memory is exposed to the system as MTD devices. So it's
+ * possible to dump the individual sections of a flashed firmware.
+ *
+ * READ src/dump.c for detailed information.
+
+ mtd0 - contains xloader and sencodary pieces of the bootloaders
+ 0x00000 - xloader.bin (size is 0x03600)
+ 0x04000 - secondary.bin (size is 0x15400)
+ 0x1FFFF - eof
+
+ mtd1 - looks like there's a pool ConF structures
+
+ mtd2 - starts with NOLO img\x5c\x13 and \x00 padding
+ 0x00800 - zImage
+
+ mtd3 - rootfs.jffs2 (20M) aka 0x200000 vs 0x3900000
+
+ mtd4 - rootfs.jffs2 (a fucking copy of the above rootfs?)
diff --git a/doc/faq b/doc/faq
new file mode 100644
index 0000000..1d0b805
--- /dev/null
+++ b/doc/faq
@@ -0,0 +1,70 @@
+<b>FAQ</b>
+
+This file tries to collect a bunch of common questions/answers about flashing
+
+<b>*) Why implement a free software flasher?</b>
+
+ The Nokia Internet Tablets are based on Free Software (software libre), but
+ not everything included *is* free software, for instance, the firmware flasher
+ tool.
+
+ The 0xFFFF project aims to feed the minds of those who really want to
+ understand how these gadgets work internally, free the knowledge to
+ avoid the restrictions and fill the lack of information on the most
+ important part of the system.
+
+ That's it, now you can build and run this flasher on *BSD, w32, MacOSX on ARM,
+ powerpc, x86, mips, etc...
+
+
+<b>*) Can I brick my device?</b>
+
+ Of course! You're free to do what you want with your device :)
+
+ Seriously. Flashing a device is not a safe thing, so I give no warranty
+ of what will happen to your device when using this tool.
+
+ BTW, after a huge number of tests I can say that these devices are hard
+ to brick, but if you are scared about bricking your device you should
+ use the flasher provided by Nokia, it's better for your heart's health.
+
+
+<b>*) What can I do with 0xFFFF?</b>
+
+ Actually 0xFFFF allows you to:
+
+ - flash separated pieces of the firmware.
+ - retrieve information about the device
+ - reboot de mother board
+ - extract the current firmware pieces from the device (reverse flash)
+ - set the USB host/slave mode
+ - set the R&R mode
+ - identify firmware pieces
+
+
+<b>*) What is NOLO?</b>
+
+ NOLO is the 'server-side' part of the flasher from Nokia. NOLO means
+ NOkia LOader and it's composed by two pieces of the firmware that are
+ flashed together.
+
+ On the n800 firmwares, these two pieces are distributed in a single
+ file, but when flashing a n770, NOLO requires to provide the xloader
+ (without commiting) and then the secondary piece.
+
+ This piece of software is closed source and is the responsable of
+ handling the requests from the client-side flasher. It provides a
+ query-like interface via usb control messages for doing different
+ actions on the device.
+
+
+<b>*) How can I identify my device?</b>
+
+ Theorically n770 and n800 have different USB device ID, but this is not
+ true at all. The first series of the n800 comes with the same usb-id
+ than n770. That's weird!
+
+ So, the only way to identify the device is by asking nolo for the version
+ information of different pieces of the firmware. This can be faked, because
+ you can flash n770 stuff on n800 and viceversa, but it's not recommended
+ because it wouldn't work :)
diff --git a/doc/nokia-tips b/doc/nokia-tips
new file mode 100644
index 0000000..468c1a1
--- /dev/null
+++ b/doc/nokia-tips
@@ -0,0 +1,105 @@
+<b>Nokia tips</b>
+
+When developing this tool I've found some bugs and misfeatures that
+should be fixed to make flashing safer and cleaner.
+
+Before reading the list of the following items I would like to say that
+Nokia has done a wonderful work on this device on the flashing/nolo parts,
+it's really hard to break the device and it works pretty nice. BTW I
+think that there are some things that should be fixed.
+
+
+<b>*) Flashing at low battery level</b>
+
+ When the device is under a certain limit of battery it will not start,
+ this is done by initfs, without any warning message or so, this really
+ scares end users, because the battery level check is done in the initfs
+ boot stage, not inside NOLO, so it's possible to flash the device on
+ low level batteries.
+
+ This is *really* dangerous and not very user friendly.
+
+
+<b>*) Internal nolo state not reset'd</b>
+
+ It's possible to get nolo on a strange state that always returns error
+ when flashing pieces, it's mandatory to reboot the device to recover
+ the original nolo state and be able to flash again.
+
+ This is an strange and not very clear to me.
+
+
+<b>*) Buffer overflows</b>
+
+ The original nokia flasher has some buffer overflow bugs that should
+ be fixed. They're safe for 99.9% of cases, but bofs on critical programs
+ like this one should not be there.
+
+ If nokia releases the source of the flasher it would be easier to make it
+ better and safer. BTW the original flasher is much more secure and reliable
+ than this one.
+
+
+<b>*) Missing stuff</b>
+
+ There are some flashing options that are not working like passing arguments
+ to the kernel, set the hw revision or do a cold flash (the most critical
+ part is undocumented).
+
+
+<b>*) Weird firmware format</b>
+
+ The (new and old) FIASCO firmware format is not a very clean format, it
+ doesn't provide any checksumming facility to ensure that the contents of
+ the firmware have been modified or incorrect, so i'll rather encourage
+ to design and create a standard firmware format for embedded devices with
+ checksumming, signatures, handling libraries, documentation and so.
+
+ I'll happilly collaborate on the design of this open firmware format, and
+ it would be used on all the open source-based devices to aim interoperability
+ between devices and flashers, providing a more standard and reliable way of
+ flashing devices.
+
+ This will ease the development on new devices, so the information and the
+ code could be revised and enhaced by zillions of eyes.
+
+
+<b>*) Poor checksumming</b>
+
+ The only checksum is a 16 bit xor of the whole firmware piece and it's only
+ checked after sending the piece to the device.
+
+ This is not very safe, because 16 bit checksum is a very low-quality
+ algorithm. It currently performs a unique check at the end, it could be
+ better to check each data block to avoid errors or invalid flashing, isn't it ?
+
+<b>*) No validation of pieces before flashing</b>
+
+ I've implemented a minimal check of the pieces to avoid flashing invalid
+ pieces on the wrong place. This is done in fpid.c (firmware piece identifier).
+
+ This should avoid end users to flash initfs on the kernel or weird things
+ that can (pseudo)brick the device.
+
+
+<b>*) Reverse flashing</b>
+
+ If you want to test a new firmware, but you don't want to loose all the
+ contents of your device. The only way to do that (afaik) is from the
+ device. That's done with `0xFFFF -e [path]`.
+
+ IMHO the reverse flashing (dump) should be implemented inside the bootloader
+ (NOLO in this case), and allow to retrieve (at least) the most critical
+ pieces of the firmware before flashing a new ones, and restore them in
+ case of a wrong checksumming (for example)
+
+
+<b>*) Documentation</b>
+
+ The nokia flasher comes as is, without documentation. This is not good
+ to anybody, because the lack of information is always the root of problems,
+ fear and ignorance.
+
+ So giving a minimal documentation about how to use the flasher (not only
+ the basic usage stuff (like the maemo community has done in the wiki)
+ would be good for everybody.
diff --git a/doc/oops b/doc/oops
new file mode 100644
index 0000000..947a31e
--- /dev/null
+++ b/doc/oops
@@ -0,0 +1,2 @@
+Consequences of a weird flashing :)<br />
+<img src="img/n770bars.jpg">
diff --git a/doc/pieces b/doc/pieces
new file mode 100644
index 0000000..2ef2f47
--- /dev/null
+++ b/doc/pieces
@@ -0,0 +1,6 @@
+Fiasco firmware pieces
+======================
+
+The firmware for the maemo devices is composed by a set of pieces containing
+the required parts to update the whole system following a partition layout
+defined by NOLO on the internal flash memory.
diff --git a/doc/usage b/doc/usage
new file mode 100644
index 0000000..59caa17
--- /dev/null
+++ b/doc/usage
@@ -0,0 +1,54 @@
+<b>Usage guide</b>
+
+0xFFFF is a free software implementation of the flasher for the Nokia Internet
+Tablets (n770 and n800).
+ <pre>
+ - flash separated pieces of the firmware.
+ - retrieve information about the device
+ - reboot de mother board
+ - extract the current firmware pieces from the device (dump)
+ - set the USB host/slave mode
+ - set the R&R mode
+ - identify firmware pieces
+ </pre>
+This is the help message of the tool:
+<pre>
+<b>~$ 0xFFFF -h</b>
+0xFFFF v0.1 - The Open Free Fiasco Firmware Flasher
+ -b [arg] boots the kernel with arguments
+ -e [path] dump the firmware pieces into the path
+ -p [[p:]file] piece-of-firmware : file-where-this-piece-is
+ -r [0|1] disable/enable R&D mode
+ -u [fiasco] unpack target fiasco image
+ -U [0|1] disable/enable the usb host mode
+ -h show this help message
+ -i show device information (let standby mode)
+ -I [piece] identify a firmware piece
+ -l list supported usb device ids
+ -d [vid:pid] injects a usb device into the supported list
+ -R reboot the omap board
+ -v be verbose and noisy
+ -V show 0xFFFF version information
+Pieces are: xloader secondary kernel initfs rootfs omap-nand
+</pre>
+
+Before anything we can execute failsafe queries like getting device information:
+<pre> <b>~$ 0xFFFF -i</b></pre>
+This command will put the bootloader in standby mode, so you can now send other
+commands without having to reboot the tablet manually. To reboot the mother
+board via USB type:
+<pre> <b>~$ 0xFFFF -R</b></pre>
+You can run 'offline' commands to identify the type of the firmware pieces:
+<pre> <b>~$ 0xFFFF -I zImage -I xloader.bin -I initfs.jffs2.orig</b>
+ kernel: zImage
+ xloader: xloader.bin
+ initfs: initfs.jffs2.orig</pre>
+If you want to backup your device firmware you can crosscompile the 0xFFFF
+utility and type this on the terminal:
+<pre> <b>~$ sudo gainroot</b>
+ ~# mkdir /media/mmc1/firmware
+ ~# ./0xFFFF -e /media/mmc1/firmware</pre>
+Now is time to flash something :) By default the flasher identifies the type
+of the piece automatically, but you can force't prefixing the filename with
+the piece-type name. To do this is just as simple as typing:
+<pre> <b>~$ 0xFFFF -p zImage</b></pre>