diff options
author | Pali Rohár <pali.rohar@gmail.com> | 2013-09-23 11:33:03 +0200 |
---|---|---|
committer | Pali Rohár <pali.rohar@gmail.com> | 2013-09-23 11:33:03 +0200 |
commit | 1096c8b426438e29b0556e1317eb981a48246fb9 (patch) | |
tree | af978e83506d221287aaa3da5ff4ccd536bf8b87 /doc | |
parent | 97eb4484d9224a49120b6e5d6cffb73c593b44c1 (diff) | |
download | 0xFFFF-1096c8b426438e29b0556e1317eb981a48246fb9.tar.bz2 |
doc: Fix typo
Diffstat (limited to 'doc')
-rw-r--r-- | doc/dumping | 8 | ||||
-rw-r--r-- | doc/examples | 2 | ||||
-rw-r--r-- | doc/faq2 | 6 | ||||
-rw-r--r-- | doc/fiasco | 4 | ||||
-rw-r--r-- | doc/local-flash | 2 | ||||
-rw-r--r-- | doc/mkii | 4 | ||||
-rw-r--r-- | doc/nokia-tips | 6 |
7 files changed, 16 insertions, 16 deletions
diff --git a/doc/dumping b/doc/dumping index add0002..2d7ce25 100644 --- a/doc/dumping +++ b/doc/dumping @@ -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. diff --git a/doc/examples b/doc/examples index 2071d0a..dc56a38 100644 --- a/doc/examples +++ b/doc/examples @@ -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 @@ -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! @@ -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 diff --git a/doc/local-flash b/doc/local-flash index 937a7bd..9ba487a 100644 --- a/doc/local-flash +++ b/doc/local-flash @@ -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 @@ -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 diff --git a/doc/nokia-tips b/doc/nokia-tips index 579d97b..6597d70 100644 --- a/doc/nokia-tips +++ b/doc/nokia-tips @@ -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 |