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: Dumping the firmware:
This technique consists on reconstructing a firmware image dumping 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: Technical details:
@@ -10,7 +10,7 @@ Technical details:
* *
* READ src/local.c for detailed information. * 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) 0x00000 - xloader.bin (size is 0x03600)
0x04000 - secondary.bin (size is 0x15400) 0x04000 - secondary.bin (size is 0x15400)
0x1FFFF - eof 0x1FFFF - eof
@@ -27,7 +27,7 @@ Technical details:
mtd4 - rootfs.jffs2 (a fucking copy of the above rootfs?) 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: kernel image without padding to file zImage:
$ nanddump -i -o -b -s 0x00000800 -l 0x001FF800 -f zImage /dev/mtd2 $ nanddump -i -o -b -s 0x00000800 -l 0x001FF800 -f zImage /dev/mtd2
@@ -40,7 +40,7 @@ Params means:
-l - "Length" -l - "Length"
-f - "Output file" -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. 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: Flash only kernel from FIASCO image and reboot:
$ 0xFFFF -M <file> -t kernel -f -r $ 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 $ 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 On the n800 firmwares, these two pieces are distributed in a single
file, but when flashing a 770, NOLO requires to provide the xloader 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 handling the requests from the client-side flasher. It provides a
query-like interface via usb control messages for doing different query-like interface via usb control messages for doing different
actions on the device. 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? *) 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 true at all. The first series of the n800 comes with the same usb-id
than 770. That's weird! 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 This is final working version of FIASCO format. FIASCO image which
is generated by this spec is acceptable by Nokia flasher-3.5 and 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 format is implemented in 0xFFFF and every image which I tested
(generated by 0xFFFF and fiasco-gen) was properly unpacked under (generated by 0xFFFF and fiasco-gen) was properly unpacked under
0xFFFF and flasher-3.5 with same result. Small difference is that 0xFFFF and flasher-3.5 with same result. Small difference is that
fiasco-gen add some unknown subsection block to image header fiasco-gen add some unknown subsection block to image header
(type '4' or '/') which contains some messy characters... But if (type '4' or '/') which contains some messy characters... But if
these sections missing, flasher-3.5 working fine too. And old FIASCO 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 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. 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. flag is not required for zImage, and the bootloader pieces.
The '-a' creates the OOB data automatically, and the '-p' flag pads 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_write (ep=1, timeout=5000)
usb_bulk_read (ep=129, 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) Format of message every message is same. It has 6 bytes header and (at least)
4 bytes body. 4 bytes body.
@@ -43,7 +43,7 @@ BODY
4 bytes -- type of message 4 bytes -- type of message
N bytes -- data 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 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 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 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 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 to design and create a standard firmware format for embedded devices with
checksumming, signatures, handling libraries, documentation and so. 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 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 between devices and flashers, providing a more standard and reliable way of
flashing devices. flashing devices.
This will ease the development on new devices, so the information and the 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 *) Poor checksumming