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.