doc: Fix typo

This commit is contained in:
Pali Rohár committed 2013-09-23 11:33:03 +02:00
1 parent 97eb4484d9
commit 1096c8b426
7 files changed
+16 -16

No files matched your search

+4 -4
View File
@@ -1,7 +1,7 @@
Dumping the firmware:
This technique consists on reconstructing a firmware image dumping
pieces at certains offsets of the device internal memory.
pieces at certain offsets of the device internal memory.
Technical details:
@@ -10,7 +10,7 @@ Technical details:
*
* READ src/local.c for detailed information.
mtd0 - contains xloader and sencodary pieces of the bootloaders
mtd0 - contains xloader and secondary pieces of the bootloaders
0x00000 - xloader.bin (size is 0x03600)
0x04000 - secondary.bin (size is 0x15400)
0x1FFFF - eof
@@ -27,7 +27,7 @@ Technical details:
mtd4 - rootfs.jffs2 (a fucking copy of the above rootfs?)
For dumping mtd parition is used tool nanddump. Here is example how to dump
For dumping mtd partition is used tool nanddump. Here is example how to dump
kernel image without padding to file zImage:
$ nanddump -i -o -b -s 0x00000800 -l 0x001FF800 -f zImage /dev/mtd2
@@ -40,7 +40,7 @@ Params means:
-l - "Length"
-f - "Output file"
Please note that some new versions of naddump have some options removed and
Please note that some new versions of nanddump have some options removed and
some are enabled by default. Before using check params of your nanddump version.
+1 -1
View File
@@ -15,7 +15,7 @@ $ 0xFFFF -M <file> -f -r
Flash only kernel from FIASCO image and reboot:
$ 0xFFFF -M <file> -t kernel -f -r
Cold-Flash 2nd and secondery bootloaders:
Cold-Flash 2nd and secondary bootloaders:
$ 0xFFFF -m 2nd:<file> -m secondary:<file> -c
+3 -3
View File
@@ -55,9 +55,9 @@ This file tries to collect a bunch of common questions/answers about flashing
On the n800 firmwares, these two pieces are distributed in a single
file, but when flashing a 770, NOLO requires to provide the xloader
(without commiting) and then the secondary piece.
(without committing) and then the secondary piece.
This piece of software is closed source and is the responsable of
This piece of software is closed source and is the responsible 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.
@@ -65,7 +65,7 @@ This file tries to collect a bunch of common questions/answers about flashing
*) How can I identify my device?
Theorically 770 and n800 have different USB device ID, but this is not
Theoretically 770 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 770. That's weird!
+2 -2
View File
@@ -6,14 +6,14 @@ SPECS FOR THE FIASCO FIRMWARE FILE FORMAT ffff!
This is final working version of FIASCO format. FIASCO image which
is generated by this spec is acceptable by Nokia flasher-3.5 and
unpack data same as FIASO image generated by Nokia fiasco-gen. This
unpack data same as FIASCO image generated by Nokia fiasco-gen. This
format is implemented in 0xFFFF and every image which I tested
(generated by 0xFFFF and fiasco-gen) was properly unpacked under
0xFFFF and flasher-3.5 with same result. Small difference is that
fiasco-gen add some unknown subsection block to image header
(type '4' or '/') which contains some messy characters... But if
these sections missing, flasher-3.5 working fine too. And old FIASCO
images (for N8x0) does not have these subsectin...
images (for N8x0) does not have these subsection...
FILE HEADER
+1 -1
View File
@@ -9,7 +9,7 @@ The way to flash is using mtd-utils:
This is an specific example plagied from initfs_flasher of bootmenu.
The '-j' flag says that this is a jffs2 partition. Theorically this
The '-j' flag says that this is a jffs2 partition. Theoretically this
flag is not required for zImage, and the bootloader pieces.
The '-a' creates the OOB data automatically, and the '-p' flag pads
+2 -2
View File
@@ -27,7 +27,7 @@ Over usb are used only these functions for communication:
usb_bulk_write (ep=1, timeout=5000)
usb_bulk_read (ep=129, timeout=5000)
For every (request) message which is send by host, server send back responce.
For every (request) message which is send by host, server send back response.
Format of message every message is same. It has 6 bytes header and (at least)
4 bytes body.
@@ -43,7 +43,7 @@ BODY
4 bytes -- type of message
N bytes -- data
Reply message data always starts with char 0x00 (except pong responce).
Reply message data always starts with char 0x00 (except pong response).
Here are some sniffed messages from Nokia RX-51. First two messages seems to
must be always protocol version exchange (first host ask for protocol version of
+3 -3
View File
@@ -44,17 +44,17 @@ think that there are some things that should be fixed.
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
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
I'll happily 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.
code could be revised and enhanced by zillions of eyes.
*) Poor checksumming