FreeCalypso > hg > freecalypso-tools
comparison doc/Flash-programming @ 677:3a41d69e8104
doc/Flash-programming: added section about discontiguous m0 images
author | Mychaela Falconia <falcon@freecalypso.org> |
---|---|
date | Sun, 08 Mar 2020 22:53:30 +0000 |
parents | b6b8307d195b |
children | a7496a1e0df7 |
comparison
equal
deleted
inserted
replaced
676:b6b8307d195b | 677:3a41d69e8104 |
---|---|
75 sectors into which new bits will be programmed, then programs the new bits. | 75 sectors into which new bits will be programmed, then programs the new bits. |
76 Thus a third equally good way to flash a new FreeCalypso fw release into a | 76 Thus a third equally good way to flash a new FreeCalypso fw release into a |
77 target such as FCDEV3B or GTA02 is to execute | 77 target such as FCDEV3B or GTA02 is to execute |
78 'flash e-program-bin 0 fwimage.bin' - but don't *ever* do it on a Mot C1xx | 78 'flash e-program-bin 0 fwimage.bin' - but don't *ever* do it on a Mot C1xx |
79 phone! | 79 phone! |
80 | |
81 Discontiguous m0 fw images with large gaps | |
82 ========================================== | |
83 | |
84 One sometimes-advantage of S-record-based formats over straight binary is that | |
85 they can have discontiguous filled regions with gaps in between them; all m0 fw | |
86 images produced by TI's TCS211 build system have some gaps in them. In our | |
87 current FC Magnetite firmwares these gaps have been reduced to less than 16384 | |
88 bytes in total, reducing the wasted disk space and image transfer time to | |
89 sufficiently insignificant if these m0 images are converted to straight binary | |
90 with mokosrec2bin and then flashed as binary as we've been doing. For | |
91 comparison, in Openmoko's classic mokoN firmwares (almost TI's original version | |
92 of the memory map) the first flash sector of 65536 bytes had only 5072 bytes of | |
93 image payload programmed into it, thus indirect programming via mokosrec2bin | |
94 followed by flash program-bin meant sending just over 60k filler 0xFF bytes to | |
95 be flashed - becomes noticeable at 115200 baud. | |
96 | |
97 But these gaps were even bigger in TI's classic firmwares (and many vendor | |
98 firmwares) built for 8 MiB or 16 MiB flash chips with TI's classic memory map. | |
99 They have two code regions: one region is exactly 4 MiB in size but is placed | |
100 not quite at the beginning, thus spilling past the chip midpoint, and the other | |
101 region starts where the first 4 MiB region ends, going to the end of the flash | |
102 chip or to the beginning of the area reserved for FFS. The way TI's linker | |
103 works results in the first of these two program regions being not quite full | |
104 before bits start getting thrown into the second one, thus the resulting m0 | |
105 image can easily have a gap of a megabyte or more between the two regions. | |
106 TI's own FLUID handles such discontiguous images with no sweat, but our | |
107 fc-loadtool has gained matching capability only as of fc-host-tools-r13 with | |
108 our new e-program-m0 command. And yes, it is smart enough to avoid needlessly | |
109 erasing sectors in the big gap, just like FLUID. | |
80 | 110 |
81 Flash backup and restore | 111 Flash backup and restore |
82 ======================== | 112 ======================== |
83 | 113 |
84 A completely different paradigm takes place on alien targets such as Motorola | 114 A completely different paradigm takes place on alien targets such as Motorola |