# HG changeset patch # User Mychaela Falconia # Date 1584244343 0 # Node ID 37d647dfb920f8a2f840c662b772892b0bc20ff2 # Parent 6cff3ee315e0f8a87d0bc48f124a114fc622cb55 fluid-mnf/README: coming further along diff -r 6cff3ee315e0 -r 37d647dfb920 fluid-mnf/README --- a/fluid-mnf/README Sun Mar 15 03:02:13 2020 +0000 +++ b/fluid-mnf/README Sun Mar 15 03:52:23 2020 +0000 @@ -279,3 +279,94 @@ component (which we haven't modified except for the 39 MHz fix) displays pretty dancing patterns on these LEDs as it does its work. +FLUID operating on Openmoko devices +=================================== + +While nowhere near as sexy as on TI's own D-Sample, our fluid-mnf port works +well on Openmoko modems: + +* Only fluid-mnf -oo mode works on Openmoko devices, NOT fluid-mnf -oO, same as + with Leonardo or Caramel boards or any other Calypso 26 MHz platform. We have + incriminating evidence that Openmoko once made fluid -oO mode work on their + platform by witchcraft (bending the known laws of physics), but we were never + able to reproduce that paranormal feat - see this FreeCalypso community + mailing list thread: + + https://www.freecalypso.org/pipermail/community/2020-March/000743.html + +* Don't try D-Sample XXO baud rates of 230400, 460800 or 921600 bps - they + won't work. However, Calypso high baud rates of 203125, 406250 and 812500 bps + do work if you are going through the external headset jack and have one of + the better USB-serial cables, either FTDI or appropriately programmed CP2102. + +Target boot control +=================== + +The code we got from TI in fluid-2.27.zip includes a rather bizarre provision +for some ancient way of doing target boot control: right after opening the +target serial port but before sending periodic beacons seeking to interrupt and +divert the boot path either in the Calypso boot ROM or in a flash-resident +FLUID bootloader, FLUID does some manipulation of the host UART's DTR and RTS +outputs, as well as sending a break on the main data line. These manipulations +do absolutely nothing on any ordinary Calypso hardware: the DTR line goes only +to a GPIO if anywhere at all; the host's RTS output line will normally be +connected to Calypso CTS_MODEM input if it's the MODEM UART, but these flow +control lines are completely ignored by both the Calypso boot ROM and various +flash-resident bootloaders. But apparently there once existed some special +cable, interfaced to some unknown (probably very early and TI-internal) Calypso +or before-Calypso targets in some unknown way, and that arrangement produced a +target reset (probably a predecessor of Iota nTESTRESET on whatever before-Iota +ABB) when FLUID did this wiggle. + +In any case, that hardware no longer exists and cannot be recreated because we +have no idea what it was like and how it is supposed to work. But the logic in +question is still there in this fluid-mnf port; running OM's fluid.exe under +strace reveals that they had retained this logic as well, although they broke +the code that generates a break on the serial data line - how ironic. + +Aside from this non-understood UART control line wiggling, there is no effective +target boot control in FLUID: not in TI's original version, not in OM's port +and not in the present fluid-mnf. You just run FLUID against a serial port, it +sends beacons and waits forever for the selected bootloader (boot ROM or FLUID +bl) to respond, and you have to cause the Calypso target to go through its boot +path by your own external means. Most importantly, there is no provision for +automation, i.e., no provision for the process to exit with an error code +instead of hanging forever if you got some target boot control implemented, but +the bootloader fails to respond as expected - put another way, there is no +equivalent to loadtools -t option which we've added as of fc-host-tools-r13. + +Performance +=========== + +Even though it cannot be a replacement for fc-loadtool in most use cases, FLUID +is very aggressively optimized for speed in ways that would be hard to match in +our fc-loadtool architecture: + +* FLUID's serial protocol between the host tool and the target-side component + includes compression (some form of LZ77) for blocks of data destined for + flash; + +* The process of programming flash is parallelized: the bits to be programmed + are serially transferred into a large RAM buffer on the target in parallel + with the execution of flash erase and program operations on the target; + specifically, flash erase and program operation functions call the UART Rx + handler function (which handles the incoming serial stream) as they poll the + flash chip to complete its operation! + +For these reasons, on those targets which are supported by both FLUID and +fc-loadtool, flash programming with FLUID is faster. Here are the performance +numbers obtained on the Mother's Slackware 14.2 host system, flashing an +Openmoko GTA02 modem with firmware version moko-new-fw-20190128, going through +the external headset jack, UberWaves CP2102 Professional cable: + +fluid-mnf at 115200 baud: 2m28s +fc-loadtool at 115200 baud: 4m02s +fluid-mnf at 812500 baud: 0m40s +fc-loadtool at 812500 baud: 1m12s + +With both tools the m0 version of the firmware image (fwimage.m0) was being +flashed; in the case of fc-loadtool the new flash e-program-m0 command was used. +The version of fc-loadtool used for this test is the one that is about to be +released with fc-host-tools-r13; previous versions would be even slower. In +the case of fluid-mnf the -C option was used to disable delta downloads, making +the test operation independent of previous flash state.