valentineus/0xFFFF
1
Fork 0
Code Releases Activity

* Initial commit of 0xFFFF.

Browse Source 
This tree contains the same as the 0.1 tarball
This commit is contained in:
pancake committed 2007-04-20 18:20:22 +02:00
commit b1d0ce2848
22 files changed
+2060
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

doc/dumping
+45
View File
@@ -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?)
doc/faq
+70
View File
@@ -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 :)
doc/nokia-tips
+105
View File
@@ -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.
doc/oops
+2
View File
@@ -0,0 +1,2 @@
Consequences of a weird flashing :)<br />
<img src="img/n770bars.jpg">
doc/pieces
+6
View File
@@ -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.
doc/usage
+54
View File
@@ -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>