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. |