diff options
author | pancake <pancake@dazo> | 2007-04-20 18:20:22 +0200 |
---|---|---|
committer | pancake <pancake@dazo> | 2007-04-20 18:20:22 +0200 |
commit | b1d0ce2848a79664374f802954b1e4390b11da6d (patch) | |
tree | 4f465ca029401b9afef0372ff1e0c60a43d87b40 /doc | |
download | 0xFFFF-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/dumping | 45 | ||||
-rw-r--r-- | doc/faq | 70 | ||||
-rw-r--r-- | doc/nokia-tips | 105 | ||||
-rw-r--r-- | doc/oops | 2 | ||||
-rw-r--r-- | doc/pieces | 6 | ||||
-rw-r--r-- | doc/usage | 54 |
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?) @@ -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> |