blob: 159f1f69dc0df47e51b5ab64ec4c46a70afa74f7 [file] [log] [blame]
Mike Dunn0dc0e842013-06-18 11:08:50 -07001
2README for the Palm Treo 680.
3
4Copyright (C) 2013 Mike Dunn <mikedunn@newsguy.com>
5
6You may reproduce the contents of this file entirely or in part, but please
7credit me by name if you do. Thanks.
8
9
10Intro
11=====
12
13Yes, you can program u-boot onto the flash of your Palm Treo 680 so that u-boot
14(then Linux, Android, ...) runs at power-up. This document describes how, and
15gives some implementation details on this port of u-boot and describes how the
16Treo 680 boots from reset.
17
18But first, I probably don't need to tell you that after doing this, your phone
19will no longer run PalmOS. You *may* be able to later restore your phone to its
20original state by creating a backup image of the flash before writing u-boot
21(details below), but this is not heavily tested and should not be relied upon.
22There is also the possibility that something may go wrong during the process of
23programming u-boot, leaving you with a bricked phone. If you follow these
24instructions carefully this chance will be minimized, but I do not recommend
25that you program u-boot onto a phone that you can not afford to lose, and
26certainly not one that contains important data that is not backed up elsewhere.
27I AM NOT RESPONSIBLE FOR THE LOSS OF YOUR PHONE. DO THIS AT YOUR OWN RISK.
28Having said that, feel free to send me a note cursing me out if something does
29go wrong, but please tell me what happened exactly. For that matter, I'd love
30to hear from you if you succeed.
31
32
33
34Details on the SPL
35==================
36
37The docg4 features a 2k region at the start of its address space that interfaces
38to the system bus like a NOR flash. This allows the docg4 to function as a boot
39ROM. The Treo 680 uses this feature. The contents of this 2k region are
40write-protected and can not be reprogrammed. Fortunately, the code it contains
41does what we need to do, at least partially. After some essential hardware
42initialization (like the SDRAM controller), it runs an IPL (initial program
43loader) that copies 128K (no more, no less) from flash to a fixed address in
44SDRAM (0xa1700000) and jumps to it. 128K is too small for u-boot, so we use it
45to load a u-boot secondary program loader (SPL). But since our SPL only
46occupies a little over 1k, we can economize on flash usage by having the IPL
47load a portion of u-boot proper as well. We let the IPL load the first 128k of
48a concatenated spl + u-boot image, and because the SPL is placed before u-boot
49proper, the IPL jumps to the SPL, which copies the portion of u-boot that the
50IPL has already loaded to its correct SDRAM address, and then loads the
51remainder of u-boot and jumps to it.
52
53
54
55The docg4's "reliable mode"
56===========================
57
58This is a special mode of operation of the docg4's integrated controller whereby
59consecutive pairs of 2k regions are used in parallel (in some fashion) to store
602k of data. In other words, the normal capacity is halved, but the data
61integrity is improved. In this mode, the data is read or written from pages in
62even-numbered 2k regions (regions starting at 0x000, 0x1000, 0x2000, ...). The
63odd-numbered 2k regions (regions starting at 0x800, 0x1800, 0x2800, ...) are
64transparently used in parallel. In reliable mode, the odd-numbered 2k regions
65are not meant to be read or written directly.
66
67Reliable mode is used by the IPL because there is not enough space in its 2k
68footprint to implement the BCH ecc algorithm. Data that is read while reliable
69mode is enabled must have been written in reliable mode, or the read fails.
70However, data written in reliable mode can also be read in normal mode (just not
71as reliably), but only from the even-numbered 2k regions; the odd-numbered 2k
72regions appear to contain junk, and will generate ecc errors. When the IPL and
73SPL read from flash, the odd-numbered 2k regions are explicitly skipped. The
74same is true for the flash_u-boot utility when it writes the u-boot image in
75reliable mode.
76
77The docg4 Linux driver supports writing in reliable mode (it is enabled by the
78module parameter), but not reading. However, the u-boot docg4_spl driver does
79read in reliable mode, in the same fashion as the IPL.
80
81
82
83Details on the IPL and its data format
84======================================
85
86Starting from block 5 and counting upward, the IPL will search for and load the
87first two blocks it finds that contain a magic number in the oob of the first
88page of the block. The contents are loaded to SDRAM starting at address
890xa1700000. After two blocks have been loaded, it jumps to 0xa1700000. The
90number of blocks loaded and the load address in SDRAM are hard-coded; only the
91flash offset of the blocks can vary at run-time (based on the presence of the
92magic number).
93
94In addition to using the docg4's reliable mode, the IPL expects each 512 byte
95page to be written redundantly in the subsequent page. The hardware is capable
96of detecting bit errors (but not correcting them), and if a bit error is
97detected when a page is read, the page contents are discarded and the subsequent
98page is read.
99
100Reliable mode reduces the capacity of a block by half, and the redundant pages
101reduce it by half again. As a result, the normal 256k capacity of a block is
102reduced to 64k for the purposes of the IPL/SPL.
103
104For the sake of simplicity and uniformity, the u-boot SPL mimics the operation
105of the IPL, and expects the image to be stored in the same format.
106
107
108
109Instructions on Programming u-boot to flash
110===========================================
111
112To program u-boot to your flash, you will need to boot the Linux kernel on your
113phone using a PalmOS bootloader such as cocoboot. The details of building and
114running Linux on your Treo (cross-compiling, creating a root filesystem,
115configuring the kernel, etc) are beyond the scope of this document. The
116remainder of this document describes in detail how to program u-boot to the
117flash using Linux running on the Treo.
118
119
120
121Hardware Prerequisites
122======================
123
124A Palm Treo 680:
125 (dugh)
126
127A Palm usb cable:
128 You'll need this to establish a usbtty console connection to u-boot from a
129 desktop PC. Currently there is no support in u-boot for the pxa27x keypad
130 (coming soon), so a serial link must be used for the console.
131 These cables are still widely available if you don't already have one.
132
133A Linux desktop PC.
134 You may be able to use Windows for the u-boot console if you have a usb driver
135 that is compatible with the Linux usbserial driver, but for programming u-boot
136 to flash, you'll really want to use a Linux PC.
137
138
139
140Treo-side Software Prerequisites
141================================
142
143Linux bootloader for PalmOS:
144
145 Cocoboot is the only one I'm aware of. If you don't already have this, you
146 can download it from
147 https://download.enlightenment.org/misc/Illume/Treo-650/2008-11-13/sdcard-base.tar.gz
148 which is a compressed tar archive of the contents of an sd card containing
149 cocoboot. Use mkdosfs to create a fat16 filesystem on the first primary
150 partition of the card, mount the partition, and extract the tar file to it.
151 You will probably need to edit the cocoboot.conf file to customize the
152 parameters passed to the kernel.
153
154
155
156Linux kernel:
157
158 The kernel on the Treo 680 is still a little rough around the edges, and the
159 official kernel frequently breaks on the Treo :( A development kernel
160 specifically for the Treo 680 can be found on github:
161 http://github.com/mike-dunn/linux-treo680
162 The master branch of this tree has been tested on the Treo, and I recommend
163 using this kernel for programming u-boot. As of this writing, there may be a
164 bug in the docg4 nand flash driver that sometimes causes block erasures to
165 fail. This has been fixed in the above tree.
166
167 If you choose to use the official kernel, it must contain the docg4 driver that
168 includes the reliable_mode module parameter. This was a later enhancement to
169 the driver, and was merged to the kernel as of v3.8. Do not try to use an
170 earlier kernel that contains the docg4 driver without support for writing in
171 reliable mode. If you try to program u-boot to flash with the docg4 driver
172 loaded without the reliable_mode parameter enabled, you *will* brick your
173 phone!
174
175 For the purpose of programming u-boot to flash, the following options must be
176 enabled in the Treo kernel's .config:
177
178 CONFIG_MTD=y
179 CONFIG_MTD_CMDLINE_PARTS=y
180 CONFIG_MTD_CHAR=y
181 CONFIG_MTD_NAND_DOCG4=m
182
183 Note that the docg4 nand driver is configured as a module, because we will
184 want to load and unload it with reliable_mode enabled or disabled as needed.
185
186 You will also need to specify mtd partitions on the kernel command line. In
187 the instructions that follow, we will assume that the flash blocks to which
188 u-boot will be programmed are defined by the second partition on the device.
189 The u-boot config file (include/configs/palmtreo680.h) places the u-boot image
190 at the start of block 6 (offset 0x180000), which is the first writable
191 (non-protected) block on the flash (this is also where the PalmOS SPL starts).
192 The u-boot image occupies four blocks, so to create the u-boot partition, pass
193 this command line to the kernel:
194 mtdparts=Msys_Diskonchip_G4:1536k(protected_part)ro,1024k(bootloader_part),-(filesys_part)
195 This will create three partitions:
196 protected_part: the first six blocks, which are read-only
197 bootloader_part: the next four blocks, for the u-boot image
198 filesys_part: the remainder of the device
199 The mtdchar kernel device driver will use device nodes /dev/mtd0, /dev/mtd1,
200 and /dev/mtd2 for these partitions, respectively. Ensure that your root file
201 system at least has /dev/mtd1 if you are not running udev or mdev.
202
203
204Userspace Utilities:
205
206 In addition to everything necessary to provide a useful userspace environment
207 (busybox is indispensable, of course), you will need the mtd-utils package on
208 your root filesystem. I use version 1.5.0 of mtd-utils, and I suggest you use
209 this version as well, or at leat a version very close to this one, as
210 mtd-utils has tended to be fluid.
211
212 Note that busybox includes a version of mtd-utils. These are deficient and
213 should not be used. When you run one of these utilities (nanddump, etc),
214 ensure you are invoking the separate executable from mtd-utils, and not the
215 one built into busybox. I recommend that you configure busybox with its
216 mtd-utils disabled to avoid any possibility of confusion.
217
218 You will also need to cross-compile the userspace Linux utility in
219 tools/palmtreo680/flash_u-boot.c, which we will run on the Treo to perform the
220 actual write of the u-boot image to flash. This utility links against libmtd
221 from the mtd-utils package.
222
223
224
225Desktop PC-side Software Prerequisites
226======================================
227
228Terminal emulator application:
229 minicom, kermit, etc.
230
231
232Linux kernel:
233 Compiled with CONFIG_USB_SERIAL enabled. Build this as a module.
234
235
236
237Recommended (Not directly related to u-boot)
238============================================
239
240Working directly on the Treo's tiny screen and keypad is difficult and
241error-prone. I recommend that you log into the Linux kernel running on your
242Treo from your desktop PC using ethernet over usb. The desktop's kernel must be
243configured with CONFIG_USB_USBNET, CONFIG_USB_NET_CDCETHER, and
244CONFIG_USB_NET_CDC_SUBSET. The Treo's kernel will need CONFIG_USB_ETH, and its
245init script will need to start an ssh daemon like dropbear. Note that the usb0
246network interface will not appear on the desktop PC until the Treo kernel's usb
247ethernet gadget driver has initialized. You must wait for this to occur (watch
248the PC's kernel log) before you can assign usb0 an ip address and log in to the
249Treo. If you also build the Treo's kernel with CONFIG_IP_PNP enabled, you can
250pass its ip address on the kernel command line, and obviate the need to
251initialize the network interface in your init script.
252
253Having the Palm usb cable connected to the host has the added benefit of keeping
254power supplied to your Treo, reducing the drain on the battery. If something
255goes wrong while you're programming u-boot to the flash, you will have lots of
256time to correct it before the battery dies.
257
258I have encountered a situation where the kernel is sometimes unable to mount a
259root filesystem on the mmc card due to the mmc controller not initializing in
260time, (and CONFIG_MMC_UNSAFE_RESUME doesn't seem to help) so I recommend that
261you build a minimal root filesystem into the kernel using the kernel's initramfs
262feature (CONFIG_BLK_DEV_INITRD). If you want your root filesystem on the mmc
263card, your init script can mount and switch_root to the mmc card after a short
264sleep. But keep in mind that in this case you won't be able to use an mmc card
265to transfer files between your desktop and the Treo once Linux is running.
266Another option for transfering files is to mount an nfs filesystem exported by
267the desktop PC. For greatest convenience, you can export the root filesystem
268itself from your desktop PC and switch_root to it in your init script. This
269will work if your initramfs init script contains a loop that waits for you to
270initialize the usb0 network interface on the desktop PC; e.g., loop while a ping
271to the desktop PC returns an error. After the loop exits, do the nfs mount and
272call switch_root. (You can not use the kernel nfsroot feature because the
273network will not be up when the kernel expects it to be; i.e., not until you
274configure the usb0 interface on the desktop.) Use the nfs 'nolock' option when
275mounting to avoid the need to run a portmapper like rpcbind.
276
277
278
279Preliminaries
280=============
281
282Once Linux is running on your Treo, you may want to perform a few sanity checks
283before programming u-boot. These checks will verify my assumptions regarding
284all the Treo 680s out there, and also ensure that the flash and mtd-utils are
285working correctly. If you are impatient and reckless, you may skip this
286section, but see disclaimer at the top of this file!
287
288Load the docg4 driver:
289
290 $ modprobe docg4 ignore_badblocks=1 reliable_mode=1
291
292We tell the driver to use the docg4's "reliable mode" when writing because this
293is the format required by the IPL, which runs from power-up and loads the first
294portion of u-boot. We must ignore bad blocks because linux mtd uses out-of-band
295(oob) bytes to mark bad blocks, which will cause the blocks written by PalmOS to
296be misidentified as "bad" by libmtd.
297
298Check the kernel log to ensure that all's well:
299
300 $ dmesg | tail
301 <... snip ...>
302 docg4 docg4: NAND device: 128MiB Diskonchip G4 detected
303 3 cmdlinepart partitions found on MTD device Msys_Diskonchip_G4
304 Creating 3 MTD partitions on "Msys_Diskonchip_G4":
305 0x000000000000-0x000000180000 : "protected_part"
306 0x000000180000-0x000000280000 : "bootloader_part"
307 0x000000280000-0x000008000000 : "filesys_part"
308
309Ensure that the partition boundaries are as shown. (If no partitions are shown,
310did you remember to pass them to the kernel on the command line?) We will write
311u-boot to bootloader_part, which starts at offset 0x180000 (block 6) and spans 4
312256k blocks. This partition is accessed through the device node /dev/mtd1.
313
314The docg4 contains a read-only table that identifies blocks that were marked as
315bad at the factory. This table is in the page at offset 0x2000, which is within
316the partition protected_part (/dev/mtd0). There is a slight chance that one or
317more of the four blocks that we will use for u-boot is listed in the table, so
318use nanddump to inspect the table to see if this is the case:
319
320 $ nanddump -p -l 512 -s 0x2000 -o /dev/mtd0
321 ECC failed: 0
322 ECC corrected: 0
323 Number of bad blocks: 0
324 Number of bbt blocks: 0
325 Block size 262144, page size 512, OOB size 16
326 Dumping data starting at 0x00002000 and ending at 0x00002200...
327 0x00002000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
328 <... snip ...>
329
330The format of the table is simple: one bit per block, with block numbers
331increasing from left to right, starting with block 0 as the most significant bit
332of the first byte. A bit will be clear if the corresponding block is bad. We
333want to use blocks 6 throgh 9, so both of the two least significant bits of the
334first byte must be set, as must the two most significant bits of the second
335byte. If this is not true in your case (you are very unlucky), you should use
336the first contiguous set of four good blocks after block 6, and adjust the
337partition boundaries accordingly. You will also have to change the value of
338CONFIG_SYS_NAND_U_BOOT_OFFS in include/configs/palmtreo680.h and recompile
339u-boot. Because the two blocks loaded by the IPL do not have to be contiguous,
340but our SPL expects them to be, you will need to erase any good blocks that are
341at an offset prior to CONFIG_SYS_NAND_U_BOOT_OFFS, so that the IPL does not find
342the magic number in oob and load it. Once you have done all this, the
343instructions in this file still apply, except that the instructions below for
344restoring the original PalmOS block contents may need to be modified.
345
346Next, use nanddump to verify that the PalmOS SPL is where we expect it to be.
347The SPL can be identified by a magic number in the oob bytes of the first page
348of each of the two blocks containing the SPL image. Pages are 512 bytes in
349size, so to dump the first page, plus the oob:
350
351 $ nanddump -p -l 512 -s 0 -o /dev/mtd1
352 ECC failed: 0
353 ECC corrected: 0
354 Number of bad blocks: 0
355 Number of bbt blocks: 0
356 Block size 262144, page size 512, OOB size 16
357 Dumping data starting at 0x00000000 and ending at 0x00000200...
358 0x00000000: 0a 00 00 ea 00 00 00 00 00 00 00 00 00 00 00 00
359 <... snip ...>
360 0x000001f0: 13 4c 21 60 13 4d 2a 69 13 4b 29 69 89 1a 99 42
361 OOB Data: 42 49 50 4f 30 30 30 10 3a e2 00 92 be a0 11 ff
362
363Verify that the first seven bytes of oob data match those in the above line.
364(This is ASCII "BIPO000".)
365
366Do the same for the next block:
367 $ nanddump -p -l 512 -s 0x40000 -o /dev/mtd1
368
369The first seven oob bytes in last line should read:
370
371 OOB Data: 42 49 50 4f 30 30 31 81 db 8e 8f 46 07 9b 59 ff
372
373(This is ASCII "BIPO001".)
374
375For additional assurance, verify that the next block does *not* contain SPL
376data.
377
378 $ nanddump -p -l 512 -s 0x80000 -o /dev/mtd1
379
380It doesn't matter what the oob contains, as long as the first four bytes are
381*not* ASCII "BIPO". PalmOS should only be using two blocks for the SPL
382(although we will need four for u-boot).
383
384If you want, you can back up the contents of bootloader_part to a file. You may
385be able to restore it later, if desired (see "Restoring PalmOS" below).
386
387 $ nanddump -l 0x100000 -s 0 -o -f bootloader_part.orig /dev/mtd1
388
389nanddump will spew voluminous warnings about uncorrectable ecc errors. This is
390a consequence of reading pages that were written in reliable mode, and is
391expected (these should all occur on pages in odd-numbered 2k regions; i.e.,
3920x800, 0xa00, 0xc00, 0xe00, 0x1800, 0x1a00, ...). The size of the file
393bootloader_part.orig should be 1081344, which is 2048 pages, each of size 512
394plus 16 oob bytes. If you are using initramfs for the root filesystem, don't
395forget to copy the file to permanent storage, such as an mmc card.
396
397If all of the above went well, you can now program u-boot.
398
399
400
401Programming u-boot
402==================
403
404Our u-boot includes a small SPL that must be prepended to u-boot proper. From
405the base u-boot source directory on your desktop PC:
406
407 $ cat spl/u-boot-spl.bin u-boot.bin > u-boot-concat.bin
408
409cd to the tools/palmtreo680/ directory, and cross-compile flash_u-boot.c for the
410Treo:
411
412 $(CC) -o flash_u-boot $(CFLAGS) $(INCLUDEPATH) $(LIBPATH) flash_u-boot.c -lmtd
413
414Substitute variable values from your cross-compilation environment as
415appropriate. Note that it links to libmtd from mtd-utils, and this must be
416included in $(LIBPATH) and $(INCLUDEPATH).
417
418Transfer u-boot-concat.bin and the compiled flash_u-boot utility to the Treo's
419root filesystem. On the Treo, cd to the directory where these files were
420placed.
421
422Load the docg4 driver if you have not already done so.
423
424 $ modprobe docg4 ignore_badblocks=1 reliable_mode=1
425
426Erase the blocks to which we will write u-boot:
427
428 $ flash_erase /dev/mtd1 0x00 4
429
430If no errors are reported, write u-boot to the flash:
431
432 $ ./flash_u-boot u-boot-concat.bin /dev/mtd1
433
434You can use nanddump (see above) to verify that the data was written. This
435time, "BIPO" should be seen in the first four oob bytes of the first page of all
436four blocks in /dev/mtd1; i.e., at offsets 0x00000, 0x40000, 0x80000, 0xc0000.
437
438Shutdown linux, remove and re-insert the battery, hold your breath...
439
440
441
442Enjoying u-boot
443===============
444
445After you insert the battery, the u-boot splash screen should appear on the lcd
446after a few seconds. With the usb cable connecting the Treo to your PC, in the
447kernel log of your PC you should see
448
449 <6>usb 3-1: New USB device found, idVendor=0525, idProduct=a4a6
450 <6>usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
451 <6>usb 3-1: Product: U-Boot 2013.01-00167-gd62ef56-dirty
452 <6>usb 3-1: Manufacturer: Das U-Boot
453
454Load the usbserial module on your desktop PC:
455
456 $ modprobe usbserial vendor=0x0525 product=0xa4a6
457
458and run your favorite terminal emulation utility (minicom, kermit, etc) with the
459serial device set to /dev/ttyUSB0 (assuming this is your only usb serial
460device). You should be at the u-boot console (type 'help').
461
462There is not much that is unique about using u-boot on the palm treo 680.
463Kernels can be loaded from mmc, flash, and from the desktop PC via kermit. You
464can expand the size of the second partition on the flash to contain a kernel, or
465else put the kernel(s) in their own partition.
466
467Nand commands work as expected, with the excepton that blocks not written by the
468linux mtd subsystem may be misidentified by the u-boot docg4 driver as "bad" if
469they contain data in the oob bytes. This will be the case for the blocks
470containing the u-boot image, for example. To work around this, use 'nand scrub'
471instead of 'nand erase' to erase these blocks, and 'nand read.raw' to read them
472to memory. (It would be useful if u-boot's nand commands provided a way to
473explicitly ignore "bad" blocks, because read.raw does not perform ecc.) The
474'nand dump' command will read these "bad" blocks, however.
475
476Currently u-boot itself can only be programmed to flash from Linux; there is no
477support for reliable mode in u-boot's docg4 flash driver. This should be
478corrected soon.
479
480
481
482Customizing
483===========
484
485If you change u-boot's configuration significantly (adding or removing
486features), you may have to adjust the value of CONFIG_SYS_NAND_U_BOOT_SIZE.
487This is the size of the concatenated spl + u-boot image, and tells the SPL how
488many flash blocks it needs to load. It will be rounded up to the next 64k
489boundary (the spl flash block capacity), so it does not have to be exact, but
490you must ensure that it is not less than the actual image size. If it is larger
491than the image, blocks may be needlessly loaded, but if too small, u-boot may
492only be partially loaded, resulting in a boot failure (bricked phone), so better
493to be too large. The flash_u-boot utility will work with any size image and
494write the required number of blocks, provided that the partition is large
495enough.
496
497As the first writable block on the device, block 6 seems to make the most sense
498as the flash offset for writing u-boot (and this is where PalmOS places its
499SPL). But you can place it elsewhere if you like. If you do, you need to
500adjust CONFIG_SYS_NAND_U_BOOT_OFFS accordingly, and you must ensure that blocks
501preceeding the ones containing u-boot do *not* have the magic number in oob (the
502IPL looks for this). In other words, make sure that any blocks that previously
503contained the u-boot image or PalmOS SPL are erased (and optionally written with
504something else) so that the IPL does not load it. Also make sure that the new
505u-boot starting offset is at the start of a flash partition (check the kernel
506log after loading the docg4 driver), and pass the corresponding mtd device file
507to the flash_u-boot utility.
508
509The u-boot built-in default environment is used because a writable environment
510in flash did not seem worth the cost of a 256k flash block. But adding this
511should be straightforward.
512
513
514
515Restoring PalmOS
516================
517
518If you backed up the contents of bootloader_part flash partition earlier, you
519should be able to restore it with the shell script shown below. The first two
520blocks of data contain the PalmOS SPL and were written in reliable mode, whereas
521the next two blocks were written in normal mode, so the script has to load and
522unload the docg4 driver. Make sure that the mtd-utils nandwrite and flash_erase
523are in your path (and are not those from busybox). Also double-check that the
524backup image file bootloader_part.orig is exactly 1081344 bytes in length. If
525not, it was not backed up correctly. Run the script as:
526
527 ./restore_bootpart bootloader_part.orig /dev/mtd1
528
529The script will take a minute or so to run. When it finishes, you may want to
530verify with nanddump that the data looks correct before you cycle power, because
531if the backup or restore failed, your phone will be bricked. Note that as a
532consequence of reliable mode, the odd-numbered 2k regions in the first two
533blocks will not exactly match the contents of the backup file, (so unfortunately
534we can't simply dump the flash contents to a file and do a binary diff with the
535original back-up image to verify that it was restored correctly). Also,
536nanddump will report uncorrectable ecc errors when it reads those regions.
537
538#!/bin/sh
539
540if [ $# -ne 2 ]; then
541 echo "usage: $0: <image file> <mtd device node>"
542 exit 1
543fi
544
545# reliable mode used for the first two blocks
546modprobe -r docg4
547modprobe docg4 ignore_badblocks=1 reliable_mode=1 || exit 1
548
549# erase all four blocks
550flash_erase $2 0 4
551
552# Program the first two blocks in reliable mode.
553# 2k (4 pages) is written at a time, skipping alternate 2k regions
554# Note that "2k" is 2112 bytes, including 64 oob bytes
555file_ofs=0
556flash_ofs=0
557page=0
558while [ $page -ne 1024 ]; do
559 dd if=$1 bs=2112 skip=$file_ofs count=1 | nandwrite -o -n -s $flash_ofs $2 - || exit 1
560 file_ofs=$((file_ofs+2))
561 flash_ofs=$((flash_ofs+0x1000))
562 page=$((page+8))
563done;
564
565# normal mode used for the next two blocks
566modprobe -r docg4
567modprobe docg4 ignore_badblocks=1 || exit 1
568dd if=$1 bs=1 skip=$file_ofs count=540672 | nandwrite -o -n -s 0x80000 $2 - || exit 1
569modprobe -r docg4
570
571
572TODO
573====
574
575 - Keypad support.
576 - Interactive boot menu using keypad and lcd.
577 - Add reliable mode support to the u-boot docg4 driver.
578 - U-boot command that will write a new image to the bootloader partition in
579 flash.
580 - Linux FTD support.
581