FreeCalypso > hg > freecalypso-reveng
comparison fluid-mnf/README @ 364:37d647dfb920
fluid-mnf/README: coming further along
author | Mychaela Falconia <falcon@freecalypso.org> |
---|---|
date | Sun, 15 Mar 2020 03:52:23 +0000 |
parents | 6cff3ee315e0 |
children | f888ae294b1b |
comparison
equal
deleted
inserted
replaced
363:6cff3ee315e0 | 364:37d647dfb920 |
---|---|
277 * The D-Sample board also has a block of 16 debug LEDs controlled by another | 277 * The D-Sample board also has a block of 16 debug LEDs controlled by another |
278 register mapped into Calypso nCS3 address space, and FLUID's target-side | 278 register mapped into Calypso nCS3 address space, and FLUID's target-side |
279 component (which we haven't modified except for the 39 MHz fix) displays | 279 component (which we haven't modified except for the 39 MHz fix) displays |
280 pretty dancing patterns on these LEDs as it does its work. | 280 pretty dancing patterns on these LEDs as it does its work. |
281 | 281 |
282 FLUID operating on Openmoko devices | |
283 =================================== | |
284 | |
285 While nowhere near as sexy as on TI's own D-Sample, our fluid-mnf port works | |
286 well on Openmoko modems: | |
287 | |
288 * Only fluid-mnf -oo mode works on Openmoko devices, NOT fluid-mnf -oO, same as | |
289 with Leonardo or Caramel boards or any other Calypso 26 MHz platform. We have | |
290 incriminating evidence that Openmoko once made fluid -oO mode work on their | |
291 platform by witchcraft (bending the known laws of physics), but we were never | |
292 able to reproduce that paranormal feat - see this FreeCalypso community | |
293 mailing list thread: | |
294 | |
295 https://www.freecalypso.org/pipermail/community/2020-March/000743.html | |
296 | |
297 * Don't try D-Sample XXO baud rates of 230400, 460800 or 921600 bps - they | |
298 won't work. However, Calypso high baud rates of 203125, 406250 and 812500 bps | |
299 do work if you are going through the external headset jack and have one of | |
300 the better USB-serial cables, either FTDI or appropriately programmed CP2102. | |
301 | |
302 Target boot control | |
303 =================== | |
304 | |
305 The code we got from TI in fluid-2.27.zip includes a rather bizarre provision | |
306 for some ancient way of doing target boot control: right after opening the | |
307 target serial port but before sending periodic beacons seeking to interrupt and | |
308 divert the boot path either in the Calypso boot ROM or in a flash-resident | |
309 FLUID bootloader, FLUID does some manipulation of the host UART's DTR and RTS | |
310 outputs, as well as sending a break on the main data line. These manipulations | |
311 do absolutely nothing on any ordinary Calypso hardware: the DTR line goes only | |
312 to a GPIO if anywhere at all; the host's RTS output line will normally be | |
313 connected to Calypso CTS_MODEM input if it's the MODEM UART, but these flow | |
314 control lines are completely ignored by both the Calypso boot ROM and various | |
315 flash-resident bootloaders. But apparently there once existed some special | |
316 cable, interfaced to some unknown (probably very early and TI-internal) Calypso | |
317 or before-Calypso targets in some unknown way, and that arrangement produced a | |
318 target reset (probably a predecessor of Iota nTESTRESET on whatever before-Iota | |
319 ABB) when FLUID did this wiggle. | |
320 | |
321 In any case, that hardware no longer exists and cannot be recreated because we | |
322 have no idea what it was like and how it is supposed to work. But the logic in | |
323 question is still there in this fluid-mnf port; running OM's fluid.exe under | |
324 strace reveals that they had retained this logic as well, although they broke | |
325 the code that generates a break on the serial data line - how ironic. | |
326 | |
327 Aside from this non-understood UART control line wiggling, there is no effective | |
328 target boot control in FLUID: not in TI's original version, not in OM's port | |
329 and not in the present fluid-mnf. You just run FLUID against a serial port, it | |
330 sends beacons and waits forever for the selected bootloader (boot ROM or FLUID | |
331 bl) to respond, and you have to cause the Calypso target to go through its boot | |
332 path by your own external means. Most importantly, there is no provision for | |
333 automation, i.e., no provision for the process to exit with an error code | |
334 instead of hanging forever if you got some target boot control implemented, but | |
335 the bootloader fails to respond as expected - put another way, there is no | |
336 equivalent to loadtools -t option which we've added as of fc-host-tools-r13. | |
337 | |
338 Performance | |
339 =========== | |
340 | |
341 Even though it cannot be a replacement for fc-loadtool in most use cases, FLUID | |
342 is very aggressively optimized for speed in ways that would be hard to match in | |
343 our fc-loadtool architecture: | |
344 | |
345 * FLUID's serial protocol between the host tool and the target-side component | |
346 includes compression (some form of LZ77) for blocks of data destined for | |
347 flash; | |
348 | |
349 * The process of programming flash is parallelized: the bits to be programmed | |
350 are serially transferred into a large RAM buffer on the target in parallel | |
351 with the execution of flash erase and program operations on the target; | |
352 specifically, flash erase and program operation functions call the UART Rx | |
353 handler function (which handles the incoming serial stream) as they poll the | |
354 flash chip to complete its operation! | |
355 | |
356 For these reasons, on those targets which are supported by both FLUID and | |
357 fc-loadtool, flash programming with FLUID is faster. Here are the performance | |
358 numbers obtained on the Mother's Slackware 14.2 host system, flashing an | |
359 Openmoko GTA02 modem with firmware version moko-new-fw-20190128, going through | |
360 the external headset jack, UberWaves CP2102 Professional cable: | |
361 | |
362 fluid-mnf at 115200 baud: 2m28s | |
363 fc-loadtool at 115200 baud: 4m02s | |
364 fluid-mnf at 812500 baud: 0m40s | |
365 fc-loadtool at 812500 baud: 1m12s | |
366 | |
367 With both tools the m0 version of the firmware image (fwimage.m0) was being | |
368 flashed; in the case of fc-loadtool the new flash e-program-m0 command was used. | |
369 The version of fc-loadtool used for this test is the one that is about to be | |
370 released with fc-host-tools-r13; previous versions would be even slower. In | |
371 the case of fluid-mnf the -C option was used to disable delta downloads, making | |
372 the test operation independent of previous flash state. |